OOAD USING UML

MODULE 1

Dr.D.Jeya Mala,
Associate Prof., Thiagarajar College of Engineering, Madurai.
Why Object-Oriented?

Courtesy : www.utdallas.edu › ~chung › OOAD › M01_OO_Intro

Real World Problems
 highly complex
 cannot be solved by means of laboratory based
simple collection of computational steps.
 Examples of real world problems
 banking applications,
 finance applications,

 trade and commerce based applications,

 medical, telecommunications, embedded applications

and so on.
How to develop them?
 Structured Approach
 simple program development having a sequence of
computational tasks which are accomplished by means
of a collection of algorithms.

 OO Approach
 the solution should be considered as a collection of
interactions among various well defined entities.
OO over Structured
 The paradigm shift now is on the collaboration of
the entities to provide the expected functionality
rather than on how to achieve the functionality.

 This improves
 performance, reliability and availability of the
software;
 extensibility and reusability of the entities in the
problem domain.
Real World Application Development –
Resolving complexity
 Algorithmic Vs. Object Oriented Abstraction

 Algorithmic Vs. Object Oriented Decomposition

 Algorithmic Vs. Object Oriented Hierarchy

Algorithmic Vs. Object Oriented
Abstraction
 Considering only the essential features of the
system by omitting the inessential things is termed as
abstraction.

 An abstraction may be viewed as an entity in

isolation that has a very clear boundary from other
abstractions.

 Some examples may be Class, UseCase, Document,

etc.
Algorithmic Abstraction
 In structured programming approach,
a computational step or an algorithm is considered as
one abstraction.

 These abstractions cannot be easily extended since if a

computational step is modified, this will adversely
affect all the modules depending on it.
OO Abstraction
 In Object oriented approach,
 each object, class, usecase etc. will be considered as
abstractions.

 These abstractions can be easily extended as they

occur as distinct entities in the problem domain.
Algorithmic Vs. Object Oriented
Decomposition
 A problem domain cannot be solved with its present
level of complexity.
 It must be decomposed into several sub systems
which in turn must be divided into sub-subsystems
and then into collection of components and then into
a collection of modules and so on till there are no
further needs for decomposition as the final coarse
of decomposition is reached.
 Usually this final level of decomposition is purely
based on the perspective of the system analyst.
Algorithmic Decomposition
 The system is viewed as a set of computational steps; each
of which is considered as one module in the system.
 Based on that, a top down structured approach is applied.

 Usually, structure charts are used to show this top down

integration of the system functionalities.
 This highlights the order of events. This approach is very
much suitable for structured programming languages and
not well suited for Object Oriented and Object based
languages.
 Also, they are not well suitable for high complex systems.
Algorithmic Decomposition

Employee Pay Roll System

Read Employee details Pay Roll Processing Report Generation

Read Personal Read Pay Details Calculate Grosspay Calculate Netpay Pay Roll Generation Pay Slip
Details Generation

Calculate Allowances Calculate Deductions

Calculate PF Calculate Tax and

other ded
Object Oriented Decomposition
 the entire problem domain is decomposed as a collection of
well defined abstractions.

 visualizes the entire problem domain as

 having a collection of autonomous entities
 which are acting as agents that either causes an action or upon them
the actions are carried out.

 This approach improves the important quality attributes of a

complex system such as reusability, understandability,
extensibility, dependability and reliability measures.
OO Decomposition
 Example : Employee Pay Roll Processing System
 Objects in the system : Employees at various levels,
Administrator, Pay detail for each employee, Pay Slip and
Pay roll and other reports
 Base classes in the system : Person, Employee,
Administrator, Pay Details, Reports
 Support Classes : DB Access, User Interface

 Interfaces : Employee Category, Pay Calculation

 Packages / Name Spaces : Employee Details, Pay Details,

Pay Process, Reports Generation
 Components : Input Data, Process Data, Output Generation
 Folder / Assembly : Pay Roll Process
Algorithmic and Object Oriented
Hierarchy
 Hierarchy helps in ordering of entities in the
problem domain

 Both Algorithmic as well as OO based hierarchy

helps to resolve the complexity of the software.
Algorithmic hierarchy

 Algorithmic hierarchy
 is top down structured and
 is showed as having a collection of subsystems under a
system and further when it is split up, this will be fine
tuned till the primitive components are reached.
 The subsystems collaborate to provide a complete
system.
 Structured Approach

System

Sub System1 Subsystem2 Subsystem3 … Subsystem n

.

Sub-Subsystem1 Sub-Subsystem n Sub-Subsystem1

……………..

Component 1 Component n ……………..

Algorithm 1 Algorithm n ……………..

OO Hierarchy
 OO Hierarchy can be established in two ways
 Object hierarchy - The object hierarchy shows how
objects have values for their properties. It is usually
depicted by ‘part of’ relationship.
 Class hierarchy - The class hierarchy shows how classes
are related with each other and it purely depicts ‘is a’
kind of relationship.
 A typical system, after Object oriented analysis and
design contains both Object hierarchy and Class
hierarchy.
OO Approach
Object Oriented Approach

Object 1 Object n Object 1 Object n Object 1 Object n

Class 1 …. … …. Class 2 …. … …. Class n

Package1/ …. …. Package n /
Namespace 1 Namespace n

Component 1 …. Component n

Folder1/ Assembly1 Folder n / Assembly

n

System
Class Hierarchy Example
Vehicle

Two Wheeler Three Wheeler Four Wheeler

Bicycle Bike Auto Rickshaw Car Bus

OO Hierarchy
Characteristics of OO
 Everything in the system is an object.
 Objects perform computation by making requests of each
other through message passing.
 Every object has its own memory, which may consist of other
objects.
 Every object is an instance of a class.
 A class groups similar objects.
 A class is a repository for behavior associated with an object
 Classes are organized into singly-rooted tree structure, called
an inheritance hierarchy.
Basic entities in Object
Orientation
 Class
 Object
 Attributes
 Methods
 Access Specifiers
 Interface
 Package
 Component
What is a Class?
 A class acts as a logical entity that works as a template for
creating similar kinds of objects.

 It shows the common properties of a collection of objects.

 It usually acts as an abstraction for developing code in Object

Oriented Programming (OOP).

 Some of the real world examples of classes are: Book, Car,

Trainer, Vehicle, Hardware, Country, Flower etc.
What is an Object?

 An object is an instance of a class that has a well

defined collection of behaviors.

 During the life time of an object, it can be in a state

determined by the values of its attributes.

 It persists in a domain unless and until it is deleted.

Object – Definition

 An object is a real world entity that exhibits some

well defined behavior at any point of time. The
behavior of an object is composed of the current
state of its attributes in terms of values and the
operations it performs.
Exercises
 Consider that, you are asked to develop an
application for “Online Airlines Traffic Monitoring
System” Apply both structured approach and object
oriented approach and derive the structure chart
and the various entities in OO. Also, justify how well
OO is suitable in designing such an application.

 You are involved in developing a “Two-Pass

Compiler” for a programming language. Which
approach is suitable to this kind of an application?
Justify your answer.
OOAD USING UML

Dr.D.Jeya Mala
 Object oriented analysis and design with UML

 Deficiency with the traditional approaches

 Lack Formality
 Don’t yield a single consistent model

 OOAD offers
A routine for acquiring understanding
 An approach for recording the relevant information

 A means for validating the developed model

Design phase
 Design: specifying the structure of how a software
system will be written and function, without actually
writing the complete implementation

 a transition from "what" the system must do, to "how"

the system will do it
 What classes will we need to implement a system that meets
our requirements?
 What fields and methods will each class have?
 How will the classes interact with each other?

30
 Visual Modeling
 Visual modeling is the process of taking the information from
real-world process of a computer system and displaying it
graphically using a standard set of graphical elements.
 Benefits
 To easily communicate information between different stakeholders in an
unambiguous way
 To specify target-language-independent designs
 To provide structure for problem solving
 To provide mechanisms (abstractions, views, filtering, structure) to
manage complexity
 To be able to easily experiment to explore multiple solutions
 To be able to build something in virtual form and verify that it works
before committing resources to build the real thing
 Visual Modeling for the Stakeholders
 Users
 Visualize interactions they will make with the system
 Analysts
 Visualize interactions between the various objects from the models
 Developers
 Visualize objects that need to be developed and the functionalities of each of
them
 Testers
 Visualize the interactions between objects and prepare test cases based on
these interactions
 Project managers
 see the entire system and understand how the individual modules interact
 Chief information officers
 Visualize high−level models and see how systems in their organization interact
with one another.
Unified Modeling Language (UML)
 History

 CASE Tools: Automation of Software Development

 People-to-People
 People-to-Computer
 Rational Software (An IBM Company)
 Rational Rose / MS Visio:
Converting UML-Diagrams-to-Programs
 OMG: Object Management Group
History

 Booch: Booch Method

 Rumbaugh: OMT (object modeling tech.)
 Jacobson: OOSE (OO software engrg.)
 Three amigos: UML
History

 UML: an open standard controlled by OMG

 UML 1.0 (1997)
 UML 2.0 (2004)
Meta-Model
 a diagram that defines the notation to be used in
the modeling language
Introduction to UML – Unified
Modeling Language
 UML: pictures of an OO system
 programming languages are not abstract enough for
OO design
 UML is an open standard; lots of companies use it

 What is legal UML?

a descriptive language: rigid formal syntax (like
programming)
 a prescriptive language: shaped by usage and
convention
 it's okay to omit things from UML diagrams if they
aren't needed by team/supervisor/instructor
38
Uses for UML
 as a sketch: to communicate aspects of system
 forward design: doing UML before coding

 backward design: doing UML after coding as documentation

 often done on whiteboard or paper

 used to get rough selective ideas

 as a blueprint: a complete design to be implemented

 sometimes done with CASE (Computer-Aided Software
Engineering) tools
 as a programming language: with the right tools, code can be
auto-generated and executed from UML
 only good if this is faster than coding in a "real" language
39
 UML as an Effective Modeling Tool

 Effective tool for

 Specification
 Visualization

 Construction

 Documenting

 Tools Available
 Rational Rose, Enterprise Architect, Eclipse, Umbrello
UML Modeler, Altova, MagicDraw, Describe and even
Microsoft Visuo.
 Special features of UML
 facilitates re-usable section of the code to be
identified easily and coded with the highest
efficiency
 spots the logic 'holes' in design drawings and hence
ensures that the software will behave as expected
 directs the way in which the software is developed
and hence right decisions are made early on in the
process
 presents an enterprise level, bird’s-eye view of the
entire system and, as a result, competent memory
and processor efficient systems can be designed
 Special features of UML
 supports easy maintenance of the application, by
providing more effective visual representations of
the system which are precisely understood by the
maintenance team
 aids in providing resourceful training to new
members of the development team
 provides an effective medium of communication with
both internal and external stakeholders since it
documents the system much more efficiently
 UML Diagrams
 Class diagram
 Object diagram
 Package diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
 Use case diagram
 Activity diagram
 State-machine diagram
 Sequence diagram
 Communication diagram
 Interaction overview diagram
 Timing diagram
Hierarchical categorization of the UML diagrams
 Support for OOA and OOD
 Models in unambiguous, precise manner
 OOA-OOD
 discovery and documentation of the key classes for a
particular problem domain, interactions, details etc.
 UML Use case diagrams, Class diagrams – great help

 Use-Case driven methods

 Architecture-centric systems
Presence of so many diagrams in UML

 Many stakeholders are involved

 Analysts

 Designers

 Coders

 Testers

 QA

 The Customer
 Technical Authors

 Need different levels of details

 Many viewpoints are involved