Rekayasa Perangkat Lunak

Transcription

1 Rekayasa Perangkat Lunak Untuk SISTEM KOMPUTER Kuliah 7: Use Case Mohammad Iqbal Based-on slide Ivan Marsic

2 Topik Aktor, Tujuan Sketsa/Ringkasan Use Cases Diagram Use Case Matrik Traceability System Boundary dan Subsystem Use Case Specification Detail Diagram System Sequence Security dan Managemen Resiko

3 Use Cases Digunakan untuk analisis kebutuhan fungsional dan Specification Use case adalah deskripsi langkah demi langkah bagaimana user menggunakan sistem untuk menyelesaikan tujuan bisnis Detailed use cases are usually written as usage scenarios or scripts, showing an envisioned sequence of actions and interactions between the external actors and the system-to-be

4 Deriving Use Cases from System Requirements REQ1: Keep door locked and auto-lock REQ2: Lock w hen LOCK pressed REQ3: Unlock w hen valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring the device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries Y Actor Actor s Goal (what the actor intends to accomplish) Use Case Name Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1) Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2) Landlord To create a new user account and allow access to home. AddUser (UC-3) Landlord To retire an existing user account and disable access. RemoveUser (UC-4) Tenant To find out who accessed the home in a given interval of time and potentially file complaints. InspectAccessHistory (UC-5) Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1) Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2) Tenant To configure the device activation preferences. SetDevicePrefs (UC-6) LockDevice To control the physical lock mechanism. UC-1, UC-2 LightSwitch To control the lightbulb. UC-1, UC-2 [to be identified] To auto-lock the door if it is left unlocked for a given interval of time. AutoLock (UC-2) ( Actors already given if working from user stories instead of system requirements )

5 Types of Actors Initiating actor (also called primary actor or simply user ): initiates the use case to achieve a goal Participating actor (also called secondary actor): participates in the use case but does not initiate it. Subtypes of participating actors: Supporting actor: helps the system-to-be to complete the use case Offstage actor: passively participates in the use case, i.e., neither initiates nor helps complete the use case, but may be notified about some aspect of it (e.g., for keeping records)

6 Use Case Diagram: Device Control UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login system boundary First tier use cases Second tier use cases actor «initiate» «initiate» UC1: Unlock «include» UC7: AuthenticateUser «participate» «participate» «participate» LockDevice Tenant «initiate» «initiate» UC2: Lock «participate» «participate» LightSwitch «initiate + participate» Landlord communication use case Timer

7 Use Case Diagram: Account Management UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login Account Management Subsystem «initiate» UC3: AddUser Landlord «initiate» «participate» «initiate» «initiate» UC4: RemoveUser UC5: InspectAccessHistory «include» «include» «include» «include» UC8: Login Tenant UC6: SetDevicePrefs

8 GUI for UC6: Set Device Pref s Device Preferences File Configure Help Activate for valid key Activate for burglary attempt Lights Music Air-conditioning Heating Alarm bell Police Send SMS Apply Close ( NOTE: Lock device is mandatory, not an option )

9 Use Case Generalizations More abstract representations can be derived from particular representations UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login Authorized Person UC9: ManageUsers Tenant Landlord UC3: AddUser UC4: RemoveUser Actor Generalization Use Case Generalization

10 Optional Use Cases: «extend» Example optional use cases: ManageAccount UC5: InspectAccessHistory UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login UC6: SetDevicePrefs Key differences between «include» and «extend» relationships Is this use case optional? Is the base use case complete without this use case? Included use case No No Extending use case Yes Yes Is the execution of this use case conditional? Does this use case change the behavior of the base use case? No No Yes Yes [ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, ]

11 Login Use Case? BAD: GOOD: Login Landlord AddUser SetDevicePrefs Landlord AddUser SetDevicePrefs Login

12 Traceability Matrix (1) Mapping: System requirements to Use cases REQ1: Keep door locked and auto-lock REQ2: Lock w hen LOCK pressed REQ3: Unlock w hen valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring the device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries Req t PW UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login REQ1 5 REQ2 2 REQ3 5 REQ4 4 REQ5 2 REQ6 1 REQ7 2 REQ8 1 REQ9 1 Max PW Total PW Continued for domain model, design diagrams,

13 Traceability Matrix Purpose To check that all requirements are covered by the use cases To check that none of the use cases is introduced without a reason (i.e., created not in response to any requirement) To prioritize the work on use cases

14 Schema for Detailed Use Cases Use Case UC-#: Name / Identifier [verb phrase] Related Requirements: Initiating Actor: Actor s Goal: Participating Actors: List of the requirements that are addressed by this use case Actor who initiates interaction with the system to accomplish a goal Informal description of the initiating actor s goal Actors that will help achieve the goal or need to know about the outcome Preconditions: Postconditions: Flow of Events for Main Success Scenario: What is assumed about the state of the system before the interaction starts What are the results after the goal is achieved or abandoned; i.e., what must be true about the system at the time the execution of this use case is completed 1. The initiating actor delivers an action or stimulus to the system (the arrow indicates the direction of interaction, to- or from the system) 2. The system s reaction or response to the stimulus; the system can also send a message to a participating actor, if any 3. Flow of Events for Extensions (Alternate Scenarios): What could go wrong? List the exceptions to the routine and describe how they are handled 1a. For example, actor enters invalid data 2a. For example, power outage, network failure, or requested data unavailable The arrows on the left indicate the direction of interaction: Actor s action; System s reaction

15 Use Case 1: Unlock Use Case UC-1: Related Requirem ts: Initiating Actor: Actor s Goal: Unlock REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1 Any of: Tenant, Landlord To disarm the lock and enter, and get space lighted up automatically. Participating Actors: Preconditions: Postconditions: LockDevice, LightSwitch, Timer The set of valid keys stored in the system database is non-empty. The system displays the menu of available functions; at the door keypad the menu choices are Lock and Unlock. The auto-lock timer has started countdown from autolockinterval. Flow of Events for Main Success Scenario: 1. Tenant/Landlord arrives at the door and selects the menu item Unlock 2. include::authenticateuser (UC-7) 3. System (a) signals to the Tenant/Landlord the lock status, e.g., disarmed, (b) signals to LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on 4. System signals to the Timer to start the auto-lock timer countdown 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]

16 Subroutine «include» Use Case Use Case UC-7: AuthenticateUser (sub-use case) Related Requirements: Initiating Actor: Actor s Goal: Participating Actors: Preconditions: Postconditions: REQ3, REQ4 stated in Table 2-1 Any of: Tenant, Landlord To be positively identified by the system (at the door interface). AlarmBell, Police The set of valid keys stored in the system database is non-empty. The counter of authentication attempts equals zero. None worth mentioning. Flow of Events for Main Success Scenario: 1. System prompts the actor for identification, e.g., alphanumeric key 2. Tenant/Landlord supplies a valid identification key 3. System (a) verifies that the key is valid, and (b) signals to the actor the key validity Flow of Events for Extensions (Alternate Scenarios): 2a. Tenant/Landlord enters an invalid identification key 1. System (a) detects error, (b) marks a failed attempt, and (c) signals to the actor System (a) detects that the count of failed attempts exceeds the maximum allowed 1a. number, (b) signals to sound AlarmBell, and (c) notifies the Police actor of a possible break-in 2. Tenant/Landlord supplies a valid identification key 3. Same as in Step 3 above

17 Acceptance Test Case for UC-7 Authenticate User Test-case Identifier: Use Case Tested: Pass/fail Criteria: Input Data: Test Procedure: TC-1 UC-1, main success scenario, and UC-7 The test passes if the user enters a key that is contained in the database, with less than a maximum allowed number of unsuccessful attempts Numeric keycode, door identifier Expected Result: Step 1. Type in an incorrect keycode and a valid door identifier System beeps to indicate failure; records unsuccessful attempt in the database; prompts the user to try again Step 2. Type in the correct keycode and door identifier System flashes a green light to indicate success; records successful access in the database; disarms the lock device

18 Use Case 2: Lock Use Case UC-2: Related Requirements: Initiating Actor: Lock REQ1, REQ2, and REQ5 stated in Table 2-1 Any of: Tenant, Landlord, or Timer Actor s Goal: To lock the door & get the lights shut automatically (?) Participating Actors: Preconditions: LockDevice, LightSwitch, Timer The system always displays the menu of available functions. Postconditions: The door is closed and lock armed & the auto-lock timer is reset. Flow of Events for Main Success Scenario: 1. Tenant/Landlord selects the menu item Lock System (a) signals affirmation, e.g., lock armed, (b) signals to LockDevice to arm the lock (if 2. not already armed), (c) signal to Timer to reset the auto-lock counter, and (d) signals to LightSwitch to turn the light off (?) Flow of Events for Extensions (Alternate Scenarios): 2a. System senses that the door is not closed, so the lock cannot be armed 1. System (a) signals a warning that the door is open, and (b) signal to Timer to start the alarm counter 2. Tenant/Landlord closes the door System (a) senses the closure, (b) signals affirmation to the Tenant/Landlord, (c) signals to 3. LockDevice to arm the lock, (d) signal to Timer to reset the auto-lock counter, and (e) signal to Timer to reset the alarm counter

19 Use Case 3: Add User Use Case UC-3: Related Requirements: Initiating Actor: Actor s Goal: Participating Actors: Preconditions: Postconditions: AddUser REQ6 stated in Error! Reference source not found. Landlord To register new or remove departed residents at runtime. Tenant None worth mentioning. (But note that this use case is only available on the main computer and not at the door keypad.) The modified data is stored into the database. Flow of Events for Main Success Scenario: 1. Landlord selects the menu item ManageUsers 2. Landlord identification: Include Login (UC-8) 3. System (a) displays the options of activities available to the Landlord (including Add User and Remove User ), and (b) prompts the Landlord to make selection 4. Landlord selects the activity, such as Add User, and enters the new data 5. System (a) stores the new data on a persistent storage, and (b) signals completion Flow of Events for Extensions (Alternate Scenarios): 4a. Selected activity entails adding new users: Include AddUser (UC-3) 4b. Selected activity entails removing users: Include RemoveUser (UC-4)

20 Use Case 5: Inspect Access History Use Case UC-5: Inspect Access History Related Requirements: REQ8 and REQ9 stated in Table 2-1 Initiating Actor: Any of: Tenant, Landlord Actor s Goal: Participating Actors: Preconditions: To examine the access history for a particular door. Database, Landlord Tenant/Landlord is logged in the system and is shown a hyperlink View Access History. Postconditions: None. Flow of Events for Main Success Scenario: 1. Tenant/Landlord clicks the hyperlink View Access History 2. System prompts for the search criteria (e.g., time frame, door location, actor role, event type, etc.) or Show all 3. Tenant/Landlord specifies the search criteria and submits 4. System prepares a database query that best matches the actor s search criteria and retrieves the records from the Database 5. Database returns the matching records 6. System (a) additionally filters the retrieved records to match the actor s search criteria; (b) renders the remaining records for display; and (c) shows the result for Tenant/Landlord s consideration 7. Tenant/Landlord browses, selects interesting records (if any), and requests further investigation (with an accompanying complaint description) System (a) displays only the selected records and confirms the request; (b) archives the request in 8. the Database and assigns it a tracking number; (c) notifies Landlord about the request; and (d) informs Tenant/Landlord about the tracking number

21 System Boundary & Subsystems Use Case Variations Example: Case (a): Local face recognition Local computer Apartment building Face image Security camera Case (b): Network Remote face recognition FaceReco, Ltd.

22 Modified Use Case Diagram Authentication subsystem (FaceReco, Ltd.) is externalized from the system-to-be: UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login UC2: Lock Tenant «participate» UC1: Unlock «include» LockDevice UC7: AuthenticateUser «initiate» UC3: AddUser «participate» «participate» Landlord «initiate» UC4: RemoveUser «include» «include» «participate» FaceReco, Ltd. UC8: Login

23 Security and Risk Management Identifying and preempting the serious risks to system s safe and successful functioning Risk types: Intolerable As low as reasonably practical (ALARP) Acceptable Example abuse case input sequence: invalid-key, invalid-key, maxnumofattempts ; wait maxattemptperiod ; invalid-key, invalid-key,

24 System Sequence Diagram [Modeling System Workflows] Use case: Unlock User «initiating actor» select function( unlock") : System LockDevice «supporting actor» LightSwitch «supporting actor» Timer «offstage actor» prompt for the key enter key verify key signal: valid key, lock open open the lock turn on the light start ("duration ) Main success scenario Similar to UML sequence diagrams, but for actor interactions instead of software object interactions

25 System Sequence Diagram [Modeling System Workflows] Use case: Unlock User «initiating actor» select function( unlock") : System AlarmBell «supporting actor» Police «offstage actor» loop prompt for the key enter key verify key signal: invalid key prompt to try again sound alarm notify intrusion Alternate scenario (burglary attempt)

26 Activity Diagram [Modeling System Workflows] Initial node Select Unlock Action Enter Key Verify Key Decision [authorized] [not authorized] Signal Success Open Lock & Lit Light Notify Intrusion Sound Alarm Start Autolock Timer Activity final node Merge