Week IV in SOS

1. Week IV in SOS Tuesday Project Time -- 4:15pm-5pm URL for project(s) due to Judy by Friday 5pm Friday Paper OOAD Handouts thru last Thursday (see web site) Lectures coming this week. Exam week V or VI. Use Case Detail

2. Week IV, Today Recap Use Cases, Part I -- Business Dynamics Debrief Homework Use Case Diagram for EU-Lease Structure the Use Case Model – refining: <<include>> and <<extend>> use cases actor and use case generalization supplemental questions scoping iterations Start Use Case Detail … Tomorrow Continue Use Case Detail Derive the User Interface

3. Structure the Use Case Model

4. Use Cases ~ recap from last time • 6 things to know about a Use Case model: • How do I discover Use Cases? • What a Use Case is NOT • Where does ‘Use Case’ fit in the development process? • What are the basic elements of a Use Case Model? • How do I draw a Use Case Model as a diagram? • After the basics, how do I refine the Use Case Model?

5. The Use Case Model ~ What are its parts called? • There are four core elements of a Use Case model: • the system (boundary) • the set of all use-cases specify a system in terms of its intended functions (functionality). This defines a firm boundary around the system, separating it from the outside world. • the actor • someone or something outside the system (boundary) that interacts with the system • the use case • a sequence of actions a system performs that yields an observable result of value to a particular actor. • the request • a line of communication between actor and use-case -- typically an initiating 'transaction.' It crosses the system boundary.

6. The Use Case Model ~ What are its parts called? shown here as a Use Case Diagram

7. Use Case documentation ~ the initial elements writing up the Use Case... Initially, just the: • Use Case name: • For example, "Order Vehicle Model" • Use Case description, a brief statement of: • the nature of what the actor needs (the system) to do • the observable result of value to the actor • For example, In “Order Vehicle Model” the actor wishes to ... • add more vehicles of a particular model into EU-Rent’s vehicle inventory, • increase the model’s vehicle-count of vehicles owned. • More elements will be added to the documentation of a use case. • (to be covered in a future lecture).

8. Use Case documentation ~ the initial elements • For example Launch Auction [ includes: Write Letters ] ... Begin the processing to dispose of an identified number of vehicles of a particular model. This involves: –     recording a specific number of vehicles of a particular model as being "surplus." –     producing letters to the "interested members," notifying each selected person of the auction and inviting the member to submit a bid. –     recording an initial, zero-amount bid record for each selected/contacted member.

9. After the basics, how do I refine a Use Case Model? In addition to the associations between actors and use-cases, you can define special kinds of association between use-cases: • using UML's stereotype extensions: • the <<include>> stereotype • the <<extend>> stereotype • using use-case & actor generalization / specialization • used to describe a specific form of a more general use-case or actor.

10. Use Case refinement using UML stereotypes • UML has standard features to extend the language. • The Guillemet character denotes a stereotype extension. << >> • 2 stereotype extensions are used to define relationships between Use Cases: • <<include>> • <<extend>> • Note: “UML trivia” ~ a Guillemet is a single symbol, not two ‘less-than’ or two ‘greater-than’ characters.

11. The Use Case <<include>> example 1 • Refine using <<include>> if you find you are repeating actions in two or more separate use-cases and you want to “factor out” the common actions into one use-case that can be used in many places. • For example, • You may find that the "Check Balance" use-case in the ATM system also includes the step "System prints receipt." • This can be factored out into a "Print receipt" use-case which is related to each of the including use-cases.

12. The Use Case <<include>> example 2 • Refine using <<include>> if you find you are repeating actions in two or more separate use-cases and you want to “factor out” the common actions into one use-case that can be used in many places. • For example, • In EU-Rent's Inventory Management system, you will discover that two use cases include the functionality to produce a Rental Group summary. • This common functionality can be factored out into a separate use-case that is then related to each of the including use-cases.

13. The Use Case <<extend>> example 1 • Refine using <<extend>> when you need to describe a conditional variation of a base case. • The “extension points” will be defined in that base case. • For example, • The third entry of an invalid PIN in a single session retains the card and triggers an activity in a security violation use-case. • This is used primarily to represent optional behavior, to handle exceptions.

14. The Use Case <<extend>> example 2 • Refine using <<extend>> when you need to describe a conditional variation of a base case. • The “extension points” will be defined in that base case. • For example, • A vehicle model is typically discontinued when there are no vehicles of the model currently owned by EU-Rent. When there are vehicles, there needs to be special handling (e.g., to dispose of those vehicles).

15. Actor Generalization This is in the Workshop – let’s discuss it here (as a jump-start to the Workshop) read it there, too

16. Where do we go from here? • Once identified, it can still be hard to decide whether a set of actor-system interactions is a single use-case or several use-cases. • For example,... • Why wasn't prompting for the PIN and validating it a complete use-case? "Use cases emerge when you focus on the things of value that a system provides to an actor." ~ Kruchten • We focus on these 'valued outputs' by analyzing the 'Information Requirements' of the system, in two flavors: (1) the Information Queries • providing critical outputs from the system (2) the Information Updates • keeping the system data used in (1) current and correct

17. Where do we go from here? • Once identified, it can still be hard to decide whether a set of actor-system interactions is a single use-case or several use-cases. • For example,... • Consider the Use-Case from EU-Rent…. Why wasn't special handling (e.g., to dispose of those vehicles) a complete use-case? .

18. A word on use case 'supplemental questions'

19. A word on the S/E Process(& iterative development) • The S/E Process The Construction Phase builds the system in a series of iterations. You set up the iterations by selecting use cases for each, or dividing use cases into ‘scenarios’…. Release Early, Release Often! Inception Elaboration Construction 1 | 2 | 3 | … Transition