0204. 아키텍처 분석과 설계 – 아키텍처 스타일 (SI 트랙) 2004. 02. 15                              

목차 패턴이란? 패턴의 의의(意義) 패턴과 패턴 언어 패턴의 형식 아키텍처 스타일이란? 아키텍처 스타일과 아키텍처 설계 ABAS 요약 소프트웨어 아키텍처

패턴이란? 풋내기와 전문가 어디서 많이 본 것 같기는 한 데… 처음이야… 어디서부터 시작해야 할까… 예전에 비슷한 걸 해봤지. 그 때하고 비슷한 방법을 쓰면 되겠군. 그 때하고 이 부분은 조금 다른 걸. 전문가들은 모든 것을 처음부터 다시 시작하지 않는다. 예전에 찾았던 좋은 방법을 반복해서 계속 활용한다. 소프트웨어 아키텍처

패턴이란? 애정소설 쓰기 애정소설 공식 소프트웨어 아키텍처 하늘 아래 새로운 것은 없다. 소설가들이 항상 새로운 이야기를 만들어 내는 것 같지만 예전부터 전해오던 이야기 틀에 살을 붙여 가는 것이다. 애정소설 공식 소프트웨어 아키텍처

패턴이란? 게으르고 영악한 건축가 이야기 어느 건축가가 대학 건물과 그 주변 통행로를 설계하게 되었다. 하지만, 이 건축가는 대학 건물만 설계하고 통행로는 전혀 설계하지 않은 채 게으름을 피웠다. 결국 통행로 없이 건물은 완성되었다. 하지만 이 건축가는 계속 여유만만이었다. 사람들은 정해진 통행로가 없었기 때문에 자기 편한 데로 대학 건물 주위를 돌아 다녔다. 어느덧 겨울이 되었고 어느 날 큰 눈이 내렸다. 건축가는 드디어 일을 시작했다. 사람들이 눈 위에 만들어 놓은 발자국들을 사진으로 찍기 시작했다. 봄이 되자 건축가는 겨우내 찍어 두었던 사진들을 보고 통행로를 설계했다. 완성된 통행로는 돌아다니기도 편했고 주변 대학 건물과도 훌륭한 조화를 이뤘다. - Brian Foote 아! 패턴이란 이런 것이다. 그 분야 최고 전문가들이 쌓아온 경험의 결정체다. 어디로 다니고 싶은 지 제일 잘 아는 사람은 대학 건물 주위를 돌아다니는 사람들이다. 이 사람들이 바로 대학 건물 주변의 동선(動線)을 제일 잘 알고 있는 전문가이고 영악한 건축가는 이 전문가들의 경험을 그대로 활용한 것이다! 소프트웨어 아키텍처

패턴이란? 크리스토퍼 알렉산더 어떤 문제는 홀로 해결되기 보다는 경쟁하는 다른 압박요인과 방해요소가 있는 환경에서 해결되기 마련이다. 다른 문제들이 상존하는 상황에서 찾아낸 특정 문제에 대한 해결책이 반복되면 이 해결책은 패턴이 된다. 문제를 작은 단위로 쪼개가다 보면 해결책의 모습이 저절로 드러난다. 최종 해결책은 새로운 해결책을 만들어 낸다. 패턴을 항상 같은 방식으로 적용할 수는 없지만 계속 반복해서 재사용할 수 있다. - The Timeless Way of Building, Oxford University Press, 1979 소프트웨어 아키텍처

패턴이란? 결국, 패턴이란 여러 문제들이 경쟁하는 상황에서 특정 문제에 대한 반복해서 나타나는 해결책이다. 다양한 상황에서 성공한 해결책들의 정수(精髓)가 바로 패턴인 것이다. 소프트웨어 아키텍처

패턴의 의의(意義) 설계 생산성을 높인다. 문제와 해결책을 문서화해서 문제 영역에서 쓰는 어휘와 언어를 정의한다. 전문가의 경험이 빠르게 초보자에게 전달된다. 초보자라도 어느 정도 수준이 있는 해결책을 빨라 내 놓을 수 있다. 문제와 해결책을 문서화해서 문제 영역에서 쓰는 어휘와 언어를 정의한다. 문제와 해결책에 대한 경험과 영감을 나눌 수 있다. 문제와 해결책을 간단 명료하게 설명할 수 있어서 협력을 쉽게 하고 쓸 데 없는 논쟁을 줄인다. 소프트웨어 아키텍처

패턴과 패턴 언어 어휘와 문법을 단순히 모은다고 언어가 되는 것이 아니듯이 패턴 언어도 단순하게 패턴과 규칙을 모아 놓은 것은 아니다. 문제를 해결하는 완전한 문장을 만들 수 있어야 비로소 패턴 언어가 된다. 문제를 해결하려면 언제 어떤 패턴을 어떻게 생성해야 하고 이 패턴이 다른 패턴과 어떤 관계를 맺고 있는 지 밝혀야 한다. 패턴 언어는 전체는 부분의 합보다 크다는 법칙을 만족해야 한다. 패턴 언어는 개별 패턴으로는 해결하기 힘든 복잡한 문제를 해결하고자 패턴들을 일정한 규칙에 따라 모아 놓은 것이다. 소프트웨어 아키텍처

패턴의 형식 패턴은 반드시 문서로 정리되어야 한다. 패턴 문서의 구성 항목은 다음과 같다. 소프트웨어 아키텍처 이름(Name) : 이름은 한 두 단어만으로 패턴이 다루는 문제와 해결책을 떠 올릴 수 있어야 한다. 이름은 우리가 문제 영역을 논의할 때 쓰는 어휘가 되어, 우리의 의도를 한 단어로 간단 명료하게 표현할 수 있게 도와준다. 말이 많아 질수록 오해가 생길 가능성도 커지기 때문에 한 마디로 간단하게 의도를 표현할 수 있다면 의사 소통 비용을 크게 줄일 수 있다. 또, 아이들이 자라날 때 어휘가 늘어나는 만큼 사고 영역이 넓어지는 것처럼, 문제영역을 논의할 수 있는 어휘가 늘어나면 문제 영역에 대한 생각의 폭은 넓어지고 생각하는 것도 쉬워진다. 따라서, 우리는 패턴에 의사소통과 사고활동을 쉽게 할 수 있도록 문제와 해결책을 대표할 수 있는 이름을 붙여야 한다. 어쩌면 이름을 정하는 것이 패턴을 기술할 때 제일 힘든 일일 지도 모른다. 문제(Problem) : 문제는 패턴의 의도를 설명해야 한다. 문제는 패턴이 특정 상황(context)과 압력(force)을 극복하고 결국 이뤄야 하는 목표를 설명한다. 따라서, 문제를 설명하려면 문제를 만든 상황과 압력을 빼놓지 않고 자세히 설명해야 한다. 상황(Context) : 상황은 패턴을 적용할 수 있는 조건이다. 패턴을 적용할 수 있는 조건이란 어떤 문제가 있고 이 문제를 해결하기 위해 패턴을 적용하기 전에 시스템이 가지는 상태라고 생각하면 된다. 특정 상황에서는 같은 문제가 반복해서 나타나고 이 문제를 푸는 해결책도 비슷하게 반복된다. 우리는 상황을 통해 패턴을 적용할 수 있을지 판단할 수 있다. 압박요인(Forces) : 압박요인은 문제가 생기게 된 원인들을 설명한다. 한 가지 문제는 보통 여러 가지 원인에서 생겨난다. 이 원인들은 자기들끼리 상충할 수도 있고 패턴이 달성해야 하는 목표와 상충할 수도 있다. 보통 압박요인은 패턴이 등장하게 된 동기인 시나리오로 표현된다. 압박요인들을 보면 풀어야 할 문제가 얼마나 복잡한지 알 수 있다. 또, 압박요인들을 잘 조절해서 압박요인들이 만들어낸 부조화와 긴장 상태를 해소할 수 있는 여러가지 절충안을 결정한다. 해결책(Solution) : 해결책은 원하는 결과를 얻는 방법을 설명한 관계와 규칙이다. 해결책은 패턴의 구조, 참가요소, 협력관계를 나타낼 수 있는 그림, 다이어그램, 문장으로 표현하며 패턴이 어떻게 문제를 해결하는 지 설명한다. 해결책은 변하지 않는 구성요소들의 관계뿐만 아니라 구성요소들이 모여 상호작용하는 행위도 설명해야 한다. 구조가 패턴의 모습과 구성을 설명한다면 행위는 패턴이 살아움직이는 메커니즘을 설명한다. 해결책을 설명할 때는 해결책을 실현할 때 지켜야 하는 지침을 명시할 때도 있고 변경할 수 있는 부분이나 특화할 수 있는 부분을 명시할 수도 있다. 해결책은 다양한 경우에 적용할 수 있는 틀일 뿐이지 특정 구현이나 설계는 아니라는 것도 기억해야 한다. 예제(Examples) : 예제는 패턴을 적용해서 문제를 해결하는 모든 과정을 예제를 통해 설명한다. 패턴을 적용해야 할 문제, 이 문제가 나타나게 된 상황과 압력, 패턴이 제공한 해결책을 적용한 방법, 해결책을 적용한 결과를 실례를 들어 자세히 설명했기 때문에 우리가 패턴을 선택해서 적용할 때 많은 도움을 준다. 해결책을 실현한 예제 구현이 붙기도 한다. 누구나 잘 아는 예를 드는 것이 좋다. 결과(Resulting Context) : 결과는 패턴을 적용했을 때 시스템에 생긴 모든 변화를 설명한다. 패턴을 적용해서 나타난 결과(consequence)와 부작용을 설명한다. 패턴을 적용하면 시스템은 새로운 상태를 가진다. 결과는 이 새로운 상태를 가진 시스템에 생길 수 있는 문제와 이 문제를 해결할 수 있는 또 다른 패턴은 무엇인지 기술한다. 결과는 패턴을 적용해서 해결한 압박요인도 있고 해결하지 못한 압박요인도 설명해야 하기 때문에 결과를 압박요인의 분해능(resolution)라고도 한다. 원리(Rationale) : 원리는 문제의 원인인 압력을 해결한 방식과 근거가 패턴의 목적, 원칙, 철학에 부합한다는 것을 밝혀서 패턴을 정당화한다. 원리는 상충하는 여러 압력과 제약조건들이 어떻게 서로 조화를 이룰 수 있는지, 패턴이 실제로 동작하는 방식과 이유가 무엇인지, 왜 이 패턴이 좋은지 설명해야 한다. 해결책에 참여하는 구성요소들이 겉으로 드러나는 패턴의 구조와 행위를 설명한다면 원리는 감춰져 있는 핵심 메커니즘과 근본 구조에 대한 영감을 제공한다. 관련패턴(Related Patterns) : 관련 패턴은 이 패턴이 다른 패턴들과 어떤 관계를 맺고 있는 지 설명한다. 서로 관계를 맺고 있는 관련 패턴들은 압력을 공유하기도 한다. 패턴들이 관계를 맺는 방식에는 몇가지 종류가 있다. 관련패턴에는 몇가지 종류가 있다. 우선, 한 패턴의 결과 상황이 다른 패턴의 초기 상황이 되어서 한 패턴이 다른 패턴을 이끌어 내는 선임자(preprocessor)-후임자(successor) 관계가 있다. 또, 다른 압력과 제약조건이 작용하기 때문에 같은 문제에 다른 해결책을 제시하는 대안(alternative) 관계와 동시에 적용해야 하는 상호종속(codependent) 관계도 있다. 알려진 사례(Known Uses) : 알려진 사례는 누구나 잘 알고 있거나 현존하는 시스템에서 이 패턴을 적용한 사례를 설명한다. 알려진 사례는 패턴이 실제로 반복해서 나타나는 문제들을 해결하고 있다는 것을 증명해서 패턴의 정당성을 입증하는 데 도움을 준다. 이 밖에도 필수요소는 아니지만 아니지만 개요(Abstract) 부분을 제일 처음 구성요소로 두어서 패턴의 전체 모습과 풀어야 하는 문제에 대한 간략한 설명을 제공하는 것도 좋다. 소프트웨어 아키텍처

소프트웨어 공학과 패턴 패턴과 패턴 언어는 은 소프트웨어 공학의 기본 어휘와 언어이다. 소프트웨어 공학의 거의 모든 분야에 패턴이란 개념이 적용된다. 디자인 패턴, 아키텍처 패턴, 유스케이스 패턴, 분석 패턴, 구현 패턴, 배포 패턴, 일정관리 패턴, 형상관리 패턴, 요구사항관리 패턴, 사용자 인터페이스 패턴, 버그 패턴, …  패턴은 소프트웨어 공학의 모든 분야에서 전문가의 경험을 모아 문제 해결법을 제공하는 학문으로 발전하고 있다. 소프트웨어 아키텍처

아키텍처 스타일이란? 아키텍처 패턴? 아키텍처 스타일? 소프트웨어 아키텍처 논쟁이 끊이지 않는다. 아키텍처 패턴과 아키텍처 스타일을 같은 것으로 생각하는 견해도 있고(SAiP) 다른 것으로 생각하는 견해(The Art of Software Architecture)도 있다. 아키텍처 스타일은 패턴 언어와 비슷한 개념으로 생각하는 견해도 있고 아키텍처 스타일과 아키텍처 패턴을 같다고 생각하는 견해도 있다. 여러 자료를 조사해보니 아키텍처 패턴은 “해결책” 자체에 가깝고 아키텍처 스타일은 아키텍처 패턴에 패션(fashion)이란 의미가 더해진 것 같다. 또, 아키텍처 스타일과 아키텍처 패턴을 다르다고 주장하는 쪽은 아키텍처 자체가 복잡하고 커다란 개념이기 때문에 아키텍처 패턴이라는 의미 덩어리로 해결하기엔 벅차다는 생각인 것 같다. 아키텍처 스타일이 직접 아키텍처가 해결해야 할 문제에 대한 해결책을 제공한다기 보다는 문제 해결책의 프레임워크만 제공한다고 주장한다. 하지만, ABAS 같이 아키텍처와 품질속성의 관계를 밝히려는 노력이 계속되면서 아키텍처 스타일이 문제를 어떻게 해결하는지 밝혀지면서 아키텍처 스타일이 문제 해결책에 점점 가까워 지고 있는 것 같다. – 해묵은 논쟁에 대답하고 싶은 생각은 없다… 그냥 비슷한 것이라고 생각하면 되지 않을까? 소프트웨어 아키텍처

아키텍처 스타일이란? 소프트웨어 아키텍처 건축에서 쓰이던 용어. 아키텍처 스타일은 건물의 외관, 실내 장식, 가구 배치까지 결정한다. 아키텍처 스타일은 건물의 모든 것을 결정하는 기초이면서 건물 안에서 사는 사람들의 생활 방식까지 결정한다. 모델링 접근법에 따라 설계한 모든 건물이 지닌 특징 있는 구조를 정의하는 개념과 기법의 기초. 소프트웨어 아키텍처

아키텍처 스타일이란? 아키텍처 스타일은 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질속성을 달성할 수 있는 방법을 문서로 정리한 것이다. 아키텍처 스타일은 시스템의 모든 설계 작업의 기초를 제공한다. 아키텍처 스타일은 다음을 정의한다. 구성요소들 구성요소들의 상호관계와 구성방식 구성요소들의 정확한 의미와 한계 구성방식에 맞춰 구성요소들이 상호작용하는 메커니즘 아키텍처 스타일이 정의하는 것들 A set of element types (such as a data repository or a component that computes a mathematical function). A topological layout of the elements indicating their interrelation-ships. A set of semantic constraints (e.g., filters in a pipe-and-filter style are pure data transducers—they incrementally transform their input stream into an output stream, but do not control either upstream or downstream elements). A set of interaction mechanisms (e.g., subroutine call, event-subscriber, blackboard) that determine how the elements coordinate through the allowed topology. 소프트웨어 아키텍처

아키텍처 스타일이란? David Garlan, Mary Shaw 아키텍처 시스템을 구성하는 컴포넌트와 커넥터 종류와 이 것들이 결합하는 방법을 정의한다. 대부분 엔터프라이즈 시스템은 여러 아키텍처 스타일을 결합해서 적용해야 한다. 아키텍처 패턴(스타일)라는 개념을 세우고 처음으로 정리한 사람들 소프트웨어 아키텍처

아키텍처 스타일이란? Ivar Jacobson 아키텍처 스타일은 모델링 언어의 외연(外延, denotation)이다. 아키텍처와 아키텍처 스타일을 시스템 개발에 들어가는 모든 모델링 접근법과 동일하다. 제이콥슨은 건축학과 비슷하게 아키텍처 스타일이 시스템 기초가 되면서 모든 모델링 과정을 지배한다고 주장했다. 방법 : 아키텍처를 적용하기 위해 따라야 하는 자세한 절차 공정 : 아키텍처에 따라 시간과 인력을 배분하는 방법 도구 : 아키텍처, 방법, 공정을 지원하고 실현 가능하게 하는 것 건축학에서 아키텍처 스타일이 외관, 내부장식, 가구까지 결정해서 그 안에 사는 사람들의 생활에도 영향을 미치는 것처럼 소프트웨어 공학의 아키텍처 스타일도 소프트웨어 개발 전 과정을 주도한다고 주장한다. 소프트웨어 아키텍처

아키텍처 스타일이란? Richard Hubert 소프트웨어 아키텍처 Richard Hubert : Convergent Architecture 저자 아키텍처 메타모델, 개발모델, 도구, 기술 적용을 IT 아키텍처 스타일이라고 함. 아키텍처 메타모델 : 제이콥슨이 이야기한 아키텍처 스타일과 같은 개념 개발 모델 : 아키텍처 메타 모델을 실현할 수 있는 방법을 제시하는 모델 도구 : 개발 모델을 지원한다. 기술 적용 : MDA를 지원하기 위해 도입한 요소로 구체 구현 기술을 적용한다. 개발 모델에 기술을 적용하면 완성품이 탄생한다. 소프트웨어 아키텍처

아키텍처 스타일이란? 아키텍처의 재사용 소프트웨어 아키텍처 아키텍처에서 쓸모는 아키텍처의 Domain-specific 부분으로 같은 문제영역에서 재사용할 수 있다. 짜임새는 여러 문제영역에 적용할 수 있는 부분이다. 예를 들어, Client/Server 아키텍처는 은행에서도 쓸 수 있고 학교에서도 쓸 수 있다. 아키텍처 스타일은 바로 이 짜임새를 기반으로 한다. 소프트웨어 아키텍처

아키텍처 스타일과 아키텍처 설계 아키텍처 스타일과 아키텍처 설계는 어떤 관계가 있을까? 아키텍처 스타일은 아키텍처 설계와 어떻게 연결될까? 소프트웨어 아키텍처

ABAS 아키텍처 스타일에 아키텍처 설계의 근거를 제공하는 프레임워크(근거 프레임워크, reasoning framework)를 결합한 것이다. 근거 프레임워크는 속성 특화 모델(attribute-specific model)에 기반을 둔다. ABAS는 한 번에 한 품질속성을 다룬다. <예> 성능과 가용성을 달성하는 데 좋은 아키텍처 스타일이 있다면 성능 ABAS와 가용성 ABAS를 만든다. 기존 아키텍처 스타일이 단순히 품질속성에 기반을 둔 것이라면 ABAS는 특정 품질속성에 특화된 것으로 아키텍처 스타일이 특정 품질속성을 달성하는 방법까지 설명한다. Attribute-Based Architectural Style SEI에서 1999년 처음 소개한 개념이다. http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html 소프트웨어 아키텍처

ABAS ABAS의 구조 소프트웨어 아키텍처 자극과 반응 측정 : 근거를 밝히고 통제하고 특정하고 싶은 자극과 반응을 정의한다. 아키텍처 스타일 : 문제를 해결하기 위한 구성요소들과 이 구성요소들의 관계를 설명한다. 실제 프로젝트에서 아키텍처를 설계하기 위해 아키텍처 스타일을 기술해야 한다면, 아키텍처 스타일을 적용할 때 결정해야 하는 중요한 아키텍처 판단 사항을 기술한다. 분석 : 자극/반응과 아키텍처 스타일의 관계를 설명한다. 소프트웨어 아키텍처

아키텍처 스타일 예제 David Garlan과 Mary Shaw 소프트웨어 아키텍처

아키텍처 스타일 예제 POSA 소프트웨어 아키텍처 아키텍처 스타일 하나 하나는 별도 문서 020B.아키텍처 분석과 설계 – Appendix B.아키텍처 스타일.ppt 참고 소프트웨어 아키텍처

요약 패턴이란 여러 문제들이 경쟁하는 상황에서 특정 문제에 대한 반복해서 나타나는 해결책을 문서화한 것이다. 패턴은 설계 생산성을 높이고 문제와 해결책을 문서화해서 문제 영역에서 쓰는 어휘와 언어를 정의한다. 패턴 언어는 개별 패턴으로는 해결하기 힘든 복잡한 문제를 해결하고자 패턴들을 일정한 규칙에 따라 모아 놓은 것이다. 패턴과 패턴 언어는 은 소프트웨어 공학의 기본 어휘와 언어로 소프트웨어 공학의 거의 모든 분야에 패턴이란 개념이 적용된다. 소프트웨어 아키텍처

요약 아키텍처 스타일은 아키텍처라는 좀 더 넓고 전체를 다루는 분야에 패턴을 적용한 것이다. 아키텍처 스타일은 시스템의 모든 설계 작업의 기초를 제공한다. ABAS는 아키텍처 스타일에 근거 프레임워크를 결합한 것으로 특정 품질속성을 달성하는 방법까지 설명한다. 소프트웨어 아키텍처