Frédérick Bénaben
email: frederick.benaben@enstimac.fr

Jihed Touzi
email: jihed.touzi@enstimacfr

Vatcharaphun Rajsiri

Hervé Pingaud
email: herve.pingaud@enstimacfr

Collaborative Information System D esign

This article deals with enterprise interoperability in order to propose lines of research about information system design in a collaborative context. The static and dynamic dimensions of collaboration are exposed and discussed. The proposed IS design approach is based on process model translation. This article also presents several perspectives, especially about IS flexibility and process model liability.

Introduction

Nowadays, companies are opening up to their partners (using instituted, regular or sporadic relations) and it is an inescapable characteristic of the market evolu tion. This need of networking rests on several aspects: concurrency, exchange improvement (of information as for goods), products increasing complexity… The capacity of enterprises to collaborate with each other (furthermore in an efficient way) becomes, by this way, a determiningf actor for their evolution and their ability to survive. This necessary ability to evolve and react according to their environment is based on companies' capacityt o interact efficiently with the industrial ecosystem in which they live.

The notion of collaboration is a vast concept that can be applied to numerous situations: group based on the complementary nature of partners (covering increasing), groups concerning enterprisesf ocused on the same service (power increasing), groupings of providers from a same decision-maker (optimization and safety), common buying platforms (improvement of negotiation capacity) and other originalnetworks, permanent or limited (due to specific constraints of the milieu).

The question of enterprises collaboration and their abilityt o interact efficiently across collaborative networks or industrial ecosystems naturally concerns the f ield of information systems. Indeed, the behavior, reactivity and all the dynamic aspects of enterprise highly depend on the information system and the processes, services and data it manages. This article deals with t he topic of collaboration (definitions, levels…) and proposes several main ideas related to information system design in a collaborative context.

The section two deals with the concept of collaboration and how this notion impacts on information systems. The third part deals with collaborating informations ystem design according to the previous section remarks. Finally, part four presents several works in progress and future works related to these topics.

Collaboration and Information System

Collaboration is a large concept and it is necessary to position it according to numerous concepts, classifications and definitions. In this article we voluntarily chose not to discuss terms and words (in order to avoid a lexical debate on "collaboration", "cooperation", "communication" and so on) but to focus on conceptual collaboration levels. Next we aim to refinet his studyf rom the general concept of collaboration to the specific informationsystems collaboration.

Enterprise Collaboration

On the basis of some research work about enterprise collaboration, we will try to build a synthetic characterization of collaboration. Several levels of collaboration will be described according to twod imensions (static and dynamic), which will be used to structure this article.

First of all, [START_REF] Kosanke | ISO Standards for Interoperability: a Comparison[END_REF] builds a synthesis of the IEC TC 65/290/DC s tandard (cf. [I02]). This standard deals with enterprise compatibilitym easurement. We propose to extract from this article the following levels of compatibility (native denominations,g iven in brackets, have been converted in compatibility levels):

• Level 1 (Coexistent): may exist independentlyin a single network,

• Level 2 (Interconnectable): may share or exchange information,

• Level 3 (Interworkable): mayshare functionalities or services,

• Level 4 (Interoperable): maywork according to a predefined collective behavior. This classification scale is shown in the following schema (figure 1) :

Compatibility level Compatibility nature 1 2 3 4
Definition of a collaborative behavior X Sharing of functionalities and services X X Exchange or sharing of information X X X Involvement in a communicationnetwork X X X X

Figure 1: compatibility levels (adapted from [START_REF] Kosanke | ISO Standards for Interoperability: a Comparison[END_REF] and [I02])

This study highlights two consequences. The first one can be directly deduced: compatibility levels introduce collaboration levels. The second consequence is indirect and puts on view temporal aspects of collaboration: in order to collaborate, enterprises have to collectively build the path, which will bring them from heterogeneity to the right level of understanding. This is a dynamic act, which brings partners to instituted, regular or sporadic relations.

[LPT03] proposes a study on the levels of understanding between enterprises (based on the concept of "common objective"). That researchwork, based on different results from the supply chain management field, provides the following understanding levels (native denominations, given in brackets, have been converted in com patibility levels):

• Level 1 (communication): sporadic data exchange,

• Level 2 (coordination): structured and instituted data sharing,

• Level 3 (collaboration): sporadic data and applications exchange,

• Level 4 (cooperation): structured and instituted data and applications s haring.

Our point of view is to use the integration concepts of data and applications and to adda third concept: processes . Continuously with [START_REF] Lauras | Proposition de référentiel pour la notion d'entente industrielle : trois approches dans le domaine de la gestion des chaînes logistiques[END_REF], we propose to complete this classificationusing two complementary understanding levels based on integrationusing data, applications and processes (figure 2). Figure 2: relative positioning of understanding levels between industrial partners

The two levels added represent higher degrees of understanding, dealingw ith processes sharing or synchronizing (in a context of common objective). This proposal to enrich [START_REF] Lauras | Proposition de référentiel pour la notion d'entente industrielle : trois approches dans le domaine de la gestion des chaînes logistiques[END_REF] results is coherentw ith [START_REF] Konstantas | Preface de : Interoperability of Enterprise Software and Applications[END_REF] (as taking into account the "established collective behavior") and [START_REF] Doumeingts | European initiatives to develop interoperability of enterprise applications basic concepts, framework and roadmap[END_REF] (which claims that interoperability is achieved if it concerns the three levels data, resources and processes are concerned).

The fifth level can be illustrated using a group answering to a call for proposal and the collective achievement of this project. The sixth level can be illustrated by the gathering of partners,w hich synchronize and harmonize their behavior in order to build a coenterprise able to react as one according to some contexts (this stage is the last step before merging in to one single entity).

Such research works, among which the preceding study, allowu s to identify two considerations on which the structure of this article will be based: the collaboration level of a group of partners can be characterized by its two main components: static and dynamic views. Our proposal of characterization of collaboration levels can be illustrated using the following graphic (figure 3): This proposal of typology will be used throughout this article to study the design of appropriate information system in a collaborative contexte.

Enterprise collaboration and information system

To confront the previous considerations with the problematic of information system design in a collaborative context, we will study the abstract and conceptual views of information systems (IS).

• Reix, in [START_REF] Reix | Systèmes d'information et management des organisations[END_REF], defines the concept of information system as an organized set of resources (hardware, software, people, data, processes) able to acquire , treat, store and export information (as data, text, pictures, sounds, etc.) in the organizations.

• Bernus, in [START_REF] Bernus | Architectures of information systems[END_REF], considers that an information system must ensure that the right information is available at the right place at the right time. The notions of right place and right time refer to a process management system which synchronizes the treatment and the carrying of information inside the IS.

• Morley, in [START_REF] Morley | La modélisation des processus : typologie et proposition utilisant UML, Actes des journées ADELI : processus et systèmes d'information[END_REF], presents the IS as the composition of two subsystems:

o the information management system (including actors, data and processes), o the computing system (including hardware and software resources, data base and functions).

Those three points of view (Reix, Bernus and Morley) emphasize several invariants of the field of information system modeling. We can sum up these principles according to the following representation: The information system supports the enterprise's processes by firstly, managing services and functions available in the company and secondly, dealing with information (carrying and storing). Actors and resources of the enterprise, totallyi nvolved in the whole informations ystem, are located outside our illustration (figure 3) because of the nature of our main objective: IS design.

Figure 4: a vision of the information system That view of information system(and particularly of its computable part) offers the advantage of being coherent with the points exposed at paragraph 2.1 about collaboration levels and the static characterization criteria (data, applications and processes). Consequently, we will use that logical representation of IS to study the consequences of collaboration on IS of partners:

Data Applications

Resources Processes

Actors

Computational dimension of theIS

• Data conversion: to be flowing, interactions between information systems need tools able to convert data efficiently (style, format). It is crucial that data can be transmitted effectively between p artners of the collaboration. In oth er words, even if each partner should be able to preservei ts privacy and to establish the specific access rights to the informational field it allows, collaboration between enterprises implies to clearlyseparate the semantic meaning of data and their syntactic form for an optimal informational integration.

• Management of applications: generally, services and applications of diverse partners are not built to be compatible. Nev ertheless, IS collaboration implies the interaction between partners' applications to be as flowing as possible (even if they are provided by heterogeneous IS). It is crucial to be able to manage external accesses to those applications (and the associated rights). Technical solutionss uch as EAI (for Enterprise Application Integration) or ESB (for Enterprise Service Bus) provide concrete support to that kind of services and applications interoperability.

• Orchestration of processes: processes can be seen as the "musical partition" to be played and accompanied by the information system (and the workflowma nagement system) by piloting the data management and the calls of services or applications. In a collaborative context, the running of collective processes( impacting all partners) must be transparent but should impact the running of internal processes (in IS of partners). That is why, collaborative processesm ust include components coming from private processes of partners (cf. [START_REF] Chikova | Customer-Driven Process Management in Value-Added Networks Using an Architecture for Collaborative Business[END_REF]). Finally, these private processes should be protected against an external malicious reading but they should also offer a partial access: at least the definition of the applications they provide, data they need and information they send out… This is probably the price of a pertinent building of collaborative processes.

Besides, if collaboration between information systems maybe f ormalized by using those three concrete levels (data, applications and processes), there are alsos everal secondary components of that point of view: interactions between different levels (applications create, use, modify data; processesneed applications and transmit data, etc.).

As for the characterization of the dynamical dimension of the collaboration between information systems, the projection of the temporal criteria on the plane of the IS modeling leads us to the following remarks:

• Internal own-knowledge and conceptual compartmentalization: temporal discontinuity andf ractioning of collaboration imply that the potential partners master and know their own IS perfectly. Indeed, it is necessary to efficiently define formats of exchanged data, modes of access and use of applications. Public and private parts of each partner should also be defined. Finally, components of one IS (of one partner) may be prepared to be compartmentalized in order to deal with the possible involvement of an enterprise into several distinct collaboration networks, for different timing, at different moments (but eventually overlapping).

• Flexibility and safety of IS: because of the previously mentioned hypotheses of an enterprise belonging to several distinct networks (versatility of partnership), information systems have to be extremely flexibl e. Answering to new, unexpected and innovative collaborationr equests is a strong component of that view of the collaboration concept. Like wise, integrating andm anaging evolutions and changes of a running collaboration is a fundamental and substantial issue. After all, the variety of types of collabo ration (instituted, regular or sporadic) i mplies an increasing need of information systems to be safe and secure while adapted to this opening (this is the price to be a trustable partner).

• Robustness of processes: the third level of collaboration (cf. §2.1) is characterized by the establishing of a collaborative behavior. This principle rests on one (or several) collaborative process(es), defining the dynamical part of the collaboration and certifying that partners share the same vision of the collective behavior of the network. The collaborative process (or a model of this process) is a key-point of the collaboration. It must be trustable (without beingn ecessarily stable because of the flexibility constraints) and a point of reference for the partnership. Hence, it seems to be legitimate to think that the building of such a collaborative process should be complemented with activities of risk management and robustness improvement.

The aim is then to propose a solution including answers to these q uestions, definitions and requirements.

Proposal about Collaborative IS design

The purpose of this third section is, first to propose a logical structure able to carry the partnership between enterprises (and their IS) by meeting the main requirements identified among the study of the collaboration concept (part 2). Secondly, this section aims at showing a designm ethod of such a kind of collaborative structure (as a software system). This part essentiallytreats the static view of the collaboration (the d ynamic one will be discussed in the fourth section).

The concept of collaborative information system (CIS)

Dealing with data conversion between partners, application management in the network and processes orchestration according to theglobal behavior of the collaboration, reveal the necessity of:

• acceding to several components and characteristics of the IS of partners,

• having an independent andi ntermediate entity available (trustable third party), located in the middle of the network. This mediator should manage the specificities of each partner but also the structural and functional conventions specific to the collaboration. We call that entity, support of interoperability, Collaborative Information System (CIS): This CISis based on connectors, plugged into the partners' information systems and able to deal with the public and private parts. These connectors can access the public data applications, and processes of partners in order to provide the CIS the information needed (access rights and other specific features have to be managed at this level). Thanks to thesemodules (connectors), the CISmay be able to carry out the collaboration by driving and controlling collaborative processes, by managin g calls of applications from partners and by carrying and translating data from one partner to the other (when it is necessary and legitimate according to global processes). This concept of CIS relates to a logical architecture, technical point of view is not mentioned here and might differ from that conceptual view.

Concerning the public/private notions, visibility and access to processes, applications and data of partners' information systems come from enforcement of pre-established collective conventions (connectors and CIS control the conventional decisions taken by the community of partners involved in the network).A ccording to this point of view, internal processes can be private, public or semi-private (if only part of a process is visible, for instance inputs and outputs of a service), applications can be private, public or controlled (if the access is restricted) and data can be private or public. Based on the previous delimitation of the concept of CIS, seen as the cornerstone of collaboration, one can reasonably askf or the contents of such a system: which knowledge should be available to define this CIS? What concrete characteristics of the network and of partners should be assembled to be in a position to design this Collaborative Information System? Morley, in [START_REF] Morley | La modélisation des processus : typologie et proposition utilisant UML, Actes des journées ADELI : processus et systèmes d'information[END_REF] assumest hat if numerous authors focused on the crucial role of the concept of information in the IS field, nowadays standard reference approaches are oriented onto the concept of process. [START_REF] Dussart | Systèmes d'Information Inter-Organisationnels, rapport Bourgogne[END_REF] points out that an inter-organizational informations ystem has the specific function to support processes goingt hrough t he organization's boundaries. Furthermore, Vernadat in [Ve99] defines a process as a set of partially ranked steps, executed in order to achieve at least one objective . Thus, from simple information management systems, information systems become systems in charge of drivingi nformational activities (thanks particularly to workflowm anagement tools). According to these ideas, we can infer that definingand designing such a CIS can be based on modeling the specific inter-organizational processes involved in one collaboration, as precisely as possible.

Formalizing those collaborative processes (seen as knowledge supplier) appears to be the next important question. In addition, formalizing the CIS to support the collaboration is a central question too. Modeling processes is a classical topic (cf. [START_REF] Berthier | Enrichissement de la modélisation des processus métiers par le paradigme des systèmes multi-agents[END_REF]) and Touzi in [START_REF] Bénaben | Une approche de la conception d'un système d'information d'entreprise par la représentation des processus[END_REF] proposes to use BPMN language (Business Process Mod eling Notation from BPMI 1 ) to describe collaboration's specific processes. Furthermore, Touzi suggests using UML (Unified Modeling Language established by OMG 2 ) to model CIS:

Figure 6: main objective One can summarize the general principle of our approach as follows: we aim at building a UMLm odel (of the adequate collaborative informations ystem) by using theg lobal knowledge (about the concerned collaboration) contained into BPMN models.However, it is relevant and essential to wonder if such an equation is homogeneous:

• what surface of the knowledge space of the collaborative network does a BPMN diagram cover?

• what are the points of view covered by the UMLmodel of an IS? The CIMOSA method is dedicated to enterprise modeling. CIMOSA describes four points of view of enterprise (seen as system), which give elements t o answer thef irst question: functional view (scenarios and processes), informational view (information and data), organizational view (hierarchical structures and organizational charts) and resources view (competences and availabilities). As p rocesses models, BPMN diagrams are mainly centered on the functional view. Nevertheless, BPMN formalism is one of the languages designed in [START_REF] Saven | Business process modelling: Review and framework[END_REF] as able to completely describe a process but also to link it with other views of the enterprise: a BPMN diagram includes connections with information (by dealing with exchanges of messages) and with resources (by allowing parallelism and synchronization).

Concerning the second question, UML is a language dedicated to several complementary points of view (essentially of software systems and thus significant for IS modeling).

Considering [START_REF] Booch | UML 2.0 Guide de référence[END_REF] and [Ro04], we can propose to focus on four dimensions: the architectural dimension (structure of the physical components: component and deployment diagrams), the behavioral dimension (dynamic description: sequence, activity, collaboration and state-transition diagrams), the functional dimension (tree of the functions available in the system: use-case diagram) a nd the structural dimension (logical structure: class and object diagrams). In our context, the problematic of generating UMLm odel from BPMN diagramsm ay be illustrated by figure 7 (where arrows between points of view and dimensions mean "provide t he knowledge for"). It seems obviously difficult to be able to produce the model of an IS architecture (no matter if it is a logical one, based on structural view, or a physical one, based on architectural view) starting from process model without providing additional knowledge (kind of architecture, nature of components). Furthermore, if BPMN goes over the edge on informational, organizational and resources dimensions, it is not sufficient to cover the whole partnership and its attributes: it is necessary to complete that knowledge with informationfrommodel of partners and the collaboration itself. Previous observations showed the necessity of completing extracted information (fromBPMN processes models) with additional knowledge describing logical and technological structures of information systems. We propose the following approach in four steps:

Enterprise Model

BPMN Formalism

IS Model

Figure 8: design method of the collaborative information system

• Stage 1: the translator extract from BPMN diagram the knowledge describing the enterprises network considered.

• Stage 2: that knowledge is injected in the logical architecture specifically chosen for the CIS (depending on the translator culture).

• Stage 3: the obtained result is enriched with complementaryk nowledge from enterprise modeling field (specific model of partners and of the network itself). This step implies human intervention. [START_REF] Berthier | Enrichissement de la modélisation des processus métiers par le paradigme des systèmes multi-agents[END_REF] proposes to use the concept of agent for such an enrichment task.

• Stage 4: finally, the obtained logical model is projected on the chosen technological architecture in order to provide an exploitable UMLmodel.

These stages are here formally identified in order to clarify the method. In fact, there are not so obviously distinguished in real implementation. Steps 1, 2 and 3 are in fact one single global stage dedicated to logical modeling (for instance it might be an iterative cycle involving the three steps almost simultaneously). This approach (cf. [START_REF] Touzi | Interoperability through model based generation: the case of the collaborative IS, I-ESA[END_REF]) seems to be compliant with the MDA 3 practice. Indeed, according to [O03], the following connectionsmight be done:

• Platform Independent Model (PIM): that part covers stages 1, 2 and 3 from figure 7, that is to say the building of BPMN models of collaborative processes and the translation into UML diagrams modeling the CIS,

• Platform Model (PM): that element describes the generic technological architecture chosen for the CIS (for instance based on a UML profile)

• Platform Specific Model (PSM): that part refers to the results of stage 4.

Figure 9: approach MDA (ModelDriven Architecture) and CIS design

The CIS designm ethod proposed finallyi s coherentw ith results presented in [EI05], which underline the need of enterprises integration by means of conceptual models (logical point of view) then technical models (physical point of view) bothimplemented from business analysis (collaborative processes could be a good example of such an analysis).

3 Model Driven Architecture, available at http://www.omg.org/mda/.

Business trackTechnical track

Collaborative process (BPMN)

CIS logical model

CIS technical architecture

Stage 4

Stages 1, 2 and 3

PSM PIM PM

This sectionwill show some o f our current research works and their connections with the previous considerations. The third part refers abundantly to research works concerning IS design from the "frozen knowledge" encapsulated in collaborative processesm odels (that is to say the static part of the collaboration concept as shown in part 2). We now present some research work of PhD in progress. Such works will particularly be located on the dynamic dimension of the concept of collaboration (according to Figure 3 in the second section).

Collaborative processes cartography

We currently try to define a system of reference for collaborative processes. This ambition comes from several statementsm adew hile stu dying the topic of BPMN model translation into UMLmodel:

1. BPMN language is notyet universally used o r recognized, 2. The CIS designm ethod to propose (cf. section 3) needs a partial "automated translation" which implies incoming BPMN models to respect some conformity conventions: current results on translation rules (cf. [START_REF] Touzi | Interopérabilité et système d'information[END_REF]) show how crucial it is to use collaborative processes models following specific standards in order to manipulate and to translate easily.

3. The will of collaboratingt aken by a group of partner d oes not systematically imply the definition of the precise collective behavior of that partnership. Building processes models and furthermore collaborative processes models is a delicate and demanding activity.

Thanks to these observations, we believe that the building of collaborative processes models takes on a significant weight. It seems to be reasonable to build a formal phase of design of collaborative BPMN diagrams (in order to obtaint rustable and adequate models). The approach we propose will be based on twosteps:

• Building of a collaborative processes cartography: the field of those particular processes is not a well-defined universe. We propose to define several pertinent characterization criteria to locate collaboration and the associated processes in the space of collaborative behavior. The goal is to obtain a system of reference allowing the compartmentalization of collective processesa nd therefore the use of generic or dedicated models (to build specific processes diagrams).

• Proposal of a method to build collaborative process models. It will be based on the cartography built to assist the modeling phase of BPMN diagrams drawing. The models thus obtained will then be compliant with the requirements of the translator (as built according to a specific method whose purpose is to meet the specific conventions of the translator).

Starting from the results of [START_REF] Kumar | Sustainable Collaboration: Managing Conflict and Cooperation in Interorganizational Systems[END_REF], the first characterization criteria on which we will base the cartography of this unknownfield are the following:

• Nature of the collaboration: [START_REF] Kumar | Sustainable Collaboration: Managing Conflict and Cooperation in Interorganizational Systems[END_REF] proposes four groups of coll aboration types (seen as a base of constructs) which are the following: enterprise / client , enterprise / supplier, enterprise / service provider, enterprise / concurrent. These relations help to locate one particular collaboration case and the associated processes on a first axis.

• Nature of the network: [START_REF] Kumar | Sustainable Collaboration: Managing Conflict and Cooperation in Interorganizational Systems[END_REF] and [START_REF] Dussart | Systèmes d'Information Inter-Organisationnels, rapport Bourgogne[END_REF] propose different types of network from centralized network (where a principal collaborates with several partners more or less significant) to chaotic network (where each partner may have specific relationw ith one another, includ ing supply chain network or other well-known standard models.

• Dynamic aspect of the collaboration: This characteristic has been exposed in section 2. It concerns temporal aspects of collaboration. It helps to define if a network is based on sporadic , regular , cyclic or instituted relations.

This list of criteria underlines the first ideas on whichw e base our current activities on collaboration characterization. This studyw ill assist them odeling of collaborative processes as exploitable BPMN diagrams.

Robustness of processesand flexibility of information systems

The previously presented notion of processes cartography bring s two additional perspectives. The first oned eals with adaptability and flexibility of collaborative informations ystem. The second one is linked to riskm anagement in collaborative processes models.

First of all, being able to evolve in the field of collaborative processes give us some flexibility as far as our propositions in this article are concerned. Indeed, processes (and collaborative processes) may dynamicallyevolve and the collaboration may also change with time. CIS supporting the partnership should follow the change and this fact is a critical issue of these researchw orks. Thus, being able to instantaneously locate the collaboration (and the involved processes) in a system of reference is a significant asset for CIS evolution. One can imaginem odifying the collaborative processesm odels in an almost continuous way (and, at the same time, the CIS supporting these processes). Such considerations allowu s to thinkw ew ill be able to follow the dynamic change of collaboration.

Secondly, using generic models of collaborative processes (associated to specific places in the collaboration system of reference) b rings the possibility of categorizing activities.

Stamping activities canh elp identifying risks associated to one nature of activity and by this way to one complete process. Indeed, we can assume that one particular sort of activityw ill carry its specific sets of generic risks (usually linked to that kind of task). For instance, one activity of transport will systematically be concerned by the same kind of risks (differentf rom the ones associated to one activity stamped conception ). Such considerations should help the risk identification, their analysis a nd treatment.

We believe these observations should leads to further research works in thef ield of interoperabilitym anagementa nd especially in the fields of collaboration support in a robust and dynamic way.

Conclusion

This article is based on three parts. The first one explores the notion of collabo ration and assumes that it particularly implies information systems collaboration. This observation brings us to discuss the concept of collaboration itself and its two identified dimensions (static and dynamic). Information systems interoperability is also discussed by introducing the notion of collaborative information syste m (as a mediator between partners' IS), which is a vector of data transmission, application management and process orchestration.

The second part presents a proposal of CIS designm ethod. This suggestion rests on models translation: from collaborative processes BPMN diagrams to CIS UMLmodel. It includes several stages (such as knowledge extraction and logical architectu re filling). The partial model so obtained is a trustable and advanced base to be enriched with additional information on partners and the network itself.

The third part exposes the perspectives and lines of research appeared thanks to the first results. The topics mentioned in that section concern flexibility and adaptability of collaborative informations ystem (thanks to collaboration localization in a collaborative processes cartography) but also robustness of collaborative processes (through a risk management approach).

This article shows a view of the concept of enterprises' collaboration based on the characterization of the partnership,w hich, from our viewpoint, seems to us to be the most relevant one: modeling of collaborative processes of the network.

Figure 3 :

 3 Figure 3: collaboration characterization proposal

Figure 5 :

 5 Figure 5: our proposal on a logical plane for information systems collaboration

  Elements to define the Collaborative Information System

Figure 7 :

 7 Figure 7: covered areas and relationsbetween enterprise modeling and IS modeling One can notice that collaborative process model in BPMN allows the def inition of behavioral and functional views of IS model (arrows A and B). Besides, structural dimension (links C, E and F) and architectural view (link D) are just partially covered.

  Design method proposed (compliant with MDA practice)




  Interest from students for basic science  Intellectual curiosity, during high-school or even before  Notions part of the curricula: special relativity, radioactivity, quantum mechanics  Teachers looking for resources  Not always familiar with our fields of research  Physics and chemistry teachers -plus occasionally mathematics  Activities welcome to liven teaching up  To provide examples/illustration of physics concepts, based on current research  Recent stress on team projects to be carried out and presented by pupils  Analysis of documents, etc.  We need the next generation of scientists to be trained  And the general audience to understand better what we are doing -and why we are  Mutual interest  Teachers act « Multiplication factors » (© CERN Teachers Programme) Teachers  Students  Families  General audience  Classic actions  Conferences  Laboratory visits  Educational documents  Teacher training sessions  IPPOG's International Masterclasses  Educational cosmic muon detectors  Cosmodétecteurs  Cosmix case  See talk at ICHEP 2014  e-PERON  New!  Passeport pour les deux infinis  A book (2010) reprinted twice (2013 and 2016)  E-letter sent to 2,700+ teachers on a quartely basis  All under the common umbrella of the « physics of the two infinities » Massive Open Online Course  A more-modern media  A wider audience to target  Not just teachers but also their students  Plus science hobbyists  Possibility of repetition  French-speaking countries  Independent learning by the teachers  At their own pace  Free (and validated) teaching material  Classes  Students bibliographic projets Examples of existing MOOCs  A (limited) digest for a French-speaking audience  Similar resources likely exist in other languages  « From particles to stars »  Available on FUN (*)  Target audience: Master 1  « Gravity! From the Big-Bang to the black holes »  Gravity-centric  Available on FUN as well  For the general audience 6 (*) « France University Numerical resources ») Voyages de l'Infiniment Grand à l'Infiniment Petit  Each path of 10 modules is divided into four sets of two-three modules each  Guided progression  Each sub-path ends with a multi-choice quiz  For student self-evaluation  Example: the « infinitely small » path  Basics  On the road to the infinitely small  From the atomic nucleus to the quarks  E=mc 2 and its consequences  Fundamental constituents of matter  Fundamental interactions  The Standard Model  Looking for new particles  Studying elementary particles  Particle accelerators  Detecting particles  The LHC and beyond  The LHC  Future projects Voyages de l'Infiniment Grand à l'Infiniment Petit  A wide topic  Nuclear and particle physics  Astroparticle and cosmology  Not just an introduction of the basic theoretical concepts  Detectors, experiments, international collaborations, prospects for the coming years  Applications to society  Links between two research fields so widely apart on the length scale  From 10  m to 10  m  Four main paths  Infinitely small  Infinitely large  Links between the two  Applications  10 module-long each  7-10 minutes video  Static shot, a single speaker per module facing the camera  Animations, pictures, schematics, etc. on the side Voyages de l'Infiniment Grand à l'Infiniment Petit  An ambitious project  Initial decision: make it local to the Orsay-Saclay area (southwest of Paris)  Ease management and communication between contributors  New clusters: network of labs, « Paris-Saclay University »  Editorial board -four people, see cover slide  Two partners  Ecole Polytechnique: film set & video editing, diffusion  The Paris-Saclay network of labs P2IO: funding support  « Physics of the 2 Infinities and of the Origins »  Support from the institutions of all the scientists involved: CNRS, CEA, Universities  Technical team from Ecole Polytechnique  Eric Vantroeyen: e-learning officer  Latifa Berkous: engineer specialized in educational projects  Frédéric Picazo: video edition  Support from high-school teachers  To link the MOOC contents with the curricula  To use as much as possible the same vocabulary than the teachers and students  Expect support from the Ministry of National Education for the MOOC diffusion  Already using associations of physics teachers to advertise the MOOC  About 15 different speakers from various Orsay-Saclay labs  Two-three modules on close topics per speaker  Balance the load among many speakers  Speakers make their training profitable by recording more than one video  Gender balance  Physicists (both on the theory and experimental sides), engineers  Audio in French  Automatically-generated subtitles  Then vetted by hand Voyages de l'Infiniment Grand à l'Infiniment Petit  MOOC plateform: Coursera  Paths available independently, as they get completed  Order of initial diffusion not necessarily optimal  Driven by organisational constraints: speaker availabilities, etc.  Infinitely small: online mid-February (2018)  More than 700 students  Applications: online mid-May  More than 200 students  Links: proofreading ongoing, online around the start of the next school year  Infinitely large: the last of the four paths, released shortly after the third one  All videos shot, editing work in progress  The four paths will be replayed regularly on Coursera  In addition, they will all be available on a CNRS website  Currently under construction  With additional educational resources  Transverse paths focusing on given topics  Example: Nuclear power, from the nucleus to the applications: medecine and energy New MOOC about the physics of two infinites  Target audience: high-school teachers and students  Complement a wide set of educational and outreach resources already available  In French  Half of the MOOC (2/4 paths) already online  The other half online by next Fall  Long-term plans for diffusion  Standard MOOC + pool of educational resources  Four main paths + topical transverse paths  Strong interest in broadening the diffusion to other French-speaking countries  Feel free to e-mail us!  See cover slide