#5 UML 가장 많이 쓰이는 항목 - Use Case, Class Diagram, Sequence Diagram - 개념과 예제

1. Use Case Diagram?

 

사용자 요구사항을 더 쉽고 효과적으로 도출하기 위해 사용한다.

 

주로 '기능 요구사항'을 작성한다.

 

아래는 각 단어의 의미이다.

 

의뢰인 : 시스템 개발을 의뢰한 사람.

 

개발자 : 시스템 개발을 하는 사람.

 

User : 시스템을 사용하는 사람.

 

Actor : 개발 대상이 아님. 개발할 시스템 외부의 존재.

 

Use Case : 개발 해야 하는 시스템의 단위 기능.

 

 

* Actor와 Use case 사이의 관계(Association)

1) 연관 관계 : Actor와 Use case를 연결하는 실선. Actor와 Use case 간의 교류가 이루어지고 있음.

 

* Use case와 Use case 사이의 관계

1) 포함 관계(Include)

→  다른 Use case에서 기존의 Use case를 재사용할 수 있음
     하나의 Use case를 수행할 때, 같은 기능을 가진 다른 Use case가 반드시 수행된다.

'포함 관계'인 경우 '기준 Use case'에 상관없이 항상 실행되는 이벤트이다.

 

 

2) 확장 관계(Extend)

→  기존의 Use case에 진행단계를 추가하여 새로운 Use case를 만들어내는 관계

'확장 관계' 인 경우 '기준 Use case'의 조건이 만족해야만 실행되는 이벤트이다.

 

 

 

 

	포함관계	확장관계
목적	여러 유스케이스에 공통적인 기능 표현	기준 유스케이스에 부가적으로 추가된 기능 표현
이벤트 흐름	1. 반드시 실행되는 유스케이스 2. 포함관계의 유스케이스 수행 결과가 향후 이벤트 흐름에 영향을 미친다.	1. 조건에 따라 실행될 수도, 실행되지 않을 수도 있다.  2. 확장관계의 유스케이스 수행결과가 향후 이벤트 흐름에 영향을 미치지 않는다.

 

 

* Actor 사이의 일반화 관계(Generalization)

일반화 관계 : 한 액터도 다른 액터에 해당된다. 한 액터가 다른 액터의 일종이다.

 

'일반화'를 사용하지 않은 경우와 '일반화'를 사용한 경우를 비교해보면 쉽게 알 수 있다.

 

1) 일반화를 사용하지 않은 경우

 

'회원'과 '비회원'이 같은 유스케이스를 사용하기 때문에 연관관계 실선이 많아진다.

복잡해보인다.

 

 

 

2) 일반화를 사용한 경우

 

 

'회원'과 '비회원'을 '고객'으로 일반화 하였다(묶었다). 연관관계 실선이 줄어들어서 보기 편하다.

 

 

 

* 유사한 기능을 가지는 여러 유스케이스의 경우

 

공통적인 이벤트 문장을 추출해서 별도의 유스케이스로 한꺼번에 표현한다.

아래 표의 1번, 2번을 묶는다. 3번, 4번, 5번을 묶어서 표현할 수 있다.

 

[기존]

대여 유스케이스 이벤트 흐름	반납 유스케이스 이벤트 흐름
1. 사서는 고객의 아이디와 패스워드를 도서관 시스템에 입력한다.
2. 도서관 시스템은 아이디와 패스워드로 고객의 정보를 확인하고 업무 종류를 선택할 수 있는 화면을 보여준다.
3. 도서관 시스템은 사서에게 도서 번호를 입력하기 위한 화면을 보여준다.
4. 사서는 도서 번호를 입력한다.
5. 도서관 시스템은 도서 목록에서 도서 번호가 유효한지 확인한다.

 

 

[변경]

 

'고객확인' 유스케이스	1. 사서는 고객의 아이디와 패스워드를 도서관 시스템에 입력한다.  2. 도서관 시스템은 아이디와 패스워드로 고객의 정보를 확인하고 업무 종류를 선택할 수 있는 화면을 보여준다.
'도서번호입력' 유스케이스	3. 도서관 시스템은 사서에게 도서 번호를 입력하기 위한 화면을 보여준다.  4. 사서는 도서 번호를 입력한다.  5. 도서관 시스템은 도서 목록에서 도서 번호가 유효한지 확인한다.

 

 

 

* 유스케이스 다이어그램 만드는 단계

1단계 : 시스템 상황 분석(문제 기술서 작성)

 

2단계 : 액터 식별(행위자와 책임 확인)

※ 액터의 명칭은 특정 사람의 이름 사용하지 않는다.

고객, 관리자, 시스템과 같은 추상적 명칭을 사용한다.

 

3단계 : 유스케이스 식별(쓰임새, 시스템 특성 확인)

 

4단계 : 유스케이스 다이어그램 작성(정제할 부분, include, extend, generalization 확인)

※ 액터↔유스케이스, 유스케이스↔유스케이스(include, extend)

 

5단계 : 유스케이스 명세서 작성(유스케이스명, 액터명, 사전조건, 사후조건, 제약사항, 작업흐름, 시나리오)

 

6단계 : 유스케이스 실체화(클래스 식별, 통신관계  파악)

 

 

 

 

<2단계 : 액터 식별>

<3단계 : 유스케이스 식별>

<4단계 : 유스케이스 다이어그램 작성>

<액터와 유스케이스 관계>

 

 

<include 관계>

'대여'와 '반납' 유스케이스가 수행될 때는 반드시 '회원확인' 유스케이스가 선행(include) 되어야 한다.

 

<extend 관계>

'결제' 유스케이스로부터 '신용카드 지불' 유스케이스가 확장되는 형태로 이루어진다.

 

 

 

 

<완성된 유스케이스 다이어그램>

 

 

5단계 : 유스케이스 명세서 작성

* 유스케이스 명 : 회원가입

* 액터명 : 고객

* 유스케이스 개요 및 설명 : ...

* 이벤트 흐름

- 정상 흐름 : 사건의 주된 흐름

- 선택 흐름 : 사건의 주된 흐름 외의 수행 절차

 

6단계 : 유스케이스 실체화

 

요구사항 정의 활동의 산출물

 

필수 : 유스케이스 다이어그램, 유스케이스 명세서

선택 : 시퀀스 다이어그램, 액티비티 다이어그램

 

2. 클래스 다이어그램

클래스의 구성 요소: 클래스 이름, 속성, 메서드 (Class, Attributes, method)

클래스 이름 : 공통의 속성, 메서드 등을 공유하는 객체 집합

속성 : 클래스의 인스턴스가 보유할 수 있는 값의 범위

메서드 : 호출 제약사항 명세

 

인스턴스?

 

메서드의 종류

public ( + ) : 자신의 속성이나 동작을 외부에 공개

protected ( # ) : 상속된 파생 클래스만 엑세스 가능

private ( - ) : 구조체의 멤버 함수만 접근 가능. 외부에서 접근 불가.

 

(클래스) -> (객체 또는 인스턴스)

학용품   -> 연필, 볼펜, 지우개

 

명사 : 클래스, 속성

동사 : 메서드

 

연관관계의 다중성

다중성 표현	의미
1	한 객체와 연관된다. 표시 안함.
0..1	0개 또는 1개 객체와 연관.
0..*	0개 또는 많은 수의 객체와 연관.
*	0..*와 동일.
1..*	1개 이상의 객체와 연관.
1..12	1개에서 12개까지의 객체와 연관.
1..2, 4, 11	1개에서 2개까지 또는 4개 또는 11개의 객체가 연관.

 

* 연관관계 / 집합 관계 / 복합 관계 / 일반화 관계

 

연관 관계(Association) : 객체들이 서로 개념으로 연결됨

 

집합 관계(Aggregation) : 독립적인 구성 요소로 연관됨

 

복합 관계(Composition) : 영구적이며 강한 연관관계(서로 분리될 수 없음)

 

일반화 관계(Generalization) : 다른 의미로는 상속관계. 예를 들어 자동차의 한 종류로 버스, 트럭, 택시가 있다.  상위 항목(자동차)에 속하는 하위 항목(버스, 트럭, 택시)을 나열한 것이다.

 

 

자동차(엔진, 휠, 샤시) -> 집합 관계

엔진(카뷰레터, 피스톤, 플러그) -> 복합관계

 

 

 

 

 

자동차 -> 버스, 트럭, 택시 (일반화 관계)

 

 

* 의존 관계 (하나의 클래스가 또 다른 클래스를 사용하는 관계)

하나의 클래스에 있는 멤버 함수의 인자가 변할 때, 다른 클래스에 영향을 미치는 관계.

 

리모컨에 의해서 채널이 선택된다. 텔레비젼은 리모컨에 의존한다. 의존관계이다.

 

ex) 수업 -> 교수 (수업은 교수에 의존한다.)

전화기 -> 버튼 (전화기는 버튼에 의존한다.)

세탁기 -> 손잡이 (세탁기는 손잡이에 의존한다.)

자동차 -> 기어 (자동차는 기어에 의존한다.)

 

 

* 추상클래스와 인터페이스

<abstarct> : 추상클래스

<interface> : 인터페이스

 

* 실체화 관계

추상클래스나 인터페이스를 상속받아 자식클래스가 추상메서드 구현할 때 사용한다.

 

3. 시퀀스 다이어그램

메세지의 시간적인 흐름을 나타낸다.

객체가 메세지를 주고 받는다.

클래스 다이어그램을 동적 프로그래밍으로 설계할 수 있다.

시퀀스 다이어그램은 수직방향이 시간의 흐름을 나타낸다.

객체의 오퍼레이션과 속성을 상세히 정의한다.

시퀀스 다이어그램은 각 유스케이스별로 작성된다.

유스케이스에 필요한 객체가 주인공으로 등장한다.

객체간의 메세지를 통해서 유스케이스의 기능이 실현된다.

시간은 가장 윗부분에서 아래를 향해 흐르기 시작한다.

 

시퀀스 다이어그램 구성요소는 5가지이다.

 

구성	요소설명
액터	메세지를 시작하는 엘리먼트
객체	메세지를 송수신하는 객체
메세지	객체간 연결
Self 메세지	같은 객체에 대한 메서드(함수) 호출
제어 블록	제어문을 위한 루프

 

* 시퀀스 다이어그램 표기법

1) 객체

왼쪽에서 오른쪽으로 배열

2) 생명선

각 객체에서 아래로 뻗어나가는 점선

3) 활성화

생명선을 따라 나타나는 작은 사각형(객체가 수행하는 오퍼레이션 실행)

활성화 사각형의 길이는 오퍼레이션의 소요 시간

소요시간은 어림잡아 그린다.

4) 메시지

동기 메시지 : 송신 객체가 수신 객체의 오퍼레이션 완료를 기다려준다. (화살표 모양, 화살표 머리가 채워짐)

비동기 메시지 : 오퍼레이션 완료를 기다리지 않는다.(화살표 모양, 화살표 머리가 비어있음)

답신 메시지 : 수신 객체로부터 답신 메세지 요청하는 경우. 점선 끝에 화살표를 붙인 모양(화살표 머리가 채워짐)