Issue 4740: Adding events to the class definition (uml2-superstructure-ftf)
Source:  (, )
Nature: Uncategorized Issue
Severity: Minor
Summary: The proposal is to add an optional fourth compartment to the 
class artifact that lists events that are accepted by that 
class.

If a class is 'Active', it will have an associated 
state/activity model. This state/activity model will respond to 
events sent to that class. At the moment the only way to 
determine what events can be accepted by a class is to observe 
its state/activity model. Very clumsy!

A workaround is to list events in the operations compartment 
and label them with an appropriate stereotype <<event>> for 
example. This should only be a temporary solution, since events 
are no more operations than they are attributes.

Events need to be part of the class definition.

Resolution: 
Revised Text: 
Actions taken:
December 7, 2001: received issue
March 9, 2005: closed issue
Discussion: 
The UML provides a mechanism to specify that a class will respond to the receipt of an
operation call (Operation) or a signal (Reception). These are explicitly listed in the
appropriate compartment. In addition to these, a class may respond to events such as
change events and time events, but these are not part of the external interface of the class
and are, therefore, not shown in a compartment.
Disposition: Closed, no change
End of Annotations:=====
Date: Fri, 7 Dec 2001 15:39:41 -0500
Message-Id: <200112072039.PAA05689@www22.ureach.com>
To: issues@omg.org
From: Les Munday <baldrick@ureach.com>
Reply-to: <baldrick@ureach.com>
Subject: Adding events to the class definition
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-vsuite-type: e
Content-Type: Text/Plain; charset=us-ascii
X-UIDL: aEVd9Fj,e9,Vkd9+mYd9

This issue arose as a thread on Rational's Object Technology 
Users Group.

The proposal is to add an optional fourth compartment to the 
class artifact that lists events that are accepted by that 
class.

If a class is 'Active', it will have an associated 
state/activity model. This state/activity model will respond to 
events sent to that class. At the moment the only way to 
determine what events can be accepted by a class is to observe 
its state/activity model. Very clumsy!

A workaround is to list events in the operations compartment 
and label them with an appropriate stereotype <<event>> for 
example. This should only be a temporary solution, since events 
are no more operations than they are attributes.

Events need to be part of the class definition.

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


From: Edwin Seidewitz <eseidewitz@intelidata.com>
To: uml-rtf@emerald.omg.org
Subject: RE: issue 4740 -- UML RTF issue
Date: Fri, 7 Dec 2001 16:35:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	      boundary="----_=_NextPart_001_01C17F67.08A64D00"
X-UIDL: g>W!!`f"!!1<'e9cL#"!


Events are not "sent" to a class. Events are part of the specification
of a state machine. Signals and messages may be sent to an object,
which may trigger signal events and call events on a state machine
associated with the class of the object. The ability to receive
specific signals or messages can be declared using receptions and
operations on the class (the notation for a signal reception is just
like that for an operation, but with the keyword <<signal>> -- see the
UML 1.4 Notation Guide, Section 3.26.6). 

Other kinds of events are generally considered internal behavior of
the class, not part of the class interface. However, note that the UML
1.3 Notation Guide mentions, as a presentation option, that
"Additional compartments may be supplied as a tool extension to show
other predefined or user-defined model properties (for example, to
show business rules, responsibilities, variations, events handled,
exceptions raised, and so on)" (Section 3.22.3).

Ed Seidewitz, Chief Architect 
InteliData Technologies 
<mailto:eseidewitz@intelidata.com> 
<http:\\www.intelidata.com> 
Office: +1.703.259.3076 
Mobile: +1.301.455.3681 

> -----Original Message----- 
> From: Juergen Boldt [mailto:juergen@omg.org] 
> Sent: Friday, December 07, 2001 3:55 PM 
> To: issues@emerald.omg.org; uml-rtf@emerald.omg.org 
> Subject: issue 4740 -- UML RTF issue 
> 
> 
> This is issue # 4740  Les Munday <baldrick@ureach.com> 
> 
> Adding events to the class definition 
> 
> The proposal is to add an optional fourth compartment to the 
> class artifact that lists events that are accepted by that 
> class. 
> 
> If a class is 'Active', it will have an associated 
> state/activity model. This state/activity model will respond to 
> events sent to that class. At the moment the only way to 
> determine what events can be accepted by a class is to observe 
> its state/activity model. Very clumsy! 
> 
> A workaround is to list events in the operations compartment 
> and label them with an appropriate stereotype <<event>> for 
> example. This should only be a temporary solution, since events 
> are no more operations than they are attributes. 
> 
> Events need to be part of the class definition. 
> ================================================================ 
> 
> Juergen Boldt 
> Senior Member of Technical Staff 
> 
> Object Management Group               Tel.    +1-781 444 0404 
>  ext. 132 
> 250 First Avenue, Suite 201           Fax:    +1-781 444 0320 
> Needham, MA 02494, USA                Email:  juergen@omg.org 
>                                       URL:    www.omg.org 
> 
> 
> 
> ================================================================ 
> 


Discussion:
The UML provides a mechanism to specify that a class will respond to the receipt of an operation call (Operation) or a signal (Reception). These correspond to CallTrigger and SignalTrigger, respectively. (Note that in UML 2.0 the metaclass representing events is Trigger.) These are shown in a compartment of the class specification.

There are two other kinds of triggers, TimeTrigger, representing the passing of an amount of time or an absolute time, and ChangeTrigger, representing a Boolean-valued expression becoming true. Neither of these are part of the external interface of the class, and are, therefore, not shown in a compartment.
Disposition:	Closed, no change