소프트웨어 설계 - 요구사항 확인 및 분석

정보처리기사 필기 준비하며 정리한 내용입니다.

소프트웨어 설계

소프트웨어 개발 단계

1. 계획
   1. 요구사항 확인
2. 분석
   1. 모델링
   2. 분석 명세
3. 설계
   1. 모델링한 것을 가지고 꼼꼼히 그림 그리는 단계
   2. 스토리보드 등
4. 구현 (개발)
5. 테스트
6. 유지운영

 

요구사항 확인

1. 도출

요구사항 도출 기법 ⭐

• 인터뷰
• 관찰 (고객사의 업무 프로세스 관찰) 또는 문화기술적 연구
• 사용자 스토리 (여러 사람의 업무에 관한 얘기를 하나씩 받는다)
• 시나리오 (요구사항 절차적으로, 이야기식으로 나열)
• 설문조사
• 브레인 스토밍
• 포커스 그룹 (이해관계자들이 모여서 회의)
• 워크샵

 

2. 분석

성능 특성 분석 측정 항목

이후에 나올 운영체제 등 모든 측정은 이것과 동일하다.

1. 반환시간 Turnaround Time
   • 요청 전달→응답→처리완료까지 걸린 시간
2. 응답시간 Response Time
   • 요청 전달→응답까지 걸린 시간
3. 가용성 Availability
   • 정보시스템이 정상적으로 사용 가능한 정도
     • 언제든지 사용 가능한지
     • ex. 카카오의 장애는 가용성이 떨어졌다고 표현한다.
   • 가용성을 올리기위한 고가용성 작업(H.A)
     • 서버를 2대 둔다.
       1. A 액티브 서버
       2. S 스탠바이 서버
          • 액티브 서버 장애시 스탠바이 서버로 돌리는 구조.
4. 사용률 Utilization
   • 요청을 처리하는 동안 CPU, 메모리 등의 자원 사용률
5. = 효율성

⭐ 반환시간과 응답시간을 구분하자!

 

모델링

모델링이랑 그림그리는 작업(비주얼화).

전반적으로 [분석→설계(둘은 완벽히 구분하는 것이 애매하다] 단계에서 사용한다.

• 기능적 모델링
  • 시스템의 기능을 사용자 관점에서 나타낸다
• 정적 모델링
  • 구조
  • 객체 간의 관계
  • 클래스 다이어그램을 주로 이용한다.
• 동적 모델링
  • 변화하는 과정들
  • 시간의 흐름에 따라 객체들을 모델링한다
  • 상태 다이어그램을 주로 이용한다

 

📌구조적 분석

구조적 분석 방법론

• 절차적인 프로그래밍 모델링할 때 사용
  • 절차적인 언어에는 대표적으로 C가 있다
• ⭐하향식 기능 분해 기법 사용

⭐ 구조적=절차적 분석 도구

• DFD (Data Flow Diagram) : 데이터(자료) 흐름도
  • 특징
    • 가장 보편적으로 사용된다
    • 기능 중심에 적합
    • 버블 차트 = 자료 흐름 그래프
  • ⭐ 구성요소
    • 처리과정(Process)
      • 기호 ○로 표시
      • 데이터가 어떻게 처리됐는지
    • 자료 흐름 Data Flow
      • 화살표로 표시
    • 자료 저장소
      • = 짝대기 두개 사이에 글자를 써서 표시
    • 단말
      • 가장 끝단에 있는 데이터 입출력 주체 (사용자)
      • 네모박스
• Data Dictionary : 자료 사전 (그 데이터의 상세한 내용)
  • 자료 흐름도에 기술된 모든 자료들에 대한 사항을 자세히 정의
  • 기호
    • 정의 = : ~로 구성되어 있다
    • 연결 +
    • 생략 () : 생략 가능한 자료
    • 자료 선택 [ | ] : 여러 대안 중 하나 선택
    • 자료 반복 { }
    • 자료 설명 * * : 주석
  • 예시
    • 자료 흐름 : 쇼핑몰 회원정보는 회원번호, 회원성명, 전화번호, 휴대폰번호로 구성되어 있고, 전화번호와 휴대폰번호는 둘 중 하나만 선택이 가능하다.
    • 자료사전 표기형식 : 회원정보 = 회원번호 + 회원성명 + [전화번호 | 휴대폰번호]
• Mini-Spec : 소단위 명세서
  • 작은 프로세스의 덩어리. = 프로세스 명세서
    • 자료 흐름도에서 어떤 일이 수행되는지를 정희하기 위해 각 처리들이 수행하는 업무를 상세하게 작성
• ERD (Entity Relationship Diagram) : 개체 관계도 ⭐
  • 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화하는 데 사용
  • 구성 (기호 기억하기)
    • 개체 : □네모박스
    • 속성 : ○동그라미
    • 관계 : ◇마름모
• STD (State Transition Diagram) : 상태 전이도
  • 시스템에 어떤 일이 발생하는지 상태의 변화에 대해 나타내는 것.

 

📌객체지향 분석 방법론

⭐ 객체지향 분석 도구 UML (Unified Modeling Language)

• UML 특징 ⭐
  • 프로그램 설계를 표현하기 위해 사용하는 표기법
  • 개발, 기획 서로 알아보기 쉽게 만드는 것
  1. 가시화 언어
     • 시각적 그래픽이니까
  2. 명세화 언어
     • 작성했으니 문서로 남을 수 있다
  3. 구축 언어
     • 이것을 가지고 개발을 하니까
     • 명세화된 모델을 소스코드로 변환 → 이게 잘 안되기에 개발자가 필요하다
  4. 문서화 언어
     • 일련의 과정을 문서로 남겨 계속 유지 보수한다.
• UML 구성요소 ⭐
  1. 사물 Things
     • 모델을 구성하는 가장 중요한 기본 요소
     • ex. 회원
  2. 관계 Relationships
     • 사물과 사물 사이 연관성
     • 회원이라는 사물과 주문이라는 사물은 관계를 맺는다
  3. 다이어그램 Diagram
     • 위의 사물과 관계를 도형으로 표현한 것
• 관계
  • 일반화 관계 Generalization
    • 상속관계 : 한 클래스가 다르 클래스를 포함하는 상위 개념일 때의 관계
      • 객체지향 개념에서는 일반화 관계를 상속관계라고 한다.
  • 연관관계 Accociation
    • 2개 이상의 사물이 서로 관련된 관계
    • 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 표시
      • ex. 사람—휴대폰
  • 의존관계 Dependency
    • 연관 관계와의 유사성
      • 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때
    • 연관 관계와의 차이점
      • 두 클래스의 관계가 한 메서드를 실행하는 동안과 같이 매우 짧은 시간만 유지된다.
        • 아주 잠깐만 사용하는 것
      • ex. 학생…색연필
  • 실체화 관계 Realization
    • 추상적으로 공통된 성질을 만들고 이것으로 구현하는 것
      • 추상화란?
        • 공통적인 성질을 묶어놓는 것
      • ex. 리모콘의 틀이라는 공통된 성질을 두고, 이걸 가지고 선풍기, TV, 에어컨 등에서 구현하는 것 = 추상화
  • 집합 관계
    • 집약 관계 Aggregation
      • 뒤에 나올 합성관계와 구분할 것
      • has a 관계
        • 한 객체가 다른 객체를 소유한다.
      • 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적
        • ex. 불고기—간장, 다시다, 미원
          • 다시다나 미원이 없어도 된다는 뜻 (맛은 없겠지만!)
    • 합성 관계 Composition
      • 집약 관계와의 중요한 차이점
        • 긴밀한 필수적 관계 (부분 객체가 전체 객체에 속하는 관계)
          • 없으면 절대 안됨
      • 전체 객체의 라이프타임과 부분 객체의 라이프타임은 의존적이다
        • ex. 책상—책상 다리, 상판, 나사
          • (부러지면 버려야 한다!)
  • UML 산출물
    1. 구조 다이어그램 (정적)
       • 클래스 다이어그램 ✅ 대표적!
         • 클래스 속성과 클래스 사이의 관계를 표현
         • ex. User 안에 ID, PW 등등이 있다
           • 고객이라는 클래스가 있고, 변수랑 메서드가 있다는 걸 하나의 박스로 그림. → 그리고 이런 클래스들간의 관계를 표시
           • 접근제한자
             • - private : 해당 클래스 안에서만 접근 가능
             • # protected : 상속이거나, 동일 패키지 안에서 사용 가능
             • + public : 아무나 다 사용 가능
       • 객체 다이어그램
         • 하나의 인스턴스가 특정 시점에 만들어졌을 때 그걸 객체 다이어그램이라고 한다.
           • 클래스 다이어그램에서 만들어지게 된다
         • ex. 유저 한명이 들어온다 = 인스턴스가 생긴다
       • 컴포넌트 다이어그램
         • 컴포넌트 사이 관계
       • 배치 다이어그램
         • 어디에 무엇을 배치했는지 (위치, 노드, 통신경로)
       • 복합체 구조 다이어그램
         • 복합 구조를 가질시
       • 패키지 다이어그램 ✅
         • 클래스 다이어그램을 관련있는 것들 끼리 묶어 패키지로 만든 것
    2. 행위 다이어그램 (동적)
       • 구조 다이어그램이 변화할 때 만들어진다
       • 유스케이스 다이어그램 Use Case ✅ 대표적!
         • Actor(사용자나 외부 시스템)가 어떤 기능을 수행하는지
         • 구성요소
           1. 시스템 : 만들고자 하는 프로그램 명칭 ex. 로그인
              • 네모박스
           2. 액터 Actor : 외부시스템, 사용자 등 (사스템과 상호작용을 하는 외부에 있는 사람 or 시스템)
              • 졸라맨
           3. 유스케이스 Usecase : 사용자 입장에서 바라본 시스템의 기능 (어떤 시스템 안에서 어떤 액터가 어떤 기능을 수행한다)
              • 타원형
           4. 관계 Relation : 액터와 유스케이스 사이의 의미있는 관계
              • 연관 관계 Association
              • 액터와 유스케이스간의 상호작용
              • 실선으로 연결
                • ex. 사용자가 글을 등록하는 경우
              • 포함 관계 include
                • 유스케이스를 수행할 떄 반드시 실행되어야 하는 경우
                  • ex. 액터가 글을 쓰고 싶은 연관관계가 있을 때 로그인을 반드시 해야 한다 <<include>>
              • 확장 관계 Extend
                • 유스케이스를 수행할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우
                  • 해도 되고 안해도 된다
                  • ex. 글을 등록할 때 파일을 첨부하는 것 (반드시 하지 않아도 되는 것) <<extend>>
              • 일반화 관계 Generalization
                • 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스
                  • 상속받는 것
                  • ex. 글을 검색한다←글쓴이로 검색, 날짜로 검색
       • 순차 다이어그램 Sequence Diagram
         • 특정 행동이 어떤 순서로 어떤 객체와 상호작용하는지 표현
           • 순차적으로 흘러가는 것
         • 구성요소
           • 객체
           • 생명선(라이프라인)
           • 활성박스
           • 메시지
         • 오브젝트 사이의 상호작용 관계
       • 커뮤니케이션 다이어그램
         • 주고받는 메시지 같은 연관관계까지 표현
       • 상태 다이어그램
         • 객체가 어떤 상태로 바뀌는지, 상태변화, (구조 다이어그램의 상태 변화)
         • 시작이 있고 끝이 있다
         • ex. 주문→결제 준비 → 결제 대기 / 결제 실패 등
       • 활동 다이어그램
         • 어떤 기능 수행하는지
       • 상호작용 다이어그램
         • 상호작용 다이어그램 간 제어 흐름 표현
       • 타이밍 다이어그램
         • 객체 상태 변화와 시간 제약
  • UML 확장 모델 스테레오 타입
    • 그냥 이 기능이 확장된 것 = 스테레오 타입
    • << >>를 사용해 확장 요소를 나타낸다
      • ex. <<interface>> : 인터페이스 클래스

 

⭐ 객체 지향 분석 모델

• 특징
  • 상향식
  • 가장 많이 쓰이는 것이 클래스 다이어그램
    • +, -, # 기억하기
  • 구조, 연산(행위=메서드), 속성, 그들간의 관계
• 종류
  1. Rumbaugh(럼바우) 방법 ⭐
     • 가장 일반적으로 사용되는 방법
       • 객체 모델, 동적 모델, 기능 모델로 나누어 수행한다.
     • 분석 절차
       • 객체 모델링
         • 처음에 클래스(구조)를 만들어야 하니까 객체부터 한다
         • 객체 다이어그램으로 표현.
       • 동적 모델링
         • 객체를 만들었으니 객체의 상태 변화해야 한다!
           • 동적인 게 나오려면 앞에 정적인 게 있어야
         • 상태 다이어그램 이용.
       • 기능 모델링
         • 기능의 순서
           • 기능이 어떻게 돌아갈 것인가
             • 기능이 돌아가려면 자료가 있어야 한다
         • 자료 흐름도 이용.
           • 자료가 흘러가야하니까 자료 흐름도 이용
  2. Booch(부치) 방법
     • 미시적 + 거시적 모두 사용
  3. Jacobson(제이콥슨) 방법
     • Use case 사용
  4. Coad(코드)와 Yourdon(요돈) 방법
     • ER 다이어그램을 사용
  5. Wirfs-Brock(워프-브록) 방법
     • 분석과 설계 간의 구분이 없다.

 

📌분석 자동화 도구

CASE (Computer Aided Software Engineering) 도구

• 개념
  • CAD도 Compute Aided Design의 약자다 (디자인을 컴퓨터가 도와준다는 뜻)
    • 즉 소프트웨어 개발을 컴퓨터가 도와준다는 뜻이다!
  • 뭔가 개발할 때 도움을 주는 것들은 다 CASE도구
    • 일부 또는 전체를 자동화 (반복적인 것들을 편하게 할 수 있도록 해줌)
• 주요기능
  • S/W 라이프사이클 전 단계의 연결 (전반적으로 관리해줘서)
  • 자료흐름도 등 다이어그램 작성 편의 지원
  • 다양한 소프트웨어 개발 모형 지원
  • 시스템 문서화 및 명세화 위한 그래픽 지원
• 분류
  • 상위 CASE
    • 분석 설계 단계
      • 생명주기 전반부에 사용
        • 생명주기란? = S/W Development Life Cycle
          • 소프트웨어가 만들어지기 시작(계획) ~ 폐기 될때까지의 전 과정
  • 하위 CASE
    • 구현 테스트 단계
      • 생명주기 후반부
    • 코드 작성, 테스트, 문서화 과정
  • 통합 CASE
    • 말 그대로 두개를 통합한 것 (전 과정 지원)

HIPO (Hierarchical Inut Process Output)

• 개념
  • 하향식 (절차적) 소프트웨어 개발을 위한 문서화 도구
  • 도표. (하이포 차트라고 한다)
• 종류 ⭐
  • 가시적 도표
    • 입력, 처리, 출력 없음
      • 큰 그림을 그리는 것이라 세세한 입출력이 없다.
    • 전체적인 구조를 보는 것
  • 총체적 도표
    • 프로그램 구성하는 기능 기술
    • 여기부턴 입력, 처리, 출력이 들어간다.
  • 세부적 도표
    • 기본 요소 상세히 기술

 

3. 명세

정리, 명세화

• 전체적인 구조를 문서화
• 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성한다.

📌요구사항 명세 기법

1. 정형 명세 기법
   • 그림이나 수식으로 표현되는 것
     • 수학, 논리학 기반
       • 수학적이다!
     • 언어 종류 : Z
2. 비정형 명세 기법
   • 서술하듯이 글로 쓰는 것
     • 자연어, 그림중심
     • 약간 애매할 수 있다. (사용자-개발자 간 오해 있을수도)

산출물 (작성했으니까 당연히 나오는 것들)

• 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서

 

4. 확인

• 고객과 확인
  • 이해관계자들이 모여 명세를 검토한다.