Kevin Vlaanderen
email: k.vlaanderen@cs.uu.nl

Inge Van De Weerd
email: i.vandeweerd@cs.uu.nl

Sjaak Brinkkemper
email: s.brinkkemper@cs.uu.nl

The Online Method Engine: From Process Assessment to Method Execution

Keywords: Method Engineering, Assessment, Process Improvement, Online Method Engine, Method Fragments, Method-as-a-Service, Software Product Management

The field of method engineering has seen an increasing amount of interesting approaches and techniques over the last ten years. The coverage of these techniques ranges from the modeling of processes and systems to the situational construction of new ones. However, access to the required domain knowledge is often not available, and the effort required for effective method engineering is in most cases too much. To overcome these problems, we propose an incremental approach for process assessment, process improvement, and process execution, based on method engineering techniques and tools. The approach is implemented in the Online Method Engine; a holistic solution that supports these three aspects. In this paper, we give a conceptual overview of the approach, along with an overview of the current state of development.

Introduction

Many researchers [START_REF] Saeki | Object-oriented meta modelling[END_REF][START_REF] Ralyté | A knowledgebased approach to manage information systems interoperability[END_REF][START_REF] Harmsen | Situational Method Engineering[END_REF][START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF] describe the use of a method base in situational method engineering. Method fragments can be stored in it, for example by using the MEL method engineering language [START_REF] Brinkkemper | A Method Engineering Language for the Description of Systems Development Methods[END_REF]. Once retrieved from the method base, they can be combined following the assembly rules described by Brinkkemper [START_REF] Brinkkemper | Meta-modelling based assembly techniques for situational method engineering[END_REF]. More recently, work has been performed on allowing incremental method evolution [START_REF] Van De Weerd | Concepts for Incremental Method Evolution : Empirical Exploration and Validation in Requirements Management[END_REF]. According to this work, method fragments can be used to describe and improve the evolution of software product management methods, by allowing the insertion, modification and deletion of method fragment components. Some method bases have actually been implemented, such as OPF [START_REF] Henderson-Sellers | Process metamodelling and process construction: examples using the OPEN Process Framework (OPF)[END_REF] and the CREWS method base [START_REF] Ralyté | Reusing scenario based approaches in requirement engineering methods: CREWS method base[END_REF]. However, for practitioners (the actual method users), retrieving these method fragments and using those in their daily work can be cumbersome. A prerequisite is that the method user should be aware of the exact method fragment that he or she is searching for. In addition, the method user must know what to do with the retrieved method fragment, how to interpret it, and how to implement it in the organization.

To support the method engineering activity, several computer-aided method engineering (CAME or meta-CASE) tools have been developed. Most of these focus on the meta-modeling aspect. One well-known example of such a tool is MetaEdit+ [START_REF] Tolvanen | MetaEdit+: Defining and Using Domain-Specific Modeling Languages and Code Generators[END_REF], which enables the definition and usage of domain-specific languages. This tool was also applied in a more agile context [START_REF] Berki | Formal Metamodelling and Agile Method Engineering in MetaCASE and CAME Tool Environments[END_REF]. On the other hand, several tools that focus more on the method construction aspect have been developed as well. One example in this field is the work of Saeki [START_REF] Saeki | Came: The first step to automated method engineering[END_REF]. Work on the method base management system 'Decamerone' has been performed by Harmsen and Brinkkemper [START_REF] Harmsen | Design and implementation of a method base management system for a situational CASE environment[END_REF].

Unfortunately, the current method bases and knowledge infrastructures are too hard to use for many practitioners. They do not always know exactly what they are looking for, nor how to implement a formal method description in the processes of their organization. Therefore, in this research, we go a few steps further. We propose an Online Method Engine (OME) that can not only be used to store and retrieve method fragments, but also to assess an organization's current processes, create an advice based on this assessment, and implement this advice in the organizations processes and tools.

This research has many similarities with research on the Method as a Service, described by Rolland [START_REF] Rolland | Method engineering: towards methods as services[END_REF] and Deneckère et al. [START_REF] Deneckère | From Method Fragments to Method Services[END_REF], and by Guzélian and Cauvet [START_REF] Guzélian | SO2M: Towards a Service-Oriented Approach for Method Engineering[END_REF]. By adopting a Service-Oriented Architecture (SOA) for method engineering, the authors aim to change method fragments into method services which are implemented as Web services [START_REF] Rolland | Method engineering: towards methods as services[END_REF]. Deneckère describes how the concept of SOA is adopted in a MOA, a Method-Oriented Architecture. This MOA facilitates a method services registry in which available method services are organized. The authors describe the MOA usage in two use cases. They state that method engineers can use CAME tools to define new method with services compositions. On the other hand, method users (developers, practitioners) can use their CASE-tools to invoke remote method services. Unfortunately, the Method as a Service concept is not thoroughly understood yet.

In our vision of the OME, existing method bases are extended. The OME does not only provide a repository in which method fragments are stored, but also offers the opportunity for users to assess their own processes and investigate which ones should be improved. Based on this assessment, an improvement roadmap is created that is used as a basis for a number of method increments. Furthermore, the company's tooling infrastructure can be directly aligned with the method improvement by automatically configuring templates and work-documents.

In the remainder of this paper, we first explain the principle of model-driven process assessment and improvement. Then, section 3 describes the implementation of this principle in the OME. Finally, in section 4, we present our conclusions and further research.

Incremental Process Assessment and Improvement

The idea of incremental process improvement that we present in this paper consists of several separate steps. The starting point for each process improvement is an analysis of the current process, based on which a maturity profile can be calculated. The situational factors of the company are used to determine an optimal maturity profile. By calculating the delta between these two, the required process improvement is determined. This process improvement is further detailed by relating it to suitable method fragments that can be combined into a new process that improves the company's process. This brief summary of the process is illustrated in Figure 1. Each of the steps in the model is explained in more detail in the following sections.

At several points in the text, references will be made to example implementations in the domain of Software Product Management (SPM). In contrast to most method engineering approaches, our solutions are not implemented in the software engineering domain. SPM deals with management of requirements, the definition of releases, and the definition of software products in a context where many internal and external stakeholders are involved [START_REF] Van De Weerd | On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support[END_REF]. It represents a context where the creation and application of situational methods is very relevant, but where knowledge regarding effective method implementations is scarce.

Analysis of Current Situation

The first step in the process improvement activity is obtaining an overview of the current situation in terms of implemented capabilities, and situational factors of the business (unit). This approach can be generalized into a form as depicted by Figure 2. The figure is an instance of a PDD (the same applies to Figure 3). Its notation is based on a combination of a UML activity diagram and a UML class diagram. On the left-hand side, boxes indicate the activities that are to be performed. Complex activities that are not further specified here have a black shadow. On the right-hand side, the resulting deliverables are shown, along with their relationships.

Fig. 2. Analysis of current situation

The current situation constitutes both the currently employed process as well as more generic aspects of the company at hand. During the initial phase, it is the company that needs to decide what the extent of the analysis will be, i.e. the focus domain. We can identify two types of situations regarding the motivation for employing method engineering:

-The need for improvement of a specific area. In many cases, method improvements can better be performed in an evolutionary way rather than in a revolutionary way. By doing so, you reduce risk and increase the chance of success. This also means that it is often not required to analyze the entire process. Instead, only a specific part of the process is looked at, and only for that part improvements are provided. -The need for improvement of the entire process. For companies that do require a major improvement of their process, this should be a possibility. In those cases, the entire process should be analyzed. This group also contains (new) companies that wish to obtain advice without having a process in place yet, or with a process that is to be abandoned altogether. Although the latter will only very rarely happen, it should be taken into account.

Based on this choice, a questionnaire is generated and performed to gather information regarding the situational context. In the area of SPM, the situational analysis has been performed by conducting a questionnaire with a list of all the relevant situational factors as described by Bekkers et al. [START_REF] Bekkers | A Situational Assessment Method for Software Product Management[END_REF]. To enhance reliability of the data, the questionnaire could be replaced by performing an interview. Similar solutions can be developed for other areas.

Data from interviews that have been held suggest that there is a variety of wishes regarding the amount of effort that companies are willing to put in, in order to obtain process improvement advice. We can distinguish two manners in which companies are willing to provide information regarding their current process:

-Full process information. In the optimal case, companies are willing to provide complete information regarding their current process, deliverables, and situational factors that describe their environment. This means that their entire process needs to be captured in a way suitable for further elaboration. Also, the situational factors need to be captured in some way, either through a questionnaire or by means of an interview. With all data available, the process improvement advice that can be obtained is the most effective. However, capturing the entire process requires significant work from an expert who is able to employ an appropriate modeling technique. -Only situational factors and maturity information. In many cases, capturing full process information requires too much effort. Therefore, it should be possible to provide a process improvement advice based solely on the situational factors and maturity information. This option implies that the advice does not contain any information on how to implement the advice, but only what should be implemented.

If a company is willing to provide full information regarding (part of) their process, the process should be modeled by an expert, either internal or external. The resulting model should contain detailed information regarding both the process as well as the deliverables. Therefore, process-deliverable diagrams (PDDs) are a very suitable technique for this purpose. Vlaanderen et al. [START_REF] Vlaanderen | Model-Driven Assessment in Software Product Management[END_REF] show how PDD's can be used to model an SPM process and to capture the current maturity level of a company's product management process.

Analysis of Need

The next phase takes the situational factors and the list of implemented capabilities from the first phase as input, after which it determines how the current process could be improved. In the domain of Software Product Management, this phase has already been described by Bekkers et al. [START_REF] Bekkers | A Situational Assessment Method for Software Product Management[END_REF] in the form of the situational assessment method, but it will be summarized here for the sake of completeness (see Figure 3). The need analysis consists of three activities; (1) construction of the current capability profile, (2) calculation of the optimal capability profile, and (3) calculation of an 'areas of improvement' matrix. The first of these three consists of translating the results from the initial maturity assessment into a form usable for further calculation. The second activity is somewhat more complex. The optimal capability profile is determined by a set of situational factor effects. Several situational indicators have an associated effect. By applying all applicable situational factors effects, an optimal capability profile is obtained that is customized for the current company.

The current capability profile and the optimal capability profile are then combined into an Areas of Improvement matrix. This is again a capability matrix, with both previous matrices integrated into it. Between the two matrices, a gap can exist, which can be called the delta. This delta indicates the capabilities that need to be implemented, in order to arrive at the optimal maturity level. An example of such an Areas of Improvement matrix within the Software Product Management domain is shown in Figure 4. The actual delta is the light-grey areas, as this depicts the difference between the actual and the optimal maturity level. This set forms the basis for the next phase in the process of method improvement.

What is important in the context of this phase is the fact that users can vary in the rigidity that they demand from the method engineering process. Some wish only a partial improvement for a specific area, while others wish to improve their process to the maximum maturity level suggested for them. As stated before, evolutionary improvement is in many cases more prone to success than revolutionary change. This implies that it should be possible to provide improvements in the form of a roadmap when the process is changed rigorously.

Selection of Process Alternatives

For the next phase, each missing capability has to be connected to a method fragment that implements the capability. The capabilities that a method fragment implements can be used as an attribute during the initial selection of method fragment candidates. As will be described later on, both process fragments as well as deliverable fragments can implement capabilities. For this reason, capability is an effective first classifier of a method fragment in the method base.

For further classification, we reuse the situational factors described by Bekkers et al. [START_REF] Bekkers | The Influence of Situational Factors in Software Product Management: An Empirical Study[END_REF]. Since many fragments will be applicable in any situation, it does not make sense to describe each fragment by all factors. This would also pose a problem when the list of situational factors would change. Therefore, situational factors should only be used to indicate restrictions on the use of the fragment. The combined set of indicators for a specific fragment forms its second classifier, situation.

A third classifier of method fragments is their rating. Through the feedback of users, method fragments are rated on several aspects, such as effectiveness, complexity, etc. Method fragments with a very low rating can be ignored in most cases, while in other cases method fragments with a high rating are selected over similar method fragments with a low rating. A simple example of a method fragment with its describing attributes can be found in table 1. It is based on a prioritization technique used within the SPM domain.

Although processes, capabilities and situational factors form a very solid ground for method fragment selection, we need to take into account that we are dealing with processes in which humans are involved. This means that the resulting process needs to fit with the preferences of the people involved in it. These people need to be able to express these preferences during the selection of alternative method fragments. The results from interviews have indicated that product managers are not always willing to accept suggestions made to them by a machine [START_REF] Vlaanderen | Improving Software Product Management Processes : a detailed view of the Product Software Knowledge Infrastructure[END_REF]. Therefore, the process should allow for differences in the amount of freedom that is provided. While it is generally a good idea to suggest one specific method fragment per capability, users should be at liberty to select another. This 'freedom-of-choice' has serious consequences for the OME. In order to make the freedom given to users useful, they need to be provided with a sufficient amount of information for them to base their decision on.

The first source of information for this is the method fragment itself. Since every method fragment can be displayed in the form of a PDD, users can use this diagram to form an initial mental image of its implications. This is possible since all related activities and deliverables are readily available in the method fragment. However, in addition to this, we also identified a need for more sources in the form of experience reports. Experience from people in similar situations is highly valued, and would thus be a valuable addition to the process.

Based on all of the sources of information combined, users should be able to make a valid and well-argued choice regarding the method fragments that should be selected, and thus regarding the changes that should be made to the existing process.

Creation of Improvement Roadmap

After the improvements have been selected, the process of embedding or implementing the process advice varies depending on the amount of information that a company has provided. The possibilities are limited when only maturity information is known, in contrast with the field of opportunities when full process information is given. In any case, the initial part of the process can be the same for both situations, as this regards the elaboration of the chosen solution into steps. Steps are needed since solutions will in many cases be too large for implementation in one iteration. An evolutionary approach has more chance of success as it will likely yield a higher acceptance due to smaller, incremental changes.

The splitting of solutions into steps is subject to several conditions. Solutions cannot be split into steps randomly. The major reason for this is that we need to take dependencies into consideration. If a company wants to increase the maturity level of its requirements gathering process from A to C (see Figure 4, it does not make sense to implement automation before centralized registration. Instead, the first step should be to implement the activity related to level B, followed by an iteration in which level C is implemented.

In most cases, several capabilities can be implemented at the same time. However, to make iterations or steps more successful, it is probably wise to make sure that each step has some sort of goal, or a theme. This ensures a set of changes that is coherent. This way, the change-process seems less chaotic to the employee. This is important, as he or she will be the one performing the new process.

After the roadmap has been presented to the user and has been accepted, the implementation of it can start. In case that only maturity information is available, this process is fairly straightforward, as little support can be given. The changes that have been proposed need to be implemented in the company manually. In order to guide this, process descriptions and templates related to the advice are provided.

If full process information is available, then this process is considerably more complex. This part encompasses the most complex asset of method engineering, namely the assembly of method fragments. For each step, the selected method fragments need to be integrated with the existing process. As this is a difficult task, it is probably best to do this fragment by fragment.

A problem with this segmented approach, however, is the risk that some parts of the process get changed multiple times. This is unwanted, as this can lead to confusion among the people that need to perform the process. Therefore, already during the creation of the roadmap, the system should make sure that no such situations occur. This is also another argument for the statement that method fragments should be kept as small as possible. By preventing the usage of complex method fragments, the chance of overlap is made smaller, thereby increasing the chance of success of any algorithm that is charged with creating a coherent roadmap.

Selection and Implementation of Method Increments

After the assembly of the selected method fragments into the original process, the changes can actually be implemented within the company. To facilitate the change, the system can generate and/or update templates based on the original and the new process description (expressed in the PDDs).

If the company's original work documents are available, than they can be updated to reflect the new deliverables within the process. During this step, original data should be maintained while new columns, sections, formulas, etc. are added to the documents.

In case deliverables are not available, templates can be generated based on the generated process description. The generated templates should be directly usable within the new process.

In addition, the system generates full process descriptions with explanations of all steps, deliverables and roles. These descriptions aid the process owner during the implementation of the process in the company.

Online Method Engine

The method engineering approach described above does not adhere to the Methodas-a-Service philosophy unless it allows users to perform the created method to some extent online. This means that, instead of using various local software tools, the workflow and the deliverables are embedded in an online platform, which we will refer to as the OME. The method modification aspect is essential for improving the effectiveness of processes, but the method execution aspect ultimately allows major improvements in the efficiency of these processes by taking away a large share of the burden of maintaining a complex IT infrastructure. We depicted our vision on the OME in Figure 5. At the bottom, the development platform is depicted. As will be described later, this refers to Google AppEngine in our approach. On top of the platform the OME is shown, with the three functional layers described throughout the previous section. Each layer contains several functional components, shown by the rounded boxes. On the right hand of the figure, two databases are shown; one for the method engineering related data such as method fragments and situational factors, and one for the method execution related data such as requirements and planned releases. These database are connected to the system using separate data-connectors, which al-low connection to any suitable database, ranging from a MySQL database to the database of a third-party requirements engineering tool.

Such an approach implies an integration of the functionality to describe a process, assess the process, adapt the process, and then perform the process. In order to be able to do so, method fragments need to be correctly translated into an interface that offers the right set of tools for users to perform their tasks. The creation and usage of templates is a core aspect of this. Such online documents can be placed on any cloud documents solution such as Google Docs. As this environment is accessible through an API, it can be integrated into any other system, such as the OME.

In addition to the translation of deliverables into documents and the management of these documents, the activities need to be correctly translated. Aspects that need to be taken into consideration here are the correct translation of access rights based on roles, the distinction between automated tasks and user input, the type of interface that is required for a certain set of activities, and the order of the activities, i.e. sequential, simultaneous, or a mix of both.

Currently, these aspects are not all derivable from the PDDs. To solve this, either stricter rules should be applied during the creation of PDDs, or additional models should be created for defining interface, access rights and business process. The former is not a good solution, as this would make the creation of PDD's too complex. The latter is similar compared to model-driven development solutions such as OO-Method [START_REF] Pastor | OO-METHOD: An OO Software Production Environment Combining Conventional and Formal Methods[END_REF] and the web-based variant OOWS [START_REF] Pastor | OOWS: A method to develop web applications from web-oriented conceptual models[END_REF]. This would require the addition of several steps to the process for creating the required models, undermining an important aspect of the OME, namely the fact that it should be simple.

To forgo this problem, an alternative solution could be developed, based on pattern recognition. The idea behind this is that certain patterns will exist in the PDD's of processes and deliverables that can be directly related to correct solutions for the interface. For instance, activities that are performed simultaneously should be connected to a tabbed interface, with a tab for each activity. Activities that are performed linearly can always be displayed as steps, allowing to go back and forward. Such a solution would require no extra effort of the user. However, the possibilities of recognizing patterns are limited and it is very prone to modeling errors. Therefore, a user should always be able to alter the interface for a given process. Alternative interface elements should be provided for this by the system. The same holds for the generation of documents based on deliverables. As it is not always possible to derive the required file-type for a deliverable, the user should have the option to change this manually.

To capture all the requirements of the translation from method description to interface, a meta-model should be defined describing all possible translations for every construct and pattern.

Information extraction using MERL

For capturing processes in the OME, referred to as 'process modeler' in Figure 5, we currently use the tool MetaEdit+. MetaEdit+ is "an environment that allows building modeling tools and generators fitting to application domains" [START_REF] Tolvanen | MetaEdit+: Defining and Using Domain-Specific Modeling Languages and Code Generators[END_REF]. It lets users define domain-specific meta-models that are used to generate a tool that is suited specifically for creating diagrams based on that meta-model. In this case, the meta-model for PDD has been implemented by defining all constructs (activities, deliverables, etc.) and rules, in addition to the visual aspects of those constructs.

Next to the modeling-capabilities of MetaEdit+, the tool also embeds a transformation language called MERL, or the MetaEdit+ R* Language. This language allows for converting diagrams into any format required. Although the language in itself is not very powerful, some tricks will make any conversion to a textual format such as XML or latex possible.

The language is normally used for code generation, in the context of modeldriven development. With such approaches, the solution domain is modeled using a domain-specific language/diagram, after which the diagram is analyzed and converted into source code. In this case, the information stored in the diagrams is used to describe the context / situation of an SPM process, and to assess its maturity (model-driven assessment).

For this research, generators have been written that allow the generation of a filled-in maturity matrix based on all PDDs of a company's process [START_REF] Vlaanderen | Improving Software Product Management Processes : a detailed view of the Product Software Knowledge Infrastructure[END_REF]. Combined with the actual diagrams, these pieces of information form a good overview of the maturity of a process, along with its description in terms of activities and deliverables.

Template Generation

As described earlier, changes made to a process through the OME should be facilitated and supported as much as possible, to ensure the success of the evolution. One technique for doing so is providing automated templates based on the deliverables of a process. In the case of minor changes, changes made to a template can be incorporated in the original company documents, preserving any data already existing. We developed a proof of concept, in which we show how a Google spreadsheet can be updated dynamically by changing the meta-model of a method fragment.

In Figure 6, the meta-model of a deliverable of a requirements prioritization activity is presented. This deliverable is a requirement. In the old case, this requirement had three attributes: No., Topic, and Priority. This priority was added based on the personal preference of the one who stored the requirements.

In the new situation, another approach is used to prioritize the requirements. The variables 'Cost', 'Weight' and 'Revenue' are added and used to calculate the priority. Furthermore, the attributes 'TeamA' and 'TeamB' are added to divide the costs (in man days) to the teams.

In the two spreadsheets that are illustrated in Figure 6, the change in the meta-model of the requirements can be viewed. Extra columns have been added to the spreadsheet. In this case, some of the cells in the new template are already filled in. Normally, this is a job for the method user. To make templates useful in practice, the current information as provided by the method fragment does not suffice. Relations within and between concepts are not clearly defined. This means that, for example, the formula that specifies the value of 'Cost' based on the other attributes (in the example above) cannot be modeled. At this point, we do not yet have a satisfactory solution for this.

Conclusions & Further Research

In this paper, we presented our vision on the OME, an online environment that can be used to assess an organization's current processes, create an advice based on this assessment, and align the company's tooling infrastructure with the method improvement by automatically configuring templates and documents.

Although the concept presented in this paper is fairly detailed, the OME that we envision is not yet operational. The complexity of such a system was already known, and this paper only strengthens the idea that we are dealing with an advanced concept requiring a lot of research effort. From this point onwards, each of the areas of the OME needs to be addressed in detail, putting together the puzzle piece by piece. Expertise in several areas will be needed, as each part of the OME has its specific challenges, from linguistic analysis for method assembly to data-optimization for the method base.

Up until this stage, the research effort has mainly been focused on analyzing the current situation and the need, with a focus on the SPM domain. Furthermore, a lot of research effort has been spent on the underlying meta-modeling techniques that are used throughout the system. This leaves the remaining areas of process alternative selection, improvement roadmap creation, and increment selection and implementation open for future research.

An important factor that can never be left out during the elaboration is the fact that the purpose of the OME is the improvement of processes. As a consequence, we are always dealing with people that bring habits, experiences, and opinions. This should not be overlooked. Doing so would result in a system that is too rigid, forcing people into ways of working that they will not accept, thereby foregoing the purpose of the system. However, if it is done right, than the OME has great potential value. We believe that this solution can increase the maturity of the software industry significantly by providing professionals with the right tools to optimize their processes.

Unfortunately, the detailed OME that is presented in this paper has not been fully validated yet. As no concrete system exists yet, doing so would have involved asking potential users to imagine themselves using such a system. This is a tremendous effort, especially due to the complexity of it, and would likely not have resulted in a valid response. However, as development continues, the user should not be forgotten. Instead, at several points in time, his opinion should be asked and corrections should be made according to it. When done correctly, this will result in a functional online method engineering environment.

Fig. 1 .

 1 Fig. 1. Incremental Process Improvement

Fig. 3 .

 3 Fig. 3. Analysis of Need

Fig. 4 .

 4 Fig. 4. Example Areas of Improvement Matrix

Fig. 5 .

 5 Fig. 5. Online Method Engine

Fig. 6 .

 6 Fig. 6. Example of an incremental template

Table 1 .

 1 Example Method Fragment with Attributes

	Wiegers' Prioritization Matrix
	Capabilities		Situation		Rating
	-Internal	Stakeholder	-# of requirements < 50	-Ease of use: 8/10
	Involvement		-Partner	involvement	-Satisfaction: 6.5/10
	-Prioritization Methodology	>= medium
	-Customer Involvement
	-Cost Revenue Consideration
	-Partner Involvement


Stijn Hoppenbrouwers
email: s.hoppenbrouwers@cs.ru.nl

Martijn Zoet
email: martijn.zoet@hu.nl

Johan Versendaal
email: johan.versendaal@hu.nl

Inge Van De Weerd
email: i.vandeweerd@cs.uu.nl

Agile Service Development: A Rule-Based Method Engineering Approach

Keywords: method engineering, agile service development, business rules, business rules management, product management, game design

Agile software development has evolved into an increasingly mature software development approach and has been applied successfully in many software vendors' development departments. In this position paper, we address the broader agile service development. Based on method engineering principles we define a framework that conceptualizes an operational way of working for the development of services, emphatically taking into account agility. As a first level of agility, the framework contains situational project factors that influence the choice of method fragments; secondly, increased agility is proposed by describing and operationalizing these method fragments not as imperative steps or activities, but instead by means of sets of minimally specified, declarative rules that determine the context and constraints within which goals are to be reached. This approach borrows concepts from rules management, organizational patterns, and game design theory.

Introduction

To remain competitive, organizations are increasingly urged to adapt to changes in their business environment. Trends like higher demanding customers, faster changing customers' demands, increased regulation, and offshoring give rise to the re-thinking of business models and processes. In the software development industry, a number of vendors have successfully applied 'agile software development process' principles, decreasing time-to-market and addressing rapidly changing customer demands.

Approaching this more generically, any business may likewise apply concepts of agility as a strategy to take up the described challenges in the business environment. Agility is defined as "the ability of a sensitive [organization] that exhibits flexibility to accommodate expected or unexpected changes rapidly, following the shortest time span, using economical, simple and quality instruments in a dynamic environment and applying updated prior knowledge and experience to learn from the internal and external environment" [START_REF] Qumer | An evaluation of the degree of agility in six agile methods and its applicability for method engineering[END_REF]. The aforementioned definition positioned in the context of agile service development asserts that an organization should be able to create or adapt a (business) service efficiently and effectively when changes occur in its environment. A business service is considered an externally visible and accessible unit of functionality offered by an organization to its environment, delivering a meaningful value to that environment. An example of such a service is 'an insurance product tailored towards singles'.

Agile development is not an alien concept in management and information systems research. It plays some role in existing work on situational method engineering in software product development literature [START_REF] Olle | Information Systems Methodologies: a Framework for Understanding[END_REF][START_REF] Kumar | Methodology engineering: a proposal for situationspecific methodology construction[END_REF][START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF][START_REF] Weerd | A product software knowledge infrastructure for situational capability maturation: Vision and case studies in product management[END_REF]. These studies acknowledge the need for development methods tuned to the situation of the project at hand. Based on situational factors distilled from the project, meta-methods composed of outlines or more detailed procedures, are selected and integrated into a coherent method appropriate for that specific situation [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF].

However, 'situational' is not synonymous to 'agile'. For a method to become truly agile, changing situational factors also have to be linked (if required) to 'run time', changes in the method: quick responses to new situational information, and the installation of short feedback loops applying to the method. Existing studies mainly focus on situational fit of the overall development process while still describing the actual method fragments in terms of 'non-agile', step-by-step, instructions inherent to traditional workflow-like process descriptions.

Method Engineering for Agile Service Development

Situationality is the ability of a method to respond and adapt to a specific environment based on defined characteristics [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF][START_REF] Ralyté | Towards a generic model for situational method engineering[END_REF]. Although scholars approach the concept from different viewpoints, the fundamental basis is the creation of reusable method parts called method fragments [START_REF] Harmsen | Situational method engineering for information system project approaches[END_REF] or method chunks [START_REF] Rolland | Specifying the reuse context of scenario method chunks[END_REF]. The method fragments are stored in a repository called the method base. In addition to the method fragments, also assembly rules and situational factors are stored inside the method base [START_REF] Weerd | A product software knowledge infrastructure for situational capability maturation: Vision and case studies in product management[END_REF].

Utilizing the perspective of situationality, method fragments can be used to provide some degree of agility with respect to the project at hand. Regarding the assembly of method fragments, our approach follows the configuration process for situational method engineering as proposed by Brinkkemper [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF]. However, our approach adds a second dimension of agility in operational execution.

Due to changes, predictable or unpredictable, in the environment, the method must be able to quickly adjust to the situation at hand. The method engineering process proposed by Brinkkemper [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF] incorporates this by means of a build-in feedback loop. This feedback loop facilitates selecting new process alternatives in terms of method fragments hereby inserting the underlying assumption that changes in the environment will result in replacing complete method fragments. We argue that changes in the environment will not always lead to changes in the executed method but can still influence the operational execution of a specific method fragment.

To realize this, we propose a particular operationalization of the method engineering approach and process in terms of the selection process of method fragments, situational factors and assembly rules. The idea is that participants are given as much freedom as possible within necessary methodical and contextual constraints (minimal specification), and that the ability to respond quickly to desired changes in the method (as indicated by fast feedback) is optimized: increased agility in our approach is supported by defining method fragments in a rule-based, declarative manner. This approach is inspired by principles and practices from (business) rules management, organizational patterns and game design theory. Rulebased specification of methods is vaguely suggested in [START_REF] Jacobson | Enough of Processes -Lets do Practices[END_REF], who argue in favor of using practices instead of processes in software engineering. Our approach is inspired by this line of thinking, but pushes for advanced description, management and operationalization of 'method rules' in a specific service development context.

In the following subsections the method engineering meta-model by Brinkkemper [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF] will be described in some more detail for 1) situational project factors and characteristics, and 2) method fragment description and identification (see figure 1).

Situational Project Factors and Characterization

Situational factors can be used to characterize projects, processes, and companies. Bekkers [START_REF] Bekkers | The influence of situational factors in software product management: an empirical study[END_REF] researched the influence of situational factors on the practice of software product management, which resulted in a list of 27 situational factors, divided over the categories (1) business unit characteristics, (2) customer characteristics, (3) market characteristics, (4) product characteristics, and (5) stakeholder involvement. A situational factor influence is, for example: "the amount of requirements that are submitted by the customers has a high impact on how requirements management processes should be carried out". If this situational factor were to change, the company should also change its processes in order to cope with this change. We intend to apply the 27 situational factors in the context of agile service development.

Method Fragments Description and Identification

We choose a rule-based, declarative approach to the description of method fragments. Declarative description allows for minimal specification. In an agile environment, 'just enough' explicit regulation of the way of working is to be preferred over imperative style, step-by-step instruction inherent to traditional flow-like process description. The declarative approach is mainly what has led us to introduce the 'game metaphor' as an image of how we intend to deal with describing agile methods and method fragments. As suggested in Hoppenbrouwers [START_REF] Hoppenbrouwers | Setting Rules of Play for Collaborative Modelling[END_REF][START_REF] Hoppenbrouwers | Method Engineering as Game Design: an Emerging HCI Perspective on Methods and CASE Tools[END_REF], methods can be fruitfully viewed as games. They have clear objectives and rules the participants are to comply to, or at least choose to be guided by. The driving concepts in this approach are goals. These can cover all aspects of what one wants to achieve (deliverable or product goals, like 'create an insurance product for singles, within 2 months') and how one wants to do this (process goals, like 'use SCRUM'; 'comply to HIPAA regulation'; 'actively involve representatives of prospective customers'). Many kinds of goals can be distinguished, and all of them can be represented in the form of rules. Goals are thus covered by goal rules.

To realize goals, activities are needed. If goals are logically ordered, so are the activities linked to them (like 'hold SCRUM standup meeting'), which can be planned in space and time, allocating specific people and resources. Activities can be temporally ordered, but do not need to be in principle. This is in line with the principles of declarative workflow [START_REF] Van Der Aalst | Declarative workflows: Balancing between flexibility and support[END_REF] and allows for minimal specification: formally planning only what needs to be planned, and leaving the rest to the team's powers of self-organization.

Not only goals can be expressed as rules, but also the temporal ordering (procedural rules: x before y) and even constraints on interaction: interaction rules that concern who talks to who ('tester t with stakeholder s') and by what means ('using think-aloud session using prototype PT2.1'). This links high-level method engineering to more operational method engineering involving communication situations [START_REF] Hoppenbrouwers | Focused Conceptualisation: Framing Questioning and Answering in Model-Oriented Dialogue Games[END_REF]. Additional rules can cover aspects like the format or language (i.e. meta-model notation: 'UML Use Cases, Class Diagrams, Activity Diagrams') of any deliverables strived for. At the operational level of communication situations, the rules have to be specific and readable enough to effectively guide people in their activities -in as far as such guidance is required (minimal specification).

There is a clear parallel between a declarative, rule-based approach, the game metaphor, and the use of patterns; in particular, organizational patterns [START_REF] Coplien | Patterns of Agile Software Development[END_REF]. Cockburn has advocated game-theoretical use of the game metaphor in studying the software engineering process [START_REF] Cockburn | The End of Software Engineering and the Start of Economic-Cooperative Gaming[END_REF], but not in the applied sense we now propose. Our rules for describing method fragments will cover principles and patterns of agile practice (including many existing ones), and operational reflections thereof.

Conclusions

In view of increasing demands for agility in processes for service development, we are in the early stages of applying existing principles and practices from situational method engineering to service development processes and methods, combining these with approaches supporting agile process management and execution. On the method engineering side, this requires some innovation concerning the description, management, and operationalization of methods. Without claiming that the approach put forward in this position paper will guarantee agility of processes for service development, we believe the approach proposed will allow for considerably better agility than existing practices in ME that are more rooted in imperative style specification of methods and method fragments. Our rule-based approach should enable quick adaptation of the method's 'rules of the game' to changing situational factors. 'Games played' will be short cycles or phases in development, in line with widespread agile practices in software engineering. In addition, we pay explicit attention to operationalization of methods by specifying actual 'games to be played' in terms of concrete 'communication situations', and linking these to higher level goals and activities as included in some method and drawn from the method base.

We will test and refine our approach to method engineering in agile service development in close cooperation with a number of partners from industry. We will explore our approach in the re-engineering of past project cases, but will also, even in the early stages of investigation, start applying our framework in real cases of running projects.

Our approach can be seen as complementary to another innovative direction in Method Engineering: that of 'Method as a Serivce' (MaaS) [START_REF] Rolland | Method Engineering: Towards Methods as Services[END_REF]. Method fragments are developed as method services which are implemented as web services. To make the method services widely available, a Method-Oriented Architecture (MOA) is proposed. With the concept of MaaS, the authors aim to overcome many drawbacks that exist with existing method fragments, such as lack of interoperability, and lack of interactivity.

Fig. 1 .

 1 Fig. 1. Method engineering approach for agile service development.

Service Development project (http://www.novay.nl/okb/projects/agileservice-development/7628), a collaborative research initiative focused on methods, techniques and tools for the agile development of business services. The project consortium consists of BeInformed, BiZZdesign, CRP Henri Tudor, HU The project is part of the program Service Innovation & ICT of the Dutch Ministry


Vincent Albert
email: vincent.albert@laas.fr

Clément Foucher
email: clement.foucher@laas.fr

Formal Framework for Discrete-Event Simulation

Keywords: Discrete-event simulation, Parallel simulator, Time Petri Net, Formal methods, MBSE

A formal framework for modelling and simulation of parallel systems named ProjectDEVS is presented. The objective of this framework is to apply a Model-Based System Engineering approach to the development of simulation products for cyber-physical embedded systems. It is intended for the design and automated deployment of virtual prototypes. Models are constructed by coupling concurrent components exchanging data through ports and executed by various simulation schemes, namely simulators. This paper focuses on the integration of a Time Petri Net implementation of a parallel simulator into the framework. The semantics of the parallel simulator is formally described using timed transition system to verify the correctness of the implementation. Then, a model with its simulator can be model checked against formal specification and be rapidly deployed on FPGA or PC via code generators.

INTRODUCTION

A cyber-physical system is a system composed of computing processes (the controller) in interaction with physical processes (the plant) for control and command. During the development cycle of a controller/plant system, different simulation platforms are used for validation purposes. We believe that a Model-Based System Engineering (MBSE) approach allows, for the development of both embedded system and their simulation products, ensuring their reliability, promoting design and test of candidate architectures, mixing real or simulated components of the controller and/or plant, and of course reducing their development time. A MBSE approach typically relies on model transformations and code generators.

At a very early stage, virtual prototyping is used to study the performance of the system and design the control algorithms with a simulated plant. Virtual prototype does not require neither the controller nor the plant to operate in real time. However, it can be executed as a software, i.e. on a desktop simulator, or instantiated on a dedicated digital hardware processing unit or a mix of both. Dedicated digital hardware processing units can be used to accelerate various computations instead of using software. With the advent of Field-Programmable Gate Arrays (FPGAs), one can design a hardware circuit and instantiate it immediately instead of going through the long process of designing an Application-Specific Integrated Circuit (ASIC). Using FPGA devices, the creation of hardware accelerators dedicated to a specific or occasional purpose becomes possible.

Discrete event simulation is widely used for the validation of parallel and distributed systems. NS3 and Omnet++, which are reference tools in the field of computer networks and VHDL simulation in the field of digital hardware processing units, use this discrete event paradigm. In the field of continuous systems simulation, there is a family of asynchronous (event-driven) numerical integrators called QSS, see [START_REF] Cellier | Continuous System Simulation[END_REF] for an overview of this method, that shows very good results. Those simulators all use the same scheme: it is the change of a variable (or signal) value which triggers what we call an event. An event can occur at any time. A variable is updated only when a specific event occurs at a discrete point of time. We call an event a time event when the considered variable is time, or a state event when it is a variable of the model. Whereas discrete-time simulators needs a special mechanism (zero-crossing functions) to handle state event for hybrid systems simulation, in discreteevent simulation, everything is time event because an event is scheduled and it is the time of the next event that makes simulation time advance.

In that context we develop a modelling and simulation tool of parallel systems named ProDEVS based on the Discrete Event System Specification (DEVS) formalism and its simulators. DEVS, formulated by [START_REF] Zeigler | Theory of Modeling and Simulation[END_REF], has an abstract syntax for atomic component which is nothing else than an interface (input/output) timed automata. It provides a modular and hierarchical construction of the model with the concept of coupled component that connects atomic component output ports to atomic component input ports. DEVS also defines a set of operational semantics (the way of executing the model), called the abstract simulator in the DEVS community, that can be seen as a Model of Computation (MoC), see [START_REF] Ptolemaeus | System Design, Modeling, and Simulation using Ptolemy II. Ptolemy.org[END_REF] for MoCs in Ptolemy. For instance we have the following Discrete-Event (DE) MoCs: Classic DEVS simulator (CDEVS) where components execution is sequential (only one component is executed at a time) and conservative Parallel DEVS simulator (PDEVS), formulated by [START_REF] Chow | Parallel DEVS: a Parallel, Hierarchical, Modular Modeling Formalism and its Distributed Simulator[END_REF], where several components can be executed at the same time but causality violations are strictly avoided. Various parallel and distributed simulation researchers have implemented parallel simulators for DEVS. A time warp optimistic DEVS simulator, see [START_REF] Jefferson | Fast Concurrent Simulation Using the Time Warp Mechanism[END_REF], where causality might be violated, detected and remedied using roll-back has been implemented by [START_REF] Christensen | Hierarchical Optimistic Distributed Simulation:Combining DEVS and Time Warp[END_REF]. A risk-free optimistic DEVS simulator, see [START_REF] Ferscha | Probabilistic Adaptive Direct Optimism Control in Time Warp[END_REF], where events are assessed for risk before sending has been implemented by [START_REF] Reisinger | Object Oriented Realization of a Parallel Discrete Event Simulator[END_REF]. See [START_REF] Zeigler | Theory of Modeling and Simulation[END_REF] for pseudo-code description of these abstract simulators. This paper focuses on the integration of a Time Petri Net (TPN) implementation of the PDEVS simulator into ProDEVS. This work results in a formal MBSE framework we called Pro-jectDEVS which takes a ProDEVS model and its simulator, automatically transforms them into a TPN and deploy the latter as a program, as digital hardware or as a mix of both. Petri net is very efficient to describe parallelism and concurrency (resource sharing, synchronization) between tasks or processes. The advantages of using TPN as a backbone between a ProDEVS model and the platform dependant virtual prototype are : (1) the development of new simulators are not hand coded anymore, there are specified using temporal logic and designed using TPN, without any impact on the deployment phase, (2) a model can be checked against a formal specification to some extent (formal methods are subject to combinatory explosion) and we can ensure that the virtual prototype is correct, (3) formal verification can be coupled with simulation statically or dynamically (during run-time).

In the next section the architecture of the framework is detailed. Then, Section 3 defines the DEVS formalism, the principles of PDEVS simulator and the class of TPN we use. In Section 4, the rules for implementing a DEVS atomic component and a PDEVS simulator are given. Section 5 describes and illustrates the method we employ to verify the implementation and finally, perspectives and issues are given in Section 6.

ARCHITECTURE

The architecture of the ProjectDEVS framework is illustrated on figure 1. It includes ProDEVS, the model designer of Pro-jectDEVS, which includes a GUI offering a block-oriented view for model design. A model is constructed with concurrent components that can be imported from ProDEVS components repository or designed from scratch using input/output timed automata that we specially profiled for DEVS formalism, see [START_REF] Vu | ProDEVS: An Event-driven Modeling and Simulation Tool for Hybrid Systems Using State Diagrams[END_REF]. User can create its own repository. Basically, the repository contains components for continuous systems, such as QSS integrators, or quantizers and switches for hybrid systems. We recently integrated FMI cosimulation and model exchange features, see MODELISAR (2014) for FMI specification, such that Fonctional Mockup Units (FMU) can also be imported in the model. We have developed a DEVS-FMI wrapper to synchronise discrete-time simulators with discrete-event simulators using FMI++. The FMI++ library is a utility package, implemented by [START_REF] Widl | The FMI++ Library: A High-level Utility Package for FMI for Model Exchange[END_REF], that provides simulation functionalities for FMI model exchange and cosimulation specification. It includes a numerical integrator and a state record mechanism for roll-back. From a model description captured in the GUI and a given abstract simulator, a TPN model is generated. This TPN can be exported to the TINA toolbox, see [START_REF] Berthomieu | Time Petri Nets Analysis with TINA[END_REF], for model checking.

Then, a description of the structure of the Petri Net with dedicated components to implement places and transitions, and boolean or logical equations to represent enabling and firing conditions can be generated for simulation. This generated code is associated to a Time Manager which is in charge of simulation time events synchronisation and Action Managers to handle data computation in reaction of transition firing. A simulation clock provides events to make the internal TPN state evolve. Combined with a Run Manager aware of the given TPN structure, the prototype can be interfaced to a controller for simulation controls (run, step, break) and data visualisation. Data is recorded on a value change event, and stored along with the associated simulation time. A mapping between the ProDEVS model domain and the platform dependant variables is loaded into the controller for data charts. For software deployment, we have Java and C code generators that provide binary code which is interfaced with the controller. For hardware, a VHDL code is generated in a synthesizable form which can be used on a FPGA. The component representing the model is then wrapped in a register-based structure which can be adapted to most bus interfaces. Then, the simulator is interfaced with the controller through an Ethernet network using a small program running on a processor inside the FPGA. Interfaces for buses used by Xilinx and Altera, AXI and Avalon, are generated along with the model code.

DEFINITIONS

Discrete Event System Specification

The following definition is taken from [START_REF] Zeigler | Theory of Modeling and Simulation[END_REF]. A DEVS atomic component is a tuple X, Y, S , δ ext , δ int , λ, ta in which :

• X = {(p, v)| p ∈ I ports, v ∈ X p }, is a set of input ports and their values, Y = {(p, v)| p ∈ Oports, v ∈ Y p }
, is a set of output ports and their values, and S is a set of sequential states, • δ ext : Q × X → S , is the external transition function which defines how the state changes when an input event occurs:

• Q = {(s, e)|s ∈ S , 0 ≤ e ≤ ta(s)} is the total state,
• e is the elapsed time since the last event, • δ int : S → S , is the internal transition function which defines how the state changes when a time event occurs, • λ : S → Y, is the output function which defines the output to produce at a time event, • ta : S → R + 0,∞ , is the time advance function which is used to determine the lifespan of a state.

DEVS defines an abstract syntax, whence transition functions and/or output functions may execute simple actions described by algebraic equation or complex functions with iterative loop and branch or even a FMU step.

An informal specification of PDEVS abstract simulator is now given. Every component is in a state s ∈ S at a given time and must be in that state for a period e = ta(s) if no input event occurs. When the time e has elapsed without any input event has occurred for some imminent components, an internal time event occurs, whence, they simultaneously calculate y = λ(s) and when every output computation is finished, they simultaneously trigger their internal transition function δ int (s). If instead, for some components, an input event x ∈ X occurs before the expiration of e, these non imminent components trigger their external transition function δ ext (s, e, x). Communications are asynchronous, i.e. non-blocking with the possibility of message loss. If upon receipt of a message on the input port x, a component is in a state s listening on x i.e., δ ext (s, e, x) ∈ δ ext , the message will be processed, otherwise it will be lost and ignored by the receiver. There may be multiple components which are candidates for internal time event at the same time. As a result of coupling, they may also receive input event at the same time. When ta(s) = ∞, only an input event will leave the state. When ta(s) = 0, the component is immediately imminent.

Time Petri Net

The following definitions are taken from [START_REF] Berthomieu | Model-checking Bounded Prioriterized Time Petri Nets[END_REF]. Definition 1. A Time Petri Net with priority (PrTPN) is a tuple P, T, Pre, Post, , m 0 , I s with :

• P, T, Pre, Post, m 0 is a Petri Net where P is the set of places, T is the set of transitions, m 0 is the initial marking and Pre, Post : T × P → R + 0,∞ are pre and post incidence matrices respectively.

• I s : T → I + is the static interval function with I + the set of non empty real intervals with non negative rational endpoints.

• is the priority relation, assumed irreflexive, asymmetric and transitive. Priority are represented by oriented arcs between transitions, the source transition having higher priority.

Moreover, we use various arcs implemented in TINA. The standard arc is written p → t with p ∈ P and t ∈ T gives Pre(t, p) = 1 or t → p with p ∈ P and t ∈ T gives Post(t, p) = 1. The inhibitor arc, written p t disables t if there is at least one token in p. The reset arc written p * → t removes all tokens of p when t is fired. The reset arc is non blocking for a transition t, i.e. Pre(t, p) = 0. The read arc written p t is blocking, i.e. Pre(t, p) = 1, but does not modify the marking of p after firing of t.

Definition 2. A state of a TPN is a pair s = (m, I) in which m is a marking and I is a function called the interval function. Function I : T → I + associates a temporal interval with every transition enabled at m. Definition 3. The semantics of a PrTPN P,T,Pre,Post, ,m 0 ,I s is the timed transition system S , s 0 , where:

• S is the set of states (m, I) of the PrTPN • s 0 = (m 0 , I 0 ) is the initial state, where m 0 is the initial marking and I 0 is the static interval function I s restricted to the transitions enabled at m 0 .

• ⊆ S × T ∪ R + × S is the state transition, defined as follows ((s, a, s ) ∈ is written s a s ). • we have (m, I) t (m , I ) iff t ∈ T and: (1) m ≥ Pre(t), t is enabled at state m (2) 0 ∈ I(t), t is fireable instantly (3) (∀t ∈ T ) then (m ≥ Pre(t ) and (t t) ⇒ 0 I(t ))
, there is no transition with higher priority that satisfies 1 and 2 (4

) (∀k ∈ T )(m ≥ Pre(k) ⇒ I (k) = if k t ∧ m -Pre(t) ≥ Pre(k) then I(k) else I s (k)).
After the firing of t then m = m -Pre(t) + Post(t), transitions that remain enabled (except t) preserve their interval before firing, all others transitions are associated with their static interval.

• we have (m, I) θ (m , I ) iff θ ∈ R + and :

(5) (∀k ∈ T )(m ≥ Pre(k) ⇒ θ ≤↑ I(k)), a temporal transition θ is possible if θ is not larger than the right endpoint of any transition enabled. For every atomic component n = X, Y, S , δ ext , δ int , λ, ta we define a TPN P n , T n , Pre, Post, m 0 , I s such that:

(6) (∀k ∈ T )(m ≥ Pre(k) ⇒ I (k) = I(k) -θ,
(1) for every state s ∈ S we have a place p s ∈ P n (2) for every input port x ∈ X we have a place p x ∈ P n (3) for every output port y ∈ Y we have a place p y ∈ P n (4) we have places p spk,n , p spkd,n , p mv,n , p mvd,n ∈ P n which are used for communication with the coordinator (5) we have a place p imm ∈ P n . When p imm is marked, it denotes that the component is imminent ( 6 Consider an atomic component n at the initial state s ∈ S , then p ck,s and p s are marked. The only condition for firing t im,s is the marking of p ck,s . If p ck,s remains marked for time ta(s) because no external event has occurred, then t im,s is fired and p imm is marked denoting that n is imminent. An output function is then triggered by the firing of t λ,s which produces a token in p y . Then, the internal transition function is triggered by firing t δ int ,s . Every input port place is emptied and the component is in a new state s denoted by the marking of p s . If an input external event on port x ∈ X has occurred before ta(s) expired, denoted by the marking of the input port place p x , the external transition function is triggered by the firing of t δ ext ,s . Every input port place is emptied and the token in p ck,s is consumed. n is now at state s denoted by the marking of p s and a new cycle starts. If n receives an input event on x, m(p x ) = 1 while n is imminent, m(p imm ) = 1, then there is a conflict between t δ int ,s and t δ ext ,s that can be resolved by adding a priority.

TPN model of a ProDEVS model and its PDEVS simulator

The semantic of a TPNDEVS model is a game, where the players are the atomic components, that takes place in two For each stage players can also pass. Each stage is modelled by a Petri Net parallel structure. For each simulation step, the players will speak in parallel, then synchronise each other, then move in parallel and finally synchronize again.

A PDEVS coordinator is a PrTPN P, T, Pre, Post, , m 0 , I s such that:

(1) we have a place p 1immN ∈ P denoting the number of imminent components at a given simulation cycle and we have transitions t spk , t mv ∈ T denoting the time to speak or to move respectively. (2) for every atomic component n ∈ N we have:

• The initial marking gives one token in places p spk,1 , ..., p spk,n denoting to the players that they can speak. p spk,n is consumed either by the firing of an output function transition or by t spkpass,n if p imm,n has no token. Every component can trigger an output function if it is imminent otherwise it passes. At the end of this stage, t mv is enabled. Then, the marking of p mv,1 , ..., p mv,n denotes it's time to move. A component n can trigger an external or internal transition function or pass by the firing of t mvpass,n . Note that input port places are emptied by the firing of t mvpass,n . Indeed, it is possible that a non imminent component receives inputs while it is in a state that do not accept these inputs. When every component has moved a new cycle starts.

VERIFICATION

Model checking consists in applying temporal logic to semantics. To reason by model checking on a ProDEVS model, the transformation must be sound. A transformation is sound if the semantics of the ProDEVS model with its simulator, called the abstract semantics, cover all possible cases of the semantics of the corresponding TPN, called the concrete semantics. Whence, a logic formula is satisfied in the concrete only if it is satisfied in the abstract. We have manually defined abstract semantics with timed transition system (S , s 0 , ) as given by definition 3. The bottom graph in figure 5 shows a part of the abstract semantics for the phase speak with three imminent components in the model. Transition labels a, b and c mean that component A, B and C respectively have spoken, i.e. an output event has been computed. This graph says that, in PDEVS, if multiple components are candidate for time internal event, the outputs can be computed in parallel. Then, the abstract semantics is mapped on the concrete semantics as illustrated in figure 5. The top graph shows the part of the state graph given by TINA with a mapping to the abstract semantics. We can observe that the abstract semantics covers all the possible cases of the concrete semantics and that markings, states and traces are preserved.

The figure 6 5. Abstract semantics and mapping to concrete semantics are all candidates to internal time event, and if C is in a state that listens on external transition g with an input connected to the output triggered by the output function a. There is an unresolved non-determinism in the ProDEVS model because an internal event time is equal to an input external event time which leads to consider two transitions that potentially brings the system to different states. Again, after the mapping, one can observe that the abstract semantics covers all the possible cases of the concrete semantics and that branching is preserved. This paper shows the integration of a Time Petri Net implementation of a parallel simulator into a modelling and simulation tool for virtual prototype development. A designed model and its simulator are automatically transformed into a correct TPN. Model checking, to verify absence of deadlock, detect non determinism, ensure reachability or safety, can be performed onto the abstract model domain using the TINA toolbox. However, as TINA only handles integers for variable and time, the data part, i.e. the action managers of the ProDEVS model are not part of the state space if it is not finite (every variable including time advance function is a bounded integer). Moreover every time advance function must be static.

The TPN model is then automatically deployed on a platform via code generators. This has at least two advantages. First, we feel more confident and comfortable in implementing simulators with TPN rather than manually code it which is error prone while TPN2Code generators are developed once for each execution platform then works for every simulator and every model. Second, in DEVS, a simulator is constructed hierarchically in order to preserve causality violation with local clock synchronisation at each level. Our transformation flattens the model so it improves the performance of the simulation by eliminating intermediate coordinators and message passing.

The other source of overall performance improvement of the simulation comes from the hardware virtual prototype. Compared to software execution, there are two major differences in the run time: the hardware generation can be very long (up to quarter an hour), where the software code compilation takes only seconds. But the hardware execution time is unrivaled by software: only a few clock cycles are used to perform a full simulation step, where the software code is dependant on a sequential execution scheme which slows it down. Thus, for small models very quickly executed on software, one will have no interest in using the hardware execution. For large models and very long simulations times however, the hardware penalty coming from the circuit generation is very quickly offset by the gain in execution time.

  Fig. 1. ProjectDEVS Architecture

Fig. 2 .

 2 Fig. 2. TPN blocs for atomic component port. A connection from an output port to an input port results in the fusion of the two corresponding places. Another TPN, the coordinator, is used for synchronisation and scheduling of atomic components. Atomic components and coordinator communicate via places. The figure 3 illustrates a TPNDEVS structure where an arrow represents a fusion of places.

Fig. 4 .

 4 Fig. 4. PDEVS coordinator stages for every simulation step. In the first stage, players can speak by triggering an output function and in the second stage they can move by triggering an internal or an external transition function.For each stage players can also pass. Each stage is modelled by a Petri Net parallel structure. For each simulation step, the players will speak in parallel, then synchronise each other, then move in parallel and finally synchronize again.

p

  1immN is used to preserve deadlock if every component is in state s with ta(s) = ∞. It denotes that at least one component among N must be imminent to continue the game. It is the only place of the all TPNDEVS which is N-bounded. All others places are 1-bounded.

  Fig. 5. Abstract semantics and mapping to concrete semantics

  Fig.6. Abstract semantics with conflict between internal and external events 6. CONCLUSION

  imm t λ,s and t λ,s → p y , the marking of p y ∈ P denotes that a data is available in the output port y ∈ Y and t λ,s denotes the firing of the output function from s (8) for every internal transition function δ int (s) ∈ δ int , we have a transition t δ Finally, we have p imm * → t δ ext ,s , p ck,s * → t δ ext ,s and if ta(s ) ∞ we have t δ ext ,s → p ck,s .

) for every state s ∈ S such that ta(s) ∞ we have a place p ck,s ∈ P n and a transition t im,s ∈ T n . We have p ck,s → t im,s , t im,s → p imm and I s(t im,s ) = [ta(s); ta(s)] (7) for every output function λ(s) ∈ λ we have a transition t λ,s ∈ T n such that I s(t λ,s ) = [0; 0], i.e. the firing is immediate, p int ,s ∈ T n such that I s(t δ int ,s ) = [0; 0] and p imm → t δ int ,s . The marking of p s denotes that the current state is s. For every internal transition function δ int (s) = s , we have p s → t δ int ,s and t δ int ,s → p s , and for every input port x ∈ X, we have p x * → t δ int ,s . Finally, if ta(s ) ∞ we have t δ int ,s → p ck,s (9) for every external transition function δ ext (s, e, x) ∈ δ ext , we have a transition t δ ext ,s ∈ T n such that I s(t δ ext ,s ) = [0; 0]. For every external transition function δ ext (s, e, x) = s , we have p s → t δ ext ,s , t δ ext ,s → p s and p x → t δ ext ,s , and for every input port x ∈ X (except x), we have p x * → t δ ext ,s .

  places p spk,n , p spkd,n , p mv,n , p mvd,n ∈ P and transitions t spkpass,n , t mvpass,n ∈ T . p spk,n and p mv,n denoting that component n can move and speak respectively. p spkd,n and p mvd,n denote that n has spoken or moved respectively. t spkpass,n and t mvpass,n are fired if n pass its turn at stage speak and move respectively • p imm,n t spkpass,n , denotes that a component can pass its turn only if it is non imminent. For every t im,s ∈ T n we have t im,s t spkpass,n • for every t λ,s ∈ T n , we have p spk,n → t λ,s , t λ,s → p spkd,n and t λ,s → p 1immN • for every t δ int ∈ T n , we have p mv,n → t δ int , t δ int → p mvd,n , t δ int t mvpass,n . Idem for every t δ ext ∈ T n • for every p x ∈ P we have p x * → t mvpass,n .

	The graphical representation of the TPN model of a ProDEVS
	model and its PDEVS simulator is given on figure 4.