[SW공학] UML, Usecase Diagram

Formal한 정도에 따른 명세 방법의 구분

 

1. Informal Notation

: 자연어를 이용하여 서술형으로 기술된 요구사항

- 자연어 기반의 서술, 작업흐름도 등의 그림을 중심으로 작성

- 작성 및 이해 용이, 사용자와 개발팀 간의 의사전달이 용이

- 불충분한 명세, 일관성 결여, 내용의 모호성, 완전성 검증 곤란

 

 

2. Semi-formal Notation

: SysML이나 UML, MBD * 등의 모델링 언어를 이용하여 기술된 요구사항

- 기능적 관점/ 구조적 관점/ 동적 관점으로 시스템을 표현

- 이해하기 용이, 커뮤니케이션 오류 감소

- 누락되거나 중복되는 사항을 파악하기 용이

- 요구사항 변경 영향을 파악하기 용이하다. 

 

 

 

3. Formal Notation

: 수학적 기호나 수식으로 기술된 요구사항

- 모델기반 언어: Z, VDM

- 대수처리 기반 언어: CSP, CCS, LOTOS

- 명세의 정확성, 불완전성, 불일치 검토 입증, 모호성을 방지

 

 

 

 

 

 

 

 

UML(Unified Modeling Language)

: 소프트웨어 공학에서 시스템 설계를 표현하는데 사용하는 통합된 모델링 언어

- 다이어그램을 통해 개발 산출물을 가시화/ 명세화/ 문서화 함으로써, 요구사항의 누락사항이나 불일치를 줄임

 

 

UML 다이어그램 종류

: UML 다이어그램은 구조(structure)와 행위(behavior) 다이어그램으로 구분, 총 14개 존재

 

 

 

 

Usecase Diagram 구성요소

- 요구사항에 대해, 고객이나 사용자와 기능이 무엇인지 합의하는 과정

맨 처음 요구사항 확정 지을 때

 

1. 시스템(System)

- 개발하고자 하는 시스템의 범위

 

2. 액터(Actor)

- 시스템의 외부에 있으면서 시스템과 상호작용을 하는 사용자, 혹은 외부 시스템

Actor를 식별하기 위한 질문
- 누가/무엇이 시스템을 사용하나요?
- 누가/무엇이 이 시스템으로부터 정보를 얻나요?
- 누가/무엇이 이 시스템에게 정보를 제공하나요?
- 회사 내의 어디서 이 시스템을 사용하나요?
- 누가/무엇이 이 시스템을 지원하거나 유지보수하나요?
- 이 시스템이 어떤 다른 시스템을 사용하나요?

 

 

3. 유스케이스(Usecase)

- 시스템이 액터에게 제공해야하는 기능의 집합

- 사용자가 어떤 목적으로 시스템과 상호작용해야 하는지 보여주는 하나의 시나리오

- 하나의 유스케이스는 하나의 기능(서비스)

Usecase 식별
- 각 actor의 목표는 무엇인가요?
- actor가 이 시스템을 사용하는 이유는 무엇인가요?
- actor가 시스템에서 데이터를 생성/저장/변경/삭제 또는 조회하나요? 그렇다면 그 이유는 무엇인가요?
- actor가 외부 이벤트 또는 변경사항에 대해 이 시스템에 알려야 하나요?
- actor에게 이 시스템의 특정 사건(이벤트)에 대해 알려야 하나요?

 

 

4. 관계(Relationship)

- 액터와 유스케이스/ 유스케이스와 유스케이스 사이의 연관 관계

 

 

 

 

 

 

 

 

 

 

 

---

 

* MBD(Model Based Development): 그림을 그리면 코드가 자동으로 만들어지는 개발 방식