Beginning the UML - in Banking Domain (UML 교육자료)

1

Beginning the UMLin Banking Domain

COPYRIGHT © 2003 Lee Juhyeon All Right Reserved.

Date : 2003.8.26Author : Lee JuhyeonEmail : [email protected] : http://www.jsummit.com

2

1. UMLBeginning the UML

S/W

청사진

작성

표준

언어

가시화

명세화

구축

문서화

SYSTEM

Unified Modeling Language

어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현

프로젝트 구성원 내부 또는 고객과의 의사소통 향상

시스템을 이해하기 위하여 하나 이상의 모델을 서로 연결 사용

복합적인 모델로 이해를 증진

3

2. UML의 역사Beginning the UML

방법론의 춘추 전국 시대(90년대 초) 주요 세력에 의한 통일화

Three Amigo - Grady Booch, James Rumbaugh, Ivar Jacobson가 주축

기존의 방법론 및 표기법의 장점을 흡수

OMG(Object Management Group)에 의하여 표준화

UnitedModelingLanguage

BoochBooch

GammaFrameworks, Pattern, Notes

RumbaughOMT

JacobsonOOSE

HarelState Charts

Wirfs-BrockResponsibilities

Shlaer-MellorObject life cycles

MeyerPre- and post- conditions

OdellClassfication

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

4. Use Case DiagramBeginning the UML

System 전체나 Use Case 일부 행동을 명세화하고 순차적으로 발생하는

활동들을 기술

System 외부의 행위자와 System 내부의 핵심 추상 개념 간의 교류를 표현

Use Case는 대상 행동의 명세화만을 수행하고 행동 수행 방법은 규정하지 않음

개발자와 사용자 간 Communication의 도구

사용자가 시스템을 이해하는 유일한 도구로 외부에서 시스템을 바라보는 관점

시스템에 대한 요구 사항을 표현

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

4.2. Use Case Diagram – 관계 1

Beginning the UML

통신 관계(Communication)

Actor와 Use Case 사이의 메시지 교류 관계

상호 작용의 의미

Association으로도 표현

일반화 관계(Generalization)

Parent의 속성을 Child가 상속받는 것을 표현

Actor와 Actor, Use Case와 Use Case 사이의 관계

객체 지향에서의 일반적인 상속을 의미

고객

개인고객 기업고객

고객계좌이체

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

4.4. Use Case Diagram – 예제 (요구분석)

Beginning the UML

논의한 시스템의 요구사항 분석

고객은 계좌이체를 사용할 수 있다.

고객은 개인고객과 기업고객으로 구분된다.

개인고객은 개인뱅킹 이체만을 기업고객은 기업뱅킹 이체만을 사용할 수 있다.

기업뱅킹 이체는 결재요청과 승인실행으로 분기된다.

기업뱅킹에서 승인실행을 하는 경우와 개인뱅킹에서 개인뱅킹 이체를 하는

경우에는 공통적인 이체실행을 수행한다.

Actor 분석

추상 Actor : 개인고객, 기업고객

구체 Actor : 개인고객, 기업고객

Domain 분석

개인뱅킹, 기업뱅킹

Use Case 분석

추상 Use Case : 계좌이체

구체 Use Case : 개인뱅킹이체, 기업뱅킹 이체, 결재요청, 승인실행, 이체실행

10

4.5. Use Case Diagram – 예제 (Diagram)

Beginning the UML

결재요청승인실행

이체실행

<<include>>

계좌이체고객

개인고객개인뱅킹 이체

<<include>>

기업고객기업뱅킹 이체

<<extend>>

<<extend>>

<<generalize>>

<<generalize>>

<<generalize>>

<<generalize>>

11

4.6. Use Case Diagram – 유의사항

Beginning the UML

구조화가 좋은 Use Case Diagram

System의 정적인 Use Case 관점에서 한 부분의 대화에만 초점을 맞춤

해당 부분을 이해하는데 필수적인 Use Case와 Actor만을 포함

추상화 수준별로 일관성 있게 상세 사항을 추가

중요한 의미는 적절한 정도의 크기로 분해

Use Case Diagram 작성법

목적을 알 수 있는 명칭의 사용

교차되는 Line이 가능하면 최소가 되도록 요소를 배치

행동, 역할, 의미가 연관이 있는 것은 인접하여 배치

Note 등의 활용으로 가시적 효과를 이용하여 중요한 특성을 부각

관계는 너무 많이 표현하지 않고 반드시 필요한 것만 표현

12

5. Activity DiagramBeginning the UML

흐름도로서 Activity 간의 전달되는 제어 흐름을 표현(발생 활동에 초점)

객체 간 통과 제어 흐름(operation)을 표현

하나의 Activity는 몇 개의 Action으로 분리

기존의 Flow-Chart와 유사

Activity, State, Flow, Swinlane으로 구성

유용성

Use Case 분석

Work-Flow의 이해

알고리즘 설명

13

5.1. Activity Diagram – 구성요소 1

Beginning the UML

State

활동(Activity에 따른 상태를 표현

기본적으로 Start State와 End State가 있음

State 자체는 자주 사용되지 않음

Activity

처리할 활동을 의미

Use Case일 수도 있고, Use Case 내의 흐름일 수도 있음

Decision

조건 분기를 의미

일반적으로 Activity에서 대신함

14

5.2. Activity Diagram – 예시 1

Beginning the UML

개념 Level의 Activity Diagram

계좌이체 실행

고객이 승인권자인가?

결재요청 실행

거래 완료 상태

거래 수신 상태

아니오 예

Activity

Decision

Start State

End State

SynchronizationBar

State

15

5.3. Activity Diagram – Synchronization Bar & Swinlane

Beginning the UML

Synchronization Bar

동시에 처리되어야 할 Activity를 표현

분기(forking) 흐름이 다시 단일화(join)되는 부분에서도 사용

Work-Flow에서 비동기 처리를 기술할 수 있음

Swimlane

Activity Diagram에 구획을 나누기 위하여 사용

일반적으로 업무 별, 시스템 별, 사용자 별로 구분

시스템 별로 적용할 경우, 기존 DFD와 유사

구획 간에 수직선으로 표현

16


Beginning the UML

전문 생성

전문 송수신

송수신 상태

전문 파싱

정상 메세지 생성

요청 메세지 수신

시스템 장애

에러 메세지 생성

응답 리턴

시스템 관리자에게 SMS 발송

비동기 처리

예

아니오

아니오

예

17


Beginning the UML

고객으로부터 입력 수신

고객에게 결과 출력

sub 사용자 이체 한도 확인

결과 메세지 생성

전문 생성

전문 송수신

이체 한도 확인 Procedure 호출

HOST 전문 송수신

UI Tier BL Tier DB Tier 중계 Tier

18

6. Sequence DiagramBeginning the UML

흐름도 중의 하나로서, 시간에 따른 객체 간의 message 발생 순서를 표현

교류를 주도하는 객체를 왼쪽에 배치

message들을 시간의 흐름에 따라 위에서 아래로 배치

한 개의 제어 흐름 만을 표현

객체 modeling이 원칙이나 다양한 정적인 대상(Class, System, etc.)도 표현 가능

실제 구현 Level에서 중요한 Diagram

19

6.1. Sequence Diagram - 구성요소Beginning the UML

Object

실제 객체의 인스턴스를 표현하는 것이 원칙

Message

객체 간 주고 받는 message이며 화살표로 표현

구현 Level에서는 메소드로 디자인됨

Lifeline

특정 시간 동안 객체가 존재하는 것을 표현

Destroyer

객체가 소멸되는 시점을 표현하며, X로 표시

일반적으로 서버 프로그래밍 시에는 선택적으로 사용됨 (Thread Pooling)

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

6.3. Sequence Diagram – 예시 2

Beginning the UML

고객 UI 계좌이체 이체실행 전문 송수신 통합중계 HOST전문 Logger

이체실행 버튼을 누른다실행()

이체실행()

송수신()

송수신 에러 확인 및 처리()

에러 여부 확인()

java 객체 --> 전문 변환()

전문 -->java 객체 변환()

결과를 본다

로깅

로깅

22

6.4. Sequence Diagram - 유의사항Beginning the UML

Use Case별로 하나씩 작성하는 것이 원칙

동일한 상호 작용이 유사하게 중복 작성되는 것을 피함

가독성을 위하여 적당한 Comment 사용

메시지 흐름은 Actor부터 작성

numbering을 사용하면 구현 Level에 대한 세밀한 설계가 가능하나,

일반적으로는 기록하지 않음

23

7. Class DiagramBeginning the UML

시스템에서 사용되는 클래스를 정의하고, 클래스의 속성과 행위를 표현

클래스 간의 다양한 관계를 표현

실제 구현 단계에 가장 접근 Forward Engineering의 기반

자동화된 Reverse Engineering의 현실적 한계 지점

정적 Model

Logical Database Design을 수행 가능

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 : Stringname : Stringssn : String

getId() : StringgetName() : StringgetSSN() : String

(from UseCase)

<<Actor>> Stereo Type

Visibility

Visibility

Type ofAttribute

Type ofOperation

고객


getId()getName()getSSN()

Attribute

Operation

Type (Name)

25

7.2. Class Diagram – 구성요소 2

Beginning the UML

하나의 클래스도 여러가지 방법으로 표현 가능

고객


getId()getName()getSSN()

고객



(from UseCase)

<<Actor>>

고객



(from UseCase)

고객



(from UseCase)

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

7.4. Class Diagram – Generalize

Beginning the UML

일반적인 상속 관계를 표현

Java에서 extends 구문으로 구현

으로 표현하며, <<generalize>>라는 stereo type을 기술

고객



(from UseCase)

<<Actor>>

기업고객

masterId : StringfirmName : String

getMasterId()getFirmName()

(from UseCase)

<<Actor>>

<<generalize>>

개인고객

isNoble : boolean

isNoble()

(from UseCase)

<<Actor>>

<<generalize>>

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

7.6. Class Diagram – Dependency

Beginning the UML

두 객체에서 하나의 특징이 변화함에 따라 다른 하나에 영향을 미치는 관계

한쪽 객체의 operation 처리 흐름 중에 다른 객체를 참조할 경우의 관계

의존되는 클래스가 변경되면, 의존하는 클래스도 검증

이 관계를 통하여 Component화의 가능성을 판단 가능

를 사용

개인뱅킹 이체 이체실행

결재요청

기업뱅킹 승인실행기업뱅킹 이체

30

7.7. Class Diagram – Association

Beginning the UML

객체 간의 동등한 관계를 표현

일반적으로 has a, refer to, copy of의 형태로 도출

으로 표현

관계선 위에 관계명(relation name)을 기술 가능

관계수(multiplicity)를 기술 가능

• 기업고객은 결재요청 내역을 0개 또는 1개 이상 가질 수 있다.

결재요청내역

reqTimerequestor : 기업고객drawAccountreceiptAccountamount

기업고객



(from UseCase)

<<Actor>>

1 0..*

has

0..*1

31

7.8. Class Diagram – Navigability

Beginning the UML

운항성은 한 객체에서 다른 객체로 접근 가능 여부를 나타냄

개념 Level에서는 중요하지 않으나, 구현 Level에서는 매우 중요

포인터 관점에서 접근

로 표현

단방향(unidirectional)은 한쪽 화살표로, 양방향(bidirectional)이나

미지정 상태는 화살표를 그리지 않음

결재요청내역

reqTimerequestor : 기업고객drawAccountreceiptAccountamount

기업고객



(from UseCase)

<<Actor>>

1 0..*

has

0..*1

32

7.9. Class Diagram – Aggregation

Beginning the UML

집합 관계를 표현하며, part of 관계로 도출

연관(Association)과 집합연관(Aggregation)을 구분하는 것은 쉽지 않음

일반적으로 유사 속성의 part of 관계이면 aggregation으로 판단

로 표현

거래내역조회데이터

계좌번호조회시작일조회종료일

개별거래내역데이터

거래일시입지구분출금계좌입금계좌거래금액수취인적요

0..100 0..1

part of

• 거래내역조회를 수행한 데이터를 다른 프로그램에서 사용하는 경우• 연관 관계로 볼 수도 있음.

33

7.10. Class Diagram – Composition

Beginning the UML

Aggregation보다 더 강한 집합 관계를 표현

개별 구성 부품이 전체(whole)에 소속되어 있고, 전체와 동일한 생명 주기를 가짐

RDB의 Table 관계와 유사

로 표현

개별이체데이터

입금계좌번호이체금액적요

대량이체거래데이터

등록일시이체일자출금계좌번호총건수

1 1..*1 1..*

part of

• HOST 송신(이체실행) 전, 고객으로부터 수신 받은 시점

34

8. UML의 사용 - 유의사항Beginning the UML

UML에 대한 접근 방법은 사용자의 경험에 따라 상이할 수 있음

분석 단계에서는 다양한 시점에서 diagram을 작성할 수 있음

UML은 사람이 생각하고 분석하는 모든 영역을 Model화 할 수 있음

UML은 개인과 조직의 상황에 맞게 사용 그러나, 계속적인 OO Design 추구

SCM의 도입 고려

35

8.UML의 사용 - UML로 옮겨가기Beginning the UML

OO 개념 초보자

추상화 개념에 익숙해지도록 함

추상 개념들을 가시화하여 정적인 모델을 작성

정적 모델로부터 간단한 동적 모델을 작성

Modeling 초보자

개발 경험이 있는 System의 일부를 대상으로 시작

Architecture Model로 다시 구축

OO 유경험자

현재 구축된 Modeling 중 구축이 어려운 부분에 High-Level Modeling을 적용

Modeling 경험자

Pattern을 modeling하는데 필요한 UML 기능 파악

UML 확장 Mechanism에 대한 연구와 해당 Domain에 직접 적용할 방안 모색

Beginning the UML - in Banking Domain (UML 교육자료)

Technology

Transcript of Beginning the UML - in Banking Domain (UML 교육자료)