Fig 3 - uploaded by Cornelia Boldyreff
Content may be subject to copyright.
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...
Context in source publication
Context 1
... UML semantics, a message can be an activator of other messages. For example, in Figure 3, the message op1() activates the message op3(), thus its NDM value is 1. 2. Number of the elements in the transitive closure of the directly dispatched mes- sages of a message (NDM * ): For example, N DM * (op1()) = |{op3(), op2()}| = 2. ...
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.
