-Different types of consistency of UML models have been described in the literature. The consistency of UML models with the UML static semantics, usually referred as wellformedness, and the consistency between different versions of the same model are among the most cited. The UML models' well-formedness is a precondition for any other kind of consistency, being described by means of the UML abstract syntax. Unfortunately, this abstract syntax specification is bogus. As a consequence, checking UML models' consistency is not a natural practice, as it should be. Beginning with 2000, there have been several papers reporting this state of facts, but without any visible consequences on the state of practice. In this paper, the authors propose a new approach (including specification techniques and a process) meant to overcome this specification drawback. Our proposal is based on a long practice of improving the specification of UML Well-Formedness Rules in the OCLE tool. Index Terms-UML model consistency, UML abstract syntax, Well-Formedness Rules
The purpose and relevance of the abstract syntax
specification of MOF-based metamodels are explicitly mentioned in all
OMG documents and acknowledged by the entire community
of modelers. As stated in [
Within the abstract syntax specification, the role of the informal (natural language) descriptions is twofold. On the one side, they are used for detailing the structure described by class diagrams, by providing additional information concerning the concepts, attributes and associations involved. On the other, they describe the constraints that should be fulfilled by the modeling concepts, as well as the additional operations used for querying the model or needed in the specification of WFRs. This second role influences both the design of OCL specifications and their validation.
Unlike previous work on the topic, this paper introduces a natural approach concerning the specification of a static semantics. Although the term “approach” may seem a bit pretentious, we claim it is the most adequate, since it refers to a process in which the involvement of the OMG standards’ authors is a must. The gaps and ambiguities residing in the standard specifications cannot be fixed in absence of their authors or in the absence of an explicit, unequivocal description, due to the risk of altering the original intentions. Our proposal takes into account the major differences among the 2.x and 1.x versions of the UML standard.
The reading of the UML 2.x specifications is more
demanding and tedious as compared to the 1.x versions. This
is due to the fact that most of the concepts are progressively
described in several packages, their understanding requiring
the investigation of various diagrams and associated textual
descriptions [
II. UML 2.X ABSTRACT SYNTAX - FROM GOALS TO
STATE OF FACTS
The primary purpose of an abstract syntax definition is
that of providing a complete, non-ambiguous and rigorous
description of a modeling language. These requirements are
mandatory for both the correct understanding and consistent
use of the modeling language, and for enabling conformance
verifications of user-models against it. Failure to fulfill these
requirements triggers inability to fully validate models and
the risk to encounter different interpretations of the same
specifications. Moreover, it compromises the chance to ensure
a safe and predictable model transfer among tools, as required
by [
Modeling languages share far more commonalities than
differences with programming languages. Therefore, similar
to programs, compilability is a mandatory requirement on
models as well. However, the similarity among the two types
of languages does not only involve compilability. Similar
to programs, models should be executable, and the results
should conform to the requirements [
The informal specifications included in the UML 2.x documents (for both WFRs and AOs) fail to comply with the quality requirements mentioned in the beginning of this section. This is a high-priority issue, in our view. In the last UML specification, 2.5, WFRs are compilable - a step forward compared to the previous specification, 2.4.1. However, the runtime testing and debugging issues are much more tedious than the compilability ones, as unanimously acknowledged by software developers. An important cause of the existing errors is the inappropriate informal specification. We will deal with these issues in Section 5 of this paper.
Beginning with 2000, several papers have focused on the specification and usage of WFRs. In the following, we summarize the ones considered to be the closest to our approach.
In [
In [
In [
The consistency among the formal and informal specifications,
the clearness of OCL expressions, the fact that evaluating OCL
specifications instead of only compiling them is imperative, are
among the proposed and exemplified practices. The paper [
[
The common feature of papers published by the teams from Bremen and Dresden is their focus on the compilation phase.
As regarding the papers published by our team, the analysis overpasses the mere compilation. The runtime results and their conformance to the informal specifications are also considered.
In [
Secondly, there are no comments about incorrect rules and about authors’ proposal for improving the existent semantics.
Finally, in [
However, the author is convinced about the importance of
consistency checking in case of UML models.
3) The formal specifications of WFRs must be
testingoriented [
cation patterns is recommended, whenever the case. 6) Indented and syntax highlighted OCL expressions enable an easier lecture of specifications. Prefixing the formal specifications with a short informal description of requirements (similar to comments in programming) is useful, as well. 7) The WFRs which are specified in an informal manner exclusively should be complemented by relevant examples of their fulfillment or failure to be fulfilled, possibly accompanied by an overview of how the authors imagine the validation process. Obeying to this requirement allows a better understanding of the rules and provides support in finding appropriate specification and validation solutions.
Except for the forth recommendation, which seems to be obeyed by almost all specifications of the UML, all the others are not met. As illustrated in the following, taking them into account will help in increasing the quality of the standard specifications.
V. ANALYZING IMPORT RELATIONSHIPS ON UML
NAMESPACES
The import in a namespace of elements from different namespaces is one of the most important relationships in both programming and modeling languages offering modular IV. THE PROPOSED APPROACH FOR SPECIFYING THE development support. This allows the imported elements to
ABSTRACT SYNTAX be directly referred by their name or by an alias, whenever The state of facts in specifying the abstract syntax of UML, there is no name conflict among the imported elements and together with a thorough analysis of the published literature on the elements belonging to the namespace which performs the the topic allow us to argue that a significant amount of all the import. In case of conflict, the use of a qualified name is existing specification errors are due to failure in obeying to a mandatory. The programming languages come with clear specnumber of elementary requirements, validated by the software ifications concerning the import relationship. Thus, we argue engineering practice. Given our experience in the field, we that any differences in the import rules specified for UML propose conforming to the following rules when specifying and MOF compared to the programming languages should be the abstract syntax of UML/MOF. clearly justified. Even more, examples are needed to illustrate 1) A complete and non-ambiguous informal equivalent of the manner in which various cases tolerated by modeling all OCL specifications (both WFRs and AOs) is the languages can be coded in a programming language (direct first and the most important of these rules. Moreover, engineering) or the reverse (reverse engineering). Otherwise, there should exist a full conformance among the in- the support offered by modeling languages to the MDA, MDE formal specification and its formal correspondent. It and MDD paradigms remains only in statements. would be helpful if the informal specification would Similar to programming languages, the UML allows two be accompanied (possibly in an attached document) by types of import: examples illustrating cases of validation and invalidation 1) explicit, by defining an individual import relationof each rule, as well as exceptional cases that may arise ship for each imported element (which should be a throughout the evaluation of AOs. PackageableElement). Such an import relationship 2) Runtime validation of formal specifications on signifi- is modeled by the ElementImport concept (direct cant data sets (models) is mandatory. Mere compilability descendent of DirectedRelationship), that has is not enough. two attributes: visibility and alias. Graphically, ElementImport is represented by a “a dashed arrow with an open arrowhead from the importing namespace to the imported element. The keyword import is shown near the dashed arrow if the visibility is public, otherwise the keyword access is shown to indicate private visibility. If an element import has an alias, this is used in lieu of the name of the imported element. The aliased name may be shown after or below the keyword import.” 2) implicit, by means of an import relationship among the importing namespace and the imported package. “Conceptually, a package import is equivalent to having an element import to each individual member of the imported namespace, unless there is already a separately-defined element import.” Similar to the case of an element import, this relationship is modeled by the PackageImport metaclass, having an analogous graphical representation. It “is shown using a dashed arrow with an open arrowhead from the importing package to the imported package. A keyword is shown near the dashed arrow to identify which kind of package import that is intended. The predefined keywords are import for a public package import, and access for a private package import.”
The concepts involved in the import relationships and their interconnections are illustrated in Figure 1. Even if not explicitly stated, the set importedMember is needed when computing the set of potential servers of a model element or when checking if an element is legally imported.
In the following, we will analyze the formal OCL specifications (and their informal descriptions) regarding the import relationship defined between a Namespace and a PackageableElement or a Package.
In the Namespace context, the AO getNamesOfMember() previously specified in the NamedElement context “is overridden to take account of importing. It gives back the set of names that an element would have in an importing namespace, either because it is owned; or if not owned, then imported individually; or if not individually, then from a package.”
In our opinion, the last part of the second phrase (marked by the underlined words) is a bit confusing. A clearer and more explicit statement (at least for a non-native speaker) could be: either because it is owned, or imported individually or by a package import.
Following, there is the corresponding OCL specification, as provided in the standard. qualified name outside the owner package. That is why, at the Namespace : : getNamesOfMember ( e l e m e n t : NamedElement ) : S t r i n g [ 0 . . ∗ ] ; beginning of this section, we have emphasized the necessity of getNamesOfMember = an explicit description of the rationale behind certain decisions. tihf ens e Slfe t. {owe lneemdMe nemt.bnear−m>e}i n c l u d e s ( e l e m e n t ) Secondly, it is easy to notice that the formal specificae l s e l e t e l e m e n t I m p o r t s : Set ( E l e m e n t I m p o r t )= s e l f . e l e m e n t I m p o r t tion does not comply with the informal one, since only the i f e−l >ems ee nlet Ic mt(peoir |tse−i>. nimotpEomr tpetdyE( )le m e n t = e l e m e n t ) i n visibilities of elementImport and packageImport are then e l e m e n t I m p o r t s−>c o l l e c t ( e l | e l . getName ( ) ) considered, without taking into account the visibility of the e l s e s e l f . packageImport−>s e l e c t ( p i | p i . i m p o r t e d P a c k a g e . v i s i b l e M e m b e r s ()−> i n c l u d e s ( e l e m e n t ) ) element itself (irrespective if it being owned by the package, −>c o l l e c t ( p i | p i . i m p o r t e d P a c k a g e . getNamesOfMember ( imported individually or by means of a package import). Moree n d i f e l e m e n t ))−> a s S e t over, the authors of the OMG specification say nothing with e n d i f respect to what happens in particular cases, such as the one in which the same element is imported both individually (with
In [
In the Package context, the query visibleMembers() model shown in Figure 2. As illustrated there, between
identifies those members of a Package that can be accessed packages P2 and P1 there is an <<import>> relationship.
outside it. The specification provided for the AO visibleMem- The package P1 owns the class A having visibility
bers() in [
The query makesVisible() specified itself in the Thirdly, when the element is imported in the package Package context, “defines whether a Package makes an by packageImport, the result returned will be wrong element visible outside itself. Elements with no visibility and if the visibility of the element transmitted by parameter elements with public visibility are made visible.”. (el) is VisibilityKind::private. A sample situation Package : : m a k e s V i s i b l e ( e l : Namespaces : : NamedElement ) : Boolean ; is illustrated in Figure 3. In the package P2, the private pre : s e l f . member−>i n c l u d e s ( e l ) class A is imported by the importPackage relationship m −a−ke stVh eis ieblleem=e n t i s i n t h e package stereotyped <<import>>. In P3, private class A is im( ownedMember−>i n c l u d e s ( e l ) ) or ported by means of the importPackage relationship, also −(−e l ei mt e nist I mi mp oprotr−t >eds e il ne cdti v( iedi u| aeil l. yv i wsii tbhi l iptuyb l=i c v i s i b i l i t y stereotyped <<import>>, between P3 and P2. In the OCL V i s i b i l i t y K i n d : : p u b l i c)−> c o l l e c t ( i m p o r t e d E l e m e n t . oclAsType ( specification of Package::makesVisible (see above), −− i t NisamiemdpEoler mteednt)t)h−r >ouignhc l uad epsac(keal g) e) owri t h p u b l i c v i s i b i l i t y this corresponds to the OCL expression following the second ( packageImport−>s e l e c t ( p i | p i . v i s i b i l i t y = or (imported through a package with public visibility). Similar pVii.siimb iploirttyeKd Pinadc k: a: gpeu.bml iecm)−be>r−c>oilnl ec lcut d( epsi |( e l ))−>notEmpty ( ) ) to the previous case, the result is wrong, due to the visibility of class A.
As regarding this specification, there are some things we Concluding, we notice that even though the would like to analyze. makesVisible() AO is compilable, its returned results do
Firstly, the informal specification states that “Elements not fully comply with the informal specification. Even more, with no visibility and elements with public visibility are the usefulness of elements with no visibility has not been made visible.” As no explanation is offered regarding why explained and taken into account in the formal specification. elements with no visibility are visible outside the package, Apart of these, there could be particular cases, like those this requirement seems strange to us. Especially since in pro- mentioned above, when the results are debatable. gramming languages (Java, for instance) only public members A possible solution would be to include in the precondition of a package can be explicitly exported or referred by their the restriction regarding the visibility of el.
Since we have no idea about the semantics of el.visibility.oclIsUndefined in this case, and due to other particular cases, our opinion is that the first thing to do is to clarify the informal specification.
In a namespace, a NamedElement is valid if it is
distinguishable from any other element owned by the
namespace [
ns : Namespace ) : Boolean def : i s D i s t i n g u i s h a b l e F r o m ( n : NamedElement ,
ns : Namespace ) : Boolean = i f s e l f . o c l I s K i n d O f ( n . oclType ) or
n . o c l I s K i n d O f ( s e l f . oclType ) then ns . getNamesOfMember ( s e l f )−> i n t e r s e c t i o n (
ns . getNamesOfMember ( n))−>isEmpty ( ) e l s e t r u e e n d i f
The formal specification fully complies with the informal requirements. However, stating that two elements having unrelated types are distinguishable could cause unpleasant situations, such as the one in which a package contains both a class and an enumeration having the same name (e.g Test). In this case, enumeration.oclIsKindOf(class.oclType) and class.oclIsKindOf(enumeration.oclType) are always evaluated to false, irrespective of the enumeration instance of the metaclass Enumeration and class instance of the metaclass Class (see Figures 4 and 5). By consequence, the type of an attribute testKind:Test belonging to a different class of the same package is uncertain. This is due to the fact that we cannot distinguish between these two types having the same name. In order to fix this bug, the simplest solution would be to remove “part a)” from the above requirements. However, the best decision would be to provide a clearer specification, including suggestive examples of models with both distinguishable and not distinguishable named elements.
The visibleMembers() AO analyzed at the beginning of this section is used by composition in computing the set of elements imported in a namespace.
“The importedMember property is derived from the ElementImports and the PackageImports.” importedMember = s e l f . e l e m e n t I m p o r t . importedElement−>a s S e t ( ) −>union ( s e l f . p a c k a g e I m p o r t . importedPackage−>c o l l e c t ( p | p . v i s i b l e M e m b e r s ())−> a s S e t ( ) )
Here, the drawback is due to previously-discussed visibleMembers(). Another problem is that both in case of a direct elementImport and packageImport, we have to consider also the elements having visibility = VisibilityKind::private and marked with the stereotype <<access>>, not only those marked with <<import>>. That is why, the importedMember in the P3 namespace of Figure 6, will return Set{A, C, B, D, E}, so the visibleMembers() has a negative influence by means of <<access>> packageImport also.
Since in case of name-clashes the imported elements can be referred only by means of their qualifiedName, let us take a short look at the derived attribute qualifiedName, specified in the NamedElement metaclass. In the standard it is stated that this attribute “is constructed from the names of the containing namespaces starting at the root of the hierarchy and ending with the name of the NamedElement itself.” The specification of the qualifiedName():String AO is: body : i f s e l f . name<>n u l l and s e l f . a l l N a m e s p a c e s()−> s e l e c t ( ns |
ns . name= n u l l)−>isEmpty ( ) then s e l f . a l l N a m e s p a c e s()−> i t e r a t e ( ns : Namespace ; agg : S t r i n g = s e l f . name | ns . name . c o n c a t ( s e l f . s e p a r a t o r ( ) ) . c o n c a t ( agg ) ) e l s e n u l l e n d i f . 5 .
T h e
C l a s s e s d i a g r a m o f t h e
C
o
n
s
tr
u
c
t
s
p
a
c
k
a
g
e
f
r
o
m
[
F g u r e 1 1 P2 iv a A < < p r t e > > P 1 C < < p r iv a t e > >
B < < imp o rt > > < < a c c e s s > >
P 3 < < a c c e s s > > < < imp o rt > > While this specification is compilable and
roughly correct, there can arise a little problem, because empty String is not forbidden as a name value, and self.’’->notEmpty() = true, the value computed for qualifiedName in such cases, is meaningless. That is why, such cases must be forbidden. More general, we consider that rules similar to those applied in programming languages must be used in modeling language as well.
The aspects analyzed in this section prove that, even in simple cases, the specifications must be realized carefully, not in a superficial manner. The reccomendations made in the previous section must be taken into acount.
The purpose of this paper has been to propose a change of attitude with respect to the definition of the UML’s abstract syntax, expected to positively affect the quality of the standard specifications. This improvement is a “sine qua non” condition for attaining the target of model-driven technologies and paradigms.
Our proposal is argued by means of meaningful examples
taken from the latest UML specification [
Another important message is that the mere compilability
of formal specifications does not value much if these
specifications are not validated on comprehensive models.
Technical aspects related to the particularities of the specification
language and the support that the formal specification style
brings in achieving compilable models are important as well.
In this respect, we recommend the adoption of a
testingoriented specification style, as introduced in [
Apart from the advice related to the specification style, all the others have been validated in Software Engineering. That is why, noticing that so much good specification practice has not been considered comes as an unpleasant surprise.
Achieving a good specification of MOF-based languages is a tedious process, requiring a quality feedback both from scientists and users. Our intent has been to make a first step, by proposing a set of “good practices” to be considered in the process, as well as a number of examples supporting our proposal. Hoping that our proposals will be analyzed, improved and extended by the OMG and thus a better abstract syntax specification will support a more efficient and widespread usage of modeling languages.