1. 소프트웨어 설계

1. 네트워크 차트

이미지 출처 : https://www.youtube.com/watch?v=dFTG3ohAcso

PERT(Program Evaluation and Review Technique)

프로젝트 작업 상호관계를 네트워크로 표현
원 노드(작업)와 간선(화살표)로 구성(불확실한 상황)
간선에는 각 작업별 낙관치/기대치/비관치를 기재

CPM(Critical Path Method)

미국 Dupont 회사에서 화학공장 유지 관리 위해 개발
노드(작업) / 간선(작업 전후 의존관계) / 박스(이정표) 구성
간선(화살표)의 흐름에 따라 작업 진행(확실한 상황)

간트 차트

각 작업의 시작 / 종료 일정을 막대 바(Bar) 도표를 이용하여 표현
시간선(Time-line) 차트 (수평 막대 길이 = 작업 기간)
작업 경로는 표현 불가 / 계획 변화에 대한 적용성이 낮음

2. 객체지향

오버라이딩(Overriding) : 중복정의 - 메서드 이름/매개변수/반환타입은 동일 (예_계산기)
오버로딩(Overloading) : 재정의 - 메서드 이름/배개변수 개수/타입 다르게 지정 (예_레시피)

2.1 객체지향 분석 모델

Booch(부치) : 미시적, 거시적 개발 프로세스를 모두 사용 (클래스/객체 분석 및 식별)
Jacobson(제이콥슨) : Use Case를 사용 (사용자, 외부 시스템이 시스템과 상호 작용)
Coad-Yourdon : E-R 다이어그램 사용 / 객체의 행위 모델링
Wirfs-Brock : 분석과 설계 구분 없으며 고객 명세서 평가 후 설계 작업까지 연속 수행
Rumbaugh(럼바우) : 가장 일반적으로 사용, 객체/동적/기능 모델로 구분
- 객체 모델링(Object) → 객체 다이어그램 / 객체들 간의 관계 규정/정의
- 동적 모델링(Dynamic) → 상태 다이어그램 / 시스템 동적인 행위 기술
- 기능 모델링(Function) → 자료 흐름도(DFD) / 다수의 프로세스들 간의 처리 과정 표현

2.2 객체지향 설계 5대 원칙

단일 책임 원칙(SRP, Single Responsibility Principle)
→ 모든 클래스/객체는 하나의 책임만 / 완전한 캡슐화
개방 폐쇄의 원칙(OCP, Open Closed Principle)
→ 확장에는 Open하고, 수정에는 Close되어야 한다.
리스코프 교체 원칙(LSP, Liskov Substitution Principle)
→ 상위 클래스의 행동 규약을 하위 클래스가 위반하면 안 된다.
인터페이스 분리 원칙(ISP, Interface Segregation Principle)
→ 클라이언트가 비사용 메서드에 의존하지 않아야 한다.
의존성 역전 원칙(DIP, Dependency Inversion Principle)
→ 의존관계 수립 시 변화하기 어려운 것(추상성이 높은 상위 클래스)에 의존해야 한다.

3. 소프트웨어 설계

분할과 정복: 여러 개의 작은 서브시스템으로 나눠서 각각을 완성
모듈화(Modularity) : 시스템 기능을 모듈 단위로 분류하여 성능/재사용성 향상
- 모듈 크기 ▲ → 모듈 개수 ▼ → 모듈간 통합비용 ▼ (but, 모듈 당 개발 비용 ▲)
- 모듈 크기 ▼ → 모듈 개수 ▲ → 모듈간 통합비용 ▲
정보 은닉(Information Hiding) : 한 모듈 내부에 포함된 절차/자료 관련 정보가 숨겨져 다른 모듈의 접근/변경 불가
모듈을 독립적으로 수행할 수 있어 요구사항에 따라 수정/시험/유지보수가 용이함

4. 아키텍처 패턴

Layer
- 시스템을 계층으로 구분/구성하는 고전적 방식(OSI 참조 모델)
Client-server
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성
- 클라이언트와 서버는 요청/응답 제외 시 서로 독립적
- *컴포넌트(Component) : 독립적 업무/기능 수행 위한 실행코드 기반 모듈
Pipe-Filter
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 후 데이터 전송
- 재사용 및 확자 용이
- 필터 컴포넌트 재배치 가능
- 단방향으로 흐르며, 필터 이동시 오버헤드 발생
- 반환, 버퍼링, 동기화 작용(ex. UNIX 쉘 - Shell)
Model-View-Controller
- 모델(Model) : 서브시스템의 핵심 기능 및 데이터 보관
- 뷰(View) : 사용자에게 정보 표시
- 컨트롤러(Controller) : 사용자로부터 받은 입력 처리
  - 각 부분은 개별 컴포넌트로 분리되어 서로 영향X
  - 하나의 모델 대상 다수 뷰 생성 ▶ 대화형 애플리케이션에 적합
Master-slave
- 마스터에서 슬레이브 컴포넌트로 작업 분할/분리/배포
- 이후 슬레이브에서 처리된 결과물을 다시 돌려 받음 (병렬 컴퓨팅)
Broker
- 컴포넌트와 사용자를 연결 (분산 환경 시스템)
Peer-to-peer
- 피어를 한 컴포넌트로 산정 후 각 피어는 클라이언트가 될 수도, 서버가 될 수도 있음 (멀티스레딩)
Event-bus
- 소스가 특정 채널에 이벤트 메세지를 발행 시 해당 채널을 구독한 리스너들이 메세지를 받아 이벤트를 처리
Blackboard
- 컴포넌트들이 검색을 통해 블랙보드에서 원하는 데이터를 찾음
Interpreter
- 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계

참고 자료

https://buly.kr/4md4oFr

5. UML(Unified Modeling Language)

5.1 관계(Relationship)

이미지 출처 : https://kyoun.tistory.com/100

연관 관계(Associaton) :
- 2개 이상의 사물이 서로 관련
- 사람 - 컴퓨터
  (사람은 컴퓨터를 소유한다)
집합 관계(Aggregation) :
- 하나의 사물이 다른 사물에 포함 (전체-부분 관계)
- 컴퓨터 - 모니터
  (전체는 각각의 객체와 독립적 - 연결 고리가 약함)
  (키보드, 모니터, 프린터 : 각각의 객체는 다른 컴퓨터와 연결이 가능함)
포함 관계(Composition) :
- 집합 관계 내 한 사물의 변화가 다른 사물에게 영향
- 집 - 방
  (집이 사라지면 방도 존재하지 않음)
일반화 관계(Generalization) :
- 한 사물이 다른 사물에 비해 일반/구체적인지 표현 (한 클래스가 다른 클래스를 포함하는 상위 개념일 떄)
- 과일 ← 수박
  동물 ← 토끼
의존 관계(Dependency) :
- 사물 간 서로에게 영향을 주는 관계 (한 클래스가 다른 클래스의 기능을 사용할 때)
- A 클래스 → B 클래스
  (A에서 B의 메서드 호출 등)
- Printer 클래스가 Document 객체를 받아 출력하는 경우
- Printer ───────▶ Document
```
class Document {
    String content;
}

class Printer {
    void print(Document doc) {
        System.out.println(doc.content);
    }
}
```
실체화 관계(Realization) :
- 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정 / 서로를 그룹화 할 수 있는 관계
- 새 - 비행기
  (비행기는 날 수 있음, Flyable 인터페이스를 구현했기 때문)
  (새도 잘 수 있음, Flyable 인터페이스를 구현했기 때문)

참고 자료

https://growingsoksok.tistory.com/31
https://swk3169.tistory.com/171 아주 정리 잘 된 블로그 ★★★

5.2 다이어그램(Diagram)

행위 다이어그램과 구조 다이어그램으로 나뉜다.

구조, 정적 다이어그램

클래스(Class) 다이어그램

클래스 사이의 관계 및 속성 표현

객체 (Object) 다이어그램

인스턴스를 객체와 객체 사이의 관계로 표현

컴포넌트 (Component) 다이어그램

구현 모델인 컴포넌트 간의 관계 표현

배치 (Deployment) 다이어그램

물리적 요소[HW/SW]의 위치 / 구조 표현

복합체 구조 (Composite Structure) 다이어그램

클래스 및 컴포넌트의 복합체 내부 구조 표현

패키지 (Package) 다이어그램

UML의 다양한 모델요소를 그룹화하여 묶음

행위, 동적 다이어그램

유스케이스 (Use case) 다이어그램

사용자의 요구를 분석 (사용자 관점) → 사용자(Actor) + 사용 사례(Use Case)

시퀀스 (Sequence) 다이어그램

시스템 / 객체들이 주고 받는 메시지 표현
→ 구성 항목 : 액터* / 객체 / 생명성 / 메시지 / 제어 삼각형

커뮤니케이션 (Communication) 다이어그램

객체들이 주고받는 메시지와 객체 간의 연관관계까지 표현

상태 (State) 다이어그램

다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현
복잡한 시스템을 한 눈에 볼 수 있게 해준다

활동 (Activity) 다이어그램

객체의 처리 로직 및 조건에 따른 처리의 흐름을 순서에 따라 표현

상태 다이어그램 vs 활동 다이어그램

활동 다이어그램과 상태 다이어그램은 모두 시스템의 동작을 시각적으로 표현하는 UML 다이어그램이지만, 초점과 표현 방식에서 차이가 있다. 활동 다이어그램은 시스템 전체의 흐름이나 워크플로우를, 상태 다이어그램은 특정 객체의 상태 변화와 그에 따른 이벤트를 중심으로 표현한다.

타이밍 (Timing) 다이어그램