User Tools

Site Tools


gqam_wg

Issues and Discussion

Ballot 1

Issue # Status Forum Page Resolution doc link Notes
Issue 14221 resolved 14221_resolved.doc Semantics description of TimedObserver. Also, confusion of startEvent and startObs, end also. Editorial changes to sec F10.18 and ch 15
Issue 14435 duplicate (merged with 15073) 14435_duplicate.doc Meta class BehaviorScenario not synchronized with its representation
Issue 14808 resolved 14808_resolved.doc GQAM::RequestedService has no definition
Issue 14891 resolved 14891_closednochange.doc Relationship of AnalysisContext,WorkloadBehavior, and Resources
Issue 14892 resolved 14892_resolved.doc Different multiplicities in the GQAM meta-model and profile
Issue 14909 resolved 14909_closednochange.doc Fig 15.3, step.concurRes property
Issue 14913 resolved 14913_resolved.doc Clarify semantics of of GQAM::BehaviorScenario attribute
Issue 14914 Closed, no change 14914_closednochange.doc Closed, no change
Issue 15048 resolved 15048_resolved.doc Timing Observer naming
Issue 15073 resolved 15073_resolved.doc Overloaded relationship of Scenario to Step

Ballot 2

Issue # Status Forum Page Resolution doc link Notes

Comments on issues related to GQAM

Issues with comments inline beneath each one

Issue 14221: Semantics description of TimedObserver

…minor editorial change in sec F10.18

Issue 14435: Meta class BehaviorScenario not synchronized with its representation

…change in Appendix F sec 10.3 to correspond to Fig 15.7. Merged with 15073 which changes the same figures and text.

Issue 14891: Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform

…This issue misreads the text, which is: “The top-level GQAM package shown in Figure 15.2, is organized around the concept of AnalysisContext, which represents the root of the domain model. It contains two parts that address different concerns:

“It” refers to the top-level package, not to AnalysisContext. The relationship to WorkloadBehavior and REsourcesPlatform is consistently an association, in chapters 15 16 17. AnalysisContext is the root of a tree of associations.

I suggest this be closed with no change. To convert the relationship to a composition would be a major rewrite of all three chapters, with no benefit i can see.

Issue 14892: Different multiplicities in the GQAM meta-model and profile (marte-rtf)

…In the GQAM domain model, the multiplicity of the AnalysisContext.workloadBehavior is 1. In the profile, the multiplicity of the stereotype attribute is *. Proposed resolution: align on the profile and make it *.

Agree.

Issue 14893: Align the NFP profile and domain model with the QUVD meta-model.5 Assigned to NFP WG

Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints Assigned to Time group, under discussion with them

Issue: Arrivals The mappings between the analysis arrival patterns (periodic, sporatic, ?)and Time durations, and clock constraints in CCSL should be defined in the specification.

I dont understand this issue and would like clarification. The arrival processes are an analysis concept describing something imposed on the system, or even generated by another subsystem. They are not prima facie clocks, although since they are event seequences, they have a relationship to clocks.

It would be unnatural in my view to require the definition of arrival processes through definitions of clocks. However it would be natural to allow an arrival process to be generated by a clock, which could then incorporate CCSL constraints in the clock definition. The clock could

(1) be a GaWorkloadGenerator (see Fig 15.7).

GaWorkloadGenerator is defined in 15.3.2.17 as a specialization of Behavior, so it can define the event streams by a behaviour mechanism. This might need to be modified to allow a clock to be a generator. This needs participation of a clock expert.

(2) generate a set of arrival instants defined as a TimedValueSpecification (p74), which could be associated with GaWorkloadEvent as a trace property. Again, the types need to be checked, as a trace is a set of events.

Issue 14902: Inconsistent definition of CommunicationChannel properties

…GQAM Annex F defines a CommunicationChannel.msgSize property while the meta-model and the profile defines a packetSize property. Note that the term 'packet' may not generic enough for the concept of CommunicationChannel.

Discussion: a channel is a logical entity that may be tailored to the application. Message seems to be an appropriate level of abstraction, and message size can be in bytes. I think the profile should say msgSize.

Issue 14909: In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource

… For the purposes of SAM andPAM the property is correctly typed SchedulableResource, which is a process. It needs to be schedulable to have priorities associated with it. However the association could conceivably be renamed schedRes… this would not change the profile in any substantial way.

… The benefit of generalizing the type to ConcurrencyResource is to allow other analysis profiles to associate concurency resources with no scheduler. I find it hard to envisage such a resource… where there is contention for resource, it is resolved by a scheduler, even if just FIFO. A data resource might not have significant contention… but it is surely not a concurrency resource. In any case no scheduler is an instance of scheduler, so it is not really a limitation.

There seems to be no benefit to this change, and indeed it is hard to see the benefit of the ConcurrencyResource stereotype at all. The Domain explanation on p 94 could equally apply to SchedulableResource, and it terms the scheduler a root concept.

… suggested resolution: no change

Issue 14912: Align notions of duration in NFP, Time and GQAM

Issue: The Time profile is suposed to provide a fundational timing model for MARTE. Time stereotypes are

specialized in several of profiles, such as GRM and GQAM. However, while 

time-related notions in the

analysis profiles are typed by NFP_Duration, the 

Time::TimedProcesssing.duration stereotype attribute is typed by a ValueSpecification. This type inconsitency makes between general and specialized concepts creates usability issues. Indepently of that, note that the TimedProcessing meta-class and stereotype attribute are not consistently typed, as the (normative) TimedProcessing.duration meta-class attribute? is typed by the (non-normative) CVS::DurationValueSpecification.

…Discussion: It seems to me that NFP_Duration is the natural type for durations, however the entire time chapter ignores NFPs, although time is an NFP. There are three possible resolutions:

(1) The Time chapter should be changed.

(2) If this is not practical, because it is too large a task or there are some philosophical issues that need to be resolved first, but we wnat the time chapter to govern analysis, then at the very least an alternative type of NFP_Duration should be allowed for CVS::DurationValueSpecification.

(3) If this is contrary to the meaning of time in Chapter 10, then it must be recognized that time values are not NFPs… they need interpretation, for instance through the units of their associated clock, to become NFPs. Then they are not the basis of time vales for analysis, but only for modeling functional clocks in systems.

Issue 14914: The Step.host attribute is redundant,

Issue: GQAM The Step.host attribute is redundant, given that a schedulable resource need to be related to a processor (execution host) for the analysis model to be complete and practically usable. Three alternatives for this stereotype attribute may be discussed: a) remove it, b) make it derived, c) keep it as a duplicate shortcut information. On-going discussion with Dorina and Murray on this topic

… discussion (Murray) It is useful for analysis to have such a property, either derived or input directly, when interpeting a behaviour model. I suggest that it may be input; if it is NUL as input then it can be derived; a derived value should override an input value.

…suggested resolution: to keep the attribute as a shortcut

Issue 14917: Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand

Issue: GQAM::BehaviorScenario specializes GRM::ResourceUsage. It seems that GRM::UsageDemand generalizes GQAM::WorkloadEvent. If so, make explicit this generalization relationship and consider the WorkloadEvent.timeEvent, WorkloadEvent.effect and BehaviorScenario.cause as redefined attributes

UsageDemand is defined only in the domain model of GRM and does not appear in the profile.

UsageDemand is similar to WorkloadEvent but has a different semantics and is not a generalization. WorkloadEvent describes the initiation of some behaviour (a scenario) which uses various resources; UsageDemand describes the initiation of the usage of one of those resources.

The two analysis models currently included in MARTE describe resource acquisition indirectly as part of behaviour. UsageDemand describes the event stream defined implicitly by resource acquire/release pairs. This creates an analysis relationship between WorkloadEvent and a particular UsageDemand, which could be derived by an analysis model.

UsageDemand may also have a direct application in further analysis models that may be added to MARTE, which could describe initiation of resource acquisition directly.

… suggested: no change.

Issue 15034: Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.

… the issue is not specific enough, does not name the affected diagram

… resolution:no change

gqam_wg.txt · Last modified: 2010/04/12 12:33 by admin