Fig 1 - uploaded by Cornelia Boldyreff
Content may be subject to copyright.
![The UML metamodel architecture [10]](profile/Cornelia-Boldyreff-3/publication/228477363/figure/fig1/AS:301964446453764@1449005342863/The-UML-metamodel-architecture-10.png)
Source publication
![Fig. 1. The UML metamodel architecture [10]](profile/Cornelia-Boldyreff-3/publication/228477363/figure/fig1/AS:301964446453764@1449005342863/The-UML-metamodel-architecture-10_Q320.jpg)
This paper proposes some new software metrics that can be applied to UML modelling elements like classes and messages. These metrics can be used to predict var-ious characteristics at the earlier stages of the software life cycle. A CASE tool is de-veloped on top of Rational Rose 1 using its BasicScript language and we provide some examples using i...
Contexts in source publication
Context 1
... metrics can be used to find out the properties of the software that we are developing and predict the needed effort and development period. Many different kinds of metrics have been developed during the past few decades matching with the different programming paradigms like structural programming and object-oriented programming (OOP). Among these, “LOC (Lines of Code)” is one of the most primitive and oldest metrics. In the beginning of 1990s, Chidamber and Kemerer proposed six new object-oriented metrics to overcome the limitations of the more traditional code-based metrics [1]. They are “weighted methods per class (WMC)”, “depth of inheritance tree (DIT)”, “number of children (NOC)”, “coupling between object classes (CBO)”, “response for a class (RFC)”, finally, “lack of cohesion in methods (LCOM)”. Their metrics have certainly helped users analyse their code to some extent along with other similar OO metrics. However, as software engineers’ focus has shifted to the earlier stages of the life cycle, the shortcomings of OO code metrics like their predecessors have become more apparent. Therefore a comprehensive approach to developing and applying metrics to artifacts such as designs produced at the early stages of the life cycle is needed. In the meantime, the Unified Modelling Language (UML) was adopted by the Object Management Group (OMG) in 1997 ending the so-called “OO methods war”, and since then has become the de facto specification standard graphical language for spec- ifying, constructing, visualising, and documenting software systems, business modelling and other non-software systems [10]. UML has been intensively used by software developers since its introduction. Many organisations are using UML as a com- mon language for their project artefacts and have adopted UML as their organisation’s standard. As the amount of UML models produced within a organisation increased, a need for measuring their characteristics has arisen. The investigation described in this paper goes into this direction. The overall aim of this paper is the development of software metrics that can be applied to UML models. These metrics are comparable to UML itself in such a way that it plays a role as a standardised metrics suite. This paper is organised as follows. Section 2 surveys some similar work on software metrics development to the one reported in this paper. Section 3 introduces new metrics that are called UML metrics with their definitions. In Section 4, the implementation aspects of these metrics are studied. A CASE tool called UMP (UML Metrics Producer) is developed. Finally, Section 5 draws some conclusions and suggests further work to be carried out. Since Chidamber and Kemerer published their OO metrics suite [1], many researchers have developed new metrics based on their own experience [5]. This is due to the fact that OOP was becoming more popular in the software development scene. Also there has been a strong interest in automating the production of these metrics. CCCC (C and C++ Code Counter) 2 , JMetric 3 and McCabe’s metrics tool 4 are among them. Most of these new metrics and tools, however, only deal with language-dependent source code that is typically available at the later stages of the software life cycle, failing to address the importance of the software artifacts produced during the earlier stages such as requirement and analysis stages. This paper reports an attempt to overcome these limitations by measuring UML models. UML adopts different layers of metamodel as shown in Figure 1. For instance, a class is an instance of the metaclass, Class of the UML Metamodel, which in turn is an instance of the metaclass, Class of the MOF Meta-Metamodel. At the bottom it shows how an object can be instantiated from a class of the analysis model. This kind of modelling scheme helps define different modelling elements and the relationships between them more precisely and formally. For example, Figure 2 elabo- rated from Figure 1 shows various relationships that can exist between classes such as generalisation, association and aggregation. The UML metrics proposed here are based on this metamodel scheme. Below the four categories of metrics are suggested, i.e. model, class, message, and use case metrics. Table 1 shows the 27 mostly new metrics to measure various characteristics of UML ...
Context 2
... metrics can be used to find out the properties of the software that we are developing and predict the needed effort and development period. Many different kinds of metrics have been developed during the past few decades matching with the different programming paradigms like structural programming and object-oriented programming (OOP). Among these, “LOC (Lines of Code)” is one of the most primitive and oldest metrics. In the beginning of 1990s, Chidamber and Kemerer proposed six new object-oriented metrics to overcome the limitations of the more traditional code-based metrics [1]. They are “weighted methods per class (WMC)”, “depth of inheritance tree (DIT)”, “number of children (NOC)”, “coupling between object classes (CBO)”, “response for a class (RFC)”, finally, “lack of cohesion in methods (LCOM)”. Their metrics have certainly helped users analyse their code to some extent along with other similar OO metrics. However, as software engineers’ focus has shifted to the earlier stages of the life cycle, the shortcomings of OO code metrics like their predecessors have become more apparent. Therefore a comprehensive approach to developing and applying metrics to artifacts such as designs produced at the early stages of the life cycle is needed. In the meantime, the Unified Modelling Language (UML) was adopted by the Object Management Group (OMG) in 1997 ending the so-called “OO methods war”, and since then has become the de facto specification standard graphical language for spec- ifying, constructing, visualising, and documenting software systems, business modelling and other non-software systems [10]. UML has been intensively used by software developers since its introduction. Many organisations are using UML as a com- mon language for their project artefacts and have adopted UML as their organisation’s standard. As the amount of UML models produced within a organisation increased, a need for measuring their characteristics has arisen. The investigation described in this paper goes into this direction. The overall aim of this paper is the development of software metrics that can be applied to UML models. These metrics are comparable to UML itself in such a way that it plays a role as a standardised metrics suite. This paper is organised as follows. Section 2 surveys some similar work on software metrics development to the one reported in this paper. Section 3 introduces new metrics that are called UML metrics with their definitions. In Section 4, the implementation aspects of these metrics are studied. A CASE tool called UMP (UML Metrics Producer) is developed. Finally, Section 5 draws some conclusions and suggests further work to be carried out. Since Chidamber and Kemerer published their OO metrics suite [1], many researchers have developed new metrics based on their own experience [5]. This is due to the fact that OOP was becoming more popular in the software development scene. Also there has been a strong interest in automating the production of these metrics. CCCC (C and C++ Code Counter) 2 , JMetric 3 and McCabe’s metrics tool 4 are among them. Most of these new metrics and tools, however, only deal with language-dependent source code that is typically available at the later stages of the software life cycle, failing to address the importance of the software artifacts produced during the earlier stages such as requirement and analysis stages. This paper reports an attempt to overcome these limitations by measuring UML models. UML adopts different layers of metamodel as shown in Figure 1. For instance, a class is an instance of the metaclass, Class of the UML Metamodel, which in turn is an instance of the metaclass, Class of the MOF Meta-Metamodel. At the bottom it shows how an object can be instantiated from a class of the analysis model. This kind of modelling scheme helps define different modelling elements and the relationships between them more precisely and formally. For example, Figure 2 elabo- rated from Figure 1 shows various relationships that can exist between classes such as generalisation, association and aggregation. The UML metrics proposed here are based on this metamodel scheme. Below the four categories of metrics are suggested, i.e. model, class, message, and use case metrics. Table 1 shows the 27 mostly new metrics to measure various characteristics of UML ...
Similar publications
Citations
... Kim and Boldyreff suggested a software metrics that can be applied to the elements of UML modelling [49]. Doraisamy et al. proposed a model metric to be a guideline for software project managers in order to control and monitor software [50]. ...
Software complexity is an indicator to the quality of software. It shows that a software or a component of software has a design or implementation that is difficult to understand, modify and maintain. Many complexity metrics have been developed by researchers to identify and measure the degree of complexity. Unfortunately, Current complexity metrics are based on the number of model elements only, regardless of the complexity of those elements themselves. In this paper, we propose new code complexity metrics that are derived from its design. This approach ensures that the derived metrics are uniquely tailored for the software under development, and the derived metrics are unique for each software module. In this study, we aim to attempt an empirical evaluation study in order to have a clear understanding of the proposed complexity metrics. We investigated whether there is a correlation between the proposed UML Class Diagram complexity and the associated code, specially code size, code smells, and technical debt. The result shows that there is a high correlation between the design driven code complexity metrics and the associated code.
... Genero et al. [44] proposed a set of complexity measures based on the UML class diagram. Kim and Boldyreff [45] proposed a number of metrics that can be used at early stages of software development. Their metric suite covered class, sequence and use case diagrams. ...
... We further searched for additional metrics that could cover use case and sequence diagram models. Hence, we established a suite of metrics that includes the traditional OO metrics such as CK metric suite and other metrics proposed by Henry and Kafura [47], Kim and Boldyreff [45], Ambler [93] and those included in a popular UML metrics tools called SDMetrics [94]. The list of these metrics is shown in Table 8. ...
Software refactoring is the process of changing a software system in a manner that does not alter its external behavior and yet improving its internal structure. Model-driven architecture and the popularity of the UML enabled the application of refactoring at model level, which was earlier applied to software code. In this paper, we propose a multi-view integrated approach to model-driven refactoring using UML models. We selected a single model from each UML view at metamodel level to construct an integrated metamodel. We selected class diagram to represent the structural view, sequence diagram to represent the behavioral view and use case diagram to represent the functional view. We validated the proposed approach by comparing integrated refactoring approach with refactoring applied to models individually in terms of quality improvement through UML model metrics. Our results indicate that more bad smell instances can be detected using the integrated approach rather than the individual refactoring approach.
... For example, they find that the use of inheritance is directly proportional to the size of meta-models. Other examples are the studies from Hyoseob et al. [36] and McQuillan et al. [37] who analyze the applicability of a set of objectoriented metrics for measuring a wide range of properties of UML models that can also be applied to UML-based metamodels. Although most of these metrics could be calculated for consecutive meta-model versions, they are not designed for monitoring the evolution of meta-models and therefore their use for this purpose is not fully applicable. ...
Domain-specific meta-models play an important role in the design of large software systems by defining language for the architectural models. Such common modeling languages are particularly important if multiple actors are involved in the development process as they assure interoperability between modeling tools used by different actors. The main objective of this paper is to facilitate the adoption of new domain-specific meta-model versions, or a subset of the new architectural features they support, by the architectural modeling tools used by different actors in the development of large software systems. In order to achieve this objective, we developed a simple measure of meta-model evolution (named NoC—Number of Changes) that captures atomic modification between different versions of the analyzed meta-model. We evaluated the NoC measure on the evolution of the AUTOSAR meta-model, a domain-specific meta-model used in the design of automotive system architectures. The evaluation shows that the measure can be used as an indicator of effort needed to update meta-model-based tools to support different actors in modeling new architectural features. Our detailed results show the impact of 14 new AUTOSAR features on the modeling tools used by the main actors in the automotive development process. We validated our results by finding a significant correlation between the results of the NoC measure and the actual effort needed to support these features in the modeling tools reported by the modeling practitioners from four AUTOSAR tool vendors and the AUTOSAR tooling team at Volvo Cars. Generally, our study shows that quantitative analysis of domain-specific meta-model evolution using a simple measure such as NoC can be used as an indicator of the required updates in the meta-model-based tools that are needed to support new meta-model versions. However, our study also shows that qualitative analysis that may include an inspection of the actual meta-model changes is needed for more accurate assessment.
... Considering UML models, there exist manifold model qualities. We chose the work of Lange (2006) to be most suitable and linked it with metrics, keeping in mind the work of McQuillan and Power (2006), and Kim and Boldyreff (2002). We then employed the work of Genero et al. (2003), (Wedemeijer 2001), and (Mohagheghi and Dehlen 2009), who described model quality as a set of dimensions and identified two primary cases of model use: maintenance and development. ...
Model evolution in model libraries differs from general model evolution. It
limits the scope to the manageable and allows to develop clear concepts,
approaches, solutions, and methodologies. Looking at model quality in evolving
model libraries, we focus on quality concerns related to reusability. In this
paper, we put forward our proactive quality guidance approach for model
evolution in model libraries. It uses an editing-time assessment linked to a
lightweight quality model, corresponding metrics, and simplified reviews. All
of which help to guide model evolution by means of quality gates fostering
model reusability.
... The ATM shall indicate that it is "Closed" af6.5 bf2->af1, bf8->af2, bf7->af3, bf8->af4, bf7->af5, bf8->af6, bf9->af7 6.8 Snapshot of class metrics derivedMetrics taken from [16] 6.9 Snapshot of Traceability Tree ...
... Use case metrics are used to count the number requirements in a scenario [2]. ...
... Whichever the methodology adapted, the success of the product is basically relying on quality of the design architecture. There are many such design quality metrics in existence being used to ensure the quality of final product at design level [2]. ...
In recent years, Software has become an indispensable part of every segment
from simple Office Automation to Space Technology and E-mail to E-commerce. The
evolution in Software architecture is always an open issue for researchers to
address complex systems with numerous domain-specific requirements. Success of
a system is based on quality outcome of every stage of development with proper
measuring techniques. Metrics are measures of Process, Product and People (P3)
who are involved in the development process, acts as quality indicators
reflecting the maturity level of the company. Several process metrics has been
defined and practiced to measure the software deliverables comprising of
requirement analysis through maintenance. Metrics at each stage has its own
significance to increase the quality of the milestones and hence the quality of
end product. This paper highlights the significance of software quality metrics
followed at major phases of software development namely requirement, design and
implementation. This paper thereby aims to bring awareness towards existing
metrics and leads towards enhancement of them in order to reflect continuous
process improvement in the company for their sustainability in the market.
... There are many approaches that follow this idea to propose syntactic measures over different types of conceptual schema diagrams, such as Entity-Relationship 2 Dolors Costal, Xavier Franch Diagrams [3], Business Processes [4], Class Diagrams [5], Activity Diagrams [6], Use Cases [7], Workflow Diagrams [8], and Goal-Oriented Diagrams [9]. These measures present some similarities both at the intra-model level (i.e., several measures over the same type of diagram are defined following the same layout) and at the inter-model level (i.e., measures over different types of diagrams are similar considering an appropriate metaschema correspondence). ...
There are many approaches that propose the use of measures for assessing the quality of conceptual schemas. Many of these measures focus purely on the syntactic aspects of the conceptual schema diagrams, e.g. their size, their shape, etc. Similarities among different measures may be found both at the intra-model level (i.e., several measures over the same type of diagram are defined following the same layout) and at the intermodel level (i.e., measures over different types of diagrams are similar considering an appropriate metaschema correspondence). In this paper we analyse these similarities for a particular family of diagrams used in conceptual modelling, those that can be ultimately seen as a combination of nodes and edges of different types. We propose a unifying measuring framework for this family to facilitate the measure definition process and illustrate its application on a particular type, namely business process diagrams.
... In [4] and [5], sequentially based on interaction diagrams like actor-object sequence diagrams and use case diagrams, the action of estimating software size has been discussed. Also in [6], various parameters have been introduced among in class part for measuring size of software. However, it is nowhere expressed about class diagram efficacy in this fact comprehensively. ...
ne of the subjects related to software engineering is software measurement. Software measurement itself includes different topics that estimating software size is one of them. Various methods have been proposed for estimating software size. Each studies this topic from specific approach. Since UML is a well-known notation for representing object-oriented models, some of the methods are based on it. In this article, through describing class diagram, we consider the efficacy and role of class diagram in estimating software size. KeywordsMeasurement, Software size estimation, UML class diagram, Analysis object model, Static Modeling
... Genero et al. have also developed a set of metrics for measuring the size and structural complexity of state-chart diagrams [10]. Kim and Boldyreff have defined a set of 27 metrics to measure various characteristics of a UML model [16]. However, the metrics are described informally and for some of these measures it is unclear which UML diagrams should be used to calculate the measures. ...
In this position paper we discuss some of the existing work on applying metrics to UML models, present some of our own work in this area, and specify some topics for future research that we regard as important.
... An excellent overview of work on metrics that had been done up to the end of late 1980s appears in [19], including a bibliography (with comments on each cited work) of major works on metrics up to that point. The increasing popularity of object-oriented (OO) programming and XML in the 1990s and 2000s led to new works on metrics, aiming to measure the complexity of representative entities of the OO paradigm, [13], [14], [15] . All the above works deal with measuring the complexity of the endproduct , i.e., the complexity of a program developed in a structured or in an OO programming language, or the complexity of the design of a software artifact developed in UML or XML. ...
Software metrics has been an area of interest in both academy and industry for more than three decades. Emphasis is usually placed on estimating the complexity of software artifacts, including those built using various programming languages as well designs expressed in XML or UML. This work is an attempt to evaluate the complexity of tools used to create the software artifacts rather than to evaluate the complexity of the artifacts themselves. Although the complexity of a software artifact may determine the degree of its usability, and this is clearly important, the usability of the tool that is used to build the artifact is also important - may be even more so. In this vein, using metrics that could typically be used to evaluate complexities of software artifacts, we discuss aspects of some core libraries common to two major platforms,.NET and Java, in terms of ease-of-use and cognitive difficulty that they may pose to the end-programmer. We pinpoint strengths and weaknesses of each library within its platform; we find that none of the two platforms is clearly superior to the other.
