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) 다이어그램

객체 상태 변화와 시간 제약 명시적으로 표현

상호작용 개요 (Interaction Overview) 다이어그램

상호작용 다이어그램 간 제어 흐름 표현

참고 자료

https://buly.kr/1RE8qrr
https://seulhee030.tistory.com/56
https://buly.kr/DEZS8sb
https://buly.kr/6Xmes2v
https://buly.kr/3COGEfv
https://ko-de-dev-green.tistory.com/96 설명이 잘 된 블로그 ★★★
https://buly.kr/6MrttBc 실전에서는 이것만 쓴다 ★★★

6. 디자인 패턴 Gof(Gang of Four)

이미지 출처 : https://buly.kr/FWTIe1z

6.1 생성패턴

~~여기서부터~~Abstract Factory
• 관련 있는 나중객체들을 그룹 단위로 생성할 수 있는 인터페이스 제공
• 구체적인 클래스에 의존하지 않음
• 제품군 간 일관성 유지 가능
• 새로운 제품군 추가는 쉬우나, 기존 제품군 확장은 어려움

졸Builder
• 객체의 생성과 표현 방법을 분리하여 같은 생성 절차로 다양한 결과 생성
• 복잡한 객체 생성 과정을 단계별로 분리
• 객체 생성 로직을 클라맨이언트로부터 없숨김
• 제품의 구성 과정을 유연하게 조립 가능

Factory Method
• 객체 생성을 위한 인터페이스만 정의하고 실제 생성은 서브클래스에서 처리
• 인스턴스를 생성할 클래스를 서브클래스에 위임
• 클라이언트는 ~~그림으로~~구체적인 클래스 몰라도 사용 가능
• 객체 생성 코드의 중복을 줄일 수 있음

Prototype
• 기존에 존재하는 객체(원형)를 복제(clone)하여 새 객체를 생성
• 복잡한 초기화 과정을 피할 수 있음
• 런타임 시점에 클래스의 종류를 모를 때 유용
• 깊은 복사/얕은 복사 개념을 잘 이해해야 함

Singleton
• 시스템 전체에서 하나의 인스턴스만 존재하도록 보장
• 전역 접근점을 제공하며, 어디서든 동일한 인스턴스 사용
• 리소스 낭비를 줄이지만 동시성 제어 주의 필요
• 다중 스레드 환경에선 thread-safe 구현 필수

6.2 구조패턴

Adapter
• 서로 호환되지 않는 인터페이스를 연결해줌
• 클라이언트가 기대하는 인터페이스로 변환함
• 중간 변환기를 통해 기존 클래스를 재사용 가능
• 레거시 코드와의 통합 시 자주 사용됨

Bridge
• 구현부와 추상화를 분리하여 독립적으로 확장 가능
• 구현 객체를 추상 계층에 위임함으로써 의존성 분리
• 기능과 구현을 별도 계층으로 나눔
• 기능 변화와 구현 변화가 서로 영향 없이 가능함

Composite
• 객체를 트리 구조로 구성하여 부분과 전체를 동일하게 다룸
• 단일 객체와 복합 객체를 클라이언트가 구분 없이 사용 가능
• 재귀적 구조를 통해 복잡한 계층 표현
• GUI 구성 요소 등에 자주 사용됨

Decorator
• 상속 없이 객체 기능을 동적으로 확장함
• 원래 객체를 감싸는 래퍼(wrapper) 형태로 기능 추가
• 기존 코드 수정 없이 기능 변경 가능
• 조합을 통해 다양한 기능 확장이 가능함

Facade
• 복잡한 하위 시스템을 단순한 인터페이스로 감쌈
• 클라이언트는 복잡한 내부 구조를 몰라도 됨
• 서브시스템 간 의존성을 줄이고 일관된 접근 제공
• 시스템 진입 지점 역할을 함

Flyweight
• 동일한 객체를 공유해 메모리 사용을 줄임
• 공통 속성은 공유하고, 변하는 속성은 외부에서 관리
• 대량의 유사 객체가 필요한 경우 효과적
• 문자, 아이콘, UI 등에서 자주 사용됨

Proxy
• 실제 객체 대신 접근을 제어하는 대리 객체 제공
• 접근 제어, 로깅, 지연 로딩 등의 기능 수행
• 클라이언트는 실제 객체와 동일한 방식으로 사용함
• 보안, 원격 통신 등에서 활용됨

6.3 행위패턴

Chain of Responsibility
• 여러 객체가 처리 가능할 때, 한 객체가 처리 못 하면 다음 객체에 요청 전달하여 처리 분산

Command
• 요청을 명령어 클래스로 캡슐화
• 실행 시점과 요청자를 분리하여 유연성 제공

Interpreter
• 언어 문법 규칙을 클래스로 표현
• 문장 해석 및 실행 가능하게 하는 패턴

Iterator
• 컬렉션 내부 구조와 상관없이 순차적으로 요소에 접근 가능
• 동일한 인터페이스 제공

Mediator
• 객체 간 복잡한 상호작용을 중재자 객체가 캡슐화
• 객체 간 결합도 낮추고 협력 관리

Memento
• 객체 상태를 캡슐화하여 저장
• 필요 시 복원 가능, 상태 변경 이전으로 되돌릴 수 있음

Observer
• 한 객체 상태 변화 시 여러 종속 객체에 자동 통보
• 상태 동기화 유지

State
• 객체 상태에 따라 행동 분리
• 상태별로 다르게 동작, 상태 변화에 따른 유연한 처리 지원

Strategy
• 알고리즘 군을 캡슐화하여 상호 교체 가능
• 클라이언트가 알고리즘을 독립적으로 선택 가능

Template Method
• 상위 클래스에 공통 알고리즘 골격 정의
• 세부 구현은 하위 클래스에 맡겨 코드 중복 줄임

Visitor
• 연산 기능을 객체 구조와 분리
• 새로운 기능 추가 시 구조 변경 없이 방문자 클래스로 작업 수행

7. 소프트웨어 테스트

7.1 프로그램 실행 여부

정적 테스트 :

프로그램 실행 X
명세서, 소스 코드만 분석
ex) 동료 검토, 워크 스루, 인스펙션, 코드 검사

동적 테스트 :

프로그램 실행 후 오류 검사
ex) 화이트/블랙박스 테스트

7.2 테스트 기반 테스트

명세 기반 :

사용자의 요구사항에 대한 명세를 빠짐 없이 테스트 켕리스로 구현하는 지 확인
ex) 동등 분할, 경계값 분석(블랙박스)

구조 기반 :

SW 내부 논리 흐름에 따라 테스트 케이스 작성/확인
ex) 구문 기반, 결정 기반, 조건 기반(화이트박스)

경험 기반 :

테스터의 경험을 기반으로 수행
ex) 에러 추정, 체크리스트, 탐색적 테스팅

7.3 목적 기반 테스트

회복(Recovery) : 시스템에 인위적 결함 부여 후 정상으로 회복되는 과정 확인
안전(Security) : 외부 불법 침입으로부터 시스템을 보호할 수 있는 지 확인
강도(Stress) : 과부하 시 SW 정상 구동 여부 확인
성능(Performance) : 실시간 성능 및 전체적인 효율성 진단 (응답 시간, 업무 처리량)
구조 (Structure) : SW 내부 논리적 경로 및 소스 코드 복잡도 평가
회귀(Regression) : SW 내 변경 똔느 수정된 코드에 새로운 결함이 없음을 확인
병행(Parallel) : 변경 및 기존 SW에 동일한 데이터 입력 후 결과 비교

7.4 시각(관점) 기반 테스트

검증(Verification) :

개발자의 시각에서 제품의 생산 과정 테스트
예) 단위/통합/시스템 테스트

확인(Validation)

사용자의 시각에서 생산된 제품의 결과 테스트
예) 인수 테스트(알파/베타)

7.5 화이트박스 / 블랙박스 테스트

나중에

8. 소프트웨어 생명 주기

아이고 힘들다

9. 소프트웨어 유지 보수

9.1 버전 관리 도구

공유 폴더 방식

파일을 공유 폴더에 복사하는 형태로, 여러 사용자가 같은 폴더에 접근해 파일을 관리한다.
RCS, SCCS, PVCS, QVCS 등

클라이언트/서버 방식

서버에서 버전을 일괄 관리하며, 클라이언트가 서버에 접속해 작업하는 구조이다.
중앙 서버가 버전 관리를 담당하기 때문에 일관된 관리가 가능하다.
CVS, SVN, CVSNT, CMBC 등.

분산 저장소 방식

원격 저장소에서 코드를 가져와 지역 저장소에 저장하고 관리하는 방식이다.
각 사용자는 로컬 저장소에서 독립적으로 작업하고 변경 사항을 원격 저장소와 동기화한다.
Git, GNU arch, DCVS, Bitkeeper, Bazaar 등

9.2 형상 관리 도구

CVS (Concurrent Versions System)

CVS는 초기 오픈소스 프로젝트에서 많이 사용되던 중앙집중형 형상관리도구이다. 각 파일의 변경 이력을 기록하고, 여러 개발자가 동시에 작업할 수 있도록 지원하지만, 병합 기능이 부족하고 속도도 느린 편이다. 현재는 기술적으로 뒤처져 거의 사용되지 않고 있다.

~~9.3~~SVN ~~CMMI~~(Subversion)

SVN은 CVS의 단점을 보완해 나온 중앙집중형 도구로, 전체 디렉토리 단위의 변경을 관리하고 파일뿐 아니라 폴더 구조도 추적할 수 있다. 오프라인 작업에는 제약이 있지만, 비교적 직관적이고 안정적인 관리가 가능해 기업 환경에서 여전히 일부 사용되고 있다.

Git

서버(원격) 저장소와 개발자(지역) 저장소가 독립적 → 커밋 실수 발생해도 서버에 영향 없음 (분산된 P2P 모델)

10. 응집도와 결합도

응집도: 모듈 내부의 관련성 (높을수록 좋음)
결합도: 모듈 간의 의존성 (낮을수록 좋음)

10.1 응집도(Cohesion)

개별 모듈이 독립적인 기능으로 정의되어 있는 정도이다. 응집도가 높을 수록 소프트웨어의 품질이 높다.

응집도 수준	유형	설명
낮음	우연적(Coincidental)	관련 없는 작업들이 하나의 모듈에 우연히 모여 있음. 최악의 응집도
	논리적(Logical)	비슷한 종류의 기능들을 하나의 모듈에 묶되, 제어 변수로 구분하여 수행함
	시간적(Temporal)	동시에 수행되는 작업들을 하나로 묶음 (예: 초기화 루틴)
	절차적(Procedural)	특정 순서에 따라 수행되어야 하는 작업들을 모듈에 묶음
	통신적(Communicational)	동일한 데이터(입력/출력)를 사용하는 기능들을 하나로 묶음
	순차적(Sequential)	한 작업의 출력이 다음 작업의 입력으로 사용됨. 기능들이 순차적으로 연결됨
높음	기능적(Functional)	모든 기능이 단일 목적 을 위해 긴밀하게 연관되어 있음. 가장 바람직한 응집도

10.2 결합도(Coupling)

모듈 간 상호 의존성의 정도 결합도가 낮을수록 독립적인 모듈로 유지보수가 쉽고, 재사용성이 높다.

결합도 수준	유형	설명
높음	내용 결합(Content)	한 모듈이 다른 모듈의 내부 동작이나 자료에 직접 접근. 최악의 결합도.
	공통 결합(Common)	여러 모듈이 전역 변수 등 공통 자료 공간을 공유함.
	외부 결합(External)	모듈이 외부 데이터 포맷이나 장치와 의존 관계를 가짐 (ex. 파일 포맷).
	제어 결합(Control)	한 모듈이 다른 모듈의 수행 흐름을 제어하기 위해 플래그나 제어값 전달함.
	스탬프 결합(Stamp)	필요한 데이터만 주는 것이 아닌, 전체 자료구조 를 전달함.
낮음	자료 결합(Data)	필요한 데이터만 전달 하며 모듈 간 최소한의 정보만 공유. 가장 바람직한 결합도.