Summary: Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the
Notation Guide, version 1.1. Complete suggested text is availabl ein the issues"s archive

No Data Available

Summary: Some minor flaws in the wording of the OCL description within OMG-UML
version 1.3, Jan. 1999:

• • Section 6.4.4, Type Conformance, page 6-222

"Each type conforms to its supertype."

The word "its" implies that there is only one. It would be better if this
said: "Each type conforms to each of its supertypes."

• • Section 6.4.5, Re-typing or Casting, page 6-223

"If the actual type of the object is not equal to the type to which
it is re-typed, the expression is undefined."

Summary: Infix operators like "+" and "<" etc. are defined for built-in OCL types.
It is not explained whether you can
use these for user defined types. The proposal is to allow infix notation
for all of the
operators defined in OCL for used-defined types as well. If someone
defines the operation
"+(p : Person)"
on type Person, this can be used in OCL by
somePerson + anotherPerson.
instead of just by
somePerson.+(anotherPerson)
The OCL specification is not clear whether this is allowed or not.

Clarified in UML 1.3.

Summary: The expressive power of change-events is limited. We are writing a
specification that is much simpler if we can trigger transitions under a
circumstance like the following:

"P has just become true and it is not the case that Q has just
become true"

There"s no way to say that with a change-event. Instead we have to write a
somewhat obscure sequence of transitions that defines a program to calculate
this.

Considered and declined.

Summary: There are a number of issues that make OCL hard to formalize. The attached
document is a draft of a research into formalizing UML/OCL. It contains
a number of issues on OCL. Instead of making all of these into separate
issues, the document is attached and all problems described in there are
hereby submitted as one (rather big) issue. This document will be posted as ad/98-10-01 on the OMG document server

Redundant with issue 2013.

Summary: OclAny is essentially a type of all types. In particular,
section 5.13 of the OCL specification implies that Set(OclAny)
is a subtype of OclAny, from which a version of the Russell
Paradox promptly follows.

This needs to be clarified/resolved in the specification

Fixed in UML 1.3.

Summary: There is no simple way currently in OCL to refer in a postcondition to the
new instances created
during the operation. The current solution is:
Person.allIstances - Person.allInstances@pre
Since this is commonly used, a simper way to denote this will be
bened=ficial.
We propose to add an operation "new" or "created" to OclType, which can ony
be used
in postconditions and has the meaning describd above. We can then write:
Person.new or Person.created

Fixed in UML 1.3.

Summary: Because no predefined set of operations will cover all cases needed in
practical situations it s important that there is a well-defined way
to extend OCL.

It is possible to define all predefined OCL types within one predefined UML
package
end define package extension mechanisms to add extensions to OCL.
The current OCL specification doesn"t disallow that, but it should
be explained explicitly how this can be done.

Fixed in UML 1.3.

Summary: Currently if a sub-expression within an OCL expression is
used twice or more, you need to spell it out each time. This
is cumbersone, eror-prone and it also disguises to the reader
of the constraint that these sub-expressions are in fact identical.

The proposal is to add a construct to OCL, that allows one
to define a variable which holds the value of such a sub-expression.

Redundant with issue 1788.

Summary: The notation guide has a couple descriptions of swimlanes as
packages, even though swimlanes are not mapped to packages.
References:

If an object lifeline is not shown, then some object within the
swimlane package is responsible for the action, but the object
is not shown. [p 127, section 10.5.2, Notation, or p 130 in UML
1.2]

Actions may be organized into swimlanes. Swimlanes are a kind of
package used to organize responsibility for activities within a
class. [p 125, section 10.4.2, Notation, or p 128 in UML
1.2]

Fixed in UML 1.3.

Summary: Partitions in various activity models may reuse the same model
element. So the multiplicity of the association from
ModelElement to Partition should be *.

Comments:

Proposal: Change multiplicity of association from ModelElement to Partition
from 0..1 to * [p 121, Figure 22, Activity Model, Semantics,
or p134 in UML 1.2].

Fixed in UML 1.3.

Summary: UML RTF Issue: Normative MOF-Compatible version of UML
Severity: Critical

1) The UML RTF must produce a normative version of UML which is MOF-compatible.
2) This normative representation should be in Rose (or equivalent) and SMIF
form in the event that a SMIF submission is adopted.
3) In the event that XMI is adopted as the SMIF technology, the normative XMI
form of UML is a generated XMI document and DTD.

Fixed in UML 1.3.

Summary: The "Core Package-Backbone" diagram shows, on the Association
between Classifer and StructuralFeature, that the "feature"
AssociationEnd is ordered. Ordering is neither wanted nor
feasible for this end. What ordering would be applied to the
set of Attributes that given Class or DataType types? The order
in which they are defined is the only conceivable ordering, which
doesn"t seem very valuable.

Clarified in UML 1.3.

Summary: Severity: Minor
Issue: missing role names

Very few of the association roles have names, which are needed for model
interchange.
Here is the convention being considered in XMI for providing those names.
1) Start with the role name.
2) If the role name is missing, use the association name
3) If the association name is missing or a generated name (see xmi6), use the
class name
4) If the name is a duplicate, use the Class name appended with a number,
counting up from 2.

Clarified in UML 1.3 physical model.

Summary: Here"s issue xmi4, which was generated by questions arising during work on the
XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

Severity: Clarification
Issue: inheritance inconsistencies
1) The semantics document shows Component inheriting from Classifier on page 4,
however the definition on page 45 indicates that it inherits from Class.
2) The semantics document shows Node inheriting from Classifier on page 44,
however the definition on page 45 indicates that it inherits from Class.
3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but
the description on page 122 indicates that it inherits from SubmachineState.
4) Figure 8 on page 44 shows Comment as a subclass of ModelElement. The text
on page 44 states Comment is a subclass of ViewElement.

Inconsistencies corrected in UML 1.3. (Mostly redundant with issue 1953.)

Summary: Severity: Minor
MOF does not support association attributes in metamodels.
The following relationships have association attributes:
1) Namespace contains ModelElement (ElementOwnership), p16
2) ModelElement presents ViewElement (Presentation), p44
3) Package contains ModelElement (ElementReference), p129

Please describe the proposed MOF mapping if the association attributes are to
be retained in UML.

Redundant with issue 1955.

Summary: Severity: Minor
Issue: missing association names

Most of the associations are missing names, which are useful for model
interchange.
Here is the convention being considered in XMI for providing those names.
1) Identify the names of the classes on each end.
2) The "first" class is the one with the name that is lexigraphically first.
3) Concatenate the two class names together, separated by an underscore (_)
character. First_Second.
4) Duplicates have a number appended, starting with 2.

An example association name is Method_Operation (and not Operation_Method).

Clarified in UML 1.3 physical model.

Summary: Here"s issue xmi3, which was generated by questions arising during work on the
XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

Severity: Clarification
Issue: Action does not define attributes
The textual description of Action on page 68 does not defne all of the
attributes in the diagram on page 67.

Clarifed in UML 1.3.

Summary: Here"s issue xmi2, which was generated by questions arising during work on the
XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

Severity: Clarification
Issue: Name attribute inheritance
Please clarify that the Name attribute is inherited from ModelElement and not
redefined in these cases.
1) Parameter on page 27
2) Feature on page 23
3) BehavioralFeature on page 20
4) Association on page 17

If Name is redefined, the diagrams should include them.

Clarified in UML 1.3 physical model.

Summary: Here"s issue xmi1, which was generated by questions arising during work on the
XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

Severity: Clarification
Issue: abstract class inconsistencies
1) Figure 13 on page 67 shows the Action class as concrete. The text on page
70 says Action is abstract.
2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70
says Instance is abstract.

Clarified in UML 1.3 physical model.

Summary: n figure 2-18 an Action has the attribute isAsynchronous and the specialization of Action, CallAction has the attribute mode:SynchronousKind. SynchronousKind is either: sk_synchronous or sk_asynchronous. This seems redundant.

Also the isAsynchronous flag is explained nowhere but it is used on page 2-84 as an attribute of Signal although it does not appear to be a member of Signal.

Fixed in UML 1.3.

Summary: One improperly phrased rule in the UML Semantics manual (page
109):
>
> "The set of transitions that will fire is the maximal
set that
> satisfies the following conditions..." (italics added)
>
> Clearly, this should say a, not the. There may be more than
one such maximal set.

Clarified in UML 1.3.

Summary: Issue: association attributes
The MOF does not support association attributes in metamodels.
The following relationships have association attributes:
1) Namespace contains ModelElement (ElementOwnership)
2) ModelElement presents ViewElement (Presentation) [removed in uml 1.2]
3) Package contains ModelElement (ElementReference)

Clarified in UML 1.3.

Summary: missing association names
1) Very few of the associations have names, a required property of MOF metamodels. Naming metamodel relationships also enhances model interchange.
2) Many of the role names of associationEnds are missing.
3) The role name of Operation->Method is missing.
4) Missing role name: Classifier<-Parameter, p16
5) Missing role name: Binding->ModelElement, p43
6) Missing role name: Node->Component, p44
7) Missing role name: ModelElement<-Component, p44
8) Missing role name: Enumeration<-EnumerationLiteral, p60
9) Missing role name: MultiplicityRange->Multiplicity, p60
10) Missing role name: Parameter->Signal, p66
11) Missing role name: Action->ActionSequence, p67
12) Missing role name: Request->Action, p67
13) Missing role name: Argument->Action, p67
14) Missing role name: Most of the associations, Fig 14, p67
15) Missing role name: Most of the associations, Fig 15, p81
16) Missing role name: Classifier->Instance, p90
17) Missing role name: Most of the associations, Figs 17 and 18, p98
18) Missing role name: Most of the associations, Fig 22, p121
19) Missing role name: ModelElement->Package, p129

Clarified in UML 1.3.

Summary: Issue: inheritance inconsistencies
1) The semantics document shows Component inheriting from Classifier on page 4, however the definition on page 45 indicates that it inherits from Class.
2) The semantics document shows Node inheriting from Classifier on page 44, however the definition on page 45 indicates that it inherits from Class.
3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but the description on page 122 indicates that it inherits from SubmachineState.

Inconsistencies corrected in UML 1.3.

Summary: Issue: Diagram missing attributes
1) The attributes of Action on page 68 do not include all of the attributes in the diagram on page 67.
2) The attributes of BehavioralFeature includes Name in the text on page 20, but is not in the diagram on page 16.
3) The attributes of Feature includes Name in the text on page 23, but is not in the diagram on page 16.
4) The attributes of Parameter includes Name in the text on page 27, but is not in the diagram on page 16.

Clarified in UML 1.3.

Summary: The semantics document is contradictory on whether subsystems
are instantiable. Comments: If a classsifier is instantiable, it should be allowed to have
methods to implement calls to its operations at runtime. In
the case of subsystems, this may just translate to operation
calls on it contained objects. If subsystems are not supposed
to have behavior of their own, then they should not be
instantiable.

Clarified in UML 1.3.

Summary: Issue: abstract class inconsistencies
1) Figure 13 on page 67 shows the Action class as concrete. The text on page 70 says Action is abstract.
2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70 says Instance is abstract.
3) Figure 8 on page 44 shows Comment as a subclass of ModelElement. The text on page 44 states Comment is a subclass of ViewElement.

Inconsistencies corrected in UML 1.3.

Summary: There is no description of what an activity state should look like. The specification needs a notation section describing activity states.

Redundant with 1051.

Summary: The UML Semantics Guide 1.1 (top of p.37) says "...a class acts as a namespace for contained classes...". But the UML Notation Guide 1.1 (p. 23) only says "The name of a class has scope within the package in which it is declared...", i.e. it only speaks to classes that are directly contained in packages and is silent on the existence of classes within classes (Java"s "inner classes", or "nested classes" in C++) or how to represent them.

Considered and declined.

Summary: The semantics has the following statement regarding states leading
to joins:

If the ObjectFlowState leads into a join pseudostate, then the
ObjectFlowState remains activated until the other predecessors
of the join have completed [end of first paragraph of semantics of
ObjectFlowState, p 139, UML Semantics 1.2].

This behavior applies to all states leading to a join in
an activity model, because of regions already exist implicitly when
using joins in activity models.

Clarified in UML 1.3.

Summary: The notation document says regarding object flow:

Activities operate by and on objects. Two kinds of relationships
can be shown: 1) The kinds of objects that have primary
responsibility for performing an action and 2) the other objects
whose values are used or determined by the action. These are
modeled as messages sent between the object owning the activity
model and the objects that are input or output by the actions in
the model. [section 3.80.1, p 130 Notation 1.2]

Presumably the activity model doesn"t tell the objects being passed

Clarified in UML 1.3

Summary: ClassifierInState does not satisfy one of its stated usages, namely
to be used as input to an action. This would require that it have
all the attributes and associations of its corresponding classifier.

Witdrawn by submitter.

Summary: Attribute "body" of Metaclass "UninterpretedAction" is redundant to
attribute "script" of Metaclass "Action"

Fixed in UML 1.3.

Summary: Currently UML fails to support the notion of "conceptual" or
"specification-only" features, i.e. features introduced only for the
purposes of defining pre/postconditions and other constraints.

This is extremely important to anyone doing formal class specifications
from which we hope to generate code (e.g. us) and should be an easy matter
to resolve.

Considered and declined.

Summary: OCL should allow the use of "let" expressions (for the sake of
readability).

Note: The lack of a "let" feature is also mentioned in the abstract for
a paper on OCL at
http://www.it.brighton.ac.uk/staff/Stuart.Kent/publications/UML98.html
along with a number of other issues:

"Specifically, the paper suggests that: the concept of flattening
collections of collections is unnecessary, state models should be
connectable to class models, defining object creation should be made more
convenient, OCL should be based on a 2-valued logic, set subtraction
should be covered more fully, and a "let" feature should be introduced."

Redundant with issue# 1689.

Summary: In Figure 2.1 ActivityState is a specialization of SimpleState yet the text on page 2-135 in section 2.13.7.1 says "ActivityState is a SubmachineState". The text seems correct, ActivityState should be a specialization of SubmachineState.

Redundant with #928.

Summary: You really need to have some relative precedence among
and, or, xor and implies to have any hope of usefulness from these
operators.
You should also separate out the precedence of = and <> from the other
comparisons

Fixed in UML 1.3.

Summary: You"ll need some ways to do approximate comparisions
if you want reals to be useful in practical specifications.

Considered and declined.

Summary: Change events should be generalizable. For example, a traffic light
changing to any color is a more general event than a change of that
traffic light to Red only. If the second event happens, then the
first must have happened also. A state machine with a trigger event
on the first event will transition if the second event occurs.

The semantics document says that an event can trigger transitions which
have a more general event [p 113, UML 1.1 Semantics].

Comments:

This is close to issue # 29, "Events should be generalizable
elements", which Rumbaugh filed and withdrew. His reasoning is that
signals are generalizable and event are just pointers to them, so it
is not necessary for events to be generalizable. In fact, events are
more than pointers to signals, as shown in the event meta-model
[figure 18, page 98, of UML 1.1 Semantics]. Events also cover call
events, time events, and change events.

Considered and declined.

Summary: It is not specified what the result is of the expression
Integer.allInstances->size,
neither of Real.allInstances->size. This needs to be added to the OCL
Specification.

Fixed in UML 1.3.

Summary: Why can"t one ask for the @pre value of a object that has
been destroyed during execution? Logically there"s no reason to prohibit
this.

Considered and declined.

Summary: It"s a mistake to automatically flatten collections of
collections. This is noncompositional in that Set

means something
different when it"s in one context (another set, say) than it means
everywhere else.

Fixed in UML 1.3.

Summary: The states of an object, as specified in its state machine, are not
directly referenceablle from within
an OCL expression. In many cases it is very useful to be able to use them
in invariants, and especially
in pre- and postconditions.
Currently, we can define a so-called state attribue, which enumerates the
states, or alternatively we can
define a boolean attribute for each state. This allows one to reference
states, but this is specific for
the chosen implementation of states. This is undesireable. Being able to
directly refer to the abstract
states from the state machine is much easier, since it allows specifying
constraints independent of
the implementation of states.
Proposal
Define an extra standard OCL operation on OclAny called "oclIsInState", or
"oclInState" which takes a state name as
a parameter, and results in true if the object is within the specified
state. This solution adds the
desired functionality without altering the syntax of OCL.

Fixed in UML 1.3.

Summary: Implicit transitive import between packages is destructive for encapsulation management. "package Users import package TapeRecorder that import package integratedCircuit implies that package Users sees every public components of integratedCircuit". I suggest that imports becomes not transitive, so that import dependencies must be explicitely declared, or deduced from package aggregation.

fixed in UML 1.3

Summary: UML still does not develop the meaning and the semantics of protocol state diagrams. Protocol state diagrams are close to be supported by the UML metamodel, which still requires some smooth evolutions.
In a protocol state diagram, a transition related to an operation expresses that the operation can be invoked under the origin state and the "guard" condition, and that under these preliminary context, the operation invocation will lead to the destination state, under a certain post-condition.
A protocol state diagram can be entirely transformed into pre and post conditions for the involved methods.
There is a need to add post-condition to transitions for protocol state diagram.
Suggestion : add a new aggregation from transition to "Guard", called post.

Considered and declined.

Summary: Figure 15 on page 81 shows that a ClassifierRole has a single base Classifier.
However, an Instance may have multiple Classifiers (see Figure 14 on p. 67).
Indeed, the Notation Guide gives a notation for showing an Object having
multiple Classes (on p. 46) and maps this notation to an Object within an
object or class diagram, but to a ClassifierRole on a collaboration diagram.
To support this notation, and to be consistant with the ability of Instances
to have multiple Classifiers, a ClassifierRole should be able to have
multiple base Classifiers.

This requires a change to the multiplicity of the appropriate association
in Figure 15 as well as updates to the ClassifierRole description on p. 82
and the well-formedness rules for ClassifierRile on p. 84. (Actually, I think
only the words in the WF rules need to change – the current OCL rules will
accomodate the change in multiplicity of "base".)

Fixed in UML 1.3.

Summary: Semantics for dynamic invocation of concurrent activity models are
missing in the current UML version.

Fixed in UML 1.3.

Summary: There is no collection type within OCL that corresponds to the UML notion
of an ordered list without duplicates [UML Notation Guide, ad/97-08-05, p.
53, definition of "ordered"], i.e. an "ordered set".

Considered and declined.

Summary: The operation asSequence is defined to return
"A Sequence that contains all the elements from set, in random order."

This probably should read "arbitrary order" since we are not promising to
apply a "random number generator."

fixed in UML 1.3

Summary: No discription of the association between Classifier and Parameter is given.
The indicates that the association (with the implicit name of parameter)
is a set. It should also be noted that it is ordered.

Considered and declined.

Summary: There are four stereotypes shown on Dependency on page 43 of V1.1 (Figure 7).
Trace, Refinement, Binding and Usage
These are shown as peers but are in fact representative of two very different
types of partition.
My proposal is to remove Usage as a subtype of Dependency. We could than add
a new abstract type Relationship to model runtime relationships, with Associaton
and Usage as subtypes. There should be no connection between Relationship
and Dependency.

Redundant with 1227.

Summary: In section 5.20.1, a "reflexive association" is defined as an association
from a class to itself. This is consistent with the terminology as
generally used in the field.

However, in section 5.20.2, a reflexive association appears to be defined
as one that has links from an object to to itself.

This second defintion is not industry standard (including some of the
amigos work), appears to conflict with 5.20.1 and somewhat misapplied. The contingent existence of an
object-to-self link should not be changing the characterization of the
association. A reflexive assocation need not require a reflexive link.

Fixed in UML 1.3

Summary: The class "Subsystem" inherits from "GeneralizedElement" twice:

SubSystem->Package->GeneralizableElement
SubSystem->Classifier->GeneralizableElement

The only functionality it adds to Package is the ability to add operations at the Subsystem level as indicated by the statement below:

"In the metamodel Subsystem is a subclass of both Package and Classifier, whose Features are all Operations."

I would recommend simplification of the class hierarchy by merging "Subsystem" into "Package" and deriving "Package" from "Classifier":

Package->Classifier->GeneralizableElement

The attibute "isInstantiable" of Subsystem can be moved up to Package.

Considered and declined.

Summary: "Different Models can be defined for the same modeled system, specifying it from different viewpoints, like a logical model, a design model, a use-case model, etc."

This statement is too prescriptive in suggesting that the modeled system should be partitioned into a logical model, a use case model, etc. The user may wish to partition the system using some other criteria, for example on functional lines, and may wish to "package" all the views for a particular function or facility within a single package. The partitioning suggested above can be easily obtained by using UML Packages named "Logical Model", "Use-Case Model" etc. Also note that class "Model" adds no attributes or associations to its superclass - it simply suggests a groping concept.

Hence I recommend complete elimination of class "Model". The modeled system is simply a hierarchy of "Packages".

Clarified in UML 1.3.

Summary: It is not very clear how types of attributes and parameters should be instantiated. For example, consider the following C++ methods:

void Draw(Window win);
void Draw(Window* win);
void Draw(Window& win);

In all three cases the name of the parameter is "win". The types are "Window", "Window*" and "Window&" respectively. How can these types be modeled? In the first case I can imagine creating a link between the parameter "win" and the Classifier "Window". But what about the remaining two cases?

UML 1.0 represented attribute and parameter types by simple uninterpretted strings. This allowed user to specify any complex language expression for types. I would prefer that this mechanism be reintroduced. The current mechanism may be left in place in case users or tools like to specify tighter bindings to Classifier instances.

Fixed in UML 1.3.

Summary: Specifying "Interface" and "Class" as seperate metamodel classes has practical ramifications for UML tools. During analysis/design, a developer may start out by specifying a class, but then decide that it should be an interface. The reverse is also possible. This switching, from Class to Interface, or vice versa, would be very easy if "Interface" is merged into "Class" and the two concepts are distiguished by a stereotype called "interface". This recommendation is also supported by the fact that indeed the notation distinguishes the two concepts by a stereotype called "interface".

Withdrawn by submitter.

Summary: The semantics of Navigation with Nary associations is not clear. For example, If we have three Classes C1, C2, C3 linked with a ternary association.
If this ternary association is navigable to C3 : what does it means?? Does C1 and C2 instances may access to C3 linked instances through this association?
Then if the ternary association is navigable to C2 and to C3. Is this legal? What does it means? Does C1 instances may access to C2 and C3 instances? Does C2 instances may access to C3 instances and C3 instances may access to C2 instances?
Some clarification is needed there.
I imagin that Navigability makes sense in binary association, but do not make much sense with Nary associations.

Clarified in UML 1.3.

Summary: Here is the new proposal for the definition of extension points.

Extension point – a named location in the behavior specified by a
Classifier. An extension point might either be before or after an
Activity or an Action in an ActionSequence, or be a State. It is used
for specifying where additional behavior may be added, e.g. by being
referenced by an Extends relationship.

Fixed in UML 1.3.

Summary: It is unclear whether a specification for a method in a derived class should be an operation in the base class, or if the operation is redeclared and it is the derived class"s instance of the operation that is the specification.
The text on p36 ("Each method implements an operation declared in the class or inherited from an ancestor...the same operation may not be
declared more than once in a full class descriptor") suggests that it is illegal to redeclare the operation in the derived class and we must have the former interpretation. However this is not enforced by the Classifier constraint [1] on page 29. If this is really what is desired, then the constraint should be self.allFeatures... instead of self.feature...

This interpretation causes operations and methods to behave like C++ rather than Java. An operation has on

Fixed in UML 1.3.

Summary: Is there any reason why UML1.1 specifies different syntax for showing an
action in response to an event, depending on whether the event is internal
(NG 9.2.2) or external (NG 9.5.2)?

And in the latter case, what is the point of the caret? For example, 9.5.2
seems to suggest that we should probably write (yes, I"m hedging, because
it isn"t completely clear there what can be in an action expression, or
indeed what the overall syntax of a transition string is intended to be)

Fixed in UML 1.3.

Summary: 3. Another major concern is the way that Responsibilities hardly figure in these
documents. They are shown as a tagged value of Classifier and that is all.
On page 156 a responsibility is defined as a contract. This is incorrect.
The two are linked but in no-one"s responsibility and contract model
(e.g. Wirfs-Brock, Meyer) are the two the same.
Responsibilities are not even in the Index.
I believe that a standard metamodel should be equally usable for a
responsibility-driven modelling approach as for a use case or data driven
approach. The lack of good support for responsibilities (which is not that
hard - we have done it in OML as an extension of UML - see paper in <<UML>>"98
Conference proceedings) is a significant drawback to the adoption of UML
by organizations using any type of responsibility-driven method.

Fixed in UML 1.3.

Summary: 5. Finally, a suggestion. In OML (see e.g. JOOP, May 1998) we found it useful
to permit multiple stereotyping on relationships. In UML, as I understand it,
there is a restriction that only a single stereotype can be used at any
one time. Whilst care must be taken in multiple stereotyping, I would suggest
that for predefined stereotypes there should be no problem and recommend
UML consider permitting multiple stereotypes.

Considered and declined