Dorian Seillier

Anne Baillot

Marie Puren

Charles Riondet

Survey on researchers requirements and practices towards Cultural Heritage institutions Documentation and analysis

Giving access to high quality Cultural Heritage data and metadata

Arts and Humanities research is mainly based on the analysis of "human traces" -such as artefacts, pieces of art, written documents, audio and video recordings, photographs, etc.that are most of the time preserved by Cultural Heritage Institutions (or CHIs). To preserve, study and promote these objects, an increasing number of heterogeneous digital data is produced by CHIs, but also by Arts and Humanities scholars themselves. For instance, digital Cultural Heritage data include natively digital documents (like qualitative or quantitative datasets, digital photographs, transcriptions, etc.), digitized resources of all kind (such as scanned texts, digitized images or 3D models, etc.), but also attached metadata, annotation or further enrichments. In this regard, access to high quality Cultural Heritage data and metadata is essential to ensure high quality research in Arts and Humanities. Data sharing is indeed a key issue in the future development of Digital Humanities. According to this vision, enabling access to and promoting the reuse of Cultural Heritage data are thus crucial to create new collaboration and new research, facilitate the development of an open publishing environment for Arts and Humanities research, and reinforce the adoption of digital methods and workflows amongst researchers.

However, in their relations with CHI, scholars seem always facing the same recurring problem: « There is no generally valid rule as to how they can quote, duplicate and furthermore republish in their scholarly work 2 ». This situation is clearly a hindrance for both CHIs and scholars, to develop new research on the one hand, and on the other to gain visibility. It is now essential to tackle this issue by providing a clear and comprehensive framework that enables interactions between CHIs and Arts and Humanities scholars.

Offering a comprehensive framework for researchers and CHIs

To provide such a framework, we propose to design a common and generic online environment regarding all aspects relevant to access to and reuse of Cultural Heritage data and metadata. This initiative is supported by APEF 3 , CLARIN ERIC 4 , DARIAH-EU 5 , E-RIHS 6 , Europeana 7 , IPERION-CH 8 and PARTHENOS 9 .

In this regard, we need first to identify all the actors taking part in the reuse of digital Cultural Heritage data, in order to take into account their specific needs and to delineate the form of their engagement. Five actors have been identified: first and foremost Cultural Heritage Institutions and researchers, but also research institutions, data centers, and Cultural Heritage laboratories.

We need then to identify their priority needs in terms of data sharing and reuse. As a first step, we have chosen to focus on interactions between Cultural Heritage Institutions and researchers.

In order to tailor the scope of this web environment to its prospective users, several workshops 10 have been already conducted with CHIs to gather their insight and get a better understanding of their needs. The survey presented here was also conceived and realized as an explorative part in the creation and development of this online environment aiming at 2 Laurent Romary, Mike Mertens, Anne Baillot, "Data fluidity in DARIAH -pushing the agenda forward", BIBLIOTHEK Forschung und Praxis, De Gruyter, 2016, 39 (3), pp.350-357. <hal-01285917v2> 3 www.archivesportaleurope.net 4 www.clarin.eu 5 www.dariah.eu 6 www.erihs.fr 7 www.europeana.eu 8 www.iperionch.eu 9 www.parthenos-project.eu 10 In Berlin and Paris in November 2016, and in Dublin in February 2017 simplifying Cultural Heritage research. It specifically addresses researchers and aims at having a clear understanding of:

• Difficulties encountered by scholars when they explore collections and exploit Cultural Heritage data;

• Their needs concerning the reuse of Cultural Heritage data;

• Their willingness to share the data they create during their research activities (with CHIs and peers).

In user-centered design (such as it was used to conceive the survey presented here), this development step is called user research. It helps prevent misconceptions about user requirements, behaviors or motives, as much as possible. User research requires empathy with the users, taking into account their personal experience and relying on the knowledge they bring. In order to achieve a balanced development, the output should introduce a distance towards this type of information, by specifically questioning and/or observing them. This was formalised in the concept papers derived from the workshops minutes regarding the position of the representatives of cultural heritage institutions. Still, the expectations of another major type of users remained unexplored, namely the researchers.

There are several ways of exploring user needs in user experience methods, between individual interviews, focus groups or surveys for the most prominent. We chose the latest mainly for commodity reasons: it was easier and less time-consuming to design a survey that we would post online and communicate to researchers through mailing lists. With this method, we get less qualitative information from the users than we would get from interviews, but we gain quantitative value by having more responses. In this case like in many others, the survey allows us to gather representative data from the respondents in order to build specifications during the design of the product. Besides, at the beginning of the design process, the team has a preliminary vision of the overall direction it wants to bring to the project. The team can formulate assumptions or hypotheses about user characteristics.

Surveys are efficient to confirm or reverse such assumptions. Lastly, it is easier to communicate quantitative results through this type of questionnaire because they allow for visual representations, such as histograms, charts, scatter plots, etc. Not only do those graphics help comprehend the results of a questionnaire quickly, they are also easier to display and explain to stakeholders.

With these different purposes in mind, we chose to use Limesurvey, a tool for building questionnaires and posting them online. It is a free and open-source application that is comparatively simple to handle.11 All these types of questions were addressed in this questionnaire (for a total of 36 questions). Its general structure is as follows: an introduction, the questions divided in four parts, the thanks and a contact address.

Structure of the survey

In a short introduction, the purpose of this study was explained as clearly as possible, but without revealing too much. This way, we hoped to prevent influencing the respondents: « We would like to learn more about researchers' practices and their experiences with

Cultural Heritage Institutions when they are engaging in transactions involving Cultural

Heritage Data reuse. This information will help us identify any issues and obstacles you may have encountered, in order to design an online solution that would ease collaboration, exchange and information retrieval. » This part is insofar of importance as it helps raise the curiosity of the respondent by giving him/her a clear idea of the survey's relevance and purpose. At this point in the survey, we also indicate the likely duration for completing the survey (15min).

The core of the survey was built during a brainstorming session bringing together the members of the project team, where every piece of information that seemed important was listed. It appeared that the questions could be grouped into four distinct parts, depending on their main topic:

1. The sociological background of the respondents 2. The experience(s) they had with Cultural Heritage Institutions 3. Their practices / habits / behaviors as researchers

Their requirements towards an online tool (what features they would like)

A first version was sent to a small group of researchers as a pre-test around December 1st, 2016. Pre-testing is essential in order to identify poorly designed questions, whether they are hard to understand or too ambiguous. It also helps measure the time required for completing the questionnaire and adjust its length if necessary. We were able to come down to 15-20 minutes average duration.

The final version was released on December 15th, 2016. It was made available online and broadcasted through various channels: mainly by mailing lists (French DH list, French Open Access list, etc.), but also on Twitter. It remained accessible for respondents for two months and a half.

Results

The goal of this study was to obtain a clear overview of the way(s) in which researchers are used to interact with Cultural Heritage Institutions (CHIs) when they need their data. Such an overview covers the feelings they can have (positive or negative) towards their experiences with CHIs as well as what they more generally think of Open Access, licenses, research publications, citation, etc. The information gathered in this manner will be used to design a user-friendly platform, well aware of the researchers' needs on this matter.

Preamble: the main biases in responses to be aware of • Acquiescence: generally speaking, it is easier to answer "yes" to a question, rather than a "no" that can appear as a form of antagonism / opposition.

• Social desirability: the respondents tend to answer questions in a way that will look their best, under a perspective more "desirable" than reality. On the contrary, the less gratifying responses are minimized.

• Halo effect: frequently, the first answers given by a participant influence his/her later answers. This effect is mainly visible when several Likert scales 12 follow each other 12 A Likert Scale is the sum of responses to several Likert items. These items are usually displayed with a visual aid, such as a series of radio buttons or a horizontal bar representing a simple scale. This is a very useful question type when you want to get an overall measurement of sentiment around a particular topic, opinion, or experience and to also collect specific data on factors that contribute to that sentiment. on the same matter. In that case, the participant tends to check all the boxes being on the same "side" of the scale. -"Aesthetics" -"Architecture and urbanism" -"Arts" -"Didactics" -"Digital Art History" -"Education" -"Environment" -"Ethnomusicology" -"History of philosophy" -"Psychoanalysis / Psychiatry" 13 The survey was sent on two French mailing lists : "dh" (French Speaking discussion list about digital humanities) and "accès ouvert" (French Speaking discussion list on Open Access for French-speaking community). 14 See the « D2.1, Report on User Requirements » (https://goo.gl/3IwI5J), delivered by PARTHENOS, that gives a definition as well as a classification of the different research communities in humanities and social sciences.

Demographics

-"Semantic web" Two conclusions can be drawn from this. First, not all respondents felt involved in the categories proposed, which may suggest that they were not exhaustive enough. We can also note that we reached researchers who do not belong to Arts and Humanities communities (e.g. "Psychoanalysis / Psychiatry" or "Environment") and therefore did not recognize themselves in the proposed disciplinary fields. Second, the perception of one's discipline is clearly not unequivocal. For example, with "Digital Art History" and "History of philosophy", the respondents considered themselves outside the broad spectrum of "Study of the past", although they could legitimately have considered themselves included.

The respondents were then asked to disclose their "current research position" by picking one of the options proposed. A substantial disparity emerged since 40% described themselves as "technical experts" or "engineers". It was only logical to deduce from this that a fair proportion of the respondents has technical skills and a good digital literacy, which is confirmed by the global ranking they stated: above 50% at 4/5 and 5/5 : How would you rate your digital literacy on a scale from 1 to 5 ? This should by no means lead to an overall generalization of all researchers being comfortable with digital tools. Here, the bias of the dissemination via Digital Humanists channels certainly impacted the balance in the represented digital skills.

Lastly, a majority of the respondents are affiliated to a research institution (85%).

Contact with CHIs for data reuse

The first question about the contact made by the researcher with a CHI for a data reuse purpose is a "filtering" one: if the participant answered "no", he/she was not concerned by a series of questions dealing with that particular experience (the transaction between the researcher and the institution). In total, 25% of the respondents never needed to contact a CHI for obtaining data in their research activities. Cross-tabulated result shows a balanced distribution among the "no".

The serendipity can play a significant role in transactions between researchers and CHIs: 30% of the "yes" respondents reached an institution after having discovered one of its collection, as opposed to those remaining who picked the "research issue" as the main reason for contact. This can be taken into account in the framework of the web platform to be developed, for instance by highlighting "popular collections" in a certain way, or by proposing some kind of recommendation engine leading towards interesting collections for a researcher (based on his/her previous research, his/her domain, etc.). The platform should be conceived in such a way to incite the institutions to disclose more information online about their collections, to make them more visible and as a consequence more "discoverable".

The type of material the respondents are interested in varies a lot. Since this insight emerged from answers to an open question, we recoded the responses to group them inside meaningful categories. But the question might have lacked precision, and a wide range of responses appears to be too ambiguous for a relevant analysis. For example, "photos" as a written answer with no contextual information is hard to disambiguate because it can refer to two different types of items: the physical object itself, a photograph, that the researcher wants to study; or the means of access to any kind of material, such as texts or artefacts, that the researcher needs to take a picture of, for subsequent analysis.

It shows that there are still a lot of improvements to make to fluidify the transactions. The web platform that we proposed to develop, could have a major impact by promoting the reciprocity between cultural heritage partners: researchers can benefit from better guidance and clearer reuse conditions, while CHIs can benefit from higher visibility thanks to concerted dissemination and (meta)data enrichments (66% of the respondents claim that they are willing to share their research results with the partner institution they obtain the data from).

According to the respondents, the institutions are widely supportive of enriching their data with researchers' work.

Did you discuss the means of disseminating your research results with the institution? based on your work ? One way to help researchers and CHI partners collaborate more easily could be to offer a mean of proposing a specific enrichment to a dataset. This is clearly a feature to consider.

Finally, what was highlighted by this second part of the questionnaire is that clear reuse conditions and Open Science strategy constitute engaging factors for researchers who want to collaborate with CHIs.

Researchers practices

The aim of the third part of the questionnaire is to find out about the general opinions and habits of researchers in their day-to-day activities. Almost 70% of the respondents claim to be willing to share their results with the institutional partner, but under certain conditions: The participants seem to have some lack of interest and/or knowledge in the existing licenses, as well as the digital surrogates they produce (75% did not answer). There is an important gap to fill in this domain: raising awareness towards licensing issue needs to be addressed. The respondents mainly know the Creative Commons (CC) licenses and lean towards CC-BY in most cases, which means they only require the attribution of their work when reused by a third party. Free and open licenses like CC seem to be preferred by the majority of respondents -a result that certainly has to do with the overrepresented awareness for licensing issues in the group of respondents that actually answered the question.

Another interesting point is the correlation between the average digital literacy of the respondents and the importance given to data format: the few participants who ranked themselves below three to assess their digital literacy assigned less value to data format than those who ranked themselves higher.

Cross-tabulated : digital literacy // is data format an important issue for you ?

Need for an online solution

The need for up-to-date information from CHIs concerning their data policy is attested here: about 60% of the respondents want to be kept informed of any policy development from the CHI partners or soon to be. This could be addressed within the future online environment, through a notification system that would alert researchers of any significant change within institutions "followed" (or "bookmarked"). It has to be linked with the fact that about 70% of the participants consider that offering the opportunity to interact online with the institutions is "useful" or "very useful". Note that the vast majority owns at least one academic profile online, so it will have to be taken into account when researchers will register in the online interface: an external authentication system could be a solution to consider in that case.

How do you feel about interacting online with the institutions about reuse conditions ?

The openness and sharing of information are generally approved by the respondents since the majority is in favor of transparency concerning their institutional partners and the reuse conditions of their own data.

Finally, the questionnaire concludes by asking researchers to point out the kind of information they would like to be able to gather online from cultural heritage institutions: documentation on data policy is the most important item (after recoding the answers), since it is something that they sometimes struggle to find on the websites or portals of the institutions. The planned online environment can step in precisely there and make that kind of information more visible and accessible to a large audience.

Four-

  main categories of questions are usually addressed to the participants of a questionnaire: Demographic questions: who are they? -Behavior questions: what do they do? -Opinion questions: what do they think? -Knowledge questions: what do they know?

  After 2 months and a half, we collected 109 responses. The respondents came from 23 countries, mostly Europe. France is overrepresented (45 respondents), mainly because the survey was spread by a French research Institution, and posted to two French research mailing lists13 . The age distribution is balanced (about one quarter for each age group), as well as the discipline distribution. Four big disciplinary fields were proposed and borrowed from the PARTHENOS typology 14 :-Study of the past (including Ancient History, Medieval History, Modern History, Art History, Epigraphy, etc.) -Language-related studies (including Literature, Linguistics, Philology, Language Technology, etc.) -Archaeology, heritage and applied Discipline (including Cultural Heritage, Archives, Libraries, Museums, preservation experts, Digital curation / edition, etc.) -Social sciences (including Sociology, Political Science, Geography, Anthropology, Cultural Studies, etc.) It appears that a third of the respondents (31,2%) did not recognize themselves in the proposed disciplinary fields and chose the "Other" option. 11 of them specified their research domain in their own words in the comment area:

  Are you willing to share your research results with the institution that gave you access to their data ? Under what conditions would you be willing to share your research results with the CHI you worked with ?

  Are you affiliated to any research institution ?How would you rate your digital literacy on a scale from 1 to 5 ? Have you ever needed to contact a CHI in order to use its data for a research project ? Cross-tabulated : research domain // have you ever needed to contact a CHI in order to use its data for a research project ? Cross-tabulated : research position // have you ever needed to contact a CHI in order to use its data for a research project ? Cross-tabulated : age // Have you ever needed to contact a CHI in order to use its data for a research project ? Was the first contact mainly initiated by… ? Free comment : Was the first contact mainly initiated by… ? (recoded) About the data reuse conditions of the institution concerned : did your university or research institution played a role in this transaction ? About the data reuse conditions of the institution concerned : did the CHI guide you effectively in your request ? About the data reuse conditions of the institution concerned : were the reuse conditions easy to understand ? About the data reuse conditions of the institution concerned : did you face obstacles in accessing the data ? Did you sign a Memorandum of Understanding with the institution or any type of cooperation agreement ? Did you contact the institution anew ? Had the conditions of use/reuse changed ? Are you more likely to work (or work again)... with an institution whose conditions of data access are clearly stated ? Are you more likely to work (or work again)... with an institution that has an explicit open science strategy ? What do you think is the legal status of the facsimile or digital surrogates you produced on the basis of the physical collections of the institution ? Are you familiar with the different types of licenses available for the publication of your research results and data ?

https://team.inria.fr/almanach/

https://www.limesurvey.org/

What key information would you want to consult online regarding an institution you are likely to interact with ? (recoded)

Country where main research takes place

What type of material was involved in the transaction (recoded) ?How did you find out about the CHI you worked with ? (recoded)

If so, how did the institution feel about enriching their (meta)data based on your work ?Once your initial work on the data was complete, did you wish to keep working on these data for another project ?

Usually, how do you cite the institutions where your primary sources come from :the way your research institution wants you to ?Usually, how do you cite the institutions where your primary sources come from : the way the CHI recommends you to ?

Usually, how do you cite the institutions where your primary sources come from : the way your publisher recommends you to ?Usually, how do you cite the institutions where your primary sources come from : no particular guidelines ?

Nevertheless, the vast majority of respondents indicate that "scans" form the basis of day-today research in Humanities and Heritage disciplines. This type of material needs to be addressed first and foremost, but without excluding others like audio/video, metadata or databases, which are also requested for research.

When interacting with the CHIs for data reuse, researchers need to gain solid information on the reuse conditions of the objects that are at the core of the transaction. That requirement can sometimes be difficult to meet. This is why we asked respondents to express their feelings about their personal experience. Almost half of the respondents claim to have been guided by the institution itself when looking for that kind of information ("agree" and "strongly agree" added).

Did the CHI guide you effectively in your request ?

The same researchers were mostly satisfied with the quality of the reuse conditions they were asking in terms of understandability. Overall, the transaction system seems to be working well: there was no big dissatisfaction towards CHIs accompanying researchers in their project, excepted for the fact that they claim to have faced obstacles in accessing the data they asked for. with the institution ? 15 The purpose of the Memorandum of Understanding is to clearly state the reuse conditions of the data provided and could be a valuable feature of the online platform : to be able to read and sign all the conditions of an institution directly online.


Mario Cervera
email: mcervera@pros.upv.es

Manoli Albert
email: malbert@pros.upv.es

Victoria Torres
email: vtorres@pros.upv.es

Vicente Pelechano

Turning Method Engineering Support into Reality

Keywords: Method Engineering, Model Driven Development, CAME Environment, Eclipse, MOSKitt

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

Introduction

Software Production Methods (hereafter simply methods) are organized and systematic approaches for software development, which can adequately govern the disciplined execution of real software development projects, and are composed, inter alia, of structured and integrated sets of activities, work products and roles. Since the definition of a universally applicable method has for long been considered unattainable, it is necessary to find solutions that enable the in-house specification of methods adapted to specific context needs and the construction of the corresponding supporting tools. Up to now, the SME discipline seems to be the most promising alternative to supply this need.

The SME discipline constitutes a sub-area of a broader field called Method Engineering (ME). Specifically, within the ME (and SME) field, method and software engineers mainly deal with (1) the definition of methods (method design) and (2) the construction of the supporting software tools (method implementation) 1 . Therefore, proposals aimed at supporting ME should cover these two phases of the ME process. However, most of the ME proposals existing in the literature (and their corresponding tools) only focus on one of them. As examples of this reality we find Computer Aided Method Engineering (CAME) and metaCASE environments. On the one hand, CAME environments generally focus on the method design phase, supporting the specification of project-specific methods for software development. In some cases, these specifications are used for building CASE tools, but with very limited capabilities. On the other hand, the so-called metaCASE environments generally focus on the method implementation, supporting the customization of CASE tools by means of high level specifications. These specifications normally define the modeling languages that are to be supported by the CASE tool and, sometimes, also the process that establishes the order in which these languages must be used. Thus, these specifications are oriented towards CASE tool definition and therefore they do not represent complete software production methods.

In order to provide a more complete proposal, in this paper we propose a methodological framework that equally encompasses the method design and method implementation phases. Combining these two phases brings an important benefit. It increments the method specifications' value in terms of how much functionality is derived from them. That is to say, these specifications are not only used for governing the execution of the software development projects, but also for the construction of CASE tools that support the methods and assist the software engineers in the development of the final systems. To achieve this goal in an effective manner, we find crucial to define an infrastructure that (1) allows the method engineer to define methods that can be applied in real software projects and also (2) (semi)automates the construction of tools that provide adequate support to the specified methods. To successfully face the definition of this infrastructure, we advocate for the use of the MDD paradigm. Thereby, we have defined a MDD infrastructure based on metamodeling and model transformation techniques that lays the foundations of the methodological framework. Specifically, the meta-modeling techniques are based on the Software & Systems Process Engineering Meta-model (SPEM) [START_REF]Software Process Engineering Meta-model (SPEM) OMG Available Specification version 2.0[END_REF] and are the means that allow the method engineer to carry out the method design. On the other hand, model transformations (semi)automate the performance of the method implementation. By applying these ideas, we have defined a methodological approach that not only tackles the definition of methods following a widely accepted standard (SPEM), but also proposes to use these definitions for the (semi)automatic generation of tools that provide rich support to the methods (textual and graphical editors, code generators, model transformations, process enactment support, etc.).

The work reported here is an extension of our previous works [START_REF] Cervera | A Methodological Framework and Software Infrastructure for the Construction of Software Production Methods[END_REF] and [START_REF] Cervera | A Technological Framework to support Model Driven Method Engineering[END_REF]. On the one hand, the theoretical part of the methodological framework is analyzed in depth, with a contextualization of the different parts of the framework. On the other hand, the software infrastructure of the framework has evolved by enhancing the way in which engineering tools assist method engineers during the method construction.

Furthermore, as a proof of concept, we also provide details of the implemented framework, which has been developed on top of MOSKitt [21], an Eclipse-based modeling platform whose plugin-based architecture and integrated modeling tools turn it into a suitable platform to support the proposal.

The remainder of the paper is structured as follows. First, section 2 summarizes the state of the art. Then, section 3 provides an overview of the proposal. Section 4 and 5 thoroughly detail the MDD infrastructure and the methodological framework respectively. Finally, section 6 draws some conclusions and outlines future work.

State of the Art

The term Method Engineering was first introduced in the mid-eighties by Bergstra et al in [START_REF] Bergstra | A Software Development Model for Method Engineering[END_REF]. Since then, many works developed both at academia and industry have contributed to this field. In order to underpin its theory, a survey of the last strands in ME is gathered in [START_REF] Henderson-Sellers | Situational Method Engineering: State-of-the-Art Review[END_REF]. In this work, the definition proposed by Brinkkemper et al. in [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF] is used to define ME as the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems (IS).

Considering this definition, we have found that there are proposals in the ME literature that mainly focus on (1) the design, construction and adaptation of methods (i.e. the method design) while others concentrate on (2) the techniques and tools for supporting such methods (i.e. the method implementation). On the one hand, among the proposals mostly dedicated to method design, we find proposals such as Brinkkemper's [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF][START_REF] Brinkkemper | Meta-Modelling Based Assembly Techniques for Situational Method Engineering[END_REF], Ralyté's [START_REF] Mirbel | Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF][START_REF] Ralyté | Towards a generic model for situational method engineering[END_REF] or Henderson-Sellers' [START_REF] Henderson-Sellers | Method Engineering for OO Systems Development[END_REF], which tackle the method construction by means of the assembly of method fragments or chunks stored in a method base repository. Examples of tools that fall in this first category are MERET [START_REF] Heym | A Semantic Data Model for Methodology Engineering[END_REF], Method Editor [START_REF] Saeki | CAME : The first step to automated method engineering[END_REF] and Decamerone [14]. Some of these proposals do support the generation of CASE environments but with limited capabilities. For instance, Method Editor enables the generation of tools that include a series of diagram editors that allow the software engineer to create/manipulate the products specified in the method. However, Method Editor does not support the specification of automated tasks that require the inclusion of a model transformation in the generated tool. Thus, these CASE tools lack code generation capabilities.

On the other hand, there are proposals that mostly focus on the method implementation [START_REF] Ferguson | MetaMOOSE -an object-oriented framework for the construction of CASE tools[END_REF][START_REF] Grundy | Towards an Integrated Environment for Method Engineering[END_REF][START_REF] Roger | Meta-CASE in Practice: a Case for KOGGE[END_REF]. These are the so-called metaCASE environments that generally support the construction of CASE tools. Examples of tools that fall in this category are MetaMOOSE [START_REF] Ferguson | MetaMOOSE -an object-oriented framework for the construction of CASE tools[END_REF], KOGGE [START_REF] Roger | Meta-CASE in Practice: a Case for KOGGE[END_REF] and MetaEdit+ [START_REF] Kelly | MetaEdit+ A Fully Configurable Multi User and MultiTool CASE and CAME Environment[END_REF]. For instance, MetaEdit+ [START_REF] Kelly | MetaEdit+ A Fully Configurable Multi User and MultiTool CASE and CAME Environment[END_REF] provides a specification language (called GOPPRR) that is oriented towards the definition of the abstract syntax of the modeling languages (in [START_REF] Kelly | MetaEdit+ A Fully Configurable Multi User and MultiTool CASE and CAME Environment[END_REF] called "methods") that need to be supported by the resulting CASE tool. In contrast, in our proposal we provide a full methodology that assist in the definition of complete software production methods by means of the SPEM standard, and also proposes the use of a meta-meta-model (such as GOPPRR) for the definition of the modeling languages that enable the creation of the method products (see sections 3 and 5). In particular, the meta-meta-model that is used in the CAME environment that supports our proposal is Ecore. engineer is indicating that this editor must be included in the generated tool, so that it enables the manipulation of this particular product. The main benefit of separating method design and configuration is that we keep generic definitions of methods (which means that we can take this generic definition and perform different method configurations), stressing the importance of reusability.

• Method implementation: in this phase, the method model is used as input of a model transformation that generates the tool support. This tool provides support to the product and process parts of the method2 . The product support consists of the tools that enable the creation/manipulation of the method products (i.e. the resources associated to the method elements in the previous phase). The process support consists of a process engine that enables the method process execution.

The MDD Infrastructure

In this section we present the MDD infrastructure that lays the foundations of the methodological framework. As mentioned above, this infrastructure is based on metamodeling and model transformation techniques.

Meta-modeling

Meta-modeling has always played a key role in the ME field as it allows the definition at a high level of abstraction of the concepts, constraints and rules that are applicable in the construction of methods. In general, proposals focusing on the method design use meta-modeling as their underlying technique to define methods [START_REF] Brinkkemper | Meta-Modelling Based Assembly Techniques for Situational Method Engineering[END_REF][START_REF] Heym | A Semantic Data Model for Methodology Engineering[END_REF][START_REF] Mirbel | Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF]. Moreover, proposals focusing on the method implementation use these techniques to specify the modeling languages supported by the generated tools [START_REF] Grundy | Towards an Integrated Environment for Method Engineering[END_REF][START_REF] Kelly | MetaEdit+ A Fully Configurable Multi User and MultiTool CASE and CAME Environment[END_REF][START_REF] Roger | Meta-CASE in Practice: a Case for KOGGE[END_REF].

In our proposal we use meta-modeling techniques for the creation of the method model, in particular following the SPEM standard. A study about the applicability of SPEM to ME is presented in [START_REF] Niknafs | Towards a Process Modeling Language for Method Engineering Support[END_REF]. In this work, the authors present some of the SPEM advantages and disadvantages for supporting the method design. Among the SPEM advantages we highlight: (1) wide acceptance in the field of process engineering, (2) good ME process coverage, (3) support to both product and process parts of methods and (4) good abstraction and modularization. Regarding its disadvantages, [START_REF] Niknafs | Towards a Process Modeling Language for Method Engineering Support[END_REF] points out the lack of executable semantics, but proposes to overcome this limitation by using a model transformation to transform the process models into executable representations that can be executed by workflow engines.

In order to provide a more in-depth view on how the SPEM meta-model is used in our proposal, below the structure of the method fragments from which SPEM models can be assembled is presented in detail. In general, in the ME proposals that suggest the use of method fragments, these are obtained by instantiating some class of a metamodel. For instance, in the OPEN Process Framework [START_REF] Firesmith | The OPEN Process Framework. An Introduction[END_REF] method fragments are generated by instantiation from one of the top levels classes: Producer, Work Product and Work Unit [START_REF] Henderson-Sellers | Situational Method Engineering: State-of-the-Art Review[END_REF]. Specifically, next subsection details the SPEM classes from which method fragments can be created and, furthermore, it presents a taxonomy that classifies the different types of fragments that are used in the proposal.

We use the term method fragment to denote the atomic element from which methods can be assembled. Other terms to name these atomic elements, such as method chunk, have been proposed in the ME literature [START_REF] Henderson-Sellers | Comparison of Method Chunks and Method Fragments for Situational Method Engineering[END_REF]. A method fragment can be either a product fragment (instances of meta-classes that represent products) or a process fragment (instances of meta-classes that represent processes). This differentiation allows us [START_REF]Activiti[END_REF] to leverage the separation between product and process specification provided by SPEM3 , (2) to relate one process fragment with many product fragments, and (3) to reuse one product fragment in the definition of many process fragments.

Attending to the different phases identified in our framework (see section 3), we use a third type of fragment, namely technical fragment, term that was first proposed in [START_REF] Harmsen | Situational Method Engineering[END_REF]. In our proposal, these fragments contain the tools that are associated to the products and tasks of the method during the method configuration and that make up the infrastructure of the generated CASE tools.

Fig. 2. Relationship between method fragments and SPEM classes

In order to illustrate the hierarchical organization of the various types of fragments, the left side of Fig. 2 graphically presents our fragment taxonomy. In this taxonomy, the new abstract category conceptual fragment (also proposed in [START_REF] Harmsen | Situational Method Engineering[END_REF]) is introduced for grouping product and process fragments. Moreover, additional information has been included, e.g. the relationship Contains which represents that SPEM processes can contain nested subprocesses, or the relationship labeled as Uses which represents that one process fragment can reference from one to many product fragments.

On the other hand, the right side of Fig. 2 shows a simplified view of the SPEM meta-model. In SPEM, a method is represented by a MethodPlugin. Each MethodPlugin contains both ContentPackages and ProcessPackages. Tasks, Roles and WorkProducts are stored in ContentPackages. Similarly, within ProcessPackages, processes are stored as instances of the class ProcessComponent.

Note that some of these SPEM concepts have been associated with fragments of our taxonomy. These associations illustrate a containment relationship. For instance, process fragments are associated with one ProcessComponent. Thus we are representing that, when process fragments are stored in the repository, they contain a SPEM model that includes one instance of the class ProcessComponent. Furthermore, product fragments are associated with ContentElements, which represents that these fragments can contain any instances of Task, Role, and WorkProduct.

Finally, even though it has been omitted in Fig. 2, method fragments are defined by a series of properties that enable their later retrieval from the repository. The fragment properties are stored in the manifest file of the RAS asset that embodies the fragment. Specifically, we make use of some of the properties defined in [START_REF] Ralyté | An Approach for Method Reengineering[END_REF]. According to these properties, our method fragments are characterized by: • Descriptor: it contains general knowledge about the fragment. For now, we consider the attributes origin, objective and type. Some examples of valid types in our proposal are task, role and work product for product fragments that contain atomic elements, or meta-model, editor, model transformation and guide for technical fragments (see section 5.2).

• Interface: it describes the context in which the fragment can be reused. For now, we only consider the attribute situation.

Model Transformations

In the previous subsection we showed that the application of meta-modeling in the ME field is not new. However, we find that the ME approaches that make use of these techniques do not really take full advantage of the possibilities that MDD offers. As stated in [START_REF] Atkinson | Model-Driven Development: A Metamodeling Foundation[END_REF], "MDD improves developers' short-term productivity by increasing the value of primary software artifacts (i.e. the models) in terms of how much functionality they deliver". Following this statement and contrary to what current ME approaches do, we want to leverage models going one step further. Defining the method as a model and considering this model as a software artifact allows us to face the implementation of the CASE tool generation process by means of model transformations.

In particular, these transformations have been implemented in the CAME environment that supports our proposal as a single model-to-text (M2T) transformation using the XPand language [START_REF]Xpand[END_REF], which is the language used within the context of the MOSKitt project [21] for that purpose. Further details about this M2T transformation are provided in section 5.3 and in [START_REF] Cervera | A Technological Framework to support Model Driven Method Engineering[END_REF].

Th

In this se designed. detail the

M

During th this mode [START_REF] Ralyté | Towards a generic model for situational method engineering[END_REF] Method Design Software Infrastructure. In order to provide software support within MOSKitt to the method design phase, the following tools have been integrated as Eclipse plugins:

• A method editor: in order to enhance MOSKitt with the capability of building method models, the EPF Composer (a SPEM 2.0 editor provided in the EPF Project [START_REF]Eclipse Process Framework Project (EPF[END_REF]) has been integrated. This editor enables the enactment of the process described in Fig. 3,i.e. it allows method engineers to build SPEM models. In addition, it has been extended so it enables the enactment of the process shown in Fig. 5, i.e. it supports the creation of fragments. In Fig. 6 5 , a screenshot of the EPF Composer integrated in MOSKitt is shown. pecify the n (e.g. the del"). to specify ion (e.g. a e method. ans of the model transformations (e.g. a M2T transformation can be linked to the task "Generate report").

• Guide: guides (i.e. text files, process models, etc.) can be optionally associated to manual tasks of the method. These files will be included in the final tool and will assist software engineers in the performance of the tasks. For instance, a map can be associated to the task "Build Business Process Model" to define as a process model the steps that must be followed to perform the task.

Method Configuration Software Infrastructure. In order to provide software support within MOSKitt to the method configuration phase, the following tools have been integrated as Eclipse plugins:

• A repository client: In order to associate technical fragments with elements of the method model, it is necessary to implement a repository client that enables the enactment of the process described in Fig. 8. To do so, the repository client must allow the method engineer to (1) connect to the repository, (2) search and select technical fragments and (3) associate them with the elements of the method. The repository client Fig. 7 can be reused for this purpose. Fig. 9 shows this repository client connected to the Asset Base.

• A guide to configure the method model: A guide is provided as an Eclipse cheatsheet to assist in the performance of the method configuration phase.

Method Implementation

During this phase a tool supporting the method is obtained by means of model transformations. This tool is mainly divided into two parts: the dynamic part and the static part (see Fig. 10). • The graphical user interface (GUI): the GUI is composed of those elements that make up the visual representation of the tool and allow software engineers to execute method instances by means of the process engine. The GUI of the generated CASE tools does not directly depend on the method model (so, they always have the same look & feel) but it uses the method content part of the SPEM model to configure itself. For instance, depending on the role selected by the user, the GUI filters its content to show only the products and tasks that the user is in charge of.

The

Method Implementation Software Infrastructure. In order to provide software support within MOSKitt to the method implementation phase, the following tool has been implemented and integrated as an Eclipse plugin:

• A M2T transformation: this transformation obtains the tool that supports the method specified in the method model. This tool corresponds to a MOSKitt reconfiguration that only contains the required Eclipse plugins to support the method (i.e. the plugins contained in the technical fragments 8 , the process engine and the Eclipse views that compose the GUI). In order to build this MOSKitt reconfiguration we make use of the Eclipse Product Configuration files (.product files). This type of files gathers all the required information to automatically generate an Eclipse-based tool such as MOSKitt. So, considering that this tool is obtained from a .product file, the model transformation has been implemented as a M2T transformation. This transformation takes as input the model resulting from the method configuration phase and generates a .product file through which the final tool is automatically generated.

Conclusions and Future Work

In the ME field it is still unclear how to combine different subareas into a whole in order to define more complete proposals. As examples of this reality we find CAME and metaCASE environments, which either focus on the method design or the method implementation phases of the ME process. In this work, we have detailed the different steps of a methodological framework that adequately covers these two phases. For this purpose, the proposed framework applies an MDD approach, tackling the method design by means of meta-modeling techniques based on the SPEM standard and the method implementation by means of model transformations. The presented framework is being defined and implemented within the context of the MOSKitt project. This project constitutes a jointly work developed by the Conselleria de Infraestructuras y Transporte and the Centro de Investigación en Métodos de Producción de Software to develop a CASE tool to support the gvMétrica method. There is a big community involved in the project, ranging from analysts to end users, which are in charge of validating each new release of the tool. This setting constitutes an adequate environment to validate our proposal. In fact, in the near future we are planning to integrate our prototype into a MOSKitt version in order to use it for the definition of gvMétrica and the construction of the supporting tool.

Regarding future work, we are working on the improvement of the CAME environment that supports our proposal. For instance, we are planning the integration of a process engine such as Activiti [START_REF]Activiti[END_REF]. Furthermore, we are concerning with one of the big challenges of ME [START_REF] Armbrust | Scoping Software Process Models -Initial Concepts and Experience from Defining Space Standards[END_REF], which deals with the variability of methods at modeling level and runtime. Providing support to variability will allow stakeholders to dynamically adapt methods and their supporting tools to changes that occur during method execution.

  Fig. example, a q pecification m Type = the fragments ved by mean on of the sele fragment of a this integrat included in a ded as a subpr y, note that du se during the c ess fragments

Fig. 6 .Fig. 7 .

 67 Fig. 6. EPF Composer editor in MOSKitt

Fig. 9 .

 9 Fig. 9. Repository client connected to the Asset Base

The product part represents the artifacts that must be built during the method execution and the process part consists of the procedures that must be followed to build such products.

In order to use the same terminology as the used in the ME field, in our proposal we consider analogous the product-process separation of methods and the SPEM separation between method content and method process.

Note th automa product

Also available at http://users.dsic.upv.es/~vtorres/moskitt4me/

The dependencies of these plugins must also be included. We are planning to tackle dependencies management in the future.


Grzegorz Loniewski

Ausias Armesto
email: aarmesto@indra.es

Emilio Insfran
email: einsfran@dsic.upv.es

Incorporating Model-Driven Techniques into Requirements Engineering for the Service-Oriented Development Process

Keywords: Model-driven development, SOA, RUP extension, Requirements Engineering

Modern information systems, which are the result of the interconnection of systems of many organizations, run in variable contexts, and require both a lightweight approach to interoperability and the capability to actively react to changing requirements and failures. Model-Driven Development (MDD) and Service-Oriented Architecture (SOA) are software development approaches that deal with this complexity, reducing time and cost development and augmenting flexibility and interoperability. Although, requirements engineering is accepted as a critical activity in these approaches, there is a need to appropriately integrate and automate the requirements modeling and transformation tasks as part of MDD and SOA development approaches. Our proposal is a Rational Unified Process (RUP) extension, in which the requirements discipline is placed in a model-driven context in order to derive SOAs. This paper includes the definition of a model-driven requirements process including activities, roles, and work products.

Introduction

The domains and problems for which it would be desirable to introduce information systems are currently very complex and the software development process is thus of the same complexity. Several software development approaches have been introduced in order to speed up and facilitate this process through its automation and the division of the final product into smaller building blocks.

One of these approaches is Service-Oriented Architecture (SOA). SOA is a logical means of designing a software system to provide independent services that are aligned with business processes. SOA strengthens such factors as reusability, scalability or interoperability.

Another approach that improves the development process of complex applications is Model-Driven Development (MDD). This is a model-based approach that promotes the separation of concerns between the business specifications and their implementation. This separation is achieved through the use of models that allow the level of abstraction to be elevated. It provides a means for development process automation by model transformations and code generation rules.

These approaches are very often used during the design phase of software development, less often in the analysis phase, and hardly ever in the initial phase of a software project when requirements have to be captured, understood and specified. Moreover, even though the aforementioned approaches provide the means to support the software development process, all such techniques, methods or architecture styles are of little use without a well-defined process that places them in a particular context.

In our opinion, the solution to providing a successful automatable development of SOA-based systems is a well-defined, and flexible model-driven process, which is requirements engineering (RE). A good basis for the development of such a methodological approach is the Rational Unified Process. RUP is a costumizable and extensible software engineering process that provides a disciplined approach with which to define tasks and responsibilities in an organized system development [START_REF] Kruchten | The Rational Unified Process: an introduction[END_REF]. Although various attempts to adapt RUP to MDD principles exist, e.g. Agile Unified Process (AUP), the development process remains mainly manual.

This paper presents a proposal for a RUP extension and adaptation with which to develop SOA-based systems by using model-driven techniques. The main extension in this methodology is the replacement of the Requirements discipline with the Model-Driven Requirements. This work can be considered as an interesting contribution for those software process engineers who are faced with the challenge of guiding software development projects that follow a modeldriven development approach from the requirements elicitation.

This work is structured as follows. Section 2 presents works related to the aforementioned area of concern. Section 3 provides an overview of the software process engineering standards. Section 4 presents an overview of the main goals of the methodology, focusing on the content and process elements of the Model-Driven Requirements discipline in the context of SOA-based systems development. Finally, Section 5 contains some conclusions and future work.

Related works

A variety of modeling techniques and methodological approaches for serviceoriented software development have been published in literature. Ramollari et al. [START_REF] Ramollari | A survey of service oriented development methodologies[END_REF] present a state-of-the-art survey on current service-oriented development approaches, among others, Service Oriented Unified Process (SOUP) [START_REF] Mittal | Service Oriented Unified Process (SOUP)[END_REF] and Service Oriented Modeling and Architecture (SOMA) [START_REF] Arsanjani | SOMA: a method for developing service-oriented solutions[END_REF]. However, none of these methodologies describes a complete methodological automated process that includes RE techniques.

There exist other approaches not included in the aforementioned survey, such as: MINERVA framework [START_REF] Delgado | A Model-driven and Serviceoriented framework for the business process improvement[END_REF], or SOA-MDK [START_REF] Barn | Soa-mdk: Towards a method development kit for service oriented system development[END_REF], which apply model-based paradigms to service-oriented development methodology. However, these ap-proaches do not include any automation while producing the services specification. SOA-MDK approach proposes the application of the Model-Driven Architecture (MDA) principles within the context of reference models. However, the nature of the model-driven base of this approach remains unclear.

Several generic methodologies are based on the MDD principles, since these have gained many enthusiasts over the last decade. However, to the best of our knowledge, a complete development process for MDD that incorporates the requirements techniques has not been defined [START_REF] Loniewski | A systematic review of the use of requirements engineering techniques in model-driven development[END_REF]. One such approach is OpenUP/MDD, which is a very simplified RUP version intended for small teams. It is consistent with the MDA, but focuses solely on the transformations from the PIM to the PSM level and does not cover transformations from requirements. In this context, our proposal for the RUP extension and the OpenUP/MDD approach are complementary.

Software Process Engineering

Different software development processes use different concepts and notations to define the contents of the methodology. The need to unify all these concepts and notations has therefore emerged leading to the introduction of the Software Process Engineering Metamodel (SPEM) [START_REF]OMG (Object Management Group): Software Process Engineering Metamodel (SPEM)[END_REF] standard by the OMG. SPEM provides a complete metamodel based on the Meta Object Facility (MOF) to formally express and maintain development method content and processes. The Unified Method Architecture (UMA) is an evolution of SPEM v1.1 and defines the schema and terminology used to represent methods consisting of method content and processes. IBM and OMG have worked on UMA to make it part of SPEM 2.0. The UMA engineering process is employed in this extension, defined by the use of IBM Rational Method Composer (RMC) [START_REF] Haumer | IBM Rational Method Composer: Part 1: key concepts (December 2005)[END_REF], which is a UMA-based comprehensive process authoring tool that provides extensive method authoring and publishing capabilities [START_REF] Shuja | IBM R Rational Unified Process R Reference and Certification Guide: Solution Designer[END_REF].

RUP Extension for the Model-Driven Requirements

In classic RUP, the Requirements discipline serves to establish the agreement with customers with regard to what the system should do, and define boundaries of the system. In our opinion, it should also provide a means for developers to better understand the requirements, it being like a bridge between the domain experts, stakeholders and the IT people.

Figure 1.A illustrates the RUP hump chart in which the Requirements discipline is replaced with a new Model-Driven Requirements (MDR) discipline. It also emphasizes the Environment discipline which serves as a means to adapt this process to SOA-based systems.

As shown in Figure 1.A, the new MDR discipline is a concern from the Inception phase to the Transition. Since the hump chart emphasizes the workload within disciplines, the diagram shows that the new discipline is particularly important during the Inception and Elaboration phase, in which the product vision is created and the architecture is established. Since we concentrate on model use in the MDD context, the workload in the Analysis & Design discipline in the Elaboration phase decreases depending on the degree of automation of activities from the MDR discipline. This approach was designed to support SOA-based system development. One of the main differences between RUP and the process proposed in our extension is the approach used to relate requirements and the system architecture. In RUP, the architecture is defined on the basis of previously created use cases and scenarios, chosen as the requirements that define strategic architectural elements. This RUP extension is architecture-oriented. It is the architectural pattern identified for the system, in this case to SOA, that becomes a basis for the MDD process definition.

Activities and workflow

A set of new activities is contributed and the discipline workflow has been replaced. Figure 1.B demonstrates the MDR discipline workflow. New or altered activities introduced with regard to the classic RUP Requirements discipline are marked with a star. Owing to space constraints, we shall comment only briefly on the newly introduced activities, with which the PIM-level model is defined and generated. Identify a Candidate Architecture. This activity is performed in the early Elaboration phase and is essential activity for the software development process in that it determine which artifacts need to be developed (type of model at the PIM-level that the architecture implies), and the MDD process to be followed. Define the Transformation Rules. This activity is the most essential in this approach. Within this activity, the elements of the source and target models are identified and well-documented. The transformation language is also chosen, and the transformation automation level and tool support are specified. Transformation rules are described in a specially prepared Transformation Rules Catalog. Generate the Analysis Model . This activity concludes the entire requirements modeling process by creating an architecture-oriented PIM. This is the result of all the previously performed activities, taking advantage of the artifacts created in the Business Modeling discipline. The output product of this activity is the input for further process analysis, design and implementation tasks.

Work Products

Owing to space constraints, we shall comment only briefly on the most important artifacts which have been introduced or improved in the new discipline. Software Architecture Document (SAD). This artifact, from the Analysis & Design discipline, is here initiated on the basis of the system architecture that has been settled on. It is an important artifact for architects and analysts during the entire development process. Transformation Rules Catalog (TRC). The transformation rules are specified on the basis of the source and target model elements identified. This artifact should consist of a precise description of rules, mappings and refinements, which also provides the basis for the requirements traceability. Transformation Iteration Plan (TIP). Requirements transformations are usually quite complex and are frequently based on defining intermediate models. A sequence of transformations rather than a single transformation is therefore necessary. This artifact is created to plan a logical order of the transformation to be performed. Generated Analysis Model (GAM). This is the most important work product in the discipline, it being a source for further transformations to generate PSMs. Its type of content depends on the architecture identified, while the model must suit the architectural pattern considered.

Roles

As the new discipline is based on the Requirements discipline, it maintains the roles originally defined by RUP. The only exception is that the Requirements Specifier has been replaced with two additional roles related to the model-driven context activities: Model Analyst and Transformation Specifier. Only the newly introduced roles are briefly described owing to space limitations. Model Analyst. During the MDR discipline, the Model Analyst coordinates a number of tasks related to: model transformations, model traceability and model validation. The main artifact for which this role is responsible is the GAM. This role also collaborates with the System Analyst to accomplish a number of tasks related to requirements modeling and traceability. Transformations Specifier . This role is responsible for specifying the details of transformation rules to transform requirements model into analysis model. It is a good practice to establish such rules in the meta-model level, which also simplifies the requirements traceability.

Conclusions

In this paper we have presented an extension of RUP by placing emphasis on the use of models as requirements representation in the context of MDD. This extension proposes a new discipline called Model-Driven Requirements that substitutes the Requirements discipline from the classic RUP. This approach through the application of architecture-oriented model-driven techniques attempts to extend RUP to specific project needs. It improves the standard development process defined by RUP in that it is not only model-based, but also This extension includes new content elements, such as: artifacts, roles, tasks, activities and capability patterns, to guide software engineers who attempt to follow an MDD approach in their software projects.

As further work, we plan to validate the approach by measuring the effort involved in the maintainability of requirements and the number of failures caused by errors in preparing the requirements specification in comparison to other similar sized projects carried out with the use of classical methodologies.

Fig. 1 .

 1 Fig. 1. A) RUP Extension disciplines, B) Model-Driven Requirements Workflow


Jelena Zdravkovic
email: jelenaz@dsv.su.se

Iyad Zikra

Tharaka Ilayperuma

An MDA Method for Service Modeling by Formalizing REA and Open-edi Business Frameworks with SBVR

Keywords: business model, business collaboration, service engineering, model-driven development, REA, Open-edi, OeBTO, MDA, SBVR

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

Introduction

Model Driven Architecture (MDA), as a formalization of Model Driven Development (MDD) approach, promotes a method for system development relying on the model transformation paradigm. MDA prescribes modeling of the business-level information as a Computational Independent Model (CIM), which is further transformed to a system-centric form called Platform Independent Model (PIM), and at the end to a Platform Specific Model (PSM) that adds the technology details needed for implementation on a specific software platform [START_REF] Kleppe | MDA Explained[END_REF].

In the service-oriented business sector, capturing the consumer needs for economic resources plays an essential role in the elicitation of the services that will deliver these values, therein seizing a desirable competitive distinction. In that context, business models offer considerable advantages compared to process models -they can capture a high-level description of a whole business in a single and easily-understandable view. Business ontologies, such as Resource-Event-Agent, REA [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF], facilitate modeling of actors involved in a business scenario and explain their relationships, formulating them in terms of economic values (i.e. resources) exchanged between the actors. Another important aspect concerns elicitation of explorative business service portfolios by spanning the whole business transaction lifecycle, which, according to the International Organization for Standardization (ISO) Open-edi initiative [START_REF]ISO/IEC: Operational aspects of Open-edi implementation[END_REF] involves planning, identification, negotiation, actualization, and post-actualization.

Recently, the ISO has focused on integrating REA and the Open-edi frameworks to create Open-edi Business Transaction Ontology (OeBTO), to specify the concepts and relationships involved in collaborative business environments. OeBTO captures the economic commitments realized by economic and business events performed by the partners, along the collaboration lifecycle in the Open-edi sense.

Following the previously outlined needs of service engineering, and MDA, in this study we consider the use of OeBTO to define a service-centric business model (i.e. CIM) and a method for its creation. To strengthen the formalism of OeBTO and thereby create an unambiguous and processable CIM, we consider the use of the OMG's Semantics of Business Vocabulary and Business Rules [START_REF]The Object Management Group (OMG): Semantic of Business Vocabulary and Business Rules (SBVR)[END_REF]. SBVR is an approach which allows specifying business in terms of a vocabulary and rules in a business-friendly language, while being formal enough to be readable by systems.

Being rooted in the use of MDA and two well-established business frameworks; REA and Open-edi formalized by SBVR, we believe that the method we propose for creating CIM forms a solid basis to be efficiently transformed to a SOA-aligned system model and further to Web services.

The rest of the paper is organized as follows. Section 2 gives the overviews on the used business frameworks, and SBVR. In Section 3 we present our method for identification and modeling of business services. In Section 4, we refer to the work related to ours, and conclude the paper.

Background

In this section, we briefly describe REA and Open-edi business frameworks and their integration in Open-edi Transaction Ontology (OeBTO); then we give an overview of the Semantics of Business Vocabulary and Business Rules (SBVR) standard.

Integration of REA and Open-edi Business Frameworks in OeBTO

The core concepts in the Resource-Event-Agent (REA) framework are resource, event, and agent [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF]. It is assumed that every business activity can be described as an event where two agents exchange economic values, i.e. resources. Economic resources may be classified as goods, rights or services. To acquire a resource, an agent (i.e. actor) has to give up some other resource (economic duality). In the study [START_REF] Geerts | An Ontological Analysis of the Primitives of the Extended-REA Enterprise Information Architecture[END_REF], the REA framework has been extended to capture additional granularity levels of business activities of enterprises. The resulting framework has integrated three vertical layers: Value Chain, Business Process and Business Event:

Open-edi Business Transaction Ontology (OeBTO) extends the REA ontology with the concepts aimed to facilitate the modeling of business collaborations defined in the ISO Open-edi initiative [START_REF]ISO/IEC: Business transaction scenarios -Accounting and economic ontology[END_REF]. According to Open-edi, business collaborations span five phases: planning, identification, negotiation, actualization and postactualization. In the planning phase, the customer and the provider are engaged in activities to identify the actions needed for selling or purchasing goods and services. The identification phase involves the activities needed to exchange information among providers and potential customers regarding selling or purchasing goods and services. During the negotiation phase, contract terms are proposed and completed. The actualization phase includes all the activities necessary for exchanging goods and services between involved actors as agreed during negotiations. The postactualization phase encompasses the activities and associated exchanges between involved actors after the major resources are provided.

SBVR

Recently, the Object Management Group (OMG) has adopted the Semantics of Business Vocabulary and Business Rules (SBVR) as a standard for capturing business vocabularies and rules [START_REF]The Object Management Group (OMG): Semantic of Business Vocabulary and Business Rules (SBVR)[END_REF]. The term "business" in SBVR is used in a general sense, referring not only to activities that imply an exchange of goods or services for money, but also to other types of activities where rules need to be defined and documented, such as education, health care, or law [START_REF] Linehan | SBVR Use Cases[END_REF]. The basic idea around which SBVR is developed is that business rules are built on top of facts, which in turn are built on top of terms that represent concepts. Furthermore, SBVR acknowledges the difference between meaning and the representation used to convey that meaning. Figure 1 above shows how SBVR realizes the business rules and also emphasizes the independence of meaning and its representation.

Creating Service-centric SBVR-based Business Model

In this study we utilize the MDA method to model services. In that effort, we consider REA and Open-edi (i.e. OeBTO) as an established conceptual basis for the business collaboration context. To obtain a service-centric CIM, we propose the following:

-A classification of the notion of Business Transaction in OeBTO to enable CIM to describe different value configurations. -An extension to the original OeBTO to capture service-related notions, such as structure, behavior or policies. -A (re)formulation of OeBTO using SBVR, to increase the formalism of CIM and thereby facilitate transformations to the PIM level.

Method for Creating a Three-layered Business Model

According to the REA framework, the method for describing the business of an enterprise comprises the decomposition of business activities along three granularity layers: value chain, business processes and business events (Figure 2). In the following, we will outline a method for creating each of the layers, where the concepts on each of the layers are defined using SBVR-based OeBTO. Step 1: Value Chain Specification In this step the business (i.e. value-adding) processes in the highest layer of the REA framework are identified, using a service-aware value configuration, such as the classification that includes traditional value chain, value shop, and value network [START_REF] Stabell | Configuring value for competitive advantage: on chains, shops, and networks[END_REF].

Step 2: Business Process Specification Moving to the middle layer of the REA framework, each identified business process (transaction, in OeBTO) is explored to find the partners involved in it, as well as the economic resources being exchanged. Each economic exchange gives rise to an aggregated service, which will be further expanded on the next layer of the framework, to discover the actual business services that will realize the delivery of the economic exchange.

Step 3: Business Event Specification

At the bottom layer of the REA framework, the economic events of the economic exchange are expanded over the five Open-edi business transaction phases. This is intended to discover the candidate business services and business events. According to OeBTO, the business event is used to represent the business activities elicited for every business transaction phase at the third layer. In order to capture the services that compose the aggregated service and at the same time aggregate related business events, we introduce the business service element. A business service is a standalone service that can be reused as part of other aggregated services to provide other economic exchanges. In Figure 3, a small excerpt of the formalization of OeBTO using SBVR is illustrated. For the full specification, the reader is referred to [START_REF] Zikra | SBVR-based Service-extended OeBTO Meta Model[END_REF] From the MDA perspective, the obtained service-aware OeBTO model is used as the input for creating a system model, i.e. Platform Independent Model (PIM). Since SBVR is completely grounded in formal logic, it gives the added benefit of automatic model processing, i.e.: -Making it possible for tools to ensure the integrity of OeBTO models.

-Ensuring the integrity of transformations that produce PIM models based on the OeBTO model.

Related Work and Conclusion

In this study, we have applied the MDA method to design business-services, which may be further transformed to system services and implemented using Web services. Lately, research in both academic and industrial communities have implied that when designing service-oriented software solutions, the starting point should be the business models of enterprises [START_REF] Baida | An Ontological Approach for Eliciting and Understanding Needs in e-Services[END_REF], [START_REF] Cherbakov | Impact of Service Orientation at the Business Level[END_REF], [START_REF] Anderssson | Aligning Goals and Services through Goal and Business Modeling[END_REF] and [START_REF] Gordijn | Requirements Engineering Techniques for e-Services[END_REF]. This fact, according to the referred studies, is shifting the focus of large scale e-service design to the context of economic resource transfers. Our method reported in [START_REF] Zdravkovic | A Model-driven Approach for Designing E-Services Using Business Ontological Frameworks[END_REF] differs from those studies in the way that we set the focus on the analysis of business transactions relying on the OeBTO standardization effort, and expanding them along a number of collaboration phases to get a rich business service portfolio. The aim of this study has been to further improve the use of OeBTO for service modeling in the MDA method, by formalizing it with SBVR, and to use SBVR to guide transformations toward PIM.

The major strength of the proposed method is the use of REA and Open-edi frameworks formalized with SBVR for modeling CIM; in that way we have obtained a method which facilitate creating a declarative-type CIM, unambiguous and processable, i.e. with the capability to be further transformed with a high extent of automation to system-centric service model (PIM).

Fig. 1 .

 1 Fig. 1. Meaning, representation, and the support of business rules in SBVR

Fig. 2 .

 2 Fig. 2. The three-layered REA business framework

Fig. 3 .

 3 Fig. 3. An excerpt of the formalization of OeBTO using SBVR.

Jelena Zdravkovic, Iyad Zikra, and Tharaka Ilayperuma

Jelena Zdravkovic, Iyad Zikra, and Tharaka Ilayperuma

Jelena Zdravkovic, Iyad Zikra, and Tharaka Ilayperuma


Sietse Overbeek

Marijn F W H A Janssen

Yao-Hua Tan
email: tan@tudelft.nl

J Overbeek

A Scenario-based Governance Method for Coordination of Service Life Cycles

Most of today's organizations are still far from profiting from the full potential of web service technology. Organizations invoke each other's web services, but do hardly synchronize the life cycles of individual web services with each other. When realizing an integrated service this might cause failures and requires a governance method for synchronizing the life cycles among organizations. In this paper, we emphasize that there is a need for such a method and the basis of the method is explained. This consists of the identification of possible life cycle related scenarios when trying to integrate services. The method also provides support to coordinate and track changes in service life cycles. Based on the different scenarios when attempting to integrate services that have different life cycles, coordination to communicate life cycle changes and having clear agreements about expectations are needed for successful service integration.

Introduction

Web service technology is becoming the solution to make the business services of single organizations and inter-organizational coalitions available online and to match the supply of services and the demand for services by clients (see e.g. [START_REF] Papazoglou | Business process development life cycle methodology[END_REF]). A web service can be defined as a software component identified by a URI, whose interfaces and bindings can be defined, described and discovered as XML artifacts [START_REF] Ferris | What are web services?[END_REF]. However, most of today's organizations are still far from profiting from the full potential of web service technology consisting of the computerization, integration and matching of services. In fact, it is common practice for most organizations to develop their web services by adding a thin SOAP / WSDL / UDDI layer on top of existing software applications or components [START_REF] Papazoglou | Business process development life cycle methodology[END_REF]. While simple services may be constructed this way, it is not sufficient for realizing and offering a dynamically created integrated web service that matches complex and varying client needs. The notion of a service-oriented life cycle methodology has been introduced to design, implement, monitor, and manage web services in such a way that organizations can benefit in full from the advantages of web services. Such methodologies also provide sufficient principles and guidelines to specify, construct, refine and customize highly flexible business processes taken from a set of internal and external web services [START_REF] Papazoglou | Service-oriented design and development methodology[END_REF]. This enables that the specification and execution of business processes is aligned with those business services that are transformed to web services. Examples of existing methodologies can be found in [START_REF] Bianchini | P2S: A methodology to enable inter-organizational process design through web services[END_REF][START_REF] Papazoglou | Service-oriented design and development methodology[END_REF]. In practice, organizations invoke each other's services and become dependent of those services. Despite these dependencies, organizations adopt or create their own methodologies which are often unrelated to those of other organizations. This increases the risk that the various life cycles are out of sync which might result in failures. This is a complicating factor when integrating web services and the accompanying business processes that need to be executed to supply the integrated service. In the context of supply chain logistics, for example, an integrated web service can be supplied to a client who wishes to declare veterinary cargo online and to track and trace that type of cargo. If the integrated web service is a new web service that is going to be offered by two different organizations then their life cycle methodologies should be applied synchronously. This will prevent, e.g., communication problems and delays in the joint development of the integrated service and the accompanying cross-organizational business process. Mismatches between life cycles can also occur if, for example, an integrated web service needs to contain both existing and new web services. A service that already exists is in a different phase of its life cycle than a newly created service. Moreover, organizations that collaborate regularly innovate their processes, methods and business models and in this way they are in need for substituting old services with new ones. In [START_REF] Van De Weerd | Incremental method evolution in global software product management: A retrospective case study[END_REF], the need for these innovations are also linked to those organizations that rapidly expand. Innovation causes organizations to phase out old services and add new services. This implies again that these services are in different phases of their life cycles. In this paper, we present a governance method for supporting the coordination of web service life cycles. The aim of the method is to ensure that the dependencies among web services from different organizations are managed during the complete life cycle. This scenario-based method provides a way of working for service providers in coordinating and keeping track of life cycle changes. Section 2 introduces four different scenarios that can occur when attempting to integrate web services that have different life cycles. Subsequently, the basis for the proposed governance method is presented in section 3. Finally, the conclusions of this paper are presented in section 4.

Scenarios for comparison of service life cycles

In order to understand how web services and their life cycles can be compared and to determine to what extent they match, we formalize four possible matching scenarios. A life cycle methodology is typically divided in various phases to depict in which position a web service is in its life cycle. The phase equation is used to determine which phases uniquely belong to which life cycle methodology: Phase : PS → LC. If a phase p ∈ PS is part of a life cycle methodology l ∈ LC, this can be expressed as Phase(p) = l. In this case, the set PS is the set of phases and LC is the set of service-oriented life cycle methodologies. The phase classification equation is used to determine in which phase of its life cycle a web service is classified: Classification : SC → PS. For example, if a service s ∈ SC is in phase p ∈ PS of its life cycle, this can be expressed as Classification(s) = p. In this case, the set SC is the set of services. When different life cycle methodologies are used, it may be impossible to compare two web services that have life cycles that are based on different methodologies. This is because different terms to describe a phase are used and web services can be classified in a certain phase based on different criteria. However, comparison may still be possible if some phases of each life cycle are semantically similar. For example, a 'planning' phase in one life cycle may have the same meaning as an 'initiation' phase in another life cycle. Semantic similarity between phases of life cycle methodologies is modeled as follows: Similarity : PS ×PS → [0, 1]. The lack of semantic similarity between two phases p 1 , p 2 ∈ PS can be expressed as Similarity(p 1 , p 2 ) = 0, while the opposite result is true for full semantic similarity between two different phases. Four scenarios are imaginable when matching life cycles: (1) Two different services are in the same phase of their life cycles and the life cycles are also applications of the same methodology. (2) Two different services are in different phases of their life cycles and the life cycles are again applications of the same methodology. (3) Two different services are in different, but semantically similar phases of their life cycles that are based on two different methodologies. (4) Two different services are in semantically distinct phases of life cycles that are based on two different methodologies. These scenarios can be described more formally by using the above equations:

∃ l∈LC ∃ p∈PS ∃ s1,s2∈SC [Phase(p) = l∧ Classification(s 1 ) = p ∧ Classification(s 2 ) = p] (1)
∃ l∈LC ∃ s1,s2∈SC [Phase(Classification(s 1 )) = l∧ Phase(Classification(s 2 )) = l ∧ Classification(s 1 ) ̸ = Classification(s 2 )] (2) ∃ l1,l2∈LC ∃ s1,s2∈SC [Phase(Classification(s 1 )) = l 1 ∧ Phase(Classification(s 2 )) = l 2 ∧ Classification(s 1 ) ̸ = Classification(s 2 ) ∧ Similarity(Classification(s 1 ), Classification(s 2 )) = 1] (3) ∃ l1,l2∈LC ∃ s1,s2∈SC [Phase(Classification(s 1 )) = l 1 ∧ Phase(Classification(s 2 )) = l 2 ∧ Classification(s 1 ) ̸ = Classification(s 2 ) ∧ Similarity(Classification(s 1 ), Classification(s 2 )) = 0] (4)
Under normal circumstances, it can be expected that in the first matching scenario the least difficulties exist to integrate web services and that these difficulties will gradually increase up until the fourth scenario. If this assumption is true, this would mean that there is a causal relation between the life cycles of web services and the ability to integrate and supply them as one integrated service.

Examples of causes for integration difficulties are: disabilities to comprehend service designs, conflicting service designs, temporal differences between activities performed in comparable phases and different service maintenance levels.

Scenario-based governance method for life cycle coordination

The proposed governance method is based on the underlying thought that changes in the life cycles of web services require proper coordination, just like the matching of supply and demand of services should be coordinated [START_REF] Burstein | A semantic web services architecture[END_REF]. This will also include the final agreements on these changes by the different owners of the web services. Changes in life cycles need to be announced and the time-line to make actual changes to the services need to be agreed on. A governance method that can be used by service providers as a way of working to keep track of desired changes and to coordinate them to ensure the proper functioning of an integrated service is then called for. The governance method consists of two parts, which concerns the activity diagrams shown in figures 1 and 2. The first diagram shows how to determine which of the four presented scenarios apply when attempting to realize an integrated service. To determine which scenario can be considered,

Compare LC methodologies [Init]
Compare phases of identical methodologies the life cycle methodologies of the services that would be part of a new integrated service are compared. If the methodologies are identical, the phases of the service life cycles can be compared. If those phases are also identical, scenario one can be considered. If not, the life cycles resemble scenario two. If the methodologies are not identical, it should be determined whether the life cycle phases are semantically similar or not. If this is the case, we arrive at scenario three. If it is not the case, we arrive at scenario four. The integration procedure can be started after determining with which scenario is dealt with and taking into account the possible issues that can arise related to that scenario. When the proper scenario is determined, service providers are more aware of which possible issues they may face during the integration process. life cycle of a service that is known to a service provider will be evaluated after its reception. More clarification concerning the change can be requested if this is needed. The clarify state represents a composite state, which is not shown further. The impacts of the change on other services are determined if there are dependencies between the service of which the life cycle has changed with other services. Next, the time-line of the change is determined. After determining this, the change can be either agreed or refused. The change is logged in a registry of life cycle changes if it is agreed upon. Both the scenario determination part and the part to coordinate life cycle changes can be used by service providers to control attempts to realize integrated services.

Conclusions

The results of the presented research show the basis of a governance method for the coordination of web service life cycles. The motivation to create such a method is rooted in the observation that organizations invoke each other's web services when realizing an integrated service for their clients, but that the life cycles of those services are hardly synchronized. The actual governance method consists of two parts for supporting the coordination of life cycles. One part shows how to determine with which life cycle scenario a service provider is confronted when integrating services. The second part provides a way of working for service providers in coordinating and keeping track of life cycle changes. By adopting the governance method, coordination to communicate changes and having clear agreements about expectations is then realized based on the different scenarios when attempting to integrate services that have different life cycles.

[

Fig. 1 .

 1 Fig. 1. Determining life cycle scenario when realizing an integrated service.

  The second diagram shows how to coordinate and keep track of changes in service life cycles. A change in a Wait for life cycle change

Fig. 2 .

 2 Fig. 2. Coordination and tracking of changes in service life cycles.


Marko Bajec
email: marko.bajec@fri.uni-lj.si

Application of Method Engineering Principles in Practice: Lessons Learned and Prospects for the Future

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

It seems that in IT sector we are all aware that for the development of non-trivial software the use of software methods is very important. They provides as with knowledge and guidance for the development process which otherwise might become too chaotic and out of control. It has been empirically proven that software development companies which have successfully established their software processes are more efficient, produce software of higher quality and have shorter time-to-market period; specifically if they are able to adapt their ways of working to specifics of a particular project.

In the research community Method Engineering (ME) principles have been promoted as a way to make software development methods agile and adaptable to particular circumstances, i.e. specifics of a development team and project. Unfortunately, however, ME have never been really accepted or widely used in practice. The reasons are several, not all are equally important.

At the University of Ljubljana we have done our own research to see what we can do to motivate software companies in employing ME principles. The research project was carried out under the umbrella of the Centre of excellence for "Information and Communication Technologies" with a mission to improve software development practice in Slovenian companies. The project was co-founded by the Slovenian Ministry of Higher Education, Science and Technology, European Commission and five participating Software Companies.

To reach the goal our idea was to facilitate the companies with a framework and tool-support for reengineering their ways of working, so that the gap between their official methods (documented methods they claim to follow) and the ways how they actually develop software would be as small as possible. As a part of this framework we have developed our own approach for process configuration (PCA) that suggests how to incorporate flexibility into formalised or documented methods, so that they could be adjusted to suite best to circumstances of a particular project. The PCA tells how to describe the ways of working in an organisation (organisation's base method) so that project-specific methods could be than created automatically by using appropriate tool-support.

It has been now three years after the participating companies incorporated the framework and supporting tools into their environments. In this talk I would like to provide the audience with more information on the research project that we have performed and share the lessons we have learned. Our findings lead us to not very enthusiastic conclusions and force us to look for different ways to tackle the problem.