Software Design: Process,

Concepts, and Models

Aqsa Tehseen
Lecturer Computer Science
CUI Sahiwal
 Introduction to Software Design
Software design is a critical phase of the software
development lifecycle (SDLC), where developers and
architects define how the system will be structured
and function. It acts as a bridge between the
requirements and implementation stages, ensuring
that the system meets the intended objectives
efficiently.
It transforms requirements into a structured solution.
Ensures scalability, maintainability, and functionality.
 Software Design Process
The design process is a systematic approach to transforming
software requirements into a structured solution. It involves
multiple stages and ensures that software is scalable, maintainable,
and meets functional and non-functional requirements.
Key Stages of the Design Process
1. Understanding Requirements
2. High-Level Design (Architecture)
3. Low-Level Design (Detailed Design)
4. Prototyping & Refinement
5. Design Documentation
6. Review & Validation
 Key Stages of the Design Process

1. Understanding Requirements
1. Analyze functional and non-functional requirements.
2. Identify constraints such as security, scalability, and
performance.
2. High-Level Design (Architectural Design)
1. Define the overall system architecture, including major
components, modules, and their interactions.
2. Decide on patterns like MVC (Model-View-Controller) or
Microservices Architecture.
3. Low-Level Design (Detailed Design)
1. Define internal module structures, algorithms, and class
hierarchies.
2. Specify data structures, database schemas, and API
definitions.
Cont.
4. Prototyping & Design Refinement
• Create a prototype if necessary to validate design choices.
• Refine based on feedback and feasibility.
5. Design Documentation
• Prepare UML diagrams like class diagrams, sequence
diagrams, and use case diagrams.
• Document design decisions and system constraints.
6. Review & Validation
• Conduct design reviews to ensure correctness, efficiency,
and adherence to best practices.
• Validate against functional and non-functional
requirements.
 Key Software Design Concepts
Design concepts provide fundamental guidelines for
developing software in an efficient and scalable manner. These
principles help in creating a well-structured and maintainable
system.
• Abstraction
• Modularity
• Encapsulation
• Separation of Concerns (SoC)
• Coupling and Cohesion
• Design Patterns
• Refactoring
• Scalability & Maintainability
Cont.
•Abstraction
•Hides complex implementation details and provides a
simpler interface.
•Example: A user interacts with a database through an ORM
(Object-Relational Mapping) without dealing with SQL
queries.
•Modularity
•Divides a system into separate modules that handle specific
functionalities.
•Example: In an E-commerce system, separate modules exist
for user authentication, product catalog, and order
management.
•Encapsulation
•Groups data and methods that operate on that data into a
single unit (class).
•Example: A BankAccount class contains balance and
transaction methods but hides internal implementation.
•Separation of Concerns (SoC)
•Ensures that each module has a distinct responsibility.
•Example: In MVC architecture, the Model manages data, the
View handles UI, and the Controller processes user inputs.
Cont.
•Coupling and Cohesion
•Low Coupling: Modules should be loosely connected,
reducing dependencies.
•High Cohesion: Each module should focus on a single
responsibility.
•Example: A payment gateway module should only handle
payment processing and not order tracking.
•Design Patterns
•Reusable solutions to common design problems.
•Examples: Singleton (for a single instance), Factory (for
object creation), Observer (for event-driven programming).
Cont.

•Refactoring
•Improves existing code without changing functionality.
•Example: Removing duplicate code by creating reusable
functions.
•Scalability & Maintainability
•Design must allow for future expansion and easy updates.
•Example: Using a microservices approach for a growing
application.
 Software Design Models
A design model is a representation of software structure,
behavior, and interactions. It helps visualize the system before
implementation, ensuring clarity and reducing errors.
Types of Design Models
A. Structural Models (Static Models)
Describe the organization of the system in terms of components,
classes, and relationships.
1. Class Diagram (UML)
1. Represents the structure of a system with classes, attributes,
methods, and relationships.
2. Example: In a Library System, classes include Book, Member, and
Librarian.
 Structural Models (Static)

•Component Diagram
•Shows how different components interact in a system.
•Example: A web application with frontend, backend, and
database components.
•Deployment Diagram
•Describes the system's physical deployment, including
hardware and software.
•Example: Cloud-based vs. on-premise deployment.
 Behavioral Models (Dynamic)
Describe how the system will behave over time,
including user interactions and data flow.
1. Use Case Diagram
1. Represents user interactions with the system.
2. Example: A Hospital Management System where a
doctor interacts with the patient record module.
2. Sequence Diagram
1. Describes interactions between objects over time.
2. Example: A customer order process in an e-commerce
system.
 Behavioral Models (Dynamic)
3. State Diagram
1.Shows how an object transitions between states
based on events.
2.Example: A traffic light system changing states
from red → yellow → green.
4. Activity Diagram
3.Represents workflows and decision points.
4.Example: A loan approval process in a bank.
 Data Flow Models
Describe how data moves through the system.
1. Data Flow Diagram (DFD)
1. Shows how data enters, moves through, and exits a
system.
2. Example: A student registration system where data
flows from student → admin → database.
2. ER Diagram (Entity-Relationship Diagram)
1. Defines database structure and relationships.
2. Example: A Retail System with entities like Product,
Customer, and Orders.
 Conclusion
• Software design process ensures a structured
approach to system development.
• Design concepts like abstraction, modularity,
and encapsulation help create scalable and
maintainable systems.
• Design models provide a blueprint for
implementation through diagrams like class,
sequence, and use case diagrams.
What is an Activity Diagram?

Activity diagrams show the steps involved in how a

system works, helping us understand the flow of
control. They display the order in which activities
happen and whether they occur one after the other
(sequential) or at the same time (concurrent). These
diagrams help explain what triggers certain actions
or events in a system.
• An activity diagram starts from an initial point and
ends at a final point, showing different decision
paths along the way.
• They are often used in business and process
modeling to show how a system behaves over time.
 Activity Diagram Notations
Notation Description UML Notation

Activity
Is used to represent a set of actions

Action
A task to be performed

Object Flow
Show the flow of an object from one activity (or action) to
another activity (or action).

Initial Node
Portrays the beginning of a set of actions or activities
Activity Final Node
Stop all control flows and object flows in an
activity (or action)

Object Node
Represent an object that is connected to a set of
Object Flows

Decision Node
Represent a test condition to ensure that the
control flow or object flow only goes down one
path
Merge Node
Bring back together different decision paths
that were created using a decision-node.

Fork Node
Split behavior into a set of parallel or
concurrent flows of activities (or actions)

Join Node
Bring back together a set of parallel or
concurrent flows of activities (or actions).
Swimlane and Partition
A way to group activities performed
by the same actor on an activity
diagram or to group activities in a
single thread
 Activity Diagram - Modeling a Word Processor

The activity diagram example below describes the workflow for a word
process to create a document through the following steps:
• Open the word processing package.
• Create a file.
• Save the file under a unique name within its directory.
• Type the document.
• If graphics are necessary, open the graphics package, create the graphics,
and paste the graphics into the document.
• If a spreadsheet is necessary, open the spreadsheet package, create the
spreadsheet, and paste the spreadsheet into the document.
• Save the file.
• Print a hard copy of the document.
• Exit the word processing package.
 Activity Diagram Example - Process Order

Given the problem description related to the workflow for processing an order,
let's model the description in visual representation using an activity diagram:

Process Order - Problem Description

• Once the order is received, the activities split into two parallel sets of
activities. One side fills and sends the order while the other handles the
billing.

• On the Fill Order side, the method of delivery is decided conditionally.

Depending on the condition either the Overnight Delivery activity or the
Regular Delivery activity is performed.

• Finally the parallel activities combine to close the order.