I'm struggling to find a way to navigate through association class to create constraints
I checked on the specification here: https://www.omg.org/spec/OCL/About-OCL/
It's says:
Let say I have this class diagram:
And this object diagram:
As you can see I created a constraint in the context of class A (just below the name of the class), I tried with lower "c" and upper "C", neither work...
Context A:
inv: self.C[b].val.mod(2) = 0
(The meaning of the constraint is not important, i just would like to make it work)
When I execute the validation process I get this error:
"Expression has errors: Semantic errors at [0:5]: Unrecognized variable: (C)"
This error message seems to be logic as I don't see an attribute "c" or "C" either in the object of type A, but I don't understand why it's that so.
Am I doing something wrong ?
I don't understand why it doesn't work as I respected the syntax described in the specification.
For information:
I use:
magic draw: v18.5
OCL: 2.0
Thank you by advance !
You looking at a very dark corner. My first attempts at actually testing this functionality foundered on a failure to find a UML tool that could actually draw Fig 7.1. Once I got to grips with the text I realized there are many problems; a potential conflict between two different x[y] syntaxes, further aggravated by a QVTo shortform. There is a problem with extension to more than binary associations. The OCL Abstract Syntax continues to use the UML 1.x concepts of AssociationEnd rather than the UML 2.x Property.
Consequently the functionality you observe is the result of the best endeavours of some tool vendor to make sense of a very inadequate specification.
With MagicDraw, you used to be using Dresden OCL, but I understand that MagicDraw has switched to Eclipse OCL, perhaps the Classic Eclipse OCL. NoMagic seem remarkably reticent in crediting the open source software they redistribute.
For the newer Pivot Eclipse OCL where I prototype solutions to many of the OMG OCL problems, the UML to Pivot loading normalises many of the UML concepts so that Associations are redundant, unless an exoplicit navigation to the Association requires an Association Class to be reified. AssociationClasses are normalized to Association Classes with ordinary Properties for each plausible navigation.
I think that your expression is incorrect.
self.C[b] cannot be a qualified association since the implicit A::C property has no key.
self.C[b] could be a disambiguated navigation A::C where the ambiguity of A::C is resolved by selecting the C::b opposite. But A::C is not ambiguous and its opposite is C::a. So self.C should be adequate, self.C[a] is redundant, self.C[b] is wrong wrt the b. Sadly your tooling dislikes self.C so your tooling is defective.
I think you should have written self.C.val.mod(2) = 0.
Uppercase C is correct. Lowercase was misguidedly suggested by OCL <= 2.2 following the UML style guide. See indented paragraph under "Missing Association End names" in 7.5.4 of OCL 2.4.
Related
I am trying to create UML diagram. For example I have a class A with method a() and class B that extends A and overrides method a(). Is there any standard to indicate overridden methods in UML?
No, there is no specific indicator for operations that override operations on a parent class.
If the signature matches it overrides the operation on the parent.
The norms says on p. 101:
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited members. A conforming implementation does not need to provide this option.
Sadly, my tool (EA) does not support that.
The simplest method is to duplicate only the operation signatures of those operations you are going to override. That will make it clear that you are overidding something.
By just looking to Class2 there is no way to tell that b is actually an override. However, if someone wants to deal with Class2 he must know that it's a subclass - and thus will know that b is an override.
Note: The UML 2.5 specs are ambigous about the caret use. While (on p. 100) they say
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol ...
the syntax below explictely mentions only properties and connectors and this passage
Analogous notations may be used for all NamedElements that are inheritedMembers of a Classifier to indicate that they are inherited.
As indicated in that answer https://stackoverflow.com/a/28932482/2458991 there is a specific indicator to indicate a member (for instance an operation) is inherited, but that indicator is not mandatory, the norm says :
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol to the textual representation that would be shown if the member were not inherited.
So, having :
B does not override oper
But having :
we cannot know except if we are sure the ^ is always used in the model as in previous diagram
[edit]
Notice the norm use two times the words member (and not properties) in that sentence, and Class inherits (indirectly) Classifier, so that applies for operations.
As noticed in an other answer the norm says also :
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited **members*.
so again two times members rather than properties, and the fact they use also clearly reference the fact there is an other way which is the ^. So two consistent sentences indicating ^ applies to operations
[warning]
I used BoUML to make the diagrams and in the first you can see "^oper()" but I 'cheated' to do that naming the corresponding operation "^oper", there is no option to show a ^ in a diagram to indicate an operation or other member is inherited
Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html
Let's say I have class Foo that has an association to some thing(s) that fulfill(s) a role. This role could be fulfilled by either (strictly) one Bar xor any number of Baz. Similarly, the role might be fulfilled by either any number or Bar xor any number of Baz (but a mixed collection is intolerable). Are there reasonable ways to represent these in a class diagram using only associations, classes, and interfaces? I would (really) like to avoid using OCL or constraint elements.
(The reason I would like to avoid these is because we are generating code from our UML. We have already implemented generation that handles associations, classes, and interfaces. Dealing with OCL would be quite the task. Constraint elements wouldn't be so bad but still quite a lot of work.)
I would start with the picture below and create several different versions before deciding which one generates best code (junior-40).
The yellow blocks represent necessary "glue code" needed to straighten your example against your other requirements
Consider creating an abstract class Thing and derive Bar and Baz from it. It abstract the whole role, can contain some own atts and methods if needed and is quite flexible and extendible.
Now Account has an association only with AccountOwner (role "role", as Jim L. has explained in his comment, a role name must be unique in this context).
Note that this does not eliminate the need of some additional restrictions. For example, all linked "roles" should be of the same type. Sometimes is not easy (or even possible) to remove all restrictions. Otherwise we would make complete systems out of class diagram. I agree though, that as much information as possible should be contained in classes, their taxonomies and features (atts, assocs and methods).
EXAMPLE:
EXAMPLE 2 (after comments):
This version overcomes the need to use OCL ant yet keeps the simplicity and flexibility:
Multiplicities are now also derived and refined for each concrete "role". No OCL needed. :)
You add a constraint on the class in OCL:
(self.role->exists(r|r.oclIsType(Bar)) and self.role->notexists(r|r.oclIsType(Baz)) ) or
(self.role->exists(r|r.oclIsType(Baz)) and self.role->notexists(r|r.oclIsType(Bar)))
You can try this out with MDriven Designer.
The reason for introducing OCL (object constraint language) in the UML specification was just this; ability to add constraint not possible or practical to convey with simple cardinality and type information
Could this image help you ? It is extracted from the norm.
Are you thinking of something like the following:
(source: uml-diagrams.org)
Where Account is your Foo, Person is your Bar, and Corporation is your Baz.
You can then specify multiplicity on each of the two associations: [1] for Bar (Person) and [1..*] for Baz (Corporation).
I came across the following description of IsRoot, IsAbstract & IsLeaf however do not understand when you would used them.
Excerpt from http://www2.sys-con.com/itsg/virtualcd/dotnet/archives/0108/clark/index.htm:
By checking the IsRoot check box, you are restricting the class from inheriting from other classes. Checking IsAbstract restricts the class from being instantiated, and forces clients to instantiate a derived class to access the functionality of the class. Checking IsLeaf indicates that the class is sealed. Sealed classes are noninheritable and help to limit the depth of an inheritance chain.
My understanding
IsRoot seems to suggest that it is a superclass
IsAbstract seems to suggest it is an abstract class
IsLeaf is a class that cannot be inherited but can be instantiated.
Can someone give me a real-world example of a model that uses these? For example I can imagine class such as 'car' that is a superclass and is abstract and beneath it you would have classes such as 'Volvo', 'Chevrolet', etc.
isRoot no longer exists in UML2. In UML 1 it means (from the specification) :
isRoot: Specifies whether the GeneralizableElement is a root
GeneralizableElement with no ancestors. True indicates that it
may not have ancestors, false indicates that it may have ancestors
(whether or not it actually has any ancestors at the moment).
isAbstract means that the element is incomplete and cannot be instantiated.
If true, the Classifier does not provide a complete declaration and can typically not be instantiated. An abstract
classifier is intended to be used by other classifiers (e.g., as the target of general metarelationships or generalization
relationships). Default value is false.
isLeaf means that you cannot redefine the element, same as final in some programming languages.
Indicates whether it is possible to further redefine a RedefinableElement. If the value is true, then it is not possible to
further redefine the RedefinableElement. Default
value is false.
Not real-life examples, but links to some.
isRoot: I think this is no longer part of UML. That article is from 2004, which was around the time UML 2 came out, and I doubt Visio supported it. It still may not support it.
isAbstract: it's a good idea to make all superclasses abstract so that you cannot create an instance that is not a member of the subclasses. Classes are essentially sets of instances. What does it mean for an instance to be a member of a superset and none of the subsets? It's unclear exactly what the classification of such an instance is, and it may inadvertently change over time. It's also a good idea to make the subclasses disjoint (non-overlapping) and covering (all known subclasses specified). There's more details and a real-life example of this using Avians in Lahman's book.
isLeaf: essentially keeps people from overriding your code. I can't verify this quotation, but supposedly the The Unified Modeling Language Reference Manual says:
Being a leaf or being constrained to be a leaf are not fundamental
semantic properties but rather software engineering mechanisms to
control human behavior.
Does that help?
hi every body i'm trying to understand UML but there are some questions about it
In UML what is the significance of tagging a class with the stereotype <<abstract>>?
and how to express this constraint as an invariant,
A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
or in ocl for MyAbstractClass holds
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:
First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.
Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.
But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).
An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.
I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.
Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.
Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.
Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.
A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).
Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:
UML keywords are reserved words that are an integral part of the UML
notation and normally appear as text annotations attached to a UML
graphic element or as part of a text line in a UML diagram. These
words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of
the model. For example, the keyword “trace” is a system-defined
stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and,
therefore, cannot be used to define any user-defined stereotype.
In UML, keywords are used for four different purposes:
To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...
To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...
To specify the value of some modifier attached to a UML concept (meta-attribute value)...
To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:
Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
words appearing in guillemets do not necessarily represent stereotypes.
In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.
In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:
Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.
I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or
specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.
So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.