RAAML 1.1 RTF Avatar
  1. OMG Issue

RAAML11 — Situation is defined ambiguously, 'situation occurrence' is not defined

  • Key: RAAML11-10
  • Status: open  
  • Source: Coventry University ( Mr. Stephen Powley)
  • Summary:

    Considering its significance, Situation is defined rather ambiguously in Table 5.1: “A situation describes a set of situation occurrences of some type. The system, place, time and state parameters are described by classifiers rather than individual descriptions. A situation occurrence is a system being in a given place at given time and in a given state.” Section 9.1 adds that “The system, place, time and state parameters are described by classifiers rather than individual descriptions.” This prompts a number of questions, which are unanswered by the specification:

    • Why is there no formal definition of ‘situation occurrence’ in the Core Profile? (it is only informally defined as part of the definition of ‘situation’) The lack of a formal definition seems to be something of an oversight, given their central importance, especially considering that the stated aim of RAAML to “avoid inconsistent model-based solutions [that] prohibit direct model sharing between organizations and across the various tools”.
    o My recommendation would be to add this to the Core Concepts e.g. “Figure 9.1 – Core concepts domain model”, a definition in Section 9.1.x and an entry in the 5.1 definitions table.

    • In the absence of the above definition of ‘situation occurrence’, the RAAML user is left to guess how ‘situation occurrences’ should be represented in the model?
    o One might initially assume that a ‘situation occurrence’ is intended to be an instances of ‘situation’, but this assumption would appear to contradict the definition of ‘situation’, which states it is a set of ‘situation occurrences’. In other words, every instance of ‘situation’ must be associated with a set corresponding instances of ‘situation occurrence’
    o What ‘types’ of ‘situation occurrence’ exist (definition of ‘situation’ states “…situation occurrences of some type”)
    o What is the nature of the set of ‘situation occurrences’ that are described by a ‘situation’?
     Should this be represented in UML with shared or composite aggregation from whatever represents ‘situation occurrence’ to ‘situation’ – maybe not, because ‘situation’ only “describes a set”, so perhaps this should be a plain association labelled ‘describes’?
     If the relationship is aggregation, should/could a ‘situation’ comprise anything else alongside the set (such as a description of the relationships between the members of the set)?
    o Regardless of whether ‘situation’ aggregates ‘situation occurrences’ or merely describes them, what range of multiplicities is valid (e.g. can a ‘situation’ be an empty set, have only a single constituent ‘situation occurrence’, or must it be comprise two or more)?

    • RAAML deliberately relies on UML classifiers to represent “system, place, time and state”.
    o State is a UML type and RAAML shows e.g. «FailureState» extending the «State» metaclass, but which classifiers are intended to be used for ‘system’, ‘time’, and ‘place’?
    o I am also left wondering why RAAML relies on classifiers for this purpose, rather than making them explicit in the Core Concepts – no rationale for this decision is provided. This seems almost certain to result in various interpretations in different organizations' tools, thus violating the stated aim "avoid inconsistent model-based solutions"

  • Reported: RAAML 1.0 — Tue, 21 Jun 2022 16:59 GMT
  • Updated: Mon, 25 Mar 2024 15:56 GMT