[정보처리기사] 2022년 1회차 (1)소프트웨어 설계

정보처리기사

개발 과정

1. 계획
2. 분석 및 설계
   • 요구사항 분석 절차
     : 도출 → 분석 → 명세 → 확인
3. 구현
4. Test
5. 유지 및 보수

 

통합(Integration) 테스트

: 단위 테스트를 통과한 컴포넌트 간의 인터페이스를 테스트

• 상향식 테스트
  • 하위 모듈에서 상위 모듈로의 테스트를 진행
  • 가상의 서버, 드라이버(Driver) 사용
• 하향식 테스트
  • 상위 모듈에서 하위 모듈로의 테스트를 진행
  • 깊이 우선 통합법, 넓이 우선 통합법 사용
  • 가상의 클라이언트, 스텁(Stub) 사용

 

자료 흐름도(Data Flow Diagram)

: 프로세스와 프로세스 간에 존재하는 상호작용을 명확하게 표현

자료 사전(Data Dictionary)

: 데이터 흐름도(Data Flow Diagram)에 기술된 자료들에 대해 정의

단위 명세서(Mini Specification)

: 프로세스 명세서, 자료 흐름도를 보완 설명하기 위해 작성

 

UML(Unified Modeling Language)

: 표준화된 모델링(개발하기 위한 그림을 그려주는) 언어

• 종류

  구조적(정적) 다이어그램
  - 객체: 객체 정보
  - 클래스: 클래스의 속성, 함수, 변수 타입으로 구성
  - 패키지: 클래스 다이어그램의 집합
  - 컴포넌트: 컴포넌트끼리의 구조 관계를 표현
  - 배치(Deployment): SW, HW 등을 포함한 시스템의 물리적 구조를 나타냄

  행위적(동적) 다이어그램
  - 유스케이스: 사용자 관점에서 바라본 시스템을 표현
      - 구성요소(Component): System, Actor, Usecase, Relation
          - system: 만들고자 하는 프로그램
          - Actor: 시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템)
          - Usecase: 사용자 입장에서 바라본 시스템의 기능
          - Relation: 액터와 유스케이스 사이의 의미있는 관계
              - 연관: 유스케이스와 액터간의 상호작용이 있음
              - 확장: "글을 등록한다" 기능을 수행 할 때 "파일을 첨부한다" 기능을 선택적으로 수행 할 수 있다는 것
              - 포함: "글을 등록한다" 기능을 동작하기 위해서 "로그인 한다" 기능이 반드시 동작되어야 한다는 것
              - 일반화: 그룹을 만들어 이해도를 높이기 위한 관계,  "글을 검색한다"를 "글쓴이로 검색한다"와 "날짜로 검색한다"로 좀더 구체화 한 것
  - 활동: 시스템 전체의 흐름
  - 상태: 하나의 객체에서 발생하는 활동 변화
  - 순차: 시간의 흐름에 따른 객체 사이의 상호 작용
  - 커뮤니케이션
  - 인터렉션 오버뷰
  - 타이밍

 

UI 설계 원칙

1. 직관성: 누구나 쉽게 이해하고 사용할 수 있어야 함
2. 유효성: 사용자의 목적을 정확히 달성해야 함
3. 학습성: 누구나 쉽게 배울 수 있어야 함
4. 유연성: 사용자의 요구사항을 최대한 수용해야 함

UI 설계 도구

1. 와이어프레임 (WireFrame): 기획 단계의 초기에 제작하는 것으로, 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계
2. 목업 (Mockup): 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형
3. 스토리보드 (Story Board): 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
4. 프로토타입 (Prototype): 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
5. 유스케이스 (Use Case): 사용자 측면에서의 요구사항

 

애자일 방법론

: 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행

- eXtreme Programming: 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
    - 5가지 핵심 가치: 의사소통, 피드백, 존중, 용기, 단순성
    - 12가지 기본 원리
        - 짝 프로그래밍 Pair programming
        - 공동 코드 소유 Collective Ownership: 시스템에 있는 코드는 누구든지 언제라도 수정 가능
        - 지속적인 통합 Continuous Integration(CI): 매일 여러 번씩 소프트웨어를 통합하고 빌드
        - 계획 세우기 Planning Process
        - 작은 릴리즈 Small Release: 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트
        - 메타포어 Metaphor: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 함
        - 간단한 디자인 Simple Design: 현재의 요구사항에 적합한 가장 단순한 시스템을 설계
        - 테스트 기반 개발 Test Driven Development(TDD): 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 코드를 작성
        - 리팩토링 Refactoring: 프로그램의 기능을 바꾸지 않으면서 중복 제거, 단순화 등을 위해 시스템을 재구성
        - 40시간 작업 40-Hour Work
        - 고객 상주 On Site Customer
        - 코드 표준 Coding Standard
- Scrum
    - 짧은 단위시간(Sprint) 내 실행가능한 SW 개발
    - 매일 15분 정도의 Scrum meeting 회의
- FDD(Feature-Driven Development): 기능주도 개발
- 크리스탈(Crystal)
- LEAN: 낭비 요소를 제거하여 품질을 향상

 

객체지향 분석의 방법론

1. Rumbaugh: 가장 일반적으로 사용되는 방법으로 분석 활동을 객체, 동적, 기능 모델로 나누어 수행
   • 객체 모델링(Object Modeling): 클래스 다이어그램을 이용하여 시스템에서 요구되는 객체을 표현한 것
   • 동적 모델링(Dynamic Modeling): 상태도를 이용하여 시간의 흐름에 따른 객체들 사이의 동적인 행위를 표현한 것
   • 기능 모델링(Functional Modeling): 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 것
2. Booch: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용
3. Jacobson: UseCase를 강조하여 사용
4. Coad와 Yourdon: E-R다이어그램을 사용
5. Wirfs-Brock: 분석과 설계간의 구분이 없음

 

객체지향 설계원칙, SOLID

1. 단일 책임 원칙 (Single Responsibility Principle)
   : 모든 클래스는 각각 하나의 책임만 가져야 함
2. 개방-폐쇄 원칙 (Open Closed Principle)
   : 확장에는 열려있고 수정에는 닫혀있어야 함
3. 리스코프 치환 원칙 (Liskov Substitution Principle)
   : 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있음
4. 인터페이스 분리 원칙 (Interface Segregation Principle)
   : 자신이 사용하지않는 인터페이스는 구현하지 말아야 함
5. 의존 역전 원칙 (Dependency Inversion Principle)
   변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존해야 함

 

객체지향 프로그래밍(OOP: Object-Oriented Programming) 구성요소

• 클래스(Class): 같은 종류(또는 문제 해결을 위한)의 집단에 속하는 속성(변수)과 행위(메소드)를 정의한 것
• 객체(Object): 클래스라는 일종의 설계도를 기반으로 실제로 생성된 그 실체가 바로 객체
• 메서드(Method): 객체에 명령을 내리는 행위
• 메시지(Message): 객체간의 통신이 이루어지는 방법, 메시지를 통해 메소드가 호출되어 사용

 

GoF(Gang of Four) 디자인 패턴

: SW 설계에서 자주 발생하는 문제에 대해 일반적이고 반복적인 해결 방법

생성 패턴(Creational Patterns) 5 : 객체 생성에 대한 패턴

종류	설명
Abstract Factory	구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공
Builder	생성 절차는 동일하지만 결과는 다르게 만듦
Factory Method	객체를 생성할 때 필요한 인터페이스 생성
Propotype	원본 객체를 복사하여 새 객체를 생성
SingleTon	오직 하나의 객체만들 생성

구조 패턴(Structural Patterns) 5 : 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

종류	설명
Adapter	클래스의 재사용성을 높이기 위해 클래스간의 기능을 변환 제공하여 호환성을 확보
Bridge	기능 클래스 계층과 구현 클래스 계층을 분리
Composite	복잡한 객체구조를 표현하여 객체집합 속에 또 다른 객체집합을 갖음
Decorator	새로운 기능이 추가될 때마다 새로운 객체를 만들고, 이전 객체의 기능은 새로운 객체내에서도 그대로 유지, 보장
Facade(퍼싸드)	서브시스템이 복잡할 경우 간단한 인터페이스를 통해 서브시스템의 주요기능을 사용할 수 있도록 함
Fly weight	인스턴스를 가능한 한 공유시켜 불필요한 생성을 하지않도록 함
Proxy	객체접근을 제어

행위 패턴(Behavioral Patterns) 11 : 반복적으로 사용되는 객체들의 상호작용을 패턴화

 

 

 

참고 자료

흥달쌤

스텁(stub)? 드라이버(driver)?

자료 흐름도(Data Flow Diagram) – 언제나 휴일

[정보처리기사] 데이터 흐름도 - DFD(Data Flow Diagram)의 개념, 구성요소

1과목. 소프트웨어 설계 - 1장 화면 설계 [011. UI 표준 및 지침 / 012. UI 설계 도구]

(UML) 유스케이스 다이어그램 - Usecase Diagram

SOLID 원칙

럼바우의 분석 기법 모델링

객체지향 프로그래밍의 개념과 특징, 그리고 설계원칙