1. 소프트웨어의 청사진, Software Architecture의 개요
가. Software Architecture의 정의
시스템에 대한 기본 조직 체계로 시스템을 이루는 구성요소와 구성요소들 사이의 관계, 구성요소와 주변 환경들과의 관계 및 시스템의 진화와 설계를 지배하는 원칙들로 실체화[IEEE1471-2000]
프로그램/시스템의 컴포넌트, 컴포넌트 간의 상호 관계의 구조이며, 이들을 설계하고 전개하기 위한 지침과 원리
나. Software Architecture의 등장배경
시스템 분석/설계에 대한 중요성 인식과 체계적인 분석/설계를 위한 접근필요
이해관계자(Stackholder)간의 관점 조율을 통한 시스템의 최적화
요구 사항들 간 개념 상의 충돌 조정
우선순위 결정과 요구사항 간의 Trade-off 분석을 위한 작업 필요
다. Software Architecture의 주요 요소
|
주요 요소 |
설명 |
|
컴포넌트 |
구체화된 시스템의 기본 조직 SW 개별 구성 요소 |
|
관계 |
|
|
원리 |
SW 디자인과 진화를 이끄는 기본적인 이론 |
라. Software Architecture의 특징
|
특징 |
내용 |
|
간략화 |
이해하고 추론할 정도의 간결성 유지 |
|
추상화 |
추상적인 표현을 사용하여 복잡도를 관리 |
|
가시성 |
시스템이 포함해야 할 것들을 가시화 소프트웨어의 청사진 |
|
관점 모형 |
이해당사자의 관심사에 따른 모형 제시 |
|
의사소통수단 |
이해당사자 간 원활한 의사소통 수단으로 이용 |
2. Software Architecture 프레임워크
가. IEEE-1471 프레임워크
유연성과 확장성을 가진 소프트웨어 중심 시스템의 아키텍처를 기술(description)하기 위한 표준인 IEEE-1471 개념적 프레임워크
나. Software Architecture 프레임워크의 구성요소
|
구성요소 |
설명 |
|
Architecture |
아키텍처를 기록하기 위한 산출물 는 시스템의 이해관계자와 그들의 관심사를 통해 식별함
|
|
이해관계자 |
소프트웨어 시스템 개발에 관련된 모든 사람과 조직
각 이해관계자는 완성된 시스템이 갖추어야하는 기능이나 성능품질 등에 대해 각기 다른 의견과 관점을 가짐 |
|
관심사 |
동일한 시스템에 대한 각 이해관계자의 서로 다른 의견과 목표 ) |
|
View & |
서로 다른 역할이나 책임으로 인해 발생하는시스템이나 산출물들에 대한 서로 다른 관점 View : 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현 Viewpoint : View를 구성하기 위한 규칙을 정의하는 패턴. 각각의 View에 1:1로 대응함. |
3. Software Architecture View
가. Software Architecture View의 정의
복잡한 SW Architecture를 다양한 이해관계자가 바라보는 측면으로서, View는 시스템의 여러 가지 측면을 고려하기 위한 다양한 관점(Viewpoint)을 바탕으로 정의
SW Architecture View에는 Perry and Wolf’s Mode, Siemens Four view, Shaw and Garlan’s Model등이 있으나, UML의 4+1 View Model이 사실상의 표준(De Facto Standard)임
나. Perry and Wolf's Model
요소(Elements): 프로세싱(Processing) 요소, 데이터(data) 요소, 연결(connecting) 요소
표현법(Form): 속성과 관계(Weighted properties and relationships)
근거(Rationale): 아키텍처를 정의하는데 고려되어 지는 다양한 선택에 대한 근거(기능성, 성능,신뢰성, 경제성)
다. Siemens Four view(Siemens사의 Soni, Nord, Hofmeister)
개념적 아키텍처 뷰: 시스템의 상위레벨 컴포넌트 및 그들 간의 관계를 식별
모듈 뷰: 시스템의 분할과 레이어로 모듈를 나눔
코드 아키텍처 뷰: 프로그램의 소스코드를 어떤 단위나 형식으로 구조화
실행 뷰: 시스템의 런타임 개체(runtime entity)와 개체의 속성(메모리 사용, 하드웨어 할당 등)을 정의
라. Shaw and Garlan's Model
컴포넌트(Components): 할당된 임무를 제공하는 실행 가능한 요소
커넥터(Connectors): 컴포넌트간 상호작용의 중재자
패턴(Patterns): 컴포넌트와 커넥터가 조합되는 방법에 대한 제약사항
마. 4+1 View Model
고객의 요구사항을 정리해놓은 시나리오에 대하여 4개의 관점에서 접근하기 위한 Software적인 접근 방법
4+1 View는 Scenario라고도 불리는 Use-Case View를 구현하기 위한 SW Architecture를 표현하는 Logical View와 Process View, Implementation View와 Deployment View의 4개의 View로 구성
라. 4+1 View Model 구성 요소
|
구성요소 |
설명 |
|
사용 사례 관점 (Use Case View) |
시스템의 외부 사용자 관점에서 사용 사례와 이들간의 관계를 정의 시스템 아키텍처를 도출함 |
|
설계 관점 (Design View) |
상위 수준에서 시스템의 논리적인 구조와 행위클래스인터페이스협력관계로 정의 시스템의 기능 요구사항을 설명 |
|
구현 관점 (Implementation View) |
시스템의 병렬 처리 및 동기화 처리를 위한 스레드와 프로세스를 정의 |
|
프로세스 관점 (Process View) |
독립적으로 실행되는 컴포넌트와 이들간의 관계를 정의 |
|
배치 관점 (Deployment View) |
실행되는 시스템 하드웨어와 소프트웨어의 관계를 정의 |
4. Software Architecture 수립 절차
- Software Architecture의 수립은 아키텍처 요구 파악, 참조 아키텍처 조사, 아키텍처 모델링, 아키텍처 프로토타이핑 및 아키텍처 배포의 다섯 단계의 절차로 수행됨
5. Software Architecture 평가
가. Software Architecture 평가 개요
최적의 아키텍처 구현 및 선택을 위해 아키텍처 접근법이 품질 속성에 미치는 영향을 측정하여 아키텍처를 분석하는 과정
아키텍처 평가는 아키텍처의 적합성(suitability)을 판단하는 것으로 아키텍처를 기반으로 완성된 시스템의 품질 목표를 달성하고 시스템을 가용한 자원만으로 구축 가능해야 함
나. Software Architecture 평가의 이점
|
특징 |
내용 |
|
비용적 이익 |
아키텍처를 초기에 분석함으로써 조기에 문제를 발견하여 사업중단 방지
|
|
검토준비 강화 |
아키텍처를 평가하기 전에 평가자에게 평가의 핵심을 알려주고 아키텍처적인 표현을 준비 아키텍처를 문서화하는 과정을 통해 문제점 파악 가능 |
|
논리적 근거 |
정해진 질문에 답변하는 방식으로 아키텍처를 평가함으로써 한정된 영역에 초점을 맞추어 문서화된 설계 근거를 토대로 발생할 수 있는 영향 평가 |
|
문제 조기 발견 |
문제를 초기에 발견할수록 수정에 드는 비용은 감소 불합리한 요구사항과 성능문제파급효과를 일으키는 변경관련 문제 등을 발견하여 제품의 품질과 제약사항을 초기에 간파 |
|
요구사항 검증 |
요구사항의 충돌과를 파악할 수 있으며 그 결과를 조절하기 위해 이해관계자들과 협의 |
|
아키텍처 개선 |
개발 조직에서는 질문사항과 제기될 이슈요구될 문서화 예측 등을 통해 아키텍처 품질 개선 가능 |
다. Software Architecture 평가의 시기
|
시기 |
내용 |
|
이른(Early) |
아키텍처가 완성되기 전에도 이미 내린 결정과 고려하고 있는 결정사항을 아키텍처 구축과정 어느 때나 평가하는 방식 아키텍처 평가 결과가 실제 아키텍처에 바로 반영 최종 아키텍처가 결정되지 않았기 때문에 평가 비용 측면과 완벽성에 있어 부담이 적음 Discovery Review : 아주 이른 시점에 하는 미니 평가로, 난해하고 불필요한 요구사항을 해소하고 시스템이 요구하는 품질 속성을 만족시킬 수 있는 요구 사항들을 검토하는 방식 |
|
늦은(Late) 평가방식 |
아키텍처가 완성되고 구현이 끝난 다음 평가하는 방식 주로 기존 시스템을 이어받아야 할 때 적용 기존 시스템을 이해하고 필요한 요구사항을 만족시킬 수 있는지 파악 |
라. Software Architecture 평가 유형 및 평가 방법
1)Software Architecture 평가 유형
|
평가유형 |
내용 |
|
Scenario based |
직접적으로 품질 요소를 위해 미리 정의된에 의존하여 평가하는 방식 시나리오에 기반하므로 평가결과도 정밀 ATAM, SAAM 등 |
|
Simulation based |
와 같은 시뮬레이션 기반 평가 방식 |
|
Mathematical model based |
기준 모델을 수치화하고 이를 기초로 평가하는 수학적 기반 모델 |
|
Experience based |
정량적인 분석이 어려운 경우 적용하는 경험기반의 평가 정형화된 평가모델을 없이경험을 중요한 평가수단으로 활용하여 평가하는 방식 |
2)Software Architecture 평가 방법
|
평가방법 |
내용 |
|
SAAM |
Software Architecture Analysis Method 수정 가능성과 기능 분석 중심의 최초의 아키텍처 평가 방법 |
|
ATAM |
Architecture Tradeoff Analysis Method 아키텍처가 목표로 하는 품질 만족도각 품질간의 연관성 즉품질 목표간의가 있는지 파악 가능한 아키텍처 평가방법 |
|
CBAM |
Cost Benefit Analysis Method SAAM, STAM의 기술적 아키텍처 중심 평가를 보완하여 시스템 구축 시 경제성 평가까지 수행 비용과 일정 간의 관계를 측정하여 아키텍처의 전략적 비용을 측정함으로써비용대비 효과가 최대가 될 수 있도록 의사결정을 도와주는 평가 모델 |
|
ARID |
Architecture Review for intermediate Design 부분 아키텍처를 아키텍처 초기에 평가하는 방법으로 시나리오 중심의과 설계 검토 방법인를 혼합한 아키텍처 평가 방법 아키텍처 설계 초기에 검토하여 발생 가능한 위험을 감소시킴 |
6. Software Architecture의 발전방향
가. 기술적인 측면
소프트웨어 공학 발전 측면에서도 Software Architecture는 가장 중요한 분야가 되고 있음
Architecture Pattern등 활발한 연구 진행 중
나. 프로젝트 적용 측면
J2EE또는 .NET, CORBA처럼 프레임워크를 근간으로 아키텍처는 발전되어 가고 있으며, 또한 이를 기반으로 적용되고 있음
EJB기반을 근간으로 한 대부분의 CBD 프로젝트에서의 소프트웨어 아키텍처를 근간으로 하여 프로젝트가 수행되고 있으며, 더욱 활발히 전파될 것으로 예상됨.
다. 대표적인 SW F/W
Struts: Open Source J2EE 기반 SW 프레임워크
LG CNS: LAF/J, LAF/.net, LAF/UI 등
소프트웨어아키텍처 스타일
|
이름 |
구조 및 설명 |
설명 |
|
저장소 구조 |
|
서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화 사례 급여 시스템 은행 시스템과 같은 데이터베이스 관리 시스템 |
|
Data Flow Architecture |
|
서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복 서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 함 대표적인 예는 Unix 쉘 |
|
Call and Return Architecture |
|
|
|
Transform Mapping |
|
|
|
Transaction Mapping |
|
|
|
MVC 구조 |
|
MVC 모델 서브시스템: 도메인의 지식을 저장보관 뷰 서브시스템: 사용자에게 보여줌 제어 서브시스템: 사용자와의 상호 작용을 관리 분리하는 이유 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문
|
|
클라이언트 서버 구조 |
|
서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공 서비스의 요구 원격 호출 메커니즘이나 CORBA나 Java RMI의 공통 객체 브로커 클라이언트: 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집 서버: 트랜잭션을 수행하고 데이터의 일관성을 보장한다 |
|
계층 구조 |
|
각 서브 시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용 추상화의 성질을 잘 이용한 구조 대표적인 예: OSI 구조 장점 각 층을 필요에 따라 쉽게 변경할 수 있음 단점 성능 저하를 가져올 수 있음
|
|
디플로이먼트 스타일 |
디플로이먼트 뷰 타입에 포함된 스타일 배치 스타일(Deployment style) 프로세스가 어떻게 하드웨어 요소에 매핑되는지 보여줌. 메시지 트래픽 예측, 성능, 보안, 신뢰성 등을 분석하는데 사용. 구현 스타일(Implementation style) 모듈이 어떻게 개발 인프라에게 매핑되는지 보여줌. 버전관리와 멀티-팀 개발을 지원. 업무 할당 스타일(Work assignment style) 모듈이 어떻게 개발조직에 매핑되는지 보여줌. 어떤 팀이 어떤 모듈을 개발해야 하는지 설명. WBS, schedule, budget |
디플로이먼트(Deployment) 스타일 - 소프트웨어 단위와 개발 및 실행 환경 사이에 관계를 표현
|
