Based on the Book "Documenting Software Architectures 2rd"

1. Software Engineering Lab
김영기책임
resious@gmail.com
Documenting Software Architectures

2. This Slide based on following book …

3. Contents
1
A Collection of Software Architecture Style
C1
Module Views
C2
A Tour of Some Module Style
C4
Tour of Some Component-and-Connector Styles
C6
Beyond the Basics
C3
Component-and-Connector Views
C7
Documenting Software Interfaces
C5
Allocation Views and a Tour of Some Allocation Styles
2
Beyond Structure: Completing the Documentation
C8
Documenting Behavior
C10
Building the Documentation Package
C9
Choosing the Views
C11
Reviewing an Architecture Document
3
Building the Architecture Documentation

4. A COLLECTION OF SOFTWARE ARCHITECTURE STYLE
Part I

5. I.1 Three Categories of Style
아키텍처스타일(Architecture Style)
3가지아키텍처스타일
문서화시각스타일에해당하는View가적어도하나씩포함되어야한다.
아키텍처스타일과아키텍처패턴
아키텍처스타일과아키텍처패턴을구별하지않고사용
아키텍처패턴–시스템의많은아키텍처컴포넌트중일부에만국한
아키텍처스타일–아키텍처패턴보다는좀더광범위한디자인솔루션
아키텍처스타일은아키텍처설계에서반복해서나타나는문제를해결하고아키텍처가만족시켜야하는시스템품질속성을달성할수있는방법을문서로정리한것이다
모듈스타일
(ModuleStyle)
특화된모듈타입들을소개
모듈타입들의요소들이어떻게결합하는지에대한규칙을지정
컴포넌트와커넥터스타일
(Component-and-Connector Style)
컴포넌트와커넥터관점에서실행시행위를기술
데이터와컨트롤플로우기술
할당스타일
(Allocation Style)
개발환경또는실행환경의요소와소프트웨어요소간의맵핑기술

6. I.2 Style Guides
스타일가이드(Architecture Guide)
스타일을설명하기위한기준구성
각각의스타일에대한비교와선택에대한일관적인기술이중요
스타일가이드의전체적인구성과섹션의내용
개요(Overview)
왜해당스타일이유용한지설명
-시스템과해당스타일이시스템을어떻게지원하는지기술
요소(ElementTypes)
관계(Relation Types)
특성(Properties)
Elements
아키텍트의구성요소
요소타입을정의하고, 스타일을사용하는아키텍처가요소의인스턴스를어떻게사용하는지정의
Relations
관계타입을정의
요소들간동작방법및협력관계를제공
Constraints
스타일의유효한인스턴스를형성하기위한요소(element)와관계(relation)간의규칙을나열
Whatit’s for
스타일에서뷰(View)에의해지원되는추론의종류를기술
Notations
스타일의뷰를문서화할때이용가능하고유용한그래픽/텍스트표현의기술
Relation to other styles
해당스타일에서유도된다른스타일에서유도된뷰와연관되어야하는지를기술
Examples
주어진스타일에서유도된뷰의문서화예제를제공

7. I.3 Choosing Properties to Document
최종목표는선택된스타일에기반한뷰(Views)를기술하는것
뷰를문서화하는것은문서화할요소의특성을결정하는것
요소의이름(Name), 역할(Role), 책임(Responsibility)
아키텍처기반의분석을지원하는특성들
–성능(Performance) : 요소의최고/최하응답시간, 요소의최대이벤트처리량, …
–보안(Security) : 암호화레벨, 인증규칙등…
하나의뷰는하나이상의스타일을나타낼수있다.
Zachman
Framework for Enterprise Architecture

8. I.4 Notations for Architecture Views
표기법(Notations)
뷰를문서화하기위한표기법은형식성(Formality)의정도에따라구별
비공식적인표기법
(InformalNotations)
선택된시스템을시각적인관례를일반적인목적의다이어그램과편집도구를이용한표기
자연어로기술되고, 특성화된의미(Semantic)은형식적으로분석하기어려움
준정형적표기법
(Semiformal notations)
미리제공된그래픽요소와구성규칙에따른표준화된표기법에의해기술된뷰
요소들의완전한의미적처리를제공하지는못한다. -UML
초보적인분석이적용가능
정형적표기법
(Formalnotations)
일반적으로수학적방법에기반한정확한의미를갖는표기법
구문과의미에대한형식분석이가능
-때때로특정스타일에특화됨
ADLs :Architecture Description Language
-도구와연계되어자동화된분석이가능함
There is no greater impediment to the advancement of knowledge than the ambiguity of words
-ThomasReid,
ScotishPhilosopher

9. MODULE VIEWS
Chapter. 1

10. 1.1 Overview
이번장에서는모듈뷰측면에서아래사항을살펴본다.
요소(Elements), 관계(Relations), 그리고특성(Properties)
목적(Purpose)과표기법(Notation)
다른뷰와의관계(Relation to other views)
요소
(Elements)
모듈은소프트웨어의구현단위
모듈은책임들의응집된셋을제공
관계
(Relations)
Ispart of :서브모듈과파트, 전체와연관모듈의부분과전체의관계를정의
Depends on : 두모듈사이의종속성을정의
Is a : 둘이상의특정모듈사이의일반화/특화관계를정의
제약사항
(Constrains)
여러모듈뷰들은토플러지에따른제약사항(Topological Constraints)을내포할수있음
목적
(WhatIt’s For)
코드작성을위한청사진제공
영향도분석향상
점진적개발계획
요구사항추적성분석지원
코드베이스의구조와시스템의기능성설명
작업할당, 구현일정, 예산정보정의지원
지속되어야하는정보구조설명

11. 1.2 Elements, Relations, Properties of Module Views
요소(Element)
모듈(Module)은책임의응집된셋을제공하는S/W의구현단위
책임(Responsibility)는아키텍처에기여하기위해예상되는것
시스템품질속성이나기능을위해수행되어야하는행위, 유지되는지식, 수행하는역할등을포함
모듈은합성(aggregated)이나분해(decomposed)가가능
관계(Relation)
Ispart of
Depends on
Is a

12. 1.2 Elements, Relations, Properties of Module Views
특성(Properties)
뷰에대한보조문서의부분으로기록
위의속성외에도뷰타입의스타일별로도속성이더있다.
이름
(Name)
모듈을식별하는가장기본적인장치
이름을통하여시스템내의역할을짐작할수있는경우가많다.
책임
(Properties)
시스템전반에걸쳐해당모듈이하는역할을알수있다.
모듈의책임을기술할때는모듈의역할을명확히알수있도록자세히기술
인터페이스가시성
(Visibilityof Interfaces)
모듈의인터페이스문서는시스템내에서해당모듈이맡은역할을상세하게정의
모듈을어떻게호출하면시스템내에서맡은역할을수행하게되는지를명세
구현정보
(Implementationinformation)
모듈은구현의단위이기때문에, 아래의정보를기록해두면유용
코드단위들간의매핑
테스트정보
관리정보
구현제약사항

13. 1.3 What Module Views Are For
모듈뷰의사용
구축(Construction)
소스코드작성의청사진:
–모듈은소스코드나디렉터리같은물리적구조와대응
분석(Analysis)
요구사항에대한추적용이성(Requirement Traceability)
–모듈의할당책임을가지고시스템의기능요구사항지원을예측
영향도분석(Impact Analysis)
–시스템변경으로발생할수있는영향을예측하는데활동
의사소통(Communication)
시스템이익숙하지않은사람에게시스템의기능을설명
시스템에부여된책임을하향식으로표현하는것이가능
–다양한규모의학습과정을이끄는지침으로활용가능
호출내용의문서화
설계완결성과모듈의무결성이중요
모듈뷰타입은S/W 기능을나누는것에쓰이기때문에실행시간의행위에대한추론은어렵다.

14. 비공식적인표기
준-정형적표기법(Unified Modeling Language, UML)
다양한종류의모듈을표현하는데활용가능함
1.4 Notations for Module Views
다양한표기법을통해모듈뷰표현가능
모듈에책임에대한설명을덧붙여사용
모듈
depend-on 관계
Module A
Imports Modules B,C

15. DSM(Dependency Structure Matrix)
시스템내의많은요소들과요소간의관계를나타냄
요소간의영향도를쉽게파악할수있음
ER 다이어그램(Entity-Relation Diagram)
데이터모델링에특화되어사용
1.4 Notations for Module Views
Design Structure Matrix
Domain Mapping Matrix
Multiple-Domain Matrix

16. 1.5 Relations to Other Views
모듈뷰는…
일반적으로C&C 뷰타입의뷰들과대응
모듈뷰의구현단위= 실행시간의수행컴포넌트
다른뷰에필요한정보가과도하게포함되는문제
제대로알고있지않는경우, 혼동을유발시킴

17. A TOUR OF SOME MODULE STYLE
Chapter. 2

18. In this Chapter …
6가지주요모듈스타일
분할스타일
(DecompositionStyle)
모듈과서브모듈의구조를보여주기위해사용
사용스타일
(UsesStyle)
모듈간의기능종속관계를표시하기위해사용
일반화스타일
(GeneralizationStyle)
모듈간의특화관계를표시하기위해사용
계층스타일
(LayeredStyle)
계층이라불리는모듈의그룹사이의제한된형식에서, 사용허용(allowed-to- use)관계의제한된방식을설명
관점스타일
(AspectsStyle)
횡단관심(crosscuttingconcerns)에책임이있는관점(Aspects)이라불리는특정모듈을기술하기위해사용
* 핵심관심: 시스템이추구하는핵심기능및가치
* 횡단관심: 핵심관심에공통적으로적용되는공통모듈
데이터모델스타일
(Data Model Style)
데이터엔티티간의관계를보여주기위해사용

19. 2.1 Decomposition Style
개요
분할뷰는모듈과서브모듈로써의코드의구조(organization)을설명
Is-part-of 관계에중점
시스템의책임이어떻게모듈에걸쳐나뉘어지는가를보여줌
분할정복기법(Divide-and-Conquer Technique)
모듈을더작은모듈로분해하는것은아래사항을포함
–특정품질속성의성취
–구현(Build)또는구매(Buy)에대한결정
–제품라인구현
–팀할당
모듈의크기는버리고다시시작할수있는정도의작은크기가좋다.
분할뷰에서정의된모듈은다른뷰에서계속해서나타날수있다.
Uses, Layered, Generalization, and …

20. 2.1 Decomposition Style
요소, 관계, 속성
분할스타일의요소는모듈
일부모듈은다른모듈과집합하여서브시스템으로불린다.
하위모듈은오직집합모듈내에서만보여질수있다.
개요
(Overview)
시스템을구현단위로분해하는데사용
코드의모듈구조와시스템의책임이어떻게분해되는가를설명
요소
(Elements)
모듈
관계
(Relations)
분할관계(Decomposition): is-part-of 의형식을갖는다.
제약사항
(Constraints)
분할그래프에서루프는허용되지않는다.
모듈은오직하나의부모를갖는다.
목적
(WhatIt’s For)
신입과요약된크기로소프트웨어의구조에대한왜이유와의사소통을위해
작업할당에대한입력을제공하기위해
지역적인변화에대한사유

21. 2.1 Decomposition Style
분할스타일의용도
시스템의책임을상세하고, 정제가능한수준의표현
아키텍트의설계작업을지원
시스템의전체적인기능을관련자에게알려주는도구로활용
작업할당스타일에서활용
소프트웨어요소를개발조직단위와매핑
제한적수준의영향도분석지원가능
표기법
모듈은중첩(nested)될수있다.
[ 비정형적표현]
[ UML ]

22. 2.1 Decomposition Style
다른스타일과의관계
분할뷰는하나이상의C&C 뷰와매핑이가능
소프트웨어의구현구조가실행구조와어떤연관이있는지를보여준다.
–하나의모듈여러개의C&C 컴포넌트
–여러개의모듈하나의C&C 컴포넌트
분할뷰는배치스타일의할당뷰와연관
모듈과구현의책임을보여준다.

23. 2.2 Uses Style
개요
모듈사용관점에서모듈뷰의Depends-on 관계가특화된형태
Uses : 하나의모듈이다른모듈을사용
모듈스타일의기능단위의구성에모듈의사용관계까지보여줌
시스템의모듈이정상적으로동작하기위해서는다른모듈필요함을알려줌
시스템의증분적(incremental)개발, 확장, 디버깅, 테스팅등에사용
요소, 관계, 속성
개요
(Overview)
모듈간의종속성이어떤지보여줌
요소
(Elements)
모듈
관계
(Relations)
사용관계(Uses): Depends-on 관계의한형식
-모듈A가자신의요구를만족시키기위해모듈B의기능에의존
제약사항
(Constraints)
구성상의제약사항없음
-Loop, broad fan-out, dependency chain은아키텍처의기능을떨어뜨림
목적
(WhatIt’s For)
증분개발과하위세트(Subset)의개발계획
디버깅과테스트
변화의효과를측정

24. 2.2 Uses Style
사용스타일의용도
증분개발과하위세트(Subset)의개발계획
디버깅과테스트
변화의효과를측정
시스템구축, 유지보수시종속성관리에활용(유지보수성관리)
표기법
[ 비정형적표현]
[ UML ]
[ DSM ]

25. 2.2 Uses Style
다른스타일과의관계
계층(Layered) 스타일과관계
Allowed-to-use 관계
개발자에게잘정제되지않았지만(Coarse-grained), 자유도의정도를지시
모듈의일관성
–분할(Decomposition)은하위모듈에대한전체모듈의사용관계를포함
인터페이스를명시적으로보여줄수있다.

26. 2.3 Generalization Style
개요
일반화를위해모듈뷰의is-a 관계가특화된형태
일반화는인터페이스와구현의상속을나타낸다.
아키텍처와개별요소의확장과진화를지원
모듈의확장은자식모듈의추가, 삭제, 변경을통하여이루어질수있다.
모듈의공통부분과가변부분을분리하기이해사용
요소, 관계, 속성
부모(Parent)모듈은자식(Child)모듈보다더일반적이다.
개요
(Overview)
아키텍처와개별요소의확장과진화를지원하기위해is-a 관계를사용
요소
(Elements)
모듈: 모듈뷰에서정의된속성외에“abstract” 속성이추가됨
관계
(Relations)
일반화관계(Generalization): is-a 관계로부터정련됨, 특화된상태를나타냄
제약사항
(Constraints)
하나의모듈은여러개의부모를가질수있다.
일반화관계에서순환(Cycle)은허용되지않는다.
목적
(WhatIt’s For)
객체지향설계에서상속을표현
부분적인진화와확장을설명
자식의다양한변화와공통성을추출
재사용을지원

27. 2.3 Generalization Style
일반화스타일의용도
객체지향설계(Object-oriented Design)
시스템의객체지향설계에서상속을표현
확장(Extension)
한모듈이다른모듈과어떻게다른지쉽게이해를돕는다.
지역적인변경과변형(Local change or Variation)
안전한전역적구조와지역적인변경과변형을수용
–상위모듈의공통성과하위모듈의변형사항을정의
재사용(Reuse)
추상모듈의정의는재사용의위한기회를창출
표기법
[ UML ]

28. 2.3 Generalization Style
다른스타일과의관계
상속및인터페이스구현관계를다른모듈과의관계로보완
복잡한모듈의계층구조를포함하고있다면…
상속관계를분리된다른타입의관계로보여주는것이좋다.

29. 2.4 Layered Style
개요
계층스타일은소프트웨어를단위별로분할하는것을의미
제약사항: 계층간의Allowed-to-use 관계가있다.
계층구조는변경용이성(modifiability)과이식성(portability)을향상시킨다.
계층은엄격한순차적관계에의하여상호작용을한다.
–일반적으로상위계층이하위계층을사용하는관계
–Layer bridging : 상위계층이바로아래의하위계층이아닌하위계층을사용하는경우
계층은소스코드를기반으로나누어지지않는다.

30. 2.4 Layered Style
요소, 관계, 속성
개요
(Overview)
계층간의단방향적인사용허용관계를나타낸다.
계층은응집된서비스의세트를제공하는모듈의그룹을말한다.
요소
(Elements)
계층(Layer) : 계층은포함하고있는모듈을정의해야한다.
관계
(Relations)
사용허용(Allowed-to-use): 일반적인종속관계(Depends-on )의특화
디자인시계층간사용규칙을정의해야한다.
제약사항
(Constraints)
소프트웨어의모든부분은정확히한계층에할당되어야한다.
적어도2개이상의계층이존재해야한다.
사용허용관계가순환(Cycle) 되면않된다.
목적
(WhatIt’s For)
변경용이성과이식성증대
코드구조복잡성을관리하고개발자들에게코드구조에대한의사소통을촉진시킨다.
재사용의증진
관심의분리

31. 2.4 Layered Style
계층스타일의용도
변경용이성과이식성증대
코드구조복잡성을관리
계층은시스템구축시아키텍처의청사진의일부분
개발자들에게코드구조에대한의사소통을촉진시킨다.
일반적인오해–계층은추가적인실행시오버헤드를가진다.
구현책임을특정팀에할당하는것을돕는다.
재사용의증진
아키텍처구조분석을돕는다.
관심의분리
변경에대한영향도분석을돕는다.
변경의범위를정하는것을가능하게한다.

32. 2.4 Layered Style
표기법
[ Stack ]
[ Segment Layers ]
[ Rings]
[ Layers with a Sidecar]
[ Size and Color]
[ UML ]

33. 2.4 Layered Style
다른스타일과의관계
모듈분할(Module Decomposition)
계층뷰의계층은분할뷰의모듈과항상연관되지만, 대부분일대일관계는아니다.
–계층은하나이상의모듈로구성된다.
–같은모듈의서로다른서브모듈을다른계층에존재할수있다.
계층(Tiers)
계층(Layer)는다중계층구조의계층(Tier)와혼동된다. (Layer≠Tier)
계층스타일(Layered Style)는구현단위의모임을나타내며, 모듈스타일의한종류
다중계층스타일은C&C 스타일로실행시의컴포넌트에집중
모듈“사용”스타일(Module “uses” style)
계층은사용허용(Allowed-to-use) 관계를표현

34. 2.5 Aspects Style
개요
다수의영역들에걸쳐진공통의관심사로모듈로부터독립시킴
비기능적요소는여러기능들에공통적으로요구되는경우가많다.
측면스타일은크로스커팅된기능의책임이있는모듈
하나또는그이상의측면뷰에배치해야된다는것을규정한다.
측면스타일은AOP를사용하여구현시유용
Crosscutting concerns은
여러기능들에공통적으로요구되는것을의미한다.
[ AOP Examples ]
관점지향프로그래밍
(Aspect Oriented Programming,AOP)
핵심관심사(core concerns)에대한관점과횡단관심사(cross- cutting concerns)에대한관점들로프로그램을분해해객체지향에서추구하는모듈화를더잘지원하기위한프로그래밍기법
관점지향프로그래밍이라고하는것은관심의분리(Separation of Concerns)를통해기존클래스의비즈니스핵심로직은유지하고변경은최소화하면서공통기능의중복코드를특수한기법으로관통하여사용할수있도록하는것이다.

35. 2.5 Aspects Style
요소, 관계, 속성
관점스타일의용도
횡단관심사에대한구현모델링
변경용이성의증진: 기능의꼬임상태를회피
개요
(Overview)
횡단관심사(crosscutting)를구현하는관점모듈(aspect modules)과관점모듈이시스템내의다른모듈과어떻게바인딩되는가를보여준다.
요소
(Elements)
관점객체(Aspect ) :횡단관심의구현을포함하는특화된모듈
관계
(Relations)
횡단(Crosscuts) : 관점모듈을관점측면의횡단로직에의해영향을받을수있는다른모듈과엮는다.
제약사항
(Constraints)
하나의관점(aspect)은관점모듈은물론, 하나또는그이상의정상모듈과횡단(crosscut)이가능하다.
하나의관점(aspect)는구현에의존하여횡단으로인한무한재귀를유발할수있다.
목적
(WhatIt’s For)
객체지향설계에서횡단관심사(crosscutting concerns)를모델링
변경용이성의향상

36. 2.5 Aspects Style
표기법
관점객체(aspects)에대한UML 상의내장된기호는없다.
Crosscut 관계는종속성의스테레오타입으로표현가능

37. 2.6 Data Model
개요
데이터모델링: 정보시스템의개발프로세스의중요한액티비티
데이터모델
데이터엔티티와엔티티간의관계로정적정보구조를표현
ERD(Entity-Relation Diagram)으로표현가능
개념데이터모델
논리데이터모델
물리데이터모델

38. 2.6 Data Model
요소, 관계, 속성
개요
(Overview)
데이터엔티티와엔티티간의관계를나타낸다.
요소
(Elements)
데이터엔티티(DataEntity) : 시스템에저장하거나표현되어야할필요가있는정보를가지고있는객체
-특성으로이름, 데이터속성, 기본키(Primary Key), 엔티티에대한사용자권한규칙등
관계
(Relations)
일대일(One-to-one), 일대다(One-to-many), 다대다(Many-to-many)관계
일반화(Generalization)/특화(Specialization)
집합(Aggregation)
제약사항
(Constraints)
기능적인종속관계를피해야한다.
목적
(WhatIt’s For)
시스템내에서사용되는데이터를기술한다.
데이터모델의변경에따른영향도분석을수행한다. (확장성분석)
중복과데이터의일관성결여를회피함으로써데이터품질향상을강제화
데이터에접근하는모듈의구현에대한가이드

39. 2.6 Data Model
데이터모델의용도
이해당사자와의의사소통을촉진
도메인분석과요구사항추출
성능요구사항, 비정규화(demoralization), 최적화(optimization), 디자인결정에활용
정보시스템: 변경용이성의분석
구조적측면의데이터무결성에대한강제화를돕는다.
데이터모델에기반하여물리적데이터베이스생성스크립트작성
응용프로그램개발자게데이터베이스접근코드를작성하는것을돕는다.
표기법
[ ERD]
[ UML ]

40. 2.6 Data Model
다른스타일과의관계
모듈뷰의모듈과본질적으로관련이있음
모듈은본질적으로데이터를포함
객체지향에서데이터저장을위해관계형데이터베이스를사용
데이터저장소는공유데이터뷰에기술
배치뷰는데이터저장소의하드웨어머신으로의할당을표현
데이터모델과여러데이터저장소의매핑관계의문서화
분산데이터베이스나데이터베이스복제솔루션을사용할때유용

41. COMPONENT-AND-CONNECTOR VIEWS
Chapter. 3

42. 3.1 Overview
컴포넌트와커넥터뷰(Component & Connect View, C&C View)
실행시간나타나는요소들로구성된모델을다룸
선과도형위주의다이어그램
–정형화되지않는경우불명확, 일관성결여의여지
실행시간에나타나는시스템의전체윤곽을보여줌
컴포넌트
프로세스, 객체, 클라이언트, 서버, 데이터저장공간
커넥터
통신연결, 통신규약, 정보흐름, 공유저장소
커넥터는2개이상의대상을연결할수도있다.

43. 3.2 Elements, Relations, and Properties of C&C Views
요소
(Elements)
컴포넌트:기본적인처리단위와데이터저장공간을나타낸다.
커넥터: 컴포넌트사이의상호작용방식
관계
(Relations)
붙임(Attachments) :컴포넌트의포트는특정커넥터의역할과관련이있다.
인터페이스위임(InterfaceDelegation) : 임의의상황에서컴포넌트포트는내부적인하위구조에대한하나이상의포트와관련이있다.
제약사항
(Constrains)
컴포넌트는오직커넥터와연결된다. 다른컴포넌트와는연결될수없다.
커넥터는오직컴포넌트와연결된다. 다른커넥터와는연결될수있다.
붙임은호환가능한포트와역할사이에만만들어질수있다.
인터페이스위임은두개의호환가능한포트사이에서만정의된다.
커넥터는고립되어나타날수없으며, 반드시컴포넌트와연결되어야한다.
목적
(WhatIt’s For)
시스템이어떻게동작하는지를보여준다.
실행요소의구조와행위를규정함으로개발에도움을준다.
성능, 신뢰성, 가용성과같은런타임시스템품질속성에대한근거가된다.

44. 3.2 Elements, Relations, and Properties of C&C Views
요소(Elements)
C&C 뷰의요소는컴포넌트와커넥터
시스템상의실행시간의현상을보여준다.
C&C 뷰는시스템의실행시구성형태를그래프로표현
컴포넌트를커넥터에연결하여관계를나타낸다.
컴포넌트(Components)
컴포넌트의이름은컴포넌트에부여된기능을가리켜야한다.
이름으로시각적으로표현된요소와보조문서를연계시킬수있어야한다.
포트(Port) : 컴포넌트가가지는인터페이스
컴포넌트가환경과잠재적인상호작용의특정접점을정의한다.
컴포넌트의포트에대한문서화는명확하게, 특히포트의개수와종류

45. 3.2 Elements, Relations, and Properties of C&C Views
커넥터(Connectors)
실행시간에두개이상의컴포넌트사이의상호작용이일어나는경로
프로시저호출, 비동기메시지, 이벤트전송, 파이프等
때때로커넥터를통해나타내는상호작용은통신규약으로설명
역할(Role) : 커넥터가가지는인터페이스
커넥터의상호작용의접점을정의
컴포넌트들이커넥터를활용해상호작용시따라야하는방식
C&C 타입과인스턴스(Types and Instances)
C&C 뷰내의컴포넌트와커넥터는C&C Type의인스턴스를기술한다.
C&C 뷰를문서화할때
–어떤아키텍트스타일이사용되었는지명확히하라
–뷰에서추가적인컴포넌트나특화된커넥터를문서화하라
–같은다이어그램에여러타입과인스턴스를함께쓰는것은좋지않다.
통신규약(Protocol)은어떤상호작용이일어나면서발생하는이벤트나동작의패턴을설명
타입들은스타일가이드에
정의되어있으며, 하나의스타일에제약사항이더해지면새로운스타일로특화될수있다.

46. 3.2 Elements, Relations, and Properties of C&C Views
관계(Relations)
붙임(Attachment)
커넥터가어떤컴포넌트에연결될것인지정의
–컴포넌트의포트와커넥터의역할의연관을나타냄
–스타일에정의된의미적인제약사항내에서컴포넌트의포트와커넥터의역할이상호호환되어야한다.
인터페이스위임(Interface Delegation)
컴포넌트나커넥터가하위구조를가질때
–내부적인구조와외부적인인터페이스의관계를나타냄
–일부표기법은이러한관계를나타내기위해특정그래픽요소를제공

47. 3.2 Elements, Relations, and Properties of C&C Views
특성(Properties)
모든요소는이름(Name)과타입(Type)을가진다.
–추가적인특성은컴포넌트또는커넥터의타입에의존한다.
일반적인속성
신뢰성
(Reliability)
컴포넌트나커넥터에서주로장애가발생하는곳은?
이속성은시스템전반적인신뢰성을가능하게해준다.
성능
(Performance)
컴포넌트에부하가걸리때반응속도의변화는?
커넥터에서예상되는지연시간과처리량은?
지연시간이나처리량,버퍼요구량과같은시스템속성을정할수있게한다.
자원요구량
(Resource requirements)
컴포넌트와커넥터에서필요로하는처리및저장용량은?
제시된하드웨어구성이적합한지평가하는데사용
기능성
(Functionality)
요소가수행하는기능은무엇인가?
시스템에서수행되는연산전반에대한근거를추측해볼수있다.
보안
(Security)
암호화나감사추적, 인증과같은시스템보안사항을제공/강화하는가?
시스템의보안취약성을알아보는데유용
동시성
(Concurrency)
컴포넌트가분리된프로세스나스레드에서실행되는가?
동시에동작하는컴포넌트의성능을분석/시뮬레이션하고데드락(dead lock)문제를정의
계층
(Tier)
계층구조에서컴포넌트가위치하는계층은?
각계층의플랫폼요구사항과빌드와배포절차를정의하는데도움
분석을위한뷰?
의사소통을위한뷰?
상황에따라속성에대한선택이필요하다. !!!

48. 3.3 What C&C Views Are For
C&C 뷰타입의용도
시스템이어떻게동작하는지알고자할때사용
시스템실행시품질속성에대한근거를찾을때사용
성능, 신뢰성, 가용성
C&C 뷰를활용하면다음질문의답을얻을수있다.
시스템에서가장기본적으로실행되는컴포넌트는무엇이고, 어떤식으로상호작용을하는가?
공유데이터저장공간은주로어떤것을사용하는가?
시스템의어느부분을얼마나복제해둘것인가?
시스템이수행되는동안데이터는어떻게흘러다니는가?
통신하는실세사이에사용되는상호작용프로토콜은무엇인가?
시스템내에서병렬적으로작동하는부분은어디인가?
시스템이실행하는동안어떤방식으로시스템구조가변경될수있는가?

49. 3.4 Notations for C&C Views
비공식적인표기법
Box-and-line 다이어그램
제한된의미를전달사람마다표기법해석이다른문제발생
엄격하고깊이있는문서화를위해서는…
–각각의컴포넌트와커넥터타입을분리된시각화형식으로표현
–타입의이름은의미를포함해야한다.
–커넥터의경우화살표의방향등에대한의미를명확히해야한다.
정형적표기법
아키텍처표기언어(ADLs)

50. 3.4 Notations for C&C Views
준-정형적표기법(Unified Modeling Language, UML)
[Component]
[Specialized Component]
[Port]
[Port with Interface]
[Connector]

51. 3.4 Notations for C&C Views
준-정형적표기법(Unified Modeling Language, UML)
[ C&C Types ]

52. 3.5 Relation to Other Kinds of Views
C&C 뷰와모듈뷰사이에는요소들간의대응관계
동일코드모듈이C&C 뷰에서는여러요소에의해실행될수있다.
C&C 뷰의한요소는여러모듈의정의된코드를실행시킬수있다.
C&C 컴포넌트는주위환경과상호작용을하는접점이여러개있을수있으며각지점은동일한모듈인터페이스로정의될수있다.
모듈뷰의모든요소가C&C 뷰에표현되지않는다.
C&CView
Module View
System as a whole
main
Split
Split, config, stdio
To-lower
to-lower, config, stdio
To-upper
to-upper, config, studio
Merge
merge, config, stdio
Each pipe
stdio
[ C&C 뷰와모듈뷰간의Mapping ]

53. TOUR OF SOME COMPONENT-AND-CONNECTOR STYLES
Chapter. 4

54. 4.1 An Introduction to C&C Styles
C&C Views
시스템의실행측면의특성을본다.
계산모델과설계된시스템에서의데이터와컨트롤흐름을기술한다.
C&C 스타일의선택은시스템의실행시특성에의존한다.
또한, 문서화의사용의도에의존할수있다.
호출-반환스타일
(Call-returnStyle)
한컴포넌트가다른컴포넌트가제공하는기능의동기적인호출을통해상호작용하는스타일
데이터흐름스타일
(Dataflow Style)
시스템에걸친데이터의흐름에의해계산이구동되는스타일
이벤트기반스타일
(Event-basedStyle)
컴포넌트들이비동기적이벤트나메시지에의해상호작용하는스타일
저장소스타일
(RepositoryStyle)
컴포넌트들이영구적이고, 공유되는대규모데이터의집합체를통하여상호작용하는스타일

55. 4.1 An Introduction to C&C Styles
A partial representation of the space of C&C style

56. 4.2 Data Flow Styles
데이터흐름스타일(Data Flow Style)
데이터흐름스타일은계산모델을포함한다.
컴포넌트(Component) : 데이터변환기로서동작
커넥터(Connector) : 한컴포넌트의출력을다른컴포넌트의입력으로전달
데이터흐름스타일
[ Batch sequential ]
[ Pipe-and-filter ]
Validate
Sort
Update
Report
tape
tape
tape
tape
tape
report
Data Flow
Data Transformation

57. 4.2.1 Pipe-and-Filter Style
개요
데이터스트림이연속적으로변환
필터에도착한데이터는변환후다음파이프를통해다음필터로이동
하나의필터는여러포트로데이터를보낼수있다.
–Ex) 신호처리시스템, 유닉스파이프이용시스템
요소, 관계, 속성
요소
(Elements)
필터(Filter) : 입력포트로부터들어온데이터를변환하여출력포트로보낸다.
파이프(Pipe) : 필터의출력을다른필터의입력으로보내는커넥터
관계
(Relations)
붙임(Attachment): 필터의출력포트와파이프의데이터입력역할을묶어주고, 필터의입력포트와파이프의출력역할을묶어준다. (상호작용하는그래프를형성)
계산모델
(Computational
Model)
시스템의외부입력으로부터외부출력까지데이터의변환이필터들에의하여연속적으로수행된다.
제약사항
(Constrains)
파이프는필터의출력포트에서필터의입력포트로연결된다.
필터는연결된파이프를통해지나는데이터타입과일치해야한다.
비순환적이거나, 선형적인시퀀스와같이컴포넌트의연관을제한할수있다. (파이프라인)
컴포넌트가stdin,stdout과같은특정이름의포트를갖도록규정할수있다.
목적
(WhatIt’s For)
필터의독립성에기인한재사용향상
데이터프로세싱의병렬화를통한성능향상
전체적인행위에대한근거의단순화

58. 4.2.1 Pipe-and-Filter Style
파이프앤필터스타일의용도
일반적으로데이터를변환하는시스템에서사용
전체적인변환작업이독립적인단계로나뉘어질수있다.
각각의단계는입력데이터의부분적변환의책임을가진다.
파이프와필터를방탕으로할수있는시스템분석
집합변환유도, 시스템의성능추론등
다른스타일/모델과의관계
데이터플로우뷰와다름
파이프앤필터
–커넥터는필터사이의선으로표현, 연산상의스트림의전송을의미
데이터플로우
–연산상의의미없이데이터통신관계를표현

59. 4.3 Call-Return Style
호출-반환스타일
컴포넌트가다른컴포넌트들에의해호출될수있는서비스세트를제공하는계산모델을포함
컴포넌트는호출된서비스가완료될때까지서비스호출을멈춤
커넥터는요청측의서비스의호출과제공자의결과의반환에책임
[ Client-Server Style]
[ Peer-to-peer Style]

60. 4.3.1 Client-Server Style
개요
컴포넌트들이서비스를서로요청하면서상호작용
짝을지어통신하고, 클라이언트가요청시서비스를제공하는측과짝을지음
–서버는하나이상의인터페이스로여러가지서비스를제공
–클라이언트는서버가제공하는서비스를사용하지않거나하나이상사용가능
요소, 관계, 속성
요소
(Elements)
클라이언트(Client) : 다른컴포넌트에서비스를요청
서버(Server) : 다를컴포넌트에서비스를제공
요청/응답커넥터:서버에서제공하는서비스에대한클라이언트의비대칭적호출을의미
관계
(Relations)
붙임(Attachment) : 클라이언트를커넥터의요청역할에묶어주고, 서버를커넥터의응답역할에묶어준다. 또한어느서비스가어느클라이언트로부터요청을받을수있는지도결정한다.
계산모델
(Computational
Model)
클라이언트가상호작용을시작하고, 필요에따라서버에서제공하는서비스를요청하고요청에대한결과를기다린다.
제약사항
(Constrains)
클라이언트는요청/응답커넥터를통하여서버와연결된다.
서버는다른서버에대해여클라이언트가될수있다.
특화는다음과같은제한사항을내포:포트에대한붙임개수, 서버사이의허용된관계
컴포넌트는계층적으로나뉠수있다.
목적
(WhatIt’s For)
변경용이성과재사용증대, 확장성과가용성향상, 종속성과보안및성능분석

61. 4.3.1 Client-Server Style
클라이언트-서버스타일의용도
공통서비스를분리시켜시스템에대한이해도를높임
기능들을묶어그룹으로만듦
시스템배치나기존시스템에서제공되는서비스와상호운용시기초정보
성능, 확장용이성, 신뢰성이제고
신뢰성, 보안, 성능분석
다른스타일과의관계
C&C 스타일들은서비스나데이터의생산자와소비자를분리
C-S 스타일은프로그래밍언어에서다루는프로시저나함수, 메소드의호출을일반화
Peer-to-Peer : C-S 스타일에서나타나는비대칭성이없음
Client와Server는그룹으로묶어분산환경상의여러기계에배치
다단계층구조를형성하는경우가많음

62. 4.3.2 Peer-to-Peer Style
개요
컴포넌트들이서비스를교환하는피어로서서로직접상호작용
C-S 스타일에나타나는비대칭성이없는요청/응답의상호작용
커넥터는양방향상호작용에필요한복잡한통신규약을갖는다.
요소, 관계, 속성
요소
(Elements)
피어(Peer) : 컴포넌트
호출-반환(Call-Return) 커넥터: 피어네트워크를연결, 다른피어를찾고, 서비스를요청
관계
(Relations)
붙임(Attachment):호출-반환커넥터로피어들이묶여진다.
계산모델
(Computational
Model)
다른피어에게서비스를요청하는피어들이협동하는방식으로동작
제약사항
(Constrains)
포트나역할마다허용가능한붙임의개수에제한을둘수있다.
특정한피어컴포넌트는라우팅, 인덱싱, 피어찾기기능을제공할수있다.
특화는컴포넌트가다른컴포넌트를알수있다는가시성제한을포함할수있다.
목적
(WhatIt’s For)
가용성과확장성향상
파일공유, 인스턴스메시지, 그리드컴퓨팅과같은고분산시스템을가능하게한다.

63. 4.3.2 Peer-to-Peer Style
P2P 스타일의용도
분산플랫폼상에시스템배치시유연성을높임
특정컴포넌트의부담을줄임
서버용량과기반구조지원에필요한책임을분산시킴
데이터나중앙서버저장소의갱신과정에서일어나는통신빈도를줄임
–데이터를개별저장하는부담이생김
분산컴퓨팅애플리케이션에활용
자원의효율적사용
작업결과의직접공유
다른스타일과의관계
계층구조가없기때문에C-S 시스템보다일반적인형태

64. 4.3.3 Service-Oriented Architecture Style
개요
SOA는서비스를제공하거나소비하는분산컴포넌트의집합으로구성
서비스를제공하는컴포넌트와소비하는컴포넌트는다른구현언어와플랫폼을사용하는것이가능
서비스들은대부분독립적이다.
컴포넌트들은독립적으로배치
컴포넌트들은서로다른시스템이나조직에소속

65. 4.3.3 Service-Oriented Architecture Style
요소, 관계, 속성
요소
(Elements)
서비스제공자(Service Providers) : 하나이상의서비스를공개된인터페이스를통해제공
서비스소비자(Service Consumer) : 직접또는중간매개체를통해서비스를호출한다.
엔터프라이즈서비스버스(ESB) : 서비스제공자와소비자사이의메시지에대한라우팅과전달할수있는중간요소
서비스레지스토리(Registry of Services) : 제공자가서비스를등록하기위해사용하며, 소비자는실행시서비스를찾기위해사용
오케스트레이션서버(OrchestrationServer) : 서비스소비자와제공자사이의상호작용을조정하고, 비즈니스워크플로우가정의된스크립트에기반한스크립트제공
SOAP 커넥터: 웹서비스사이의동기통신을위해SOAP 프로토콜을사용
메세징커넥터: 비동기메시지교환을위해제공되는메시지시스템을사용
관계
(Relations)
붙임(Attachment) : 각각의커넥터에대해서로다른종류의포트가가능하다.
계산모델
(Computational
Model)
네트워크를통해서비스를제공하거나소비하는협동하는컴포넌트의집합으로이루어진다.
종종워크플로우모델의한종류로기술된다.
제약사항
(Constrains)
서비스소비자는서비스제공자와연결되지만, 중간에컴포넌트가사용될수있다.
엔터프라이즈서비스버스(ESB)는hub-and-spoke방식을유도한다.
서비스제공자는서비스소비자가될수있다.
특정SOA패턴은추가적인제한사항을포함한다.
목적
(WhatIt’s For)
서로다른플랫폼이나인터넷을통해실행되는분산컴포넌트의상호운용을허용한다.
레거시시스템과통합
동적구조변경을허용한다.

66. 4.3.3 Service-Oriented Architecture Style
SOA스타일의용도
상호운용성의활용
서비스제공자와소비자는서로다른플랫폼에서운영
서로다른시스템이나레거시시스템과통합
때때로외부서비스요소와상호작용하기위해인터넷활용

67. 4.4 Event-based Style
이벤트기반스타일
컴포넌트들이비동기메시지를통하여통신
느슨한결합(loosely coupled)을통한컴포넌트들의제휴
이벤트를통하여다른컴포넌트의행위를트리거
다양한이벤트스타일이존재
Point-to-Point
–호출-반환스타일과유사하나, 동시성이강함
–이벤트송신축은이벤트수신측에서처리하는동안동작을정지하지않음
Multi-party
–이벤트가여러컴포넌트에전달
–발행구독시스템(publish-subscribe system)

68. 4.4.1 Publish-Subscribe Style
개요
이벤트의알림을통하여상호작용
커넥터의기본형태는이벤트버스
컴포넌트는여러가지이벤트를구독할수있음
발행된이벤트가이벤트를받아볼모든구독자에게전달하는책임
–발행구독실행시간기반구조에서처리
메시지의생산자와소비자를분리하고자할때사용
나중에변경이용이하다.

69. 4.4.1 Publish-Subscribe Style
요소, 관계, 속성
발행구독스타일의용도
미지의수신자에게이벤트와메시지를보낸다.
발신자의변경없이수신자를추가할수있다.
응용프로그램에서UI의분리
요소
(Elements)
모든C&C컴포넌트타입: 이벤트를발행하거나구독하는인터페이스를가진다.
발행구독커넥터(Publish-subscriber connector) : 컴포넌트가발행하거나구독하기를원하는이벤트를알리거나듣는다.
관계
(Relations)
붙임(Attachment): 어느컴포넌트가이벤트를통지하고, 어떤컴포넌트가이벤트를수신할지를등록하는것을지시하여컴포넌트와발행구독커넥터를묶어준다.
계산모델
(Computational
Model)
컴포넌트가이벤트를구독한다. 컴포넌트가이벤트를발행하면, 커넥터가모든구독자에게이벤트를전달한다.
제약사항
(Constrains)
모든컴포넌트는이벤트배분자와연결된다.
컴포넌트는두타입의포트모두를가짐으로써발행자와구독자의역할모두를할수있다.
목적
(WhatIt’s For)
알려지지않은수신자에게이벤트를보낸다(이벤트생산자를소비자로부터고립시킨다.)
GUI프레임워크, 메일링리스트, 공개게시판, 소셜네트워크의핵심기능을제공

70. 4.4.1 Publish-Subscribe Style
다른스타일과의관계
지속성을지원하지않는공유데이터블랙보드로볼수있음
블랙보드스타일: 데이터베이스가이벤트발행
발행구독스타일: 어떤컴포넌트라도이벤트발행이가능
묵시적인호출은호출반환스타일과결합되는경우가많다.
서비스호출또는비동기적이벤트발행에컴포넌트가동기적을상호작용하는경우

71. 4.5 Repository Styles
저장소스타일(Repository Style)
하나이상의저장소라불리는컴포넌트를포함한다.
저장소(Repository) : 대규모의영구데이터의집합을유지하는저장소
컴포넌트들이저장소에데이터를쓰거나읽는다
Ex) 데이터베이스시스템
데이터접근자
저장소에서말하는공유데이터스타일을따라상호작용을시작하는것에대한책임이있다.

72. 4.5.1 Shared-Data Style
개요
영속적인데이터를교환하는형태의상호작용
데이터의접근자가여러개존재해야한다
데이터를영속적으로보관할수있는공유데이터저장소도최소한하나이상존재
예로는, 데이터베이스시스템이나지식기반시스템

73. 4.5.1 Shared-Data Style
요소, 관계, 속성
공유데이터스타일의용도
다양한데이터항목들이영속적이고접근자가여럿인경우사용
데이터생산자와소비자를분리
성능, 보안, 신뢰성, 기존데이터와의호환성에초점
요소
(Elements)
저장소컴포넌트(Repository Component) : 데이터를저장,데이터성능관련특성, 데이터분산, 접근허용수에대한특성을가진다.
데이터접근자컴포넌트(Data accessorComponent)
데이터읽기-쓰기커넥터(Data read and write connector) : 트랜젝션유무의특성
관계
(Relations)
붙임(Attachment): 어느데이터접근자가어느데이터저장소에연결되는지결정
계산모델
(Computational
Model)
공유저장소에서데이터접근자들사이의통신을중재
통신은데이터접근자에서먼저시작할수도있고, 데이터저장소에서먼저시작할수도있음
제약사항
(Constrains)
데이터접근자는데이터저장소와상호작용한다.
목적
(WhatIt’s For)
영속적인데이터에여러컴포넌트가접근하는것을허용
데이터생산자를데이터소비자로부터분리하여변경용이성향상을제공

74. 4.5.1 Shared-Data Style
다른스타일과의관계
클라이언트/서버스타일과공통되는부분
다중클라이언트/서버형태
발행구독스타일의블랙보드스타일과유사
블랙보드는데이터의영속성이없음
데이터모델스타일과의관계
데이터모델: 데이터엔티티와관계
공유데이터스타일: 데이터저장소와접근자
배치스타일과의관계
배치스타일은저장소와다른컴포넌트의하드웨어노드할당상태를보여줌

75. 4.6 Crosscutting Issues for C&C Styles
C&C 스타일의횡단이슈(Crosscutting Issue)
동시성(Concurrency)
시스템상의컴포넌트들이동시에쓰레드나프로세스로실행
계층의사용(Use of Tier)
계층으로구성요소그룹을통합
접하지않은계층사이의컴포넌트간통신경로를제한
동적구조변경(Dynamic reconfiguration)
실행시컴포넌트의생성및제거가가능

76. ALLOCATION VIEWS AND A TOUR OF SOME ALLOCATION STYLES
Chapter. 5

77. 5.1 Overview
소프트웨어아키텍처문서화시
아키텍처와상호작용하는내용도함께문서화해야한다.
하드웨어, 팀구조, 파일시스템등
S/W 아키텍처하드웨어: 시스템성능분석
S/W 아키텍처팀구조: 효과적인프로젝트관리
S/W 환경파일구조: 시스템개발진행
할당뷰(Allocation View)
개요
(Overview)
할당스타일들은소프트웨어아키텍처와환경사이를매핑
요소
(Elements)
소프트웨어요소와환경적인요소
소프트웨어요소는환경에서요구하는특성을가진다.
환경요소는소프트웨어에제공해야하는특성을가진다.
관계
(Relations)
Allocate-to : 소프트웨어요소는환경요소와매핑(할당)된다.
특성은특정스타일에의존한다.
제약사항
(Constrains)
스타일에따라다양하다.

78. 5.1 Overview
할당뷰(Allocation View)
모듈스타일이나C&C 스타일에나오는요소와환경적요소를대응
배치스타일
(DeploymentStyle)
소프트웨어가실행될하드웨어에컴포넌트와커넥터가어떻게
대응되는지를설명
구현스타일
(Implementation Style)
모듈을담은파일시스템에모듈이어떻게대응되는지를설명
작업할당스타일
(WorkAssignment Style)
모듈을구현하는사람, 그룹,팀에모듈이어떻게대응하는지를설명
Computing
Platform
Development
Organization
Production
Environment
Software Elements From
Module or C&C Views
Deployment
Style
Work
Assignment
Style
Install
Style

79. 5.2 Deployment Style
요소, 관계, 속성
개요
(Overview)
배치스타일(Deploy Style)은소프트웨어아키텍처의Component와Connector를컴퓨팅플랫폼의하드웨어에매핑한다.
요소
(Elements)
소프트웨어요소:C&C뷰의요소
-하드웨어로부터요구되는중요한특성들을포함한문서화를위한유용한특성들
. 프로세싱, 메모리, 용량요구사항, 결함방지등
환경요소:컴퓨팅프로세서의하드웨어요소
-할당결정에영향을주는하드웨어측면의환경적요소들의중요한특성들
. 프로세서, 메모리, 디스크, 네트웍
관계
(Relations)
Allocated-to(할당) : 소프트웨어요소가어떤물리적장치에탑재되는지보여준다.
-특성은할당이실행시간에변경가능한지여부를포함
Migrates-to (이동) , Copy-migrates-to (복사이동) , Execution-migrates –to
(실행이동) : 할당이동적으로이루어지는경우에사용
제약사항
(Constrains)
할당의구성형태(AllocationTopology)에대한제약이없다.
-하드웨어에의해제공되는특성에의해소프트웨어에요구되는특성은반드시
만족되어야한다.

80. 5.2 Deployment Style
배치스타일에서의관계
일반적으로“할당(Assignment to)”
할당은소프트웨어요소가어떤물리적장치에탑재되었는지보여준다.
시스템동작시할당내용이변경될수있으므로할당은동적일수있다.
추가적인관계
–Migrates-to (이동)
임의의프로세스에서동작하는소프트웨어요소를다른프로세스로옮김
소프트웨어요소는동시에양쪽프로세스에존재하지않는경우
–Copy-migrates-to (복사이동)
이동과유사하지만, 원래프로세스에소프트웨어요소가남아있으면서
자신을복사한사본을새로운프로세스로보냄
–Execution-migrates–to (실행이동)
복사이동과유사, 프로세스간이동은하지만, 코드가옮겨가지않는관계
한프로세스가여러프로세서에존재가능하지만특정시점에실행되는프로세스는단하나뿐인경우

81. 5.2 Deployment Style
배치스타일요소의특성
소프트웨어를물리적인요소에할당할때영향을주는속성이중요
물리적인요소가S/W요소의요구사항을만족시킬지는S/W와H/W속성을모두봐야가능
분석형태에따라요소들이갖추어야할속성값이결정될수있음
–메모리용량분석이필요S/W 요소는메모리소비측면의속성을갖춰야함
하드웨어요소와
관련된속성
CPU속성
연산요소와관련된속성, 클럭속도, 프로세스개수등
메모리속성
메모리관련속성, 메모리용량, 메모리속도등
디스크나저장장치의용량
저장용량과접근속도, 등
대역폭
통신채널의데이터전송능력
결함허용
장애처리제어방식에대한속성
소프트웨어요소와
관련된속성
자원소비
연산에필요한명령어수등
자원요구사항과제약사항
실행에대한시간제약사항등
안전중요성
소프트웨어의동작시간에대한속성등
할당과관련된속성
이동트리거
시스템중할당이변경되는경우, 선행되어야하는요건

82. 5.2 Deployment Style
배치스타일의용도
성능, 신뢰성, 보안에대한분석과비용예측에활용
H/W와S/W의할당구조를변경함으로써성능최적화가가능
신뢰성은프로세스요소나통신채널에직접적인영향을받음
시스템배치비용은시스템의하드웨어요소에영향
–배치뷰에서는개별구성에따른하드웨어요소및용도를표현해야함
–하드웨어요소에배치되는프로세스
할당을통하여기업전반에걸친배치작업수행이가능
배치스타일≠소프트웨어아키텍처
–하나의뷰로소프트웨어아키텍처를완전히기술할수없음
배치스타일에서의설계오류
–배치단위에추가로다른소프트웨어단위를넣는경우에발생

83. 5.2 Deployment Style
표기법
비공식적인표기법
도형(S/W, H/W 요소)과선, 화살표(할당관계)
–양식화된기호나아이콘도환경적요소표현에사용됨
–배치구조가단순한경우S/W 단위와관련H/W 목록을표로작성가능
정형적표기법
AADL (Architecture Analysis and Design Language)
SysML
때때로비공식적인표기법이
더이해하기쉽고직관적일때가있다.

84. 표기법
UML –Deployment Diagram
다른스타일과의관계
C&C 스타일과의관계
배치스타일은소프트웨어와컴퓨팅플랫폼의하드웨어의할당을보여준다.
Install Style은하드웨어노드에대한파일의할당을보여준다.
5.2 Deployment Style
배치다이어그램을보면시스템을구성하는HW의연결관계와HW에대한소프트웨어컴포넌트의배치상태를알수있군~

85. 5.3 Install Style
개요(Overview)
C&C 스타일의컴포넌트를생산환경의파일관리시스템에할당
라이브러리, 실행파일, 데이터파일, 로그파일, 구성및버전컨트롤파일등
대규모소프트웨어시스템에서설치되는파일들은조직화될필요가있다
시스템빌드와패키지제작프로세스의무결성을유지하고, 통제하기위해…
배포자와운영자필요시파일을찾아처리하는것을돕기위해…
아키텍처설명(Architecture Description)
설치된시스템이파일과폴더의구조로어떻게구성되었는가를보여준다.
소프트웨어요소가어떻게파일구조와맵핑되는가를보여준다.
–해당정보는개발자, 배포자, 운영자에게는중요한자산
시스템의여러버전을생산하기위한특정파일의사용/구성, 패키징정보
국제화지원
다른가격정책(무료버전, 사용버전)
서로다른고객을위한주문제작수용
구버전의메시지요청을보내는분산시스템내의고객지원

86. 5.3 Install Style
요소, 관계, 속성
소프트웨어나환경적요소에서중요한속성
소프트웨어를형상항목에할당할때영향을줄수있는속성들
Overview
생산환경의파일시스템과소프트웨어아키텍처의컴포넌트간의매핑을설명
Elements
소프트웨어요소: C&C 컴포넌트
환경적요소: 파일이나폴더와같은구성항목
Relations
할당(Allocated-to) : 모듈이하나의형상항목으로할당되는것을나타낸다.
포괄(Containment): 다른형상항목을포함하는형상항목을보여준다.
Constraints
파일과폴더가트리구조를구성된다.
포함관계를형성: is-contained-in

87. 5.3 Install Style
설치스타일의용도
빌드와배치절차생성
설치된시스템을구성하는많은수의파일과폴더를탐색
특정파일을위치지정에대해서는주의가필요(로그파일또는환경설정파일)
소프트웨어제품라인의특정버전을만들기위한구성파일의선택
동일시스템의다양한설치버전의파일의갱신과구성
목적이나생산에문제를빠진내용이나손상된파일을정의
자동갱신특성의설계와구현
구입옵션의분석을지원하는데사용
표기법
컴포넌트, 파일과폴더사이의매핑관계를보여준다.
UML 에서지원되는스테레오타입
<<artifact>>, <<manifest>>

88. 5.3 Install Style
표기법(cont’)
다른스타일과의관계
C&C 스타일과강한연관: 소프트웨어요소의할당을설명
배치스타일: 하드웨어요소와설치된파일의관계를보여줌
[ 비공식적인표기법]
[ UML표기법]

89. 5.4 Work Assignment Style
개요(Overview)
모듈스타일에서의모듈을구현책임이있는개인이나그룹에할당
개발팀의모듈의구현및통합에대한책임을정의
Ex) WBS(Work Breakdown Structure)
요소, 관계, 속성
Overview
소프트웨어아키텍처와개발조직내의팀들간의매핑을나타낸다.
Elements
소프트웨어요소: 모듈
환경적요소: 조직구성단위(사람, 팀, 부서, 등..)
Relations
할당(Allocated-to) : 하나의소프트웨어요소가하나의조직단위에할당
Constraints
할당에다한제한이없다. 그러나일반적으로하나의모듈은하나의조직단위에할당하는것으로제한한다.

90. 5.4 Work Assignment Style
작업할당스타일의용도
동작하는시스템을구성하기위해주요소프트웨어단위들이표현된다.
주요소프트웨어단위들을누가만들어야하는지를보여준다.
자원할당과구축의책임, 프로젝트구조의설명을돕는다.
작업할당구조와예산/일정의추정의기초
표기법
작업할당구조뷰를위한특별한표기법은없다.
ECSElement (Modules)
Organizational Unit
Segment
Subsystem
ScienceData
Processing
Segment
(SDPS)
Client
Scienceteam
Interoperability
Prime contractor team 1
Ingest
Prime contractor team 2
Data Management
Data team
DataProcessing
Data team
DataServer
Data team
Planning
Orbitalvehicle team
Flight
Operations
Segment
(FOS)
Planning and Scheduling
Orbital vehicle team
Data Management
Database team
User Interface
User interfaceteam
…
…
…
ECS : NASA의사용- 작업할당뷰를테이블형식으로표현

91. 5.4 Work Assignment Style
다른스타일과의관계
작업할당스타일은분해스타일(Decomposition Style)과관련
작업의할당과매핑의일반적인기초가되기때문
모듈분해로확장가능
개발도구나, 테스트툴, 형상관리시스템등과관련되는모듈을추가할경우
다른뷰와조합될수있다.
예제: 계층구조로내에서의계층내작업할당표시
이경우도구의구축에대한부분이빠질수있다.
–많은경우, 보조적인소프트웨어도구는시스템의일부가아니다.
작업할당뷰를생성시관리가능한크기로작업을분해방법에대해주의필요

92. 5.5 Other Allocation Styles
구현스타일
(ImplementationStyle)
개발환경에서파일과폴더의트리구조를보여준다.
-개발자가산출물을탐색하거나개발산출물을적절한곳에위치시키도록돕는다.
설치스타일(InstallStyle)이생산환경에서의파일과폴더의구조를보여준다면, 구현스타일은개발환경에서의파일과폴더의구조를보여준다.
데이터저장소스타일
(DataStores Style)
SW데이터엔티티와소프트웨어가위치하는데이터서버의HW 간의매핑을보여줌
-데이터베이스의지리적인분산이나복제를보여준다.
-데이터웨어하우스가위치하는머신과데이터저장소를보여줄수있다.
배치스타일과비슷하나,데이터엔티티와HW간의매핑을보여준다는점이다르다.
요구사항할당스타일
(Requirement-Allocation Style)
시스템요구사항과소프트웨어아키텍처요소간의매핑을보여준다.
배치스타일의특화
(Specializingthe deployment Style)
배치스타일은내제하는토플러지에대한제한이없지만특별하게유용한배치스타일의유형을발견할수있다.
-MS의Tiered Distribution 패턴,IBM의WebSphere 의11개토플러지
작업할당스타일의특화
(Specializingthe Work Assignment Style)
플랫폼스타일(Platform Style) : Product Line의개발시사용
역량중심스타일(Competence-center Style) : 해당분야의역량이있는팀에관련업무할당
오픈소스스타일(Open-SourceStyle) : 많은독립적인공헌자를활용
프로세스단계스타일(Process-Step Style) : 개발프로세스를여러사이트에걸쳐적용
배포기반스타일(Release-basedStyle) :제품의개발과릴리즈가사이트를돌며진행

93. BEYOND STRUCTURE: COMPLETING THE DOCUMENTATION
Part II

94. DOCUMENTING BEHAVIOR
Chapter. 8

95. 8. Documenting Behavior
아키텍처의행위적측면문서화
아키텍처개발과시스템유지보수모두에혜택을제공
시스템의이해
이해당사자의품질요구사항을만족시키기위한아키텍처에대한근거제공
구조적뷰의추가적인내용을기술
아키텍처적요소들이해당구조를통해어떻게상호작용하는가를설명

96. 8.1 Beyond Structure
뷰의행위적측면을문서화
구조적인정보에시간축을더해야함
구조적관계를바탕으로시스템내에서발생하는상호작용을반영
특정시간상에서보면상호작용중일부만실행
시스템행위
요소간상호작용이특정시간이나시스템상태에끼치는영향을설명
일부시스템행위는시스템구조설명으로분석이가능(Definition-use analysis)
데드락, 시간내작업완료등의판단은요소행위와상호작용의제약사항이있어야판단가능
행위문서화는다음의정보를필요로한다.
요소들사이의상호작용순서
동시성발생가능성
상호작용간의시간종속성
시스템이나시스템일부의가능한상태
여러가지시스템자원의사용패턴

97. 8.2 How to Document Behavior
1단계
해답이필요한질문의종류가
무엇인지결정하기
Decide What Kinds of Questions You Need to Answer
설계되는시스템의종류의존하고, 개발의단계, 그리고설계노력에초점을맞춘모델화하기위해행위의종류를결정
개발초기에는입력데이터가출력으로어떻게변환되는지에대한세부사항보다는요소들과요소들이어떻게상호작용하는지에중점
요소내에서변환행위가시스템의전체행위에영향을주기때문에요소내의변환행위에대한제한사항에대하여파악하는것은유용
최소한자극행위에대한모델과한요소에서다른요소로의정보의이전에대하여모델을만들어야한다.
문서는제약사항과상호작용에대한명시적인정보를포함해야한다.
2단계
어떤종류의정보가이용가능한지,
제한될수있는지를결정하기
Determine What Types of Information Are Available
or Can be Constrained
행위다이어그램은정보의전송측면과한요소에서다른요소로자극행위에대한설명을제공해야한다.
포함되는특성
일반적인목적/행위방법/적용범위
제약사항
순서에따른제약사항/시간에기반한자극
3단계
표기법선택하기
Choosea Notation
시스템행위에대한문서화를지원하는모든언어는반드시상호작용의시퀀스를묘사할수있어야한다.
시퀀스는시간에따른순서이며이것은시간기반의종속성을보여줄수있다.
상호작용과실행되는활동들의시퀀스는임의의자극이도착한다음에일어나는순서로표시된다.
행위문서화에서발견되는표현들
자극과활동, 상호작용의순서, 행위와연결되는관계의구조적요소
2가지종류의행위문서화방법
시나리오동안의시스템의구조적요소를통해일어나는것을문서화(traces)
구조적요소나요소셋의완전한행위를상태기반으로문서화(comprehensivemodel)

98. 8.3 Notation for Documenting Behavior
Trace표기법
Usecase diagram
Sequence diagram
Communicationdiagram
Activity diagram
State chart
Timing diagram
SDL
BPEL
SDL : Specification and Description Language
BPEL : Business Process Execution Language

99. 8.3 Notation for Documenting Behavior
Comprehensive Model 표기법
구조적요소들의완전한행위를표현한다.
초기상태에서최종상태까지의모든가능한경로를파악할수있다.
상태머신언어
제약사항과함께시스템요소의구조적인기술이가능
외부적또는환경적자극의일정시간내의반응을표현가능
Statemachine diagram
AADL
AADL : Architecture Analysis and Description Language

100. 8.4 Where to Document Behavior
행위문서화의위치
행위를아키텍처문서패키지의어느부분에기록할지는내용에따라다르다.
요소가특정방법으로자극을받을경우어떻게작동하는지를보여주고싶을때
전체시스템의포함요소의집합이서로어떻게상호작용하는지를보여주고싶을때
뷰개괄문서
아키텍처가어떻게요구사항을만족시키는지에대한논리적근거부분
설계정당성의일부로삽입가능

101. 8.5 Why to Document Behavior
행위문서화의필요성
시스템의행위문서는이해당사자들사이의의사소통을위해사용된다.
개발과정과유지보수과정에서사용
개발활동의추진
이해당사자와의중요한의사소통수단
시스템요소의내부행위와시스템의전체구조의이해를촉진
시스템모의시험에활용
–시스템테스트케이스개발에활용가능
시스템분석
행위를문서화하면시스템의완결성과정확성, 품질속성에대한논리적판단에도움
–시스템요구사항의충족여부확인
–시스템기능의일관성확인
–성능, 안정성, 변경용이성예측

102. BUILDING THE ARCHITECTURE DOCUMENTATION
Part III

103. REVIEWING AN ARCHITECTURE DOCUMENT
Chapter. 11

104. In this Chapter …
이장의목적은
아키텍처평가가아닌아키텍처의문서화를평가하는것이다.
목적의적합성을위한문서화리뷰
문서가올바른정보를적절한방법으로표현하고있는지확인
이번장에서는문서리뷰를위한절차를설명한다.
체크리스트는문서화산출물이적절한지를평가한다.

105. 11.1 Steps of the Procedure
문서리뷰절차
검토목적수립하기Establish the purpose of the review
1
검토대상설정하기Establish the subject of the review
2
적절한질문세트구성하기Build or adapt the appropriate question set(s)
3
리뷰의세부사항계획하기Plan the details of the review
4
리뷰수행Perform the review
5
결과를분석하고요약하기Analyze and summarize the results
6

106. 11.1 Steps of the Procedure
1단계-검토목적수립하기
이해당사자에의해설정된특정목적에부합하는검토목적수립
리뷰참가자와직접적인리뷰에중점
아키텍처문서는하나이상의목적에부합
다원적인리뷰가될수있다.
한가지목적을가진여러개의작은리뷰들은대안이될수있다.
검토목적수립시,
문서의리뷰의이해당사자를정의해야한다.
언제리뷰를할것인지결정해야한다.
–어떤수명주기프로세스를사용하든문제가되지않는다.
–리뷰목적에따라프로젝트단계또는마일스톤과연관된다.
Why?
Who?
When?

107. 11.1 Steps of the Procedure
개발주기와아키텍처리뷰
개발단계
활동
아키텍처설계리뷰
Concept
이해당사자의요구사항정의
개념, 목적, 다양한해결책탐색
대안적인아키텍처분석
아키텍처적인개념준비
계약협상의일부분으로고객과개발자
사이의의견교환
올바른이해당사자와관심사항의포착
제안에대한지원
Development
시스템요구사항정제하기
해결책에대한설명서만들기
시스템또는시스템들을구축
시스템에대한V&V(Verifying and Validating)
규범사양에적합성에대한지원
평가지원
개발지원
생성및분석도구에입력지원
아키텍처에대한구현적합성심사지원
프로젝트계획에대한지원
Utilization
사용자요구를충족시키기위한시스템의운영
운영오류에대한추적성지원
Support
지속적인시스템기능제공
아키텍처와관련된시스템진화와진화를
위한비즈니스계획과관련된지원

108. 11.1 Steps of the Procedure
2단계-검토대상설정하기
요구되는산출물의집합을정의하고, 리뷰를위하여해당산출물을모은다.
산출물타입, 산출물의버전과소스
리뷰를수행하기위해필요한산출물의완성도정도
아키텍처문서(AD)는반드시필요!!!
모든검토자가동일한산출물의같은버전을검토하도록해야한다.
3단계-적절한질문세트구성하기
아키텍처리뷰를위한질문세트정의
기존질문세트가있는경우재사용이가능
–리뷰목적에맞도록조정이필요할수있음
새로운질문세트를만드는경우
–재사용이가능하도록만들어야한다.
–리뷰목적에맞는문맥적인정보와이해당사자의요구를제공
–결과를획득하고, 해석할수있는가이드라인제공
일반적인질문은프로젝트의기술에따라특화된질문으로교체가능
질문들은적절한형식을갖추도록할수있다.

109. 11.1 Steps of the Procedure
4단계-리뷰의세부사항계획하기
리뷰날짜, 리뷰시간표(time frame), 리뷰형식등
질문의우선순위에따라시간을더할당하거나제한이가능하다.
실제리뷰참가자지정하고, 그들의참석여부를확보
검토자에게초기질문을할당
이해당사자는질문에대한응답을할수있음
리뷰가시작되면, 우선순위와이해당사자할당이변경될수있다.
–문서에대한이해도를높이기위해
–리뷰어가적용가능한부분을찾기위해
리뷰를위한실행계획을조정
회의장소와시간
모든참석자의참석여부
미리읽어야할자료제공

110. 11.1 Steps of the Procedure
5단계-리뷰수행
리뷰에포함된이해당사자에게질문하기
이해당사자가검토자역할을하고, 질문을할수있다.
분리된팀들이이해당사자에게질문할수있다.
리뷰방식은
개인리뷰, 면대면, 온라인분산/원격회의
리뷰어가좀더신중히검토해야할질문들이나산출물
리뷰초기부분에결정해야한다.
6단계-결과를분석하고요약하기
질문에대한답변을종합
아키텍처문서의전반적인영향에대한질적인결정
결과는Pass/Fail과같이단순할수도있고
아키텍처문서의특정부분의문제에집중한미묘한답변이될수도있다.

111. 11.2 Sample Question Sets for Reviewing for AD
Question Set Template
1
질문세트이름
(Question Set Name)
질문세트를재사용할때, 참조할수있는질문세트의이름
2
목적
(Purpose)
질문세트를나오도록한리뷰의목적
3
이해당사자와관심사항
(Stakeholdersand Concerns)
누가이해당사자이고, 그들의관심사항은무엇인지를설명
-아키텍처문서검토의첫째수준의이해당사자와관심사항의설정은질문세트의
목적을효과적으로정제하고, 질문의계통적서식을알게한다.
4
Questions
a.응답자
(Respondents)
누구에게질문을해야하는가?
b. 예상답변
(Expected Answer)
찾고자하는답변은무엇인가?
c. 중요도
(Criticality)
각질문들이얼마나중요한가?
5
조언사항
(Advice)
언제, 어떻게리뷰가진행되어야하는지에대한추가적인유용한정보를제공

112. Example Question Set for Reviewing for Conformance to ISO/IEC 42010
11.2 Examples

113. Q&A …