Object-oriented Analysis and

Design
What is Object-oriented Analysis and
Design??
It is a popular technical approach for
o Analyzing
o Designing an application, system, or business
o By applying the object-oriented paradigm and
o Visual modeling throughout the development life cycles for better
communication and product quality
What is OOAD ??
• Object-oriented analysis and design(OOAD) is a
software engineering approach that models a system as
a group of interacting objects.
• OOAD -> A software development approach that
emphasizes a logical solution based on objects
• EXAMPLES OF OBJECT ORIENTED SYSTEMS:-
• IN OO system, “everything is an object”.
• A spreadsheet cell, bar chart, report,
• Numbers, arrays, records, fields , files,forms, an invoice,
etc.
What is 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 primary tasks in object-oriented analysis (OOA) are
1. Identifying objects
2. Organizing the objects by creating object model diagram.
3. Defining the internals of the objects, or object attributes.
4. Defining the behavior of the objects, i.e., object actions
5. Describing how the objects interact
Object-oriented Analysis Techniques
• The three analysis techniques that are used in conjunction with each
other for object-oriented analysis are
1. Object modelling,
2. Dynamic modelling, and
3. 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 −
I. Identify objects and group into classes
II. Identify the relationships among classes
III. Create user object model diagram
IV. Define user object attributes
V. Define the operations that should be performed on the classes
VI. 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 −
I. Identify states of each object
II. Identify events and analyze the applicability of actions
III. Construct dynamic model diagram, comprising of state transition diagrams
IV. Express each state in terms of object attributes
V. 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
−
I. Identify all the inputs and outputs
II. Construct data flow diagrams showing functional dependencies
III. State the purpose of each function
IV. Identify constraints
V. Specify optimization criteria
What is 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.
• OOA focuses on What the system does , OOD on how the system does
it.
OOAD
• Object Oriented: This means organizing software as a collection of
individual parts called “objects”. Objects have attributes (data) and
methods (functions) that operate on the data.
• Analysis: Analysis refers to the process of understanding and defining
the requirements of a system. This involves studying the problem
domain, identifying stakeholders, and capturing the essential features
and functions that the software system must provide.
• Design: It refers to the process of defining the architecture,
components, interfaces, and other characteristics of a software system
to meet the requirements identified during the analysis phase.
Benefits
• Improved modularity: OOAD encourages the creation of small, reusable
objects that can be combined to create more complex systems, improving
the modularity and maintainability of the software.
• Better abstraction: OOAD provides a high-level, abstract representation of
a software system, making it easier to understand and maintain.
• Improved reuse: OOAD encourages the reuse of objects and object-
oriented design patterns, reducing the amount of code that needs to be
written and improving the quality and consistency of the software.
• Improved communication: OOAD provides a common vocabulary and
methodology for software developers, improving communication and
collaboration within teams.
• Requirements Gathering: This involves understanding what the system should do
from the user's perspective.
• Identifying Objects: Objects are typically identified based on the nouns in the
requirements. These could be tangible things (like Car or Employee) or concepts (like
Transaction or Order).
• Defining Classes: Once objects are identified, classes are defined to encapsulate data
(attributes) and behaviour (methods) for these objects.
• Use Case Analysis: Use cases describe the interactions between users (actors) and the
system. They help in defining the functional requirements and identifying key objects.
• Modelling Relationships: Understanding and defining how objects interact with one
another, including relationships like associations, aggregations, and compositions.
Unified Modelling Language
In software engineering, Unified Modeling Diagrams are a set of
graphical tools used to specify, visualize, and document the structure
and behavior of a software system. These diagrams are part of the
Unified Modeling Language (UML), which provides a standardized
way to model software systems. UML helps design complex systems
and facilitates communication among stakeholders by providing a clear
and standardized way to represent various aspects of a system.
UML Diagram Types
Class Diagram
• A Class Diagram is one of the most fundamental types of diagrams in
UML (Unified Modeling Language). It represents the static structure
of a system by depicting its classes, their attributes, methods, and the
relationships among the classes. Class diagrams are crucial for
modeling the detailed design of a system, showing how different
components interact at a class level.
Class Diagram Components
• Class: A class is a blueprint for objects. It defines a set of attributes
(properties) and methods (functions) that the objects created from the
class will have.
• Attributes: Attributes are properties or data fields of a class. They
represent the state or characteristics of the objects created from the
class.
• Methods: Methods are functions or operations that can be performed
on the objects of the class. They represent the behavior or actions of
the class.
Example
Object Diagram
Sequence Diagram
Collaboration Diagram
UML Design Methodology
• The methodology you've described is a classic Object-Oriented (OO)
design approach, often used in conjunction with UML (Unified
Modeling Language). Here's how it aligns with OO design and UML
principles:
1. Identify Classes and Relationships between Them:

• This step involves recognizing the major classes (representing real-

world entities or concepts) that will exist in the system and their
relationships (associations, generalizations, dependencies, etc.).
• UML Class Diagrams are used here to represent the static structure of
the system. They show classes, attributes, methods, and the
relationships between classes such as inheritance, composition, and
association.
2. Develop the Dynamic Model and Use It to Define Operations on
Classes:

• The dynamic model captures the behavior of the system, including

how objects interact with each other over time.
• UML Sequence Diagrams and State Diagrams are typically used for
modeling dynamic behavior:
• Sequence Diagrams represent the interaction between objects,
focusing on the messages exchanged.
• State Diagrams represent how objects change state in response to
events.
• This step helps in defining operations and behaviors that classes need
to implement.
3. Develop the Functional Model and Use It to Define Operations on
Classes:

• The functional model focuses on what the system does in terms of

inputs, processes, and outputs, similar to a more function-oriented
view.
• UML Activity Diagrams can be used here to represent workflows and
the flow of control between activities or processes.
• The functional model ensures that each class has operations defined
that support the system's
• functional requirements.
4. Identify Internal Classes and Operations:

• Internal classes are those that may not directly map to external entities
but are necessary for the implementation of the system's functionality
(e.g., helper or utility classes).
• In UML, these classes are also represented in class diagrams but may
not be as prominent or externally visible as others.
5. Optimize and Package:

• Optimization focuses on refining the design for performance,

efficiency, and maintainability, possibly adjusting relationships or
operations.
• Package Diagrams in UML help organize classes into packages or
modules for better structure and management.
• Packaging can also involve grouping related classes into modules to
ensure high cohesion and low coupling, aligning with OO design
principles.
Structured Design Methodology:
• Overview: Structured design is a methodology based on problem
partitioning, with the goal of dividing a system into smaller, more
manageable modules. The system is typically partitioned into subsystems
that focus on inputs, outputs, and transformations. Each of these subsystems
is designed to handle specific aspects of the system's functionality.

• The primary goal of structured design is to produce a design that is modular

and simple, improving maintainability and scalability. It emphasizes
separating the logic for handling inputs, outputs, and core transformations
to ensure that each module has a clear, distinct responsibility.
Key Steps in Structured Design Methodology:
1. Restate the Problem as a Data Flow Diagram (DFD):
• The first step involves translating the problem into a Data Flow
Diagram (DFD). A DFD models the flow of information in the
system by representing the processes that data undergoes, the data
sources, data sinks, and data stores.
• DFD illustrates how data moves from input to output and through
various transformation processes. It breaks down complex
processes into more manageable sub-processes.
• This diagram helps visualize the functional flow of the system and
identify key elements
2. Identify the Input and Output Data Elements:

• In this step, the system is analysed to determine the input and

output data.
• For inputs, you define how data will enter the system, including
issues like formats, sources, errors, and exceptions. For outputs,
you determine the required reports, charts, or formats for
presentation.
• This helps ensure the system is organized around managing input
and output effectively, as a significant part of software design often
focuses on how data is captured and presented.
3. First-Level Factoring:

• First-level factoring divides the system into subsystems for each of the major
parts: inputs, outputs, and transformations.
• Each subsystem is responsible for a specific aspect:
• Input Subsystems: Handle the acquisition of data, managing screen interfaces, formats,
error handling, and validation.
• Output Subsystems: Focus on formatting and presenting the output, generating reports,
charts, or other forms of output.
• Transformation Subsystems: Handle the core logic of the system, the actual
computation or processing of the data, once clean inputs are obtained.
• This factoring ensures each part of the system is modular, making the design
simpler and easier to manage.
4. Factoring of Input, Output, and Transform Branches:

• After first-level factoring, each branch (input, output, and transformation) is

further broken down into smaller modules.
Data Flow Diagram
• A data flow diagram (DFD) is a graphical or visual representation that
uses a standardized set of symbols and notations to describe a
business's operations through data movement. They're often elements
of a formal methodology, such as Structured Systems Analysis and
Design Method (SSADM).
How are data flow diagrams used?
• DFDs make it easy to depict the business requirements of applications
by representing the sequence of process steps and flow of information
using a graphical representation or visual representation rather than a
textual description. When used through an entire development process,
they first document the results of business analysis. They then refine
the representation to show how information moves through and is
changed by application flows. Both automated and manual processes
are represented.
What are the different DFD levels or layers?
• Levels or layers are used in DFDs to represent progressive degrees of
detail about the system or process. These levels include the following:
• Level 0. Also known as a context diagram, this is the highest level and
shows a simple, top-level view of the system being represented.
• Level 1. This is still a relatively broad view of the system, but it
incorporates sub processes and more detail.
• Level 2. Provides even more detail and continues to break down sub
processes as needed.
• Level 3. While this amount of detail is uncommon, complex systems
can benefit from representation at this level.
How do you create a data flow diagram?
• While it depends on the tool used to prepare a DFD, the following is a
basic breakdown of steps to follow to create a DFD:
1. Choose a process or system to diagram.
2. Select the interests involved and categorize them into external entities,
flows, processes and stores.
3. Illustrate a Level 0 context diagram with basic connections.
4. Create more detailed Level 1 diagrams that branch off the processes of
the context diagram, including connected flows, stores, additional
processes and external entities.
5. Repeat as necessary and with as much detail as required.
Hospital Management
System
Library Management
System
Library Management
System
DFD 0
DFD 1
DFD 2