More Than Two Decades of Research on Verification of UML Class Models: A Systematic Literature Review

Error checking is easy and inexpensive in the initial stages as compared to later stages due to when the development cycle precedes the development cost and efforts also increase. UML class model is a key element of modern software methodologies and creates in the initial stage of software development. Therefore, error detection and rectification of the UML class model may save software development costs and time. This paper presents an overview of UML Class model verification approaches and identifies open issues, current research trends, and other improvement areas. This study uses a systematic literature review as an investigation method with six research questions and assesses 65 papers dated January 1997 to December 2020. From 2124 published research papers, 65 papers are selected and distributed into 7 studies. This work provides an analysis of verification approaches and the automation level of proposed approaches. As a result, it is found that the existing UML class model verification methods provide great efforts to check correctness. However, in some situations (when dealing with large and complex models), they consume a significant amount of time and do not support many important features of the UML class model.


I. INTRODUCTION
Model Derive Engineering (MDE) is a software development methodology where the software model is considered the nucleus of software development activities. In the MDE, software specifications are stated through abstract models. These models are initially built platform-neutral and are known as Platform Independent Model (PIM) [1]. Then PIM models are gradually refined and transformed into the Platform Specific Model (PSM). Finally, the programming code is generated (semi)automatically by the PSM models [1]. MDE approach saves time and cost, and the industry extensively adopts it. However, the MDE approach has some limitations, such as the PIM model is developed in the preliminary phases of software development. In the early stages, the development team is not fully aware of the system and its constraints. Therefore, there is a possibility that a PIM model will be built with errors, and these errors will be move implicitly into the PSM model and code. Model verification is a promising solution to the problem.
Model verification makes sure the model is bug-free. Mainly, it checks the model's correctness and ensures that the model under consideration is consistent and satisfactory. Unified Modeling Language (UML) is an industry adopted graphical modeling language, and it is recurrently used in MDE [2] [3]. It has many models for dealing with different aspects of software [4] [5]. The class model is an essential part of UML and performs a key role in software analysis and design [6]. UML only provides graphical elements for designing models without reasoning support due to a lack of formal foundation [7] [8]. Therefore, many researchers have used various formal/semi-formal approaches to verify the UML class model, such as Z Notation, B method, Alloy, CSP. This paper reviews many research articles on UML class model verification to evaluate the progress and direct future research on this MDE problem. In [9], authors performed a systematic study on verification of conceptual models in which they also discussed verification of UML class model verification. However, the study presented in [9] differs from VOLUME 4, 2016 this study in the following directions: • The study presented in [9] focuses on verification of almost all conceptual models, including the Entity Relationship Diagram (ERD) model, domain-specific model, and UML class model. The presented study only focuses on the UML class model. • In [9], authors also reviewed UML class model validation methods such as the USE method. In this study, the presented work only considered verification approaches. • Authors of [9] also reviewed approaches that only support transformation and verification of OCL without a class model such as OCLtoFOL. The presented study only focuses on verification approaches that performed formalization of OCL constraints with a class model. • They reviewed from 2002 to 2014. due to this range, authors of [9] missed initial works such as Z and Bbased approaches, which provide a foundation for modern verification methods. The presented study reviewed the period from 1997 to 2020, covering a suitable range of papers that include both foundation and up-to-date verification approaches.
The rest of the paper is structured as follows. Section II presents methodology for the conducted Systematic Literature Review (SLR). Section III shows the results obtained from SLR . Discussions are explored in Section IV. Finally, Section VI provides the conclusions.

II. METHODOLOGY
This section discusses the applied methodology for the conducted SLR. The following sections, describe the process to be followed during this work, followed by stating the Research Questions (RQs), strategy regarding search and selection, then defining inclusion and exclusion criteria, and finally specified the method to follow for data extraction.

A. PROCESS
The procedure of the systematic literature review was developed according to the guidelines specified by Kitchenham and Charters. SLR has three key stages; planning, execution, and reporting [10]. 1 Planning Stage: Reporting phase: Systematic discussion and present the outcomes.

B. RESEARCH QUESTIONS
The presented work provides a comprehensive survey and analysis of formal and semi-formal verification methods. More significantly, focus on the following research questions: RQ1: What are the importance of UML and UML class model in modeling and MDE? RQ2: What methods or techniques have been adopted for verification of the UML class model? RQ3: Is the verification approach is based on a metamodel? RQ4: Which model defects have been undertaken in each method, and which defect has been examined in most cases? RQ5: Is an automatic or semi-automatic tool developed for the verification method, and what are their strengths and limitations?
RQ1 Is designed to describe UML and UML class model role in the model-driven engineering and software industry. The expected outcome will be a comprehensive view about the use of UML and UML class models in the industry. The RQ2 is formulated to identify different formal and semiformal methods that have been used in the verification of the UML class model. RQ3 is specially designed to find the answer that current verification methods still support the metamodel's formalization. RQ4 is designed to determine the state-of-the-art of research on different correctness properties which are verified in different methods. RQ5 is formulated to examine that the proposed approaches practically demonstrated through the software. It also helps us to identifies the limitations and strengths of the method on which the tool is based.

C. SEARCH AND SELECTION STRATEGY
This is the most critical and most important stage of SLR. It must be specified very carefully as the search for studies should ensure complete coverage of the subject under consideration. The search strategy developed in this work has 4 stages. (1) Automatically searched on the most relevant scientific digital libraries. (2) removed all duplicate studies (3) ensuing pre-set criteria of inclusion, only related studies were considered. (4) more papers were explored by snowballing. Figure 1 shows the search and selection strategy employed in this work.

1) Stage 1: Performing Automatic Search
To obtain as many related studies as possible, an automatic search was performed on the scientific digital libraries (list of scientific libraries shown in Table 1). These scientific libraries have a massive amount of software engineering publications PICOC (Population, Intervention, Comparison, Outcome, Context) criteria [10] were employed to specify Population "UML class model" OR "UML class diagram" OR "UML Model" OR "UML/OCL" Intervention "verification" OR "consistency" OR "analysis" OR "reasoning" OR "satisfiability" OR "corrections" OR "checking" OR "unsatisfiable" OR "formalisation" Comparison Not Applicable Outcome Report on the current state-of-the-art method, technique, tools and challenges of UML class model verification Context Peer-reviewed publications The overall search string is as follows: 1) (("verification" OR "consistency" OR "analysis" OR "reasoning" OR "satisfiability" OR "corrections" OR "checking" OR "unsatisfiable" OR "formalization")) AND (("UML class model") OR ("UML class diagram") OR ("UML Model") OR ("UML/OCL")) 2) Scientific Digital libraries have different syntax, a specialized search string for each digital library was created. This is to make sure to include as appropriate studies as possible.

2) Stage 2: Removing duplicate studies
Initially, Mendeley's reference manager was used to a kept a pool of primary studies. This repository has also helped the process of finding duplicate papers. Two or more papers are treated duplicate if and only if: 1) Study title, date of publications, location, and authors are the same. The most recent paper is kept when different versions of the same paper were found. 2) In case of paper is published in a different location, one of them is selected (the most recent). 3) In the case of a study published in a journal and conference, the journal publication is counted because the journal publication comprises the extended study and provides more information.

3) Stage 3: Selecting studies
In this stage, on the inclusion and exclusion criteria, primary studies are selected. Only those studies are included which matching the criteria. The criteria were implemented by reading the article title, abstract/summary, keywords, and introduction sections. However, if this is not adequate to reach an absolute decision, other sections such as methodology and conclusion are considered. The search strings specified in the previous section were very wide and returned papers that are not directly related to the goal of the systematic literature review. After collecting 2124 papers, the pruning stage was started, which kept out unrelated studies.
In the title pruning stage, papers title and keywords were read. After carefully read, 40 papers were excluded because they were focusing on the verification of other UML models. The remaining 82 papers were finalized for further analysis. In the last, the abstracts of the remaining papers were read, and 48 papers were excluded because they were focused on inter-model consistency. In the end, only 37 articles were selected that were directly related to the purpose of this review. The list of papers is given in Table 3. This list was complemented with papers that are found after the snowballing process.

4) Stage 4: Snowballing
To ensure not miss potential studies, articles that could not be automatically searched or published in the issues of scientific digital libraries were also searched. The snowballing process is done by discovering citing of the primary studies. Google Scholar is used to discover those articles. Subsequently, newly discovered and selected articles are included to the pool.
In the snowballing process, references of all selected papers were carefully read. After applying inclusion and exclusion criteria mentioned in section 4 and pruning stages, 24 more papers added to the study, as listed in Table 4. Finally, after the pruning and snowballing stages total of 61 papers were selected for the study. The year-wise distribution of selected papers is shown in Figure 2.
This work includes related work published from January 1997 to December 2020 to answer the above research questions. 61 research papers were analyzed and combined into 7 studies, as shown in Table 5. These studies are further divided into sub-studies that indicate similar approaches by different authors. However, the final study is not further divided because it is a combination of controversial confirmation approaches. In this SLR, most of the papers are part of a single research project.

D. INCLUSION AND EXCLUSION CRITERIA
In the systematic literature review, some criterion is defined for incorporating only related research works. The inclusion criteria focus only on the verification of the UML class model with or without OCL. The exclusion criteria also defined, such as inter-model consistency and the UML class model VOLUME 4, 2016  Reasoning about UML/OCL class diagrams using constraint logic programming and formula 2019 FIGURE 2: Paper included in the review year-wise distribution validation did not consider. This study only considers work published after 1996 in English. Table 6 is showing the inclusion and exclusion criteria.

E. IDENTIFICATION OF PAPERS
This review includes papers published between January 1997 and December 2020. The paper searching process was completed in December 2020. Therefore, papers published over the time period as a result of the publication time lags. The search strategy mainly consists of the following: 1) The first strategy was based on research repositories: ACM Digital Library, IEEE Explore, Science Direct, Springer Link, Google Scholar, and Microsoft Academic Search. These libraries have a massive amount of software engineering publications, and the following search strings were used (("verification" OR "consistency" OR "analysis" OR "reasoning" OR "satisfiability" OR "corrections" OR "checking" OR "unsatisfiable" OR "formalisation")) AND (("UML class model") OR ("UML class diagram") OR ("UML Model") OR ("UML/OCL")). 2) In the last, references of crucial papers were searched manually.

F. STUDY SELECTION
The study (papers) selection phases mainly focus on identifying papers related to the systematic literature review's goal. The search strings specified in the previous section were very wide and returned papers that are not directly related to the systematic literature review's goal. After collecting 125 papers, the pruning stage was started, which kept out unrelated studies.
In the title pruning stage, the title of papers and keywords were read. After carefully read, 41 papers were excluded because they focused on the verification of other UML models. The remaining 84 papers were finalized for further analysis. In the last, the abstracts of the remaining papers were read, and 47 papers were excluded because they were focused on inter-model consistency. In the end, only 37 VOLUME 4, 2016 articles were selected that were directly related to the purpose of this review. The list of papers is given in Table 3. This list was complemented with papers that are found after the snowballing process. Figure 3 gives a distribution of paper according to the source, which shows that most of the included papers have been published in high esteem journals and conferences such as Elsevier, Springer, IEEE, and ACM.

H. DATA EXTRACTION AND SYNTHESIS
This phase extracted related information from each research work. For this purpose, an Excel sheet was prepared, which was used for storing essential information. Mainly, information about each work was recorded in two groups in the following way. As shown in Table 7, general information about each work was collected in the first group, such as title, author name, published year, no of citation. As shown in Table 8, the second group collected the information directly corresponding to the research questions, such as the importance of UML and class model, the name of verification method, and transformation level.

A. RQ1-WHAT ARE THE IMPORTANCE OF UML AND UML CLASS MODEL IN MODELING AND MDE?
More or less, all studies (S1 to S7) reported that the UML is an industry adapted visual modeling language. It hides the complexity of the system and provides an appropriate level of abstraction [59]. It is used in the software industry for software specification, analysis, design, documentation, and nowadays, it is also used for code generation [44]. UML has various models that deal with various aspects of software modeling [4] [5]. It uses simple diagrammatic notations for describing software [7]. It is currently also used in engineering, ontology, DBMS, and other areas [32].  [32], and it is widely used in the industry [27]. It describes the system through concepts, their relationship, and constraint [6]. It is also a key ingredient of the MDE process [6] [47] [49].

1) Z Notation
The first study uses the Z notation for formalization and verification of the UML class model. This study is divided into 2 sub-studies (SS1.1 and SS1.2). The SS1.1 compiles the work of Evans et al. [11]- [14], and SS1.2 collects the work of Kim et al. [15] [16]. In SS1.1, the authors used Z notation to provide the formal foundation of the UML core metamodel. They argued that the formal foundation provides various benefits such as clarity, consistency checking, refinement, and proof [12,13]. They represented the UML core metamodel (also a class model) through a compositional schema that contains several subschemes. The sub-schemes formalize UML model elements such as type, instance, values, operation, associations, etc. The authors also describe three ways to formalize the UML model: They also describe following three ways to formalize UML model: 1) Supplemented: In this way, informally defined elements of the UML model are defined formally. 2) OO-Extended: In this approach, the existing formal method is extended with object-oriented concepts such as Object-Z. 3) Method Integration: In this method, the entire UML model is transformed into the formal model.
They also argued that only formal UML analysis is not enough for the discovery of semantic correctness [14]. Moreover, they suggested that industry experts' feedback is also essential for the UML model semantic correctness. They developed a formal reference manual that precisely and formally describes the semantics of UML concepts. The reference manual provides inference rules for analyzing different models properties [14]. In [11], the authors extended their work and proposed a diagrammatic transformation of the UML class model. They further proposed five steps roadmap for model formalization and verification [11]. The roadmap is as follows: 1) A mature formal language must be chosen that should be expressive and well supported by the tools. 2) The abstract syntax of modeling notation (metamodel) should be formalized. 3) Infrastructure parts of modeling notation should be formalized. 4) The meaning function should be defined, which maps the syntax and semantic of the model into the formal notation. 5) Finally, analysis techniques should be developed. In SS1.2, the authors used the object-z for the core UML model's formal specification and provided a sound mechanism for reasoning [15], [16]. They formalized core UML class model constructs in Object-Z, verified inconsistency and errors through the Z proof technique [15]. They formalized associations, generalization, aggregation, composition, and association classes. [67]. They defined the UML class model's hidden semantics through the schema's invariant of the Z machine. For example, domain and range of association must be classes. The public and protected attributes of the class must be included in the child class. In the aggregation relationship, the whole class should be the range, and the part class should be the domain. They also defined abstract syntax of UML (meta-model) in object-z. In [16], they argued that a single formal method could not cover all analysis tasks of UML class model verification because different formal methods have different strengths and limitations.
Consequently, they presented an integrated verification and validation framework where different formalisms are available for different analysis tasks. It is a hybrid technique where an analyst can select appropriate formalism according to the requirement. Mainly, in this approach, a metamodel is automatically transformed from one formal notation to another.
In SS2.1, the authors presented the transformation of UML classes, attributes, and operations into B Machine [8,18]. They also presented the transformation of OCL constraint into the B method. They transformed OCL basic types (integer, float, etc.) into B method basic types and operations such as +, -, etc., into B method basic operations [17]. They used B prover to verify the consistency of UML class model [7]. Further, they integrated all their previous works and proposed the UML class model and metamodel transformation with well-formedness rules in B specification for verification [19]. In this approach, elements of the metamodel's core package are transformed into B abstract machine.
The authors in SS2.2 also used the B method to verify the UML class model [20]. In the approach, the transformation process is done in two stages. Firstly, a core abstract machine (interface) is declared, which describes the complete system structure and the associations. Finally, abstract machines are declared for classes.
In SS3.1, the authors analyzed the UML class model through description logic and verified the model correctness properties, such as redundancies and inconsistencies. They argued that the description logic could adequately deal with the UML class model expressiveness. They mainly verified the UML class model satisfiability and class equivalence [24] [25]. In [26], authors extended their work and performed various reasoning experiments (consistency and satisfiability) on the UML class model through two well-known reasoners, Fact and Racer. They further investigated the computational complexity of UML class model reasoning [21]- [23]. The investigation found that reasoning on the UML class model with minimum supporting features (binary association, minimal multiplicity, and generalization) is ExpTime-hard. They also argued, the reasoning task of checking correctness properties (class subsumption, class equivalence, class consistency) can be mutually reducible into each other.
In SS3.2, the authors proposed bounded verification of constraint generalization set through linear inequalities. They analyzed different generalization types such as tree structure, acyclic structure, and graph structure [32]. In the tree structure generalization, subclasses only inherit from the single superclass. In the acyclic structure generalization, a subclass inherits from multiple superclasses, but an inheritance from a common ancestor is not allowed. In the graph structure generalization, multiple inheritances with different ancestors are allowed. They also proposed two algorithms that reduce the generalization Set (GS) complexity in polynomial time. VOLUME 4, 2016 The first algorithm deals with GS without constraints. The algorithm replaces all GS constructs with binary associations and represents the associations through linear inequalities. The second algorithm supports GS with constraints and does not support disjoint and complete constraint within the cyclic class hierarchy. In [30], the authors proposed another algorithm that supports disjoint and complete constraints over cyclic class hierarchy and introduced a more compact version of linear inequalities. In [31], authors extended their work and added the support of qualifier, association classes in the algorithm. The author also identifies that currently there are no accepted benchmarks for class diagrams for checking the scalability of verification methods. Therefore, they developed a set of metrics for measuring the size and complexity of the class diagram. Furthermore, they also statistically measure the scalability of finiteSat algorithm [68].
They further extended their work and added the support of qualifier, association classes in the algorithm [31].
Moreover, they also introduced a constraints detecting method that detects the causes of unsatisfiability. The extended algorithm replaces the qualifier constraint with associations and a new class. In [29], the authors formalized their approach, which they presented in [31] [32] through description logic, and built a DL formula for the multiplicity constraint. In [27], they further expanded the work and presented methods for eliminating redundancy in wider constraints (Universal and Extensional).
In SS3.3, the authors also used description logic for the formalization of a class model. They transformed many elements of the class, such as attributes (visibility, type multiplicity, etc.), operations (visibility, parameter list, return types), composition, aggregation, and generalization [33].
In SS3.4, the authors proposed an ontology-based method for verification of the UML class model. In [34], they argued that the UML class model and OCL could be formally represented through the Web Ontology Language (OWL). In [35], the authors presented ontology-based algorithms for checking the satisfiability of association cardinality constraints. The proposed algorithms use the ontology graph and ontology constraints to find the optimal solution. In [36], they also transformed xor constraints and dependency relationship into the ontology.
In SS4.1, the authors presented a linear inequality-based method for finite model verification through constraint programming. They represented the UML class model through the Constraint Satisfaction Problem (CSP), and the satisfiability of the UML class model is checked by the ILOG's Solver [4]. Furthermore, two correctness problems of the class model were addressed and encoded into CSP. In the first problem, they verify that all the model's classes are completely satisfied at the same time. In the second problem, they verify a finite non-empty model can be obtained from the class model.
In SS4.2 authors presented a framework for checking the satisfiability of UML class model through CLP. The proposed framework detects the design defects in UML class model annotated with OCL. They used the bounded verification approach and performed the reasoning on finite bounds for the number of instances of the model through model-finding tool Formula. The proposed approach checks the predefined correctness properties such as satisfiability, lack of redundant constraints. Furthermore, it can be used to examine complex models for finding best fit object model for the domain. They also implemented the proposed framework through an eclipse plug in called CD-to-Formula.
In SS4.3, the authors used Constraint Logic Programming (CLP) to verify the UML class model. They transformed the UML class model, metamodel, and meta-meta-model into CLP clauses (fact and rules) [5]. In this approach, meta-metamodel, metamodel, and UML class model concrete elements (which have instances) are transformed into CLP facts, and abstract elements and constraints are transformed into the rules. Additionally, CLP's goals are also declared, which negate the consistency rules. In the end, a unified checker finds the solution to the goal, and if the goals are resolved, then the UML class model considers inconsistent.
In SS4.3, the authors proposed incremental verification of the OCL integrity constraint of the class model. They introduced the term Potential Structure Even (PSE) and argued that checking integrity constraints after every structure event (Insert Entity, Update Attribute, Delete Entity, Specialised Entity, etc.) can be costly [44]. On the other side, The PSEs represent only those events that can violate the constraint. Therefore, PSEs for every integrity constraint are recorded. Moreover, only those instances of entity types and relationship types that are the victim of PSEs are verified. They implemented the proposed approach through CSP and presented a fully automatic, decidable solution for binding the UML class model with OCL [38]. Mainly, classes and associations of the UML class model are transformed into a set of variables, domains, and CSP constraints. If the generated CSP is solvable, the model is considered satisfiable otherwise is considered unsatisfiable. They also reported different class models (CivilStatus, WriterReview, DisjointSubclasses, and ObjectASInteger) as a benchmark along with various analysis questions such as consistency, invariant independence, consequences [41]. They further introduced two more benchmarks, which were not included in the previous work [42]. The proposed benchmarks target different UML class model features and specified various computational challenges for verification tools. In [37], they pointed out bounded verification limitation and argued that an inadequate bound could miss defects in the model due to small search space or maybe inefficient if set too large. In the proposed solution, large initial bounds are set. Then bounds are tightened up as much as possible, and unnecessary value from the bounds is eliminated through the interval constraint propagation technique. This technique further improved in a way that verification bounds are automatically set whenever possible, then bounds are tightened through user assistance and guide the uses regarding bound setting. Furthermore, they proposed techniques for the incremental verification of the UML class and OCL model. The proposed techniques merge the slicing technique (which will be discussed in the next study) and a model as a certificate approach presented in the work. In the certificate approach, the model's instance is considered a certificate of satisfiability [46].

5) Alloy
In the fifth study, a lightweight formal method Alloy has been used to verify the UML class model. This study is mainly divided into two sub-studies (SS5.1 and SS5.2). The SS5.1 compiles the work of Anastasakis et al. [56] [58] [59], and SS5.2 presented the work of Maozi et al. [57].
In SS5.1, the authors transformed the UML class model and UML metamodel into Alloy specification [58]. They reported different challenges faced by authors during transformation [58]. For example, both approaches support inheritance, but in UML, child classes can redefine the parent class's properties and methods. However, Alloy's subsignature does not support this feature (overriding is impossible in the Alloy). In [58], they further discussed challenges such as object identifier, multiple inheritances, and collection constraints in more detail. OCL mapping rules also presented in [56]. According to this work, many OCL operations can be directly mapped into the Alloy's elements and operations. Operations that do not have direct corresponding elements in the Alloy are represented by the combination of other elements.
In SS5.2, the authors claimed that the previous UML verification works through Alloy only support limited features and only analyze the model's consistency [57]. This work mapped advanced features (multiple inheritances, interface) of the class model through a combination of Alloy's basic construct (fact, functions, and predicate). This work also supports various analyses on the class model, such as the intersection and refinement analysis.
In SS6.1, the authors proposed a model slicing technique for solving UML class model verification's scalability problem. In the proposed approach class model is partitioned into sub-models (Slice); each slice only contains elements that have some impact on model verification and constraints that are not trivially satisfiable such as key unique value assignment, drive value constraints, etc. Elements and constraints which apply to the same model elements are combined into the same slice. The correctness of each slice is checked separately, and finally, the verification result of all slices is combined to determine the correctness of the entire model. The slicing process is initiated from the identification of local and global constraints. The local constraints are verified separately because they do not affect more than one instance of the class. Mainly, a dependency graph is used for analyzing the dependency among class elements, and slices are made from connecting components of the dependency graph. The authors also reported that slicing techniques minimize the verification time of a large model with fewer constraints. However, the slicing technique does not work with complex models. In [50], the authors extended the work and provided the support of non-disjoint sub-models (where a class is used in several constraints). They also reported that if a class model has a large number of disjoint sub-models, then minimum slices will be created, and efficacy cannot be gained. The proposed slicing technique has been applied on two verification methods UMLtoCSP and Alloy, and reported improved results [47]. In [6], they introduced the feedback technique for the unsatisfied UML class model. Moreover, they reported a slice could be unsatisfiable due to various reasons, e.g. constraints specified an inconsistent condition. Furthermore, they demonstrated the slicing technique on a real-world case study, "DBLP" [51]. In [52] they extended the work with the support of both disjoint and non-disjoint slicing. Furthermore, they proposed an overall concept of disjoint and non-disjoint slicing techniques that can split UML/OCL class diagrams into several independent submodels to reduce the complexity. Addtionally, the reasons for unsatisfiability is also discussed through feedback technique.
In the study SS6.2, the authors presented model slicing techniques to optimize two class model analysis techniques. The first technique checks conformance between the object model and class model. The latter one verifies the order of operation invocation to discover the invariant violation. In the first task, they verify the consistency between the object model and the invariant specified in the UML class model and verifies whether the object model is a valid instance of the class model. The proposed approach takes two inputs, object model and class model. The second task presented a rigorous slicing technique that works with both OCL invariants and operations contracts.

7) Others
The last study S7, is a combination of heterogeneous approaches. This study is mainly divided into 3 sub-studies (SS7.1, SS7.2, and SS7.3). The SS7.1 compiles the work of Queralt et al. [63] [64] [65], SS7.2 presented the work of Seiter et al. [60]- [62]. SS7.3 focused on the work of Abbas et al [66]. VOLUME 4, 2016 In SS7.1, the authors formalized the UML class model through the first-order logic and used the CQC method for verification [62]. They proposed automatic verification of various correctness properties (class liveliness, satisfiability, and redundancy) of OCL integrity constraint. The proposed technique automatically generated tests that verify the association's cardinalities, disjointness, and generalization constraints. Furthermore, it provides a query box reasoning facility for checking reachability for a particular state [64]. In SS7.2, the authors proposed an algorithm for automatically reducing the UML class model's irrelevant elements. The proposed method only considers relevant elements, which are necessary for verification. It takes the verification task and model as input. An empty model is then initialized, which has only classes without attributes, operations, and invariants. After that, other elements that are related to verification are added for verification. At last, associations are added, which affect verification [62]. In [60] [61], the authors pointed out that current verification techniques only focus on single model verification. They further argued that in Model-Driven Engineering (MDE) abstract model is constructed first, and then subsequent models are built. Focusing on a single model without considering the previous model can sometimes lead to consistency issues between models. It is desirable that the refined model consistent with all preceding models. Finally, they proposed a framework for managing consistency in the verified models.
In SS7.1, the authors presented the UML class model's formal transformation into FoCaLiZe, a proof-based formal approach. It supports various UML class model elements, such as multiple inheritances, dependency, templates, template bindings, and OCL constraints navigation. They convert UML classes in the FoCaLiZe species, properties of classes as a getter function, and OCL constraint as species' properties. Furthermore, in the proposed method, the multiple inheritances are converted into species hierarchy, UML template, template binding, and dependency relationships into species parameters substitution. Species properties that represent OCL constraints converted into FoCaLiZe inheritance and parameterization relationships. They used Zenon for verification [66].

C. RQ3-IS THE VERIFICATION APPROACH IS BASED ON A METAMODEL?
Numerous studies have focused not only on formalizing the UML class model but also on the UML class model meta model partially or completely. In the study [SS1.1], the UML core metamodel was formalized in Z-notation and represented through compositional schemes. In SS1.2, the authors transformed the core UML metamodel in Object-Z meta-Schema. In SS2.1, the authors transformed the UML core metamodel and its well-formedness rules into B abstract machine. They transformed classes, data types, associations, attributes, operations, association ends, and operation parameters of the UML core metamodel into the B method. They also transformed semantic rules of the UML core metamodel into the B method. In SS4.3, the authors transformed the UML class model's metamodel basic elements into the constraint logic program. The metamodel elements such as namespace, class, property, features, named element, and static features were transformed into a CLP meta-fact. In SS5.1, the authors constructed the UML class model's metamodel equivalent metamodel in Alloy. They transformed most UML metamodel constructs into Alloy, such as type, class, package, association, attributes, etc.

D. RQ4-WHICH MODEL DEFECTS HAVE BEEN UNDERTAKEN IN EACH METHOD, AND WHICH DEFECT HAS BEEN EXAMINED IN MOST CASES?
Model validation ensures that the model is error-free and has satisfied correctness features such as satisfactory (strong and weak), consistency, and accuracy such as a class system. The model is considered incorrect when it does not justify any single correctness feature and is considered correct when it meets all the correctness features.
In logic theories, satisfiability means checking the validity of formulas. If the formula is found correct, it is called satisfiable; otherwise, it is called unsatisfiable. Satisfiability is the most crucial correctness property, and it makes sure that a non-empty instance of a model may be created without violation of any constraint. Furthermore, other correctness properties can be covered under it. Some authors also divide satisfiability into two types: weak satisfiability and strong satisfiability. Strong satisfiability checks whether an instances model of the UML class model may be instantiated successfully in which at least one instance of each element successfully populates. Weak satisfiability checks whether at least one or more elements of the model can be instantiated successfully. Class liveliness checks whether a class can be populated successfully. Redundancy of OCL integrity constraint checks the duplication of OCL constraints.
In SS1.1 and SS1.2, the authors verified the UML class model's consistency against the well-formedness rules. In SS1.1, the authors also performed a diagrammatic transformation of the UML class model where one model infer from another through transformation rules. In SS2.1 and SS2.2, the authors checked the consistency of the UML class model against well-formedness rules. They also checked the OCL syntax error, incompatible types of expression, use of the illegal operation. In SS3.1, the authors verified the satisfiability of the UML class model and individual classes. Additionally, they checked class equivalence, class subsumption, and logical consequence.
In SS3.2, the authors verified the finite satisfiability of the unconstrained generalized set, constrained generalized set, and association qualifier of the UML class model. Finite satisfiability (strong satisfiability and weak satisfiability) is checked in SS4.1 and SS4.1. The consistency of the UML class model against the metamodel is verified in SS4.2. In SS4.3, the authors mainly checked finite satisfiability (Weak and Strong Satisfiability) of the UML class model along with OCL constraints. They also verified other correctness fea-tures: lack of constraint subsumptions, strong class liveliness, and constraint redundancies. In SS5.1, the authors checked the satisfiability of the UML class model in conjunction with OCL constraints. In SS5.2, the authors checked the intersection of different class models and refinements. The SS7.1 verified satisfiability, class liveliness, redundancy of OCL integrity constraint, and state reachability. In SS7.2, the authors test the state reachability of the model. Figure  4 shows the correctness properties verified by different substudies. As shown in Figure 4 satisfiability and consistency have been checked in most of the sub-studies. The correctness property "well-formedness" only checked by the initial works, and only two sub-studies verified the UML class model's well-formedness against the metamodel.
In most cases, class liveness and constraints redundancy are verified by the works that focus on satisfiability, and 3 sub-studies have verified these properties. Only 1 sub-study also checked the consequences/state reachability. One substudy checks that the deduced model does not contain any contradiction.

E. RQ5-IS AN AUTOMATIC OR SEMI-AUTOMATIC TOOL DEVELOPED FOR THE VERIFICATION METHOD, AND WHAT ARE THEIR STRENGTHS AND LIMITATIONS?
In SS2.1, the authors reported a prototype tool called Ar-goUML+B based on the ArgoUML platform. This tool takes the UML class model in XMI format and automatically transforms it into the B specification. The authors of SS2.2 also developed a prototype tool called OCL2B, which takes the UML class model and OCL file for analysis. This tool used OCAML higher-order language for mapping transformation rules. In SS3.2, the authors presented a tool called Finite-SatUSE, which uses a FiniteSat algorithm for verification of class model with constraints generalization. In SS4.3 authors presented the tool called UMLtoCSP. It takes the class model in the XMI format and OCL as a separate text file. The model and OCL are transformed into the CSP and then checked by the CSP solver. Metadata Repository API parses the XMI file, and the Dresden OCL Toolkit processes OCL constraints. In SS5.1, the authors presented the tool UML2Alloy, which transformed the UML class model and OCL constraint into the Alloy specification. In SS5.2, the authors developed a plug-in CD2Alloy for ECLIPSE. In CD2Alloy, the transformation rules are specified through FreeMarker templates. It provides the facility of class model editing and analyzing. In SS7.1, the authors developed a Java-based prototype tool called AuRUS for Automated Reasoning on UML/OCL Schemas.

IV. DISCUSSIONS
In modern software development, software design models perform critical roles. They are not only used for documentation but also used for analysis, design, testing, and even for code generation through automatic transformation technique. The transformation technique provides automatic reuse of existing software artifacts. However, it has some problems, such as through the transformation, models' defects are automatically transferred in the transformed model. These defects are difficult to discover and repair. Model verification is a promising solution for the problem.
Verification of the UML class model performs a vital role in ensuring the model quality before the transformation. Verification of the UML class model through formal notation has been discussed in several works. In the existing literature, different facets of UML class model correctness have been discussed by the researchers according to different factors such as static vs. dynamic and inter vs. intra-model [66]. Under the static factor, only the UML class model's structural elements are considered for verification, such as association multiplicities and generalization. In the dynamic category, the behavior part, such as operation, is considered for analysis. In the inter-model verification, consistency between two different models is verified, and in the intra-model verification, consistency and satisfiability of the model against constraints are verified.
Consistency and well-formedness are the most fundamental correctness features [48]. The consistency verifies whether the model elements are consistent with the declaration, whereas well-formedness verifies whether a model is a correct instance of its metamodel [66]. However, wellformedness only verifies the initial level of syntax weaknesses and is not concerned with the model's semantic correctness. Semantic correctness concerns the constraints that are graphically specified in the model, such as associations, dependencies, generalizations, or textually defined through constraint languages OCL.
The most fundamental semantic correctness property of the static model is satisfiability [66]. It checks the possibility of the creation of an instance model without violation of any constraint. Other important correctness properties which are verified and come under the umbrella of satisfiability are strong satisfiability, weak satisfiability, and class liveli- VOLUME 4, 2016 ness [38]. The UML class model provides graphical modeling notation without any formal foundation [7]. The wellformedness rules are specified through metamodel and OCL without any formal proof facility.
Consistency and finite satisfiability are two major correctness features of the UML class model, and both guarantee a non-empty and finite instance model. The consistency focuses on non-emptiness, and finite satisfiability focuses on finiteness [71]. Contradicting constraints such as creating a subclass of two disjoint classes can cause an emptiness, and little mistake in association multiplicity constraints specification can cause non-finiteness. A class model is considered consistent if it has legitimate non-empty instances of all classes (maybe infinite) and finitely satisfiable if it has one legitimate finite instance where all classes are non-empty [71]. Hence, finding a single legitimate instance of the class model is adequate to guarantee consistency in which all classes are non-empty. Therefore, finite satisfiability can cover consistency [71]. Many other correctness properties such as class liveliness, constraint redundancy, and subsumption can be verified under satisfiability [66]. However, another important aspect of model verification is consequences, which infer new properties from the existing properties [41]. Current UML class model verification methods efficiently verify the correctness of the model. However, in some cases, their performance goes down mostly when they deal with the large and complex model or consume a lot of computational resources (CPU, Memory). Furthermore, they do not support some essential elements of the UML class model. The major limitations of each verification method regarding the UML class model's supporting features are shown in Table 9. The majority of the methods support association, aggregation, and generalization relationships and do not support the xor constraint, dependency relationships, and stereotypes.
Another analysis is presented in Table 9 based on 7 studies, which describes some verification methods' efficiency. As shown in Table 10, current methods work well on a small model with few constraints, such as the performance of UMLtoCSP goes down when it performs verification on the large and complex model. Table 10 also depicts the execution time of UML2Alloy, which depends upon the scope, and its efficiency goes down when deals with a larger scope. Additionally, some improvement can be achieved by the slicing techniques on both approaches. However, UOST also has some limitations, such as it does not work with the complex (constraints rich) UML class model. Approximately all existing verification methods supported their method through prototype tools. Table 11 shows the availability of the tools on the internet. Therefore, there are two open issues. First, some important UML class model elements have not been supported by existing verification methods, such as xor associations, dependency relationships, and stereotypes. Second, there is a need for an optimized technique that reduces the verification time.

V. THREAD TO VALIDITY
It is very important for every SLR to identify all relevant studies. To deal with this threat, the research protocol was formed and validated rigorously to reduce the risk of eliminating relevant studies. The Searching terms were designed in a way that only a trivial number of relevant studies could be missed, and very few irrelevant studies could be included. Manual search and snowballing were also performed besides the automatic search. The protocol was carefully designed to be reusable by others for reproducing the same study. This review has a few limitations. Like all reviews, it was limited by the search conditions used, the journals and conferences included, and the time period. However, the research works presented in this literature review provide a snapshot of UML class model verification methods. This review excluded non-English papers. Although many aspects of UML class model verification are discussed here, there may be other important aspects in model verification. The review studies are coded with respect to their strengths and weaknesses, although the verification methods' challenges during transformation and verification have not been discussed.

VI. CONCLUSIONS
This study is based on a systematic review of UML class model verification literature with and without OCL constraints. This work identifies numerous challenges the researcher faces during the model transformation process and presents potential strategies to tackle these challenges. This work presents the findings in two phases: The first phase provides quantitative information on the number of works published each year since 1996, the type of methods reported in reviewed work, and the reported studies' contextual factor. In the second phase, studies are analyzed and extracted data interpreted to answer research questions.
Our findings suggest that existing UML class model verification methods provide great efforts in verifying the UML class model. However, there are some limitations. Firstly, almost all works only focus on core UML class elements such as classes, binary associations, generalization, and aggregation. They do not focus on the other elements such as xor constraint over the associations, dependency relationships, and qualified associations, n-ary associations, and stereotypes. Most of the initial studies only focus on the UML class model's well-formedness due to the unavailability of a formal foundation in UML. Modern studies mainly work on consistency and satisfiability. Some other correctness properties such as class liveliness, constraint redundancy, and subsumption have also been verified in different research studies. However, less attention has been paid to them than consistency and satisfaction.