工学-2.1使用事例モデリング
COMETライフサイクルモデルでは、デマンドモデルを「UseCaseモデル」と呼びます.
ソフトウェアの機能要件は、Use CaseとActorの観点から決定されます. Use CaseとActorは、ソフトウェアがどのような機能を提供すべきかを示します. は、UMLのUseCaseおよびActorを使用して、お客様のニーズを表します.
Usecase Modelingとは、
これは システム要件を抽出する方法である. システムと相互作用するユーザ/外部システムを識別する. システムがユーザ/外部システムとどのように相互作用するかを説明するプロセス. システム開発の目的を達成するために、システム内部コンポーネントが正しく認識されているかどうかを決定することができる. システムの開発を要求されたお客様とUser Case Diagramで交渉できます.
UseCase:動作とシステム間の相互作用シーケンス
UseCase:開発するシステムと外部ユーザーの間でどのように対話するかを示すプロセスです.
つまり,Actorとシステム間のインタラクションがUse Caseである.
UseCaseは、Actorに必要なシステムの主な機能です.★★★
ユーザ事例は,Actorのシステム使用目的,ターゲットと見なすことができる.
ユーザー・ケースは、Actorに価値を提供する必要があります.
Use Caseを使用して実際のリクエストモデリングを実行するのは「Use Caseモデリング」です.
includeとextendの「UseCase関係」があります.(後文)
User Caseを設計する際、最も重要なのは「内部実装を非表示にし、Actorとシステム間の相互要求と可視結果のみを記述する」ことです.はい.★★★
Actor : External entities of System
Acer:外部からシステムを起動したり、システムと情報を交換したりするオブジェクト!
つまり、システムとインタラクティブな外部ユーザーや外部システム!
マクロタイプ 人、ユーザー 外部I/O機器 外部システムex)サーバ タイマ~>Real-timeシステムは、これらのTimerを有する.
マクロベースはシステムを通じて行動する. システムを使用して、物理的にコミュニケーションを行います. Actorは、UseCaseを実行する.★
~>矩形は「開発するシステム」を表し,その楕円はUseCase,すなわちInteractionである.システム外部のヒューマンモデルはActorです.
~>大学システムでは,StudentというActorがシステムとTakeCourseのUseCaseを持つ.
~>外部I/Oシステム(「到着センサ」と呼ばれる)は、エレベータシステムと通信するUseCase「エレベータを停止する」!
主なActor:システムに入力することで、UseCaseのActorを起動する
Secondary Actor:ユーザー・ケースは起動しませんが、そのユーザー・ケースに参加するActor Secondary Actorは、他のUseCaseにおいてPrimary Actorであってもよい.
マクロベースはシステムユーザーを表すことができます. 実際のユーザは、マクロベースのInstanceと見なすことができる. 実際のユーザは、複数のActorの役割を果たすことができる.
~>自主走行車両では、特定のタイマーが期限切れになると、現在の走行速度を算出するシステムがある.このシステムでは、「走行速度計算」Use Caseをトリガする主なActorがTimerである.一方,速度に関与するパイロットActorはSecondary Actorである.
~>別の例.目覚まし時計と公告の本体がロボットであれば、ロボットはメインアクターになります.
関連付け:ActorとUseCaseの間のすべてのインタラクションを表します.
(ここから)
UseCaseは、「開発者が開発するシステム」内で外部のActorと通信するサービス/機能です.
~>Actorによって起動される一連の詳細イベントと見なすこともできる.
=>これらの抽象化はUse Caseである. Use Case is..
これは、 マクロベースとシステムとの間で実行される機能です. Actorによって実行される機能と見なすことができる. Actorにも価値が割り当てられます. Actorの入力から開始します. 種以上のVariant Pathがあります. 異なる場合、またはエラー処理について、
~>1つのActivtorには3つのUseCaseの例がある
~>ATMシステム例(draw.io使用)
1)ATM(システム)をRectangleとして描画する.(ブラックボックスの状況)
2)Actorを設定します.例えば、ユーザ、サーバ、メンテナ等
3)各マクロベースにどのようなサービスを提供するか,およびマクロベースの立場でこのシステムを使用する目的は何であり,使用状況を決定する.
※Monitor、Keyboardなどのハードウェア要素は、Actorを使用しない傾向があります.すなわち、ソフトウェアコードを必要としないハードウェア要素は、Actorと見なされない.
各UseCaseを以下の形式でドキュメント化します. Name:UseCaseの名前 概要:Use Case の簡単な紹介依存性:他のUseCaseへの依存性(include&extend関係を明記してください)★ エイサー:関連エイサー 前提条件: Description:基本サービスパスの説明
ステップ によって記述される.★ Alternatives:特定の例外代替スキーム経路 を記述する. PostConditions:UseCase終了時の場合は、 と明記してください
Alternatives:
•6番でPIN番号が一致しない場合はエラーメッセージが表示され、再度ウィンドウを開いてPIN番号を入力します.マッチングに3回以上失敗した場合は、カードを削除して「Welcome」メッセージを再送信します.
•10日に十分なお金がない場合は、エラーメッセージを送信し、引き出し量を再入力します.
•10回を超えるとエラーメッセージが出て、出金量を再入力します.
Include Relationship:複数のUse Caseから共通のパターン、要素を識別し、その共通属性を抽出して「Abstract Use Case」とする.
~>Withdraw Funds、Query Account、Transfer Funds Useともに「Validate PIN」プロセスが必要です.
~~>Abstract Use Caseにする! include関係は以下のように表される. 破線矢印を使用します. 線の横に「<含む>」という表記があります. 矢印は、「抽出された共通属性」を指します.つまり、それは含まれるUse Caseを指す. この場合、「含む」UseCaseを「具体的」UseCase、「含む」UseCaseを「抽象的」UseCaseと呼ぶ.
=>上記の例は次のようにDiagramとして表示されます.
Extend Relationship:まったく逆のレベルのUser Case Relationshipを指します.
ConcreteからAbstractまでのincludeとは異なり、AbstractからConcreteまでの点線矢印です. 線の横にと書いてあります.
extendはincludeとは異なります.
includeは、Concreteが使用しなければならないUse Caseです.
extendは、Concreteが選択的に使用するUseCaseです.
違いがわかりますか.
ソフトウェアの機能要件は、Use CaseとActorの観点から決定されます.
Usecase Modelingとは、
これは
Use Case Modeling
Use Case
UseCase:動作とシステム間の相互作用シーケンス
UseCase:開発するシステムと外部ユーザーの間でどのように対話するかを示すプロセスです.
つまり,Actorとシステム間のインタラクションがUse Caseである.
UseCaseは、Actorに必要なシステムの主な機能です.★★★
ユーザ事例は,Actorのシステム使用目的,ターゲットと見なすことができる.
ユーザー・ケースは、Actorに価値を提供する必要があります.
Use Caseを使用して実際のリクエストモデリングを実行するのは「Use Caseモデリング」です.
includeとextendの「UseCase関係」があります.(後文)
Actor
Actor : External entities of System
Acer:外部からシステムを起動したり、システムと情報を交換したりするオブジェクト!
つまり、システムとインタラクティブな外部ユーザーや外部システム!
マクロタイプ
マクロベースはシステムを通じて行動する.
~>矩形は「開発するシステム」を表し,その楕円はUseCase,すなわちInteractionである.システム外部のヒューマンモデルはActorです.
~>大学システムでは,StudentというActorがシステムとTakeCourseのUseCaseを持つ.
~>外部I/Oシステム(「到着センサ」と呼ばれる)は、エレベータシステムと通信するUseCase「エレベータを停止する」!
主なActor:システムに入力することで、UseCaseのActorを起動する
Secondary Actor:ユーザー・ケースは起動しませんが、そのユーザー・ケースに参加するActor
マクロベースはシステムユーザーを表すことができます.
~>自主走行車両では、特定のタイマーが期限切れになると、現在の走行速度を算出するシステムがある.このシステムでは、「走行速度計算」Use Caseをトリガする主なActorがTimerである.一方,速度に関与するパイロットActorはSecondary Actorである.
~>別の例.目覚まし時計と公告の本体がロボットであれば、ロボットはメインアクターになります.
Association
関連付け:ActorとUseCaseの間のすべてのインタラクションを表します.
UseCase詳細
Identifying
UseCaseは、「開発者が開発するシステム」内で外部のActorと通信するサービス/機能です.
~>Actorによって起動される一連の詳細イベントと見なすこともできる.
=>これらの抽象化はUse Caseである.
これは、
~>1つのActivtorには3つのUseCaseの例がある
~>ATMシステム例(draw.io使用)
1)ATM(システム)をRectangleとして描画する.(ブラックボックスの状況)
2)Actorを設定します.例えば、ユーザ、サーバ、メンテナ等
3)各マクロベースにどのようなサービスを提供するか,およびマクロベースの立場でこのシステムを使用する目的は何であり,使用状況を決定する.
※Monitor、Keyboardなどのハードウェア要素は、Actorを使用しない傾向があります.すなわち、ソフトウェアコードを必要としないハードウェア要素は、Actorと見なされない.
Documenting
各UseCaseを以下の形式でドキュメント化します.
ステップ
Ex) Use Case Name: 현금 인출
Summary: 유효한 은행 계좌에서 소비자가 특정 양의 자금을 인출한다.
Actor: ATM 고객
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. 고객이 ATM기 카드 리더기에 카드를 삽입한다.
2. 시스템이 카드를 인식하면, 카드를 읽는다.
3. 시스템이 고객에게 비밀번호 입력을 위한 창을 띄운다.
4. 고객이 비밀번호 PIN Number를 입력한다.
5. 시스템이 카드의 만료 기한과 도난 여부 등을 확인한다.
6. 카드가 유효하면, 서버에 저장된 카드의 비밀번호와 입력된 비밀번호가 일치하는지 확인한다.
7. 비밀번호가 일치하면, 해당 카드가 어떤 계좌에 접근 가능한지 체크한다.
8. 시스템이 화면에 선택 창을 띄운다. : 인출, 입금, 송금
9. 고객이 인출을 누르고, 인출할 양을 입력한다.
10. 시스템이 계좌에 충분한 돈이 있는지 확인하고, 또한 한도 초과는 아닌지 체크한다.
11. 확인이 완료되면, 인출을 허가한다.
12. 현금을 드르르륵 내보낸다.
13. 시스템이 영수증을 출력한다.
14. 시스템이 카드를 제거한다.
15. 시스템이 다시 'Welcome' 메세지를 띄운다.
~>以上のUseCaseドキュメントにAlternativesを作成する場合は、次のことができます.Alternatives:
•6番でPIN番号が一致しない場合はエラーメッセージが表示され、再度ウィンドウを開いてPIN番号を入力します.マッチングに3回以上失敗した場合は、カードを削除して「Welcome」メッセージを再送信します.
•10日に十分なお金がない場合は、エラーメッセージを送信し、引き出し量を再入力します.
•10回を超えるとエラーメッセージが出て、出金量を再入力します.
Use Case Relationship
~>Withdraw Funds、Query Account、Transfer Funds Useともに「Validate PIN」プロセスが必要です.
~~>Abstract Use Caseにする!
Ex) Use Case Name: PIN 유효 확인
Summary: 시스템이 PIN 넘버의 유효성을 확인한다.
Actor: ATM 고객
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. 고객이 ATM기 카드 리더기에 카드를 삽입한다.
2. 시스템이 카드를 인식하면, 카드를 읽는다.
3. 시스템이 고객에게 비밀번호 입력을 위한 창을 띄운다.
4. 고객이 비밀번호 PIN Number를 입력한다.
5. 시스템이 카드의 만료 기한과 도난 여부 등을 확인한다.
6. 카드가 유효하면, 서버에 저장된 카드의 비밀번호와 입력된 비밀번호가 일치하는지 확인한다.
7. 비밀번호가 일치하면, 해당 카드가 어떤 계좌에 접근 가능한지 체크한다.
8. 시스템이 화면에 선택 창을 띄운다. : 인출, 입금, 송금
Alternatives:
• 만약 시스템이 카드를 인식하지 못하면, 카드를 제거한다.
• 만약 카드 기한이 만료되었다면, 카드를 제거한다.
• 도난 신고가 들어온 카드라면, 카드를 제고하고, 경찰에 신고한다.
• 서버의 비밀번호와 입력받은 PIN이 일치하지 않으면, 에러 메세지를 띄우고, 다시 입력받는다.
• 3번의 입력이 모두 실패하면, 카드를 제거하고, 초기 상태 'Welcome' 메세지로 돌아간다.
• 고객이 'Cancel' 버튼을 누르면, 동작을 멈추고 거래를 취소한 후, 카드를 제거한다.
Postcondition: PIN 넘버의 유효성을 검증받았다.
これは、~>から抽出した「Validate PIN」というAbstract Use Caseのドキュメントの例です.Ex) Use Case Name: 현금 인출
Summary: 유효한 은행 계좌에서 소비자가 특정 양의 자금을 인출한다.
Actor: ATM 고객
Dependency: Include Validate PIN Abstract Use Case (주목) ★★★
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. Include Validate PIN Abstract Use Case
2. 고객이 인출을 누르고, 인출할 양을 입력한다.
3. 시스템이 계좌에 충분한 돈이 있는지 확인하고, 또한 한도 초과는 아닌지 체크한다.
4. 확인이 완료되면, 인출을 허가한다.
5. 현금을 드르르륵 내보낸다.
6. 시스템이 영수증을 출력한다.
7. 시스템이 카드를 제거한다.
8. 시스템이 다시 'Welcome' 메세지를 띄운다.
Alternatives:
• Description의 각 Step에 대한 대안을 적어두면 된다..
• ...
Postconditions: 고객이 현금 인출에 성공한다.
~>UseCaseのInclude関係により、上記のように文書記録をより容易に行うことができる.=>上記の例は次のようにDiagramとして表示されます.
Extend Relationship:まったく逆のレベルのUser Case Relationshipを指します.
ConcreteからAbstractまでのincludeとは異なり、AbstractからConcreteまでの点線矢印です.
extendはincludeとは異なります.
includeは、Concreteが使用しなければならないUse Caseです.
extendは、Concreteが選択的に使用するUseCaseです.
Reference
この問題について(工学-2.1使用事例モデリング), 我々は、より多くの情報をここで見つけました https://velog.io/@junttang/SW공학-2.1-Use-Case-Modelingテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol