고층빌딩을 건축할 때 흔히 볼 수 있는 것이 타워 크레인입니다. 이 중장비는
빌딩의 뼈대가 되는 철골 구조물이나 콘크리트 벽체를 높은 곳으로 들어올려 한 층,
한 층 "조립"해 나가는데 필수적인 장비입니다. 요즈음의 빌딩들은 철골 구조물과
콘크리트 구조물을 공장에서 미리 만든 후 현장으로 옮겨와 조립하는 방식으로
만들어 나갑니다.
이러한 부품(컴포넌트)과 조립에 의한 생산방식은 근대 이후 제조업에서는
필수적인 전제 조건이 되었습니다. SW분야에서도 이러한 부품화 및 조립개념이
도입되고 있습니다. CBD(Component Based Development)가 그것입니다.
컴포넌트 다이어그램은 이러한 부품을 정의할 수 있게 도움을 주는 모델입니다.
자, 그럼 시작해 볼까요? |
1.개요
|
|
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 상호 간에도 사용되는
관계입니다. | | | |
|
다음은 간단한 컴포넌트 다이어그램 사례입니다. 지금까지 배운 내용으로 아래 모델을
나름대로 해석해 봅시다. |
|
|
| |
|
위 컴포넌트 다이어그램은 시스템(혹은 서브시스템)이 GUI, Planner, Scheduler의
3개 컴포넌트로 구성됨을 의미합니다. 그리고 다음과 같은 컴포넌트간의 의존관계가
존재함을 표현합니다. |
|
|
GUI 컴포넌트가 Update 인터페이스를 통해 Planner 컴포넌트의 실행을 요청 |
|
|
Planner 컴포넌트가 Reservations 인터페이스를 통해 Scheduler 컴포넌트의 |
|
실행을 요청 | | | |
|
다음은 컴포넌트 다이어그램의 두 번째 사례입니다.
첫 번째 사례와는 달리 인터페이스가 없습니다. 이 모델이 무엇을 말하고 있는지
해석해 봅시다. |
|
|
| |
위 컴포넌트 다이어그램은 umlviewer.exe라는 실행 모듈이 동작하면서 graphics.dll,
dbhandler.dll , umlcore.obj라는 실행 모듈들에게 서비스를의 실행을 요청한다는
것을 모델링한 것입니다.
4.작성단계 및 주의사항
|
 |
|
|
| 다음은 컴포넌트 다이어그램 작성 시 주의사항입니다. |
|
|
컴포넌트는 응집도는 높고 결합도는 낮은 단위로 정의되어야 합니다. |
|
|
실행모듈로서의 컴포넌트를 식별할 때, 컴포넌트는 다른 컴포넌트와 독립적이고,
기능 차별성을 갖추는 단위로 정의되어야 합니다. 즉, 기능 측면에서 컴포넌트 내부는
강한 유사성을 갖는 단위들로 구성되어야 하고(높은 응집도), 다른 컴포넌트에 강하게
종속되지는 않는(낮은 결합도) 단위로 정의되어야 합니다. |
|
|
컴포넌트 크기(Granularity)의 일관성을 고려해야 합니다. |
|
|
한 시스템에서 컴포넌트의 크기에 너무 차이가 나면 바람직하지 않습니다. 컴포넌트의
크기는 기술구조와 시스템 특성들이 고려되어 적절한 크기로 정의해야 하며, 그 크기도
되도록 많이 차이나지 않도록 하는 것이 좋습니다. |
|
 |
추상화 수준에 맞는 상세성을 일관되게 제공합니다. |
|
|
모든 모델이 마찬가지 입니다만, 한 장의 모델에는 동일한 상세화 레벨이 유지되어야
합니다. 서로 다른 추상화 레벨의 컴포넌트가 섞여 있으면 의미를 파악하기 힘들게
됩니다. 소스와 실행모듈을 한 장에 정의한 컴포넌트는 좋은 예가 아닙니다. |
|
 |
목적을 전달할 수 있는 명칭을 부여해야 합니다. |
|
|
컴포넌트,인터페이스를 비롯해 쓰이는 모든 명칭들은 명확한 표현을 사용해야 합니다.
모호한 명칭으로 정의하면 혼란만 야기 시키는 결과가 됩니다. | | |
소프트웨어공학_시립대.ppt
Prev
