Software Analysis and Design - Software Architecture Design

1. Software Architecture

소프트웨어 아키텍쳐란 무엇일까? ISO/IEC/IEEE와 같은 표준 기구가 정의한 내용을 살펴보자면, 소프트웨어 아키텍쳐란 요소, 관계, 원칙, 디자인으로 구현된 환경에서의 시스템의 근본적인 개념 혹은 속성을 뜻한다. 

<개념 추가>

위에 서술한 소프트웨어 아키텍처의 개념에서 구성 요소를 뽑아보면 다음과 같다.

 

1. Element (Component)

2. Relationship (Connector, Inter-component relationship)

3. Principle (아키텍쳐에서 component와 relationship을 바탕으로 어떻게 구성되는지에 대한 Constraints)

 

각 요소에 대해서 어떤것이 있고, 어떻게 세분화 되며, 어떻게 뽑아낼 수 있을지에 대해서 생각해보자.

 

2. Software Architecture의 구성 요소

2-1. Component

component는 Functional component, Data Component, Control Component, Hardware Adapter 등이 존재한다. 아래의 구조는 Functional component의 예시이다.

 

2-2. Connector

Connector에는 Inter-component relationship과 Interaction path로 나타낼 수 있다. 아래는 Inter-component relationship에 대한 예시이다.

 

2-3. Principle

Target system의 속성을 지배하는 원칙이다.

 

 

2-4. International standard defining software architecture

다음 그림은 ISO/IEC/IEEE가 제안한 Architecture Description에 대한 conceptual model이다.

Conceptual model of an architecture description proposed by the ISO/IEC/IEEE 42010:2011 standard.&nbsp;

AD : Design Document (Document of software architecture)

Stakeholder : 주체 (Client, laywer, 등...)

Concern : Gether Stakeholder's contern

Architecture View(Viewpoint)

 

2-5. Software Architecture과 SRS의 관계

다시한번 구현하여야 할 소프트웨어의 요구조건이 담긴 명세서인 SRS(Software Requirement Specification)에 대해서 상기해보자. SRS는 만족해야할 Functional Requirement와 Non-Functional Requirment(NFR)로 나눌 수 있었다.  Functional Requirement의 경우, UML과 같이 OOAD(Object Oriented Analysis Design)으로 나타내어 디자인 할 수 있었지만, NFR의 경우 지금까지 배운 것으로는 디자인 할 수 없었다. NFR을 위한 디자인을 가능하게 하는 것이 SW Architecture이다. SW Architectue는 Quiality에 관여하며, NFR을 효과적으로 구현해준다.

이제부터 어떻게 SW Architecture를 통해 NFR을 만족할 지 알아보자.

 

 

3. Software Architecture Description(AD)

Software Architecture Description란 Target system의 Software Architecture Design에 대한 명세(specification)이다. 이때 Software architecture descriptor가 어떤 것을 명시하여 Architecture를 표현하는지 살펴보자면 다음과 같다.

 

1) 전체 시스템을 위한 structural design(Skeleton architecture)

2) System structure을 완성하기 위한 Detailed design(Design for views)

3) Non-Functional Requirements를 만족하기 위한 Effective Tactic(Design for NFRs)

 

이를 그림으로 표현하면, 

이제 AD가 명시하는 것들이 정확히 무엇이고 어떻게 도출할 수 있을지에 대해서 자세히 살펴보자.

 

3-1. Software Architecture Design의 요소

3-1-1. Skeleton Arcitechture

system의 중심(core)이자 / 변하지 않는(stable) structure로, Architecture style로 디자인할 수 있다.

 

3-1-2. Design for views

Software Architecture를 특정 관점에서 본 Representation으로, 다음과 같이 세분화 되어 나뉠 수 있다. 

 

- design for context view

- design for functional view

- design for information view

- design for behavior view

- design for deployment view

- design for development view

- design for operation view

 

각 view에 대한 design의 guidline으로, Class diagram, Usecase diagram등을 view에 올바른 자료를 활용하여 정의할 수 있다. 

 

3-1-3. Design for Non-Functional Requirements (NFRs)

Arcitecture Tactics으로, 같은 기능을 제공하더라도(마이크->음성명령), 어떤 전략을 이용하는지에 따라 효과는 다르므로, 이에 대한 정의가 중요하다 예를 들어 앞선 경우에는 ML을 이용하면 단순 성조 인식보다는 효과적으로 기능을 제공할 수 있을것이다.

 

3-2. BOK for Software Architecture

이것들에 대해서 지식체계를 구축하면 다음과 같이 표현할 수 있다.

각 단어들이 어떤것을 의미하는지는 차차 배우도록 하자.

 

3-3. Architecture Design Methodology(방법론)

방법론에는 Process나 How-to Instructions등이 포함된다. 이 방법론에 의거하여 어떻게 Architecture Descriptor의 3요소(Skeleton architecture, Design for view, Design for NFR)을 디자인 할 지 알아보자

 

 

4. 예시

4-1. Skeleton Archtiecture의 디자인을 위한 Arcitecture Stlye : MVC

Architecutre style이란, Software architecture에서 일반적으로 발생하는 structural problem에 대한 general하고 reusable한 구조적 레이아웃과 속성에 대한 description이다. 예시인 MVC 스타일의 경우, 시스템이 3개의 레이어(Model, View, Controller)로 명확히 구분될 때 / system이 높은 수준의 user-interactive을 요구할 때 / business process가 동일 data representation에 대해 독립적으로 형성되어야 할 때 / database가 business process별로 독립적으로 디자인 되어야 할 때 사용되는 Architecture style이다. 아래는 그 활용에 대한 예시이다.

 

4-1-1. Structure

이를 3개의 layer(Model, View, Controller)로 표현한다.

Model의 경우, data model을 표현하고, query에 반응하고, 데이터 변화에 의한 dependent component notification등 persistent data를 표현하는 레이어이다.

 

View의 경우, 유저에게 정보를 출력하고, 유저의 입력을 controller에게 전달하고, notification을 받았을 때 model로 부터 데이터를 불러오는 등, View를 표현하는 레이어이다.

 

Controller의 경우, view로 부터 전달받은 input을 기반으로 process하고, 어플리케이션의 workflow를 정의하며, event를 번역하고, model로 request를 전달하는 등 동작을 표현하는 레이어이다.

 

4-1-2. Connector types

이제 각 layer를 정의하였으니, 어떻게 연결되는지 알아보자. 그 예시로는 Method invocation + Response연결 혹은 Event + Reply연결이 있다

 

4-1-3. Contraints

어떠한 tactic 혹은 constraint을 부여하는지 알아보자. 우선 view는 user input을 직접 처리하지 않으며 controller에게 전달한다. 그리고 오직 controller만이 model내의 data에 대한 업데이트를 할 수 있으며, model은 view를 바꾸지 않고, 그저 데이터의 변화를 알릴 뿐이다. view는 model과 연관된 부분을 query하고, 업데이트 한다.

 

4-1-4. Behavior

이는 각 레이어간의 행동들을 명시한 것이다. User는 view layer와 상호작용하며, view layer는 control layer의 service를 invoke한다. control layer는 persistent data를 조작하기 위해 model layer를 invoke하며, model layer는 실제 physical database를 관리한다.

 

이처럼 Architecture style중 유명한 MVC style을 이용하여 skeleton architecture를 표현할 수 있었다.

 

4-2. Design for view를 위한 Arcitecture View

architecture view는 software architecture의 특정 관점에 대한 representation이다. 아래는 Architecture view의 예이다. 

Architecture description은 다양한 view들로 조직되어 이루어진다. 위에 별표친 3개의 view는 implementable하므로 중요하다. 이에 대해서 간단히 알아보자. (요점은 software system에는 다양한 view가 존재하며 각 view가 서로 분리되고 표현된다는 것!!)

 

 

4-2-1. Contex view

Relationship, dependency, system과 enviroment사이의 interaction을 표현하는 관점(view)이다. shakeholder들에게 자신의 responsibility를 이해시키는데 도움을 준다

 

4-2-2. Functional view

System functional element와 그들의 responsibility, interface, primiary interaction을 표현하는 관점(view)이다. 이는 다른 view의 형태를 도출해주기도 한다.

 

4-2-3. Information(Persistent Data) view

architecture가 데이터를 어떻게 저장할지, 조작할지, 관리할지, 분배할지를 표현한 관점(view)이다. 이는 static data structure(즉, persistent data)에 대한 high-level veiw이다. (content, structure, ownership 등)

 

4-2-4. Runtime Behavior view

Runtime structure를 표현하는 관점(view)이다. functional elemnt와 computation unit을 연결하고, concurrent하게 실행될 부분을 명시하고, 어떻게 협업하며, 컨트롤 될지를 명시한다.(IPC, Process. Thread structure 등)

 

4-2-5. Development view

Architecture가 software development process를 어떻게 서포트할지에 대한 관점(view)

 

4-2-6. Deployment view

deploy될 시스템의 Enviroment에 대한 관점(view)

 

4-2-7. Operational view

어떻게 시스템이 작동하고, 인증되며, 지원할지에 대한 관점(view)

 

 

5. Architectural viewpoint

Architecture Design에는 Architectural viewpoint라는 용어가 있는데, 이는 하나의 view를 구성하기 위한 pattern, templates, convetions과 같은 view에 대한 guidline을 의미한다. 이는 conceptual framework으로, Architectural knowledg를 reusable하게 구성하기 위해 존재한다. 각 view당 하나의 viewpoint를 갖는다. information viewpoint를 예시로 들면 데이터를 저장하기 위한 Procedure(혹은 guidline)이 정의된 패턴의 집합이다. 따라서 Architech는 좋은 방법론(viewpoint)를 제공해야 한다