Patterns in “PATTERN-ORIENTED SOFTWARE ARCHITECTURE”

Layer A.P. 어플케이션을 구조화하기 위해 서브 태스크(Subtask)들을 그룹으로 묶기 위해 분해한다. 공통된 추상 레벨에 있는 서브 태스크들끼리 묶어서 그룹으로 분류한다.

Pipes and Filters A.P. 데이터 스트림을 처리하는 시스템 구조를 제공한다. 각 프로세싱 단계는 필터 컴포넌트로 추상화한다. 데이터는 파이프를 통해 연관된 필터들에게 전달된다. 필터들을 다양하게 재조합하여 시스템을 재구축할 수 있다.

Blackboard A.P. 정의되지 않은 도메인에서의 문제를 해결할때 유용하다. 솔루션에 대한 부분적이거나 대략적인 해법을 수립하기 위해 몇가지 특수한 서브시스템들의 지식을 조합한다.

Broker A.P. 분산 소프트웨어 시스템을 구조화할때 유용하다. 분산 소프트웨어 시스템은 분리된 컴포넌트들이 서로 유기적으로 조합되어 운영되는 시스템으로, 이러한 컴포넌트들 간의 통신을 관장하는 역활을 하는 것이 Broker이다.

Model-View-Controller A.P. 모델은 핵심기능과 데이터를 의미하고 뷰는 기능에 의한 데이터의 표현이며 컨트롤은 사용자의 입력에 대한 처리이다. 뷰와 컨트롤러는 사용자의 인터페이스를 구성하며 사용자 인터페이스와 모델간의 일관성 및 정합성을 보장한다.

Presentation-Abstraction-Control A.P. 계층구조를 이루는 에이전트들이 상호작용하는 소프트웨어 시스템에 대한 패턴. 각각의 에이전트는 하나의 어플리케이션의 특정 부분을 전담하며 에이전트는 프리젠테이션/추상/컨트롤로 구성된다.

Microkernel A.P. 변화하는 시스템에 대한 요구사항을 수용할 수 있도록 하는 패턴. 시스템에서 가장 최하단에 위치하는 핵심 기능을 추출해 내며, 추가된 요구사항에 대해 확장기능으로 정의하여 시스템에 손쉽게 추가할 수 있도록 한다.

Reflection A.P. 소프트웨어 시스템의 구조와 동작을 동적으로 변경할 수 있는 메커니즘을 제공.

Whole-Part D.P. 전체(Whole) 객체를 구성하는 컴포넌트(Part)를 정의한다. Whole 객체를 통해 Part 컴포넌트들의 관계를 맺으며, 이 Whole 객체를 통해서만 Part 컴포넌트와 통신할 수 있다.

Master-Slave D.P. 마스터 컴포넌트는 슬레이브 컴포넌트에게 작업을 분산시켜서 최종적으로 슬레이브로부터 그 결과를 취합한다.

Proxy D.P. 실제 컴포넌트가 아닌 대리자를 앞단에 두어 이 대리자를 통해 실제 컴포넌트와 통신을 한다. 실제 컴포넌트의 위치 추상화, 실제 컴포넌트를 사용하기 위한 인증 등과 같은 전처리는 물론 후처리에 대한 기능 추가가 용이하다.

Command Processor D.P. 사용자의 요청을 하나의 객체로 정의하여 관리하며 Undo/Redo와 같은 처리가 가능하다.

View Handler D.P. 시스템의 모든 뷰를 관리하는 책임을 분리하여 뷰들 간의 관계성과 연관된 작업을 쉽게 처리할 수 있도록 한다.

Forwarder-Receiver D.P. 투명한 IPC를 제공하고 Peer를 분리하기 위해 Forwarder와 Receiver를 분리한다.

Client-Dispatcher-Server D.P. 클라이언트와 서버 사이에 디스패처 레이어를 도입한다. 위치 투명성을 제공하고 클라이언트와 서버간의 통신에 대한 세부적인 구현을 캡출화한다.

Publisher-Subscriber D.P. 서로 긴밀하게 관계를 맺고 있는 컴포넌트들 간의 상태에 대해 정합성을 유지하는데 용이하다. Publisher가 책임을 지고 하나의 변경에 대해 다수의 Subscriber에게 변경을 통지한다.

프로그래밍 문제 해결 체크 리스트

오랜만에 포스팅 합니다. 이곳을 방문하시는 분들 중에 소수의 분들은 아시겠지만, 제가 결혼을 하고 지난주 월요일에 신혼 여행을 다녀온 후에.. 외부 프로젝트에서 열심히 작업에 한창인지라, 블로그에 글 하나 올릴 여유가 없는듯합니다.

고로… 다시금 블로그에 글을 올리기 위한 동기 마련을 위해 금주 월요일, 오늘 글을 하나 올려 보려고 합니다. 딱히 요즘 작업에 여념이 없어, 새로운 학습이 없어 올릴만한 주제가 없긴한데요.. 그래서 요즘 개발하고 있는 컴포넌트에 대한 오류의 디버깅을 하던 차에.. 문제점 해결을 위해 이렇게 하면 좋겠구나 하는 제 경험적인 내용을 간단히 정리하려고 합니다.

먼저 문제점이 발생했을 경우, 그 문제점에 대한 현상을 구체적이고 정확히 서술 해줘야합니다. 그 다음으로 이 현상을 발생시켰던 사용자의 행위를 단계별로 정리해야 합니다. 물론 사용자의 행위가 없는 경우가 있습니다. 예를 들어… 프로그램이 가만이 있는데, 다운된다거나 하는 등.. 그리고 다음으로는 문제 현상을 발생시키는 프로그램 코드의 위치를 파악해야 합니다. 그리고 현상과 사용자의 행위 그리고 문제가 되는 코드를 힌트로 해서 문제점의 원인을 추정해 봅니다. 일단 추정이므로 추정 원인은 여러개가 나올 수 있겠습니다. 이 추정 리스트를 통해서 확인해 가면서 맞아 떨어지는 추정을 해결하면 문제점이 해결되겠지요. 여기서 중요한 것은 해결방법을 최종적으로 구체적으로 정리해서 추후에 동일한 문제점이 발생했을때 동일한 실수를 범하지 말아야한다는 점입니다.

정리해보면, 프로그래밍 문제 해결 체크 리스트 항목으로…

  1. 문제점에 대한 현상
  2. 문제의 현상을 일으키는 사용자 행위
  3. 문제가 되는 프로그램 코드 위치
  4. 문제점의 원인 추정
  5. 추정에 대한 해결방법

이번주는 프로그램에 대한 버그 수정에 곯머리를 앓을것같아서, 막무가내로 버그를 잡지 말고 체계적으로 해결해자는 취지에서 이 글을 올려봅니다. 물론, 오랜만에 블러그에 글을 포스팅하는 이유도 있지만 말입니다.