통합 모델링 언어(UML, Unified Modeling Language)
- 소프트웨어를 설계할 때 다이어그램을 그리기 위한 시각적인 표기법
UML 다이어그램의 한 종류로, 유스케이스 다이어그램이 있다. 유스케이스 다이어그램은 주로 개발 프로세스 중 요구사항 분석 단계에서 사용된다. 고객과의 소통을 위해서 시스템이 어떻게 사용자와 상호작용하는지 기능 위주의 요구사항 도출 및 정리를 위해 활용된다. 이렇게 사용자의 행위 중심의 다이어그램은 동적 다이어그램으로 분류된다.
액터: 사용자 또는 외부 시스템
유스케이스: 시스템 동작 또는 기능의 단위
관계
실선(연관관계)는 액터와 유스케이스 사이에서만 사용 가능
유스케이스 다이어그램은 상황에 따라 여러 형태로 작성될 수 있다. 다만 액터와 기능의 관계를 명확하게 하고, 유스케이스를 구체화('입출금'의 단일 유스케이스가 아닌 '입금', '출금' 유스케이스로 분리)할 필요가 있다. 유스케이스는 아무 관계 없이 존재할 수 없으며 반드시 상호 작용을 해야 한다.
상품 조회, 리뷰 조회, 관리 등이 가능한 일반적인 인터넷 쇼핑몰의 요구사항 기술서를 바탕으로 UML 툴을 사용해서 유스케이스 다이어그램을 작성해보겠다.

액터는 system boundary 바깥에, usecase는 안에 위치할 수 있도록 한다.

유스케이스 다이어그램을 작성하며 고민을 했던 부분들이다.
Q. 상품목록조회-상품검색, 상품목록조회-상품상세조회, 회원정보조회-회원수정, 회원정보조회-회원탈퇴 등의 관계는 include로 설정해야 할까, extend로 설정해야 할까?
A. 요구사항 기술서를 어떻게 해석하느냐에 따라서 달라질 것 같다. 나는 무조건 회원상세 조회를 거쳐야만 회원 수정과 회원 탈퇴가 가능한, 기능을 포함하는 '반드시 해야 하는' 관계로 해석했기 때문에 include로 관계를 작성하였다. 하지만 일반적인 쇼핑몰을 생각했을 때, 무조건 종속되는 관계는 아닌 것 같기도 하다. 문서가 명확하게 기술되어야 하는 이유를 체감하였다.
Q. 일반화 관계, 확장 관계, 포함 관계 모두 하나의 유스케이스가 다른 유스케이스를 포괄하는 상위-하위 관계 아닌가? 어떤 차이가 있나?
A. 포함 관계는 나머지 둘에 비해 쉽게 구분할 수 있다. 다른 관계와 달리 한 유스케이스가 다른 유스케이스를 거치지 않고서는 발생할 수 없는 '의무 관계'이기 때문이다. 그렇다면 확장 관계와 일반화 관계가 관건이다. 확장 관계의 예로는 회원관리(<- extends - 회원조회, 회원수정, 회원탈퇴)가 있고, 일반화 관계의 예로는 게시글 검색(<-- 제목검색, 내용검색)이 있다.
나는 둘을 구분하는 방법으로, 하위 단계의 유스케이스(화살표 꼬리쪽)가 상위 단계의 유스케이스(화살표 머리쪽)와 동일한 의미를 가질 수 있나? 를 생각해보았다. 동일한 의미를 가질 수 있으면 일반화 관계, 없으면 확장 관계이다. 예를 들어, 제목검색은 그 단어 자체로 게시글검색을 의미한다. 하지만 회원조회는 그 단어 자체로 회원관리를 의미하지 못한다.
Thumnail - Copyright 2020. Team Greedy all rights reserved