오늘부터 공부한다
Use Case Diagram(유스케이스 다이어그램) 본문
전에 UML 공부 할때 간단히 적은 것 같은데 설명이 부실한 것 같다.
이번에는 그림도 넣고 해서 좀 자세하게 알아보겠다.
유스케이스 다이어그램
시스템과 사용자의 상호작용을 다이어그램으로 표현한 것으로 사용자의 관점에서 혹은 시스템 서비스, 기능 등의 요소를 보여주는 것이다.
사용자는 시스템 내부에 있는 기능 중에 어떤 기능을 사용 할 수 있는지 나타내며 유스케이스 다이어 그램을 사용함으로써 고객과 개발자가 요구사항에 대한 의견을 조율 할 수 있다.
유스케이스 다이어그램의 구성요소
1) 시스템(System)
만들고자 하는 프로그램
사각형의 모양으로 유스케이스를 감싼다.
2) 액터 (Actor)
시스템의 외부에 있고, 시스템과 상호작용을 하는 사람이다.
액터 명은 위나 아래에 표시하여 액터의 역할을 작성해야한다.
졸라맨(?) 모양으로 표시한다.
3) 유스케이스(Usecase)
사용자 입장에서 바라본 시스템의 기능
시스템이 액터에게 제공해야 하는 기능으로 요구사항을 나타낸다.
타원으로 표시한다.
유스케이스는 (~한다)와 같이 표시해야한다.
4) 관계(Relation)
액터와 유스케이스 사이의 관계를 나타낸다.
종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있다.
그 중 의존 관계는 포함(Include), 확장(Extend)로 나뉘어진다.
1. 연관관계(Association)는 유스케이스와 액터간의 상호작용이 있음을 표현한다.
유스케이스와 액터를 실선으로 연결한다.
2. 의존관계 중 포함관계(Include)는 하나의 유스케이스가 다른 유스케이스를 반드시 실행을 해야한다는 전제 하에 형성되는 관계이다.
포함하는 유스케이스에서는 포합되는 유스케이스 방향을 점선 화살표로 연결하고 <<include>>라고 표기한다.
위의 예제 처럼 "글을 등록하기 전"에 "로그인 한다"라는 명령이 반드시 수행되어야 한다는 것을 나타낸다.
3. 의존관계 중 확장관계(Extend)는 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계다.
확장된 유스케이스는 특정 조건에 따라 수행하기에 필수적으로 수행되야하는 것은 아니다.
확장 기능 유스케이스에서는 확장 대상 유스케이스 방향으로 점선 화살표를 연결하고 <<extend>>라고 표기한다.
위 그림은 "글을 등록한다" 기능을 수행하기 전에 "파일을 첨부한다"라는 선택적으로 수행할 수 있는 것을 의미한다.
4. 일반화 관계(Generalization)는 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다.
구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다.
위 그림은 "글을 검색한다"를 "글쓴이로 검색한다"와 "날씨로 검색한다"등으로 구체화 한것을 나타낸다.
작성 순서
1단계 - 시스템의 상황을 확인한다.
2단계 - 액터 식별 (행위자와 그들의 책임을 확인한다)
3단계 - 유스케이스 식별(시스템의 목적과 특성을 확인한다)
4단계 - 유스케이스 다이어그램 작성 (액터와 유스케이스간의 관계 평가)
5단계 - 유스케이스 명세서 작성(유스케이스명, 액터명, 기능 등 유스케이스 다이어그램을 명세서로 작성한다.)
6단계 - 유스케이스 실체화(구현 시스템을 클래스로 식별하고 통신관계 파악)
1. 액터 식별
액터식별은 외부에서 시스템에 접근할 수 있는 사람 또는 시스템과 관련된 외부 시스템을 의미한다.
아까도 말했듯이 액터의 명칭은 특정 사람의 이름보다는 역할을 명칭으로 한다.
EX) 개똥이 -> 고객, 관리자
시스템으로부터 정보를 받는 외부 시스템의 사람 또는 사물로 접근가능하다.
한 줄 요약
Actor의 이름(역할)을 서술하는 것
2. 유스케이스 식별
개발을 위한 시스템의 기능을 의미한다.
시스템을 수행하는 일련의 행위
시스템에서 제공해야하는 독립적인 기능을 의미한다.
외부 시스템과 상호작용하는 행위들의 기능만을 의미
한 줄 요약
시스템의 외부, 내부를 포함한 유스케이스의 기능을 명세하는 것
3. 유스케이스 다이어그램 작성
액터와 유스케이스 관계에서의 관점 :
해당 액터와 정보를 주고받는 유스케이스를 찾아서 연관 관계를 설정한다.
유스케이스와 유스케이스 관계에서의 관점 :
<<include>>, <<extend>>로 표현
전체적인 유스케이스 다이어그램 작성 :
요구명세서로부터 액터와 유스케이스 관계 및 유스케이스 사이의 관계를 이용한 전체적인 유스케이스 다이어그램을 작성한다.
한 줄 요약
요구사항가 정의된 문서를 통해 유스케이스 간의 관계를 작성한다.
4. 유스케이스 명세서 작성
a. 유스케이스명
b. 액터명
c. 유스케이스 개요
d. 이벤트 흐름 - 정상 흐름과 선택 흐름 분류 (예외처리 같은 느낌?)
한 줄 요약
완성된 유스케이스의 기능을 글로 정리한다(?)
5. 유스케이스 실체화
실체화를 위해 유스케이스들이 어떻게 실현되는지를 객체들 간 메시지 흐름의 상호작용으로 설명함으로
실체화된다고 볼 수 있다.
'소프트웨어 공학' 카테고리의 다른 글
블록체인(Block Chain) (0) | 2019.10.14 |
---|---|
클라이드 컴퓨팅 (Cloud Computing)이란? (0) | 2019.10.14 |
객체지향의 특징 (0) | 2019.10.07 |
객체지향 (0) | 2019.10.07 |
4+1 뷰 아키텍처 모델 (0) | 2019.10.07 |