아키텍처 설계 - 패키지 다이어그램, 유형, 디자인 패턴

<분석에서 설계로>

> 분석단계

- 시스템에서 무엇이 가능한지를 찾아냄

● 목적 : 비즈니스 요구가 무엇인지 찾아냄

> 설계단계

- 분석 단계에서 모은 요구를 반영하여, 미래 시스템을 위한 설계 도면 작성

구현이 가도록 시스템의 도면 만듦
시스템 통합, 자료변환, 기술 ... 'HOW'의 관점으로 생각

● 목적
어떻게 구축할 것인지를 결정
분석 모델의 집합을 설계로 발전시켜 나감

아키텍처 설계

- 시스템의 구조적인 요소와 관계 결정 작업

클래스, 메소드 -> 모듈로 구성 ->
모듈 사이의 인터페이스 정의

분석단계에서 찾아낸 클래스와 메소드를클래스 묶음(패키지)로 정리패키지 사이의 인터페이스 정하기

데이터베이스 설계

- 자료를 저장할 데이터베이스에 대한 상세한 데이터 모델 작성

개념적 스키마 작성
테이블
인덱스

UI 설계

- 사용자가 시스템과 상호작용하기 위한 방법을 포함하고 있는 UI를 설계

객체지향 관점의 설계

- 분석 단계에서 찾아낸 도메인 클래스에 아키텍처 생성하고, 나머지 설계 클래스 찾는 작업

---

<설계의 개념과 원리>

- 분석단계에서 파악한 요구를 구현 가능한 설계안으로 바꾸는 작업

개념적 -> 구체적
프로그램과 가까운 실제적인 것

> 작업

• 컴포넌트의 발견
• 설계안의 선택 (가장 최적의 설계안 선택)
• 충분한 상세 설계 도면 작성

바람직한 설계

• 복잡성 최소화
• 편리한 유지관리
• 느슨한 결합
• 유연한 구조

● 복잡성 최소화

복잡함 최소화 -> 단순화
추가적인 설명이 필요한 복잡한 구조 피하기
시스템을 몇 개의 큰 덩어리로 분할

● 편리한 유지관리

시스템은 한번 릴리스 한 후에도 계속 변경되고 진화함
-> 편리한 유지 관리 필수

모듈화
밀접한 관련된 부분을 함께 덩어리로 만들어 -> 컴포넌트화

● 느슨한 결합

모듈간의 연결을 최소화
정보 은닉 원리 적용
-> 내부의 모든 자세한 작업 숨기고, 외부 클라이언트에게는 인터페이스 제공 -> 그것만 쓰게 만듦
테스트, 유지보수시 작업 줄일 수 있음

● 유연한 구조

내부구조를 해치지 않고 확장할 수 있는가
변경될 것 같은 부분을 찾아 고립시킴
-> 자주 바뀌는 부분은 별도의 클래스로 분류, 고립 -> 외부에 영향 X 인터페이스 설계
동적 바인딩 패턴을 이용하여 바인딩 타임 늦춤
다형성(프로그램 언어 각 요소들이 다양한 자료형에 속하는 것이 허가)

설계 수준

표현하려는 내용이 다 표현되었는지 확인
다른 다이어그램에도 동일하게 표현되었는지 확인

> 서브시스템, 패키지 수준 설계

- 서브시스템 사이에 알아야할 필요성이 있어야 커뮤니케이션 가능하게

직접 커뮤니케이션 X -> 중간 제어 역할을 하는 모듈 효과적
서브시스템이나 패키지로 어떻게 분할할 것인지
분할된 모듈 사이에 어떤 식으로 인터페이스하고 사용할지 결정

> 클래스 수준 설계

패턴이 중요, 자주 출현좋은 설계 조각의 모임

● 옵서버(observer) 패턴

자주 변경되는 자료를 가진 클래스와 이런 자료를 이용하는 클래스 사이의 효과적인 협력방법

---

<설계 표현 방법>

- 시스템의 아키텍처(계층 / 모듈)는 패키지 수준으로 나타냄
클래스와 패키지의 의존관계 파악하는 것 -> 시스템 유지보수에 매우 필요

패키지

클래스를 포함하는 컨테이너
분할된 덩어리
패키지 다이어그램(UML)로 표현

> 요소

패키지 다이어그램의 관계 : 의존관계
두 패키지 사이에 존재하는 변경 의존 관계

의존하는 -> 의존 당하는

● 의존관계

- 한쪽이 익스포트(export)한 것을 다른 한쪽의 패키지 요소가 임포트(import)하는 관계

점선 화살표
양방향 점선 화살표 -> 양방향 의존 관계
한 패키지에서 다른 패키지에 있는 클래스를 최소한 하나 사용

> 패키지 다이어그램 그리기

수십, 수백 개의 클래스를 패키지, 계층화
대규모 시스템을 분할하여 관리하기 좋은 덩어리로 제공
분할 & 계층화 작업 도와줌

1. 범위 지정
2. 공통의 관게를 기반으로 클래스를 패키지로 묶음
3. 묶은 클래스를 패키지로 모델링
4. 패키지 사이의 의존관계 찾음
5. 패키지 사이의 의존관계 표시

> 패키지 표기법

> 단순 표기법

> 확장 표기법

(a) 패키지와 함께 클래스 표현

(c) 패키지 안에 패키지를 경로만 표현

> 중첩된 표기법

(b) 클래스 이름만 나타내고, 가기성 표현

(d) 패키지 안에 패키지를 단순표기법으로 포함하여 표현

---

<아키텍처>

> 추상화

- 대상에 대하여 특정 목적에 관련된 정보에 집중, 나머지 정보 무시하는 관점
소프트웨어 개발시 프로시저 개수 많아지면 전체 한번에 작업 / 생각 어려움 -> 해결책 : 추상화
복잡성을 줄이고 복잡한 소프트웨어 시스템을 효율적으로 다루고 구현
문제 분할의 근본

• 분할 : 복잡한 시스템을 구성요소로 자르는 과정

이들 요소간 상호작용 걸정, 외부에 보이는 동작을 잘 나타내는 추상화 필요

> 소프트웨어 아키텍처

- 소프트웨어 시스템에서 높은 추상 수준의 구성요소, 구조와 구성요소의 관계, 연결 우형 및 상호작용
소프트웨어 개발 모든 단계에 영향
시스템이 잘 가동될 것인지의 성패 판가름

● 계층적 분할

상세수준에 따라 나누어 표현된 컴포넌트를 더 자세히 나타내기 위해 분할

결합

- 모듈간의 상호의존도
좋은 소프트웨어 - 낮은 결합력
결합이 높으면 변경시 파급력 높아짐 (하나의 모듈 잘못 작동 -> 관련된 모듈 전반에 오류 전파)

> 모듈간 결합 정도

제어정보를 전달해야 한다면 모듈의 동작이 다른 모듈에서 생성하여 전달된 제어정보에 좌우 -> 이해, 추상성 어려워짐
이름으로 서로 연결되고 간단한 정보를 파라메터로 넘기는 경우 -> 결합 낮음

> 모듈 사이의 결합 정도 단계

• 내용 결합 : 한 모듈이 다른 모듈의 내용 직접 참조
• 공통 결합 : 한 모듈이 다른 모듈이 읽은 전역변수 값을 쓰거나 변경한 경우 다른 모듈의 전역 변수를 이용하여 데이터 교환하는 경우
• 제어 결합 : 한 모듈이 다른 모듈의 제어흐름 경로 결정
• 스탬프 결합 : 복합 데이터의 일부만 사용하는 모듈에 복합데이터 구조를 전달
• 데이터 결합 : 모듈들이 주고받는 매개변수가 간단한 타입

응집

- 하나의 모듈 안에서 수행되는 작업들이 서로 관련된 정도
설계 단위들이 특정 작업을 수행하기 위해 잘 모여있는지
모든 요소가 하나의 기능 단위로써 협동하는 정도로 정의

● 높은 응집력 : 코드의 단위 안의 요소들이 서로 관련 있는 것을 한 곳에 넣고 유지
높은 응집이 좋음 -> 단일 책임을 갖게 하면 모듈안의 응집력 높아짐

● 낮은 응집력 : 단위 안의 요소들이 의미적으로 아무 관련이 없는 경우
모듈 기능을 한마디로 요약할 수 없다면 여러가지 기능이 복합되어 있어 응집이 낮다고 볼 수 있음

---

<아키텍처 설계 요소와 방법>

- 아키텍처 설계 작업 : 시스템을 관리하기 쉬운 크기로 분할, 이들 사이의 관계 정의

분석단계 초점	설계단계 초점
시스템의 목적과 기능	시스템의 구조와 구성요소 데이터 구조 및 구현에 필요한 하드웨어 소프트웨어 컴포넌트

> 설계 작업 요소 비교

> 아키텍처 설계 과정

제약사항들을 만족시켜서서브시스템과 이들 사이의 인터페이스 정하는 일

설계 목표

개발할 시스템이 초점을 두어야할 품질 목표

• 성능 목표
• 신용도
• 사용자 목표
• 비용 목표
• 유지보수 목표

● 성능 목표

● 신용도

시스템이 얼마나 믿을만 한가

● 사용자 목표

● 비용 목표

● 유지보수 목표

서브시스템

- 설계 단계에서 솔류션을 포함하여 시스템을 분할한 것
응용 도메인의 복잡도를 줄이기 위하여 작은 부품인 클래스를 패키지로 그루핑하여 구조화
단일 팀이 다룰 수 있는 작업의 규모

서비시스템 특징은 다른 서브시스템에게 어떤 서비스를 제공하는가에 의해 결정

• 서비스 : 공통된 목적을 추구하는 관련된 오퍼레이션 집합

인터페이스

- 프로그램간 상호작용하는 곳
서비스를 부르는 프로그램 사용(오퍼레이션 이름, 파라메터)
서브시스템 -> 다른 시스템 : 인터페이스 형태로 서비스 제공
오퍼레이션의 이름, 파라메터, 타입, 리턴값 포함

시스템 설계는 각 서비시스템이 제공하는 서비스를 정의하는데 초점

API 제공, 파라미터와 리턴값 타입 포함
-> 인터페이스에 더욱 집중

내부 구현 관계 (X) < 사용자 접점 (O)
서비스를 사용하는 입장에서 쉽게 사용

인터페이스 작성시 구현에 관한 정보를 제공하는 부분 최소화

> 인터페이스 구현의 분리 원칙

- 컴포넌트의 공개 인터페이스를 컴포넌트가 어떻게 구현되는지 상세하게 나타낸 것과 분리
-> 인터페이스와 분리된 구현 쉽게 변경 가능

컴포넌트

- 프로그래밍에 있어, 재사용 가능한 독립된 모듈
소프트웨어의 재사용의 중요성, 필요성 때문에 나온 기술
독립적인 기능 수행, 추후에 교환
배포 가능

컴포넌트 세부 사항은 겉으로 드러나서는 안 된다
패키지화 될 수 있어야 함
소스가 아닌 실행코드 기반으로 이미 구현이 완료되어야 함
컴포넌트의 유형, 용도, 기술, 인터페이스에 대한 명세가 되어 있어야 함

> 컴포넌트 다이어그램

- 컴포넌트 모델링, 컴포넌트의 인터페이스 표현

• 제공하는 인터페이스 : 시스템이 무엇을 할 수 있는지 - 외부에 나타냄
• 요구하는 인터페이스 : 시스템 내부를 구현하기 위해 - 외부에 요청하는 서비스에 대한 인터페이스

제공하는 인터페이스 : 막대 사탕 + 이름
요구하는 인터페이스 : 소켓 심볼

● 컴포넌트

탭이 달린 직사각형모든 컴포넌트는 반드시 이름 필요

컴포넌트가 패키지에 포함될 경우
컴포넌트 이름 앞에 패키지 이름 붙일 수 O컴포넌트 내부 동작 보여줄 수 O

● 인터페이스

- 컴포넌트와 인터페이스의 의존관계로 표현
- 실제로 동작하는 컴포넌트에 인터페이스를 적용하여 표현 (인터페이스 실체화)

의존관계
한 컴포넌트에 어떤 변경 발생 -> 그 변경으로 인해 다른 컴포넌트도 영향 받음
한 컴포넌트에 변경 발생 -> 그 변경의 범위를 추적해서 파악하고 싶을 때 유용

---

<아키텍처 유형(스타일)>

- 구조 유형, 스타일
시스템 분할, 전체적인 제어 흐름, 경계조건의 처리, 서브시스템 사이의 커뮤니케이션 프로토콜 유형에 따라
애플리케이션, 플랫폼, 도메인에 따라 다른 유형이 적합

시스템이 개발된 뒤에는 잘못된 구조를 바로잡기 쉽지 X

> 주요 아키텍처 유형

• 중앙저장소
• MVC
• Peer - to - Peer
• 3계층
• 4계층
• 파이프 필터

중앙 저장소

- 타 서브시스템들이 단일 중앙 저장소의 자료를 접근, 변경
공유된 자료가 중요한 시스템일 경우 채택
서브시스템들은 상대적으로 독립적
중앙저장소의 잠금을 이용하여 제어

ex) 급여 시스템, 은행 시스테과 같은 데이터, 개발환경

MVC (모델 / 뷰 / 제어)

● 모델 서브시스템

- 도메인의 지식을 저장 보관
데이터 상태에 변화가 있을 때 -> 제어, 뷰에 통보
-> 뷰 : 최신 결과 보여줌 / 제어 : 모델의 변화에 따른 적용 가능한 명령

● 뷰 서브시스템

- 사용자에게 보여줌
사용자가 볼 결과물을 생성하기 위해
모델로부터 정보 얻어오는 역할

● 제어 서브시스템

- 사용자와의 상호작용 관리
모델에 명령을 보냄 -> 모델 상태를 변경
관련된 뷰에 명령을 보냄 -> 모델의 표시 방법 변경

뷰, 제어가 모델보다 더 자주 변경될 수 있기 때문에 분리
모델 시스템은 여러 뷰, 제어 시스템에 의존되지 않도록 개발
여러 뷰를 통하여 시스템을 사용하는 대화형 시스템에 적합

사용자 인터페이스 -> 비즈니스 로직 분리
-> 애플리케이션의 시각적 요소, 그 이면에 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있음

사용자 인터페이스 담당 계층의 응집력 ↑
여러개의 다른 UI를 만들어 그 사이의 결합 ↓

클라이언트 서버

● 클라이언트

- 사용자로부터 입력을 받아 -> 서버의 데이터베이스 트랜잭션 구동 -> 필요한 모든 데이터 수집

● 서버

- 클라이언트에게 서비스를 제공
강력한 성능으로 자원 관리, 클라이언트가 요청하는 기능, 자원 제공
단일 사용자 시스템으로 자원의 사용을 위하여 서버를 접속하는 애플리케이션 존재
데이터 일관성 보장

클라이언트의 요청으로 트랜잭션 수행
많은 클라이언트 동시에 서비스 가능
클라이언트는 수천개의 여러 서버에 쉽게 접근

Peer - to - Peer

- 클라이언트 서버 유형의 일반화
각 서브시스템이 클라이언트, 서버로 동작 -> 서비스를 요청하거나 제공할 수 있음
서브시스템 안의 제어흐름 - 독립적으로 수행, 요청에 따라 동기화

ex) 블록체인 기술

3계층

- 계층형 스타일은 소프트웨어 기능을 수직으로 상호작용하는 여러 층으로 분할
각 층은 바로 위 / 아래 층에만 메시지를 보내고 받음

● 인터페이스 층

사용자와 관련된 경계 객체 포함

● 응용 로직 층

구현하는 제어 및 엔티티 객체 포함

● 저장 층

데이터베이스에 지속하여 저장하는 객체의 스토리지, 검색, 질의 구현

4계층

- 인터페이스 층 -> 프리젠테이션 클라이언트 층 / 프리젠텡이션 서버층 분리
3가지 클라이언트에 공유되는 폼은 프리젠테이션 서버 층에서 정의하고 제공됨
-> 클라이언트에서 중복될 염려 X

● 프리젠테이션 클라이언트 층

사용자 컴퓨터에 위치

● 프리젠테이션 서버 층

하나 이상의 서버에 올림

● 응용 로직 층

구현하는 제어 및 엔티티 객체 포함

● 저장 층

데이터베이스에 지속하여 저장하는 객체의 스토리지, 검색, 질의 구현

ex) 웹브라우저, 현금자동인출기, 직원을 위한 애플리케이션

파이프 필터

- 서브시스템은 입력 집합으로부터 데이터를 받아 다른 서브시스템에 결과를 출력으로 보냄
필터 사이에 데이터를 이동시키며 단계적으로 처리하는 구조
데이터느 파이프를 통해 단방향으로 흐름

서브시스템 = 필터
서브시스템 사이 = 파이프

ex) UNIX Shell(쉘), 컴파일러

---

<디자인 패턴>

- 모듈 간의 관계 & 인터페이스 설계할 때 참조할 수 있는 전형적인 해결 방식 / 예제
구성 : 문제 및 배경, 실제 적용된 사례, 재사용 가능한 샘플 코드 ...
문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 효율적임
디자인 패턴의 이름, 문제, 해결책, 결과의 요소 가짐

> 디자인 패턴 요소

• 이름 : 다른 패턴과 구별할 수 있는 고유한 이름
• 문제 : 패턴이 사용되는 상황을 설명한 문제 설명
• 해결책 : 협력 클래스와 인터페이스 집합
• 결과 : 설정한 설계 목표에 따라 고려된 저울질과 대안들 기술

> 디자인 패턴 혜택

• 쉽게 재사용 가능
• 설계 작업 쉬워짐
• 디자인 논의위한 의사소통 쉬움
• 객체지향 설계 원리를 잘 따르게 됨

> 디자인 패턴 종류

• 추상팩토리, 빌더, 팩토리 메소드, 싱글톤
• 어댑터, 브리지, 컴포지트, 데코레이터, 퍼싸드, 플라이웨스트, 프록시
• 옵서버, 전략, 책임 연쇄, 커맨드, 인터프리터, 반복자, 중재자, 메멘토, 상태, 템플릿 메소드, 방문자

어댑터 패턴

- 어떤 클라이언트가 요구하는 인터페이스와는 다른 인터페이스를 가진 서비스가 있는 경우 사용
사용 가능한 서비스의 인터페이스를 클라이언트가 예쌍하는 인터페이스에 맞게 조정
자료구조의 반환 동작은 어댑터 클래스에서 이뤄짐
어댑터 클라이언트에서 예상하는 대로 동작
어댑터를 활용함으로써 수정될 필요가 없기 때문에 쉽게 재사용 가능

브리지 패턴

- 구현부에서 추상층을 분리, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
점증적으로 통합되는 서브시스템
완성되기 전에 스텁(stub) 사용

• 스텁 : 특정 서브시스템이 완성되지 않을 때 대치하는 모조 버전

서브시스템을 여러 버전으로 만들어야 하는 경우
여러 다른 버전에 대하여 동일한 인터페이스를 가지고 동적으로 갈아 끼울 수 있게 하는 해결책

추상 팩토리 패턴

- 여러 생산자가 만든 장치를 혼합하여 사용하는 경우,
클라이언트는 주어진 패밀리에 대한 부품 생성을 추상팩토리에 맡김
클라이언트가 구체적인 객체 생성 지정 X
관련된 구상 클래스들을 지정하지 않고도 관련 객체들의 모음을 생성할 수 있음 => 생성패턴
클라이언트는 추상팩토리에는 연결되지만, 구체적인 특정 팩토리나 프로덕트와는 느슨하게 연결

콤포지트 패턴

- 여러 객체를 가진 복합 개체와 단일 객체를 구분없이 다루고자 할 때 사용
전체 - 부분의 관계를 갖는 객체들 사이의 관계 정의 유용
객체들을 트리구조로 구성하여 복합 객체 안에 복합 객체가 포함되는 구조 구현
클라이언트가 복합 객체 / 단일 객체를 동일하게 취급하는 것 목적

콤포지트는 하나 이상의 유사한 객체를 구성으로 설계된 객체
클라이언트 -> 콤포넌트 부름
콤포넌트는 Leaf와 composite 자식으로 가짐
operation의 구현은 자식들이 함
composite는 compoenet를 집합으로 가짐

---

참고 도서 : 최은만, UML로 배우는 시스템분석설계, 생능출판사, 2020년 3월 (제2판)