CHAPTER 6. CONCLUSIONS AND OUTLOOK
3. P ERSPECTIVES
3.1. Perspectives on the current solution and the prototype
In Chapters 3 and 4 we have discussed the concepts, goals and use of technologies for constituting the knowledge-based system to support the design of collaborative processes. The prototype of this system which has been developed consists of four tools. The principal functionalities provided by each tool have also been presented. However, the prototype is not yet complete due to the complexity of the approach, development concepts as well as technologies. Some limitations and perspective works are highlighted as follows:
The concepts, relations, and restrictions of the actual CNO as well as the deduction rules can be enriched. At the current stage, the deduction and extraction of knowledge from the KB (the second and third functionalities) bring out a quantity of knowledge that is related to the input collaborative situation. The first collaborative process model obtained from this generation is however really complex and hard to deal with (Fig.V.4). The improvement of the CNO and the rules may put more constraints on the deduction and make the deduction results more precise and exact. The rules can be improved at the concept levels of common goal, topology, and continuous and discontinuous relationships, which we have not significantly taken into account at this stage.
The generation of gateways and events defined in the third functionality is not yet complete. Up to now, this functionality can generate only the start and end events and four types of gateway (parallel, event-based exclusive, data-based exclusive and data- based inclusive gateways) which are frequently used in BPMN processes. We have not yet included for example, message event, time event, complex gateway, etc. Thus, we may need to enrich this generation concept by taking into account these missing elements.
The instances originally stored in the KB come only from the MIT Process Handbook. This makes our knowledge-based system and the collaborative process models generated from it limited. Thus, we need to enlarge the KB by storing more instances coming from other sources, such as collaboration use cases, creating new business services by partners from scratch, etc.
The prototype itself can be improved to be more user-friendly in terms of user interfaces, design concept, and functionalities. For example, at the current stage, the definition of roles is not yet provided which makes it hard for users to select a suitable one. The prototype should provide more human aids, such as a tool manual, ability to search or browse by keywords, tags, etc.
Even if the current prototype is made to be connectable to the Translator V1.0, these two tools have been implemented separately. The future work (starting PhD) will be to create a multi-view integrated framework in order to provide a loose approach (to avoid the tight aspect of the CIM-PIM-PSM drive).
These limitations are not easy to deal with and overcome rapidly. Some of them need to be investigated in detail. This investigation will lead to develop and open-up new visions for future work.
3.2.Event-based approach for improving the current solution of collaborative process definition
An event-based approach can be another way to improve our current solution. We can enhance our modelling mechanism by integrating this event-based approach to better define a collaborative process.
A collaborative process includes a set of services executed by several partners that take over specific roles. Our current solution deals with the service sequencing through the concept of dependency of resources between services. When we find two services where the service input of one is the same as the service output of the other, we link these two services together. Once we have obtained the dependencies we generate events. Although this solution takes into account the event aspect, this is not enough, as an event is an important aspect for making the process dynamic and flexible.
The fundamental concept in the event-based approach is, of course, an event. An event is a notable thing that happens inside or outside the enterprise [Michelson, 2006]. It can be defined as a significant change in the state of a system or an environment [Mani Chandy,
2006]. Coming back to our case, the event generation concept that we now use is based on the flow but not on the states of resources, conditions or trigger events which are the crucial patterns of event. We can adopt the event-based approach to improve our current event generation and service sequencing. The event patterns are described as event-condition-action (ECA) rules. For example:
Event: request by buyer to send materials
Condition: new purchase order is received and not yet processed (purchase order is in the received or non-processed state)
Action: send purchase order to the delivery service (purchase order is in the processed state)
The ECA rule can be expressed as follows: when event is produced, if condition is satisfied, then action will be performed [Bouslimi et al., 2008]. The implementation of such an event- based approach may impact on the work of this dissertation. The generated collaborative process models will be more dynamic, complete and concrete because we will take into account the event patterns during the design of the collaborative processes. When new events happen or change the collaborative process definition changes accordingly. Thus, this approach may offer flexibility to our current solution.
3.3.Mapping identified services on the obtained BPMN collaborative process and real