Reasoning with UML Class Diagrams: Relevance, Problems ...mira/CDReasoning-07.pdf · Reasoning with...
Transcript of Reasoning with UML Class Diagrams: Relevance, Problems ...mira/CDReasoning-07.pdf · Reasoning with...
�
Reasoning with UML Class Diagrams: Relevance, Problems, and Solutions – a Survey
Mira Balaban1, Azzam Maraee2, Arnon Sturm2
1Department of Computer Science, 2Department of Information Systems Engineering,
Ben-Gurion University of the Negev, Beer Sheva 84105, Israel
[email protected], [email protected], [email protected]
Abstract UML is now widely accepted as the standard modeling language for software construction. The
Class Diagram model is its core view, providing the backbone for any modeling effort and
having well formed semantics. Class diagrams are widely used for purposes such as software and
language specification, database and ontology engineering, and model transformation. The
central role played by class diagrams emphasizes the need for strengthening Computer Aided
Software Engineering (CASE) tools with features at the level of modern integrated development
environments. Such tools need to detect errors in models, identify the source of errors, reveal
redundancies, and possibly suggest design improvements. These tasks require reasoning
capabilities since they depend on the meaning of the constraints that occur in a diagram.
This paper characterizes four essential reasoning problems in class diagram design, and
surveys methods for their solution. The contribution of this paper lies in classifying reasoning
problems in the class diagram model, presenting the state of the art results for these problems,
and enlightening key issues for future research.
Keywords: Reasoning, Conceptual Modeling, UML, class diagrams, consistency, finite satisfiability, redundancy, design quality, inconsistency detection.
�
Reasoning with UML Class Diagrams: Problems, Relevance and Efficiency – a Survey
Abstract UML is now widely accepted as the standard modeling language for software construction. The
Class Diagram model is its core view, providing the backbone for any modeling effort and
having well formed semantics. Class diagrams are widely used for purposes such as software and
language specification, database and ontology engineering, and model transformation. The
central role played by class diagrams emphasizes the need for strengthening Computer Aided
Software Engineering (CASE) tools with features at the level of modern integrated development
environments. Such tools need to detect errors in models, identify the source of errors, reveal
redundancies, and possibly suggest design improvements. These tasks require reasoning
capabilities since they depend on the meaning of the constraints that occur in a diagram.
This paper characterizes four essential reasoning problems in class diagram design, and
surveys methods for their solution. The contribution of this paper lies in classifying reasoning
problems in the class diagram model, presenting the state of the art results for these problems,
and enlightening key issues for future research.
1 Introduction The Unified Modeling Language (UML) is the standard de facto for system development as it
was developed and adopted by the Object Management Group [�68]. It consists of several
languages, each describing a different view of object-oriented software. The most important view
of UML is the static/structural specification that is expressed as a class diagram. A class diagram
�
is a structural abstraction of the real world which consists of classes and their descriptors,
associations among them, and constraints imposed on both classes and associations.
The origin of the class diagram model is the conceptual models of the 80's, like Entity-
relationship (ER) diagrams [�23], their Enhanced versions (EER), Object-Role Modeling (ORM)
diagrams [�42], and Frames structured modeling in artificial intelligence [�67]. The UML class
diagram model includes elements from all of these models.
Among the nine visual UML models, class diagrams appear to be the most clear, intuitive
and well defined. Dobing and Parsons performed a survey on the usage of UML [�28]. In that
survey, the class diagram was most frequently used (73 percents). It was found useful in
clarifying technical understanding, for programmer specification, and for maintenance
documentation. It was found less useful for client verification. The major usage of UML class
diagrams is to specify, visualize, and document the system static view. They also serve as a basis
for generating implementation artifacts such as code skeleton and database schemata, as a means
for knowledge representation such as specifying ontologies, and for defining meta-models of
other programming, modeling, and specification languages.
The central role that class diagrams play in the design and specification of software,
databases and ontologies emphasizes the need for powerful Computer Aided Software
Engineering (CASE) tools, at the level of current Integrated Development Environments (IDE).
Such tools need to prevent syntax errors, provide model critique, and possibly suggest design
improvements. Model critique can detect redundancies and contradictions, and identify the
reasons for errors. Such tasks require reasoning capabilities since they depend on the meaning of
the constraints that occur in a diagram. Furthermore, reasoning enables better model
management as it provides capabilities for querying the model.
�
In this paper, we characterize four essential problems that require reasoning on class
diagrams, and survey main research results in coping with these problems. The contribution of
the paper lies in classifying reasoning problems with respect to the class diagram model, and
presenting the state of the art results for these problems, while enlightening the key issues for
future research.
The structure of the rest of the paper is as follows. Section 2 introduces the class diagram
notions, and discusses the relevance of applying reasoning techniques when analyzing it. Section
3 presents the classification of class diagram reasoning problems, and the survey of available
solutions. Section 4 concludes and draws the line for future research.
2. The UML Class Diagram A class diagram is a structural abstraction of a real world phenomenon. The model consists of
basic elements, descriptors and constraints. The basic elements are classes and associations, the
descriptors are class and association attributes, and the constraints are restrictions imposed on
these elements. The constraints are (1) cardinality constraints on associations, with or without
qualifiers; (2) association class constraint; (3) class and associations hierarchy constraints; (4)
generalization set constraints; (5) association constraints; (6) aggregation constraints; and (7)
cardinality constraints on attributes. The syntax and informal semantics are described in [�68,
�74].
Figure 1 is an example of a class diagram, which partially specifies a university system. It
captures the people hierarchy within the university and their relationship to the university
courses. Classes are represented by rectangles; associations are represented by lines between the
rectangles; cardinality constraints are marked on the association line ends; association classes are
marked by a dashed line connecting a class rectangle with an association line; class hierarchy
�
constraints are marked by empty arrow heads; and association hierarchies are marked by a
dashed arrow labeled "subset" between association lines.
The semantics of class diagram assigns set extension1 to classes, and relations to
associations. For example, in Figure 1, the Academic class represents the set of academic people
in the university, and the association between FacultyMember and Course denotes a set of pairs
(links) of faculty members and courses in which the FacultyMember object plays the role of a
teacher. Attributes serve to identify all members of a class as having the same set of attributes
(and methods).
Constraints are used to restrict the otherwise unrestricted extensions of the components of
a class diagram. Class and association constraints restrict the set and relation extensions of
classes and associations, respectively. Attribute constraints restrict attribute values in terms of
types and cardinality. Association cardinality constraints are written at the association line end,
and specify the number of objects of one class that can be associated with one object from the
other class. For example, according to Figure 1, a FacultyMember can teach up to three Courses
(as indicated by the 0..3 cardinality constraint). Association classes restrict their objects to be
identified by pairs of the connected association. In Figure 1, every Enrollment object is identified
by a Course-Student object pair (no two enrollments are identified by the same pair).
Class hierarchy constraints specify subset relation between the extensions of classes. In
Figure 1, the extensions of the FacultyMember and the Graduate classes are subsets of the
Academic extension. Class hierarchy constraints can be grouped into a Generalization Set, as
shown in Figure 1. For example, GraduateCourse, UnderGraduateCourse and Course form a
Generalization Set. In that case, more constraints can be defined on the group. There are two
1�The term set extension refers to the set of objects (class instances) that instantiate a class, and to the set of links
(association instances) that instantiate an association.
�
orthogonal planes for defining such constraints: (1) disjointness and (2) completeness. The
constraints {overlapping, complete} on the generalization set of Course indicate that a course
may be simultaneously a graduate and an undergraduate course {overlapping}, and that every
course is either graduate or undergraduate {complete}.
Figure 1. A partial class diagram of a university system
2.1. Applications of UML Class Diagrams UML models are now being used for a wide range of applications, including traditional software
specification, model transformations, ontology design, and meta-modeling.
System specification and model transformation:
A class diagram is the backbone of any software specification since it captures the system
structure throughout the lifecycle development. Moreover, in reverse engineering, the main
output artifact is a class diagram that is a mirror of the code. The system specification is also
used for transformation purposes such as generating code skeleton [�64] and database schemata
[�13].
Ontology design:
�
Another emerging use of class diagrams is the design of ontologies [�53, �56]. Currently, there is
no standard for ontology representation languages. There are several OWL based dialects [�88�27]
there is a WSML effort [�26, �59], there are plain RDF written ontologies, there are general KIF
based general ontologies like SUMO [�79], and there are plenty industry initiated concrete
ontologies (e.g., OAGIS [�69] and Rosettanet [�73]). One thing is agreed for all ontologies:
Symbolic ontology specification is not human-understandable. Therefore, there is a need for a
visual language for ontology specification and manipulation.
The UML class diagram model, being the standard for system specification that is widely
adopted in the industry and supported by most CASE tools, is a natural candidate. The
integration of the two formalisms is usually done using the transformation approach, i.e.,
defining rules for converting class diagrams to an ontology language specification [�24, �25, �37,
�40, �83].
Meta-modeling:
The class diagram model is a major meta-modeling formalism. A meta-model is an explicit
model of the constructs and rules (abstract syntax) needed to build specific models within a
domain of interest. A meta-model can be viewed from three different perspectives: (1) as a set of
building blocks and rules used to build models; (2) as a model of a domain of interest, and (3) as
an instance of another model [�66]. Meta-modeling is the process of determining the requirements
imposed on the modeling language or the modeling process [�86]. The usage of meta-modeling
has increased during the last decade. It is used for building meta-CASE tools for supporting
multiple specification languages and composing new domain specific languages [�65�33]. It is also
used as a means for specifying transformations among models, as in [�2]. In addition, meta-
models are used for data integration. The usage of UML class diagrams for meta-modeling
purposes have been demonstrated by Karsai et al., who use a subset of the UML class diagram
and OCL for describing a meta-model [�55]. The Eclipse environment for system development
provides several plug-ins, e.g., the Generic Eclipse Modeling System (GEMS), that use class
diagrams as a means for defining meta-models [�31].
2.2. Reasoning Needs in UML Class Diagram 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 [�77]. Indeed, Lange et al. showed that model defects often remain
undetected, even if practitioners check the model attentively [�58].
These problems are empowered when a model originates from different resources, as
frequently happens when Web services are integrated. Combined sources are usually
overlapping, and the integration yields redundant inconsistent models [�1, �15, �18, �44,�46]. It is a
common belief that such problems can best be solved at the level of models [�50].
Thus, the need to provide coherent models is appealing. In particular, in order to avoid
inconsistencies, redundancies, and ambiguities, it is essential to have tools that can support
validation of the models. Furthermore, models can be improved, based on given design criteria.
For ontology engineering purposes, it is of utmost importance to keep the model accurate,
consistent, and unambiguous, as it usually serves multiple knowledge bases. The same holds for
meta-models as they underlie the modeling of concrete systems. In order to achieve the goal of
improving a model quality a diversity of reasoning capabilities is required.
Reasoning with formalism requires the existence of formal semantics that assigns an exact
meaning to each expression of the formalism. Indeed, there is a wide research effort whose goal
is to provide formal semantics to class diagrams (and to UML as a whole). One way to define
meaning is to directly assign a denotation to every language construct. This is termed declarative
direct semantics. An alternative way to define language semantics is to use a different formally
defined language that already has a formal semantics, as a "mediator". That is, instead of
defining the meaning of elements directly as described above, they are translated into
expressions of the intermediate language. This approach is termed indirect semantics.
The semantics of UML class diagrams has been defined using both approaches. The direct
semantics of class diagrams assigns set extensions to classes and associations. It has been
formally defined by several studies such as [�72, �78]. There are several indirect semantics
approaches for class diagrams in the literature. Full first order logic is the most popular
intermediate language for class diagrams without OCL constraints [�12, �54], or with OCL
constraints [�10, �70]. Some other intermediate languages are Z and Object-Z [�22, �34, �35, �76],
Algebraic specifications in the form of Abstract Data Types [�3, �4], and Hierarchical Predicate
Transition Nets [�49].
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. The
additional power can help in detecting design problems, identifying the reasons for these errors,
suggesting possible solutions, and providing advice for design improvements [�12, �52, �57, �85].
3. Reasoning Problems in Class Diagrams Reasoning on UML models in general and on class diagrams, in particular, gains much attention,
recently. Reasoning is necessary for improving the design quality and for supporting application
construction needs. Design quality refers to (1) erroneous models that impose inconsistent
constraints, (2) redundant models that can be simplified, and (3) models that can be improved
��
according to some design criteria [�12, �46]. Reasoning helps in detecting erroneous models,
finding the source of errors and possibly suggesting repairs. It is used for revealing redundant
situations, and for testing whether design criteria are met.
Questions about class diagram quality deal with inconsistency, finite satisfiability,
redundancy, and design improvement. Inconsistency arises when the constraints imposed by a
class diagram are contradictory. Finite satisfiability is caused by cardinality constraints that can
be satisfied by either empty or infinite class extensions (i.e., instantiations). Redundancy appears
when constraints seem to allow values or links that cannot be realized (are inconsistent). Quality
improvement deals with changing the models following various criteria such as design patterns
or reuse enhancements.
Inconsistency and lack of finite satisfiability, are considered erroneous design. The first,
because an inconsistent class diagram does not have a non-empty extension, and the latter,
because there is no finite and non-empty extension [�16]. For example, constraints that imply
simultaneous disjointness and non-empty intersection of classes cause inconsistency
(contradiction). Both questions may be asked at the diagram or at the class level. The consistency
question at the whole diagram level is: "Is there an instance where all class extensions are non-
empty?" Consistency at the class level is "For every class in a diagram, is there and instance in
which the class extension is not empty?" Similarly, the whole diagram can be checked for finite
satisfiability (i.e., having an instance where all class extensions are finite and non-empty), or
whether a single class is finitely satisfiable. Most reasoning efforts have been devoted to the
identification, detection and repair of inconsistency.
Redundancy is considered as inaccurate specification. For example, a wide cardinality
constraint range, which cannot be realized without causing inconsistency, is a source of
��
redundancy. Equivalent classes (having the same extension) are another source of redundancy.
Redundancy detection can help in simplification tasks, since it enables to tighten cardinality
constraint ranges and removing redundant classes and associations.
Design improvement within a class diagram refers to the ability to represent the
specification in terms of the appropriate abstraction for handling reuse and maintenance.
In the following we define and demonstrate the aforementioned problems. The various
examples were kept small in size for the sake of clarity. These problems can clearly be indicated
and resolved. Yet, when dealing with real system models (i.e., complex models), the
identification and the solutions of such problems become a heavy-duty task.
3.1 Inconsistency (Unsatisfiabilty) in Class Diagrams Inconsistency means class emptiness, that is, a class cannot be instantiated since the constraints
imposed on its instances cannot be satisfied. The extreme case involves all classes in the
diagram. Indeed in [�12], Berardi et al. distinguish two cases:
Consistency of a class diagram – A class diagram is consistent (satisfiable) if it has an
instantiation with at-least one non-empty class extension. Otherwise, it is inconsistent
(unsatisfiable).
Class consistency – A class is consistent if there is an instantiation in which the class extension
is non-empty. Otherwise, it is inconsistent.
We claim that class diagram consistency is of less importance, since every class diagram
that has an unconstrained class is consistent.
��
Figure 2 presents an example of such a diagram. The Seminar class is unconstrained and can be
freely instantiated.
Figure 2. A consistnt class diagram, due to an unconstrained class
In fact, every realistic class diagram that we have checked proved to have such a class.
Consequently, we suggest two additional notions termed all class consistency (satisfiability) and
full consistency (satisfiability):
All class consistency of a class diagram – A class diagram is all class consistent (satisfiable) if
every class is consistent.
Full consistency of a class diagram – A class diagram is fully consistent if it has an instance in
which all class extensions are non-empty.
Clearly, full consistency implies all class consistency, which implies consistency. In the
opposite direction, Consistency of a class diagram does not imply all class consistency.
However, all class consistency implies full consistency. Intuitively, this claim is proved by the
following argument: For every class, there is an instance in which the class extension is not
empty. It can be shown that all these (disjoint) instances, can be combined into a single instance
of the class diagram, in which all class extensions are non empty. The argument holds due to the
special character of UML class diagram constraints, which are invariant under disjoint instance
combination [�61, �62, �63].
Inconsistency is caused by constraint contradiction. UML class diagrams include seven
kinds of constraints as described in Section 2. Kaneiwa and Satoh identify some factors for class
rest of the diagram�
��
inconsistency [�54]. We extend their work and characterize contradictory interactions between
constraints.
1. Inconsistency due to generalization set constraints:
Such inconsistency occurs when, for example, a generalization hierarchy has a disjoint
constraint, where the disjoint subclasses have a common subclass. Figure 3(a) presents a case
in which the disjointness constraint enforces the Elective class to be empty. In Figure 3(b), the
interaction of the disjointness and the completeness constraints forces the class B to be empty.
Any instance of E must be an instance of one of the subclasses C or D, but the classes B, C
and D satisfy the disjointness constraint.
(a) (b)
Figure 3. Inconsistency due to generalization-set constraints
2. Inconsistency due to the interaction between class hierarchy constraints and
cardinality constraints:
Such inconsistency may occur when contradictory cardinality constraints exist among
associations that are related by a subset constraint. In Figure 4 the cardinality constraint of
class Member within the LargeComposition is 5. Yet, as this association is defined as a
subset of the Composition association which has cardinality constraint 1..3, there is a
contradiction between these constraints, implying a necessarily empty extension for class
Large.
��
Figure 4. Inconsyitency due to class hierrachy and cardinality constraints
3. Inconsistency due to the interaction between association constraints and cardinality
constraints:
XOR constrains between associations contradict a non-zero minimum cardinality constraint
since the XOR implies that only one of the associations is realized in every instantiation.
Figure 4 presents such a situation.
Figure 5. Inconsistency due to multilicity and inter association constraints
3.2 Finite Satisfiabilty in Class Diagrams Finite satisfiability means that a class has a finite non-empty extension. Lack of finite
satisfiabilty is certainly erroneous since it means that the class cannot be instantiated. An
example of a finite satisfiability problem can be derived from Figure 1 in Section 2. In this
example, the cardinally and the class hierarchy constraints between classes Graduate and
Academic enforce the Graduate class to be either empty or infinite.
Finite satisfiability is an essential property for all classes, since a necessarily empty or
infinite class extension means that a class is either empty, and hence redundant, or its
instantiation causes infinite loops. Similarly to the inconsistency case, finite satisfiability can
��
also refer to a single class or to the whole class diagram. However, while class diagram
consistency requires the consistency of at least one class, finite satisfiability must apply to all
classes.
In analogy with the terminology for inconsistency, we introduce three terms: Class
finiteness, all class finiteness, and full finiteness.
Class finite satisfiability – A class is finitely satisfiable if there is a finite instance of the class
diagram, in which the class extension is non-empty. A class diagram instance is finite if all class
extensions are finite.
All class finite satisfiability of a class diagram – A class diagram is all class finitely satisfiable
if for every class there is a finite instance in which the class extension is non-empty. Lenzerini
and Nobili (1990) used the notion strong satisfiability for this term.
Full finite satisfiability of a class diagram – A class diagram is fully finitely satisfiable if it has a
finite instance in which all class extensions are non-empty.
Clearly, full finite satisfiability implies all class finite satisfiability. The inverse is also
true, i.e., all class finite satisfiability implies full finite satisfiability. The proof is similar to the
consistency case. Note that in the consistency case no attention is paid to finiteness of the class
diagram instances.
Finite satisfiability problems are caused by cycles of conflicting cardinality constraints.
The cycles might include class hierarchy constraints, generalization set constraints, and
association class constraints. We analyze six kinds of conflicting constraints that prevent finite
satisfiability, and provide examples for each kind. In all cases the diagrams are fully consistent
but lack finite satisfiability. That is, full consistency can be achieved only by infinite class
extensions.
��
1. Lack of finite satisfiability due to cardinality constraint conflict:
In Figure 6, each course should have a single successor and at least two predecessors. Therefore,
if the number of courses in a diagram instance is C, and the number of Dependency links is D,
then D must satisfy D = C*1 and D � C*2, implying the inequality: C � C*2, that can be
satisfied only by empty or infinite extensions for class Course. Therefore, although the class
Course is consistent it is not finitely satisfiable.
Figure 6. Unsatisfiability due to cardinality constraint conflict
2. Lack of finite satisfiability due to class hierarchy and cardinality constraint conflict:
Figure 7 presents a cardinality constraint cycle that involves a compound class, Graduate,
whose instances must be related to Academic instances. Therefor, using similar considerations as
in the previous case, the number of student-advisor links in every diagram instance must be both,
G*1 and A*2, assuming that G and A are the number of graduates and academics, respectively.
Therefore, the extensions of Graduate and Academic must satisfy G = A*2, while the Graduate
extension is a subset of the Academic extension. This constraint can, again, be satisfied only by
empty or infinite extensions. Note that the diagram is fully consistent as every class has a non-
empty extension.
Figure 7. Unsatisfiability due to class hierarchy constraint conflict
��
3. Lack of finite satisfiability due to interaction between an association class constraint and
cardinality constraints:
Figure 8 presents a case where an association class, Contract, is constrained by contradictory
cardinality constraints. In every legal instance, the number C of contracts is as twice the number
of employees, E, since every employee is linked with two departments. Yet, the number of
contracts is equal to the number of employees, as dictated by the Manager association. That is, C
= E*2, and E = C, implying E = E*2 which can be achieved only by either empty or infinite
extensions for all three classes.
Figure 8. Unstatisfiability due to aasociation class and cardinality constraints conflicts
4. Lack of finite satisfiability due to cardinality constraints conflict, that is caused by class
and association hierarchy:
In Figure 9, classes Member and Large are related via associations Management and
LargeComposition. The cardinality constraints in these associations can be finitely satisfied.
However, the LargeComposition association is constrained to be a subset of the Composition
association between Team and Member, implying that the cardinality constraint of Member in
LargeComposition is actually tightened into 2..3.
This restricted cardinality range causes a finite satisfiability problem. For the Management
association, if M, L, Man are the number of instances of Member, Large and Management,
respectively, then Man = L*4, Man = M*1 imply M = L*4. For the LargeComposition
association, if LC is the number of its links, then L*2 � LC � L*3, LC = M*1 imply L*2 � M �
�
L*3. Replacing M by L*4 yields the inequality L*2 � L*4 � L*3, that can be satisfied only if the
Large, and thereby the Member, extensions are either empty or infinite.
Figure 9. Inconsistency due to class hierrachy and cardinality constraints
5. Lack of finite satisfiability due to asymmetry of aggregation and composition:
The asymmetric property of aggregation/composition requires that a part of an assembly cannot
aggregate one of its aggregators. Consequently, a legal instance of a class diagram cannot
include aggregation cycles. Figure 10 depicts a case, where an organization consists of at least
one child organization. Due to the acyclic character of the aggregation association, this
cardinality constraint can be satisfied by either an empty or an infinite chain of organizations.
Figure 10. Unsatisfiability due to the asymmetry of aggregation
6. Lack of finite satisfiability due to a generalization set constraint:
In Figure 11 the {disjoint, incomplete} constraints suggests that the Academic extension properly
includes the FacultyMember and the Graduate extensions. Yet, Academic elements are mapped
in a 1:1 manner to Graduate elements, implying that the sets have the same size. The problem is
that non-emptyness of class FacultyMember implies infinity of classes Academic and Graduate.
The only solution for proper set inclusion with equal size is that the sets are either empty or
infinite.
�
Figure 11. Unsatisfiability due to a generalization set constraint
3.3 Redundancy Redundancy means that the specification can be simplified without affecting its meaning. For
example, classes or associations that have the same extension in all instances are redundant.
Another example involves cardinality values, in cardinality constraints or in attribute
descriptions, which cannot be realized. In the first case, one of the equivalent elements can be
removed. In the latter case, the cardinality value range can be tightened. In the following we
demonstrate these two cases of redundancy.
1. Redundancy due to equivalent classes:
Class redundancy occurs mainly due to generalization. In Figure 12 the Graduate extension is a
subset of Academic due to the class hierarchy constraint, and the sets have the same size, since
Academic elements are mapped in a 1:1 manner to Graduate elements. If the sets are finite, they
must be equal, and therefore the Graduate class is redundant and can be removed.
Figure 12. Redundancy due to equivalent classes
2. Redundancy due to equivalent associations Association equivalence can occur due to generalization constraints that involve association
classes. In Figure 13, R and Q are associations and that constrain the association classes, P and
Q, respectively. The association classes are constrained by class hierarchy, as well as by a 1:1
��
cardinality constraint. As in the previous case, P and Q have equal extensions in all diagram
instances. Therefore, one of the associations R and Q, and one of the association classes P and S,
are redundant, and should be removed.
Figure 13. Redundancy due to equivalent associations
3. Redundancy of cardinality constraint values:
Figure 14 demonstrates an association hierarchy constraint between the LargeComposition and
the Composition associations. The cardinality constraint 1..3 of the Member class in
Composition, makes the cardinality constraint 1..* of the Member class in LargeComposition too
loose, as the maximal cardinality is 3.
Figure 14. Redundancy due to cardinality constraints
3.4 Design Improvement Improving the design quality might arise when implicit consequences are noticed. For example,
assume that a class diagram specification implies that a certain class or an association must be a
sub-class or a super-class of another class or association, respectively. Then explicit specification
of these hierarchy relations might improve the diagram quality, or expose relations that should be
observed by the developer. Figures 15 and16 demonstrate transformations of class diagrams,
��
based on redundancy and repair of semantic errors detection. Similar problems of class diagram
redundancy and implicit consequences are identified and discussed by [�12, �34, �78].
1. Design improvement due to class redundancy:
Figure 12 demonstrates redundancy since classes Graduate and Academic are equivalent (they
necessarily have the same extension). The redundancy can be eliminated, thereby improving the
overall design, as shown in Figure 15.
Figure 15. Design improvement due to class equivalence
2. Design improvement due to incomplete hierarchical structure:
Complex structures within class diagrams can include semantic errors, as shown in Figure 16a.
The problem is that association hierarchy can apply only to class pairs that admit class hierarchy
constraints (the subset relation can exist only among same type pairs). Instead of rejecting the
diagram, a “smart” CASE tool might adopt a credulous approach, by inferring a repair to the
detected problem, as shown in Figure 16b.
�
(a) (b)
Figure 16. Design improvement due to incomplete hierarichal structure
��
4 Methods for Reasoning about Class Diagrams
Reasoning methods about class diagrams support both general implication and handling the
problems of consistency, finite satisfiability, redundancy and design improvement, which are
described in the previous section. Solutions to these problems can be at three levels: problem
detection, cause identification, and repair [�46]. Problem detection means just notification that a
problem exists. Cause identification means detecting the reason for the problem, and repairing
amounts to suggesting a solution. Most reasoning approaches provide problem detection alone.
Yet, if we wish to have CASE tools that approach the level of current Integrated Development
Environment compilers we need to provide at least cause identification.
Class diagram reasoning methods can be classified into concrete reasoning methods that
directly solve specific problems [�7, �43, �54, �61, �63], and to translation-based methods that
support reasoning by mapping UML models into a formal reasoning framework [�12]. Concrete
methods tend to apply to error detection and revealing redundancy, while translation based
methods deal with general query answering for a variety of modeling needs.
In the translation-based methods, a UML class diagram is translated into a formula or
expression in some other language, and the translation is proved correct. The notion of
correctness varies between studies. The formal notion requires a proof of equivalence, i.e., a
proof that the translation preserves all and only the implications of the original class diagram.
The main advantage of the translation-based approach is the uniform handling it provides to a
variety of problems. Once the class diagram is translated, such methods rely on an already
existing reasoner for question answering. Therefore, a single translation can serve for answering
many questions. On the other hand, they cannot optimize solutions to problems.
��
Concrete methods present an opposite approach. Each method is usually targeted at
solving a single problem, in an optimal way. Consequently, solutions are better dedicated to
solve their problems, but many such solutions need to be designed. Yet, the concrete methods
tend better to scale up to large problems, and it is easier to embed such algorithms within UML
CASE tools. This option seems unreasonable for translation-based methods, as the embedding of
a full reasoner tends to be quite heavy.
Before embarking on the description of existing methods, it is important to emphasize
three essential features of reasoning methods: Soundness, completeness and complexity.
Soundness means that the method infers correct results; completeness means that the method can
derive all correct results, and complexity refers to its efficiency. It is well known that there is a
tradeoff between the expressivity of a formalism and efficiency of reasoning on it. Greater
expressivity leads to reduced efficiency. Reasoning on expressive formalisms is a hard problem,
which cannot be solved efficiently. Therefore, insisting on complete reasoning necessarily leads
to inefficient reasoning. Indeed, while soundness is unquestionable, completeness is a subject for
debate: Should we (1) restrict the formalism, (2) abandon completeness, or (3) live with
inefficient reasoning algorithms?
The reasoning methods described below demonstrate all of these options. The description
logics based methods support complete, intractable reasoning on expressive class diagrams.
Some concrete methods support complete tractable reasoning for restricted versions of UML
class diagrams. Still other concrete methods provide efficient incomplete methods for reasoning
over expressive class diagrams. Our survey separates the translation-based methods from the
concrete ones. Among the first kind, we concentrate on the description logics based approach.
The concrete methods are classified by the concrete addressed problems.
��
4.1 Translation-Based Methods for Reasoning about Class Diagrams Using Description Logics (DLs) is, probably, the most prominent approach for reasoning about
class diagrams and databases, by employing a general reasoner. It is motivated by the immediate
similarity between the worlds described by both formalisms [�14, �17, �19, �20, �21, �90].
Class diagrams describe a structured world of classes and associations, while DLs
describe a similar world of concepts and roles. Beyond this analogy, each formalism has its own
unique elements. Class diagrams have additional descriptors (attributes of classes and
associations), and specific constraints that receive concrete visualizations. Description logics,
being logic languages, are more uniform and have just few additional elements [�5]. In fact,
beyond concepts and roles, description logics have just combinators (operators) used for
constructing concept and role expressions. Such expressions enable the introduction of an
unbound number of implicit, nameless concepts and roles. These operators are the only
difference between the various description logics. For example, referring to Figure 1, description
logics can describe the following concepts:
� Graduate-course or Undergraduate-course2 – stands for all objects that are either graduate or
undergraduate courses;
� not (Faculty-member or Graduate) – stands for all objects that are not academics;
� Course and all Enrollment is (atleast 2 Graduate and Resident) – stands for all courses
having at least two enrolled graduate resident students;
� Course and exists teacher.student is Resident – stands for all courses whose teacher advises
a resident graduate student;
2� For the sake of readability, we use an intuitive free syntax.
��
The common feature of the above four concepts is that they are nameless, and are implicitly
defined using the concept forming operators or, and, not, all, exists, atleast3. This is different
from UML class diagrams, where the only way to introduce classes is via an explicit new name,
that is associated with the class attributes, associations and constraints.
Implicit concept/role construction opens the door for targeted concept/role reasoning. For
example, it is possible to infer that:
� Objects that are neither faculty members nor graduates are necessarily not academics: not
(Faculty-member or Graduate) is subsumed by not Academic;
� Electives that have at least two student enrollments are not necessarily courses with at least
one graduate student enrollment:
Elective and all Enrollment is (atleast 2 Student) is not subsumed by
Course and all Enrollment is (atleast 1 Graduate);
Indeed, description logics have developed concrete sound and complete inference algorithms,
that are implemented in state of the art description logic reasoners like Racer [�41] and FaCT
[�51]. Moreover, FaCT++ [�84] supports reasoning with ontology languages like OWL [�71]) and
WSML-DL [�26].
The ontological similarity between UML class diagrams and description logics, and the
essential reasoning capabilities of description logic tools present DLs as a natural candidate for
supporting reasoning about class diagrams. Berardi et al. encode class diagrams in description
logics and prove that reasoning on UML class diagrams is EXPTIME-hard [�12]. They also show
that under minor restrictions, UML class diagrams can be encoded in the description logic
ALCQI which is the most expressive description logic that is supported by DL reasoning tools.
Berardi describes a tool that translates UML class diagrams into the DL reasoners FaCT and
3� This is similar to a relational DB table, obtained by a relational algebra operator from other tables.
��
Racer [�11]. The ICOM tool supports DL based reasoning on Extended Entity Relationship and
UML class diagrams [�38].
The encoding of UML class diagrams into Racer suggests that UML CASE tools can
provide reasoning capabilities by association with DL reasoners. The beauty of such encoding is
that it can be used for answering a variety of questions about a class diagram. In fact, apart from
finite satisfiability, all reasoning problems discussed in this paper can be answered using the DL
translation. Moreover, using the DL encoding, all reasoning problems can be reduced to the
emptiness problem.
Nevertheless, the description logic based reasoning does not support inconsistency cause
identification and certainly not repairing. In order to localize the reason for inconsistency, one
has to query for the consistency of each class, separately. Moreover, reasoners would not suggest
implicit consequences by themselves, unless they are explicitly asked for. Therefore, DL based
reasoners for reasoning on UML class diagrams cannot function as smart compilers that can
detect the cause for a problem and suggest solutions for repairing.
A different translation based approach for reasoning about class diagrams is reported in [�3,
�4]. In that study, UML class diagrams are translated into abstract data types, and the Larch
prover [�39] is used for reasoning about them. Similarly to the description logics based
translation, the method enables reasoning on a variety of inconsistency problems. The problem
seems to lie in scaling, as each class diagram element translates into multiple algebraic rules, and
the prover cannot handle large sets of rules.
4.2 Concrete Methods for Reasoning about Emptiness (inconsistency) of Class Diagrams
��
Kaneiwa and Satoh study the problem of full consistency in a subset of UML class diagrams
that include classes with typed attributes and cardinality constraints on the attributes,
unconstrained associations and constrained generalization sets [�54]. They identify three factors
for inconsistency in such diagrams: (1) combination of generalization with disjointness; (2)
attribute overwriting in multiple hierarchies; and (3) combination of completeness and
disjointness constraints in generalization sets. Based on these factors, they provide tractable
algorithms for deciding full consistency in the restricted class diagram model.
The algorithms operate on a first order logic encoding of the class diagram, which serves
as an indirect-semantics definition. They analyze the structure of the given diagram and identify
occurrences of the inconsistency factors. Consequently, this concrete method functions as
inconsistency detection algorithm and cause identification algorithm as well.
This method is implemented as a debugging system for restricted class diagrams [�75].
The debugging is based on an elaborated set of rules for contradiction detection. The rules enable
identification of the part in the UML diagram that cause the inconsistency, and suggest a possible
solution.
In comparison with the description logic based approach for deciding consistency, this
method is stronger in the sense that it can decide full consistency in a tractable time, identify its
cause, and suggest a solution. Yet, the method applies only to a restricted version of UML class
diagrams. Description logics, on the other hand, account for any class diagram, but cannot
account for full consistency using a single query. One can query for consistency of every class in
the diagram, but not for the simultaneous consistency of all classes.
4.3 Concrete Methods for Reasoning about Finiteness of Class Diagrams
�
Reasoning on finiteness of entity relationship and class diagrams has attracted much attention.
The problem was independently identified by Lenzerini and Nobili [�61] and by Thalheim [�80�80,
�81, �82], and referred to entity relationship diagrams. Later on the methods have been extended to
various fragments of UML class diagrams. The problem is to detect, identify cause and suggest
repair, to diagrams that are not fully finitely satisfiable.
There are two main approaches: the linear programming approach and the graph based
approach. The first approach reduces the full finite satisfiability problem to the problem of
finding a solution to a system of linear inequalities. The second approach detects infinity causing
cycles in the diagram, and possibly suggest repair transformations. All methods apply only to
fragments of UML class diagrams. Detection of infinity in unrestricted UML class diagrams is
still an open issue.
4.3.1 Linear Programming Based Full Finite Satisfiability Detection:
The work of Lenzerini and Nobily (1990):
The fundamental method of Lenzerini and Nobily [�61] is defined for an entity relationship
diagram that includes Entity types (Classes), n-ary Relationship types (Associations), and
Cardinality Constraints4. The method consists of a transformation of the cardinality constraints
into a set of linear inequalities whose variables stand for the sizes (cardinalities) of the entity and
relationship types in a possible instance. A relationship:
yields the four inequalities: r � min1�C1 , r � max1�C1 , r � min2�C2 , r � max2�C2., where r, C1,
C2, are variables that stand for the sizes of the respective entity or relationship types. In addition,
4�Lenzerini and Nobili (1990) use the membership semantics for cardinality constraints (consult Balaban and Shoval
(2002) for semantics of cardinality constraints). For non-binary relationships, this is not the standard semantics of cardinality constraints, neither in the entity relation model nor in the class diagram model.
min1..max1 min2..max2
r C1 C2
�
for every entity or relationship type T, the inequality T>0 is inserted. The size of the inequality
system is polynomial in the size of the diagram. The main result is that the entity relationship
diagram is fully finitely satisfiable if and only if the inequalities system has a solution. Since
linear programming is solvable in polynomial time in the size of the problem encoding, full finite
satisfiability for this fragment of class diagrams can be decided in polynomial time.
The work of Calvanese and Lenzerini (1994):
Calvanese and Lenzerini extend the inequalities based method of Lenzerini and Nobili [63] to
apply to schemata with ISA (class hierarchy) constraints [�17]. The expansion is based on the
assumption that class extensions may overlap. They provide a two stage algorithm in which the
full finite satisfiability problem of a class diagram with ISA constraints is reduced into the full
finite satisfiability problem of a class diagram having no class hierarchy constraints. Then,
similarly to Lenzerini and Nobili [63], the full finite satisfiabilty of the new class diagram is
checked by testing whether a derived linear inequalities system has a solution.
The linear inequalities system derived in Calvanese and Lenzerini [�17] is different from
the one derived by Lenzerini and Nobili [63]. It is quite complex, and might introduce, in the
worst case, an exponential number, in terms of the input diagram size, of new classes and
associations. This method was simplified in Cadoli et al. by restricting class overlapping to class
hierarchy alone [�16]. The latter simplification reduces the overall numbers of classes and
association, but still introduces, in the worst case, an exponential number of new classes and
associations.
Calvanese and Lenzerini show that class hierarchy constraints can be used also for
answering implication queries [�17]. That is, answering whether a constraint is implied by a class
diagram. The idea is to add an ISA constraint in which the desired implication is embedded. For
��
example, to answer questions like "Is m the minimum (maximum) cardinality on the role R of a
class C in an association A", they suggest to add a subclass C’ to C, with a maximum m-1
(minimum m+1) for its role R in A, and ask for finite satisfiability of the new class. The
implication holds if and only if the new class C’ is not finitely satisfiable (because in that case, in
every extension of C the cardinality is as required).
The work of Balaban and Maraee (2006):
Balaban and Maraee extend the inequalities based method of Lenzerini and Nobili [63] to apply
to UML class diagrams with (1) binary association; (2) class hierarchy (ISA) constraints; (3)
generalization set constraints disjoint/overlapping and complete/incomplete; (4) n-ary association
with the standard interpretation of cardinality constraints; (5) qualifier dependent cardinality
constraint; (6) association classes; (7) association hierarchy constraints [�7, �62, �63]. The extension
is based on a preprocessing reduction of full finite satisfiability of a given class diagram, to the
full finite satisfiability of a restricted class diagrams handled by the Lenzerini and Nobili
method [63].
The generalization set constraints present the hardest requirement. Their occurrences
require the addition of new inequalities, and restrict the method scope to class hierarchies whose
undirected graph structure is acyclic (termed below acyclic class hierarchies). For example, for
the class diagram in Figure 1, the method presented in [�62, �63] does not apply to the Course
cyclic class hierarchy, but fully applies to the rest of the diagram.
The advantage of this method over the Calvanese and Lenzerini method [19] lies in its
simplicity and efficiency. The method introduces only a linear number of new associations and
inequalities (linear in the diagram size) and requires only a linear inequalities solver. Therefore it
is simple to extend a UML CASE tool with this method [�63]. On the other hand, this method
��
does not apply to cyclic class hierarchies (see above). Therefore, it seems reasonable to combine
it with the Calvanese and Lenzerini method [19]. That is, use the first method for the major part
of a class diagram, and apply the latter more expensive method to the cyclic class hierarchies in
the diagram. This method integration relies on the assumption that cyclic class hierarchies do not
occur frequently in class diagrams.
The three linear inequalities based methods described above act only as detectors for full
finite satisfiability. Boufares and Bennaceur [�15] suggest using the Fourier-Motzkin elimination
method [�89] for solving the obtained system of linear inequalities. They show how this method
can help in identifying the source of infinity, when the inequalities system is unsolvable. The
idea is that backtracking the solution process reveals the conflicting cardinality constraints.
4.3.2 Graph-Theoretic Full Finite Satisfiability Detection, Cause Identification and Repair:
The work of Lenzerini and Nobili (1990):
In addition to the linear inequalities method, Lenzerini and Nobili also present a method for
identification of causes for lack of finite satisfiability [63]. For that purpose they convert the
diagram into a directed graph whose nodes stand for classes and relationships. The edges are
assigned weights that are derived from the cardinality constraints. They prove a connection
between finite satisfibility to the weights on graph cycles. Cycles that imply infinity are termed
critical cycles. Moreover, each critical cycle singles out a non-finitely satisfiable set of
cardinality constraint. Lenzerini and Nobili were the first to suggest a method for cause
identification of full finite satisfiability in restricted entity relationship diagrams. Their solution
is not constructive, as they do not provide a method for computing critical cycles. A first step
towards finding critical cycles appears in [�82]. Hartman presents a different method for
identifying the cause for infinity [�43] (see below).
��
The work of Dullea and Song (1998):
Dullea et al. characterize infinity causing structures (termed structural invalidity) of recursive
binary and ternary relationship types in entity relationship diagrams [�29, �30]. The analysis
suggests a set of structure based decision rules for identifying structural invalidity in entity
relationship diagrams.
The work of Hartman (1995; 2001a; 2001b):
Hartman handle the problems of full finite satisfiability from all three aspects of detection, cause
identification and repair [�43�46, �47]. He suggests a polynomial time graph-theoretical method for
the detection of full finite satisfiability in entity relationship diagrams (same model as in
Lenzerini and Nobili). He defines a similar notion of critical cycles, and uses it for detecting
infinity problems. In addition, for graphs without critical cycles, the method can derive a
minimal finite instance. More details on this work appear in [�44, �45].
Hartman suggests critical cycles based methods for cause identification and repairing for
lack of finite satisfiability problems [�46]. The paper suggests four heuristic strategies for
repairing infinity problems. One method is based on finding minimal inconsistent constraint sets
that exist in every critical cycle, and suggests how to repair them. Another method is based on
the notion of feedback arc set which is a set of arcs that intersects all critical cycles in the graph.
The paper suggests a cardinality constraint repair plan, based on an optimization method for
finding a minimal feedback arc set.
Hartmann extends the former work for reasoning about a set of cardinality constraints,
key constraints, soft constraints and functional dependencies [�47, �48]. He presents a list of seven
implication rules for deriving new cardinality constraints from given ones.
��
5. Concluding Remarks Reasoning on UML models in general and on class diagrams, in particular, gains much attention,
recently. In this paper we have classified the major problems that require reasoning on UML
class diagrams, and surveyed the existing approaches and results. We claim that reasoning is
essential for supporting advanced IDE and CASE tools in all application areas of UML class
diagrams. The emerging model driven development approach requires reliable models that are
equipped with powerful reasoning capabilities.
We have identified four categories of reasoning problems: inconsistency, finite satisfiability,
redundancy, and design improvement. The reasoning techniques survey distinguishes between
transformation-based approaches and concrete methods. In particular, we surveyed reasoning
methods that concern emptiness and finite satisfiability problems in class diagrams.
Transformation-based approaches tend to be inclusive, powerful, and solve a variety of
problems. Yet, they fall short of handling full consistency, finite satisfiability, and cause
identification and repair for inconsistency. In particular, weaving such reasoners into an IDE or a
CASE tool is quite heavy. Concrete reasoning methods are, usually lighter, scalable (complexity
depending), and easily weaved into existing tools. Yet, they do not apply to unrestricted class
diagrams. In general, cause identification and repair did not receive sufficient attention.
We envision that the next generation of reasoning tools will embark on method integration.
Tools would employ a mixture of reasoning methods, applying the simpler methods where
possible, and resorting to heavy translation-based reasoning when other methods fail. Embedding
reasoning capabilities within these tools requires scalability; for that purpose incremental
reasoning needs to be further explored.
��
References 1. Ali, A. B., Boufares, F., and Abdellatif, A., On the global coherence of integrity constraints
in UML class diagrams, in Proceedings of the 24th IASTED international Conference on Database and Applications, (2006) 109-114.
2. Amelunxen, C., Konigs, A., and Rotschke, T., MOSL: Composing a Visual Language for a Metamodeling Framework, IEEE Symposium on Visual Languages and Human-Centric Computing, (2006) 81-84.
3. André, P., Romanczuk, A., Royer, J.-C., and Vasconcelos, A., An algebraic view of UML class diagrams, in Proceedings of the 6th colloquium on Languages and Models with Objects, (2000) 261-276.
4. André, P., Romanczuk-Réquilé, A., Royer, J.-C., and Vasconcelos, A., Checking the Consistency of UML Class Diagrams Using Larch Prover, in Proceedings of the third Rigorous Object-Oriented Methods Workshop (2000).
5. Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., and Patel-Schneider, P. F., The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, (2003).
6. Baclawski, K., Kokar, M., Kogut, P., Hart, L., Smith, J., Holmes, W., Letkowski, J., Aronson, M., and Emery, P., Extending the UML for Ontology Development, Software and System Modeling 1 (2003) 1-15.
7. Balaban, M. and Maraee, A., Consistency of UML Class Diagrams with Hierarchy Constraints, in Proceedings of NGITS, LNCS 4032, (2006) 71-82.
8. Balaban, M. and Shoval, P., Enforcing Cardinality Constraints in the ER Model with Integrity Methods. Advanced Topics in Database Research 1 (2002) 1-16.
9. Balaban, M. and Shoval, P., MEER -- An EER Model Enhanced with Structure Methods. Information Systems, 27 (2002) 245-275.
10. Beckert, B., Keller, U. and. Schmitt, P.H., Translating the Object Constraint Language into first-order predicate logic, in Proceedings of VERIFY Workshop at FLoC, Copenhagen, Denmark (2002).
11. Berardi, D., Using description logics to reason on UML class diagrams, in Proceeding of the KI’2002Workshop on Applications of Description Logics (2002).
12. Berardi, D., Calvanese, D., and De Giacomo, G., Reasoning on UML class diagrams. Artificial Intelligence 168 (1) (2005) 70-118.
13. Blaha, M., Premerlani, W., and Shen, H., Converting OO Models Into RDBMS Schema. IEEE Software 11 (3) (1994) 28-39.
14. Borgida, A., Description logics in data management, IEEE Transactions on Knowledge and Data Engineering 7 (5) (1995) 671-682.
15. Boufares, F. and Bennaceur, H., Consistency Problems in ER-schemas for Database Systems. Information Sciences 163 (4) (2004) 263-274.
16. Cadoli, M., Calvanese, D., De Giacomo, G. and Mancini, T., Finite satisfiability of UML class diagrams by constraint programming, in Proceedings of the CP 2004 Workshop on CSP Techniques with Immediate Application (2004).
17. Calvanese, D, Lenzerini, M., On the Interaction between ISA and Cardinality Constraints, in Proceedings of the 10th IEEE International Conference on Data Engineering (1994) 204-213.
��
18. Calvanese, D., De Giacomo, G., Lenzerini, M., Nardi, D., and Rosati, R., Description Logic Framework for Information Integration, in Proceedings of the Sixth International Conference on the Principles of Knowledge Representation and Reasoning (KR'98) (1998) 2-13.
19. Calvanese, D., Lenzerini, M., and Nardi, D., A Unified Framework for Class Based Representation Formalisms, in Proceedings of the Forth International Conference on the Principles of Knowledge Representation and Reasoning (1994) 109-120.
20. Calvanese, D., Lenzerini, M., and Nardi, D., Description logics for conceptual data modeling, in Chomicki J. and Saake G. (eds), Logics for Databases and Information Systems (1998) 229-263�
21. Calvanese, D., Lenzerini, M., and Nardi, D., Unifying class-based representation formalisms, Journal of Artificial Intelligence Research 11 (1999) 199-240.
22. Carrington, D. A. and Kim, S.-K., Formalizing the UML Class Diagram Using Object-Z, in Proceedings of the Second International Conference on the Unified Modeling Language: Beyond the Standard, LNCS 1723 (1999) 83-98.
23. Chen, P. P., The entity-relationship model—toward a unified view of data, ACM Transaction on Database Systems 1 (1) (1976) 9-36.
24. Cranefield, S., Networked knowledge representation and exchange using UML and RDF, Journal of Digital Information 1(8) (2001).
25. Cranefield, S. and Purvis, M., UML as an ontology modeling language, in Proceedings of the Workshop on Intelligent Information Integration, 16th International Joint Conference on Artificial Intelligence (IJCAI-99), (1999).
26. de Bruijn, J., Lausen, H., Polleres, A., and Fensel, D., The WSML rule languages for the Semantic Web, in Proceedings of the W3C Workshop on Rule Languages for Interoperability, (2005).
27. de Bruijn, J., Polleres, A., Lara, R., and Fensel, D., OWL DL vs. OWL Flight: Conceptual Modeling and Reasoning for the Semantic Web, in Proceedings of the Fourteenth International World Wide Web Conference (WWW2005), 2005.
28. Dobing, B. and Parsons, J., How UML is used, Communication of the ACM 49 (5) (2006) 109-113.
29. Dullea, J. and Song, I., An Analysis of Structural Validity of Ternary Relationships in Entity-Relationship Modeling, in Proceedings of Seventh International Conference on Information and Knowledge Management (CIKM `98) (1998) 331-339.
30. Dullea, J., Song, I., and Lamprou, I., An analysis of structural validity in entity-relationship modeling, Data and Knowledge Engineering 47 (2) (2003) 167-205.
31. Eclipse, http://eclipse-plugins.info/ (2006). 32. Engel, K. and Hartmann, S., Minimal Sample Databases for Global Cardinality Constraint, in
Proceedings of the Second International Symposium on Foundations of Information and Knowledge Systems, LNCS 2284, (2002), 268-288.
33. Engstrom, E. and Krueger, J., Building and Rapidly Evolving Domain-Specific Tools with DOME, in Proceedings of the 2000 IEEE International Symposium on Computer-Aided Control System Design (2000) 83-88.
34. Evans, A. S., Reasoning with UML Class Diagrams, in Proceedings of the Second IEEE Workshop on Industrial Strength Formal Specification Techniques (1998) 102-113.
35. Evans, A. S. and Clark, T., Foundations of the Unified Modeling Language, in Proceedings of the 2nd Northern Formal Methods Workshop (1997).
��
36. Evans, A., France, R., Lano, K., and Rumpe, B., The UML as a formal modeling notation, in Proceedings of the Unifed Modeling Language: the first international workshop, (1998).
37. Falkovych, K., Sabou, M., and Stuckenschmidt H., UML for the Semantic Web: Transformation-Based Approaches, in Knowledge Transformation for the Semantic Web (2003).
38. Franconi, E. and Ng, G., The ICOM Tool for Intelligent Conceptual Modelling, in Proceeding of the Seventh International Workshop on Knowledge Representation meets Databases (2000).
39. Garland, S. J. and Guttag, J. V., An overview of LP, the larch power, in Proceedings of the 3rd international Conference on Rewriting Techniques and Applications (1989) 137-151.
40. Gasevic, D., Djuric, D., Devedzic, V., and Damjanovi, V., Converting UML to OWL ontologies, in Proceedings of the 13th international World Wide Web Conference on Alternate Track Papers &Amp (2004) 488-489.
41. Haarslev, V. and Möller R., RACER System Description, in Proceedings of the International Joint Conference on Automated Reasoning, IJCAR'2001 (2001) 701–705.
42. Halpin, T.A., A Logical Analysis of Information Systems: Static Aspects of the Data-Oriented Perspective, Ph.D. thesis, Department of Computer Science, University of Queensland, Brisbane, Australia (1989).
43. Hartmann, S., Graph-Theoretical Methods to Construct Entity- Relationship Databases, in Proceedings of the 21st international Workshop on Graph-theoretic Concepts in Computer Science, LNCS1017 (1995) 131-145.
44. Hartmann, S., On the Consistency of Int-cardinality Constraints, in Proceedings of the 17th International Conference on Conceptual Modeling, LNCS 1507 (1998)150-163.
45. Hartmann, S., On Interactions of Cardinality Constraints, Key, and Functional Dependencies, in Proceedings of the First International Symposium on Foundations of Information and Knowledge Systems, LNCS 1762 (2000) 136-155.
46. Hartmann, S., Coping with Inconsistent Constraint Specifications, in Proceedings of International Conference on Conceptual Modeling - ER 2001, LNCS 2224 (2001) 241-155.
47. Hartmann, S., On the implication problem for cardinality constraints and functional dependencies, Annals of Mathematics and Artificial Intelligence 33(2-4) (2001) 253-307.
48. Hartmann, S., Soft Constraints and Heuristic Constraint Correction in Entity-Relationship Modelling, in L. Bertossi, G.O.H. Katona, K.-D. Schewe, B. Thalheim, eds., Semantics in Databases (2001).
49. He, X., Formalizing UML class diagrams - a hierarchical predicate transition net approach, in Proceedings of the 24th Annual International Computer Software and Applications Conference (2000) 217-222.
50. Heckel, R. and Voigt H., Towards consistency of web service architectures, in Proceedings of the 7th World Multiconference on Systemics, Cybernetics, and Informatics (2003).
51. Horrocks, I., The FaCT system, in Proceedings of the 2nd International Conference on Analytic Tableaux and Related Methods (TABLEAUX'98), LNCS 1397 (1998) 307-312.
52. Jackson, D. and Rinard, M. Software analysis: a roadmap, in Proceedings of the Conference on the Future of Software Engineering (2004) 133-145.
53. Kabilan, V. and Johannesson, P., UML for Ontology Modeling and Interoperability, CAiSE Workshops (3) (2004) 349-354.
��
54. Kaneiwa, K. and Satoh, K., Consistency checking algorithms for restricted UML class diagrams, in Proceedings of the Fourth International Symposium on Foundations of Information and Knowledge Systems (FoIKS2006), LNCS 3861 (2006) 219–239.
55. Karsai, G., Maroti, M., Ledeczi, A., Gray, J., and Sztipanovits J., Composition and Cloning in Modeling and Meta-Modeling, IEEE Transactions on Control System Technology 12 (2) (2003) 263- 278.
56. Kogut, P. A., Cranefield, S., Hart, L., Dutra, M., Baclawski, K. and Kokar, M. M. and Smith, J. E. UML for Ontology Development, The Knowledge Engineering Review 17 (1) (2002) 61 - 64.
57. Kozlenkov, A. and Zisman, A., Discovering, Recording, and Handling Inconsistencies in Software Specifications, International Journal of Computer and Information Science 5(2) (2004) 89-108.
58. Lange, C.F.J., Chaudron, M.R.V., Muskens J., In Practice: UML Software Architecture and Design Description, IEEE Software 23 (2) (2006) 40-46.
59. Lara, R., Roman, D., P. Axel, Fensel, D., A Conceptual Comparison of WSMO and OWL-S. European Conference on Web Services (ECOWS) (2004), 254-269.
60. Ledeczi A., Bakay A., Maroti M., Volgyesi P., Nordstrom G., Sprinkle J., and Karsai G., Composing Domain-Specific Design Environments, Computer 34 (11) (2001) 44-51.
61. Lenzerini, M. and Nobili, P., On the satisfiability of dependency constraints in entity-relationship schemata, Information Systems 15 (4) (1990) 453-461.
62. Maraee A. and Balaban, M., Efficient Decision of Consistency in UML Diagrams with Constrained Generalization Sets, in Proceedings of the first Workshop on Quality in Modeling, MoDELS, (2006).
63. Maraee, A., Finite Satisfiabilty Problems in UML Class Diagram, Master thesis, Ben-Gurion University of the Negev, (2007).
64. Martin, R.C., UML for Java™ Programmers (Prentice Hall, 2003). 65. MetaEdit, http://www.metacase.com/ (2006) 66. MetaModeling, http://www.metamodel.com/ (2006). 67. Minsky, M. A Framework for Representing Knowledge. Technical Report. UMI Order
Number: AIM-306., Massachusetts Institute of Technology (1974). 68. OMG-UML, UML 2.0 Superstructure (2006). 69. Open Applications Group, http://www.openapplications.org/ (2007). 70. Queralt, A. and Teniente, E., Reasoning on UML Class Diagrams with OCL Constraints, in
Proceedings of 25th International Conference on Conceptual Modeling (ER2006) (2006) 497-512.
71. Rector, A., Drummond, N., Horridge, M., Rogers, J., Knublauch, H., Stevens, R., Wang, H., and Wroe, C., OWL Pizzas: Practical Experience of Teaching OWL-DL: Common Errors & Common Patterns, in Proceedings of the European Conference on Knowledge Acquisition, LNCS 3257 (2004) 63-81.
72. Richters, M. A Precise Approach to Validating UML Models and OCL Constraints. Phd thesis. Universitaet Bremen. Logos Verlag, Berlin, BISS Monographs (14) (2002).
73. RosettaNet, http://www.rosettanet.org (2005). 74. Rumbaugh, J., Jacobson, I, and Booch, G., The Unified Modeling Language Reference
Manual, Second Edition (Addison-Wessly, 2005).
�
75. Satoh, K., Kaneiwa, K., and Uno, T., Contradiction Finding and Minimal Recovery for UML Class Diagrams, in Proceedings of the 21st IEEE International Conference on Automated Software Engineering (2006).
76. Shroff, M. and France R., Towards a Formalization of UML Class Structures in Z, in Proceedings of the 21st International Computer Software and Applications Conference (COMPSAC'97), (1997) 646-651.
77. Sunye, G., Pollet, D., Le Taraon, Y., and Jezkel J.-M., Refactoring UML models. in Proceedings of UML 2001, LNCS 2185 (2001) 134-148.
78. Szlenk, M., Formal Semantics and Reasoning about UML Class Diagram, in IEEE Proceedings of the International Conference on Dependability of Computer Systems (2006) 51-59.
79. Teknowledge, SUMO ontology, http://ontology.teknowledge.com/ (2005). 80. Thalheim, B., Fundamentals of Entity-Relationship Modeling. Annals Mathematics and
Artificial Intelligence 7 (1993) 197-256. 81. Thalheim, B. Entity Relationship Modeling, Foundation of Database Technology, (2000). 82. Thalheim, B., Fundamentals of cardinality constraints, in Proceedings of the 11th
International Conference on the Entity-Relationship Approach (ER-92), LNCS 645 (1992) 7-23.
83. Timm, J.T.E. and Gannod, G., A model-driven approach for specifying semantic web services, in Proceeding of International Conference of Web Services (ICWS), (2005) 313–320.
84. Tsarkov, D. and Horrocks, I., FaCT++ description logic reasoner: System description, in Proceedings of the International Joint Conference on Automated Reasoning (IJCAR 2006), LNCS 4130 (2006) 292-297.
85. Unhelkar, B., Verification and Validation for Quality of UML 2.0 Models (Addison Wesley, 2005).
86. Van Gigch, J. P. System Design Modeling and Metamodeling (Kluwer Academic Publishers, 1991).
87. W3C , OWL-S: Semantic Markup for Web Services , http://www.w3.org/Submission/OWL-S (2004). 88. W3C, OWL, Web Ontology Language Reference, http://www.w3.org/TR/owl-ref/ (2004). 89. Williams H.P., Model Solving in Mathematical Programming (John Wiley and Sons, 1993). 90. Zhihong, Z. and Mingtian, Z., Some considerations in formalizing UML class diagrams with
description logics, in Proceedings of the IEEE International Conference on Robotics, Intelligent Systems and Signal Processing (2003) 111-115.