[소프트웨어 분석 및 설계] 10. SW Architecture Design

다음 4가지 순서로 배울 것임.

 

1) SW Architecture 소개 

2) Architecture Styles - 디자인 패턴 같은 거를 배움, Reusable Design임.

3) Architecture Viewpoints

4) Architecture Design for NFR - NFR이란? quality requirement(ex. security, reliability, efficiency 등)

 

SW Architecture?

: Architecture는 그냥 Structure(구조물)이다. SW Architecture는 요소(Component), 관계(Inter-component Relationship), 원칙(아키텍쳐가 어떤 컴포넌트와 그 관계들로 구성되어져 있는지)들을 지닌 시스템의 기본 개념 혹은 특징임.

SW Architecture의 요소, 관계, 원칙

 

OOAD(기능적 요구사항에 대해서 효과적으로 설계할 수 있는 기법) -> only Functional Requirement만 만족

SW Architecture -> Functional Requirement + Non-Functional Requirement 모두 만족

 

SW Acrhitecture Description(AD)

: SW Architecture를 설계한 문서

- 비기능적 요구사항까지 만족하게 설계되어 작성됨.

- AD는 시스템 전체에 대한 구조적 디자인이라 문서가 매우 길다.

- 구성요소:

1) Skeleton Architecture

-> Architecture Styles 지식을 알아야 함.

2) Design for Views

-> Architecture Viewpoints(각 View에 대한 가이드라인) 지식을 알아야 함.

3)Design for NFRs

-> NFR를 만족시키는 Architecture Tactics(기법) 

- 30+- Architecture Styles

- 7 Viewpoints

- SW Quality Model, Tactics

 

Architecture Design을 하기 위해선 우리가 알고 있는 기술 뿐만 아니라 이를 적용해서 설계할 수 있는 방법론이 필요함.

 

Architecture Styles

: 설계 명세로, 자주 발생하는 SW 구조적 문제들을 해결하기 위해 적용됨.

얘네들은 40여년 동안 개발되고 증명되어와서 신뢰해도 됨.

이렇게 많은데 이 중 일부만 공부할 것임.

Batch Sequential Architecture Style

: 데이터를 모아서 한번에 Ouput 처리하는 것.

ex. 월별 요금청구서

Pipe and Filter Architecture Style

: Batch와는 달리 pipe로 구성되어 앞에서 보내는 족족 pipe를 통해 넘어감. 이때 각 컴포넌트는 Filtering을 함.(필터링을 병렬로도 처리가 가능함.)

Shared Repository Architecture Style

: 공유 레포지토리(DB)를 두고 각 Data Accessor가 dataset들을 Read&Write하며 공유하는 형태. 이때 서로 공유하는 것은 효율적이긴 하나 업데이트된 값을 가져오려면 수동 접근을 해야 함. 이런건 좀 비효율적임.

ex. 은행 시스템

Active Repository Architecture Style

: 수동적인 메모리 공유 방식인 Shared Repository와 달리 자동적으로 datasets을 공유하는 방식임.

Layered Acrhitecture Style

: 각자 역할이 정해진 Layer들이 수직으로 구성된 형태로, 아래의 Layer는 위의 Layer에 Virtual Machine을 제공하기에 더 밑의 Layer 내용을 알 필요가 없음.

Model View Controller Architecture Style

: Layered와 비슷한데 3가지 Layer를 가짐.(Model, Controller, View)

N-Tier Architecture Style

: 네트워크로 연결된 티어들의 시스템 형태.

Client Server Architecture Style

:  두개의 tier(Client tier, Server tier)로 구성되어 있는 시스템 형태.

Server tier는 Client tier에게 공통 기능(common service)을 제공하고,

Client tier들끼리는 Server tier로부터 제공된 기능을 서로 공유할 수 있다.

Broker Architecture Style

: Client node와 여러 Server node들 사이에 Broker node가 끼어있는 것으로 높은 서비스 신뢰도와 QoS를 보장함. 이들 사이에 Broker node가 있기에 client와 server는 직접 상호작용하지 않음.

Dispatcher Architecture Style

: Broker와 비슷한데, Broker node 대신 Dispatcher node가 있음. 처음엔 Broker 처럼 굴다가 Client와 서버를 연결시켜주면 그때부턴 얘 안거치고 Client와 Server가 직접 통신함.

Microservice Architecture Style

: 현재 가장 널리 쓰이는 스타일로, Client와 Micro Service의 인터페이스가 서로 다를 경우 이걸 맞춰주는 역할(adapter)을 하는 gateway가 함.

- QoS 보장해줌(microservice A가 fail or 성능 저하 -> 다른 걸로 대체함)

- 개발 비용이 절감됨.

Publish and Subscribe Architecture Style

: Publisher와 Subscriber 사이에 Notification Broker가 있고 이를 통해 둘 사이를 연결해주기에 역할이 중요함.