Issue 6682: See CommonBehavior for a description of Event specifications (uml2-superstructure-ftf) Source: XTG, LLC (Mr. Joaquin Miller, nobody) Nature: Clarification Severity: Critical Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. Resolution: see above THEN below Revised Text: p216, AcceptCallAction, Semantics, first paragraph, rephrase: “This action accepts (event) occurrences representing the receipt of calls on the operation specified by the call trig ger. If an ongoing activity has executed an accept call action that has not completed and the owning object has an event occurrence representing a call of the specified activity, the accept call action claims the occurrence and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the occurrence, but one and only one action will claim the occurrence. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in a token on the returnInformation output pin. The execution of the accept call action is then complete. This return information token flows like any other data token, but the information in it is opaque and may not be manipulated by any actions. It only has meaning to ReplyA.” p217, AcceptEventAction, Semantics, parapraph 1-2, rephrase: Accept event actions handle event occurrences detected by the object owning the activity. Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. If the accept event action is executed and the object detected an occurrence matching the specification on the action and the occurrence has not been accepted by another action or otherwise consumed by another behavior, then the accept signal action completes and outputs a token describing the occurrence. If such a matching occurrence is not available, the action waits until such an occurrence becomes available, at which point the action may accept it. In a system with concurrency, several actions or other behaviors might contend for an available occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions. If the occurrence is of a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications. If an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept occurrences, no matter how many it accepts. It does not terminate after accepting an occurrence and outputing a value, but continues to wait for other occurrences. This semantic is an exception to the normal execution rules in Activities. p370, Common Behaviors, Basic behaviors, first paragraph, substitute: “partially ordered sequences of events” to “partially ordered sequences of occurrences” “observable events” to “observable occurrences” p372, p372, Common Behaviors, Communications, 2nd paragraph on page, substitute: “the invocation event that eventually will lead” to “the invocation occurrence that eventually will lead” Tthird paragraph, rephrase: The detection of an (event) occurrence may cause a behavioral response. For example, a statemachine may transition to a new state upon detection of the occurrence of a trigger event or an activity may be enabled upon receipt of a message. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. The behavior will be executed in the context of the receiving object (i.e., the receiving object will host the behavior execution). The details of identifying the behavior to be invoked in response to the occurrence of an event is a semantic variation point. p381, Behavior, Semantics, Paragraph 3: The behavior executes within its context object, independently of and concurrently with any existing behavior executions. The object which is the context of the behavior manages the input pool holding the (event) occurrences to which a behavior may respond (see BehavioredClassifier on page 383). As an object may have a number of behaviors associated, all these behaviors may access the same input pool. The object ensures that each occurrence on the input pool is consumed by only one behavior. p383, BehavioredClassifier, Semantics Paragraph 2: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. p489, StateMachine, Overview: State machines can be used to express the behavior of part of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the detection of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine. p491, StateMachine, Semantics, Event Processing: Event occurrences are detected and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority-based schemes. The semantics of event processing is based on the run-to-completion assumption, interpreted as run-tocompletion processing. Run-to-completion processing means that an event occurrence can only be taken from the pool and dis patched if the processing of the previous current event occurrence is fully completed. Run-to-completion may be implemented in various ways. For active classes, it may be realized by an eventloop running in its own thread, and that reads event occurrences from a pool. For passive classes it may be implemented as a monitor. The processing of a single event occurrence by a state machine is known as a run-to-completion step. Before commencing on a runto-completion step, a state machine is in a stable state configuration with all entry/exit/internal activities (but not necessarily state (do) activities) completed. The same conditions apply after the run-to-completion step is completed. Thus, an event occurrence will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine. The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its runto- completion step. When an event occurrence is detected, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event (type) is not in the deferred event list of the current state configuration, the occurrence is discarded and the run-tocompletion step is completed. In the presence of orthogonal regions it is possible to fire multiple transitions as a result of the same event occurrence — as many as one transition in each region in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined. Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions (i.e., “bottomlevel” region) can fire at most one transition as a result of the current event occurrence. When all orthogonal regions have finished executing the transition, the current event occurrence is fully consumed, and the run-to-completion step is completed. During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a state machine, then the transition step is not completed until the invoked object complete its run-tocompletion step. p498, Transition, Overview: A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to the occurrence of an event of a particular type. p498, Transition, Associations, guard, substitute: “The guard is evaluated when an event is dispatched by the state machine.” to “The guard is evaluated when an event occurrence is processed by the state machine.” p500, Transition, Enabled transitions, 2nd bullet: • One of the triggers of the transition is satisfied by the event (type) of the current occurrence. An event satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization thereof. Actions taken: December 8, 2003: received issue March 8, 2005: closed issue Discussion: The following changes support the sentiment at the FTF meeting in Anaheim to regularize the terminology around events. Several people were strongly in favor of making these changes and nobody expressed opposition, so I have carried out the changes that I promised by searching the text document. Broadly, the following issues are addressed: 1. Establish and enforce a consistent naming policy for metaclasses over the categories of types, instances, values, and uses (references). 2. Restore Event as a class with subclasses instead of having subclasses of Trigger, and have Trigger point to Event (a particular trigger instance would point to an instance of a particular event subclass).Also add additional event subclasses for creation, destruction, initiation, and completion. 3. Rename a few other classes that break the pattern, such as using “occurrence” in their name when they do not refer to event instances, e.g., CollaborationOccurrence.. 4. Clean up occasional sloppiness in the text in making distinctions between model things and runtime thingstypes and instances with respect to behavioral things such as events and executions, broadly speaking to be consistent about type/instance distinctions. The terminology obeys the following principles: Consistent naming policy There was inconsistency in naming various kinds of behavioral things, with the same word being used for different things. In particular, the distinction between instances, roles, and value specifications was done differently and inconsistently. As these important but sometimes subtle distinctions are tricky enough, the naming inconsistencies made understanding difficult. The proposal supplies a regular pattern of naming. First we note the 4 different levels at which a concept might appear: Type level – Represents generic types of entities in models, such as classes, etc. These are the most common constituents of models. Instance level – These are the things that models represent at runtime. They don’t appear in models directly (except very occasionally as detailed examples), but they are necessary to explain the semantics of what models mean. Uses within a context – These are the things that represent instances within a generic, reusable context. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are not instances because they are generic. Value specifications – Another realization of UML2 is that values can be specified at various levels of precision. What appears in models is usually not values but specifications of values that may or may not correspond to a single value. Individual appearances of a type within a context – These are the roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are not instances because they are generic. We have the following categories of concepts that we try to name using uniformnaming patterns: Types : Instances : Modeling of instancesValues : Individual use within a contextUses Classifier : Instance : InstanceSpecification : Part, /Role, XXXUse (e.g., CollaborationUse) Class : Object : InstanceSpecification : Part, Attribute Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger) (XXXUse) Behavior : Execution : ExecutionSpecification : (various) (e.g., ActivityNode, State), XXXUse (e.g., InteractionUse) The appearances have too wide a variety of names to reduce to a single pattern, although the form XXXUse is suggested for simple cases. In particular, the word “event” has been used inconsistently throughout the document to mean both type and instance. The word “event” will now mean the type and the word “occurrence” will mean the instance. When necessary, the clarifications full form event (type) and (event) occurrence are may be used. Note that this is consistent with the frequent usage “an event occurs” = the occurrence of an event of a given type, so much of the language can be left unchanged; it is not necessary (and in fact is probably wrong) to say “an event occurrence occurs”, because the noun form (an occurrence of X) and the verb form (an event X occurs) are really too ways to say the same thing. Event restored as metaclass. The other complaint was the removal in the UML2 adopted specification of the subclasses of Event by pushing all of the subtyping information into subtypes of Trigger. While this works OK for transitions, it removed the possibility of talking about the various kinds of events directly, which several people emphasized was important. The other change has been addingSo I have restored subclasses of Event: ChangeEvent, SignalEventSendEvent, etc, etc. At the same time I removed the subclasses of Trigger, because Trigger will now just reference an Event, which can be of any subtype. This change was urgently requested by several people and it does close a big hole in the conceptual model at little cost (except for lots of minor edits). The metamodel cost is only one additional reference within Trigger and a couple of extra constraints in actions to make sure the right kind of event is reference in a trigger. But it now allows the various event subclasses to be used independently of Trigger, which seems important for descriptive purposes to many people. Conflicts with the new naming pattern I have had to rename a few other classes to avoid confusion, notably CollaborationOccurrence to CollaborationUse (it has nothing to do with event occurrence, so the name was misleading). The English word “occurrence” has several senses, but we have given a temporal meaning to “occurrence” and a “spatial” meaning to “use”. I have gone through and cleaned up the usage of the words event, trigger, and occurrence, consistent with these general principles. I didn’t fuss about every minor wording where the meaning is clear enough, but I focused on all the important or possible misleading wordings, especially in definitions and key semantics. Hopefully the terminology is now consistent and uniform. Imprecise wording I also corrected some language that was imprecise in making distinctions between the various levels of behavior. Changes to the published UML superstructure text: Note: Boldface within quotes shows the portion of the quote that changed. Roman face shows the unchanged portion. This convention is not applicable if the whole quote is in roman face. Changes to the metamodel are shown in red. Event stuff – This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording p212, diagram 150 and metamodel, Accept event actions: Delete association from AcceptCallAction to CallTrigger with rolename ‘trigger’. p216, AcceptCallAction, Associations: Delete ‘trigger: CallTrigger’ entry. p216, AcceptCallAction, Constraints, rephrase constraint 1: The result pins must match the in and inout parameters of the operation specified by the trigger event in number, type, and order. p216, AcceptCallAction, Contraints: Add new constaint 2: “[2] The trigger event must be a CallEvent. self.trigger.event.oclIsKindOf (CallEvent)” p216, AcceptCallAction, Semantics, sentence 1, rephrase as: This action accepts events representing the receipt of calls on the operation specified by the trigger call event. p217, AcceptEventAction, Associations, trigger, rephrase comment sentence 2: “If it is a trigger with a signal event, a signal of any subtype of the specified signal type is accepted.” p217, AcceptEventAction, constraints, rephrase constraints 2 and 3 as follows: “[2] If the trigger event is a ChangeEvent, there are no output pins. Same is true for CallEvent if this class is AcceptCallAction and not one of its children. [3] If the trigger event is a SignalEvent or a Time Event, there is exactly one output pin.” p254, ReplyAction, Associations, replyToCall: Change type from “CallTrigger” to “Trigger” and rephrase the comment as “The trigger specifying the operation whose call is being replied to.” p254, ReplyAction, Constraints, rephrase constraint 1: “[1] The reply value pins must match the return, out, and inout parameters of the operation on the event on the trigger in number, type, and order.” p254, ReplyAction, Constraints, add new constraint: “[2] The event on replyToCall trigger must be a CallEvent. self.replyToCall.event.oclIsKindOf (CallEvent)” p254, ReplyAction, Semantics, Paragraph 2, last sentence, replace “call trigger” with “call event on the trigger”. p377, Diagram 317, Triggers: Remove all the subclasses of Trigger. Add a directed association from Trigger to a new class Event with the rolename ‘event’, multiplicity 1. [[Not shown in the PDF file]] Add a new diagram “Events” after diagram “Triggers”. Place it in package Communications. Place in it abstract class Event as a subclass of PackageableElement. Take the hierarchy of classes formerly subclassed from Trigger, replacing ‘Trigger’ in each class name with ‘Event’, and place the new hierarchy as a subclass to Event. Rename “AnyEvent” (formerly “AnyTrigger”) to be “AnyReceiveEvent”. The subclasses preserve the attributes and associations that existed in the former hierarchy under Trigger. On the new Events diagram, also add as subclasses of Event the abstract metaclasses ExecutionEvent and LifetimeEvent. Add an association to Behavior called “behavior” with multiplicity 0..1. Add as subclasses of ExecutionEvent the concrete metaclasses ExecutionStartEvent and ExecutionFinishEvent. Add an association to Classifier called “type” with multiplicity 0..1. Add as subclasses of LifetimeEvent the concrete metaclasses CreationEvent and DestructionEvent. p378, Diagram 318, Simple Time: Replace class “TimeTrigger” with class “TimeEvent”. P378: Insert the following new entries into the chapter in the appropriate alphabetic order. Add the appropriate empty sections to satisfy the style. [begin inserted text] ExecutionEvent (from Events) An abstract class representing the initiation or completion of execution of behavior. Associations behavior: Behavior[0..1] -- The kind of behavior whose execution is being modeled. Semantics This event represents the initiation or completion of execution. The kind of behavior being modeled is optional. [Thomas: Is Behavior the most general class to type an execution? I know there were a number of changes to the schema. Maybe it is an Action now. We want to cover anything that could be an execution region on a lifeline, at least. Please check.] ExecutionInitiationEvent (from Events) An event representing the initiation of execution of a behavior. Semantics This event is not usually used as a trigger. It is usually used in interaction models. ExecutionCompletionEvent (from Events) An event representing the completion of execution of a behavior. Semantics This event is not usually used as an explicit trigger. On a transition, the absence of a trigger implies the completion event of the current state. It is usually used in interaction models. LifetimeEvent (from Events) An abstract class representing the creation or destruction of an instance. Associatons objectType: Classifier[0..1] -- The type of instance being modeled. Semantics This event reperesents the creation or destruction of an instance. The type of instance is optional. CreationEvent (from Events) An event representing the creation of an instance. Semantics This event is not usually used as an explicit trigger. It is usually used in interaction models. DestructionEvent (from Events) An event representing the destruction of an instance. Semantics This event is not usually used as an explicit trigger. It is usually used in interaction models. [end inserted text] p379, AnyTrigger: Title: Change “AnyTrigger” to “AnyMessageEventAnyReceiveEvent” Description: Rephrase: “An AnyMessageEvent AnyReceiveEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.” Semantics: Rephrase: “An AnyMessageEvent AnyReceiveEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.” Notation: Replace “AnyTrigger” with “AnyMessageEventAnyReceiveEvent”. p385, CallTrigger: Title: Replace “CallTrigger” by “CallEvent” Summary: Replace by: “A CallEvent models the receipt by an object of a message invoking a call of an operation.” Description: Rephrase the first sentence as “A call event represents the reception of a request to invoke a specific operation.” (cutting the final phrase of the original sentence) Associations: Delete the phrase “that is specified by the call trigger” from the comment. Semantics: Rephrase first sentence as “A call event represents the reception of a request to invoke a specific operation on an object.” Changes from UML 1.x: Delete this section entirely. p385, ChangeTrigger: Title: Change “ChangeTrigger” to “ChangeEvent”. Summary: Replace with “A change event models a change in the system configuration that makes a condition true.” Description, beginning of first sentence: Change “A change trigger specifies an event that occurs” to “A change event occurs”. Notation: Rephrase as “A change event is denoted in a trigger by a Boolean expression.” Changes from UML1.x: Delete entire section. p391, insert new class Event: [begin insert] Event (from Communications) Description An event is the specification of some occurrence that may potentially trigger effects by an object. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics An event is the specification of some occurrence that may potentially trigger effects by an object. This is an abstract metaclass. Notation None. Changes from UML 1.x None. [end insert] p392, MessageTrigger: Title: Change “MessageTrigger” to “MessageEvent”. Description: Rephrase as: “A message event specifies the receipt by an object of either a call or a signal. MessageEvent is an abstract metaclass.” p396, SignalTrigger: Title: Change “SignalTrigger” to “SignalEvent”. Summary: Delete the phrase “the fact that a behavior may trigger based upon”. Semantics: Replace the first sentence by: A signal event occurs when a signal message, originally caused by a send action executed by some object, is received by another (possibly the same) object.” p399, TimeTrigger: Title: Change “TimeTrigger” to “TimeEvent”. Summary: Replace entirely with “A TimeEvent specifies a point in time. At the specified time, the event occurs.” Description: Replace entirely with “A time event specifies a point in time by an expression. The expression might be absolute or might be relative to some other point in time. Changes from UML1.x: Delete “This metaclass replaces TimeEvent.” p400, Trigger: Summary: Rephrase as “A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier. Event is an abstract metaclass.” SemanticsDescription: Second sentence: Replace “triggers” by “trigger”. Third sentence: Delete “Trigger is an abstract metaclass.” Semantics: Delete sentence 3 “Based on ... respectively.” Changes from UML1.x: Delete the final sentence “In UML2.0 ... event type.” p498: TimeTrigger (from BehaviorStateMachines, as specialized): Title: Change title to “TimeEvent”. Description: Change “time triggers” to “time events”. Naming pattern stuff and precise wording – overview explanation (The current specification doesn’t have any overview that ties together the model and the runtime configurations that it models. This provides at least a brief introduction and lays out the naming conventions.) Chapter 6, Preface. Before the Acknowledgements, insert the following sections: [begin insertion] Models and What They Model A model contains three major categories of elements: classifiers, events, and behaviors. Each major category models individuals in an incarnation of the system being modeled. A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects. An event describes a set of possible occurrences; an occurrence is something that happens that has some consequence within the system. A behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. Models do not contain objects, occurrences, and executions, because those things are the subject of models, not their content. Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties. Value specifications, occurrence specifications, and execution specifications model individual objects, occurrences, and executions within a particular context. The distinction between objects and models of objects, for example, may appear subtle, but it is important. Objects (and occurrences and executions) are the domain of a model and, as such, are always complete, precise, and concrete. Models of objects (such as value specifications) can be incomplete, imprecise, and abstract according to their purpose in the model. Semantic Levels and Naming A large number of UML metaclasses can be arranged into 4 levels with metasemantic relationships among the metaclasses in the different levels that transcend different semantic categories (e.g., classifiers, events, behaviors). We have tried (with incomplete success) to provide a consistent naming pattern across the various categories to place elements into levels and emphasize metarelationships among related elements in different levels. The following 4 levels are important: Type level – Represents generic types of entities in models, such as classes, states, activities, events, etc. These are the most common constituents of models because models are primarily about making generic specifications. Instance level – These are the things that models represent at runtime. They don’t appear in models directly (except very occasionally as detailed examples), but they are necessary to explain the semantics of what models mean. These classes do not appear at all in the UML2 metamodel or in UML models, but they underlie the meaning of models. We provide a brief runtime metamodel in the Common Behavior chapter, but we do not formally define the semantics of UML using the runtime metamodel. Such a formal definition would be a ma jor amount of work. Uses within a context – These are the things that represent instances within a generic, reusable context. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are not instances because they are generic. Value specifications – A realization of UML2, compared to UML, is that values can be specified at various levels of precision. The specification of a value is not necessarily an instance; it might be a large set of possible instances consistent with certain conditions. What appears in models is usually not instances (individual values) but specifications of values that may or may not be limited to a single value. In any case, models contain specifications of values, not values themselves, which are runtime entities. Individual appearances of a type within a context – These are roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are model elements, not instances, because they are generic and can be used many times to generate many different instances. We have established the following categories of concepts that we try to name using uniformnaming patterns: Types : Instances : Modeling of instancesValues : Individual use within a contextUses Classifier, Class : Instance, Object : InstanceSpecification : Part, /Role, Attribute, XXXUse (e.g., CollaborationUse) Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger) (XXXUse) Behavior : Execution : ExecutionSpecification : (various) (e.g., ActivityNode, State), XXXUse (e.g., InteractionUse) The appearances category has too wide a variety of elements to reduce to a single pattern, although the form XXXUse is suggested for simple cases where an appearance of an element is contained in a definition of the same kind of element. In particular, the word “event” has been used inconsistently in the past to mean both type and instance. The word “event” now mean the type and the word “occurrence” means the instance. When necessary, the clarifications phrases “event (type” (for event)) and “(event) occurrence” (for occurrence) are may be used. Note that this is consistent with the frequent English usage “an event occurs” = the occurrence of an event of a given type; so to describe a runtime situation, one could say “event X occurs” or “an occurrence of event X” depending on which form is more convenient in a sentence. It is redundant and incorrect to say “an event occurrence occurs”. [end insertion] Naming pattern stuff – renaming in the metamodel and text p369, Figure 306: Change “BehaviorOccurrence” to “BehaviorPerformance”. p370, BasicBehaviors, second paragraph: Change each appearance of “event” to “occurrence”. p370, Figure 307: In the diagram, change each appearance of the subword “Event” to “Occurrence” within a name. p371, first full paragraph, first sentence: Insert “an occurence of” before “an invocation event may result”. p371, Figure 308, Communication Domain Model: Change “InvocationEvent” to “InvocationOccurrence” and change “ReceivingEvent” to “ReceiveOccurrence” [sic]. p371, last paragraph: Change all appearances of “event” to “occurrence”. p372, Figure 309, Domain Model Showing Request Kinds: Change all subwords “Event” to “Occurrence” in names, except change “ReceivingEvent” to “ReceiveOccurrence”. p372, after Figure 309 in section “Communications”, replace all text on page as follows,: [begin insert] An invocation event occurrence represents the recognition of an invocation request after its receipt by a target object. Invocation event occurrences are the result of the execution of invocation actions (see “InvocationAction” on page 236). Invocation actions include send actions and call actions. A send action is specified by a Signal (see “Signal” on page 395) and argument values. The execution of a send action results in a send request, which results in a call event occurrence when it is recognized by the target object. A call action is specified by an Operation and argument values. The execution of a call action results in a call request, which results in a call event occurrence when it is recognized by the target object. Signal event occurrences and call event occurrences are specified by the corresponding metaclasses (see “SignalEvent” on page 396 and “CallEvent” on page 385). As shown in Figure 308, an object hosts a behavior execution (i.e., a behavior will be executed in the context of that object). The execution of an invocation action by the behavior constitutes an invocation occurrence. The invocation occurrence results in a request object that transmits the invocation request from the sender object (caller) to the receiver object (target). The receipt of the request by the receiver is manifest as a receive occurrence. When the receive occurrence matches a trigger defined in the class of the target object, it causes the execution of a behavior. The details of identifying the behavior to be invoked in response to the occurrence of an event are a semantic variation point. The resulting behavior execution is hosted by the target object. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. If the invocation action is synchronous, the request object also includes sufficient information to identify the execution that invoked the behavior, but this information is not available for the use of the invoked behavior (and, therefore, is not modeled). When a synchronous execution completes, this information is used to direct a reply message to the original behavior execution. The detection of an (event) occurrence by an object may cause a behavioral response. For example, a state machine may transition to a new state upon the occurrence of an event specified by a trigger owned by the state machine or an activity may be enabled upon the occurrence of an event specified by a trigger owned by an object. When an event occurrence is recognized by an object, it may have an immediate effect or the event may be saved in an event pool and have a later effect when it is matched by a trigger specified for a behavior. The occurrence of a change event (see “ChangeEvent” on page 385) is based on some expression becoming true. A time event occurs when a predetermined deadline expires (see “TimeEvent” on page 399). No data is passed by the occurrence of a change event or a time event. Figure 317 shows the hierarchy of events. [end of insert] p373, Figure 310, Domain Model showing event kinds: Delete diagram. The following changes to Chapter 14, Interactions, bring the terminology in line with the remainder of the spec. Most notably, ExecutionOccurrence and EventOccurrence are renamed ExecutionSpecification and OccurrenceSpecification to be parallel to ValueSpecification (where execution and occurrence belong to the run-time system like object and value). Note, however, that trace, as discussed in this chapter, properly belongs to the run-time system, therefore discus sions of (event) occurrences in traces remain valid (probably more valid than previously, with the proper distinction between models of instances and instances themselves). [There is additional loose wording in this chapter that mixes up class models, instance models, and actual instances, but I’m not going to rewrite all of that; most of it is understandable enough if you don’t take it literally.] Pp405326ff, Figure 326 and the following diagrams: In the metamodel, change class “ExecutionOccur rence” to “ExecutionSpecification” and change “EventOccurrence” to “OccurrenceSpecification” using a captial- letter-sensitive replace. Change class “Interactio nOccurrence” to “InteractionUse”. Propagate the change to all the diagrams in the chapter. Do a search-and-replace on these terms throughout the chapter. Do NOT replace “eventoccurrence” or “event occurrence”, which properly refer to the run-time environment. p416, EventOccurrence: Should have been replaced by “OccurrenceSpecification” Rephrase first paragraph as follows: “OccurrenceSpecifications represent event occurrences -- moments in time to which the executions of Actions are associated. An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption.” Remainder of section: The replace specified previously should have been done. p417, ExecutionOccurrence: Should have been replaced by “ExecutionSpecification” but requires some modification.: Replace the first paragraph as follows: 'An ExecutionSpecification is a specification of the execution of a unit of behavior within the Lifeline. Since the The duration of an ExecutionSpecification will have some duration, it is represented by two OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.' Remainder of section: The chapter-wide subsititions should have been done. Semantics: Replace the text as follows: The trace semantics of Interactions merely see an ExecutionnOccurrence as the trace <start, finish>. There may be event occurrences between these. Typically the start event occurrence and the finish event occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a return Message). p419, Interaction, Semantics, third paragraph, first sentence, rephrase: “A trace is a sequence of event occurrences, each of which is described by an OccurrenceSpecification in a model.” p420, Interaction, Relation of Trace Model to Execution Model, paragraph 3-6, rephrase: An InvocationOccurrence in the Execution model corresponds with an (event) Occurrence in a trace. Occurrences are modeled in an Interaction by OccurrenceSpecifications. Normally in Interaction the action leading to the invocation as such is not described (such as the sending action). However, if it is desirable to go into details, a Behavior (such as an Activity) may be associated with an OccurrenceSpecification. An occurrence in Interactions is normally interpreted to take zero time. Duration is always between occurrences. Likewise a ReceiveOccurrence in the Execution model is modeled by an OccurrenceSpecification. Similarly the detailed actions following immediately from this reception is often omitted in Interactions, but may also be described explicitly with a Behavior associated with that OccurrenceSpecification. A Request in the Execution model is modeled by the Message in Interactions. An Execution in the Execution model is modeled by an ExecutionSpecification in Interactions. An Execution is defined in the trace by two Occurrences, one at the start and one at the end. This corresponds to the StartOccurrence and the CompletionOccurrence of the Execution model p423, InteractionOccurrence: Should have been renamed to “InteractionUse”. The chapter-wide substitution will fix the wording in the text of this class. p443: Replace “CollaborationOccurrence” and “Collaboration Occurrence” by “Collaboratio nUse” everywhere on the page. Conflicts with the new pattern—necessary renamings Need to replace some other uses of the word “Occurrence” in class names, normally with the word “Use”, to avoid semantic confusion about the names: p155: In metamodel Figure 100 and elsewhere in the metamodel rename “CollaborationOccurrence” to be “CollaborationUse” and propagate to diagrams (notably figure 100). In the association Classifier-CollaborationUse (as renamed) rename rolename “occurrence” to “collaborationUse”. Global replace in the document “CollaborationOccurrence” with “CollaborationUse”. Global replace “collaboration occurrence” with “collaboration use” (cloning capitals). p157, Classifier (as specialized), associations: rename “occurrence” as “collaborationUse”. p179: Top diagram: Rename “Collaboration Occurrence” as “Collaboration Use”. p424, within syntax and following paragraphs: Rename “collaborationoccurrence” as “collaborationuse”. Event versus occurrence—cleaning up imprecise wording The following changes clean up the use of the word event as distinguished from (event) occurrence: p216, AcceptCallAction, Semantics, first paragrap End of Annotations:===== m: webmaster@omg.org Date: 08 Dec 2003 14:38:57 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Joaquin Miller Company: X-Change Technologies mailFrom: joaquin.no.spam@acm.org Notification: Yes Specification: UML 2 Section: 11.3.2 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: 8/no day2003 Page: 217 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/5.0 (Windows NT 5.0; U) Opera 7.22 [en] Description The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. Reply-To: Joaquin Miller X-Sender: jm-miller-at@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 26 Jan 2004 22:11:42 -0800 To: Juergen Boldt From: Joaquin Miller Subject: Re: ,gi, ,cb, Event--first three items for discussion X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0R6UYtU029658 Sorry: 6682 At 07:26 AM 1/26/2004, you wrote: Joaquin, what are the issue numbers for this?? -Juergen At 01:39 AM 1/26/2004, you wrote: Here are the first three of items for discussion, the result of my following the e-mail discussion of events and then reading every text in the Superstructure specification that mentions events. I briefly discuss the item and then state my conclusion. It will be a successful test each time it is found that one of my conclusions is false. As a bonus, no charge, there is a modeling use case at the end. 1. It is explained in e-mail that Trigger is not the M1 concept to the M0 event. "In UML2, an event is not modeled but occurs in the real world (M0). What is represented in UML2 is how the event effects things that are modeled. This is shown in the metaclass Trigger." "... triggers and event are separate notions..." "[A trigger is a specification of] "what to do" when "something happens"." It makes sense that Trigger is not the M1 concept to the M0 event. If it were, we would expect only one Trigger for each type of event. But same description of an event will appear in every trigger that is triggered by an event of that type (for example, 'myC:C.a = 0' will appear in every trigger that is to be triggered when myC.a changes from not zero to zero). So: Trigger is not event type. 2. It is claimed in e-mail that there is no place in UML 2 to specify events, except within triggers. That is correct. No model element represents a type of event. [But see Action below.] 3. It is specified in the UML 2 specification that ChangeTrigger replaces UML 1 ChangeEvent. That is false. A UML 2 trigger is not an event. But "a [UML 1] change event models an event that occurs when an explicit boolean expression becomes true." [formal/03-03-01 2.12.2.2 ChangeEvent] ........................................... Action --------- In contradiction with the rest of the specification, with actions, the specification says that a trigger is a type of event. It is, of course, possible that this is merely an editorial error. It is also quite possible that this is evidence of different understandings of the meaning of trigger by different U2P teams. And it is possible that i misread the text and it is to be read as meaning that a trigger specifies a type of event. This may call for an explanation of the difference between specifying and representing. 11.3.2 AcceptEventAction (CompleteActions) AcceptEventAction is an action that waits for the occurrence of an event meeting specified conditions. Attributes none Associations trigger : Trigger [1] The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted. ------------------------------------------------ ------------------------------------------------ ------------------------------------------------ A use case for specification of types of events in a UML 2 model: Certain behaviors must be initiated at a close. A close is a kind of time in a business cycle. Kinds of closes are market close, close of business, and close of accounting period. In UML 2, Close is a type of trigger event or close is a trigger event (one or the other). In the specifications of some systems for part of the operation of a business, there will be many triggers that specify the close, each in order to trigger the execution of its associated behavior, one of the behaviors necessary be initiated at close. There is a use for a specification of the event type, Close, in a single place in a UML model, which event type can then be used throughout the model in triggers. A change to the specification of the event type, Close, can then be made in one place, rather than in each trigger. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 26 Jan 2004 22:38:36 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,gi, ,cb, Issue 6682 suggestions on events Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see .SignalTrigger....) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Date: Tue, 27 Jan 2004 10:57:07 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, ,cb, Issue 6682 suggestions on events Thread-Index: AcPkoFzuwwWb3jqISTegUkR//h4ldgATQHS3 From: "Karl Frank" To: "UML Superstructure FTF" X-OriginalArrivalTime: 27 Jan 2004 15:57:08.0871 (UTC) FILETIME=[37F5C970:01C3E4EE] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0RFqVBc003106 Would someone with some expertise in SDL please comment on the following? (This leaves me out -- my colleague Randy Miller made the following observation). The use of signal as a model element representing events appears to be based on the TeleCom industry's SDL modeling approach. Does this observation do anything to clarify the terms of this discussion re: signal and event? Specifically, how does SDL in Telecom handle the Types of Events and did that aspect of SDL get included in UML 2 along with the sequence charts etc? - Karl Frank -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Tue 1/27/2004 1:38 AM To: UML Superstructure FTF Cc: Subject: ,gi, ,cb, Issue 6682 suggestions on events Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see ā..SignalTriggerā.¯...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Tue, 27 Jan 2004 16:00:35 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Joaquin Miller CC: UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see .SignalTrigger....) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 From: "Thomas Weigert" To: "Karl Frank" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Date: Tue, 27 Jan 2004 10:08:36 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0RGCkBc003553 In UML2, the model element signal does not represent an event. Please look at the introduction of the common behavior section. An instance a send action causes an event and transmits information. The signal specifies the information communicated. The history of "signal" has less to do with SDL than with the tradition of distinguishing between synchronous and asynchronous communication. At some point, there was a sense that signals represented asynchronous communication, while operations represented synchronous communication. However, in UML2 this all has been generalized through the new actions. All the best, Th. > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Tuesday, January 27, 2004 9:57 AM > To: UML Superstructure FTF > Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events > > > Would someone with some expertise in SDL please comment on the > following? (This leaves me out -- my colleague Randy Miller made > the following observation). > > The use of signal as a model element representing events appears > to be based on the TeleCom industry's SDL modeling approach. > > Does this observation do anything to clarify the terms of this > discussion re: signal and event? Specifically, how does SDL in > Telecom handle the Types of Events and did that aspect of SDL get > included in UML 2 along with the sequence charts etc? > > - Karl Frank > > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Tue 1/27/2004 1:38 AM > To: UML Superstructure FTF > Cc: > Subject: ,gi, ,cb, Issue 6682 suggestions on events > > > Guus and Berger both made helpful suggestions. > > Guus suggested looking at Signal. I see that the intended > use of Signal is close to what is called 'event' in an > event-based architecture. Here is a sample of what I find, > looking at Signal: > > 11.3.2 AcceptEventAction > ... > If the event is a SignalEvent, ... > > 13 Common Behaviors > 13.1 Overview > ... > A send request is specified by a Signal... > Signal events ... are specified by the corresponding > metaclass... (see SignalTrigger...) > > 13.3.21 Signal > A signal is a specification of type of send request > instances communicated between objects. > > Looking at Signal provides some illustrations of the problems. > 13.1 distinguishes SignalEvent from Signal. > 13.3.21 says a signal is type to items communicated between > objects, not to events. > > ....... > > Birger suggested that Operation could do the job of being > the type to some events. I see that a type for some events can > be expressed in the form: an event in which operation C.o is > invoked. But one of the first texts i hit is: > > 14.3.14 Message > ... > When a Message represents an Operation the arguments of the > Message are the arguments of the CallAction on the sending > Lifeline and the arguments of the CallEvent on the receiving Lifeline. > > This provides a couple of puzzles in one sentence: > > It says one model element (a message) represent another > model element (an operation). > > It suggests that CallEvent is an element of the langauge: > that a model can contain call events. > > And it makes makes Operation distinct from CallEvent. > > ....................... > > I appreciate the suggestions. I apologize that, for the > moment, i use them to illustrate the problems. > > Cordially, > > Joaquin > > > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > > > From: "Thomas Weigert" To: "Guus Ramackers" , "Joaquin Miller" Cc: "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Date: Tue, 27 Jan 2004 12:25:52 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal The text quoted is what the UML 2 says about signals. It is very clear that a signal specifies the communicated data, not the event. In UML2 a signal is NOT an event type or event specification. If you want to add an explicit modeling of events, you have * explain how it fits into the informal semantics of behavior * clearly lay out the metamodel I suggest to start with the first. Take the common behavior intro section and edit it by the proposed dealing with events and event specifications. Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Tuesday, January 27, 2004 10:01 AM To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see .SignalTrigger....) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Jan 2004 12:07:50 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-to: "Joaquin Miller" X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Jan 2004 12:07:50 -0800 To: "UML Superstructure FTF" From: "Joaquin Miller" Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-WSS-ID: 6C081245124575-01-01 X-OriginalArrivalTime: 27 Jan 2004 20:41:32.0491 (UTC) FILETIME=[F2AB91B0:01C3E515] X-WSS-ID: 6C09CA0F174294-01-01 Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction .. If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview .. A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ...... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message .. When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ...................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Jan 2004 22:03:46 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,gi, ,cb, Issue 6682 Event--fourth, fifth, and sixth items for discussion [As with the first three, i am at this point looking only for agreement or contradiction. It is quite likely i do not yet understand the model enough to make suggestions. If the conclusions of 5 and 6 are correct, then maybe i understand pretty well. If they are wrong, then i am likely still baffled.] 4. 11.3.2 AcceptEventAction ... Associations AcceptEventAction.trigger : Trigger [1] The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted. The UML 2 specification says that a trigger is a type of event. 5. Figure 307 shows a class, Object, associated with a class, BehaviorExecution. Behavior execution is associated with the class Event. If we rely on that diagram, an event is an individual, like an object; events are not types. 13.3.28 Trigger says: A trigger specifies the an event that may cause the execution of an associated behavior. Description A trigger specifies the an event that may cause the execution of an associated behavior. ... Semantics Events may cause execution of behavior, e.g the execution of the effect activity of a transition in a state machine. A triggers specifies the event that may trigger a behavior execution as well as any constraints on the event to filter out events not of interest. This says that a trigger specifies an individual event. This can't be right. This might be intended to say that a trigger specifies a type of event. But that's not right either. A trigger is triggered by a events of a certain type. 6. 15.3.11 State ... Associations State.deferrableTrigger: Trigger A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred. This is not correct. Events are retained, not triggers. ........................................... Here is a summary of the conclusions of the first three items 1. Trigger is not event type. 2. There is no place in UML 2 to specify events, except within triggers. 3. It is specified in the UML 2 specification that ChangeTrigger replaces UML 1 ChangeEvent. That is false. From: "Thomas Weigert" To: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 Event--fourth, fifth, and sixth items for discussion Date: Wed, 28 Jan 2004 07:18:19 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal The wording here is too loose. By "Trigger [1] The type of event accepted..." just means that this action has a trigger associated which describes under what conditions this action will fire. This puts a "filter" on the stream of environmental stimuli and will respond only to those that are detected by the filter (the trigger). When it is said that "A Trigger specifies the event that may cause the execution of an..." the word "specify" means that the trigger describes what environmental stimuli it will detect and pass on to whoever is listening. Anything happening in the environment of the trigger that matches this description will cause the trigger to detect it. I think the basic confusion here is that what you think of as an "event" the specification calls a "trigger". The class "Trigger" specifies such triggers. By trigger we mean a set of facts about the environment that occurred which an action or a statemachine (or whatever) respond to. The metaclass Trigger gives the specification of this set of facts. The reason why this name was changed from "event" was that it was very confusing. Events, for example, are instantaneous things. How could you store them in a queue. What you store are representations of the events, and this is what the trigger is. It actually is absolutely irrelevant what really happened, what mattered is what the trigger filtered on and detected. For example, a trigger may be a Boolean combination of events. A trigger may also contain static conditions. Therefore, when it is said below, that "A deferred trigger is retained until...." this is exactly what is meant. So: i. events happen in the world. ii. Triggers are descriptions of (possibly a combination of) such events or other static conditions, i.e., they are a filter on a set of facts about the world. iii. The actual occurrence of that set of facts is referred to as a "trigger" as it, in a sense, is specified by the Trigger. iv. the statemachine, action, etc., respond to a trigger, not an event. Hope this clarifies. Th. > -----Original Message----- > From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Wednesday, January 28, 2004 12:04 AM > To: UML Superstructure FTF > Subject: ,gi, ,cb, Issue 6682 Event--fourth, fifth, and sixth items for > discussion > > > [As with the first three, i am at this point looking only for > agreement or > contradiction. It is quite likely i do not yet understand the > model enough > to make suggestions. If the conclusions of 5 and 6 are correct, > then maybe > i understand pretty well. If they are wrong, then i am likely > still baffled.] > > 4. > 11.3.2 AcceptEventAction > ... > Associations > AcceptEventAction.trigger : Trigger [1] The type of event accepted by the > action, as specified by a trigger. If it is a signal trigger, a > signal of > any subtype of the specified signal type is accepted. > > The UML 2 specification says that a trigger is a type of event. > > 5. Figure 307 shows a class, Object, associated with a class, > BehaviorExecution. Behavior execution is associated with the class > Event. If we rely on that diagram, an event is an individual, like an > object; events are not types. > > 13.3.28 Trigger says: > A trigger specifies the an event that may cause the execution of an > associated behavior. > Description > A trigger specifies the an event that may cause the execution of an > associated behavior. ... > Semantics > Events may cause execution of behavior, e.g the execution of the effect > activity of a transition in a state machine. A triggers specifies > the event > that may trigger a behavior execution as well as any constraints on the > event to filter out events not of interest. > > This says that a trigger specifies an individual event. This can't be > right. This might be intended to say that a trigger specifies a type of > event. But that's not right either. > > A trigger is triggered by a events of a certain type. > > > 6. > 15.3.11 State > ... > Associations > State.deferrableTrigger: Trigger A list of triggers that are > candidates to > be retained by the state machine if they trigger no transitions > out of the > state (not consumed). A deferred trigger is retained until the state > machine reaches a state configuration where it is no longer deferred. > > This is not correct. Events are retained, not triggers. > > ........................................... > > Here is a summary of the conclusions of the first three items > > 1. Trigger is not event type. > 2. There is no place in UML 2 to specify events, except within triggers. > 3. It is specified in the UML 2 specification that ChangeTrigger > replaces > UML 1 ChangeEvent. That is false. > > > To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 28 Jan 2004 08:43:37 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/28/2004 08:43:40, Serialize complete at 01/28/2004 08:43:40 Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Jan 2004 10:05:02 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,gi, ,cb, Issue 6682 Event--items for discussion 1 thru n Sorry, folks. I must have clicked the wrong button. [More to follow.] n. [text says] m. [we agree] [As with the first three, i am at this point looking only for agreement or contradiction. It is quite likely i do not yet understand the model enough to make suggestions. If the conclusions of 5 and 6 are correct, then maybe i understand pretty well. If they are wrong, then i am likely still baffled.] 4. 11.3.2 AcceptEventAction ... Associations AcceptEventAction.trigger : Trigger [1] The type of event accepted by the action, as specified by a trigger. If it is a signal trigger, a signal of any subtype of the specified signal type is accepted. The UML 2 specification says that a trigger is a type of event. 5. Figure 307 shows a class, Object, associated with a class, BehaviorExecution. Behavior execution is associated with the class Event. If we rely on that diagram, an event is an individual, like an object; events are not types. 13.3.28 Trigger says: A trigger specifies the an event that may cause the execution of an associated behavior. Description A trigger specifies the an event that may cause the execution of an associated behavior. ... Semantics Events may cause execution of behavior, e.g the execution of the effect activity of a transition in a state machine. A triggers specifies the event that may trigger a behavior execution as well as any constraints on the event to filter out events not of interest. This says that a trigger specifies an individual event. This can't be right. This might be intended to say that a trigger specifies a type of event. But that's not right either. A trigger is triggered by a events of a certain type. 6. 15.3.11 State ... Associations State.deferrableTrigger: Trigger A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred. This is not correct. Events are retained, not triggers. ........................................... Here is a summary of the conclusions of the first three items 1. Trigger is not event type. 2. There is no place in UML 2 to specify events, except within triggers. 3. It is specified in the UML 2 specification that ChangeTrigger replaces UML 1 ChangeEvent. That is false. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 te: Thu, 29 Jan 2004 12:47:07 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Branislav Selic CC: Joaquin Miller , UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Date: Thu, 29 Jan 2004 08:40:13 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, ,cb, Issue 6682 suggestions on events Thread-Index: AcPmZrQhPZIGwVXcRQyVoD7hDXgJngABUiSx From: "Karl Frank" To: "Guus Ramackers" , "Branislav Selic" Cc: "Joaquin Miller" , "UML Superstructure FTF" X-OriginalArrivalTime: 29 Jan 2004 13:40:15.0087 (UTC) FILETIME=[6CFD4FF0:01C3E66D] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0TDYGJN001083 Events as that which happens in time constitute a fundamentally distinct ontologic category from objects, that which exists. UML 2 is provisioned only for modeling objects and their appurtences. Hence whatever one represents in UML modeling elements shows up as a kind of object. The events, which we all know happen in the environment of a transducer, give rise in the OO software to event-objects. Depending on the design, these may be enqueued, and returned by methods such as getNextEvent() The event-objects are not events, but objects used to represent events. Most of the industry, again in my experience, uses the word "event" in some form for these objects, but UML 2 goes against this tradition and calls them "signals". - Karl See Herakleitus, Parmenides, and the first Macintosh toolbox for my sources in this. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Thu 1/29/2004 7:47 AM To: Branislav Selic Cc: Joaquin Miller; UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Guus Ramackers Cc: Joaquin Miller , UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 29 Jan 2004 08:47:03 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/29/2004 08:47:06, Serialize complete at 01/29/2004 08:47:06 Guus, There is indeed a backward compatibility issue. But, I don't believe it is particularly serious: I don't believe that anyone explicitly defined events in 1.x models because thre was no such notation. I actually recall the meeting at Oracle (your office) many years back, when, you, Eran, and I decided that the Event concept was a going to represent an event type and not an event occurrence. I now believe that this was a bad decision since it kept confusing people whose intuition told them that event means event occurrence. This was then discussed extensively in the U2P and the conclusion was that this needed to be changed. So, for better or worse, it got changed. Although, as Joaquin has pointed out nicely (thanks, Joaquin), it was not done consistently throughout the spec. In my view, changing it back now, will just cause more confusion. My personal view is that Event (occurrence), EventType, Message (instance), MessageType, and Trigger, are all separate but related concepts. We should clarify their relationships, define any missing concepts that people feel they need (EventType and MessageType?) and be done with it. My preference would be to model your OutOfStock event, as a MessageType (preferred) or, or as a Signal, or, if we are talking about a CIM, as an EventType (if we decide that we need the concept). Cheers, Bran Guus Ramackers 01/29/2004 07:47 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Joaquin Miller , UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: "Karl Frank" Cc: "Branislav Selic" , "Guus Ramackers" , "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Thu, 29 Jan 2004 13:02:45 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/29/2004 14:02:50, Serialize complete at 01/29/2004 14:02:50 This discussion shows a confusion over semantic categories that UML2 has, in fact, improved over UML1. One must be careful about quoting various English sentences in support of a particular terminoloy, because natural language is loose and uses words in many senses. An event occurrence is something that happens at run time. An event (type) is a type of an event. This follows normal UML terminology in using the naked word for the type and adding "instance", "occurrence", "object", or something like that for the run-time individual. There are several kinds of events--time events, condition events, etc. In particular, there are two kinds of events that programs can explicitly cause directly (as opposed to indirectly, such as making a condition true): invoking operations and sending signals. Conceptually (and this shows up in the interaction model) there are events corresponding to both issuing a request for a call/signal and to receiving such a request by the target. In real-time systems, one could conceive of other events associated with transmitting such a request, such as queuing/unqueuing, etc., but we pass over that in most ordinary modeling. Calling an operation or sending a signal are done by actions, so there is really no need to model a sending event in most cases (although it can appear in an interaction model)--the event is just the act of execution a call/send action, so we don't need to separately model send events or their types. We could, but it wouldn't serve much of a useful purpose. On the other end of the transmission, receiving an event has definite effects for state machines. We can name them "call events" or "signal events" and sometimes do in the text--more precisely, they are "receipt of call events" and "receive of signal events". There are also time events and condition events. In UML1, we had an Event type with subtypes for the different kinds, and further subtyping for signals (calls were not properly integrated). But the realization (and it wasn't I who did it) was that all of the distinction among event types aren't actually needed in the metamodel. The only way they show up is in state machine transitions, namely in the trigger rules, so in UML2 we have several subtypes of Trigger accordingly. A trigger is not quite the same as an event type--it's more a rule that includes an event type (implicitly) plus the parameters of the event that are relevant. So, the botton line is we don't actually model event types in UML2 and we don't need to. So what's a Signal? A signal is a kind of classifier, one that may be used as the information structure in a signal transmission. What you model in UML is the format of the data that the signal transmits and that the signal reception event makes available. It was modeled incorrectly in UML1, as a subtype of event. It's not an event, it a PARAMETER of a signal transmission request and of the signal reception event. This change made the whole model fit together properly and also matches programming language usage. After all, an Operation is not an event either--calling an operation is an action and the receipt of a call by a target object is a call event. So in UML2, we have types that describe the information in a message request, namely Signal and Operation, which primarily describe the data structure of the request. We have types that describe the triggerability of behavior by events, including the receipt of messages, namely Trigger and its subtypes (TimeTrigger, ChangeTrigger, CallTrigger, SignalTrigger, even AnyTrigger). We don't have types that describe event types themselves, and WE DON'T NEED THEM because they never appear separately. Actually I think we are in accord with most of the industry in the use of event to mean "something that happens". The use of the word to denote the whole message transmission or the message itself does occur, but it is a loose usage of English and cannot stand in precise usage. The use of "signal" to denote the message (more precisely, the information content in the message) again concurs with more precise industry usage. But it is necessary to distinguish the following terms that are often mixed together as "event" in casual speech: message -- the transmission of a request (including the values of the request) from a sender object to a receiver object, optionally including parameters of the transmission itself (such as times, delays, etc.) signal -- the type of information in a signal request object -- includes the run-time information in a signal request operation -- the type of information in a call request [there is no single run-time object corresponding to a call request, it is broken into pieces] event -- the type decribing the detection of some dynamic change of interest event occurrence -- an instance of some dynamic change of interest - Jim Rumbaugh (See a few interleaved comments in the following, exdented) "Karl Frank" 01/29/2004 05:40 AM To "Guus Ramackers" , "Branislav Selic" cc "Joaquin Miller" , "UML Superstructure FTF" Subject RE: ,gi, ,cb, Issue 6682 suggestions on events Events as that which happens in time constitute a fundamentally distinct ontologic category from objects, that which exists. UML 2 is provisioned only for modeling objects and their appurtences. See EventOccurrence under Interactions. They are for modeling event instances. So the following statements are false. Hence whatever one represents in UML modeling elements shows up as a kind of object. The events, which we all know happen in the environment of a transducer, give rise in the OO software to event-objects. Depending on the design, these may be enqueued, and returned by methods such as getNextEvent() The event-objects are not events, but objects used to represent events. Most of the industry, again in my experience, uses the word "event" in some form for these objects, but UML 2 goes against this tradition and calls them "signals". - Karl See Herakleitus, Parmenides, and the first Macintosh toolbox for my sources in this. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Thu 1/29/2004 7:47 AM To: Branislav Selic Cc: Joaquin Miller; UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus You can certainly model this. OutOfStock is a Signal type, i.e., a classifier describing the parameters of the event. Receiving such a signal is an event. A state machine could have a SignalTrigger for the reception of the signal. The signal trigger would have the signal type as one of its parameters. There is no need for a separate event type, and no backward compatibility issue (except that we have cleaned up a broken metamodel hierarchy and made it more usable with ordinary languages). Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") Operations can't be defined separately from classes (I tried that in the unified messaging proposal but it got shot down by several people. I guess I could have used your support) but that is a separate issue from events, and one that does have a lot to do with programming language feelings. But really, if that's what you want, signals are perfectly adequeate to model them, so why fuss about it? For the other who insist that the modeling language has to look just like the C-clan, they don't mind second class concepts. U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. The following has it correct: [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: No, it can't be the TYPE of some events. It can be the PARAMETER of some events. Not really a subtle distinction but an important one. There really isn't any problem here. 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Date: Thu, 29 Jan 2004 16:40:56 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, ,cb, Issue 6682 suggestions on events Thread-Index: AcPmq1pROgaUHpKlQGiYo94aub5VMAAAm5pX From: "Karl Frank" To: "James E Rumbaugh" Cc: "Branislav Selic" , "Guus Ramackers" , "Joaquin Miller" , "UML Superstructure FTF" X-OriginalArrivalTime: 29 Jan 2004 21:40:57.0961 (UTC) FILETIME=[94AE9D90:01C3E6B0] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0TLYuJN010496 Jim's email helps me in making headway. EventOccurrence is exactly what I said we did not have, so Jim is right in saying my bit below is false. The problem then is that the spec does NOT follow what Jim says is "normal UML" usage, "An event occurrence is something that happens at run time. An event (type) is a type of an event. This follows normal UML terminology in using the naked word for the type and adding "instance", "occurrence", "object", or something like that for the run-time individual. " Because the naked word is "event" and there is no model element representing the type. The confusion has been caused by using "signal" for the type and "eventOccurrence" for the run-time individual. Event of UML 1 has become Signal of UML 2. Note the following from the spec (page 401 as printed, page 417 in the pdf view) Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term ā..eventā.¯ means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Thu 1/29/2004 4:02 PM To: Karl Frank Cc: Branislav Selic; Guus Ramackers; Joaquin Miller; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events This discussion shows a confusion over semantic categories that UML2 has, in fact, improved over UML1. One must be careful about quoting various English sentences in support of a particular terminoloy, because natural language is loose and uses words in many senses. An event occurrence is something that happens at run time. An event (type) is a type of an event. This follows normal UML terminology in using the naked word for the type and adding "instance", "occurrence", "object", or something like that for the run-time individual. There are several kinds of events--time events, condition events, etc. In particular, there are two kinds of events that programs can explicitly cause directly (as opposed to indirectly, such as making a condition true): invoking operations and sending signals. Conceptually (and this shows up in the interaction model) there are events corresponding to both issuing a request for a call/signal and to receiving such a request by the target. In real-time systems, one could conceive of other events associated with transmitting such a request, such as queuing/unqueuing, etc., but we pass over that in most ordinary modeling. Calling an operation or sending a signal are done by actions, so there is really no need to model a sending event in most cases (although it can appear in an interaction model)--the event is just the act of execution a call/send action, so we don't need to separately model send events or their types. We could, but it wouldn't serve much of a useful purpose. On the other end of the transmission, receiving an event has definite effects for state machines. We can name them "call events" or "signal events" and sometimes do in the text--more precisely, they are "receipt of call events" and "receive of signal events". There are also time events and condition events. In UML1, we had an Event type with subtypes for the different kinds, and further subtyping for signals (calls were not properly integrated). But the realization (and it wasn't I who did it) was that all of the distinction among event types aren't actually needed in the metamodel. The only way they show up is in state machine transitions, namely in the trigger rules, so in UML2 we have several subtypes of Trigger accordingly. A trigger is not quite the same as an event type--it's more a rule that includes an event type (implicitly) plus the parameters of the event that are relevant. So, the botton line is we don't actually model event types in UML2 and we don't need to. So what's a Signal? A signal is a kind of classifier, one that may be used as the information structure in a signal transmission. What you model in UML is the format of the data that the signal transmits and that the signal reception event makes available. It was modeled incorrectly in UML1, as a subtype of event. It's not an event, it a PARAMETER of a signal transmission request and of the signal reception event. This change made the whole model fit together properly and also matches programming language usage. After all, an Operation is not an event either--calling an operation is an action and the receipt of a call by a target object is a call event. So in UML2, we have types that describe the information in a message request, namely Signal and Operation, which primarily describe the data structure of the request. We have types that describe the triggerability of behavior by events, including the receipt of messages, namely Trigger and its subtypes (TimeTrigger, ChangeTrigger, CallTrigger, SignalTrigger, even AnyTrigger). We don't have types that describe event types themselves, and WE DON'T NEED THEM because they never appear separately. Actually I think we are in accord with most of the industry in the use of event to mean "something that happens". The use of the word to denote the whole message transmission or the message itself does occur, but it is a loose usage of English and cannot stand in precise usage. The use of "signal" to denote the message (more precisely, the information content in the message) again concurs with more precise industry usage. But it is necessary to distinguish the following terms that are often mixed together as "event" in casual speech: message -- the transmission of a request (including the values of the request) from a sender object to a receiver object, optionally including parameters of the transmission itself (such as times, delays, etc.) signal -- the type of information in a signal request object -- includes the run-time information in a signal request operation -- the type of information in a call request [there is no single run-time object corresponding to a call request, it is broken into pieces] event -- the type decribing the detection of some dynamic change of interest event occurrence -- an instance of some dynamic change of interest - Jim Rumbaugh (See a few interleaved comments in the following, exdented) "Karl Frank" 01/29/2004 05:40 AM To "Guus Ramackers" , "Branislav Selic" cc "Joaquin Miller" , "UML Superstructure FTF" Subject RE: ,gi, ,cb, Issue 6682 suggestions on events Events as that which happens in time constitute a fundamentally distinct ontologic category from objects, that which exists. UML 2 is provisioned only for modeling objects and their appurtences. See EventOccurrence under Interactions. They are for modeling event instances. So the following statements are false. Hence whatever one represents in UML modeling elements shows up as a kind of object. The events, which we all know happen in the environment of a transducer, give rise in the OO software to event-objects. Depending on the design, these may be enqueued, and returned by methods such as getNextEvent() The event-objects are not events, but objects used to represent events. Most of the industry, again in my experience, uses the word "event" in some form for these objects, but UML 2 goes against this tradition and calls them "signals". - Karl See Herakleitus, Parmenides, and the first Macintosh toolbox for my sources in this. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Thu 1/29/2004 7:47 AM To: Branislav Selic Cc: Joaquin Miller; UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus You can certainly model this. OutOfStock is a Signal type, i.e., a classifier describing the parameters of the event. Receiving such a signal is an event. A state machine could have a SignalTrigger for the reception of the signal. The signal trigger would have the signal type as one of its parameters. There is no need for a separate event type, and no backward compatibility issue (except that we have cleaned up a broken metamodel hierarchy and made it more usable with ordinary languages). Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") Operations can't be defined separately from classes (I tried that in the unified messaging proposal but it got shot down by several people. I guess I could have used your support) but that is a separate issue from events, and one that does have a lot to do with programming language feelings. But really, if that's what you want, signals are perfectly adequeate to model them, so why fuss about it? For the other who insist that the modeling language has to look just like the C-clan, they don't mind second class concepts. U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. The following has it correct: [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: No, it can't be the TYPE of some events. It can be the PARAMETER of some events. Not really a subtle distinction but an important one. There really isn't any problem here. 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: "Karl Frank" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 29 Jan 2004 17:04:01 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/29/2004 17:04:03, Serialize complete at 01/29/2004 17:04:03 Almost right, Karl, but not quite: Event disappeared completely as a metaclass. It did not become Signal nor did it become Trigger -- notwithstanding claims to the contrary in the spec and in some previous e-mails. It was meant to represent EventType in 1.x. The term "event" is now meant to convey "event occurrence", as Karl says. In the most general sense an event in UML 2 means an instantaneous change of state in the system. It could be many different things: the receiving or sending of a message, the tick of a clock, the start of execution of an action, the crash of a processor, the firing of a neuron.... There is really no mystery here and I don't think we have to go to Kant or Hiedegger to understand it -- in fact, I think that raising this to a metaphysical level only confuses things. Bran "Karl Frank" 01/29/2004 04:40 PM To: "James E Rumbaugh" cc: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events Jim's email helps me in making headway. EventOccurrence is exactly what I said we did not have, so Jim is right in saying my bit below is false. The problem then is that the spec does NOT follow what Jim says is "normal UML" usage, "An event occurrence is something that happens at run time. An event (type) is a type of an event. This follows normal UML terminology in using the naked word for the type and adding "instance", "occurrence", "object", or something like that for the run-time individual. " Because the naked word is "event" and there is no model element representing the type. The confusion has been caused by using "signal" for the type and "eventOccurrence" for the run-time individual. Event of UML 1 has become Signal of UML 2. Note the following from the spec (page 401 as printed, page 417 in the pdf view) Changes from UML 1.x The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term ā..eventā.¯ means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Thu 1/29/2004 4:02 PM To: Karl Frank Cc: Branislav Selic; Guus Ramackers; Joaquin Miller; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events This discussion shows a confusion over semantic categories that UML2 has, in fact, improved over UML1. One must be careful about quoting various English sentences in support of a particular terminoloy, because natural language is loose and uses words in many senses. An event occurrence is something that happens at run time. An event (type) is a type of an event. This follows normal UML terminology in using the naked word for the type and adding "instance", "occurrence", "object", or something like that for the run-time individual. There are several kinds of events--time events, condition events, etc. In particular, there are two kinds of events that programs can explicitly cause directly (as opposed to indirectly, such as making a condition true): invoking operations and sending signals. Conceptually (and this shows up in the interaction model) there are events corresponding to both issuing a request for a call/signal and to receiving such a request by the target. In real-time systems, one could conceive of other events associated with transmitting such a request, such as queuing/unqueuing, etc., but we pass over that in most ordinary modeling. Calling an operation or sending a signal are done by actions, so there is really no need to model a sending event in most cases (although it can appear in an interaction model)--the event is just the act of execution a call/send action, so we don't need to separately model send events or their types. We could, but it wouldn't serve much of a useful purpose. On the other end of the transmission, receiving an event has definite effects for state machines. We can name them "call events" or "signal events" and sometimes do in the text--more precisely, they are "receipt of call events" and "receive of signal events". There are also time events and condition events. In UML1, we had an Event type with subtypes for the different kinds, and further subtyping for signals (calls were not properly integrated). But the realization (and it wasn't I who did it) was that all of the distinction among event types aren't actually needed in the metamodel. The only way they show up is in state machine transitions, namely in the trigger rules, so in UML2 we have several subtypes of Trigger accordingly. A trigger is not quite the same as an event type--it's more a rule that includes an event type (implicitly) plus the parameters of the event that are relevant. So, the botton line is we don't actually model event types in UML2 and we don't need to. So what's a Signal? A signal is a kind of classifier, one that may be used as the information structure in a signal transmission. What you model in UML is the format of the data that the signal transmits and that the signal reception event makes available. It was modeled incorrectly in UML1, as a subtype of event. It's not an event, it a PARAMETER of a signal transmission request and of the signal reception event. This change made the whole model fit together properly and also matches programming language usage. After all, an Operation is not an event either--calling an operation is an action and the receipt of a call by a target object is a call event. So in UML2, we have types that describe the information in a message request, namely Signal and Operation, which primarily describe the data structure of the request. We have types that describe the triggerability of behavior by events, including the receipt of messages, namely Trigger and its subtypes (TimeTrigger, ChangeTrigger, CallTrigger, SignalTrigger, even AnyTrigger). We don't have types that describe event types themselves, and WE DON'T NEED THEM because they never appear separately. Actually I think we are in accord with most of the industry in the use of event to mean "something that happens". The use of the word to denote the whole message transmission or the message itself does occur, but it is a loose usage of English and cannot stand in precise usage. The use of "signal" to denote the message (more precisely, the information content in the message) again concurs with more precise industry usage. But it is necessary to distinguish the following terms that are often mixed together as "event" in casual speech: message -- the transmission of a request (including the values of the request) from a sender object to a receiver object, optionally including parameters of the transmission itself (such as times, delays, etc.) signal -- the type of information in a signal request object -- includes the run-time information in a signal request operation -- the type of information in a call request [there is no single run-time object corresponding to a call request, it is broken into pieces] event -- the type decribing the detection of some dynamic change of interest event occurrence -- an instance of some dynamic change of interest - Jim Rumbaugh (See a few interleaved comments in the following, exdented) "Karl Frank" 01/29/2004 05:40 AM To "Guus Ramackers" , "Branislav Selic" cc "Joaquin Miller" , "UML Superstructure FTF" Subject RE: ,gi, ,cb, Issue 6682 suggestions on events Events as that which happens in time constitute a fundamentally distinct ontologic category from objects, that which exists. UML 2 is provisioned only for modeling objects and their appurtences. See EventOccurrence under Interactions. They are for modeling event instances. So the following statements are false. Hence whatever one represents in UML modeling elements shows up as a kind of object. The events, which we all know happen in the environment of a transducer, give rise in the OO software to event-objects. Depending on the design, these may be enqueued, and returned by methods such as getNextEvent() The event-objects are not events, but objects used to represent events. Most of the industry, again in my experience, uses the word "event" in some form for these objects, but UML 2 goes against this tradition and calls them "signals". - Karl See Herakleitus, Parmenides, and the first Macintosh toolbox for my sources in this. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Thu 1/29/2004 7:47 AM To: Branislav Selic Cc: Joaquin Miller; UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Bran, If Signal has nothing to do with event type as the modeler defines them (as opposed to lower level system based events that you refer to) then there is a serious backward compatibility issue with UML 1.x. Again, I repeat my example of an event type "OutOfStock" with as event data the "product name". This is a common example in enterprise systems. Apparently I cannot define that anymore in UML 2.0. Thanks, Guus You can certainly model this. OutOfStock is a Signal type, i.e., a classifier describing the parameters of the event. Receiving such a signal is an event. A state machine could have a SignalTrigger for the reception of the signal. The signal trigger would have the signal type as one of its parameters. There is no need for a separate event type, and no backward compatibility issue (except that we have cleaned up a broken metamodel hierarchy and made it more usable with ordinary languages). Branislav Selic wrote: Please folks, do not conflate signals with events. An event, as informally defined in the common behaviors section, has to do with occurrences of things. The sending of a signal is an event occurrence as is the reception of a signal. In a multicast or broadcast situation, a send signal event occurrence could be followed by multiple receive signal occurrences. Given that this is the model in the current spec, there is no way that a signal can be an event -- unless we decide to change this rather fundamental view. That, in my opinion, is out of scope for an FTF. Cheers, Bran Joaquin Miller 01/27/2004 03:07 PM Please respond to Joaquin Miller To: UML Superstructure FTF cc: Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events Thanks, Guus. Good stuff. Something you point out raises an interesting topic. The only difference between a method call and a signal interchange seems to be that "A signal is defined independently of the classifiers handling the signal." This says that a signal and the sending of a signal can be specified, even if there is no reception for the signal. (That's desirable in event based architectures and event based design styles.) But an operation invocation can't be specified, unless there is a corresponding operation already on some classifier in the model. Signal is first class, operation second. (Smells a bit like methodology creeping into the language. Or a programming language bias. Or a tough doctrine of some schools of "O-O.") Operations can't be defined separately from classes (I tried that in the unified messaging proposal but it got shot down by several people. I guess I could have used your support) but that is a separate issue from events, and one that does have a lot to do with programming language feelings. But really, if that's what you want, signals are perfectly adequeate to model them, so why fuss about it? For the other who insist that the modeling language has to look just like the C-clan, they don't mind second class concepts. U2P decided to not adopt the general 3C approach to models of what happens. That approach permits specification of anything that happens, independently of specifying the participants. I don't propose to try to change that in this FTF. But i feel it is worth emphasizing this discrepancy or asymmetry in UML, in case it helps someone clarify the whole event business. The following has it correct: [Yes, right: One model is that events are something that happens or else types of things that happen, while signals are models of data passed between objects and operations are a declaration part of specifications of behaviors. In that model it is a step or a few from operation and reception-plus-signal to event. But a signal can certainly be used to specify a type of event, just as an operation can be used to specify a type of event. For that matter, a reception could be used to specify a type of event, if that reception had an associated signal. (Or maybe even if it did not. I don't know why it is that a reception is not required to have a signal.) Actually, a signal can be use to specify two different kinds of type of event: events in which that signal is sent, and events in which that signal is received by a reception. If we have signals in a model, both kinds of event types are useful.] ----------------------------------------------- Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." This is significant for its interpretation as event type, but there are a few other aspects that are worth clarifying in the spec: - the term Signal is used for the declaration of an Event specification in UML (Event is a term that is used frequently in system architectures) - clarify the definition of Signal to include 'indirect' communication, where a sender does not direct the signal to a particular receiver instance, but just "raises" the event. The sender may not know which instances (potentially of different types) will respond to the raising of the signal. At run-time there will be some implementation mechanism for this, but at design time we don't want to force people to model that mechanism explicitly (e.g. QueueHandlers etc). - clarify the definition of Signal to include events that are raised by "the system", rather than by an instance of a specified class For instance, time events don't always originate from an instance: they will be thrown by the system / container at run-time, but during specification time, all the user wants to do is specify that the event exists and what the triggered operations are (not that there is a Clock instance that sends the signal). Thanks, Guus Joaquin Miller wrote: Guus and Berger both made helpful suggestions. Guus suggested looking at Signal. I see that the intended use of Signal is close to what is called 'event' in an event-based architecture. Here is a sample of what I find, looking at Signal: 11.3.2 AcceptEventAction ... If the event is a SignalEvent, ... 13 Common Behaviors 13.1 Overview ... A send request is specified by a Signal... Signal events ... are specified by the corresponding metaclass... (see SignalTrigger ...) 13.3.21 Signal A signal is a specification of type of send request instances communicated between objects. Looking at Signal provides some illustrations of the problems. 13.1 distinguishes SignalEvent from Signal. 13.3.21 says a signal is type to items communicated between objects, not to events. ....... Birger suggested that Operation could do the job of being the type to some events. I see that a type for some events can be expressed in the form: an event in which operation C.o is invoked. But one of the first texts i hit is: No, it can't be the TYPE of some events. It can be the PARAMETER of some events. Not really a subtle distinction but an important one. There really isn't any problem here. 14.3.14 Message ... When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline. This provides a couple of puzzles in one sentence: It says one model element (a message) represent another model element (an operation). It suggests that CallEvent is an element of the langauge: that a model can contain call events. And it makes makes Operation distinct from CallEvent. ....................... I appreciate the suggestions. I apologize that, for the moment, i use them to illustrate the problems. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Date: Fri, 30 Jan 2004 11:56:19 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Trygve Reenskaug CC: Joaquin Miller , UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Trygve, I agree there is an analogy between Interface and Signal/event type in terms of "being able to be defined as a standalone concept". I believe that the spec for Interface (FAS, section 7.15) does allow the modeler to define the Interface as a stanalone concept (Classifier with properties), and then tie that to classes and components that realize or require it. Whether it is appropriate to use Signal as a standalone definition for an "event type" in the modeling domain seems disputed at this stage. Thanks, Guus Trygve Reenskaug wrote: Guus, An Interface is currently defined in terms of the classifier that provides it. But we also find Interfaces as a Component's required interfaces. Here, a major point is that the classifiers that provide the interfaces can and sometimes should be unknown. So, interfaces ought to be defined independently of the classifiers handling their operations The current def. of interface does not seem to cover its current usage. Interface should be a symmetric concept, neither tightly bound to requester nor to provider. Sounds like it should be like signals? --Trygve At 27.01.2004 16:00, Guus Ramackers wrote: Joaquin, Some more detailed comments on Signal, and suggestions for improving its interpretation as event type or specification: In UML 2.0 the definition of Signal is : A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal. the only difference between a method call and a signal interchange seems that "A signal is defined independently of the classifiers handling the signal." ............... -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: "Karl Frank" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 30 Jan 2004 15:22:04 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/30/2004 15:22:07, Serialize complete at 01/30/2004 15:22:07 OK, I've done a review of the situation with "events" and it's even messier than I thought. There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Cheers, Bran Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Date: Fri, 30 Jan 2004 15:51:20 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Thread-Index: AcPnb6lWLDodVgavRV2KMSNwOFGm1gAAgI9i From: "Karl Frank" To: "Branislav Selic" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" X-OriginalArrivalTime: 30 Jan 2004 20:51:22.0170 (UTC) FILETIME=[D162B1A0:01C3E772] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0UKjBJN021133 Good work in researching this. Before we go further I would like to take Guus' approach one step further and establish what our agreed baseline is. Consider this simple description of ordinary state-transition modeling and possibly familiar terminology. A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. Is not this the way most people use the term 'event'? If so, should our UML terminology agree with this? My answers to both questions are in the affirmative. Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 3:22 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) 3. the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) 4. call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Cheers, Bran To: "Karl Frank" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 30 Jan 2004 16:21:14 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/30/2004 16:21:22, Serialize complete at 01/30/2004 16:21:22 Karl, is your concern about terminology or what is being modeled? In my proposal, I suggested that we need to differentiate at least three kinds of things, because I saw a clear need for each one. Are you suggesting that we do not need to differentiate them? For example, in doing performance analysis of a UML model (something that people are already doing), it becomes quite important to differentiate the point in time when an action starts to execute and the point when it finishes. This means that we need the notion of start of execution and the notion of end of execution. It is also often necessary to talk about messages and their arrival rates and propagation time distributions. We can call these things anything we like, but we need to be able to talk about them and, often, to model them explicitly. I really think that this is the baseline that we need to agree to first. Once we have an agreement, we can tackle the names. What do you think? Cheers, Bran "Karl Frank" 01/30/2004 03:51 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Good work in researching this. Before we go further I would like to take Guus' approach one step further and establish what our agreed baseline is. Consider this simple description of ordinary state-transition modeling and possibly familiar terminology. A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. Is not this the way most people use the term 'event'? If so, should our UML terminology agree with this? My answers to both questions are in the affirmative. Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 3:22 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) 3. the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) 4. call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Cheers, Bran To: Branislav Selic Cc: "Guus Ramackers" , "Joaquin Miller" , "Karl Frank" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Fri, 30 Jan 2004 13:26:32 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/30/2004 14:26:38, Serialize complete at 01/30/2004 14:26:38 Branislav Selic 01/30/2004 12:22 PM To "Karl Frank" cc "Guus Ramackers" , "Joaquin Miller" , James E Rumbaugh/Cupertino/IBM@IBMUS, "UML Superstructure FTF" Subject RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) I think it is already closer than you think and you don't need to make so many changes. Let's go with the terms already in the metamodel and adjust the nonmetamodel terms (I.e., the English) if necessary. I have researched the current spec in working on an update of the UML Reference Manual. OK, I've done a review of the situation with "events" and it's even messier than I thought. There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) This has been called 'event' and it has the right meaning. However, we need to choose names for both the type and instance form, which seems to be the major fuss. Note that it does not appear in the metamodel right now and doesn't need to, so it's only a matter of text. 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) This has been called 'trigger' in CommonBehavior, which seems like a much better word than 'stimulus', because it implies action. So no change is needed. And trigger is only used in the type sense, because it is part of a generic description (such as a state machine). Any instance behavior follows the description. So we only need one word. 3. the notion of a communications vehicle that carries information between objects, including information about a change of state The has been called 'message' in interactions, and it has the right connotation. We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) No, that's a misconception. See below for the type vs. instance discussion. Keep event for the type and event occurrence for the instance specification. 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) This was confusing in UML1 so let's not bring back the word "stimulus". Trigger is actually a much better word, because it is used that way in computing already (e.g., databases). 4. call the communications vehicle "message" This seems to be what everybody does. We need to distinguish event types (i.e., things that might appear in discussions of state machines, for example) and event instances (i.e., things that might appear in traces). Some people seem concerned that, as they claim, in ordinary speech "event" means an event instance. But, just like with many words in UML (such as "object"), in casual speech a word can often mean either a type thing or an instance thing depending on context, which is usually (but not always) clear from the discussion. Karl makes the point: A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. So in this usage, and in pretty much any modeling usage EXCEPT talking about traces, event means event type. There is also the general UML principle that we normally use the naked word for the type thing and append the word "instance" to describe the instance thing, partly for convenience because we are normally talking about type things (I've called them "desciptors" in the past to be slightly more general) in models and only occasionally about actual instances, mostly in examples. By the way, note that instances of any kind don't really appear in UML2 model any more, which does clean up a semantic confusion of UML1. As I read it, instances are the things that actually exist at run time. Therefore they don't appear in models. What appears in models are models of instances, which seem to be called "instance specifications". Although the distinction is subtle, the lack of it caused definite confusion in UML1. Similarly, "event occurrence" can probably be read as "specification of an event instance", so the word is not a bad choice, and not a pleonasm (I had to look it up--you can do the same!), because it actually makes a subtle but important distinction. - Jim Rumbaugh Date: Fri, 30 Jan 2004 16:56:15 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en To: Branislav Selic Cc: James E Rumbaugh , Guus Ramackers , Joaquin Miller , Karl Frank , UML Superstructure FTF Subject: Re: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) I think Jim's proposal has a lot of merit. I propose that we use it as the basis for cleaning up this confusion. Jishnu. James E Rumbaugh wrote: *Branislav Selic * 01/30/2004 12:22 PM To "Karl Frank" cc "Guus Ramackers" , "Joaquin Miller" , James E Rumbaugh/Cupertino/IBM@IBMUS, "UML Superstructure FTF" Subject RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) *I think it is already closer than you think and you don't need to make so many changes. Let's go with the terms already in the metamodel and adjust the nonmetamodel terms (I.e., the English) if necessary. I have researched the current spec in working on an update of the UML Reference Manual.* OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) This has been called 'event' and it has the right meaning. However, we need to choose names for both the type and instance form, which seems to be the major fuss. Note that it does not appear in the metamodel right now and doesn't need to, so it's only a matter of text. 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) This has been called 'trigger' in CommonBehavior, which seems like a much better word than 'stimulus', because it implies action. So no change is needed. And trigger is only used in the type sense, because it is part of a generic description (such as a state machine). Any instance behavior follows the description. So we only need one word. 3. the notion of a communications vehicle that carries information between objects, including information about a change of state The has been called 'message' in interactions, and it has the right connotation. We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) No, that's a misconception. See below for the type vs. instance discussion. Keep event for the type and event occurrence for the instance specification. 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) This was confusing in UML1 so let's not bring back the word "stimulus". Trigger is actually a much better word, because it is used that way in computing already (e.g., databases). 4. call the communications vehicle "message" This seems to be what everybody does. We need to distinguish event types (i.e., things that might appear in discussions of state machines, for example) and event instances (i.e., things that might appear in traces). Some people seem concerned that, as they claim, in ordinary speech "event" means an event instance. But, just like with many words in UML (such as "object"), in casual speech a word can often mean either a type thing or an instance thing depending on context, which is usually (but not always) clear from the discussion. Karl makes the point: A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. So in this usage, and in pretty much any modeling usage EXCEPT talking about traces, event means event type. There is also the general UML principle that we normally use the naked word for the type thing and append the word "instance" to describe the instance thing, partly for convenience because we are normally talking about type things (I've called them "desciptors" in the past to be slightly more general) in models and only occasionally about actual instances, mostly in examples. By the way, note that instances of any kind don't really appear in UML2 model any more, which does clean up a semantic confusion of UML1. As I read it, instances are the things that actually exist at run time. Therefore they don't appear in models. What appears in models are models of instances, which seem to be called "instance specifications". Although the distinction is subtle, the lack of it caused definite confusion in UML1. Similarly, "event occurrence" can probably be read as "specification of an event instance", so the word is not a bad choice, and not a pleonasm (I had to look it up--you can do the same!), because it actually makes a subtle but important distinction. - Jim Rumbaugh Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 Jan 2004 14:05:08 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Thanks, Jim. One suggestion. Similarly, "event occurrence" can probably be read as "specification of an event instance", so the word is not a bad choice, and not a pleonasm (I had to look it up--you can do the same!), because it actually makes a subtle but important distinction. Let's try to have parallelism between the vocabulary for things and for happenings. We have instanceSpecifications. But the are limited to instances of classifiers. And the classifiers are only the elements that represent sets of things. The elements that represent sets of happenings are not classifiers. Let's either allow instanceSpecification to also represent particular happenings (events, right?), or add OccurrenceSpecification, in order to allow us to represent particular happenings. I feel that using 'event occurrence' to represent a specification in the model of an event in the system is going to result in confusion of the kind we saw in users of UML 1 and saw in me, when reading the current UML 2 spec. In short, let's use 'occurrence' as parallel to 'instance,' or let's not use 'occurrence' at all, and use 'instance' for both things and happenings. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Fri, 30 Jan 2004 14:35:21 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/30/2004 15:35:26, Serialize complete at 01/30/2004 15:35:26 Based on Joaquin's suggestion: classifier : instance : instance specification :: class : object : object specification :: event : occurrence :: occurrence specifaction It does make things more parallel. And we can leave open the issue of whether an occurrence is an instance (and therefore whether an event is a classifier), because it really doesn't matter (so let's leave it alone--Classifier already has enough baggage, so let's keep it focused on data things, not happening things). It even fits normal speech ("the third occurrence of the UnexpectedIntruder event"). The "specificaton" suffix is a bit of a pain but it was even more of a pain when we tried to come up with 3 sets of names for every concept. In most text, you can say "the specification of the object" or "the specification of the occurrence" so it doesn't sound so bad. - Jim Rumbaugh Joaquin Miller 01/30/2004 02:05 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Thanks, Jim. One suggestion. Similarly, "event occurrence" can probably be read as "specification of an event instance", so the word is not a bad choice, and not a pleonasm (I had to look it up--you can do the same!), because it actually makes a subtle but important distinction. Let's try to have parallelism between the vocabulary for things and for happenings. We have instanceSpecifications. But the are limited to instances of classifiers. And the classifiers are only the elements that represent sets of things. The elements that represent sets of happenings are not classifiers. Let's either allow instanceSpecification to also represent particular happenings (events, right?), or add OccurrenceSpecification, in order to allow us to represent particular happenings. I feel that using 'event occurrence' to represent a specification in the model of an event in the system is going to result in confusion of the kind we saw in users of UML 1 and saw in me, when reading the current UML 2 spec. In short, let's use 'occurrence' as parallel to 'instance,' or let's not use 'occurrence' at all, and use 'instance' for both things and happenings. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Date: Fri, 30 Jan 2004 16:36:26 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0UMaQJN021941 Karl, the agreed upon baseline of what event and friends are is written up in the introduction to the common behavior section. I'd suggest to take this as a starting point and try to correct the inconsistencies in other parts of the spec found, if any, in light of that section. Any improvements that you want to do have to start with updating that section. Th. > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, January 30, 2004 2:51 PM > To: Branislav Selic > Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure > FTF > Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a > proposal) > > > Good work in researching this. > > Before we go further I would like to take Guus' approach one step > further and establish what our agreed baseline is. > > Consider this simple description of ordinary state-transition > modeling and possibly familiar terminology. > > A statemachine modeled in a statechart shows how an automaton > changes state in response to certain events. The automaton > modeled in this way is not any particular instance of this > statemachine, but is the general case, and the events that are > cited in the model are not particular occurrences in actual time, > but are types of such occurrences, such that ANY occurenc of the > modeled type at ANY time in history will cause ANY instance of > this statemachine to change state as described by the model, > according to the state it was in when an event of the given type occurs. > > Is not this the way most people use the term 'event'? > If so, should our UML terminology agree with this? > > My answers to both questions are in the affirmative. > > Karl > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Fri 1/30/2004 3:22 PM > To: Karl Frank > Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML > Superstructure FTF > Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events > (Includes a proposal) > > > > OK, I've done a review of the situation with "events" and > it's even messier than I thought. > > > * There is much inconsistency throughout the document > in the use of the terms "event", "event occurrence" (in > Interactions), "request", "stimulus", "trigger", and "message". > * One of the main ones comes from folding in the > Action semantics chapters. In these chapters "event" is most > definitely not used to mean "event occurrence" but, instead, > denotes the communication vehicle that some communication action > was executed (a call action or a signal received action). > * The Interactions chapter introduces an explicit > "event occurrence" concept -- which if we are to follow the > philosophy that we set out in Common Behavior (which we had > agreed on in U2P) -- is redundant, since "event" already means > "event occurrence". To make things more confusing, it also uses > the term "event" which, from what I can see, is synonymous with > event occurrence. The actual action names, also use "event" > rather than "event occurrence" (e.g., ReceiveEventAction). It > also uses the term "message" for denoting what the Actions > chapter calls "event". > * The Activities chapter (including some OCL > constraints) and the glossary still talk about "stimulus". > * I have not seen any occurrences of the old > interpretation of "event" as "event type", but I suspect it is there. > > > As I see it, we need at least the following basic concepts > to describe the run-time semantics of UML: > > > 1. the notion of an observable and instantaneous > change of state (e.g., change of the value of a variable, a time > out, a message send) > 2. the notion of something that causes a behavior to > execute; this is always the result of some change of state, but > not all changes of state will necessarily result in behavior > execution (e.g., the receipt of a message or the creation of an object) > 3. the notion of a communications vehicle that carries > information between objects, including information about a change of state > > > We may also need other things that build on these two basic > things, such as types for the above and classifications of > different kinds of change of state (not all of these necessarily > have to be reflected in the metamodel, but should be properly > defined in the spec). > > To get things going, I propose the following: > > > 1. call the observable and instantaneous change of > state an "event" -- because that fits most people's intuition of > what an event is > 2. do NOT use the pleonasm "event occurrence" (this > means changing Interactions in particular) > 3. call the notion of something that causes a behavior > to execute a "stimulus" (this will probably not be an actual > metamodel element) > 4. call the communications vehicle "message" > > > This is my proposal for the Tuesday afternoon discussion on > the topic of events. If you have an alternative proposal, please > send it out. > > Cheers, > Bran > > > Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 Jan 2004 14:41:24 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: ,gi, ,cb, Issue 6682 All the text on events The longer attachment has all the text on events. (Almost all, i chose to leave out a few that did not add anything that had not already appeared in previous text.) I send this to help folks who would like to do as Bran has done, and review the text. As i plowed through doing this, I quickly gave up adding document references. It is easy to find the context by simply copying a short text fragment and then searching the spec for that fragment. The shorter attachment shows the elements in the metamodel and the events "domain model." that have 'event' in the name. Cordially, Joaquin Event model elements--jm.txt Event text--jm.txt AcceptEventAction EventOccurrence NamedElement InteractionFragment EventOccurrence Stop (plain)EventOccurrence MessageEnd Event Occurrence[?] Gate The event "domain model" Event Trigger Event ReceivingEvent SpontaneousEvent ChangeEvent TimeEvent CallBehaviorEvent Termination Event Start Event InvocationEvent SendInvocationEvent CallInvocationEvent ReceivingEvent CallEvent SignalEvent TimeEvent [Time Event appears only on page 400.] ................................ [A message end may be in the roles sendEvent or receiveEvent with respect to a message. An event occurrence may be in the roles start or finssh with respect to an execution occurrence.] A send invocation event creates a send request and causes a signal event in the receiver. A call invocation event creates a call request and causes a call event in the receiver. Figure 318: namedElements play the role of events for timeExpressions and durations. (also check rolenames, some of the form 'xxxxEvent') Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 Jan 2004 14:46:20 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Bravo! Good work, Jim. Glad i could contribute. (There was an error in your "proportion;" below i change the last double colon to a single.) classifier : instance : instance specification :: class : object : object specification :: event : occurrence : occurrence specifaction It does make things more parallel. And we can leave open the issue of whether an occurrence is an instance (and therefore whether an event is a classifier), because it really doesn't matter (so let's leave it alone... Yes. Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Date: Fri, 30 Jan 2004 20:08:26 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Thread-Index: AcPndx9wyad1PPGkQbiVtcOJe0JkjQAHkYAb From: "Karl Frank" To: "Branislav Selic" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" X-OriginalArrivalTime: 31 Jan 2004 01:08:28.0263 (UTC) FILETIME=[BC0DAF70:01C3E796] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0V12bJN022634 My concern was with using familiar terms for familiar concepts. There are many many books and articles by Mealy, Moore, Harel, Lamport, Douglass, (Selic, Rumbaugh) and countless UML 1.n statechart models, that use 'event' in the way Jim was endorsing and which I tried to exemplify in my text sample. The idea that we can stipulate that "whateverwewant" shall henceforth be the term for event is the way to make UML 2 ridiculed.' My objective is to make UML used and usable without putting unnecessary roadblocks in its path by arbitrary and novel choices of words for familiar concepts. I am not raising any question about the need to differentiate the time when an action begins to execute and whether (for example) other actions are on the same or other process threads, etc....) - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 4:21 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Karl, is your concern about terminology or what is being modeled? In my proposal, I suggested that we need to differentiate at least three kinds of things, because I saw a clear need for each one. Are you suggesting that we do not need to differentiate them? For example, in doing performance analysis of a UML model (something that people are already doing), it becomes quite important to differentiate the point in time when an action starts to execute and the point when it finishes. This means that we need the notion of start of execution and the notion of end of execution. It is also often necessary to talk about messages and their arrival rates and propagation time distributions. We can call these things anything we like, but we need to be able to talk about them and, often, to model them explicitly. I really think that this is the baseline that we need to agree to first. Once we have an agreement, we can tackle the names. What do you think? Cheers, Bran "Karl Frank" 01/30/2004 03:51 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Good work in researching this. Before we go further I would like to take Guus' approach one step further and establish what our agreed baseline is. Consider this simple description of ordinary state-transition modeling and possibly familiar terminology. A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. Is not this the way most people use the term 'event'? If so, should our UML terminology agree with this? My answers to both questions are in the affirmative. Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 3:22 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) 3. the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) 4. call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Cheers, Bran To: "Karl Frank" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 31 Jan 2004 08:15:36 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/31/2004 08:15:48, Serialize complete at 01/31/2004 08:15:48 Let me concede on the naming issue -- especially since there does not seem to be any disagreement on the substantive issue (i.e., what are the things that we need to name). It seems that there is a consensus building up around Karl's, Joaquin's, and Jim's consolidated proposal. There is another advantage that I found while checking out the spec: almost the only place in the entire spec where "event" is used to mean "event occurrence" is in the CommonBehaviors chapter. Thus, from a purely practical point of view, if we change the text in CommonBehaviors chapter rather than the other way around, there is significantly less work and a lot less impact on the spec. Regards, Bran "Karl Frank" 01/30/2004 08:08 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) My concern was with using familiar terms for familiar concepts. There are many many books and articles by Mealy, Moore, Harel, Lamport, Douglass, (Selic, Rumbaugh) and countless UML 1.n statechart models, that use 'event' in the way Jim was endorsing and which I tried to exemplify in my text sample. The idea that we can stipulate that "whateverwewant" shall henceforth be the term for event is the way to make UML 2 ridiculed.' My objective is to make UML used and usable without putting unnecessary roadblocks in its path by arbitrary and novel choices of words for familiar concepts. I am not raising any question about the need to differentiate the time when an action begins to execute and whether (for example) other actions are on the same or other process threads, etc....) - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 4:21 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Karl, is your concern about terminology or what is being modeled? In my proposal, I suggested that we need to differentiate at least three kinds of things, because I saw a clear need for each one. Are you suggesting that we do not need to differentiate them? For example, in doing performance analysis of a UML model (something that people are already doing), it becomes quite important to differentiate the point in time when an action starts to execute and the point when it finishes. This means that we need the notion of start of execution and the notion of end of execution. It is also often necessary to talk about messages and their arrival rates and propagation time distributions. We can call these things anything we like, but we need to be able to talk about them and, often, to model them explicitly. I really think that this is the baseline that we need to agree to first. Once we have an agreement, we can tackle the names. What do you think? Cheers, Bran "Karl Frank" 01/30/2004 03:51 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Good work in researching this. Before we go further I would like to take Guus' approach one step further and establish what our agreed baseline is. Consider this simple description of ordinary state-transition modeling and possibly familiar terminology. A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. Is not this the way most people use the term 'event'? If so, should our UML terminology agree with this? My answers to both questions are in the affirmative. Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 3:22 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) 3. the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) 4. call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Cheers, Bran OMG Issue No: 6682 Title: See CommonBehavior for a description of Event specifications Source: X-Change Technologies Group, LLC (Mr. Joaquin Miller, joaquin.no.spam@acm.org) Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. Discussion: The following changes support the sentiment at the FTF meeting in Anaheim to regularize the terminology around events. Several people were strongly in favor of making these changes and nobody expressed opposition, so I have carried out the changes that I promised by searching the text document. The terminology obeys the following principles: We have the following categories of concepts that we try to name using uniform patterns: Types : Instances : Modeling of instances : Individual use within a context Classifier : Instance : InstanceSpecification : Part Class : Object : InstanceSpecification : Part Event : Occurrence : OccurrenceSpecification : (XXXUse) Behavior : Execution : ExecutionSpecification : (various) In particular, the word .event. has been used inconsistently throughout the document to mean both type and instance. The word .event. will now mean the type and the word .occurrence. will mean the instance. When necessary, the clarifications event (type) and (event) occurrence are used. Note that this is consistent with the frequent usage .an event occurs. = occurrence of an event of a given type, so much of the language can be left unchanged. The other change has been adding subclasses of Event: ChangeEvent, SignalEvent, etc. At the same time I removed the subclasses of Trigger, because Trigger will just reference an Event. This change was urgently requested by several people and it does close a big hole in the conceptual model at little cost (except for lots of minor edits). The metamodel cost is only one reference within Trigger. I have had to rename a few other classes to avoid confusion, notably CollaborationOccurrence to CollaborationUse (it has nothing to do with temporal occurrence, so the name was misleading). I have gone through and cleaned up the usage of the words event, trigger, and occurrence, consistent with these general principles. I didn.t fuss about every minor wording where the meaning is clear enough, but I focused on all the important or possible misleading wordings, especially in definitions and key semantics. Hopefully the terminology is now consistent and uniform. Changes to the published UML superstructure text: Note: Boldface within quotes shows the portion of the quote that changed. Roman face shows the unchanged portion. This convention is not applicable if the whole quote is in roman face. p8: Glossay entry .event.: This has the correct meaning and can remain unchanged. p15, Glossary entry .signal.: Change .stimulus that triggers. to .stimulus whose receipt is an event that triggers.. Rephrase the third sentence as .The data carried by a send request and passed to it by the occurrence of the send action that caused the request, the parameters of the request being represented as attributes of the signal instance.. p212, diagram 150, Accept event actions: Delete association from AcceptCallAction to CallTrigger with rolename .trigger.. p216, AcceptCallAction, Associations: Delete .trigger: CallTrigger. entry. p216, AcceptCallAction, Constraints, rephrase constraint 1: The result pins must match the in and inout parameters of the operation specified by the trigger event in number, type, and order. p216, AcceptCallAction, Contraints: Add new constaint 2: .[2] The trigger event must be a CallEvent. self.trigger.event.oclIsKindOf (CallEvent). p216, AcceptCallAction, Semantics, sentence 1, rephrase as: This action accepts events representing the receipt of calls on the operation specified by the trigger call event. p217, AcceptEventAction, Associations, trigger, rephrase comment sentence 2: .If it is a trigger with a signal event, a signal of any subtype of the specified signal type is accepted.. p217, AcceptEventAction, constraints, rephrase constraints 2 and 3 as follows: .[2] If the trigger event is a ChangeEvent, there are no output pins. Same is true for CallEvent if this class is AcceptCallAction and not one of its children. [3] If the trigger event is a SignalEvent or a TimeEvent, there is exactly one output pin.. p254, ReplyAction, Associations, replyToCall: Change type from .CallTrigger. to .Trigger. and rephrase the comment as .The trigger specifying the operation whose call is being replied to.. p254, ReplyAction, Constraints, rephrase constraint 1: .[1] The reply value pins must match the return, out, and inout parameters of the operation on the event on the trigger in number, type, and order.. p254, ReplyAction, Constraints, add new constraint: .[2] The event on replyToCall trigger must be a CallEvent. self.replyToCall.event.oclIsKindOf (CallEvent). p254, ReplyAction, Semantics, Paragraph 2, last sentence, replace .call trigger. with .call event on the trigger.. p377, Diagram 317, Triggers: Remove all the subclasses of Trigger. Add a directed association from Trigger to a new class Event with the rolename .event., multiplicity 1. Add a new diagram .Events. after diagram .Triggers.. Place in it class Event. Take the hierarchy of classes formerly subclassed from Trigger, replacing .Trigger. in each class name with .Event., and place the new hierachy as a subclass to Event. Rename .AnyEvent. (formerly .AnyTrigger.) to be .AnyReceiveEvent.. The subclasses preserve the attributes and associations that existed in the former hierachy under Trigger. p378, Diagram 318, Simple Time: Replace class .TimeTrigger. with class .TimeEvent.. p379, AnyTrigger: Title: Change .AnyTrigger. to .AnyMessageEvent. Description: Rephrase: .An AnyMessageEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.. Semantics: Rephrase: .An AnyMessageEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.. Notation: Replace .AnyTrigger. with .AnyMessageEvent.. p385, CallTrigger: Title: Replace .CallTrigger. by .CallEvent. Summary: Replace by: .A CallEvent models the receipt by an object of a message invoking a call of an operation.. Description: Rephrase the first sentence as .A call event represents the reception of a request to invoke a specific operation.. (cutting the final phrase of the original sentence) Associations: Delete the phrase .that is specified by the call trigger. from the comment. Semantics: Rephrase first sentence as .A call event represents the reception of a request to invoke a specific operation on an object.. Changes from UML 1.x: Delete this section entirely. p385, ChangeTrigger: Title: Change .ChangeTrigger. to .ChangeEvent.. Description, beginning of first sentence: Change .A change trigger specifies an event that occurs. to .A change event occurs.. Notation: Rephrase as .A change event is denoted in a trigger by a Boolean expression.. Changes from UML1.x: Delete entire section. p391, insert new class Event: Event (from Communications) Description An event is the specification of some occurrence that may potentially trigger effects by an object. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics An event is the specification of some occurrence that may potentially trigger effects by an object. This is an abstract metaclass. Notation None. Changes from UML 1.x None. p392, MessageTrigger: Title: Change .MessageTrigger. to .MessageEvent.. Description: Rephrase as: .A message event specifies the receipt by an object of either a call or a signal. MessageEvent is an abstract metaclass.. p396, SignalTrigger: Title: Change .SignalTrigger. to .SignalEvent.. Summary: Delete the phrase .the fact that a behavior may trigger based upon.. Semantics: Replace the first sentence by: A signal event occurs when a signal message, originally caused by a send action executed by some object, is received by another (possibly the same) object.. p399, TimeTrigger: Title: Change .TimeTrigger. to .TimeEvent.. Summary: Replace entirely with .A TimeEvent specifies a point in time. At the specified time, the event occurs.. Description: Replace entirely with .A time event specifies a point in time by an expression. The expression might be absolute or might be relative to some other point in time. Changes from UML1.x: Delete .This metaclass replaces TimeEvent.. p400, Trigger: Summary: Rephrase as .A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier. Event is an abstract metaclass.. Semantics: Second sentence: Replace .triggers. by .trigger.. Semantics: Delete sentence 3 .Based on ... respectively.. Changes from UML1.x: Delete the final sentence .In UML2.0 ... event type.. p498: TimeTrigger (from BehaviorStateMachines, as specialized): Title: Change title to .TimeEvent.. Description: Change .time triggers. to .time events.. A number of changes are required to the Common Behavior Overview to align it with these changes and to correct some imprecise wording. The intent of the overview is not changed: p369, Overview. After the first paragraph (ending in .occurrence of behaviors.) add the following: Models and What They Model A model contains three major categories of elements: classifiers, events, and behaviors. Each major category models individuals in an incarnation of the system being modeled. A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects. An event describes a set of possible occurrences; an occurrence is something that happens that has some consequence within the system. A behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. Models do not contain objects, occurrences, and executions, because those things are the subject of models, not their content. Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties. Value specifications, occurrence specifications, and execution specifications model individual objects, occurrences, and executions within a particular context. The distinction between objects and models of objects, for example, may appear subtle, but it is important. Objects (and occurrences and executions) are the domain of a model and, as such, are always complete, precise, and concrete. Models of objects (such as value specifications) can be incomplete, imprecise, and abstract according to their purpose in the model. [After the diagram, insert the new heading;] Behaviors p369, Figure 306: Change .BehaviorOccurrence. to .BehaviorPerformance.. p370, BasicBehaviors, second paragraph: Change each appearance of .event. to .occurrence.. p370, Figure 307: In the diagram, change each appearance of the subword .Event. to .Occurrence. within a name. p371, first full paragraph, first sentence: Insert .an occurence of. before .an invocation event may result.. p371, Figure 308, Communication Domain Model: Change .InvocationEvent. to .InvocationOccurrence. and change .ReceivingEvent. to .ReceiveOccurrence. [sic]. p371, last paragraph: Change all appearances of .event. to .occurrence.. p372, Figure 309, Domain Model Showing Request Kinds: Change all subwords .Event. to .Occurrence. in names, except change .ReceivingEvent. to .ReceiveOccurrence.. p372, first paragraph, rephrase as: Invocation occurrences are specified by various kinds of actions (see Chapter 5, .Actions.). A send request is specified by a Signal (see .Signal. on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. Signal occurrences and call occurrences are specified by the corresponding metaclasses (see .SignalEvent. on page xxx and .CallEvent. on page xxx). p372, second paragraph, first sentence, rephrase as: As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution environment to direct a reply message to the original execution. p372, third paragraph, first sentence: Change .Receiving events. to .Occurrences of receive events.. Second and third sentence, change .receiving event. to .receive event.. p372, last paragraph, rephrase slightly as follows: The occurrence of spontaneous events may also trigger behaviors: The occurrence of a change event (see .ChangeEvent. on page 385) is based on some expression becoming true. A time event occurs when a predetermined deadline expires (see .TimeEvent. on page 399). No data is passed by the occurrence of a spontaneous event except the event itself. [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract metaclasses that are not used in the actual metamodel.] p373, Figure 310, Domain Model showing event kinds: Delete diagram. The following changes to Chapter 14, Interactions, bring the terminology in line with the remainder of the spec. Most notably, ExecutionOccurrence and EventOccurrence are renamed ExecutionSpecification and OccurrenceSpecification to be parallel to ValueSpecification (where execution and occurrence belong to the run-time system like object and value). Note, however, that trace, as discussed in this chapter, properly belongs to the run-time system, therefore discussions of (event) occurrences in traces remain valid (probably more valid than previously, with the proper distinction between models of instances and instances themselves). [There is additional loose wording in this chapter that mixes up class models, instance models, and actual instances, but I.m not going to rewrite all of that; most of it is understandable enough if you don.t take it literally.] p326ff, Figure 326 and the following diagrams: In the metamodel, change class .ExecutionOccurrence. to .ExecutionSpecification. and change .EventOccurrence. to .OccurrenceSpecification. using a captial-letter-sensitive replace. Change class .InteractionOccurrence. to .InteractionUse.. Propagate the change to all the diagrams in the chapter. Do a search-and-replace on these terms throughout the chapter. Do NOT replace .eventoccurrence. or .event occurrence., which properly refer to the run-time environment. p416, EventOccurrence: Should have been replaced by .OccurrenceSpecification. Rephrase first paragraph as follows: .OccurrenceSpecifications represent event occurrences -- moments in time to which the executions of Actions are associated. An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption.. Remainder of section: The replace specified previously should have been done. p417, ExecutionOccurrence: Should have been replaced by .ExecutionSpecification.: Replace the first paragraph as follows: 'An ExecutionSpecification is a specification of the execution of a unit of behavior within the Lifeline. Since the ExecutionSpecification will have some duration, it is represented by two OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.' Remainder of section: The chapter-wide subsititions should have been done. Semantics: Replace the text as follows: The trace semantics of Interactions merely see an ExecutionOccurrence as the trace . There may be event occurrences between these. Typically the start event occurrence and the finish event occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a return Message). p419, Interaction, Semantics, third paragraph, first sentence, rephrase: .A trace is a sequence of event occurrences, each of which is described by an OccurrenceSpecification in a model.. p420, Interaction, Relation of Trace Model to Execution Model, paragraph 3-6, rephrase: An InvocationOccurrence in the Execution model corresponds with an (event) Occurrence in a trace. Occurrences are modeled in an Interaction by OccurrenceSpecifications. Normally in Interaction the action leading to the invocation as such is not described (such as the sending action). However, if it is desirable to go into details, a Behavior (such as an Activity) may be associated with an OccurrenceSpecification. An occurrence in Interactions is normally interpreted to take zero time. Duration is always between occurrences. Likewise a ReceiveOccurrence in the Execution model is modeled by an OccurrenceSpecification. Similarly the detailed actions following immediately from this reception is often omitted in Interactions, but may also be described explicitly with a Behavior associated with that OccurrenceSpecification. A Request in the Execution model is modeled by the Message in Interactions. An Execution in the Execution model is modeled by an ExecutionSpecification in Interactions. An Execution is defined in the trace by two Occurrences, one at the start and one at the end. This corresponds to the StartOccurrence and the CompletionOccurrence of the Execution model p423, InteractionOccurrence: Should have been renamed to .InteractionUse.. The chapter-wide substitution will fix the wording in the text of this class. p443: Replace .CollaborationOccurrence. and .Collaboration Occurrence. by .CollaborationUse. everywhere on the page. Need to replace some other uses of the word .Occurrence. in class names, normally with the word .Use., to avoid semantic confusion about the names: p155: In metamodel rename .CollaborationOccurrence. to be .CollaborationUse. and propagate to diagrams (notably figure 100). In the association Classifier-CollaborationUse (as renamed) rename rolename .occurrence. to .collaborationUse.. Global replace in the document .CollaborationOccurrence. with .CollaborationUse.. Global replace .collaboration occurrence. with .collaboration use. (cloning capitals). p157, Classifier (as specialized), associations: rename .occurrence. as .collaborationUse.. p179: Top diagram: Rename .Collaboration Occurrence. as .Collaboration Use.. p424, within syntax and following paragraphs: Rename .collaborationoccurrence. as .collaborationuse.. The following changes clean up the use of the word event as distinguished from (event) occurrence: p216, AcceptCallAction, Semantics, first paragraph, rephrase: .This action accepts (event) occurrences representing the receipt of calls on the operation specified by the call trigger. If an ongoing activity has executed an accept call action that has not completed and the owning object has an event occurrence representing a call of the specified activity, the accept call action claims the occurrence and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the occurrence, but one and only one action will claim the occurrence. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in a token on the returnInformation output pin. The execution of the accept call action is then complete. This return information token flows like any other data token, but the information in it is opaque and may not be manipulated by any actions. It only has meaning to ReplyA.. p217, AcceptEventAction, Semantics, parapraph 1-2, rephrase: Accept event actions handle event occurrences detected by the object owning the activity. Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. If the accept event action is executed and the object detected an occurrence matching the specification on the action and the occurrence has not been accepted by another action or otherwise consumed by another behavior, then the accept signal action completes and outputs a token describing the occurrence. If such a matching occurrence is not available, the action waits until such an occurrence becomes available, at which point the action may accept it. In a system with concurrency, several actions or other behaviors might contend for an available occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions. If the occurrence is of a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications. If an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept occurrences, no matter how many it accepts. It does not terminate after accepting an occurrence and outputing a value, but continues to wait for other occurrences. This semantic is an exception to the normal execution rules in Activities. p370, Common Behaviors, Basic behaviors, first paragraph, substitute: .partially ordered sequences of events. to .partially ordered sequences of occurrences. .observable events. to .observable occurrences. p372, Common Behaviors, Communications, 2nd paragraph on page, substitute: .the invocation event that eventually will lead. to .the invocation occurrence that eventually will lead. Third paragraph, rephrase: The detection of an (event) occurrence may cause a behavioral response. For example, a statemachine may transition to a new state upon detection of the occurrence of a trigger event or an activity may be enabled upon receipt of a message. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. The behavior will be executed in the context of the receiving object (i.e., the receiving object will host the behavior execution). The details of identifying the behavior to be invoked in response to the occurrence of an event is a semantic variation point. p381, Behavior, Semantics, Paragraph 3: The behavior executes within its context object, independently of and concurrently with any existing behavior executions. The object which is the context of the behavior manages the input pool holding the (event) occurrences to which a behavior may respond (see BehavioredClassifier on page 383). As an object may have a number of behaviors associated, all these behaviors may access the same input pool. The object ensures that each occurrence on the input pool is consumed by only one behavior. p383, BehavioredClassifier, Semantics Paragraph 2: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. p489, StateMachine, Overview: State machines can be used to express the behavior of part of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the detection of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine. p491, StateMachine, Semantics, Event Processing: Event occurrences are detected and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority-based schemes. The semantics of event processing is based on the run-to-completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event occurrence can only be taken from the pool and dispatched if the processing of the previous current event occurrence is fully completed. Run-to-completion may be implemented in various ways. For active classes, it may be realized by an event-loop running in its own thread, and that reads event occurrences from a pool. For passive classes it may be implemented as a monitor. The processing of a single event occurrence by a state machine is known as a run-to-completion step. Before commencing on a runto-completion step, a state machine is in a stable state configuration with all entry/exit/internal activities (but not necessarily state (do) activities) completed. The same conditions apply after the run-to-completion step is completed. Thus, an event occurrence will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine. The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its run-to-completion step. When an event occurrence is detected, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event (type) is not in the deferred event list of the current state configuration, the occurrence is discarded and the run-tocompletion step is completed. In the presence of orthogonal regions it is possible to fire multiple transitions as a result of the same event occurrence . as many as one transition in each region in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined. Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions (i.e., .bottomlevel. region) can fire at most one transition as a result of the current event occurrence. When all orthogonal regions have finished executing the transition, the current event occurrence is fully consumed, and the run-to-completion step is completed. During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a state machine, then the transition step is not completed until the invoked object complete its run-tocompletion step. p498, Transition, Overview: A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to the occurrence of an event of a particular type. p498, Transition, Associations, guard, substitute: .The guard is evaluated when an event is dispatched by the state machine.. to .The guard is evaluated when an event occurrence is processed by the state machine.. p500, Transition, Enabled transitions, 2nd bullet: . One of the triggers of the transition is satisfied by the event (type) of the current occurrence. An event satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization thereof. Disposition: Resolved To: "Nikolai Mansurov" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 11 Mar 2004 16:29:20 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/11/2004 16:29:23, Serialize complete at 03/11/2004 16:29:23 Nick, I reviewed your discussion on the issue and, although I agree with most of it in principle, I am greatly concerned that it may be beyond the scope of the FTF. It includes some rearranging of the Interactions metamodel that might be hazardous at this stage. I have more detailed comments below: > If you look at the SimpleTime package (Figure 318), Duration and > TimeExpression are said to be associated with "events" (role names > and text), but are (on the meta-model) associated with NamedElement. > Consider the text (pages 387 for Duration, 397-398 for TimeExpression). > > The text for Duration association event seems to be wrong: it says > that "event" refers to the specification(s) that describes the > starting TimeExpression (??) and the ending TimeExpression (??) of > the Duration. If only one NamedElement is referenced, the duration > is from the first point in time (!!) of that NamedElement until the > last point in time of that NamedElement. > > TimeExpressions are, of course NamedElements (as almost anything > else in the spec), but I believe that the "events" of Duration are > actually the new OccurenceSpecifications. A "point in time" looks > like an Occurence in the new terminology. > > By far, not all NamedElements can be associated with "points in > time".Therefore I believe that this is too general to type "event" > association of Duration and TimeExpression to a NamedElement. It > would be more appropriate to type them as OccurenceSpecifications. Having something more concrete than NamedElement to represent an event occurrence would definitely be an important improvement. > Please correct me, if I'm wrong, but Jim's proposal does not address > the above issue. I believe that you are correct. > Duration and TimeExpression should be associated with > OccurenceSpecification. Role of these associations should be renamed > from "event" to "occurencespec". Duration should always be > associated with two OccurenceSpecifications. Agreed. > This involves some tweaks in the Interactions meta-model. This is where I start to have my doubts. The fix described above is a simple and easy fix that blends nicely with the introduction of Event types and occurrences as proposed by Jim. However, what follows is an attempt to make a more systematic fix, which in an ideal world should be made, but which threatens to be highly destabilizing. > Consider InteractionFragments in Interactions ("things" on > Lifelines). The notion of InteractionFragment is probably the source of a lot of problems, since it reflects a notational viewpoint rather than a semantic viewpoint. As you point out, it merges a number of semantically quite diverse concepts. Your suggestions are, in essence, an attempt to impose a form on the interactions metamodel that is based on the semantic viewpoint. But, the metamodel is currently in large part based on a notational viewpoint. So, my concern is that your fixes, although justifiable from a theoretical viewpoint, are really an attempt to change the architecture of the metamodel. ...... > Now the question about Gates: do we want Durations and > TimeExpressions to be associated with Gates, or not ? > If we do, then MessageEnd should be a subclass of OccurenceSpecification. In my opinion, any attempt to more closely couple the SimpleTime metamodel with Interactions is a bad thing to do -- even if it seems to make sense. This is because it then imposes anyone who uses interactions to also adopt the simple time model. Remember that this model is called that because it is based on a centralized and idealized model of time. Many distributed applications will find this model inadequate (and, to be fair, it was not intended to be a universal model). Therefore, I would strongly oppose anything that would force people into using the simple time model. To summarize: my recommendation is that we just take the first part of your suggestion and replace the NamedElement in SimpleTime model with OccurrenceSpecification and leave it at that. (Oh, and I would get rid of the generalization from EventOccurrence to NamedElement -- this is probably something that Oystein forgot to clean up.) Regards, Bran Subject: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Date: Fri, 12 Mar 2004 17:31:09 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Thread-Index: AcQBPrDelc/MH29DTaykX+2ACR/UXwALtGnwAcSAAnA= From: "Nikolai Mansurov" To: "Branislav Selic (E-mail)" , Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? vvvBest regards, Nick Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Mar 2004 11:38:48 -0800 To: From: Joaquin Miller Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick wrote: 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). But he meant to write: Duration and TimeExpression are associated with NamedElements, ... PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Mon, 15 Mar 2004 09:31:33 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Nikolai Mansurov CC: "Branislav Selic (E-mail)" , uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=1.119, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Subject: RE: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Date: Mon, 15 Mar 2004 15:07:30 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Thread-Index: AcQKaAJ5AqHy2pOmToSAz2eyH+ttWAAWt6Nw From: "Nikolai Mansurov" To: "Oystein Haugen" Cc: "Branislav Selic (E-mail)" , Hi Oystein, Thanks for your detailed comments, I really appreciate you taking time to review, this was very valuable indeed. Regarding the "association targets" for Duration and Time Expression. I do understand that introducing a dependency between SimpleTime and Interaction packages is a concern. However, the possibility to associate Duration with ANY NamedElement is also a concern. For example, what is the meaning of a duration between two classes ? Logically, Duration should be an association between two OccurencesSpecifications, and nothing else. So, the question is, what other model elements specify OccurenceSpecifications ? Maybe we should move OccurenceSpecification to another package higher up in the hierarchy, like CommonBehaviors ? Then let Interactions::OccurenceSpecification subclass it. In fact, part of the original proposal was to rename Interactions::OccurenceSpecification into Interactions::OrderableOccurenceSpecification. Regarding the restructuring of subclasses of the InteractionFragment. You are absolutely right in pointing out that StateInvariants and Continuations are NOT subclasses of EventOccurence (OccurenceSpecification), but rather of InteractionFragment. I have to admit, this was a wrong summary of the original lengthy restructuring proposal. The rest of the proposal suggests having an abstract class CompositeOccurenceSpecification with associations to two OccurenceSpecifications (roles start and end). The reason: in Interaction one should be able to add Duration annotations also to InteractionUse, CombinedFragment and InteractionOperand. The goal of the whole restructuring is to more precisely specify the usage of Durations and Time Expressions with OccurenceSpecifications. In other words, the price of being more precise in defining the targets of Duration and TimeExpression is to either forbid InteractionUse and CombinedFragment as such targets (since they are currently not associated with EventOccurences), or to provide such associations (via an abstract class, or alterantively, directly). Best regards, Nick -----Original Message----- From: Oystein Haugen [mailto:oysteinh@ifi.uio.no] Sent: Monday, March 15, 2004 3:32 AM To: Nikolai Mansurov Cc: Branislav Selic (E-mail); uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Date: Mon, 15 Mar 2004 21:46:43 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Nikolai Mansurov CC: Oystein Haugen , "Branislav Selic (E-mail)" , uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=1.119, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Nick Thank you for your last clarifications. Let me try and summarize what is important to me in this context. 1. Simple time model is not only for Interactions. If it were, the time concepts would have been placed there which of course would have been wrong. 2. Making tweaks to the Interaction metamodel will only make the simple time model more associated with Interactions rather than the other behavioral notations. 3. NamedElement is definitely too general, but it was/is the lowest metaclass I could find. To improve this there is a need for further alignment of the different behavior description variants which probably goes beyond this FTF. The discussion on Event etc. etc. is a good start and probably this could be the start of this other discussion on time. 4. It is possible to write in the simple time model as constraints (textually) that only some constructs actually apply and not all NamedElements. Formally it is more difficult because of the placement of Common Behavior in the total package structure. Thanks, Oystein Nikolai Mansurov wrote: Hi Oystein, Thanks for your detailed comments, I really appreciate you taking time to review, this was very valuable indeed. Regarding the "association targets" for Duration and Time Expression. I do understand that introducing a dependency between SimpleTime and Interaction packages is a concern. However, the possibility to associate Duration with ANY NamedElement is also a concern. For example, what is the meaning of a duration between two classes ? Logically, Duration should be an association between two OccurencesSpecifications, and nothing else. So, the question is, what other model elements specify OccurenceSpecifications ? Maybe we should move OccurenceSpecification to another package higher up in the hierarchy, like CommonBehaviors ? Then let Interactions::OccurenceSpecification subclass it. In fact, part of the original proposal was to rename Interactions::OccurenceSpecification into Interactions::OrderableOccurenceSpecification. Regarding the restructuring of subclasses of the InteractionFragment. You are absolutely right in pointing out that StateInvariants and Continuations are NOT subclasses of EventOccurence (OccurenceSpecification), but rather of InteractionFragment. I have to admit, this was a wrong summary of the original lengthy restructuring proposal. The rest of the proposal suggests having an abstract class CompositeOccurenceSpecification with associations to two OccurenceSpecifications (roles start and end). The reason: in Interaction one should be able to add Duration annotations also to InteractionUse, CombinedFragment and InteractionOperand. The goal of the whole restructuring is to more precisely specify the usage of Durations and Time Expressions with OccurenceSpecifications. In other words, the price of being more precise in defining the targets of Duration and TimeExpression is to either forbid InteractionUse and CombinedFragment as such targets (since they are currently not associated with EventOccurences), or to provide such associations (via an abstract class, or alterantively, directly). Best regards, Nick -----Original Message----- From: Oystein Haugen [mailto:oysteinh@ifi.uio.no] Sent: Monday, March 15, 2004 3:32 AM To: Nikolai Mansurov Cc: Branislav Selic (E-mail); uml2-superstructure-ftf@omg.org Subject: Re: FW: ,gi, some inconsistencies in Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) Nick Please see the comments interleaved. I am sorry not to have addressed this before, but you seem to have misunderstood the meaning of the metamodel for simple time. My message is that this works, do not fix it. The tweaks will have cascading effects that may make other places less elegant. Nikolai Mansurov wrote: Hello all, I'm broadcasting my earlier message, which did not make it to the list because of some technical issues, now resolved. Please note, that there is already a response from Bran on this message from March 11th. Please find an executive summary of the message below. 1. There is an inconsistency in SimpleTime package: Duration and TimeExpression are associated with NamedEvents, while they should be in fact associated with EventOccurences (OccurenceSpecifications in the new terminology). This can be corrected by proper subclassing to EventOccurences (OccurenceSpecification in the new terminology). Originally the 'event' roles pointed to NamedElements and this was since the simple time model was not only addressing Interactions. In Interactions you would often attach the time expressions and durations to event occurrences, but in state machines there would be other kinds of metaclasses to attach to. Notice also that Common Behavior or higher in the package hierarchy and therefore the Interaction metaclasses are not available and therefore EventOccurrence cannot be used. Furthermore this is more general as it may not only associate to EventOccurrences even in Interactions, it may also associate with other interaction fragments with the obvious interpretation. This is exactly like in MSC. 2. There is a certain inconsistency in what are the subclasses of EventOccurences (OccurenceSpecification in the new terminology) (in Interactions). StateInvariant and Continuation - they are just some annotations of the Lifeline. Probably, it's not a good idea to associate Durations and TimeEvents with them. The proposal below suggests a restructuring of the EventOccurences (OccurenceSpecification in the new terminology) subtree. The motivation is to use EventOccurences (OccurenceSpecification in the new terminology) for proper subclassing in the SimpleTime package. StateInvariants and Continuations are NOT EventOccurrences if the metamodel has not been totally screwed up. They are Interaction Fragments and that is something very different and that is meaningful since the whole Interaction concept is built on Interaction Fragments. Please do not "fix" this. 2.1. There is a related question to the restructuring, suggested in #2: Do we want to add TimeExpressions and Durations to Gates, or just to EventOccurences ? Since we add "d = duration" annotation to a regular message between two Lifelines, would it be also desirable to add such annotation to a message to/from a Gate ? It may sound desirable to associate time expressions with gates, but the meaning of that is somewhat more involved. I do not think that is wise to do in the FTF. As today's addition, #2 above can be implemented simpy by a constraint within Interactions. Subclassing to EventOccurence, suggested in #1 above will create a coupling between SimpleTime and Interactions. Cheers, Nick I continue to comment below! -----Original Message----- From: Nikolai Mansurov Sent: Wednesday, March 03, 2004 8:07 PM To: Branislav Selic Cc: James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: ,gi, Proposed resolutions to issues 4263, 4456, 6682 (events/occurrences/types, etc.) There are some more inconsistencies in the meta-model that can be solved within the new "event" proposal. There is a gap between SimpleTime package and Interactions with respect to the target of Duration and TimeExpression associations. This is related to the "event" and "occurence" concepts. If you look at the SimpleTime package (Figure 318), Duration and TimeExpression are said to be associated with "events" (role names and text), but are (on the meta-model) associated with NamedElement. Consider the text (pages 387 for Duration, 397-398 for TimeExpression). The text for Duration association event seems to be wrong: it says that "event" refers to the specification(s) that describes the starting TimeExpression (??) and the ending TimeExpression (??) of the Duration. If only one NamedElement is referenced, the duration is from the first point in time (!!) of that NamedElement until the last point in time of that NamedElement. TimeExpressions are, of course NamedElements (as almost anything else in the spec), but I believe that the "events" of Duration are actually the new OccurenceSpecifications. A "point in time" looks like an Occurence in the new terminology. There is nothing wrong with this! You have misunderstood the modeling here. The Duration is an Interval and that interval has two Time Expressions (or one in the special case), but which specification elements are they attached to? That is what the 'event' association tells. It does not point to the Time Expressions but to the specification elements that are subject to these time expressions. By far, not all NamedElements can be associated with "points in time".Therefore I believe that this is too general to type "event" association of Duration and TimeExpression to a NamedElement. It would be more appropriate to type them as OccurenceSpecifications. Please correct me, if I'm wrong, but Jim's proposal does not address the above issue. Duration and TimeExpression should be associated with OccurenceSpecification. Role of these associations should be renamed from "event" to "occurencespec". Duration should always be associated with two OccurenceSpecifications. This involves some tweaks in the Interactions meta-model. Consider InteractionFragments in Interactions ("things" on Lifelines). Some of them are clearly Occurence specifications (in the new terminology): EventOccurence, ExecutionOccurence. Some are "containers for occurence specifications": CombinedFragment, InteractionOccurence. Others are not quite Occurence specifications: StateInvariant, Continuation - they are just some annotations of the Lifeline. This is just one example of NamedElements that you don't want to associate Durations with. Each InteractionFragment inherits directly from NamedElement. In fact, EventOccurence does so three times: super class InteractionFragment inheritcs from NamedElement; EventOccurence inherits directly; super class MessageEnd of EventOccurence also inherits from NamedElement. We should not restrict OccurenceSpecification to "things that can be placed on Lifelines in Interactions", as the current EventOccurence (because current EventOccurence covers a certain Lifeline). So, we should rename current EventOccurence not to OccurenceSpecification, but to e.g. OrderableOccurenceSpecification. And introduce new class OccurenceSpecification. Make OrderableOccurenceSpecification a subclass of OccurenceSpecification. As I have suggested earlier, OccurenceSpecification should be associated to an Event. I suggest to introduce a new abstract class "CompositeOccurenceSpecification", with associations to two OccurenceSpecifications (start and end). The subclasses of CompositeOccurenceSpecifications should be InteractionOccurence (InteractionUse in the new terminology), InteractionFragment and CombinedFragment and ExecutionOccurence (ExecutionSpecification in the new terminology). With the above distintion between OrderableOccurenceSpecification (on a certain Lifeline) and a general OccurenceSpecification, this makes sense: each CompositeOccurenceSpecification is associated with two Occurences, not one per each Lifeline. Now the question about Gates: do we want Durations and TimeExpressions to be associated with Gates, or not ? If we do, then MessageEnd should be a subclass of OccurenceSpecification. Now, question: are we allowing Durations and TimeExpressions to be associated with anything else, rather than the current EventOccurences, start and finish of InteractionOccurences and CombinedFragments, and, possibly, Gates ? Does it make sense to use Durations and TimeExpressions in Activity Diagrams and State Machines ? Having NamedElement as the target of these purely behavioral concepts seems an overkill. Does this make sense ? Best regards, Nick -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 16:21:37 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 16:21:39 After several rounds of discussion and several months of thought (since the Anaheim meeting), we now have a comprehensive and very systematic proposal from Jim R, Thomas W. and Joaquin M. on the outstanding issue of Events and Triggers (what are they? what should they be called? how are they manifested?). All the basic principles of this proposal are summarized in the first few paragraphs of the resolution (and will also be included in the spec itself). This is followed by a longish list of detailed changes most of which have been verified against the current spec. I am posting it now so that it gets adequate soak time before ballot 23 (coming out next Friday). So, if you feel passionately about this, please review and comment. The following are the most recent comments by Thomas on the current version -- so there are likely to be changes in that area. --------------------------------------------------------------------------- After reviewing the convenience document I have the following comments... First, I think that some of your rewrites in Section "Naming pattern stuff" change the meaning enough to be either unclear or different from before. I list them in the following: 1. The specification of an invocation occurrence includes an action, which may be one of the action subclasses (see Chapter 5, ā..Actionsā.¯). A send request is speciĀ­fied by a Signal (see ā..Signalā.¯ on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. 2. As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution environment engine to direct a reply message to the original execution. 3. [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract metaĀ­classes that are not used in the actual metamodel.] Note that these are examples where the changes went beyond what we discussed today. I am willing to tackle these three paragraphs to bring them in line with the rest of your document. But I do think that these were not changes for the better. --------------------------------------------------------------------------- Regards, Bran Events.Issues.Resolutions.040805.doc OMG Issue No: 6682 Title: See CommonBehavior for a description of Event specifications Source: X-Change Technologies Group, LLC (Mr. Joaquin Miller, joaquin.no.spam@acm.org) Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. Discussion: The following changes support the sentiment at the FTF meeting in Anaheim to regularize the terminology around events. Several people were strongly in favor of making these changes and nobody expressed opposition, so I have carried out the changes that I promised by searching the text document. Broadly, the following issues are addressed: 1. Establish and enforce a consistent naming policy for metaclasses over the categories of types, instances, values, and uses (references). 2. Restore Event as a class with subclasses instead of having subclasses of Trigger, and have Trigger point to Event (a particular trigger instance would point to an instance of a particular event subclass). 3. Rename a few other classes that break the pattern, such as using .occurrence. in their name when they do not refer to event instances, e.g., CollaborationOccurrence. 4. Clean up occasional sloppiness in the text in making distinctions between types and instances with respect to behavioral things such as events and executions. Consistent naming policy There was inconsistency in naming various kinds of behavioral things, with the same word being used for different things. In particular, the distinction between instances, roles, and value specifications was done differently and inconsistently. As these important but sometimes subtle distinctions are tricky enough, the naming inconsistencies made understanding difficult. The proposal supplies a regular pattern of naming. First we note the 4 different levels at which a concept might appear: Type level . Represents generic types of entities in models, such as classes, etc. These are the most common constituents of models. Instance level . These are the things that models represent at runtime. They don.t appear in models directly (except very occasionally as detailed examples), but they are necessary to explain the semantics of what models mean. Value specifications . Another realization of UML2 is that values can be specified at various levels of precision. What appears in models is usually not values but specifications of values that may or may not correspond to a single value. Individual appearances of a type within a context . These are the roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are not instances because they are generic. We have the following naming patterns: Types : Instances : Values : Uses Classifier : Instance : InstanceSpecification : Part, Role, XXXUse (e.g., CollaborationUse) Class : Object : InstanceSpecification : Part, Attribute Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger) Behavior : Execution : ExecutionSpecification : various (e.g., ActivityNode, State), XXXUse (e.g., InteractionUse) The appearances have too wide a variety of names to reduce to a single pattern, although the form XXXUse is suggested for simple cases. In particular, the word .event. has been used inconsistently throughout the document to mean both type and instance. The word .event. will now mean the type and the word .occurrence. will mean the instance. When necessary, the full form event type and event occurrence may be used. Note that this is consistent with the frequent usage .an event occurs. = the occurrence of an event of a given type, so much of the language can be left unchanged; it is not necessary (and in fact is probably wrong) to say .an event occurrence occurs., because the noun form (an occurrence of X) and the verb form (an event X occurs) are really too ways to say the same thing. Event restored as metaclass The other complaint was the removal in the UML2 adopted specification of the subclasses of Event by pushing all of the subtyping information into subtypes of Trigger. While this works OK for transitions, it removed the possibility of talking about the various kinds of events directly, which several people emphasized was important. So I have restored subclasses of Event: ChangeEvent, SendEvent, etc. At the same time I removed the subclasses of Trigger, because Trigger will now just reference an Event, which can be of any subtype. This change was urgently requested by several people and it does close a big hole in the conceptual model at little cost (except for lots of minor edits). The metamodel cost is only one additional reference within Trigger and a couple of extra constraints in actions to make sure the right kind of event is reference in a trigger. But it now allows the various event subclasses to be used independently of Trigger, which seems important for descriptive purposes to many people. Conflicts with the new naming pattern I have had to rename a few other classes to avoid confusion, notably CollaborationOccurrence to CollaborationUse (it has nothing to do with event occurrence, so the name was misleading). The English word .occurrence. has several senses, but we have given a temporal meaning to .occurrence. and a .spatial. meaning to .use.. I have gone through and cleaned up the usage of the words event, trigger, and occurrence, consistent with these general principles. I didn.t fuss about every minor wording where the meaning is clear enough, but I focused on all the important or possible misleading wordings, especially in definitions and key semantics. Hopefully the terminology is now consistent and uniform. Imprecise wording I also corrected some language that was imprecise in making distinctions between the various levels of behavior. Changes to the published UML superstructure text: Note: Boldface within quotes shows the portion of the quote that changed. Roman face shows the unchanged portion. This convention is not applicable if the whole quote is in roman face. Changes to the metamodel are shown in red. Event stuff . This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording p212, diagram 150 and metamodel, Accept event actions: Delete association from AcceptCallAction to CallTrigger with rolename .trigger.. p216, AcceptCallAction, Associations: Delete .trigger: CallTrigger. entry. p216, AcceptCallAction, Constraints, rephrase constraint 1: The result pins must match the in and inout parameters of the operation specified by the trigger event in number, type, and order. p216, AcceptCallAction, Contraints: Add new constaint 2: .[2] The trigger event must be a CallEvent. self.trigger.event.oclIsKindOf (CallEvent). p216, AcceptCallAction, Semantics, sentence 1, rephrase as: This action accepts events representing the receipt of calls on the operation specified by the trigger call event. p217, AcceptEventAction, Associations, trigger, rephrase comment sentence 2: .If it is a trigger with a signal event, a signal of any subtype of the specified signal type is accepted.. p217, AcceptEventAction, constraints, rephrase constraints 2 and 3 as follows: .[2] If the trigger event is a ChangeEvent, there are no output pins. Same is true for CallEvent if this class is AcceptCallAction and not one of its children. [3] If the trigger event is a SignalEvent or a TimeEvent, there is exactly one output pin.. p254, ReplyAction, Associations, replyToCall: Change type from .CallTrigger. to .Trigger. and rephrase the comment as .The trigger specifying the operation whose call is being replied to.. p254, ReplyAction, Constraints, rephrase constraint 1: .[1] The reply value pins must match the return, out, and inout parameters of the operation on the event on the trigger in number, type, and order.. p254, ReplyAction, Constraints, add new constraint: .[2] The event on replyToCall trigger must be a CallEvent. self.replyToCall.event.oclIsKindOf (CallEvent). p254, ReplyAction, Semantics, Paragraph 2, last sentence, replace .call trigger. with .call event on the trigger.. p377, Diagram 317, Triggers: Remove all the subclasses of Trigger. Add a directed association from Trigger to a new class Event with the rolename .event., multiplicity 1. [[Not shown in the PDF file]] Add a new diagram .Events. after diagram .Triggers.. Place it in package Communications. Place in it abstract class Event as a subclass of PackageableElement. Take the hierarchy of classes formerly subclassed from Trigger, replacing .Trigger. in each class name with .Event., and place the new hierarchy as a subclass to Event. Rename .AnyEvent. (formerly .AnyTrigger.) to be .AnyReceiveEvent.. The subclasses preserve the attributes and associations that existed in the former hierarchy under Trigger. p378, Diagram 318, Simple Time: Replace class .TimeTrigger. with class .TimeEvent.. p379, AnyTrigger: Title: Change .AnyTrigger. to .AnyReceiveEvent. Description: Rephrase: .An AnyReceiveEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.. Semantics: Rephrase: .An AnyReceiveEvent for a given transition specifies that the transition is triggered by the receipt of any message except for those specified explicitly on other transitions for the same state.. Notation: Replace .AnyTrigger. with .AnyReceiveEvent.. p385, CallTrigger: Title: Replace .CallTrigger. by .CallEvent. Summary: Replace by: .A CallEvent models the receipt by an object of a message invoking a call of an operation.. Description: Rephrase the first sentence as .A call event represents the reception of a request to invoke a specific operation.. (cutting the final phrase of the original sentence) Associations: Delete the phrase .that is specified by the call trigger. from the comment. Semantics: Rephrase first sentence as .A call event represents the reception of a request to invoke a specific operation on an object.. Changes from UML 1.x: Delete this section entirely. p385, ChangeTrigger: Title: Change .ChangeTrigger. to .ChangeEvent.. Summary: Replace with .A change event models a change in the system configuration that makes a condition true.. Description, beginning of first sentence: Change .A change trigger specifies an event that occurs. to .A change event occurs.. Notation: Rephrase as .A change event is denoted in a trigger by a Boolean expression.. Changes from UML1.x: Delete entire section. p391, insert new class Event: [begin insert] Event (from Communications) Description An event is the specification of some occurrence that may potentially trigger effects by an object. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics An event is the specification of some occurrence that may potentially trigger effects by an object. This is an abstract metaclass. Notation None. Changes from UML 1.x None. [end insert] p392, MessageTrigger: Title: Change .MessageTrigger. to .MessageEvent.. Description: Rephrase as: .A message event specifies the receipt by an object of either a call or a signal. MessageEvent is an abstract metaclass.. p396, SignalTrigger: Title: Change .SignalTrigger. to .SignalEvent.. Summary: Delete the phrase .the fact that a behavior may trigger based upon.. Semantics: Replace the first sentence by: A signal event occurs when a signal message, originally caused by a send action executed by some object, is received by another (possibly the same) object.. p399, TimeTrigger: Title: Change .TimeTrigger. to .TimeEvent.. Summary: Replace entirely with .A TimeEvent specifies a point in time. At the specified time, the event occurs.. Description: Replace entirely with .A time event specifies a point in time by an expression. The expression might be absolute or might be relative to some other point in time. Changes from UML1.x: Delete .This metaclass replaces TimeEvent.. p400, Trigger: Summary: Rephrase as .A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier. Event is an abstract metaclass.. Description: Second sentence: Replace .triggers. by .trigger.. Third sentence: Delete .Trigger is an abstract metaclass.. Semantics: Delete sentence 3 .Based on ... respectively.. Changes from UML1.x: Delete the final sentence .In UML2.0 ... event type.. p498: TimeTrigger (from BehaviorStateMachines, as specialized): Title: Change title to .TimeEvent.. Description: Change .time triggers. to .time events.. Naming pattern stuff and precise wording . overview explanation (The current specification doesn.t have any overview that ties together the model and the runtime configurations that it models. This provides at least a brief introduction and lays out the naming conventions.) Chapter 6, Preface. Before the Acknowledgements, insert the following sections: [begin insertion] Models and What They Model A model contains three major categories of elements: classifiers, events, and behaviors. Each major category models individuals in an incarnation of the system being modeled. A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects. An event describes a set of possible occurrences; an occurrence is something that happens that has some consequence within the system. A behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules. Models do not contain objects, occurrences, and executions, because those things are the subject of models, not their content. Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties. Value specifications, occurrence specifications, and execution specifications model individual objects, occurrences, and executions within a particular context. The distinction between objects and models of objects, for example, may appear subtle, but it is important. Objects (and occurrences and executions) are the domain of a model and, as such, are always complete, precise, and concrete. Models of objects (such as value specifications) can be incomplete, imprecise, and abstract according to their purpose in the model. Semantic Levels and Naming A large number of UML metaclasses can be arranged into 4 levels with metasemantic relationships among the metaclasses in the different levels that transcend different semantic categories (e.g., classifiers, events, behaviors). We have tried (with incomplete success) to provide a consistent naming pattern across the various categories to place elements into levels and emphasize metarelationships among related elements in different levels. The following 4 levels are important: Type level . Represents generic types of entities in models, such as classes, states, activities, events, etc. These are the most common constituents of models because models are primarily about making generic specifications. Instance level . These are the things that models represent at runtime. They don.t appear in models directly (except very occasionally as detailed examples), but they are necessary to explain the semantics of what models mean. These classes do not appear at all in the UML2 metamodel or in UML models, but they underlie the meaning of models. We provide a brief runtime metamodel in the Common Behavior chapter, but we do not formally define the semantics of UML using the runtime metamodel. Such a formal definition would be a major amount of work. Value specifications . A realization of UML2, compared to UML, is that values can be specified at various levels of precision. The specification of a value is not necessarily an instance; it might be a large set of possible instances consistent with certain conditions. What appears in models is usually not instances (individual values) but specifications of values that may or may not be limited to a single value. In any case, models contain specifications of values, not values themselves, which are runtime entities. Individual appearances of a type within a context . These are roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves. A realization of UML2 was that the things called instances in UML1 were mostly roles: they map to instances in an instance of their container, but they are model elements, not instances, because they are generic and can be used many times to generate many different instances. We have established the following naming patterns: Types : Instances : Values : Uses Classifier, Class : Instance, Object : InstanceSpecification : Part, Role, Attribute, XXXUse (e.g., CollaborationUse) Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger) Behavior : Execution : ExecutionSpecification : various (e.g., ActivityNode, State), XXXUse (e.g., InteractionUse) The appearances category has too wide a variety of elements to reduce to a single pattern, although the form XXXUse is suggested for simple cases where an appearance of an element is contained in a definition of the same kind of element. In particular, the word .event. has been used inconsistently in the past to mean both type and instance. The word .event. now mean the type and the word .occurrence. means the instance. When necessary, the phrases .event type. (for event) and .event occurrence. (for occurrence) may be used. Note that this is consistent with the frequent English usage .an event occurs. = the occurrence of an event of a given type; so to describe a runtime situation, one could say .event X occurs. or .an occurrence of event X. depending on which form is more convenient in a sentence. It is redundant and incorrect to say .an event occurrence occurs.. [end insertion] Naming pattern stuff . renaming in the metamodel and text p369, Figure 306: Change .BehaviorOccurrence. to .BehaviorPerformance.. p370, BasicBehaviors, second paragraph: Change each appearance of .event. to .occurrence.. p370, Figure 307: In the diagram, change each appearance of the subword .Event. to .Occurrence. within a name. p371, first full paragraph, first sentence: Insert .an occurence of. before .an invocation event may result.. p371, Figure 308, Communication Domain Model: Change .InvocationEvent. to .InvocationOccurrence. and change .ReceivingEvent. to .ReceiveOccurrence. [sic]. p371, last paragraph: Change all appearances of .event. to .occurrence.. p372, Figure 309, Domain Model Showing Request Kinds: Change all subwords .Event. to .Occurrence. in names, except change .ReceivingEvent. to .ReceiveOccurrence.. p372, first paragraph, rephrase as: The specification of an invocation occurrence includes an action, which may be one of the action subclasses (see Chapter 5, .Actions.). A send request is specified by a Signal (see .Signal. on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. Signal occurrences and call occurrences are specified by the corresponding metaclasses (see .SignalEvent. on page xxx and .CallEvent. on page xxx). p372, second paragraph, first sentence, rephrase as: As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution engine to direct a reply message to the original execution. p372, last paragraph, rephrase slightly as follows: The occurrence of other events may also trigger behaviors: The occurrence of a change event (see .ChangeEvent. on page 385) is based on some expression becoming true. A time event occurs when a predetermined deadline expires (see .TimeEvent. on page 399). [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract metaclasses that are not used in the actual metamodel.] p373, Figure 310, Domain Model showing event kinds: Delete diagram. The following changes to Chapter 14, Interactions, bring the terminology in line with the remainder of the spec. Most notably, ExecutionOccurrence and EventOccurrence are renamed ExecutionSpecification and OccurrenceSpecification to be parallel to ValueSpecification (where execution and occurrence belong to the run-time system like object and value). Note, however, that trace, as discussed in this chapter, properly belongs to the run-time system, therefore discussions of (event) occurrences in traces remain valid (probably more valid than previously, with the proper distinction between models of instances and instances themselves). [There is additional loose wording in this chapter that mixes up class models, instance models, and actual instances, but I.m not going to rewrite all of that; most of it is understandable enough if you don.t take it literally.] p405ff, Figure 326 and the following diagrams: In the metamodel, change class .ExecutionOccurrence. to .ExecutionSpecification. and change .EventOccurrence. to .OccurrenceSpecification. using a captial-letter-sensitive replace. Change class .InteractionOccurrence. to .InteractionUse.. Propagate the change to all the diagrams in the chapter. Do a search-and-replace on these terms throughout the chapter. Do NOT replace .eventoccurrence. or .event occurrence., which properly refer to the run-time environment. p416, EventOccurrence: Should have been replaced by .OccurrenceSpecification. Rephrase first paragraph as follows: .OccurrenceSpecifications represent event occurrences -- moments in time to which the executions of Actions are associated. An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption.. Remainder of section: The replace specified previously should have been done. p417, ExecutionOccurrence: Should have been replaced by .ExecutionSpecification. but requires some modification. Replace the first paragraph as follows: 'An ExecutionSpecification is a specification of the execution of a unit of behavior within the Lifeline. The duration of an ExecutionSpecification is represented by two OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.' Remainder of section: The chapter-wide subsititions should have been done. Semantics: Replace the text as follows: The trace semantics of Interactions merely see an Execution as the trace . There may be occurrences between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a return Message). p419, Interaction, Semantics, third paragraph, first sentence, rephrase: .A trace is a sequence of event occurrences, each of which is described by an OccurrenceSpecification in a model.. p420, Interaction, Relation of Trace Model to Execution Model, paragraph 3-6, rephrase: An InvocationOccurrence in the Execution model corresponds with an (event) Occurrence in a trace. Occurrences are modeled in an Interaction by OccurrenceSpecifications. Normally in Interaction the action leading to the invocation as such is not described (such as the sending action). However, if it is desirable to go into details, a Behavior (such as an Activity) may be associated with an OccurrenceSpecification. An occurrence in Interactions is normally interpreted to take zero time. Duration is always between occurrences. Likewise a ReceiveOccurrence in the Execution model is modeled by an OccurrenceSpecification. Similarly the detailed actions following immediately from this reception is often omitted in Interactions, but may also be described explicitly with a Behavior associated with that OccurrenceSpecification. A Request in the Execution model is modeled by the Message in Interactions. An Execution in the Execution model is modeled by an ExecutionSpecification in Interactions. An Execution is defined in the trace by two Occurrences, one at the start and one at the end. This corresponds to the StartOccurrence and the CompletionOccurrence of the Execution model p423, InteractionOccurrence: Should have been renamed to .InteractionUse.. The chapter-wide substitution will fix the wording in the text of this class. p443: Replace .CollaborationOccurrence. and .Collaboration Occurrence. by .CollaborationUse. everywhere on the page. Conflicts with the new pattern.necessary renamings Need to replace some other uses of the word .Occurrence. in class names, normally with the word .Use., to avoid semantic confusion about the names: p155: In Figure 100 and elsewhere in the metamodel rename .CollaborationOccurrence. to be .CollaborationUse. and propagate to diagrams (notably figure 100). In the association Classifier-CollaborationUse (as renamed) rename rolename .occurrence. to .collaborationUse.. Global replace in the document .CollaborationOccurrence. with .CollaborationUse.. Global replace .collaboration occurrence. with .collaboration use. (cloning capitals). p157, Classifier (as specialized), associations: rename .occurrence. as .collaborationUse.. p179: Top diagram: Rename .Collaboration Occurrence. as .Collaboration Use.. p424, within syntax and following paragraphs: Rename .collaborationoccurrence. as .collaborationuse.. Event versus occurrence.cleaning up imprecise wording The following changes clean up the use of the word event as distinguished from (event) occurrence: p216, AcceptCallAction, Semantics, first paragraph, rephrase: .This action accepts (event) occurrences representing the receipt of calls on the operation specified by the call trigger. If an ongoing activity has executed an accept call action that has not completed and the owning object has an event occurrence representing a call of the specified activity, the accept call action claims the occurrence and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the occurrence, but one and only one action will claim the occurrence. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in a token on the returnInformation output pin. The execution of the accept call action is then complete. This return information token flows like any other data token, but the information in it is opaque and may not be manipulated by any actions. It only has meaning to ReplyA.. p217, AcceptEventAction, Semantics, parapraph 1-2, rephrase: Accept event actions handle event occurrences detected by the object owning the activity. Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. If the accept event action is executed and the object detected an occurrence matching the specification on the action and the occurrence has not been accepted by another action or otherwise consumed by another behavior, then the accept signal action completes and outputs a token describing the occurrence. If such a matching occurrence is not available, the action waits until such an occurrence becomes available, at which point the action may accept it. In a system with concurrency, several actions or other behaviors might contend for an available occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions. If the occurrence is of a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications. If an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept occurrences, no matter how many it accepts. It does not terminate after accepting an occurrence and outputing a value, but continues to wait for other occurrences. This semantic is an exception to the normal execution rules in Activities. p370, Common Behaviors, Basic behaviors, first paragraph, substitute: .partially ordered sequences of events. to .partially ordered sequences of occurrences. .observable events. to .observable occurrences. p372, third paragraph, rephrase: The detection of an (event) occurrence may cause a behavioral response. For example, a statemachine may transition to a new state upon detection of the occurrence of a trigger event or an activity may be enabled upon receipt of a message. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. The behavior will be executed in the context of the receiving object (i.e., the receiving object will host the behavior execution). The details of identifying the behavior to be invoked in response to the occurrence of an event is a semantic variation point. p381, Behavior, Semantics, Paragraph 3: The behavior executes within its context object, independently of and concurrently with any existing behavior executions. The object which is the context of the behavior manages the input pool holding the (event) occurrences to which a behavior may respond (see BehavioredClassifier on page 383). As an object may have a number of behaviors associated, all these behaviors may access the same input pool. The object ensures that each occurrence on the input pool is consumed by only one behavior. p383, BehavioredClassifier, Semantics Paragraph 2: When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event (the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in the input event pool of the object and the later consumption of the occurrence by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event (type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by the event. p489, StateMachine, Overview: State machines can be used to express the behavior of part of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the detection of series of (event) occurrences. During this traversal, the state machine executes a series of activities associated with various elements of the state machine. p491, StateMachine, Semantics, Event Processing: Event occurrences are detected and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority-based schemes. The semantics of event processing is based on the run-to-completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event occurrence can only be taken from the pool and dispatched if the processing of the previous current event occurrence is fully completed. Run-to-completion may be implemented in various ways. For active classes, it may be realized by an event-loop running in its own thread, and that reads event occurrences from a pool. For passive classes it may be implemented as a monitor. The processing of a single event occurrence by a state machine is known as a run-to-completion step. Before commencing on a runto-completion step, a state machine is in a stable state configuration with all entry/exit/internal activities (but not necessarily state (do) activities) completed. The same conditions apply after the run-to-completion step is completed. Thus, an event occurrence will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine. The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its run-to-completion step. When an event occurrence is detected, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event (type) is not in the deferred event list of the current state configuration, the occurrence is discarded and the run-tocompletion step is completed. In the presence of orthogonal regions it is possible to fire multiple transitions as a result of the same event occurrence . as many as one transition in each region in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined. Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions (i.e., .bottomlevel. region) can fire at most one transition as a result of the current event occurrence. When all orthogonal regions have finished executing the transition, the current event occurrence is fully consumed, and the run-to-completion step is completed. During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a state machine, then the transition step is not completed until the invoked object complete its run-tocompletion step. p498, Transition, Overview: A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to the occurrence of an event of a particular type. p498, Transition, Associations, guard, substitute: .The guard is evaluated when an event is dispatched by the state machine.. to .The guard is evaluated when an event occurrence is processed by the state machine.. p500, Transition, Enabled transitions, 2nd bullet: . One of the triggers of the transition is satisfied by the event (type) of the current occurrence. An event satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization thereof. Disposition: Resolved OMG Issue No: 4456 Title: Event => Event Specification Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The event metaclass would better called "event specification". Or at least the runtime event should be called "occurences" rather than instances. Discussion: This issue is resolved by the resolution to issue 6682. Disposition: Resolved Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 00:06:13 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR789/PRCaBiRWpSzu5478gj5hLtwCZEWLw From: "Anders Ek" To: "Branislav Selic" , Cc: A question about this proposal from the statemachine point of view: Triggers were in the existing text owned by the transitions. Furthermore the syntax on the transition defined exactly one trigger. From a tools point of view this was very easy: Parse the text and you get the trigger. Now this obviously has changed and instead the text on a transition is supposed to reference an event defined somewhere else. So: - Where is the event defined? - How do we define the events? I must admit that I am very sceptical to this change. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 6 augusti 2004 22:22 To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Events, triggers, etc. proposal After several rounds of discussion and several months of thought (since the Anaheim meeting), we now have a comprehensive and very systematic proposal from Jim R, Thomas W. and Joaquin M. on the outstanding issue of Events and Triggers (what are they? what should they be called? how are they manifested?). All the basic principles of this proposal are summarized in the first few paragraphs of the resolution (and will also be included in the spec itself). This is followed by a longish list of detailed changes most of which have been verified against the current spec. I am posting it now so that it gets adequate soak time before ballot 23 (coming out next Friday). So, if you feel passionately about this, please review and comment. The following are the most recent comments by Thomas on the current version -- so there are likely to be changes in that area. --------------------------------------------------------------------------- After reviewing the convenience document I have the following comments... First, I think that some of your rewrites in Section "Naming pattern stuff" change the meaning enough to be either unclear or different from before. I list them in the following: 1. The specification of an invocation occurrence includes an action, which may be one of the action subclasses (see Chapter 5, .Actions.). A send request is speci­fied by a Signal (see .Signal. on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. 2. As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution environment engine to direct a reply message to the original execution. 3. [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract meta­classes that are not used in the actual metamodel.] Note that these are examples where the changes went beyond what we discussed today. I am willing to tackle these three paragraphs to bring them in line with the rest of your document. But I do think that these were not changes for the better. --------------------------------------------------------------------------- Regards, Bran To: "Anders Ek" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 9 Aug 2004 18:09:49 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/09/2004 18:09:51, Serialize complete at 08/09/2004 18:09:51 Correction to your statement, Anders: transitions can have multiple triggers, not just one (see fig. 354 in the FAS). Also, one comment: this resolution is merely a renaming exercise. Nothing has changed as far as I know. Bran To: "Anders Ek" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 9 Aug 2004 18:19:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/09/2004 18:19:54, Serialize complete at 08/09/2004 18:19:54 A more complete reply to Anders: > A question about this proposal from the statemachine point of view: > Triggers were in the existing text owned by the transitions. No they were not. Originally, they were not owned by anything (a bug). This was changed in the resolution to issue 6206 to be owned by the behaviored classifeir that uses them. The latter was probably a bad choice, since the whole idea was to allow them to be shared by many different classifiers. > Furthermore the syntax on the transition defined exactly one > trigger. I already noted that this is not the case. > From a tools point of view this was very easy: Parse the > text and you get the trigger. Now this obviously has changed and > instead the text on a transition is supposed to reference an event > defined somewhere else. I also noted that this resolution does not really change the metamodel. Specifically, the issues that you raise were there before this resolution. > So: > > - Where is the event defined? At the moment, in Behaviored Classifier. > - How do we define the events? Based on what the U2P spec said, the right quesiton to ask was "How do we define Triggers"? (One possibly but not very satisfactory answer is to say that a Trigger also implies an Event. A more likely scenario is to define triggers in the same way that Signals are declared.) Bran To: "Anders Ek" Cc: "Branislav Selic" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Mon, 9 Aug 2004 15:41:32 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/09/2004 16:41:35, Serialize complete at 08/09/2004 16:41:35 Anders, Bran answered most of this. Here is the effect on state machines: Basically, the only effect on state machines is that the Trigger will contain a reference to an Event, which may be of any Event subtype, instead of having Trigger subtypes with the same information. So it has exactly the same information at the cost of one reference. Operationally for state machines, everything else is exactly the same. But it permits other chapters to use Events without being part of a Trigger. So the change to state machines is minimal but it avoids an unnatural use of Triggers where they are not needed. So as far as where and when the events are defined, it could be the same place the triggers were defined, if you are just doing state machines. - Jim Rumbaugh "Anders Ek" 08/09/2004 03:06 PM To "Branislav Selic" , cc Subject RE: Events, triggers, etc. proposal A question about this proposal from the statemachine point of view: Triggers were in the existing text owned by the transitions. Furthermore the syntax on the transition defined exactly one trigger. From a tools point of view this was very easy: Parse the text and you get the trigger. Now this obviously has changed and instead the text on a transition is supposed to reference an event defined somewhere else. So: - Where is the event defined? - How do we define the events? I must admit that I am very sceptical to this change. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 6 augusti 2004 22:22 To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Events, triggers, etc. proposal After several rounds of discussion and several months of thought (since the Anaheim meeting), we now have a comprehensive and very systematic proposal from Jim R, Thomas W. and Joaquin M. on the outstanding issue of Events and Triggers (what are they? what should they be called? how are they manifested?). All the basic principles of this proposal are summarized in the first few paragraphs of the resolution (and will also be included in the spec itself). This is followed by a longish list of detailed changes most of which have been verified against the current spec. I am posting it now so that it gets adequate soak time before ballot 23 (coming out next Friday). So, if you feel passionately about this, please review and comment. The following are the most recent comments by Thomas on the current version -- so there are likely to be changes in that area. --------------------------------------------------------------------------- After reviewing the convenience document I have the following comments... First, I think that some of your rewrites in Section "Naming pattern stuff" change the meaning enough to be either unclear or different from before. I list them in the following: 1. The specification of an invocation occurrence includes an action, which may be one of the action subclasses (see Chapter 5, .Actions.). A send request is speci­fied by a Signal (see .Signal. on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. 2. As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution environment engine to direct a reply message to the original execution. 3. [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract meta­classes that are not used in the actual metamodel.] Note that these are examples where the changes went beyond what we discussed today. I am willing to tackle these three paragraphs to bring them in line with the rest of your document. But I do think that these were not changes for the better. --------------------------------------------------------------------------- Regards, Bran Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 09:21:26 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR+Yg+YZ1Js+TzNRUeS3etlmwNfQgARmepQ From: "Anders Ek" To: "James E Rumbaugh" , "Branislav Selic" Cc: , Weather we call something event or trigger is not too important to me but it is essentially that we must not force the user to define the events explicitly. Consider for example a simple thing like a signal trigger. This is defined by the following grammar fragment to be written on the transition: event-name-list [ .(. assignment-specification .). ] so it could be e.g. .mysig1, mysig2. This is the only thing a user should have to write to specify the trigger. In particular: We should not force a user to somehow separately specify some mysterious .mysig1, mysig2. signal event and then view the text in the trigger as a reference to this event. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 10 augusti 2004 00:42 To: Anders Ek Cc: Branislav Selic; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, Bran answered most of this. Here is the effect on state machines: Basically, the only effect on state machines is that the Trigger will contain a reference to an Event, which may be of any Event subtype, instead of having Trigger subtypes with the same information. So it has exactly the same information at the cost of one reference. Operationally for state machines, everything else is exactly the same. But it permits other chapters to use Events without being part of a Trigger. So the change to state machines is minimal but it avoids an unnatural use of Triggers where they are not needed. So as far as where and when the events are defined, it could be the same place the triggers were defined, if you are just doing state machines. - Jim Rumbaugh "Anders Ek" 08/09/2004 03:06 PM To "Branislav Selic" , cc Subject RE: Events, triggers, etc. proposal A question about this proposal from the statemachine point of view: Triggers were in the existing text owned by the transitions. Furthermore the syntax on the transition defined exactly one trigger. From a tools point of view this was very easy: Parse the text and you get the trigger. Now this obviously has changed and instead the text on a transition is supposed to reference an event defined somewhere else. So: - Where is the event defined? - How do we define the events? I must admit that I am very sceptical to this change. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 6 augusti 2004 22:22 To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Events, triggers, etc. proposal After several rounds of discussion and several months of thought (since the Anaheim meeting), we now have a comprehensive and very systematic proposal from Jim R, Thomas W. and Joaquin M. on the outstanding issue of Events and Triggers (what are they? what should they be called? how are they manifested?). All the basic principles of this proposal are summarized in the first few paragraphs of the resolution (and will also be included in the spec itself). This is followed by a longish list of detailed changes most of which have been verified against the current spec. I am posting it now so that it gets adequate soak time before ballot 23 (coming out next Friday). So, if you feel passionately about this, please review and comment. The following are the most recent comments by Thomas on the current version -- so there are likely to be changes in that area. --------------------------------------------------------------------------- After reviewing the convenience document I have the following comments... First, I think that some of your rewrites in Section "Naming pattern stuff" change the meaning enough to be either unclear or different from before. I list them in the following: 1. The specification of an invocation occurrence includes an action, which may be one of the action subclasses (see Chapter 5, .Actions.). A send request is speci­fied by a Signal (see .Signal. on page 395). A call request is associated with the operation specified by the call action that resulted in the call occurrence. 2. As shown in Figure 308, an object owns a behavior execution. The execution of an invocation action by the behavior is an invocation occurrence. The invocation occurrence creates a request object that transmits the invocation request from the sender (caller) to the receiver (target). The receipt of the request by the receiver is a receive occurrence. The receive occurrence matches a trigger the class of the target object, resulting in the execution of a behavior. The resulting behavior execution is hosted by the target object. If the invocation action is synchronous, the execution environment also includes sufficient information in the request object to identify the execution that invoked the behavior, but this information is not available for the use of the target behavior and therefore its form is not modeled. When a synchronous execution completes, this hidden information is used by the execution environment engine to direct a reply message to the original execution. 3. [Delete the remainder of the paragraph, which contradicts the metamodel by introducing abstract meta­classes that are not used in the actual metamodel.] Note that these are examples where the changes went beyond what we discussed today. I am willing to tackle these three paragraphs to bring them in line with the rest of your document. But I do think that these were not changes for the better. --------------------------------------------------------------------------- Regards, Bran To: "Anders Ek" , "Thomas Weigert" Cc: mu2i-ftf@omg.org, "James E Rumbaugh" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 08:09:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 08:09:11, Serialize complete at 08/10/2004 08:09:11 Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 15:55:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR+0uU0lcWYEn9wSFOfzX8r8djOPwADXIOg From: "Anders Ek" To: "Branislav Selic" , "Thomas Weigert" Cc: , "James E Rumbaugh" , Of course the signal needs to be defined. But the signal is not a trigger. So the special .MySig1, MySig2. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( .after( 10 ms ).) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ .(. assignment-specification .). ] > > so it could be e.g. .mysig1, mysig2. > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran To: "Anders Ek" Cc: mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 10:23:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 10:23:44, Serialize complete at 08/10/2004 10:23:44 Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special ā..MySig1, MySig2ā.. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( ā..after( 10 ms )ā.¯) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 17:03:32 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR+5a4oH/0Bg7VDTVS6Ope8ah3v1QAAMjbA From: "Anders Ek" To: "Branislav Selic" Cc: , "James E Rumbaugh" , "Thomas Weigert" , It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special .MySig1, MySig2. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( .after( 10 ms ).) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ .(. assignment-specification .). ] > > so it could be e.g. .mysig1, mysig2. > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran To: "Anders Ek" Cc: mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 11:34:15 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 11:34:18, Serialize complete at 08/10/2004 11:34:18 There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special ā..MySig1, MySig2ā.. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( ā..after( 10 ms )ā.¯) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran Date: Tue, 10 Aug 2004 16:50:09 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Anders Ek CC: Branislav Selic , mu2i-ftf@omg.org, James E Rumbaugh , Thomas Weigert , uml2-superstructure-ftf@omg.org Subject: Re: Events, triggers, etc. proposal Anders, > if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. The Event would be (transitively) owned by the transition which would not allow it to be shared between different behavioral specifications or between classes. The trigger can be owned by the Transition (as Bran points out in the FAS there was no owner), but not the Event. Agreed with Bran that tools can create Event definitions implicitly, if desired. Thanks, Guus Anders Ek wrote: It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special .MySig1, MySig2. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( .after( 10 ms ).) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ .(. assignment-specification .). ] > > so it could be e.g. .mysig1, mysig2. > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 To: Branislav Selic Cc: "Anders Ek" , mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 12:21:03 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 12:21:08, Serialize complete at 08/10/2004 12:21:08 It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special ā..MySig1, MySig2ā.. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( ā..after( 10 ms )ā.¯) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran From: "Eran Gery" To: "'Branislav Selic'" Cc: "'Anders Ek'" , , "'James E Rumbaugh'" , "'Thomas Weigert'" , Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 20:46:07 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Bran The proposal you sent out says "Event stuff . This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special ā..MySig1, MySig2ā.. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( ā..after( 10 ms )ā.¯) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran To: Branislav Selic Cc: "Anders Ek" , Branislav Selic , mu2i-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 10 Aug 2004 10:56:22 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/10/2004 11:56:24, Serialize complete at 08/10/2004 11:56:24 I retained Trigger because I wanted to make a minimal change to the state machine chapter. I presumed it was part of the structure of transitions. If it isn't needed, then we could get rid of it, but I would expect guidance from the state machine people on that. Better to do that as a separate cleanup. I don't understand Anders's worries. The information is the same as before, just repackaged slightly. Hopefully it is not a concern about one additional object in the repository. If that is the case, then most of UML has the same problem: To declare a Class, you have to declare Operations as separate objects, which contain Parameters as separate objects, which contain types as separate objects, etc. Anders, it really isn't any different than before for state machines! Any tool can hide the minor difference. To model a Trigger, you do almost exactly the same thing as before. As Bran observes, if you use Signals (the most common kind of event), you always needed to declare them separately. If you use time events, then the information is exactly the same as before, except it is placed in an instance of a TimeEvent object which is referenced from an instance of a Trigger object. Not a fundamental change. But a number of people wanted to be able to model Events separately without using them in Triggers. That was the motivation for the proposal. - Jim Rumbaugh Branislav Selic 08/10/2004 09:21 AM To Branislav Selic cc "Anders Ek" , mu2i-ftf@omg.org, James E Rumbaugh/Cupertino/IBM@IBMUS, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special .MySig1, MySig2. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( .after( 10 ms ).) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ .(. assignment-specification .). ] > > so it could be e.g. .mysig1, mysig2. > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran To: "Eran Gery" Cc: "'Anders Ek'" , "'Branislav Selic'" , mu2i-ftf@omg.org, "'Thomas Weigert'" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 10 Aug 2004 11:08:14 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/10/2004 12:08:18, Serialize complete at 08/10/2004 12:08:18 Eran, I think Bran may have said it in a confusing way. The proposal does the following: 1. Defines a new Event class. 2. Retains the Trigger class, makes it concrete, and gives it a reference to an Event instance with rolename "event". 3. Takes the subclasses of Trigger (SignalTrigger, TimeTrigger, ChangeTrigger, CallTrigger) and makes them subclasses of Event (SignalEvent, TimeEvent, ChangeEvent, CallEvent). They have the same attributes and associations they had as subclasses of Trigger. So instead of having for example aTrigger = SignalTrigger(signal=someSignal), you would have aTrigger = Trigger(event=anEvent), anEvent = SignalEvent(signal=someSignal). Yes, there's an extra indirection, but that's no difference from a million other places in UML where we express structure with objects. - Jim Rumbaugh "Eran Gery" 08/10/2004 10:46 AM To "'Branislav Selic'" cc "'Anders Ek'" , , James E Rumbaugh/Cupertino/IBM@IBMUS, "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal Bran The proposal you sent out says "Event stuff . This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special .MySig1, MySig2. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( .after( 10 ms ).) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ .(. assignment-specification .). ] > > so it could be e.g. .mysig1, mysig2. > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran From: "Eran Gery" To: "'James E Rumbaugh'" Cc: "'Anders Ek'" , "'Branislav Selic'" , , "'Thomas Weigert'" , Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 21:25:34 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) OK - but there was a document with the proposal that said differently and needs to be updated. I agree having the extra metaclass is no big deal in that case, but I would also support removing it. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, August 10, 2004 9:08 PM To: Eran Gery Cc: 'Anders Ek'; 'Branislav Selic'; mu2i-ftf@omg.org; 'Thomas Weigert'; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Eran, I think Bran may have said it in a confusing way. The proposal does the following: 1. Defines a new Event class. 2. Retains the Trigger class, makes it concrete, and gives it a reference to an Event instance with rolename "event". 3. Takes the subclasses of Trigger (SignalTrigger, TimeTrigger, ChangeTrigger, CallTrigger) and makes them subclasses of Event (SignalEvent, TimeEvent, ChangeEvent, CallEvent). They have the same attributes and associations they had as subclasses of Trigger. So instead of having for example aTrigger = SignalTrigger(signal=someSignal), you would have aTrigger = Trigger(event=anEvent), anEvent = SignalEvent(signal=someSignal). Yes, there's an extra indirection, but that's no difference from a million other places in UML where we express structure with objects. - Jim Rumbaugh "Eran Gery" 08/10/2004 10:46 AM To "'Branislav Selic'" cc "'Anders Ek'" , , James E Rumbaugh/Cupertino/IBM@IBMUS, "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal Bran The proposal you sent out says "Event stuff - This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special 'MySig1, MySig2' trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( "after( 10 ms )") and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ '(' assignment-specification ')' ] > > so it could be e.g. "mysig1, mysig2" > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran To: "Eran Gery" Cc: "'Anders Ek'" , mu2i-ftf@omg.org, "'James E Rumbaugh'" , "'Thomas Weigert'" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 14:46:18 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 14:46:25, Serialize complete at 08/10/2004 14:46:25 For the time being, it is what Jim R has posted. However, Jim did not actually suggest removing the Trigger class. Although he replaces the current Trigger class by Event, in his proposal there is still a Trigger class but with a different meaning than before. I think he should modify his proposal to get rid of Trigger -- it's a minor change. Bran "Eran Gery" 08/10/2004 01:46 PM To Branislav Selic/Ottawa/IBM@IBMCA cc "'Anders Ek'" , , "'James E Rumbaugh'" , "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal Bran The proposal you sent out says "Event stuff . This replaces the Trigger subclasses wiith Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special ā..MySig1, MySig2ā.. trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( ā..after( 10 ms )ā.¯) and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ ā..(ā.. assignment-specification ā..)ā.. ] > > so it could be e.g. ā..mysig1, mysig2ā.¯ > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran : "Eran Gery" Cc: "'Anders Ek'" , mu2i-ftf@omg.org, "'James E Rumbaugh'" , "'Thomas Weigert'" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 14:51:25 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 14:51:28, Serialize complete at 08/10/2004 14:51:28 Well, Jim, you have it from the state machine WG -- let's remove Trigger and let's do it in this resolution (it's only a couple of extra lines). I don't think that Anders will object, but we should wait for him to respond tomorrow. Bran User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 10 Aug 2004 15:21:33 -0400 Subject: Re: Events, triggers, etc. proposal From: James Odell To: CC: Please, not so fast. Eran indicated that it .is no big deal..as well as supporting its removal. So, there was nothing conclusive to remove Trigger, as I understand it. An event can trigger multiple processes. If Trigger is removed, it seems that we will also lose the link between something that occurs to those things that need to be invoked: i.e., the link between cause and effect. Am afraid removing trigger will dumb-down UML too much . particularly for those of us that need to model such things. I strongly support letting Jim.s resolution stand as it is. -Jim O On 8/10/04 2:51 PM, "Branislav Selic" indited: Well, Jim, you have it from the state machine WG -- let's remove Trigger and let's do it in this resolution (it's only a couple of extra lines). I don't think that Anders will object, but we should wait for him to respond tomorrow. Bran User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 10 Aug 2004 15:42:39 -0400 Subject: Re: Events, triggers, etc. proposal From: James Odell To: CC: Since this is an important issue to me, I would like to add a bit more to my previous email in the topic. Events . something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have not behavior, and need no ports. Triggers . a link between an event and something that cares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Does that make sense? -Jim O X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 15:58:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 15:58:09, Serialize complete at 08/10/2004 15:58:09 Jim, I'm not sure that I understand your objection. Trigger is still a concept that is linked to the behavior that it triggers. It just happens to be defined as an association end rather than a metaclass. I don't see that anything is lost. An event is a definition such as: "Signal X has been received". If I want to trigger a set of transitions by an occurrence of this event, all I have to do is have each of those transitions include a reference to the "Signal X has been received" event. This is how the old model worked as well except that the thing I call "event" in the previous pargraph was called "trigger". So, nothing is lost. What Anders is objecting to is that, in addition to having to define "Signal X has been received", I also have to define "Signal X has been received trigger" (which has to reference the event) as well. Then i have to have the transition referencing the latter instead of the former. If you think about it, there really is no need to define that thing in the middle. Bran To: James Odell Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 16:04:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 16:04:12, Serialize complete at 08/10/2004 16:04:12 I see your point. However, the port on which a trigger occurs could be another reference on the transition. (But, that would cause problems when you have mutliple triggers associated with different ports.) I think you are right. We may not be able to get rid of Trigger -- which gets us back to Anders' dilemma. Bran James Odell 08/10/2004 03:42 PM To cc Subject Re: Events, triggers, etc. proposal Since this is an important issue to me, I would like to add a bit more to my previous email in the topic. Events . something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have not behavior, and need no ports. Triggers . a link between an event and something that caares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Does that make sense? -Jim O To: Branislav Selic Cc: James Odell , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 10 Aug 2004 13:13:36 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/10/2004 14:13:39, Serialize complete at 08/10/2004 14:13:39 One complication I see is that Trigger has an attribute "port: Port[*]" that specifies the ports on which a communication event arrived. You don't want to put that information on Event; an event is something that happers, regardless of which path it takes. I don't think you want to say that "order received" on port 2 is a different event from the same thing on port 1. Since Trigger represents the recognition of an event (rather than the event itself), it seems like an appropriate place for things such as the port, which is why I presume it was added in the UML2 process. I could also forsee similar kind of information being attached to a trigger in a profile, so it might be useful to have it separate. So is there any better place to attach information such as the port? I imagine the idea behind Trigger was to avoid having to stick it in Transition and similar places. The cost of adding a separate object is miniscule and can be automated, so I don't think we should focus on that. - Jim Rumbaugh Branislav Selic 08/10/2004 12:58 PM To James Odell cc mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject Re: Events, triggers, etc. proposal Jim, I'm not sure that I understand your objection. Trigger is still a concept that is linked to the behavior that it triggers. It just happens to be defined as an association end rather than a metaclass. I don't see that anything is lost. An event is a definition such as: "Signal X has been received". If I want to trigger a set of transitions by an occurrence of this event, all I have to do is have each of those transitions include a reference to the "Signal X has been received" event. This is how the old model worked as well except that the thing I call "event" in the previous pargraph was called "trigger". So, nothing is lost. What Anders is objecting to is that, in addition to having to define "Signal X has been received", I also have to define "Signal X has been received trigger" (which has to reference the event) as well. Then i have to have the transition referencing the latter instead of the former. If you think about it, there really is no need to define that thing in the middle. Bran James Odell 08/10/2004 03:21 PM To cc Subject Re: Events, triggers, etc. proposal Please, not so fast. Eran indicated that it .is no big deal..as well as supporting its removal. So, there was nothing conclusive to remove Trigger, as I understand it. An event can trigger multiple processes. If Trigger is removed, it seems that we will also lose the link between something that occurs to those things that need to be invoked: i.e., the link between cause and effect. Am afraid removing trigger will dumb-down UML too much . particularly for those of us that need to model such things. I strongly support letting Jim.s resolution stand as it is. -Jim O To: Branislav Selic Cc: James Odell , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 10 Aug 2004 13:19:50 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/10/2004 14:19:53, Serialize complete at 08/10/2004 14:19:53 What dilemma? This is making a mountain out of a molehill. Your tool does it for you. No difference from before. If you don't have a tool, nobody is going to be able to get all the pieces of a UML model together at the repository level. We never worried about this anywhere else in UML. There is absolutely no change in the workflow for the state machine user. Branislav Selic 08/10/2004 01:04 PM To James Odell cc mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject Re: Events, triggers, etc. proposal I see your point. However, the port on which a trigger occurs could be another reference on the transition. (But, that would cause problems when you have mutliple triggers associated with different ports.) I think you are right. We may not be able to get rid of Trigger -- which gets us back to Anders' dilemma. Bran James Odell 08/10/2004 03:42 PM To cc Subject Re: Events, triggers, etc. proposal Since this is an important issue to me, I would like to add a bit more to my previous email in the topic. Events . something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have not behavior, and need no ports. Triggers . a link between an event and something that cares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Does that make sense? -Jim O Reply-To: From: "Conrad Bock" To: , Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 16:48:32 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7AL0Nlj006504 Bran, > There is some misunderstanding here, Anders. Triggers are NOT > defined elsewhere. You don't have to define them separately. The > resolution eliminates Trigger as a metaclass, and trigger > reverts to an association end from Transition to Event. That's how it was in UML 1.5, so it can't be just a renaming exercise. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 16:57:04 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > The cost of adding a separate object is miniscule and can be > automated, so I don't think we should focus on that. I agree with the two Jim's here. There is a semantic distinction, and it shows up in the metamodel, so let's keep it that way. Disk is cheap, semantic mismatch isn't. Conrad Subject: RE: Events, triggers, etc. proposal Date: Tue, 10 Aug 2004 15:28:45 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR/Hs2dNH4NLqyFRSKb3SN/vlpa9gAAXP0Q From: "Pidcock, Woody" To: "James Odell" , Cc: X-OriginalArrivalTime: 10 Aug 2004 22:28:46.0564 (UTC) FILETIME=[66A43240:01C47F29] I too see a distinction between Event and Trigger. I also support Jim Rumbaugh's explanation of how both would be used. The extra layer of indirection is needed for interoperability. I am not conversant with the current vocabulary in UML 2.0. Here is a plain English example of the distinction I make between Event and Trigger, using an e-mail from Jim Odell as a reference point: A "noteworthy" change in state is noteworthy because some business logic uses this state variable in calculating a condition, which evaluates to false before the event and evaluates to true after the event. When this condition changes from false to true (my definition of a noteworthy change in state), it triggers additional processing to occur. For example, a withdrawal from my bank account is an event. The state of my bank balance goes down. For me, this occurs many times a week. A separate event, automatic deposit of my paycheck, occurs once every two weeks. The state of my bank balance goes up. These changes of state aren't noteworthy to me unless the withdrawal event changes the condition on my bank balance from overdrawn = false to overdrawn = true. When this occurs, I expect to be notified, and I need to do some additional processing :-). So, if a process (e.g., me) requests notification of the occurence of an event, it is not for a simple change in state event, it is for those noteworthy events (e.g., bank balance = overdrawn) when business logic evaluates a condition of importance to the process to be true that was previously false. The notification, I would say this is the same as a trigger, is a result of the change of state on the condition specified by the process, not the specific event (e.g., bank withdrawal). Each process defines its own conditions separate from the events that occur. Triggers are process dependent, whereas events are not. Bottom line: I think we need both Event and Trigger. -Woody -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: Tuesday, August 10, 2004 12:22 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Re: Events, triggers, etc. proposal Please, not so fast. Eran indicated that it .is no big deal..as well as supporting its removal. So, there was nothing conclusive to remove Trigger, as I understand it. An event can trigger multiple processes. If Trigger is removed, it seems that we will also lose the link between something that occurs to those things that need to be invoked: i.e., the link between cause and effect. Am afraid removing trigger will dumb-down UML too much . particularly for those of us that need to model such things. I strongly support letting Jim.s resolution stand as it is. -Jim O On 8/10/04 2:51 PM, "Branislav Selic" indited: Well, Jim, you have it from the state machine WG -- let's remove Trigger and let's do it in this resolution (it's only a couple of extra lines). I don't think that Anders will object, but we should wait for him to respond tomorrow. Bran "Eran Gery" 08/10/2004 02:25 PM To "'James E Rumbaugh'" cc "'Anders Ek'" , Branislav Selic/Ottawa/IBM@IBMCA, , "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal OK - but there was a document with the proposal that said differently and needs to be updated. I agree having the extra metaclass is no big deal in that case, but I would also support removing it. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, August 10, 2004 9:08 PM To: Eran Gery Cc: 'Anders Ek'; 'Branislav Selic'; mu2i-ftf@omg.org; 'Thomas Weigert'; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Eran, I think Bran may have said it in a confusing way. The proposal does the following: 1. Defines a new Event class. 2. Retains the Trigger class, makes it concrete, and gives it a reference to an Event instance with rolename "event". 3. Takes the subclasses of Trigger (SignalTrigger, TimeTrigger, ChangeTrigger, CallTrigger) and makes them subclasses of Event (SignalEvent, TimeEvent, ChangeEvent, CallEvent). They have the same attributes and associations they had as subclasses of Trigger. So instead of having for example aTrigger = SignalTrigger(signal=someSignal), you would have aTrigger = Trigger(event=anEvent), anEvent = SignalEvent(signal=someSignal). Yes, there's an extra indirection, but that's no difference from a million other places in UML where we express structure with objects. - Jim Rumbaugh "Eran Gery" 08/10/2004 10:46 AM To "'Branislav Selic'" cc "'Anders Ek'" , , James E Rumbaugh/Cupertino/IBM@IBMUS, "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal Bran The proposal you sent out says "Event stuff - This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special 'MySig1, MySig2' trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( "after( 10 ms )") and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ '(' assignment-specification ')' ] > > so it could be e.g. "mysig1, mysig2" > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran Date: Wed, 11 Aug 2004 11:25:34 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: James Odell CC: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: Re: Events, triggers, etc. proposal Jim, Certainly. However, both models discussed allow you to do this. Events - define the Event in terms of name and properties Trigger - link the Event to a Transition (in SM). This can be done by having a meta class Trgger or by having a direct meta association from Transition to Event with teh role name "trigger". In both approaches the Event can be used to trigger multiple things. Note that Jim R's mail indicates that there is a property (port type) on trigger, and that profiles may want to stereotype triggers. To support that, a meta class Trigger should be used. (which takes us back to your original position ;-) Thanks, Guus James Odell wrote: Since this is an important issue to me, I would like to add a bit more to my previous email in the topic. Events . something that occurs. Occurrences are basically points in time when there was some noteworthy change in state. They have not behavior, and need no ports. Triggers . a link between an event and something that cares when a particular kind of event occurs. Here, a port would be useful because it provides an interaction point. Events do not have interaction points, but the notification of event occurrence needs one. Does that make sense? -Jim O -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: RE: Events, triggers, etc. proposal Date: Wed, 11 Aug 2004 12:32:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR/CxS1n4gyU/DLQvWfvNbYIKhT9wAgzUVg From: "Anders Ek" To: "Branislav Selic" , "Eran Gery" Cc: , "James E Rumbaugh" , "Thomas Weigert" , Removing the extra trigger class is a step in the right direction. By removing this class the proposal is more or less only a name change so it is better than before. /Anders Subject: RE: Events, triggers, etc. proposal Date: Wed, 11 Aug 2004 12:41:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR/A2wR6g2/ke57Tzm2nOR4U1qbQgAixDNA From: "Anders Ek" To: "James E Rumbaugh" , "Branislav Selic" Cc: , What worries me here is that a lot of people seem to think a Signal is an Event (where Event == Trigger). It is not and that is the way it should be. But I.m afraid that this is a misconception that will cause a lot of problems. A Trigger is a special condition that describes when a transition is fired. It is a requirement on a runtime .event.. For example a Trigger can be described by a list of Signals. This means that the transition is fired when a signal instance of one the corresponding signal types is consumed. Now we.ve renamed Trigger to Event. So now an Event is a condition describing a requirement on a run-time .event. and can for example be a list of Signals. But a Signal is not in itself an Event. I know that this confusion was what made us change the name to Trigger in the first place. /Anders From: "Thomas Weigert" To: "Anders Ek" , "Branislav Selic" , "Eran Gery" Cc: , "James E Rumbaugh" , Subject: RE: Events, triggers, etc. proposal Date: Wed, 11 Aug 2004 17:18:44 +0530 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Not quite. Trigger, as proposed by Jim R., is a ternary relationship between a transition, an event, and possibly a port. You cannot remove it as you then have no way of saying that this transition is triggered by a certain event arriving at a given port. Note that the event may be reusable by other triggers. The event is the specification of some occurrence in the world, e.g., a signal being received. In the case of signal, as you describe below, the event would basically just reference the signal. Th. Subject: RE: Events, triggers, etc. proposal Date: Wed, 11 Aug 2004 16:06:53 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR/mddAkt57vKGUQTesKn630AmrQgAEEnTQ From: "Anders Ek" To: "Thomas Weigert" , "Branislav Selic" , "Eran Gery" Cc: , "James E Rumbaugh" , You are right, with the proposal as it stands we either need to add the port to the Event or keep the Trigger. About reusing events: No user will ever know if he reused an event or created a new one. There is no visible difference. I must admit that I don.t understand why we try to add events to the modelling constructs in UML. We will have no syntax for them. Users will never see them. It will be a construct not intended for the users of UML. So who is it intended for? Furthermore the only real problem in the current model (the ownership of the triggers) still remains. Why don.t we stick to the model as it was? /Anders Date: Wed, 11 Aug 2004 15:25:36 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Anders Ek CC: Thomas Weigert , Branislav Selic , Eran Gery , mu2i-ftf@omg.org, James E Rumbaugh , uml2-superstructure-ftf@omg.org Subject: Re: Events, triggers, etc. proposal Anders, There have been extensive discussions around enabling the user to define an Event once, and then reuse it in different places. UML 1.x enabled this, but we lost the capability in UML 2.0. Jim's proposal fixes this. As for notation, I'm not hung up but UML 1.x used a classifier symbol (with attributes to define the payload) - that would work for 2.0 as well. Thanks, guus To: "Anders Ek" Cc: "Eran Gery" , mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 11 Aug 2004 10:27:27 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/11/2004 10:27:33, Serialize complete at 08/11/2004 10:27:33 Anders, The discussion on whether we need events took place at the Anaheim meeting. I can't recall the number of people who asked for the concept of an event, but it was not a small number. The conclusion of the meeting was that enough people felt that it was useful that it was worthwhile for Jim R was to propose a resolution. We are looking at that resolution now. So, the FTF have a difference of opinion on this issue and, given the time available, I doubt that we will be able to reach consensus. This is why there is a voting process as a way of resolving such dilemmas. Regards Bran To: "Anders Ek" Cc: "Branislav Selic" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 11 Aug 2004 10:34:50 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/11/2004 11:43:54, Serialize complete at 08/11/2004 11:43:54 Anders, The distinctions are not mysterious, but they require modelers to distinguish things that are often lumped together in ordinary speech. Some people are unable to do this; they will never be good modelers. But many people feel that the distinctions are important. Signal = a data type that may be used as a message (It is important to get away from the mistake that it IS the message. In fact, we didn't even need to keep Signal in UML2; Class would have been enough, but it allows people to indicate data types that will be used for messages.) Message = the transmission of a signal from one object to another. It might contain hidden implementation information. In fact, the specification does say that it contains opaque return information for synchronous calls. Note, however, that this metaclass never appears in models, because a modeler cannot access a message in transmission. You can send a signal and receive a signal, so although we can use this concept to talk about what UML "means", it doesn't appear in the metamodel. Event = the recognition of something that happens at a point in time and space (space being taken in a broad sense). In particular, the receipt of a message by an object, or perhaps more precisely, the handling of a previously received message by an object is one kind of event, and probably the most valuable for state machine transitions. The recognition of the change in a Boolean expression is another kind of event. (Note that UML is properly vague on the timing delays that might occur between a change in value at one location and its recognition as an event at another location.) Recognition of state changes does not involve messages. There are other kinds of events, such as time events and the receipt of calls. Note that a message itself is not an event, as it transcends an interval of time; its receipt or its sending can be an event. Trigger = the (implicit) association between an event and specification of an effect (such as a change of state or the execution of a procedure) on an object. An event just "happens". A trigger associates the happening with a behavior. The trigger can include conditions on the recognition of the event, such as the port that a message was received on. I could forsee broadening trigger conditions, for example, by specifying a time period during which it is effective. This is not in UML now, but it is a concept that might be added in the future. (It's hardly a far-out concept--it exists in some databases today.) So one reason for distinguishing Event and Trigger is to permit this kind of distinction in the future. You are correct that we could eliminate the distinction between event and trigger and save a metaclass. This kind of minimalist thinking has already caused a lot of confusion with UML2. I think it is important to make semantic distinctions when they appear important to people. You may not think this distinction is important, but a lot of other people do, so I would ask you to back off and accept it as something that may be a minor nuisance to you, but which others feel strongly about. Our goal should not be to minimize the number of UML metaclasses. If storage is a problem, the UML2 metamodel is already hopelessly inefficient, so that can't be our goal, and we shoud not get hung up on it in this case. - Jim Rumbaugh "Anders Ek" To: "Guus Ramackers" Cc: "Thomas Weigert" , "Branislav Selic" , "Eran Gery" , , "James E Rumbaugh" , Guus, I.m afraid we.re confusing signal definitions and the corresponding events again. I just looked up UML 1.5. A Signal is a classifier and is indeed defined using the classifier notation. BUT IT IS NOT AN EVENT. The only notation for a signal event was the notation used in transitions in state machines. Cmp section 3.77 (for notation) and 2.12.2 (for the metamodel) in UML 1.5 /Anders PS! But I do agree that the 3.77 section is confusing. The entire example in the section deals with signals and not with events. So it is a bit strange. Subject: RE: Events, triggers, etc. proposal Date: Thu, 12 Aug 2004 11:48:03 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Events, triggers, etc. proposal Thread-Index: AcR/ytGu/NapCr6fShu9rM4ekvGovQAfcePg From: "Anders Ek" To: "James E Rumbaugh" Cc: "Branislav Selic" , , I have no problem with the distinction. But it comes back all the time. Even Guus who knows UML very well made this mistake in a recent email to the list where he mistakenly assumed that we have a notation for events to be reused. Maybe you can enlighten me to why we.re trying to do this at all? I was not in the Anaheim meeting so I missed the discussion. /Anders To: "Anders Ek" , Joaquin Miller Cc: mu2i-ftf@omg.org, "James E Rumbaugh" , uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 09:50:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 09:50:46 Anders, > Maybe you can enlighten me to why weā..re trying to do this at all? I > was not in the Anaheim meeting so I missed the discussion. The strongest proponent of the separation of Events and Triggers, from what I recall, was Joaquin. So, it is probably best if he were to volunteer teh explanation. For what it's worth, I am attaching the minutes of the various meetings where the issue was discussed and where the appearance at least of a consensus emerged. Joaquin, can you please help Anders out? Regards, Bran TeleconMinutes.0401141.bvs.doc Minutes.Anaheim.Super.0402031.doc TeleconMinutes.0401211.bvs.doc From: "Eran Gery" To: "'Thomas Weigert'" , "'Anders Ek'" , "'Branislav Selic'" Cc: , "'James E Rumbaugh'" , Subject: RE: Events, triggers, etc. proposal Date: Fri, 13 Aug 2004 12:49:34 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Good point - this shall be fixed by adding the port to the signal event definition. Basically arrival of a signal to a port is a noteworthy event - it is not specific only to statemachine triggering. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 11, 2004 2:49 PM To: Anders Ek; Branislav Selic; Eran Gery Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Not quite. Trigger, as proposed by Jim R., is a ternary relationship between a transition, an event, and possibly a port. You cannot remove it as you then have no way of saying that this transition is triggered by a certain event arriving at a given port. Note that the event may be reusable by other triggers. The event is the specification of some occurrence in the world, e.g., a signal being received. In the case of signal, as you describe below, the event would basically just reference the signal. Th. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Wednesday, August 11, 2004 4:02 PM To: Branislav Selic; Eran Gery Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Removing the extra trigger class is a step in the right direction. By removing this class the proposal is more or less only a name change so it is better than before. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 20:51 To: Eran Gery Cc: Anders Ek; mu2i-ftf@omg.org; 'James E Rumbaugh'; 'Thomas Weigert'; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Well, Jim, you have it from the state machine WG -- let's remove Trigger and let's do it in this resolution (it's only a couple of extra lines). I don't think that Anders will object, but we should wait for him to respond tomorrow. Bran "Eran Gery" 08/10/2004 02:25 PM To "'James E Rumbaugh'" cc "'Anders Ek'" , Branislav Selic/Ottawa/IBM@IBMCA, , "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal OK - but there was a document with the proposal that said differently and needs to be updated. I agree having the extra metaclass is no big deal in that case, but I would also support removing it. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, August 10, 2004 9:08 PM To: Eran Gery Cc: 'Anders Ek'; 'Branislav Selic'; mu2i-ftf@omg.org; 'Thomas Weigert'; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Eran, I think Bran may have said it in a confusing way. The proposal does the following: 1. Defines a new Event class. 2. Retains the Trigger class, makes it concrete, and gives it a reference to an Event instance with rolename "event". 3. Takes the subclasses of Trigger (SignalTrigger, TimeTrigger, ChangeTrigger, CallTrigger) and makes them subclasses of Event (SignalEvent, TimeEvent, ChangeEvent, CallEvent). They have the same attributes and associations they had as subclasses of Trigger. So instead of having for example aTrigger = SignalTrigger(signal=someSignal), you would have aTrigger = Trigger(event=anEvent), anEvent = SignalEvent(signal=someSignal). Yes, there's an extra indirection, but that's no difference from a million other places in UML where we express structure with objects. - Jim Rumbaugh "Eran Gery" 08/10/2004 10:46 AM To "'Branislav Selic'" cc "'Anders Ek'" , , James E Rumbaugh/Cupertino/IBM@IBMUS, "'Thomas Weigert'" , Subject RE: Events, triggers, etc. proposal Bran The proposal you sent out says "Event stuff - This replaces the Trigger subclasses with Event subclasses (as in UML1) and makes necessary changes in wording" So what is the proposal now ? I agree that trigger needs to be a rolename as all it does is associating the transition with an event. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 10, 2004 7:21 PM To: Branislav Selic Cc: Anders Ek; mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal It turns out that the misunderstanding is mine, not Anders' (apologies). Jim's proposal still retains Trigger -- but I don't see why. It is no longer necessary, since nothing is obtained by reusing Trigger specifications. They can be simply pointers to events. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/10/2004 11:34 AM To "Anders Ek" cc mu2i-ftf@omg.org, "James E Rumbaugh" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject RE: Events, triggers, etc. proposal There is some misunderstanding here, Anders. Triggers are NOT defined elsewhere. You don't have to define them separately. The resolution eliminates Trigger as a metaclass, and trigger reverts to an association end from Transition to Event. Bran "Anders Ek" 08/10/2004 11:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "James E Rumbaugh" , "Thomas Weigert" , Subject RE: Events, triggers, etc. proposal It is true that a similar situation was already a problem in the u2p submission. It would have been better if the triggers that had been composite parts of the transitions. However now we will duplicate the problem: We have transitions that reference triggers (defined elsewhere) that will reference events (defined elsewhere) that in case of signal triggers/events will reference signals (defined elsewhere). And the only think visible to the user will be the text on the transition and the signal definition. This is not a good solution. What could make this acceptable would be if it would be allowed to have a composition hierarchy where the transitions contained the triggers that contained the events. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 16:24 To: Anders Ek Cc: mu2i-ftf@omg.org; James E Rumbaugh; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Agreed, but it seems to me that a tool should be abe to do this nicely. When you write "MySig1, MySig2" on the transition then the tool should be able to declare a pair of SignalEvents for that case. It should probably declare them in the same namespaces that contain the definitions of the signals MySig1 and MySig2. Again, I would like to note that this "extra" step is not something that was introduced by this resolution. The need to do it this way has been around since the U2P submission, where the notion of "Trigger" was, in effect, what the resolution now calls "Event". (BTW, when the resolution to 6206 was introduced, it actually corrupted the meaning of Trigger as a kind of event type by attaching it to a behaviored classifier. This only makes sense for triggers, not for events. This unintended error was caused by the confusion between the concepts of triggers and events. By separating them, we should avoid this type of error in the future.) Bran "Anders Ek" 08/10/2004 09:55 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "James E Rumbaugh" , Subject RE: Events, triggers, etc. proposal Of course the signal needs to be defined. But the signal is not a trigger. So the special 'MySig1, MySig2' trigger (or event if you prefer that term) should not need to be separately defined. It should be enough to define this in the transition. This also applies to the other triggers: It does for example not make sense to force a user first to define a TimeEvent / TimeTrigger somewhere ( "after( 10 ms )") and then reference this definition from a transition. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 10 augusti 2004 14:09 To: Anders Ek; Thomas Weigert Cc: mu2i-ftf@omg.org; James E Rumbaugh; uml2-superstructure-ftf@omg.org Subject: RE: Events, triggers, etc. proposal Anders, > Weather we call something event or trigger is not too important to > me but it is essentially that we must not force the user to define > the events explicitly. To a certain extent, this is a toolset option. You may choose to have your tool do the declaration implicitly when you define a transition. However, there are some issues here that need to be studied... > Consider for example a simple thing like a signal trigger. This is > defined by the following grammar fragment to be written on the transition: > > event-name-list [ '(' assignment-specification ')' ] > > so it could be e.g. "mysig1, mysig2" > > This is the only thing a user should have to write to specify the trigger. But, the signal itself has to be sent by someone and, unless the signal is sent by the class to itself, it has to be sent by someone else who must have access to that signal (which, BTW, is why it seems wrong to have "Event"/"Trigger" owned by a BehavioredClassifier as was done in the resolution to issue 6206). So, by definition, since a signal is used to communicate between things, it is something that has to be shared by those things. This seems to imply that signals need to be declared in some shared namespace -- usually a package. Consequently, I fail to see how you can avoid having to declare a signal somewhere else, in addition to pointing to it in your trigger specification. Cheers...Bran From: "Thomas Weigert" To: "Eran Gery" , "'Anders Ek'" , "'Branislav Selic'" Cc: , "'James E Rumbaugh'" , Subject: RE: Events, triggers, etc. proposal Date: Fri, 13 Aug 2004 05:11:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) But it is not part of a event that is defined outside of a classifier. How can an event defined at a package level know about the port? That is something that has to be inside the classifier. I think the correct solution is as Jim R. had it. Trigger is not part of the state machine and it is not outside of the classifier. Th. -----Original Message----- From: "Eran Gery" To: "'Thomas Weigert'" , "'Anders Ek'" , "'Branislav Selic'" Cc: , "'James E Rumbaugh'" , Subject: RE: Events, triggers, etc. proposal Date: Fri, 13 Aug 2004 13:45:23 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Do we have a constraint for events to be defined only at package level (not within a class?) To me a signal arriving at a port is an event, like a time event based on entering a state of some statemachine. They are all occurences of things. It would be a cleaner model to allow event specification to express this. However, I can live with Jim's proposal as is for pragmatic reasons of running out of time... Eran From: "Thomas Weigert" To: "Eran Gery" , "'Anders Ek'" , "'Branislav Selic'" Cc: , "'James E Rumbaugh'" , Subject: RE: Events, triggers, etc. proposal Date: Fri, 13 Aug 2004 05:46:06 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Now, we don't have this constraint. But there were many requests to have events be a packagable element, so often we find that an event should be reusable. You want the same event to be reused by different behaviored classifiers, but limited to different ports at times. Th. -----Original Message----- From: "Thomas Weigert" To: "James E Rumbaugh" Cc: , "Branislav Selic" , "Joaquin Miller" Subject: RE: Errata and comments on 6682 resolution Date: Tue, 10 Aug 2004 22:38:19 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Please find attached suggested wording modifications for issue 6682. These apply to the section "communications" in the common behavior chapter. Th. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Friday, August 06, 2004 3:41 PM To: Thomas Weigert Cc: Branislav Selic; Joaquin Miller Subject: RE: Errata and comments on 6682 resolution Thomas, Certainly, write it up as you think it should be said, now that you know what I was trying to clarify in the original. I am sure that it can be stated even more clearly. At this point, you should post your changes to the whole FTF mailing list. Others on the FTF may have suggestions, although at this point I suspect everyone is worn down so the people on this mailing list are probably the only ones left standing on this issue. commonbehavior-communications.doc Insert after Figure 309 in section .Communications. and replace to end of paragraph: Invocation event occurrences are the result of the execution of invocation actions (see .InvocationAction. on page 236). A send request is specified by a Signal (see .Signal. on page 395). A call request is specified by the Operation associated with the call action that resulted in the call occurrence. Signal event occurrences and call event occurrences are specified by the corresponding metaclasses (see .SignalEvent. on page 396 and .CallEvent. on page 385). As shown in Figure 308, an object hosts a behavior execution (i.e., a behavior will be executed in the context of that object). The execution of an invocation action by the behavior constitutes an invocation occurrence. The invocation occurrence results in a request object that transmits the invocation request from the sender object (caller) to the receiver object (target). The receipt of the request by the receiver is manifest as a receive occurrence. When the receive occurrence matches a trigger defined in the class of the target object, it causes the execution of a behavior. The details of identifying the behavior to be invoked in response to the occurrence of an event is a semantic variation point. The resulting behavior execution is hosted by the target object. The specific mechanism by which the data passed with the request (the attributes of the request object) are made available as arguments to the invoked behavior (e.g., whether the data or copies are passed with the request) is a semantic variation point. If the invocation action is synchronous, the request also includes sufficient information to identify the execution that invoked the behavior, but this information is not available for the use of the invoked behavior (and, therefore, is not modeled. When a synchronous execution completes, this information is used to direct a reply message to the original behavior execution. The detection of an (event) occurrence may cause a behavioral response. For example, a statemachine may transition to a new state upon the occurrence of a trigger event or an activity may be enabled upon the occurrence of a trigger event. The occurrence of a change event (see .ChangeEvent. on page 385) is based on some expression becoming true. A time event occurs when a predetermined deadline expires (see .TimeEvent. on page 399). No data is passed by the occurrence of a spontaneous event. Figure 317 shows the hierarchy of events. When an event occurrence is recognized by an object, it may have an immediate effect or the event may be saved in an event pool and have a later effect when it is matched by a trigger specified for a behavior. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Aug 2004 16:19:35 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Anders wrote: Maybe you can enlighten me to why we're trying to do this at all? Bran wrote: Joaquin, can you please help Anders out? Anders: The proposed resolution is in response to at least three issues, 4263, 4456, and 6682. This is the text of the issue i filed: .................................................. Issue 6682: See CommonBehavior for a description of Event specifications Source: X-Change Technologies (Mr. Joaquin Miller) Nature: Clarification Severity: Critical Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. .................................................. That last sentence uses the lexicon of the FAS. Using the lexicon of the proposed resolution: But we aren't told there or anywhere how to specify an occurrence (the instance) nor how to specify an event (the type). Of course, in a state transition model, every event of interest is associated with a transition. Many folks want to use events in other contexts. Even when state transition models are an integral part of the modeling approach, events are often used independently from the state transition models in which they also appear. For example, Sally Shlaer's recommendations for compliance with DOD-STD-2167A use events in the specification of both internal and external interfaces of computer software configuration items. Several published methodologies recommend identifying events at an early stage in analysis or design; several of those do not use state transition models at all. Different of the folks supporting the resolution text that Jim R has prepared have different primary reasons for their support. -- Some would like to see the spec deliver on its promise: "See CommonBehavior for a description of Event specifications." -- Some are unhappy that the FAS uses events in the description and semantics sections, without providing any way to specify an event. "The notion of event is used 530 times within the UML 2.0 Superstructure specification..." -- According to the FAS the UML 1 concept, event, is renamed trigger, and "in UML 2.0, the term 'event' means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type." Some consider such changes to be unnecessary and against the mandatory RFP requirement to "minimize the impact on users of the current UML 1.x." -- Some don't like using the same word, event, for both type and instance. -- Some don't like using 'instance' for an instance of an event type. -- The actions text in the FAS depends on several kinds of events. Some feel these should be explicit metaclasses. -- Many of the kinds of events used in the FAS are not mentioned at Trigger or any of its subclasses; it appears that Trigger is not intended to be used to specify these kinds of events. Some feel that there is, therefore, no way to specify them. -- Some need to use UML to specify specific occurrences (instances of event types) in addition to events (event types) -- Some feel that matching on names is not the best way to determine the intent of a model. It is not clear that UML 2 provides any help for determining whether two uses of the same text as a name denote the same item, unless those texts appear as names of named elements (in that case, the namespace structure provides the answer). -- Some read the FAS as not including event names in the model at all, but only in diagrams. Trigger does not appear to declare, nor inherit, any attributes, nor to have any name itself. Though each of the many UML workers who supports the proposed changes may like only one or two of these many different reasons, and some certainly don't like some of them, they all do agree on the changes worked out by Jim R. I hope that helps. I'll be glad to answer any questions. Cordially, Joaquin Subject: RE: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Date: Mon, 16 Aug 2004 09:23:35 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Thread-Index: AcSBjTbaDGi7dO5oSeWhtFXr0fsJrQB0XolA From: "Anders Ek" To: "Joaquin Miller" Cc: "UML Superstructure FTF" Thanks. It is nice to get some explanation of the reasoning behind the proposal. Now for my questions/comments: - Hope you realize that there is still no notation for events, even after the proposal. They are still hidden behind the textual notation e.g. on transitions in state charts. Isn.t this a bit of a problem for someone who would like to use the events? - One of the examples you use below comes from DoDAF. As it happened I looked fairly closely at this area some time ago and found that the concept that we found needed was much closer to what in UML is called a signal than what is right now proposed as an event. What to me would have been a much more useful construct would to introduce a special kind of signal that could be used to model events (i.e. it should have a more .loose. semantics than the fairly well-defined signals). The main difference compared to a signal would be that it would be that the creation/invokation/occurrence/... would be different than signals. I guess the simplest way to specify this would right now be to do it informally. That would have given a nice notation (based on the classifier notation) and a possibility to actually use the event concept in practise. It would also have give a well-defined way to refer to the events from e.g. statemachines. Any comments? Regards Anders -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: den 14 augusti 2004 01:20 To: UML Superstructure FTF Subject: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Anders wrote: Maybe you can enlighten me to why we're trying to do this at all? Bran wrote: Joaquin, can you please help Anders out? Anders: The proposed resolution is in response to at least three issues, 4263, 4456, and 6682. This is the text of the issue i filed: .................................................. Issue 6682: See CommonBehavior for a description of Event specifications Source: X-Change Technologies (Mr. Joaquin Miller) Nature: Clarification Severity: Critical Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. .................................................. That last sentence uses the lexicon of the FAS. Using the lexicon of the proposed resolution: But we aren't told there or anywhere how to specify an occurrence (the instance) nor how to specify an event (the type). Of course, in a state transition model, every event of interest is associated with a transition. Many folks want to use events in other contexts. Even when state transition models are an integral part of the modeling approach, events are often used independently from the state transition models in which they also appear. For example, Sally Shlaer's recommendations for compliance with DOD-STD-2167A use events in the specification of both internal and external interfaces of computer software configuration items. Several published methodologies recommend identifying events at an early stage in analysis or design; several of those do not use state transition models at all. Different of the folks supporting the resolution text that Jim R has prepared have different primary reasons for their support. -- Some would like to see the spec deliver on its promise: "See CommonBehavior for a description of Event specifications." -- Some are unhappy that the FAS uses events in the description and semantics sections, without providing any way to specify an event. "The notion of event is used 530 times within the UML 2.0 Superstructure specification..." -- According to the FAS the UML 1 concept, event, is renamed trigger, and "in UML 2.0, the term 'event' means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type." Some consider such changes to be unnecessary and against the mandatory RFP requirement to "minimize the impact on users of the current UML 1.x." -- Some don't like using the same word, event, for both type and instance. -- Some don't like using 'instance' for an instance of an event type. -- The actions text in the FAS depends on several kinds of events. Some feel these should be explicit metaclasses. -- Many of the kinds of events used in the FAS are not mentioned at Trigger or any of its subclasses; it appears that Trigger is not intended to be used to specify these kinds of events. Some feel that there is, therefore, no way to specify them. -- Some need to use UML to specify specific occurrences (instances of event types) in addition to events (event types) -- Some feel that matching on names is not the best way to determine the intent of a model. It is not clear that UML 2 provides any help for determining whether two uses of the same text as a name denote the same item, unless those texts appear as names of named elements (in that case, the namespace structure provides the answer). -- Some read the FAS as not including event names in the model at all, but only in diagrams. Trigger does not appear to declare, nor inherit, any attributes, nor to have any name itself. Though each of the many UML workers who supports the proposed changes may like only one or two of these many different reasons, and some certainly don't like some of them, they all do agree on the changes worked out by Jim R. I hope that helps. I'll be glad to answer any questions. Cordially, Joaquin Subject: RE: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Date: Mon, 16 Aug 2004 07:03:21 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Thread-Index: AcSBjTbaDGi7dO5oSeWhtFXr0fsJrQB0XolAAA6s0hA= From: "Karl Frank" To: "Anders Ek" , "Joaquin Miller" Cc: "UML Superstructure FTF" X-OriginalArrivalTime: 16 Aug 2004 14:03:24.0877 (UTC) FILETIME=[CBFC6FD0:01C48399] As a vendor, I see no problem in the standards doc being silent on the subject of a notation for events. One does not "fail to comply" with a standard by using a notation , when the standard is silent on the subject. Together uses a little "lightening bolt" symbol for events in an event sheet diagram. - Karl -------------------------------------------------------------------------------- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, August 16, 2004 3:24 AM To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Thanks. It is nice to get some explanation of the reasoning behind the proposal. Now for my questions/comments: - Hope you realize that there is still no notation for events, even after the proposal. They are still hidden behind the textual notation e.g. on transitions in state charts. Isn.t this a bit of a problem for someone who would like to use the events? - One of the examples you use below comes from DoDAF. As it happened I looked fairly closely at this area some time ago and found that the concept that we found needed was much closer to what in UML is called a signal than what is right now proposed as an event. What to me would have been a much more useful construct would to introduce a special kind of signal that could be used to model events (i.e. it should have a more .loose. semantics than the fairly well-defined signals). The main difference compared to a signal would be that it would be that the creation/invokation/occurrence/... would be different than signals. I guess the simplest way to specify this would right now be to do it informally. That would have given a nice notation (based on the classifier notation) and a possibility to actually use the event concept in practise. It would also have give a well-defined way to refer to the events from e.g. statemachines. Any comments? Regards Anders -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: den 14 augusti 2004 01:20 To: UML Superstructure FTF Subject: ,cb, Issue 6682 RE: Events, triggers, etc. proposal Anders wrote: Maybe you can enlighten me to why we're trying to do this at all? Bran wrote: Joaquin, can you please help Anders out? Anders: The proposed resolution is in response to at least three issues, 4263, 4456, and 6682. This is the text of the issue i filed: .................................................. Issue 6682: See CommonBehavior for a description of Event specifications Source: X-Change Technologies (Mr. Joaquin Miller) Nature: Clarification Severity: Critical Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. .................................................. That last sentence uses the lexicon of the FAS. Using the lexicon of the proposed resolution: But we aren't told there or anywhere how to specify an occurrence (the instance) nor how to specify an event (the type). Of course, in a state transition model, every event of interest is associated with a transition. Many folks want to use events in other contexts. Even when state transition models are an integral part of the modeling approach, events are often used independently from the state transition models in which they also appear. For example, Sally Shlaer's recommendations for compliance with DOD-STD-2167A use events in the specification of both internal and external interfaces of computer software configuration items. Several published methodologies recommend identifying events at an early stage in analysis or design; several of those do not use state transition models at all. Different of the folks supporting the resolution text that Jim R has prepared have different primary reasons for their support. -- Some would like to see the spec deliver on its promise: "See CommonBehavior for a description of Event specifications." -- Some are unhappy that the FAS uses events in the description and semantics sections, without providing any way to specify an event. "The notion of event is used 530 times within the UML 2.0 Superstructure specification..." -- According to the FAS the UML 1 concept, event, is renamed trigger, and "in UML 2.0, the term 'event' means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type." Some consider such changes to be unnecessary and against the mandatory RFP requirement to "minimize the impact on users of the current UML 1.x." -- Some don't like using the same word, event, for both type and instance. -- Some don't like using 'instance' for an instance of an event type. -- The actions text in the FAS depends on several kinds of events. Some feel these should be explicit metaclasses. -- Many of the kinds of events used in the FAS are not mentioned at Trigger or any of its subclasses; it appears that Trigger is not intended to be used to specify these kinds of events. Some feel that there is, therefore, no way to specify them. -- Some need to use UML to specify specific occurrences (instances of event types) in addition to events (event types) -- Some feel that matching on names is not the best way to determine the intent of a model. It is not clear that UML 2 provides any help for determining whether two uses of the same text as a name denote the same item, unless those texts appear as names of named elements (in that case, the namespace structure provides the answer). -- Some read the FAS as not including event names in the model at all, but only in diagrams. Trigger does not appear to declare, nor inherit, any attributes, nor to have any name itself. Though each of the many UML workers who supports the proposed changes may like only one or two of these many different reasons, and some certainly don't like some of them, they all do agree on the changes worked out by Jim R. I hope that helps. I'll be glad to answer any questions. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Aug 2004 10:27:04 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cb, Issue 6682 RE: Events, triggers, etc. proposal - Hope you realize that there is still no notation for events, even after the proposal. They are still hidden behind the textual notation e.g. on transitions in state charts. Isn t this a bit of a problem for someone who would like to use the events? It has been proposed that Event be a Classifier. Certainly events can be classified, and the proposed Event is a type to the occurrences (i.e., to the instances of an event type). Then it would have a notation, the box, distinguished by a keyword. Sounds good to me, but not a part of the current proposed resolution, Events.Issues.Resolutions.040805.doc - One of the examples you use below comes from DoDAF. As it happened I looked fairly closely at this area some time ago and found that the concept that we found needed was much closer to what in UML is called a signal than what is right now proposed as an event. What to me would have been a much more useful construct would to introduce a special kind of signal that could be used to model events (i.e. it should have a more loose semantics than the fairly well-defined signals). The main difference compared to a signal would be that it would be that the creation/invokation/occurrence/... would be different than signals. I guess the simplest way to specify this would right now be to do it informally. That would have given a nice notation (based on the classifier notation) and a possibility to actually use the event concept in practise. It would also have give a well-defined way to refer to the events from e.g. statemachines. That approach certainly makes sense. The FAS text and the proposed resolution text, which talks about events going into a pool, does not make me happy. From my peculiar viewpoint in looking at these things, the only items that could possibly go into a pool are records of events or items arriving to give notice of events (e.g. signals). [Jim R., quite properly, did not tackle this; he stuck to the issues raised.] We reached consensus in a large group and Jim R did the heavy lifting, so i am very happy to go with the current proposal. I'd like to see a change that would be along the lines you suggest (distinguish occurrence from record of occurrence) and would also be used to improve the explication of the "event pool," but we are running out of time and, as you see, i'm not volunteering. Cordially, Joaquin -----Original Message----- The proposed resolution is in response to at least three issues, 4263, 4456, and 6682. This is the text of the issue i filed: .................................................. Issue 6682: See CommonBehavior for a description of Event specifications Source: X-Change Technologies (Mr. Joaquin Miller) Nature: Clarification Severity: Critical Summary: The text says "See CommonBehavior for a description of Event specifications." Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others. But we aren't told there or anywhere how to specify an event nor how to specify a type of event. .................................................. That last sentence uses the lexicon of the FAS. Using the lexicon of the proposed resolution: But we aren't told there or anywhere how to specify an occurrence (the instance) nor how to specify an event (the type). Of course, in a state transition model, every event of interest is associated with a transition. Many folks want to use events in other contexts. Even when state transition models are an integral part of the modeling approach, events are often used independently from the state transition models in which they also appear. For example, Sally Shlaer's recommendations for compliance with DOD-STD-2167A use events in the specification of both internal and external interfaces of computer software configuration items. Several published methodologies recommend identifying events at an early stage in analysis or design; several of those do not use state transition models at all. Different of the folks supporting the resolution text that Jim R has prepared have different primary reasons for their support. -- Some would like to see the spec deliver on its promise: "See CommonBehavior for a description of Event specifications." -- Some are unhappy that the FAS uses events in the description and semantics sections, without providing any way to specify an event. "The notion of event is used 530 times within the UML 2.0 Superstructure specification..." -- According to the FAS the UML 1 concept, event, is renamed trigger, and "in UML 2.0, the term 'event' means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type." Some consider such changes to be unnecessary and against the mandatory RFP requirement to "minimize the impact on users of the current UML 1.x." -- Some don't like using the same word, event, for both type and instance. -- Some don't like using 'instance' for an instance of an event type. -- The actions text in the FAS depends on several kinds of events. Some feel these should be explicit metaclasses. -- Many of the kinds of events used in the FAS are not mentioned at Trigger or any of its subclasses; it appears that Trigger is not intended to be used to specify these kinds of events. Some feel that there is, therefore, no way to specify them. -- Some need to use UML to specify specific occurrences (instances of event types) in addition to events (event types) -- Some feel that matching on names is not the best way to determine the intent of a model. It is not clear that UML 2 provides any help for determining whether two uses of the same text as a name denote the same item, unless those texts appear as names of named elements (in that case, the namespace structure provides the answer). -- Some read the FAS as not including event names in the model at all, but only in diagrams. Trigger does not appear to declare, nor inherit, any attributes, nor to have any name itself. Though each of the many UML workers who supports the proposed changes may like only one or two of these many different reasons, and some certainly don't like some of them, they all do agree on the changes worked out by Jim R. I hope that helps. I'll be glad to answer any questions. Cordially, Subject: RE: Ballot 23 Date: Wed, 18 Aug 2004 04:40:01 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 23 Thread-Index: AcSBggiDzvWXv4IqRoGC9OTAQRPrtgDelEOA From: "Pete Rivett" To: "Branislav Selic" , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Adaptive votes YES to all the proposed resolutions except 6187 and 6197 to which it votes NO. The 6187 resolution (6197 is very similar) makes the claim that Super (from Abstractions) is in effect merged since: The Constructs package of Infrastructure imports the Super package as shown in figure 11 on page 39 of the Infrastructure FAS (ptc/03-09-15). This is then merged into the Classes package... However AFAIK an import merely allows one to use the names from the imported package (Semantics of 11.6.5 only states that "A package import is a relationship between an importing namespace and a package, indicating that the importing namespace adds the names of the members of the package to its own namespace.") An import consequently does not in any way have merge semantics, so the fact that Classes merges Constructs just leads Classes to have an import of Super and not a merge. So the Issue seems correct in saying that Super is not merged. (I'm willing to be corrected on this and change my vote accordingly) Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:58 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 23 Attached, please find ballot 23. The following two issues were removed from the draft that was published earlier: 3391 6248 (compliance points issue) The text of the resolution to issue 7039 was changed but not the "closed, no change" disposition. Vote ends next Friday at 6 pm EDT. Regards, Bran From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: Ballot 23 Date: Wed, 18 Aug 2004 21:32:11 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, I am so sorry to discover this so late, but there are two serious errors and a typo in resolution 6682 (the event rework). On p. 20 of your document, under the changes for Trigger, it is omitted to add an association to Event. Note that by definition, a trigger relates an event to the behavior that it may effect (see the summary statement of trigger as modified by the proposal). A trigger is a ternary metaclass relating an event, a transition (or other items that can be triggered), and optionally, a port. Please add to the proposal under Trigger: In the Associations section add as first bullet * event: Event [1] The event that may effect the execution of the behavior. In addition, Trigger now is not an abstract metaclass. Please replace the suggestion for summary by: Rephrase as "A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier." Finally, there is a typo in the first sentence of the description. Please add into the proposal under Trigger, after "Description:" Delete the redundant fourth word "the". Please make sure that the abstract syntax matches these changes. I.e., add the association between trigger and event, and show Trigger as concrete. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 4:58 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 23 Attached, please find ballot 23. The following two issues were removed from the draft that was published earlier: 3391 6248 (compliance points issue) The text of the resolution to issue 7039 was changed but not the "closed, no change" disposition. Vote ends next Friday at 6 pm EDT. Regards, Bran From: "Thomas Weigert" To: "Thomas Weigert" , "Branislav Selic" , Subject: RE: Ballot 23 Date: Wed, 18 Aug 2004 21:57:41 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) MOT votes "YES" to all resolutions on Ballot 23, except for the issue discussed below: 6682. MOT will vote "YES" to said issue if the changes described, or equivalent changes, are made to the Ballot. Further, MOT would like to remind the editor of his commitment to update the resolution to 7553 in Ballot 24 as discussed. -----Original Message----- From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] Sent: Wednesday, August 18, 2004 9:32 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: RE: Ballot 23 Bran, I am so sorry to discover this so late, but there are two serious errors and a typo in resolution 6682 (the event rework). On p. 20 of your document, under the changes for Trigger, it is omitted to add an association to Event. Note that by definition, a trigger relates an event to the behavior that it may effect (see the summary statement of trigger as modified by the proposal). A trigger is a ternary metaclass relating an event, a transition (or other items that can be triggered), and optionally, a port. Please add to the proposal under Trigger: In the Associations section add as first bullet * event: Event [1] The event that may effect the execution of the behavior. In addition, Trigger now is not an abstract metaclass. Please replace the suggestion for summary by: Rephrase as "A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier." Finally, there is a typo in the first sentence of the description. Please add into the proposal under Trigger, after "Description:" Delete the redundant fourth word "the". Please make sure that the abstract syntax matches these changes. I.e., add the association between trigger and event, and show Trigger as concrete. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 4:58 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 23 Attached, please find ballot 23. The following two issues were removed from the draft that was published earlier: 3391 6248 (compliance points issue) The text of the resolution to issue 7039 was changed but not the "closed, no change" disposition. Vote ends next Friday at 6 pm EDT. Regards, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 23 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:02:21 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:02:23, Serialize complete at 08/18/2004 23:02:23 These all seem like minor but useful corrections to the text. I presume that those who already voted on ballot 23 will have no problems with these minor modifications to the resolution that is already on the ballot and that I will not have to pull this resolution from the ballot. If you disagree with this, tell me. Regards, Bran "Thomas Weigert" 08/18/2004 10:32 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Ballot 23 Bran, I am so sorry to discover this so late, but there are two serious errors and a typo in resolution 6682 (the event rework). On p. 20 of your document, under the changes for Trigger, it is omitted to add an association to Event. Note that by definition, a trigger relates an event to the behavior that it may effect (see the summary statement of trigger as modified by the proposal). A trigger is a ternary metaclass relating an event, a transition (or other items that can be triggered), and optionally, a port. Please add to the proposal under Trigger: In the Associations section add as first bullet * event: Event [1] The event that may effect the execution of the behavior. In addition, Trigger now is not an abstract metaclass. Please replace the suggestion for summary by: Rephrase as "A Trigger relates an Event to the Behavior that it may effect in an instance of a Classifier." Finally, there is a typo in the first sentence of the description. Please add into the proposal under Trigger, after "Description:" Delete the redundant fourth word "the". Please make sure that the abstract syntax matches these changes. I.e., add the association between trigger and event, and show Trigger as concrete. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 4:58 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 23 Attached, please find ballot 23. The following two issues were removed from the draft that was published earlier: 3391 6248 (compliance points issue) The text of the resolution to issue 7039 was changed but not the "closed, no change" disposition. Vote ends next Friday at 6 pm EDT. Regards, Bran