Today, in a guest post, Juergen Wuest presents us his tool SDMetrics . Read his post to know more about this excellent software design metrics tool for UML!
SDMetrics is a software design quality measurement tool for the UML. It measures structural design properties such as coupling, size, and complexity of UML models. SDMetrics also checks design rules to automatically detect incomplete or incorrect design, and adherence to style guidelines such as circular dependencies or naming conventions.
Design quality measurement
Structural design properties such as complexity are known to have an impact on the quality of the resulting system. For example, high complexity or coupling can lead to increased fault-proneness, and make the system more difficult to maintain. System size is the main driver for development effort. Measures of structural properties are frequently applied to source code. Tools to calculate metrics such as LOC (lines of code) or McCabe’s Cyclomatic Complexity are available for practically every programming language.
SDMetrics applies these principles to UML models. The later a problem is found in the development process, the more expensive it is to fix. Therefore, design quality measurement has the potential to find problems earlier. By measuring the structural properties of their models, software engineers can better focus design reviews and testing efforts on the potentially critical areas that are likely sources of reliability or maintainability problems in their software designs, before they are committed to source code. Measures of design size also support effort estimation, project planning and monitoring.
Customizable design measurement
As shipped, SDMetrics calculates about 120 design metrics and 130 design rules, covering all UML diagram types. However, usage of the UML varies greatly among software organizations, in the level of detail of the models, the types OF diagrams that ARE created, the rigor WITH which the UML IS applied, AND the ways IN which the extension mechanisms OF the UML ARE used.
Therefore, users must be able TO define design measures AND rules OF their own, that ARE tailored TO the way they use the UML IN their development processes. TO this END, SDMetrics provides the “SDMetricsML”, an XML-based DOMAIN-specific LANGUAGE TO define new design metrics AND rules. ALL OF SDMetrics’ inbuilt metrics and rules are defined by means of the SDMetricsML.
Customizable XMI import
SDMetrics uses XMI for model interchange. SDMetrics imports XMI 1.x files with UML1.3/1.4 models, and XMI 2.0/2.1 files with UML 2.x models.
XMI model interchange is notoriously difficult in practice. SDMetrics addresses this problem with a customizable XMI parser which is controlled by XML-based configuration files. For UML tools that use non-standard or proprietary extensions of the UML or XMI, SDMetrics’ XMI import can be easily adapted TO account FOR the idiosyncrasies OF the UML tool.
For MORE information, see www.sdmetrics.com. SDMetrics is a commercial Java application. Academic licenses are available for universities and non-profit organizations. The XMI parser and metrics engine of SDMetrics is open source under the GNU Affero General Public License.
ICREA Research Professor at Internet Interdisciplinary Institute (UOC). Leader of the SOM Research Lab focusing on the broad area of systems and software engineering. Home page.
From a twitter conversation with @grammarware: Are there any claims on how design metrics correspond to code metrics? how we know that e.g. “complex” design in this sense will yield more complex programs? (i.e. or the opposite, how do we know the positive effects of improving the values of design metrics when afterwards generating the code?
I’m aware of one study supervised by Michel Chaudron and Christian Lange that investigates the correspondence of design structural properties to code, see http://www.langomat.de/research/papers/Correspondence_QAOOSE_ECOOP05.pdf
They find mostly moderate and a few strong correlations. As it turns out, mapping code artefacts to design artefacts is not trivial.
As to the second question, I would not advise to measure the positive effects of improving the values of design metrics in terms of the generated code, but more directly in terms of the external quality attributes (such as reliability) of the system. There are several studies that investigate these relationships at the model level, Christian Lange and Ariadi Nugroho did some of the best work in that area in the course of their PhDs.
That’s one major advantage ON HAVING a visual LANGUAGE, that IS used BOTH FOR design AND development. If you have joint models you can track the complexity across the whole solution, AND even relate that TO team performance, NOT just system quality. We’ve been doing some work related with this right on the field, applying it to some dozens of projects delivered with our platform. From that, we built a tool that automatically analyzes and gives suggestions on how to improve the model. It still needs a lot of work though to ensure that, for instance, ‘master entities’ are easily infered from the domain model and tracked down the whole model. This is definitely something that will help systems to stay ‘young’ and manageable over time as they grow.
what kind of information presented in the Xmi is useful for the metrics??
like for example the metrics in the design diagram
The XMI includes all the information about the elements in your model, XMI is just an storage format for your models