Transcript No Slide Title

Review
of
OO Design Concepts
COP 4331 and EEL4884
© Dr. David A. Workman
School of EE and Computer Science
University of Central Florida
Jan. 14, 2010
Object Definitions
OBJECT
“A concept, abstraction, or thing with crisp boundaries and meaning for the
problem at hand; an instance of a class.” [James Rumbaugh]
“An abstraction of something in the domain of a problem or its
implementation, reflecting the capabilities of a system to keep information
about it, interact with it, or both; an encapsulation of attribute values and
their exclusive services.” [Peter Coad & Ed Yourdon]
UML Example
CoffeeMaker
See Notes!
Jan. 14, 2010
Objects have a name or identity – described by nouns
WaterTank
CoffeeGrounds
BrewedCoffee
BrewTime
WallTime
Objects have attributes (encapsulated data) that
characterize their dynamic state and persist over
the lifetime of the object.
PlugIn()
UnPlug()
BrewOn()
BrewOff()
SetBrewTime()
SetWallTime()
AddWater()
PourCoffee()
Objects have a behavior characterized by the collection
of services they provide to other objects – these are
operations “you can perform on objects” to alter their
behavior or determine their state – behavior is how the
object reacts to external stimuli.
(c) Dr. David A. Workman
2
Abstract Object Model
Name
Encapsulated Data
(private attribute set)
Service Layer
(public interface)
Method Layer
(private service
implementation)
C++ Implementation
(.cpp) file
Jan. 14, 2010
(c) Dr. David A. Workman
C++ Header (.h) file
CoffeeMaker
WaterTank
CoffeeGrounds
BrewedCoffee
BrewTime
WallTime
PlugIn();
UnPlug();
BrewOn();
BrewOff();
SetBrewTime();
SetWallTime();
AddWater();
PourCoffee();
PlugIn() { … }
UnPlug() { … }
BrewOn() { … }
BrewOff() { … }
SetBrewTime() { … }
SetWallTime() { … }
AddWater() { … }
PourCoffee() { … }
3
Objects as Software Components
An Object is modeled by software components consisting of the following elements:
A Name by which the object is referenced – that is, the name that must be used to invoke its
methods.
A Public Interface (provides all and only the information necessary to use the Object) defined by:
– A Set of Provided Services the Object offers to clients (users) - these services characterize the
Object’s behavior ( defines what functionality it supports) in the given application. Provided
Services can be generally classified as effectors or mutators (services that can potentially
change the Object’s attributes) and inspectors, properties and predicates (services that only
report values of the Object’s attributes);
– A Set of Constraints that define a protocol by which services can be used.
e
t
t
as
ce.
A Private Implementation ( provides a realization of the Object Interface and hides details of
Object representation) defined by:
– A set of Data Members (attributes) whose values can denote objects of other kinds or primitive
types like int and float.
– A Set of Methods having exclusive access to the Object’s attributes that implement Provided
Services.
– Provided services of other objects (or types) may be called by the Object’s Implementation,
they are designated as the Object’s Required Services.
as
See Notes!
Jan. 14, 2010
(c) Dr. David A. Workman
4
Object Example
Circle
-Radius: double
-Center: Point
+getRadius(): double
+getCenter(): Point
+isAtOrigin: bool
+isBndryPt( Point ): bool
+hasArea(): double
+hasCircumf(): double
Predicates:
isOrigin()
Properties:
hasDistance()
Inspectors:
getXcoord()
getYcoord()
Operators:
Binary(-)
Point
getRadius() {..}
getCenter() {..}
isAtOrigin {..}
isBndryPt( Point ) {……..}
hasArea() {..}
hasCircumf() {..}
Predicates:
isAtOrigin()
isBndryPt()
Services of Point
Required by Circle
-x: double
-y: double
+getXcoord(): double
+getYcoord(): double
+isOrigin(): bool
+hasDistance(): double
+operator-( Point ): Point
Properties:
hasArea()
hasCircumf()
Inspectors:
getRadius()
getCenter()
Jan. 14, 2010
(c) Dr. David A. Workman
5
Object Example
CoffeeMaker::Brew()
Time
Service, Brew(), Provided by CoffeeMaker
requires Service, Heat(), provided by Water
Water::Heat( Temperature T)
Jan. 14, 2010
(c) Dr. David A. Workman
6
Single Object Implementation in C++
Object.h
#include “AppError.h”
namespace Object {
// Declare C++ functions representing methods of the namespace object.
// At least one of these function must always be defined to properly initialize
// the object’s environment before any other method can be called. These
// initialization functions serve the same purpose as constructors of a class
// type. The default initialization method is declared below.
Define encapsulated data members here.
void Initialize();
Primitive data can be directly initialized by their
}
definition. Encapsulated data of class types may
Object.cpp
#include “Object.h”
namespace Object {
void Initialize()
{
}
}
Jan. 14, 2010
need to be defined via pointers and initialized in
the Initialize() method. A special
boolean or enumeration variable may have to be
defined to ensure the proper protocol is used
when calling methods (e.g., Initialize() must be
called before any other method, or an exception
is thrown.
Define the bodies of the functions declared in the
header file. The bodies are defined using
The same syntax you would use for functions in C,
but they have direct visibility to all data members
defined at the top of the namespace.
An AppError exception should be thrown if
the method protocol has been violated.
(c) Dr. David A. Workman
7
Object Implementation in C++
An Implementation of a CoffeeMaker in C++ using namespaces.
http://www.cs.ucf.edu/~workman/cop4331/CoffeeMaker2
Jan. 14, 2010
(c) Dr. David A. Workman
8
Active vs. Passive Objects
Active objects are usually objects that have the responsibility for initiating or
precipitating a sequence of processing actions or events in the system.
Active objects play the role of driver, controller, supervisor, or manager
for either the entire system or one of its subsystems. Active objects
typically introduce an independent thread of control and have decision
making capability.
Passive objects are benign entities or servers (usually dedicated to a single
object). Their services run on the control thread of their client, they have
none of their own.
Examples:
Passive objects: Radio, Bank Account, Grocery Cart, Shopping List
Active objects: Cat, Shopper
Jan. 14, 2010
(c) Dr. David A. Workman
9
Quiz
1. Is a CoffeeMaker a passive or active object? Justify your answer.
2. Is an ATM Machine in the Student Union passive or active?
3. How would you model the behavior of an ATM Machine?
4. What are the functions of an ATM Machine?
5. How you model its state?
6. Is your pet an active or passive object?
7. How would you model the behavior of your pet?
8. What functions does your pet perform?
9. How would you model its state?
10. Is a rock a passive or active object?
11. How would you model its state and behavior?
Jan. 14, 2010
(c) Dr. David A. Workman
10
Class Definition
A CLASS is a collection of objects offering a common set of services and
possessing a common set of attributes. In addition, a Class defines some
mechanism for creating (constructor services) and destroying objects
(destructor services).
NOTE: This does not imply all objects in the same Class have identical
behaviors and states. It is only necessary that they have certain common
characteristics or features. The next slide illustrates this concept.
NOTE: In C++, destructor methods are provided by default, but may need
to be redefined by the programmer.
Jan. 14, 2010
(c) Dr. David A. Workman
11
Class instances
share common
behavior and state
characteristics.
Abstract Class Model
Subclasses or
Subtypes
See Notes!
Subclasses
Jan. 14, 2010
Superclass
(c) Dr. David A. Workman
12
How Objects Interact
A Message is an information structure providing a mechanism for
transmitting both control and data between objects. A Message
specifies explicitly or implicitly the following:
(1) The identity of the Client (message sender)
(2) The identity of the Server (message receiver)
(3) The identity of the Service to be performed
(4) Any Parameters needed by the Service
and optionally
(5) A Result return to the Client.
Examples:
• Electronic signals
• Sound waves
• Reflected light
• A letter sent via surface mail
• A message sent via email
• Sensor values
See Notes!
NOTE: When objects are modeled in software, messages are realized by method calls.
Jan. 14, 2010
(c) Dr. David A. Workman
13
UML Concepts and Notation
Class
Active Class
Name
Name
Attributes
(private)
Attributes
(private)
Services or
Operations
Services or
Operations
Functional
Responsibilities
Component
Note
Name
Textual
content
Name
Functional
Responsibilities
Use case
Analysis
Analysis
Boundary Class Control Class
Relationships
Association
Oriented Association
Dependency or Flow
Generalization/Specialization
Composition
Aggregation
Action
Actor
{ constraint }
Jan. 14, 2010
Packages
« stereotype »
(c) Dr. David A. Workman
exactly
one
Analysis
Entity Class
1
zero
or more
*
optional
0..1
bounded
range
m..n
class
class
class
class
14
UML Class & Object Examples
Objects
Class
Class
Class with details suppressed
Abstract classes have italicized names
Class with analysis-level details
Class
width: Length
height: Length
ready: Bool
/area: Length2
display()
reset()
attributes: type or description
derived attributes denoted by “/”
are computable from other attributes
methods or responsibilities
(functional capabilities)
Class
+size: Area(50,100)
#ready: Bool = false
-winptr: Window&
+display()
+reset()
-attach(Window& Obj)
Jan. 14, 2010
x :Point
size = (20, 45)
ready = true
h /head:Point
:Class
An instance of
class “Point”
named “x”
values of
instance
attributes
Instance with
/role specified.
An anonymous
instance of an
active class
Class with implementation-level details
Class Properties
+ denotes public accessibility
# denotes protected accessibility
- denotes private accessibility
parameters and types specified
accessibility attributes specified
(c) Dr. David A. Workman
Class Name
« boundary »
{attribute = value,…}
« stereotype »
{ class attributes }
15
Abstract vs. Concrete Classes
DEFINITION (Abstract vs. Concrete)
Class
Class
A class is said to be abstract if no instances of that class can be created,
otherwise the class is said to be concrete.
Class declarations in C++ provide a kind of specification template for its
concrete (or implementation) subclasses. A class is abstract in C++ if it
declares one or more pure virtual methods. Pure virtual methods have no
implementation (no bodies) in the abstract class, but ALL derived subclasses
MUST re-define and implement pure virtual methods of their superclasses.
class Agent
{public:
Agent();
// default constructor
virtual ~Agent(); // virtual destructor
virtual void Initialize( Message *) = 0; //pure virtual method defines class as abstract.
virtual void Dispatch( Message *) = 0; //pure virtual method defines class as abstract.
private:
string name;
}
Jan. 14, 2010
(c) Dr. David A. Workman
16
Object Relationships: Composition
WHOLE-PART (Composition)
Objects relate to one another in a variety of ways, some relationships are of a
physical nature, while others are of a more logical or conceptual nature.
For example:
– Whole-Part: In this type of relationship, one or more objects are parts
or components of a more complex composite object representing the
whole. Relationships of this kind tend to model physical or geographic
relationships involving tangible objects. For example,
An Engine is part of an Automobile.
Whole-Part is also referred to as the “Has-A(n)” relation, that is,
An Automobile Has-An Engine.
See Notes!
Whole-Part relationships tend to imply a strong functional interaction
(high coupling) between constituent objects.
– Composition is usually implied when the “whole” has responsibility for
creating its “parts” [Texel]. Furthermore, Composition is implied when
the Whole will not function properly without the presence of each of its
Parts.
Jan. 14, 2010
(c) Dr. David A. Workman
17
UML: Composition
Whole
Part A
Part B
Automobile
Part C
Composition is indicated
by a “solid” colored or
“filled” diamond shaped
connector between
Whole and its Parts
instance name
Class name
Socket
Engine
Transmission
FuelSys
1
CoffeeMaker
Style
1
1
Local :HostAddr
Remote:HostAddr
HostAddr
Tank
Basket
HotPlate
Port
Jan. 14, 2010
(c) Dr. David A. Workman
IPaddress
18
Object Relationships: Aggregation
WHOLE-PART (Aggregation)
– Container-Containee: This relationship is somewhat like the WholePart where the Whole is an object that plays the role of a “storage
container” used to hold and organize instances of some class or classes
of “containee” objects. Normally, there is a very little interaction
between the Container and its Containees.
For example, a Bag of Groceries. The Bag denotes the container and
the groceries are the containees. A List of addresses.
– This relationship might also be called the “Holds-A(n)” relation. In
contrast to Composition, seldom are there any functional dependencies
or interactions between the Container and its Containees.
– Containers are normally not responsible for creating containees.
Jan. 14, 2010
(c) Dr. David A. Workman
19
Object Relationships: Affiliation
WHOLE-PART (Affiliation )
– Organization-Member: Affiliations are almost always logical in nature.
The Organization may represent a loose collection of Members( people
or things ) having a common purpose or interest or other reason for
affiliation.
– The Member-Organization relationship might also be called the
“Belongs-To” relation; conversely, the Organization-Member
relationship could be called the “subscription” relation.
This type of relationship may not be formal enough to define a class of
objects - it is the type of relationship that can dynamically change its
membership; that is, the type of objects that form the affiliation defined
by this relationship can change with time.
For example, members of a club or email interest group may have a
common background, common interests, or a common hobby that forms
the basis for their affiliation, but there may not be a need for a formal
organization.
Jan. 14, 2010
(c) Dr. David A. Workman
20
UML: Aggregation and Affiliation
Container
Aggregation is indicated
by an “unfilled” diamond
shaped connector between
Container and its Containees
Multiplicity indicator (*)
means that zero – or – more
instances of the Containee
class could be held by one
instance of the Container class.
*
Containee
CoffeeMaker
MailBox
Tank
Basket
1
Filter
Carafe
Coffee
Grounds
Coffee
Jan. 14, 2010
AddrBook
ACM
HotPlate
heats
Water
WaitingLine
*
MailMsg
0..10
Customers
Name
(c) Dr. David A. Workman
0..500
AddrCard
1..3
Phone
*
Member
Eaddr
21
Object Relationships: Association
ASSOCIATION
– This relationship is the most informal of all those mentioned above. This
relationship is used to define an instance connections (Coad/Yourdon) between
objects; that is, a weak relationship between objects necessary to model some
property or “interest” they have in common. Or, objects that have some reason to
interact.
For example, Mary likes Bob, Ed and Charles both own Fords.
Again, it is even more informal than the Organization-Member relation.
College
2..*
Course
*
offers
Department
Member of
1
1..*
Faculty
1
Chairperson of
Jan. 14, 2010
(c) Dr. David A. Workman
22
Class Relationships: Generalization-Specialization
INHERITANCE (GEN-SPEC)
Inheritance is a relationship between classes also known as the GeneralizationSpecialization (Gen-Spec) relation. A superclass is said to generalize its subclasses,
conversley, a subclass is said to specialize its superclass. Inheritance implies the
following:
– Objects of a subclass inherit all attributes defined by the superclass, and may
define addtional ones;
– Objects of a subclass normally inherit all methods (behavioral characteristics
and functional capabilities ) defined by the superclass, and may override (redefine) any subset of them;
– Objects of a subclass may define new methods (behavior variation) not provided
by the superclass.
Defines all features common to, or
shared by, each subclass. These
features are automatically defined
through the mechanism of inheritance
for instances of each subclass,
UNLESS, the subclass chooses to
re-define them.
Jan. 14, 2010
See Notes!
Grocery
Produce
Bulk
Priced by
Number or
volume
Priced by
weight
(c) Dr. David A. Workman
MfgGoods
Priced by
barcode
23
Abstract Inheritance Model
INHERITANCE RELATION
Common Attributes
Superclass
S2
S3
New Attributes
See Notes!
S1
Subclass A
Is-A
S2
S3
S”1
Z
Jan. 14, 2010
S”4
S4
Is-A
Subclass B
S”2
Inherited Attributes
White = inherited services
Green = new attributes
Yellow = redefined services
Red = new services
(c) Dr. David A. Workman
S1
S”3
S4
24
Quiz
Model the following object relationships in UML.
a) Clock to Second Hand
b) Source Program to Compiler
c) Class to Data Member
d) Coffee Cup to Pencils
e) Pencil to Eraser
f) Student to Course
g) Course to COP4331
h) Professor to University
i) Method to Data Member
j) People to Software Process Model
k) Cat to Pet
l) your pet to Pet
Jan. 14, 2010
(c) Dr. David A. Workman
25
Use of Analysis Classes
External
Data Source
or Sink
System Boundary
External
Data Source
or Sink
External
Data Source
or Sink
External
Data Source
or Sink
Jan. 14, 2010
Data flow
Control flow
(c) Dr. David A. Workman
26
CoffeeMaker2 Simulation
water
time
System
time
wallclock
coldwater
Data flow
OS
Control flow
Coffee
Maker
Main()
messages
Exe. time
messages
cout
coffee
Mycup
Coffee
Drinker
Jan. 14, 2010
System Boundary
(c) Dr. David A. Workman
27
CoffeeMaker2 Design
Water
-Amount: Cups
-Temperature: Degrees
CoffeeMaker
-PowerOn: boolean
-*Tank
-*Carafe
-BrewTime: time
-WallTime: time
-BrewMode: Mode
-BrewRate: float
-BrewTemp: float
+PlugIn();
+UnPlug();
+SetBrewMode( Mode);
+SetBrewTime( int );
+AddWater( Water );
+BrewCoffee();
+PourCoffee( Cups ): Coffee;
Jan. 14, 2010
Tank
-Capacity: Cups
-Contents: Water
+SetCapacity(Cups)
+AddWater(Cups);
+HeatWater( Degrees );
+RemoveWater(Cups);
Carafe
+Water(Cups,Degrees)
+AddAmount(Cups)
+DelAmount(Cups);
+ChangeTemp(Degrees);
+Insert( ostream );
#Put( ostream );
#setAmount( Cups );
#setTemp( Degrees );
Coffee
-Capacity: Cups
-Contents: Water
-Amount: Cups
-Temperature: Degrees
+SetCapacity(Cups)
+AddCoffee(Cups);
+RemoveCoffee(Cups);
+Coffee(Cups,Degrees)
+Insert( ostream );
#Put( ostream );
(c) Dr. David A. Workman
28
CoffeeMaker Simulation
Jan. 14, 2010
(c) Dr. David A. Workman
29