1. 소프트웨어 설계의 기본원칙

1. 소프트웨어 설계

1. 소프트웨어 설계의 개념

요구사항 명세서 참조 -> 소프트웨어 설계서 작성
Story Board(파워포인트), Wireframe(기획자랑 디자이너)

2. 설계의 종류

상위 설계:
- 아키텍서 설계: 전체적인 구조 설계
- 데이터 설계: 데이터베이스 설계
- 인터페이스 정의:
- 사용자 인터페이스 설계: 사용자 화면 설계(UI/UX)
하위 설계:
- 모듈 설계
- 자료구조 설계
- 알고리즘 설계

3. 설계의 원리

분할과 정복(Divide & Conquer)
추상화(Abstraction)
- 과정 추상화: 흐름만 먼저 설계
- 데이터 추상화: 데이터 구조
- 제어 추상화: 여러 명령어를 간단한 표현으로 대체
단계적 분해(Gradual Decomposition)
모듈화(Modulization)
정보 은닉(Information Hiding)
- 캡슐화와 밀접한 관계

2. 설계 모델링

1. 개념

소프트웨어를 구성하는 모듈들을 식별하고, 연결을 그림으로 표현한 것
보기 쉬운 그림과 설명으로 문서화

2. 원칙

변경이 용이하도록 구조화시켜야 한다
필요한 자료만을 사용
요구사항 분석에 얻은 정보를 이용하여 명확히 표현
모듈 단위로 설계

3. 유형

구조 모델링(정적 모델링)
- 구조적 관계와 특성 위주
- UML 정적 다이어그램
행위 모델링(동적 모델링)
- 어떤 순서로 기능 수행하는지 위주
- 유즈케이스 다이어그램, 액티비티 다이어그램, 상태 다이어그램

4. 소프트웨어 설계 절차 및 유형

아키텍처 설계: 전체적인 구조
데이터베이스 설계
서브시스템 설계
컴포넌트 설계
자료구조와 알고리즘 설계
협약의 의한 설계
- 클래스에 대한 여러 가정을 공유하도록 명세
- 선행 조건: 사용전에 이루어져야할 조건
- 결과 조건: 사용 후 만족되어야할 조건
- 불변 조건: 항상 만족되어야할 조건

2. 소프트웨어 아키텍처

1. 소프트웨어 아키텍처

1. 소프트웨어 아키텍처 개념:

소프투웨어의 골격이 되는 기본 구조

2. 소프트웨어 아키텍처 특징:

간략성
추상화
가시성
관점 모형
의사소통수단

3. 소프트웨어 아키텍처 프레임워크 구성요소

아키텍처 명세서(Architecture Description)
이해관계자(Stakeholder)
관심사(Concerns)
관점(Viewpoint)
뷰(View)

4. 소프트웨어 아키텍처 4+1 뷰

4개의 관점에서 바라보는 고객의 요구사항

출처: https://www.jasonchoi.dev/posts/sw-engineering/6

관점	설명	다이어그램
유스케이스 뷰 (Usecase View)	- 다른 뷰를 검증하는데 사용 - 사용자, 설계자, 개발자, 테스트 관점	유스케이스 다이어그램
논리 뷰 (Logical View)	- 시스템 기능 적인 요구사항이 어떻게 제공되는지 - 클래스나 컴포넌트의 종류와 관계를 설명하고 설계가 실제로 구현 되는지 설명 - 설계자 관점 (순서도나 UML 그리는 시점)	클래스/시퀀스 다이어그램
프로세스 뷰 (Process View)	- 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 성능, 확장성, 효율성 관련 - 시스템 통합자의 관점	시퀀스/협력 다이어그램
구현 뷰 (Implementation View)	- 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰 - 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의 - 실제 구현할 수 있는지 여부를 확인 - 직접 만드는 개발자의 관점	컴포넌트 다이어그램
배포 뷰 (Deployment View)	- 컴포넌트가 물리적 환경에서 배치 연결 작업이 어떻게 실행 되는지를 매핑해서 보여주는 뷰	배치(배포) 다이어그램

5. 소프트웨어 아키텍처 품질속성

정확성(Correctness)
신뢰성(Reliability)
효율성(Efficiency)
무결성(Integrity)
사용 용이성(Usability)
유지보수성(Maintainability)
시험 용이성(Testability)
유연성(Flexibility)
이식성(Potability)
재사용성(Reusability)
상호 운용성(Interoperability)

2. 소프트웨어 아키텍처 패턴

1. 소프트웨어 아키텍처 패턴의 개념

공통적인 발생 문제에 대한 재사용 가능한 해결책
- 컴퓨터 하드웨어 성능
- 고가용성

2. 소프트웨어 아키텍처 패턴 종류

1. 계층화 패턴(Layered Pattern)

N-티어 아키텍처 패턴으로 부른다
ex) OSI 7계층, TCP/IP 4계층

2. 클라이언트-서버 패턴(Client-Server Pattern)

다수의 클라이언트와 하나의 서버로 구성
ex) 웹 프로그램, N-잡

3. 마스터-슬레이브 패턴(Master-Slave Pattern)

클라이언트-서버 패턴과 비슷한 형태: 한개의 마스터, 여러개의 슬레이브
다른점: 각 클라이언트가 능동적이지 못함, 입력-출력만 함
ex) 컴퓨터와 주변장치

4. 파이프-필터 패턴(Pipe-Filter Pattern)

데이터 스트림을 생성하고 처리하는 시스템에서 사용
데이터가 파이프로 들어가면 각종 필터들이 필요한 작업을 한 뒤 내보내는 형태
ex) Unix 쉘처리

5. 브로커 패턴(Broker Pattern)

분리된 컴포넌트로 구성된 분산 시스템에서 사용
분리된 컴포넌트간의 통신을 브로커가 조절

6. 피어 투 피어 패턴(Peer to Peer Pattern)

피어간 서비스를 주고 받는 패턴
피어 객체 하나가 클라이언트, 서버의 역할을 모두 수행하는 구조
ex) 파일 공유(P2P), 토렌트

7. 이벤트-버스 패턴(Event-Bus Pattern)

특정 채널로 메시지를 발행
ex) 알림 서비스, 단체카톡

8. 모델-뷰-컨트롤러 패턴(MVC Pattern, Model-View-Controller Pattern)

Model: 도메인의 기능과 자료를 저장하고 보관
View: 사용자에게 결과를 표시
Controller: 사용자로부터 입력을 받아 연산을 처리
ex) 일반적인 웹 애플리케이션 설치 아키텍쳐

9. 블랙보드 패턴(Blackboard Pattern)

명확히 정의된 해결 전략이 알려지지 않은 문제에 대해서 유용한 패턴

10. 인터프리터 패턴(Interpreter Pattern)

특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용되는 패턴

3. UML(Unified Model Language)

1. UML

1. UML 개념

프로그램 설계를 위해 표준화된 모델링 언어
이 언어를 사용하여 산출물을 규정하고 시각화, 문서화 한다

2. UML 특징

가시화 언어
명세화 언어
구축 언어
문서화 언어

2. UML 구성 요소

1. 사물(Things)

구조사물:
- 개념적, 물리적 요소
- ex) 클래스, 유스케이스, 컴포넌트
행동사물:
- 시간과 공간에 따른 요소들의 행위
- ex) 상호작용, 상태머신
그룹사물:
- 요소들을 그룹으로 묶은 것
- ex) 패키지
주해사물
- 부가적 설명이나 제약조건
- ex) 주석, 노트

2. 관계(Relationship)

일반화 관계(Generalization):
- 한 클래스가 다른 클래스를 포함하는 상위개념(객체지향 개념에서의 상속관계(Inheritance))
연관관계(Association):
- 2개 이상 사물이 서로 관련된 관계 (오래)
- ex) 사람->휴대폰
의존관계(Dependency)
- 연관관계와 비슷하지만 관계가 잠시 유지되는 경우(매우 짧은 시간)
- ex) 학생->색연필
실체화 관계(Realization)
- 인터페이스를 구현받아 추상 메서드를 오버라이딩 하는 것
- 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정
- ex) 리모컨과 티비리모콘, 에어컨리모콘 (각 버튼을 티비, 에어컨 객체에서 오퍼레이션 수행한다)
집햡 관계 - 집약관계(Aggregation)
- 한 객체가 다른 객체를 소류하는 ‘has a’ 관계
- 각 객체가 독립적
집합관계 - 합성관계(Composition)
- 부분객체가 전체 객체에 속하는 관계인것으로 집약관계와 같지만 긴밀한 필수적 관계
- 전체가 없어지면 부분 객체도 없어짐, 반대로도 적용

3. 다이어그램(Diagram)

1. 구조 다이어그램(정적)

다이어그램	설명
클래스 다이어그램	- 클래스의 속성과 클래스 사이의 관계를 표시 - 구조 파악 및 구조상 문제점을 도출
객체 다이어그램	- 클래스에 속한 객체(인스턴스)를 특정 시점의 객체와 객체 사이 관계로 표현
컴포넌트 다이어그램	- 컴포넌트 사이 관계나 인터페이스를 표현
배치 다이어그램	- 물리적 요소들의 위치, 노드와 통신 경로 표현
복합체 다이어그램	- 클래스나 컴포넌트가 복합구조를 가질 시 내부를 표현
패키지 다이어그램	- 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

2. 행위 다이어그램(동적)

다이어그램	설명
유스케이스 다이어그램	- 유저의 요구를 분석하며 기능 모델링 작업에 사용 - 구성요소: Actor, Use Case, System
시퀀스 다이어그램	- 시스템 시나리오, 행동이 어떤 순서로 어떤 객체와 상호작용하는지 표현 - 구성요소: 활성객체, 메시지, 생명선, 제어 사각형 - 메세지요형: 동기메세지, 비동기 메세지, 반환 메세지, 자체 메세지
커뮤니케이션 다이어그램	- 객체들이 주고받는 메세지, 객체간 연관 표현
상태 다이어그램	- 객체간 상호작용에 따라 상태변환 표화
활동 다이어그램	- 시스템 수행 기능을 객체 처리 로직이나 조건에 따른 처리 순서에 따라 표현
상호작용 다이어그램	- 상호작용 간 제어 흐름 표현
타이밍 다이어그램	- 객체 상태 변화와 시간 제약 명시적 표현

3. 주요 다이어그램

1. 클래스 다이어그램

클래스 다이어그램 개념

자기만의 속성(attribute)과 일정한 행동(behavior)으로 구성
여러 클래스들을 서로 연관이나 상속, 의존 관계 등으로 서로간의 상초작용을 표현

2. 유스케이스 다이어그램

유스케이스 다이어그램 개념:

시스템과 사용자의 상호작용을 다이어그램으로 표현
사용자 관점
프로젝트에 대한 요구사항을 정의하고 세부기능을 분석

유스케이스 다이어그램 구성요소:

시스템(System): 만들고자 하는 프로그램 명칭
액터(Actor)
유스케이스(Usecase): 사용자 입장에서 본 시스템 기능
관계(Relationship)

유스케이스 다이어그램 관계:

연관관계(Association): 실선
포함 관계(Include): 반드시 실행되어야 하는 경우. <<Include»로 표현
확장 관계(Extend): 조건에 따라. <<extend»
일반화 관계(Generalization)

3. 시퀀스 다이어그램

시퀀스 다이어그램 개념:

객체간의 상호작용 메시지 시퀀스를 시간의 흐름에 따라 나타내는 다이어그램

시퀀스 다이어그램 구성요소:

개체(Object)와 생명선(Lifeline)
활성 박스(Activiation Box)
메세지(Message)
- 동기 메세지: 요청 후 반환까지 대기
- 비동기 메세지: 요청 후 바로 다음 작업 수행
- 자체 메세지: 자기 자신에게 메세지 보냄
- 반환 메세지: 요청에 대해 메세지를 반환

4. 상태 다이어그램

상태 다이어그램 개념:

한 객체의 상태 변화를 나타내는 다이어그램

출처: https://gitmind.com/kr/state-diagram.html

상태 다이어그램 구성 요소:

초기 상태 – 이름에서 알 수 있듯이, 이 상태는 객체가 프로세스의 시작점에 있는 첫 번째 상태입니다. 이 요소의 기호는 실선 원입니다..
상태 – 다음으로 포함해야 하는 구성 요소는 “상태”입니다. 모든 프로세스에서 관련된 개체는 한 지점에서 상태 또는 단계로 들어갑니다. 상태는 모서리가 둥근 직사각형 상자로 표시됩니다.
전환 – 이 요소는 한 상태에서 다른 상태로의 전환을 나타냅니다. 이는 상태 차트 다이어그램 내의 화살표로 표시됩니다.
이벤트 – 다이어그램에서 프로세스 중에 전환이 발생할 수 있는 모든 것을 의미합니다.
신호 – 상태로 전환하는 동안 발생하는 모든 메시지 또는 신호를 신호라고 합니다.
최종 상태 – 초기 상태와 완전히 반대입니다. 최종 상태는 개체에서 예상되는 결과를 나타냅니다. 반실선 원형 또는 중심 기호로 나타낼 수 있습니다.

[정보처리기사]1과목 소프트웨어 구축-3.소프트웨어 설계