29
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

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

Embed Size (px)

Citation preview

Page 1: 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

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

Page 2: 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

Jan. 14, 2010 (c) Dr. David A. Workman 2

Object DefinitionsOBJECT

“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

WaterTankCoffeeGroundsBrewedCoffeeBrewTimeWallTime

PlugIn()UnPlug()BrewOn()BrewOff()SetBrewTime()SetWallTime()AddWater()PourCoffee()

Objects have a name or identity – described by nouns

Objects have attributes (encapsulated data) that characterize their dynamic state and persist over the lifetime of the object.

Objects have a behavior characterized by the collectionof 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 theobject reacts to external stimuli.

See Notes!

Page 3: 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

Jan. 14, 2010 (c) Dr. David A. Workman 3

Abstract Object Model

Encapsulated Data(private attribute set)

Service Layer(public interface)

Method Layer(private service implementation)

CoffeeMaker

WaterTankCoffeeGroundsBrewedCoffeeBrewTimeWallTime

PlugIn();UnPlug();BrewOn();BrewOff();SetBrewTime();SetWallTime();AddWater();PourCoffee();

Name

PlugIn() { … }UnPlug() { … }

BrewOn() { … }

BrewOff() { … }

SetBrewTime() { … }

SetWallTime() { … }

AddWater() { … }

PourCoffee() { … }

C++ Header (.h) file

C++ Implementation

(.cpp) file

Page 4: 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

Jan. 14, 2010 (c) Dr. David A. Workman 4

Objects as Software ComponentsAn 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(provides all and only the information necessary to use use the Object)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.

A Private Implementation ( provides a realization of the Object Interface and hides details of ( provides a realization of the Object Interface and hides details of Object representation)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.

Specify exactly what the object can do and how itwill be done.

“attributes” are frequently referred to as the “object’s state”

“contraints” are implicit- they should be stated ascomments in the interface.

See Notes!

Page 5: 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

Jan. 14, 2010 (c) Dr. David A. Workman 5

Object ExampleCircle

-Radius: double-Center: Point

+getRadius(): double+getCenter(): Point+isAtOrigin: bool+isBndryPt( Point ): bool+hasArea(): double+hasCircumf(): double

Inspectors:getRadius()getCenter()

Predicates:isAtOrigin()isBndryPt()

Properties:hasArea()hasCircumf()

Point

-x: double-y: double

+getXcoord(): double+getYcoord(): double+isOrigin(): bool+hasDistance(): double+operator-( Point ): Point

getRadius() {..} getCenter() {..}

isAtOrigin {..}

isBndryPt( Point ) {……..}

hasArea() {..}

hasCircumf() {..}

Inspectors:getXcoord()getYcoord()

Predicates:isOrigin()

Properties:hasDistance()

Services of PointRequired by Circle

Operators:Binary(-)

Page 6: 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

Jan. 14, 2010 (c) Dr. David A. Workman 6

CoffeeMaker::Brew()

Water::Heat( Temperature T)

Service, Brew(), Provided by CoffeeMakerrequires Service, Heat(), provided by WaterTime

Object Example

Page 7: 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

Jan. 14, 2010 (c) Dr. David A. Workman 7

Single Object Implementation in C++

#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.void Initialize(); }

Object.h

#include “Object.h”namespace Object {

}

Object.cpp

void Initialize() {}

Define encapsulated data members here. Primitive data can be directly initialized by their definition. Encapsulated data of class types may need to be defined via pointers and initialized in the Initialize() method. A specialboolean or enumeration variable may have to bedefined to ensure the proper protocol is usedwhen calling methods (e.g., Initialize() must becalled before any other method, or an exceptionis thrown.

Define the bodies of the functions declared in the header file. The bodies are defined usingThe 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 ifthe method protocol has been violated.

Page 8: 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

Jan. 14, 2010 (c) Dr. David A. Workman 8

Object Implementation in C++An Implementation of a CoffeeMaker in C++ using namespaces.

http://www.cs.ucf.edu/~workman/cop4331/CoffeeMaker2

Page 9: 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

Jan. 14, 2010 (c) Dr. David A. Workman 9

Active vs. Passive ObjectsActive 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

Page 10: 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

Jan. 14, 2010 (c) Dr. David A. Workman 10

Quiz1. 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?

Page 11: 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

Jan. 14, 2010 (c) Dr. David A. Workman 11

Class DefinitionA 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.

Page 12: 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

Jan. 14, 2010 (c) Dr. David A. Workman 12

Abstract Class Model

Subclasses Superclass

Class instances share common behavior and state characteristics.

Subclasses orSubtypes

See Notes!

Page 13: 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

Jan. 14, 2010 (c) Dr. David A. Workman 13

How Objects InteractA 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 Serviceand 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

NOTE: When objects are modeled in software, messages are realized by method calls.

See Notes!

Page 14: 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

Jan. 14, 2010 (c) Dr. David A. Workman 14

UML Concepts and Notation

Name

Attributes(private)

Services orOperations

FunctionalRespon-sibilities

Class Active Class

Name

Packages

Textual content

Note

Action

Use case

Actor

AnalysisEntity Class

AnalysisBoundary Class

AnalysisControl Class

Relationships

AssociationOriented AssociationDependency or FlowGeneralization/SpecializationCompositionAggregation

Component

Name

class

class

class

class

1

*

0..1

m..n

exactly one

zero or more

optional

boundedrange{ constraint } « stereotype »

Name

Attributes(private)

Services orOperations

FunctionalRespon-sibilities

Page 15: 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

Jan. 14, 2010 (c) Dr. David A. Workman 15

UML Class & Object ExamplesClass

Class with details suppressedAbstract classes have italicized names

Class

width: Lengthheight: Length ready: Bool/area: Length2

display()reset()

Class with analysis-level details

attributes: type or descriptionderived 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)

Class with implementation-level details

+ denotes public accessibility# denotes protected accessibility- denotes private accessibility

parameters and types specifiedaccessibility attributes specified

x :Point

size = (20, 45)ready = true

An instance ofclass “Point” named “x”

values of instance attributes

Objects

:ClassAn anonymous instance of anactive class

Class Name« boundary »

{attribute = value,…}

Class Properties

Class

« stereotype »{ class attributes }

h /head:PointInstance with/role specified.

Page 16: 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

Jan. 14, 2010 (c) Dr. David A. Workman 16

Abstract vs. Concrete Classes

DEFINITION (Abstract vs. Concrete)

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 Class

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;}

Page 17: 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

Jan. 14, 2010 (c) Dr. David A. Workman 17

Object Relationships: CompositionWHOLE-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.

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.See Notes!

Page 18: 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

Jan. 14, 2010 (c) Dr. David A. Workman 18

UML: Composition

Whole

Part A Part B Part C

Composition is indicatedby a “solid” colored or “filled” diamond shaped connector between Whole and its Parts

Automobile

Engine Transmission FuelSys

Socket

Style Local :HostAddr Remote:HostAddr

IPaddressPort

Class name

instance name

1 1 1

HostAddr

CoffeeMaker

Tank Basket HotPlate

Page 19: 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

Jan. 14, 2010 (c) Dr. David A. Workman 19

Object Relationships: Aggregation

WHOLE-PART (Aggregation)

– Container-Containee: This relationship is somewhat like the Whole-Part 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.

Page 20: 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

Jan. 14, 2010 (c) Dr. David A. Workman 20

Object Relationships: AffiliationWHOLE-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.

Page 21: 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

Jan. 14, 2010 (c) Dr. David A. Workman 21

UML: Aggregation and Affiliation

Container

Aggregation is indicatedby an “unfilled” diamond shaped connector between Container and its Containees

MailBox

MailMsg

Containee*

Multiplicity indicator (*) means that zero – or – moreinstances of the Containeeclass could be held by oneinstance of the Container class.

*

WaitingLine

Customers

0..10

AddrBook

AddrCard

0..500

NamePhone

Eaddr1..3

ACM

Member*

CoffeeMaker

Tank Basket HotPlate

Water Filter

CoffeeGrounds

1

Carafe

Coffee

heats

Page 22: 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

Jan. 14, 2010 (c) Dr. David A. Workman 22

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.

Department Faculty1..*

1

Course * Member ofoffers

1Chairperson of

College

2..*

Page 23: 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

Jan. 14, 2010 (c) Dr. David A. Workman 23

Class Relationships: Generalization-Specialization

INHERITANCE (GEN-SPEC)Inheritance is a relationship between classes also known as the Generalization-

Specialization (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 (re-define) any subset of them;

– Objects of a subclass may define new methods (behavior variation) not provided by the superclass.

Grocery

Produce MfgGoodsBulk

Priced byNumber orvolume

Priced byweight

Priced bybarcode

Defines all features common to, orshared by, each subclass. Thesefeatures are automatically defined through the mechanism of inheritance for instances of each subclass, UNLESS, the subclass chooses to re-define them.

See Notes!

Page 24: 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

Jan. 14, 2010 (c) Dr. David A. Workman 24

Abstract Inheritance Model INHERITANCE RELATION

New Attributes

S1

S2S3

S4

Superclass

S”1

S2

S3

S1

S”2S”3

S4

Subclass A Subclass B

Z S”4

Is-A Is-A

Inherited Attributes

White = inherited servicesGreen = new attributesYellow = redefined servicesRed = new services

Common Attributes

See Notes!

Page 25: 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

Jan. 14, 2010 (c) Dr. David A. Workman 25

Quiz

Model the following object relationships in UML.a) Clock to Second Handb) Source Program to Compilerc) Class to Data Memberd) Coffee Cup to Pencilse) Pencil to Eraserf) Student to Courseg) Course to COP4331h) Professor to Universityi) Method to Data Memberj) People to Software Process Modelk) Cat to Petl) your pet to Pet

Page 26: 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

Jan. 14, 2010 (c) Dr. David A. Workman 26

Use of Analysis Classes

System Boundary

ExternalData Source

or Sink

ExternalData Source

or Sink

ExternalData Source

or Sink

ExternalData Source

or Sink

Data flow

Control flow

Page 27: 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

Jan. 14, 2010 (c) Dr. David A. Workman 27

CoffeeMaker2 Simulation

System Boundary

Data flow

Control flow

Main()

CoffeeDrinker

coutmessages

time

OS

Systemtime

water

coffee

Mycup

coldwater

messages

coldwater CoffeeMaker

brewtim

e

brewmode

#cups

wallclock

Exe. time

Page 28: 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

Jan. 14, 2010 (c) Dr. David A. Workman 28

CoffeeMaker2 Design

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;

Tank

-Capacity: Cups-Contents: Water

+SetCapacity(Cups)+AddWater(Cups);+HeatWater( Degrees );+RemoveWater(Cups);

Carafe

-Capacity: Cups-Contents: Water

+SetCapacity(Cups)+AddCoffee(Cups);+RemoveCoffee(Cups);

Water

-Amount: Cups-Temperature: Degrees

+Water(Cups,Degrees)+AddAmount(Cups)+DelAmount(Cups);+ChangeTemp(Degrees);+Insert( ostream );#Put( ostream );#setAmount( Cups );#setTemp( Degrees );

Coffee

-Amount: Cups-Temperature: Degrees

+Coffee(Cups,Degrees)+Insert( ostream );#Put( ostream );

Page 29: 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

Jan. 14, 2010 (c) Dr. David A. Workman 29

CoffeeMaker Simulation