OOAD

Unit-4
Development Stages:

The Object-Oriented Modelling (OOM) technique visualizes things in an application by using

models organized around objects. Any software development approach goes through the
following stages −

• Analysis,
• Design, and
• Implementation.

In object-oriented software engineering, the software developer identifies and organizes the
application in terms of object-oriented concepts, prior to their final representation in any
specific programming language or software tools.

Phases in Object-Oriented Software Development

The major phases of software development using object–oriented methodology are object-
oriented analysis, object-oriented design, and object-oriented implementation.

Object–Oriented Analysis

In this stage, the problem is formulated, user requirements are identified, and then a model is
built based upon real–world objects. The analysis produces models on how the desired system
should function and how it must be developed. The models do not include any implementation
details so that it can be understood and examined by any non–technical application expert.

Object–Oriented Design

Object-oriented design includes two main stages, namely, system design and object design.

System Design

In this stage, the complete architecture of the desired system is designed. The system is
conceived as a set of interacting subsystems that in turn is composed of a hierarchy of
interacting objects, grouped into classes. System design is done according to both the system
analysis model and the proposed system architecture. Here, the emphasis is on the objects
comprising the system rather than the processes in the system.

Object Design

In this phase, a design model is developed based on both the models developed in the system
analysis phase and the architecture designed in the system design phase. All the classes required
are identified. The designer decides whether −

• new classes are to be created from scratch,

• any existing classes can be used in their original form, or
 • new classes should be inherited from the existing classes.

The associations between the identified classes are established and the hierarchies of classes
are identified. Besides, the developer designs the internal details of the classes and their
associations, i.e., the data structure for each attribute and the algorithms for the operations.

Object–Oriented Implementation and Testing

In this stage, the design model developed in the object design is translated into code in an
appropriate programming language or software tool. The databases are created and the specific
hardware requirements are ascertained. Once the code is in shape, it is tested using specialized
techniques to identify and remove the errors in the code.

Development Life Cycle:

An effective System Development Life Cycle (SDLC) should result in a high quality system
that meets customer expectations, reaches completion within time and cost evaluations, and
works effectively and efficiently in the current and planned Information Technology
infrastructure.

System Development Life Cycle (SDLC) is a conceptual model which includes policies and
procedures for developing or altering systems throughout their life cycles.

SDLC is used by analysts to develop an information system. SDLC includes the following
activities −

• requirements
• design
• implementation
• testing
• deployment
• operations
• maintenance

Phases of SDLC

Systems Development Life Cycle is a systematic approach which explicitly breaks down the
work into phases that are required to implement either new or modified Information System.
Feasibility Study or Planning

• Define the problem and scope of existing system.

• Overview the new system and determine its objectives.
• Confirm project feasibility and produce the project Schedule.
• During this phase, threats, constraints, integration and security of system are also
considered.
• A feasibility report for the entire project is created at the end of this phase.

Analysis and Specification

• Gather, analyze, and validate the information.

• Define the requirements and prototypes for new system.
• Evaluate the alternatives and prioritize the requirements.
• Examine the information needs of end-user and enhances the system goal.
• A Software Requirement Specification (SRS) document, which specifies the software,
hardware, functional, and network requirements of the system is prepared at the end of
this phase.

System Design

• Includes the design of application, network, databases, user interfaces, and system
interfaces.
• Transform the SRS document into logical structure, which contains detailed and
complete set of specifications that can be implemented in a programming language.
• Create a contingency, training, maintenance, and operation plan.
• Review the proposed design. Ensure that the final design must meet the requirements
stated in SRS document.
• Finally, prepare a design document which will be used during next phases.

Implementation
 • Implement the design into source code through coding.
• Combine all the modules together into training environment that detects errors and
defects.
• A test report which contains errors is prepared through test plan that includes test related
tasks such as test case generation, testing criteria, and resource allocation for testing.
• Integrate the information system into its environment and install the new system.

Maintenance/Support

• Include all the activities such as phone support or physical on-site support for users that
is required once the system is installing.
• Implement the changes that software might undergo over a period of time, or implement
any new requirements after the software is deployed at the customer location.
• It also includes handling the residual errors and resolve any issues that may exist in the
system even after the testing phase.
• Maintenance and support may be needed for a longer time for large systems and for a
short time for smaller systems.

Devising a system concept:

hen devising a system concept in object-oriented analysis and design (OOAD), you can
consider the following:

• Defining objects

Map entities to classes and create a class diagram from the conceptual diagram

Identifying attributes
Identify the attributes and their models
Using design patterns
Design patterns are descriptions of solutions to common problems in a context
Using models
Use three types of models to describe a system from different perspectives:

• Class model: Describes the static structure of objects and their relationships

State model: Describes the aspects of an object that change over time
Interaction model: Describes how objects interact to achieve broader results

OOAD is a technical approach that uses visual modeling and object-oriented programming to
analyze and design systems, applications, or businesses. It's similar to the approach proposed
in General Systems Theory.

Elaborating a concept:
Elaboration is the initial series of iterations during which, on a normal project:
• the core, risky software architecture is programmed and tested
• the majority of requirements are discovered and stabilized
• the major risks are mitigated or retired
• Build the core architecture, resolve the high-risk elements, define most
 • requirements, and estimate the overall schedule and resources.
• Elaboration is the initial series of iterations during which the team does serious
• investigation, implements (programs and tests) the core architecture, clarifies most
• requirements, and tackles the high-risk issues.
• Elaboration often consists of two or more iterations; Each iteration is
• recommended to be between two and six weeks; prefer the shorter versions unless
• the team size is massive. Each iteration is time boxed, i.e its end date is fixed.
• Elaboration is not a design phase or a phase when the models are fully
• developed in preparation for implementation in the construction step that
• would be an example of superimposing waterfall ideas on iterative
• development and the UP.
• During this phase, no prototypes are created ; rather, the code and design are
• production-quality portions of the final system.
• Architectural prototype means a production subset of the final system. More
• commonly it is called the executable architecture or architectural baseline.
•
Key Ideas and Best Practices will manifest in elaboration:
• do short time boxed risk-driven iterations
• start programming early
• adaptively design, implement, and test the core and risky parts of the
• architecture
• test early, often, realistically
• adapt based on feedback from tests, users, developers
• write most of the use cases and other requirements in detail, through a series
• of workshops, once per elaboration iteration

Preparing a problem statement:

A problem statement is a concise description of the problem or issues a project seeks to address.
The problem statement identifies the current state, the desired future state and any gaps between
the two. A problem statement is an important communication tool that can help ensure
everyone working on a project knows what the problem they need to address is and why the
project is important.

Importance of a problem statement

A problem statement is important to a process improvement project because it helps clearly

identify the goals of the project and outline the scope of a project. It also helps guide the
activities and decisions of the people who are working on the project. The problem statement
can help a business or organization gain support and buy-in for a process improvement project.

What are the key elements of a problem statement?

There are four key elements you can include when writing a problem statement:

1. Ideal situation
Problem statements often begin by describing what the ideal situation would be if there wasn't
a problem you needed to address. This section can identify the goals and scope of the project,
and create a clear understanding of what the ideal environment will be once the issue has been
resolved.

2. Reality

The next section of your problem statement can describe what the current reality is for your
company or organization. This section will identify what the problem is, state why it is a
problem, and identify who the problem is impacting. It will also describe when and where the
problem was identified.

3. Consequences

After describing the current reality, your problem statement can focus on the consequences of
the problem. This section describes the effects of the problem by describing how the people
affected by the problem are being impacted and quantifying how much the problem is
impacting them. Common consequences can include the loss of time, money, resources,
competitive advantage and productivity.

4. Proposal

The proposal section of a problem statement may contain various possible solutions to the
problem, but it is important to remember that it does not need to identify a specific solution.
The purpose of the proposal section should be to guide the project team on how they can
research, investigate and resolve the problem.

How to write a problem statement?

A good problem statement can be created by identifying and answering several questions
related to the problem. The process used to write a problem statement can involve answering
questions using a method commonly known as [Link] process involves identifying what
the problem is, why it is a problem, when and where the problem was identified, who the
problem impacts, how they are impacted by the problem and how much of an impact the
problem has. You can use the following process to craft a problem statement that addresses the
following:

1. Identify the problem

Before you can begin writing your problem statement, it is important to identify what the
problem is.

2. Begin your statement with your ideal situation

Next, you can begin writing your problem statement by describing what the ideal environment
would look like if your problem didn't exist. This section can be used to describe what your
company hopes to accomplish as a result of the process improvement project.

3. Describe current gaps

This step involves writing the reality section of your problem statement. Your goal in this
section is to clearly identify what the current environment looks like. It is advisable to identify
what the problem is, what is causing the problem, and why it is an issue. Also consider
describing when, where, and how you were able to identify the problem.

4. State the consequences of the problem

Next, write the consequences section of your problem statement. This section is used to
quantify and support the claim of what the problem is. You can use this section to identify
specific numbers such as the amount of time or revenue being lost or the number of resources
being wasted. It is important to include concrete numbers that support your claims in this
section.

5. Propose addressing the problem

You can end your statement with a proposal section. In this section, consider identifying how
your company will make progress toward reaching your goals and accomplishing your ideal
environment. While you may choose to identify several possible solutions in this section, it is
more important to focus on identifying how your company will find those solutions than it is
to identify the specific solution that will be used.

Overview of Analysis:

In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.

The three analysis techniques that are used in conjunction with each other for object-oriented
analysis are object modelling, dynamic modelling, and functional modelling.

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.

The process of object modelling can be visualized in the following steps −

• Identify objects and group into classes

• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the classes
• Review glossary

Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to time and external
changes needs to be examined. This is the purpose of dynamic modelling.

Dynamic Modelling can be defined as “a way of describing how an individual object responds
to events, either internal events triggered by other objects, or external events triggered by the
outside world”.

The process of dynamic modelling can be visualized in the following steps −

• Identify states of each object

• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state transition diagrams
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn

Functional Modelling

Functional Modelling is the final component of object-oriented analysis. The functional model
shows the processes that are performed within an object and how the data changes as it moves
between methods. It specifies the meaning of the operations of object modelling and the actions
of dynamic modelling. The functional model corresponds to the data flow diagram of
traditional structured analysis.

The process of functional modelling can be visualized in the following steps −

• Identify all the inputs and outputs

• Construct data flow diagrams showing functional dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of

software development based upon the waterfall model. The phases of development of a system
using SASD are −

• Feasibility Study
• Requirement Analysis and Specification
• System Design
• Implementation
• Post-implementation Review

Now, we will look at the relative advantages and disadvantages of structured analysis approach
and object-oriented analysis approach.

Advantages/Disadvantages of Object Oriented Analysis

Advantages Disadvantages
Functionality is restricted within objects. This
Focuses on data rather than the procedures as may pose a problem for systems which are
in Structured Analysis. intrinsically procedural or computational in
nature.
The principles of encapsulation and data
hiding help the developer to develop systems It cannot identify which objects would generate
that cannot be tampered by other parts of the an optimal system design.
system.
The principles of encapsulation and data
The object-oriented models do not easily show
hiding help the developer to develop systems
the communications between the objects in the
that cannot be tampered by other parts of the
system.
system.
It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.
It can be upgraded from small to large
systems at a greater ease than in systems
following structured analysis.

Advantages/Disadvantages of Structured Analysis

Advantages Disadvantages
In traditional structured analysis models,
As it follows a top-down approach in contrast to one phase should be completed before the
bottom-up approach of object-oriented analysis, it next phase. This poses a problem in
can be more easily comprehended than OOA. design, particularly if errors crop up or
requirements change.
It is based upon functionality. The overall purpose
The initial cost of constructing the system
is identified and then functional decomposition is
is high, since the whole system needs to
done for developing the software. The emphasis not
be designed at once leaving very little
only gives a better understanding of the system but
option to add functionality later.
also generates more complete systems.
The specifications in it are written in simple English It does not support reusability of code.
language, and hence can be more easily analyzed by So, the time and cost of development is
non-technical personnel. inherently high.

Domain Class Model:

• First step in analyzing the requirements is to construct a domain model.
• Static structure of the real world system is captured.
• The domain model describes real-world classes and their relationships to
each other.
• Information for the domain model comes from the problem statement,
artifacts from related systems, expert knowledge of the application domain
and general knowledge of the real world.
The steps to be performed to construct a domain class model:
• Find Classes.
• Prepare a data dictionary.
• Find associations.
• Find attributes of objects and links.
• Organize and simplify classes using inheritance.
• Verify that access paths exist for likely queries.
• Iterate and refine the model.
• Reconsider the level of abstraction.
• Group classes into packages
• Finding classes
• Classes often correspond to nouns.
• Eg- ” a reservation system sell tickets to performances at various theater”-
Tentative classes would be Reservation, System, Tickets, Performance and
Theaters.
• Idea is to capture concepts. not all nouns are concepts, and concepts are
also expressed in other parts of speech.

Domain State Model:

The Following steps are performed in constructing a domain state model
• Identifying classes with states
• Finding states
• Finding Events
• Building state diagrams
• Evaluating state diagrams
After running thro the above steps, the domain state model obtained is a shown in Figure.
Domain Interaction Model:
• The Interaction model is seldom important for domain analysis.
• The Interaction model is an important aspect of application modeling

The interaction model is the third leg of the modeling tripod and describes interactions with in
a system. The class model describes the objects in a system and their relationships, the state
model describes the life cycles of the objects, and the interaction model describes how the
objects interact.
The interaction model describes how objects interact to produce useful results. Itis a holistic
view of behavior across many objects, whereas the state model is a reductionist view of
behavior that examines each object individually. Both the state model and the interaction model
are needed to describe behavior fully. They complement each other by viewing behavior from
two different perspectives.
Interactions can be modeled at different levels of abstraction. At a high level, use cases describe
how a system interacts with outside actors. Each use case represents a piece of functionality
that a system provides to its users. Use cases are helpful for capturing informal requirements.
Sequence diagrams provide more detail and show the messages exchanged among a set of
objects over time. Messages include both asynchronous signals and procedure calls. Sequence
diagrams are good for showing the behavior sequences seen by users of a system.
And finally, activity diagrams provide further detail and show the flow of control among the
steps of a computation. Activity diagrams can show data flows as well as control flows.
Activity diagrams document the steps necessary to implement an operation or a business
process referenced in a sequence diagram.