Modeling with UML (1)

Overview

* What is UML?
First pass quickly

* Use case diagrams

* Class diagrams
* Summary

* (next time....three more diagrams)

What is UML?

* UML (Unified Modeling Language)

Emerging standard for modeling object-oriented systems.
Resulted from the convergence of notations from three
leading object-oriented methods:
OMT (James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)
* Reference: -------
http://www-306.ibm.com/software/rational/uml/
* Supported by several CASE tools, incl. --------------
UML and This Course
* You can model 80% of most problems by using about
20% UML

* You learn those 20%

For the rest, see the official UML definition

* UML is a set of notations, not a single methodology

We will use the textbook methodology

And we’ll use UML to model SE processes (cf. last class)

UML First Pass
* Use case diagrams
Functional behavior of the system as seen by the user.
* Class diagrams
Static structure of the system: Objects, Attributes, and
Associations.
* Sequence diagrams
Dynamic behavior between actors and system objects.
* Statechart diagrams
Dynamic behavior of an individual object as FSM.
* Activity diagrams
Dynamic behavior of a system, in particular the workflow, i.e. a
flowchart.
UML First Pass: Use Case Diagrams

Package
SimpleWatch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

Use case
ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
UML First Pass: Class Diagrams

Class

Multiplicity SimpleWatch Association

1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load() now()
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking() Attributes
referesh()

Operations

Class diagrams represent the structure of the domain or system

UML First Pass: Sequence Diagram
Object

:SimpleWatch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Message
Activation

Sequence diagrams represent the behavior as interactions

 UML First Pass: Statechart Diagrams
Initial state State
Event
button1&2Pressed button2Pressed
Blink Increment
Hours Hours

Transition button1Pressed

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds

Final state
button1&2Pressed
Other UML Notations

UML provides other notations.

* Implementation diagrams
Component diagrams
Deployment diagrams
Introduced in lecture on System Design

* Object Constraint Language (OCL)

Not officially a part of UML, but a standard way to state
logical rules formally
UML Core Conventions

* Rectangles are classes or instances

* Ovals are functions or use cases
* Types are denoted with non-underlined names
SimpleWatch
Firefighter
* Instances are denoted with an underlined names
myWatch:SimpleWatch
Joe:Firefighter
* Diagrams are higraphs
Nodes are entities (e.g. classes, states)
Arcs are relationships among entities (e.g. sender/receiver)
UML Second Pass: Use Case Diagrams

Used during requirements

elicitation to represent external
behavior
* Actors represent roles, (types
Passenger of user of the system) not nec.
people
* Use cases represent standard
mode of use or transaction
* The use case model is the set of
all use cases. It is a complete
description of the functionality
of the system and its
PurchaseTicket environment, but vague
Actors

* An actor models an external entity

which communicates with the system:
User
External system
Physical environment
* An actor has a unique name and an
Passenger optional description.
* Examples:
Passenger: A person in the train
GPS satellite: Provides the system with
GPS coordinates
 Use Case

A use case represents a class of

functionality provided by the
system as an event flow.

A use case consists of:

PurchaseTicket * Unique name
* Participating actors
* Entry conditions
* Flow of events
* Exit conditions
* Special requirements
Use Case Example

Name: Purchase ticket Event flow:

1. Passenger selects the
Participating actor: number of zones to be
Passenger traveled.
2. Distributor displays the
Entry condition: amount due.
* Passenger standing in 3. Passenger inserts money,
front of ticket distributor. of at least the amount due.
* Passenger has sufficient 4. Distributor returns
money to purchase ticket. change.
5. Distributor issues ticket.
Exit condition:
* Passenger has ticket.
Class Diagrams

TariffSchedule Trip
zone:Zone
Enumeration getZones() price:Price
Price getPrice(Zone)
* *

* Class diagrams represent the structure of the system.

* Class diagrams are used
during requirements analysis to model problem domain
during system design to model subsystems and interfaces
during object design to model classes.
Classes
TariffSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TariffSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TariffSchedule

* A class represent a concept.

* A class encapsulates state (attributes) and behavior
(operations).
* Each attribute has a type.
* Each operation has a signature.
* The class name is the only mandatory information.
Instances

tariff_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

* An instance represents a phenomenon.

* The name of an instance is underlined and can contain
the class of the instance.
* The attributes are represented with their values.
Actor vs. Instances

* What is the difference between an actor and a class

and an instance?
* Actor:
An entity outside the system to be modeled, interacting with
the system (“Pilot”)
* Class:
An abstraction modeling an entity in the problem domain,
inside the system to be modeled (“Cockpit”)
* Object:
A specific instance of a class (“Joe, the inspector”).
Associations

TarifSchedule TripLeg
price
Enumeration getZones() * * zone
Price getPrice(Zone)

* Associations denote relationships between classes.

* The multiplicity of an association end denotes how
many objects the source object can legitimately
reference.
1-to-1 and 1-to-Many Associations

Has-capital
Country City
1 1
name:String name:String

1-to-1 association

Polygon 1 * Point
x:Integer
y:Integer
draw()

1-to-many association
Aggregation

* An aggregation is a special case of association

denoting a “consists of” hierarchy.
* The aggregate is the parent class, the components are
the children class.

Exhaust System

1 0..2
Muffler Tailpipe
Composition

* A solid diamond denotes composition, a strong form of

aggregation, where components cannot exist without
the aggregate.

TicketMachine

3
ZoneButton
Generalization

Button

CancelButton ZoneButton

* Generalization relationships denote inheritance

between classes.
* The children classes inherit the attributes and
operations of the parent class.
* Generalization simplifies the model by eliminating
redundancy.
From Problem Statement to Code
Problem Statement
A stock exchange lists many companies. Each company is
identified by a ticker symbol

Class Diagram
lists
StockExchange * * Company
tickerSymbol

Java Code
public class StockExchange {
public Vector m_Company = new Vector();
};
public class Company {
public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();
};
Summary

* UML provides a wide variety of notations for

representing many aspects of software development
Powerful, but complex language
Can be misused to generate unreadable models
Can be misunderstood when using too many exotic features

* We concentrate on a few notations:

Functional model: use case diagram
Object model: class diagram

Next time:
Dynamic model: sequence diagrams, statechart and
activity diagrams