When to use UML

• When you need to clarify something through diagrams!
  • Typically used with bigger development groups, or when two separate groups' code need to interact
• Don't write UML diagrams just for the sake of writing UML diagrams...

UML diagrams diagram (!)

(Object diagrams are now Domain model diagrams)

UML diagram types

Sources

• A few diagram images are from Wikipedia (or Wikicommons)
• Most are from http://www.uml-diagrams.org/
  • These images are not part of the repo, as their licenses do not provide for that
  • So this slide set just deep links to those imags
  • That site has a lot of information, far beyond what is in this lecture set
• In all cases, the title is the hyperlink to the source page, to allow for the image to be the largest size possible

Class diagram

Component diagram

Composite structure diagram

Deployment diagram

Domain model diagram

Package diagram

Activity diagram

Use case diagram

State diagram

Sequence diagram

Interaction overview diagram

Timing diagram

User stories

a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function

• from Wikipedia

Use cases

• Just a prose (i.e. English) explanation of what's happening
  • Play a dice game: player requests to roll the dice. System presents results: if the dice face value totals seven, player wins; otherwise, player looses.
• Three types:
  • Brief: one-paragraph summary (like the one 2 slides ago) that covers the 'happy path'
    • This is like a user story
  • Casual: multiple-paragraph format that covers multiple scenarios
  • Fully dressed: highly detailed

Fully dressed use case

Alistair Cockburn describes the following fields:

I have a 4-page example. Want to see it?

UML for use cases

• Use cases are primarily text!
• However, you may often see a diagram that shows how the use cases interact
  • The use case diagram from earlier in this slide set (and repeated next slide) is such an example

Use case diagram

Actors

• Some 'thing' with a behavior
  • A person, computer system, organization, etc.
• Three types
  • Primary actor
  • Supporting actor
  • Offstage actor

Use case writing guidelines

• Write in an essential UI-free style
• Write terse use cases
• Write black-box use cases
• Take an actor and actor-goal perspective
• Finding use cases

Use cases: the big picture

• The waterfall method defines all the use cases up front
• Agile development methods define them over time
  • And they are refined iteratively

Buzzword alert: artifacts

• An 'artifact' (as far as the Unified Process is concerned) is a document that defines some aspect of the development
  • Wikipedia defines them as the "tangible by-products produced during the development of software"
• Examples: Vision, Business Case, Use-Case Model, Supplementary Specification, Glossary, Business Rules, Risk List, Risk Management Plan, Prototypes, Iteration Plan, Phase Plan, Software Development Plan, Development Case, etc.

Vision

Sections of a vision statement:

• Introduction and product description
• Positioning
  • Business opportunity
  • Problem statement
  • Product position statement
• Stakeholder descriptions
• Product overview
• Summary of system features
• Other requirements and constraints

Supplementary Specification

This includes anything specifications not covered in a use case. Possible sections:

Glossary

• Includes (among other things):
  • Definitions
  • A data dictionary: Metadata
• And, not surprisingly, it evolves over time...

Domain (business) rules

• These rules dictate how a domain (or business) may operate
  • Such as laws, regulations, policies, etc.
• Example: a cashier system will need to know how sales tax is calculated, and on what times (i.e., not food)

What's Missing?

• Only a few critical things...
• User manual
• Installation manual
• Licensing document
• Guide to the code for future developers & maintainers

When to use all of this

• Here, "this" means either UML diagrams or documentation
• Some companies write a lot of documentation
  • These tend to be more waterfall-based development shops
  • Sometimes with good reasoan, but not always
• My philosophy is you only use it when you need it to clarify something
  • That doesn't mean you avoid it at all costs!