1

Object Oriented Analysis and

Design
 A Brief History 2
The object-oriented paradigm took its shape from the initial concept of a new
programming approach, while the interest in design and analysis methods came much
later.
 The first object–oriented language was Simula (Simulation of real systems) that was
developed in 1960 by researchers at the Norwegian Computing Center.
 In 1970, Alan Kay and his research group at Xerox PARK created a personal computer
named Dynabook and the first pure object-oriented programming language (OOPL) -
Smalltalk, for programming the Dynabook.
 In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainly
presented a design for the programming language, Ada. In the ensuing editions, he
extended his ideas to a complete object–oriented design method.
 In the 1990s, Coad incorporated behavioral ideas to object-oriented methods. The
other significant innovations were Object Modelling Techniques (OMT) by James
Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson.
Object-Oriented Analysis 3
 Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s object
model, which comprises of interacting objects.
 The main difference between object-oriented analysis and other forms of analysis is that in
object-oriented approach, requirements are organized around objects, which integrate both
data and functions. They are modelled after real-world objects that the system interacts with. In
traditional analysis methodologies, the two aspects - functions and data - are considered
separately.
 Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that
examines requirements from the perspective of the classes and objects found in the vocabulary
of the problem domain”.
 The primary tasks in object-oriented analysis (OOA) are:
 Identifying objects
 Organizing the objects by creating object model diagram
 Defining the internals of the objects, or object attributes
 Defining the behavior of the objects, i.e., object actions
 Describing how the objects interact
The common models used in OOA are use cases and object models.
 Object-Oriented Design 4
 Object–Oriented Design (OOD) involves the implementation of the conceptual model
produced during object-oriented analysis. In OOD, concepts in the analysis model, which are
technology−independent, are mapped onto implementing classes, constraints are identified
and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed
description of how the system is to be built on concrete technologies.

 Grady Booch has defined object-oriented design as “a method of design encompassing the process of
object-oriented decomposition and a notation for depicting both logical and physical as well as static
and dynamic models of the system under design”.

 The implementation details generally include:

 Restructuring the class data (if necessary),
 Implementation of methods, i.e., internal data structures and algorithms
 Implementation of control
 Implementation of associations.
Object-Oriented Programming 5

 Object-oriented programming (OOP) is a programming paradigm based upon objects (having both
data and methods) that aims to incorporate the advantages of modularity and reusability.
 Objects, which are usually instances of classes, are used to interact with one another to design
applications and computer programs.
 Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi, C#, Perl,
Python, Ruby, and PHP.
 Grady Booch has defined object–oriented programming as “a method of implementation in which
programs are organized as cooperative collections of objects, each of which represents an instance of
some class, and whose classes are all members of a hierarchy of classes united via inheritance
relationships”.
 The important features of object–oriented programming are:
 Bottom–up approach in program design
 Programs organized around objects, grouped in classes
 Focus on data with methods to operate upon object’s data
 Interaction between objects through functions
 Reusability of design through creation of new classes by adding features to existing classes.
Three Models 6

 Class Model
 State model and
 Interaction model
Class-Object Model 7

 The concepts of objects and classes are intrinsically linked with each other and form
the foundation of object–oriented paradigm.
 Object
An object is a real-world element in an object–oriented environment that may have
a physical or a conceptual existence. Each object has:
 Identity that distinguishes it from other objects in the system.
 State that determines the characteristic properties of an object as well as the values of the
properties that the object holds.
 Behavior that represents externally visible activities performed by an object in terms of
changes in its state.
Objects can be modelled according to the needs of the application. An object may have a
physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a
project, a process, etc.
 Conti.

 Class 8
A class represents a collection of objects having same characteristic properties that
exhibit common behavior. It gives the blueprint or description of the objects that can be
created from it. Creation of an object as a member of a class is called instantiation.
Thus, object is an instance of a class.
The constituents of a class are:
 A set of attributes for the objects that are to be instantiated from the class. Generally,
different objects of a class have some difference in the values of the attributes. Attributes
are often referred as class data.
 A set of operations that portray the behavior of the objects of the class. Operations are
also referred as functions or methods.
 Conti.

 Phase of OMT 9
The OMT methodology covers the full software development life cycle. The methodology
has the following phase.
Analysis: Analysis is the first phase of OMT methodology. The aim of analysis phase is to
build a model of the real world situation to show its important properties and domain. This
phase is concerned with preparation of precise and correct modeling of the real world
System design: System design phase determines the overall system Architecture. During
system design, the high level structure of the system is designed.
Object design: Object design is concerned with fully classifying the existing and
remaining classes, associations, attributes and operations necessary for implementing a
solution to the problem
Implementation: Implementation phase of the OMT is a matter of translating the design
in to a programming language constructs. It is important to have good software
engineering practice so that the design phase is smoothly translated in to the
implementation phase
State model 10
 Some Domain objects pass through connected distinct states and each state
has different constraints and Association or multiplicities
 The state diagram describes the various states that object can assume and
their properties and Constraints in all and the events take in each state.

 Domain State Model Steps

 First -Identify the Domain class with states
 Second -Find the states
 Third -Find events
 Fourth -Build State diagrams
 Fifth -Evaluate state diagrams
 Interaction Model
11
 An interaction Model shows an interaction, consisting of a set of objects
and their relationships, including the messages that may be dispatched
among them
 Interaction diagrams commonly contain Objects, Links, Messages
 Interaction diagrams are used to model the dynamic aspects of a system
 An interaction diagram is basically a projection of the elements found in
an interaction.
 Interaction Model also represent by Use case Models, sequence models,
activity models
The software development life-cycle (ISO
12207)
 ISO(International Organization for
Standardization ) 12207 life-cycle
Requirements analysis

 This is finding out in detail what the users require of the system that the project is to
implement. Some work along these lines will almost certainly have been carried out
when the project was evaluated but now the original information obtained needs to
be updated and supplemented. Several different approaches to the users'
requirements may be explored. For example, a small system that satisfies some, but
not all, of the users' needs at a low price may be compared to a system with more
functions but at a higher price.
 Architecture design
 Based on system requirements
 Defines components of system: hardware, software, organizational
 Software requirements will come out of this
 Detailed Design
 Each software component is made-up of a number of software units that can be separately
coded and tested
 Code and test
 Refers to writing code for each software unit.
 Initial testing to debug individual software units would be carried out at this stage.
 Integration
 The components are tested together to see if they meet the overall requirements .
 Integration could involve combining various software components , or combining and testing the
software element of the system in conjunction with the hardware platforms and user interactions.
 Qualification testing
 The system , including the software components, has to be tested carefully to ensure that all the
requirements have been fulfilled.
 Installation
 The process of making the system operational
 Includes setting up standing data, setting system parameters, installing on operational hardware
platforms, user training etc
 Acceptance support
 This is the resolving of problems with the newly installed systems including the correction of any
errors, and implementing agreed extensions and improvements.
Waterfall Model

 The Waterfall Model was first Process Model to be introduced.

 It is also referred to as a linear-sequential life cycle model.
 It is very simple to understand and use.
 In a waterfall model, each phase must be completed fully before
the next phase can begin.
 This type of software development model is basically used for the for
the project which is small and there are no uncertain requirements.
 At the end of each phase, a review takes place to determine if the
project is on the right path and whether or not to continue or
discard the project.
 In this model software testing starts only after the development is
complete.
Advantages of waterfall model:

 This model is simple and easy to understand and use.

 It is easy to manage due to the rigidity of the model – each phase
has specific deliverables and a review process.
 In this model phases are processed and completed one at a time.
Phases do not overlap.
 Waterfall model works well for smaller projects where requirements
are very well understood.
Disadvantages of waterfall model:

 Once an application is in the testing stage, it is very difficult to go

back and change something that was not well-thought out in the
concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate
to high risk of changing.
When to use

 This model is used only when the requirements are very well known,
clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.
Spiral Model

 The spiral model is similar to the incremental model, with more

emphasis placed on risk analysis.
 The spiral model has four phases: Planning, Risk Analysis, Engineering
and Evaluation.
 A software project repeatedly passes through these phases in
iterations (called Spirals in this model).
 The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the
baseline spiral.
Advantages

 Easier to cope with the changes inherent to software development

 Software engineers can start working on the project earlier rather
than wading through a lengthy early design process.
Disadvantages

 Estimates of budget and time are harder to judge at the beginning

of the project since the requirements evolve through the process
Software Prototyping

 The basic idea in Prototype model is that instead of freezing the

requirements before a design or coding can proceed, a throwaway
prototype is built to understand the requirements.
 This prototype is developed based on the currently known
requirements.
 Prototype model is a software development model.
 By using this prototype, the client can get an “actual feel” of the
system, since the interactions with prototype can enable the client
to better understand the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems
for which there is no manual process or existing system to help
determining the requirements.
Advantages of Prototype model:

 Users are actively involved in the development

 Since in this methodology a working model of the system is
provided, the users get a better understanding of the system being
developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily.
Disadvantages of Prototype model:

 Practically, this methodology may increase the complexity of the

system as scope of the system may expand beyond original plans.
Incremental model
 Incremental Model is combination of one or more Waterfall
Models.

 In Incremental Model, Project requirements are divided into

multiple modules and each module is developed separately.

 Finally developed modules are integrated with other

modules.

 During development of each module, waterfall model is

followed for each module development separately.
 Each developed module in Incremental Model is standalone
feature and could be delivered to the end users to use it.
 As each module is standalone application and there is no
dependencies on other modules so we can deliver the project with
initial developed feature and other features could be added on
incremental basis with new releases.
Advantages of Incremental model:

 Generates working software quickly and early during the software

life cycle.

 It is easier to test and debug during a smaller iteration.

 In this model customer can respond to each built.
 Easier to manage risk.
Disadvantages of Incremental
model:
 Needs good planning and design.

 Total cost is higher than waterfall.

Dynamic System Development
Method (DSDM)
 The Dynamic System Development Method (DSDM) is
dynamic as it is a Rapid Application Development method
that uses incremental prototyping.

 This method is particularly useful for the systems to be

developed in short time span and where the requirements
cannot be frozen at the start of the application building.

 Whatever requirements are known at a time, design for them

is prepared and design is developed and incorporated into
system.
 In Dynamic System Development Method (DSDM), analysis,
design and development phase can overlap.

 Like at one time some people will be working on some new

requirements while some will be developing something for the
system.

 In Dynamic System Development Method (DSDM),

requirements evolve with time.
 DSDM Model Limitations

 It is a relatively new model. It is not very common. So it is difficult to

understand.
 DSDM Model Advantages

 Active user participation throughout the life of the project and

iterative nature of development improves quality of the
product.

 DSDM ensures rapid deliveries.

 What is UML?

• The UML stands for Unified modeling language.

• It is used for specifying, visualizing, constructing, and documenting the primary
artifacts of the software system.
• The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James
Rumbaugh .
• The Object Management Group (OMG) is an association of several companies that
controls the open standard UML.
 Object Inheritance

Conceptua
Class Polymorphism
l Modelling

Abstraction Encapsulation
 OO Analysis and Design

Step 1: Step 2: Step 3

OO OO OO
Design Implementation
Analysis
 UML-Building Blocks

Things Relationshi Diagrams

ps
USE CASE
DIAGRAM
USE CASE DIAGRAM

 A UML use case diagram is the primary form of system/software

requirements for a new software program underdeveloped.
 Use cases specify the expected behavior (what), and not the exact
method of making it happen (how).
 Use cases once specified can be denoted both textual and visual
representation (i.e. use case diagram).
 A key concept of use case modeling is that it helps us design a
system from the end user's perspective.
 It is an effective technique for communicating system behavior in
the user's terms by specifying all externally visible system behavior.
Origin of Use Case

 These days use case modeling is often associated with UML,

although it has been introduced before UML existed. Its brief history
is as follow:
 In 1986, Ivar Jacobson first formulated textual and visual
modeling techniques for specifying use cases.
 In 1992 his co-authored book Object-Oriented Software Engineering
- A Use Case Driven Approach helped to popularize the technique
for capturing functional requirements, especially in software
development.
Purpose of Use Case Diagram

 Specify the context of a system

 Capture the requirements of a system
 Validate a systems architecture
 Drive implementation and generate test cases
 Developed by analysts together with domain experts
Actor
 Someone interacts with use case (system function).
 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user can play different
roles
 For example:
 A prof. can be instructor and also researcher
 plays 2 roles with two systems
 Actor triggers use case(s).
 Actor has a responsibility toward the system (inputs), and
Actor has expectations from the system (outputs).
Use Case

 System function (process - automated or manual)

 Named by verb + Noun (or Noun Phrase).
 i.e. Do something
 Each Actor must be linked to a use case, while
some use cases may not be linked to actors.
Communication Link

 The participation of an actor in a use case is shown

by connecting an actor to a use case by a solid link.
 Actors may be connected to use cases by
associations, indicating that the actor and the use
case communicate with one another using
messages.
Boundary of system

 The system boundary is potentially the entire system as

defined in the requirements document.
 For large and complex systems, each module may be
the system boundary.
 For example, for an ERP system for an organization, each
of the modules such as personnel, payroll, accounting,
etc.
 can form a system boundary for use cases specific to
each of these business functions.
 The entire system can span all of these modules
depicting the overall system boundary
Include
 When a use case is depicted as using the functionality of
another use case, the relationship between the use cases is
named as include or uses relationship.
 A use case includes the functionality described in another
use case as a part of its business process flow.
 A uses relationship from base use case to child use case
indicates that an instance of the base use case will include
the behavior as specified in the child use case.
 An include relationship is depicted with a directed arrow
having a dotted line. The tip of arrowhead points to the
child use case and the parent use case connected at the
base of the arrow.
 The stereotype "<<include>>" identifies the relationship as
an include relationship.
 Extends
 Indicates that an "Invalid Password" use case may
include (subject to specified in the extension) the
behavior specified by base use case "Login Account".
 Depict with a directed arrow having a dotted line. The
tip of arrowhead points to the base use case and the
child use case is connected at the base of the arrow.
 The stereotype "<<extends>>" identifies as an extend
relationship
Generalization
 A generalization relationship is a parent-child
relationship between use cases.
 The child use case is an enhancement of the parent
use case.
 Generalization is shown as a directed arrow with a
triangle arrowhead.
 The child use case is connected at the base of the
arrow. The tip of the arrow is connected to the
parent use case.
Class Diagram
Class

 A description of a group of objects all with similar roles in the system,

which consists of:
 Structural features (attributes) define what objects of the class
"know"
 Represent the state of an object of the class
 Are descriptions of the structural or static features of a class
 Behavioral features (operations) define what objects of the class
"can do"
 Define the way in which objects may interact
 Operations are descriptions of behavioral or dynamic features of a class
 Class Notation
 Class Name
 The name of the class appears in the first partition.
 Class Attributes
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
 Class Operations
 Operations are shown in the third partition. They are services the
class provides.
 The return type of a method is shown after the colon at the end of
the method signature.
 The return type of method parameters is shown after the colon
following the parameter name.
 Operations map onto class methods in code
Class Relationships

 Inheritance (or Generalization):

•Represents an "is-a" relationship.

•An abstract class name is shown in italics.
•SubClass1 and SubClass2 are specializations of Super
Class.
•A solid line with a hollow arrowhead that point from the
child to the parent class
Simple Association:

•A structural link between two peer classes.

•There is an association between Class1 and Class2
•A solid line connecting two classes
 Aggregation:

A special type of association. It represents a "part of"

relationship.
•Class2 is part of Class1.
•Many instances (denoted by the *) of Class2 can be
associated with Class1.
•Objects of Class1 and Class2 have separate lifetimes.
•A solid line with an unfilled diamond at the association end
connected to the class of composite
 Composition:

A special type of aggregation where parts are destroyed when

the whole is destroyed.
•Objects of Class2 live and die with Class1.
•Class2 cannot stand by itself.
•A solid line with a filled diamond at the association connected to
the class of composite
 Dependency:

•Exists between two classes if the changes to the definition of one may cause changes to
the other (but not the other way around).
•Class1 depends on Class2
•A dashed line with an open arrow