Component Diagram

고층빌딩을 건축할 때 흔히 볼 수 있는 것이 타워 크레인입니다. 이 중장비는 빌딩의 뼈대가 되는 철골 구조물이나 콘크리트 벽체를 높은 곳으로 들어올려 한 층, 한 층 "조립"해 나가는데 필수적인 장비입니다. 요즈음의 빌딩들은 철골 구조물과 콘크리트 구조물을 공장에서 미리 만든 후 현장으로 옮겨와 조립하는 방식으로 만들어 나갑니다. 이러한 부품(컴포넌트)과 조립에 의한 생산방식은 근대 이후 제조업에서는 필수적인 전제 조건이 되었습니다. SW분야에서도 이러한 부품화 및 조립개념이 도입되고 있습니다. CBD(Component Based Development)가 그것입니다. 컴포넌트 다이어그램은 이러한 부품을 정의할 수 있게 도움을 주는 모델입니다. 자, 그럼 시작해 볼까요?

 

1.개요

 

컴포넌트 다이어그램은 "시스템의 구현관점에서 실행모듈(컴포넌트)을 정의하고 실행모듈간의 정적 상호작용을 정의한 모델"입니다. 이 다이어그램은 시스템이 어떠한 물리적 구성요소들로 -실행모듈(컴포넌트)- 구성되고, 그들간의 연관성을 정의한 것입니다.

여기서 컴포넌트는 매우 광범위한 의미로 사용되는 용어입니다. 여러 분야에서 쓰이는 컴포넌트의 많은 의미 중에서, SW 분야에서 사용되는 컴포넌트를 정의하면 다음과 같습니다.

Reusable application building block. 컴포넌트는 시스템의 재사용 가능한 구성요소입니다. Physically replaceable or upgradeable parts of a system 컴포넌트는 시스템의 교체단위이자 업그레이드 단위입니다. An independently deliverable piece of functionality providing access to its services through interfaces 컴포넌트는 인터페이스를 통해 그 기능이 사용되어지는, 독립적으로 인도되는 기능조각입니다.   다음은 UML에서 정의한 컴포넌트의 정의입니다.

	A component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code(source, binary or executable) or equivalents such as scripts or command files. As such, a Component may itself conform to and provide the realization of a set of interfaces, which represent services implemented by the elements resident in the component. These services define behavior offered by instances of the Component as a whole to other client Component instances.
	(참고자료 : UML 1.3 Specification, OMG)

 

 

컴포넌트 다이어그램을 작성하는 목적은 다음과 같습니다. 시스템의 실행모듈(컴포넌트)들을 정의합니다. 컴포넌트 다이어그램은 시스템이 구축될 때, 어떤 실행모듈(컴포넌트)들로 구축될 것인지를 정의하는 용도로 사용됩니다. 이러한 컴포넌트는 독립적으로 배치, 교체가 가능한 단위입니다. 개발 플랫폼에 따라 이러한 실행모듈의 특성은 달라집니다. 컴포넌트간 Dependency를 정의합니다. 컴포넌트 다이어그램은 실행모듈(컴포넌트)간의 정적인 상호작용을 정의하는 용도로 사용됩니다. 컴포넌트 사이의 종속관계를 표현함으로써 실행 시 상호참조하는 연관성을 표현합니다. 실행모듈뿐 아니라 소스코드, 데이터베이스 등의 상호작용을 모델링합니다. 컴포넌트외에 소스코드나 데이터 베이스등 조각으로 나누어 정의할 수 있는 대상들에 대해, 그 대상들의 상호작용을 정의하기도 합니다. 그러나 이런 용도로 사용되는 경우는 흔치 않습니다. 그럼, 이러한 컴포넌트 다이어그램은 언제 작성하는 것이 적절할까요? 컴포넌트 다이어그램은 시스템의 설계단계의 막바지에 작성합니다. 즉, 모든 클래스가 물리적으로 완전히 정의되고, 그 상호관계도 정의된 후 컴포넌트 다이어그램이 작성될 수 있습니다.

 

2.구성요소

 

컴포넌트 다이어그램의 구성요소는 다음과 같습니다. Things 혹은 심볼 : 컴포넌트(Component), 인터페이스(Interface) Relationships : Dependency, Realization

 

컴포넌트의 표기 컴포넌트는 탭이 달린 직사각형으로 표기하며, 컴포넌트 명은 심볼 내에 표기합니다. 컴포넌트의 정의 컴포넌트는 독립적으로 배포되고 교체되며 재사용될 수 있는 SW조각를 의미합니다. 보통의 경우 실행모듈을 말하지만, 실제 통용되는 컴포넌트라는 용어는 항상 실행모듈만을 가리키지는 않습니다. 컴포넌트가 가끔은 아주 광의로 사용되어서 소스코드나 UI(User Interface), 분석, 설계 산출물들을 포함한 것을 의미하기도 합니다. 컴포넌트라는 용어의 의미는 문맥에서 말하는 사람의 의도를 생각해서 받아들여야 합니다. 컴포넌트의 예 컴포넌트는 매우 다양한 크기로 정의되며. 아래 예들은 한정된 컴포넌트의 사례일 뿐입니다. 결재 시스템에서 결재, 사원 등 전자 상거래 시스템에서 우편번호 검색, 신용카드 결제 등

인터페이스의 표기 인터페이스는 두 가지 형태로 표기가 가능합니다. 하나는 icon형태의 표기로 원으로 표현하는데, 이 경우 인터페이스 명은 아래쪽에 표기합니다. 다른 하나는 보통의 클래스에 <>라는 스테레오 타입이 부가된 표기입니다. 인터페이스의 정의 Interface는 Class의 일종입니다. interface는 class나 Component의 기능을 외부에 공개할 목적으로 쓰이며, 구현은 하지 않습니다. interface의 구현은 클래스나 컴포넌트에서 하게 되며, 이 클래스는 interface를 상속하여 단지 선언뿐인 interface의 구현을 담당합니다. Interface는 단독으로 표시되는 경우는 거의 없으며 해당 Interface를 구현하는 Class나 Component에 붙어 다닙니다.

Dependency의 표기 점선 화살표로 표현하고 필요에 따라 선 위에 설명을 붙이기도 합니다. 컴포넌트의 정의 객체나 컴포넌트가 다른 객체나 컴포넌트의 실행을 요청하는 경우, 즉 사물 간의 실행 혹은 참조관계를 표현합니다. Class와 Class , Package와 package , Component와 Component에 주로 사용되는 관계이고, 때로는 Class-Package-Component 상호 간에도 사용되는 관계입니다.

Realization의 표기 속이 빈 삼각형의 화살표가 한쪽에 달린 점선으로 표현합니다. 그러나 특별히 컴포넌트 다이어그램에서는 인터페이스와 컴포넌트간의 실선으로 표현됩니다. Realization의 표기 인터페이스와 컴포넌트 간 표기 Realization의 정의 정의하는 사물과 이를 구현하는 사물 간에 표현하는 관계입니다. Realization은 인터페이스(정의) - 컴포넌트(구현), 유즈케이스(정의) - 컬레버레이션(구현)과 인터페이스(정의) - 클래스(구현) 사이에 허용되는 관계입니다. 삼각형이 붙은 쪽이 정의하는 사물, 반대쪽이 구현하는 사물입니다.

3.사례연구

 

다음은 간단한 컴포넌트 다이어그램 사례입니다. 지금까지 배운 내용으로 아래 모델을 나름대로 해석해 봅시다.

위 컴포넌트 다이어그램은 시스템(혹은 서브시스템)이 GUI, Planner, Scheduler의 3개 컴포넌트로 구성됨을 의미합니다. 그리고 다음과 같은 컴포넌트간의 의존관계가 존재함을 표현합니다. GUI 컴포넌트가 Update 인터페이스를 통해 Planner 컴포넌트의 실행을 요청 Planner 컴포넌트가 Reservations 인터페이스를 통해 Scheduler 컴포넌트의 실행을 요청

다음은 컴포넌트 다이어그램의 두 번째 사례입니다. 첫 번째 사례와는 달리 인터페이스가 없습니다. 이 모델이 무엇을 말하고 있는지 해석해 봅시다.

위 컴포넌트 다이어그램은 umlviewer.exe라는 실행 모듈이 동작하면서 graphics.dll,
dbhandler.dll , umlcore.obj라는 실행 모듈들에게 서비스를의 실행을 요청한다는
것을 모델링한 것입니다.

 

4.작성단계 및 주의사항

 

먼저, 컴포넌트 다이어그램의 작성순서를 알아보겠습니다. 컴포넌트 대상을 정의합니다. 컴포넌트 다이어그램을 그리기 전에 무엇을 컴포넌트로 표현할지 클래스를 구성요소로 하는 실행모듈로 할지, 소스코드를 정의할 지 기타 무엇을 컴포넌트로 표현할 지를 정해야 합니다. 컴포넌트를 식별합니다. 컴포넌트 다이어그램에 등장할 컴포넌트를 정합니다. 소스 파일일 경우 그 대상은 쉽게 식별되지만 실행모듈일 경우 간단치 않습니다. 여러 가지 가능한 방법으로 컴포넌트를 식별해 내는 작업을 수행 합니다. 컴포넌트를 배치하고 필요시 인터페이스를 붙입니다. 컴포넌트 다이어그램에 컴포넌트를 배치하고 이름을 정의합니다. 그리고 인터페이스를 정의할 필요가 있을 경우 인터페이스를 정의하고 컴포넌트와 realization관계로 연결합니다. Dependency를 정의합니다. 컴포넌트와 컴포넌트간 의존관계를 분석하여 Dependency 관계를 정의합니다.

다음은 컴포넌트 다이어그램 작성 시 주의사항입니다. 컴포넌트는 응집도는 높고 결합도는 낮은 단위로 정의되어야 합니다. 실행모듈로서의 컴포넌트를 식별할 때, 컴포넌트는 다른 컴포넌트와 독립적이고, 기능 차별성을 갖추는 단위로 정의되어야 합니다. 즉, 기능 측면에서 컴포넌트 내부는 강한 유사성을 갖는 단위들로 구성되어야 하고(높은 응집도), 다른 컴포넌트에 강하게 종속되지는 않는(낮은 결합도) 단위로 정의되어야 합니다. 컴포넌트 크기(Granularity)의 일관성을 고려해야 합니다. 한 시스템에서 컴포넌트의 크기에 너무 차이가 나면 바람직하지 않습니다. 컴포넌트의 크기는 기술구조와 시스템 특성들이 고려되어 적절한 크기로 정의해야 하며, 그 크기도 되도록 많이 차이나지 않도록 하는 것이 좋습니다. 추상화 수준에 맞는 상세성을 일관되게 제공합니다. 모든 모델이 마찬가지 입니다만, 한 장의 모델에는 동일한 상세화 레벨이 유지되어야 합니다. 서로 다른 추상화 레벨의 컴포넌트가 섞여 있으면 의미를 파악하기 힘들게 됩니다. 소스와 실행모듈을 한 장에 정의한 컴포넌트는 좋은 예가 아닙니다. 목적을 전달할 수 있는 명칭을 부여해야 합니다. 컴포넌트,인터페이스를 비롯해 쓰이는 모든 명칭들은 명확한 표현을 사용해야 합니다. 모호한 명칭으로 정의하면 혼란만 야기 시키는 결과가 됩니다.