Chapter 2 UML Overview

 Building blocks of the UML

 Structure things in the UML
 Behavioral things in the UML
 Grouping things in the UML
 Relationships in the UML
 Diagrams in the UML
 Extension mechanism of the UML
 Simple Example - Hello World

Object Oriented Analysis and Design 1

 Building Blocks of the UML

Object Oriented Analysis and Design 2

Building Blocks of the UML
 The vocabulary of the UML encompasses
three kinds of building blocks:
 Things: the abstractions that are first-class
citizens in a model;
 Relationships: relationships tie these things
together;
 Diagrams: diagrams group interesting
collections of things.

Object Oriented Analysis and Design 3

Things in the UML
 There are four kinds of things in the UML:
 Structural things: class, interface, collaboration,
use case, active class, component, artifact &
node
 Behavioral things: interaction, state machine,
activity
 Grouping things: package
 Annotational things: note
 These things are the basic object-oriented
building blocks of the UML.

Object Oriented Analysis and Design 4

 Structural things in the UML

Object Oriented Analysis and Design 5

Structural things in the UML
 the nouns of UML models.
 the mostly static parts of a model, either
conceptual or physical
 Collectively, the structural things are called
classifiers
 eight kinds:
 Logic view: class, interface, collaboration,
 Requirement view: use case
 Process view: active class
 Implementation view: component, artifact, node

Object Oriented Analysis and Design 6

Structural things - Class
 A class is a description of a set of objects
that share the same attributes, operations,
relationships, and semantics.
 A class is represented using a
compartmented rectangle
Professor
- name
- employeeID : UniqueId
Objects Attributes
- hireDate
- status
- discipline
- maxLoad
Professor Smith
+ submitFinalGrade()
+ acceptCourseOffering()
Professor Mellon + setMaxLoad()
+ takeSabbatical()
Operations
Professor Jones
Object Oriented Analysis and Design 7
Review: Class Compartments
 A class is comprised of three sections
 The first section contains the class name
 The second section shows the structure
(attributes)
 The third section shows the behavior
(operations)

Class Name Professor

name
Attributes empID
Operations create( )
save( )
delete( )
change( )

Object Oriented Analysis and Design 8

Review: Representing Objects
 An object is represented as rectangles with
underlined names

: Professor

ProfessorClark a + b = 10
Class Name Only

Professor Clark
ProfessorClark :
Professor Object Name Only

Class and Object Name

Object Oriented Analysis and Design 9

Structural things - Interface
 An interface is a collection of operations
that specify a service of a class or
component.
 Interfaces support “plug-and-play”
architectures Tube
<<interface>>
Shape
Pyramid
Draw
Move
Scale
Rotate Cube

Realization relationship
Object Oriented Analysis and Design 10
Review: Interface Representations
Tube
Elided/Iconic
Representation
(“lollipop”) Pyramid

Shape Cube

Canonical Tube
<<interface>>
(Class/Stereotype) Shape
Representation
Draw Pyramid
Move
Scale
Rotate Cube

Object Oriented Analysis and Design 11

Structural things - Collaboration
 In the context of a system's architecture, a
collaboration allows you to name a conceptual
chunk that encompasses both static and
dynamic aspects.
 A collaboration names a society of classes,
interfaces, and other elements that work
together to provide some cooperative behavior
that's bigger than the sum of all its parts.
 You use collaborations to specify the
realization of use cases and operations, and to
model the architecturally significant
mechanisms of your system.
Object Oriented Analysis and Design 12
Structural things - Collaboration
 A collaboration is a society of classes, interfaces,
and other elements that work together to provide
some cooperative behavior that's bigger than the
sum of all its parts.
 A collaboration is also the specification of how an
element, such as a classifier (including a class,
interface,component, node, or use case) or an
operation, is realized by a set of classifiers and
associations playing specific roles used in a specific
way.
 Graphically, a collaboration is rendered as an ellipse
with dashed lines.

Login Login

Object Oriented Analysis and Design 13

Structural things – Use Case
 a use case is a description of set of sequence of
actions that a system performs that yields an
observable result of value to a particular actor.
 A use case is used to structure the behavioral things
in a model.
 A use case is realized by a collaboration.
 Graphically, a use case is rendered as an ellipse with
solid lines, usually including only its name.

Login Login

Object Oriented Analysis and Design 14

Structural things – Active Class
 an active class is a class whose objects own one or
more processes or threads and therefore can initiate
control activity.
 An active class is just like a class except that its
objects represent elements whose behavior is
concurrent with other elements.
 Graphically, an active class is rendered as a class
with double lines on the left and right; it usually
includes its name, attributes, and operations.
EventManager

suspend()
flush()

Object Oriented Analysis and Design 15

Structural things – Component
 A component is a modular physical part of the
system design that hides its implementation
behind a set of external interfaces.
 The implementation of a component can be
expressed by wiring together parts and
connectors.
 Graphically, a component is rendered like a
class with a special icon in the upper right
corner.

Orderform
Object Oriented Analysis and Design 16
Structural things – Artifact
 An artifact is a physical and replaceable part
of a system that contains physical information
("bits").
 An artifact typically represents the physical
packaging of source or run-time information.
 Graphically, an artifact is rendered as a
rectangle with the keyword «artifact» above
the name.

<<artifact>>

Login.dll

Object Oriented Analysis and Design 17

Structural things – Node
 a node is a physical element that exists at run time
and represents a computational resource, generally
having at least some memory and, often, processing
capability.
 A set of components may reside on a node and may
also migrate from node to node.
 Graphically, a node is rendered as a cube, usually
including only its name.

<<Node>>
Node #1

Object Oriented Analysis and Design 18

 Behavioral things in the UML

Object Oriented Analysis and Design 19

Behavioral things in the UML
 the verbs of UML models.
 the mostly dynamic parts of a model
 three primary kinds:
 Among a set of objects: interaction
 For an object: state machine
 The sequence of steps: activity

Object Oriented Analysis and Design 20

Behavioral things - Interaction
 an interaction is a behavior that comprises a set of
messages exchanged among a set of objects
within a particular context to accomplish a specific
purpose.
 The behavior of a society of objects or of an
individual operation may be specified with an
interaction.
 An interaction involves a number of other elements,
including messages, action sequences (the
behavior invoked by a message), and links (the
connection between objects).
 Graphically, a message is rendered as a directed
line, almost always including the name of its
operation. display()

Object Oriented Analysis and Design 21

What Is an Interaction Diagram?
 An interaction diagram shows an interaction,
consisting of a set of objects and their
relationships, including the messages that
may be dispatched among them.
 It models the dynamic aspects of a system.

Sequence Diagrams Collaboration Diagrams

Object Oriented Analysis and Design 22

What Is a Sequence Diagram?
 A sequence diagram is an interaction
diagram that emphasizes the time ordering
of messages.
 The diagram shows
 The objects participating in the interaction.
 The sequence of messages exchanged.

Sequence Diagrams

Object Oriented Analysis and Design 23

What Is a Communication Diagram?
 A communication diagram emphasizes the
organization of the objects that participate in
an interaction.
 The communication diagram shows
 The objects participating in the interaction.
 Links between the objects.
 Messages passed between the objects.

Communication Diagrams
Object Oriented Analysis and Design 24
Interaction Diagram Example - HelloWorldApp2.java
public class HelloWorldApp2 {
public static void main(String[] args) {
Greeting hello = new Greeting(); client hello : Greeting
hello.greet("Hello World");
} greet(String)
}
class Greeting {
public void greet(String s) {
System.out.println(s);
}
}

1: greet(String)
client hello : Greeting

Object Oriented Analysis and Design 25

Behavioral things - State machine
 a state machine is a behavior that specifies the
sequences of states an object or an interaction
goes through during its lifetime in response to
events, together with its responses to those events.
 The behavior of an individual class or a
collaboration of classes may be specified with a
state machine.
 A state machine involves a number of other
elements, including states, transitions, events, and
activities.
 Graphically, a state is rendered as a rounded
rectangle, usually including its name and its
substates, if any.
waiting

Object Oriented Analysis and Design 26

Behavioral things - Activity
 an activity is a behavior that specifies the
sequence of steps a computational process
performs
 In an activity, the focus is on the flows among
steps without regard to which object
performs each step.
 A step of an activity is called an action.
 Graphically, an action is rendered as a rounded
rectangle with a name indicating its purpose. States
and actions are distinguished by their different
contexts.

waiting

Object Oriented Analysis and Design 27

 Grouping things in the UML

Object Oriented Analysis and Design 28

Grouping things in the UML
 A package is a general-purpose mechanism for
organizing elements into groups.
 In all, there is one primary kind of grouping thing,
namely, packages.
 Packages are the basic grouping things with which
you may organize a UML model. There are also
variations, such as frameworks, models, and
subsystems (kinds of packages)

Bus ines s rules

Object Oriented Analysis and Design 29

Grouping things - Package
 Grouping things are the organizational parts of UML
models.
 Structural things, behavioral things, and even other
grouping things may be placed in a package.
 Unlike components (which exist at run time), a
package is purely conceptual (meaning that it exists
only at development time).
 Graphically, a package is rendered as a tabbed
folder, usually including only its name and,
sometimes, its contents.
A B
(from (from PackageA PackageB
packageA) packageB)
Dependency relationship
Object Oriented Analysis and Design 30
Annotational things - Note
 Annotational things are the explanatory parts of UML models.
 These are the comments you may apply to describe,
illuminate, and remark about any element in a model.
 There is one primary kind of annotational thing, called a note.
 A note is simply a symbol for rendering constraints and
comments attached to an element or a collection of elements.
 Graphically, a note is rendered as a rectangle with a dog-
eared corner, together with a textual or graphical comment.

One of these is
executed:

Object Oriented Analysis and Design 31

 Relationships in the UML

Object Oriented Analysis and Design 32

Relationships in the UML
 There are four kinds of relationships in the
UML:
 Association
 Dependency
 Generalization
 Realization
Window <<Interface>>
+ open() : void AbstractWindow
+ close() : void + open() : void
+ handleEvent(e: Event) : void + close() : void

Event

ConsoleWindow DialogBox Control

Object Oriented Analysis and Design 33

What Is an Association?
 The semantic relationship between two
or more classes that specifies
connections among their instances
 A structural relationship, specifying that objects of
one thing are connected to objects of another

<<entity>> <<entity>> <<entity>>

Student Schedule Course

Association
Role Names
Name
Professor Works for University
Employee Employer
Association
Object Oriented Analysis and Design 34
What Is an Association? – A example
class CatalogueEntry {
private string name; CatalogueEntry screw= new
CatalogueEntry
private int number; (“screw”, 28834, 0.02);
private double cost;
public double getCost () { Part screw1 = new Part(screw) ;

return cost;
screw1.cost();
}
}
class Part {
private CatalogueEntry
entry;
public double cost () {
return entry.getCost();
}
}
Object Oriented Analysis and Design 35
What Is an Association? – A example
 An association is a structual relationship that desribes a set of
links.
 a link being a connection among objects.

: CatalogueEntry
Describes Describes
: Part name = “screw” : Part
number = 28834
Fig. Links between objects cost = 0.02
 A link specifies a path along which one object can dispatch a
message to another (or the same)object.

: CatalogueEntry

Client
cost() : Part
getCost()
name = “screw”
number = 28834
cost = 0.02
Fig. Finding the cost of a Part

Object Oriented Analysis and Design 36

What Is an Association? – A example
 In general, a link is an instance of an
association.

CatalogueEntry
- name Part
- number
- cost
+ cost() * 1 + getCost()

Fig. Example of an association

Object Oriented Analysis and Design 37

Example : Associations mapping to VB

‘ Schedule.cls
Schedule
Public theStudent as Student
1

1 ‘ Student.cls

Student Public theSchedule as Schedule

Object Oriented Analysis and Design 38

Adornments that apply to associations.
 An association name: to describe the nature of the
relationship.
 When a class participates in an association, it has a specific
role that it plays in that relationship. A role is just the face the
class at the near end of the association presents to the class at
the other end of the association.

Association
Name
nn job nn
Person Company
-employee -employer

Role Names

Object Oriented Analysis and Design 39

Adornments that apply to associations.
 The multiplicity of an association's role: to state how many
objects may be connected across an instance of an
association.
 Navigation: Given a plain, unadorned association between two
classes, it's possible to navigate from objects of one kind to
objects of the other kind.
 Unspecified
 Exactly one
1
 Zero or more (many,
0..* Multiplicity
unlimited)
 One or more *
University Professor
 Zero or one 1..* 1 0..*
 Specified range 0..1
 Multiple, disjoint 2..4
ranges 2, 4..6 Navigation

Object Oriented Analysis and Design 40

Association - Aggregation
 A special form of association that models a
whole-part relationship between an
aggregate (the whole) and its parts

Whole Part

Student Schedule

Aggregation

Object Oriented Analysis and Design 41

Association - Composition
 A form of aggregation with strong ownership
and coincident lifetimes
 The parts cannot survive the whole/aggregate

Whole Part

Student Schedule

Composition

Object Oriented Analysis and Design 42

Association - Association Class
 In an association between two classes, the
association itself might have properties.
 A class “attached” to an association
 Contains properties of a relationship
 One instance per link

Company 1..* Person

*
-employer -employee

Job
-salary
+ getSalary()
Object Oriented Analysis and Design 43
Association - Association Class
Company 1..* Person
*
-employer -employee

Job
-salary
+ getSalary()

Design Decisions

Company 1 1..* Job Person

* 1
-salary
+ getSalary()

Object Oriented Analysis and Design 44

Association - Recursive association

prerequisites
0..*

Course

Object Oriented Analysis and Design 45

Association - Example

has 0..1
School Department
1 1..n 1..n
1..n 1..n

assignedTo
member
-chairperson
n 1..n 1..n 0..1
Student attends Course teaches Instructor
n n n 1..n

Object Oriented Analysis and Design 46

Relationships: Dependency
 A relationship between two model elements
where a change in one may cause a
change in the other
 Non-structural, “using” relationship

Client Supplier Componen

Class
t

Package Client Supplier

Dependency
relationship

ClientPackage SupplierPackage
Dependency
relationship

Object Oriented Analysis and Design 47

Dependency – Example

Professor Course

class Professor {
public void teach(Course c) { ……..}
……………..
}

class Professor {
public void teach() { Course c = new Course(); ……..}
……………..
}

Object Oriented Analysis and Design 48

Example: HelloWorld.java
import java.applet.Applet;
import java.awt.Graphics;

public class HelloWorld extends Applet {

public void paint(Graphics g) {
g.drawString("Hello World!", 50, 25);
}
}
Applet
Dependency relationship

Graphics HelloWorld

paint()
Object Oriented Analysis and Design 49
Relationships: Generalization
 A relationship among classes where one
class shares the structure and/or behavior
of one or more classes
 Defines a hierarchy of abstractions in which
a subclass inherits from one or more
superclasses
Generalization
 Single inheritance relationship
 Multiple inheritance Employee
 an “is-a-kind of” relationship

Engineer Manager
Object Oriented Analysis and Design 50
Generalization - Example
• Employee is a generalization of Engineers and
Managers.
• Engineer is a specialization of Employee.
• Manager is a kind of Employee.
• Engineers and Managers inherit the Employee interface
(and in this case, some implementation too).
class Employee {…...};
class Manager : public Employee {..};
class Engineer : public Employee {…};.
class Employee {…...}
class Manager extends Employee {..}
class Engineer extends Employee {…}
Object Oriented Analysis and Design 51
Example: HelloWorld.java
import java.applet.Applet;
import java.awt.Graphics;

public class HelloWorld extends Applet {

public void paint(Graphics g) {
g.drawString("Hello World!", 50, 25);
}
}
Applet
Generalization relationship

Graphics HelloWorld

paint()
Object Oriented Analysis and Design 52
Example: Single Inheritance
 One class inherits from another
Ancestor

Account
balance
name
Superclass number
(parent) Withdraw()
CreateStatement()
Generalizatio
n Relationship

Checking Savings

Subclasses Withdraw() GetInterest()

Withdraw()

Descendents

Object Oriented Analysis and Design 53

Example: Multiple Inheritance
 A class can inherit from several other
classes

FlyingThing Animal

multiple
inheritance

Airplane Helicopter Bird Wolf Horse

Use multiple inheritance only when needed, and always with caution !

Object Oriented Analysis and Design 54

What Gets Inherited?
 A subclass inherits its parent’s attributes,
operations, and relationships
 A subclass may:
 Add additional attributes, operations,
relationships
 Redefine inherited operations (use caution!)
 Common attributes, operations, and/or
relationships are shown at the highest
applicable level in the hierarchy
Inheritance leverages the similarities among classes

Object Oriented Analysis and Design 55

Example: What Gets Inherited

GroundVehicle
owner Person
Superclass weight
(parent) licenseNumber 0..* 1

register( )
generalization

Car Truck Trailer

Subclass size tonnage
getTax( )

Object Oriented Analysis and Design 56

Relationships: Realization
 One classifier serves as the contract that
the other classifier agrees to carry out
Realization relationship

Tube
Tube
<<Interface>>
Shape
Pyramid
Pyramid
draw()
Shape move()
scale()
Cube
rotate() Cube

Elided/Iconic
Representation Canonical
(“lollipop”) (Class/Stereotype)
Representation

Object Oriented Analysis and Design 57

Realization - Example

Circle

Shape

interface Shape { class Shape {

public void draw() ; public:
} virtual void draw() = 0 ;
};
class Circle implements Shape { class Circle : public Shape {
public void draw() {…..} public:
……
void draw() {…..}
}
……
};

Object Oriented Analysis and Design 58

 Diagrams in the UML

Object Oriented Analysis and Design 59

Diagrams in the UML 1.x
 The UML1.x includes nine such diagrams:
 Ö Class diagrams: to illustrate logical structure.
 Object diagrams: to illustrate objects and links.
 State diagrams: to illustrate behavior.
 Component diagrams: to illustrate physical structure of
the software.
 Deployment diagrams: to show the mapping of software
to hardware configurations.
 Interaction diagrams (i.e., collaboration and sequence
diagrams): to illustrate behavior.
 Activity diagrams: to illustrate the flow of events in a use-
Ö case.

Object Oriented Analysis and Design 60

A diagram is a view into a model
A model is a complete
description of a system
from a particular State
State
State
State
Diagrams
Class
perspective Diagrams
Class
Diagrams
Diagrams
Diagrams
Diagrams State
State
use-case
use-case State
State
Diagrams
Diagrams Object
Diagrams
Object
Diagrams
Activity
Activity Diagrams Diagrams
Diagrams
Diagrams Diagrams
Diagrams

Scenario
Scenario State
State
Scenario
Scenario
Diagrams State
State
Diagrams
Sequence
Diagrams
Sequence
Diagrams State
Diagrams
State
Diagrams
Diagrams
Diagrams Models Diagrams
Diagrams
Diagrams Diagrams

Scenario
Scenario
Component
Component
Scenario
Scenario
Diagrams
Component
Diagrams
Component
Component
Diagrams
Collaboration
Diagrams
Collaboration
Diagrams Deployment
Deployment Component
Diagrams
Diagrams
Diagrams
Diagrams Diagrams Diagrams
Diagrams
Diagrams Diagrams

Object Oriented Analysis and Design 61

Diagrams in the UML1.x
Modeling Requirements
Use Case diagram - organizing and modeling the behaviors of a system.

Modeling Structure: Logic View

Class diagram - shows a set of classes, interfaces, and collaborations and their
relationships.
Component diagram - shows the organizations and dependencies among a set of Physical View
components.
Deployment diagram - shows a set of nodes and their relationships.

Modeling Behavior Projection of

Interaction
Sequence diagram - emphasizes the time ordering of messages.
Collaboration diagram - emphasizes the organization of the objects that participate in
an interaction.

Statechart diagram - emphasizes the event-ordered behavior of an object.

Activity diagram- emphasizes the flow of control among objects.
Projection of
state machine

Object Oriented Analysis and Design 62

Diagrams in the UML 2.0
 The UML2.0 includes thirteen diagrams:
 Class diagram
 Object diagrams
 Component diagrams
 Composite structure diagram
 State diagram
 Deployment diagram
 Interaction diagrams
• communication and sequence diagrams)
 Activity diagram.
 Package diagram
 Timing diagram
 Interaction overview diagram
Object Oriented Analysis and Design 63
Diagrams in the UML 2.0

Object Oriented Analysis and Design 64

Diagrams - Class Diagram
 Class diagram shows a set of classes, interfaces,
and collaborations and their relationships

Object Oriented Analysis and Design 65

Diagrams - Class Diagram
 Class diagrams contain:
 Classes, interfaces, collaborations.
 Dependency, generalization, and association relationships
 Captures the vocabulary of a system
 Built and refined throughout development
 Purpose
 Name and model concepts in the system
 Specify collaborations
 Specify logical database schemas
 Developed by analysts, designers, and
implementers

Object Oriented Analysis & Design, SJTU 66

Object Oriented Analysis and Design 66
A Simple Sales Order Example

Order

Product

Ship via

Object Oriented Analysis and Design 67

Class Diagram for the Sales Example
Sale

Salesperson Customer Product Vehicle

seller buyer item sold shipping mechanism

Corporate Individual Truck Train

Object Oriented Analysis and Design 68

Effect of Requirements Change
Suppose you need a new
type of shipping vehicle ...
Sale

seller buyer item sold shipping mechanism

Salesperson Customer Product Vehicle

Corporate Individual Truck Train Airplane

Change involves adding a new subclass

Object Oriented Analysis and Design 69
Diagrams - Component Diagram
 A component diagram shows the organizations and dependencies
among software components, including source code components,
binary code components, and executable components.
 Component diagrams contain:
 Component packages.
 Components
 Interfaces
 Dependency relationships

image.java component.java
ImageObserver

Object Oriented Analysis and Design 70

Diagrams - Component Diagram
 Captures the physical structure of the
implementation
 Visualize the physical components in a
system.
 libraries, packages, files etc.
 Built as part of architectural specification
 Purpose
 Organize source code
 Construct an executable release
 Specify a physical database
 Developed by architects and programmers
Object Oriented Analysis and Design 71
Component Diagram - Example

Object Oriented Analysis and Design 72

Component Diagram - Example

Object Oriented Analysis and Design 73

Diagrams - Deployment Diagram
 A deployment diagram is a diagram that shows
the configuration of run time processing nodes
and the components that live on them.
 Captures the topology of a system’s hardware
 Built as part of architectural specification
 Purpose
 Specify the distribution of components
 Identify performance bottlenecks
 Developed by architects, networking engineers,
and system engineers

Object Oriented Analysis and Design 74

Deployment Diagram -Example

Object Oriented Analysis and Design 75

Deployment Diagram -Example

Object Oriented Analysis and Design 76

Diagrams - Sequence Diagram
 A sequence diagram emphasizes the time
ordering of messages.
Client Object Supplier Object

:Client :Supplier

Object Lifeline
Reflexive Message
1: doSomething()

1.1: doAnotherthing()
Message

Sequence number

Focus of Control
Object Oriented Analysis and Design 77
Diagrams - Collaboration Diagram
 A collaboration diagram emphasizes the
organization of the objects that participate in an
interaction.
Client Object Link Supplier Object

:Client :Supplier
1: doSomething()
Message

Object Oriented Analysis and Design 78

Sequence Diagram V.S. Collaboration Diagram
 Sequence diagrams and collaboration diagrams
express similar information but show it in
different ways.
 Sequence diagrams show the explicit sequence
of messages and are better for real-time
specifications and for complex scenarios.
 Collaboration diagrams show the relationships
among objects and are better for understanding
all of the effects on a given object and for
procedural design.

Object Oriented Analysis and Design 79

Diagrams - Statechart diagram
 A statechart diagram shows a state machine,
consisting of states, transitions, events, and
activities.
 Statechart diagrams emphasize the event-ordered
behavior of an object, which is especially useful
in modeling reactive systems.

shutDown

keyPress
Idle Running
Finished

Object Oriented Analysis and Design 80

 Statechart diagram -Example
add student / numStudents = numStudents + 1

/ numStudents = 0 remove student / numStudents = numStudents - 1

Unassigned

closeRegistration

cancel Cancelled
addProfessor
do: Send cancellation notices
close

removeProfessor cancel
[ numStudents = 10 ]
cancel
Full

close[ numStudents < 3 ] close

add student / closeRegistration [ has Professor assigned ]

[ numStudents = 10 ]
numStudents = numStudents + 1

Assigned closeRegistration[ numStudents >= 3 ] Committed

do: Generate class roster

close[ numStudents >= 3 ]

remove student / numStudents = numStudents - 1

Object Oriented Analysis and Design 81

Statechart diagram -Example
superstate
/ numStudents = 0 Open closeRegistration Closed

close Cancelled
Unassigned do: Send cancellation notices

cancel
cancel
substate
Full
close[ numStudents < 3 ]
remove a professor
[ numStudents = 10 ] close
add a professor
closeRegistration [ has Professor assigned ]

closeRegistration[ numStudents >= 3 ] Committed

Assigned
do: Generate class roster
add student /
numStudents = numStudents + 1
close[ numStudents >= 3 ]
H

remove student / numStudents = numStudents - 1

Object Oriented Analysis and Design 82

Diagrams - Activity Diagram
 An activity diagram shows the flow from activity to activity within a system.

initial state

Select site
action state
Bid Plan

decisio [ not accepted ]

[ else ] guard
n
expression
concurrent fork
Do site work Do trade work

concurrent join

Finish construction

final state
Object Oriented Analysis and Design 83
 Extension mechanism of the UML

Object Oriented Analysis and Design 84

Extension mechanism of the UML
 Stereotype
 Tagged value
 Constraint

Object Oriented Analysis and Design 85

Extension mechanism - Stereotypes
 A stereotype is an extension of the vocabulary of the
UML, allowing you to create new kinds of building blocks
similar to existing ones but specific to your problem.
 Stereotypes must be based on certain existing types or
classes in the metamodel. Stereotypes may extend the
semantics, but not the structure of pre-existing types and
classes. Certain stereotypes are predefined in the UML,
others may be user defined.

<<boundary>>
LoginForm LoginForm

Stereotyped element as icon

Named Stereotype
Object Oriented Analysis and Design 86
Stereotypes
 Stereotypes define a new model element in
terms of another model element.
 Sometimes, you need to introduce new
things that speak the language of your
domain and look like primitive building
blocks.
 Represented with name in guillemets or as
a different icon
<<Interface>>
Shape

Shape

Object Oriented Analysis and Design 87

Extension mechanism - Tagged Values
 Many kinds of elements have detailed properties that do
not have a visual notation. In addition, users can define
new element properties using the tagged value
mechanism.
 A tagged value is an extension of the properties of a
UML element, allowing you to create new information in
that element’s specification.
 A tagged value is a keyword-value pair that may be
attached to any kind of model element The keyword is
called a tag.

Object Oriented Analysis and Design 88

Tagged Values - Example

Common examples of tagged values are:

• {Author = (Dave,Ron)}
• {Version Number = 3}
• {Location = d:\java\uml\examples}
• {Location = Node: Middle Tier}

MyClass
{Version =
1.02}

Object Oriented Analysis and Design 89

Extension mechanism - Constraint
 A constraint is an extension of the semantics of a UML
elements, allowing you to add new rules or to modify
existing ones.
 Constraints may be written as free-form text. If you want to
specify your semantics more precisely, you can use the
UML’s Objec Constraint Language(OCL).

Simple constraint Portfolio

Corporation
{secure}
{or}
BankAccount Person
+wife
gender : {female,male}
Constraint across multiple elements 0..1
+husband
0..1
Formal constraint using OCL
{self.wife.gender = female and self.husband.gender = male}

Object Oriented Analysis and Design 90

Common Modeling Techniques
1) Modeling Comments - use notes

2) Modeling New Building Blocks - use stereotype.

3) Modeling New Properties - use tagged values.

4) Modeling New Semantics - use constraint

Object Oriented Analysis and Design 91

 Simple Example – Hello World

Object Oriented Analysis and Design 92

Simple Example - Hello World
 Key Abstractions
 Mechanisms
 Components

Object Oriented Analysis and Design 93

Example - Key Abstractions
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet
{
public void paint (Graphics g) {
g.drawString (“Hello World !”,10,10);
}
}
Applet
HelloWorld

paint() HelloWorld
Graphics
paint()
g.drawString (“Hello World !”,10,10)

Object Oriented Analysis and Design 94

Example - Key Abstractions
Object

Component
jav
ImageObserver
a
Container
HelloWorld applet

Panel awt

lang
Applet

HelloWorld

Object Oriented Analysis and Design 95

Example - Mechanisms
client : Thread : Toolkit : target :
ComponentPeer HelloWord
run( )
run( )

callbackLoop( )

handleExpose( )
paint( )

Painting mechanism
Object Oriented Analysis and Design 96
Example - Components

HelloWorld.class hello.java

hello.html
hello.jpg

HelloWorld Component

Object Oriented Analysis and Design 97