7. 아키텍처 설계와 패턴

●아키텍처의 역할

시스템의 구조를 확립하는 소프트웨어 개발의 중심축

설계, 구현과 통합, 테스팅까지 통합하는 뼈대

모든 단계에 영향을 줄 만한 초기 의사 결정의 핵심

 

●아키텍처 스타일

일반적인 모양과 조화를 위한 스타일을 정하는 작업

- 시스템 분할, 전체 제어 흐름, 오류 처리 방침,서브시스템간의 통신 프로토콜 포함

구성 요소 유형에 대한 설명 및 런타임 제어, 데이터 전송에 대한 패턴

주요 스타일

- 클라이언트 서버형

- 계층형

- 이벤트 기반 아키텍처

- MVC

- 파이프 필터

- 데이터 중심 아키텍처

- Peer-to-Peer 스타일

 

●클라이언트 서버형

서버 : 강력한 성능으로 자원을 관리하며 클라이언트가 요청하는 기능이나 자원을 제공

클라이언트 : 자원의 사용을 위해 서버 접속

장점 : 데이터 집중화, 보안

단점 : 병목, 비용, 비강인성

 

●계층형

소프트웨어의 기능을 수직으로 상호 작용하는 여러 층으로 분할

각 층 사이는 메시지를 교환

장점 : 추상화, 캡슐화, 응집 높음, 재사용

단점 : 이웃 층과의 커뮤니케이션이 제한적

 

●이벤트 기반 아키텍처

이벤트 스트림을 생성하는 이벤트 생산자

이벤트를 수신 대기하는 이벤트 소비자로 구성

이벤트 : 실시간으로 전달되어 발생하는 즉시 소비자가 이벤트에 응답할 수 있어야

상태 기반 처리

 

●MVC(Model-View-Controller)

사용자 인터페이스로부터 비즈니스 로직과 데이터를 분리

컨트롤러 : 모델에 명령을 보냄으로써 모델의 상태를 변경

모델 : 데이터의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보

뷰 : 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옴

 

●파이프 필터(Pipe and Filter)

필터 사이에 데이터를 이동시키며 단계적으로 처리

데이터의 변환을 수행하는 필터 구성 요소로 구성

ex) 컴파일러

장점 : 단순성, 재사용, 병렬성

단점 : 자원의 낭비

 

●데이터 중심 아키텍처

공유 데이터 저장소와 공유 데이터 접근자로 구성

접근자는 공유 데이터를 추가, 삭제 및 수정

블랙보드 : 제어 스레드 포함, 옵서버 디자인 패턴 사용

리파지토리 : 공유 데이터를 질의하여 변경 사항을 발견

 

●Peer-to-Peer 스타일

각 컴포넌트는 동등하여 서비스를 요청하는 클라이언트 동시에 서비스를 제공하는 서버 역할

동일한 수신, 전송 데이터 양을 가지므로 대칭적인 시스템

 

●디자인 패턴

아키텍처 설계 수준보다 낮은 수주의 설계 문제에 재사용 가능한 솔루션 제공

혜택 : 쉽게 재사용 가능, 설계 작업이 쉬워짐, 설계 관련 지식이 정리됨, 디자인을 논의하기 위한 의사소통이 쉬워짐, 객체지향 설계 원리를 잘 따르게 됨

프로그램 개발에 자주 등장하는 문제를 기술하고 같은 작업을 반복하여 설계하지 않고 여러 번 반복하여 사용할 수 있는 문제에 대한 솔루션을 기술한 것

여러 가지 상황에 적용될 수 있는 템플릿

문제에 대한 설계를 추상적으로 표현한 것

문제를 해결하려는 요소들을 일반화하여 잘 정리한 것

커스텀화된 객체나 클래스의 연결을 나타낸 것

패턴은 검증된 설계 경험의 기록

패턴은 주어진 시스템 상황에서 반복적으로 발생할 수 있는 문제에 대해 솔루션 제시

패턴은 디자인과 아키텍처에 대한 용어 제공

패턴 그룹은 아키텍처의 가반

설계 패턴 구성 요소 : 패턴의 이름과 구분, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

 

●설계 패턴의 3가지 유형

생성 패턴(Creational Pattern)

- 객체를 생성하는데 관련된 패턴들

- 객체가 생성되는 과정에 유연성을 높이고, 코드의 유지가 쉬워짐

- Abstract Factory, Prototype, Singleton, Factory Method, Builder

구조 패턴(Structural Pattern)

- 프로그램의 구조에 관련된 패턴들

- 프로그램내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 많이 활용될 수 있는 패턴들

- Adapter, Bridge, Composite, Decorator, Flyweight, Facade, Proxy 

행위 패턴(Behavioral Pattern)

- 반복적으로 사용되는 객체들의 상호작용을 패턴화

- Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

 

●위임(Delegation)

상속 : base class에 새로운 오퍼레이션이나 기존 오퍼레이션을 overriding해서 확장하는 방식

위임 : 오퍼레이션을 가로채서 다른 객체에게 전달

위임은 객체 조합(object composition)을 통해 상속과 같은 재사용 효과를 낼 수 있음

 

●Singleton(싱클톤 패턴)

해결하는 문제

+ 오직 하나의 인스턴스(객체)를 가져야 하는 경우

+ 객체를 강제적으로 하나만 생성하려는 목적으로 사용

+ 다수의 객체 생성은 복잡도를 높이고 성능 저하를 초래할 수 있음

솔루션

+ 하나의 객체만을 생성하고 재사용함

+ 재사용을 담당하는 코드는 캡슐화하여 외부 접근을 차단

 

●Iterator(반복자 패턴)

해결하는 문제

+ 복합 객체 요소의 내부 표현 방식을 공개하지 않고 순차적으로 접근할 수 있는 방법 제공

+ 집합 클래스의 자료구조와 상관없이 집합에 소속된 요소들을 쉽게 접근하기 위해 반복자에게 위임

+ 서로 다른 복합 객체에 대해서도 동일한 방법으로 순회 가능

솔루션

+ 반복 수행하는 집합 클래스에 대하여 접근하는 반복자 Iterator 인터페이스 정의

+ 집합에 의해 구현될 Aggregate 인터페이스 정의. 인터페이스는 반복자를 반환하는 팩토리 메소드 포함

+ 추상 팩토리 메소드를 상속 구현하여 특정 집합의 반복자를 반환하는 집합 클래스 작성

+ 정의한 Iterator, Aggregate 인터페이스를 이용하는 클라이언트 코드 작성

 

●Adapter(어댑터 패턴)

해결하는 문제

+ 기존 모듈 재사용을 위한 인터페이스 변경

+ 프로그램 개발 시 참고할 코드의 소스가 없는 경우

+ 예를 들어, Java의 경우, .class 파일만 있는 경우

+ 재사용 코드가 개발자가 원하는 인터페이스를 제공하지 않는 경우(메소드 이름이 다른 경우, 메소드 수가 많거나 적은 경우)

위와 같은 문제 상황에서, 특정 코드를 재사용하기 위해 adapter 패턴을 적용

 

●Decorator(데코레이터 패턴)

집합 관계와 위임을 사용하여 기존 클래스의 동작을 가볍고 유연하게 확장

코드 수정에 의한 기능 변경(코드 직접 수정 필요, 객체지향 설계 원리 중 OCP 원리 위배)

상속에 의한 기능 변경(기능의 조합 수 만큼의 서브 클래스가 필요)

위임에 의한 기능 변경(런타임 객체 기능 변경, 데코레이터 패턴 사용)

구성 요소

+ 장식 대상 component 클래스와 확장 기능이 담긴 데코레이터

데코레이터 객체가 재귀 합성으로 component 객체를 래핑

데코레이터와 어댑터 패턴은 모두 위임을 사용하여 인터페이스 구현

데코레이터 패턴은 wrapping하는 객체와 동일한 인터페이스를 구현하지만, 어댑터 패턴은 요청과는 다른 인터페이스 구현

 

●Factory Method(팩토리 메소드 패턴)

대행 함수(팩토리 메소드)를 통한 객체 생성

생성되는 객체에 대한 결정을 서브클래스가 할 수 있도록 객체 생성 인터페이스 제공

서브클래스에게 인스턴스 생성의 책임을 위임

구체적으로 생성할 객체 타입을 예측할 수 없을 때 사용

생성할 객체를 기술하는 책임을 서브클래스에 정의하고자 하는 경우

객체 생성의 책임을 서브클래스에게 위임하고 서브클래스 정보를 은닉

 

●Abstract Factory(추상 팩토리 패턴)

객체를 사용할 클라이언트에서 구체적인 객체 생성을 지정하는 책임을 분리하기 위하여 추상 인터페이스를 이용하여 관련 객체 패밀리를 생성

 

●State(상태 패턴)

객체의 내부상태 변경에 따라 객체의 행위가 변경됨

이벤트 의존 애플리케이션에 적합한 패턴

시스템이 동작하면서 발생되는 이벤트에 따라 변경이 이루어질 수 있도록 설계

 

●Observer(옵서버 패턴)

객체 상태의 변동을 실시간 감지하기 위한 패턴

변동 사항을 알고 싶은 관찰자(observer) 객체는 사전에 등록되어야 함

관찰 대상 객체(subject)의 상태가 변하면 등록된 관찰자 객체들에게 변동 사항을 알려줌

 

●Strategy

유사성을 가지는 다양한 알고리즘이 존재할 경우, 각각의 알고리즘을 별도의 클래스로 캡슐화하여 알고리즘의 대체가 가능하도록 하고자할 경우 사용

클라이언트와 알고리즘은 독립성을 가지며 알고리즘을 바꾸더라도 클라이언트는 변경이 없음

 

●Facade

서브시스템의 내부가 복잡하여 클라이언트 코드가 사용하기 힘들 때 간단한 인터페이스를 통해 서브시스템을 사용하도록 제공

단일화된 인터페이스를 제공하며 클라이언트는 시스템의 내부 구조를 알 필요가 없음

 

●아키텍처 평가

아키텍처나 디자인 패턴의 속성, 강점 및 약점을 결정하는 방법

개발자가 선택한 아키텍처가 기능적 및 비기능적 품질 요구 사항을 모두 충족시킬 수 있음을 보증

방법 : SAAM(시나리오 기반 평가), ATAM(여러가지 품질 속성에 초점 맞춰 평가)

 

●SAAM(Software Architecture Analysis Method)

아키텍처가 시나리오를 실행할 수 있는지 여부를 결정(못하는 경우, 시나리오를 지원하도록 아키텍처를 변경)

여러 이해 당사자를 통하여 시나리오 도출

직접 시나리오 : 시스템의 변경이 요구되지 않는 시나리오. 유스케이스를 통한 아키텍처 평가

간접 시나리오 : 시스템의 변경이 요구되는 시나리오. 새로운 기능을 추가하거나 원하지 않는 기능을 삭제. 새로운 하드웨어, 운영체제, IO 장치 환경에 적응하는지 평가

 

●ATAM(Architecture Trade-off Analysis Method)

여러 가지 품질 속성(유지 보수성, 성능, 가용성, 보안성, 사용 용이성 등)에 초점을 맞추어 평가하여 아키텍처의 Trade-off, 설계 타협점을 찾아냄