본장에서는아키텍처설계단계에대한전반적인내용을다룬다. 아키텍처설계단계에서해야할활동들과산출물들에대해서소개하고, 소프트웨어아키텍처에대한기초이론과개념그리고어떻게시스템의아키텍처를묘사하고그것을문서화하는지를상세하게설명한다. 1
본장에서는다음을달성할수있도록하는것에목적을둔다. 1. 소프트웨어아키텍처에관한기본개념들을이해한다. 2. 소프트웨어아키텍처를표현하기위한 UML 의요소및다이어그램들을살펴보고이것을직접활용할수있다. 3. 자신의시스템에적합한이키텍처뷰 (Architecture View) 들을식별해내고그것들을효과적으로표현해낼수있다. 4. 정의된아키텍처를효과적으로소프트웨어아키텍처문서 (Software Architecture Document) 로작성할수있다. 2
본섹션에서는아키텍처설계단계에전반적인내용을소개한다. 3
아키텍처설계 (Architectural Design) 단계에서다음과같은작업을수행한다. 1. 주어진요구사항들을바탕으로소프트웨어시스템전반에영향을주게될중요한설계결정을내린다. 2. 소프트웨어시스템을다양한관점에서바라본소프트웨어아키텍처를수립하여상세설계의토대를마련한다. 3. 소프트웨어아키텍처를 SAD(Software Architecture Document) 문서로작성한다. 4
아키텍처설계단계에서는아키텍트 (Architect) 에의해총 1 개의활동 (Activity) 이수행되어진다. Describing Architecture Describing Architecture 활동의목적은주어진요구사항들을바탕으로소프트웨어시스템전반에영향을미칠중요한설계결정을내리고그것을다양한관점에서바라본아키텍처모델을개발하고문서화하여향후상세설계의기초를제공하는것이다. 5
본섹션에서는소프트웨어아키텍처의기초이론과개념들을설명한다. 6
7
프로그램혹은컴퓨팅시스템의소프트웨어아키텍처 (Software Architecture) 는소프트웨어컴포넌트 (Software Component) 와이들이외부적으로드러내는프로퍼티 (Externally visible properties), 그리고컴포넌트들의관계 (Relationships) 를포함하는시스템구조 (Structure) 이다. 소프트웨어아키텍처는시스템의조직 (organization) 에관한중대한결정을의미하므로핵심적인요구사항과품질에관한속성들을반영하게되고구체적인시스템설계에대한기준이된다. 8
소프트웨어아키텍처 (Software Architecture) 를나타내는최소의단위는컴포넌트 (Component) 와그것들을연결하는연결자 (Connector) 들이다. 또한시스템의중요한속성들을반영하고, 아키텍처상중요한 (architecturally significant) 요소들만을반영한다. 시스템에대한전체설계는아키텍처가아니며그러한설계의중요한단면 (slice) 이아키텍처를구성하게된다. 9
소프트웨어아키텍처에영향을주는요인 (Factor) 들은매우다양하다. 이해관계자 (Stakeholders) : 시스템에는많은이해관계자들이있다. 사용자뿐만아니라개발자, 아키텍트, 유지보수담당자, 마케팅매니저등이있는데이들은각각서로다른관점에서시스템을바라보고요구사항들도서로다르다. 이들모두의요구를적절히조절하면서충족시키는아키텍처를정의하여야한다. 조직적요인 (Organizational Factors) : 조직에서는시스템개발에대한비용과시장진출시기등을고려하지않을수없다. 더나아가서프로젝트의위험도그리고직원들의능력등을고려한아키텍처를정의하여야한다. 기술적요인 (Technical Factors) : 현재의기술적트렌드를따라너무뒤쳐진기술에의존해서는안되고, 기술적어려움그리고가능성등을고려한아키텍처를정의해야한다. 아키텍트의배경 (Architect s Background) : 결국많은요인들을반영한소프트웨어아키텍처를정의하는것은아키텍트 (Architect) 이다. 아키텍트의경험, 기술적능력, 관리적능력그리고리더십등은아키텍처에엄청난영향을미친다. 10
소프트웨어아키텍처는다음의 3 가지이유에서매우중요하다. 커뮤니케이션의수단 (Communication Vehicle) : 소프트웨어아키텍처는시스템에대한높은수준의추상화 (High-level abstraction) 를표현한다. 따라서, 모두는아니더라도대부분의시스템이해관계자 (stakeholder) 들이이것을기준으로상호간의이해 (understanding) 와합의 (consensus) 를이루어내고또한커뮤니케이션을하기위한기초가된다. 이른설계결정 (Early Design Decision) : 소프트웨어아키텍처는시스템에대한가장이른설계결정의표명이고이러한결정들은이후소프트웨어개발과배치그리고유지보수등으로중대한영향을주게된다. 아키텍처의재사용 (Architectural Reuse) : 소프트웨어아키텍처는시스템이어떻게구조화되고컴포넌트어떻게함께작업을처리하는지에대한비교적작고, 지적인모델이므로다른시스템으로전이되고재사용될수있다. 유사한요구사항을지닌시스템에큰규모의재사용을제공하게된다. 11
어떤시스템의아키텍처가정의되었다면그것은다른유사한요구들을반영해야하는시스템에서도재사용될가능성이높다. 이렇듯여러시스템에서반복적으로발견되고시스템의중요한결정들을반영한아키텍처를재사용가능하도록일반화한것을아키텍처패턴 (Architectural Pattern) 이라고한다. 12
13
파이프와필터 (Pipes and filters) 아키텍처패턴 시스템에서다루어지는정보 / 데이터들을파이프 (Pipe) 라는컴포넌트에의해전달되고필터 (Filter) 에의해처리되는순차적처리프로세스를묘사하는아키텍처패턴이다. 예로는유닉스의파이프및컴파일러시스템등이이러한패턴에적용된다. 파이프와필터패턴은각각의파이프및필터들이독립적인컴포넌트로재사용이가능하고순차적으로처리하지만각각의필터들이병렬적으로데이터를처리할수있으므로성능에좋은효과를줄수있다. 14
계층 (Layer) 아키텍처패턴 시스템을수평적인몇개의계층으로분할하여컴포넌트들이그중한가의계층에속하게하고상위계층의컴포넌트들만하위계층의컴포넌트에접근할수있도록한정하는방식의패턴이다. 예로는 OSI 7 Layer, GUI 프레임워크나기타멀티티어 (Multi-tier) 시스템이이패턴에적용된다. 계층아키텍처패턴을사용하게되면하위계층들을적절하게추상화하면다른시스템에서그러한계층들을재사용할수있게되고, 또한이식성이높아지게된다. 또한유지보수하기에도수월하다. 15
칠판 (Blackboard) 아키텍처패턴 시스템이중앙에칠판과같은데이터를공동으로저장할수있는컴포넌트들두고주위의다른여러컴포넌트들이공동으로데이터에접근하고변화및조작하는형태의패턴이다. 공동작업을지원하는컴퓨터시스템의아키텍처에적용될수있다. 중앙에공용데이터저장공간이존재하기때문에데이터를다루는행위를하는컴포넌트들을얼마든지추가할수있으므로시스템의규모를확장하는데유리하고다른시스템과통합할때에도공용데이터공간에접근할수있으므로편리하다. 다만, 보안성이취약한단점이있다. 16
어떤사물도한쪽면만을봐서는전체적인형태를알수없다. 건축물의경우도측면도, 정면도및전기배선도등과같은여러장의도면이있어야건축물을완전하게지을수있다. 소프트웨어시스템의아키텍처도하나의관점으로만봐서는시스템의전체적인구성을표현하기어렵기때문에다양한관점을표현한여러개의아키텍처뷰 (Architectural View) 가전체적인시스템의아키텍처를구성한다. 17
소프트웨어시스템의아키텍처는여러개의아키텍처뷰 (Architectural View) 들로구성된다. 각각의아키텍처뷰는특정관점 (Perspective) 에서의시스템에대한간략한기술이며특정이해관계자 (Stakeholder) 의의도를반영한다. 단, 아키텍처뷰는모든설계를포함하는것이아니라아키텍처상중요한요소들과내용들만을포함하여야한다. 18
19
Philippe Kruchten 에의해 1995 년에발표된 Architectural Blueprints The 4+1 View Model of Software Architecture 논문에서제시한 4+1 View Model of Architecture 는이후대중적으로받아들여지고있다. 4+1 뷰모델은논리적뷰 (Logical View), 구현뷰 (Implementation View), 프로세스뷰 (Process View) 와배치뷰 (Deployment View) 로구성되고추가로유스케이스뷰 (Use Case View) 를추가로포함한다. 각각의뷰들은서로다른이해관계자의관점과서로다른고려사항들을반영하게된다. 20
21
22
23
24
25
26
27
활동의목적 (Purposes) Describing Architecture 활동의목적은시스템에요구되어진다양한요구사항에부응하고시스템의중요한설계결정을반영하여상세한설계의기초토대가되는소프트웨어아키텍처를정의하는것이다. 활동의입력 (Input) Analysis Model : 분석수준의클래스들로구성된 UML 모델이다. Use Case Model : 시스템의기능적요구사항을유스케이스 (Use Case) 로표현하는 UML 모델이다. Software Requirements Specification : 시스템에요구되어지는모든요구사항들을명세화한문서이다. 활동에의한산출물 (Outputs) Design Model : 시스템의상세한설계를표현하는클래스등의요소들로구성된 UML 모델이다. ( 아키텍처상중요한설계요소들만을포함한다.) Implementation Model : 시스템을구성하는소프트웨어컴포넌트들을표현한 UML 모델이다. ( 아키텍처상중요한컴포넌트들만을포함한다.) Deployment Model : 시스템을구성하는컴퓨터, 하드웨어등의전산자원들로구성된 UML 모델이다. ( 아키텍처상중요한노드들만을포함한다.) Software Architecture Document : 소프트웨어아키텍처를다양한관점에서표현한문서이다. 28
29
컴포넌트다이어그램은소프트웨어시스템을구성하는소프트웨어컴포넌트, 실행파일, 라이브러리, 문서등과그것들간의상호의존관계를표현하는다이어그램이다. 컴포넌트다이어그램은주로다음과같은용도로사용하게된다. 시스템의정적인구현뷰 : 소프트웨어시스템을구성하는컴포넌트, 실행파일, 라이브러리, 문서등과같이컴퓨팅노드에실제로존재하는요소들을모델링하는것이다. 다르게설명하면, 소프트웨어시스템의런타임이미지 (Runtime Image) 를표현한다고할수있다. 구축하는시스템의컴포넌트 - 기반의시스템 (Component-Based System) 인경우시스템의컴포넌트아키텍처 (Component Architecture) 를표현한다. 30
배치다이어그램은소프트웨어시스템을구성하는컴퓨팅노드들과같은하드웨어와그들간의관계를표현하는다이어그램이다. 컴포넌트다이어그램은주로다음과같은용도로사용하게된다. 시스템의정적인배치뷰 : 시스템의정적인배치뷰는시스템에실행되는하드웨어의형태를표현하는것이다. 31
인터페이스 (Interface) 는클래스 (Class), 컴포넌트 (Component), 서브시스템 (Subsystem) 등의요소들이제공해야하는서비스들을명세화하기위해사용하는요소로써여러개의연산 (Operation) 들로구성된다. 연산은구현까지제공하는메소드 (Method) 과는다르다. 인터페이스는클래스와모양이동일하고이름위에 <<interface>> 라고표시한다. 또한많은경우인터페이스는작은원으로표현된다. 32
의존 (Dependency) 은두요소사이의의미적관계로서한쪽요소에변경이생기면다른쪽요소가갖는의미에영향을줄수있는관계이다. 의존은어떠한요소사이에도정의될수있으나주로, 패키지들사이의의존관계, 클래스들사이의의존관계그리고컴포넌트가제공하는인터페이스에의의존등에주로많이사용된다. 33
실체화 (Realization) 관계는명세 (specification) 요소와구현 (implementation) 요소사이의관계를의미한다. 즉, 명세에정의된내용대로구현요소가실체화해야하는것이다. 실체화관계는주로인터페이스 (Interface) 를실체화하는클래스 (Class), 컴포넌트 (Component), 서브시스템 (Subsystem) 사이에많이사용되고또한유스케이스 (Use Case) 를실체화하는협동 (Collaboration) 요소사이에도주로사용된다. 34
컴포넌트는물리적이고교체가능한시스템의한부분이며, 2 개의탭이달린사각형으로표현한다. 35
컴포넌트는주로다음과같은것들을표현한다. 소프트웨어컴포넌트 (Software Component) : ActiveX, COM, EJB,.NET Assembly 등과같은소프트웨어컴포넌트를표현 실행파일 (executable) : EXE 와같은실행파일을표현 라이브러리 (library) : LIB, DLL 와같은정적혹은동적라이브러리를표현 파일 (file) :.ini,.java,.gif 등과같은다양한파일들을표현 문서 (document) : 특정문서를표현 36
인터페이스를연산들의집합으로써컴포넌트의서비스를명세화하는데사용되고컴포넌트는하나이상의인터페이스를준수하고구현할수있다. 37
컴포넌트들사이에는의존관계 (dependency) 가존재한다. 컴포넌트가다른컴포넌트에직접적으로의존하거나다른컴포넌트가제공하는인터페이스에의존한다. 후자가더올바른형태이다. 38
컴포넌트에는여러개의요소들이상주할수있다. 특히, 컴포넌트를실제로구성하는클래스들이컴포넌트에상주하는대표적인요소이다. 39
컴포넌트는하나의타입 (type) 이다. 컴포넌트가적용되는실제인스턴스를컴포넌트인스턴스 (Component Instance) 라고한다. 컴포넌트인스턴스의이름은객체의이름을표현하는방식과동일하다. 40
노드 (Node) 는물리요소로서시스템이실행될때존재하고, 일반적으로는어느정도의메모리와처리능력을갖춘전산자원을나타내며, 그래픽으로는 3 차원의직육면체로표현한다. 41
노드들간에는연관 (Association) 관계가존재한다. 노드들을연결하는물리적인연결을표현하고그종류를더명확하게표현하기위해서스테레오타입 (stereotype) 을사용할수있다. 42
노드에는컴포넌트들이배치된다. 배치되었다는것은실제컴포넌트가해당컴퓨터에설치되어동작함을의미한다. 43
노드는하나의타입 (type) 이다. 노드가적용되는실제인스턴스를노드인스턴스 (Node Instance) 라고한다. 노드인스턴스의이름은객체의이름을표현하는방식과동일하다. 44
프로세스 (Process) 는중량급이고운영체제에서다루어지며독립된주소공간을할당받아실행되는반면, 쓰레드 (Thread) 는경량급으로써프로세스내에포함되어져주소공간을공유하면서실행된다. 45
46
47
48
49
50
소프트웨어아키텍처문서 (SAD Software Architecture Document) 는소프트웨어시스템의아키텍처를정의하여중요한설계결정들을반영하는문서이다. IEEE Std 1471 에서 SAD 작성에대한권고사항을정의하고있으므로참고하는것이좋다. 51
SAD 문서에는여러가지의내용들을담을수있으나일반적으로다음의핵심적인내용들을포함한다. Architectural Representation : 소프트웨어시스템의아키텍처가어떻게표현되는지를기술한다. ( 구성되는아키텍처의뷰 ) Architectural Goals and Constraints : 소프트웨어아키텍처가달성해야할목표및기타제약사항들을기술한다. Architectural Views : 각각의아키텍처뷰에대한다이어그램및설명을기술한다. (4+1 뷰모델을사용하는경우 Use Case View, Logical View, Implementation View, Process View 그리고 Deployment View 를각각기술한다.) Rationale : 아키텍처가시스템에주어진중요한품질속성들을어떻게만족하게되는지를합리화한다. 52
53
54