Issues for Mailing list of the UML Profile and Metamodel for Voice Applications Finalization Task Force

To comment on any of these issues, send email to voice-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 10961: Propose a better structuring of the profile
Issue 10962: Variability in notation
Issue 10963: Global variables
Issue 10964: Import of external entities
Issue 10965: Textual syntax adjustments

Issue 10961: Propose a better structuring of the profile (voice-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: (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.
Revised Text:
Actions taken:
April 20, 2007: received issue
November 7, 2007: closed issue

Discussion:

The structure of a service dialog in the voice specification was influenced by the facilities provided in most of the available UML tools. For instance most of the tools does not allow a "behavior" to contain directly operations and attributes and instead requires a class to be defined.

However to allow a more direct representation in a fully compliant UML2 tool the proposed resolution allows to have some variability in the structure of the model.

Issue 10962: Variability in notation (voice-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
April 20, 2007: received issue
November 7, 2007: closed issue

Discussion:

The UML2 transition-oriented notation for state-machines which is appropriate to render voice dialogs is not yet widely implemented by UML tools. The activity diagram notation, which renders closely like the transition-oriented notation, is in constrast widely supported.

Issue 10963: Global variables (voice-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: (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'
Revised Text:
Actions taken:
April 20, 2007: received issue
November 7, 2007: closed issue

Discussion:

Because in most cases dialogs and invoked sub-dialogs execute in the same address space global variables were introduced. However it could be interesting to allow an end-user to declare that a Dialog definition is not depending on global variables of a containing dialog. To this end the resolution proposed below enables the ability to declare "standalone" dialogs.

Issue 10964: Import of external entities (voice-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
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?

Resolution: RESOLUTION: Merged with issue 10961 Solved when applying resolution of issue 10961.
Revised Text:
Actions taken:
April 20, 2007: received issue
November 7, 2007: closed issue

Discussion:

RESOLUTION: Merged with issue 10961

Solved when applying resolution of issue 10961.

Issue 10965: Textual syntax adjustments (voice-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
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)

Resolution: (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
Revised Text:
Actions taken:
April 20, 2007: received issue
November 7, 2007: closed issue

Discussion:

The two variants should be accepted: '<>' and '!='. One comes from OCL, the other is what we find in JAVA. To that end two equivalent tokens are defined: NE and NEX (see proposed resolution).