Issue 5035: Chap. 5, p. 47 and following (4.2.1 Modeling Realization Relationships) Jira Issue SPTP-4
Issue 5047: concepts introduced can be redundant with UML Jira Issue SPTP-5
Issue 5048: Section 6.2.2 UML Extensions, page 103 Jira Issue SPTP-6
Issue 5049: p. 99: Jira Issue SPTP-7
Issue 5050: SA Profile issue Jira Issue SPTP-8
Issue 5078: concepts that already exists in UML Jira Issue SPTP-9
Issue 5085: The different profiles do not pay special attention to identify well-formed Jira Issue SPTP-10
Issue 5275: Page 4-36, "GRMAcquire" (issue 2) Jira Issue SPTP-11
Issue 5290: Page 8-20, PaextOpValue Jira Issue SPTP-12
Issue 5313: more abstract demand unit needed Jira Issue SPTP-13
Issue 5314: Repetition counts Jira Issue SPTP-14
Issue 5315: The concept of scenario Jira Issue SPTP-15
Issue 5316: there could be a better, more complete RTtimeValue (p90+) Jira Issue SPTP-16
Issue 5317: Frequency Jira Issue SPTP-17
Issue 5318: OrderedTimeSets Jira Issue SPTP-18
Issue 5319: time/frequency definitions Jira Issue SPTP-19
Issue 5699: suggest inclusion of <<RTtimedAction>> stereotype (inherited from <<RTactio Jira Issue SPTP-20
Issue 5700: TVL notation Jira Issue SPTP-21
Issue 5703: <<CRsync>> Jira Issue SPTP-22
Issue 5704: <<SAschedRes>> Jira Issue SPTP-23
Issue 5711: Section 5, figure 5-5. Jira Issue SPTP-24
Issue 5712: Section 5, Page 5-13 first lines. Jira Issue SPTP-25
Issue 5720: Fig 5-5 Timed Action should inherit from Action Execution Jira Issue SPTP-26
Issue 5875: General issue Jira Issue SPTP-1
Issue 5919: Support high-level schedulability analysis Jira Issue SPTP-2
Issue 5035: Chap. 5, p. 47 and following (4.2.1 Modeling Realization Relationships) (uml-scheduling-ftf)
Click here for this issue's archive.
Source: Esterel Technologies (Mr. Jean-Paul Rigault, )
Nature: Uncategorized Issue
Severity:
Summary:
The distinction between Refinement and Realization becomes less and less clear to me. I understand the logical difference between presenting the same model with vari-ous levels of details (refinement) and setting a bridge between two different models, one realizing/implementing/deploying the other (realization). However, as far as the modeling elements and their relationships are concerned, the mechanisms seem to be identical and the frontier often appears fuzzy. This trouble and confusion is apparent in the submission itself since one category of realization may well be considered as refinement (replacement, p. 51), as indicated by the authors themselves. The argument that hardware and software are still different entities is not completely convincing to make it a realization: indeed the hardware manipulates (although under different forms) the same information as the software, at run-time. Another question: why restrict replacement to the deploy mapping and to a relation-ship between hardware and software? Is not �code� a form of replacement? � I was also expecting a general notation for representing the Realization (or Realiza-tion/ Refinement) relationship in UML. This is only sketched in the document (p. 48) but far from expressing the whole richness. The following characteristics seem of interest to me: - multiplicity, both on client and supplier sides - conjunction or disjunction - exclusivity or not - "optionality" or "mandatority" - static or dynamic nature of the relationship and of all the above characteristics - combination of functionalities (additive, replacement...) I am not sure that the simple distinction between require on the one hand and inclu-sive and exclusive (static or dynamic) on the other hand (p. 50) is sufficient to repre-sent all the useful and significant cases. However, I am already late to send this review so I have no time to elaborate more on this, but I would be pleased to discussed it with anybody, if this is found interesting. Of course, this submission might not be the place to set up a general model of Real-ization/ Refinement.
This has been pointed out as one of the major weak areas of the submission and needs to be elaborated further or maybe removed (Bran). As indicated in previous discussions, this is indeed considered to be a major weak point in the spec and at least warrants some additional clarifications to the text in sections 4.1.8.1 and 4.1.8.2. However, it is not expected that these will be sufficient to remove the issue. Also, the issuer seems to have missed the fact that at least some of the characteristics he mentions as being omitted (multiplicty, conjunction/disjunction, etc.) are in fact addressed in section 4.2.1.2. Keep the issue open for the 2.0 version of the profile.
Other concepts introduced can be redundant with UML modeling elements or attributes; for example SynchronousInvoke and AsynchronousInvoke are redundant with attributes of methods and operation attributes in UML metamodels
This was intentional, but may need to be looked into; the problem is that some of the existing UML models of such things tended to be rather na�ve and did not fit well into the more sophisticated models required here; however, I will revisit this and see if something can be done (Bran). Valid comment but it should be taking into account in the context of an alignement work with UML2.0. It implies, it is out of the scope of this RTF.
The proposed <<CRConcurrent>> stereotype appears to overlap concepts found in UML active classes and objects yet there is no discussion of their relationships. Recommend such a discussion be included.
I will add such discussion in order to state "active" stereotype regarding these one introduced in the SPT profile. I fully share this point. But the problem is very difficult to solve because in theory a UML profile should be an extension or a subset of the UML. In this case, the UML instantiate a concept that is defined in a generic way in a profile. So how to status about this issue? BTW, we will have the same problem later with the version 2.0 of the UML profile SPT regarding concept of time for example
"In the domain view point describing the concurrency feature, two specific kinds of service are introduced: DeferredService and ImmediateService. I propose to add: IgnoredService A kind of service instance that is ignored if the receiving object is not able to handle it when it receives it. RejectedService A kind of service instance that is rejected if the receiving object is not able to handle it when it receives it. The rejection of a call will also raise an exception that can be catch either by the sender of the stimuli or by the system itself."
I propose to enrich this part in order to aligned with incoming proposal of UML 2.0. This point should be done in the context of alignment with UML2.0 (e.g. with concepts ciontroduced for protocol statemachine). So it is out of the scope of a RTF and should be done in the version 2.0 of the UML profile for SPT.
Activity diagrams are an interesting solution for the description of behaviors. This notation restricted (we cannot include loops and the fork join pseudo states must be used in cobegin-coend sequences) can represent the same types of responses used in some scheduling analysis methods [6,5,7,3]. They can be used to describe the behavior of Operations and this will describe the response associated to messages and stimulus. This is useful to describe sequences of actions that use different types of resources, and these actions could be executed in sequence, parallel or selection. If we have the sequence of a collaboration diagram DD1 ope1 -> DD1.1 ope2 -> DD1.2 ope3, and the operations are described with the activity diagrams like ((action1 || action2) | action3) -> action4 (|| represents the parallel execution, | the selection, and actioni are action states that can be stereotyped as SAStep), we can substitute the operation message or stimuli by their activity diagram, and create an event response based on the combination of both types of behavior description. These notations are useful to represent complex behaviors of operations and messages and to optimize the evaluation of jitters
Aim is sound, but problem with representing executions in Activity Graphs in UML. Consider activity graphs more fully in GRM. Given that we do not intend to incorporate any elements of UML 2.0 in to this revision this is outside the scope of the RTF but should be deferred to version 2.0.
We think it is not possible to forget some concepts that already exists in UML and that are very closed to some of the previous one. More precisely I think about three following issues: 1.������ The isActive meta-attribute of the Class meta-class � Active/passive object which are particular case of active/passive resource; So, according to me they are specialization of the stereotype <<GRMactiveRessource>>. 2.������ The concurrency meta-attribute of the Operation meta-class which is a kind of concurrency policy on operations; 3.������ The isQuery meta-Attribute of BehavioralFeature may be connected to the Service concept. 4.������ Both stereotypes <<Thread>> and <<Process>> of the Classifier meta-class I deem that they are outside the scope of UML core and could be placed in the RT profile. There are indeed specialization of the stereotype <<GRMactiveResource>>. To conclude, we think that the links between this profile and UML meta-model is not so simple. Today we have no precise solution. One way to proceed could be to remove from UML all concepts pertaining to concurrency and put them in the concurrency profile for UML � to remove isActive, concurrency and isQuery meta-attributes and <<Thread>> , <<Process>> stereotypes;
We should at least map the concepts over.
The different profiles do not pay special attention to identify well-formed rules. Each stereotype has a set of rules, but they are not OCL constraints. The rules pay attention to the consistence of the stereotypes and their tagged values, but there are not consistence rules of complete models (e.g. the workload elements in performance models must have associated some steps that must be identified in the context of the model, and this identification depends on the mapping).
Valid point; but probably exceeds the scope of an FTF (Bran). I guess this is a complaint that some of the semantic relationships that exist in the domain model are not captured explicitly through OCL constraints. This is definitely the case, but would require significant effort to rectify - beyond the scope of an RTF but should be a requirement in the future RfP.
Shouldn't the services referenced by GRMexclServ have a stereotype to say that they're exclusive - we used to have one GRMExclusive but this appears to have been removed.
The scope of this goes beyond an RTF but shouldn't be forgotten.
PaextOpValue is a complex tagged value that seems to iterate over a set of operation and provide information about those operations. Wouldn't it be better to introduce a stereotype of operation and add <integer> and <time-value> to that? We would then either add a tag from "Pastep" to this new stereotype or use an existing UML relationship.
The recommendation for an RTF revisit of this was based on a misunderstanding of what RTFs are mandated to do. This is a new feature that requires a separate RFP.
CPU demands are represented as time values... this is useful for limited studies, but a more abstract demand unit, that can be scaled to different platforms, which give greater modeling power. There is no obvious unit for this... the definition of execution demands could be relaxed so it can be any units. Call it demand instead of execution time.
Valid comment, but this is a new feature that is outside the scope of either an FTF or RTF. Should be deferred to major revision.
Repetition counts on messages need to be RTtimeString rather than integers, to allow for more general behaviour. For instance in sending an image frame, the number of packets sent is not a fixed number, but depends on compression... so an RTtimeString could give the distribution or average number.
Valid comment, but this is a new feature that is outside the scope of either an FTF or RTF. Should be deferred to major revision.
The concept of scenario is limited to an ordered set of steps. It needs to accomodate scenario structure, such as a graph with connectors such as OR-form/join, and probabilities of forks. This kind of structure is also needed in the sequence diagram, so maybe the same solution can be used for both.
This new feature needs UML 2.0 sequence diagrams, so defer to new RfP
"1) I believe that there could be a better, more complete RTtimeValue (p90+). While the included format does handle many situations it is not sufficiently general. For example, it could handle several other common time designators, e.g., time zones (EST, GMT, PDT,...), Julian Date, and (the un-related) Julian Calendar, approximates times, and to support diversity, non Gregorian calendars."
Again, the existing comment reflects a misunderstanding of an RTF mandate. This is a new feature that requires a new RFP.
"2) Frequency. While the probabilistic definitions are included (and necessary), there are many other instances of repeatable events that need to be described e.g., Every Third Monday, the 15th of the month, twice a day. (or a really hard one, every Easter). Though you may feel that these events are out of scope, they are important in any sort of scheduler, and are necessary to ensure that the low-level time definitions scale up. It would not be good to use incompatible time/frequency expressions at different scale."
Again, the existing comment reflects a misunderstanding of an RTF mandate. This is a new feature that requires a new RFP.
"3) OrderedTimeSets: While I did some ordered time for the purpose of schedule. I believe that a more robust OrderedTimeSet may be needed for the concepts of observations. The special case of a OrderedTimeSet with 2 elements becomes the basis for Duration."
Again, the existing comment reflects a misunderstanding of an RTF mandate. This is a new feature that requires a new RFP.
"The general timing specification (GTS) semantically is a general set of points in time. The purpose of the GTS is to specify the complex timing of events and actions (mainly in orders and scheduling systems.) The GTS also supports the cyclical validity patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime)... The GTS data type has the following aspects: � GTS as a general set of points in time (SET<TS>). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. � GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. � GTS as a generator of a sequence of intervals of point in time (LIST<IVL<TS>>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. � GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time (SET<TS>). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form... I've recently passed part of the HL7 data type spec to Bran Selic, I arguing for using this opportunity to develop a more broadly useful and powerful time [BTW, I'd personally enumerate the days of the week with Sunday first, not last]
Again, the existing comment reflects a misunderstanding of an RTF mandate. This is a new feature that requires a new RFP.
"As actions can have a limited time budget, they should include a deadline. Therefore, I suggest the inclusion of the <<RTtimedAction>> stereotype (inherited from <<RTaction>>), which would represent an action with a deadline (tag RTdeadline - also new) and a timeout exception handler (tag RTtimeoutException). A motivation for adding this new element is that, in general, modeling such restrictions is more complex than programming it using ORC APIs! Another benefit is that the exception caused by the deadline violation would be explicitly associated with the stereotype. Please take a look at item 1 in the attached file (Leandro Diagrams.doc)."
Valid point that requires a new feature and, hence, an RFP
"TVL notation: I could observe the absence of expressiveness to indicate a condition to finish the event generation (e.g. in the TMO one can say ""generate events from 10am to 10:50am""): ""for t = from 10am to 10:50am every 30min start-during (t, t+5min) finish-by t+10min"", i.e.: {""start-during (10am, 10:05am) finish-by 10:10am"", ""start-during (10:30am, 10:35am) finish-by 10:40am""}." Valid point that requires a new feature and, hence, an RFP
<<CRsync>>: we suggest the inclusion of a new tagged valued called CRcallTimeout. It would represent the maximum waiting time from the calling object. For example, this would be useful to model the RT-CORBA Messaging:: RELATIVE_RT_TIMEOUT_POLICY_TYPE attribute. Like in 1.2, the could be a timeout handler associated with, for example, a stereotype named RTcallTimeoutHandler (see attached item 3 in (Leandro Diagrams.doc)).
Because of impact on the profile architecture (dependency between time and concurrency sub-profiles), I suggest to defer this issue the version 2.0.
<<SAschedRes>>: why this stereotype isn't inherited from <<CRconcurrent>>? As I could understand from the documentation, they represent the same thing: "a unit of concurrent execution, such as a task, a process, or a thread". Therefore, I believe it should also include the tag CRmain.
I agree with this suggestion - but it does change the normative specification slightly, by adding a new feature, so I'll defer to 2.0.
Some scheduling analysis techniques use more than one duration time in the description of actions (one action, specially SAction that inherits TimedAction, can have associated more than one duration and this can provide different scheduling analysis results).
Requires significant change to the spec, so outside scope of RTF - useful idea though so bear in mind for new RfP.
The definition of duration looks like an �execution time� definition, not like a �computation time� definition, that is the role of this attribute in analysis metamodels. Suggest the following definition: "the time interval of execution capacity used by the action"
This may be true in certain analysis domains, but I do not believe that it holds for all necessarily. Hence, the general nature of the concept of "duration" in this abstract part of the model should be retained and then refined in the appropriate subsections. This is related to the proposed resolution of issue 5711. Hence, this should be retained as an RTF item.
Fig 5-5 Timed Action should inherit from Action Execution - this would allow it to have predecessors and successors and requiredQoS as well as Scenario properties (because Action Execution inherits from Scenario) Julio Medina [[email protected]] This is a new feature request that requires an RFP
Need to say for each association in the domain models, how they map to UML with the SPT profile applied.
This requires significant rework much of which will have to be redone for the 2.0 version of the profile. Hence, it is better to resolve the issue in 2.0.
Often in the early stages of analysis, an the active objects, rather than their internal operations are treated as the schedulable entity. In order to support this mode of analysis, the stereotypes associated to schedulable entities, SAtrigger and SAresponse, must include in their base types all relevant classifiers and Instance