여기에서 제공하는 요약 정보는 제 개인적으로 책을 읽고 정리한것입니다. 추호도 책의 저작권을 침해할 뜻이 없으며 이 글을 읽으시는분도 분명 참고만 하시길 바라며 꼭 서점에서 책을 구매하서서 읽어 보시길 권해 드립니다.
저자 : Frank Buschmann , Regine Meunier , Hans Rohnert , Peter Sommerlad , Michael Stal
역자 : 김지선
감수 : 데브피아 EVA 스터디 팀
출판사 : 지앤선
ISBN : 9788955508727
기타 : 번역서 / 2008-01-18 / 528 쪽
역자 : 김지선
감수 : 데브피아 EVA 스터디 팀
출판사 : 지앤선
ISBN : 9788955508727
기타 : 번역서 / 2008-01-18 / 528 쪽
1.1 패턴이란 무엇인가.?
- 문제-해법(Problem-Solution) 쌍의 방식으로 접근하는 전문가들의 습관~~
- “각 문제-해법 쌍들에 따라 비슷한 문제와 해법을 가진 집합들로 분류되는데, 분류된 각 집합은 문제와 해법으로 이루어진 하나의 패턴을 형성한다”[Joh94]
- 크리스토퍼 알렉산더(Cristopher Alexander)가 패턴이라는 용어의 정리
- 각 패턴은 정황(context), 문제(problem), 해법(solution), 이렇게 세부분으로 이루어진 하나의 규칙으로, 이 규칙은 각 부분들의 관계를 표현해야 한다.
- 실제 세게의 한 요소로서, 각 패턴은 특정 정황, 그 정황에서 반복적으로 발생하는 영향력의 체계(system of forces), 이 영향력들을 해소해주는 공간 구성(spatial configuration), 이렇게 세가지 관계로 구성된다.
- 즉 실제 세계에 존재하는 어떤 사물이며, 어떻게 그것을 생성하는지 그리고 언제 그것을 생성해야 하는지 말해주는 규칙이다. 그것은 과정(process)이자 동시에 사물(thing)이다. 살아있는 사물로도 설명할 수 있으며, 그 사물이 생성되는 과정으로도 설명할 수 있기 때문이다.
- MVC 모델을 통한 소프트웨어 아키텍처 패턴에 대한 몇가지 특징 도출
- 패턴은 특정 설계 상황에서 반복적으로 설계 문제를 제기하며 그 문제에 대한 해법을 제시한다.
- MVC 모델이 해결하고자 하는 문제는 사용자 인터페이스 변하기 쉽다는 것
- 이 문제를 해결하기 위해서는 책임(responsibility)를 엄밀히 구분하는것
- 패턴은 기존에 이미 입증된 설계 경험을 정리한 것이다.
- 패턴은 클래스와 인스턴스의 레벨(혹은 컴포넌트의 레벨) 보다 상위의 추상 수준에서 정의된다.
- 패턴은 설계 원칙에 대한 공통 어휘(vocabulary)와 공감대를 형성시켜 준다. → 개발자간의 커뮤니케이션
- 패턴은 소프트웨어 아키텍처를 체계적으로 문서화하여 정리하는 방법을 제공한다.
- 패턴은 소프트웨어 아키텍처 분야에서 정의한 고유 특성(property)들에 근거해 소프트웨어를 개발할 수 있도록 지원한다.
- 패턴은 복잡하고 이질적인(heterogeneous) 소프트웨어 아키텍처를 구축하는 데 도움을 준다.
- 패턴은 “복잡한 설계를 위한 빌딩블록(building-block) 역할을 한다.” [GHJV93]
- 패턴을 사용하면 소프트웨어 복잡도를 관리하는 데 유용하다.
- 패턴은 특정 설계 상황에서 반복적으로 설계 문제를 제기하며 그 문제에 대한 해법을 제시한다.
- 그래서 패턴은을 최종적으로 정리하자면 “특정 설계 정황(design context)에서 반복해서 발생하는 설계 문제를 다루며 그 해법(solution)에 대한 검증된 일반 스키마를 제공한다. 해법 스키마는 ①그 해법을 구성하는 컴포넌트들, ②컴포넌트들의 책임과 관계, ③컴포넌트들의 책임과 관계, ④컴포넌트들 간의 협력 방법을 서술하는 기준이 된다.”
1.2 패턴은 무엇으로 구성되는가?
- 모든 패턴이 기본적으로 지켜야 할 세가지
- 정황(context)
- 패턴에 적용할 모든 상황을 정리한다는 것은 사실상 불가능하다.
- 문제(problem)
- 정황에서 반복적으로 발생하는 영향력(force)들
- 해법(solution)
- 반복해서 발생하는 문제를 해결하는 방법
- 문제와 관련된 영향력들이 균형(balance)을 이루는 방법을 설명
- 소프트웨어 아키텍처에서 해법은 두가지 측면을 포함한다.
- 패턴의 해법은 패턴의 특정 구조, 즉 요소들의 공간적 구성(spatial configuration)을 정의 – 정적(static)
- 패턴의 해법은 런타임에 어떻게 동작하는지 정의 – 동적(dynamic)
1.3 패턴 카테고리
- 아키텍처 패턴(architectural pattern)
- 정의 : 소프트웨어 시스템의 기본 구조를 구성하기 위한 스키마를 다룬다. 이 패턴은 미리 정의된 서브 시스템들을 제공하고 각 서브시스템들의 책임을 정의 하며 서브시스템들 간의 관계를 조직화하는 규칙과 가이드라인을 포함한다.
- 소프트웨어 시스템을 개발할 때 어떤 아키텍처 패턴을 선택하는가는 기본 설계 결정에 막대한 영향을 미친다.
- MVC 패턴은 아키텍처 패턴 중에 가장 잘 알려진 예~
- 디자인 패턴(design pattern)
- 정의 : 소프트웨어 시스템의 서브시스템이나 컴포넌트들, 혹은 그것들 간의 관계를 정의하기 위한 스키마를 제공한다. 디자인 패턴은 특정 정황 내에서 일반적인 설계 문제를 해결하며, 통신하는 컴포넌트들 간의 반복적으로 발생하는 구조를 서술한다.
- 디자인 패턴은 중간 규모(medium-scale)의 패턴
- 아키텍처 패턴보다 규모는 작지만 특정 언어나 프로그래밍 패러다임에 종속되는 경향을 나타내지 않음
- 대부분의 디자인 패턴은 복잡한 서비스나 컴포넌트를 분해하기 위한 구조를 제공
- 그 외 디자인 패턴은 패턴들 간의 협력이 효율적으로 이루어 질 수 있는 방법을 제공(예, Observer 디자인 패턴, Publisher-Subscriber 디자인 패턴)
- 이디엄(idiom)
- 이디엄은 특정 설계 이슈를 다룬다.
- 정의 : 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴(low-level pattern)이다. 이디엄은 주어진 언*어의 기능을 사용해서 컴포넌트들 간 관계의 특정 측면을 구현하는 방법을 서술한다.
- 그래서 이디엄은 설계(design)와 구현(implementation), 이 두가지 측면을 해결한다.
1.4 패턴 간의 관계
- 패턴 내에 있는 컴포넌트들과 그것들 간의 관계는 항상 원자적(atomic) 이지만은 않다.
- 다시 말해 패턴 내에 있는 컴포넌트들, 그리고 컴포넌트들의 관계는 항상 더 이상 쪼개지지 않는 최소 단위가 아니라는 의미임
- ‘Each pattern depends on the smaller patterns it contains and on the larger patterns in which it is contained’ [Ale79]
- 번역서에 오역이 있는것 같은데 → 개별 패턴은 그것을(그것이가 맞을듯) 포함하고 있는 더 작은 패턴에, 그리고 그것을 포함하고 있는 더 큰 패턴에 종속된다.
- 또한 패턴은 다른 패턴의 변형이 될 수도 있다.
1.5 패턴 서술
- 이름(name)
- 별칭(also known as)
- 예제(example)
- 정황(context)
- 문제(problem)
- 해법(solution)
- 구조(structure)
- 동작(dynamic)
- 구현(implementation)
- 예제 심화(example resolved)
- 변형(variant)
- 용례(known use)
- 결과(consequence)
- 관련 자료(see also)
1.6 패턴과 소프트웨어 아키텍처
- 패턴은 소프트웨어 공학의 목표와 적절히 일치해야 한다.
- 정신적 빌딩블록 역할을 하는 패턴
- “소프트웨어 아키텍처 분야에서 정의한 고유 특성(property)들에 근거해 소프트웨어를 구축해야 한다.”
- 패턴은 특수한 문제에 국한되지 않는 일반적인 아키텍처 기법을 특수한 문제 지향(problem-oriented) 아키텍처 기법으로 보완한다.
- 여러 패턴을 적용한 복합 아키텍처의 구축
- 대규모 소프트웨어 아키텍처의 요구 사항에 부합하려면 복잡다기한 설계 문제를 해결하기 위해 풍부한 패턴 집합이 필요하다.
- 그러므로 효과적으로 패턴을 사용하기 위해 패턴들을 패턴시스템(pattern system)으로 조직화 할 필요가 있다.
- 패턴 vs. 방법론
- 패턴 서술서에서의 가이드는 마이크로 방법론(micro-method), 이는 분석-설계 방법론에 비해 좀더 특정 문제에 포커싱되어 있다.
- 패턴 구현
- 패턴을 구현하기 위한 패러다임이나 언어가 단 하나만 존재하는 것은 아니라는 사실이다.
- 패턴은 소프트웨어 아키텍처를 구축할 때 사용되는 모든 패러다임과 함께 통합될 수 있다.
1.7 요약
- 패턴 전체는 애플리케이션의 기능적 요구사항(funtional requirement)과 비기능적 요구사항(non-funtional requirement) 모두에 적합한 소스트웨어를 구축하는 정신적인 도구상자(mental toolbox) 역할을 한다.
- 패턴의 역량을 한껏 이용하려면 각 패턴을 고립적으로 바라보는 시야를 넘어서서 기술적이고 방법론적인 지원이 필요하다.
"Design & Method" 분류의 다른 글
| [BOOK Summary] 소프트웨어 컨플릭트 2.0 - PART 2. 기술 진영에서 (0) | 2008/10/16 |
| [BOOK Summary] 소프트웨어 컨플릭트 2.0 - PART 1. 논쟁의 장 (0) | 2008/10/14 |
| [BOOK Summary] Code Complete 2th - PART 2. 고급코드 생성하기 (0) | 2008/10/11 |
| [BOOK Summary] Code Complete 2th - PART 1. 기초수립 (0) | 2008/10/11 |
| [BOOK Summary] REFACTORING - 1 (2장. 리팩토링의 원리 & 3장. 코드에서의... (0) | 2008/10/11 |





::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::
예전에 한번 읽었는데 요약본을 보니 또 감회가 새롭네요~ 잘 읽을께요~ 감사합니다. ^^