소프트웨어아키텍처문서화 - kosta.or.kr 1-4_yokim.pdf · all rights reserved, young on,...

All Rights reserved, Young On, Kim (金榮溫)

소프트웨어아키텍처문서화

2016. 7. 21

김 영 온

All Rights reserved, Young On, Kim (金榮溫) - 2 -

History I. SW 아키텍처

1994

2012/2003/1997

2001

2011/2002

?


SW 아키텍처 정의

What is Software architecture?

시스템의 SW아키텍처는 SW요소와 요소간의

관계 그리고 각각의 속성으로 구성된

시스템에 필요한 구조의 집합이다.

아키텍처는 SW 구조의 집합이다. SW시스템은

많은 구조로 이루어지고, 단일 구조는

아키텍처가 아니다.

Module view / Component and connector view /Allocation view

컴포넌트와 컴포넌트 상호간 그리고 환경과의 관계, 설계와 개선 시 지

켜야 하는 원칙을 포함하는 시스템의 기본적인 조직 (fundamental

organization of a system) - ISO/IEC 42010: 2007 아키텍처 정의

I. SW 아키텍처


아키텍처 영향 주기

아키텍처 수립 주기 (AIC - Architecture Influence Cycle)

SW 아키텍처는 설계를 위하여 아키텍처를 구축하고, 목표 시스템 또는 어플리케이션을구축하고 관리하는 것을 포함한다.

1. 시스템 타당성 수립(Making a business case for the system)

2. 중요한 아키텍처 요구사항 이해(Understanding the architecturally significant requirements)

3. 아키텍처 생성 또는 선택(Creating or selecting the architecture)

4. 아키텍처 문서화와 의사소통(Documenting and communicating the architecture)

5. 아키텍처 분석 또는 평가(Analyzing or evaluating the architecture)

6. 아키텍처 기반 시스템 구축과 테스트(Implementing and testing the system based on the architecture)

7. 아키텍처에 따라 구축되었는지 확인(Ensuring that the implementation conforms to the architecture)

SW 아키텍처 수립의 주요 활동아키텍처 영향 주기

업무

기술

프로젝트

전문 역량

이해당사자 아키텍처

시스템

아키텍트

아키텍트의 영향

Software Architecture in Practice, 3rd edition, Bass, Clements,.., 2013

I. SW 아키텍처


Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000

S/W 아키텍처

설계

도메인 분석,

요구사항 분석,

위험 분석

상세 설계,

코딩,

통합 테스트

요구사항,요구 속성

요구사항변경요청

기술아키텍처

기술아키텍처변경요청

이행고려사항

S/W아키텍처

유형별 아키텍처간 상관 관계

- 5 -

Positioning

소프트웨어 아키텍처는 비즈니스 요구사항에 따라 개발한 기술과 데이터 아키텍처와 상호 영향을 미치면서 개발함

기술 아키텍처

설계

비즈니스 요구사항,

비지니스 아키텍처

개발 타스크

feedforward

feedback

이행고려사항

Biz.아키텍처

정보시스템 아키텍처

어플리케이션 아키텍처

데이터 아키텍처

정보시스템

아키텍처간 상관 관계

I. SW 아키텍처


아키텍처의 역할

Reflections on Software Architecture, SATURN, 2016

아키텍처의 핵심 역할

시스템아키텍처비즈니스와미션 목표

이행하고, 진화한다

설계한다

만족한다 확인한다

만족한다

이행한다

I. SW 아키텍처

- 6 -


A rational design process: how and why to fake it- David L. Parnas, Paul C. Clements, 1986

David L. Parnas- information hiding

in modular programming

Paul C. Clements

second author

first author

II. 합리적인 설계 프로세스


SW 프로젝트의 한계

1. 대부분의 경우 SW 시스템 개발에 참여하는 이해당사자는 무엇을 원하는지 정확히 모르고, 아는 것을 말해 줄 수 없다.

2. 요구사항을 알더라도 SW 설계를 위해서 알아야할 것이 더 많고, 상세내용은 개발을 진행하면서 알 수 있는 것도 있다.

3. 설계를 시작하기 전에 모든 상세한 내용을 알더라도, 인간은 올바른 시스템 설계와 개발을 위해 고려해야 할 상세한 내용을 이해할 수 없다는 것을 경험이 보여주었다.

설계 프로세스는 다룰 수 있는 정보의 양을 제한하여 일하도록 관심을분리하는 것이다. 따라서 관심을 분리하는 한 오류를 범할 수 밖에 없다.

SW 프로젝트를 합리적으로 진행하지 못하는 이유(1/2)

A rational design process: how and why to fake it, David L. Parnas, Paul C. Clements, 1986



SW 프로젝트의 한계

4. 필요한 모든 상세 내용을 완전히 이해하더라도, 대부분의 프로젝트는외부 요인에 의하여 변경이 발생한다.

5. 인간 오류는 인간을 사용하지 않을 때만 피할 수 있다. 관심을 분리하는 한 오류는 발생한다.

6. 자신의 경험, 관련 프로젝트 경험, 교실에서 들은 아이디어 같은 선입관에 의해 선호하는 설계 아이디어를 종종 적용하는데, 합리적인 프로세스에 의해 정의된 요구사항과 관계없는 아이디어일 수도 있다.

7. 경제적인 이유로 다른 프로젝트에서 개발한 SW를 사용하거나 다른 프로젝트와 SW를 공유하도록 요구 받을 수도 있다. 이 SW는 요구사항에따라 개발된 것이 아니기 때문에 어느 프로젝트에도 이상적이지 않을수 있지만, 공수를 절감하여 충분한 가치를 제공할 수 있다.

SW 프로젝트를 합리적으로 진행하지 못하는 이유(2/2)




Why rational process?

1. 설계자는 가이드가 필요하다. 이상적인 프로세스를 이해하면 어떻게 일을 진행할지 도움이 된다.

2. 임으로 진행하는 것보다 프로세스를 지키려고 노력하면 합리적인 설계에 더 가까워 질 것이다.

3. 조직이 여러 프로젝트를 진행한다면 표준 절차의 장점은 효과적인 설계검토, 프로젝트 간 인력 교류와 SW의 공유가 용이해진다.

4. 표준 프로세스에 합의하면, 프로젝트 진척도 측정이 더 쉬워진다.

5. 프로젝트 외부의 정기적인 프로젝트 진척도 검토는 관리를 위한 필수요소인데, 표준 프로세스를 준수하면 검토하기 쉬워진다.

합리적이고 이상적인 프로세스에 따른 설계가 필요 이유는?- faking a rational design process




문서화의 한계

대부분의 개발자는 문서는 필요 악이고, 관료화 (프로세스 또는 계약)때문에 사후적으로 작성하는 것이라고 생각한다.

문서에 내재된 구조적 문제점

부적절한 구조

“stream of consciousness” & “stream of execution”

지루한 문장 (a statement in PL, formula or diagram 대신에)

혼란스럽고 불일치하는 용어

근시안적 – 지엽적인 사항의 문서화로 시스템을 잘 아는 사람에게만 도움됨

문서화는?




합리적인 설계 프로세스

A. 요구사항 설정과 문서화

1. 왜 요구사항 문서가 필요한가?

1) 시스템의 바람직한 행위에 대한 기록이며, 사용자가 검토할 수 있는 문서이다.

2) 즉흥적인 요구사항 의사결정을 피해야 한다.

3) 중복과 불일치를 피할 수 있다. 요구사항 문서가 없으면, 설계자, 개발자, 검토자로부터 개발 내내 반복된 질문이 발생한다. (답변 불일치, 비용 발생)

4) 시스템 구축에 필요한 작업량과 자원 추정을 위해 충분치는 않지만 필요하다.

5) 요구사항 문서는 팀원이 이직할 경우, 프로젝트 지식을 유지할 수 있다.

6) 요구사항 문서는 테스트 계획 개발의 기초가 된다.

7) 요구사항 문서는 개발자사이에 이견이 발생했을 때 참고 자료로 사용될 수 있다.

2. 요구사항 작성자

이상적으로는 사용자 또는 대표자이나, 일반적으로 SW 개발자가 초안을 만들고, 사용자 대표가 검토하고 승인한다.

합리적인 설계 프로세스(1/2)




합리적인 설계 프로세스

B. 모듈 구조 설계와 문서화 – 모듈 가이드

중복 회피와 관심의 분리 “information hiding or separation of concerns”

문제 발생 또는 변경 요청에 따라 영향받는 모듈 발견이 용이함

C. 모듈 인터페이스 설계

모듈을 사용하는 access programs 목록

Access programs의 파라미터

Access programs의 외부적으로 보이는 효과

필요 시 시간과 정확도 제약사항

비정상 이벤트의 정의

D. 사용 계층 (uses hierarchy) 의 설계와 문서화

E. 모듈 내부 구조 설계와 문서화

F. 프로그램 작성

G. 유지보수

합리적인 설계 프로세스(2/2)




문서화 경제학과 원칙

아키텍처 문서화의 경제학

(아키텍처 문서 없는 어플리케이션 개발 비용 – 아키텍처 문서와 함께어플리케이션 개발 비용) > 아키텍처 문서 개발 비용

건전한 문서화의 7가지 원칙

1. 작성자가 아닌 독자의 관점에서 문서를 작성한다.

2. 불필요한 반복을 피한다.

3. 애매한 것을 피한다. 항상 노테이션을 설명한다.

4. 표준 구조를 사용한다.

5. 가설을 기록한다.

6. 문서를 너무 현행화하지는 말고, 현행화 한다.

7. 목적이 적합한지 문서를 검토한다.

Documenting Software Architecture: Views and Beyond, 2nd edition, Paul Clements, .., 2011

III. 아키텍처 문서화


SW 아키텍처 문서화


SW 아키텍처문서화

구성한다관련 뷰 집합

뷰

아키텍처로설계 된 구조

이해당사자별문서화

뷰 패킷

뷰 템플릿1. Primary Presentation2. 요소 카탈로그

a. 요소와 속성b. 관계와 속성c. 요소 인터페이스d. 요소 행위

3. 컨택스트 다이어그램4. 가변성 가이드5. 가설

Beyond 뷰 문서 템플릿1. 문서 로드맵2. 뷰 문서화 방법3. 시스템 개요4. 뷰 간 매핑5. 가설6. 디렉토리

인터페이스 문서 템플릿1. 인터페이스 identity2. 자원(syntax,

semantics, 에러 처리)3. 데이터 타입과 상수4. 에러 처리5. 가변성6. 품질 속성 특성7. 가설과 설계 이슈8. 사용 가이드

한 뷰 이상에적용된 정보

구성한다

구성한다

하나 이상을포함한다

문서화하기위하여 선택된다

~ 으로 나누어질 수 있다

문서화하기위하여 선택된다

구성한다 구성한다

SW 아키텍처 문서화



SW 아키텍처 스타일


스타일(style)뷰(view) 품질 속성

모듈 스타일

Pipe-and-Filter 스타일

분할 스타일하이브리드스타일

분할 스타일

사용 스타일

일반화 스타일

Layered스타일

Aspects스타일

데이터 모델스타일

Client-Server스타일

P2P 스타일

SOA 스타일

게시-구독스타일

공유 데이터스타일

멀티 티어스타일

전개 스타일

설치 스타일

작업 할당스타일

다른 분할스타일

컴포넌트와컨넷터 스타일

시스템에 적용될 때, ~을 만든다.

아키텍트가해결하기 위해선택한다.

하나 이상을결합한다.~ 일 수 있다. ~ 일 수 있다.~ 일 수 있다.

~ 일 수 있다.





모듈 뷰 Module view

~ 의 부분이다 is part of

서브 모듈과 집합 모듈 사이의 part/whole 관계

~ 에 의존한다 depends on

uses(사용)

allowed to use (레이어드)

crosscuts (aspect)

data entity relationships (데이터 모델)

~ 이다 is a

일반화/특화

객체 지향 상속과 인터페이스 실현





컴포넌트와 컨넥터 뷰 Component & connector view

콜-리턴 스타일

클라이언트-서버 스타일

P2P(peer-to-peer) 스타일

SOA 스타일

데이터 흐름 스타일

파이프 & 필터 스타일

이벤트 기반 스타일

게시-구독(publish-subscribe) 스타일

레포지토리 스타일

공유 데이터 스타일





할당 뷰 Allocation view

전개 스타일

설치 스타일

작업 할당 스타일

다른 할당 스타일

구현 스타일

데이터 스토어 스타일

특화 Specialization

전개 스타일 특화

작업 할당 스타일 특화

플랫폼 스타일

Competence 센터 스타일

오픈 소스 스타일

프로세스 스텝 스타일(SW 개발 단계에 따라)

릴리즈 기반 스타일




SW 아키텍처 템플릿

아키텍처 노트북 - OpenUP

1. 목적

2. 아키텍처 목적과 철학

3. 가정과 의존성

4. 아키텍처적으로 중요한 요구사항(ASR)

5. 결정, 제약사항,그리고 정당화

6. 아키텍처 메카니즘

아키텍처 메카니즘 1

아키텍처 메카니즘 2

7. 핵심 추상화

8. 레이어 또는 아키텍처 framework

9. 아키텍처 뷰

추천 뷰

논리 뷰

운영 뷰

Use case 뷰

템플릿

http://epf.eclipse.org/wikis/openup/



SW 아키텍처 템플릿

SW 아키텍처 문서 템플릿 – Rational Software

아키텍처 목표와 제약사항

비즈니스 도메일/Use-Case 뷰

비기능 요구사항

논리 뷰

프로세스 뷰

이행 뷰

전개 뷰

용량과 성능

품질

………..

Architecture Deliverables

Principles of Architecting Software Systems, Rational Software, 2000

별첨 산출물

설계 가이드라인

프로그래밍 가이드라인

테스팅 가이드라인

변경 가이드라인

SW 형상 관리 계획

베이스라인 아키텍처

실행 가능한 아키텍처 프로토타입

이행한 베이스라인 아키텍처

일부 이행한 시스템

선택된 시스템을 보여주기 위한prototype

파악된 위험 완화를 위한 prototype

이행 시스템의 일부로서 prototype



이해 당사자와 문서 요구



프로젝트 관리자

Deta

il

ModuleViews

C&CViews

AllocationViews

테스터 또는 통합자

Deta

il

ModuleViews

C&CViews

AllocationViews

개발자

Deta

il

ModuleViews

C&CViews

AllocationViews

고객

Deta

il

ModuleViews

C&CViews

AllocationViews

분석가와 아키텍트

Deta

il

ModuleViews

C&CViews

AllocationViews

사용자

Deta

ilModuleViews

C&CViews

AllocationViews





이해당사자와 문서 요구

Module ViewsC&CViews

Allocation Views Other Documentation

Deco

mpositio

n

use

s

Genera

lizatio

n

Layere

d

Data

Model

Vario

us

Deplo

ym

ent

Imple

menta

tion

Insta

ll

Work

Assig

nm

ent

Inte

rface

Docu

menta

tion

Conte

xt D

iagra

m

Mappin

g B

etw

een V

iew

s

Varia

bility

Guid

e

Analy

sis Resu

lts

Ratio

nale

& C

onstra

ints

Project managers s s s d d o s

Development team member d d d d d d s s d d d d d s

Testers and integrators d d d d d s s s s d d s d s

Designers of other systems s d o

Maintainers d d d d d d s s d d d d d

Product-line appl. builders d d s o s s s s s s d s d s

Customers o o o s

End users s s o s

Analysts d d s d d s d s d d s d s

Infra support personnel s s s s d d o s

New stakeholders x x x x x x x x x x x x x x x x

Current & future architects d d d d d d d s d s d d d d d d

KEY: d = detailed information, s = some details, o = overview information, x = anything



Which views?

ECS: system for making available extremely high volumes of data from a constellation of earth-observing satellites.

12 후보 뷰

decomposition, uses, layered, generalization,

Pipes-filter, Shared-data, client-server, peer-to-peer, communicating-processes,

deployment, implementation, work assignment

7 뷰

decomposition/uses, layered, generalization,

shared-data/client-server/peer-to-peer/communicating-processes,

deployment, implementation, work assignment

full-fledged 4 뷰

decomposition

work assignment

combined C&C

deployment

+ minor three ones with coarse grained




모델의 관계

System

Sub System

Class

Package

Layer

Entity

Actor

Use case

Event

Activity Diagram

Sequence/Communication

1..*1..*

1..*

1..*

1..*

1..*

1

1

1

1

1..?

1..* 1..*11

0..*

1..?

1..*

1..*

1

관심의 분리 separation of concerns, 나누어서 정복 divide & conquer

Architecture patterns 적용 View & control class 추가 Layered class 추가 …..

Design patterns 적용 기술적 요구사항 반영



마무리하며

1. 구축할 SW의 량을 줄인다.

범위 관리 (범위 내, 사용자에게 도움이 되는, 개발할 수 있는 것을 제대로)

중복 최소화

2. 프로세스 개선과 팀워크를 통하여 재작업을 줄인다.

프로세스 최적화

역량 개발과 팀 빌딩

모든 구성원이 능동적이고 예방적인 검토와 인스펙션 수행

3. 자동화를 통하여 잔여 작업의 노동 집중을 줄인다.

도구 사용 (역량 확보 & 프로세스 먼저)

합리적인 SW 아키텍처는 프로젝트 성공의 핵심이다.

Software project management – A unified framework, Walker Royce,, Addison-Wesley, 1998

Best Practices

- 26 -


마무리하며

아키텍처 문서는

프로젝트에 도움이 되어야 한다

Accurate without being overly precise

요구사항을 정확하게 반영한다.

검증된 내용만 포함하고 상세 설계와 구현에서 준수할 수 있는 내용만은 포함한다.

이해당사자의 눈높이를 맞추어야 한다.

Waterfall 보다는 반복/점진적 또는 애자일로 아키텍처를 검증하고 문서를 작성한다.


Any questions & comments?

Software 공학 이야기 http://youngseolsan1.blogspot.kr/

프로젝트에서 SW아키텍트의 역할 http://www.slideshare.net/yokim31/sw-20140717

[email protected] 김 영온

소프트웨어아키텍처문서화 - kosta.or.kr 1-4_yokim.pdf · all rights reserved, young on,...

Documents