{"id":1648,"date":"2015-05-07T23:35:14","date_gmt":"2015-05-07T23:35:14","guid":{"rendered":"http:\/\/www.codergears.com\/Blog\/?p=1648"},"modified":"2015-05-07T23:42:55","modified_gmt":"2015-05-07T23:42:55","slug":"how-a-dependency-structure-matrix-could-help-you-to-improve-your-application-design","status":"publish","type":"post","link":"https:\/\/codergears.com\/Blog\/?p=1648","title":{"rendered":"How Dependency Structure Matrix could help you  improve your software design"},"content":{"rendered":"<p><span style=\"color: #333333;\">The DSM (Dependency Structure Matrix) is a compact way to represent and navigate across dependencies between components. For most engineers, talking of dependencies means talking about something that looks like that:<!--more--><\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image15\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/GraphSample.jpg\" alt=\"\" \/><\/p>\n<p>DSM is used to represent the same information than a graph.<\/span><!--more--><!--more--><!--more--><\/p>\n<ul>\n<li style=\"color: #555555;\">Matrix headers\u2019 elements represent graph boxes<\/li>\n<li style=\"color: #555555;\">Matrix non-empty cells correspond to graph arrows.<\/li>\n<\/ul>\n<p><span style=\"color: #333333;\">As a consequence, in the snapshot below, the coupling from\u00a0<i>Net<\/i>\u00a0to\u00a0<i>Foundation<\/i>\u00a0is represented by a non empty cell in the matrix and by an arrow in the graph.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image16\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/MatrixVsGraph1.jpg\" alt=\"\" \/><\/p>\n<p>Why using two different ways, graph and DSM, to represent the same information? Because there is a trade-off:<\/span><\/p>\n<ul>\n<li style=\"color: #555555;\">Graph is more intuitive but can be totally not understandable when the numbers of nodes and edges grow (a few dozens boxes can be enough to produce a graph too complex)<\/li>\n<li style=\"color: #555555;\">DSM is less intuitive but can be very efficient to represent large and complex graph. We say that DSM\u00a0<span style=\"font-weight: bold;\">scales<\/span>compare to graph.<\/li>\n<\/ul>\n<p><span style=\"color: #333333;\">A non-empty DSM Cell contain a number. This number represent the strengths of the coupling represented by the cell. The coupling strength can be expressed in terms of number of members\/methods\/fields\/types or namespaces involved in the coupling, depending on the actual value of the option\u00a0<span style=\"font-weight: bold;\">Weight on Cells<\/span>. In addition to the Context-Sensitive Help, the DSM offers as well a\u00a0<span style=\"font-weight: bold;\">Info Panel<\/span>\u00a0that explains coupling with a plain-english description:<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image8\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/Cell.png\" alt=\"\" \/><\/p>\n<p><strong>Identify Code Structure Patterns on Matrix<\/strong><br \/>\n<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label6\" style=\"color: #333333;\">DSM comes with the particularity to offer easy identification of popular Code Structure Patterns. Let&#8217;s present most common scenarios:<\/p>\n<p><\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label8\" style=\"font-weight: bold; color: #0077c6;\">Layered Code<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label9\">One pattern that is made obvious by a DSM is\u00a0<span style=\"font-weight: bold;\">layered structure<\/span>\u00a0(i.e acyclic structure). When the matrix is triangular, with all blue cells in the lower-left triangle and all green cells in the upper-right triangle, then it shows that the structure is perfectly layered. In other words, the structure doesn\u2019t contain any dependency cycle.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image1\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/Levelized.jpg\" alt=\"\" \/><\/p>\n<p>On the right part of the snapshot, the same layered structure is represented with a graph. All arrows have the same left to right direction. The problem with graph, is that the graph layout doesn\u2019t scale. Here, we can barely see the big picture of the structure. If the number of boxes would be multiplied by 2, the graph would be completely un-readable. On the other side, the DSM representation wouldn\u2019t be affected; we say that\u00a0<span style=\"font-weight: bold;\">DSM scales better than graph<\/span>.<\/p>\n<p><i>Side note: Interestingly enough, most of graph layout algorithms rely on the fact that a graph is acyclic. To compute layout of a graph with cycles, these algorithms temporarily discard some dependencies to deal with a layered graph, and then append the discarded dependencies at the last step of the computation.\u00a0<\/i><\/p>\n<p><\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label11\" style=\"font-weight: bold; color: #0077c6;\">Dependency Cycle<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label12\">If a structure contains a cycle, the cycle is displayed by a red square on the DSM. We can see that inside the red square, green and blue cells are mixed across the diagonal. There are also some black cells that represent mutual direct usage (i.e A is using B and B is using A).<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image2\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/CycleDirect.png\" alt=\"\" \/><\/p>\n<p>The <a href=\"http:\/\/www.cppdepend.com\">CppDepend<\/a>\u2019s DSM comes with the option\u00a0<span style=\"font-weight: bold;\">Indirect Dependency<\/span>. An indirect dependency between A and B means that A is using something, that is using something, that is using something \u2026 that is using B. Below is shown the same DSM with a cycle but in indirect mode. We can see that the red square is filled up with only black cells. It just means that given any element A and B in the cycle, A and B are indirectly and mutually dependent.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image3\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/CycleIndirect.png\" alt=\"\" \/><\/p>\n<p>Here is the same structure represented with a graph. The red arrow shows that several elements are mutually dependent. But the graph is not of any help to highlight all elements involved in the parent cycle.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image4\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/CycleGraph.png\" alt=\"\" \/><br \/>\n<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label14\" style=\"font-weight: bold; color: #0077c6;\">High Cohesion &#8211; Low Coupling<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label15\">The idea of high-cohesion (inside a component) \/ low-coupling (between components) is popular nowadays. But if one cannot measure and visualize dependencies, it is hard to get a concrete evaluation of cohesion and coupling. DSM is good at showing high cohesion. In the DSM below, an obvious squared aggregate around the diagonal is displayed. It means that elements involved in the square have a high cohesion: they are strongly dependent on each other although. Moreover, we can see that they are layered since there is no cycle. They are certainly candidate to be grouped into a parent artifact (such as a namespace or an assembly).<\/p>\n<p>On the other hand, the fact that most cells around the square are empty advocate for low-coupling between elements of the square and other elements.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image6\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/HighCohesion.jpg\" alt=\"\" \/><\/p>\n<p>In the DSM below, we can see 2 components with high cohesion (upper and lower square) and a pretty low coupling between them.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image7\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/HighCohesion2.jpg\" alt=\"\" \/><\/p>\n<p>While refactoring, having such an indicator can be pretty useful to know if there are opportunities to split coarse components into several more fine-grained components.<\/p>\n<p><\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label17\" style=\"font-weight: bold; color: #0077c6;\">Too Many Responsibilities<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label18\">The\u00a0<span style=\"font-weight: bold;\">Single Responsibility Principle (SRP)<\/span>\u00a0is getting popular amongst software architects community nowadays. The principle states that:\u00a0<span style=\"font-weight: bold;\">a class shouldn\u2019t have more than one reason to change<\/span>. Another way to interpret the SRP is that a class shouldn\u2019t use too many different other types. If we extend the idea at other level (assemblies, namespaces and method), certainly, if a code element is using dozens of other different code elements (at same level), it has too many responsibilities. Often the term\u00a0<span style=\"font-weight: bold;\">God class<\/span>\u00a0or\u00a0<span style=\"font-weight: bold;\">God component<\/span>\u00a0is used to qualify such piece of code.<\/p>\n<p>DSM can help pinpoint code elements with too many responsibilities. Such code element is represented by columns with many blue cells and by rows with many green cells. The DSM below exposes this phenomenon.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image12\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/TooManyResponsabilities.jpg\" alt=\"\" \/><\/p>\n<p><\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label21\" style=\"font-weight: bold; color: #0077c6;\">Popular Code Elements<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label22\">A popular code element is used by many other code elements. Popular code elements are unavoidable (think of the<i>String<\/i>\u00a0class for example) but a popular code element is not a flaw. It just means that in every code base, there are some central concepts represented with popular classes<\/p>\n<p>A popular code element is represented by columns with many green cells and by rows with many blue cells. The DSM below highlights a popular code element.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image13\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/PopularCallee.jpg\" alt=\"\" \/><\/p>\n<p>Something to notice is that when one is keeping its code structure perfectly layered, popular components are naturally kept at low-level. Indeed, a popular component cannot de-facto use many things, because popular component are low-level, they cannot use something at a higher level. This would create a dependency from low-level to high-level and this would break the acyclic property of the structure.<br \/>\n<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label4\" style=\"font-weight: bold; color: #0077c6;\">Mutually Dependent<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label20\">You can see the coupling between 2 components by right clicking a non-empty cell, and select the menu\u00a0<i>Open this dependency<\/i>.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image11\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/MutualDependency1.jpg\" alt=\"\" \/><\/p>\n<p>If the opened cell was black as in the snapshot above (i.e if A and B are mutually dependent) then the resulting rectangular matrix will contains both green and blue cells (and eventually black cells as well) as in the snapshot below.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image10\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/MutualDependency2.jpg\" alt=\"\" \/><\/p>\n<p><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The DSM (Dependency Structure Matrix) is a compact way to represent and navigate across dependencies between components. For most engineers, talking of dependencies means talking about something that looks like that:<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1648","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1648","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1648"}],"version-history":[{"count":8,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1648\/revisions"}],"predecessor-version":[{"id":1688,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1648\/revisions\/1688"}],"wp:attachment":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1648"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1648"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1648"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}