Fast Forward to Use Case Diagrams

What is Software Engineering?
What is a software process?
What are requirements elicitation, specification and analysis?
What is a use case?
What is UML?
What is a use case diagram?

Use the space bar or right arrow for next slide,
left arrow to back up. Use 'a' key to toggle between single page and slide modes.

What is Software Engineering?

The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. [Classic Definition 1969]

(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1). [IEEE 1993]

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. [Wikipedia 2010]

What is a process?

Defines who does what, and when to do it, to reach a certain goal
There are many competing software development processes
Each is based on a lifecycle model

Traditional Waterfall Lifecycle Model

Divides activities into a sequence of phases
Evolved into more workable models, with increments and feedback
Basic classification of activites is still valid

Diagram reproduced from http://en.wikipedia.org/Waterfall_model.

Requirements/Analysis

Elicitation - from the user/customer
Analysis - understanding, developing a model
Specification - getting it down in writing

Importance of Requirements

The first step in software development process
The most critical - errors here have the biggest impact (Why?)
Arguably the most difficult (Why?)

Swing cartoon from www.dons.net.au. One of several variations on this theme that are widely reproduced. Original artist unknown.

Analysis versus Design

Analysis
- investigate the problem and requirements
- find and describe the objects (or concepts) in the problem domain
- build a model of the application domain (the problem)
Design
- find a conceptual solution
- define the software objects and how they collaborate
- build a model of the software system (the solution)

Object-Oriented Analysis and Design frames the definitions and models in terms of objects

A modeling language provides notations for describing abstract views of software applications domains and software systems, at various levels of abstraction.

Similar-looking modeling techniques may be applied in both phases, but the goals are different -- to modeling the problem versus modeling the solution.

What is a use case?

An requirements analysis concept
A case of a use of the system/product
Describes the system's actions from a the point of view of a user
Tells a story
- A sequence of events involving
- Interactions of a user with the system
Specifies one aspect of the behavior of a system,
without specifying the structure of the system
Is oriented toward satisfying a user's goal

Use cases are not exclusively a feature of object oriented analysis and design; they are applicable to non-OO methods as well as OO. However, they plan an important role in all phases of the UP, starting with requirements analysis.

How do we describe use cases?

Textual or tabular descriptions
User stories
Diagrams

Use Case Descriptions

actors - something with a behavior or role, e.g., a person, another system, organization.
scenario - a specific sequence of actions and interactions between actors and the system, a.k.a. a use case instance
use case - a collection of related success and failure scenarios, describing actors using the system to support a goal.

Key question: "How can using the system provide observable value to the user, or fulfill their goals"?

What is an Actor?

Include all user roles that interact with the system
Include system components only if they responsible for initiating/triggering a use case.
For example, a timer that triggers sending of an e-mail reminder
primary - a user whose goals are fulfilled by the system
importance: define user goals
supporting - provides a service (e.g., info) to the system
importance: clarify external interfaces and protocols
offstage - has an interest in the behavior but is not primary or supporting, e.g., government
importance: ensure all interests (even subtle) are identified and satisfied

What is a user story?

An abbreviated description of a use case
Used in agile development

Answers 3 questions:

Who?
Does what?
And why?

As a <type of user>,
I want <some behavior from the system>
so that <some value is achieved>

Use Case Diagrams

A a picture
- describes how actors relate to use cases
- and use cases relate to one another
Diagrams are not essential
They are helpful in giving an overview, but only secondary in importance to the textual description
They do not capture the full information of the actual use cases
In contrast, text is essential

Larman says only novices and academics are preoccupied with diagrams and relationships, but they are fun and can be very helpful for visually oriented people.

Example Use-Case Diagram

A standard form of use case diagram is defined in the Unified Modeling Language.

Diagram reproduced from http://www.cc.gatech.edu/classes/AY2004/cs2335_summer/umlex/UseCaseDiagram1.jpg.

What is UML?

Unified Modeling Language
Graphical notation for communicating requirements and design
Combination of notations of "three amigos", and others
- Grady Booch's "Booch Method"
- Jim Rumbaugh's "Object Modeling Technique" (OMT)
- Ivar Jacobson'se "Objectory Method"
Standards maintained by www.omg.org (OMG)

The UML and the UP (Unified Process) both contain the word "unified" but are distinct. The UP happens to make use of UML, the UP comprises many other elements. Moreover, UML and the UP have distinct histories.

UML UCD Elements

The symbol for an actor is
The symbol for a use case is

Relation Lines in Use Case Diagrams

Association relationships
Generalization relationships
One element (child) "is based on" another element (parent)
Include relationships
One use case (base) includes the functionality of another (inclusion case)
Supports re-use of functionality
Extend relationships
One use case (extension) extends the behavior of another (base)

In various UML diagrams, including use case diagrams, there are several kinds of lines used to show relationships. These are the ones that can be included in use case diagrams.

It seems, from examples published on the Web, that there is some variation in the conventions for usage of these lines and annotations. The conventions shown here come from the Rational/IBM documentation.

Example Larger Use-Case Diagram

How do use case diagrams fit in?

This applies also to use case descriptions.

Diagram reproduced from www.edrawsoft.com.