The discussion on when to send BiDirIds over connections is floundering.
In part, I think this is due to a lack of precision in our thinking (and more
importantly in the adopted firewall spec we are working from).

When does a GIOP connection become bi-directional? The implementation
of the connection-initiator protocol engine must know this. Before this
event it has to treat a GIOP Request message as a protocol error and after
the event it has to dispatch the request.

There seems to be an assumption (or more than one) that there is a
relationship between an Object Reference (i.e. the programming language
artefact representing CORBA::Object) and a GIOP connection.

Whilst it is true that an implementation of the CORBA spec will provide a
relationship (else an invocation cannot result in a GIOP Request message)
the particular relationship was left to ORB implementers to provide for
flexibility of implementation. Specifically, such a relationship is not prescribed
in the CORBA specification (nor should it be).

I suggest it would be dangerous to define a GIOP connection to change state
when an Object Reference that (in some ill-defined way) "points to" a server
that is the target of that connection, undergoes a policy change (i.e. its BiDir
Offer policy is set to Allow).

Instead, a GIOP connection presumably becomes bi-directional when an
invocation on an Object Reference, with an effective Offer Policy of Allow, results
in a Request message being sent over that connection.

The specification must be explicit over which event causes the connection to
become bi-directional.

Also, can a connection cease to be bi-directional? For example if either the
Object Reference invoked above or the POA with "Export = Allow" are destroyed.
Again this would appear to be fraught with problems, leading to the assumption
that the GIOP connection, once bi-directional, remains bi-directional until it is
closed.

Lastly, the closing of idle connections and the subsequent re-connection has
hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
withstanding). This is unfortunate as an application won't be aware of the ORB
having conserved resources in this way and the ORB should not be expected to
provide session semantics that span multiple tcp connections (this is currently
stated in the description of NegotiateSession).

Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

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

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.

Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

"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?

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.

DeploymentSpecification - notation for DeploymentSpecification on the instance level

There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread)

See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199

I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends.

Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not?

The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

Add presentation option for multiple object flows between two actions, shown as one line.

Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract)

Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator.

Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections.

SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment).

Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.