소프트웨어 아키텍처

SW Architecture in Practice
김영기책임
네트워크사업부
SE Lab

This Slide based on following book …

Overview of Part 1 : Introduction
Part 1 tell about …
What is Software Architecture and Why that is import ?
What effect to the Software Architecture ?
Chapter 1. What Is Software Architecture?
Software Architecture Definition
Software Architecture Views
Software Architecture Patterns
Chapter 2. Why Is Software Architecture Important?
Uses of an Software Architecture
Roles of an Software Architecture
Chapter 3. The Many Context of Software Architecture
Contexts in Software Architecture
Architecture Influence Cycle

Chapter 1. What Is Software Architecture?

In this Chapter …
소프트웨어아키텍처책에대한2 가지가정
소프트웨어시스템의성공적인개발에있어서소프트웨어아키텍처는중요하다.
아키텍처책은충분한양의,일반화된, 지식체계를포함하고있다.
비즈니스목표
(추상적)
최종적인결과시스템
(구체적)
소프트웨어아키텍처
(설계, 분석, 문서화, 구현)

Chapter 1.1
What Software Architecture Is and What It Isn’t
소프트웨어아키텍처(Software Architecture)정의다양하다
아키텍처적인결정은“프로젝트초기”에일어난다
아니다. Agile이나Spiral 의경우초기에결정되지않는다
아키텍처적인결정은설계적인측면의“중요한” 결정이다
초기의결정이모두아키텍처적인것은아니다.
소프트웨어구조(Software Structure)
소프트웨어는많은구조들(Structures)로이루어진다.
Software Architecture ≠ Software Structure
Structure는특정관점(Perspective)에서소프트웨어를정의한것이다.
Structure는구현중심으로, Structure의표현을View라고한다.
The Software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both
All information
Some
information

Chapter 1.1
아키텍처정의의의미
소프트웨어아키텍처는소프트웨어구조들의집합이다.
소프트웨어시스템은여러가지구조로구성되며, 하나의구조를아키텍처라고할수없다.
아키텍처구조의3가지분류
Module Decomposition
Structure
Allocation
Structure
Conponent-and-Connector
Structure
-시스템을구현단위로분리
-정적구조
-시스템이기능시요소들간의
상호작용중점
-동적구조
-소프트웨어요소와외부환경과의관계

Chapter 1.1
아키텍처는추상화수준의상위개념이다.
아키텍처는소프트웨어요소와요소들의관계를전체적인관점에서본다.
아키텍처는시스템에유용하지않은정보나세부적인사항을생략/압축할수있다.
특정목적과관계없는요소들간의관계정보를명확하게한정해서생략가능
모든소프트웨어시스템은소프트웨어아키텍처를가진다.
아키텍처는행위(Behavior)를포함한다.
모든아키텍처가좋은아키텍처는아니다.
시스템아키텍처와엔터프라이즈아키텍처
소프트웨어아키텍처를공유한다.
시스템이어떻게동작하는지설명
-시스템구성및동작원리
구성요소간의관계및시스템외부환경과
관계묘사
시스템설계에대한제약사항
조직의프로세스및정보시스템및부서의
구조와기능을포괄적으로기술
조직이전략적목표에따라행동하도록
방향제시
System
Architecture
Enterprise
Architecture

1.2
아키텍처구조와뷰(View)
구조란아키텍처적인요소들의집합이며, 이러한구조의표현이View이다
3가지아키텍처구조
모든것을한번에
표현하기에는너무복잡하다
특정관점의선택
(관심의대상이무엇인가?)
관심의대상이되는
일부요소만을표현
View란시스템중에서관심있는시스템요소와그들간의관계를표현하는것이다.
모듈구조
(ModuleStructures)
구현과관련된모듈의집합으로시스템을표현
How is it structured as a set of code unit?
컴포넌트와커넥터구조
(Component-and-Connector Structures)
런타임행위와상호작용을갖는요소의집합으로시스템을표현
Howis it structured as a set of elements that have run-time behavior and interacts?
할당구조
(Allocation Structures)
소프트웨어요소가환경적인구조에Mapping
Howdoes it relate to non-software structures in its environment?

1.2
일반적인아키텍처구조
Module
C&C
Allocation
Decomposition
Uses
Layered
Class
Service
Shared Data
Deployment
Work Assignment
Implementation
Data model
Software
Structure
Element
Type
Relations
Useful For
Quality
Attributes
Affected
Module
Structures
Decomposition
Module
Is a submoduleof
Resource Allocation,
Project Structuring/Planning
Information Hiding
Configuration Control
Modifiability
Uses
Module
Uses
Engineeringsubsets,
Engineering extensions
Subsetability,
Extensibility
Layers
Layer
Requires the correct presence of,
Usesthe services of, provides abstraction to
Incremental development,
Implementing systems on the top of “virtual machines”
Protability
Class
Class, Object
Is an instance of ,
Shares access methodsof
In OOD System, factoring out commonality,
Planningextensions of functionality
Modifiability,
Extensibility
Datamodel
Dataentity
{one, many}-to-{one, many},
Generalizes,Specializes
Engineering globalstructures for consistency and performance
Modifiability,
Performance

1.2
일반적인아키텍처구조(cont.)
위의구조들은다양한관점을제공하지만, 독립적이지않다.
한구조의요소는다른구조의요소와관련이있다.
참조가능한구조는많지만모든구조를다참조할수는없고, 가능한적은수의구조를가지는것이좋다.
어떤구조를선택할것인가?
시스템에있어가장중요한품질속성에대하여통찰력을주고이용가능한구조를선택
Software
Structure
Element
Type
Relations
Useful For
Quality
Attributes
Affected
C&C
Structures
Service
Service, ESB, Registry, Others
Runs concurrently with,
May run concurrently with,
Excludes, precedes, etc.
Schedulinganalysis,
Performance analysis
Interoperability,
Modifiability
Concurrency
Processes, Threads
Can run in parallel
Identifying locations where resource contention exists,or where threads may fork, join, be created, or be killed
Performance,
Availability
Allocation
Structures
Deployment
Components,
HW element
Allocated to,
Migratesto
Performance,availability, security analysis
Performance,
Security,Availability
Implementation
Modules,
File Structures
Stored in
Configuration control, integration, test activities
Development Efficiency
Work assignment
Module,
Organizational Units
Assigned to
Project Management, best use of expertise and availableresources, management of commonality
Development Efficiency

1.3
아키텍처패턴
Architectural Patterns
The Software Pattern of is composition of architectural elements to solve particular problems.
It delineates the element types and their forms of interaction used in solving the problem
Architectural patterns can be used at the beginning of coarse- grained design addressing system-wide properties
Design Patterns can be used to refinethe architectural elements prior to implementation
Idiomsare used during detailed design and implementation
Client
Server
Import java.io.IOException;
Public class MainThreadextends Thread
{
private String UserString;
public MyThread(String UserString)
{
this.UserString= UserString;
setDaemon(true)
Distributed
Event-driven
Frame-based
Batch
Pipes and filters
Repository-centric
Blockboard
Interpreter
Rule-based
Layered
MVC
IR-centric
Subsumption
Disposable

1.4
“좋은” 아키텍처의요건
좋은아키텍처와나쁜아키텍처를나누는기준은없다.
특정한목적에적합한아키텍처와적합하지않은아키텍처가있을뿐이다.
아키텍처평가의목적: 시스템이특정목적에부합하는지를확인
권고사항(Rule of thumb)
아키텍처수립시참고사항
아키텍트팀에의한아키텍처수립
요구사항에따른QA 우선순위화
아키텍처문서화
-Static view, Dynamic view 포함
이해당사자를통한아키텍처검증
성능품질정량적수치로평가
골격시스템은최소한의기능만을포함
자원경쟁정확하고명확하게명시및관리
기능모듈단위로구분
잘정의된인터페이스제공
QA 정의및QA 목표달성
특정상용제품이나도구에독립적
데이터생성과사용모듈구분
병렬처리시스템
-모듈을하나의컴포넌트나커넥터로표시X
Task, 프로세스의문서화
특징적인상호작용패턴
프로세스측면의
권고사항
제품(구조적) 측면의
권고사항

Chapter 2. Why Is Software Architecture Important?

In this Chapter …
기술적측면에서의아키텍처의중요성에대하여이야기한다.
시스템품질속성의사용또는억제하는기준이된다.
변경에대한원인파악과관리를가능하게한다.
시스템품질의예측할수있도록한다.
이해당사자와의의사소통수단이된다.
시스템초기의설계결정사항을기술한다.
개발시제약사항정의한다
개발조직구조를결정한다
점진적인Prototype 개발을가능하게한다
비용과일정을정확하게예측하도록한다.
변경가능하고, 재사용가능한모델을제공한다
독립적으로개발된컴포넌트들의통합을가능하게한다
설계선택사항을제한한다.
훈련의기반이된다.

2.1
시스템품질속성의사용또는억제하는기준이된다.
시스템에요구되는품질속성은아키텍처에의하여결정된다.
아키텍처만으로시스템에요구되는기능과품질을보장하지못한다.
개발주기상의모든결정들이품질에영향을미친다.
품질은설계, 구현, 배포등모든단계에영향을받는다.
좋은품질을보장하기위해좋은아키텍처가필요하지만, 아키텍처가품질을보장하지는않는다.
고성능(High Performance)
요소들의시간기반의행위
공유자원의사용
내부요소들간커뮤니케이션의빈도와크기
변경용이성(Modifiability)
시스템요소에책임할당변경범위의최소화
보안(Highly Security)
내부요소의외부연동관리또는금지
정보조회요소를한정
확장성(Scalability)
시스템자원사용의내부한정
자원사용량, 한계를코드상에한정하지말것
점증적개발(Deliver Incremental)
내부컴포넌트사용의세밀한관리
재사용성(Reusability)
내부요소간Coupling 제한
시스템환경과독립적인개발

2.2
변경에대한원인파악과관리를가능하게한다.
소프트웨어시스템의총비용
소프트웨어시스템은생명주기에따라계속변화한다.
시스템변화의타입
효과적인아키텍처는변화를쉽게처리할수있도록한다.
시스템변경에필요할때, 어느부분을어떤방법으로변경하는지를결정하기위해서는,
시스템요소들과요소의행위, 요소들간의관계에대한이해가필요하다.
After initial deployment
Before initial deployment
지역적(Local)
하나의요소만을수정하는경우.
전역적(Nonlocal)
많은요소를수정하지만아키텍처적인변화는아니다.
아키텍처적(Architectural)
요소들간의상호작용에영향을준다.
시스템전반에대한변경을요구하기도한다.

2.3
시스템품질의예측할수있도록한다.
아키텍처는시스템의품질을고취하며, 품질을예측할수있게해준다.
아키텍처적인결정이어떤품질속성에영향을주는지알수있다면,
아키텍처적인결정을할수있다.
아키텍처적인결정과관련된속성의결과를올바르게예측할수있다.
정량적인분석이어려운경우라도, 때때로아키텍처가규정된결과를가져올수있는지보장할필요가있다

2.4
이해당사자와의의사소통수단이된다.
소프트웨어아키텍처는시스템을추상적으로표현
대부분의이해당사자들이서로이해하고, 타협하는동의수단으로사용가능하다
이해당사자는아키텍처에영향을주는각기다른시스템의특성에관심을갖는다.
소프트웨어아키텍처는
대부분의비기술적인사람들도이해할수있을정도로추상화되어야한다.
구현, 통합, 테스트, 배포를가이드하기위한기술적인명세로정제할수있어야한다.
사용자
고객사
관리자
빠르고,
언제나쉽게이용가능한..
개발일정을맞추고, 비용도초과하지말고..
일정,비용..
팀구성이쉬운구조로..
아키텍트
품질목표달성은어떤설계전략으로..

2.5
시스템초기의설계결정사항을기술한다.
소프트웨어아키텍처는시스템개발초기의설계결정사항을표현
초기의결정사항은최종산출물에영향을준다.
초기의결정사항은나중에변경하는것이힘들다. 물결효과(Ripple effect)
초기결정사항은시스템개발과유지보수와관련된많은결정사항을해결한다.
시스템개발초기에시스템분석을가능하게한다.
때때로아키텍처는리팩토링되거나재설계되어야한다. 그러나이런작업은쉽게수행하기가어렵다.

2.6
개발시제약사항정의한다
시스템개발시, 아키텍처에기술된설계구조를준수아키텍처의실현
개발단위= 아키텍처구성요소단위
아키텍처에기술된대로다른요소들과상호작용
아키텍처에기술된요소의기능을수행
구현시각요소의명세를지켜야하지만,요소들간의Trade-off를고려
개발인력분배도제약사항
개발자는인식하지못하나관리자는인력과환경을최적으로구성할수있는정보
개발자설계명세를이해하고구현
아키텍트아키텍처의Trade-off 고려
구현에대한
제약사항

2.7
개발조직구조를결정한다
아키텍처는시스템구성구조와아키텍처구조를통한개발조직간관계도표현
대규모시스템개발시개발단위구분개발부분할당
WBS (Work Breakdown Structure)
시스템아키텍처는최상위수준의시스템분할구조를표현
작업분할구조의기초로활용: 개발계획, 일정, 비용계산에참고
작업분할구조수립은소프트웨어아키텍처의한측면을고정(Side effect)
아키텍처가결정되면여러이유로변경이어렵다.
대규모시스템에서소프트웨어아키텍처를확정하려면, 아키텍처평가가선행되어야한다.
Project
Task 1
Task 2
Subtask 1.1
Subtask
1.2
Work
Package 1.1.1
Work
Package 1.1.2
Work
Package 1.1.3

2.8
점진적인Prototype 개발을가능하게한다
아키텍처가결정되면, 분석가능한Prototype형태의골격시스템(Skeletal System)으로개발이가능
골격시스템은최종시스템이만들어지기전적절한지여부를판단하게한다.
실행가능한시스템의경우초기에잠재적인문제를발견하게한다.
골격시스템은실제로정확함(Fidelity)가떨어지기도한다.
프로젝트의잠재적인위험요소(Risk)를줄인다.
군제품(Family Product)개발의경우, Prototype을위한Framework 개발은비용분산효과가있다.
바로만들기에는너무위험요소가많다!!!

비용과일정을정확하게예측하도록한다.
비용과일정의예측은프로젝트에필요한자원과문제를해결하는관리도구로활용가능하다.
프로젝트조직구성은아키텍처에의해결정된다.
비용의예측은대략적인시스템정보로도출하는방식(Top-down)보다, 세부적인정보를이해하고도출하는방식(Bottom-up)이정확하다
프로젝트관리자보다는프로젝트내,팀단위로비용과일정을예측하는것이더정확하다
2.9
시스템범위에대한정보를더많이알수록, 비용과일정을좀더정확히예측할수있다.
1M
2M
3M
S
1M
2M
S

2.10
변경가능하고, 재사용가능한모델을제공한다
프로젝트초기에아키텍처를재사용하면많은혜택을볼수있다.
코드의재사용뿐아니라, 아키텍처를결정하는요구사항이나아키텍처, 아키텍처개발경험등아키텍처관련된자료를여러시스템에서재사용할수있다.
소프트웨어Product Line은시스템특징을공유한다.
핵심공통모듈의개발제품군에서필요로하는것을기술한아키텍처가가장중요
Product Line에서공유하는아키텍처는제품군내모든멤버를고려하여선택
아키텍처재사용
System 1
System 2

2.11
독립적으로개발된컴포넌트들의통합을가능하게한다
소프트웨어패러다임의변화
아키텍처에는시스템에포함될수있는아키텍처요소들이정의되어있다.
아키텍처요소들은독립적으로개발하여통합할수있다.
아키텍처에는외부개발요소를추가하거나기존요소들을대체하기위한조건이제시될수있다.
아키텍처요소와인터페이스, 운영개념의조합교환용이성(Interchangeability)
시장출시시간의단축
신뢰성증가
비용감소
유연성증가
Focused
Programming
(LOC)
Focused
Composing or
Assembling
소프트웨어패러다임의변화
Architecture-based
Development
Earlier
S/W Development

2.12
설계선택사항을제한한다
소프트웨어요소들은수많은방법으로조합될수있다
복잡도가높아질가능성이높다.
아키텍처패턴이나설계패턴을한정하면,
설계시복잡도를낮추고, 재사용을높일수있다.
이해하기쉽고, 의사소통이쉬워진다.
분석이쉬워지고, 개발시간이단축된다.
아키텍처패턴을이용하면,
설계의이해도를높일수있다.
요구사항의불일치성을찾을수있다.
충돌이발생하는설계제약사항을중재할수있다.
아키텍처패턴의
선택이중요하다
Project Risk
Architectural
Patterns
Project Elements

2.13
훈련의기반이된다.
아키텍처는시스템의행위를설명한다.
요소와요소들의상호작용방법을기술
아키텍처문서들은새로운프로젝트멤버의훈련에도움을준다.
아키텍처는다양한이해당사자간의대화수단으로공통적으로참조할수있다.

Chapter 3. The Many Context of Software Architecture

In this Chapter …
Starts with Saul Steinberg’s cartoon
View Of The World From 9th Avenue (New Yorker’s view of the world)

In this Chapter …
다음과같은4가지Context를소개한다.
컨텍스트자체는변하지않지만, 특정시스템에적용시명확히할필요가있다.
아키텍트의과제중하나는어떤컨텍스트가변경가능한지, 시스템과개발에어떻게적용시켜야하는지에대한것이다.
What technical role does the software architecture play in the system or systems of which it’s part?
Technical
Project Life Cycle
Business
Professional
How does a software architecture relate to the other phases of a software development cycle?
How does the presence of a software architecture affect an organization’s business environment?
What is the role of a software architect in an organization or a development project?

3.1
Architecture in a Technical Context
아키텍처는시스템품질속성에영향을미친다. (2장참조)
아키텍처는품질속성을장려하거나억제한다.
아키텍처를통하여시스템품질의여러측면을예측할수있다.
아키텍처는변경에대한원인파악과관리를가능하게한다.
아키텍처를설계할때의기술적인환경은아키텍처에영향을미친다.
기술적환경이란, 업계표준적인사례나엔지니어링기법들이다. 그러나변한다.
고성능(High Performance)
요소들의시간기반의행위
공유자원의사용
내부요소들간커뮤니케이션의빈도와크기
가용성(Availability)
이벤트실패시, 컴포넌트상호간동작방법
오류발생시시스템의반응
사용성(Usability)
사용자인터페이스와사용자경험에책임이있는요소들을시스템의다른부분과고립Tailoring과향상을통한시간단축
테스트가능성(Testability)
개별요소에대한테스트가능성
-각요소의상태가관찰가능하고, 통제가능하도록한다.
-요소들이함께동작할때비정상행위에대한이해
안전성(Safety)
요소들의행위를감추고, 비정상동작에대한처리
상호운용성(Interoperability)
요소의외부와의상호작용과상호작용에대한통제

3.1
스웨덴의전함“바사(Vasa)호”의교훈
요구사항을만족시킬수있는성공적인아키텍처사례를통하여현재에적용할수있도록해야한다.
사례가없는시스템을설계할경우시스템을구축하기전에아키텍처를평가할수있는방법을통해위험을감소시켜야한다.
점진적인아키텍처기반의개발기법을을통하여너무늦지않도록설계오류를수정할수있어야한다.

3.2
Architecture in a Project Life-Cycle Context
소프트웨어개발프로세스는소프트웨어개발을위한표준적인접근방법이다.
개발프로세스는소프트웨어엔지니어와팀에대한원칙을강제한다.
대표적인4 가지소프트웨어개발프로세스
어떤개발프로세스를사용하던, 아키텍처관련활동이포함되어있다.
시스템에대한비즈니스사례만들기
아키텍처적으로중요한요구사항이해하기
아키텍처생성또는선택
아키텍처에대한문서화와커뮤니케이션
아키텍처분석과평가
아키텍처에기반한구현과시스템테스트
아키텍처에대한구현준수에대한보장
Waterfall
Iterative
Agile
Model-Driven

3.3
Architecture in a Business Context
아키텍처와비즈니스목표
아키텍처와시스템은비즈니스목표를가지고구현된다.
시스템은하나이상의조직의비즈니스목표를만족시키기위해만들어진다.
비즈니스목적은아키텍처에많은영향을준다.
비즈니스목적은품질속성목표로명백해질수있다.
어떤비즈니스목적은요구사향형식으로보여지지않는다.
어떤비즈니스목적은아키텍처에영향을미치지않는다.
아키텍트는
각조직과
조직의목적을
이해해야한다.
개발조직
고객
정부, 하청업체
수익창출
시장확보
사업유지
고객편의증진
편의증진
생산성향상
시스템에대한규정준수
Business Goal
Architecture
Quality Attribute
Nonarchitectural
Solutions

3.3
Architecture in a Business Context
아키텍처와개발조직
개발조직의특성이나구조는아키텍처에영향을미친다.
개발자들의숙련도, 개발일정, 개발예산
조직이가진기존아키텍처나제품기반의개발을할수있다. 재사용측면의장점
조직은기반구조와같은장기적인관점의투자를전략적인목표에의해할수있다.
기반구조에대한투자는개발조직에영향을준다.
조직인구조는소프트웨어아키텍처의형태를결정한다. (역도성립)
개발조직은기술적이고, 적용개념으로조직된다.
조직구조
S/W 아키텍처
서로영향을
주고받음

3.4
Architecture in a Professional Context
아키텍트에게는기술적인능력이외의것이필요하다.
아키텍처의배경과경험도아키텍처에영향을준다.
아키텍트가경험한프로젝트에서의아키텍처적용사례(성공과실패사례모두)
(아키텍처패턴이나기술에대한) 교육과훈련에의한아키텍처적인결정
아키텍트의능력
Skills
Duties
knowledge
사교성, 협상력,
커뮤니케이션능력
아키텍트를만들어
내는액티비티
아키텍처에대한
지식과실무능력
아키텍트

3.5
Stakeholders
S/W시스템에직간접적으로이해관계를가지는(관심이있는)사람또는조직
고객, 사용자, 개발자, 프로젝트관리자, 유지보수자,마케팅책임자…
이해당사자는각자시스템에대한다양한요구사항을가진다
성능, 신뢰성, 가용성, 변경용이성, 사용편의성,상호운용성, 호환성, 효율…
이해관계자의목적에따라요구사항이충돌우선순위를가능한빨리알아야한다
아키텍처평가, 반복적인Prototype 을통해사용자참여를유도
사용자
개발조직
관리자
마케팅
담당자
깔끔한UI, Time- to-Market, 적은비용, 경쟁력
적은비용,
고용기술자유지…
아키텍트
시스템동작, 성능, 보안, 신뢰성, 사용편의성까지..
고객
유지보수
담당자
우아아악~~~
적은비용, 일정준수, 시스템개발후변경않됨…
변경용이성,
시스템이해도가높게...
아키텍트는시스템특성을
모두기록하여테스트가가능한수준까지
작성할수있어야한다.

3.6
How Is Architecture Influenced ?
아키텍처는비즈니스, 기술, 프로젝트, 아키텍트의경험등에영향을받는다.
아키텍트는아키텍처를만들고, 이를기반으로시스템이구축된다.
아키텍트
GSM Channels
TrafficChannels
SignalingChannels
Full- rate
Half- rate
BroadcastChannels
Common Control Channels
DedicateControl Channels
TCH/ F
TCH/ H
BCCH
FCCH
SCH
PCH
AGCH
RACH
TCH/ H
TCH/ H
TCH/ H
downlink
uplink
fast
slow
아키텍처
시스템
아키텍트영향을미치는요소들
Technical
Business
Professional
Project
Stakeholders

3.7
What Do Architectures Influence?
아키텍처는비즈니스, 기술, 프로젝트, 아키텍트의경험등에영향을받는다.
아키텍트는아키텍처를만들고, 이를기반으로시스템이구축된다.
아키텍처는비즈니스, 기술, 프로젝트, 아키텍트의경험에영향을준다.
아키텍트의환경적인요소들은미래의아키텍처에영향을준다.
아키텍트
GSM Channels
TrafficChannels
SignalingChannels
Full- rate
Half- rate
BroadcastChannels
Common Control Channels
DedicateControl Channels
TCH/ F
TCH/ H
BCCH
FCCH
SCH
PCH
AGCH
RACH
TCH/ H
TCH/ H
TCH/ H
downlink
uplink
fast
slow
아키텍처
시스템
아키텍트영향을미치는요소들
Technical
Business
Professional
Project
Stakeholders

Overview of Part 2 : Quality Attributes
Part 2 Provide technical foundation about …
Design or analyze an architecture to achieve particular quality attribute
Not discuss design or analysis processes
Chapter 4. Understanding Quality Attributes
Specify a quality attribute, requirement, and tactics
7 categories for design decisions
Chapter 5 ~ 12. Particular quality Attributes
Availability, Interoperability, Modifiability, Performance, Security, Testability
Additional Quality Attributes
Chapter 13. Architectural Tactics and Patterns
Some of most important patterns and tactics and their relationship
Chapter 14. Quality Attribute Modeling and Analysis
Modeling techniques for some of quality attributes

Chapter 4. Understanding Quality Attributes

In this Chapter …
왜품질속성(Quality Attribute)에대하여논의하는가?
품질속성들은시스템의기능(Functionality)과더불어아키텍처에영향을준다.
시스템이재설계되는이유는대부분기능부족때문이아니다.
유지보수, 포팅, 확장성, 성능등의이슈품질속성과관련된다.
품질속성의정의
이번장에서는다음의사항에중점을둔다.
구축하고자하는시스템이나시스템들에제공되는아키텍처에원하는품질속성을어떻게표현할것인가?
어떻게품질속성(의수준)을만족시킬것인가?
각품질속성에대한설계적인결정은어떻게내릴것인가?
품질속성은이해당사자의요구를시스템이어떻게잘만족시키는가를나타내는,
측정가능하고(Measurable) 테스트가능한(Testable) 시스템의특성이다.

4.1
Architecture and Requirement
시스템에대한요구사항은다양한형태를가진다.
요구사항문장, 실물모형(mockup), 기존시스템, Use case, 사용자스토리…
요구사항의3가지분류
기능요구사항(Functional Requirements)
시스템이반드시제공해야하는기능을의미한다.
설계전반에걸쳐적절한순서로책임(Responsibility)을할당한다.
품질요구사항(Quality Attribute Requirements)
시스템이나기능요구사항전반에걸쳐요구되는능력을의미한다.
요소들간동작과상호작용을정의한다양한구조들(Structure)를아키텍처에적용한다.
제약사항(Constraints)
선택의여지가없는설계결정사항이다.
설계결정사항을받아들이고, 다른설계결정사항과조화를이루게해야한다.
Software
Architecture
Functional
Requirement
Quality
Attributes
Constraints

4.2
Functionality
기능성은아키텍처를결정하지않는다.
주어진기능을만족시키는아키텍처는수없이많다.
기능성은임의의특정구조에독립적이다.
기능성은아키텍처요소에책임을할당함으로써달성할수있다.
책임은임의의모듈에할당될수있다.
다른품질속성이중요한경우,아키텍처는책임의할당을제한할수있다.
기능성(Functionality)이란의도한작업을수행할수있는시스템의능력이다.

4.3
Quality Attribute Considerations
시스템의기능은품질속성에고려없이표현될수없다. (역도성립)
기존품질속성에대한논의는아키텍처관점에서다음과같은문제가있다.
기존속성에대한정의들은테스트가가능하지않다.
종종논의가어느품질의관점에서볼것인가에중점을둔다.
각커뮤니티는각자자신들만의용어를발전시켜왔다.
Event ? Or Attacks ?
Failure ? Or User Input?
품질에대한2가지관점
시스템실행시의특성: Availability, Performance, Usability
시스템개발시의특성: Modifiability, Testability
복잡한시스템에서, 품질속성은고립되어성취할수없다.
여러품질속성들간에Trade-off가발생한다.
설계에대한결정이필요(17장에서..)
품질속성시나리오로
품질속성을구체화
각품질속성에대한
기본관심사항에대한토의

4.4
Specify Quality Attribute Requirement
품질속성요구사항은모호하지않고, 테스트가능해야한다.
모든품질속성요구사항을명세하기위한공통된형식을사용!!!
품질속성을표현은품질속성시나리오를이용한다.
품질속성시나리오의6 가지요소
Stimulus
Source
Stimulus
Environment
Response
Response
Measure
1
2
3
4
Artifact
자극유발원(StimulusSource)
•자극을만들어내는대상체
자극(Stimulus)
•이벤트가시스템에도착했을경우
응답(Response)
•자극에대하여시스템이취하는동작또는행위
응답측정(ResponseMeasure)
•응답이발생하면, 요구사항의만족여부를응답측정을통해서검증
환경(Environment)
•시나리오가발생하는특정환경의집합
대상체(Artifact)
•자극을받는대상

4.5
Achieving Quality Attributes through Tactics
아키텍트전술(Architectural Tactics)
요구되는품질속성을성취하기위해아키텍트가사용할수있는기법
품질속성의응답을제어하는데영향을주는설계결정사항
하나의품질속성의응답에대해서초점을둔다. 
No Trade-off. : 아키텍처패턴과의차이점
디자인패턴과같이오랫동안사용해온설계기법들이다.
새로운전술을고안하기보다, 적용할수있는전술에기술한다.
디자인패턴들은복잡하다, 또한때때로적용하기가어려운경우가있다.
설계목적을실현시킬패턴이없는경우, 아키텍트가디자인분할을구성할수있도록한다.
일부제한사항에대한좀더시스템적인결정을하도록한다.
기존의전술은개선(refine)될수있다.
응답을
제어하는
설계전술
자극
응답

4.6
Guiding Quality Design Decisions
아키텍처는설계결정의집합을적용한결과이다.
설계결정은설계관점을가장문제가있을것같은것에아키텍처가초점을갖게하며시스템적으로분류할수있다.
설계결정은다음과같이7가지로분류된다.
책임할당
(Allocation of responsibilities)
•기본적인시스템기능, 아키텍처인프라, 품질속성을만족시키기위한중요한책임의정의
•책임들의정적(non-runtime), 동적(runtime)할당
조정모델
(Coordination model)
•조정되거나금지해야하는시스템요소의정의
•조정해야할특성결정(시간적절성, 동시성, 완전성..)
•특성을구현하기위한커뮤니케이션메커니즘
데이터모델
(Data model)
•주요데이터의추상화, 오퍼레이션, 데이터특성선택
•데이터의일관성있는해석을위한메타데이터편집
•데이터조직화
자원관리
(Management of resources)
•관리되어야하는자원과각각의대한한계설정
•자원을관리하기위한시스템요소맵핑
•자원의공유방법
•여러자원들의포화상태에대한영향결정
아키텍처요소들간의맵핑
(Mapping among architectural elements)
•모듈과실행요소간의맵핑
•실행요소에대한프로세서할당
•데이터저장소에저장할데이터모델상의아이템할당
바인딩시간결정
(Binding time decisions)
•시점에따라다른엔터티와연동범위내변동을가능하게한다.
•책임의할당파라미터화된Makefilebuild 시선택가능
•조정모델프로토콜선택, 자원관리드라이버선택, 사용기술선택
기술선택
(Choice of technology)
•사용할기술과해당기술을지원하는도구선택
•기술의내부적인유사성과외부적인지원정도
•선택된기술의부작용확인과신기술에대한호환성

In this Chapter …
가용성(Availability)이란…
가용성이란Task의수행이필요시수행준비가되어있음을나타내는S/W 의특성이다
사용자입장에서시스템을얼마나사용할수있는가를정도를의미한다.
가용성은신뢰성(Reliability)를확장한개념이다
Availability = reliability + recovery notion
Dependability = 허용가능한것보다더자주일어나고, 더심각한실패를회피할수있는능력
가용성은누적서비스중단기간이명시된시간동안에요구되는값을초과하지않도록오류(faults)를가리거나회복할수있는시스템의능력을의미한다.
가용성은다른속성들과관련이있다
보안(Security)
성능(Performance)
안전(Safety)
가용성은시스템의오류를완화시킴으로써서비스중단시간을최소화하는것이다.

In this Chapter …
Fault, Failure, Error
고가용성(High-Availability)의Fault-tolerant 한시스템을위해서는운영중발생되는Failure(실패)의본질을이해해야한다.
Fault와Failure의구분은자동화된회복전략(Automated repair strategies)에대한논의를가능하게하다.
Fault는방지(prevented), 처리(tolerated), 제거(removed), 예측(forecast) 될수있다.
Fault –시스템실패의원인
Failure –시스템이정상적으로동작하지않는상태로사용자등이관찰가능
Error –시스템실패의원인을가지고있지만Failure가발생하지않은상태

In this Chapter …
가용성(Availability)이란…
가용성은확률적인계산이가능하다.
Planning for Failure
실패는조건적인것이아니라, 대부분불가피한것이다.
시스템이어떠한실패의경향이있는지, 각각의유형이어떤결과를가져오는지에대한이해가필요
실패를처리하기위한3가지기법
Hazard Analysis
Fault Tree Analysis
Failure Mode, Effect, and Criticality Analysis (FMECA)
Steady-state availability =
MTBF
(MTBF + MTTR)
•MTBF = mean time to between failure
•MTTR = mean time to repair

In this Chapter …
Hazard Analysis
시스템운영중발생할수있는위험들에대하여목록화
위험의심각도에따라분류, 위험의정의와분류는도메인마다다름
DO-178B Standard (항공기시스템과장비인증에관한소프트웨어고려사항)
Software Level and Structural Coverage Requirement
Software
Criticality Level
Failure Definition
Associated Structure
Coverage Level
Level A
Softwareresulting in a catastrophicfailure condition for the system
Modified condition/Decision Coverage, Decision Coverage & Statement Coverage
LevelB
Software resulting in a hazardousor severe-majorfailure condition for the system
Decision Coverage &Statement Coverage
LevelC
Softwareresulting in a majorfailure condition for the system
Statement Coverage
Level D
Softwareresulting in a minorfailure condition for the system
None Required
LevelE
Softwareresulting in no effectfor the system
None Required

Gate
Meaning
AND
OR
COMBINATION
EXCLUSIVEOR
PRIORITY AND
INHIBIT
In this Chapter …
Fault Tree Analysis
시스템의안전과신뢰성에부정적인영향을주는시스템의상태를명세하기위한분석적인기법으로,
시스템의바람직하지않은상태를발견하기위해시스템의컨텍스트와작동방식을분석
n
D Fails
A Fails
B or C Fail
B Fails
C Fails
G1
A
G2

In this Chapter …
Failure Mode, Effect, and Criticality Analysis (FMECA)
시스템실패의종류를실패가갖는심각도와함께목록화
과거의유사시스템의실패이력에의존
Probability of a critical system failure
(5*10-5) + (5*10-5) + (5*10-5) + (5*10-5) = 2*10-4
Component
Failure
Probability
Failure
Mode
%Failure
by Mode
Effects
Critical
Noncritical
A
1*10-3
Open
90
X
Short
5
X (5*10-5)
Other
5
X (5*10-5)
B
1*10-3
Open
90
X
Short
5
X (5*10-5)
Other
5
X (5*10-5)

5.1
Availability General Scenario
시나리오항목
입력가능한값
Source
시스템내부/시스템외부: 사람, 하드웨어, 소프트웨어, 물리적인하부구조, 물리적환경
Stimulus
결함: 누락, 정지, 부정확한타이밍, 부정확한응답
Environment
정상동작, 시작, 종료, 수리모드, 저하된동작, 가중된동작
Artifact
프로세서, 통신채널, 영구저장장치, 프로세스
Response
실패가될수있는결함을방지한다.
결함의발견
결함의기록
적절한실체에통보(사람또는시스템)
결함을복구한다.
결함의원인이되는이벤트의소스를사용하지못하게한다.
수리동안에일시적으로이용하지못하도록한다.
결함/실패또는손상의원인을포함하는것을고치거나감춘다.
수리되는동안저하모드로동작한다.
ResponseMeasure
가용성백분율(예를들어99.999)
결함감지시간
결함수리시간
시스템이비정상모드에서동작할수있는시간또는시간간격
시스템이방지하거나실패없이처리한결함이임의의결함분포나비율

5.1
Availability General Scenario
Sample concrete availability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
하트비트모니터
기대치않은
메시지
정상동작
프로세스
운영자에게
동작을계속
하라고알린다
중단시간없음

5.2
Tactics for Availability
Availability Tactics
Detect Fault
Recover from Fault
Prevent Faults
Fault
Masked
Or
Repair
Made
Fault
Preparation
and Repair
Reintroduction
Ping/Echo
Monitor
Heart beat
Voting
Timestamp
Sanity Checking
Condition Monitoring
Self-Test
Exception Detection
Shadow
State
Resynchronization
Escalating
Restart
Non-StopForwarding
Removal from
Service
Transaction
Predictive
Model
Exception
Prevention
Increase
Competence Set
Active
Redundancy
Passive
Redundancy
Spare
Exception
Handling
Rollback
Software
Upgrade
Retry
Ignore Faulty
Behavior
Degradation
Reconfiguration

5.2
Availability Tactics
DetectFault
Ping/Echo
한컴포넌트가신호를보내고다른컴포넌트로부터정해진시간내에응답이오는지를확인
Monitor
시스템의다양한부분의상태를감시하는컴포넌트(monitor) 의사용
Heartbeat
한컴포넌트로부터주기적신호/메시지를받아상태를
결함여부를파악
Timestamp
분산메시지처리시스템에서잘못된이벤트의순서를감지하기위해사용
Sanity Checking
특정동작이나컴포넌트의출력의적절성/유효성을체크
Condition Monitoring
프로세스나디바이스의상태를체크
설계시정의된가정을검증
Voting
중복된프로세스에서실행되는프로세스들이같은입력을받고투표자에게값을보내다르게동작하는프로세스감지–다수결원칙
Exception Detection
정상적인시스템흐름에서변경된시스템상태의감지
-SystemException, Parameter fence/typing, Timeout
Self-Test
컴포넌트나서브시스템이올바른동작을위하여자체테스트를수행

5.2
Recover from Fault
Preparation
and Repair
Active Redundancy
중복된컴포넌트들이동시에이벤트에응답하여,
결과적으로모두동일상태를갖도록한다.
Passive Redundancy
한컴포넌트가이벤트에응답하고, 대기컴포넌트들에게상태를통보하면대기컴포넌트들도업데이트를수행
Spare
다양한종류의컴포넌트실패에대하려는목적으로예비컴포넌트준비
ExceptionHandling
예외발생시시스템이해당예외처리를하여시스템동작이계속진행될수있도록처리
Rollback
실패를감지한경우이전의알려졌던정상상태로되돌림
SoftwareUpgrade
서비스에영향을주지않는방법으로실행코드이미지를업그레이드
Retry
실패의원인이일시적인경우,재시도를통하여시스템동작을정상적으로수행
Ignore Faulty Behavior
특정소스로부터오는메시지가의미없다고판단한경우해당소스의메시지를무시
Degradation
시스템실패시덜중요한컴포넌트의기능은내리고가장중요한시스템기능만유지
Reconfiguration
가능한기능은유지하면서,자원에대하여책임을재할당함으로컴포넌트의실패로부터복구를시도
Reintroduction
Shadow
실패한컴포넌트를“ShadowMode”로작동시켜정상상태가되면다시복귀시킴
State
Resynchronization
Active Redundancy나Passive Redundancy 에서파트너에게현재상태를통보
Escalating Restart
다양한컴포넌트들의재시작단위를통한시스템의결함으로복구를지원하며, 이에영향을받는서비스의수준을최소화함
Non-Stop
Forwarding
라우터설계에서고안된개념,ControlPlane 과Data Plane 으로구분, Control Plane상태에관계없이Data Plane은동작

5.2
Prevent Fault
Removal fromService
실패를회피하기위해현재진행중인동작에서특정컴포넌트를제거하는것
Transactions
일련의순차적인절차를한꺼번에원상태로복구할수있도록그절차들을묶어놓는경우(ACID Properties)
PredictiveModel
명목상의운영파라미터를가지고정상행위를하는지를보장하기위해시스템의상태를감시하기위하여사용
Exception Prevention
시스템예외발생을방지하기위한기법–예외클래스등
시스템예외발생시투명한방식으로시스템을복구
Increase Competence Set
프로그램의동작시더많은오류경우에대하여처리할수있도록설계하는것을의미

5.3
A Design Checklist for Availability
분류
체크리스트
Allocation of Responsibilities
고가용성을위한시스템의책임을결정
-누락, 충돌, 잘못된타이밍, 또는잘못된응답을감지하기위한추가적인책임의할당을포함
-로깅, 통지, 이벤트비활성화, 일시정지, 결함/실패의수정및감춤, 저하모드수행
Coordination Model
조정메커니즘이누락, 충돌, 잘못된타이밍, 또는잘못된응답을감지할수있는지확인
조정모델이로깅, 통지, 이벤트비활성화, 일시정지, 결함/실패의수정및감춤, 저하모드수행을확인
조정모델이사용되는대상체의교체를지원하는지확인
조정모델이저하모드에서수행여부결정
Data Model
시스템의어떤부분이고가용성이필요한지결정
-데이터추상화와데이터와관련된동작및특성
Mapping among
Architectural Elements
대상체와발생되는결함의Mapping
아키텍처요소들의Mapping이결함복구시충분히유연한지여부
Resource Management
결함이발생한경우시스템이계속동작하기위해중요한자원의결정
중요자원의가용시간결정
Binding Time
아키텍처요소들이언제, 어떤방법으로바인딩될것인지를결정
-선택된가용전략이알려진결함을대비가능한지확인
Choice of Technology
시스템결함을감지할수있는기술의선택
발생되는결함과선택된기술의Mapping결정
선택된기술자체의가용특성결정

In this Chapter …
상호운용성(Interoperability)이란…
상호운용성이란둘이상의시스템들이의미있는정보를특정컨텍스트내에서인터페이스를통하여교환할수있는정도를의미한다.
상호운영성은다음의2가지의미를가진다.
Syntactic interoperability : 데이터를교환할수있는능력
Semantic interoperability : 교환된데이터를올바르게해석할수있는능력
상호운용성은시스템들이예상하는운용방식에영향을받는다.
시스템이상호운영할외부시스템의인터페이스를미리알고있다면,
해당정보가시스템에포함되도록설계가가능하다.
시스템을좀더일반화된형식으로상호운영토록설계할수있다.
상호운영성은“된다, 안된다”의명제가아니라여러의미(shades of meaning) 를가진다.

In this Chapter …
Systems of Systems
시스템들이그룹으로하나의공통된목적을위해상호운영하는경우
각각의독립적이고유용한시스템들을더큰규모의시스템으로통합
System of System 분류
Directed
•SoSobjectives, centralized management, funding, and authority for the overall SoS are in place. Systems are subordinated to the SoS
Acknowledged
•SoSobjectives, centralized management, funding, and authority in place, However, systems retain their own management, funding, and authority in parallel with the SoS
Collaborative
•Thereare no overall objectives, centralized management, authority, responsibility, or funding at the SoS level, Systems voluntarily work together to address shared or common interests
Virtual
•Like collaborative,but systems don’t know about each other

6.1
Interoperability General Scenario
시나리오항목
입력가능한값
Source
시스템은다른시스템과상호운용에대한요청을보낸다.
Stimulus
시스템사이의정보를교환하기위한요청
Environment
상호운영하고자하는시스템은실행시발견되거나실행전미리알려져있다.
Artifact
상호운용하고자하는시스템
Response
다음중하나또는그이상이된다.
요청이(적절하게) 거부되거나적당한엔터티(사람또는시스템)에통보된다.
요청이(적절하게) 승인되고, 정보가성공적으로교환된다.
요청이하나또는그이상의포함된시스템들에의해기록된다.
ResponseMeasure
다음중하나또는그이상이된다.
적절하게처리된,교환된정보의비율
적절하게거부된,교환정보의비율

6.1
Interoperability General Scenario
Sample concrete interoperability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
차량정보시스템
현재위치를
보냄
시스템들은
이전동작시간을
알고있다.
교통감시시스템
교통감시시스템은
현재의위치와다른
정보를조합하여
구글맵으로보여주고
브로드캐스팅한다
차량정보는99.9%의
시간적정확성을포함

6.2
Tactics for Interoperability
Interoperability Tactics
Locate
Manage Interface
Request
Information
Discover Service
Manage Interface
Tailor Interface
Exchange
Request
Correctly
Handled

6.2
Interoperability Tactics
Locate
Discover Service
알려진디렉터리서비스검색을통해서비스를찾는다.
Manage
Interface
Orchestrate
특정서비스들의호출순서를조정하고, 관리하는통제메커니즘
Tailor Interface
인터페이스새로운기능을추가하거나제거

6.3
A Design Checklist for Interoperability
분류
체크리스트
다른시스템과의상호운용을위한시스템의책임을결정
외부시스템과상호운영을위한요구를감지하기위한책임이할당되었는가의확인
-요청수락, 정보교환, 요청거부, 적절한통보, 신뢰할수없는환경에서의요청기록
Coordination Model
중요품질속성요구사항을조정모델이만족하는지보장
-네트워크상의트래픽양, 시스템에보내는시간에관계없는메시지, 메시지를보내는비용,
메시지도착시의잡음등
Data Model
주요데이터추상화의구문과의미결정
사용운영중인시스템사이의데이터일관성을위한주된데이터추상화의확인
Mapping among
컴포넌트와프로세서의Mapping
-보안, 가용성, 그리고성능요구사항을고려
Resource Management
다른시스템과의상호운영을위한요구/거절시중요시스템자원이고갈되지않는지여부를확인
상호운영의가능한통신요구사항에의해내포된자원의사용정도에대한확인
상호운영시시스템들간의자원의공유가요구된다면, 적당한분배정책이있는지확인
Binding Time
시스템이상호운영한다면, 언제시스템들이서로를알게되는지를결정
-알려지거나알려지지않은외부시스템의바인딩을처리하기위한정책이있는지확인
-승인되지않은바인딩을거절하고, 기록하기위한메커니즘을확인
-늦은바인딩시점의경우관련된새로운서비스나프로토콜을찾기위한메커니즘을확인
시스템의인터페이스가“보여지는지”, 그들이상호운용에영향을주는지
선택된기술들이상호운용성을지원하도록설계되었는지

In this Chapter …
변경용이성(Modifiability)이란…
변화와변화가만들어내는비용과위험에관심을둔다.
변경용이성에대한계획을위해서는다음사항에관심을둔다.
무엇이변경될수있는가?
변화의가능성이있는것은무엇인가?
변화가일어나는시기와누가변화는만드는가?
변화의비용은얼마나되는가?
시스템에적용할새로운메커니즘을소개하는비용
새로운메커니즘을시스템에적용하는비용

7.1
Modifiability General Scenario
시나리오항목
입력가능한값
Source
최종사용자, 개발자, 시스템관리자
Stimulus
기능의추가/삭제/변경지시, 또는품질속성, 용량, 기술에대한변경
Environment
실행시점, 컴파일시점, 빌드시점, 초기화시점, 설계시간
Artifact
코드, 데이터, 인터페이스, 컴포넌트, 자원,환경구성
Response
다음의하나이상을따른다.
변경을한다.
변경결과를테스트한다.
변경결과를배포한다.
ResponseMeasure
다음관점의비용이따른다.
영향을받는요소의개수, 크기,복잡도
노력
일정
비용(직접비용또는간접비용
해당변경이확장되어다른기능이나품질속성에영향을준다.
새로운결함의발견

7.1
Modifiability General Scenario
Sample concrete modifiability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
개발자
UI 변경을
원함
설계시간
Code
코드변경및
단위테스트
3시간이내

7.2
Tactics for Modifiability
Modifiability Tactics
Reduce Size
of a Module
Increase
Cohesion
Defer
Binding
Change Made
Within Time
And Budget
Change
Arrives
Split Module
Encapsulate
Use an Intermediary
Restrict Dependencies
Refactor
Increase Semantic Coherence
Reduce
Coupling
Abstract Common Service

7.2
Modifiability Tactics
Reduce Size
of a Module
Split Module
평균적인변경비용이감소하도록모듈을여러개의작은모듈로나눈다.
Increase
Cohesion
Increase Semantic Coherence
하나의모듈에있는다른책임들이동일목적을위해제공되지않아야한다. (서로다른모듈에위치시켜야함)
Reduce
Coupling
Encapsulate
모듈에대한명확한인터페이스정의
한모듈의변경이다른모듈에전파될확률을줄인다.
Use an Intermediary
한모듈이다른모듈에의존한다면, 의존성과관련된행위를제어하는중개자를중간에삽입
Restrict Dependencies
주어진모듈과상호작용하거나종속성을갖는모듈을
제한(모듈에대한가시성을제한)
Refactor
두모듈이서로중복되어있어동일한변경에(잠재적) 영향을받는경우
Abstract CommonServices
두모듈이상당히동일하지는않지만유사한서비스를제공하는경우, 서비스를일반화된형식으로구현(비용효과)
Defer
Binding
배치시점과비개발자들에의한변경을허용
추가적인내부구조가필요

7.3
A Design Checklist for Interoperability
분류
체크리스트
기술적, 법적, 사회적, 업무적, 고객에의한변화의고려를통해일어날만한변화와변화의분류결정
-변경을위해추가, 변경, 삭제가필요한책임결정, 변화에영향을받는책임결정
-모듈에대한책임의결정(동일모듈에서동시에변경/ 다른모듈에서다른시점에변경)
Coordination Model
어떤기능과품질속성이실행시변경되는지여부와그것이조정모델에얼마나영향을주는지결정
변화에대한조정을위해어떤디바이스, 프로토콜, 통신경로가사용되는지결정
Data Model
데이터의추상화,동작, 특성에어떤변경이있는지결정(생성, 초기화, 지속, 처리, 변환, 파기포함)
최종사용자, 시스템관리자, 또는개발자에의해변경이일어날지여부결정
Mapping among
실행, 컴파일, 설계또는빌드시의기능과계산요소의맵핑이바람직한변경방식인지를결정
기능과품질속성의추가, 삭제, 변경을수용하기위해필요한변경의범위를결정
-실행종속성/ 데이터베이스에데이터할당/프로세스, 쓰레드, 프로세서실행요소할당
Resource Management
자원사용에영향을주는책임이나품질속성을어떻게추가, 삭제, 변경할것인지를결정
변경후의자원이시스템요구사항을만족하는지확인
모든자원관리자를캡슐화하고, 이러한자원관리자에의해구현된정책들이캡슐화되고바인딩이가능한범위까지지연되는지를확인
Binding Time
변경이필요할최종시간을결정
선택된시간에적당한기능을제공하기위한지연바인딩메커니즘을선택
메커니즘소개비용과선택된메커니즘을사용하여만들어지는변경을결정
변화가내포하는종속성사이의선택은복잡하고알려져있지않기때문에너무많은바인딩선택사항을갖지말것
선택된기술에의하여어떠한변경이더쉬워지는지또는어려워지는결정한다.
가장있음직한변경을지원하기기술의선택

Appendix : Coupling and Cohesion
Coupling
External interaction of the module with other modules
Cohesion
Internal interaction of the module (Crisp abstraction of purpose)
For component independence
High cohesion, Low coupling
Coincidental Cohesion
Temporal Cohesion
Communicational Cohesion
Informational Cohesion
Functional Cohesion
Logical Cohesion
Procedural Cohesion
Bad
Good
Less interdependency
Less coordination
Less information flow
More interdependency
More coordination
More information flow
Contentcoupling
External coupling
Stamp coupling
Data coupling
Message coupling
Common coupling
Control coupling

Appendix : Coupling ExampleChangeChange
High coupling makes modifying parts of the system difficult,
e.g., modifying a component affects all the components to which the component is connected

Appendix : Coupling and Cohesion
Architectural Building Blocks
A good architecture
Minimizes coupling between modules
Goal : modules don’t need to know much about one another to interact
Low coupling makes future change easier
Maximizes the cohesion of each module
Goal : the contents of each module are strongly inter-related
High cohesion makes a module easier to understand
Module
Module
Connector
Good Case
Bad Case

Appendix : Type of Cohesion
Refer to : http://en.wikipedia.org/wiki/Cohesion_(computer_science)
CohesionType
Description
Functional cohesion (best)
Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. tokenizinga string of XML)
Sequential cohesion
Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data
Communicational cohesion
Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information)
Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).
Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are processed -the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).
Logical cohesion
Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines).
Coincidental cohesion (worst)
Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class).

Appendix : Type of Coupling
Refer to : http://en.wikipedia.org/wiki/Coupling_(computer_programming)
CouplingType
Description
No coupling
Modules do not communicate at all with one another.
Message coupling (low)
This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing
Data coupling
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).
Stamp coupling
(Data-structured coupling)
Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g., passing a whole record to a function that only needs one field of it).
Control coupling
Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag).
External coupling
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.
Common coupling
Common coupling (also known as Global coupling) is when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it.
Content coupling (high)
Content coupling (also known as Pathological coupling) is when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.

In this Chapter …
성능(Performance)이란…
시간과시간적인요구사항을만족시키는S/W 시스템의능력이다.
시스템이나시스템의일부요소에서이벤트가발생하면, 적절한시간내에응답이되어야한다.
이벤트패턴과응답패턴은특성화할수있다.
모든시스템은성능요구사항을갖는다.
성능을때때로확장성(Scalability)와관련을갖는다.

8.1
Performance General Scenario
Performance General Scenario
Sample concrete performance scenario
시나리오항목
입력가능한값
Source
시스템의내부또는외부
Stimulus
이벤트의주기적, 산발적, 또는확률적인도착
Environment
운영모드: 정상, 응급, 최대부하, 과부화
Artifact
시스템또는시스템내의하나이상의컴포넌트
Response
프로세스이벤트, 서비스레벨의변화
ResponseMeasure
대기시간, 마감시간,처리량, 지연시간,데이터손실
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
사용자
트랜잭션
시작
정상동작
시스템
트랜잭션들의처리
2초의평균지연

8.2
Tactics for Performance
Performance Tactics
Control Resource Demand
Manage Resource
Response
Event
Arrives
Manage Sampling Rate
Increase Resource
Introduce Concurrency
Maintain Multiple Copies of Computations
Maintain Multiple Copies of Data
Bound Queue Size
Generated within
Time Constraints
Limit Event Response
Prioritize Events
Reduce Overhead
Bound Execution Times
Increase Resource Efficiency
Schedule Resources

8.2
Performance Tactics
Control
Resource
Demand
Manage Sampling Rate
외부에서만들어지는이벤트도착에대한제어
Limit Event Response
이산적인이벤트들의도착이처리하기에는너무빠른경우이벤트가처리될때까지큐에저장
Prioritize Events
이벤트에우선순위화를통하여중요한이벤트순서에따라처리
Reduce Overhead
중개자의사용은이벤트처리에자원을더요구하지만지연을제거함으로대기시간을줄인다.
Bound Execution Times
이벤트에응답하는데사용되는실행시간을제한
정확한계산을경우보다비용이적다.
Increase Resource Efficiency
중요지점에대한알고리즘의향상을통하여대기시간을단축
Manage
Resources
Increase Resources
더많은자원의추가를통한대기시간의감소(비용고려)
Introduce Concurrency
요청에대한병렬처리는자원대기시간을줄임
Maintain Multiple Copies
of Computations
동일한복사본을여러곳에분산하여경쟁을줄임
Loadbalancer Round-robin, Least buy server
Maintain MultipleCopies
of Data
접근속도가다른저장장치상의데이터복사본을유지
Bound Queue Sizes
이벤트도착을처리하는데사용하는자원과대기중인도착이벤트의최대치를제어
Schedule Resources
항상자원에대한경쟁이있다면, 자원사용에대해서스케쥴링이되어야한다.

8.3
A Design Checklist for Performance
분류
체크리스트
많은자원, 시간에민감한응답요구사항을포함한시스템의책임과자원을많이사용하거나시간에
민감한이벤트가발생하는영향을받는시스템의부분을결정
각각의책임에대한처리요구사항을확인하고, 병목현상의원인이되는지결정
정의된책임과자원에대하여요구되는성능응답을만족시키는지확인
Coordination Model
(직접또는간접적으로) 서로조정되어야하는시스템의요소결정
커뮤니케이션과조정메커니즘선택
-동시성, 이벤트우선순위, 스케줄링전략/ 요구된성능응답의제공보장
-주기적, 확률적, 산발적인이벤트도착의포착/ 적절한통신메커니즘의특성을가지고있는지여부
Data Model
많은자원, 시간에민감한응답요구사항을포함한시스템의책임과자원을많이사용하거나시간에
민감한이벤트가발생하는영향을받는데이터모델의부분을결정
-핵심데이터의다중복사본유지/ 성능을위한데이터분리/ 데이터처리요구사항축소/ 자원추가
Mapping among
네트워크상에부하가일어날수있는부분과성능을위해일부컴포넌트를동시에어디에위치시킬지결정
많은계산요구사항을가진컴포넌트를가장처리능력이많은프로세스에할당했는지확인
동시성을어디에적용할지여부와성능에긍정적인가를확인
제어쓰레드의선택여부와병목에유발하는책임들의연관관계를결정
Resource Management
시스템의어떤자원이성능에심각한영향을주는지결정
-시간과성능에민감한자원을관리하기위한시스템요소, 프로세스/쓰레드모델, 자원과자원의접근에
대한우선순위화, 스케줄링과락킹전략, 증가되는부하를만족시키기위한자원의추가배분
Binding Time
완전한바인딩에필요한시간
늦은바인딩메커니즘에의한추가적인오버헤드
해당값들이시스템에허용되지않는성능저하를일으키지않는지를확인
선택한기술이hard/real-time deadline을만족할수있는가?
-스케줄링정책, 우선순위, 요구감소를위한정책, 프로세서에대한기술분야할당,다른성능관련파라미터

In this Chapter …
보안(Security)이란…
인증된사람과시스템에게는접근을허용하는반면, 인증되지않은접근으로
부터데이터와정보를보호하는시스템의능력이다.
보안의3가지특징(CIA)
CIA를지원하기위한다른특성들
비밀보장
(Confidentiality)
•인증되지않은접근으로부터데이터또는서비스가보호되어야한다.
무결성
(Integrity)
•인증되지않은처리로부터데이터또는서비스가영향을받지않아야한다.
가용성
(Availability)
•시스템은정당한사용이가능해야한다.
인증
(Authentication)
•처리를위한참가자들의신분을검증하고, 그들이정당한사용자인지를
확인한다.
부인방지
(Nonrepudiation)
•송신측이메시지를보낸사실과수신측이메시지를수신한사실을나중에
부인하지못하도록보장한다.
권한부여
(Authorization)
•사용자가테스트를수행할수있는권한을부여한다.

9.1
Security General Scenario
시나리오항목
입력가능한값
Source
사람또는미리정의된/알려지지않은시스템으로부터의공격
조직내부또는외부로부터의공격
Stimulus
데이터를표시, 변경또는삭제하려는인증되지않은시도, 시스템서비스로의접근,
시스템동작의변경, 또는시스템가용성의축소하려는시도
Environment
온라인또는오프라인, 네트워크의연결또는비연결, 방화벽또는공개,
완전작동, 부분적작동, 미작동
Artifact
시스템서비스, 시스템내의데이터, 시스템의컴포넌트또는자원,
시스템에의해생산되거나소비된자원
Response
트랜잭션은다음과같은방식으로수행된다.
인증되지않은접근으로부터데이터또는서비스가보호된다.
데이터나서비스가인증없이는처리되지않는다.
트랜잭션의일부가보장된다.
트랜잭션의일부가그들의포함을거부할수없다.
데이터, 자원그리고시스템서비스를합법적으로사용할수있다.
시스템은다음에의하여활동을추적
접근과변경을기록
데이터, 자원, 그리고서비스에대한접근시도를기록
공격이감지된경우적절한엔티티(사람또는시스템)에통보
ResponseMeasure
특정컴포넌트나데이터가손상되었을때시스템이얼마나손상정도
공격을감지하기까지걸린시간
얼마나많은공격을견디었는지여부
성공적인공격으로회복하는데걸린시간
특정공격에대한데이터의취약성정도

9.1
SecurityGeneral Scenario
Sample concrete security scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
원격의불만있는
고용자
지급비율의
수정시도
정상동작
시스템내부
데이터
시스템이
감사추적을수행
하루이내에올바른
데이터와변경을시도한
소스가저장된다.

9.2
Tactics for Security
Security Tactics
Detect Attacks
Resist Attacks
Recover
from Attacks
System Detects,
Resists, Reacts,
Or Recovers
Attack
Maintain
AuditTrail
Restore
Revoke
Access
See
Availability
Identify
Actors
Authenticate
Actors
Authorize
Actors
Limit Access
Limit Exposure
Encrypt Data
Separate
Entities
Change Default
Settings
React to Attacks
Lock
Computer
Inform
Actors
Detect
Intrusion
Detect Service
Denial
Verify Message
Integrity
Detect Message
Delay

9.2
Security Tactics
Detect
Attacks
Detect Intrusion
DB에저장된알려진악의적인행동패턴과네트워크트래픽또는서비스요청패턴과비교
Detect Service Denial
알려진DoS 공격패턴을시스템에들어오는네트워크트래픽신호나패턴과비교
Verify Message Integrity
메시지와파일의무결성을검증하기위해checksum또는Hash 값을사용
Detect Message Delay
악의적인사람이메시지를가로채는사람이중간에개입하는잠재적인공격을감지
Resist
Attacks
Identify Actors
시스템의모든외부입력에대한소스를확인
Authenticate Actors
사용자나원격컴퓨터가실제로누구인지보장
Authorize Actors
인증된사용자에게데이터나서비스의접근과변경에대한올바른권한이있는지확인
Limit Access
메모리, 네트워크접속등에대한자원에대한접근을포함한컴퓨팅자원에대한접근제어
Limit Exposure
시스템의외부의공격을최소화하는전략의노출을제한
Encrypt Data
인증되지않은접근으로부터의데이터보호
Separate Entities
중요한데이터와중요하지않은데이터의분리는공격의가능성을줄인다. (물리적인분리포함)
Change Default Settings
일반적이고공통적으로이용가능한시스템설정을통한잠재적인공격방지

9.2
SecurityTactics
React to
Attacks
RevokeAccess
시스템이나시스템관리자가시스템이공격을받는다고믿는다면, 정상적인사용자나사용에대해서도민감한자원에대한접근을심각하게제한할수있다.
Lock Computer
반복된로그인실패는잠재적인공격시도가될수있다.
이런경우특정컴퓨터로부터의로그인을제한할수있다.
Inform Actors
시스템에대한공격이감지되었을경우, 이에대응하기위한담당자에게통보가필요
Recover from
Attacks
Maintain Audit Trail
시스템내부데이터에적용된각트랜잭션을식별정보와함께복사해놓는다감사, 부인방지, 시스템복구지원
Restore
가용성(Availability) 참조

9.3
A Design Checklist for Security
분류
체크리스트
안전을위해필요한시스템의책임결정
-액터식별, 액터인증, 액터권한부여, 데이터나서비스에접근허용또는거부, 데이터나서비스에
접근또는변경에대한기록, 데이터암호화, 공격으로부터의복구, Checksum과Hash값검증
Coordination Model
다른시스템이나사람들과의커뮤니케이션과조정을위한메커니즘결정
-액터와시스템에대한인증및권한부여, 전송을위한데이터암호화메커니즘확인
-예상치못한자원과서비스의요구를감시및인식/접속과해제를제한하기위한메커니즘확인
Data Model
여러데이터필드에대한민감도결정
-데이터에따른민감도가분리되었는지, 민감도에따라다른접근권한과접속전접근권한을확인하는지체크,
-민감한데이터접근에대한기록과기록이적절히보호되는지확인, 데이터변경시적절히저장되는지확인
-데이터가적절하게암호화되고암호와키가데이터와분리되어있는지확인,
Mapping among
시스템서비스와자원에접근이나데이터를읽고, 쓰고수정방법의변경을고려할때아키텍처요소들에대한대안적인맵핑을결정
대안적인맵핑이데이터, 서비스, 자원접근에대한기록과예상치못한많은자원요청를인지하는데어떻게영향을줄것인지를결정
Resource Management
요구되는시스템자원과내/외부의개인과시스템의인증여부감시를결정
보안관련동작을위해필요한자원을결정, 감염된요소가다른요소를감염시키지않는지확인
민감한데이터의전달에공유자원이사용되지않는지를보장
Binding Time
늦은컴포넌트의바인딩의인스턴스가신뢰할수없는경우를결정
-해당경우각각의컴포너트는검증되어야한다.
사용자인증, 데이터접근권한, 자원보호, 데이터암호화에사용가능한기술결정
선택된기술이보안요구에관련된전술을지원하는지확인

10.1
Testability General Scenario
시나리오항목
입력가능한값
Source
단위테스터, 통합시험테스터, 시스템테스터, 고객인증테스터, 최종사용자
수동테스트수행또는자동테스팅툴수행
Stimulus
클래스계층이나서비스와같은코딩추가부분의구현완료에따른테스트셋의수행,
서브시스템의통합전체시스템의구현, 또는고객에게시스템전달
Environment
설계시간, 개발시간, 컴파일시간, 통합시간, 배포시간,수행시간
Artifact
테스트중인시스템의일부
Response
테스트셋의수행과결과의확보
결함의결과행위기록
시스템상태의통제와감시
ResponseMeasure
결함과결함의분류를구분하기위한노력
상태공간커버리지의지정된비율을달성하기위한노력
다음테스트에의해결함이나타날확률
테스트수행시간
결함을감지하기위한노력
테스트상의가장긴종속성체인의길이
테스트환경준비시간
노출된위험의감소(크기* 확률)

10.1
TestabilityGeneral Scenario
Sample concrete testability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
단위시험테스터
단위코드완성
개발환경
단위코드
시험결과수집
3시간내의85%
경로커버리지

10.2
Tactics for Testability
Testability Tactics
Control and Observe
System State
Limit Complexity
Fault
Detected
Tests
Executed
Specialized
Interfaces
Limit Structural
Complexity
Limit
Nondeterminism
Record/Playback
Localize State
Storage
Abstract Data
Sources
Sandbox
Executable
Assertions

10.2
TestabilityTactics
Controland Observe
System State
Specialized Interfaces
특화된시험인터페이스는개별적인정상동작뿐아니라테스트장비를통한변수값을기록/명세하게한다.
Record/Playback
인터페이스를통과하는정보를모으고,
이를통한시험입력생성및시험출력저장
Localize State Storage
현재상태를추적하고보고하는메커니즘으로상태저장을외부화하는StateMachine 사용
Abstract Data Sources
인터페이스추상화를통하여테스트데이터를쉽게변경가능
Sandbox
실험이가능하도록시스템의인스턴스를실세계로부터격리
ExecutableAssertions
데이터값이지정된제약을만족하는지확인
LimitComplexity
Limit StructuralComplexity
순환종속성을회피또는해결, 외부환경에대한종속성을고립시키거나캡슐화, 컴포넌트사이의종속성감소
LimitNondeterminism
결정되지않은행동에대한모든소스를발견

10.3
A Design Checklist for Testability
분류
체크리스트
어떤시스템책임이가장중요하고, 완전한테스트가필요한지결정
테스트실행과결과저장, 예상치못한행위에대한기록, 연관시스템상태의통제및관찰을위한추가적인시스템책임들의할당을확인
높은응집도, 낮은결함도, 관심의분리와낮은구조적복잡성을제공하는기능의할당을보장
Coordination Model
시스템의조정및커뮤니케이션메커니즘을확인
-시스템이나시스템사이의테스트의수행과결과기록, 결함의결과를기록하는액티비티지원
-시스템이나시스템사이의테스팅을위해사용되는통신채널로상태의주입및감시지원
Data Model
시스템의정상동작을보장하기위해반드시테스트되어야하는주요데이터추상화결정
-추상화데이터인스턴스의가능한결과값, 값설정가능여부확인
-추상화데이터인스턴스의생성, 초기화, 저장, 처리, 변환, 파기가수행및기록이가능한지확인
Mapping among
테스트를위해아키텍처요소들을어떻게맵핑할것인지를결정
-프로세스와프로세서, 쓰레드와프로세스, 모듈과컴포넌트
-원하는테스트결과를받고, 잠재적인경쟁상태를확인
Resource Management
테스트실행과결과의저장을위한충분한자원이용이가능한지확인
-테스트자원한도, 이벤트실패분석을위한자원할당, 테스트목적의새로운자원주입한계, 테스팅가상자원
테스트환경이실제수행환경을대표하는지확인
Binding Time
컴파일이후바인드된컴포넌트가늦은바운드컨텍스트로테스트되는지확인
실패시해당상황의재현이가능한지확인
전체범위의바인딩가능성에대해서테스트가가능한지확인
아키텍처에적용할테스트용이성시나리오를가능하게하는데이용가능한기술의결정
선택한기술이얼마나테스트가능한지와선택한기법이시스템에적당한테스트수준을제공하는지확인

11.1
Usability General Scenario
시나리오항목
입력가능한값
Source
최종사용자, 가능한전문역할
Stimulus
최종사용자가시스템을효율적으로사용하려고시도/시스템사용법을배우려고한다/ 에러의영향을최소화하려고한다/ 시스템을변경하려고한다/ 시스템환경을구성하려고한다
Environment
실행시간또는환경구성시간
Artifact
시스템또는사용자와상호작용하는시스템의특정부분
Response
시스템은사용자가필요로하는기능을제공하거나, 사용자의요구를예상할수있어야한다.
ResponseMeasure
작업시간, 에러의수, 완료된작업의수
사용자만족도, 사용자지식의습득
전제동작중성공한동작의비율
총에러발생시간또는에러가발생한경우분실된데이터

11.1
Usability General Scenario
Sample concrete usability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
사용자
새로운
응용프로그램
다운로드
실행시
시스템
사용자가
응용프로그램을
생산적으로사용
2분이내의
실행시험

11.2
Tactics for Usability
Usability Tactics
Support User
Initiative
Support System
Initiative
User Given
Appropriate
Feedback and
Assistance
User
Request
Cancel
Undo
Maintain Task
Model
Maintain user
Model
Maintain System
Model
Pause/Resume
Aggregate

11.2
Usability Tactics
Control and Observe
System State
Cancel
사용자가취소명령을내리면시스템은해당명령에반응해야하고, 취소되는명령은반드시종료되어야한다.
Undo
이전상태로되돌리기위해시스템은시스템의상태에대한충분한양의정보를유지해야한다.
Pause/Resume
사용자가오랜시간동작하는명령을수행시, 다른태스크에자원을할당할수있도록임시로자원을해제할수있도록한다
Aggregate
사용자가반복적인명령을수행시, 또는명령이많은수의객체에동일한방식으로적용시, 명령을그룹에대하여적용한다.
Limit
Complexity
MaintainTask Model
작업모델은컨텍스트를이해하고, 사용자에게어떤지원을할지를결정하는데사용된다.
Maintain User Model
예상응답시간이나다른항목을이용해시스템에대한사용자의지식과행동을명시적으로나타낸다.
Maintain System Model
사용자에게적절한피드백을제공하기위해예상되는시스템의동작을결정한다.

11.3
A Design Checklist for Usability
분류
체크리스트
사용자를지원하기위해필요한추가적인시스템책임이할당되었는지확인
-시스템사용방법학습, 수동으로효과적인태스크수행, 시스템의적용및구성
-사용자및시스템오류로부터의복구
Coordination Model
시스템요소의특성조정-적절성, 동시성, 완전성, 정확성, 일관성-이사용자의사용에어떻게영향을주는지결정
Data Model
사용자가인지할수있는행위를포함한주요데이터추상화를결정
-이러한데이터의추상화가사용자가태스크를완수하는데지원하기위해고안된것인지를확인
Mapping among
아키텍처요소들사이의어떤맵핑이최종사용자에게보여지는지확인
-이러한맵핑이어떻게사용자에게영향을주는지확인
Resource Management
사용자가시스템의사용자원을어떻게적용하고구성하는지결정
모든사용자구성이통제된환경하에서자원제한이사용자의태스크수행을저하시키는지확인
자원의사용수준이사용자의시스템사용능력에영향을주지않는지확인
Binding Time
사용자통제하의바인딩시간결정을결정하고사용자가사용성지원을위한결정을내릴수있는지를확인
선택된기술이시스템에적용할사용성시나리오를성취하는데도움을주는지확인
선택된기술이시스템의사용성에악영향을주지않는지확인

Chapter 12. Other Quality Attributes

12.1
Other Important Quality Attributes
가변성
(Variability)
변경용이성의특별한경우
미리계획된방식에의하여변형된산출물세트를지원하는능력
Product Line에서중요한특성
이식성
(Portability)
변경용이성의특별한경우
한플랫폼에서구현된S/W가다른플랫폼에서도동작하도록변경될수있는특성
플랫폼종속성小, 종속성의격리, 가상머신(Virtual Machine)
개발분산용이성
(Development Distributability)
소프트웨어의분산개발을지원하기위한설계품질
(코드와데이터모델에대한) 개발팀간의조정을최소화
확장성
(Scalability)
수직적확장성(논리적단위에자원추가), 수평적확장성(물리적단위자원추가)
추가된자원을얼마나효과적으로활용하는가에대한문제가생김
Effective: 추가적인자원측정가능한시스템품질향상, 추가노력이없어야하며,
시스템동작을방해하지말아야한다.
배치성
(Deployability)
실행단위가어떻게호스트플랫폼에도착하고나중에호출되는가에대한특성
이동성
(Mobility)
플랫폼의이동과제공에관한문제
배터리관리, 단절후재접속기간, 여러플랫폼지원을위한다른사용자인터페이스지원等
관찰용이성
(Monitorability)
시스템에실행시운영상태를모니터링할수있는능력
안전성
(Safety)
소프트웨어환경내에서손실, 부상, 사용자의사망등의상태의원인이되거나유도할수있는상태로들어가는것을회피하고, 나쁜상태로들어갔을경우, 손실을제한하고회복하는소프트웨어의능력
위험한실패에대한방지및회복
가용성(Availability)와관련이많다.

12.2
Other Categories of Quality Attributes
최종제품의“이로운점(Goodness)”를측정하는품질속성부류
아키텍처의개념적인무결성(Conceptual Integrity)
아키텍처설계상의일관성아키텍처에대한이해도↑,혼동에따른에러↓
같은것을같은방식(the same thing is done in the same way)으로,
그러나간결하게(Less is more)
사용품질(Quality in use)
유효성(Effectiveness)
시스템이올바르게구축되었는가? (요구사항을만족하는가?)
올바른시스템이구축되었는가? (사용자의도대로동작하는가?)
효율성(Efficiency)
비용과노력이얼마나드는가?
위험으로부터의자유(Freedom from risk)
제품이나시스템이경제적인상태, 인간의삶, 건강, 또는환경에영향을주는정도
시장성(Marketability)
시장경쟁에대한시스템의효용성(알려진아키텍처의경우다른속성보다우선시함)

12.3
Software Quality Attributes and System Quality Attributes
물리적인시스템은품질속성들을만족시키기위해내장된S/W에의존한다.
때때로소프트웨어아키텍처는시스템의품질속성에많은영향을줄수있다.
대규모시스템의경우
더많은자원요구
대용량메모리
더빠른프로세서
대용량배터리
더적은자원요구
소용량메모리
일반적인프로세서
소용량배터리
효율적인
소프트웨어
아키텍처사용
비효율적인
소프트웨어
아키텍처사용
소프트웨어
아키텍트
시스템아키텍트
또는엔지니어
소프트웨어가포함되는
시스템에서품질속성을
성취하는방법을
이해하는것이필요하다.
소프트웨어가어떻게
시스템품질에
기여하는지를
이해해야한다.

12.4
Using Standard Lists of Quality Attributes –or Not
ISO/IEC FCD 25010
System and software product Quality Requirements and Evaluation (SQuaRE)
품질속성을사용품질(Quality in Use)와제품품질(Product Quality)로구분
System Software Product Quality
Functional
suitability
Performance
efficiency
Compatibility
Usability
Reliability
Security
Maintainability
Portability
Functional
completeness
Time behavior
Coexistence
Appropriateness recogizability
Maturity
Confidentiability
Modularity
Adaptability
Functional
correctness
Resourceutilization
Interoperability
Learnability
Availability
Integrity
Reusability
Installability
Functional
appropriateness
Capacity
Operability
Faulttolerance
Nonrepudiation
Analyzability
Replaceability
User error prediction
Recoverability
Accountability
Modifiability
User interfaceaesthetics
Authenticity
Testability
Accessibility

Appendix : Quality Attributes in ISO 9126
ISO 9126 defines 6 attributes
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
Product
Operations
Product
Transition
Product
Revision
Maintainability -Can I fix it?
Flexibility -Can I change it?
Testability -Can I test it?
Portability -Will I be able to use on
another machine?
Reusability -Will I be able to reuse
some of the software?
Interoperability -Will I be able to interface it
with another machine?
Correctness -Does it do what I want?
Reliability -Does it do it accurately all the time?
Efficiency -Will it run on my machine as well as it can?
Integrity -Is it secure?
Usability -Can I run it?

12.4
Using Standard Lists of Quality Attributes –or Not
표준품질속성리스트의장점과단점
표준품질속성리스트의사용은
체크리스트로도움을줄수있다. 그러나용어에너무집착하는것은좋지않다.
품질속성과그하위품질속성이무엇인지에논하는것은대부분의미없는일이다.
품질속성시나리오는품질속성을논할때, 가정정확하게이야기할수있는방법이다.
요구사항(Requirements)수집시
-요구사항에대한체크리스트작성에도움을준다
-중요한요구(Needs)가빠졌는지확인하게한다
관심을가지는분야의품질속성에대한체크리스트
작성의기초가된다.
-도메인, 산업, 조직, 제품
완벽한리스트가될수없다
이해보단논란을만드는경우가있다
때때로분류에중점을둔다
아키텍트에게모든품질속성에관심을두도록
강요한다
-시스템에불필요한품질속성에대해서도
장점
단점

12.5
Dealing with “X-ability”: Bring a New Quality Attribute into the Fold
1 단계: 새로운품질속성에대한시나리오작성
1.1 이해당사자를통하여새로운품질속성에대한필요성확인
1.2해당품질속성의특징을묘사하는시나리오들작성
1.3 수집된시나리오들을일반화한시나리오작성
2 단계: 새로운품질속성을위한설계방법만들기
2.1 기존패턴을조사하고, 각패턴이새품질속성에어떻게영향을
주는지확인
2.2 품질속성을다루기위한설계기법조사
2.3 전문가와면담및조언들기
2.4 일반화시나리오를통하여올바른응답을만들기위한설계방법의
리스트목록화
2.5 일반화시나리오를통하여문제아키텍처가요구된응답에
실패하는경우에대한리스트목록화와이러한경우를제거하기
위한설계방법의고안
3 단계: 새로운품질속성모델링
3.1 설계방법(패턴과전술)의셋을만드는데도움을줄수있는
개념모델생성
3.2 모델을통한품질속성에영향을주는파라미터세의이해
4 단계: 새로운품질속성에대한설계전략세트만들기
4.1 품질속성에대한전술의소스(모델과전문가)파악
4.2 모델에기반한전술생성
4.2.1 모델의파라미터열거
4.2.2 파라미터별로영향을주는아키텍처적인결정들열거
5 단계: 새로운품질속성에대한설계체크리스트작성
5.1 설계결정에대한7가지분류에대하여시험한다.
5.2 소프트웨어아키텍처에대한리뷰
-어떻게새로운품질을만족할것인지이해
디자인문제를추적가능하게한다
일부속성은모델을만들수경우가있다. 이경우…
-해당분야의전문가와인터뷰
-시스템에대한검사
-관련된디자인검색
-문서화된아키텍처패턴검사

Chapter 13. Architectural Tactics and Patterns

In this Chapter …
아키텍처패턴은
현실에서반복적으로발견되는설계결정의묶음으로,
재사용을가능하게하는특성을가지며,
아키텍처의분류를묘사한다.
아키텍처패턴과설계전술
전술은단일구조나계산메커니즘에사용한다. (Atom)
아키텍처패턴은전술들의집합이다. (Molecule)
전술은아키텍처패턴의구성요소(Building Block)이다.
전술이단일전술인반면, 패턴은여러설계전략의조합으로나타난다.
아키텍처패턴과전술은좋은설계구조를만들기위한검증된방법이기대문에재사용이가능하다.
설계전략
아키텍트패턴

13.1
Architectural Patterns
특정문제를해결하기위해반복되어사용되는솔루션을문서화한것
아키텍처패턴을다음과같은장점이있다.
검증된아키텍처
구축전시스템의특성에대하여시뮬레이션이가능
기존시스템을이해하는데도움
{컨텍스트, 문제, 해결방법}은패턴의문서화를위한형식을구성한다.
복잡한시스템은동시에하나이상의패턴을사용한다.
Problem
Solution
Context
Architectural
Patterns
문제가반복적으로일어나는일반적인환경
주어진Context에서발생하는
추상화되고, 일반화된문제
문제에대한성공적인아키텍처적인해결책
다음의내용을결정하거나설명
-Elements
-Relations
-Constraints

13.2
Overview of the Patterns Catalog
패턴은Context, Problem, Solution을기술
Solution에는Elements, Relations, Constraints를포함
패턴을적용하는것은양단(all-or-nothing)의결정은아니다.
때때로Trade-off 발생
패턴은아래와같은타입으로분류가가능하다
Module Pattern
Component & Connector Pattern
Allocation Pattern : S/W 요소의조합을보여줌
ModulePattern
C&CPatterns
Allocation Pattern
Layered Pattern
BrokerPattern
Model-View-Controller Pattern
Pipe-and-Filter Pattern
Client-Server Pattern
Peer-to-Peer Pattern
Service-Oriented Architecture Pattern
Publish-Subscribe Pattern
Shared-Data Pattern
Map-ReducePattern
Multi-tier Pattern

Chapter 14. Quality Attribute Modeling and Analysis

In this Chapter …
아키텍처분석은시스템품질에대한초기의예측을가능하게한다.
시스템개발동안의불필요한활동을줄여준다.
Architecture let us to do better than that, much better …
아키텍처분석은구현시작전에시스템(들)이어떻게구현되고, 품질속성을달성하는지를알게한다.
품질속성분석
일부품질속성은분석적인모델링기법으로이해되고, 강력한검증이가능
성능(Performance), 가용성(Availability)
어떤품질속성은체크리스트를통하여분석할수가능
보안성(Security)
그외품질속성은대략적인계산(back-of-the-envelop calculation)과실험(Experiments)을통해서알수있다.

14.1
Modeling Architectures to Enable Quality Attribute Analysis

소프트웨어 아키텍처

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 소프트웨어 아키텍처

Similar a 소프트웨어 아키텍처 (20)

Más de 영기 김

Más de 영기 김 (19)

소프트웨어 아키텍처