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
