개요

여기서는 Software Architecture의 정의에 대해서 살펴 보고, Architecture가 무엇으로 어떻게 표현되는지 살펴 본다. 이 후 어떻게 Architecture Design을 수행하는지, 이와 관련된 Architecture Style, Tactics 등에 대해서는 따로 정리해 보기로 한다. 최종 설계된 Architecture가 어떻게 문서화 될 수 있는지도 이후 살펴 보도록 한다.
 

소프트웨어 아키텍처(Software Architecture)의 정의

Wikipedia[1]에서도 [2]의 정의를 가장 앞에 두고 채용하고 있다. 이 책은[2]는 Carnegie Mellon 대학의 Software Engineering Institute (SEI)의 Software Engineering Book Series[3] 중의 하나이기도 하다.

 

"The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, and properties of both"

 

"시스템의 소프트웨어 아키텍처는 시스템에 대해 추론하는 데 필요한 구조의 집합으로, 소프트웨어 구성 요소(Element)와 속성(Properties)로 구성된다."

 

여기서 구조(Structure)와 뷰(View)에 대해서 잘 이해애야 한다. [2]에서의 설명을 보면 다음과 같다.

 

  • A view is a representation of a structure. It consists of a representation of a set of elements and the relations among them.
  • A structure is the set of elements itself, as they exist in software or hardware.

즉, Structure가 Architecture를 구성하는 Element의 집합이라는 것이고 Architecture의 일부라는 것을 알 수 있다. 그렇다면, View를 이 Structure를 보여주는 (Represent) 것이다. Architecture를 설계하는 Architect는 결국 Structure를 설계하는 것이다. 그리고 설계한 Structure를 View를 통해서 보여주고(Represent)하고 문서화 한다(Document). 이 View에 대해서는 따로 상세히 이야기 하기로 한다.

 

Software Architecture에 대한 다른 정의를 Martin Fowler의 논문[4]에서 찾아 볼 수 있다. 

 

"Architecture is the set of design decisions that must be made early in a project." 

 

여기서 design decision을 Architectural Design Decision이라고 부른다. 이는 Software System의 요구 사항(Requirement)에 대해서 다른 결과를 제공하는 Architecture Design들의 차이점을 비교하여 내리는 결정들이라고 할 수 있다. 

 

이 내용을 요약하면, Software Architecture는 어떻게 Software System의 Structure를 보여주는 View들을 통해서 Stakeholder들에게 보여 주는가? 그리고, 이러한 Structure들을 선택하여 결정한 Architectural Design Decision을 Stakeholder들에게 설명하는가가 중요하다고 할 수 있다. 이는 최종 결과물에 대한 것이고 이러한 최종 결과물을 찾아 가는 과정은 또한 다른 이야기 이다. 이 최종 결과물은 여러가지 형태가 가능하겠지만, 여기서는 문서 (Architecture Document)로 보도록 한다.

 

 

뷰(Views)

View는 Software Architecture를 다양한 측면에서 바라 보는 것이라고 할 수 있다. 여기서는 CMU SEI의 Three View와 RUP의 4+1 View를 기준으로 설명하고 둘 간의 겹치는 부분에 대해서 살펴 본다.
 

CMU SEI Three Views

[5]에서는CMU의 SEI에 이야기 하는 Software Architecture의 3가지 View에 대해서 설명한다. 

첫 번째는 Module View이다. Module은 소프트웨어의 구현단위이다. 그렇기 때문에, Module View는 소스 코드 작성의 청사진(Blueprint)으로 사용될 수 있다. 그리고, Module은  소스코드나디렉터리같은 물리적구조와 대응된다.

 

 

 

두 번째는 Component-and-Connector (C&C) View이다. 이는 런타임(Runtime)에 나타나는 요소들(Component)로 구성된다. 실재로는 선(Connector)과 도형(Component) 위주의 다이어그램으로 표현된다. 즉, 실행시간에 나타나는 시스템의 전체 윤곽을 보여준다. 여기서, Component는 프로세스, 객체, 클라이언트, 서버, 데이터저장공간을 나타내고, Connector는 통신연결, 통신규약, 정보흐름, 공유저장소를 나타내는데, 2개 이상의 대상을 연결할 수도 있다.

 

일반적으로 C&C View는 실행 시간의 수행 Component이고 Module View에서는 구현 단위 이다. 아래 그림은 [5]에 있는 예이다. 여기서 볼 수 있 듯이, Module View는 구현 입장에 있는 Element들과 이와 관련된 구조를 보여 준다. 이에 대한 실재 실행이 된다면, 왼쪽과 같은 모습을 가질 수 있게 되는 것이다.

 
 
 

 

세 번째 View는 Allocation View이다. 이는 Software Architecture와 환경을 매핑시키는 역할을 한다. 우선 Deployment Style와 Work Assignment Style을 살펴 보자

 

Deployment Style은 Software Element가 어떤 물리적 장치에 탑재되는지 보여 준다. 시스템 동작 시, Deployment 내용이 변경 될 수 있으므로 할당은 동적일 수 있다.

 
Work Assignment Style은 Module View의 내용 중 구현 책임이 있는 개인이나 그룹에 할당하는 것이다. 즉, 구조와 작업하는 개발 그룹간의 관계를 보여 주는 모습이라고 할 수 있다.
 

RUP Views: 4+1 Views

아래 4+1 View[6]는 Rational에서 일하던 Philippe Kruchten에 의해서 제안되었다. Scenario(Use Case)를 기반으로 4개의 View가 있다.
 
 

 

 
  • Development View : Development View는 프로그래머 관점에서 시스템을 보여 주며 소프트웨어 관리와 관련됩니다. 이 뷰는 Implementation View라고도합니다. UML Component Diagram을 사용하여 시스템 구성 요소를 설명합니다. Development View를 표현하는 데 사용되는 UML Diagram에는 Package Diagram이 포함됩니다.
  • Logical View : Logical View는 시스템이 최종 사용자에게 제공하는 기능과 관련됩니다. Logical View을 나타내는 데 사용되는 UML Diagram은 Class Diagram 및 State Diagram을 포함한다.
  • Physical View: Physical View는 시스템 엔지니어의 관점에서 시스템을 묘사합니다. 이는 물리적 레이어의 소프트웨어 구성 요소와 이러한 구성 요소 간의 물리적 연결의 토폴로지와 관련이 있습니다. 이 View는 Deployment View라고도 합니다. Physical View를 나타내는 데 사용되는 UML Diagram에는 Deployment Diagram이 포함됩니다. 
  • Process View : Process View는 시스템의 동적 측면을 다루고, 시스템 프로세스와 이들이 통신하는 방법을 설명하고, 시스템의 런타임 동작에 초점을 맞 춥니다. Process View는 Concurrency, Distribution, Integrators, Performance및 Scalability 등을 처리합니다. Process View를 나타내는 UML Diagram에는 Activity Diagram이 포함됩니다.
  • Scenario: 아키텍처에 대한 설명은 작은 Use Case의 집합 또는 Scenario를 사용하여 설명됩니다.이 시나리오는 다섯 번째 View가 됩니다. Scenario는 Object간 및 Process 간 상호 작용을 설명합니다. 이들은 아키텍처 요소를 식별하고 아키텍처 설계를 설명하고 검증하는 데 사용됩니다. 또한 아키텍처 프로토 타입 테스트의 출발점 역할을합니다. 이 View는 Use Case View라고도 합니다.
 
  • Scenarios: The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.
 

결국은 어떤 View를 선택해야 할까?

SEI와 RUP의 View에서는아래 내용들이 유사하게 보여 진다.
 
Allocation View-Work Assignment Style Development View
Module View  Logical View
C&C View Process View 
Allocation View-Deployment Style  Physical View(Deployment View) 

 

다른 View들도 있지만, 결국 이 View들이 기본적인 View라고 볼 수 있다. 

Architectural Decisions

[2]의 Chapter 4.3을 보면 아래와 같이 7가지 Design Decision을 설명하고 있다. 물론 이것 말고도 다른 것도 있을 수 있지만, 이를 통해서 결국 Architecture를 설명할 수 있다는 입장에서 이해하면 된다.
 
  1. Allocation of responsibilities
  2. Coordination model
  3. Data model
  4. Management of resources
  5. Mapping among architectural elements
  6. Binding time decisions
  7. Choice of technology
 

책임 할당 (Allocation of responsibilities)

  • 이 Architectural Decision은 중요한 책임(Responsibility)를 구분하는 것이다. 이 책임(Responsibility)에는 Basic System Function, Architectural Infrastructure, 품질 속성(Quality Attribute)에 대한 충족을 포함한다.
  • 이 Responsibility를 결정하는 것은 (Module, Component 혹은 Connector)라고 불리는 Non-runtime/Runtime Element에 할당하는 것을 의미한다.
 

모델 코디네이션 (Coordination model)

  • 반드시 Coordinate해야 하거나 Coordinate하면 안되는 시스템의 Element를 구분해내야 한다. 
  • Coordination의 속성(Properties)를 결정해야 한다. 이에는 시간관련 사항(Timeliness), 흐름(Currency), 완료성(Completeness), 정확성(Correctness) 그리고 일관성(Consistency)가 포함된다.
  • 이 속성들을 실현하는 통신 메커니즘(Communication Mechanism)을 선택해야 한다.
 

데이터 모델 (Data model)

  • 주요 데이터 추상화(Major Data Abstraction)과 관련된 동작(Operation)과 속성(Properties)을 선택해야 한다.
  • 데이터의 일관된 해석을 위해 필요한 Metadata를 만들어야 한다(Compile).
  • 데이터를 오거나이징(Organizing)해야 한다.
 

자원 관리 (Management of resources)

  • 관리해야 할 자원(Resource)를 구분하고 각각의 제약(Limit)을 결정해야 한다.
  • 어떤 System Element(s)가 각 자원(Resource)를 관리할지 결정한다.
  • 어떻게 자원이 공유되고 충돌(Contention)이 있을 때 어떠한 중재 정책(Arbitration Strategy)을 채용할지 결정한다.
  • 다른 자원들의 포화되는 경우의 영향을 결정한다.
 

Architectural Element 매핑 (Mapping among architectural elements)

  • Module과 Runtime Element를 서로 매핑합니다. 즉, 각 Module에서 생성된 Runtime Element입니다. 즉, Module은 각각의 Runtime Element에 대한 코드를 포함하는 것이라 할 수 있습니다.
  • Runtime Element를 Processor(실재 실행되는 컴퓨팅 리소스)에 할당합니다.
  • Data Model의 항목을 데이터 저장소(Data Store)에 할당합니다.
  • Module과 Runtime Element를 전달 단위(Units of delivery)로 매핑합니다.
 

바인딩 시간 결정 (Binding time decisions)

  • 책임(Responsibility) 할당을 위해 매개 변수화 된 makefile을 통해 모듈(Module)을 빌드 타임으로 선택합니다.
  • 프로토콜의 런타임 협상(Negotiation)의 설계를 위해 코디네이션 모델을 선택합니다.
  • 리소스 관리를 위해 런타임에 플러그인 된 새로운 주변 장치를 수용하도록 시스템을 설계 한 다음 시스템이 이를 인식하고 올바른 드라이버를 자동으로 다운로드 및 설치합니다.
  • 기술 선택을 위해 스마트 폰용 앱 스토어를 구축하여 앱을 구매하는 고객의 전화에 적합한 앱 버전을 자동으로 다운로드합니다.
 

기술 선정 (Choice of technology)

  • 다른 카테고리의 Architectural Decision을 실현하기 위해 사용할 수있는 기술을 결정합니다.
  • 이 기술 선택을 지원하는 데 사용할 수있는 도구 (IDE, 시뮬레이터, 테스트 도구 등)가 개발 진행에 적합한지 판단합니다.
  • 기술의 외부 지원의 정도 (예 : 강좌, 자습서, 사례 및 위기 상황에서 전문성을 제공 할 수있는 계약자의 가용성)뿐만 내부의 친밀도를 판별합니다. 또한, 이의 도입을 진행하기에 적합한 지를 결정합니다.
  • 요구되는 조정 모델 또는 제한된 자원 관리 기회와 같은 기술 선택의 부작용 판별합니다.
  • 새로운 기술이 기존 기술 스택과 호환되는지 여부를 판별합니다.
 

마치며...

여기서는 Software Architecture의 정의를 살펴 보고, 결국 Architecture가 View의 집합 혹은 Architectural Decision의 집합으로 설명될 수 있는 것을 알 수 있다. 특히 View의 경우는4개의 View로 설명이 가능하고, Architectural Decision은 7가지의 종류로 나뉘어 지는 것을 알 수 있었다. 그렇다면, 어떻게 Architectural Decision들이 이루어 지고, 최종적으로 Architecture가 결정되는지 살펴 볼 필요가 있다. 그리고, 최종 결정된 Architecture를 4가지 View로 그려보는 것이 필요하다. 그리고, 결정된 Architecture를 어떻게 문서로 전달할지도 알아 볼 필요가 있다.

References

[2] Len Bass, et. al., "Software Architecture in Practice, Third Edition," Addison Wisely, 2012
[3] SEI Book Series in Software Engineering, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=465870
[4] Martin Fowler, "Who Needs Architect," IEEE Software Volume: 20 , Issue: 5 , Sept.-Oct. 2003
[5] Paul Clements et. al., "Documenting Software Architectures - Views and Beyond 2nd Ed," Addison-Wesley 2011
[6] Philippe Kruchten, "Architectural Blueprints - The “4+1” View Model of Software Architecture," IEEE Software 12 (6), 1995, November
 

 

저작자표시 비영리 변경금지

'Software Architecture' 카테고리의 다른 글

Software Architecture: ATAM, Architecture Evaluation  (0) 2020.01.22
Software Architecture를 위한 Quality Attribute  (0) 2018.10.09
Software Architecture: 요구 사항은 어떻게 추출하는가?  (0) 2018.10.09
Software Architecture: 어떻게 설계 할 것인가?  (0) 2018.09.30
소프트웨어 아키텍처 공부를 시작하며...  (0) 2018.09.03

+ Recent posts

티스토리툴바