The document discusses the importance of modularity in software engineering, emphasizing features such as coherent components, loose coupling, and ease of understanding, reuse, and modification. It outlines principles for effective design, including hierarchical decomposition, balancing component sizes, and the distinction between top-down and bottom-up approaches. Additionally, it highlights the significance of designing systems that allow for independent problem-solving, reusability, and minimizing side effects from runtime errors.

1. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 1

2. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 2

3. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 3

4. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 4
Where modularity is needed ?
 Component design
₋ Make sure components have single responsibility, with few clear
connections or interfaces with other components.
 Debugging
₋ Makes bug finding easier as modularity limits the bug propagation to
as few classes as possible.
 Testing
₋ Makes it possible to carry out testing in a piecemeal fashion, that is
one component at a time.

5. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 5
How ? Hierarchical decomposition design with different level of abstraction:
 Decompose into components:
- with clearly defined input and output and well identified purpose,
- from higher more abstraction level to lower more detailed level,
- with minimum possible interactions.
 Balance the size of the components:
₋ Small size components will require relatively more connections, while
₋ Large size components will require relatively less connections but
more complexity.

6. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 6
 The modularity principle is the most basic principle in engineering. It states:
 A cohesive component has a well defined function or purpose.
 Components are loosely coupled if their interdependencies are minimized.
 Cohesive, loosely coupled components are easy to understand, reuse, and replace.
 UML component diagrams model systems from the
perspective of components (components), interfaces
(lollipops and sockets), and dependencies:

7. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 7
 Modularity is a part of our life
 According to Bertrand Meyer modularity principles are:
1. Modular Decomposability
2. Modular Composability
3. Modular Understandability
4. Modular Continuity
5. Modular Protection

8. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 8
• Structure software systems in terms of cohesive, decoupled, and orthogonal
components or modules.
• Appropriate separation and assignment of responsibilities are one of the
critical skills in object-oriented design. There are nine general responsibility
assignment patterns, called GRASP .

9. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 9
• This criterion is met by a design method if the methods supports
decomposition of a problem into smaller sub-problems, which can be solved,
independently.
• Top-down design methods fulfil this criterion; stepwise refinement is an
example of such method.

10. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 10
• A counter-example is the use of a global initialization module that include actions such as
opening a certain file or initializing a variable.
• Decomposition
» Break a problem into sub-problems connected by simple structures
> minimize communication between sub-problems
> permit further work to proceed separately on each subproblem

11. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 11
• Build reusable software elements which may then be freely combined with
each other to produce new systems, possibly outside their original contexts.
• Composability is directly related to the issue of reusability.
• Composability motivates design of elements that are sufficiently autonomous
and independent from the immediate goal, that led to their existence.

12. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 12
• Composition
» Produce software from reusable plug and play modules
» Composed software is itself a reusable module
» Reusable modules work in environments different from the ones in
which they were developed
» Examples
> using pipe in the Unix shell to combine Unix commands
> using abstract data types and bottom-up design

13. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 13
• Composition is "bottom-up" design while decomposition is "top-down"
design.
- Top-down design tends to produce modules that are targeted at fulfilling
specific requirements and hence are not easy to combine.
- Bottom-up design favors general modules that are too general, hence
when combined generate inefficient systems – in size and speed.
• Trick is to know when and how to best use both methods.

14. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 14
 Structuring software architecture in such a way that a slight change in the
problem specification triggers a change of just one module or a small number
of modules.
 In large software systems, the most challenging part of making changes is
not the change itself, but making the change in a way that does not regress
any other important behavior.
 This criterion is is directly connected to the goal of extensibility.

15. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 15
 Each module, or in other words, the unit of software should be
understandable without the need for knowing the others.
 This principle leads to the heuristic that control structure related to a
particular functionality are preferably assigned to one class rather than being
distributed over several classes.

16. 4/20/2020 S. Parsa, Associate Professor (www.parsa.iust.ac.ir) 16
 Runtime error in a module confines to that module, or at worst propagates to
a few neighboring modules.
 In effect, processing error side-effects are should be minimized.
 This feature enhances the testability because the bug localization process will
be confounded to the module in which the fault is observed.