OBJECT ORIENTED ANALYSIS AND DESIGN

OOAD – BASIC CONCEPTS

 Object oriented concepts have become quiet popular in the area of computer programming with the
promise of
 Interchangeable
 Reusable
 Easily updateable
 Easily interconnected
software parts.
OOAD – BASIC CONCEPTS

 The Magic Concept

 Data or Software can be “Containerized”
 Everything goes into a box and there can be boxes within boxes

 Whereas in a object oriented language each step might be a whole box full of instructions.
OOAD – BASIC CONCEPTS

• The central concept of object oriented design is the object

▫ Definition: an object is a distinct software unit that contains a collection of related variables
(attributes /data) and methods (procedures)
• Generally these methods and variables are not directly visible outside the object. Rather well defined
interfaces exist that allow other software units to have access to these variables and methods.
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.
 Requirements Gathering:
 Identify the system's functional and non-functional requirements.
 Understand the user's needs and expectations.
 Object-Oriented Analysis:
 Identify the objects and their relationships in the system.
 Create a conceptual model of the system using UML diagrams (e.g., use case diagrams, class diagrams).
 Define the attributes and methods of each object.
OBJECT-ORIENTED ANALYSIS

 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

 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.
 Design the system's architecture, including the overall structure and components.
 Design the classes and their relationships, focusing on modularity and reusability.
 Create detailed design diagrams (e.g., class diagrams, sequence diagrams).
OBJECT-ORIENTED 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, and
 Implementation of associations.
WHAT IS THE UML*?

• UML stands for Unified Modeling Language

• The UML combines the best of the best from:
▫ Data Modeling concepts (Entity Relationship Diagrams)
▫ Business Modeling (Work Flow)
▫ Object Modeling
▫ Component Modeling
• The UML is a standard language for specifying, visualizing, documenting and constructing the artifacts
of a software-intensive system
• It can be used with all processes, throughout the development life cycle, and across different
implementation technologies
GOALS OF UML

 Enable the modeling of systems (not just software) using object-oriented concepts
 Establish an explicit coupling to conceptual as well as executable artifacts
 Address the issues of scale inherent in complex, mission-critical systems
 Create a modeling language usable by both humans and machines
UML USAGE: OVERVIEW

• The UML may be used to:

▫ Represent the Elements of a system or a domain and their Relationships in a Static Structure using
class and object diagrams
▫ Model the Behavior of objects with state transition diagrams
▫ Reveal the Physical Implementation Architecture with component & deployment diagrams
▫ Display the Boundary of a System & its major Functions using use cases and actors
▫ Illustrate Use Case Realizations with interaction diagrams
UML FOR INFORMATION MODELING

 Provides a uniform modeling formalism and a set of (object-oriented) constructs (notation) for
representing the elements of a domain of interest as well as their relationships in a Static Structural
Model
 By effectively using UML for informational modeling, software developers and analysts can:
 Improve Communication: Clearly communicate the information structure of a system to stakeholders.
 Enhance Design Quality: Create well-structured and maintainable data models.
 Facilitate Database Design: Generate database schemas directly from UML models.
 Support Code Generation: Automate the generation of code from UML models.
BASIC MODELING ELEMENTS

 Structural elements
 Class – Attributes – Operations - Interface –Object
 Behavioral elements
 Use Case – Activity Diagram – Sequence Diagram – State chart Diagram
 Grouping elements
 package, subsystem
BASIC MODELING ELEMENTS

 Relationships Between Elements

 Association: A relationship between two classes, indicating that instances of one class can be linked
to instances of another.
 Dependency: A relationship between two elements where a change in one element can affect the
other.
 Generalization: A relationship between a general class (superclass) and a more specific class
(subclass).
 Realization: A relationship between a class and an interface, indicating that the class implements the
interface.
WHY BUILD MODELS?

 To understand the problem better

 To communicate with stakeholders

 To find errors or omissions

 To plan out the design

 To generate code
MODELS AND DIAGRAMS State
State
Diagrams
Class
Diagrams
Use Case Diagrams
A model is a Use Case
Diagrams State
complete Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
description of a Diagrams
Sequence Diagrams
Diagrams
system Diagrams
from a particular
perspective
Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Component
Diagrams
Diagrams Diagrams
Models

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams
UML MODEL VIEWS

• Requirements (use case diagrams)

• Static structure (class diagrams)
▫ kinds of objects and their relationships
• Dynamic behavior (state machines)
▫ possible life histories of an object
• Interactive behavior (activity, sequence, and collaboration diagrams)
▫ flow of control among objects to achieve system-level behavior
• Physical implementation structures (component and deployment diagrams)
▫ software modules and deployment on physical nodes
DIAGRAMS

• A diagram is a view into a model

▫ Presented from the aspect of a particular stakeholder
▫ Provides a partial representation of the system
▫ Is semantically consistent with other views
• In the UML, there are nine standard diagrams
▫ Static views: use case, class, object, component, deployment
▫ Dynamic views: sequence, collaboration, statechart, activity