Issue for XMI for MOF 2

The specification of XMI for MOF 2 does not describe handling of MOF's
object type, which is a supertype of ordinary class types as well as data
types. Particularly, it does not describe what XML results from the
following small example. The whole model is this:

In a package M there is one class X having one owned attribute named Y of
type TypeLibrary::Objects::Object with multiplicity 1..1.

Consider the following 4 instances of X:

1. An instance of X having Y set to the second instance of X.
2. An instance of X having Y set to the integer 3.
3. An instance of X having Y set to the string "this UNICODE string".
4. An instance of X having Y set to that same fourth instance of X.

What would an XMI-based serialization of these four instances of X look
like?

What would an XML schema for the package M look like?

The XMI for MOF 2 Specification seems to have been written as if referring to a MOF 1 Specification. For example, it defines mappings and mapping parameters for AssociationEnd, which is not in MOF 2.

Recommended Resolution: Restate the XMI rules and mapping parameters in terms of MOF 2 and UML 2.

The XMI for MOF 2 specification has not been updated to reflect one of the key goals in the alignment of MOF 2 with UML 2, which is that XMI becomes applicable to UML class models in general rather than to MOF-based metamodels only.

Recommended Resolution: Replace "metamodel" with "model" in most places within the XMI for MOF 2 specification. Also, in describing the mapping from classes, properties, etc. to XML, do not use wording that implies a restriction to a MOF context except where MOF is , such as for elements of the MOF Type Library.

The XMI for MOF 2 specification defines several tagged values for adding
data to a UML model that guide generation of an XML Schema and that guide
document production. But these tags appear to be defined as if for MOF 1.
To be appropriate for MOF 2 these must be defined using either an extension
to the MOF or UML core models (as a package that adds to MOF and/or UML
infrastructure) or they must be defined as a UML 2 profile. In either case,
an official XML rendering of the model or profile is required. And given
the big change from MOF 1, an example of such tags as they would appear in
an XMI-based XML document of an example model would be very helpful.

Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2.0, S. 3-15
There it says:

"... An instance of Company can use xsi:type to
indicate that its HQAddress is actually of type USAddress and includes a zipcode:
<Company xmi:id="Company_1" name="Acme">
<HQAddress xmi:type="USAddress" xmi:id="Address_1"
Street="Side Street" City="Hometown" zipcode="90210"
... "
The 'HQAdress'-Element has a 'xmi:type'-Attribute. Parsing this with Xerces 2.4.0 gives problems, since a 'xsi:type' Attribute is required. Derived types must be specified with the 'xsi:type'-Attibute. Maybe the line
"... An instance of Company CAN use xsi:type ..."
should be changed in
" ... An instance of Company MUST use xsi:type ..."

maybe this is just because of my ignorance, but I'm running into
a problem trying to validate documents against an XMI based schema
here, and it looks like the validator has a point.

As usual, my base document is XMI 2.0, formal/03-05-02.

Section 1.10.2 "Linking" describes the usage of XLink simple links
and XPointers to link across documents.

However, looking at the schema production rules (page 2-2 to 2-5,
rules 4g:ClassAttListItems and 1g:XMIFixedAttribs, as well as the
LinkAttribs attributeGroup in the Fixed Schema Declarations on
page 2-10, the xlink:href is never declared as a legal attribute
for complexTypes.

Hence I see why the parser (Xerces-C, when requested to validate)
complains about attempts to use XLinks in a document.

I think it is paramount that documents validate against the schema.
(Am I the first to attempt validation? Can't be.)

I realize that there doesn't seem to be a schema for XLinks yet,
so the short-term solution might be to allow the "normal" href
attribute to contain an XPointer.

As a minor nitpicking, page 1-23 gives the XLink namespace as
"http://www.w3.org/1999/XLink", whereas the W3C recommendation
for XLink uses "http://www.w3.org/1999/xlink" (note case).

Doc references are based on formal/03-05-02.

In a Schema that is produced by the XML Schema Production
rules, enforcement of multiplicities is incompatible with
the use of proxies.

According to 1.10.1, page 1-21, "Elements act as a union,
where they are either a definition or a proxy. Proxies use
the LinkAttribs attribute group to define the link, and
contain no nested elements."

However, if the org.omg.xmi.enforceMinimumMultiplicity is
true, then the generated schema does not allow the complex-
Type's content to be empty, and so proxies cannot exist in
an XML document.

As a simple fix, the 4b:ClassContents could be wrapped into
an additional choice element, as in

<xsd:choice minOccurs="0">
<xsd:sequence>
4b:ClassContents
</xsd:sequence>
</xsd:choice>

This would allow the element to be empty. However, in this
form, an XML document that contained both link attributes
and contents would still validate.

A stronger solution would be to make a choice between a
link element and contents, by removing the LinkAttribs from
the ObjectAttribs attribute group and by, in rule set 4,
defining something along the lines of

<xsd:choice>
<xsd:sequence>
4b:ClassContents
</xsd:sequence>
<xsd:element name="href" type="xsd:string">
<xsd:element name="idref" type="IDREF">
</xsd:choice>

This way, an element in a validating document could only be
either a proxy or not.

As a side note to this issue, there are obviously unpleasant
side effects when org.omg.xmi.enforceMinimumMultiplicity is
true and org.omg.xmi.element is false. org.omg.xmi.enforce-
MinimumMultiplicity=true should have the same effect as
if org.omg.xmi.element=true and org.omg.xmi.attribute=false.

Section 1.10.2.2 (page 1-23) gives the URL for the xmi namespace
as http://schema.omg.org/spec/XMI/2.0

Section 2.2.1 (page 2-2) uses http://www.omg.org/XMI instead

Document refs are against formal/03-05-02.

According to rule 4d of the Schema production rules on page 2-5,
"The type is 'xsd:string' for simple attributes".

I assume here that "simple attributes" refers to MOF primitive
types (Boolean, Integer, Long, Float, Double, String).

I wonder why xsd:string was used for all these primitive types,
when perfectly suitable data types are predefined for XML Schemas:
there's xsd:boolean, xsd:int, xsd:long, xsd:float and xsd:double
that exactly match the data types used by MOF.

I propose to make use of these existing types to strengthen the
generated schema.

Document refs are against formal/03-05-02.

Maybe it's because I'm still struggling with the details
of XML Schemas and MOF, but I'm confused with rule 4d of
the XML Schema Production rules (EBNF on page 2-4, expla-
nation on page 2-5).

• According to the EBNF, a type='xmi:Any' is an output
  option, but according to the explanation, this option
  is never used.

• The explanation goes, "The type is 'xsd:string' for simple
  attributes ..." It is not clear to me what constitutes a
  "simple" vs. "non-simple" attributes. I assume this refers
  to MOFs PrimitiveTypes, but in any case a clarification
  would be useful.

• The explanation goes on, "The type is [...] part of the
  of the value of the org.omg.xmi.schemaType tag". Why does
  it say "part of"? What should be removed from the value?

• There is also a question of precedence. I guess the
  intention is that the schemaType tag should take
  precedence over the "simple attribute" decision?

• There is no "else:" What if the attribute is not simple,
  not an enumeration, and the schemaType tag is not set?
  (Or maybe that is not possible in MOF?)

The Schema production rule for 'ClassReferences' (4.e) does not conform with the Document Production Rule 'Reference Element' (4). In the Class References the linking attribues are missing

Sending a signal after a delay

The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).

According to the UML 1.4 metamodel, a ModelElement can contain any number of
taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
it can itself contain taggedValues.

The question is: is this really intended? And if so: please explain the
semantics of such a construction.

If not, at simple well-formedness rule

self.taggedValue = { }

attached to TaggedValue would do the trick.

see above, resolved

The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
"...specifies a restricted view of a [base] classifier.." and defines "...a
set of Features, which is a subset of those available in the base
classifier, as well as a subset of ModelElements contained in the base
classifier...".

The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
"feature" association inherited from Classifier must be empty - instead the
ClassifierRole must select features from the base classifier using the
"availableFeature" association [UML 1.4, pp. 2-121].

The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
2-121] indicating "the subset of ModelElements contained in the base
Classifier, which is used in the Collaboration". There is however no
restriction in the wellformedness rules restricting the ownedElements
contents of the ClassifierRole itself, meaning that a ClassifierRole can
contain the following meta-elements:

Method
Attribute
Operation
Reception
State
ActionState
ObjectFlowState
Transition
CallState
Pseudostate
SimpleState
SubactivityState
SynchState
CompositeState
SubmachineState
SubState
FinalState
CallAction
TerminateAction
CreateAction
DestroyAction
SendAction
ActionSequence
UninterpretedAction
ReturnAction
ExtensionPoint
Stimulus
Parameter
Permission
UseCase
ProgrammingLanguageDataType
StateMachine
Comment
LinkObject
Enumeration
Association
Dependency
ClassifierInState
SignalEvent
Constraint
NodeInstance
Usage
Signal
Actor
Interface
Component
Link
Primitive
Collaboration
SubsystemInstance
ChangeEvent
Generalization
Stereotype
Subsystem
TagDefinition
Abstraction
Extend
ActivityGraph
Flow
UseCaseInstance
DataType
Object
Class
TimeEvent
ComponentInstance
Exception
Include
CollaborationInstanceSet
AssociationClass
CallEvent
Binding
Package
Node
Artifact
Model
DataValue
TaggedValue

So the question is: is this lack of restriction intentional? And if so, why
are ownedElements handled differently from features? And what is the
semantic difference between entities selected using the "availableContents"
association and those contained directly?

No Data Available

According to the UML 1.4 standard, the abstract metaclass Namespace
compositely contains any type of ModelElement, but does however state that
subclasses may restrict this containment [UML 1.4, pp. 2-45].

The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
however.

This means that Node, Artifact, Package and Model can compositely contain
the following concrete metaclasses as ownedElements:

Method
Attribute
Operation
Reception

State
ActionState
ObjectFlowState
Transition
CallState
Pseudostate
SimpleState
SubactivityState
SynchState
CompositeState
SubmachineState
SubState
FinalState

CallAction
TerminateAction
CreateAction
DestroyAction
SendAction
ActionSequence
UninterpretedAction
ReturnAction

ExtensionPoint
Stimulus
Parameter

Permission
UseCase
ProgrammingLanguageDataType
StateMachine
Comment
LinkObject
Enumeration
Association
Dependency
ClassifierInState
SignalEvent
Constraint
NodeInstance
Usage
Signal
Actor
Interface
Component
Link
Primitive
Collaboration
SubsystemInstance
ChangeEvent
Generalization
Stereotype
Subsystem
TagDefinition
Abstraction
Extend
ActivityGraph
Flow
UseCaseInstance
DataType
Object
Class
TimeEvent
ComponentInstance
Exception
Include
CollaborationInstanceSet
AssociationClass
CallEvent
Binding
Package
Node
Artifact
Model
DataValue
TaggedValue

The question is: are all these ownedElement types intended for all the
mentioned containers? Especially the first 28 in the list appear out of
place.

No Data Available

Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification.

This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away.

Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

No Data Available

The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
XMI.link.att declaration as follows:

<!-- _______________________________________________________________ -->
<!-- -->
<!-- XMI.link.att defines the attributes that each XML element that -->
<!-- corresponds to a metamodel class must have to enable it to -->
<!-- function as a simple XLink as well as refer to model -->
<!-- constructs within the same XMI file. -->
<!-- _______________________________________________________________ -->

<!ENTITY % XMI.link.att
'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
xlink:actuate (show|user) #IMPLIED xlink:content-role
CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
(embed|replace|new) #IMPLIED xlink:behavior CDATA
#IMPLIED'>

The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
these (p4-81 of formal/00-11-02).

The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
(this appendix was removed at XMI 1.2 since it was wrong and misleading).

Many of the above link attributes seem actually to be invalid:

• xml:link is invalid since this is not part of the xml namespace
• xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
  namespace
• xlink:actuate has invalid values - the standard values are
  (onLoad|onRequest|other|none)
• xlink:show is missing values - the full set is
  (new|replace|embed|other|none) [I guess it is not so much of a problem to
  exclude certain values]

No Data Available

In the case of MOF 1.4 there are far more important reasons for moving to
it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
opposed to CORBA datatypes hidden away in typeCodes. Because of this:
a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
Java APIs to metamodels and is being adopted by a number of repository and
UML tool vendors. Without an official version of UML expressed in MOF 1.4
people will have to do their own conversion with subsequent interoperability
problems

b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
Without being expressed in MOF 1.4, the UML interchange definition cannot be
expressed as an XML Schema.

c) the proper datatype model provides the opportunity to 'clean up' a
number of datatype-related issues in UML (e.g. issue 4452). And represent
UML's datatypes such as Multiplicity and MultiplicityRange as MOF
(structure) datatypes rather than MOF classes.

I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
be willing to draft a proposal for this. Is there a version of this with
already-agreed 1.4.1 changes incorporated?

No Data Available

Add action for invoking an activity

No Data Available

A StateMachine compositely contains a State through the "top" association
[UML 1.4, pp. 2-147, fig. 2-24].

However, the wellformedness rules for StateMachine state that "A top state
is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
2-158].

If that is the case, the top association should target a CompositeState, not
the more general State.

Note: of course this is not an error as such, but if a wellformedness rule
can be expressed just as easily in UML, there is no reason to complicate
matters

No Data Available

AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
fig.2-17].

The former containment obviously prevents the latter from ever being
realized.

Note: If changing the former containment from mandatory to optional, please
remember to exclude AttributeLink from other composite containments
implicitly enabled by such a change - such as being an ownedElement of a
Namespace, or a parameter of a template.

No Data Available

The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS.

For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words.

Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right.

People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it.

No Data Available

As previously mentioned in issues 3558 (Who owns an Event?) and
4734 (Event containment problem).
Based upon issue 3558 response I believe that an Event should be owned by a
StateMachine.
A composite relationship should be added between Event and StateMachine in
the UML Meta-Model.

No Data Available

[Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
they point at inputs/outputs of contained actions. Groups referred
input pins together that receive the value from the same parameter.

No Data Available

[Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes. The
specification text does not clearly explain how 'match' and 'correspond'

• dependencies are to be used. See figure 2-57, page 2-307 are used in
  the spec. Are these intended to be illustrative? Are they constraints
  on the values passing thru input and output pins. What is the
  difference between 'match' and 'correspond'?

No Data Available

[Conrad Bock] Does StartStateMachine cause the intial state to be
entered and its outgoing transition taken? Ie, what is the semantics in
relation to the RTC step.

No Data Available

The current definition of the operation Namespace.contents is:

The operation "contents" results in a Set containing all ModelElements
contained by the Namespace.
contents : Set(ModelElement)
contents = self.ownedElement -> union(self.namespace, contents)

(UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

The last line of this definition seems wrong, since the "union" operation
must have a single parameter.

The former definition of this operation did not present any contradiction
between text and OCL expression:

The operation "contents" results in a Set containing all ModelElements
contained by the Namespace.
contents : Set(ModelElement)
contents = self.ownedElement

(UML Semantics, version 1.1 page 32)

No Data Available

The proposal is to add an optional fourth compartment to the
class artifact that lists events that are accepted by that
class.

If a class is 'Active', it will have an associated
state/activity model. This state/activity model will respond to
events sent to that class. At the moment the only way to
determine what events can be accepted by a class is to observe
its state/activity model. Very clumsy!

A workaround is to list events in the operations compartment
and label them with an appropriate stereotype <<event>> for
example. This should only be a temporary solution, since events
are no more operations than they are attributes.

Events need to be part of the class definition.

No Data Available

This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards.
The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines?

No Data Available

I have a question about the spelling of the word Use Case. The different
>spellings used everywhere are a little bit irritating to me (but this may
>not be the case for other people). I think that it should be one fixed
>spelling of the word defined i UML. But even in the UML specification I
>found three different spellings on the same side: Use Case, use case and
>UseCase. In a book I'm reading they use the following spelling: Use Case
>and, when used with other words, Use-Case (Realization for example).

see above, resolved

There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

No Data Available

Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

No Data Available

There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

No Data Available

There are misprints with numeration of rules of the Instance element

No Data Available

think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

No Data Available

The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1.." and not "".

No Data Available

Wrong alphabetical order: DataValue section should be before DestroyAction section.

No Data Available

I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

No Data Available

There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

No Data Available

“self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size.

No Data Available

According to the UML 1.4 metamodel, a State can either be contained as a
"subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
concrete subclasses of Namespace restrict their owned elements to exclude
State). The latter containment does not seem to make a lot of sense.

Fortunately, the description of a StateMachine states that "This means that
a state machine owns its transitions and its top state. All remaining states
are transitively owned through the state containment hierarchy rooted in the
top state." [UML 1.4, pp. 2-153].

The question is: does this mean that a State is restricted to being
contained in a CompositeState or a StateMachine? If not, please explain the
meaning of e.g. a State contained directly in an otherwise empty Package?

If the mentioned restriction is intended, it should be stated
unambiguously so in the wellformedness rules for State:

No Data Available

n UML 1.4, an Action is only used in the context of a StateMachine or a
CollaborationInstanceSet.

In a CollaborationInstanceSet, an Action is required as the cause of a
Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
a Namespace (or in the context of a StateMachine, which is irrelevant here),
it cannot be contained in the Stimulus, nor in the Instances the Stimulus
connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
are part of. The "nearest" possible container is the Package that happens to
contain the CollaborationInstanceSet.

Intuitively, this makes no sense - used in this context, the Action is
clearly part of the InteractionInstanceSet, or the participating Instances
or Stimuli.

If this error report is rejected, please elaborate on the intended
containment structures for Collaboration instances.

No Data Available

According to the UML 1.4 standard, an Event is defined as "...a
specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
is used exclusively in the context of state machines, as triggers of state
transitions [UML 1.4, pp. 2-147, fig. 2-24].

Because Event is a direct subclass of ModelElement - and because no other
composite containments are specified for Event or any of its subclasses - it
must be compositely contained as an ownedElement in a ClassifierRole, Model.
Package, Artifact or Node (all other concrete subclasses of Namespace have
restricted their owned elements to exclude Event).

The question is: is this containment intended, or should an Event be
contained in e.g. the StateMachine in which it is used? If the currently
allowed containment IS intended, please explain the semantics of e.g. an
Event contained in an otherwise empty Package (or even Model).

No Data Available

According to the UML 1.4 standard, a Stimulus is a ModelElement representing
a communication between two instances [UML 1.4, pp. 2-106]. It is used
exclusively in the context of collaborations, as part of an
InteractionInstanceSet [UML 1.4, pp. 2-120].

Because Stimulus is a direct subclass of ModelElement - and because no other
composite containments are specified for Stimulus - it must be compositely
contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
or Node (all other concrete subclasses of Namespace have restricted their
owned elements to exclude Stimulus).

Having the Stimulus be part of any of these classes makes no sense, as it is
intuitively part of the InteractionInstanceSet.

Proposed remedy: change the association between InteractionInstanceSet and
Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
containment (with Stimulus as the part).

Alternatively, please clarify the intended semantics of each of the
currently allowed containments listed above

No Data Available

According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
contained either as an "internalTransition" in a State, as a "transition" in
a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
Package, Artifact, Node or ClassifierRole (other containers excluded because
of restrictions they make on the "ownedElement" containment in their
wellformedness rules). The latter containment does not seem to make a lot of
sense.

The question is: is the containment of a Transition as an "ownedElement"
intended? If so, please explain the meaning of e.g. a Transition contained
directly in an otherwise empty Package.

If not, it should be stated unambiguously so in the wellformedness rules for
Transition, e.g.:

self.namespace = null

No Data Available

According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
Artifact, Node or ClassifierRole (other containers excluded because of
restrictions they make on the "ownedElement" containment in their
wellformedness rules).

The questions are: what is the intended meaning of an ExtensionPoint in eg.
an otherwise empty Package? Why isn't the ExtensionPoint contained in the
UseCase it extends, as would appear more logical to the uninitiated?

Suggestion: change the association between ExtensionPoint and UseCase [UML
1.4, pp. 2-135] to an unconditional composite containment (with
ExtensionPoint as the part).

No Data Available

According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
contained either as an "feature" in a Classifier, or as an "ownedElement"
[UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
(other containers excluded because of restrictions they make on the
"ownedElement" containment in their wellformedness rules). In addition an
Attribute (subclass of Feature) may be contained as a "qualifier" in an
AssociationEnd [UML 1.4, pp. 2-14].

The question is: is the containment as an "ownedElement" intended? If so,
please explain the meaning of e.g. an Operation contained directly in an
otherwise empty Package.

If not, it should be stated unambiguously so in the wellformedness rules for
Feature:

self.namespace = null

Remarks:
========
It should be noted that the standard does make a number of partly
contradictory statements which seem to indicate that Features can not be
used as ownedElements:

Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
Classifier."
Page 2-36: "A feature [...] is encapsulated within a Classifier."
[contradicts with the statement below].
Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
case it is a feature) or an AssociationEnd (in which case it is a qualifier)
but not both."
Page 2-42: "Method is a declaration of a named piece of behavior in a
Classifier"
Page 2-45: "Operation is a BehavioralFeature that can be applied to the
Instances of the Classifier that contains the Operation.".

These statements could however be made unambiguous by adding the mentioned
wellformedness rule.

No Data Available

Because Action is a ModelElement, it may be contained as an ownedElement
[UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
Node or Collaboration (all other concrete subclasses of Namespace restrict
their owned elements to exclude Action).

Because Actions are only used in the context of either a StateMachine or a
CollaborationInstanceSet, this containment does not seem to make sense.

In order to exclude these containments, the wellformedness rules for Action
could include the following statement:

self.namespace = null

No Data Available

This issue was triggered by what seemed to be an ill-formed state machine
example which revealed a deeper lack of rigor in the spec.

The example state machine in section 6.5.10 (illustrating oclInState) does
not have an initial pseudostate within the 'Off' state. Section 3.80.2
indicates that this is mandatory:
"A transition drawn to a composite state boundary indicates a transition to
the
composite state. This is equivalent to a transition to the initial
pseudostate within the
composite state region. The initial pseudostate must be present."

[Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
object.oclInState(Off:NoPower) should have a double colon:
object.oclInState(Off::NoPower)].

If indeed it is mandatory to have an initial state where there is a
transition to a composite state (this does seem sensible for
predictability), this should be reflected in a constraint within the
abstract Syntax (section 2.12) to the effect that a CompositeState with
'incoming' Transitions must contain an initial PseudoState.

For example 2.12.4.3 contains the following which implies an initial
pseudostate, though uses the ill-defined 'default transition' as well as
'initial transition':
"Entering a non-concurrent composite state
Upon entering a composite state, the following cases are differentiated:
• Default entry: Graphically, this is indicated by an incoming transition
that
terminates on the outside edge of the composite state. In this case, the
default
transition is taken. If there is a guard on the transition it must be
enabled (true). (A
disabled initial transition is an ill-defined execution state and its
handling is not
defined.) The entry action of the state is executed before the action
associated with
the initial transition."

Proposed Resolution
-------------------

1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
composite with a transition to 'Standby'.

2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
should have a double colon: object.oclInState(Off::NoPower)

3. Add the following constraint to section 2.12.3.1
[7] A composite state with an incoming transition must have an initial
state.
self.incoming->notEmpty() implies
self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
Pseudostate | p.kind = #initial)->size = 1

4. Alter the section in 2.12.4.3 to read as follows:
"Entering a non-concurrent composite state
Upon entering a composite state, the following cases are differentiated:
• Default entry: Graphically, this is indicated by an incoming transition
that
terminates on the outside edge of the composite state. In this case, there
must be an initial state and the initial
transition is taken. If there is a guard on the transition it must be
enabled (true). (A
disabled initial transition is an ill-defined execution state and its
handling is not
defined.) The entry action of the state is executed before the action
associated with
the initial transition."

see above, resolved

UML 1.4 has no association for showing what a Partition relates to.
Typically this would be something representing a role in a process.

No Data Available

"An Activity Diagram is a special case of a state machine in which the
states represent performance of actions or subactivitities and the
transitions are triggered by the completion of actions or subactivities. It
represents the state machine of a procedure itself."

But in Section 2.13.1 it says:

"An activity graph is a special case of a state machine that is used to
model processes involving one or more classifiers. Its primary focus is on
the sequence and conditions for the actions that are taken, rather than on
which classifiers perform those actions. Most of the states in such a graph
are action states that represent atomic actions; that is, states that invoke
actions and then wait for their completion. Transitions into action states
are triggered by events, which can be

• the completion of a previous action state (completion events),
• the availability of an object in a certain state,
• the occurrence of a signal, or
• the satisfaction of some condition.
  "

The latter statement implies that (a) events other than completion of prev
activity can be triggers and (b) entire processes, not just procedures can
be modeled in ADs.

Which one is it?

No Data Available

2) Section 2.13.4.3 says

"Unless there is an explicit "fork" that creates orthogonal obect
states only one of an object flow state's outgoing transitions will fire as
determined by the guards of the transitions",

which seems to require that if you want to "feed" the object to multiple
actions, you will need a "fork" bar. But then 3.90.2.2 says:

"The same object may be (and usually is) the output of one action
and the input of one or more subsequent actions".

This would seem to suggest that a "fork" bar is not required. Please
clarify.

No Data Available

The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
exist in the UML metamodel XMI file. This causes problems for my product
which is metamodel-driven so reports an error when an import attempts to
supply a value for the non-existent reference. This is strictly speaking a
bug in the DTD (since it's not generated according to the XMI rules):
however changing the DTD might cause inconvenience for vendors who are
making use of it, and because not having the reference would make processing
the tags much harder.

At UML 1.4 the reference has been added to the metamodel, which suggests
that the metamodel rather than the DTD be fixed. However this could require
a restructuring to avoid circular package dependencies [see UML issue 3735].

The same issue applies to the 'stereotype' reference on ModelElement - again
it should ideally be added to the metamodel.

The reason I'm raising the issue on UML 1.3 is that this is the chosen
version for interoperability work. A decision is needed as to which way to
resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
1.4.

No Data Available

Probably an Action Semantics RTF Issue, but one that may be addressed
in an UML RTF.

In the UML 1.5 spec in the action semantics chapter, sections numbers
2.16 and 2.17 are duplicated. The section content appears all right
but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.

The document simply needs consistent renumbering of that chapter.

No Data Available

Section 3.90.2.2 says

"In other words when a state prodices an outpout that is input to the
subsequent state, that object flow relationship implies a control
constraint."

I take it that this is not the same as isSynch being true? That is isSynch
means that an object in an object flow is rather like a token in a Petri
net. ie once it flows out to the consuming state, its gone from its place.
Is that correct?

No Data Available

Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
oclIsKindOf, which should only take a single argument.

No Data Available

The
association in question is not named in the UML 1.4 interchange model. The
name "A_context_raisedSignal", is an artificial one that was created by the
program that created the DTD. It was using an algorithm recommended by the
MOF RTF for naming unnamed associations. However, it would seem to be wise
policy for this association to have a name. This would remove any
dependency on the vagaries of various MOF tools.

No Data Available

How does one indicate the target object for a CallState (i.e. the actual
object that executes the stated action/method)? If the target action takes
no parameters then it may be possible to say that the target object is just
the object flowing into the CallState. But what if it does take parameters?
(e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
more than one object to be flowing into the CallState and leads to an
ambiguity about which constitutes the target and which the parameter.

P.S. The actual object may be passed around by the activity diagram, so it
is not possible to show it statically on a swimlane (even if that is the
recommended way)

No Data Available

parameters of object flow states – The Notation section of the UML 1.4
Spec does not discuss it, nor is an example provided. I am still in the dark
about how parameters are supposed to be used in the context of object flow
states. Are output parameters supposed to be like reference parameters in
the Algol style languages?

No Data Available

Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
incorrect use of oclIsKindOf, which only takes one argument.

No Data Available

Swap rule 2 and rule 3 of the Binding element. It improves readability

No Data Available