Although the current specification defines the basic units of
compliance for UML, it does not clearly specify the extent to which they may
be omitted (via the "no/incomplete" Valid Options in the summary table on p.
xxv) before the implementation is not considered OMG UML. (As a degenerate
case, it could be argued that they all could be omitted and that an
implementation might still claim compliance.) Further note that the optional
compliance of OCL is discussed as a special case on p. xxiii, although no
special treatment of its compliance is reflected in the summary table.
Optional compliance needs to be more clearly specified before we consider
future optional compliance points, as some are proposing for the Action
Semantics.

duplicate

> In 3.23.1 "Notation", it is described that
> italics are used to represent abstract classes.
> We don't usally use slanting letters in Japanese.
> It seems strange. So, I think this should be moved into
> "Presentaion Options" or "Style Guidelines".
>
> In 3.22.4 "Style Guidelines",
> it is described that uppercase letters are
> used to represent class names and
> lowercase letters are used to represent attributes
> and operation names.
> Japanese language doesn't have uppercase nor lowercase
> letters. However, this is "Style Guidelines", so I think
> this is not a problem, because the specification already
> says that "Style Guideline" and "Presentation Option" are
> not mandatory.

No Data Available

I am running a simple program but i am getting the error

"There is no servant with object . minorcode=0 completed=NO"

but i am not finding any documentation that explains abt the minorcode=0. it starts from 1. can u please help me out

No Data Available

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4.4 as follows:

2.9.4.25 Object and DataValue . 2-103
2.9.4.26 Link . . . . . . . . . . 2-104
2.9.4.27 Signal, Exception and Stimulus . 2-104
2.9.4.28 Action . . . . . . . . 2-105

It would appear that the fourth level carries on from 2.9.3.24

No Data Available

The Action ModelElement looks like it is abstract in the Rose MDL
because the name is in italics.
However, checking the details tab in Rose shows that it has not been marked
as abstract.

No Data Available

An Event is aggregated by a transition but there seems to be no
reference to who owns an event.
If it should reside in a Package the OCL-WellFormedness rule for Package
should be updated.

No Data Available

Suggestions for the UML Notation Guide, Part 9 - Statechart Diagrams
1. In Part 9 - Statechart Diagrams:[Proposed changes in red for the
first 3 suggestions.] "A statechart diagram can be used to describe the
behavior of instances of a model element such as an object or an
interaction. Specifically, it describes possible sequences of states and
actions through which the element instance can proceed during its lifetime
as a result of reacting to discrete events (e.g., signals, operation
invocations). " [The idea is that model elements are not dynamic or have
lifetimes; rather they apply to instances of model elements.]
2. In 3.74.1: "Typically, it is used for describing the behavior of
classes instances, but statecharts may also describe the behavior of other
model entities such as use-cases, actors, subsystems, operations, or
methods." [A method is an instance of an operation. Therefore, you must have
implementation level knowledge, in this case, the programming language used,
to know about a method. This is antithetical to good modeling principles
which state that a model should be implementation independent.]
3. In 3.74.3: "That StateMachine may be owned by an instance of a model
element capable of dynamic behavior, ..."
4. Event-name or action-label??? 3.75.2 says "Internal transitions
compartment This compartment holds a list of internal actions or activities
that are performed while the element is in the state. The notation for such
each of these list items has the following general format: action-label '/'
action-expression" and later "The general format for the list item of an
internal transition is: event-name '(' comma-separated-parameter-list ')'
'[' guard-condition']' '/'action-expression". Which is to be used? Or is
action-label the name of the expression: event-name '('
comma-separated-parameter-list ')' '[' guard-condition']'? Compare this with
3.78.2 which has " event-signature '[' guard-condition ']' '/'
action-expression. The event-signature describes an event with its
arguments: event-name '(' comma-separated-parameter-list ')'"
5. In 3.75.2: "If the event has parameters, they can be used in the
action expression through the current event variable." Should it be
action-expression for consistency?
6. 3.75.4: "The action expression maps into the ActionSequence and
Guard for the Transition." Should it be action-expression?
7. 3.75.4: "The Transition has a trigger Association to the Event." The
term trigger does not appear to be unambiguously defined. It was previously
mentioned in the section. " In all other cases, the action label identifies
the event that triggers the corresponding action expression." Is this
sufficient? It is not in the glossary.
8. The use of the term pseudostate is not consistent throughout. In the
glossary it is "pseudo-state", with a hyphen. In 2.12.2 it is pseudostate.
9. 3.76.3, Figure 3-63: Passed and Failed are activities and not
states. Change to the right graphic.
10. 3.78.1: " A simple transition is a relationship between two states
indicating that an object in the first state ..." Object should probably be
instance. (This should be looked at throughout the document.) I suspect this
opens a can of worms but the definitions, and probably the concepts
themselves, of instance and object need clarification.
11. 3.80.4 Figure 3-66: Each of the two diagrams should have a top level
state around it to keep the rule about not transitioning from a stubbed
state to an external state. See below. Granted they are implied but we are
trying to be clear.
12. 3.80.5: Eliminate the word "elision". It is not a common word plus
it appears to be misused. "Elision is the omission of sounds, syllables, or
words in spoken or written discourse
</lingualinks/library/literacy/glossary/cjJ405/tks2801.htm>." and "The
omission of a letter or syllable as a means of contraction, generally to
achieve a uniform metrical pattern, but sometimes to smooth the
pronunciation; such omissions are marked with an apostrophe <gl-a.html>.
Specific types of elision include aphaeresis <gl-a.html>, apocope
<gl-a.html>, syncope <gl-s.html>, synaeresis <gl-s.html> and synaloepha
<gl-s.html>." Suggest replace with shortcut.
13. 3.81.2: " represented by a a small white circle" Eliminate one "a".
14. 3.83.2: " The bound is either a positive integer or a star ('*') for
unlimited." "Unlimited" should be "any number" and "star" should be
"asterisk".

No Data Available

Namespace notation too specific

The model management namespace containment notation (the circled plus
sign ) should be available on all namespace elements.

declined

Suggestions for the UML Notation Guide, Part 6 - Use Case Diagrams
1. 3.56.1: Use different class names in the relationships: extend use A
& B, generalization use C & D, include use E & F for clarity.

declined

Part 3 - Behavioral Elements
1. In 2.8: typo "that is used to model proocesses." Should be
"processes"
2. In 2.9.2, Figure 2-15: "Clas" should be "Class"
3. In 2.9.2, Figure 2-15 and Argument: There is an internal
inconsistency. The relationship from Argument to Action is diagrammed as a
composition. The text says: [An argument] "is aggregated within an action."
Is it aggregation or composition?
4. Continuing #3: Also the glossary definition of composition ties
non-fixed multiplicity and coincident lifetimes. Does 0..1 count as
non-fixed? If so, where is it defined? What does this distinction mean in
the first place?
5. In 2.9.2, Instance: "The instance construct defines an entity to
which a set of operations can be applied ..." Operation should be method.
Operations exist at the Classifier level; methods are instances of
operations and exist at the instance (application) level.
6. In 2.9.2, Instance\Tagged Values\persistent: "Persistence denotes
the permanence of the state of the instance, marking it as transitory (its
state is destroyed when the instance is destroyed) or persistent (its state
is not destroyed when the instance is destroyed)." Seems it should say that
transitory is the default. Else add transitory as a tagged value.
7. In 2.9.2, Figure 2-16: Would two refinements be clearer than the two
associations from Link to Association and LinkEnd to AssociationEnd since
they are a different levels of abstraction? Also from Instance to
Classifier? [Should the relationship from Method to Operation in 2.5.2,
Figure 2-5 also be a refinement?]
8. In 2.9.2, Figure 2-16: Should the composition relationship from
Attribute to Classifier also be modeled?
9. In 2.9.2, Figure 2-16: The element Instance is abstract according to
the text and should be stereotyped <<abstract>>.
10. In 2.9.2, Link: "In the metamodel Link is an instance of an
Association. It has a set of LinkEnds that matches the set of
AssociationEnds of the Association." In Figure 2-16 LinkEnd to Link is

. Should this be consistent with AssociationEnd to Association?

No Data Available

Part 2 - Diagram Elements
1. 3.6.4: Title should be 'Examples' for clarity. Or add a subheading
to communicate that a list of examples follows.
2. 3.10.3: same as above
3. 3.10.7: same as above
4. 3.12: "Examples of such pairs in UML include: Class-Object,
Association-Link, Parameter-Value, Operation-Call, and so on." Should
Operation-Call be Operation-Method? 3.59.5 defines a call as procedural.

No Data Available

What has become of the dropped property : "Action::effect : String" ? ( referenced in Ballot 7319 )

No Data Available

When the UML spec standardises an XMI-generated interchange format for
UML
models, it should include:

• the "input" MOF meta-model for UML that was used to generate the
  interchange format, and

• a formal statement of the other XMI "parameters" used to generate
  the interchange format.

If possible, the UML spec should include a definitive meta-model for
UML
expressed as a MOF / XMI document. This is a MOF alignment issue.

No Data Available

In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

On page 2-173 of 2.12:

• • • The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

[...]

Once a transition is enabled and is selected to fire, the following steps are carried out in order:

• The main source state is properly exited.

• Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

• If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

• The main target state is properly entered. ***

This is certainly much better than 1.3. But I still find it difficult to follow:

Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

Remove the paragraph explaining the LCA from the “Transition execution sequence” section and add an
explanation of LCA to the “Transition ownership” section

For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.

This is a duplicate of issue 6430

I raised this issue at the AB level. I didn't recommend holding up approval
of UML 1.4 over this but we agreed that the new RTF would take this matter
up with dispatch.

Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
issue. I can speak to this as a practical matter based on the profiling
work I've done. When I define a Stereotype on a UML metamodel element, as
in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
of the UML metamodel element. I don't want to have to define it again
before defining the relationship between my new Stereotype and that UML
metamodel element. Thus, requiring the <<metaclass>> Stereotype on the UML
metamodel element means that, in the UML metamodel itself, I would have to
Stereotype all the metaclasses this way so that, if I need to, I can reuse
them in VMMs. True, I could opt not to display the <<metaclass>>
Stereotype in a pure UML metamodel diagram and opt to display it a VMM
diagram, but all the UML metamodel elements would be carrying the
<<metaclass>> Stereotype.

The best solution I can think of to this problem is to to drop the
requirement to use the <<metaclass>> Stereotype in VMM diagrams. As long as
the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
is adhered to, it should be pretty clear in a VMM diagram what is a
Stereotype and what is a UML metamodel element. Also, the the standard
metamodel Stereotype of Package indicates that the elements in the
Package are elements of a metamodel.

I am open to other suggestions as to how to resolve this issue.

resolved, close issue

In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

No Data Available

UML 1.4 Specification, Section 2.12.3, p. 2-165

Description:
WFR 5 for the class Transition states that "Transitions outgoing
pseudostates may not have a trigger" and the OCL supports this absolute
statement. However, WFR 6 is intended to allow transitions out of initial
states, which are a kind of pseudostate, to have "a trigger with the
stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
legal.

Recommendation:
Change WFR 5 as follows.

[5] Transitions outgoing pseudostates other than initial states may not have
a trigger.

self.source.oclIsKindOf(Pseudostate) implies
self.source.oclAsType(Pseudostate).kind<>#initial implies
(self.trigger->isEmpty())

see below

Adding multiplicity to Parameter would enable modeling of arrays,
collections, sequences etc. I would like to model BehavioralFeatures that
can return an array and take an array as an argument.
The notation would simply add the [multiplicity] after the Parameter type.
The initial value syntax would be

No Data Available

Here is my understanding of communication between instances on an
example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
An instance i1 performs a SendAction, according to the spec: "A send
action is an action that results in the (asynchronous) sending of a
signal". Then, the signal is delivered to say instance i2, and as a
consequence of the receipt, a SignalEvent is generated (according to the
spec, "A signal event represents the RECEPTION of a particular
(asynchronous) signal")
Now the problems:
1) the spec goes on further to say about the signal event that "A signal
event
instance should not be confused with the action (e.g., send action) that
generated it". The problem I have with my above understanding is that
the send action should not be the one generating the send event but
rather the reception of the signal should be the one generating it.
2)According to the spec: "A signal is a specification of an asynchronous
stimulus communicated between instances" where a stimulus is more
general "In the metamodel Stimulus is a communication, i.e. a Signal
sent to an Instance, or an invocation of an Operation". Thus, I conclude
that the things sent between instances are stimuli.
However, I'm a little confused of the relationship between events and
stimuli with the following sentence taken from the spec "Event instances
are generated as a result of some action either within the system or in
the environment surrounding the system. An event is then conveyed to one
or more targets. The means by which event instances are transported to
their destination depend on the type of action, the target,..."
Furthermore, how are stimuli and signals related in the metamodel?

No Data Available

Actions seem to be owned by the Message in the following paragraph.

Section 2.10 page 2-130. "In the metamodel a Message defines one specific
kind of communication in an Interaction. A
communication can be e.g. raising a Signal, invoking an Operation, creating
or destroying an
Instance. The Message specifies not only the kind of communication, but also
the roles of the
sender and the receiver, the dispatching Action, and the role played by the
communication
Link. Furthermore, the Message defines the relative sequencing of Messages
within the
Interaction."

Is the Action a reference to a Action in the Sender, as the meta-model
suggests, or is it owned by the Message as the above suggests?

Please clarify.

No Data Available

MOF rules should disallow composition relationships in instance metamodels
where the container is in one MOF Package and the contained item is in
another MOF Package and a dependency of the first package on the second is
not allowed by the physical version of the metamodel due to MOF-imposed IDL
generation rules.

Reason for the issue:

In the process of implementing an XMI-based interchange for UML 1.3, I have
encountered a serious problem.

This problem has to do with a divergence between the "Logical" and
"Physical" model for UML 1.3 caused by rules imposed by MOF.

In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
version), "Preconditions for IDL Generation", requires that there be no
cyclical dependencies between ModelElements in a meta-model.

However, the UML 1.3 specification (June 1999) has a cyclical dependency
between the Core and the Extension Mechanisms packages in the metamodel (See
Figure 2-4). This cyclical dependency is explicitly disallowed by the
precondition cited above.

This circular dependency was removed from the "Physical Model" for UML 1.3
in order to allow CORBA IDL and XMI DTD declarations in conformance with the
precondition. As a result of the removal of this dependency, there are
tremendous difficulties expressing the composition relationship between the
UML ModelElement and the UML Tagged Value (see figure 2-10). In fact, the
TaggedValue XML elements cannot even be in the exported UML Package element
– they must be placed outside of it. This greatly complicates the export
and import of UML 1.3 model files.

No Data Available

The CWM submitters needed to display inherited associations on some class
diagrams to enhance understandability. These were not intended to be
derived associations; that is, there was no intention to specify additional
computational machinery when showing these inherited associations.
Unfortunately, the MOF and UML have no succint way to display inherited
associations. The CWM submitters placed the "/" derived prefix on the
association end names in the class diagrams. At the same time, in order to
prevent the generation of additional computational machinery, they omitted
the inherited association from the normative XMI rendition of the metamodel.
This was probably a reasonable choice under the circumstances. However, it
means that the class diagrams and the XMI representation of the metamodel
conflict with one another.

It is very common to need to show inherited associations on a class diagram.
We ran into this when we specified the CORBA metamodel for the CORBA
Component Model submission. We used derived associations in the class
diagrams as well. However, we retained the derived associations in the XMI
rendition of the metamodel. In order to prevent additional computational
machinery from being generated, we stereotyped the associations as
<<implicit>>. This stereotype is defined in the UML specification but not
in the MOF specification and says that an association is only conceptual and
not manifest. We then made sure that the generator producing the IDL and
XML DTDs was sensitive to the <<implicit>> stereotype. This had the
advantage of maintaining consistency between the class diagrams and the XMI
rendition of the metamodel. Of course this is also a non-standard
approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
generators to understand it.

The lack of a standard means for representing inherited associations in
class diagrams is thus resulting in a proliferation of non-standard
approaches in adopted OMG metamodels. This could become unmanageable as the
number of metamodels grows. A standard means should be specified.

No Data Available

Since an ActivityGraph is derived from a StateMachine its
constraints must be consistent with that of a StateMachine. If an
ActivityGraph has a Package as its context it violates the constraint
inherited from StateMachine.

ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
(self.context.oclIsTypeOf(Package) xor
self.context.oclIsKindOf(Classifier) xor
self.context.oclIsKindOf(BehavioralFeature))

StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
self.context.oclIsKindOf(BehavioralFeature) or
self.context.oclIsKindOf(Classifier)

One way to avoid this problem is to change the StateMachine constraint to be
applicable when self is oclIsTypeOf(StateMachine) so the constraint is not
applied to it children.

A general mechanism to disable inherited constraints could also solve the
problem.

No Data Available

the association between StructuralFeature and Classifier should be
removed. Attributes can not describe more information than
Associations/AssociationEnds can. Therefore it is obsolete and confuses
the user of UML, which to choose when modeling.

On page 3-40 in the UML 1.3 specification it says: "Note that an
attribute is semantically equivalent to a composition association;
however, the intent and usage is normally different."

If the semantics are equivalent, then it is impossible to distinguish
between them. There is no extra layer of meaning above the semantics
layer that can distinguish between two things with equal semantics.
Semantics is meaning. I think this sentence is contradictory. I have not
been able to find out what the difference in "intent and usage" is. If
this is defined, it will obviously make the semantics of the two
different.

To improve the readability of class diagrams when everything is
associations, I propose that associations should be possible to
represent as text in the compartment where attributes are written today.

see above

This is a request for an interpretation of UML 1.3.

The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

-------- Background -------

Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

The UML submission said:

"... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

"UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."

UML 1.3 says:

"2.5.4 Semantics

"Interface

"... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

[It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

--------

I am hoping this is easy to interpret and can be resolved quickly.

see below

Every StateMachine must have one top State. However, there is an
OCL constraint that says that the top State must be a CompositeState
(Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
2-141). So, why not make the top relationship from StateMachine to
CompositeState instead of from StateMachine to State. The constraint can
then be eliminated.

No Data Available

I'd find the document easier to digest if Chap 2 had some pictures in it.
>>
>>I know that the semantics is supposed to be independent of the
>>representation. However, Chap 3 does contain some semantics in it for
>>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
>>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
>>picture of the diamond shaped association end for aggregations, it would be
>>easier to follow what the document is talking about.
>>
>>At least sections 3.55.1 and 2.11.4 for instance might have links, even if
>>only footnotes, to connect actor notation and semantics.

No Data Available

This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

---Begin of issues---------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

(p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

(p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

(p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

(p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

Please clarify or correct the statement.

(p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

(p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

(p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

(p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

(p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

(p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

(p. 3-3) Typographical/Editorial: There is no Part 8.

(p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

(p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

(p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

(p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

(p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

(p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

(p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

(p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

(p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

Please clarify

see below

In the physical metamodel for extensions (Figure 6-8) the class
TaggedValuewill have two association-ends with the same name "stereotype".
One
from the association with the superclass ModelElement
(extendedElement-stereotype) and one on its own (requiredTag-stereotype).

in Uml 1.4 final, there is only one association end with this name

Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

editorial fix in diagram: metaclass name is truncated (ModelElement => Model…). Duplicate of 4349

I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty

I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state.

On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add?

On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

see above

2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic);

2.5.4.3 Class has methods which can be polymorphic (isPolymorphic)

2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic)

But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

This is a duplicate of issue 4617,

A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

The rule seems to have unintentionally disappeared from 1.3 to 1.4.

it's => its on page 3-150.

editorial fix

The second wf rule for AssociationEnd uses the OCL operation
applied to the wrong type (max applied to multiplicities).

obvious error, OCL only fix.

In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'.

This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

editorial fix : Rose truncating the diagram, Previously fixed.

In the example the dependencies between the focus class and the two
auxiliary classes should connect to the target interfaces of the auxiliary
classes, rather than their class rectangles. (Note: this typo may be
corrected in the formal version of the UML 1.4 specification, which is not
yet available.)

Diagram to be fixed

The glossary entry "call" should be "call state".

Change the name of the glossary entry

At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9.

My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version:

1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association

B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1

2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement

B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of *

3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances

B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind

Can you help me to solve this trouble?

rejected

2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
follows:

1 oppositeAssociationEnds : Set (AssociationEnd);
2 oppositeAssociationEnds =
3 self.association->select ( a | a.associationEnd->select ( ae |
4 ae.type = self ).size = 1 )->collect ( a |
5 a.associationEnd->select ( ae | ae.type <self ) )->union
6 (
7 self.association->select ( a | a.associationEnd->select ( ae |
8 ae.type = self ).size 1 )->collect ( a |
9 a.associationEnd) )

In line 5, the expression 'ae.type <self' is clearly wrong. I believe the
intention may have been to test for inequality, i.e. 'ae.type <> self'.

In line 8 'size 1' doesn't parse. I'm not sure what the intent was.

A greater concern is that, even if corrected to address these flaws, this
logic doesn't seem right in the case where we are dealing with an
association where both ends are of the same type. It appears to be relying
on detecting whether an end is opposite by testing the end's type. A fair
number of other well-formedness rules leverage this operation in one way or
another, so they are affected by this apparent flaw. Correcting this would
require comparing the end instances, i.e. something like 'ae <> self' which
does not have the same problem as 'ae.type <> self'.

This issue has been fixed in UML 1.4. The correct operator is "<>"

Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model.

Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It’s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

rejected

Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2, p. 2-17, Figure
2-9 Core Package - Auxiliary Elements
Nature: Revision
Severity: Minor
Summary: A Comment is shown as having a relationship to ModelElement
(annotatedElement). However, the ownership of a Comment is not specified
anywhere. If it should reside in a Package the OCL-WellFormedness rule for
Package should be updated. Also, shouldn't a Comment have a text field to
hold the annotation?

Add Comment to wfr listing what may be owned by a Package

In the UML 1.3 specification (ad/99-06-08) there are the following problems:

1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
operation 'oppositeEnds' which is not defined. This probably should be
'oppositeAssociationEnds'.

No Data Available