본문 바로가기
Homo Architect

컴포넌트 클러스터링 [1]

by javauser 2008. 11. 5.
1. 정의
컴포넌트는 객체들의 집합으로 이루어진다. 즉, 객체들의 묶음(clustering)을 통해서 컴포넌트를 구성한다. 따라서, 컴포넌트 클러스터링이란 객체들을 어떤 기준으로 묶어서(clustering) 컴포넌트를 만든다 라는 의미이다. 기업은 비즈니스 목적에 따라 다양한 클러스터링 방식이 존재할 수 있다. 따라서 클러스터링 방식에 대한 공감대를 형성하는 것이 컴포넌트 기반 개발의 첫걸음이라고 할 수 있다.

클러스터링은 문제 영역(problem area)을 서로 독립된 (independent) 세부 영역 (sub-area)로 나누는 것으로, 상호 작용 (interaction) 을 최대한 줄이고 (병행하거나 순차적인 방법 등으로), 통합에 대한 위험성을 최대한 줄여주는 목적을 가지고 있다. 클러스터링을 하고자 하는 자의 관점이나 특별한 목적에 의해서, 객체 (object) 를 같이 묶는 방법과 객체들의 집합을 세부 집합으로 나눈 방법 모두를 의미한다. 이러한 더 작은 집합이나 세부 집합을 '클러스터(cluster)' 라고 하며, '클러스터링(clustering)' 이라는 용어 자체는 일련의 관련된 클러스터들을 정의하는 절차, 혹은 이러한 절차에 의한 결과, 즉, 일련의 클러스터를 의미한다. 각각의 클러스터는 설계 프로젝트나, 부서의 책임성 등이 어떠한 것을 포함하고 있는지를 열거함으로써 이러한 것들의 범위를 정의하는데 사용될 수 있다. ([Very94])

컴포넌트 클러스터링은 비즈니스 드라이버가 명확하게 식별될수록 기준이 세분화된다. 따라서, 초기의 컴포넌트 클러스터링 원칙은 컴포넌트 명세가 완료되는 시점까지 지속적으로 갱신되어야 한다.

2. 원칙 수립
클러스터링 원칙을 수립하기 위해 먼저 비즈니스 컨텍스트를 분석하고, 그 결과로 바탕으로 컴포넌트화를 하고자 하는 비즈니스 측면의 이유인 비즈니스 드라이버를 식별한다. 비즈니스 드라이버는 조직의 비즈니스 특성과 목표에 따라 "재사용성 증대", "생산성 향상", "의사소통 향상", "IT 자원 절약" 등 다양할 수 있다.
클러스터링 원칙을 적용하는 절차는 그림2-1과 같다. 비즈니스 모델링 결과를 바탕으로 클러스터링 원칙을 적용하여 비즈니스 객체들의 클러스터를 구성한 후 클러스터링 원칙을 기준으로 클러스터의 타당성을 검토한다. 타당성이 부족하면 비즈니스 문제 분석 단계나 비즈니스 모델링 단계로 돌아가 추가 및 보완 작업을 수행한다. 타당성이 충분하면 이 클러스터는 비즈니스 컴포넌트로 식별되고 관리된다.

그림 2-1. 컴포넌트 클러스터링 원칙 적용 절차

클러스터링 목적
  • 범위(scoping)는 통상 전체 문제 영역을 작은 객체로 쪼개어서 응집성이 있는 하위 문제를 형성하도록 객체들을 같이 클러스터링함으로써 설정된다. 클러스터링의 목적은 함께 수행될 수 있는 객체끼리 같이 그룹핑하는 것이다. 예를 들어, 수많은 조그만 크기의 서로 연결된 문제들로 구성된 커다란 복잡한 문제를 관련이 있는 문제들의 몇몇 그룹으로 나누는 것이다. 그러한 클러스터링에 따라서 일반적으로 업무를 구조화시키고, 책임성을 클러스터링에 부여한다. 다른 클러스터링과는 상관없이 해당 클러스터에 최소한 몇가지 계획으로 설계 결정을 가하려고 한다. 이와 같이 클러스터링이 되면 한가지 클러스터에 대해서 집중적으로 분석 설계를 할 수 있다. 이처럼 클러스터링은 문제 영역에 대해서 범위를 한정하여 구획할 수 있고, 이는 상품화할 수 있는 기반을 마련해주며, 새로운 버전이나 릴리즈로 기능을 강화할 수 있는 계기를 마련한다.
좋은 클러스터링의 기준 (criteria)
  • 좋은 클러스터링은 상호작용(개발과 운영시)을 최소화시키고, 통합 위험성(예를 들어, 업무와 기술에 대한 조화 요구 부합의 실패)을 줄인다. 좋은 클러스터링에서, 각각의 클러스터는 높은 응집력 (highly coherent)을 가지며, 클러스터간에 오버랩이나 커플링이 거의 없다. 두 클러스터 사이 보다 한 클러스터 내에서 유사성과 친밀도가 더 나타난다.
  • 크기에 대한 견고성(consistency)이 추가적인 기준으로 제시되기도 한다. 즉, 각각의 클러스터는 거의 동일한 크기가 될 수 있다. 이것은 상호작용이나 통합 위험성과는 상관이 없다. 비슷한 크기로 클러스터링을 하는 것이 때로는 편리할 수도 있겠지만, 어떤 경우에는 불편할 수도 있다. 예를 들어, 당신이 회사의 사장이고, 비슷한 능력과 경험, 실력을 가진 프로젝트 관리자를 부하직원으로 가지고 있다면, 그들에게 동일한 양의 업무를 줄 것이지만, 능력이나 경험, 실력이 전부 다른 프로젝트 관리자한테는 그들의 능력이나 실력에 맞게 소화할 수 있는 업무를 부여할 것이다. 어느 경우든, 크기만으로 응집력이 있고, 견고한 클러스터링 기준이 될 수 없다.




반응형

'Homo Architect' 카테고리의 다른 글

Component Refactoring [1]  (0) 2008.11.12
컴포넌트 클러스터링 [5]  (0) 2008.11.06
컴포넌트 클러스터링 [4]  (0) 2008.11.06
컴포넌트 클러스터링 [3]  (0) 2008.11.06
컴포넌트 클러스터링 [2]  (0) 2008.11.06