개발자 끄적끄적
Usecase Diagram 본문
<Modeling>
- 요구사항 분석
- 고객의 문제의 실체를 이해하고 분석하여 분석 모델을 구축
- 설계
- 설계 모델을 통해 고객의 문제를 해결하는 해결책을 표현
- 구현
- 설계 모델을 기반으로 프로그래밍 언어를 통해 소프트웨어(구현 모델) 구축
*분석 모델 : 고객의 요구사항을 모델링
*설계 모델 : 해결책을 모델링
*구현전에 모델링(요구사항분석, 설계 단계 -> 모델링 언어 필요 -> UML(Unified Modeling Language))
<모델의 역할>
- 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토
- 현재 시스템 또는 앞으로 개발할 시스템의 원하는 모습을 가시화
- 시스템을 구축하는 틀 제공
<UML(Unified Modeling Language)>
- 대표적인 시스템 모델링 언어
- 제임스 러버 OMT + 야콥슨 OOSE + 부치 OOAD
- 2015년 UML 2.5
- UML 모델 : 시스템 구조와 행위를 표현
<유스케이스 다이어그램(Usecase Diagram)>
- 유스케이스란 시스템을 사용하는 목적이다
- 시스템을 사용하는 목적들, 즉 유스케이스들을 사용자 관점에서 기술한 다이어그램이며
이 목적 달성을 위한 사용자와 시스템 사이의 상호작용을 보여준다
- 시스템이 제공하는 기능이나 서비스 등을 정의하고, 시스템의 범위를 결정
<유스케이스 다이어그램의 구성요소>
- 액터(Actor) : 사용자
- 관계(Relationship)
- 시스템(System) : 게시판
- 유스케이스(Usecase) : 글을 등록한다
- 유스케이스는 액터의 사용목적이자 시스템이 제공하는 기능이나 서비스이다
<시스템(System)>
- 의미 : 만들고자 하는 어플리케이션
- 표기법 : 유스케이스를 둘러싼 사각형의 틀을 그리고, 시스템의 명칭을 사각형 안쪽 상단에 기술
<액터(Actor)>
- 의미 : 시스템의 외부에 있으면서 시스템과 상호 작용을 하는 사람 또는 다른 시스템
- 표기법
- 원과 선을 조합하여 사람 모양으로 표현
- 그 위 또는 아래에 액터명 표시
- 액터명은 액터의 역할로 정한다
<유스케이스(Usecase)>
- 의미
- 시스템이 액터에게 제공해야 하는 기능의 집합
- 시스템의 요구사항을 보여준다
- 표기법
- 타원으로 표시하고 그 안쪽이나 아래쪽에 유스케이스명을 기술
- 유스케이스의 이름은 "~한다" 와 같이 동사로 표현
- 각 유스케이스가 개발될 기능 하나와 연결될 수 있드록 한다
- ex) 글을 등록한다
<관계(Relationship)>
- 의미 : 액터와 유스케이스 사이의 의미 있는 관계
- 종류
- 연관 관계(association)
- 의존관계(dependency)
- 포함관계(include) : 필수적으로 수행하는 관계
- 확장관계(extend) : 선택적으로 수행하는 관계
- 일반화관계(generalization)
<관계>
- 연관 관계(association)
- 유스케이스와 액터간에 상호작용이 있음을 표현
- 유스케이스와 액터를 실선으로 연결
- 포함 관계(include)
- 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
- 포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용
- '포함하는 유스케이스'에서 '포함되는 유스케이스' 방향으로 화살표를 점선으로 연결하여 표현하고 <<include>>라고 표기
- ex)
기능을 포함하는 유스케이스 <<include>> ---> 기능에 포함되는 유스케이스
글을 등록한다 <<include>> ---> 로그인한다
- 확장 관계(extend)
- 확장 기능(Extending) 유스케이스와 확장 대상(Extended) 유스케이스 사이에 형성되는 관계
- 확장 대상 유스케이스를 수행할 떄에 특정 조건에 따라 확장 기능 유스케이스를 수행하기도 하는 경우에 적용
- '확장 기능 유스케이스'에서 '확장 대상 유스케이스' 방향으로 화살표를 점선으로 연결하여 표현하고 <<extend>>라고 표기
- 일반화 관계(generalization)
- 유사한 유스케이스들 또는 액터들을 모아 그들을 추상화한 유스케이스 또는 액터와 연결시켜 그룹핑(Grouping)함으로써
이해도를 높이기 위한 관계
- '구체적인 유스케이스'에서 '추상적인 유스케이스' 방향으로 끝부분이 삼각형 테두리로 표현된 화살표를 실선으로 연결하여 표현
<UMLet>
- GPL licence
- GPL 라이선스를 가지는 소프트웨어를 변경하여 외부에 배포하는 경우에 소스코드를 공개하는 의무를 지닌다
- http://www.umlet.com
<유스케이스 다이어그램 작성 순서>
1. 액터 식별
- 액터 : 외부 시스템이나 사람
- 사용자의 역할 식별
- 외부 시스템 식별
- 액터는 개개의 실체 개체가 아니라 그들이 수행하는 역할이다
- 액터가 시스템인 경우에는 박스로 나타내고 박스 안에 <<actor>> 로 표시한다
- Primary Actor(주액터) : 시스템을 사용함으로써 실제 가치를 획득하는 액터
- 유스케이스 다이어그램의 왼쪽에 그리는 것이 관례이다
- Second Actor(부액터) : Primary Actor가 목적 달성을 위해 지원하는 엑터
- 유스케이스 다이어그램의 오른쪽에 나타낸다
- 액터 간에도 일반화 관계를 사용하여 모델링 할 수 있다
2. Use Case 식별(ex. 글을 등록한다 -> 유스케이스 식별)
- 액터가 요구하는 서비스 식별
- 액터가 요구하는 정보 식별
- 액터가 시스템과 상호작용하는 행위 식별
3. 관계 정의
- 액터간 유스케이스 간의 일반화 정의
- 액터간 유스케이스간의 연관관계 정의
- 유스케이스간 포함, 확장관계 정의
<액터 식별>
- 액터를 찾기 위한 질문들
- 누가 정보를 제공하고, 사용하고, 삭제하는가?
- 누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가?
- 누가 요구사항에 대해 관심을 가지고, 시스템이 만들어낸 결과에 관심이 있는가?
- 누가 시스템이 잘 운영될 수 있도록 유지보수 및 관리를 하는가?
- 개발될 시스템과 상호작용하는 하드웨어나 소프트웨어 시스템은 무엇인가?
<유스케이스 식별>
- 유스케이스를 찾기 위한 질문들
- 액터가 원하는 시스템 제공 기능은 무엇인가?
- 액터는 시스템에 어떤 정보를 생성, 수정, 조회, 삭제하고 싶어하는가?
- 시스템이 어떤 기능을 제공하면 액터의 일상 작업이 효율적이고 편리해지는가?
<관계를 식별하기 위한 질문>
- 연관관계(Association)
- 액터와 유스케이스 간에 상호 작용이 존재하는가?
- 포함관계(Include)
- 이 유스케이스를 실행하기 위하여 반드시 실행되어야 하는 유스케이스가 존재하는가?
- 확장관계(Extend)
- 이 유스케이스를 실행함으로써 선택적으로 실행되는 유스케이스가 있는가?
- 일반화 관계(Generalization)
- 액터 또는 유스케이스가 구체화 된 다른 여러 액터나 유스케이스를 가지고 있는가?
<관계 정의>
- 연관관계(액터 - 유스케이스)
- 일반화관계(유스케이스(액터) - 유스케이스)
- 포함관계, 확장관계(유스케이스 - 유스케이스)
- 유사한 유스케이스를 일반화 관계를 이용하여 그룹핑한다
<유스케이스 명세서 작성>
- 유스케이스 명세서
- 액터가 유스케이스로 표현된 목적을 달성하기 위한 시스템과 상호작용하는 단계를 기술
- 상호작용은 유스케이스 명세서에서 기술된다
- 유스케이스 기술서 항목
- 유스케이스명
- 액터명
- 유스케이스 개요 및 설명
- 사전 조건
- 사후 조건
- 작업 흐름
- 정상흐름(Normal Flow) : 해당 유스케이스가 정상적으로 수행되는 흐름을 표현하는 절차
- 대체흐름(Alternative Flow)
- 유스케이스 내의 작업 흐름이 수행되는 중에 특정 시점에서 여러 가지 선택적인 흐름으로 나뉘
질 경우에 발생하는 흐름
- 대체흐름 번호는 단계, 번호, 문자로 표기한다
- 예외흐름(Exceptional Flow) : 유스케이스 내의 작업 흐름이 수행되는 중에 발생할 수 있는 예외 상황이나 오류를 표현하는 흐름
- 시나리오 : 각 시나리오는 유스케이스의 특정한 예를 나타낸다
- ex) 2a. 비번이 맞지 않는 경우에 "비번 다시 입력" 메시지를 표시한 후 단계 1로 돌아간다
7a. 글쓰기 박스에 글을 쓰지않고 등록한 경우, "내용을 넣으세요"라는 메시지를 표시하고 단계 5로 돌아간다
- 유스케이스명 : 글을 수정한다
- 액터명 : 사용자
- 유스케이스 개요 및 설명 : 사용자는 게시판 글을 수정한다
- 사전조건 : 사용자 및 글이 등록되어야 한다
- 사후죄건 : 수정된 글이 시스템에 등록된다
- 작업 흐름
- 정상흐름
- 1. 사용자는 id와 비번을 입력한다
- 2. 시스템은 id와 비번을 검증한다
- 3. 사용자는 글 수정을 선택한다
- 4. 시스템은 글쓰기 박스에 수정할 글을 가져온다
- 5. 사용자는 글쓰기 박스에서 글을 수정한 후 등록을 한다
- 6. 시스템은 글을 저장한다
- 대체흐름/예외흐름
*여러 함수에서 공통적으로 수행하는 부분은 함수로 분리한다
*등록된 사용자와 게스트가 모두 공통적으로 연관이 잇는 유스케이스(글을 조회, 글을 검색)는 사용자와 연관 관계를 맺도록 조정한다
*사용자가 글을 검색하고 글을 조회할 수 있다는 의미는 자식 액터인 게스트와 등록된 사용자도 글을 검색하고 글을 조회할 수 있다는 의미이다
<대체 흐름과 예외 흐름>
- 대체흐름 : 유스케이스를 바로 종결시키지 않고 기본 흐름과 다른 경로를 실행한다
- 예외 흐름 : 유스케이스를 비정상적인 상태로 종결한다
<로그인 유스케이스 명세서 작성>
- 유스케이스명 : 로그인한다
- 액터명 : 사용자
- 유스케이스 개요 및 설명 : 사용자는 시스템에 로그인한다
- 사전 조건 : 사용자가 등록되어 있어야 한다
- 사후조건 : 시스템에 사용자가 로그인된다
- 작업 흐름
- 정상 흐름
- 1. 사용자는 id, 비번을 입력한다
- 2. 시스템은 id와 비번을 검증한다
- 대체/예외 흐름
- 2a. 비번이 맞지 않는 경우에 "비번 다시 입력" 메시지를 표시한 후 단계 1로 들어간다
<확장 단계>
- 유스케이스명 : 글을 등록한다
- 액터명 : 사용자
- 유스케이스 개요 및 설명 : 사용자가 원하는 글을 게시판에 등록한다
- 사전 조건 : 사용자가 등록되어 있어야 한다
- 사후 조건 : 글이 시스템에 등록된다
- 작업 흐름
- 정상흐름
- 1. 사용자는 로그인 유스케이스를 실행한다
- 2. 사용자는 글쓰기를 선택한다
- 3. 시스템은 글쓰기 박스를 보여준다
- 4. 사용자는 글쓰기 박스에 원하는 글을 작성한다
- 5. {파일 첨부} 사용자는 글을 등록한다
- 6. 시스템은 글을 저장한다
- 대체/예외 흐름
- 6a. 글쓰기 박스에 글을 쓰지 않고 등록 원하는 경우, "내용을 넣으세요"라는 메시지를 표시하고 단계 3으로 돌아간다
*확장관계를 사용하여 유스케이스가 수행하는 추가 기능을 명시적으로 표현
*유스케이스를 실행하기 위해서는 사전조건이 만족되기를 요구한다
<변경 후, 유스케이스 명세서 작성>
- 유스케이스명 : 글을 등록한다
- 액터명 : 사용자
- 유스케이스 개요 및 설명 : 사용자가 원하는 글을 게시판에 등록한다
- 사전 조건 : 사용자가 등록되어 있어야 한다
- 사후 조건 : 글이 시스템에 등록된다
- 작업 흐름
- 정상흐름
- 1. 사용자는 글쓰기를 선택한다
- 2. 시스템은 글쓰기 박스를 보여준다
- 3. 사용자는 글쓰기 박스에 원하는 글을 작성한다
- 4. {파일 첨부} 사용자는 글을 등록한다
- 5. 시스템은 글을 저장한다
- 대체/예외 흐름
- 4a. 글쓰기 박스에 글을 쓰지 않고 등록 원하는 경우, "내용을 넣으세요"라는 메시지를 표시하고 단계 3으로 돌아간다
*따라서 유스케이스 실행 중에 로그인 유스케이스가 실행되는게 아니라 미리 로그인 유스케이스가 실행되기를 요구한다
<<extend 관계>>
- 확장점 1, 2에서 extending use casr가 Use Case의 행위를 확장한다
- 확장 관계는 행위를 추가 하고자 할 때 사용한다
- 확장점 : 확장 대상 유스케이스에서 확장(추가)기느이 수행되는 기점
- 확장점 : {파일 첨부} 여기에서 "파일을 첨부하다" 유스케이스가 실행된다
<관계를 고려한 유스케이스 다이어그램 해석>
- S라는 시스템에서 액터 A가 U라는 유스케이스와 연관이 있는 경우에는
- 'A는 U라는 목적을 달성하기 위해 S와 상호작용한다.' 로 해석한다
- U가 U1과 포함관계(Include)에 있는 경우에는 필수적 관계이므로
- 'A는 U라는 목적을 달성하기 위해 S와 상호작용한다. U를 하기 위해서는 U1을 "반드시" 수행한다.' 로 해석한다
- U가 U2와 확장관계에 있는 경우에는 선택적 관계이므로
- 'A는 U라는 목적을 달성하기 위해 S와 상호 작용한다. 경우에 따라 U2가 수행된다.'로 해석한다.
- 만약 U 유스케이스가 U1, U2, U3 사이에 일반화 관계가 있다면
- 'A는 U라는 목적을 달성하기 위해 S와 상호작용한다. U의 종류로 U1, U2, U3이 있다.'로 해석한다
<잘못된 유스케이스 다이어그램>
- 유스케이스 다이어그램은 흐름도가 아니다. 즉, 유스케이스간의 실행 순서관계는 유스케이스 다이어그램에서는 나타나지 않는다
- ex. include, extend, association, generaliation
- 한 유스케이스의 실행 단계를 포함관계를 사용하지 나타내지 말 것
'소프트웨어공학' 카테고리의 다른 글
클래스 다이어그램(Class Diagram) (0) | 2024.04.11 |
---|---|
프로토타입(Prototype) (0) | 2024.04.01 |
요구사항 명세 (0) | 2024.03.27 |