7. 아키텍처 설계 2

• 아키텍처
• 아키텍처 패턴
• 아키텍처 문서화

 

---

아키텍처

 

 

• 아키텍처

→ 시스템의 구조와 구성요소 간의 상호작용을 정의하거나 전반적인 구조를 설계하는 과정

→ 소프트웨어를 서브 시스템으로 분할

→ 설계의 핵심으로 소프트웨어 엔지니어 전부가 이해하고 있어야 함

→ 시스템 전체의 효율성/재사용성/유지보수성을 결정

→ 논리적 구성을 기반으로 정의되는 시스템의 상세 설계도

→ 이해 당사자들의 요구 사항을 고려해 정의하며, 당사자들과 이해, 협상, 동의 및 의사교환을 위한 도구

 

• 아키텍처의 중요성

→ 소프트웨어 시스템의 이해를 용이하게 함

→ 시스템 일부의 독립적 작업을 가능하게 함

→ 시스템 확장의 준비 / 재사용성 증진

 

• 좋은 아키텍처 모델

→ 논리적인 분할 / 서브 시스템 사이의 인터페이스

→ 컴포넌트 사이의 동적 인터렉션 / 서브시스템 사이에 공유하는 데이터

→ 컴포넌트가 런타임에 존재하는 위치

 

• 아키텍처 모델의 개발

1. 컴포넌트들의 상호작용 / 인터페이스 방법을 찾음

2. 컴포넌트 사이에 자료와 기능 분배를 결정

3. 현재 프레임워크를 재사용 가능한지, 프레임 구축이 가능한지 결정

4.. 사용사례를 보며 아키텍처를 수정한다.

 

• 패키지 다이어그램

→ 패키지 : 공통적인 특성을 가진 클래스들의 모임 / 재사용의 단위

→ 점선 화살표 : 의존관계 / 컴파일 타임에 바인딩 됨을 의미

 

• 배치 다이어그램

→ 시스템의 소프트웨어 및 하드웨어 컴포넌트의 물리적인 설치 관계를 나타내는 다이어그램

→ 노드 : 컴퓨팅 유닛 / 링크 : 시스템의 통신 경로

 

 

 

---

아키텍처 패턴

 

 

•  아키텍처 패턴

→ 소프트웨어 구조의 유형

→ 설계 원칙과 지침을 제공 / 시스템의 요구사항에 대한 해결방법 제시

→ 컴포넌트를 이용해 융통성 있는 시스템 설계를 도와준다.

 

• 아키텍처 패턴의 종류 

1-1. 계층구조 스타일

→ 하나의 층 바로 아래 있는 층만 서로 커뮤니케이션

→ 복잡한 시스템은 층을 포개어 구성

→ 상위층에서는 하위층을 하나의 서비스로 여긴다.

→ UI 를 위한 별도의 층을 갖는다.

 

1-2. 계층구조 스타일의 설계원리 ( 설계원리를 어떻게 만족하는가 - 설계원리는 6. 아키텍처 설계 1 참조)

→ 분할정복 : 분리된 계층은 서로 독립적

→ 응집도 증진 : 계층 응집도

→ 결합력 감소 : 잘 설계된 하위층은 상위층에 대해 알지 못하고, 층 사이에는 API 를 통한 커넥션이 이루어짐

→ 추상화 : 하위층이 어떻게 구현되었는지 몰라도 됨

→ 재사용성 : 하위층의 범용적 설계 / 다른 곳에서 개발된 층의 재사용

→ 융통성 : 상위층의 교체 / 하위층에 기능 추가

→ 노후 예측 : 컴포넌트를 분리된 층에 고립

→ 이식성 : 특정 플랫폼에 의존된 부분을 하나의 계층에 격리

→ 테스트 가능성 : 각 층을 분리 테스트

→ 방어적 설계 : 각 층에서 API 를 assertion 체크로 구축

 

2-1. 클라이언트 서버 스타일

→ 커넥션을 기다리고 처리해 주는 하나의 서버 존재

→ 서비스를 제공받기 위해 커넥션을 시도하는 하나의 클라이언트 존재

→ peer-to-peer : 여러 호스트에 분산되어 있는 여러 소프트웨어 컴포넌트로 구성됨

 

2-2. 분산 시스템의 설계 원리

→ 분할 정복 : 클라이언트 – 서버로 분리하고 별도로 개발

→ 응집도 증진 : 서버가 클라이언트에게 응집도 높은 서비스를 제공

→ 결합력 감소 : 단순 메시지를 교환하는 유일한 통신 채널

→ 추상화 : 별도의 분산 컴포넌트를 이용한 추상성

→ 재사용 확대 : 분산 시스템을 구축하기 위한 좋은 프레임워크

→ 융통성 : 서버와 클라이언트를 추가하는 것만으로 시스템의 쉬운 재구성

→ 이식성 : 서버를 이식하지 않고 클라이언트를 새 플랫폼에 올리는 것이 가능

→ 테스트 가능성 : 서버와 클라이언트의 별도 테스트

→ 방어적 설계 : 메시지 처리 코드의 엄격한 체크 

 

3-1. 브로커 스타일

→ 여러 노드에 투명하도록 소프트웨어 시스템을 분산

→ 원거리에 있는 객체의 메소드 호출 가능

→ CORBA 표준 사용

 

3-2. 브로커 스타일의 설계 원리

→ 분할정복 : 원격객체의 독립적 설계

→ 재사용성 : 다른 시스템도 사용 가능한 원격 객체를 설계하고 재사용

→ 융통성 : 필요에 따라 브로커의 변경 / 프록시가 다른 원격 객체와 통신 가능

→ 이식성 : 동일 브로커를 접근하는 새로운 플랫폼을 위한 클라이언트 작성 가능

→ 방어적 설계 : 원격 객체에 대한 ASSERTION 체크

 

4-1. 트랜젝션 처리 스타일

→ 연달아 들어오는 입력을 하나씩 읽는다

→ 트랜젝션 : 시스템에 저장되어 있는 데이터를 조작하는 명령들

→ 각 입력은 트랜젝션을 명시한다.

→ 트렌젝션을 어디서 처리할 지 나타내는 트랜젝션 사령 컴포넌트 존재

→ 사령 컴포넌트는 프로시저 호출 or 메시지를 트랜젝션을 처리할 컴포넌트에 배치

 

4-2. 트랜잭션 처리 스타일의 설계 원리

→ 분할 정복 : 트랜젝션 처리기는 분리된 하나의 단위

→ 응집도 증진 : 트랜젝션 처리기는 원래 응집된 단위이다

→ 결합력 감소 : 처리기에서 사령 컴포넌트를 분리함으로써 결합도 감소

→ 융통성 : 새로운 트랜잭션 처리기의 쉬운 추가

→ 방어적 설계 : 트랜잭션 처리기와 사령 컴포넌트에 assertion

 

5-1. 파이프 필터 스타일

→ 단순한 데이터 스트림이 프로세스에 차례대로 전달

→ 파이프라인으로 데이터 주입

→ 프로세스의 병렬적 실행

→ 아키텍처의 높은 융통성 : 모든 컴포넌트가 삭제/대치/추가/순서재배치 가능

 

5-2. 파이프 필터 아키텍처 설계 원리

→ 분할정복 : 각 프로세스의 별도 설계

→ 응집도 증진 : 각 프로세스가 기능적 응집

→ 결합력 감소 : 각 프로세스의 단일 입출력

→ 추상화 : 파이프라인 컴포넌트들의 높은 추상성

→ 재사용성 : 프로세스가 다른 환경에서 재사용 가능 / 재사용 가능한 컴포넌트(프로세스)를 파이프라인에 추가 가능

→ 융통성 : 프로세스 순서의 유연한 재배치

→ 테스트 가능성 : 프로세스의 개별 테스트 가능

→ 방어적 설계 : 각 컴포넌트 입력의 엄격한 체크

 

6-1. MVC 스타일

→ 사용자 인터페이스를 시스템의 다른 부분과 분리하는 스타일

→ 모델은 사용자에게 보여주고 조작가능한 중요 클래스 인스턴스를 포함한다.

→ 뷰는 모델에 있는 데이터를 사용자 인터페이스에 보여준다

→ 제어부분은 사용자가 모델과 뷰를 인터렉션하는 것을 제어하는 객체를 포함한다

→ 옵서버 패턴이 뷰로부터 모델을 분리하는데 사용된다.

 

6-2. MVC 스타일의 설계 원리

→ 분할 정복 : 세 가지 컴포넌트의 독립적 설계

→ 응집도 증진 : 뷰와 제어부분이 단일 UI 계층에 같이 존재

→ 결합력 감소 : 세 컴포넌트 사이의 통신 채널의 최소화

→ 재사용 : 뷰와 제어 부분의 재사용 가능

→ 융통성 : 뷰 , 제어의 쉬운 변경을 통한 UI 갱신

→ 테스트 가능성 : 애플리케이션을 UI 와 분리하여 테스트 가능

 

 

---

아키텍처 문서화

 

 

 

• 아키텍처 문서화

→ 문서는 더 좋은 설계를 위한 도우미 역할을 한다.

→ 구현을 시작하기 전에 중요한 설계 이슈를 찾게 해준다.

→ 참여 그룹은 설계를 검토 및 개선

→ 문서는 설계 구현자 – 설계 수정자 – 설계를 바탕으로 한 새로운 시스템 개발자 사이에 커뮤니케이션 수단이 된다.

 

• 문서 구조

→ 목적 / 우선순위 / 아웃라인 / 주요 설계 이슈 / 상세 사항

→ 목적1 : 문서가 기술하는 시스템이 무엇인지 기술

→ 목적2 : 설계가 다루고 있는 요구 사항에 대한 참고문헌 소개

→ 우선순위 : 설계 작업 과정을 설명할 우선순위 기술

→ 아웃라인 : 개괄적인 소개를 하기 위하여 최상위로 추상화된 설계 제시

→ 설계 이슈 : 해결되어야 할 중요한 이슈 / 고려해야 할 대안, 최종결정, 결정 이유 기술

→ 상세 사항 : 언급되지 않은 것 중 독자가 꼭 알아야 할 사항