Complexity and Modularity Outline o Complexity n Understanding

Complexity and Modularity

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

Complexity o Complexity in designs can be measured by the interconnectedness of things. o Complexity is a function of the degree of dependency among elements of a system. o 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.

The Design Structure Matrix (DSM) o An alternative to a directed graph is a DSM. o It is an N by N matrix where the same elements appear as rows and columns in the same order. (The diagonal is ignored. ) o 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

The Design Structure Matrix (DSM) Example Element A Element B 0 Element B X 0

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

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

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

Granularity and Context q “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) q You cannot understand the architecture of a system by looking at low-level design models and source code.

Granularity and Context (Cont’d) o Complexity depends not only on the number of dependencies, but also on the pattern of dependencies. o One must also take into account the relationship types. o 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 reason about the system.

Varying Degrees of Complexity – Fully Connected DSM A B C D E A O X X B X O X X X C X X O X X D X X X O X E X X O

Varying Degrees of Complexity – Fully Disconnected DSM A A B C D E O O O

Varying Degrees of Complexity – A Layered Architecture A B C D A O B X O C X X O D X X X O E X X E O

Varying Degrees of Complexity – Also a Layered Architecture A B A O X B X O X X O C D E

Varying Degrees of Complexity – The Most Complex A A B C O X X O D E O B C X D X E X O X X O

Modularity o 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. o The principles of coupling and cohesion are important to understand how to create a modular architecture. o Modular operators can help to achieve a simpler design.

Architecture and Modules o 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. o A component is a runtime entity while a module is a discrete package of software.

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

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

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

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

Design Elements and Design Rules (Cont’d) q These elements are called design rules. q 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).

Analyzing a DSM for System Modules A B C D E F G H A 0 B X 0 X C X X 0 D X X 0 X E X F G H X 0 X X 0

Analyzing a DSM for System Modules (Cont’d) B C F A D E G H B 0 X X C X 0 X F A X 0 X X E G H 0 X X X D X 0

Analyzing a DSM for System Modules (Cont’d) B B C 0 X F D 1 E F X X 0 C 0 X F X 0 D 1 A F G D 2 0 X X 0 G 0 X D 2 E A X X

A Modular System Design Rules O X Des O X X Rules X O UI X App X Logic O X X X UI O X App Logic X O O X X O

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

A TSM for a Business Application A A. Business Obj 1 C D E F G 0 B. Business Obj 2 0 C. Bus. Obj. Search X D. UI Screen 1 X E. UI Screen 2 X F. UI Screen 3 G. Email Notifier B X 0 X X X 0 0

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

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

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

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

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

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

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

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