* Software Architecture
- System을 구성하는 Sub-System을 분할 및 제어법, 통신법 식별
- 대부분의 System은 최초로 개발되는 것이 없다. > 이미 Architecture가 framework식으로 존재
- 본 단계의 결과물은 Software Architecture Design이다.
- 본 단계는 요구사항과 앞으로 일어나는 활동의 연결부분으로 중요한 역할을 한다.
- 본 단계는 Specification과 동시에 발생한다.
- 아키텍쳐는 큰 관점(in the large)으로 System, 독립적프로그램, 각 System간의 관계등을 정의
작은 관점(in the small)으로 클래스, 컴포넌트, 클래스 간의 관계등을 정의한다.
- 장점
> stakeholder communication 수단으로써 사용된다.
> System 분석이 가능하다
> 재사용하기 쉽다(large-scale reuse)
* 의사 결정 단계
- create process : 아키텍쳐에 대한 많은 지표가 있지만, 현 상황에 딱 맞는 아키텍쳐는 없다.
- 공통적읜 의사 결정 : 비기능적 요구사항도 함께 해결해야 한다.
ⓐ 사용할 수 있는 일반적은 소프트웨어 아키텍쳐가 존재하는가 살펴본다.
ex) 책 파는 site의 경우 일반적으로 의료를 파는 site와 architecture가 비슷할 것이다.
ⓑ 어떻게 System을 분산할 것인가?
ⓒ 아키텍쳐 스타일(패턴)선택 : 스타일을 통해서 대략적인 아키텍쳐가 생성된다.
ex) 건축에는 바로크, 모던, 전동 등의 다양한 스타일이 존재하며, 스타일을 선택하므로써 대략적인 구조가 나옴
ⓓ 어떤 식으로 구조화 할 것인가?
ⓔ System - subSystem - module(Component, object)간의 관계는 어떻게 할 것인가?
ⓕ 어떻게 이 아키텍쳐를 평가할 것인가?
ⓖ 어떻게 이 아키텍쳐를 문서화 할 것인가?
- ⓐ 단계에 대한 추가설명 : ⓐ 단계는 아키텍쳐 재사용과 간계가 되어 있으며, 같은 Domain에 속해 있다면
유사한 아키텍쳐를 가지고 있다.
※ Product line : 공장에서 제품을 만들 듯이 원하는 것을 선택하여 하나의 System을 생산
ex) e-commerce : Product line에서 원하는 것을 선택하여 새로운 아키택쳐를 생산할 수 있다.
* 아키텍쳐에서 비기능적 요구사항을 고려하는 이유
- 이 이유는 아키텍쳐 평과와도 밀접한 연관관계를 보인다.
ⓐ 성능 : sub-System을 너무 나누면(fine-grain component) 성능이 떨어 질 수 있다.
ⓑ 보안 : layered architecture를 적용할 것인가?
ⓒ 안전 : 하나의 System에 모아 놔야 좋다.(적은 수의 sub-system을 갖는 것이 좋다.)
ⓓ 가용성 : 똑같은 것을 여러개 가지고 있다.(redundant ↑)
ⓔ 유지성 : fine-grain component를 하는 것이 좋다.
- 서로 상충되는 것이 많은 것이 보인다. 즉, 답이 존재하지 않는다.
- 위 5가지를 보면, 아키텍쳐가 비기능적 요구사항과 밀접한 연관이 있다는 것을 알 수 있다.
* 문서화 방법
- (View or perspective)에 따라서 다르다
> 해결을 위해서 4+1측면의 View를 가지고 작성을 한다.
ⓐ logical view : 구성하고 있는 object, class를 보여준다.
package diagram, class diagram으로 표현하는 것이 좋다.
ⓑ process view : system / component의 상호작용을 보여준다.
sequence diagram으로 그려주는 것이 좋다.
ⓒ development view : 개발자의 편의를 위해 그려주는 것
component diagram으로 표현해주는 것이 좋다.
ⓓ A physical view : 물리적 상태를 보여준다.(network, hardware)
deployment diagram으로 그려주는 것이 효율적이다.
ⓔ (+ usecase or diagram)
img) deployment diagram // component diagram
* Architecture pattern / style
- 이미 다른 사람들이 해본 것으로 시도가 되고, 테스트가 된것을 pattern이라고 한다.
- 그림과 표를 이용해서 설명을 한다.
- MVC, Layered, Repository, Client-Server, Pipe & filter등의 대표적인 페턴이 존재한다.
ⓐ MVC(Model - View - Controller)
- UI, 상호작용, data를 나눠서 구현할 때 사용되며, model component(data 관리), view component(UI 관리),
controller component(상호작용 정의)로 나뉜다.
- 웹 기반 어플리케이션에 MVC가 많이 적용된다.
- MVC model은 하나의 Data를 여러개의 view로 보여주는 시스템 개발과 data의 표현 방식과 상호 통신법이
정해지지 않은 System 개발에 용의하다.
- 장점 : Data구조가 변해도 다른 Component(view, controller)가 변하지 않는다.
하나의 data를 여러개로 표현이 가능하다.
- 단점 : MVC가 섞여 있는 어플리케이션이 많이 존재하며, MVC를 나누므로서 더욱 복잡해 질 수 있다.
img) MVC
ⓑ Layered Architecture (Abstract Machine)
- System을 layer로 나눠서 분할하여 구현
- OSI 7 layer, internet 5 layer등이 대표적인 예로 들 수 있다.
- 존재하는 기능에 시스템을 올려 놓는 시스템 개발에 용이하다.
- 장점 : incremental development가 가능하다. (layer를 나눈후 각 layer를 따로 구현 가능)
유지 보수에 용이하다.(layer가 잘 나뉘어져 있다면, 한 layer의 변화는 바로위의 layer에만 영향을 줌)
- 단점 : layer를 나누는 것이 힘들고, performance가 좋지 않다.
- 어떻게 보면 layered architecture는 product line과 닮았다.
img) Layered Architecture
ⓒ Repository Architecture
- Repository : 단순히 생각하면, Global variable이다.
- 중앙에 큰 메모리를 공유하여, 서로의 data 통신을 원할하게 해준다.
- 각 component는 repository에 정보를 쓰거나 읽기만 하면된다. > component간의 통신은 불필요
- 큰 데이터 이동 및 큰 데이터 공유가 필요할 때 사용
- 장점 : Component 추가, 삭제가 편리하다.(하나의 component 변화가 전체에 영향을 주지 않는다.)
Data management가 편리하다.
Data가 변화하면 모든 Component가 변화를 인지 할 수 있다.
- 단점 : Repository가 잘못되면 System 전체에 오루를 끼친다.
데이터를 분산하기 힘들다.
img) Repository Architecture
ⓓ Client - Server architecture
- Client, Server 그리고 이 둘사이의 Network만이 중요하다.
- Server는 제공자로서 Client는 사용자로서 동작을 한다.
- 공유된 데이터를 멀리 있는 여러사람이 공유하기 위해서 사용된다.
- 장점 : Data를 분배하기 쉽다.
Client는 매우 편리하다.
- 단점 : System의 읜존성이 Server에 강하므로, Server가 고장나면 System이 동작하지 않는다.
성능이 Network상황에 읜존하므로 단언하기 힘들다.
Server 관리가 힘들다.
img) Client-Server architecture
ⓔ Pipe and Filter architecture
- Pipe : data flow // Filter : process
- process가 실행되면 그 output이 다른 process의 input이 되어 흘러가면서 실행된다.
- Interactive System에는 사용이 불가능하다.
- Unix의 shell이 동작하는 방식과 유사하다.
- 장점 : 이해하기 쉽고 filter 단위로 재사용이 가능하다.
sequential or concurrent system 모두에 적용이 가능하다.
많은 business model과 상통한다.
- 단점 : Output이 Input으로 들어가기 때문에 filter간 Data format을 같게해야한다.
img) Pipe and Filter architecture
* Application architecture
- Application category별로 pattern이 존재한다.
- Application architecture의 사용
> 아키텍쳐 디자인의 시작 지점
> 아키텍쳐 비교, 평가
> 개발 조직화
> 재사용의단위
> 의사소통의 수단
- Type
ⓐ Data processing application : 데이터 처리가 주(데이터 의존성이 많다)인 application(eg. excel)
ⓑ Transaction processing application : 데이터베이스 처리가 필요한 application(eg. 회사원 관리)
ⓒ Event processing system : Event 처리에 의해 동작하는 Application(eg. 핸드폰)
ⓓ Language processing system : 언어 처리 system(eg. compilers, interpreters)
* Transaction processing system
- 사용자의 요구, 요청을 DB에 의존하여 처리하는 System
- Transaction : 하나의 Data를 얻어오는(하나의 요청을 처리하는) 모든 과정
ⓐ Information System architecture
- Transaction processing system의 하위
- layered architecture로 이뤄져 있다.
ⓐ-1. Web based information System
- Client-server, layered architecture를 사용
- server와 client 컴퓨터의 개수에 따라서 layer가 달라진다.
ex) client <-> web server <-> application server <-> DB server
// web server : 사용자의 IO정보를 파악해 application server로 넘김
// application server : DB가 필요하다면 DB server를 검색, 아니면 event 처리후 web server로 전송
* Language processing System
- 자연언어 또는 생산된 언어(eg. UML)를 다른 언어로 표현해주는 System
ⓐ Compiler
- Components : lexical 분석기, symbol table, syntax 분석기, syntax tree, semantic analyzer, code generator
- Pipe & Filter, Repository Architecture를 사용
img) Compiler
