Successfully reported this slideshow.
Your SlideShare is downloading. ×

Cari2020 Rodrigue Aimé Djeumen Djatcha

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 28 Ad

More Related Content

Similar to Cari2020 Rodrigue Aimé Djeumen Djatcha (20)

More from Mokhtar SELLAMI (15)

Advertisement

Cari2020 Rodrigue Aimé Djeumen Djatcha

  1. 1. A role-based collaborative process design on crowdsourcing systems Rodrigue Aimé Djeumen Djatcha Faculty of Sciences, University of Douala, Cameroon LIRIMA FUCHSIA Team CARI’2020 African Conference on Research in Computer Science and Applied Mathematics Polytech School of Thiès, Senegal October 2020 R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 1
  2. 2. Case study: crowdsourced road maintenance activity Consider a city participatory management case, with five stakeholders categories involved: 1 Citizens (BOB, JANE, ALICE,...) provide information on the state of city roads and determine which ones to maintain as priority; 2 Urban Information System (URBANIS), an infrastructure dedicated to collect, store, process and broadcast information city wide; 3 Cleaning Company (CLEANING_CO), in charge of road cleaning, waste management,...; 4 Road maintenance company (ROAD_CO); 5 City council (DOUALA1), made up of elected representatives in charge of city management. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 2
  3. 3. A targeted road maintenance activity, with participation of all stakeholders, can be carried out by the process depicted below each stakeholder has both infrastructure mechanisms and functional goals in the system, namely: BOB, JANE, ALICE infrastructures, offer SENSOR and CITIZEN functionalities, URBANIS infrastructure offer IS functionality, CLEANING_CO infrastructure offer CLEANER functionality, ... R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 3
  4. 4. The process described above takes place on a collaborative system context having various characteristics: 1 There is a clear separation between stakeholder’s infrastructure mechanisms and functional goals, infrastructure mechanisms simply termed actor, describes intrinsic skills; functional goal termed role describing business skills. 2 each actor can play one or more roles to provide precise services, 3 multiple instances of the same role could exist in the process (i.e. different ways of providing same services), 4 several actors (the crowd) can play the same role instance, then services provided are crowd services, 5 service calls may not be hierarchically organized. Such a system is a crowdsourcing system, as it is a set of multi-skilled independent stakeholders which potentially provide precise services on request. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 4
  5. 5. Problematic A crowdsourcing system can be seen both as: a software architecture style, inspired by service-oriented architectures, but with service calls not often hierarchically organized, that allows you to build an application by assembling a suite of small services, or organized groups of services (roles). a set of services, interacting in a dynamic context, for solving a given problem. In such a system, the concept of role is central because, each actor involved must have a clear framework within which to collaborate with other actors. The role specifies both what the system expects from a stakeholder, but also what a stakeholder expects from the system, thus avoiding access to information (or tasks) that are not necessary. But... Traditionally, collaborative systems lose flexibility as soon as their design is role-oriented, because only static role description mechanisms, based on intuitive concepts, are available. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 5
  6. 6. Solutions The problem, is solved in four steps: 1 defining clearly what an outsourceable task or crowd task is, by introducing a crowdsourcing tasking model, 2 specify roles clearly and rigorously, while ensuring flexibility for collaboration, this is achieved by the interfaces of roles concept, 3 providing role switching mechanisms, 4 providing an abstract basis, for crowdsourcing system design and workflow monitoring and checking mechanisms. Goal Being able to partially or completely specify crowdsourcing system processes, by means of roles involved in a given context. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 6
  7. 7. Outline 2 Grammatical tasking Model specification Role, Business skills Crowd tasks, Crowd Role Interface of role Basic operations on role interface 3 Collaboration, collaboration schemes and Workflows 4 Activity in collaborative context 5 Actor of a crowdsourcing system 6 Conclusion R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 7
  8. 8. Specifying Role (r) & Business skills (G) A role r is given by a couple (G,R) where G is a guarded attribute grammar (GAG) specifying role r business skills, R it’s associated interface of role. Business skills are expressed as grammar production rules (or business rules), describing job decomposition, in the form s0 → T0···Tm s1 ···sn s0 ···sp (1) where: s0 is a defined service, T0···Tm are intrinsic skills, s1 ···sn are used services, s0 ···sp are crowd tasks or crowd services. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 8
  9. 9. Crowd tasks (si) & Crowd role specification Crowd tasks are defined by business rules like si → T0···Tm (0 ≤ i ≤ p) i.e they are type of services requiring only intrinsic skills, to be carried out and so, they are autonomous services. Consider a business rule s0 → T0···Tm In fact s0 is a potentially outsourceable task, it can be defined and used in the same role (or used by another role); rather s0 is an outsourced task, so it is only defined in an autonomous role, term crowd role, and only used by a requester role. By convention, a crowd role is autonomous and only define outsourced tasks, and we say a crowd role supply only crowd services. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 9
  10. 10. Interface of role (R) An interface of role R is an abstraction of a role r business skills as a tuple (•R,R,R•), specifying services provided (R•) by r, which external services are required (•R) to carry them out and the potential dependencies between required and provided services (R). As an example, an Information System (IS) basically collect, store, process and broadcast information among the city. It can be orchestrated on request (req) to conjointly select a targeted road for maintenance, using business skills: selectRoad → COLLECT STORE PROCESS BROADCAST req clSnap tagPicture selectRoad → PROCESS BROADCAST req snap tagPicture alert → ε (2) with associated interface of role •IS = clSnap,snap,tagPicture,req IS = (clSnap,selectRoad),(snap,selectRoad),(tagPicture,selectRoad),(req,selectRoad),(_,alert) IS• = {selectRoad,alert} (3) R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 10
  11. 11. Role interface basic operations Let R1 and R2 be two interfaces of roles, associated to roles r1 and r2 respectively and O a given subset of services. Three basic operations on interfaces are define below: Restriction ( ): R1 O reconfigure role r1 so that, only its provided services elements of O are enabled; useful when just some skills of a multi-skilled role are needed. Cascade composition test ( , ): cascade composition of roles r1 and r2 holds iff R• 1 ∩ •R2 = /0∧•R1 ∩R• 2 = /0. We denote R1 R2 their cascade product test (or R2 R1 since this operation is commutative). Direct Product(×) consider R1 and R2 two composable role interfaces. If R• 1∩•R2 = /0 and R• 2 ∩•R1 = /0 , the composition is the (direct) product of R1 and R2, denoted by R1 ×R2. Note that R1 ×R2 = R1 ∪R1 and so •(R1 ×R2) = •R1 ∪•R2 and (R1 ×R2)• = R• 1 ∪R• 2. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 11
  12. 12. Outline 2 Grammatical tasking Model specification 3 Collaboration, collaboration schemes and Workflows Defining role collaboration Collaboration schemes Workflow of a service Workflow factorization 4 Activity in collaborative context 5 Actor of a crowdsourcing system 6 Conclusion R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 12
  13. 13. Defining role collaboration A role r1 = (G1,R1) potentially depends on a role r2 = (G2,R2) iff R1 R2 holds; and •R1 ∩R• 2 are services provided (or required) in that dependence. Two roles r1 and r2 are in a direct collaboration iff r1 potentially depends on r2 or r2 potentially depends on r1 (i.e. R1 R2 or R2 R1), and we denote (•R1 ∩R• 2 ,r2,r1) resp. (•R2 ∩R• 1 ,r1,r2) that collaboration, labeled by •R1 ∩R• 2 , the set of services for which r1 and r2 collaborate, r1 being the services requester (resp. provider), r2 is the provider (resp. requester) of those services. r1 and r2 will be in an indirect collaboration iff ∃rk = (Gk ,Rk ) such that R1 Rk R2 holds. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 13
  14. 14. Collaboration schemes Consider a reasoning context R below, in which each role ri is member with associated interface Ri (0 ≤ i ≤ 6) For a given role rk in the context, it’s potential direct collaborations rPDG(rk ,R) can be processed as follow rPDG(rk ,R) | rk = ri = if Rk Ri then rPDG(rk ,R/{ri })∪{(•Rk ∩R• i ,ri ,rk )} | rk == ri = rPDG(rk ,R/{ri }) such that rPDG(r3,R)= {({x},r0,r3), ({x},r4,r3), ({t},r2,r3), ({w},r1,r3)} R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 14
  15. 15. The induced potential dependencies graph (iPDG) or collaboration scheme of that context, is then processed as iPDG(R,R ) = if (ri in R) and (R = /0) then rPDG(ri ,R ∪R ) ∪ iPDG (R {ri },R ) with iPDG(R, /0) = {({a},r5,r0),({m},r6,r4),({y},r0,r2), ({z},r1,r2),({w},r1,r3),({x},r4,r3), ({x},r0,r3),({t},r2,r3)} (4) R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 15
  16. 16. Potential workflow of a service From the context R depict by collaboration scheme iPDG(R, /0), an induced workflow of a service, describes how this service will be issued and which roles are involved. For instance, workflow of service u is given below: workflow({u},R) = { (x,r4,r3),(x,r0,r3), (t,r2,r3),(m,r6,r4), (a,r5,r0),(y,r0,r2),(z,r1,r2)} R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 16
  17. 17. A collaboration scheme may include several alternatives in supplying the same service. In a given context, factorizing is being able to transform cases such as for a role r3, requesting service x, so that we have service x potential suppliers list; An F −collaboration is a triplet (•R0 ∩R• 1 ,{r1,···rm},r0), where r1,···rm are potential providers of services elements of set •R0 ∩R• i (1 ≤ i ≤ m) and r0 is the requester for those services (with •R0 ∩R• 1 = ··· = •R0 ∩R• m). A factorized collaboration scheme is then a potential dependency graph, possibly consisting of collaborations (i.e (•R0 ∩R• 1,r1,r0)), and F −collaborations ((•R0 ∩R• i ,{r1,···rm},r0)) if necessary. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 17
  18. 18. Outline 2 Grammatical tasking Model specification 3 Collaboration, collaboration schemes and Workflows 4 Activity in collaborative context Activity: definition and some properties Decomposition Realisability 5 Actor of a crowdsourcing system 6 Conclusion R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 18
  19. 19. Activity and some properties An activity for a given service s0, in a context R, is a couple activitys0 = (s0,workflow({s0},R)), viewed as supplying service s0, using by workflow({s0},R). Equivalence Two activities activitys0 and activitys1 are equivalent, and we denote by activitys0 ≡ activitys1 , iff s0 = s1 and workflow({s0},R) ≡ workflow({s1},R) i.e they deliver the same service in context R, by different ways. Atomicity An activity activitys0 = (s0,workflow(s0,R)) is atomic, iff for all (s0,ri ,rj ) and (s0,rk ,rj ) in workflow(s0,R), ri = rk . R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 19
  20. 20. Activity decomposition Consider below an E-administration activity for issuing civil status certificates The above activity can be broken down into two atomic sub-activities, representing individually the different possibilities of issuing a civil status certificate. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 20
  21. 21. An activity with associated factorized workflow C , can progressively be fragmented into a set of atomic activities C, decomp(C ,C) = forall c in C if |provider(c)| == 1 then //c is like (•R0 ∩R• 1 ,{r1},r0) decomp(C {c},insert(c,C)) else if |provider(c)| > 1 then //c is like (•R0 ∩R• 1 ,{r1,··· ,r|c|},r0) decomp(C {c},mdup(c,C)) 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. Consider activitys0 = (s0,workflow0(s0,R)) and activitys0 = (s0, workflow1(s0,R)) two activities, where activitys0 ≡ activitys0 . activitys0 is decomposable to activitys0 if and only if workflow0(s0,R) = workflow1(s0,R) and factorize(workflow0(s0,R)) = workflow1(s0,R) R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 21
  22. 22. Activity realisability Realizability refers to the possibility of carrying out an activity, in a finite number of stages, and rendering provided service. This assumes that all necessary roles are available instantly; we say it is a favorable context. Termination of an activity, is conditioned by the fact that its workflow must roles triggers. realizable(/0,_) = (True, /0) //the workflow is realizable realizable(Serv, /0) = (False,Serv) //not realizable, Serv are required services realizable(Serv,c ∈ C) | Serv ∩ label(c) == /0 =realizable(Serv ∪ req,C {c}) | Serv ∩ label(c) = /0 =realizable(Serv ∪ req,C {c}) where Serv = Serv (x ∈ Serv ∧ x /∈ label(c)) req = dependOn(label(c), provider(c)) An activity activitys0 = (s0,workflow(s0,R)) is quasi realizable, if at least one of its atomic forms obtained by decomposition, ends; i.e there is a C ∈ decomp(workflow(s0,R), /0) such that realisable({s0},C) = (True, /0); realizable, if all it’s atomic forms end; i.e. for all C ∈ decomp(workflow(s0,R), /0), realisable({s0},C) = (True, /0). R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 22
  23. 23. Outline 2 Grammatical tasking Model specification 3 Collaboration, collaboration schemes and Workflows 4 Activity in collaborative context 5 Actor of a crowdsourcing system Definitions and constraints Playing a role 6 Conclusion R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 23
  24. 24. Actor, definition and constraints An actor aτ is given by a couple (Rτ,Cτ), where Rτ is the set of potential roles that actor can play, and Cτ is the set of constraints on those potential roles. Let aτ = (Rτ,Cτ) an actor, ri and rj two roles; association between actor aτ and roles ri and rj is materialized by ri ,rj ∈Rτ. We will say for instance that ri ,rj are actor’s aτ potential roles. Four constraint values can be defined on actor’s potential roles: 1 Dcr or nothing for no constraint; 2 Imp (ri ,rj ) indicating that if actor aτ plays role ri , then he must also play role rj ; 3 Eqv (ri ,rj ) in case both Imp (ri ,rj ) and Imp (rj ,ri ) holds; 4 Phb (ri ,rj ) and so, actor aτ playing role ri , cannot play role rj . R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 24
  25. 25. Actor playing a role (a) Actor aτ playing two roles (b) Workflow simplified by the direct product of R0 and R1 (c) An actor involved in two parallel activities (d) Several actors playing same role r2 in an activity R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 25
  26. 26. Consider three primitives play aτ,{ri }1≤i≤|Rτ| ,activitys0 {cstrk }1≤k≤N indicating that aτ potentially can play roles {ri }1≤i≤|Rτ| in activity activitys0 , with constraints {cstrk }1≤k≤N ; play (aτ,ri ,activitys0 )cstrk to express that aτ potentially can play the roles ri in activity activitys0 , according to the constraint cstrk , with play aτ,{ri }1≤i≤|Rτ| ,activitys0 {cstrk }1≤k≤N = 1≤i≤|Rτ| play (aτ,ri ,activitys0 )cstrk play (aτ,Ri ,activitys0 ) expressing that aτ actually plays the role ri whose interface is Ri , in activity activitys0 "play" relationship play (aτ,ri ,activitys0 )Dcr = play (aτ,Ri ,activitys0 ) play (aτ,ri ,activitys0 )Imp(ri ,rj ) = play (aτ,Ri ×Rj ,activitys0 ) play (aτ,ri ,activitys0 )Eqv(ri ,rj ) = play (aτ,Ri ×Rj ,activitys0 ) or play (aτ,Rj ×Ri ,activitys0 ) play (aτ,ri ,activitys0 )Phb(ri ,rj ) = play (aτ,Ri ,activitys0 ) and not play (aτ,Rj ,activitys0 ) (5) R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 26
  27. 27. Conclusion and perspectives This work is a prelude to a role-based design approach, for distributed collaborative systems. An immediate continuation is to reconsider a more complex system, as co-creative and innovative crowdsourcing systems, i.e a context where there are no pre-established rules, clarify conception of those type of processes, and describe interactions between actors. R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 27
  28. 28. Thanks for your attention R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 28

×