we think this term is too vague
Closed, no change
VoidData should be documented
The distributed thread id must be available in all interception points.
The RTC1 document needs to assert that RTCurrent must be correct
in various interception points (in order for Dynamic Scheduling
to work).
The RTC1 document needs to be integrated with the RTC2 document
There is a potential problem for some schedulers in using
Portable Interceptors for scheduling points. PICurrent can't
be updated in receive_reply.
In section 5.2.7.2, "scheduling policy" should be "scheduling parameter
In section 5.5.2, the semantics for scheduling_policies should be discussed
It should be possible to get the thread id from a
distributable thread instance
Spawn should discuss the initial execution state of the
newly created distributable thread
There is a stereotype called<<SAschedulable>> and a tag
definition called SAschedulable in the SAprofile package - to avoid
potential problems with name clashes (UML is unclear whether this is
allowed) the stereotype should be renamed <<SAschedRes>>.
Scheduling and Performance sub-profiles do not give details for the identification of behaviors from UML models. This is especially important in performance and scheduling analysis. They do not restrict the UML behavior models (e.g. collaboration diagrams, activity diagrams and state diagrams, sequence diagrams), and sometimes some types of models are not analyzable (e.g. loops in state and activity diagrams are not directly analyzable with scheduling analysis methods). Because of this, different mappings from UML models to analysis domain models can provide different analysis results or not classify consistent the same models. The profile do not provides restrictions and guidelines of mappings from message sequences, stimulus sequences, and state and activity transitions to scheduling domain models.
Closed, no change
The profiles proposed, but CORBA RT sub-profile, are real-time platform and language independent. The extensions are independent of specific analysis methods, specially the performance and scheduling analysis sub-profiles. To identify some parameters of specific methods new extensions must be introduced. The analysis of platform specific models requires the definition of new sub-profiles based on the profiles of the standard, and this process requires a very good knowledge of this standard.
Closed, no change
The fourth column of the tags specification table in the UML viewpoint should be “Domain Attribute/Association Name” instead of “Domain Attribute Name” because sometimes the tags match an attribute of the corresponding domain element but it can also match to an association.
see above
Fig 7-3 An Execution Engine may have one to many Scheduling Policies - this
seems clear if you follow the relationship from Execution Engine through
Scheduler to Scheduling Policy. Julio Medina [medinajl@unican.es]
see below
Fig 7-1 In order to better support analysis of distributed scheduling
problems, we need to weaken some of the multiplicities: A (distrubuted)
Scheduling Job should be related to one or more Execution Engines; An
SAction has an optional host. Julio Medina [medinajl@unican.es]
see below
Reference 10, "Guiterrez" should read "Gutierrez"
Use suggested text
"Position regarding Action Language Semantics Work
I think that some concepts introduced in the SPT profile are closed, even similar, to ones introduced in the Action Semantics Language profile. For example: Is the concept of action introduced in SPT consistent with this one introduced in ASL? In fact, action definition is the core issue of ASL profile. So my opinion is that it would be better to reuse the ASL concepts as much as possible instead of introducing additional one?
These two profiles are know almost mature and then are going to be standardized. Moreover, both are going to be very useful for real-time system area: SPT by nature, and ASL because it will allow to build full executable UML models. So it is very important these two profiles to be coherent. Then I think it could be a good think to take some times to synchronize both woks before standardizing them.
"
Closed, no change
I am very surprised by the fact that very often concepts specified in the domain viewpoint are not present in the UML viewpoint. Some examples can be extracted from the GRM model: the main concept introduced in this package, i.e. Ressource, is not translated in the UML viewpoint.
Closed, no change
"
I am certainly not a specialist in Schedulability and Performance Analyses. Thus I can
only give a general impression. These two chapters appeared to me as the most diffi-cult
to read and understand. The risk (clearly faced by the authors themselves) is that
the concepts presented be biased toward existing tools. Another risk is that these con-cepts
rely on the new Time and resource modeling, and that the corresponding notions
need to be somewhat broken in before being applied."
closed, no change
Below in the text, the term “Analysis” is used alone (i.e. without reference with objective of the anaysis, i.e. Performance, Scheduling, which are real-time properties analysis) in association with “model” without and then become very ambiguous because if it is well understood by the majority of real-time system analysts I think it could be misunderstood by non real-time specialist modelers. Indeed, this terms is often used in process definition too as being the development stage where the modeler specify what the system has to do. And yet, this document will be certainly read by non real-time specialists too. To avoid such confusion, I propose to explicitly write “real-time properties analysis” or something closed to that.
see above
A general convention used in the profile is to use prefix GRM, RT and SA for the names of the profiles. RT does not respect this and SA has not respect at tagged value value of stereotype SAArrivalPatternString
Closed, no change
The document has been developed assuming the UML extensibility mechanisms as proposed for UML 1.4, but this is not said until section 4.2.3. This assumption is done in the rest of the document, and the rest of the sections do not clarify this. We propose include this clarification in earlier chapters
see above
Suggest the following definition Execution Engine: "An execution engine is an active, protected, executing-type resource that is allocated to the execution of schedulable resources, and hence any actions that use those schedulable resources to execute. In general, they are processor, network or device." See issue with page 30 in section 4. This modification takes in to account the scheduling policies in networks and devices (not only processors)
AM - I agree with the suggestion
We suggest changing some multiplicities to avoid some problems. The association ExecutionEngine-SchedulingJob imposes a single ExecutionEngine to SchedulingJob. In distributed systems an schedulingjob will execute in mode than one execution engine (the modification of page 118 description of Scheduling Jobs is because of this). Some scheduling analysis techniques support alternative of responses (more than one response for each scheduling job), and more than one trigger event can generate the execution of the scheduling job.
see abopve
GRMrelase stereotype there is a spelling error.
Closed, no change
some spelling errors and remote references in second title and first line of second paragraph.
see above
definition of role "executionEngine" should be "the execution engines which realizes this scheduling job" (the same reason as modification page 113 figure 7-1).
AM - I agree with the suggestion
definition Processing Rate. We are talking about percents and we use probabilities as numbers, so suggest normative value is 100%.
AM - I agree with the suggestion
Suggest this as first sentence for definition of host "the schedulable resource that the action executes on; this is only defined if all the internal SActions that constitute the SAction execute on the same schedulable resource". This modification tries to clarify the same details that include the same definition in page 140.
AM - I agree with the suggestion
Relate different refinements of the same thing, e.g. protocol stacks
Closed, no change
Tag definitions. The domain attribute name of RTduration is wrong.
See issue 5039 for disposition
I find the use of multiple stereotypes just to get the tags required to do a simple global RMA analysis, plus all the indirection necessary. ugly, ugly, ugly. A thought occurred to me - why not highly-specific analysis subprofiles, where we would define a set of stereotypes like <<RMAG_Task>> which would be <<CRConcurrnent>>, <<SASchedulable>> and <<SAAction>> all bundled together? (RMA Global is where I got RMAG). Thus we could stereotype elements such as active objects and resources very simply. A small set of internally consistent tags with the right properties that map specifically to the kind of analysis to be perform would make the profile much easier to use.
Closed, no change
We suggest you introduce a new superclass (Executing Resource), with the following descritpion "executing resources represent any type of resource that support services for the execution of actions", to generalize the executing resources that can be included in an analysis (specially to associate this new type to the scheduling analysis metamodels, to consider the scheduling policies not only of processor resources). This affects section 7 figure 7-2.
Closed, no change
Suggest adding " In this case, the QoS characteristics and QoS value of descriptors and instance must be compatible". This addition tries to clarify that the annotations on classifier is a good technique to reuse the annotations but can create inconsistencies be-cause of inheritance (subclass and superclass have annotations incompatibles; the type of an instance in the scenarios is the superclass, but the class in exe-cution is the subclass). The same problem appears when the annotations are attached to interfaces (the interface and its implementations can have incon-sistent annotations and the real type of the instance, classified with the inter-face, is not known when we do the analysis).
closed, no change
We think that client and supplier are interchanged.
Closed, no change
description of protected resource. Suggest this for the first 3 sentences of the definition: "This is an instance of a resource that provides one or more exclusive servicesservices that can only be accessed according to an access control policy administered by an associated resource broker. (The resource broker is a role that may be played by the resource itself.) The number of concurrent services executed in the resource is bounded and in general 1". SResource in section 7 inherits of protected resource, but has associated the capacity attribute (number of permissible concurrent users). Both definitions are inconsistent.
Closed, no change
Spelling error in the title of figure
Closed, no change
What is the relation of stereotype RTtimeEvent in Figure 27 with UML 1.3 metaclass TimeEvent?
see below
What is the relation of Figure 27 with UML 1.3 DataType package and the metaclass TimeExpression
see below
The names of tagged values can create confusion, especially when we want to combine this profile with other profiles. Tagged value names as value and arg can be repeated in the profiles for the same element and this can create collisions of tagged values
Closed, no change
How do we map months/years to seconds
Closed, no change
" The properties of timing devices are listed, but some of them are not explained, and
no clue is given as to measure or represent them. This is the case for stability and skew.
In particular, the relationship between skew and offset should be explicit.
Last paragraph but one, last sentence, definition of drift: the definition does not appear
very clear to me: what can be the relative frequency of a clock between two successive
ticks? Is not the drift simply measured by (the absolute value of) the difference of fre-quencies?
(Frequency taken with the usual definition, one over the period.)
Last paragraph, last sentence: It says that a timer is always associated with a particular
clock; this is not explicit on the diagram of fig. 5-3; in fact, according to this diagram,
a timer is indirectly and implicitly associated with (at least) two clocks, one coming
through inheritance from TimingMechanism (the reference clock) and the other com-ing
through the association with TimeValue, which is itself associated with a refer-ence
clock; there is no constraint to express that these two clocks should be the same.
Should they?"
see above
A critical delay may begin at one event and end at a different one which is in a different place in the system. Time at the moment is represented in tagged values associated with stereotypes. What may be needed is a Delay stereotype, which points to the initiating event and the terminating event, and has time tags.
Closed, no change
RTtimeString should be able to represent a percentile requirement (for soft real-time systems)...a value and a percentage of responses that should meet it.
Closed, no change
The capitilzation of stereotype and tag names should be consistent
throughout the profile.
see above
Second, in the example on page 6-11
"there is a notational difference that I don't get. <<CRAsync>> is put on
the receiving instance (on TelemDataDisplay) but for the synch. invocations
<<CRSynch>> is put on the client side (TelemetryDisplayer).
'jaol@enea.se
see above
First example, on page 6-10 -
"The clock main scenario executes a MessageAction that is a <<CRImmediate>>
invocation of the TelemDataGather operation in DataGatherer. What I wonder:
Why is TG clock's life line stereotyped <<CRAsynch>>? Is it an indication
that nobody is blocking on the main scenario of TGClock?
see above
<<RTaction» This stereotype should also be associated with operations.
Agreed. Add Operation to the RTaction Base Class column in section 5.2.2.3.
There is a stereotype
called<<SAschedulable>> and a tag
definition called SAschedulable in the SAprofile package
see below
<<CRasync>>, <<CRsync>>: In my understanding, UML already includes means to represent sync
and async invocations (through the arrow shape - e.g. in RTS one can
edit the 'Timing' folder in the methods properties). Therefore, I would
consider these stereotypes as alternative to the already existing UML
notation. Nevertheless, such stereotypes are associated with the UML
notion of action (e.g. OSD::Step), what forbids combining them directly
with the methods invocations (or operations). To be more exact, I
suggest allowing these stereotypes to be associated also with operations
(see attached item 2 in (Leandro Diagrams.doc)
see below
<<CRaction>>: this stereotype should be inherited from <<RTaction>>
closed no change
PaschdPolicy uses acronyms whereas scheduling policy in theSAprofile uses full names - consider harmonizing
see above
SaschedulingPolicy references a similarly named tag - isn't this really the same tag?
Closed, no change
Should SaschedulingPolicy include a value of FIFO?
Add FIFO to enumeration for SAschedulingPolicy on page 7-18.
there should be support for scaling of time and clocks so that models can work with heterogeneous time scales (e.g., microseconds as well as days all in the same model and diagrams)
Closed, no change
Why have RSAsrvPrio when the parent supports a priority?
Closed, no change
The tag Saschedulingpolicy seems to be related to SchedulingPolicy::timeout
see above
The tag name is SaaccessControl, but the enumeration values are different, so should be different tag.
see below
In the Paprofile and Saprofile we've used Priority Range whereas here we've used High and Low priorities - consider harmonising
Closed, no change
Why have RSAclPrio when the parent supports a priority?
Closed, no change
Shouldn't a resource have an access policy, not a scheduling policy?
Closed, no change
SacontextSwitch has a tag type of Time Function - should this be RttimeValue?
Make tag type of SAcontextSwitch RTtimeValue on page 7-17.
Both this and resource have an access policy - are they in fact the same and so should have the same tag definition - if so, how do we show this?
Closed, no change
10. RT CORBA models do not identifies network resources. RT CORBA standard does not pay special attention to communication transport times (like operating system support), but an scheduling analysis that does not take into account network resources (e.g. ATM, CAN networks, or RSVP protocols) provide scheduling analysis non realistic. The profile includes comments about the operating systems dependencies but not communication transport.
see above
This example figure shows several active objects and two node instances in the same diagram. Is there a UML view that allows this? If not, perhaps the response should include this as part of a change to UML.
Closed, no change
How do I model the response time for the entire scenario when there are three independent triggers and all the messages are sent asynchronously?
Closed, no change
The concepts described in the beginning of each section in terms of a class model are later transposed in terms of stereotypes. But how are the association from the initial class model reflected in the stereotypes (which are, as I understand, the only normative part of the profile)?For example, a Resource has a set of offered QoS characteristics. How is the connection between a user <<GRMressource>> class and its corresponding <<GRMqosCharacteristics>> made in the user's model?The same question holds for all other associations. In some cases the connection is obvious informally: for example in case of a user class stereotyped with <<GRMresource>>, whose operations are stereotyped with<<GRMresourceService>>, it is clear that the operations represent the services of the resource represented by the user class. But that link is not captured formally by the metamodel / stereotype definition
see below
Most of the material presented in this chapter appears to me as rather general and
applicable to almost all kinds of UML models. Thus I do not clearly understand why
it belongs here."
Closed, no change
SAActualPty is not in the domain model, or in the tag table - is it actually needed - perhaps it is the Sapriority tag applied to a specific instance
Not needed - remove
Again, RTStimulus doesn't have a timestamp tag.
see above
RttimerPar is an RttimeValue, but presumably that only applies to instances of the service, not to the description of the service - presumably in that case, it is a reference to the formal parameter that is used to convey the new time. How should we model this?
see above
In the domain concepts for TimedInterval, we say that duration is not explicitly modelling and yet it is.
Incorrect text in section 5.1.5.5 removed
It seems odd that we have two sets of tags that model the same thing - RtintStart/Rtstart, RtintEnd/Rtend etc. Consider harmonising them
Closed, no change
It seems odd that a sub-type "Rtdelay" is more constrained than the super-type, "Rtaction", consider addressing this.
constraint on the use of RTstart and RTend has been removed
How do we formalize stereotypes and tag value constraints (e.g. Limited To) in the UML
Closed, no change
It is not clear how a QoS characteristic can be attached to a Resource. The example given throughout Chapter 4 is
{qosDeadline = 5ms}, which leaves the reader with the idea that QoS characteristics will be attached as tagged values. But later QoS characteristics are defined to be stereotyped Packages, Values, Instances or Classifiers (stereotyped with <<GRMqosCharacteristic>>), and qosDeadline turns out to be a predefined tag value without connection to the <<GRMqosCharacteristic>> stereotype. Furthermore, in Fig. 28, the QoS characteristics of a clock are defined as required tags of the RTtimingMechanism stereotype, with no mention to <<GRMqosCharacteristic>>.
closed no change
Why is GRMexclServ a tag of GRMAqcuire, is this because this particular acquire only gives access to this set of services?
Closed, no change
"Position regarding to existing UML concepts pertaining to time aspects
In the proposal, I have not really seen something about a link between the already existing UML elements that target time aspects (e.g. TimeEvent, active/passive objects, concurrent states
) and the concepts proposed by the SPT profile. I think the proposal does not position enough itself regarding to UML elements.
"
Closed, no change
Stimulus doesn't appear to have a Rttimestamp tag.
fixed; added proper inherited tags (RTstart and Rtend)
The domain attribute name of the Rtduration tag is TimedAction::probability - should be TimedAction::duration I think.
Closed, no change
The limits of the use of stereotypes are sometimes ambiguous. For example, in Fig. 28 there is a composition drawn between two stereotypes. This is not supported in UML (stereotypes are not classifiers). Inheritance between stereotypes imposes constraints on the set of metaclasses on which the stereotypes are defined. For example, how is it possible for GRMaccessControlPolicy to be defined for ActivityGraphs, while its ancestor GRMqosCharacteristic is not valid on ActivityGraphs
closed, no change
Response to RFP 6.5.6: this response is short. The model of concurrency presented in
chapter 6 is only a partial answer to 6.5.6; to complete it, it could be added that syn-chronization
mechanisms are mentioned in chapter 4 (protected resource and access
control policy). Even with this addition, we are far from the specifics of 6.5.6. At this
point a (short) sentence might be needed to justify the gap."
Closed, no change
the schedulable entity used at modeling stage may be some times not a concrete entity, It may depend on the modeling stage the modeler/user is working.
Closed, no change
In Figure 43 you include a QoS constraint to represent end-to-end response times. But it is not clear how you do this. If WCRT:80 is a tagged value, this cannot be represented in UML 1.3 because we can only associate a tagged value to a single element, and we cannot associate it to two messages, and if we do the association to the object we cannot identify the end points. Another alternative would be use constraints to represent the WCRT:80 condition (we can associate the constraint to more than one UML element), but you do not clarify this
Closed, no change
If we include SAStep in the objects to represent the messages sequences we will not respect the method used in UML 1.3, because the element stereotyped are the objects and not the messages, and we can not use the sequence activator-predecessor to define the response sequence with steps associated to objects. Another problem: If we associate more than one SAStep to the object, who defines the order? we need some kind of tagged value in the stereotype to do this.
Closed, no change
When we use SAStep intern to the objects instances (like step DD1 in diagram Figure 40) we need to identify the message sequence, and define its order. The SAStep stereotype has not associated tagged values to do this. In UML 1.3 this is represented with the associations predecessor and activator of metaclass Message.
Closed, no change
it is said that the schedulability analysis is inherently instance-based. The instance-based description is required to identify the system load (identify the active objects and their execution distributions) and data resources (objects that can be used for synchronization purposes). But the non-blocking passive objects can be analyzed description-based, and their dynamic instantiation do not affect to the analysis because their responses do not depend on the instance (but some polymorpic behaviors). The instance-based analysis does not allow analyze systems where passive objects are created dynamically (the static analysis of systems with dynamic creation of active and resource objects is a different problem).
Closed, no change
Timing Mechanisms, page 65. Typo. There is a missing word in the first line of the second-to-last paragraph.
Closed, no change
The grammar for expressing time values, and especially dates, is very much Western
time oriented. It may appear as regressive compared to time internationalization
found in modern programming languages like Java, or even C! Although what is pre-sented
here is certainly sufficient for most real time applications, it cannot serve as a
general notion of time, usable by all sorts of UML models throughout many types of
application domains.
By the way, there was not a year 0, there will be hopefully a year 10000, and there
were negative years!
Valid comment but definitely outside the scope of the RTF, closed no change
we need to clarify what the term "value-based scheduling" means (there was some disagreement on this point)
Rewrote the sentence
in fact the whole sentence could be suppressed, because it has been described in these terms before
Closed, no change
to be consistent with previous § where “thread” is only one possible example of the “schedulable entities”
Closed, no change
This paragraph mentions “value based scheduling”. This phrase however, does not appear in following pages where tag value pairs are defined for scheduling policies. Is the “MaxizeAccruedUtility” policy meant to cover value based scheduling? If so, I recommend the phrase “value based scheduling” be replaced with “utility-based scheduling”.
Add reference to utility-based scheduling as alternative nomenclature
"The schedule is the result of a scheduler implementing a scheduling policy
across a set of scheduling jobs on the execution engines that it schedules.
This sentence appears rather tautological to me and little informative. Note that it is
repeated (without increasing the information) on top of p. 114:
A scheduler is responsible for generating a schedule which is used to sched-ule
one or more scheduling jobs."
Removed offending sentence
The item labeled as "Schedulable Entity"; the sub-item "isSchedulable" may be too simplistic as a result and should perhaps support something more sophisticated (e.g., an ordered list of alternative conclusions?)
Closed, no change
"Is there any difference between Worst-case Response time and
Worst-case Completion time, or are the terms synonymous?"
Closed, no change
"One definition of Abs Deadline=Release-time + Rel Deadline,
whereas we seem to mean something else in the spec, i.e abs is used when
laxity is hard, rel is when laxity is soft"
see above
"What's the best way of representing end-to-end times across several schedulable entities;
"
see above
The sequence diagrams of Figure 43 and 42 (the Figure numbers are incorrect) include similar problems because the use pseudo sender object for the initial stimulus.
Closed, no change
In these examples, the links represent the initial events, and we could represent this concept linking an actor instance to the SAEvent Link. But if we want to represent events that are not originated by external actors (for example a cyclic object executed periodically) other solutions are need (for example a classifier stereotype like SACyclic with a tagged value that identifies the sequence message generated periodically [2]).
see below
Diagrams of Figures 40 and 41 include messages that only include a LinkEnd. UML 1.3 specifies two or more LinkEnd associated to the Link. Next Figure is part of UML 1.3 metamodel
Closed, no change
9. TimedAction defines ‘duration’ as “the time interval during which the action is occurring”. This creates confusion when is reused in SAction because I suppose that duration defines the amount of time that preemptable resources will be used in the execution of the action. ‘duration’ definitions looks like the definition of “Worst-case Completion Time” (“the overall time taken to execute the action, including all overheads”). ‘duration’ includes the overheads too? When the action is blocked or preempted, is it occurring?
Closed, no change
8. TimedAction and SAction are introduced as actions that can include subactions. In that case the priority of an action can be variable (subactions can vary their priority). Because of this, the description of priority in page 115 can create confusion.
Closed, no change
Figure 7-2 includes a direct and indirect inheritance from SAction to Scenario. Why two inheritances?
Closed, no change
The stereotype SARealTimeSituation makes reference to stereotype GRMAAnalysisContext that has been named GRMcontext
Closed, no change
The stereotypes of the others profiles are in alphabetic order.
Fix - Done
The scheduling analysis does not consider some UML concurrency parameters. Will the analyzers take in to account these attributes? Examples of these parameters are the concurrency attribute of metaclass Operation and attribute isActive of metaclass Class.
Closed, no change
Footnote: the reference to Einstein appear rather pompous to me.
reference removed
Most of behavior concepts are based on the stimulus concept that is used in UML metamodels for the description of sequence diagrams semantics, but not for other diagrams like collaboration diagrams. This creates confusion because we can think that we are talking about the concept of stimulus of UML metamodels, and I suppose that this is not the intention of the authors.
Closed, no change
This is a misunderstanding: there is no first and last event being modeled here. It has to do with the difference between reception and generation – these are two distinct concepts. (Bran)
Closed, no change
Second introductory paragraph: I agree with the idea of limiting this submission to
metric time (as opposed to logical time), but I find a little too short the justification for
the restriction. After all, real time system are also concerned by correction wrt logical
time. Moreover, at run time, logical time (as represented by interrupt events) is often
the only time of which the system is aware and that it may manipulate. This deserves
certainly consideration, even at modeling level.
Of course take this remark as from somebody whose real-time background deals
mostly with logical time!"
Closed, no change
Bullets for the definitions of Exclusive static and Exclusive dynamic: the use of the verb
to support in this context brings trouble (to me at least); it has not been used so far to
describe the relationship between clients and suppliers, and its meaning appears con-fuse
(in fact, what supports what?); May be we should stick to using the verb to real-ize."
Change made in section 4.2.1.1. "supports" replaced by "realizes"
We propose to add a link between the concepts “Service” and “Resource” (I have reappointed “RessourceService” into “Service” because it is evident due to the link). Moreover, I have reappointed also “AcquireRessource” into “AcquireService” and “ReleaseResource” into “ReleaseService” because I think it is more natural due to the fact we are describing services. Moreover, I think that a service typed “ReleaseService” is an exclusive service. Indeed, I do not think it can be executed concurrently with another “ReleaseService”.
Closed, no change
Previous model of service description allow release operation to performed concurrently and thus as being without side-effect on the resource state. For example, if you consider the Semaphore resource defind in POSIX, it get a release service so-called sem_post that modifies the resource state incrementing the semaphore value. So a release service may involve side-effect on its resource. (see. New model proposed below).
Closed, no change
have reappointed “ToleranceLevel” into “ConcurrencyPolicy” because I think this concept is more relative to concurrency issues between different services provided by a given resource. Moreover ToleranceLevel may be give indication about fault tolerance.
Closed, no change
We propose to suppress this association for following reason: It has been demonstrated (REF. MCH 94: C. McHale, “Synchronization in concurrent, object oriented languages: expressive power, genericity and inheritance.”, PhD thesis, Department of Computer Science, Trinity College, Dublin, Ireland, October 1994) that specifying mutual exclusion constraint among services by listing explicitly conflicting services penalizes maintainability, evolutivity of the system. Namely, this point leads to the question of inheritance anomaly. Indeed, it does not allow to change the interface (i.e. set of service it provides to clients) without reanalyzing whole concurrency issues. herefore, specifying concurrency constraints of services by declaring the set of used resource and their using mode (modifying, querying, ) ensures that the specification of each services remains independent. And thus it will remove the drawbacks mentioned before.
Closed, no change
There is certainly a link to do between this concept and the ”ConcurrencyPolicy” concept managing concurrent execution of services of a given a resource. But I did not find it
Closed, no change
The hierarchy of Figure 22 creates problems when we combine protection and activeness in the same resource (this is very common). An alternative is to use two tagged values in GSMResource to distinguish protection and activeness
Closed, no change
At the beginning of page 4.24 it is said “It is often useful to group sets of QoS characteristics that are related » The ideas included in page 4.25 proposes distinguish “which annotations represent required QoS and which ones are offered QoS”. The stereotype SAResource includes the tagged value SAPriorityCeiling that is an output result of some scheduling analysis tools, and the stereotype includes other required tagged values
Closed, no change
Page 4.23 paragraph 5. UML 1.3 does not describe how to refer a Model Element with tagged values (I do not know if this will be included in UML 1.4). CASE tools have problems to maintain consistencies, when we use tagged value references. Modification names are not updated in the tagged values.
Closed, no change
end of paragraph 3 two point
Closed, no change
introduces the dimension protection, “which identifies whether the device is protected against concurrent access or not”. Some resources can be qualified as protected and concurrent at the same time if the resource capacity is limited. The attribute Capacity in page 6.5 introduces the Multi-Unit objects. A good example of these kind of resources are the multi-thread objects of RT-CORBA [9]. The access is controlled with specific policies, but the concurrent access is limited. In page 4.18 the class ProtectedResource includes the attribute AccessControlPolicy ”that control access to the exclusive services
Closed, no change
According to previous remark, I change also in the Figure “Engineering Model” into “ExecutionModel”.
See issue 4990 for disposition
in this Figure, change of “Engineering” into “Execution”
See issue 4990 for disposition
Problem of ref number, 3.3, last para
Closed, no change
I do not well understand the difference between the concept of “Resource Broker” and this one of “Access Control Policy”. According to me, it is the same thing and moreover if you attache a “Resource broker” to one or more unprotected resources they become protected and are no more unprotected resource. It is the reason I propose to suppress this concept in the Figure 19.
See issue 5016 for disposition
The fourth column of the table describing the tags of «RTnewTimer» and «RTset» is not consistent with others. It is a description instead of the domain attribute name specification.
descriptions updated
I see no compelling reason to support this feature – it strikes me as being too detailed for the kinds of analyses envisaged by the profile (Bran)
Closed, no change
see document (don't know, what the issue is)
see above
A time interval is always relative; it makes no sense to talk about an absolute time interval (Bran)
Closed, no change
See document (???? what is the issue?)
Closed, no change
The approach of application of QoS characteristics from the descriptor to instances can have associated problems, when the descriptor is an interface and the interface is implemented by multiples classifiers with different implementations of methods (the descriptor of the instance can be the interface and the classes can have associated different QoS characteristics and we cannot identify the characteristics of the instances).
see above
We introduce the term “query” in order to fit to the isQuery meta-attribute of BehavioralFeature in UML specifying when true that the execution of a feature leaves the state of the system unchanged and conversely we introduce the term “modifying” to fit to the case where the isQuery value is false that is involving side-effects. This point is similar to the one pertaining to read and write operations. This new terms are just propositions and may be of course changed
Closed, no change
I do not well understand the differency between the concept of “Ressource Broker” and this one of “Access Control Policy”. As described in the sentence, it seems to me that it designates the same thing. Moreover if you attache a “Ressource broker” to one or more unprotected resources they become protected. It is the reason I propose to suppress this concept in the Figure 19.
Additional explanatory text added in section 4.1.7
Are threads and processes (at UNIX meaning) active resources? If yes (I think yes), I suggest to add an example which do not come from hardware area.
Appropriate examples were added to the text in section 4.1.6.
The term “Analysis” is very ambiguous because if it is well understood by the majority of real-time system analysts I think it could be misunderstood by non real-time specialist modelers. Indeed, this terms is often used in process definition too as being the development stage where the modeler specify what the system has to do. And yet, this document will be certainly read by non real-time specialists too. To avoid such confusion, I propose to explicitly write “real-time analysis”.
See issue 4839 for disposition
"Suggested insertion at the beginning of the section:Extracted from [5]:
« May be qualified as « real-time » every application operating a computing system which working is liable for the dynamic evolution of the environment state (so-called technique) that is linked to and which it has to control the behavior. ».
Extracted from [38]:
« Real-Time systems are those systems in which correctness of the system depends not only on the logical results of computations, but also on the time at which results are produced. ».
Both previous definitions of the term “real-time” give us following features of real-time system:
Closed, no change
The profile some concepts as stereotypes when they are concepts that could be represented with other types of UML extensions, especially constraints. Some examples are GRMqosCharacteristic and GRMaccesControlPolicy. [1,4,8] use extensively constraint to represent these concepts, the represent the concepts like response times, and control policies as constraints. The problem is the formal language for the description of these concepts in the constraints, but we can use stereotyped constraints. This mean stereotypes for constraints, these stereotypes can include the tagged values that represent the constraint parameters and the constraint can represent the characteristic [3]. We can use the stereotype inheritance to represent the inheritance of these types of constraints.
Closed, no change
item labeled "GRMscenarioStep: should the stereotype also apply to Activity?
Closed, no change
The stereotype GRMresourceUsage could be associate to BehavioralFeature to represent the resource usage in all messages or stimulus to the same operation
Closed, no change
The stereotype GRMconxtet is limited to collaboration, package and instance, but most of examples included in the proposal associate a diagram to collaborations or packages and stereotype the collaboration or package. An alternative would be to stereotype the diagrams, but it is not possible in UML 1.3. May be in UML 1.4. An alternative would be a configuration based on diagrams. If we represent the same collaboration with two alternative collaboration diagrams (two possible solutions) we can configure the analysis for a specific solution. If we stereotype the collaboration, what are we going to do? do we include both diagrams with all its elements?
Closed, no change
the composition relationship between ScenarioStep and Scenario is shown as ordered. It is not clear how this is specified in the profile.
Closed, no change
Do you plan to provide an example of that (e.g. for Rate-Monotonic Analysis)? This could be an help for further reader of the profile to understand the mechanism.
Closed, no change
item labeled "ReleaseResource" should be defined as a "non-exclusive" service rather than an "exclusive" service
Closed, no change
This should be expanded to identify what other taxonomies exist and guidelines should be added to help modelers identify how to classify specific resource types
Closed, no change
physical resource is same think that “execution engine”. Moreover, the expression “execution engine” is not present in the content of the preceding text whereas physical model it is.
Closed, no change
we add this expression definition in order to contrast with this one of “Logical model”
Closed, no change
we think that “thread” is a too much ambiguous term and propose to use “flow” instead here.
Closed, no change
we think that “thread” is a too much ambiguous term and propose to use “flow” instead here.
Closed, no change
Appendix B- Clock
Closed, no change
"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)."
"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]
"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."
"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."
6. UML extensions use tagged values to reference modeling elements. This can create problems in the consistence of the models because of the creation or destruction of modeling elements. This is not a problem specific of this profile, this is a general problem of extension techniques, but in these profiles this solutions is used very often to represent associations.
Closed, no change
In a first correction, I have mentioned I disagree with the proposed terms of “engineering model” introduced on page 34 in order to define the layer which is more technology-specific. In his reply Bran Selic answers me it was because of the RM-ODP terminology mandated by the OMG. But even if this term is conserved, we could at least put an asterisk explaining it. Because, according to my mind, people who build the logical model are also engineers, I prefer to use terms like: “operational”, “execution”, instead of “engineering”.
See issue 4990 for disposition
Modeling Resources, 2nd paragraph, page 14. This RFP response uses the phrase “required QoS” for identifying the QoS a client demands from a resource. To me, the word “required” implies an “all or nothing” response which I do not think is the right connotation if these QoS values are to be used at run time as well as during analysis. I believe that eventually we will want auto-generated software embedded with these QoS values where the values are exposed and acted upon by the run time infrastructure. In this case, clients may get less than optimal resource service. Recommend the phase “required QoS” be replaced with “desired QoS”. This phrase is used throughout the RFP response.
Closed, no change
"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."
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.
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.
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.
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).
<<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.
<<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)).
"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.:
."
clarify what is meant by "hard" real-time (i.e., is it regarding timeliness or criticality?); add examples of the types of systems that are covered.
see above
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 [medinajl@unican.es]
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"
introduces the model-processing paradigm. The problem that we find in this paradigm is that some evaluation method (included scheduling analysis) can produce result that cannot be represented with UML elements. For example graphics of resource usage, preemption diagrams and other results that cannot be represented with tagged values, that is the method used in the profile to update the results in the model.
Closed, no change
Make the notion of return values from Model Processing more explicit and potentially add new material about meta-level replies
Closed, no change
The example of priorities not being relevant to availability analysis sounds wrong (since it turned out to be quite relevant for availability in the case of the Mars Pathfinder); choose a different example that is not likely to be misunderstood
Closed, no change
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.
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 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).
“engineering” is a too much general terms that may designate any kind of enginnering activity and not especially this one that consist in designing an real-time execution model. I propose also to substitute this terms by “execution” or “operational” or “operating” or why not “real-time engineering model”
Closed, no change
The difference we understand between layered and peer interpretations is that in first case, the client is in the logical model whereas its resource(s) are part of one underlying execution model. In second case, they are at the same level of modeling. Is it right?
Closed, no change
do not know where you are within this task, but we should be interested to work with on the concurrency package?
Closed, no change
"The bibliography is abundant and relevant. It would be even more usable if there were
links in the text (I know, it’s quite a job!)."
Closed, no change
The reference should be the standard or at least should also include a reference to the standard itself
Closed, no change
Update Appendix B to align the specification with RT CORBA 2.0
see below
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;
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
"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."
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.
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
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: