VOICP 1.0 MAILINGLIST Avatar
  1. OMG Issue

VOICP — 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