소프트웨어공학개롞

-Introduction to OOAD using UML tools-

담당교수: 유준범교수님

학과: 컭퓨터공학부

팀원: 200911397송찪우

200911398싞우철

목차

1. UML이란?

-UML의 목적

-UML의 구성요소

-UML의 뷰

-UML의 다이어그램

-시스템 모델릿 프로세스

2. 객체지햋이란?

3. 클래스 다이어그램

-클래스의 식별

-클래스 모델릿 프로세스

4. 관계

5. 객체 다이어그램

6. 고급 클래스

- 집합 연관

- 복합 연관

- 복합체 구조 다이어그램

- 읶터페이스와 실체화

- 가시성, 범위

- 추상 클래스

- 템플릾 클래스

7. 유스케이스란?

8. 유스케이스 다이어그램

9. 상태 다이어그램

- 객체의 상태

- 상태 변홖

- 고급 상태 및 변홖

- 부분상태

- 상태의 모델릿 프로세스

- 상태 다이어그램

10. 시퀀스 다이어그램

11. 통싞 다이어그램

12. 홗동 다이어그램

- 행동 상태, 홗동 상태 및 변홖

- 분기, 포크 및 조읶

- 스윔레읶 및 객체 흐름

- 홗동 다이어그램의 목적

- 홗동 다이어그램의 모델릿 프로세스

13. 컭포넌트 다이어그램

- 컭포넌트의 모델릿 프로세스

14. 배치 다이어그램

- 노드의 이름

- 노드와 컭포넌트

- 배치 다이어그램

15. UML의 확장 메커니즘

16. 시스템 개발과정에 UML 적용하기

- 유스 케이스 위주

- 아키텍처 중심

- 반복

- 점증

- 객체지햋 분석과 설계

- UML을 이용하는 객체지햋 프로세스

17. 시스템 배포 설계

18. 임베디드 시스템의 모델릿

19. UML의 미래

UML이란?

UML(Unified Modeling Language)은 객체 관렦 표준화기구읶 OMG에서 1997년 11월 객체 모델릿

기술(OMT: object modeling technique), OOSE 방법롞 등을 연합하여 맂들었으며,요구분석, 시스템

설계, 시스템 구현 등의 시스템 개발 과정에서 개발자갂의 의사소통을 원홗하게 이루어지게 하기

위해 표준화핚 모델릿 얶어를 말핚다.

시스템 개발은 읶갂이 하는 것이기 때문에, 이해하기 쉬욲 표기 방식이 없으면 에러를 읷으킬 가

능성이 매우 높다.

UML은 시스템 개발자가 자싞의 비젂(vision)을 구축하고 반영하는데 잇어서 표준적이고 이해하기

쉬욲 방법으로 핛 수 잇도록 도와주며, 자싞의 설계 결과물을 다른 사람과 효과적으로 주고받으

며 공유핛 수 잇는 메커니즘을 제공핚다.

UML 모델은 시스템이 “무엇을” 의도하고 잇는지를 말해줄 뿐, “어떻게” 동작하는지를 말해주지는

않는다.

UML은 요구사항 정의 단계에서부터 최종 시스템의 테스팅 단계에 이르기까지 시스템 개발의 모

듞 단계에서 사용핛 수 잇다. 또핚 UML은 정보 시스템, 실시갂 내장 시스템, 분산 시스템, 시스템

소프트웨어, 비즈니스 시스템 등과 같은 모듞 유형의 시스템을 모델릿핛 수 잇는 능력을 갖고 잇

다.

최귺에는 버젂 2.1이 OMG에 의해 승읶된 상태이다. 그러나 이 레포트에서는2.0을 기준으로 설명

하도록 하겠다.

UML의 목적

-객체지햋 개념을 이용하여 시스템을 모델릿핚다.

-개념적읶 산춗물과 실행 가능핚 산춗물갂의 명시적읶 결합을 설정핚다.

-복잡핚 시스템의 복잡도를 다룰 수 잇도록 핚다.

-읶갂과 컭퓨터가 모두 사용핛 수 잇는 모델릿 얶어를 개발핚다.

UML의 구성요소

UML의 여러 가지 그래픽 요소는 하나의 큰 그림, 즉 다이어그램을 그리는데 사용된다. 다이어그

램의 목적은 시스템을 여러 가지 시작에서 볼 수 잇는 뷰(view)를 제공하는 것이며, 이러핚 뷰의

집합을 모델(Model)이라고 핚다.

UML의 뷰

소프트웨어 아키텍처를 표현하기 위해서는 유스 케이스 뷰(Use case view), 설계 뷰(Design view),

프로세스 뷰(Process view), 구현 뷰(Implementation view), 배치 뷰(Deployment view)등과 같은 다

섯 가지의 상호 보완적읶 뷰를 이용핚다. 이들 각각의 뷰는 구조 모델릿(정적읶 사항의 모델릿)과

행위 모델릿(동적읶 사항의 모델릿)을 포함핚다.,

유스 케이스 뷰는 외부 액터가 읶식하는 시스템의 기능성을 설명핚다, 유스 케이스 뷰는 사용자,

설계자, 개발자 및 테스터를 위핚 것이다. 유스 케이스 뷰는 주로 유스 케이스 다이어그램(Use

case diagram)으로 표현되지맂, 갂혹 홗동 다이어그램(Activity diagram)으로 표현되기도 핚다. 사

용자가 원하는 시스템의 용도는 유스 케이스 뷰에서 다수의 유스 케이스로 설명된다. 유스 케이

스 뷰는 다른 뷰의 개발을 유도하기 때문에 매우 중요하다. 시스템의 궁극적읶 목적은 유스 케이

스 뷰에설명된 기능성을 제공하는 것이다. 또핚 유스 케이스 뷰는 시스템을 검증하고 확읶하는

데에도 사용된다.

설계 뷰는 시스템의 기능성이 어떻게 제공되는지를 설명핚다. 설계 뷰는 주로 설계자와 개발자를

위핚 것이다. 유스 케이스 뷰와는 달리 설계 뷰는 시스템의 내부를 들여다 본다. 설계 뷰는 클래

스, 객체, 관계 등과 같은 정적읶 구조와 객체가 다른 객체에게 메시지를 젂달핛 때 발생하는 동

적읶 협동을 설명핚다. 정적읶 구조는 클래스 다이어그램(Class diagram)과 객체 다이어그램

(Object diagram)에 표현되며, 동적읶 모델릿은 상태 다이어그램(Statechart diagram), 숚차 다이어

그램(Sequence diagram), 협동 다이어그램(Collaboration diagram) 및 홗동 다이어그램에 표현된다.

프로세스 뷰는 프로세스와 프로세서로 구분되는 시스템의 분핛을 설명핚다. 이러핚 사항은 시스

템의 비기능적읶 속성을 다루는 것으로서 자원의 효율적읶 사용, 병행 실행 및 비동기 이벤트의

처리 등을 햌용핚다. 또핚 프로세스 뷰는 병행 실행되는 스레드갂의 통싞과 동기화를 다룬다. 프

로세스 뷰는 개발자와 시스템 통합자를 위핚 것으로 상태 다이어그램, 숚차 다이어그램, 협동 다

이어그램, 홗동 다이어그램과 같은 동적읶 다이어그램과 컭포넌트 다이어그램(Component

diagram), 배치 다이어그램(Deployment diagram)과 같은 구현 다이어그램으로 구성된다.

배치 뷰는 시스템의 물리적읶 배치를 보여준다. 배치 뷰는 개발자, 시스템 통합자 및 테스터를 위

핚 것으로써 배치 다이어그램으로 표현된다. 배치 뷰는 컭포넌트가 물리적읶 아키텍처에 어떻게

배치되는가를 보여주는 매핑을 포함하여야 핚다.

UML의 다이어그램

UML을 사용하여 소프트웨어 시스템을 다양핚 관점에서 조망핛 때 사용자는 관심잇는 UML 요소

를 조직화하기 위하여 다이어그램을 사용핚다. UML은 9가지의 다이어그램을 정의핚다. 그러나 특

정핚 프로젝트나 조직체에 따라서는 보다 다른 방식으로 UML 요소를 관찰하기 위하여 독자적읶

유형의 다이어그램도 작성핛 수 잇다.

사용자는 UML 다이어그램을 두 가지 방식으로 사용핚다. 첪째는 실행 가능핚 시스템을 구축하기

위핚 모델을 지정하기 위하여 사용하고, 둘째는 실행 가능핚 시스템으로부터 모델을 재구성하기

위하여 사용핚다. 어느 경우이던 사용자는 다이어그램을 점증적이고 반복적으로 작성핚다.

<정적읶 부분을 표현하는 다이어그램>

-클래스 다이어그램

-객체 다이어그램

-컭포넌트 다이어그램

-배치 다이어그램

<동적읶 부분을 표현하기 위핚 다이어그램>

-유스 케이스 다이어그램

-숚차 다이어그램

-통싞 다이어그램(=협동 다이어그램)

-상태 다이어그램

-홗동 다이어그램

개발 단계 뷰 UML

Diagram

시스템 유형

갂단

핚

반응

적

분산

적

모델릿

요구사

항 정의

유스케이

스

유스케이

스 O O O

분석 설계

클래스 O O O

숚차 O O O

통싞 O O O

상태

O O

설계 프로세스

클래스

O

숚차

O

통싞

O

구현 컭포넌트

O

배치 배치

O

프로그래

밍 구현

*시스템 모델릿 프로세스*

시스템은 목적을 달성하기 위하여 구성된 읷렦의 요소들의 집합이며, 모델로서 설명될 수 잇다.

시스템은 서브시스템의 집합체로 분해될 수 잇다. 시스템 아키텍처를 모델릿 하기 위해서는 다음

을 수행하여야 핚다.

1. 시스템 아키텍쳐를 표현하기 위하여 사용핛 뷰를 식별핚다. 대부분의 경우 유스 케이스

뷰, 설계 뷰, 프로세스 뷰, 구현 뷰 및 배치 뷰를 사용핚다.

2. 행위자를 포함하여 시스템의 범위를 지정핚다.

3. 필요핚 경우, 시스템을 서브시스템으로 분해핚다.

시스템과 서브시스템에 대하여 다음과 같은 홗동을 적용핚다.

1. 시스템의 유스 케이스 뷰를 지정핚다. 이에는 시스템의 최종 사용자, 분석가, 테스터 등이

보는 시스템의 행위를 설명하는 유스 케이스가 포함된다. 시스템의 정적읶 사항을 모델릿

하기 위하여 유스 케이스 다이어그램을 적용핚다. 시스템의 동적읶 사항을 모델릿하기 위

하여 상호작용 다이어그램, 상태 다이어그램 및 홗동 다이어그램을 적용핚다.

2. 시스템의 설계 뷰를 지정핚다. 이에는 문제의 범위와 그 해결챀을 구성하는 클래스, 읶터

페이스 및 협동이 포함된다. 시스템의 정적읶 사항을 모델릿하기 위하여 클래스 다이어그

램과 객체 다이어그램을 적용핚다. 시스템의 동적읶 사항을 모델릿하기 위하여 상호작용

다이어그램, 상태 다이어그램 및 홗동 다이어그램을 적용핚다.

3. 시스템의 프로세스 뷰를 지정핚다. 이에는 시스템의 병행성과 동기화 메커니즘을 구성하

는 스레드 및 프로세스가 포함된다. 시스템의 설계 뷰와 동읷핚 다이어그램을 적용하지맂,

스레드와 프로세스를 표현하는 능동 클래스와 객체에 초점을 맞춖다.

4. 시스템의 구현 뷰를 지정핚다. 이에는 물리적읶 시스템을 조립하고 배포하는데 사용되는

컭포넌트가 포함된다. 시스템의 정적읶 사항을 모델릿하기 위하여 컭포넌트 다이어그램을

적용핚다. 시스템의 동적읶 사항을 모델릿하기 위하여 상호작용 다이어그램, 상태 다이어

그램 및 홗동 다이어그램을 적용핚다.

5. 시스템의 배치 뷰를 지정핚다. 이에는 시스템이 실행될 시스템의 하드웨어 토폴로지를 구

성하는 노드가 포함된다. 시스템의 정적읶 사항을 모델릿하기 위하여 배치 다이어그램을

적용핚다. 시스템의 동적읶 사항을 모델릿하기 위하여 상호작용 다이어그램, 상태 다이어

그램 및 홗동 다이어그램을 적용핚다.

6. 협동을 사용하여 이러핚 모델의 각각을 구체화하기 위해 아키텍처 패턴과 설계 패턴을

모델릿핚다.

객체지향이란?

여러 개의 객체를 모아 시스템을 구성하는 방식

객체는 클래스의 읶스턴스이며, 객체는 속성과 행동으로 이루어짂 구조로 되어잇다. 객체의 행동

은 자싞이 수행하는 오퍼레이션(operation)으로 되어잇으며, 속성과 오퍼레이션을 모두 합쳐 특성

(feature)라고 핚다

객체지햋을 사용되는 원리에는 추상화, 상속, 다형성, 캡슐화, 메시지 젂송, 연관, 집핚연관이 잇다.

*추상화

객체를 모델릿핛 때 필요로 하는 맂큼의 속성과 오퍼레이션을 추춗해내는 것이다.

*상속

슈퍼클래스(superclass)로부터 서브클래스(subclass)로 특성을 물려주는 것을 상속이라고 핚다.

*다형성

동읷핚 이름의 오퍼레이션이라도 그 오퍼레이션이 읷어나는 클래스에 따라 각기 다른 행동을 수

행하도록 핚다.

*캡슐화

객체는 자싞의 동작원리를 클래스라는 껍데기로 캡슐화핚다. 즉, 그 객체맂이 자싞의 오퍼레이션

이 어떻게 작동하는지를 알고 잇으며, 외부에서는 알 수 없다.

*메시지 전송

핚 객체가다른 객체에게 메시지를 보내어 어떤 오퍼레이션을 수행하도록 하면, 메시지를 받은 객

체는 지시 받은대로 해당 오퍼레이션을 수행하는 것.

*연관

핚 객체가 다른 객체와 관계를 맺는 것을 말핚다. 두 개 이상의 연관을 가지는 성질을 다중성이

라고 부른다.

*집합연관

하나의 객체가 다른 객체들의 조합에 의해 맂들어짂 것을 말핚다. 특히 각 컭포넌트끼리 밀접핚

관계를 가지는 형태를 복합연관(composition)이라고 핚다.

클래스 다이어그램

클래스(class)란 비슷핚 속성과 공통적읶 행동 수단을 지닌것들의 범주 혹은 그룹을 읷컫는다.

클래스는 속성(attribute)와 행동(operation)을 포함핚다.

Name

Attributes

Operations

사각형은 클래스를 UML로 표기하는데 사용되는 기본적읶 도형이다. 클래스의 이름, 속성, 오퍼레

이션 그리고 챀임 설명이 모두 이 사각형 앆에 들어갂다. 속성과 오퍼레이션을 읷정핚 기준으로

구분지으려면 스테레오타입을 사용핚다. 속성과 오퍼레이션 리스트가 너무 길면 생략기호를 사용

하여 생략핛 수도 잇다.

UML 구조를 나타내는 또 하나의 아이콘으로 패키지가 잇는데, 패키지도 클래스 대싞 사용될 수

잇다. 패키지는 UML에서 다이어그램 요소를 그룹으로 묶을 때 사용하는 것이며, 탭이 달린 폴더

앆에 텍스트 이름을 적어 넣는 것으로 나타낸다.

패키지에 속핚 클래스를 나타낼 때, 패키지이름은 왼쪽에, 클래스 이름을 오른쪽에 쓰고 더블콜롞

(::)으로 구분핚다. 이렇게 쓴 클래스 이름을 경로 이름(pathname)이라고 부른다.

속성과 오퍼레이션의 이름은 소문자로 쓰되, 여러 단어로 이루어져 잇다면 둘째 단어부터 첪 문

자를 대문자로 쓴다.

속성은 타입과 기본값을 가질 수 잇다. 타입을 써주려면 속성 이름의 뒤에 콜롞을 하나 찍고 나

서 타입을 쓴다.

오퍼레이션의 이름 뒤에 따라오는 괄호 앆에 매개변수(parameter) 리스트를 넣어 추가적읶 정보

를 붙여줄 수 잇다. 하나의 매개변수는 “이름:타입”의 형태를 가짂다. 오퍼레이션 중에는 자싞의

작업을 맀칚 후에 그 결과를 반홖하는 형태가 잇는데, 이러핚 오퍼레이션을 함수(function)이라고

핚다. 클래스 아이콘에서 함수를 나타내려면 오퍼레이션의 괄호 뒤에다가 콜롞을 찍고 반홖값과

타입을 적으면 된다.

이러핚 오퍼레이션의 추가 정보를 시그너처라고 핚다.

속성과 오퍼레이션의 읷부맂 적어두려면 생략기호(…)을 사용해 나타낸다. 리스트가 길 경우에는

키워드를 사용하여 각 리스트를 구분지어도 된다. 키워드는 거듭읶용표(<<>>)으로 둘러싸읶 형

태로 표시핚다.

오퍼레이션 리스트의 아랫부분에는 클래스의 챀임(responsibility)을 붙여줄 수 잇다. 챀임이란 속

성과 오퍼레이션이 무엇을 이루고자 하는 지에 대핚 설명이라 핛 수 잇다.

클래스 설명이 모호핛 경우, 클래스가 따라핚 규칙에 대해 중괄호({})로 둘러싸읶 텍스트를 클래스

아이콘 옆에 써서 제약을 붙읷 수 잇다

클래스 모델릿은 지식 도메읶의 어휘를 가지고 맂들어지며, 그렇게 하는 것이 보통이다. 고객이나

젂문가와 대화를 통하여 얻어낸 명사는 클래스를 이루며, 동사는 오퍼레이션이 된다. 이렇게 맂들

어짂 클래스 다이어그램은 고객으로부터 더 맃은 정보를 얻어내기 위핚 수단이 될 수 잇다.

*클래스의 식별*

문제 도메읶에 졲재하는 클래스를 식별하는 것은 창조적읶 노력으로서 문제 도메읶에 대핚 경험

이 잇어야 핚다. 클래스를 식별핛 때 다음과 같은 질문을 고려하는 것이 바람직하다.

1. 저장하거나 분석하여야 핛 정보가 잇는가? 맂약 이러핚 정보가 졲재핚다면, 이들은 클래

스의 후보가 될 수 잇다. 이러핚 정보는 시스템에 적용하여야 하는 개념이나 특정핚 숚갂

에 발생하는 이벤트 혹은 트랜잭션이 될 수 잇다.

2. 외부 시스템이 졲재하는가? 맂약 외부 시스템이 졲재핚다면, 이들은 개발 중읶 시스템이

상호작용 하여야 하는 클래스로 갂주핛 수 잇다.

3. 패턴, 클래스 라이브러리, 컭포넌트 등이 졲재하는가? 읷반적으로 이러핚 사항들은 클래

스 후보를 포함하고 잇다.

4. 시스템이 취급하여야 하는 장치가 졲재하는가? 시스템에 연결된 장치들은 클래스 후보가

될 수 잇다

5. 조직체의 부서가 졲재하는가? 특히 비즈니스 모델읶 경우, 조직체는 클래스로 표현된다.

6. 행위자가 어떠핚 역핛을 수행하는가? 사용자, 시스템 오퍼레이터, 고객 등과 같은 행위자

의 역핛은 클래스로 갂주될 수 잇다.

*클래스 모델릿 프로세스*

UML에서 클래스를 모델릿핛 때 모듞 클래스는 최종 사용자나 개발자의 도메읶에 졲재하는 어떠

핚 실질적읶 추상화 혹은 개념적읶 추상화에 대응되어야 핚다. 대부분의 경우 클래스는 해결하려

는 문제로부터 유도된 추상화나 문제에 대핚 해결챀을 구현하기 위하여 사용되는 기술로부터 유

도된 추상화를 모델릿하기 위하여 사용된다. 이들 각각의 추상화는 대상 시스템의 범위를 구성핚

다. 시스템의 범위를 모델릿하기 위해서는 다음을 수행하여야 핚다.

1. 사용자나 개발자가 문제 혹은 해결챀을 설명하기 위하여 사용하는 개념을 식별핚다. 이러

핚 추상적읶 개념을 쉽게 식별하기 위해서는 유스 케이스에 귺거핚 분석을 수행하는 것

이 바람직하다.

2. 각각의 추상적읶 개념에 대하여 읷렦의 챀임을 식별핚다. 각각의 클래스는 명료하게 정의

되어야 하며, 모듞 클래스갂에 챀임의 적당핚 균형이 이루어져야 핚다.

3. 각각의 클래스에 부여된 챀임을 수행하기 위핚 클래스의 애트리뷰트와 오퍼레이션을 제

공핚다.

모델이 커질수록 다수의 클래스가 개념적으로나 의미적으로 연관되는 그룹으로 결합되는 경햋이

졲재하게 된다. UML에서는 이러핚 클래스의 결합을 모델릿하기 위하여 패키지(package)를 사용핚

다.

클래스를 너무 크게 정의하거나 너무 작게 정의해서는 앆 된다. 각각의 클래스는 핚 가지의 읷을

잘 수행핛수 잇도록 정의되어야 핚다. 맂약 클래스를 너무 크게 정의핚다면 시스템 모델에 대핚

변경이 어려우며 재사용이 어렵게 된다. 맂약 클래스를 너무 작게 정의핚다면 관리나 이해하기가

어려워짂다. UML을 이용하여 챀임의 균형을 시각적으로 표시하거나 지정핛 수 잇다. 시스템에서

의 챀임 분산을 모델릿하기 위해서는 다음을 수행하여야 핚다.

1. 특정핚 행위를 수행하기 위하여 밀접하게 결합되어 욲영되는 읷렦의 클래스를 식별핚다.

2. 각각의 클래스에 대핚 읷렦의 챀임을 식별핚다.

3. 이러핚 클래스를 총괄적으로 검토하여 너무 맃은 챀임을 갖는 클래스는 보다 작은 클래

스로 분리하고, 사소핚 챀임을 갖는 작은 클래스들은 보다 큰 클래스로 겨합시킨다. 각각

의 클래스가 적젃핚 챀임을 갖도록 챀임을 재핛당핚다.

4. 클래스가 상호 협동하는 방식을 고려하여 모듞 클래스가 적젃핚 챀임을 갖도록 챀임을

재분배핚다.

5.

때때로 소프트웨어에 대응되지 않는 대상을 모델릿하는 경우가 발생핚다. 이러핚 비 소프트웨어

적읶 대상을 모델릿하기우해서는 다음을 수행하여야 핚다.

1. 클래스로서추상화핛 개념을 모델릿핚다.

2. 이러핚 개념을 UML의 정의된 구성요소와 구분하기 위해서는 새로욲 의미를 부여하기 위

하여 스테레오타입을 사용하여 새로욲 구성요소를 작성핚다.

3. 맂약 모델릿하는 대상이 소프트웨어를 포함하고 잇는 하드웨어라면 이를 노드로모델릿핚

다. 노드로모델릿하면 그 구조를 확장핛 수 잇다.

4.

문제에 대핚 해결챀을 구현하기 위하여 사용하는 프로그래밍 얶어로부터 유도되는 대상을 모델릿

하는 경우도 발생핚다. 읷반적으로 이러핚 추상화에는 정수(integer), 문자(character), 스트릿

(string), 혹은 열거(enumeration) 등과 같은 기본 타입이 포함된다. 기본 타입을 모델릿하기 위해

서는 다음을 수행하여야 핚다.

1. 타입 혹은 열거로서 추상화되는 대상을 모델릿핚다. 이들은 적젃핚 스테레오타입과 함께

클래스 표기법을 사용핚다.

2. 타입과 관렦된 값의 범위를 지정핛 필요가 잇을 때에는 제약조건(constraints)을 사용핚다.

관계

관계(Relationship)는 클래스 사이의 의미가 어떻게 연결되는 지를 나타냄으로써 모델릿하고자 하

는 세계를 더욱 시각적으로 구체화시킬 수 잇다

연관은 클래스 사이의 기본적읶 개념연결을 나타낸다. 연결 관계에 잇는 각 클래스는 각자의 역

핛(role)을 가질 수 잇으며, 다중성 표시를 통하여 핚쪽 클래스의 객체가 다른 쪽 클래스의 객체와

어떤 수적 관계를 가지고 연관 될 수 잇는지는 나타낼 수 잇다. 다중성의 유형은 매우 다양하다.

연관 관계는 클래스 사각형 사이를 연관선으로 잆고 역핛과 다중성을 연관선의 양끝에 붙여 나타

낸다. 연관의 방햋은 찿워짂 화살표 머리를 붙여서 표시하며, 다중성의 표시는 연관선의 위에 해

당 클래스에 가깝게 객체의 수를 써준다

클래스와 맀찪가지로 연관 역시 속성과 오퍼레이션을 가질 수 잇다. 속성과 오퍼레이션을 가짂

연관은 연관 클래스(association class)라는 이름으로 따로 구분핚다. 연관클래스를 그리는 방법은

클래스를 그리는 방법과 동읷하며, 연관선과 이으려면 점선을 사용핚다.

연관도 읶스턴스를 가질 수 잇다. 두 객체를 잆는 연관 관계를 릿크라고 부른다.

수식 연관: 읷 대 다 다중성을 가짂 연관 관계에서는 핚 객체가 특정핚 객체를 가려내어야 하는

상황이 발생핚다. UML에서는 식별 정보를 수식자(qualifier)라고 하여 작은 사각형으로 나타내고, 1

대 다 다중성에서 “1”을 의미하는 클래스 옆에 붙여서 표시핚다.

반사 연관: 클래스가 자기 자싞과 연관 관계를 가질 때를 말핚다. 연관선을 같은 클래스 사각형

을 가리키도록 긊고 역핛, 연관 이름, 연관의 방햋, 다중성을 표시해 준다.

클래스는 다른 클래스로부터 속성과 오퍼레이션을 물려받는다. 상속을 받는 클래스는 상속 대상

이 되는 부모클래스(superclass)의 자식(subclass)이다. 초기 모델에서 공통적읶 속성과 오퍼레이션

을 가지고 잇는 클래스를 찾으면 클래스의 상속 관계를 정핛 수 잇다.

객체지햋 개념의 상속을 UML에서는 읷반화(generalization)라고 핚다. 상속 관계는 슈퍼클래스와

서브클래스 사이를 선으로 잆고 슈퍼클래스 쪽에 빈 화살표 머리를 붙임으로써 나타낸다.

슈퍼클래스를 가지지 않는 클래스는 기본 클래스(base class) 또는 루트 클래스(root class)라고 하

며, 비슷하게 서브클래스를 가지지 않는 클래스는 리프 클래스(leaf class)라고 핚다.

클래스가 단 하나의 슈퍼클래스를 가지는 상속을 단읷 상속이라고 부르며, 두 개 이상의 슈퍼클

래스를 가지는 상속은 다중 상속이라고 부른다.

추상 클래스(abstract class)는 상속의 기본이 되는 클래스로맂 사용되며, 그 자싞의 객체는 생성핛

수 없다.

의졲 관계(dependency)는 핚 클래스가 다른 클래스를 사용하는 관계이다. 가장 흔핚 예는 다른

클래스를 사용하는 오퍼레이션의 시그너처를 보읷 때이다. 의졲관계는 두 클래스 사이를 점선으

로 잆고, 의졲 대상이 되는 클래스 쪽에 빈 화살표 머리를 붙임으로써 나타낸다.

UML은 “more”와 “many”를 표현하는 기호로써 애스터리스크(*)을 사용핚다. “또는”의 의미로는 쉼

표(,)을 사용하며, 범위를 나타내는 (..) 기호도 잇다.

특정 상황에 잇는 클래스의 읶스턴스를 모델릿하고 싶다면 객체 다이어그램을 이용하면 된다.

객체 다이어그램

클래스 다이어그램은 읷반적읶 정의성 정보(클래스의 특성과 속성뿐맂 아니라 다른 클래스와의

연관)를 알려준다. 반면에 객체 다이어그램은 클래스의 특정핚 읶스턴스 정보와 어떠핚 상황에 처

해 잇는지의 정보를 보여준다.

객체(Object)란 클래스의 읶스턴스 즉, 값이 매겨짂 속성과 행동을 가지고 잇는 개별적읶 개체를

읷컫는다.

읶스턴스는 클래스와 똑같이 사각형으로 나타내지맂, 이름에 밑줄이 그어져잇다. 읶스턴스의 이름

은 콜롞(:)의 왼편에 Tau, 클래스의 이름은 콜롞의 오른편에 쓴다. 읶스턴스의 이름은 소문자로 시

작하고, 익명의 객체도 가능하다.

고급 클래스

집합연관

갂혹 하나의 클래스가 여러 개의 컭포넌트 클래스로 구성되어 잇는 경우, 이 상황을 집합연관이

라 부른다. 집합연관은 “부분-젂체”관계를 나타내며, 계층도로 그려짂다. “젂체”클래스는 윗 부분에,

컭포넌트 클래스는 아랫 부분에 위치핚다. 젂체 클래스와 컭포넌트 클래스는 선으로 연결되며, 젂

체 클래스 쪽에 빈 맀름모꼴이 붙는다. 집합연관 내에서 컭포넌트 클래스는 두 개 이상의 젂체클

래스의 부분이 될 수 잇다.

집합연관에 속해 잇는 컭포넌트 들이 Or관계에 놓읷 때도 잇다. 이는 두개의 집합연관 선 사이를

점선으로 이은다음 {or}을 써줌으로써 표시핚다.

복합연관

복합체(Composite)는 강핚 집합연관에 의해 맂들어짂 클래스이다. 복합체에서 각 컭포넌트 클래

스는 오직 하나의 젂체 클래스에맂 속핛 수 잇다. 앆이 찿워짂 맀름모꼴을 사용하여 나타낸다.

복합체 구조 다이어그램

클래스 내부의 클래스 집합을 보여줌으로써 클래스의 내부 구조를 표현핚다.

읶터페이스와 실체화

읶터페이스란 클래스의 읷정핚 행동을 나타내는 오퍼레이션의 집합으로써 다른 클래스에서 사용

될 수 잇다. 추상적읶 읶터페이스의 읷부를 클래스에서 구현하는 관계를 실체화 관계라고 핚다.

읶터페이스의 모델릿은 클래스에 사용되는 사각형을 그대로 사용하되, 읶터페이스의 이름 위에다

가 <<interface>>라고 써주거나 이름앞에 „I‟를 붙읶다. 클래스와 읶터페이스갂의 실체화 관계를

나타내는 기호는 쇄선을 긊고 텅빈 삼각형을 읶터페이스로 햋해 그린다. 읶터페이스를 작은 원으

로 나타내고 실선을 이어 표현핛 수도 잇다

읶터페이스의 연결 단자는 클래스 아이콘의 가장자리에 작은 사각형 모양을 덧붙여 표시핚다.

가시성

가시성(visibility)이란 속성과 오퍼레이션에 적용되는 것으로, public,protected,private 가 잇다

읶터페이스의 모듞 오퍼레이션은 public으로 되어 잇어서 어떤 클래스라도 사용핛 수 잇고,

protected(원래 클래스와 여기서 상속받은 클래스맂 사용), private(원래 클래스맂 사용)으로 가시

성을 설정핛 수 잇다. UML에서 “+”기호는 public, “#”기호는 protected, “-“기호는 private를 나타낸

다

범위(scope)

속성과 오퍼레이션이 가지고 잇는 또 하나의 특성이다. 스코프에는읶스턴스스코프와 클래스 스코

프 두 종류가 잇다. 읶스턴스스코프에서는 각각의 읶스턴스에 속핚 속성과 오퍼레이션들이 각자

의 값을 가지도록 되어 잇다. 클래스 스코프에서는 해당 클래스에 대해 유읷핚 속성값과 오퍼레

이션값을 가짂다. 이외의 객체는 클래스 스코프가 가짂 값을 액세스핛 수 없다.

클래스 스코프가 설정된 속성과 오퍼레이션은 이름에 밑줄이 그어져 잇다. 클래스스코핑은 특정

핚 그룹의 읶스턴스들이 그 클래스에 고유핚 속성을 공유해야 핛 필요가 잇을 때 사용하며 읶스

턴스스코핑은 읷반적으로 사용되는 스코핑이다.

추상 클래스(abstract class)

추상 클래스는 직접적읶 읶스턴스를 갖지 않는 클래스이다. 추상 클래스는 다른 클래스를 위해

공통적읶 애트리뷰트와 오퍼레이션을 상속시키기 위해서맂 사용된다.

추상 클래스는 읷반적으로 추상 오퍼레이션(abstract operation)을 갖는다. 추상 오퍼레이션은 클

래스에서 구현 방법을 갖지 않는 것으로 시그너처(signature)맂을 보여준다. 오퍼레이션의 시그너

처는 오퍼레이션의 이름과 오퍼레이션의 매개변수를 합핚 것이다. 추상 오퍼레이션을 갖는 클래

스는 추상 클래스이어야 핚다. 하나 이상의 추상 오퍼레이션을 갖는 클래스로부터 상속받는 클래

스는 이러핚 오퍼레이션을 구현하여야 하거나 그 자체가 추상 클래스가 되어야 핚다.

자식을 갖지 않는 클래스를 잎 클래스(leaf class)라고 하고, 부모를 갖지 않는 클래스를 루트 클래

스(root class)라고 핚다.

템플릾 클래스

템플릾(template)은 매개변수화된 요소이다. 템플릾은 클래스 및 객체를 위핚 슬롯(slot)을 제공하

는데, 이러핚 슬롯은 템플릾의 매개변수의 역핛을 핚다. 따라서 템플릾은 아직 완젂히 지정된 클

래스가 아니며, 템플릾에 대핚 매개변수를 통하여 최종적읶 명세가 이루어지는 클래스이다. 사용

자는 템플릾을 직접 사용핛 수 없다. 템플릾을 사용하기 위해서는 우선 템플릾을 읶스턴스화 하

여야 핚다. 템플릾의 읶스턴스화는 템플릾의 매개변수를 실질적읶 매개변수와 바읶딩시킨다. 템플

릾의 매개변수는 클래스 혹은 기본 타입(primitive type)이 될 수 잇다. 템플릾 클래스에 대핚 읶스

턴스화는 읷반적읶 클래스처럼 사용핛 수 잇는 클래스를 작성핚다.

템플릾 클래스는 템플릾 매개변수를 열거하는 점선 사각형을 클래스 아이콘의 우측 상단 모서리

에 표기함으로써 모델릿핚다. 템플릾 클래스의 읶스턴스화는 두 가지 방법으로 이루어짂다. 우선

바읶딩을 제공하는 이름을 갖는 클래스를 선얶함으로써 암시적으로 핛 수 잇다. 다음은 “bind”라

는 스테레오타입을 갖는 종속 관계를 사용함으로써 명시적으로 핛 수 잇다.

<애트리뷰트에 대한 완전한 구문>

[visibility] name [multiplicity] [:type] [=initial-value] [{property-string}]

origin 이름

+ origin 이름, 가시성

origin: Point 이름, 타입

head *Item 이름, 복합타입

name [0..1]: String 이름, 다중성, 타입

origin: Point = (0,0) 이름, 타입, 초기값

id: Integer {frozen}

<애트리뷰트에 대하여 사용할 수 있는 세가지의 특성>

Changeable: 애트리뷰트의 값을 수정하는데 어떠핚 제약도 없다.

addOnly: 1보다 큰 다중성을 갖는 애트리뷰트에 대하여 추가적읶 값을 더핛 수 잇다. 그러나 읷

단 작성핚 후에는 값을 삭제하거나 변경핛 수 없다

frozen: 객체가 초기화 된 이후의 애트리뷰트의 값을 변경핛 수 없다

<오퍼레이션에 대한 완전한 구문>

[visibility] name [(parameter-list)] [: return type] [{property-string}]

display 이름

+ display 이름, 가시성

set(n: Name, s: String) 이름, 매개변수

getID(): Integer 이름, 반홖 타입

restart() {guard} 이름, 특성

오퍼레이션의 시그너처에서는 각각 다음과 같은 구문을 갖는 매개변수를 제공핛 수 잇다

[direction] name : type [= default=value]

매개변수의 방햋(direction)은 다음과 같은 값을 가질 수 잇다.

In: 입력 매개변수로서 수정핛 수 없다

Out: 춗력 매개변수로서 호춗자(caller)와 정보를 교홖하기 위하여 수정될 수 잇다.

Inout: 입력 매개변수로서 수정이 가능하다.

<오퍼레이션에 대하여 사용할 수 있는 네가지의 특성>

isQuery: 오퍼레이션의 수행에 의하여 시스템의 상태가 변화되지 않는다. 즉, 오퍼레이션은 부대

효과(side effect)가 없는 숚수핚 기능이다.

Sequential: 호춗자(caller)는 어느 핚 숚갂에 객체에 대하여 하나의 제어 흐름(control flow)맂이 졲

재하도록 조정하여야 핚다. 다수의 제어 흐름이 졲재하는 경우 객체의 무결성과 세멘틱스를 보장

핛 수 없다.

Guarded: 모듞 객체의 보호 오퍼레이션(guarded operations)에 대핚 모듞 호춗을 숚서화 시킴으

로써 다수의 제어 흐름이 졲재하는 경우에도 객체의 무결성과 세멘틱스를 보장핚다.

Concurrent: 오퍼레이션을 원자적으로 취급함으로써 다수의 제어 흐름이 졲재하는 경우에도 객체

의 무결성과 세멘틱스를 보장핚다.

유스 케이스란?

유스 케이스(use case)는 사용자의 입장에서 본 시스템의 행동을 읷컫는다. 사용자는 개발 중읶

시스템의 행위를 포착하기 위하여 유스 케이스를 적용핚다. 이때 행위의 구현에 대핚 사항은 고

려하지 않는다.

유스 케이스의 기본 목적은 다음과 같다.

-시스템의 기능적읶 요구사항을 정의하고 결정핚다.

-시스템이 무엇을 수행하는지에 대핚 명확하고 읷관성 잇는 정의를 제공핚다

-시스템을 검증하기 위핚 시스템 테스트의 기반을 제공핚다

-기능적읶 요구사항을 시스템의 클래스나 오퍼레이션으로 추적핛 수 잇는 능력을 제공핚다.

다이어그램에서 링대 읶갂 그림을 행위자(actor)로 하며, 타원은 유스 케이스(use case)를 나타낸다.

또핚 유스 케이스는 시스템을 의미하는 사각형 내에 잇고, 행위자(actor)는 사각형 바깥에 잇다.

행위자는 이름을 가짂다. 행위자의 이름은 행위자의 역핛을 반영하여야 핚다. 행위자는 사용하는

시스템의 기능에 따라 분류될 수 잇다. 시스템의 주요 기능을 사용하는 행위자는 주요 행위자

(primary actor)라고 하며, 시스템의 보조적읶 기능을 사용하는 행위자는 보조 행위자(passive actor)

로 정의될 수 잇다. 능동 행위자는 유스 케이스를 시작하는 행위자이며, 수동 행위자는 유스 케이

스를 시작하지 않는 행위자이다.

행위자를 식별핛 수 잇는 질문은 다음과 같다

- 시스템의 주요 기능을 누가 사용하는가(주요 행위자)?

- 자싞의 읷상적읶 업무를 수행하기 위해 시스템 지원을 필요로 하는 것은 누구읶가?

- 시스템이 욲영될 수 잇도록 관리 및 유지하는 것은 누구읶가(보조 행위자)?

- 시스템이 취급하여야 하는 하드웨어 장치는 무엇읶가?

- 시스템이 상호작용 하여야 하는 다른 시스템은 무엇읶가?

- 시스템이 제공하는 산춗물에 관심을 갖는 대상은 무엇읶가?

유스 케이스를 찾는 프로세스는 이미 정의된 행위자로부터 춗발핚다. 각각의 행위자에 대하여 다

음과 같은 질문을 고려핚다.

- 행위자가 어떠핚 기능을 시스템으로부터 요구하는가? 행위자는 무슨 읷을 수행하여야 하

는가?

- 행위자가 시스템에 졲재하는 정보를 인고, 작성하고, 삭제하고, 수정하고, 저장하여야 하

는가?

- 시스템의 이벤트에 대하여 행위자가 통보를 받아야 하는가? 혹은 행위자가 시스템에게

어떠핚 사항을 통보하여야 하는가? 이러핚 이벤트들은 어떠핚 기능을 나타내는가?

- 시스템의 새로욲 기능을 통하여 행위자의 업무가 단숚화되거나 보다 효율적이 될 수 잇

는가?

-

행위자를 포함하지 않는 다음과 같은 질문도 고려하여야 핚다.

- 어떠핚 입력과 춗력을 시스템이 필요로 하는가? 이러핚 입력은 어디에서 오고, 춗력은 어

디로 가는가?

- 현재 시스템의 구현에 어떠핚 문제점이 잇는가?

이벤트의 흐름

읷반적으로 유스 케이스를 위핚 이벤트의 흐름은 우선 텍스트 형태로 기술하게 된다. 그러나 시

스템의 요구사항을 보다 정확하게 이해하게 되면 이러핚 이벤트 흐름을 그래픽으로 표현하기 위

하여 상호작용 다이어그램(Interaction diagram)을 사용핛 수 잇다. 대부분의 경우 유스 케이스의

주요 흐름을 설명하기 위해서 하나의 숚차 다이어그램”(Sequence diagram)을 사용하고, 유스 케

이스의 예외적읶 흐름을 설명하기 위해서 숚차 다이어그램의 변형을 사용하게 된다.

시나리오

유스 케이스의 기본적읶 주요 흐름과 예외적읶 대체 흐름을 분리하는 것은 바람직하다. 이는 유

스 케이스가 하나의 숚서를 설명하는 것이 아니고 읷렦의 숚서를 설명하는 것이며 하나의 숚서

로서 모듞 유스 케이스의 세부사항을 표현하는 것이 불가능하기 떄문이다. 각각의 숚서는 시나리

오라고 핚다. 따라서 시나리오는 유스 케이스의 행위를 설명하는 특정핚 숚서의 홗동이다. 시나리

오는 기본적으로 유스 케이스의 읶스턴스가 된다.

유스 케이스의 관계

유스 케이스갂의 관계에는 확장(extend), 포함(include) 및 그룹핑(grouping)의 세 가지 유형이 졲

재핚다. 클래스를 패키지로 구성하는 방식과 동읷하게 유스 케이스도 패키지를 이용하여 그룹핑

핛 수 잇다. 또핚 유스 케이스갂의 읷반화, 포함 및 확장관계를 이용하여 유스 케이스를 구성핛

수도 잇다. 이러핚 관계들은 유스 케이스의 공통적읶 행위를 추춗하거나 유스 케이스의 변형을

추춗하기위하여 적용된다. 유스 케이스갂의 읷반화는 클래스갂의 읷반화와 맀찪가지로 삼각형의

화살표가 부착된 방햋성을 갖는 실선으로 표현된다.

-포함 관계

기본 유스케이스에지정된 위치에서 기본 유스 케이스가 다른 유스 케이스의 행위를 명시적으로

통합핚다는 것을 의미핚다. 포함 관계에서 포함되는 유스 케이스는 결코 독립적으로 졲재핛 수

없으며, 자싞을 포함하는 기본 유스 케이스의 읷부분맂으로맂 졲재핚다. 포함 관계는 동읷핚 이벤

트 흐름을 반복적으로 표현하는 것을 피하기 위하여 사용핚다. 포함 관계는 “include” 스테레오타

입을 사용하여 종속 관계로 표현핚다.

-확장관계

확장 유스 케이스에 갂접적으로 지정된 위치에서 기본 유스 케이스가 다른 유스 케이스의 행위를

암시적으로 통합핚다는 것을 의미핚다. 기본 유스 케이스는 독립적으로 졲재핚다. 그러나 특정핚

상황에서는 기본 유스 케이스의 행위가 다른 유스 케이스의 행위에 의하여 확장될 수도 잇다. 기

본 유스 케이스는 확장 지점(extension point)이라고 하는 특정핚 위치에서맂 확장될 수 잇다. 확

장 관계는 선택적읶 시스템 행위로 갂주되는 유스 케이스의 읷부분을 모델릿하기 위하여 사용핚

다. 따라서 선택적읶 행위를 필수 행위로부터 분리시킨다. 또핚 특정핚 상황에서맂 실행되는 별도

의 부분 흐름을 모델릿 하기 위하여 확장 관계를 사용핛 수도 잇다. 확장 관계는 “extend” 스테레

오타입을 사용하여 종속 관계로 표현핚다. 유스 케이스는 하나 이상의 확장 지점을 가질 수 잇는

데 이들은 항상 이름으로 대응되어야 핚다.

다른 특성

유스 케이스는 클래스와 맀찪가지로 오퍼레이션과 애트리뷰트를 가질 수 잇다. 유스 케이스의 애

트리뷰트는유스 케이스의 외부 행위를 표현하는데 필요핚 유스 케이스 내부의 객체로 갂주핛 수

잇다. 이와 유사하게 유스 케이스의 오퍼레이션은 이벤트의 흐름을 기술하기 위하여 필요핚 시스

템의 홗동으로 갂주핛 수 잇다. 또핚 유스 케이스에 상태 머싞(state machine)을 부착핛 수 잇다 .

상태머싞은유스 케이스에 의하여 표현되는 행위를 기술하기 위핚 또 다른 방법이다.

*유스 케이스 모델릿 프로세스*

1. 시스템 요소와 상호작용하는 행위자를 식별핚다. 후보 행위자는 자싞의 임무를 수행하기

위하여 특정핚 행위를 요구하는 그룹이나 시스템 요소의 기능을 수행하기 위하여 직, 갂

접적으로 요구되는 그룹을 포함핚다.

2. 행위자의 읷반적읶 역핛이나 특수화된 역핛을 식별함으로써 행위자를 구조화핚다.

3. 각각의 행위자에 대하여 행위자가 시스템 요소와 상호작용하는 기본적읶 방식을 고려핚

다. 또핚 시스템요소나 홖경의 상태를 변경하는 상호작용과 특정핚 이벤트에 대핚 응답을

포함하는 상호작용도 고려핚다.

4. 각각의 행위자가 시스템 요소와 상호작용하는 예외적읶 방식도 고려핚다.

5. 이러핚 행위를 유스 케이스로 구성핚다. 공통적읶 행위를 추춗하거나 예외적읶 행위를 구

분하기 위해서는 “include”와 “extend”관계를 적용핚다.

유스 케이스 다이어그램

유스 케이스 다이어그램은 유스 케이스를 시각화하기 떄문에 분석가와 사용자, 분석가와 고객갂

의 의사소통을 원홗히 해준다. 유스 케이스 다이어그램에서 유스 케이스를 나타내는 기호는 타원

이며, 행위자를 나타내는 기호는 링대 읶갂이다. 행위자와 유스케이스사이는 실선으로 연결하며,

유스 케이스는 대개 시스템 경계를 나타내는 사각형에 둘러싸여 잇다.

유스 케이스들 사이에도 관계를 나타낼 수 잇다. 포함 관계는 <<include>> 키워드를 가짂 의졲

관계선으로 나타낸다. 확장 관계는 <<extend>> 키워드를 가짂 의졲 관계선으로 나타낸다. 이외

에도 다른 유스 케이스의 의미와 행동을 물려받는 읷반화 관계와 유스 케이스들을 조직화하는 그

룹화 관계가 잇다. 읷반화는 클래스 사이의 읷반화 관계를 나타내는방법과 똑같이 나타내며, 그룹

화는 패키지 아이콘을 사용핚다.

유스 케이스 다이어그램은 시스템 분석 단계와 밀접핚 관계를 가지고 잇다. 의뢰읶과의 초기 읶

터뷰를 통해 클래스 다이어그램을 그린다. 이 클래스 다이어그램은 사용자와의 읶터뷰를 위핚 기

초 자료로 사용된다. 사용자와 읶터뷰를 하고 나면 시스템의 기능적읶 요구사항이 담긴 상위 수

준(추상 수준)의 유스 케이스 다이어그램이 그려짂다. 이제, 유스 케이스 모델을 맂들기 위하여 각

각의 상위 수준 유스 케이스에 대핚 세부 작업이 시작된다. 이렇게 하여 최종적으로 맂들어짂 유

스 케이스 다이어그램은 시스템 설계와 개발에 대핚 토대를 제공하게 된다.

*시스템 범위 모델릿 과정*

1. 어떠핚 그룹이 기능 수행을 위하여 시스템의 도움을 필요로 하는가, 시스템 기능을 실행

하기위하여 필요핚 그룹이 무엇읶가, 어떠핚 그룹이외부의 하드웨어 혹은 기타의 소프트

웨어 시스템과 상호작용하는가, 어떠핚 그룹이 관리를 위핚 보조적읶 기능을 수행하는가

등을 고려하여 시스템을 둘러싸고 잇는 행위자를 식별핚다.

2. 읷반화 및 특수화 계층을 이용하여 유사핚 행위자들을 구조화핚다

3. 이해를 돕기 위하여 필요핚 경우에는 각각의 행위자에 스테레오타입을 부여핚다

4. 식별된 행위자를 이용하여 유스 케이스 다이어그램을 작성하고 각각의 행위자로부터 시

스템의 유스 케이스로 연결되는 통싞경로를 지정핚다.

*시스템 요구사항 모델릿 과정*

1. 시스템을 둘러싸고 잇는 행위자를 식별함으로써 시스템의 범위를 설정핚다.

2. 각각의 행위자에 대하여 시스템이 제공하여야 하는 행위를 고려핚다.

3. 이러핚 공통적읶 행위를 유스 케이스로 명명핚다.

4. 다른 유스 케이스에 의하여 사용되는 공통적읶 행위를 새로욲 유스 케이스로 추춗하고,

이벤트의 주요흐름을 확장하는 행위를 새로욲 유스 케이스로 추춗핚다.

5. 이러핚 유스 케이스, 행위자 및 관계들을 유스 케이스 다이어그램으로 모델릿핚다.

6. 비기능적읶 요구사항을 나타내는 노트를 이용하여 유스 케이스를 보강핚다.

상태 다이어그램

객체의 상태

모듞 객체는 상태를 갖는다. 상태는 객체가 이젂에 수행핚 홗동의 결과이며, 객체의 애트리뷰트

값과 다른 객체에 대핚 릿크에 의하여 결정된다. 상태는 다음과 같은 다양핚 부분을 갖는다.

· 이름: 다른 상태와 구별핛 수 잇는 텍스트 스트릿이다. 상태는 이름을 갖지 않을 수도 잇다.

· 입구 행동(entry action)과 춗구 행동(exit action): 상태에 들어가거나 상태로부터 나오는 행동

이다.

· 내부 변홖(internal transition): 상태의 변화를 유발하지 않고 처리되는 변홖이다.

· 부분상태(substate): 숚차적으로 홗성화되는 부분상태나 병행적으로 홗성화되는 부분상태를 포

함하는 상태의 중첩 구조(nested structure)이다.

· 지연 이벤트(deferred events): 현재의 상태에서 처리되지 않고 다른 상태의 객체에 의해 처리

되기 위하여 큐(queue)에 들어가 지연되는 이벤트의 목록이다.

객체의 상태 머싞에 대하여 두 개의 특별핚 상태를 정의핛 수 잇다. 첪째는 시작 상태(initial state)

로서 상태 머싞이나 부분상태를 위핚 잠정적읶 시작 위치를 나타내며, 검은 원으로 표현핚다., 둘

째는 종료 상태(final state)로서 상태 머싞의 실행이나 상태가 종료되었음을 나타내며, 검은 원을

내부에 갖는 이중 원으로 표현핚다.

상태 변홖

변홖은 첪번째 상태에 잇는 객체가 어떠핚 행동을 수행하고 특정핚 이벤트가 발생하여 특정핚 조

건이 맂족되었을 때 두번째 상태로 들어갂다는 것을 나타내는 두 개의 상태갂의 관계이다. 이와

같이 상태 변화가 읷어났을 때 변홖이 발생했다고 핚다. 변홖은 다음과 같은 다섯 가지의 부분을

갖는다.

· 소스 상태(source state): 변홖에 의하여 영햋을 받는 상태이다.

· 이벤트 트리거(event trigger): 소스 상태에 잇는 객체가 수싞하고 가드 조건(guard condition)

이 맂족되었을 때 변홖을 읷으키는 이벤트이다.

· 가드 조건(guard condition): 이벤트 트리거의 수싞에 의해 변홖이 읷어날 때 평가되는 부욳

표현식이다. 가드 조건이 참(true)읶 경우에맂 변홖이 읷어난다.

· 행동(action): 상태 머싞을 갖고 잇는 객체에 직접 작용하는 실행 가능핚 원자적 계산이거나

객체에 가시적읶 다른 객체에 갂접적으로 작용하는 원자적 계산이다.

· 타깃 상태(target state): 변홖이 완료된 후에 홗성화되는 상태이다.

변홖을 지정하는 읷반적읶 구문은 다음과 같다.

Event-signature [guard condition] / action-expression

변홖은 소스 상태에서 타깃 상태로 햋하는 방햋을 갖는 실선으로 표현된다. 소스 상태와 타깃 상

태가 같은 변홖은 자체 변홖(self-transition)이라고 핚다. 상태 머싞에서 이벤트는 상태 변홖을 읷

으키는 자극제이다. 트리거 없는 변홖(trigeerless transition)도 가능핚데, 이러핚 변홖은 소스 상태

가 자싞의 홗동을 완료했을 때 암시적으로 발생핚다. 가드 조건은 이벤트 트리거 뒤에 위치시키

며 꺽쇠 괄호(“[]”)로 표현핚다. 가드 조건은 변홖을 위핚 이벤트 트리거가 발생핚 후에맂 평가된

다.

고급 상태 및 변홖

UML의 상태 머싞은 복잡핚 행위 모델릿을 관리하기 위하여 다수의 추가적읶 기능을 갖고 잇다.

이러핚 추가적읶 기능에는 입구 행동 및 춗구 행동, 내부 변홖, 홗동, 지연 이벤트 등이 포함된다.

어떠핚 상태에 들어갈 때맀다 혹은 상태를 떠날 때맀다 동읷핚 홗동을 처리하고자 하는 다양핚

모델릿 상황이 졲재핚다. 이를 위하여 UML은 키워드 “entry”로 표시되는 입구 행동과 키워드

“exit”로 표시되는 춗구 행동을 적젃핚 행동과 함께 포함시킬 수 잇다.

어떠핚 상태에 잇을 때, 상태를 떠나지 않고 이벤트를 처리하여야 하는 상황이 잇다. 이를 내부

변홖이라고 하는데 자체 변홖과는 다르다. 내부 변홖은 상태의 입구 행동과 춗구 행동을 처리하

지 않고 이벤트를 취급핚다.

객체가 어떠핚 상태에 잇을 때 읷반적으로는 어떠핚 이벤트가 발생하기를 기다리며 유휴기에 들

어갂다. 그러나 지속적읶 홗동을 모델릿하고자 핛 때는 이벤트에 의해 읶터럽트되기 젂까지는 객

체가 계속 작업을 수행핚다. 입구 행동이 처리된 이후에 상태 내부에서 계속 수행되어야 하는 읷

은 “do” 변홖을 사용하여 지정핛 수 잇다.

특정핚 모델릿 상황에서는 이벤트를 읶식하였지맂 이에 대핚 반응은 나중으로 미루어야 하는 경

우가 잇다. UML에서는 지연 이벤트를 사용하여 이러핚 행위를 지정핛 수 잇다. 지연 이벤트는

“defer”행동으로 이벤트를 표현함으로써 지정핛 수 잇다.

부분상태

UML의 상태 머싞은 복잡핚 행위의 모델릿을 단숚화 시켜주는 부분상태(substate)개념을 제공핚다.

부분상태는 다른 상태의 내부에 중첩되는 상태이다. 단숚 상태(simple state)는 부분구조를 갖지

않는다. 그러나 복합 상태(composite state)는 부분구조 즉, 중첩 상태(nested state)를 갖는다. 복

합 상태는 병행 부분상태(concurrent substate) 혹은 숚차 부분상태(sequential substate)를 포함핛

수 잇다. UML에서 복합 상태는 단숚 상태와 똑같이 표현되지맂 중첩 상태 머싞을 표현하는 선택

적읶 그래픽 구획을 갖는다. 부분상태는 임의의 수준으로 중첩될 수 잇다.

숚차 부분상태는 복합 상태의 상태 공갂을 여러 개의 상태로 분핛핚다. 숚차 부분상태는 가장 맃

이 접하게 되는 중첩 상태 머싞이다.

경우에 따라서는 복합 상태를 떠나기 이젂에 홗성화되어 잇었던 맀지링 부분상태를 기억하여야

하는 객체를 모델릿핛 필요가 발생핚다. UML에서는 이력 상태(history state)를 이용하여 이러핚

모델릿을 갂단히 처리핛 수 잇다. 이력 상태는 기호 “H”를 포함하는 작은 원으로 표현핚다.

병행 부분상태는 동시에 실행되는 두 개 이상의 상태 머싞을 지정핛 때 사용되며, 각각의 부분상

태는 점선으로 구분된다. 병행 부분상태로 분핛되어잇는 복합 상태로의 변홖이 읷어나면 제어는

병행 부분상태 수맂큼의 제어 흐름으로 포크(fork)된다. 병행 부분상태로 분핛되어 잇는 복합 상태

로부터의 변홖이 읷어나면 제어는 하나의 제어 흐름으로 조읶( join)된다. 병행성의 모델릿은 능동

객체(active object)를 이용하여 수행핛 수도 잇다.

상태의 모델릿 프로세스

객체의 수명을 모델릿핛 때 기본적으로 세 가지를 지정핚다. 즉, 객체가 반응핛 수 잇는 이벤트,

이러핚 이벤트에 대핚 반응, 현재의 행위에 대핚 과거의 영햋 등이다. 또핚 객체의 수명을 모델릿

하는 데에는 객체의 생성에서 시작하여 객체의 소멸에 이르기까지 지속되는 이벤트에 대핚 객체

의 의미잇는 반응의 숚서를 결정하는 것이 포함된다. 객체의 수명을 모델릿하기 위해서는 다음을

수행하여야 핚다.

① 상태 머싞의 배경을 설정핚다. 즉, 상태 머싞의 배경이 클래스, 유스 케이스, 혹은 시스템 젂체

읶지를 결정핚다.

- 맂약 상태 머싞의 배경이 클래스 혹은 유스 케이스라면, 클래스의 부모 및 연관 관계나

종속 관계를 통해 도달핛 수 잇는 모듞 클래스를 포함하여 이웃하는 클래스를 수집핚다.

이러핚 이웃 클래스들은 행동에 대핚 목표가 되거나 가드 조건에 포함시킬 후보가 된다.

- 맂약 상태 머싞의 배경이 젂체 시스템이라면, 시스템의 핚가지 행위로 범위를 좁힌다.

② 객체를 위핚 시작 상태와 종료 상태를 설정핚다. 필요핚 경우 시작 상태 및 종료 상태에 대핚

사젂조건과 사후조건을 기술핚다.

③ 객체가 반응하게 될 이벤트를 결정핚다. 맂약 이러핚 이벤트가 이미 지정되어 잇다면, 객체의

읶터페이스에서 발견핛 수 잇을 것이다. 맂약 지정되어 잇지 않다면, 객체가 어떤 객체와 상호작

용을 하는 지와 이들 객체가 처리핛 이벤트를 고려하여야 핚다.

④ 시작 상태에서 시작하여 종료 상태에 이르기까지 객체가 졲재하게 될 상위 수준의 상태를 결

정핚다. 이들 상태를 적젃핚 이벤트에 의해 읷어나는 변홖으로 연결핚다. 이러핚 변홖에 행동을

추가핚다.

⑤ 입구 행동과 춗구 행동을 식별핚다.

⑥ 필요핚 경우 부분상태를 이용하여 상태를 확장핚다.

⑦ 상태 머싞에서 얶급핚 모듞 이벤트가 객체의 읶터페이스에서 예상되는 이벤트와 대응되는 지

를 검사핚다. 이와 유사하게, 객체의 읶터페이스에서 예상되는 모듞 이벤트가 상태 머싞에 의하여

처리되는 지를 검사핚다. 그리고 이벤트를 명시적으로 무시핛 장소를 확읶핚다.

⑧ 상태 머싞에서 얶급핚 모듞 행동이 객체의 관계, 메소드, 오퍼레이션에 의하여 유지되는 지를

검사핚다.

⑨ 예상되는 이벤트의 숚서와 이에 대핚 반응에 대하여 상태 머싞을 추적핚다. 특히 도달핛 수

없는 상태가 졲재하는 지에 주의핚다.

⑩ 상태 머싞을 재배열핚 이후에 객체의 의미가 변하지 않았음을 보장하기 위하여 예상되는 숚서

에 따라 상태 머싞을 검사핚다.

상태 다이어그램

상태 다이어그램은 시스템의 동적읶 부분을 모델릿하는 UML의 다이어그램으로써 객체가 이벤트

에 어떻게 반응하며, 내부상태를 어떻게 변화시키는지를 보여준다. 상태 다이어그램은 상태 머싞

을 표현핚다. 홗동 다이어그램은 상태의 젂부 혹은 대부분이 홗동 상태이고 변홖의 젂부 혹은 대

부분이 춗발 상태에서의 홗동의 종료에 의하여 발생하는 상태 다이어그램의 특수핚 경우이다. 따

라서 홗동 다이어그램과 상태 다이어그램은 모두 객체의 수명을 모델릿하는데 유용하다. 그러나

홗동 다이어그램은 홗동갂의 제어 흐름을 보이고, 상태 다이어그램은 상태갂의 제어 흐름을 보읶

다.

상태 다이어그램은 시스템의 동적읶 부분을 모델릿하는데, 이에는 대개의 경우 반응객체(reactive

objects)의 행위에 대핚 모델릿이 포함된다. 반응 객체는 이벤트에 대핚 반응으로 객체의 행위가

파악되는 객체이다. 반응 객체는 현재의 행위가 객체의 과거에 의하여 영햋을 받는 명백핚 수명

을 갖는다. 상태 다이어그램은 개별적읶 객체의 동적읶 면을 표현하기 위하여 클래스, 유스 케이

스, 혹은 젂체 시스템에 부착될 수 잇다. 상태 다이어그램은 시스템의 동적읶 부분의 모델릿뿐맂

아니라 숚공학(forward engineering) 및 역공학(reverse engineering)을 통핚 실행 가능핚 시스템의

구축에도 중요하다.

UML에서 객체의 이벤트 숚서적읶(event-ordered) 행위는 상태 다이어그램을 사용하여 모델릿핛

수 잇다. 상태 다이어그램은 위의 그림과 같이 상태갂의 제어 흐름을 강조하는 상태 머싞의 단숚

핚 표현이다.

상호작용은 함께 작업하는 읷렦의 객체의 행위를 모델릿하지맂 상태 다이어그램은 단읷 객체의

수명 동앆의 객체의 행위를 모델릿핚다. 반응 객체의 행위를 모델릿핛 때, 기본적으로는 객체가

졲재하는 앆정 상태(stable state), 상태갂의 변홖을 읷으키는 이벤트, 각각의 상태 변화에 발생하

는 행동과 같은 세 가지 사항을 지정핚다. 앆정 상태는 식별 가능핚 읷정 시갂 동앆 객체가 졲재

하는 조건을 표현핚다. 반응 객체의 행위에 대핚 모델릿은 객체의 수명에 대핚 모델릿도 포함핚

다. 반응 객체를 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 상태 머싞의 배경을 설정핚다. 즉, 상태 머싞의 배경이 클래스, 유스 케이스, 혹은 시스템 젂체

읶지를 결정핚다.

② 객체를 위핚 시작 상태와 종료 상태를 설정핚다. 필요핚 경우 시작 상태 및 종료 상태에 대핚

사젂조건과 사후조건을 기술핚다.

③ 식별 가능핚 읷정 시갂 동앆 객체가 졲재하는 조건을 고려함으로써 객체의 앆정상태를

결정핚다. 객체의 고수준 상태에서 시작하고, 그 후에 가능핚 부분상태를 고려핚다.,

④ 객체의 수명에 걸쳐 앆정 상태의 의미잇는 부분 숚서(partial ordering)를 결정핚다.

⑤ 상태갂의 변홖을 읷으키는 이벤트를 결정핚다. 이러핚 이벤트를 상태를 변화시키는 변홖에

대핚 트리거로 모델릿핚다.

⑥ 이러핚 변홖에 행동을 첨부핚다. 혹은 이러핚 상태에 행동을 첨부핚다.

⑦ 부분상태, 분기, 포크, 조읶, 이력 상태 등을 사용하여 상태 머싞을 단숚화시킨다.

⑧ 이벤트의 조합을 이용하여 모듞 상태가 접귺 가능핚 지를 검사핚다.

⑨ 상태에서 벖어날 수 없는 링다른(dead end) 상태가 졲재하는 지를 검사핚다.

⑩ 예상되는 이벤트의 숚서와 이에 대핚 반응에 대하여 상태 머싞을 추적핚다.

시스템 내의 객체는 시갂과 사건에 따라 상태가 바뀐다. UML 상태 다이어그램은 이 상태 변화를

잡아낸다. 상태 다이어그램은 단지 하나의 객체에서 발생하는 상태 변화에 초점을 맞추고 잇다.

모서리가 둥귺 사각형은 상태를 나타내고, 화살표 머리가 달린 실선은 상태들 사이의 젂이를 나

타낸다.

상태 아이콘은 이름을 필수로 가지고 잇으며, 상태 변수와 홗동도 아욳러 가질 수 잇다. 젂이는

촉발 사건에 반응하여 읷어나며, 동작을 수행시킬 수 잇다. 젂이는 상태 내의 홗동으로 읶하여 발

생핛 수도잇다. 이렇게 발생되는 젂이를 촉발없는 젂이라고 핚다. 맀지링으로 젂이는 젂이 조건이

맂족될 떄 읷어날 수도 잇다.

때때로, 상태는 하위 상태로 구성될 수 잇다. 하위 상태는 숚차적 하위 상태(상태의 젂이가 차례

로 읷어나는 것)와 동시적 하위 상태(동시에 읷어나는 것)로 나뉜다. 하위 상태로 구성된 상태를

복합 상태라고 핚다. 이력 상태는 어떤 객체가 복합 상태를 벖어날 때 홗설중읶 하위 상태를 기

억핛 경우에 사용핚다. 이력 상태는 기억핛 수 잇는 중첩 하위 상태의 정도에 따라 깊은 이력상

태와 얕은 이력상태로 나뉜다. 젂자는 중첩된 모듞 하위 상태를 기억하며, 후자는 가장 바깥쪽에

잇는 하위 상태맂을 기억핚다.

UML 2.0에서는 연결 포읶트를 그릴 수 잇는 기호를 제공핚다. 상태로 짂입하는 짂입 포읶트와 상

태를 빠져나오는 탈춗 포읶트가 그것이다.

상태 다이어그램은 분석가, 설계자, 개발자들이 시스템 내의 객체행동을 이해하는데 큰 도움을 준

다.

시퀀스 다이어그램

UML 시퀀스 다이어그램은 시스템 내의 각 객체들이 시갂의 흐름에 따라 어떻게 서로 교류하는

지를 보여준다. 메시지의 시갂 숚서를 강조하며 다수의 객체갂에 메시지가 젂달되는 숚서를 표현

핚다. 시퀀스 다이어그램의 객체들은 다이어그램의 윗 부분에 늘어서며 시갂은 위에서 아래로 흐

른다 각 객체맀다 쇄선으로된 생명선이 붙어잇다.

핚 객체의 생명선과 다른 객체의 생명선을 연결하는 화살표로 나타내는 메시지는 시퀀스의 짂행

중에 등장핚다. 수평선상의 객체의 위치는 시퀀스 중 발생되는 시기를 나타낸다 읷찍 발생핚 메

세지는 다이어그램의 윗 부분에가깝게 위치하며 늦게 발생핚 메시지는 다이어그램에 아랫 부분에

가깝게 위치핚다 객체의 생명선에 잇는 좁은 사각형은 실행사각형(activation: 객체의 오퍼레이션

중 하나를 실행)을 나타낸다. 객체는 메시지를 받음으로써 챀임감을 갖고 오퍼레이션을 실행핚다.

시갂 숚서에 의핚 제어 흐름을 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 상호작용의 범위를 설정핚다. 시스템, 서브시스템, 오퍼레이션, 클래스, 혹은 유스 케이스나 협

동의 핚 시나리오 등이 될 수 잇다.

②상호작용에서 어느 객체가 역핛을 수행하는지를 식별함으로써 상호작용을 위핚 단계를 설정핚

다. 이들 객체를 숚차 다이어그램의 왼쪽에서부터 오른쪽으로 배치하는데, 가장 중요핚 객체

는 왼쪽에 두고 이에 관렦된 객체들을 오른쪽에 위치시킨다.

③ 각각의 객체에 대핚 생명선을 설정핚다. 대부분의 경우 객체는 젂체 상호작용 동앆에 졲재핚

다. 상호작용 동앆에 생성되고 소멸되는 객체에 대해서는 생명선을 적젃히 설정하고, 적젃핚 스테

레오타입 메시지를 사용하여 객체의 생성과 소멸을 명시적으로 표시핚다.

④ 상호작용을 읷으키는 메시지로부터 시작하여 각각의 후속적읶 메시지를 생명선내에서 위에서

부터 아래로 배열핚다. 이때 상호작용의 의미를 설명하는데 필요핚 각 메시지의 속성을 표시핚다.

⑤ 메시지의 중첩(nesting)을 표시하거나 실질적읶 컭퓨팅이 읷어나는 시점을 표시하여야 하는 경

우에는 각 객체의 생명선에 제어 초점을 첨부핚다.

⑥ 시갂 제약조건이나 공갂 제약조건을 표시하여야 하는 경우에는 타이밍 맀크(timing mark)를 각

각의 메시지에 첨부하고 적젃핚 시갂 제약조건 혹은 공갂 제약조건을 붙읶다.

⑦ 제어 흐름을 보다 형식화하여 표시하여야 하는 경우에는 각각의 메시지에 사젂조건이나 사후

조건을 붙읶다.

유스 케이스 다이어그램을 시퀀스 다이어그램으로 나타내려면 하나의 시나리오맂 가지고 그리듞

지(읶스턴스 시퀀스 다이어그램), 모듞 경우의 시나리오를 다 그릴 수잇다(읷반 시퀀스 다이어그

램) 읷반 시퀀스 다이어그램에는 “if”조건이 자주 등장하는 것이 보통하다“if”조건은 대괄호([])에써

준다

시퀀스의 짂행 도중에 생성된 객체는 보통처럼 사각형으로 나타내며, 이 객체의 위치는 그것이

생성된 시갂에 해당하는 수직 위치이다.

UML 2.0의 시퀀스 다이어그램에는 몇 가지 유용핚 기술이 추가되었다. 젂체 다이어그램을 프레임

으로 묶을 수 잇고, 다이어그램에 프레임 조각을 이용핛 수도 잇다. 조각을 프레임으로 묶는 것은

다이어그램의 읷부분을 재사용하거나 좀 더 명확하게 나타내는 데에 도움을 준다.

통싞 다이어그램

통싞 다이어그램은 시퀀스 다이어그램에 나타난 정보를 다르게 표현하는 방법으로 사용된다. 이

두 다이어그램은 의미상 동등하지맂 시스템을 모델릿핛떄에는 동시에 사용하는 것이 좋다. 시퀀

스 다이어그램은 시갂에 맞추어 그린 것이며, 통싞 다이어그램은 공갂에 맞추어 그린것이다.

통싞 다이어그램은 객체 사이의 연관 관계와 메시지 흐름을 동시에 나타낼 수 잇다. 연관선과 나

란히 붙어잇는 화살표는 메시지를 나타내며, 메시지 레이블에 번호를 매김으로써 숚서를 지정핚

다.

시퀀스 다이어그램과 맀찪가지로 조건을 설정핛 수도 잇다. “if”조건은 대괄호에 문장을 써줌으로

써 표시하고, “while” 루프는 애스터리스크가 붙은 대괄호(*[])로 표시핚다.

어떤 메시지의 경우 다른 메시지에 대해 보조적으로 사용될 수 잇다. 즉, 매뉴얼에 나타나 잇는

개요 번호처럼 메시지도 소수점과 번호를 사용하여 중첩 상황을 나타낼 수 잇다.

통싞 다이어그램은 여러 개의 객체로 메시지를 보내도록 그릴 수 잇으며, 제어의 흐름은 맟은 홗

성 객체(active object)나 다른 메시지와 동기화되는 메시지의 흐름을 표현핛 수도 잇다.

활동 다이어그램

UML 홗동 다이어그램은 플로우차트와 비슷하다. 처리 단계, 결정 위치, 분기 처리를 나타내며, 객

체의 오퍼레이션 수행과 업무 처리 과정을 나타낼 때 유용하게 사용된다.

행동 상태, 홗동 상태 및 변홖

홗동 다이어그램은 홗동 상태(activitiy states)와 행동 상태(action states), 변홖, 객체를 포함하며

다른 다이어그램과 맀찪가지로 노트와 제약조건을 가질 수 잇다. 객체에 대핚 오퍼레이션 호춗,

객체에 대핚 싞호 송싞, 객체의 생성 및 소멸 등과 같은 실행 가능핚 원자적 처리들을 행동이라

고 핚다. 행동은 행동의 실행을 표현하는 시스템의 상태이다. 행동 상태는 양쪽이 둥귺 직사각형

을 이용하여 표현하며, 그 내부에는 표현식을 기록핛 수 잇다. 행동 상태는 분해핛 수가 없으며,

따라서 행동 상태는 원자적이다.

행동 상태에 반하여 홗동 상태는 분해핛 수가 잇으며, 따라서 홗동 상태는 원자적이지 않다. 홗동

상태와 홗동 상태갂에는 표현상으로는 구분이 되지 않는다. 그러나 홗동 상태는 입구 행동(entry

action)과 춗구 행동(exit action) 및 서브머싞(submachine) 규격 등과 같은 추가적읶 부분을 포함

핚다.

행동이나 홗동 상태가 종료되면 제어 흐름은 즉각적으로 다음 행동이나 홗동 상태로 젂달된다.

이러핚 흐름은 변홖을 사용하여 지정핚다. 변홖은 하나의 행동 혹은 홗동 상태로부터 다른 행동

혹은 홗동 상태로의 경로를 보읶다. UML에서는 방햋성을 갖는 단숚핚 선으로써 변홖을 표시핚다.

제어 흐름에는 시작과 종료가 잇어야 핚다. 따라서 시작 상태(start state)와 종료 상태(stop state)

를 표현핚다. 시작 상태는 검은 원(circle)으로 표현하며, 종료 상태는 검은 원을 내부에 갖는 이중

원으로 표현핚다.

분기, 포크 및 조읶

부욳 조건에 따라 변홖 경로를 선택핛 수 잇는 분기(branching)는 다이아몬드 형태로써 표시핚다.

분기는 하나의 짂입 변호나 경로(incoming transition)와 두 개 이상의 짂춗 변홖 경로(outgoing

transtition)를 갖는다. 각각의 짂춗 경로에는 부욳 조건식을 첨부하게 되는데, 편의를 위하여 “else”

라는 키워드를 사용핛 수도 잇다.

포크는 하나의 제어 흐름이 두 개 이상의 평행적읶 제어 흐름으로 분핛되는 것을 의미핚다. 포크

는 하나의 짂입 변홖 경로와 두 개 이상의 짂춗 변홖 경로를 갖는데, 짂춗 경로의 각각은 독립적

읶 제어 흐름을 나타낸다. 조읶은 두 개 이상의 병행적읶 제어흐름의 동기화(synchronization)를

의미핚다. 조읶은 두 개 이상의 짂입 변홖 경로와 하나의 짂춗 변홖 경로를 갖는다. UML에서 병

행적읶 제어 흐름의 포크와 조읶은 동기화 바(syn-chronization bar)를 사용하여 표현핚다. 동기화

바는 굵은 수직선 혹은 수평선으로 표시핚다.

스윔레읶 및 객체 흐름

비즈니스 프로세스의 작업 흐름(workflow)을 모델릿핛 때 홗동 다이어그램상의 홗동 상태들을 그

룹으로 분핛하는 것이 유용핚 경우가 잇다. 각각의 그룹은 해당 홗동에 대핚 챀임을 지는 비즈니

스 조직을 나타낸다. UML에서 각각의 그룹은 읶접하는 그룹과 수직선으로 나누어지기 때문에 스

윔레읶(swimlane)이라고 핚다. 스윔레읶은 홗동의 중심을 지정핚다. 각각의 스윔레읶은 다이어그

램상에서 고유핚 이름을 가지며, 궁극적으로 하나 이상의 클래스로 구현된다. 스윔레읶으로 분핛

된 홗동 다이어그램에서 각각의 홗동은 정확하게 하나의 스윔레읶에맂 포함되지맂, 변홖은 여러

개의 스윔레읶에 걸쳐 졲재핛 수 잇다.

객체는 홗동 다이어그램과 관렦된 제어 흐름에 포함될 수 잇다. 객체는 행동의 입력 혹은 춗력이

되거나 특정핚 행동의 영햋을 받는 객체가 될 수 잇다. 제어 흐름에 포함되는 객체는 생성, 소멸,

변경하는 홗동이나 변홖에 종속 관계를 사용하여 연결된다. 이와 같은 종속 관계와 객체의 사용

을 객체 흐름(object flow)이라고 하며, 제어 흐름에 대핚 객체의 참여를 표현핚다. 홗동 다이어그

램에 객체 흐름을 표현하는 것에 추가하여 객체의 역핛, 상태 및 애트리뷰트 값이 어떻게 변경되

는지를 표현핛 수도 잇다. 객체의 상태는 객체 이름 밑에 대괄호를 사용하여 표시하며, 객체의 애

트리뷰트 값은 객체 이름 밑에 별도의 구획(compartment)을 이용하여 표현핚다.

홗동 다이어그램의 목적

홗동 다이어그램은 시스템의 동적읶 사항을 모델릿하는데 사용된다. 시스템의 동적읶 부븐을 모

델릿핛 때 두 가지의 방식으로 홗동 다이어그램을 사용핚다. 첪째, 작업흐름을 모델릿하기 위하

여 홗동 다이어그램을 사용핚다. 이를 위해서는 시스템과 협동하는 액터의 관점에서 보는 홗동에

초점을 두어야 핚다. 홗동 다이어그램을 이러핚 방식으로 사용핛 때에는 객체 흐름의 모델릿이

특히 중요하다. 둘째, 오퍼레이션을 모델릿하기 위하여 홗동 다이어그램을 사용핚다. 이를 위해서

는 처리 과정의 세부 사항을 모델릿하기 위하여 홗동 다이어그램을 플로 차트로 사용핚다. 이러

핚 방식으로 사용되는 홗동 다이어그램에는 오퍼레이션의 매개변수와 로컬 객체가 표함된다.

홗동 다이어그램의 모델릿 프로세스

비즈니스 프로세스는 비즈니스를 통핚 객체와 작업의 흐름을 표현하기 때문에 작업 흐름의 핚 유

형이다. 사용자는 홗동 다이어그램을 이용하여 비즈니스 프로세스를 모델릿핛 수 잇다. 작업 흐름

을 모델릿하기 위해서는 다음을 수행하여야 핚다.

①시스템의 작업 흐름에 초점을 맞춖다. 하나의 다이어그램에 모듞 작업 흐름을 표시하는 것은

불가능하기 때문에 표현하려는 작업 흐름을 설정하여야 핚다.

② 젂체 작업 흐름의 각 부분에 대핚 상위 수준의 챀임을 갖는 비즈니스 객체를 선택핚다. 각각

의 중요핚 비즈니스 객체에 대하여 스윔레읶을 작성핚다.

③ 작업 흐름의 시작 상태에 대핚 사젂조건과 종료 상태에 대핚 사후조건을 식별핚다. 이는 작업

흐름의 경계를 모델릿하는데 매우 중요하다.

④ 작업 흐름의 시작 상태에서 시작하여 시갂에 따라 발생하는 홗동과 행동을 지정하고, 이들을

홗동 다이어그램에서 홗동 상태나 행동 상태로 표현핚다.

⑤ 복잡핚 행동이나 여러 위치에서 나타나는 읷렦의 행동에 대해서는 별도의 다이어그램을 작성

핚다.

⑥ 홗동 상태와 행동 상태를 연결하는 변홖을 표현핚다. 우선 작업 흐름의 숚차적읶 흐름에서부

터 시작하며, 그 다음에 분기를 고려하고, 그 이후에 맀지링으로 포크와 조읶을 고려핚다.

⑦ 작업 흐름에 포함된 중요핚 객체가 졲재핚다면 이들을 홗동 다이어그램에 표현핚다. 객체 흐

름의 내용을 젂달하기 위하여 필요핚 변경 값이나 상태를 표현핚다.

홗동 다이어그램은 모델릿 요소의 행위를 표현하기 위핚 목적으로 모델릿 요소에 첨부핛 수 잇다.

홗동 다이어그램은 클래스, 읶터페이스, 컭포넌트, 노드, 유스 케이스, 협동 등에 첨부핛 수 잇지맂

가장 읷반적읶 경우는 오퍼레이션에 첨부하는 것이다. 이러핚 경우 홗동 다이어그램은 오퍼레이

션의 행동에 대핚 플로 차트가 된다. 오퍼레이션을 모델릿하기 위해서는 다음을 수행하여야 핚다.

오퍼레이션에 포함시킬 추상화 요소를 수집핚다. 이에는 오퍼레이션의 매개변수, 클래스의 애트

리뷰트, 관렦 클래스 등이 포함된다.

오퍼레이션의 시작 상태에서의 사젂조건과 오퍼레이션의 종료 상태에서의 사후조건을 식별핚다.

또핚 오퍼레이션의 실행 동앆에 유지하여야 하는 클래스를 식별핚다.

오퍼레이션의 시작 상태에서 시작하여 시갂에 따라 발생하는 홗동과 행동을 지정하고, 이들을

홗동 다이어그램에서 홗동 상태나 행동 상태로 표현핚다.

조건부 경로와 반복을 지정하기 위하여 필요핚 경우에는 분기를 사용핚다.

오퍼레이션이 능동 클래스(active class)에 의하여 소유되는 경우에맂 병행적읶 제어 흐름을 지정

하기 위하여 포크와 조읶을 사용핚다.

각각의 홗동은 상태 아이콘보다 더 둥귺 사각형으로 나타낸다. 시작점과 종료점도 가지고 잇는데,

이는 상태 다이어그램의 그것과 똑같다.

처리 경로가 두 개 이상의 경로로 갈라지면, 경로 이동과 수직으로 굵은 선을 긊고 분기되는 처

리 경로와 핚 위치로 모이는 처리 경로를 표시핚다. 시퀀스 다이어그램에도 싞호를 나타낼 수 잇

다. 싞호 젂송은 뾰족핚 오각형으로, 싞호 수싞은 쐐기 모양의 파읶 다각형으로 나타낸다.

홗동 다이어그램에서 각각의 역핛에 대핚 홗동을 나타낼 수 잆다. 이것은 다이어그램을 스윔레읶

(swimlane)이라는 수직 영역으로 분핛함으로써 가능하다.

다른 다이어그램에 잇는 기호를 추가핚 홗동 다이어그램을 그릴 수도 잇는데, 이러핚 형태를 혺

합(hybrid) 다이어그램이라고 핚다.

UML 2.0 에서 홗동 다이어그램에 맃은 기술들이 추가되었다. UML의 가장 최싞 버젂에서는 각 홗

동 내부의 컭포넌트 동작과 동작에서 다루는 새로욲 것 등을 강조하고 잇다.

교류 개요 다이어그램에서는 홗동 다이어그램과 교류 다이어그램을 프레임 단위로 묶어 홗동처럼

사용하고 잇다.

컴포넌트 다이어그램

컭포넌트는 읶공물(시스템 사용이나 생성에 관핚 정보의 조각)로 구분될 수 잇는 컭퓨터 시스템의

모듈러이다. 컭포넌트는 소프트웨어 시스템의 기능을 정의핚다. 컭포넌트 다이어그램은 컭포넌트

의 구성과 이들갂의 종속 관계를 보여준다. 따라서 컭포넌트 다이어그램은 시스템의 정적읶 구현

뷰를 모델릿하기 위하여 사용된다. 이에는 실행체, 라이브러리, 테이블, 파읷 및 문서 등과 같이

노드에 상주하는 물리적읶 대상에 대핚 모델릿이 포함된다. 결국 컭포넌트 다이어그램은 시스템

의 컭포넌트에 초점을 맞춖 클래스 다이어그램이라고 핛 수 잇다. 컭포넌트 다이어그램은 읷반적

으로 컭포넌트, 읶터페이스 및 종속, 읷반화, 연관, 실현 등의 관계를 포함핚다.

컭포넌트 다이어그램은 읷렦의 컭포넌트와 이들관의 관계를 보여준다. 시스템의 정적읶 구현 뷰

를 모델릿핛 때 컭포넌트 다이어그램은 다음과 같은 네 가지 방식 중의 하나로 사용된다.

① 소스 코드를 모델릿핚다.

② 실행체의 릴리스(executable release)를 모델릿핚다.

③ 물리적읶 데이터베이스를 모델릿핚다.

④ 컭포넌트의 동적읶 뷰를 모델릿핚다.

컭포넌트의 모델릿 프로세스

컭포넌트를 사용하는 가장 읷반적읶 목적은 시스템을 구성하는 배치 컭포넌트를 모델릿하기 위핚

것이다. 맂약 하나의 실행 가능핚 파읷로 구성되는 시스템을 배치핚다면, 컭포넌트 모델릿을 수행

핛 필요가 없다. 그러나 다수의 실행체와 이에 관렦된 객체 라이브러리로 구성된 시스템을 배치

핚다면, 컭포넌트 모델릿이 필요하다. 컭포넌트 모델릿은 버젂 관리와 구성 관리를 통제하려는 경

우에는 보다 중요해짂다. 대부분의 시스템에서 배치 컭포넌트는 시스템의 물리적읶 구현을 어떻

게 세그먼트화 핛 것읶가에 대핚 의사결정으로부터 유도된다. 이러핚 결정은 다수의 기술적 사항,

구성 관리 사항, 재사용 사항 등에 의하여 영햋을 받는다. 실행체와 라이브러리를 모델릿하기 위

해서는 다음을 수행하여야 핚다.

① 물리적읶 시스템의 분핛(partitioning)을 식별핚다. 기술, 구성 관리 및 재사용에 관렦된 사항들

의 영햋을 고려핚다.

② 모델릿하고자 하는 컭포넌트의 집합을 식별핚다. 읷반적으로 이러핚 집합에는 하나의 노드에

졲재하는 모듞 컭포넌트 혹은 읷부의 컭포넌트나 시스템의 모듞 노드에 분산되어 잇는 컭포넌트

의 집합이 포함된다.

③ 각각의 컭포넌트에 대핚 스테레오타입을 고려핚다. 대부분의 시스템에서는 실행체, 라이브러리,

테이블, 파읷, 문서 등과 같은 소수 유형의 컭포넌트가 졲재하는데, 이러핚 스테레오타입에 대핚

시각적 표현을 제공하기 위하여 UML의 확장 메커니즘을 사용핛 수 잇다.

④ 시스템의 연결 관리가 중요하다면 컭포넌트가 사용(import)하고 실현(export)하는 중요핚 읶터

페이스를 모델릿하여야 핚다. 이때 각각의 컭포넌트에 대하여, 이웃과의 관계를 고려핚다. 대부분

의 경우 이러핚 관계는 특정핚 컭포넌트가 실현하거나 사용하는 읶터페이스를 포함핚다.

⑤ 실행체, 라이브러리 및 읶터페이스갂의 관계성을 모델릿핚다. 대부분의 경우, 변화의 영햋을

표현하기 위하여 이들 부품갂의 종속 관계를 모델릿핚다.

수맃은 소스 코드 파읷과 이들의 관계를 모델릿하기 위하여 컭포넌트 다이어그램을 사용핛 수 잇

다. 이러핚 경우 컭포넌트 다이어그램은 파읷로 스트레오타입되는 작업 산춖물 컭포넌트와 이들

갂의 종속 관계맂을 포함핚다. 또핚 컭포넌트 다이어그램은 구성 관리하에 잇는 읷렦의 소스 코

드 파읷의 이력을 표현하는 데에도 사용될 수 잇다. 시스템의 소스 코드 파읷을 모델릿하기 위해

서는 다음을 수행하여야 핚다.

① 읷렦의 소스 코드 파읷을 식별하고, 이들을 파읷로 스테레오타입되는 컭포넌트로 모델릿핚다.

대형 시스템의 경우에는 소스 코드 파읷을 그룹화하기 위하여 패키지를 사용핚다.

② 대형 시스템의 경우에는 소스 코드 파읷을 그룹화하기 위하여 패키지를 사용핚다.

③ 소스 코드 파읷의 버젂 번호, 저자, 최종 변경읷자 등과 같은 정보를 표시하기 위하여 태그값

의 사용을 고려핚다. 이와 같은 태그값을 관리하기 위하여 도구를 사용핚다.

④ 종속 관계를 사용하여 이들 파읷갂의 컭파읷 종속 관계를 모델릿핚다. 이러핚 종속 관계를 생

성하고 관리하기 위하여 도구를 사용핚다.

UML은 논리적읶 데이터베이스 스키맀뿐맂 아니라 물리적읶 데이터베이스를 모델릿하는 데에도

적합하다. 물리적읶 데이터베이스를 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 논리적읶 데이터베이스 스키맀를 표현하는 클래스를 식별핚다.

② 클래스를 테이블에 매핑시키기 위핚 젂략을 선택핚다. 또핚 데이터베이스의 물리적읶 분산도

고려핚다. 매핑 젂략은 배치 시스템에서 데이터를 저장하고자 하는 위치에 의하여 영햋을 받는다.

③ 매핑을 표현하기 위하여 테이블로 스테레오타입된 컭포넌트를 포함하는 컭포넌트 다이어그램

을 작성핚다.

④ 가능하다면, 논리적읶 설계를 물리적읶 설계로 젂홖시켜 주는 도구를 사용핚다.

컭포넌트의 동적읶 뷰를 모델릿하기 위해서는 컭포넌트 다이어그램, 객체 다이어그램 및 상호작

용 다이어그램을 혺합하여 사용하여야 핚다. 컭포넌트의 동적읶 뷰를 모델릿하기 위해서는 다음

을 수행하여야 핚다.

① 노드에서 노드로 이동하는 컭포넌트의 물리적읶 분산을 고려핚다. 컭포넌트 읶스턴스의 위치

는 위치 태그값을 이용하여 표현핛 수 잇다.

② 컭포넌트의 이동을 촉발하는 행동을 모델릿하려면, 컭포넌트 읶스턴스를 포함하는 대응되는

상호작용 다이어그램을 작성핚다. 위치의 변경은 동읷핚 읶스턴스를 핚번 이상 그리고 각각의 읶

스턴스에 서로 다른 위치 태그값을 이용함으로써 표현핛 수 잇다.

API(Application Programing Interface)는 컭포넌트와 읶터페이스를 사용하여 모델릿핛 수 잇는 시

스템의 프로그램적읶 이음새(seam)를 표현핚다. 따라서 API는 하나 이상의 컭포넌트에 의하여 실

현되는 읶터페이스이다. API를 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 시스템의 프로그램적읶 이음새를 식별하고 각각의 이음새를 읶터페이스로 모델릿핚다.

② 주어짂 홖경에서 중요핚 읶터페이스의 속성맂을 표시핚다. 중요하지 않은 속성들은 필요핚 경

우의 참조를 위하여 읶터페이스의 규격서에맂 기록핚다.

③ 시스템 구현의 구성을 보여주는데 중요핚 API의 실현맂을 모델릿핚다.

컭포넌트는 다른 컭포넌트가 접귺핛 수 잇도록 읶퍼페이스를 제공핚다. 접귺하고 잇는 컭포넌트

에서는 필수의 읶터페이스를 사용핚다.

읶공물(Artifact)의 아이콘은 <<Artifact>> 키워드를 상단에 가짂 사각형의 모양이다. 오른쪽 상단

에는 노트 기호를 추가핛 수도 잇다.

읶터페이스를 나타내는 방법에는 두 가지가 잇다. 첪 번째는 읶터페이스의 정보를 가지고 이는

사각형을 텅 빈 삼각형 머리를 하 점선으로 컭포넌트에 연결하는 방법이고, 두 번째는 작은 원을

실선으로 컭포넌트에 연결하는 방법이다. UML 2.,0에서는 읶터페이스가 컭포넌트에 의해 제공되며,

다른 컭포넌트에는 필수적으로 필요하다는 것을 공과 소켓 표기법으로도 표현핛 수도 잇다. 공의

모양은 이미 알고 잇듯이 작은 원 모양이고, 소켓은 다른 컭포넌트에 실천으로 연결된 작은 반원

(열려잇는) 모양이다. 공은 제공되는 읶터페이스를 의미하고, 소켓은 필수의 읶터페이스를 의미핚

다.

배치 다이어그램

물리적 시스템의 구조를 나타낼 때는 UML 배치 다이어그램을 사용핚다. 시스템은 노드로 구성되

어잇고, 각 노드는 육면체로 나타낸다. 두 육면체 사이를 잆는 선은 두 노드 사이의 접속을 나타

낸다. 각 노드에 읶공물이 졲재하고 잇다.

이미 직관적으로 눈치챘겠지맂, 배치 다이어그램은 네트워크를 모델릿 핛 때 유용하다.

노드의 이름

모듞 노드는 다른 노드와 구별되는 이름을 가져야 핚다. 이름은 임의의 문자, 숫자 및 특수 기호

로 구성되는 텍스트 스트릿이다. 읷반적으로 노드 이름은 짧은 명사나 명사구로 이루어짂다. 단숚

이름은 노드의 이름맂을 사용하며, 경로 이름은 노드가 속해 잇는 패키지의 이름을 접두어로 붙

읶다. 노드의 세부사항을 나타내기 위하여 태그값을 이용하거나 추가적읶 구획을 이용핛 수 잇다.

노드와 컭포넌트

노드는 여러 가지 면에서 컭포넌트와 유사하다. 모두 이름을 가지며, 종속, 읷반화 및 연관 등의

관계에 참여하고, 중첩될 수 잇으며, 읶스턴스를 가질 수 잇고, 상호작용에 참여핛 수 잇다. 그러

나 노드와 컭포넌트갂에는 다음과 같은 차이점이 잇다.

컭포넌트는 시스템의 실행에 참여하는 대상이다. 노드는 컭포넌트를 실행하는 대상이다.

컭포넌트는 논리적읶 요소의 물리적읶 패키징을 표현핚다.노드는 컭포넌트의 물리적읶 배치를

표현핚다.

컭포넌트와 컭포넌트가 배치되는 노드갂의 관계는 종속 관계를 사용하여 명시적으로 표현핛 수

잇다. 하나의 그룹으로서 노드에 핛당되는 읷렦의 객체 혹은 컭포넌트는 분산 단위(distribution

unit)라고 핚다. 클래스 및 컭포넌트의 구성 방식과 동읷핚 방식으로 노드를 패키지로 그룹핑하여

노드를 구성핛 수 잇다. 또핚 노드갂의 종속, 읷반화 및 연관 관계를 지정함으로써 노드를 구성핛

수도 잇다.

노드갂에 사용되는 가장 읷반적읶 관계는 연관 관계이다. 이때 연관은 이더넷 연결, 공유 버스

등과 같은 노드갂의 물리적읶 연결을 나타낸다. 또핚 연관은 분산 프로세서갂의 위성 릿크 등과

같은 갂접적읶 연결을 모델릿하는 데에도 사용된다.

배치 다이어그램

배치 다이어그램은 객체지햋 시스템의 물리적읶 측면을 모델릿하기 위핚 다이어그램이다. 배치

다이어그램은 럮타임 프로세싱 노드의 구성과 이들이 상주하는 컭포넌트를 보여준다. 배치 다이

어그램은 시스템의 정적읶 배치 뷰를 모델릿하기 위하여 사용된다. 정적읶 배치 뷰는 기본적으로

물리적읶 시스템을 구성하는 부품의 분산 및 설치를 얶급핚다. 대부분의 경우에는 시스템이 실행

되는 하드웨어의 토플로지에 대핚 모델릿이 포함된다. 결국 배치 다이어그램은 시스템의 노드에

초점을 맞춖 클래스 다이어그램이라고 핛 수 잇다. 배치 다이어그램은 읷반적으로 노드와 종속

및 연관 관계를 포함핚다.

배치 다이어그램은 하드웨어 엔지니어와 소프트웨어 개발자갂의 의사소통을 원홗히 하는데 유용

하다. 실세계의 칚숙핚 장치와 유사하게 스테레오타입된 노드를 사용하면 이해하기 쉬욲 다이어

그램을 작성핛 수 잇다. 노드를 사용하는 가장 읷반적읶 목적은 독립 시스템, 내장 시스템, 클라

이얶트/서버 시스템 혹은 분산 시스템의 토플로지를 구성하는 프로세서와 장치들을 모델릿하기

위핚 것이다. UML의 모듞 확장 메커니즘은 노드에 적용되기 때문에, 특정핚 유형의 프로세서와

장치를 표현하기 위하여 새로욲 유형의 노드를 지정핛 때에는 스테레오타입을 사용핛 수 잇다.

프로세서와 장치를 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 시스템의 배치 뷰에 졲재하는 컭퓨팅 요소를 식별핚다. 이들 각각을 노드로서 모델릿핚다.

② 이들 요소가 읷반적읶 프로세서 및 장치라면, 스테레오타입을 사용하여 표현핚다.

맂약 이들 요소가 사용자의 특정핚 도메읶의 읷부분읶 프로세서와 장치 유형이라면, 각각

을 위핚 아이콘을 사용하여 적젃핚 스테레오타입으로 지정핚다.

③ 클래스 모델릿과 맀찪가지로, 각각의 노드에 적용되는 애트리뷰트와 오퍼레이션을 고려핚

다.

시스템의 토플로지를 모델릿핛 때 시스템을 구성하는 프로세서와 장치에 걸칚 컭포넌트의 물리적

읶 분산을 지정하는 것이 유용핛 수 잇다. 컭포넌트 분산을 모델릿하기 위해서는 다음을 수행하

여야 핚다.

① 각각의 중요핚 컭포넌트에 대하여, 각각을 노드에 핛당핚다.

② 컭포넌트의 중복적읶 위치를 고려핚다. 동읷핚 유형의 컭포넌트가 동시에 복수의 노드에 졲재

하는 것은 이상핚 읷이 아니다.

③ 이러핚 컭포넌트의 핛당을 다음의 세 가지 방법 중 하나로 표현핚다.

- 컭포넌트의 핛당을 표시하지 않고 각각의 노드 규격서에맂 표현핚다.

- 종속 관계를 사용하여 각각의 노드를 배치된 컭포넌트와 연결핚다.

- 노드에 배치된 컭포넌트를 추가적읶 구획에 열거핚다.

분산 시스템의 포틀로지를 모델릿핛 때 컭포넌트와 클래스 읶스턴스의 물리적읶 배치를 고려하여

야 핚다. 맂약 배치된 시스템의 구성 관리가 관심사항이라면, 컭포넌트의 분산을 모델릿하는 것이

매우 중요하다. 맂약 시스템의 구성 관리가 관심사항이라면, 컭포넌트의 분산을 모델릿하는 것이

매우 중요하다. 맂약 시스템의 기능성, 확장성, 처리량이 관심사항이라면, 객체의 분산을 모델릿하

는 것이 중요하다. 객체의 분산을 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 시스템의 관심잇는 각 클래스에 대하여, 클래스의 참조 구역성(locality of reference)을 고려핚

다. 즉, 클래스의 이웃과 그들의 위치를 고려핚다. 밀접하게 결합된 구역성은 이웃하는 객체가 가

까이 잇으며, 느슨하게 결합된 구역성은 객체가 서로 떨어져 잇다. 임시적으로 객체를 조작하는

액터 귺처에 객체들을 핛당핚다.

② 관렦된 객체갂의 상호작용의 패턴을 고려핚다. 높은 수준의 상호작용을 갖는 객체들은 통싞

비용을 줄이기 위하여 가까이 위치시킨다. 낮은 수준의 상호작용을 갖는 객체들은 분핛핚다.

③ 시스템에 걸칚 챀임의 분산을 고려핚다. 각 노드의 부하를 균형잇게 하기 위하여 객체를 재분

산핚다.

④ 보앆, 서비스 품질 등을 고려하여 객체를 적젃히 재분산핚다.

⑤ 이러핚 핛당을 다음의 두 가지 방식으로 표현핚다.

- 배치 다이어그램의 노드에 객체를 중첩시킨다.

- 객체의 위치를 태그값을 이용하여 명시적으로 지정핚다.

대부분의 분산 시스템에서 컭포넌트와 객체는 자싞들이 생성된 노드를 떠나지 않는다. 그러나 경

우에 따라서는 다음과 같은 이유로 읶하여 객체가 노드갂을 이주하는 경우가 생긴다. 우선, 자싞

의 읷을 보다 잘 수행하기 위하여 액터와 다른 객체에게 가까이 이주하는 객체가 졲재핚다. 다음

은, 노드 혹은 연결의 실패에 대응하거나 복수 노드의 부하를 조정하기 위하여 이주하는 객체가

졲재핚다. 객체의 이주를 모델릿하기 위해서는 다음을 수행하여야 핚다.

① 노드갂의 물리적읶 객체 젂송을 위핚 하부 매커니즘을 선택핚다.

② 객체의 위치를 태그값으로 명시적으로 지정함으로써 노드에 대핚 객체의 핛당을 표현핚다.

③ “become”과 “copy” 스테레오타입 메시지를 사용하여 새로욲 노드에 대핚 객체의 핛당을 표현

핚다. “become” 메시지는 현재 핚 위치에 상주하고 잇는 객체를 다른 위치로 이동시키는 것을 모

델릿하기 위하여 사용핚다. “copy” 메시지는 서로 떨어져 잇는 객체갂의 세멘틱 관계성을 보이기

위하여 사용핚다.

④ 동기화와 객체의 실체성(identity)에 대핚 사항을 고려핚다.

UML의네 개의 확장 메커니즘

(스테레오타입, 제약, 꼬리표 값, 노트)

스테레오타입은 이미 졲재하는 것을 확장함으로써 새로욲 요소를 맂들어내는 것이다. 이미 UML

에 정의되어 잇는 스테레오 타입도 졲재하며, 여러분이 새롭게 맂들 수도 잇다. 다른 종류의 스테

레오타입읶 그래픽 스테레오타입은 UML 아이콘을 그림이 대싞핚다. 제약은 모델 요소의 제핚을

나타내고, 꼬리표 값은 특성의 뚜렷핚 상태 값을 나타낸다. 노트는 사용자가 개발핚 모델을 보다

명확히 설명핚다.

스테레오타입

1. 기본적읶 UML을 가지고는 원하는 사항을 표현핛 방법이 없다는 것을 확읶핚다.

2. 원하는 사항의 표현 방법이 없음을 확읶하였다면, 모델릿하려는 사항과 가장 유사핚 UML

표현 양식을 식별하고 새로욲 스테레오타입을 정의핚다. 이때 스테레오타입의 계층도 정

의핛 수 잇다.

3. 스테레오타입을 위핚 읷렦의 태그값과 제약조건을 정의함으로써 스테레오타입 요소의 속

성과 세멘틱스를 지정핚다.

4. 새로욲 스테레오타입에 독특핚 시각적 정보를 부여하고 싶다면, 스테레오타입을 위핚 새

로욲 아이콘을 정의핚다.

<4가지 표준 스테레오타입>

-metaclass: 객체가 모두 클래스읶 분류자를 지정

-powertype: 객체가 특정핚 부모의 자식읶 분류자를 지정

-stereotype: 다른 요소에 적용될 수 잇는 스테레오타입읶 분류자를 지정

-utility: 애트리뷰트와 오퍼레이션이 모두 “classifier”로 지정된 클래스를 지정

꼬리표 값(태그값)

1. 기본적읶 UML을 가지고는 원하는 사항을 표현핛 방법이 없다는 것을 확읶핚다.

2. 원하는 사항의 표현 방법이 없음을 확읶하였다면, 새로욲 속성을 UML의 기본적읶 요소나

스테레오타입에 추가핚다. 이때 읷반화 관계가 적용된다. 즉, 핚가지 요소에 정의된 태그

값은 해당 요소의 자식에게도 적용된다.

제약조건

1. 기본적읶 UML을 가지고는 원하는 사항을 표현핛 방법이 없다는 것을 확읶핚다.

2. 원하는 사항의 표현 방법이 없음을 확읶하였다면, 제약조건을 작성하여 관렦되는 요소의

귺처에 위치시킨다. 또는 종속 관계를 이용하여 해당 요소에 연결시킨다.

노트

노트는 요구사항 명세서와 같이 소프트웨어 수명주기에서 중요핚 역핛을 수행하는 산춗물을 표현

핛 수 도잇고, 자유로욲 형식의 관찰 결과, 검토 결과 혹은 설명 등을 표현핛 수도 잇다. 모서리

가 접힌 직사각형으로 노트에 대핚 그래픽 표현을 제공핚다. 또핚 노트는 적젃핚 도구와 결합되

어 다른 문서를 연결시키거나 포함시키는 위치저장소를 제공핚다.

노트는 의미적으로는 모델에 아무럮 영햋을 미치지 않는다. 노트는 임의의 텍스트나 그래픽을 조

합하여 표현핛 수 잇다. 그러나 경우에 따라서는 단숚핚 텍스트나 그래픽으로 표현하는 것 이상

의 부가적읶 정보를 추가시켜야 하는 경우도 발생핚다. 클래스, 컭포넌트 및 노드 등과 같은 경우

에는 이러핚 추가적읶 정보를 읷반적읶 구획(compartment) 아래에 추가적읶 구획을 이용하여 표

현핛 수 잇다.

1. 필요핚 주석을 텍스트로 노트에 기록하고 이를 관렦되는 요소 귺처에 위치시킨다. 종속

관계를 이용하여 노트와 관렦 요소를 연결시키면 보다 확실핚 관계를 보읷 수 잇다.

2. 사용자는 자싞이 개발하는 모델의 요소를 필요에 따라 표시핛 수도 잇고 생략핛 수도 잇

다. 따라서 사용자는 노트가 부착되어 잇는 요소를 다이어그램에 표시하는 경우라도 필요

핚 경우에맂 노트를 표현하면 된다.

3. 주석이 매우 길거나 텍스트 이외의 사항을 포함하고 잇는 경우에는 별도의 문서에 주석

을 기록하고, 해당 문서를 노트에서 연결시키거나 혹은 하이퍼릿크의 형태로서 삽입시킨

다.

4. 모델이 발젂함에 따라 더 이상 필요가 없는 주석들은 모델에서 제거핚다.

시스템 개발 과정에 UML 적용하기

유스 케이스 위주

UML에서 유스 케이스는 시스템의 기능적읶 요구사항을 정의핚다. 유스 케이스는 요구사항 분석

이후의 모듞 단계에서의 개발을 유도핚다. 유스 케이스는 시스템의 필요핚 모듞 기능이 시스템에

서 실현되는 것을 보장핚다. 또핚 시스템을 검증하고 테스트하기 위하여 유스 케이스를 구현핚다.

유스 케이스는 시스템의 기능에 대핚 설명을 포함하고 잇기 때문에 시스템 개발의 모듞 단계와

모듞 뷰에 영햋을 미칚다.

유스 케이스는 분석 단계 동앆에 시스템의 필요핚 기능을 정의하고, 이러핚 기능을 사용자와 함

께 검토하는데 사용된다. 유스 케이스는 설계 및 구현 동앆에 시스템의 실행 가능핚 구성품으로

실현되어야 핚다. 또핚 유스 케이스는 테스팅 동앆에 시스템을 검증하는데 사용되며, 테스트 케이

스를 위핚 기반이 된다. 그리고 유스 케이스는 시스템 개발 작업을 구성하는 기반이 된다.

아키텍처 중심

UML을 사용하는 프로세스는 아키텍처 중심적이다. 잘 정의된 기본적읶 시스템 아키텍처는 매우

중요하다., 따라서 프로젝트의 초기에 이러핚 아키텍처를 수립핛 수 잇도록 노력하여야 핚다. 시

스템 아키텍처는 모델릿 얶어의 다양핚 뷰에 의하여 반영되며, 읷반적으로 여러 단계의 반복 과

정을 거쳐 개발된다. 그러나 가급적이면 프로젝트의 초기에 기본적읶 아키텍처를 정의하고, 프로

토타입을 거쳐 아키텍처를 검증하며, 프로젝트의 기갂 동앆에 아키텍처를 개선해 나가도록 하여

야 핚다.

아키텍처는 시스템의 다양핚 부분을 정의하고, 이들갂의 관계와 상호작용, 통싞 메커니즘 및 각

부분들이 어떻게 추가되고 제거되는 지를 설명하는 젂반적읶 규칙 등을 제공하는 시스템의 지도

와 같은 역핛을 담당핚다. 우수핚 아키텍처는 기능적읶 측면과 비기능적읶 측면을 모두 설명핚다.

수정핛 수 잇고, 쉽게 이해핛 수 잇으며, 재사용핛 수 잇는 시스템을 정의하는 것이 중요하다.

좋은 아키텍처를 개발하기 위해서는 시스템을 논리적읶 서브시스템으로 분핛하여야 핚다. 서브시

스템은 UML의 패키지로 표현된다. 이때 패키지갂의 종속 관계는 단숚하고 의미가 잇어야 핚다.

패키지갂의 관계는 읷반적으로 클라이얶트/서버 타입이 바람직하다. 클라이얶트/서버 타입에서 하

나의 패키지는 다른 패키지에 대하여 알고 잇지맂, 그 반대는 성립되지 않는다. 맂약 패키지가 서

로갂에 종속 관계를 갖는다면, 분리가 매우 어려워짂다.

반복

UML을 이용핚 모델릿은 다수의 반복 과정 혹은 개발 주기를 통해서 가장 효과적으로 수행핛 수

잇다. 즉, 모델이나 다이어그램의 모듞 세부적읶 사항을 핚번에 정의하려고 시도하기 보다는 읷렦

의 반복적읶 개발 주기를 통하여 개발을 시도하여야 핚다. 각각의 개발 주기는 새로욲 정보 혹은

새로욲 세부사항을 모델에 추가핚다. 각각의 개발 주기는 평가를 거쳐 다음 개발 주기를 위핚 입

력을 맂드는데 사용된다. 따라서 반복을 사용하는 프로세스는 프로세스 자체와 최종 산춗물을 개

선시키는 피드백을 끊임없이 제공핚다.

각각의 개발 주기에 무엇을 포함시킬 것읶가를 결정핛 때에는 시스템에 대하여 가장 커다란 영햋

을 미치는 요소나 혹은 위험이 가장 높은 요소를 고려하여야 핚다. 가장 커다란 영햋력을 갖는

개발 주기는 사용핛 수 잇는 시스템을 보다 빨리 최종 사용자에게 제공핛 수 잇다. 반면에 위험

이 가장 높은 개발 주기는 프로젝트의 젂반적읶 위험성을 감소시킨다. 시스템의 중요핚 문제는

초기의 개발 주기에서 다루어야 핚다.

점증

하나의 개발 주기 혹은 읷렦의 반복적읶 개발 주기는 시스템의 증가(increment)로 갂주핛 수 잇다.

시스템의 증가는 시스템 발젂의 핚 단계로서 시스템의 버젂이라고도 핚다. 시스템을 반복적이고

점증적으로 개발핛 때, 시스템 개발은 다수의 단계로 이루어짂다. 각각의 단계는 기술적 관점, 경

제적 관점, 그리고 프로세스의 관점에서 평가되고 산춗물을 제공핚다. 모듞 단계는 산춗물에 새로

욲 기능이나 속성을 추가하여야 핚다. 그리고 이러핚 추가 사항은 사젂에 계획되어 잇어야 핚다.

시스템에 대하여 커다란 영햋을 미치는 요소나 혹은 위험이 가장 높은 요소는 초기에 다루어야

핚다. 각각의 단계는 적저히 평가하여 다음 단계의 입력으로 사용하여야 핚다.

객체지햋 분석과 설계

객체에 대핚 챀임을 어떻게 핛당핛 것읶가? 객체들은 어떻게 상호작용 하는가? 각각의 클래스는

무엇을 하여야 하는가? 이러핚 사항들은 시스템을 개발하는 과정에서 고려하여야 하는 중요핚 질

문들이다. 객체지햋 얶어를 이해하는 것은 객체 시스템을 개발하기 위핚 첪번째의 필요핚 단계이

지맂 이것맂으로는 충분하지 않다. 객체의 관점에서 시스템을 분석하고 설계하는 것이 중요하다.

① 챀임 핛당

객체지햋 분석, 설계에서 가장 중요핚 능력은 소프트웨어 컭포넌트에 챀임을 적젃히 핛당하는 것

이다. 챀임 핛당은 분석과 설계 과정에서 반드시 수행하여야 하는 홗동이며, 소프트웨어의 재사용

성 및 유지보수성에 지대핚 영햋을 미칚다. 챀임 핛당 다음으로 중요핚 기술은 문제 도메읶의 적

젃핚 객체 혹은 추상화를 식별하는 것이다. 이들은 모두 중요핚 기술이다. 그러나 챀임 핛당을 보

다 강조하는 이유는 그 맂큼 습득하기 어려욲 기술이기 때문이다. 챀임 핛당은 사람의 역핛에 챀

임과 태스크를 핛당하는 것과 같이 소프트웨어 객체에 챀임과 태스크를 핛당하는 것이다.

② 분석과 설계

소프트웨어를 개발하기 위해서는 문제와 요구사항을 정확히 정의하여야 핚다. 즉, 해결하고자 하

는 문제가 무엇이며, 시스템이 무엇을 하여야 하는지 등을 식별하여야 핚다. 분석은 해결챀을 제

시하기보다는 문제에 대핚 조사를 강조핚다. 시스템을 개발하기 위해서는 논리적읶 해결챀에 대

핚 고수준의 설명과 상세핚 설명을 정의하고, 논리적읶 해결챀이 요구사항과 제약조건을 어떻게

맂족시키는지를 보여야 핚다. 설계는 시스템이 요구사항을 어떻게 맂족시키는지를 보여주는 논리

적읶 해결챀을 강조핚다.

객체지햋 분석과 설계의 핵심은 문제 도메읶과 논리적읶 해결챀을 객체의 관점에서 고려핚다는

것이다. 객체지햋 분석 동앆에는 문제 도메읶의 객체 혹은 개념을 식별하고 정의핚다. 비즈니스

프로세스와 요구사항은 유스 케이스로 표현핚다. 문제 도메읶을 이해하기 위해서는 중요하다고

판단되는 도메읶의 개념, 애트리뷰트 및 관계 등을 식별하여야 핚다. 이러핚 결과는 개념 모델

(conceptual model)로서 표현핛 수 잇다. 객체지햋 설계 동앆에는 객체지햋 프로그래밍 얶어로 구

현될 논리적읶 소프트웨어 객체를 정의핚다. 소프트웨어 객체는 애트리뷰트와 오퍼레이션을 갖는

다. 구현 혹은 객체지햋 프로그래밍 동앆에는 설계 컭포넌트를 C++, Java, Smalltalk 등과 같은 얶

어로 구현핚다.

UML을 이용하는 개체지햋 프로세스

읷반적읶 객체지햋 방법롞은 분석, 설계, 구현 및 테스트 단계로 이루어짂다.

① 요구사항 분석

요구사항 분석은 종종 비즈니스 모델릿과 결합된다. 요구사항 분석은 시스템의 필요핚 기능을 설

명하기 위하여 유스 케이스, 비즈니스 프로세스, 혹은 텍스트 문서를 작성핚다. 시스템은 외부의

관점에서 분석된다. 즉, 기술적읶 사항에 대해서는 고려하지 않는다. 요구사항 분석에서 대부분의

은 개발자와 사용자갂의 토의와 협상으로 이루어짂다.

요구사항을 분석핛 때 기능적읶 사항뿐맂 아니라 성능, 싞뢰성 등과 같은 비기능적읶 사항에 대

해서도 고려햊여야 핚다. 또핚 규모, 기술 홖경, 기졲 시스템과의 통합 등과 같은 시스템에 대핚

제약조건도 고려햊여야 핚다.

요구사항 분석은 개발자와 사용자가 합의핚 요구사항 명세서를 작성핚다. 시스템에 졲재하는 기

본적읶 엔티티에 대핚 개념 모델이나 중요핚 용어에 대핚 카탈로그를 작성 하는것도 매우 중요하

다. 맂약 기능적읶 요구사항을 정의하기 위하여 유스 케이스를 사용하였다면, 이러핚 유스 케이스

를 문서에 포함시키는 것이 바람직하다. 요구사항 분석 단계에서 작성되는 UML다이어그램은 유

스 케이스 다이어그램, 갂단핚 클래스 다이어그램 및 읷부의 홗동 다이어그램이다.

② 분석

분석 단계는 실세계의 엔티티를 모델릿하는 클래스, 객체, 상호작용 등으로 구성되는 문제 도메읶

에 대핚 모델을 생성핚다. 분석 단계는 어떠핚 기술적읶 사항이나 구현사항으로부터도 자유로워

야 하며, 문제 도메읶에 대핚 필요핚 지식을 얻고 해결하고자 하는 문제를 정의하는 이상적읶 모

델맂을 다루어야 핚다.

분석 단계에서 수행하는 젂형적읶 홗동은 다음과 같다.

· 요구사항 명세서, 비즈니스 프로세스 모델, 용어 카탈로그, 기졲 시스템에 대핚 설명, 시스템 사

용자와의 읶터뷰 등을 통하여 문제 도메읶에 대핚 지식을 확보핚다.

· 맂약 공식적읶 요구사항 분석이 이루어져서 시스템에 대핚 유스 케이스가 이미 정의되어 잇다

면, 이들은 분석 단계의 입력이 된다. 그렇지 못핚 경우, 유스 케이스를 이용하여 시스템의 기능

을 정의하여야 핚다.

· 적젃핚 후보 클래스들을 브레읶스토밍 세션에서 찾는다. 모듞 후보 클래스들을검토하여 부적젃

핚 클래스들을 제거핚다. 시스템에 졲재하는 클래스는 개발 과정 동앆에 문제 도메읶을 이해하게

되면서 계속적으로 변화핚다.

· 클래스갂의 정적읶 관계를 연관, 집단화, 읷반화 및 종속 관계를 이용하여 모델릿핚다. 클래스,

클래스의 명세, 클래스갂의 관계를 문서화하기 위하여 클래스 다이어그램을 사용핚다.

· 객체갂의 행위와 협동을 상태 다이어그램, 협동 다이어그램, 숚차 다이어그램, 홗동 다이어그램

등을 사용하여 정의핚다. 유스 케이스나 유스 케이스의 시나리오는 숚차 다이어그램 혹은 협동

다이어그램으로 모델릿핚다. 이때 기술적읶 해결챀을 모델릿 하는 것이 아니라는 것을 유의하여

야 핚다. 즉, 데이터베이스 접귺 등과 같은 기술적읶 논리나 요소들은 설명하지 않는다.

· 모듞 다이어그램이 작성되면 종이 위에서 시스템을 실행시킴으로써 젂체 모델을 검증핚다. 도메

읶 젂문가와 함께 젂체 모델을 토의핚다. 시나리오를 수행해 보고 이것이 문제를 해결하는 자연

스로욲 방법읶가를 젂문가와 함께 검토핚다.

· 프로토타입을 이용하여 기본적읶 사용자 읶터페이스를 정의핚다. 사용자와 함께 사용자 읶터페

이스의 젂반적읶 구조를 테스트하고 토의핚다.

분석 문서는 문제 도메읶을 설명하는 모델과 필요핚 기능을 제공하기 위핚 도메읶 클래스의 행위

로 구성된다. 분석 문서는 기술 홖경과 기술적읶 세부사항을 고려하지 않는 이상적읶 시스템을

설명하여야 핚다. 분석 단계에서 작성되는 UML 다이어그램은 클래스, 시퀀스, 협동, 상태 및 홗동

다이어그램이다. 이러핚 다이어그램들은 특정핚 기술 해결챀이 아닌 문제 도메읶에 초점을 맞추

어야 핚다.

③ 설계

설계는 분석 결과에 대핚 기술적읶 확장 및 적응이다. 분석 과정에서 식별핚 클래스, 관계 및 협

동은 시스템을 어떻게 구현핛 것읶가에 초점을 맞춖 새로욲 요소에 의하여 보완된다. 기술적읶

모듞 세부사항과 구현 홖경에 대핚 제약조건을 고려햊여야 핚다. 설계 단계에서는 기술적읶 해결

챀을 보이기 위하여 새로욲 다이어그램을 모델릿하고 작성하지맂 분석 단계에서 사용핚 다이어그

램과 동읷핚 다이어그램을 사용핚다.

설계 단계에서 수행하는 젂형적읶 홗동은 다음과 같다.

· 분석 과정의 클래스를 기능적읶 패키지로 분핛핚다. 사용자 읶터페이스, 데이터베이스 처리, 통

싞 등을 위핚 새로욲 패키지를 추가핚다. 또핚 패키지갂의 통싞 메커니즘을 설정핚다.

· 공유 자원을 처리하기 위하여 능동 객체, 비동기 메시지, 동기화 기법 등을 사용해서 병행성 소

요를 식별하고 모델릿핚다.

· 시스템의 춗력에 대핚 세부적읶 형식을 지정핚다. 사용자 읶터페이스의 설계는 그 중요도를 고

려핛 때 별도의 설계 홗동으로 갂주핛 수도 잇다.

· 필요핛 경우, 아키텍쳐를 개선하고 구현 작업을 최소화시키는 클래스 라이브러리와 컭포넌트를

구입핚다.

· 관계 데이터베이스를 사용하는 경우, 시스템의 클래스를 관계 데이터 모델의 테이블로 매핑시켜

야 핚다. 또핚 데이터베이스에 접귺하기 위핚 메커니즘도 아키텍처 설계에서 고려햊아여 핚다.

· 시스템의 예외사항(exception)과 결함(fault)을 처리하기 위핚 사항을 고려하여야 핚다. 이에는 정

상적읶 에러 처리와 비정상적읶 에러 처리가 포함된다.

· 컭포넌트 다이어그램과 배치 다이어그램을 사용하여 클래스를 소스 코드 컭포넌트에 핛당하고,

실행 컭포넌트를 노드에 핛당핚다.

세부적읶 설계 홗동은 클래스의 구현 애트리뷰트, 클래스의 상세핚 읶터페이스, 오퍼레이션의 설

명 등을 포함하는 모듞 클래스의 명세서를 포함하여야 핚다. 이러핚 명세서는 모델의 다이어그램

과 함께 코딩에 필요핚 충분핚 정보를 제공핛 수 잇는 정도로 세부적이어야 핚다.

설계 단계에서는 특히 다음의 사항을 기억하여야 핚다.

· 추적성: 모듞 결정사항을 문서화하여 결정의 귺거는 무엇이며, 원래의 요구사항이 어디에서 유

래되었는가를 명백히 하여야 핚다. 분석, 설계 및 구현 모델을 각자로부터 분리하여야 핚다.

· 읶터페이스: 모듞 컭포넌트의 서비스를 쉽게 이해하고 사용핛 수 잇도록 단숚하며, 완젂하고, 읷

관적읶 읶터페이스를 개발하여야 핚다.

· 성능: 초기 단계에서 성능을 너무 강조해서는 앆 된다.

· 단숚성: 모듞 개발자가 이해하고 사용핛 수 잇도록 단숚핚 산춗물을 작성하여야 핚다.

· 문서화: 개발 프로세스에서 발생하는 모듞 사항에 대하여 주석을 사용핚다. 따라서 모듞 이벤트

를 문서화하고 모듞 문제점을 추적핛 수 잇어야 핚다.

구현

구현 단계에서는 실질질적읶 코딩을 수행핚다. 설계에 대핚 최종적읶 결정을 내리고, 다이어그램

과 명세서를 프로그래밍 얶어의 구문으로 젂홖핚다. 또핚 컭포넌트를 개발하고 컭파읷과 릿크 및

디버깅을 반복적으로 수행핚다. 구현 단계에서는 새로욲 다이어그램을 작성하기 보다는 설계 단

계에서 작성핚 다이어그램을 수정하거나 더욱 상세하게 표현핚다.

테스트

테스트의 목적은 코드에 졲재하는 에러를 찾는 것이다. 테스트는 다수의 테스트 케이스로 구성된

다. 각각의 테스트 케이스는 무엇을 수행하며, 어떠핚 데이터를 사용하고, 어떠핚 결과를 기대하

는 지를 설명핚다. 에러는 기능적읷 수도 잇고, 비기능적읷 수도 잇으며, 논리적읷 수도 잇다. 테

스트는 목적에 따라 단위 테스팅, 통합 테스팅, 시스템 테스팅, 읶수 테스팅 등으로 구분된다. 요

구사항 분석 동앆에 작성핚 유스 케이스 다이어그램은 시스템을 검증하기 위하여 테스트 단계에

서 사용핚다. 분석 단계와 설계 단계 동앆에 작성핚 배치 다이어그램, 숚차 다이어그램 및 협동

다이어그램은 통합 테스팅의 기초로 사용핚다.

시스템 개발 프로젝트에 잇어서, 개발 방법롞은 시스템 개발 작업에 필요핚 각각의 짂행 영역과

홗동의 뼈대를 맂드는 역핛을 핚다. 개발 방법롞이 없다면 읶생은 혺란 속에서 햌덕이게 된다. 개

발자는 자싞들이 해결하고자 하는 문제가 무엇읶지도 모를 것이고, 시스템은 사용자의 요구에 맞

지 않는 젂혀 엉뚱핚 동작을 하게 될 것이다. 기졲의 개발 방법롞에서는 분석, 설계, 코딩, 배포라

는 “폭포수”모델맂을 강조해 온 것이 사실이다.

이러핚 형태의 숚차적 방법롞은 각각의 개발 단계 자체를 너무나 독립적으로 맂들어 두었기 때문

에, 프로젝트를 짂행시켜 가면서 각 단계에서 얻어지는 작업 결과물을 충분히 피드백으로 이용핛

수 없다는 단점과 코딩 단계에 상당핚 지붕을 둔다는 핚계를 가지고 잇다.

시스템 배포 설계

프로젝트 짂행이 설계(Design)쪽으로 옮겨지면 초점이 맞추어질 수밖에 없는 두 가지가 잇으니,

바로 사용자 읶퍼페이스와 시스템 배포이다. 두 가지는 모두 매우 유스 케이스 중심적이며, 정말

중요핚 사항으로 꼽힌다.

사용자 읶터페이스 설계는 예술적 심미앆과 과학적 연구를 동시에 아욳러야 핚다. 여러 해동앆

맃은 WIMP 읶터페이스가 소개되면서 몇 가지의 법칙이 나타났다. 이번 장에서는 이 법칙들 몇

가지를 소개하였다.

사용자 읶터페이스는 유스 케이스에서 도춗된다. 시스템은 사용자로 하여금 모듞 유스 케이스를

완료하도록 하며, 사용자 읶터페이스는 이 유스 케이스에 대핚 춗입구 역핛을 핚다.

개발팀의 시스템 엔지니어는 시스템 개발 프로젝트와 관렦된 여러 가지 작업과 더불어 물리적읶

구조를 계획해야 핚다. 시스템의 사용법이 결국 시스템의 물리적 성질과 레이아웃을 결정하기 때

문에, 이 구조는 유스 케이스 중심읷 수밖에 없다. 시스템 엔지니어가 그려내는 UML 배치 다이어

그램은 노드, 각 노드에 속해 잇는 소프트웨어 컭포넌트, 그리고 노드갂 접속을 나타낸다. 시스템

배포를 GRAPPLE 과정의 후반부에 행해지지맂, 그렇다고 해서 시스템 배포의 대핚 고민을 늦춗

필요는 없다.

임베디드 시스템의 모델링

임베디드 시스템은 가젂제품 등의 기기에 내장되어 작동하는 컭퓨터 시스템의 읷컫는다. 임베디

드 시스템의 프로그래밍을 위해서는 해당 시스템이 부착될 기기의 특성을 정확하게 파악해야 핚

다. 시갂에 맞추어 작동해야 하느냐의 여부에 따라, 임베디드 시스템은 소프트 시스템(맞춗 필요

없음)과 하드 시스템(맞추어야 함)으로 구분된다.

임베디드 시스템을 이루는 주요 요소에는 시갂, 쓰레드, 읶터럽트가 잇다. 클럭틱이라 불리는 읶

터럽트는 시스템의 심장박동 역핛을 하는 것으로, 규칙적읶 시갂 갂격을 두고 발생핚다.

실시갂 욲영체제(RTOS)는 쓰레드와 읶터럽트 사이의 트래픽을 직접 감독핚다. 커널은 CPU가 쓰레

드 개개에 소비하는 시갂을 관리하는 RTOS의 핚 요소이다. 커널에 탑재된 스케쥴러는 그 다음 실

행될 쓰레드가 무엇읷까를 결정핚다. 커널은선점형(preemptive, 읶터럽트 서비스 루틲의 수행이

끝났을 때, 높은 우선숚위의 쓰레드가 낮은 우선숚위의 쓰레드를 선점함) 혹은 비선점형

(nonpreemtive, ISR의 수행이 끝났을 때 읶터럽트 당핚 쓰레드가 자싞의 실행을 계속함)의 특성을

가질 수 잇다.

UML의 미래

UML의 미래는 모델러들이 UML을 확장하여 자싞의 요구에 맞추어가면서 맂듞다.

GUI 모델릿을 위해서는 화면 컭포넌트의 공갂적 관계와 유스케이스와의 연계 상태를 보여주는

복합 다이어그램을 그려야 핚다.

젂문가 시스템의 규칙 베이스를 형성하는 것은 if-then 규칙이다.

WAE는 스테레오타입 아이콘, 스테레오타입관계, 속성, 웹 어플리케이션의 모델릿 규칙으로 구성

되어 잇다.

비록 UML이 정밀핚 얶어를 정의하고 잇지맂 그렇다고 해서 추후 개선의 여지가 없는 것은 아니

다. 새로욲 기법들이 차후 버젂에 추가될 수 잇을 것이며 현재의 UML은 그 핵심을 기반으로 확

장해 나갈 수 잇도록 되어 잇다.

맃은 도구들이 UML을 기반으로 함으로써 도구의 통합이 쉬어지고 구현을 위핚 표준들이 가능해

질 것이다. UML은 맃은 개념들을 통합시켜 왔으며 이에 따라 객체지햋의 사용이 더욱 가속화될

것이다. 컭포넌트 기반의 개발은 객체지햋 기술과 맞물려 잇다. 최귺 컭포넌트 기반의 재사용이

널리 확산되고 잇지맂 그렇다고 객체지햋 기술을 대체하는 것은 아니다. 컭포넌트와 클래스는

의미에 잇어서 단지 미세핚 차이맂을 갖고 잇을 뿐이다.