Robert Cole
email: robert.g.cole@us.army.mil

Ulrich Herberg
email: ulrich@herberg.name

Performance Analysis of SNMP in OLSRv2-routed MANETs

Keywords: OLSRv2, MANET, management, performance management, control, SNMP, performance study, simulation, NS2 OLSRv2, MANET, management, performance management, control, SNMP, performance study, simulation, NS2

Mobile Ad Hoc NETworks (MANETs) are generally thought of as infrastructure-less and largely "un-managed", capable of accommodating highly dynamic network topologies. Yet, while the network may be un-managed, monitoring performance and setting configuration parameters post-deployment, remains important in order to ensure proper "tuning" and maintenance of a MANET. While SNMP is sometimes considered too "heavy" for MANETsa too chatty a protocol with too large protocol messages -it remains the predominant management and monitoring protocol in the Internet, and many implementations exist. This memorandum analyzes SNMP in an OLSRv2-routed MANET, with the purpose of investigating performance metrics, such as delivery ratio, delay, management overhead, collisions and performance monitoring accuracy. In order to address concerns both regarding SNMP being "heavy", as well as regarding the accuracy of performance reports obtained via SNMP polling in MANETs, where path delays can be highly variable, the utility of performance reporting proxies, i.e. the REPORT-MIB, is studied. The obtained results show that a significant benefit can be obtained by so deploying performance reporting proxies in an SNMP managed MANET. The investigations are supported by way of network simulations (NS2).

Introduction

Mobile Ad Hoc Network (MANET) routing protocols are commonly assumed to be entirely self-managing: routers perceive the topology of a MANET by way of control message exchanges, with changes to the topology being reflected in routing tables of each router after a bounded convergence time. Usually, no operator intervention is required: variable parameters for the routing protocol are either negotiated in the control traffic exchange, or are of only local importance to each router (i.e. do not influence interoperability). Still, external management and monitoring of a MANET routing protocol may be desired, for optimizing routing protocol operation, e.g. to attain a more stable perceived topology, a lower control traffic overhead, and ultimately a higher data delivery ratio, a lower end-to-end delay, and less bandwidth and energy usage.

This memorandum analyzes the performance of the Simple Network Management Protocol (SNMP), the prevailing management and monitoring protocol in the Internet, in the context of an OLSRv2 routed MANET. OLSRv2 is currently in the process of being standardized by the MANET working group of the IETF1 . Further, this memorandum analyzes the benefits of performance reporting proxies for reducing network management overhead, and for improving the accuracy of performance reports in MANETs.

Surveys of performance aspects of SNMP exist, e.g. [START_REF] Andrey | Survey of SNMP performance analysis studies[END_REF], yet -to the best of the authors' knowledge -none consider performance in MANETs. [START_REF] Kuthethoor | Performance analysis of SNMP in airborne tactical networks[END_REF] proposes an extension to SNMP that allows aggregation, and presents a study of that extension applied in airborne tactical networks, with a static network of nodes arranged in a grid. However [START_REF] Kuthethoor | Performance analysis of SNMP in airborne tactical networks[END_REF] presents no general performance analysis.

Reasons for the lack of research in this area may be twofold: (i) SNMP may be considered too "heavy" for MANETs, yet as no alternative "light-weight" management protocol has been standardized, SNMP remains the (Internet) management protocol2 . (ii) Despite the 'S' in SNMP meaning "simple", SNMP is composed by a large corpus of RFCs, rendering a fully compliant implementation of SNMP for network simulators a daunting undertaking.

[4] presents a tool, AgentJ, which allows plugging unmodified Java protocols into NS2 for simulation studies. This memorandum uses AgentJ to plug "SNMP4J" [START_REF]SNMP4J Website[END_REF] and JOLSRv2 [START_REF] Herberg | JOLSRv2 -An OLSRv2 implementation in Java[END_REF] (Java implementations of OLSRv2 and SNMP) into NS2, as a basis for the studies undertaken.

Memorandum Outline

The remainder of this memorandum is organized as follows: Section 2 provides a brief overview of OLSRv2 and SNMP. Section 3 describes the motivation for monitoring and controlling OLSRv2 routed MANETs. Section 4 presents a management architecture for OLSRv2, including the role of performance reporting proxies, e.g. the REPORT-MIB [20]. Section 5 describes the simulation settings for the performance analysis of SNMP and the REPORT-MIB in OLSRv2-based MANETs, and details the results. This memorandum is concluded in section 6.

Overview of OLSRvand SNMP

This section outlines OLSRv2 and SNMP.

OLSRv2 Overview

The Optimized Link State Routing Protocol version 2 (OLSRv2) [START_REF] Clausen | RFC5444: Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format[END_REF]9,10,11] is a successor to the widely deployed OLSR [12] routing protocol for MANETs. OLSRv2 retains the same basic algorithms as its predecessor, however offers various improvements, e.g. a modular and flexible architecture allowing extensions, such as for security, to be developed as add-ons to the basic protocol. OLSRv2 contains three basic processes: Neighborhood Discovery, MPR Flooding and Link State Advertisements. The basic operation of OLSRv2 is detailed in section 2.1.1 to 2.1.3 below, followed by the flexible message format used by OLSRv2, in section 2.1.4, and a discussion of the configuration and operation of OLSRv2 routers in section 2.1.5.

Neighborhood Discovery (NHDP)

The process, whereby each router discovers the routers which are in direct communication range of itself (1-hop neighbors), and detects with which of these it can establish bi-directional communication. Each router sends HELLOs, listing the identifiers of all the routers from which it has recently received a HELLO, as well as the "status" of the link (HEARD, verified bi-directional -called SYM). A router a receiving a HELLO from a neighbor b in which b indicates to have recently received a HELLO from a considers the link a-b to be bi-directional. As b lists identifiers of all its neighbors in its HELLO, a learns the "neighbors of its neighbors" (2-hop neighbors) through this process. HELLOs are sent periodically, however certain events may trigger non-periodic HELLOs. NHDP enables each router interface to apply a hysteresis function which, in addition to the message exchange, may constrain when a link is considered as "usable" or not: for example, a router may elect to not consider, and thus not advertise, a link as SYM or HEARD unless a certain ratio of HELLOs are received, unless the SNR reaches a given threshold, etc. Symmetrically, a router may decide to stop advertising a link as SYM or HEARD, subject to similar such constraints.

MPR Flooding

The process whereby each router is able to, efficiently, conduct network-wide broadcasts. Each router designates, from among its bi-directional neighbors, a subset (MPR set) such that a message transmitted by the router and relayed by the MPR set is received by all its 2-hop neighbors. MPR selection is encoded in outgoing HELLOs.

Link State Advertisement

The process whereby routers are determining which link state information to advertise through the network. Each router must advertise links between itself and its MPR-selector-set, in order to allow all routers to calculate shortest paths. Such link state advertisements, carried in TC messages, are broadcast through the network using the MPR Flooding process. As a router selects

INRIA

MPRs only from among bi-directional neighbors, links advertised in TCs are also bi-directional. TC messages are sent periodically, however certain events may trigger non-periodic TCs.

Flexible Message Format

OLSRv2 employs the format specified in [START_REF] Clausen | RFC5444: Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format[END_REF], for all protocol messages, thereby enabling scope-limited message flooding, compact (aggregated) address representation, also of non-contiguous network addresses, and the ability to associate any number of arbitrary attributes to either of control messages or addresses, by way of inclusion of Type-Length-Value objects (TLVs). The TLV structure permits any given message to be parsed correctly by allowing an implementation to "skip over" TLVs not recognized, thus enabling extensions to be developed that embed information into existing OLSRv2 control messages.

OLSRv2 Router Configuration

The configuration of an OLSRv2 router consists of the set of prefixes "owned", and thus advertised, by the router, as well as interfaces of that router, participating in the OLSRv2 routing protocol. For each such interface, a set of parameters (other than the IP address(es)) apply: control message emission intervals, hysteresis values and link quality estimations. Agreement between OLSRv2 routers on these values is not required for interoperability: link quality and hysteresis affect only which links a given router permits to become SYM or HEARD. Control message emission intervals and message content validity are encoded in outgoing control messages, by way of TLVs, such that a recipient router can correctly process these, regardless of its own configuration.

SNMP Overview

The Structure of Management Information (SMI) standardizes a way of exposing management data (system configuration, performance measurements, etc.) by way of defining a set of objects on the managed devices. These objects may then be read and, if appropriate, set in a standardized manner via SNMP. This, by way of a Network Management System communicating with an agent on the managed device -in this case, an OLSRv2 router. SNMP and SMI do not mandate a specific set of objects to read or set, on a device, but defines a standardized way for a device to present such objects -a Management Information Base (MIB). A SMI defines modules of related management objects within such a MIB.

Three versions of SNMP exists. SNMPv1 [13] specified a set of basic network management capabilities, including a basic security model. SNMPv2 [14] extended the functionality of SNMP, notably for retrieving more voluminous data through a single request. SNMPv3 [15] saw improvements to the security model, and otherwise left the protocol as in SNMPv2. The Structure of Management Information version 2 (SMIv2) [16] is the current version of SMI, and allows designing and describing the management model for the system, protocol or device being managed. SMIv2 allows for the definition of fairly complex management models, yet allows for simplicity of chosen implementations through the definition of Compliance statements within the MIB.

As indicated in section 2.1.5, OLSRv2 imposes few constraints on valid router configuration parameters. Fundamentally, the only parameter upon which agreement is required for interoperability is C -a constant, used to fix the scale and granularity of the validity and interval time values, included in protocol control messages. [9] proposes a value for this constant. As control messages carry validity time and interval time values, a recipient OLSRv2 router can behave appropriately, even if it uses vastly different values itself, so long as the recipient and sender use the same value for C.

Link admittance, by way of the hysteresis values and link quality estimation are used for an individual router to determine a suitable threshold for "considering that a link could be a candidate for being advertised as usable", and thus do not need agreement.

Still, external monitoring and management may be desirable in an OLSRv2 network. A network may benefit from having its control message emission tuned according to the network dynamics: in a mostly static network, i.e. a network in which the topology remains stable over long durations, the control message emission frequency could be decreased in order to consume less bandwidth or less energy. Conversely, of course, in a highly dynamic network, the emission frequency could be increased for improved responsiveness.

This example requires a more "global view" of the network, than that of a single OLSRv2 routeri.e. entails that a Network Management System is able to inquire as to various performance values of the network (e.g. to discover the network dynamics), and to set various router parameters (e.g. tune up or down emission intervals). Thus, a first-order task is to identify suitable management data for an OLSRv2 routed MANET, and to describe these by way of MIBs for use by an SNMP Network Management System. A second-order task is to develop a proxy in order to (i) provide highly accurate performance measurements in delay variable MANETs and (ii) minimize SNMP overhead in the MANET.

OLSRv2 Management Architecture

The OLSRv2 management system architecture consists of three MIB modules: NHDP-MIB [18], OLSRv2-MIB [19], and the REPORT-MIB [20]. Both the NHDP-MIB and the OLSRv2-MIB consist of different groups, allowing (i) changing protocol parameters such as message intervals (e.g. for HELLOs) and information validity times (e.g. hold times), and (ii) monitoring the router state (e.g. the neighbor set).

As is standard for SNMP management architectures, a Network Management System interacts with the various components of the device models directly over the network. However, frequent polling for object values in such a system involves a frequent and bandwidth-consuming message exchange -prohibitive in a MANET where connectivity often is wireless. Further, because of highly variable network delays in such MANETs, it is not possible for a management application to determine the time associated with object values obtained via polling. In order to specifically address these issues of performance management over low bandwidth and high latency networks, the proposed OLSRv2 management sys-INRIA tem architecture includes a proxy capability, denoted REPORT-MIB [20]. This proxy is located in close proximity to the managed devices, and offers remote generation of performance reports established via the management application using Remote Monitoring (RMON) [17] style control and reporting. The proxy then polls (locally) for the current values of the relevant objects necessary for the generation of the performance reporting. Hence, the bulk of the SNMP traffic is removed from the MANET and is isolated to local interaction.

[21] provides further details regarding the MIBs modules and how they allow monitoring performance of NHDP and OLSRv2.

Performance Study of SNMP for OLSRv2

In order to understand the implications when running SNMP in an OLSRv2 routed MANET, this section presents a performance study of SNMP in the NS2 simulator. Typical performance metrics -such as delivery ratio, delay, overhead, collision ratio and performance measurement accuracy -are evaluated.

Simulation Settings

Simulations have been conducted with JOLSRv2 [START_REF] Herberg | JOLSRv2 -An OLSRv2 implementation in Java[END_REF], a fully-compliant Java implementation of OLSRv2, as routing protocol, and SNMP4J [START_REF]SNMP4J Website[END_REF], a Java implementation of SNMP, hooked into NS2 using AgentJ [START_REF] Herberg | Development Framework for Supporting Java NS2 Routing Protocols[END_REF]. According to [START_REF]SNMP4J Website[END_REF], "SNMP4J is an enterprise class free open source and state-of-the-art SNMP implementation for Java 2 SE 1.4 or later. SNMP4J supports command generation (managers) as well as command responding (agents). Its clean object oriented design is inspired by SNMP++, which is a well-known SNMPv1/v2c/v3 API for C++ [...]."

Simulations have been performed using the scenario parameters in table 1. Each presented data point represents an average over 10 simulation runs of randomly generated scenarios, each corresponding to these parameters. Proposed default values of [11] In all scenarios, one router (with ID of 0) is positioned at exactly the center of the simulated area, and does not move. This router runs an SNMP manager.

All other routers run an SNMP agent, providing the NHDP-MIB [18] and the REPORT-MIB [20].

For the first set of simulations, the SNMP manager continuously sends requests ("get-next-request") for the NHDP parameter N_HOLD_TIME to all other routers, one by one. The manager starts sending these requests after 10s, in order to allow routing tables to converge. UDP is used as transport protocol. Each request has a a 500ms timeout, i.e. the manager aborts the request if no response has been received after 500ms, and proceeds to send a request to the next router. 25 seconds after the first request is sent, all routers have been interrogated and either responded or timed out (50 routers • 500ms timeout). The manager, then, restarts interrogating the first router again -resulting in each router being interrogated 25 times during the simulation.

Simulations are run using SNMPv2c, SNMPv3 without authentication or privacy ("SNMPv3"), SNMPv3 with SHA authentication only ("SNMPv3 (SHA)"), SNMPv3 with authentication and privacy (denoted "SNMPv3 (SHADES)" [22] and "SNMPv3 (SHAAES128)") [23] 3 .

For the second set of simulations, the impact of performance reporting proxies, i.e. the REPORT-MIB, is investigated. For these simulations, the manager polls each router 20 times over a 10 second window to collect counter values for performance reports, corresponds to standard SNMP operation for data collection for performance monitoring. With the REPORT-MIB implemented locally on each router, the SNMP manager needs only to interact with the routers twice during this period: first, to set up the report control, and, second to collect the performance report from the local REPORT-MIB instance.

The goal of these simulation studies is to measure the reduction of SNMP overhead when using the REPORT-MIB -as well as to estimate the accuracy of the performance reports generated in MANETs, where path delays may be highly variable. Specifically, SNMP management applications typically poll periodically for a common set of objects for the purpose of computing performance statistics related to state of performance objects on managed devices.

Let V be the value associated with an SNMP object of interest. Typically, management applications are interested in the rate of change of the value of this object, i.e.:

a(t) = ∂V (t) ∂t (1)
where a(t) represents the actual value of the quantity of interest. SNMP management applications estimate this derivative as:

e(t) = V (t 2 ) -V (t 1 ) t 2 -t 1 (2)
where V (t i ) is the value of the SNMP object at time t i and e(t) represents the estimate of a(t) at time t between t 1 and t 2 .

Because of the distance between the management application and the managed device, there typically is some variation in the round trip delay between these devices. This causes an error in the derived estimate, termed m(t) for measured.

+ - d σ + - d σ req( t + ∆ ) + - d σ + - d σ + - 1 + = t ) d 2 σ resp( t" 1 V(t' 1 ) + - = t + d 2 σ 2 ) resp( t" V(t' 2 ) t' 2 + - d σ = t + ∆ + t' 1 + - d σ = t + V(t' 2 ) V(t' 1 ) req(t) Client Agent
Fig. 1. Impact of delay variation on SNMP performance data collection.

first, to set up the report control, and, second to collect the performance report from the local REPORT-MIB instance. The goal of these simulation studies is to measure the reduction of SNMP overhead when using the REPORT-MIB -as well as to estimate the accuracy of the performance reports generated in MANETs, where path delays may be highly variable. Specifically, SNMP management applications typically poll periodically for a common set of objects for the purpose of computing performance statistics related to state of performance objects on managed devices.

Let V be the value associated with an SNMP object of interest. Typically, management applications are interested in the rate of change of the value of this object, i.e.:

a(t) = ∂V (t) ∂t (1)
where a(t) represents the actual value of the quantity of interest. SNMP management applications estimate this derivative as:

e(t) = V (t 2 ) -V (t 1 ) t 2 -t 1 (2)
where

V

B. Simulation Results

This section present ure 2 depicts the accu OLSRv2 during the si of forwarded message prisingly, increases wit Referring to Figure 1 the measured result can be written, using ∆ = t 2t 1 , as:

m(t) = V (t 2 ) -V (t 1 ) t 2 -t 1 ∼ V (t 2 ) -V (t 1 ) ± 2σ( ∂ ∂t V ) ∆[1 ± 4( σ ∆ )] (3)
which reduces to (given the definitions of the actual, measured and estimate):

m(t) ∼ e(t) 1 ± 4( σ ∆ ) ± 2( σ ∆ ) a(t) e(t) (4)
Assuming that the actual and the estimate are identical, then:

m(t) ∼ e(t) 1 ± 6( σ ∆ ) (5)
where m(t) is the result as measured by the SNMP network management application, e(t) is the estimate available if computed locally on the managed device, ∆ is the time difference between the SNMP requests (e.g. polls) sent from the SNMP manager (the inverse of the polling frequency) and δ is the standard deviation of the one-way delay between the SNMP manager and the managed device, assumed to be identical for both directions across the network.

In the following, the results of the NS2-simulations will be used to develop estimates of the error between m(t) and e(t), illustrating the value of the REPORT-MIB for MANETs.

Simulation Results

This section presents the obtained simulation results. Figure 2 depicts the accumulated transmitted control traffic of OLSRv2 during the simulation, counting each retransmission of forwarded messages. The control traffic overhead, unsurprisingly, increases with the number of routers in the network. Figure 3 depicts the control traffic in a network with 50 routers, for different router velocities (except for router 0, which is static). The control traffic overhead is higher than in a static scenario, but otherwise mostly constant from 5 m/s. The reason for the difference between a static and a mobile scenario is that JOLSRv2 supports "triggered" HELLO and TC messages, generated when links break or appear between routers.

Figure 4 depicts the accumulated SNMP traffic for the different SNMP versions and security mechanisms. Again unsurprisingly, traffic grows linearly with the number of routers (and, thus, SNMP agents) in the network. SNMPv2 exhibits a far lower overhead than SNMPv3. SNMPv3 with authentication only (SHA) exhibits a higher overhead than SNMPv3 without authentication, but less than both tested encrypted SNMPv3 variants (which have an almost equal overhead).

SNMP messages for the different versions tested contain different amount of security related parameters, accounting for the differences in overhead incurred. Table 2 depicts the message sizes of the get-next-request message that is sent from the manager to the agents, measured with Wireshark between two physical routers using the same SNMP implementation, SNMP4J, as in the simulations.

SHADES and SHAAES128 have similar SNMP message sizes, confirming the almost equal plots in figure 4. The payload (the PDU) is of equal size in both, due to the mode of operation of the block cipher (see [24]). SHADES applies CBC (Cipher-block Chaining), which splits the plaintext in multiples of 8 bytes with possible padding. As the payload happens to be a multiple of 8 bytes, the cypher text has the same length as the plaintext. SHAAES128 uses a CFB (Cipher Feedback) operation mode, which always outputs the same length as the input plaintext.

Another reason for the different total SNMP traffic is the number of transmitted messages. Figure 5 compares SNMPv2c with the SHAAES128 variant of SNMPv34 . With SHAAES128, for each pair of routers exchanging SNMP messages, an additional initial message exchange has to be performed in order to provide replay protection, illustrated in Figure 6. For SNMPv2, the get-next-request is directly sent and answered, whereas SNMPv3 exchanges the Authoritative EngineID and a counter of how often the agent has been rebooted, in order to provide replay protection. For the simulations presented in this memorandum , this initial exchange of parameters is only performed for the first request from the manager to an agent, not in any subsequent one -which explains why the plot in figure 5 for SNMPv3 show only slightly more frames set than SNMPv2.

Figure 7 depicts the MAC frame collision ratio. As the amount of OLSRv2 control traffic and SNMP unicast traffic increases with the number of routers in the network, so does the collision ratio. There is no significant difference between the different SNMP variants as the SNMP traffic makes up only a small fraction of the total traffic in the network. Note that this is no general observation: in the simulated scenarios, no concurrent SNMP message exchanges take place, and no other unicast data traffic is present in the network.

Figure 8 depicts the collisions for different router velocities. As OLSRv2 control traffic accounts for the majority of the traffic in the simulation, and as that control traffic does not considerably increase with velocity, as depicted in figure 3, the collision ratio remains stable, at about 12%. Figure 9 depicts the message exchange delay between transmission of the get-next-request and the reception of a response by the manager. As the number of routers in the network increases, so does the message exchange delay across all SNMP variants. SNMPv3 and SNMPv3 with privacy incurs higher delays because of the initial message exchange for replay protection, depicted in figure 6. 7), the delivery ratio is relatively high, increasing network density. There is no significant difference observed between the different SNMP variants. Figure 11 depicts the delivery ratio for SNMP messages when routers are mobile. The delivery ratio decreases as the velocity increases, but remains at a relatively high level -because of the low collision ration, combined with the relatively low number of hops from the manager to all agents. Figure 12 depicts the average path length, measured in number of hops, between the SNMP manager and the agents. There is no significant difference between the different SNMP variants.

Beyond this basic understanding of the behavior of SNMP in an OLSRv2network, the impact of the REPORT-MIB as an SNMP performance management proxy in MANET environments is of interest. Specifically, the subsequent Figure 13 depicts number of frames sent when polling (as in standard SNMP) is used, as well as when the REPORT-MIB proxy is used. While the reduction in overhead when using the REPORT-MIB is substantial, note that this results in reports being generated only after the equivalent of 20 polling intervals. The SNMP manager interacts with each router only twice per report (configure report collection, collect performance report). Of course, the results will depend in general on the relative relationship of the report duration to the polling intervals, as well as other aspects of the network.

Equation 5 approximates the error in performance reports generated through the standard SNMP polling method, where the network manager is responsible for generating performance reports based upon collected SNMP counter. The error in these reports is related to the uncertainty on the measured times on the managed devices due to the possibility for highly variable path delays in MANETs.

Figure 14 depicts the average, standard deviation and maximum delays, experienced by these SNMP polls. These results show that the standard deviation of the round trip delays of the polls can be significant. These results can be considered as extremely conservative, as there is no other data traffic in the MANET.

Figure 15 depicts estimates of the accuracy of the performance reports, as generated through standard SNMP polling methods and based upon equation 5 and on the simulation results. The error in the performance reports can become quite significant. The middle curves in the figure are the estimates based on the simulation results, where the maximum reporting error is roughly 6% for the 50 node results. Polling at a lower frequency can improve the error estimate overhead in the MANET due to the placement of the REPORT-MIB proxy on the managed device, as well as to quantify the reduction in the potential error in the performance reports due to larger and varying path delays occurring in MANETs.

Figure 13 depicts number of frames sent when polling (as in standard SNMP) is used, as well as when the REPORT-MIB proxy is used. While the reduction in overhead when using the REPORT-MIB is substantial, note that this results in reports being generated only after the equivalent of 20 polling intervals. The SNMP manager interacts with each router only twice per report (configure report collection, collect performance report), Of course, the results will depend in general on the relative relationship of the report duration to the polling intervals, as well as other aspects of the network.

Equation 5 approximated the error in performance reports generated through the standard SNMP polling method, where the network manager is responsible for generating performance reports based upon collected SNMP counter. The error in these reports is related to the uncertainty on the measured times on the managed devices due to the possibility for highly variable path delays in MANETs.

Figure 14 depicts the average, standard deviation and maximum delays, experienced by these SNMP polls. These results show that the standard deviation of the round trip delays of Figure 15 depicts e mance reports, as gen methods and based u results. The error in th significant. The middl based on the simulatio error is roughly 6% fo frequency can improv two lower curves, wh interval.

Care must be taken as the assumption th performance statistic a small can break, if the Finally, the upper t the standard deviation would be the case if th traffic") in the networ large errors in the per generated through sta Deployment of the R routers would elimina reporting errors.

V

The MANET routi any operator interven to accommodate freq a self-organizing man as to enable a netw with heterogeneous c desirable to monitor t and to tweak parame the routing protocol, e change over time.

This paper analyze SNMP, the predomina -illustrated in the two lower curves, which assume a five times longer polling interval.

Care must be taken when increasing the polling interval, as the assumption that the difference between the actual performance statistic a(t) and the sampled estimate e(t) was small can break, if the polling interval becomes too long.

Finally, the upper two curves present the expected error if the standard deviation of the delay increased 5 times, such as would be the case if there was other data traffic ("background traffic") in the network. This illustrates the potential for very large errors in the performance reports that would have been generated through standard SNMP polling over a MANET. Deployment of the REPORT-MIB proxy on the MANET routers would eliminate the existence of these performance reporting errors.

Conclusion

The MANET routing protocol OLSRv2 does not require any operator intervention once deployed: routers are able to accommodate frequently changing network topologies in a self-organizing manner, and the protocol is designed so as to enable a network to accommodate OLSRv2 routers with heterogeneous configurations. However, it may still be desirable to monitor the performance of a deployed network, and to tweak parameters for improving the performance of the routing protocol, e.g. if the conditions of the deployment change over time. the polls can be significant. These results can be considered as extremely conservative, as there is no other data traffic in the MANET. Figure 15 depicts estimates of the accuracy of the performance reports, as generated through standard SNMP polling methods and based upon equation 5 and on the simulation results. The error in the performance reports can become quite significant. The middle curves in the figure are the estimates based on the simulation results, where the maximum reporting error is roughly 6% for the 50 node results. Polling at a lower frequency can improve the error estimate -illustrated in the two lower curves, which assume a five times longer polling interval.

Care must be taken when increasing the polling interval, as the assumption that the difference between the actual performance statistic a(t) and the sampled estimate e(t) was small can break, if the polling interval becomes too long.

Finally, the upper two curves present the expected error if the standard deviation of the delay increased 5 times, such as would be the case if there was other data traffic ("background traffic") in the network. This illustrates the potential for very large errors in the performance reports that would have been generated through standard SNMP polling over a MANET. Deployment of the REPORT-MIB proxy on the MANET routers would eliminate the existence of these performance reporting errors. This memorandum analyzes the performance of SNMP, the predominant management and monitoring protocol for routers in the Internet, in OLSRv2routed MANETs. Different evaluation metrics are considered, such as delivery ratio, delay, overhead, collisions, both in static and in mobile networks. Different variants of SNMP, notably SNMPv2c, SNMPv3 without authentication or privacy, SNMPv3 with SHA authentication only, and SNMPv3 with authentication and privacy (AES128 and DES) are studied. This memorandum also analyzes the impact of performance reports collected through standard SNMP polling methods in the presence of large path delays and path delay variations, such as may occur in MANETs. These standard SNMP performance reporting methods generate a relatively large overhead in the network. Further, the accuracy of the resulting reports can be greatly diminished because of these delay variations. Colloquially speaking, SNMP polling across a MANET gives the worst possible result: a large traffic load on the network, resulting in erroneous, or at least inaccurate, results. This memorandum demonstrates both of these effects, as well as presents the benefits of a reporting proxy, i.e. the REPORT-MIB, for reducing the management overhead and in improving the accuracy of performance reports in these challenging MANET environments. col for routers in the Internet, in OLSRv2-routed MANETs. Different evaluation metrics are considered, such as delivery ratio, delay, overhead, collisions, both in static and in mobile networks. Different variants of SNMP, notably SNMPv2c, SNMPv3 without authentication or privacy, SNMPv3 with SHA authentication only, and SNMPv3 with authentication and privacy (AES128 and DES) are studied. This paper also analyzes the impact of performance reports collected through standard SNMP polling methods in the presence of large path delays and path delay variations, such as may occur in MANETs. These standard SNMP performance reporting methods generate a relatively large overhead in the network. Further, the accuracy of the resulting reports can be greatly diminished due to these delay variations. Colloquially speaking, SNMP polling across a MANET gives the

Fig. 2 .Figure 3

 23 Fig. 2. OLSRv2 accumu

Figure 1 :

 1 Figure 1: Impact of delay variation on SNMP performance data collection.

Figure 2 :

 2 Figure 2: OLSRv2 accumulated control traffic throughout the simulation

Figure 3 :Figure 4 :

 34 Figure 3: OLSRv2 accumulated control traffic throughout the simulation in a network with 50 routers and variable router velocity.

Figure 5 :

 5 Figure 5: Number of transmitted SNMP messages

Figure 6 :Figure 7 :Figure 8 :

 678 Figure 6: SNMP message exchange: (a) in SNMPv2 (b) in SNMPv3 with privacy

Figure 9 :

 9 Figure 9: Message exchange delay Figure 10 depicts the delivery ratio for SNMP messages. With a low collision ratio (figure7), the delivery ratio is relatively high, increasing network density. There is no significant difference observed between the different SNMP variants.

Figure 10 :

 10 Figure 10: Delivery ratio of SNMP messages

Figure 11 :

 11 Figure 11: Delivery ratio in network a with 50 routers and variable router velocity.

Figure 12 :

 12 Figure 12: Average path length

Fig. 13 .

 13 Fig. 12. Average path length

Fig. 14 .

 14 Fig. 14. The average, stan the SNMP polling over the

Figure 13 :

 13 Figure 13: The reduction polling overhead in terms of frames due to the deployment of the Report-MIB.

Fig. 14 .

 14 Fig. 14. The average, standard deviation and maximum round trip delay for the SNMP polling over the MANET.

Figure 14 :

 14 Figure 14: The average, standard deviation and maximum round trip delay for the SNMP polling over the MANET.

  Maximum error, background traffic Average error, background traffic Maximum error Average error Maximum error, low freq Average error, low freq

Fig. 15 .

 15 Fig. 15. The typical and maximum error in standard SNMP performance reporting.

Figure 15 :

 15 Figure 15: The typical and maximum error in standard SNMP performance reporting.

Table 1 :

 1

		NS2 parameters
	Parameter	Value
	NS2 version	2.34
	Mobility scenario	Random walk
	Grid size	1000m x 1000m
	Number of routers	10 -50
	Communication range	250m
	Radio propagation model Two-ray ground
	Simulation time	270 secs
	Interface type	802.11b
	Radio frequency	2.4 GHz
	OLSRv2 parameters

Table 2

 2

		: SNMP sizes
	Variant	Frame size SNMP message size PDU size
	SNMPv3	140	103	48
	SNMPv3-SHA	146	109	48
	SNMPv3-SHADES	159	122	48
	SNMPv3-SHAAES128	163	125	48

The Internet Engineering Task Force: http://www.ietf.org

The IETF has standardized NETCONF[START_REF] Enns | RFC4741: NETCONF Configuration Protocol[END_REF] in 2006, but not with the focus on constrained devices such as MANET routers RR n°7407

RR n°7407

Some implementations, e.g. SNMP4J and Cisco SNMP, provide other ciphers such as SHAAES192, SHAAES256 and SHA3DES, however these have not been standardized, and have therefore not been considered.INRIA

For the other encrypted variants the results are similar INRIA


María De Los

Reyes Grangel Seguer

Michel Bigand

Jean-Pierre Bourey
email: jean-pierre.bourey@ec-lille.fr

Transformation of Decisional Models into UML: Application to GRAI Grids

Keywords: ENTERPRISE MODELLING, MODELLING MODEL TRANSFORMATION, UML Profile model transformation, GRAI decisional model, UML profile

Model Driven Engineering (MDE) significantly improves the software development process as well as enterprise integration. Based on both modelling and transformation activities it is possible to link models at different levels of abstraction in a classical forward engineering process in order to produce code or, in a reverse engineering process, to produce models from code by a bottom-up approach. But it can also be used to bridge the gap between models belonging to different domains that use different formalisms. This paper therefore focuses mainly on the transformation of decisional models belonging to the Enterprise Modelling domain into UML models used in the Information Technology domain. This kind of transformation is one component of a more general model-driven approach to solve business process interoperability problems or, more widely still, integration problems. More precisely, the paper describes two UML Profile definitions used to transform GRAI Grids into UML Use Case Diagrams or Activity Diagrams. The implementation of these Profiles with the Atlas Transformation Language (ATL) is presented and results are compared and discussed.

Introduction

Enterprises must fit their functions and processes to those of others in order to improve their competitiveness and to take advantage of new market opportunities.

Both Business Process and Enterprise Modelling techniques and methods have been successfully used by enterprises to integrate their information and manufacturing systems throughout the last few decades [START_REF] Vernadat | Enterprise Modeling and Integration: Principles and Applications[END_REF]. However, the rapid evolution of technology means that enterprises need to advance ever faster, and they must establish collaborative networks, such as Extended and Virtual Enterprises, so as to be able to take advantage of their core competences and to look for others that they do not have [START_REF] Tae-Young | A modeling framework for agile and interoperable virtual enterprises[END_REF]. New problems, such as Business Process Integration or Interoperability, arise in collaborative enterprises. Solving these interoperability problems not only at the code level but also starting from a higher level of abstraction is a challenge that was one of the objectives proposed by INTEROP NoE [START_REF] Interop | Interoperability Research for Networked Enterprises Applicationsand Software NoE[END_REF], and more precisely by Task Group 2 (TG2), in order to search for solutions to achieve interoperability following a model-driven approach (Grangel et al. 2005, Chen and[START_REF] Chen | European initiatives to develop interoperability of enterprise applications-basic concepts, framework and roadmap[END_REF].

The aim of TG2 has been to analyse and propose guidelines and methods that can help to solve the interoperability problems of Enterprise Software Applications (ESA) starting out from the enterprise models level and using an approach based on Model Driven Architecture (MDA) [START_REF] Omg | MDA Guide Version 1.0.1[END_REF]. This method is called Model Driven Interoperability (MDI) [START_REF] Grangel | Solving Problems in the Parametrisation of ERPs using a Model-Driven Approach[END_REF]. The work of TG2 first focused on the models and transformations to be performed at the Computation Independent Model (CIM) level from the theoretical point of view. At this level the GRAI 1 method [START_REF] Doumeingts | GIM (GRAI Integrated Methodology) and its Evolutions -A Methodology to Design and Specify Advanced Manufacturing Systems[END_REF][START_REF] Berio | Project UEML, WP3, Deliverable D3.3, Requirements Analysis: initial core constructs and architecture[END_REF] was chosen as means to capture the enterprise models and the UML was selected to play an interface role between enterprise models and IT models. To address the feasibility of its proposal, TG2 has tested it with transformation tools. More precisely, from the Business Process Modelling point of view, TG2 first worked on model transformation from GRAI Extended Actigrams to UML Activity Diagrams [START_REF] Bourey | INTEROP NoE: Deliverable DTG2.2: Report on Model Interoperability[END_REF]).

The paper focuses on the transformation of the decisional model which is an important model at business level. It is organised as follows: section 2 describes the context of the study and section 3 gives an overview of model transformation concepts. In Section 4 the basic constructs of GRAI Grids are presented and two first mappings with semantic losses are described and discussed. Then, in Section 5 two UML profiles to avoid semantic losses are defined and they are implemented within a transformation tool presented in Section 6. Finally, Section 7 outlines the main conclusions.

Context of the Study

Model Driven Engineering focuses on models as the primary artefacts in the development process, with transformations as the primary operation on models which is used to map information from one model to another [START_REF] Bézivin | Search of a Basic Principle for Model Driven Engineering[END_REF]. Model Driven approaches aim to provide large scope solutions to improve software development processes. These kinds of approaches can also be useful for performing model transformations in the Enterprise Modelling context as well as for contributing to solve interoperability problems [START_REF] Jardim-Gonçalves | Challenging the interoperability between computers in industry with MDA and SOA[END_REF].

Enterprise Modelling is perceived as a prerequisite to achieve integration, and it can also help to solve interoperability problems starting from a higher level of abstraction than code. It is defined by [START_REF] Vernadat | Enterprise Modeling and Integration: Principles and Applications[END_REF] as the art of externalising enterprise knowledge and know-how, which represents the Enterprise in terms of its organisation and functions (activities, information, resources and organisation units, and system infrastructure and architecture). It is also the process of drawing up models of the whole or part of the enterprise that include its different functions.

Enterprise Modelling is achieved through by using Enterprise Modelling Languages (EML). In this context, there are several formalisms which deal with Enterprise Modelling, such as GRAI [START_REF] Doumeingts | GIM (GRAI Integrated Methodology) and its Evolutions -A Methodology to Design and Specify Advanced Manufacturing Systems[END_REF][START_REF] Berio | Project UEML, WP3, Deliverable D3.3, Requirements Analysis: initial core constructs and architecture[END_REF], CIMOSA [START_REF] Berio | New developments in enterprise modelling using CIMOSA[END_REF], PERA [START_REF] Williams | The Purdue Enterprise Reference Architecture[END_REF], IDEF [START_REF] Idef | Integrated DEFinition Methods[END_REF], and so forth. The GRAI methodology, which was created and developed by the research group LAP/GRAI at the University of Bordeaux 1, is a well-known Enterprise Modelling methodology.

One of its strengths is that it takes into account both the decisional and the functional aspects together, as well as the informational and business process aspects. All these aspects are considered from both a general and a local point of view. GRAI Grids are defined to model the global functional and decisional aspects and GRAI Nets are used for local modelling of decision processes. GRAI Extended Actigrams are dedicated to Business Process Modelling. The GRAI methodology has been acknowledged and approved (by the IFIP and the IFAC) as one of the three important Enterprise

Modelling methodologies together with CIMOSA and PERA.

However, one of the main weaknesses of EML is the difficulty involved in establishing strong links between enterprise and software models [START_REF] Grangel | Enterprise Modelling, an overview focused on software generation[END_REF]. This paper addresses one part of this issue (more precisely the Decisional aspects) by defining a transformation of GRAI Grids. On the other hand, UML2 , which has been successfully used to model and develop IT systems in different domains, can also be useful in the context of Enterprise Modelling (Marshall 2000, Eriksson and[START_REF] Eriksson | Business Modeling with UML: Business Patterns at Work[END_REF]. It is the most widely known Object Management Group™ (OMG™) adopted specification, as an object-oriented modelling language used to model applications in the context of Software Engineering. For these reasons, UML is a good candidate to establish links between the contexts of Enterprise Modelling and Software Engineering and, therefore, to fill the gap between these two domains.

Model Transformations

The objective is to transform a source model Ma into a target model Mb. One of the most commonly used techniques for model transformation is known as the Metamodel Approach [START_REF] Omg | MDA Guide Version 1.0.1[END_REF] which is based on the Model Transformation Pattern shown in Figure 1. In this approach, the first step consists in defining the source and target metamodels (resp. MMa and MMb) which define the languages used to build the models (resp. Ma and Mb). Each model conforms to its metamodel. Then a mapping (Tab) between the metamodels is built. This process consists in establishing correspondences between the constructs in each metamodel. This mapping can be defined as a simple table showing the construct matching. For example, in [START_REF] Cuenca | From UML or DFD models to CIMOSA partial models and enterprise components[END_REF] found. This kind of table can be used as a set of specifications to be implemented by using more formal and executable languages (like XSL, general programming languages or transformation dedicated languages such as ATL [START_REF] Jouault | ATL: a QVT-like transformation language[END_REF]).

In this case the language that is used conforms to its metamodel MMt. By using an executable language it is possible to perform the transformation Tab from any input model Ma conforming to MMa in order to generate the corresponding target model

Mb conforming to MMb. The transformation pattern in Figure 1 is obviously not limited to a one-to-one model transformation, but it can be adapted in a Modelweaving context [START_REF] Milewski | The model weaving description language (MWDL)-Towards a formal aspect oriented language for MDA model transformations[END_REF].

Figure 1. Model Transformation Pattern from [START_REF] Allilaire | ATL -Eclipse Support for Model Transformation[END_REF] In our study MMa is the GRAI Grid metamodel and will be described in the following section. MMb is the UML metamodel which is fully defined in (OMG 2009). Two target models will be considered:

GRAI Grids

Within the GRAI methodology [START_REF] Doumeingts | GIM (GRAI Integrated Methodology) and its Evolutions -A Methodology to Design and Specify Advanced Manufacturing Systems[END_REF][START_REF] Doumeingts | Decisional modelling using the GRAI Grid[END_REF][START_REF] Berio | Project UEML, WP3, Deliverable D3.3, Requirements Analysis: initial core constructs and architecture[END_REF]), three formalisms have been defined: GRAI Grids are defined to model the comprehensive functional and decisional aspects, and GRAI Nets are used for local modelling of decision making processes. GRAI Extended Actigrams are dedicated to Business Process Modelling. This paper addresses one part of the transformation of GRAI models and, more precisely, the transformation of GRAI Grids into UML models.

Transformations of GRAI Extended Actigrams into UML Activity Diagrams with semantic losses was studied in [START_REF] Grangel | Transforming GRAI Extended Actigrams into UML Activity Diagrams: a First Step to Model Driven Interoperability[END_REF], Bourey et al. 2006) and a UML profile for preserving semantics was proposed in [START_REF] Grangel | A UML profile for transforming GRAI Extended Actigrams into UML[END_REF].

GRAI Grids are intended to provide a general cartography of periodic decision making inside an enterprise. Thanks to a matrix representation, they emphasise the temporal scope of a decision as well as the functional analysis of the enterprise.

The rows define the Decisional Levels (for instance, Strategic, Tactical, Operational) and are characterised by both a Horizon and a Period. The Horizon defines the time limit for reaching the objectives. The Period is a subdivision of the Horizon and defines the period of time beyond which the decision could be reconsidered in order to reach the objective at the end of the Horizon.

The columns are macroscopic Functions of the enterprise. GRAI nets are not presented in greater detail in this paper but a thorough description of them can be found in [START_REF] Doumeingts | Decisional modelling using the GRAI Grid[END_REF] and [START_REF] Berio | Project UEML, WP3, Deliverable D3.3, Requirements Analysis: initial core constructs and architecture[END_REF]. From this first informal description, the first task was to formalise the GRAI Grid modelling language by means of its Metamodel. The two main class diagrams of this metamodel are presented in Figure 4 and Figure 5. OCL constraints [START_REF] Omg | Object Constraint Language 2[END_REF] were defined to ensure the consistency of the formalism described by this metamodel.

GRAI Grid Transformation

Mapping Proposals

The objective is to establish a bridge from the Enterprise Modelling domain to the Software Engineering domain and, more precisely, from the comprehensive modelling of decision-making represented by means of GRAI Grids to another formalism belonging to the Software Engineering domain. Due to its broad coverage and use, UML was chosen as the target formalism for this study. The method to establish this bridge consists in:

1) defining a first mapping from GRAI Grids to UML by finding the basic concepts of UML that are the closest to the GRAI Grid concepts; since the central component of a GRAI Grid is the Decision Centre, the first step consists in choosing the UML target for the Decision Centre and then defining the other related UML targets in order to obtain a consistent model from the point of view of UML semantics; 2) filling the semantic gap between the source and target concepts in order to completely define a mapping; 3) implementing the mapping within a tool using a Model Transformation Language.

A first study on this mapping was proposed by [START_REF] Darras | Proposal of a formal framework for the design and use of an Enterprise Resource Planning software[END_REF]), but the results partially covered the first step and were based on UML 1.5. In the following, the three steps will be covered and the latest UML adopted specification will be used (i.e. UML

(OMG 2009))

. In order to define a consistent mapping from GRAI Grids onto UML, two viewpoints can be considered. The first one involves taking the consistency of relations between modelling components into account: if a GRAI Grid source construct SC1 is mapped onto a target UML construct TC1, and SC1 is linked to a second source construct SC2, then SC2 must be mapped onto a UML target construct TC2 that is linkable to TC1 and complies with the UML metamodel. The second viewpoint consists in taking the purposes of the decision-making modelling into account and then finding the most appropriate UML constructs as targets for the mapping definition.

From the first viewpoint, to ensure the consistency between the relations throughout the mapping definition, a bottom-up approach can be considered starting with the mapping of GRAI Nets. Actually, GRAI Nets are extensions of GRAI Extended Actigrams and can therefore easily be transformed into UML Activity Diagrams as proposed in [START_REF] Grangel | Transforming GRAI Extended Actigrams into UML Activity Diagrams: a First Step to Model Driven Interoperability[END_REF][START_REF] Grangel | A UML profile for transforming GRAI Extended Actigrams into UML[END_REF]. As previously mentioned, a GRAI Net is associated to a Decision Centre, which is the central construct of a GRAI Grid. Therefore, GRAI Decision Centres must be mapped onto a UML construct so that it can be expanded into UML Activity Diagrams. This problem of defining a consistent mapping respecting the hierarchical breakdown of GRAI Grids into GRAI Nets is represented in Figure 6. Therefore it is necessary to navigate into the UML metamodel to find which UML concepts can be broken down into Activities. An excerpt of the UML metamodel is shown in Figure 7. On this excerpt we can notice that an Activity is a specialisation of the abstract metaclass Behavior. Moreover an Activity is composed of Activity Nodes that are transitively specialised into CallBehaviorActions that are associated to the Behavior they call. In other words, that means that an activity can contain CallBehaviorActions calling activities that can be considered as sub-activities.

Therefore Activity is a candidate as target of a grid and thus its CallBehaviourActions are possible targets for transformation of Decision Centres. In this case GRAI grids will be represented on Activity Diagrams. On the Figure 7, we can also see that the UseCase metaclass is a specialisation of the abstract metaclass BehavioredClassifier.

This metaclass has a composition relation with the Behavior metaclass. By using the specialisation relationship between Activity and Behavior, that means that a Use case can be broken down into an Activity. Therefore Use Cases can be used as target for transformation of Decision Centres. Moreover, Use cases are packageable elements and use case diagrams can contains packages. Therefore GRAI grids can be mapped onto packages and represented on Use Case Diagrams. Figure 8 shows the summary of these two proposals Engineering approach, a GRAI Grid (and more precisely a Decision Centre) can be considered from two points of view:

• from a requirement-oriented point of view: each Decision Centre is considered to • a requirement on how a decision has to be made. In this case, the most appropriated UML construct for the mapping of a Decision Centre is a Use Case. • from a process-oriented point of view: in this case, the focus is more on the flows (Decision Frames and Information Flows) and the schedule of decisionmaking. Therefore, UML Activity Diagrams are good candidates for the translation of GRAI Grids.

These two last proposals are consistent with the mapping of GRAI Nets onto UML Activity Diagrams as well as with the bottom-up approach presented earlier.

The following two sections will detail each mapping proposal. In order to fill the semantic gap, these mappings will be completed by the Profile definitions discussed in Section 5.4. Section 5.5 will recall the main components of a UML Profile and Sections 5.6 and 5.7 will describe the proposed profiles.

First Mapping onto UML Use Case Diagram

In this case, GRAI Grids are considered to be a set of requirements on how a decision has to be made. or to one and only one package. The consequence is the following: a mapping of GRAI grids onto UML using use cases has to give the priority to one of the both dimensions: temporal or functional dimension. In this paper, the functional breakdown has been chosen: packages will be used as target for the transformations of the functions and temporal information carried by the lines representing the Decisional Levels of the grids will be considered as secondary information.

Nevertheless the approach presented in this paper could be used for the dual approach giving priority to the line and considering the functional breakdown as a secondary aspect.

External and internal Information

First Mapping onto UML Activity Diagram

The second approach consists in mapping GRAI Grids onto UML Activity. In order to ensure the consistency of refinement of the Decision Centre into GRAI Nets, Decision The two justifications are the following:

• since we have given the priority to the functional breakdown for the mapping of grids onto use case diagram, it will be easier to compare the results produced by the both approaches.

• even if we choose a bidimensional structure taking both the lines and the columns of the grid into account by creating both horizontal and vertical Activity Partitions, temporal information about horizon and period will be lost in this first mapping (see section 5.4).

This mapping is consistent with the GRAI Function breakdown since a UML the semantic gaps. In this paper, only the first approach is investigated through the definition of UML profiles presented in the next sections.

Activity

UML Profile Definition

A profile is a specific version of UML. Generally, a profile is first defined by means of a domain model which represents the new concepts and their relationships as well as a description of their semantics. Then the mapping of these new concepts onto UML constructs is defined through a set of extension elements applied to the UML basic constructs. Therefore, a UML Profile can be considered as being a lightweight extension mechanism that adapts the UML Metamodel to one Specific Modelling Domain. A typical UML Profile is made up of stereotypes, tagged values and constraints (OMG 2009):

• Stereotypes: according to the UML 2.2 specification, these are specialisations of the metaclass Class and define how an existing metaclass may be extended.

Each stereotype may extend one or more metaclasses of the UML Metamodel through extensions as part of a profile. • Tagged Values: these are properties of a stereotype and are standard metaattributes.

• Constraints: these are conditions or restrictions expressed in natural language text or, better, in a machine-readable language such as OCL [START_REF] Omg | Object Constraint Language 2[END_REF]) that are classically used in UML to define the usage of a model element, and in the case of a profile definition, of a stereotype or of its tagged values. main problems of the first mappings that are presented is the loss of information. In the following sections, an approach based on the definition of UML Profiles is presented to tackle this problem when UML is considered as the target model. These profiles are defined to enrich the first mappings summarised in Figure 9 and 10: each stereotype presented in the following sections will extend the basic UML elements in the right-hand columns of Figure 9 and 10. These profiles are called respectively 'UML Profile for GRAIGrid2UCD' and 'UML Profile for GRAIGrid2AD'.

Profile for Transformation into UML Use Case Diagram

For this profile (shown in Figure 11), five stereotypes were created to extend the Package metaclass:

• graiDecisionalModel for the root element,

• graiGrid for the GRAI Grid structure,

• graiFunction for the columns associated to GRAI Functions or Subfunctions,

• graiExternalInformation for the left-most column of a GRAI Grid,

• graiInternalInformation for the right-most column of a GRAI Grid. The Use Case metaclass was extended by the stereotype graiDecisionCentre.

Since the rows (i.e. the Level) of GRAI Grids have no corresponding concepts in UML, their properties horizon and period have to be copied onto all UML elements corresponding to row members. Therefore, two attributes (i.e. tagged values) horizon and period were added to the stereotype graiDecisionCentre. This method was also used for the stereotype graiInformationSource to extend the metaclass Actor.

Finally, the Dependency metaclass was extended by two stereotypes to take completely into account the two types of flows used in GRAI Grids:

• graiInformationFlow, which possesses one attribute named 'type'with which to identify its nature (i.e. Internal or External), • graiDecisionFrame, containing four attributes to store the characteristics of a Decision Frame (i.e. objectives, decision variables, constraints and criteria).

Profile for Transformation into a UML Activity Diagram

As for the previous profile, nine stereotypes were defined (Figure 12) to fill the semantic gap between the GRAI Grid concepts and the basic constructs of UML. The main differences concern the extended UML metaclasses:

• graiDecisionalModel extends the metaclass Package,

• graiGrid is now an extension of Activity,

• graiFunction, graiExternalInformation and graiInternalInformation extend the ActivityPartition metaclass, • graiDecisionCentre is an extension of the CallBehaviorAction metaclass,

• graiInformationSource is used to extend CentralBufferNode,

• graiDecisionFrame and graiInformationFlow are extensions of ObjectFlow.

New Mappings

Taking these two profile definitions into account, two new mappings are proposed on Figure 13 and 14 for the 7 fundamental GRAI Grid concepts. These mappings are presented as tables where:

• the first column contains the GRAI Grid source concepts;

• the 'Conditions' column of the Figure 14 gives the conditions for generating different UML targets. For example, the Figure 14 shows that the transformation of Information Flow will depends on the fact that its source and target are Decision Centre or not; • the 'UML Targets' column shows the UML elements corresponding to the GRAI source concepts. For some GRAI source concepts only one UML element will be generated. For example, a GRAI Decision Centre will be transformed into a UML Use Case. But for other GRAI concepts, several UML elements will be generated. For example, in the case of transformation into a Use Case Diagram, a grid will generate 3 packages: one for the grid itself containing the two others associated to External Information and Internal Information; • the 'Stereotypes' column shows the stereotypes that will be applied to the corresponding UML targets; • the 'Tagged Values' column shows the names of the tagged values defined on the stereotyped UML targets with the possible values in case of enumerated types (for example, the tagged value 'type' defined on the 'graiInformationFlow' stereotype can be 'Internal' or 'External')

Figure 13. Mapping from GRAI Grid onto a UML Use Case Diagram using a profile Figure 14. Mapping from GRAI Grid onto a UML Activity Diagram using a profile

Application

In order to demonstrate the feasibility of the implementation of the two complete mappings using UML profiles presented in the previous sections, a model transformation language was used. This section presents first an overview of the language used and then a description of the results thus obtained.

ATL Overview

Atlas Transformation Language (ATL) is a Model Transformation Language that has been developed and specified by the ATLAS INRIA & LINA research group [START_REF] Lina | [END_REF], as an answer to the OMG's MOF/QVT Request For Proposal (RFP) [START_REF] Jouault | ATL: a QVT-like transformation language[END_REF]. ATL is a hybrid of declarative and imperative languages based on OCL [START_REF] Omg | Object Constraint Language 2[END_REF]. The preferred style of transformation writing is declarative, which means mappings can be expressed by rules. However, imperative constructs are provided so that some mappings, which are too complex to be handled declaratively, can be specified within rules by using imperative helpers.

A rule describes the transformation from a source model to a target model by relating metamodels. Each rule contains a unique name. It is introduced by the keyword 'rule' that is followed by the rule's name. In the source pattern, rules declare which element type of the source model has to be transformed. It consists of the keyword 'from', a source variable declaration and an optional precondition. This precondition is expressed using an OCL expression that restricts the rule triggering to elements of the source model that satisfy this precondition. When no filter is specified, the rule is executed for each input element whose type corresponds to the in variable declaration.

A first optional section introduced by the keyword 'using' can be used to declare local variables.

In the target pattern, rules declare to which element(s) of the target model the source pattern has to be transformed to. It may contain one or several target pattern elements. A target pattern element starts with the keyword 'to' and consists of a variable declaration and a sequence of bindings (assignments).

A second optional section of an ATL matched rule is the 'do' section. This section enables to specify a sequence of ATL imperative statements that will be executed once the initialization of the target model elements generated by the rule has completed. This imperative block can be used to initialise some model element features that have not been initialised using the declarative bindings, or to modify some already initialized features. This section will be used in the following to apply stereotype to a target element. The general structure of a rule is shown in the following code. Eight ATL rules were written in order to implement the complete mapping of the seven basic constructs of GRAI Grids onto UML Use Case Diagrams: two rules were needed for the transformations of GRAI functions, depending on their potential breakdown into subfunctions.

Ten rules were developed for the transformation into UML Activity Diagrams, including two for GRAI Functions and three for GRAI information flows according to the type of their source and target (Decision Centre or Information Source); indeed, to conform to the UML Metamodel, it is necessary to manage the input/output Pins of CallBehaviorActions for UML object flows.

The following sections present three kinds of rules: simple rule, rule with helper and rule with application profile.

Simple Rule

The first rule presented deals with the transformation of a GRAI Function into a UML Package without using the proposed Profile.

Rule with Helper

The rule presented in this section deals with the transformation of GRAI Information Flow. As presented in the previous section the transformation depends on the fact that the GRAI Information Flow is connected or not to a Decision Centre. This condition will be a precondition of the transformation rule. In order to increase the readability and reusability, a helper is defined on the source element 'Information Flow' (see code herafter). This helper, named 'isComingFromADecisionCentre', uses the association linking an Information Flow to its source through the association end 'source' of the association 'from' linking a Flow to a Node (see Figure 5). In this helper, 'self' references the current InformationFlow on which the helper is invoked.

Therefore 'self.source' references the instance of Node which is the source of the current Information Flow. On this Node, the OCL operation 'oclIsKindOf' in invoked to test if the node is a kind of Decision Centre. The same type of helper has been defined to test if an Information Flow has a Decision Centre as target. 1) The first one consists in defining the profile with an UML tool (IBM ® Rational Software Modeler ® (IBM 2009) or MagicDraw (MagicDraw 2009) for example). 2) In the second step, the profile is applied to the generated UML model. For example, in order to apply the profile called 'GRAIGrid2UCD' (GRAI Grid to Use Case Diagram) to a target UML model, the following statement must be added in the 'do' section of the rule creating the UML model:

target_UmlModel.applyProfile(UML2!Profile.allInstances()-> select(e | e.name = 'GRAIGrid2UCD').first());

3) The third step consists in applying stereotypes to the elements of the UML target model for which we want to keep additional semantics coming from the source model. The 'applyStereotype' method is invoked on the target element with an instance of the metaclass Stereotype as parameter. To get it, the 'getApplicableStereotype' method is invoked with the name of the stereotype to apply. For example, to apply the stereotype 'graiDecisionCentre' to the target UML Use Case called 'target_UmlUseCase' obtained after transformation of a GRAI Decision Centre, the following code must be added in the 'do' section of the rule creating a Use Case from a GRAI Decision Centre:

target_UmlUseCase.applyStereotype( target_UmlUseCase.getApplicableStereotype( 'GRAIGrid2UCD::graiDecisionCentre'));

4) Finally, for concerned target elements, tagged values of stereotyped UML model elements are set using the 'setValue' method. This method is invoked on a UML element and has three parameters: (1) the stereotype, (2) the name of the tagged value and (3) its value. For example, to assign a value to the tagged values 'horizon' and 'period' of a Use Case obtained after transformation of a GRAI Decision Centre according to its nature, the following code must be added in the 'do' section of the rule creating an Use Case from a GRAI Decision Centre, after the application of the stereotype 'graiDecisionCentre': In contrast to the work presented by [START_REF] Darras | Proposal of a formal framework for the design and use of an Enterprise Resource Planning software[END_REF], this paper has completely defined both the profiles and the mappings. Moreover, a complete implementation has been also carried out to validate the mapping proposals. This implementation has emphasised some inconsistencies of the mapping proposed in [START_REF] Darras | Proposal of a formal framework for the design and use of an Enterprise Resource Planning software[END_REF]), for instance concerning the direction of dependencies between use cases. Other mapping solutions have been also proposed in this paper dealing with Information Sources or Functions.

Discussion

Conclusion

This paper has focused on the transformation of GRAI Grids into UML. The first main contribution of this work is related to the definition of the metamodel of the GRAI Grid. This metamodel has been used to define a first mapping onto UML Uses

Cases and Activity Diagrams. In order to fill the semantic gaps between GRAI Grids and UML, two profiles have been proposed and implemented by means of a transformation language. This implementation has demonstrated the feasibility of the whole approach. This approach, which is not limited to GRAI Grids, makes it possible to establish a bridge between dedicated Enterprise Modelling Languages and a language that is widely used in the Software Engineering domain. It can be used within a vertical MDA approach to link the CIM and PIM levels. But this approach can also be used in a horizontal manner in order to transform enterprise models that are expressed using different formalisms into models using a single language in order to make it easier to define the interoperability needs between the enterprise systems.

The work currently in progress deals with a complete integration of the profiles defined for the semantic lossless transformations of the three GRAI formalisms (i.e. Grids, Nets and Extended Actigrams) into a single UML profile. This profile will take both the general and the local aspects of the decision-making, as well as business process modelling, into account. Future research will focus on the transformation of the other model types at the Enterprise Modelling Level (organisation, business date, services, and so forth) according to both vertical (i.e.

MDA-based) and horizontal (i.e. for solving interoperability problems) approaches.

At last model weaving techniques are currently studied as alternative solutions to preserve semantics during the transformation process.

1

  GRAI is a French acronym that can be translated into Graph showing Interrelations between Results and Activities

Figure 2

 2 Figure2shows an example of a GRAI Grid. In order to describe how each

Figure 2 .

 2 Figure 2. Example of a GRAI Grid

Figure 3 .

 3 Figure 3. Example of a GRAI Net

Figure 4 .

 4 Figure 4. GRAI Grid Metamodel: classes, generalisations and structural associations

Figure 6 .

 6 Figure 6. Problem of defining consistent mappings

  Sources are considered as information providers: they can be mapped onto Actors belonging to a specific Package. Finally, Information Flow and Decision Frames are directed relations than can be mapped onto Dependencies. Since a UML Dependency is defined from a client to a supplier(OMG 2009), it will be directed from the target of the Information Source or Decision Frame to its source in order to keep the logical dependency of the initial information and decision flows. As a graphical consequence, the resulting UML arrow points in the opposite direction to the GRAI arrow. A summary of the proposed mapping is shown in Figure9.

Figure 9 .

 9 Figure 9. First Mapping from GRAI Grid onto UML Use Case Diagram

  Centres are mapped onto CallBehaviorActions. The called behaviour is then the Activity corresponding to its GRAI Net. The Function a Decision Centre belongs to is mapped onto an Activity Partition graphically represented by swimlanes. Indeed, as mentioned into the UML Superstructure (OMG 2009): "They [Activity Partitions] often correspond to organizational units in a business model". The mapping of Functions onto Activity Partitions is then natural. Since it is possible to share elements between Activity Partitions, UML makes it possible to build multidimensional activity structures. However we will only keep the vertical functional view as privileged view.

  Figure 10. First Mapping from GRAI Grid onto UML Activity Diagram

  The profile definitions presented in the next two sections are devoted only to the transformation of GRAI Grids into Use Case Diagrams (called 'UML UCD' in the following) and into Activity Diagrams (called 'UML AD' in the following). They are part of a more general on-going work that aims to define a complete specialisation of UML for bridging all the GRAI formalisms (Extended Actigrams, Grids and Nets) with UML. Since the objective is both to transform GRAI Grids and to define UML profiles, the starting domain model for these profile definitions is the GRAI Grid metamodel presented in Section 4. As mentioned in the previous sections, one of the

Figure 11 .

 11 Figure 11. UML Profile for Transformation of a GRAI Grid into a UML UC Diagram

Figure 12 .

 12 Figure 12. UML Profile for Transformation of a GRAI Grid into a UML Activity Diagram

  variable declaration>] to <targetVariable> : <targetMetaModel>!<targetElement> (<assignments>) [do {<imperative statements>}] }--end of the rule

  rule GraiFunction2UmlPackage { from source_GraiFunction : GraiGridMetaModel!Function to target_UmlPackage : UML2!Package ( --the name is the same name <-source_GraiFunction.name, --the subfunctions of the current GRAI function --will be elements of the generated UML package packagedElement <-source_GraiFunction.subFunction ) --end of 'to' section } --end of the rule This rule simply copies the name of the source GRAI Function to the target UML Package. It also specifies that the results of the transformation of the subfunctions of the current GRAI Function will be elements belonging to the generated UML package.

  helper context GraiGridMetaModel!InformationFlow def : isComingFromADecisionCentre() : Boolean = self.source.oclIsKindOf(GraiGridMetaModel!DecisionCentre) ; The same type of helper has been defined to test if an Information Flow has a Decision Centre as target. helper context GraiGridMetaModel!InformationFlow def : isGoingToADecisionCentre() : Boolean = self.target.oclIsKindOf(GraiGridMetaModel!DecisionCentre) ; These two helpers have been used to define the preconditions of the rules implementing the mapping of Information Flows. Hereafter the source code corresponding to the mapping for Information Flows going from a Decision Centre to another one is given. the name name <-source_GraiInformationFlow.name, --assign to the main activity activity <-source_GraiInformationFlow.graiGrid )--end of 'to' section do { --code to link the generated Pins and ObjectFlow to the actions --that are the result of the transformation of decision centres --Not detailed in this paper }--end of 'do' section }--end of the ruleIn this rule, the 'to' section describes the binding between the source and the target properties. As described in the Figure14, this rule creates three UML target elements: an Input Pin, an Output Pin and an Object Flow. First, the Input Pin and the Output Pin are created. Their names are built by prefixing the name of the Information Flow by 'IP_IF_' and 'OP_IF_'. Then the Object Flow is created. Its name is set to the name of the Information Flow and the activity this generated Object Flow belongs to is set to the activity resulting from the transformation of the GRAI Grid the Information Flow belongs to. The 'do' section, not described here, contains the code making the links between the generated elements.

  ATL makes it possible to use UML Profiles. The method to use profile with ATL is made up of four steps.

Figure 15 and

 15 Figure 16 show the results obtained after the transformation of the GRAI Grid example of Figure 2 into respectively Use Case Diagram and Activity Diagram. Only the two left-most columns (i.e. External Information and To Manage Products, including its two subfunctions To Manage Procurement and To Manage Materials) and the three top-most rows are illustrated. These models were obtained by using first the ATL Development Tools (IDE developed for ATL on top of Eclipse) (Allilaire and Idrissi 2004) and then by importing the result into IBM Rational Software Modeler (IBM 2009) for visualising purposes.

Figure 15 .

 15 Figure 15. Excerpt from the Result of Transformation into UML Use Case Diagram

  Transformation of GRAI Grid into UML UC Diagram 229x101mm (96 x 96 DPI)

  a table for the mapping of UML use cases or DFD onto CIMOSA can be

	F o r
	P
	e
	e r
	R
	e
	v i e
	w
	O n l
	y

  column (i.e. functional breakdown). On the UML side, a package is a container for use cases, because use cases are packageable elements, but a use case belongs to zero

	F o r
	P
	e
	e r
	R
	e
	v i e
	w
	O n l
	y

Each requirement is represented by a Decision Centre which can be mapped onto a UML Use Case since they are both used to capture the requirements of a system, that is, what a system is supposed to do

(OMG 2009)

. Since Use cases are packageable elements, the Function a Decision Centre belongs to can be mapped onto a UML Package used as a Use Case container. If a Function is broken down, each subfunction is mapped onto a nested Package. Consequently, a GRAI Grid is also mapped onto a UML Package and a GRAI Decisional Model is mapped onto a UML Model in order to maintain the consistency of the structural hierarchy of the model.

However the bi dimensional structure of the GRAI grids is not kept: a Decision Centre belongs to both a line (i.e. Decisional Levels with temporal aspects) and a

Model Driven Architecture, MDA, Object Management Group, OMG, UML and XMI are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

URL: http://mc.manuscriptcentral.com/tandf/tcim Email:ijcim@bath.ac.ukInternational Journal of Computer Integrated Manufacturing

Acknowledgements. This work was initiated and partially funded by the EC within the 6th FP, INTEROP Network of Excellence (INTEROP 2007). The authors were indebted to TG2. It was also partially funded by the ASICOM project. This project started in April 2008 was approved by two French poles of competitiveness: PICOM in Trade Industries domain and Nov@log in Logistics domain.