Issues for UML 2.0 Superstructure Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7408: Section: 7.11.2
Issue 7409: three possibilities for aggregation kind at 7.11.2, but only two notations
Issue 7410: It is not clear what 'related to' means
Issue 7411: At «implementation Class», what does "a child of instance" mean?!
Issue 7412: What is a mapping that is not computable?
Issue 7415: Section: 9.3.3
Issue 7416: Association collaborationRole
Issue 7419: Editrial error in Section: 9.3.4 ?
Issue 7420: Description text for CollaborationOccurrence unclear
Issue 7426: Notation of enumeration literals
Issue 7430: Composite structures/Unspecified connector features
Issue 7431: Composite structures/contradictory constraint on connector
Issue 7434: Figure 109, p162
Issue 7435: Concept of 'port side' not to be found in metamodel
Issue 7441: UML 2 Super/Interfaces
Issue 7442: Components
Issue 7443: Issue in UML 2 Interaction package
Issue 7444: Issue on UML 2 Interaction class
Issue 7445: Issue in UML 2 Interaction class : Local attributes
Issue 7446: Issue in UML 2 Interaction class: Lifeline ordering
Issue 7447: Issue in UML 2 Lifeline class
Issue 7448: Issue in UML 2 Message class
Issue 7449: Issue in UML 2 Message class
Issue 7450: Issue in UML 2 CombinedFragment class
Issue 7451: Issue in UML 2 Continuation
Issue 7452: Issue in UML 2 Gate class
Issue 7549: actions
Issue 7550: All single query operations in the spec defined in OCL invalid ?
Issue 7552: Actions need to be independent from Activities
Issue 7555: State Machine Package--Compliance
Issue 7558: Semantics section of StructuralFeature
Issue 7559: There is no "precise mapping
Issue 7567: Port should specialize featuringClassifier
Issue 7590: Loop notation
Issue 7593: Wrong metamodel for internal transitions
Issue 7598: UML2 super&infra/Profiles/ownership of Image
Issue 7607: UML 2 Super/Activities/Class-Activity association missing
Issue 7608: Profiles
Issue 7614: Section: 9.3.12
Issue 7617: UML 2 Super/Interactions/ LOOP construct specifications
Issue 7618: UML 2 Super/Templates/Template substitution symbol problematic
Issue 7621: UML 2 Super/Interactions/notation for accessing a static feature
Issue 7622: UML 2 Super/Components/missing description of Connector::contract
Issue 7624: Name without a colon for Property in Composite Structures
Issue 7625: Missing notation for Behaviors in a BehavioredClassifier
Issue 7626: Redundant parameter specifications for Operation and Behavior
Issue 7627: Profiles in Compliance Level 1?
Issue 7644: . <<create>> on Usage
Issue 7645: Figures 103 and 121 use <<create>> dependencies
Issue 7646: Figures 120 and 121
Issue 7650: Bidirectional messages to a port object
Issue 7651: Compliance points - Diagram Interchange
Issue 7652: "required interface"
Issue 7654: Messages to ports with only one connector
Issue 7668: P.35 Typo in OCL definition of isDistinguishableFrom query
Issue 7669: P.58 Missing closing bracket in second constraint
Issue 7673: Active and passive
Issue 7675: UML 2 does not permit use of a state machine
Issue 7676: check the BNF example given in the text
Issue 7683: included use case wrongly referred to as the including use case
Issue 7747: multiplicity of the "role:ConnectableElement"
Issue 7748: "role binding"
Issue 7758: UML 2 Super and Infra/ defualt property of Parameter::effect
Issue 7777: Associations between interfaces
Issue 7778: CollaborationOccurence
Issue 7779: UML 2.0 Issue: Semantics of Provided and Required Interfaces
Issue 7780: UML2 Superstructure - profiles
Issue 7784: UML 2 Superstructure - cross-hair notation for nested classes
Issue 7825: UML 2 Superstructure -Incompatible use of term link
Issue 7831: UML 2 Super/Templates/Inconsistent organization
Issue 7847: Dependency associations
Issue 7848: Deployment (from ComponentDeployments, Nodes)
Issue 7850: UML2 super/CommonBehavior/Opaque behavior : bad OO modelling
Issue 7851: section 8.3.2, a "Connector"
Issue 7854: 7.3.24 Interface (from Interfaces)
Issue 7855: 9.3.6 Connector (from InternalStructures)
Issue 7856: 8.3.1 Component (from BasicComponents, PackagingComponents)
Issue 7857: .3.44 Property (from Kernel)
Issue 7858: 9.3.11 Port (from Ports)
Issue 7859: Artifact (from Artifacts)
Issue 7860: 15.3.16 Vertex (from BehaviorStateMachines)
Issue 7861: 15.3.8 Pseudostate (from BehaviorStateMachines)
Issue 7862: 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)
Issue 7863: 15.3.10 Region (from BehaviorStateMachines)
Issue 7864: 15.3.14 Transition (from BehaviorStateMachines)
Issue 7865: notational standard for {subsets x} in textual contexts
Issue 7866: inadequate definition of 'constructor'
Issue 7875: inconsistent Generalization subsections in spec format
Issue 7876: "Class" should read "Classifier" in Generalization subsection for Behaviore
Issue 7879: Associations section of InteractionUse
Issue 7881: UML 2 Super/ Classes / issue with Property::isComposite
Issue 7882: UML2 Super / Templates / ordering of subExpressions
Issue 7884: Figure 307 and Figure 308 are exactly the same

Issue 7408: Section: 7.11.2 (uml2-superstructure-ftf)

"The interaction of association specialization with association end redefinition and subsetting is not defined." Is that as good as we can do? 

There are three possibilities for aggregation kind at 7.11.2, but only two notations at 7.11.3. 

"When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association" It is not clear what 'related to' means. The text ought to spell out what this relationship is, exactly.

At «implementation Class», what does "a child of instance" mean?!

"It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." What is a mapping that is not computable?

A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances (its roles)," Roles aren't instances, are they? Does this want to say something like: A collaboration is a kind of classifier and defines a set of roles to be played by cooperating instances, ... Well, probably not. Perhaps: A collaboration is represented as a kind of classifier and defines a set of cooperating entities (its roles) to be played by instances, ...

"Association collaborationRole: ConnectableElement References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration." Do they represent roles, or are they roles? If they represent roles, how do we learn which role a particular element represents?

"Associated dependencies map features of the collaboration type to features in the classifier. These dependencies indicate which role in the classifier plays which role in the collaboration." seems to be an editorial error

The Description text for CollaborationOccurrence seems to be unclear about roles and the instances playing roles. For example, roles aren't involved in an occurrence, instances playing roles are. For another example, in the case of multiple occurrences of a given collaboration, the roles are the same, while the instances playing those roles may (or may not) differ.

Notation of enumeration literals The UML Superstructure spec often writes enumeration literal in OCL expressions as a hash mark (#) followed by the name of the enumeration literal, i.e. #public (p. 20) #protected (p. 27) #composite (p.80) #false (p. 215) #unordered (p. 216) #entryPoint (p. 469) #deepHistory (p. 474) etc. Sometimes it also includes enumeration literals consisting of a (fully qualified) enumeration name followed by '::' and the enumeration literal name, i.e. Aggregation::none (p. 69) According to the OCL 2.0 spec, the second notation is correct (see Sec 7.4.2 in the OCL 2.0 spec) Suggestion: replace all occurences of enumeration literal names with a leading '#' by the notation introduced in OCL 2.0. 

Composite structures/Unspecified connector features between ports having multiple interfaces. What happens when ports have multiple interfaces, that in addition can mix
required and provided interfaces? This is not specified. In particular, a
connector could connect two ports using only a specified subset of the
interfaces from both ports.


Recommendation:
Extend the metamodel to allow the specification of the interfaces used for a
connector between ports having several interfaces.


or


Provide a default rule for that situation, such as the connector uses the
compatible interfaces between the interfaces of both ports.

We read as a constraint for connector (composite structure)


[2] If a connector is attached to a connectable element which has required
interfaces, then the connectable elements attached
to the other ends must realize interfaces that are compatible with these
required interfaces.


And Commponents::Connector provides the following constraint:
[1] A delegation connector must only be defined between used Interfaces or
Ports of the same kind, e.g. between two provided
Ports or between two required Ports.


Both are in contradiction.



Proposed correction:


Ditch CompositeStructure::Connector constraint [2]

Figure 109, p162: according to the metamodel presented in figure 100, I think that the dependencies shown in this diagram are inverted.

the semantic variation point about port uses the concept of "port side" that I cannot find in the metamodel. May be it should be added?

03-08-02 Figure 63 - firstly there ar a couple of typoes. The interface
stereotype on IAlarm is missing <<, and sensor should be ISensor. More
serious are the implications of the caption - "IAlarm is the required
interface for any classifier implementing Isensor;
conversely, Isensor is the required interface for any classifier
implementing
IAlarm."


To me the caption sounds wrong but at the very least more explanation is
needed. Firstly, does having the association to the interface imply that a
usage dependency is required to ISensor from any class that implements
IAlarm? If so a constraint is needed to enforce that. Secondly, isn't such a
usage dependency redundant, given that its existence is implied from the
presence of the association?

The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested.

In the UML 2 Interaction package specification (UML
2 spec, dated 2003/04/10): p. 381, it is written that
"InteractionFragment is an abstract notion of the most general
interaction unit. An interaction fragment is a piece of an interaction.
Each interaction fragment is conceptually like an interaction by itself".


InteractionFragment is described as an abstract notion and Interaction
is defined as a specialization of InteractionFragment. Don't we define
normally in the other way around: the InteractionFragment is the
abstract notion and is called Interaction and the interaction is called
InteractionFragment? We can have the definition for Interaction
(previously called InteractionFragment): "Interaction is an abstract
notion of the most general interaction unit. An Interaction is composed
of at least an InteractionFragment".


Usual semantics for fragments refers to something within something else
but here, the something else is undefined.

It is not possible to represent that an Interaction frame represents a design pattern with unbound parameters

It is possible to represent local attributes to an Interaction (see Figure 8-148 p. 380) but it is not written how these attributes are treated: are they public to all the lifelines? Is it possible to have private attributes and in this case to which lifelines? Are they local to the Interaction? What happens if one of the lifeline is self? Does it mean that these parameters are owned by the self lifeline?

Lifelines are associated to Interaction but it is not possible to save the ordering contrary to the fragments.

p. 386, it is written: "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line". Figure 8-144 p. 372 presents several sizes of grey rectangles. Particularly, does it mean that method activation is performed all along the Lifeline ob1:C1? A temporal vertical axis will be added to allow several sizes of rectangles and duration of method activation.

The signature of the Message class is said to be of type NamedElement but such class allows for instance to write the qualifiedName and the visibility (see p. 11) and we do not know exactly what these two features offer here.

It is possible that the sendEvent and the ReceiveEvent are on the same Lifeline but it is not possible to specify whether the sender will receive a copy of the Message.

It is not possible to represent atomic message sending

Is it not possible to have a symbol for the setting? That could help reading the diagram.

It is not possible to write which InteractionFragment is addressed with a formal Gate

In the opinion of some, "at present, the spec bases actions on foundations described in the activities section." However the text says: "An action is the fundamental unit of behavior specification." Thus the text contradicts the opinion. If the opinion is correct, the text should be corrected to agree

This seems rather serious, but perhaps some OCL FTF person will reassure me that it's not: 

The UML 2 Superstructure spec defines additional query operations for a number of metaclasses. For example, the following query is defined for the metaclass Element: 

     Element::allOwnedElements(): Set(Element); 
          allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) 

Another example is the query defined for ProtocolTransition: 

     context Region::belongsToPSM () : Boolean 
          result = if not stateMachine->isEmpty() then 
                               oclIsTypeOf(ProtocolStateMachine) 
                         else if not state->isEmpty() then 
                               state.container.belongsToPSM () 
                         else false 

Notice the different forms used to define these two queries. The first one uses the name of the operation to store the result while the second uses the OCL reserved word "result". In the spec, there many queries that use the first form and only three cases of the latter form. 

A review of the OCL spec with respect to this issue -- as far as I can tell -- indicates that there are three valid ways of specifying a query as shown by the following two examples: 

(1) using body expressions (note the 'body:' prefix in the second line): 
      
    context Element::allOwnedElements(): Set(Element); 
          body: ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) 

(2) using postconditions (note the use of the reserved word 'result' following the 'post:' prefix): 
      
    context Element::allOwnedElements(): Set(Element); 
          post: result = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) 

(3) using auxilliary definitions (note the 'def:' prefix in the second line): 
      
    context Element 
          def: allOwnedElements(): Set(Element) = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) 

Unfortunately, neither of the two forms used in the spec conform to any of these formats, which seems to imply that every single query operation in the spec that is defined in OCL is invalid! There are 73 such queries at the moment. 

Can someone from the OCL team shed light on this? 

All single query operations in the spec  defined in OCL invalid ?

If we take Activity as fundamental, and consider that we can't specify something that happens with Action alone, shouldn't we remove the first sentence of the second paragraph of 11 Actions : 11.1 Overview : Basic Concepts:


     "An action is the fundamental unit of behavior specification."

Please accept the following as an Issue for the UML 2 FTF. 
  
State Machine Package--Compliance 
  
Compliance with the state machine package is too onerous for 
many vendors.  
  
There is no need--for many of us--to include choice points, entry 
points, and other elements. 
  
An suggested layering would consist of: 
Layer 1: Initial pseudo states, states, final states, events,  transitions. 
Layer 2: Stuff required to support hierarchy 
Layer 3: Stuff required to support orthogonal regions. 
Layer 4: All the rest. 

The Semantics section of StructuralFeature says "A structural feature specifies that instances of the featuring classifier have a slot..."
That's wrong.  It is instance specifications of the classifier that have slots, not instances.

The RFP requires that "Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. ... In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing OMG specifications." [5.1.6] "Since UML has a large installed user base all proposed changes should consider backward incompatibility issues." [6.2] "... gratuitous changes to the current UML specification are strongly discouraged." [6.3] "Wherever changes have adversely impacted backward compatibility with previous specifications, submissions shall provide rationales and change summaries along with their precise mappings." "Proposals shall minimize the impact on users of the current UML 1.x, XMI 1.x and MOF 1.x specifications, and shall provide a precise mapping between the current UML 1.x and the UML 2.0 metamodels." "Proposals shall identify language elements to be retired from the language ..." [6.5.1] UML 2 removes three essential elements of an existing OMG specification, the UML 1.5 action language: GroupAction, ConditionalAction and LoopAction. No reason is given. The UML 2 specification notes that "conditional nodes replace ConditionalAction from the UML 1.5 action model" but gives no rationale for this change. There is no mention of the removal of GroupAction and LoopAction. There is no "precise mapping between the current UML 1.x and the UML 2.0 metamodels" for GroupAction, ConditionalAction and LoopAction. 

Apparently a structural feature can be on more than one classifier,
because the multiplicity of /featuringClassifier is 1..*.  Not all the
subtypes of StructuralFeature narrow this to one, or change it to strong
ownership (eg, Port).


Is it intentional that structural feature have more than one
featuringClassifier, and not be owned by that classifier?  If not, Bran,
please assign this to classes.  Otherwise, it is problem for Ports as
well.

I am putting together an example of a sequence diagram using the loop
combinedFragment. The spec seems confusing. Just where does a guard
condition that is not the minint or maxint get placed?


According the CombinedFragemt definition, I can describe a minimum and
maximum number of times to perform the loop. "The Guard may include a lower
and an upper number of iterations of the loop as well as a Boolean
expression." I can also describe a guard condition. However, the notation
describes a syntax like LOOP (minint, maxint) with no extra guard.


Do I place the extra guard as an interaction constraint in a region as shown
in figure 333. Is this allowed? Do I only get one interaction constraint
(either the min,maxint or the separate interaction constraint in the body of
the loop combined fragment?


I would like to say something like LOOP 1, * [status = notFound] or LOOP
(1,*,status = notFound). I suppose I could say LOOP (1,[status = notFound]).
All of these should say that the loop interaction is performed at least
once. After that if the status is "notFound" then the loop continues
otherwise the loop terminates.

Description: In the UML 2.0 statemachines an internal transition is modeled as a transition owned by a region. 

It is wrong that in order to specify an internal or local transition one needs

to instantiate a region. This makes any state with local transitions a composite state which is wrong.

Local/Internal transitions shall be owned directly by states and not via regions.

In  the current UML2metamodel, the ownership of the new Image metaclass is
not specified.

An activity diagram is a graphical form of method, however there is no way to assign them to a class that would contain such a method.  This may be more general than activity diagrams.  For example, the same could apply to sequence diagrams.  Since organizing structure and behavior by class is a fundamental OO concept, we need to have a way to associate UML-expressed methods to the “organizing” class.

Issue with tags (i.e. properties of stereotypes); I can't see an example of
display of multi-valued tags or tags whose types are UML metaclasses. There
should be a normative mechanism for displaying these.

Instance values are depicted using the same icon as for the defining classifier. However, for parts this convenient notational convention is not defined. Allow to use the same icon as for the classifier that is the type of the part, when representing the part (modulo the namestring, which is necessarily different, as is the case with instance value also). As an example, a part that derives from an active class could then optionally be shown with the vertical side bars highlighting its active nature.

This issue is submitted on behalf of Craig Larman (see signature at the end fo this e-mail): 

Current: The LOOP keyword, used in sequence diagrams in a frame, has the syntax LOOP, LOOP( repeat ), or LOOP( min, max) 
  
  
Problem: Iteration over a collection of objects, sending the same “doX” message to each member is a very very common idiom, so it would be nice if the UML had an easy notation to support this (and otherwise, how will you reverse engineer to code to the right diagram case, or vice versa? It is currently not clear…). AAt present, it is not clear how to say “for i = 1 to collection.size”, nor is there support to allow this ‘i’ loop variable to be reference in a lifeline **selector** 
  
  
Solution: 
1.        change the LOOP syntax to (in its fullest form),  LOOP( <varName>, <start>, <end>, <increment>) e.g., LOOP( i, 1, 10, 1), or LOOP( i, 10, 1, -1). Increment should default to +1. 
a.        Also <start> and <end> may be expressions referring to participants in the interaction, such as end = lineItems.size where lineItems is a collection of SalesLineItem objects. Note that there is already syntax for a “max” (similar to <end>), and one aspect of this change is making (or ensuring) it can be an expression involving lifeline participants, not just a constant. 
  
  
2.        allow a lifeline contained within the frame to have its selector refer to the LOOP var. e.g., “ lineItems[ i ] : SalesLineItem” to indicate selecting one SalesLineItem from the lineItems collection, given the current value of ‘i’. Note that a selector such as “lineItem[ i ]” is already allowed in the spec (and there are examples in the spec). this request is for tying the ‘i’ variable to the LOOP construct. 
  
Variant Solutions: 
Perhaps the upper-bound can be handled in the LOOP guard instead. E.g.,  [ i < lineItems.size ]. However, in this case, i still need a way to indicate the incrementing of ‘i’, and the ability to legally refer to “i” in the selector “lineItems[ i ]. 
  
  
i attach a picture to illustrate. 
  
 
  
  
  

Templates use an arrow symbol inline with the text to show a binding of a template parameter 
  
Problem: typographic problem. the arrow symbol is not present in many common fonts (times, arial, Helvetica, …). Therefore, one must use another font for this character (e.g., ZapfDingbats). That will create some fuss at several levels, related to fonts, usability, and tools. It also creates more dependency on printing with commercial printers; if you’re a book author, you know that adding more fonts to a book is another source of error. Yes, solvable, but nice to simplify. 
  
Solution: use a simple symbol part of the basic character fonts (e.g., in Arial, …). I suggest ‘= ™ 
  
Example: ArrayList<T = Person> 

Context: 
  
Invoking static or class methods on classes is incredibly common. If you look at a typical Java or .NET app (or the libraries themselves), or even Smalltalk, between 5-10% of the calls are class method calls. If you reverse engineer any Java or C# code to a sequence diagram, one should be able to see what’s a class method call on class X, versus instance calls. When you creatively draw an interaction diagram, the reader (a human or tool) should be able to know when something is a static call on a class. 
  
There are literally thousands of class methods in the Java and .NET core libraries. Any significant java app makes thousands of calls to these many library class methods, in addition to hundreds or thousands of calls to app-defined class methods. 
  
  
Problem: 
  
This is basic stuff, but the interaction diagram notation is not clear on how to show this. Tool vendors need a solution ASAP; many are in beta, and want to know the “correct” way asap, during rev eng of java code to a seq dgm, to show such calls. E.g., given the basic java code that i show in the attached example picture, how to rev eng the code to a seq dgm. 
And my book, that teaches intro OOA/D, has to show the solution – i’ve got an aug 30 publishing deadline. 
  
  
UML 1 had a way to solve this in interaction diagrams, with underlined/not underlined labels in the boxes, where not underlined indicated it was a class, and thus a class method call. But of course, that convention doesn’t work with UML 2 lifeline boxes. 
  
  
The problem can probably be solved with the appropriate label in a lifeline box, and ensuring that the context composite structure diagram relates appropriately. 
  
  
Solution: 
  
I’ve asked this question to Jim Rumbuagh, who gave a “convention” solution i very much like, for the lifeline box label: “ClassName : Class ” 
  
  
e.g. “Font : Class”,  “Collections : Class” or perhaps “Font : Type” if reverse engineering from C#. 
  
  
e.g.., going meta and viewing the class as an instance of class Class. 
  
  
In Java and Smalltalk (for example) all classes are indeed instances of class Class. In .NET, they are instances of class Type. 
  
  
Then the lifeline box still represents an instance (of class Class or Type or whatever), and the “class messages” are still instance messages. 
  
  
I attach a diagram that gives a sequence diagram example. 
  
  
And–and i consider this important–the solution should be obviously understandable and straightforward to a novice, as is Jim’s. It corresponds to an OO programmer’s mental model. I encourage the committee members to choose a solution that is simple and obvious, that maps straightforward to the language most OO developers are working in – Java or C#, not an obscure solution. 
  
  
An outstanding problem, with bigger ramifications, is the names “Font” and “Class” in the related context diagram. Where are they defined? Of course, most of these classes will be from the core Java or .NET libraries (each have about 20,000 classes). I propose being able to declare a convention something like “assume that in this composite structure diagram there is an implicit import of the classes needed from the java libraries (or other libraries).” 
  
  
Well, some convention like that is needed in any event, because we are frequently calling instance methods on instances of java library classes – in a typical java app, 30-50% of the calls are to objects from the library. You can’t expect (because it would be too fussy/awkward/unusable) a UML modeler working in Java to re-create or have to explicit import specific parts of the Java libraries (or various common 3rd party libraries) every time they want to refer to library objects – which is frequently. 
  
  
i attach a picture to illustrate. 
  

The association end Connector::contract, specified in figure 78 on page 135 is not documented in the description for Connector

In Composite Structures, under 9.3.12 Property, the following
paragraph under "Presentation Options" under "Notation" is
inconsistent with the rest of UML in creating a special
interpretation of a missing notation element:


  "A property symbol may be shown containing just a single name
  (without the colon) in its name string. This implies the
  definition of an anonymously named class nested within the
  namespace of the containing class. The part has this anonymous
  class as its type. Every occurrence of an anonymous class is
  different from any other occurrence. The anonymously defined
  class has the properties specified with the part symbol. It is
  allowed to show compartments defining attributes and operations
  of the anonymously named class."


The simple omission of notation elements is part of the option
in virtually all UML diagrams to elide elements that aren't
relevant or are defined and shown on other diagram views.
Implying something to be created by the *absence* of an
element breaks from user expectations.


In this case, the most natural expectation of a simple name on
a property box, without any colon, is that the string is just
the name of the part or property, and that the type for the
name, ordinarily shown using a ":Type" string, has been omitted
from the diagram.


The simplest way to resolve this issue is just to remove this
paragraph from the specification.  The specification would then
revert to the default interpretation of a missing notation
element, which is just that it isn't shown on a particular
diagram view, not that it doesn't exist.


The application of Composite Structure diagrams to systems
engineering, in response to the UML for Systems Engineering
RFP, expects to use all the flexibility that UML provides to
include or not include diagram elements on particular views
of a complex system, to avoid cluttering the many partial
views that might be needed.  Resolution of this issue is
essential to avoid having a different rule for a name without
a colon in standard UML vs. its application to systems
engineering.

There's no notation specified for showing the ownedBehaviors of a BehavioredClassifier. This could be done by using another compartment in the context classifier, but this is not mentioned, nor is the syntax for the behavior and its parameters specified that I could find. 

A Behavior can be defined in the context of a BehavioredClassifier where it must have a specification BehavioralFeature which defines its parameters and return value. A Behavior may also stand alone in order to represent procedural-based models in which case the Behavior specifies its own parameters and return result. 

There is a constraint that specifies the parameters of a Behavior in the context of a BehavioredClassifier must match the parameters of its specification BehavioralFeature. However, parameter matching is not explicitly defined. Is it match in mode, name, type, multiplicity, constraints, etc., or just type? 

A better solution would be to disallow behavior parameters if the behavior has a specification. This would eliminate the need to redundantly specify the parameters for a behavior if it has a specification, and then enforce a constraint to have them match. 

Specifically: 

1. section 13.3.3, remove constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature. 

2. add a new (second) constraint: [2] A Behavior with a specification BehavioralFeature obtains its parameters from the BehavioralFeature and cannot specify its own parameters. 

3. add a new constraint: [3] A Behavior with a specification BehavioralFeature cannot have any redefinedBehaviors. The redefinitions come from the BehavioralFeature.

It has been suggested that Profiles should be part of Compliance Level 1 (Basic Level) rather than part of Compliance Level 2 (Intermediate Level) as currently defined. The rationale is that it gives any UML user the ability to specialize UML. We already know from experience that UML is almost ALWAYS specialized when it is used -- implicitly or explicitly. Given that, we might as well provide users at all levels with the ability to use profiles. I feel that this is a reasonable suggestion. 

1. <<create>> on Usage is defined in the standard stereotypes and in the
    retired stereotypes.  It is used in Figure 103 and 121 of the FAS.

 Figures 103 and 121 use <<create>> dependencies, which do not apply to
    the example.  Standard stereotypes defines <<create>> for
    BehavioralFeature as:


      "Specifies that the designated feature creates an instance of
       the classifier to which the feature is attached. May be
       promoted to the Classifier containing the feature."

 Figures 120 and 121 underline the association names, which doesn't
     seem consistent with the notation for instances in Figure 21.

How do required and provided interfaces on a port support messages from
both inside and outside the composite?  Messages to a port object sent
from the inside of the containing composite must be declared in the
required interface of the port object, but usually messages sent to an
object must also be declared in the provided interfaces.  Is there a
special case for ports?  Didn't see anything in the spec explaining
this.

From letters from Bran Selic and Pete Rivett I learn that the Superstructure
FTF plans to revoke Diagram Interchange as a compliance point to UML 2
compliance. As the Chair of the Diagram Interchange FTF I urge you to make
compliance Diagram Interchange a necessity for full compliance. 


In all discussions I attended it was always pointed out that the ability to
exchange UML diagrams compliant to a standard using XMI was the single most
important issue missing in UML 1. The Diagram Interchange specification was
specifically designed to solve this problem. It is of essence that Diagram
Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2
standard is drastically reduces in its value.


The Diagram Interchange specification is of high quality. It is fully
implemented by Gentleware to provide a reference, we have made cross checks
with various other vendors that confirm high quality and interchangability.
May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has
implemented an XSLT transformation from XMI to SVG. It is available on his
web site at www.jeckle.de. 

The concept of "required interface" is discussed but not clearly specified. 1. Shouldn't a specialized "Usage" be derived to model those related to interfaces? 2. May Classifier have required interfaces or only BehavioredClassifier? 3. A derived role or at least an OclHelper should be provided to get the required interfaces.

The semantics of Port says:


 > If there is a connector attached to only one side of a port, any
 > requests arriving at this port will terminate at this port.


but it also says: 


 > For a behavior port, the instance of the owning classifier will
 > handle requests arriving at this port (as specified in the behavior
 > of the classifier, see Chapter 13, Common Behaviors), if this
 > classifier has any behavior.


And presumably for non-behavior ports, the message could be forwarded to
the intefaces of the owning classifier.  So the first statement above is
incorrect, isn't it?

There is a typo in the OCL definition of the isDistinguishableFrom query. The 2nd line of the definition states:

 

isDistinguishable = 

 

This should read as:

 

isDistinguishableFrom = 

Missing closing bracket in second constraint on P.58

 

It reads:

 

classifier->forAll(c | 

(c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)

)

 

And should read:

 

classifier->forAll(c | 

(c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1))

)

I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification.  They seem to mean various things to different people.  I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 

1. They may or may not have their own thread of control  (this is often called "active" but why not be more direct?) 
        1a. Which may be single or possibly multiple (not sure if this is relevant) 
        1b. Which may start automatically or may be explicitly started (but why whom??) 

2. They may or may not have a queue for incoming events  (often associated with #1, but we can decide whether they are completely linke) 

3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 

4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) 


Note that various combinations of these are possible, so an object could be both "active" and "passive". 

But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? 

The current specification has a lousy definition of the terms, one that is circular.

It appears UML 2 does not permit use of a state machine as a specification technique for a class. The support for use of a state machine to specify a method does not help: that state machine won't be a method. The support for use of a state machine to specify a classifier behavior does not help: since that state machine is not a specification of code that gets invoked when an object is created. Example: An architect specifies a state machine for a class. This is not the specification of a method, nor of an independent computation belonging to an object of that class, but of the overall behavior of an object of that class. That state machine responds to four events. As a refinement of that model, a tool or a designer generates four event taker method specifications, which together implement the specified state machine. Those methods are then hand coded according to that specification, or perhaps another tool generates the code for those methods. An object of this class "does nothing until it [one of its event taker methods] is invoked by some other object, then it does its thing, and then it returns and again does nothing." The behavior of that object is fully specified by this state machine. This state machine is not the specification of a method, nor is it the specification of a classifier behavior ("When an instance of a behaviored classifier is created, its classifier behavior is invoked."). But the opinion of experts, expressed in FTF discussions, is that these are the only two uses of a state machine permitted by the FAS. This state machine is not intended to "to describe or illustrate the behavior of an object." It is intended to fully specify that behavior. It is not a protocol state machine. Proposal: Specifically authorize this use of a state machine. 

I'd check the BNF example given in the text. While an order designator can be used with the grammer shown, the uniqueness designator seems to just be hanging out in limbo.

Section 16.3.5 Include (from UseCases) 
 
The Semantics section for Inlcude, page 603 in the 042808.pdf convenience document, says "An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case."
 
For "including" read "included (or addition) " and for "base" read "base (or including)".
 
The parenthetical "addition" is needed because this is the term used in the abstract syntax, which does not have "included" as a rolename. Likewise, the abstract syntax does not recognize a role called "base use case" but calls it the "includingCase".
 

It's not clear whether the multiplicity of the "role:ConnectableElement" role multiplicity is [1] or [0..1]. I think it should be [1], as stated in the role description but figure 96 shows "0..1" and the ConnectorEnd constraints descriptions aren't clear on that point

If a "role binding" is describe as a mapping between ConnectableElements, Collaboration::Classifier should derive from InternalStructure::StructuredClassifier rather than from Kernel::Classifier

I think it makes sense that the default value of Parameter::effect be 'read' (currently it is not specified). 

The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows
an association between example interfaces IAlarm, ISensor, and has this
caption:


  IAlarm is the required interface for any classifier implementing
  Isensor; conversely, Isensor is the required interface for any
  classifier implementing IAlarm.


The text description says:


  A set of interfaces constituting a protocol may be depicted as
  interfaces with associations between them


Is this just notation, or are associations really in the model?


  - If it is just notation, what is the model?


  - If it is the model, isn't it overly restrictive?  The modeler's
    intention might be that these are both required interfaces,
    declaring that the two support classes will include an association
    between them.  I thought interface were extended in UML 2 to include
    associations generally.

The ability for a CollaborationOccurence to be owned by an operation is stated in the CollaborationOccurence semantics but doesn't appear in the metamodel (c.f. Figure 100). More I think that the constraints specified for a CollaborationOccurence should be clarified to to take into account that the owner may be an operation.

In your presentation in Bertinoro you had 
a figure representing the mapping of the classic 'lollipop-notation' for 
provided and required interfaces into stereotyped dependencies between 
the port and the interfaces. I would like to propose that a similar 
picture be included in the specification to make the intent of the 
specification clearer. A good place for this figure would probably be 
9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

From the current spec I really can't work out what to implement. For what
it's worth, this is what I think should be there: 
Properties can be typed either by MOF primitive types (the ones used in the
UML metamodel, such as string, boolean and enumeration and subtypes), or by
UML metaclasses. This is not only consistent wth UML 1.x, it also is likely
to be the most easily implemented - vendors already need to provide a UI for
editing boolean properties etc. and editing properties typed by metaclasses
is easy - just use a list control to reference existing model elements. 
The spec seems to state that properties can typed by arbitrary model
elements.("However, it is possible to have
associations between ordinary classes, and from stereotypes to ordinary
classes")
How is a tool supposed to know what to do with it - it looks like the
current spec allows a stereotype property to be typed by something like an
Actor, not the actor metaclass, but some specific actor - what use is that? 
The more I read about this the more I'm convinced that we will never get
interoperability, unless we tighten the rules as I suggested above.

The cross-hair notation is specified as an alternate notation for showing
the containment of classifiers in packages, but there is no mention of the
use of this notation for nesting classifiers within classes - this notation
was present in UML 1.4 and so for backwards compatibility reasons should be
in 2.0 also. I also note that the cross-hair notation does not appear in the
diagrams section of Classes.

The Semantics of Association says:


"An association declares that there can be links between instances of the
associated types. A link is a tuple with one value for
each end of the assocaition, where each value is an instance of the type of
the end."


but in Semantics of Connector the spec states:


"Specifies a link that enables communication between two or more instances.
This link may be an instance of an association, or
it may represent the possibility of the instances being able to communicate
because their identities are known by virtue of
being passed in as parameters, held in variables or slots, or because the
communicating instances are the same instance."


The small issue is that link is used in incompatible ways which is
confusing. The bigger issue is that Connectors may be typed by Associations
and even if there is no actual type, one is "inferred". I would have thought
that an instance of a Connector (a link) typed by an Association would have
to be an Association Instance; one possible interpretation of this is that
an instance of a Connector is only an Association Instance if it has a
"non-inferred" type, although the value of "inferring" a type seems dubious
if that is the case. The spec should clarify the situation.

The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

I think, that Dependency associations must subset (or specialize?): Dependency::client - DirectedRelationship::source Dependency::supplier - DirectedRelationship::target

Deployment (from ComponentDeployments, Nodes): Associatons: • configuration : deploymentSpecification [*] The specification of properties that parameterize the deployment and execution of one or more Artifacts. This association is specialized from the ownedMember association. There is no "ownedMember" association in inheritance hierarchy of Deployment.

When we see the attributes of OpaqueBehavior :
• body : String [1..*] Specifies the behavior in one or more languages.
• language : String [*] Languages the body strings use in the same order as
the body strings.


We can state that this is bad modelling practice : two attributes are sets,
which elements have to be related 2 by 2 according to an ordering rule. This
is even bad database modeling practice (violation of the 1st normal form
rule).



Proposition :
Create an additional class "Language expression", having 2 attributes :
Language and Body, and relate it to "OpaqueBehavior" instead of these two
guilty attributes.

In section 8.3.2, a "Connector" is defined as either a "delegate" or an "assembly" connector. The definition is based on "required port" resp. "provided port". However, these terms are not defined in the document; furthermore, they do not make sense at all. In section 9.3.11, a port is defined to have "provided" and/or "required" interfaces, which are well-defined. However, in the whole document is no definition for a "provided port" or "required port". From my understanding, such a thing does not make sense at all. A port is a point of interaction, and the terms "provided/required port" are non-sense. Please, provide a definition of "provided port" and "required port", or remove the corresponding sections. I hope I could help You with Your great work, Yours, Dr. Uli Margull PS: I came across this topic when working for the AutoSAR standard (car manufacturer and OEMs). They have the same unclear usage of "provided port" and "required port", and looking into the UML standard 2.0 did not help me to resolve this issue.

A.
 
            Association:
 
                        redefinedInterface : Interface – subsets Element :: redefinedElement
 
Element does not have member redefinedElement. Must be: “RedefinableElement :: redefinedElement”. 
Or  better yet, change to “Classifier :: redefinedClassifier”. 
 
B.
 
            Association:
 
                        ownedAttribute : Property – subsets Namespace.ownedMember and Classifier.feature
 
instead of Classifier.feature, ownedAttribute subsets Classifier.attribute.  See Figure 9 where Classifier.attribute:Property  is annotated as {subsets feature} 

Association
 
                        redefinedConnector : Connector [0..*] – subsets Element.redefinedElement

Element has no redefinedElement association. Change to RedefinableElement::redefinedElement 

 Association:
 
                        ownedMember : PackageableElement [*]
 
Conflicts with Namespace :: ownedMember. Perhaps add a word about redefine?

Attribute:
 
                        isReadOnly : Boolean

This is redundant.  Superclass of Property – StructuralFeature (from Kernel) has the same attribute with same default value. I think member isReadOnly can be inherited from StructuralFeature, and no needs define it in the Property. 

A. All associations here are defined without multiplicity  
 
 the multiplicity is given in the syntax diagram as * so [*] should be added to the text spec.
 

  B. redefinedPort : Port – subsets Element.redefinedElement. 
Element does not have member ‘redefinedElement’, must changed to be RedefinableElement::redefinedElement or (better yet) Property::redefinedProperty  

P#224 – Figure 127 – Artifact (from Artifacts)
 
P#769 – Figure 467 – Artifact (from Artifacts)
 
Must be “Artifact (from Artifacts, Nodes)” because there is no “Artifact (from Artifacts)” in this document. 

15.3.16 Vertex (from BehaviorStateMachines)

            Associations:

                        container : Region [0..1] – subsets Element::owner

 

 This is  a  mistake, because Element::owner  is already subsetted in parent of Vertex – NamedElement::namespace.

 

Must be “subsets NamedElement::namespace”

15.3.8 Pseudostate (from BehaviorStateMachines)

            Associations:

                        stateMachine : Statemachine [0..1] – subsets Element::owner

 

Like above: must be “subsets Vertex::container”. 
Type of stateMachine must be StateMachine (letter ‘M’ must be capital). 

1.         Attributes:

                        /isComposite

                        /isSimple

                        /isSubmachineState

 

defined without a type ( it must be Boolean).

 

2.         Associations:

                        redefinedState : State [0..1]

 

Must  be  subsets RedefinableElement::redefinedElement.

 

3.

            region : Region  [*] – subsets ownedMember

Must be “subsets Namespace::ownedMember”.

 

4.

            /redefinitionContext : Classifier [1]

This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

 

5.

            region : Region [0..1]

Second member named ‘region’ with another multiplicity and different semantic.

 

6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

 

15.3.10 Region (from BehaviorStateMachines)

            Association:

                        /redefinitionContext : Classifier [1]

Must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

 

1.         Association:

                        /redefinitionContext : Classifier [1]

Must redefine RedefinableElement::redefinitionContext (different multiplicity).

2.

                        container [1]

Defined without type (but (wonder?) with multiplicity!). J

 

3.

Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

The text of the UML 2 Finalized Superstructure spec randomly uses dots and doubled-colons,  as separator characters,  in specifying the metaattribute of a metaassociation end,  {subsets <x>}  
It also randomly uses or does not use (a) capitalization,  as in 'Subsets' and 'subsets', and (b) curly braces.  These issues may seem trivial to some human readers but are of consequence wrt any attempt to programmatically navigate structured text..

Details:

The dot sometimes used as a navigation path separator,  as is correct for OCL, and in other contexts the UML namespace separator, the double-colon, is used.

Instances of the usage of the dot are at 7.3.5 BehavioralFeature, Association, ownedParameter (which also shows random variation,  in not including the curly braces that sometimes set off the subsets property in the textual spec), and of the doubled-colons, at 17.2.1 InformationFlow,  Associations target:NamedElement[ ] {Subsets DirectedRelationship::target} which also shows the occasional use of the curly braces.

It seems that, since subsets is a relationship between the sets of instances that can qualify for occupying an end of an association, the dot notation, which is used for instance navigation in OCL and in familiar OO programming languages, is correct.

Another reason for thinking the dot is correct is that the namespace separator implies that the named association end is part of the namespace of the Classifier at the other end, and that seems to imply that the end is navigable.  There are some instances in the spec where the namespace separator is used, but wrt a non-navigable end.

Question: 
what is the "standard" notation in the context of text outside of diagrams?
Proposal:  
Revise the notation section for Association to make it explicit that the notational standards given there apply in both diagrams and text, and revise the text for consistency. The problem may be that the notational standard does not say whether it applies to text, diagrams, or both.

The current "definition" of constructor, section 9.3.1 "Notation"
subsection (page 75) leaves some issues. 


The description proposes a notation for associating an instance
representation with a "constructor", noting only that a constructor is
an operation that "must have the class as its classifier." 


Given a list of operations (_ _ is static):


_+ newInstance(name:String):Foo_   
_+ getFooForName(name:String):Foo_
+ identity():Foo
+ clone():Foo
+ Foo(name:String):Foo
_+ Foo(name:String):Foo_
_+ make(name:String):Foo_


Any of the above operations could be viewed as a constructor under the
definition provided. The only marker suggested in the superstructure
specification to clearly specify a constructor is a "<<create>>"
assocation from the default instance created by the constructor. 


Assuming foo:Foo:
Foo::newInstance("bar")
foo.clone()
Foo::make("bar")
Foo::Foo("bar")
In the predominant commercial OO languages, newInstance(...) and clone()
are delegating the actual creation to Foo::Foo(...), but clone or copy
may be the vehicles of instantiation in languages like io or self.


If UML had a specific marker for constructors, like the stereotype
"<<constructor>>" then OCL and other notations and tools could treat
constructors specially where useful.


The OCL specificaion already includes notation for Tuple and Collection
"constructors" to specify what are essentially Tuple and Collection
constants. Providing a standard marker for constructors might reliably
allow similar clear constructs for all other types (ex. if baz >
Foo(1.30, Currency::USDollars) then ...).

Reviewing of the new "generalization" subsections in the UML 2 spec, some are pointing down the inheritance hiearchy and some are pointing up.  
 
 Section 6.5.1 Specification format says these sections are supposed to list the direct generalizations of a concept (see page 14, all the concepts "immediately above" in the hierarchy), yet I find many examples where metaclasses listed in Generalization subsections are the specializations of the concept.
 
For example, Section 7.3.3 for Association correctly lists Classifier among its Generalizations, but 7.3.6 BehavioredClassifier(from Interfaces) lists BehavioredClassifier(from BasicBehaviors) thereby pointing down the hierarchy.
 
Other examples are too numerous to list.  The issue reported below may be another instance of this broader issue.

Reference to the October 2005 UML 2 Superstructure Specification as delivered out of the FTF.
 
Issue name: "Class" should read "Classifier" in Generalization subsection for BehavioredClassifier.
 
Description:
 
BehavioredClassifier text specification on page 468 lists generalization as Class (from Kernel)
 
However, the syntax diagram Figure 311 on page 459 shows the generalization of BehavioredClassifer as Classifier(from Kernel)
 
Figure 314 shows Class as a specialization, not a generalization, for Behaviored Classifier.
 
I suspect 'Generalization Class (from Kernel)' on page 468 is an error in the text and it should read 'Generalization Classifier' (from Kernel).

Associations section of InteractionUse: Type of argument must be Action instead of InputPin. Add Property string {ordered}.

There is a serious inconcistency in the specification with respect to Property::isComposite. 

In the description of Association, it states that "Composition is represented by the isComposite attribute on the part end of the association being set to true". 

But in the discussion of structured classifier parts or the discussion of profile extensions it implies the opposite. isComposite should be true for the end that is owned by the whole. 

This will have a serious impact on interchange (among other things) if different implementations put the "black diamond" on different ends of the composition...

StringExpression:subExpression should be ordered

Figure 307 (Invocation Domain Model) and Figure 308 (Communication Domain Model) are exactly the same ("Copy&Paste error"). Communication Domain Model should be replaced