'UML'에 해당되는 글 6건

  1. 2009.01.02 [UML] Component Diagram
  2. 2009.01.02 [안영회의 UML 강좌3] - Use Case Diagram
  3. 2008.10.01 클래스 다이어그램 3
  4. 2008.10.01 유스케이스(Usecase) 다이어그램 1
  5. 2008.10.01 UML의 구성
  6. 2008.10.01 UML 강좌
2009. 1. 2. 17:57

[UML] 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)의 일관성을 고려해야 합니다.
한 시스템에서 컴포넌트의 크기에 너무 차이가 나면 바람직하지 않습니다. 컴포넌트의
크기는 기술구조와 시스템 특성들이 고려되어 적절한 크기로 정의해야 하며, 그 크기도
되도록 많이 차이나지 않도록 하는 것이 좋습니다.
추상화 수준에 맞는 상세성을 일관되게 제공합니다.
모든 모델이 마찬가지 입니다만, 한 장의 모델에는 동일한 상세화 레벨이 유지되어야
합니다. 서로 다른 추상화 레벨의 컴포넌트가 섞여 있으면 의미를 파악하기 힘들게
됩니다. 소스와 실행모듈을 한 장에 정의한 컴포넌트는 좋은 예가 아닙니다.
목적을 전달할 수 있는 명칭을 부여해야 합니다.
컴포넌트,인터페이스를 비롯해 쓰이는 모든 명칭들은 명확한 표현을 사용해야 합니다.
모호한 명칭으로 정의하면 혼란만 야기 시키는 결과가 됩니다.
2009. 1. 2. 16:01

[안영회의 UML 강좌3] - Use Case Diagram





RUP (Rational Unified Process)

지난 시간에는 UML의 필요성과 간단한 개념을 살펴보았습니다. 이번 시간부터는 UML을 구성하는 각종 다이어그램들을 하나씩 살펴봅시다. 또한 깊은 이해와 함께 몸으로 익힐 수 있도록 UML 모델링 도구로 가장 유명한 Rational Rose를 이용하여 간단한 실습을 해보도록 하죠. 실습을 위한 소프트웨어는 UML 관련 책자의 부록이나 Rational 사의 웹사이트를 통해 평가판을 구하실 수 있습니다. 평가판을 다운로드 할 수 있는 웹 페이지의 URL은 다음과 같습니다.

본 내용을 진행하기에 앞서 다음의 서적들을 참고로 이 글을 작성했음을 밝힙니다. 더 깊은 이해를 위해서는 이들 서적을 참고하세요.
  Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley
  UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley
  초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북
  The Rational Unified Process An Introduction Second Edition, Philippe Kruchten
  The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
예제 화면은 rose2001A.04.00 버전을 기준으로 사용했습니다. 다른 버전을 사용하시더라도 UML을 배우는 입장에서 큰 차이는 없을 것입니다. 예제 내용은 일반적이고 검증된 것을 사용하고자 Visual Modeling with Rational Rose and UML의 예제를 인용했습니다. UML 구성 요소들의 이름을 한글로 사용할 수 있지만, 코드와의 일관성 유지 등의 목적으로 영어를 사용했습니다. 다만, 한글로 충분히 설명을 기술하도록 하겠습니다.

RUP (Rational Unified Process)
유즈케이스(Use Case)에 대해 본격적으로 설명하기에 앞서 RUP에 대한 언급을 하지 않을 수가 없습니다. UML은 모델링을 위한 표기법입니다. UML이 시스템 개발에 매우 중요하다 하겠지만, UML만으로는 아무 것도 되지 않습니다. 객체 지향으로 시스템 개발을 하겠다고 UML을 사용하면서 개발은 기존의 전통적인 방식을 따른다면 효과가 높지 않을 것입니다.

객체 지향의 시스템 개발을 하려고 한다면 개발의 방법론 역시 객체 지향을 따라야 할 것입니다. 수많은 객체 지향 방법론이 존재한다고 합니다. 이 중에 가장 부각되고 있는 것이 RUP입니다. 무엇보다 RUP는 Rational의 소프트웨어 군을 이용한 개발 방법론으로서 이론뿐만 아니라 구체적인 솔루션이 동반된다는 강점을 지니고 있습니다.

쉽게 얘기하면Rational의 도구들과 RUP에 맞춰서 UML을 사용하여 개발 한다면 삼박자를 갖추게 된다는 매력적인 제안이죠. 우리는 RUP를 배우는 게 아니고 UML을 배우는 것이지만, 시스템을 개발하는 과정을 염두에 두지 않고 UML을 논하는 것은 공허할 수 있습니다. UML이 어떻게 쓰이는지를 생각하지 않겠다는 것이 될 수 있으니까요.
RUP가 최상의 개발 방법론은 아니지만, 개발 공정에 대한 한 예로 RUP를 간단하게 엿보도록 하죠.
다음은 RUP의 개발 공정에 대한 개괄적 그림입니다.
[RUP 개발 공정]

RUP의 개발 공정은 크게 두 축으로 나눠 볼 수 있습니다. 우선 그림의 가로축으로 시간의 흐름에 따른 네 가지 단계(Phases)로 구분할 수 있고, 세로축의 9가지 웍플로우(Workflow)로 나눌 수 있습니다. 웍플로우는 컴포넌트처럼 작업의 성격에 따라 일을 분리한 것입니다.

기존의 방법론이 도입기에는 주로 타당성 검증 등을 하고, 분석 및 설계, 구현, 검증 및 배포와 같은 식으로 일원적인 관점에서 개발을 했다면 RUP는 이차원적인 관점을 갖는다고 하겠습니다. 도입기라고 할 수 있는 도입(Inception) 단계에서는 주로 비즈니스 모델링(Business Modeling)을 수행하지만 이를 위해 상당량의 요구사항 분석을 수행해야 하고, 개발 프로젝트의 타당성이나 위험도 등의 검증을 위해 프로토타입을 만들어 본다든가 하는 구현도 일부분 수행하게 됩니다. 마찬가지로 향후 프로젝트를 정교하게 발전시켜가는 정련(Elaboration) 단계에서도 요구사항 수집과 분석 설계는 물론 도입 단계에서 만들어진 비즈니스 모델링(Business Modeling)을 검증하고 더욱 정교하게 수정하는 일도 계속하게 됩니다. RUP는 이와 같은 식으로 점진적인 개발 방법을 채택하고 있습니다. 이러한 단계들과 웍플로우의 적절한 조합은 두말할 필요 없이 매우 중요하다고 하겠죠. 프로젝트 관리자에 의해서 이러한 적절한 조합이 계획되는데 이를 이터레이션(Iteration)이라고 합니다. 결국 RUP는 이터레이션의 연속으로 개발을 수행하게 되는 것이죠.

유즈케이스 이해하기
이제야 본격적으로 유즈케이스를 얘기할 차례군요. 유즈케이스는 우리말로는 쓰임새라고도 합니다. 두 가지를 동시에 사용하는 혼돈을 막기 위해서 여기서는 원어로 유즈케이스라고 표기하는 것을 원칙으로 하겠습니다.

유즈케이스라 함은 말 그대로 ‘쓰이는 경우’라던가 ‘용도’ 같은 의미로 받아들여도 큰 무리가 없다고 보여집니다. 어떤 일에 쓰느냐 하는 것이죠. 시스템이 쓰여지는 용도를 모아서 시스템을 만들어낸다면 다용도 시스템이 만들어지겠죠. 유즈케이스들을 모아서 시스템으로 매핑 시키는 것을 개발 과정의 간단한 정의로 보아도 무리가 없을 만큼 유즈케이스는 가치 있는 것입니다.

제가 한국 Rational 이사님의 세미나를 들은 일이 있습니다. 그때 UML에 관한 부분에서는 유즈케이스를 유난히 강조하시더군요. 유즈케이스는 사용자 시각에 맞춘 분석입니다. 어떤 시스템을 만드느냐를 사용자 입장에서 조명하는 것이죠. 최근 비즈니스가 발전함에 따라 고객 지향 마인드가 널리 퍼져 있습니다. 당연한 결과라 하겠죠. 마찬가지로 시스템 개발에 있어서도 고객 관점에서 바라보는 시각이 부각되는 것은 당연한 일이라 하겠습니다.

객체 지향 개발 자체가 기존 개발 방법들에 비해 상당히 인간위주의 개발 방법론이라는 느낌이 드는데 유즈케이스는 이러한 휴머니즘의 선봉에 서있다고 해도 큰 비약은 아니라는 생각이 듭니다. 아무튼 유즈케이스는 시스템 보다는 그것을 사용하는 인간, 즉 사용자의 입장을 우선해서 시스템이 어때야 하는가를 알아보는 것입니다. 아무리 잘 만든 시스템도 인간에게 가치를 주지 못하면 무의미한 것이죠.

이러한 휴머니즘을 잊지 마시고, 유즈케이스를 배워 봅시다. 유즈케이스는 시스템의 행위를 결정하는 것입니다. 구체적으로는 시스템의 기능을 정의하고, 범위를 결정함으로써 시스템과 외부 환경 변수를 구분하고, 상호 관계를 정립하는 것이라고 볼 수 있습니다.
개발 공정과 연관해서 보면 도입 단계에서 주요 유즈케이스를 뽑아내고, 차츰 이를 정련하게 됩니다.
유즈케이스를 나타내는 유즈케이스 모델(Use case Model)은 유즈케이스 다이어그램으로 표현됩니다. 유즈케이스 다이어그램은 액터(Actor, 행위자)와 유즈케이스, 그리고 관계(Relationship)로 나타냅니다.


 
유즈케이스, 액터, 관계

액터(Actors)
액터는 시스템의 일부가 아닙니다. 액터는 시스템과 상호작용을 하는 모든 것들을 나타냅니다. 시스템을 사용하게 될 사람은 물론이고, 연관된 다른 시스템도 액터입니다. 대체로 액터의 행위는 정보의 입력과 출력으로 살펴 볼 수 있습니다. 정보를 입력하거나 출력하는 액터가 있고, 입출력을 모두 행하는 액터가 있을 것입니다.

액터를 뽑아내는 일은 매우 중요한 일입니다. 모든 주요 액터를 고려해야만 모두에게 가치 있는 시스템이 될 수 있을 테니까요. Visual Modeling with Rational Rose and UML에 따르면 다음과 같은 질문들이 액터를 뽑아내는데 도움을 준다고 합니다.
   특정 요구사항에 이해관계자는 누구인가?
   어떠한 부서나 집단에서 시스템을 사용하는가?
   시스템을 사용함으로써 이익을 얻는 이는 누구인가?
   누가 시스템에 정보를 입력하고 사용하며 삭제하는가?
   누가 시스템의 유지보수를 수행하는가?
   시스템이 외부 자원을 사용하는가?
   한 사람이 복수의 역할을 수행하는가?
   여러 사람이 한 가지 역할을 수행하는가?
   시스템이 레거시 시스템(Legacy System)과 상호 작용 하는가?

액터는 다이어그램 상에서 막대인간(stickman)으로 표현됩니다.
[액터의 UML 표기법]

유즈케이스 (Use Cases)
유즈케이스 모델은 시스템과 액터와의 의사소통을 표현합니다. 각각의 유즈케이스는 시스템이 제공해야 하는 기능을 묘사하고, 이러한 유즈케이스들이 시스템 전체의 기능을 나타냅니다. 하나의 유즈케이스는 액터가 원하는 기능을 수행하기 위해 시스템이 수행하는 일련의 처리들의 연속입니다. Visual Modeling with Rational Rose and UML에 따르면 다음과 같은 질문들이 유즈케이스를 뽑아내는데 도움을 준다고 합니다.
   각각의 액터의 업무는 무엇인가?
   액터가 시스템의 정보를 생성, 저장, 수정, 삭제하고 읽는가?
   어떠한 유즈케이스가 시스템의 정보를 생성, 저장, 수정, 삭제하고 읽는가?
   액터가 돌연한 외부 변화에 대한 정보를 시스템에게 알릴 필요가 있는가?
   시스템에 갑자기 발생한 일들을 액터가 알아야 하는가?
   어떠한 유즈케이스들이 시스템을 지원하고 유지하는가?
   유즈케이스들이 모든 요구되는 기능을 포괄하여 수행하는가?

유즈케이스의 UML 표기법은 타원(Oval)입니다.
[Use Case의 UML 표기법]

관계(Relationship)
관계는 크게 두 가지로 볼 수 있습니다. 하나는 액터와 유즈케이스의 관계이고, 다른 하나는 유즈케이스간의 관계입니다. 액터와 유즈케이스와의 관계는 연관(Association) 혹은 커뮤니케이션 연관(Communicates Association)이라고 합니다. 액터와 유즈케이스간의 의사소통을 나타내기 때문이겠죠.

연관은 양방향으로 진행될 수 있습니다. 연관의 방향성은 어느 쪽이 연관을 유발하느냐에 따라 달라집니다. 오직 액터 혹은 유즈케이스만이 연관을 유발하는 단방향 연관이 있고, 양쪽 모두에서 연관을 일으키는 양방향 연관이 있습니다.

유즈케이스간의 관계는 두 가지 형태가 있습니다. 포함(Inclusion 혹은 사용 Use)과 확장(Extension)입니다. 여러 유즈케이스들이 하나의 기능 조각을 공유할 때 이를 모든 유즈케이스에 각각 집어넣는 것 보다는 이를 분리해두고 필요한 유즈케이스들이 이를 포함해서 사용하게 됩니다. 예를 들어 회원제를 기반으로 한 인터넷 사이트에 접속하셔서 각종 서비스를 제공받기에 앞서 늘 수행하는 회원 인증과 같은 유즈케이스가 포함 관계입니다.

확장 관계는 기본 유즈케이스에서 특정 조건이나 액터의 선택에 따라 발생하는 유즈케이스입니다. 가령, ATM에서 사용자의 메뉴 선택에 따라 달라지는 유즈케이스의 경우나 긴급 상황 시에 발생할 수 있는 유즈케이스가 확장의 예로 생각할 수 있습니다.

관계는 선으로 표기하며 관계의 방향성은 화살표로 나타냅니다. UML에는 스테레오타입(Stereotype)이라는 개념이 있습니다. 이는 기본적인 모델링 요소 이외의 새로운 타입을 나타내는 것입니다. 따라서 확장을 가능하게 해줍니다. 스테레오타입이라는 것이 인쇄소의 연판을 나타내는 것입니다. 어느 정도 변화를 줄 수 있는 유연한 판형이라는 것이죠. 이처럼 스테레오타입은 기본 모델링 요소에 확장성을 부여할 수 있는 개념입니다.
2008. 10. 1. 16:06

클래스 다이어그램





본 호에서는 UML에서 시스템의 정적인 부분을 주로 나타내는 클래스 다이어그램을 알아볼 것이다. 독자들이 객체 지향 공부를 하면서 익힌 클래스, 상속 등의 익숙한 개념이 많이 나타나는 다이어그램이다.  UML의 다이어그램 중 어느 한 다이어그램이 중요하지 않다 말할 수는 없지만 클래스 다이어그램은 그 중 중요하다 할 수 있는 다이어그램이다. 필자가 시스템을 구축하면서 느낀 점을 보태어서 말한다면 만들어진 시스템의 정적구조가 엉망이라면 시스템의 구축이나 기능확장의 어려움이 막대하다 할 수 있다. 반면에 잘 만들어진 구조를 가졌다면 시스템 구축자체에서나 기능의 확장에 있어서 무리 없이 가능해진다.  물론 이렇게 잘 된 정적 구조의 중요성을 실감하기 위해서는 실제 시스템의 만들어보고 잘못된 구조로 인한 피해를 느껴봐야만 할 것이다.
만약 이 글을 읽는 독자 중에 시스템의 정적인 구조를 처음 설계하려는 사람이 있다면 되도록이면 빠른 싸이클로 반복을 하기 바란다.  왜냐하면  설계에 대한 충분한 경험을 가지고 있지 않고는 처음 설계한 구조가 시스템을 구축하기에 완벽하게 만족시키지 못하기 때문이다.  빠른 싸이클의 반복은 잘못된 구조의 수정 기회를 늘인다.
이제 클래스 다이어그램에 관한 내용을 알아보도록 하자. 실제 클래스 다이어그램의 내용은 한 회에 다 실을 수 없을 만큼 양이 많다.  글의 제목에서도 느낄 수 있는 것과 같이 클래스 다이어그램을 2내지3회의 분량으로 할 계획이다. 클래스 다이어그램이 이렇게 분량이 많은 이유는 클래스 다이어그램이 프로그래밍 언어들과 가장 직접적으로 연관을 맺고 있고 또한 아주 많은 부분에서 객체지향의 이론이 녹아들어가 있기 때문이다. 이번 호에서는 클래스 다이어그램의 가장 기본이 되는 요소들과  그 의미를 알아보도록 할 것이다.
1.클래스
그림 1 - 클래스의 표기
클래스의 표기는 그림1에서의 표기와 같이한다. 그림1의 좌측에 있는 것은 Attribute와 Operation이 축약되지 않은 표기이고 나머지는 축약된 표기이다.
클래스의 의미는 일반적으로 객체지향 언어에서 사용하는 클래스의 의미와 유사하다. 클래스라는 것은 시스템에서 동작하게 되는 하나의 개념의 추상화 도구로써 사용되며 추상화의 단계에 따라 클래스의 의미가 약간씩 차이가 생긴다. 만약 설계 당시에 추상화가 아주 높은 단계에서 이러한 클래스는 시스템에서 사용되는 하나의 역할로서의 의미를 가진다. 하지만 구현단계와 같은 추상화 단계가 아주 낮은 상태에서는 실제 객체를 생성하기 위한 클래스의의미를 가지게 된다. 이러한 단계의 구별은 사용자의 의도에 따라 적당히 사용하면 될 것이다.
2.Attribute와 Operation
Attribute와 Operation 의 표기 또한 추상화 단계에 따라 표기의 방법이 달라 질 수 있다. 예를 들어 구현단계에 근접하여 클래스 다이어그램을 도시하려 한다면 구현하기위한 언어에 밀접한 형태의 Attribute와 Operation 으로 나타내어야 하지만 추상화 단계가 높을 경우는 대략적인 의미 전달을 할 수 있을 정도로 표기하여도 된다. Attribute의 UML1.1 표준형식은 다음과 같다.
visibility name : type-expression = initial-value { property-string }.
구조에 대한 설명은 프로그래밍 언어를 사용하여 본 사람이라면 쉽게 이해할 수 있을 것이다. Operation의 UML1.1표준형식은 다음과 같다.
visibility name ( parameter-list ) : return-type-expression { property-string }
Attribute와 마찬가지고 구조는 쉽게 이해될 것이다. 여기서 한가지 짚고 넘어가야 할 부분이 Visibility부분이다. 언어에서 Visibility를 private와 protect, public으로 구분하듯이 여기서도 이러한 구분을 표시할 수 있다. 즉 private는 '-'로 protected 는 '#'로 public은 '+'로 표기함을 알아두어야 할 것이다.
3.클래스와 클래스의 상속관계(Generalization Relationship).
그림 2  - 상속관계
상속관계의 표기는 그림 2와 같이 닫혀져 있는 머리를 가진 화살표로 나타낸다.
상속의 의미는 일반 언어에서의 상속의 의미와 유사하게 상위클래스의 모든 특징과 행위를 하위의 클래스가 모두 이어받게 된다. 즉 다양한 클래스들의 나열에서 동일한 행위나 특징을 가진 여러 클래스들이 존재할 때 공통되는 부분을 상위 클래스로 만들 수 있다.

4.클래스와 클래스의 연관관계(Association Relationship)
그림 3 - 연관관계
연관관계의 표기는 그림 3과 같이 실선으로 표기하게 된다. 연관관계의 의미는 두 클래스가 서로 어떠한 연관을 가지고 있다는 의미이다.  예를 들어 회사와 사원은 어떤 식으로든지 연관을 가지고 있다. 이것을 표현하기 위해서 연관의 관계를 사용한다. 물론 이러한 연관을 사용하기 위해서 UML에서는 표기의 확장으로 여러가지 장식(Adornments)들을 사용한다 여기서 사용되는 장식들로는 연관의 이름, 다중성(Multiplicity), 역할이름(RoleName) 등이 있다. 각 장식에 대하여 알아보면 먼저 연관의 이름은 어떠한 연관인지를 명시적으로 나타내게 된다. 다중성의 의미는 연관된 상대의 수를 표시하게 된다. 마지막으로 역할이름은 연관을 맺은 상태에서 상대 클래스에서 사용되어지게 되는 역할의 이름을 나타낸다.
5.클래스와 클래스의 집합연관관계(Aggregation Relationship)
그림 4 - 집합연관관계
집합연관관계의 표기는 그림 4와 같이 속이 빈 마름모 머리를 가진 실선으로 표기하게 된다. 집합연관관계는 연관관계의 일종으로 연관관계에서 쓰이는 모든 장식들이 다 쓰일 수 있다.집합연관관계를 쓰는 경우는 클래스와 클래스의 관계가 부분과 전체의 관계를 가질 때 표시할 수 있다. 예를 들면 자동차와 바퀴는 전체와 부분의 관계가 될 수 있다.
6.클래스와 클래스의 복합연관관계(Composition Relationship)
그림 5 -복합 연관관계
복합연관의 표기는 그림 5에서와 같이 속이 찬 마름모머리를 가진 실선으로 표기하게 된다. 복합 연관관계는 집합연관관계와 유사하게 전체와 부분의 관계를 나타내게 된다. 하지만 엄연한 차이점이 존재한다. 집합연관관계에서는 부분 클래스가 전체 클래스와 같은 생명시간을 가진다는 것이다. 즉 전체의 클래스의 객체가 소멸될 때 부분 클래스의 객체 또한 소멸되는 것이다. 예를 들어 우리가 흔히 말하는 윈도우를 전체로 보고 그 안에 들어가는 버튼을 부분으로 보면 이해가 쉬울 것이다.
7.클래스와 클래스의 의존관계(Dependency Relationship)
그림 6 - 의존 관계
의존관계은 그림 6에서와 같인 열려진 머리의 화살표를 가진 점선으로 표기한다.
의존관계의 의미는 한 클래스의 변화가 다른 클래스에 영향을 미칠 때 사용한다. 이러한 의존의 관계는 여러가지 관계에서 나타날 수 있다.  의존관계의 종류에 관하여서는 다음 호에 자세히 다루도록 할 것이다.
이로서 클래스 다이어그램에서 사용되는 기본적인 요소들을 모두 알아보았다. 여기서 설명한 요소들은 가장 기본적인 개념들이므로 숙지하길 바란다. 다음호 에는 이를 바탕으로 여러가지 부가적인 요소들을 알아보도록 할 것이다.

본 회에서는 지난 호에 이어 클래스 다이어그램에 나타나는 표기에 관하여 알아본다. 지난회에서 핵심이되는 클래스의 대략적인 모습을 보았다. 이번 회에는 클래스 표기 자체의 확장과 스테레오 타입을 이용한 확장된 의미의 여러가지 클래스들에 대하여 알아보기로 한다.
1. 클래스에서 사용자 정의 구역(User-defined compartment)
그림 1 사용정의 구역 (user-defined compartment)
클래스를 구성하는 부분으로 이름구역, Attribute구역, Operation구역이 있음을 우리는 알고 있다. 이러한 클래스를 구성하는 세가지 부분은 UML에서 미리 정의하는 부분이고 이외에 사용자가 정의하여 작성할 수 있는 새로운 구역을 첨가할 수 있다. 이러한 사용자 정의 구역은 툴이 제공하는 환경에 따라 다양하게 제공된다. 만약 독자 여러분이  UML Modeling툴을 만든다면 사용자 정의 역역을 이용하여 순공학이나 문서화 등의 툴의 부가적인 기능을 돋보이게 할 수 있을 것이다.
2. Type and Implementation Class
그림2  type and implementation class
지금부터 언급하는 내용은 클래스 다이어그램에 적용함에 있어서 스테레오타입(Stereotype)이나 컨스트레인트(Constraint)를 이용하여 기존 클래스의 의미를 확대하는 부분이다. 이러한 의미의 확대는 실제 업무에서 사용되는 개념과 좀 더 근접시키기위해 UML에서 표준으로 지정하고 있다.
먼저 Type의 경우 스테레오타입으로 'type'을 가진다. 이것은 객체가 가지는 Specification만을 표시한다. 그러한 이유로 실제로 언어에 바인딩되는 attribute나 method를 적는 것이 아니라 specification상에 나타나는 attribute나 operation이 반영된다. 반면에 Implementation class의 경우 실제 물리적인 언어에 바인딩되게 표현을 한다. Implementation class의 경우 스테레오 타입을 'implementationClass'를 기입하게 된다. Type과 iplementation class의 차이는 type을 실체화(Realization) 시킨 것이 Implementation class가 된다.
3. Interface
그림 3 Interface
인터페이스 클래스의 경우 스테레오타입을 'interface'로 가지며 객체지향 언어인 java에서 사용되는 인터페이스의 의미와 동일하게 클래스의 행위만을 확정하고 있다. 이러한 인터페이스는 구현을 가지지 않으므로 abstract operation을 가지게 된다.
4. Parameterized Class (Template Class)
그림 4 Parameterized Class
Parameterrized Class의 표기는 위의 그림과 같이 표기하고 그 의미는 객체지향언어 C++에서 사용되는 Template와 동일하다.
5. Utility
그림 5  Utility Class
Utility class의 표기는 스테레오타입을 'utility'로 가진다. 그 의미는 일반적인 클래스의 의미가 아니라 프로그램의 편리를 위해 만들어진 클래스이다. 프로그램을 하면 반드시 Global로 만들어야 할 프로시져나 변수들이 존재하게 된다. 이를 기능적으로 분리하기 위해 utility class를 사용한다. Utility class 내부에 존재하는 attribute나 operation의 경우 Global 변수나 프로시져로 인식하면 된다.
6. MetaClass
MetaClass의 표기는 스테레오타입을 'metaclass'로 가지는 클래스이다. 이것은 metaclass의 인스턴스가 클래스가 되는 클래스를 의미한다.
7. Enumeration
Enumeration Class의 경우 스테레오타입을 'enumeration'으로 가지는 클래스이다. Enumeration Class의 의미는 프로그램언어에서 사용되는 일반적인 enumeration type과 의미가 유사하다. 정확한 Enumeration Class의 의미는 이 클래스의 인스턴스는 반드시 사용자가 정의한 특정 문자의 집합이어야 한다는 것이다. 이러한 문자는 상대적인 순서를 가지게 된다.
8. Stereotype
Stereotype Class의 경우 UML에서 사용되는 의미확장의 도구인 stereotype을 UML에서 지정한 것 이외에 사용자 정의 스테레오타입을 만들기위해 사용되는 클래스이다. Stereotype Class의 표기는 스테레오타입을 'stereotype'으로 가진다.
9. Class Pathname
그림 6 Class Pathname
클래스를 표기함에 있어서 UML에서 패키지(Package)를 같이 붙여 클래스의 범위를 지정할 수 있다. 패키지는 UML에서 Namespace역할을 한다. 패키지에 대한 자세한 설명은 차후 다이어그램에서 공통으로 사용되는 요소를 설명할 때 하기로 한다. 패키지속에 패키지가 포함 될 수 있으므로 패키지 path를 다 적용하여 클래스의 Pathname을 표기하기도 한다.
지금까지 클래스 다이어그램에서 정의하는 확장된 의미의 표기를 살펴보았다. 참고로 이러한 모든 내용에 대하여서 자세히 알고 싶다면 UML Spec을 보는 것이 도움이 될것이다.
실무에서는 시스템을 구성하는 클래스를 뽑아내고 그것의 역할을 지정하고 연관을 맺는 것이 가장 힘든 일일 것이다. 이것에 대한 정확히 정립된 방법은 존재하지 않는다. 약간이나마 정형화된 클래스를 뽑아내는 시점에 관하여 적어보면 통상 시스템 구축에 있어서 유스케이스 다이어그램을 그려서 시스템의 큰 기능을 만들고 그 유스케이스의 흐름을 가지고 시퀀스나 콜레버레이션 다이어그램에서 객체와 객체사이의 인터렉션을 정의하게 된다. 여기서 사용되는 객체의 행위와 속성을 가지고 클래스의 구체적 형상을 뽑아낼 수 있을 것이다. 물론 여러 번의 반복을 통한 클래스이 확정이 필요할 것이다.
그 동안 필자 주변의 일로 몇 회의 뉴스레터에 글을 올리지 못한 경우가 있었습니다. 매번 이러한 이야기를 하는 것이 구차한 변명인 줄 알고 있지만 어쩔 수 없이 양해를 구해야하는 것이 도리이기에 차후에 적어나갈 글을 더욱 알차게 적겠다는 말로 사과를 대신하려 합니다.
2008. 10. 1. 16:04

유스케이스(Usecase) 다이어그램




지난 회에서 우리는 UML의 전체 구성에 대하여 알아보았다. 전체적인 구성을 보았으니 앞으로 각 다이어그램을 하나씩 보도록 하자.  이번 회에는 유스케이스 다이어그램에 관하여 알아보도록 하겠다.  많은 다이어그램 중에 왜 유스케이스 다이어그램을 가장 먼저 설명을 하는가에 대한 의문이 일것이다.  물론 필자의 마음일 수도 있지만 이 보다도 더 명확한 이유가 존재한다.  독자 여러분이 어떠한 방법론을 배우고 있다 하더라도 프로젝트를 수행함에 있어서 가장 먼저 수행되는 일이 동일할 것이다. 그것은 프로젝트가 무엇인지에 대한 기술이다. 프로젝트가 무엇인지 모르고 어떻게 프로젝트를 수행하겠는가?  이렇게 프로젝트가 무엇인지에 대해서 알아보는 것이 요구분석(Requirement Analysis)이다.  글의 흐름으로 보아 유스케이스 다이어그램이 요구분석을 위한 다이어그램이라는 것을 유추할 수 있을 것이다.  결국 유스케이스 다이어그램은 프로젝트 수행시 가장 먼저 나오는 다이어그램이고 다른 다이어그램의 배경이 되는 중요한 다이어그램이다.  이제부터 유스케이스 다이어그램을 자세히 알아보도록 하겠다.
 
1. 표기(Notation)과 의미(Semantics)
(1) 유스케이스(Usecase)
그림 1. 유스케이스

유스케이스의 표기는 그림 1에서와 같이 타원으로 표시하고 이름을 속에 명시하게된다.
(2) 유스케이스의 의미.
유스케이스는 말 그대로 쓰임새를 나타낸다. 다시 말해 한 프로젝트의 결과물이 작동하여 사용되는 쓰임새를 분류하여 나타내는 것이다. 예를 들어 우리가 늘 상주하는 집을 들면 집이 사용되어지는 예를 들 수가 있다. 집은 식사를 위한 장소를 사용되어질 수 있고 아니면 휴식을 위한 장소 아니면 수면을 취하기 위한 장소.. 등등 여러가지 용도의 사용 예를 들 수 있다. 결국 이러한 여러 사용 예들이 집의 구조를 결정하는 사항이 될 것이다.
(3) 액터(Actor)

그림 2 - 액터

그림 3 - 스테레오 타입이 액터인 클래스
액터의 경우 그림 2에서 보는 바와 같이 스틱맨으로 표시하고 그 하단에 액터의 이름을 명시한다.  또한 그림 3와 같이 스테레오타입(Stereotype)을  'Actor' 로 가지는 클래스로 표기하기도 한다.
(4) 액터의 의미
액터는 구축해야할 시스템과 상호 교류하는 어떠한 사람이나 어떤 것이 될 수 있다. 예를 들어 입출금할 수 있는 ATM기계를 보면 입출금을 하는 행위자인 손님의 경우 하나의 액터가 될 수 있다. 그리고 ATM기계가 입출금의 처리를 위해 연결하는 은행의 주 전산망 또한 하나의 액터가 될 수 있다. 이렇듯이 구축하고자 하는 시스템의 쓰임새와 교류하는 외부적인 것들의 추상적인 역할을 액터라고 한다.
 
2. 액터들간의 관계(Relationship)
(1) 일반화(Generalization) 관계의 표기

그림 4 -액터와 액터 사이의 일반화 관계 
(2) 일반화 관계의 의미
일반화 관계는 객체지향의 상속의 의미와 유사하다. 일반화된 액터의 모든 특성을 특수한 액터가 모두 가지게 된다. 그림 4에서와 같이 고객 액터의 모든 특성을 상업고객이 모두 포함하게 된다.
 
3. 액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계
유스케이스와 유스케이스사이의 관계를 말하기에 앞서 알아두어야 할 사항이 있다. 현재 UML의 표준화된 버전은1.1 이다. 하지만 현시점에도 계속 버전업을 위한 수정이 가해지고 있다. 결과적으로 현재 1.3 RTF라는 표준화되지 않은 버전 또한 나와 있다.  유스케이스와 유스케이스와의 관계에서 1.1버전과 1.3버전의 차이점이 존재함을 유념하기 바란다.  필자는 표준인 1.1 을 대상으로 설명을 하도록 하겠다.
(1) 통신(Communicates) 관계

그림 5 - 통신(Association) 관계 
(2) 통신 관계의 의미
통신관계의 의미는 이러한 관계로 묶인 두 개체가 상호 작용을 한다는 의미이다.  그림 5에서와 같이 현금자동출납기계의 시스템에서 그 사용자와 사용자확인의 유스케이스는 상호작용을 하게 된다. 이를 관계로 표시한 것이 통신 관계이다. 참고로 UML1.3 RTF의 경우 통신관계는 연관(Association) 관계로 대체되어 사용되게 된다.
(3) 확장(Extends) 관계

그림 6 - 확장(Extends) 관계
(4) 확장 관계의 의미
확장(Extends)관계는 유스케이스가 어떤한 조건이 만족할 경우 확장할 수 있는 확장시점(Extention Point)를 가지고 그 때 연관된 유스케이스를 포함하는 관계이다 예를 들면 그림 6에서와 같이 추가 요구시라는 확장시점에서 카탈로그요구의 유스케이스가 주문접수의 유스케이스에 포함되게 된다.
(5) 사용(Uses) 관계

그림 7 - 사용(Uses) 관계
(6) 사용 관계의 의미
사용관계는 특정한 유스케이스가 다른 유스케이스를 포함하고 있는 경우를 나타낸다. 그림 7에서는 고객확인의 유스케이스가 주문접수의 유스케이스와 주문조사의 유스케이스를 모두 포함하게 되는 경우이다. UML 1.3 RTF에서는 Uses의 관계가 include의 관계로 이름이 바뀌어서 사용되게 된다.
(7) 일반화(Generalization) 관계 

그림 8 - 일반화(Generalization) 관계
(8) 일반화 관계의 의미
일반화 관계는 액터 사이의 일반화 관계와 동일하게 객체지향의 상속의 개념과 유사하다. 
 
4. 액터와 유스케이스의 추출법.
실제로 시스템을 구축하기 위해 유스케이스 다이어그램을 그릴 때 액터와 유스케이스를 만들기가 막막할 것이다. 물론 정확한 액터와 유스케이스를 추출하기 위해서는 여러 번의 반복이 필요하지만 처음으로 추출할려는 사람은 다음과 같은 대충의 지표 등을 통해 추출해보는 것도 좋다.
(1) 액터의 추출법
  1. 시스템의 주기능을 사용하는 사람은 누구인가.
  2. 누가 시스템으로부터 업무 지원을 받는가?
  3. 누가 시스템을 운영, 유지 보수하는가?
  4. 시스템과 정보를 교환하는 외부 시스템은 무엇인가?
  5. 시스템이 내어놓은 결과물에 누가 관심을 가지는가?
(2) 유스케이스 추출법
  1. Actor가 요구하는 시스템의 주요 기능은 무엇인가?
  2. Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?
  3. 시스템이 Actor에게 주는 어떠한 Event가 있는가?,  Actor가 시스템에는 어떠한 Event가 있는가?
  4. 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?
  5. 시스템의 구현에서 가장 문제가 되는 점은 무엇인가?
 
5. 시나리오
유스케이스 다이어그램을 그리면서 빠뜨려서는 안될 내용이 시나리오이다. 유스케이스 다이어그램을 완성하였다면 유스케이스 다이어그램의 명세가 필요하게 된다. 즉 유스케이스 다이어그램이 무엇을 해야하고 어떻게 해야하는가에 같은 부연 설명이 필요한 것이다. 유스케이스는 순서에 의해 배열이 가능하고 이러한 순서를 일반적인 자연어 문장으로 표현하되 외부인이 보아도 알기쉬운 정도로 쉽게 기술하여야 한다.
마무리?
유스케이스 다이어그램은 다른 다이어그램을 그리기 위한 바탕이 되는 다이어그램이다. 즉 유스케이스 다이어그램이 잘못 되었다면 결과물은 잘못된 것일 수밖에 없다. 유스케이스 다이어그래이 잘 되었다면 이후 그려나갈 다른 다이어그램이 원래의 목적에 맞게 그릴 수 있는지 비교할 수 있는 좋은 바탕이 될 수 있다.
참고로 유스케이스 다이어그램을 잘 그리기 위해 다음의 단계로 넘어가는 것을 주저하지 말기 바란다. 프로젝트를 잘 수행하기 위해서는 여러 번의 반복적 개발을 통해 오류의 수정 과정이 필요하고 이에 유스케이스 다이어그램을 수정하는 일도 포함된다. 즉 어느 정도 유스케이스 다이어그램이 완성되면 다음의 다이어그램을 진행하길 바란다.

2008. 10. 1. 16:03

UML의 구성




1. UML과 방법론의 차이
UML의 구성을 알아보기에 앞서 먼저 UML과 방법론의 차이를 알아야 한다. 필자는 UML을 공부하는 초기에 UML을 하나의 방법론으로 착각하는 오류를 하였다. 물론 똑똑한 독자는 이러한 오류를 범하지 않으리라 생각하지만 혹시나 하는 마음에 먼저 언급하려고 한다.
방법론이란 말그대로 어떠한 작업을 할 때 이러저러한 절차를 가지고 작업을 하면 된다라고 하는 것을 이론적으로 정립을 하여놓은 것이다. 소프트웨어공학에서 많은 방법론이 있어왔고 현재도 수많은 방법론이 존재한다. 사실 프로그램을 하는 모든 사람은 나름대로의 방법론을 가지고 있다. 그러한 나름의 방법론이 작업을 얼마만큼 효과적으로 만드는지에 따라 좋은 방법론인지 아닌지 결정 날 것이다.
그럼 UML은 무엇인가?  UML은 이러한 방법론을 적용할 때의 결과물을 나타내기 위한 도구이다.  예를 들면 모든 소프트웨어를 설계 할 때 어떠한 표준적인 규칙을 가지고 설계도를 그려야한다. 이때 설계의 표준이 되는 것이 UML이다.  건축도면에서 나오는 건물 내부의 여러가지 표준적인 표기라 보면 될 것이다.  즉 각자 다양한 방법론을 자기의 프로젝트에 적용하더라도 UML을 공통적으로 적용할 수 있다.
2. UML의 구성
이제 UML이 어떻게 구성되어있는지 알아보도록 하겠다.  전체 UML은 8가지 다이어그램으로 나타난다. 시스템의 정적인 면을 나타내는 클래스 다이어그램(Class Diagram)이 있고 동적인 면을 나타내는 콜레버레이션 다이어그램(Collaboration Diagram), 시퀸스 다이어그램(Sequence Diagram), 상태 다이어그램(Statechart Diagram), 액티비티 다이어그램(Activity Diagram), 디플로이먼트 다이어그램(Deployment Diagram), 컴포넌트 다이어그램(Component Diagram)으로 구성되어져 있다.
이외로 유스케이스 다이어그램(Usecase Diagram)이 존재한다. 유스케이스 다이어그램을 두 부류로 나누지 않은 이유는 다른 모든 다이어그램을 그리기 위해 기반이 되는 다이어그램이기 때문이다.이제 각 다이어그램이 시스템의 어떠한 면을 반영하는지 간단하게 알아보도록 하자.
(1) 유스케이스 다이어그램 (Usecase Diagram)
유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를들어 보험처리 프로그램의 경우에 "고객이 보험증권에 sign한다.",  "보험 판매원이 판매통계량을 종합한다." 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 입장에서 이해할 수 있을 정도로 기술을 하여야 한다. 이러한 유스케이스 다이어그램은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.

그림 1 - 유스케이스 다이어그램
(2) 클래스 다이어그램 (Class Diagram)
클래스 다이어그램의 경우 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스들의 속성(Attribute)과 행위(Behavior)를 기입한다. 여기서 클래스들 사이에 여러가지 관계(Relationship)를 가질수 있다. 예를 들어 연관관계(Association)은 클래스와 클래스가 어떠한 연관을 가지고 있음을 나타내고 여기서 세부적으로 복합연관(Composition)과 집합 연관관계 (Aggregation) 등으로 나뉘어 질 수 있다. 이외에 상속관계(Generalization), 의존관계(Dependency)가 나타날 수 있다. 클래스 다이어그램을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기입하고 대충의 관계를 기입하여도 충분할 것이다. 이 단계에서 너무 상세한 내용을 찾고 기입하다 보면 클래스 다이어그램 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다. 이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.

그림 2 - 클래스 다이어그램
(3) 시퀸스 다이어그램 (Sequence Diagram)
시퀸스 다이어그램은 콜레버레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는 메시지를 나타내게 된다. 콜레버레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램 만의 특징이라면 횡축을 시간축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고있다.

그림 3 - 시퀀스 다이어그램
(4) 콜레버레이션 다이어그램 (Collaboration Diagram)
콜레버레이션 다이어그램 또한 시퀸스 다이어그램과 함께 메시지의 흐름을 나타낸다. 하지만 콜레버레이션 다어그램은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 클래스의 인스턴스인 객체를 표기하는 다이어그램이 명시적으로 존재하지 않는다. 이러한 객체들 사이의 관계를 나타내기 위해 별도로 오브젝트 다이어그램(Object Diagram)을 사용하여도 되지만 오브젝트 다이어그램은 클래스 다이어그램과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어있지 않다. 갑자기 이러한 오브젝트 다이어그램을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 클래스 다이어그램과 거의 동일한 오브젝트 다이어그램을 그리기 보다는 특별히 클래스 다이어그램과 차이점이 되는 부분을 여기 콜레버레이션 다이어그램에 기입하는 것이 좋을 것이다.

그림 4 - 콜레버레이션 다이어그램
(5) 상태 다이어그램 (Statechart Diagram)
상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행시 객체의 상태는 메시지를 주고 받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다.  실제 시스템에서 실행시 많은 객체가 생성되고 소멸된다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다.  결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간동안의 상태를 표시하여야 한다.

그림 5 - 상태 다이어그램
(6) 액티비티 다이어그램 (Activity Diagram)
액티비티 다이어그램은 플로우챠트가 UML에 접목이 되었다면 가장 이해가 빠를 것이다.  시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다. 이러한 액티비티 다이어그램에서 기존 플로우 챠트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우챠트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다라고 보아도 좋다.

그림 6 - 액티비티 다이어그램
(7) 디플로이먼트 다이어그램 (Deployment Diagram) 과 컴포넌트 다이어그램 (Component Diagram)
이 두 다이어그램은 시스템의 물리적인 부분의 구성을 나타낸다. 디플로이먼트 다이어그램은 실제 하드웨어적인 배치와 연결상태를 나타낸다. 그리고 컴포넌트 다이어그램은 소프트웨어의 물리적 단위(Exe, dll 등 기타 library)의 구성과 연결상태를 나타내게 된다.

그림 7 - 디플로이먼트 다이어그램

그림 8 - 컴포넌트 다이어그램
3. 이외의 사항들
지금까지 UML의 다이어그램적인 구성에 대하여 알아보았다. 하지만 UML은 이러한 다이어그램적인 사항이 아닌 확장을 위한 여러가지 도구들을 준비되어있다. 예를들어 스테레오타입(Stereotype)이나 컨스트레인트(Constraint) 등의 의미적 변환을 위한 도구가 있다. 그리고 UML은 의미적인 무결성을 위해 메타모델을 위해 준비해 두었다. 이제 전체적인 UML의 구성이 어떻게 되어있는지 알수 있을 것이다.  다음 회부터 본격적으로 UML의 세부적 사항을 요목조목 알아보도록 하겠다.

이 글에 삽입된 다이어그램은 “Plastic Software”의 UML 모델링 툴인 “PLASTIC 2.0”을 이용하여 그렸다.

2008. 10. 1. 15:56

UML 강좌




UML1) ?
객체지향 분석/설계 산물(artifacts)을 위한, 표준화된 notation
Not a method
Not a development process
UML은 모델링 언어의 통합을 위한 표준
UML은 s/w를 시각화, 명세화, 문서화하기 위한 언어
UML은 시스템의 여러 분야를 포함
데이터 모델링(Entity Relationship Diagram)
객체 모델링
Component 모델링