The Past, Present, and Future of Software Architecture 재사용 방법론 권오현.

Presentation on theme: "The Past, Present, and Future of Software Architecture 재사용 방법론 권오현."— Presentation transcript:

1 The Past, Present, and Future of Software Architecture 재사용 방법론 권오현

2 Index Index of Article  What is software architecture  A brief history of software architecture  Where are we now?  The articles in this issue  Future

3 What is software architecture The structure and organization by which modern system components and subsystems interact to form systems The properties of systems that can best be designed and analyzed at the system level 소프트웨어 아키텍처는 다음과 같은 요소들을 포함  소프트웨어 디자인  소프트웨어 재사용  소프트웨어 공학  엔터프라이즈 아키텍처  리버스 공학  요구사항 공학  품질

4 What is software architecture Paul Clements lists several definitions on the Software Engineering Institute’s architecture practices site  http://www.sei.cmu.edu/architecture/definitions.html

5 What is software architecture Paul Clements lists several definitions on the Software Engineering Institute’s architecture practices site  John Carter (Software Technologist) 디자인에서의 기묘한 일관성과 동질성이 재사용성을 높일 수 있도록 도와주는 것  Giovanni Godena (Software engineer) 재사용성을 높이기 위해서 우리는 우리가 목표로 하는 도메 인의 산출물들을 잘 사용해야 한다. 이러한 산출물들과 이들 간의 관계는 아키텍처로 정의가 되어 있을 것이다. Software Architecture 는 이들을 성공적으로 재사용하기 위해서 사용한 다.

6 What is software architecture Paul Clements lists several definitions on the Software Engineering Institute’s architecture practices site  Praveen Joshi (Team Leader, LG Soft India) Software Architecture 는 잘 정리된 규칙들과 시스템의 구조를 정의하기 위한 프로토콜로 구성된 프레임워크이다. 잘 정의된 아키텍처는 심플하고 더 나은 삶으로 인도한다. 이것은 다양 한 복잡도와 종류, 크기를 가진 기능들을 실제 실행 단계로 인 도한다. 잘 설계된 아키텍처는 그리하여 소프트웨어 구성요소 들의 재사용성을 극대화한다.

7 What is software architecture Subareas of the software architecture  Architectural design 어떻게 아키텍처를 만들 것인가 ?  Analysis 우리가 아키텍처를 기반으로 최종적인 상품의 확실한 품질에 관한 문제들을 어떻게 답할 것인가 ?  Realization 우리가 아키텍처 기술 내용을 기반으로 시스템을 어떻게 생 산할 것인가 ?  Representation 어떻게 사람이나 기계들이 의사소통할 수 있는 확실한 결과 물들을 생산할 것인가 ?  Economics 어떤 아키텍처 이슈들이 기업의 의사결정을 이끌어 내는가 ?

8 A brief history of software architecture Pre-1995  1969 NATO 에서 Software architecture 라는 구문을 처음 사용  Until the late 1980s “Architecture” 라는 단어가 컴퓨터 시스템의 물리적인 구조를 나타내는 뜻으로 널리 쓰임  간혹 컴퓨터의 명령어 집합 등으로도 사용  1990s 명확한 분야로써의 Software Architecture 의 컨셉이 확립 Winston W. Royce, Walker Royce 는 1991 년, 저서인 Systems Architecting: Creating and Building Complex Systems 에서 처 음으로 기술과 프로세스 사이에서의 Software Architecture 의 위치를 제시함

9 A brief history of software architecture Pre-1995  1990s {elements, forms, rationale} = software architecture  요소 (Elements): 프로세싱 요소, 데이터 요소, 연결 요소  표현법 (Forms): 속성과 관계  근거 (Rationale): 아키텍처를 정의하는데 고려되어지는 다양한 선택에 대한 근거 ( 기능성, 성능, 신뢰성, 경제성 )  당시 존재했던 많은 Architecture Description Languages (ADLs) 들의 기본으로 사용됨 C2, Rapide, Darwin, Wright, ACME, Unicon… 1994 년, IBM 에서 Software architecture 에 관한 첫 번째 도서 출판

10 A brief history of software architecture 1995-1998  1995 년을 기점으로 Software Architecture 에 관한 연구나 산업 전 반에 걸친 적용이 가속화됨  Software Architecture Analysis Method (SAAM) Software Engineering Institute (SEI) 에서 개발 Software Architecture 를 평가하기 위한 첫 번째 방법론 수정가능성 (Modifiability) 관점에서 평가 및 분석 아키텍처 기술서와 품질 속성을 설명하는 시나리오를 통해 시나리오와 아키텍처간의 매핑 테이블 등의 산출물을 생성

11 A brief history of software architecture 1995-1998  Software Architecture Analysis Method (SAAM) 시스템이 지원해야 하는 모든 기능성에 대해서 도출  시스템의 주요 사용  시스템의 사용자  미래의 변경 가능성  시스템이 지원해야 하는 품질 속성 시나리오 개발 ( 브레인 스토밍 ) => 분류 및 우선순위 결정 ( 투 표 ) => 시나리오와 아키텍처 맵핑 => 시나리오간 상호작용 평가 => 전체 평가

12 A brief history of software architecture 1995-1998  다양한 Multiple View 나 디자인 패턴들이 개발됨  Nokia, Philips, Nortel, IBM 등 거대 개발 회사들이 Software Architecture 나 Software Product Line Architectures 를 조사하기 위한 Reuse Community 에 대해 관심을 기울이기 시작

13 A brief history of software architecture 1999-2005  Software Architecture 의 첫 번째 IFIP 컨퍼런스가 1999 년에 개최  Architecture Description Markup Language Architecture Description 을 위해 Open Group 이 소개 XML 기반 Architecture Description Language 아키텍처 모델의 광범위한 공유를 지원하기 위한 목적  Software Product Line 이 기본 원칙으로 탈바꿈  새로운 아키텍처 방법론들의 대두 BAPO, ATAM, etc… IEEE 는 RMODP 와 IEEE1471 을 기본 아키텍처 표준으로 사용  Software Architecture 에 관한 새로운 책들이 계속해서 출판

14 A brief history of software architecture 1999-2005  재사용 효과, Process pattern, p46 효과적인 재사용에 관한 제시

15 1999-2005  재사용 효과, Process pattern, p46 Domain-component Reuse  미리 빌드된, 넓은 범위의 도메인 컴포넌트의 재사용 Pattern Reuse  패턴의 재사용 Artifact Reuse  이전 개발에서 사용한 Use Case 나 표준 문서, 도메인 상 세, 산출물 가이드라인 등의 재사용 Framework Reuse  공용 기술이나 비즈니스의 기본 기능성을 공유하는 클래 스 컬렉션의 재사용 A brief history of software architecture

16 1999-2005  재사용 효과, Process pattern, p46 Component Reuse  미리 빌드된, 캡슐화된 컴포넌트의 재사용 Template Reuse  산출물 및 문서, 모델이나 소스코드의 템플릿을 재사용 Inheritance Reuse  존재하는 클래스를 상속하여 쓰는 재사용 Code Reuse  소스코드의 재사용 A brief history of software architecture

17 아키텍처 표준화 아키텍처 표준화의 필요성  다양한 모델간의 메시지 교환, 재사용성을 강화 아키텍처 = 다양한 관점에서의 모델들로 구성 여러 사용자들의 요구사항들간의 격차를 줄임 아키텍처를 효과적으로 표현  다양한 아키텍처 표준화 기법 ADL, UML, IEEE1471….

18 아키텍처 표준화 아키텍쳐 표현의 두 가지 방법  ADL 을 통하여  UML 을 이용하여 Requirements ADLsUML Code

19 아키텍처 표준화 ADL  고차원 시스템 구조 모델링 아키텍처 구조에 맞도록 표기법의 테일러링 가능 시스템 레벨의 성질들을 이해하기 쉬움 아키텍처 연구 그룹들부터의 다양한 경험 반영 다양한 도구 UML  객체지향 위주의 아키텍처 모델링  구현과 직접 연결  산업계 표준  상업적 도구 지원

20 아키텍처 표준화 ADL 의 필요성  프로그래밍 언어 사용 구현 수준의 표현 높은 수준의 추상화의 어려움 의사소통의 불확실성 제고, 이해성 제고 아키텍처 모델의 분석, 정제, 구현의 자동화를 통해 효율성 추구 ADL 현황  시스템 구조와 행위의 특정 측면을 표현하기 위한 수많은 언어들이 존재하지만 중요한 모든 측면들을 종합적으로 기술할 수 있는 ADL 은 존재하지 않음  ADL 로 기술된 아키텍처를 EJB 나 COM 아키텍처로 변환하는 것이 쉽지 않음  UML 프로파일 및 MDA 등장의 배경

21 아키텍처 표준화 ADL 의 예시  ACME Architecture Description Languages: An Overview, Tw Cook, MCC, 1999

22 아키텍처 표준화 IEEE 1471  IEEE 에서 2000 년 제정된 국제 표준  아키텍처가 표현해야 하는 내용 및 이들간의 관계를 제공  어떤 규모의 개발 프로젝트에서도 유용하게 활용될 수 있는 포괄 적인 내용을 다룸  아키텍처 명세가 반드시 포함해야 하는 내용들을 기술 이해관계자 (stakeholder), 관심사항 (concern), 뷰포인트 (viewpoint), 뷰 (view), 모델 (model) 등 Architecture Description Languages: An Overview, Tw Cook, MCC, 1999

23 Where are we now? 몇 몇 도메인에서는 J2EE 나.NET, Symbian/Series 60 과 같이 미리 조리된 (Precooked) 아키텍처가 플랫폼의 형태 로 제공됨  XML 이나 SOAP 와 같은 Application layer interchange 표준들은 이 러한 아키텍처에 중요한 영항을 미침 Python 이나 Perl 과 같은 스크립트 언어는 우리가 시스템 을 구성하는 방법을 변화시킴 프로젝트 시작의 변화  플랫폼의 능력에 관한 이해력을 바탕으로 시스템을 설계  오픈소스 소프트웨어와 같은 요소가 영향을 미침

24 The articles in this issue The Golden Age of Software Architecture  Mary Shaw and Paul Clements  Software Architecture 분야의 성숙에 관한 내용

25 The articles in this issue In Practices: UML Software Architecture and Design Description  Christian Lange, Michel Chaudron Muskens  UML 의 사용과 이의 효용성 및 문제에 관한 넓은 범위의 조사 자 료를 제공

26 The articles in this issue In Practices: UML Software Architecture and Design Description  UML 의 개선점 모델링에서의 좀 더 높은 표준성 특정 도메인이나 프로젝트를 위한 아키텍처 및 패턴 제공 Implementation 을 위한 UML 모델과 시스템 요구사항간의 높 은 일관성 품질 목표를 정의하기 위한 UML 모델

27 The articles in this issue Software Architecture-Centric Methods and Agile Development  Robert L. Nord, James E. Tomayko  Architecture-centric 방법론과 애자일 개발 방법론에 관한 컨셉

28 The articles in this issue Software Architecture-Centric Methods and Agile Development  XP(Extreme Programming)- 정규화된 프로세스 대신 기본 철학을 정의 수동적인 프로세스보다 능동적인 의지로 개발에 참여 의사소통  원활한 의사소통을 통해 왜곡된 결과를 미연에 방지  Pair Programming, 고객 상주 및 단위 테스트와 같은 방법 제시 단순성  당장 필요한 기능만 최대한 잘 만드는 것을 의미  의사소통과 맞물려서 간결한 디자인과 프로그램에 대한 불필요 한 의사소통을 최소화해서 전체적인 효율성을 높임 피드백  개발대상 시스템이며 즉각적인 피드백을 확인하기 위해서 항상 시 스템을 구성하는 프로그램이 실행 가능한 상태를 유지 용기  의사소통, 단순성, 피드백 등을 통해 다른 사람이 작업한 내용을 수 정할 때 개발자들이 부정적이거나 소극적인 모습을 보이지 않도 록 유도

29 The articles in this issue Using Architectural Patterns and Blueprints for Service- Oriented Architecture  Michael Stal  기존의 패턴들을 사용해 SOA 를 기반으로 하는 시스템의 기본적 인 구조를 설명  시스템 아키텍처적으로 미리 구성된 패턴을 사용함으로써 시스 템의 목적을 손쉽게 달성 서비스 클라이언트와 서비스 제공을 분리하기 위한 느슨한 결합 설계 구조 다양한 커뮤니케이션 스타일을 지원하기 위한 메시지 교환 패턴 서비스 검색 및 등록에 관한 패턴

30 The articles in this issue Using Architecture Models for Runtime Adaptability  Jacqueline Floch, Svein Hall steinsen, Erlend Stav, Frank Eliassen, Ketil Lund, Eli Gjorven  런타임 분석을 위한 아키텍처 리저닝의 필요성을 확장

31 Future 향후 10 년동안의 예상 이슈 (From 2006)  UML 을 기반으로 하는 Model-driven architecture  특정 도메인 아키텍처의 디자인, 표현, 분석, 실행 등과 같은 작업 들을 지원하는 툴  Agile Software development 의 기본 원칙을 지원하는 Software Architecture 주요 아키텍처 이슈  클라우드 시스템 아키텍처  Model Driven Development  모바일 애플리케이션 아키텍처  분산처리 애플리케이션  웹 애플리케이션 아키텍처  웹서비스 아키텍처

32 32

33 아키텍처 표준화 ADL 의 특성  합성 및 구현 부분적 기술들을 합성하여 전체 시스템의 구성 이질적 아키텍처의 합성 상위 수준의 제약성을 가진 도메인 아키텍처의 표현  추상화 서브 시스템의 캡슐화 사용자 정의  재사용 디자인 솔루션 ( 아키텍처 ) 의 재사용  분석 일관성, 완전성 등 시스템 수준의 특성을 아키텍처 모델에서 확인하고 검증할 수 있어야 함

34 ADL 과 UML ADL 의 예시  Semantic Application Design Language (SADL) Semantic Application Design Language (SADL), http://sadl.sourceforge.net/

35 Ten years of software architecture