UML Profile for Modeling QoS and FT Avatar
  1. OMG Specification

UML Profile for Modeling QoS and FT — Closed Issues

  • Acronym: QFTP
  • Issues Count: 24
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
QFTP-41 figure 12-12 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-40 figure 12-10 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-39 define treatments as temporary QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-38 The treatment options should include "Accept" QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-37 Section 12.1.4 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-36 The definition of RiskEvaluation is too vague. QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-35 The definition of Risk doesn't seem to define risk. QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-34 type (or grading) of a risk QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-33 The RiskTheme suggests a grouping, but this is different to packaging QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-32 suggest using the dependency relationship to model elements. QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-31 figure 12.5 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-30 figure 12.3 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-29 The class ownership should be explained QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-28 Section 12 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-27 Profile issue QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-26 should QoSDimension be a feature or attribute QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-25 It is unclear what the QoSTransition is actually providing QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-24 association between QoSCompoundConstraint and QoSConstraint QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-23 We should use the phrase "QoS Provided" instead of "QoS offered". QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-22 Section 8.3 clarification QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-21 Section 8.3 QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-20 fig 8.3 - add explanation QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-19 QoS Category QFTP 1.0b1 QFTP 1.0 Resolved closed
QFTP-18 QoS Constraints QFTP 1.0b1 QFTP 1.0 Resolved closed

Issues Descriptions

figure 12-12

  • Key: QFTP-41
  • Legacy Issue Number: 7824
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 12-10

  • Key: QFTP-40
  • Legacy Issue Number: 7823
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

define treatments as temporary

  • Key: QFTP-39
  • Legacy Issue Number: 7821
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The treatment options should include "Accept"

  • Key: QFTP-38
  • Legacy Issue Number: 7820
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.1.4

  • Key: QFTP-37
  • Legacy Issue Number: 7819
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The definition of RiskEvaluation is too vague.

  • Key: QFTP-36
  • Legacy Issue Number: 7818
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The definition of Risk doesn't seem to define risk.

  • Key: QFTP-35
  • Legacy Issue Number: 7817
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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"

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

type (or grading) of a risk

  • Key: QFTP-34
  • Legacy Issue Number: 7816
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The RiskTheme suggests a grouping, but this is different to packaging

  • Key: QFTP-33
  • Legacy Issue Number: 7815
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

suggest using the dependency relationship to model elements.

  • Key: QFTP-32
  • Legacy Issue Number: 7814
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 12.5

  • Key: QFTP-31
  • Legacy Issue Number: 7813
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 12.3

  • Key: QFTP-30
  • Legacy Issue Number: 7812
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The class ownership should be explained

  • Key: QFTP-29
  • Legacy Issue Number: 7811
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    The class ownership should be explained

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12

  • Key: QFTP-28
  • Legacy Issue Number: 7810
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile issue

  • Key: QFTP-27
  • Legacy Issue Number: 7809
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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)

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

should QoSDimension be a feature or attribute

  • Key: QFTP-26
  • Legacy Issue Number: 7803
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

It is unclear what the QoSTransition is actually providing

  • Key: QFTP-25
  • Legacy Issue Number: 7802
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

association between QoSCompoundConstraint and QoSConstraint

  • Key: QFTP-24
  • Legacy Issue Number: 7801
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: QFTP-23
  • Legacy Issue Number: 7797
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3 clarification

  • Key: QFTP-22
  • Legacy Issue Number: 7796
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

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

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3

  • Key: QFTP-21
  • Legacy Issue Number: 7795
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fig 8.3 - add explanation

  • Key: QFTP-20
  • Legacy Issue Number: 7794
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QoS Category

  • Key: QFTP-19
  • Legacy Issue Number: 7793
  • Status: closed  
  • Source: BAE SYSTEMS ( Kevin Dockerill)
  • Summary:

    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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QoS Constraints

  • Key: QFTP-18
  • Legacy Issue Number: 7792
  • Status: closed  
  • Source: Universidad Politecnica de Madrid ( Miguel de Miguel)
  • 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.

  • Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — QFTP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT