SWT - Diagrammatics

Lecture 3/4 - Diagramming in OO Software Development - partA2-May-2000

Previous Lecture Review

• Diagram Distinctions :– Adjoinment, Linkage, Containment.

• Diagram Taxonomies.• Diagram use in Computer Science :

– Venn, Flowcharts, NSD’s, Structure, Dataflow, ERD’s, Cell and Arrows, State, Petri nets.

• Logic Gate Diagrams.• How to operate Theseus under CM.

Overview– OO Introduction,– OO Design Notations, – Objects, Messages / Control & Data Flow, Classes.– Class Attributes and Operations,– Visibility of Attributes and Operations,– Relationships :

– Association, Multiplicity, Aggregation,– Dependency, Inheritance.

– Object Oriented Views

• OO Systems are viewed as compositions of domain specific object abstractions, rather than data and functions. Objects associate data and behaviour.

• Objects in a System inter-communicate by sending messages to each other.

• An Object is a domain concept that has :– State– Behaviour– Identity

What OO Systems are?

OO Software Engineeringhas three distinctive OO processes :

• OO Analysis (OOA) focuses on the understanding of real-world models.

• OO Design (OOD) stresses the mapping of the OOA model to structured architectures, and

• OO Programming (OOP) deals with the building of OOD models under the constraints of the existing environments.

The Object Model

Is a view of the world in terms of Objects and their relationships.

Object Oriented Design Notations• OOD is one of CS’s disciplines that make heavy use of

diagrams.• There are many different OOD notations, all conveying the

same (more or less) information about the systems they describe :

• Coad/Yourdon, Fusion, Jacobson, Martin/Odell, Shlaer and Mellor, Wirfs-Brock et al, Meyer etc

• Three are the most popular ones :– Booch,OMT, UML.

• You can use which ever you prefer, however UML became the standard in OO design on feb’97.

Objects• An object is an atomic entity, formed from the union of state

and behaviour.• Provides encapsulation.• Provides a weak coupling with the outside world.• Software objects define an abstract representation of real

or virtual world entities.

Visible behaviour

Hidden internal state

An object

Objects• In Booch, objects are represented by clouds.• In OMT as in UML, objects are represented by rectangles.• In UML, the name of the object is underlined.

Name : Class Name : Class Name : Class

Booch OMT UML

Messages / Control & Data Flow• The message is the unit of inter-object communication.• It allows interaction in a flexible manner.• It is responsible for the delegation of tasks, and guarantees

that constraints are satisfied.• A message combines control flows and data flows within a

single entity.• The notion of a message is an abstract concept: it could be a

constructor, a method call, a discrete event, an interrupt, a UDP datagram etc.

Object1 Object2Message A Control FlowData Flow

Data Flow

Messages / Control & Data Flow• In the three notations, messages are represented using arrows near the links.• The control flow type is represented by using a line decorated with an

arrowhead.• A small circle connected to the line indicates a data flow, with the arrow

pointing to the direction of the flow.• This notation is optional and has become redundant.

Booch OMT UML

Data flowrepresentedby the messagelabels

Classes

A Class

• A class is the product of an abstraction process which starts with the identification of common characteristics of a set of elements, and proceeds to the concise description of these characteristics.

• The abstraction process is arbitrary: it is defined with respect to a particular viewpoint

Classes• A class describes the definition domain of a set of objects.• It acts as a “mould” from which objects can be created.• Software objects are built from the class, via a process called “instantiation”, objects are

“instances” of classes.• In Booch, classes are represented using dotted clouds.• In OMT, as in UML, classes are represented using rectangles.

Class Class

Booch OMT UML

Class Attributes and Operations

• Each class is represented as a rectangle subdivided into three components :– The name of the class,– The attributes of the class,– The operations of the class,

• By default, attributes are hidden and operations are visible.• These compartments may be omitted to simplify the diagrams.

Class name

Operations( )

Attributes

Class Attributes and Operations• In all three notations, attributes and operations are represented

within the class glyph.• Some attributes can be hidden for the sake of readability.• OMT and UML use boxes to distinguish the attributes from the

operations.

Class name

Operations( )

Attributes

Class name

Operations( )

Attributes

Booch OMT UML

Class name Attributes Operations( )

Visibility of Attributes and Operations• Visibility rules complement and refine the concept of

encapsulation.• It is possible to customise the degree of protection to the

benefit of a class client by declaring attributes as public, protected or private.

• One of the benefits of breaking encapsulation can be, for example, to reduce the time required to access attributes by making unnecessary to call setters/getters. Could this be a right decision? Class name

+ Public Operation( )# Protected Operation( )- Private Operation( )

+ Public Attribute# Protected Attribute- Private Attribute

Visibility of Attributes and Operations• The three notations encompass public, protected and private

levels of protection.• Booch provides an additional “implementation” level.

Class name

+ Public Operation( )# Protected Operation( )- Private Operation( )

+ Public Attribute# Protected Attribute- Private Attribute

Booch OMT UML

Class name

+ Public Operation( )# Protected Operation( )- Private Operation( )

+ Public Attribute# Protected Attribute- Private Attribute

Class name Public Attribute| Protected Attribute| | Private Attribute Public Operation( )| Protected Operation( )| | | Private Operation( )

Nothing public| protected| | private| | | implementation

Nothing unspecified+ public# protected- private

+ public# protected- private

Relationships: Association• The association relationship expresses a bi-directional,

semantic connection between classes.• An association is an abstraction of the links that exist between

object instances.• It is possible to specify the role of a class within an association.• A role name may be specified on either side of the association.

University StudentDean

Relationships: Association

• In all the three notations, an association is represented by a continuous line between the classes that participate in it.

StudentUniversity

Booch OMT & UML

University Student

Multiplicity• Relationships between classes carry multiplicity information that

specifies the number of instances that participate in the relationship• The table below summarises the most common multiplicity values :

Symbol Meaning1 One and only one0..1 Zero or oneM..N From M to N (natural integers)* From zero to any positive integer0..* From zero to any positive integer1..* From one to any positive integer

University Student1 0..* 1 1

Dean

Multiplicity

• OMT proposes a graphical representation based on circles.• Take care not to confuse these circles with those meaning has

and uses in Booch, as there is no relationship between these two representations.

Booch OMT UML

10..1N3..5, 7, 153..N

10..1*3..5, 7, 153..*

0..1

0..N

3..5

1+

1 by default

Relationships: Aggregation• An aggregation is a particular kind of association that

expresses a stronger coupling between classes.• Aggregation allows the representation of relationships like

“master and slave”, “all and part of” and “composed of and components”.

• It is commonly referred to as a “HasA” (or “HasMany”) relationship.

Car Engine1

1

Relationships: Aggregation• There is no strict equivalence between the Booch, OMT and UML

notations.• As aggregation is concerned, Booch is closer to the design phase,

OMT is closer to the analysis stage, and UML covers both.• 2 cases are illustrated for each design methodology : aggregation

by reference and aggregation by value (same in OMT)

Car Engine

Booch OMT UML

Car EngineCar Engine

Car Engine Car Engine Car Engine

Relationships: Dependency• A dependency is a “loose” association that expresses a weaker

coupling between classes.• Usually dependency shows that a class uses another class

with one way or another, maybe by using the other class’s static methods or by passing objects of the second class’s type to another object of another class.

• It is commonly referred to as a “Uses” relationship.

AssemblerRobot

Car Parts1

1..*

Relationships: Dependency• Booch represents a dependency using an association labelled

with a small circle placed on the client side.• OMT represents a dependency using a dotted arrow with a

filled head.• UML uses a dotted arrow with an open head.• In OMT and UML the arrow points to the supplier – the element

being dependent on.

Robot PartsRobot PartsRobot Parts

Booch OMT UML

Relationships: Inheritance• Inheritance is a technique offered by programming languages to construct

a class from one or more (in C++) classes, sharing attributes, operations and sometimes constraints within a hierarchy of classes.

• A class can specialise, extend, subclass, or be a child of another class.

Shape

Star

is a

Vehicle

Car Bike

Audi BMW Yamaha Suzuki

Relationships: Inheritance• Inheritance propagates the characteristics of the parent class (depending

on their visibility) into the child classes.• It is commonly read as an “IsA” relationship.

Relationships: Inheritance• In all three notations, inheritance is represented using an arrow

that points from the subclass to the superclass.

Vehicle

Car

Bike

Vehicle

Car

Vehicle

Car Bike

Vehicle

CarOr as in OMT

Vehicle

Vehicle

Car

Car Bike

Booch OMT UML

Object Oriented views

• Hierarchy view (usually static) :– classes, interfaces and their relationships.

• Interaction view (usually dynamic) :– objects, method calls, events, messages.

• Modules view :– name spaces, packages-libraries-modules,

classes, and their internal and external dependencies.

Hierarchy View

• Inheritance, • Aggregation,• Uses.

Shape

Rect

draw()toString()setText()

draw()setOrigin()setColor()

Oval

draw()toString()setText()

Line

draw()toString()setText()

Drawable

draw()

TestProgram

main()

is

hasimplements

Relationships :

Interaction View

• Is based on objects and method calls.• Depicts the runtime of the system.

myTestprogram

drawAll()

myVector

elements()

myEnum

*[hasMoreElements()]nextElement()

myShape

draw()

Module View

framework

tools

figures

util

commands

guidomain

• Package Visibility• Package Dependencies

The end of lecture 3