BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
'2013/05'에 해당되는 글 10건
2013.05.10 15:09

2장. Why Is Software Architecture Important?

3장. The Many Contexts of Software Architecture

 

2부. Quality Attributes

4장. Understanding Quality Attributes

4.1 Architecture and Requirements

4.2 Functionality

4.3 Quality Attribute Considerations

4.4 Specifying Quality Attribute Requirements

4.5 Achieving Quality Attributes through Tactics

4.6 Guiding Quality Design Decisions

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 20:34
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 19:52

아키텍처는 설계결정들의 컬렉션을 적용한 결과라고도 말 할 수 있을 것이다.

저자들은 설계결정을 7가지 카테고리로 나누고 있다.

책임 할당(Allocation of responsibilities)Coordination mode, 데이타 모델(Data model), 자원 관리(Management of resources), 아키텍처 요소들 사이의 매핑(Mapping among architectural elements), Binding time decisions, 기술 선택(choice of technology)

 

책임 할당(Allocation of responsibilities)

할당할 중요한 책임이 무엇이고, 그 책임을 어떤 요소에 어떻게 할당할 것인지에 대한 결정

Identifying the important responsibilities, including basic system functions, architectural infrastructure, and satisfaction of quality attributes.

Determining how these responsibilities are allocated to non-runtime and runtime elements (namely, modules, components, and connectors).

이러한 결정들에 대한 전략에는 기능 분할(functional decomposition), 실세계 객체들을 모델링(modeling real-world objects), 시스템 동작의 주요 모드들에 기반한 그루핑(grouping based on the major modes of system operation), 유사한 품질 요구사항들에 기반한 그루핑(grouping based on similar quality requirements)과 같은 것들이 있다.

 

Coordination model

소프트웨어는 설계된 메커니즘을 통해 서로 상호작용하는 요소들에 의해 동작한다. 이러한 메커니즘들을 모아 coordination model이라고 한다.

coordinate해야 하는 요소와 coordinate하지 못하도록 해야 하는 요소들을 식별하고, coordination의 특성들 정하고, 커뮤니케이션 메커니즘 선택에 대한 결정 

Identifying the elements of the system that must coordinate, or are prohibited from coordinating.

Determining the properties of the coordination, such as timeliness, currency, completeness, correctness, and consistency.

Choosing the communication mechanisms (between systems, between our system and external entities, between elements of our system) that realize those properties. Important properties of the communication mechanisms include stateful versus stateless, synchronous versus asynchronous, guaranteed versus nonguaranteed delivery, and performance-related properties such as throughput and latency.

 

데이타 모델(Data model)

주요 데이터 추상들과 그들의 오퍼레이션들과 속성들을 선택하고, 일관된 데이터 해석을 위한 메타데이터 작성하고 데이터를 조직과 관련된 결정

Choosing the major data abstractions, their operations, and their properties. This includes determining how the data items are created, initialized, accessed, persisted, manipulated, translated, and destroyed.

Compiling metadata needed for consistent interpretation of the data.

Organizing the data. This includes determining whether the data is going to be kept in a relational database, a collection of objects, or both. If both, then the mapping between the two different locations of the data must be determined.

 

자원 관리(Management of resources) 

소프트웨어 시스템은 제한된 하드웨어 자원(CPU, memory, battery, hardware buffers,
system clock, I/O ports)과 소프트웨어 자원(system locks, software buffers, thread pools, and non-thread-safe code)을 갖는다.
공유된 자원은 관리되어야 한다.

어떤 자원이 관리되어야 하고, 어떤 시스템 요소가 각각의 자원을 관리하고, 어떻게 자원이 공유되고, 어떤 전략을 경쟁에 사용하고, 다른 자원의 포화상태에서의 영향이 어떠한지를 결정 

Identifying the resources that must be managed and determining the limits for each.

Determining which system element(s) manage each resource.

Determining how resources are shared and the arbitration strategies employed when there is contention.

Determining the impact of saturation on different resources.

 

아키텍처 요소들 사이의 매핑(Mapping among architectural elements)

아키텍트는 두 종류의 매핑을 제공해야 한다. 첫 번째는 서로 다른 유형의 아키텍처 구조에 속하는 구성요소들 사이의 매핑이고, 두 번째는 소프트웨어 요소와 환경 요소와의 매핑이다.

첫 번째 매핑의 예: 개발 단위(모듈)을 실행 단위(쓰레드나 프로세스)에 매핑

두 번째 매핑의 예: 프로세스를 프로세스가 실행되는 특별한 CPU에 매핑

 

Binding time decisions

설계결정은 누가, 어느 시점(개발 주기의)에 할 것인가에 따라 좀 더 다양하게 분류될 수 있을 것이다. 따라서 나머지 6개의 카테고리의 속하는 설계결정들은 연관된 binding time decisions을 갖는다.

Binding time decisions introduce allowable ranges of variation. This variation can be bound at different times in the software life cycle by different entities from design time by a developer to runtime by an end user. A binding time decision establishes the scope, the point in the life cycle, and the mechanism for achieving the variation. 

 

기술 선택(choice of technology)

모든 아키텍처 결정은 궁극적으로 특별한 기술을 사용해서 실현되기 때문에 아키텍트는 기술들을 결정해야 한다.

설계 결정을 실현하기 위해 사용할 기술들과 기술들을 지원할 도구들을 결정하고, 기술 지원에대한 내부적 외부적 지원 정도와 기술 선택에 대한 부수적 효과와 새로운 기술이 존재하는 기술들과 호환될 수 있는지를 결정

Deciding which technologies are available to realize the decisions made in the other categories.
Determining whether the available tools to support this technology choice (IDEs, simulators, testing tools, etc.) are adequate for development to proceed.

Determining the extent of internal familiarity as well as the degree of external support available for the technology (such as courses, tutorials, examples, and availability of contractors who can provide expertise in a crunch) and deciding whether this is adequate to proceed.

Determining the side effects of choosing a technology, such as a required coordination model or constrained resource management opportunities.

Determining whether a new technology is compatible with the existing technology stack. For example, can the new technology run on top of or alongside the existing technology stack? Can it communicate with the existing technology stack? Can the new technology be monitored and managed?

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 15:00

아키텍트는 자극과 환경과 대응으로 주어진 문제에 대해서 어떻게 해결할 것인지를 결정해야 한다. 아키텍트의 이러한 설계결정을 아키텍처 전술(architectural tactics)이라 한다. 아키텍처 전술은 하나의 품질속성 대응에 초점을 맞춘다. 품질속성간에 트레이드 오프는 전술들의 패키지인 아키텍처 패턴에서 언급한다.

품질속성별로 초점을 맞춘 것이 전술이니, 당연하게 전술들은 품질속성별로 분류된다. 이 부분 또한 높게 평가할 부분들 중 하나이다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 13:01

사람들은 이야기를 좋아한다. 이미 시나리오는 기능 요구사항을 명세하는데 널리 사용되고 있고 유용한 것으로 평가되고 있다. 이런 상황에서 품질속성 요구사항을 명세하는데 시나리오를 사용하는 것은 현명한 선택으로 보인다.

당연한 것이 당연한 것이 아닐 수 있다. 필자는 이 책을 포함한 SEI 식의 소프트웨어 아키텍처의 가장 위대한 성과는 품질속성 시나리오라고 평가한다.

 

저자들은 품질속성에 대한 일반화된 시나리오를 템플릿 형태로 제시하고, 이를 general quality attribute scenario라고 부른다.

시나리오는 source of stimulus, stimulus, environment, artifact, response, response measure와 같은 6개의 부분으로 이루어진다.

자극(stimulus)은 시스템 밖의 무엇인가에 의해 생긴다. 자극을 일으키는 그 무엇인가를 자극의 출처(source of stimulus)라고 한다. 시스템이 반응할 필요가 없는 것은 자극이 아니다. 시스템이 반응해야 하는 시스템 밖에서 일어난 일(event)을 자극이라고 한다.

시스템은 아무 때나 외부 자극에 반응하지 않고, 특정한 조건에서만 반응할 수도 있다. 시스템이 수행 중에 처하는 특정한 조건을 시스템이 어떤 환경에 처했을 때인가로 표현하고, 이를 환경(environment)이라고 한다.

시스템은 다양한 구성요소들로 이루어지는데, 특정한 자극에는 일부 시스템 구성요소들만 반응해야 할 때도 있다. 자극에 반영하는 시스템 구성요소를 artifact라고 한다.

자극에 대응해야 하는 시스템 구성요소들이 어떻게 대응해야 하는가를 대응(response)라고 한다.

어떻게 대응해야하는가는 측정가능하고 시험가능해야 함으로 구체적인 기준을 명시해야 한다. 이것을 대응기준(response measure)라고 한다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 12:36

품질속성은 다양한 방법으로 분류될 수 있을 것이다. 유용한 분류법의 하나는 시스템의 런타임 속성인가 개발 속성인가로 구분하는 것이다.

복잡한 시스템에서는 하나의 품질속성이 고립되어 그 자체만으로 달성되지 않는다. 서로 다른 품질속성들이 서로에게 긍정적이거나 부정적인 영향을 주고 받는다.

아키텍트는 전체 시스템의 목적을 달성하는데 최적화 되도록 품질속성들의 정도를 조정해야 한다. 품질속성은 다양한 이해관계자들에 의해 요구되기 때문에 이를 조정하기 위해서는 먼저 이해관계자들간의 품질속성에 대한 이해가 요구된다.

저자들은 먼저 우리가 품질속성을 어떻게 명세하고, 특별한 품질속성을 달성하도록 하는 아키텍처 결정이 무엇이고 어떤 질문을 함으로 올바른 아키텍처 결정을 내릴 수 있는지를 알려주고 싶어한다.

Our purpose here is to provide the context for discussing each quality attribute. In particular, we focus
on how quality attributes can be specified, what architectural decisions will enable the achievement of particular quality attributes, and what questions about quality attributes will enable the architect to make the correct design decisions.

이후의 절들에서는 이것들을 차례대로 다룬다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 12:19

이미 앞에서도 이야기 했듯이, 저자들은 기능이 아키텍처를 결정하는데 별 상관이 없는 것으로 이야기하고 있다.

Functionality has the strangest relationship to architecture. First of all, functionality does not determine architecture.

필자는 구조를 기능구조와 비기능구조로 나누어야 하고, 기능구조도 아키텍처에 포함해야 하며기능구조는 도메인구조를 반영해야 한다고 강하게 주장한다.

'도메인구조를 반영해서 기능구조를 만든다'는 말에는 '도메인구조를 이해하고 이를 그대로 반영한다'는 의미가 강해게 암시되는 것 같다. 이 의미를 좀 더 확장하면, 의사결정할 일이 없다는 의미도 될 수 있을 것 같고, 이를 더 확장하면 도메인 구조를 설계하는 것이 아니라 제약사항으로 받아들여진다는 의미가 될 수도 있을 것 같다.

하지만, 현실적으로 도메인에는 소프트웨어 시스템 개발에 사용할 도메인구조가 명시적으로 제시되지 않는다. 도메인구조는 특정한 방법론이나 접근 방법에 의해 논리구조가 결정된다. 논리구조는 얼마나 기술적으로 잘 구현할 것인지가 배제된 것으로 철저하게 기능에 의해 결정된다. 도메인의 변화가 발생했을 때 그 변화를 유의미하게 반영하기 위해서는 도메인구조를 시스템구조로 반영해야 한다. 이 구조가 잘 못 결정되면 수정용이성과 같은 품질속성에도 큰 영향을 미치게 되는 것이다.

소프트웨어 시스템은 도메인에 영향에서 절대 자유로울 수 없기 때문에 도메인구조에 해당하는 기능구조에 큰 영향을 받는다. 이러한 이유로 구조설계의 많은 노력이 기능구조에 들여져야 하는 것이다. 

저자들은 마치 기능을 품질속성 중심으로 결정된 구조에 태우는 것처럼 이야기한다. 저자들의 이러한 설명은 이 책을 통해 공부하는 아키텍처들에게 도메인구조는 버려두고 품질속성에 충실한 구조 만을 만들어내는 우를 범하게 할 수 있다. 이러한 경우에 발생할 수 있는 일반적인 우가 도메인구조를 반영하지 않는 모듈구조일 것이다.

But although functionality is independent of any particular structure, functionality is achieved by assigning responsibilities to architectural elements, resulting in one of the most basic of architectural structures.
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 11:47

요구사항은 일반적으로 기능요구사항와 비기능요구사항으로 구분된다. 비기능요구사항은 품질속성 요구사항과 제약사항으로 구분된다.

저자들은 비기능요구라는 용어를 사용하지 않고, 요구사항을 기능 요구사항(Functional requirements), 품질속성 요구사항(Quality attribute requirements), 제약사항(Constraints)과 같이 구분하고 있다.

기능 요구사항은 시스템이 무엇을 해야 하는지와 사용자와 시스템이 어떻게 상호작용해야 하는지를 나타낸다.

품질속성 요구사항은 기능 요구사항이나 전체 시스템의 품질에 대한 요구사항이다.

제약사항은 선택의 자유도가 없는 이미 정해진 설계 결정이다. 프로그래밍 언어나 기존 모듈의 재사용이나 서비스 지향으로 시스템을 개발할 것과 같은 것들은 시스템 개발 전에 결정되어 제약으로 사용될 수 있다.

 

이들 요구사항들과 아키텍처는 어떤 관계가 있을까?

기능 요구사항은 설계를 통해 아키텍처 요소들에게 적당하게 책임을 부여함으로 만족되어진다.

품질속성 요구사항은 아키텍처로 설계된 다양한 구조들에 의해 만족된다.

제약사항은 설계 결정을 수용하고, 다른 영향 받는 설계 결정들을 잘 조화시킴으로 만족된다.

What is the “response” of architecture to each of these kinds of requirements?

1. Functional requirements are satisfied by assigning an appropriate sequence of responsibilities throughout the design. As we will see later in this chapter, assigning responsibilities to architectural elements is a fundamental architectural design decision.

2. Quality attribute requirements are satisfied by the various structures designed into the architecture, and the behaviors and interactions of the elements that populate those structures. Chapter 17 will show this approach in more detail.

3. Constraints are satisfied by accepting the design decision and reconciling it with other affected design decisions.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.06 11:19

이 시점에서 이 책을 읽는 독자들은 다음과 같은 것들이 궁금할 것 같다. 

품질속성이 뭐야? 왜 품질속성이라고 했을까?

품질속성이란 것은 시스템에 요구되는 것이라고 했는데, 그럼 요구사항이 아닌가?

품질속성 요구사항을 어떻게 명세하지?

품질속성은 아키텍처에 의해 달성된다고 했는데 품질속성을 달성하기 위한 아키텍처는 어떻게 설계할것인가?

아키텍처에 의해 품질속성이 달성되었는지를 어떻게 알 수 있는가? 어떻게 평가할 것인가?

 

저자들은 품질속성에 대해서 다음과 같이 정의한다.

A quality attribute is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.

시스템은 여러 종류의 속성들을 갖는다. 품질속성은 품질에 대한 시스템 속성이다. 품질속성은 시스템이 이해관계자들의 품질에 대한 니즈를 얼마나 잘 만족시켜주는가를 나타내는데 사용된다. 품질속성은 정도를 나타내는 것으로 측정되고 시험가능해야 한다.

 

저자는 우리에게 다음과 같은 세 가지를 알려주기 원한다고 한다.  다행이도 우리가 알고자 하는 것들을 포함하고 있다.

How to express the qualities we want our architecture to provide to the system or systems we are building from it.

How to achieve those qualities.

How to determine the design decisions we might make with respect to those qualities.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.05.04 12:02

2부에서 저자들이 알려주고자 하는 것은 무엇인가?

특별한 품질속성을 달성하기 위해 어떻게 아키텍처를 설계하고 분석할 것인가에 대한 알려주고자 한다. 프로세스는 언급하지 않는데, 이것은 3부에서 다룬다.

4장에서는 품질속성 요구사항을 어떻게 명세하고, 품질속성을 달성하도록 하는 설계기술(전술)을 다룬다. 저자들은 설계결정을 7가지 카테고리(availability, interoperability, modifiability, performance, security, testability, usability)로 구분해서 다룬다.

5장에서 11장까지는 4장에서 언급한 7가지 카테고리를 하나 하나 다룬다.

13장에서는 가장 중요한 패턴들 중의 몇몇을 언급하고, 패턴과 전술 사이의 관계에 대해서 다룬다.

14장에서는 특별한 품질속성에 대한 설계를 분석하는 기술로 모델링 기술을 다룬다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바