Bouabid Oussama Mohamed Reda
email: redaoussama@yahoo.fr

El L Ouahidi
email: ouahidi@fsr.ac.ma

Daniel Bourget
email: daniel.bourget@enst-bretagne.fr

Towards a refinement of the open distributed systems interactions signatures

Keywords: ODP, Computational Viewpoint, UML, OCL, Meta-modelling, Interaction Signature, Action Template, Interaction refinements

come

Introduction

The ODP standardization initiative has led to a framework by which distributed systems can be modeled using five viewpoints. For each viewpoint, the Reference Model [START_REF] Iso/Iec | Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use ISO/IEC CD 10746-1[END_REF], [START_REF]ISO/IEC, RM-ODP-Part2: Descriptive Model ISO/IEC DIS[END_REF], [START_REF]ISO/IEC, RM-ODP-Part3: Perspective Model ISO/IEC DIS[END_REF] for ODP provides a viewpoint language that defines concepts and structuring rules for specifying ODP systems from the corresponding viewpoint. These viewpoints include a computational viewpoint, which is concerned with the description of the system as a set of objects that interact at interfaces -enabling system distribution. A computational specification describes the functional decomposition of an ODP system in distribution transparent terms, and is constrained by the rules of the computational language. These comprise among others interaction rules.

Works within the computational viewpoint such as [START_REF] Romero | Modelling the ODP Computational Viewpoint with UML 2.0[END_REF], [START_REF] Akehurst | Addressing Computational Viewpoint Design[END_REF], [START_REF] Bordbar | Using UML to specify QoS constraints in ODP[END_REF] has mainly addressed the specification of the functional decomposition of an ODP system using UML. Other works [START_REF] Romero | Action templates and causalities in the ODP computational viewpoint in 1ST International Workshop on ODP in the Enterprise Computing (WODPEC)[END_REF] has focused on how to consistently formalize concepts of the ODP computational viewpoint and clarify some ambiguities found while aiming to express them formally. The authors discussed the issue concerning whether Action Templates belong to the syntactic level or the semantic one. Then, they proposed to introduce the term Inter-action Signature at the syntactic level, and to reserve Action Templates to a semantic level while they interaction signature as syntactic. They also raised a second issue which has to do with the way in which the concept of Causality is used and have proposed some solutions.

From this perspective, we raise the issue of expressing Operation Signatures in terms of Action Templates and show how to get round the problem of whether Operation Signatures are kinds of Action Templates or are constituents of Action Templates. As we shall see, we propose to solve the problem by formalizing the concept of both Invocations and their associated Terminations by introducing them as roles played in Action Templates. On the other hand, we address another issue concerning how to describe both Operation Signatures and Signal Signatures on one side and Flow Signatures on the other side in terms of Action Templates. In fact, Flow Signatures differ significantly in their characteristics from both Operation and Signal Signatures. That is, a Flow Signature has an information type characteristic which is not the case for Operation and Signal Signatures. Conversely, both Operation and Signal Signatures have parameters and their numbers as two characteristics which are not significant in Flow Signatures. We propose to solve this issue by introducing a new term referred to as ParametrizedActionTemplate as we shall see later. In the other hand, one of our main focus in this work is the refinements of any kind of interactions into signals. We shall see how to refine Operation Signatures into Signal Signatures and provide formal constraints relating to their refinements. In doing so, we are indirectly addressing fundamental QoS issues.

The RM-ODP is not prescriptive about the use of any particular formal description and specification techniques for the specification of ODP systems. Recently there has been a considerable amount of research [START_REF] Steen | Applying the UML to the ODP Enterprise Viewpoint[END_REF] [START_REF] Linington | The specification and testing of conformance in ODP systems[END_REF], [START_REF] Steen | Formalising ODP Enterprise Policies[END_REF] within the field of applying the UML Language [START_REF] Booch | The Unified Modelling Language Guide Addison Wesly[END_REF], [START_REF] Rumbaugh | The Unified Modelling Language Reference Manual[END_REF] as a formal notation with the ODP viewpoints, and particularly to the ODP computational viewpoint [START_REF] Romero | Modelling the ODP Computational Viewpoint with UML 2.0[END_REF], [START_REF] Akehurst | Addressing Computational Viewpoint Design[END_REF], [START_REF] Bordbar | Using UML to specify QoS constraints in ODP[END_REF].

In this respect, we use the UML language to discuss and present our proposals. Our contribution is based on ideas from the field of defining notations for ODP viewpoints.

The remainder of the paper is organized as follows. In Section 2, we discuss why we have chosen UML as a modelling language for our purposes. In section 3 we present concepts of Interaction Signatures provided by RM-ODP. We discuss in section 4 how to express Operation Signatures in terms of Action Templates. In section 5 we show how to integrate the Flow Signatures concept to the Operation Signatures model. Section 6 discusses why refinement of interactions are highly significant to the QoS concept, at the same time that it provides OCL constraints concerning these refinements. A conclusion and perspectives end the paper.

UML language and OCL

The UML Language [START_REF] Booch | The Unified Modelling Language Guide Addison Wesly[END_REF], [START_REF] Rumbaugh | The Unified Modelling Language Reference Manual[END_REF], is rapidly becoming as de-facto language for modelling object-oriented systems. This language is unique and important for several reasons: (1) UML is an amalgamation of several, in the past competing, notations for object-oriented modelling. For a scientific approach, it is an ideal vehicle to discuss fundamental issues in the context of a language used in industry; ( 2) compared to other pragmatic modelling notations in software engineering. UML is very precisely defined and contains large portions which are similar to a formal specification language as the Object Constraint Language (OCL) [START_REF] Omg | UML2.0 OCL Final Specification[END_REF] used for the constraints.

Although UML provides a semantics document, an important aspect of the language is the recognition by its authors of the need to provide a precise description of its semantics. The intention is that this should act as an unambiguous description of the language. This has resulted in a Semantics Document, which is presently being managed by the Object Management Group (OMG). The approach taken is to give a metamodel description of the language (describing the semantics of the UML within the UML itself). This is presented in terms of three views: the abstract syntax, well-formalness rules, and modelling elements semantics. The abstract syntax is expressed using a subset of UML static modelling notations. The wellformalness rules are expressed in OCL. Finally, the semantics of modelling elements are expressed in natural language. Unfortunately, the current semantics are not sufficiently formal. Furthermore little consideration has been paid to important issues such as, compositionally and rigorous tool support.

The task of formalizing UML has been addressed using various available formal techniques. Most of these attempts are complementary, because they approach the task from different viewpoints and aims. We will not consider the large number of papers on the semantics of UML constructs ; we overview the Precise UML (pUML) group formalisation strategy [START_REF]The Precise UML web site[END_REF].

An approach [START_REF] Gogolla | State Diagrams in UML-A Formal Semantics Using Graph Transformation[END_REF] shows how to use graph rewriting techniques to transform UML state machines into another simplified machine (a kind of normal form). Some papers try to formalize UML by using a particular specification language; for example, using Real-Time Action Logic, a form of real time temporal logic [START_REF] Lano | Formalising the UML on Structured Temporal Theories[END_REF]. The relevance of the underlying model for making precise UML has been considered in [START_REF] Breu | Systems Views and Models of UML[END_REF], where a different model, a kind of stream processing function is used. But the main aim is methodological: how a software engineering method can benefit from an integrative mathematical foundation.

The Precise UML (pUML) group believes that the existing UML semantics documentation and the metamodelling approach already provide a good foundation for a precise semantics. The use of denotational semantics is the key to describing the semantics of UML precisely. UML already partially adopts the denotational approach to describe aspects of the language. The meta-modelling approach semantics [START_REF] Evans | Core Meta-Modelling Semantics of UML: The pUML Approach IEE Computer Society Press[END_REF] naturally supports the description of denotational relationships between model elements: model elements and their denotations can both be abstracted as conceptual classes and, the relationships between them can be formalized by associations and OCL constraints. The pUML defines a a formalization strategy which consists of several steps. Those steps are (1) identify specific elements that contribute to a core semantic model, (2) iteratively examine the elements seeking to verify their completeness ; here, the completeness is achieved when : (2.1) the modelling elements have a precise syntax, (2.2) are well-formed, and (2.3) have a precise denotation in terms of some fundamental aspect of the core semantic model, (3) use formal techniques to gain better insight into the existing definitions (e.g [START_REF] Bruel | Transforming UML Models to Formal Specifications, UML'98-Beyond The Notation[END_REF] ), and (4) feed the results into the UML meta-modelling, and disseminate to interested parties for feedback.

Several papers have based on the pUML formalization strategy for formalizing UML constructs [START_REF] Evans | Developing the UML as a formal Modelling Notations Proceeding of UML[END_REF] As mentioned before, the RM-ODP is not perspective about the use of any particular notations and for the viewpoints. Elsewhere, any particular formal description and specification techniques is suitable for the specification of ODP systems. In the past several years, there has been a considerable amount of research within the field of applying the UML as a formal notation to the ODP viewpoints. For example, [START_REF] Steen | Applying the UML to the ODP Enterprise Viewpoint[END_REF] [START_REF] Linington | The specification and testing of conformance in ODP systems[END_REF] addressed how the relevant UML constructs can be used to represent the enterprise language concepts and support the enterprise specifications; a meta-model of the core concepts and their relationships is constructed. [START_REF] Steen | Formalising ODP Enterprise Policies[END_REF] uses UML language for formalizing the ODP enterprise policies; it defines an UML meta-model for policy related concepts which is built on top of the formal object oriented specification language Object-Z (step 2 of the pUML formalisation strategy).

In this respect, we use the UML language to define a notation for computational viewpoint specifications which will serve as a basis for defining end to end QoS characteristics. Our contribution is based on ideas from the field of defining notations for ODP viewpoints.

Interaction Signatures concepts

In this section, we present the Interaction Signatures concepts as they are defined in the computational viewpoint. These definitions will serve us to discuss the ideas of the rest of the paper. the definitions are given as follows:

A computational interface template is an interface template for either a signal interface, a stream interface or an operation interface. Each interface has a signature:

• A signal interface signature comprises a finite set of action templates, one for each signal type in the interface. Each action template comprises the name for the signal, the number, names and types of its parameters and an indication of causality (initiating or responding, but not both) with respect to the object which instantiates the template.

• An operation interface signature comprises a set of announcement and interrogation signatures as appropriate, one for each operation type in the interface, together with an indication of causality (client or server, but not both) for the interface as a whole, with respect to the object which instantiates the template.

Each announcement signature is an action template containing both the name of the invocation and the number, names and types of its parameters.

Each interrogation signature comprises an action template with the following elements : the name of the invocation; the number, names and types of its parameters, a finite, non-empty set of action templates, one for each possible termination type of the invocation, each containing both the name of the termination and the number, names and types of its parameters.

• A stream interface comprises a finite set of action templates, one for each flow type in the stream interface. Each action template for a flow contains the name of the flow, the information type of the flow, and an indication of causality for the flow (i.e., producer or consumer but not both) with respect to the object which instantiates the template.

Operation Signatures and Action Templates

When trying to formalize these concepts we have met with an issue concerning Action Templates and how they are currently used and defined. In other work such as [START_REF] Romero | Action templates and causalities in the ODP computational viewpoint in 1ST International Workshop on ODP in the Enterprise Computing (WODPEC)[END_REF] discussions have focused on whether an Action Template concept lays on a syntactic level or a semantic one. Here, we do not confront this issue as we attempt to solve the problem on a syntactic level. We think that the difficulty of formalizing Action Templates stems from the fact that sometimes, Interaction Signatures seem to be kind ofAction Templates, while other times they comprise a set of Action Templates.

In fact, Announcement Signatures are kind of Action Templates. In contrast, Interrogation Signatures consist of two kinds of interactions which are Invocations and their associated Terminations. Thus, it is not evident whether Operation Signatures are kind of Action Templates or comprise Action Templates and it is difficult to merge these two faces of Operation Signatures in order to formalize them in one blow. Furthermore, Invocations and Terminations seem to be kinds of Action Templates. However, the definition of Interrogation Signatures above is a little bit ambiguous. Indeed, Interrogation Signatures are defined as comprising Actions Templates (the Invocations) which themselves (the Invocations) comprise a finite non empty set of Action Templates (the terminations). This definition is a bit confusing when trying to formalize Interrogation Signatures(Invocations and Terminations). To eliminate this ambiguity, we can see this definition from another perspective. In fact, we can look at Interrogation Signatures as ones comprising both Invocations and their corresponding Terminations which are now linked with an association. So, our proposals to solve this issue is to introduce roles ( invocation role, termination role) to Action Templates (see figure 1). Having said that, Announcement Signatures are now kind of Action Templates, while Interrogation Signatures comprise Action Templates, and that roles introduced to Action Templates are there in order to distinguish between Invocations and their associated Terminations.

Finally, to complete our proposal, we must add a constraint which asserts that whenever an Action Template plays the role of an Invocation the set of its corresponding Terminations is not empty. we leave this to later in the work.

Flow Signatures and Action Templates

Now that we know how to express Operation Signatures in terms of Action Templates, we turn our attention to Flow signatures, and see how to formalize them in terms of Action Templates. We shall see how to integrate Flow Signatures with the Interaction Signatures model and clarify some inconsistencies by in-troducing a new term that we call ParametrizedAc-tionTemplate.

When we look at how Flow Signatures are defined, we can see they are described as kind of Action Templates. However, when taking a close look to this, we realize that it is not convenient to derive Flow Signatures directly from already formalized Action Templates. In fact, Flow Signatures do not involve parameters and their numbers as characteristics which describe them statically. Moreover, Operation Signatures are not characterized by the Flow Information Type which is strictly belonging to Flow Signatures. Thus, we cannot express both Flow Signatures and Interrogation Signatures directly in terms of Action Templates in one go. We resolve this problem by introducing the term ParametrizedActionTemplate as an intermediate level between interrogation Signatures and Action Templates(see figure 2). Now, Operation Signatures will be derived indirectly from Action Templates via Parameterized Action Template while Flow Signatures derive its description directly from Action Templates. In doing so, the description of Action Templates will change. Indeed, since Action Templates are the common descriptive elements between Operation Signatures and Flow Signatures, an Action Template will neither have parameters, nor their numbers in its description. In fact, these two attributes belong now to the term ParametrizedActionTemplate and Action Templates are now expressed in terms of the minimal description consisting of the name and causality of Action Templates which is conceptually more convenient.

Having done this, we can join the two models elaborated above into one model that describes all the Interaction Signatures in one blow (see figure 3). Now, once we have aggregated the constituent parts of the model, we still need additional terms in it in order to get ready for the following section. As we shall see in the following section, all kinds of interaction may be mapped onto signals, and thus, many rules relating to interactions can be reduced to signals.

Since the coming part of the work treats this sight in details, we don't need to further discuss and analyze it here. Right now, all we need to know is that an interaction can be refined into an alliance of composing signals. This is expressed in the elaborated model by an association link between SignalInterfaceSignature and OperationInterfaceSignature classes.

As we mentioned above, we have to add a constraint which ensures that the set of Terminations associated to an Invocation is never empty. But, as Interrogation Signatures are related now to Parametrized Action Templates, the constraint will belong to the ParametrizedActionTemplate term. The constraint written in OCL is as follows:

context InterrogationSignature inv : self.ParameterizedActionTemplate.termination→ notEmpty()
This constraint occurs in the context of Interrogation Signature. Now that we have joined all the pieces of the puzzle together, the final model can be seen as a consistent description of Interaction Signatures within the ODP computational viewpoint.

Interaction refinements

Operations and Flows versus Signals

As it is known now, The interaction models assist diverse sorts of interaction. Moreover, these interaction models do differ in their failure traits. The parties involved in a flow or operation may have an incoherent sight of an interaction at various times, particularly, when failures have taken place.

The execution of operations is stretched out in space and time. This is the reason why, when an operation failure arises, the participators may consider it at different times, as the breakdown need not appear for all them.

For interrogations and announcements, the facility of the client to detect and act on failures is distinct. For interrogations, the two flight path handshake guarantees either the server substantiates the performance of the function that has been supplicated by the client, and that; the server replies to the invocations in the same sequence the client has called them after an appeal to a chain of interrogations has already been triggered by a client thread of activity. In contrast, for announcements, the environment contracts that put on the operations, neither provides any insurances of the achievement of invocations, nor establishes their order of execution.

One can use flows in order to model, for example, the flow of audio or video information in a multimedia application or in voice-based telecommunication services, or the continuous flow of periodic sensor readings in a process control application [START_REF] Iso/Iec | Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use ISO/IEC CD 10746-1[END_REF]. There can be several distinct meanings for flows, relying on the application area. Therefore, the precise semantics of flows is left unfixed in the computational model. Now, in comparison to streams and operations, a signal either comes through or crashes alike for both partakers in the interaction. Thus, there is no concept of halfway failure of a signal.

A signal is a pairwise, atom like minute action out coming in one-way communication from an initiating object to a responding object, bearing in mind that, responding signifies accepting the communication in this context of use. As a consequence of this, a signal is a reference point for measurement ends, in QoS observations for instance; and that, to all participants, a failure is observable and one and the same for all of them since signals comes up at a determined point in time. The definition of the concept does not exclude the implementation of signals via transaction mechanisms which provide the fundamental behaviour guarantees and, in several cases a signal will coincide, in implementation words, with a visible occurrence at some physical place.

An operation or a flow can be resolved in terms of a composition of several individual signals. For instance, we can interpret an interrogation in terms of a sequence of four signals: invocation emission (by the client object), invocation receipt (by the server object), termination emission (by the server), termina-tion receipt (by the client) [START_REF] Iso/Iec | Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use ISO/IEC CD 10746-1[END_REF]. In opposition, since the computational model do not provide the precise semantics of flows, their mapping on signals is not defined.

In fact, a definition of flows using signals depends upon the details of the interactions abstracted in the specification of the stream interface concerned and therefore is beyond the scope of the ODP Reference Model [START_REF] Iso/Iec | Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use ISO/IEC CD 10746-1[END_REF].

Signals are the least degree of representation of interactions between computational objects. Now, since we know signals do provide the constructing bricks of all other interactions, it is tempting to make use of them in order to refine interactions in their terms. To do so, the computational language imposes rules on these mappings so as to provide for reliable refinements when required. This is exactly the purpose of the following section. Having said all of that, let's go right now in these refinements and see how they are concreted.

OCL constraints on interaction refinements

In this section, using the OCL language, we specify the constraints concerning the Operation to Signal refinement. these constraints ensure that the refinements are consistent to serve as basis for defining QoS Characteristics.

Client operation interface constraints

The two following constraints are relating to a client operation interface: First constraint: In a signal interface corresponding to a client operation interface there is a signal -invocation submit-corresponding to each invocation with the same parameters. This constraint is described using OCL as follows: Second constraint: in the case of an interface containing interrogations, a signal -termination deliver -corresponding to each possible termination with the same parameters as that termination. This constraint is described using OCL as follows:

Server operation interface constraints

The two following constraints relate to a server operation interface:

First constraint : in the signal interface corresponding to a server operation interface there is a signal -invocation deliver-corresponding to each invocation with the same parameters. This constraint is described using OCL as follows: Second constraint : in the case of an interface containing interrogations there is a signaltermination submit-corresponding to each possible termination with the same parameters as that termination. This constraint is described using OCL as follows: This creates an equivalence between the resulting set of signals and the set of invocations and terminations in the operation interfaces being described.

Conclusion and perspectives

In our past work [START_REF] Ouahidi | An UML-based Metalanguage for the QoS-aware Enterprise Specification of Open Distributed System[END_REF], we have proposed a UML-Based language for the QoS-aware enterprise specification of ODP systems in which we focused mainly on the specification of QoS from an enterprise viewpoint. When trying to deal with the QoS concepts within the computational viewpoint we have met with some issues as mentioned before. So, we decided to clarify some ambiguities relevant to the computational viewpoint.

In the other hand, the QoS in ODP framework states that QoS requirements on interactions between computational objects relate to QoS characteristics such as, transfer delay and jitter, throughput, error probability, security and precedence. It also states that QoS relations are by definition associated with individual objects, and hence they can refer only to elements pertaining to individual objects such as , in the computational viewpoint, occurrences of signals at interfaces belonging to an object.

In our current work we have shown how to refine an Operation Signature into a Signal Signature, and in doing so, we have created a laying underground, which will permits us to specify safely, Qos requirements on interactions from the computational viewpoint. Indeed, now we know exactly that QoS requirements on interactions in the computational viewpoint might be specified just using signals. Thus, our current work constitutes a pertinent link and a logical bridge between our past and future works, at the same time that it helps us to move forward confidently in our coming ones.

We are studying the relationship between the QoS enterprise specification and the QoS computational specification and paying particular attention to the specification of QoS requirements on interactions from the computational viewpoint, focusing our specifications only on signals. We are also investigating how to extend the QML (QoS Modelling Language) [START_REF] Frolund | QML: A language for Quality of Service Specification[END_REF] to specify and compose the QoS relations.

Figure 1 :

 1 Figure 1: Operation Signatures in terms of Action Templates

1 Figure 2 :

 12 Figure 2: Flow Signatures and Action Templates

Figure 3 :

 3 Figure 3: An UML model of Open Distributed Processing Interactions

  context op: OperationInterfaceSignature inv: self.causality='client' implies op.AnnouncementSignature→forAll(Ann| op.isrefinedto.ParameterizedActionTemplate→exists(s| Ann.Parameter.name=s.Parameter.name And Ann.Parameter.type=s.Parameter.type))

  context op: OperationInterfaceSignature inv: self.causality='client' and self.InterrogationSignature→notEmpty() implies op.InterrogationSignature.ParameterizedActionTemplate.invocation →forAll(inv| op.isrefinedto.ParameterizedActionTemplate→exists(s| inv.Parameter.name=s.Parameter.name and inv.Parameter.type=s.Parameter.type))