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 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 5703: <<CRsync>> <<SAschedRes>> Section 4, Page 4-4, Line 6.
Issue 5704: <<SAschedRes>> Section 4, Page 4-4, Line 6.
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 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 12514: The <<tiler>> stereotype should be applied on the UML::Port metaclass Profile Notation of Process Element

Issue 5445: Mapping of <<enumeration>> stereotype missing from UML profile for MOF Conformance Points appear to be contradictory ()

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

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

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

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

The <<tiler>> stereotype should be applied on the UML::Port metaclass. Tilers are currently applicable on connectors and connector ends, along with instances (parts) of a given class. It would be very useful to make use of the same stereotype at a classifier level, in order to define the expected and produced data format at a classifier level. The UML::Port metaclass is a good candidate to carry this stereotype.