Software design is a process through which requirements are translated into a ― blueprint for constructing the software. Initially, the blueprint shows how the software will look and what kind of data or components will be required to in making it. The software is divided into separately named components, often called ‘MODULES’, that are used to detect problems at ease. This follows the "DIVIDE AND CONQUER" conclusion. It's easier to solve a complex problem when you break it into manageable pieces.

1. Software Design

2. Software Design
 Software design is a process through which requirements
are translated into a ― blue-print for constructing the
software.
 Initially, the blueprint shows how the software will look and
what kind of data or components will be required to in making
it.

3. Process of Software Design
Engineering
 During the design process, the software specifications are
transformed into design models
 Each design product is reviewed for quality before moving
to the next phase of software development.
 At the end of the design process, a design model and
specification document is produced.

4. Design Specification Models
 Data design – created by transforming the analysis information
model (data dictionary and ERD) into data structures required to
implement the software. More detailed data design occurs as each
software component is designed.
 Architectural design - defines the relationships among the major
structural elements of the software, the design patterns, that can be
used to achieve the requirements that have been defined for the
system. Relationships can be made using UML or USECASE
diagrams.

5. Design Specification Models
 Interface design - describes how the software elements
communicate with each other, with other systems, and with
human users; the data flow and control flow diagrams provide
much of the necessary information required.
 Procedural design - created by transforming the structural elements
defined by the software architecture into procedural descriptions of
software components using information obtained from the process.

6. Design - Fundamental Concepts
 Abstraction
 Architecture
 Patterns
 Modularity
 Information hiding
 Functional independence
 Refinement
 Refactoring

7. Modularity

8. MODULARITY
Software is divided into separately named components,
often called ‘MODULES’, that are used to detect problems
at ease.
This follows the "DIVIDE AND CONQUER" conclusion.
It's easier to solve a complex problem when you break it
into manageable pieces.

9. Why modularize a system?
• Management: Partition the overall development effort
• Evolution: Decouple parts of a system so that changes to one
part are isolated from changes to other parts
– Principle of Discontinuity (Delete a part)
– Principle of Continuity (Addition to the part)
• Understanding: Permit system to be understood
– as composition of mind-sized chunks
– With one issue at a time

10. Advantage of modularization
• Smaller components are easier to maintain
• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the
program
• Components with high usage can be re-used.
• Concurrent execution can be made possible

11. Modular Design
 Easier to change
 Easier to build
 Easier to maintain

12. Functional Independence
COHESION : The degree to which a module performs
one and only one function.
COUPLING : The degree to which a module is
“connected” to other module in the system.

13. Modularity Modules’ Cost
Verses Size
The effort (cost) to develop
an individual software
module does decrease as the
total number of modules
increases. Given the same
set of requirements, more
modules means smaller
individual size. However, as
the number of modules
grows, the effort (cost)
associated with integrating
the modules also grows.

14. Modularity Modules’ Cost
Verses Size
These characteristics lead to
a total cost or effort curve
shown in the figure. There
is a number "M" of modules
that would result in
minimum development cost,
but we do not have the
necessary sophistication to
predict M with assurance.

15. Self-Contained : "Agile & Autonomous"
• A module is a self-contained component of a larger
software system.
• This doesn't mean that it is an atomic component.
• In fact a module consists a several smaller pieces which
are collectively contributed to the
functionality/performance of the module.

16. We cannot remove or modify at least any of these
tiny (compared to larger software system)
components and if we do so, the 'Module' will cease
it expected functionality

17. A set of compartments that can mimic the modularity.
Any of these compartments can be move without
affecting other components' functionality (but when we
move a module the functionality of the whole system
changes).
Lets try to understand this by above
real world scenarios.
Modular Compartments

18. A module can be installed, un-installed or moved
as a whole(single unit) and it wont affect the
functionality of the other modules.

19. We can form different letters by place different
components(modules) at different places and we
have the freedom of moving modules freely without
affecting the functionality of other modules
Modularizing ..

20. It is necessary for the programmers and designers
to recognize those modules, which can be made
parallel execution.

21. Thank You