비즈니스 컴포넌트 식별 및 구조(3) - 컴포넌트 클러스터링

컴포넌트 클러스터링

컴포넌트는 객체들의 집합으로 이루어지며, 객체들의 묶음(clustering)을 통해 컴포넌트가 구성되며, 컴포넌트 클러스터링이란 객체들을 어떤 기준으로 묶어서 컴포넌트를 만든다는 의미이다. 클러스터링은 문제 영역(problem area)을 서로 독립된 세부 영역(sub-area)으로 나누는 것으로, 상호작용을 최대한 줄이고 (병행하거나 순차적인 방법 등으로), 통합에 대한 위험성을 최대한 줄여주는 목적을 가지고 있다. 클러스터링을 하고자 하는 자의 관점이나 특별한 목적에 의해서, 객체를 같이 묶는 방법과 객체들의 집합을 세부 집합으로 나눈 방법 모두를 의미한다. 각각의 클러스터는 설계 프로젝트나, 보서의 책임성 등이 어떠한 것을 포함하고 있는지를 열거함으로써 이러한 것들의 범위를 정의하는데 사용될 수 있다.

컴포넌트 클러스터링의 목적은 함께 수행될 수 있는 객체끼리 같이 그룹핑하는 것으로, 수많은 조그만 크기의 서로 연결된 문제들로 구성된 커다란 복잡한 문제를 관련이 있는 문제들의 몇몇 그룹으로 나누는 것이다. 좋은 클러스터는 높은 응집력(highly cohesion)을 가지며, 클러스터간에 오버랩이나 커플링이 거의 없다. 컴포넌트 클러스터링에 대한 기준으로 크기에 대한 것이 제시되기도 하지만, 이는 상호작용이나 통합 위험성과는 상관이 없다. 비슷한 클러스터링을 하는 것이 때로는 편리할 수도 있겠지만, 어떤 경우에는 불편할 수도 있다. 예를 들어, 능력과 경험, 실력이 비슷한 부하직원을 가지고 있는 경우, 이들에게 동일한 크기의 업무를 부여할 수는 있지만, 이것들이 모두 다르다면 능력이나 실력에 맞는 업무를 부여하면 된다. 즉, 크기만으로 응집력이 있고 견고한 클러스터링 기준이 될 수 없다.

클러스터링 목적
범위(scoping)는 통상 전체 문제 영역을 작은 객체로 쪼개어서 응집성이 있는 하위 문제를 형성하도록 객체들을 같이 클러스터링함으로써 설정된다. 클러스터링의 목적은 함께 수행될 수 있는 객체끼리 같이 그룹핑하는 것이다. 예를 들어, 수많은 조그만 크기의 서로 연결된 문제들로 구성된 커다란 복잡한 문제를 관련이 있는 문제들의 몇몇 그룹으로 나누는 것이다. 그러한 클러스터링에 따라서 일반적으로 업무를 구조화시키고, 책임성을 클러스터링에 부여한다. 다른 클러스터링과는 상관없이 해당 클러스터에 최소한 몇가지 계획으로 설계 결정을 가하려고 한다. 이와 같이 클러스터링이 되면 한가지 클러스터에 대해서 집중적으로 분석 설계를 할 수 있다. 이처럼 클러스터링은 문제 영역에 대해서 범위를 한정하여 구획할 수 있고, 이는 상품화할 수 있는 기반을 마련해주며, 새로운 버전이나 릴리즈로 기능을 강화할 수 있는 계기를 마련한다.

좋은 클러스터링의 기준 (criteria)
좋은 클러스터링은 상호작용(개발과 운영시)을 최소화시키고, 통합 위험성(예를 들어, 업무와 기술에 대한 조화 요구 부합의 실패)을 줄인다. 좋은 클러스터링에서, 각각의 클러스터는 높은 응집력 (highly coherent)을 가지며, 클러스터간에 오버랩이나 커플링이 거의 없다. 두 클러스터 사이 보다 한 클러스터 내에서 유사성과 친밀도가 더 나타난다.

방법론 기준 클러스터링

UML 표기법을 기반으로 한 방법론으로 Desmond Francis D'Souza가 제안한 Catalysis는 학계에서 주도되어 비즈니스 중심의 개발방법론으로 발전되었으며 많은 기술적인 개념들이 포함되어 있으나, 실제 업계에서는 많이 활용되고 있지는 않다.[3] Catalysis에서는 컴포넌트를 상호작용을 하는 객체들의 집합으로 보고, 단순한 소프트웨어의 집합일 뿐만 아니라 하나의 비즈니스 행위가 될 수 있다고 보고 있다. 또한, 컴포넌트 명세도 프레임워크와 패턴 등 객체의 상호작용을 중심으로 기술된 것으로 보고 있다. 컴포넌트 구축도 초기 단계에서 선정된 비즈니스 모델이 타입이나 협동 등으로 표현되면서 컴포넌트로 이어지고 있다. Catalysis는 컴포넌트 식별에 대해서 하향식(top-down) 기법을 사용하고 있는데, 처음에 시스템을 하나의 객체 타입으로 생각하고 패턴을 적용함으로써 시스템이 수행하는 각각의 역할에 따라서 인터페이스가 식별된다. 이러한 방식으로 계속해서 분해해 나가면서 시스템은 하위 컴포넌트로 분해되며 이러한 과정은 시스템 각각에 대해서 반복된다.

Select Perspective는 변화에 대해 유연하며 적용 가능한 방법론을 제공하기 위해서 컴포넌트 기술을 채택하고 있으며, 아키텍처 프레임워크 내의 프로세스 템플릿을 활용하고 있다.[4] 또한, 업계에서 가장 실질적으로 받아들여진 모델링 기술들의 집합으로 볼 수 있다. 서비스와 관련된 블랙박스 캡슐화를 제공하는 코드의 실행가능한 단위로 컴포넌트를 정의하고 있으며, 비즈니스 요구사항 명세를 토대로 컴포넌트를 구현한다. 비즈니스 컴포넌트에 대한 식별은 크게 비즈니스 프로세스, 책임성, 정보를 기준으로 수행된다. 특히, 책임성과 정보를 중심으로 객체를 그룹핑하는 경우, 두가지가 서로 반대가 되는 경우에 프로세스를 조절해서 적절한 크기로 컴포넌트를 식별하게 된다.

특정 기준에 의한 클러스터링

아키텍처 관점에서 고정된 레이어를 사용하는 방식에는 나누어진 레이어를 클러스터링하는 방법이 각각의 레이어 내에서 컴포넌트를 식별하는 방법(레이어드 방식)과, 레이어와 상관없이 컴포넌트를 식별하고 컴포넌트를 레이어로 다시 나누는 방법(크로스 레이어드 방식)이 있다.[5] 레이어드 방식은 각각의 레이어에서 서로 다른 방식의 클러스터링 원칙이나 기준을 적용할 수 있다는 장점이 있다. 예를 들어, J2EE의 엔티티빈 레이어에서 단 하나의 클러스터링 기준을 적용하고, 세션빈 레이어에서는 다양한 클러스터링 기준을 적용함으로써 유연성과 재사용성을 더 높일 수 있다. 크로스 레이어드 방식은 입도, 수행성능, 확장성, 유연성, 유지보수성, 연관관리, 재사용성, 데이터 관리, 프로젝트 관리, 자산소유 관리 등의 측면에서 더 잇점이 있다. 이러한 방식은 결국에 중요한 비즈니스 개념을 실행 시점에 식별가능한 배포 산출물로 매핑할 수 있다. 비즈니스 모델에서 직접 식별된 비즈니스 객체가 비즈니스 측면에서 더 중요한 의미라는 것을 반영한 방식이다. 레이어드와 크로스 레이어드 방식은 모두 레이어를 나눈다는 것을 전데로 하고 있다. 즉, 크로스 레이어드 방식의 장점은 레이어드 방식의 장점을 모두 포함하게 된다. 이러한 레이어링은 아키텍처 스타일이고, 아키텍처 관점에서 어느 시점에 레이어링을 할 것인가가 중요한 문제이다. 또한, 레이어와 레이어간 연결이나, 레이어 내에서의 구조적인 문제도 중요한 이슈 중의 하나이다. 비즈니스 컴포넌트에서는 크로스 레이어드 방식을 적용한다.

관심의 분리라는 원칙 하에 컴포넌트 구조는 크게 4가지 레이어로 나뉜다.[6] User Layer는 외부에 노출되는 인터페이스 (GUI, Web-based, 배치 커맨드 등)와 사용자의 상호작용 제어를 제공한다. Workflow & Process Control 레이어는 비즈니스 서비스와 상호작용하는 복잡하고 자동화된 비즈니스 프로세스를 관리한다. Business Service & Legacy Wrapping 레이어는 비즈니스 규칙과 운영 활동에 대한 구현을 제공한다. Data & Operating System Services 레이어는 DBMS와 파일 시스템을 포함하여 저장 환경과 상호작용하는 기능을 제공한다.

Workflow Stereotype
- Interface Controller : visual control 혹은 server page의 항해나 순서를 관리하면서 개개의 사용자 화면 요소를 커플링을 줄여준다.
- Process Controller : 하나 이상의 비즈니스 컴포넌트에 대해서 거친 입자(coarse-grained) 비즈니스 프로세스 (자동화된 하나의 유스케이스 정도) 를 수행하기 위해서 수많은 서비스와의 상호작용을 관리
- Workflow Agent : 특정 워크플로우에 대한 화면의 항해를 제어하는 사용자측(Interface Controller 를 사용)과, 워크플로우 자체를 실행하고, 간섭하고, 관리하기 위해 Process Controller와 Business Component의 사용을 관리하는 워크플로우/프로세스 제어측면이 있다.
- Infoware Component : 어플리케이션에서 필요한 저장 데이터/정보를 다루는 능력을 제공. 예를 들어, 저장 객체, 데이터베이스 레코드, 파일, 문서, 그래픽이 이러한 컴포넌트의 서비스를 통해서 사용된다.

클러스터링의 대상이 되는 객체/컴포넌트의 역할에 따른 클러스터링이 가능하다. 따라서 임의의 객체/컴포넌트는 어떤 역할을 수행하기 위해서 클러스터를 형성한다. 컴포넌트 클러스터링 목표 도메인의 특성에 따라 새로운 역할이 존재할 수 있으며, 시스템에 새로운 역할의 추가 및 기존 역할의 확장을 할 수 있다. 역할을 클러스터링에 사용하는 방식은 책임성에 기반한 방식(Responsibility Driven Design, RDD)의 OOAD 기법에서 가져온 개념으로 일부는 컴포넌트를 구성하는 내부의 소규모 컴포넌트들에 역할과 책임을 부여할 때 사용이 가능하다.[7] 특수한 기능이나 연산 기능을 필요로 하는 책임성은 Service Provider가 담당하고, 어떠한 사실을 알고 있는 책임성을 가지는 Information Holder, 서로 분리된 부분을 연결해주는 다리 역할을 제공하는 Interfacer, 자신이 결정하고 다른 컴포넌트나 객체에게 행위를 지시하는 역할을 담당하는 Controller, 다른 컴포넌트에게 정보를 전달하고 행위를 지시하는 역할을 담당하는 Coordinator, 구조화된 정보를 조회/비교/수정하거나, 구조화시킨 객체들을 통해 외부 자원을 연결하는 역할을 담당하는 Structurer 등으로 구분된다.

소유권이나 위치 기준으로 클러스터링을 하거나, 레거시 기준으로 클러스터링이 가능하다. 또한, 허브나 번들 클러스터링 형태도 객체를 그룹핑하는 또 다른 방식이다.[8]

■ 소유권에 따른 클러스터링 - 조직, 관리, 프로젝트 요구
데이터와 활동이 조직의 부서에 의한 사용 혹은, 조직의 부서의 관리 목표에 따라 클러스터링 된다. 결국 조직 구조와 일치하는 시스템 구조를 만들게 된다. 이것은 시스템이 조직 단위 사이의 의사소통인 아닌 조직 내에서의 의사소통을 제공해야 함을 의미한다.
■ 위치에 따른 클러스터링 - 지역, 기술 플랫폼
소유권에 따른 클러스터링과 유사하게, 데이터와 활동이 조직의 서로 다른 위치에 의한 사용에 따라서 클러스터링 된다. 결국, 시스템이 지역 구조와 일치하는 형태가 되며, 지역간의 의사소통이 아닌, 지역 내에서의 의사소통을 지원해야 함을 의미한다.
■ 레거시에 따른 클러스터링 - 기본 클러스터 사용
기존 클러스터링 (예를 들어, 기존 시스템 혹은 조직) 은 새로운 클러스터를 정의하기 위해서 두가지 방법으로 사용될 수 있다. 첫번째는 새로 정의된 클러스터는 기존 클러스터로부터 긍정적으로 도출될 수 있다. 클러스터를 정의함으로써 기존 클러스터를 대체하게 된다. 예를 들어, 활동 클러스터는 기존 시스템에 기반할 수 있으며, 데이터 클러스터는 기존 데이터 저장소에 기인하게 된다. 이는 새로 구현되는 시스템을 더욱 쉽게 만들 수 있다. (신구 시스템의 연결 측면에서) 단기간 동안에 시스템을 구현할 수 있다는 장점은 있지만, 장기간 동안 개선을 할 수 있는 여지는 제공하지 못한다. 만일 프로젝트 영역이 조직 영역 (기능적인 조직) 과 다소 대응된다면, 프로젝트 내의 응용이 쉽게 이루어질 수는 있지만, 프로젝트 간 응용이 쉽지 않을 수 있다. 두번째는 기존 클러스터가 부정적으로 도출될 수 있는 경우이다. 클러스터가 기존 시스템과 데이터 저장소에 상관없이 정의된다. 이는 경험적인 요소가 아닌, 다른 비즈니스 경험요소를 도입하여 수행될 수 있다. 이 경우, 기존 영역을 사용하는 것보다 기존 영역을 분리하는 것이 더 유용할 수도 있다. 기존 시스템과 데이터 영역을 무시하고 새로운 시스템과 데이터 저장소를 정의하는 장점은 통합을 증대시키고 데이터 무결성을 강화할 수 있는 기회를 만들 수 있다는 것이다. 기존 시스템이 좋지 않다면, 완전하게 다른 것으로 클러스터링 함으로써 향상을 꾀해야만 한다. 그렇지만, 이 경우, 많은 계획과 작업, 조정, 조화가 필요하다. 단기간에 있어서는 좋지 않은 클러스터링을 만들 수 있겠지만, 장기간에 있어서는 좋은 결과를 낼 수 있다. 
■ 가용성에 따른 클러스터링 - 외부 클러스터와 연계
■ 허브 클러스터링
한 단일 객체가 중심 혹은 허브 객체로 선정되고, 영역이 허브 객체를 중심으로 연결되는 형태로 정의된다. 예를 들어, 수평(horizon)과 역수평(inverse horizon) 이라는 개념이 개체 타입 위주로 클러스터를 정의하기 위해서 사용될 수 있다. 동일한 방향성으로 모든 것들이 일대다 관계를 형성하고 있다면, 파생된 일대다 관계는 그 합으로 정의될 수 있다. 하나의 클러스터는 허브로써 활동으로 정의될 수도 있다. 비즈니스 프로세스를 중심으로 클러스터링 된 것은 선행조건과 프로세스 통제를 필요로 할 수 있다. 예를 들어, 권한이나 에러 관리 프로세스는 허브 프로세스에서 다른 데이터를 사용하고 있다 하더라도 프로젝트 영역에 암시적으로 포함될 수 있고, 프로젝트 범위가 정의되었어도 명시적으로 식별되지 않을 수도 있다.
■ 구조와 제약조건에 따른 클러스터링
■ 의존성에 따른 클러스터링 - 논리적, 상업용
■ 사용에 따른 클러스터링
■ 상호작용에 따른 클러스터링
■ 번들 클러스터링
통신의 일반적인 형태가 클러스터의 초점으로 선택되고, 통신되는 어떤 것이든지 그 영역으로 정의될 수 있는데, 이러한 것을 정보 흐름 혹은 번들이라고 한다. 예를 들어, 웨어하우스에서 팩토리로 통신하는 것을 분석하는 경우, 제품 데이터를 포함하고 프로세스를 촉발시키는 클러스터를 정의할 수 있다. 소유권과 위치에 따른 클러스터링은 조직 단위 혹은 지역 내에서의 통신에 대한 메커니즘을 제공하는 반면에, 번들 클러스터링은 조직 단위 혹은 지역 사이의 통신 메커니즘을 제공하게 된다.

다음 >>

[3] Desmond Francis D'Souza and A.C. Wills, "Objects, Components and Framework with UML: The Catalysis Approach," Addison Wesley, 1999
[4] Hedley Apperly et al., "Service- and Component-based Development: Using the Select Perspective and UML," Addison Wesley, 2003
[5] Richard Veryard, "Identifying Components - Part II," CBDi Journal, Oct. 23, 2001, http://www.cbdiforum.com
[6] G.T. Heineman and W.T. Council et al., "Component-Based Software Engineering: Putting the Pieces Together," Addison Wesley, 2001
[7] R. Wirfs-Brock and A. McKean, "Object Design," Addison-Wesley, 2002
[8] R. Veryard, "Information Coordination: The Management of Information Models, Systems Organization," Prentice Hall, 1994