4.1

Object-oriented development approaches

IMS5006 - Information Systems Development Practices

4.2

System development approaches

three basic approaches to systems development:

functionalprocess decomposition is the basis

data used by processes

data-centreddata is the stable basis

process decomposition to define functions

object-orienteddata, process and behaviour combined in one object

“objects” structure the application domain

4.3

Data

Process

Behaviour

These three perspectives are encapsulated within the object.

The three perspectives of an information system

4.4

Object-oriented development is built around the concept of modelling a system in terms of objects

An object encapsulates data, process and behaviour

Programming languages first, then analysis and design

Object-oriented development

4.5

Object-oriented and conventional approaches

Conventional

Object-oriented

Process Database

Data

Process

Data

Process

message

message

The emphasis is on object structure NOT on procedure structure

4.6

Object-oriented approaches

claimed benefits:

“seamless” development process shift of development effort into analysis:

conceptual models, not computer models facilitates reuse increased consistency between analysis, design

and programming activities and models more “natural” modelling of the problem domain a “cleaner” design

4.7

Object-oriented development

An object is a thing (tangible or a concept) that has a well-defined role in the application domain

It has an identity, state and behaviour, and is something to which actions are directed

Its state encompasses its properties (attributes and relationships) and their values

Its behaviour is how it acts and reacts

4.8

Object-oriented development lifecycle

The OO lifecycle consists of progressively developing an object representation through 3 phases:analysis, design and implementation

In the early stages, the model is abstract, focusing on the external qualities of the application As the model evolves, it becomes more detailed, focusing on how the system will be built and how it will

function Focus on front-end conceptual issues, not back-end implementation issues to avoid restricting design

choices

4.9

Analysis: a model of the real-world application abstracting concepts describing what the system must do

Design: System design: overall system architecture, subsystems

(the context for physical design decisions) Object design: add design detail e.g. internal data

structures and algorithms, efficiency tuning, control, associations, module packaging

Implementation: implement design using programming languages, DBMS etc.

Example object-oriented development lifecycle

4.10

Object-oriented notations

Various object-oriented approaches have been proposed with various modelling notations in late 80s and early 90s e.g. Booch’s Booch Method, Rumbaugh et al’s Object Modelling Notation (OMT), Jacobson et al’s Object-oriented Software Engineering (OOSE), Coad and Yourdon’s Object-oriented Analysis (OOA)

Booch, Rumbaugh, Jacobson created a standard modelling language: Unified Modelling Language (UML) with version 1.0 released in 1997

UML is widely-accepted standard for notation

4.11

Object-oriented modelling

Object class diagrams show the static structure of the application domain

Dynamic models represent the dynamic behaviour of the system

Operations represent the processes of the system and are triggered by events

4.12

Object class: group of objects with similar properties, behaviour,

relationships and semantics each object is in one class

(an inherent property of the object) objects have identity: objects are distinct even if all

their attribute values and operations are the same an object has a state and exhibits behaviour through

operations that can examine or inspect its state attribute: a data value held by objects in a class

Object modelling

4.13

Object modelling: class diagrams

Employee

Employee idEmployee nameEmployee addressEmployee D-O-B

Create new employeeChange employee

address

Class name

Operations

Attributes

Object class diagram

Ian Smith: Employee

Employee id = 345Employee name=Ian SmithEmployee address =Caulfield, VicEmployee D-O-B =4/10/64

Object instance diagram

4.14

abstraction encapsulation information hiding polymorphism inheritance messaging

Object Modelling Concepts

4.15

Abstraction in object modelling

hide detail to focus our attention on selected aspects of the system

Identification

Classification Association Generalisation Aggregation

4.16

Classification groups objects into classes group objects based on similarity inherently subjective based on common attributes, behaviour or semantics

for example: Polygon Objects

Polygon Class

Attributes: vertices border-colour fill-colour

Operations: draw erase move

4.17

Association

means of establishing relationships between objects and object classes

group of conceptual links between objects exists independently of objects an association is a group of links with

common structure and semantics describes a set of potential links inherently bi-directional degree may be unary, binary, ternary etc.

4.18

Associations

often implemented as pointers

an association is independent of object classes

Country City

(Country) (City)

(Country) (City)

Australia Canberra

Indonesia Jakarta

name nameClass Diagram

Instance Diagram

Has-capital

Has-capital

Has-capital

4.19

Association

employeeis-assigned

customerplaces

studentenrols-in

multiplicity indicates how many instances participate in the association

parkingpermit

sales order

subject

0..1 0..1

1 1..*

* *

one-to-one

one-to-many

many-to-many

4.20

Association

ternary or higher order associations may be represented

Project Language

Person

(Person)Mary

(Project)Accounting System

(Project)CADprogram

(Language)Cobol

(Language) C++

*

*

*

4.21

Generalisation

group object classes based on similarity powerful abstraction technique for sharing similarities

between classes the class being refined is the “superclass” and each

refined version is a “subclass” each object can have many subclasses and many

superclasses sometimes called the “is-a” or “ako” relationship the generalisation relationship may be specified by a

discriminating attribute: the discriminator

- the basis for the generalisation

4.22

GeneralisationConnector

LocationDiameterLength

displayLocationdisplayDiameterdisplayLengthupstreamPipe

Free Flow Connector Network Connector

openWaterSupply: {abstract}closeWaterSupply: {abstract}

Pump Connector

onoff

Service Outlet Valve ConnectorPermit NumberopenWaterSupplycloseWaterSupply

openWaterSupplycloseWaterSupply

connector type

network connector type

4.23

Inheritance

each subclass is said to inherit the features of its superclass

generalisation and inheritance are transitive across levels (ancestor and descendant)

each subclass not only inherits all features of its ancestors but adds further specific attributes and operations

inheritance is a major benefit of OO derived by implementing generalisation structures

4.24

Use of generalisation

both conceptual modelling and implementation

structuring classes based on similarity and difference

mechanism for inheritance

reuse of library classes

4.25

Disjoint and overlapping subclasses

Disjoint subclasses each instance belongs to exactly one of the subclasses E.g. Hourly-employee, Salaried-employee, Exempt-employee indicated using braces in UML notation Overlapping subclasses each instance can belong to more than one subclass e.g. graduate student, part-time student indicated using braces in UML notation Complete and incomplete subclasses in UML notation this indicates whether additional

subclasses are expected

4.26

all students are either graduate or undergraduate

graduate students may hold one or both types of assistantships

Disjoint and overlapping subclasses

student

graduatestudent

undergraduate student

researchassistant

teachingassistant

student level

assistantship type

{complete, overlapping}

{complete, disjoint}

4.27

where a class has more than one superclass and inherits from all parents

brings greater power to modelling but with loss of conceptual simplicity

Multiple Inheritance

vehicle

landvehicle

watervehicle

amphibious vehicle boatCar

4.28

Aggregation

a grouping of component classes: a “part-of” relationship representing components and

assemblies a special form of association where component classes do

not have independent existence

transitivity:

If A is-part-of B and B is-part-of C

then A is-part-of C anti-symmetric:

If A is-part-of B then B is NOT part-of A

4.29

aggregation

relates an assembly class to ONE component class and allows us to specify multiplicity of each component

Document Paragraph Sentence* *

4.30

Aggregation

Car

DriveSystem

ElectricalSystem

FuelSystem

• • •

Alternator Battery Coil

• • •

1-2

aggregation and generalisation are commonly confusedbecause of the hierarchical nature of both constructs

4.31

Aggregation and Generalisation

aggregation groups unlike instances (AND) generalisation groups similar classes (OR)

Network

ConnectorPipe

Free FlowConnector

NetworkConnector

note: associations betweenPipe and Connector have been omitted

PumpConnector

4.32

Aggregation or Association?

For aggregation:

- would you use the phrase “part of”?

- are some operations on the assembly automatically applied to its parts? E.g. copy document so copy paragraphs

- are some attribute values propagated from the assembly to its parts? E.g. car speed is 60 kph so car door speed is 60 kph

- is there an intrinsic “asymmetry” to the association?

4.33

Encapsulation and Information Hiding

encapsulation and information hiding are often used interchangeably

they are related concepts but not the same

encapsulation is the containment of data and behaviour within an object

information hiding refers to the restricted interface an object offers to its internal workings:

the object “hides” its internal implementation details -

messages are required to access the object’s data or status

4.34

the state of an object includes its properties (attributes and associations) and the values they have: it is determined by its attribute values and links

the behaviour of an object is how it acts and reacts:it is determined by its state and the operation being performed

an operation is a function or transformation that may be applied to or by an object in a class

eg. COMPANY hire, fire, pay-dividend

a method is an implementation of an operation in class

Object states and behaviour

4.35

Polymorphism

polymorphism = “many forms” same operation may behave differently on different classes

An operation may have more than one method implementing it.

The correct method is selected based on the class and operation names.

an operator may have arguments (parameters) methods for same operator must have same signature

(number and type of arguments and type of result value) behaviour of all methods for an operation should have

consistent intent

E.g.print

Picture file

Binary file

4.36

operations are listed in third part of class box can include parameter list and result type $ indicates an operation performed on the whole object

Operation notation

Person

Name: stringAddress: stringAge: integer

change-namechange-address$createPerson

Geometric Object

color: stringposition: point

move (delta:Vector)select (p:point): Booleanrotate (angle)

4.37

Dynamic modelling Characterises temporal nature of system :

describes changes to object classes and relationships over time

Deals with flow of control, interactions and sequences of operations in a system of concurrently active objects (message passing)

Shows object states and events, and operations as actions and activities

Use state diagrams and sequence diagrams

4.38

Scenarios and sequence diagrams

a scenario is a sequence of events that occurs during one particular execution of a system

E.g.

consumer inserts coin ($1)interface displays amount ($1)letter selection button pressed (A)interface displays letter (A)number selection button pressed (1)interface displays number (1)food dispenser dispenses item (A1)

4.39

Sequence diagrams

show the sequence of events and the objects exchanging events

consumer inserts coin ($1)

interface displays amount ($1)

letter selection button pressed (A)

interface displays letter (A)

number selection button pressed (1)

interface displays number (1)

food dispenser dispenses item (A1)

consumer interface food dispenser

4.40

Example state diagram

Idle

Dispensing

Waiting forletter

Waiting fordigit

money Inserted

[letter valid]

[digit valid]

[digit invalid]

[letter invalid]

an event is received from the coin collector (moneyInserted)

the conditions indicate processing within the food dispenser object and not the state of the coin collector.

ButtonPressed (name)

ButtonPressed(name)

4.41

Message passing is the means of communication between objects in an application

A message is passed when an object invokes one or more of another object’s operations to request information or some action

Can create an Object Communication Model Form: operation name (arguments)

Messaging

Food selection panel

Dispenser Coin Slot

dispense(selection) amount paid?

100

E.g. Food Vending Machine

4.42

UML (Uniform Modelling Language)

Major analysis models in UML:

use cases:represent the functional requirements (the “what”) of the system

class diagrams:the static structure of data and operations that act on the data

state diagrams:represent how objects change their states in response to events

sequence diagrams:represent dynamics of of the interactions between objects

4.43

use case: a complete sequence of related actions initiated by an actor

(scenarios) use cases may be extended by or used by another use case

class diagram: models the object classes and their attributes and operations

state diagram: models the states of an object and the events that cause state

transitions

sequence diagrams: shows the passing of messages between objects

UML (Uniform Modelling Language)

4.44

Coad & Yourdon’s OOA five major activities:

1. find class-&-objects

2. identify structures

3. identify subjects

4. define attributes

5. define services

activities may be iterative, and there is no strict sequence

4.45

find class-&-objects: identify object classes that form the core of the applicationidentify structures: organise the classes into generalisation (gen-spec) and aggregation

(whole-part) hierarchiesidentify subjects: group the object model into manageable subject areas to create

subject layer and structure layerdefine attributes: identify data elements of each classdefine services of each class: a service is the operation or processes performed by the object in

response to receipt of a message; service charts specify details

Coad & Yourdon’s OOA

4.46

Advantages of object-oriented approaches reduced semantic gap between models and problem domain

greater semantic richness particularly in the use of inheritance to explicitly represent commonality

re-usability is encouraged: not code libraries but object libraries

“seamless” development and increased consistencyof activities and models: traceability of objects

effect of changes to an object is more localised

message passing convention leads to easier interface descriptions between objects

4.47

References

AVISON, D.E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London.

Chapter 21

HOFFER, J.A., GEORGE, J.F. and VALACICH (1999) 2nd ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts.

Chapter 12

WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed.,

Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY.

Modules A, B