Issue 4734: UML 1.4: Event containment problem (uml2-superstructure-ftf)
Source:  (, )
Nature: Uncategorized Issue
Severity: 
Summary: 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).

Resolution: 
Revised Text: 
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue
Discussion: 
The Event metaclass is no longer defined in UML 2.0.
Disposition: Closed, no change
End of Annotations:=====
From: Thomas Schaumburg <thomas.schaumburg@hiq.dk>
To: "'issues@omg.org'" <issues@omg.org>
Subject: UML 1.4: Event containment problem
Date: Wed, 5 Dec 2001 15:42:34 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: /fBe9GXBe97N-e9O*0e9

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


Discussion:
In UML 2.0 the metaclass Event has been replaced by the metaclass Trigger. No metaclass specifically owns a Trigger, so it can be owned by any namespace. Typically, a Trigger would be owned by a surrounding package or it could be owned by the classifier referencing the trigger, such as a state machine, an interaction. Obviously, visibility rules partially dictate the owner of a trigger.

There are no special considerations regarding the semantics of a namespace owning a Trigger, as is hinted to in the issue summary.
Disposition:	Closed, no change



OMG Issue No: 4734
Title:	Event containment problem
Source:
Summary:
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).
Discussion:
Duplicate of 6206.

Note that in UML 2.0 the metaclass Event has been replaced by the metaclass Trigger. There are no special considerations regarding the semantics of a namespace owning a Trigger, as is hinted to in the issue summary.

[Conrad: I think the issue is that Trigger is not owned, at least not in Figure 354.  The XMI won't generate properly without owndership, will it?]
Disposition:	Duplicate