3. 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
5. In this Chapter …
소프트웨어아키텍처책에대한2 가지가정
소프트웨어시스템의성공적인개발에있어서소프트웨어아키텍처는중요하다.
아키텍처책은충분한양의,일반화된, 지식체계를포함하고있다.
비즈니스목표
(추상적)
최종적인결과시스템
(구체적)
소프트웨어아키텍처
(설계, 분석, 문서화, 구현)
6. 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
9. 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?
10. 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
11. 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
12. 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
30. In this Chapter …
Starts with Saul Steinberg’s cartoon
View Of The World From 9th Avenue (New Yorker’s view of the world)
31. 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?
39. 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
40. 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
41. 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
53. 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
54. 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
55. 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
56. 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)
65. In this Chapter …
상호운용성(Interoperability)이란…
상호운용성이란둘이상의시스템들이의미있는정보를특정컨텍스트내에서인터페이스를통하여교환할수있는정도를의미한다.
상호운영성은다음의2가지의미를가진다.
Syntactic interoperability : 데이터를교환할수있는능력
Semantic interoperability : 교환된데이터를올바르게해석할수있는능력
상호운용성은시스템들이예상하는운용방식에영향을받는다.
시스템이상호운영할외부시스템의인터페이스를미리알고있다면,
해당정보가시스템에포함되도록설계가가능하다.
시스템을좀더일반화된형식으로상호운영토록설계할수있다.
상호운영성은“된다, 안된다”의명제가아니라여러의미(shades of meaning) 를가진다.
66. 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
76. 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
78. 7.3
A Design Checklist for Interoperability
분류
체크리스트
Allocation of Responsibilities
기술적, 법적, 사회적, 업무적, 고객에의한변화의고려를통해일어날만한변화와변화의분류결정
-변경을위해추가, 변경, 삭제가필요한책임결정, 변화에영향을받는책임결정
-모듈에대한책임의결정(동일모듈에서동시에변경/ 다른모듈에서다른시점에변경)
Coordination Model
어떤기능과품질속성이실행시변경되는지여부와그것이조정모델에얼마나영향을주는지결정
변화에대한조정을위해어떤디바이스, 프로토콜, 통신경로가사용되는지결정
Data Model
데이터의추상화,동작, 특성에어떤변경이있는지결정(생성, 초기화, 지속, 처리, 변환, 파기포함)
최종사용자, 시스템관리자, 또는개발자에의해변경이일어날지여부결정
Mapping among
Architectural Elements
실행, 컴파일, 설계또는빌드시의기능과계산요소의맵핑이바람직한변경방식인지를결정
기능과품질속성의추가, 삭제, 변경을수용하기위해필요한변경의범위를결정
-실행종속성/ 데이터베이스에데이터할당/프로세스, 쓰레드, 프로세서실행요소할당
Resource Management
자원사용에영향을주는책임이나품질속성을어떻게추가, 삭제, 변경할것인지를결정
변경후의자원이시스템요구사항을만족하는지확인
모든자원관리자를캡슐화하고, 이러한자원관리자에의해구현된정책들이캡슐화되고바인딩이가능한범위까지지연되는지를확인
Binding Time
변경이필요할최종시간을결정
선택된시간에적당한기능을제공하기위한지연바인딩메커니즘을선택
메커니즘소개비용과선택된메커니즘을사용하여만들어지는변경을결정
변화가내포하는종속성사이의선택은복잡하고알려져있지않기때문에너무많은바인딩선택사항을갖지말것
Choice of Technology
선택된기술에의하여어떠한변경이더쉬워지는지또는어려워지는결정한다.
가장있음직한변경을지원하기기술의선택
79. 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
80. 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
81. 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
82. 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).
83. 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.
101. 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
102. 10.2
TestabilityTactics
Controland Observe
System State
Specialized Interfaces
특화된시험인터페이스는개별적인정상동작뿐아니라테스트장비를통한변수값을기록/명세하게한다.
Record/Playback
인터페이스를통과하는정보를모으고,
이를통한시험입력생성및시험출력저장
Localize State Storage
현재상태를추적하고보고하는메커니즘으로상태저장을외부화하는StateMachine 사용
Abstract Data Sources
인터페이스추상화를통하여테스트데이터를쉽게변경가능
Sandbox
실험이가능하도록시스템의인스턴스를실세계로부터격리
ExecutableAssertions
데이터값이지정된제약을만족하는지확인
LimitComplexity
Limit StructuralComplexity
순환종속성을회피또는해결, 외부환경에대한종속성을고립시키거나캡슐화, 컴포넌트사이의종속성감소
LimitNondeterminism
결정되지않은행동에대한모든소스를발견
103. 10.3
A Design Checklist for Testability
분류
체크리스트
Allocation of Responsibilities
어떤시스템책임이가장중요하고, 완전한테스트가필요한지결정
테스트실행과결과저장, 예상치못한행위에대한기록, 연관시스템상태의통제및관찰을위한추가적인시스템책임들의할당을확인
높은응집도, 낮은결함도, 관심의분리와낮은구조적복잡성을제공하는기능의할당을보장
Coordination Model
시스템의조정및커뮤니케이션메커니즘을확인
-시스템이나시스템사이의테스트의수행과결과기록, 결함의결과를기록하는액티비티지원
-시스템이나시스템사이의테스팅을위해사용되는통신채널로상태의주입및감시지원
Data Model
시스템의정상동작을보장하기위해반드시테스트되어야하는주요데이터추상화결정
-추상화데이터인스턴스의가능한결과값, 값설정가능여부확인
-추상화데이터인스턴스의생성, 초기화, 저장, 처리, 변환, 파기가수행및기록이가능한지확인
Mapping among
Architectural Elements
테스트를위해아키텍처요소들을어떻게맵핑할것인지를결정
-프로세스와프로세서, 쓰레드와프로세스, 모듈과컴포넌트
-원하는테스트결과를받고, 잠재적인경쟁상태를확인
Resource Management
테스트실행과결과의저장을위한충분한자원이용이가능한지확인
-테스트자원한도, 이벤트실패분석을위한자원할당, 테스트목적의새로운자원주입한계, 테스팅가상자원
테스트환경이실제수행환경을대표하는지확인
Binding Time
컴파일이후바인드된컴포넌트가늦은바운드컨텍스트로테스트되는지확인
실패시해당상황의재현이가능한지확인
전체범위의바인딩가능성에대해서테스트가가능한지확인
Choice of Technology
아키텍처에적용할테스트용이성시나리오를가능하게하는데이용가능한기술의결정
선택한기술이얼마나테스트가능한지와선택한기법이시스템에적당한테스트수준을제공하는지확인
106. 11.1
Usability General Scenario
Sample concrete usability scenario
Source:
Stimulus:
Environment:
Response:
Response
Measure:
1
2
3
4
Artifact:
사용자
새로운
응용프로그램
다운로드
실행시
시스템
사용자가
응용프로그램을
생산적으로사용
2분이내의
실행시험
107. 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
108. 11.2
Usability Tactics
Control and Observe
System State
Cancel
사용자가취소명령을내리면시스템은해당명령에반응해야하고, 취소되는명령은반드시종료되어야한다.
Undo
이전상태로되돌리기위해시스템은시스템의상태에대한충분한양의정보를유지해야한다.
Pause/Resume
사용자가오랜시간동작하는명령을수행시, 다른태스크에자원을할당할수있도록임시로자원을해제할수있도록한다
Aggregate
사용자가반복적인명령을수행시, 또는명령이많은수의객체에동일한방식으로적용시, 명령을그룹에대하여적용한다.
Limit
Complexity
MaintainTask Model
작업모델은컨텍스트를이해하고, 사용자에게어떤지원을할지를결정하는데사용된다.
Maintain User Model
예상응답시간이나다른항목을이용해시스템에대한사용자의지식과행동을명시적으로나타낸다.
Maintain System Model
사용자에게적절한피드백을제공하기위해예상되는시스템의동작을결정한다.
109. 11.3
A Design Checklist for Usability
분류
체크리스트
Allocation of Responsibilities
사용자를지원하기위해필요한추가적인시스템책임이할당되었는지확인
-시스템사용방법학습, 수동으로효과적인태스크수행, 시스템의적용및구성
-사용자및시스템오류로부터의복구
Coordination Model
시스템요소의특성조정-적절성, 동시성, 완전성, 정확성, 일관성-이사용자의사용에어떻게영향을주는지결정
Data Model
사용자가인지할수있는행위를포함한주요데이터추상화를결정
-이러한데이터의추상화가사용자가태스크를완수하는데지원하기위해고안된것인지를확인
Mapping among
Architectural Elements
아키텍처요소들사이의어떤맵핑이최종사용자에게보여지는지확인
-이러한맵핑이어떻게사용자에게영향을주는지확인
Resource Management
사용자가시스템의사용자원을어떻게적용하고구성하는지결정
모든사용자구성이통제된환경하에서자원제한이사용자의태스크수행을저하시키는지확인
자원의사용수준이사용자의시스템사용능력에영향을주지않는지확인
Binding Time
사용자통제하의바인딩시간결정을결정하고사용자가사용성지원을위한결정을내릴수있는지를확인
Choice of Technology
선택된기술이시스템에적용할사용성시나리오를성취하는데도움을주는지확인
선택된기술이시스템의사용성에악영향을주지않는지확인
112. 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)
시장경쟁에대한시스템의효용성(알려진아키텍처의경우다른속성보다우선시함)
113. 12.3
Software Quality Attributes and System Quality Attributes
물리적인시스템은품질속성들을만족시키기위해내장된S/W에의존한다.
때때로소프트웨어아키텍처는시스템의품질속성에많은영향을줄수있다.
대규모시스템의경우
더많은자원요구
대용량메모리
더빠른프로세서
대용량배터리
더적은자원요구
소용량메모리
일반적인프로세서
소용량배터리
효율적인
소프트웨어
아키텍처사용
비효율적인
소프트웨어
아키텍처사용
소프트웨어
아키텍트
시스템아키텍트
또는엔지니어
소프트웨어가포함되는
시스템에서품질속성을
성취하는방법을
이해하는것이필요하다.
소프트웨어가어떻게
시스템품질에
기여하는지를
이해해야한다.
114. 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
115. 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?
116. 12.4
Using Standard Lists of Quality Attributes –or Not
표준품질속성리스트의장점과단점
표준품질속성리스트의사용은
체크리스트로도움을줄수있다. 그러나용어에너무집착하는것은좋지않다.
품질속성과그하위품질속성이무엇인지에논하는것은대부분의미없는일이다.
품질속성시나리오는품질속성을논할때, 가정정확하게이야기할수있는방법이다.
요구사항(Requirements)수집시
-요구사항에대한체크리스트작성에도움을준다
-중요한요구(Needs)가빠졌는지확인하게한다
관심을가지는분야의품질속성에대한체크리스트
작성의기초가된다.
-도메인, 산업, 조직, 제품
완벽한리스트가될수없다
이해보단논란을만드는경우가있다
때때로분류에중점을둔다
아키텍트에게모든품질속성에관심을두도록
강요한다
-시스템에불필요한품질속성에대해서도
장점
단점
126. In this Chapter …
아키텍처분석은시스템품질에대한초기의예측을가능하게한다.
시스템개발동안의불필요한활동을줄여준다.
Architecture let us to do better than that, much better …
아키텍처분석은구현시작전에시스템(들)이어떻게구현되고, 품질속성을달성하는지를알게한다.
품질속성분석
일부품질속성은분석적인모델링기법으로이해되고, 강력한검증이가능
성능(Performance), 가용성(Availability)
어떤품질속성은체크리스트를통하여분석할수가능
보안성(Security)
그외품질속성은대략적인계산(back-of-the-envelop calculation)과실험(Experiments)을통해서알수있다.