1과목. 소프트웨어 설계 - 애플리케이션 설계

---

공통 모듈 설계

---

✅설계 모델링

◾ 공통 모듈 [★★★☆☆]
여러 프로그램에서 공통으로 사용할 수 있는 모듈을 의미한다.

유의사항

• 복잡도와 중복성을 줄이고 일관성을 유지한다.
• 재사용성 확보와 중복 개발 회피를 위해 명세서를 작성해야 한다.
• 예측 가능해야 하며 이해가 쉬워야 한다.
• 유지보수가 간편해야 한다.
• 모듈 간 결합도를 약하게 하면, 모듈의 독립성이 증가한다.

공통 모듈 작성 원칙
정확성(Correctness), 명확성(Clarity), 완전성(Completeness), 일관성(Consistency), 추적성(Traceability)

재사용(Reuse)
이미 개발된 기능을 활용해 비용과 개발 시간을 절약하는 방법이다. 재사용을 위해서는 외부 모듈과 결합도는 낮고, 응집도는 높아야 한다. 즉 독립성이 높아야 한다.

공통 모듈의 재사용 범위에 따른 분류

함수와 객체: Class나 Method 단위의 Source Code를 재사용한다.
Component: 컴포넌트에 대한 수정 없이 인터페이스를 통해 통신하며 재사용한다.
Application: 애플리케이션을 공유하며 재사용한다.

◾ Code
자료를 분류하고 추출하기 쉽도록 사용하는 기호이다.

구분	설명
순차 코드 (Sequence Code)	일정한 기준에 따라 순서대로 일련번호를 부여한 코드 예) 가나다순으로 1번, 2번, ...
표의 숫자 코드 (Significant Digit Code)	도서 분류식 코드, 대상 자료의 물리적인 수치인 길이, 넓이, 용량 등을 표시한 코드 예) 20-10-300 (길이-넓이-용량 조합)
블록 코드 (Block Code)	공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 코드 예) 전화번호 (지역번호-국번-일련번호 조합에서 지역번호-국번은 같은 지역끼리 공통)
그룹 분류 코드 (Group Classification Code)	대상을 기준에 따라 대분류, 중분류, 소분류로 구분하여 번호를 부여한 코드 예) 학번 (입학년도-일련번호 조합)
10진 코드 (Decimal Code)	10진수 형태로 표현한 코드 예) 상품 바코드
연상 코드 (Mnemonic Code)	코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호(간단하고 알기 쉽게 나타내어 만든 부호) 형태로 넣어 구성된 코드 예) 나라 이름 (한국: KR, 미국: US, ...)
합성 코드 (Conbineed Code)	2개 이상의 코드를 조합한 코드 예) 대한항공 711기(KE-711)

특징

• 일정한 규칙에 따라 작성된다.
• 주요 기능: 식별, 분류, 배열, 표준화, 간소화

◾ Fan-In & Fan-Out
모듈을 계측적으로 분석하기 위해 사용하는 것으로, 시스템의 복잡도를 알 수 있다. 시스템 복잡도를 최적화하기 위해서는 Fan-In은 높고 Fan-Out은 낮은 것이 이상적이다.

Fan-In: 제어를 받는 상위 모듈의 수
Fan-Out: 제어를 하는 하위 모듈의 수

특징

• Fan-In이 높으면 재사용 측면에서 설계가 잘 되어 있는 것이다. 반면, 단일 장애점(한 요소가 동작하지 않으면 전체 시스템이 다운되는 지점)이 발생할 수 있다.
• Fan-Out이 높으면 불필요하게 다른 모듈을 호출하고 있을 수 있다. 따라서 단순화 시킬 수 있는지 검토해야 한다.

◾ N-S Chart(Nassi-Schneiderman)
연속, 선택, 반복 등의 제어 논리 구조를 표현하는 차트로, 박스다이어그램, Chapin Chart라고도 한다.

특징

• 논리적 기술에 중점을 둔 도형식 표현 방법이다.
• GOTO나 화살표를 사용하지 않는다.
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합하다.
• 이해하기 쉽고, 코드 변환이 용이하나, 작성하기 어렵다.

✅소프트웨어 아키텍처 (Software Architecture)

소프트웨어 개발 원칙 또는 지침을 의미한다.

◾소프트웨어 아키텍처 설계 원리

• 모듈화(Modularity)
  수정 및 재사용, 유지관리이 편하도록 시스템의 기능을 모듈 단위로 나눈다.
• 추상화(Abstraction)
  시스템에서 중요한 부분을 추출한다,

  추상화 유형

  • 제어 추상화
  • 과정 추상화
  • 자료(Data) 추상화

• 단계적 분해(Stepwise Refinement)
  Niklaus Wirth가 제안한 하향식 설계 전략으로, 추상화를 반복하며 개념을 구체화한다.
• 정보 은닉(Infomation Hiding)
  타 모듈이 접근하거나 변경하지 못하도록 제한한다. 각 모듈은 독립적이며, 하나의 모듈 변경이 다른 모듈에 영향을 미치지 않기 때문에 수정 및 유지보수가 용이하다.

소프트웨어 아키텍처 품질 속성(평가)

• 시스템
  성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성, 테스트 용이성, 안정성

• 비즈니스
  시장 적시성, 비용 및 혜택, 시스템 수명

• 아키텍처
  개념적 무결성, 정확성, 완결성, 구축 가능성, 대체성, 일치성, 변경성

시스템 타입

• 대화형 시스템: 사용자 요구 발생 시 처리
• 이벤트 중심 시스템: 외부 상태 변화에 따라 동작
• 변환형 시스템: 데이터 입력 시 동작
• 객체 영속성 시스템: 데이터베이스 사용

협약(Contract)에 의한 설계
컴포넌트 설계 시 가정을 명세한 것으로 선행조건(Precondition), 결과조건(Postcondition), 불변조건(Invariant)가 있다.

◾소프트웨어 아키텍처 패턴(Software Architecture Pattern)
소프트웨어 아키텍처를 설계하는 표준화된 방법이다.

• 장점: 개발시간 단축, 안정적, 간편한 유지보수

종류 참고자료

1. Pipe-Filter Pattern
   데이터 스트림을 처리하는 패턴으로, 배관을 통해 정수 과정을 거치 듯 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 파이프를 통해 다음 서브 시스템으로 넘겨주는 과정을 반복한다.
   

   특징
   - 필터 간 이동 시 Overhead가 발생한다.
   - 추가하기 편하기 때문에 재사용성이 좋고, 확장이 용이하다.

2. 계층화 패턴(Layer Pattern)
   상위 계층과 하위 계층으로 구성된 수직적인 패턴으로, 마주보고 있는 두 계층 사이에서만 상호작용이 발생한다.
   예) OSI(Open System Interconnection) 모델
   

특징
- 하나의 레이어만 교체해 성능을 개선할 수 있다.

3. Client-server pattern
   하나의 서버와 다수의 클라이언트로 구성된 패턴으로, 상호 독립적이며, 서버는 항상 대기 상태를 유지해야 한다.
   

4. Model-View-Controller Pattern
   핵심 기능과 데이터를 포함하는 Model과 정보를 표시하는 View, 입력을 처리하는 Controller로 구성된 패턴이다.
   

특징
- 여러 개의 View를 만들 수 있으며, 대화형 애플리케이션에 적합하다.

5. Master-Slave Pattern
   Master component와 구조가 동일한 Slave component들로 작업을 분할하여 처리하고, 처리된 결과물을 Master component로 되돌려 받는다.
   

6. Broker Pattern
   사용자가 Broker component에 작업을 요청하면, Broker component가 적합한 component를 연결한다.
   

7. Peer-TO-Peer Pattern
   각 Peer는 Client 또는 Service가 될 수 있다.
   

8. Event-Bus Pattern
   Source가 특정 Channel에 Message를 발행(Publish)하면, 해당 채널을 구독(Subscribe)한 Listner가 Event를 처리한다.
   

9. Blackboard Pattern
   모든 component가 Blackboard component와 공유 DB에 접근할 수 있다.

10. Interpreter Pattern

---

객체지향 설계

---

✅객체지향(Object Oriented)[★★★★★]

현실 세계의 개체(Entity)를 하나의 객체(Object)로 만들어 소프트웨어를 개발하는 기법이다.

◾객체지향 특징

• 구조적 기법의 대안으로 사용된다.
• 재사용 및 확장이 용이하고, 유지보수가 간편하다.
• 병렬 처리를 지원한다.

◾객체지향 구성 요소

1. 객체(Object)
   데이터(Attribute, Data Structure...)와 함수(Method, Operation...)를 묶어놓은 모듈이다.

   특징
   - 독립적으로 식별 가능한 이름이 있다.
   - 상태(State)는 시간에 따라 변한다.
   - 일정한 기억장소를 가지고 있다.

※ Message: 객체에 명령하는 것

2. Class
   공통된 속성과 연산(행위)를 갖는 객체의 집합이다.

   특징
   - 데이터를 추상화하는 단위이다.

※ Instance: 클래스에 속한 각각의 객체
※ 인스턴스화(Instantiation): 클래스로부터 새로운 객체를 생성하는 것
※ Super Class: 특정 Class의 상위(Parents) Class
※ Sub Class: 특정 Class의 하위(Child) Class

◾객체지향 기법

1. 캡슐화(Encapsulation)
   관련성이 높은 데이터와 함수를 하나로 묶는 것을 의미한다.

   특징
   - 정보은닉으로 외부에서 접근이 제한된다.
   - 단순화를 통해 재사용성이 향상된다.

2. 상속성(Inheritance)
   상위 클래스의 속성을 하위 클래스가 물려받는 것
   다중 상속(Multiple Inheritance): 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것으로, 다중 상속의 겨여우 계층을 복잡하게 만들기 때문에 허용하지 않는 프로그래밍 언어도 존재한다.

3. 다형성(Polymorphism)
   상속받은 여러 개의 하위 객체(Class)들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질

4. 연관성(Relationship)
   두 개 이상의 객체(Class)가 상호 참조하는 관계

is member of: Association(일련화) - 상호 관련
is instance of: Classification(분류화) - 유사 객체 
is part of: Aggregation(집단화) - 상위 객체 구성
is a: Generalization(일반화), Specialization(상세화)

◾객체지향 분석 방법론[★★★☆☆]

종류	만든이(방법론)	설명
OMT (Object Modeling Technology)	Rumbaugh(럼바우)	가장 일반적인 방법 객체 모델링 → 동적 모델링 → 기능 모델링
OOA (Object Oriented Analysis)	Coad와 Yourdon	E-R 다이어그램
OOSE (Object Oriented Software Engineering)	Jacobson(야콥슨)	Use Case
OOD (Object Oriented Design)	Booch(부치)	Micro와 Macro 개발 프로세스
OOD (Object Oriented Design)	Wirfs-Brock	고객 명세서 평가

• Rumbaugh(럼바우) 분석법[★★★★★]
  모든 구성 요소를 그래픽 표기법을 활용해 모델링하는 기법으로, 객체 모델링 → 동적 모델링 → 기능 모델링 순서로 분석한다.
  =객체 모델링 기법(OMT, Object-Modeling Technique)

  1. 객체 모델링(Object Modeling)
     객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것으로 정보 모델링이라고도 한다.

  2. 동적 모델링(Dynamic Modeling)
     상태 다이어그램을 이용하여 시간의 흐름에 따라 객체들의 동적 행위를 표현하는 방법이다.

  3. 기능 모델링(Functional Modeling)
     자료 흐름도(DFD)를 이용해 자료 흐름을 중심으로 표현하는 방법이다.

◾ 객체지향 설계 원칙(SOLID)

원칙	설명
단일 책임의 원칙 (SRP) (Single Responsibility Principle)	객체는 하나의 책임만 진다.
개방 폐쇄 원칙 (OCP) (Open Close Principle)	확장에는 열려있고, 변경에는 닫혀있다.(기존 코드를 변경하지 않고 기능을 추가한다), 캡슐화
리스코프 치환의 원칙 (LSP) (Liskov Subsitution)	Sub(Child) Class는 Super(Parents) Class를 상속받아야 한다.
인터페이스 분리의 원칙 (ISP) (Interface Segregation Principle)	클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안 된다. 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다.
의존성 역전의 원칙 (DIP) (Dependency Inversion Principle)	객체 간 의존 관계가 설링될 때 추상성이 높은 클래스와 의존 관계를 맺어야 한다.

✅디자인 패턴(Design Pattern)

서브시스템(컴포넌트 등)을 설계할 때 참고할 수 있는 표준화된 해결 방법 또는 예제를 의미한다. 문제 및 배경, 실제 적용 사례, 재사용 가능한 샘플 코드 등으로 구성되어 있다.
※ 아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용한다.

장점

• 범용적 코딩 스타일로 소프트웨어 구조 파악이 간편하다.
• 객체지향 설계 및 구현의 생산성을 높이는데 적합하다.
• 재사용을 위한 개발 시간이 단축된다.
• 검증된 패턴을 사용하여 시간 및 비용을 절감할 수 있다.
• 개발자 간 의사소통이 쉽다.
• 유연한 대처가 가능하다.

단점

• 요구 사항을 디자인 패턴에 맞게 구현해야 하기 때문에 초기에 발생하는 비용은 높을 수 있다.(단, 유지보수 및 재사용 측면에서 볼 때 전체적으로는 비용이 절감된다.)
• 객체지향 기반으로 설계와 구현을 하기 때문에 다른 기반의 애플리케이션 개발에 적합하지 않다.

◾ GoF(Gang of Four) [★★★★★]
1995년 에릭 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vlissides)가 디자인 패턴을 구체화 및 체계화한 것으로, 생성 패턴, 구조 패턴, 행위 패턴으로 나뉜다.

생성 패턴(Creational Pattern)	구조 패턴(Structure Pattern)	행위 패턴(Behavioral Pattern)
Singleton	Bridge	Strategy(전략)
Prototype	---------	Mediator(중재자)
Abstract(추상) Factory	Adapter	Command
Factory Method	Composite	State
---------	Decorator	Observer
Builder	Façade	Visitor
	Flyweight	---------
	Proxy	Interpreter
		Iterator(반복자)
		Memento
		Chain of Responsibility(책임 연쇄)
		Template Method

1. 생성 패턴(Creational Pattern)
   객체의 생성과 참조 과정을 캡슐화하는 패턴으로, 객체 생성 및 변경에 따른 프로그램의 구조 영향이 크지 않아 프로그램에 유연성을 높일 수 있다.

생성 패턴(Creational Pattern) 상세	설명
Singleton	클래스 내 인스턴스가 하나뿐임을 보장한다. 생성된 객체는 누구든 접근할 수 있으나, 동시에 접근할 수는 없다.
Prototype	원본 객체를 복사하여 객체를 생성한다.
Abstract(추상) Factory	구체적인 클래스를 지정하지 않고, 서로 연관된 객체들을 그룹으로 생성하여, 추상적으로 표현한다.
Factory Method	상위클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 한다. 객체를 생성하기 위한 인터페이스를 정의하여, 어떤 클래스가 인스턴스화 될 것인지 서브 클래스가 결정하도록 한다. =Virtual Constructor(가상 생성자)
---------
Builder	작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성한다.

2. 구조 패턴(Structure Pattern)
   클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴으로, 구조가 복잡한 시스템 개발을 간편하게 한다.

구조 패턴(Structure Pattern) 상세	설명
Bridge	구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
---------
Adapter	기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 패턴 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
Composite	여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
Decorator	객체 간의 결합을 통해 기능을 확장할 수 있는 패턴
Facade	복잡한 서브 클래스들을 피해 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
Flyweight	인스턴스가 필요할 때마다 생성하지 않고 공유해서 사용함으로써 메모리를 절약하는 패턴
Proxy	접근이 어려운 객체와 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

Composite: 합성의
Facade: 표면
Proxy: 대리

3. 행위 패턴(Behavioral Pattern)
   클래스나 객체들이 서로 상호작용하는 방법 및 책임 분배 방법 등을 정의하는 패턴으로, 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 한다.

행위 패턴(Behavioral Pattern) 상세	설명
Strategy(전략)	동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
Mediator(중재자)	객체 간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성한다.
Command	용청을 객체 형태로 캡슐화하여 재이용하거나, 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
State(상태)	객체의 상태에 따라 동일한 동작을 다르게 처리할 때 사용하는 패턴
Observer	한 객체의 상태가 변화하면 객체에 상속된 다른 객체들에도 변화된 상태를 전달하는 패턴
Visitor	각 클래스의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
---------
Interpreter	언어에 문법 표현을 정의하는 패턴
Iterator(반복자)	자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
Memento	특정 시점의 객체의 상태를 저장한 후 요청에 따라 해당 시점으로 되돌릴 수 있는 기능을 제공하는 패턴
Chain of Responsibility(책임 연쇄)	한 객체가 요청을 처리하지 못하면 다음 객체로 넘어가는 패턴
Template Method	상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 패턴

mediate: 중재하다
memento: 기억, 유물