Use Cases UML

Use Cases

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

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

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

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

Documenting Use Cases  Simple text description  UML diagrams

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

UML: Unified Modeling Language A BRIEF DETOUR

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”

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

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

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 (  Version 2.0 completed in 2004

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?

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

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

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

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

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

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

Back to Use Cases

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

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

Example of Use Case (customer name)

A UML Gallery

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

Object Diagrams object diagram: instantiates class diagram

Sequence Diagram

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

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

Activity Diagram General purpose flowchart

And… Component Diagram Deployment Diagram