Software Design and Modularity

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. S oftware 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 , t he design pattern s , th at can be used to achieve the requirements that have been defined for the syste m . 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. I t'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 C ontinuity (Addition to the part) Understanding : Permit system to be understood as composition of mind-sized chunks W ith 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. W e 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