Issues for which there is not a valid OMG list (because of typos, or issues for which there is no RTF in existence).

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

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

Issue 1213: <<local>>, <<parameter>>, <<global>>, <<self>>, not well supported "derived" not defined
Issue 1681: Syntactic category <Factor> includes <Ident> and \<Ident>...Why? Section 2.4.6 : positional notation wrt to unions
Issue 3283: UML RTF 1.4 Issue: <<primitive>> keyword/stereotype UML RTF 1.4 Issue: Flow relationship has the incorrect semantics
Issue 3788: Mapping for Sequences -> <sequence_class>Holder "RequiredTraits" exception issue
Issue 5367: Use UML profile for MOF <<enumeration>> stereotype Clarify constraints on EAILink
Issue 5701: <<CRaction>>: this stereotype should be inherited from <<RTaction>> <<CRasync>>, <<CRsync>> <<CRsync>> <<SAschedRes>> Section 4, Page 4-4, Line 6.
Issue 5702: <<CRasync>>, <<CRsync>> <<CRsync>> <<SAschedRes>> Section 4, Page 4-4, Line 6.
Issue 6246: fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <<merge> Question about InterruptibleActivityRegion
Issue 6434: UML Superstructure: 03-08-02 / <<instantiate>> MonolithicImplementationDescription Attributes
Issue 6517: Package Extensibility <<merge>> - UML2 Superstructure issue does "is not instantiable" imply "isAbstract"? - UML2 Superstructure
Issue 7152: Deployment - keyword <<deploy>> not introduced DeploymentTarget - Missing OCL expression
Issue 7433: Figure 52, p107: shouldn't the <<refine>> relationship be reversed ? Figure 109, p162
Issue 8204: {redefined <end-name>} should be named {redefines <end-name>} Audio I/O Facilities Attribute Types
Issue 9603: Section: 1.2.x (CorbaToWsdl)
Issue 9776: What does <<moe>> mean? Page 36
Issue 9794: regarding the <<requirementRelated>> stereotype in the Requirements package section 1.21.3 IDLEntity

Issue 1213: <<local>>, <<parameter>>, <<global>>, <<self>>, not well supported "derived" not defined ()

Summary:  Notation 5.27.2 pg. 65 says that <<local>>, <<parameter>>, <<global>>,
 <<self>> are LinkEnd stereotypes, when they are in fact constraints.
  Moreover, <<local>>, <<parameter>>, <<global>> and <<self>> are not
 well
 supported by the metamodel, because a Link has a unary association to an
 Association, and a <<local>>, <<parameter>>, <<global>> and <<self>>
 Link do
 not refer to any association.
 

They should be LinkEnd stereotypes. Don't see any other problems.
Proposal
Move them to stereotypes.

Summary: Secondly, I"d like to have something clarified, if possible. The
 syntactic category <Factor> includes <Ident> and \ <Ident>. What is the
 reason for this? It seems to me that the only use for <Ident> in this
 context is as a check for the existence of a runtime variable. $var is
 used to denote the value of runtime variable var. However the "exist"
 operator is used for this.
 
 Would the semantics be any clearer if "$" was not used for runtime
 variables at all? In this case a standalone <Ident> (not part of the
 current event) would denote a variable.

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

Re : ptc/00-01-08 IDL to Java Language mapping spec, Section 1.10

The <sequence_class>Holder class shown below does not implement org.omg.CORBA.portable.Streamable
interface, whereas the basic type holders like ShortHolder implement the Streamable interface.

final public class <sequence_class>Holder {
	public <sequence_element_type>[] value;
	public <sequence_class>Holder() {};
	public <sequence_class>Holder(
		<sequence_element_type>[] initial)
		{...};
	public void _read(
		org.omg.CORBA.portable.InputStream is)
		{...}
	public void _write(
		org.omg.CORBA.portable.OutputStream os)
		{...}
	public org.omg.CORBA.TypeCode _type() {...}

Section 6.3.2 Figure 6-7. This should use the UML Profile for MOF (defined in EDOC) to depict the metamodel (i.e. EAISyncMode should have stereotype <<enumeration>> and each value should be depicted as an attribute).

<<CRaction>>: this stereotype should be inherited from <<RTaction>>

Because of lack of more information about the motivations relating this change and its impact of the profile architecture, I propose to reject this issue.

<<CRasync>>, <<CRsync>>:  In my understanding, UML already includes means to represent sync
and async invocations (through the arrow shape - e.g. in RTS one can
edit the 'Timing' folder in the methods properties). Therefore, I would
consider these stereotypes as alternative to the already existing UML
notation. Nevertheless, such stereotypes are associated with the UML
notion of action (e.g. OSD::Step), what forbids combining them directly
with the methods invocations (or operations). To be more exact, I
suggest allowing these stereotypes to be associated also with operations
(see attached item 2 in  (Leandro Diagrams.doc)

medium significance

The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities.

This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal.  Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs."

This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction.  Yet the Figure 175 says otherwise

Suggested resolution:

The root of this problem may be:

a.  Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed.  
b.  In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages."  It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages.  This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages"  is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction.
c.  Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two.  This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept.

The author of the issue seems to have misread the spec. Figure 141 shows a dependency
from IntermediateActions (not IntermediateActivities) to StructuredActivities. However,
there was indeed a merge in the original FAS that coupled the Intermediate and
Structured Activities, but this link was removed in response to issue 6179. Therefore,
even that is no longer a problem and the statement about the separation of these two types
of activities is valid.
As for the recommended solution related to package merge, that issue is dealt with as part
of the resolution to issue 6279.
Disposition: Closed, no change

Definition mismatch:


p. 108/109:
"...dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class."


p. 595:
"A usage dependency among classifiers indicating that
operations on the client create instances of the supplier."


Either use a <<create>> dependency on p. 108/109 or change definition on p. 595.


I think the instantiate dependency is a relationshp between an instance and its specification.

When merging packages... How are associated state machines handled?


 

The handling of non-MOF kinds of model elements is explained in detail the resolution to
issue 6279. The “default rule” in particular is relevant to this and similar cases.
Specifically, if two state machines are matched but not the same in the merged and
receiving package, the merge is not well formed. If they match and are the same, no
merge is performed.

In UML 1.4, the visual representation of a deployment relationship is adorned with the keyword <<deploy>>. I suggest to introduce this is keyword in section "Notation" on page 188. Also, adorn the deployment relationship in Figure 130 on page 188 with <<deploy>>. 

Table 9 on page 199 includes the notation for a deployment dependency including the keyword <<deploy>>, but the depencendy arrow should be drawn with a dashed line.

Insert on page 138 in section 10.3.4 Notation after figure 130 the following text and
diagram:
An alternative notation to containing the deployed artifacts within a deployment target
symbol, is to use a dependency labeled <<deploy>> that is drawn from the artifact to the
deployment target.
:AppServer1
ShoppingCart.jar Order.jar
«deploy» «deploy»
«artifact» «artifact»
Figure 131: An alternative deployment representation using a dependency labeled
<<deploy>>.
In table 9, section 10.5, change the deploy dependency to have a dashed line, instead of a
solid one.
Disposition:

Figure 52, p107: shouldn't the <<refine>> relationship be reversed ?

{redefined <end-name>} should be named {redefines <end-name>}

Please add a footnode explaining what <<moe>> is (just for readability)

Add a footnote below Figure 7.3 defining and point a reference to Appendix C Section 3.2

regarding the <<requirementRelated>> stereotype in the Requirements package of the SysML profile.  I have two questions:

 

Why is the “verifies” tag on requirementRelated instead of <<testcase>>? 
Why do you allow <<requirementRelated>> to be applied to <<testcase>> items? 
 

It makes more sense to me to put the “verifies” tag on <<testcase>> and have a constraint on <<requirementRelated>> that states it cannot be applied to items stereotyped as <<testcase>>.  As I understand it <<requirementRelated>> is basically a placeholder for the derived tags that can’t go anywhere else (e.g. “satisfies”, etc).  Since <<testcase>> is already a stereotype there’s no reason why it can’t hold the “verifies” tag.  

 

The submitter is right in the sense that only <<testcase>> can be used to verify requirement. The derived properties Verifies in the RequirementRelated Stereotype will never be filled unless the stereotype is applied to a testcase. Therefore, the Verifies property can be removed from the RequirementRelated stereotype.
Revise the text in section 16.3.2.4 to reflect that Verifies does not belong anymore to the stereotype RequirementRelated. Update 16.3.2.5 to reflect that a new derived property called Verifies is added to the stereotype. I disagree with the second part of the issue "have a constraint on <<RequirementRelated>>" because a test case can still be traced, satisfy or refine a requirement. Therefore no constrain should be added.

Update the Figures 16.1 and 16.2 accordingly.