Chapter 3

The Unified Modeling Language

 Requirements Process Phase Affected by This Chapter
Analysis
Design
FrameworkArchitectureDetailed Design

Implementation

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Classes at Detailed Design

wafer

canister Canister Class name

+ numCanisters: int
- numWafers: int Attribute: type
+:Visible - size: float
from without + display()
- getNumOpenSlots() Operations
+ setStatus()
Responsibilities:
-- describes each Place for
canister undergoing comments
fabrication

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Key Concept:  Representing a Class in UML
UML represents a class with a rectangle
containing the class name. We display
additional information within the
rectangle as needed: Variables,
methods, etc.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 UML Notation … and … Typical Implementation

package of classes
MyPackage
package MyPackage;
abstract class MyAbstractClass . . . .
abstract class
MyAbstractClass package MyPackage;
class MyDerivedClass extends MyAbstractClass
{
inheritance int att;
.....
void myFunction( ReferencedClass r )
{ . .. }
}
MyDerivedClass
att: int attribute
myFunction() operation

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Interfaces
UML Notation …… Typical Java Implementation

interface MyInterface . . . .
interface
MyInterface
myMethod() class MyClass implements MyInterface
{
.....
realization }

MyClass
myMethod()

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept:  Representing Inheritance in UML
UML represents inheritance and interface
realization with an open triangle.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Aggregation : UML Notation and Typical Implementation

MyClass aggregation
att: int ac 1 MyAggregatedClass
myFunction()

class MyClass
{
MyAggregatedClass ac;
int att;
.....
}

Composed object exists only in

composition
ac the scope of owner object
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept:  Representing Aggregation in UML
Class A aggregates class B if A objects
require B objects in a structural sense –
typically with an instance variable. UML
symbol is an open diamond.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Dependence : UML Notation … and …Typical Implementation

MyDependentClass
att: int MyReferencedClass
myFunction()
dependence
class MyDependentClass (reference to a class)
{
.....
void myFunction1( MyReferencedClass r )
{ . .. }
parameter
MyReferencedClass myFunction2( … )
{ . .. }
or return type
void myFunction3( … )
{ MyReferencedClass m …
}
or local variable type
}

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept:  Representing Dependency 
Class A depends on class B if A
objects require B objects for their
definition. In practice, this means that
B appears in at least one method of A.
UML representation: a dotted arrow.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Association : UML Notation and Typical Implementation

1..3 employs 1..n

Employer Employee
is employed by

class Employer
{
Employee[ ] employees;
.....
}

class Employee
{
Employer[ ] employers;
.....
}

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Customer Mail Application
CustomerMailApplication
generateMail() customer 1 Customer
getCustomerTypeFromUser() createMail()
main()

DelinquentCustomer MountainCustomer RegularCustomer

createMail() createMail() createMail()

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Key Concept:  Use Cases
-- a sequence of actions
taken by an application
and its user. The user
takes one role.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 1. Actor hits any key.
Use Cases For Video Store Application
2. Application displays
Activate main menu. …

1. . . . .
Check in Precondition:
Application has been
activated
clerk 1. Actor clicks “check
Check out
out.”
2. Actor swipes bar
code.
Add video 3. Application prompts
for rental duration.
4. Actor enters duration.
5. Application stores
.........
stocker 1. record.…
6. Application
Adapted from Software Design: From Programming to Architecture by Eric J. Braudeprints
(Wiley 2003), with permission.

customer’s account
 Use Case
Generalization & A. Application displays main options
Usage B. User selects icon

Perform warehouse
Warehou transaction
se
worker «uses»

ControlApplication «extends»

Modify Stock

(i). Application displays

Dispatcher
logo A. Application displays main
(ii). “Perform options
warehouse 1. User moves cursor to stock
Transaction” use case. icon
(iii) Application B. User selects icon
2. Application
Adapted from Software Design: From Programming
displays farewell displays
to Architecture by Eric J. Braude (Wiley 2003), stock
with permission.
 Beginning of Sequence Diagram for Check Out Use
Case
Note 1

Clerk :MainScreen:BarCodeReader:CheckoutOptionDisplay

doCheckout() Note 0

order
:Checkout
read()
Note 2
} Step 2 of use case

use case{
Step 3 of initiate()

Note 3
show()

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Beginning of Sequence Diagram for Check Out Use
Case
User :MainScreen:BarCodeReader :CheckoutOptionDisplay
doCheckout()

:Checkout :Account
1. read()
2.1 initiate()
2.2 create()
2.3 show()

3. setDuration()

Use case: 4. store()

1. User swipes bar code
2. Application prompts for rental 5. print()
duration
3. User enters duration
4. Application stores record
5. Application prints customer’s account
status Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Building a Sequence Diagram 1
1. Identify the use case whose sequence
diagram you will build (if applicable).
2. Identify which entity initiates the use
case
the user, or
an object of a class
name the class
name the object
myObject
3. Draw a rectangle to represent
:MyClass
this object at left top
use UML object:Class notation
4. Draw an elongated rectangle beneath
this to represent the execution
of an operation
5. Draw an arrow pointing right from its top
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Building a Sequence Diagram 2

6. Identify which entity handles myObject myObject1

the operation initiated :MyClass :MyClass1
an object of a class
name the class operation()
name the object
7. Label the arrow with the
name of the operation
8. Show a process beginning,
using an elongated rectangle
9…… Continue with each new
statement of the use case.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept:  Sequence Diagrams
A sequence diagram shows the
order in which methods of various
objects execute.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 States for OnlineShopper Class

Browsing ItemsChosen

CheckingOut
Incomplete

CreditUnderValidation

CreditDenied Complete

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 [credit card
Conditions on
data Events
incomplete]

[credit
Incomplete Hit
Submit card data CreditUnderValidation
button complete]

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 State/Transition Diagram for OnlineShopper Class

select
put back item
last item
[credit
Browsing select ItemsChosen card data
item incomplet
Hit checkout button e]

CheckingOut hit
Incomplete Submit
hit
Qui button
t
[credit
hit card data
OK CreditUnderValidation
complete
denial ]
received validatio hit OK
n
CreditDenied received
Complete

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Key Concept:  State Diagrams 
Some applications or parts thereof
are conveniently thought of as
being in one of several possible
states. UML state diagrams help
us visualize these, and the events
that cause transitions among
them.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Do Something
Activity Chart
Notation
Do Something More

[condition true] else

Do A Task Do Another Task

} In
parallel

Do Even More

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 A Class Model for Chaining

static factList static ruleBase

Fact 1 consequent Rule

content addRule()
addFact() 1..n antecedents proveAntecedents()
proveBack() forwardChain()

Set Fact.factList to the known facts

and a Rule.ruleBase to the known rules.
Create Fact object soughtFact
Execute soughtFact.proveBack( ruleBase );
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Flowchart for soughtFact.proveBack()

Fact Rule
else

soughtFa
ct
in
factList Another rule R exists
with soughtFact as its else
consequent

Apply
Report FALSE
R.proveAntecedents()*

proof else
succeeded
* Prove that every
Report TRUE antecedent fact is
true
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Specifications for Figure Drawing

 Facilitate drawing
stick figures
 Drag to vicinity to
auto-complete
 Feet can be
rectangles or
ellipses
(Rest to be 
Releasing dragged figure anywhere in
specified)
this area causes it to appear in position
at end Adapted
of left leg Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
from Software
Bad Attempt: “A Foot is Either an Ellipse or a Rectangle”

Ellipse Rectangle

Foot

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Better Attempt: “A Foot is Either an Ellipse or a Rectangle”

Ellipse Foot Rectangle

EllipseFoot RectangleFoot

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Another Attempt: “A Foot is Either an Ellipse or a Rectangle”

Foot FootShape

Ellipse Rectangle

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Best Attempt So Far: “A Foot is Either an Ellipse or a
Rectangle”

FootShape
Foot
drawAsEllipse()
draw()
drawAsRectangle()

Ellipse Rectangle
draw() draw()

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Class Model Showing All Dependencies

Area
GeometricFigure
releaseCursor()
Leg

FootShape
Foot
drawAsEllipse()
draw()
drawAsRectangle()

Ellipse Rectangle
Position
draw() draw()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Sequence Diagram for Figure Drawing Application

:Area :Foot :FootShape :Ellipse

releaseCursor
( GeometricFigure
draw
aGeometricFigure )
( Leg aLeg, drawAsEllipse*
aGeometricFigure )
( Position aPosition )
draw( aPosition )

* or drawAsRectangle() …

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Use Cases
Actor / application
interactions
 Sequence Diagrams
UML Models
Objects
Sequence of methods
 calling methods among
objects
 Class Models
 Activity Diagrams
Flow of control
 State Diagrams
States
Transitions among states
 caused by events
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
 Relationships Between Classes

 Dependency
member method mentions
another class
 Association
structural
e.g., sale / receipt
Aggregation
 common kind of association
 e.g. airplane / wing
 one-way
 “has-a”
 Inheritance
“is-a”
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.