가이드라인: 유스 케이스
주제
다음과 같이 이러한 정의에는 몇 가지 핵심 단어가 있습니다.
- 유스 케이스 인스턴스. 정의에서 언급되는 순서는
실제로 시스템을 통한 특정 이벤트 플로우이거나 인스턴스입니다. 많은 이벤트 플로우가
가능하지만 대다수가 매우 유사할 수 있습니다.
유스 케이스 모델을 이해 가능하게 만드려면 비슷한 이벤트 플로우를 하나의
유스 케이스로 묶어야 합니다. 유스 케이스를 식별하고 설명하는 것은
실제로 관련된 이벤트 플로우 그룹을 식별하고 설명하는 것을 의미합니다.
- 시스템 수행사항. 이것은 시스템이 유스 케이스를 제공한다는
것을 의미합니다. 액터는 시스템의 유스 케이스 인스턴스와 통신합니다.
- 관측 가능한 결과 값. 성공적으로 수행된 유스 케이스에
값을 넣을 수 있습니다. 유스 케이스는 액터가 식별 가능한 값을 가진
타스크를 수행할 수 있는지 확인해야 합니다. 이것은 유스 케이스의 올바른
레벨 또는 단위 정보를 판별할 때 매우 중요합니다. 올바른 레벨은
너무 작지 않은 유스 케이스를 달성하는 것을 말합니다. 어떤 경우에는
시스템의 액터인 개인을 포함하는 조직에서 계획 단위로 유스 케이스를 사용할 수 있습니다.
- 조치. 조치는 계산적 또는 알고리즘적인 프로시저입니다. 이것은 액터가 시스템에 신호를 제공하거나 시스템이 시간 이벤트를 받는
경우 호출됩니다. 조치는 호출하는 액터 또는 기타 액터에게
신호를 전달하는 것을 내포할 수 있습니다. 조치는 전체적으로 수행되거나
전혀 수행되지 않는다는 점에서 원자적입니다.
- 특정 액터. 액터는 특히 액터가 너무 큰 유스 케이스를
피할 수 있도록 도와주기 때문에 올바른 유스 케이스를 찾는 관문입니다. 한 예로
비주얼 모델링 툴을 생각해봅시다. 이 어플리케이션에는 실제로 두 명의
액터가 있습니다. 지원으로 툴을 사용하여 시스템을 개발하는 개발자와
툴을 관리하는 시스템 관리자입니다. 이러한 각 액터는
시스템에 대한 자신만의 요구사항이 있으므로 자신만의 유스 케이스를 필요로 합니다.
시스템 기능은 각각 특정 이벤트 플로우를 나타내는 다른 유스 케이스로 정의됩니다. 유스 케이스 설명은 유스 케이스가 수행될 때 시스템에서 발생하는 사항에 대해 정의합니다.

예를 들어, 자동 금전 출납 시스템에서 고객은 계좌에서 돈을 인출하거나 계좌에 돈을
송금하거나 계좌 잔고를 확인할 수 있습니다. 이러한 기능이 유스 케이스로 나타낼
수 있는 플로우에 해당합니다.
각 유스 케이스는 수행할 자신만의 타스크를 갖습니다. 수집된 유스 케이스는
가능한 모든 시스템 사용법을 구성합니다. 단순히 이름만 보고도 유스 케이스 타스크에 대해
알 수 있습니다.
다음은 유스 케이스를 식별할 때 유용한 질문사항입니다.
- 식별한 각 액터에 대해 해당 시스템이 개입된 타스크는 무엇입니까?
- 시스템의 특정 발생사건에 대해 액터에게 알려야 합니까?
- 액터는 갑작스런 외부 변경사항에 대해 시스템으로부터 통지받아야 합니까?
- 시스템은 올바른 작동으로 비즈니스를 지원합니까?
- 식별한 유스 케이스로 모든 기능을 수행할 수 있습니까?
- 시스템을 지원하고 유지보수하는 유스 케이스는 무엇입니까?
- 시스템에서 수정되었거나 작성되어야 하는 정보는 무엇입니까?
보통 시스템의 기본 기능으로 나타나지 않기 때문에 종종 간과되는 유스 케이스는
다음과 같은 유형일 수 있습니다.
- 시스템 시작 및 중지.
- 시스템 유지보수(예: 새 사용자 추가 및 사용자 프로파일 설정).
- 시스템에 저장된 데이터 유지보수(예: 시스템이 레거시 시스템과
동시에 작업하도록 구성되었고 둘 사이에서 데이터를 동기화해야 할 때).
- 시스템에서 작동을 수정해야 하는 기능(예: 새 보고서 작성 기능).
구현 단계의 초반 반복에서는 소수의 유스 케이스만(구조적으로 중요한 것으로
간주되는 것) 간략한 설명을 넘어서 자세히 설명됩니다. 항상 세부적으로 파고 들기
전에 먼저 유스 케이스 개요(단계 별로)를 개발해야 합니다. 이 단계별 개요는
유스 케이스의 이벤트 플로우 구조를 정의할 때 첫 번째 작업이어야 합니다(아래의
이벤트 플로우 - 구조 참조). 항상 기본적인
유스 케이스 플로우부터 시작하십시오. 일단 기본 플로우 개요에 대한 몇 가지
합의가 있으면 기본 플로우와 관련된 다른 플로우를 추가할 수 있습니다.
구현 단계 끝까지 세부적으로 설명하려는 모든 유스 케이스를 완성해야 합니다.
종종 이벤트 플로우에 대한 자세한 설명이 필요없을 만큼 단순하여 단계별 개요만으로
충분한 유스 케이스가 모델에 있습니다. 이러한 의사결정의 기준은 유스
케이스가 의미하는 것에 대해 독자인 사용자들의 의견 차이가 없고
설계자와 테스터가 단계별로 제공되는 세부사항 레벨에 만족하는 것입니다. 시스템의
일부 데이터에 대한 단순 입력 또는 검색을 설명하는 유스 케이스가 한 예입니다.
종종 사용자 시스템 상호작용 세트 또는 대화 상자의 유스 케이스가 하나인지 또는
여러 개인지 판단하기 어렵습니다. 재활용 시스템 사용을 생각해봅시다. 고객은
캔, 병, 나무 상자와 같은 적립금 항목을 재활용 시스템에 삽입합니다. 모든
적립금 항목을 삽입하면 단추를 누르고 영수증을 인쇄합니다. 그런 후 이 영수증을
돈과 교환할 수 있습니다.
이것이 적립금 항목을 삽입하는 유스 케이스 하나와 영수증을 필요로 하는 다른
한 개의 유스 케이스입니까? 또는 모두 하나의 유스 케이스입니까? 여기에는
두 가지 조치가 있지만 다른 한 조치가 빠진 조치는 고객에게 큰 의미가
없습니다. 오히려 고객에게 가치 있는 전체 대화 상자는 모든 삽입과
영수증 확보를 포함한 것입니다. 따라서 먼저 적립금 항목 삽입에서부터
단추를 누르고 영수증를 확보하는 것까지의 전체 대화 상자가 전체 유스 케이스인 하나의
유스 케이스입니다.
또한 두 조치를 함께 유지하여 두 가지를 동시에 검토하고 함께 수정하며
함께 테스트하고 매뉴얼을 작성하며 일반적으로 한 단위로 관리하고자 할 수 있습니다. 이것은
대형 시스템에서 매우 명백합니다.
유스 케이스는 액터가 유스 케이스를 실행하기 위해 시스템과 상호작용할 때
시스템에서 발생하는 사항에 대해 설명합니다. 유스 케이스는 객체 협업 측면에서
시스템이 내부적으로 타스크를 수행하는 방식을 정의하지 않습니다. 이것은
표시할 유스 케이스 구현을 위해 남겨져 있습니다.
예:
전화 예에서 유스 케이스는 수화기를 들 때 시스템이
신호를 내면 시스템이 전화번호를 수신하고 수신 상대방을 찾으며
전화를 울리고 통화자에게 연결하며 음성을 전달하는 것 등을 표시합니다.
실행 시스템에서 유스 케이스 인스턴스는 구현 모델의 특정 객체(예:
코드의 클래스 인스턴스)에 대응하지 않습니다. 대신 액터에 의해 호출되고
객체 세트 사이에서 일련의 이벤트로 실행되는 특정 이벤트 플로우에 대응합니다.
다시 말해 유스 케이스 인스턴스는 구현된 객체 인스턴스 통신에 대응합니다. 이것을 유스 케이스 구현이라고 합니다. 종종 동일한 객체가
둘 이상의 유스 케이스 구현에 관련됩니다. 예를 들어, 뱅킹 시스템에서
예금 및 인출 유스 케이스는 모두 특정 계좌 객체를 구현에 사용할 수 있습니다. 이것은 두 개의 유스 케이스가 통신한다는 것을 의미하는 것이 아니라
동일한 객체를 구현에 사용한다는 것만 의미합니다.
전체 이벤트 플로우에서 함께 사용되는
여러 개의 서브플로우로 구성된 이벤트 플로우를 볼 수 있습니다. 다른 유스 케이스의
이벤트 플로우에서 서브플로우 설명을 다시 사용할 수 있습니다. 한 유스 케이스의
이벤트 플로우 설명에 있는 서브플로우가 다른 유스 케이스의 이벤트 플로우 설명에 있는
서브플로우와 일치할 수 있습니다. 설계에서 모든 관련 유스 케이스에 대해 동일한 객체는
이러한 공통 작동을 수행하도록 해야 합니다. 즉, 유스 케이스에서 실행하는 것이 무엇이든
한 세트의 객체만 이 작동을 수행해야 합니다.
예:
자동 금전 출납 시스템에서 초기 서브플로우는
예금 인출과 잔고 확인 유스 케이스의 이벤트 플로우에서 모두 동일합니다. 고객의 개인 액세스 코드와 카드의 신원을 확인하면서 두 유스 케이스의 이벤트 플로우가 시작됩니다.
유스 케이스 인스턴스는 거의 무제한적이지만 열거 가능한 수의 경로를 따라갈 수 있습니다. 이러한 경로는 이벤트 플로우 설명에서 유스 케이스 인스턴스에게 열려 있는 선택사항을 나타냅니다. 선택되는 경로는 이벤트에 따라 달라집니다. 이벤트 유형에는 다음 사항이 포함됩니다.
- 액터로부터의 입력 정보. 예를 들어, 액터는 여러 가지 옵션 중에서 다음 번에
수행할 사항을 결정할 수 있습니다.
예:
재활용 시스템의 유스 케이스 재활용품에서
고객은 항상 기존의 다른 적립금 항목을 손에 쥐느냐 리턴된 항목의
영수증을 받느냐 하는 두 가지 옵션을 갖습니다.
- 내부 객체 또는 속성의 유형 또는 값 확인. 예를 들어, 값이 특정 값보다 크거나
작은 경우 이벤트 플로우가 달라질 수 있습니다.
예:
자동 금전 출납 시스템의 예금 인출 유스 케이스에서
고객이 계좌에 있는 것보다 많은 돈을 요구하는 경우 이벤트 플로우가 달라집니다. 따라서
유스 케이스는 다른 경로를 따라가게 됩니다.
몇 가지 유스 케이스 인스턴스와 동일한 유스 케이스의 몇 가지 인스턴스는
시스템이 허용하는 경우 동시에 작동합니다. 유스 케이스 모델링에서
유스 케이스 인스턴스가 충돌 없이 동시에 활성화될 수 있다고 가정할 수 있습니다. 유스 케이스 모델링이 작동 방식을 설명하지 않기 때문에 설계 모델이
이 문제점을 해결해야 합니다. 이것을 보는 한 가지 방법은
한 번에 하나의 유스 케이스 인스턴스만 활성화하고 이 인스턴스를 자동 조치로
실행하는 것입니다. 유스 케이스 모델링에서 "해석 시스템"은 무제한
빠르다고 가정되므로 유스 케이스 인스턴스의 직렬 실행은 문제가 안됩니다.
각 유스 케이스는 액터와의 상호작용으로 수행되는 사항을 보여주는 이름을 가지고
있어야 합니다. 이름은 몇 가지 단어로 이해할 수 있어야 합니다. 두 가지 유스 케이스가 동일한 이름을 가질 수 없습니다.
예:
다음은 재활용 시스템에서 유스 케이스 재활용품 이름의 여러 가지 예입니다.
- 적립금 항목 받기
- 적립금 항목 받는 중
- 적립금 항목 리턴
- 적립금 항목
유스 케이스의 간략한 설명은 그 목적을 반영해야 합니다. 설명을 작성할 때
유스 케이스에 포함된 액터 및 용어집을 참고하고 필요한 경우 새 개념을 정의하십시오.
예:
다음은 재활용 시스템의 유스 케이스 재활용품 및
새 병 유형 추가 유스 케이스에 대한 간략한 설명의 예입니다.
재활용품: 사용자는 이 시스템을 사용하여
자동으로 모든 리턴 항목(병, 캔 및 나무 상자)을 세고 영수증을 수령합니다. 영수증은 금전 등록기(시스템)에서 현금화됩니다.
새 병 유형 추가: '학습 모드'에서 시작하여
항목 리턴 시와 마찬가지로 5개 샘플을 삽입하여 시스템에 새로운 유형의
병을 추가할 수 있습니다. 이 때 시스템은 병의 치수를 재어 식별할 수 있습니다. 관리자는 새 병 유형의 환불값을 지정합니다.
유스 케이스의 이벤트 플로우에는 유스 케이스 모델링 작업에서 나온
가장 중요한 정보가 들어 있습니다. 초보자도 쉽게 이해할 수 있도록
유스 케이스의 이벤트 플로우를 분명하게 설명해야 합니다.
이벤트 플로우는 필요한 작동을 수행하는 시스템의 설계 방식이 아닌
시스템의 수행사항을 제공해야 합니다.
이벤트 플로우 컨텐츠에 대한 가이드라인은 다음과 같습니다.
- 유스 케이스가 시작되고 종료되는 방법을 설명합니다.
- 액터와 유스 케이스 사이에서 교환되는 데이터를 설명합니다.
- 시스템 작동을 이해해야 하는 경우가 아닌 한 사용자 인터페이스 세부사항을 설명하지 않습니다. 예를 들어, 종종 어플리케이션이 웹 기반이 될 것이라는 것을 미리 아는 경우
제한된 수의 웹 특정 용어를 사용하는 것이 좋습니다. 그렇지 않으면 유스 케이스 텍스트가 너무 추상적으로 인식되는 위험을
감수해야 합니다. 용어에 포함시키는 단어는 "탐색", "찾아보기",
"하이퍼링크" "페이지", "제출" 및 "브라우저"일
수 있습니다. 그러나 "프레임" 또는 "웹 페이지"에 대한 언급을
포함시키는 것은 바람직하지 않습니다. 이들은 결정적인 설계 의사결정 사항입니다.
- 기능만이 아닌 이벤트 플로우를 설명합니다. 이를 수행하려면
모든 조치를 "액터가...할 때"로 시작하십시오.
- 다른 유스 케이스 또는 시스템 밖에서 발생하는 사항을 제외한
해당 유스 케이스에 속한 이벤트만 설명합니다.
- "예를 들어", "등", "정보"와 같은 모호한 용어를 피합니다.
- 모두 "무엇"에 대해 응답해야 하는 이벤트 플로우를 세부화합니다.
테스트 설계자는 테스트 케이스를 식별하는 데 이 텍스트를 사용합니다.
다른 유스 케이스에서 특정 용어를 사용할 때 이 유스 케이스에서
의도하는 의미와 같은 경우 정확히 동일한 용어를 사용해야 합니다. 공통 용어로
관리하려면 용어집에 추가하십시오.
이벤트 플로우의 기본적인 두 부분은 기본 이벤트 플로우와
선택적 이벤트 플로우입니다. 기본 이벤트 플로우는
유스 케이스를 수행할 때 "일반적으로" 발생하는 사항을 다루어야 합니다. 선택적
이벤트 플로우는 일반 작동과 비교하여 선택적이거나 예외적인 작동을 다루고
일반 작동의 변종을 다루어야 합니다. 일부는 기본 이벤트 플로우로 돌아가고
일부는 유스 케이스 실행을 종료하므로, 기본 이벤트 플로우에서 대체 이벤트 플로우로
"되돌아 간다고" 간주할 수 있습니다.

이벤트 플로우의 전형적인 구조. 직선 화살표는
기본 이벤트 플로우를 나타내고 곡선은 일반적인 것과 비교하여 선택적인
경로를 나타냅니다. 일부 선택적 경로는 기본 이벤트 플로우로 돌아가고
나머지는 유스 케이스를 종료합니다.
기본 이벤트 플로우 및 선택적 이벤트 플로우 모두는 단계별로 또는
서브플로우로 좀더 체계화되어야 합니다. 이를 수행할 때 주요 목적은
텍스트를 쉽게 읽을 수 있어야 한다는 것 입니다(아래의 이벤트 플로우 -
양식도 참조). 원칙은 서브플로우가 명백한 목적을 가진 유스 케이스에서
작동 세그먼트여야 하며, 설명된 조치를 모두 수행하거나 전부 수행하지 않는다는
점에서 "원자적"이라는 것 입니다. 몇 가지 레벨의 서브플로우를 가지고 있어야
할 수 있지만 가능한 한 텍스트를 복잡하게 하고 이해하기 어렵게 하는 것은 피해야 합니다.
활동 다이어그램으로 이벤트 플로우 구조를 설명할 수 있습니다(가이드라인:
유스 케이스의 활동 다이어그램 참조).
연속되는 서브섹션으로 구조화된 이러한 유형의 작성된 텍스트는 본질적으로
서브플로우 간에 순서가 있음을 독자에게 내포합니다. 오해를 막기 위해
항상 서브플로우 순서의 고정 여부를 지정해야 합니다. 이러한 유형의 고려사항은 종종 다음과 관련됩니다.
- 비즈니스 규칙. 예를 들어, 시스템이 특정 데이터를 사용 가능하게 하기 전에
사용자에게 권한 부여가 되어야 합니다.
- 사용자 인터페이스 설계. 예를 들어, 시스템은 일부 사용자에게만
이해될 수 있는 특정 작동 순서를 실행해서는 안됩니다.
구조에서 선택적 이벤트 플로우가 적절한 위치를 명백히 하려면
기본 이벤트 플로우로 "되돌아 가는" 각 방법에 대해 다음을 설명해야 합니다.
- 선택적 이벤트 플로우를 삽입할 수 있는 기본 이벤트 플로우의 위치.
- 선택적 작동을 시작하기 위해 충족되어야 하는 조건.
- 기본 이벤트 플로우의 재개 방법과 위치 또는 유스 케이스의 종료 방법.
예:
이것은 기계 재활용 시스템에서 유스 케이스 리턴 항목의 대체 서브플로우입니다.
2.1. 끼인 병
섹션 1.5 적립금 항목 삽입에서 병이 문에 끼인 경우
문 주위의 센서와 측정 문이 이 문제점을 감지합니다. 컨베이어 벨트가 중지되고
시스템이 알람을 울려 조작원을 호출합니다. 시스템은 조작원이 해당 문제점을
수정했다고 알려줄 때까지 대기합니다. 그런 후 시스템은 기본 플로우의 섹션 1.9에서
계속됩니다.
위 예에서 선택적 이벤트 플로우는 기본 이벤트 플로우의 특정 위치에 삽입됩니다. 또한 둘 이상의 위치에 삽입될 수 있는 선택적 이벤트 플로우도 있고
심지어 일부는 기본 이벤트 플로우의 어느 위치에나 삽입될 수 있습니다.
예:
이것은 기계 재활용 시스템에서 유스 케이스 리턴 항목의 대체 서브플로우입니다.
2.2. 전면 패널 제거
누군가 재활용 시스템의 전면 패널을 제거한 경우 캔
압축이 비활성됩니다. 전면 패널이 벗겨진 상태에서 캔 압축을 시작할 수 없습니다. 제거는 또한 조작원에게 알람을 활성화합니다. 전면 패널이 다시 닫히면
시스템은 기본 이벤트 플로우가 중지된 위치에서부터 조작을 재개합니다.
선택적 이벤트 플로우가 매우 간단한 경우 기본 이벤트 플로우 섹션에서
설명만 하는 것이 좋아보일 수 있습니다(몇 가지 비공식적인 "if-then-else"
구성 사용). 그러나 그것은 피해야 합니다. 너무 많은 선택사항으로 인해
일반 작동을 알아보기 어렵게 됩니다. 또한 기본 이벤트 플로우 섹션에
선택적 경로를 포함시키면 텍스트가 "의사 코드와 유사하게" 되어 쉽게 읽을 수 없게 됩니다.
일반적으로 이벤트 플로우 일부를 뽑아내어 별도로 설명하게 되면
기본 이벤트 플로우를 쉽게 읽을 수 있게 되고 유스 케이스 및 유스 케이스 모델의
구조가 개선될 수 있습니다. 다음과 같이 추출한 부분을 모델링할 수 있습니다.
- 기본 이벤트 플로우의 단순한 변형, 옵션 또는 예외에 해당하는 기본 유스 케이스의
선택적 이벤트 플로우.
- 다른 유스 케이스에서 다시 사용할 수 있도록 요약하려는 경우
기본 유스 케이스의 명시적 포함(가이드라인: 포함 관계 참조)으로.
- 기본 유스 케이스의 기본 이벤트 플로우가 그 시작 및 끝이 정의되어
완전한 경우 기본 유스 케이스의 암시적 포함(가이드라인: 확장 관계 참조)으로. 확장 플로우의 본질은 보다 덜 복잡할 수 있도록 기본 유스 케이스의 설명에
숨기는 것이어야 합니다.
- 위 선택사항 중 어느 것도 해당되지 않는 경우 다른 옵션으로 기본 이벤트 플로우의
서브플로우. 예를 들어, 직원 정보 관리 유스 케이스에는 직원 정보를 추가, 삭제 및
수정하는 별도의 서브플로우가 있을 수 있습니다.
여러 가지 양식으로 유스 케이스를 설명할 수 있습니다. 한 예로 기본적으로
공식적인 모습과 세 가지 다른 양식으로 설명된 주문 관리 유스 케이스의
기본 이벤트 플로우가 있습니다. 첫 번째 양식(아래 예
1 참조)은 이해하기 쉽고 발생 순서가 분명하게 보이기 때문에
권장됩니다. 텍스트는 번호가 매겨지고 이름이 지정된 서브섹션으로 나뉩니다. 서브섹션을 참조하기 쉽게하기 위해 번호를 해주므로 지정합니다.
서브섹션 이름은 독자가 머리글만을 읽고 텍스트를 살펴보는 것만으로도
이벤트 플로우에 대한 빠른 개요를 얻을 수 있게 해줍니다.
아래 예 2의 이벤트 플로우 설명은
발생 순서를 명확히 보여주지 못합니다. 이 양식으로 작성하는 경우
시스템과 관련된 중요한 사항을 놓칠 수 있습니다.
아래 예 3은 이벤트 순서를 명확히 표현하기
어려운 경우 사용할 수 있는 또 다른 양식을 보여줍니다. 이 의사 코드 양식은
보다 정밀하지만 기술에 대한 초보자가 텍스트를 읽고 이해하기는 어렵습니다(특히 이벤트 플로우를 신속하게
파악해야 하는 경우).
1.1. 유스 케이스 시작
이 유스 케이스는 조작원 액터가 시스템에게 견적 주문 작성을
명령하면 시작됩니다. 그런 다음 시스템은 이 특정 조작원에게 사용 가능한
모든 네트워크 요소 액터, 측정 객체 및 대응되는 측정 기능을 검색합니다. 사용 가능한 네트워크 요소는 조작 중이고 조작원에게 액세스 권한이 있는 것입니다.
측정 기능의 사용 가능성 여부는 측정 객체의 특정 유형에 대한 설정에 따라 다릅니다.
1.2. 견적 주문 형상
시스템은 조작원 액터가 측정할 네트워크 요소를 선택할 수 있게 한 후
선택한 네트워크 요소에 사용 가능한 측정 객체를 표시합니다. 시스템은 조작원이
측정 객체 중에서 선택한 다음 각 측정 객체에 설정할 측정 기능을 선택할 수 있게 합니다.
시스템을 통해 조작원은 견정 주문에 텍스트로 된 설명을 입력할 수 있습니다.
조작원은 시스템에 견적 주문 완료를 명령합니다. 시스템은
견적 주문의 고유 이름을 생성하고 측정 시기, 빈도 및 기간에 대한 기본값을 설정하여
응답합니다. 기본값은 각 조작원에게 고유합니다.
그 다음, 시스템은 조작원이 이러한 기본값을 편집할 수 있게 합니다.
1.3. 주문 초기화
조작원은 시스템에 견적 주문 초기화를 명령합니다. 그 다음, 시스템은 작성하는 조작원의 ID, 작성 날짜 및 견적 주문의 "스케줄" 상태를 기록합니다.
1.4. 유스 케이스 종료
시스템은 조작원에게 견적 주문 초기화를 확인하고
다른 액터가 견적 주문을 볼 수 있게 됩니다. |
유스 케이스 설명: 이 양식에서
텍스트는 읽기 쉽고 이벤트 플로우는 따라가기 쉽습니다. 설명에서 이와 같은
양식을 목표로 삼으십시오.
주문자는 주문을 작성하여 네트워크 요소에서 견적 데이터를 수집할 수 있습니다.
시스템은 주문에 고유 이름 뿐만 아니라 견적 길이 및 시간과
반복 빈도를 표시하는 기본값을 지정합니다. 주문자는 이러한 값을 편집할 수 있습니다.
주문자는 적절한 측정 기능, 네트워크 요소 및 측정 객체를 더 지정해야 합니다. 또한 주문자는 주문에 개인적인 설명을 추가할 수도 있습니다.
필요한 정보가 정의되면 새 주문이 작성되고 정의된 속성, 작성자 이름 및
작성 날짜를 사용하여 초기화됩니다. 주문 상태는 "스케줄"로
설정됩니다(가능한 상태 값: 스케줄, 실행 중, 완료, 취소, 오류).
그 다음 사용자 인터페이스에 새 주문이 작성되었고
새 주문에 대한 언급을 받아 표시할 것임이 알려집니다. |
유스 케이스 설명: 이 양식은 읽기 쉽지만 이벤트 플로우가 모호합니다.
'Administrate order' (User identity)
REPEAT
<='Show administer order menu'
IF (=> 'Creating an Order' (Measurement function,
network element, measurement object)) THEN
The system finds a unique name, default values for when and
how long the measurement should be executed.
<= 'Show order' (Default attributes)
REPEAT
=> 'Edit order' (Attribute to change, New value of attribute)
<= 'Update screen' (New attributes)
UNTIL (All attributes are defined)
REPEAT
IF (=> 'Edit order' (Attribute to change, New value of attribute))
THEN <= 'Update screen' (New attributes)
ELSIF (=> 'Save order' (Order identity, Attributes)) THEN
The order is created and initialized in the system with
the defined attributes, the name of the creator,
date of creation and the status 'scheduled'.
<= 'New order created' (The order)
ENDIF
UNTIL (=> 'Quit')
ENDIF
UNTIL 'Quit administer order'
|
유스 케이스 설명: 여기에서 작성자는
의사 코드를 사용하여 공식 양식을 선택했습니다. 이 양식은 프로세스 단계를 신속하게
파악하기는 어렵지만 이벤트 플로우를 정확히 파악하기 어려운 경우 유용할 수 있습니다.
선택적 플로우를 포함하여 주문 관리 유스 케이스의 이벤트 플로우에 대한
전체 설명은 다음과 같습니다.
1.기본 이벤트 플로우
1.1. 유스 케이스 시작
이 유스 케이스는 조작원 액터가 시스템에게 견적 주문 작성을
명령하면 시작됩니다. 그런 다음 시스템은 이 특정 조작원에게 사용 가능한
모든 네트워크 요소 액터, 측정 객체 및 대응되는 측정 기능을 검색합니다. 사용 가능한 네트워크 요소는 조작 중이고 조작원에게 액세스 권한이 있는 것입니다. 측정 기능의 사용 가능성 여부는 측정 객체의 특정 유형에 대한 설정에 따라 다릅니다.
1.2. 견적 주문 형상
시스템은 조작원 액터가 측정할 네트워크 요소를 선택할 수 있게 한 후
선택한 네트워크 요소에 사용 가능한 측정 객체를 표시합니다. 시스템은 조작원이
이들 측정 객체 중에서 선택한 다음 각 측정 객체에 설정할 측정 기능을 선택할 수 있게 합니다.
시스템은 조작원이 견적 주문에 텍스트로 된 설명을 입력할 수 있도록 합니다.
조작원은 시스템에 견적 주문 완료를 명령합니다. 시스템은
견적 주문의 고유 이름을 생성하고 측정 시기, 빈도 및 기간에 대한 기본값을 설정하여
응답합니다. 기본값은 각 조작원에게 고유합니다. 그 다음, 시스템은 조작원이 이러한 기본값을 편집할 수 있게 합니다.
1.3. 주문 초기화
조작원은 시스템에 견적 주문 초기화를 명령합니다. 그 다음, 시스템은 작성하는 조작원의 ID, 작성 날짜 및 견적 주문의 "스케줄" 상태를 기록합니다.
1.4. 유스 케이스 종료
시스템은 조작원에게 견적 주문 초기화를 확인하고
다른 액터가 견적 주문을 볼 수 있게 됩니다.
2. 선택적 이벤트 플로우
2.1. 사용 가능한 네트워크 요소가 없는 경우
1.1, 유스 케이스 시작에서 이 조작원에 대해 측정 가능한 네트워크 요소가
없다는 것이 판명된 경우 시스템은 조작원에게 이 사실을 알려줍니다. 그러면 유스 케이스가 종료됩니다.
2.2. 사용 가능한 측정 기능이 없는 경우
1.2, 견적 주문 형상에서 선택한 네트워크 요소에 대해 사용 가능한 측정 기능이
없는 경우 시스템은 조작원에게 알리고 조작원은 다른 네트워크 요소를 선택할 수 있습니다.
2.3. 견적 주문 취소
시스템은 조작원이 유스 케이스 실행 중 언제든지 모든 조치를 취소할 수 있게
허용합니다. 그런 다음 시스템은 유스 케이스가 시작되기 전의 상태로
돌아가고 유스 케이스를 종료합니다.
유스 케이스의 특수 요구사항에서는 이벤트 플로우에서 다루어지지 않은 유스
케이스의 모든 요구사항을 설명합니다. 이것은 설계 모델에 영향을 미치는
비기능적 요구사항들입니다. 가이드라인: 유스 케이스 모델에 있는
비기능적 요구사항에 대한 논의도 참조하십시오. 이러한 요구사항을 사용성, 신뢰성, 성능 및 대용성과
같은 범주로 체계화할 수 있지만 일반적으로 이러한 범주화에
특별히 가치 부여를 하지 않으므로 소수만 존재합니다.
예:
재활용 시스템에서 적립금 항목 리턴 유스 케이스의
특수 요구사항은 다음과 같을 수 있습니다.
시스템이 95% 이상의 신뢰성을 가지고 적립금 항목을
인식할 수 있어야 합니다.
전졔 조건 및 사후 조건 개념은 이벤트 플로우가 시작되고
종료되는 방식을 명확하게 설명할 때 유용할 수 있습니다. 그러나
유스 케이스 사용자가 여기에 가치 부여를 하는 경우에만 사용하십시오.

전졔 조건은 유스 케이스를 시작하기 위해 요구되는
시스템 및 그 환경에 대한 상태입니다. 사후 조건은 유스 케이스가 종료된 후
시스템에 있을 수 있는 상태입니다.
다음 사항을 고려하십시오.
- 사전 또는 사후 조건으로 설명되는 상태는 사용자가 관찰할 수 있는
상태여야 합니다. "사용자가 시스템에 로그온했습니다" 또는
"사용자가 문서를 열었습니다"가 관찰 가능한 상태의 예입니다.
- 전졔 조건은 유스 케이스가 시작될 때의 제한조건입니다. 이것은 유스 케이스를 시작하는 이벤트가 아닙니다.
- 서브플로우 레벨에서 전졔 조건과 사후 조건을 정의할 수 있지만
유스 케이스의 전졔 조건은 오직 한 서브플로우의 전졔 조건이 아닙니다.
- 유스 케이스의 사후 조건은 선택적 플로우 실행 여부와 상관없이
참이어야 합니다. 기본 플로우의 경우에만 참이어서는 안됩니다. 실패할
가능성이 있는 경우, 단순히 "조치가 완료되었습니다"보다는
"조치가 완료되었거나 혹은 실패한 경우 조치가 수행되지 않았습니다"를 지정하여
사후 조건에서 해당 사항을 처리합니다.
- 확장 관계와 함께 사후 조건을 사용하는 경우 확장하는 유스 케이스가
기본 유스 케이스의 사후 조건을 위반하는 서브플로우를 포함하지 않도록 주의를
기울여야 합니다.
- 사후 조건은 유스 케이스를 설명하는 강력한 툴일 수 있습니다. 먼저
유스 케이스가 도달한다고 추정되는 사항(사후 조건)을 정의합니다.
그런 후 이 조건에 도달하는 방식(필요한 이벤트 플로우)을 설명할 수 있습니다.
예:
ATM 시스템에서 현금 인출 유스 케이스의 전졔 조건:
고객은 카드 판독기에 맞는 개인적으로 발행되는 카드를 가지고 있고
PIN 번호가 발행되었고 뱅킹 시스템에 등록되어 있습니다.
ATM 시스템에서 현금 인출 유스 케이스의 사후 조건:
유스 케이스 종료시 모든 계좌 및 트랜잭션 로그가 맞춰지고
뱅킹 시스템과의 의사소통이 다시 초기화되며 고객에게 카드를 돌려줍니다.
확장 지점은 확장 가능한 지점까지 유스 케이스를 엽니다. 이름이 지정되며 유스 케이스 이벤트 플로우에서 하나 이상의
위치에 대한 참조 목록이 있습니다. 확장 지점은 유스 케이스 내의 두 작동 단계
사이의 한 위치를 말하는 것일 수 있습니다. 또한 불연속 위치 세트를 말하는 것일 수도 있습니다.
이름이 지정된 확장 지점을 사용하면 기본 유스 케이스의 내부 세부사항과
확장하는 유스 케이스 작동 스펙을 분리하는 데 도움이 됩니다. 확장 지점의
이름이 동일하게 유지되는 한 확장하는 유스 케이스에 영향을 미치지 않으므로
기본 유스 케이스를 수정하거나 재배열할 수 있습니다.
동시에 작동을 확장할 수 있는 위치 세부사항으로 기본 유스 케이스의
이벤트 플로우를 설명하는 텍스트를 채우지 않습니다. 가이드라인: 확장 관계도 참조하십시오.
예:
전화 시스템에서 전화 걸기 유스 케이스는
추상적
유스 케이스인 통화자 신원 표시에서 확장될 수 있습니다. 이것은 수신 상대방으로부터
요청되었거나 요청되지 않았을 수 있는 선택적
서비스(종종 "통화자 ID"라고 지칭)입니다. 전화 걸기 유스 케이스의 확장 지점 설명은 다음과 같습니다.
이름: 신원 표시
위치: 섹션 1.9 수신 상대방 전화벨 울리기 이후
유스 케이스가 액터 및 유스 케이스에 포함된 다른 유스 케이스와 관련된 방식을
유스 케이스 다이어그램(드물게는 둘 이상의 다이어그램)으로 설명하고자 할 수 있습니다. 이것은 유스 케이스에 여러 액터가 개입되어 있거나 다수의 다른 유스 케이스와
관련되어 있는 경우 유용합니다. 이러한 종류의 다이어그램은
하나의 유스 케이스 Perspective에서만 유스 케이스 모델을 보여주고 전체 유스 케이스 모델에 관한
일반적 사실을 설명할 목적이 아니기 때문에 "로컬" 문자로 되어 있습니다. 가이드라인: 유스 케이스 다이어그램도 참조하십시오.
|