UML Testing Profile 2 Avatar
  1. OMG Specification

UML Testing Profile 2 — All Issues

  • Acronym: UTP2
  • Issues Count: 12
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLTP22-4 Harmonize illustration of property modifiers in the spec UTP2 1.0b1 $issue.fixedSpecification.name Deferred closed
UMLTP22-9 Group abstract syntax diagram in separate sub-section for better changeability of the spec UTP2 1.0b1 $issue.fixedSpecification.name Deferred closed
UMLTP23-22 Harmonize illustration of property modifiers in the spec UTP2 1.0b1 open
UMLTP23-23 Group abstract syntax diagram in separate sub-section for better changeability of the spec UTP2 1.0b1 open
UMLTP22-8 Cleanup Figure 8.15 - Test-specific actions Overview UTP2 1.0b1 $issue.fixedSpecification.name Resolved closed
UMLTP22-7 Change bar in section 8.6.1 Data Specifications need to be removed UTP2 1.0b1 $issue.fixedSpecification.name Closed; No Change closed
UMLTP22-10 Arbitration specification binding mechanism restricted to only one arbitration specification UTP2 1.0b1 $issue.fixedSpecification.name Resolved closed
UMLTP22-6 Last paragraph of Clause 8.6.2 Data Values needs to be removed UTP2 1.0b1 $issue.fixedSpecification.name Resolved closed
UMLTP22-5 Unnecessary linebreak between first and second paragraph of Clause 8.7.1 Arbitration Specifications UTP2 1.0b1 $issue.fixedSpecification.name Closed; No Change closed
UMLTP21-19 Correct XMI files and URI of machine-readable files for UTP 2.1 UTP2 1.0b1 UTP2 2.1 Resolved closed
UMLTP2-33 Multiplicity of ID for TestSet and TestContext should be 0..1 UTP2 1.0b1 UTP2 2.0 Resolved closed
UMLTP2-37 TestContext.testLevel and TestContext.testType ought to allow for an upper bound of * UTP2 1.0b1 UTP2 2.0 Duplicate or Merged closed

Issues Descriptions

Harmonize illustration of property modifiers in the spec

  • Key: UMLTP22-4
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The current document generation process used to produce the UTP 2 specs is limited with respect to the illustration of property/association end modifiers (i.e., unique, ordered, redefines, subsets, read-only, union). According to UML, those modifiers shall be illustrated after der name and type and multiplicity of a property. The following grammar rule (taken from UML 2.5, Clause 9.54) specifies the textual notation of properties:
    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘<prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

    In the UTP 2 document generation framework the illutration of modifiers was circumvented in a way that is is close to, but different to the notation prescribed by UML. Although, the aligned notation of UTP 2 is okay from a readers point of view, it appears that the modifiers have not been consistenly illustrated. See two examples from the spec:

    In section 8.3.2.7.17 TestDesignDirective , TestDesignDirective modifies are displayed before the name of the propery:

    {read-only, union} subDirective : TestDesignDirective [*]

    In section 8.4.2.5 TestConfigurationRole, modifiers are displayed after the name of the property:
    /roleConfiguration {read-only, union}

    : RoleConfiguration [*]

    Even though both ways are still good enough to comprehend, from an editorial point of view, one way should be preferred to other.

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:31 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    Deferred due to lack of time

    The RTF agreed that this a valid, but pure editorial issues. As explained in the issue description, the reason for these varying property modifiers lies in the document generation framework. Since all required information is available, though, the RTF agreed to resolve this issue in a future RTF.

  • Updated: Fri, 5 Jan 2024 20:27 GMT

Group abstract syntax diagram in separate sub-section for better changeability of the spec

  • Key: UMLTP22-9
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In the current spec, the abstract syntax diagrams reside in dedictated sub-sections directly underneath the conceptual context section (e.g., 8.7.2. Test Logging) they belong to. Stereotype definitions of ths conceptual context are grouped in a dedicated sub-section 'stereotype definitions'.

    In UTP 2.1 RTF turned out that this structure does not support maintainability and modifiability of the spec. Everytime an additional diagram is added to the conceptual context section (maybe due to enhacements, clean-ups, better seperation and illustration of complex diagrams), the entire stereotype definitions need to be renumbered, because the respective diagram sub-sections and the 'stereotype specification' sub-section reside on the same level.

    If the abstract syntax diagrams would be sub-sections of a section called 'Abstract Syntax', there would be no need to renumber stereotypes.

    Therefore, I propose to make the spec more maintainable and stable by incoporating the following structure for every concepual context section in the spec.

    8.7. Test Evaluation
    8.7.1 ArbitrationSpecifications
    8.7.2 Test Logging
    8.7.2.1 Abstract Syntax
    8.7.2.2 Stereotype Specfications

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:15 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    Deferred due to lack of time

    The issues requests a pure editorial change for better maintainability of the specifcation. The RTF agreed that the proposed change makes sense, but due to lack of time, the resolution of that issue will be resolved in a future RTF.

  • Updated: Fri, 5 Jan 2024 20:27 GMT

Harmonize illustration of property modifiers in the spec

  • Key: UMLTP23-22
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The current document generation process used to produce the UTP 2 specs is limited with respect to the illustration of property/association end modifiers (i.e., unique, ordered, redefines, subsets, read-only, union). According to UML, those modifiers shall be illustrated after der name and type and multiplicity of a property. The following grammar rule (taken from UML 2.5, Clause 9.54) specifies the textual notation of properties:
    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘<prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

    In the UTP 2 document generation framework the illutration of modifiers was circumvented in a way that is is close to, but different to the notation prescribed by UML. Although, the aligned notation of UTP 2 is okay from a readers point of view, it appears that the modifiers have not been consistenly illustrated. See two examples from the spec:

    In section 8.3.2.7.17 TestDesignDirective , TestDesignDirective modifies are displayed before the name of the propery:

    {read-only, union} subDirective : TestDesignDirective [*]

    In section 8.4.2.5 TestConfigurationRole, modifiers are displayed after the name of the property:
    /roleConfiguration {read-only, union}

    : RoleConfiguration [*]

    Even though both ways are still good enough to comprehend, from an editorial point of view, one way should be preferred to other.

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:31 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

Group abstract syntax diagram in separate sub-section for better changeability of the spec

  • Key: UMLTP23-23
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In the current spec, the abstract syntax diagrams reside in dedictated sub-sections directly underneath the conceptual context section (e.g., 8.7.2. Test Logging) they belong to. Stereotype definitions of ths conceptual context are grouped in a dedicated sub-section 'stereotype definitions'.

    In UTP 2.1 RTF turned out that this structure does not support maintainability and modifiability of the spec. Everytime an additional diagram is added to the conceptual context section (maybe due to enhacements, clean-ups, better seperation and illustration of complex diagrams), the entire stereotype definitions need to be renumbered, because the respective diagram sub-sections and the 'stereotype specification' sub-section reside on the same level.

    If the abstract syntax diagrams would be sub-sections of a section called 'Abstract Syntax', there would be no need to renumber stereotypes.

    Therefore, I propose to make the spec more maintainable and stable by incoporating the following structure for every concepual context section in the spec.

    8.7. Test Evaluation
    8.7.1 ArbitrationSpecifications
    8.7.2 Test Logging
    8.7.2.1 Abstract Syntax
    8.7.2.2 Stereotype Specfications

  • Reported: UTP2 1.0b1 — Fri, 10 May 2019 10:15 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

Cleanup Figure 8.15 - Test-specific actions Overview

  • Key: UMLTP22-8
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    "Figure 8.15 - Test-specific actions Overview" needs to be cleaned up. Stereotype shapes are overlapping.

  • Reported: UTP2 1.0b1 — Wed, 19 Jun 2019 13:46 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Replace Figure 8.15 with new figure

    RTF agreed to correct this pure editorial issue.

  • Updated: Fri, 5 Jan 2024 20:12 GMT
  • Attachments:

Change bar in section 8.6.1 Data Specifications need to be removed

  • Key: UMLTP22-7
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    There is an obvious misplaced change bar marker in the beginning of section "8.6.1 Data Specification". It needs to be removed.

  • Reported: UTP2 1.0b1 — Wed, 19 Jun 2019 13:50 GMT
  • Disposition: Closed; No Change — $issue.fixedSpecification.name
  • Disposition Summary:

    Changebar not present anymore in UTP 2.1 official document

    This pure editotial issue has been already fixed with the release of the UTP 2.1 document

  • Updated: Fri, 5 Jan 2024 20:12 GMT

Arbitration specification binding mechanism restricted to only one arbitration specification

  • Key: UMLTP22-10
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    UTP 2 defines for each element that may produce a verdict (i.e. test set, test case and all procedural elements), default arbitration specifications that prescribe how to calculate that verdict. The default arbitration specifications are optimized for functional testing, though. In case of testing non-functional aspects such as fault tolerance, performance or security, the rules to determine functional verdicts do usually not suffice anymore. Therfore, UTP 2 enables the definiton of proprietary arbitration specification (mainfested as stereotype <<ArbitrationSpecification>>) to grant the hightest flexibility possible to the user.

    However, the current mechanism to associate a test set, test case or procedural element with a dedicated arbitration specification is restricted to only one arbitration specification. Even though this would be sufficient in many situations, the problem with the current binding mechanism is that the test set, test case or procedural element is literally changed by the binding. This may lead to situations where elements are copied only for the sake of associating a different arbitration specification to a that element. This is a situation that should be avoided under all circumstances.

    We suggest adding a loosely coupled arbitration specification binding mechanism that keeps the elements and the arbitration specifications that ought to be bound to that element separated from each other. This would bring the benefit that test sets, test cases and procedural elements stay clean of any arbitration specification. This would also foster reusability of these elements.

    The loosely coupled mechanism to bind arbitration specifications to the test sets, test cases and procedural elements could be based on a new concept 'ArbitrationDirective' , similar to the 'TestDesignDirective' concept that already exists in the language and proved its applicability. By doing so, users could define and assign an arbitrary number of arbitration specifications to a test set, test case or procedural element without technically modifying any of these elements.

  • Reported: UTP2 1.0b1 — Fri, 5 Oct 2018 08:48 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Introducing an arbitration specification binding mechanism

    The RTF agreed that the current arbitration facility is not flexile enough and will result in a number of duplicated model elements just for the purpose of assigning different pass/fail criteria. The RTF has developed an arbitration specification binding mechanism that loosely couples arbitration targets with arbitration specifications. Bindings can be overridden in a cascading manner that fosters reuse of existing arbitration specification.

  • Updated: Fri, 5 Jan 2024 20:12 GMT
  • Attachments:

Last paragraph of Clause 8.6.2 Data Values needs to be removed

  • Key: UMLTP22-6
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The last paragraph of Clause 8.6.2 Data Values is an unintended left over from the revised submission. In the revised submission, there was the attempt to precisely define the semantics of matching ValueSpecifications. This attempt ought to be entirely removed. Thus, this paragraph should be removed.
    For the sake of clarity:

    Both stimuli and expected responses yield data values for distinct signature elements. A signature element is defined
    as instance of either a Parameter or Property (i.e., this specification introduces a virtual metaclass SignatureElement that is the joint superclass of Property and Parameter and has at least the following attributes: type : UML::Type,
    lower : Integer, upper : UnlimitedNatural). Given by UML [UML25], a "... Type specifies a set of allowed values
    known as the instances of the Type." This specification denotes this set in the context of a SignatureElement
    expressed as type(se), with type(se) as SignatureElement.type, and use T as abbreviation for type(se).
    We specify
    with se instance of SignatureElement and lower(se) as SignatureElement.lower and denote it by SE type.
    A ValueSpecification V as an argument for a SignatureElement is specified as
    These basic definitions are further used for the specific ValueSpecification matching mechanism extensions
    introduced by UTP.

  • Reported: UTP2 1.0b1 — Wed, 19 Jun 2019 13:56 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Remove last paragraph

    RTF agreed to remove the last paragraph as it represents a relict from the initial submission.

  • Updated: Fri, 5 Jan 2024 20:12 GMT
  • Attachments:

Unnecessary linebreak between first and second paragraph of Clause 8.7.1 Arbitration Specifications

  • Key: UMLTP22-5
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    This linebreak can be removed.

  • Reported: UTP2 1.0b1 — Wed, 19 Jun 2019 13:59 GMT
  • Disposition: Closed; No Change — $issue.fixedSpecification.name
  • Disposition Summary:

    Issue not present anymore

    The reported issue is not anymore present in the document with number formal/20-08-05.

  • Updated: Fri, 5 Jan 2024 20:12 GMT

Correct XMI files and URI of machine-readable files for UTP 2.1

  • Key: UMLTP21-19
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    This is an urgent issue, raised by the AB with respect to the correctness of the XMI files as well as the URI of the XMI files and the correct URIs mentioned on the cover page of the UTP 2.1 specification.

  • Reported: UTP2 1.0b1 — Thu, 20 Jun 2019 15:11 GMT
  • Disposition: Resolved — UTP2 2.1
  • Disposition Summary:

    Correct XMI files and URI of machine-readable files for UTP 2.1

    As discussed during the AB meeting at the Amsterdam meeting, the XMI file needed some cleanup and also the URI of the machine-readable files need to be corrected on the cover page.

  • Updated: Tue, 8 Oct 2019 18:00 GMT

Multiplicity of ID for TestSet and TestContext should be 0..1

  • Key: UMLTP2-33
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The ID attribute offered by the TestSet and TestContext should be 0..1 similar to TestConfiguration, TestCase etc.
    The reason is that those IDs shall act as traceability element in context of a testing tools landscapes, in particular for synchonization with test management and test reporting tools.
    If such a traceability link is not required, models shall not become invalid.

  • Reported: UTP2 1.0b1 — Mon, 19 Feb 2018 14:22 GMT
  • Disposition: Resolved — UTP2 2.0
  • Disposition Summary:

    Change multiplicity of attribute ID of TestSet and TestContext to 0..1

    As recommended by the issue description, the mutliplicity of the attribute 'ID' should be changed to 0..1.
    This proposal incorporates also the resolution of proposal UMLTP2-38. As agreed in that proposal, the tag definitions 'testLevel' and 'testType' of TestContext ought to have an upper bound of *.

  • Updated: Wed, 3 Oct 2018 14:16 GMT
  • Attachments:

TestContext.testLevel and TestContext.testType ought to allow for an upper bound of *

  • Key: UMLTP2-37
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The two tag definitions 'testLevel' and 'testType' determine the corresponding test item level and the test item's quality criteria that are targeted by the artifacts of the test context. Currently, this is set to an optional multiplicity of 1, but ought to be 0..*

  • Reported: UTP2 1.0b1 — Mon, 26 Mar 2018 11:47 GMT
  • Disposition: Duplicate or Merged — UTP2 2.0
  • Disposition Summary:

    Change upper bound to 0..*

    The issue is correct; it is easily possible that tester want to reuse the test artifacts assembled by the test context for more than just one test level or test type.

    In fact, the way it is written in the spec (plural), it seems that it was intended from the very beginning to assign an upper bound of * to both tag definitions.

    The resolution of this issue was done in conjunction with proposal UMLTP2-34.

  • Updated: Wed, 3 Oct 2018 14:16 GMT