[BOOK Summary] 패턴 지향 소프트웨어 아키텍쳐 : Volume 1(POSA1) - Chaper 01.패턴

[Design & Method]
여기에서 제공하는 요약 정보는 제 개인적으로 책을 읽고 정리한것입니다. 추호도 책의 저작권을 침해할 뜻이 없으며 이 글을 읽으시는분도 분명 참고만 하시길 바라며 꼭 서점에서 책을 구매하서서 읽어 보시길 권해 드립니다.

저자 : Frank Buschmann , Regine Meunier , Hans Rohnert , Peter Sommerlad , Michael Stal
역자 : 김지선
감수 : 데브피아 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 모델을 통한 소프트웨어 아키텍처 패턴에 대한 몇가지 특징 도출
    1. 패턴은 특정 설계 상황에서 반복적으로 설계 문제를 제기하며 그 문제에 대한 해법을 제시한다.
      • MVC 모델이 해결하고자 하는 문제는 사용자 인터페이스 변하기 쉽다는 것
      • 이 문제를 해결하기 위해서는 책임(responsibility)를 엄밀히 구분하는것
    2. 패턴은 기존에 이미 입증된 설계 경험을 정리한 것이다.
    3. 패턴은 클래스와 인스턴스의 레벨(혹은 컴포넌트의 레벨) 보다 상위의 추상 수준에서 정의된다.
    4. 패턴은 설계 원칙에 대한 공통 어휘(vocabulary)와 공감대를 형성시켜 준다. → 개발자간의 커뮤니케이션
    5. 패턴은 소프트웨어 아키텍처를 체계적으로 문서화하여 정리하는 방법을 제공한다.
    6. 패턴은 소프트웨어 아키텍처 분야에서 정의한 고유 특성(property)들에 근거해 소프트웨어를 개발할 수 있도록 지원한다.
    7. 패턴은 복잡하고 이질적인(heterogeneous) 소프트웨어 아키텍처를 구축하는 데 도움을 준다.
      • 패턴은 “복잡한 설계를 위한 빌딩블록(building-block) 역할을 한다.” [GHJV93]
    8. 패턴을 사용하면 소프트웨어 복잡도를 관리하는 데 유용하다.
  • 그래서 패턴은을 최종적으로 정리하자면 “특정 설계 정황(design context)에서 반복해서 발생하는 설계 문제를 다루며 그 해법(solution)에 대한 검증된 일반 스키마를 제공한다. 해법 스키마는 ①그 해법을 구성하는 컴포넌트들, ②컴포넌트들의 책임과 관계, ③컴포넌트들의 책임과 관계, ④컴포넌트들 간의 협력 방법을 서술하는 기준이 된다.”

1.2 패턴은 무엇으로 구성되는가?

  • 모든 패턴이 기본적으로 지켜야 할 세가지
    1. 정황(context)
      • 패턴에 적용할 모든 상황을 정리한다는 것은 사실상 불가능하다.
    2. 문제(problem)
      • 정황에서 반복적으로 발생하는 영향력(force)들
    3. 해법(solution)
      • 반복해서 발생하는 문제를 해결하는 방법
      • 문제와 관련된 영향력들이 균형(balance)을 이루는 방법을 설명
      • 소프트웨어 아키텍처에서 해법은 두가지 측면을 포함한다.
        1. 패턴의 해법은 패턴의 특정 구조, 즉 요소들의 공간적 구성(spatial configuration)을 정의 – 정적(static)
        2. 패턴의 해법은 런타임에 어떻게 동작하는지 정의 – 동적(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) 역할을 한다.
  • 패턴의 역량을 한껏 이용하려면 각 패턴을 고립적으로 바라보는 시야를 넘어서서 기술적이고 방법론적인 지원이 필요하다.
2009/03/12 01:20 2009/03/12 01:20

이 글의 트랙백 주소 :: http://radicaled.org/blog/trackback/25

::: 사람과 사람의 교감! 人터넷의 첫 시작! 댓글을 달아주세요! :::

  1. 나그네 [2009/03/12 15:05]  [댓글주소]  [수정/삭제]  [댓글쓰기]

    예전에 한번 읽었는데 요약본을 보니 또 감회가 새롭네요~ 잘 읽을께요~ 감사합니다. ^^

[로그인][오픈아이디란?]