Issue 7792: QoS Constraints
Issue 7793: QoS Category
Issue 7794: fig 8.3 - add explanation
Issue 7795: Section 8.3
Issue 7796: Section 8.3 clarification
Issue 7797: We should use the phrase "QoS Provided" instead of "QoS offered".
Issue 7801: association between QoSCompoundConstraint and QoSConstraint
Issue 7802: It is unclear what the QoSTransition is actually providing
Issue 7803: should QoSDimension be a feature or attribute
Issue 7809: Profile issue
Issue 7810: Section 12
Issue 7811: The class ownership should be explained
Issue 7812: figure 12.3
Issue 7813: figure 12.5
Issue 7814: suggest using the dependency relationship to model elements.
Issue 7815: The RiskTheme suggests a grouping, but this is different to packaging
Issue 7816: type (or grading) of a risk
Issue 7817: The definition of Risk doesn't seem to define risk.
Issue 7818: The definition of RiskEvaluation is too vague.
Issue 7819: Section 12.1.4
Issue 7820: The treatment options should include "Accept"
Issue 7821: define treatments as temporary
Issue 7823: figure 12-10
Issue 7824: figure 12-12
Issue 10389: Relations of QoS Metamol metaclasses and UML2 metaclasses
Issue 10390: QoSCompoundConstraint in the profile
Issue 10391: update name styles in QoS metamodels
Issue 10392: Page 5 third paragraph 3
Issue 10393: Paragraph 5:
Issue 10394: Paragraph 6
Issue 10395: Paragraph 7:
Issue 10396: Page 6 paragraph 4
Issue 10397: Paragraph 5:
Issue 10398: Page 11 paragraph 3
Issue 10399: Paragraph 4:
Issue 10400: Page 13 paragraph 1
Issue 10401: Paragraph 3:
Issue 10402: Page 14 Paragraph 8
Issue 10403: Page 15 Paragraph 3
Issue 10405: Page 54 paragraph 1:
Issue 10406: Page 77 paragraph 3:
Issue 10407: Page 79 paragraph 79
Issue 7792: QoS Constraints (uml-qos-ft-ftf)
Click here for this issue's archive.
Source: Universidad Politecnica de Madrid (Dr. Miguel A. de Miguel, mmiguel@dit.upm.es)
Nature: Enhancement
Severity: Significant
Summary:
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.
We have included in metamodel and profile elements for the identification of source and target
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.
A new type of relation between QoS Categories represents dependencies between categories. In case of models of quality this relations defines dependencies between quality models.
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.
Discussion: Figure 9-6 and its paragraphs explain this mapping. Disposition: Closed, no change
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.
The range can be represented with several approaches. An example is to use statistical qualifiers to identify the minimum and maximum qos dimensions Following chapters and sections include several examples. Disposition: Closed, no change
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).
New notations improve the description of end-to-end constraints decomposition
We should use the phrase "QoS Provided" instead of "QoS offered".
QoS offered is a well established term in other QoS standards. ISO15935 was a basic reference in the RFP and we have used this and other ISO standards as basic source of terminology. Disposition: Closed, no change
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
The associations are included in Figure 8.6. Disposition: Closed, no change
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
We introduce a new attribute in the QoSTransitions to support the description of the set of actions. We do not specify the concrete syntax for language used for the description of these actions.
QoSDimension is defined as a feature. The examples later in the profile only specify an attribute. So, should QoSDimension be a feature or attribute?
Some times the dimension can be represented with methods. Figure 10-10 includes an example. Disposition: Closed, no change
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)
The profile gives notations to model risk analysis. But it does not propose mappings or specific analysis methods. The extended models can be used to generate very different analysis models, but we do not give specific solution for this transformation of models
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).
The purpose of the misuse cases is to make the scenarios containing misuse explicit at the use case level. A misuse case may of course be refined into several scenarios, as with use cases. This is no less generic that deriving risks from scenarios; the difference is an explicit grouping of scenarios into those that contain misuse and those that don't. Disposition: Closed, no change
The class ownership should be explained
The name of the meta-class "Ownership" is changed to "Interest", and the following text is added: "Interest: The relationship between a stakeholder and an asset identified by that stakeholder" This also means changes in the metamodel, in the profile and in the example..
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".
The word "enterprise" was included to emphasis that SWOT is carried out at the enterprise or business level.
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.
As risk is defined in the profile, it may have a frequency value, a consequence value and a risk value (see example in figure 12-17). 2. Capturing the rationale of values is useful, and the profile supports this in the sense that the stereotype <<ValueDefinition>> is undefined/underspecified in the profile. When applying the stereotype as the example in figure 12-13, an additional attribute "description" or "rationale" may be added. Disposition: Closed, no change
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.
Assets are the means for specifying what has value in the system and identification of assets will define the parts of the system that should be assessed. Without assets there is no need for risk assessment. Misuse cases are a means for high level modelling and representation of risks (threats and unwanted incidents). This does not mean that only use cases may be assessed, but that the results of an assessment is represented as misuse cases that, as with normal use cases, may be refined in other models. Disposition: Closed, no change
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.
Risk themes are categorizations of risks without any constraints on the categorization. The reason for this is to have full flexibility in the categorization. The reason for defining RiskTheme as specialization of AbstractRisk is that it sometimes is useful to define treatment relative to risk themes, while insisting that a theme is related to a single asset is too constraining. Risk evaluation criteria are related to abstract risk, but are in general underspecified in the meta model, so they may be defined with full flexibility. Disposition: Closed, no change
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.
One of the main ideas of the profile is that risks are defined relative to stakeholders. Technical and commercial issues are different stakes and therefore relative to different stakeholders. An unwanted incident that has technical and commercial implications will for that reason be identified as two risks with their respective values. Disposition: Closed, no change
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"
This proposed definition is equivalent to the definition of unwanted incident: "An undesired event that may reduce the value of an asset" The definition of risk: "An unwanted incident that has been assigned a consequence value, a frequency value and a resulting risk value", is based in the definition in AS/NZS 4360: 1999 "Risk; the chance of something happening that will have an impact upon objectives. It is measured in terms of consequence and likelihood". Disposition: Closed, no change
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
This is meta-data that have no place in a UML model, but belong to the documentation of the risk assessment process. The stereotype <<ValueDefinition>> is undefined/underspecified in the profile and the values may be defined in any way the user of the profile prefers. Disposition: Closed, no change
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).
The stereotype <<ValueDefinition>> is undefined/underspecified in the profile and the values may be defined in any way the user of the profile prefers.
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).
Treatment option "Retain" added. Rationale should be treated as other "textual elements", see comments on issues 7813 and 7818.
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.
This is not a fundamental attribute of a treatment. Such attributes can be added to treatments without having them present in the meta-model. Disposition: Closed, no change
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.
Scenarios often involve agents, and "Threat" is sometimes understood as an agent and sometimes a scenario. "ThreatAgent" is changed to "Threat" but ThreatScenario are kept to make explicit what is what. A ThreatScenario is a high level representation of a (set of) scenario(s), and there is no reason to not call it a threat scenario. Disposition: Closed, no change
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).
Treatments are part of the functions a system performs, and there is no reason that shouldn't be represented as a use case. Again, the idea behind a graphical language is to represent things graphically (see earlier comments). Disposition: Closed, no change
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.
Resolution: The new model includes some inheritances and associations to UML metamodel. The inheritances allow including QoS modeling elements (e.g. QoS categories or characteristics) as contents of UML modelling elements. The associations to UML modeling elements allow navigating to UML elements related with the QoS modelling elements. In the profile, these associations are included as stereotype associations
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.
Resolution: QoSCompoundConstraint stereotype has been included. The QoS profile model has been updated with UML 2.1 approaches. The main difference is the method to represent stereotype properties that reference other stereotypes or modelling elements. In this approach we use associations based on UML 2.1 modification in profile chapter (Page 693 ptc06-01-02): Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass. Currently there are not too many tools that support the properties of stereotypes to other stereotypes (we don't know any tool public available). The profiles that accompanies to this document implement the associations of stereotypes as properties which type is the base element of the other stereotype. These properties should be only the stereotype or the model element annotated with the stereotype.
Update names in roles of QoS Metamodel to use the same name styles as in UML2 metamodels
Resolution: To make compatible QoS repositories and UML2 repositories, we have updated style of roles and we have changed some names to avoid compilation errors when we generate QoS repositories with eMOF tools. Styles of names are the same as UML2.
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.
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
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
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**
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.
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.
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
QoS Value and QoS Characteristics are specializations of QoS** change c to C** haracteristics and QoSValue
Discussion: UML Profile for Scheduling Time and Performance uses the term QoScharactereistic. Disposition: Closed, no change
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:
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.
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.
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.
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.
Figure A-1**insert space ** includes the concepts of resource and resource services.
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