<참고 링크>
*데자뷰우님의 티스토리
[ UML 다이어그램이란? ]
통합 모델링 언어를 사용하여 시스템 상호작용, 업무흐름, 시스템 구조, 컴포넌트 관게 등을 그린 도면입니다.
[ 사용하는 이유 ]
프로그래밍을 단순화 시켜 표현하여 의사소통하기 좋게 만들며, 또 대규모 프로젝트 구조의 로드맵을 만들거나 개발을 위한 시스템 구축에 기본을 마련합니다.
[ 종류 ]
| 종류 | 사용 |
|---|---|
| Use Case | 요구 분석 과정에서 시스템과 외부와의 상호 작용을 묘사함 |
| Activity | 업무의 흐름을 모델링하거나 객체의 생명주기를 표현함 |
| Squence | 객체 간의 메세지 전달을 시간적 흐름에서 분석함 |
| Collaboration | 객체와 객체가 주고받는 메세지 중심으로 작성함 |
| Class | 시스템의 구조적인 모습을 그림 |
| Component | 소프트웨어 구조를 그림 |
| Deployment | 기업 환경의 구성과 컴포넌트들 간의 관계를 그림 |
[ Use Case 다이어그램 ]
- 요구분석을 위한 UML
- 시스템에 요구되는 기능을 사용자 관점에서 나타낸 다이어그램
[ 구성 요소 ]
[ 시스템 (Systems) ]
개발하고자 하는 것 그 자체 ( 웹사이트, 소프트웨어 컴포넌트, 어플리케이션 등...)
시스템 범위를 정의하며 흐름이 일어나는 영역의 경계를 정의합니다.
위와 같이 사각형 형태로 표시하고, 상단에 시스템 이름을 정의합니다.
사각형 안은 시스템 안에서만 일어나고, 범위 밖에 있는 흐름은 시스템 안에서 일어나지 않습니다.
[ Actor ]
- 시스템 외부에 존재하면서 시스템과 상호작용하는 객체 (ex. 고객, 관계자)
(꼭 사람이 아님)
액터는 반드시 하나 이상의 유즈케이스들과 상호작용해야합니다.
액터 이름은 개인적이거나 무언가를 특정해서는 안 됩니다.
(ex. Hongildong (X) / Customer (O) )
두 가지의 액터가 존재합니다.
1. 프라이머리 액터 (Primary Actor) : 시스템을 사용하고, 직접 이득을 보는 액터이며, 졸라맨으로 표기합니다. 보통 시스템의 왼쪽에 표시합니다.
2. 세컨더리 액터 (Secondary Actor) : 프라이머리 액터가 목적을 달성하기 위해 도움을 주는 액터이며 사각형 박스에 << actor >> 를 입력하여 표기합니다. 보통 시스템의 오른쪽에 표시합니다.
[ Use Case ]
사용자 관점의 기능 단위 (서비스 단위) 타원형으로 표기합니다.
ex) 은행 앱의 경우 로그인, 잔고 확인, 계좌이체 등이 될 수 있습니다.
[ 관계 (Relationships) ]
선 또는 화살표로 나타내며, 이어진 2개의 액터 또는 유즈케이스들이 서로 상호작용함을 나타냅니다.
총 4가지의 관계가 존재합니다.
[ Association (연관 관계) ]
유즈케이스와 액터 사이에 상호작용이 있다는 뜻으로, 실선으로 표시합니다.
[ << include >> 포함관계 ]
기본 유즈케이스가 실행되기 위해서는 반드시 다른 특정 유즈케이스의 행위를 포함해야한다는 것을 의미합니다.
ex)
[ 잔고 확인 ] ----<< include >> ------▶ [ 로그인 ]
잔고를 확인하기 위해서 로그인 기능을 포함해야함.
[ << extend >> ]
유즈케이스가 특정 유즈케이스에 정의된 행위로 선택적으로 추가 확장될 수 있다는 것을 나타냅니다.
ex)
[ 계좌이체 ] ◀----<< extend >>------ [ 보내는 메모 작성 ]
계좌 이체가 가능한 Customer는 계좌이체 시 메모를 작성하여 보낼 수 있습니다.
[ Generalization (일반화) ]
기능의 추가 관계가 아닌, 개념의 확대로 봐야하는 상속관계를 나타냅니다.
특정 유즈케이스들이 하나의 유즈케이스의 특수화된 유즈케이스라는 뜻을 가지고 있습니다.
자식 유즈케이스에서 부모 유즈케이스 방향으로 삼각형 실선 화살표를 그립니다.
확장 관계(extend)와의 차이점
일반화 관계에 있는 자식 유즈케이스들은 부모의 속성들을 물려받기 때문에, 부모 유즈케이스가 해당된 모든 포함, 확장 관계를 만족해야합니다.
반면에 확장 관계에 있는 유즈케이스는 속성을 물려받은 것이 아니므로, 기존 유즈케이스와 다른 유즈케이스와의 관계를 만족하지 않아도 됩니다.
ex)
[ 결제 ] ◀------------ 체크 카드 결제 or 무통장 입금 결제
저도 처음 그린 UML이라 정확하지 않습니다...
결제를 할 때 로그인을 해야하는데 근데 잔액 확인에서 로그인을 시도하기 때문에 괜찮은지...
하지만 한 번에 정확하게 그릴 수 없듯. 그리면서 차근차근 컨펌하면서 좋은 다이어그램을 그려 나가면 좋을 거 같습니다.
[ 작성 순서 ]
-
시스템 정의
시스템 영역과 이름을 정의합니다. -
액터 정의
사용자 (Primary Actor)를 정의합니다.
시스템과 상호작용하는 외부 시스템 (Secondary Actor)를 정의합니다. -
유즈케이스 정의
Actor가 요구하는 서비스를 식별합니다.
Actor들이 시스템과 상호작용하는 행위를 식별합니다. -
관계정의
Actor와 Actor 사이의 관계를 정의합니다.
Actor와 유즈케이스 사이의 관계를 정의합니다.
유즈케이스 간의 관계를 정의합니다. -
유즈케이스 구조화
두 개 이상의 유즈케이스의 공통된 서비스를 추출하여 일반화 시킵니다.
