1. Structure and Content of Use Cases

2. Will look at a Use Case template Much more detail on preconditions and post-conditions and other use case properties. Will introduce concepts of ‘extension’ and ‘diagrams’ Will look at ‘scenarios’ and ‘use case realizations.’

3. System and External Events System: a collection of connected units that are organized to accomplish a specific purpose. A system can be described by one or more models, possibly from different viewpoints. Synonym: physical system. The ‘system’ forms a whole. The ‘system’ has a distinct boundary.  Boundary defines the border between the system and the environment that surrounds and interacts with the system.  Can view system as black box that responds to stimuli and produces outputs. Systems can also be treated as a stimulus-response machine. In a use case model, the detected / generated events are:  Major events – those that start a use case  Minor events – those that are generated as part of an ongoing interaction between the system and an actor. The Use Case description must clearly describe the event that will start the use case.  The ‘communicates’ relationship clearly denotes the source of the initial event (actor) that starts the use case and whether the use case starts interactions with any additional supporting actors.

4. Preconditions and Post-Conditions Sometimes, the system must be in a particular state in order for the use case to be executed.  We declare the required condition, or state, in which the system must be: the precondition. Examples:  User must be authorized to use the system Alternatively: the user is logged-in  The system must have sufficient cash available to process a typical transaction.  The communications channel to the host system is open and available for use…. Preconditions may be established by execution of another use case, so we can say:  The use case “Authenticate User’ has been executed.

5. Preconditions and Post-Conditions Doesn’t matter ‘how’ system was put into this ‘state.’ May be a number of ways ‘Authenticate User’ was executed…  May be executed ‘normally.’  May be executed giving reduced permissions…  May have used a card; retinal scan? All these are different flows of events – all resulting in the same ‘state.’ Preconditions: necessary but not sufficient.  Necessary? Yes.  Sufficient? No. Needs an actor to initiate the use case. Preconditions refer to externally-visible signs actors would understand. Preconditions – cannot depend on design or implementation constraints. True regardless how system is implemented. Postconditions – statements about the state (or condition) in which the system is at the conclusion of the use case.  Not always triggers for other use cases.  Help reader understand what the result of executing the use case has been. State of system at end of executing use case… Example: the user is authorized to execute transactions in the system, or  The user has been barred from using the system….

6. Preconditions and Post-Conditions No preconditions?   there is no restriction on when the use case can be started. No post-conditions?   there are no explicit constraints on the state of the system when the use case ends.

7. Independence of Use Cases Use Cases do not communicate with each other. Use Cases are independent of each other Sequences of behavior that results in something of value to a user of the system. Use cases present things of independent value!  Consider the use case, “Log In”  What do you think???

8. Independence of Use Cases Consider use cases:  Login, Select Products, Enter Order Information, Enter Shipping Information, Enter Payment Information, Confirm Order. These ‘things’ do describe desired behaviors, but is ‘each’ independently valuable? Imply a ‘sequencing of use cases.’ Not desirable! Imply ‘dependencies.’ Regroup into: Browse Products and Place Orders. Preconditions: Specify some ‘condition’ or ‘state’ that must exist before use case can begin.  Might occur because of some other use case completing… State Use Case precondition dependencies in terms of some condition that must be satisfied is robust and unlike to be affected by the use case model that might have use cases split or combined…

9. Nature of Flows of Events Basic Flow: what ‘normally happens’ when the use case is performed. Sub-flows:  Complex flows may be divided into Subflows.  Desired to improve readability of the text.  Sub-flows must have a clear purpose and be atomic. Remember: Use Case can perform sub-flows in optional sequences or in loops or even several at a time. Name and number them. Use an Active name

10. Subflows Examples  The Browse Products and Place Orders use case contains the following sub-flows: S1 Validate Payment Instructions S2 Validate Shipping Instructions S3 Execute the Financial Transaction  Can reference the subflow from within another flow (like the Basic Course of Events) as: Perform subflow

11. Subflows  An extract from the Browse Products and Place Orders use case. Illustrates the use of a subflow named in the previous slide.  7. The Customer enters the payment instructions.  8. The system captures the payment instructions using a secured protocol.  9. Perform Subflow Validate Payment Instructions.  {Invalid Payment Instructions}  10. The system prompts the Customer to enter shipping instructions.  11. Customer enters shipping instructions supplying at least the billing address, shipping address, shipper preference, and delivery options.  12. The system captures the shipping instructions using a secure protocol  13. Perform Subflow Validate Shipping Instructions  {Invalid Shipping Instructions}  14. Perform Subflow Execute the Financial Transaction  …

12. Subflows Perfect candidate in Deliverable #3:  Authenticate User (or whatever you call this activity)  Sub-flows are often separately documented.  Remember, number it and name it giving it an action name, such as:  S1. Authenticate User (or ….)

13. Extension Points Extension Points: named “places” in the flow of events where additional behavior ‘can’ be inserted / attached. See: {Invalid Payment Instructions}, {Invalid Shipping Instructions}, {Display Product Catalogue}, {Out of Stock}, {Process the Order}, {Order Processed}…  Private (used only within the use case in which it appears)  Public – Covered separately as an ‘extended Use Case  Notation: Within flow of events, extension points are shown in bold and braces… The primary use (not the only use) for extension points is for defining alternative flows (ahead) Within a flow of events, extension points are shown in bold and enclosed in curly brackets. (are other ways – just a preference)

14. Extension Points - example No specific naming convention for extension Should:  ‘sum up’ some aspect of where the position is in the use case, or  indicate what the use case has achieved. Can appear anywhere in flow, but appear nicer on their own line (not embedded) Consider the following Use Case:  Note some extension points are used as headings, while other extension points are used to indicate state of the use case...

15. Extension Points - example  With extension points, the basic flow now becomes: 1. The Use Case starts when the actor Customer selects to browse the catalogue of product offerings. {Display Product Catalogue} 2. The system displays the product offerings highlighting the product categories associated with the Customer’s profile. {Select Products} 3. The Customer selects a product to be purchased, entering the number of items required. 4. For each selected item that is in stock, the system records the product identifier and the number of items required, reserving them in inventory and adding them to the Customer’s shopping cart. {Out of Stock} 5. Steps 3 and 4 are repeated until the Customer selects to order the products. {Process the Order} 6. The system prompts the Customer to enter payment instructions. …

16. Extension Points - Remarks No specific naming conventions for extension points. Least intrusive if they sum up some aspect of where the position is in the use case or what the use case has achieved. Can occur anywhere in flow of events.  Preferably on their own line and not embedded.  Good way is as ‘headings’ in text (previous slide) to delimit self-contained sections of flows.

17. Alternate Flows Definition: Alternate flows of events cover behavior that is of optional, exceptional, or truly alternate character in relation to another flow of events. Always dependent upon some condition occurring at an explicit point in another flow.  If alternate flow is not conditional, it is not an alternative. Always named and numbered, such as A1…An Give them active names that sum their purpose

18. Alternative Flows Three kinds:  1. Specific Alternative Flows – These are alternative flows that start at a specific named point in another flow of events…  2. General Alternative Flows – These are alternative flows that can start at any point within a use case,  3. Bounded Alternative Flows: These are like general alternative flows but can only occur between two named points.

19. Alternate Flows – more specifically. The first line of the alternate flow’s flow of events identifies the point at which the alternate will be activated and the conditions under which it will occur: Clause always has the form:  At {extension point} when … or,  At {extension point} if  Last line of alternative flow, and any other exit points within it, must state explicitly where the actor resumes the flow of events. For optional behavior, this is usually the original extension point; For truly alternative behavior, this is usually another extension point; For exceptional behavior, this is usually the end of the use case.  The flow of events can only be resumed at an extension point that identifies a single location or the extension point from which it was started.

20. Alternate Flows - Context In our use case, Browse Products and Place Orders, there are several alternative flows, including  A3 Handle Product Out of Stock and  A1 Undertake a Keyword Search. Example 1: A specific alternate flow: A3. Handle Product Out of Stock At {Out of Stock} ‘if’ there are insufficient amounts of the product in the inventory to fulfill the Customer request.  The system informs the user that the order cannot be fulfilled.  …the flow continues to describe the offering of alternative amounts and products to the Customer  The flow of events is resumed from the point at which it was interrupted.

21. Alternate Flows - Context Example 2: A bounded alternative flow  A1 Undertake a Keyword Search  ‘At’ any point between {Display Product Catalogue} and {Process Order} ‘when’ the Customer selects to undertake a keyword search. The system prompts the Customer to enter the product search criteria The Customer enters the product search criteria …The flow continues to describe what the Customer and the System do to complete the search… The flow of events is resumed at {Select Product}

22. Why all this? Why all the attention to the structure of flow of events - especially on exception points and alternative flows? Why not do everything using sub-flows and if statements as one long and continuous narrative? Remember: use cases are used to manage the scope of the system.  Want to be able to define meaningful subsets of functionality that will actually deliver value to customer.  Want to be able to take subsets of functionality away without breaking the system and/or failing to provide any value at all.  If we manage everything at the use case level, no chance to do scope management, because use cases will be large and relatively indivisible. By structuring, can remove alternatives and thus remove scope Nature of alternative flows is to permit behavior to be removed without affecting the basic flow.

23. Consider: Basic Flow:  Insert The Card  Validate Card  Validate Bank Customer  Select Withdraw  Select Amount form List of Standard Amounts  Confirm Transaction with Banking System  Dispense Money  Eject Card

24. List of Alternate Flows A1 Card cannot be identified A2 Customer cannot be identified A3 Withdraw not required A4 Nonstandard amount required A5 No money in account A6 Attempt to withdraw more than daily amount A7 No connection to the banking system A8 Link goes down A9 Card stolen – the card is on the hot card list A10 The ATM is out of money A11 The card cannot be dispensed A12 A receipt is required A13 The withdrawal is not from the card’s primary account …

25. So, To not include A3 Withdraw not required, A4 Nonstandard amount required, A12 A receipt is required, … would we still have a usable system that delivers value? Yes. Not all alternative flows represent core functionality. Some may not be required at all and cost too much or not provide enough value to warrant further development. Impact of not delivering part of the basic flow???  Like validate card, dispense cash, …  Without basic flow, use case cannot deliver any value at all. Alternative Flows allow us to incrementally add functionality on top of the basic flow as the use case evolves and/or to remove functionality as the time and money run out. Can easily see the impacts of not including a use case or an alternative flow. It is this structure that makes use cases so integral to iterative and incremental development. Allows the targeting of individual sets of flows onto the iterations and the value provided by the system to increase iteration by iteration.

26. Some Bullets “Design complexity” is a function of how hard something is to implement, whereas “use case complexity” is a function of how hard the desired behavior is to describe. The complexity of the system comes from the problem domain and certain non-functional requirements that dictate the required responsiveness of the system, the types of devices that must be used, the need to correctly report / detect, … But the use-case model itself may be quite simple. Too many use cases? – Will struggle to write meaningful use cases and come up with ways to string them together to provide something of value…. The internal complexity of the system is completely unrelated to the number or length of the use cases. What the use cases reflect is really the complexity of USING the system, and that should be as simple as possible.

27. Scenarios Scenarios are instances or specific occurrences of use cases. Walk through a particular use case – use values…... Useful for defining test cases and for verification Typical use case has a basic flow and several alternative flows of events. A single scenario will walk through one particular path of the use case from beginning to end. As you go through a scenario, look at boundary conditions to see how a small change in the value of some variable causes some very different behavior in the system as a whole. Boundary conditions help you to find flaws in the use case.. Boundary conditions help us to find interesting values for the variables Looking at boundary conditions will reduce the number of scenarios to test. Impossible to formally document all of them.

28. Use Case Realizations Represent the design perspective of a use case. Organizes the artifacts related to the use case, but which belong to the design model. Use Case realization is a collaboration of components that realizes (or performs) some use case.  Typically objects; sequences of objects collaborating… Shows collaboration of elements within the system. Provides a bridge between the descriptions of the system used by external stakeholders and the internal stakeholders. Can be expressed using UML constructs (interaction diagrams) or textually using structured English. For each use case in the use-case model, there is a use-case realization in the design model with a realization relationship to the use case. More later.