Transcript 소프트웨어 아키텍처

소프트웨어 아키텍처
소프트웨어 아키텍처 개론
소프트웨어 아키텍처 팀
김정호 과장
1
소프트웨어 아키텍처
목차
I.
소프트웨어 아키텍처 개념 및 예제
II.
소프트웨어 아키텍트 역할 및 자질 이해
III.
소프트웨어 아키텍처 결정 요인 소개
IV.
소프트웨어 아키텍처 전략 수립 방법
V.
소프트웨어 아키텍처 설계 방법 소개
VI.
소프트웨어 아키텍처 대안 평가 방법 소개
2
아키텍처 개념
소프트웨어 아키텍처
다양한 건축물
3
아키텍처 개념
소프트웨어 아키텍처
다양한 건축물
4
아키텍처 개념
소프트웨어 아키텍처
건축물 평면도
5
아키텍처 개념
소프트웨어 아키텍처
건축물 단면도
6
아키텍처 개념
소프트웨어 아키텍처
건축물 배치도
7
아키텍처 개념
소프트웨어 아키텍처
건축물 입체도
8
아키텍처 역사
소프트웨어 아키텍처
Copied by “Software Architecture Theory” 이해일
9
아키텍처 역사


소프트웨어 아키텍처
아키텍처 기원

기원전 2000년 전 피라미드 건축에도 아키텍처 사용

어원으로 사용된 것은 기원전 500년 건축에서 시작
시스템(소프트웨어) 아키텍처의 기원

19세기 미국 횡단 철도 공사 사업의 대규모로 진행

1887년 전화개발과 전신 사업에서의 복잡성이 증대

1950년대의 미 국방 방위 시스템 reliable한 시스템 개발이 필요

20세기 대용량 computer에서 PC 보급 등 컴퓨팅 시스템의 다양화
10
아키텍처 정의
소프트웨어 아키텍처
Copied by “Software Architecture Theory” 이해일
11
아키텍처 정의

소프트웨어 아키텍처
비투루비우스의 삼각형
Copied by “Software Architecture Theory” 이해일
12
아키텍처 정의


소프트웨어 아키텍처
아키텍처 란?

건축물 설계도 또는 도시의 지도와 같이 어떤 대상의 주요한 특징을 추상화 하여 묘사한 것.

시스템의 논리적(Logical)이고 구조적(Structural)인 산출물
Architect 란?

archi (시작, 출발, 원칙 등) + tekton (벽돌 쌓는 사람, 석공)
=> 건축가의 대표, 숙련된 기술자

아키텍처를 개발하는 사람

아키텍처를 설계(수립)하는 행위
13
소프트웨어 아키텍처 예제
소프트웨어
아키텍처
소프트웨어 아키텍처 - Box and Line ?
14
소프트웨어 아키텍처 예제
소프트웨어
아키텍처
소프트웨어 아키텍처 - Stacks and Box ?
15
소프트웨어 아키텍처 예제
소프트웨어
외부사용자 계층
내부 사용자 계층
연동 시스템 계층
(외부 영업(모집인, 대리점))
(현업 직원)
(대외 기관, 내부 채널)
외부 사용자 보안 계층
(Login, Policy, PKI)
내부 사용자 보안 계층
(Login, Policy)
사용자 서비스 통합 계층
시스템 통합 계층
(사용자(EP))
운용자
계층
아키텍처
(대외 연계, 대내 연계(EAI))
프레젠테이션 계층
(영업 화면 구성(JSP), 기간계 화면 구성(X-internet))
비즈니스 계층
(Framework, RBMS, Image, Workflow, Batch)
영업 데이터
계층
기간계 데이터 계층
16
소프트웨어 아키텍처 예제
소프트웨어
아키텍처
17
소프트웨어 아키텍처 정의
소프트웨어

아키텍처
당신의 정의는?

각각의 서버는 다수의 사용자 요청을 동시에 처리해야 하며 이 정보를 기업의 데이
터 베이스에 넣어 서로 공유한다.


어떠한 클라이언트 프로그램도 DB에 바로 접속할 수 없다.

J2EE를 사용한다.

골격, 기본, 틀
일반적인 정의?

소프트웨어 구성 요소들, 관계, 공정, 제약조건, 기능으로 표현된 기본적이고 통합
적인 체계구조. [Rechtin 1991]

소프트웨어 구성 요소들, 관계, 제약조건 등의 모임

소프트웨어 개발 참가자들의 요구 사항들의 모임

구성 요소들간의 연결, 소프트웨어 개발 참가자들의 요구 사항들을 만족시키는데
필요한 제약 조건들을 증명해 보일 수 있는 근거[Boehm 1995]
18
소프트웨어 아키텍처 정의
소프트웨어


아키텍처
정의한 종류는 몇가지?

Google => 6,540,000 hits

Citeseer => 5476 hits

다들 비슷비슷 하다.
이 과정에서 사용하는 정의는?

A software Architecture for a system is the structure or
structures of the system, which comprise elements, their
externally-visible properties, and the relationships among
them.

프로그램이나 컴퓨팅 시스템에서 소프트웨어 아키텍처는 소프트웨어 구
성요소와 그들이 가진 특성 중에 외부에 드러나는 요소의 특성, 그리고 구
성요소들 간의 관계를 표현하는 시스템의 구조나 구조체를 말한다. 시스
템 설계와 개발 시 적용되는 원칙과 지침을 가지고 있어야 한다.
19
소프트웨어 아키텍처가 나타난
이유
소프트웨어

소프트웨어 시스템의 복잡성이 증가
Ubiquitous/pervasive
computing
Dependable/dynamic/self-healing
수만

systems
라인의 코드
인간 능력의 한계
개발

아키텍처
프로젝트에 이해 관계자는 수백명에 이른다.
소프트웨어 기술의 신속한 변화
MFC,
J2EE, Eclipse, MDA, SOA, Web2.0, etc.
20
소프트웨어 아키텍처 나타난
이유
소프트웨어
아키텍처
소프트웨어 개발 프로젝트의 이해 관계자들
21
소프트웨어 아키텍처 수립
이점
소프트웨어

아키텍처
시스템 이해도를 높일 수 있는 대화 수단으로 사용
시스템의 추상화 개념을 통해 이해관계자(고객, 사용자, PM, 설계자 , 개발자)가
모두 시스템의 하나된 모습을 볼 수 있다면 요구사항 추출, 리스크 감소에 탁월한
효과가 있다.


초기 설계의 원칙을 제공함
만약 단순 functional requirement의 답을 찾기 위함이라면 굳이 아키텍처의 개
념을 사용할 필요가 없다. 그러나 우리에게는 이해하고 구현하기 힘든 소프트웨어
품질 속성이 있다.


상위 수준 설계의 재사용이 가능
이미 관련단체들은 하위 수준의 재사용은 이미 실패하였다고 발표하고 있다. 상위
수준의 재사용만이 우리가 할 수 있는 유일한 생산성 향상이 될 것이다.

22
소프트웨어 아키텍처 이점
소프트웨어

아키텍처
개발 및 유지보수 비용 감소

디자인 레벨에서의 Reuse가 가능함
 시스템의 이해도를 높일 수 있는 대화 수단으로 사용

시스템이 진화하는 것에 기본 데이터를 제공
 ATT에서 1988 아키텍처 Review B를 창설하여 6년 동안 350개의 소프트웨어 아키텍처를
review하였고 그에 대한 결과를 약 175 staff/year를 줄였다고 발표했다.

소프트웨어 product의 품질 증가

요구사항을 명확히 하기 위함

소프트웨어 product을 결정할 시점에 갈등을 막아 줄 수 있는 원칙을 만들기 위
함

디자인 단계에서 초기 분석을 진행하기 위함
만약 단순 functional requirement의 답을 찾기 위함이라면 굳이 아키텍처의 개념을 사용할
필요가 없다. 그러나 우리에게는 이해하고 구현하기 힘든 소프트웨어 품질 속성이 있다.

23
소프트웨어 아키텍처 이점
소프트웨어

아키텍처
소프트웨어 개발의 Risk 대처 가능

Stakeholder들과 같이 대화할 수 있는 기초 자료로 활용
 초기 디자인 단계의 가이드를 제시해 줌

소프트웨어 요구 사항에 변화가 생겼을 경우 그에 대한 impact를 예측하기 쉬움
 소프트웨어 개발 프로젝트 초기 단계에 아키텍처를 통한 Risk 검증은 절대적이라고 할 수 있
다. 소프트웨어 아키텍처를 그리기 전에는 engineering 측면의 risk를 찾기가 거의 불가능하
다.

개발 조직을 프로젝트에 맞게 재편 가능

소프트웨어 아키텍처를 기준으로 개발 조직을 만들 수 있음
 소프트웨어 아키텍처에서 얘기하는 기술의 흐름을 파악하고 전사 조직을 여기에
맞게 재편할 수 있음
 Architectural Business Cycle에서 제시하듯 소프트웨어 아키텍처는 비즈니스에 영향을 준
다.
24
소프트웨어 아키텍처 수립
이점
소프트웨어
아키텍처
Architectural Business Cycle
25
아키텍처 종류

소프트웨어 아키텍처
Enterprise 아키텍처

비즈니스 구조와 이들을 연결하는 프로세스
를 표시한다.

System 아키텍처

User와 컴퓨팅 System과의 데이터 흐름 및
Zachman Enterprise Framework
인터페이스 정의한다.

소프트웨어 아키텍처

시스템 특성을 가지고 있는 요소들과 그들의
연관관계를 표시하는 시스템 구조를 말한다.
Unix System 아키텍처
26
소프트웨어 아키텍처
아키텍처 종류

아키텍처의 관계
Enterprise Architecture
Business
Architecture
Application
Architecture
Data
Architecture
Technical
Architecture
Software
Architecture
System
Architecture
Infra
Architecture
27
소프트웨어 아키텍처의 위치
소프트웨어
아키텍처
User Model
User 관점에서의 문제점
Requirements
시스템 관점에서의 문제점
소프트웨어 아키텍처
Code
Executable
상위 레벨의 시스템 디자인
시스템 레벨의 추상화
모듈, 컴포넌트, 알고리즘,
데이터 구조
Data Layout, Memory Map
28
소프트웨어 아키텍트 정의
소프트웨어

아키텍처
소프트웨어 아키텍트란?

이해관계자(고객, PM, 개발자 등)와 지속적인 대화를 통해 소프트웨어
시스템의 목표를 명확히 하는 communication의 달인

소프트웨어 아키텍트는 소프트웨어 시스템 구축을 위한 소프트웨어 아
키텍처를 설계(수립) 하는 고급 엔지니어

소프트웨어 아키텍처를 수립하는 과정에서 발생하는 다양한 논쟁과 상
충 사안을 해결하는 협상 전문가

소프트웨어 아키텍처가 시스템 구축에 정확하게 구축되도록 지속적으로
lead, Help, check하는 강력한 리더
29
소프트웨어 아키텍트 정의
소프트웨어

아키텍처
소프트웨어 아키텍트가 갖춰야 할 자질
기능/
품질
(참조)
아키텍처
패턴
아키텍처
평가
Business
도메인
(증권, 은행, 공공, etc.)
소프트웨어 아키텍처
설계(수립)
Technology
도메인
(Framework, DB, Java, etc.)
리더십
의사소통
30
소프트웨어 아키텍트 정의
소프트웨어
아키텍처
아키텍처를 이해시킬 수 있는가? – 정답: 추상화
Abstract (less details)
human’s
capability
Concrete (more details)
31
소프트웨어 아키텍처 - 추상화
소프트웨어
아키텍처
이런 아키텍처를 이해시킬 수 있는가?
32
소프트웨어 아키텍처 - 추상화
소프트웨어
아키텍처
이런 아키텍처는 이해시킬 수 있는가?
33
소프트웨어 아키텍처 결정
요인
소프트웨어

아키텍처
아키텍처를 작성할 때 발생할 수 있는 결정 요인

기능 요구사항


시스템이 반드시 수행해야 되는 기능들
제약 사항

소프트웨어 개발 시, 이미 결정된 사항들


Ex) 기간, 비용, COTS, etc.
품질 속성

소프트웨어 개발할 때 요구되는 품질 속성들

Ex) 가용성(Availability), 성능, 보안, 유지보수성, etc.
기능 요구사항
소프트웨어
아키텍처
품질 속성
제약 사항
34
소프트웨어 아키텍처 결정
요인 - 제약 사항아키텍처
소프트웨어

비즈니스 제약 사항
법률적인
회사
제약 (ex. 개인의 위치를 찾을 경우 반드시 피 위치 추적자의 동의를 사전에 얻어야 한다.)
사규 (ex. 모든 회사 임직원은 자동으로 임직원 시스템에 등록된다.)
비즈니스
목표 (ex. 급변하는 시장에 적응하기 위해 서비스 정보를 임원들에게 주기적으로 보고해야 한다.)
…

기술적 제약 사항
Compatibility
Conformance
(ex. Windows OS와 Linux에 모두 porting이 되어야 한다.)
GUI Style (ex. 회사 표준으로 사용하는 GUI Style을 따라야 한다.)
특정
아키텍처 사용 (ex. J2EE 아키텍처를 표준으로 도입한다.)
특정
언어 사용 (ex. 모든 개발 언어는 시스템 portability가 좋은 Java를 사용한다.)
특정
국제 표준 사용 (ex. web service의 기능을 이용한다.)
H/W,
S/W reuse (ex. 기존 시스템의 재활용 측면에서 아래와 같은 H/W, S/W를 개발에 사용한다.)
…

조직적 제약 사항
시간
(ex. 본 프로젝트는 2007년 2월 1차 오픈, 2007년 8월 최종 오픈으로 한다.)
비용
(ex. 본 프로젝트는 인건비용과 H/W, S/W 구입 비용을 포함하여 총 xxx를 SKC&C에 지급한다.)
인력
(ex. SOA 전문 인력을 2명 확보해야 하나 1명만 확보되어 시스템 디자인에 투입한다.)

…
35
소프트웨어 아키텍처 결정
요인
소프트웨어
아키텍처
아키텍처를 작성할 때 가장 중요한 것은?
Terminal
Host
호스트 구조
36
소프트웨어 아키텍처 결정
요인
소프트웨어
아키텍처
아키텍처를 작성할 때 가장 중요한 것은 ?
Server
Client
Client – Server 구조
37
소프트웨어 아키텍처 결정
요인
소프트웨어
아키텍처
아키텍처를 작성할 때 가장 중요한 것은 ?
Client
Middleware
DBMS
3-tier 구조
38
소프트웨어 아키텍처 결정
요인
소프트웨어
아키텍처
아키텍처를 작성할 때 가장 중요한 것은 ?
Thin
Client
Presentation
Middleware
DBMS
4-tier 구조
39
소프트웨어 아키텍처 결정
요인 - 품질
소프트웨어
아키텍처
아키텍처를 작성할 때 가장 중요한 것은 ?
품질 (Quality)
40
소프트웨어 아키텍처 결정
요인 - 품질
소프트웨어

아키텍처
기능과 품질은 상호 독립적(orthogonal)이다.

두개의 다른 시스템에 같은 기능을 구현할 수 있다.

두개의 시스템이 서로 다른 구조를 가지고 있는 것은 품질 속성이 다르기 때문이다.

Example> 포탈의 communication channel과 우주 왕복선의 communication
channel


아키텍처 구성은 특정한 품질을 높이지만 특정 품질에는 안 좋을 수 있다.

미들웨어를 두는 것은 유지보수에 도움은 되지만 성능을 오히려 저해한다.

이것을 아키텍처 Tradeoff라고 한다.
품질 속성은 반드시 초기 설계에 반영이 되어야 한다.

기능 요구사항을 만족시키는 개발을 한 후에 품질을 더 한다?
41
소프트웨어 아키텍처 결정
요인 - 품질
소프트웨어


아키텍처
품질은 소프트웨어 아키텍처만 관련이 있는가?

소프트웨어 아키텍처

System(H/W, N/W) 아키텍처

Data 아키텍처

Business 아키텍처

코드

알고리즘

…
품질과 가장 관련이 많은 것은?

가장 변수가 많은 것
소프트웨어 아키텍처
42
품질 속성

소프트웨어 아키텍처
품질 속성 시나리오

Stimulus – 시스템에 적용되는 조건들

Response – Stimulus 결과 반영되는 결과들

Source of the stimulus – Stimulus를 발생하는 원인

Environment – Stimulus가 발생할 때 연계되는 외부 조건들

Artifact stimulated – Stimulus에 의해 영향 받는 산출물들

Response measure – System에 반영되는 결과를 수치화 하는 지표
43
품질 속성 시나리오

소프트웨어 아키텍처
Example
“ 예상치 못한 메시지를 전달 받았을 때, 시스템은 운용자에게 이를 즉시 알
려야 한다. 그리고 시스템이 다운되는 시점에서도 이를 즉시 운용자에게 리
고 조치를 취해야 한다. “
여기에

무슨 품질 속성이 있을까?
Example
“디스크를 점검하는 Error Indicator는 10초 주기로 디스크를 점검하여 디
스크에 이상 메시지가 발견되거나 시스템이 다운되었다고 판단되면 다음과
같은 기능을 하여 서비스의 끊김이 없어야 한다.
- 즉시 운용자에게 알람 메시지를 전달한다.
- 10초 이내에 백업 시스템을 가동해야 한다.
- 1분 이내에 Background로 시스템을 재 부팅한다. “
44
품질 속성 종류

소프트웨어 아키텍처
가용성(Availability)

소프트웨어 시스템 다운 상황으로 서비스를 더 지속하기 힘들 때, 이를 대처하는 동작들을
의미한다.

변경용이성(Modifiability)


성능(Performance)


소프트웨어 시스템이 변화하려고 할 때 발생하는 비용과 변화 용이성을 의미한다.
Event가 발생했을 때, 이를 처리하는 시간과 동시에 이를 처리하는 능력을 말한다.
보안(Security)

허가되지 않은 사용자가 시스템 데이터나 기능을 사용하려 할 때 이를 저지하는 기능을 말한
다.

Others

유지보수성(Maintainability), 신뢰성(reliability), 사용성(usability), 확장성(extensibility,
scalability), portability, learnability, testability, buildability
45
품질 속성 종류
소프트웨어 아키텍처
46
Quality Attributes Workshop
(QAW)
소프트웨어

아키텍처
정의

QAW는 시스템 stakeholder들이 모여서 S/W system의 품질 속성을 추출하
는 방법을 말한다.

다음과 같은 순서로 진행된다.
1.
Introductions

2.
아키텍처 Driver 추출

3.
4.
QAW를 설명하고 비즈니스 환경과 아키텍처 개발 계획을 소개한다.
Functional Requirement, Constraint를 정의한다.
품질 속성 Scenario

Stakeholder들과 Brainstorming을 통하여 Scenario를 정한다.

Scenario 결과를 취합하여 review하고 순위를 매긴다.
Iteration

충분하다고 판단할 때까지 1 ~ 3의 과정을 반복한다.
47
Quality Attributes Workshop
(QAW)
소프트웨어
아키텍처
품질 속성 도출, 시나리오 작성 및 순위 결정
품질
요구사항명
요구사항 설명
난이도
중요도
상
상
상
상
중
상
상
중
중
하
시스템 개발자가 신규 상품을 시스템에 적용하려 할 때, 기존 상
확장성
신규 서비스 추
품의 변동 없이 신규 상품(Universal 보험 상품 등은 제외)은
가의 용이성
4일 이내, 유사 상품은 4시간 이내에 기간 시스템 및 SFA에
launch해야 한다. (테스트 시간은 제외)
서비스 사용자가 서비스를 사용하려 할 때, 단순한 조회일 경우,
평균 3초 이내(NSP 프로젝트의 범위내 기준으로, 최대 10초
성능
Latency
이내), 온라인 통계자료 조회일 경우는 평균 10초(최대 30초)
이내로 처리해야 한다. (예외 특이건에 대하여는 해당시점에 협
의하여 성능목표를 정함)
정보
제공성
정보
제공성
실시간성
일마감 지원
월마감 지원
실시간 처리
서비스 관리자가 일마감 정보를 원할 경우 특정 시간(예: 자정)
이후에 일마감 정보 실시간으로 제공해야 한다.
서비스 관리자가 월마감 정보를 원할 경우 수납 마감일 이후 3
일 이내에 월마감 정보 제공해야 한다.
정보계 시스템은5분 주기로 정보를 수집해야 한다.
48
소프트웨어 아키텍처
아키텍처 패턴
Model
View
아키텍처 패턴
Control
• 시스템의 구조에 초점을 맞춘 상위 수준의
설계 지침 을 결정한다.
• 아키텍처 스타일, 디자인 패턴과 혼용해서
사용되기도 한다.
Ex) Layer, Blackboard, Pipe and Filter, etc.
Model
디자인 패턴
ActionForm
View
Control
Action
JSP
Action
Servlet
• 시스템의 구조에서 특정한 디자인의 문제를
해결하기 위해 자주 사용되는 구조를
• 상위 수준의 아키텍처를 기준으로 상세
디자인의 설계 지침을 준다.
Ex) Singleton, Master-Slave, Access-Control
etc.
49
아키텍처 Tactics

소프트웨어 아키텍처
아키텍처 Tactics

품질에 조절할 수 있도록 상위 수준의 패턴을 결정하게 하는 기법
주요 품질 요소



가용성 (Availability)
변경 용이성 (Modifiability)

성능성 (Performance)

보안성 (Security)
50
아키텍처 Tactics

소프트웨어 아키텍처
가용성 (Availability)
51
아키텍처 Tactics

소프트웨어 아키텍처
변경 용이성 (Modifiability)
52
아키텍처 Tactics

소프트웨어 아키텍처
성능성 (Performance)
53
아키텍처 Tactics

소프트웨어 아키텍처
보안성 (Security)
54
아키텍처 패턴, 참조 모델,소프트웨어
참조 아키텍처
아키텍처
참조 모델
(TOGAF, etc.)
참조 아키텍처
S/W 아키텍처
(J2EE, SOA, etc.)
(XX 프로젝트 아키텍처, etc.)
아키텍처 패턴
(Call-Return, etc.)
Implementation
F/W
Qualities
Infrastructure Applications
(Spring, Struts, etc.)
Operating System Services
Network Services

참조 아키텍처


참조 모델과 아키텍처 패턴을 결합하여 특정 품질을 항상 시켜 놓은 아키텍처
Communications Infrastructure Interface
Communication Infrastructure
TOGAF TRM
Implementation F/W

참조 아키텍처를 기준으로 프레임워크으로 개발 된 상용 제품
55
Graphics & Image
Data Management
International
Operations
Data Interchange
User Interface
Transaction
Processing
Location & Directory
특정 도메인의 기능을 요소 별로 구분하여 놓은 것
Security

System & Network
Management
참조 모델
Software Engineering

Business Applications
Application Programming Interface
Spring
소프트웨어 아키텍처
56
Struts
소프트웨어 아키텍처
57
iBatis
소프트웨어 아키텍처
58
아키텍처 전략 수립 방법론
- ADD
소프트웨어
1.
순서
1)
ADD(Attribute Driven Design)은 순차적으로 소프트웨어 아키텍처
수립하기 위한 시스템적인 방법론을 말한다.
ADD는 소프트웨어 시스템의 기능적인 속성과 품질 속성, 그리고
제약사항을 input으로 받아 각각의 속성을 만족시킬 수 있도록 최상위
수준에서 recursive하게 분할하는 과정을 통해 아키텍처를 수립하는
방법이다.
ADD를 수행하는 step은 아래와 같다.
1.
요소들간의 관계를 설계할 핵심적인 아키텍처 요구사항을
추출한다. 핵심적인 아키텍처 요구사항은 기능적인 목표, 품질
속성, 비즈니스 속성 등의 조합으로 주로 나타나 아키텍처에
중요한 역할을 수행하는 요구사항을 말한다. 요구사항들은 반드시
순위로 작성하여야 한다.
2.
소프트웨어 아키텍처를 수립할 소프트웨어 시스템의 최상위 수준
요소를 선별하고 분할할 요소를 선택한다.
3.
우선 순위가 높은 요구사항을 추출한다.
4.
이를 만족시킬 수 있는 아키텍처 설계 방향(아키텍처 패턴이나
tactics)을 선택한다. 이 때에 사용하려 하는 아키텍처 패턴이나
tactics들이 다른 아키텍처 요구사항과 tradeoff가 발생할 경우
우선 순위로 선택한다.
5.
선택된 아키텍처 패턴과 tactics에 맞도록 분할할 요소에
맵핑한다.
6.
분할할 요소 내부에 새로운 요소를 정의하고 이들의 인터페이스
및 연관관계를 정의한다.
7.
아키텍처 요구사항을 다시 한번 정제하고 앞에서 정해진 요소를
제약사항으로 놓는다.
8.
정의하고 모든 아키텍처 요구사항을 만족하는지 확인하여 만족할
때까지 1 ~ 7번을 반복적으로 수행한다.
2)
3)
아키텍처
S/W 아키텍처 요소

소프트웨어 아키텍처
S/W 아키텍처 란?
“프로그램이나 컴퓨팅 시스템에서 소프트웨어 아키텍처는 소프트웨어 구성요소와 그
들이 가진 특성 중에 외부에 드러나는 요소의 특성, 그리고 구성요소들 간의 관계를
표현하는 시스템의 구조나 구조체를 말한다. “

S/W 아키텍처는 S/W 시스템을 대표하는 Structure를 추상화해야 한다.

시스템을 대표하는 Structure를 시스템의 View라고 부른다.
Physical 측면
• Allocation Views
- Computers
- Devices
- Networks
S/W
아키텍처
Runtime 측면
• Runtime Views
- Processes
- Sequence diagrams
- dataflow
Static 측면
• Module Views
- Classes
- Functions
- Interfaces
60
S/W 아키텍처 요소

소프트웨어 아키텍처
Structures 와 View의 관계
Human Body Structure
심장 전문의
Static View
Static View
Dynamic View
Dynamic View
외과 전문의
61
S/W 아키텍처 요소

소프트웨어 아키텍처
S/W 아키텍처 란?
“프로그램이나 컴퓨팅 시스템에서 소프트웨어 아키텍처는 소프트웨어 구성요소와 그
들이 가진 특성 중에 외부에 드러나는 요소의 특성, 그리고 구성요소들 간의 관계를
표현하는 시스템의 구조나 구조체를 말한다. ”

S/W 요소는 시스템을 시스템을 구성하고 있는 작은 단위의 요소이다.

시스템의 바라보는 관점에 따라서 다음과 같은 요소들이 존재한다.

Static 관점 : classes, files …

Runtime 관점 : thread, data flow, control …

Physical 관점 : computers, actuators, networks …
62
S/W 아키텍처 요소

소프트웨어 아키텍처
S/W 아키텍처 란?
“프로그램이나 컴퓨팅 시스템에서 소프트웨어 아키텍처는 소프트웨어 구성요소와 그
들이 가진 특성 중에 외부에 드러나는 요소의 특성, 그리고 구성요소들 간의 관계를
표현하는 시스템의 구조나 구조체를 말한다.”

Externally visible properties는 S/W elements가 시스템에 미칠 수 있는 영향
을 말한다.

다음과 같은 property가 존재한다.

Performance characteristics => runtime view

Modifiability => module view

Fault handling => module, allocation or runtime view.
63
S/W 아키텍처 요소

소프트웨어 아키텍처
S/W 아키텍처 란?
“프로그램이나 컴퓨팅 시스템에서 소프트웨어 아키텍처는 소프트웨어 구성요소와 그
들이 가진 특성 중에 외부에 드러나는 요소의 특성, 그리고 구성요소들 간의 관계를
표현하는 시스템의 구조나 구조체를 말한다. “

S/W 요소들 사이에 존재하는 연관(interaction)관계를 표시해야 한다.
relationship(s)
Element 1
properties = {p1, p2. …}
Element 2
properties = {p1, p2. …}
64
S/W 아키텍처 View

소프트웨어 아키텍처
View 란?

시스템을 이루는 요소들의 집합과 그들의 연관 관계를 추상적으로 표현한 것
뷰 포인트
소프트웨어 시스템
소프트웨어 아키텍처 뷰
S/W 아키텍처 View
소프트웨어 아키텍처
1. UP에서 제시한 4+1 view
1)
2)
4+1 View는 Logical, Implementation, Process, Deployment 뷰 이렇게 4가지 뷰와 Use case 뷰를 포함한다.
고객이 4+1 View를 요구할 경우에는 위에서 제시한 3 view를 참조하고 아래의 관계를 고려하여 작성한다.
이름
설명
당사의 3 view와의 관계
Logical view
시스템의 기능적인 요구사항, 즉
시스템이 최종 사용자에게 해주는
것을 구조적으로 정의한 뷰이다.
• 당사가 제시한 Module view 타입에 속한다.
• 당사의 특성상 기능적인 요구사항에 대한 분석, 설계는 사업팀
에서 담당하고 소프트웨어 아키텍트는 기능적 요구사항 분석이
가능한 틀을 이 뷰에서 제시한다. (23 페이지 참조)
Implementation
view
개발 환경내의 정적인 소프트웨어
모듈(소스 코드, 데이터 파일, 컴포
넌트, 실행 파일 등)의 구성을 나타
낸뷰
• 당사가 제시한 Allocation view의 Implementation view에 속
한다.
• 개발자의 구현 관점에서 사용되고 프로젝트 관리에 사용하기가
좋다.
• 개발환경을 표현한 디렉토리 구조와 logical view의 모듈을
구현 모델로 어떻게 맵핑한 구조로 나눌 수 있다.
Process view
실제 구동 환경을 살펴본 형태인
Process View가 있습니다.
• 당사가 제시한 Runtime view에 속한다.
• 4+1 view에서는 Logical view를 중심으로 생각하고 있으나
당사가 제시한 3 view는 Runtime view을 중심으로 생각한다.
Deployment
view
시스템이 실제로 설치되고, 배치되
는 모습을 표현한 뷰
• 당사가 제시한 Allocation view의 Deployment view에 속한다.
Use case view
위의 4가지 뷰 모두를 검증하고 통
합시켜주는 뷰 (소프트웨어 아키텍
처에 속하지 않음)
• Use case를 중심으로 당사의 Runtime view를 검증하는
프로토타입에 사용한다. (아키텍처 검증 Asset 참조)
S/W 아키텍처 View

소프트웨어 아키텍처
Viewtype 란?
view를
구조화 하는 방법을 viewtype이라고 한다.

Module viewtype : Code unit들을 어떻게 구성하지?

Runtime viewtype : S/W system 요소들의 runtime behavior와 interaction은
어떻게 표현하지?

Allocation viewtype : S/W 요소들이 non-software 환경과 어떻게 mapping이 되
지?

Examples
Semantic
Semantic
Main
Definition
NodeAnalyzer
Expression
NodeAnalyzer
Statement
NodeAnalyzer
Semantic
Error
<<interface>>
Semantic
Visitor
Module viewtype
Runtime viewtype
Allocation viewtype
67
S/W 아키텍처 style

소프트웨어 아키텍처
아키텍처 style 이란?
S/W
제약 사항을 표현할 수 있는 S/W 구성 요소와 연관관계의 특별한 type을 말한다.
Module

viewtype
Decomposition Style : 계층적으로 모듈을 분리하여 작성, Concurrent System 개발에 유리한
Style

Generalization Style : Reuse를 목적으로 계층을 특성화 한 Style

Layered Style : Portability, Reusability을 위한 Style
Runtime

viewtype
Data Flow Style : 데이터 이동에 목적을 둔 Style


Call & Return : S/W 요소들의 호출을 특성화 한 Style


Ex. Implicit, Explicit event
Data-Sharing : Data Storage를 중심으로 연동하는 Style

Allocation

Ex. Main program/subroutines, Information hiding
Interacting process : Event Based로 system이 움직이는 Style


Ex. Batch sequential, pipes & filters
Ex. Compound Documents
viewtype
Deployment Style, Implementation Style, Work assignment style
68
Module viewtype

소프트웨어 아키텍처
Decomposition Style

S/W 요소(Elements) : Code에 근간을 둔 Modules
연관관계
(relationship) : “is part of ”
A
B
C
D
A
C
B
D
69
Module viewtype

소프트웨어 아키텍처
Generalization Style

S/W 요소(Elements) : Code에 근간을 둔 Modules

연관관계 (relationship) : Generalize, “is a”

UML 등으로 표시
A
A
B
C
D
B
C
D
70
Module viewtype

소프트웨어 아키텍처
Layered Style

S/W 요소(Elements) : Layers, a virtual machine, etc.

연관관계 (relationship) : Allowed-to-use, depends-on
71
Runtime viewtype



소프트웨어 아키텍처
S/W 요소(Elements)

Components : Run-time과 연관되는 핵심 단위

Connectors : Component들 간의 연동 Mechanism을 표시
연관관계 (relationship)

Ports : Component들 간의 연동을 위한 gate

Roles : Component와 연동하기 위한 Connector의 역할
특성 (Properties)

S/W 개발과 분석을 위해 정보를 특성화 하는 것

Ex. 품질 요구사항
port
Connector
Component 1
Component 2
role
72
Runtime viewtype

소프트웨어 아키텍처
Pipe and Filter Style

Components => Filters


Connectors => Pipes


입력되는 데이터가 해당 Filter에 관련이 되면 처리를 하고 아니면 그냥 흘려 보냄
데이터가 흘러 다니는 파이프
Constraints

데이터는 한 곳으로 흘러야 하며, Filter간의 state 정보 공유가 필요 없다.
Ex>>
cat etc/passwd | grep “joe” | sort > junk
73
Runtime viewtype

소프트웨어 아키텍처
Call & Return Style

Components


서비스를 제공하는 단위로서 서비스를 요청하거나 제공한다.
Connectors

서비스를 Callee에게 요청하고 return 되는 서비스를 Caller에게 전달하는 역할을 한
다.
종류

Object model, Tier model
74
Runtime viewtype

소프트웨어 아키텍처
Event-Based Style

Components


Event 발생 시 기능을 하는 모듈들
Connectors

Event 전달을 목적으로 하는 Event Bus
종류

Explicit, Implicit Event type
75
Allocation viewtype

소프트웨어 아키텍처
S/W 요소(Elements) : Module 혹은 Runtime style을 그대로 유지,
주변 환경 요소들

연관관계 (relationship) : allocated-to

Deployment style : Runtime 요소와 H/W와의 관계
Deployment style
76
Allocation viewtype

소프트웨어 아키텍처
Implementation Style : 클래스 혹은 소스 코드와 디렉토리와의 연관 관계
Implementation style
77
아키텍처 기술 목적


소프트웨어 아키텍처
S/W 아키텍처는 시스템 전반을 보여주는 Blueprint이다.

초기 분석의 가장 좋은 산출물

S/W 품질을 표시할 수 있는 첫번째 운반자

S/W 유지보수에도 결정적 key factor를 제공
아키텍처기술을 통해서 체계적으로 S/W 아키텍처를 개발할 수 있
다.

Artifact는 영원하다.
78
아키텍처 기술의 7가지 원칙
소프트웨어
1.
아키텍처
읽는 사람 입장에서 작성하라
Main Controller
2.
불필요하게 반복되는 어구를 피하라
3.
모호한 부분을 피하라
4.
표준화된 포맷을 이용하라
5.
합리적인 이유를 작성하라
6.
Document의 버전 관리를 철저히 하라
7.
분명한 목적을 가지고 Document를 Review해야 한다.
C-code
Tree
79
아키텍처 기술의 문제점 및
해결 방법
소프트웨어


아키텍처
많은 부분들이 제대로 정의되지 않은 채 버려져 있다.

이것은 어떤 종류의 아키텍처 요소인가?

이 relation은 어떤 의미를 가지지?

여기의 box와 저기의 화살표하고는 무슨 연관 관계가 있는거야?

Layout의 명확한 의미가 뭐야?

왜 High level view에 control 프로세스가 있는거야?
어떻게 피할 수 있는가?

반드시 범례를 포함해라

화살표의 의미를 명확하게 하라(Ex. Control flow? or data flow?)

View type을 목적 없이 혼합하지 마라.

그림 뒤에는 반드시 설명을 달아라.
80
아키텍처 문서의 품질 지표
소프트웨어


아키텍처
Good Point

Line과 Box들 각각 색깔을 달리하고 설명을 달면…

표를 달아서 아키텍처 선택 요인을 표시하면…

한 장에 하나의 아키텍처 view가 나오면…

Viewtype별 차이를 명확하게 하면…
Bad Point

Line하고 Box는 항상 일정하네….

화살표의 의미가 없어…

화살표 하나에 의미가 너무 많아…

아키텍처를 구현 생각하고 그리네…

아키텍처 결정 사항이 없고 범례도 없네…
A가 B에게 control을 전달?
A가 B에게 데이터를 전달?
A가 B로부터 어떤 값을
가지고 옴?
A가 B에게 메시지를 전달?
A가 B의 서비스를 요청?
A
B
81
Good Example of 아키텍처
소프트웨어
아키텍처
82
아키텍처 문서에 포함되어야
할 내용
소프트웨어

아키텍처
요구사항을 기술하라.

Business Context, Product과 Domain에 대한 이해

품질 요소에 명확한 추출
EAM

EAI
Constraints를 써라.

Business, implementation, deployment
User
Web Browser
Framework
DB
Reporting

Context를 반드시 기술하라.


범례
구성 요소
시스템과 연동되는 외부 시스템, 내부 인터페이스
아키텍처 Diagram

Box, line의 구분

적정한 설명

범례
•
•
•
•
HTTP 호출
. JDBC 호출
사용자는 웹 브라우저를 이용하여 시스템의 초기
화면을 요청한다.
•
초기 화면을 통해 로그인을 요청하면
Framework에서 EAM으로 인증 요청을 하여
처리한다.
인증이 완료되면 사용자의 웹브라우저에 X-internet
제품의 클라이언트 모듈이 탑재되고 이를 통해
Framework 연동하고 비즈니스 로직을 처리한다.
인증 및 권한 정보는 EAI 를 통하여 DB에서
EAM으로 전송된다.
리포팅은 별도의 사용자에게 특정 데이터를 DB에
바로 접속하여 분석하고 별도의 화면으로 제공한다.
(Reporting 관련 로직은 X-internet, Framework과
별도의 아키텍처를 구성한다.)
83
Other aspects



소프트웨어 아키텍처
아키텍처 Design issues

어떻게 요구사항과 constraints를 추출했는지…

Alternatives를 고려해 봤는지…
Style/Product-line issues

어떤 부분은 변하지 않고 유지가 될까?

어떤 부분은 몇 가지 차원으로 구분하여서 표시해야 할까?
Management issues

OA&M : operations, administration, and maintenance
84
아키텍처 작성 기법 – Context
Diagram
소프트웨어
S/W system 및 subsystem 아키텍처를 이해하기 위해, 시스템 내/외
부 환경을 정리한 Picture

외부와 연동하는 환경을 작성

외부 인터페이스위주로 작성

다른 시스템과의 의존성을 표시
중앙예방정보시스템
중앙예방정보
Application
PC Browser
중앙사용자
JGarnet
Framework
각종 통계
보고서
도면
S/W
DataBase
WAS
Data
통합

아키텍처
Data 송수신, SSO인증
연계시스템
시도예방정보시스템
시도예방정보
Application
PC Browser
시도사용자
JGarnet
Framework
Mobile Data
Terminal
무선
인터넷
도면
S/W
DataBase
WAS
Legend
Interaction
Actor
Boundary
Framework
Application
Channel
Repository
85
아키텍처 작성 기법 – Context
Diagram
소프트웨어

아키텍처
Context Diagram은 복잡할 수 있다.
86
아키텍처 작성 기법 – View
및 Style의 혼합 아키텍처
소프트웨어

Viewtype을 목적에 맞게 혼합하여 사용하는 방식

겹쳐서 사용하라

혼합하려는 양쪽의 S/W element(요소)와 relation(연관관계)을 새롭게 정의
하는 hybrid style을 새롭게 정의하라

하나의 viewtype의 S/W element와 relation을 혼합되는 viewtype의 S/W
element와 relation으로 mapping되는 내용을 가지는 bridging document를
가져라.
87
아키텍처 작성 기법 – Hierarchy
소프트웨어

아키텍처
계층적 방법을 이용해서 아키텍처를 구현하는 방식

Module Decomposition view에서의 part-whole 관계

Runtime Tiered view에서의 Substructure
88
소프트웨어 아키텍처 뷰를
선정하는 기준
소프트웨어
이름
아키텍처
설명
사용 목적
Context
Diagram
개발하려고 하는 시
스템과 외부환경을
표시한 다이어그램
이다.
• 이 다이어그램은 시스템 자체에 대한 구조를 표시하는 것이 아니어서
아키텍처로 볼 수는 없다.
• 이 다이어그램을 사용하는 목적은 아키텍트가 아키텍처를 수립할 범
위를 명확히 하기 위해서이고 외부와의 인터페이스(채널)을 확실히 구
분하기 위해서이다.
• 제안서에 이를 표시하는 경우에는 생략해도 무방하다.
Runtime
View
시스템이 동작하고
있는 순간의 스냅샵
의 구조를 작성한
뷰이다.
• 전체 시스템을 이해하거나 시스템의 특정 상태를 설명할 때 유용하게
사용되는 뷰이다.
• 추상화 수준을 조절하여 고객,사용자, PM, PL 등과 대화하기에 유리
한 뷰이다.
• 각종 품질 속성(성능, 안정성, 유지보수성)을 판단할 수 있는 근거를
제공한다.
Module
View
시스템이 작동하기
위해서 존재하는 정
적인 모듈들의 관계
를 나타낸 뷰이다.
• 개발과 관련된 모듈을 표시할 때 유용한 뷰이다.
• 높은 수준의 모듈 뷰는 팀에 작업을 할당하거나 개발 리더들의 관리
도구로 사용될 수 있고 상세한 수준의 모듈 뷰는 개발자와 직접 대화할
수 있는 도구로 사용된다.
Allocation
View
개발되는 소프트웨
어(런타임 컴포넌트
혹은 정적인 모듈)
를 하드웨어나 기타
환경에 맵핑한 뷰이
다.
• 런타임 컴포넌트와 하드웨어와의 관계를 나타낸 deployment 뷰는 성
능과 관련된 부분을 얘기할 때 유리하다.
• 개발 모듈과 개발환경(개발 디렉토리 등)의 맵핑을 나타낸
implement 뷰타입은 개발관계자 와 얘기를 할 경우에 유익하다.
대안 아키텍처 평가 기법소프트웨어
QR2
신규 서비
스 추가 용
이성
아키텍처
(중요도, 난이
도)
품질 요구 사항 시나리오
시스템 개발자가 신규 상품을 시스템에 적용하려 할 때, 기존 상품의 변동 없이 신규
상품(Universal 보험 상품 등은 제외)은 4일 이내, 유사 상품은 4시간 이내에 기간 시
스템 및 SFA에 launch해야 한다. (테스트 시간은 제외)
(상, 상)
범례
Data/Module
Sync.
NCRM
표준 UI
대안
아키텍처
1안
(기간계
Rule에서
신규 상품
을 단독 실
행이 가능
한 java
class로 제
공)
화면을 표준화하여
최소한의 수정으로
SFA에 적용
F/W
SFA S/A
Client
Module
공통 Module
1
SFA UI
신규 클래스
그대로 제사용
2
신규 Rule
Logic class
I/F
서비스
클래스.
신규
Rule
Logic
class
신규 Rule
Logic class
SFA AP
데이터 Sync.
class
기간계 DB
신규
정보/데이터
SFA DB
EAI
DBIO
SFA S/A DB
신규
정보/데이터
신규
정보/데이터
대안 아키텍처 평가 기법소프트웨어
QR2
신규 서비
스 추가 용
이성
(중요도, 난이
도)
품질 요구 사항 시나리오
시스템 개발자가 신규 상품을 시스템에 적용하려 할 때, 기존 상품의 변동 없이 신규
상품(Universal 보험 상품 등은 제외)은 4일 이내, 유사 상품은 4시간 이내에 기간 시
스템 및 SFA에 launch해야 한다. (테스트 시간은 제외)
XInternet
대안
아키텍처
2안
(신규 상품
요구 사항
을 가지고
기간계와
별도로 개
발)
아키텍처
범례
표준 UI
Data/Module
Sync.
공통 Module
SFA S/A
신규 개발 모듈
(상, 상)
SFA S/A
Client
Module
SFA UI
F/W
SFA AP
Rule
Eng.
신규
Rule
Logic
(XML)
데이터 Sync.
class
SFA DB
기간계 DB
신규
정보/데이터
EAI
신규
정보/데이터
신규 Rule
Logic class
DBIO
SFA S/A DB
신규
정보/데이터
대안 아키텍처 평가 기법소프트웨어
아키텍처
대안 아키텍처
Sensitivity
Tradeoff
Risk
대안 아키텍처 1
1, 3, 4, 5
1
1, 2, 3, 4
대안 아키텍처 2
2, 6, 7, 8, 9
2
5, 6, 7
Sensitivities
1.
2.
3.
4.
5.
6.
7.
8.
9.
중복되는 로직이 많을 경우
중복되는 기능이 많지 않을 경우(혹은 중복될 만한 내용은 Rule을 통해 커버하는 경우)
개별 애플리케이션 단위의 개발 및 유지보수 최적화 보다는 동기화를 비롯한 두가지
애플리케이션의 개발 및 유지보수 최적화를 목표로 할 경우
공유 로직으로 파악된 내용이 화면 수준에서도 동일한지, 향후에도 계속 재사용될 수
있는지에 대한 확신이 있을 경우
공유 로직을 잘 관리하고 개발자가 트러블을 통제할 만한 역량이 있을 경우
늘어나는 개발 및 유지보수 물량이 부담되지 않을 경우
개별 애플리케이션의 개발 및 유지보수의 최적화가 우선적인 경우
지금은 동일 기능이라 할지라도 향후 서로가 어떻게 진화할지 확신이 없는 경우
공유 로직에 대한 관리력이 문제가 될 경우 (개발자간 책임 전가 등)
Tradeoffs
1.
확장성과 유연성
2.
유연성 및 유지 보수성
대안 아키텍처 평가 기법소프트웨어
아키텍처
Risks
1.
2.
3.
4.
5.
6.
7.
로직의 재사용성 확보를 위한 어플리케이션 구조의 복잡도 증대(개별 어플리케이션으로 보면
개발 및 유지보수 생산성이 오히려 낮아질 수 있음
이로 인해 어플리케이션의 런타임 속도에 영향을 줄 수 있음
개별 어플리케이션의 요구사항이 조금씩 달라질 경우 (화면 입출력 단위 및 기타) 대응이
어렵고 변경 사항이 의도하지 않게 타 어플리케이션에 전달될 수 있음
공유 로직의 관리 및 개발자간 커뮤니케이션에 적지 않은 비용이 들어감 (공유 로직의 개발
담당자가 명확해야 함)
동일 로직의 중복된 개발로 전체적인 개발 및 유지 보수성이 떨어짐
로직의 변경이 발생할 경우 두 어플리케이션을 각기 수정해야 하는 번거로움으로 동기화에
대한 관리가 어려움
독립적으로 구현되므로 경우에 따라서는 하나의 유지보수자가 동일한 내용을 수정하기 위해 두
가지의 애플리케이션 구조를 파악하고 있어야 함
품질 요소
대안 아키텍처 1
대안 아키텍처 2
확장성
+
-
안정성
-
+
유연성
+
+
유지보수성
+
-
SKC&C 수립 방법론
아키텍처
결정요인 도출
비즈니스 요구사항
파악
아키텍처
전략 정의
아키텍처 수립
전략 설계
(참조 아키텍처)
제약 사항
파악
(Optional)
품질 속성
분석
소프트웨어 아키텍처
아키텍처
구성 요소 도출
(Optional)
아키텍처
구성 원칙 정의
(Optional)
아키텍처
수립
아키텍처
평가
Runtime
View
수립
Module View
수립
Allocation
View
수립
아키텍처 Review
(대안 평가 활용)
아키텍처
품질 평가
(프로토타이핑)
SKC&C 수립 방법론
가이드
프로젝트
제안요청서
프로젝트
계획서
Biz. 분석
및 목표
상위수준의
기능요구
사항
(Use Cases)
비즈니스
요구사항
파악
Stakeholders
리스트
프로젝트
분석/설계
표준 정의
아키텍처 수립
전략 설계
참조 아키텍처
선정 리스트
Context
Diagram
품질 속성
시나리오
Asset
(참조 아키텍처)
예제
템플릿
Runtime
View
수립
Runtime
구조도
제약 사항
리스트
Context
Diagram
아키텍처
구성 요소
도출
구성요소
리스트
제약 사항
파악
품질 속성
분석
H/W, S/W
목록
(구성도)
Stakeholders
리스트
소프트웨어 아키텍처
Module View
수립
Runtime
View
아키텍처
구성 원칙 정의
구성 원칙
리스트
Module
View
아키텍처
정의서
Runtime
행위도
아키텍처
평가
아키텍처
정의서
Allocation
View
수립
Allocation
View
아키텍처
Review
대안
아키텍처
평가서
프로토타입
계획서/
결과서
참조 문서
Software Architecture
in Practice, Second
Edition, by Len Bass,
Paul Clements, and
Rick Kazman,
Addison-Wesley
2003
소프트웨어 아키텍처
Documenting
Software
Architectures:
Views and
Beyond, by
Clements, et al.
Addison-Wesley
2003
소프트웨어
아키텍처
이론과 실제
Software
Architecture in
Practice 번역본
김정호, 송재하 역 ,
에이콘 2007
96
참조 문서
Pattern Oriented Software
Archiecture, Volume 1: A
system of Pattern, Frank
Buschmann, Willy 1996
소프트웨어 아키텍처
객체지향 CBD 개발
방법론(.NET),
전병선
컴포넌트비젼㈜
Evaluate Software Architecture:
Methods and Case Studies by
Paul Clements, Rick Kazman,
and Mark Klein. Published by
Addison Wesley Professional.
97
소프트웨어 아키텍처
Question ?
98