아키텍처 & 디자인 패턴 용어 정리

Architecture & Design Pattern 전체 링크
 
오브젝트 (Object)
- 데이터와 그 데이터를 처리하는 메서드의 조합으로 이루어진 소프트웨어의 기본 단위
- State(attributes)와 Behavior(operations)을 가진다.
- 클래스는 객체를 생성하기 위한 템플릿(Abstract Definition)이며, 객체는 클래스의 인스턴스다.
 
인스턴스 (Instance)
- 객체지향 프로그래밍에서 클래스를 기반으로 생성된 실체
- 클래스는 객체를 만들기 위한 템플릿이며, 이 템플릿을 기반으로 생성되는 것이 인스턴스
 

객체지향 분석 (OOA, Object-oriented Analysis)

- 도메인을 이해하고, 시스템이 가져야 할 요구사항을 식별하고 분석하는 단계 (Use Case Diagram)

- 사용자의 요구사항을 수집, 분석, 도메인 내 객체 식별

- What에 대한 분석

 

객체지향 설계 (OOD, Object-oriented Design)

- OOA에서 식별된 객체들을 클래스와 객체의 구조로 변환하고 상호작용을 설계 (Class Diagram)

- 객체들의 인터페이스와 동작을 정의하고, 어떻게 커뮤니케이션할지 정의 (Sequence Diagram)

- How에 대한 설계

객체지향 분석 및 설계 (OOAD, Object-oriented Analysis and Design)
- 사용자의 요구 사항을 이해하고 이를 객체들의 집합으로 모델링하는 과정
 

도메인 모델 (Domain Model)

- 특정 도메인에 대한 현실 세계의 개념과 규칙을 반영하는 소프트웨어 모델

- 해당 도메인의 핵심 객체, 관계, 동작, 규칙 등을 포함한다.

- 도메인 모델은 클래스 다이어그램과 비슷하지만 operation이 없고, attribute만 존재한다.

통합 프로세스(Unified Process)
- 객체지향 분석 및 설계 (OOAD)에 대한 프로세스로, SW 개발을 위한 반복적이고 증분적인 접근 방식을 제공
- 요구 사항 분석, 설계, 구현, 테스트 등의 단계를 반복
- 도입 (Inception) → 구체화 (Elaboration) → 구축 (Construction) → 전이 (Transition)
 
SRS (Software Requirements Specification)
- 소프트웨어 요구사항 명세서
- 개발 프로젝트의 초기 단계에서 작성
- 개발자, 고객, 프로젝트 관리자 등 모든 이해관계자 간에 요구사항을 이해하고 합의하는 데 사용
 
SDS (Software  Design Specification)
- 소프트웨어 설계 명세서
- 시스템의 구조, 구성요소 및 작동 방식을 설명
- 시스템을 개발하기 위한 설계 단계에서 작성
- 시스템 아키텍처, 데이터베이스 구조, 모듈 인터페이스, 알고리즘 등에 대한 세부 정보 제공

 

의존성 부패 (Dependency Rot)
- 여러 구성 요소 간의 의존성이 증가하는 현상
- 상위 모듈이 하위 모듈에, 하위 모듈이 상위 모듈에 서로 의존적이면 의존성 부패가 나타나게 된다.
 
원자성 (Atomicity)
- 연산이 도중에 중단되지 않고 전체가 완료되거나 전혀 수행되지 않는 것
- 원자성이 지켜져야 멀티스레드 환경에서 데이터의 일관성을 유지하고 동시성 문제를 해결할 수 있다.
 
지연 로딩(Lazy Loading)
- 객체나 자원이 처음 사용될 때까지 초기화 또는 로딩을 지연시키는 기법
- 대규모 시스템에서 모든 객체를 초기화하거나 로딩할 필요가 없는 경우, 필요한 시점에 로딩하여 성능을 향상
- 지연된 초기화(Lazy Initialization)는 싱글턴 패턴에서 사용되는 기법
 
더블 체크 락킹 패턴 (DCLP, Double Checked Locking Pattern)
- 객체의 인스턴스가 생성되지 않았을 때만 락을 사용하여 여러 스레드에서 안전하게 인스턴스를 생성하는 방법을 제공
- 메모리 모델 특성상 스레드 간의 가시성 문제가 발생할 수 있어 권장되지 않음
 

응집도 (Cohesion)
- 소프트웨어 디자인에서 모듈이나 클래스가 하나의 목적을 가지고 있는 정도를 나타내는 개념
- 응집도가 높다는 것은 서로 연관된 기능이 묶여있다는 것을 의미한다.
- 응집도가 낮다는 것은 서로 상관없는 기능들이 묶여있다는 것을 의미한다.

 

결합도 (Coupling)

- 모듈 또는 클래스가 다른 모듈, 클래스에 얼마나 의존하고 있는지를 나타내는 척도

- 결합도가 높다는 것은 한 모듈의 변경이 다른 모듈에 미치는 영향이 크고, 재사용성이 떨어지는 것을 의미한다.

- 결합도가 낮다는 것은 모듈 간의 상호작용이 적고, 독립적으로 변경될 수 있는 구조를 의미한다.

느슨한 결합 (Loose Coupling)
- 소프트웨어 구성 요소 간의 의존성을 최소화하는 디자인 원칙
- 한 요소가 다른 요소에 대해 가능한 한 적은 정보를 알아야 한다.
- 두 객체가 서로 상호작용을 하지만 서로의 동작에 대해 잘 모르는 상태를 의미한다.
- 인터페이스와 추상화를 통해 구현할 수 있다.
- 유지보수, 재사용성, 테스트 용이성과 같은 이점이 발생한다.

비즈니스 목표 (Business Goal)

- SW 시스템이 궁극적으로 달성하려는 비즈니스 관련 목표나 목적

- SW 아키텍처는 비즈니스 목표 달성을 위한 기술적 토대를 제공한다.

- 비즈니스 목표가 SW 시스템의 방향과 우선순위를 결정하게 된다.

 

아키텍처 드라이버 (Software Architectural Driver)

- 시스템 아키텍처 설계에 영향을 미치는 주요 요인

- 기능적 요구사항 (FR) : 시스템이 사용자의 Business Goal을 달성하기 위한 요구사항, 기능, 서비스

- 비기능적 요구사항 (NFR) : 시스템의 운영 특성, 성능, 보안, 유지보수성 등과 관련된 품질 속성 요구사항 

- 제약 조건 (Constraints) : 시스템 개발 과정에서 반드시 준수해야 하는 조건이나 제한 사항 (기술, 환경, 법, 조직 등)

 

품질 속성 (Quality Attributes)

- 소프트웨어 시스템이 충족해야 하는 비기능적 특성을 의미

- NFR의 구체적인 형태로 시스템의 품질을 측정하고 평가한다.

- Availability, Interoperability, Modifiability, Performance, Security, Testability, Usability 등

- 품질 속성 시나리오 (QAS, Quality Attribute Scenarios)로 평가할 수 있다.

 

아키텍처 뷰 (Architectural Views)

- 시스템의 구조를 표현한 것으로 시스템 측면을 강조

- 시스템의 다양한 측면을 다른 관점에서 표현하고, 시스템을 더 잘 이해하고, 의사소통을 원할하게 하기 위해 필요

- 다양한 이해당사자 관점에서 표현, 복잡도를 관리하고 상호 일관성을 유지한다.

 

아키텍처 전술 (Architectural Tactics)

- SW 시스템의 특정 품질 속성을 만족시키기 위한 설계 전략

- 구체적인 품질 요구사항을 달성하기 위해 사용되는 기술적인 접근 방법

 

아키텍처 스타일 (Architectural Style)

- 시스템의 구조와 구성 요소들 간의 조직된 상호작용 방식을 기술하는 패턴의 집합

- 일반적인 설계 접근 방식을 나타내며, 특정 문제 해결을 위한 구체적인 패턴보다는 더 큰 규모와 범위에서 사용

- Client-Server, Peer-to-Peer, Event-Driven Architecture, Service-Oriented Architecture, ...

 

아키텍처 패턴 (Architectural Pattern)

- 재사용 가능한 해결책을 제공하는 고수준의 설계 템플릿

- 시스템의 기본 구조를 설계하고, 구성 요소 간의 관계와 상호작용을 규정하고, 여러 품질 속성을 동시에 고려

- MVC 패턴, Layered Architecture, Microservices Architecture, ...

 

디자인 패턴 (Design Pattern)

- 특정한 문제를 해결하기 위해 반복적으로 발생하는 문제와 그에 대한 해결책을 포괄하는 설계 또는 구조

- 아키텍처 패턴보다 더 구체적인 문제를 해결하고, 클래스와 객체 간의 관계를 정의

- 전략 패턴, 팩토리 메서드 패턴, 어댑터 패턴, ...

---

객체 지향 기본 원칙
 
추상화 (Abstraction)
- 복잡한 시스템이나 데이터를 단순화하여 필요한 부분만을 강조
- 공통적인 특성이나 행동을 찾아내어 클래스나 객체 모델을 만드는 과정
 
캡슐화 (Encapsulation)
- 데이터와 데이터를 다루는 메서드를 하나의 단위로 묶어 외부로부터 보호하는 것
- 정보 은닉 (Information Hiding)의 핵심 원리 중 하나
 
다형성 (Polymorphism)
- 같은 이름의 메서드가 서로 다른 동작을 수행할 수 있는 능력 (재사용성, 유연성 ↑)
- 상속, 인터페이스 구현, 메서드 오버라이딩
 
상속 (Inheritance, Generalization)
- is-a, is a kind of 관계
- 기존 클래스의 특성과 동작을 다른 클래스에게 재사용하거나 확장하기 위한 메커니즘
 
구성 (Composition)
- has-a 관계, 다형성을 구현하는 방법
- 두 객체 사이의 의존성을 런타임에 처리할 수 있다.
- 내부에 포함되는 객체의 구현이 아닌 인터페이스에 의존
- 스트래티지 패턴에서 상속 대신 구성을 활용해 런타임에 알고리즘을 교체한다.
 
위임 (Delegation)
- 한 객체가 다른 객체에게 자신이 필요한 기능을 수행하도록 하는 것
- 객체 간의 의존성을 줄이고 유연성, 코드 재사용과 모듈화를 향상 시킨다.
 
객체지향 설계 5대 원칙 (SOLID)
- 단일 책임 원칙 (SRP, Single Responsibility Principle)
- 개방-폐쇄 원칙 (OCP, Open-Closed Principle)
- 리스코프 치환 원칙 (LCP, Liskov Substitution Principle)
- 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
- 의존 역전 원칙 (DIP, Dependency Inversion Principle)
 
최소 지식 원칙 (The Principle of Least Knowledge)
- 객체가 다른 객체와 직접적으로 상호 작용하는 것보다는 가능한 다른 객체들과의 관련을 최소화해야 한다.
- 객체는 해당 객체와 직접 관련된 정보만을 알아야 하고, 다른 객체의 내부 동작에 대해 세부 사항을 알 필요가 없다.
- 객체와 다른 객체는 인터페이스를 통해 간접적으로 상호 작용을 유지해야 한다.
 
헐리우드 원칙 (The Hollywood Principle)
- Don't call us, we'll call you
- 높은 수준의 모듈 간의 상호작용을 관리하기 위해 사용되는 원칙
- 상위 모듈이 하위 모듈에 의존할 때, 상위 모듈은 직접적으로 하위 모듈에 의존하지 말아야 한다.
- 두 모듈 모두 추상화에 의존해야 한다.
- 하위 모듈이 상위 모듈을 호출하지 않아야 하며, 상위 모듈이 추상화된 인터페이스를 통해 하위 모듈을 호출해야 한다.

---

UML 다이어그램 요약

 

UML 다이어그램 (Unified Modeling Language Diagram)
- 유스케이스 다이어그램 (Use Case Diagram)
- 클래스 다이어그램 (Class Diagram)
- 오브젝트 다이어그램 (Object Diagram)
- 패키지 다이어그램 (Package Diagram)
- 컴포넌트 다이어그램 (Component Diagram)
- 복합 구조 다이어그램 (Composite Structure Diagram)
- 배치 다이어그램 (Deployment Diagram)
- 시퀀스 다이어그램 (Sequence Diagram)
- 커뮤니케이션 다이어그램 (Communication Diagram)
- 타이밍 다이어그램 (Timing Diagram)
- 활동 다이어그램 (Activity Diagram)

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

- 상태 다이어그램 (Statechart Diagram)

---

C++ 디자인 패턴 요약

 

생성 패턴

- 싱글턴 패턴 (Singleton Pattern)

- 팩토리 메서드 패턴 (Factory Method Pattern)

- 추상 팩토리 패턴 (Abstract Factory Pattern)

- 프로토타입 패턴 (Prototype Pattern)

- 빌더 패턴 (Builder Pattern)

 

행동 패턴

- 전략, 스트래티지 패턴 (Strategy Pattern)

- 옵저버 패턴 (Observer Pattern)

- 반복자, 이터레이터 패턴 (Iterator Pattern)

- 상태, 스테이트 패턴 (State Pattern)

- 커맨드 패턴 (Command Pattern)

- 템플릿 메서드 패턴 (Template Method Pattern)

- 역할 사슬, CoR 패턴 (Chain of Responsibility Pattern)

- 방문자, 비지터 패턴 (Visitor Pattern)

- 중재자, 미디에이터 패턴 (Mediator Pattern)

- 메멘토 패턴 (Memento Pattern)

 

구조 패턴

- 복합체, 컴포지트 패턴 (Composite Pattern)

- 데코레이터 패턴 (Decorator Pattern)

- 어댑터 패턴 (Adapter Pattern)

- 퍼사드 패턴 (Facade Pattern)

- 프록시 패턴 (Proxy Pattern)

- 브리지 패턴 (Bridge Pattern)
- 플라이웨이트 패턴 (Flyweight Pattern)