free-vahn

본문

objectworld.org에 종호님 질문(패턴 랭귀지가 되려면 어떤 걸 만족시켜야 하나요?)에 대한 답.

안녕하세요? 종호님..... UML1 스터디에 안 나간지 오래되서 얼굴 못 뵌지 꽤 됐네요..
잘 지내시죠???

패턴 랭귀지의 조건을 규정하기란 퍽 힘든 일 같습니다. 그렇기 때문에 대부분 개념에 대한 정의는 규정 보다는 직유로 많이 표현하고 또, 정의되었다 해도 단체나 학회마다 의견이 다를 뿐더러 너무 추상적이어서 정확한 이해를 유도하기 힘듭니다. - 아마도 오류, 예외 가능성을 배제하다 보니 추상화 레벨이 엄청 높은 정합적 정의를 내리지 않나 싶습니다.

이런 전차로 저 또한 패턴 랭귀지에 대한 '이미지 설명' 정도 밖에 못 할 것 같은데요...


"The limits of my language are the limits of my world." - Ludwig Wittgenstein or "No Pattern is an Island"


패턴 랭귀지를 묘사 할 때 흔히 'Domain Specific Language'라고 합니다.
특정 도메인에 등장하는 패턴들의 집합으로서 도메인의 지적, 경험적 자산을 정리해놓은 거라 할 수 있습니다.
그렇기 때문에 패턴 랭귀지는 단순히 특정 도메인에 등장하는 패턴들을 서술 하지 않고 패턴들 간의 관계를 정의하고 있습니다. (No Pattern is an Island)
하지만 "No Pattern is an Island"란 단어는 그다지 생경하지 않지요? GoF의 Design Patterns 에서도 등장한 개념입니다.
GoF의 Pattern Vocabulary 개념과 다른 점은 패턴 랭귀지에 와서는 특정 도메인에 등장하는 문제점과 다른 문제점들의 상호관계를 정의합니다.
그리고 그대로 그 문제점을 해결할 수 있는 패턴들과 다른 패턴들간의 관계로 매핑시킵니다.
즉, 하나의 Problem과 패턴의 관계는 1:1..n 의 관계가 되며 이 (1..n 개의) 패턴들이 다른 Problem에 대한 (1..n 개의) 패턴들과 상호관계를 갖게됩니다.
이렇게 유기적으로 구성된 특정 도메인의 패턴 집합체를 패턴랭귀지라고 합니다.

상술했던 비트겐슈타인의 말에서 어림잡을 수 있듯이 이런 각각의 (도메인에 대한) 패턴 랭귀지를 정복한다면 소프트웨어 시스템이라는 거대한 체계에 대한 지평이 넓어지겠죠...


패턴들간의 관계


패턴 랭귀지의 패러다임에 들어서면서 패턴에 대한 자산이 꽤 많아졌습니다. 그러다 보니 전술했던 것 처럼 하나의 Problem에 하나 이상의 Pattern이 등장하게 되고 패턴들간의 관계도 다양하게 구성될 수 있는데요..
패턴 랭귀지의 특징 중 하나가 이 패턴들의 다양한 관계에 있습니다. 그 '관계'들을 설명하자면 대충 다음과 같습니다.

1) 상생할 수 없는 관계 (재하옹에 의하면 경쟁관계) :
    하나의 Problem에 대한 같은 Solution을 갖는 패턴들의 관계입니다. 그렇기 때문에 개발자는 각 패턴의 Force에 따라서 하나의 패턴만 선택하게 되죠..

2) 포함 관계 :
    하나의 패턴이 존재하기 위해서 다른 패턴(들)을 사용하는 경우입니다. Architectural Pattern과 Design Pattern의 관계가 이런 형태를 보이는데요... 이를테면 MVC 패턴은 이벤트 전달을 위해 Observer 패턴을 사용하고 또, 메시지의 detail한 부분과 처리의 추상화를 위해 Command를 사용하죠...

3) 사용 관계 :
    패턴이 처리를 위해 다른 패턴을 사용하는 경우입니다. 2번의 [포함 관계]와 다른 점은 2번의 패턴들의 관계가 Aggregation 관계 라면 3번의 관계는 Association 관계 정도 되며 2번은 '구성'의 (sub 패턴이) 필수 요소인 반면 3번의 경우는 '처리'의 관점에서 다른 패턴을 사용합니다. POSA2의 예로 Reactor가 Connection에 대한 처리를 위해 Acceptor-Connector를 사용하는 경우입니다. - 2,3번의 다른점을 정확히 표현하기 힘들군요.. ^^;

4) 인접 관계 :
    패턴들 간의 Sequencial Cohesion을 갖는 경우입니다. J2EE 패턴의 경우 Business Delegate에서 클라이언에게 비즈니스 서비스 인터페이스를 제공하고 Business Delegate는 실제 서비스 처리를 위해 Session Facade에게 위임하는 경우입니다.

끝으로 Douglas C. Schmidt 박사는 패턴들간의 관계를 위해서 다음 두가지 스텝을 밟는다고 합니다.
1) Identify pattern relationships.
2) Define pattern ordering.