Ch06. 아키텍처 설계

▶6주차 필기 내용

Ch06. 아키텍처 설계

📌 소프트웨어 공학 10판- 한티미디어

[아키텍처 설계]

• 시스템 전체 구조 설계
• 시스템 주요 구조 컴포넌트(subsystem)들과 상호작용하는 컴포넌트 간의 관계

[아키텍처 변경]

• 아키텍처 변경 비용 많이 듬
• 애자일 개발 초기 단계는 아키텍처 설계에 초점 맞춰야 함
• 컴포넌트 리팩토링은 비교적 쉽지만 아키텍처의 점진적 개발은 바람직 X

[아키텍처 설계와 요구공학 프로세스의 중첩]

• 이상적으로는 요구사항 명세에 설계 포함 X
• 요구공학 프로세스의 일부로서 추상 시스템 아키텍처가 제시되어야 함

[아키텍처 요구사항]

• 시스템의 개별 컴포넌트가 ‘기능적’ 요구사항을 구현
• 시스템의 아키텍처는 ‘비기능적’ 요구사항에 영향을 줌

[아키텍처 명시적 설계와 문서화의 장점]

• 상위 수준 시스템 표현으로 이해당사자 간 의사소통에 도움
• 시스템의 중대한 비기능적 요구사항(성능, 신뢰성, 유지보수성) 만족시킬 수 있는지 분석
• 비슷한 요구사항 가진 시스템 아키텍처 재사용

---

6.1 아키텍처 설계 결정

[아키텍처와 비기능적 특성 간 관계]

1) 성능(performance)

• 컴포넌트 간 통신을 줄임, 시스템 중복, 부하 분산

2) 보안성(security)

• 중요한 자산을 가장 안쪽 계층에 두는 계층 구조 사용

3) 안전성(safety)

• 안전 관련 작업을 소수의 컴포넌트에 배치하여 안전 검증과 대응 간단히 함

4) 가용성(availability)

• 중복 컴포넌트 배치, 시스템 중단 없이 컴포넌트 교체 및 갱신

5) 유지보수성(maintainability)

• 변경이 용이한 독립적 컴포넌트 사용

---

6.2 아키텍처 뷰

[ 4+1 뷰 모델] : 시스템 아키텍처를 여러 개의 뷰로 바라봤다.

1) 논리적 뷰

• 시스템의 논리적 구조 보여줌. 클래스 다이어그램 등

2) 프로세스 뷰

• 시스템의 프로세스/쓰레드의 런타임 상호작용을 보여줌
• 성능, 가용성 등 비기능적 시스템 특성과 관련

3) 개발 뷰

• 소프트웨어가 개발을 위해 어떻게 분해되는지 보여줌

4) 물리적뷰

• 시스템 하드웨어와 소프트웨어 컴포넌트들의 배치 보여줌

5) 유스케이스 뷰

• 시스템의 행동(유스케이스 시나리오)를 액터 관점에서 보여줌

---

6.3 아키텍처 패턴

[패턴]

• 자주 발생하는 문제에 대한 해법
• 지식 공유, 재사용 목적
• Gamma 등 객체 클래스 설계 패턴 널리 알려짐
• 이름, 설명, 문제, 해법 등으로 구성

[아키텍처 패턴]

• 아키텍처 스타일이라는 이름으로 제안됨
• 해당 영역에서 성공적이고 바람직한 시스템 구조 사례를 추상화
• ex. 모델 뷰 제어기(MVC : Model-View-Controller)

[MVC 패턴]

▸설명

• 데이터로부터 표현과 상호작용 분리시켜, 3개의 논리적 컴포넌트로 구조화
• 모델: 데이터와 이에 대한 오퍼레이션 관리
• 뷰: 사용자에게 데이터 표현 관리
• 제어기 : 사용자 상호작용 관리하고 이를 뷰와 모델에 전달

▸언제 사용

• 데이터 표현과 상호작용 방법이 여러 가지일 때 사용

▸장점

• 데이터 표현과 무관하게 데이터 변경 O
• 동일한 데이터를 서로 다른 방식으로 표현하는 것 지원.
• 뷰의 추가/변경 쉬움

▸단점

• 데이터 모델과 상호작용 단순한 경우, 불필요하게 코드만 복잡해짐

[아키텍처 패턴]

(1) 계층 아키텍처 (.. 그냥 넘어감)

▸설명

• 각각의 기능을 ‘계층’ 단위로 분리하여 전체 시스템을 구성
• 각 계층은 상위 계층에 서비스를 제공함

▸언제 사용

• 기존 시스템에 ‘새로운 기능’ 구축할 때
• 계층별로 분리하여 여러 팀이 각각 독립적으로 개발할 때
• 다중 수준 보안 필요할 때

▸장점

• 시스템 확실성 높이기 위해, 중복된 기능 제공할 수 O
• 인터페이스 동일하면 계층 대체 가능 O

▸단점

• 계층 명확 구분 어려움
• 불필요하게 모든 계층 처리를 거치며 성능 저하될 수 있음
• (2) 저장소 아키텍처

▸대량 데이터 사용 시스템은 ‘공유 데이터베이스(저장소) 중심으로 구성된다.

▸저장소를 중심으로 ’컴포넌트(도구)‘들을 배치

• 공통 저장소 데이터 모델(스키마) 구조를 따라야 함
• 효율적으로 대량 데이터 공유. 저장소에서 데이터를 저장/인출

▸장점

• 컴포넌트들이 독립적이라 다른 컴포넌트 알 필요 X
• 데이터 일관성 있게 관리 가능O

▸단점

• 통신이 저장소에 집중되어, 저장소에 문제 발생 시 -> 시스템 전체 영향을 줌
• (3) 클라이언트-서버 아키텍처

▸분산 네트워크 환경에서 ’클라이언트-서버‘ 아키텍처는 주요 아키텍처

▸클라이언트 서버 아키텍처의 컴포넌트

• 서비스 제공 서버(프로세스) 집합
• 서비스 요청 클라이언트(프로세스) 집합
• 클라잉언트와 서버 연결 네트워크

▸클라이언트와 서버 연ㅇ결

▸특징

• 분산 아키텍처이므로 서버 추가/통합/업그레이드 쉬움
• 네트워크 성능이 시스템 성능에 영향 줌. 서비스 거부 공경(Dos)에 취약
• (4) 파이프 필터 아키텍처

▸파이프 필터 아키텍처

• 입력 데이터를 기능적 변환 처리하여 출력 데이터 생성
• 데이터가 변환을 통해 흘러감
• 변환이 순차적/병렬적으로 실행

▸변환 재사용 쉽고, 일괄처리 시스템에 적합

---

6.4 애플리케이션 아키텍처

[애플리케이션 아키텍처] //그냥 읽고 넘김

• 비즈니스 영역에 따라 사용되는 애플리케이션 시스템은 공통점 있음
• 같은 유형의 시스템 개발 시 공통적인 아키텍처 구조가 재사용됨
• [1. 트랜잭션 처리 시스템] // 대충 설명 후 넘김

[트랜잭션]

• 원자성을 가지며, 트랜잭션 수행되면 트랜잭션 내 모든 작업들이 완료되어야 함
• cf. 데이터페이스 트랜잭션 ACID
• 예시) 은행 계좌 이체

[트랜잭션 처리 시스템]

• 데이터베이스에 있는 정보에 대한 (사용자 요청/갱신 요청) 처리 위해 설계됨
• 사용자 서비스 요청을 비동기적 처리하는 대화식 시스템

[트랜잭션 처리 위한 미들웨어]

• TP(Transaction Processing) monitor
• Application Server :WAS, Aapche Tomcat, WebLogic. Jeus 등
• [2. 언어 처리 시스템] //대충 설명 후 넘김