Issue 15377: RequestEventStream changed by WorkloadEvent (marte-rtf) Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es) Nature: Clarification Severity: Significant Summary: The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent. Resolution: The change from RequestEventStream to WorkloadEvent needs to be completed. The sections where it appears still in the text are: annex H, some texts in GQAM and PAM and many sections in Annex F: 10.19, 10.14, 10.21, 11.1, 12.1, 12.3, 12.4 Revised Text: Change text: (search for requestEvent) In Section 17.2.2.3 Workload, change the paragraph: “Behavior is initiated by a request event. An open workload is a RequestEventStream in which the events arrive at a given rate in some predetermined pattern (such as clocked or Poisson arrivals), or by a trace.” By “Behavior is initiated by a workload event. An open workload is a WorloadEvent in which the events arrive at a given rate in some predetermined pattern (such as clocked or Poisson arrivals), or by a trace.” Towards the end of section 17.4.6 Example 6: State machine annotations Change text: “A second use of a state machine is to define a sequence of operations, like an interaction diagram. This must be a behavior that terminates, and its start point is driven by a RequestEventStream.” By “A second use of a state machine is to define a sequence of operations, like an interaction diagram. This must be a behavior that terminates, and its start point is driven by a WorkloadEvent.” In section F.10.3 BehaviorScenario Change association: • inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. By • cause: WorkloadEvent [1..*] The requesting event stream that initiates it. Change Constraint [1] The same BehaviorScenario may be associated with one or more RequestEventStreams within the same AnalysisContext. By [1] The same BehaviorScenario may be associated with one or more WorkloadEvent within the same AnalysisContext. In section F.10.7 EventTrace Change its description from: “A trace of events that can be the source for the request event stream.” To “A trace of events that can be the source for the workload event stream.” Change the association: • stream: RequestEventStream [1] Indicates the event stream driven by the trace. To • stream: WorkloadEvent [1] Indicates the workload event stream driven by the trace. In section F.10.14 RequestEventStream Change the name of the section from RequestEventStream to WorkloadEvent Eliminate Attribute • type: EventStreamKind [0..1] One of the following enumeration values: {Generator, Pattern, Trace, Timed} which indicates how the request events are obtained. Change attribute: From: • pattern: ArrivalPattern [0..1] If the type value is Pattern, then this attribute of type ArrivalPattern (which is a dataType imported from the model library of Basic::NFPTypes) describes it. To: • pattern: ArrivalPattern [0..1] If this attribute is present it describes the pattern of events generated. Change the constraint from: “[1] The type attribute determines which source of events defines the stream, and the optional association or attribute for that type must be defined.” To: “[1] Only one among the three associations: generator trace and timedEvent, and the attribute pattern may be present.” Eliminate section F.10.20 WorkloadEvent In section F.10.19 WorkloadBehavior Change associations from: • demand: RequestEventStream [*] Indicates the request event streams that are part of this container. • behavior: BehaviourScenario [*] Indicates the set of system behaviors used for analysis. To: • demand: WorkloadEvent [1..*] Indicates the workload event streams that are part of this container. • behavior: BehaviorScenario [1..*] Indicates the set of system behaviors used for analysis. In section F.10.21 WorkloadGenerator Change association from: • behavior: RequestEventStream [*] To: • behavior: WorkloadEvent [*] Change constraint: [1] One generator may trigger several RequestEventStreams, and one Behavior may be triggered by several generators By: [1] One generator may trigger several WorkloadEvents, and one Behavior may be triggered by several generators In section F.11.1 EndToEndFlow Change association: • endToEndStimuli: RequestEventStream [1..*] Set of request event stream that trigger the processing flow. To • endToEndStimuli: WorkloadEvent [1..*] Set of workload events that trigger the processing flow. In Annex H Change the mapping for element SAtrigger from RequestEventStream to WorkloadEvent In Section F.12PAM there are several concepts previously removed, which are now not related to the text in the PAM section, please delete them as editorial changes. Actions taken: July 20, 2010: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 Jul 2010 15:40:58 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Julio Medina Employer: Universidad de Cantabria mailFrom: julio.medina@unican.es Terms_Agreement: Specification: UML Profile for MARTE Section: SAM FormalNumber: formal/2009-11-02 Version: 1.0 Doc_Year: 2009 Doc_Month: November Doc_Day: 30 Page: 682 Title: RequestEventStream changed by WorkloadEvent Nature: Clarification Severity: Significant CODE: 3TMw8 B1: Report Issue Description: The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent.