UNIT-1

To define object-oriented analysis we must first define what we mean by

an object. The definition of an object, according to most dictionaries, is “a
tangible, material thing.” Drilling down a bit more to the realm of computer
science, an object can be most anything in a programmatic sense, from a
variable or data model to a function, class, or method. Moving even deeper into
the realm of object-oriented programming, an object is an instance of a thing
that typically represents a real world object and has all the same types of
characteristics (properties), behaviours (methods), and states (data). When
discussing OOAD concepts, an object most closely resembles the object-
oriented programming version of an object, in that it is a representation of a real
world object with behaviours, characteristics, and states.

Most developers are well-aware of the concepts of object-oriented development,

but those same concepts originate from a broader approach to the entire
software development life cycle known as object-oriented analysis and
design (OOAD). OOAD is a technical method of analysing and designing an
application based on that system’s object models (the logical components of the
system that interact with one another).

Object-Oriented Analysis:

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 behaviour of the objects, i.e., object actions
 Describing how the objects interact
Object-Oriented Design:

Object–Oriented Design (OOD) involves 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. The implementation details
generally include:

 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,
 Implementation of control, and
 Implementation of associations.

Grady Booch has defined object-oriented design as “a method of design

encompassing the process of object-oriented decomposition and a notation for
depicting logical and physical as well as static and dynamic models of the
system under design”.

Origins of Object-Oriented Analysis and Design:

During the software development life cycle, development is typically broken up

into stages, which are loose, abstract concepts used to separate the activities
taking place within each phase of development. Often, these stages might
include requirements, planning, design, coding/development, testing, deployme
nt, maintenance, and so forth.

In the case of stringent development methodologies, such as the waterfall

method, these stages are sequential and intended to be completely separate from
one another. Thus, when creating an application using the waterfall method, it’s
unlikely that discoveries made during the testing or deployment phases can
impact the decisions already made during the planning or design phases. These
limitations, along with the strict step-by-step staging process of waterfall
models, led to the rise of iterative models like object-oriented analysis and
design.

While OOAD practices have been around for a number of decades, the core
ideas and techniques were largely cemented in the collective mind of the
development community in the 1990s. An assortment of practitioners and
authorities in the industry, working together and on solo endeavors, began to
publish a number of books, articles, and techniques that all relied heavily
on OOAD concepts. Some of these publications and methodologies are still
well-known and in use today, including the Unified Modeling Language and
the Rational Unified Process.

Object-oriented modelling or Object Modelling:

Object modelling develops the static structure of the software system in terms of
objects. It identifies the objects, the classes into which the objects can be
grouped into and the relationships between the objects. It also identifies the
main attributes and operations that characterize each class.
Object-oriented modelling (OOM) is a common approach to modelling
applications, systems, and business domains by using the object-oriented
paradigm throughout the entire development life cycles. OOM is a main
technique heavily used by both OOD and OOA activities in modern software
engineering.
Object-oriented modelling typically divides into two aspects of work: the
modelling of dynamic behaviours like business processes and use cases, and the
modelling of static structures like classes and components. OOA and OOD are
the two distinct abstract levels (i.e. the analysis level and the design level)
during OOM. The Unified Modelling Language (UML) and SysML are the two
popular international standard languages used for object-oriented modelling.
The benefits of OOM are:

Efficient and effective communication:

Users typically have difficulties in understanding comprehensive documents
and programming language codes well. Visual model diagrams can be more
understandable and can allow users and stakeholders to give developers
feedback on the appropriate requirements and structure of the system. A key
goal of the object-oriented approach is to decrease the "semantic gap" between
the system and the real world, and to have the system be constructed using
terminology that is almost the same as the stakeholders use in everyday
business. Object-oriented modelling is an essential tool to facilitate this.
Useful and stable abstraction:
Modelling helps coding. A goal of most modern software methodologies is to
first address "what" questions and then address "how" questions, i.e. first
determine the functionality the system is to provide without consideration of
implementation constraints, and then consider how to make specific solutions to
these abstract requirements, and refine them into detailed designs and codes by
constraints such as technology and budget. Object-oriented modeling enables
this by producing abstract and accessible descriptions of both system
requirements and designs, i.e. models that define their essential structures and
behaviours like processes and objects, which are important and valuable
development assets with higher abstraction levels above concrete and complex
source code.

Structured analysis structured design (SA/SD)

In software engineering, structured analysis (SA) and its allied technique,
structured design (SD), are methods for an4alyzing business requirements and
developing specifications for converting practices into computer programs,
hardware configurations, and related manual procedures. Structured analysis
and design techniques are fundamental tools of systems analysis.

They developed from classical systems analysis of the 1960s and 1970s
structured analysis structured design (SA/SD) approach, with all the models
most physicists are used: data flow diagrams, algorithmic decomposition, flow
charts, top down module hierarchical tree. SA/SD puts the emphasis on
decomposing a system as a set of processes and the set of data they manage, and
their mutual dependencies. Hence, it focuses upon and exposes the structure of
data and the implementation details of the processes that manipulate it, exactly
those parts that in a complex software environment are most subject to changes
for improvement. Indeed most of the effort spent is in trying to achieve first the
most stable data structures, then the hierarchical tree of processes that mutually
exchange them. Unfortunately, once defined the data, processes are so tightly
depending on data structures to become difficult to improve, if not to simply
modify, and the knowledge of data structures is so deep in the fabric of the
system to discourage any evolution, even when major improvements would then
be achievable. In facts, the modules that express the relevant abstractions
depend upon the modules that contain the irrelevant details! From this derives
that when changes are made to the details, the abstractions are affected.

In SA/SD, the top-down tree of the structured program expresses also the chain
of dependencies from the more abstract modules at the top (closer to the
problem domain) to the more detailed ones at the bottom: purely
implementation concerned (solution domain) modules. Therefore, if we attempt
to reuse one of those abstractions we must carry along all the details that those
abstractions depend upon (the traditional reuse). It is not an exaggeration to say
that every experiment in HEP has faced these and similar problems during its
life time.
DIFFERENCES BETWEEN STRUCTURED ANALYSIS AND
OBJECT ORIENTED ANALYSIS
Object oriented analysis design (OOAD) is basically a bottom up approach
which supports viewing the system as a set of components (objects) that can be
logically kept together to form the system.

Advantages and Disadvantages of Object Oriented Analysis and Design:

Advantages:

The OO approach inherently makes each object a standalone component that

can be reused not only within a specific stat problem domain, but also is
completely different problem domains, having the requirement of similar
objects.

The other main advantage of object oriented (OO) is the focus on data
relationships. You cannot develop a successful system where data relationships
are not well understood. An OO model provides all of the insight of an ER
diagram and contains additional information related to the methods to be
performed on the data.

Disadvantages:

You know that OO methods only build functional models within the objects.
There is no place in the methodology to build a complete functional model.
While this is not a problem for some applications (e.g., building a software
toolset), but for large systems, it can lead to missed requirements. You will see
in Unit 3 of this course. “Use cases” addresses this problem, but since all use
cases cannot be developed, it is still possible to miss requirements until late in
the development cycle.

Another disadvantage of the object oriented analysis design (OOAD) is in

system modelling for performance and sizing. The object oriented (OO) models
do not easily describe the communications between objects. Indeed, a basic
concept of object oriented (OO) is that the object need not know who is
invoking it. While this leads to a flexible design, performance modeling cannot
be handled easily.

The object oriented (OO) analysis design itself does not provide support for
identifying which objects will generate an optimal system design. Specifically,
there is no single diagram that shows all of the interfaces between objects. You
will study object oriented analysis design (OOAD) diagrams in Unit 3 of this
course. As you know, coupling is a major factor in system complexity, not
having this information makes architecture component selection a hit or miss
proposition.

Advantages and Disadvantages of Structured Analysis:

With experience, you will come to know that most customers understand
structured methods better than object oriented (OO) methods. Since one of the
main reasons of modeling a system is for communication with customers and
users, there is an advantage in providing structured models for information
exchange with user groups or customers.

Implementation of Detailed design:

Object design is a very iterative process in which several classes (maybe newly
created), relationships between objects, are added when you move from one
level to another level of the design.

There are certain steps to be followed in this design:

1) Classify the operations on classes

This step basically means all the three models, functional, object and dynamic
must be combined so as to know what operations are to be performed on
objects. We can make a state diagram describing the life history of an object. A
transition is a change of state of object and it maps into an operation on the
object. It helps in visualizing state changes. We can associate an operation with
each event received by an object. Also, sometimes an event may represent an
operation on another objects i.e., where one event triggers another event. Thus,
in this case, the event pair must be mapped into an operation performing action
and returning control, provided that the events are on a single thread of control
passing from object to object.

Any action initiated by transition in a state diagram can be expanded into an

entire data flow diagram in the functional model. The processes in a data flow
diagram consist of sub-operations which may be operational on the original
target object, or on other objects.

2) Design an algorithm to implement operations

Each and every operation specified in a functional model should be formulated

as an algorithm. The algorithm indicates how the operation is done rather than
what it does, as in analysis specification.
The algorithm designer must:

i) Select the proper algorithm so as to minimize implementation cost

ii) Find the most appropriate data structure for the selected algorithm
iii) Define new internal classes and operations, if required
iv) Assign responsibility for operations to appropriate classes.

3) Optimization of data access paths

Optimization is a very important aspect of any design. The designer should do

the followings for optimization:
i) Add redundant associations, or omit non-usable existing associations
to minimize access cost and maximize convenience
ii) Rearrange the order of computational tasks for better efficiency.
iii) Save derived attributes to avoid re-computation of complicated
expressions.

4) Implementing software control

To implement software control the designer must redesign the strategy of the
state event model that is present in the dynamic model. Generally, there are
three basic approaches to implement the dynamic model. These approaches are:

i) Storing state of program as location within a program, i.e., as a procedure

driven system
ii) Direct implementation of a state machine mechanism i.e., event driver
iii) Using concurrent tasks.

5) Adjustment of inheritance

The inheritance can be increased as the object design progresses by changing

the class structure. The designer should:

i) Adjust, or rearrange the classes and operations

ii) Abstract common behaviour out of groups of classes
iii) Use delegation to share behaviour when inheritance is semantically
incorrect.

6) Design of associations

During the object design phase we must make a strategy to implement the
associations. Association can be unidirectional or bi-directional. Whichever
implementation strategy we choose, we should hide the implementation, using
access operations to traverse and update the associations. This will allow us to
change our decision with minimal effort. The designer should:

i) Analyze the path of associations.

ii) Implement every association either as a distinct object,
iii) or as a link to another object.

7) Determine object representation

As a designer, you must choose properly when to use primitive types in
representing objects, and when to combine groups of related objects, i.e., what
is the exact representation of object attributes.

8) Package classes and associations into models

Programs are made of discrete physical units that can be edited, complied,
imported or otherwise manipulated. The careful partitioning of an
implementation into package is important for group work on a program.
Packaging involves the following issues:

a. Information hiding
b. Collection of entities
c. Constructing physical modules with strong coupling within each module.

Program Component, Interface and Package:

Component: A component is a physical and replaceable part of the system that

conforms to and provides the realization of a set of interfaces. It represents the
physical packaging of elements like classes and interfaces.

Notation : In UML diagrams, a component is represented by a rectangle with

tabs as shown in the figure below.
Interface: Interface is a collection of methods of a class or component. It
specifies the set of services that may be provided by the class or component.

Notation : Generally, an interface is drawn as a circle together with its name. An

interface is almost always attached to the class or component that realizes it.
The following figure gives the notation of an interface.

Package: A package is an organized group of elements. A package may contain

structural things like classes, components, and other packages in it.

Notation : Graphically, a package is represented by a tabbed folder. A package

is generally drawn with only its name. However it may have additional details
about the contents of the package. See the following figures.

Integration of SA/SD with OOD:

We will see here how we can map different models in SAD to different models
in OOAD. We will consider various levels of abstraction through which this is
done. The data flow diagram (DFD) in SAD is mapped to Use Case diagram in
OOAD. DFD represents a broader model of a system from the process point of
view. Hence, DFD cannot be transformed as it is to equivalent representation in
UML.
The processes are transformed those into Use Case, and the external entity in
DFD has similar characteristics to of an actor in OOAD. The data store is
transformed into class and part of the data store to attributes of class.

An object-oriented design process

1. Define the context and modes
2. Designs the system architecture
3. Identifies the principal system objects
4. Identifies concurrency in the problem
5. Handling boundary conditions
6. Develops design models
7. Specifies object interfaces

Software developers, data base administrators (DBAs), need to be familiar with

the basic concepts of object-orientation. The object-oriented (OO) paradigm is a
Development strategy based on the concept that systems should be built from a
Collection of reusable components called objects. Instead of separating data and
Functionality as is done in the structured paradigm, objects encompass both.
While the object oriented paradigm sounds similar to the structured paradigm,
as you will see in this course material it is actually quite different. A common
mistake that many experienced developers make is to applying similar software-
engineering principles to OO design. To succeed one must recognize that the
OO approach is different than the structured approach.