1. OMG Mailing List
  2. UML Testing Profile 2.1 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: utp2-rtf
  • Issues Count: 8

Issues Descriptions

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

Generators for and Queries on Test Logs

  • Key: UMLTP23-25
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    Curently, UTP2 supports capturing actual results of a Test Set or a Test Case execution via its Test Log capability. A TestLog is an instance of a Test Log Structure that shall specify, what exacty is to be logged. However, the current UTP2 specification does not specify, how such a Test Log Structure is to be expressed. Furthermore, when one or more Test Logs have been instantiated (after executing some Test Sets or Test Cases), the tester may whish to extract only those parts of an existing (potentially huge) Test Log that are relevant to investigate a specific problem. This is not supported by the current UTP2 specification.

  • Reported: UTP2 2.0b2 — Tue, 18 Dec 2018 15:50 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

Non-navigable associations ends shall be removed from the spec

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

    In the current spec, non-navigable association ends (i.e., association ends that shall belong to the association) are still listed in the section 'Associations' of the stereotype on the other side.

    See for example in section 8.4.2.5 TestConfigurationRole the following entry in the sub-section 'Associations':
    : TestConfiguration

    The spec should be cleaned up in that regard.

  • Reported: UTP2 2.0 — Fri, 10 May 2019 10:05 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

UTP should incorporate concepts to speciy decision tables for allowing decision table testing

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

    Decision table testing is a major and frequently used black-box test design technique. In system and acceptance testing as well as testing of business processes, decision table testing is used to identify the test conditions within business rules by representing these rules in a tabluar format.

    The Decision Modeling Notation (DMN) provides a MOF-based metamodel for modeling decision tables. Within the DMN, decition tables are an isolated part, well suited for being extracted as profile as part of UTP.

    Incorporating a decision table profile into UTP, inspired by the DMN MOF-based metamodel, would improve UTP in the area of business rule testing and make UTP more complete regarding specification-oriented test design techniques.

  • Reported: UTP2 2.1 — Mon, 14 Dec 2020 21:24 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

LoginExample is not in synch with latest Profile Specification

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

    Double-check that the LoginExample copes with the latest version of the spec.

  • Reported: UTP 2.0b1 — Tue, 16 Jan 2018 09:17 GMT
  • Updated: Fri, 5 Jan 2024 20:27 GMT

Cannot access XMI library and TypesLibrary for UTP 2.1

  • Key: UMLTP23-2
  • Status: open   Implementation work Blocked
  • Source: Lockheed Martin ( Justin Nguyen)
  • Summary:

    Error when attempting to open UTP 2.1 Library and Types Library. The same error message is presented when opening either file

    "error on line 3 at column 80: xmlns:StandardProfile: ' http://www.omg.org/spec/UML/20161101/StandardProfile' is not a valid URI"

  • Reported: UTP2 2.1 — Tue, 15 Feb 2022 11:40 GMT
  • Updated: Fri, 8 Dec 2023 13:56 GMT

XMI files reference non-working URLs. Cannot import into tool.

  • Key: UMLTP23-1
  • Status: open   Implementation work Blocked
  • Source: JHU APL ( Trisha Radocaj)
  • Summary:

    The .xmi files for the UTP2 have links that do not work. Even when separately going to the OMG UML site and downloading the StandardProfile.xmi and the PrimitiveTypes.xmi, unable to load the utp2.xmi profile. Tool vendor (Cameo Systems Modeler)--they suggest that the problem is in the references in the profile. In the utp2.xmi import may be getting stuck on the UML.xmi "used project". It will not let me manually select the UML.xmi file as it says "NOT A USED PROJECT!" Many permutations of installation have been attempted. This is preventing effective use of the standard in its application of test to our system model.

  • Reported: UTP2 2.1 — Fri, 1 Apr 2022 14:36 GMT
  • Updated: Fri, 8 Dec 2023 13:56 GMT