{"id":27,"date":"2018-03-08T08:11:23","date_gmt":"2018-03-08T08:11:23","guid":{"rendered":"http:\/\/cppdepend.com\/wordpress\/?p=27"},"modified":"2023-05-31T16:05:25","modified_gmt":"2023-05-31T16:05:25","slug":"visualizing-cpp-projects-power-of-pictures","status":"publish","type":"post","link":"https:\/\/cppdepend.com\/blog\/visualizing-cpp-projects-power-of-pictures\/","title":{"rendered":"Visualizing C\/C++ Projects: The Power of Pictures"},"content":{"rendered":"<p><span style=\"color: #252525;\">&#8220;<\/span><strong style=\"color: #252525;\">A picture is worth a thousand words<\/strong><span style=\"color: #252525;\">&#8221; is an\u00a0<\/span>English<span style=\"color: #252525;\">\u00a0<\/span>idiom<span style=\"color: #252525;\">. It refers to the notion that a complex idea can be conveyed with just a single still image or that an image of a subject conveys its meaning or essence more effectively than a description does.<\/span><\/p>\n<p>This idiom could also be applied in software programming. Indeed you can easilly understand a mini project when exploring its source code. However a big project become complex and not easy to understand. \u00a0In such cases it&#8217;s better to visualize the source code using graphs and diagrams to assist the developers\u00a0understanding the source code.<img decoding=\"async\" class=\"mceWPmore mceItemNoResize\" title=\"More...\" src=\"http:\/\/javadepend.com\/Blog\/wp-includes\/js\/tinymce\/plugins\/wordpress\/img\/trans.gif\" alt=\"\" \/><!--more--><\/p>\n<p>Let&#8217;s discover some useful diagrams \u00a0provided by <a href=\"http:\/\/www.cppdepend.com\">CppDepend<\/a> to understand the code base.<\/p>\n<p><strong>I-Treemap diagram<\/strong>:<\/p>\n<p><span style=\"color: #333333;\">Treemapping is a method for displaying tree-structured data by using nested rectangles. The tree structure used in CppDepend treemap is the usual code hierarchy:<\/span><\/p>\n<ul style=\"color: #333333;\">\n<li style=\"color: #555555;\">C\/C++ projects contain namespaces,<\/li>\n<li style=\"color: #555555;\">Namespaces contain types,<\/li>\n<li style=\"color: #555555;\">Types contains methods and fields.<\/li>\n<\/ul>\n<p><span style=\"color: #333333;\">With treemap rectangles represent code elements. The option\u00a0<\/span><span style=\"font-weight: bold; color: #333333;\">level<\/span><span style=\"color: #333333;\">\u00a0determines the kind of code element represented by unit rectangles. The option\u00a0<\/span><span style=\"font-weight: bold; color: #333333;\">level<\/span><span style=\"color: #333333;\">\u00a0can take the 5 values: project, namespace, type, method and field. The two screenshots below shows the same code base represented through type level on left, and namespace level on right.\u00a0<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><img loading=\"lazy\" decoding=\"async\" id=\"img1\" class=\"img-responsive\" style=\"color: #333333;\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/TreemapIntro2.png\" alt=\"\" width=\"678\" height=\"371\" \/><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">The option\u00a0<\/span><span style=\"font-weight: bold; color: #333333;\">Code Metric<\/span><span style=\"color: #333333;\">\u00a0of the treemap determines the size of rectangles. For example if level is set to\u00a0<\/span><em style=\"color: #333333;\">type<\/em><span style=\"color: #333333;\">\u00a0and metric is set to<\/span><em style=\"color: #333333;\">number of Lines of Code<\/em><span style=\"color: #333333;\">, each unit rectangle represents a type, and the size of a unit rectangle is proportional to the number of Lines of Code of the corresponding type.\u00a0<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">If a CQLinq query is currently edited, the set of code elements matched by the query is shown on the treemap as a set of blue rectangles. In the screenshot below, a CQLinq query matches the 200 largest methods. Here the treemap level is\u00a0<\/span><em style=\"color: #333333;\">method<\/em><span style=\"color: #333333;\">\u00a0and the metric is\u00a0<\/span><em style=\"color: #333333;\">number of lines of code<\/em><span style=\"color: #333333;\">. As expected, we can see that blue rectangles represent the 200 largest unit rectangles of the treemap.\u00a0<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">The screenshot below also shows that the currently pointed code element (here the project\u00a0<\/span><em style=\"color: #333333;\">XML<\/em><span style=\"color: #333333;\">) is shown as a red rectangles on the treemap.\u00a0<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><img loading=\"lazy\" decoding=\"async\" id=\"imgSandTrail1\" class=\"img-responsive\" style=\"color: #333333;\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/TreemapIntro.png\" alt=\"\" width=\"605\" height=\"296\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label5\" style=\"font-weight: bold; color: #496ca0;\">Common Scenarios<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label6\" style=\"color: #333333;\">By choosing an appropriate combination of\u00a0<span style=\"font-weight: bold;\">metric<\/span>\u00a0and\u00a0<span style=\"font-weight: bold;\">level<\/span>\u00a0values, the\u00a0<span style=\"font-weight: bold;\">Metric View<\/span>\u00a0helps see patterns that would be hard to spot with other ways.<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label8\" style=\"font-weight: bold; color: #0077c6;\">Too Big, Too Complex<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label9\">CppDepend provides many code metrics to spot too big and too complex code. Method with too many parameters, too many variables, too many lines of code, too high cyclomatic complexity etc&#8230; should be banished. The same way types with too many lines of code should be banished too.<\/span><\/p>\n<p>On the screenshot below, the treemap level is set to\u00a0<em>type<\/em>\u00a0and the metric is\u00a0<em>number of lines of code<\/em>. Large rectangles represent large types of the code base. Hovering a rectangle with the mouse indicates the type metric values, here the type number of lines of code. Clearly, code treemaping helps not only spotting too large and too complex code elements, but also, it helps comparing their respective size and complexity.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image8\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/TooBig.png\" alt=\"\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label11\" style=\"font-weight: bold; color: #0077c6;\">Flaws Localization<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label12\">In the screenshot below we are asking with a CQLinq query, for methods with too many parameters and too many variables. Blue rectangles show matched methods on the treemap. Here the interesting point is that some matched methods seem to be grouped. Because treemap is a hierarchical view, if a set of code elements is grouped, it means that the code elements belong to the same parent. And indeed, here the 12 methods grouped belong to the same type.<\/span><\/p>\n<p>Spotting the parent types of these 12 methods would have been hard without treemaping. Now the code quality reviewer can focus his attention on this region that seems to contain more flaws than other part of the code base.<\/p>\n<p><img decoding=\"async\" id=\"img2\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/FlawsLocalization.png\" alt=\"\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label17\" style=\"font-weight: bold; color: #0077c6;\">Top-Down Code Exploration<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label18\">The CppDepend treemap metric view supports zoom-in and zoom-out. This makes easy to zoom on a particular project, namespace or class. This can be especially useful to explore and compare the volume of components in terms of lines of code.<\/span><\/p>\n<p>By no mean productivity should be measured in terms of lines of code. However counting lines of code has been proven to be a useful metric to accurately estimate software, given a certain context of an organization. The code base features are somehow partitioned into assemblies, namespaces and types. With treemaping, these artifacts become rectangles that sit side-by-side. Rectangles areas, hence features weight, can be compared visually. Being able to periodically explore code size through treemaping is a unique way to build an accurate sense of feature weight and feature cost.<\/p>\n<p>Do the experiment to visualize treemap on a code base you know well, and you&#8217;ll be surprised to discover unexpected feature size.<\/p>\n<p><img decoding=\"async\" id=\"img3\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/TopDown.png\" alt=\"\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label21\" style=\"font-weight: bold; color: #0077c6;\">Code Structure Observations<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label22\">Choosing to use the\u00a0<span style=\"font-weight: bold;\">Metric View<\/span>\u00a0with a metric different than volume (lines of code, number of parameters for methods&#8230;) or complexity, can reveal interesting observations.<\/span><\/p>\n<p>The\u00a0<a style=\"color: #72c02c;\" href=\"http:\/\/www.cppdepend.com\/Metrics.aspx#TypeRank\">ranking metric<\/a>\u00a0is a code metric that measure the popularity of a type or a method in a code base. Using treemaping with the ranking metric gives a clear view of where popular types are declared. This quickly gives information about what is important in the code base.<\/p>\n<p>The screenshot below shows types of the\u00a0<em>Microsoft DLR (Dynamic language Runtime)<\/em>\u00a0code base treemaped with the ranking metric. The treemap indicates that\u00a0<em>CallSite<\/em>\u00a0and\u00a0<em>Expression<\/em>\u00a0are popular concepts of the DLR, and this is indeed the case.<\/p>\n<p>The same kind of interesting Code Structure Observations can be made with code metrics such as\u00a0<a style=\"color: #72c02c;\" href=\"http:\/\/www.cppdepend.com\/Metrics.aspx#TypeCa\">Afferent\/Efferent coupling<\/a>\u00a0or\u00a0<a style=\"color: #72c02c;\" href=\"http:\/\/www.cppdepend.com\/Metrics.aspx#Level\">Level<\/a>.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image1\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Treemap\/CodeStructure.png\" alt=\"\" \/><\/p>\n<p><strong>\u00a0II- Dependency Graph<\/strong><\/p>\n<p><span style=\"color: #333333;\">CppDepend offers a wide range of facilities to help user exploring an Existing Code Architecture using the dependency grapj. here are some\u00a0most popular Code Exploration scenarios:<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label5\" style=\"font-weight: bold; color: #496ca0;\">Call Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">CppDepend can generate any call graph you might need with a two steps procedure.<\/span><\/p>\n<ul>\n<li style=\"color: #555555;\"><span style=\"font-weight: bold;\">First<\/span>: Ask for direct and indirect callers\/callees of a type, a field, a method, a namespace or a project. The effect is that the following CQLinq query is generated to match all callers or callees asked.<img decoding=\"async\" id=\"img4\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/CallGraph1.png\" alt=\"\" \/><\/li>\n<\/ul>\n<ul>\n<li style=\"color: #555555;\">Notice that, in the CQLinq query result, the metric\u00a0<em>DepthOfIsUsing\/DepthOfIsUsedBy<\/em>\u00a0shows depth of usage (1 means direct, 2 means using a direct user etc&#8230;). The CQLinq query can easily be modified to only match indirect callers\/callees with a certain condition on depth of usage.Notice also that callers\/callees asked are not necessarily of the same kind of the concerned code element. For example here we ask for methods that are using directly or indirectly a type.<\/li>\n<li style=\"color: #555555;\"><span style=\"font-weight: bold;\">Second<\/span>: Once the CQLinq query matches the set of callers\/callees that the user wishes, the set of matches result can be exported to the Dependency Graph. This has for effect to show the call graph wished.<img decoding=\"async\" id=\"img5\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/CallGraph2.png\" alt=\"\" \/><\/li>\n<\/ul>\n<p><span id=\"ctl00_MyContentPH_Label9\" style=\"font-weight: bold; color: #496ca0;\">Class Inheritance Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">To display a Class of Inheritance Graph, the same two steps procedure shown in the precedent section (on generating a Call Graph) must be applied.<\/span><\/p>\n<ul>\n<li style=\"color: #555555;\"><span style=\"font-weight: bold;\">First<\/span>: Generate a CQLinq query asking for the set of classes that inherits from a particular class (or that implement a particular interface). Here, the following CQLinq query is generated:<img decoding=\"async\" id=\"img6\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Inherit1.png\" alt=\"\" \/><\/li>\n<li style=\"color: #555555;\"><span style=\"font-weight: bold;\">Second<\/span>: Export the result of the CQLinq query to the Dependency Graph to show the inheritance graph wished.<img decoding=\"async\" id=\"img7\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Inherit2.png\" alt=\"\" \/><\/li>\n<\/ul>\n<p><span id=\"ctl00_MyContentPH_Label11\" style=\"font-weight: bold; color: #496ca0;\">Coupling Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label12\" style=\"color: #333333;\">It might be needed to know which code elements exactly are involved in a particular dependency. Especially when one needs to anticipate the impact of a structural change. In the screenshoot below, the CppDepend Info panel describes a coupling between 2 projects.<\/span><\/p>\n<p>From pointing a cell in the dependency matrix, it says that X types of an project A are using Y types of an project B. Notice that you can change the option\u00a0<em>Weight on Cell<\/em>\u00a0to\u00a0<em># methods<\/em>,\u00a0<em># members<\/em>\u00a0or\u00a0<em># namespaces<\/em>, if you need to know the coupling with something else than types.<\/p>\n<p><img decoding=\"async\" id=\"img8\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Coupling1.png\" alt=\"\" \/><\/p>\n<p>Just left clicking the matrix cell shows the coupling graph below.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image2\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Coupling2.png\" alt=\"\" \/><\/p>\n<p>A coupling graph can also be generated from an edge in the dependency graph. Here, you can adjust the option\u00a0<em>Edge Thickness<\/em>\u00a0to something else than\u00a0<em># type<\/em>.<\/p>\n<p><img decoding=\"async\" id=\"img9\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Coupling3.png\" alt=\"\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label13\" style=\"font-weight: bold; color: #496ca0;\">Path Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label14\" style=\"color: #333333;\">If you wish to dig into a path or a dependency cycle between 2 code elements, the first thing to do is to show the dependency matrix with the option\u00a0<em>Weight on Cells:<\/em>\u00a0<span style=\"font-weight: bold;\">Direct &amp; indirect depth of use<\/span>.<\/span><\/p>\n<p>Matrix blue and green cells will represent\u00a0<em>paths<\/em>\u00a0while black cells will represent\u00a0<em>dependency cycles<\/em>. For example, here, the Info panel tells us that there is a path of minimal length 7 between the 2 types involved.<\/p>\n<p><img decoding=\"async\" id=\"img10\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Path1.png\" alt=\"\" \/><\/p>\n<p>Just left clicking the cell shows the path graph below.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" id=\"ctl00_MyContentPH_Image1\" class=\"img-responsive aligncenter\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Path2.png\" alt=\"\" width=\"162\" height=\"470\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label24\" style=\"font-weight: bold; color: #496ca0;\">All Paths Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label25\" style=\"color: #333333;\">In certain situations, you&#8217;ll need to know about all paths from a code element A to a code element B. For example, here, the Info panel tells us that there is a path of minimal length 2 between the 2 types involved.<\/span><\/p>\n<p><img decoding=\"async\" id=\"img14\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/AllPaths1.png\" alt=\"\" \/><\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image5\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/AllPaths2.png\" alt=\"\" \/><\/p>\n<p>Finally exporting to the graph the 12 types matched by the CQLinq query, shows all paths from A to B.<\/p>\n<p><img decoding=\"async\" id=\"img15\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/AllPaths3.png\" alt=\"\" \/><\/p>\n<p><span id=\"ctl00_MyContentPH_Label1\" style=\"font-weight: bold; color: #496ca0;\">Cycle Graph<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label2\" style=\"color: #333333;\">As we explained in the previous section, to deal with dependency cycle graphs, the first thing to do is to show the dependency matrix with the option\u00a0<em>Weight on Cells:<\/em>\u00a0<span style=\"font-weight: bold;\">Direct &amp; indirect depth of use<\/span>. Black cells then represent cycles.<\/span><\/p>\n<p>For example, here, the Info panel tells us that there is a dependency cycle of minimal length 5 between the 2 types involved.<\/p>\n<p><img decoding=\"async\" id=\"img11\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Cycle1.png\" alt=\"\" \/><\/p>\n<p>Just left clicking the cell shows the cycle graph below.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image3\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Cycle2.png\" alt=\"\" \/><\/p>\n<p>We&#8217;d like to warn that obtaining a clean &#8217;rounded&#8217; dependency cycle as the one shown above, is actually more an exceptional situation than a rule.<\/p>\n<p>Often, exhibiting a cycle will end up in a not &#8217;rounded&#8217; graph as the one shown below. In this example, the minimal length of a cycle between the 2 types involved (in yellow) is 12. Count the number of edges crossed from one yellow type to the other one, and you&#8217;ll get 12. You&#8217;ll see that some edges will be counted more than once.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image4\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/Cycle3.png\" alt=\"\" \/><\/p>\n<p><strong>III &#8211; Dependency Structure Matrix\u00a0<\/strong><\/p>\n<p><span id=\"ctl00_MyContentPH_Label15\" style=\"font-weight: bold; color: #496ca0;\">Large Graph visualized with Dependency Structure Matrix<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span style=\"color: #333333;\">Here, we&#8217;d like to underline the fact that when the dependency Graph becomes unreadable, it is worth switching to the dependency Matrix.<br \/>\nBoth dependency Graph and dependency Matrix co-exist because:<\/span><\/p>\n<ul>\n<li style=\"color: #555555;\">Dependency Graph is intuitive but becomes unreadable as soon as there are too many edges between nodes.<\/li>\n<li style=\"color: #555555;\">Dependency Matrix requires time to be understood, but once mastered, you&#8217;ll see that\u00a0<span style=\"font-weight: bold;\">the Dependency Matrix is much more efficient than the Dependency Graph to explore an existing architecture<\/span>. More information on the Dependency Matrix readability can be found in\u00a0<a style=\"color: #555555;\" href=\"http:\/\/codebetter.com\/blogs\/patricksmacchia\/archive\/2009\/08\/24\/identify-code-structure-patterns-at-a-glance.aspx\" target=\"_blank\" rel=\"noopener\">Identify Code Structure Patterns at a Glance<\/a><\/li>\n<\/ul>\n<p><span id=\"ctl00_MyContentPH_Label16\" style=\"color: #333333;\">To illustrate the point, find below the same dependencies between 77 namespaces shown through Dependency Graph and Dependency Matrix.<\/span><\/p>\n<p><img decoding=\"async\" id=\"img12\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/LargeGraph.png\" alt=\"\" \/><\/p>\n<p><img decoding=\"async\" id=\"img13\" class=\"img-responsive\" title=\"\" src=\"http:\/\/www.cppdepend.com\/Doc\/VS_Arch\/LargeMatrix.png\" alt=\"\" \/><\/p>\n<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:<\/span><\/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.<\/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<em>Net<\/em>\u00a0to\u00a0<em>Foundation<\/em>\u00a0is represented by a non empty cell in the matrix and by an arrow in the graph.<\/span><\/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:<\/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;\">Once one understood DSM principles, typically one prefers DSM over graph to represent dependencies. This is mainly because DSM offers the possibility to\u00a0<span style=\"font-weight: bold;\">spot structural patterns at a glance<\/span>. This is explained in the second half of the current document.<\/span><\/p>\n<p>CppDepend offers\u00a0<span style=\"font-weight: bold;\">Context-Sensitive Help<\/span>\u00a0to educate the user about what he sees on DSM. CppDepend&#8217;s DSM relies on a simple 3 coloring scheme for DSM cell: Blue, Green and Black. When hovering a row or a column with the mouse, the Context-Sensitive Help explains the meaning of this coloring scheme:<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image14\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/RowColumn.png\" alt=\"\" \/><\/p>\n<p>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>CppDepend&#8217;s DSM comes with numerous options to try:<\/p>\n<ul>\n<li style=\"color: #555555;\">It has numerous facilities to dig into dependency exploration (a parent column\/row can be opened, cells can be expanded&#8230;)<\/li>\n<li style=\"color: #555555;\">It can deal with squared symmetric DSM and rectangular non-symmetric DSM<\/li>\n<li style=\"color: #555555;\">Horizontal and Vertical headers can be bound, to constantly have a squared symmetric matrix<\/li>\n<li style=\"color: #555555;\">It comes with the option\u00a0<span style=\"font-weight: bold;\">Indirect usage<\/span>, where cell shows direct and indirect usage<\/li>\n<li style=\"color: #555555;\">The vertical header can contains tier code elements<\/li>\n<li style=\"color: #555555;\">&#8230;<\/li>\n<\/ul>\n<p><span id=\"ctl00_MyContentPH_Label1\" style=\"color: #333333;\">It is advised to experience all these features by yourself, by analyzing dependencies into your code base.<\/span><\/p>\n<p><span id=\"ctl00_MyContentPH_Label5\" style=\"font-weight: bold; color: #496ca0;\">Identify Code Structure Patterns on Matrix<\/span><br style=\"color: #333333;\" \/><br style=\"color: #333333;\" \/><span id=\"ctl00_MyContentPH_Label6\" style=\"color: #333333;\">As explained in the introduction, DSM comes with the particularity to offer easy identification of popular Code Structure Patterns. Let&#8217;s present most common scenarios:<\/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.<\/span><\/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><em>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<\/em><\/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).<\/span><\/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 CppDepend\u2019s DSM comes with the unique 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=\"\" \/><\/p>\n<p>Notice that in CppDepend, we provided a button to highlight cycles in the DSM (if any). If the structure is layered, then this button has for effect to triangularize the matrix and to keep non-empty cells as closed as possible to the diagonal.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image5\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/TriangularizeMatrix.jpg\" alt=\"\" \/><\/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).<\/span><\/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 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.<\/span><\/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 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<em>String<\/em>\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<\/span><\/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.<\/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<em>Open this dependency<\/em>.<\/span><\/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>In this situation, you\u2019ll often notice a deficit of green or blue cells (3 blue cells for 1 green cell here). It is because even if 2 code elements are mutually dependent, there often exists a natural level order between them. For example, consider the\u00a0<em>System.Threading<\/em>\u00a0namespaces and the\u00a0<em>System.String<\/em>\u00a0class. They are mutually dependent; they both rely on each other. But the matrix shows that\u00a0<em>Threading<\/em>\u00a0is much more dependent on\u00a0<em>String<\/em>\u00a0than the opposite (there are much more blue cells than green cells). This confirms the intuition that\u00a0<em>Threading<\/em>\u00a0is upper level than\u00a0<em>String<\/em>.<\/p>\n<p><img decoding=\"async\" id=\"ctl00_MyContentPH_Image9\" class=\"img-responsive\" src=\"http:\/\/www.cppdepend.com\/Doc\/Matrix\/ThreadingToString.jpg\" alt=\"\" \/><\/p>\n","protected":false},"excerpt":{"rendered":"<p>&#8220;A picture is worth a thousand words&#8221; is an\u00a0English\u00a0idiom. It refers to the notion that a complex idea can be conveyed with just a single still image or that an image of a subject conveys its meaning or essence more effectively than a description does. This idiom could also be applied in software programming. Indeed &hellip; <a href=\"https:\/\/cppdepend.com\/blog\/visualizing-cpp-projects-power-of-pictures\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Visualizing C\/C++ Projects: The Power of Pictures&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[18,49,194,193,21,20],"class_list":["post-27","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-cppdepend","tag-dependency-graph","tag-dependency-matrix","tag-dsm","tag-graph","tag-treemap"],"_links":{"self":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/27","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/comments?post=27"}],"version-history":[{"count":4,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/27\/revisions"}],"predecessor-version":[{"id":1486,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/27\/revisions\/1486"}],"wp:attachment":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/media?parent=27"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/categories?post=27"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/tags?post=27"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}