1. Modeling
1) 요구사항 분석: 고객의 문제의 실체를 이해하고 분석하여 분석 모델을 구축 -> 분석 모델(고객의 요구사항을 모델링)
2) 설계: 설계 모델을 통해 고객의 문제를 해결하는 해결책을 표현 -> 설계 모델(해결책을 모델링) 구축
3) 구현: 설계 모델을 기반으로 프로그래밍 언어를 통해 소프트웨어(구현 모델) 구축
-> 사용자로부터 요구사항을 수집한 다음, 요구사항을 바탕으로 바로 프로그래밍 언어로 구현하지 않는다는 것을 알 수 있음
2. 모델의 역할
- 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토
- 현재 시스템 또는 앞으로 개발할 시스템의 원하는 모습을 가시화
- 시스템을 구축하는 틀 제공
3. UML
- 대표적인 시스템 모델링 언어
- 제임스 러버 OMT + 야콥슨 OOSE + 부치 OOAD
- 2015년 UML 2.5
- 시스템 구조와 행위를 표현(구조 다이어그램과 행위 다이어그램으로 분류)
4. 유스케이스 다이어그램
- 시스템을 사용하는 목적들, 즉 유스케이스들을 사용자 관점에서 기술한 다이어그램이며 이 목적 달성을 위한 사용자와 시스템 사이의 상호작용을 보여줌
- 시스템이 제공하는 기능이나 서비스 등을 정의하고, 시스템의 범위를 결정
4.1 유스케이스 다이어그램의 구성요소
1) 시스템(System)
- 의미: 만들고자 하는 애플리케이션
- 표기법: 유스케이스를 둘러싼 사각형의 틀(범위를 표시)을 그리고, 시스템 명칭을 사각형 안쪽 상단에 기술
2) 액터(Actor)
- 의미: 시스템의 외부에 있으면서 시스템과 상호 작용을 하는 사람 또는 다른 시스템
- 표기법
- 원과 선을 조합하여 사람 모양으로 표현
- 그 위 또는 아래에 엑터명 표시
- 액터명은 액터의 역할로 정함
3) 유스케이스(Usecase)
- 의미
- 시스템이 액터에게 제공해야 하는 기능의 집합
- 시스템의 요구사항을 보여줌 - 표기법
- 타원으로 표시하고 그 안쪽이나 아래쪽에 유스케이스명을 기술
- 유스케이스 이름은 "~한다"와 같이 동사로 표현
- 각 유스케이스가 개발될 기능 하나와 연결될 수 있도록 함
ex) "등록한다"는 동사의 대상이 나타나 있지 않으므로 좋은 이름이 될 수 없음
** 액터: 명사(구), 유스케이스: 부사구/동사구
4) 관계(Relationship)
- 의미: 액터와 유스케이스 사이의 의미 있는 관계
- 종류는 연관 관계, 의존 관계, 일반화 관계가 있고, 의존 관계는 다시 포함 관계, 확장 관계로 나뉨
- 포함/확장 관계는 유스케이스 간의 관계이고, 일반화 관계는 액터 간의 관계, 유스케이스 간의 관계 두개를 다룸
- 포함 관계는 필수적으로 수행하는 관계이고, 확장 관계는 선택적으로 수행하는 관계
- 일반화 관계 ~는 ~의 종류라고 해석
관계 종류 설명 연관 관계(association) - 유스케이스와 액터간의 상호작용이 있음을 표현
- 유스케이스와 액터를 실선으로 연결함포함 관계(include) - 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
- 포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용
- '포함하는 유스케이스'에서 '포함되는 유스케이스' 방향으로 화살표를 점선으로 연결하여 표현하고 <<include>>라고 표기확장 관계(extend) - 확장 기능(extending) 유스케이스와 확장 대상(extended) 유스케이스 사이에 형성되는 관계
- 확장 대상 유스케이스를 수행할 때에 특정 조건에 따라 확장 기능 유스케이스를 수행하기도 하는 경우에 적용
- '확장 기능 유스케이스'에서 '확장 대상 유스케이스' 방향으로 화살표를 점선으로 연결하여 표현하고 <<extend>>라고 표기일반화 관계(generalization) - 유사한 유스케이스들 또는 액터들을 모아 그들을 추상화한 유스케이스 또는 액터와 연결시켜 그룹핑함으로써 이해도를 높이기 위한 관계
- '구체적인 유스케이스'에서 '추상적인 유스케이스' 방향으로 끝부분이 삼각형의 테두로 표현된 화살표를 실선으로 연결하여 표현
5) UMLet
- GPL licence
- www.umlet.com
4.2 유스케이스 다이어그램 작성 순서
액터 식별 - Use Case 식별 - 관계 정의 순
1. 액터 식별
- 액터를 찾기 위한 질문들
- 누가 정보를 제공하고, 사용하고, 삭제하는가?
- 누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가?
2. 유스케이스 식별
- 유스케이스를 찾기 위한 질문들
- 액터가 원하는 시스템 제공 기능은 무엇인가?
- 액터는 시스템에 어떤 정보를 생성, 수정, 조회, 삭제하고 싶어 하는가?
3. 관계를 식별하기 위한 질문
- 연관 관계: 액터와 유스케이스 간에 상호작용이 존재하는가?
- 포함 관계: 이 유스케이스를 실행하기 위하여 반드시 실행되어야 하는 유스케이스가 존재하는가?
- 확장 관계: 이 유스케이스를 실행함으로써 선택적으로 실행되는 유스케이스가 있는가?
- 일반화 관계: 액터 또는 유스케이스가 구체화된 다른 여러 액터나 유스케이스를 가지고 있는가?
4. 유스케이스 명세서 작성
- 액터가 유스케이스로 표현된 목적을 달성하기 위한 시스템과 상호작용하는 단계를 기술
- 유스케이스 기술서 항목
- 유스케이스 명
- 액터 명
- 유스케이스 개요 및 설명
- 사전 및 사후 조건
- 작업 흐름
- 정상 흐름(Normal Flow): 해당 유스케이스가 정상적으로 수행되는 흐름을 표현하는 절차
- 대체 흐름(Alternative Flow): 유스케이스 내의 작업 흐름이 수행되는 중에 특정 시점에서 여러 가지 선택적인 흐름으로 나뉘어질 경우에 발생하는 흐름
- 예외 흐름(Exceptional Flow): 유스케이스 내의 작업 흐름이 수행되는 중에 발생할 수 있는 예외 상황이나 오류를 표현하는 흐름- 시나리오: 각 시나리오는 유스케이스의 특정한 예를 나타냄
- 대체 흐름과 예외 흐름
- 대체 흐름은 유스케이스를 바로 종결시키지 않고 기본 흐름과 다른 경로를 실행
- 예외 흐름은 유스케이스를 비정상적인 상태로 종결함
- 대체 흐름 번호는 단계 번호.문자로 표시
5. 이외 추가적인 내용
- primary actor(주 액터): 시스템을 사용함으로써 실제 가치를 획득하는 액터로, 유스케이스 다이어그램의 왼쪽에 그리는 것이 관례
- secondary actor(부 액터): primary actor가 목적 달성을 위해 지원하는 액터로, 유스케이스의 오른쪽에 나타냄
- 액터가 외부에 있는 시스템일 수도 있음(액터가 사람 모양이 아니라 박스 모양)
-> 액터가 시스템인 경우에는 박스로 나타내고 박스 안에 <<actor>>로 표시 - 액터 간에도 일반화 관계를 사용하여 모델링할 수 있음
- 등록된 사용자와 게스트가 모두 공통적으로 연관이 있는 유스케이스는 사용자와 연관 관계를 맺도록 조정
-> 액터가 사용할 수 있는 기능은 자식 액터도 해당 기능을 수행할 수 있음 - 유스케이스를 실행하기 위해서는 사전조건이 만족되기를 요구함
4.3 잘못된 유스케이스 다이어그램
- 유스케이스 다이어그램은 흐름도가 아님
- 실행 순서의 관계가 아님
- 한 유스케이스의 실행 단계를 포함 관계를 사용하여 나타내는 것이 아님
-> 공통된 부분을 뽑아내어 포함 관계 지정
