The base class of stereotype <<QoSCharacteristic>> is Class. Properties and Structural Features with stereotype

<<QoSDimension>> provide support for the quantification of characteristics. The base classes of

<<QoSDimension>> are StructuralFeature and Property. The types for QoSDimensions are UML 2.0 primitive types,

enumerations, or QoS Characteristics. The metaclass Class included *Change in un* metamodel:

Qos Contract: second sentence is not a complete sentence.

The non-normative OMG document ptc/06-11-04 (06-11-04.uml2) includes a reference to a non-existent document (ecore.uml2).

In the "uml:Package" named "uml2", we have a "uml:Class" named "Element" that have a generalization reference to a "uml:Class"
href="../../eclipse/workspace2/MetaModels2/model/ecore.uml2#_Ui5E27hiEdqpTJOL-CJ2eQ".

This reference seems to be specific to a particular environment where the document 06-11-04.uml2 was exported. The reference needs to be updated to an existent one.

catastrophic is misspelled. Cannot edit the figure as is, needs to be fixed in the original figure.

Figure 11-9 SWOT Profile
Use Case is not listed in the figure.

Quality levels express the quantifiable level of satisfaction of a non-functional property. An RCC can associate quality

levels to its facets and event sinks. These quality levels are the RCC** remove 's ** quality provided contracts.

No Data Available

The facets, receptacles, event sinks, and event sources interconnect the RCC group, which collaborate to provide support of QASF. They support QASF transforming input data and events into output data and events. The QASF are the external QoS system operations, which have a quality utility associated that express the degree of satisfaction of the operation, from the user or external system point of view. The quality utility is expressed in terms of quality types and quality constraints. The grouped RCC are not quality independent in the sense that their configuration and quality provided in

their facets and event sink may limit the quality behavior of another RCC. The end-to-end quality of a qualified functionality depends on the sequence of transformations developed along the RCC sequence. For example, the end-to end latency of a video signal transformation depends on the latency of all RCC*insert s* involved in the transformation operation.

No Data Available

The attribute Qualification specifies the strictness of the constraint. The values are: Guarantee, ** chage Best Bets**-Effort, Threshold-Best-Effort, Compulsory-Best-Effort, and none.

No Data Available

QoS Contract: The quality provider specifies the quality values it can support (provider- Offered QoS) and the

requirements that must achieve its clients (provider-Required QoS). And the user, the quality it requires (client-

Required QoS), and the quality that it ensures (client-Offered QoS). ** this is not a sentence Finally**, in an assembly process, we must

establish an agreement between all constraints.

No Data Available

QoS Constraint: This is an abstract metaclass. A QoS Constraint limits the allowed values of one or more QoSCharacteristics. The QoS Constraints define the constraints of the QoS Characteristics of modeling elements. Application requirements or architectural decisions limit the allowed values of quality and the QoS Constraints

describe these limitations. QoS Context defines the QoS Characteristics and functional elements involved in a QoS Constraint. The QoS Context establishes the vocabulary of the constraint, and the QoS Constraint ** remove the** allowed values.

No Data Available

A QoS Context is described with QoS Characteristics or with the combination of other QoS Context*inser s. This means that a QoS Context that does not include **insert an*other QoS Context must be defined in terms of QoS Characteristics:

No Data Available

The characteristics of quality and their parameters are based on two types of concerns: i) user satisfaction, ** remove these** parameters are based on the user or client

No Data Available

Most modeling languages provide support for the description of functional behavior, they describe ** remove the** non-functional requirement*include s* merely using simple comments or informal structures. An example are the interfaces that provide support for the description of functional services in some modeling and interface description languages, but they do not specify nonfunctional properties of implementators. When a client defines a dependency of these interfaces, it has no information about the quality properties.

No Data Available

QoS specification languages are based on a set of constructors that provide support to describe the main QoS elements of the problem. Nevertheless, the model requires a general reference architecture. We are going to consider the QoS specification for two different abstraction levels: QoS application analysis and QoS application architecture. In the first case we analyze the QoS of the system** remove s**

No Data Available

The function ** chage does ** the quality characterization of software components or the entire system, where qi are the quality attributes of other components or external environment that affect *remove to* the quality of this component (input), r are

No Data Available

QoS Value and QoS Characteristics are specializations of QoS** change c to C** haracteristics and QoSValue

No Data Available

QoS Value: QoS Characteristics and QoS Context provide support for the description of quantifiable QoS values. However, often there are some QoS specific values identifiable at modeling time (e.g., limits of characteristics, or specific QoS values). QoS Value instantiate** insert s** QoS Characteristic and fixes it with specific values of its value definitions (QoS DimensionSlot). When we attach a QoS Value to a model element, we are characterizing the element with quality values

No Data Available

Update names in roles of QoS Metamodel to use the same name styles as in UML2 metamodels

No Data Available

QoSCompoundConstraint does not have associated a stereotype in the profile. It must be represented with some

Other QoSConstraint stereotypes, but this creates imprecision. Specific stereotype is needed to avoid this.

No Data Available

QoSRequired and QoSContract constraint based on QoS4SADemand can annotate UML 2.0 Messages, Control Flows,

Associations, and Transitions for the description of frequencies of demand of services. These UML elements have

associated implicitly or explicitly request of services from a client to a service provider, and the QoS Constraints provide

additional information for the temporal distribution of the invocations. ** Change QoS4SADemand** QoS4SADeamand include some dimensions that

No Data Available

Figure A-1**insert space ** includes the concepts of resource and resource services.

No Data Available

As seen in Figure 11-9, SWOTElement is modeled as ** Don't see this use case in the figure below UseCase** and EnterpriseAsset as Classifier.

No Data Available

QoS Metamodels in the FTF does not include relations of metaclasses and metaclasses in UML2.

This approach allows using QoS repositories in UML2 independent environments (e.g. non-UML2 QoS-aware

Modeling languages), but to do provide details about how to integrate QoS metamodels and UML2 metamodels.

Relations from QoS matamodel to UML2 would provide details about the integration of both modeling languages.

No Data Available

Again, a note to reflect on the general comments. Treatment should not be a use case. I suppose this should again be a textual element. Alternatively, you could think about a dependency to an element where the risk is being mitigated (e.g. use case, requirement and constraint).

No Data Available

The treatment options should include "Accept" since some risk assessments will accept a risk. The treatment should include a rationale (e.g. why do you accept or transfer the risk).

No Data Available

The definition of Frequency mentions a given period of time. However, we would treat the frequency as the probability of occurrence against something (e.g. system or release).

No Data Available

I think there is a major problem with this whole section. It appears that the 'mis-use cases' are the only way by which risks are defined. This is just not true and I would even suggest that it will be the least used way of identifying risks. I appreciate that there are mis-use cases (e.g. "breaking into a car"), although it could be argued that these could be seen as scenarios (e.g. Use Case is getting into the car and the scenario is "no key"). However, I suspect that most of the risks will arise from scenarios themselves. For example, a use case "configure flight plan" has scenarios involving entry of flight plan data. A risk is that the user is not trained sufficiently or the system does not verify the data. Thus unwanted incidents and threat scenarios are not use cases. I don't have a problem with mis-use cases per se, except when it is proposed as the only solution. Thus the whole profile should reflect a more generic way of capturing risk data to accommodate both the mis-use cases and the mechanisms described here (i.e. derived from scenarios). This generic notion can be reflected in fig 12-5 by defining dependencies between risks and model elements (e.g. use cases, scenarios, components and classes). The dependency has a tag to capture the rationale for the risk (i.e. RiskEvaluation is a tag).

No Data Available

The profile aims to establish risk analysis methods like HazOp, FTA and FMEA. The proposed profile does none of these. (this comment is minor if we remove the wording, but major if the wording is retained)

No Data Available

QoSDimension is defined as a feature. The examples later in the profile only specify an attribute. So, should QoSDimension be a feature or attribute?

No Data Available

It is unclear what the QoSTransition is actually providing. If the QoSLevel represents a system configuration, then this is drawn as a state diagram. Thus the states represent the system modes or configurations. Consequently, transitions are provided within the state diagram and hence I can't see what additional metaclass elements are providing. If there are reasons for QoSTransition, then it would be useful if an explanation was included

No Data Available

The RiskTheme by itself doesn't allow the type (or grading) of a risk to be specified. There can be both technical and commercial implications for a risk, but the profile only supports single values. It would be useful to enable different types (and their frequency/consequence) to be defined. This way, both commercial and technical risks can be captured with the model.

No Data Available

The RiskTheme suggests a grouping, but this is different to packaging. For example, we would define a theme (e.g. user input), but package risks according to a different criteria (e.g. user groups). Following this definition, it seems unnecessary to define RiskTheme as a specialisation of AbstractRisk. A RiskTheme sounds like a theme. It enables the user to categorise risks in some way. Values are held for each risk (frequency and consequence). It may thus be useful to consider having threshold values within the RiskTheme (for Frequency and Consequence). So, a 'user input' theme has a threshold 'low' so that you can run checks to see that all risks of this theme are also low.

No Data Available

The profile uses the phrase "Enterprise" within its definitions, but there doesn't seem to be anything special here for enterprise applications. I suggest the metaclasses are renamed by removing "Enterprise", so we have "Strength", "Weakness", Opportunity" and "Threat".

No Data Available

The class ownership should be explained

No Data Available

Risk Assessments can be defined for parts of the system. For example, a subsystem or component. However, the bias towards mis-use cases means that risks are only associated with assets and use cases. So, a more generic relationship should be defined (as stated in the comments above). I suggest using the dependency relationship to model elements.

No Data Available

A risk has a Frequency and a Consequence. We usually associate values with each of these (e.g. high, medium and low), but the profile only captures a single value for the risk. Furthermore, we also capture rational for the values (e.g. why we marked the risk as medium). However, there is no attribute (i.e. tag) to capture the rationale for the risk or its values.

No Data Available

Just a note to reflect on the comments on previous issue. Threats can be derived from scenarios, so I'm not sure of the need to define ThreatAgent as a stereotype. A Scenario is a realisation of a use case, so ThreatScenario is not a good name. At best, make this Threat.

No Data Available

It may be useful to define treatments as temporary (we often call these workarounds). This could be a boolean attribute of treatment. For example, a system may have a known deficiency in checking input data, but the treatment says 'better training'. This only applies to the current release and hence we need to eventually introduce better resolutions (i.e. treatments) before the system can be qualified.

No Data Available

The definition of RiskEvaluation is too vague. This should capture how the risk was arrived at, hence the suggestion here is that it should be a stereotype and tag (for the rationale) of a dependency

No Data Available

The definition of Risk doesn't seem to define risk. We define Risk as "an event or a series of event which, on occurring, would damage a project or business objective in terms of performance, functionality, time of delivery, acceptance or cost" I would modify this to say "damage a project, business objective or system"

No Data Available

I can see the aim of this section and it is important to keep this in the profile. In figure 8-7, the LHS of the diagram is providing compound capabilities, thus I would expect to see some association between QoSCompoundConstraint and QoSConstraint

No Data Available

We should use the phrase "QoS Provided" instead of "QoS offered".

No Data Available

Only QoS Constraints that are represented with UML constraints can be attached to more than one modelling element. To represent end-to-end QoS constraints we need to identify the source and the target of the constraint. An UML constraint is not enough to identify the source and the target.

No Data Available

think it would be good to include (at least mention) time/utility functions (TUFs) and TUF-based assurance analysis techniques. TUFs generalizes deadline constraints and TUF scheduling algorithms encompass deadline-based scheduling algorithms such as EDF/RMA in terms of timeliness behavior. Thus, I think including TUFs/TUF algorithms will increase the discussion's scope

The document implies the self-association on QoSCharacteristic (with roles Template and Derivations) is something to do with templates in UML. Some explanation here would be useful.

No Data Available

QoS Category - The document says that the QoS Category can be used to define categories such as dependability. I assume then that Quality Factors is an appropriate category, which composes of quality factors (they themselves being defined as QoS Categories). Quality factors could be associated with design characteristics (e.g. cohesion and coupling), which could be defined as QoS Category. So, I would expect an association between QoS Categories. Also, the QoSCharacteristics can be associated with multiple QoS Categories and hence the aggregation between QoSCategory and QoSCharacteristic may be better served as an association.

No Data Available

I am struggling with the notion of a constraint, whereby operators (e.g. >, < and =) are used within an expression containing QoS characteristics and class attributes. I can see that QoSCharacteristic is a specialisation of QoSContext, although QoSDimensionSlot seems an odd place to declare operators. Should the model look like: Diagram Alternatively, I assume there is a pattern within the SysML parametric model.

Specification of preemptive memory policy QoS annotated UML model characterized by stochastic-timing annotations allow to derive evaluation stochastic models that can be used to carry out verification and validation activities by means of the application of analytical methods and/or simulation techniques. When a stochastic model is characterized by activities whose duration is specified by general distributions (i.e., non negative exponential) it is necessary to associate to them memory policies that allow to decide in case of preemption whether or not to take into account of the amount of work carried out from the starting of the activity until the activity interruption.

Paragraph "Often, an end-to-end quality requirement is decomposed … " This talks about a set of Required QoS, although the set could be ordered (e.g. sequence).

No Data Available

Numbered List (point 2) - "the expressions define maximum and minimum values". I agree with the sentiment, but I can't see how the model is capturing a range (e.g. minimum and maximum) since the range itself may be associated with a QoSCharacteristic or attributes of a class. See further comments below.

No Data Available

don't understand the obsession with use cases here. A SWOT Element should not be a specialisation of a use case. A SWOT is performed for a system, not necessarily how you use it. I suggest we look for something equivalent to a Requirement (e.g. textual element), like there is in SysML

This comment is listed as minor on the assumption that the QoS Categories listed are examples (see comment above). The QoS Categories listed seem to mix different concepts, namely Software Quality Factors (SQF), Design Characteristics and general QoS (or bucket!). Examples of SQF's and design characteristics are attached to these comments. Also, we have promoted three sub-categories of Performance, namely Timing, Accuracy and Resource. The comment here is that projects will have different views on categories and it is unlikely there will be a strong consensus. I don't think the profile does this because the QoS Categories listed are not specifically in the profile, but examples. You should include these examples, but structure the lists of QoS Categories - I suggest SQF and Design Characteristics at least.

QoSConstraint is defined as a dependency. How do we show the QoS for operations and attributes? I think this may be important since components provide services using operations and attributes. Thus the constraints are applied to these (and possibly the data sent within operations).

The profile requires two stereotypes to be applied simultaneously (QoSDimension and QoSCharacteristic). This is untidy, although I can see from the examples later in the document that QoSDimension is applied to attributes when QoSCharacteristic is applied to a class. The document, at least, should include the rationale for not declaring QoSDimension as tagged values (fig 8-3 on page 11).

3rd Paragraph - "A quality model is easy to reuse in the specification of non-functional properties .." You should have a QoS for a requirement. This raises the question "Why have Categories?". Surely a model will contain packages of requirements (as being defined in SysML) and the QoS would be applied to them.

It is unclear what we are trying to achieve with this section. It seems that the section contains a lot of definitions (e.g. throughput), but the figures suggest that these are only examples. Examples are good and hence the section should be reorganised to clearly state all the categories as examples

For performance/dependability analysis the models are usually stochastics. How to specify distributions ? The "statisticalQualifier" attribute associated to a <<QoS dimension>> attribute allows to declare that the type of value of the attribute is a distribution but not the "type of distribution". On the other hand, a syntax is not given for the specification of the type of distribution as well as, in general, for complex timing values. To illustrate a possible solution let us consider a system UML model in which we want to specify the service time for two resources COM and MEM as random variables distributed according to the uniform PdF and to the negative exponential PdF, respectively. The annotation has to be as simple as possible but at the same time detailed enough to be useful for the construction of a stochastic model.

The term "QoS Level" doesn't seem right. Maybe "QoS Configuration" is better.

It may be better to call "GlobalConstraint" something like "CompoundConstraint" to avoid implications of the term 'global'.