ISO/IEC JTC 1/SC 30/WG1 N 039



Finnish Data Communication Association


Salomonkatu 17A, 10th Floor  
FIN-00100 Helsinki



Direct Line : +358 9 4763 000

Direct Fax : +358 9 4763 0399


TITLE : Synthesis of role models

SOURCE: Norway



1. Introduction

This is a contribution to the work done by SC 30/ WG 1 on scenarios in the BOV perspective of Open-edi. It is based on [Myrseth], and examines the synthesis of role models. A role model defines the interaction between roles in an Open-edi scenario.

Decomposition of business processes is discussed in [WG1/N004], which describes a generalized trading process where "Each trade is defined as something that is conducted between two players". It is not the purpose to examine the identification of minimal scenarios (e.g. whether basic scenarios of more than two players may be required) in this document. Some examples thus include basic role models with three roles.

1.1 Purpose

This document is intended as input to discussions in WG1. Depending on the outcome of discussions in Seoul and the finalization of [Myrseth], it may be developed into contributions to the document "Identification and Mapping of Business Requirements on Open-edi Scenarios" [WG1/N003]. It adresses mainly issues of section 3.2.2 (The specification of Open-edi Scenarios - Model of the External Intended Behavior (Role Models) - Roles+Diagram). A formal description Technique (FDT) is used that may be a candidate for inclusion in chapter 4 (Examples of FDTs).

1.2 Terminology

Business transaction

A business transaction is a set of activities and/or processes carried out by business users. Business transactions are initiated to obtain a defined business goal, and are terminated upon achievement of a universally accepted state [DIS].

Examples of business transactions are for instance ordering a product, invoicing, supplying information (when considered a separate product), performing payment transfers, customs clearances, exchanging transport information, etc. A business transaction is described by means of a scenario.


A scenario is a formal specification of a category of business transactions that have the same business goals [DIS]. A scenario includes for instance all procedures from a product is ordered until transport is completed and both transport and product are paid for. A scenario will describe roles and the flow of information between the roles.


A role is an entity that models the external intended behaviour. It describes business users having the same function within a scenario. Examples of roles are transporters, transport orderers, payers, payment recipients, customs authorities, etc. A business user may perform several roles simultaneously if required.

Role model

A role model is a description of the information flow between roles in a scenario and comprises basic role models and compound role models.

Basic role model

A basic role model is minimal, i.e. it consists of a minimum number of roles and information parcels. The model can not be further decomposed without losing its meening.

Compound role model

A compound role model is produced by joining one or more basic role models; what usually happens is that roles from the various basic role models are joined together to form one compound role.

Compound role

A compound role is produced by joining two or more basic role models, with at least two of the roles from the original role models merged to one role.

2 A "building block" approach

According to [DIS] parts of a scenario will be optional. One instance of a scenario will therefore not necessarily cover all roles and information parcels that are described. Accordingly, an instance in a scenario will usually be a sub-set of the scenario which was described in a BOV perspective.

Comprehensive BOV scenarios based on a selection approach are largely equivalent to the approach currently used in the development of EDIFACT. This approach has led to well known problems with incompatible profiles and implementation guides, and a "building block" approach is therefore suggested.

The following text discusses this approach for the modelling of roles and role models. Similar arguments and solutions are applicable to Information Parcels.

Basic role models in a BOV perspective with clearly defined interfaces between each other may be put together as building blocks to form a compound role model. A set of basic role models in a BOV perspective may then be joined together to support the performance of a business transaction. The result is a compound role model which is built up of a set of basic role models. One of these basic role models is chosen as the most central one.

From a selection perspective one may integrate various role models to support the accomplishment of a desired business transaction. The chief role models must not be discardable, since they will be essential for all instances of a scenario. A business transaction is thus described by means of one or more role models.

2.1 Object Oriented Role Analysis and Modelling (OOram)

OOram is a comprehensive object oriented method with a focus on roles. Some of the OOram notation is used in examples below, and a minimal introduction is included. For a more extensive presentation of OOram, including an evaluation of OOram as an FDT for Open-edi according to requirements identified in [Walseth], see [Myrseth]. For the full documentation of OOram, see [Reenskaug96] and [Reenskaug95].

OOram focuses on the interplay between roles in role models. Role models show the exchange of information between roles which is equivalent to the interaction between roles as defined in the Open-edi scenario definition. An EDI party may handle several roles and OOram permits decomposition of the roles which the EDI party is supposed to master.

An EDI party may handle zero, one or several roles in those role models resulting from the decomposition, and vice versa, role models may be joined together to form compound role models in which an individual EDI party may carry out several roles. This combination of role models and roles is termed an OOram synthesis. The use of this term is in accordance with the Open-edi use of the role term.

OOram is more concrete in terms of modelling external behaviour than Open-edi. A role is encapsulated and communicates with its surroundings via an in-tray and an out-tray. The role also has a set of assignments and rules for how the tasks shall be carried out. This agrees well with the Open-edi definition of a role as a model of external behaviour.

OOram consists of ten different notations and a focus on the same roles. These approaches include "Process View", "State Diagram View", "Method Specification View" and "Area of Concern View". There are CASE tools available for OOram that support an entire development course, from analysis of the problem area to implementation, maintenance and reuse of program code.

2.2 Scenario view of role models

A Scenario View in OOram shows how the information parcels are exchanged between roles and how this sequence is placed in time. The notation that OOram uses to describe a scenario view is as follows:

An example illustrates use of the notation:


Figure 1

The role model in Figure 1 consists of two roles: the buyer of a product and the seller of the same product.

The role model illustrates that the buyer sends an order to the seller. Orders and invoices are examples of information parcels. The model does not show transport of the product since that is product flow, not information flow.

The seller then sends an invoice to the buyer. This may be called a basic role model since it is minimal, i.e. it cannot be broken down into less roles without losing its meaning.

Figure 2

The basic role model in figure 2 consists of three roles: the payer who is to pay a bill , the beneficiary who is to receive money, and the payment agent/bank. The payer sends a payment order to the bank, which sees to it that the beneficiary gets a credit advice, the bank then sends a debet advice to the payer.

2.3 Synthesis of role models

When we wish to combine several basic role models this can be done by using the stimulus (to be defined!) and response (to be defined!) of the role model to communicate between models. This method of joining basic role models to form a compound role model is called an OOram synthesis.

Figure 3

In figure 3 the basic role models for ordering a product and the payment scenario are combined to form a compound role model. The role "bank" is not compound. The roles "buyer" and "payer" are combined in "buyer", likewise "seller" and "beneficiary" are combined in "seller". The dashed rectangles indicate the original basic role model which makes up the compound role model All interaction between roles go via defined information parcels, and the obtained information parcels activate the role.

2.4 State diagrams

A state diagram describes which states are legal for a role and what makes a role change its state. A role will always have an initial state, as will a role model. A role enters this initial state by receiving the information parcel permitting it to be activated, the so-called stimulus

The role model enters this initial state when the role that is defined as its initial role receives its stimulus. The role will be able to send and receive information parcels according to its state diagram. One simple example showing which states may be legal is as follows:

State diagram for the role Seller in the role model: Ordering a product

Action State when starting Execute Final state
Receive purchase order Initial Send product Product sent
Prepare invoice Product sent Prepare and send invoice Complete

By using synthesis one obtains compound roles. To understand the behaviour of a compound role one must put together the state reviews of the original roles to form a state survey for the compound role.

A role is activated when it receives its stimulus. When a role is active it may activate other roles by sending their stimuli. The problem arises when one puts together the role of buyer and payer as is done in figure 3, then the state review of the original role "buyer" does not indicate how the role of "payer" is activated. When the buyer has

received the invoice the original role enters the complete state. This is a mistake in the compound role model, since when the invoice has been received the payment order is to be implemented. One does not get this result automatically by only joining the state reviews. Every time a compound role is designed one must always be certain that the compound state diagram is complete.

With synthesis one arrives at a Cartesian product of the states based on the original state diagrams. For example: Role A has three states and role B has two. A Cartesian product means that for every three of A's states B will have two. Hence, the number of states will be A's number of states multiplied by B's number of states.

Figure 4 [Reenskaug96]

Figure 4 shows a synthesis of state diagrams. A1, B1 and A1B1 are initial states for the state diagrams A, B and AB respectively.

3 Discussion

This chapter focuses on some aspects of scenarios, role models and roles that need discussion.

3.1 State explosions

Consider an example where roles A, B and C were to be combined to form a compound role and that they had 4, 5 and 6 states respectively. The compound state diagram would then consist of 4*5*6=120 states. This is called a state explosion and is a major problem with synthesis. In order to limit the state explosion one must edit the

state diagram of the compound role and make manual adjustments in the state diagram itself. It is helpful if one can limit the state diagrams for the compound role so that they will always have to be done sequentially. The state explosion would in that case have produced 4+5+6=15 states.

Normally, compound roles will have less states than would be expected from a Cartesian product. This is because the states of roles will often be tied to a sequence. The following example shows this point:

If these three point reflect a sequence that always occurs and not only occurs as a rule, one may simplify the relevant state diagram. These three points are only random examples and thus must not be used to justify that simplification of a compound state diagram is always possible.

For compound state diagrams it would be easiest if the state diagrams of each role have a given sequence and that the state diagrams of the original roles are always carried out in a particular sequence. For example: Role A has four states that always must be performed in a particular sequence. Role B has five states that always must be performed in a particular sequence. For the compound role AB all A's states will thus be run through and when they are over B's states will be initiated, i.e. 4+5 states.

3.2 Standardisation of role interfaces

One of the intentions behind Open-edi is that the standard shall not decide the internal performance of a role by an EDI-party, it shall only determine what must be performed and impose requirements on the interfaces between the roles. However, this becomes a dilemma when several roles are performed by the same Open-edi party.

The interface between the roles will then be an internal matter for the EDI-party performing the roles.

Thus, the Open-edi standard also determines to some extent the internal performance within an organization, which is in conflict with the basic intentions.

This may be solved by permitting proprietary interfaces between roles performed by the same Open-edi party, but the standard must be followed for those roles communicating with roles performed by other Open-edi parties.

However, proprietary solutions may cause problems for the synthesis. With proprietary solutions the state diagrams of the individual roles will probably be altered and the synthesis will not necessarily be possible to carry out.

3.3 Negotiation of scenario properties

For implementation purposes an Open-edi party will choose a set of basic role models, roles, information parcels, etc. These choices are made on the basis of the business transaction(s) that the Open-edi party is interested in using for his coming Open-edi system. The choices form the basis of what types of scenario instances that the party may participate in. The actual scenarios that an Open-edi Party may participate in is limited by the party's own capabilities as well as by the capabilities of available candidates to other roles.

One advantage of object oriented modelling of the scenario is precisely the benefit of being able to negotiate the properties of a compound scenario: which role-performers take part and what information parcels and additional parcels that may be used. This negotiation may also be carried out when necessary while a scenario is active. For a large

scenario it will not be realistic to negotiate the complete run of a scenario from A to Z at the initial instance. Roles will be initiated and terminated on the basis of states in the middle of the scenario and unforeseen complications may arise that terminate the scenario before it is completed. For example, it will be meaningless to complete a transport scenario if the product that is to be transported is damaged or does not exist for another reason. It will be necessary for one or more scenarios that describe handling of various deviations in the overall scenario.

A pre-scenario is needed in which one decides what the compound scenario is to consist of. It may perhaps be useful to define this pre-scenario as a separate initial scenario, or it may be a basic scenario. It will also be necessary with a termination scenario to handle possible unforeseen terminations and which ensures that all Open-edi parties and instances of other units involved are terminated. This may be a basic scenario or a separate post-scenario.

3.4 Scenario components

The interface between roles is essential in practical use. When a scenario is initiated and roles are to be performed the scenario attributes and business logic attached to certain information parcels must be integrated in the roles. One should therefore consider whether a scenario is appropriately described by means of roles, information parcels and scenario attributes as terms on an equal footing. The implemented role is in charge of handling the scenario attributes and business logic that is tied to particular information parcels.

In some cases a synthesis of role models may lead to a need for scenario attributes that were not needed in the original basic role models. This problem seems to be unavoidable when synthesis of role models is used.

However, if one chooses not to base the scenario modelling on role model synthesis, one will encounter the same problem when an EDI-party plays roles from more than one scenario. This situation will arise as a result

of the Open-edi Reference Model requirement that an EDI-Party should be able to play several roles, combined with the need for a larger number of scenarios if synthesis of scenarios is not used.

This indicates that the inclusion of new scenarion attributes during synthesis must be facilitated. As corrsponding problems will have to be solved even without the use of role model synthesis, discarding the whole method of role model synthesis is not a solution.

4 References

[Myrseth] (In Norwegian) Per Myrseth. An evaluation of Open-edi. Draft version (18/7/96) of thesis to be submitted for Cand.Scient. degree in Informatics, University of Oslo.

[WG1/N003] Identification and Mapping of Business Requirements on Open-edi Scenarios (TOPIC 14), ISO/ IEC JTC 1/SC30/WG1 N003

[WG1/N004] R. Miki. Analysis and Method to describe the Business Scenario, ISO/ IEC JTC 1/SC30/WG1 N004

[DIS] Draft International Standard ISO/IEC 14662, Information Technology - Open-edi reference model.

[Walseth] Sverre Walseth, Matts Ahlsen, Hannu Pelkonen. Consepts and Notations for Open-edi Scenarios. Televerkets forskningsinstitutt, TF R 25/94.

[Reenskaug95] Trygve Reenskaug, Working with objects, A three-model architecture for the analysis of information systems. 1995.

[Reenskaug96] Trygve Reenskaug, Working with objects, The OOram Software Engeneering Method. Manning Publications Co 1996.