Complexity and Modularity

1. Complexity and Modularity

2. Outline • Complexity • Understanding complexity • Granularity and context • Modularity • Architecture and modules • Importing and exporting • Coupling and cohesion • Design elements and design rules • Task structure matrix • Modular operators • Summary

3. Complexity • Complexity in designs can be measured by the interconnectedness of things. • Complexity is a function of the degree of dependency among elements of a system. • A directed graph is a convenient way to show these dependencies as long as the number of nodes doesn’t exceed our ability to view and analyze the diagram.

4. The Design Structure Matrix (DSM) • An alternative to a directed graph is a DSM. • It is an N by N matrix where the same elements appear as rows and columns in the same order. (The diagonal is ignored.) • An X is placed in the matrix where a dependency exists. The element corresponding to a given row is dependent upon the elements in the columns for which an X appears

5. The Design Structure Matrix (DSM) Example

6. Complexity Arises in Many Aspects of Software Design • Requirements • User Interface • “High-level” design • “Low-level” design • Source code

7. Understanding Complexity • The complexity of a software design is associated with the length of its description. • The greater the number of dependencies the longer the description. • Using abstraction more elements can be added while reducing the ratio of dependencies to elements (although the actual number of dependencies may go up.)

8. Understanding Complexity (Cont’d) • As the complexity of the architecture increases, the complexity of the individual models can decrease. • Hierarchically decomposing a system allows us to distribute complexity across multiple components. • We can reduce the apparent complexity of a system by our choice of design language.

9. Granularity and Context • “When defining complexity it is always necessary to specify a level of detail up to which the system is described with finer details being ignored. Physicists call that ‘course graining.’” (Murray Gell-Mann) • You cannot understand the architecture of a system by looking at low-level design models and source code.

10. Granularity and Context (Cont’d) • Complexity depends not only on the number of dependencies, but also on the pattern of dependencies. • One must also take into account the relationship types. • Part of managing complexity is in our ability to improve the comprehensibility of a system. Although this doesn’t reduce complexity, it improves our ability to understand and reason about the system.

11. Varying Degrees of Complexity – Fully Connected DSM

12. Varying Degrees of Complexity – Fully Disconnected DSM

13. Varying Degrees of Complexity – A Layered Architecture

14. Varying Degrees of Complexity – Also a Layered Architecture

15. Varying Degrees of Complexity – The Most Complex

16. Modularity • Modularity is the primary principle by which we manage complexity of designs and design tasks by identifying and isolating those connections or relationships that are the most complex. • The principles of coupling and cohesion are important to understand how to create a modular architecture. • Modular operators can help to achieve a simpler design.

17. Architecture and Modules • We distinguish between a static design-level view of the system’s structure in terms of modules and a runtime component view of the application. • A component is a runtime entity while a module is a discrete package of software.

18. Importing and Exporting • Things imported by a module that are exported by another module can thought of as abstract interfaces. • The term interface is used to mean anything that is imported or exported.

19. Coupling and Cohesion • Coupling refers to the connection between two modules. • Cohesion refers to the density of dependencies within a module

20. Design Elements and Design Rules • Typically, we take a first pass at decomposing or splitting our system into several subsystems. • First we perform a functional decomposition of the system. The system is split both horizontally and vertically. • We group one set of design elements into a potential module and another set into another potential module.

21. Design Elements and Design Rules (Cont’d) • We select design elements that form the strongest dependencies between our potential modules and establish their design first. • These elements become the interface between the two modules.

22. Design Elements and Design Rules (Cont’d) • These elements are called design rules. • Design rules tend to be things like shared data representation (the format of business object data) and the interaction style (whether application logic functions are synchronous or asynchronous).

23. Analyzing a DSM for System Modules

24. Analyzing a DSM for System Modules (Cont’d)

25. Analyzing a DSM for System Modules (Cont’d)

26. A Modular System

27. Task Structure Matrix • The design structure matrix maps to a task structure matrix. • Once the DSM is stable you can see the interdependencies between design tasks and schedule the order in which the design tasks are accomplished.

28. A TSM for a Business Application

29. Module Operators • Splitting a design into two or more modules • Substituting one design module for another • Augmenting the system by adding a new module • Excluding a module from the system • Inverting a module to create new interfaces (design rules) • Porting a module to another system

30. Splitting • This is the operation of separating a set of design tasks as represented in a DSM into multiple groups. • These groups should exhibit high internal cohesion and low external coupling to begin with. • A module itself may split independently from other modules. This is how a hierarchical design is formed.

31. Substituting • If two different designs serve the same function but with different quality attributes, then it is possible that one can be substituted for another. • This allows an organization to create multiple competing designs for a given component to find the best design.

32. Augmenting and Excluding • These are complementary operations • Augmenting means adding a module to a design and excluding means leaving a module out of a design • A reconfigurable system is one that can later be changed by augmenting or excluding modules

33. Inversion • The operation of breaking encapsulation • It takes (some) hidden information and makes it visible as new design rules

34. Porting • Using a module in a different system than the one it was originally designed for.

35. Summary • Complexity is probably the most influential force in the development of design methods and tools. • Modular design is one of the most effective ways to manage complexity. • The DSM (Design Structure Matrix) is a powerful representation model for learning about the complexities of a design.

36. Summary (Cont’d) • A DSM is isomorphic to a TSM (Task Structure Matrix) which serves as the basis for creating a development schedule. • An architectural design can be transformed by the application of modular operators. • The creation of a design for a complex application requires several iterations and possibly many permutations