Management of Correctness Problems in UML Class Diagrams Towards a Pattern-Based Approach

Management of Correctness Problems in UML Class Diagrams Towards a Pattern-Based Approach

Mira Balaban, Azzam Maraee, Arnon Sturm
Copyright: © 2010 |Pages: 24
DOI: 10.4018/jismd.2010100102
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

UML is now widely accepted as the standard modeling language for software construction. The Class Diagram is its core view, having well formed semantics and providing the backbone for any modeling effort. Class diagrams are widely used for purposes such as software specification, database and ontology engineering, meta-modeling, and model transformation. The central role played by class diagrams emphasizes the need for strengthening UML modeling tools with features such as recognition of erroneous models and the detection of errors’ sources. Correctness of UML class diagrams refers to the capability of a diagram to denote a finite but not empty reality. This is a natural, unquestionable requirement. Nevertheless, incorrect diagrams are often designed, due to the interaction of contradicting constraints and the limitations of current tools. In this paper, the authors clarify the notion of class diagram correctness, discuss various approaches for detecting correctness problems, and propose a pattern-based approach for identifying situations in which correctness problems occur, and for providing explanations and repair advices.
Article Preview
Top

Introduction

The Unified Modeling Language (UML) is the de facto standard for system development, as it was developed and adopted by the Object Management Group (OMG-UML, 2009). It consists of several diagrammatic languages, each describing a different view of object-oriented software; a system model consists of a collection of such diagrams. The most important view of UML is the static/structural specification which describes a structural abstraction of the real world. This view is expressed by class diagrams, which consist of classes and their descriptors, associations among them, and constraints imposed on both classes and associations. Among the nine visual UML models, class diagrams appear to be the most clear, intuitive and well defined.

Dobing and Parsons (2006 ) found that the Class Diagram view is the most frequently used (73%) in their examination of the usage of UML. It was found to be useful in clarifying technical understanding, and for maintaining software documentation. The major usage of UML class diagrams is to specify, visualize, and document systems’ static view. They also serve as a basis for generating implementation artifacts such as code skeleton (Martin, 2006) and database schemata (Blaha et al., 1994), as a means for knowledge representation such as specifying ontologies (Cranefield, 2001; Falkovych et al., 2003; Gasevic et al., 2004; Kabilan & Johannesson, 2004; Kogut, 2002; Timm & Gannod, 2005), and for defining meta-models of other programming, modeling, and specification languages.

Class diagrams are models written by people, and therefore, usually suffer from modeling problems like inconsistency, redundancy, and abstraction errors. Inexperienced designers tend to create erroneous models, but even experienced ones cannot anticipate the implication of a change on an overall model (Sunye et al., 2001). Indeed, Lange et al. (2006) show that model defects often remain undetected, even if practitioners check the model attentively. These problems are empowered when a model originates from different resources. Combined sources are usually overlapping, and the integration yields redundant inconsistent models (Ackermann & Turowski, 2006; Huzar et al., 2004). It is a common belief that such problems can best be solved at the level of models (Jackson & Rinard, 2004).

In view of the wide spread usage of UML class diagrams and the difficulties of producing high quality models, it is essential to equip UML CASE tools with reasoning capabilities for identifying problems within models (Berardi et al., 2005; Cadoli et al., 2004; Hartman, 2001; Jackson & Rinard, 2004). These capabilities can help in detecting design problems, identifying the reasons for these errors, suggesting possible solutions, and providing advice for design improvements (Unhelkar, 2005). The quality of models is especially important for the emerging Model Driven Engineering (MDE) approach, in which software is developed by repeated transformations of models (Stahl et al., 2006).

Complete Article List

Search this Journal:
Reset
Volume 15: 1 Issue (2024)
Volume 14: 1 Issue (2023)
Volume 13: 8 Issues (2022): 7 Released, 1 Forthcoming
Volume 12: 4 Issues (2021)
Volume 11: 4 Issues (2020)
Volume 10: 4 Issues (2019)
Volume 9: 4 Issues (2018)
Volume 8: 4 Issues (2017)
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing