Architectural Design - Hanyang · 2018-05-20 · Analyzing Architectural Design • Architecture Trade-off Analysis Method (ATAM) by SEI 1. 시나리오 수집 2. 요구사항, 제약

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Architectural Design

CSE4006 Software Engineering


Software Architecture

!2

• 시스템에 대한 기본적인 기술 제공 • 시스템을 구성하는 컴포넌트• 시스템의 데이터와 제어 흐름을 포함하는 컴포넌트 사이의 중요 연관/협업 (collaboration)

• 설계 및 품질 (성능)에 대한 분석, 의사 결정, 위험 평가를 위한 안전한 기반 (sound basis)을 제공

• 조직에 실질적 가치 (tangible value)를 창출하는 자산 (asset)


Purpose of Architecture

• 아키텍처는 동작하는 소프트웨어가 아님 • 아키텍처는 소프트웨어 엔지니어가 다음을 수행 할 수 있게 해주는 표현 :

1. 명시된 요구 사항을 충족시키는 데있어 설계의 효과를 분석

2. 상대적으로 설계 변경이 아직 쉬운 단계에서 아키텍처 대안을 고려

3. 소프트웨어 생산과 관련된 위험 요인 감소

!3


Importance of Architecture

• 소프트웨어 아키텍처의 표현은 개발에 관련있는 모든 이해관계자 사이의 의사소통을 가능하게 함

• 아키텍처는 초기 의사 결정을 강조 • 초기 의사 결정은 이후 뒤 따르는 소프트웨어 공학 작업과 시스템의 궁극적 성공에 중대한 영향을 줌

• 아키텍처는 시스템이 어떻게 구조화되고 그 컴포넌트가 어떻게 함께 작업하게 되는지에 대해 파악/이해할 수 있는 모델 제공

!4


Architectural Description (AD)“a collection of products to document and architecture”

- IEEE Standard

• 다양한 이해 관계자 시스템 관점을 반영한 작업 산출물 집합 • 뷰 (view)는 관련 이해 관계자의 우려/관심 (concern)의 관점에서 전체 시스템을 표현한 것

• 관점 (viewpoint)은 뷰 (view)를 구성 및 사용하기 위한 규칙의 명세

• Recommended Practice for Architectural Description of Software-

Intensive System [IEEE-Std-1471-2000] • 소프트웨어 아키텍처 설계를 위한 개념적 프레임워크와 어휘 확립 • AD 표현을 위한 자세한 지침 제공 • 안전한 아키텍처 설계 실무를 장려

!5


Architectural Description Language (ADL)

• 소프트웨어 아키텍처 설명을 위한 의미 및 구문을 제공 • 설계자에게 아래 능력 제공 :

• 아키텍처 컴포넌트 분해 • 개별 컴포넌트를 더 큰 아케텍처 블록으로 구성 • 컴포넌트 사이의 인터페이스 (연결/소통 메커니즘) 정의

• 소프트웨어 아키텍처 표현 언어의 예 : • ABACUS (UTS에서 개발) • ACME (CMU에서 개발) • AADL (SAE에서 개발) • C2 (UCI에서 개발) • Darwin (Imperial College London에서 개발) • Rapide (Stanford 대학교에서 개발) • Wright (CMU에서 개발)

!6


ADL Example (in ACME)System simple cs= {

Component client = Port send-request Component server = Port receive-request Connector rpc = Roles caller, callee Attachments : client.send-request to rpc.caller; server.receive-request to rpc.callee

}

simple_cs

!7


Architectural Genre

• 장르 (Genre) : 전체 소프트웨어 도메인 내의 특정 카테고리 e.g. 인공 지능, 통신, 장치, 금융, 게임, 산업, 법률, 의료, 군사, 교통, …

• 각 카테고리 (장르) 내, 많은 하위 카테고리 (일반적 스타일)도 존재 e.g. 건물 장르 내에 다음과 같은 일반적 스타일 존재 : 주택, 콘도, 아파트, 사무실, 창고, …

• 각 일반적 스타일 내에 더 구체적인 스타일 적용 가능 - 각 스타일은 예측가능한 패턴의 집합을 사용하여 설명할 수 있는 구조

!8


Architectural Style

• 각 스타일은 아래를 포함하는 시스템 카테고리를 기술

1. 컴포넌트 (components) : 시스템에 필요한 기능을 수행하는 데이터베이스 혹은 계산 모듈

2. 연결자 (connectors) : 컴포넌트들 사이의 의사소통, 조합, 협력을 가능하게 함

3. 제약사항 (constraints) : 시스템을 구성하기 위해 컴포넌트들이 어떻게 통합되는지 정의

4. 의미적 모델 (semantic models) : 설계자가 시스템 구성요소의 알려진 특성을 분석하여 시스템의 전반적 특성을 이해할 수 있게 함

!9


Architectural Style• Data centered architectures :

• 데이터 저장소 (파일 또는 데이터베이스)는 중앙에 있으며 데이터를 수정하는 다른 컴포넌트 (클라이언트)가 자주 접근

• Data flow architectures : • 입력 데이터는 일련의 계산 또는 조작 컴포넌트에 의해 출력 데이터로 변환

• Layered architectures : • 여러 계층이 정의 되며, 각 계층은 기계 명령어에 점진적으로 가까워지는 연산을 수행

• Call and return architectures : • 프로그램 구조는 함수를 제어 계층으로 분해 - 주 프로그램이 여러 서브 프로그램 호출

• Object-oriented architectures : • 시스템의 컴포넌트는 데이터 및 연산을 캡슐화하고 컴포넌트 사이의 의사 소통은 메세지 전달을 통함

!10


Data-Centered Architecture

!11


Data-Centered Architecture

• 데이터 자장소 (repository) • 수동적 (passive)

- 클라이언트 소프트웨어는 데이터 변경이나 다른 클라이언트의 동작과 상관 없이 데이터에 접근

• blackboard scheme - 클라이언트의 관심 데이터가 변경되면 클라이언트 소프트웨어에 알림

• 높은 통합성 (integrability) • 클라이언트 컴포넌트가 독립적으로 작동

!12


Data Flow Architecture

Pipe-filter pattern

Batch sequential

!13


Pipes and Filters : Pattern

• 연속적 입력 데이터에 대한 일련의 변환으로 시스템을 표현하는 data-flow architectural 패턴

• pipes • stateless이며, 여러 filter 사이의 데이터 스트림을 이동시키기 위한 통로 역할

• filters • 스트림 수정자 (stream modifier) - 들어오는 데이터를 특정 방식으로 처리하고 수정 된 데이터 스트림을 pipe을 통해 다른 필터로 보냄

!14


Pipes and Filters : Features

• 점진적 (incremental) 전달 : 작업 수행된 데이터 출력

• 동시 (비순차) 처리 (concurrent (non-sequential) processing) : • 데이터는 pipeline을 통해서 스트림으로 흘러가며 여러 filter가 동시에 데이터 스트림의 서로 다른 부분에서 작업 가능

• filter는 독립적으로 서로 모른채 작업 - plug & play

• 유지보수는 다시 loosely coupled 개별 필터로 분할

• 생산자-소비자 (producer-consumer) 메커니즘 지원에 매우 좋음

• 다중 독자 (reader) 및 작가 (writer) 가능

!15


Batch Sequential Data Processing

• 독립 실행 형 (stand-alone) 프로그램은 데이터를 처리하여 출력으로 파일을 생성

• 파일은 다른 독립 실행 형 프로그램의 입력으로 사용 • 파일을 읽고, 처리하고, 다른 파일을 출력

• 프로세스는 순차적으로 (sequentially) 발생 • 정해진 순서의 각 프로세스는 완료될때까지 실행, 새로운 형태의 출력 파일을 생성, 다음 단계가 시작

!16


Pipes and Filters : Benefits• 이해하고 구현하기 상당히 간단함 • 단순하고 정의된 인터페이스로 복잡한 통합 문제를 줄임 • filter는 black-box로 대체 가능하며 plug & play가 가능하므로 생산적인 방법으로 재사용 됨

• filter는 매우 가변적 (modifiable) • filter 사이에는 결합도 (coupling)가 없으며 새로운 filter는 생성되어 기존

pipeline에 추가 될 수 있음 • filters와 pipes은 계층적일 수 있으며 클라이언트 접근을 더욱 단순화하는 메커니즘으로 구성될 수 있음

• filter는 독립 실행 형 (stand-alone)이므로 쉽게 배포되고 동시 실행 (concurrent execution)을 진행할 수 있음 (스트림이 진행 중)

• 여러 filter는 더 크고 복잡하며 매우 가변적 (modifiable)인 알고리즘 설계에 사용될 수 있음 (filter 추가 / 삭제를 통해)

!17


Pipes and Filters : Limitation

• batch processing metaphor는 본질적으로 한계를 가지지 않지만, 시스템 상호 작용에 대한 매우 동적인 (highly dynamic) 응답을 제공하지 못함• filter는 black-box로 서로 인식하지 못하므로 동적으로 지능적이게 스스로를 재정렬 할 수 없음

• 일단 pipeline이 진행되면 스트림을 휘손시키지 않고는 변경할 수 없음

• 내용에 따라 한 필터에서 다른 필터로 경로를 잡는 동적 pipeline 구성이 어려움

!18


Layered Architecture

!19


Layers

• 아키텍처 계층은 복잡한 시스템의 협력 부분 • 점진적 (incremental) 코딩 및 테스팅을 지원하여 변경의 범위 제한

• 잘 정의 된 인터페이스는 서로 다른 계층의 대체를 가능하게 함

• 서로 협력 (상호 작용)하는 계층들 사이 보호 • 계층은 세부 작업을 서로 관련 있는 책임 그룹으로 나눌 수 있는 책임 기반 (responsibility-driven) 아키텍처

!20


Layers Pattern

• 순수한 의미에서 각 계층은 바로 위 계층에 서비스를 제공하고 바로 아래 계층의 클라이언트 역할을 함

• 불순한 (impure) 구현에서는 서로 떨어진 계층 사이 의사 소통이 허락된 bridge 형태가 가능하나 휴대성, 유연성, plug & play 능력이 감소됨

• 각 계층은 정의된 인터페이스를 위 및 아래 계층에 제공 • 상위 계층은 증가된 추상화 수준 제공

!21


Example : Protocol Stacks

!22


Layered Architecture : Benefits

• Layered 패턴은 추상화 수준 증가를 지원하여 설계를 단순화 • 복잡한 문제를 일련의 관리 가능한 점진적 전략 (계층)으로 분리할 수 있음

• pipes와 filters처럼 계층이 느슨하게 결합됨 (loose coupled) • 새로운 계층이 추가되면 기존의 두 컴포넌트 (계층)만 영향을 받음으로 유지보수 향상

• 계층은 plug & play (재사용 가능) 설계 지원 • 인터페이스가 변경되지 않는 한, 한 계층을 다른 계층으로 대체하여 계층 시스템의 동작 변경이 가능

!23


Layered Architecture : Disadvantages

• 병치된 (juxtaposed) 계층의 밀착 결합 (close coupling)으로 유지보수 저하

• 각 계층은 모든 데이터 marshaling/buffering을 관리해야 함

• 낮은 runtime 효율성 • 다양한 계층의 세분성(granularity) 확립이 어려움

!24


Layered Architecture : Disadvantages

• 주 프로그램 / 서브 프로그램 아키텍처 • 원격 프로시저 호출 아키텍처

!25


An Architectural Design Method

• 고객 요구사항

!26


Architecture Design

• 소프트웨어는 context에 배치 • 디자인은 소프트웨어가 상호작용하는 외부 개체 (타 시스템, 장치, 사람)와 상호작용의 성격을 정의

• 아키텍처 archetype 식별 • archetype은 (클래스와 비슷하게) 시스템 동작의 한 요소를 나타내는 추상

• 설계자는 각 archetype을 구현하는 소프트웨어 컴포넌트를 정의 및 수정함으로써 시스템의 구조 명세

• 완벽한 아키텍처 구조가 도출될 때까지 반복적으로 프로세스를 진행

!27


Architectural Context

!28


Archetypes

!29


Component Structure

최상위 레벨의 컴포넌트 구조

!30


Component Structure

정제된 컴포넌트 구조

!31


Architectural Consideration• 경제성 (economy) :

• 최고의 소프트웨어는 불필요한 세부사항을 줄이기 위해 정리(uncluttered)되어 있고 추상화에 의존

• 가시성 (visibility) : • 아키텍처 결정 및 결정에 대한 이유는 나중에 코델을 검사하는 소프트웨어 엔지니어에게 분명해야 함

• 간격 (spacing) : • 숨은 의존 관계를 추가하지 않으며 관심 (concern)을 분리

• 대칭 (symmetry) : • 시스템이 일관성 있고 균형이 잡혀 있음을 의미

• 창발성 (emergence) : • 창발적이고 자기 조직화 된 행동 및 제어는 확장 가능하고, 효울적이며, 경제적인 소프트웨어 아키텍처를 생성하는데 중요

!32


Architectural Decision Documentation

1. 각 결정(decision) 및 이의 최적 표현을 위해 어떠한 정보 항목이 필요한지 결정

2. 각 결정과 적절할 요구 사항 사이의 연결 정의

3. 대안 결정의 평가 필요 시 상태 변경 메커니즘 제공

4. 추적 가능성을 지원하기 위해 결정 사이의 전제 조건 정의

5. 중요 결정과 결정으로 인한 아키텍처 뷰와 연결

6. 모든 결정을 문서화하고 전달 함

!33


Analyzing Architectural Design

• Architecture Trade-off Analysis Method (ATAM) by SEI1. 시나리오 수집

2. 요구사항, 제약 사항, 환경 기술을 도출

3. 시나리오와 요구사항을 위해 선택된 아키텍처 스타일/패턴 기술 • module view / process view / data flow view

4. 각 품질 속성을 개별적으로 고려하여 평가 5. 특정 아키텍처 스타일의 다양한 아키텍처 속성에 대해 품질 속성의 감도 식별

6. (3단계에서 개발 된) 특정 아키텍처 후보를 5단계에서 진행한 민감도 분석을 사용하여 평가

!34


Architectural Complexity

• 아키텍처 내의 컴포넌트 사이의 의존성을 고려하여 평가 • 공유 의존성

- 같은 자원을 사용하는 소비자 혹은 같은 소비자를 위해서 생산하는 생산자 사이의 의존성

• 흐름 의존성 - 자원의 생산자와 소비자 사이의 의존성

• 제한된 의존성 - 컴포넌트 집합 사이의 상대적 흐름에 대한 제약

!35


Architectural Review

• 소프트웨어 어키텍처가 시스템의 품질 요구 사항 충족 및 잠재적 위험을 식별할 수 있는 능력을 평가

• 설계 문제를 일찍 탐지하여 프로젝트 비용을 절감하는 잠재력

• 경험 기반 리뷰, 프로토타입 평가, 그리고 시나리오 리뷰, 체크리스트 등이 종 종 사용됨

!36


Pattern-based Architectural Review

1. 유스 케이스를 탐색하여 품질 속성을 식별하고 논함

2. 시스템의 아키텍처 다이어그램을 요구사항 관련하여 논함

3. 사용된 아키텍처 패턴을 식별하고 시스템 구조를 패턴 구조화 일치 시킴

4. 기존 문서 및 아전 유스 케이스를 사용하여 시스템 품질 속성에 대한 각 패턴의 효과를 결정

5. 설계에 사용된 아키텍처 패턴에 의해 제기 된 모둔 품질 문제 식별

6. 회의 중 발견된 문제에 대한 간략한 요약을 작성

!37

Documents

Architectural Design - Hanyang · 2018-05-20 · Analyzing Architectural Design • Architecture Trade-off Analysis Method (ATAM) by SEI 1. 시나리오 수집 2. 요구사항, 제약