SWE2018 -Object Oriented Analysis

and Design

Faculty : R KIRUBA THANGAM

Winter 2016-17

SWE2018_Winter 2016 1 Faculty:R.Kiruba Thangam

 Introduction

Structure of Complex Systems, Decomposing

Complexity - Elements of Analysis and Design,
Object Modeling - Unified Process - Phases of
Unified Process Benefits and Risks of Object
Oriented Development

SWE2018_WintEr 2016 2 Faculty:R.KiRuba thangam

 Simple Vs Complex Software
Simple Software:
Specified
Constructed and Maintained
Used by the same person
Have a very limited purpose and a very short life
span
Eg: Lab exercises of students
Develop a library management system using
Rational-Rose
TCP Socket Programming
SWE2018_WintEr 2016 3 Faculty:R.KiRuba thangam
 Complex Software(Industrial-
strength software )
Exhibit a very rich set of behaviors
(Heterogeneous)
Dynamic and reactive to physical events
Maintain the integrity of 100s of 1000s of
records of information
Concurrent updates and queries
Long life span

SWE2018_WintEr 2016 4 Faculty:R.KiRuba thangam

 Why Software Is Inherently Complex

Inherent complexity derives from four elements

1.The complexity of the problem domain
2.The difficulty of managing the
developmental process
3.The flexibility possible through software
4.The problems of characterizing the
behaviour of discrete systems

SWE2018_WintEr 2016 5 Faculty:R.KiRuba thangam

 Complexity of problem domain

It involves inescapable complexity.

It involves contradictory requirement
For e.g system of multiengine aircraft,
cellular phone
switching system or autonomous robot. The
functionality of such system is difficult.

SWE2018_WintEr 2016 6 Faculty:R.KiRuba thangam

 The Complexity of the Problem
Domain
Complexity of the elements involved
Perceptual view of requirements
Impedance mismatch between users and
developers
Presence of competing or contradictory
requirements
Dynamic requirements change

SWE2018_WintEr 2016 7 Faculty:R.KiRuba thangam

 The Complexity of the Problem
Domain
In large software system we must have
Maintenance to correct errors
Evolution - respond to changing requirements
Preservation - keep an ancient and decaying
piece of software in operation

SWE2018_WintEr 2016 8 Faculty:R.KiRuba thangam

SWE2018_WintEr 2016 9 Faculty:R.KiRuba thangam
 The Difficulty of managing the
development process
The fundamental task of software
development team is to engineer the illusion
of simplicity

SWE2018_WintEr 2016 10 Faculty:R.KiRuba thangam

 Difficulty of managing the
development process

Hiding the underlying software complexity

Presence of multiple languages, platforms,
processes, architectures, and tools
Heterogeneity

SWE2018_WintEr 2016 11 Faculty:R.KiRuba thangam

 Difficulty of managing the
development process
Making use of powerful mechanisms, reusing
frame-works of existing designs and code
Avoid Issues of scalability Size up, Speed up,
Scale up
To maintain unity and integrity of design

SWE2018_WintEr 2016 12 Faculty:R.KiRuba thangam

 Flexibility possible through Software
Software offers the ultimate flexibility
So developer can express almost any kind of
abstraction
Uniform building codes and standards for the
quality must be adopted.
Software development remains labor
intensive business.

SWE2018_WintEr 2016 13 Faculty:R.KiRuba thangam

 The Problems of Characterizing the
Behaviour of Discrete Systems

Digital computers
we use a system with discrete states, Non-
continuous behaviour of discrete systems
Unfortunate behaviour from unexpected
external events
Lack of mathematical tools and intellectual
capacity to model the behaviour of large
discrete systems
SWE2018_WintEr 2016 14 Faculty:R.KiRuba thangam
SWE2018_WintEr 2016 15 Faculty:R.KiRuba thangam
 The five attributes of Complex
Systems
Hierarchic structure
Relative Primitives
Seperation of Concerns
Common patterns
Stable Intermediate Forms

SWE2018_WintEr 2016 16 Faculty:R.KiRuba thangam

 Hierarchic structure
Hierarchy systems are usually composed of
only a few different kinds of subsystems in
various combinations and arrangements.

SWE2018_WintEr 2016 17 Faculty:R.KiRuba thangam

 Hierarchic structure
A complex system is composed of
Interrelated subsystem that have in turn their own
subsystem and so on, until some lowest level of
elementary components is received.

SWE2018_WintEr 2016 18 Faculty:R.KiRuba thangam

 Relative Primitives

The choice of what components in a system are

primitive is relatively arbitrary and is largely up to
the discretion of the observer system.

What is primitive for one observer may be at a much

higher level of abstraction for another.

SWE2018_WintEr 2016 19 Faculty:R.KiRuba thangam

 Seperation of Concerns

Hierarchic systems decomposable because they can

be divided into identifiable parts.

Intracomponent linkages are generally stronger

than intercomponent linkages .
Seperating the high frequency dynamics of the
components-Involving the internal structure of
the components-from the low frequency
dynamics-involving interaction among
components.

SWE2018_WintEr 2016 20 Faculty:R.KiRuba thangam

 Seperation of Concerns

The difference between intra-and inter

component interactions provide a clear
seperation of concerns among various parts of
system making it possible to study each part in
relative isolation.

SWE2018_WintEr 2016 21 Faculty:R.KiRuba thangam

 Common patterns

Hierarchic systems are usually composed of

only afew different kinds of subsystems in
various combinations and arrangements.
Complex systems have common patterns.
Patterns involve the reuse of small components.

SWE2018_WintEr 2016 22 Faculty:R.KiRuba thangam

 Stable Intermediate Forms
Complex systems will evolve from simple
systems much more rapidly if there are stable
intermediate forms than if there are not.

SWE2018_WintEr 2016 23 Faculty:R.KiRuba thangam

 Stable Intermediate Forms
The complex system that works is invariably
found to have evolved from a simple system that
worked.
A complex system designed from a scratch
never works and cannot be patched up to make
it work.

Start working with simple systems

SWE2018_WintEr 2016 24 Faculty:R.KiRuba thangam

 Canonical form of a complex system

SWE2018_WintEr 2016 25 Faculty:R.KiRuba thangam

 Canonical form of a complex system

SWE2018_WintEr 2016 26 Faculty:R.KiRuba thangam

 Decomposing complexity

When designing a complex software system it is

essential to decompose it into smaller and
smaller parts.

Each of these smaller parts may then refine

independently

SWE2018_WintEr 2016 27 Faculty:R.KiRuba thangam

 Algorithmic Decomposition

Top down structural design

By algorithms
Highlights the ordering of events
We approach decomposition as a simple matter
of algorithmic decomposistion.
Each module in the system denotes some major
step in some overall process.

SWE2018_WintEr 2016 28 Faculty:R.KiRuba thangam

 Algorithmic Decomposition

SWE2018_WintEr 2016 29 Faculty:R.KiRuba thangam

 Object oriented decomposition

Alternate Decomposition
Emphasizes the agents that either cause actions.
Based on the key abstractions in the problem
domain rather than decomposing the problem into
steps such as Getformatted update and add
checksum.
Objects are identified such as master file and check
sum which derive directly from the vocabulary of
the problem domain.

SWE2018_WintEr 2016 30 Faculty:R.KiRuba thangam

 Object oriented decomposition

SWE2018_WintEr 2016 31 Faculty:R.KiRuba thangam

 Object oriented decomposition

We view world as a set of autonomous agents

that collaborate to perform some higher level
behaviour.

Object-tangible entity-well defined behavior

SWE2018_WintEr 2016 32 Faculty:R.KiRuba thangam

 Advantages of Object oriented
decomposition
Reduces risk
Resilient to change
Reduces the risk of building complex
software system

SWE2018_WintEr 2016 33 Faculty:R.KiRuba thangam

 Elements of analysis and design

System involve incremental and iterative process

Notation: The language for expressing each
model
Process: The activities leading to the orderly
construction of
the system model
Tools: The artifacts that eliminate the
tediousness of model
building and enforcing rules about the models
themselves, so
that errors and inconsistencies can be expressed.

SWE2018_WintEr 2016 34 Faculty:R.KiRuba thangam

 Elements of analysis and design

System involve incremental and iterative

process
Notation: The language for expressing each
model.
Process: The activities leading to the orderly
construction of the system model.
Tools: The artifacts that eliminate the
tediousness of model building and enforcing
rules about the models themselves, so that
errors and inconsistencies can be expressed.
SWE2018_WintEr 2016 35 Faculty:R.KiRuba thangam
 Benefits of object model

The main advantage of object oriented system is

that you can build on what you already have.
Reuse code and develop more maintainable
systems in a shorter amount of time.
The use of the object model produces systems
that are build upon stable Intermediate form
which is easy to change.

SWE2018_WintEr 2016 36 Faculty:R.KiRuba thangam

 Object
It represents entity the entities are as follows:
Physical entity
Conceptual entity
Software entity
An object is an entity with well defined boundary
and identify that encapsulate state and
behaviour.
state is represented by attribute relationship .
Behaviour is represented by operations, methods
and
state machine.
SWE2018_WintEr 2016 37 Faculty:R.KiRuba thangam
 An object is a real world element each object
has
Identity that distinguishes from other objects
in the system
State It determines characteristic properties
of an object.
Behaviour that represents externally visible
activities

SWE2018_WintEr 2016 38 Faculty:R.KiRuba thangam

 Object oriented programming

Object oriented programming is a method of

implementation in which programs are
organized as a co-operative collection of
objects, each of which represent instance of
some class and whose classes are all
members.

SWE2018_WintEr 2016 39 Faculty:R.KiRuba thangam

 Object Oriented Design and Programming

OOD Major proponents and developers

Grady Booch, Ivar Jacobson, and James Rumbaugh
Unified Modelling Language (UML)
OOP Several OOP languages
Smalltalk, Eiffel. Pure OOPL
C++, Java. Said to be object based OOPL

SWE2018_WintEr 2016 40 Faculty:R.KiRuba thangam

 Software Tools
Object Oriented Programming (OOP)
C++
Using Microsoft Visual C++ compiler
Object Oriented Design (OOD)
UML (Unified Modelling Language)
Rational Rose UML visual modelling tool

SWE2018_WintEr 2016 41 Faculty:R.KiRuba thangam

 Elements of Object model
Procedure Oriented
Object Oriented
Logic Oriented
Rule Oriented
Constraint Oriented

SWE2018_WintEr 2016 42 Faculty:R.KiRuba thangam

 Four major elements
Abstraction
Encapsulation
Modularity
Hierarchy

SWE2018_WintEr 2016 43 Faculty:R.KiRuba thangam

 Abstraction

Helps to deal with

complexity by focusing
on certain features and
suppressing others.
Focus on interface
(outside view)
Separate behaviour from
implementation

SWE2018_Winter 2016 44 Faculty:R.Kiruba Thangam

 Abstraction
Essential characteristics of an object that
distinguish it from all other kinds of objects
Provide crisply defined conceptual boundaries,
relative to the perspective of the viewer.

SWE2018_WintEr 2016 45 Faculty:R.KiRuba thangam

 Abstraction
Focuses on the outside view of an object and so
serves to separate an object s essential
behaviour from its implementation.

SWE2018_WintEr 2016 46 Faculty:R.KiRuba thangam

 Abstraction
Entity abstraction
Action abstraction
Virtual machine abstraction
Coincidental abstraction

SWE2018_WintEr 2016 47 Faculty:R.KiRuba thangam

 Examples

SWE2018_WintEr 2016 48 Faculty:R.KiRuba thangam

 Examples

SWE2018_WintEr 2016 49 Faculty:R.KiRuba thangam

 Examples

SWE2018_WintEr 2016 50 Faculty:R.KiRuba thangam

 Encapsulation
Abstraction and Encapsulation are
complementary concepts.

Abstraction-observable behaviour of an object.

Encapsulation-Implementation that give rise to
this behaviour.

SWE2018_WintEr 2016 51 Faculty:R.KiRuba thangam

 Encapsulation
Achieved through information hiding
Hiding all secrets of an object that do not
contribute to its essential characteristics.
Structure of an object is hidden and
Implementation of its methods.

SWE2018_WintEr 2016 52 Faculty:R.KiRuba Thangam

 Encapsulation
Abstration ---Helps people to think about what
they are doing

Encapsulation ---Allows program changes to

be reliably made with limited effort

SWE2018_WintEr 2016 53 Faculty:R.KiRuba thangam

 Encapsulation
It provides explicit barriers among different
abstractions and thus leads to clear seperation of
concerns.

SWE2018_WintEr 2016 54 Faculty:R.KiRuba thangam

 Encapsulation

Also known as
information hiding
Hides the details of the
implementation
Complementary to
abstraction

SWE2018_Winter 2016 55 Faculty:R.Kiruba Thangam

SWE2018_WintEr 2016 56 Faculty:R.KiRuba thangam
 Abstraction, Encapsulation and Software
Design

Interface should be simple,

providing the required
behaviour.
User is presented with high
level abstract view. The detail
of the implementation is
hidden from the user.
The designer may change the
implementation keeping the
interface the same.

SWE2018_Winter 2016 57 Faculty:R.Kiruba Thangam

 Modularity
A common Divide and
conquer approach
Partitions a problem into sub-
problems reducing complexity
Modularity packages
abstractions into discrete units
In C++ classes are the basic
modules providing
encapsulation and abstraction

SWE2018_Winter 2016 58 Faculty:R.Kiruba Thangam

 Modularity
Partitioning a program into individual
components can reduce its complexity to some
degree.

SWE2018_WintEr 2016 59 Faculty:R.KiRuba thangam

 Modularity
Modularization consists of dividing a program
into modules which can be compiled seperately.

SWE2018_WintEr 2016 60 Faculty:R.KiRuba thangam

 Hierarchy

A way of ordering
abstractions
Object hierarchical
abstractions (HAS A or
PART OF relationship)
Interfaces and behaviours
at each level
Higher levels are more
abstract

SWE2018_Winter 2016 61 Faculty:R.Kiruba Thangam

 Hierarchy

SWE2018_WintEr 2016 62 Faculty:R.KiRuba thangam

 Hierarchy

SWE2018_WintEr 2016 63 Faculty:R.KiRuba thangam

 Hierarchy

SWE2018_WintEr 2016 64 Faculty:R.KiRuba thangam

 Three minor elements
Typing (language dependent data typing)
Concurrency (OS dependent)
Persistence

SWE2018_WintEr 2016 65 Faculty:R.KiRuba thangam

 Typing

It is a precise characterization of structural or

behavioral properties which a collection of all
entities share without type checking the program
in most languages can crash at runtime.
In most systems the edit-compile-debug cycle is
so tedious that early error detection is
indispensable.
Type declaration helps to document the program.
Most compilers can generate more efficient
object code if types are declared
SWE2018_WintEr 2016 66 Faculty:R.KiRuba thangam
 Typing

SWE2018_WintEr 2016 67 Faculty:R.KiRuba thangam

 Typing
Static binding: are early binding which means
all variables and expressions are fixed.
Dynamic binding : means the type of all
variables and expressions are not known until
runtime.

SWE2018_WintEr 2016 68 Faculty:R.KiRuba thangam

 Concurrency

SWE2018_WintEr 2016 69 Faculty:R.KiRuba thangam

 Persistence

SWE2018_WintEr 2016 70 Faculty:R.KiRuba thangam

 Persistence

SWE2018_WintEr 2016 71 Faculty:R.KiRuba thangam