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>>.
"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."
"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.:
."
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"
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).
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: