Complexity and ModularityOutlineComplexityThe Design Structure Matrix (DSM)The Design Structure Matrix (DSM) ExampleComplexity Arises in Many Aspects of Software DesignUnderstanding ComplexityUnderstanding Complexity (Cont’d)Granularity and ContextGranularity and Context (Cont’d)Varying Degrees of Complexity – Fully Connected DSMVarying Degrees of Complexity – Fully Disconnected DSMVarying Degrees of Complexity – A Layered ArchitectureVarying Degrees of Complexity – Also a Layered ArchitectureVarying Degrees of Complexity – The Most ComplexModularityArchitecture and ModulesImporting and ExportingCoupling and CohesionDesign Elements and Design RulesDesign Elements and Design Rules (Cont’d)Slide 22Analyzing a DSM for System ModulesAnalyzing a DSM for System Modules (Cont’d)Slide 25A Modular SystemTask Structure MatrixA TSM for a Business ApplicationModule OperatorsSplittingSubstitutingAugmenting and ExcludingInversionPortingSummarySummary (Cont’d)Complexity and ModularityOutline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SummaryComplexity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.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 appearsThe Design Structure Matrix (DSM) ExampleElement A Element BElement A 0 XElement B 0Complexity Arises in Many Aspects of Software DesignRequirementsUser Interface“High-level” design“Low-level” designSource codeUnderstanding 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.)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.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.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.Varying Degrees of Complexity – Fully Connected DSMA B C D EA O X X X XB X O X X XC X X O X XD X X X O XE X X X X OVarying Degrees of Complexity – Fully Disconnected DSMA B C D EA OB OC OD OE OVarying Degrees of Complexity – A Layered ArchitectureA B C D EA OB X OC X X OD X X X OE X X X X OVarying Degrees of Complexity – Also a Layered ArchitectureA B C D EA O XB X O XC X O XD X O XE X OVarying Degrees of Complexity – The Most ComplexA B C D EA OB O XC X X OD X OE X X X OModularity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.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.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.Coupling and CohesionCoupling refers to the connection between two modules.Cohesion refers to the density of dependencies within a moduleDesign 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.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.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).Analyzing a DSM for System Modules A B C D E F G HA 0 X X XB 0 XC 0 X XD X X 0E X 0 X XF X 0G X X 0 XH X 0Analyzing a DSM for System Modules (Cont’d)B C F A D E G HB 0 XC 0 X XF X 0A X X 0 XD X X 0E X X 0 XG X X 0 XH X 0Analyzing a DSM for System Modules (Cont’d)B C F D1 A D2 E F GB 0 XC 0 X XF X 0D1 0A X X X 0 XD2 X X 0E X X 0 XF X X 0 XG X 0A Modular SystemDesign Rules UI App LogicDesRulesO XO X XX OOUI X X X O XX X OAppLogicX X O XX X O XX OTask Structure MatrixThe design structure matrix maps to a task structure matrix.Once the DSM is stable you can