In the OCL specification, properties of Collections like
'isEmpty', 'size' etc. are defined as operations with
pre and postconditions. Their syntax however is as attributes without
parenthesis.
For consistency it would be more clear to change the sytax of these
predefined operations to use parenthesis as in 'isEmpty()', just
like other operations.
The same holds for operations on other predefined types like
Real::floor.

No Data Available

Summary: A package is a grouping of model elements. However, the rectangular shape of the package symbol makes it difficult to group model elements that have fixed geometrical position to each-other. In other words, the rectangular package shape often requires to change geometrical position of the model elements that belong to the group. It is almost impossible to use the rectangular package to show overlapping groups of model elements.

For example, it is difficult to use the rectangular package symbol to show the objects in a class diagram that belong to a certain thread, or to show the use cases in a use case diagram that belong to a certain group.

declined

Association generalization has notation but no semantics.

The notation document says:

[p 3-80] Generalization may be applied to associations as well as
classes, although the notation may be messy because of the multiple
lines. An association can be shown as an association class for the
purpose of attaching generalization arrows.

But no semantics is defined for association generalization. That's why
it's on the UML 2.0 roadmap. The above should be removed for 1.4.

No Data Available

Ordering of attribute values

Link ends can be ordered, by setting the ordering metaattibute of
AssociationEnd to "ordered". But attribute values currently cannot be
ordered. The metaclass StructuralFeature should have an ordering
metaattribute.

No Data Available

The unary prefix operator "-" is missing in the definition of the OCL
type "Real". It only defines binary "-".

No Data Available

Multiple languages for uninterpreted strings

The various places that uninterpreted strings are used in UML should
support multiple languages. For example, the Expression metaclass has
an metaattribute for language and another for the uninterpreted string.
This should be a set of such pairs. Then code generators can target
multiple languages from the same model.

duplicate of 3391

Changeability in associations

Changeability as currently described does not make sense when applied to
associations. It is summarized as:

[p 2-21] When placed on a target end, specifies whether an instance of
the Association may be modified from the source end. Possibilities
are:

What does "modified from the source end" mean?

[p 2-21] frozen - No links may be added after the creation of the
source object.

[p 2-57] the link cannot be modified once it has been initialized
(frozen).

No links may be added to what? The source/target objects, the link
itself? See below for the conflicting answers:

[p 2-21] addOnly - Links may be added at any time from the source
object, but once created a link may not be removed from the
source end.

[p 2-57] new links of the association may be added but not removed or
altered (addOnly)

Again, what does it mean to modify an association from "an end"? It
doesn't mean the objects at the ends, according to this:

These constraints do not affect the modifiability of the objects
themselves that are attached to the links. Moreover, t ) the
classifier, or (a child of) the classifier itself.

(The second sentence has too many typos to understand).

Finally, compare the above to:

An association-end also specifies whether or not an instance playing
that role in a connection may be replaced by another instance. It may
state that no constraints exist (changeable), that the link cannot be
modified once it has been initialized (frozen), or that new links of
the association may be added but not removed or altered (addOnly).

The first sentence implies the link is what is frozen, but that isn't
consistent with the last sentence.

No Data Available

In OCL versions prior to UML 1.3, type names had to begin with a
upper-case character. This was changed, and the rules for typeName and
name are now identical.
Unfortunately, this introduces an ambiguity into the OCL grammar rule
pathName.
pathName := (<typeName> | <name>) ("::" (<typeName> | <name>))*

This problem could be solved by dropping the distinction between names
and type name completely. The path name rule could be changed to:
pathName := <name> ("::" <name>)*

Now, the problem arises that it is not possible to distinguish between
property accesses and type literals if they have the same name. For
example, consider the following UML model:

• Classes TypeA, typeB, TypeC
• Association between TypeA and TypeC, association end at TypeC is
  named typeB.
  The expression "typeB" in the context of "TypeA" might either be
  interpreted as a navigation to the association end
  "typeB", and hence result in an object of "TypeC", or as the type
  "typeB".

No Data Available

he term "navigation context" is used to denote the
start of an OCL navigation expression. The standard navigation context
is "self", or the iterator name in a subexpression
that is the argument to collection operations like "forAll".

The standard navigation context in the argument expression of the
operation "iterate" is not clearly defined in the OCL specification. It
might either be the iterator or the accumulator.

Proposed solution:
Since none of these alternatives is clearly more intuitive than the
other, we would favour to demand the explicit qualification of the
navigation context in iterate's argument expression through either the
iterator or accumulator name or "self".

It might be noted that similarly, the default navigation context is not
clear if the operation "forAll" is used with two or more iterators.

No Data Available

The collection operations "iterate", "forAll", "exists",
"select", "reject", and "collect" can have declarators.
Declarators should also be allowed for "sortedBy" and "isUnique",
or, more generally, for all collection operations
with an OclExpression as parameter. This is not stated clearly stated by
the specification, though it's propably intended.

No Data Available

The declarators for the collection operation "iterate" have a different
format than those for "forAll" and other operations. The specification´s
grammar allows only the form used with "forAll". The production rule
"declarator" should be updated as follows:

declarator :=
( name ("," name)* (":" simpleTypeSpecifier)? "|" ) |
( name ":" simpleTypeSpecifier ";" name simpleTypeSpecifier "="
expression "|" )

No Data Available

The OCL specification defines a precedence of "<", ">", "<=" and
">=" over "=" and "<>". This is misleading, because the OCL
grammar does not allow relational expression with more than one
relational operator, so that expressions like "a>b = c<d" are illegal
anyway.

Proposed Solution: Change the precedence rules to define that "<", ">",
"<=", ">=", "=" and "<>" have the same precedence.

No Data Available

In 2.10.4, semantics of Collaboration, the 1st sentence is confusing. It should be "The term instance of a collaboration (also collaboration instance) denotes the set of instances of Classifiers that play roles defined by ClassifierRoles in one specific collaboration specification."

No Data Available

Page 2-114, 2nd paragraph. It should be collaboration template rather than template collaboration. This distinction is important: a template is not a special form of the templatized model element. (Much like a process description is not a described process or a painted car is not car paint).

fixed

5. In 2.10.2 and 2.10.4, the words "classifier roles", "ClassifierRoles" and "instances of ClassifierRole" are used interchangeably. I suggest to stick to one way of doing it and avoid the others.

fixed

In 2.10.5, you give pattern a non-standard definition. A pattern is not a formal template. For any given design pattern, there may be any number of collaboration templates that represent a category of design structures that will be considered pattern instances by experts. So the relationship between design pattern and collaboration template is 1 to n, similar to the relationship between collaboration specification template and collaboration specification.

No Data Available

Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Class".

No Data Available

suggest to stick with one consistent terminology and avoid imprecise variations and synonyms.

2.1 Collaboration should be a shortcut for Collaboration Specification. Frequently, however, it also means Collaboration Instance. Here, I suggest to drop the rather awkward "collaboration (diagram) on a specification level" and make it collaboration specification, etc.

2.2 IMO, it should be collaboration template rather than template collaboration or parameterized collaboration. First of all, a template collaboration is a collaboration, not a template, so this is confusing. Also, should UML 2.0 solve the template problem in ModelElement, it will be the natural thing anyway.

No Data Available

4. In 2.10.2, the use of the phrase "In the metamodel..." is unclear to me. (It typically starts the second paragraph of a concept definition. Using ClassifierRole as the example, it should be "In a model, an (instance of) ClassifierRole specifies".

No Data Available

3. It is unclear to me, why AssociationRole is a subtype of Association, and, similarly, why AssociationEndRole is a subtype of AssociationEnd. The resulting recursive relationship suggests that AssociationRoles can serve as the base for further AssociationRoles, the meaning of which is unclear to me. (Some people suggest to have roles of roles, but I think this confuses concepts.)

No Data Available

2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

fixed

1. I suggest to consistently use "collaboration specification" and "collaboration instance" rather than the awkward "collaboration diagram on an instance or specification level". The use of "collaboration" should probably be discouraged. If it cannot be avoided, it should default to "collaboration specification".

No Data Available

The current UML definition of design pattern is oversimplifying the situation. The relationship between a design pattern and collaboration template is 1 to n. For any given design pattern, you can find any number of templates as formal abstract specifications of specific collaboration specifications.

The structure diagram in the GOF book illustrates one common abstract form of the design pattern, but certainly not the only one. Other variants, typically more complex ones, are hidden in the implementation section. The reason for this: in the opinion of its fathers, design patterns can not be formalized.

The best way to escape the debate of whether to formalize or not is to distinguish between a non-formalizable pattern and formalizable templates. This is also how people do it in practice, if you take a look at the many different abstract descriptions (= templates) of, say, the Observer pattern.

No Data Available

During a discussion of "physical" metamodel (i.e., the MOF-compliant
metamodel) issues, the following data types defined in the logical
metamodel Data Types package were identified as unused anywhere else:

o MessageDirectionKind
o Time
o Mapping
o TypeExpression

This note responds to an action to search the UML Specification document
to make sure this is actually true before we consider removing them from
the logical model. I performed this search by doing using the Acrobat
"Find" command on the PDF file for the UML Specification, which also
searches the diagrams.

o MessageDirectionKind: This data type is actually described in the
semantics as "no longer used in UML." And, indeed, it appears no where
in the document outside of the Data Types section, except for the index
and the parts of the IDL and the physical metamodel generated from the
Data Types package.

o Time: This data type is only referenced in the logical metamodel in
the text of the definition of a TimeExpression: "In the metamodel
TimeExpression defines a statement which will evaluate to an instance of
Time when it is evaluated." Thus, this type is not really necessary for
defining the metamodel, since TimeExpression is not further specified
(this will probably have to be dealt with as part of the action
semantics work.) In the IDL, the Time data type is implemented as
"UmlTime", which is a typedef of float. It appears as Time in the
physical metamodel.

o Mapping: This data type is only reference in the logical metamodel in
the text of the definition of a MappingExpression: "An expression that
evaluates to a mapping." As with Time, this type is not really necessary
for defining the metamodel, since the form of its "body" is not further
specified. It is implemented as a string in the IDL, but has no body
attribute in the physical metamodel.

o TypeExpression: This data type appears nowhere else in the Semantics
chapter than the Data Types section (except for the index). However, in
Notation Guide states:

"The type of an attribute is a TypeExpression. It may resolve to a class
name or it may be complex, such as array[String] of Point. In any case,
the details of the attribute type expressions are not specified by UML.
They depend on the expression syntax supported by the particular
specification or programming language being used."

Unfortunately, the abstract syntax requires that the type of an
attribute (or any structural feature) by a classifier (see Section
2.5.2). There is thus no way to map the notation for an attribute,
unless the type expression happens to be the name of a classifier. The
use of a general type expression is desirable, so this should be
corrected.

(One possible approach, which would preserve the definition of an
attribute type as a classifier, would be to make TypeExpression a child
of Classifier as well as Expression. This could also be useful on
instance diagrams, since it would allow one to show instances of
implementation-specific type expressions.)

No Data Available

The contents of a package (i.e. the ownedElements of the Namespace of
the the package) can be shown in two different ways: either enclosed by
the package symbol or attached with the encircled plus sign (figure 3-6
in the Notation Guide).

Even though classes are also namespaces, then the same options do not
apply for them. In fact there is no notation for this at all. It is
possible to have class boxes enclosed by a class box, but it has another
mapping than notation elements being enclosed graphically by a package
symbol: according to 3.47.5 of the Notation Guide "A class box with
contained class boxes maps into a set of composition associations;".

One may argue that packages are different from classes, but subsystems
come close to objects. A Subsystem (in its capacity of being a Package)
have the two options of showing the contents, i.e. it is possible to
have class boxes within the Subsystem symbol. The meaning of this should
be (according to the text on Package) that the classes are defined
within the Subsystem. However, the Semantics of Subsystem says that "the
semantics of an instantiable susbsystem is similar to the semantics of a
composite class", which means that the enclosed class boxes should be
interpreted in the same way as for class boxes enclosed by a class
boxes.

The enhancement of this should be that notation for namespace
"containment" (ownedElement) and object containment (composition) should
be clarified and made similar for similar concepts.

No Data Available

This should refer to "exit" not entry:

[p 134] An optional action that is executed whenever this state
is exited regardless of which transition was taken out of the
state. If defined, entry actions are always executed to
completion only after all internal activities and transition
actions have completed execution.

No Data Available

[p 109, semantics] the former roles may possibly be
specialized with new features (as classifier roles are also
generalizable elements).

The parenthetical remark is misleading. Classifier roles are
not allowed to have features of their own (see OCL on
ClassifierRole). They only have links to features, ie,
instances of the meta-association between ClassifierRole and
Feature. These links don't automatically inherit to children
of a ClassifierRole, because inheritance only applies to actual
features of the role, which it isn't allowed to have. So the
fact that classifier roles are generalizable elements doesn't
achieve the inheritance of the links to features. That is a
behavior introduced by role specialization.

No Data Available

Figure 3-56, p 117 of the collaboration notation, it intended to
give an example of constraining elements, but it shows
generalization relationships between roles instead. I thought
the constraining elements would refer to the base classifiers and
associations, not the roles. Using generalization links between
roles has a different semantics than between the base classifiers
(see Semantics of Collaboration 2, above).

No Data Available

[p 126, notation] A signature is a string that indicates the
name, the arguments, and the return value of an Operation, a
Message, or a Signal.

Messages don't have signatures. "Message" can be dropped from
the above sentence.

No Data Available

[p 125, notation] predecessor guard-condition
sequence-expression return-value := message-name
argument-list

The descriptions after this imply that "predecessor" and "guard
condition" are the same:

[p 125, notation] The meaning is that the Message is not
enabled until all of the communications whose sequence
numbers appear in the list have occurred (once the
communication has occurred the guard remains
satisfied). Therefore, the guard condition represents a
synchronization of threads.

It's confusing the have two names for the same thing. I
thought on first glance that some bracketed notation as in
state machine were supported at this position in the label, but
that is in the recurrence part of sequence expressions.

No Data Available

[p 122] A multi-object symbol maps to a set of Objects that
together conforms to a ClassifierRole with multiplicity
"many".

There is no construct for "set" in UML.

No Data Available

The Constraint meta-type, in the Extension Mechanisms meta-model, has
two associations with the same association end name on the "opposite"
ends ("constrainedElement"). Assuming that UML meta-classifiers should
adhere to the OCL for regular classifiers, then this is ill-formed
according to OCL 3 of Classifier, p 47:

[3] No opposite AssociationEnds may have the same name within a Classifier.

self.oppositeEnds->forAll ( p, q | p.name = q.name implies p = q )

The same may be true for the Collaboration meta-type (the
"ownedElement" association end is duplicated), but these two are
specializations of an association inherited from ModelElement, so
perhaps that is acceptable.

No Data Available

Using a role as the target of a create action does not support
instantiation of children of the role classifier. [p 2-112
collaboration semantics].

No Data Available

UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

No Data Available

Action composition meta-modelled improperly: action sequence
inherits from action. Should be Gamma's composition model with
action as a sibling of action sequence.

declined

[p 102, notation] An arrow with the arrowhead pointing to an
object symbol within the frame of the diagram maps into a
Stimulus dispatched by a CreateAction

Figure 3-48 [p 100] shows the above for ob1:C1, and ob2:C2, but
with lifelines below each one sending messages (eg, to ob2:C2
and ob4:C4 respectively). Does this mean the constructor of
the object, that is the object creation method, is sending
messages? These objects aren't notated as active, so they
can't send messages on their own. It would be good to explain
this in the above text.

No Data Available

The semantics of the stick arrowhead is described as:

[p 124, notation] Flat flow of control. Each arrow shows the
progression to the next step in sequence. Normally all of the
messages are asynchronous.

[p 128, notation] stick arrowhead: flat flow of control
(normally asynchronous).

What is a "flat flow of control"? How is it different than an
asynchronous operation or signal? It is ambiguous to say that it
is "normally" asychronous. How does the user tell whether it is
or isn't in any particular case?

It is more confusing when compared to the descriptions for
half-stick:

[p 124, notation] Asynchronous flow of control. Used instead of
the stick arrowhead to explicitly show an asynchronous
communication between two Objects in a procedural sequence.

[p 128] half stick arrowhead: an asynchronous operation invocation

How is a "flat flow of control" different from a "procedural
sequence"?

This topics has been very confusing for the agent modelers, who
are using sequence diagrams to model agent protocols.

No Data Available

Each state machine is owned by exactly one model element.

The meta-model shows 0..1.

declined

Flow relationship has the incorrect semantics specified for it:

[p 2-33] It usually connects an activity to or from an object
flow state, or two object flow states. It can also connect from
a fork or to a branch.

Compare:

<<become>>

Specifies a Flow relationship, source and target of which
represent the same instance at different points in time, but
each with potentially different values, state instance, and
roles. A Become Dependency from A to B means that instance A
becomes B with possibly new values, state instance, and roles at
a different moment in time/space.

<<copy>

Specifies a Flow relationship, the source and target of which
are different instances, but each with the same values, state
instance, and roles (but a distinct identity). A Copy Dependency
from A to B means that B is an exact copy of A. Future changes
in A are not necessarily reflected in B.

No Data Available

The <<primitive>> keyword/stereotype used in the meta-models of
the datatype section are not defined. Isn't clear what level the
datatype meta-model elements are at.

No Data Available

What happens when a event is defered in one region, but not another? Is
it left on the queue accessible to both regions, even if it has already
been consumed by one of the regions? Semantics says deferred events are
kept if not used in one of the regions. So if one region uses it, it is
lost, even if it is deferred in the other region. User cannot use event
in both regions.

Reference manual says:

At the time that an object processes an event, it may be in one or more
concurrent states. Each state receives a separate copy of the event and
acts on it independently. Transitions in concurrent states fire
independently. One substate can change without affecting the others,
except on a fork or join caused by a complex transition (described
later).[p 443, Reference Manual]

and refers to an internal queue of events:

Deferred events. A list of events whose occurrence in the state
is postponed until a state in which they are not deferred becomes
active, at which time they occur and may trigger transitions in
that state as if they had just occurred. The implementation of
such deferred events would involve an internal queue of
events. [p 438]

declined

States currently do not model the conditions required for an
object to be in a particular state. A constraint note can be
linked to a state, but there is no specification of when the
constraint should be tested. It could be tested when the object
enters the state, leaves the state, or at any other time. Even if
this were unambiguous, the consequence of violating the constraint
is not defined, namely, to transition the machine to a state that
has a constraint satisfied by the object. This might be modeled
as a change-event trigger on an exiting transition, but it would
be redundant with the constraint recorded on the state and with
triggers on other transitions leaving the state, thereby impairing
maintainability.

No Data Available

ownerScope in Feature has the same semantics as targetScope in
StructureFeature. Aren't they clashing?

No Data Available

It is very common for readers of activity diagrams to look at a
call state and want to see what type of object is having an
operation invoked by the action of that state. There is
currently no adopted notation for this. Notes are too bulky and
non-standard for this application. Without this notation
activity diagrams appear non-object-oriented.

No Data Available

What is the reason that Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

duplicate 3341

ISSUE FOR UML, SECTION ActivityGraphs
-------------------------------------

Description:
------------
The metaclass ClassifierInState is too limited and can be generalized
to become more useful. It might show to be completely unneccesary.

The Definition of ClassifierInSate in UML 1.3 is as follows:

A classifier-in-state characterizes instances of a given classifier
that are in a particular state or states. ......
ClassifierInState is a child of Classifier and may be used in static
structural models and collaborations (e.g., it can be used to show
associations that are only relevant when objects of a class are in a
given state).

Issue 1:
This might be a useful concept, but defined in a too limited way.

Specifying that only instances which fulfil certain condiations
can be used is meaningful at many places. However, these restrcitions
are not based only on the state in which the instance is. They can also
be based on attribute values and link values.
Therefore the ClassifierInState is too restricted, because the
condition can only be a (or more) state(s).

Solution:
---------
Instead I would like to define a metaclass RestrictedClassifier (or
ConstrainedClassifier) instead of ClassifierInState. The definition should
be:

A RestrictedClassifier characterizes instances of a given classifier
that conform to certain constraints.

For modeling the restrictions UML already has a perfect metaclass called
Constraint. A RestrictedClassifier has an association to Constraint with
multiplicity 1..* (at least one constraint)
The constraint can either be stated in OCL, which allows one to specify
generically any restrictions you want (or in any other language).
OCL allows to check whether an instance is in a certain state by the
expression "instance.oclInState(statename)", and is therefore able to
specify at least everything you can specify with ClassifierInState.

Potentially we could define a stereotype (e.g. <<restriction>>) for this
kind of Constraint.

declined

Description:
------------
The metaclass ClassifierInState is unneccesary and can be replaced by
existing metaclasses.

Discussion
-----------
In a number of cases a specific ClassifierInState is not needed. When e.g.
a ClassifierRole always has certain restrictions, these restrictions can be
modeled with a Constraint (stereotypes as <<invariant>>) on the
ClassifierRole.

The use of ClassifierInState in activity graphs is to show the output or input
parameter to actions. The same concept can be modeled in a unified way by
using existing preconditions and postconditions.

To denote that an object must be in a state after the action can be modeled
by a
<<postcondition>> Constraint attached to the action state.
To denote that an object must be in a state before the action can be
modeled by a
<<precondition>> Constraint attached to the action state.
An action is a piece of behavior and can have pre- and postconditions attached
to it. using that, the ClassifierInState might turn out to be superfluous.

Solution
--------
Remove ClassifierInState metaclass and replace it by a description how
existing
metaclasses can be used to solve the same modeling problem.

declined

We are currently implementing the UML spec into java and have stumbled upon the following problem:
According to the Model Management package, a UML Package can only own/reference Packages, Classifiers, ..., and Stereotypes.
My question is, where to put UML 'Instances' (Common Behavior package, p. 2-89) in the model?

Shouldn't the UML Package (p. 2-173 & 2-175) be allowed to own/reference UML 'Instances'?

No Data Available

Issue: The semantics of inheritance (UML 1.3, ad/99-06-8, p. 60-61) does
not include Stereotypes as being among the things that a subclass inherits
from its superclasses.

Recommendation: Explicitly specify that Stereotypes are inherited.

Discussion: UML specifies that Constraints are inherited. A Stereotype is
logically a constraint, and can even formally define Constraints that apply
to stereotyped ModeledElements. Consider a Class A that is stereotyped S, where C is the Constraint that the Stereotype definition specifies for all ModelElements stereotyped S. Now consider Class B that
inherits A. It stands to reason that the Constraint C applies to Class B.

No Data Available

State Machines:

Why is "FinalState" a separate metaclass ?

It seems that a final state can be modeled as a kind of PseudoState
(with PseudoStateKind = final).

FinalState has no attributes of its own, and all associations inherited
from State must be empty for a final state:

• A final state cannot have an entry action
• A final state cannot have an exit action
• A final state cannot have an doActivity
• A final state cannot have a deferrableEvent
• A final state cannot have an internalTransition

Could anybody explain the reason of existence for a FinalState metaclass ?

declined

his nice feature provides a useful shortcut for writing complex OCL
expressions. However, it is under-defined both syntactically and
semantically.

Syntactically, why stop at one level, as specified by the grammar
rule:

expression := letExpression?
logicalExpression

To make the language more orthogonal, that rule should be
replaced with:

expression := ( letExpression expression )

which, by the way, ensures the correct precedence and evaluation
order. The generic form of the let expression is:

let <variable> = <expression-1> in <expression-2>

what is not so self-evident, is the following: this fancy syntax
somehow hides the fact that semantically this is equivalent to the
lambda-expressions known from functional analysis:

No Data Available

OCL expression is duplicated with errors:

"self.source.kind = #initial" should be
"self.source.oclAsType(Pseudostate).kind = #initial"
"self.StateMachine.top" should be "self.stateMachine.top"
"self.trigger.operation" should be
"self.trigger.oclAsType(CallEvent).operation"
"self.StateMachine.context" should be "self.stateMachine.context"

No Data Available

There are some examples of OCL expressions with type errors.
For example, in section 7.4.4. there is an OCL expression:

1 + 'motorcycle'

of which it is said that it is invalid because type Integer does
not conform to type String. The conclusion is correct, but the reason
for the expression above being invalid is entirely different.
The reason for it is that type String does not confirm to type Real!

Proposed solution:

Rephrase the text in the OCL specification. And check other examples.
____________________________________________________________________________

No Data Available

There is no 'self' object in preconditions and postconditions
of class operations. For example the following:

context X::increaseInstanceCounter()
post: instanceCounter = instanceCounter@pre+1

will not work, because "instanceCounter" is only a
syntactic shortcut for the full form
"self.instanceCounter", and, as already said, there is no
valid self in this context.

We can even allow a little syntactic trick along the lines of OCL
case-sensitivity: when a class name is on the other end of an
association, making its 1st letter lowercase actually denotes
associated instance(s) of this class. Going the other way round, we
may state that when self is written in a capitalized form Self, it
actually denotes the context class, not object:

context X::increaseInstanceCounter()
post:
Self.instanceCounter =
Self.instanceCounter@pre+1

This point clearly merits a discussion. The good thing is: even if
the provisions for static class members are included in the OCL
exactly as suggested above, all existing OCL code will remain
valid.

rejected

If, as I was told before, they are supposed to be similar to Java
strings, the correct rule for string constants will be:

string := "'" (
(~["'","\\","\n","\r"] )

Allowing octal escapes only in the ASCII range is not really a part
of syntax ­ it is a part of OCL semantics, and this is where it
belongs.

As a matter of fact, even that is not 100% right ­ because it doesn't
allow for hexadecimal escape sequences ­ and allows to specify
only ASCII characters (decimal codes 0..255), while in Java strings
the hexadecimal escapes can be used to specify any UNICODE
character.

I am also wondering, why OCL insists that all strings should be
ASCII strings? Is there a compelling reason for disallowing
UNICODE strings (and thus having no support for international
applications)?

No Data Available

The OCL chapter of the UML reference insists that not only there
is a data type Real, but one can also write constants of this type.
However, the OCL grammar does not allow for floating-point
constants.

To correct that, the rule for numbers:

number := ["0"-"9"] (["0"-"9"])*

could be rewritten as:

number := ["0"-"9"] (["0"-"9"])*
( "." ["0"-"9"] (["0"-"9"])* )?
( ("e" | "E") ( "+" | "-" )? ["0"-"9"] (["0"-"9"])* )?

to allow all traditional forms of Real constants, both with decimal
point and with exponent (and both).

The one mandatory digit after the decimal point is there on purpose,
to make sure that in an OCL string like

1..10

(which is perfectly legal inside the OCL collection literal) the
leftmost sub-string '1.' will not be incorrectly recognized as a real
constant. This little trick allows writing lexical parser for the OCL
that does not need more than one-character look-ahead.

Proposed resolution:

Agreed.
______________

No Data Available

Currently, the syntax for the literal collection allows either a single
range of values, or a list of individual values:

literalCollection := collectionKind "

"

expressionListOrRange := expression
( ( "," expression )+

This is too complicated a rule for what could have been
made much simpler:

literalCollection := collectionKind "

"

collectionItem := expression ( ".." expression )?

Which would also allow more general types of literal collections,
like in:

Set

And is just as easy to parse.

Proposed resolution:

This is more generic and should be includes in the OCL grammar.
grammar is ok.

No Data Available

Enumerations are Datatypes in UML and have a name. They can be shown
with the notation of a class. In the attribute box, the possible values
of the enumeration are written. In fact these names are class
constants (class-scopes frozen attribute) for the enumeration type.
If we use this UML definition in OCL, the logical way to
refer to them will be as class attributes, for which there is already a
defined notation in OCL (Classname.attributeName):

When we have Datatype named Sex with values 'female' or 'male'
they can be used as follows:

context Person inv:
sex = Sex.male

Also the enumeration type has a name, therefore the "var :
enum

" type declaration in OCL is superfluous. We can use
the typename instead: "var : EnumTypeName".
A logical consequence of this is that the special notation for
enumerations will disappear completely and only the above syntax is allowed.

No Data Available

When an enumeration constant is used, it has to be preceded by the
hash '#' sign. While this is not strictly necessary, it certainly
makes parsing easier and, therefore, can stand as it is.

However, the need for the same hash characters in the definition of
the enumeration types, like in

enum

is what the OCL grammar currently requires ­ and in this context
the hash characters should probably be abolished, because:

• Their presence does not give anything significant to user
  because name conflicts can't happen inside the enumeration type
  definition. Everything inside the curly brackets {} is enumeration
  constants.
• Normally, one can try to copy-paste some text between UML and OCL
  parts of the class model. This is made a bit tricky, because UML and
  OCL use
  different syntax for the enumeration types. It would
  be nice of OCL could adopt the UML syntax.

No Data Available

The rule for non-terminal primaryExpression should be
changed from

primaryExpression := literalCollection

to

primaryExpression := literalCollection

for two reasons:

• It will become shorter
• It describes what is going on more carefully ­ since
  what happens is exactly the feature call on the default
  object (self).

Proposed sulution:

Needs to be checked in detail to see what the consequences of this
change are.

No Data Available

Although the OCL specifies a respectable set of keywords (like
"and", "if", etc.) the OCL reference says nothing about whether
they are reserved or not. Clearly, a software designer is completely
free to specify the class with an attribute called "if". Or, more
probably, "context". Or any other OCL keyword. How, then, to
parse an OCL constraint like:

context if : X inv:
if.then->size()>=else->size()

(where if is used instead of self to designate the object an
invariant is applied to, and then and else are its associations).

Clearly, reserving keywords is a bad idea. The rule, which seems
to work well (and has been tried in many real programming
languages over decades) is:

An identifier is recognized as a keyword if and only if it is
encountered in a context where this keyword can legally
appear.

No Data Available

Some non-terminals are enclosed in angle brackets <>,
and others are not. This would not have been a big problem, if not for the
fact that enclosing non-terminals in angle brackets is a technique from
the original BNF specification format. So, we should either use it
consistently for all non-terminals ­ or not use it at all.

Proposed resolution:

make the grammar description consistent.

No Data Available

The UML Specification contains UML diagrams of the "physical" metamodel, but
the diagrams do not show which association ends have corresponding
references. Using a UML facility requires knowing exactly where references
occur, so showing references in diagrams is important.

Recommendation: Make references explicit in the UML diagrams of the
"Physical Metamodel". We can do this by showing each reference as an
attribute with a stereotype of <<reference>>.

No Data Available

We can imagine packages
Package1 and Package2, both containing the class X, but we
are free to use scope resolution to refer to these two different
classes as Package1::X and Package2::X.

However, we then should also be able to specify constraints on
these classes. To do so, the context definition should allow the
fully scoped class name to be used, like in

context Package1::X inv: …

No Data Available

The text of the OCL specification says, that both following forms
are allowed:

context Company
inv : self.numberOfEmployees > 50

and

context c : Company
inv : c.numberOfEmployees > 50

However, the OCL grammar does not allow the 2nd form.
To allow the 2nd form, the rule

classifierContext := <typeName>

Should be changed to

classifierContext := ( name ":" )?
<typeName>

No Data Available

UML's "physical" metamodels need to be more careful about which association
ends have corresponding references. In places where an association end can
relate one element to another element imported from another model, it is
generally best to not have a reference on the inverse end. Note that
"reference" is a MOF concept. The lack of a reference does not affect
whether an association end is navigable. It does affect whether a link can
be in a different MOF package extent (this is a MOF constraint). If both
sides of an association have references, then related objects are forced to
reside in the same package extent, which prevents the federation of UML
facilities.

An important aspect of interoperability comes from federation: UML
facilities having links to other UML facilities. The overuse of references
prevents use of such links in places where they should be allowed.

No Data Available

There is no XMI-based XML rendering of the UML metamodels in the UML 1.3
Specification. The "physical" metamodels must be precisely described using
the MOF Model document type in order to maximize tool interoperability
across vendors and to enable extension of the metamodels by others. This
has been done in MOF 1.3, in the initial CWM submission and in other OMG
submissions, thereby providing definitive metamodels with complete
machine-readable clarity.

Recommendation: Put an XML rendering of UML metamodels in the UML 1.4
specification based on the MOF Model DTD.

No Data Available

In order to maximize tool interoperability, the language names provided in
UML Expressions should follow a consistent naming pattern. No such pattern
is given by the UML Specification.

Recommendation: Add the following simple statement after the predefined
language names (a list of one) given in the description of Expression. Note
that the following naming practice has a president. It is recommended in
the ANSI/ISO C++ standard for language names used for external linkage:

No Data Available

sUnique for Collections is defined as follows:
>>
>>collection->isUnique(expr : OclExpression) : Boolean
>> post: result = collection->collect(expr)->forAll(e1,e2 | e1<>e2)
>>
>>Unfortunately, if the collection is not empty, this expression
>>always evaluates to false. This is due to the fact that in a
>>forAll over two iterators, both iterate over the full collection.
>>Therefor, for each element in the collectionen , there is a
>>step where both itereters point to this element, but at this
>>point, e1 <> e2 evaluates to false.
>>
>>My suggestion for the definition of isUnique would be as follows:
>>
>>collection->isUnique(expr : OclExpression) : Boolean
>> post:
>> let res = collection->collect(expr) in
>> result = res->forAll(e $|$ res->count(e) = 1)
>>
>>This expression states, that each element in the collection 'res'
>>appears exactly once, i.e. is unique.

No Data Available

The issue / problem relates to the use of interfaces in associations, i.e.
the "type" association in the meta model between AssociationEnd and
Classifier.

Besides the use of a syntactical interface specification, I use the
interfaces as well as the location to provide semantics, using OCL.

OCL provides a well-defined way to navigate along association ends. Where
actually interfaces would provide the semantic context for association ends,
I have to refrain from specifiying those on the interface, but have to defer
this association to the realizing class.

As an alternative it is possible to provide getter and setter operations
providing access to the association ends in the deferred implementation. But
this presents two other problems:
a) this public (as no other ones are allowed) operation on the interface
will need to be realized any realizing class (and I do not always want to
compromise this information)
b) the return value of the operation (in case of a multiplicity > 1) will
not per se have the same OCL "accessibility" as an association end;
furthermore tools - at this point in time - provide significant better
control in terms of verification for associations than for operation
parameters / return values.

rejected

Summary: UML 1.3 Metamodel Semantics

Generalization should be meta-metamodel element

It is a generally accepted fact that generalization is a second order
relation, ie, a relation whose elements (instances) are pairs of
types (classifiers, or whatever). Associations, by contrast, are
first order: their elements are tuples of objects (individuals,
etc.).

UML is based on a four-layer metamodel structure, including metamodel
and meta-metamodel layers. Why, then, do Generalization and
Association appear on the same layer, namely the metamodel? Much more
troublesome: How can they be specializations of the same
generalization, namely Relationship? Together with the defined
implication of generalization: "The more specific element is fully
consistent with the more general element (it has all of its
properties, members, and relationships) ..." [UML 1.3, sect. 2.5.2]
this leads to a paradox, because generalization itself would be
inherited. The paradox would be avoided, however, if generalization
were a relation of the meta-metalayer.

declined

Summary: Roles play a dual role in UML. On one hand, a role is the name of an association end [UML, § 2.5.2] and thus nothing more than the name of place of a relation. On the other hand, UML has a notion of roles specified in the context of collaborations [UML, 2.10]. This notion conflicts with the first one since a single role of the collaboration may have different role names assigned by the different associations it participates in. In other words, the associations of a collaboration may assign different role names to their ends (and thus, to the classifiers at the ends) than assigned by the collaboration directly, potentially leading to a clash of role names.

Overall, the specification of the role concept in UML remains rather vague. It seems that classifier roles only indirectly specify the base classifiers whose instances can play the roles: "In fact, since an instance may originate from several classifiers (multiple classification), a classifier role may have several base classifiers." (but where are these specified?) and "However, since the only requirement on conforming instances is that they must have attribute values corresponding to the attributes specified by the classifier role, and must participate in links corresponding to the association roles connected to the classifier role, they may be instances of any classifier meeting this requirement." [UML, 2.10.4]. And finally "Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent"s roles; it is enough that they contain all the required features." This is certainly a very unusual feature in a typed language such as UML.

So what are roles? It seems that in UML they are not types (or classifiers), but a positive definition (other than the equally vague glossary entry) would seem imperative!

resolved

Summary: Descriptor:
symbols such as +, - or * in the name of a feature in Ocl expressions
are not allowed.

No Data Available

Summary: "The owners of the copyright in the UML specification version 1.2 [sic, in
1.3alpha5] hereby grant you a [...] license [...] to create and distribute
software which is based upon the UML specifications [...]

Software developed under the terms of this license must include a complete
implementation of the current version of this specification [...]"

This appears to say that any UML-based CASE tool must implement the whole
of the standard. Since as far as I"m aware no existing tool, including
Rational Rose, comes even close to doing this, should not the restriction
be changed? (I do not suggest that it should be enforced!)

fixed in UML 1.3

Summary: There seems to be an error in the third postcondition for String::concat on page 6-31. It says:

post: result.substring(string.size + 1, string2.size) = string2

It should read:

post: result.substring(string.size + 1, string.size + string2.size) = string2

No Data Available

Summary: The not-equals operator, "<>", seems to be listed for Enumerations, but not for Reals (page 6-27), Integers (p 6-29), Booleans (p 6-31) or Strings (p 6-30), even though it seems to be used in many places elsewhere in the specification.

All the other operators seem to be there (equality, less than, etc.), so I think this one should be as well (although you can simulate it using "not").

Note that inequality is defined for OclAny, but then so is equality.

No Data Available

Summary: Under the "Real" type on page 6-29, the divide operator is incorrectly
written as an asterisk instead of a forward slash.

I am not sure if this is just a typo, computer glitch, or error in translating the document to Acrobat format or something weird like that.

No Data Available

Summary: pages 6-28 to 6-29 of OCL documentation

Trivial point - For consistency, the Real operators +, -, * and / should take a parameter called r2, not r1. This seems to be the convention used elsewhere throughout the document, and makes the point that they are the second real number in the expression.

No Data Available

Summary: page 6-10 of OCL documentation for 1.3alphaR5

I notice that not equals <>, the pathname operator :: and the @pre operator are not listed in the precedence table, and so I guess, technically, their precedence is undefined.

You could also put parentheses at the top of the table as well, of course, to make that table more complete and stand-alone. Parentheses would then not need to be described in a sentence following the list.

No Data Available

Summary: The second postcondition on Integer::div is incorrect. It currently reads:

i.div( i2 : Integer) : Integer

The number of times that i2 fits completely within i.

post: result * i2 <= i
post: result * (i2 + 1) > i

No Data Available

Summary: The postcondition seems to be incorrect for sequence::subSequence. It currently reads:

sequence->subSequence(lower : Integer, upper : Integer) : Sequence(T)

The sub-sequence of sequence starting at element number lower, up to and including element number upper.

post: if sequence->size < upper then
result = Undefined
else
result->size = upper - lower + 1 and
Sequence

->forAll( index |
result->at(index - lower + 1) =
sequence->at(lower + index - 1))
endif

The indexing is incorrect.

No Data Available

Summary: The postcondition on set::collect seems to be incorrect. It currently reads:

set->collect(expression : OclExpression) : Bag(expression.oclType)

The Bag of elements that results from applying expr to every member of set.

post: result = set->iterate(elem; acc : Bag(T) = Bag{} | acc->including(expr) )

The type of acc is wrong, and it should read:

post: result = set->iterate(elem; acc : Bag(expression.oclType) = Bag{} | acc->including(expr) )

Note that the same goes for Bag::collect on page 6-41.

No Data Available

Summary: I know it"s late in the game, but in my use of activity diagrams for
modeling algorithms, a minor change has become apparent. Specifically, it
is possible to have objects "flow" from one activity state to another, but
it is not possible to show a persistent object which is modified by some
activity states and used by others. I therefore recommend the following change:

Activity states be able to depend on objects with stereotypes for <<use>>
and <<modify>>. In this case, control flow among the activity states must
be shown since the "data object" does not flow between activity states but
exists in an enclosing structural context.

No Data Available

Summary: resolving the issue of extensibility of OCL (like adding an operation to a
predefined
OCL type) I have written a new section in the OCL chapter. It describes
the
existence of a default package in each UML model, containing the predefined
OCL
types. I have chosen to name this package "UML_OCL" (or StandardOCL, ...).

Typically, the modeler will define its own OCL package (named e.g. MyOCL),
import
the standard OCL package (import UML_OCL) and extend the predefined OCL
types
to his/her liking. A like approach is taken in Catalysis.

No Data Available

Summary: The end of the association which is opossite to ModelElement is named as "stereotypeConstraint". I sugesst to rename it to "constraint" or "elementConstraint".
The name "stereotypeConstraint" is somewhat misleading. issue from Constantine Plotnikov (cap@novosoft.nsc.ru)

No Data Available

Summary: OCL should allow one constraint to reference another (e.g. by name) to avoid
redundancy in a specifiation and errors related to maintenance of separate constraints
that should be the same.

declined

Summary: Summary: The action state symbol and the state symbol differ only in the convexity of their vertical sides. Therefore, it is difficult to distinguish between them, if the diagram is drawn by hand. The symbols have different semantics and both of them can appear in a single diagram (activity diagram). Therefore, it is necessary to clearly distinguish between the symbol for the state and the symbol for the action state.

Previously considered for 1.4 and closed w.o. change

Summary: UML has a symbol for multiobject. However, UML does not have any specific symbol for multiple instances of a component, node, subsystem, interface, actor, use case and collaboration. Adding these symbols to UML will maintain symmetry and therefore, simplicity of the notation.

declined

Summary: Dependency relationship in UML does not have role ends, similar to the association ends that associations have. Therefore, it is not possible to specify, for example, that:

1. an entity depends on an ordered set of other entities.
2. an entity depends on a specified number of instances of other entities
3. the roles of the entities that participate in the dependency. Dependency imply the entity roles "client" and "supplier". However, I often came across situations where I needed to specify more concrete roles than "client" and "supplier". In cases I came across, replacing dependencies by associations was not a convenient solution.

No Data Available

Summary: I would again propose that Responsibilities are added as a new metatype.
After all Relationship is about to be added in Version 1.3 so I would
suggest respectfully that the easy addition of one metaclass (Responsibility)
and two metalevel association relationships (from Classifier to
Responsibility and from Responsibility to Feature) would be highly
beneficial and very easily changed in the metamodel. Notational support
is no problem since (as I have discussed with Grady) is just the addition
of a new box under the class icon.

No Data Available

Summary: On aggregation. The white diamond name should be "shareable"
not "shared" because it really indicates the ability to be shared not
the notion that it IS necessarily shared.
submit: Submit Issue Report

No Data Available

Summary: The metamodel and semantics for aggregations is still causing me
much concern. Primarily, it is stated that black diamond (composition)
must have linked lifetimes and dependencies between part and whole.
This means that the parts are NOT separable from the whole. It also states
that whilst there is only one owner that owner may be changed. This means
that the parts MUST BE separable from the whole. This is a contradiction.

No Data Available

Summary: Interface is a kind ofclassifier and therefore has features - but it
supposedly only has operations

rejected

Summary: Only single stereotyping is supported. Multiple partitioning and
therefore multiple partitioning would be usefully and easily added

No Data Available

Summary: Use of black diamond (even when semantics are pinned down) in the metamodel e.g. Classifier
as a composition of Feature is not convincing. The ideas of lifetime
interlinking seems not necessarily to be the case for many of the metamodel
uses of black diamond. Similarly for Transition as a composition of
Guards in the STD.

No Data Available

Summary: The OCL prescribes certain characteristics of names of classes,
attributes, etc. Clas anmes must start with uppercase, attributes
start with lowercase, etc.
It would be more flexible if these restrictions could be widened.

No Data Available

Summary: In the current metamodel, it is not unambiguously defined whether
a BooleanExpression is written in OCL or in some other language.
With tool vendors developing OCL tools, it is important to be able
to state exactly whether an Expression is written in OCL or not.

fixed in UML 1.3

Summary: A number of common operations should be added to the collection
types in OCL. These are:

Collection(T) :
any( <boolean-expression> ) : T
returns any element which satisfies <boolean-expression>
one( <boolean-expression> ) : Boolean
returns true if thee is exactly one element that satisfies
<boolean-expression>
theOne( <boolean-expression> ) : T
returns the single element which satisfies <boolean-expression>

and maybe others as well.

Summary: There does not appear to be a definition of "instantiable."

If "not instantiable" means can not have instances in a model, then some
model elements should be instantiable, which are currently specified to
be not instantiable.

If "not instantiable" means can not have instances in a running system,
but may have instances in a model, then this should be made clear.

No Data Available

Summary: The notation says that associations may be parts of composites:

The parts of a composition may include classes and
associations. The meaning of an association in a composition
is that any tuple of objects connected by a single link must
all belong to the same container object. [p62, section 5.26.1
Notation, UML 1.1, or p65, section 3.42.1 in UML 1.2]

The above meaning of association as part is not recorded in the
semantics.

In any case, the definition prevents associations from having
parts themselves. When an association has parts, some parts must
be associations that connect to objects outside the containing
association. See Bock & Odell in JOOP, Vol 11, No 5, September
1998, also at:

No Data Available

Summary: In Section 5.17 of the Notation Guide, the notation for an object is
described as allowing the inclusion of particular states that the object
is in, but no mapping is given. The obvious mapping is to use a
ClassifierInState construct from activity modeling as a classifier of
such an Object, but the well-formedness rule for Object on page 76 of
the Semantics requires that all classifiers of Objects be Classes.
A ClassifierInState is a kind of Classifier, but NOT a kind of Class, so
its use is prevented in the metamodel.

No Data Available

Summary: Rules 3 and 4 for Transitions in state machines should be limited
to state machines, because these rules are overridden in the first
rule for PseudoState in activity models. See Rule 3 and 4
Transitions in State Machines: [p 118, UML 1.2 Semantics], and
Rule 1 of PseudoState in Activity Models: [p 138 UML 1.2,
Semantics].

No Data Available

Summary: In figure 2-13 Comment is a specialization of ModelElement. Yet the text on page 2-49 section 2.6.2 says that "Comment is a subclass of ViewElement." Also it mentions it has an association with a set of model elements. Presumably it would have a text attribute to hold the comment as well.

No Data Available

Summary: In example 2 pg. 114, according to the definition of LCA, main source,
main
target, LCA(t)=s, main source(t)=region 1 of s, main target(t)=region 2
of
s. Text says all of them are s.

No Data Available

Summary: Rules Transition [6] and [7] pg. 105-106 should be rewritten. One of
the
problems with them is:

In rule Transition [6] pg. 105-106, the fact that the originating
regions
of a group of transitions entering a fork pseudostate should be
orthogonal
is not caught. A configuration like:
state A with subregions B and C, b1 substate of B and transitions t1
and t2 both exiting b1 and entering the same join state
satisfies the constraint, although it is clearly wrong.

The same problem appears for rule [7] pg. 106, for fork pseudostates.

No Data Available

Summary: In Semantics/Inheritance pg. 34 it is stated that "Each kind of
generalizable element has a set of inheritable features", without saying
which are those features for each kind of generalizable element. Note
that
they are different: for a Package, the ownedElements are inherited,
while
for a Classifier they are not. The set of inheritable features should be
defined for each descendent from GeneralizableElement.

No Data Available

Summary: Notation states that a Class(ifier) can have at most one implementation
for a given Operation. Although this can be inferred from the Semantics
document, it should be stated explicitly in the Semantics document.

No Data Available

Summary: The EBNF-construction "+" is not explained.
add to explanation: "+" means one or more time

A number of brackets have been lost in the definitions for
typeName, name and number:
number := ["0"-"9"] ( ["0"-"9"] )*

there is no way to specify a float literal (3.14)

No Data Available

Summary: p. 80 NG (Notation for Sequence Diagram) "Objects can be grouped into
"swimlanes" on a diagram."

These swimlanes are not mapped and there is nothing in the SG to map them to.

No Data Available

Summary: The following well-formdness rules in the SG are only expressed in English.
Whether the OCL was intentionally left out or not, is unclear:

• p. 27, Association[3]
• p. 75, Instance[6]
• p. 104 Guard[1]
• p. 124 ActivityModel[2]
• p. 125 PseudoState[2]

No Data Available

Summary: p. 40 NG The example in fig. 14 can not be represented in the model. The
template parameter "k:Integer" refers to the multiplicity "k" of the
composition association to "T". To be more precise: it refers to the
attribute "multiplicity" of AssociationEnd. But this contradicts fig. 7 on
p. 43 of the SG. A template parameter is there defined to be a reference to
a ModelElement. Referring to an attribute of a ModelElement is not possible.

No Data Available

Summary: The NG and the SG are inconsistent on where Instances my be defined:

On p. 22 the NG states:

"Note that a "class" diagram may also contain interfaces, packages,
relationships, and even instances, such as objects and links."

and:

"If a diagram is part of a package, then its contents map into elements
in the same package."

No Data Available