Systems modelLing

(COMP1429)

Prepared by Dr. Avgousta Kyriakidou-

Zacharoudiou
Delivered by Dr. Joseph Osunde
By the End of today’s lecture
• Introduction to the Object Oriented (OO) approach

• Key OO principles and concepts

• UML modelling notation

SO FAR…
• SSM helped us “design the problem”.

• We now know some requirements, we have an idea of what we are

going to build…
BUT WHAT NEXT?

• SYSTEMS ANALYSIS AND SPECIFYING REQUIREMENTS: Analysis is

about building a model of the proposed system, operating within its
environment.
• From this model a specification can be derived, which will contain
information about what the new system is intended to do and how it
should operate.

• One way of modelling systems, thus specifying functional

requirements  Object Oriented Systems Analysis and Design
Introducing the OBJECT ORIENTED Approach
OOAD: One technique for analysing, specifying and modelling functional
requirements for a system.

Object oriented Analysis

• Focus is on understanding the problem
• What the system does
• Logical (abstract model): aspects of the system that can be designed
without knowledge of the implementation platform
• Process of investigating and modelling requirements

Dr A.Kyriakidou
Object oriented Design
• Focus is on understanding the solution
• How the system does it
• Physical: aspects of the system that are dependent on the
implementation platform which will be used
• Elaborates the analysis models/diagrams to design models in order to
implement the requirements.

Object oriented Programming: turns the design models into code.

Object oriented analysis and design
• More than 30 years history of OO analysis (late 1980s) (longer
history of OO design and programming).
• There was a need for more coherent means of describing systems which
closely coupled data and behaviour in one object.

• An attempt to put data, process and behaviour back together again.

• By keeping the three elements together, it is easier to model the real
problem domain.
• The analysis (OOA), design (OOD) and programming (OOP) in OO
approaches are fused together.  Better communication between
developers.

• In contrast to SSAD which keeps data and process separate (using

Data flow diagrams and ERDs to model the data).

No longer, as in SSAD, a top-down, divide-and-conquer approach, but

keeping those key elements together in a way that is more closely
attuned to modeling the real problem domain.
Object oriented analysis and design
• The problem area is viewed as objects (things) with certain
characteristics that interact with each other.

• The world is modelled in terms of hierarchies of objects

sharing/inheriting general characteristics, but accommodating the
particular.

• Provides a cleaner and well-integrated model of system behaviour

• Smooths the transition between analysis, design and
programming
• Supports the iterative (repeated cycles) and incremental (in
smaller portions at a time) development process.
• the analysis, design and development happen at repeated cycles
and in smaller portions at a time.
Object oriented analysis and design
Iterative:
Allows analysts to take advantage of what was learned during earlier
analysis.
Any changes made in the specifications can be easily made out without
much overhead.

Incremental:
More frequent checks on how the parts fit together. Confidence that
the project is on the right track.
Goal is to complete a part of the product, but it also allows you to
foresee additional capability, discover errors or extra needs/functions in
the next increment.
 Minimizes the amount of work needed for testing and monitoring.
Diagrams more enriched with information
 more easily can be turned into code
 maintenance is easier.
Object Oriented Object/Class modelling
process
• Identifying objects:
using encapsulation concepts, CRC cards, etc.

• Organising the objects:

classifying the objects identified, so similar objects can later be defined in the same
class

• Identifying relationships between objects:

this helps to determine inputs and outputs of an object

• Defining behaviours (operations) of objects:

the way data is processed within an object

• Defining objects internally:

Information/data held within the objects
But what is an Object?

• OO indented to make thinking about programming closer to

thinking about the real world.
• What is an object in programming we need to ask what is an object
in the real world?

Dr A.Kyriakidou
• Object: a “thing” that is capable of being seen, touched or
sensed and about which users store data and associate
behaviour.
But what is an Object?
BUT WHAT IS A THING?
• Types of objects may include a person, place, tangible things or
event:

Person objects: student, customer, inspector

Dr A.Kyriakidou
Place objects: warehouse, building, room
Things objects: product, vehicle, equipment
Event objects: Order, payment, invoice, reservation, registration,
application, contract

• These things exist within the system’s environment, and equally

within the system.
Objects
recap data and behaviour
• Entities that encapsulate
• about which users store data and associate behaviour
• Have characteristics – inherent properties that describe them
(e.g. a mag can be full or empty, a lamp can be on or of, apple
can be yellow or red)
• these are the attributes of any object, things like colour, size,
weight – describe the current state of an object – state of
one object is independent of the state of the other

type : rectangle number: 12445231 name: John

height: 10 type: current gender: M
width: 20 balance: 1000 dob: 14/09/98
getArea() deposit() walk()
resize() withdraw() run ()

Shape Object Bank Account Object Person Object

Objects
• Objects are not always physical items or visible items e.g. car, house,
product, apple
• A date, a bank account, timer can be an object – they still meet our
idea of object

• Each object has an identity, multiple attributes and behaviour

it can be referred individually
it is distinguishable from other objects
Attributes: a mug can be full or empty, but also black or white
Behaviour: a phone can ring, an airplane can fly , you can deposit in a
bank account or withdrawn.
Identifying an Object

Can you put the word “the” in front of them?

• The mug, the apple, the bank account, the date.

•You wouldn’t say the saving, the printing, those are verbs
behaviours of objects
 Classes
recap
 Objects and classes go hand in hand.
 Cannot talk about one without talking about the other
 OOAD is all about classes because we use classes to create objects

 A class is a blueprint or template or set of instructions used to create a specific

type of object (object instances) - describes what an object will be, but it’s not
the object itself
 A class comes first

 An abstraction specifying the attributes /behaviour of a set of objects

• Each abstraction describes a set of objects with: common properties
(attributes), common behaviour (operations/methods), common
relationships to other objects, and common semantics

 All objects of a given class are identical in structure (attributes) and

behaviour but contain different data in their attributes.
Classes
recap

•A good class captures one and only one abstraction . It should have
one major theme
• E.g. represents a kind of person, place, event or thing about which
the system will need to capture and store information.

•Each object is an instance of some class, and objects cannot be

instances of more than one class
The difference between objects and
classes
A class is a blueprint, or prototype, that defines the attributes and
the methods common to all objects of a certain kind.
Class car:
Attributes: make, colour, type, weight etc.
Behaviour: start_engine(); drive()

Use to make

Class (the blueprint) Objects

UML notation: Class
• Simply represented as a box with class name inside
• which also shows the attributes and operations
• the complete signature of an attribute /operation is:
<attributeName>:<type>
<operationName(parameterName:paramType…)>:<returnType>
Visibility: private (-), public (+), protected (#), or package(~)

BankAccount BankAccount BankAccount BankAccount BankAccount

number deposit() number - number: int

Class name balance withdraw() balance - balance: double

Attributes deposit() + deposit(real)

Behaviour
(operations/methods) withdraw() + withdraw():real
UML Notation: Class
Class
Attributes
Name
Attributes
Operations
Operations

Dr A.Kyriakidou
The concept of dog The concept and some dogs

Dog Rover
Dog Colley
Patch
Name Name Sebastian
Breed Breed Dusk
Run Conker
Run
Fetch
Fetch
The problem with modeling specific instances of a class, and thus individual
objects is that it gets very complex very quickly. And that’s why we model
classes
UML notation: Class Object – Instance of Book

class vs objectsBook : Joebook

title = “Software Engineering”
author = “Pressman”
isbn = “2-5345-53455-6”
publisher = “McGraw and Hill”
price = 40.00

Class getQuantity()
Book get_bookDetails() Object – Instance of Book
set_bookDetails() Book : MariaBook
title: String deletebook()
author : String title = “Computer Science”
isbn: String author = “Sommervile”
publisher: String isbn = “6-5344-534343-4”
price: Real publisher = “Publishing”
getQuantity() price = 35.00
get_bookDetails() getQuantity()
set_bookDetails() get_bookDetails()
deletebook() set_bookDetails()
deletebook()

In classes we don’t define primary and foreign keys. This

goes against the primary principles of object orientation. It’s
not an ERD!
Object Oriented Object/Class principles
• Identity - an object knows who it is
• Classification - an object knows the class it belongs to
classify objects to later create similar objects as needed
• Relationships - an object knows of other objects to interact with
this helps to determine inputs and outputs of an object
• Abstract behaviour – an object performs actions/operations/functions, it
does things, it has a specific behaviour
the way data is processed within an object

To define these, ask questions like:

•What do I need to know to perform my role? (What data do they
(classes) hold?) (attributes)
•What do I need to do in order to be able to perform my role?
What do they (classes) do? (methods)
•Whom do I need to know to perform my role? (How are they
(classes) associated?) (relations/visibility)
Customer:
Product: 2459
Mr. Brown
Or
de Order:Brown1
r2
45 ch?
9 u
m
ow
H

3 00
£

own
00

Dr A.Kyriakidou
3
ӣ

r
wn

r. B
r o
B n”

to M
r. w
M Bro
ill “ M r .
B o

me
t
So ld
een

d
Sen
’veB
u
“Yo

CreditCard: Mr. Brown’s Card Dispatch Object

APIE Object Oriented PRINCIPLES
There are a number of concepts under the OO paradigm that help us
deal with problems.

•OOAD is based on a set of principles that serve to manage and

reduce the complexity of the system.
• APIE - Abstraction, Polymorphism, Inheritance,
Encapsulation

•Abstraction: capture key aspects, ignore irrelevant detail

• Only include relevant and important things in a class
• Supported by two main ideas:
• Information Hiding and Encapsulation
APIE Object Oriented PRINCIPLES
Information Hiding
•A class should hide details of how they are internally
implemented as computer code from other classes.
• Allows for the data (attributes) not to be visible to the outside
world
• thus methods are the ones to allow other objects to access the data
in a controlled fashion.

• Hiding information is useful as it cannot be corrupted by other

classes that are not supposed to use it.

• Clipboard example: we can’t see the information on the other

person’s clipboard. We have to ask for permission to access that
information.
 APIE Object Oriented PRINCIPLES
Encapsulation:
•Combining both attributes and behaviour in a class and hide the non relevant detail at a given
scale.
• If you put data and process together you support abstraction as Objects can be used as building
blocks which can be put together to make the system.
• Encapsulation allows for a more robust model, easier to reuse and easier to maintain
•Example: Object is like an Egg
•Yolk is the data surrounded by the
white which is the methods that act
Shell
on the data. The shell surrounds the whole thing and keeps it together and hides it from the outside
world. The shell is the interface and the only thing that is seen. White

With encapsulation and information hiding, the overhead during maintenance is reduced as youYolk are
certain that when you are fixing a problem inside a class, only that particular class’s code is affected.

•Association: explain events by linking different objects

APIE Object Oriented PRINCIPLES
Inheritance
• generic descriptions of object classes. An object from a more specific
class may inherit the attributes and methods from a more generic
class. Class: Person (Super
type)
Name
Birth date
Gender
Walk()
Jump()
Talk()
Sleep()

Class: Student (Sub Class: Teacher (Sub

type) type)
GPA
Classification Rank
Enroll() Lecture ()
DisplayGPA()
APIE Object Oriented PRINCIPLES

Polymorphism
•general characteristics of a class can be inherited but overridden if
need be.
• Allowing operations of different object classes to have the same
name, whilst the details of the actual operation carried out may be
different.
• E.g. “Close method” a door can “swing shut” a window can “slide
downwards”

•How is polymorphism related to message sending between objects?

• The requesting object knows what behaviour(operation) to request and
from which object but does not need to worry about how that behaviour
is accomplished.
Polymorphism example

PRINT TEXT object

PRINT
30000
25000 BLUE SKY A

GRAPH object
20000 I R L I N E S Sales
Report January
15000
10000
5000 BLUE SKY A
I R L I N E S Sales
0
Report February

Dr A.Kyriakidou
North South East West

PRINT IMAGE object

 Inheritance and polymorphism may improve reuse.

 This reduces design, programming and validation costs.
What is the outcome of OO systems
Analysis?
• The result of system analysis is various system models.

• A model should:
• use a standard notation (we’ll use UML notation)
• be understandable by clients and users
• lead software engineers to have insights about the
system
• provide abstraction
OO Approach: Unified Modelling
Language (UML) models
• UML provides a rich, standardised diagrammatic notation
- For developing a series of system models

• These models will become increasingly less abstract, and more

detailed as the project progresses
- Transition between analysis and design

• UML Not “UMM” A Language, not a methodology It does not

prescribe a method for developing systems – only a notation that is
now widely accepted as a standard for object modelling.

• A CASE tool, provides support for incremental analysis, design,

construction
WHAT UML models?
• The models and associated diagrams we will discuss are:

• Analysis:
• Use-case models - use case diagrams
• Conceptual object model - class diagram

• Design:
• Dynamic models
• Object sequence diagrams
• State transition diagrams
• Design class diagram
UML Models
Use Case Model: Use case diagram
•Drives the analysis - Identifies and describes the system’s functions from
the perspective of the external user, using a tool called use-cases.

•It is intended to provide a high level and user oriented description of a

Dr A.Kyriakidou
system - not any design detail.

•Actor as a role for a person or as a role for an inanimate actor, such as

another system

•Use case as a functional requirement tied to an actor.

• Interaction between them.
• Scenarios explaining the interaction.

•Further elements in the <<includes>> and <<extends>> relationships

UML Models

• Object Model - Class Diagram (Conceptual VS

Design Class diagram)

• Identifies Classes:
• Names

Dr A.Kyriakidou
• Attributes
• Visibility
• Obvious behaviour (methods)

and their relationships - the static structure of a system as it

models the environment within which it operates
UML Models

Dynamic Models:

•Object Sequence Diagram

Representation of the dynamic behaviour
how objects collaborate in the system

Dr A.Kyriakidou
ties together the use case and the class diagrams.
Here the interaction between the classes is discussed (what
messages are being passed and what methods are initiated).

•State transition diagrams

What happens in the life of an object within many use cases. More
detailed view of classes. Helps identify further behaviour of objects.
Which diagram comes first?...
• “Chicken and Egg” dilemma?

• In reality:
• An iterative process

Dr A.Kyriakidou
• Needs Experience
An OO simple process Implementation code:
code classes, their attribute
variables, methods and
visibility variables, UI,
storage etc..

Class Pseudocode

Design class diagrams:
Design classes, their
attributes, operations and
visibility associations
Pseudocode:
Pseudocode classes, their
attribute variables, methods
Class definition
and visibility variables and
method logic

Conceptual class
Start diagrams: Interaction logic/ sequence
Business classes, their
attributes and
associations
Feed operations to classes
Requirements

and visibility/ also new classes

CRC Cards
Feed classes

Start Use Case Diagrams:
External classes
(Actors),external
interactions (Use Cases)
Sequence Diagrams:
Scenatios, interactions
Explode Use between objects, State Chart Diagrams:
cases messages :events, States, transitions
operations, creation, (ebent/action) for each
destruction class
Summary: Key concepts of object orientation

• Puts data, process and behaviour back together.

• Iterative and incremental development, therefore smooth transition

from analysis to design and coding
• Better communication between the development team, not partitioning
of effort.

• Object is a different (stronger) conceptual basis for system

conception, model building and for systems development.
• Not only for storing data, but it acts, it has behaviour)

• Direct focus on managing scale and complexity and support for reuse
(abstraction, information hiding, encapsulation, inheritance etc.)

• Dynamic model but more important dynamic modelling of system in

its environment (Object sequence diagram)
Summary: Key concepts of object orientation
• The Object oriented approach is based on OO languages such as
Smalltalk, Java, C#, or C++ as well as object libraries and components.
• Makes it more suitable for the development of systems that need to be
more interactive and flexible or internet-based systems.

• OO can be used in systems that require quite heavy maintenance

afterwards, as OO approaches allow for easier maintainability.

• OO approach takes for granted ideas such as

• spiral/risk driven approaches
• prototyping, working within and with domain actors,
• reuse and components,
• creeping commitment and phased delivery (producing the right outputs
in the right time)
• working in small and flexible teams.
This approach therefore can be better suited in agile projects.
Conclusion…

• There is no silver bullet to development (Brook 1987).

• There is no one magic solution that could solve every complex

problem.

Dr A.Kyriakidou
• Should decide which approach (OOAD or SSAD) to use based
on the type of system to be built, environment etc.

.
Conclusion…
Remember:
• Despite the advances in information technologies such as
expert systems etc. or the advances in the development
approaches, still the most important asset of an organization
is its manpower, its people, having great and skilled
designers.

• Therefore the best way to develop systems is by “growing”

great designers.
WRAPPING IT UP!
• Object oriented analysis as another way of modelling functional
requirements
• What is an object, what is a class
• Key principles of object orientation – abstraction, information
hiding, encapsulation, association, inheritance, polymorphism.
• Introduced UML and the diagrams we will be discussing in the

Dr A.Kyriakidou
next lectures.

Next week:
Using UML notations to create use case diagrams
Online quiz
• Please access the link below to leave your replies

PollEv.com/josephosunde966
Readings for this week’s lecture
Readings on object oriented analysis and UML
Sommerville (2016) – Chapters on Object Orientation and UML
Or

Bennet St, McRobb S, Farmer R (2010) - Object-Oriented Systems

Analysis and Design Using UML

Interesting article on Object Orientation (to access from Moodle)

Fichman and Kemerer (2012):Adoption of Software Engineering
Process Innovations: The Case of Object Orientation