UML Profile for Voice-based Applications Avatar
  1. OMG Specification

UML Profile for Voice-based Applications — All Issues

  • Acronym: VOICP
  • Issues Count: 5
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Textual syntax adjustments

  • Key: VOICP-5
  • Legacy Issue Number: 10965
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Some adjustments to the textual syntax are needed.
    In particyular:
    Allow decision with empty decision expression decision ()

    { … }


    Operator != is missing in BNF (found '<>' instead)

  • Reported: VOICP 1.0b1 — Fri, 20 Apr 2007 04:00 GMT
  • Disposition: Resolved — VOICP 1.0
  • Disposition Summary:

    (1) In Section 10.2, after "This section gives formally the grammar.", adds the following paragraph:

    Lexical elements:

    The list of reserved words is:
    'service', 'voiceservice', 'entities', 'package', 'class', 'operation', 'message', 'messagepart', 'event', 'externalevent', 'systemevent', 'static', 'global', 'shared', 'property', 'var', 'extends','maindialog', 'dialog', 'within', 'in','inout','out', 'behavior', 'play', 'playall', 'call', 'divert', 'return', 'stop', 'decision', 'case', 'junction', 'jump', 'restart', 'wait', 'when', 'do', 'accept', 'if', 'then', 'else', 'endif', 'null', 'true', 'false', 'unlimited', 'not', 'and','or','xor'','informal','new','Set','Bag','Sequence','OrderedSet'.

    In the BNF these keywords are denoted by the corresponding word in capital letters. For instance DIALOG denotes the occurrence of the dialog keyword.

    The following variable tokens are defined:

    ID: an alphanumeric identifier
    ICONST: integer value
    FCONST: float value
    SCONST: double quoted string
    CCONST: single quoted string

    The following character tokens are defined:
    'PLUS' -> '+'
    'MINUS' > ''
    'TIMES' -> '*'
    'DIVIDE' -> '/'
    'MOD' -> '%'
    'EQ' -> '=='
    'LT' -> '<'
    'LE' -> '<='
    'LT' -> '<'
    'GE' -> '>='
    'GT' -> '>'
    'NE' -> '<>'
    'NEX' -> '!='
    'EQUALS' -> '='
    'PLUSEQUAL' -> '+='
    'MINUSEQUAL' > '='
    'ARROW' > '>'
    'PERIOD' -> '.'
    'LPAREN' -> '('
    'RPAREN' -> ')'
    'LBRACKET' -> '['
    'RBRACKET' -> ']'
    'LBRACE' -> '

    {' 'RBRACE' -> '}

    '
    'COMMA' -> ','
    'SEMI' -> ';'
    'COLON' -> ':'
    'DCOLON' -> '::'

    (2) Replace the BNF rule:
    decision_head LBRACE decision_body RBRACE
    by
    decision_head LBRACE decision_body? RBRACE

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

Import of external entities

  • Key: VOICP-4
  • Legacy Issue Number: 10964
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A Model containing more than one Service. Entities that are
    shared versus entities specific to a service. What about import
    of external entities?? How to represent it?

  • Reported: VOICP 1.0b1 — Fri, 20 Apr 2007 04:00 GMT
  • Disposition: Resolved — VOICP 1.0
  • Disposition Summary:

    RESOLUTION: Merged with issue 10961

    Solved when applying resolution of issue 10961.

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

Global variables

  • Key: VOICP-3
  • Legacy Issue Number: 10963
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Should we allow global variables between dialogs that are not
    connected (as it is currently)?

  • Reported: VOICP 1.0b1 — Fri, 20 Apr 2007 04:00 GMT
  • Disposition: Resolved — VOICP 1.0
  • Disposition Summary:

    (1) In Section 8.3.1 Dialog, at the end of the actual property list, add a 'standalone' property with the following definition: "states whether the dialog is allowed to refer to global variables. If standalone is True no global variables can be used.
    (2) Update Figure 8.5 by adding the Boolean standalone property in class Dialog.
    (3) In the Textual syntax section (Section 10) add the 'standalone' keyword in the list of reserved words and adjust the BNF rule for dialog as follows:
    Replace the definition of the 'dialog_head' non terminal by:
    'dialog_head : 'standalone'? dialog_kind ID within_dialog_opt'

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

Variability in notation

  • Key: VOICP-2
  • Legacy Issue Number: 10962
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Allow usage of activity diagrams as alternative to state machine
    when not available

  • Reported: VOICP 1.0b1 — Fri, 20 Apr 2007 04:00 GMT
  • Disposition: Resolved — VOICP 1.0
  • Disposition Summary:

    After section 9.2 Stereotypes of the UML Voice Profile, add a section: "Using Activity diagrams to represent dialog behavior" with the following content.

    For more flexibility in the implementation, the dialog behavior which, from a semantic point of view is defined by a state machine, can however be rendered by an activity diagram following some conventions.

    When this variation in notation is used the following mappings should apply:

    • An ActivityGraph replaces a StateMachine.
    • A InitialNode replaces a Pseudostate with kind=initial
    • A DecisionNode replaces a Pseudostate with kind=choice
    • A MergeNode replaces a Pseudostate with kind=junction
    • An ActivityFinalNode replaces a FinalState
    • An Action replaces a State

    The base classes for the stereotypes are changed according to these mappings.

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

Propose a better structuring of the profile

  • Key: VOICP-1
  • Legacy Issue Number: 10961
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Propose a better structuring of the profile :
    A Behavior can contain directly operations and attributes,
    signals and contained behaviors.
    This allows to represents directly Dialogs containing messages,
    input events variables and sub-dialogs.
    A Dialog is a Behavior which can contain directly operations,
    Variables

  • Reported: VOICP 1.0b1 — Fri, 20 Apr 2007 04:00 GMT
  • Disposition: Resolved — VOICP 1.0
  • Disposition Summary:

    (1) Insert a new section within Section 9 (The Voice UML Profile) named "Structure of a voice service model" with the following text:

    A UML model may contain the definition of a single voice service or the definition of various voice services. A "Framework" package contains the lists of predefined signals and predefined operations that are available to all services. Each voice service is represented by a Package stereotyped <<Service>>. A package containing the definition of entities can be either contained within a <<Service>> package or live at same level - typically imported from other UML models. The latter is useful for services sharing the same set of entities.

    The structure of a <<Service>> package should follow one of the two structural schemes:

    Old style:
    Entities defined specifically for the service are defined within a package stereotyped <<EntitiesModel>>.The dialogs are represented by a package stereotyped <<DialogModel>>. The main dialog is the unique <<DialogModel>> package directly contained by the <<Service>> package. A <<DialogModel>> has the following structure: a class stereotyped <<InputContainer>> to contain the locally defined input events (UML signals), a class stereotyped <<VariableContainer>> to contain the global variables (only for the main dialog), a class stereotyped <<MessageContainer>> to contain the messages (UML operations)
    and a class stereotyped <<BehaviorContainer>> to contain the operation containing the behavior definition (state machine or activity graph). Sub dialogs are defined by nested packages stereotyped <<DialogModel>>.

    New style:
    Within the <<Service>> package, a dialog is directly defined by a behavior (either a state machine or an activity graph). The main dialog is the unique behavior directly contained by the <<Service>> package. Sub dialogs are defined as behaviors owned by the behavior representing the owning dialog. The input events are defined as signals owned by the <<Service>> package. Variables are defined as properties of the behavior and messages are defined as operations of the behavior.

    These two styles are needed to cope with existing UML implementations. Old style can be used by UML 1.x conformant tools or UML2 tools that do not support the ability for a behavior to contain properties and operations.

    (2) In page 28, within the line describing "Message", remove the sentence "The operation is owned by a class stereotyped <<MessageContainer>>".

    (3) In Section 9.2 Stereotypes of the UML Voice Profile, after the table add the following sentence.

    The following stereotypes are only applicable when the "old style" structural schema (see Section 9.1) is used: <<MessageContainer>>, <<InputContainer>>, <<BehaviorContainer>> and <<DialogModel>>.

    (4) In Section 9.2 remove the stereotypes <<PackageModel>>, <<ConceptContainer>>. Note: These are duplicates of <<DialogModel>> and <<InputContainer>> respectively.

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