Issue 11838: What are semantics of real-time features on provided/required interfaces? (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Enhancement Severity: Significant Summary: Resolution: This resolution proposes general clarifications on the usage of the stereotype «RtFeature» (including its usage and underlying semantics in the context of provided/required interfaces). The stereotype «RtFeature» can be applied to multiple elements Additionnaly, issue 12954 also requires some clarifications. These clarifications require modifications to figures that are modified in this resolution. We therefore propose to resolve problems identified in issue 12954 in this document, and we state resolution to issue 12954 as duplicate/merge with this resolution 11838. More specifically, issue 12954 has identified the following problems: 1- In figure 3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. : In the proposed modification of figure 3.10, this inconsistency is removed. 2- In section 13.3.2.8 the stereotype «RtFeature» is said to extend the UML Behavior element; however in section 3.10 this extension is not shown. : In the proposed resolution, «RtFeature» does not apply anymore to behavior. 3- Figure 3.11 does not show all the attributes of the «RtAction» stereotype. The new version of figure 3.11 proposed in this resolution includes all the attributes. 4- The use of the stereotype «RtBehavior» is not clear. An example in 13.4 would be of great help. This stereotype has been deleted. Its attributes are indeed only characterizations of the event pool of an active object. Its attributes have been added to «RtFeature», and prefixed with ‘sr’ (for Schedulable Resource). (InvocationAction, BehavioralFeature, Message, Signal). In order to clarify to meaning of these multiple extensions, some text is added in the section describing the stereotype «RtFeature» to explain that: the most basic element on which «RtFeature» can be applied is InvocationAction, and that any other places where this stereotype is applied enables to specify a kind of default value in the case where the stereotype «RtFeature» has not been applied on a particular InvocationAction. Additionnaly, the title of this issue suggests that real-time features could be contextual to the usage of interfaces (for example, one may want to specify that a real-time feature concerns an operation of an interface that is provided on a given port). Therefore, we propose the following modifications: The stereotype «RtFeature» is modified so that it now also extends the Port metaclass. The stereotype «RtSpecification» is introduced, and it extends the Comment metaclass. All the attributes of «RtFeature» are removed from «RtFeature», and they are added to «RtSpecification». An «RtFeature» can now own multiple «RtSpecification», and it is possible to specify the behavioral feature that is concerned by this «RtSpecification». For example, a port can be stereotyped with «RtFeature». It can then own multiple «RtSpecification», where each of these «RtSpecification» may concern a behavioral feature of a provided or required interface of this port. Revised Text: see ptc/2009-05-12 pages 38 - 62 Actions taken: December 20, 2007: received issue October 16, 2009: closed issue Discussion: Resolution: An interface is a contract. Today, for software systems, interfaces typically express only a specification for available behaviors (e.g. Operations) or permissible information (e.g. to some extent FlowSpecs). Arguably, though, one ought to be able to express performance, cost, reliability, quality, and other non-functional properties in an interface specification. Therefore, it is not unreasonable to infer that an NFP Constraint on an interface is a constraint also on any realization of that interface. If NFP Constraints on a Provided interface conflict with NFP Constraints on a Required interface, clearly any attempt to pair the two entities should be difficult. As there currently is no section within Chapter 13 which discusses Interfaces generally or specifically applying NFP Constraints to Interfaces, the topic should be, at this late date, deferred to a subsequent revision of the MARTE specification. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 20 Dec 2007 13:53:43 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: 13 FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 155 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description Suject: What are the semantics of real-time features on provided/required interfaces? Details: A section of chapter 13 should explain how real-time service and real-time features from RTEMoCC can be applied on provided and required interfaces of a component (such as CCM). More precisely, what are the semantics of a real-time feature (e.g. deadline) on a provided/required interface? Is there an underlying notion of contract between required/provided interfaces? Proposed resolution: refine and enhance chapter 13. Subject: MARTE - Issue 11838 - Initial proposal for 11838 Date: Sat, 16 Aug 2008 06:07:39 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MARTE - Issue 11838 - Initial proposal for 11838 thread-index: Acj/XgEJk0NzhLSxRGa/z4OATxdbZg== From: "VanZandt, Lonnie" To: X-SpamInfo: FortiGuard - AntiSpam url, black url www.ArtisanSoftwareTools.com http://www.omgwiki.org/marte-ftf2/doku.php?id=forum_11838 PS: We have many more to address before the end of September. Please check your tasks at the www.omgwiki.org/marte-ftf2 site. Lonnie VanZandt Principal Engineer T: 303 482-2943 M: 720 201-1349 Lonnie.VanZandt@ArtisanSoftwareTools.com www.ArtisanSoftwareTools.com X-Orig: 71-215-95-220.hlrn.qwest.net [71.215.95.220] X-Authentication-Warning: predictableresponse.com: predicta owned process doing -bs From: "Lonnie VanZandt" To: Subject: Issue 11838: What are semantics of real-time features on provided/required interfaces? Date: Tue, 11 Nov 2008 10:28:19 -0700 Organization: Predictable Response Consulting, LLC X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclEIuNATHdINw4AQoirVZRppvm08w== Please review the recommendation at http://www.omgwiki.org/marte-ftf2/doku.php?id=forum_11838 and record your vote (there, please not in email). Your vote is nonbinding and we can formally decide the resolution of each issue in Santa Clara (during the Wednesday session). Lonnie VanZandt Consulting Systems Engineer Work: 303 482-2943 Mobile: 720 201-1349 Email: lonniev@predictableresponse.com IM: lonnievanzandt (Yahoo) http://www.linkedin.com/in/lonnievanzandt PGP Key Predictable Response Consulting, LLC 637 Witter Gulch Road Evergreen, CO 80439 We're hiring! Engineering Reliable Software Solutions... See who we know in common