Use Case Diagrams Use Case Descriptions

1. Use Case DiagramsUse Case Descriptions Use Case Book (Chapter 2) and Visual Modeling Book

2. Use Case Diagrams… actor use cases Withdraw Money Transfer Money

3. Extending the UML with Stereotyping • Know we have ‘Change’ in everything. • Extend UML? Built in feature! • extend UML for new ‘types’ ; New types of model elements! • allows customization of models for project • Stereotypes allow ‘refine’ / ‘reclassify’ ‘re-specify’ all model elements into a more specialized form rather than create additional symbols! • Example: might specify a Use Case as a <<mission critical>> or class name with the stereotype: <<boundary>> or <<control>> etc. • Most common UML stereotyped element is the class. • Stereotyping makes these different model elements!!!

4. Stereotypes in Modeling:Built-ins and User-Defined • Associations in Use Case Diagrams may be stereotyped as includes or extends. (built-ins) • Now, special kinds of associations between Use Cases (later) • Can be used to ‘increase relevance’ of model elements, such as use cases in requirements gathering. • (Much controversy on ‘extends’ and ‘includes’ and use cases invoking use cases...(Later) <<includes>> and <<extends>> … • Use Cases may also be stereotyped • “Stereotyped element”  has ‘special’ criteria. • e.g. A use case that is “mission critical” => must be processed within five seconds. • A <mission critical> use case ‘may’ be specified in a separate document addressing all stereotypes • Classes may also be stereotyped: <boundary>, others… • A boundary class is one that interacts directly with an actor… • Any UML modeling element may be stereotyped….

5. Use Case Template

6. Use Cases • Use Cases – a great tool that helps us to express interactions between system (application) and actors. • Meaningful to customer who is concerned with the ‘whats’ of the system. • Successful development of Use Cases requires an understanding of the goals of each of the use cases, which, in turn, is developed from identified, required functionality!

7. Goals of Use Cases • Interactions must present a value to actor. • actor may be an accounting system; general ledger system; person; customer; a relay; or thermostat… • Use Cases are black box representations; they • do not show implementation-specific language • do not want to imply how use case will be realized. • do not include language such as: people, interface widgets (buttons, menus…), IFTHENELSE statements; pseudo-code, more… • Are written in language of the application domain. • Are ‘abstractions’ of detailed interactions. • Capture stories addressing functional requirements…

8. Goals: Use Cases capture ‘whats’ • “Context-free” use • Excellent for requirements gathering / modeling; analyzing the user environment… •  Numbers of Use Cases? • 70-80 for very large system? • Medium sized – 20 to 50; • Small systems - fewer. •  Smaller number forces abstraction. Desirable.

9. Use Case Diagrams and Relationships

10. Actors • Actors trigger the start of a use case. • people, computer systems, date/time, relay, device... • Secondary actors • actor/role providing system inputs/outputs from another actor/role. First (outside) actor/role is ‘secondary actor’ and should be shown if its actions affect system reaction. • Actors may be: • Systems feeding your system and vice versa. • May be a legacy RDBMS or a legacy VSAM file… • Pressure and temperature may be actors (triggers) • Actors may influence how the classes are constructed; may themselves become classes – e.g. Customer • Customers exist in the domain model and are likely ‘entities.’ • Makes sense to take care in creating the right actor to interact with the use cases.”

11. Actors and Use Case Diagrams • Not customary to label association lines between actor & use case. • Default is <<communicates>> • But there are others… • Actors have ‘role names’ – useful if ‘association’ needs information beyond the fact that they simply interact. • Associations exist in many forms and among many model elements… • Exist between actors, use cases, and actor and use cases (at least in the context of use cases and actors). • Clearly, associations are quite abundant and essential when we create class diagrams and other model elements.

12. Associations: Generalization in Actors • Generalization: abstract the commonalities. • two sub-actors generalized into a super-actor • Have both behavior and attributes in common – described under the super-actor. • Super-actor should interact with use cases when ALL of its sub-actors interact the same way; • Sub-actors should interact with use cases when their individual interactions differ from that of the super-actor.

13. some use case Different use case

14. Use Case Associations Extend/Include Stereotypes • Stereotyped associations indicate a special kind of association. (good pix – Chap 2, Use Cases, Fig 2.12) • Extending (blunt side) is a special use case that extends the original use case (sharp) • Extending use case would not exist without the use case it is extending (extended use case); special case; exceptional behaviors. • Arrow points toward the base use case that is being extended… • Include stereotype allows use case designers to avoid duplicating steps across multiple use cases (a reuse strategy). • Arrow extends away from the owning parent use case. • (Similar steps put into the owner Use Case. • e.g. Authenticate User

15. The Use Case Template • A page or two of text; corresponds to a rounded oval in the Use Case diagram. • Definitely need a standard template. • Most organizations using Use Cases develop their own template format. Consistency is critical. • Use Case Name, iteration name/number; author, description, basic course of events; alternative paths, exception paths, triggers, assumptions; preconditions; post-conditions; references to related business rules; risks lists, and more. • All seem important.

16. Use Case Template - more • Create an “index of use cases” to index the use cases…(Entries already presented) • Name – unique and in English; verb  object • Iteration = the ‘maturity’ of the use case – and hence the maturity of our understanding of the functional requirements. • (façade, filled, focused … many name variations…) • Description –sentences describing the interaction. • Basic Course of Events – (NOT in Façade Use Case) • actor always takes first step (trigger) • always the happy path (simple path; most likely path) • can include a picture, if helpful. (screen shot, etc.)

17. Use Case Template - more • Alternative Paths • Other paths (may be less common) – but not the happy path • Each alternative and exception (below) should indicate WHERE in the basic course of events the alternative / exception emanates from. • Where is its starting point… • Techniques: cite the step number; labels in the basic course of events (preferred). Discuss. • Exception Paths • Like alternatives but typically shown for errors.

18. Use Case Template - more • Extension Points • The <<extends>> relationship exists between use cases when one use case provides an optional sequence of events that is included in the other use case. (See pg. 36, Visual Modeling book for picture) (see pg. 42, Use Case text) • “Extension point” in the flow of events shows step name (in braces) or step number from which the extending use case extends. (more later) • Note: the extending use case points to the extended use case. • Extending use case has ‘no life’ without the extended use case • Triggers: entry points for a use case - conditions • Assumptions – document things assumed to be true (but might not be true) (Critical section.)

19. Use Case Template - more • Preconditions – • Things that must be in place before an interaction may occur. (part of contract between use case and outside world) • (No, I really don’t see the difference between preconditions and assumptions.) • Post Condition – • part of contract between use case and outside world; specify outcomes; independent of alternative path. • e.g. transaction successfully posted. • Related Business Rules • Reference to business rules – may be separated • Related Risks addressed by this Use Case. • Include a reference to the Risk List document • Author and Date • at bottom; original date for each version: façade, filled, focused or whathaveyou.

20. Paths and Scenarios • Use Cases – abstractions; not many • Really need detailed interactions – scenarios. • Scenarios can provide details of the interactions! • Book provides three definitions for scenarios: • 1: merely an alternate path; • 2: an instantiation of the use case with a specific path plus relevant data; • 3: same as a use case (synonyms) •  Definition #2 – the “Instance,” where the scenario is a realization of a use case (one possible path) with included data. • Scenarios can be used during requirements capture for feedback to users and analysts that the use cases accurately reflect user needs, and in testing to test whether the system reflects the requirements. • Scenarios, then, are instances, of use cases (complete with production data) that effectively test one path through a use case.

21. Exception and Alternative Paths • Last look: • Exceptions are errors that occur. • Interactions thus contain steps to be executed. • Alternatives are close to basic course of events – just not the most likely course of events. • No errors- but some authors treat these to document error conditions. • Alternatives may be just as important as the basic course… • Some authors treat alternatives as MUCH less likely to occur. I don’t. • (Clearly, in some contexts, treating alternatives as those scenarios that are much less likely to occur may be appropriate) • Alternate Paths: very important to capture them (with full interactions in most cases, too). • Exception paths should be kept separate from alternative paths.

22. Read last three pages of chapter – Use Cases for Inquiry-only systems, Use Cases for Requests For Proposals, etc. • DO READ THESE.

23. Summary Points on Use Cases - fromUse Case Driven Modeling by Rosenberg • Essence of use case model is to capture user requirements of a new system or based on an existing system. • Detail all scenarios users will be performing • Use Case Model is at conceptual center of the process. • Developed in cooperation with domain model • Precedes any Analysis modeling • Use Cases – sequence of actions that an actor, often a person (role), but perhaps some other kind of external entity, such as another system, performs within a system to achieve a particular goal. • A complete and unambiguous use case describes one aspect of usage of the system without presuming any specific design or implementation. • Result of UC Modeling: all required system functionality is described in the use cases!! (Recall, however, that these evolve…) • Note: that the Façade Use Cases constitute an overview or umbrella look at the functionality; identification (without elaboration) of basic use cases – no basic course of events and many attributes not included. • We show use cases and actors on a use case diagram.

24. Other Names for Use Cases… • Some authors describe use cases with different designators (vice façade, focused, filled, etc.) as: • analysis-level use cases – never instantiated • (sometimes called business process use cases) • design-level use case – instantiated; concrete… contains real data…. • Some other authors call design-level use cases scenarios.

25. More on Prototyping the Interface

26. Prototyping Provides Basic Flow and More • Rapid prototyping can be used to demonstrate ‘proof of concept.’ • Can write a rough Users Manual from the prototype and use case descriptions. • (as if the prototype were a fully functioning system) • Prototyping normally provides the Basic Courses of events, because rapid prototyping normally (may often) ignores many alternatives and exceptions… • My own feeling is that the prototype, however, MUST include alternative courses of events in order to fully capture the user expectation (and hence, functionality).

27. Prototyping Provides Basic Flow and More • Prototype can contain simple windows containing radio buttons or generic icons – only to show functionality.. • Should have a window navigation diagram within the prototype. • Whether you build a prototype, draw mockups, or use some other technique to address the visual aspects of your system, it is very useful to link your screen designs to your use cases. • (Can do this manually or via a visual modeling tool.) • Use Case text should be relatively free of presentation details. • Field names often match up directly with attribute names in domain model (classes; entities). Use terms from domain! • Many nouns / actors are classes in domain model • Interactions will be ‘control’ later… •  Some controversy:  Important to do prototyping, mockups, etc. before you start writing use cases  or in conjunction with your use cases…Otherwise, you may spend lots of extra time trying to pin down your user expectations….

28. More on Basic Course of Events… • ‘Basic course of action’ is the main ‘start to finish path’ the user will follow. • Alternate course of actions represent an other used paths through the scenario. • Goal is NOT to build an elegant use case – • Goal is to ACCOUNT for everything user might do! • The more well-defined the system behavior is (modeled from the interactions in use case and other design drawings later), the easier it will be to build the system. • Developing Use Cases is sometimes referred to as a ‘behavioral approach’ to capturing requirements. Actually, this is correct.

29. Factoring out Commonality in Usage • Generalization - … • Includes – involves making one use case take full use of another use case. (more later) See page 42 for illustration) • Goes to ‘reuse’ = a prime objective of use case modeling. • Example I like: login or authentication use case may be ‘included.’ (factored out – not decomposition) • Association is defined as a stereotype. Put <<includes>> on arrow. • Extends – allows a modeler to insert one use case into another use case thus ‘extending’ the second use case. (use <<extends>> on arrow) • Can show ‘optional system behavior’ or behavior that is executed only under certain circumstances. (The ‘extends’) • Defined as a stereotype Put <<extends>> on association arrow. • <<extends>> points to use case that is extended (from extending use case)

30. More on Extends and Includes • UML defines a use case as one form of a class….But we normally do not generalize use cases, because generalization is most useful for building elaborate structures dominated by abstract use cases….(But some people do…) • Don’t spend lots of time worrying to use includes, extends ….. • Don’t spend lots of time with long, involved use case templates. • (I like the <<extend>> and <<include>> associations to assist in factoring functionality associated with Use Cases…)

31. Use Case Packages • A package is a grouping of related model elements such as classes, use cases... • Very desirable to group into packages primarily because these packages can be used to form logical boundaries for dividing work among sub-teams. • A good rule of thumb – each package should correspond with a chapter or at least a major section in the user manual. • A division of functionality, responsibilities, etc…… • Package Diagrams may contain use cases that are related….These go to functionality (architecture later) • In Rose, use the Use Case Model (in the browser) and group the Use Cases ‘by functionality’ as much as possible…

32. More – very important tidbits here. • The relationship between requirements and use cases is subject of much discussion. • A use case describes a unit of behavior • A requirement describes a law that governsbehavior • A use case can capture/satisfy/describe one or more functional requirements • A functional requirement may be satisfied by one or more use cases… • Note that a system will have other requirements besides ‘functional,’ such as performance, maintainability, scalability, reliability… that don’t map easily to use cases…. • These tend to ‘thread themselves through Use Cases.’ • Non-functional requirements • Some will readily be captured via the software architecture (later in course). • At end of use case modeling, you are ready to embark upon the creation of an analysis model (or preliminary design) … (some authors call it a robust analysis…) • Probably entering a second iteration within Elaboration Phase. • This will involve very careful and highly iterative analysis of use cases and all their scenarios. • This can only take place after the full Use Case Model is ‘completed.’

33. Summary • Where are we in our projects? • ‘Done’ with real-world domain objects and business modeling…. • Have done rapid prototyping of proposed system to gain user interface information… • Identify your use cases using use case diagrams • Organize use cases into packages…(related functionality) • Allocate functional requirements to the use cases and domain objects at this stage….(early Use Case iteration…) • To do: we will have a full Requirements Review after next bullet: • Will develop full descriptions of each use cases – basic courses of action that represent mainstream interactions and alternate courses for less-frequently traveled paths and error conditions. Major Effort! • Will then develop: analysis model…. Major Effort! • For each use case, identify first cut objects to accomplish the stated scenario. Use stereotypes… • Update domain model class diagram with new objects and attributes as you discover them. • Ensure initial vision and related support documents are ALL reviewed and updated. Ensure cost/schedule/’go position’ still looks good…. • To do: have a Preliminary Design Review……

34. Common Mistakes • 10. Write functional requirements instead of usage scenario text • 9. Describe attributes and methods in too much detail rather than usage • 8. Write the use cases too tersely (won’t do much good!) • 7. Divorce yourself completely from the user interface • Big mistake!!! • 6. Avoid explicit names for your boundary objects. (more later) • 5. Write using a perspective other than the user’s, and doing so in passive voice. • 4. Describe only user interactions; ignore system responses. • 3. Omit text and references for alternative courses of action • 2. Focus on something other than what’s ‘inside’ a use case, such as how you get there (precondition) or what happens afterward (post-condition). • 1. Spend a month deciding whether to use <<include>> or <<extend>> associations.