[소공] 7장 아키텍쳐와 패턴

7-1 아키텍처 기초

1. 소프트웨어 아키텍처 정의

: 소프트웨어 시스템에서 높은 수준의 구성요소와 그들의 관계, 상호작용 등을 의미.

 

2. 아키텍처 설계 정의

: 소프트웨어 시스템에 대한 전반적인 구조 설계하는 과정.

(서브시스템 분할 및 덩어리화 작업, 서브시스템 상호 작동 결정, 서브시스템 인터페이스 결정)

 

3. 아키텍처 표현 관점(5) 

• 논리적으로 분할된 서브시스템
• 서브시스템 사이의 인터페이스
• 컴포넌트 사이의 동적인 상호작용
• 서브시스템 사이에 공유되는 데이터
• 런타임에 존재하는 컴포넌트 위치

 

4. 아키텍처 중요성(4)

• 소프트웨어 시스템을 개발자가 잘 이해하기 위해
• 시스템의 일부는 독립적으로 작업하기 위해
• 시스템의 확장을 위해
• 재사용과 재사용 가능성을 위해

 

5. 아키텍처의 역할

: 소프트웨어 개발의 중심축, 뼈대

 

6. 아키텍처 표현

: 일반적으로 계층적 분할.

  - 패키지 다이어그램

    : 서브시스템으로 분할해 객체 간 의존성을 줄여 표현 → 복잡성 줄임

• 점선 화살표 - 의존관계
• Business System Client는 Customer와 RentalUI 클래스를 감추는 Facade 클래스(퍼사드 클래스 - 간략화된 인터페이스)

 

7-2 아키텍처 스타일

1. 아키텍처 스타일 정의

: 시스템 전체 구성 요소, 런타임 제어, 데이터 전송 패턴 등을 명시

 

2. 주요 스타일(7)

• 클라이어트 서버형
• 계층형
• 이벤트 기반 아키텍처
• MVC
• 파이프 필터
• 데이터 중심 아키텍처
• Peer-to-Peer 스타일

 

2-1. 클라이언트 서버형

• 서버: 자원 관리, 클라이언트가 요청한 기능, 자원 제공
• 클라이언트: 자원의 사용을 위해 서버 접속

• 장점(2): 데이터 집중화, 보안
• 단점(3): 병목, 비용, 비강인성

 

2-2. 계층형

• 소프트웨어 기능을 수직으로 분할
• 각 층은 메시지 교환

• 장점(4): 추상화, 캠슐화, 응집 높음, 재사용
• 단점(1): 이웃 층과 커뮤니케이션 제한적

 

2-3 이벤트 기반 아키텍처

• 이벤트 생산자: 이벤트 스트림 생성
• 이벤트 소비자: 이벤트 수신 대기
• 이벤트: 상태 기반 처리

• 장점(2): 캡슐화, 확장성
• 단점(2): 복잡성, 테스팅이 어려움

 

2-4. MVC(Model-View-Controlller)

• 모델: 데이터의 상태 변화가 있으면 컨트롤러와 뷰에게 이를 통보
• 뷰: 모델에서 얻은 정보로 결과 표시
• 컨트롤러: 모델에 명령을 보내 모델 상태 변경

• 장점(2): 확장성(여러 뷰 지원), 비동기
• 단점(1): 복잡성

 

2-5. 파이프 필터

• 필터를 통해 데이터 변환을 수행
• 필터로 데이터 변환을 함. (ex. 컴파일러)

• 장점(3): 단순성, 재사용, 병렬성
• 단점(1): 자원의 낭비

 

2-6. 데이터 중심 아키텍처

• 공유 데이터 저장소
• 접근자: 공유 데이터를 추가, 삭제, 수정
• 종류1-블랙보드: 공유데이터에 제어 스레드 포함, 공유데이터 저장소는 옵서버 디자인 패턴을 사용해 변경될 때 클라이언트에게 알림.
• 종류2-리파지토리: 클라이언트가 공유데이터를 질의해 변경사항 발견.

• 장점(2): 낮은 결합, 확장성
• 단점(1): 단일장애지점

 

2-7. Peer-to-Peer 스타일

• 각 컴포넌트는 클라이언트 겸 서버 역할.
• 동일한 수신, 전송 데이터 양을 가지므로 대칭적인 시스템을 가짐.

• 장점(3): 전담서버 없음,  확장성, 신뢰성
• 단점(2): 중앙제어 불능, 노드 수 증가시 성능 저하 가능.

7-3 디자인 패턴

1. 디자인 패턴 정의

:"A solution to a problem in a context"

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

 

2. 소프트웨어 패턴의 역사(5)

• 1977: 건축가 알랙산더 - "A Pattern Language: Towns, Buildings, Construction"
• 1987: 켄트 백 - 알랙산더의 아이디어를 Smalltalk GUI에 적용
• 1991: 에리히 감마의 박사 학위 논문
• 1995: 감마 등 -  "Design Patterns: Elements of Reusable Object-Oriented Software"
• 1994~현재: " Pattern Languages of Programs (PLoP)"

3. 디자인 패턴의 혜택(5)

• 재사용가능
• 설게가 쉬워짐
• 설계 관련 지식이 정리됨
• 설계를 논의하기 위한 의사소통이 용이.
• 객체 지향 설계 원리를 잘 따르게 됨.

4. 디자인 패턴 종류()

Gangs of Four

 

4-1. 싱글톤 패턴

• 문제: 하나의 클래스에 객체를 강제적으로 하나만 생성.

• 솔루션: 
  • 클래스 안에 자신을 정적 속성으로 갖게 함.
  • 생성된 유일한 객체를 접근하는 정적 메서드 사용.
  • 생성자를 private로 선언

 

4-2 반복자 패턴

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

• 솔루션: 
  • 1. 반복자를 Iterator 인터페이스로 정의
  • 2. 집합에 구현될 Aggregate 인터페이스 정의. 이 안에는 반복자를 반환하는 팩토리 메소드가 존재해야함.
  • 3. 추상 팩토리 메소드를 상속 구현
  • 4. 정의한 Iterator, Aggregate 인터페이스를 이용하는 클라이언트 코드 작성

 

4-3 어댑터 패턴

• 문제: 클라이언트가 요구하는 인터페이스와 서비스가 제공하는 인터페이스가 다른 문제.

• 솔루션: 
  • 어댑터 클래스 작성: 서비스가 제공하는 인터페이스를 클라이언트가 기대하는 인터페이스로 변환.

 

4-4. 데코레이터 패턴

• 문제: 기본 클래스의 동작을 동적으로 추가하는 문제 해결

• 솔루션: 
  • 구성요소1: component 클래스(데코의 대상)
  • 구성요소2: 데코레이터(확장 기능이 담겨있음)
  • 데코레이터 객체가 재귀 합성으로 component 객체 래핑

 

4-5. 팩토리 메소드 패턴

• 문제: 클래스가 객체를 생성하는 책임을 분리.(객체 생성에 변화를 대비)

• 솔루션: 
  • 객체를 생성하기 위한 팩토리 메소드를 포함하는 추상클래스 정의

 

4-6. 추상 팩토리 패턴

• 문제: 구체적인 객체 생성을 지정하는 책임을 분리.

• 솔루션: 
  • 추상 인터페이스를 이용해 관련 객체 패밀리 생성.

 

4-7. 옵서버 패턴

• 문제: 데이터를 보관하고 있는 Subject가 그 데이터를 이용하는 옵서버와 효과적인 통신 + 느슨하게 결합하는 법

• 솔루션: 
  • Subject 클래스: observer 목록을 유지, 변경을 고지
  • Observer 클래스: 변경을 통지 받고 접근을 요청

•  

 

4-8. 상태 패턴

• 문제: 상태에 따라 객체의 동작을 변경해야하는 경우

• 솔루션: 
  • 객체가 가질 수 있는 모든 상태에 대해 새 클래스를 만들고, 모든 상태별 동작을 상태 클래스에 몰아 넣음.

왼: 안좋은 예, 오: 올바른 예

 

7-4 아키텍처 평가

1. 아키텍처 평가

: 아키텍처의 속성, 강점, 약점을 결정하는 방법.

• 방법1: SAAM - 시나리오 기반 평가 방법
• 방법2: ATAM - 여러가지 품질 속성에 초점을 맞춰 평가

 

1-1. SAAM(Software Architecture Analysis Method)

• 아키텍처가 시나리오를 실행할 수 있는지 여부 결정.
• 실행 못했으면, 아키텍처 변경에 필요한 사항 나열 및 변경 비용 추정.

• 직접 시나리오: 시스템의 변경이 요구되지 않는 시나리오(일반적인 요구사항에 대한 아키텍처의 지원 평가)
• 간접 시나리오: 시스템의 변경이 요구되는 시나리오(새로운 기능 지원하는지 평가)

 

1-2. ATAM(Architecture Trade-off Analysis Method)

• 품질 속성에 초점을 두고, 시나리오에 기반해 아키텍처 분석.
• 평가 후 아키텍처 절충안 찾음.
• 아키텍처 내부 리스크 발견

 

7-5 아키텍처 문서화

1. 아키텍처 문서

• 구현 전 설계 이슈 발견 가능
• 설계 검토, 개선
• 의사소통 수단

 

2. 아키텍처 문서구조(5)

• 목적
• 우선순위
• 최상위 설계 - 최상위로 추상화된 설계 작성(패키지 다이어그)
• 주요 설계 이슈
• 설계 상세 사항