UNIT 1

An Overview of Object Oriented Systems Development

Object-Oriented Systems Development (OOSD) is a methodology used in

software engineering for designing and building software systems. It focuses
on organizing and structuring software around the concept of "objects," which
are instances of classes. Each object represents a distinct entity, encapsulating
both data (attributes) and behaviors (methods or functions). OOSD is often
used to develop complex systems, as it provides a clear and organized
approach to software design, maintenance, and scalability.

Key Concepts of Object-Oriented Systems Development:

1. Objects:
o Objects are the fundamental units in object-oriented systems. They
represent entities in the system and can contain both data and
methods that operate on that data.
o Example: In a banking system, an object could be an instance of
an account with attributes like balance and methods like deposit or
withdraw.
2. Classes:
o A class is a blueprint or template from which objects are
instantiated. It defines the properties (attributes) and behaviors
(methods) that the objects created from the class will have.
o Example: A class Account could have attributes like balance and
methods like deposit() or withdraw().
3. Encapsulation:
o Encapsulation refers to the concept of bundling the data
(attributes) and the methods that manipulate the data into a single
unit or object. It also hides the internal state of the object from the
outside world, exposing only what is necessary through interfaces.
o Example: The balance of an account may be encapsulated within
the object, and access to it may be controlled via methods like
getBalance().
4. Inheritance:
o Inheritance allows new classes to inherit the properties and
behaviors of existing classes. It promotes code reuse and
establishes a relationship between parent and child classes.
o Example: A SavingsAccount class can inherit from a general
Account class, thus gaining all the properties and behaviors of the
Account class while adding additional features like interest rate.
5. Polymorphism:
 o Polymorphism enables objects of different classes to be treated as
objects of a common superclass. It allows for methods to be used
interchangeably across different object types, simplifying code
and increasing flexibility.
o Example: A method processTransaction() could work with any
type of account (checking, savings, etc.), even though each
account type may have a different implementation.
6. Abstraction:
o Abstraction involves hiding complex implementation details and
exposing only the necessary functionality to the user. It simplifies
the interaction with complex systems and improves
maintainability.
o Example: A BankAccount class might abstract the details of how
transactions are processed and only provide a simple method to
deposit or withdraw funds.
7. Message Passing:
o Objects communicate with one another by sending messages
(calling methods) to each other. This communication is central to
the interactions within an object-oriented system.
o Example: A Customer object might send a message to the
BankAccount object to process a withdrawal.

Phases in Object-Oriented Systems Development:

1. Analysis:
o The focus here is on understanding the problem domain. The
requirements are gathered, and objects, their behaviors, and
relationships are identified. Techniques like use cases and class
diagrams are often used in this phase.
2. Design:
o In this phase, a blueprint for the system is created. This includes
designing the classes, defining their attributes, and specifying the
 methods. Class diagrams, sequence diagrams, and interaction
diagrams are commonly used to represent the design.
3. Implementation:
o The actual coding of the system occurs in this phase, where the
design is translated into code using an object-oriented
programming language (like Java, C++, or Python).
4. Testing:
o After implementation, the system is tested for correctness,
performance, and reliability. Object-oriented testing focuses on
testing individual objects, their interactions, and the overall system
behavior.
5. Maintenance:
o After deployment, the system enters the maintenance phase, where
bugs are fixed, and new features may be added. Object-oriented
systems are generally easier to maintain due to their modularity
and reusability.

Advantages of Object-Oriented Systems Development:

 Modularity: Objects are independent, allowing for easier modification
and debugging.
 Reusability: Classes and objects can be reused across different systems
or parts of a system, which reduces development time and effort.
 Maintainability: Systems are easier to maintain because of their
modular structure and encapsulation, making it possible to update or
replace individual objects without affecting the entire system.
 Flexibility: Polymorphism and inheritance allow the system to be easily
extended and modified without changing existing code.
 Scalability: The structure supports the creation of large, complex
systems by managing complexity through abstraction and organization.

Challenges of Object-Oriented Systems Development:

 Complexity: The learning curve can be steep, especially for large
systems with many interacting objects.
 Performance Overhead: Object-oriented systems can introduce
performance overhead due to the need for dynamic dispatch, memory
allocation, and other runtime factors.
 Design Pitfalls: Poor design decisions can lead to excessive
interdependencies or improper use of inheritance, which may
complicate maintenance and scalability.
Object Basics

In Object-Oriented Analysis and Design (OOAD), object basics refer to the

foundational concepts and principles that govern how objects are used and
represented within an object-oriented system. Objects are the primary
building blocks in OOAD, and understanding their characteristics is crucial
for developing robust and maintainable systems. Here's an overview of the
key concepts of objects in OOAD:

Key Concepts of Objects in OOAD:

1. Object:
o An object is an instance of a class that represents a real-world
entity or concept. It encapsulates both state (data) and behavior
(methods or functions).
o State refers to the properties or attributes that describe the object.
For example, a Car object might have attributes like color, model,
and engineType.
o Behavior refers to the actions or methods that the object can
perform. For example, a Car object might have methods like
start(), stop(), and accelerate().
o Example: A Customer object in an e-commerce system could
have attributes like name, email, and address, while methods
might include placeOrder() or updateProfile().
2. Class:
o A class is a blueprint or template from which objects are created.
It defines the structure (attributes) and behavior (methods) that the
objects will have.
o Example: A Customer class might define the attributes name,
email, and address and methods like placeOrder() or
updateProfile(). When you create a Customer object, it will inherit
these properties and behaviors.
3. Encapsulation:
o Encapsulation is the principle of bundling an object’s state
(attributes) and behavior (methods) into a single unit, and
restricting direct access to the object's internal state.
o This protects the object’s integrity by preventing external entities
from modifying its internal state in an uncontrolled manner.
Instead, the object exposes controlled interfaces (methods) to
interact with its data.
o Example: A BankAccount object might encapsulate the balance
attribute and only allow access to it via methods like deposit(),
 withdraw(), or getBalance(). This ensures that the balance is
always manipulated through controlled operations.
4. Identity:
o Every object has a unique identity that distinguishes it from other
objects, even if their state (attributes) is identical. The identity of
an object is not based on its value, but on its reference in memory.
o Example: Two Car objects can have the same color and model,
but they will still be distinct objects with different identities in
memory.
5. Message Passing:
o Objects communicate with one another by passing messages. In
OOAD, a message is a request for an object to execute a method
(i.e., invoking a function).
o Example: A Customer object may send a message to an Order
object to process an order. This means that the Customer object
asks the Order object to invoke its methods, such as
processPayment() or shipProduct().
6. Object Interaction:
o Objects rarely operate in isolation; they typically interact with
other objects. These interactions are fundamental to how a system
functions. Object interactions happen through method calls and
message passing, allowing one object to request another to
perform a specific task.
o Example: In an online banking system, a Customer object
interacts with a BankAccount object to check balance, deposit
funds, or withdraw money.
7. Abstraction:
o Abstraction involves simplifying complex systems by focusing on
the essential characteristics while hiding unnecessary details. It
allows developers to represent complex real-world objects in a
way that focuses on what the object does, rather than how it
works.
o Example: An Employee object might have an abstract method like
calculateSalary(), but the internal implementation of this method
may vary depending on whether the employee is salaried, hourly,
or commission-based.
8. Instance vs. Class:
o Class: A class is the blueprint, and it defines the structure and
behavior that its instances will have.
o Instance: An instance is a specific realization of a class, an object
created from a class.
o Example: The Employee class can have multiple instances, such
as employee1, employee2, etc. Each instance will have its own
 state (attributes) but share the behavior (methods) defined in the
Employee class.
9. Constructors and Destructors:
o Constructor: A special method used to initialize an object when it
is created. The constructor typically sets the initial state of the
object’s attributes.
o Destructor: A method that is called when an object is destroyed
or goes out of scope. It is used to clean up resources held by the
object.
o Example: A Car class may have a constructor that sets the model,
color, and engineType when an object of Car is created. A
destructor could handle deallocating memory when the car object
is no longer needed.
10. Overloading and Overriding:
o Overloading: Occurs when two or more methods in the same
class share the same name but differ in the number or type of their
parameters. It allows methods to perform different tasks based on
the arguments passed.
o Overriding: Occurs when a subclass provides a specific
implementation for a method that is already defined in its
superclass. The method in the subclass "overrides" the method in
the superclass.
o Example of Overloading: A calculateArea() method can be
overloaded in a Shape class to handle both circles (using radius)
and rectangles (using length and width).
o Example of Overriding: A draw() method in a Shape class could
be overridden by a Circle subclass to provide specific behavior for
drawing circles.

Principles of Object-Oriented Systems

The conceptual framework of object–oriented systems is based upon the

object model. There are two categories of elements in an object-oriented
system −

Major Elements − By major, it is meant that if a model does not have any
one of these elements, it ceases to be object oriented. The four major elements
are −

 Abstraction
 Encapsulation
 Modularity
 Hierarchy
 Minor Elements − By minor, it is meant that these elements are useful, but
not indispensable part of the object model. The three minor elements are −
 Typing
 Concurrency
 Persistence

Abstraction
Abstraction means to focus on the essential features of an element or object in
OOP, ignoring its extraneous or accidental properties. The essential features
are relative to the context in which the object is being used.

Grady Booch has defined abstraction as follows −

“An abstraction denotes the essential characteristics of an object that

distinguish it from all other kinds of objects and thus provide crisply defined
conceptual boundaries, relative to the perspective of the viewer.”

Example − When a class Student is designed, the attributes

enrolment_number, name, course, and address are included while
characteristics like pulse_rate and size_of_shoe are eliminated, since they are
irrelevant in the perspective of the educational institution.

Encapsulation

Encapsulation is the process of binding both attributes and methods together

within a class. Through encapsulation, the internal details of a class can be
hidden from outside. The class has methods that provide user interfaces by
which the services provided by the class may be used.

Modularity
Modularity is the process of decomposing a problem (program) into a set of
modules so as to reduce the overall complexity of the problem. Booch has
defined modularity as −

“Modularity is the property of a system that has been decomposed into a set
of cohesive and loosely coupled modules.”

Modularity is intrinsically linked with encapsulation. Modularity can be

visualized as a way of mapping encapsulated abstractions into real, physical
modules having high cohesion within the modules and their inter–module
interaction or coupling is low.
 Hierarchy

In Grady Booch’s words, “Hierarchy is the ranking or ordering of

abstraction”. Through hierarchy, a system can be made up of interrelated
subsystems, which can have their own subsystems and so on until the smallest
level components are reached. It uses the principle of “divide and conquer”.
Hierarchy allows code reusability.

The two types of hierarchies in OOA are −

 “IS–A” hierarchy − It defines the hierarchical relationship in inheritance,

whereby from a super-class, a number of subclasses may be derived which
may again have subclasses and so on. For example, if we derive a class Rose
from a class Flower, we can say that a rose “is–a” flower.
 “PART–OF” hierarchy − It defines the hierarchical relationship in
aggregation by which a class may be composed of other classes. For example,
a flower is composed of sepals, petals, stamens, and carpel. It can be said that
a petal is a “part–of” flower.

Typing

According to the theories of abstract data type, a type is a characterization of

a set of elements. In OOP, a class is visualized as a type having properties
distinct from any other types. Typing is the enforcement of the notion that an
object is an instance of a single class or type. It also enforces that objects of
different types may not be generally interchanged; and can be interchanged
only in a very restricted manner if absolutely required to do so.

The two types of typing are −

 Strong Typing − Here, the operation on an object is checked at the time of

compilation, as in the programming language Eiffel.
 Weak Typing − Here, messages may be sent to any class. The operation is
checked only at the time of execution, as in the programming language
Smalltalk.

Concurrency
Concurrency in operating systems allows performing multiple tasks or
processes simultaneously. When a single process exists in a system, it is said
that there is a single thread of control. However, most systems have multiple
threads, some active, some waiting for CPU, some suspended, and some
terminated. Systems with multiple CPUs inherently permit concurrent threads
of control; but systems running on a single CPU use appropriate algorithms to
give equitable CPU time to the threads so as to enable concurrency.
In an object-oriented environment, there are active and inactive objects. The
active objects have independent threads of control that can execute
concurrently with threads of other objects. The active objects synchronize
with one another as well as with purely sequential objects.

Persistence

An object occupies a memory space and exists for a particular period of time.
In traditional programming, the lifespan of an object was typically the
lifespan of the execution of the program that created it. In files or databases,
the object lifespan is longer than the duration of the process creating the
object. This property by which an object continues to exist even after its
creator ceases to exist is known as persistence.

Booch Methodology
The Booch Methodology is an early and influential object-oriented software
development methodology created by Grady Booch. It was designed to
provide a formal and structured approach to software development using
object-oriented principles. This methodology emphasizes the use of object-
oriented concepts like classes, objects, inheritance, and encapsulation to
model and design complex systems.

Booch's work is one of the key foundations for what would later become the
Unified Modeling Language (UML), and the Booch method itself played a
significant role in the evolution of object-oriented modeling.

Key Components of the Booch Methodology:

1. Analysis:
o The first step is to gather the requirements and analyze the system
in terms of objects. This involves identifying the system’s objects,
understanding the problem domain, and developing an object
model.
o Use cases are often employed to capture functional requirements
and describe how users interact with the system.
2. Design:
o The design phase involves transforming the object model from
analysis into a detailed design, where the classes are defined, and
their interactions and relationships are determined.
 o The Booch Methodology uses the abstract design and refined
design stages to iteratively refine the system’s structure and
behavior.
o At this point, class diagrams, object diagrams, and interaction
diagrams are created to represent the detailed design of the system.
3. Implementation:
o Once the design is finalized, the system is implemented using an
object-oriented programming language. This phase involves
coding the classes and their methods, as well as establishing the
relationships between them.
o Since Booch's methodology is closely tied to object-oriented
programming, the implementation phase follows directly from the
design.
4. Testing and Maintenance:
o The final step is testing and maintaining the software. The Booch
methodology advocates for continuous testing throughout the
development process, with each iteration focusing on validating
the system’s behavior against the requirements.
Booch Methodology Phases
The Booch Methodology encompasses several phases that guide the process of object-
oriented analysis and design (OOAD) and software development. These phases include:

1. Requirements Gathering and Analysis

In this initial phase, the focus is on understanding the stakeholders' requirements and
analyzing the problem domain. Requirements are gathered through interactions with
stakeholders, including end-users, clients, and domain experts. The goal is to identify
the functional and non-functional requirements that the software system must fulfill.
2. Object-Oriented Analysis (OOA)
During the OOA phase, the emphasis is on modeling the problem domain using object-
oriented concepts. Object modeling techniques, such as use case diagrams, class
diagrams, and interaction diagrams, are employed to capture the structure, behavior,
and relationships of the system's entities and objects. The goal is to develop a clear
understanding of the problem domain and define the system's requirements in terms of
objects and their interactions.
3. Object-Oriented Design (OOD)
In the OOD phase, the focus shifts to designing the solution architecture based on the
requirements identified during the analysis phase. Design decisions are made regarding
the organization of classes, modules, and components, as well as the definition of
interfaces and relationships between objects. Object-oriented design principles, such as
encapsulation, inheritance, and polymorphism, are applied to ensure modularity,
reusability, and maintainability of the software.
4. Implementation
During the implementation phase, the design specifications are translated into
executable code. Object-oriented programming languages, such as Java or C++, are
typically used to implement the classes and components defined in the design phase.
The emphasis is on writing clean, modular, and well-documented code that adheres to
the design specifications and coding standards.
5. Testing
The testing phase involves verifying and validating the software system to ensure that it
meets the specified requirements and functions correctly. Various testing techniques,
including unit testing, integration testing, and system testing, are employed to identify
and fix defects or bugs in the software. The goal is to ensure the reliability, robustness,
and quality of the software before deployment.
6. Deployment and Maintenance
Once the software has been thoroughly tested and validated, it is deployed into the
production environment for end-users to use. The deployment phase involves activities
such as installation, configuration, and user training. After deployment, the software
enters the maintenance phase, where updates, enhancements, and bug fixes are made to
address evolving user needs and ensure the long-term viability of the system.
By following these phases in the Booch Methodology, software development teams can
systematically analyze, design, implement, test, deploy, and maintain high-quality
object-oriented software systems that meet the needs of stakeholders and end-users.

Advantages of the Booch Methodology:

 Clear Object Representation: By focusing on modeling real-world

objects and their interactions, the Booch Methodology helps developers
organize and structure complex systems.
 Reusability: The object-oriented approach encourages the reuse of
existing classes and components, leading to reduced development time
and improved maintainability.
 Modularization: The emphasis on objects and classes promotes
modularity, making it easier to manage, test, and update individual
components of the system.
 Scalability: Booch’s approach allows for the development of large,
scalable systems by breaking them down into manageable objects and
classes.

Limitations of the Booch Methodology:

 Complexity for Large Systems: The Booch Methodology can be

complex and difficult to manage for very large systems due to the large
number of objects and relationships.
 Learning Curve: For teams not already familiar with object-oriented
principles or modeling techniques, the Booch Methodology can have a
steep learning curve.
 Lack of Specific Process: Unlike some other methodologies like the
Unified Process, Booch doesn't provide as much focus on specific
process steps, which can lead to some flexibility or ambiguity in its
application.

Evolution of the Booch Methodology:

The Booch Methodology has significantly influenced the development of

other modeling methodologies, particularly Unified Modeling Language
(UML), which was developed by Grady Booch, Ivar Jacobson, and James
Rumbaugh. UML consolidated the notations and techniques from various
object-oriented methodologies, including the Booch Methodology, into a
standardized visual language for object-oriented modeling.

Although the Booch Methodology itself is less commonly used today, its
principles are embedded in many modern object-oriented development
practices, particularly those used in UML and Object-Oriented Analysis
and Design (OOAD).

Rumbaugh Methodology

The Rumbaugh Methodology refers to a set of guidelines for Object-Oriented Analysis

and Design (OOAD) that was developed by James Rumbaugh and his colleagues at
Rational Software. This methodology focuses on defining and analyzing the system from
an object-oriented perspective, where both the data and the behaviors of a system are
encapsulated into objects.

The Rumbaugh Methodology is often associated with the Object Modeling Technique
(OMT), which is a framework for object-oriented analysis and design. OMT provides
techniques for modeling and constructing systems using object-oriented principles.

Key Components of the Rumbaugh Methodology:

1. Object Modeling (OMT):

o The primary goal of object modeling is to represent the system as a
collection of interacting objects.
o Objects are identified and their relationships and behaviors are specified.
o The objects are categorized into three types:
 Objects: Represent the entities in the system.
 Classes: Define the blueprints or templates for creating objects.
 Associations: Describe relationships between objects.
2. Dynamic Modeling:
o Focuses on the time-dependent behavior of the system.
o This involves modeling the interaction between objects over time, typically
represented by state diagrams or sequence diagrams.
o The aim is to understand the life cycle of objects and how they interact
during the execution of processes.
3. Functional Modeling:
o Concerned with the functionality or operations that the system must
perform.
o It deals with the processes or transformations in the system and how they
interact with data.
o This can be represented by data flow diagrams or other process-oriented
models.
 4. Use Case Modeling:
o Use cases are utilized to describe how users (or external entities) interact
with the system.
o The goal is to capture functional requirements by outlining scenarios where
the system interacts with users or other systems.
5. Class Diagrams:
o Class diagrams are used to represent the static structure of the system. They
show the classes in the system, their attributes, methods, and the
relationships (associations, inheritance, etc.) between them.
6. Sequence Diagrams:
o Sequence diagrams show the interactions between objects, focusing on the
sequence of messages exchanged between objects.

The Three Phases of the Rumbaugh Methodology:

1. Analysis Phase:
o Identify the problem and the relevant objects.
o Discover and model the key objects, their attributes, and interactions.
o Define the system requirements through use cases.
2. Design Phase:
o Develop a more detailed object model and design the classes, including
their attributes, methods, and relationships.
o Define the internal and external interfaces between objects.
3. Implementation Phase:
o Translate the design into actual code, using an object-oriented programming
language.
o Ensure that the code adheres to the object-oriented principles established
during the design phase.

Advantages of Rumbaugh's Methodology:

 Emphasizes object-oriented principles like encapsulation, inheritance, and

polymorphism.
 Provides clear guidelines for modeling real-world systems.
 Ensures that both the structure and behavior of the system are modeled effectively.
 Helps manage complexity by dividing the system into manageable objects.

Jacobson Methodology

The Jacobson Methodology, also known as the Use Case Driven Object-Oriented
Analysis and Design (OOAD) methodology, was developed by Ivar Jacobson in the
early 1990s. This methodology is particularly focused on the use case as the central tool
for modeling the functional requirements of a system.
Jacobson’s approach emphasizes the importance of understanding user interactions with
the system through use cases, which are descriptions of how users or other systems
interact with the system to achieve a particular goal.

Key Aspects of the Jacobson Methodology:

1. Use Cases:
o Use cases are central to the Jacobson methodology. A use case defines a
sequence of interactions between an actor (usually a user or another system)
and the system to achieve a goal.
o Use cases capture the functional requirements of the system from the
perspective of its end users.
o Actors represent entities that interact with the system, such as users, other
systems, or external devices.
o Use cases are organized into use case diagrams and detailed narratives to
capture scenarios and actions.
2. Object-Oriented Analysis (OOA):
o Object modeling: In this phase, objects are identified based on the
functional requirements captured in use cases.
o The primary goal is to represent real-world entities in terms of objects,
which encapsulate both state (attributes) and behavior (methods).
o Identify classes, objects, associations, and responsibilities to achieve the
system's goals.
3. Object-Oriented Design (OOD):
o Once the objects are identified in the analysis phase, the next step is to
refine and design the system architecture.
o Classes are further refined into design classes, and collaborations (the
interactions between classes) are specified to achieve the functionality
described by the use cases.
o The design phase focuses on mapping the analysis model to a detailed
system design.
4. Responsibilities-Driven Design:
o In the Jacobson methodology, each object or class is designed to take on
specific responsibilities. Responsibilities refer to what an object is
supposed to do and how it does it.
o Objects interact with each other to fulfill their responsibilities. The focus on
responsibilities helps in creating a well-structured, modular system where
each class or object has a clear, manageable role.
5. Iterative Development:
o Jacobson advocates for an iterative and incremental approach to software
development.
 o The methodology stresses the importance of continuously refining the
system through iterations, allowing for changes and feedback throughout
the development process.
o This allows teams to adapt and evolve the system as more is learned about
the requirements and the design.
6. Subsystems:
o Large systems are often decomposed into smaller subsystems or packages
of related classes.
o This helps manage complexity by organizing the system into manageable
components with well-defined interfaces.

Phases in the Jacobson Methodology:

1. Requirements Capture (Use Case Model):

o This is the first phase where the system's functional requirements are
captured through use cases.
o Each use case represents a specific interaction between an actor and the
system.
o The primary goal is to define the system’s functionality as seen by the
users.
2. Analysis:
o Identify objects and their responsibilities based on the use cases.
o Analyze the system in terms of real-world entities (e.g., objects, actors,
scenarios, etc.).
o Create an object model that captures the dynamic and static aspects of the
system.
3. Design:
o Design the system by refining the analysis model and defining
collaborations between objects.
o Specify the design classes and their interactions to achieve the system's
requirements.
o Define interfaces, architectures, and subsystems to ensure scalability and
maintainability.
4. Implementation:
o Translate the design into code using object-oriented programming
languages.
o Each class in the design corresponds to a class in the implementation.
o The system is developed incrementally, with each iteration refining the
design and implementation.

Key Concepts in Jacobson Methodology:

  Use Cases: Descriptions of system interactions that help in identifying functional
requirements.
 Actors: External entities (users or systems) that interact with the system.
 Objects and Classes: Represent real-world entities, and their behavior and data
are encapsulated in the system.
 Responsibilities: Each object or class is assigned specific tasks or responsibilities
to meet the system’s functional needs.
 Iterative Development: The system is developed in iterations, allowing for
continuous feedback and refinement.
 Subsystems: Decomposition of the system into manageable components or
packages.

Advantages of the Jacobson Methodology:

1. User-Centered Focus: Use cases emphasize user interactions, which helps ensure
that the system meets user needs.
2. Clear Requirements: Use cases provide a straightforward way to capture and
communicate system requirements.
3. Modular Design: Emphasis on classes, objects, and responsibilities leads to a
well-structured, modular system.
4. Iterative Process: The iterative development process allows for flexibility and
adapts well to changing requirements.

Challenges:

1. Complexity in Large Systems: As the system grows, the number of use cases and
interactions can become difficult to manage.
2. Focus on Functional Requirements: While use cases are great for capturing
functional behavior, non-functional requirements (like performance, scalability,
etc.) might be harder to represent.

Patterns

In Object-Oriented Analysis and Design (OOAD), patterns refer to reusable solutions to

common design problems that arise during the software development process. These
patterns help designers and developers avoid reinventing the wheel and ensure that best
practices are followed. There are several categories of design patterns in OOAD, and
they are typically classified into three main types: Creational Patterns, Structural
Patterns, and Behavioral Patterns. Below are some of the most widely used patterns in
each category:
1. Creational Patterns

These patterns deal with the process of object creation and help to make the system more
flexible by decoupling the client from the object creation process.

 Singleton Pattern: Ensures a class has only one instance and provides a global
point of access to it.
 Factory Method Pattern: Defines an interface for creating objects, but allows
subclasses to alter the type of objects that will be created.
 Abstract Factory Pattern: Provides an interface for creating families of related
or dependent objects without specifying their concrete classes.
 Builder Pattern: Allows the creation of complex objects step by step. It separates
the construction of a complex object from its representation.
 Prototype Pattern: Creates new objects by copying an existing object, known as
the prototype. This is useful when the cost of creating an object is more expensive
than copying an existing one.

2. Structural Patterns

These patterns focus on the composition of classes or objects and provide solutions for
creating relationships between entities in a flexible way.

 Adapter Pattern: Allows incompatible interfaces to work together by providing a

wrapper that translates the interface of a class into another interface that the client
expects.
 Composite Pattern: Allows you to compose objects into tree-like structures to
represent part-whole hierarchies. Clients can treat individual objects and
compositions of objects uniformly.
 Decorator Pattern: Adds new functionality to an object dynamically without
altering its structure. It involves wrapping the original object in a new class that
adds additional behavior.
 Facade Pattern: Provides a simplified interface to a complex subsystem, making
it easier to use without exposing the internal complexities.
 Flyweight Pattern: Reduces the number of objects created by sharing objects that
are similar in nature, thus improving memory usage and performance.
  Proxy Pattern: Provides a surrogate or placeholder object that controls access to
the real object. It can be used for purposes such as lazy initialization, access
control, and logging.

3. Behavioral Patterns

These patterns are concerned with the interaction between objects, and the
responsibilities of each object in a system.

 Observer Pattern: Defines a one-to-many dependency between objects, so when

one object changes state, all its dependents are notified and updated automatically.
 Strategy Pattern: Allows a family of algorithms to be defined and encapsulated
within a class. Clients can choose an algorithm at runtime based on their needs.
 Command Pattern: Encapsulates a request as an object, allowing users to
parameterize clients with different requests, queue requests, and log the requests
for undo functionality.
 State Pattern: Allows an object to alter its behavior when its internal state
changes. The object will appear to change its class.
 Iterator Pattern: Provides a way to access elements of a collection sequentially
without exposing the underlying representation of the collection.
 Chain of Responsibility Pattern: Allows passing a request along a chain of
handlers. Each handler decides whether to process the request or pass it along to
the next handler in the chain.
 Mediator Pattern: Defines an object that controls the interaction between a group
of objects, making sure that the objects do not communicate directly but through
the mediator.
 Template Method Pattern: Defines the skeleton of an algorithm in a method,
deferring some steps to subclasses. Subclasses can redefine certain steps of the
algorithm without changing its structure.
 Memento Pattern: Captures and externalizes an object's internal state, so that it
can be restored to that state later without violating encapsulation.
 Visitor Pattern: Allows you to add further operations to objects without having to
modify them, by defining a new operation in the visitor class.
Benefits of Using Patterns in OOAD:

 Reusability: Once a pattern is created, it can be reused across multiple projects.

 Scalability and Maintainability: Design patterns make it easier to scale
applications and maintain the code.
 Improved Communication: Patterns provide a common vocabulary and
understanding among team members.
 Efficiency: Patterns solve common problems in efficient ways, improving
development time and reducing errors.

Frameworks

The framework in Object-Oriented Analysis and Design (OOAD) refers to a reusable

structure or set of classes that provides a foundation for developing software
applications. In OOAD, a framework is a pre-designed set of classes and components
that define the structure and behavior of a software system.
 It provides a foundation for building applications by offering a structure that
developers can extend and customize to meet specific requirements.
 They are designed to address common software development challenges and provide
solutions to recurring problems.
 They encapsulate best practices, design patterns, and reusable components, allowing
developers to focus on implementing application-specific functionality rather than
reinventing basic infrastructure.
Some of the features of the framework include:
 Abstraction: Frameworks abstract away low-level details and provide higher-level
abstractions for common tasks and functionalities.
 Reusability: Frameworks are designed to be reused across multiple projects, saving
time and effort by leveraging existing code.
 Extensibility: Frameworks allow developers to extend and customize their
functionality to meet specific project requirements.
 Modularity: Frameworks are typically modular, allowing developers to work on
different parts of the application independently.
 Flexibility: Frameworks are designed to be flexible and adaptable to different
application scenarios and environments.

Unified Approach

The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a

flexible and iterative approach to developing software. It focuses on creating working
software increments, collaborating with team members, and adapting to changes.

What is Unified Process?

Key Principles of Unified Process

Below are the key principles of the Unified Process:
 Iterative and Incremental: Unified Process divides the development process into
multiple iterations, with each iteration adding new functionality incrementally.
 Use Case Driven: The Unified Process focuses on identifying and prioritizing use
cases that represent the system's functionality from the user's perspective.
 Architecture-Centric: The Unified Process emphasizes defining and refining the
system architecture throughout the development process.
 Risk Management: Unified Process identifies and manages project risks
proactively to minimize their impact on the project's success.
 Continuous Validation: Unified Process ensures continuous validation of the
system's requirements, design, and implementation through reviews, testing, and
feedback.
Phases of Unified Process
Unified Process (UP) is characterized by its iterative and incremental approach to
software development. The phases in Unified Process provide a structured framework
for managing the various activities and tasks involved in building a software system.
Here's an in-depth look at each phase:
1. Inception
This is the initial phase where the project's scope, objectives, and feasibility are
determined. Key activities in this phase include identifying stakeholders, defining the
initial requirements, outlining the project plan, and assessing risks. The goal of this
phase is to establish a solid foundation for the project and ensure that it is worth
pursuing.
2. Elaboration
In this phase, the project requirements are analyzed in more detail, and the architecture
of the system is defined. Key activities include developing use cases, creating the
architectural baseline, identifying key components, and refining the project plan. The
goal of this phase is to mitigate major risks and establish a solid architectural
foundation for the project.
3. Construction
This is the phase where the actual implementation of the system takes place. Key
activities include developing, testing, and integrating the system components, as well
as continuously verifying that the system meets the requirements. The goal of this
phase is to build a complete, high-quality software product that is ready for
deployment.
4. Transition
In this final phase, the software is deployed to end users. Key activities include user
training, final system testing, and transitioning the system to the operations and
maintenance team. The goal of this phase is to ensure a smooth transition from
development to production and to address any issues that arise during deployment.
These phases are iterative, meaning that they may be revisited multiple times
throughout the project to incorporate feedback, make improvements, and address
changes in requirements. This iterative approach allows for flexibility and adaptability,
making the Unified Process well-suited for complex and evolving software projects.
Unified Modeling Language

The Unified Modeling Language (UML) plays a central role in Object-Oriented

Analysis and Design (OOAD). UML is a standardized visual language that provides a set
of diagram types for modeling the structure and behavior of object-oriented systems. It
helps developers, architects, and stakeholders communicate complex ideas and designs
in a simple, understandable manner.

What is UML?

Unified Modeling Language (UML) is a standardized visual modeling language that is

a versatile, flexible, and user-friendly method for visualizing a system’s design.
Software system artifacts can be specified, visualized, built, and documented with the
use of UML.
 We use UML diagrams to show the behavior and structure of a system.
 UML helps software engineers, businessmen, and system architects with modeling,
design, and analysis.
Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of elements
and forms associations between them to form diagrams. Diagrams in UML can be
broadly classified as:
1. Structure Diagrams

Structure diagrams represent the static aspects of the system. They show how the system
is organized, its components, and their relationships.

Class Diagram:

o The most commonly used structure diagram.

o Represents the classes, interfaces, and their relationships (associations,
inheritance, etc.).
o Shows the attributes and methods of classes.
o Useful for representing the static structure of the system and understanding
object relationships.
Component Diagram:

o Depicts the physical components of the system, such as modules or

subsystems.
o Shows how components interact and how they are related.
o Helps with system architecture planning.

Composite Structure Diagram:

o Shows the internal structure of a class, including its relationships with other
classes and components.
o Helps to describe how individual objects or parts of an object interact with
each other.

Deployment Diagram:

o Describes the physical deployment of the software system.

o Shows the hardware nodes (e.g., servers, workstations) and the software
components deployed on those nodes.
 o Used for system infrastructure design and configuration.

Package Diagram:

o Represents how the system is organized into packages (groups of related

classes).
o Shows dependencies between packages.
o Helps in modularizing and managing large systems.
2. Behavior Diagrams

Behavior diagrams represent the dynamic aspects of the system. They focus on how
objects or components interact, how they change states, and how the system behaves
over time.

 Use Case Diagram:

o Represents the functional requirements of the system from the user’s
perspective.
o Shows actors (users or external systems) and use cases (specific interactions
or functions the system performs).
o Helps in identifying system functionality and how it should be used.
 Sequence Diagram:
o Shows how objects interact with each other in a sequence over time.
o Describes the flow of messages and method calls between objects.
o Useful for modeling interactions between system components in specific
scenarios.

 Communication Diagram (formerly known as Collaboration Diagram):

o Similar to sequence diagrams but focuses on the relationships between
objects, rather than the sequence of messages.
 o Shows how objects are connected and interact via messages, highlighting
their collaborations.

 State Diagram (State Machine Diagram):

o Describes the states that an object can be in and the transitions between
those states.
o Useful for modeling the life cycle of an object and how it reacts to events.
o Often used to model reactive systems (e.g., a user interface or a workflow
system).
 Activity Diagram:
o Represents workflows and the flow of control in a system.
o Shows activities, decisions, and concurrent actions.
o Useful for modeling business processes, system operations, or complex
control flows.

 Interaction Overview Diagram:

o Combines elements of activity diagrams and sequence diagrams to provide
a high-level overview of interactions within a system.
o Focuses on controlling the flow of interactions between different
components or subsystems.
3. Additional UML Diagrams

 Timing Diagram: Focuses on the timing constraints of interactions between

objects over time. Used for real-time systems.
 Profile Diagram: Allows customization of UML to adapt it to a specific domain
or platform, adding new stereotypes and extending the language.