In Model-Driven Development (MDD) processes, models are key artifacts that are used as input for code generation. Therefore, it is very important to evaluate the quality of these input models in order to obtain high-quality software products. The detection of defects is a promising technique to evaluate software quality, which is emerging as a suitable alternative for MDD processes. The detection of defects in conceptual models is usually manually performed. However, since current MDD standards and technologies allow both the specification of metamodels to represent conceptual models and the implementation of model transformations to automate the generation of final software products, it is possible to automate defect detection from the defined conceptual models. This paper presents a quality model that not only encapsulates defect types that are related to conceptual models but also takes advantage of current standards in order to automate defect detection in MDD environments.
Historically, software production methods and tools have a unique goal:
To evaluate the quality of conceptual models, many proposals have been developed following different perspectives [
To develop an effective quality assurance technique, it is necessary to know what kind of defects may occur in conceptual models related to MDD approaches. Currently, there are some approaches that detect defects in conceptual models (such as [
In this article, we present an approach that allows the automatic verification of the conceptual models used in MDD environments with respect to defect types from the data, process, and interaction perspectives. We present a set of defect types related to data, process, and interaction models as well as a quality model that formalizes the elements involved in the identification of the different defect types proposed. This quality model, which is defined using current metamodeling standards, is the main contribution of this article. It is oriented to represent the abstract syntax of the constructs involved in the conceptual specification of software applications generated in MDD environments. From this quality model, defect detection can be automated by means of OCL [
The remainder of the paper is organized as follows. Section
In the literature, there is no consensus for the definition of the quality of conceptual models. There are several proposals that use different terminologies to refer to the same concepts. There are also many proposals that do not even define what they mean by quality of conceptual models. In order to achieve consensus about the definition of quality and to improve the conceptual models, we have adopted the definition proposed by Moody [
In order to design a quality model, the types of defects that the conceptual models used in MDD environments must be known. Defect detection refers to identifying anomalies in software products in order to correct them to be able to obtain better software products. The IEEE 1044 [
Taking into account that the cost of fault correction increases exponentially over the development life cycle [
Travassos et al. [
Laitenberger et al. [
Conradi et al. [
Gomma and Wijesekera [
Kuzniarz [
Berenbach [
Lange and Chaudron [
Leung and Bolloju [
Bellur and Vallieswaran [
Summarizing, the above proposals present defect types that are related to the consistency (consistency is defined in the IEEE 610 standard as the degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component) [
Defect types of conceptual models in the state of the art.
Quality characteristic | Authors | Model | Defect types |
---|---|---|---|
Consistency among diagrams |
Laitenberger et al. [ | UML Class | (i) A class in the design class diagram is not a class in the system class diagram (with the same name) |
(ii) The number, types, and names of the attributes of a class in the design class diagram are not the same in the class of the system class diagram | |||
(iii) The number, names, and arguments of the methods of a class in the design class diagram are not the same in the class of the system class diagram | |||
(iv) The associations with their cardinality and arity in the design class diagram are not the same in the system class diagram | |||
(v) The constraints between classes of the design class diagram are not the same constraints for these classes in the system class diagram | |||
UML Collaboration | (i) An object that does not correspond to a class of the class diagram | ||
(ii) The collaboration diagram has messages that do not correspond to the system operation | |||
(iii) The messages do not have the same number and type of arguments as the operations of the system described in the Operation model | |||
Operation model of the Fusion method | (i) Operations (read, change, send, and result) that do not have the corresponding message in the collaboration diagram | ||
Gomma and Wijesekera [ | UML Use-case | (i) A use case that does not correspond to at least one scenario described by an interaction diagram | |
COMET state transition | (i) Each Statechart that does not correspond to a state that is dependent on the control class in a class diagram | ||
(ii) The values of the current states, events, actions, and activities that appear on a Statechart that are not declared as attribute values of the respective state, event, action, and activity attributes for the state that is dependent on the control class | |||
(iii) An event on a Statechart that does not correspond to a method of the state of the control class in the class diagram | |||
(iv) Variables used to define conditions in any Statechart that are not attributes of the state that is dependent on the control class in the corresponding class diagram | |||
(v) Each event on a Statechart that corresponds to an incoming message on the state that is dependent on the control object, which is not represented in an interaction diagram (which executes the Statechart) | |||
(vi) Each action on a Statechart that corresponds to an outgoing message on the state that is dependent on the control object, which is not represented in an interaction diagram (which executes the Statechart) | |||
Kuzniarz [ | UML Use-case | (i) The actor that is defined in the use case diagram is not the same actor that takes part in the interaction that is defined in the corresponding sequence diagram | |
(ii) Not all the steps that are defined in the use case description correspond to messages in the system sequence diagram | |||
(iii) There are extension points for the extension of use cases that are missing (not represented) in the diagram of the controller use case | |||
UML Sequence | (i) An iteration symbol that is related to an iterative task is missing in the sequence diagram | ||
(ii) There are links used in sequence diagrams that are not associations in the class diagram | |||
(iii) There are sequences of messages in the sequence diagram that are not acceptable for the controller use case | |||
(iv) There are elements used in pre- and postconditions of the contracts that are not defined in the class model | |||
(vi) There are sequences of messages in the sequence diagram that are not an acceptable subsequence for the state machines that take part in the sequence diagram | |||
Berenbach [ | UML Use-case | (i) Actors in use-case diagrams that are not specified in the context diagram | |
(ii) Use case without an interaction diagram that shows the possible scenarios | |||
UML Class | (i) An interface in the class diagram that is not used to communicate with a concrete use case | ||
(ii) A class that is not instantiated in any process of the system (sequence and collaboration diagrams) | |||
(iii) Methods of the interface class that are not represented in the process of the system (sequence and collaboration diagrams) | |||
(iv) Classes in the class diagram that are not specified in the use-case diagram | |||
(v) Interfaces in the class diagram that are not specified in the use-case diagram | |||
Lange and Chaudron [ | UML Sequence | (i) Messages between unrelated classes | |
UML Class | (i) Classes that are not called in the sequence diagram | ||
(ii) Interfaces that are not called in the sequence diagram | |||
(iii) Methods that are not called in the sequence diagram | |||
Lange and Chaudron [ | UML Use-case | (i) Use cases without sequence diagrams | |
UML Sequence | (i) Objects of the sequence diagram that are not related to a class in the class diagram | ||
Bellur and Vallieswaran [ | UML Use-case | (i) A use case that does not reference a use-case sequence diagram | |
UML Sequence | (i) A variable of a general class used in the sequence diagram that is null or is not a valid class in the class diagram | ||
(ii) A method referenced in the sequence diagram that is null or is not a valid method in the method sequence charts | |||
(iii) An object that is not the sender or the receiver in any interaction | |||
(iv) An object that does not reference a valid class and state diagram | |||
(v) A message that is not an instance of one class method for some class defined in the system | |||
UML State Transition | (i) A state diagram that is not related to one and only one class | ||
(ii) A state that is not described by one or more attributes of the class | |||
(iii) State change events that do not correspond to messages in the method sequence diagrams | |||
UML Component | (i) An intercomponent relationship that does not have 2 terminating end classes which are valid classes in the class diagram | ||
(ii) A component in the component diagram that is not mapped to a physical system described in the deployment diagram | |||
UML Deployment | (i) A deployment diagram that is not related to one or more component diagrams | ||
Correctness | Laitenberger et al. [ | UML Class | (i) The types of the attributes of a class are not specified |
(ii) The methods of a class are not specified | |||
(iii) Parameters that do not have a type associated | |||
Berenbach [ | UML Use-case | (i) Multiple entry point for the system in the use-case diagram | |
(ii) Diagrams without a description and status | |||
(iii) Concrete use cases without a definition | |||
(iv) Abstract use cases that are not realized by a concrete use-case | |||
(v) Extends use-case relationship that is specified between use cases that are not concrete | |||
(vi) A concrete use case that includes an abstract use case | |||
UML Business | (i) Services of business objects that do not have defined pre- and postconditions | ||
UML Class | (i) An interface class with private methods | ||
Lange and Chaudron [ | UML Sequence | (i) Objects without a name | |
(ii) Abstract classes in sequence diagrams | |||
(iii) Messages without a name | |||
(iv) Messages without a method | |||
UML Class | (i) Classes without methods | ||
(ii) Interfaces without methods | |||
(iii) Classes with public attributes | |||
Leung and Bolloju [ | UML Class | (i) Missing association label or cardinality detail | |
(ii) Improper label for a class, an association, an attribute, or an operation | |||
(iii) Improper notation for an association, an aggregation, or a generalization | |||
(iv) The nonimplicit operations that are present in sequence diagram are not included | |||
(v) Implicit operation is listed | |||
(vi) Wrong association cardinality (reversed or wrong range) | |||
(vii) Wrong location of an attribute or an operation | |||
(viii) Wrong association grouping | |||
(ix) Missing class, attribute, operation, or association | |||
(x) Incomplete class description | |||
(xi) Operation that cannot be realized (using attributes and relationships) | |||
(xii) Does not use domain-specific terminology | |||
(xiii) Poor layout of the class diagram | |||
(xiv) Insufficient distinction among sub-classes | |||
(xv) Operation naming is improper or ambiguous | |||
(xvi) Associations are replicated at sub-classes | |||
(xvii) Manual operation is represented as association | |||
(xviii) Excessive use of generalization, PK concept, FK concept, or emphasis on statistical information | |||
(xix) Redundant attributes | |||
(xx) Redundant associations | |||
(xxi) Implementation detail is present in the diagram | |||
Lange and Chaudron [ | UML Sequence | (i) Message in wrong direction in the sequence diagram | |
UML Class | (i) Multiple definitions of classes with equal names | ||
Bellur and Vallieswaran [ | UML Use-case | (i) An actor that does not use one or more use cases | |
(ii) A use case that is not used by one or more actors | |||
(iii) A use case that does not belong to system | |||
UML Sequence | (i) A message that does not have a sender and a receiver object | ||
(ii) A message that does not conform to the signature of the method corresponding to the message | |||
UML Class | (i) A class diagram without classes | ||
(ii) An association without a source and target class | |||
(iii) A class that does not have at least one attribute or method | |||
UML State Transition | (i) A state diagram without one start state and one end state | ||
(ii) A state that has overlap of attribute values describing the state | |||
(iii) A state that is not reachable from the start state | |||
(iv) A state that cannot reach the end state | |||
UML Component | (i) A component diagram without components |
In the systematic revision of the state of the art, we noticed that all the proposals for defect detection in conceptual models are focused on UML models. However, it is well known that UML diagrams [
Since MDD proposals select a set of conceptual constructs and aggregate others to specify the conceptual models, it is important to note that a great number of conceptual constructs increase the complexity of the specification of the models and may cause the introduction of more defects into the conceptual models. For this reason, the conceptual constructs of an MDD proposal must be carefully selected so that the number of constructs that allow the complete specification of software applications at the conceptual abstraction level is as low as possible. In the following section, we present a minimal set of the conceptual constructs for an MDD environment.
Model-Driven Development environments generally use Domain-Specific Modeling Languages (DSMLs), which define the set of conceptual constructs in order to represent the semantics of a particular domain in a precise way [
The MDD methods use models at different levels of abstraction to automate their transformations to generate software products. Model-Driven Architecture (MDA) is a standard proposed by OMG [
To provide details of the conceptual constructs of MDD proposals for the MIS domain, we have selected a specific MDD environment as reference: the OO-Method approach [
The conceptual model of an MDD proposal must be able to specify the structure, the behavior, and the interaction of the components of an MIS in an abstract way. Therefore, we distinguish three kinds of models that together provide the complete specification of software systems: a structural model, a behavior model, and an interaction model.
The structural model describes the static part of the system and is generally represented by means of a class model. A class describes a set of objects that share the same specifications of characteristics, constraints, and semantics. A class can have attributes, integrity constraints, services, and relationships with other classes.
The attributes of a class represent characteristics of this class. The attributes of a class can also be derived attributes, which obtain their value from the values of other attributes or constants. The integrity constraints are expressions of a semantic condition that must be preserved in every valid state of an object.
The services of a class are basic components that are associated with the specification of the behavior of a class. The services can be events, transactions, or operations. The events are indivisible atomic services that can assign a value to an attribute. The transactions are a sequence of events or other transactions that have two ways to end the execution: either all involved services are correctly executed or none of the services are executed. The operations are a sequence of events, transactions, or other operations, which are executed sequentially independently of whether or not the involved services have been executed correctly. The services can have preconditions that limit their execution because the preconditions are conditions that must be true for the execution of a service.
The relationships between classes in the structural model can be the following: agent, association, aggregation, composition, and specialization. Agents are relationships that indicate the classes that can access specific attributes or services of other classes of the model. Agents are specifically defined in the reference MDD approach.
The behavior model describes the dynamic part of a system. These dynamics include the behavior of each class and the interaction among the objects of the system. For the specification of the behavior of a system, we select the functional model of the reference MDD approach, which defines the behavior of the services defined inside the classes of the structural model.
The functional model specifies a formula with the sequence of events, transactions, or operations that must be executed when a service is used. This formula must be specified by means of well-formed, first-order logic formulae that are defined using the OASIS language [
The functional model specifies the effects that the execution of an event has over the value of the attributes of the class that owns the event. To do this, the functional model uses valuations to assign values to the corresponding attributes. The effect of a valuation is also specified using formulae within the syntax of the OASIS language. The change that a valuation produces in the value of an attribute is classified into three different categories:
Since services can have preconditions, the conditions and the error messages of the preconditions are also specified using OASIS formulae. The integrity constraints of a class are also specified using OASIS formulae.
The interaction model describes the presentation (static aspects of a user interface like widgets, layout, contents, etc.) and the dialogs (dynamic aspects of a user interface like controls, dynamic page change, etc.) of the system [
The interaction model allows the specification of the graphical user interface of an application in an abstract way [
Based on the menu-like view provided by the first level, the second level allows the specification of the interaction units of the system. The interaction units are groups of functionality that allow the users of the application to interact with the system. Thus, the interaction units of the interaction model represent entry-points for the application. These units can be the following. A A An A
The third level of the interaction model allows the specification of the auxiliary patterns that characterize lower level details about the behavior of the interaction units. These auxiliary patterns are the following. The The The The The The The The
Each auxiliary pattern has its own scope that states the context in which it can be applied. With these conceptual constructs we can completely specify applications that correspond to the MIS domain in an abstract way. To formalize the concepts and the relationships among them, we present a generic metamodel for MDD proposals.
The quality model proposed in this article is specified by means of the modeling facilities that current metamodeling standards provide, specifically, the EMOF specification [
In general terms, a metamodel is the artifact used to specify the abstract syntax of a modeling language: the structural definition of the involved conceptual constructs with their properties, the definition of relationships among the different constructs, and the definition of a set of rules to control the interaction among the different constructs specified [
With EMOF, the quality metamodel can specify the constructs involved in the different types of defects as well as the properties that must be present in the different conceptual constructs for the detection of defects. The OCL language used for the metamodeling rules can be used to define specific rules to automate defect detection. The final quality model is comprised of two main elements: (1) a metamodel for the description of the conceptual constructs that are used in MDD environments (which includes all the properties involved in defect detection) and (2) a set of OCL rules that allows the automatic detection of defects according to the list of defects presented in this article.
Figure
A metamodel for defect detection in MDD-oriented conceptual models.
The derived attributes, services, preconditions, and integrity constraints require the specification of the functionality that they perform. This functionality is specified by means of the behaviour model. The behaviour model has elements (class
The interaction model has a set of interaction units (class
Since the quality metamodel has been specified using the standards of metamodelling, this metamodel eliminates redundancy of the elements defined and can be implemented using open-source modeling tools.
Before the specification of the OCL rules, the types of defects that the conceptual models used in MDD environments must be known. To do this, we use a Functional Size Measurement (FSM) procedure designed for the OO-Method MDD approach, which is called OOmCFP [
The OOmCFP procedure is structured using three phases: the strategy phase, the mapping phase, and the measurement phase. The strategy phase addresses the four key parameters of software functional size measurement that must be considered before actually starting to measure: purpose of the measurement, scope of the measurement, identification of functional users, and level of granularity that should be measured. The mapping phase presents the rules to identify the functional processes, data groups, and data attributes in the software specification (i.e., in the conceptual model) depending on the parameters defined in the strategy phase. The measurement phase presents the rules to identify and measure the data movements that occur between the functional users and the functional processes.
OOmCFP starts with the definition of the strategy to perform the measurement. The
Once the scope of the measurement has been determined, it is important to identify the
Layers, pieces of software, and functional users of the OO-Method applications.
Since the
Once the strategy is defined, OOmCFP starts a mapping phase. A
In the measuring phase, the data movements correspond to the movements of data groups between the users and the functional processes. Each functional process has two or more data movements. Each data movement moves a single data group. A data movement can be an
Data movements between the users and layers of an OO-Method application.
Since the OOmCFP procedure has been designed to obtain accurate measures of the applications that are generated from the OO-Method conceptual model [
In order to determine the defect types of MDD conceptual models, the proposed metamodel and procedure were applied to three case studies with conceptual models of different functional sizes: a Publishing application (a small model), a Photography Agency application (a medium model), and an Expense Report application (a large model). We identified 39 defects and grouped them into 24 defect types (see [
Defect types of conceptual models found using OOmCFP.
Defect types found using OOmCFP |
---|
Defect: An object model without a specification of an agent class |
Defect: An OO-Method Conceptual Model without a definition of the presentation model |
Defect: A presentation model without the specification of one or more interaction units |
Defect: An object model without the specifications of one or more classes |
Defect: A class without a name |
Defect: Classes with a repeated name |
Defect: A class without the definition of one or more attributes |
Defect: A class with attributes with repeated names |
Defect: An instance interaction unit without a display pattern |
Defect: A population interaction unit without a display pattern |
Defect: A display pattern without attributes |
Defect: Derived attributes without a derivation formula |
Defect: A filer without a filter formula |
Defect: An event of a class of the object diagram without valuations (excluding creation or destruction events) |
Defect: A class without a creation event |
Defect: Transactions without a specification of a sequence of services (service formula) |
Defect: Operations without a specification of a sequence of services (service formula) |
Defect: A service without arguments |
Defect: A service with arguments with repeated names |
Defect: A precondition without the specification of the precondition formula |
Defect: A precondition without an error message |
Defect: An integrity constraint without the specification of the integrity formula |
Defect: An integrity constraint without an error message |
These defect types correspond to those related to structural models and those related to interaction models. This is one interesting contribution of our measurement procedure since, to our knowledge, there are no reported findings of defect types related to interaction models in the published literature. In order to formalize defect detection in the metamodel presented in Figure
23 Defect types of conceptual models found using OOmCFP and OCL rules.
Defect types found using OOmCFP | OCL rules |
---|---|
Defect: An object model without a specification of an agent class | |
Defect: An OO-Method Conceptual Model without a definition of the presentation model | |
Defect: A presentation model without the specification of one or more interaction units | |
Defect: An object model without the specifications of one or more classes | |
Defect: A class without a name | |
Defect: Classes with a repeated name | |
Defect: A class without the definition of one or more attributes | |
Defect: A class with attributes with repeated names | |
Defect: An instance interaction unit without a display pattern | |
Defect: A population interaction unit without a display pattern | |
Defect: A display pattern without attributes | |
Defect: Derived attributes without a derivation formula | |
Defect: A filter without a filter formula | |
Defect: An event of a class of the object diagram without valuations (excluding creation or destruction events) | |
Defect: A class without a creation event | |
Defect: Transactions without a specification of a sequence of services (service formula) | |
Defect: Operations without a specification of a sequence of services (service formula) | |
Defect: A service without arguments | |
Defect: A service with arguments with repeated names | |
Defect: A precondition without the specification of the precondition formula | |
Defect: A precondition without an error message | |
Defect: An integrity constraint without the specification of the integrity formula | |
Defect: An integrity constraint without an error message |
In order to identify the maximum number of defects using the quality model, we aggregated the defect types already found in the literature (see Table
5 Defect types of conceptual models found in the literature and OCL rules.
Defects types found in the literature | OCL rules |
---|---|
Defect: An attribute of a class without the specification of the type | |
Defect: An argument of a service without the specification of the type | |
Defect: Associations replicated at sub-classes | |
Defect: Associations with a repeated name | |
Defect: An association without a source and target class |
In the three case studies mentioned above, the conceptual models did not achieve the characteristics of consistency and correctness due to the defect types presented in our approach. The OCL rules presented in Tables
In this paper, we have presented a quality model to evaluate the conceptual models used in MDD environments to generate final applications through well-defined model transformations. The quality model is comprised of the following: (1) a metamodel that contains a minimal set of conceptual constructs, their properties, and their relationships, which allows the complete specification of applications in the conceptual model of an MDD environment; and (2) a set of rules for the detection of defects in the model, which have been specified using OCL constraints [
The design of the metamodel has been systematically performed using an MDD approach as reference. This approach, which is known as OO-Method, has been successfully applied in the software industry. However, it is important to note that even though some elements of the metamodel are specific to the OO-Method MDD approach, equivalent modeling constructs can be found in other object-oriented MDD methods. Thus, this metamodel can be used as a reference to improve existent MDD approaches or as a starting point for the specification of new MDD-oriented modeling languages. Moreover, the main modeling constructs that compose the metamodel are the same constructs present in the UML specification. For this reason, the quality model presented here can be applied to other MDD methods that use UML-like models.
We take advantage of modeling, metamodeling, and transformation techniques to avoid having to manually identify defects in the conceptual models, which is an error-prone activity. Thus, the quality model (metamodel + OCL rules) has been designed for easy application to other MDD proposals. This is feasible because the EMOF standard is used to define the metamodel, which is supported by existent open-source tools [
For future works, we plan to apply the quality model into different MDD approaches by using an integration process that automatically generates metamodeling extensions [
This work has been developed with the support of MEC under the project SESAMO TIN2007-62894 and GVA ORCA PROMETEO/2009/015.