Figure 3 - uploaded by Jannik Laval
Content may be subject to copyright.
Source publication
Dependency Structure Matrix (DSM) has been successfully applied to identify software dependencies among packages and subsystems. A number of algorithms were proposed to compute the matrix so that it highlights patterns and problematic dependencies between subsystems. However, existing DSM implementations often miss important informa- tion to fully...
Contexts in source publication
Context 1
... use color in DSM cells to identify cycles. DSM cells involved in a cycle have a yellow or red color (Figure 3). The red color means that the two concerned packages reference each other and thus create a direct cycle. ...
Context 2
... intuition is that it will be easier to fix a cycle by focusing on the side with fewer dependencies. A cell with much fewer dependencies is displayed with a bright red color whereas its symmetric cell is displayed with a light red/pink color ( Figure 3). The ratio we currently use is 1 to 3. ...
Citations
... Matrix pile. Adjacency matrices are often used to visualize edges between software related components [3], [4], [5]. Each element of a matrix indicates whether two elements are related. ...
... Brackets is a popular application, with over 27K stars and 340 contributors. Brackets has a truck factor of 5 4 . ...
... Lattix [3] offers a navigable adjacency matrix. Enriched DSM [4] augments each matrix cell with information about the indicated dependency. ...
Context
Accurately relating code authorship to commit frequency over multiple software revisions is a complex task. Most of the navigation tools found in common source code versioning clients are often too rigid to formulate specific queries and adequately present results of such queries. Questions related to evolution asked by software engineers are therefore challenging at answering using common Git clients.
Objective
This paper explores the use of stacked adjacency matrices and a domain specific language to produce tailored interactive visualizations for software evolution exploration. We are able to support some classical software evolution tasks using short and concise scripts using our language.
Method
We propose a domain-specific language to stack adjacency matrices and produce scalable and interactive visualizations. Our language and visualizations are evaluated using two independent controlled experiments and closely observing participants.
Results
We made the following findings: (i) participants are able to express sophisticated queries using our domain-specific language and visualizations, (ii) participants perform better than GitHub’s visualizations to answer a set of questions.
Conclusion
Our visual and scripting environment performs better than GitHub’s visualizations at extracting software evolution information.
... Accurately identifying dependencies between software components is essential in reengineering, reverse engineering, and software maintenance activities[1],[2]. In a statically typed language (e.g., Java), dependencies are directly expressed from the type of a program structure (e.g., method definitions, variables, class references). ...
Identifying dependencies between classes is an essential activity when maintaining and evolving software applications. It is also known that JavaScript developers often use classes to structure their projects. This happens even in legacy code, i.e., code implemented in JavaScript versions that do not provide syntactical support to classes. However, identifying associations and other dependencies between classes remain a challenge due to the lack of static type annotations. This paper investigates the use of type inference to identify relations between classes in legacy JavaScript code. To this purpose, we rely on Flow, a state-of-the-art type checker and inferencer tool for JavaScript. We perform a study using code with and without annotating the class import statements in two modular applications. The results show that precision is 100% in both systems, and that the annotated version improves the recall, ranging from 37% to 51% for dependencies in general and from 54% to 85% for associations. Therefore, we hypothesize that these tools should also depend on dynamic analysis to cover all possible dependencies in JavaScript code.
... The icicle plot works as a legend for the matrix: rows of the matrix align with the leaf nodes of the icicle plots; columns have the same order. Such hierarchical adjacency matrix representations, also called dependency structure matrices, are a common way to visualize hierarchically structured coupling graphs [23], [34], [35]. We decided against adding links to connect the nodes because such an approach does not visually scale well [36]. ...
... In software engineering circular dependencies between imports of software artifacts are widely considered as problematic. Several solutions on how to find and avoid circular dependencies have been proposed, including [15][16][17][18]. Tools with built-in support dependencies are e.g., Lattix [19] and JDepend [20]. ...
This paper describes the OntoMaven implementation of a resolution algorithm for importation in the ISO Common Logic (Edition 2) language. OntoMaven is a plug-in based extension of the Apache Maven software build tool for the development and reuse of knowledge base (KB) artifacts, such as ontologies and rule bases, managed in distributed (Web) repositories, such as Github and Subversion. The OntoMaven CL2 import plug-in contributes a proof-of-concept implementation of CL2 importation semantics that handles circular imports.
... Several articles proposed visualizations that provide information on packages and their dependencies, by visualizing metrics values, package connectivity and cycles, package evolution or the common usage of package classes (e.g., [9] [10] [11] [12] [13] [14] [15] [16] [17]). Relevant body of existing work on software understanding is based on visualization approaches [18] [19], in particular, on nodelink visualizations [20] [21] [22] [23]. ...
Large object-oriented applications are structured over many packages. Packages are important but complex structural entities that are difficult to understand since they act as containers of classes, which can have many dependencies with other classes spread over multiple packages. However to be able to take decisions (e.g. refactoring and/or assessment decisions), maintainers face the challenges of managing (sorting, grouping) the massive amount of dependencies between classes spread over multiple packages. To help maintainers, there is a need for at the same time understanding, and quantifying, dependencies between classes as well as understanding how packages as containers of such classes depend on each other.
... Each study has a different context to evaluate the usability of the eDSM visualization. We expand on our previous work [22] with an improvement of cell visualization and with multiple validations of the approach. In [22], we proposed a first visualization and a first case study. ...
... We expand on our previous work [22] with an improvement of cell visualization and with multiple validations of the approach. In [22], we proposed a first visualization and a first case study. In this paper, (i) we improve the visualization taking into account comments from users and results of the first validation, (ii) we perform two case studies to show that eDSM is usable as a valid information system for remodularization, (iii) we perform a survey to measure and assess user experience feedback. ...
Dependency structural matrix (DSM) is an approach originally developed for process optimization. It has been successfully applied to identify software dependencies among packages and subsystems. A number of algorithms have been proposed to compute the matrix so that it highlights patterns and problematic dependencies between subsystems. However, existing DSM implementations often miss important information to fully support reengineering effort. For example, they do not clearly qualify and quantify problematic relationships, information that is crucial to support remediation tasks. We propose enriched DSM (eDSM), which provides small-multiple views and micro–macro-readings by adding fine-grained information in each cell of the matrix. Each cell is enriched with contextual information about (i) the type of dependencies (inheritance, class reference, etc.), (ii) the proportion of referencing entities, and (iii) the proportion of referenced entities. We distinguish independent cycles and stress potentially simple fixes for cycles by using coloring information. This work is language independent and has been implemented on top of the Moose software analysis platform. In this paper, we expand our previous work. We improved the cell content information view on the basis of user feedback and performed multiple validations: two different case studies on Moose and Seaside software; one user study for validating eDSM as a usable approach for developers. Solutions to problems identified with eDSM have been performed and retrofitted in analyzed software. Copyright © 2012 John Wiley & Sons, Ltd.
... Moose offers various facilities for building software engineering tools, ranging from importing data, source-code modeling, querying, to building software visualizations. In the past, Moose has been successfully leveraged for building a wide variety of tools, such as Torch [27] (a tool supporting source-code change integration), SmallDude [4] (a duplication detector), and eDSM [19] (a tool to detect cyclic dependencies). Within the context of this work, we opted to base our tool on Moose for the following reasons: @BULLET FAMIX. ...
When using aspect-oriented programming the application implicitly invokes the functionality contained in the aspects. Consequently program comprehension of such a software is more intricate. To alleviate this difficulty we developed the AspectMaps visualization and tool. AspectMaps extends the Moose program comprehension and reverse engineering platform with support for aspects, and is implemented using facilities provided by Moose. In this paper we present the AspectMaps tool, and show how it can be used by performing an exploration of a fairly large aspect-oriented application. We then show how we extended the FAMIX meta-model family that underpins Moose to also provide support for aspects. This extension is called ASPIX, and thanks to this enhancement Moose can now also treat aspect-oriented software. Finally, we report on our experiences using some of the tools in Moose; Mondrian to implement the visualization, and Glamour to build the user interface. We discuss how we were able to implement a sizable visualization tool using them and how we were able to deal with some of their limitations.
Note: This paper uses colors extensively. Please use a color version to better understand the ideas presented here.
... Dependency cycles among components have for long been regarded as symptoms of design decay that should be avoided in software systems (Briand et al., 2001a;Fowler, 2001;Lakos, 1996;Martin, 2000;Martin, 1996;Parnas, 1979). Lakos (1996) argues that cycles among components present a unique problem in terms of understandability since there is no reasonably starting point and no single part of the system can make sense on its own. ...
... Dependency cycles among components have for long been regarded as symptoms of design decay that should be avoided in software systems (Briand et al., 2001a;Fowler, 2001;Lakos, 1996;Martin, 2000;Martin, 1996;Parnas, 1979). Lakos (1996) argues that cycles among components present a unique problem in terms of understandability since there is no reasonably starting point and no single part of the system can make sense on its own. For Parnas (1979), cycles, referred as "loops in the Uses Relation", can lead to a situation where nothing works in a system until everything works and that cycles prevent easy extension of software components. ...
... Despite numerous claims that cycles inhibit software quality attributes such as extensibility, understandability, testability, reusability, build-ability and maintainability (Fowler, 2001;Lakos, 1996;Martin, 2000;Parnas, 1979), evidence shows that cycles are widespread in real life software systems (Briand et al., 2001a;Hanh et al., 2001;Kung et al., 1996;Le Traon et al., 2000;Melton and Tempero, 2007a;Parnas, 1979;Tai and Daniels, 1997). The extent to which cycles are pervasive in software systems suggests that design advice (Fowler, 2001;Lakos, 1996;Martin, 2000;Parnas, 1979) regarding cyclic dependencies has not been followed. ...
Background
Empirical evidence shows that dependency cycles among software components are pervasive in real-life software systems, although such cycles are known to be detrimental to software quality attributes such as understandability, testability, reusability, build-ability and maintainability.
Research goals
Can the use of extended object-oriented metrics make us better understand the relationships among cyclic related components and their defect-proneness?
Approach
First, we extend such metrics to mine and classify software components into two groups – the cyclic and the non-cyclic ones. Next, we have performed an empirical study of six software applications. Using standard statistical tests on four different hypotheses, we have determined the significance of the defect profiles of both groups.
Results
Our results show that most defects and defective components are concentrated in cyclic-dependent components, either directly or indirectly.
Discussion and conclusion
These results have important implications for software maintenance and system testing. By identifying the most defect-prone set in a software system, it is possible to effectively allocate testing resources in a cost efficient manner. Based on these results, we demonstrate how additional structural properties could be collected to understand component's defect proneness and aid decision process in refactoring defect-prone cyclic related components.
... For example, it is specifically targeted by the Acyclic Dependencies Principle, defined by Martin [Mar00], stating that the dependency graph between packages should be a directed acyclic graph: there should not be any cyclic dependency between packages. Unfortunately, legacy and/or large systems often present structures that do not respect this principle [LDDB09]. Consequently, identifying layers in a large system is not trivial. ...
... Figure 5 presents the layered organization that we would like to see for the package structure of our example (see Figure 2). We propose heuristics that are based on observations and experiments from our previous work [LDDB09,LDD09]. The cornerstone of our approach is to find layer-breaking dependencies. Ignoring them allows one to build a layered architecture more easily, and removing them can be beneficial to the general organization of the system. ...
... To understand the complexity of large object-oriented software systems and particularly the package structure, there are some visualization tools ([DGK06, DL05, BDL05, LSP05]). Package Blueprint ([DPS + 07]) shows the communications between packages; eDSM ( [LDDB09]) and CycleTable ( [LDD09]) highlight the cycle problems in a system. However, these approaches do not identify layers for packages present in a software system. ...
A layered software architecture helps in understanding the role of software entities (e.g. packages or classes) in a system and, hence, the impact of changes on these entities. However, the computation of an optimal layered organization in the presence of cyclic dependencies is difficult. In this paper, we present an approach that (i) provides a strategy supporting the automated detection of cyclic dependencies, (ii) proposes heuristics to break cyclic dependencies, and (iii) computes an organization of software entities in multiple layers even in the presence of cyclic dependencies. Our approach performs better than the other existing approaches in terms of accuracy and interactivity, and it supports human inputs and constraints. In this paper, we present this approach and compare it to existing solutions. We applied our approach on two large software systems to identify package layers and the results are manually validated by software engineers of the two systems.
... Apart from improving the modularity of the system, re-structuring could also aim at removing cyclic dependencies between packages (e.g. see [20], [15]). We computed the number and size of Strongly Connected Components (SCC) in the system as an indicator of the presence and importance of cyclic dependencies between Java packages or Eclipse plugins. ...
... Cyclic dependencies are denounced as a bad coding practice for example in [19]. Research exists that tries to break such cycles to improve the modularity of systems (e.g. [20], [15]). We used two metrics to evaluate the system quality in terms of existence (or absence) of cycles: number of Strongly Connected Components (SCC) in the system and size of the largest SCC. ...
Software re-modularization is an old preoccupation of reverse engineering
research. The advantages of a well structured or modularized system are well
known. Yet after so much time and efforts, the field seems unable to come up
with solutions that make a clear difference in practice. Recently, some
researchers started to question whether some basic assumptions of the field
were not overrated. The main one consists in evaluating the
high-cohesion/low-coupling dogma with metrics of unknown relevance. In this
paper, we study a real structuring case (on the Eclipse platform) to try to
better understand if (some) existing metrics would have helped the software
engineers in the task. Results show that the cohesion and coupling metrics used
in the experiment did not behave as expected and would probably not have helped
the maintainers reach there goal. We also measured another possible
restructuring which is to decrease the number of cyclic dependencies between
modules. Again, the results did not meet expectations.
