Mariam Lahami
email: mariam.lahami@redcad.org

Fairouz Fakhfakh
email: fairouz.fakhfakh@redcad.org

Moez Krichen
email: moez.krichen@redcad.org

Mohamed Jmaiel
email: mohamed.jmaiel@enis.rnu.tn

Towards a TTCN-3 Test System for Runtime Testing of Adaptable and Distributed Systems

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Nowadays, a relevant issue in the software engineering research area consists in delivering software systems able to change their configuration dynamically in order to achieve new requirements and avoid failures without service interrupting. Therefore, they evolve continuously by integrating new components, deleting faulty or unneeded ones and substituting old components by new versions at runtime. Dealing with such reconfiguration actions, the possibility of unexpected errors (components failure, connections going down, etc.) during the reconfiguration process is unavoidable.

Accordingly, a validation technique, such as testing, has to be applied in order to detect as soon as possible such inconsistencies and to check functional and non-functional requirements after each dynamic reconfiguration. Nevertheless, traditional testing techniques cannot be done for these highly evolvable systems since they are applied during the development phase.

For this reason, a recent branch of work has demonstrated the interest of using the Runtime Testing as a new solution for the validation of the above systems [START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF][START_REF] Piel | Automating integration testing of large-scale publish/subscribe systems[END_REF][START_REF] Piel | Data-flow integration testing adapted to runtime evolution in component-based systems[END_REF][START_REF] Gonzalez | Architecture support for runtime integration and verification of component-based systems of systems[END_REF][START_REF] Niebuhr | Guaranteeing correctness of component bindings in dynamic adaptive systems based on runtime testing[END_REF][START_REF] Bai | Dynamic reconfigurable testing of service-oriented architecture[END_REF][START_REF] Greiler | Evaluation of Online Testing for Services A Case Study[END_REF][START_REF] King | Safe runtime validation of behavioral adaptations in autonomic software[END_REF]. They have focused on building specific test infrastructures, for instance based on the JUnit Framework. None of them have used a generic test standard like TTCN-3 for the specification or the execution of runtime tests. Furthermore, they are using at most one technique to isolate runtime tests in the aim of reducing the interference between business and test data. To the best of our knowledge, only one approach presented in [START_REF] Deussen | A TTCN-3 Based Online Test and Validation Platform for Internet Services[END_REF] uses TTCN-3 standard for online validation and testing of internet services. However, this work did not deal with test isolation issues when testing is applied in the production phase.

This paper makes a contribution in these directions by proposing a TTCN-3 test system for Runtime Testing (TT4RT). The key idea is to extend the reference architecture of the standardized TTCN-3 test system by a new module supporting different test isolation techniques. The latter is a fundamental issue that has to be tackled while executing runtime tests either components under test are testable or not testable. As illustrative example, we describe a case study in telemedicine area called Teleservices and Remote Medical Care System (TRMCS).

The remaining of this paper is structured as follows. Section 2 introduces the runtime testing approach and its challenges that we are facing.The TTCN-3 standard and its key elements are introduced in Section 3. The proposed approach is illustrated in section 4. Section 5 introduces the case study. Some scenarios are illustrated in Section 6. A brief description of related work is addressed in section 7. Finally, section 8 concludes the paper and draws some future work.

Runtime Testing Of Dynamic and Distributed Component based systems

Runtime testing is a novel solution for validating highly dynamic systems. It is defined in [START_REF] Brenner | Reducing verification effort in component-based software engineering through built-in testing[END_REF] as any testing method that has to be carried out in the final execution environment of a system while it is performing its normal work. It can be performed first at deployment-time and second at service-time. The deployment-time testing serves to validate and verify the assembled system in its runtime environment while it is deployed for the first time. For systems whose architecture remains constant after initial installation, there is obviously no need to retest the system when it has been placed in-service. On the contrary, if the execution environment or the system behavior and architecture have changed, service-time testing will be a necessity to verify and validate the new system in the new situation [START_REF] Brenner | Reducing verification effort in component-based software engineering through built-in testing[END_REF].

As previously mentioned in the definition of runtime testing, any test method can be applied at runtime such unit testing, integration testing, conformance testing, etc. In our work, we support unit testing as well as integration testing. On the first hand, unit testing is used to validate that the component behavior still conforms to its specification while it is running in isolation in the execution environment. On the other hand, integration testing is used at runtime to validate that the affected component compositions by the reconfiguration action still behave as intended. In order to minimize the number of testers to be deployed and the number of test cases to be re-executed, we apply unit and integration tests only on the affected parts of the system under test by a reconfiguration action. Consequently, the testing effort, cost and time will be reduced [START_REF] Lahami | A distributed test architecture for adaptable and distributed real-time systems[END_REF].

However, other challenges still persist such as test processes interference with the business processes of the running system due to their parallel execution. The best way to resolve such problem is the application of test isolation mechanisms widely discussed in [START_REF] Piel | Automating integration testing of large-scale publish/subscribe systems[END_REF][START_REF] Gonzalez | Architecture support for runtime integration and verification of component-based systems of systems[END_REF] (such as cloning components, adding a test interface, tagging test data, blocking components during test, etc). This challenging issue is resolved in our approach by supporting the well known test isolation mechanisms in the literature. It will be discussed in depth in following sections.

TTCN-Overview

TTCN-3 (Testing and Test Control Notation Language Version 3) is a test specification language used to define test procedures for reactive black-box testing of distributed systems [START_REF]ETSI: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language[END_REF]. This test standard has been widely used in the protocol testing field and is newly addressing other kinds of applications such as service-oriented or CORBA-based systems. It is also suitable for various types of tests such as conformance, robustness, regression and functional testing.

TTCN-3 allows the specification of dynamic and concurrent test systems. In fact, it offers a test configuration system made of two kinds of test components: Main Test Component (MTC) and Parallel Test Component (PTC). For each test case, an MTC is created. PTCs can be created dynamically at any time during the execution of test case. Thus, test system can use any number of test components to realize test procedures in parallel. Communications between the test system and the SUT are established through ports.

The structure of TTCN-3 test system is depicted in Figure 1. It is made up of a set of interacting entities where each one corresponds to a specific functionality involved in the test system implementation. These entities interact together through two major interfaces: the TTCN-3 Control Interface (TCI) [START_REF]ETSI: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI)[END_REF] and the TTCN-3 Runtime Interface (TRI) [START_REF]ETSI: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)[END_REF]. They are briefly described [START_REF] Schulz | Implementation of TTCN-3 Test Systems using the TRI[END_REF] as follows:

-The Test Management (TM) Entity manages the test execution.

-The Test Logging (TL) Entity is responsible for maintaining the test logs.

-The TTCN-3 Executable (TE) Entity executes the compiled TTCN-3 code. we can address complexity of testing evolvable systems which are also heterogeneous in structure and technologies. Hence, different network and platforms technologies can communicate easily with the TTCN-3 test system through the adaptation layer [START_REF] Rentea | Ensuring quality of web applications by client-side testing using ttcn-3[END_REF]. The latter comprises three parts of the reference architecture that are Coding-Decoding entity, Test Adapter entity and Platform Adapter entity. These entities provide means to adapt the communication and the time handling between the SUT and test system in a loose coupling manner. Due to all these features: a standardized, abstract and platform independent test-language and offering a flexible adaptation layer with the aim of facilitating interaction with the SUT, TTCN-3 was adopted in our work and also enhanced to support runtime testing.

The proposed Approach: TT4RT

Our main objective is to design and build a test system that handles complexity of testing evolvable and heterogenous (both in structure and technologies) systems. Therefore, we have enhanced the TTCN-3 test system by adding two layers as depicted in Figure 2: a Test Management Layer and a Test Isolation Layer. The main purposes of these layers are described in the following:

Test Management Layer. It intends to control the execution of runtime tests. It includes a GUI component called TTmanGUI. The latter is responsible mainly for starting and stopping test cases. The TTmanGUI interacts with the TM entity offered by the classical TTCN-3 test system in order to achieve the test execution management and also with test isolation layer in order to prepare the test environment.

We have to mention that this layer has as input an XML file which contains the components under test, the test components to deploy and their deployment hosts as well as the test cases to execute. This file is called Resource Aware Test Plan since the assignment of the test components to execution nodes must fit some resource constraints1 . The structure of this file will be introduced later.

Test isolation Layer. It aims to reduce the interference risk between test data and business data when testing is performed at runtime. It includes a component which is able to choose the most adequate test isolation technique for each component under test. This choice is suggested by using a policy called Test Isolation Policy. For each test request, the proposed policy is executed in order to generate the test isolation technique to apply. Our test system supports four test isolation techniques: duplication, blocking, tagging and built-in tests.

For reasons of space, these techniques are briefly introduced through some examples. For instance, if a component is not testable and it is under some timing constraints then it will be automatically duplicated. In this case, the test processes are executed in the duplicate with the aim of not disturbing the execution of the original component. Unless the component is under some timing constraints, it can be blocked until the test processes are achieved. Also, some components can be provided with some capabilities such as testability through a test interface or test awareness through a flag which lets the component under test differentiate between the test data and business data. The proposed policy treats all these conditions and produces the best solution when a test request is triggered.

Abstract Layer. As we have explained above, this layer is offered by the classical TTCN-3 test system in order to build abstract test suites. This feature makes runtime tests independent of the test execution environment and enhances their reusability and extensibility. All the specified test cases are compiled and stored in a repository in order to make them executable.

Adaptation Layer. It includes the implemented Coding/Decoding and System Adapter entities which facilitate the communication between TT4RT and the SUT in production phase. In order to detail the internal interactions in TT4RT system, a workflow illustrated by the Figure 3 is given:

-When a reconfiguration action is triggered, the test plan that describes the affected parts of the SUT by this dynamic change and the test configuration used to validate it, is generated. This plan is considered as an input to the TT4RT system (Step 1). -Test isolation policy is called for each component under test in order to choose the best test isolation technique (Step 2). -The appropriate test isolation technique is then used to prepare the test environment (Step 3). -After preparing the test environment, the test system user initiates the test execution through the TTmanGUI and by calling the adequate method in the TM entity TciStartTestCase (Steps 4-5). -Once the test process is started, the TE entity creates the involved test components and informs the SA entity that the test case has been started with the aim of allowing the SA entity to prepare its communication facilities. This is done through the call of triExecuteTestcase method (Step 6). -Next, TE invokes the CD entity in order to encode the test data from a structured TTCN-3 value into a form that will be accepted by the SUT. This is done through the call of encode method (Step 7). -The encoded test data is passed back to the TE entity as a binary string and forwarded to the SUT via the SA entity with the triSend method (Steps 8-9-10).

-After the test data is sent, a timer can be started. To achieve this, the TE invokes the triStartTimer method on the PA entity (Step 11). -The SUT returns its response to the SA entity. The given response is an encoded value that has to be decoded in order to be understandable by the TTCN-3 test system (Step 12). -For doing this, the SA entity forwards the encoded test data to the TE entity through the method triEnqueueMsg (Step 13). -The TE entity transmits the encoded response to the CD entity with the intention of decoding it into a structured TTCN-3 value (this is done through the call of decode method) (Step 14). -The decoded response is passed back to the TE that stops the running timer by invoking the triStopTimer method on the PA and finally computes the global verdict (Steps 15-16-17). -At last, the test system user is notified by the generated verdict (pass, fail or inconclusive) by the TTmanGUI (Step 18).

The gains of this design are the conformance to the TTCN-3 standard, generality and platform-independency (applicable to every component based or service oriented systems), reusability and extensibility (compiled code TTCN-3 is stored as jar files in a repository and can be loaded at any time and also updated dynamically without restarting TT4RT system). Furthermore, TT4RT can be used either at deployment time or at service time to validate the SUT. Instead the classical TTCN-3 test systems which consider the SUT as a black-box, TT4RT system treats the SUT as a grey-box (the SUT is composed of a collection of interacting components and compositions under test (CUTs)). This fact can help to localize easily the faulty component or composition and to proceed enhancement of the quality and reliability of the SUT.

Case Study

To illustrate our approach, we choose a case study in the telemedicine field. In fact, telemedicine has become an important research issue. It merges telecommunication and information technologies in order to provide remotely clinical health care. It facilitates communications between patients who suffer from chronic health problems and medical staff. In addition, it improves the access to medical services as well as the transmission of patient data (e.g monitored vital signs, laboratory tests, etc.) especially when critical events or emergency situations occur.

As widely described in the literature [START_REF] Chen | Pervasive Digital Monitoring and Transmission of Pre-Care Patient Biostatics with an OSGi, MOM and SOA Based Remote Health Care System[END_REF][START_REF] Varshney | Pervasive healthcare and wireless health monitoring[END_REF][START_REF] André | Distributed Dynamic Self-adaptation of Data Management in Telemedicine Applications[END_REF], telemedicine applications have to evolve dynamically in order to fulfill new requirements such as adding new health care services, updating the existing one in order to support improvements in wireless and mobile technologies, etc. This adaptability is essential to ensure that these applications remain within the functional requirements defined by application designers, as well as maintain their performance, security and safety properties. Furthermore, the execution environment of such applications is distinguished by its hardware heterogeneity (for instance PDA, PC and sensors) and the use of large range of wireless networking solutions like wireless LANs, ad-hoc wireless networks and cellular/GSM/3G infrastructure-oriented networks.

Due to these dynamic variabilities, medical errors and degradation of QoS parameters can occur. Therefore, runtime testing is required to validate dynamic system changes. Thus, this validation technique can improve health care quality and lead to the early detection and repair of medical devices malfunctions. In the following subsections, we present the architecture of the studied telemedicine application and also its implementation.

Architecture of TRMCS Case Study

The adopted telemedicine application is called Teleservices and Remote Medical Care System (TRMCS). The main behaviors and structure of such system are inspired from [START_REF] Inverardi | Software Architectures and Coordination Models[END_REF]. As depicted in Figure 4, TRMCS system provides monitoring and assistance to patients suffering from chronic health problems. The interacting actors in the system are :

-Medical staff which is composed of physicians, nurses, etc. These health care providers can be located in their own office, hospitals or even an ambulance car. -One or more patients who are located at their home and are equipped with wearable devices that can sense one or more vital signs such as blood pressure, respiration rate, pulse rate, oxygen saturation and body core temperature.

The wearable medical sensors measure and transmit biomedical data to local as well as remote medical data centers. They should operate autonomously and have to send alert signals when emergency problems arise.

The main functionalities that the TRMCS system supports are:

-The acquisition of biomedical data from patients equipped with wearable medical sensors. -The processing of monitored data by generating reports.

-The transmission of the monitored data, medical images, laboratory tests to a local as well as remote medical data centers for storage. -The analysis of monitored data by sending emergency signals when critical events are triggered or threshold conditions are reached2 .

The latter functionality is highlighted and used as proof-of-concept. Within the following studied scenario, the ability of TT4RT system to detect reconfiguration faults is demonstrated. Studied scenario. The initial architecture of the studied scenario is outlined in the Figure 5. Each patient sends different kind of help requests to different help centers such as doctor's office, nursery, hospital and ambulatory. This help request can be issued by the patient through a user GUI or raised automatically by the monitoring system. In this current implementation, we support three kinds of help requests: generating call, SMS or alarm signal. Reconfiguration scenario. It comes a moment when this system is changed to fulfill new requirements. For instance, the Alarm component is changed by a new version with the aim of increasing SUT performance and responsiveness. The new version sends the help request to the help center in a duration that does not exceed 15 time units instead of 30 time units for the old version. Once this reconfiguration is achieved, the new component and all the affected parts of the system by this modification have to be tested.

Implementation of TRMCS Case Study

In the literature, we have found some research works that use the Open Service Gateway initiative (OSGi) platform3 to implement such case study [START_REF] Chen | A Service Oriented Agent Architecture To Support Telecardiology Services On Demand[END_REF][START_REF] Chen | Pervasive Digital Monitoring and Transmission of Pre-Care Patient Biostatics with an OSGi, MOM and SOA Based Remote Health Care System[END_REF]. We follow the same technology choice due its dynamism (a powerful Framework to create highly dynamic applications). Thus, we implement the studied scenario using the OSGi Framework, especially OSGi iPOJO model4 . Under OSGi architecture, software components are encapsulated into bundles which is a java archive file that contains packages and service prerequisites. These bundles are loaded and run automatically by the Apache Felix5 1.8 implementation.

Without loss of generality, the proposed TT4RT system is used to validate this service oriented application 6 and to detect some previously seeded faults as outlined in the section below.

Validation of TRMCS by using TT4RT System

The key concepts presented so far have been used in order to keep the system quality at the same level after a dynamic update has taken place. Thus, we have applied some runtime tests to the evolvable sub-system while substituting the Alarm component by another version dynamically. The affected components and compositions by this modification, their testability options, the test cases to execute are specified in the generated Resource Aware Test Plan as outlined in the Figure 6. Furthermore, We have to mention that some faults have been seeded in the new configuration in order to assess the capabilities of TT4RT system to find these reconfiguration faults. It is worth noting that some inconsistencies are automatically detected by the OSGi Framework, for instance a required service crashing. Nevertheless, TT4RT is still required to detect other kinds of faults such erroneous results provided by the new service, incompatibilities between compositions, degradation of quality of service, etc.

Specifying the abstract test cases

Different test cases specified following the TTCN-3 notation are available to detect reconfiguration faults. In fact, TTCN-3 standard is used to define not only the behavior of each test component but also the dynamic and concurrent test configuration of each test request. First of all, the Listing 1 bellow outlines the adopted test configuration and highlights the different test components involved in this testing process.

1 testcase tc_substitute_alarm() runs on mtcType system systemType { 2 var ptcType ptc_alarm,ptc_alarm_nurse,ptc_alarm_hospital,ptc_alarm_doctor; The global test process is managed by the MTC component as defined in line 1. This MTC component is responsible for dynamically creating a PTC checking the new Alarm component (see line 3) and also three others PTCs for validation the communication between the affected compositions (alarm-nurse, alarm-hospital, alarm-doctor) as indicated respectively in line 8, 13 and 18. To start the execution of these test components, the map7 and start methods are used and the adequate function is called (see for example line 4 and 5). We have to mention that the instantiation of test components and communication links are done dynamically and the execution of their behaviors is done in a parallel manner. For instance, the next listing shows the behavior of one PTC validating the new Alarm component (ptcBehaviour alarm()). As depicted in the Listing 2, a timer is defined in line 2 and started in line 4 when testing data are sent (see line 3). It is used to validate the timing behavior of the new Alarm component that transmits the help request in a period of time smaller than 15 time units. If this deadline is not respected by the new version (see line 10) a fail verdict is generated as indicated in line 11. Otherwise, the functional behavior is validated and accordingly a partial verdict is computed (see line 7 and 9).

For editing and compiling the specified tests, we have used respectively the CL Editor (TTCN-3 Core Language Editor) and the TThree Compiler that are included in the TTworkbench basic tool 8 . The generated Jars are stored in the repository for further use and can be dynamically loaded during the execution when runtime testing is required to validate dynamic changes.

Preparing the test execution environment

Before executing the compiled tests, the test isolation policy is called in order to choose for each component under test the suitable test isolation technique. The testability options of each component involved in the testing process are specified in the resource aware test plan as depicted in Figure 6. In the current scenario, the Alarm component is test aware. It differentiates between test data and business data by using a test tag as illustrated in the test plan. The Nurse component is not testable. Thus, we use the default test isolation technique mentioned in the test plan file which is the duplication technique. In this case, a new component is created which handles the test request. Such solution aims not to disturb the original Nurse component. The same work is done for Doctor and Hospital components.

Executing runtime tests

Once the Resource Aware Test Plan is loaded and the test process is started through the TTmanGUI, the test environment is built and the test components are created dynamically. The Figure 7 highlights the main interaction between some components under test and the corresponding test components. For instance, it shows that the test component PTC alarm is created in order to validate the Alarm2 component. The latter is instructed to use both the testing data and business data. Thus, PTC alarm sends inputs data which is generated with the test tag and receive outputs in order to verify that the specified timing constraint is respected by the new component. Furthermore, affected compositions are also checked by test components like PTC alarm nurse. Due to the non testability of the Nurse component, it has been duplicated and the duplicate component is used while testing the composition under test behavior.

We follow the same principles for the rest of the components under test as specified in the resource aware test plan. Once the PTCs components terminate their specified behaviors, they are removed from the test configuration. The MTC component computes the global verdict which is finally displayed to the test system user through the TTmanGUI. The latter has been implemented using the Java language and the swing package. It has been packaged as an OSGi bundle. The Figure 8 shows the proposed graphical user interface also the final verdict of the executed runtime tests.

Related Work

Recent research activities have been proposed to deal with runtime testing in dynamic environments. They aim to ensure the correctness of the running system after reconfiguration. In fact, we distinguish approaches dealing with ubiquitous software systems [START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF], CBA systems [START_REF] Piel | Data-flow integration testing adapted to runtime evolution in component-based systems[END_REF][START_REF] Niebuhr | Guaranteeing correctness of component bindings in dynamic adaptive systems based on runtime testing[END_REF][START_REF] Gonzalez | Architecture support for runtime integration and verification of component-based systems of systems[END_REF], SOA systems [START_REF] Bai | Dynamic reconfigurable testing of service-oriented architecture[END_REF][START_REF] Greiler | Evaluation of Online Testing for Services A Case Study[END_REF], publish/subscribe systems [START_REF] Piel | Automating integration testing of large-scale publish/subscribe systems[END_REF] and autonomic systems [START_REF] King | Safe runtime validation of behavioral adaptations in autonomic software[END_REF].

Each of them proposes a test system tightly coupled with the system under test (SUT). In addition, they did not concentrate on proposing a generic and platform independent test architecture that evolves when the system under test evolves too. Moreover, they are based on only one technique to isolate runtime tests in the aim of reducing the interference between business and test data except [START_REF] King | Safe runtime validation of behavioral adaptations in autonomic software[END_REF] which supports two kinds of test isolation techniques. These approaches mostly used a specific language framework such as Junit to write and execute tests. None of them have used a generic testing language such as TTCN-3.

There have been many efforts on proposing test systems based on the TTCN-3 standard. We distinguish research for testing protocol based applications [START_REF] Schieferdecker | Realizing distributed ttcn-3 test systems with tci[END_REF][START_REF] Schulz | Implementation of TTCN-3 Test Systems using the TRI[END_REF], Web services [START_REF] Schieferdecker | Distributed functional and load tests for web services[END_REF][START_REF] Rentea | Ensuring quality of web applications by client-side testing using ttcn-3[END_REF], Web applications [START_REF] Stepien | Framework Testing of Web applications using TTCN-3[END_REF][START_REF] Li | Research on Web application software load test using Technology of TTCN-3[END_REF][START_REF] Din | Distributed load tests with ttcn-3[END_REF] and also real time and embedded systems [START_REF] Okika | Developing a ttcn-3 test harness for legacy software[END_REF][START_REF] Serbanescu | Real-time testing with ttcn-3[END_REF]. To the best of our knowledge, [START_REF] Deussen | A TTCN-3 Based Online Test and Validation Platform for Internet Services[END_REF] is the only previous paper presenting ideas on using TTCN-3 standard for online validation and testing of internet services. However, this work did not deal with test isolation issues when testing is applied in the production phase.

Unlike these approaches, our work aims at proposing a generic and platform independent test system based on the TTCN-3 standard to execute runtime tests. The proposed test system supports different test isolation mechanisms in order to support testing different kinds of components: test sensitive, test aware or even non testable components. Such test system has an important impact on reducing the risk of interference between test behaviors and business behaviors as well as avoiding overheads and burdens.

Conclusion

The work presented in this paper focuses on the use of TTCN-3 standard for executing runtime tests to reveal component based system inconsistencies and faults. Our main contribution consists in adding a test isolation layer in the classic TTCN-3 test system in order to reduce test data interference with business data at runtime. Furthermore, we add a test management layer that facilitates the interaction between a test system user and the TT4RT system through a graphical interface. We illustrated the proposed approach by implementing a prototype for validating OSGi bundles in the context of telemedicine applications. In addition, we shortly presented the technical solutions that we employed for the current implementation of our TT4RT system.

Nevertheless, distributing test configurations in different nodes remains unsolved. Hence, we are exploring solutions in this area to distribute efficiently test components with fitting some resource and connectivity constraints. Besides, this work does not deal with test cases generation. All the executed tests are specified manually. Therefore, we aim to investigate effort in automating TTCN-3 test cases generation, especially when behavior adaptation occurs. An-other area to explore is the optimization of test cases selection by re-testing only the affected parts of the system due to a reconfiguration action.

Fig. 2 .

 2 Fig. 2. Supported layers of TT4RT.

Fig. 3 .

 3 Fig. 3. The proposed workflow of the TT4RT system.

Fig. 4 .Fig. 5 .

 45 Fig. 4. Global view of Teleservices and Remote Medical Care System.

Fig. 6 .

 6 Fig. 6. The main features included in the Resource Aware Test Plan XML file.

3Listing 1 .

 1 ptc_alarm := ptcType.create("ptc_alarm"); 4 map(ptc_alarm:ptcPort, system:systemPort); ptcType.create("ptc_alarm_doctor"); 14 map(ptc_alarm_doctor:ptcPort, system:systemPort2); 15 ptc_alarm_doctor.start(ptcBehaviour_alarm_doctor()); 16 ptc_alarm_doctor.done; 17 18 ptc_alarm_hospital := ptcType.create("ptc_alarm_hospital"); 19 map(ptc_alarm_hospital:ptcPort, system:systemPort3); 20 ptc_alarm_hospital.start(ptcBehaviour_alarm_hospital()); 21 ptc_alarm_hospital.done; 22 } The test configuration.

1 2 timer 6 [ 8 [ 12 localtimer.stop; 13 }}Listing 2 .

 26812132 function ptcBehaviour_alarm() runs on ptcType { ] ptcPort.receive("Service invoked Successfully") 7 {setverdict (pass, "Test service alarm successfully");} ] ptcPort.receive 9 {setverdict (fail, "Something else received");} 10 [] localtimer.timeout 11 { setverdict (fail, "Timeout");} An example of a PTC behavior.

Fig. 7 .

 7 Fig. 7. Test components interaction with the affected components under test.

Fig. 8 .

 8 Fig. 8. Screenshot of the Prototype TTmanGUI of the TT4RT system.

Test System User TRI TCI Test Management(TM) Test Logging (TL) Coding and Decoding(CD) TTCN-3 Executable (TE) Main Test Component Component Handling(CH) Parallel Test Component System Under Test (SUT) System Adapter (SA) Platform Adapter (PA) TRI

	Fig. 1. TTCN-3 reference architecture.
	-The Coding/Decoding (CD) Entity encodes and decodes test data types and
	values.
	-The Component Handling (CH) Entity handles the communication between
	test components.
	-The SUT Adapter (SA) Entity implements communication between SUT
	and test system.
	-The Platform Adapter (PA) Entity implements timers and external func-
	tions.
	TTCN-3 is used in our context to define abstract test suites following the
	TTCN-3 notation. In this case, test suites are specified at an abstract layer,
	Abstract Test Suites (ATS). This feature helps to separate test design from test
	implementation and makes the ATS language platform independent. Further-
	more, it increases the reusability of the elaborated test cases. By doing this,

This assignment problem is not considered in this current work

For instance, when the heart rate exceeds a certain level of tolerance.

OSGi Alliance, http://www.osgi.org/markets/index.asp

http://felix.apache.org/site/apache-felix-ipojo.html

http://felix.apache.org/site/index.html

It is worthy to note that our TT4RT system can be used to validate either object or component based applications.

This method aims for connecting a port of a PTC to a port of SUT.

http://www.testingtech.com/products/ttworkbench.php


Mariam Lahami
email: mariam.lahami@redcad.org

Moez Krichen
email: moez.krichen@redcad.org

Mariam Bouchakwa
email: mariam.bouchakwa@redcad.org

Mohamed Jmaiel
email: mohamed.jmaiel@enis.rnu.tn

Using Knapsack Problem Model to Design a Resource Aware Test Architecture for Adaptable and Distributed Systems

This work focuses on testing the consistency of distributed and adaptable systems. In this context, Runtime Testing which is carried out on the final execution environment is emerging as a new solution for quality assurance and validation of these systems. This activity can be costly and resource consuming especially when execution environment is shared between the software system and the test system. To overcome this challenging problem, we propose a new approach to design a resource aware test architecture. We consider the best usage of available resources (such as CPU load, memory, battery level, etc.) in the execution nodes while assigning the test components to them. Hence, this work describes basically a method for test component placement in the execution environment based on an existing model called Multiple Multidimensional Knapsack Problem. A tool based on the constraint programming Choco library has been also implemented.

Introduction

Adaptable and distributed systems are characterized by the possibility of dynamically changing their behaviors or structures at runtime in order to preserve their usefulness and achieve new requirements. They evolve continuously by integrating new components, deleting faulty or unneeded ones and substituting old components by new versions without service interruption.

In order to preserve the system safety and consistency and to check functional as well as non-functional requirements during and after dynamic adaptation, a validation technique, such as Runtime Testing, has to be applied. It is defined in [1] as any testing method that has to be carried out in the final execution environment of a system while it is performing its normal work.

In a previous work [2], we have proposed a flexible and evolvable distributed test architecture made of two kinds of test components. These test components execute unit tests (respectively integration tests) on the affected components (respectively component compositions) with the aim of detecting reconfiguration faults. To do this, they send stimuli to the System Under Test (SUT) in order to verify that it responds as expected. The main challenging problem here is that the test execution is done while the SUT is running. Also, test components are usually deployed and executed in the same execution environment with the SUT. Consequently, SUT performance can be highly influenced especially when execution nodes have scarce resources or testing processes are very resource consuming.

Therefore, placing efficiently test components can be a useful solution to reduce runtime testing cost. This activity has to be resource aware by respecting all resource constraints in order not to disturb the SUT performance and not burden the execution nodes.

Various research efforts have addressed the resource aware testing activity such as [START_REF] Zhang | Resource-Aware Test Suite Optimization[END_REF][START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF]. They focus mainly on optimizing the generation of test cases with the best usage of available resources. To our best knowledge, there is only two visible research works [START_REF] Din | Distributed Load Tests with TTCN-3[END_REF][START_REF] Csorba | Experimenting with Dynamic Test Component Deployment in TTCN-3[END_REF] being carried out the issue of test component placement with respecting only some resource constraints and some user preferences. Connectivity constraints which are stated with the aim of reducing communications cost over the network between components under test and testers are ignored in these approaches.

In this paper, we propose a resource aware test architecture design phase before executing runtime tests while the system evolves dynamically. Essentially, we have studied the issue of test component placement in a shared execution environment with the SUT. Two main kinds of constraints are considered : resource and connectivity constraints. Hence, the most important question to be tackled in this paper is: How to place test components in the adequate nodes in order to fit these constraints? To solve this problem, we have modeled it using an existing model in the combinatorial optimization area, called Multiple Multidimensional Knapsack Problem. In addition, an implementation of a tool based on the Choco solver has been presented. Also, some experiments have been done to evaluate the proposed approach.

The remainder of this paper is organized as follows. We begin by a motivating example in Section 2. A brief description of related work is addressed in section 3. Section 4 overviews the resource aware test architecture design phase and outlines particularly the test component placement over the execution nodes fitting resource and connectivity constraints. In Section 5, we present our test component placement method based on the Knapsack Problem (KP) model. First, we introduce concisely the background of the standard KP and its diverse forms. Next, we illustrate the mathematical modeling of the placement problem using a new KP variant called Multiple Multidimensional Knapsack Problem. The realization of this approach is provided in Section 6. Some experiments for execution time measuring of the placement method are conducted in section 7. Finally, Section 8 concludes the paper and draws some future work.

Motivating Example

Consider an execution environment made of four nodes (N 1,N 2,N 3 and N 4) which are offering some free resources as illustrated in table 1. Some software components (C1,C2,C3,C4 and C5) are running and distributed among these nodes. We assume that a dynamic reconfiguration occurs and all these components are affected by this modification. Thus, they have to be tested in order to ensure that they still behave as intended. For this reason, some test components have to be deployed in this shared execution environment. These test components require some computational resources as depicted in table 2. With the aim of not disturbing the running SUT and reducing test burdens, they have to be assigned to the execution nodes efficiently while fitting some resource constraints. In this example, we consider just two kinds of computational resources: RAM and CPU. It is worthy to note that others resources like battery level and hard disk space can be included. Furthermore, we assume for simplicity that memories and processors in execution nodes have approximately the same capacities. Besides resource constraints, connectivity issue in the execution environment has to be also tackled. If all nodes are connected together as a strongly connex graph or even a connex graph (see Figure 1 (a),(b)), test components can be assigned to any node in the environment in order to perform runtime tests. Nevertheless, we are faced sometimes with some connectivity problems1 that can be arisen due to Firewalls, non-routing networks [START_REF] Maassen | Smartsockets: solving the connectivity problems in grid computing[END_REF], node mobility, etc. In this case, connectivity constraints have to be considered while assigning test components to nodes. For example, while non routing is performed between the node N 4 and the rest of the execution environment as depicted in Figure 1 (c) the test component T 4, which is responsible of testing the component under test (CUT) C5, can be hosted only in the node N 4. It is not allowed to place T 4 in N 1, N 2 or even N 3 because no route is available to communicate with the component under test C5. In the same way, the other test components can be assigned to any node except N 4. This illustrative example is detailed progressively in the following sections of the paper. Placement solutions are also given in section 5.

Related Work

Since runtime testing is performed while the system is operational, the business process execution may be affected by testing activities and the system performance may be negatively influenced. Therefore, test isolation techniques (such as SUT duplication, tagging, SUT blocking, etc.) are required to separate testing processes from business processes [START_REF] Piel | Automating Integration Testing of Large-Scale Publish/Subscribe Systems[END_REF][START_REF] Gonzalez | Testing Challenges of Maritime Safety and Security Systems-of-Systems[END_REF][START_REF] King | Safe Runtime Validation of Behavioral Adaptations in Autonomic Software[END_REF]. In addition, testing activities have to be resource aware with the aim of minimizing execution nodes burdens while runtime tests are executed. The first issue is out of the scope of this paper. We mainly concentrate on studying the resource aware testing activity [START_REF] Zhang | Resource-Aware Test Suite Optimization[END_REF][START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF].

Fitting resource and connectivity constraints while testing distributed and adaptable systems at runtime is included in a larger class called context aware testing [START_REF] Mei | A context-aware orchestrating and choreographic test framework for service-oriented applications[END_REF][START_REF] Flores | Towards context-aware testing for semantic interoperability on PvC environments[END_REF]. The latter has recently emerged to validate especially new class of software systems which are context aware and adaptive, also known as Ubiquitous or Pervasive systems [START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF]. This kind of systems can sense their surrounding environment and adapt their behavior accordingly. In [START_REF] Rodriguez | Dynamic Software Architecture Management for Collaborative Communicating Systems[END_REF], the author generally defines the context as any information that can be used to characterize the situation of an entity (which can be a person, a machine or any object including a service, a software component, or data). He divides context into two main categories: external context (which contains information about the users, their location, time, etc.) and resource context (which describes the available resources on nodes and communication links like memory, CPU load, battery level, bandwidth between two nodes, etc.). Various research efforts have addressed testing activity with considering resource context such as [START_REF] Zhang | Resource-Aware Test Suite Optimization[END_REF][START_REF] Merdes | Ubiquitous RATs: how resource-aware run-time tests can improve ubiquitous software systems[END_REF]. They focus mainly on optimizing the generation of test cases with the best usage of available resources but without studying the placement and the deployment cost of test components.

To our best knowledge, there is only two visible research works related to test component placement under resource constraints and user preferences. In the first work [START_REF] Din | Distributed Load Tests with TTCN-3[END_REF], the authors propose a function for distributing a set of test components, which are belonging to a test configuration implemented in TTCN-3 standard 2 [14], on different test nodes (computers that are dedicated for test execution). The proposed mathematical function is applied at deployment time separately for each test component in order to assign it to a node where it will be deployed and also executed. It considers two types of parameters when distributing test components in the adequate test nodes: external parameters such as CPU load, memory consumption and internal parameters like the number of components that can be hosted in a specific test node. The second work presented in [START_REF] Csorba | Experimenting with Dynamic Test Component Deployment in TTCN-3[END_REF] mainly focuses on the dynamic deployment of test components also implemented in TTCN-3 standard. It proposes an approach for designing load tests and distributing test components efficiently with considering the available workstation resources. The major problem here is that these approaches do not define explicitly the proposed distributed function used for test components assignment to test nodes. Moreover, they focus mainly on computational resources and they ignore connectivity constraints.

Unlike these approaches, our work aims at defining a novel method for assigning test components to execution nodes in a way fitting both resource and connectivity constraints. This challenging issue has been widely addressed in other research areas. First, an interesting work is presented in [START_REF] Portigliatti | Java Components with constraints and preferences in automatic administration of execution and placement[END_REF] that aims to optimize resource allocation and the placement of Java components by using a graph mapping approach. The latter consists in modeling the application by a software graph and the execution environment by a hardware graph. The main purpose here is to map as best as possible the software graph on the hardware graph. Other approaches have studied the placement issue based on constraint programming, which aims to model and solve combinatory problems, such as [START_REF] Pizzocaro | Sensor assignment in virtual environments using constraint programming[END_REF][START_REF] Hermenier | Reconfiguration dynamique du placement dans les grilles de calculs dirigée par des objectifs[END_REF]. By extending the Multiple Knapsack Problem model, [START_REF] Pizzocaro | Sensor assignment in virtual environments using constraint programming[END_REF] proposes a method for assigning sensors in virtual environments. Hermenier [START_REF] Hermenier | Reconfiguration dynamique du placement dans les grilles de calculs dirigée par des objectifs[END_REF] presents a flexible architecture that adapts the placement of virtual machines in grids with response to requirements analysis, resources states and some placement constraints defined by the user. The problem here is similar to Two-Dimensional Bin Packing problem. The classical problem consists in packing objects with different volumes into a finite number of bins having a predefined capacity in a way that minimizes the number of bins used. Following the same principle, Hermenier's work aims to minimize the number of nodes in the grid involved in the placement of virtual machines while satisfying resource constraints such as CPU load and memory consumption. Both introduced approaches use the Choco solver [START_REF] Jussien | Choco: an Open Source Java Constraint Programming Library[END_REF] in order to solve the placement problem. In the rest of this paper, our proposal that is inspired from the constraint programming based approaches will be highlighted.

Resource Aware Test Architecture Design

After a dynamic evolution of the system, runtime testing process is started to validate these changes. Only the affected parts of the system are considered in the testing activity. In Figure 2, two fundamental steps are outlined: Test Architecture Design and Test Component Placement. They will be detailed in the following subsections.

Test Architecture Design

This activity consists in defining for each affected component or composition the kind of test component to deploy and the test cases to execute. As illustrated in Figure 3, the elements involved in a distributed test architecture (DTA), their kind and their number depend on the affected parts of the system by a reconfiguration action. In our previous work [ In this work, we suppose that for each adaptation process a test manager which is responsible for controlling and managing all the runtime testing processes is introduced. It defines the adequate test architecture and assigns test cases. We also assume that during deployment phase, test cases are available and stored in a repository for further use. They can be also updated or new ones can be added if behavioral adaptations occur.

Test Component Placement

Once the distributed test architecture is elaborated, we have to assign its constituents to the execution nodes. It is worth noting that in this work we focus on assigning mainly single components testers to the execution nodes. The placement issue of component composition testers is out the scope of this paper.

Test component placement is more challenging when tests are executed at runtime. In fact, test components may share the same execution environment with the running SUT. This may burden some execution nodes of the SUT and may have a bad impact on the SUT performance. Also, it may sometimes cause

SCT1

Test manager

Test cases repository

Selects test cases

TSC

DTA

CCT2 CCT1

Identifies testers and assigns test cases malfunctions. To resolve this problem, we concentrate in this work on proposing a new method for adapting the test components deployment at runtime to the resource situation of the execution nodes and also to connectivity constraints.

-Consideration of resource allocation issue

We first introduce the considered resources for nodes as well as for test components. For each node in the execution environment, three resources are monitored during SUT execution: the available memory, the provided CPU and the battery level. The value of each resource can be directly captured on each node through the use of internal monitors. These values are measured after the runtime reconfiguration and before starting the testing activity.

For each test component, we introduce the memory size (the memory occupation needed by a test component in execution), CPU load and battery consumption properties. We suppose that these properties values are provided by the test manager. It is also worth noting that some techniques are available in the literature for obtaining the required resources by testers. For example in [START_REF] Din | Distributed Load Tests with TTCN-3[END_REF], the authors propose a preliminary test to learn about some required resources such as the amount of memory allocated by a test component, the time needed to execute the test behavior, etc.

-Consideration of connectivity issue

Regarding the connectivity constraints, we consider that each test component has to find at least one route to communicate with the component under test. As mentioned before, this constraint can be ignored when all nodes are communicating together. In this case, the execution environment is modeled as a connected graph. Recall that in the graph theory, a graph is connected if for every pair of vertices, there is a path in the graph between those vertices. Hence, each test component can be assigned to any node and it can communicate with the node under test either locally or remotely.

In the worst case, whereas some connectivity problems occur [START_REF] Maassen | Smartsockets: solving the connectivity problems in grid computing[END_REF], the execution environment is considered not connected. In this situation, the graph is obviously decomposed in several connected components as we have seen in the illustrative example (see Figure 1 (c)). Therefore, for each test component we have to pinpoint a set of forbidden nodes to avoid when the placement procedure is done. For instance, the set of forbidden nodes for the test component T 1 contains N 4. From a technical perspective, either depth-first3 or breadth-first4 algorithm can be used to firstly identify the connected components and secondly to compute the forbidden nodes for each test component involved in the test architecture.

We can also associate for each node a profit. While the tester is placed in the same node with the component under test, the profit is maximal because the communications cost over the network will be reduced. It decreases once the tester is placed far from the component under test.

In the rest of this paper, we suppose that the execution environment has been modeled as a connex graph. Even when the obtained graph is disconnected, we have to compute the connected components and apply the same adopted method for placement to these sub-graphs. In the next section, we formalize the placement problem using a variant of the Knapsack Problem under assumptions like: provided resources for each node are accessible and required resources for each test component are available too.

Mathematical Modeling of The Test Component Placement

Background

The Knapsack Problem (KP) is a well-studied, N P-hard combinatorial optimization problem. It has been used to model different applications for instance in computer science and financial management. It considers a set of n objects O = o 1 , . . . , o n and a knapsack of capacity W . Each object o j has an associated profit p j and weight w j . The objective is to find a subset S ⊆ O in such a way that the weight sum over the objects in S does not exceed the knapsack capacity and yields a maximum profit [19][20][START_REF] Puchinger | The Core Concept for the Multidimensional Knapsack Problem[END_REF].

The most basic form of Knapsack Problem (KP) is formulated as follows:

KP =            maximize z = n j=1 p j x j subject to n j=1 w j x j ≤ W x j ∈ {0, 1} ∀j ∈ {1, • • • , n}
In the literature, we found many variants of this problem. Due to space limitations, we describe in details only the two models used in our context:

The Multidimensional Knapsack Problem (MDKP). is also called Multiply constrained Knapsack Problem or m-dimensional knapsack problem. It can be viewed as a resource allocation model and can be modeled as follows:

M DKP =            maximize z = n j=1 p j x j subject to n j=1 w ij x j ≤ c i ∀i ∈ {1, • • • , m} x j ∈ {0, 1} ∀j ∈ {1, • • • , n}
Where a set of n items with profits p j > 0 and m resources with capacities c i > 0 are given. Each item j consumes an amount w ij ≥ 0 from each resource i. The 0-1 decision variables x j indicate which items are selected. The main purpose is to choose a subset of items with maximum total profit. Selected items must not exceed resource capacities. This is expressed by the knapsack constraints [START_REF] Puchinger | The Core Concept for the Multidimensional Knapsack Problem[END_REF]. Obviously, the KP is a special case of the multidimensional knapsack problem with m = 1.

The 0-1 Multiple Knapsack Problem (0-1 MKP). is the problem of assigning a subset of n items to m distinct knapsacks having different capacities [START_REF] Martello | Solution of the zero-one multiple knapsack problem[END_REF][START_REF] Jansen | Parameterized approximation scheme for the multiple knapsack problem[END_REF]. It is also referenced as the 0-1 integer programming problem or the 0-1 linear programming problem. More formally, a MKP is stated as follows:

M KP =                    maximize z = m i=1 n j=1 p j x ij subject to n j=1 w j x ij ≤ W i ∀i ∈ {1, • • • , m} m i=1 x ij ≤ 1 ∀j ∈ {1, • • • , n} x ij ∈ {0, 1} ∀j ∈ {1, • • • , n} and ∀i ∈ {1, • • • , m}

Our Mathematical Modeling

Mathematically, our placement problem can be modeled by merging the two introduced knapsack variants: multidimensional and multiple knapsack problems. The obtained model is called Multiple Multidimensional Knapsack Problem (MMKP). It is worthy to note that this new variant of the standard KP has been rarely addressed in the literature except in [24]. We assume that the execution environment consists of m nodes and we have n test components that may be assigned to them. We attempt to find an optimal solution of test component placement not violating resource and connectivity constraints and also maximizing their placement profit. We can formulate this problem using the MMKP variant as follows:

M M KP =                                    maximize Z = n i=1 m j=1 p ij x ij (1) subject to n i=1 x ij dc i ≤ c j ∀j ∈ {1, • • • , m} (2)
n i=1 x ij dr i ≤ r j ∀j ∈ {1, • • • , m} (3)
n i=1 x ij db i ≤ b j ∀j ∈ {1, • • • , m} (4)
m j=1 x ij = 1 ∀i ∈ {1, • • • , n} (5)
x ij ∈ {0, 1} ∀i ∈ {1, • • • , n} and ∀j ∈ {1, • • • , m}
The provided resources by the m nodes are given through three vectors: C that contains the provided CPU, R that provides the available RAM and B that contains the battery level of each node.

C =      c 1 c 2 . . . c m      R =      r 1 r 2 . . . r m      B =      b 1 b 2 . . . b m     
In addition, the required resources for each test component are illustrated over three vectors: D c that carries the required CPU, D r that contains the required RAM and D b that contains the required Battery by each tester.

D c =      dc 1 dc 2 . . . dc n      D r =      dr 1 dr 2 . . . dr n      D b =      db 1 db 2 . . . db n     
Similarly, we define the two dimensional variable, x ij as follows:

x ij = 1 if tester i is assigned to node j 0 otherwise
We may find a feasible solution of test component placement if the objective function (1) is omitted. Otherwise, an optimal solution is computed that maximizes the placement profit. For doing this, a matrix P has been introduced which is filled with a profit value of each test component in response to execution nodes. This matrix depends on the length path between the node under test 5 and the node hosting the test component. The profit p ij can be equal to a predefined value maxP if the test component i is assigned to a node j which corresponds to the node under test. It can be equal to maxP -l if the test component i is assigned to a node j reachable from the node under test via a path having the length l. The constraints (2),( 3) and ( 4) ensure that the overall required resources by the testers can not exceed the available resources in each node. They are called knapsack constraints similar to the standard knapsack problem. The equality [START_REF] Din | Distributed Load Tests with TTCN-3[END_REF] indicates that all testers have to be assigned to the execution nodes and each of them has to be placed in at most one node.

It is worthy to note that in this work we have chosen the distance between nodes as criteria for filling the matrix P. However, other placement criteria can be used such as bandwidth utilization. Furthermore, this solution is dedicated for a connected network. Even if some connectivity problems occur, we apply the proposed model for each connected component in the network. Thus, we obtain in this case partial placement solution.

Illustration

We use the previously studied example in section 2 to illustrate the feasibility of our proposal. In case of connectivity problem as shown in Figure 1 (c), the node N 4 is forbidden to host testers T 1, T 2 and T 3. In this case, the placement problem is divided into two sub-problems. In the first one, we consider the connected nodes (N 1, N 2 and N 3) while searching placement solution for test components T 1, T 2 and T 3. In the second one, we study the possibility of assigning the test component T 4 to N 4. In the following, we detail the first subproblem as illustrated in Figure 4. First, we introduce for instance the RAM and CPU constraints for the node N 1 when all nodes in the network are connected:

10x 11 + 10x 21 + 15x 31 ≤ 50.
(1)

10x 11 + 5x 21 + 10x 31 ≤ 20. (2)
Next, the objective function is formed as follows with considering that the maxP value is equal to α and maxP -1 is equal to β in this example. The formed MMKP seeks to maximize the equation ( 3) subject to the constraints such as defined in equations ( 1) and (2). In the following, we illustrate the derivation of an exact solution of such problem using a well known constraint programming solver called Choco.

Realization

To solve our test component placement problem which is modeled as MMKP, we propose a tool illustrated in Figure 5. As inputs, it takes three XML 6 files: nodes provided resources, testers required resources and tester profits. As output, it generates an XML based resource aware test plan which contains for each tester the adequate host to be deployed on. The core of this tool is based on the open source Choco Java library. In the following subsections, we first introduce the Choco library. Next, we demonstrate the mapping between the mathematical formalism to the Choco Java code.

ChOCO library based code

Nodes provided resources + Testers required resources + Testers profits XML files XML file

GUI

Resource Aware Test Plan Fig. 5. Architecture of Choco based tool.

Choco Library

Choco is introduced in [START_REF] Jussien | Choco: an Open Source Java Constraint Programming Library[END_REF] as a Java library for constraint satisfaction problems (CSP) and constraint programming (CP).

It is an open source software which offers a problem modeler and a constraint programming solver. The first one is able to manipulate a large variety of variable types and supports over 70 constraints. The second one can be used in satisfaction mode by computing one solution, all solutions or iterating them. Also, it can be used in an optimization mode (maximization and minimization). We selected this solver because it seems to be one of the most popular within the research community and because it is reliable and stable open source Java solver. In the following, we show how to make use of these two fundamental characteristics of Choco to model and solve our placement problem.

Modeling and resolving our placement problem with Choco

To solve the test component placement in execution nodes formulated as MMKP, we use Choco library by defining the variables set of the problem and stating constraints (conditions, properties) which must be satisfied by the solution.

Listing 1. Choco code example.

The above Listing 1 presents a brief overview of the model translation from the mathematical representation of our problem to Choco code. In line 7, it shows the declaration of the x ij variable and its domain. Moreover, we display in line 9 the declaration of the objective function that maximize the gain of test component placement. Stating the constraint (5) using the Choco syntax has been illustrated in line 14. To solve the placement problem, two cases exist : obtaining a satisfying solution or an optimal solution. The latter case is illustrated in the line 24.

Experimentation

In this section, we present some experiments that are conducted to evaluate the execution time (order of milliseconds) needed for the placement phase. Two cases have been studied in the following subsections. First, we measure the time needed by calculating a satisfying solution. Next, we compute the execution time while optimal solution is required.

All of the experiments were conducted on a PC with Intel Core 2 Duo CPU and 2 GB of main memory having as operating system Microsoft vista. The number of nodes is equal to the number of testers in all the experiments that we have done. Also, we have to note that each experiment is carried out five times to derive the precise average execution time of the placement phase.

Computation of a feasible solution

The graph of Figure 6 shows the average execution time required by the Choco solver to compute a satisfying solution. Analysis of the results indicates that the average time required for assigning test components to execution nodes increases with the increase in number of test components and nodes. The proposed solver may resolve this N P-hard problem in a reasonable amount of time while the number of test components and nodes does not exceed some dozens. Such solution can be sufficient especially when the affected parts of the system to validate after dynamic reconfiguration are not important also when the execution environment is not large.

Computation of an optimal solution

Recall that in this case we search for an exact solution that maximizes the placement profits by assigning test components to the adequate execution nodes. By computing such solution, we aim to reduce the communication cost over the network between the test components and the components under test. As illustrated in Figure 7, the calculation of the optimal solution takes a significant time especially when the number of test components and nodes increases. We have to note that this computation technique can be opted when the dynamic changes are not frequently done. Thus, we have enough time to validate them. Otherwise, it can be enhanced by the use of some predefined heuristics in Choco library.

Conclusion

In this paper, we have studied the runtime testing of adaptable and distributed systems after the occurrence of dynamic changes. This resource intense testing method is often performed in a resource constrained execution environment. For this reason, defining efficiently the distributed test architecture and the assignment of its components to the execution nodes can be a useful solution for either respecting resource constraints or reducing the cost of testing activity.

To do this, we have proposed a new approach for resource aware test architecture design of adaptable and distributed systems. Our main contribution in this work consists in proposing a method for test component placement in the execution nodes while respecting resource and connectivity constraints. This N P-hard problem has been formulated as a multiple multidimensional knapsack problem. We have also implemented a tool facilitating the resolution of our problem using the Choco Java library.

As future work, we will enhance the proposed solution by adding other resource constraints such as network bandwidth or by associating different weights with the considered resources. Moreover, it is obvious that for large scale systems or systems having hard realtime timing constraints, the proposed method is not suitable. In this case, it might take a lot of time to find the exact solution. Therefore, we investigate effort in enhancing the proposed technique using heuristics.

Fig. 1 .

 1 Fig. 1. Execution environment modeling using graphs.

Fig. 3 .

 3 Fig. 3. Overview of a detailed Distributed Test Architecture.

Z = αx 11 +Fig. 4 .

 114 Fig. 4. Illustration Example.

Fig. 6 .Fig. 7 .

 67 Fig. 6. Execution time needed for computing a feasible solution.

Table 1 .

 1 Execution node characteristics.

	Nodes Free RAM CPU Load Components
	N 1	50 %	20 %	C1, C2
	N 2	40 %	30 %	C3
	N 3	35 %	50%	C4
	N 4	60 %	60 %	C5

Table 2 .

 2 Test component characteristics.

	Testers Required RAM CPU usage CUTs
	T 1	10 %	10 %	C1
	T 2	10 %	5 %	C2
	T 3	15 %	10 %	C4
	T 4	20 %	15 %	C5

For instance, wireless communication networks are characterized by frequent and unpredictable changes in connectivity.

Testing and Test Control Notation version

(TTCN-3) standard offers a standardized test notation and an execution platform facilitating the deployment and the execution of test components, http://www.ttcn-3.org/

http://en.wikipedia.org/wiki/Depth-first search

http://en.wikipedia.org/wiki/Breadth-first search


Marlène Delhaye

Jabes

Carl Grant

Evaluating the Webscale Platforms and Their Impact on Librarianship

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

In the current context of shrinking budgets, diminishing activity and an ageing workforce, Carl exposed several challenges the profession has to face: rises in Higher Education costs, changing technologies (mobiles, Internet of things, etc), growing quantity of data to handle, wider dissemination of education with MOOCs and distance learning, even smaller attention spans. Librarians have to create new strategic spaces, offering unique value to their users. The hard part is to provide value and differentiation while remaining consistent with the original aims of the libraries -maybe it is time to think bigger: cloud computing and extensive use of APIs are key elements in enabling libraries to cope with their readers' needs.

Cloud computing makes it possible to share data more easily (and handle bigger amounts of data): it is a first step towards the end of the silos libraries naturally tend to create, and a way to re-focus on end-users (by providing more valuable services). The new library platforms are based on cloud computing and allow us to scale up the opportunities to share.

APIs support wide collaboration between providers, librarians and users. It is no longer the content that matters anymore, it is the conversation that occurs around the content, of which the user, thanks to APIs, can play a part in creating and processing (Carl cited the example of community-created metadata by the Alma community zone from Ex Libris).

The role of libraries in this context shifts from controlling the conversation (controlled vocabularies) to facilitating it (users tagging): users want the information, but they want it their way -librarians have to have to build tools to support all forms of collaboration (see the example of the Trove Project of the National Library of Australia [START_REF] Holley | Trove: Innovation in Access to Information in Australia[END_REF]). Library services platforms can help libraries achieve this goal, though libraries also need to be able to connect to the numerous services on the Web where the users are, and where the discovery overwhelmingly takes place. Developing platforms allowing users to discover established information as well as creating new material may assuredly be a path to follow for librarians.

I Just Wanted to Tell You

Raymond Bérard, Director of ABES Mr Bérard, who is leaving the ABES after 7 years, summarised the agency's development during his mandate: the gain in technical autonomy with the development of applications outside OCLC/CBS, the expansion in international partnerships (with Jisc, DART-Europe, DARIAH-EU, OCLC/Worldcat, etc), the opening up of all bibliographic data created by the ABES network through the application of the Etalab open licence [7], the start of a closer involvement of ABES in the research environment, with partnerships with research teams, the reinforcement of partnerships with research institutions and work around the IdRef [8] and ORCID [9] projects. The growing part of e-resources purchasing and the achievement of comprehensive coverage of the theses processes completed the picture. These achievements confirmed the major role ABES played in the current scientific information landscape in France.

Figure 2: JABES 2013 Web page

Raymond also shared with us some failures (ILL modernisation, implementation of the OCLC/Collection Analysis service, e-resources shared cataloguing and a few regrets: applications that did not engage with ABES' users, but which nobody dares close (Num-ES [10], Signets des universités (academic bookmarks) [START_REF]Signets des universités[END_REF], RDA implementation (hard to perform without a schedule), mitigation of ISSN's licence terms.

New tasks have to be completed during the next five years, some of which will be discussed later: e-resources signposting, for which a strong partnership with the Couperin consortium is indispensable, the pooled ILS project, and the finalisation of the metadata hub. These projects will require closer collaboration between the agency and its partners in the field of scientific information in Higher Education: Couperin, Centre pour la Communication Scientifique Directe (CCSD) (the body operating the French open archive HaL [12]) and the INIST-CNRS (Institut de l'Information Scientifique et Technique du CNRS, a branch of the Centre national de la recherche scientifique, CNRS), which M. Bérard will join in September 2013. There is no co-ordinated policy defining the relationships between all these operators at the moment, but existing projects, particularly those revolving around metadata, often require the knowledge and expertise of all of them, regardless of their exact perimeters.

Digitisation of Public Domain Documents: Which Policies?

Panel with Jeannette Frey, Anders Toftgaard, Jacqueline Sanson, Carole Melzac, Christophe Pérales, moderated by Yves Alix

The recent announcement of the private-public partnerships concluded between the Bibliothèque nationale de France (BnF) and several companies led to extensive press coverage [START_REF]French National Library: How the nation is in the process of being rooked', blog S.I.Lex[END_REF], and it seemed useful to consider some of the politics surrounding the digitisation of public domain works. Jeannette Frey, from Bibliothèque Cantonale et Universitaire de Lausanne [14], Switzerland, is used to outsourcing the mass digitisation work to private companies: her library started with Google in 2006 with monographs, which were followed by several regional newspaper projects. All the digitised material is available openly on the Web, which contributes to the success of this kind of project: usage reports show over 120 million visits yearly, just for the Google book titles. Open access to the documents is a choice, strengthened by the precise contractual definition of the role of each of the partners.

The Danish Royal Library [15] began its digitisation programmes in the 1990s with medieval manuscripts, rare documents potentially of interest to an international audience. It then extended the programme to more Danish books, realising that at some point, 'quantity wins over quality and access over conservation'. The Library relies on its partners for mass digitisation, and for associated services (on-demand digitisation with EOD). Anders Toftgaard outlined the principal points of the Proquest partnership [START_REF]New Online Collection from ProQuest Creates Access to Full-Colour 15[END_REF]: it relates to Danish books from 1482 to 1700 plus incunabula. The Library provides the metadata, and all documents are available freely to Danish IP addresses as well as for Danish users abroad. The books are in the public domain, but are not available to everyone: an embargo period of 10 to 15 years (for the 17th century) is imposed on works, during which period access is restricted to Denmark only. There has been some criticism of this embargo period, but others would argue that 10 years represent quite a short term on a library timescale. Ultimately, all documents will be placed on open access to everybody. In a time of budget constraints, the agreement appeared very satisfactory both for the Library and for its readers.

Jacqueline Sanson then reminded us of the steps taken by the Bibliothèque nationale de France (BnF) since the 1990s in respect of digitisation: the first programmes were focused on the constitution of selected corpuses, hosting texts and images. In the mid-2000's, the massive projects led by Google accelerated the global move towards bigger scale programmes, and prompted the BnF to drop thematic digitisation. With Gallica [17] since 2007, the library tends to exhaustive coverage. Due to funding limits, the library has had to open its digitization projects to companies from the private sector in public-private partnership structures via its dedicated subsidiary, BnF-Partenariats. 70,000 books from the 17th and 18th century and 200,000 audio records will benefit from these agreements with Proquest (books) and Mnemon / Believe digital (records).

The critics that have emerged from the field rely on the 10-year embargo during which only a very small part of the collections (5%) will be available to the wide public on Gallica, the core of the documents being accessible exclusively from the BnF's premises. Mrs Sanson admitted the Library had made this choice in favour of a reduced exclusivity period overall; in the future, solutions more suitable for Higher Education institutions will be favoured.

Christophe Péralès, President of the Association des directeurs de bibliothèques universitaires (ADBU) [18] expressed the view of the members of the Association about the issue : private-public partnerships are neither a good or bad measure per se, but the costs have to be carefully examined, particularly in respect of the value added by the publishers: it is important to know exactly who pays what.

Finally, Carole Melzac (ABES), looked back on the notion of public domain, which is rather blurry for public institutions as far as digital copies of the work are concerned. The report by the Lescure Commission [START_REF]Acte II de l'exception culturelle[END_REF], published in May 2013, makes significant proposals with regard to the protection and enhancement of the public domain in the digital world; its outcomes will need to be followed carefully.

Day Two: 15 May 2013

The Pooled ILS Project at the Crossroads Jean Bernon, project manager, ABES and members of the pooled ILS Working Group Jean Bernon first reminded us of the issues at stake for the project: setting up a signposting solution for electronic resources; developing the SUDOC by changing its core Central Bibliographic System (CBS) and thus extend its perimeter to e-resources, which are poorly covered at the moment; reducing the gap between national and local data; and enhancing collection development. He then presented the different scenarios [START_REF]Système de gestion mutualisé. Etude d'impact, version de travail[END_REF] devised by the working group :

1. Completion of migration of all institutional members of the SUDOC network as well as the SUDOC itself to a new, cloud-based mutualised next-gen Integrated Library System (ILS) (implementation in pilot institutions to take place within 2 years) 2. Maintainance of a shared cataloguing system on CBS and migration to a shared next-gen ILS system for several pilot institutions, with an enhanced workflow between both systems 3. Maintainance of a shared cataloguing system on CBS and development of connectors for the various next-gen ILS systems chosen by the member institutions The various impacts of the project on member institutions were then described: they included internal workflow reorganisation; the necessary evolution within the libraries, ie switching from a long-term purchasing model to a yearly subscription model; adaptation of specific local functionalities to a pooled environment; and privacy issues. The impact on ABES itself is important as well: less control over the quality of metadata (mainly provided by publishers); the need to create a French Resource Description and Access (RDA) profile; maintainance of all the existing workflows between the SUDOC and the various applications with which it communicates, cost issues and scope of services provided by the Agency.

The response from the project manager and the working group focused upon the need to build a national knowledge base, linked to the data hub, fed by Global Open Knowledge Base (GoKB) [START_REF]The Global Open KnowledgeBase[END_REF] for international data, and by the French universities for local data. It was felt the ABES would be the appropriate agent for this work.

Figure 3: Slide from The Pooled ILS Project at the Crossroads

Members of the working group, as well as those librarians in the room, expressed some reservations and concerns about the pooled ILS project: they related to the loss of specific local features (but they could be handled through the development of APIs); the lack of consortial features in the products currently available (and no certainty as to their implementation), the fear of the creation of a captive market (just as has occurred for e-resources), the lack of visibility with regard to the costs the libraries will have to bear (though a requirement of the project is to maintain the same level of costs). The absence of funding from the Ministry for Higher Education was also mentioned: someone from the Ministry in the room reminded us that the project began as an inter-institutional mutualisation project, so no funding had been assigned. But as the impact of the changes mentioned took the project to a larger scale, the need for additional funding appeared crucial. The Ministry for Higher Education might consider working out a solution.

It was reported in conclusion that the whole project would be discussed further, and that decisions as to its future would be taken at the next meeting of the Board of the ABES on 30 May 2013.

On Open Access in Freemium Mode, and Some Remarks about Unique Identification in Academia

Marin Dacos, Openedition

In the first part of his talk, Marin Dacos approached the issue of unique identifiers for scientific publications: the DOI (Digital Object Identifier) [22] is a cost-effective system, driven by a business model (the content providers, commercial as well as not-for-profit, such as universities, are driven to declare and pay for DOIs on all their articles). But the process is not governed by scientific interests. With ORCID (Open Researcher and Contributor ID) [9], the researcher identification project, Crossref aims to control the ecosystem of identifiers. In France, we are behind the curve on these matters, although we already have infrastructures (IdRef, Identifiants et référentiels Sudoc pour l'enseignement supérieur et la recherche [8], and Isni, International Standard Name Identifier [23]) -their flaw is that they are document-centred, rather than person-centred. In the ORCID firmament, the researchers or authors are stars, and benefit from an attractive Web environment, which motivates them to enrich the system. Marin concluded that we have to develop our own infrastructures, and connect them with ORCID to enrich it. In this way we will become sources of data ourselves (and keep the control of them at the same time), and will no longer be customers of a commercial system.

Being actors instead of clients was likewise the theme of the second part of the talk: knowledge and information have to break out from the silos in which we tend to confine them, and that is what Open Access is all about. And particularly where social sciences are concerned: there are more than 10 million visits on the four French-speaking journals platforms (Revues.org, Persée, Cairn, Erudit) per month, which tends to prove they answer a real and strong social demand. Open Access does not mean there are no longer any costs associated: platform costs have replaced print costs, and electronic publishing is qualified work, that has to be rewarded. Consequently, new business models have to be invented to cover these costs and to maintain the widest access to knowledge possible. Author-pays models are unfair, and prompt publishers to publish more articles, instead of concentrating on the quality of content. What Openedition [24] (the umbrella for Revues.org's 300 journals, Hypotheses' 600 scientific blogs, Calenda's 20000+ scientific announcements and soon-toarrive 1,000 ebooks from the Books programme) proposes is inspired by the Web, based on premium models (such as Skype, where the basic service is free, while enhanced service comes at a cost). In the Freemium model, access to the content in HTML is free for everyone, and a yearly subscription gives access to additional services (pdf and epub formats, usage reports and metadata records for libraries, etc).

These costs are reinvested within the system: 33% go to the development of the platform, and 66% go to the content providers. With this model, 80 journals have been strengthened in their choice of open access, and 10 have left the moving wall (no embargo anymore). 94% of the journals on Revues.org are fully open access now. Many projects are now ongoing for the Openedition team, thanks to a national grant: for example, OE Books (15,000 e-books in 7 years), OE Labs (R&D department, text mining projects). Open access is a big issue, we need to contribute to national (Bibliothèque Scientifique Numérique, BSN) [25] and international infrastructures (DARIAH-EU) [START_REF]Dariah-EU (Digital Research Infrastructure for the Arts and Humanities[END_REF] to move forward.

Towards a Mutualised Knowledgebase at the International Level

Maurits Van der Graaf, Pleiade Management & Consultancy, Liam Earney, KB+ (Jisc), Kristin Antelman, GOKb

Maurits Van der Graaf outlined the main points of the study [START_REF]The ABES Discovery study: A study into three scenarios for a National Webscale Discovery Tool for scholarly e-content[END_REF] he conducted for ABES about the eventual implementation of a national discovery tool. After reminding us of the main goals of the project (enhanced access to print and e-collections, wide connectivity with local existing systems and provision of resolver services for libraries not as yet equipped and connection to national licensed platforms), he described the likely different scenarios: implementation of a discovery portal, creation of a centralised index, development of a national locator service. The latter seems the most feasible option in the current French configuration. It would seem to call for the creation of a national knowledge base (to cover local resources absent from the international knowledge bases), which would be complemented by data from existing international projects such as KB+ from Jisc and GOKb. Data would be enriched by the metadata hub [START_REF]Le rôle du hub de métadonnées -Carrefour de l[END_REF] currently prototyped by the ABES team as well. The development of this national locator system is a first step in a possible migration towards a global cloud-based information infrastructure.

The creation of non-commercial knowledge bases is an issue Jisc has been working on for a few years: as money was scarce for building new Library Management Systems (LMS) or Electronic Resources Management systems (ERMs), the project focused on data provision. Now at an advanced stage, the KB+ Project [29] as presented by Liam Earney, wants to become a one-stop shop for libraries, somewhere where they will find all the data they need in order signpost and better manage their resources for their users. The idea is the creation of a centralised KB, fed by Jisc Collections [30], the section of Jisc in charge of e-resources negociations. The data are available at the title level, and provide detailed information about local collections, machine-readable licences, information on the contracts and consortial negociations. International co-operation with GoKB [START_REF]The Global Open KnowledgeBase[END_REF] makes it possible to expand the coverage of data at the package level. The challenges to deal with are the poor quality of publishers' metadata (even the KBART-formatted [31] data supplied contained lots of mistakes, therefore the updating work is now done only semi-automatically by Jisc's data managers, which is a rather time-consuming process), implementation in other workflows and systems, stabilising a system in a somewhat erratic environment. The next steps are the integration of libraries' workflows and interoperability among different systems. Enhancements foreseen are the enrichment of data on licences, the provision of statistics (the Analytics project aims to provide information about a community's activity, to help governing bodies make informed decisions) and the addition of export features. There is also a huge demand for data on ebooks and on Open Access, but the type of data has still to be defined.

Finally Kristin Antelman provided an update on Global Open Knowledgebase (GOKb) [START_REF]The Global Open KnowledgeBase[END_REF], part of the Open Library Environment (OLE) Project [32], led by the Kuali Foundation. Started in 2011, its public release is expected in 2014.

GOKb is an open data repository of information about electronic publications developed in close collaboration with Jisc and partner libraries. Data on journals are handled at the package level as well as the title level; the project uses normalised exchange protocols such as KBART, Onyx or EDItEUR. Regarding the feeding and updating of GOKb, it is a pooled process, inserted in the member libraries' usual workflow. There is important cleaning work to be done at the first stages of the project, very time-consuming, but it is an investment for the future, the processes will be less demanding once the system is in production. This cleaning work relies on the Open refine [33] tools (which are pooled as well) and Web apps are used to support viewing of data via a Web interface.

Conclusion

The variety of themes addressed during the conference was huge, and this report does not do full justice to the richness of the sessions scheduled in the programme [34]. For example, we could not summarise in this article: tracks about heritage, about theses and about cataloguing which were very well received by the participants. Nor could we adequately convey the dynamism demonstrated by the members of the Sudoc network.

The main trends emerging from the sessions show what could well form the next steps: transferring data and technical infrastructures into the cloud; developing APIs to adapt the systems to our users' needs; and unlocking data from the silos in which they have become stuck. These aspects seem to comprise a path to follow in order to guarantee better, more appropriate services for our users.

For Raymond Bérard, who brought the event to its closure, the past few days had furnished participants with a greater understanding of the projects as well as the issues at stake for libraries, both now and in the near future.

Figure 1 :

 1 Figure 1: Opening page of 'Evaluating the Webscale Platforms and Their Impact on Librarianship'

reports on the two-

Author Details

Marlène Delhaye E-resources Librarian Université d'Aix-Marseille Email: marlene.delhaye@univ-amu.fr (link sends e-mail) Web site: http://bu.univ-amu.fr/ (link is external) Blog This article has been published under Creative Commons Attribution 3.0 Unported (CC BY 3.0) licence (link is external). Please note this CC BY licence applies to textual content of this article, and that some images or other non-textual elements may be covered by special copyright arrangements. For guidance on citing this article (giving attribution as required by the CC BY licence), please see below our recommendation of 'How to cite this article'.