Rodrigue Aimé

Djeumen Djatcha Directed

Eric Badouel

Professor, Samuel Bowong

President Leandre Nneme Nneme

Associate Professor, Alessandra Agostini

Associate Professor, Georges E Kouamou

Associate Professor, Jean Gaston Tamba

A formal approach for role-based modeling of business collaboration processes by

Keywords: Business Collaboration, Role-Based Design, Service Oriented Design, Software Reuse, Interface of Role, Guarded Attribute Grammar

Business collaboration defined as working together to achieve a common goal, is suitably specified in terms of where collaboration takes place (context), those who are involved (contributors), what they do both individually (skills) and collectively (production processes), and finally, what is the expected purpose of this collaboration (business goal). We assume a clear separation between skills and effective contribution to collaboration (i.e role). Technically, a context can the be defined by the set of roles involved, offering a formal basis for reasoning. Considering business collaborative processes, involved contributor's behaviors set is similar to a software components, possibly abstracted as role i.e services or group of services provided with their production rules. A collaborative context is then viewed as a user-centered service oriented architecture where every stakeholder could be assigned one or more roles. We address the problem of a formal design approach for such business collaboration processes in that context, facing components reuse and process management challenges as unambiguously describing business roles, role composition and dynamic collaborative process management.

RÉSUMÉ

La collaboration métier, définie comme le fait de travailler ensemble pour atteindre un objectif commun, se spécifie convenablement en termes du lieu de la collaboration (contexte), de ceux qui y sont impliqués (contributeurs), ce qu'ils font à la fois individuellement (compétences) et collectivement (processus de production ) enfin, le but attendu de cette collaboration (objectif métier). On suppose une franche séparation entre la compétence et la contribution effective dans la collaboration. Techniquement, un contexte peut se décrire par l'ensemble des rôles en présence, offrant ainsi une base de raisonnement formelle. Considérant un processus de collaboration métier, l'ensemble des comportements de contributeurs, est similaire à un composant logiciel, pouvant s'abstraire comme un rôle i.e. des services ou des groupes de services fournis ainsi que les règles de production associées.

Un contexte de collaboration s'apparente alors à une architecture orientée service centrée utilisateur où chaque contributeur pourrait se voir attribuer un ou plusieurs rôles. Nous abordons la problématique d'une approche formelle de conception, pour les processus de collaboration métier dans un tel contexte confrontés aux même défis que ceux de la réutilisation et le management de processus de composants, à savoir la description non ambiguë de rôles métiers, la composition de rôles et la gestion dynamique de processus.

Mots clés: Collaboration métier, Conception Rôle-Centrée, Conception Orientée Service, Réutilisation, Interface de rôle, Grammaire Attribuée Gardée.

ACKNOWLEDGMENTS

I would like with these words to express my deep gratitude and appreciation to Professor Eric Badouel, for his patience and his availability. A thanks also to Professor Claude Tangha of late memory for his advice; Finally, thanks to Professor Samuel Bowong and Doctor Auguste Noumsi for accepting the new co-direction of this work. Let all those who are not mentioned by name here, in particular brothers, friends and acquaintances, know that in some way they have supported me in the context of this work and receive all my gratitude.

CONTENTS

Abstract i

Résumé ii

LIST OF FIGURES

INTRODUCTION Context

The dazzling development of ICTs in recent years has considerably contributed on the one hand, to develop and even create new types of behavior and, on the other hand, has broken down barriers geographically , economically, culturally, technologically, etc. Thus contributing not only to bringing together individuals, institutions and organizations in their daily functioning; but also to qualitatively improve their respective managerial approaches. Among the behaviors whose evolution is closely linked to ICT's evolution, we have business collaboration or simply collaboration.

Etymologically, collaboration is defined as working together to achieve a common goal. Intuitively, it follows from this definition, that collaboration is suitably described in terms of (1) those who are involved (contributors) i.e. who they are and how to integrate them into the collaboration; [START_REF] Gary | Which kind of collaboration is right for you?[END_REF] what they do both individually (skills) and collectively (production processes); (3) where collaboration takes place (context) and finally, (4) what is the expected purpose of this collaboration (business goal). In addition, depending on the purpose sought in the collaboration, there are two subcategories of collaborations [START_REF] Burger-Helmchen | Crowdsourcing: Définition, enjeux, typologie[END_REF][START_REF] Gary | Which kind of collaboration is right for you?[END_REF]3]: collaboration for service delivery, in which functional rules are structured processes clearly defined a priori; and collaboration for co-creation, innovation and knowledge sharing, where the functional rules are unstructured processes defined as the collaboration is deployed.

Designing collaboration is a very complex exercise. The complexity here, is in-herent to the heterogeneity of the four intrinsic elements of a collaboration, taken separately and collectively. Indeed, the context of a collaboration is strongly influenced among other things by contributors diversity, in terms of their individual skills; but also by the evolving nature of business goals, which in turn greatly influences production processes involved. In such a fairly dynamic context, two major almost recurring needs emerge; namely effectively taking into account the recurrent reorganization of work within collaborative structures on the one hand, and the possibility of incrementally integrating particularly heterogeneous sectors of activity in the collaboration, on the other hand. So a business collaboration design tool, must own dynamism, scalability and flexibility properties among others.

Motivations and Objectives

contributor's behaviors in a business collaborative process, are similar to software components, possibly abstracted roles i.e. services or group of services with associated production rules. A collaborative context is then similar to a user-centered service oriented architecture where every contributor could be assigned one or more roles. In this role-based design approach a role can be encapsulated by a module whose interface specifies provided services exported by the module and imported external services required. Usually, modules in service oriented design are hierarchically organized; rather the modules in role-based design approach often depend on one another (although cyclic dependencies between services should be avoided). In addition, the activated services can work as routines and a service call can activate new services in a way that may depend on user's choice on how the service is to be provided. Designing collaboration in the context above faces similar challenges as those of components reuse [4] and dynamic process management. A design activity, then requires the ability to discover services unambiguous choice a given service among potential services. Hence the motivation to have a precise description of tasks involved, a notion of a richer role interface and lastly means to dynamically manage and monitor collaboration evolution.

Contributions

Collaboration spectrum been wide and diverse choice has been made to focus on collaborative processes for service delivery. Thereby, our contribution has the form of three main extensions to GAG concept. Firstly the definition of a flexible tasking model. Secondly, the definition of composition and reuse mechanisms for role interfaces, inferred from tasking models specifications in GAG formalism. Thirdly, the introduction of a role-based design approach and its mechanisms, suitable to business collaboration design. More specifically, our contribution can be summed up with the three salient points below:

• A definition of a tasking model, for service delivery business collaboration:

A business process model formally defining tasks, services, crowd tasks, and contributor's intrinsic skills involved and their orchestration as business skills needed to complete a collaborative job.

• A definition of an interface of role theory for collaboration: Here business skills are encapsulated component behaviors, described by interfaces, termed interface of role. In a contract-based service-oriented and user-centric context we design components interfaces and provides three main operations: interfaces composition specifying how components behaves to the environment, an implementation order for been able to state when a component satisfies an interface, finally a residual operation checking systems needed for realizing a global specification, when composed with a given component.

• A definition of a role-based design approach for collaboration: In this approach a clear separation is made between contributor's intrinsic skills and his explicit contribution (role) in a given collaboration. A role is then viewed as a particular concern of a domain. In a dynamic context roles involved offers a formal abstract basis for reasoning; but traditional role-based systems lack flexibility, because only role static description mechanisms are available. We introduce improvements by providing various mechanisms for business skills dynamic choreography, role switching, workflow monitoring and checking.

Publications

(1) A Stable and Consistent Document Model Suitable for Asynchronous Cooperative Edition [START_REF] Tchoupé Tchendji | Un modèle de documents stable par projections pour l'édition coopérative asynchrone[END_REF][START_REF] Tchendji | A stable and consistent document model suitable for asynchronous cooperative edition[END_REF]: Complex structured documents can be intentionally represented as a tree structure decorated with attributes. Ignoring attributes in the context of a cooperative edition (these are related to semantic aspects that can be treated separately from purely structural aspects on interest here). The purpose of this work is to present grammatical structures, which are grammars permitting not only to specify a (global) model for documents published in a cooperative manner, but also to derive automatically via a so call projection operation, consistent (local) models for each co-authors involved in the cooperative edition. Some properties that meet these grammatical structures are also shown.

(2) Modular Design of Domain-Specific Languages using Splittings of Catamorphisms [START_REF] Badouel | Modular Design of Domain-Specific Languages using Splittings of Catamorphisms[END_REF]: Language oriented programming is an approach to software composition based on domain specific languages (DSL) dedicated to specific aspects of an application domain. In order to combine such languages we embed them into a host language (namely Haskell, a strongly typed higher-order lazy functional language). A DSL is then given by an algebraic type, whose operators are the constructors of abstract syntax trees to which one can associate a polynomial functor. Algebras (respectively co-algebras) express how to evaluate/interpret/execute programs (resp. generate/construct programs) where programs are viewed as abstract syntax trees. Using Bekîc theorem we define a modular decomposition of algebras that leads to a class of parametric abstract context-free grammars, associated with regular functors, allowing for the modular design of domain-specific embedded languages.

(3) A Calculus of Interfaces for Distributed Collaborative Systems: The Guarded Attribute Grammar Approach [START_REF] Badouel | Interfaces of Roles in Distributed Collaborative Systems[END_REF][START_REF] Badouel | A Calculus of Interfaces for Distributed Collaborative Systems: The Guarded Attribute Grammar Approach[END_REF] We address the problem of component reuse in the context of service-oriented programming and more specifically for the design of user-centric distributed collaborative systems modeled by Guarded Attribute Grammars. Following the contract-based specification of components we develop an approach to an interface theory for the components of a collaborative system in three stages: we define a composition of interfaces that specifies how the component behaves with respect to its environment, we introduce an implementation order on interfaces and finally a residual operation on interfaces characterizing the systems that, when composed with a given component, can complement it in order to realize a global specification.

(4) A role-based collaborative process design on crowdsourcing systems [START_REF] Aimé | A role-based collaborative process design on crowdsourcing systems[END_REF]: Crowdsourcing is a collaborative business process model, in which tasks are carried out by a crowd. In crowdsourcing systems, there are two types of stakeholders namely, requesters who outsources tasks and the crowd, or contributors, performing those tasks. We consider a stakeholder as an actor, or a standalone software component, evolving on a platform and having both mechanisms of interaction with its environment and business skills. A set of stakeholders interacting in a dynamic context for solving a problem is a distributed collaborative system and we term it crowdsourcing system. In such a system the role concept is central, because each stakeholder must have a specific framework within which he collaborate.

Document organization

The remainder of this document, is organized as follow:

• Chapter 1: devoted to the presentation of fundamental theoretical concepts necessary and useful in this work, as role and contributor concepts, business process modeling (BPM), system design approaches and principles, guarded attributes grammars (GAG).

• Chapter 2: presents principles, classifications, and mechanisms of business collaboration. A general tasking model for service delivery collaboration, described in GAG formalism, is also provided.

• Chapter 3: presents an extension made to GAGs, by defining the role interface notion and associated mechanisms, useful for components composition.

• Chapter 4: introduces a role-based approach, the design of service delivery business collaboration processes.

• Conclusion: to this work, with future perspectives and challenges.

• Appendix A: provides implementations of main concepts presented in this work, in the purely functional programming language Haskell1 .

• Appendix B: lists all publications made in the context of this work.

CHAPTER 1

RELATED WORKS AND USEFUL

BACKGROUND THEORIES 1.1 Introduction

This chapter introduces some founding basic key concepts, useful for various ideas developed in the next part. Specifically, we will introduce concepts of role and contributors of a dynamic system, as the desired approach in this work is role oriented.

Then business process modeling will be presented with an emphasis on it definition, taxonomy, characterization and its usual mechanisms, since business processes design in a dynamic environment is also a major concern. Next, focus will be made on system design principles. Finally, we introduce guarded attribute grammar, the formal tool capturing characteristic principles of a user-centric collaboration.

Roles, contributors and mechanisms

The role approach

The concept of role is crucial in any collaborative or cooperative work system. Importance here is related to the fact that, each stakeholder or contributor in this type of system, must have a clear framework within which he collaborates with others. In this context, the role specifies both what the system expects from the contributor, but also what the contributor expects from the system; preventing a contributor from being overwhelmed by information (or tasks) that is not necessary. In practice, the role-based approach is variously used, such as in UML design (use case diagram, class diagram, etc.), access controls modeling [START_REF] Ferraiolo | Role-based access control[END_REF][START_REF] Sandhu | Role-based access control models[END_REF], and collaborative or cooperative systems modeling such as a company, multi-agent systems [START_REF] Xu | Developing role-based open multiagent software systems[END_REF][START_REF] Kazik | Role-based approaches to development of multi-agent systems: A survey[END_REF],

business processes [START_REF] Caetano | Business process decompositionan approach based on the principle of separation of concerns[END_REF], social media, etc.

Common definitions and terminologies

Role and role type A role type is the perception that one contributor has of another contributor [START_REF] Riehle | Role model based framework design and integration[END_REF]. A role type is specified uniquely and a contributor plays at a given time a role specified by a role type. A role is therefore defined as one of the instances of a given role type, played by a contributor. This separation between contributors (i.e. the one that intervenes in the system), and a role (i.e. what an actor does in the system), brings dynamism to the system described as a dynamic role [START_REF] Edwards | Policies and roles in collaborative applications[END_REF].

Foundation and semantic rigidity

Depending on the case, it may not always be easy to differentiate between a role and a contributor. For instance, consider the use case below :

Use case 0. According to laws in Cameroon, civil-status certificates are issued by a civil status officer (csOfficer). Depending on the context, a user could apply to a Mayor, if he is locally based in the country; or rather to the embassy if he is abroad.

Mayor and csOfficer entities, are part of the business collaboration within an organization. Being able to distinguish between these entities, which is role type (or simply role) and which is contributor, can be rather complex. The sharp distinction between a contributor and a role type is based on both concepts of foundation and semantic rigidity [START_REF] Guarino | Concepts, attributes and arbitrary relations: Some linguistic and ontological criteria for structuring knowledge bases[END_REF].

Definition 1.2.1 (Foundation & Rigidity

). An entity is considered to be founded, if its specification implies a dependency or relationship with another entity. While an entity is semantically rigid, if its identity depends on certain characteristics, and can not exist without them.

Thus, it will be said that Mayor is unfounded and semantically rigid (and therefore Mayor is a contributor), whereas csOfficer is founded and semantically non-rigid (csOfficer is a role). In other words, a Mayor plays the csOfficer role. Hence a contributor is unfounded and semantically rigid, while a role is founded and semantically non-rigid. From the above we consider in this work that concepts of role type and role are equivalent, and will simply be called role.

Constraints on roles

Considering a contributor and his potential roles, constraints can be defined over those roles, as predicates which if necessary, return the value "acceptable" or "not acceptable", applicable to the play relationship between contributor's roles. Let r 0 and r 1 be two roles, four constraints can be defined over those roles [START_REF] Riehle | Role model based framework design and integration[END_REF][START_REF] Bögel | A role model-based approach for modelling collaborative processes[END_REF]:

1. Dcr (Don't care) for no constraints on contributors playing each of the roles.

2. Impl(r 0 , r 1 ) (Prerequisite or Implied) a contributor playing a role r 0 should always be able to play a role r 1 (the reverse is not always necessary).

3. Eqv(r 0 , r 1 ) (Equivalence) the implied constraint is checked for both the pair (r 0 , r 1 ) and the pair (r 1 , r 0 ).

4.

P hb(r 0 , r 1 ) (Prohibited or mutual exclusion) a contributor playing a role r 0 never plays a role r 1 and vice versa.

Business processes Modeling

Processes and workflows

A process is a set of repeatable activities, that need to be carried out by contributors in order to accomplish some sort of organizational goal. Depending on the context a process can be structured or unstructured [START_REF] Szelagowski | Static and dynamic processes[END_REF]. Structured processes (or static processes) are those processes unchangeable in form, as well as those which change over a long period of time. Their structure is known beforehand and are completely automatized. Conversely, unstructured processes (or dynamic processes) are processes the course of which is dependent on individual condition of execution or which contain such a large amount of variables that it is impossible to model them. They requires to factor in at design the possibility of process contributors making individual decisions that are not able to foresee before hand and integrating contributor's knowledge in design and improvement of processes.

A workflow [START_REF] Van Der Aalst | Workflow patterns[END_REF] is a series of repeatable activities needed to be carried out to perform a task. A workflow is developed in support to a process and describes how to get a process accomplished. A workflow is equivalent to a process if, and only if, the task carried out by that workflow is an organizational goal. A workflow gather several elements as [START_REF] Becker | Guidelines of Business Process Modeling[END_REF][START_REF] Kim | Dynamic business process management based on process change patterns[END_REF][START_REF] Toma | A systematic literature review on dynamic business processes[END_REF]:

(1) conditions: which decides when a given action should be performed;

(2) activities: which determines the functionality of the workflow. Each activity performs a different task, can succeed or fail;

(3) activity content: being the different information units as data, object, documents, artifacts, etc. Content help articulating workflow progression;

(4) sequence activity: that is, part of multiple activities of a workflow, useful for organizing several successive activities into one major step, and implemented as a function;

(5) decision nodes: which enables a workflow to make a selection on the execution path to follow, it behavior can be seen as a switch-case statement.

Business processes

A business process is a set of organized activities or tasks potentially performed in an environment or organization. Those activity jointly realize a business goal as delivering values for internal or external contributors. Each business process is enacted by a single contributor but it may interact with other business processes performed by other contributors [START_REF] Wil | Business process management: A comprehensive survey[END_REF][START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF][START_REF] Kirchmer | Business Process Management: What Is It and Why Do You Need It?[END_REF]. A business process is modeled by explicitly defining it's two components, in particular a related workflow describing the targeted process and associated contributors with respect to understandability and maintainability properties [START_REF] Weber | Collaborative business process modeling[END_REF].

Dynamism in Business Process

The dynamism of a business process is the ability to react to changing conditions (internal or external) of operation, according to needs, in a appropriate timely manner, at process instance runtime without having a negative impact on the process existence or its expected completion [START_REF] Kim | Dynamic business process management based on process change patterns[END_REF][START_REF] Vasilecas | Rule-and context-based dynamic business process modelling and simulation[END_REF]. A dynamic business process can then be defined as a business process whose related workflows components and contributors may vary and, if necessary, change with low latency at runtime due to changes of the context [START_REF] Toma | A systematic literature review on dynamic business processes[END_REF].

Technically there are two ways perception of process dynamism [START_REF] Vasilecas | Rule-and context-based dynamic business process modelling and simulation[END_REF]. On one hand, horizontal perception or implementation perspective where the process is viewed at different stage of it life cycle (execution, simulation, automation). On the other hand, vertical perception or layered dynamism as the ability of a business process to adapt to changes in the environment. From the last perception, there are three dynamism implementation levels:

(1) Using decision points: human or automated systems decides what to do next, according to predefined rules (a user-centric approach).

(2) Automatic configuration of business process: construct a process from a number of reusable fragments, depending on conditions change.

(3) Goal-driven business process: constructing a business process from a number of possible and reusable tasks at runtime. Separation of concerns (SoC) [START_REF] Edsger | On the Role of Scientific Thought[END_REF] is an abstract concept of system decomposition, difficult to define. The difficulty here is mainly due to the complexity of the targeted system, but also due to the exact definition of what is a concern in that system.

System design principles

Craftsman [START_REF]The art of separation of concerns[END_REF] defines separation of concerns as a delineation and correlation of system elements, in order to establish a well organized system where each part fulfills a meaningful and intuitive role while maximizing its ability to adapt to change. It follows from this definition that a concern as part of the target system, is a set of clearly defined responsibilities making it possible to achieve a single purpose; but in practice, not all concerns are easily separable and they are termed crosscutting concerns. SoC is an important design principle in many areas such as urban planing, architecture and information design. Well achieved, it promotes a better understanding, design and management of complex interdependent systems, so that parts can be reused, optimized independently of other parts, and insulated from the potential failure of other parts. [START_REF] Martin | OCP: The Open-Closed Principle(Object Mentor SOLID Design Papers)[END_REF][START_REF] Martin | LSP: The Liskov Substitution Principle(Object Mentor SOLID Design Papers)[END_REF][START_REF] Martin | DIP: The Dependency Inversion Principle(Object Mentor SOLID Design Papers)[END_REF][START_REF] Martin | Design Principles and Design Patterns(Object Mentor SOLID Design Papers)[END_REF][START_REF] Martin | Clean Architecture: A Craftsman's Guide to Software Structure and Design[END_REF] as:

(1) Single responsibility (Cohesion and Coupling) [START_REF] Martin | SRP: The Single Responsibility Principle(Object Mentor SOLID Design Papers)[END_REF] (2) Interface segregation (Scalability) [START_REF] Martin | ISP: The Interface Segregation Principle(Object Mentor SOLID Design Papers)[END_REF]: Systems evolve by dynamically redefining interfaces involved. For that purpose, interface segregation principle, recommends the implementation of several specific interfaces, instead of one general purpose interface. However, if such an approach considerably reduces the frequency of necessary changes to the system, it could cause side effects if, while designing interfaces, not only useful methods are expressed each time.

A concern gathers several properties [START_REF] Aksit | The six concerns for separation of concerns[END_REF] as: canonicity, composability, reusability, adequation and closure, wich in turn guarantee maintainability, robustness, adaptability and evolutivity properties to the system.

Soc design approaches

Systems must usually satisfy multiple properties, perform multiple functions simultaneously, and satisfy multiple purposes [START_REF] Jackson | Separating concerns in requirements analysis: An example[END_REF]. With that high level complexity, the main difficulty in designing those systems, is achieving separation of concerns; Various separation techniques exists [START_REF] Atkinson | Separation of concerns through stratified architectures[END_REF][START_REF] Aldrich | Challenge problems for separation of concerns[END_REF][START_REF]The art of separation of concerns[END_REF]: (i) horizontal separation or layered separation, i.e grouping processing concerns based on their role within application.

The process is to divide an application into logical layers of functionality that fulfill the same role within the system. This is an organization of concerns which minimizes the level of dependencies with application. (ii) Vertical separation i.e dividing an application into modules of functionalities that relate to the same feature or subsystem within an application. This clarifies the responsibility and dependencies of each features. Boundaries may be defined logically to aid in organization, or physically to enable independent development and maintenance. (iii) Aspect separation i.e. segregating an application's cross-cutting concerns [START_REF] Bergmans | Composing crosscutting concerns using composition filters[END_REF] or aspects, from its core concerns. This approach is known as aspect-oriented programming [START_REF] Kiczales | Aspect-oriented programming[END_REF]. Components publish services availability in a repository and make service calls in a peer-to-peer manner [START_REF] Sillitti | Service oriented programming: A new paradigm of software reuse[END_REF][START_REF] Malek | The NOMADS republic -a case for ambient service oriented computing[END_REF][START_REF] Dijkman | Service-oriented design: a multi-viewpoint approach[END_REF][START_REF] Parigot | Architecture orientée services dynamique: Dsoa[END_REF]. This could be abstracted as an integrated business application where services represent steps of a business process and one the main application is the composite business application, also viewed as a distributed computing environment. Properties gained from this approach are: (i) ability to use or combine services in ways not conceived by their originators (conjonctivity), (ii) ability to deploy or reuse a component in any compatible environment (portability, deployability), (iii) possibly redundant networked resources (availability, failure handling), (iv) ability of components from different sources to use each others services (interoperability) [START_REF] Bieber | Isd Ci. Introduction to service-oriented programming[END_REF].

SOD architecture

Service Oriented Architecture (SOA) is a distributed computing environment, organized around five main elements [START_REF] Brewer | A network architecture for heterogeneous mobile computing[END_REF][START_REF] Bieber | Isd Ci. Introduction to service-oriented programming[END_REF][START_REF] Erl | Service-Oriented Architecture: Concepts, Technology, and Design[END_REF][START_REF] Erl | Cloud Computing: Concepts, Technology & Architecture[END_REF]:

(1) Context: i.e. an environment for deploying plug and play components, prescribing details of installation, security, discovery and lookup;

(2) Component: reusable element providing services independently to platforms, protocols and context;

(3) Container: an environment executing components that manages availability and code security;

(4) Contract: an interface, that contractually defines the syntax and semantics of single behavior;

(5) Connector: autonomous element encapsulating transport specific details for a specified contracts.

SOD interactions

Interactions describes how, through the connector, components make their services available or request those of others and how, collaboration takes place between components. Concretely there are two interaction pattern forms: communication pattern and services composition pattern elements of Service Oriented Computing (SOC) [START_REF] Michael | Serviceoriented computing: State of the art and research challenges[END_REF].

Communication pattern These patterns describes mechanisms used to publish and discover services. Service subscribers should possibly express their interest to a service event or may be a service event pattern and be notified when they occur, i.e published [START_REF] Yoneki | ECCO: Data centric asynchronous communication[END_REF]. Technically three main implementations exist presented below, the least developed to the most elaborate:

• Messaging: subscribers send asynchronous messages through a common canal to publishers who processes the service synchronously.

• Remote Procedure Call (RPC): subscribers make asynchronous blocking service call which are synchronously processed by publishers.

• Publish/Subscribe: it is an event oriented style with total de coupling in time i.e. stakeholders are not supposed to take part actively in the interaction at the same time, space i.e. stakeholders does not know each other, and synchronization i.e publishing and subscribing are not locked parallel events.

There could be many pub/sub categories: topic-based, content-based, typebased [START_REF] Th | The many faces of publish/subscribe[END_REF].

Services composition pattern Describes those patterns used to select and bind services, for a particular goal. In a layered architecture context, vertical service composition takes place at all layers of the architecture, it is a component deployment; rather horizontal service composition take place at the same layer. Composition can be static when occurring at design step (i.e service orchestration), or dynamic when occurring at execution, then services are substituted on demand, without rebuilding the whole system, providing more flexibility to the system (service choreography) [START_REF] Dijkman | Service-oriented design: a multi-viewpoint approach[END_REF][START_REF] Mietzner | Combining horizontal and vertical composition of services[END_REF].

• Service orchestration: is a behavior that a service provider performs internally to realize a service that it provides. It describes tasks that a service provider performs internally.

• Service choreography: it is a goal focus approach, describing common goal interactions and tasks (flow relations) among service providers and between service providers and service requester. It does not describe sub-tasks performed internally, because those tasks are not essential to collaboration. Finally, it covers the perspective of a stakeholder that wishes to have an overview of a collaboration.

User-Centered design

A User-Centered Design is an iterative design process framework that incorporate validation from the user every step of the way [START_REF] Ho | User-centered design: Definition, examples, and tips[END_REF]. Thereby, it is an optimistic approach to invent new solutions [START_REF] Gladkiy | User-centered design: Process and benefits[END_REF] by designing from user's perspective. This closeness and frequent interaction, helps understand user's needs.

1.5 Guarded attribute grammar

1.5.

Concepts and principles

Guarded attribute grammar (GAG) [START_REF] Badouel | Active workspaces: Distributed collaborative systems based on guarded attribute grammars[END_REF] is a formal framework, inspired from Knuth's attribute grammar concepts [START_REF] Klint | Toward an engineering discipline for grammarware[END_REF][START_REF] Knuth | Semantics of context-free languages[END_REF][START_REF] Vogt | Higher order attribute grammars[END_REF], also viewed as a process grammar [START_REF] Lee | Process grammar as a tool for business process design[END_REF],

and designed to model open user-centric architectures where data and rules requires flexibility. GAG help designing business processes by allowing dynamic task creation and data handling. Tasks competitive execution is implemented by a declarative approach where task dependencies are specified without any order.

The GAG system offers a process model with three levels of stratification [START_REF] Bhattacharya | Towards formal analysis of artifact-centric business process models[END_REF]:

(i) the business services (or tasks) level which identifies all of the existing tasks (known or inferred) in the target domain; this level does not evolve much, it is these tasks that act on the artifacts, according to the rules;

(ii) the business rules level, used to aggregate services together in a declarative language;

(iii) the business artifact level which offers the ultimate stage of abstraction, by combining data and processes.

s 0 → s 1 • • • s n (i ∈ N), rule i is production label, symbol s 0 is the left-hand side (lhs) and s 1 • • • s n is the right-hand side (rhs).
A symbol is said to be used, (respectively defined) when it appears in the righthand side (resp. left-hand side) of some production. We let • G and G • denote respectively the set of used but not defined symbols, and the set of defined but not used symbols respectively. given by w → w ′ iff exist u 1 , u 2 ∈ S * and (X, u)

∈ P such that w = u 1 • X • u 2 and
A formal approach for role-Based modeling of business collaboration processes

w ′ = u 1 • u • u 2 ;
and we let → * , be its reflexive and transitive closure.

Reduced grammar

Let ♯ B (u) denotes the number of occurrences of symbol B in word u.

Definition 1.5.3. (Reduced grammar): A grammar is reduced if (i) every symbol is accessible:

(∀B ∈ S) (∃A → * u) A ∈ G • ∧ ♯ B (u) ̸ = 0
and, (ii) for every symbol A exists a derivation A → * u leading to a word u all of whose symbols are in • G.

Data, Variables, Attributes and Guards

Data are arbitrarily typed piece of information needed to complete the execution of a task or produced as the result of the execution of a task. The GAG model associates data to pending task, using attributes. Each pending task is associated with two types of attributes, namely inherited attributes (inh) as incoming data to pending task context and synthesized attributes (syn) produced during task resolution and used by the context.

Each attribute a i is associated with a term or pattern and given by an equation of the form a i = t i , where t i is a data record, simply presented in a functional [START_REF] Nsaibirni | A Guarded Attribute Grammar Based Model for User Centered, Distributed, and Collaborative Case Management Case of the Disease Surveillance Process[END_REF] manner and can be recursively defined by equations 1.1 below

t i = c(t 1 , . . . , t n ) | v | cte (1.1)
where c is a data constructor or record, t 1 , . . . , t n are subterms or field of the record, v is a variable; variables in terms represent holes or place-holders which identify parts of the term that remain to be filled. Finally cte is a constant value of a given basic type which can be identified with zero arity data constructor. A term is said to be closed, if it contains only data constructors, filled with constant values carrying some meaning in the context in which they are used.

We let V ar(t) be the set of variables occurring in term t, then t is closed iff V ar(t) = ∅. We also let p : s 0 → s 1 • • • s n be a business rule, with inh(s) and syn(s)

being respectively inherited and synthesized attributes associated to symbol s; then we define

V ar inh (s) = {x ∈ V ar(t a ) | a ∈ inh(s)} V ar syn (s) = syn(s) V ar(s) = V ar inh (s) ∪ V ar syn (s) V ar inh (p) = V ar inh (s 0 ) V ar syn (p) = V ar syn (s 0 ) V ar(p) = ∪ ∀s∈lhs(p)∪rhs(p) V ar(s) (1.2)
as well as a guard (condition affecting inherited information) which specifies when production is activated.

Artifacts

An artifact is an abstract structure obtained by combining data and operations (processes), so as to form a monolithic block. Offering as advantages, several levels of abstraction, modularity and flexibility in the composition of business operations.

The description of an artifact first requires a data model that describes the internal structure of business objects; and secondly a model life cycle which describes the possible paths and timing for the execution of these objects.

GAGs are artifact-centric as they offers a high level of abstraction, while promoting varied and rich communication between the stakeholders of the system in the performance of an activity. The models obtained by this approach is said to be actionable [START_REF] Bhattacharya | Towards formal analysis of artifact-centric business process models[END_REF][START_REF] Cohn | Business artifacts: A data-centric approach to modeling business operations and processes[END_REF], i.e. can be used to automatically generate executable.

Formally, an artifact is seen as a tree with typed nodes termed as X :: s where X is the node of type s. Each node associated with the left hand side of a grammar

A formal approach for role-Based modeling of business collaboration processes

rule. An artifact is given by a set of equations of the form

X = P (X 1 • • • X n ) indicating that
X = R(X 1 • • • X n )
where X :: s and X i ::

s i with the underlying rule U (R) = s → s 1 • • • s n .
A closed node state that task s is completed using rule P , as shown on figure 1.2.

An opened node is a X :: s node associated to a pending task for which, performing rules are not yet known, and given by an equation on the form

X = s(t 1 , . . . t n )⟨u 1 . . . u m ⟩

Conclusion

This chapter presented the founding elements of this work, that is the role approach and its mechanisms, business process modeling, systems design principles and approaches, with the separation of concerns and service-oriented design. But also, the formal modeling framework that are the GAGs, used in this work was introduced.

The next chapter will complete the basic concepts, by describing the two various forms of business collaboration.

Ph.D thesis in Computer Science -University of Douala (2022)

CHAPTER 2

BUSINESS COLLABORATION:

PILLARS, TAXONOMY, USE CASES AND TASKING MODELS

Introduction

A business collaboration or more simply collaboration is the process of two or more people or organizations working together to complete a task, or to achieve a shared goal. Collaboration allows diverse skill sets both internally and externally, to be harnessed together, to set comprehensive content strategy designed to achieve business goals. As a process, a collaboration is completely defined by four elements:

(1) its process organization, i.e the way work will be carried out; (2) those involved namely contributors; (3) the reason for the existence of collaboration or business goals; (4) the context of collaboration.

Collaboration and its deployment environment is a distributed collaborative system (or simply collaborative system) as it is a set of independent entities or contributors either moral, human, machine or software components, providing precise services each individually. Every contributor in the system has personal intrinsic skills, i.e he is equipped with various mechanisms, namely for data storage, for communication (by message, Restful like, SOAP like,...) with his environment, for service discovery, sensing, etc. A contributor, by using a contextual assigned business skills, also plays a specific role in the accomplishment of some system business goal. In collaborative systems contributors can enter or go out from the system as they pleased. Same services occurrences can be provided by several contributors in the system. This chapter is devoted to business collaboration, for characterization and classification purpose, and to deduce both a formal definition,properties and describe associated tasking models for collaboration.

Pillars, criteria and strategies

Pillars of collaboration

A collaboration deployment process relationies on five pillars, namely: requester, contributors, tasks, interactions and outsourcing [START_REF] Dijkman | Service-oriented design: a multi-viewpoint approach[END_REF][START_REF] Hosseini | The four pillars of crowdsourcing: A reference model[END_REF].

Requester

The requester is a natural or legal person, who requests the power and wisdom of a contributor or a group of contributors, for the performance of a given service. To this end, the requester, among other things, can encourage contributors by gratification or social motivation (public recognition), outsource tasks, check the compliance of results with predefined standards and finally ensure project contributor's data confidentiality.

Contributors

A group of contributors is a community of actors or persons, taking part in a collaborative activity. A group of contributors must gather these four characteristic properties:

(1) Diversity: expressed here in terms of expertise (expertise and variety of skills), spatiality (geographic and disparate profiles), gender and age of contributors, etc.

(2) Anonymity: because contributors of a project, do not necessarily know each other, and do not necessarily know the requester.

(3) Importance: in terms of contributors numbers.

(4) Completeness or adequacy: i.e. contributors gather skills necessary to complete a task. However, an abundance in this context leads to overload, confusion and management difficulties.

Tasks

Within the framework of collaboration, three types of tasks can be distinguished, in particular primitives, services and outsourced tasks. • Outsourced task or crowd task is a decomposable service described only in terms of primitives. They are those types of services, requiring only contributor's intrinsic skills. When contributors are massively used to perform the same task within an activity they are called a crowd, and that task is a crowd task. Crowd task is an activity in which the crowd participates. This activity can be a large-scale data collection, a co-creation task, or an innovation task. By convention, their names are overlined. The association mechanism between a crowd and a crowd task is called outsourcing. A crowd task can be characterized by the five major properties defined below:

(1) Modularity i.e. a crowd task can be either atomic or decomposable.

(2) Complexity i.e. level of difficulty in carrying out this task. The complexity here is different from modularity in that a task can be complex, while remaining atomic.

(3) Solvability i.e. a crowd task is simple enough to be solved by humans, but complex for computers.

(4) Automaticity i.e. a crowd task is either difficult to automate, or expensive in automation.

(5) Contributor-centric i.e it is controlled and carried out by contributors.

Interaction scheme

An interaction represents the existing pairwise relation between requester, contributors and task in a collaborative system in order to perform a given goal. It is an explicitness of collaboration between those entities. Different forms of interaction are distinguished: between requester and contributors termed tasking relation, between tasks and requester or requesting relation, between tasks and contributors or supplying relation and finally between tasks or dependency relation.

An interaction scheme is a description of all interactions existing in a given collaborative system. To this end, there are two levels of interaction description: first level, describing interactions between required services (requested by requesters) and provided services (supplied by contributors) termed service choreography. Second level, describing how contributors render their services and term service orchestration. making power, on the evaluation of work carried out, choice between proposals for solutions, ideas, work orientation. In practice, there are two governance modes: hierarchical governance mode and flat governance mode:

Skills orchestration strategies

• Top-down mode or hierarchical governance: in this mode, to supply a given service, related tasks are assigned in an hierarchical manner progressively down to the base, and results are also assembled until the complete delivery of the desired service. Such approach is said to be a top-down hierarchical process and control rules are pre-established, control is operated at different stages of the system.

• Bottom-up mode or flat governance: by this mode, no control rule is established in advance. It consists in being able to provide a required service without prior organization. So it is according to needs that a task is carried out and results obtained are assembled progressively. Such an approach is said to be basic bottom-up process.

Participation

Participation defines properly the way contributors enter the collaborative activity; it can possibly be closed or opened.

• Closed participation: In this case, according to some system needs, contributors are explicitly invited, based on their skills. This casting approach provides a form of homogeneity of skills in the system, since contributors are chosen such grouping their skills, may cover the needs of entire targeted collaboration.

This form of collaboration is also said to be internal collaboration [START_REF] Laroui | Definition and types of collaboration in business[END_REF][START_REF] Johnson | Internal vs. external collaboration: What works[END_REF].

• Opened participation: contributors can freely access the collaborative process according to their feelings, skills and knowledge; in that context, skills can be hardly heterogeneous in the sense that possibly, there may be several occurrences of the same skills; but also, the set of skills involved may not cover the collaboration needs. This form of collaboration is also said to be external collaboration [START_REF] Johnson | Internal vs. external collaboration: What works[END_REF].

Business goal categories

As stated earlier, a collaboration is orchestrated for a given goal. Technically, there are three main goal categories for collaboration. Namely service supplying, knowledge sharing and co-creation (innovation). However, it should be noted that a choice made on a goal type for a collaboration also influences the choices in organization and participation criteria.

• Service supplying: process is clearly defined and structured, so organization is top-down; but participation could either be closed or opened.

• Knowledge sharing: organization could be top-down, as in learning case, where some contributors teach others; rather could also be flat as in social media.

participation could either be closed or opened.

• Co-creation and innovation: organization is flat, contributors jointly define rules as things progress. participation could either be closed or opened. Ph.D thesis in Computer Science -University of Douala (2022)

Types of collaboration

Coworking

Coworking is an arrangement in which several contributors from different area, share a common space [START_REF] Rus | Coworking: A community of work[END_REF][START_REF] Spinuzzi | Working alone, together: Coworking as emergent collaborative activity[END_REF]. There is no pre-established rules, and contributors are business partners as they freely contribute to an activity. When participation is closed, we talk of team coworking, rather when participation is opened, it is a opened coworking.

Team coworking

Team coworking is a form of collaboration, where members are chosen related to their skills. It is a form of collaboration in which contributors jointly choose a problem, determine the organization of work and select results. This type of collaboration is suite for cases where an organization has a case, but doesn't know how to manage it, as in innovation and co-creation cases.

Opened coworking

Opened coworking or communitarianism is a case of a crowdsourcing for innovation, as an opened community where members freely join. It is a form of collaboration in which everyone proposes problems and solutions as in a knowledge sharing case;

governance is flat and the participation of contributors is open.

Service supplying collaboration

Participation criteria applied to service supplying collaboration, leads to two subtypes of collaboration. Namely, when participation is closed, we talk of team servicing; while when participation is open, it is crowdsourcing.

Team servicing

It is a form collaboration where, contributors have complementary skills and are chosen by an organization to carry out a project. Everyone knows everybody else, their skill sets and their contribution to work. Governance here is hierarchical, with business processes well defined; while participation remains closed. Deadlines are set and achievements are equally recognized. This type of collaboration is the most common, due to service supplying e.g health management cases [START_REF] Nsaibirni | A Guarded Attribute Grammar Based Model for User Centered, Distributed, and Collaborative Case Management Case of the Disease Surveillance Process[END_REF], software development, administrative managements, etc.

As an illustration case, consider an E-administration application for issuing civil status certificates, with the process described on figure 2 The crowdsourcing concept, introduced by Jeff Howe [START_REF] Howe | The rise of crowdsourcing[END_REF], is a collaborative business process model, in which tasks are carried out by a crowd. Simply, an organization wishing to carry out a task can requests an online community for a voluntary accomplishment of the task, according to what both parties have a mutual benefit.

In crowdsourcing, organizational objectives are top-down, while creative activity is bottom-up. We therefore say that crowdsourcing is a mixed mode organized process [START_REF] Burger-Helmchen | Crowdsourcing: Définition, enjeux, typologie[END_REF][START_REF] Kulkarni | Collaboratively crowdsourcing workflows with turkomatic[END_REF][START_REF] Brabham | Using crowdsourcing in governement[END_REF]3,[START_REF] Kubiak | Business models innovation based on crowds: a comparative study[END_REF], as it is a combination of top-down and bottom-up processes.

Ph.D thesis in Computer Science -University of Douala (2022) Crowdsourcing can also be defined as an activity (either costly in time or in resources) outsourcing process, towards a large number of anonymous actors termed the crowd. A crowdsourcing system is then an environment, on which a crowdsourcing process is deployed. It integrates the practices of business process modeling, and establishes the connection between the crowd, different individual actors and machines. (1) an interface describing required services (or data) and provided services (or data),

Formalizing business collaboration

(2) a storage for persistence within the contributor,

(3) business rules or functionalities targeted by the contributor, lastly (4) communication resources and mechanisms by which a contributor exchanges with others.

Building collaboration, requires to identify capabilities that must be added to individual contributors so that they can work with others [START_REF] Grosz | Collaborative systems (aaai-94 presidential address)[END_REF]. So when considering a contributor, a clear separation is made between its infrastructure (storage, communication mechanisms, sensing,etc.) and its functional goal in the system (interface, business rules). The contributor infrastructure is thus perceived as an actor part, while its functional goal is a role part. In fact, within a collaboration, each entity can be assigned a single role, or rather play several roles at a moment. In addition, due to potential unavailability of entities ( maybe caused by failure, saturation, etc.) at a given time, a complete process reconfiguration may occurred, which strongly impacts the nature of potential services carried out. Contributors may not have the same skills, and several occurrences of a role could exist at the same time; for those reasons, collaboration is said to be a dynamic process.

Business collaboration tasking model 2.5.2.1 Preliminaries and properties

At this step we focus on service supplying collaboration types. Recall that, as the goal is to describe processes, we are just interested with grammar structure in GAG concept, mainly business service and business rules levels. A production is interpreted as an action that is performed in order to (partially) solve the task A in its left-hand side, and the symbols in its right-hand side represent the residual tasks that should in turn be solved in order to get a full completion of A. Thus a derivation A → * u is interpreted as a process (a partially ordered set of actions) directed towards the resolution of task A, and this process is complete if u is the empty word.

The process is conditionally complete if u contains only external services (symbols in • G) since its completion is then conditioned by the complete execution of these services by its environment. If • G = ∅, i.e. the grammar represent a standalone application that relies on no external services, and if the grammar is reduced then every partial resolution of a task can be extended in order to reach completion.

This property is called soundness. One can define a relative notion of conditional soundness stating that any provided service can indeed be rendered using external services irrespective of the way the computation started.

The soundness property that can easily be checked by a fixed point computation is nonetheless undecidable for guarded attribute grammars due to fact that data attached to services can dynamically restrict the set of potentially applicable productions [START_REF] Badouel | Active workspaces: Distributed collaborative systems based on guarded attribute grammars[END_REF]. Note moreover that the soundness of its underlying grammar is neither a sufficient nor a necessary condition for the soundness of a guarded attribute grammar due to the non-monotony of this property arising from the combination of a universal and an existential quantifier in its definition:

∀A → * u ∃u → * ε 2.5.2.

Intrinsic skills and services

Consider a production or business rule of a given grammar G = (S, P ) below

s 0 → T 0 • • •T m s 1 • • • s n with n, p ∈ N (2.1)
• s 0 ∈ S is a defined service, i.e service carried out by processing the rule 2.1 above.

• s 1 • • • s n are used services in that rule, and they must be completed before completing s 0 .

• T 0 • • • T m are intrinsic skills, implemented as primitives (see section 2.2.1.3).

Within a role and considering business rules, services defined but not used, are called provided services, those used but not defined are required services, lastly services defined and used are internal services.

s 0 → T 0 • • •T m s 1 • • • s n s 0 • • • s p (2.2)
where:

• s 0 is a defined service,

•

s 1 • • • s n are used services • T 0 • • •T m are contributor's intrinsic skills, finally • s 0 • • • s p are crowd tasks.
According to rule 2.2, to supply service s 0 , services s 1

Conclusion

This chapter was devoted to business collaboration concepts, particularly on definition, characterization, taxonomy, as well as use cases illustrating some real world situations. Ultimately, a collaboration is implemented as a set of independent tenants, qualified to offer specific services, in a given context. Among the four types of collaboration presented, we focused for the family of collaborations with an hierarchical organization (team servicing and crowdsourcing) for which a business tasking model has been described, in guarded attribute grammars formalism. The next chapter will define role interface, i.e. an extension made to GAGs, with the aim of providing them with (de) composition mechanisms, conducive to flexible description of collaborations.

Ph.D thesis in Computer Science -University of Douala (2022)

CHAPTER 3

AN INTERFACE OF ROLE THEORY FOR COLLABORATION 3.1 Introduction

This chapter focuses on service-oriented design, for collaboration modeled by GAG, with the purpose of providing a reasoning base. Even if the objectives differ (serviceoriented design versus verification) as well as the models used (user-centric collaborative systems versus reactive systems) we are largely inspired by works that have been carried out on behavioral interfaces of communicating processes. Three main ingredients have been put forward here, which will serve as our guideline. First, an interface is mainly used to formalize a contract-based reasoning for components.

Second, an interface is viewed as an abstraction of a component, a so-called behavioral type. Third, given a specification G of the desired overall system and a specification C of a given component, we seek for a specification X, for those systems that, when composed with the component C, satisfies the global property (residual specification concept).

Modeling interface of role

Considering a very simple extension of interface concept, obtained by adding a binary relation on a set of services, indicating for each of provided services, the list of services that are potentially required to carry it out. This relation gives only potential dependencies because a service can be provided in various ways and relying on a variety of external services.

Recall that as the goal is to describe processes, we are just interested with grammar structure in GAG concept. Business skills are expressed as grammar production rules (or business rules), describing job decomposition, in the form

s 0 → T 0 • • •T m s 1 • • • s n s 0 • • • s p (3.1)
where s 0 is a defined service, s 1

Potential dependencies

In a business collaboration, a service is potentially provided in different ways, described by business rules. However, the manner of rendering this service is dictated both, on the one hand, by choices made by the contributor of this service and, on the other hand, by the availability of required services. Reconsidering rule declaration 0 above for example, we can observe that service dcl could be rendered in three different ways. It will be said that dcl potentially depends on services withnessing, hospital and reading respectively. At a given moment, the effective way of rendering this service dcl, will depend on the choice made by contributor Citizen, playing role Declarer. Definition 3.2.1. Potential dependencies are over-approximations of relations between provided services and required services.

Grammar interface

The goal is to define an abstraction of grammar, called an interface for grammar, specifying which services are provided, which external services are required to perform them, and potential dependencies; in particular, the interface ignores internal tasks. In order to process service A that is a pending task in his workspace, rule br 1 can be chosen and applied (which corresponds to a certain action or activity) and this decision ends execution of service A (since the right part is empty). Alternatively, rule br 2 can also be chosen. In that case, two new (residual) services, namely B and C are created and A will end as soon as B and C are completed.

It is considered that provided service s 0 , potentially depend on required service s 1 , if there is a derivation s 0 → * u where the word u contains an occurrence of s 1 .

Definition 3.2.2. An interface for grammar G = (S, P ) is

I(G) = ( • G, R(G), G • ) where R(G) = {(s 1 , s 0 ) | ∃u ∈ S * s 0 → * u ∧ ♯ s 1 (u) ̸ = 0}
and ♯ s 1 (u) denotes occurrences number of symbol s 1 in the word u.

Interface of role

An interface of role [START_REF] Badouel | Interfaces of Roles in Distributed Collaborative Systems[END_REF][START_REF] Badouel | A Calculus of Interfaces for Distributed Collaborative Systems: The Guarded Attribute Grammar Approach[END_REF] is some abstraction of the guarded attribute grammar

( • R, R, R • ) consist of a finite binary relation R ⊆ Ω × Ω of disjointed sub-sets • R and R • from Ω, such that • R = R -1 (Ω) = {s 0 ∈ Ω | ∃s 1 ∈ Ω, (s 0 , s 1 ) ∈ R} and R • ⊇ R(Ω) = {s 1 ∈ Ω | ∃ s 0 ∈ Ω, (s 0 , s 1 ) ∈ R}.
Set R • represents services provided (or defined) by the interface and • R is the set of required (or used) services. Relation (A, B) ∈ R indicates that service B potentially depends upon service A.

Thus A ∈ R • \ R(Ω)

Properties, conventions, basic operations

Property and conventions

Autonomy or closure: An interface is closed (or autonomous) if relation R (and therefore also • R) is empty. Thus, a closed interface is given by all services it (autonomously) provides.

In order to facilitate ratings and calculations, we will use the following conventions:

Emptiness: The empty interface that does not provide any service is noted ∅ = (∅, ∅, ∅).

Transitivity: We will first identify a relation

R ⊆ Ω×Ω such that R(Ω)∩R -1 (Ω) = ∅ with interface ( • R, R, R • ) such that • R = R -1 (Ω) and R • = R(Ω).
We also identify a set of X ⊆ Ω with the restriction of the identity relation to the whole

X, i.e., the diagonal {(A, A) ∈ Ω 2 | A ∈ X}.
In doing so, it is possible, for example, to express the condition

B ∈ Y ∧(∃C ∈ X (A, C) ∈ R ∧ (C, B) ∈ Y ) for R, S ⊆ Ω × Ω et X, Y ⊆ Ω since (A, B) ∈ R; X; S; Y where operator (; )
denotes sequential composition defined below in section 3.3.2 Note also that with this convention we have X ∩ Y = X; Y for X and Y sub-sets of Ω.

Sequential composition

Let R 1 and R 2 two interfaces, a sequential composition of those interfaces, denoted

R 1 ; R 2 is defined when • R 1 ∩ R • 2 = ∅ and given by R 1 ; R 2 = { (s 0 , s 2 ) ∈ Ω 2 | ∃s 1 ∈ Ω (s 0 , s 1 ) ∈ R 1 ∧ (s 1 , s 2 ) ∈ R 2 }
(R 1 ; R 2 ) = R -1 1 ( • R 2 ) ⊆ • R 1 and (R 1 ; R 2 ) • = R 2 (R • 1 ) ⊆ R • 2 .
Sequential composition, simply solves transitivity in potential dependencies between services.

Restriction and Co-restriction

Let O ⊆ Ω a subset of services. A restriction of interface R to O denoted by R O is given as

R O = {(s 1 , s 0 ) ∈ R | s 0 ∈ O} With (R O) • = O ∩ R • and • (R O) = R -1 (O ∩ R • ) respectively.
In fact, considering any system having a role r interfaced by R, and a subset of services O, the restriction operation reconfigures role r so that, only its provided services elements of O are enabled; other provided services are inhibited. In practice, this operator is useful when you are interested just by some skills of a multi-skilled role.

Union of interfaces, quasi-interface and acyclicity

The union of interfaces is an interface if none of the services defined by one interface is used by another. In the general case, R = (∪

• i R i , ∪ i R i , ∪ i R • i ) meets the conditions of the definition 3.2.3 of interface, but • R ∩ R • = ∅. If the R relation is acyclic,
it is said to be a quasi-interface since it induces an interface given by the following definition. This is the rationale for assuming that a quasi-interface must be acyclic. More specifically, what example 1 above, shows is the (simplest) illustration of two grammars that are reduced but whose union is not. This is due to the cycle created when we put them together. It is immediate that the union of two reduced grammars whose union of interfaces is acyclic is also reduced. Our objective is to be able to present an autonomous grammar as the gathering of subgrammars. The global grammar will thus be reduced (and therefore sound) if each of the subgrammars is reduced and if the operation of union (whose associativity we will seen below) preserves this property. Hence the importance of this acyclicity hypothesis, even though it is somewhat pessimistic. In a way, this assumption imposes a constraint on how to break down a system into sub-modules, i.e. how to structure our specification. In practice, as we have experienced in our previous studies [START_REF] Nsaibirni | User interactions in dynamic processes: Modeling user intractions in dynamic collaborative processes using active workspaces[END_REF], these constraints are reasonable. Nevertheless, if we give ourselves finer abstractions of grammars, which will be done further by introducing non-deterministic interfaces, we can end up with less constrained forms of composition.

Interface of role composition

Concept and principles

An interface is mainly used to formalize a contract-based reasoning for components.

The idea is that a component of a reactive system [START_REF] Harel | Logics and models of concurrent systems[END_REF] is required to behave correctly only when its environment does. The correctness of composition is stated in terms of a contract given by assume-guarantee conditions: the component should guarantee some expected behaviour when plugged into an environment that satisfies some properties. The principle of composition is however made subtle by the fact that each component takes part in the others' environment [START_REF] Abadi | Composing specifications[END_REF]. Safety and liveness properties, which are not relevant in our case, are crucial issues in this context and largely contribute to the complexity of the resulting formalisms. The underlying models of a component range from process calculi [START_REF] Abadi | A logical view of composition[END_REF] to I/O automata and games [START_REF] De Alfaro | Interface automata[END_REF]. These interface theories have also been extended to take some qualitative aspects into account (time and/or probability).

Composition operation

Note that (R

1 ◃▹ R 2 ) • = R • 1 ∪ R • 2 . In addition, since R • i ∩R • i = ∅ for i = 1, 2 we get • (R 1 ◃▹ R 2 ) = ( • R 1 \ R • 2 ) ∪ ( • R 2 \ • R 1 )
if their union R 1 ∪ R 2 is an acyclic relation and R • 1 ∩ R • 2 = ∅. Then we'll denote R 1 ◃▹ R 2 = ⟨R 1 ∪ R 2 ⟩ their composition.
It follows directly from the definition that the composition of interfaces is commutative and has the empty interface as a neutral element. Note that we can have

• R 1 ∩ • R 2 ̸ = ∅,
so that both interfaces may require common external services.

Associativity of the composition

The following example shows that composition is not associative, if we do not require that composable interfaces have disjoint outputs. Of course, the hypothesis of having an associative interface composition operation is a matter of choice. One could alternatively have chosen to drop the assumption that composable interfaces have disjoint output sets and to deal with a non-associative composition operation. Let R 1 , R 2 , and R 3 three interfaces given by figure

3.7. If R 1 ◃▹ (R 2 ◃▹ R 3 ) = (R 1 ◃▹ R 2 )
◃▹ R 3 we would expect this interface to be given by

R = ⟨R 1 ∪ R 2 ∪ R 3 ⟩, so R = {(A,
try in R 2 ◃▹ R 3 . Symmetrically R l = (R 1 ◃▹ R 2 ) ◃▹ R 3 = {(A, D), (C, D), (A, E), (C, E)}.
(or R 2 R 1 since this operation, as a special case of ◃▹ remains commutative). So

• (R 1 R 2 ) = ( • R 1 \ R • 2 ) ∪ • R 2 , and (R 1 R 2 ) • = R • 1 ∪ R • 2 .
Figure 3.8: Cascaded product of two roles R 1 and R 2

The cascaded product of interfaces R 1 and R 2 is a form of role interfaces composition, in which R 2 requires no service from R 1 . The composite interface obtained has as provided services, the union of the various provided services of R 1 and R 2 . The composite interface required services is then defined as the union of required services of R 1 and R 2 , where those provided by R 2 and required by R 1 are removed.

Remark 2. The underlying relation of the cascaded product is given by

R 1 R 2 = (I 1 × R 2 ) ; (R 1 × O 2 )
where

I 1 = • R 1 \ R • 2 et O 2 = R • 2 \ • R 1 .

Direct product

Let R 1 and R 2 two composable role interfaces, as stated in definition 3.4.1. If

R • 1 ∩ • R 2 = ∅ and R • 2 ∩ • R 1 = ∅ are verified, we say that the composition is the product (direct) of R 1 and R 2 , denoted by R 1 × R 2 . Note that R 1 × R 2 = R 1 ∪ R 1 and so • (R 1 × R 2 ) = • R 1 ∪ • R 2 and (R 1 × R 2 ) • = R • 1 ∪ R • 2 .
Direct product of interfaces R 1 and R 2 , is a special case of composition, where both associated roles requires no services from each other. Composition operation, is then assumed as a pooling skills operation, since required services of the composition, is the union of R 1 and R 2 required services, and the same for the composition provided services.

Componentization test

Componentization which is the process of breaking into separate components, is an approach to software development that involves breaking software down into identifiable pieces, independently implements and deploy, these components are then stitched together with network connections and workflows. We gain flexibility in design and ease of component reuse. Precisely, in a context of role-based approach, having two interfaces R and R 1 , it may be useful to know if their skills encompass, or may be if R 1 can be used in a context where R is expected; then R 1 is said to be a component of R.

Definition 3.4.2. R 1 is a component of R, noted R 1 ⊑ R, if there is an interface R 2 such as R = R 1 ◃▹ R 2 . R 1 is a strict component of R, noted R 1 R, if there is an interface R 2 such as R = R 1 × R 2 .

Implementation order

An interface is viewed as an abstraction of a component, a so-called behavioral type.

Thus we must be able to state when a component satisfies an interface, viewed as an abstract specification of its behavior. A relation of refinement, given by a preorder I 1 ≤ I 2 , indicates that any component that satisfies I 2 also satisfies I 1 . In the context of service-oriented programming we would say that interface I 2 implements interface I 1 .

An interface environment is a component that provides all the services required by the interface and uses only the services provided by the interface for this purpose.

Definition 3.5.1. An E interface is an eligible environment for an R interface if both interfaces are composable and the composition is a closed interface, namely

• (R ◃▹ E) = ∅.
We let Env (R) refers to all eligible environments of the R interface.

Ph.D thesis in Computer Science -University of Douala (2022) Definition 3.5.2. An interface R 2 is a implementation of the interface R 1 , noted

R 1 ≤ R 2 , when R • 2 = R • 1 and R 2 ⊆ R 1 .
Thus, R 2 is an implementation of R 1 if it provides the same services as R 1 using only those services already available to R 1 and with fewer dependencies1 . The following proposition shows that R 2 is an implementation of the R 1 interface if and only if it can be substituted to R 1 in any eligible environment for R 1 .

Proposition 3.5.1.

R 1 ≤ R 2 if and only if Env (R 1 ) ⊆ Env (R 2 ).
Proof. We first show that the condition is necessary. For this reason, let's assume

R 1 ≤ R 2 ( which means that R • 2 = R • 1 and R 2 ⊆ R 1 ) and prove that any eligible environment E for R 1 is a qualifying environment for R 2 . Since E is composable with R 1 we have R • 1 ∩ E • = ∅ and E ∪ R 1 is acyclic. Then we also have R • 2 ∩ E • = ∅ and E ∪ R 2 is acyclic since R • 2 = R • 1 and R 2 ⊆ R 1 . Thus E is composable with R 2 . Moreover, for the same reasons, • (E ◃▹ R 2 ) = ( • E \ R • 2 ) ∪ ( • R 2 \ E • ) ⊆ ( • E \ R • 1 ) ∪ ( • R 1 \ E • ) = • (E ◃▹ R 2 ) = ∅. Hence E ∈ Env (R 2 ). We show that the condition is sufficient by contradiction. Since R 1 ≤ R 2 implies R • 2 = R • 1 you have to build E ∈ Env (R 1 ) \ Env (R 2 ) assuming that R 1 ̸ ⊇ R 2 . Let's say (A, B) ∈ R 2 \ R 1 then
the interface we're looking for is E such as

• E = {B}, E • = • R 2 , and E = {(B, A)}.
Indeed, E can be composed with R 1 but not with R 2 because of the B → A → B cycle in (R 1 ∪ {(B, A)} * . In addition, the composition of E with R 1 gives a closed interface.

Residual specification

Third, a notion of residual specification has also proved to be useful. The problem was first stated in [START_REF] Merlin | On the construction of submodule specifications and communication protocols[END_REF] as a form of equation solving on specifications. Namely, given a specification G of the desired overall system and a specification C of a given component we seek for a specification X for those systems that when composed

. If R 1 ⊑ R then R = R 1 (R ↙ R 1 ) or R ↙ R 1 , called the strict residue of R per R 1 , is given as the restriction from R to R • \ R • 1 . If R = R 1 R 2 then R R • 2 = R ↙ R 1 = R 2 and R = (R ↙ R) × (R ↙ R 1 ).
Proof. It must be shown that if R 1 and R 2 are two relations that can be composed

with R = R 1 ◃▹ R 2 then R = R 1 R ↙ R 1 and R = (R ↙ R 1 ) × (R ↙ R 1 ) or R ↙ R i = R R • j for {i, j} = {1, 2}. By the remark 1 R 1 ◃▹ R 2 is (the only) 2 solution of the equation system. R 1 ◃▹ R 2 = (A ∪ I 1 ); R 1 ∪ (B ∪ I 2 ); R 2 où I 1 = • R 1 \ R • 2 I 2 = • R 2 \ R • 1 O 1 = R • 1 ∩ • R 2 O 2 = R • 2 ∩ • R 1 A = (B ∪ I 2 ); R 2 ; O 2 B = A ∪ I 1 ); R 1 ; O 1 So it is immediate (see Figure 3.10a) that R 1 (R 1 ◃▹ R 2 ) R •
2 is the solution of the same 'equations system and thus the two relations coincide. The same system of equations is associated to (R ↙ R 2 ) × (R ↙ R 1 ) as shown in figure 3.10b.

It remains to be shown that

if R = R 1 R 2 then R ↙ R 1 = R R • 2 coincides with R 2 , and indeed R R • 2 = (( • R 1 \ R • 2 ) ∪ R 2 ) ; (R 1 ∪ R • 2 ) R • 2 = (( • R 1 \ R • 2 ) ∪ R 2 ) R • 2 = R 2 by the remark 2 and because R • 1 ∩ R • 2 = ∅.
Hence residual R/R 1 characterize the interfaces of the components that, when composed with R 1 , provide an implementation of R.

Non-deterministic Interfaces

The notion of interface presented so far is still a somewhat rough abstraction of the roles described by a GAG specification. In particular, we would like to be able to take into account the non-determinism that results from the choices offered to the user on how to solve a task. For that purpose we replace relation R ⊆ Ω × Ω by a map R : Ω → ℘(℘(Ω)) that associates each service A ∈ Ω with a finite number of alternative ways to carry it out, and each of these with the set of external services that it requires. Definition 3.7.1. A non-deterministic quasi interface on a set Ω of services is a map

R : Ω → ℘(℘(Ω)). We let R • = {A ∈ Ω | R(A) ̸ = ∅} and • R = ∪ {R(A) | A ∈ Ω }. It is a non-deterministic interface when • R ∩ R • = ∅.
R(A) = {π(u) ⊆ • G | A → * u }
where π(u) = {A ∈ S | ♯ A (u) ̸ = 0 } is the set of grammatical symbols that occur in word u. Thus a set of symbols is in R(A) if and only if it is the set of symbols of a word in ( • G) * that derives from A. Note that if the grammar is reduced one has

• R = • G and R • = G • .
This new representation of interfaces is richer than its deterministic counterpart.

It is more precise and might indeed been considered too much precise in some situations since it requires to handle more information. Nonetheless non-deterministic interfaces are in many respect more easy to handle than deterministic interfaces and they lead to simplified definitions and easier proofs as shown next. In particular, and by contrast with deterministic interfaces, both sets • R and R • can be left implicit. This is due to the fact that services A provided by a non-deterministic interface that requires no external services are now explicitly given as those such that R(A) = {∅} (which should not be confused with R(A) = ∅ which corresponds to A ̸ ∈ R • ). Thus the following operations can straightforwardly be defined for non-deterministic quasi-interfaces.

• Sequential composition:

R 1 ; R 2 (A) = {∪ i X i | {A 1 , . . . , A n } ∈ R 2 (A) and X i ∈ A i }. • Restriction: R O(A) = R(A) if A ∈ O and R O(A) = ∅ otherwise. • Union: (∪ i R i )(A) = ∪ i R i (A). • Transitive closure: R * (A) = ∪ ∞ i=1 R i (A) where R n+1 = R n ; R. Note that R * = R if R is an interface. • Composition: R 1 ◃▹ R 2 = ⟨R 1 ∪R 2 ⟩ where ⟨R⟩(A) = R * (A)∩℘(℘(Ω\R • )) is the non-deterministic interface induced by the non-deterministic quasi-interface R. Note that (R 1 ◃▹ R 2 ) • ⊆ R • 1 ∪ R • 2 and • (R 1 ◃▹ R 2 ) ⊆ ( • R 1 \ R • 2 ) ∪ ( • R 2 \ R • 1 ). A quasi-interface R is said to be reduced when • ⟨R⟩ = • R and • ⟨R⟩ = • R.
We say that two interfaces R 1 and R 2 are safely composable3 when their union (the quasi-interface

R 1 ∪ R 2 ) is reduced. Two interfaces R 1 and R 2 are safely composable if and only if (R 1 ◃▹ R 2 ) • = R • 1 ∪ R • 2 and • (R 1 ◃▹ R 2 ) = ( • R 1 \ R • 2 ) ∪ ( • R 2 \ R • 1 ).
It is readily shown that the composition of non-deterministic quasi-interfaces is associative and one does not need to require that the individual components have disjoint output sets to ensure that property. Thus non-deterministic quasi-interfaces equipped with this composition operation is a commutative monoid (whose neutral element is the empty interface). Moreover R ◃▹ R = ⟨R⟩ and since ⟨R⟩ = R when R is an interface, we deduce that the composition of interfaces is idempotent.

The natural extension of the implementation order in the non-deterministic case is to let

R 1 ≤ R 2 ⇐⇒ (∀A ∈ Ω) (∀X ∈ R 1 (A)) (∃Y ∈ R 2 (A)) • Y ⊆ X
expressing that anything that R 1 can do R 2 can do better (namely, it can do the same using fewer external services). This is a pre-order (reflexive and transitive relation) where two non-deterministic interfaces are equivalent when their images for each A have the same sets of minimal elements (for set inclusion) or equivalently have identical upward closures. Say that an interface is saturated if R(A) is upwardclosed for every A ∈ Ω. And it is reduced is for every A ∈ Ω any two elements of R(A) are incomparable. Thus any non-deterministic interface is equivalent to its upward-closure (a saturated interface) and to its restriction to its set of minimal elements (a reduced interface). The order relation on saturated interfaces is simply given by the pointwise set-theoretic inclusion:

R 1 ≤ R 2 ⇐⇒ (∀A ∈ Ω) R 1 (A) ⊆ R 2 (A)
Thus their least upper bounds are given by pointwise set-theoretic union:

( ∨ i R i )(A) = ∪ i R i (A)
and their greatest lower bounds by pointwise set-theoretic intersection:

( ∧ i R i )(A) = ∩ i R i (A).
The following properties then immediately follow:

• distributivity:

∨ i ∧ j R i,j = ∧ j ∨ i R i,j . • ( ∨ i R i ) • = ∪ i R • i but also ( ∧ i R i ) • = ∩ i R • i because the sets R i (A)
are upper closed sets and thus all those which are not empty contain Ω and thus have non empty intersection.

Note that the greatest lower bound of an arbitrary set of (saturated and nondeterministic) interfaces is also given by (

∧ i R i )(A) = {∪ i X i | ∀i X i ∈ R i (A) }.
Lemma 3.7.1. The composition commutes with joins:

R ◃▹ ( ∧ i R i ) = ∧ i (R ◃▹ R i ).
Proof. The operation ◃▹ is monotonic in each of its argument and thus R ◃▹

(∧ i R i ) ≤ ∧ i (R ◃▹ R i ).
We are left to prove the converse relation. By definition of the sequential composition of relations and the greatest lower bound of interfaces it follows that R;

(∧ i R i ) = ∧ i (R; R i ), and thus ∧ i R n i = (∧ i R i ) n by induction on n. Hence ∧ i R * i = ∧ i (∨ n R n i ) = ∨ n (∧ i R n i ) = ∨ n (∧ i R i ) n = (∧ i R i ) * . It follows that ⟨∧ i R i ⟩(A) = (∧ i R i ) * (A) ∩ ℘(℘(Ω \ (∧ i R i ) • )) = (∩ i R * i (A)) ∩ ℘(℘(Ω \ ∩ i R • i )) = (∩ i R * i (A)) ∩ ℘(℘(∪ i (Ω \ R • i ))) ⊇ (∩ i R * i (A)) ∩ (∩ i ℘(℘(Ω \ R • i ))) = ∩ i ⟨R i ⟩(A) i.e. ⟨∧ i R i ⟩ ≥ ∧ i ⟨R i ⟩. Thus R ◃▹ (∧ i R i ) = ⟨R ∨ (∧ i R i )⟩ = ⟨∧ i (R ∨ R i )⟩ ≥ ∧ i ⟨R ∨ R i ⟩ = ∧ i (R ◃▹ R i ).
Since we can compute the least upper bound of an arbitrary family of (saturated and non-deterministic) interfaces, one can directly define the residual operation as: Definition 3.7.3. The residual of two interfaces is given by:

R/R 1 = ∧ {R ′ | R ≤ R 1 ◃▹ R ′ }
which satisfies (almost by definition!) the required property of residuals:

Proposition 3.7.2. R/R 1 ≤ R ′ ⇐⇒ R ≤ R 1 ◃▹ R ′ . Proof. R ≤ R 1 ◃▹ R ′ ⇒ R/R 1 ≤ R ′ by definition of the residual. Conversely let us assume that R/R 1 ≤ R ′ then by monotony R 1 ◃▹ R/R 1 ≤ R 1 ◃▹ R ′ . By lemma 3.7.1 R 1 ◃▹ R/R 1 = R 1 ◃▹ ∧ {R ′′ | R ≤ R 1 ◃▹ R ′′ } = ∧ {R 1 ◃▹ R ′′ | R ≤ R 1 ◃▹ R ′′ } ≥ R (since R is a lower bound of the given set). Hence R ≤ R 1 ◃▹ R ′ .

Conclusion

This work is a first attempt to develop an interface theory for distributed collaborative systems in the context of service-oriented programming. We defined a notion of interface in order to explicit how a module can be used in a given environment using an assume/guarantee approach: we describe the set of services that can be provided by the module under the assumption that some other services are available in its environment. We have then defined a residual operation on interfaces characterizing the systems that, when composed with a given component, can complement it in order to realize a global specification. We intend to use residuation to define and structure the activities of crowdsourcing system actors. The residual operation can be used to identify the skills to be sought in the context of existing services in order to achieve a desired overall behavior. Such a system can be implemented by Guarded Attribute Grammars and interfaces can be used to type applications.

We have mainly worked with basic (deterministic) interfaces. We have nonetheless shown how to extend the approach to non-deterministic interfaces. In the nondeterministic case it becomes possible to define an additional operation, namely an

Ph.D thesis in Computer Science -University of Douala (2022)

operation that gives the co-restriction R I of an interface R to a set of services

I ⊆ Ω by letting (R I)(A) = {X ⊆ I | X ∈ R(A) }.
That operation states how a role can be used when the set of services actually provided by the environment is known (to be I). This operation can be used to identify the usefulness of a component given by its interface knowing which services are actually available in the environment. Note that one can define the corresponding operation on grammars with N I(G I) = N I(G) I: G I by deleting all productions whose right-hand side contains a grammatical symbol in • G \ I.

On that basis one can enrich the information to take qualitative information into account to cope with uncertainty or time constraints. Actually it might be possible that we have only a partial knowledge of the set of available services in the environment in the form of a believe function [START_REF] Shafer | A mathematical theory of evidence[END_REF] or a possibilistic distribution [START_REF] Zadeh | Fuzzy sets as the basis for a teory of possibility[END_REF]. The interface should then allow us to quantify the possibility of realizing a service given this information on the environment. Similarly information can also be added on time execution, for instance by limiting behavior to ensure that services are delivered within certain time constraints.. implies a prior rigorous definition, of the set of roles and the relations between them, necessary to describe the functioning of a target domain. The role is seen here as a particular concern in the system to be modeled. In fact, a role-based design approach is similar to a separation of concern technique [START_REF] Czarnecki | Generative programming -methods, tools and applications[END_REF][START_REF] Caetano | Business process decompositionan approach based on the principle of separation of concerns[END_REF][START_REF] Stefan | Separation of concerns in model elicitation -role-based actor-driven business process modeling[END_REF], applied to business process design, and enables inter-organizational flexible process design [START_REF] Saidani | A role-based approach for modeling flexible business processes[END_REF][START_REF] Bianchini | Semantic service design for collaborative business processes in internetworked enterprises[END_REF][START_REF] Bianchini | P2s: A methodology to enable inter-organizational process design through web services[END_REF].

It is implemented by specifying activities defining the process steps, as well as flows describing coordination of these activities, as it may be done with BPMN [START_REF] Winters | Bpmn and microservices orchestration, part 1 of 2: Flow languages, engines, and timeless patterns[END_REF][START_REF] Rücker | The microservices workflow automation cheat sheet[END_REF] orchestration or UML collaboration or activities diagrams [START_REF]Documents associated with unified modeling language(uml) version 2.5 -beta 2[END_REF]. Applying a role-based approach requires a clear separation of infrastructure mechanisms (communication, storage, service discovery, etc.) seen as primitives, necessary for its collaboration within its environment on the one hand, and functional goal i.e its effective contribution to collaboration on the other hand. By considering all functional goals present in a given system context, we get a formal basis for business objectives of the whole dynamic system.

A grammatical modeling of role concept

Each role is associated with a grammar describing its business skills, i.e. it's contribution in a given collaborative process. We recall that a production of the grammar is given by a left part, indicating the non-terminal to be expanded and a right part, describing how to expand this non-terminal. We interpret a production as a means of decomposing a task, the symbol on the left-hand side, as sub-tasks associated with the symbols on the right-hand side. A role specifies the set of actions that a given contributor can take in the system. For simplification purpose, consider role type and role as equivalent, simply called role (see section 1.2.2 for more details).

A role specifies the set of actions or business skills devolved to a given actor in the system. We also recall that, as the goal is to describe processes, we are not yet interested with attributes in guarded attribute grammars.

Definition 4.2.1. A role r is given by a couple (G, R) where G is a guarded attribute grammar (GAG) [START_REF] Badouel | Active workspaces: Distributed collaborative systems based on guarded attribute grammars[END_REF] specifying role r business skills, and R it's associated interface of role.

Role collaboration

We talk about collaboration between two roles, when there is a service dependency between these two roles. This dependency can be direct, in which case it is a direct collaboration, likewise, the dependency can be indirect and in that case it is an indirect collaboration. Definition 4.2.2. Two roles

r 1 = (G 1 , R 1 ) and r 2 = (G 2 , R 2 ) are in a direct collabo- ration iff R 1 R 2 holds. We denote ( • R 1 ∩ R • 2 , r 2 , r 1 ) that collaboration, labeled by • R 1 ∩ R •
2 , the set of services for which r 1 and r 2 collaborate; r 1 being the services requester, while r 2 is the provider of those services.

Thus r 1 and r 2 will be in an indirect collaboration iff

∃r k = (G k , R k ) such that R 1 R k R 2 holds.

Potential direct collaborations of a role

A potential direct collaborations of a role, is a graph showing all potential services providers for that role in a collaborative context. Let r 0 be a given role; algorithm 1, determines potential direct collaborations (or potential dependencies) of r 0 , in a context R, in which r is member and such that ∀r i ∈ R, r i = (G i , R i ).

1 input: r 0 = (G 0 , R 0 ) , R 2 output: C //set of potential collaborations of role r 0 . 3 4 C ← ∅ 5 rPDG(r 0 , R) = 6 forall r i in R 7 if R 0 R i then C ∪ {( • R 0 ∩ R • i , r i ,
R ′ ← ∅ 6 iPDG(R, R ′ ) = 7 if (r i in R) and (R ̸ = ∅) then 8 rPDG(r i , R ∪ {R ′ ∪ {r i }}) ∪ iPDG(R \ {r i }, R ′ ) 9 else iPDG(R \ {r i }, R ′ ) Algorithm 2: Context R induced potential dependencies graph (iPDG) C = { ({a} , r 5 , r 0 ) , ({m} , r 6 , r 4 ) ({y} , r 0 , r 2 ) , ({z} , r 1 , r 2 ) ({w} , r 1 , r 3 ) , ({x} , r 4 , r 3 ) ({x} , r 0 , r 3 ) , ({t} , r 2 , r 3 ) } (4.1)

Potential workflow of a service

The induced workflow of a service s 0 , describes how this service will be issue; and is implemented as a dependency subgraph, derived from the induced potential dependencies graph (iP DG) of the role providing service s 0 . Consider a predicate depend(l, s 0 ) with l, s 0 ∈ Ω, which returns true if service s 0 depends on the service l and f alse otherwise. We define function dependOn(s 0 , R) = {(L, r) | L ⊂ Ω * , r ∈ R and ∀l ∈ L depend(l, s 0 )} which seeks in context R, all the roles involved in the process of providing service s 0 , as well as the associated required services, and returns a list of couples with on one hand a set of required services L and the role r requesting these services on the other hand.

We also let collaborations (l 0 , r i , r j ) such as for any couple (L k , r k ) ∈ dependOn(s 0 , R), r k being requester of service l 0 with (l 0 ∈ L k et r j = r k ).

iP DG(R, ∅) L k = {(l 0 , r i , r j ) | ∀(L k , r k ) ∈ dependOn(s 0 ,
1 Inputs: Serv = ∅ ∪ {s 0 } , R 2 output: C //a set of potential collaborations needed to provide the service s 0 .

4.3.1. An F -collaboration is a triplet ( • R 0 ∩ R • i , {r i , • • • r k } , r 0 ), where r 1 , • • • r k are potential providers of services elements of set • R 0 ∩ R •
i and r 0 is the requester for those services (with

• R 0 ∩ R • i = • • • = • R 0 ∩ R • k )
, for some i and j.

A factorized collaboration scheme is then a potential dependency graph, possibly consisting of collaborations (i.e

( • R 0 ∩ R • 1 , r 1 , r 0 )), and F -collaboration (( • R 0 ∩ R • i , {r i , • • • r k } , r 0 )) if necessary. 1 input: C 2 output: C ′ 3 C ′ ← ∅ 4 factorize(C) = 5 forall c in P (C) 6 if |c| ==1 then //c is like { ( • R 0 ∩ R • 1 , r 1 , r 0 ) } 7 C ′ ∪ c 8 else if |c| > 1 then //c is like {( • R 0 ∩ R • 1 , r 1 , r 0 ), • • • , ( • R 0 ∩ R • |c| , r |c| , r 0 )} 9 C ′ ∪ { ( • R 0 ∩ R • 1 , {r 1 , • • • , r |c| }, r 0 ) | 10 r 1≤i≤|c| ∈ provider ( • R 1 ∩ R • |c| , c
( • R 1 ∩ R • |c| , c
) returns the list of service providers, labeled by elements of set

• R 1 ∩ R • |c| in a c
collaboration set, while requester(c) checks if r 0 is the requester in each case of collaboration. i=1 R i and R ′ = n i=1 R i their respective cascade compositions. By proposition 4.5 in [START_REF] Badouel | Interfaces of Roles in Distributed Collaborative Systems[END_REF][START_REF] Badouel | A Calculus of Interfaces for Distributed Collaborative Systems: The Guarded Attribute Grammar Approach[END_REF], those compositions are associative. As by hypothesis those workflows render same services, we have s 0 = s 1 and s 0 ∈ R • ∩ R ′• , two cases can be distinguished: whether m > n and then R ′ ⊆ R, we say R ′ realizes service s 0 with less business rules than R; or m < n so R ⊆ R ′ and as R ′ , R realizes service s 0 with less business rules.

Activity in collaborative context

Atomicity of an activity

An activity for a given service s 0 , is said to be atomic [START_REF] Caetano | Business process decompositionan approach based on the principle of separation of concerns[END_REF], if it has only one occurrence of role supplier for each required service in that activity. For example, the atomic forms of activity activity u in the previous equation 4.2, are respectively:

activity u 0 = ( u, [ (x
, r 0 , r 3 ), (t, r 2 , r 3 ), (a, r 5 , r 0 ), (y, r 0 , r 2 ), (z, r 1 , r 2 ) ] )

(4.3)

activity u 1 = ( u, [ (x, r 4 , r 3 ), (t, r 2 , r 3 ), (m, r 6 , r 4 ), (y, r 0 , r 2 ), (z, r 1 , r 2 ) ] ) (4.4)
Definition 4.4.2. An activity activity s 0 = (s 0 , workf low(s 0 , R)) is atomic, iff for all (s 0 , r i , r j ) and (s 0 , r k , r j ) in workf low(s 0 , R), r i = r k .

Activities functional decomposition

An activity can be progressively fragmented into a set of atomic activities. The principle of decomposition, is based on roles (concerns), and states that, as long as there are several occurrences of the same role r in an activity, this activity is broken down into new activities containing a single role occurrence r. This principle

Activity realizability

The question of feasibility here, refers to the possibility of carrying out an activity, in a finite number of stages, and rendering provided service. This assumes that all the roles necessary for carrying out that activity must be available; we say it is a favorable context.

Termination of an activity, is conditioned by the fact that its workflow must contain autonomous roles at the start of the chain. These autonomous roles, playing activity trigger role, we also say they are service trigger roles. Algorithm 6 below, describes principle of test of feasibility for a workflow, by applying a filtering pattern mechanism. A workflow is realizable if that algorithm returns T rue and its required services queue(Serv) is empty. In case that F alse is returned. Required service queue contains a list of services, still to be provided, for completing activity.

= ( • R i ∩ R • k , r k , r i ), label(c) returns set • R i ∩ R • k
of services labeling that collaboration, and provider(c) returns r k providing those services.

Remark 0. An activity activity s 0 = (s 0 , workf low(s 0 , R)) is said to be almost realizable, if at least one of its atomic forms obtained by decomposition, ends; i.e there is a C ∈ decomp(workf low(s 0 , R), ∅) such that realisable({s 0 } , C) = (T rue, ∅).

Similarly the activity activity s 0 is said realizable, if all atomic forms end; i.e. whatever C ∈ decomp(workf low(s 0 , R), ∅), realisable({s 0 } , C) = (T rue, ∅).

Contributor of a business collaborative process

Concept and definitions

A contributor is any entity in a system capable of acquiring information, communicating with its environment and processing. For this, a contributor has several primitive. He can also play one or more roles in the system. Since a contributor knows how to instrument, communicate and process information he is considered an intelligent active space [START_REF] Badouel | Active workspaces: Distributed collaborative systems based on guarded attribute grammars[END_REF].

In this work, since a contributor is an entity which intervenes in a process by playing a predetermined role, we will assume that it has an internal mechanism of communication with its environment. Similarly we will assume that it also has persistence mechanisms for its data, and finally, a publication and service discovery mechanism.

Definition 4.5.1. A contributor a τ is given by a couple (R τ , C τ ), where R τ is the set of potential roles the contributor can play, and C τ is the set of constraints on those potential roles.

Constraints on contributor's potential roles

Let a τ = (R τ , C τ ) an actor, r i and r j two roles; an association between contributor a τ and roles r i and r j is materialized by the fact that r i , r j ∈R τ . We will say for instance that r i ,r j are contributor's a τ potential roles.

It is possible to define constraints, on the potential roles of a contributor [START_REF] Riehle | Role model based framework design and integration[END_REF].

Consider role pairs (r i , r j ) such that r i , r j ∈R τ with 1 ≤ i, j ≤ |R τ |; four constraint values can be associated with these pairs roles (see section 1.2.3 ), namely:

Dcr or nothing, for no constraint;

Imp (r i , r j ) indicating that if actor a τ plays role r i , then he must also play role r j ;

Eqv (r i , r j ) in case both Imp (r i , r j ) and Imp (r j , r i ) holds;

P hb (r i , r j ) in this case, actor a τ playing role r i , cannot play role r j .

Relation "play a role"

A contributor can play one or more roles, within an activity, or in several parallel activities. So one can distinguishes several cases of implementation of "play" relation.

Case 1: Playing several roles in an activity

A contributor actor can play more than one role within an activity; provided that those roles do not provide the same services.

) Imp(r i ,r j ) = play (a τ , R i × R j , activity s 0 ) play (a τ , r i , activity s 0 ) Eqv(r i ,r j ) = play (a τ , R i × R j , activity s 0 )
or play (a τ , R j × R i , activity s 0 ) play (a τ , r i , activity s 0 ) P hb(r i ,r j ) = play (a τ , R i , activity s 0 )

and not play (a τ , R j , activity s 0 ) (4.5)

Ph.D thesis in Computer Science -University of Douala (2022)

Conclusion

The main interest in this chapter, was to outline a role-based design approach, for business collaboration processes. The role concept has been formally defined, as well as associated readjustment and switching mechanisms, to provide a certain flexibility to design. Collaboration scheme was formally defined, in the form of a given service workflow, thus making it possible to describe what is an activity in a given context. Finally, the notion of contributor and it's interaction mechanisms was presented, thus offering the whole range of tools necessary for this design approach.

Architecturally, role-based design approach is similar to agent design approach, but differ on how job is carried out. In agent systems, a contributor will do the job according to its knowledge to the whole system [START_REF] Zhu | A role agent model for collaborative systems[END_REF][START_REF] Zhu | Role mechanisms in collaborative systems[END_REF][START_REF] Kazik | Role-based approaches to development of multi-agent systems: A survey[END_REF], while here, a contributor will ordinarily accomplish his tasks according to his own decisions.

To conclude, we discuss the key features of our design approach and draw some future research directions.

Assessment of the design approach

Guarded attribute grammars provide a modular, declarative, user-centric, datadriven, distributed and reconfigurable formal design tool for business collaboration.

It favors flexible design and execution of business process since it possesses concurrency, modularity, reconfiguration, distribution, interoperability properties [START_REF] Nsaibirni | A Guarded Attribute Grammar Based Model for User Centered, Distributed, and Collaborative Case Management Case of the Disease Surveillance Process[END_REF].

These properties are directly inherited by the role-based approach, since it has GAGs as a basis. In addition, this approach guarantees many of the design principles and properties set out in section 1.4; also as a process modeling, those of understandability and maintainability [START_REF] Weber | Collaborative business process modeling[END_REF][START_REF] Hermann | Collaborative business process management -a literature-based analysis of methods for supporting model understandability[END_REF].

Cohesion and coupling: our approach design unit is a role. A role is described in terms of services provided, services required, internal services and relationship between them; that is, a role wrap together semantically close elements. Thus, within a role, cohesion is strong. Also, interface of role and its mechanisms, provides flexibility in composition, making coupling weak. These requirements of cohesion and coupling, being necessary for a good design, guarantee the single responsibility principle; and then one could say that the role-based approach encapsulate the separation of concerns principle.

Scalability: as setting operators like restriction, helps to hide not needed functionalities of an interface, together with composition mechanisms associated with role interfaces, this approach facilitates the dynamic redefinition of roles available in a context, thus respecting the principle of interface segregation.

Reusability: this approach is concerned with building collaboration, based on use of existing roles in the collaborative process. These roles are designs and byproducts of the design life cycle, viewed as stand alone units.

Ph.D thesis in Computer Science -University of Douala (2022)

Maintainability: as a role is single responsible, possible failures in processes may be easily detected, identified, isolated and corrected.

Future works

Defining a data model for business collaboration: An immediate extension of this work is to include data handling in the design approach. For this, it is necessary to define a graphical syntax for the business artifacts, as well as to explain the interaction mechanisms between them, which can highlight the data manipulated in the business collaboration, and define data aggregation and splitting operators; [START_REF] Tchendji | A stable and consistent document model suitable for asynchronous cooperative edition[END_REF] could be a basis to this work.

A dynamic tasking model for a coworking context: the coworking approach to collaboration is goal oriented; it assumes an unstructured production process, and it is through contributors interactions that production rules are defined. From the GAG architecture (see section 1.5.1) describing such a business collaboration approach supposes starting from business artifacts, in order to infer the rules that have favored their evolution. Then the business rules life cycle is therefore closely linked to artifacts life cycle. It would be interesting to propose a design approach for such cases.

Modular DSL for roles and collaborations: We will be dealing here with the serialization of collaboration schemes, in a role-based design context. As we have seen previously, this approach favors the use of modules or libraries considered as a toolbox, for the assembly line development, of products conforming to a specific field of application. Since the role implementation (library) is seen as a domain specific language (DSL), capturing the semantics of an application domain, a collaboration scheme can reasonably be seen as a composition of DSLs. This is not achieved without certain difficulties, in particular the difficulty of conceiving and implementing new languages on the one hand, the little flexibility that a language offers in order to facilitate its evolution, and finally the collaboration between languages. This work can be carried out on the basis of the precedent work done on modular language design [START_REF] Badouel | Modular Design of Domain-Specific Languages using Splittings of Catamorphisms[END_REF].

I

  would also like to say a special thank you to a number of natural and legal persons without whom the completion of this work would not have been possible: • LIRIMA (International Laboratory for Research in Computer Science and Applied Mathematics), • The FUCSHIA research team, • The Faculty of Sciences of the University of Douala, • My colleagues at the Department of Mathematics and Computer Science of the University of Douala.

  Legal structures are characterized by a document model (an abstract grammar) and each intentional representation can be manipulated independently and possibly asynchronously by several co-authors through various editing tools that operate on "partial replicas ". For unsynchronized edition of a partial replica concerned co-author must have a syntactic document local model that constraints him to ensure minimum consistency of local representation with respect to the global model. This consistency is synonymous with the existence of one or more (global) intentional representations towards the global model, assuming the current local representation as her/their partial replica.

1. 4 . 1

 41 Separation of concerns 1.4.1.1 Definitions and goal

Figure 1 . 1 :

 11 Figure 1.1: GAG layered architecture with associated goals

Definition 1 .

 1 5.2. (Derivation relation): We let the derivation relation →⊆ S * × S *

  the node X :: s is labeled by the production P : s → s 1 • • • s n and having as successors X1 :: s1 • • • Xn :: sn respectively; and two equations cannot have the same left hand side. There are two types of nodes, namely open nodes or tasks being resolved and closed nodes or resolved tasks.

Figure 1 . 2 :

 12 Figure 1.2: Artifact construction by rewriting rules

Figure 1 . 3 :

 13 figure 1.3 above.

Figure 2 . 1 :

 21 Figure 2.1: Business collaboration taxonomy

  .2, showing collaborations between roles Declarer, Secretary, csOfficer and Judiciary_Authority; roles played respectively by the actors Citizen, Agent, (Mayor, Diplomat) and Prosecutor as contributors in an issuance civil status certificate (birth, marriage, death) activity according to laws in Cameroon. this example is a cross-functional collaboration case, as Mayor and Diplomat can issue certificate deliverance, but in different contexts.

Figure 2 . 2 :

 22 Figure 2.2: Administrative collaboration in civil status certificate issuance

Figure 2 . 3 :

 23 Figure 2.3: A crowdsourced road maintenance activity

2. 5 .

 5 1 contributor in a business collaboration Definition 2.5.1. (contributor): A contributor of a business collaborative process, is an active entity gathering four things:

declaration 0 :

 0 dcl → IN P U T withnessing | IN P U T hospital | IN P U T reading declaration 1 : sDcl → IN P U T (3.2)

br 1 :Figure 3 . 1 :Figure 3 .

 1313 Figure 3.1: Grammar of a role providing service A

G

  associated to a role, whose aim is to specify what services are provided, which Ph.D thesis in Computer Science -University of Douala (2022) external services are required to carry them out and an over-approximation of the dependencies between required and provided services termed potential dependencies. Interface disregards internal services.

Figure 3 . 2 :

 32 Figure 3.2: An interface of role associated with the role on figure 3.1

  is a service provided by the interface that requires no external services.Note that, since • R is the domain of the R relation, the set of required services may remain implicit. This is not the case for all the services provided because it can strictly encompass the co-domain of the relation. Nevertheless, we will use the same symbol to designate an interface and its underlying relation.The Declarer interface of rules 3.2 above, is then defined by figure 3.3 and equation 3.3 below.

Figure 3 . 3 :

 33 Figure 3.3: Interface of a Declarer role

Figure 3 . 4 :

 34 Figure 3.4: Sequential composition of two interfaces

Definition 3 . 3 . 1 .

 331 If R = ( • R, R, R • ) is a quasi-interface, i. e. R is an acyclic relation, • R = R -1 (Ω) and R • ⊇ R(Ω), let's put ⟨R⟩ = R * ∩ (I × O), where I = • R \ R • and O = R • . ⟨R⟩ is an interface with • ⟨R⟩ = I and ⟨R⟩ • = O.

Figure 3 . 5 :

 35 Figure 3.5: Interface induced by a quasi-interface

Figure 3 . 6 :

 36 Figure 3.6: Composition of two interfaces.

Figure 3 . 7 :

 37 Figure 3.7: A counter-example showing that, associativity of composition does not hold, if interfaces shared some provided services.

  D), (C, D), (A, E), (B, E), (C, E)}. It should be noted that service D could be produced either by R 1 or R 3 so that we have both (A, D) and (C, D) as dependencies in R. It follows that E potentially depends on both A, B, and C. However, if we compute R 1 ◃▹ (R 2 ◃▹ R 3 ) we get R r = {(A, D), (C, D), (B, E), (C, E)} because in R 2 required service D is no longer an en-

Figure 3 . 9 :

 39 Figure 3.9: Direct product of two roles R 1 and R 2

  with the component satisfies the global property. It takes the form of an equation C ◃▹ X ≈ G where ◃▹ stands for the composition of specifications and ≈ is some equivalence relation. If ≈ is the equivalence induced by the refinement relation the above problem can better be formulated as a Galois connection [87] G/C ≤ X ⇐⇒ G ≤ C ◃▹ X stating that the residual specification G/C is the smallest (i.e. less specific or more general) specification that when composed with the local specification is a refinement of the global specification. Since C ◃▹ -is monotonous (due to Galois connection) it actually entails that a component is an implementation of the residual specification if and only if it provides an implementation of the global specification when composed with an implementation of the local specification . Proposition 3.6.1

Definition 3 . 7 . 2 .

 372 The non-deterministic interface of a grammar G = (S, P ) is the function R = N I(G) : Ω → ℘(℘(Ω)) where Ω = • G ∪ G • (i.e. grammatical symbols that correspond to internal tasks are abstracted) and

  Ph.D thesis in Computer Science -University of Douala (2022)

4. 2 Context, role and collaboration 4 . 2 . 1

 2421 Context of collaborationIn a targeted domain, a context of collaboration is the set of roles readily available for the realization of some activity. A context of collaboration is dynamic, i.e roles involved vary over time. For instance, we will consider the context on Figure4.1 as a running collaborative context for the next parts of this work.

Figure 4 . 1 :

 41 Figure 4.1: Running collaboration context of a system

r 0 )} Algorithm 1 :

 1 Role potential dependencies graph (rPDG) calculus In our running context of figure 4.1, applying algorithm 1 to determine potential dependencies of role r 3 , will result to graph below figure 4.2, given in extension by C below.

Figure 4 . 2 :

 42 Figure 4.2: Direct potential collaborations of role r 3 , in figure 4.1 context

1 input: R 2 R

 2 ′ //roles whose rPDG have already been determined, initially empty. 3 output: C 4 5

  R), l 0 ∈ L k and r j = r k } be a filtering made on the induced potential dependencies graph, concerning Ph.D thesis in Computer Science -University of Douala (2022)

5 if

 5 s i in Serv then i ∈ {1, • • • , |Serv|} 6 ns = Serv \ {s i } ∪ {s | (s, r) ∈ dependOn(s i , R)} 7 {iP DG(R, ∅) L k } ∪ workflow(ns, R, iP DG(R, ∅))8 where (L k , r k ) ∈ dependOn(s 0 , R) Algorithm 3: Determining a potential workflow for a service Algorithm 3, generates the potential workflow of a given service s 0 , from a context (R), having the associated induced potential dependencies graph (iP DG(R, ∅)). For instance, the potential workflow of the service u, obtained by applying that algorithm in the context of previous figure 4.1, is presented in the figure 4.3 below, in which unnecessary services and dependencies are watermarked.

Figure 4 . 3 :

 43 Figure 4.3: Service u potential workflow

Figure 4 . 4 :

 44 Figure 4.4: Factorizing a workflow -(a) a collaboration scheme. (b) the factorized collaboration scheme equivalent to the one on (a).

Definition

) and r 0 Algorithm 4 :

 04 scheme to a C ′ factorized collaborations scheme. Where function provider

4. 4 . 1 Figure 4 . 5 :

 4145 Figure 4.5: Activity activity u workflow

( a )

 a Process of issuing a civil status certificate by the mayor (b) Process for the issuance of a civil status certificate by a diplomat

Figure 4 . 6 :

 46 Figure 4.6: Decomposition of the previous activity on figure 2.3, into two subactivities, csDelivrance0 and csDelivrance1

1 input: Serv //set of required services 2 C 7 | 8 |

 278 //activity workflow 3 output: (Bool, Serv)4 realizable(∅, _) = (T rue, ∅) //the workflow is realizable 5 realizable(Serv, ∅) = (F alse, Serv) // not realizable, Serv are required services 6 realizable(Serv, c ∈ C) Serv ∩ label(c) == ∅ =realizable(Serv ∪ req, C \ {c}) Serv ∩ label(c) ̸ = ∅ =realizable(Serv ′ ∪ req, C \ {c})9 where 10 Serv ′ = Serv (x ∈ Serv ∧ x / ∈ label(c)) 11 req = dependOn(label(c), provider(c)) Algorithm 6: Checking realizability of activity s 0 For a given collaboration c

  Ph.D thesis in Computer Science -University of Douala (2022) (a) Contributor a τ playing two roles (b) Workflow simplified by the direct product of R 0 and R 1

Figure 4 . 7 :

 47 Figure 4.7: A contributor playing several roles in an activity

Figure 4 . 8 :

 48 Figure 4.8: Several contributors playing same role r 2 in an activity

Figure 4 . 9 :

 49 Figure 4.9: A contributor involved in two parallel activities

  Ph.D thesis in Computer Science -University of Douala (2022) required = toSet fst --Sequential composition of two R1 and R2 seqComp::Eq a => Relation a -> Relation a -> Relation a seqComp [] _ = [] seqComp _ [] = [] seqComp (l:ls) rs = oneComp l rs ++ seqComp ls rs --Checking composition possibility between a relation instance (x,y) --and a relation R2 oneComp::Eq a => (a,a) -> Relation a -> Relation a oneComp _ [] = [] oneComp (x,y) (r:rs)= if y == fst r then (x,snd r): oneComp (x,y) rs else oneComp (x,y) rs --restriction of a relation R to a subset of provided services O in Out(R) restriction::Eq a => [a] -> Relation a -> Relation a restriction [] _ = [] restriction (l:ls) rs = toSelect snd l rs ++ restriction ls rs --Checking relations providing a given provided service toSelect::Eq a => ((a,a) -> a) -> a -> Relation a -> Relation a toSelect _ _ [] = [] toSelect f l (r:rs) = if l == f r then r: toSelect f l rs else toSelect f l rs --Reflexive-Transitive closure of a relation refTransClosure::(Eq a,Ord a) => Relation a -> Relation a refTransClosure = refClosure.transClosure --reflexive closure refClosure:: (Eq a,Ord a) => Relation a -> Relation a refClosure [] = [] refClosure (x:xs) = List.nub ((x:xs) ++ [(y,y) | y <-Set.toAscList (required (x:xs)) ++ Set.toAscList (provided (x:xs))]) --transitive closure transClosure::(Eq a) => Relation a -> Relation a transClosure [] = [] transClosure closure |closure == closureUntilNow = closure |otherwise = transClosure closureUntilNow where closureUntilNow = List.nub $ closure ++ [(a,c)|(a,b)<-closure, (b',c)<-closure, b == b'] --cyclicity test isCyclic::(Eq a,Ord a) => Relation a ->Bool isCyclic [] = False isCyclic r = hasCycle (Set.toAscList (Set.union (required r) (provided r))) r --is a quasi-Interface ? isQuasi::(Eq a,Ord a) => Relation a -> Bool isQuasi [] = False isQuasi r = not(isCyclic (refTransClosure r)) --relations union union::(Eq a) => Relation a -> Relation a -> Relation a union xs ys = List.nub (xs ++ ys) --checking dependencies within a relation depend::(Eq a) => a -> Relation a -> [a] depend _ [] = [] depend s (r:rs) = if s == snd r then fst r : depend s rs else depend s rs A.2 Implementation of a role interface module Interface where import qualified Data.Set as Set import Data.List() import Relation type Interface a = (Set.Set a,Relation a,Set.Set a) --is closed interface? isClosed::Interface a -> Bool isClosed (x,r,_) = null x && null r --is empty interface? isEmpty::Interface a -> Bool isEmpty (x,r,y) = null x && null r && null y --get empty interface empty::Interface a empty = (Set.empty,[],Set.empty) --check interfaces composability areComposable::(Eq a,Ord a) => Interface a -> Interface a -> Bool areComposable (_, x1, o1) (_,x2,o2) = not(isCyclic (transClosure (x1 `union`x2))) && Set.null (Set.intersection o1 o2) --check possible collaboration sdependOn (x:xs) i = if null req then sdependOn xs i else req ++ sdependOn xs i where req = depend x (relation i) dependOn0::(Eq a) => a -> Interface a -> ([a], Interface a) dependOn0 s i = (depend s (relation i), i) mdependOn::(Eq a) => [a] -> [Interface a] -> [a] mdependOn [] _ = [] mdependOn _ [] = [] mdependOn (x:xs) crowd = concatMap (dependOn x) crowd ++ mdependOn xs crowd mdependOn0::(Eq a) => [a] -> [Interface a] -> [([a],Interface a)] mdependOn0 [] _ = [] mdependOn0 _ [] = [] mdependOn0 (x:xs) crowd = filter (\(f,_)-> f/=[]) (map (dependOn0 x) crowd) ++ mdependOn0 xs crowd A.3 Implementing a collaboration module Collaboration where import Interface import qualified Data.Set as Set import Data.List(intersect) type Collaboration a = ([a],Interface a,Interface a) label::Collaboration a -> [a] label (xs ,_,_) = xs requester:: Collaboration a -> Interface a requester (_ ,_,r) = r provider:: Collaboration a -> Interface a provider (_,r,_) = r whoSupply::(Ord a) => a -> [Interface a] -> [Interface a] whoSupply s = seekService s output whoNeeds::(Ord a) =>a -> [Interface a] -> [Interface a] whoNeeds s = seekService s input --seekService::(Ord a) => a -> (Interface a -> Set.Set a) -> [Interface a] -> [Interface a] seekService _ _ [] = [] seekService s h (i:is) = if Set.member s (h i) then i : seekService s h is else seekService s h is rGDPi::(Eq a, Ord a) => Interface a -> [Interface a] -> [Collaboration a] rGDPi _ [] = [] rGDPi r (i:is) = if not (collaborate r i) then rGDPi r is else (x,y,z) : rGDPi r is where x = Set.toAscList (Set.intersection (input r) (output i)) y = i z = r gDPi::(Eq a, Ord a) => [Interface a] -> [Interface a] -> [[Collaboration a]] gDPi [] _ = [] Ph.D thesis in Computer Science -University of Douala (2022) gDPi (i:is) prec = rGDPi i (xs++is) : gDPi is xs where xs = i:prec sGDPi::(Eq a, Ord a) => a -> [Interface a] -> [Collaboration a] sGDPi _ [] = [] sGDPi s crew = hx [s] crew (concat (gDPi crew [])) decidable::(Eq a, Ord a) => [a] -> [Collaboration a] ->(Bool,[a]) decidable [] _ = (True, []) decidable xs [] = (False, xs) decidable xs (c:cs) | null (xs `intersect`label c) = decidable (xs++req) cs | not (null (xs `intersect`label c)) = decidable (xxs ++ req) cs where xxs = [x | x <-xs, x `notElem`label c] req = sdependOn (label c) (provider c) A.4 Implementing an F-collaboration a] (Interface a) (Interface a) | OrCol [a] [Interface a] (Interface a) deriving Show Ph.D thesis in Computer Science -University of Douala (2022) groupCol::(Eq a, Ord a) => [Collaboration a] -> [[Collaboration a]] groupCol [] = [] groupCol (c:cs) = fst (subCol (label c) (c:cs)) : groupCol (snd (subCol (label c) (c:cs))) subCol:: (Eq a, Ord a) => [a] -> [Collaboration a] -> ([Collaboration a],[Collaboration a]) subCol xs cs = (x,c) where x = filter(\(l,_,_)-> l == xs) cs c = filter(\(l,_,_)-> l /= xs) cs ortransform::(Eq a, Ord a) =>[Collaboration a] -> [TCollaboration a] ortransform cs = ortrans (groupCol cs) ortrans::[[Collaboration a]] -> [TCollaboration a] ortrans = map orT orT::[Collaboration a] -> TCollaboration a orT [] = NoCol orT [c] = Col (label c) (provider c) (requester c) orT (c:cs) = OrCol (label c) (map provider (c:cs)) (requester c) Activity a = (a,[Collaboration a]) process::Activity a -> [Collaboration a] isDecomposable::(Eq a, Ord a) => Activity a -> Bool isDecomposable act = foldr ((||).decomposable) False (ortransform (process act)) decomp::Eq a =>[TCollaboration a] -> [[TCollaboration a]] -> [[TCollaboration a]] decomp [] prefix = prefix decomp (NoCol:cs) prefix = decomp cs prefix decomp (OrCol s p r :cs) prefix = decomp cs (mdup (s,p,r) prefix) decomp (Col s r0 r1:cs) prefix = decomp cs (inser (Col s r0 r1) prefix) inser::Eq a => TCollaboration a -> [[TCollaboration a]] -> [[TCollaboration a]] inser _ [] = [] inser (Col s p r) (xs:xss) = pref : inser (Col s p r) xss where pref = if isSupplied r xs then xs ++ [Col s p r] else xs isSupplied::Eq a => Interface a -> [TCollaboration a] -> Bool isSupplied _ [] = False isSupplied r (Col _ _ r0:cs) = r == r0 || isSupplied r cs dup::([a],[Interface a],Interface a) -> [TCollaboration a] -> [[TCollaboration a]] dup (_,[],_) _= [] dup (_,_,_) [] = [] dup (s,p:ps,r) cs = (cs ++ [Col s p r]) : dup (s,ps,r) cs mdup::([a],[Interface a],Interface a) -> [[TCollaboration a]] -> [[TCollaboration a]] mdup (_,[],_) _= [] mdup (s,p:ps,r) [] = [Col s p r] : mdup (s,ps,r) [] mdup (s,ps,r) (cs:css) = dup (s,ps,r) cs ++ mdup (s,ps,r) css dec::(Eq a, Ord a) => Activity a -> (Bool,[a]) dec(_,[]) = (True,[]) dec(s0,cs) = decidable [s0] cs Ph.D thesis in Computer Science -University of Douala (2022)

  Cascaded product of two roles R 1 and R 2 . . . . . . . . . . . . . . . . 3.9 Direct product of two roles R 1 and R 2 . . . . . . . . . . . . . . . . . 3.10 Residual composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Running collaboration context of a system . . . . . . . . . . . . . . .

1.1 GAG layered architecture with associated goals . . . . . . . . . . . . 1.2 Artifact construction by rewriting rules . . . . . . . . . . . . . . . . . 1.3 Data handling by an artifact . . . . . . . . . . . . . . . . . . . . . . . 2.1 Business collaboration taxonomy . . . . . . . . . . . . . . . . . . . . 2.2 Administrative collaboration in civil status certificate issuance . . . . 2.3 A crowdsourced road maintenance activity . . . . . . . . . . . . . . . 3.1 Grammar of a role providing service A . . . . . . . . . . . . . . . . . 3.2 An interface of role associated with the role on figure 3.1 . . . . . . . 3.3 Interface of a Declarer role . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Sequential composition of two interfaces . . . . . . . . . . . . . . . . 3.5 Interface induced by a quasi-interface . . . . . . . . . . . . . . . . . . 3.6 Composition of two interfaces. . . . . . . . . . . . . . . . . . . . . . . 3.7 A counter-example showing that, associativity of composition does not hold, if interfaces shared some provided services. . . . . . . . . . 3.8 4.2 Direct potential collaborations of role r 3 , in figure 4.1 context . . . . 4.3 Service u potential workflow . . . . . . . . . . . . . . . . . . . . . . xi

Table 2 .

 2

	1: Some usual primitives
	• Services are (de)-composable pieces of work, possibly described in terms of
	primitives, outsourced tasks and services. A service is a goal or a targeted
	functionality offered by a role (by convention, a service names starts with a
	lower case letter).

  2.5.2.3 Crowd tasksDefinition 2.5.2 (Crowd task). A crowd task s i with i ∈ N is defined by a business rule like s i → T 0 • • •T m i.e they are type of services requiring only contributors intrinsic skills, to be carried out and thus are autonomous services.Consider a business rule s 0 → T 0 • • •T m one may ask the difference between services s 0 and s 0 . In fact s 0 is a potentially outsourceable task, it can be defined and used in the same role (or used by another role); rather s 0 is an outsourced task, so it is only defined in an autonomous role, termed crowd role, and only used by a requester role. By convention, a crowd role only define outsourced tasks, and we say a crowd role supply only crowd services.

2.5.2.4 Business skills Definition 2.5.3 (Business skills). A business skill is a set of business rules, describing job decomposition in the form

  • • • s n and s 0 • • • s p must be achieved and skills T 0 • • •T m are needed by contributor playing that role. Any Declarer, can trigger the process of establishing a civil status certificate, by a declaration which can be either normal (dcl) or special (sDcl), following business skills expressed by rules (2.3) below.

	clSnap → CON T EXT LOCAT ION SN AP snap → SN AP	(2.6)
	• A Citizen according to business skills in rule (2.7), can tag a picture and assess
	br 0 : dcl → IN P U T withnessing object, in both cases by inputting some data.
		| IN P U T hospital
		| IN P U T reading tagP icture → IN P U T assessObject → IN P U T	(2.3) (2.7)
		br 1 : sDcl → IN P U T
	• A Secretary according to business skills in rule (2.4), is responsible of decla-• an IS i.e information system is responsible of data collection, selecting targeted
	rations correction and transcription in related registers, whether these decla-road for maintenance, and sending some alerts (rules are not yet defined).
	rations are normal (normAscr) or special (spAscr).
	selectRoad → clSnap snap tagP icture alert → ε	(2.8)
		| SIGN U P spAscr	(2.5)
	br 6 :	check → ε
	2.5.3.2 Crowdsourced road maintenance activity
	If we reconsider the crowdsourcing activity described on figure 2.3,
	• Any Sensor, can snap an object, in a predefined context (state of the object)
	2.5.3 Tasking model use cases and (geographic) location (clSnap) on the one hand or quite simply according

2.5.3.1 Issuing civil status certificates

Reconsider the e-administration application for issuing civil status certificates, described on figure

2

.3, • br 2 : normAscr → T RAN SCRIP T ION dcl br 3 : spAscr → T RAN SCRIP T ION sDcl judgment br 4 : reading → CORRECT dcl (2.4) • Lastly according to rule (2.5), a CsOfficer is responsible of issuing civil status certificates and certain checks. Checks rules are not yet expressed and may be done later. br 5 : csDelivrance → SIGN U P normAscr to the circumstances of the moment (snap), following business skills expressed by business rules in (2.6).

Ph.D thesis in Computer Science -University of Douala (2022)

https://www.haskell.org Ph.D thesis in Computer Science -University of Douala (2022)

In practice, an interface used as an implementation can define additional services: R

is a implementation low of the R 1 interface, in notation R 1 ≤ w R 2 , if R • 2 ⊇ R • 1 and R 1 ≤ R 2 (R • 1 ). However, the additional services provided by R 2 must be masked so that they cannot conflict with the services in any environment compatible withR 1 .Ph.D thesis in Computer Science -University of Douala (2022)

The uniqueness comes from the fact that we only consider finite paths due to acyclicity.Ph.D thesis in Computer Science -University of Douala (2022)

Safely composability is the natural extension to the non-determinstic case of the composability of deterministic interfaces. However since we first defined the operation of composition of nondeterministic (quasi-) interfaces we felt obliged to add this qualifying term.Ph.D thesis in Computer Science -University of Douala (2022)

Acknowledgements iii

Dedication iv Introduction

DEDICATION

To the DJATCHA's My late dad(Jean-Marc), mum(Louisette), all sisters and brothers; AND TO the DJEUMEN's Elisabeth Reine, Axel, Lucas, Noemie and Florin.

the elements of this path, except the first one, A, belong to R • . Proposition 3.4.1. The composition of the interfaces is associative. More precisely, if R 1 • • • R n are interfaces that can be pairwise composed, then

Proof. Using the commutativity of composition, the proposal follows by induction on n as soon as it was verified that (R 1 ◃▹ R 2 ) ◃▹ R 3 = ⟨R 1 ∪ R 2 ∪ R 3 ⟩ for interfaces that can be composed in pairs R 1 , R 2 and R 3 . So we have to show

The following two cases of composition are to be distinguished: the cascaded product and the direct product.

Cascade product

Let R 1 and R 2 two composable role interfaces, as stated in definition 3.4.1. If

for {i, j} = {1, 2} and the following conditions are equivalent:

• R 1 is a restriction of R: R 1 = (R • 1 ), and

Proof. By the remark 1 (A, B) ∈ R ◃▹ R i if and only if there is a finite sequence

Proof. By the proposal 3.6.1 and the lemma 3.6.

The opposite direction follows by the lemma 3.6.3 and the proposal 3.6.1:

As a corollary 3.6 the above proposal implies that an implementation of a strict residue R ↙ R 1 is a strict component of R and therefore cannot capture all the components of an implementation of R, i.e. all interfaces

To do this, we must add to the residue all dependencies between the respective outputs of the component and the residue that do not contradict the dependencies in R:

then by the remark 1 there exists a sequence A 0 , . . . , A n such that

Ph.D thesis in Computer Science -University of Douala (2022)

Proof. Note that if the sequence does not contain any transition of the latter category, it then witnesses the fact that

We're going to phase out all transitions of type (3). To do this, let us consider the leftmost transition that belongs to this type if it exists.

Thus, i is the smallest index such as

And so by replacing the sequence σ by the transition (A, A i ) we get a sequence with a transition less R ↗ R 1 and thus we end up with a sequence without transition

Proof. By lemma 3.6.5 and lemma 3.6.

The converse direction follows by lemma 3.6.7 and lemma 3.6.6:

Introduction

The concept of role is central in any collaborative or cooperative system. This importance is motivated by the fact that each contributor must have a clear framework within which he collaborates with other contributors. In this context, a role specifies both what the system expects from contributors, but also what contributors expects from the system; thus avoiding that a contributor be overwhelmed by information (or tasks) that he doesn't need. Traditionally, collaborative systems lose flexibility as soon as their design makes use of roles; because only static role description mechanisms, based on intuitive concepts, are available [START_REF] Zhu | Role mechanisms in collaborative systems[END_REF][START_REF] Bögel | A role model-based approach for modelling collaborative processes[END_REF]. Indeed, a dynamic context of collaboration further complicates a design of such systems, since involved entities evolve over time in number and in skills. An improvement would be to provide two things: firstly being able to specify roles clearly and rigorously, while ensuring flexibility for collaboration, and secondly provide an abstraction basis, for dynamic collaborative system design with tools for dynamic workflow management; in order to make collaboration more productive and effective. This design approach is repeated until all the activities obtained are atomic [START_REF] Caetano | Business process decompositionan approach based on the principle of separation of concerns[END_REF]. For this, the associated workflow must be factorized; if at the end of this, F -collaborations exist, that means the activity is decomposable, according to the principle described by the algorithm 5.

Proposition 4.4.2. Consider activity s 0 = (s 0 , workf low 0 (s 0 , R)) and activity ′ s 0 = (s 0 , workf low 1 (s 0 , R)) two activities, where activity s 0 ≡ activity ′ s 0 . activity s 0 is decomposable to activity ′

Proof. As the two activities are equivalents by hypothesis, the demonstration is equivalent to show that a in a workflow, several collaborations for given service, is equivalent to an F-collaboration on the same service; and this is done by definition 4.3.1.

1 input: C ′ //factorized workflow of the activity . 2 output: C //set of potential atomic workflows.

Algorithm 5: Atomic decomposition of an activity's workflow

CONCLUSION AND PERSPECTIVES

Summary of thesis achievements

At this point of our dissertation, let us recall that the initial problem was to formalize a role-based approach for the design of business collaboration processes in a dynamic context where recurrent reorganization of work within collaborative structures occur, but also the need of incrementally integrating particularly heterogeneous sectors of activity in the collaboration. Our approach made a clear separation between contributor capabilities (intrinsic skills) and what he does in a collaboration (business role). Considering all roles involved in a particular context of collaboration offers a formal basis for reasoning. As there are mainly two goal-oriented collaborative approaches, we focused on servicing collaboration types and we benefited from the GAG formal framework, the collaboration processes description mechanisms. We improved GAG by adding three extension elements, namely: (1) a tasking model making it possible to describe a design for services provision without ambiguity and for any form of business collaboration process. (2) a notion of role interface, as an integration of single responsibility and interface segregation principles in GAGs, thus offering flexible mechanisms for services composition. (3) A role-based design approach, which is a form of user-centered approach, with roles assigned to each contributor in the process. Thus a contributor is perceived both in terms of its intrinsic skills and the role he plays in the collaboration. This approach allows us to monitor and manage all the roles present in a given context, to substitute roles, to compose them, in order to choreograph a given activity.