1. Use Cases UML

2. Use Cases

3. What are Use Cases?  A statement of the functionality users expect and need, organized by functional units  Different from user stories because they are from the software’s perspective  Functional units are any natural division  Relationships between user types and use cases  User activities, decisions, and objects involved  In terms of user types: classifications that the system recognizes

4. Use Case Usage  determining features (requirements)  basis for communicating with clients  generating test cases

5. For requirements sprint  Concept  User stories  Personas  Full set of use cases and requirements

6. For each sprint  Select the use case(s) that you will support  Identify the requirements they engender  For those cases,  Functional spec: what it does  Test cases: how I know it does it  Design doc: how it does it  User manual: how the user knows what to do  Code: does it

7. Documenting Use Cases  Simple text description  UML diagrams

8. Documenting Use Cases  We will use simple text description  Examples from prior years  Butterfly Lab Butterfly Lab  Foreign Language Resource Center Foreign Language Resource Center

9. UML: Unified Modeling Language A BRIEF DETOUR

10. What is UML?  software blueprint language: common vocabulary  for analysts, designers, and programmers  not for the customer  applicable to object-oriented problem solving  begins with the construction of a model  models consist of objects  interact by sending messages  attributes: things they know  behaviors or operations: things they can do  state  Also used for business processes  Contradicts “not for the customer”

11. Modeling (Will return to it)  Based on abstraction  looking only at relevant information  hiding details  Multiple views  as orthogonal as possible  each view has information that  is unique  appears in other views  common information is consistent

12. Modeling Languages and Processes  Language: syntax  usually graphical  used to express design  Process: steps to take to create a design  Many processes, not a lot of agreement  General consensus has built around UML as a language

13. UML History  Three well received models in early 90s  Grady Booch (Rational), Object Oriented Analysis and Design  Jim Rumbaugh (GE), Object Modeling Technique  Ivar Jacobson (Ericsson), Object Oriented Software Engineering  By ’95, all three “amigos” were working for Rational (acquired by IBM in 2002)  OMG adopted UML in ’97 (www.uml.org)www.uml.org  Version 2.0 completed in 2004

14. Why Study UML?  software engineering cultural literacy  useful tool  natural model for design  lots of good tools  Rational generates C++ and Java code  Some people expect tools to generate code  good for prototyping  good for development?  Would this be good or bad?

15. What UML Is and Isn’t  Syntax only  Standardized  Language and tool independent  Generic enough to be  Usable in lots of environments  And leaving you lots of space to misuse it  Extendable through “stereotypes”  New symbols built up from basic ones  Used to develop a business process model  Not a process  There is a companion one—Unified Process

16. Good Reference  Fowler, UML Distilled, Addison-Wesley  3 rd edition, 2004, covers 2.0  Short  Good summary charts on inside covers

17. Diagram Types DiagramStatic/DynamicPhase Use caseDynamicRequirements ClassStaticDesign ObjectStaticDesign SequenceDynamicDesign CollaborationDynamicDesign StatechartDynamicDesign ActivityDynamicDesign ComponentStaticCode DeploymentStaticDeploy

18. UML Views: Diagram Types Use Case – outside view (scenarios) Class – classes and relationships among them Object – instances instead of classes Sequence – how & when objects interact through messages Collaboration – how objects interact through roles Statechart – object behaviors as reflected through states Activity – flow diagram of classes & interactions Component – analogous to class but for code module Deployment – physical configuration of system nodes

19. Pitfalls of UML  can feel like you’ve accomplished more than design because there are tools and artifacts  need to know when to stop designing  variant of analysis paralysis

20. Symptoms of UML Fever (Bell, Queue, March 2005)Bell  expecting more from UML than it was ever intended to do (performance, fault tolerance)  taking UML to too detailed a level  UML products become most of the milestones  UML syntax discussions dominate design brainstorming sessions  “if it can’t be described in UML, it’s not relevant”  UML designed without user input

21. Back to Use Cases

22. Use Case Diagram  Defines the outside view  Elements  Actors (stick figures): anything outside the system that interacts with it  Use cases (ovals): procedures by which the actor interacts with the system  Solid lines: indicate how actors interact

23. Use Case Extensions  Dotted lines: dependencies between procedures  Includes (subroutine)  Extends (variation)

24. Example of Use Case (customer name)

25. A UML Gallery

26. Class Diagrams Static structure of the system. What interacts, but not what happens.

27. Object Diagrams object diagram: instantiates class diagram

28. Sequence Diagram

29. Collaboration Diagram  Alternative to sequence diagram  Focus on object roles instead of the times that messages are sent

30. Statechart Diagram  Often used in real-time embedded systems  Shows the order in which incoming calls normally occur

31. Activity Diagram General purpose flowchart

32. And… Component Diagram Deployment Diagram