뱅킹 도메인(인터넷 뱅킹, 금융)을 중심으로 UML을 설명한 자료입니다.

1. 1
Beginning the UML
in Banking Domain
COPYRIGHT © 2003 Lee Juhyeon All Right Reserved.
Date : 2003.8.26
Author : Lee Juhyeon
Email : jhlee@jsummit.com
Homepage : http://www.jsummit.com

2. 2
1. UML
Beginning the UML
S/W
청
사
진
작
성
표
준
언
어
가시화
명세화
구축
문서화
SYSTEM
 Unified Modeling Language
 어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현
 프로젝트 구성원 내부 또는 고객과의 의사소통 향상
 시스템을 이해하기 위하여 하나 이상의 모델을 서로 연결 사용
 복합적인 모델로 이해를 증진

3. 3
2. UML의 역사
Beginning the UML
 방법론의 춘추 전국 시대(90년대 초)  주요 세력에 의한 통일화
 Three Amigo - Grady Booch, James Rumbaugh, Ivar Jacobson가 주축
 기존의 방법론 및 표기법의 장점을 흡수
 OMG(Object Management Group)에 의하여 표준화
United
Modeling
Language
Booch
Booch
Gamma
Frameworks, Pattern, Notes
Rumbaugh
OMT
Jacobson
OOSE
Harel
State Charts
Wirfs-Brock
Responsibilities
Shlaer-Mellor
Object life cycles
Meyer
Pre- and post- conditions
Odell
Classfication

4. 4
3. 구성요소
Beginning the UML
구조 사물
Structural Thing
행동 사물
Behavioral Thing
그룹 사물
Grouping Thing
주해 사물
Annotation Thing
사물
(Things)
의존 관계
Dependency
연관 관계
Association
일반화 관계
Generalization
실체화 관계
Realization
관계
(Relationships)
클래스 도
Class Diagram
객체 도
Object Diagram
쓰임새 도
Use Case Diagram
순차 도
Sequence Diagram
협력 도
Collaboration Diagram
상태 도
State Chart Diagram
활동 도
Activity Diagram
컴포넌트 도
Component Diagram
배치 도
Deployment Diagram
도해
(Diagrams)
UML 구성 요소

5. 5
4. Use Case Diagram
Beginning the UML
 System 전체나 Use Case 일부 행동을 명세화하고 순차적으로 발생하는
활동들을 기술
 System 외부의 행위자와 System 내부의 핵심 추상 개념 간의 교류를 표현
 Use Case는 대상 행동의 명세화만을 수행하고 행동 수행 방법은 규정하지 않음
 개발자와 사용자 간 Communication의 도구
 사용자가 시스템을 이해하는 유일한 도구로 외부에서 시스템을 바라보는 관점
 시스템에 대한 요구 사항을 표현

6. 6
4.1. Use Case Diagram - 구성요소
Beginning the UML
 Actor
 System 외부에서 시스템을 작동시키는 모든 것(User, System, Device, etc.)
 명확한 존재 의미가 있어야 함(Role Name으로 표시)
 Use Case와 메시지 교류를 수행
 Use Case
 System이 수행하여야 하는 무엇(what) - 서비스
 해당 서비스를 제공하기 위하여 내부적으로 수행되는 일련의 동작들
 고객 관점에서의 기본적인 요구 사항
고객 계좌이체Role Name

7. 7
4.2. Use Case Diagram – 관계 1
Beginning the UML
 통신 관계(Communication)
 Actor와 Use Case 사이의 메시지 교류 관계
 상호 작용의 의미
 Association으로도 표현
 일반화 관계(Generalization)
 Parent의 속성을 Child가 상속받는 것을 표현
 Actor와 Actor, Use Case와 Use Case 사이의 관계
 객체 지향에서의 일반적인 상속을 의미
고객
개인고객 기업고객
고객
계좌이체

8. 8
4.3. Use Case Diagram – 관계 2
Beginning the UML
 포함 관계(Include)
 여러 Use Case에서 공통의 행위를 독립 Use Case로 구성
 의존 관계이며 use로도 표현
 Component화의 기준점
 확장 관계(Extend)
 조건이 있는 포함 관계로서 사용자가 선택적으로 보는 System의 행동
 특별한 조건에서만 수행되는 부 흐름(sub flow)을 별도로 모형화
기업뱅킹 이체
결재요청승인실행
<<extend>> <<extend>>
개인뱅킹 이체
이체실행
<<include>>
<<include>>

9. 9
4.4. Use Case Diagram – 예제 (요구분석)
Beginning the UML
 논의한 시스템의 요구사항 분석
 고객은 계좌이체를 사용할 수 있다.
 고객은 개인고객과 기업고객으로 구분된다.
 개인고객은 개인뱅킹 이체만을 기업고객은 기업뱅킹 이체만을 사용할 수 있다.
 기업뱅킹 이체는 결재요청과 승인실행으로 분기된다.
 기업뱅킹에서 승인실행을 하는 경우와 개인뱅킹에서 개인뱅킹 이체를 하는
경우에는 공통적인 이체실행을 수행한다.
 Actor 분석
 추상 Actor : 개인고객, 기업고객
 구체 Actor : 개인고객, 기업고객
 Domain 분석
 개인뱅킹, 기업뱅킹
 Use Case 분석
 추상 Use Case : 계좌이체
 구체 Use Case : 개인뱅킹이체, 기업뱅킹 이체, 결재요청, 승인실행, 이체실행

10. 10
4.5. Use Case Diagram – 예제 (Diagram)
Beginning the UML
결재요청승인실행
이체실행
<<include>>
계좌이체
고객
개인고객
개인뱅킹 이체
<<include>>
기업고객
기업뱅킹 이체
<<extend>>
<<extend>>
<<generalize>>
<<generalize>>
<<generalize>>
<<generalize>>

11. 11
4.6. Use Case Diagram – 유의사항
Beginning the UML
 구조화가 좋은 Use Case Diagram
 System의 정적인 Use Case 관점에서 한 부분의 대화에만 초점을 맞춤
 해당 부분을 이해하는데 필수적인 Use Case와 Actor만을 포함
 추상화 수준별로 일관성 있게 상세 사항을 추가
 중요한 의미는 적절한 정도의 크기로 분해
 Use Case Diagram 작성법
 목적을 알 수 있는 명칭의 사용
 교차되는 Line이 가능하면 최소가 되도록 요소를 배치
 행동, 역할, 의미가 연관이 있는 것은 인접하여 배치
 Note 등의 활용으로 가시적 효과를 이용하여 중요한 특성을 부각
 관계는 너무 많이 표현하지 않고 반드시 필요한 것만 표현

12. 12
5. Activity Diagram
Beginning the UML
 흐름도로서 Activity 간의 전달되는 제어 흐름을 표현(발생 활동에 초점)
 객체 간 통과 제어 흐름(operation)을 표현
 하나의 Activity는 몇 개의 Action으로 분리
 기존의 Flow-Chart와 유사
 Activity, State, Flow, Swinlane으로 구성
 유용성
 Use Case 분석
 Work-Flow의 이해
 알고리즘 설명

13. 13
5.1. Activity Diagram – 구성요소 1
Beginning the UML
 State
 활동(Activity에 따른 상태를 표현
 기본적으로 Start State와 End State가 있음
 State 자체는 자주 사용되지 않음
 Activity
 처리할 활동을 의미
 Use Case일 수도 있고, Use Case 내의 흐름일 수도 있음
 Decision
 조건 분기를 의미
 일반적으로 Activity에서 대신함

14. 14
5.2. Activity Diagram – 예시 1
Beginning the UML
 개념 Level의 Activity Diagram
계좌이체 실행
고객이 승인권
자인가?
결재요청 실행
거래 완료
상태
거래 수신
상태
아니오 예
Activity
Decision
Start State
End State
Synchronization
Bar
State

15. 15
5.3. Activity Diagram – Synchronization Bar & Swinlane
Beginning the UML
 Synchronization Bar
 동시에 처리되어야 할 Activity를 표현
 분기(forking) 흐름이 다시 단일화(join)되는 부분에서도 사용
 Work-Flow에서 비동기 처리를 기술할 수 있음
 Swimlane
 Activity Diagram에 구획을 나누기 위하여 사용
 일반적으로 업무 별, 시스템 별, 사용자 별로 구분
 시스템 별로 적용할 경우, 기존 DFD와 유사
 구획 간에 수직선으로 표현

16. 16
5.4. Activity Diagram – 예시 2
Beginning the UML
전문 생성
전문 송수신
송수신 상태
전문 파싱
정상 메세지
생성
요청 메세지
수신
시스템 장애
에러 메세지
생성
응답 리턴
시스템 관리자에게
SMS 발송
비동기 처리
예
아니오
아니오
예

17. 17
5.5. Activity Diagram – 예시 3
Beginning the UML
고객으로부터
입력 수신
고객에게 결과
출력
sub 사용자 이체
한도 확인
결과 메세지
생성
전문 생성
전문 송수신
이체 한도 확인
Procedure 호출
HOST 전문
송수신
UI Tier BL Tier DB Tier 중계 Tier

18. 18
6. Sequence Diagram
Beginning the UML
 흐름도 중의 하나로서, 시간에 따른 객체 간의 message 발생 순서를 표현
 교류를 주도하는 객체를 왼쪽에 배치
 message들을 시간의 흐름에 따라 위에서 아래로 배치
 한 개의 제어 흐름 만을 표현
 객체 modeling이 원칙이나 다양한 정적인 대상(Class, System, etc.)도 표현 가능
 실제 구현 Level에서 중요한 Diagram

19. 19
6.1. Sequence Diagram - 구성요소
Beginning the UML
 Object
 실제 객체의 인스턴스를 표현하는 것이 원칙
 Message
 객체 간 주고 받는 message이며 화살표로 표현
 구현 Level에서는 메소드로 디자인됨
 Lifeline
 특정 시간 동안 객체가 존재하는 것을 표현
 Destroyer
 객체가 소멸되는 시점을 표현하며, X로 표시
 일반적으로 서버 프로그래밍 시에는 선택적으로 사용됨 (Thread Pooling)

20. 20
6.2. Sequence Diagram – 예시 1
Beginning the UML
 개념적 시스템 흐름
고객 UI Business Logic ComServer HOSTDBMS
항목 입력
EJB Request
전문 송신(TCP)
전문 송신(SNA)
전문 응답(SNA)
전문 응답(TCP)
EJB Response
Query 송신
Query 응답
결과 출력
Lifeline
Message

21. 21
6.3. Sequence Diagram – 예시 2
Beginning the UML
고객 UI 계좌이체 이체실행 전문 송수신 통합중계 HOST전문 Logger
이체실행 버튼을 누른다
실행()
이체실행()
송수신()
송수신 에러 확인 및 처리()
에러 여부 확인()
java 객체 --> 전문 변환()
전문 -->java 객체 변환()
결과를 본다
로깅
로깅

22. 22
6.4. Sequence Diagram - 유의사항
Beginning the UML
 Use Case별로 하나씩 작성하는 것이 원칙
 동일한 상호 작용이 유사하게 중복 작성되는 것을 피함
 가독성을 위하여 적당한 Comment 사용
 메시지 흐름은 Actor부터 작성
 numbering을 사용하면 구현 Level에 대한 세밀한 설계가 가능하나,
일반적으로는 기록하지 않음

23. 23
7. Class Diagram
Beginning the UML
 시스템에서 사용되는 클래스를 정의하고, 클래스의 속성과 행위를 표현
 클래스 간의 다양한 관계를 표현
 실제 구현 단계에 가장 접근  Forward Engineering의 기반
 자동화된 Reverse Engineering의 현실적 한계 지점
 정적 Model
 Logical Database Design을 수행 가능

24. 24
7.1. Class Diagram – 구성요소 1
Beginning the UML
 클래스
 Type : 클래스의 이름
 Attribute : 클래스의 속성. C++에서는 member 변수, Java에서는 클래스 변수
 Operation : 클래스의 행동. C++에서는 member 함수, Java에서는 메소드
 클래스 표기 요소
 Stereo Type
 Attribute, Operation의 visibility
 Attribute의 Type
 Operation의 반환 값 유형
고객
id : String
name : String
ssn : String
getId() : String
getName() : String
getSSN() : String
(from UseCase)
<<Actor>> Stereo Type
Visibility
Visibility
Type of
Attribute
Type of
Operation
고객
id : String
name : String
ssn : String
getId()
getName()
getSSN()
Attribute
Operation
Type (Name)

25. 25
7.2. Class Diagram – 구성요소 2
Beginning the UML
 하나의 클래스도 여러가지 방법으로 표현 가능
고객
id : String
name : String
ssn : String
getId()
getName()
getSSN()
고객
id : String
name : String
ssn : String
getId() : String
getName() : String
getSSN() : String
(from UseCase)
<<Actor>>
고객
id : String
name : String
ssn : String
getId() : String
getName() : String
getSSN() : String
(from UseCase)
고객
id : String
name : String
ssn : String
getId() : String
getName() : String
getSSN() : String
(from UseCase)

26. 26
7.3. Class Diagram – 관계
Beginning the UML
 Class Diagram에서는 Class 간의 정적인 관계를 표현
 Generalization : Generalize, Realize,
 Dependency
 Association : Associate, Aggregate, Composite
 Association 유형에서는 관계수(multiplicity)와 관계명(relation name),
운항성(navigability)을 기술 가능

27. 27
7.4. Class Diagram – Generalize
Beginning the UML
 일반적인 상속 관계를 표현
 Java에서 extends 구문으로 구현
 으로 표현하며, <<generalize>>라는 stereo type을 기술
고객
id : String
name : String
ssn : String
getId() : String
getName() : String
getSSN() : String
(from UseCase)
<<Actor>>
기업고객
masterId : String
firmName : String
getMasterId()
getFirmName()
(from UseCase)
<<Actor>>
<<generalize>>
개인고객
isNoble : boolean
isNoble()
(from UseCase)
<<Actor>>
<<generalize>>

28. 28
7.5. Class Diagram – Realize
Beginning the UML
 인터페이스 구현 관계를 표현
 Java에서 implements 구문으로 구현
 으로 표현하며, <<realize>>라는 stereo type을 기술
 인터페이스는 operation 정의만 있는 클래스 (attribute와 operation body가 없음)
 Component화의 중요한 요소
EJB 프로그램
업무 프로그램1
perform()
WooriApplication
perform()
<<Interface>>
EJBSessionBean
<<Interface>>
업무 프로그램2
perform()

29. 29
7.6. Class Diagram – Dependency
Beginning the UML
 두 객체에서 하나의 특징이 변화함에 따라 다른 하나에 영향을 미치는 관계
 한쪽 객체의 operation 처리 흐름 중에 다른 객체를 참조할 경우의 관계
 의존되는 클래스가 변경되면, 의존하는 클래스도 검증
 이 관계를 통하여 Component화의 가능성을 판단 가능
 를 사용
개인뱅킹 이체 이체실행
결재요청
기업뱅킹 승인실행기업뱅킹 이체

30. 30
7.7. Class Diagram – Association
Beginning the UML
 객체 간의 동등한 관계를 표현
 일반적으로 has a, refer to, copy of의 형태로 도출
 으로 표현
 관계선 위에 관계명(relation name)을 기술 가능
 관계수(multiplicity)를 기술 가능
• 기업고객은 결재요청 내역을 0개 또는 1개 이상 가질 수 있다.
결재요청내역
reqTime
requestor : 기업고객
drawAccount
receiptAccount
amount
기업고객
masterId : String
firmName : String
getMasterId()
getFirmName()
(from UseCase)
<<Actor>>
1 0..*
has
0..*1

31. 31
7.8. Class Diagram – Navigability
Beginning the UML
 운항성은 한 객체에서 다른 객체로 접근 가능 여부를 나타냄
 개념 Level에서는 중요하지 않으나, 구현 Level에서는 매우 중요
 포인터 관점에서 접근
 로 표현
 단방향(unidirectional)은 한쪽 화살표로, 양방향(bidirectional)이나
미지정 상태는 화살표를 그리지 않음
결재요청내역
reqTime
requestor : 기업고객
drawAccount
receiptAccount
amount
기업고객
masterId : String
firmName : String
getMasterId()
getFirmName()
(from UseCase)
<<Actor>>
1 0..*
has
0..*1

32. 32
7.9. Class Diagram – Aggregation
Beginning the UML
 집합 관계를 표현하며, part of 관계로 도출
 연관(Association)과 집합연관(Aggregation)을 구분하는 것은 쉽지 않음
 일반적으로 유사 속성의 part of 관계이면 aggregation으로 판단
 로 표현
거래내역조회데이터
계좌번호
조회시작일
조회종료일
개별거래내역데이터
거래일시
입지구분
출금계좌
입금계좌
거래금액
수취인
적요
0..100 0..1
part of
• 거래내역조회를 수행한 데이터를 다른 프로그램에서 사용하는 경우
• 연관 관계로 볼 수도 있음.

33. 33
7.10. Class Diagram – Composition
Beginning the UML
 Aggregation보다 더 강한 집합 관계를 표현
 개별 구성 부품이 전체(whole)에 소속되어 있고, 전체와 동일한 생명 주기를 가짐
 RDB의 Table 관계와 유사
 로 표현
개별이체데이터
입금계좌번호
이체금액
적요
대량이체거래데이터
등록일시
이체일자
출금계좌번호
총건수
1 1..*1 1..*
part of
• HOST 송신(이체실행) 전, 고객으로부터 수신 받은 시점

34. 34
8. UML의 사용 - 유의사항
Beginning the UML
 UML에 대한 접근 방법은 사용자의 경험에 따라 상이할 수 있음
 분석 단계에서는 다양한 시점에서 diagram을 작성할 수 있음
 UML은 사람이 생각하고 분석하는 모든 영역을 Model화 할 수 있음
 UML은 개인과 조직의 상황에 맞게 사용  그러나, 계속적인 OO Design 추구
 SCM의 도입 고려

35. 35
8.UML의 사용 - UML로 옮겨가기
Beginning the UML
 OO 개념 초보자
 추상화 개념에 익숙해지도록 함
 추상 개념들을 가시화하여 정적인 모델을 작성
 정적 모델로부터 간단한 동적 모델을 작성
 Modeling 초보자
 개발 경험이 있는 System의 일부를 대상으로 시작
 Architecture Model로 다시 구축
 OO 유경험자
 현재 구축된 Modeling 중 구축이 어려운 부분에 High-Level Modeling을 적용
 Modeling 경험자
 Pattern을 modeling하는데 필요한 UML 기능 파악
 UML 확장 Mechanism에 대한 연구와 해당 Domain에 직접 적용할 방안 모색