Transcript Document

UML and Patterns
Dr. Zhen Jiang
West Chester University
E-mail: [email protected]
url: www.cs.wcupa.edu/~zjiang
Outline

Introduction to UML
 Objects and Classes
 Class Diagrams
– Class Icon
– Relationships
– Constraints
Introduction to UML
What’s UML
 Goals of UML
 Overview

UML: Unified Modeling
Language

The Unified Modeling Language (UML) is
an industry-standard language for
specifying, visualizing, constructing, and
documenting the artifacts of software
systems
 The UML definition was led by Grady
Booch, Ivar Jacobson, and Jim Rumbaugh
(all now at Rational Software)
UML simplifies
the process of software
design, making a "blueprint" for construction
In Essence: a tool used through the analysis and design
phases of system development for expressing the
constructs and relationships of complex systems
Target Usage: for building object-oriented and
component-based systems
Goals of UML
1. Provide users with a ready-to-use, expressive visual modeling
language so they can develop and exchange meaningful models
2. Provide extensibility and specialization mechanisms to extend
the core concepts.
3. Be independent of particular programming languages and
development processes.
4. Provide a formal basis for understanding the modeling
language.
5. Encourage the growth of the Object-Oriented tools market.
6. Support higher-level development concepts such as
collaborations, frameworks, patterns and components.
7. Integrate best practices.
Many
free learning materials on the web
– e.g. www.rational.com/uml
Standard
of UML
www.cs.wcupa.edu/~zjiang/01-09-67.pdf
Some
recommended texts on UML:
– The Unified Modeling Language User Guide, [G.
Booch, J. Rumbaugh, I. Jacobson, 2000]
– UML Explained, [Kendall Scott, 2001]
– Applying UML and Patterns 2nd Ed., [Craig Larman,
2002]
– UML Distilled 2nd Ed., [Martin Fowler with K. Scott,
2000]
– UML and C++, [R. Lee & W. Tepfenhart, 2001]
UML Overview

UML is a language for visualizing,
specifying, constructing and documenting
the artifacts of a software system
 The artifacts might include requirements,
architecture, design, source code, project
plans, tests, prototypes, releases
 Six diagram types will be introduced: class,
relationship, constraint, activity, sequence,
statechart
Objects and Classes

What’s object
– Identity
– State
– Behavior




Sequence Diagram
Statechart Diagram
Messages and methods
What’s class
–
–
–
–
–
–
–
Objects and Classes
Nature of a class
Class Attributes
Operation (Method)
Interfaces
Interfaces and Implementation
Corresponding C++ code
Objects and Classes

Fundamentals of Object-Oriented
Programming
Objects

Conceptually, there are many ways to think
of an object
– something that can be seen or touched
– a thing to which some action is directed
– something that performs an action

The structure and behaviour of similar
objects are defined in their common class
 Objects have thee properties: identity , state,
and behaviour
Object Property 1: Identity

Identity is that property of an object which
distinguishes it from all other objects
 Most programming languages use variable
names to refer to objects
 Keep in mind, however, that an object may
not have a name; Similarly, an object might
have multiple names (aliases)
– For this reason, there is a subtle distinction
made between the concepts of "name" and
"identity"
Object Property 2: State

The state of an object encompasses all of the
(usually static) properties of the object plus
the current (usually dynamic) values of each
of these properties
R equirem ents
C apture
[rew ork]
[rev iew ]
C onc ept
D es ign
[rev iew ]
[rew ork]
[iterate]
[Lif e Update]
D et ailed
D es ign
[rew ork]
[rev iew ]
Im plem entat ion
[rev iew ]
Produc tion
[lif e end]
D ec om m is s ion
Object Property 3: Behaviour

Behaviour is how an object acts and reacts,
in terms of its state changes and message
passing
 The state of an object represents the
cumulative results of its behaviour
 In object-oriented programming, a
behaviour is invoked by sending a message
to an object
 If the receiver object does not have a
method for that message, an error is reported
Sequence Diagrams

A sequence diagram is an interaction
diagram that focuses on the time ordering of
messages
 A vertical dashed line is used to represent
the lifetime of an object (it’s the object’s
lifeline)
 A focus of control is a tall, thin rectangle
that shows the period of time during which
an object is performing an action
: Pilot
: ATC
requestLdgClearance(r)
: Radar
checkWeather
checkRunwayClear(r)
clear
clearance
Sequence
Development
Engineer
Customer
aw ard
contract
discuss
Process
negotiate
Quality
Engineer
allocate
plan
programme
allocate
allocate
capture
requirements
plan
quality
contribute
review
Programme
Manager
monitor
[monthly]
requirements
review
report
claim
Statechart Diagram

Captures dynamic behavior (event-oriented)
 Purpose
– Model object lifecycle
– Model reactive objects (user interfaces, devices, etc.)
Example Objects

There are many physical objects we can
examine right in this room
– each person is an object
– any chair is not an object
– each light bulb is an object
– Any book is not an object
– this room itself is an object (full or not)

See if the followings are objects or not:
–
–
–
–
–
–
–
–
–

Desk
Light
Person
Log
The Earth
Clock
Machine
Computer
Saving account
Answer: N, Y, Y, N, Y, Y, Y, Y, Y
Messages and Methods

A object executes a method when it is sent a
message
 For example, we can ask/tell a dog to sit by
sending him the message "sit"
 In object-oriented programming, objects are
sent messages asking/telling them to
perform behaviours -- the object invokes the
method corresponding to the message in
order to execute the desired behaviour
Objects versus Classes

How would we describe the state, behaviour,
and identity for each of these objects
 We have looked at objects and we have seen
that objects can be "classified" into classes
 As programmers, we work with both classes
and objects from those classes
 For example, we might write a stack class
and create multiple stack objects for use in
our program
Classes and Objects

An object is called an "instance" of a class
 The terms instance and object are
interchangeable
 Creating an object from a class is often
called instantiation
 For example, there are many person objects
in this room -- each person is an instance of
the person class
The Nature of a Class

A class describes the common structure
(attributes/state) and behaviour of its instances
 For example,
– 3.14, 2.71, and 5.5 can be classified as Floats
– the following shapes can be classified as Circles

In a 2D drawing package, circles have a
radius, a line thickness, a line colour, and a
fill colour
 Each individual circle (instance) drawn by
the user has its own value for each attribute
 The programmer writes a Circle class and
the program instantiates a Circle object
every time the user draws a Circle
a snowman made from 9
Circle instances
Class Attributes




An attribute is a named property of a class
that describes the range of values that
instances of the property may
hold.(Booch,1999)
An attribute has a type that defines the
type of its instances.
Only the object itself should be able to
change the value of its attributes.
The values of the attributes define the
state of the object
Operation (Methods)

An operation is the implementation of a service
that can be requested from any object of the class
to affect behavior (Booch, 1999)

An operation can be:
– Question (does not change the value of the object)
– Command (may change the value of the object)
Interfaces



An interface is a collection of operations that
are used to specify a service of a class or a
component (Booch, 1999)
An interface is a contract of related services
and a set of conditions that must be true for the
contract to be faithfully executed
Interfaces formalize polymorphism, they allow
us to define polymorphism in a declarative way
unrelated to implementation
Interface and Implementation

The class interface is its external (public)
view
 The class implementation is its internal
(private) view
 It is convenient to think of the interface as
describing "what the objects of this class can
do" and the implementation as "how the
objects of this class do it"
 The implementation of a class consists of all
the "behind the scenes" operations defined
in the interface of the class
Review
something
Object
action
state1
action
state2
operations/methods
attributes: {attribute1,
attribute2}
structure
operation/method
attribute1
attribute2
value
Light
Turn on/off
On
Off
operations/methods:
Turn_on/off ( )
attributes: {True,
False}
structure
Turn_on
True
False
Turn_off
value
C++ code
class Light
{
public:
void turn_on();
void turn_off();
Light();
~Light();
private:
bool status;
};
//
//
//
//
Modifier
Modifier
Constructor
Destructor

Class heading (class Light) & head file (light.h)
 Operation implementation (light.cc) & library
(light.o, light.lib)
 Usage (message/event, interface and its
implementation) & main (classroom.cc)
int main()
{
Light s1[2];
//Class obj1, obj2;
while (1){
Event event;
event.receive_message();
//receive task
for (int i = 0 ; i < 2; i ++){
//for all the objs
// concerned, interface
if (event.needs_turn_on())
s[i].turn_on ();
//interface implement
}
//end of one iteration
}
//end of while
return 0;
}
Class Diagram

Introduction
 Class Icon
 Relationships
 Constraints
Introduction

The class diagram is fundamental to objectoriented programming
 UML’s class diagrams capture the attributes
and operations of each class as well the
relationships that exist between classes
Class Icon





Class Icon
Hiding Details
Visibility Notation
Attribute Specification
Operation Specification
UML Class Icon

The UML class icon is
a rectangle with three
compartments:
– class name
– class attributes
– class operations

Attributes are specified
in the following form:
– object:class name
Circle
radius: float
center_x: int
center_y: int
area()
display()
Hiding Detail

You can optionally leave out the attributes,
operations, or both in a class icon:
Circle
area()
display()
Circle
radius: float
center_x: int
center_y: int
Circle
UML Member Visibility
Notation
UML has
three visibility prefixes for
members:
+ for public, # for protected, and – for
private
– e.g.
Circle
-radius: float
#area()
+display()
Full UML Attribute
Specification

The full form of a UML attribute is as
follows:
[visibility] name [multiplicity] [: type] [= initial value]
[{property}]
– The property choices are changeable, addOnly, and frozen
Student Info
-id: string
-hasGraduated: bool = false
Full UML Operation
Specification
The
full form of a UML operation is as
follows:
[visibility] name [(parameter-list)] [:return-type] [{property}]
– The property choices are sequential, concurrent, guarded, and
isQuery
The full form of a UML parameter is:
[direction] name : type [= default-value]
– The direction choices are in, out, and inout
UML Class Relationships

A class relationship is a connection between
two (or more) classes
 The three most important class relationships
are generalizations, associations, and
aggregations
 UML provides a graphical representation for
each of the relationships using a different
line type for each relationship
Class Relationships

Generalization
 Association
 Association Class
 Qualified Association
 Ternary Association
 Aggregation
Generalization


A generalization is a relationship between a general
thing (superclass) and a more specific kind of that
thing (subclass)
In the UML, generalization requires that objects of the
subclass may be used anywhere an object of the
superclass appears
Person
Student
Generalization
Class Person
{
public:
Person( long );
~Person();
void show_id();
private:
long ssn;
};
// Constructor
// Destructor
// social security number
Class Student : public Person
{
public:
Student( long, long );
~Student();
void show_info();
private:
long sn;
// student number
};
Generalization
Person::Person (long number)
{
ssn=number;
}
Student::Student (long snumer, long ssnumber):Person(ssnumber)
{
sn=snumber;
}
void Student:: show_info ()
{
Person::show_id();
cout << “; student number is “ << sn <<endl;
}
void Person:: show_id ()
{
cout << “Social security number is “ << ssn <<endl;
}
Generalization
int main ()
{
Person a(900010034);
a.show_id();
Student b(123456789, 654321);
b.show_info();
}
Generalization
Class Person
{
public:
Person( long );
~Person();
void show_id();
protected:
long ssn;
};
// Constructor
// Destructor
// social security number
Class Student : public Person
{
public:
Student( long, long );
~Student();
void show_info();
private:
long sn;
// student number
};
Generalization
void Student:: show_info ()
{
cout << “Social security number is “ << ssn <<endl;
cout << “; student number is “ << sn <<endl;
}
Generalization
Class Person
{
public:
Person( long );
// Constructor
~Person();
// Destructor
virtual void show_info()=0;
protected:
long ssn;
// social security number
};
Class Student : public Person
{
public:
Student( long, long );
~Student();
void show_info();
private:
long sn;
// student number
};
Generalization
void Student:: show_info ()
{
cout << “Social security number is “ << ssn <<endl;
cout << “; student number is “ << sn <<endl;
}
Association
An
association is a structural relationship that specifies
that objects of one thing are connected to objects of
another
Faculty
Student
Association
Class Student
{
// other declarations as before
private:
Faculty * teacher;
friend Faculty::add_new_student( Student *);
friend Faculty::remove_from_list ( Student *);
public:
Faculty * get_teacher () {return teacher;}
};
Class Faculty : public Student
//it’s not generalization
{
// other declarations as before
private:
Student ** students;
public:
void add_new_student ( Student *);
void remove_from_list( Student *);
Student ** get_students () {return students;}
};
Association
void Faculty:: add_new_student ( Student * s)
{
s->teacher = this;
// add s to students;
}
void Faculty:: remove_from_list (Student * s)
{
s->teacher = 0;
// remove s from students;
}
Association
Associations
can be adorned with a name.
Teaching
Faculty
Student
Association
Associations
Faculty
can be adorned with the roles.
teacher
learner
Student
Association
Associations
Faculty
can be adorned with the multiplicity.
1
4..*
Student
Association Class (relation
attributes)

Each object of association class is one
instance of relationship (link) in an
association.
Faculty
1..*
4..*
Course
Student
Qualified Association

Qualified association relates two classes and
a qualifier.
 The qualifier is a special attribute that
reduces the effective multiplicity of an
association.
Directory
file
name
File
Ternary Association

A ternary association is a structural relationship that
specifies that objects of one thing are connected to
objects of other two’s.
Project
Language
Developer
Aggregation

An aggregation is an association that
represents whole/part relationship
 The “whole” end of the association
relationship is adorned with an open
diamond shape (e.g. X is part of Y)
 e.g. door:Door is part of car:Car
X
Y
Generalization, Aggregation, and
Association

See if the following pairs of classes have
generalization, aggregation or association

Faculty & student (as)
 Hospital & doctor (as)
 Door & Car (ag --<>)
 Member & Organization (ag --<>)
 People & student (ge <|-- )
 Circle & point (ge --|>)
 Department & Faculty (as)
 Employee & Faculty (ge <|--)
 Item & Printer (ge <|--)
 Account & Checking account (ge <|-- )
Constraints

Constraints on Object
 Constraints on Relations (Ordering)
 General Constraints (Dependency)
Constraints on Object
The
constraints restricts the values that
objects can be.
Example:
No employee’s salary can exceed
the salary of the employee’s boss.
{salary <=boss.salary}
Employee
Salary
Employer
Salary
Constraints on Relations
(Ordering)
{Order}
indicates that the elements of the
“many” end of an association have an explicit
order that must be preserved.
{ordered}
Paper
1
1..
*
Author
General Constraints
(Dependency)

A dependency is a using relationship that states that a
change in specification of one thing may affect another
thing that uses it (but not necessarily the reverse)
General Constraints
(Dependency)

Dependencies are often used when one class uses
another class as an argument of the operation
Aerodrome
checkRVR( r: Runway )

Runway
Dependencies are also often used to express general
constraints.
member-of
Person
{subset}
chair-of
Committee