Issue 10480: Data flow diagrams (rtc-ftf) Source: Technologic Arts (Mr. Takeshi Sakamoto, tsakamoto@tech-arts.co.jp) Nature: Uncategorized Issue Severity: Minor Summary: Summary Like Figure 7.2 Lightweight RTC package,I think it would be better that Figure 7.6 Data flow type be divided into several diagrams. In terms of the Stereotype description, dataFlowComposite (Page 33) and dataFlowParticipant (Page 35), since there is a description, "The dataFlowComposite stereotype may only be applied to a component that is also extended by the lightweightRTComponent stereotype or some subtype thereof" in Constraints, I think it would be better to take over the lightweightRTComponent stereotype. If lightweightRTComponent is taken over, the stereotype that takes over the characteristics of lightweightRTComponent is only one, either dataFlowComposite or dataFlowParticipant, and the description in Constraints can be deleted. Proposed Resolution [attachment:data-flow-metamodel.png] [[BR]] Meta-Model [attachment:data-flow-stereotypes.png] [[BR]] Stereotypes Discussion I agree with the reorganization of the diagrams. I'm not sure about the stereotypes, though. By "take over the lightweightRTComponent stereotype," you mean define dataFlow* as subtypes of lightweightRTComponent? I think there may be a problem with that when multiple stereotypes are used. If a component has both dataFlowParticipant and dataFlowComposite, the lightweightRTComponent stereotype will really be there twice. I don't know whether that's a problem in UML, but when it is mapped to IDL and then to code, it will result in diamond inheritance, which can be inconvenient. -- RickWarren, 2006/11/27 Sakamot-san's comment. Although two stereotypes have inheritance relation in stereotypes definition, they need not have inheritance relation in implementation. * The stereotype definition defines how the meta-class (in our case, it is Component) should be extended. * The inheritance (or generalization) makes the feature that is defined in the upper-class take over to a lower-classes as it is. * According to the stereotype inheritance, the lower-classes can use extension method that is defined in upper-class. Since the stereotype defines only meta-classes extension, it does not limit implementation or PSM. -- NoriakiAndo, 2006/12/4 Resolution: Unify the dataFlowParticipant and dataFlowComposite stereotypes. The combined stereotype will extend the lightweightRTComponent stereotype directly. Revised Text: · In section 7.3.1, Periodic Sampled Data Processing, the sentence "In a hierarchical component-based application, data flow consists of two roles:" and the bulleted list that follows should be replaced with the following sentences. A periodic execution context executes data flow components periodically in a well-defined order relative to one another. A data flow component may also be a composite component containing other data flow components. In this way, sampled data processing may be decomposed to an arbitrary level of hierarchy. · In section 7.3.1, Periodic Sampled Data Processing, the following figure should replace Figure 7.6, Data Flow Types. Figure < number > - Periodic Sampled Data Processing Stereotypes · In section 7.3.1, below Figure7.6, Data Flow Type, the following sentence "An RTC developer declares a particular RTC to be a data flow composite and/or participant by extending it with the stereotypes dataFlowComposite and/or dataFlowParticipant respectively." should be replaced with "An RTC developer declares a particular RTC to be a data flow component by extending it with the stereotype dataFlowComponent." · In section 7.3.1, Periodic Sampled Data Processing, the following figure should replace Figure 7.7, Data Flow Example. Figure < number > - Periodic Sampled Data Processing M1 Illustration · Rename section 7.3.1.1 dataFlowComposite, to dataFlowComponent. · In section 7.3.1.1 dataFlowComposite (now dataFlowComponent), replace the sentence under Description with the following: "The dataFlowComponent stereotype may be applied to a component type to indicate that its instances should be executed in sorted order by a periodic execution context." · In section 7.3.1.1 dataFlowComposite (now dataFlowComponent), the first constraint should be deleted. · In section 7.3.1.1 dataFlowComposite (now dataFlowComponent), the second constraint should be rewritten as "An instance of a component extended by the dataFlowComponent stereotype must participate in at least one execution context of kind PERIODIC, which shall also be used for the execution of any contained data flow components." · In section 7.3.1.1 dataFlowComposite (now dataFlowComponent), a third constraint should be added: "A component extended by dataFlowComponent must realize the interface DataFlowComponentAction." · In section 7.3.1.1 dataFlowComposite (now dataFlowComponent), the following unnumbered subsection should be added after Description subsection. Generalizations· lightweightRTComponent · In section 7.3.1.1.1 Execution Sorting, rename "data flow composite" and "data flow participant" to "data flow component". · In section 7.3.1.1.1, Execution Sorting, the following figure should replace Figure 7.8, Data flow composite containing data flow participants. Figure < number > - Hierarchical Data flow Component · In section 7.3.1.1.2 Two-Pass Execution, rename "data flow participant" to "data flow component". · In section 7.3.1.1.2, Two-Pass Execution, the following figure should replace Figure Two-pass Execution Example. (This figure was added by the resolution to issue 10481.) Figure < number > - Two-pass Execution Example · In section 7.3.1.1.2, Two-Pass Execution, the following figure should replace Figure ExecutionContextOperations::set_rate Example. (This figure was added by the resolution to issue 10481.) Figure < number > - ExecutionContextOperations::set_rate Example · Remove section 7.3.1.2 dataFlowParticipant. · In section 7.3.1.3 DataFlowComponentAction, Description, replace the sentence with the following: "DataFlowComponentAction is a companion to ComponentAction (see Section 7.2.2.5<cross reference to ComponentAction>) that provides additional callbacks for intercepting the two execution passes defined in Section 7.3.1.1.2<cross reference to Two-Pass Execution>." · In section 8.2.2, Stereotypes, replace the dataFlowComposite and dataFlowParticipant bullets with a single bullet "dataFlowComponent is represented by the DataFlowComponent interface." · In RTC.idl and in Annex A, remove the definition of DataFlowComposite and rename DataFlowParticipant to DataFlowComponent. · Subsequent sections and Figure numbers should be renumbered accordingly. Actions taken: Discussion: End of Annotations:===== MG issue 10480: Data flow diagrams Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]]) Severity: Minor Disposition: Resolution Proposed Summary Like Figure 7.2 Lightweight RTC package.I think it would be better that Figure 7.6 Data flow type be divided into several diagrams. In terms of the Stereotype description, dataFlowComposite (Page 33) and dataFlowParticipant (Page 35), since there is a description, "The dataFlowComposite stereotype may only be applied to a component that is also extended by the lightweightRTComponent stereotype or some subtype thereof" in Constraints, I think it would be better to take over the lightweightRTComponent stereotype. If lightweightRTComponent is taken over, the stereotype that takes over the characteristics of lightweightRTComponent is only one, either dataFlowComposite or dataFlowParticipant, and the description in Constraints can be deleted. Proposed Resolution [attachment:data-flow-metamodel.png] [[BR]] Meta-Model [attachment:data-flow-stereotypes.png] [[BR]] Stereotypes Discussion I agree with the reorganization of the diagrams. I'm not sure about the stereotypes, though. By "take over the lightweightRTComponent stereotype," you mean define dataFlow* as subtypes of lightweightRTComponent? I think there may be a problem with that when multiple stereotypes are used. If a component has both dataFlowParticipant and dataFlowComposite, the lightweightRTComponent stereotype will really be there twice. I don't know whether that's a problem in UML, but when it is mapped to IDL and then to code, it will result in diamond inheritance, which can be inconvenient. -- RickWarren, 2006/11/27 Sakamot-san's comment. Although two stereotypes have inheritance relation in stereotypes definition, they need not have inheritance relation in implementation. * The stereotype definition defines how the meta-class (in our case, it is Component) should be extended. * The inheritance (or generalization) makes the feature that is defined in the upper-class take over to a lower-classes as it is. * According to the stereotype inheritance, the lower-classes can use extension method that is defined in upper-class. Since the stereotype defines only meta-classes extension, it does not limit implementation or PSM. -- NoriakiAndo, 2006/12/4