SOFTWARE DESIGN CONCEPT

U n i t - 3
S o f t w a r e E n g i n e e r i n g
 Introduction to
system design

System design is the process of defining the architecture, components,

modules, interfaces, and data for a system to satisfy specified requirements.
It involves making decisions about how to structure a software or hardware
system to achieve desired functionality, performance, scalability, reliability,
and other quality attributes.
 System Design
Concepts

System design involves structuring a system to meet specified requirements,

emphasizing scalability, reliability, performance, and other key attributes.
Here are fundamental design concepts:

1. **Modularity**: Divide system into manageable modules.

2. **Scalability**: Handle increased workload without major changes.
3. **Reliability**: Ensure consistent operation despite failures.
4. **Performance**: Optimize response time and resource use.
5. **Availability**: Maximize uptime through redundancy.
6. **Security**: Protect against unauthorized access and breaches.
7. **Maintainability**: Facilitate easy troubleshooting and updates.
8. **Flexibility**: Allow adaptation to changing requirements.
9. **Consistency**: Ensure data consistency across the system.
10. **Interoperability**: Work seamlessly with other systems.
11. **Concurrency**: Manage multiple operations concurrently.
12. **Testing**: Validate functionality and performance through testing.

These concepts guide the design process for creating robust, scalable, and
 Architecture
Design Models
Different models offer frameworks for designing systems, each with its own strengths and
applications.

1. **Layered Architecture**: Divides the system into logical layers.

2. **Client-Server Architecture**: Splits the system into client and server components.
3. **Microservices Architecture**: Decomposes the system into small, independently
deployable services.
4. **Service-Oriented Architecture (SOA)**: Organizes the system into loosely coupled
services.
5. **Event-Driven Architecture (EDA)**: Emphasizes the production, detection, and
reaction to events.
6. **Component-Based Architecture**: Constructs the system from reusable, self-contained
software components.
7. **Peer-to-Peer (P2P) Architecture**: Distributes the workload among peer nodes.
8. **Space-Based Architecture**: Distributes data and processing across a grid of
interconnected nodes.
9. **Model-View-Controller (MVC)**: Separates the system into model, view, and controller
components.
 Abstraction

Abstraction:

•Definition: Abstraction involves simplifying complex systems by representing only the essential
features without including unnecessary details.

•Importance: It allows developers to focus on relevant aspects of the system, hiding

implementation details and reducing complexity.

•Benefits: Enhances code readability, maintainability, and scalability by providing a clear and
concise view of the system's functionality.

•Examples: Encapsulation, inheritance, and interfaces in object-oriented programming are

mechanisms that facilitate abstraction by defining clear boundaries between different components
of the system.
 Coupling

Coupling:
•Definition: Coupling refers to the degree of interdependence between software
modules or components.
•Types:
• Loose Coupling: Components are relatively independent and interact through
well-defined interfaces, minimizing the impact of changes in one component on
others.
• Tight Coupling: Components are highly dependent on each other, making it
difficult to modify or replace one component without affecting others.
•Importance: Loose coupling promotes flexibility, reusability, and maintainability,
while tight coupling can lead to code fragility and difficulties in testing and
maintenance.
•Examples: In object-oriented design, dependency injection, and event-driven
architectures help reduce coupling by decoupling components and promoting modular
design.
 Cohesion

Cohesion:
•Definition: Cohesion measures the degree to which elements within a module
or component are related to each other.
•Types:
• High Cohesion: Elements within a module are closely related and work
together to achieve a single, well-defined purpose.
• Low Cohesion: Elements within a module are loosely related and may
perform multiple unrelated tasks.
•Importance: High cohesion promotes code clarity, maintainability, and
reusability by keeping related functionality together and reducing
dependencies between modules.
•Examples: Single Responsibility Principle (SRP) in object-oriented design
encourages high cohesion by advocating that a class should have only one
reason to change, leading to more maintainable and modular code.
 Ty p e s o f Ty p e s o f

Cohesion Coupling

1.Functional Cohesion: Components perform

1.Content Coupling: Components share data
related tasks that contribute to a single, well-
directly, tightly coupling their implementations.
defined purpose.
2.Common Coupling: Components share a
2.Sequential Cohesion: Components execute
global data source, coupling their access to this
tasks in a sequence where the output of one
shared resource.
feeds into the input of the next.
3.Control Coupling: One component controls
3.Communicational Cohesion: Components
the behavior of another by passing control
operate on the same data or share information.
information.
4.Procedural Cohesion: Components execute a
4.Stamp Coupling: Components share data
series of operations on the same data or inputs.
structures, coupling their internal
5.Temporal Cohesion: Components perform
representations.
tasks related to the same time frame or event.
5.Data Coupling: Components share data
through parameters or return values, but not
their internal state.
 To p D o w n
Approaches to
System Design
•Definition: In the top-down approach, the system is
decomposed into smaller subsystems or modules, starting from
the highest-level abstraction down to the lowest-level details.
•Process: The design process begins by identifying the overall
system architecture and main functionalities. Then, these
functionalities are further broken down into smaller, more
detailed components or modules. This decomposition continues
until the lowest level of granularity is reached.
•Advantages:
• Provides a clear overall structure of the system from the
beginning.
• Helps in defining interfaces between different subsystems
early in the design process.
• Facilitates a systematic approach to development, ensuring
that all components fit together cohesively.
•Considerations:
• May result in a delay in implementing specific
functionalities as the focus initially remains on higher-level
design.
• Dependencies between modules need to be carefully
 Bottom up
Approach to
System design
•Definition: In the bottom-up approach, development starts with
individual components or modules, which are then gradually integrated
to form larger subsystems and eventually the complete system.
•Process: Developers begin by creating smaller, independent modules
that perform specific functions or tasks. These modules are then
gradually combined to form larger components, and the integration
process continues until the entire system is constructed.
•Advantages:
• Allows for rapid prototyping and early implementation of specific
functionalities.
• Offers flexibility to focus on critical or high-risk components first.
• Enables incremental development and testing, potentially reducing
overall development time.
•Considerations:
• May result in a lack of overall system coherence until all
components are integrated.
• Dependencies between modules may become apparent later in the
development process, requiring adjustments or redesign.
 Fu n c t i o n a l v s O b j e c t O r i e n t e d
Approach
Object-Oriented Programming (OOP): Functional Programming (FP):
•Focuses on objects containing data and •Emphasizes functions as first-class citizens.
methods. •Promotes immutability and pure functions for
•Encourages modularity and code reuse clarity and predictability.
through encapsulation, inheritance, and •Supports higher-order functions and function
polymorphism. composition.
•Well-suited for modeling real-world entities •Ideal for data processing, concurrency, and
and interactions. mathematical computations.
•Commonly used in GUI applications, games,
and enterprise software.
D e s i g n S p e c i fi c a t i o n

A design specification is a detailed

document that outlines the requirements,
architecture, functionality, and
constraints of a software system or
product. It serves as a blueprint for
developers, designers, and stakeholders
to understand the scope and
implementation of the project.
 Design
S p e c i fi c a t i o n
Here's what a design specification typically includes:

•Introduction: Purpose and audience

•Scope: Project boundaries
•Functional Requirements: Specific functions
•Non-functional Requirements: Quality attributes
•Architecture and Design: System structure
•Data Model: Data structure and relationships
•User Interface Design: Interface layout and design
•Dependencies and Constraints: External dependencies and technical constraints
•Testing and Quality Assurance: Testing strategy and documentation
•Documentation: Guides and manuals
•Timeline and Milestones: Development timeline
•Approval and Sign-off: Review and approval process.
 UML
Unified Modeling Language (UML) is a standardized modeling language used in software engineering for
visualizing, specifying, constructing, and documenting the artifacts of software systems. It provides a common set
of diagrams and notation techniques that enable communication and understanding among stakeholders
involved in the software development process.

An Example of an UML diagram

 U n i fi e d M o d e l l i n g
Language
1. **Diagrams**: UML consists of several types of diagrams, each serving a specific purpose:
- Structural Diagrams: Describe the static structure of the system, such as classes, objects, components, and their relationships. Examples include Class Diagrams, Object
Diagrams, Component Diagrams, and Package Diagrams.
- Behavioral Diagrams: Describe the dynamic behavior of the system, including interactions, state transitions, and collaborations among components. Examples include Use Case
Diagrams, Sequence Diagrams, Activity Diagrams, and State Machine Diagrams.
- Interaction Diagrams: Focus on the interactions between objects or components, depicting the flow of messages and the sequence of actions. Examples include Sequence
Diagrams and Communication Diagrams.

2. **Notation**: UML provides a standardized notation for representing elements and relationships in diagrams. This notation includes symbols, shapes, and connectors that
convey specific meanings and semantics. For example, classes are represented as rectangles with compartments for attributes and methods, while associations between classes are
depicted using lines with arrowheads.

3. **Modeling Elements**: UML defines various modeling elements to represent different aspects of software systems, such as classes, objects, interfaces, packages, components,
use cases, actors, and collaborations. These elements help to capture the structure, behavior, and interactions of the system in a systematic manner.

4. **Abstraction Levels**: UML supports multiple levels of abstraction, allowing developers to model systems at different levels of detail. This includes high-level conceptual
models for early-stage design and detailed models for implementation and documentation purposes.

5. **Tool Support**: There are many UML modeling tools available that support the creation, editing, and analysis of UML diagrams. These tools often provide features for
generating code from UML models, reverse engineering code into UML diagrams, and collaborating with team members.
Types of UML diagrams Steps to create UML diagrams
 C h
Common Challenges in UML Modeling
a l l e n g e s i n U M L
1.Time-Intensive: UML modeling can be perceived as time-consuming, especially in fast-paced Agile
environments where rapid development is emphasized. Teams may struggle to keep up with the need for
frequent updates to UML diagrams.
2.Over-Documentation: Agile principles value working software over comprehensive documentation. There’s
a risk of over-documentation when using UML, as teams may spend too much time on detailed diagrams that
do not directly contribute to delivering value.
3.Changing Requirements: Agile projects often face changing requirements, and UML diagrams may become
quickly outdated. Keeping up with these changes and ensuring that UML models reflect the current system
state can be challenging.
4.Collaboration Issues: Agile emphasizes collaboration among team members, and sometimes UML
diagrams are seen as artifacts that only certain team members understand. Ensuring that everyone can
contribute to and benefit from UML models can be a challenge.
B e n e fi t s o f U s i n g U M L
1.Standardization: UML provides a standardized way of representing system models, ensuring that developers
and stakeholders can communicate using a common visual language.
2.Communication: UML diagrams serve as a powerful communication tool between stakeholders, including
developers, designers, testers, and business users. They help in conveying complex ideas in a more
understandable manner.
3.Visualization: UML diagrams facilitate the visualization of system components, relationships, and processes.
This visual representation aids in understanding and designing complex systems.
4.Documentation: UML diagrams can be used as effective documentation tools. They provide a structured and
organized way to document various aspects of a system, such as architecture, design, and behavior.
5.Analysis and Design: UML supports both analysis and design phases of software development. It helps in
modeling the requirements of a system and then transforming them into a design that can be implemented.
 Information Hiding
Information hiding, also known as encapsulation, is a fundamental concept in software engineering and design that emphasizes the idea of restricting access to
certain components of a system and exposing only the necessary information to the outside world. The main goal of information hiding is to minimize the
dependencies between different parts of a system, thereby enhancing modularity, reducing complexity, and improving maintainability. Here's a closer look at
information hiding:

Principle: Information hiding is based on the principle of abstraction, which states that the internal details of a module or component should be hidden from
other modules or components. Instead, only the essential interface or contract should be exposed to interact with that module or component.

Encapsulation: Encapsulation is a key mechanism for implementing information hiding. It involves bundling the data (attributes or properties) and methods
(functions or procedures) that operate on the data into a single unit, called an object (in object-oriented programming) or a module (in procedural programming).
Encapsulation allows the internal state of an object or module to be hidden from external access, and only specific methods or functions are provided to
manipulate that state.

Benefits:
- **Modularity**: Information hiding promotes modularity by breaking down a system into smaller, independent components that can be developed, tested,
and maintained separately.
- **Reduced Complexity**: By hiding implementation details, information hiding reduces the complexity of a system, making it easier to understand and reason
about.
- **Enhanced Security**: Hiding sensitive information or implementation details helps improve security by preventing unauthorized access or modification.
- **Improved Maintainability**: Since changes to one component can be made without affecting other components, information hiding improves the
maintainability of a system.

Implementation:
- In object-oriented programming, information hiding is typically achieved through access control mechanisms, such as private, protected, and public access
modifiers, which restrict the visibility of class members (attributes and methods) to other classes.
- In procedural programming, information hiding can be achieved by declaring certain variables and functions as static or private within a module, limiting their
visibility to other modules.
 Information Hiding Continued

Examples of Information Hiding

In a class representing a bank account, the account balance may be hidden from direct access by
making it a private attribute and providing public methods such as deposit and withdraw to modify
it.
In a software library, internal implementation details may be hidden from users of the library's API,
exposing only the functions or classes needed to interact with the library.
 For more insight into these concepts check the below

A lot of material for the purpose of this presentation was taken from GeeksForGeeks,
so checking the source material for a better understanding is recommended

TEXT BOOKS -
Richard Fairley, “Software Engineering Concepts”, McGraw Hill, 1985.
Roger S. Pressman, “Software Engineering A Practitioner Approach” 4th edition , McGraw Hill, 1999

REFERENCE BOOKS –
Ian Sommerville, Software engineering, Pearson education Asia, 6th edition, 2000.
Pankaj Jalote- An Integrated Approach to Software Engineering, Springer Verlag, 1997.
Shooman, Software Engineering, McGraw Hill, 1983.
Fundamentals of Software Engineering by Rajib Mall, – PHI-3rd Edition, 2009

Or just use GPT

Thank You