Issue 10961: Propose a better structuring of the profile (voice-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.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. End of Annotations:===== s is issue # 10961 From: "BELAUNDE Mariano RD-MAPS-LAN" Propose a better structuring of the profile 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