Issue 11706: use the stereotype <<allocated>> alone Jira Issue MARTE11-1
Issue 11767: [Time: Examples] Jira Issue MARTE11-2
Issue 11845: Runtimes may have multiple stacks Jira Issue MARTE11-3
Issue 12223: Introduce new chapter in section 6.4 Jira Issue MARTE11-4
Issue 12403: ConcurrentAccessProtocolKind Jira Issue MARTE11-5
Issue 13654: Having icons and symbols for stereotypes improves models comprehesibility Jira Issue MARTE11-6
Issue 13668: Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type Jira Issue MARTE11-7
Issue 13842: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Jira Issue MARTE11-8
Issue 14428: NfpConstraint stereotype: rename property mode to modes Jira Issue MARTE11-9
Issue 14610: Missing constraint between scheduler and scheduling parameters Jira Issue MARTE11-10
Issue 14893: Align the NFP profile and domain model with the QUVD meta-model Jira Issue MARTE11-11
Issue 14898: SwResource should be a direct specialization of Resource, like its hardware counterpart Jira Issue MARTE11-50
Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints Jira Issue MARTE11-12
Issue 14915: Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified Jira Issue MARTE11-13
Issue 15166: Specification of real time properties at "part with port" level Jira Issue MARTE11-14
Issue 15261: MARTE, sterotype <<assign>>, Jira Issue MARTE11-15
Issue 15275: The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE Jira Issue MARTE11-16
Issue 15291: ImpliesConstraint of Allocate and Assign relationships Jira Issue MARTE11-17
Issue 15310: GRM:Support for Time table driven schedules Jira Issue MARTE11-18
Issue 15432: The DurationUnitKind doesn't exist any more Jira Issue MARTE11-19
Issue 15433: The IntervalType attributes are not the same ones in the profil diagram and profil elements description Jira Issue MARTE11-20
Issue 15434: The "Mb/s" baseUnit should be "Kb/s". Jira Issue MARTE11-21
Issue 15659: Precise the shape of an array of ports of an array of parts Jira Issue MARTE11-22
Issue 15660: Constraint 6 on the tiler is just "Notation", this should be precised Jira Issue MARTE11-23
Issue 15727: The semantics of the Reshape should be precised Jira Issue MARTE11-24
Issue 16010: a verb is missed in last sentence of first � Jira Issue MARTE11-25
Issue 16012: ClientServerFeature: possible ambiguity on provided/required status of signal reception Jira Issue MARTE11-26
Issue 16158: Missing HwRouter stereotype to allow modeling of Networks-on-Chips Jira Issue MARTE11-27
Issue 16162: VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): Jira Issue MARTE11-28
Issue 16224: Coherency between active resource of MARTE and active class in UML Jira Issue MARTE11-29
Issue 16229: Typo in diagram 14.25 for stereotype SwSchedulableResource Jira Issue MARTE11-30
Issue 16247: Update Table of Contents Jira Issue MARTE11-31
Issue 16248: Page 269: Section 14.2.3.2, Stereotype Descriptions Jira Issue MARTE11-32
Issue 16583: Flow properties cannot be characterized with an RtSpecification Jira Issue MARTE11-33
Issue 16609: MARTE Clocks Jira Issue MARTE11-34
Issue 16835: Allocations kind and nature Jira Issue MARTE11-35
Issue 17339: TIME model overview: consistency of bullet descriptions Jira Issue MARTE11-36
Issue 17340: TIME model: reference to TimeStructureRelation Library does not exists Jira Issue MARTE11-37
Issue 17341: TIME model: name of referred section and name of section differ Jira Issue MARTE11-38
Issue 17342: TIME model: wrong section name Jira Issue MARTE11-39
Issue 17343: TIME model: clarification of ClockConstraint properties Jira Issue MARTE11-40
Issue 17344: TIME model: examples should be more pedagogical Jira Issue MARTE11-41
Issue 18165: Missing syncronization resource in UML mapping for PpUnit Jira Issue MARTE11-42
Issue 18249: MARTE: VSL short form for NFP_Real subtypes Jira Issue MARTE11-43
Issue 18547: Typos issues in GQAM Jira Issue MARTE11-44
Issue 18565: Refinement issue from GQAM to SAM Jira Issue MARTE11-45
Issue 18567: Questions on observators within GQAM and SAM Jira Issue MARTE11-46
Issue 18576: �GaWorkloadGenerator� and its pop attribute Jira Issue MARTE11-47
Issue 18581: About Gacenario:: Jira Issue MARTE11-48
Issue 18657: MARTE issue: Observation does not allow specification of time value Jira Issue MARTE11-49
Issue 11706: use the stereotype <<allocated>> alone (marte-rtf)
Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:
ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.
Due to lack of time, ths issue is deferred to next RTF of MARTE
[Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams
Discussion: There are ongoing discussions about the introduction of Timing Diagrams in SysML. MARTE is equipped to annotate UML Timing Diagrams. Giving a precise example in the MARTE specification might anticipate the SysML decision. So I suggest to postpone this issue for the FTF and wait for the evolution of SysML. Disposition: Deferred
Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.
Discussion: This is already possible to describe multiple stacke because the multiplicty of the staskSizeElement attribute is unlimited (concurrentResource stereotype). It seems that there is a need to describe more precisely several stacks : primiary stack, secondary stack ... One solution leads to describe an explicit "Stack" stereotype. Such solution deeply modifies the SRM chapter. Disposition: Deferred
It would be interested to introduce in the section 6.4 a chapter to explain the diferent design patterns adopted within the specification to use the UML extenssion mechanisms.
Due to lack of time we defer this issue to next RTF. Disposition: Deferred Due to lack of time, this issue is deferred to next RTF of MARTE. Disposition: Deferred
"ConcurrentAccessProtocolKind" contains several enumeration literals, one of them is "Other." With this representation, it is possible to represent ONE implicit user define protocol acces but impossible to make the distinction between various protocols defined by the end user like for exemple (ex: .Interrupt_Masking, Maximum_Priority).
This issue is more generally related to the usage of Enumerations for typing attributes of stereotypes, and the way to extend them. This is a recurrent problem when designing a profile: The enumeration literals of an Enumeration are used to capture the most representative interpretations of the aspect under study (e.g., for ConcurrentAccessProtocolKind, each enumeration literal represents a usual protocol for concurrent accesses) but one would let the possibility for users to define their own interpretations (e.g., for ConcurrentAccessProtocolKind, the literal �Other� is intended to capture such an alternative interpretation). As this problem is recurrent, it is worth taking time to have deeper discussions and propose a systematic modeling pattern to address this profiling issue. We therefore propose to defer issue 12403. Disposition: Deferred
Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.
Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type do allow to discriminate between interleaved and non interleaved multi-bank memories
Title: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Description : Consider an execution platform : a rack composed of 3 boards, each boards has a general-purpose processor and an accelerator. The rack and the board are structured classes defined with composite structure diagrams. The pseudo-code below provides an informal description of the platform: Rack { board: Board [3] } Board { gpp: GPP accelerator: FPGA } GPP {...} FPGA {...} How to precisely address the accelerator on the second board of the rack and allocate application elements on it ? The current allocation mechanism allows one to allocate an application on gpp property of the Board class but does not express that the second board is specifically designated. Due to lack of time, this issue is deferred to next RTF of MARTE. Disposition: Deferred
The property mode of the stereotype NfpCinstaint has a multiplicity [0 ..*]. To reflect that I propose to rename this latter mode to modes.
In the GRM domain model (Figure 10.11) and GRM profile (Figure 10.16), there should be a constraint that enforce consistency between scheduling parameters and the related scheduler (e.g. a task brokered by an HPF scheduler cannot have anything else than a priority - integer - as a scheduling parameter).
Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)
This issue needs further discussion with the SysML group in order to converge on the profile design of the QUVD meta-model. For timing reason, we decide to defer the resolution of this issue in order to get this time and propose a common resolution with the SysML group. Disposition: Deferred
In the SRM meta-model, the SwResource specializes ResourceManager which makes SwSchedulableResource themselves. SwResource should be a direct specialization of Resource, like its hardware counterpart.
The mappings between the analysis arrival patterns (periodic, sporatic, �) and Time durations, and clock constraints in CCSL should be defined in the specification.
UML introduce deployment concepts. MARTE introduces a notion of allocation that seem to encompass deployment-related notions (as stated in the specification). How these concepts relate to analysis attributes is left undefined in the specification at the moment. Depending on the examples one can have a look at, MARTE allocations and UML deployments seem to be used in a similar way (see Section 16.3.3 and Section 17.4). However, nothing is formally stated. Clarify whether MARTE allocations / UML deployment have the same semantics w.r.t. analysis, or not. And, if possible, make the connection with the related issue on host stereotype properties.
There is already a short discussion on the relationship between MARTE allocation and UML deployment in the specification. The issuer wanted to go more by extending the Deployment metaclass. This seems to restrict a bit the usage of the allocation stereotype and poses compatibility problems with SysML. This issue needs more discussion to be addressed properly. Disposition: Transferred to RTF 1.2
Currently HLAM::RtSpecification,RtFeature stereotypes allow modeling of real-time features for operations provided/required through ports at class level, while is not possible to use RtFeature/RtSpecifcation at "part with port" level. It would be useful to have this feature in order to be able differentiating quantitative attributes like deadline, period at part (i.e. instance) level in a composite structure diagram.
problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <<trace>>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) � thus potentially increasing the cost for interfacing models. (2) We could reuse <<assign>> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage � thus potentially increasing in usability. In this solution, stereotype <<assign>> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <<assign>> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <<assign>> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <<assign>>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R�egion Cluster. It is sponsored by the �Safe, reliable and adapted transportation� program (PREDIT) of the �Agence Nationale pour la Recherche�. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture.
The notion of "access connection" needs to be explicited in the AADL annex (A.2) of MARTE
According to its definition, the impliesConstraint association of both Allocate and Assign stereotypes should be a composition and not a simple reference
Having the opaque expresion attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule, like IMA platforms. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easyer and in a standardized way. An alternative to study may be formalizing the attribute �schedule� of a scheduler to include at least the frame_cycle_time, and the list of �windows� or �time_slots� to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.
The DurationUnitKind described in the D.2.10 NFP-Duration section, doesn't exist any more. "unit" should be a TimeUnitKind as described in the figure 8.6, page 48.
page 436, the IntervalType has the "intervalAttrib" attribute. page 451, the IntervalType has both "minAttrib" and "maxAttrib" attributes. The IntervalType attribute(s) should be the same ones.
In the DataTxRateUnitKind dimension, the "Mb/s" baseUnit should be "Kb/s" (and convFactor = 1024) or the convFactor should be 1048576 (and baseUnit = "b/s").
When a shaped port belongs to a shaped part, one should understand its shape as the product of both shapes as stated in the definition of the tiler. This should be stated here for the case when the reshape stereotype can be ommitted.
What does this "Notation" means? Either remove it or precise it.
The current specification is ambiguous and should be refined. The issue is the way the elements of the tiles are connected from one end to the other. This connection should be point-to-point.
in the sentence: ------------- Hence, the idea to associate time structure with events, behaviors, and objects, or more generally instances of the concrete subtypes of the BehavioredClassifier metaclass. ------------- it seems that a verb is missed... perhaps this could be reformulated as: --------------- Hence, the idea is to associate time structure with events, behaviors, and objects, or more generally instances of the concrete subtypes of the BehavioredClassifier metaclass.
in the following sentence: ------------ If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception. ------------ it would be more explicit to precise that signal receptions are respectively also "required" and "provided", e.g.: --------------- If kind is required it is expected to be a required operation or a required signal reception while if kind is provided, it is expected to be a provided operation or a provided signal reception. ---------------
An extension to the HwMedia stereotype should be added to allow the modeling of Networks-on-Chips in addition to buses as the become more and more the communication media of choice for new generation systems-on-chips. This HwRouter stereotype could have the following attributes: + fifoSize: NFP_DataSize + isRoutingAdaptative: NFP_Boolean + switchingType: SwitchingType + isSynchronous: NFP_Boolean + fifoLocation: FifoLocationSpecification with the following definition of SwitchingType: �Enumeration� SwitchingType paquetSwitching circuitSwitching other undefined and of FifoLocationSpecification: �Enumeration� FifoLocationSpecification input output both
VSL, Section B.3.3.9. The following attributes are missing (see figure B.7): baseType : VSL::DataTypes::DataType [1] Designates an ordered DataType. .. isMinOpen: Boolean [0..1] Defines if minValue is excluded in the bounded value space. isMaxOpen: Boolean [0..1] Defines if maxValue is excluded in the bounded value space.
In GRM, a Resource may be active. MARTE needs to specify the relationship(coherency) between an active resource and and active class.
Attribute schedulers : NamedElement [1] of SwSchedulableResource should be "scheduler : NamedElement [1]"
Updated Table of Contents to reflect topics according to updated formatting
Add the following : McProcessor The McProcessor stereotype maps the McProcessor domain element Generalizations HwProcessor Attributes Core_Id: NFP_Natural
The type of the derived property RtSpecification::context is BehavioralFeature. It can be used to specify that the RtSpecification actually concerns a particular behavioral feature (i.e. Operation or Reception) exposed by a port (the port being identified by the RtFeature owning this RtSpecification). This works well with ClientServer ports. However, it cannot be used to characterize flow properties of FlowPort, since a FlowProperty is a StructuralFeature, not a BehavioralFeature. An easy solution to address that is to make the type of /context Feature, instead of BehavioralFeature.
In the time chapter, I was reading the following sentence in clause 9.3.1.1: �When the property "on" is not specified, it should be understood as being by default, a dense chronometric clock with no flaws that represent the physical time.� However, the lower bound of the multiplicity of the on role from TimedElement to Clock is one, meaning that one value at least has to be specified. May the aforementioned sentence should be repharsed, isn�t?
There are many possible usages for the Allocation concept which cannot be restricted to those listed in the AllocationKind and AllocationNature enumerations. The �kind� and �nature� attribute of both <<Allocate>> and <<Assign>> stereotypes should be optional (multiplicity: [0..1]). Alternatively, a literal could be added to the enumerations named above, such as �unspecified� or �other�, to address usages which are not covered by the existing literals.
problem: In section Overview of the time model chapter, there are three bullets to describe the time. In these bullet titles, the slash ('/') character has different meaning: * Causal/temporal --> it should be understood as causal vs temporal * Clocked/synchronous --> it should be understood as Clocked or synchronous * Physical/real-time --> it should be understood as Physical or real-time proposed resolution: the bullet should be renamed with: * Causal (untimed): * Synchronous (partially timed): * Physical (real-time): additionally, to keep consistency, the last sentence of the last bullet should be rephrased, for instance with : "Physical time models refine the partially timed models by adding reference(s) to one or more physical dimensions, for instance to derive the admissible speed of a reaction."problem: In section 9.2.2.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Predefined time base relations are suggested in the TimeStructureRelation Library of MARTE. The semantics of these relations is given in OCL.". However, the TimeStructureRelation Library does not exist in the specification. proposed resolution: There exists a description of predefined time base relations in the annex C. We propose to modify the text as well as the example depicted figure 9.7 to conform with the existing predefined time base relations.
problem: In section 9.2.4.2 (concrete time base relations) of the time model chapter, there is the following sentence: "Clock constraint specifications are special value specifications described in Annex C (Clock Constraint Specification Language)". However, the reference should be to annex C.3 and the named of annex C.3 is "Clock Constraint Specification". proposed resolution: change annex C to annex C.3 in the text of chapter 9.2.4.2. rename the annex C.3 as "Clock Constraint Specification Language"
problem: Section 9.2.4.5.2 is named "The timeEvent Package". It should be named "The TimedEvent Package" proposed resolution: rename section 9.2.4.5.2 as "The TimedEvent Package"
problem: In section 9.3.1.3, on figure 9.28, the ClockConstraint stereotype have three properties named "isCoincidenceBased", "isPrecedenceBased", "isChronometricBased". These three attributes refers to the kind of relation(s) resulting from the constraint enforcement. This kind of relation are described by three named bullets in the time model overview, chapter 9.1. The name of the bullets and the name of the properties should conform. These properties are described in section 9.3.2.2, the names should also refer to the bullet names. proposed resolution: rename the properties of the ClockConstraint stereotype to conform with the name of the bullet in section 9.1. The section 9.3.2.2 should be kept consistent with such changes.
problem: In section 9.3.3 (Examples) from the time model, the examples describe some complex and pathological cases, which reflect the good expressiveness of the time model. These examples should perhaps be simplified to help the reader understanding classical/intended use of the time model in its design.
We have detected an inconsistency between the semantic description and its mapping to UML for Protected Passive Unit (PpUnit). In figure 13.3 and in the Annex F.7.7, PpUnit inherits from BehavioredClassifier and SynchResource. But when you see the UML Representation (Section 13.3) in Figure 13.8, the PpUnit inheritance from BehavioredClassifier is taken into account by using it as the base elements to be extended with the stereotype. Its nature as synchronization resource is not explicitly mapped to UML. For these reasons, and considering the need to link a PpUnit with its implementing mutual exclusion resources that we propose a PpUnit to have an additional attribute (with multiplicity 0..n) that includes the MutualExclusionResource that the existence of the PpUnit implies. Being a GRM:: MutualExclusionResource a specialization of SynchResource, this attribute maps the synchronization resource nature of the PpUnit as it is expressed in its definition in the Annex F.
There are numerous examples in the MARTE spec that show the use of tuple value expressions of the form (v, u), where v is the value and u is the unit (e.g., (50, ms)) to specify the value of a subtype of NFP_Real (e.g., NFP_Duration, NFP_Weight, etc.). However, based on how tuple expressions work, this is not valid, since, without additional information, the parser cannot know which attributes are being assigned these two values. Note that subtypes of NFP_Real can have many attributes (e.g., NFP_Duration has 11 attributes) and most of them have at least two Real-type attributes. Based on that, in an expression such as (50, ms), it is not possible to determine which attribute is being assigned the value 50 (e.g., in case of NFP_Duration, it could be either the "value" attribute, the "precision" attribute, the "worst" attribute, or the "best" attribute). VSL does allow label-less expressions of this type, but, that can only work if the list of values follows the order in which the attributes appear (which, actually, is not quite clear from the spec), and if the use of the default or null literals is used for entries that are not assigned. For example, for an NFP duration of 50 milliseconds, the proper lable-less expression looks like it should be: (null, null, null,null, null, 50, ms, null, null, null, null), or, alternatively (-, -, -, -, -, 50, ms, -, -, -, -). Clearly, this is far too cumbersome for practical application. One possible solution is to have VSL recognize the special and most common by far case of subtypes of NFP_Real, allowing a short form in cases where only the value and unit need to be specified (leaving the other attribute values to default). This short form would, naturally, be the (v, u) form. That would make the common form currently used in the spec valid.
Diagram shown in 15.7 contains a set of inconsistencies: - Multiplicity of GaWorkloadEvent::cause is 1 and not [0..1] - Change GaWorkloadEvent::timeEvent: timeEvent into �GaWorkloadEvent::timeEvent: TimeEvent� - Multiplicity of the GaScenario::cause property is [1..*]. This multiplicity shall be shown on the diagram. - Type of GaScenario::timing should be GaTimedObs instead of GaTimingOberver that does not exist anymore. - The association between GaWorkloadEvent and TimeEvent should be removed. p. 300, in the attributes section of the �15.3.2.2 GaAnalysisContext�, ref to B.3.3.12 should be B.3.3.13. p. 309, as denoted in the diagram shown in Figure 15.7, �effect:GaScenario [1]� should be listed in the attributes section and not in the list of associations.
The domain model of SAM defines the concept of EndToEndFLow which is described as being a container for a set of request event streams that trigger processing flows (identified as WorkloadEvent in the figure 16.3) and a set of end-to-end execution scenario (identified as BehaviorScenario in the figure 16.3) as response to a related set of request event stream. The domain model of GQAM defines the of WorkloadBehavior which is described as being a container for a set of behaviors defined as Scenario and a set of demands defined as WorkloadEvent. WorkloadEvent are defined as the cause of the Scenario. In this context, this latter is considered as being the effect of a WorkloadEvent. This specification raises both next issues: - Firstly, the stereotype �SaEndToEndFLow� introduced to map the SAM domain model element EndToEndFLow does not have properties fitting the endToEndStimuli and endToEndResponse properties of this latter. Consequently, the specification of stimuli and responses of a SaEndToEndFlow has to be done implicitly within the user model using containment relationships of the UML. The issue with such modeling mean is that the relationship between the SaEndToEndFlow and its containment is less formal and relies on specific means/choices to model the link between the SaEndToEndFLow and its stimuli and scenarios. - Secondly, the duality between both concepts, EndToEndFLow and WorkloadBehavior, seems to introduce unnecessary complexity. I would like to propose to define EndToEndFlow as a specialization of WorkloadBehavior, where both endToEndStimuli and endToEndResponse would refine respectively demand and behavior properties of the WorkloadBehavior concept. Miscellaneous: - In figure 16.3, EndToEndFLow has an association toward SAM_Obsrever::TimedObserver. A priori, it should be SchedulingObserver instead of TimedObsever. - In section �16.3.2.7 SaSchedObs�, SaSchedObs should inherit from GaTimedObs and not TimedObs as shown in figure 16.8. - In section �16.3.2.1 SaEndToEndFlow�, the timing attribute should be typed as SaSchedObs and not TimedObs.
I was wondering, why two kinds of observators was designed within the GQAM as denoted in the figure shown below: Why not gathering both into one single stereotype? I propose to keep the second one, GaLatencyObs. In addition, I was also wondering why the <<SaSchedObs>> stereotype defined within SAM was not inheriting from <<GaLatencyObs>> instead of <<GaTimedObs>>? What do you think?
Can someone clarify the meaning of the pop attribute of the �GaWorkloadGenerator� stereotype?
GaScenario has the attribute utilization. Its definition is : �The occupancy of the scenario, computed as the mean number of scenario instances active at any one time.�. What does �occupancy� mean?
In the current UML metamodel, there is no link from the metaclass Observation to a ValueSpecificaiton that can be used to specify the time value of the Observation. As a result, it is not possible to directly assign time values to TimedInstantObservation or TimedDurationObservation. This means that it is not possible to refer to the time values of such observations in a time expression. One easy solution is to create an association from the TimedObservation stereotype to the UML ValueSpecification metaclass (role name "value"). This could then be used to store the time value associated with either kind of time observation.