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 5445: Mapping of <<enumeration>> stereotype missing from UML profile for MOF Conformance Points appear to be contradictory
Issue 5645: Rename stereotype from <<SAschedulable>> to <<SAschedRes>> Java source code for org.omg.PortableServer.POAOperations
Issue 5699: suggest inclusion of <<RTtimedAction>> stereotype (inherited from <<RTactio TVL notation
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 5703: <<CRsync>> <<SAschedRes>> Section 4, Page 4-4, Line 6.
Issue 5704: <<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 7644: . <<create>> on Usage Figures 103 and 121 use <<create>> dependencies Figures 120 and 121
Issue 7645: Figures 103 and 121 use <<create>> dependencies Figures 120 and 121
Issue 8184: Section: 11.3.39
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 10061: SysML: << and >> vs < and > SysML: Instance Diagrams
Issue 11177: 9.6: These types should be declared as <<primitive>> 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.
Issue 11491: <<satisfy>> is displayed as dependency (in examples) Uppercase/lowercase problems
Issue 11498: <<continuous>> Parts are added directly into package
Issue 11706: use the stereotype <<allocated>> alone Consider providing a tabular notation (as in SysML)
Issue 12011: SystemSystemSoftware
Issue 12235: Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

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).

relates to EAI issue: 5367)
The UML profile for MOF needs to say how the UML <<enumeration>> maps to a
MOF enumeration.

There is a stereotype called<<SAschedulable>> and a tag
definition called SAschedulable in the SAprofile package - to avoid
potential problems with name clashes (UML is unclear whether this is
allowed) the stereotype should be renamed <<SAschedRes>>.

"As actions can have a limited time budget, they should include a
deadline. Therefore, I suggest the inclusion of the <<RTtimedAction>>
stereotype (inherited from <<RTaction>>), which would represent an
action with a deadline (tag RTdeadline - also new) and a timeout
exception handler (tag RTtimeoutException). A motivation for adding this
new element is that, in general, modeling such restrictions is more
complex than programming it using ORC APIs! Another benefit is that the
exception caused by the deadline violation would be explicitly
associated with the stereotype. Please take a look at item 1 in the
attached file (Leandro Diagrams.doc)."

Valid point that requires a new feature and, hence, an RFP

<<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)

<<CRsync>>: we suggest the inclusion of a new tagged valued called
CRcallTimeout. It would represent the maximum waiting time from the
calling object. For example, this would be useful to model the RT-CORBA
Messaging:: RELATIVE_RT_TIMEOUT_POLICY_TYPE attribute. Like in 1.2, the
could be a timeout handler associated with, for example, a stereotype
named RTcallTimeoutHandler (see attached item 3 in (Leandro Diagrams.doc)).

Because of impact on the profile architecture (dependency between time and concurrency sub-profiles), I suggest to defer this issue the version 2.0.

<<SAschedRes>>: why this stereotype isn't inherited from
<<CRconcurrent>>? As I could understand from the documentation, they
represent the same thing: "a unit of concurrent execution, such as a
task, a process, or a thread". Therefore, I believe it should also
include the tag CRmain.

I agree with this suggestion -  but it does change the normative specification slightly, by adding a new feature, so I'll defer to 2.0.

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 ?

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

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

{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.

Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio

9.6: These types should be declared as <<primitive>>

<<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used) 

<<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too. 

 ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.

By the same argument as that indicated in issue 12010 this association is not seen as required.

Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."