GROUP 3

PRESENTATION

PRESENTED BY: 2023-CS-15, 2023-CS-01, 2023-CS-09, 2023-CS-17, 2023-CS-19.

PRESENTED TO: SIR ABDUL BASIT
SOFTWARE ENGINEERING
INTRODUCTION TO OBJECT-ORIENTED DESIGN USING UML

AN OVERVIEW OF OBJECT-ORIENTED CONCEPTS AND UML MODELS

PRESENTED BY 2023-CS-15
LAIBA HAMID
OBJECT-ORIENTED DESIGN (OOD)
 Definition: OOD is a method of design that organizes a system into classes of
objects that interact with each other.
 Key Principles:
• Encapsulation: Hiding the internal state of an object and requiring all
interaction to be performed through well-defined interfaces.
• Inheritance: A mechanism where a new class derives properties and
behaviors from an existing class.
• Polymorphism: The ability for objects of different classes to be treated as
objects of a common superclass.
• Abstraction: Hiding complex reality while exposing only the necessary
parts of the system.
WHY USE OOD?

 Modularity: Divides the system into smaller, reusable modules

(classes).
 Maintainability: Easier to maintain due to separation of concerns and
reusable code.
 Scalability: Simplifies extending systems with new features.
 Flexibility: Adapts well to change with minimal disruption.
UNIFIED MODELING LANGUAGE (UML)

 UML (Unified Modeling Language) is a standardized modeling language used

to design, visualize, and document object-oriented systems.
 Purpose:
• Helps in understanding system architecture.
• Provides a visual representation for better communication.
• Documents the design and behavior of a system.
KEY UML DIAGRAMS IN OOD

• Class Diagram: Represents the structure of classes and their relationships.

• Use Case Diagram: Depicts system functionalities from the user’s
perspective.
• Sequence Diagram: Shows object interactions over time.
• Activity Diagram: Models workflows and business processes.
Example: For an e-commerce system:
• Class Diagram: Product, Order, Customer, and their relationships.
• Use Case Diagram: Actions like "Make Payment", "View Cart".
• Sequence Diagram: Interaction between the User and System when placing an
order.
CONCLUSION OF INTRODUCTION TO OOD USING UML:

 Object-Oriented Design (OOD) focuses on modeling real-world objects and their

interactions.
 UML provides a powerful toolset to visually represent OOD concepts and system
behavior.
 Using OOD and UML together leads to better system design, documentation, and
maintainability.
SYSTEM CONTEXT AND
INTERACTIONS
UNDERSTANDING THE BOUNDARIES AND INTERACTIONS OF
SOFTWARE SYSTEMS
SYSTEM CONTEXT

 Definition: System context defines the environment in which the software

operates and its interactions with external entities (users, other systems,
hardware).
 Key Points:
• External Entities: Users, systems, devices.
• Interfaces: Communication points between the system and external entities.
• Boundaries: What is inside and outside the system.
 Purpose: Provides a high-level view of the system’s environment and
interactions.
SYSTEM INTERACTION

 Definition: Describes how the system interacts with external entities during
operation, focusing on data exchange, actions, and communication.
 Purpose: Models the dynamic interactions of the system in action.
 Types of Interactions:
• Internal Interactions: Between components or modules within the system
• External Interactions: Between the system and external entities like users,
external systems, databases, etc.
DIFFERENCES BETWEEN SYSTEM CONTEXT AND
INTERACTION

 System Context:
• Static View: Focuses on external relationships and boundaries.
• Purpose: Establishes the environment in which the system operates.
 System Interaction:
• Dynamic View: Focuses on interactions, data flow, and processes during
operation.
• Purpose: Describes the behavior of the system at runtime.
EXAMPLE OF SYSTEM CONTEXT & INTERACTION
 System Context Example:

An online banking system:

• External Entities: Customers, bank staff, third-party payment
systems.
• Interfaces: Web, mobile apps, APIs for payments and transactions.

 System Interaction Example:

User interaction with the online banking system:

• User logs in, checks balance, makes a transfer.
• The system interacts with the database and external systems to
process the request.
CONCLUSION

•System Context defines the system's environment and boundaries

•System Interaction models how the system behaves during

runtime, focusing on data exchange and processes.

•Both are essential for understanding the design, operation, and

scalability of software systems
PRESENTATION title:
Architectural design.
Object class identification.
Design models.

WRITTEN BY:
AROOJ JAVEED.
SUBMITTED TO:
PROF. ABDUL BASIT.
TOPIC:
ARCHITECHTURAL DESIGN

Architectural design refers to the high-level process of defining the structure, components, and
interactions of a software system. It involves making decisions about the system's overall
organization and how its various parts will interact to meet both functional and non-functional
requirements, such as scalability, performance, security, and maintainability. It describes how the
system is organized as a set of communicating components.
The Architecture of a Packing Robot Control System
 Architectural Abstraction

Architectural Abstraction in software engineering refers to the process of simplifying and

generalizing the design of a software system by focusing on key components and their interactions,
while ignoring specific implementation details. The goal of abstraction is to manage complexity by
creating models that represent the system's architecture at various levels, from high-level
conceptual views down to detailed technical implementations.

Purpose of Architectural Abstraction

Manage Complexity: By abstracting away unnecessary details, architects can focus on the
system’s structure and high-level organization without getting overwhelmed by low-level concerns.
Separation of Concerns: Abstraction helps separate different levels of concerns within the
system, so developers can focus on specific tasks without worrying about unrelated complexities.
Reusability: Through abstraction, components or patterns can be reused across different systems
or projects, as the underlying details are hidden.
Scalability and Flexibility: By abstracting certain layers, the system is better able to evolve over
time. For example, high-level components can be restructured without affecting low-level
components, making it easier to scale or modify the system.
Improved Communication: Abstraction provides a common language that different stakeholders
(e.g., developers, architects, project managers) can use to discuss the system without needing to
be familiar with its underlying details.
 Advantages of Explicit Architecture
Clear Blueprint: Provides a well-defined structure for the system, making it easier to understand,
design, and implement.
Improved Communication: Ensures all stakeholders (developers, architects, managers) share a
common understanding of the system's design, improving collaboration.
Easier Maintenance: With a clear architecture, maintaining and updating the system becomes
more manageable, as changes can be made in a structured and predictable way.
Scalability and Flexibility: Explicit architecture helps identify components that can be scaled or
modified independently, making the system more adaptable to future needs.
Risk Mitigation: By explicitly planning and documenting the architecture upfront, potential risks
(e.g., performance bottlenecks, security vulnerabilities) can be identified and mitigated early.
Reusability: A well-defined architecture encourages the use of reusable components and
patterns, which can speed up development and reduce costs.
Consistency: Ensures consistent design and coding practices across the development team,
leading to more reliable and cohesive software.
Better Decision Making: With a clear architectural framework, decisions related to technologies,
tools, and design patterns can be made more effectively.
 Architectural Representation
Architectural Representation refers to the way in which the architecture of a software system is
depicted or described, typically using models, diagrams, and views. These representations help in
communicating the design decisions, structure, and behavior of the system to stakeholders, such
as developers, architects, and project managers.

Key Aspects of Architectural Representation

1. Models: A model is an abstract representation of the system's architecture that captures its key
components and relationships. Models help visualize the architecture and guide design
decisions. Common models include
• Structural Model: Focuses on the organization of components (e.g., classes, modules, or
services).
• Behavioral Model: Describes the interactions and dynamic behavior between components
(e.g., state diagrams, sequence diagrams).
• Interaction Model: Focuses on how components communicate with each other (e.g., message
flows, client-server interactions).

2. Diagrams: Diagrams are visual representations of the system's architecture, offering a clear
view of the system's structure. Common diagram types include:
• Component Diagram: Represents the high-level components of the system and their
• Sequence Diagram: Shows the interaction between components over time.
• Use Case Diagram: Provides an overview of system functionality from the user
perspective.
• Data Flow Diagram (DFD): Illustrates how data flows through the system.

3. Architecture Decision Records (ADR)

These are documents that capture architectural decisions, providing a clear rationale behind
choices made during the design process. ADRs help maintain the integrity of design decisions
throughout the software lifecycle.

4. Notations and Frameworks: Various notations and frameworks are used for architectural
representation, such as:
UML (Unified Modeling Language): A widely-used modeling language that provides a
standard way to visualize the design of a system through various diagram types.
Benefits of Architectural Representation
Clear Communication: Helps stakeholders understand the system's structure and design
decisions, facilitating better collaboration.
Documentation: Provides a formalized documentation of the architecture, which can be
referenced during development, testing, and maintenance.
Decision Support: Helps in making informed decisions about the system's design,
technologies, and tools.
 Box and Line Diagram
A Box and Line Diagram is a simple yet effective method used in software engineering to
represent the structure and relationships of different components in a system. This diagram is
commonly used to give a high-level view of the system’s architecture, showing how different
parts of the system are connected or interact with each other.
• Boxes: Represent components, modules, or subsystems in the architecture. Each box can be
labeled with the name of the component it represents (e.g., "User Interface", "Database",
"Authentication Service").
• Lines: Represent the relationships or communication between the components. The lines may
be directed (arrows) to indicate the direction of interaction or data flow.
• Labels: Labels on the boxes and lines clarify the role of each component and the nature of the
interaction between components.
Architectural Design Decisions
Architectural design decisions are critical choices made during the system design phase that
shape the software's structure, functionality, and performance. These decisions influence how
the system meets both functional and non-functional requirements.
• Communication: Choosing interaction methods (e.g., REST, message queues).
• Data Management: Selecting databases and caching strategies.
• Scalability: How to scale the system (e.g., horizontal vs. vertical).
• Security: Ensuring data protection and secure communication.
•
TOPIC:
OBJECT CLASS IDENTIFICATION

In software engineering, object class identification is the process of grouping objects based on
the attributes they share. Here are some steps to identify classes in software engineering:
• Obtain a sequence diagram
• Identify objects that appear repeatedly
• Analyze the flow of message
• Look for consistent behavior
• Identify roles
• Validate with a case study
1. Obtain a Sequence Diagram:
Sequence diagrams represent how objects interact over time, focusing on the flow of messages
between them. By examining the sequence diagram, you can identify the key objects involved
in specific scenarios or use cases.
2. Identify Key Nouns in the Use Case:
•From the use cases, extract the nouns that represent entities in the system. Nouns usually
correspond to potential objects or classes.
•Example: In the use case "Customer places an order," the nouns might be "Customer," "Order,"
and "Product."
3. Create a Class Diagram:

A Class Diagram is used to represent the structure of the system by showing the classes,
their attributes, and relationships.
Define classes based on the identified objects. For Example
• Customer: Attributes could include name, address, and methods like placeholder().
• Order: Attributes could include order number, orderdate and methods like calculate total().
• Product: Attributes could include product name, price, and methods like apply discount().

4. Analyze Relationships between Classes:

Identify associations, inheritance, and dependencies between classes
• Associations: Show how classes are related (e.g., a Customer "places" an Order).
• Inheritance: Identify parent-child relationships between classes (e.g., "PremiumCustomer"
inherits from "Customer").
• Aggregations: Show "has-a" relationships (e.g., an "Order" has multiple "Products").

5. Refine and Validate Classes:

• Ensure that the identified classes are cohesive, with a clear set of responsibilities and
behaviors.
• Validate with sequence diagrams to see how the objects interact over time, ensuring that
the classes support the required operations.
TOPIC:
DESIGN MODELS
In software engineering, design models are used to represent and structure the software
system during the design phase. These models provide a blueprint for how the system will be
implemented, detailing the system’s architecture, behavior, and interactions. UML (Unified
Modeling Language) is widely used to create these design models. Here are the key design
models in software engineering using UML:
1. Use Case Diagram:
• Purpose: Shows the system's functional requirements and how external actors (users or
other systems) interact with the system.
• Components:
• Actors: Represent external users or systems that interact with the software.
• Use Cases: Represent the functionalities or actions the system performs.
• Associations: Show the interactions between actors and use cases.
• Example: In an online shopping system, actors might be "Customer" and "Admin", while use
cases might include "Place Order", "View Product", "Process Payment".
2.Class Diagram
• Purpose: Represents the static structure of the system by showing the classes, their attributes,
methods, and relationships.
• Components:
• Classes: Define the objects of the system.
• Attributes: Properties or data elements of the classes.
• Methods: Functions or operations that the classes perform.
• Relationships: Includes associations, inheritance, composition, and aggregation.
• Example: In the online shopping system, classes might include "Customer", "Order", "Product",
with relationships showing that an "Order" contains multiple "Products".

3.Sequence Diagram
• Purpose: Describes how objects interact with each other over time, focusing on the sequence
of messages exchanged between objects.
• Components:
• Objects: Represented as vertical lines.
• Messages: Horizontal arrows indicating communication between objects.
• Example: In a checkout process, a sequence diagram shows the interaction between the
"Customer", "Shopping Cart", "Payment Gateway", and "Order" objects during order placement.

4.Activity Diagram
•Purpose: Shows the flow of control or data within a system, particularly useful for modeling
business processes or work flows.
• Components:
• Activities: Represent the steps or actions in a process.
• Transitions: Indicate the flow from one activity to the next.
• Decision Nodes: Show branching or conditional logic.
• Start and End Nodes: Indicate the initiation and termination of a process.
• Example: An activity diagram for the "Place Order" process might include activities like "Add
Product to Cart", "Select Payment Method", and "Confirm Order".

5.State Machine Diagram

Purpose: Models the states an object can be in, along with the transitions between those
states
based on events or conditions.
• States: Represent the different conditions or statuses an object can be in.
• Transitions: Arrows that show how the object changes from one state to another.
• Events: Triggers that cause a transition between states.

• :Example In a "Order" object, states might include "Pending", "Shipped", "Delivered", with
transitions based on events like "Payment Received" or "Shipment Processed".

6.Component Diagram
• Purpose: Represents the high-level structure of the system by showing how different
software
• components (modules) interact and depend on each other.
• Components:
• Components: Represents modular parts of the system.
• Interfaces: Points of interaction between components.
• Relationships: Show how components are connected or depend on each other.

• Example: In a web application, components might include "User Interface", "Database“,

• "Payment Service", with relationships showing how the UI interacts with the database.
7. Deployment Diagram
•Purpose: Models the physical deployment of the software on hardware components, showing
how software components are distributed across servers, networks, and devices.

• Components:
• Nodes: Represent physical devices or servers.
• Artifacts: Represent the software components deployed on the nodes.
• Associations: Show communication paths between nodes.

• Example: A deployment diagram for an online store might show how the application server,
database server, and web server are distributed in a cloud environment.
 INTERFACE SPECIFICATION
AND
DESIGN PATTERN
MARYAM FAKHAR 2023-CS-15
WHAT IS INTERFACE SPECIFICATION ?

 In software engineering, an interface specification is a detailed description of the

methods, properties, and behaviors that components, modules, or systems are expected to
implement and interact with, often in the context of software development. It serves as a
contract between different parts of a system or between different systems that
communicate with one another, specifying how they should interact without revealing the
internal details of the implementation.
 KEY ELEMENTS

Preconditions and Postconditions:

 Preconditions: Describe the expected state before a method or function is invoked (e.g., input values,
object states).
 Postconditions: Describe the expected state after the method has executed (e.g., modified values,
outputs).

Method Signatures:
 The interface specifies the methods/functions that a component exposes to other components, including
their names, parameters, and return types.
 It includes the function's input, output, and sometimes exceptions that could be thrown.

Data Types:
 The interface specification defines the data types that are expected for input parameters and
 KEY ELEMENTS
Exceptions and Error Handling:
 The interface specifies the types of errors or exceptions that could occur during the
execution of the methods, and how those should be handled.
State Descriptions:
 For certain types of interfaces, such as those involving stateful objects, the interface
specification may describe how the state is maintained or changed across method
calls.
Protocols and Communication:
 For distributed systems, an interface specification might also describe how
components communicate (e.g., through REST APIs, RPC calls, message queues) and
what protocols are used (e.g., HTTP, SOAP, gRPC).
Behavioral Contracts:
 The specification may include expected behavior such as time complexity (e.g., O(n)
for an algorithm), concurrency handling (e.g., thread safety), or how a system
behaves under different conditions.
 BENEFITS OF INTERFACE SPECIFICATION
 Decoupling: Interface specifications allow systems to be decoupled. The implementing
classes or systems do not need to know the internal details of the other systems or
components; they just need to follow the interface contract.
 Modularity: They promote modular design where different modules can interact with each
other without tightly coupling.
 Interoperability: In distributed or heterogeneous environments, interface specifications
ensure that systems with different implementations can interact effectively (e.g.,
microservices communicating via APIs).
 Consistency and Predictability: They define expected behavior, which reduces ambiguity
and allows developers to write predictable, reliable code.
 CONCLUSION

An interface specification in software engineering defines how components or systems

communicate with one another, offering a clear contract that ensures functionality is met
while maintaining flexibility and modularity.
 WHAT IS DESIGN PATTERNS?
Design patterns are a
critical tool in software
engineering, providing
reusable solutions to
common problems and
improving code structure
and maintainability. By
following these patterns,
developers can create
more flexible, scalable,
and understandable
software systems.
Creational & Behavioral
Design Patterns with UML
This presentation will delve into the world of design patterns,
focusing on creational and behavioral patterns. We will explore
their uses, benefits, and how to implement them using UML
diagrams.
by Zahra Arshad
Introduction to Design Patterns
What are Design Patterns? Benefits of Design Patterns

Design patterns are reusable solutions to common Design patterns enhance code readability,
software design problems. They provide a blueprint for maintainability, and reusability. They promote
how to structure code and relationships between collaboration and foster best practices within
objects. development teams.
The Creational Design Patterns

1 Abstract Factory

2 Factory Method

3 Builder

4 Prototype

5 Singleton
Singleton Pattern
Concept Example

Ensures that a class has only one instance and Consider a logging system where you only want one
provides a global point of access to it. This pattern is instance to handle all log entries. The Singleton pattern
useful when you need to restrict the creation of ensures a centralized and efficient logging mechanism.
multiple instances.
Factory Pattern
Concept Example
Defines an interface for Imagine a car
creating objects but lets manufacturing system. The
subclasses decide which Factory pattern can create
class to instantiate. This different car types (Sedan,
pattern decouples object SUV, etc.) based on user
creation from the code that input without explicitly
uses them. specifying the car class.
Abstract Factory Pattern
Concept Example

Provides an interface for creating families of related Consider a UI toolkit. The Abstract Factory pattern can
objects without specifying their concrete classes. This create different UI elements for different platforms
pattern allows for flexible and independent creation of (Windows, macOS, etc.) while maintaining consistent
object hierarchies. UI design.
The Behavioral Design Patterns

1 Mediator

2 Observer

3 Strategy

4 Template Method
Observer Pattern
1 Concept 2 Example
Defines a one-to-many Imagine a stock trading
dependency between application. When stock
objects. When one object prices change, the
changes state, all its Observer pattern notifies
dependents are notified. all subscribers who have
registered to observe
specific stocks.
Strategy Pattern

Concept Example
Defines a family of algorithms, Consider a sorting algorithm.
encapsulates each one, and The Strategy pattern allows you
makes them interchangeable. to choose between different
This pattern lets you choose the sorting algorithms (Bubble Sort,
algorithm at runtime. Quick Sort, etc.) based on the
needs of the application.
Conclusion and Key
Takeaways
Design patterns offer powerful tools for building robust and
maintainable software systems. By understanding and applying
these patterns, you can create better-structured, more adaptable,
and more collaborative codebases.
IMPLEMENTATION ISSUES
Azka Shahzad 2023-CS-19

Object-oriented design (OOD) using unified modeling

language (UML) is a standard approach to developing
software systems. While UML provides tools for
visualization and design, certain implementation
issues can arise during the transition from design to
code. Here are the common issues:
 MAJOR ISSUES :

Misinterpretation of UML Diagrams

 Issue: Developers may misinterpret complex UML diagrams (e.g., class,
sequence, or state diagrams) due to lack of clarity or insufficient detail.
 Design Complexity
 Issue: Overly detailed or intricate UML models can make implementation
cumbersome and error-prone.
 Mapping UML Constructs to Code
 Issue: Some UML constructs (e.g., interfaces, associations, or inheritance) may
not map directly to the programming language being used.
 Class Hierarchy and Inheritance Issues
 Issue: Incorrect or overly deep class hierarchies designed in UML diagrams can
lead to rigid and hard-to-maintain systems.
 .

 Encapsulation and Access Control

 Issue: Mismanagement of access control (e.g., public, private, or protected
methods and attributes) in UML class diagrams can lead to improper
implementation.
 Ambiguity in Associations
 Issue: UML association types (e.g., aggregation, composition, or simple
associations) might be misrepresented or misunderstood during
implementation.
 Error in State Transitions
 Issue: State diagrams may fail to account for edge cases or undefined
states.
 . Performance Issues
 Issue: Poorly designed interactions (e.g., in sequence or activity diagrams)
can lead to inefficient algorithms or unnecessary object creation.
 REUSABILITY

Reusability is a core principle of object-oriented design

(OOD) and a key factor in reducing development time
and cost. Unified modeling language (UML) plays a
significant role in enhancing reusability by enabling
clear, structured design representations. Below are the
aspects of reusability in OOD with UML:
1. Encapsulation for Modular Design
Encapsulation bundles data and behavior into cohesive units (classes), hiding
•Concept:

implementation details.
•UML Representation:
•Class Diagrams: Show encapsulated attributes and methods, with visibility markers ( +, -, #)
ensuring appropriate access control.
•Reusability Advantage: Encapsulated classes can be reused as building blocks without
exposing internal details, enhancing modularity.
 2. Inheritance for Code Reuse
 Concept: Inheritance allows new classes (subclasses) to derive properties and behaviors
from existing ones (superclasses).
 UML Representation:
 Generalization Arrows: Depict inheritance relationships in class diagrams.

 Reusability Advantage: Promotes reuse of common functionality while allowing

customization through overriding or extension.
Polymorphism for Flexibility
Polymorphism enables the same interface to represent different underlying
•Concept:

implementations.
•UML Representation:
•Interfaces and Abstract Classes: Indicated in class diagrams with <<interface>> or
italicized method names for abstract methods.
•Reusability Advantage: Allows interchangeable use of components implementing the same
interface,
•enhancing flexibility in design.

. Design Patterns

Concept: Reusable solutions to common design problems, such as Singleton, Factory, and
Observer patterns.
UML Representation:
Sequence Diagrams: Illustrate interactions within a pattern.
Class Diagrams: Represent roles and relationships in a pattern.
Reusability Advantage: Patterns provide proven, reusable templates for solving recurring design
challenges.
CONFIGURATION MANAGEMENT

 Version Control of UML Artifacts

 Track and manage changes to UML diagrams (e.g., class, sequence, and activity diagrams)
to reflect the current state of the design.
 Baseline Management
 Establish specific versions of UML diagrams as baselines for development phases
 Change Control
 Manage modifications to UML designs systematically to avoid introducing errors.
 Component Tracking
 Identify and track reusable components across UML diagrams and OOD artifacts.
•Define and document all UML artifacts and their relationships in the configuration management
 Configuration Identification
system.
QUESTIONS?