1 kyung hee university modeling with objects spring 2001

11

Kyung Hee University

Modeling with ObjectsModeling with Objects

Spring 2001

22


The Object ModelThe Object Model

The object model is a common computational model shared by both OO programs and design languages. It characterizes object oriented systems as:

dynamic networks of intercommunicating objects

Objects : Manage part of the system’s data and functionality.

Network : The objects are linked together.

Dynamic : The topology of the network of objects changes as the system evolves.

Intercommunicating : Objects communicate and “work together” to achieve system-wide functionality.

33


Role of the Object ModelRole of the Object Model

The Object Model

gives an abstract view of the run-time properties of object-oriented programs.

is used to explain the meaning of UML’s design notations.

It therefore serves as the ‘common ground’ between design

and programming languages, and explains the suitability of

UML as a language for designing object-oriented programs.

The object model is not a specific model within UML. It is a

general framework of concepts that are used to explain what

‘object-orientation’ amounts to.

44


A Simple ApplicationA Simple Application

Keeps track of parts in a manufacturing environment

and how they are use in constructing assemblies. We’ll

use the following terminology:

Parts : Individual, physical objects.

Assemblies : Complex structures made up out of parts, and

possibly structured into subassemblies.

55


A Simple Application (cont’d)A Simple Application (cont’d)

The program could:

maintain catalogue information: what kinds of parts are

there?

maintain inventory information: how many are in stock?

record structure of manufactured assemblies.

provide operations on assemblies:

– calculating the total cost of parts in an assembly;

– print a listing of all the parts in an assembly.

66


ObjectsObjects

Objects contain part of the system’s data.

A major task of object-oriented design is: to decide ho

w system’s data should be split up between different obje

cts.

A frequently applied rule of thumb for the identi

fication of objects is to represent real-world obje

cts from the application domain by the objects in

the model

77


Objects (cont’d)Objects (cont’d)

Rule of thumb

Consider application domain concepts, such as part, as

candidate objects. What data do we need to store about parts?

An identification number

A description

Their price

. . .

* Rule of thumb : A method or procedure derived entirely from practice or experience, without any basis in scientific knowledge; a roughly practical method.

88


Objects (cont’d)Objects (cont’d)

As a first step in the design of the stock management s

ystem, we are proposing that a ‘part’ class is defined

consider what data should be held by instances of that class

name number cost

99


A part classA part class

public class Part

{public Part(String nm, long num, double cst){

name = nm;number = num;cost = cst;

}

public String getName() { return name; }public long getNumber() { return number; }public double getCost() { return cost; }

private String name;private long number;private double cost;

}

1010


Object CreationObject Creation

In programming languages, classes are defined at the co

mpile-time. Objects are created at run-time, as instances o

f a class.

New object creation in Java :

part myScrew = new Part (“screw”, 28834, 0.02);

1111


Object Notation Object Notation

UML provides the following notation to show indiv

idual objects:

rectangular icon

object name and class name (underlined) in upper Compartment

attribute names and values in lower compartment

1212


Object Notation (cont’d)Object Notation (cont’d)

The following elements of this notation are optional:

object and class name (but one must be present)

the attribute compartment

attributes which are not of interest

Conventions

Class names start with upper-case letters

Object names start with lower-case letters

1313


ProblemsProblems

If we have 100,000 screws, this design would represent them by 100,000 screw objects, each storing the ID number of the part, its description and its price.

There are at least two major problems with this approach:

Redundancy : Storing the same data 100,000 times will waste

significant amounts of storage.

Maintainability : If for example the price of a screw changed, there would be 100,000 updates to perform in order to update the system. As well as being time-consuming, this will make it very hard to ensure that the system’s data is accurate and consistent.

1414


SolutionSolutionMove the shared information out of the part objects into a new

object that describes a particular kind of part. These ‘descriptor’

objects do not represent individual parts.

Rather, they represent the information associated with a catalogue

entry that describes a type of part.

1515


Properties of ObjectsProperties of Objects

The following terminology is often used in talking about objec

ts:

State : The aggregate of the data values in the object. Shown in the lo

wer part of the object icon.

Behaviour : The operations that the object can perform. Not shown on

the object icon.

Identity : A property of the object model. Objects are distinct, even if t

hey have identical state.

Encapsulation : Object state is only accessible through its operations.

1616


Links Links

In the object model, objects can be linked together to show some so

rt of relationship between them. In this case, the relationship is th

at the catalogue entry describes the part.

A relationship between objects is in UML known as a link

- Labels are often verbsObject diagram

1717


Links (cont’d)Links (cont’d)

Object Diagrams

Show objects and their relationships at a given point in time.

Links store data

Links store data “structurally”. The fact that a part is of a

particular type is represented by the link between the two

objects, not by a data item in the part object.

1818


Implementation of LinksImplementation of Links

Most programming languages do not define a way of directly imp

lementing of links. The simplest approach is usually to represent t

he link inside the linked objects by providing some way in which

an object can know which other objects it is linked to.

Allowing each part to maintain a reference to the catalogue entry

that describes it.

The implementation in next slide states that when a part is create

d, a reference to the appropriate catalogue entry object must be pr

ovided.

1919


Implementation of Links (cont’d)Implementation of Links (cont’d)public class CatalogueEntry{

public CatalogueEntry(String nm, long num, double cst){name = nm;number = num;cost = cst;}

public String getName() { return name; }public long getNumber() { return number; }public double getCost() { return cost; }

private String name;private long number;private double cost;

public class Part{public Part(CatalogueEntry e){entry = e;}

private CatalogueEntry entry;}

}

2020


Implementation of Links (cont’d)Implementation of Links (cont’d)

Showing how to create two objects, a catalogue entry and

a corresponding part.

The constructor of the part class ensures that the part obje

ct is linked to the catalogue entry object after it is created.

CatalogueEntry screw

= new CatalogueEntry (“screw”, 28834, 0.02) ;

Part screw1 = new Part (screw) ;

2121


NavigabilityNavigability

This implementation means that a part can access its catalogue entry, but not vice versa. In other words, the link can only be ‘navigated’ in one direction. This can be shown on an object diagram as follows:

The name of the data member implementing the link can be shown as a rolename at the end of the link. This shows the connection between the link and its implementation.

2222


MessagesMessages

So data in an object-oriented system is distributed across a

network of linked objects.

Some data is held explicitly, as attributes in objects.

Some data is held implicitly, represented by links between objects.

How is the data accessed? There is a single basic operation:

Send a message to an object

For example, to find out the cost of a part, you would send a message to the object representing the part asking for its cost.

2323


Notation for messagesNotation for messages Messages can be shown on object diagrams attached to links:

Here a client object is sending a message to a Part object, asking for

its cost. (Notice that the class of the client is not specified. In gen

eral, the same message can be sent by objects of many different cl

asses, and the class of the sender is not important.)

Messages have a name, such as “cost”, and are written in a familiar “function call” notation.

Return values can be shown using the := assignment symbol.

2424


Notation for messages (cont’d)Notation for messages (cont’d)

Links as communication channels

If two objects are connected by a link then they can send

messages to each other, navigability permitting.

2525


Sharing responsibilitySharing responsibility

Data is distributed across the network of objects. An object will oft

en get a message asking it to do something, but it doesn’t itself ho

ld all the data necessary to generate a response.

For example, how does the part object know its cost? The data is sto

red in the linked catalogue entry object: it must be retrieved from

there by sending a further message.

2626


Sharing responsibility (cont’d)Sharing responsibility (cont’d)

An object diagram which includes messages is called a collaboratio

n diagram or an interaction in UML.

2727


Implementation of message passingImplementation of message passing

The messages shown above behave in the same way as normal func

tion calls. They correspond to methods in the class receiving the

message. Sending a message corresponds to calling such a metho

d. When a part object receives a cost message, it sends a further m

essage to its linked catalogue entry object. This could be impleme

nted like this:public class CatalogueEntry{

public double getCost(){

return cost;}

private double cost;

}

public class Part{

public double cost(){

return entry.getCost();}

private CataloueEntry entry;}

2828


AssembliesAssemblies

An assembly is a grouping of individual parts that together make

up a structure.

2929


Assemblies (cont’d)Assemblies (cont’d)

All the information about the parts in the assembly is h

eld implicitly, represented by the links connecting part o

bjects to the assembly.

An implementation of the assembly class must contain:

1. a data structure to store references to linked objects

2. “housekeeping” operations to add, test and remove links from

this collection

3030


PolyporphismPolyporphism

Assemblies can also contain subassemblies, thus forming a hierar

chy of subassemblies and parts.

3131


Polyporphism (cont’d)Polyporphism (cont’d)

This is an example of polymorphism.

In order for this to work we must define a new class, whic

h will be called “Component”, which is a generalization

or superclass of “Part” and “Assembly”. We can then thi

nk of an assembly as containing a number of component

s, each of which could either be a part or a further assem

bly.

3232


Implementation of polymorphismImplementation of polymorphism

In order to achieve polymorphism is object-oriented languages the mec

hanism of inheritance is used. A components class can be defined, and

the part and assembly classes defined to be subclasss of this class :public abstract class Component{ }

public class Part extends Component {}

public class Assembly extends Component{

private Vector components = new Vector();

public void add(Component c) {

components.addElement(c);}

}

3333


Abstract ClassAbstract Class

No objects of the component class are ever created. It exists only to

describe the common features of parts and assemblies, namely

that they can both be stored in assemblies, and

that we can find out the cost of both.

Such a class is called an abstract class.

3434


Dynamic bindingDynamic binding

The same message may give rise to different processing,

depending on which object it is sent to.

3535


Dynamic binding (cont’d)Dynamic binding (cont’d)

When a part object is asked for its cost, it retrieves it from the ass

ociated catalogue entry object by sending a single getCost mess

age and returning the result.

When an assembly object is asked for its cost, it sends a cost m

essage to all of its components, adds up the values returned, and t

hen returns the total.

3636


Implementation of Late BindingImplementation of Late Binding

Programming languages allow superclass to define oper

ations which are implemented in different ways in differ

ent subclasses.

public abstract class Component

{

public abstract double cost();

}

public class Part extends Component

{ public double cost()

{

return entry.getCost();

}

}

public class Assembly extends Component

{

private Vector components = new Vector();

public double cost()

{

double total = 0.0;

Enumeration enum = components.elements();

while(enum.hasMoreElements())

{

total += ((component) enum.nextElement()).cost();

}

return total;

}

}

3737


Implementation of Late Binding (cont’d)Implementation of Late Binding (cont’d)

The class of the object receiving the message is checked at

run-time and the appropriate method called.

3838


Class diagramClass diagram

We’ve seen

UML object and collaboration diagrams showing runtime properties of the system

source code showing compile-time definitions of the relevant classes and objects

UML also provides notation for showing the compile-time design:

3939


Class diagram (cont’d)Class diagram (cont’d)

Shows classes that we’ve identified, and their attributes

Shows how instances of those classes can be linked at run-tim

e

Shows subclass relationship

4040


Class diagram

1 kyung hee university modeling with objects spring 2001

Documents