Issue 15073: MARTE Issue: Overloaded relationship Scenario to Step in Analysis (marte-rtf) Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca) Nature: Uncategorized Issue Severity: Summary: In the analysis subprofiles a step has two relationships to scenarios: 1 Containment... a step is always contained in a scenario 2 Refinement: a step may be optionally be refined by a lower-level scenario The GQAM chapter defines one association behavior/steps which is defined as containment from the scenario point of view, and as refinement from the step point of view. This is navigable and usable, but formally incorrect. Suggested resolution: To be formally correct it requires two associations. One defines a collection of steps as the steps of the scenario, the other defines a scenario as a refinement of a step. Suggestion: Containment: Scenario has association steps, Step has association scenario Refinement: Scenario has association parentStep, Step has association childScenario Alternatively we could explain the overloading in the text and leave the profile as it is. Needs discussion. Resolution: To be formally correct it requires two associations. One defines a collection of steps as the steps of the scenario, the other defines a scenario as a refinement of a step. Suggestion: Containment: Scenario has association steps, Step has association scenario Refinement: Scenario has association parentStep, Step has association childScenario These changes are needed both in the domain model sec 15.2 and the profile sec 15.3, and in Appendix F.10 for the encoding of the domain model Also, some changes in sec. F.10.3 to synchronize it with sec 15.2 were transferred from issue 14435, • association Actions renamed steps (consistent with Fig 15.3) • association usedResources dropped (not in Fig. 15.3) • association inputStream renamed cause (consistent with fig 15.3) • association connectors added (consistent with Fig 15.3) • attribute priority dropped (it occurs on Step)(consistent with chapter 15) (A) Figure 15.3: • add association parentStep - childScenario • rename association behavior - steps to scenario - steps (B) Section 15.2, Text p 290 para 5: Before: Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step can be optional (with a probability less than one of being executed), or repeated (with a repetition count). It can be refined as another BehaviorScenario (its “behavior” association). The “isAtomic” property specifies atomicity of execution (default is false). Revised Text (the one new sentence is in red) Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step can be optional (with a probability less than one of being executed), or repeated (with a repetition count). A BehaviorScenario is a collection of Steps, but also a Step can also be the parent of a refinement as a more detailed BehaviorScenario (its childScenario). The “isAtomic” property specifies atomicity of execution (default is false). (C) Fig 15.7 (the profile) also needs to be updated for the second association between Step and Scenario: • add association parentStep - childScenario • modify association behavior - steps to scenario - steps (D) Appendix F.10.3 for BehaviorScenario The five changes transferred from issue 14435 are included, plus the association change between Step and BehaviorScenario. For clarity the new text is in red. Original text: Associations • root: Step [0..1] Root Step to begin the BehaviorScenario. • Actions: Step [0..1] Set of Steps making up the BehaviorScenario. • inputStream: RequestEventStream [1..*] RequestEventStream that initiates it. • usedResources: Resource [0..*] {ordered} Set of resources used by the scenario UML Profile for MARTE, V1.0 Attributes • hostDemand: NFP_Duration [0..1] CPU demand in time units. • hostDemandOps: NFP_Real [0..1] CPU demand in operations. • priority: NFP_Integer [0..1] • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation. • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an operation. • throughput: NFP_Rate [0..1] Frequency of initiations of an operation. • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times delay). For a resource, the fraction of time each unit is busy, times the number of units. • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this operation. Revised text: Associations • root: Step [0..1] Root Step to begin the BehaviorScenario. • steps: Step [0..1] Set of Steps making up the BehaviorScenario. • cause: RequestEventStream [1..*] RequestEventStream that initiates it. • parentStep: Step [0..1] Step of which this BehaviorScenario is a refinement (nested behavior) • connectors: PrecedenceRelation [*] The set of precedence relationships between the steps of the scenario Attributes • hostDemand: NFP_Duration [0..1] CPU demand in time units. • hostDemandOps: NFP_Real [0..1] CPU demand in operations. • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation. • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an operation. • throughput: NFP_Rate [0..1] Frequency of initiations of an operation. • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times delay). For a resource, the fraction of time each unit is busy, times the number of units. • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this operation. (E) Section F10.17 for Step Add the new association between Step and BehaviorScenario Old text: Associations • outputRel: PrecedenceRelation [*] Successor relation. • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation. Attributes • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further. • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step. • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or loop. • probability: NFP_Real [0..1] Probability of the step to be executed (useful for conditional execution). • priority: NFP_Interval [0..1] Step priority. Revised text: Associations • outputRel: PrecedenceRelation [*] Successor relation. • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation. • childScenario: Scenario [0..1] An optional refinement of the behavior of this Step Attributes • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further. • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step. • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or loop. • probability: NFP_Real [0..1] Probability of the step to be executed (useful for conditional execution). • priority: NFP_Interval [0..1] Step priority. (F) Sec 15.3.2.12, giving the UML definition of GaScenario Old text: Associations • steps: Step [1..*] The set of steps that make up the Scenario. New text: Associations • steps: GaStep [1..*] The set of steps that make up the Scenario. • parentStep: GaStep [1..*] A GaStep, of which this scenario is a refinement. (G) Sec 15.3.2.13, giving the UML definition of GaStep Old text: Associations • behavior: GaScenario [0..1] A GaScenario that refines a composite Step. New text: Associations • scenario: GaScenario [0..1] The GaScenario that that contains this Step. • childScenario: GaScenario [0..1] A GaScenario that refines this Step, making it a composite Step. Disposition: Resolved Revised Text: Actions taken: February 20, 2010: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== te: Sat, 20 Feb 2010 11:55:50 -0500 Subject: MARTE Issue: Overloaded relationship Scenario to Step in Analysis From: cmw@sce.carleton.ca To: issues@omg.org User-Agent: SquirrelMail/1.4.19 In the analysis subprofiles a step has two relationships to scenarios: 1 Containment... a step is always contained in a scenario 2 Refinement: a step may be optionally be refined by a lower-level scenario The GQAM chapter defines one association behavior/steps which is defined as containment from the scenario point of view, and as refinement from the step point of view. This is navigable and usable, but formally incorrect. Suggested resolution: To be formally correct it requires two associations. One defines a collection of steps as the steps of the scenario, the other defines a scenario as a refinement of a step. Suggestion: Containment: Scenario has association steps, Step has association scenario Refinement: Scenario has association parentStep, Step has association childScenario Alternatively we could explain the overloading in the text and leave the profile as it is. Subject: MARTE: issue 15073 Date: Mon, 8 Mar 2010 10:58:13 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MARTE: issue 15073 Thread-Index: Acq+pd4zdiZUxsiNQfuW+P+dCHMNnQ== From: "GERARD Sebastien 166342" To: X-OriginalArrivalTime: 08 Mar 2010 09:58:14.0966 (UTC) FILETIME=[DEC2A560:01CABEA5] Hi Murray, For issue http://www.omg.org/issues/marte-rtf.html#Issue15073, your suggestion adding explicitly two association for containment and refinement sound good for me. Can you make proposal in this sens for ballot 1 please? Thanks, Cheers. Séstien G. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment Subject: RE: MARTE: issue 15073 Date: Tue, 13 Apr 2010 10:14:24 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MARTE: issue 15073 Thread-Index: Acq+pd4zdiZUxsiNQfuW+P+dCHMNnQcOLdoA From: "BERNARD, Yves" To: "GERARD Sebastien 166342" , X-OriginalArrivalTime: 13 Apr 2010 08:14:25.0006 (UTC) FILETIME=[544930E0:01CADAE1] Sé Murray, I think there are inconsistencies in the proposed resolution. For instance the .childScenario. association end is typed by a class Scenario that is not defined, the .steps. association end has [0..1] multiplicity in the revised text while it should be [0..*]. More, the exact relationship between Step and BehaviorScenario is not clear and seems inconsistent. On one hand a Step is described as a subtype of BehavioralScenario and on the other hand it is stated that it can be refined by a BehavioralScenario. My feeling is that Step and BehavioralScenario are in fact two aspects of the same thing that UML try to formalize in its InteractionFragment metaclass. I believe it.s worth reviewing all that part of the domain model. Yves De : GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Envoyé lundi 8 mars 2010 10:58 À: marte-rtf@omg.org Objet : MARTE: issue 15073 Hi Murray, For issue http://www.omg.org/issues/marte-rtf.html#Issue15073, your suggestion adding explicitly two association for containment and refinement sound good for me. Can you make proposal in this sens for ballot 1 please? Thanks, Cheers. Séstien G. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Date: Wed, 14 Apr 2010 14:21:19 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: "BERNARD, Yves" cc: GERARD Sebastien 166342 , marte-rtf@omg.org Subject: RE: MARTE: issue 15073 User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Yves, The relationship has had a lot of discussion and indeed use in modeling, and I am quite sure it is sound. A step can be part of a parent scenario, but also it can itself have a refinement... exactly like an interaction fragment or a structured activity, the MARTE refinement of a step represents both. The purpose of stereotyping these existing concepts is not to change their meaning but to attach parameters to them. There may be some details such as multiplicity that are still incorrect. I will have to look again. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Tue, 13 Apr 2010, BERNARD, Yves wrote: Séb, Murray,  I think there are inconsistencies in the proposed resolution. For instance the âchildScenarioâ association end is typed by a class Scenario that is not defined, the âstepsâ association end has [0..1] multiplicity in the revised text while it should be [0..*]. More, the exact relationship between Step and BehaviorScenario is not clear and seems inconsistent. On one hand a Step is described as a subtype of BehavioralScenario and on the other hand it is stated that it can be refined by a BehavioralScenario.  My feeling is that Step and BehavioralScenario are in fact two aspects of the same thing that UML try to formalize in its InteractionFragment metaclass. I believe itâs worth reviewing all that part of the domain model.  Yves  DeÂ: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] EnvoyéÂ: lundi 8 mars 2010 10:58 ÃÂ: marte-rtf@omg.org ObjetÂ: MARTE: issue 15073  Hi Murray,  For issue http://www.omg.org/issues/marte-rtf.html#Issue15073, your suggestion adding explicitly two association for containment and refinement sound good for me. Can you make proposal in this sens for ballot 1 please?  Thanks, Cheers. Sébastien G. >   Dr. Sébastien Gérard Head of MDD for DRES research project CEA LIST, Laboratoire dâIngénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Boîte courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus  Before printing, think about the environment  This mail has originated outside your organization, either from an external partner or the Global Inte rnet. Keep this in mind if you answer this message.  The information in this e-mail is confidential. The contents may not be disclosed or used by anyone ot her than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you s hould take whatever measures you deem to be appropriate to ensure that this message and any attachment s are virus free. Needs discussion.