Unit 3

Object Oriented Analysis – Identifying Use-Cases: Complexity in Object Oriented

Analysis, Business Process Modelling and Business Object Analysis, Use-Case Driven
Object-Oriented Analysis, Use-Case Model and Documentation.

Types of software:

• Personal or limited use software.

• Industrial used software.

Personal or Limited Use Software refers to software designed for individual users or a small
group with specific and limited, functionality. This type of software is typically tailored for
personal tasks, small-scale projects, or a specific user base, rather than large, enterprise-level
applications.

Characteristics of Personal or Limited Use Software:

• Limited Scope: The software usually addresses a specific need, like personal
organization, note-taking, or small business management, rather than being a
comprehensive solution.
• Single User or Small Group: It is designed for a single user or a limited number of users
rather than a large organization or a wide audience.
• Simple Interface: Personal use software tends to have a user-friendly, straightforward
interface that doesn’t require specialized training.
• Cost-Effective: Often, personal or limited use software is available as free, freemium, or
low-cost paid versions, making it affordable for individual users.

Examples of Personal or Limited Use Software:

• Microsoft OneNote (Personal Productivity Software):

 Purpose: Designed for personal note-taking and organization.
o Example Use: A student may use OneNote to organize lecture notes, create to-do
lists, or track personal projects.
o Features: Includes text, image, audio notes, collaboration, and cloud syncing.

Industrial-use software refers to specialized software developed to support industrial processes,

manage operations, and optimize efficiency in various sectors such as manufacturing,
engineering, energy, transportation, and more. This type of software is designed to handle large-
scale operations, complex systems, and often integrates with hardware and machinery to
automate and improve workflows.
Characteristics of Industrial-Use Software:

• Complexity: Industrial software handles intricate processes, often involving large data
sets, real-time monitoring, and interaction with multiple systems.
• Scalability: It is built to scale up, capable of handling a large number of users, devices,
or transactions, depending on the size of the industry.
• Customization: Industrial software is often tailored to meet specific needs of the industry
or business, with features that cater to particular industrial processes.
• Integration: It frequently integrates with existing enterprise systems like Enterprise
Resource Planning (ERP), Supervisory Control and Data Acquisition (SCADA), or
Internet of Things (IoT) networks for machine communication.
• Automation: Many industrial applications focus on automating repetitive tasks,
monitoring operations, and even predictive maintenance.
• High Reliability: Industrial software must be highly reliable, with minimal downtime,
because errors in such environments can lead to costly delays or safety hazards.

Enterprise Resource Planning (ERP):

• Purpose: ERP systems manage business processes by integrating various functions like
finance, inventory, procurement, and human resources.
• Industries: Manufacturing, retail, logistics, and supply chain management.
• Example Use: A manufacturing company uses ERP software like SAP or Oracle to track
inventory, manage supply chain logistics, and automate financial reporting.
• Features: Integrated modules for procurement, inventory management, accounting, HR,
and production planning.
Inherent complexity derives from four elements:
• The Complexity of the Problem Domain •
• The Difficulty of Managing the Development Process
• The Flexibility Possible through Software
• The Problems of Characterizing the Behavior of Discrete Systems

Inherent complexity in software systems arises from four key elements: the Complexity of the
Problem Domain, the Difficulty of Managing the Development Process, the Flexibility
Possible through Software, and the Problems of Characterizing the Behavior of Discrete
Systems. Each of these elements contributes to the intrinsic difficulty of creating and
maintaining software systems. Let’s explain each with examples.
1. The Complexity of the Problem Domain

Explanation: This type of complexity arises from the nature of the domain or the problem that
the software aims to solve. Some domains, like finance, stock market, Bank, Library, healthcare,
and aviation, have complex rules, regulations, and interactions, making the software inherently
difficult to design and implement.

• 1. Technical Factors:

These are challenges related to the technology, architecture, and functionality of the software.

Regulatory Compliance:

Explanation: Some domains like healthcare (HIPAA), finance (SEC), or aviation (FAA)
have stringent regulations that software must comply with.
Example: A healthcare system must ensure patient data privacy, encryption, and logging
of all access to comply with regulations like HIPAA.

Real-Time Data Processing:

Explanation: Certain systems, like stock trading platforms or air traffic control systems,
require processing vast amounts of data in real-time with minimal latency.
Example: In a stock trading system, a delay of even milliseconds can result in financial
losses due to the fast pace of trades.

Integration with Legacy Systems:

Explanation: Many industries rely on older systems that new software must integrate
with to function effectively.
Example: In finance, a new trading platform may need to integrate with existing systems
for processing trades and market data.

Security and Data Privacy:

Explanation: Domains like healthcare, banking, or e-commerce handle sensitive data

(e.g., personal health information, financial records) that must be protected from
breaches.
Example: A banking app must implement encryption, multi-factor authentication, and
regular security audits to protect user accounts from hackers.
Handling Complex Workflows:

Explanation: Some domains involve intricate, multi-step workflows that must be

accurately modeled and automated by the software.
Example: An aviation system must handle flight scheduling, pilot communication, and
real-time monitoring of planes in airspace.

2. Non-Technical Factors:

These are challenges related to people, communication, and organizational factors.

Communication Gaps:

Explanation: Miscommunication between different stakeholders (e.g., developers,

business users, and project managers) can lead to misunderstandings and poorly defined
requirements.
Example: A hospital might need a specific feature for patient record handling, but if
doctors and IT staff don’t clearly communicate, the feature might be left out or poorly
implemented.

Evolving Requirements:

Explanation: As businesses grow or regulations change, software requirements often

evolve, adding complexity to development and maintenance.
Example: A banking system might need to be updated frequently to comply with new
anti-money laundering laws, requiring continuous revisions and testing.

3. Domain-Specific Challenges:

• These challenges are unique to the specific industry or problem domain.

Complex Domain Knowledge:

Explanation: Some problem domains, like healthcare or finance, require specialized

knowledge that can be difficult to translate into software design.
Example: In a healthcare system, understanding medical terminology, patient workflows,
and insurance claims processing can be complex for developers without healthcare
experience.
High Stake Decisions:

Explanation: In domains like aviation or stock trading, errors or delays can have
catastrophic consequences, making the software extremely sensitive to errors.
Example: In air traffic control systems, a software glitch could lead to flight collisions,
making safety critical and error-free operations essential.

Multiple User Roles:

Explanation: Some systems need to handle different roles with varying access levels and
permissions, increasing the complexity of design.
Example: In a hospital management system, doctors, nurses, admin staff, and patients all
need different access rights to the system.

Large Volume of Data:

Explanation: Domains like finance or social media require systems that can manage and
process large volumes of data efficiently.
Example: A stock trading platform must handle millions of transactions daily, with real-
time updates to stock prices and market data.

The Difficulty of Managing the Development Process (Short Version)

Introduction

Managing the software development process is complex due to various factors affecting
timelines, costs, and project success.

Key Challenges

• Evolving Requirements:
o Explanation: Requirements can change due to market trends or user feedback,
leading to scope creep.
o Example: A banking app's initial features may expand due to user requests for
budgeting tools.
• Communication Barriers:
o Explanation: Miscommunication among stakeholders can lead to
misunderstandings about project goals.
o Example: Misalignment between the marketing team and developers can result in
a product that doesn’t meet user expectations.
 • Resource Management:
o Explanation: Effectively managing time, budget, and personnel is challenging;
understaffing can lead to burnout.
o Example: A team lacking specialized skills may face delays and quality issues.
• Technical Debt:
o Explanation: Short-term solutions can accumulate and hinder future
development.
o Example: Quick fixes for bugs may lead to more significant issues later on.
• Risk Management:
o Explanation: Identifying and mitigating risks is crucial; neglecting this can result
in project delays.
o Example: Failing to account for new data privacy regulations may lead to
compliance issues.
• Stakeholder Involvement:
o Explanation: Conflicting interests among stakeholders can complicate decision-
making.
o Example: Balancing usability and compliance needs in a healthcare project can
be challenging.

Discussion Questions

• What challenges have you faced in software development?

• How can organizations better handle changing requirements?

The Flexibility Possible through Software

In Object-Oriented Analysis and Design (OOAD), software flexibility refers to the ability of a
system to adapt to new requirements with minimal changes. This flexibility is a core principle in
OOAD and can be achieved through various design strategies:

• Encapsulation: Hiding internal details of objects allows the system to change internal
implementations without affecting other parts.
o Example: A Car class encapsulates its engine, and if the engine implementation
changes, other objects interacting with Car remain unaffected.
• Inheritance: Promotes code reuse and flexibility by allowing new functionalities to be
added through subclassing.
o Example: A Vehicle class can be extended by Car and Bike classes, allowing
flexibility to add more types without changing existing code.
• Polymorphism: Enables objects to be processed differently based on their data type or
class, providing flexibility in method handling.
 o Example: A function accepting a Vehicle can work with Car, Truck, or any new
vehicle types added later.
• Design Patterns: Patterns like Factory, Strategy, or Observer allow flexible designs by
decoupling components, making it easier to adapt to new requirements.

Civil Construction:

42. Material Sourcing: Construction projects depend heavily on external vendors for raw
materials like timber, steel, cement, and glass. These materials are sourced from
specialized suppliers who ensure their quality and availability.
43. Uniform Standards: There are well-established building codes and standards that govern
the quality and specifications of materials. These codes must be followed to ensure
safety, structural integrity, and compliance with legal regulations.
44. Limited Flexibility in Changes: Modifications to existing structures, especially large
ones, are uncommon and complex. For example, adding a new sub-basement to a 100-
story building would be an extremely difficult and costly endeavor, requiring detailed
planning, high costs, and significant risks.

Software Development:

45. Component Creation: Unlike construction, software development teams often create
their own components instead of relying on external suppliers. Since software is
inherently a flexible medium, teams can build their required modules or functionalities
internally, adapting them as needed.
46. Few Standards: Unlike civil construction, software development lacks uniform
standards for reusable components. While some best practices exist, there is no universal
regulation ensuring that every piece of code is interchangeable or adheres to a specific
quality.
47. Flexibility in Changes: Software systems are far more adaptable than physical
structures. Users often request significant changes, like adding new features or
completely reworking parts of the system. Unlike in construction, where large-scale
modifications are rare, software can often accommodate these changes with less
complexity, making it a much more dynamic field.

The Problems of Characterizing the Behavior of Discrete Systems

Discrete Systems in Software:

• Software systems are built and executed on digital computers, which process discrete
data in distinct steps. This makes them discrete systems because they operate in a
defined, finite number of states, unlike continuous systems that change smoothly.

Complexity in Large Applications:

• Variables: In a large application, there could be hundreds or thousands of variables, each

holding specific values. These variables represent object properties, class attributes, or
method parameters.
• Threads of Control: In OOAD, multiple objects often operate concurrently, and in a
large application, there can be more than one (often several) threads of control,
representing multiple objects or processes executing at the same time. Each thread may
represent different objects performing various tasks.

Business Process Modelling (BPM) and Business Object Analysis (BOA) are techniques
used to design and analyze the workflow of a business and the key entities or objects
involved in that workflow. Both are essential in understanding how a business operates and
how a software system can support and improve those operations.

Business Process Modelling (BPM)

Business Process Modelling (BPM) is the technique of mapping and visualizing the steps and
flow of a business process. It helps in understanding, analyzing, and improving business
processes by creating a visual representation of the tasks, decisions, and interactions that take
place to achieve a specific goal.

Uses of BPM:

• Process Understanding: Helps teams understand how work is done within an

organization by visualizing each step.
• Process Improvement: Identifies inefficiencies, bottlenecks, or unnecessary steps to
improve overall efficiency.
• Automation: Helps in identifying areas where tasks can be automated.
• Communication: Facilitates clear communication among stakeholders by providing a
common understanding of business processes.
Example of BPM: Order Processing in E-Commerce

In an e-commerce business, the order processing workflow might include:

• Customer places order: Customer selects products and submits an order.

• Inventory check: System checks if the items are in stock.
• Payment processing: Payment is authorized and processed.
• Order fulfillment: Items are packed and shipped to the customer.
• Order completion: The customer receives a confirmation and tracking details.

This flow can be modeled using a flowchart or BPMN diagram to map each task and decision.
The visual representation makes it easy to see how the process works, where delays or errors
could happen, and where improvements are possible.

Business Object Analysis (BOA)

Business Object Analysis (BOA) focuses on identifying and defining the key business objects
that the system or business interacts with. These objects represent real-world entities like
Customer, Order, Product, and Invoice, and they are central to the functioning of the system.

Uses of BOA:

• Entity Identification: Helps identify the key business objects or entities relevant to the
business domain.
• Data Organization: Defines the attributes and relationships between these objects,
ensuring data is well-structured.
• System Design: BOA ensures that the system handles real-world business objects in a
way that reflects the business's needs and processes.
• Consistency: Ensures that data is consistent and relationships between objects are
correctly modeled, reducing errors and improving system performance.

Example of BOA: Online Shopping System

In the same e-commerce business, the key business objects might be:

• Customer: Stores customer details like name, email, address.

• Order: Represents customer orders, with attributes like orderID, date, and totalAmount.
• Product: Contains product information such as productID, name, and price.
• Payment: Manages payment transactions, with attributes like paymentID, paymentDate,
and amount.
In Business Object Analysis, these objects are analyzed, and a UML class diagram can be
created to show the attributes and relationships. For example:

• A Customer can place multiple Orders.

• Each Order contains one or more Products.
• Each Payment is linked to a specific Order.
Questions:
1. In the online shopping example, how would you define the relationship between a
Customer and Order in a UML class diagram?
2. What would be the impact on the system if the relationship between Payment and Order
is not clearly defined?
3. How would you handle a scenario where a customer cancels an order after payment in
terms of business object interactions?
4. If a new payment method is introduced to the system, how would you modify the existing
business objects and relationships?
5. How can BOA help improve communication between business analysts and software
developers?

Answers:

1. In the online shopping example, how would you define the relationship between a
Customer and Order in a UML class diagram?

In a UML class diagram, the relationship between a Customer and an Order is typically defined
as a one-to-many relationship. This means that:

• One Customer can place multiple Orders.

• Each Order is linked to only one Customer.

In the diagram:

• The Customer class will have attributes like customerID, name, email, and address.
• The Order class will have attributes like orderID, orderDate, and totalAmount.
• There will be an association between the two classes, with a line connecting them. The
multiplicity will be 1 near the Customer class (indicating one customer), and * near the
Order class (indicating multiple orders).
2. What would be the impact on the system if the relationship between Payment and Order
is not clearly defined?

If the relationship between Payment and Order is not clearly defined, several issues may arise:

• Inconsistent Data: The system may not properly track which order a payment belongs
to, leading to confusion in financial records. For example, payments could be
misallocated or not linked to the correct order.
• Failed Transactions: Orders might be processed without confirming whether payment
has been received. This could lead to shipping products without payment confirmation or
customers being charged incorrectly.
• Difficulty in Refunding: If a payment is not linked to a specific order, processing
refunds or handling payment disputes would be extremely challenging, leading to poor
customer service and financial loss.
• Lack of Auditability: It would be difficult to audit financial records, as there would be
no clear connection between orders and their payments, creating accountability issues.

3. How would you handle a scenario where a customer cancels an order after payment in
terms of business object interactions?

In the case where a customer cancels an order after payment, several business object interactions
would take place:

• The Order status would be updated to "Cancelled."

• The Payment object linked to the order would trigger a refund process. This could
involve creating a new Refund object, which is linked to the original Payment and
Order.
• The Inventory (Product stock) system would be updated if the order items had already
been reserved or shipped. If products were allocated, they would be returned to available
stock.
• Depending on the system, the Customer object may receive a notification of the
cancellation and refund process.

This series of interactions ensures that the customer gets their money back, and the system
maintains accurate records.

4. If a new payment method is introduced to the system, how would you modify the existing
business objects and relationships?

If a new payment method is introduced, the following changes would be made to the business
objects:
 • A new subclass or attribute would be added to the Payment class to accommodate the
new payment type (for example, paymentType could now include options like "Credit
Card", "PayPal", or the new method).
• A new object could be created if the new payment method has unique attributes or
processes (e.g., a DigitalWallet class could be created for e-wallet payments).
• The relationship between Order and Payment would remain the same, but the Payment
class might have to accommodate the new method's unique processing, authorization, and
confirmation flows.
• If the new payment method involves an external API (e.g., integration with a third-party
payment provider), additional integration points would need to be modeled.

This update ensures that the system remains flexible and scalable to accept future payment
methods.

5. How can BOA help improve communication between business analysts and software
developers?

BOA improves communication between business analysts and software developers in several
ways:

• Clear Understanding of Business Needs: BOA provides a structured way to define

business objects and their relationships, ensuring that developers understand the core
entities the business works with and the associated processes. This bridges the gap
between business requirements and technical implementation.
• Standardized Terminology: Business object analysis encourages the use of consistent,
standardized terms for key objects, reducing the risk of miscommunication between non-
technical (business analysts) and technical (developers) teams.
• Visual Representation (UML Diagrams): BOA often results in UML class diagrams or
entity-relationship diagrams that visually represent business objects and their
relationships. These diagrams serve as a common language, allowing both analysts and
developers to see how objects should be structured.
• Early Detection of Errors: By analyzing business objects early on, BOA helps ensure
that all entities and relationships are clearly defined before development begins, reducing
the chance of errors and rework later in the project lifecycle.
• Requirement Traceability: BOA helps track how specific business requirements
translate into system design, ensuring that developers implement features aligned with
business goals.

Use-Case Driven Object-Oriented Analysis

Use-Case Driven Object-Oriented Analysis (OOA) is a methodology that emphasizes the
identification and development of software systems by focusing on use cases—the scenarios or
functional requirements that describe how users interact with the system. It helps bridge the gap
between what users need and how the system will be designed.

Key Steps:

• Identify Use Cases: The process begins by identifying the key use cases—the specific
interactions or actions that the users (or actors) will perform with the system.
• Develop Use Case Models: These use cases are documented in a use case diagram that
shows the relationships between actors (users or systems) and the use cases. Each use
case represents a specific piece of functionality or goal.
• Analyze Use Cases: The next step involves breaking down the use cases to identify the
system's objects (e.g., classes) and their responsibilities. Each use case helps define the
objects, attributes, methods, and interactions.
• Refine with Class Diagrams: Based on the use cases, class diagrams are created to
represent the static structure of the system—showing the objects (classes) and their
relationships.
• Iterative Development: As the system grows and more use cases are added, the design
evolves iteratively. Each iteration refines the system’s objects, methods, and interactions.

Students Work:

• Draw use case diagram for College ERP, then break down the use cases to identify
the system's objects (e.g., classes) and their responsibilities. Based on the use cases,
class diagrams are created to represent the static structure of the system—showing
the objects (classes) and their relationships.

1. Drawing the Use Case Diagram for College ERP:

A Use Case Diagram represents the interactions between different actors (users or other
systems) and the system itself. For a College ERP system, the following actors and use cases
could be identified:

Actors:

• Student: Enrolls in courses, checks grades, makes payments.

• Teacher: Manages course content, grades students, and communicates with students.
• Administrator: Manages users, schedules, fees, and academic records.
• Librarian: Manages library resources and student borrowings.
 • Accountant: Manages student fee payments and financial records.

Use Cases:

• Student:
 Enroll in courses.
 View grades.
 Pay fees.
 Access library resources.
• Teacher:
 Manage courses (create, update course material).
 Grade students.
 Communicate with students (send messages or announcements).
• Administrator:
 Manage user accounts (add/edit students, teachers).
 Schedule academic calendar.
 Manage fee structure.
• Librarian:
 Manage books (add new books, update availability).
 Track borrow and return of books.
• Accountant:
 Process student fee payments.
 Generate fee receipts.

Use Case Diagram:

Based on this information, you would draw the Use Case Diagram with:

• Actors outside the system (Student, Teacher, Administrator, Librarian, Accountant).

• Use Cases (Enroll in Courses, View Grades, Pay Fees, etc.).
• Relationships between actors and use cases (e.g., Students will be linked to "Enroll in
Courses," "View Grades," etc.).

2. Break Down the Use Cases to Identify System’s Objects (Classes):

Once you’ve identified the use cases, the next step is to break them down to identify potential
objects or classes in the system. These objects represent entities in the College ERP system.
From the Use Cases, we can derive the following classes:

• Student: Attributes like studentID, name, email, enrollmentYear. Methods like

enrollInCourse(), viewGrades(), payFees().
• Course: Attributes like courseID, courseName, creditHours. Methods like addStudent(),
updateContent().
• Teacher: Attributes like teacherID, name, department. Methods like manageCourse(),
gradeStudent(), sendMessage().
• Administrator: Attributes like adminID, name. Methods like manageUsers(),
manageSchedules(), manageFees().
• Library: Attributes like bookID, title, availability. Methods like issueBook(),
returnBook(), addBook().
• Payment: Attributes like paymentID, amount, date. Methods like processPayment(),
generateReceipt().

3. Creating the Class Diagram Based on Use Cases:

Now that we’ve identified the primary classes (Student, Teacher, Course, Administrator, etc.),
we can move on to create the Class Diagram. A Class Diagram represents the static structure of
the system, showing the objects (classes), their attributes, methods, and relationships.

Classes & Attributes:

• Student:
 Attributes: studentID, name, email, enrollmentYear.
 Methods: enrollInCourse(), viewGrades(), payFees().
• Course:
 Attributes: courseID, courseName, creditHours.
 Methods: addStudent(), updateContent().
• Teacher:
 Attributes: teacherID, name, department.
 Methods: manageCourse(), gradeStudent(), sendMessage().
• Administrator:
 Attributes: adminID, name.
 Methods: manageUsers(), manageSchedules(), manageFees().
• Library:
 Attributes: bookID, title, availability.
 Methods: issueBook(), returnBook(), addBook().
• Payment:
  Attributes: paymentID, amount, date.
 Methods: processPayment(), generateReceipt().

Relationships:

1. Student to Course:
a. A Student enrolls in Courses.
b. This relationship is a many-to-many association (since a student can enroll in
multiple courses and each course can have multiple students).
2. Teacher to Course:
a. A Teacher manages Courses.
b. This is a one-to-many relationship (a teacher can teach many courses, but a
course is typically taught by one teacher).
3. Administrator to Student/Teacher:
a. An Administrator manages Students and Teachers (for user management
tasks).
b. This is a one-to-many relationship (one administrator manages many students
and teachers).
4. Library to Student:
a. A Library interacts with Students for issuing books.
b. This is a many-to-many relationship (students can borrow multiple books, and
each book can be borrowed by multiple students).
5. Payment to Student:
a. A Payment is made by a Student for fees.
b. This is a one-to-many relationship (a student can make multiple payments, but
each payment is linked to one student).

Class Diagram:

• Student (attributes: studentID, name, email, enrollmentYear; methods: enrollInCourse(),

viewGrades(), payFees())
• Course (attributes: courseID, courseName, creditHours; methods: addStudent(),
updateContent())
• Teacher (attributes: teacherID, name, department; methods: manageCourse(),
gradeStudent(), sendMessage())
• Administrator (attributes: adminID, name; methods: manageUsers(),
manageSchedules(), manageFees())
• Library (attributes: bookID, title, availability; methods: issueBook(), returnBook(),
addBook())
 • Payment (attributes: paymentID, amount, date; methods: processPayment(),
generateReceipt())

Relationships:

• Student — Enrolls in — Course (many-to-many)

• Teacher — Manages — Course (one-to-many)
• Administrator — Manages — Student, Teacher (one-to-many)
• Library — Issues books to — Student (many-to-many)
• Payment — Made by — Student (one-to-many)

This Class Diagram will visually represent the relationships and structure of the system. Each
class will show its attributes, methods, and how it connects with other classes, providing a
detailed static model of the College ERP system.

Example: Online Shopping System

Let’s use an online shopping system as an example to explain how Use-Case Driven Object-
Oriented Analysis works:

Step 1: Identify Use Cases

Some possible use cases for an online shopping system:

• Browse Products: A customer browses the catalog of products.

• Add to Cart: The customer adds items to their shopping cart.
• Checkout: The customer completes the purchase by entering payment and shipping
information.
• Track Order: The customer checks the status of their order.

Step 2: Develop Use Case Models

A use case diagram could look like this:

• Actors:
o Customer: Interacts with the system to browse, add to cart, checkout, and track
orders.
o Admin: Manages product inventory and customer orders.
• Use Cases:
o Customer interacts with "Browse Products", "Add to Cart", "Checkout", and
"Track Order".
 o Admin interacts with "Manage Products" and "Manage Orders".

Step 3: Analyze Use Cases

For the Checkout use case, we might identify the following:

• Objects/Classes:
o Customer: Stores customer details.
o Cart: Represents a shopping cart holding selected items.
o Order: Represents the customer’s order.
o Payment: Handles payment processing.
• Interactions:
o The Customer class interacts with the Cart class to finalize the selection of
items.
o The Order class generates an order, and Payment handles the payment process.
Design Principles of Object Oriented, UML Object Constraint Language, Planning and
Strategies for Designing Classes.

1. Design Principles of Object-Oriented Programming (OOP)

Object-Oriented Programming (OOP) is a programming paradigm centered on the concept of

objects, which are instances of classes. The design principles of OOP help in creating more
robust, reusable, and scalable code. These principles can be summarized by key concepts like
encapsulation, inheritance, polymorphism, and abstraction.

Key Design Principles:

Encapsulation:

• Definition: Encapsulation is the bundling of data (attributes) and methods (functions)

that operate on the data into a single unit called a class. It also restricts direct access to
some of an object's components, which is a means of preventing accidental interference
and misuse.
• Example: Think of a car. You don’t need to know the internal workings of the engine to
drive it; you just use the interface (steering wheel, pedals) provided.
• Example:
class Car {
private String model;
private int speed;

public Car(String model) {

this.model = model;
}

public void accelerate(int increment) {

speed += increment;
}

public int getSpeed() {

return speed;
}
}

• The speed is private and can only be changed using methods, maintaining control over
how the data is modified.
 Abstraction:

• Definition: Abstraction focuses on hiding the complex implementation details and

showing only the essential features of an object. It helps in reducing complexity by
allowing you to work at a higher level without worrying about low-level details.
• Example: A TV remote is an abstraction of a TV. You don't need to know how the TV
works internally; you just need the remote to change channels or adjust the volume.
• Example:
abstract class Animal {
abstract void sound();
}

class Dog extends Animal {

public void sound() {
System.out.println("Barks");
}
}

class Cat extends Animal {

public void sound() {
System.out.println("Meows");
}
}

Inheritance:

• Definition: Inheritance allows a new class to inherit the properties and behaviors
(methods) of an existing class. This promotes code reusability and logical hierarchy.
• Example: A child inherits characteristics from the parents. Similarly, a class can inherit
properties from a parent class.
• Example:
class Vehicle {
public void move() {
System.out.println("Vehicle is moving");
}
}

class Car extends Vehicle {

public void move() {
 System.out.println("Car is moving");
}
}

Polymorphism:

•
Definition: Polymorphism allows one interface to be used for a general class of actions.
The specific action is determined by the exact nature of the situation. In simpler terms, a
method or object can take multiple forms.
• Example: A person can act as a father, employee, and friend. Depending on the context,
the person behaves differently.
• Example:
class Animal {
public void sound() {
System.out.println("Animal is making a sound");
}
}

class Dog extends Animal {

public void sound() {
System.out.println("Dog barks");
}
}

class Cat extends Animal {

public void sound() {
System.out.println("Cat meows");
}
}

SOLID Principles:

The SOLID principles are a set of guidelines that help make OOP systems more maintainable
and scalable.

• Single Responsibility Principle (SRP):

A class should have one, and only one, reason to change. Each class should be
responsible for a single part of the functionality.
• Liskov Substitution Principle (LSP):
 Objects of a superclass should be replaceable with objects of a subclass without
affecting the correctness of the program.
• Interface Segregation Principle (ISP):
No client should be forced to depend on methods it does not use.

2. UML Object Constraint Language (OCL)

The Object Constraint Language (OCL) is a formal language used to describe expressions on
UML models. These expressions typically specify invariant conditions that must hold true for the
system being modeled. OCL is used to add precision to the UML diagrams by allowing
constraints to be placed on the objects and relationships.

Key Concepts of OCL:

• Invariants:
These are conditions that must always hold true for all instances of a class.
• Pre-conditions and Post-conditions:
Pre-conditions specify what must be true before an operation is executed.
Post-conditions specify what must be true after the operation has been executed.
• Example: Suppose we have a class BankAccount, and we want to specify that the
balance must never be negative.
OCL Expression:

context BankAccount
inv: self.balance >= 0

3. Planning and Strategies for Designing Classes

Designing classes is a critical part of Object-Oriented Design. Effective class design ensures that
the system is modular, flexible, and maintainable.

Steps for Class Design:

• Identify Classes from Requirements:

Analyze the problem domain to identify potential classes. Look for nouns in the
problem description, which often map to objects in the system.
 • Define Responsibilities:

Determine what each class should do. Responsibilities should align with the
Single Responsibility Principle (SRP).

• Define Relationships Between Classes:

Classes often interact with each other. Use association, aggregation, and
composition to describe how objects will interact. You may also use inheritance
where applicable.

• Design for Flexibility:

Design classes that are flexible and can accommodate future changes. Use the
Open/Closed Principle to ensure your classes are open to extension but closed to
modification.

Strategies for Class Design:

• Modularity:

Break the system down into small, reusable components. Each module or class
should handle one aspect of the problem domain.

• Information Hiding:

Hide the internal details of how a class works. Only expose what is necessary
through a well-defined interface.

• Low Coupling:

Design classes to be as independent as possible. A loosely coupled system is more

flexible and easier to maintain.

• High Cohesion:

Ensure that all the methods and attributes within a class are closely related to its
purpose. High cohesion leads to more focused and manageable classes.

Example:

Suppose we are designing a Library Management System. Following good design principles,
we might have classes like Book, LibraryMember, Loan, etc.
• Book class would manage information about a book (title, author, ISBN, etc.).
• LibraryMember would manage information about library users.
• Loan class would manage the loaning of books.