What is Software Design ?
Software Design
Awet Fesseha
Rwanda Coding Academy
Awet Fesseha (@[Link]) RCA 1 / 46
Contents
1 Introduction
2 Overview of SOLID Principles
3 DRY, KISS
4 Coupling and Cohesion
Cohesion
Coupling
Awet Fesseha (@[Link]) RCA 2 / 46
Introduction
Introduction
Awet Fesseha (@[Link]) RCA 3 / 46
Introduction
Introduction System Design
W hen a developer starts working on a project, he wants to start scripting
the code.
if he builds software without a plan, then he might be building a home
without setting a foundation.
As a developer, why learn about software design? And, is it worth it?
Awet Fesseha (@[Link]) RCA 4 / 46
Introduction
System Design..
Software design transforms user requirements into a suitable form, which
helps the programmer in software coding and implementation.
These are more specific and detailed requirements in software terms for
implementation.
The output of this process can directly be used in programming languages.
During the software design phase, the document is produced, based on the
customer requirements as documented in the SRS document.
which moves the concentration from the problem domain to the solution
domain. Attempts to specify how to fulfill the requirements mentioned in
SRS
Awet Fesseha (@[Link]) RCA 5 / 46
Introduction
Why is software design so important?
Software design sets the foundation for constructing the software structure code.
This is why it is the most important aspect of software development. Below are
some reasons that make software design so important.
Modularity: You can split your software project into small tasks called
modules. If your client decides to make changes, you can restructure this
specific module.
Maintainability : A good software design gives you the privilege of detecting
bugs, debugging, restructuring, and changing the appearance and
functionality of the software by working on a specific module.
Quality Performance : It makes it easy to track errors. That is, if the
software project is handed over to another software developer, then the new
developer can follow up with its quality by just reading the software design.
Portability Portability allows transferring functions from one module to
another, as it can make many changes in the functionality of software
applications.
Awet Fesseha (@[Link]) RCA 6 / 46
Introduction
The software-level design
The software-level design process is divided into three main phases:
1 Architectural Design
2 High-level design
3 Detailed design
Awet Fesseha (@[Link]) RCA 7 / 46
Introduction
[Link] Design
Architectural Design -The architectural design is the highest abstract
version of the system
It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of the proposed solution
domain.
Example : micro-service architecture, client-architecture, L-layer,
Awet Fesseha (@[Link]) RCA 8 / 46
Introduction
2. High-level design
High-level Design High-level design breaks the single entity-multiple
component concept of architectural design into a less abstract view of
subsystems and modules and depicts their interaction with each other.
focuses on how the system and all its components can be implemented as
modules.
It recognizes the modular structure of each subsystem and their relationship
and interaction with each other.
Awet Fesseha (@[Link]) RCA 9 / 46
Introduction
[Link] design
Detailed Design-Detailed design deals with the implementation part of what
is seen as a system and its sub-systems in the previous two designs.
It is more detailed towards modules and their implementations.
It defines logical structure of each module and their interfaces to
communicate with other modules.
Awet Fesseha (@[Link]) RCA 10 / 46
Introduction
What are the objectives of having software design?
Correctness: A great design will apply all the required functionalities of the
system.
Efficiency: Good software addresses all resource, cost, and time optimization
issues.
Understandability: A good design has its modules arranged in one layer.
Completeness: A complete design has all the complete components,
including data structures, modules, and external interfaces.
Maintainability: A flexible software design is adaptable whenever a change is
required.
Awet Fesseha (@[Link]) RCA 11 / 46
Overview of SOLID Principles
Overview of SOLID Principles
Awet Fesseha (@[Link]) RCA 12 / 46
Overview of SOLID Principles
Overview of SOLID Principles
SOLID is a popular set of design principles that are used in object-oriented
software [Link] is a set of five principles that help software
developers design maintainable, scalable, and flexible systems
Single responsibility principle,
Open-closed principle,
Liskov substitution principle,
Interface segregation principle, and
Dependency inversion principle
Awet Fesseha (@[Link]) RCA 13 / 46
Overview of SOLID Principles
1. Single Responsibility principle
Robert Martin summarizes this principle well by mandating that
a class should have one and only one reason to change .
Following this principle means that each class only does one thing, and every
class or module only has responsibility for one part of the software
functionality.
More simply, each class should solve only one problem
Awet Fesseha (@[Link]) RCA 14 / 46
Overview of SOLID Principles
1. single responsibility principle...
Awet Fesseha (@[Link]) RCA 15 / 46
Overview of SOLID Principles
[Link]-closed principle
The idea of open-closed principle is that existing, well-tested classes will need
to be modified when something needs to be added.
However, changing classes can cause problems or [Link] of changing
the class, you simply want to extend it.
With that goal in mind, Martin summarizes this principle,
”you should be able to extend a class’s behavior without modifying it”
Awet Fesseha (@[Link]) RCA 16 / 46
Overview of SOLID Principles
[Link]-closed principle....
Awet Fesseha (@[Link]) RCA 17 / 46
Overview of SOLID Principles
[Link]-closed principle....
Following this principle is essential for writing code that is easy to maintain and
revise. Your class complies with this principle if it is:
1 Open for extension, meaning that the class s behavior can be extended;
and
2 Closed for modification, meaning that the source code is set and cannot be
changed
The way to comply with these principles and to make sure that your class is easily
extendable to modify the code is through using of abstractions, inheritance or
interfaces that allow polymorphic substitutions is a common way to comply with
this principle.
Awet Fesseha (@[Link]) RCA 18 / 46
Overview of SOLID Principles
3. Liskov substitution principle
is also one of the five SOLID principles
”Objects of a superclass should be replaceable with objects of its subclasses
without breaking the application.”
This means that a subclass should extend the behavior of a superclass
without altering its expected behavior.
If a subclass modifies or removes functionality instead of extending it, it
violates LSP and can cause unexpected issues.
It s a way of ensuring that derived classes extend the base class without
changing behavior.
Awet Fesseha (@[Link]) RCA 19 / 46
Overview of SOLID Principles
3. Liskov substitution principle...
Awet Fesseha (@[Link]) RCA 20 / 46
Overview of SOLID Principles
[Link] Segregation Principle (ISP)
”Clients should not be forced to depend on interfaces they do not use.” alot
of smaller interfaces than a few bigger ones.
Martin explains this principle by advising, Make fine-grained interfaces
that are client-specific. Clients should not be forced to implement interfaces
they do not use.
In other word , engineers should work to have many client-specific interfaces,
avoiding the temptation of having one big, general-purpose interface.
Awet Fesseha (@[Link]) RCA 21 / 46
Overview of SOLID Principles
[Link] Segregation Principle
Awet Fesseha (@[Link]) RCA 22 / 46
Overview of SOLID Principles
5. Dependency inversion principle
Martin further explains this principle by asserting that high level modules
should not depend upon low level modules Both should depend
on, abstractions . Further, abstractions should not depend on
details. Details should depend upon abstractions.
Simply put, the dependency inversion principle means that developers should
depend on abstractions, not on concretions.
Analogy: Wall Socket & Electrical Devices ,Imagine you have a lamp, a
phone charger, and a TV.
By using an abstraction (socket interface), both the power source and devices
remain independent and flexible.
Awet Fesseha (@[Link]) RCA 23 / 46
Overview of SOLID Principles
5. Dependency inversion principle...
Awet Fesseha (@[Link]) RCA 24 / 46
DRY, KISS
DRY, KISS
Awet Fesseha (@[Link]) RCA 25 / 46
DRY, KISS
DRY, KISS, and YAGNI Principles
The DRY principle in coding stands for ”Don’t Repeat Yourself.”
It means that in your code, you should
avoid duplicating the same logic or information in multiple places.
Instead, create reusable functions, classes, or variables to keep your code
concise and maintainable.
Awet Fesseha (@[Link]) RCA 26 / 46
DRY, KISS
DRY principle
Awet Fesseha (@[Link]) RCA 27 / 46
DRY, KISS
KISS (Keep It Simple, Stupid.)
KISS is a principle that aims to avoid complexity in code.
Complexity can make your code harder to understand, test, and modify.
KISS encourages you to write code that is
clear, concise, and self-explanatory .
This way, you can avoid unnecessary features, dependencies, or abstractions
that can confuse you or other developers who work on your code.
Awet Fesseha (@[Link]) RCA 28 / 46
DRY, KISS
KISS principle
Awet Fesseha (@[Link]) RCA 29 / 46
DRY, KISS
Conclusion
And that’s a wrap on our overview of the SOLID, DRY, and KISS principles.
Recall that the goal here is to write clean, efficient, and maintainable code.
While these principles can guide us, don’t forget the most important
Awet Fesseha (@[Link]) RCA 30 / 46
Coupling and Cohesion
Coupling and Cohesion
Awet Fesseha (@[Link]) RCA 31 / 46
Coupling and Cohesion
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several
modules based on some characteristics.
As we know, modules are set of instructions put together in order to achieve
some tasks. They are though, considered as single entity but may refer to
each other to work together.
There are measures by which the quality of a design of modules and their
interaction among them can be measured.
These measures are called coupling and cohesion .
Awet Fesseha (@[Link]) RCA 32 / 46
Coupling and Cohesion Cohesion
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within
elements of a module.
The greater the cohesion, the better is the program design.
Awet Fesseha (@[Link]) RCA 33 / 46
Coupling and Cohesion Cohesion
Types of cohesion
1 Type 1: coincidental cohesion
It performs a set of tasks that are associated with each other very loosely
Example: calculator : ADD ,SUB,MUL,DIV
2 Type 2: logical cohesion
If all element of the module perform a similar operation
Example: error handlining ,sorting ,if type of record =student then display
student record
3 Type 3: temporal cohesion
The activates related in time ,where all methods executed at same time
Temporal cohesion is found in the modules of initialization and termination
Example : counter ,open student file ,clear(),initializing the array etc
Awet Fesseha (@[Link]) RCA 34 / 46
Coupling and Cohesion Cohesion
Types of Cohesion ...
1 Types 4: procedural cohesion
All parts of procedure execute in particular sequence of steps for achieving
goal.
Example : calling on function to another function,loop statements, reading
record etc
2 Types 5: communication cohesion
If all the elements of a module are working on the same input and output
accessing The data through the same data structs.
Example: update the record in the data base and send it to the printer
3 Types 6 : sequence cohesion
Output of one element treats as an input to the other elements inside the
same module
Example : Enter the number� display addition
Awet Fesseha (@[Link]) RCA 35 / 46
Coupling and Cohesion
Types of Cohesion ...
1 Types 7: Function cohesion
If a single module aims to perform all similar types of functionalities through it
different elements The purpose of functional cohesion is single minded ,high
,strong and focused
Example : Railway Reservation system
Awet Fesseha (@[Link]) RCA 36 / 46
Coupling and Cohesion
Good and Bad software Design
Awet Fesseha (@[Link]) RCA 37 / 46
Coupling and Cohesion Coupling
Coupling
Coupling is a measure that defines the level of inter-dependability among
modules of a program.
It tells at what level the modules interfere and interact with each other.
The lower the coupling, the better the program.
Awet Fesseha (@[Link]) RCA 38 / 46
Coupling and Cohesion Coupling
Coupling...
The coupling is the degree of interdependence or number of relations between
modules
Two modules that are tightly coupled are strongly dependent on each other
However,two modules that are loosely coupled are not much dependent on
each other.
A good design is the one that has low coupling.
High coupling generates more errors because they shared large number of
data
Awet Fesseha (@[Link]) RCA 39 / 46
Coupling and Cohesion Coupling
Coupling...
Awet Fesseha (@[Link]) RCA 40 / 46
Coupling and Cohesion Coupling
Types of coupling
1 Type 1: content coupling
Here, two modules are connected as they share the same content like function
,methods
When change is made in one module the other module needs to be updated as
well
2 Type 2 : common coupling
Two modules are common coupled if they share information through some
global data items
3 Type 3: external coupling
When two modules share an externally import data format,communication
protocols or device interface
This is related to communication to external tools and devices
Awet Fesseha (@[Link]) RCA 41 / 46
Coupling and Cohesion Coupling
Types of coupling
1 Type 4: control coupling
Control coupling handle functional flow between software modules
Example : Module 1 set flag 1̄ then only module 2 perform action.
2 Type 5: Data coupling
When data are passed from one modules to another modules via argument list
or parameters through functional blocks
Awet Fesseha (@[Link]) RCA 42 / 46
Coupling and Cohesion Coupling
Why high cohesive and low coupling generate good design?
Due to low coupling
Readability: modules are easy to understand not complex
Maintainability: changes one module little impact to other
Modularity: enhance modules development
Scalability: adding new module remove exiting one easy
Testability: modules are easy to test and debug
Awet Fesseha (@[Link]) RCA 43 / 46
Coupling and Cohesion Coupling
Why high cohesive and low coupling generate good design?
Due to high cohesion
Readability :related function easy to understand
Reusability :easily Reuse module in another system
Reliability :Generate overall improvment of system
Testability: module are easy to test and debug
Awet Fesseha (@[Link]) RCA 44 / 46
Coupling and Cohesion Coupling
Recap questions Important questions
Can you explain a real-world scenario where applying the Single Responsibility
Principle improved a system’s design?
How would you explain the Open-Closed Principle to a junior developer who’s
never heard of SOLID?
What do you meant by term cohesion and coupling in the context of software
design ?
How are the concepts are useful for good design system
Why software design should have high cohesive and low coupling ?
please email this answer to : [Link]@[Link] BEFORE THE END
OF CLASS
Awet Fesseha (@[Link]) RCA 45 / 46
Acknowledgement
Thank you!
Awet Fesseha (@[Link]) RCA 46 / 46
