📂 목차
- 재사용 유형
- 모듈
- 공통 모듈 원칙
- 모듈화 기법
- 모듈 개수-비용 간 상관관계
- 응집도
- 결합도
- 팬인 및 팬아웃
- 소프트웨어 아키텍쳐 비용 평가 모델 종류
- 소프트웨어 아키텍처 패턴 유형
- 객체 지향 기법
- 객체 지향 설계 원칙(SOLID)
- 객체 지향 방법론 종류
- ⭐️ 디자인 패턴
📚 본문
재사용 유형
- 함수와 객체
- 컴포넌트
- 어플리케이션
모듈
자체적으로 컴파일 가능
공통 모듈 원칙
- 정확성: 실제 시스템 구현 시 필요한지 아닌지를 알 수 있도록 정확하게 작성
- 명확성: 일관되게 이해되고 한 가지로 해석될 수 있게 작성
- 완전성: 필요하고 요구되는 모든 것을 기술
- 일관성: 상호 충돌이 없도록 작성
- 추적성: 공농 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별 가능하도록 작성
모듈화 기법
- 루틴: 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
- 메인루틴: 전체적인 동작 절차를 표시하도록 만들어진 루틴
- 서브 루틴: 메인 루틴에 의해 호출되는 루틴
모듈 개수-비용 간 상관관계
- 모듈 개수가 늘어나면, 모듈 통합 비용은 커지며, 개발 비용은 줄어듦
- 모듈 개수가 적어지면, 모듈 통합 비용은 줄지만, 개발 비용은 늘어남
응집도
모듈 내부 구성요소 간의 연관 정도
외우기 - 우논시절통순기
- 우연적(Coincidental) 응집도 - 서로 간에 어떠한 의미 있는 연관이 없을때
- 논리적(Logical) 응집도 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들이 한 모듈에서 처리됨
- 시간적(Temporal) 응집도 - 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리
- 절차적(Procedural) 응집도 - 구성요소들이 순차적으로 수행
- 통신적(Communication) 응집도 - 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있음
- 순차적(Sequential) 응집도 - 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
- 기능적(Functional) 응집도 - 모든 기능이 단일한 목적을 위해 수행
기준은 ‘한 모듈’
결합도
모듈과 모듈간의 상호의존성을 나타냄
외우기 - 내공외제스자
- 내용(Content) 결합도 - 다른 모듈의 변수나 기능을 다른 모듈에서 사용하는 경우
- 공통(Common) 결합도 - 모듈 밖의 전역 변수를 참조하고 갱신하는 식의 상호작용
- 외부(External) 결합도 - 데이터 포맷, 통신 프로토콜/디바이스 인터페이스를 공유할 경우
- 제어(Control) 결합도 - 내부 논리 조직을 제어하기 위한 목적으로 제어 신호 이용
- 스탬프(Stamp) 결합도 - 모듈 간 인터페이스로 객체, 구조 등이 전달되는 경우
- 자료(Data) 결합도 - 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어남
팬인 및 팬아웃
팬인: 어떤 모듈을 제어하는 모듈 수 팬아웃: 어떤 모듈에 의해 제어되는 모듈 수
소프트웨어 아키텍쳐 비용 평가 모델 종류
- SAAM: 변경 용이성과 기능성에 집주, 평가가 용이
- ATAM: 아키텍처 품질 속성 판단
- CBAM: 비용 평가 모델
- ADR: 응집도 평가 모델
- ARID: 특정 부분에 대한 품질요소의 비용 평가
소프트웨어 아키텍처 패턴 유형
- 계층화 패턴: 하위 모듈이 상위 모듈에게 서비스 제공
- 클라이언트-서버 패턴
- 파이프-필터 패턴: 데이터 스트림 생성, 처리하는 단반향 패턴, 필터 컴포넌트는 재사용성이 좋음
- 브로커 패턴: 브로커가 통신 조정하는 역할
- 모델-뷰-컨트롤러 패턴: 모델(핵심 기능과 데이터 보관), 뷰(정보 표시), 컨트롤러(입력 처리)
- 마스터-슬레이브 패턴: 실시간 시스템에서 사용
객체 지향 기법
- Encapsulation: 인터페이스 단순화
- Inheritance: re-define 없이 물려받아 사용하는 기법
- Polymorphism: 오버로딩(여러 생성자를 정의), 오버라이딩(메서드 재정의)
- Abstraction: 공통 성질을 추출하여 추상 클래스를 정의
- Information Hiding: 공개 인터페이스만을 통해서만 접근, Side-effect 최소화, 모듈 간 독립성 유지
- Relationship: 두 개 이상의 엔티티 형에서 데이터를 참조하는 관계를 나타내는 기법
- 연관화: is-member-of, 객체 참조
- 집단화: part-whole, 모여서 하나의 상위 객체를 만듦
- 분류화: is-instance-of, 포함관계이자 상속
- 일반화: is-a, 상위 특성을 상속
- 특수화: is-a, 상위 특성을 상속 후 그 특성을 수정
객체 지향 설계 원칙(SOLID)
- Single Responsibility: 하나의 클래스는 하나의 목적을 위해서
- Open Close Principle: 확장에는 열려있고, 변경에는 닫혀있고
- Liskov Substitution Principle: “서브 타입은 어디서나 그 상위 타입으로 교체할 수 있어야 한다.”
- Interface Segregation Principle: 필요한 최소한의 인터페이스만 구현
- ⭐️ Dependency Inversion(Injection) Principle: 실제 사용 관계는 바뀌지 않고 추상을 매개로 메시지를 주고받아 관계를 최대한 느슨하게 만드는 원칙
객체 지향 방법론 종류
- OOSE: 분석-설계-구현, 기능 요구사항 중심
- OMT: 객체-동적-기능, 모델링 중심
- Object Modeling: 객체 다이어그램
- Dynamic Modeling: 상태 다이어그램
- Functional Modeling: 자료 흐름도
- OOD: 분석과 설계의 분리 불가능
- Coad-Yourdon: E-R 다이어그램
- Wirfs-Brock: 분석/설계 간의 구분이 없고 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행
⭐️ 디자인 패턴
생성 패턴
생빌 프로 팩앱싱
- Builder: 복합 객체를 생성하는 방법, 객체를 구현하는 방법을 분리, 보통 클래스 내부에 Builder nested class 를 작성
- Prototype: 일반적인 원형을 만든 후 해당 객체를 복제
- Factory Method: 객체를 생성하는 인터페이스를 정의 → 하위에서 객체를 생성하는 인터페이스 구현
- Abstract Factory: Composite Structure 를 가지는 인스턴스에 대한 팩토리를 만드는 객체
- Singleton: 전역 변수를 사용하지 않고 객체 하나만 생성
구조 패턴
구 브데 퍼플 프록 컴 어
- Bridge: ‘분리된’ 기능과 구현을 ‘연결시켜’ 추상화된 부분과 실제 구현 부분을 독립적으로 확장, 구현 뿐 아니라 추상화 부분 까지 건드려야 하는 경우 유용
- Decorator: 필요한 기능을 추가해 확장이 필요할 때 객체 간의 결합을 통해 기능을 유연하게 확장, 여러 곳에 기능을 쉽게 넣을 때 개발의 편의성을 위한 목적
- Facade: 사용자와 시스템, 시스템과 시스템 간의 통합된 단순한 인터페이스를 제공, 느슨한 결합도 목적
- Flyweight: 다수 객체로 생성될 때, 공유 요소를 클래스 화하여 가상 인스턴스 공유로 메모리를 절약, 클래스 경량화 목적
- Proxy: 실제 객체에 대한 대리 객체, 특정 객체로 접근을 제어하기 위해 사용
- Composite: 객체들의 관계를 트리 구조로 구성, 복합 객체와 단일 객체를 동일시
- Adapter: 기존 생성된 클래스를 재사용할 수 있도록 인터페이스 역할을 함, 인터페이스가 호환되지 않는 클래스들을 함께 이용하도록 할때 유용
행위 패턴
메인아이템 옵스 비컴 스메체
- Mediator: 객체의 수가 많아짐에 따라 서로 간의 통신이 복잡하여 통신을 위한 중재자(mediator)를 둠
- Interpreter: 구문을 나누고, 분리된 구문의 해석을 맡는 클래스를 ‘각각 작성’ 후 여러 형태의 언어 구문을 해석
- Iterator: 컬렉션 구현 방법을 노출시키지 않고, 순회자(반복자) 클래스를 사용하여 접근
- Template: 추상 클래스에는 추상 메서드를 통해 기능의 골격을 제공, 메서드는 세부 처리를 구체화하는 방식으로 사용
- Observer: 한 객체의 상태가 바뀔 시 의존하는 다른 객체들에게 연락이 가는 구조, 일대 다의 의존성을 가짐
- State: 객체 상태를 캡슐화하여, 참조하게 만드는 방식, 상태에 따라 다른 처리를 해야할 때 유용
- Visitor: 각 객체가 구조가 자주 변경되지 않고, 새로운 연산을 자주 추가해야 할 때 사용, 보통 for 문으로 visitor를 매개변수로 넣는식으로 동작하며 그림 그리기 서비스에 유용하다.
- Command: 재사용성이 높은 클래스를 설계, 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
- Strategy: 알고리즘 군을 정의(추상 클래스)하고, 같은 알고리즘을 각각 하나의 클래스로 캡슐화 후 필요할 때 서로 교환해서 사용
- Memento: 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴, Undo 기능을 개발할 때 사용
- Chain of Responsibility: 정적으로 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능, 동적으로 연결되어 있는 경우 다르게 처리될 수 있도록 연결한 디자인 패턴, 한 요청을 2개 이상의 객체에서 처리