이 정의에는 몇 가지 키 단어가 있습니다.
-
유스 케이스 인스턴스. 정의에 관련된 시퀀스는 실제로 시스템을 통한 특정 이벤트 플로우이거나 인스턴스입니다. 많은 이벤트 플로우가 가능하고, 매우 비슷한 이벤트 플로우도 많이 있을
수 있습니다. 유스 케이스 모델을 이해하기 쉽게 작성하려면, 유사 이벤트 플로우를 하나의 유스 케이스로 그룹화하십시오. 유스 케이스를 식별하고 설명하는 작업은 실제로 관련 이벤트 플로우 그룹을 식별하고
설명하는 작업을 말합니다.
-
시스템 수행. 시스템이 유스 케이스를 제공함을 의미합니다. 액터는 시스템의 유스 케이스 인스턴스와 통신합니다.
-
관찰 가능한 결과 값. 수행 완료된 유스 케이스에 값을 입력할 수 있습니다. 유스 케이스는 액터가 식별 가능한 값을 갖는 타스크를 수행할 수 있는지 확인해야 합니다. 이 작업은 유스 케이스의
올바른 레벨 또는 세분성을 판별하는 데 매우 중요합니다. 올바른 레벨은 너무 작지 않은 유스 케이스를 설정하는 것입니다. 경우에 따라서는 시스템의 액터인 개인을 포함하는 조직에서 유스 케이스를 계획 단위로
사용할 수 있습니다.
-
조치. 조치는 계산 또는 대수 프로시저입니다. 액터가 시스템에 신호를 제공하거나 시스템이 시간 이벤트를 얻을 때 호출됩니다. 조치는 호출 액터 또는 기타 액터에 대한 신호 전송을 수반할 수
있습니다. 조치는 원자 동작이며, 이는 전체를 수행하거나 하나도 수행하지 않음을 의미합니다.
-
특정 액터. 특히 액터는 너무 큰 유스 케이스를 사용하지 않도록 도와주므로 액터는 올바른 유스 케이스를 찾는 핵심이 됩니다. 한 예제로 비주얼 모델링 도구를 검토할 수 있습니다. 이
응용프로그램에 대해 실제로 두 액터 즉, 개발자(지원 도구를 사용하여 시스템을 개발하는 사람) 및 시스템 관리자(도구를 관리하는 사람)가 있습니다. 이 두 액터는 시스템에 대한 각자의 요구가 있으므로 각자
유스 케이스를 설정해야 합니다.
시스템 기능성은 다양한 유스 케이스로 정의되며, 각 유스 케이스는 특정 이벤트 플로우를 나타냅니다. 유스 케이스의 설명은 유스 케이스가 수행될 때 시스템에서 일어나는 일에 대해 정의합니다.
예를 들어 현금 자동 인출기(ATM)에서 고객은 계정에서 돈을 인출하거나 돈을 계정으로 이체하거나 계정 잔액을 확인할 수 있습니다. 이 기능은 유스 케이스로 표시할 수 있는 플로우에 해당합니다.
각 유스 케이스에는 그 나름대로 수행할 타스크가 있습니다. 수집된 유스 케이스는 가능한 시스템 사용 방법을 모두 구성합니다. 유스 케이스 타스크의 개념은 이름만 봐도 알 수 있습니다.
다음은 유스 케이스를 식별할 때 도움이 되는 질문 세트입니다.
-
식별한 각 액터에 대해 시스템이 관여하는 타스크는 무엇입니까?
-
액터는 시스템에서 발생한 특정 사항에 대해 알고 있어야 합니까?
-
액터는 갑작스런 외부 변경에 대한 정보를 시스템에 제공해야 합니까?
-
시스템은 비즈니스에 올바른 동작을 제공합니까?
-
식별한 유스 케이스에 따라 모든 기능을 수행할 수 있습니까?
-
시스템을 지원하고 유지보수하는 유스 케이스는 무엇입니까?
-
시스템에서 수정 또는 작성해야 하는 정보는 무엇입니까?
일반적으로 시스템의 기본 기능이 무엇인지를 표시하지 않아 종종 간과되는 유스 케이스는 다음 종류에 해당할 수 있습니다.
-
시스템 시작 및 중지.
-
시스템 유지보수. 예: 사용자 새로 추가 및 사용자 프로파일 설정.
-
시스템에 저장된 데이터 유지보수. 예를 들어, 시스템은 레거시 시스템과 병행하여 작동하도록 구성되어 있으므로 두 시스템 간 데이터를 동기화해야 합니다.
-
시스템의 동작을 수정하는 데 필요한 기능성. 새 보고서 작성에 필요한 기능성의 예제입니다.
비즈니스 유스 케이스 모델 및 비즈니스 분석 모델을 개발한 경우 이 아티팩트는 유스 케이스를 식별하기에 적합한 시작점입니다.
정제(Elaboration)의 초기 반복에서 (구조적으로 중시되는) 소수의 유스 케이스에 대해서만 간략한 설명 이상으로 자세히 설명됩니다. 언제나 깊이 파고들기 전에 우선 단계별 형식으로 유스 케이스의 아웃라인부터
개발해야 합니다. 이 단계별 아웃라인은 유스 케이스 이벤트 플로우의 구조를 정의하는 일차적인 시도입니다(아래 이벤트 플로우 -
구조 참조). 언제나 유스 케이스의 기본 플로우부터 시작하십시오. 기본 플로우의 아웃라인에 동의하는 경우, 기본 플로우에 관하여 대체 플로우를 추가할 수 있습니다.
정제의 마지막 단계에 이르면 자세히 설명하려고 계획한 모든 유스 케이스를 완료해야 합니다.
모델의 유스 케이스가 너무 단순하여 이벤트 플로우에 대한 자세한 설명이 필요하지 않은 경우 해당 유스 케이스는 단계별 아웃라인만으로 충분합니다. 이 결정을 위한 기준으로는, 유스 케이스가 의미하는 바에 대해 독자들
간에 의견 차이를 보이지 않고, 디자이너 및 테스터가 단계별 형식에 제공된 세부사항 레벨에 대해 만족해야 합니다. 예제는 시스템의 일부 데이터의 단순 입력 또는 검색을 설명하는 유스 케이스입니다.
사용자 시스템 상호작용 설정 또는 대화 상자의 유스 케이스가 하나인지 여러 개인지 결정하기가 어려운 경우도 있습니다. 재활용품 수집기의 사용을 생각해 보십시오. 고객은 폐품(예: 깡통, 병 및 나무 상자)을
재활용품 수집기에 넣습니다. 모든 폐품을 삽입한 후 단추를 누르면 영수증이 인쇄됩니다. 그러면 이 영수증을 돈으로 교환할 수 있습니다.
폐품을 삽입하는 유스 케이스가 하나 있고 영수증을 요구하는 유스 케이스가 하나 있습니까? 아니면, 모두 하나의 유스 케이스입니까? 두 가지 조치가 있는데 둘 중 하나라도 없으면 고객에게 별로 가치가 없습니다.
오히려 삽입에서 영수증을 받기까지를 전체 대화 상자로 만드는 것이 고객에게 가치가 있고 이치에도 맞습니다. 첫 번째 폐품을 삽입해서 단추를 누르고 영수증을 받기까지 전체 대화 상자가 사용되는 전체 경우, 즉 유스
케이스입니다.
또한 두 조치에 대해 동시 검토, 일괄 수정, 일괄 테스트, 해당 매뉴얼 작성을 수행하고 대개 하나의 단위로 관리할 수 있으려면 두 조치를 함께 보관해야 할 필요가 있습니다. 이 필요성은 대규모 시스템에서 아주
명확합니다.
유스 케이스는 액터가 시스템과 상호작용하여 유스 케이스를 실행할 때 시스템에서 일어나는 현상을 설명합니다. 유스 케이스는 시스템이 협업 오브젝트에 관하여 해당 타스크를 내부적으로 수행하는 방식을 정의하지 않습니다.
유스 케이스 실현 형태를 보여주기 위한 것입니다.
예제:
전화 예제에서, 유스 케이스는 수화기를 들면 시스템이 신호를 발행하고, 곧이어 시스템이 숫자를 받고, 수신측을 찾고, 전화를 걸고, 전화를 연결하고, 말을 전하는 일을 다른 일보다 우선적으로 표시합니다.
실행 시스템에서 유스 케이스의 인스턴스는 구현 모델의 특정 오브젝트에 해당하지 않습니다(예: 코드 클래스의 인스턴스). 그보다는 오히려 액터에 의해 호출되어 오브젝트 세트 사이에 이벤트 시퀀스로 실행되는 특정
이벤트 플로우에 해당합니다. 다시 말해서, 유스 케이스 인스턴스는 구현된 오브젝트의 통신 인스턴스에 해당합니다. 이를 일컬어 유스 케이스의 실현(realization)이라고 합니다. 대개의 경우, 동일 오브젝트는
둘 이상의 유스 케이스 실현에 관여합니다. 예를 들어, 은행 업무 시스템의 유스 케이스 입금과 인출은 실현 시 특정 계정 오브젝트를 사용할 수 있습니다. 이는 두 유스 케이스가 통신할 때 실현 형태로 동일한
오브젝트를 사용한다는 것만을 의미하지는 않습니다.
여러 서브플로우로 구성되어 있어 한꺼번에 전체 이벤트 플로우를 산출할 수 있는 이벤트 플로우를 볼 수 있습니다. 기타 유스 케이스의 이벤트 플로우에서 서브플로우의 설명을 다시 사용할 수 있습니다. 한 유스 케이스의
이벤트 플로우 설명에 포함된 서브플로우는 기타 유스 케이스 설명에 들어 있는 서브플로우와 공통될 수 있습니다. 동일한 오브젝트를 포함하는 디자인에서 모든 관련 유스 케이스에 대하여 이 공통 동작을 수행하십시오.
즉, 실행 중인 유스 케이스에 관계없이 하나의 오브젝트 세트만 이 동작을 수행해야 합니다.
예제:
현금 자동 인출기(ATM) 시스템에서 초기 서브플로우는 유스 케이스 현금 인출 및 잔액 조회의 이벤트 플로우에서 동일합니다. 두 유스 케이스의 이벤트 플로우는 카드 ID와 고객의 개인 액세스 코드를 확인하는 것으로
시작합니다.
유스 케이스 인스턴스는 무제한에 가까운 수많은 경로를 수행할 수 있습니다. 이 경로는 이벤트 플로우의 설명에서 유스 케이스 인스턴스에 개방되어 있는 선택사항을 표시합니다. 선택된 경로는 이벤트에 의존합니다. 이벤트
유형은 다음을 포함합니다.
-
액터의 입력 정보. 예를 들어, 액터는 여러 옵션 중에서 다음에 수행할 작업을 결정할 수 있습니다.
예제:
'재활용품 수집기 시스템의 항목 재활용' 유스 케이스에서 고객은 두 가지 옵션 즉, 다른 폐품 제출 또는 반환 항목의 영수증 받기를 사용할 수 있습니다.
-
내부 오브젝트 또는 속성의 값이나 유형 선택. 예를 들어, 이벤트 플로우는 값이 특정 값 이상이거나 이하인 경우에 다를 수 있습니다.
예제:
현금 자동 인출기(ATM) 시스템의 현금 인출 유스 케이스에서 고객이 이 계정에 들어 있는 돈보다 많은 돈을 청구하는 경우에는 이벤트 플로우가 다릅니다. 유스 케이스 인스턴스는 다른 경로를 따릅니다.
여러 유스 케이스의 인스턴스와 동일 유스 케이스의 여러 인스턴스는 시스템이 허용하는 경우 동시에 작동합니다. 유스 케이스 모델링에서 유스 케이스의 인스턴스가 충돌 없이 동시에 활성화될 수 있다고 가정할 수
있습니다. 유스 케이스 모델링이 해당 작업 방식을 설명하지 않으므로 디자인 모델은 이 문제점을 해결할 수 있을 것으로 예상됩니다. 이에 대한 검증 방법으로, 한 번에 하나의 유스 케이스 인스턴스만 활성화되고 이
인스턴스의 실행은 원자 조치라고 가정해 보십시오. 유스 케이스 모델링에서 "해석 시스템"은 무한히 빠르다고 여겨지므로 유스 케이스 인스턴스의 직렬화는 문제가 되지 않습니다.
각 유스 케이스는 액터와의 상호 작용으로 얻어진 결과를 표시하는 이름을 포함합니다. 이름은 이해할 수 있는 몇몇 단어일 수 있습니다. 두 개의 유스 케이스가 같은 이름을 가질 수 없습니다.
예제:
다음은 재활용품 수집기의 항목 재활용 유스 케이스의 이름 변동 예제입니다. 예를 들어 다음과 같습니다.
-
폐품 받기(Receive Deposit Items)
-
폐품 받기(Receiving Deposit Items)
-
폐품 반환(Return Deposit Items)
-
폐품(Deposit Items)
유스 케이스의 간략한 설명은 유스 케이스의 목적을 반영합니다. 설명을 작성할 때 유스 케이스에 관련된 액터와 용어집을 참조하고 필요한 경우 새 개념을 정의하십시오.
예제:
다음은 재활용품 수집기 시스템에서 항목 재활용 및 병류 새로 추가 유스 케이스에 대한 간략한 설명 샘플입니다.
항목 재활용: 사용자는 이 시스템을 사용하여 반환 항목(병, 깡통 및 나무 상자)을 모두 자동으로 세고 영수증을 받습니다. 영수증은 현금 등록기(시스템)에서 현금화할 수 있습니다.
병류 새로 추가: 새 병류는 '학습 모드'에서 시작해서 항목을 반환할 때와 같이 다섯 개의 샘플을 삽입하여 시스템에 추가할 수 있습니다. 이 방법으로 시스템은 병을 세고 식별할 수 있게 됩니다.
관리자는 새 병류에 대한 반환 값을 지정합니다.
유스 케이스의 이벤트 플로우는 유스 케이스 모델링 작업에서 파생된 가장 중요한 정보를 포함합니다. 이 정보는 유스 케이스의 이벤트 플로우를 외부인도 쉽게 이해할 수 있을 정도로 명확하게 설명합니다.
이벤트 플로우는 시스템이 수행하는 작업을 나타내고, 필수 동작을 수행하기 위한 시스템 디자인 방법은 나타내지 않습니다.
이벤트 플로우 컨텐츠에 대한 가이드라인은 다음과 같습니다.
-
유스 케이스 시작 및 종료 방법을 설명하십시오.
-
액터와 유스 케이스 간에 교환되는 데이터를 설명하십시오.
-
시스템 동작을 이해해야 할 필요가 없는 경우, 사용자 인터페이스의 정밀도는 설명하지 마십시오. 예를 들어 응용프로그램이 웹 기반이라는 사실이 미리 알려져 있을 때 한정된 웹 특정 용어 세트를 사용하는 것이
바람직한 경우도 있습니다. 그렇지 않으면 유스 케이스 텍스트를 너무 추상적으로 인식하는 위험성에 빠집니다. 용어에 포함시킬 단어는 "탐색", "찾아보기", "하이퍼링크", "페이지", "제출", "브라우저"
등이 있습니다. 하지만 용어 간 경계에 대한 가정을 작성하는 방법으로 "프레임" 또는 "웹 페이지"에 참조를 포함시키는 것은 바람직하지 않습니다. 이는 중요한 디자인 결정입니다.
-
기능성만이 아니라 이벤트 플로우도 설명하십시오. 이를 실행하려면 모든 조치를 "액터가...할 때"로 시작하십시오.
-
다른 유스 케이스 또는 시스템 외부에서 일어나는 이벤트는 제외하고 유스 케이스에 속하는 이벤트만 설명하십시오.
-
모호한 용어는 사용하지 마십시오.
-
응답해야 하는 모든 "질문"에 대해 이벤트 플로우를 자세히 설명하십시오. 테스트 디자이너는 이 텍스트를 사용하여 테스트 케이스를 식별해야 합니다.
다른 유스 케이스에서 특정 용어를 사용한 경우, 이 유스 케이스에서 똑같은 용어를 사용하고 용어가 의도하는 의미도 같게 하십시오. 공통 용어를 관리하려면 용어집에 넣으십시오.
이벤트 플로우에서 두 개의 주 파트는 기본 이벤트 플로우 및 대체 이벤트 플로우입니다. 기본 이벤트 플로우는 유스 케이스가 수행될 때 "정규로" 일어나는 이벤트를 포함합니다.
대체 이벤트 플로우는 정상 동작에 관련된 선택적 또는 예외적 특성의 동작을 포함하고 정상 동작의 변동도 포함합니다. 대체 이벤트 플로우는 기본 이벤트 플로우의 "우회로"로 고려할 수 있으며, 일부는 기본 이벤트
플로우로 돌아가고 일부는 유스 케이스의 실행을 종료합니다.
이벤트 플로우의 일반적인 구조. 직선 화살표는 기본 이벤트 플로우를 나타내고 곡선은 표준에 관련된 대체 경로를 나타냅니다. 일부 대체 경로는 기본 이벤트 플로우로 돌아가지만 다른 대체 경로는 유스 케이스를
종료합니다.
기본 이벤트 플로우와 대체 이벤트 플로우는 둘 다 단계 또는 서브플로우로 한층 더 구조화됩니다. 이 작업 수행 시 기본 목적은 텍스트를 읽기 쉽게 하는 것입니다(아래의 이벤트 플로우 - 스타일 섹션 참조). 경험 법칙상 서브플로우는 분명한 목적을 갖는 유스 케이스 내의 동작 세그먼트여야 하고, 설명된
조치를 모두 수행하거나 하나도 수행하지 않는다는 의미에서 "원자" 조치입니다. 여러 서브플로우 레벨이 필요할 수 있지만 많은 레벨 사용 시 텍스트가 더 복잡해지고 이해하기가 더 어려울 수 있으므로 가능한 한 피해야
합니다. 활동 다이어그램으로 이벤트 플로우의 구조를 설명할 수 있습니다. 중간 산출물 가이드라인: 유스 케이스의 활동 다이어그램을 참조하십시오.
이와 같이 작성된 후 연속 서브섹션으로 구조화된 텍스트의 유형은 특성상 서브플로우 간에 시퀀스가 있음을 리더에게 암시합니다. 오해를 피하기 위해 항상 서브플로우 순서의 수정 여부를 지시해야 합니다. 이 유형의
고려사항은 종종 다음과 관련이 있습니다.
-
비즈니스 규칙. 예를 들어, 시스템이 특정 데이터를 사용 가능하게 하려면 먼저 사용자가 권한을 부여받아야 합니다.
-
사용자 인터페이스 디자인. 예를 들어, 시스템은 사용자에 따라 직관적으로 인식될 수도 인식되지 않을 수도 있는 동작의 특정 시퀀스를 실행하지 않아야 합니다.
구조에서 대체 이벤트 플로우의 적합한 위치를 명백히 설명하기 위해 기본 이벤트 플로우의 각 "우회로"에 대해 다음을 설명해야 합니다.
-
기본 이벤트 플로우에서 대체 동작을 삽입할 수 있는 위치.
-
대체 동작을 시작하기 위해 수행해야 할 조건.
-
기본 이벤트 플로우의 재개 방법 및 위치 또는 유스 케이스의 종료 방법.
예제:
다음은 재활용품 수집기 시스템의 항목 반환 유스 케이스의 대체 서브 플로우입니다.
2.1. 병 걸림
섹션 1.5, 폐품 삽입에서 병이 게이트에 계속 걸려 있으면 게이트 주변 센서와 측정 게이트가 이 문제점을 발견합니다. 컨베이어 벨트가 중지되고 수집기가 알람을 발행하여 운영자를 호출합니다. 수집기는 운영자가
문제점이 수정되었음을 표시할 때까지 대기합니다. 이때 수집기는 기본 플로우의 섹션 1.9에 머무릅니다.
위의 예제에서 대체 이벤트 플로우는 기본 이벤트 플로우에서 특정 위치에 삽입됩니다. 둘 이상의 위치에 삽입될 수 있는 대체 이벤트 플로우도 있으며, 일부는 기본 이벤트 플로우에서 어떤 위치에도 삽입될 수 있습니다.
예제:
다음은 재활용품 수집기 시스템의 항목 반환 유스 케이스의 대체 서브 플로우입니다.
2.2. 전면판이 제거됨
누군가 재활용품 수집기의 전면판을 제거하면, 깡통 압축이 비활성화됩니다. 전면판이 제거된 상태에서 깡통 압축을 시작하는 것은 가능하지 않습니다. 또한 제거 시 운영자에 대한 알람이 활성화됩니다. 전면판이 다시
닫히면 수집기는 중지된 기본 이벤트 플로우에서 조작을 재개합니다.
대체 이벤트 플로우는 매우 단순한 경우 "if-then-else" 구성을 사용하여 기본 이벤트 플로우 섹션에서 설명을 시도할 수 있습니다. 그러나 이 방법은 피해야 합니다. 너무 많이 대체하면 정상 동작을 확인하기
어려울 수 있습니다. 또한 기본 이벤트 플로우에 대체 경로를 포함하면 텍스트가 "의사 코드와 더 유사"해져서 읽기가 더 여려워집니다.
일반적으로 이벤트 플로우의 파트를 추출하여 이 파트를 개별적으로 설명하면 기본 이벤트 플로우가 읽기 쉬워지고 유스 케이스 및 유스 케이스 모델의 구조가 개선될 수 있습니다. 추출된 파트는 다음과 같이 모델링할 수
있습니다.
-
기본 이벤트 플로우에 대한 단순 변형, 옵션 또는 예외인 경우 기본 유스 케이스 내의 대체 이벤트 플로우.
-
기타 유스 케이스에서 재사용할 수 있도록 캡슐화해야 할 대상인 경우 기본 유스 케이스의 명시 포함사항(중간 산출물
가이드라인: 포함 관계 참조).
-
기본 유스 케이스의 기본 이벤트 플로우가 완료된 경우 즉, 시작 및 끝이 정의되어 있는 경우 기본 유스 케이스의 내재적 포함사항(중간 산출물
가이드라인: 확장 관계 참조). 확장 플로우의 특성은 기본 유스 케이스 설명의 복잡도를 줄이기 위해 해당 설명에 드러내지 않으려고 하는 본질입니다.
-
위의 대체가 하나도 적용되지 않는 경우 가능한 다른 옵션으로서 기본 이벤트 플로우의 서브플로우. 예를 들어 종업원 정보 유지보수 유스 케이스에서는 종업원 정보 추가, 삭제 및 수정을 위한 독립 서브 플로우가
있을 수 있습니다.
많은 스타일의 유스 케이스를 설명할 수 있습니다. 한 예로, 스타일의 정규도에 근본적인 차이가 있는 세 가지의 서로 다른 스타일로 설명된 순서 지정 관리(Administer Order) 유스 케이스의 기본 이벤트
플로우를 보여줍니다. 아래 예제 1에 표시된 첫 번째 스타일은 이해하기 쉽고 사건 발생 순서가 명백하므로 바람직합니다. 텍스트는 번호 지정 및 이름 지정된
서브섹션으로 나뉩니다. 숫자는 서브섹션을 쉽게 참조하기 위한 것입니다. 서브섹션 이름을 통해 독자는 텍스트에서 헤더만 읽고도 이벤트 플로우의 개요를 빨리 이해할 수 있습니다.
아래 예제 2의 이벤트 플로우 설명에는 사건이 일어나는 순서가 설명되지 않았습니다. 이 스타일로 작성하면 누구든지 시스템에 관련하는 중요한 사항을 놓칠 수
있습니다.
아래의 예제 3은 또 다른 스타일을 보여주며, 이벤트 시퀀스를 명확히 표현하기가 어려운 경우 도움이 될 수 있습니다. 이 pseudo 코드 스타일은 더 정확하지만
비전문가는 이해하기 어려우며 특히 이벤트 플로우를 빨리 이해해야 할 경우 더욱 그렇습니다.
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'
|
유스 케이스 설명: 작성자는 pseudo 코드를 사용하는 정규 스타일을 선택했습니다. 이 스타일은 프로세스 단계를 빨리 이해하기는 어렵지만 이벤트 플로우를 정확히 캡처하기 어려운 경우에는 도움이 될 수 있습니다.
대체 플로우를 포함한 유스 케이스 관리 순서 이벤트 플로우의 전체 설명은 다음과 같이 보일 수 있습니다.
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 표시에 의해 확장될 수 있습니다. 이 유스 케이스는
수신측에 의해 요청될 수도 요청되지 않을 수도 있는 선택적 서비스이며 흔히 "발신자 ID"라고도 합니다. 전화 걸기 유스 케이스에서 확장점의 설명은 다음과 같을 수 있습니다.
이름: ID 표시
위치: 섹션 1.9 수신측 전화기 울림 후.
유스 케이스가 해당 유스 케이스가 소유한 하나의 유스 케이스 다이어그램(예외적인 경우, 둘 이상의 다이어그램)에서 액터 및 기타 유스 케이스와 어떻게 관련되는지 설명하고자 할 수 있습니다. 이 선택사항은 유스
케이스가 많은 액터와 관련되어 있거나 많은 기타 유스 케이스와 관계가 있는 경우에 유용합니다. 이 유형의 다이어그램은, 하나의 유스 케이스의 관점에서만 유스 케이스 모델을 보여주고 전체 유스 케이스 모델에 대한
일반적인 사실을 설명하지 않으므로 "로컬" 특성을 갖습니다. 또한 중간 산출물 가이드라인:
유스 케이스 다이어그램을 참조하십시오.
|