Transcript 단원1(시작하기)
UML 사용자 지침서
(The Unified Modeling Language User Guide)
•UML 사용자 지침서(심재철, 신인식, 임춘봉 공역, 도서출판 인터비전)를 요약정리
•원서 : The Unified Modeling Language User Guide(Jacobson, Booch, Rumbaugh,
Addison-wesley)
Kwangju University
UML 사용자 지침서
1
목 차
단원 1. 시작하기
단원 2. 기본 구조 모델링
단원 3. 고급 구조 모델링
단원 4. 기본 행동 모델링
단원 5. 고급 행동 모델링
단원 6. 아키텍쳐 모델링
단원 7. UML 적용
Kwangju University
UML 사용자 지침서
2
단원 1. 시작하기
1장. 왜 모델을 만드는가 ?
2장. UML 소개
3장. UML의 기초
Kwangju University
UML 사용자 지침서
3
1장. 왜 모델을 만드는가 ?
모델링의 중요성
모델링의 원리
객체지향 모델링
Kwangju University
UML 사용자 지침서
4
모델링의 중요성
모델링 (Modeling)
모델을 만드는 일(추상화)로써 품질이 좋은 소프트웨어를 개발 및 배치할 수
있게 하는 모든 활동의 중심
모델 구축을 통해 개발 대상 시스템에 대한 이해의 증진
모델 (Model)
현실을 단순화/가시화 시키는 것
System의 Blueprint를 제공
개발 고려 시스템의 총체적인 계획 및 상세 계획 표현
중요 영향 요소의 파악, 불 필요 요소의 생략 및 시스템 구축 제약 조건 표
현
모델링의 목적
시스템을 현재 또는 원하는 모습으로 가시화
시스템의 구조와 행동을 명세화
시스템을 구축하는 기본 형태를 제공
시스템 분석/설계의 문서화
Kwangju University
UML 사용자 지침서
5
모델링의 원리
모델링의 원리
생성할 모델의 신중한 선택 : 선택 모델에 따라 문제를 공략하는 방법과 해결
책을 실현하는 방법에 많은 영향이 있음
모든 모델을 다양한 수준의 정밀도로 표현
현실을 반영한 모델 작성
상호 독립적인 모델들 몇 가지를 선택하여 모델링에 착수
Kwangju University
UML 사용자 지침서
6
객체 지향 모델링
소프트웨어의 모델링 관점
알고리즘 관점 : S/W의 주요 구성 요소인 Procedure 와 Function을 제어
관점에서 분할하여 시스템을 모형화
요구사항 변화에 적응력이 없음
대규모 시스템에서는 유지보수를 포함한 관리의 어려움
객체 지향 관점 : S/W 시스템의 기본 요소를 객체 또는 클래스로 파악하여
문제 영역과 해결 영역을 모형화
객체(Object) : 사물(Thing)을 말하며 고유성과 상태, 행동을 갖음
클래스(Class) : 공통적인 객체들의 집합
UML(Unified Modeling Language)의 목적
객체 지향 시스템을 가시화, 명세화, 문서화 하는 것
Kwangju University
UML 사용자 지침서
7
2장. UML 소개
UML
UML
UML
UML
개요
개념 모델
아키텍쳐
개발 생명주기
Kwangju University
UML 사용자 지침서
8
UML 개요
산출물
S/W
UML
청
사
진
작
성
표
준
언
어
가시화
명세화
SYSTEM
구축
문서화
UML은 언어(Language)
어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현하여 의사 소통을
돕는 것을 목적으로 함
시스템을 이해하기 위하여 하나 이상의 모델을 서로 연결 사용하여 복합적
인 모델로 이해를 도움
Kwangju University
UML 사용자 지침서
9
UML 개요(계속)
가시화 언어
명세화 언어
개념 모델 작성
오류 없이 전달
의사 소통의 용이
Graphic 언어
정확한 모델 제시
완전한 모델 작성
분석,설계의 결정 표현
UML
문서화 언어
구축 언어
시스템에 대한 통제,
평가, 의사소통의 문서
(요구사항, Architecture,
설계, Source Code,
Project 계획,Test,
Prototype, Release)
다양한 Prog. 언어와 연결
왕복 공학 가능
(순 공학/역공 학)
실행 시스템 예측 가능
Kwangju University
UML 사용자 지침서
10
UML 개념 모델
UML 구성 요소
사물
(Things)
구 조 사물
UML 구성 요소
관계
(Relationships)
도해
(Diagrams)
Structural Thing
의 존 관계
Dependency
클 래스 도
Class Diagram
행 동 사물
Behavioral Thing
연 관 관계
Association
객체 도
Object Diagram
그 룹 사물
Grouping Thing
일 반화 관 계
Generalization
쓰 임새 도
Use Case Diagram
주 해 사물
Annotation Thing
실 체화 관 계
Realization
순차 도
Sequence Diagram
협력 도
Collaboration Diagram
상태 도
State Chart Diagram
활동 도
Activity Diagram
컴 포넌트 도
Component Diagram
배치 도
Deployment Diagram
Kwangju University
UML 사용자 지침서
11
UML 개념 모델(계속)
사물 (Things) : 추상적 개념으로 모형 구성의 기본 요소
구조 사물 (Structural Thing) : UML 모형의 명사형으로써 모형의 정적인
부분이며 개념적이거나 물리적인 요소들을 표현
클래스 (Class)
동일한 속성(Attribute), Operation, 관계, 그리고 의미를 공유하는 객체를 표현
Window
origin
size
open ( )
close ( )
move ( )
display ( )
인터페이스 (Interface)
Class 또는 Component의 Service를 명세화 하는 Operation들의 집합
외부적으로 가시화 할 수 있는 요소의 행동을 설명
특정 Class나 Component의 전체 또는 일부분 만의 행동을 표현
ISpelling
Kwangju University
UML 사용자 지침서
12
UML 개념 모델(계속)
협력 (Collaboration)
교류(Interaction)를 정의하며 서로 다른 요소와 역할들의 집합을 표현
시스템을 구성하는 Pattern을 표현 - Class의 행동적이고 구조적인 중요성을 도식
Chain of
responsibility
쓰임새 (Use Case)
시스템이 수행하는 순차적 활동들을 기술하며 행위자(Actor)에게 결과치를 제공
행동 사물을 구조화하기 위하여 사용하며 협력으로 실현
use
Chain of
responsibility
활성 클래스 (Active Class)
객체가 하나 또는 그 이상의 Process나 Tread를 갖는 클래스 (제어 활동을 포함)
객체들의 행동이 다른 요소들과 함께 동시적으로 발생
EventManager
suspend ( )
flush ( )
Kwangju University
UML 사용자 지침서
13
UML 개념 모델(계속)
컴포넌트 (Component)
시스템의 물리적이고 대체 가능한 부분으로 Interface를 준수하고 구현
Class, Interface, Collaboration 등 서로 다른 논리 요소를 물리적으로
Package화
Component 종류 : Application, Document, File, Library, Page, Table, …..
orderform.java
노드 (Node)
실행 시에 존재하는 물리적 요소이며 Computer 자원을 나타내고 약간의
Memory와 처리 능력을 포함
Server
Kwangju University
UML 사용자 지침서
14
UML 개념 모델(계속)
행동 사물 (Behavioral Thing) : UML 모형의 동사형으로써 모형의 동적인
부분이며 시간과 공간에 따른 행동 요소들을 표현
교류 (Interaction)
행위이며 지정된 목적을 완성하기 위하여 특정 문맥에 속한 객체들 사이에 주고
밭는 Message들로 구성
Display
상태 머신 (State Machine)
상태의 순서를 지정하는 행동
하나의 객체 혹은 교류에 발생하는 사건(Event)에 대한 대기 및 응답의 표현
Waiting
Kwangju University
UML 사용자 지침서
15
UML 개념 모델(계속)
그룹 사물 (Grouping Thing) : UML 모형을 조직하는 부분이며 모델을 분해
하여 재 구성화 할 수 있는 단위 상자
패키지 (Package)
요소들을 Group으로 묶는 다목적 Mechanism
Component와는 다르며 개발 시에만 존재하는 개념적인 모형
종류 : Frame Work, Sub System 표현
Business Rules
Kwangju University
UML 사용자 지침서
16
UML 개념 모델(계속)
주해 사물 (Annotation Thing) : UML 모형을 설명하는 부분이며 Comment
로써 모형 요소를 설명하고, 명확히 하는 표현 도구
노트 (Note)
하나의 요소 또는 요소들로 구성된 공동체에 첨부되는 제약과 주석을 표현하는
기호
Return copy
of self
Kwangju University
UML 사용자 지침서
17
UML 개념 모델(계속)
관계 (Relationships) : 구성 요소 간의 의미 있는 연결
의존 관계 (Dependency Relationship)
두 사물간의 의미적인 관계로써 한쪽(독립) 사물의 변화가 다른(종속) 사물에 영향
을 주는 관계
연관 관계 (Association Relationship)
구조적 관계로써 Link(객체 간의 연결)의 집합을 나타냄
집합(Aggregation) 연관 관계는 특별한 연관 관계로써 전체(Whole)와 부분(Part)
간의 구조적 관계를 표현
0 .. 1
Employer
Kwangju University
*
Employee
UML 사용자 지침서
18
UML 개념 모델(계속)
일반화 관계 (Generalization Relationship)
특수화(Specialization)/일반화(Generalization) 관계로써 일반화 된 요소(Parent)
의 객체를 특수화된 요소(Child)의 객체로 치환할 수 있는 관계(Child는 Parent
의 구조와 행동을 공유)
실체화 관계 (Realization Relationship)
분류자(Classifier) 간의 의미적 관계
한 쪽 분류자는 다른 쪽 분류자가 수행하기로 되어 있는 계약(Contract)을 명세화
Kwangju University
UML 사용자 지침서
19
UML 개념 모델(계속)
도해 (Diagramming) : 구성 요소 들의 Graphic 표현
클래스도 (Class Diagram)
Class, Interface, Collaboration 간의 관계를 나타내며 객체 지향 시스템 모형화
에서 가장 공통적으로 많이 쓰이는 Diagram
Class Diagram : 시스템의 정적(Static) 설계 View
Active Class Diagram : 시스템의 정적 Process View
객체도 (Object Diagram)
객체들 사이의 관계를 표현
Class Diagram에 있는 사물들의 Instance에 대한 정적 Snap Shut을 표현
실제 사례나 Prototype 사례의 시각에서 도해
쓰임새도 (Use Case Diagram)
Use Case, Actor 간의 관계를 표현
시스템 행동을 조직화하고 Modeling
시스템의 정적 Use Case View
순차도 (Sequence Diagram), 협력도 (Collaboration Diagram)
교류도 (Interaction Diagram)의 한 종류로 객체와 객체 간의 관계, 그리고 객체
간에 보낼 수 있는 Message 들로 구성
순차도 와 협력도 는 동일 구조로써 상호 변형가능하며 순차도 는 Message의 시간
적 순서를 강조하고 협력도 는 객체의 구조적 구성을 강조
시스템의 동적(Dynamic) View
Kwangju University
UML 사용자 지침서
20
UML 개념 모델(계속)
상태도 (State Diagram)
상태(State), 전이(Transition), 사건(Event), 활동(Activity)로 구성
사건에 따라 순차적으로 발생하는 객체 행동에 중점을 두고 작성
시스템의 동적 View
활동도 (Activity Diagram)
특별한 종류의 상태도로써 시스템 내부에 있는 활동간의 흐름을 표현
시스템의 기능을 모형화하고 객체간의 제어 흐름 표현에 유용
시스템의 동적 View
컴포넌트도 (Component Diagram)
Component 간의 구성과 의존 관계를 표현
시스템의 정적 구현 View
배치도 (Deployment Diagram)
실행 시 처리하는 Node와 그 Node에 존재하는 Component 들의 구성을 표현
Architecture의 정적 배치 View
Kwangju University
UML 사용자 지침서
21
UML 개념 모델(계속)
UML 규칙
UML 규칙은 자체 일관성이 있으며 관련 Model들과 조화를 이룸
이름
(Name)
범위
(Scope)
가시성
(Visibility)
무결성
(Integrity)
실행
(Execution)
사물, 관계, 도해의 호칭
이름에 특정한 의미를 부여하는 문맥(Context)
이름을 참조하고 사용할 수 있는 방법
사물 상호간에 올바르고 일관성 있는 관계를
유지시키는 방법
동적 Model을 실행하거나 모의 실험 하는 것
잘못된 모형
생략
View를 단순화 하려고 특정 요소를 감춤
(Elided)
불완전
특정 요소를 빼고 작성
(Incomplete)
불일치
모델의 무결성이 보장되지 않음
(Inconsistent)
Kwangju University
UML 사용자 지침서
22
UML 개념 모델(계속)
UML 공통 Mechanism
명세서 (Specification)
UML의 Graphic 표현에 구문법과 구성 요소의 의미를 포함하여 점진적으로 모델
을 구성
표기 (Adornment)
UML 요소의 고유하고 직접적인 Graphic 표기 등 요소의 가장 중요한 관점을 가
시적으로 표현
Transaction
+ execute ( )
+ rollback ( )
# priority ( )
- timestamp ( )
Kwangju University
UML 사용자 지침서
23
UML 개념 모델(계속)
공통 분할 (Common Division)
객체 지향 모델링은 다시 몇 가지로 나누어 표현 가능
Class와 Object의 분할
Customer
Jan : Customer
name
address
phone
: Customer
Elyse
Interface와 구현의 분리
IUnknown
spellingwizard.dll
ISpelling
Kwangju University
UML 사용자 지침서
24
UML 개념 모델(계속)
확장 메커니즘 (Extensibility Mechanism)
UML의 목적인 분석/설계 정보를 정확하게 전달하기 위한 표준 언어를 제공
하나의 언어로 불가능한 모형은 통제된 방법으로 언어를 확장
스테레오 타입 (Stereotypes)
UML 어휘를 확장하여 새로운 종류의 구성 요소를 생성
기존 구성에서 파생되므로 문제 영역은 기존 구성 요소의 고유한 것
꼬리표 값 (Tagged Values)
UML의 구성 요소가 갖는 Property를 확장
구성 요소의 명세서에 새로운 정보를 추가 생성 가능하도록
제약 (Constraints)
UML 구성 요소가 갖는 의미를 확장하여 새로운 규칙의 추가 및 기존 규칙 변경
Stereotype
“exception”
Overflow
Kwangju University
EventQueue
{version = 3.2
author = YL}
Tagged Value
add ( )
remove ( )
flush ( )
UML 사용자 지침서
Constraint
{ordered}
25
UML 아키텍쳐
아키텍쳐 결정 사항
S/W System의 구성
System 구성 요소들과 요소들 간의 Interface 선택
요소들 간의 협력으로 명세화 되는 행동을 결정
점진적으로 큰 시스템으로의 구조 요소와 행동 요소를 결합
아키텍쳐 양식(정적/동적)들과 이들의 Interface, 협력, 결합을 표현
S/W Architecture
구조와 행동
용도, 기능성, 성능, 탄력성, 재 사용성, 경제성
기술적 제약 및 방법
미학적 표현
. . . .
Kwangju University
UML 사용자 지침서
26
UML 아키텍쳐(계속)
S/W 중심 시스템의 Architecture Modeling
어휘
기능성
설계 뷰
(Design View)
구현 뷰
(Implementation View)
시스템 조립
형상관리
쓰임새 뷰
(Use Case View)
성능
확장성
처리량
프로세스 뷰
(Process View)
Kwangju University
배치 뷰
(Deployment View)
UML 사용자 지침서
시스템 구성 형태
분산, 인도, 설치
27
UML 아키텍쳐(계속)
아키텍쳐 종류
쓰임새 뷰
(Use Case View)
설계 뷰
(Design View)
프로세스 뷰
(Process View)
구현 뷰
(Implementation
View)
내 용
정적 도해
동적 도해
시스템 행동을 설명
최종사용자, 분석가, 설계자, 테스트 담당자에게 제공
되는 뷰
시스템 아키텍쳐를 구체화하는 요인들을 명세화
쓰임새도
교류도
상태도
활동도
시스템이 최종사용자에게 제공해야 할 서비스를 표현
문제 영역과 해법의 어휘를 형성하고 있는 Class,
Interface, Collaboration으로 구성
클래스도
객체도
교류도
상태도
활동도
시스템의 성능, 신축성, 처리 능력을 표현
클래스도
시스템의 동시성과 동기화 메커니즘을 형설하고 있는
객체도
Thread와 Process로 구성
활성 클래스도
교류도
상태도
활동도
시스템 배포의 형상관리 표현
물리적인 시스템을 조립하고 배포하는데 사용되는
Component와 File 들로 구성
컴포넌트도
교류도
상태도
활동도
배치도
교류도
상태도
활동도
시스템을 구성하는 물리적 부분의 분산, 인도, 설치 표현
(Deployment View) H/W 형태를 형성하는 Node로 구성
배치 뷰
Kwangju University
UML 사용자 지침서
28
UML 개발 생명주기
개발 Process 고려 사항
UML은 개발 Process에 독립적 임
프로세스
설 명
System에 요구되는 행동을 파악
쓰임세 중심
System Architecture 검증, 확인 및 Test
Project 관련자의 의사소통
(Use Case 관련 주요 산출물 활용)
개발중인 System의 개념화, 구축, 관리
아키텍쳐 중심
진화(변화) 내용을 파악하고 수행
(System Architecture 관련 주요 산출물 활용)
반복/점진적
프로세스 중심
Kwangju University
반복 프로세스는 실행 배포판을 관리
점진적 프로세스는 System Architecture를 지속적으로
통합하고 개정 배포판을 작성
UML 사용자 지침서
29
UML 개발 생명주기(계속)
S/W 개발 생명 주기 단계
각 단계는 반복적으로 수행되며 반복은 별개 활동으로써 대내외적으로 배포
판을 만드는 기준 계획과 평가 기준을 갖음
단계
도입
(Inception)
설 명
개발의 시작점으로써 대상 요소들을 정의
정련 단계로 진입할 수 있는 충분한 근거 파악
정련
(Elaboration)
제품 Vision과 Architecture를 정의
System의 요구 사항의 명료화, 우선 순위 결정, 기준선 설정 및
Test 기준 설정
요구 사항의 기능적 행동과 비 기능적 행동을 명세화
구축
(Construction)
S/W의 작성 및 실행
Architecture 기준선으로부터 전이의 준비 단계
Project에 대한 요구 사항과 평가 기준의 재 검사
위험 요소들을 제거하기위한 자원의 할당
전이
(Transition)
Kwangju University
S/W의 사용자 전달
System의 지속적인 개선, 결함 제거
배포판에 새로운 특성 추가
UML 사용자 지침서
30
UML 개발 생명주기(계속)
Phases
Core Workflows
Inception
Elaboration
Construction
Transition
Requirements
An iteration in the
elaboration phase
Analysis
Design
Implementation
Test
P r e lim in a ry
Ite ra tio n (s )
ite r.
#1
ite r.
#2
ite r.
#n
ite r.
#n+1
ite r.
#n +2
ite r.
#m
ite r.
#m +1
Ite ra tio n s
Kwangju University
UML 사용자 지침서
31
3장. UML 기초
핵심 부분 추상화
메카니즘
컴포넌트
Kwangju University
UML 사용자 지침서
32
핵심 부분 추상화
Web Browser Java Applet “Hello World ! “의 예제
Class
import java.awt.Graphics ;
class HelloWorld extends java.applet.Applet
Package
{ public void paint (Graphics g)
{ g’.drawString (“Hello, World !”, 10 , 10); } }
Parameter
Kwangju University
호출 OP.
UML 사용자 지침서
Operation
33
핵심 부분 추상화(계속)
HelloWorld의 핵심 부분 추상화
HelloWorld
G.drawString
(“Hello, World !”, 10, 10)
paint ( )
HelloWorld 주위의 인접 Class
Applet
일반화 관계
(상속 관계)
HelloWorld
paint ( )
Kwangju University
의존 관계
Graphics
UML 사용자 지침서
34
핵심 부분 추상화(계속)
HelloWorld 상속(Inheritance) 계층도
Object
Component
구현 부분은 없으며 다른 Class에서
Interface를 구현할 필요가 있음
ImageObserver
Container
Java에 있는 모든 Class의
Parent Class
Panel
Applet
HelloWorld
Kwangju University
UML 사용자 지침서
35
핵심 부분 추상화(계속)
HelloWorld의 Package도
Java
HelloWorld
applet
awt
lang
Kwangju University
UML 사용자 지침서
36
메카니즘
메커니즘 표현
Class의 상속 관계의 표현이 아닌 Operation의 실행을 표현
각 Class에 속하는 Instance를 포함해서 다수의 객체들이 순서를 갖고 협력
하는 것을 표현
Painting Mechanism
Instance
: Toolkit
: Thread
: ComponentPeer Target : HelloWorld
Run
Run
CallbackLoop
Operation
Kwangju University
handleExpose
UML 사용자 지침서
paint
37
컴포넌트
컴포넌트 표현
실행 가능한 컴포넌트를 연결하여 각 메커니즘에 의해 기동 되는 것을 도식
개발 환경과 구성 관리 툴을 포함하여 표현
HelloWorld Component
HelloWorld.java
hello.html
HelloWorld.class
hello.jpg
Kwangju University
UML 사용자 지침서
38
단원 2. 기본 구조 모델링
4장.
5장.
6장.
7장.
8장.
클래스
관계
공통 메카니즘
도해
클래스도
Kwangju University
UML 사용자 지침서
39
4장. 클래스(Class)
시작하기
용어와 개념
보편적 모델링 기법
시스템 어휘 모델링
시스템에서 책임 분산 모델링
비 소프트웨어 사물 모델링
원시 타입 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
40
시작하기
클래스(Class) 란 ?
어휘의 일부가 되는 사물들을 추상화 하는 것
클래스는 가장 중요한 구성 요소이며 동일한 속성, Operation, Relation 그
리고 의미를 공유하는 객체 집합을 표현
하나 또는 그 이상의 Interface를 구현
Class 명
Shape
origin
move ( )
resize ( )
display ( )
Kwangju University
Attribute 명
Operation 명
UML 사용자 지침서
41
용어와 개념
Class 명
모든 Class는 다른 Class 들과 구별되는 유일한 명칭을 갖음
단순명 (Simple Name) : Class 자체만을 표현
경로명 (Path Name) : Class가 소속된 Package명을 포함
Simple Name
Temperature
Sensor
Path Name
Customer
Business Rules :: FraudAgent
Wall
Kwangju University
Java :: awt :: Rectangle
UML 사용자 지침서
42
용어와 개념(계속)
속성 (Attribute)
Class의 Property에 이를 대표하는 짧은 명사나 명사구로 이름을 붙인 것
속성 표현
속성과 타입 표현
Visibility Name : Type = Default Value
Attribute Default Value
Attribute Type
Signature
Attribute Name
+ : Public
- : Private
# : Protection
Customer
name
address
phone
birthdate
Kwangju University
Wall
height : float
width : float
thickness : float
isLoadBearing : Boolean = false
UML 사용자 지침서
43
용어와 개념(계속)
오퍼레이션 (Operation)
객체 행동에 영향을 주기 위해 특정 Class의 객체로부터 요청할 수 있는 Service를
표현한 것 (객체에서 할 수 있는 것이 무엇인가를 추상화 한 것)
오퍼레이션 표현
오퍼레이션(Operation : Class)과 용법(Method : Object) 표현
속성과 오퍼레이션 구성
Visibility Name (Parameter-List) : Return-Type-Expression {Property-String}
Rectangle
add ( )
grow ( )
move ( )
isEmpty ( )
Kwangju University
TemperatureSensor
FaudeAgent
<<constructor>>
reset ( )
setAlarm (t : Temperature) new ( )
new (p : Policy)
value ( ) : Temperature
<<process>>
Stereotype
process (o : Order)
...
<<query>>
isSuspect (o : Order)
isFraudulent (o : Order)
<<helper>>
validateOrder (o : Order)
UML 사용자 지침서
44
용어와 개념(계속)
책임 (Responsibility)
Class가 행해야 하는 의무 또는 계약
속성과 오퍼레이션 특성들로 Class의 책임을 수행
FraudAgent
Responsibilities
-- determine the risk of a customer order
-- handle customer - specific criteria for fraud
CRC(Class Responsibility Collaboration) Card
Order
Class
Check if items in stocks
Responsibility
Order Line
Determine price
Check for valid payment
Collaboration
“
Customer
Dispatch to delivery address
Kwangju University
UML 사용자 지침서
45
보편적 모델링 기법
시스템 어휘 모델링
사용자나 개발자가 문제나 해법을 설명하기 위해 사용하는 사물을 파악(CRC
Card, Use Case 중심 분석)
추상 개념에 대한 책임을 파악
Class의 책임을 수행하기 위하여 필요한 속성과 오퍼레이션 파악
Customer
name
address
phone
birthdate
Transaction
actions
commit ( )
rollBack ( )
wasSuccessful ( )
Order
item
quantity
Warehouse
Invoice
Product
id
name
price
location
Shipment
Responsibilities
-- maintain the information regarding products shipped against an orde
-- track the status and location of the shipped product
모델은 점점 커지게 되며 개념적 또는 의미적으로 연관 있는 것 끼리 Class
집단을 모델링 하여 Package화 함
Kwangju University
UML 사용자 지침서
46
보편적 모델링 기법(계속)
시스템 책임 분산 모델링
어떤 행동을 수행하기위해 긴밀하게 연관 있는 Class 집합을 파악
Class 각각의 책임 집합 파악
Class에 너무 많은 책임이 있으면 작게, 너무 적은 책임이 있으면 여러 개를
모아서 하나의 역할을 수행할 수 있는 합리적 Class로 재 할당
서로 교류하는 것을 파악하여 적절하게 책임을 재 분배
Model
View
Responsibilities
-- manage the state of the model
Controller
Responsibilities
-- render the model on the screen
-- manage movement and resize of the view
-- intercept user events
Responsibilities
-- synchronize changes in
the model and its views
Kwangju University
UML 사용자 지침서
47
보편적 모델링 기법(계속)
비 소프트웨어 사물 모델링
추상화 대상 사물을 Class로 Modeling
이미 정의된 구성 요소들과 구분을 위해 Stereotype을 사용하고 새로운 의
미와 분명한 시각적 암시를 제공
Modeling하려는 대상이 S/W를 포함하는 H/W의 일종이면 Node로
Modeling
Account Receivable Agent
Robot
processOrder ( )
change Order ( )
status ( )
Kwangju University
UML 사용자 지침서
48
보편적 모델링 기법(계속)
원시 타입 모델링
추상화 대상 사물을 Type이나 열거 Type으로 Modeling하고 Stereotype과
함께 Class로 표현
이 Type에 값의 범위를 지정하려면 제약을 사용
<<type>>
Int
{values range from
-2**31-1 to +2**31}
<<enumeration>>
Status
idle
working
error
Kwangju University
UML 사용자 지침서
<<enumeration>>
Boolean
false
true
49
힌트와 조언
좋은 구조의 Class
문제 영역이나 해법 영역 어휘에서 추출된 Class에 대한 명확한 추상화 제공
작고도 정의가 잘된 책임 집합을 가지며 그들 모두를 매우 잘 수행
추상 개념 명세서와 구현을 분명하게 구분
이해하기 좋고, 단순하며, 확장 가능하고, 적응이 용이
UML에서 Class를 도해 방법
문맥상에서 추상화를 이해하기 위해 꼭 필요한 Property만을 표현
속성이나 오퍼레이션 목록이 많으면 범주에 따라 Group으로 분류하여 조직화
관련된 Class들은 같은 Class도에 표현
Kwangju University
UML 사용자 지침서
50
5장. 관계 (Relationship)
시작하기
용어와 개념
보편적 모델링 기법
단순 의존 모델링
단일 상속 모델링
구조적 관계 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
51
시작하기
관계(Relationship)란 ?
UML에서 사물(Thing)들이 상호 논리적/물리적으로 연결되는 것
관계 종류 : 의존 관계, 일반화 관계, 연관 관계
특정 프로그래밍 언어와 무관하게 관계를 도해하는 것을 가능하게 하며 관계에서
중요한 부분을 강조할 수 있도록 함
관계 이름, 연결 대상, 관계 Property
의존
Window
open ( )
close ( )
move ( )
display ( )
handleEvent ( )
Event
ConsoleWindow
일반화
DialogBox
Control
연관
Kwangju University
UML 사용자 지침서
52
용어와 개념
의존 (Dependency)
사용 관계로써 한 사물의 명세서가 바뀌면 이를 사용하는 다른 사물에게 영
향을 미침
Class 문맥에서 한 Class가 다른 Class를 Operation 용법에 Parameter로 사
용하는 경우에 주로 활용
사용중인 Class가 바뀌면 상대 Class의 Operation이 함께 영향을 받음
Transaction
name
playOn (c:Channel)
Channel
start ( )
stop ( )
Dependency Relationship
reset ( )
Kwangju University
UML 사용자 지침서
53
용어와 개념(계속)
일반화 (Generalization)
“ is-a kind-of ” 관계
일반화된 사물(Super type, Parent type)과 보다 특수화된 사물(Sub type,
Child type)들 사이의 관계를 표현
Child 객체는 Parent 객체가 사용되는 어느 곳에서나 사용될 수 있음
Shape
Generalized Relationship
Rectangle
corner : Point
Square
Kwangju University
origin
move ( )
resize ( )
display ( )
Circle
radius : Float
Leaf Class
UML 사용자 지침서
Base Class
Polygon
points : List
display ( )
54
용어와 개념(계속)
연관 (Association)
“ has-a ” 관계
구조적인 관계로써 특정 사물 객체가 다른 사물 객체와 관계가 있음을 표현
두 Class가 서로 연결되어 연관이 있다면 한쪽 객체에서 다른 객체로 옮겨 갈
수 있으며 그 반대도 가능 (쌍방 연관)
name
name direction
Works for
Person
Company
Association Relationship
역할(Role name) 표현
Person
employee
employer
Company
역할명(role name)
Kwangju University
UML 사용자 지침서
55
용어와 개념(계속)
다중성(Multiplicity) 표현
다중성(Multiplicity)
Person
1 .. *
*
employee employer
Company
집합 연관(Aggregation) 표현 : “ part-of ” 관계
독자 운영 가능
합성 연관(Composition) 표현
단독 사용 불가하며 반드시 Super Class(Object)와 함께 사용
Company
Employee
1
1
Aggregation
*
1
Department
Kwangju University
Composition
Body
UML 사용자 지침서
56
보편적 모델링 기법
단순 의존 모델링
특정 Class가 다른 Class를 Operation에서 Parameter로만 사용하는 관계
Operation에서 Parameter로 상대 Class를 사용하려는 Class쪽에서 의존 관
계를 표현
CourseSchedule
add (c : Course)
remove (c : Course)
Course
Iterator
Kwangju University
UML 사용자 지침서
57
보편적 모델링 기법(계속)
단일 상속 모델링
구조적, 행동적 특성을 파악하여 일반화 Class와 특수화 Class로 구분하여 작
성
Class 집합에서 둘 이상 다수의 Class에 공통으로 존재하는 책임, 속성,
Operation을 파악
파악된 책임, 속성, Operation을 일반화 Class로 작성
특수화 Class는 일반화 Class로부터 상속되도록 관계를 설정
Security
presentValue ( )
history ( )
CashAccount
interestRate
presentValue ( )
Stock
Bond
presentValue ( )
presentValue ( )
SmallCapStock
Kwangju University
Property
assesment
presentValue ( )
LargeCapStock
UML 사용자 지침서
58
보편적 모델링 기법(계속)
구조적 관계 모델링
의존(사용 관계)/일반화(부분 관계) 관계와 같이 일방적인 관계가 아닌 Class
간에 대등한 관계
한 쌍의 Class에 대하여 한 객체들로부터 다른 객체로의 왕래가 필요하면 두
Class사이에 연관 관계를 지정
한 쌍의 Class에 대하여 한 Class 객체가 다른 Class 객체와 Operation
Parameter 이외의 방법으로 교류하면 관계 설정(행동 중심적 관점)
각 연관에 대해 다중성, 역할 명을 표현
한쪽 Class가 구조적, 조직적으로 전체가 되고 다른 쪽이 부분 관계와 같이
판단되면 집합 연관으로 표현
School
1 .. *
has
1
1 .. *
Department
1 .. *
0 .. 1
1 .. *
assignedTo
member
*
Student
Kwangju University
1 .. *
attends
*
*
Course
*
UML 사용자 지침서
0 .. 1
chairperson
1 .. *
teaches
Instructor
1 .. *
59
힌트와 조언
UML에서 관계를 Modeling하려면
Modeling 대상 관계가 구조적이 아닌 경우에만 의존 사용
일반화는 “is-a-kind-of” 관계일 때만 사용하며 다중 상속은 집합 연관으로
표현
순환하는 일반화 관계는 표현하지 않도록 유의
일반화 관계를 전체적으로 균형 있게 유지(상속 계층이 너무 깊거나, 넓지 않
도록)
연관은 객체간에 구조적 관계가 있을 때 사용
UML의 관계 도해
직사각형을 이루는 직선이나 사선의 사용 금지
가능하면 관계를 표현하는 선이 서로 교차하지 않도록
사물의 특정한 모임을 이해하기 쉬울 정도의 필요한 만큼의 관계만 표현
Kwangju University
UML 사용자 지침서
60
6장. 공통 메카니즘(Common Mechanism)
시작하기
용어와 개념
보편적 모델링 기법
주석 모델링
새로운 구성 요소 모델링
새로운 프로퍼티 모델링
새로운 의미 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
61
시작하기
UML Mechanism : 분석/설계 내용을 쉽게 이해하도록 산출물 작성
명세
장식
공통
확장
(Specification)
(Adornment)
분할 (Common Division)
(Extensibility)
UML 확장 Mechanism : 새로운 구성 요소 추가, 새로운 Property, 의미 지정
스테레오 타입 (Stereotype)
꼬리표 값 (Tagged Value)
제약 (Constraint)
공통 Mechanism 사용 이유
UML은 다양한 시스템의 산출물을 제공하지만 약간의 변형이나 확장으로 보다
나은 의사 소통이 가능
Stereotype
note
Tagged Value
<<subsystem>>
Billing
Constraint
{version = 3.2}
Consider the use of the
broker design patter here.
{>56Kbps}
egb 10/22/99
Kwangju University
Server
UML 사용자 지침서
Remote Client
62
용어와 개념
장식 (Adornment)
Note
주석을 표현하는 Note는 의미상 아무런 영향을 미치지 못 함 (이해를 돕는 단순 설
명)
단순 Text
문서의 연결
다른 장식
See http://www.gamelan.com
for an example of this applet
See encrypt.doc for
details about this algorithm
Transaction
addAction ( )
removeAction ( )
perform ( )
rollBack ( )
exceptions
emptyTransaction
noSuchAction
resourceLocked
Kwangju University
삽입 URL
Publish this component in
the project responsibility after
the next design review.
Client
bill.exe
report.exe
contacts.exe
이름 없는 칸
이름 있는 칸
UML 사용자 지침서
63
용어와 개념(계속)
스테레오 타입(Stereotype)
UML에서 제공하는 구조 사물, 행동 사물, 그룹 사물, 주해 사물을 이용한
표현에서 새로운 원시 구성 요소처럼 나타내고 할 때 사용
<< meteclass >>
ModelElement
이름 있는 Stereotype
Icon과 이름 있는 Stereotype
<< exception >>
Underflow
!
Icon으로 표시한 Stereotype 요소
HumiditySensor
Kwangju University
UML 사용자 지침서
64
용어와 개념(계속)
꼬리표 값 (Tagged Value)
UML 산출물에 새로운 Property 추가할 때 사용
<< library >>
flower.dll
{serverOnly}
꼬리표 값
Server
{processors = 3}
Kwangju University
UML 사용자 지침서
65
용어와 개념(계속)
제약 (Constraint)
제약을 이용하여 새로운 의미를 추가하거나 기존 규칙을 수정
Model이 잘 구성되도록 하기 위하여 반드시 지켜야 할 조건들을 지정
Portfolio
단순 제약
여러 요소 간의 제약
Corporation
{secure}
BankAccount
{or}
wife
Person
0
gender : {female, male} .. 1
0 .. 1
husband
OCL로 나타낸 정형적 제약
{self.wife.gender = female and
self.husband.gender = male}
Kwangju University
UML 사용자 지침서
66
보편적 모델링 기법
주석 (Comment) Modeling
주석을 Model에 둠으로써 개발 과정에서 만들어진 각종 분산 산출물(관찰 기록,
검토 의견, 설명, . . . )에 대한 공통 저장소 역할
주석 모델링 방법
문장으로 작성하여 Note에 담고 관련 요소를 근처에 배치하여 의존 관계를 표현
해당 문맥의 정보에 관한 의사 소통의 필요가 있는 경우에만 표현
주석이 길거나 단순 문장 이상인 경우 별도 문서로 작성하거나 내장 시켜 모델에 표현
Model이 진화 할 수록 중요한 결정 사항을 기록하되 추론이 불가능한 주석만 남김
Security
<< requirement >>
Shall conform to corporate
presentValue ( )
framework for transaction logging,
history ( )
in compliance with federal law.
CashAccount
interestRate
presentValue ( )
Mary : add two intermediate
abstract classes to distinguish
read/intangible securities
walkthrough on 10/22/99
Stock
Bond
presentValue ( )
presentValue ( )
Property
assesment
presentValue ( )
See policy 8-5-96.doc for
details about these algorithm
Kwangju University
UML 사용자 지침서
67
보편적 모델링 기법(계속)
새로운 구성 요소 Modeling
UML 구성 요소(Class, Interface, Collaboration, Component, Node,
Relation, ..) 들로 불충분한 표현의 어휘 확장(Stereotype 사용)
새로운 구성 요소 모델링 방법
기본 구성 요소로 표현 불가능을 파악
사용할 구성 요소가 없을 경우 스테레오 타입으로 표현
표현하려는 기본 요소에 정의된 이상의 공통 Property와 의미에 대하여 꼬리표 값
과 제약들의 집합으로 정의
Stereotype 요소들이 명백한 시각적 암시를 표현하도록 하기 위하여 새로운 Icon
정의
Registration
Competition
: Coach
Register Team
: Team
[unregistered}
Pay fees
Get event
materials
Return event
materials
Kwangju University
: Team
[registered}
Practice
Compete
Get event results
: Team
[finished}
UML 사용자 지침서
68
보편적 모델링 기법(계속)
새로운 Property Modeling
포괄적인 Property 보다 상세하게 새로운 구성 요소의 Property를 꼬리표 값으로
사용
새로운 Property 모델링 방법
기본 Property로 표현 불가능을 파악
사용할 Property가 없을 경우 새로운 Property를 각 요소나 스테레오 타입으로 추가 일반적인 원칙이 적용되며 요소에 정의된 꼬리표 값은 하위 Class에도 적용 됨
<< subsystem >>
FieldAccess
{version = 2.5
status = checkedln}
<< subsystem >>
AccountPayable
<< subsystem >>
Billing
{version = 3.2.1
status = checkedln}
{version = 3.2
status = checkedout}
<< subsystem >>
WorldCurrency
{version = 7.5
status = checkedln}
Kwangju University
UML 사용자 지침서
69
보편적 모델링 기법(계속)
새로운 의미 Modeling
UML의 목적은 이해를 쉽게 할 수 있으며 의사 소통을 원할 하도록 하는 것이
므로 새로운 부분을 표현해야 할 필요가 있을 경우에는 제약을 사용
새로운 의미 모델링 방법
기본적인 표현으로 표현 불가능하다는 것을 확인
사용할 표현 방법이 없을 경우 의미를 제약으로 작성하고 관련 있는 요소 들을 가까이
둠
의미를 보다 정확히, 공식적으로 표현하려면 새로운 의미를 OCL(Object Constraint
Language)을 이용하여 기술
Department
*
*
{subset}
member
1 .. *
1
manager
Person
Kwangju University
UML 사용자 지침서
70
힌트와 조언
Model에 Note를 사용하여 장식하려면
기존 UML 특성으로는 표현할 수 없을 때 요구 사항, 관찰 기록, 검토 의견, 설
명 등을 표현
Note는 단지 참조로 사용하며 진행중인 일의 진척 사항을 추적하는데 사용
Note를 도해 할 때
장문의 주석은 전체 주석을 담고 있는 문서를 연결하거나 내장하는 장소로 Note
를 활용
Stereotype, Tagged Value, Constraint를 사용하여 Model을 확장하려면
몇 개의 표준화 만을 설정하여 Project에 활용
짧고, 의미 있는 명칭 사용
정확성이 중요하게 요구되는 부분이면 OCL을 사용하여 제약 표현식으로 나타내
고 그렇지 않으면 자유로운 형상의 문장 사용
Stereotype, Tagged Value, Constraint를 도해하려면
Graphic Stereotype은 자제
Graphic Stereotype은 단순한 표현, 색 또는 그림자를 활용하고 복잡한 것은
Icon을 사용
Kwangju University
UML 사용자 지침서
71
7장. 도해(Diagrams)
시작하기
용어와 개념
보편적 모델링 기법
시스템의 다양한 뷰 모델링
다양한 추상화 계층 모델링
복잡한 뷰 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
72
시작하기
도해 (Diagram)
구성 요소들의 집합(사물들과 그 관계)을 Graphic으로 표현한 것
S/W 분야의 Architecture를 가시화, 명세화, 구축, 문서화하는 뷰
쓰임새 뷰, 설계 뷰, 프로세스 뷰, 구현 뷰, 배치 뷰
뷰 모델링
구조적 모델링 : 정적인 사물 모델링
행동적 모델링 : 동적인 사물 모델링
UML 도해 방식
순 공학(Forward Engineering) 방법 : 모델을 먼저 작성하고 실행 시스템을 구현
역 공학(Reverse Engineering) 방법 : 실행 시스템으로부터 모델을 재 구축
Kwangju University
UML 사용자 지침서
73
용어와 개념
System과 Sub System
특정 목적을 수행하기 위하여 구성된 Sub System들로 이루어지며 다양한
시각에서 바라본 Model들의 집합으로 표현
구성 요소들의 모임으로서 요소의 일부는 다른 요소들에게 제공할 행동에 대
한 명세를 구성
Architecture 관점에서 View는 System Model에 대한 조직과 구조를 투영
한 것으로 도해는 요소들의 집합을 Graphic으로 표현한 것
System의 정적인 부분 도해 Model
클래스도(Class Diagram)
객체도(Object Diagram)
컴포넌트도(Component Diagram)
배치도(Deployment Diagram)
System의 동적인 부분 도해 Model
쓰임새도(Use Case Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(State chart Diagram)
활동도(Activity Diagram)
Kwangju University
UML 사용자 지침서
74
보편적 모델링 기법
System의 다양한 View Modeling
System의 Architecture를 표현하고 Project의 기술적인 위험을 표현하기에
가장 좋은 View를 결정
각 View의 필수적인 상세를 파악하기위해 만들어야 할 산출물을 결정
Project 계획 시 각 View에 대해 어떤 도해를 어느 정도 형식적 제어하에 둘
것인가를 결정
몇 가지 도해는 중도에 폐기 할 수 있다는 여유를 갖고 모형화
단순 일체형의 Application Modeling
복잡한 분산 System Modeling
쓰임새 뷰
쓰임새도
쓰임새 뷰
쓰임새도, 활동도
설계 뷰
클래스도, 교류도
설계 뷰
클래스도, 교류도, 상태도
프로세스 뷰
불 필요
프로세스 뷰
클래스도, 교류도
구현 뷰
불 필요
구현 뷰
컴포넌트도
배치 뷰
불 필요
배치 뷰
배치도
Kwangju University
UML 사용자 지침서
75
보편적 모델링 기법(계속)
다양한 추상화 Hierarchical Modeling
추상화 계층을 달리하여 시스템을 표현할 필요가 있을 때 활용
추상화 계층 종류
같은 Model에 대하여 상세한 정도를 달리하는 방법
초기부터 추상화 계층을 달리하여 Model을 작성 그러나 한 Model에서 다른 Model
로 추적이 가능하도록 하는 방법
추상화 계층 Modeling 방법
요구 사항을 고려하면서 제시된 모델로 시작
모형을 필요로 하는 사용자(최종 사용자, 분석/설계자) 수준에 맞는 계층을 설정
추상화 수준 결정에 따라 각 사물들을 모델에 표현
구성 요소와 관계 : 도해 목적과 요구에 부합되지 않는 것은 Hide
장식 : 도해를 이해하는데 필수적 구성 요소와 관계에 관한 장식만 표현
흐름 : 행동적 도해의 경우 의도를 이해하는데 필수적인 Message나 Transit만 확장
스테레오 타입 : 속성이나 Operation과 같은 것에 대해 도해의 의도를 이해하는데 필
수적인 스테레오 타입 항목만 표현
Kwangju University
UML 사용자 지침서
76
보편적 모델링 기법(계속)
다양한 추상화 계층 Modeling 방법
요구 사항을 고려하여 각자가 원하는 추상화 계층을 결정하고 각 계층에 맞게 별도
Model 작성
상위 계층의 추상화 Model에는 단순한 추상화 개념들로 구성, 하위 계층 추상화
Model에는 상세한 추상화 개념 포함
다섯 가지 View 준수 시 4 가지 고려 사항
Use Case와 구현 : 쓰임새 모델의 쓰임새는 설계 모델의 협력으로 추적
Collaboration 과 구현 : 협력을 수행하기 위해 함께 협력하는 Class의 모임으로 추
적
Component와 설계 : 구현 모델의 Component들은 설계 모델의 요소 들로 추적
Node와 Component : 배치 모델의 Node들은 구현 모델의 Component 들로 추적
상위 추상화 계층도의 교류
: OrderTaker
: OrdeFulfillment
submitOrder
placeOrder
acknowledgeOrder
Kwangju University
UML 사용자 지침서
77
보편적 모델링 기법(계속)
하위 추상화 계층의 교류도
: OrderTaker
: CreditCardAgent : OrderFulfillment
: BillingAgent
submitOrder
processCard
placeOrder
triggerBill
acknowledgeOrder
See Credit Failure
for a variation of this
scenario
Kwangju University
UML 사용자 지침서
78
보편적 모델링 기법(계속)
복잡한 View Modeling
대단히 크고 복잡한 도해를 작성할 때 공통 Pattern을 파악하여 상위 계층의
협력으로 도해
복잡한 View Modeling 방법
도해의 일부를 감추고 다른 부분을 상세하게 드러내는 방식으로 상위 추상화 계층
에서 이러한 정보를 표현할 방법이 없다는 것을 확인
충분히 감추어 표현하였는데도 도해가 복잡하다면 요소들을 Package로 묶거나 상
위 계층의 협력으로 묶는 것을 고려
도해가 복잡하다면 Note나 색깔을 이용하여 강조 부분을 부각 시킴
전체 도해를 확인하며 공동 Pattern을 연구
Kwangju University
UML 사용자 지침서
79
힌트와 조언
도해를 만들 때
도해의 목적은 시스템의 가시화, 명세화, 구축, 문서화 임
도해의 전부를 유지하는 것이 아니라 시스템이 만들어질 떄 활용되고 용도를 마친 도해
는 폐기
불 필요하거나 중복된 도해는 작성하지 않음
각 도해가 의도하는 문제를 다루기에 충분하도록 상세하게 표현
원하는 것이 상위의 추상화 계층이 아니라면 도해를 최소한으로 만들지 말아야
구조적 도해와 행동적 도해가 균형을 유지하도록
너무 크거나 적지 않은 범위에서 표현
각 도해에 의미 있는 명칭을 붙이고 의도를 명확하게 표현
형식에 집착하지 않고 작성
구조가 좋은 도해
시스템에서 하나의 View를 전달하는데 초점을 맞춤
관점을 이해하는데 필수적인 요소만 표현
추상적 계층에 맞는 상세한 정보를 제공
중요한 의미를 사용자에게 정확히 전달될 정도로 복잡하게 구현
Kwangju University
UML 사용자 지침서
80
8장. 클래스도(Class Diagram)
시작하기
용어와 개념
보편적 모델링 기법
단순 협력 모델링
논리 데이타베이스 스키마 모델링
순 공학과 역 공학
힌트와 조언
Kwangju University
UML 사용자 지침서
81
시작하기
Class Diagram
Class, Interface, collaboration, Relation을 이용하여 시스템의 정적인 관
점들을 가시화하고 구축을 위한 자세한 내용을 명세화
System 어휘와 협력, Schema를 Modeling하는 것이 대부분
Company
클래스
*
0..1
제약
1..*
Department
name : Name
*
member 1..*
역할
속성
Operation
*
{subset}
1
집합 연관
다중성
1..*
Office
address : String
* voice : Number
Location
*
연관
Kwangju University
Interface
일반화
ISecureInformation
1 manager
Person
name : Name
employeeID : Integer
title : String
getPhoto (p : Photo)
getSoundByte ( )
getContactInformation ( )
getPersonalRecords ( )
클래스 명
Headquaters
의존
ContactInformation
address : String
UML 사용자 지침서
PersonalRecord
taxID
employmentHistory
salary
82
용어와 개념
공통 Property
Class Diagram은 특별 도해의 하나이지만 다른 모든 Diagram 들과 공통적
인 Property가 존재
내용
Class
Interface
Collaboration
Relationship(Dependency, Generalization, Association)
공통 사용
Class Diagram의 정적인 설계 View 작성 방식
System 어휘 Modeling : 시스템화 대상의 추상 개념을 도출하여 추상 개념들 사이
의 관계를 명세화
단순 협력 Modeling : 서로 협동적인 행동을 제공하기 위하여 함께 작용하는 Class,
Interface, 다른 요소들과의 관계를 가시화하고 명세화
논리 Database Schema Modeling : 시스템 구현 Database Schema를 Modeling
하기위한 설계의 청사진을 제시
Kwangju University
UML 사용자 지침서
83
보편적 모델링 기법
단순 협력 모델링
존재하는 Class 들 간의 협력 관계를 명세화
협력 Modeling 방법
Modeling 대상 Mechanism(System 일부의 기능/행동)을 파악
각 Mechanism에 협력을 하는 Class, Interface 등 다른 협력 관계 파악
사물을 검토하기 위하여 Scenario를 활용
필요 요소들을 채움 : 균형 잡힌 책임 할당, 구체적인 속성, Operation 추가
PathAgent
1
*
Responsibilities
1
-- seek path
-- avoid obstacles
1
CollisionSensor
Driver
Motor
1
MainMotor
1
SteetingMotor
Kwangju University
UML 사용자 지침서
move (d:Direction; s:Speed)
stop ( )
resetCounter ( )
Status status ( )
Integer distance ( )
84
보편적 모델링 기법(계속)
논리 Database Schema Modeling
Modeling의 결과로 생성해야 할 Database 구조를 설계
자료 표현에만 초점을 두는 ERD에 비교하여 행동 모형을 포함하는 상위 집합
물리 Database에 있어서 논리 Operation은 Trigger나 Stored Procedure로 구
현
Schema Modeling 방법
사용된 Class 중에서 단순 Application으로 끝나는 것이 아닌 것을 파악
파악된 대상을 포함하여 Class Diagram을 작성하고 꼬리표를 붙여 표시
구조적 상세 내용(속성)을 확정하며 연관 관계 파악
물리적 Database 설계를 복잡하게 하는 공통 Pattern 파악(순화 연관, 다수 연관 …)
무결성 유지를 위한 Operation을 확장하여 Class의 행동으로 고려
가능하면 CASE Tool을 이용하여 논리 설계를 물리 설계로 변환
Kwangju University
UML 사용자 지침서
85
보편적 모델링 기법(계속)
School
{persistent}
name : Name
address : String
phone : Number
addStudent ( )
removeStudent ( )
getStudent ( )
getAllStudent ( )
addDepartment ( )
removeDepartment ( )
getDepartment ( )
getAllDepartment ( )
Department
Has
1
{persistence}
1..*
name : Name
0 .. 1
addInstructor ( )
removeInstructor ( )
getInstructor ( )
getAllInstructor ( )
1..*
1..*
AssignedTo
1..*
Member
1..*
*
Student
{persistence}
name : Name
studentID : Number *
Kwangju University
1..*
Course
Attends
Instructor
{persistence}
name : Name
* courseID : Number
UML 사용자 지침서
Chairperson
0 .. 1
Teaches
*
1..*
{persistence}
name : Name
86
보편적 모델링 기법(계속)
순 공학과 역 공학
순 공학 (Forward Engineering)
Model을 대응 언어에 대응시켜 Code로 옮기는 절차
순 공학 방법
구현 언어나 선택 언어에 대응 시키는 규칙 파악
선택 언어의 의미에 따라 UML 특성들을 제한적으로 사용
꼬리표 값을 사용하여 구현 언어를 지정
도구의 활용
Client
{Java}
successor
EventHandler
currentEventID : Integer
source : String
handleRequest ( ) : void
GUIEventHandler
{Java}
Kwangju University
순 공학 구현 Code
{Java}
Public abstract class EventHandler {
EventHandler successor ;
private Integer currentEventID ;
private String source;
}
UML 사용자 지침서
EventHandler ( ) { }
public void handleRequest ( ) { }
87
보편적 모델링 기법(계속)
역 공학 (Reverse Engineering)
특정 구현 언어를 대응시켜 Code에서 Model로 옮기는 절차
역 공학 방법
구현 언어 또는 선택 언어로부터 대응 시키는 규칙 파악
도구를 활용하여 역 공학 부분 Code를 선택
도구를 활용하여 Model을 질의함으로써 Class Diagram을 작성
Kwangju University
UML 사용자 지침서
88
힌트와 조언
구조가 좋은 Class Diagram
System의 정적 설계 View의 한 관점을 전달하는데 초점
해당 관점을 이해하는데 필수적인 요소들만 표현
추상화 계층에 알맞은 정도의 상세 내용을 제공하고 이해하는데 필수적인 장
식만을 사용
중요한 의미를 이해할 수 있을 정도로 복잡하게
Class Diagram 작성 규칙
목적에 맞는 명칭 사용
서로 교차하는 선(관계 표현)을 최소화 하도록 배치
의미적으로 관련 있는 Class들을 가까운 위치에 배치
시각적 암시를 활용 (Note 또는 색깔)
너무 많은 관계를 나타내지 않도록 도해
Kwangju University
UML 사용자 지침서
89
Kwangju University
UML 사용자 지침서
90
단원 3. 응용 구조 모델링
9장. 응용 클래스
10장. 응용 관계
11장. 인터페이스, 타입, 역할
12장. 패키지
13장. 인스턴스
14장. 객체도
Kwangju University
UML 사용자 지침서
91
9장. 응용 클래스(Advanced Classes)
시작하기
용어와 개념
보편적 모델링 기법
클래스 의미 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
92
시작하기
다양한 종류의 클래스
클래스는 일반적인 구성 요소인 분류자(Classifier)의 한 종류
분류자(Class)는 속성(Class 구조)과 Operation(Class 행동)이라는 Property
외에 다른 응용 특성들을 갖고 다중성(Multiplicity), 가시성(Visibility), 용법
(Signature), 다형성(Polymorphism) 및 다른 특성들을 모형화
Class 범위
추상 개념
Type
Frame
Public (공용)
Protected (보호)
Private (전용)
Kwangju University
header : FrameHeader
uniqueID : Long
+ addMessage(m : Message) : Status
# setCheckSum( )
- encrypt ( )
Signature (용법)
UML 사용자 지침서
93
용어와 개념
분류자 (Classifier)
구조적/행동적 특성을 설명하기 위한 Mechanism
모형화 할 때 추상 개념의 의미를 파악하기 위해 필요한 상세 수준을 제공할
목적으로 사용
분류자 종류
Class : 동일한 속성, Operation, Relationship, 의미를 공유하는 객체들의 집합
Interface : Class나 Component의 Service를 명세화 하기 위해 사용하는
Operation 집합
Datatype : 정체성을 갖지 않는 값들의 형식 (Number, Character, Boolean, …)
Signal : Instance 사이의 비 동기 자극 통신
Component : System에서 물리적으로 교체 가능한 부품 (Interface를 준수하고
실현)
Node : 실행시의 물리적 요소로써 처리 능력과 다소의 Memory 능력을 갖는 전산
자원
Use Case : System이 실행하는 일련의 행동에 대한 설명 (변이를 포함)
Subsystem : 요소들의 집합으로써 다른 요소들이 제공하는 행동 명세를 구성
Kwangju University
UML 사용자 지침서
94
용어와 개념(계속)
Class
Interface
Datatype
IUnknown
<< type >>
int
{values range from
-2**31-1 to +2**31
Shape
origin
move( )
resize( )
display( )
Component
kernel32.dll
Kwangju University
Node
egb_server
Use Case
Process loan
UML 사용자 지침서
Signal
<< Signal >>
OffHook
Subsystem
<<subsystem>>
Customer Service
subsystem
95
용어와 개념(계속)
가시성 (Visibility)
해당 속성, Operation이 다른 분류자에 의해 사용될 수 있는가의 여부를 지정
가시성 종류
Public (공용) : 모든 외부 분류자들이 사용 (+)
Protected (보호) : 모든 자식들이 사용 (#)
Private (전용) : 자신만이 사용 (-)
Toolbar
Public
Private
Kwangju University
# currentSelection : Tool
# toolCount : Integer
+ pickItem(i : Integer)
+ addTool(t : Tool)
+ removeTool(i : Integer)
+ getTool( ) : Tool
# checkOrphans( )
- compact( )
UML 사용자 지침서
Protection
96
용어와 개념(계속)
범위 (Scope)
해당 특성이 분류자의 모든 Instance에 나타나는지 또는 분류자의 모든
Instance에 대해서 하나의 특성 Instance만 존재하는가를 지정
대부분의 분류자 특성은 Instance 소유자 범위이며 Classifier 범위는 해당
분류자에 속하는 일부 Instance들이 공유해야 하는 Private 속성에 흔히 사
용
Frame
Class Scope
Kwangju University
header : FrameHeader
uniqueID : Long
UML 사용자 지침서
Instance Scope
97
용어와 개념(계속)
추상, 뿌리, 잎, 그리고 다형적 요소
(Abstract, Root, Leaf, and Polymorphic Elements)
일반화 관계를 이용하여 Class 계층을 모형화
특수한 것 보다는 일반화된 추상 개념을 상위에 표현
추상 Class
Icon
{root}
origin : Point
display( )
getID( ) : integer{leaf}
기본 Class
추상 Operation
추상 Class
RectangularIcon
height : Integer
width : Integer
구체 Operation
ArbitraryIcon
edge : LineCollection
isInside(p : Point) : Boolean
구체 Class
다형적 Operation
Button
display( )
Kwangju University
OKButton
{leaf}
잎 Class
display(
UML) 사용자 지침서
98
용어와 개념(계속)
다중성 (Multiplicity)
하나의 Class가 갖을 수 있는 다수의 Instance 수
독자 Class
NetworkController 1
consolePort [2..*] : Port
ControlRod 3
다중성
Kwangju University
UML 사용자 지침서
99
용어와 개념(계속)
속성 (Attribute)
가장 높은 추상화 수준에서 Class의 구조적 특성인 속성을 표현할 때는 명칭만
을 기술
속성에도 가시성, 범위, 다중성, 타입, 초기값, 변경 가능성 등을 지정 가능
속성을 기술하는 UML의 완전한 문장
[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}
명칭
가시성, 명칭
명칭, Type
명칭, 복잡한 Type
명칭, 다중성, Type
명칭, Type, 초기값
명칭, Property
속성 정의 Property
changeable(변경) : 속성값 바꾸는 제약 없음
addOnly(추가) : 하나 이상의 다중성을 가진 속성에 추가만 가능
frozen(동결) : 객체가 초기화된 이후 속성값을 바꿀 수 없음
Kwangju University
UML 사용자 지침서
100
용어와 개념(계속)
오퍼레이션 (Operation)
가장 높은 추상화 수준에서는 Operation 명칭만을 기술하지만 여기에 Parameter,
Return Type, 동시성 그리고 Operation Property를 지정 - Operation의
Signature
Operation을 기술하는 UML의 완전한 문장
[visibility] name [(parameter-list)] [:return type] [{property-string}]
Operation 선언 예제
display
+ display
set (n : Name, s:String)
getID ( ) : Integer
restart ( ) {guarded}
Parameter 제공 구문
명칭
가시성, 명칭
명칭, Parameter
명칭, Return Type
명칭, Property
[direction] name : type [ =default-value]
Operation 적용 Property
isQuery (질의) : Operation 실행 후 System 상태 변화 없음
sequential (순차) : 객체 외부에서 서로 협조하여 객체 안에 한번에 하나의 흐름만 존재
guarded (보호) : Operation에 대한 모든 호출을 순차적으로 관리(의미, 무결성 보장)
concurrent (동시) : 여러 제어흐름이 존재해도 각 Operation을 원자적으로 처리
(의미, 무결성 보장)
Kwangju University
UML 사용자 지침서
101
용어와 개념(계속)
템플릿 클래스 (Template Class)
Template : Parameter로 된 요소
일반 Class와 마찬가지로 사용할 수 있는 구체 Class로써 직접 사용할 수는 없
고 객체화(형식 Parameter를 실 Parameter로 Binding) 시켜야 함
예제 - Map 이라는 Parameter Class를 선언하는 C++ Code
template <class Item, class Value, int Buckets>
class Map {
public :
virtual Boolean bind (const Item&, const Value&) ;
virtual Boolean isBound (const Item&) const ;
. . .
} ;
]
위 Template을 이용한 Customer 객체의 Order 객체 대응
m : Map <Customer, Order, 3> ;
Kwangju University
UML 사용자 지침서
102
용어와 개념(계속)
Template Parameter
Template Class
Map
Item
Value
Buckets : int
+ bind(in i : Item; in v : Value) : Boolean
+ isBound(in i : Item) : Boolean {isQuery}
<<bind>> (Customer, Order, 3)
명시적 결합
묵시적 결합
OrderMap
Map<Customer, Order, 3>
Kwangju University
UML 사용자 지침서
103
용어와 개념(계속)
표준 요소
꼬리표 값을 사용하여 Class Property를 확장하고 새로운 Component를 지정
하기 위해 Stereotype을 활용
4 가지 표준 Stereotype
metaclass : 객체가 모두 Class인 분류자
powertype : 객체가 모두 주어진 Parent의 Child인 분류자
stereotype : 분류자가 stereotype이며 다른 요소에 적용
utility : 속성과 Operation이 모두 Class 범위를 갖는 Class
Kwangju University
UML 사용자 지침서
104
보편적 모델링 기법
Class 의미 모델링
추상 개념을 파악하고 그들이 갖는 의미를 명세화 하는 것
Class 의미를 모형화 하기 위하여는 비 정형인 것부터 정형적인 것 까지 명세화
Class의 책임을 기술
Class 의미를 구조화된 문장으로 표현하고 Semantic으로 Stereotype화 하여 Note에
표현
Method의 몸체를 구조화된 문장이나 Programming 언어로 기술하여 Note레 표현하고
의존 관계를 사용하여 Operation에 첨부
Operation 선행/종료 조건을 기술하고 구조화된 문장으로 Class 전체 불변 값 기술
Class 상태 Machine을 기술
Class를 대표하는 협력을 기술
각 Operation의 선행/종료 조건을 기술하고 OCL 등의 정형적 언어를 사용하여 Class
의 전체적 불변 값 기술
Kwangju University
UML 사용자 지침서
105
힌트와 조언
좋은 구조의 분류자
구조적인 동시에 행동적인 관점을 포함
응집도는 강하고 결합도는 약하게
Class 사용자에게 꼭 필요한 특성만 나타나도록
의도와 의미가 명확하게
과도하게 기술하여 구현의 자유를 배제하지 않도록
부족하게 기술하여 분류자의 의미가 모호하지 않게
UML에서 분류자 도해 방법
문맥에서 추상 개념을 이해하기 위해 필요한 분류자의 Property만 나타냄
분류자의 의도를 가장 잘 표현하는 시각적 효과를 제공하는 Stereotype
Version을 선택
Kwangju University
UML 사용자 지침서
106
10장. 응용 관계(Advanced Relationship)
시작하기
용어와 개념
보편적 모델링 기법
복잡한 관계 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
107
시작하기
응용 관계 (Advanced Relationship)
사물들 사이의 연결 표현 (관계 설명의 3 가지 구성 요소)
의존(Dependency)
일반화(Generalization)
연관(Association)
Interface와 Class, Component 그리고 Use Case와 Collaboration 간의 연
결 관계 Modeling 표현 (관계 설명의 4번째 구성 요소)
현실화(Realization)
다중 상속
Controller
연관 운항
<<interface>>
URLStreamHandler
openConnection( )
parseURL( )
setURL( )
toExternalForm( )
Kwangju University
EmbeddedAgent
현실화
SetTopController
authorizatioLevel
startUp( )
<<friend>>
shutDown( )
connect( )
PowerManager
Channellterator
Stereotype 의존
UML 사용자 지침서
108
용어와 개념
의존 (Dependency)
Class와 Object들 사이의 의존 관계에 적용할 Stereotype
bind(결합) : 실 Parameter를 이용하여 Source가 Target Template을 Object화
하는 것
derive(파생) : 대상으로부터 Source를 계산 가능
friend : Source는 대상에 대하여 특별한 가시성을 갖음
instanceOf : Source Object가 대상 분류자인 Instance
instantiate : Source가 대상 Object를 생성
powertype : Object들 모두가 특정 Parent의 분류자
refine(정제) : Source가 대상보다도 추상화 정도가 더 세밀
use(사용) : Source요소의 의미가 공용 부분이 갖는 의미에 의존
Package 사이의 의존 관계에 적용할 Stereotype
Access(접근) : Source Package는 대상 Package 요소들에 대해 참조 권한을 갖음
Import (수입) : 대상 Package의 공용 내용들이 Source 내에 정의된 것과 같이 참
조 권한을 갖음
Use Case 사이의 의존 관계에 적용할 Stereotype
extend(확장) : 대상 Use Case가 Source Use Case의 행동을 확장
include(포함) : Used : Source Use Case가 명시적으로 다른 Use Case의 행동을
Source가 지정하는 위치에 포함
Kwangju University
UML 사용자 지침서
109
용어와 개념(계속)
Object 간 교류 Modeling을 위한 Stereotype
become(변화) : 대상 Object가 Source와 같으나 일정 시간 경과 후 다른 값, 상
태, 역할을 갖음
call(호출) : Source Operation이 대상 Operation을 호출
copy(복사) : 대상 Object가 똑 같으나 독립적인 복사본임을 표현
상태 Machine 문맥에서 사용하는 Stereotype
send(전송) : Source Operation이 대상 사건을 전송하는 것
System 요소들을 조직화하여 Sub System과 Model로 만드는 문맥에서 사
용하는 Stereotype
Trace(추적) : 대상이 Source의 과거에는 상위 임
Kwangju University
UML 사용자 지침서
110
용어와 개념(계속)
일반화 (Generalization)
일반적인 사물(Parent, Super-Class)과 이것의 특수화된 사물(Child, SubClass) 사이에 맺어지는 관계
상속 (inheritance) : Super-Class의 구조와 행동을 물려 받는 것
단일 상속 : 하나의 Parent Class로부터 상속
다중 상속 : 두개 이상의 Parent Class로부터 상속
InterestBearingItem
InsurableItem
Asset
다중 상속
BankAccount
CheckingAccount
Kwangju University
다중 상속
단일 상속
RealEstate
SavingAccount
UML 사용자 지침서
Security
Stock
Bond
111
용어와 개념(계속)
일반화 관계의 Stereotype
Implementation(구현) : Child가 Parent의 구현을 상속하지만 이를 공용으로 지정
하지 않고 Interface를 지원하지 않아 대체 가능성을 위반
일반화 관계의 제약사항
Complete(완전) : Parent의 모든 Child가 Model에 지정되어 더 이상 Child가 추가
될 수 없음
Incomplete(불완전) : Parent의 모든 Child가 Model에 지정되지 않아 Child가 더
추가 될 수 있음
Disjoint(배타적) : Parent Object가 한 가지 Child Type만 포함
Overlapping(겹침) : Parent Object가 한 가지 이상의 Child Type을 포함
Kwangju University
UML 사용자 지침서
112
용어와 개념(계속)
연관 (Association)
한 사물의 Object들이 다른 사물의 Object들과 맺어지는 관계
운항(Navigation) : 하나의 객체에서 다른 객체로의 연결 표현
User
1
연관 운항
*
Owner
Password
연관
가시성(Visibility) : 연관의 외부 객체에 해당 연관의 가시성을 제한할 때 사
용
연관
UserGroup
*
*
User
+ User
1
*
+ Owner - Key
Password
연관 운항
수식(Qualification) : 연관의 한쪽 객체에서 다른 쪽의 객체(객체 집합)를 찾
는 수식자 표현
수식자
WorkDeskjobID : Int
Kwangju University
*
0 .. 1
연관
UML 사용자 지침서
Password
113
용어와 개념(계속)
인터페이스 지정자(Interface Specifier) : Class에 의해 구현되는
Interface는 해당 Class의 행동에 대한 완전한 명세서이나 연관 문맥에서
Source Class의 일부만 표현
연관
worker : IEmployee *
1
Person
supervisor : IManager
Interface 지정자
복합 연관(Composition) : 일종의 집합 연관으로써 전체 쪽에서 강력한 소유
권을 갖고 다른 부분들은 전체와 동시에 생성되고 소멸
복합 연관
전체
Kwangju University
Window
1
*
Frame
UML 사용자 지침서
부분
114
용어와 개념(계속)
연관(Association) Class : 두 Class의 연관에서 연관 자체가 Property를 포함
Company
*
1 .. *
employer
employee
Job
description
dateHired
salary
Person
연관 Class
제약(Constraint) : 의미상 더 상세한 표현을 필요로 할 때 연관 관계에 적용하
는 제약
implicit(암시) : 관계가 실제적이 아닌 개념적 관계
ordered(정렬) : 객체 집합이 명백한 순서를 갖음
changeable(변경) : 객체 연결 Link가 추가, 삭제, 변경이 가능
addOnly(추가만) : 연관의 반대쪽 객체로부터 새로운 Link 연결 가능
frozen(동결) : 연관의 반대쪽 객체로부터 Link가 한번 연결도면 수정, 삭제 불가능
Kwangju University
UML 사용자 지침서
115
용어와 개념(계속)
현실화 (Realization)
분류자들 사이의 의미적 관계로써 한 분류자가 다른 분류자의 수행해야 할
계약을 지정
현실화는 Interface와 Collaboration에서 사용
Interface와 이에 대한 Operation이나 Service를 제공하는 Class나
Component 사이의 관계를 지정하기 위해 사용
<<interface>>
IRuleAgent
addRule( )
changeRule( )
explainAction( )
IRuleAgent
정규형
생략형
현실화
Validate
user
Kwangju University
Acctrule.dll
AccountBusinessRules
Validation
UML 사용자 지침서
116
보편적 모델링 기법
복잡한 관계 모델링
추상 개념들 각각의 명확한 경계를 설정한다는 것은 어려운 일이며 이들의
보다 복잡한 관계들을 설정한다는 것은 더욱 어려운 작업임(응집도는 높고
결합도는 낮게)
복잡한 관계 Modeling
추상 개념들 사이의 관계를 발견하려 노력
구조적 관계들을 Modeling하면서 시작
일반화/특수화 관계를 파악하며 다중 상속은 적게 사용
앞 단계들의 의존 관계를 확인
고급 특성을 적용 시 의도를 표현해야 할 절대적 요구가 있을 때 표현
하나의 도해나 뷰 보다는 시스템 관계들을 서로 다른 뷰 들로 분산시켜 표현
Kwangju University
UML 사용자 지침서
117
힌트와 조언
구조가 좋은 관계
Client가 관계를 사용하는데 필요한 특성만을 나타냄
의미와 의도가 모호하지 않게 표현
과도하게 지정하여 구현의 자유를 제약하지 않도록
부족하게 지정하여 관계의 의미가 모호하지 않게
관계 도해
문맥에서 추상 개념을 이해하기에 필요한 관계의 Property만 표현
관계 의도를 잘 표현하는 시각적 암시를 제공하는 Stereotype을 이용
Kwangju University
UML 사용자 지침서
118
11장. 인터페이스, 타입, 역할
시작하기
용어와 개념
보편적 모델링 기법
시스템 이음매 모델링
정적 타입과 동적 타입 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
119
시작하기
인터페이스 (Interface)
System 내의 이음매를 가시화, 명세화, 구축, 문서화하기 위하여 사용
Operation들의 모임
하나의 Class나 Component들이 제공하는 Service를 명세화 하기 위해 사용
타입 (Type) 과 역할 (Role)
특정한 문맥에서 Interface에 대한 추상 개념의 정적/동적 일치 여부를
Modeling 할 수 있도록 하는 Mechanism을 제공
Type은 Class의 Stereotype의로써 Operation들과 함께 객체의 영역을 지정
하기 위해 사용
Role은 특정 문맥에 포함되어 있는 실체 행동을 표현
IThesaurus
Interface
ISpelling
wordsmith.dll
Component
IUnknown
Kwangju University
UML 사용자 지침서
120
용어와 개념
명칭 (Name)
다른 Interface와 구분하기 위한 고유의 문자열을 갖음
단순 명(Simple Name)과 경로 명(Path Name)
IUnknown
ISpelling
ISensor
단순 명
Networking::IRoute
Isensors::ITarget 경로 명
오퍼레이션 (Operation)
Interface는 Class나 Component의 Service를 명세화 하기 위하여 사용하는
Operation들의 모임에 명칭을 붙이는 것
Operation들은 가시성 Property, Stereotype, 꼬리표 값, 제약 등으로 장
식
<<interface>>
Stereotype
URLStreamHandler
openConnection( )
parseURL( )
setURL( )
toExternalForm( )
Kwangju University
UML 사용자 지침서
Operation
121
용어와 개념(계속)
관계 (Relationship)
Class와 마찬가지로 일반화, 의존, 연관 관계가 있음
실체화 관계에도 참여하며 두 분류자 사이의 의미적 관계로 대상 분류자가
책임지고 수행 해야 할 계약을 지정
하나의 Interface는 하나의 계약을 명세화하고 의무를 준수하는 범위에서 독
자적 변경 가능
TargetTracker
Tracker
Observer
현실화(단순형)
Java::Util::Observable
의존
Interface
Target
id
currentPosition
setPosition( )
setVelocity( )
expectedPosition( )
Kwangju University
<<interface>>
Observer
TargetTracker
update( )
현실화(확장형)
UML 사용자 지침서
122
용어와 개념(계속)
Interface 이해하기
각 Operation에 대한 선행 / 종료 조건, 그리고 Class나 Component에 대한 전
체적인 불변 값 명시
State Machine을 이용하여 Interface의 Operation 들에 대한 순서를 명세화
Collaboration Diagram을 활용하여 협력을 표현 함으로써 Interface가 제공할
행동을 명세화
Type 과 Role
Type : Class의 Stereotype으로써 Object 들의 영역을 명세화 하기 위하여
사용
Role : 특정 문맥에 참여하는 실체의 행동에 명칭을 붙인 것
Interface
<<interface>>
Employee
Person
getEmploymentHistory( )
getCompensation( )
getBenefits( )
연관
1 .. *
*
Company
e : Employee
Class
Kwangju University
UML 사용자 지침서
123
보편적 모델링 기법
시스템 이음매 모델링 (System Seams Modeling)
System의 이음매를 파악하는 것은 Architecture의 명확한 경계선을 파악하
는 것을 포함하여 경계선의 양쪽에 독립적으로 상대편에 영향을 미치지 않으
며 변경 가능한 Component 들을 파악하는 것
System의 이음매 Modeling 방법
Class와 Component들의 집단에서 다른 Class 또는 Component와 밀접하게 결합되
는 경향이 있는 것들의 주위를 선으로 둘러쌈
변경에 대한 영향을 고려하며 함께 변경될 수 있는 Class와 Component들을 협력으
로 표현
경계를 통해 전달되는 Operation이나 Signal을 고려하여 표현
논리적으로 연결된 Operation아나 Signal들을 Interface로 묶음
System 내의 협력들에 대하여 의존 Interface(Import)와 제공 Interface(Export)
를 파악
각 Interface에 대해 동적 활동을 문서화하되 Operation들의 선행/종료 조건과 쓰
임새와 상태 Machine을 문서화
Kwangju University
UML 사용자 지침서
124
보편적 모델링 기법(계속)
<<interface>>
Itransaction
QueryInterface( ) : HRERULT
AddRef( ) : ULONG
Release( ) : ULONG
<<interface>>
Itransaction
ILedger
IReports
Kwangju University
ledger.dll
IStreaming
UML 사용자 지침서
start( )
performAction( )
commit( )
rollback( )
Exeptions
failure
125
보편적 모델링 기법(계속)
정적 (Static) Type / 동적 (Dynamic) Type Modeling
Object의 정적 성질 Modeling은 Class Diagram으로 가시화하지만
Workflow를 거치며 역할을 바꾸는 Business Object와 같은 사물은 명시적으
로 Object Type의 동적 성질을 Modeling하는 것이 유용할 수 있음
Dynamic Type Modeling
추상 개념의 구조와 행동을 필요로 한다면 객체의 서로 다른 형태를 Type
Stereotype을 이용하여 Class로 지정
추상 개념이 행동만을 요구한다면 Interface로 지정
Object의 Class가 취할 모든 역할들을 Modeling
교류도에서 동적으로 타입을 결정하는 Class와 Instance를 표현
Object의 역할이 변하는 것을 나타내기 위해 교류 속에서 Object가 수행하는 역할
하나에 한번씩 나타내고 become Stereotype Message로 이 Object들을 연결
6 : <<become>>
<<type>>
p : Person
p : Person
<<type>>
<<type>>
Employee
[Candidate]
[Employee]
Candidate
Retiree
5 : hire( )
Person
Static Type Modeling
Kwangju University
:HRDepartment
UML 사용자 지침서
Dynamic Type Modeling
126
힌트와 조언
구조가 좋은 Interface
모든 필요한 Operation을 제공하되 하나의 Service를 명세화 하기에 충분하
고 단순하며 완전하게
Interface를 사용하고 실체화 하기에 충분한 정보를 제공할 만큼 이해하기
쉽게
사용자에게 주요 Property를 나타내는 정보를 제공하되 Operation들의 상세
한 내용이 너무 복잡하지 않고 접근이 쉽도록
Interface를 그릴 때
단순 이음매는 Class가 아닌 Component에 사용
Service 자체의 상세한 내용을 가시화 하려면 확장된 형태를 사용
Kwangju University
UML 사용자 지침서
127
12장. 패키지(Package)
시작하기
용어와 개념
보편적 모델링 기법
요소 그룹 모델링
아키텍쳐 뷰 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
128
시작하기
패키지 (Package)
Modeling의 다른 요소(Class, Interface, Component, Node, Collaboration,
Use Case, 다른 Package)들을 Group으로 조직화하는 범용 Mechanism으로
써 이해가 쉽게
요소들을 의미적으로 가깝게 모으고 함께 변화 가능하도록
Package는 매우 느슨하게 결합되고 응집도는 매우 높으며 Package 내용물에
대한 접근은 제어가 매우 엄격
명칭
Sensor fusion
Kwangju University
UML 사용자 지침서
129
용어와 개념
명칭 (Name)
다른 Package와 구분하기위한 문자열의 명칭을 갖음
Class와 마찬가지로 꼬리표 값으로 장식하거나, 상세한 내용을 표현하기 위
하여 추가 칸을 사용
포함하는 Package명
단순명
Business Rules
Package명
Client
+ OrderForm
+ TrackingForm
- Order
Sensors::Vision
{version = 2.24}
경로명
확장 Package
소유된 요소 (Owned Element)
소유는 복합 관계로써 해당 요소가 Package 안에 선언되어야 함
서로 다른 종류의 요소들이 같은 Package 내에서 같은 명칭 사용 가능
Package는 다른 Package 소유 가능
System의 구성 요소들이 시간 변화에 따른 속도가 다른 진화를 가능하도록
Package 내부의 내용을 명시적으로 문자나 그림으로 표현 가능
Kwangju University
UML 사용자 지침서
130
용어와 개념(계속)
소유된 요소 (Owned Element)
소유는 복합 관계로써 해당 요소가 Package 안에 선언되어야 함
서로 다른 종류의 요소들이 같은 Package 내에서 같은 명칭 사용 가능
Package는 다른 Package 소유 가능
System의 구성 요소들이 시간 변화에 따른 속도가 다른 진화를 가능하도록
Package 내부의 내용을 명시적으로 문자나 그림으로 표현 가능
Client
+ OrderForm
+ TrackingForm
- Order
Text 중첩
Client
+ OrderForm
+ TrackingForm
- Order
Graphic 중첩
Kwangju University
UML 사용자 지침서
131
용어와 개념(계속)
가시성 (Visibility)
Package가 소유하고 있는 요소는 공용(Public)임 : 해당 요소가 소속된
Package를 Import하고 있는 Package의 내용물들은 이 요소들을 활용할 수 있
다는 것
보호(Protected) 또는 전용(Private)으로 지정 가능하며 명칭 앞에 “#” 와 “-”
사용
수입(Import)과 수출 (Export)
서로 다른 Package에 존재하는 요소들이 각 Package에 Public으로 선언되어 있
어도 각 Package는 서로를 활용 할 수 없음
Import는 한 Package에 속한 요소들이 다른 Package의 요소들에 대해 일 방
향 접근을 허용
Export는 Package 내의 Public 부분을 지칭
Client
수출
Server
+ Database
+ LoggingService
Policies
GUI
+ Window
+ Form
# EventHandler
Kwangju University
+ OrderForm
+ TrackingForm
- Order
<<import>>
+ OrderRules
- GUI::Window
<<import>>
UML 사용자 지침서
수입
132
용어와 개념(계속)
일반화 (Generalization)
Package의 관계 종류
Import : 접근 Dependency로써 한쪽이 수출한 것을 다른 한쪽이 수출한 것을
Package 요소로 수입
Generalization : Package들의 계열(Family)을 지정하는데 사용
WindowsGUI
+ GUI::Window
+ Form
# GUI : EventHandler
+ VBForm
GUI
+ Window
+ Form
# EventHandler
MacGUI
일반화
표준 요소
꼬리표 값을 사용하여 Class Property를 확장
Package에 적용하는 Stereotype
façade(겉보기) : 다른 Package에게 View를 제공하기만 함
framework : Pattern으로 구성된 Package
stub(절단) : 다른 Package의 공용 내용물에 대한 대리자 역할을 수행
subsystem : 전체 시스템의 독립적인 일부분을 대표하는 Package
system : Modeling하려는 전체 시스템을 대표하는 Package
Kwangju University
UML 사용자 지침서
133
보편적 모델링 기법
요소 그룹 (Element Group) Modeling
Class는 문제 영역이나 해법에 존재하는 사물들을 추사화 하는 반면 Package
는 Model의 사물들을 조직화하는 Mechanism
Group Element Modeling 방법
개념적으로 또는 의미적으로 가까운 요소들의 집합을 파악
이 집합을 Package로 표현
Package에 대해 오부의 접근을 허용하는 요소 파악 (Public, Protect, Private 지
정)
외부 Package에 의존하는 Package들을 명시적으로 Import Dependency를 표현
Package가 Family를 이룰 경우 Generalization 관계 표현
User Services
<<import>>
Business Services
<<import>>
Kwangju University
UML 사용자 지침서
Data Services
134
보편적 모델링 기법(계속)
아키텍쳐 뷰 (Architecture View) Modeling
View는 System의 조직과 구조에 대한 투영이며 System의 특별한 관점에 초
점을 둔 것으로 System의 교차(orthogonal)를 Package로 분해
Architecture View Modeling 방법
문제 영역의 중요한 Architecture View 파악 : Design(설계), Process(프로세스),
Implementation(구현), Deployment(배치), Use Case (쓰임새) View 의 파악
View 의미를 가시화, 명세화, 구축, 문서화하기에 필요한 요소들을 Package에 배치
필요하다면 구성 요소들을 더 작은 Package로 구성
다른 View에 속한 요소간의 의존 관계 표현
Design View
Implementation View
Use Case View
Process View
Kwangju University
Deployment View
UML 사용자 지침서
135
힌트와 조언
구조가 좋은 Package
응집도가 높으며 관련 요소들의 경계가 명확할 것
결합도가 느슨하여 다른 Package들로부터 꼭 필요한 요소들만 Export,
Import되게
중첩도가 복잡하지 않도록
Package 크기가 적절한 크기가 되도록
Package 작성시
단순한 Package Icon 사용
Package 내용물 표현 시 문맥에서 Package 의미를 이해하는데 필요한 요소
만을 표현
형상관리 중인 사물들을 Modeling하기위한 Package인 경우 Version과 관련
꼬리표 값 표현
Kwangju University
UML 사용자 지침서
136
13장. 인스턴스(Instance)
시작하기
용어와 개념
보편적 모델링 기법
구체 인스턴스 모델링
프로토타입 인스턴스 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
137
시작하기
인스턴스 (Instance)
Instance와 Object는 같은 개념임
추상 개념의 구체적 실상이며 Operation 집합을 적용할 수 있고 Operation
효과를 저장하고 있는 상태를 포함
실 세계에 존재하는 구체적 사물이나 Prototype의 사물들을 Modeling
keystrokes : Queue
익명 Instance
Kwangju University
명칭이 있는 Instance
: Frame
UML 사용자 지침서
138
용어와 개념
추상 개념과 Instance
Instance는 혼자 존재하지 않으며 항상 추상 개념과 연결
Instance는 Object Diagram, Interaction Diagram, Activity Diagram에
포함하여 Modeling
Instance 분류자는 정적인 특성을 갖으며 추상 개념이 바뀌는 것이 가능
명칭 (Name)
다른 Instance와 구분하기 위한 명칭을 갖음
명칭 종류
단순명(Simple Name)
경로명(path Name) : 추상 개념의 명칭에 그것이 존재하는 Package 명을 덧붙인
것
명칭 포함 Instance
myCustomer
t : Transaction
익명 Instance
:Multimedia::AudioStream
Path
Kwangju University
다중 Object Instance
: keyCode
UML 사용자 지침서
단독 Instance
Agent :
139
용어와 개념(계속)
Operation
Object는 공간적 내용을 포함하여 해야 할
Object에 대한 실행 Operation들은 객체의 추상 개념 안에 선언
Operation의 상속 계층에 따른 다형적 호출 가능
상태 (State)
정적인 Property와 동적인 각 Property의 현재 값을 포함
객체의 속성들과 모든 집합체 부분들을(Aggregate Parts) 포함
객체 상태를 가시화 하는 것은 특정 시간과 공간 상에 주어진 순간의 상태 값
을 명세화 하는 것
객체에 대한 Operation을 수행하면 그 상태는 변화가 발생
속성 값 포함 Instance
myCustomer
Id : SSN = “432-89-1783”
active = True
c : Phone
[WaitingForAnswer]
Kwangju University
명시적 상태 포함 Instance
UML 사용자 지침서
140
용어와 개념(계속)
다른 특성
활성 Class 선언 가능 : Process View를 구성하는 Process와 Thread를 표현
링크(Link) : 객체간 의미적 연결
Class 범위의 Attribute와 Operation
Active Object
r : FrameRenderThread
표준 요소
<<exception>>
e : Overflow
Stereotype Instance
Object와 Class 사이의 의존 관계 표현 Stereotype
instanceOf(인스턴스) : 고객 객체가 공급 분류자인 Instance
instantiate(인스턴스화) : 고객 Class가 공급 Class의 객체를 생성 함
Message와 상태 전이 관계의 Stereotype
become(변화) : 현재는 아니지만 일정 기간(시간)이 지난 후 공급 객체와 대상 객체가
같음
copy(복사) : 공급 객체와 대상 객체가 똑 같지만 독립적인 본사 본 임
Object에 적용할 표준 제약
transient(일시) : 한 역할 Instance가 교류 실행 중 생성되었다 소멸되는 것
Kwangju University
UML 사용자 지침서
141
보편적 모델링 기법
구체 Instance Modeling
Instance 들 사이의 구조적 관계 표현
구체 Instance Modeling 방법
Modeling하려는 문제 영역을 가시화, 명세화, 구축, 문서화하기 위한 Instance 파악
UML 객체들을 Instance로 표현(Object에 명칭 부여)
Modeling하기에 필요/충분한 Instance에 Stereotype, Tagged Value, Attribute 표
현
Instance들과 이들의 관계를 Object Diagram으로 표현하거나 해당 instance를 적절
한 다를 Diagram으로 표현
current : Transaction
primaryAgent <<instanceOf>>
FraudAgent
[working]
Transaction
Kwangju University
UML 사용자 지침서
142
보편적 모델링 기법(계속)
Prototype Instance Modeling
Prototype Object : 개념적 객체 또는 실 세계에서 결과적으로 필요하게 될 대
역 객체
Prototype Instance Modeling 방법
Modeling 대상 문제 영역을 가시화, 명세화, 구축, 문서화하기 위한 Prototype
Instance 파악
UML 객체들을 Instance로 표현 (Object에 명칭 부여)
Modeling하기에 필요/충분한 Instance에 Attribute 표현
Instance들과 이들의 관계를 Interaction Diagram 또는 Activity Diagram으로 표현
2.1 : startBilling
1 : create
a : CallingAgent
c : Connection
2 : enableConnection
1.1 : add
t1 : Terminal
Kwangju University
UML 사용자 지침서
1.2 : add
t2 : Terminal
143
힌트와 조언
구조가 좋은 Instance
특정 추상 개념과 명시적으로 관련
문제나 해법 영역 어휘에서 추출한 고유한 명칭
Instance 그릴 때
문맥에서 명확하지 않으면 Instance의 추상 개념에 대한 명칭을 표기
Instance의 Stereotype, Role, State를 표현하되 문맥에서 Object를 이해
하기에 충분한 정도를 표현
속성과 그 값의 목록이 커지면 각 분류에 따라 개별 Group화
Kwangju University
UML 사용자 지침서
144
14장. 객체도(Object Diagram)
시작하기
용어와 개념
보편적 모델링 기법
객체 구조 모델링
순 공학과 역 공학
힌트와 조언
Kwangju University
UML 사용자 지침서
145
시작하기
객체도 (Object Diagram)
Class Diagram에 포함된 사물들의 Instance를 Modeling
System의 정적인 Design View나 정적인 Process View를 Modeling
하나의 객체도는 특정한 시간의 객체들의 집합과 객체들 간의 관계를 표현
특정 시간의 System Snapshot을 Modeling하여 Object들의 집합, 상태, 관
계 등을 표현
c : Company
d1 : Department
name = “sales”
d2 : Department
name = “R&D”
Link
Object
d3 : Department
name = “US sales”
속성 값
manager
p : Person
name = “Erin”
employeeID = 4362
title = “VP of Sales”
Kwangju University
UML 사용자 지침서
익명 Object
: ContactInformation
address = “1472 Miller St. ”
146
용어와 개념
공통 Property
명칭과 Model을 투영하는 Graphic 내용으로 다른 모든 도해들과 공유하는
공통 Property를 갖음
내용
Package나 Sub-System을 포함할 수 있으며 Model의 요소들을 관련을 고려
하여 Group화 하는데 사용
사용 Property
Object
Link
Note & Constraint
공통 사용
System의 정적인 Design View 또는 Process View를 Modeling 하려 사용하
지만 구체 Instance나 Prototype Instance 관점에서 보는 것이 다름
Kwangju University
UML 사용자 지침서
147
보편적 모델링 기법
Object 구조 Modeling
특정 순간에 System에서 Object들의 Snapshot을 찍은 것
Interaction Diagram의 동적인 Storyboard 중에서 하나의 정적인
Frame(하나의 객체 집합들의 관계)
Class Diagram으로는 추상 개념과 관계의 완전한 명세화가 가능하지만
Object Diagram은 객체 구조를 완벽하게 명세화 할 수 없음. 따라서 구체적
인 Instance나 Prototype Object 집합 중에서 관심이 있는 부분만을 드러
내기에 유리
Object 구조 Modeling 방법
Modeling 대상 Mechanism(System 일부를 이루는 기능이나 행동) 파악
Mechanism에 대해 협력에 참여하는 Class, Interface, Relationship 및 다른 요
소들을 파악
Mechanism을 통과하는 하나의 Scenario를 선정
Scenario를 이해하는데 필요한 각 Object들의 상태와 속성 값 표현
이 Object들과 Link 하는 객체 간의 연관 Instance 표현
Kwangju University
UML 사용자 지침서
148
보편적 모델링 기법(계속)
r : Robot
[moving]
<<global>>
w : World
a1 : Area
unassigned
a2 : Area
w1 : Wall
width = 36
Kwangju University
: Element
w2 : Wall
width = 96
d8 : Door
width = 36
UML 사용자 지침서
w3 : Wall
width = 96
149
보편적 모델링 기법(계속)
순공학과 역공학
Object Diagram의 순공학은 이론적으로 가능하나 실제적으로는 제한된 가
치를 갖음
Object Oriented System에서 Instance는 Application의 실행 중에 생성/
소멸되는 사물들로써 이러한 객체들의 Instance를 외부에 정확히 만들기는
어려움
Object Diagram의 역공학은 개발자나 Tool 들이 System을 Debugging하는
하는 중에 항상 수행되는 일
역공학 방법
역공학 대상 선정
Tool을 사용하거나 Scenario를 검토하면서 특정 순간에 실행을 멈춤
해당 문맥에서 협동하는 관심 있는 객체집단을 파악하여 Object Diagram에 표현
의미를 이해하는데 필요한 정도의 객체만 표현
객체 사이에 존재하는 Link 파악
Diagram이 너무 복잡해 지면 알고자 하는 Scenario와 관련 없는 객체를 제거
Kwangju University
UML 사용자 지침서
150
힌트와 조언
구조가 좋은 Object Diagram
System의 정적 Design View, Process View의 한 관점을 전달하는데 초점을 둠
한 교류도로 표현되는 동적인 Storyboard 중에서 한 Frame 만을 표현
관점을 이해하기에 필수적인 요소들만 표현
추상화 정도에 맞게 상세하며, 이해하기에 꼭 필요한 속성 값과 장식만 표현
중요한 의미가 전달되기에 충분한 정도의 정보만 표현
Object Diagram 그릴 때
목적을 전달하기에 충분한 명칭(Object) 사용
선들이 가능한 한 서로 얽히지 않게 요소들을 배치
의미적으로 밀접한 요소들이 공간적으로 근접하게 배치
중요한 특성들은 시각적 효과를 높이기 위해 Note, Color를 이용
작성자의 의도를 전달하기에 꼭 필요한 Object Value, State, Role 만을 표현
Kwangju University
UML 사용자 지침서
151
Kwangju University
UML 사용자 지침서
152
단원 4. 기본 행동 모델링
15장. 교류
16장. 쓰임새
17장. 쓰임새도
18장. 교류도
19장. 활동도
Kwangju University
UML 사용자 지침서
153
15장. 교류 (Interaction)
시작하기
용어와 개념
보편적 모델링 기법
제어 흐름 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
154
시작하기
교류 (Interaction)
어떤 목적을 달성하기 위하여 Object 간에 교환되는 Message들로 구성
System의 동적인 측면을 모형화
특정 Object에서 다른 Object로 전달되는 Message(Operation 호출, Signal
전송, 다른 Object 생성/소멸 명령)를 표현
교류를 사용하여 제어 흐름을 모형화하며 제어 흐름은 Operation 내에 있거
나 Class,Component, Use Case, 또는 System 전체에 표현
교류의 모형화 방법
시간 관점에서의 Message 순서를 강조하는 방법
Object의 구조 관점에서 Message 순서를 강조하는 방법
Message
Sequence No.
1.1 : getLastCheckpoint( )
1 : getPositionAtTime(t)
t : AirTrafficPlanner
p : FlightPlan
Object
Kwangju University
Link
UML 사용자 지침서
155
용어와 개념
교류는 목적을 달성하기 위해 문맥 내에서 Object 집합간에 교환되는
Message 들의 집합으로 구성된 행동
Message는 Object들 간의 의사 소통을 위한 명세서로써 정보 전달 후 후속
활동이 있음
문맥 (Context)
Object 들이 Link되어 있는 곳에는 교류가 존재
교류 내재 문맥
System 이나 Sub System 전체 문맥에 있는 Object들의 협력에 존재
Object 간의 교류는 Operation 구현에서 표현 됨
Class 문맥에 표현
객체와 역할 (Object & Role)
교류에 참여하는 Object 들은 구체적 사물 또는 Prototype 사물 임
교류의 정적 측면을 표현한 객체도는 함께 동작하는 모든 객체들을 표현하여
교류를 준비하며 객체를 연결한 Link를 따라 Message들의 순서를 동적으로
표현
Kwangju University
UML 사용자 지침서
156
용어와 개념(개념)
링크 (Link)
Object 들의 의미 있는 연결
Link는 연관의 한 Instance이며 한 Object가 다른 Object 또는 자신에게
Message를 보내는 경로를 명세화
Link에 추가되는 표준 Stereotype
Association (연관) : 대응 객체가 연관으로 가시적임을 표현
Self (자신) : 대응 객체가 Operation의 전송자로 가시적임을 표현
Global (전역) : 대응 객체가 내포 범위 내에 존재함을 표현
Local (지역) : 대응 객체가 지역 범위 내에 있음을 표현
Parameter (매개 변수) : 대응 객체가 Parameter임을 표현
Person
1 .. *
+ setCompensation(s:Salary)Employee
+ assign(d: Department)
...
연관
Operation
*
Employer
Company
Class
Message
Assign(development)
p : Person
이름있는 객체
Kwangju University
UML 사용자 지침서
: Company
Link
이름없는 객체
157
용어와 개념(개념)
메시지 (Message)
Object간의 대화 명세화(Object가 활동을 계속 수행한다는 가정하에 정보이동)
Message 전달 시 결과 활동은 실행 가능한 명령문으로써 연산 Procedure를 추
상화 시킨 형태를 취함
활동의 모형화
생성
Call (호출) : 객체 내에 있는 Operation 호출
Return (반환) : 호출자에게 값을 반환
Send (발송) : : 신호를 객체에게 보냄
Create (생성) : 객체를 생성
Destroy (소멸) : 객체를 소멸
Object
c : Client
<<create>>
: TicketAgent
호출
Setltinerart(i)
반환
소멸
반환 값
route
<<destroy>>
발신
Kwangju University
p : PlanningAssistant
실 매개변수
calculateRoute( )
호출
(지역 호출)
notify( )
UML 사용자 지침서
158
용어와 개념(개념)
순차화 (Sequencing)
Message의 흐름은 순차 형태 임
한 Object가 다른 Object에게 Message를 보내면 수신 객체는 또 다른 객체
에게 Message를 다시 보내고 그 수신 객체는 또 다른 객체에게 Message를
다시 보냄
System에 있는 각 Process와 Thread는 제어 흐름을 구별시켜 정의하고, 각
흐름 내에서 Message 들은 시간별로 순서가 있음
Procedural Sequence
Message
순차 번호
2 : clickAt(p)
2.2 : putRecentPick(l)
: View
c : Controller
: Cache
2.1 : l = findAT(p)
중첩 제어 흐름
Flat Sequence
평면 제어 흐름
1: lifeHandset( )
c : Caller
Kwangju University
2 : assertCall( )
: Telephone
UML 사용자 지침서
: Exchange
159
용어와 개념(개념)
생성, 수정, 소멸 (Creation, Modification, Destruction)
Object나 Link가 교류 시간 동안의 변화
New (생성) : Instant나 Link가 교류 시간 내 실행 중에 생성
Destroyed (소멸) : Instance나 Link가 교류 시간 내 실행이 완료되기 전에 소멸
Transient (일시) : Instance나 Link가 교류 시간 내 실행 중에 생성되고 완료 전에 소
멸
표현 (Representation)
교류와 Object와 Message를 가시화하는 방법
순차도 (Sequence Diagram) : Message의 시간적 순서를 강조
Object Lifeline을 Modeling
협력도 (Collaboration Diagram) : Message를 주고 받는 Object들의 조직 구조 표현
교류하는 Object들 간의 Link 구조를 Modeling
Kwangju University
UML 사용자 지침서
160
보편적 모델링 기법
제어 흐름 모델링
교류 사용 목적 : 전체 System 행동 특징을 제어 흐름으로 Modeling하는 것
제어 흐름 모형화 방법
교류 문맥 설정
교류 단계 설정
연결 Link 식별
Object 간의 Message 명세화
보충 설명 추가
시간별 제어 흐름
p : StockQuotePublisher
s1 : StockQuoteSubscript
s2 : StockQuoteSubscript
attach(s1)
attach(s2)
notify( )
update( )
getState( )
update( )
getState( )
Kwangju University
UML 사용자 지침서
161
보편적 모델링 기법(계속)
조직별 제어 흐름
s1 : StockQuoteSubscript
3 : notify( )
4 : update( )
p : StockQuotePublisher
2 : attach(s2)
7 : getState( )
Kwangju University
1 : attach(s1)
6 : getState( )
5 : update( )
s2 : StockQuoteSubscript
UML 사용자 지침서
162
힌트와 조언
좋은 구조의 교류
단순하고 같이 작업하는 Object를 모음
문맥이 분명한 Operation, Class, 전체 System Object 간의 교류를 표현
시간과 자원 간 최적 균형으로 효율적 행동을 표현
교류 요소 중 변경 가능성이 있는 고립 요소를 쉽게 수정하여 적응성이 좋음
부 적절한 부분이 없고 모호한 표현이 없는 이해성이 좋은 표현
UML에서 교류도 도해 방법
교류에 강조를 두는 것을 선택 (시간에 따른 Message 순서를 강조)
해당 문맥에서 교류를 아는데 중요한 Object 특성만 표현
해당 문맥에서 교류를 아는데 중요한 Message 특성만 표현
Kwangju University
UML 사용자 지침서
163
16장. 쓰임새 (Use Case)
시작하기
용어와 개념
보편적 모델링 기법
요소의 행동 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
164
시작하기
쓰임새 (Use Case)
System 전체나 Use Case 일부 행동을 명세화하고 순차적으로 발생하는 활동
들을 기술
행동 순차 모임을 설명하며 순차는 System 외부의 행위자와 핵심 추상 개념
간의 교류를 표현
Use Case는 대상 행동을 명세화만을 수행하고 행동 수행 방법은 규정하지는
않음
모든 행동을 Use Case로 모형화하며 Use Case의 실현과는 무관하게 명세화
순차적으로 발생하는 활동들을 기술하며, 변이를 가질 수 있음
행동은 System 수준에 있는 기능들로써 요구 사항 분석 시 System이 수행해
야 할 활동을 가시화, 명세화, 구축, 문서화하는 도구
Use Case 특성
Use Case는 행위자와 System 간의 교류를 표현
가시적인 작업을 수행
Use Case
전체 System에서도 활용
Actor
Process loan
LoanOffice
Kwangju University
UML 사용자 지침서
명칭
165
용어와 개념
명칭 (Name)
Use Case 는 명칭을 부여하여 다른 Use Case와 구분
명칭 종류
단순명 (Simple name)
경로명(Path name)
단순명
Place Order
경로명
Sensors::
Caliblate location
Validate User
Use Case 와 행위자 (Actor)
Actor는 Use Case와 교류할 때 Use Case 사용자들의 역할을 표현
Actor는 Use Case에 연관 관계를 이용하여 연결 표현
Actor와 Use Case는 서로 대화하며 Message를 주고 받음
Actor
Customer
Kwangju University
Commercial
일반화
Customer
UML 사용자 지침서
166
용어와 개념(계속)
Use Case 와 사건 흐름
Use Case는 System이 무엇을 해야 하는 가를 설명하며, 어떻게 하는가는 명
세화 하지 않음
System의 내부 관점과 외부 관점 간의 관심사를 명백히 분리 표현
Use Case 행동을 명세화 하려면 사건 흐름을 문장으로 설명
사건 흐름 작성시 Use Case가 언제, 어떻게 시작/종료 되는지를 표현
언제 Actor와 교류하며, 변경 객체와 기본 행동 흐름, 대안 행동 흐름도 표현
Use Case 와 Scenario
Scenario는 기본적인 Use Case 의 한 Instance임
하나의 Use Case는 하나의 Sequence가 아닌 여러 개의 Sequence를 한꺼번
에 설명하므로 이러한 순차 집합표현을 하는 흐름을 각각의 순차로 표현하는
것
Kwangju University
UML 사용자 지침서
167
용어와 개념(계속)
Use Case 와 Collaboration
Use Case는 System이 수행 해야 할 행동만을 파악하고 구현은 고려하지 않으
므로 Class와 다른 요소들로 구성된 공동체를 생성하여 함께 표현되도록 Use
Case 행동을 구현
Place Order
Collaboration
Order
Management
Use Case
실체화
Use Case 조직하기
Class와 마찬가지로 Package에 분류 조직 가능
Use Case는 Generalization, Include, Extend관계를 명세화 하여 조직
일반화 (Generalization)
Class 일반화와 마찬가지로 Child Use Case는 Parent Use Case의 행동과 의미를
상속 받음
Child는 Parent가 갖는 행동에 추가될 수 있으며 Parent가 표현되는 곳은 Child로 대
체 가능
포함 (Include)
기본 Use Case가 다른 Use Case 행동을 명시적으로 수용하는 것을 의미
포함된 Use Case는 기본 Use Case 일부로만 Instance를 작성할 수 있음
Kwangju University
UML 사용자 지침서
168
용어와 개념(계속)
포함 관계는 위임을 뜻하며 System이 수행해야 할 책임들을 정한 후 해당 Use Case에서
만 획득 가능하며 다른 Use Case 에서도 기능이 필요하면 해당 책임 집합을 포함시킴
의존 관계로써 Stereotype “Include”로 표현
확장 (Extend)
기본 Use Case에서 간접적으로 명시한 곳에서 다른 Use Case 행동을 암시적으로 편입
기본 Use Case 가 확장될 수 있는 지점을 Extension Point라 하며 미리 정해지므로 예측
가능
사용자가 선택적으로 보는 System 행동
특별한 조건에서만 수행되는 부 흐름을 별도로 모형화
의존 관계로써 Stereotype “Extent”로 표현
확장 관계
<<extend>>
Place Order
(set priority)
Place
Extension points
rush order
set priority
확장점
포함 관계
Track
Order
Check Password
<<include>>
<<include>>
Validate
User
일반화
Retinal Scan
Kwangju University
UML 사용자 지침서
169
보편적 모델링 기법
요소의 행동 모델링
행동을 모형화 하는 것은 요소가 무엇을 하는가에 초점을 맞춤
Use Case 중요 이유
Use Case로 요소 행동을 모형화 하면 최종 사용자,분석가, 개발자간의 의사 소통이
수단으로 활용
Use Case는 개발자 들이 요소에 접근하여 사용되는 방법을 이해할 수 있는 방향을
제시
개발 기간 중에 진화하면서 각 요소를 Test 할 수 있는 기초로 활용
요소 행동 모형화 방법
요소와 교류하는 Actor를 식별
일반화된 역할과 특수화 된 역할을 식별하여 Actor를 조직
Actor가 요소와 교류하는데 중요한 것을 파악
Actor가 요소와 교류할 때 예외적 방법 파악
Use Case로 행동을 조직하되 포함과 확장 관계를 적용하여 공통 행동은 분해하고 예
외 행동을 파악
Kwangju University
UML 사용자 지침서
170
보편적 모델링 기법(계속)
Place order
Track
Order
<<include>>
<<include>>
Validate
customer
<<include>>
Ship order
Extension points
materials ready
Kwangju University
Bill
customer
<<extend>>
UML 사용자 지침서
Ship
partial order
171
힌트와 조언
좋은 구조의 Use Case
행동 명칭은 단일 명칭, 식별 가능 명칭 사용
Use Case가 포함하고 있는 행동을 공통 행동으로 분해
변이성 행동을 구별하여 다른 Use Case에 확장을 표현
Event 흐름을 명확히 하여 쉽게 알 수 있도록
Use Case 의미가 정상인 것과 변이적인 것을 초소한의 Scenario로 명세화
Use Case 도해 방법
전체 System이나 일부 System 문맥에서 행동을 파악하는데 중요한 Use
Case만을 표현
Use Case와 관련 있는 Actor를 표현
Use Case 와 Use Case, Use Case 와 Actor, Actor와 Actor 사이의 관계
를 명세화
Kwangju University
UML 사용자 지침서
172
17장. 쓰임새도 (Use Case Diagram)
시작하기
용어와 개념
보편적 모델링 기법
시스템 문맥 모델링
시스템 요구사항 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
173
시작하기
Use Case Diagram
System이 해야 할 행동을 명세화
System, Sub-System, Class의 각 요소 행동을 모형화 하는 도구로써 요소
이용법을 파악하고, 개발자가 요소를 구현 가능하도록 하는 도구
Use Case Diagram은 Use Case, Actor, 이들 간의 Relation을 표현
Place phone
call
Cellular
network
Actor
User
<<extend>>
Place
conference call
확장(Extend)
Receive
phone call
<<extend>>
Use
scheduler
Receive
additional call
Use Case
System 경계
연관(Association)
Kwangju University
UML 사용자 지침서
174
용어와 개념
내용
Use Case, Actor, Relationship (Dependency, Generalization,
Association)
Use Case Diagram에는 Package가 있어 Model에 존재하는 요소들을 더 큰
단위로 Modeling할 수 있음
공통 사용
System 문맥을 Modeling하는 경우
전체 System을 큰 사각형으로 표현
System 밖에 Actor를 배치 (Actor의 역할도 표현)
System과의 교류 표현
System 요구 사항을 Modeling하는 경우
System이 행 해야 하는 일을 명세화 (방법은 표현하지 않음)
System의 외부에 존재하는 것과 외부에서 발생하는 일 그리고 일에 대한 반
응은 볼 수 있으나 System 내부에서 작동하는 방법은 볼 수 없음
Kwangju University
UML 사용자 지침서
175
보편적 모델링 기법
System 문맥 Modeling
System 외부에 존재하는 것(Actor)과 System과의 교류를 명세화
System 문맥 Modeling 방법
System으로부터 도움을 받아 Task를 수행해야 할 Group을 식별하여 Actor를 식별
Actor 중에서 유사한 것이 존재하면 일반화/특수화 계층으로 조직
Actor를 Stereotype으로 표현하여 이해에 도움을 줌
Use Case Diagram에 식별된 Actor를 표현하고 Actor로부터 Use Case에 대화 경
로 명시
Credit Card Validation System
Perform
card transaction
Customer
Process
customer bill
Retail institution
Reconcile
transactions
Individual
customer
Kwangju University
Corporate
customer
Manage
customer account
UML 사용자 지침서
Sponsoring
financial institution
176
보편적 모델링 기법(계속)
System 요구 사항 Modeling
요구 사항은 System의 설계 특성, Property, Behavior
System 요구 사항 Modeling 방법
System 외부의 Actor를 식별하여 System 문맥을 설정
Actor 별로 System에 요구하는 내용/행동을 파악
공통 행동을 Use Case로 만들고 명칭을 붙임
공통 행동을 분해하여 새로운 Use Case를 만들고 다른 곳에서도 사용 가능하도록
확장
Use Case, Actor, Relationship을 Modeling하여 Use Case Diagram 작성
Credit Card Validation System
Customer
Retail institution
Sponsoring
financial institution
Kwangju University
Perform
card transaction
Process
customer bill
Reconcile
transactions
Report on
account status
Detect
card fraud
Manage
network outage
Manage
customer account
UML 사용자 지침서
177
보편적 모델링 기법(계속)
순공학과 역공학
Use Case Diagram 순공학
Diagram에 있는 각 Use Case 마다 사건 흐름과 예외 사건 흐름을 식별
시험을 깊이 있게 하려면 각 흐름별 시험 Script를 생성
Use Case와 교류하는 각 Actor를 대표하는 Test 기초 생성
Use Case Diagram이 적용되는 요소를 배포할 때마다 Tool을 사용하여 Test
Use Case Diagram 역공학
System과 교류하는 Actor 파악
Actor 별로 Actor가 System과 교류하는 방법을 파악
Actor별로 관련 있는 실행 System에서의 사건 흐름을 추적
관련되는 흐름들을 묶고 적절한 Use Case 명칭을 부여
Actor와 Use Case로 Use Case Diagram을 도식하고 Relationship을 설정
Kwangju University
UML 사용자 지침서
178
힌트와 조언
구조화가 좋은 Use Case Diagram
System의 정적인 Use Case 관점에서 한 부분의 대화에만 초점을 맞춤
해당 부분을 이해하는데 필수적인 Use Case와 Actor만을 포함
추상화 수준별로 일관성 있게 상세 사항을 추가
중요한 의미는 적절한 정도의 크기로 분해
Use Case Diagram 작성법
목적을 알 수 있는 명칭의 사용
교차되는 Line이 가능하면 최소화 되도록 요소를 배치
행동, 역할, 의미가 연관이 있는 것은 인접하여 배치
Note 등의 활용으로 가시적 효과를 이용하여 중요한 특성을 부각 시킴
관계는 너무 많이 표현하지 않고 반드시 필요한 것 만을 표현
Kwangju University
UML 사용자 지침서
179
18장. 교류도 (Interaction Diagram)
시작하기
용어와 개념
보편적 모델링 기법
시간적 순서에 따른 제어 흐름 모델링
구조에 의한 제어 흐름 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
180
시작하기
교류도 (Interaction Diagram)
Object 들과 그들 간의 관계로 구성된 교류를 표현
Object 간 전달되는 Message를 표현
Class, Interface, Component, Node 들의 실체 Instance나 Prototype
Instance를 Modeling 하는 것과 관련되고, 행동을 설명하는 Scenario 문맥에
서 구성 요소간에 전달되는 Message도 포함
교류도 종류
순차도 (Sequence Diagram)
협력도 (Collaboration Diagram)
의미적 동등성
순차도와 협력도는 UML Meta Model에 있는 같은 정보들로부터 파생된 것으
로써 의미상 동등
Kwangju University
UML 사용자 지침서
181
용어와 개념
내용
교류도에 포함되는 요소 : Object, Link, Message
순차도 (Sequence Diagram)
시간에 따른 Message 발생 순서를 강조
교류를 주도하는 객체를 왼쪽에 배치하여 Message 들을 시간의 흐름에 따
라 위에서 아래로 세로축에 따라 배치
Lifeline : 특정 시간(기간)동안 객체가 존재하는 것을 표현
제어 초점(Focus of Control)을 두어 객체가 활동하는 시간대를 표현
순차도 한 개는 제어 흐름 한 개만을 표현
객체
c : Client
Object
<<create>>
: Transaction
setActions(a,d,o)
시간
setValues(d, 3.4)
setValues(a, “CO”)
committed
<<destroy>>
Kwangju University
p : ODBCProxy
{transient}
Message
Focus of Control
UML 사용자 지침서
Lifeline
182
용어와 개념(계속)
협력도 (Collaboration Diagram)
교류하는 Object들 간의 구조적인 관계를 강조
교류에 나타나는 객체들을 Graph 상의 꼭지 점으로 하여 Link롤 연결하고
Message를 순차 번호를 부여하여 표현
순차도와 다른점
Path를 표현
Sequence Number를 부여
Object
c : Client
1 : <<create>>
2 : setActions(a,d,o) Path
3 : <<destroy>>
Stereotype
Link
<<local>>
: Transaction
{transient}
<<global>>
2.1 : setValues(d, 3.4)
2.2 : setValues(a, “CO”)
Sequence Number
Kwangju University
p : ODBCProxy
Message
UML 사용자 지침서
183
보편적 모델링 기법
시간적 순서에 따른 제어 흐름 모델링
교류 문맥을 설정
교류에서 역할 관계를 식별하여 교류 단계 설정
객체의 생명선 설정
교류 개시 Message를 시작으로 후속 Message를 위에서 아래로 생명선 사이에 배
치
교류 의미를 설명하는데 필요한 Property(Parameter)를 표현
실제 연산이 발생하는 지점을 가시화하려면 제어 초점으로 객체 생명선을 장식
시간 제약이나 공간 제약을 명세화 하려면 Massage에 시간과 공간의 제약 장식
제어흐름을 더욱 자세히 명세화 하려면 각 Message에 선행 조건, 종료 조건 명시
s : Caller
r : Caller
: Switch
liftReceiver
setDialtone( )
* dialDigit(d)
dialing
connect(r)
Kwangju University
{dialing.executionTime < 30 sec}
routeCall(s,n)
<<create>>
c:Conversation
Ring( )
liftReceiver
connect(r, s)
connect(s)
UML 사용자 지침서
Caller s and r may
exchange information
after both are connected
184
보편적 모델링 기법(계속)
구조에 의한 제어 흐름 모델링
교류 문맥을 설정
교류에서 객체 역할을 식별하여 교류 단계 설정
객체 각각의 초기 Property 설정
객체간 Link의 명세화
교류 시작 Message로부터 연속되는 Message를 Link에 순차 번호를 포함하여
표현
시간 Mark로 시간 제약, 공간 제약 표현
제어 흐름의 공식 명세화가 필요하면 선행/종료 조건을 각 Message에 포함
1 : <<create>>
3 : register ( )
<<local>>
s : Student
2 : addStudent(s)
r : RegistrarAgent
: School
3.1 : getSchedule ( )
{self}
s : Student
3.4 : <<become>> registered : False
registered : False
3.2 : add(s)
3.3 : add(s)
c1 : Course
c2 : Course
{association} {association}
Kwangju University
UML 사용자 지침서
185
보편적 모델링 기법(계속)
순공학과 역공학
Interaction Diagram은 문맥이 Operation이면 순공학/역공학에서 모두 유
리
순공학
앞의 예제(협력도)를 자바 Code로 생성하면
public void register ( ) {
courseCollection c = getSchedule ( ) ;
for (int I =0 ; I <c.size ( ) ; I ++)
c.item (i) . Add(this) ;
this.registered = true ;
}
역공학
해당 부분이 Registration Operation을 도구로 실행시키면 그려 낼 수 있음
배치된 System을 실행하는 것 보다는 모델을 동작시키는 것이 역공학 Model을 작
성하는데 유리
Kwangju University
UML 사용자 지침서
186
힌트와 조언
구조가 좋은 교류도를 작성
한 가지 측면에만 초점을 맞춘 동적인 면 파악
해당 부분을 이해하는데 필수적인 요소만 표현
추상화 수준에 맞으며 이해하기에 필수적인 장식만 표현
적정한 단위까지 최소화 시켜 작성
교류도 작성 방법
목적을 전달할 수 있는 명칭 부여
시간적 강조이면 순차도, 구조적 강조이면 협력도 사용
교차 선이 최소화하는 요소 배치
Note 등을 이용한 시각 효과를 표현
분기를 최소화 표현
Kwangju University
UML 사용자 지침서
187
19장. 활동도 (Activity Diagram)
시작하기
용어와 개념
보편적 모델링 기법
워크플로 모델링
오퍼레이션 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
188
시작하기
활동도 (Activity Diagram)
순서도의 일종으로 발생하는 활동을 강조
흐름도로써 활동으로부터 활동으로 전달되는 제어 흐름 표현(발생 활동에 초점)
객체간 통과 제어 흐름(Operation)을 표현
활동은 다시 몇 개의 Action으로 분리
초기 상태
동시 분할
Select site
동작 상태
Commission architect
Do site work Do trade work( )
동시 합류
Develop plan
Bid plan
Finish construction
[not accepted]
순차적 분기
Kwangju University
Sub Machine이 있는
활동 상태
: Certificate Of Occupancy
[completed]
객체 흐름
[else]
종료 상태
UML 사용자 지침서
189
용어와 개념
동작 (Action) 상태와 활동 (Activity) 상태
동작(Action) 상태
Object에 있는 Operation을 호출, Object에 Signal을 전송, Object의 생성, 소
멸을 시키는 일
동작 상태는 더 이상 분해되지 않음
작업 실행 시간은 순간적으로 진행
표현식 동작
Bid plan
Index := lookup(e) + 7 ;
단순 동작
활동(Activity) 상태
제어 흐름이 다른 활동 상태들과 동작 상태들의 복합
활동 상태는 더 작은 활동과 동작으로 분해 가능
종료하는데 어느 정도의 시간이 필요
Sub Machine
Process bill (b)
Kwangju University
Do construction ( )
entry / setLock ( )
UML 사용자 지침서
진입 동작
190
용어와 개념(계속)
전이 (Transition)
한 동작이나 활동 상태에서 다른 동작이나 활동 상태로 가는 경로
Select site
촉발 없는 전이
Commission architect
분기 (Branching)
하나의 전이가 부울식에 근거한 경로 대안으로 두개 이상의 전이로 나뉘는 것
Release work order
[material not ready]
Reschedule
[material ready]
Assign tasks
Kwangju University
전이식
UML 사용자 지침서
191
용어와 개념(계속)
분할 (Forking)과 합류 (Joining)
동기화 막대를 이용하여 동시 제어 흐름을 여러 개로 나누거나 하나로 합하
는 전이 표현
Prepare for speech
분할
Decompress
Gesture( )
Synch mouth( )
Stream Audio( )
합류
Clean up
Kwangju University
UML 사용자 지침서
192
용어와 개념(계속)
구획면 (Swimlanes)
활동도의 활동 상태들을 분리시켜 Group화 하는 것
유일한 명칭을 갖으며 실세계의 실체를 대표
Customer
Request product
Sale
Warehouse
구획면
Process order
Pull material
Ship order
Receive order
Pay bill
Kwangju University
Bill customer
Close order
UML 사용자 지침서
193
용어와 개념(계속)
Object 흐름
활동도에 관여하는 사물들을 명세화
Customer
Sale
Warehouse
Request product
Process order
o : Order
[in progress]
Receive order
Pay bill
b : Bill
[paid]
Kwangju University
Pull material
Ship order
객체 흐름
Bill customer
b : Bill
[unpaid]
Close order
UML 사용자 지침서
o : Order
[filled]
객체
상태
194
보편적 모델링 기법
Workflow Modeling
System과 협력하는 행위자 관점에서 활동에 초점을 맞추어 개발 대상에 있
는 업무 공정을 가시화, 명세화, 구축, 문서화
Workflow Modeling 순서
Workflow에 초점을 맞춤
전체 Workflow의 부분들을 상위에서 책임지는 업무 Object를 선정
초기 상태로 가기 위한 선행 조건과 종료 상태가 되기 위한 조건 식별
시간에 따라 발생하는 활동과 동작을 활동도에 표현
복잡환 활동, 반복 활동은 활동 상태 단위로 나눈 후 각각을 별도 활동으로 표현
활동이나 동작 상태 등을 연결시켜 전이를 추가
관련 중요 Object를 활동도에 표현
Kwangju University
UML 사용자 지침서
195
보편적 모델링 기법(계속)
Customer
Telesales
Accounting
Warehouse
Request return
Get return No.
Ship item
Receive item
I : Item
[returned]
Restock item
Credit account
Kwangju University
UML 사용자 지침서
I : Item
[available]
196
보편적 모델링 기법(계속)
Operation Modeling
활동도의 문맥에 있는 Operation의 Parameter와 Local Object의 분기
(Branch), 분할(Fork), 합류(Join) 등을 활용한 모형화
Operation Modeling 순서
Operation 관련 추상 개념 수집
초기 상태의 선행 조건과 종료 상태의 종료 조건 파악
시간 경과에 따라 활동과 동작 표현
Operation이 활동 Class에 소속된 경우 분할과 합류를 사용하여 동시 제어 흐름 명
세화
[slope = l.slope]
[else]
return Point (0,0)
x = (l.delta - delta) / slope - l.slope) ;
y = (slope * x) + delta
return Point (x, y)
Kwangju University
UML 사용자 지침서
197
보편적 모델링 기법(계속)
순공학과 역공학
활동도(Operation Modeling)의 순공학 C++ Code 예제
Point Line :: Intersection (l : Line) {
if (slope == l.slope) return Point (0, 0) ;
int x = (l.delta - delta) / (slope - l.slope) ;
int y = (slope * x) + delta ;
return Point (x, y) ; }
역공학은 Code 문맥이 Operation의 몸체인 경우 구현 Class로부터 생성 가능
운영 System에서 Message들을 전달 시키는 것과 같이 도구로 Message를 작
동 시켜 Model 동작을 관찰
Kwangju University
UML 사용자 지침서
198
힌트와 조언
구조가 좋은 활동도
System 동적인 면의 한 가지 측면에만 초점을 둠
해당 부분을 이해하는데 필수적인 요소들만 표현
추상화 수준에 맞는 상세성을 일관되게 제공
중요한 의미를 이해하기 적절한 단위로 표현
활동도 작성 방법
목적을 전달할 수 있는 명칭의 부여
주 흐름으로부터 시작하여 전이, 분기, 동시성을 표현 (하위 활동도를 고려)
교차 선이 최소화 하도록 요소를 배치
중요한 부분은 Note, Color 등을 이용하여 시각적 효과 부각
Kwangju University
UML 사용자 지침서
199
Kwangju University
UML 사용자 지침서
200
단원 5. 응용 행동 모델링
20장. 사건과 신호
21장. 상태 머신
22장. 프로세스와 쓰레드
23장. 시간과 공간
24장. 상태도
Kwangju University
UML 사용자 지침서
201
20장. 사건과 신호(Event & Signal)
시작하기
용어와 개념
보편적 모델링 기법
신호 패밀리 모델링
예외 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
202
시작하기
사건과 신호 (Events & Signals)
사건(Event)이란 실 세계에서 발생하는 시간과 공간을 점유하는 의미 있는 일
신호란 사건에 발생하는 자극
사건은 동기 또는 비동기로 발생하며, 사건 Model은 Process Model과
Thread Model로 완성 됨
상태 머신(State Machine) 문맥에서는 사건을 이용하여 자극이 상태 전이를 발
생 시키는 행위를 Model로 작성 함.
사건에는 신호, 호출, 시간 경과, 상태 변경 등이 발생
사건 선언
Idle
<<signal>>
OffHook
OffHook / dropConnection( )
사건
Kwangju University
UML 사용자 지침서
Active
203
용어와 개념
사건 종류 (Kinds of Events)
내부 사건 : System 내부의 Object 간에 발생하는 사건
외부 사건 : System과 Actor 간에 발생하는 사건
UML의 사건 Model 종류
Signal
Call
Pass of Time
Change in State
신호 (Signal)
한 Object에서 비동기로 전송하면 다른 객체에서 수신하는 것
Signal은 Class와 유사하며 Instance를 만들 수 있고 일반화 관계를 이용하
여 사건 계층 Model을 갖을 수 있음
Signal
Parameter
Kwangju University
<<signal>>
Collision
force : Float
<<send>>
MovementAgent
position
velocity
moveTo( )
Send Dependency
UML 사용자 지침서
204
용어와 개념(계속)
호출 사건 (Call Events)
Operation이 발생되는 것 (동기적)
한 Object가 State Machine이 있는 다른 Object에 속한 Operation을
Invoke(가동) 시키면 Control은 발송자로부터 수신자로 사건 전이 촉발
Operation이 완료되면 수신자는 새로운 상태로 전이되며 제어는 발송자로 복
귀
startAutopilot(normal)
Manual
Automatic
Event
Parameter
시간(Time) 사건과 변경(Change) 사건
시간 사건 : 시간의 경과를 나타내는 사건
변경 사건 : 상태의 변경 즉, 어떤 조건이 만족되는 것을 나타내는 사건
when (11:49 PM) / selfTest( )
Change Event
Idle
Time Event
after (2 seconds)
/ dropConnection( )
Active
Kwangju University
UML 사용자 지침서
205
용어와 개념(계속)
사건 보내기와 받기 (Sending and Receiving Events)
신호 사건과 호출 사건은 적어도 두 Object와의 관련(신호를 보내거나
Operation을 기동 시키는 Object와 사건이 향하고 있는 Object가 존재)
Class에서 나오는 모든 Instance는 수신 Object에게 Signal을 보낼 수 있고
Operation을 기동 시킬 수 있으며 Class의 어떤 Instance이건 호출 사건 즉
Signal을 받을 수 있음
활성 Class
KeypadManager
Signals
pushbutton(b : button)
powerUp
powerDown
Kwangju University
UML 사용자 지침서
Signal
206
보편적 모델링 기법
신호 패밀리 (Family of Signal) Modeling
사건 중심 System에서 신호 사건은 계층적 임
신호 계층을 Modeling하면 다형성 사건을 명세화 할 수 있음
Signal Family Modeling
주어진 활동 Object가 응답할 수 있는 모든 종류의 신호를 고려
공통으로 사용되는 신호를 파악하여 상속을 이용해서 일반화/특수화에 배치
활성 Object의 State Machine에서 다형성이 될 수 있는 것을 파악
<<signal>>
RobotSignal
<<signal>>
Collision
sensor : Integer
<<signal>>
BatteryFault
<<signal>>
HardwareFault
<<signal>>
MovementFault
<<signal>>
VisionFault
<<signal>>
RangingFault
<<signal>>
MotorStall
Kwangju University
UML 사용자 지침서
207
보편적 모델링 기법(계속)
예외 (Exception) Modeling
하나의 Operation이 발생할 수 있는 예외 신호를 명세화
예외도 신호의 한 종류이며 Stereotype Class로 Model화
Exception Modeling
각 Class와 Interface나 요소들의 Operation에 대해 발생할 수 있는 예외 조건을 파
악
예외들을 계층적으로 배열
각 Operation에 대하여 예외가 발생할 수 있는 것을 명세화
<<exception>>
Exception
setHandler( )
firstHandler( )
lastHandler( )
Set
add( )
remove( )
Kwangju University
item
<<signal>>
<<send>> MovementFault
<<send>>
<<send>>
<<signal>>
VisionFault
UML 사용자 지침서
<<signal>>
RangingFault
208
힌트와 조언
Event Model 만들 때
신호 계층을 구축하여 관련된 신호들에 있는 공통 Property를 발견
정상 제어 흐름을 대치하면서 신호를 보내거나 예외가 없도록
사건을 수신하는 각 요소마다 합당한 State Machine이 있는가 확인
사건을 수신하는 요소들을 Modeling하는 것 외에 사건을 발생하는 요소들을
Modeling
UML로 사건을 표현할 때
사건 계층은 명시적으로 표현하고 사용에 관한 것은 사건을 발송/수신하는
각 Class 또는 Operation의 이면(Backplane)에서 Model을 작성
Kwangju University
UML 사용자 지침서
209
21장. 상태 머신(State Machine)
시작하기
용어와 개념
보편적 모델링 기법
객체 생명 주기 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
210
시작하기
State Machine
State Machine을 이용하여 개별 Object의 행동(동적인 측면)을 Modeling하
며 이는 Object가 생명주기 동안 통과하는 State들을 발생하는 순서대로 명
시한 행동이며 Object는 사건이 도달되면 반응하고 사건에 응답
State Machine의 두 가지 방법
활동도(Activity Diagram) : Object 안에서 발생하는 활동에서 초점을 두어 한 활
동에서 다른 활동으로 전달되는 Control Flow를 강조
상태도(Statechart Diagram) : 사건 요구에 따른 Object가 취할 수 있는 행동에
초점을 두고 상태들 사이의 전이를 강조 - 반응 System 모형 작성에 유용
Final State
Initial State
shutDown
Idle
State
Event Parameter
tooCold(desiredTemp)
Heating
tooHot(desiredTemp)
Event
atTemp
Cooling
atTemp
Activating
tooHot(desiredTemp)
tooCold(desiredTemp)
Kwangju University
Action
Transition
UML 사용자 지침서
Nested State
ready / turnOn( )
Active
211
용어와 개념
State Machine : 상태가 순차적으로 발생하는 것을 명세화 한 행동이며
Object는 생명 주기 동안 사건에 따라 상태를 변경해 가며 사건에 대한 응답 수
행
State : Object가 생명 주기 동안 가질 수 있는 조건(상황)이며 특정 조건이 만
족된 상태에서 활동을 수행하고 사건을 기다림
Event : 시간과 공간에서 위치를 점유하고 있는 중요한 발생 명세서로써 자극이
발생되며 상태 전이를 촉발
Transition : 두 상태 간의 관계로써 특정 상태에 있던 Object가 동작을 수행한
후 사건이 발생하고 정해진 조건이 만족되었을 때 다음 상태로 전환
Activity : State Machine안에서 비 원자성으로 실행
Action : 실행될 수 있는 원자성 연산으로 Model 상태를 변경하거나 Return 값
을 발생
문맥 (Context)
Object가 생명 주기 동안에 다른 Object에 작용할 수 있고, 작용 받을 수 있는
동기적인 것을 포함하며 이들 Message들은 단순한 동기 Operation을 호출
State Machine은 신호를 받을 수 있는 Class 들의 Instance와 활동 Object도
포함
비 동기적 자극이 오면 응답해야 하는 Object 행동이나 객체의 현 행동이 과거
에 의존하는 경우 State Machine을 이용하여 명세화 하는 것이 바람직
Kwangju University
UML 사용자 지침서
212
용어와 개념(계속)
상태 (State)
Object 생명 주기 동안에 가질 수 있는 특정 조건(상황)이며 해당 기간 동안
Object는 조건이 만족된 상태에서 활동을 수행하고 다른 사건도 기다림
상태의 구성
명칭(Name) : 특정 상태와 다른 상태를 구분 짓는 문자열로 구성된 이름
진입/탈출 동작(Entry/Exit Action) : 상태에 들어오거나 나갈 때 수행되는 동작
내부 전이(Internal Transition) : 상태 변경을 초래하지 않고 처리되는 상태 내의
전이
하위 상태(Substate) : 중첩(Nested) 구조로 된 상태이며 배타적 하위상태(순차적
활성화)나 동시적 하위 상태(동시적 활성화)
지연 사건(Deferred Event) : 사건 목록으로써 현 상태에서 처리되지 않고 다른
상태에서 처리하기 위하여 대기 Queue에 저장되는 사건
초기 상태와 종료 상태
shutDown
keyPress
Idle
Running
finished
상태 명칭
Kwangju University
UML 사용자 지침서
213
용어와 개념(계속)
전이 (Transition)
특정 Object가 현 상태에서 어떤 동작을 수행한 후 지정된 상태가 발생하고 지정된
조건이 만족되었을 때 다음 상태로 들어가는 두 상태간의 관계
전이의 5 부분
원래 상태(Source State) : 전이에 의해 바뀌는 상태
촉발 사건(Event Trigger) : 원래 상태의 객체가 한 사건을 받았을 때 조건이 만족되어 전이
를 합당하게 수행할 수 있는 조건
전이 조건(Guard Condition) : 촉발 사건이 수신되어 전이 촉발 시에 검토되는 Boolean 식
(True이면 수행)
동작(Action) : 실행 가능한 원자성 연산, Object에 직접 또는 간접적으로 발생하는 작용
목표 상태(Target State) : 전이가 완료된 후의 활성 상태
시간 사건
After (2 seconds) / send c.isAlive
재귀 전이
사건 Trigger
전송 신호
Idle
매개 변수 있는 사건 Trigger
noise
Searching
Engaging
전이 조건
targetAt(p) [isThreat] /
t.addTarget(p)
동작
Kwangju University
Trigger 없는 전이
Tracking
UML 사용자 지침서
shutDown
contact
Engaging
214
용어와 개념(계속)
상태와 전이의 응용 (Advanced States & Transitions)
행동 모형이 복잡해질 때 활용
고급 특성
진입 / 탈출 동작(Entry/Exit Action) : State에 들어갈 때 진입 동작 실행, State를 떠
날 때 탈출 동작 실행
내부 전이(Internal Transition) : 재귀 전이와는 차이가 있으며 상태 내부에서 접하는 사
건들을 처리하되 상태를 벗어나지는 않음
활동(Activity) : Object가 한 상태에 있을 때 유휴 상태에서 사건 발생을 기다리거나 진
행중인 행동을 Model화 하는데 한 상태에 있는 동안은 상태에서 어떤 일을 수행하며 이는
Event가 도달하면 Interrupt가 발생 됨
지연 사건(Deferred Event) : 특정 사건이 동작되기 전에는 다른 사건들이 연기(대기)
명칭
Tracking
진입 동작
entry / setMode(onTrack)
exit / setMode(offTrack)
newTarget / tracker.Acquire( )
do / followTarget
selfTest / defer
내부 전이
지연 사건
Kwangju University
UML 사용자 지침서
탈출 동작
활동
215
용어와 개념(계속)
하위 상태 (Substate)
단순(Simple) 상태 : 하위 구조를 갖지 않는 상태
복합(Composite) 상태 : 하위 상태를 포함하는 중첩(Nested) 상태
복합 상태는 동시(직교성(orthogonal)) 하위 상태 또는 순차(배타적(Disjoin))
하위 상태를 포함
순차 하위 상태(Sequential Substate)
Active 순차에 있는 모두로부터 나오는 전이를 한꺼번에 표현
순차 하위 상태들은 복합 상태의 사태 공간을 분할하여 배타적 상태가 됨
복합 상태
복합 상태의 전이
Idle
cardInserted
cancel
Active
Activating
[continue]
maintain
Selecting
Processing
[not continue]
Maintenance
하위 상태로부터의 전이
Kwangju University
순차 하위 상태
entry / readyCard
exit / ejectCard
UML 사용자 지침서
Printing
216
용어와 개념(계속)
이력 상태(History State)
Object가 복합 상태를 떠날 때 활동한 마지막 하위 상태를 기억하고 있는 Object
Model을 만들 필요가 있을 때 사용
얕은(Shallow) 이력 상태
첫번째 진입의 초기 상태
BackingUp
H
Command
query
Collecting
Copying
CleaningUp
Kwangju University
UML 사용자 지침서
217
용어와 개념(계속)
동시 하위 상태(Concurrent Substate)
포함된 Object들의 문맥에서 동시적으로 실행되는 State Machine이 두개 이상 나
타낼 때 사용
동시 하위 상태는 실행이 병렬도 진행되다 각 중첩 State Machine이 종료 상태에
도달
Idle
분할(fork)
합류(join)
maintain
복합 상태
Maintenance
동시 하위 상태
Testing
Testing
devices
Commanding
Testing
devices
Kwangju University
Self
diagnosis
[continue]
keyPress
UML 사용자 지침서
Self
diagnosis
[not continue]
218
보편적 모델링 기법
Object 생명 주기(Lifetime) Modeling
Interaction은 함께 작동하는 Object 들의 행동 Modeling에 활용하며,
State Machine은 한 Object Lifetime Modeling으로 Class의 Instance,
Use Case, 전체 System Model의 사용자 Interface, Controller, Device
등을 대상으로 함
Object Lifetime Modeling
State Machine의 문맥을 설정(Class, Use Case, 전체 System을 대상)
Object의 초기 / 종료 상태 설정
Object가 응답할 수 있는 Event 파악
초기 상태에서 시작하여 종료 상태에 이르기까지의 Object 상태들을 배치
진입 동작과 탈출 방법을 식별
각 상태들을 하위 상태를 이용하여 필요한 만큼 확장
State Machine에 표현된 각 사건들이 Object Interface에서 예견되는 사건들과
부합되는지 확인
State Machine에 표현된 각 Action들이 Object를 내포한 관계와 Method,
Operation에 의해 유지되는지를 점검
State Machine을 Trace하면서 예견되는 사건 순차와 응답을 보면서 확인
State Machine을 재 배치한 후에 예견되는 순차를 보면서 다시 점검하며 Object
의미가 바뀌지 않았는지를 확인
Kwangju University
UML 사용자 지침서
219
보편적 모델링 기법(계속)
Initializing
after(10 seconds) / selfTest
Idle
attention
alarm(s)
clear
Active
Command
attention
Checking
Calling
entry /
callCenter(s)
Entry / setAlarm
exit / clearAlarm
Kwangju University
UML 사용자 지침서
Waiting
220
힌트와 조언
구조가 좋은 State Machine
단순하며 State나 Transition이 과다하지 않을 것
문맥이 분명하며 내포된 Object에서 가시적인 모든 Object에 접근 가능
시간과 자원을 동작 요구에 최적으로 활용되도록
System에 존재하는 어휘로 State나 Transition 명칭을 사용하여 이해하기
쉽도록
과다한 중첩을 피할 것
동시 하위 상태를 많이 사용하지 말 것(활용 Class 사용)
UML로 State Machine을 표현할 때
가능하면 Transition이 교차하지 않도록
복합 상태를 확장할 때는 Diagram을 이해하기 쉽게 하는 범위로 한정
Kwangju University
UML 사용자 지침서
221
22장. 프로세스와 쓰레드(Process & Thread)
시작하기
용어와 개념
보편적 모델링 기법
다중 제어 흐름 모델링
프로세스간 통신 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
222
시작하기
Process와 Thread
System Model의 Process View에 해당
System의 병렬 및 동기화 Mechanism을 구성 시키는 Thread와 Process를 포
함
독립된 각 제어 흐름은 활동 객체(Active Object)로 Modeling하며 제어 활동
을 주도할 수 있는 Process나 Thread로 구성
Process : 비교적 큰 흐름의 표현으로 다른 Process와 병행으로 실행
Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread와 병행으로
실행
Active Class
Name
BackgroundController
currentKnowledgeSource
Signals
blackboardIsSovned
hasAHint
Kwangju University
UML 사용자 지침서
Attribute
Operation
Signal
223
용어와 개념
Active Object : Process나 Thread를 소유하고 있는 Object로써 제어 활동을
주도
Active Class : 자신의 Instance가 활성 객체인 Class
Process : 비교적 큰 흐름의 표현으로 다른 Process와 병행으로 실행
Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread와 병행으
로 실행
제어 흐름 (Flow of Control)
특정 순간에 발생하는 사건의 진행
순차 System의 제어 흐름은 한 개이며 동시 System에서는 두 개 이상 임
Class와 Event
Active Class도 Class의 일종이지만 독립적인 제어 흐름을 갖는 다는 점이 다름
Active Object는 Active Class의 Instance로써 Process와 Thread를 구현
Active Object는 비활성(Passive) Object가 표현되는 곳이면 어디에서나 활용
가능하며 State Machine에서 사건의 목표를 표현할 수 있음
표준 요소 (Standard Element)
UML 확장 Mechanism은 모두 Active Class에 적용(Tagged Value 활용)
적용 표준 Stereotype
Process
Thread
Kwangju University
UML 사용자 지침서
224
용어와 개념(계속)
통신 (Communication)
Object 간의 협력은 그들 Message를 서로 전달하며 교류
교류 방법
비활성 객체 : Operation이 단순히 호출되는 것
활성 객체 : 한 활성 객체가 다른 객체 Operation을 동기로 호출
비동기로 신호를 보내거나 객체 Operation을 호출
활성 객체
비활성 객체 : 두 개 이상의 활성 객체가 한 순간에 각각의 제어 흐
름을 비활성 객체로 통과 시키는 경우
비활성 객체
활성 객체 : 활성 객체에서 활성 객체로 Message를 통과시키는
것과 동일
비활성 객체
활성 객체
Active Object
Synchronous Message
b : Blackboard
c1 : initialize( )
Asynchronous Message
2 : placePartialSolution( )
c : BlackboardController
Flow Sequence
Kwangju University
1 : hasAHint(k)
c2 : startSearch( )
c3 : k.evaluate( )
UML 사용자 지침서
: KnowledgeSource
225
용어와 개념(계속)
동기화 (Synchronization)
흐름이 Operation을 통과할 때 주어진 한 순간의 제어 자취는 Operation에 있으
며 Operation이 다른 Object의 활동을 유발
한 Operation은 각 제어흐름을 갖을 수 있고 또한 여러 제어 흐름이 존재 가능
한 Object 내에서 여러 제어흐름이 있을 때 서로의 흐름이 방해하지 않도록
순차(Sequential) : 호출자는 Object 외부와 조정을 하여 한 순간에 단 한 개의 흐름만
존재하도록
감시(Guarded) : 복수 제어 흐름이 존재할 때 Object의 감시를 받는 모든 Operation을
순차화 하여 Object 의미와 무결성 보장
동시(Concurrent) : 복수 제어흐름이 있을 때 Operation을 원자성으로 취급하여 객체 의
미와 무결성 보장
Name
Operation
Buffer
size : integer
add( ) {concurrent}
remove( ) {concurrent}
Attribute
Synchronization Property
Process View
Active Process는 System의 Process View를 가시화, 명세화, 구축, 문서화
System Process View는 동시성과 동기화 Mechanism을 형성하는 Thread와
Process를 포함(System의 성능, 신축성, 처리량 등을 포함)
Kwangju University
UML 사용자 지침서
226
보편적 모델링 기법
다중 제어 흐름 (Multiple Flow of Control) Modeling
복수 제어 흐름을 포함한 System은 동시 활성 객체의 작업 순서를 결정해야 하
며 System의 활성 객체와 비 활성 객체와의 정확한 통신이 되도록 설계
제어의 다중 흐름 Modeling
동시 활동 가능성을 식별 후 각 흐름을 구체화하여 Active Class로 구현
Active Class 책임을 균형 있게 분산하고 각 Class 들이 정적으로 협조하고 있는 다른
Active Class와 Passive Class를 조사
Active Class들을 명시적으로 부각시키며 정적인 결정 사항을 획득
각 Class Group 들이 서로 동적으로 협력하는 방법을 파악
Active Class 간에 발생하는 Communication을 조사
Active Class와 협력중인 Passive Class와의 동기화에 주의를 기울여 도식
s1 : postValue( )
s : StockTicker
c : CNNNewsFeed
s : StockTicker
c1 : postBreakingStory( )
s2 : postAlert( )
m1 : postAlert( )
m : AlertManager
t : TradingManager
i2 : postAlert( )
i1 : postValue( )
i : IndexWatcher
i : IndexWatcher
Kwangju University
UML 사용자 지침서
227
보편적 모델링 기법(계속)
프로세스간 통신 (Interprocess Communication) Modeling
System에서 복수로 수용되는 제어 흐름을 상주하는 Object간에 통신하는
Mechanism 도식
Process간 통신 Modeling
복수 제어 흐름 Model 작성
활성 객체 중 Process와 Thread를 Stereotype을 이용하여 구분
Message Model을 비동기 통신으로 하고 동기 통신으로 Remote Procedure Call
Model 작성
Note를 활용하여 하부 통신 Mechanism을 명세화
CORBA ORD
t1 : planTrip( )
Client
<<process>>
t : TripPlanner
{location = client}
Server
<<process>>
r : ReservationAgent
{location = reservation server}
r3 : postResults( )
r1 : make( )
<<process>>
h : HotelAgent
{location = hotel server}
Kwangju University
UML 사용자 지침서
r2 : make( )
<<process>>
t : TicketingManager
{location = airline server}
Communicates
across Beans
messaging service
228
힌트와 조언
구조가 좋은 Active Class와 Active Object
독립 제어 흐름으로 표현하여 System 동시성의 잠재력을 높임
다른 활성 요소들이 복수로 표현될 정도로 적지 않도록
활성 요소들 간의 통신은 동기식과 비동기식 Messaging을 선택하여 표현
각 Object를 임계 지역(Critical Region)으로 주의 깊게 취급
Process와 Thread 의미를 명시적으로 구분
UML로 Active Class와 Active Object를 표현할 때
문맥 내의 추상 개념을 이해하기에 충분한 정도의 Attribute, Operation,
Signal 들만 표현
모든 동기 Property를 명시적으로 표현
Kwangju University
UML 사용자 지침서
229
23장. 시간과 공간(Time & Scope)
시작하기
용어와 개념
보편적 모델링 기법
시간 제약 모델링
객체 분산 모델링
이주 객체 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
230
시작하기
시간과 공간 (Time & Space)
시간과 공간 Model을 만드는 일은 실시간 / 분산 System에서는 필수 요소
이며 시간 표시, 시간 표현식, 제약, 꼬리표 값 등을 포함하여 System 표현
System의 시간과 공간 특성을 필요 / 충분하게 반영
실시간 분산 System
실시간 System
위치
분산 System
c : Client
{location = console}
m : MapServer
{location = server}
a : getMap(region)
c : MapCache
{location = missionserver}
b : getMap(region)
시간 표시
{a.executionTime < 10ms}
시간 제약
Kwangju University
시간 식
UML 사용자 지침서
231
용어와 개념
시간 표시(Timing Mark) : Event가 발생하는 시간 표시
시간 표현식(Time Expression) : 절대 시간 / 상대 시간을 검사하는 표현식
시간 제약(Time Constraint) : 시간과 관련된 모든 제약
시간 (Time)
System에서 시간상 규칙적 / 비 규칙적으로 발생할 내용 표현
사건에 대한 응답은 예측 가능한 절대 시간이나 사건에 상대적으로 예측 가
능한 시간에 표현
{every 1 ms}
c1 : testKeys( )
c : MIDIController
시간 제약
: KeyCollection
c2 : testKey( )
{executionTime < 10ns}
k : Key
c3 : add(k)
{every 1 ms}
t1 : remove( )
B : MIDIEventBuffer
Kwangju University
UML 사용자 지침서
c : MIDITransmitter
232
용어와 개념(계속)
위치 (Location)
여러 지역에 분산되어 있는 System Node들의 물리적인 Component들을 표현
<<processor>>
KioskServer
Deploys
vision.exe
log.exe
selftest.exe
Location by Nesting
: LoadAgent
{location = Router}
Location Tagged Value
Kwangju University
UML 사용자 지침서
233
보편적 모델링 기법
시간 제약(Timing Constraint) Modeling
시간 제약을 이용하는 실 시간 System의 Time Critical Property
사건의 절대 시간 Modeling
사건간 상대 시간 Modeling
한 동작을 수행하는데 걸리는 시간 Modeling
Timing Constraint Modeling
교류에 있는 각 사건에 대해 절대 시간에 시작되어야 할 대상을 파악
교류에서 관심 대상인 Message의 각 순서에 대해 연관된 상대 시간을 파악
각 Class에 존재하는 시간이 급한 Operation에 대해 시간 복잡성을 파악
{a : startTime every 1 ms}
S : SystemAgent
P : ServerPage
a : refresh( )
C : Camera
b : getImage( )
{getImage.executionTime is
proportional to image size.}
{b.executionTime < 100ns}
Kwangju University
UML 사용자 지침서
234
보편적 모델링 기법(계속)
객체 분산(Distribution of Object) Modeling
분산 System Topology를 만들 때 고려해야 할 Component와 Class Instance의 물
리적 배치
Object Distribution Modeling
System 관심 대상 Object들에 대해 참조의 지역성을 파악
관련 Object 집합에서 교류 Pattern을 파악하고 교류 정도가 높은 Object끼리 모음
Node별 부하 균형을 고려하여 분산
보안, 취약성, Service 품질을 고려하여 Object 분산을 재 배치
배치도의 Node로 Object를 중첩 시키거나 꼬리표 값으로 Object 위치를 명시적 표기
o : Order
s : Sales
{location = Workstation}
{location = Workstation}
a : ObserverAgent
{location = Server}
p : Product
{location = Server}
Kwangju University
UML 사용자 지침서
p : ProductTable
{location = DataWarehouse}
235
보편적 모델링 기법(계속)
이주 객체(Object that Migrate) Modeling
분산 System 하에서 Class 들이 서로 다를 Node로 이동
Object 들이 보다 좋은 결과를 산출하기 위해
Node의 연결 실패, Node의 균형 잡힌 부하를 위하여
Object Migrate Modeling
물리적 Object들을 전송할 기반 Mechanism 선택
한 Node에 Object를 할당 시키되 꼬리표 값으로 위치를 명시적 표시
Stereotype Message인 Become, Copy를 이용하여 한 Object를 새로운 Node에 할당
동기화 문제와 고유성 문제를 숙고
1 : bid( )
t : TravelAgent
: Auctioneer
{location = United server}
{location = United server}
1.1 : <<become>>
2 : bid( )
t : TravelAgent
: Auctioneer
i : Itinerary
{location = client server}
{location = SAS server}
2.1 : <<become>>
3 : bid( )
t : TravelAgent
: Auctioneer
{location = TWA server}
4 : tenderBid( )
{location = SAS server}
{location = TWA server}
3.1 : <<become>>
t : TravelAgent
{location = client server}
Kwangju University
UML 사용자 지침서
236
힌트와 조언
구조가 좋은 시간과 공간 Property
System 행동 요구 획득에 필요 / 충분한 시간, 공간 Property만 표현
Property 사용을 중앙에 위치시켜 찾기 쉽고 바꾸기 쉽게
UML로 시간과 공간 Property를 표현할 때
시간 표시(Message Name)에 의미 있는 명칭 부여
상대 시간 표현식과 절대 시간 표현식을 명확히 구분
공간 Property는 주로 꼬리표 값으로 표현
Kwangju University
UML 사용자 지침서
237
24장. 상태도(Statechart Diagram)
시작하기
용어와 개념
보편적 모델링 기법
반응 객체 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
238
시작하기
상태도 (Statechart Diagram)
State Machine으로 System의 동적 측면 Modeling하는 것으로 반응
(Reactive) Object의 행동 Model을 작성
활동도 와 상태도
활동도(Activity Diagram) : 활동에서 활동으로 가는 제어 흐름을 표현하는 상태도
의 특별한 경우
상태도(Statechart Diagram) : 상태에서 상태로 가는 제어흐름을 표현
Transition
Idle
State
ringing
sendFax
Transmitting
Kwangju University
Event
hangUp
Error
/ printReport
Nested State
Event
Receiving
Connected
headerOk
Processing
checkSumOk
Entry / pickUp
Action
Cleaning up
exit
/
disconnect
Triggerless
Composite State
Transition
UML 사용자 지침서
239
용어와 개념
공통 (Common) Property
다른 Diagram과 마찬 가지로 공통 성질을 공유
내용 (Contents)
상태도에 포함되는 내용
단순 상태(State)와 복합 상태(Composite State)
Event, Action, Transition
Note, Constraint, ..
공통 이용 (Common Use)
동적 측면을 Modeling하는 것은 System Architecture 관점에서 어떤 종류
의 Object에 있는 Event Sequence에 관한 행동을 모형화
반응 객체(Reactive Object) 즉, 사건 중심 객체는 문맥 외부에서 발송된 사
건에 응답하는 것을 Modeling
Kwangju University
UML 사용자 지침서
240
보편적 모델링 기법
반응 객체 (Reactive Object) Modeling
반응 객체 명세화 세 가지 요소
Object가 살아갈 수 있는 안정된 상태
상태에서 상태로 전이를 촉발시키는 사건
상태가 바뀔 떄 일어나는 동작
Reactive Object Modeling
State Machine 문맥 결정
Object의 초기 상태와 종료 상태 결정
Object가 식별 가능한 시간동안 존재할 수 있는 조건을 고려하여 안정된 상태를
결정
Object 생명 주기에서 안정 상태들이 부분적으로 의미 있도록 순서 결정
상태에서 상태로 전이를 촉발시키는 사건 결정
동작을 전이 또는 상태에 첨부하거나, 양쪽 모두에 첨부
하위 상태, 분기, 분할, 합류, 이력 상태를 이용하여 Machine을 단순화 시킬 방안
파악
사건들이 여러 조합으로 발생될 때 모든 상태에 도달될 수 있는가 파악
Object 상태 중에서 어떤 사건이 발생하더라도 상태 밖으로 나갈 수 없는 상태가
없는가 확인
State Machine을 추적해 가면서 사건 순서나 응답이 예상대로인지 확인
Kwangju University
UML 사용자 지침서
241
보편적 모델링 기법(계속)
Waiting
put(c) [c /= ‘< ’]
/ return false
put(c) [c == ‘<‘]
/ return false
GettingToken
put(c) [c == ‘;’]
/ return false
put(c) [c == ‘>’]
/ return false
put(c) [c /= ‘>’]
/ token.append(c); return false GettingBody
put(c) [c /= ‘;’]
/ body.append(c); return false
Kwangju University
UML 사용자 지침서
242
보편적 모델링 기법(계속)
순공학과 역공학 (Forward & Reverse Engineering)
상태도에서 순공학 즉 Model에서 Code 생성하기는 가능
순공학 도구로 작성된 Message Parser Class에 대한 Java Code 예제
Class Message Parser {
public
boolean put (char c) {
switch (state) {
case Waiting :
if (c == ‘< ’ {
state = GettingToken ;
token = new StringBuffer( ) ;
body = new StringBuffer( ) ;
}
break ;
case GettingToken :
if (c == ‘>’)
state = GettingBody ;
else
token.append(c) ;
break ;
Kwangju University
UML 사용자 지침서
case GettingBody :
if (c == ‘;’)
state = Waiting ;
else
body.append(c) ;
return true;
}
return false ;
}
243
보편적 모델링 기법(계속)
StringBuffer getToken ( ) {
return token ;
}
StringBuffer getBody ( ) {
return body ;
}
private
final static int Wating = 0 ;
final static int GettingToken = 1 ;
final static int GettingBody = 2 ;
int state = Waiting ;
StringBuffer token, body ;
역공학은 이론적으로 가능하지만 실용적이지 못 함
Kwangju University
UML 사용자 지침서
244
힌트와 조언
구조가 좋은 상태도
System의 동적 측면을 표현하는데 초점
이해하는데 필수적인 요소만 표현
추상화 수준에 따라 일관성 있게 상세성 제공
형태간 균형 유지
상태도를 작성할 때
명칭 부여는 목적을 전달할 수 있도록
Object의 안정된 상태 Modeling으로부터, 상태에서 상태로 적법한 전이
Modeling을 진행
요소 배열 시 교차되는 선이 최소화 되도록
Kwangju University
UML 사용자 지침서
245
Kwangju University
UML 사용자 지침서
246
단원 6. 아키텍쳐 모델링
25장. 컴포넌트
26장. 배치
27장. 협력
28장. 패턴과 프레임웍
29장. 컴포넌트도
30장. 배치도
31장. 시스템과 모델
Kwangju University
UML 사용자 지침서
247
25장. 컴포넌트(Component)
시작하기
용어와 개념
보편적 모델링 기법
실행 파일과 라이브러리 모델링
테이블, 파일, 그리고 문서의 모델링
API 모델링
소스 코드 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
248
시작하기
Component
Component와 Deployment는 System의 물리적 관점을 Modeling하는 중요 요
소
실행 File, Library, Table, File, document 같이 Node에 존재하는 물리적인
요소를 Modeling하는데 사용
물리적이며 교체 가능한 System의 한 부분
정의가 명확한 Interface로 추상 개념 정의하며 새롭고 호환성있는
Component로 교체하기 쉽게 작성
명칭
kernel32.dll
Kwangju University
UML 사용자 지침서
249
용어와 개념
명칭 (Name)
다른 Component와 구분하기 위한 문자열로 된 명칭이 반드시 필요
단일명과 Component가 속한 Package 명을 앞에 붙인 경로명 사용
Class와 마찬가지로 Tagged Value를 사용하며 구획을 추가 가능
Simple Name
fraudagent.dll
Realizes
FraudAgent
FraudPolicy
PatternSearch
agent.java
Path Name
확장 Component
system::dialog.dll
{version = 2.0.1.75}
Kwangju University
UML 사용자 지침서
250
용어와 개념(계속)
Component 와 Class
Component와 Class는 매우 유사함
Component
Class
명칭
존재
존재
Interface 실현
가능
가능
관계 표현
의존, 연관, 일반화 의존, 연관, 일반화
중첩
가능
가능
Interaction
참여 가능
참여 가능
추상화 단계
논리적
물리적
추상화 정도
상세
속성, 오퍼레이션을
직접 표현
비교적 상세
Interface를 통한
Operation
표현
fraudagent.dll
Componet
Class
FraudAgent
Kwangju University
FraudPolicy
UML 사용자 지침서
PatternSearch
251
용어와 개념(계속)
Component와 Interface
Interface는 Operation의 모음으로써 Class와 Component의 Service를 명세
화 하는데 사용
Component를 함께 묶는 수단으로 Interface를 사용
Interface를 통해 Service를 호출하는 다른Component들과 함께 그
Interface를 실현하는 Component들을 준비
Interface간의 관계 표현
생략된 Icon형으로 표현
Operation을 나타내는 확장된 형태로 표현
Interface 종류
Export Interface : Component가 실현하는 Interface를 말하며 다른 Component
들에 대한 Service로 제공
Import Interface : Component가 사용하는 Interface로써 외부 Component가 포
함한 내용을 의존 사용하는 Interface
Kwangju University
UML 사용자 지침서
252
용어와 개념(계속)
Icon 형태
image.java
component.java
ImageObserver
확장 형태
image.java
Kwangju University
의존
Interface
<<interface>>
ImageObserver
abort : int{final static}
error : int{final static}
imageUpdate( ) : Boolean
UML 사용자 지침서
현실화
component.java
253
용어와 개념(계속)
이진 교차성 (Binary Replaceability)
Component 기반 Operating System의 기본 취지는 이진 교차 가능한 부분들
로 System을 조립하게 하는 것
System을 새로 구축하지 않고 새로운 Component를 추가하거나 존재하는 것
을 교체하여 System을 발전 시킴
Component는 Bit로 된 세계에 있으며 개념적인 것이 아닌 물리적인 것
Component는 교체 가능(같은 Interface를 준수하는 다른 것으로)
다른 Component와 협력하면서 Architecture 또는 기술적 상황에서 사용될
목적으로 존재하는 System의 한 부분
Component는 전해진 Interface를 준수하고 구현
Component 종류
배치(Deployment) Component : 동적 라이브러리(DLL), 실행 File과 같은 것
으로 실행 가능한 System 구성에 필요/충분 한 것
작업 결과(Work Product) Component : 개발 Process의 산출물로써 배치
Compo nent를 생성하는 Source Code File 및 Data File 등이며 개발 작업에
서 만들어진 산출물이며 실행 System을 생성하는데 사용
실행(Execution) Component : 실행 System의 수행 결과로 생성되는
Component
Kwangju University
UML 사용자 지침서
254
용어와 개념(계속)
Component의 구성
Class를 구성하는 것과 같은 방법으로 Component를 Package에 Group화하여 구
성 가능
Component 간의 의존, 연관, 일반화 관계, 구체화 관계를 명기하여 구성 가능
표준 요소
5가지 표준 Stereotype
Executable(실행) : Node에서 실행될 수 있는 Component를 명세화
Library : 정적/동적 객체 Library를 명세화
Table : Database Table을 나타내는 Component를 명세화
File : Source Code 또는 Data를 포함하는 문서를 나타내는 Component를 명세화
Document(문서) : 문서를 나타내는 Component를 명세화
Kwangju University
UML 사용자 지침서
255
보편적 모델링 기법
실행 File과 Library Modeling
System에 포함되는 다수의 실행 File과 이들에 연관된 객체 Library로 구성
실행 File과 Library Model 구성 방법
물리적인 System을 어떻게 분할할 것인가를 확인(기술적, 형상관리, 재사용 측면)
적합한 표준 요소를 사용하여 모든 실행 File과 Library를 Component로 Modeling
Component간 중요한 연결은 Interface로 Modeling
실행 File, Library, Interface 간의 관계를 Model에 표현하고 의존성을 Model에
표현(변화에 대한 영향을 가시화)
dlog.dll
animator.exe
{version = 5.0.1}
raytrce.dll
Kwangju University
render.dll
UML 사용자 지침서
wrfrme.dll
256
보편적 모델링 기법(계속)
Table, File, Document Modeling
부수적 배치 Component로써 Data File, 도움말 File, Script Log File, 초기
화 File, 설치/제거 File 등 을 Component로 표현
Table, File, Document Model 구성
부수적 Component 확인
적합한 Stereotype 등을 이용하여 Component로 Modeling
부수적 Component들과 실행 File, Library, Interface 간의 관계를 Modeling하고
의존성을 Model에 표현(변화에 대한 영향을 가시화)
animator.hlp
dlog.dll
animator.exe
{version = 5.0.1}
animator.ini
render.dll
wrfrme.dll
Shapes.tbl
raytrce.dll
Kwangju University
UML 사용자 지침서
257
보편적 모델링 기법(계속)
API(Application Programming Interface) Modeling
API는 Program 형태로 접합되는 부분을 나타내며 Interface와 Component를
사용하여 Modeling
API Model 구성
System 내에서 Program 형태로 접합되어야 하는 부분을 확인
가시화해야 하는 중요한 Interface Property만 남김
특정 구현 물을 표현할 때에는 각 API의 구현 내역을 Model화
animator.exe
IScripts
{version = 5.0.1}
IRendering
IApplicationIModels
Kwangju University
UML 사용자 지침서
258
보편적 모델링 기법(계속)
Source Code Modeling
Source Code File의 구성을 Modeling
Source Code File 간의 Compile 의존성을 가시화 하거나 개발 경로의 분기,
결합에 따른 File을 분할/집합 등을 가시화
Source Code Model 구성
Compile 의존성과 더불어 개발 Tool 지정 방식에 따른 논리 요소들의 상세 내역을 저
장하는 File을 확인
Model들을 형상 관리 및 Version 제어 Tool과 접목하는 것이 중요하면 꼬리표 값을
이용
개발 Tool이 File들의 해당 관계를 관리하도록 하고 이들의 관계를 문서화할 떄 만
UML 이용
render.cpp
rengine.h
{version = 5.3.7}
render.h
{version = 4.6}
{version = 5.3}
poly.h
{version = 4.1}
Kwangju University
UML 사용자 지침서
colotab.h
{version = 4.1}
259
힌트와 조언
구조가 좋은 Component
System의 물리적인 관점에서 얻어진 것들에 대한 명쾌한 추상 개념 제공
작고 정의가 명확한 Interface 구현
Class 들을 직접 구현하며 해당 Class 들은 Interface가 갖는 의미를 수행
Component 간의 결합도는 상대적으로 낮으므로 의존 관계와 현실화 관계만 이
용
Component를 그릴 때
Interface가 제공하는 Operation을 명시적으로 나타낼 필요가 없으면
Interface Icon 사용
해당 Component의 의미를 이해하는데 필요한 Interface만 표현
Library나 Source Code와 같은 것은 Version을 표현하고 Tagged Value 활용
Kwangju University
UML 사용자 지침서
260
26장. 배치(Deployment)
시작하기
용어와 개념
보편적 모델링 기법
프로세스와 장치의 모델링
컴포넌트 분산 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
261
시작하기
배치 (Deployment)
Node는 Component와 같이 현실 세계의 System의 물리적 관점을 Modeling
하는데 사용되며 어느 정도의 Memory와 자체 처리 능력을 갖는 전산 자원을
표현
Node는 System이 실행되는 H/W의 총체적 구조를 Modeling하는데 사용하
며 Component가 배치될 수 있는 Processor나 장치를 나타냄
S/W 중심 System 설계
논리적 측면 : Class, Interface, Collaboration, Interaction, State Machine
물리적 측면 : Component(논리적 및 물리적 요소의 Package화)
Node(Component들이 배치되고 실행되는 H/W 표현)
명칭
egb_server
Kwangju University
UML 사용자 지침서
262
용어와 개념
명칭 (Name)
다른 Node와 구분하기 위한 문자열로 된 명칭이 반드시 필요
단일명(Simple Name)과 Node가 속한 Package 명을 붙인 경로명(Path Name)
Class와 같이 Node에 Tagged Value사용 가능
단순명
sales
Deploys
pos.exe
contacts.exe
kiosk_7
확장 Node
경로명
Kwangju University
Server::backup
{remoteAdministrationOnly}
UML 사용자 지침서
263
용어와 개념(계속)
Node와 Component
Node와 Component는 매우 유사함
분산(Distribution) Unit : 일체의 Object나 Component가 하나의 Group으
로 Node에 위치할 때
Component
Node
명칭
존재
존재
관계 표현
의존, 연관, 일반화
의존, 연관, 일반화
중첩
가능
가능
Instance
포함
참여 가능
포함
참여 가능
Interaction 참여
실행 구분
표현
System 실행에 참여
Component 실행
서로 다른 논리적 요소들을
Component의 물리적 배치
물리적으로 Package화
Component
contacts.exe
Kwangju University
pos.exe
sales
UML 사용자 지침서
Node
264
용어와 개념(계속)
Node의 구성
Node를 Package로 Group화 하여 구성
Node 간의 의존, 일반화, 연관 관계로 Node들의 관계 표현
연결 (Connection)
Node간의 관계를 표현하며 연관 관계가 일반적 임
연관 관계는 Ethernet, Serial Line, Shared Bus 등과 같은 Node간의 물리
적 연결을 표현
kiosk
<<10-T Ethernet>>
RAID farm
server
console
Kwangju University
<<RS-232>>
연결
UML 사용자 지침서
265
보편적 모델링 기법
Processor와 장치의 Modeling
독립형 System, 내장 System, Client/Server System, Distribution
System 등의 형태를 구성하는 Processor(Component를 수행할 처리 능력을
갖는 Node) 와 장치 (처리 능력을 갖지 않는 Node)를 Modeling
Processor와 장치를 Modeling 하려면
System의 Deployment View에 있는 Computing 요소들을 확인하고 각각을 Node화
일반적인 Process와 장치를 표현하면 Stereotype을 적용하여 설명
각 Node에 적용할 수 있는 Attribute와 Operation을 고려
<<10-T Ethernet>>
kiosk
<<processor>>
server
RAID farm
<<RS-232>>
console
Kwangju University
UML 사용자 지침서
266
보편적 모델링 기법(계속)
Component Distribution Modeling
System을 구성하는 Processor와 장치들에 설치된 Component들의 물리적인
분산을 가시화, 명세화 하여 System의 전반적인 구조를 Modeling
Component 분산을 Modeling 하려면
System에 존재하는 중요한 Component를 Node에 배치
여러 Node의 Component들을 중복 배치하는 것을 고려
배치의 방법을 선택
Component 배치를 나타내지 않고 각 Node의 명세서에만 보존
의존 관계를 사용하여 해당 Node가 배치하는 Component와 각 Node를 연결
Node를 표시하는 요소에 새로운 구획을 추가하여 배치되는 Component를 나열
: kiosk
Deploys
user.exe
c : console
Deploys
admin.exe
config.exe
Kwangju University
<<10-T Ethernet>>
s : server
processorSpeed = 300mHz
memory = 128M
<<RS-232>>
: RAID farm
Deploys
dbadmin.exe
tktmstr.exe
UML 사용자 지침서
267
힌트와 조언
구조가 좋은 Node
해결 영역의 H/W에 나타나는 어휘에서 얻어진 것들의 명확한 추상 개념 제
공
Model을 만든 목적을 전달하기에 필요한 수준까지만 분해
Modeling하려는 Domain에 적합한 Attribute와 Operation만 표현
Node에 위치하는 Component들을 직접 배치
실 System의 전체 구조를 반영하는 형태로 다른 Node들과의 연결을 고려
UML에서 Node 작성시
Project나 전체 조직을 대상으로 Stereotype들을 적합한 Icon으로 정의
주어진 상황에서 해당 Node의 의미를 이해하기에 적합한 Attribute와
Operation만을 표현
Kwangju University
UML 사용자 지침서
268
27장. 협력(Collaboration)
시작하기
용어와 개념
보편적 모델링 기법
쓰임새(Use Case)의 실체화 모델링
오퍼레이션의 실체화 모델링
메커니즘 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
269
시작하기
협력 (Collaboration)
협력은 Class, Interface 그리고 다른 요소들로 이루어진 공동체를 말하며 각
부분의 모든 행동을 합한 것 보다 큰 공동의 행동을 제공하기 위하여 함께 동
작
협력을 사용하여 Use Case와 Operation의 현실화(Realization)를 상세히 기술
하며, Architecture에서 중요한 System Mechanism을 Modeling
분류자(Class, Interface, Component, Node, Use Case, …)나 Operation과
같은 요소가 실현되는 방법을 기술하는 명세서
실현은 특정 역할을 담당하는 분류자와 그들 간의 연관관계에 의해 이루어 짐
패턴(Pattern) : 특정 상화에서 공통적 문제에 대한 공통적 해법
Idiom : Program을 작성하는 공통 방법
Mechanism : System Architecture의 개념적인 Group을 나타내는 설계 Pattern
Framework : 특정 Domain 내에서 Application 작성을 위하여 확장 가능한
Template를 제공하는 Architecture Pattern
Inter-node
messaging
Kwangju University
명칭
UML 사용자 지침서
270
용어와 개념
명칭 (Name)
다른 협력과 구분하기 위한 문자열로 된 명칭이 반드시 필요
단일명(Simple Name)과 협력이 속한 Package 명을 붙인 경로명(Path Name)
구조 (Structure)
협력의 두 가지 관점
구조적 부분 : 협력을 수행하기 위해 함께 동작하는 Class, Interface, Component,
Node 등과 같은 다른 요소들과의 조합 관계를 표현
행동적 부분 : 요소들이 교류하는 방법의 동적인 관점을 명세화
Role
다중성
mailbox
Queue
*
addMessage( )
removeMessage( )
count( )
*
TransportAgent
Interface
sender
received
IDistributed
sendMessage( )
연관
일반화
IncomingQueue
Kwangju University
1
*
Message
ID
header
body
의존
OutgoingQueue
UML 사용자 지침서
271
용어와 개념(계속)
행동 (Behavior)
협력의 행동적인 부분은 Interaction Diagram으로 표현
교류도는 Message들로 이루어지는 행동을 나타내고 있는 교류를 명세화하고
Message들은 지정된 목적을 수행하기 위해 특정 상황에서 Object들 간에
주고 받는 것
Actor
Instance
: Message
: OutgoingQueue
create
addMessage
: TransportAgent
Message
removeMessage
Lifeline
Focus of Control
Kwangju University
UML 사용자 지침서
Note
Transport agents
periodically remove
message from their
assigned queues,
according to their
scheduling policies.
272
용어와 개념(계속)
협력의 구성
적당한 크기와 정상적인 개수의 협력을 구성해야
협력의 두 가지 관계
현실화(Realization) 관계
정제(Refinement) 관계
Place
order
Use Case
Realization
Collaboration
Order
Management
<<refine>>
Refinement
Order
Validation
Kwangju University
UML 사용자 지침서
273
보편적 모델링 기법
Use Case의 현실화 Modeling
Use Case들의 구체적인 구조와 행동을 현실화
Use Case 현실화 Modeling
Use Case가 갖는 의미를 수행하는데 충분하면서 필요한 구조 요소 확인
구조 요소들의 구성을 파악하여 Class Diagram으로 표현
Use Case가 나타내는 개별적인 Scenario를 고려
Scenario의 동적인 활동을 파악하여 Interaction Diagram으로 표현
구조 요소와 행동 요소들을 하나의 협력으로 구성하면서 현실화 관계를 이용하여
해당 Use Case와 연결
Detect
card fraud
<<include>>
Place
order
Customer
Order
Management
<<include>>
Validate
transaction
Generate
bill
Kwangju University
UML 사용자 지침서
274
보편적 모델링 기법(계속)
Operation의 현실화 Modeling
Object들이 협조해야 하는 Operation들에 대하여 Code화하기 전에 협력을
통한 구현 Model을 작성하는 것
Operation 특유의 Parameter, Return Value 그리고 Object들은 해당
Operation의 현실화에 필요한 상황을 제공
Operation 현실화 Modeling
Operation에 나타나는 Parameter, Return Value, Object를 확인
일반적인 것이면 Code 형태로 구현하여 Model과 별개로 기록 유지 또는 Note 이
용
Algorithm 집약적이면 Activity Diagram을 이용하여 현실화를 Model에 표현
복잡하거나 상세 설계가 필요하면 구현을 협력으로 표현하고 Class Diagram과
Interaction Diagram을 활용하여 협력의 구조적 부분과 행동적 부분을 학장
RenderFrame
setContents
render
progress
Kwangju University
Ray trace
return
(totalPolygons - renaming) /
totalPolygons
UML 사용자 지침서
275
힌트와 조언
구조가 좋은 Collaboration
구조적 관점과 행동적 관점 모두로 구성
System에서 식별이 가능한 교류에 대하여 명쾌한 추상 개념을 제공
다른 협력이 갖는 구조 요소들과 중복되게 표현
이해하기 쉽고 간단하게
UML로 협력을 그릴 때
다른 협력, 분류자, Operation, System 전체에 대한 관계를 이해할 필요가
있을 때에만 협력을 명시
분류자나 Operation별로 협력을 구성하거나, System 전체와 연관되는
Package에 포함
Kwangju University
UML 사용자 지침서
276
28장. 패턴과 프레임웍(Pattern & Framework)
시작하기
용어와 개념
보편적 모델링 기법
설계 패턴 모델링
아키텍쳐 패턴 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
277
시작하기
패턴과 프레임웍 (Pattern & Framework)
Pattern : 주어진 상황에서 공통적으로 발생하는 문제에 대하여 공통적으로
적용할 수 있는 Solution
Mechanism : 설계 Pattern으로써 Class들로 이루어진 공동체에 적용
Framework : Architecture Pattern으로써 특정 Domain의 Application들을
위해 확장 가능한 Template를 제공
Pattern을 이용하여 System Architecture를 형성하는 Mechanism과
Framework을 명세화
Pattern의 사용자가 조정할 수 있는 동전 구멍(Slot), 줄(Tab), 손잡이
(Knob), 숫자판(Dial)을 사용하여 접근이 쉽게 작성
<<framework>>
Receivable
Framework
Mechanism
Billing
Reconciliation
Kwangju University
UML 사용자 지침서
278
용어와 개념
Pattern과 Architecture
Model-View-Controller Patter을 사용하여 추상 개념들을 구성하는 것이 좋은 방
법
설계 Pattern은 Class들로 이루어진 공동체가 갖는 구조와 행동을 명세화
(Mechanism)
Architecture Pattern은 전체 System의 구조와 행동을 명세(Framework)
Mechanism
설계 Pattern의 다른 명칭이며 Class로 이루어진 공동체에 적용
Mechanism의 두 가지 표현
일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 지정
일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 Template
으로 지정
Template
TaskQueue Subject
Subject
Observer
Bind
SliderBar
Kwangju University
Observer
Observer
Collaboration
Role
UML 사용자 지침서
279
용어와 개념(계속)
Framework
Architecture Pattern이며 Domain에 있는 Application들을 위한 확장 가능
한 Template을 제공
Mechanism보다 규모가 크며 Mechanism을 포함하는 Micro Architecture의
일종
Bind
Pacemaker
<<framework>>
CyclicExecutive
Framework
Client
Handler
EventHandler
Collaboration
CommonEvents
Kwangju University
UML 사용자 지침서
280
보편적 모델링 기법
설계 Pattern Modeling
설계 Pattern은 Parameter 협력으로 표현되며, Pattern은 추상 개념을 제공
하고, 추상 개념들이 갖는 구조와 행동은 함께 동작하여 일부 유용한 기능을
수행
Parameter들은 해당 Pattern의 사용자가 반드시 결합 시켜 주어야 하는 요
소들을 지정
설계 Pattern Modeling
공통적인 문제에 대한 공통 해법을 찾고 이를 Mechanism으로 구체화
Mechanism을 구조적이고 행동적인 관점을 제공하는 협력으로 Model화
지정된 상황에 있는 요소들과 반드시 결합하여야 하는 설계 Pattern 요소들을 확인
하고 이들 협력의 Parameter로 표현
Client
Command
Application
Client
Invoker
Receiver
Command
PasteCommand
Command
Command
OpenCommand
Invoker
MenuItem
Kwangju University
UML 사용자 지침서
Receiver
Document
281
보편적 모델링 기법(계속)
설계 Pattern의 구조적 관점 Modeling
Client
Command
Invoker
execute( )
addCommand( )
Receiver
receiver
action( )
설계 Pattern의 행동적 관점 Modeling
: Client
c : Command
: Invoker
: Receiver
new
storeCommand(c)
execute( )
action( )
Kwangju University
UML 사용자 지침서
282
보편적 모델링 기법(계속)
Architecture Pattern Modeling
Framework은 Stereotype으로 지정된 Package로 표현, 하나의 Package로
써 필요한 요소(Class, Interface, Use Case, Component, Node,
Collaboration, 다른 Framework)들을 제공
줄(Tab) : 요소들 중에서 일부가 공용(Public) 타입이 되어Client가 의존할 수
있는 자원으로 표현(추상 개념들과 Framework을 연결)
동전 구멍(Slot) : 공용 요소의 일부는 설계 Pattern이 되고 Client가 결합하
는 자원을 표현하며 이는 설계 Pattern과 결합할 때 채워짐
요소들 중 일부는 보호 타입, 전용 타입으로써 Capsule화 된 Flamework 요
소들을 나타내며 이들은 외부 View에서 접근할 수 없도록 감추어져 있음
Architecture Pattern Modeling
현존하면서 검증된 Architecture에서 Framework을 도출
Stereotype으로 지정된 Package로 Framework의 Model 작성
Framework을 설계 Pattern과 협력의 형태로 변경하는데 필요한 Slot, Tab, Knob,
Dial을 표현
Kwangju University
UML 사용자 지침서
283
보편적 모델링 기법(계속)
<<framework>>
Blackboard
Knowledge Source
Blackboard
Control
Blackboard
Knowledge Source
Reasoning engine
Apply new knowledge
source
Kwangju University
UML 사용자 지침서
284
힌트와 조언
구조가 좋은 Pattern
공통적인 방법으로 공통적인 문제를 해결
구조적 관점과 행동적 관점 모두 구성
Slot, Tab, Knob, Dial을 나타내고 해당 관점들을 다시 표현하여 특정 상황
에 적용 가능하도록
원자적(더 작은 Pattern으로 분할되지 않는 것) 구성
System에 있는 개별적인 추상 내역들을 횡적으로 분할
UML로 Pattern을 그릴 때
해당 상황에 적용하기 위해 변경해야만 하는 Pattern 요소들을 표현
Pattern의 변경은 물론 이를 사용하기위해 필요한 Use Case를 제공하여 해
당 Pattern에 접근이 용이하도록
Kwangju University
UML 사용자 지침서
285
29장. 컴포넌트도(Component Diagram)
시작하기
용어와 개념
보편적 모델링 기법
소스 코드 모델링
실행 배포판 모델링
물리적 데이터베이스 모델링
적응력 있는 시스템 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
286
시작하기
Component Diagram
Component들 간의 구성과 의존을 정적인 Implementation View로 Modeling
실행 File, Library, Table, File, Document 같은 Node에 존재하는 물리적인
구성 요소들을 Modeling
본질적으로는 Class Diagram이며 System의 Component에 관점을 둠
Page
find.html
실행 File
fine.exe
<<hyperlink>>
index.html
neteng.dll
dbacs.dll
Component
Kwangju University
Library
UML 사용자 지침서
287
용어와 개념
공통 Property
다른 Diagram들과 동일한 공통 Property를 공유하며 Component의 관계를 표
현하며 Graphic으로는 꼭지점(Vertices)와 호(Arc)를 사용
내용 (Content)
공통적 포함 내용
Component
Interface
Relationship : Dependency, Generalization, Association, Realization
Note와 Constraint를 포함
Package 또는 Sub-System 포함 가능
공통적 사용
System 각 부분의 Configuration Management를 지원하는 정적인
Implementation View 작성에 활용
Kwangju University
UML 사용자 지침서
288
보편적 모델링 기법
Source Code Modeling
Source Code File들과 그들의 관계를 Modeling
Source Code Modeling
중요한 Source Code File을 확인(Stereotype으로 지정된 Component로 Modeling)
System이 큰 경우에는 Package를 활용하여 Source Code File들을 Group화
Source Code File의 Version No., 작성자, 변경일자 등을 Tagged Value로 표현
의존 관계를 사용하여 File들 간의 Compile 의존성을 모형화
signal.h
{version = 3.5}
signal.h
<<parent>>
{version = 4.0}
signal.h
{version = 4.1}
<<parent>>
signal.cpp
{version = 4.1}
interp.cpp
interp.cpp
Kwangju University
interp.cpp
UML 사용자 지침서
289
보편적 모델링 기법(계속)
실행 배포판(Executable Release) Modeling
완전하고 모순 없는 산출물을 내부/외부에 인도하기 위한 Modeling
고유한 각 Application을 공유할 수 있도록 하며 분산 System에서 흩어져 있
는 많은 실행 File들 및 구성 요소들을 적절하게 배치(Deployment)하기 위한
도해
실행 배포판 Modeling
Model로 작성할 Component 확인
각 Component에 대해 Stereotype 고려
각 Component에 대해 인접한 Component와의 관계를 고려
path.dll
collision.dll
driver.dll
{version = 8.1.3.2}
IDrive
ISelfTest
Kwangju University
UML 사용자 지침서
290
보편적 모델링 기법(계속)
물리적(Physical) Database Modeling
논리적(Logical) Database Schema : System에서 보존할 Data의 관계가 갖
는 의미와 함께 그들의 어휘에서 파악되는 저장 정보를 파악
물리적(Physical) Database Schema : 논리적 Database Schema를 저장 자
료구조의 특성을 고려하여 System에 저장하기위한 정보 구조로 변환하는 것
이며 논리적 Database Schema에 정의된 Operation들을 Mapping
물리적 Database Modeling 전략
각 Class 당 하나의 Table을 별도로 지정
상속 관계를 제거하고 상속 계층에 속하는 Class들의 모든 Instance가 같은 상태
(State)를 갖도록(Instance들에 불필요한 정보가 저장될 수 있음)
Parent와 Child 상태를 서로 다른 Table로 분리(교차적인 Table Join이 많이 발생)
논리적 Operation들이 구현되는 방법
단순한 CRUD Operation의 경우는 표준 SQL 또는 ODBC 호출로 구현
복잡한 행동(업무 규칙)들은 Trigger 또는 Stored Procedure로 Mapping
Kwangju University
UML 사용자 지침서
291
보편적 모델링 기법(계속)
물리적 Database Modeling
논리적 Database Schema를 나타내는 Class를 확인
Class들을 Table로 Mapping하기 위한 전략을 선택
Mapping 시킨 내역을 가시화, 명세화, 구축, 문서화하기 위한 Stereotype 지정
가능하면 Tool을 이용
school.db
course
Kwangju University
department
instructor
UML 사용자 지침서
school
student
292
보편적 모델링 기법(계속)
적응력 있는 System Modeling
Component Diagram은 정적인 표현만을 표현하나 경우에 따라서는 다른
UML 일부 Diagram(Object Diagram, Interaction Diagram)들과 결합 사용
하여 동적인 표현을 가능하도록
적응력 있는 System Modeling
Node에서 Node로 이동할 수 있는 Component들의 물리적인 분산을 고려(위치를
꼬리표 값으로 표현, Component Instance의 위치 명세화)
Component의 이동을 초래하는 활동들을 Model화 하려면 Component Instance를
포함하는 Interaction Diagram 생성
The school database
on Server B replicates
the database on Server A.
: school.db
: school.db
{location = Server A}
{location = Server B}
<<copy>>
Kwangju University
UML 사용자 지침서
293
보편적 모델링 기법(계속)
순공학과 역공학
Component Diagram 순공학
각 Component에 대해 해당 Component가 구현하는 Class나 Collaboration을 파악
해당 Component를 어느 것으로 순공학 처리할 것인가를 결정
가능하면 Tool을 사용
Component Diagram 역공학
역공학 대상을 선택
Tool을 활용하여 역공학 하려는 Code를 지정
Tool을 사용하여 Model을 질의(Query) 하는 형식으로 Component Diagram 생성
DataBinding
DataObject
vbrun.dll
ContainedControls
PropertyBag
ParentControls
AsyncProperties
SelectedControls
DataObjectFiles
Kwangju University
HyperLink
DataBindings
UML 사용자 지침서
AmbientProperties
294
힌트와 조언
구조가 좋은 Component Diagram
System의 정적 구현 View 중에서 한가지 관점에만 초점
해당 관점을 이해하는데 꼭 필요한 요소들만 포함
내용을 이해하는데 꼭 필요한 장식(Adornment)만을 포함하여 해당 내용 추
상화 수준과 일치하는 상세 내역 제공
너무 적지 않으며 충분한 내용을 포함하고 있어서 의미를 이해하기에 부족하
지 않도록
Component Diagram을 그릴 때
목적을 잘 알 수 있는 명칭 사용
교차선이 최소화 되도록 요소를 적절히 배치
의미적으로 밀접한 것들이 서로 가까이 존재하도록 공간을 활용한 배치
시각적 효과를 충분히 나타내도록(Note, Color, …)
Stereotype으로 지정된 요소들을 주의해서 사용
Kwangju University
UML 사용자 지침서
295
30장. 배치도(Deployment Diagram)
시작하기
용어와 개념
보편적 모델링 기법
내장 시스템 모델링
클라이언트 / 서버 시스템 모델링
완전 분산 시스템 모델링
순공학과 역공학
힌트와 조언
Kwangju University
UML 사용자 지침서
296
시작하기
배치도 (Deployment Diagram)
Component Diagram과 함께 System의 물리적 관점을 Modeling하는 Diagram
실행 처리 능력을 갖는 Node의 구성과 해당 Node에 존재하는 Component 들을
표현
본질적으로 Class Diagram이며 System Node(실행되는 H/W의 형태 Modeling)
에 초점을 두어 정적인 관점을 가시화
Internet
Connection
Node
Modem bank
<<processor>>
caching server
<<processor>>
caching server
Node
<<network>> local network
<<processor>>
primary server
Kwangju University
<<processor>>
server
<<processor>>
server
UML 사용자 지침서
<<processor>>
server
297
용어와 개념
공통 Property
다른 Diagram들과 동일한 공통 Property를 공유하며 Node에 존재하는
Component 의 구성을 나타내며 Graphic으로는 꼭지점(Vertices)와 호(Arc)를 사
용
내용 (Content)
공통적 포함 내용
Node
Relationship : Dependency, Association
Note와 Constraint를 포함
Package 또는 Sub-System 포함 가능
공통적 사용
물리적 System 구성 부분들의 분산, 인도, 설치를 다루는 정적인 Deployment
View 작성에 활용
다수의 Processor에 걸쳐 분산되어 있는 장치들과 교류하는 S/W를 개발하고자
하는 경우 S/W를 H/W로 Mapping하는 것을 쉽게 표현
Kwangju University
UML 사용자 지침서
298
보편적 모델링 기법
내장(Embedded) System Modeling
물리적인 세계와 Interface하는 H/W와 S/W를 집약
내장 System을 구성하는 장치와 Processor를 Modeling
Project에 참여하는 H/W Engineer와 S/W 개발자간의 의사 소통을 용이하게
내장 System Modeling
System의 고유한 장치와 Node를 확인
확장 Mechanism을 활용하여 System 특유의 Stereotype을 적절한 Icon으로 정의
Processor와 장치들 사이의 관계를 배치도에 Modeling
자체 처리 능력을 갖는 장치들에 대해 Model을 확장하되, 더 상세한 배치도로 구조를
Modeling
Timer
Serial I/O port
Ultrasonic
sonar sensor
<<RS232>>
Digital I/O port
8
<<processor>> Rigth position encoder
Left position encoder
Pentium
motherboard
M
Steering Motor ~
Kwangju University
M
Drive Motor
~
UML 사용자 지침서
299
보편적 모델링 기법(계속)
Client/Server System Modeling
System의 사용자 Interface(Client)와 보존 Data(Server)간의 관계를 분명
하게 구분하며 Network 연결 및 Node에 걸쳐 존재하는 S/W Component의
물리적 분산 표현
Client/Server System Modeling
System의 Client와 Server Processor를 나타내는 Node 확인
System의 행동과 밀접한 관계가 있는 장치들에 중점을 두고 배치에 중점을 둠
Stereotype을 이용하여 해당 Processor와 장치들을 시각적으로 가시화
Node의 형태를 배치도에 표현(배치 View에 있는 Component와 Node 관계 명세)
Server
Client
console
Kwangju University
kiosk
2..*
<<processor>>
caching server
Deploys
http.exe
rting.exe
UML 사용자 지침서
4..*
<<processor>>
server
Deploys
dbadmin.exe
tktmstr.exe
logexc.exe
300
보편적 모델링 기법(계속)
완전 분산 System Modeling
다단계 Server를 포함하여 광범위하게 분산되어 있는 System을 명세화
두개 이상의 Processor로 구성된 System으로부터 지리적으로 널리 산개된
Node들을 연결하는 표현
완전 분산 System Modeling
System의 장치와 Processor를 확인
System Network의 성능 또는 Network 변화에 따른 영향 등을 파악한 통신 장치
Model 작성
Node 들을 논리적으로 분류하기 위한 Package의 활용
장치 들과 Processor들을 배치도에 Model로 표현
동적 활동에 초점을 두려면 Use Case Diagram으로 활동을 명세화하고
Interaction Diagram을 이용하여 상세화
console
console
console : Internet
Kwangju University
: regional
server
: regional
server
: regional
server
UML 사용자 지침서
Note : country servers
are reachable to one
another via the company’s
private network
: country
server
: logging
server
301
힌트와 조언
구조가 좋은 Deployment Diagram
System의 정적인 배치 View 중에서 한가지 관점에만 초점
해당 관점을 이해하는데 꼭 필요한 요소들만 포함
내용을 이해하는데 꼭 필요한 장식(Adornment)만을 포함하여 해당 내용 추
상화 수준과 일치하는 상세 내역 제공
너무 적지 않으며 충분한 내용을 포함하고 있어서 의미를 이해하기에 부족하
지 않도록
Deployment Diagram을 그릴 때
목적을 잘 알 수 있는 명칭 사용
교차되는 선이 최소화 되도록 요소를 적절히 배치
의미적으로 밀접한 것들이 서로 가까이 존재하도록 공간을 활용한 배치
시각적 효과를 충분히 나타내도록(Note, Color, …)
Stereotype으로 지정된 요소들을 주의해서 사용
Kwangju University
UML 사용자 지침서
302
31장. 시스템과 모델(System & Model)
시작하기
용어와 개념
보편적 모델링 기법
시스템 아키텍쳐 모델링
시스템의 상위 시스템 모델링
힌트와 조언
Kwangju University
UML 사용자 지침서
303
시작하기
System 과 Model
UML은 S/W 중심의 System 산출물을 가시화, 명세화, 구축, 상세화 하는 것
UML을 이용하여 System Model을 단계적으로 작성
구조가 좋은 System : 기능적, 논리적, 물리적으로 응집력이 좋고 결합력이 약
한 Sub-System으로 형성
구조가 좋은 Model : 서로 다른 Model이 상호 관계를 유지하며 복잡한
System을 간결하고 이해하기 쉽게 표현
System
<<subsystem>>
Customer Service
Subsystem
Kwangju University
<<system>>
Retail Enterprise
System
<<subsystem>>
In Store
Management
Subsystem
UML 사용자 지침서
Subsystem
<<subsystem>>
Warehouse
Management
Subsystem
304
용어와 개념
System과 Subsystem
System : 개발 또는 Modeling하려는 주체이며 특정 목적을 얻기 위해 구성된 요
소들로 되어 있으며 서로 다른 관점을 갖고 있는 Model들로 기술
Subsystem : System의 한 부분이며 복잡한 System을 상호 독립적인 부분들로
분해하는데 사용
System과 Subsystem 간의 기본적 관계는 Aggregation 관계이며
Generalization 관계를 갖을 수도 있으며 전체 System은 Zero 또는 그 이상의
Subsystem을 포함
Model과 View
Model은 현실을 단순화 한 것이며 System을 추상화하는 것으로 System의 범위
내에 정의
Model은 특별한 종류의 Package로써 구성 요소들을 소유
View는 Model에 대한 투영(Projection)이며 Model이 갖는 것들에 대한 부분 집
합으로써 Model간의 경계를 무시하고 표현할 수는 없음
추적 (Trace)
서로 다른 Model에 존재하는 요소들 간의 개념적 관계를 추적 관계로 Modeling
Kwangju University
UML 사용자 지침서
305
보편적 모델링 기법
System Architecture Modeling
System 요구 사항, 논리적 요소, 물리적 요소를 파악하고 결정하여 표현
System과 Pattern이 갖는 구조적이고 행동적인 관점을 Model 화
System Architecture Modeling
Architecture를 표현하기 위하여 어떠한 View를 사용할 것인가를 확인
System과 관련 있는 Actor를 포함해서 해당 System의 상황(Context)를 명세화
필요하면 System을 Subsystem으로 분해
어휘
기능성
설계 뷰
(Design View)
구현 뷰
시스템 조립
(Implementation View) 형상관리
쓰임새 뷰
(Use Case View)
성능
확장성
처리량
프로세스 뷰
(Process View)
논리적
Kwangju University
배치 뷰
(Deployment View)
시스템 구성 형태
분산, 인도, 설치
물리적
UML 사용자 지침서
306
보편적 모델링 기법(계속)
System과 Subsystem에 대해 수행해야 할 일
System의 Use Case View를 명세화 : 최종 사용자, 분석가, Test 담당자 등이
보는 System 행동을 설명. Use Case Diagram을 적용하여 정적인 관점을
Modeling하고 Interaction Diagram, Statechart Diagram, Activity
Diagram을 적용하여 동적인 관점을 Modeling
System의 Design View를 명세화 : 문제 영역과 해법의 어휘를 형성하는 Class,
Interface, Collaboration을 포함. Class Diagram, Object Diagram을 적용하
여 정적인 관점을 Modeling하고 Interaction Diagram, Statechart Diagram,
Activity Diagram을 적용하여 동적인 관점을 Modeling
System의 Process View를 명세화 : 동시성(Concurrency)과 동기화
(Synchronization) Mechanism을 형성하는 Thread와 Process를 포함. Design
View와 동일한 Diagram을 적용하되 Thread와 Process를 나타내는 활성 Class
와 Object에 초점을 둠
System의 Implementation View를 명세화 : 물리적인 System을 조립하고 배
포하는데 사용되는 Component를 포함. Component Diagram을 적용하여 정적
인 관점을 Modeling하고 Interaction Diagram, Statechart Diagram,
Activity Diagram을 적용하여 동적인 관점을 Modeling
Kwangju University
UML 사용자 지침서
307
보편적 모델링 기법(계속)
System의 Deployment View를 명세화 : System이 실행되는 H/W 형태
를 나타내는 Node를 포함. Deployment Diagram을 적용하여 정적인 관
점을 Modeling하고 Interaction Diagram, Statechart Diagram,
Activity Diagram을 적용하여 동적인 관점을 Modeling
Collaboration을 이용하여 해당 Model들의 Architecture Pattern과
Design Pattern을 Model화
System Architecture는 한번의 Big-Bang으로 만들어질 수 없으며 지속적인
반복, 점진적 발전을 통해 정제(Refinement) 됨
System의 상위 System Modeling
특정 추상화 수준에 있는 System은 더 높은 추상화 수준에 있는 System의
Subsystem으로 표현
System 또는 Subsystem의 Modeling
독립적으로 개발, 배포, 배치될 수 있는 System의 주요 기능들을 확인
각 Subsystem에 대해 해당 상황들을 명세화
각 Subsystem에 대한 Architecture를 Modeling
Kwangju University
UML 사용자 지침서
308
힌트와 조언
구조가 좋은 Model
Model간 독립된 관점에서 현실을 단순화
자체 Model에 필요한 모든 내용을 포함
결합도가 낮게 다른 Model과의 추적 관계 유지
System에서 필요로 하는 산출물들을 완전하게 표현
구조가 좋은 System
기능적, 논리적, 물리적으로 응집
독립적인 Subsystem으로 분해될 수 있고, Subsystem들은 더 낮은 추상화
수준의 System으로 표현
상호 연관적이면서도 중복되지 않는 Model들에 의하여 가시화, 명세화, 구축,
문서화
UML로 System이나 Subsystem을 표현 할 때
System이나 Subsystem에 연관되는 모든 산출물들을 작성하기위한 시작점
으로 각각을 서로 이용
System과 Subsystem간의 기본적인 집합 연관 만을 표현
Kwangju University
UML 사용자 지침서
309
Kwangju University
UML 사용자 지침서
310
단원 7. 마무리
32장. UML의 적용
Kwangju University
UML 사용자 지침서
311
32장. UML의 적용
UML로 옮겨 가기
UML 참고 자료
Kwangju University
UML 사용자 지침서
312
UML로 옮겨 가기
UML의 사용
UML을 사용하려 할 때 접근하는 방법은 사용자의 경험에 따라 달라
질 수 있음
UML은 단순히 정보 System 관련 Modeling에만 적용되는 것이 아니
라 사람이 생각하고 분석해야 할 것이라면 무엇이든 Model화 할 수
있음
UML로 옮겨 가기
Class, Attribute, Operation, Use Case, Component, Package와
같은 기본 구조 사물들을 Dependency, Generalization, Association
과 같은 구조 관계들과 함께 사용하면 많은 종류의 문제 영역에 대한
정적인 Model을 충분히 생성
단순 State Machine 및 Interaction과 같은 기본 행동 사물들을 추
가하면 System에 유용한 동적 관점들을 Modeling하며 동시성과 분
산을 모형화 하는 것과 같이 보다 복잡한 상황에서는 더 진보된 UML
기능을 사용
Kwangju University
UML 사용자 지침서
313
UML로 옮겨 가기(계속)
Object Oriented에 처음 접할 때
추상화 개념에 익숙해 지도록(CRC Card, Use Case Analysis 등을 숙지
하여 추상 개념을 찾는 능력 개발)
추상 개념들로 이루어진 것들을 가시화하는데 친숙해 지도록 Class,
Dependency, Generalization, Association을 사용하여 간단한 정적인
Model 작성
간단한 Sequence Diagram이나 Collaboration Diagram을 사용하여 문제
영역의 동적인 부분 Model 작성
Object Oriented에 처음 접할 때
추상화 개념에 익숙해 지도록(CRC Card, Use Case Analysis 등
을 숙지하여 추상 개념을 찾는 능력 개발)
추상 개념들로 이루어진 것들을 가시화하는데 친숙해 지도록
Class, Dependency, Generalization, Association을 사용하여
간단한 정적인 Model 작성
간단한 Sequence Diagram이나 Collaboration Diagram을 사용하
여 문제 영역의 동적인
Kwangju University
UML 사용자 지침서
314
UML로 옮겨 가기(계속)
Modeling에 처음 접할 때
개발해 본 경험이 있는 System의 일부를 대상으로 시작
System에 사용했던 Programming Idiom이나 Mechanism의 상태 내역
중 일부에 대하여 UML을 사용해 Model화
복잡한 Application의 경우에는 포함된 주요 요소를 표현하기 위하여
UML의 Package를 이용하여 Application의 Architecture Model을 다시
구축
UML의 익숙해진 후 다른 Project에 UML 적용
Object Oriented 경험이 있을 때
현재의 Modeling Language를 재고하여 내재된 요소들을 UML 요소로
Mapping시키는 방법을 모색
현재의 Modeling Language로 구현이 힘들거나 불가능한 대상을 UML의
진보된 기능을 적용
사용을 잘할 때
UML 개념 Model을 개발
Component, 동시성, 분산, Pattern들을 Modeling하는데 필요한 UML 기
능들을 파악
UML 확장 Mechanism을 자세히 살피고 해당 Domain에 직접 적용할 방
법을 모색
Kwangju University
UML 사용자 지침서
315
UML 참고 자료
UML 참고 자료
The Unified Modeling Language User Guide : Addison Wesley
The Unified Modeling Language Reference Manual : Addison Wesley
The Unified Development Process : Addison Wesley
Object Oriented Analysis and Design : Addison Wesley
Object Oriented Software Engineering : Addison Wesley
Object Oriented Modeling and Design : Addison Wesley
Use Case Driven Object Modeling with UML : Addison Wesley
Use Cases Combined with Booch/OMT/UML : Prentice Hall
Advanced Object Oriented Analysis and Design Using UML : Cambridge
University Press
UML Distilled : Addison Wesley
Object Oriented Analysis : Prentice Hall
Object Oriented Systems Analysis : Yourdon Press
Web Site
www.rational.com
www.omg.org
www.uml.co.kr
www.rational.co.kr y
Kwangju University
UML 사용자 지침서
316