Project IST SUPER Semantics Utilized for Process management within and between Enterprises. Deliverable 8.3

Transcription

1 Project IST SUPER Semantics Utilized for Process management within and between Enterprises Deliverable 8.3 Life-Cycle Tools deployment report Leading Partner: TP Contributing Partner: Nexcom Security Classification: Public (PU) October, 2008 Version _SUPER_D8 3_V2_ES.doc PUBLIC Page I

2 Project Details IST Project Number Acronym Project Title Project URL EU Project Officer SUPER Semantics Utilised for Process management within and between EnteRprises Werner Janusch Authors (Partner) Zlatina Jordanova (Nexcom), Hanna Kupidura (TP), Ewelina Szczekocka (TP) Deliverable Owner (Partner) Ewelina Szczekocka (TP) Phone _SUPER_D8 3_V2_ES.doc PUBLIC Page II

3 Versioning and Contribution History Version Description Comments 0.1 Initial Draft TP 0.2 Contribution of Nexcom and TP first version Nexcom, TP 0.3 Integrated version Nexcom, TP 0.4 Pre-review comments included TP 0.5 Peer review comments included Nexcom, TP 0.6 Peer review final comments included Nexcom, TP 0.7 EPMB review final comments included Nexcom, TP 1.0 Finalised document for M24 review TP 1.1 Review comments realisation Nexcom, TP 1.2 OU and TID comments included Nexcom, TP 1.3 EPMB review final comments included TP 2.0 Finalised document for resubmission TP _SUPER_D8 3_V2_ES.doc PUBLIC Page III

4 Table of Contents Executive summary 1 Deliverable alignment 1 Ontology stack alignment 1 Modelling Stack Alignment 1 Methodology alignment 2 1 Introduction Organization of the deliverable 6 2 Tools Requirements Analysis Modelling Tool Requirements Analysis Tool Requirements YATOSP Perspective Requirements SBP Modelling Tool SBP Monitoring and Management Tool SBP Analysis Tool 12 3 Life-cycle Tools Deployment Deployment of the Modelling Tool Using the Modelling Tool Modelling Tool Usage Composer Usage Deployment of the Analysis Tool Using the Analysis Tool 27 4 Analysis of the Life-Cycle Tools Use Analysis of the Modelling Tool Use Analysis of the Analysis Tool Use Refinement Requirements for Tools and YATOSP Developers 36 5 Conclusions 40 6 References 42 7 Appendix _SUPER_D8 3_V2_ES.doc PUBLIC Page IV

5 Index of Figures Figure 1 SUPER Modelling Stack 2 Figure 2: Importing BPMO Diagram into a Project 14 Figure 3: Selecting a BPMO file to be used in WSMO Studio 15 Figure 4: Selecting a process fragment to be used in WSMO Studio 16 Figure 5: Creating a new Project 17 Figure 6: Creating a new BPMO process model 18 Figure 7: Preparing a process flow using building blocks from the Palette 20 Figure 8: Annotating task properties with ontology elements 21 Figure 9: Visualising a semantic description of a business process model 22 Figure 10: Adding Non-functional parameters and Constraints 23 Figure 11: Modelling environment with BPMN diagram and task sequence for composition 24 Figure 12: Business goals to be edited by an analyst in user friendly manner 25 Figure 13: Message after the composition for selected task is accomplished 26 Figure 14: Services found by The Composer to substitute the task in the BPMN diagram 27 Figure 15: Upload of a log file 28 Figure 16: Filtering logs 29 Figure 17: Choosing an exact analysis type 30 Figure 18: Process Mining 30 Figure 19: Conversion and Exports menu 31 Index of Tables Table 1: Tools with functionalities designed by tool developers 5 Table 2: Realisation of the modelling requirements 34 Table 3: Realisation of the Composer requirements 34 Table 4: Realisation of YATOSP requirements 35 Table 5: Realisation of the Analysis requirements 36 Table 6: Refinement requirements for the Modelling Tool 37 Table 7: Refinement requirements for the Composer 38 Table 8: Refinement requirements for the Analysis Tool 38 Table 9: Refinement requirements regarding YATOSP 39 Table 10: Components and Ontologies Required by Use Case Partners _SUPER_D8 3_V2_ES.doc PUBLIC Page V

6 Table of Acronyms Acronym BP BPEL BPEL4WS BPEL4SWS BPMO ESB etom EVO GUI JMS MOM NGOSS OSS/J SA-MXML SBP SBPA SBPC SBPE SBPM sbpel SBPELEE SEE SID srbe SSB SWS TAM TMF UML WSML YATOSP Description Business Process Business Process Execution Language BPEL for Web Services BPEL for Semantic Web Services Business Process Modelling Ontology Enterprise Service Bus extended Telecommunications Operations Map Events Ontology Graphical User Interface Java Messaging Service Message Oriented Middleware New Generation of Operation Support Systems Operation Support System Through Java Initiative Semantically Annotated Mining extensible Markup Language Semantic Business Process Semantic Business Process Analysis Semantic Business Process Configuration Semantic Business Process Execution Semantic Business Process Modelling Semantic BPEL Semantic Business Process Execution Engine Semantic Execution Environment Shared Information Domain Semantic Reverse Business Engineering Semantic Service Bus Semantic Web Service Telecommunications Application Map Telemanagement Forum Unified Modelling Language Web Service Modelling Language Yet Another Telecommunication Ontologies, Services and Processes framework _SUPER_D8 3_V2_ES.doc PUBLIC Page VI

7 Executive summary In the deliverable we deploy tools and vertical ontologies across the Business Process Life Cycle and describe results of the deployment. Some tests, that were provided, were limited to the Modelling and Analysis tools, used by use case partners engaged in the report delivery. Representing end users, we have some requirements that the tools and meta-models should fulfil to satisfy our needs. We give feedback information of deployment to tools and YATOSP developers, hoping that it helps to adapt tools and ontologies yet more appropriately, if it is necessary. A future follow-up of the deliverable could provide more information about tools including those ones dedicated to other BP Life Cycle phases. Deliverable alignment Ontology stack alignment In the context of tools deployment we focus on the usage of the following set of ontologies, relevant for the use case development: Business Process Modelling Ontology (BPMO) for the purpose of annotating the terms from the common business area; the BPMO ontology is integrated with the Modelling Tools; YATOSP a framework of telecommunication domain ontologies, including semantic descriptions of industry specific concepts, herein telecom ones, as well as concepts based on Telemanagement Forum standards (NGOSS) [1], concerning business functions and information model. Those ontologies are used to annotate specific processes and services within the telecommunication domain. Modelling Stack Alignment This deliverable is concerned with tools corresponding to the second level: the Modelling Tool (see Figure 1) as it is concerned with process model designing, and to the third level: the Analysis Tool, as it is concerned with retrieving information on executable models from Execution History _SUPER_D8 3_V2_ES.doc PUBLIC Page 1

8 Figure 1 SUPER Modelling Stack Methodology alignment The SUPER methodology defines a Business Process Life Cycle (BP Life Cycle) in respect of semantics and business requirements in relation to SUPER tools and ontology stack. In this document we take into account Business Process Life Cycle in relation to the SUPER tools, from the Nexcom and TP use cases perspective: Nexcom use case is mapped to the last two phases of BP Life Cycle: Semantic Business Process Execution (SBPE) Semantic Business Process Analysis, including Monitoring (SBPA). TP use case covers the first two phases: Semantic Business Process Modelling (SBPM), Semantic Business Process Configuration (SBPC) _SUPER_D8 3_V2_ES.doc PUBLIC Page 2

9 1 Introduction The analysis provided in the document is dedicated to tool and YATOSP developers. The use case partners, as End-users of the solution proposed, have given their comments as a feedback: how they find the functionality, is it really needed and important for an everyday work of enterprises using as a basis business processes and flows, what is the most important functionality from their point of view. We realise that the solution is a prototype, not a fully commercial product. We focus then mainly on checking if technologies work together and if they are able to provide the most important functionalities, necessary to process automation across the Business Process Life Cycle. We intend to depict briefly tools that SUPER will offer in each of the BP Life Cycle phases, and we focus on the tools considered by the deliverable. The functionality depicted in the table below is described in the relevant deliverables (see references). SBP Modelling Phase Tool Name The Modelling Tool Functionality design business process models creating semantic business process descriptions from scratch; enriching existing process with semantic annotations using ontologies import process models from other tools using serialisation to standard notations import BPMO processes provide GUI for end user and invoke other tools like Execution tools, Analysis tools and other tools Components: Composition; Discovery; Data Mediation; Process Mediation; Transformation. SBP Discoverer process fragment detection identification of reusable process fragments within the BPMO process description; process fragment discovery covering the goal based matchmaking according to a set of user criteria based both on static as well as behavioural aspects. This request is then matched to descriptions of process fragments from the BP Library and a ranked list of fragments meeting user criteria is returned to a user as a result, for his acceptance ; _SUPER_D8 3_V2_ES.doc PUBLIC Page 3

10 autocompletion functionality enabled by a user to complete a process model with fragments from the BP Library; in result a list offered with possibility of selection the most suitable process fragment/model to include into the designed model; process fragment substitution - functionality supporting replacement of a selected process fragment with another one e.g. corresponding to the new process redesign goals. SBP Configuration Phase Tool Name SBP Composer Functionality task composition implementation of a task by SWS composition based on WSMO goal attached to the task and a context information from SBP; as result: BP fragment with SWS bound to the tasks; SBP composition binding tasks of BP models to services from implementation level; as result: a refined process model with all tasks bound to Web Services, reflecting the structure of the original process; SBP fragment composition a completion of missed sub-processes on the basis on their semantic descriptions; a function similar to the task composition, but regarding process fragments instead of single tasks; validation provided on BP level, as process fragment is context-sensitive, i.e. it depends on a whole process; validation and process reparation check of executable process models upon correctness and consistency. SBP Execution Phase Tool Name Semantic Execution Tools: SBPELEE SEE Service Requester Functionality convert a process model to the executable formats: first sbpel (expressed in sbpel ontology) and next serialised into BPEL4SWS executable; deployment of executable process on the Execution Engine (SBPELEE), where it is ready for instantiation and execution; binding of processes using SWS (SEE); execution support. SBPELEE instantiation; achieving SBP instances using SBP Reasoner. SEE SWS discovery and selection discovering SWS services that meet requirements (functional and non-functional) of a requester; _SUPER_D8 3_V2_ES.doc PUBLIC Page 4

11 SWS mediation and invocation required to ensure seamless interactions between a service requester and SWS selected, if needed; realised through conversational message exchange and data mediation) - data mediation when process instances annotated by different data models (ontologies) need to interact with each other; data mediation mappings are defined during design time; - BP mediation a component allowing an interaction of processes from different organisations (partners), particularly in case of behavioural incompatibilities; added by Business Analyst at design time. Service corresponding to the user that requests to achieve a SBP task Requester SBP Analysis Phase Tool Name Monitoring and Management Tool Functionality two types of monitoring - active real time monitoring, providing status of processes at execution time; - passive reports and information feedback on a user request; it gives detailed information on a process, its instances and particular activities. three perspectives - process view; - resource view; - object view statistics useful for checking the performance of BP and its elements Analysis Tool Semantic Reverse Business Engineering tool allowing a creation, classification and execution of BP questions; making a selection of relevant business questions from the set available in Business Questions Repository, according to user criteria; Semantic Process Mining Tool tool allowing an automating discovery of information from event logs (Execution History); it contains seven different plugins. Table 1: Tools with functionalities designed by tool developers Tools taking into account in the deliverable are the scope of workpackages: WP3, WP5, WP6 and WP8. The workpackages concern the following areas of SUPER technology: WP3 Semantic Composition [2] and Discovery [3]; WP5 The Modelling Tool [4] and Analysis Tool [5]; and WP 6 for Process Mining prototype [6]; _SUPER_D8 3_V2_ES.doc PUBLIC Page 5

12 WP8 domain [7] and industry-specific ontologies [8]. Domain ontologies were created on the basis of Use Cases - their concepts concern terms used in Use Cases. Industry-specific ontologies were created on the basis of TeleManagement standards - mentioned above NGOSS, particularly etom and SID standards, respectively for business functions and data model. A manual for the Modelling Tool is accessible in the Internet as well, at the link [9]. Information on the tool is also included in [4]. There are several recorded demos on usage: - modelling [10], - configuration [11] - epc-import [12] - the bpmo editor (concerning one of the previous versions) [13]. The latest installation version of the modelling environment can be found at [14] (ver for the purpose of the document). The latest version of the Analysis Tool can be found at [15]. The information on the tool usage is included in [5] Organization of the deliverable The deliverable presents in Section 2 use case partners requirements related to the SUPER tools: Modelling Tool (including the Composer) (sub-section 2.1) and the Analysis Tool (sub-section 2.2). The work is mainly based on Nexcom and TP experiences, supported by some Telefonica and etel contributions. Next, in sub-section 2.3, we present requirements related to YATOSP [8]. The second part of the deliverable concerns the deployment (section 3) and analysis (section 4) of the tools indicated. First of all, we explain how to install the tools, next we describe what we have done to test the requirements, i.e. how the tools were used. Finally we provide an analysis of the results of the tests, deriving some conclusions that aim at providing useful feedback to both tools and YATOSP developers _SUPER_D8 3_V2_ES.doc PUBLIC Page 6

13 2 Tools Requirements Analysis In this section we present a set of requirements to the SUPER tools that are indicated as important for use cases development. These requirements concern the Modelling Tool (including the Composer functionality) and the Analysis Tool. We are going to evaluate these requirements by making use of the tools with the vertical ontologies: NGOSS (particularly etom and SID ontologies) as well as TP and Nexcom use case ontologies. These evaluations will derive some conclusions about what is accomplished or not with current version of the tools (i.e: pros and cons of the tools). For each requirement we include: A requirement identifier to be used across the document (i.e. REQ.MOD.001 means Requirement number 001 for the Modelling Tool), A textual description, Criticalness of the requirement. We use the Moscow notation [16]: MUST, SHOULD and MAY. MUST means obligatory functionalities, SHOULD functionality that is demanded from the usability point of view, MAY is optional. 2.1 Modelling Tool Requirements Modelling of processes REQ.MOD.01 (expressed by TP): The Modelling Tool MUST support importing of existing processes modelled in BPMN in other tools, which serialise them to standardised formats. REQ.MOD.02 (expressed by TP): The Modelling Tool SHOULD validate process models being imported. REQ.MOD.03 (expressed by TP): The Modelling Tool SHOULD support importing semantic descriptions of process models modelled in other notations. REQ.MOD.04 (expressed by TP): The Modelling Tool MUST allow the easy and intuitive creation and edition of process models. REQ.MOD.05 (expressed by TP): The Modelling Tool MUST support a user in adding semantic annotations to a process using existing domain and industry-specific ontologies. REQ.MOD.06 (expressed by TP): The Modelling Tool MUST allow the categorisation of process models according to business function, business resources and business units they correspond to. REQ.MOD.07 (expressed by TP): The Modelling Tool SHOULD hide the complexity of WSML representation of a process to the user. REQ.MOD.08 (expressed by TP): The Modelling Tool SHOULD support a user in the creation of modification of domain ontologies used to annotate a process _SUPER_D8 3_V2_ES.doc PUBLIC Page 7

14 REQ.MOD.09 (expressed by TP): The Modelling Tool MUST support linking business process models to the existing IT infrastructure (Semantic Web services). REQ.MOD.10 (expressed by TP): The Modelling Tool SHOULD inform the user if linking a business process model to the existing IT infrastructure is impossible i.e. there is no semantic Web service implementing the defined goal (taking into account the non-functional properties). REQ.MOD.11 (expressed by TP): The Modelling Tool SHOULD support specification of non-functional properties of tasks modelled within a process as well as for the entire process. REQ.MOD.12 (expressed by TP): The Modelling Tool SHOULD support completing a business process model with fragments of already modelled processes depending on a process context. REQ.MOD.13 (expressed by TP): The Modelling Tool (taking advantage of the Analysis Tool) MUST support linking existing process models with their execution data (if any). REQ.MOD.14 (expressed by TP): Business goal editor of the Modelling Tool MUST allow editing preand post-conditions by selecting concepts from the list, operations, defining variables and assigning values /states. The functionality could be expressed in Interface by: dialog window with pre- and postcondition tabs, the tab contains editing area with concept /variable field (combo box), logical operations (combo box), value /state combo box, and add button. The list area contains all defined conditions, with remove and edit options. REQ.MOD.15 (expressed by TP): The Modelling Tool SHOULD give the possibility of visualising ontologies in main window. REQ.MOD.16 (expressed by TID): The Modelling Tool MUST be able to load BPMO files, and draw their corresponding BPMN diagram. REQ.MOD.17 (expressed by TID): The Modelling Tool MUST allow the definition of workflows in the process, allowing the use of any BPMN component defined by the standard. REQ.MOD.18 (expressed by TID): The Modelling Tool MUST present a list of possible attributes that can be annotated in the process and each task. These attributes MUST include the possibility to make domain and functional annotations, and SHOULD include all the organizational and YATOSP ontologies. REQ.MOD.19 (expressed by TID): The Modelling Tool MAY give the chance of selecting the ontologies you are using to annotate, allowing loading and unloading them. REQ.MOD.20 (expressed by TID): The Modelling Tool SHOULD ensure that any change in the ontologies used to annotate is refreshed, and thus taken into account. REQ.MOD.21 (expressed by TID): The Modelling Tool MUST provide mechanisms to change any annotation of the process or the tasks. REQ.MOD.22 (expressed by TID): The Modelling Tool MAY admit other formats apart from BPMO, such as XPDL, and transform them to BPMO _SUPER_D8 3_V2_ES.doc PUBLIC Page 8

15 REQ.MOD.23 (expressed by TID): The Modelling Tool MAY give the functionality to export a BPMO file to sbpel notation. REQ.MOD.24 (expressed by TID): The Modelling Tool SHOULD admit any subclass of bpmo#process, although extra information (new attributes) is not taken into account. This extra information MAY be showed in the editor. REQ.MOD.25 (expressed by TID): The Modelling Tool SHOULD enable the definition of abstract tasks in a process. It MAY enable the definition of abstract processes (patterns) as well. Requirements merged REQ.MOD.01.M Relevant requirements of Use Case partners REQ.MOD.01, REQ.MOD.22 Comment The requirements concern import process models from different notations. Both authors depict it in their requirements, but TP puts more stress on that. Composing of processes REQ.COM.01 (expressed by TP): The Composer MUST offer substitution of tasks in Business Process Model with corresponding Semantic Web Services on the basis of business goals assigned to the tasks REQ.COM.02 (expressed by TP): The Composer MUST run composition sequentially for the whole process (each task), available only if all tasks have business goals assigned (Compose cascade). The functionality could be expressed in Interface by: right-clicking on the Process Modelling Area and choosing the option (Req. concerning GUI). REQ.COM.03 (expressed by TP): The Composer MUST run composition for selected sequence of tasks, subsequence of the whole process, example: separate branch (Compose selected). The functionality could be expressed in Interface by: selection tool to group tasks (similar to grouping objects in graphic tools) right-click on the group and choosing the option (Req. concerning GUI). REQ.COM.04 (expressed by TP): The Composer MUST allow composing again a fragment of the process where goal in one of grouped tasks has changed, not a structure (Recompose) (Req. concerning GUI). REQ.COM.05 (expressed by TP): The Composer SHOULD return in result parallel branches (using End) for the parts of processes that could be executed in parallel (if any). REQ.COM.06 (expressed by TP): The Composer MAY return the result with alternative branches of a process (using XOR Split). REQ.COM.07 (expressed by TP): The Composer MAY continue work in a background and suggest different possibilities for composed task that it discovered after the first result was already returned _SUPER_D8 3_V2_ES.doc PUBLIC Page 9

16 2.2 Analysis Tool Requirements REQ.AN.01 (expressed by Nexcom): Analysis tool SHOULD be able to support different levels of discovery, i.e. to be able to derive information about the process model, organizational context etc.. REQ.AN.02 (expressed by Nexcom): Analysis tool SHOULD be able to support different notations in order to present the result information in suitable way (for example to able to provide different chart, graphics etc.). REQ.AN.03 (expressed by Nexcom): Analysis tool MUST have an option for adding different custom oriented plug-ins depending on the specific user. REQ.AN.04 (expressed by Nexcom): Analysis tool SHOULD allow only a selected part of the log to be analysed. REQ.AN.05 (expressed by Nexcom): Analysis tool SHOULD be able to identify the relations between the different participants in the business process. REQ.AN.06 (expressed by Nexcom): Analysis tool SHOULD be able to extract detailed hierarchical business process model over the logs from the execution of the process. REQ.AN.07 (expressed by Nexcom): Analysis tool SHOULD be able to reveal different groups in the model based on certain criteria (like people working on the same tasks or in the same department). REQ.AN.08 (expressed by Nexcom): Analysis tool SHOULD have validation functions over the process. REQ.AN.09 (expressed by Nexcom): Analysis tool MUST identify bottlenecks of the executed process. REQ.AN.10 (expressed by Nexcom): Analysis tool MUST function during the run time of the process without affecting it. REQ.AN.11 (expressed by Nexcom): Analysis tool SHOULD evaluate the efficiency and complexity of the business process (for example the time that takes from placing the request to the actual activation of the service or are there any activities that can be done simultaneously in order to shorten the process). 2.3 YATOSP Perspective Requirements In this section we define and present the SUPER tooling components, from YATOSP perspective and related requirements,. We establish tools relationship with YATOSP framework, in order to provide a guideline to implement a global SUPER framework. There is a bi-directional dependence between YATOSP and tools. From one side tools should be aligned with YATOSP and offer a range of functionalities allowing the optimal use of ontologies. From the other side, ontologies and their mutual relationships should be designed taking into account using information in the best possible way. In the previous sub-sections regarding tools we focus on the first aspect. Here we focus on the second aspect _SUPER_D8 3_V2_ES.doc PUBLIC Page 10

17 2.3.1 SBP Modelling Tool SUPER Business Process Modelling Tool (SBP Modelling Tool) makes use of the SUPER ontology stack to enable the annotation of semantic business processes. In order to make use of YATOSP ontologies to annotate telecommunication business processes both from a functional (etom) and domain (SID) perspective, it is necessary that the root concepts of these ontologies (etom_function and SID-Entity) extend BusinessFunction and BusinessDomain concepts of UPO ontology, respectively. Through these extensions, the SBP Modelling Tool is able to import YATOSP ontologies and allows the semantic annotations using YATOSP concepts. The SBP Modelling Tool should be able to use YATOSP business process patterns [18], and offer them to business analysts so that these patterns can be extended to create concrete business processes, which will be executed by SUPER execution infrastructure. These patterns should be available when they are stored in the business process repository. It is important to stress out that business process patterns are a special kind of business processes (they are abstract, and thus not executable), and therefore they can be treated by SBP Modelling Tool in the same way as business processes are. The SBP Modelling Tool, however, should provide a way to specifically retrieve business process patterns in order to effectively support the business process design. In summary the requirements that need to be implemented by the SBP Modelling Tool in relation to YATOSP are the following: REQ.YAT.01 (expressed by TID): Importing YATOSP Ontologies MUST be possible in order to annotate Semantic Business Processes using YATOSP concepts REQ.YAT.02 (expressed by TID): Query Interface to the SBP Repository SHOULD be accessible in order to locate YATOSP business process fragments REQ.YAT.03 (expressed by TID): Management Interface to the SBP Repository SHOULD be accessible in order to save YATOSP business process fragments for further reuse REQ.YAT.04 (expressed by TP): Extensions of etom and SID concepts with UPO ontology concepts MAY be provided REQ.YAT.05 (expressed by TP): Ontology mapping interface MAY be accessible to allow easy extending of ontology concepts (e.g. UPO with NGOSS concepts, NGOSS with Use Case concepts) SBP Monitoring and Management Tool The SBP Monitoring Tool is used, among other tasks, for gathering information about running process instances. The SSB provides a publish/subscribe infrastructure, which is used by the SBPELEE and SEE for publishing events during process execution. The monitoring tool can also query the Execution History. The Execution History provides a WSDL interface with corresponding operations. In contrast to event-based monitoring, querying can also access old events. On the other hand, SBP Analysis Tool analyses already executed process _SUPER_D8 3_V2_ES.doc PUBLIC Page 11

18 instances, with the goal to provide the necessary information to the user, who wants to optimize the process model. The service engines (SBPELEE and SEE) provide management interfaces. These can be used to retrieve information about services running inside these containers. For example, the SBPELEE management interface contains methods for listing the running process instances, getting the state of a particular process instance, aborting process instances, etc. The requirement regarding YATOSP and its link to the Monitoring Tool is: REQ.YAT.06 (expressed by TP): Some link between YATOSP ontologies and Monitoring phase ontologies MAY be provided in order to enable a control which of the chosen process models were executed and what results were achieved (errors, inconsistency problems etc.) SBP Analysis Tool SBP Analysis Tool targets the analysis of semantic process models, getting information from already executed process instances in a certain time frame and trying to find out how the process models could be optimised. This tool provides two functionalities: Process Mining and Reverse Business Engineering (RBE). Both functionalities are based on the audit data log in the Execution History. Process Mining functionality discovers (or mines) information based on the data logged in the Execution History. It discovers different perspectives (control-flow, organizational models, etc) that present how process models are actually being executed in SUPER. Process Mining requires the audit log data to be in the SA-MXML format. The purpose of semantic Reverse Business Engineering (srbe) is the scenario-based analysis of business processes and configuration of application systems in an automated process. The selection of business questions according to the scenario and other dedicated criteria is achieved by linking them to SUPER ontologies (e.g. Business Question Ontology or Organizational Ontology), and therefore it can also be linked to YATOSP Ontologies, which extends the SUPER Ontology Stack. Moreover, each business question is described by input parameters that can be specified with regard to an analysis and output parameters, which semantically describe the analysis results. This facilitates the formatting, interpretation, and comparability of analysis results. On the other hand, the general business questions have to be lifted to a semantic level by using Business Question Ontology. The requirement regarding YATOSP and its link to the Analysis Tool is: REQ.YAT.07 (expressed by TID and TP): YATOSP ontologies SHOULD be used to link their concepts with the business questions enabling linking execution data with existing process models _SUPER_D8 3_V2_ES.doc PUBLIC Page 12

19 3 Life-cycle Tools Deployment In this section we detail how we deployed and used the SUPER tools and the YATOSP platform in order to conduct the requirements validation, and to derive feedback for tools and YATOSP developers. 3.1 Deployment of the Modelling Tool The Modelling Tool installation and running The Modelling Tool, called WSMO Studio, can work in different environments, like Windows or Linux. It can be used in the standalone distribution or Eclipse-integrated (embedded mode). We have provided an installation of a standalone distribution in Windows environment. Installation of the Modelling Tool is a simple task. It can be provided in two different ways: - using WSMO Studio installer, that offers a Wizard; - without using WSMO Studio installer, just unpacking the product. We have used the second way. Then user should choose a folder to unpack the product. After this it is ready to use, by clicking on the wsmo-studio icon of executable application ( ). A shortcut on the Desktop can be created to make it even easier. After double-clicking the icon, we have WSMO-Studio operating. The Composer installation and running Installation of the Composer is very similar to the Modelling Tool installation. It is only necessary to unpack WSMO Studio and WSMX to any directory. Running WSMX is possible by double-clicking the start.bat icon in its home directory. When WSMX is running, then it is necessary to run WSMO Studio by double-clicking the wsmo-studio.exe icon in its home directory. 3.2 Using the Modelling Tool Modelling Tool Usage Importing BPMO processes We can import an existing BPMO process model to WSMO Studio in different ways: Drag and drop an existing file containing BPMO diagram into the Project folder in the window of Navigator; Copy a file containing BPMO diagram into the proper Workspace and Project folder (outside an application); Use a context menu in the Navigator _SUPER_D8 3_V2_ES.doc PUBLIC Page 13

20 We have chosen the third possibility to import a BPMO diagram: 1. We choose a proper Project in the Navigator and next use a context menu by clicking the right mouse button on the project name. 2. In the context menu we choose: New-> Other-> General-> File-> Next (Figure 2). Figure 2: Importing BPMO Diagram into a Project 3. We select the Advanced button in the window that opened and select the check box Link to the file in the file system. After selecting the check box we can point the file in the file system shown in window that has now opened (Figure 3). The file will be saved in the Project folder. From now it will be available for further refinement or semantic annotation _SUPER_D8 3_V2_ES.doc PUBLIC Page 14

21 Figure 3: Selecting a BPMO file to be used in WSMO Studio It should be also available a possibility to load a business process model from a repository, i.e. Business Process Library. Using process fragments Importing an existing process fragment to WSMO Studio is performed in the same way as import of a BPMO process model. 1. We choose a proper Project in the Navigator and next use a context menu by clicking the right mouse button on the project name. 2. In the context menu we choose: New-> Other-> General-> File-> Next (Figure 4). 3. We select the Advanced button in the window that opened and select the check box Link to the file in the file system. After selecting the check box we can point the file in the file system shown in window that has now opened (Figure 3). The file will be saved in the Project folder _SUPER_D8 3_V2_ES.doc PUBLIC Page 15

22 Figure 4: Selecting a process fragment to be used in WSMO Studio It should be also available a possibility to load a process fragment from a repository, i.e. Business Process Library. Designing process models from the scratch If we have a project (i.e. a folder), when we want to have process models grouped, then we simply have to start a new process model and indicate the project where the model will be placed. If there is no appropriate project, first we need to create it: 1. We use the following sequence of options: File-> New General->Project. 2. We double-click on a Project icon. 3. We must input a name of a new project name (Figure 5) _SUPER_D8 3_V2_ES.doc PUBLIC Page 16

23 Figure 5: Creating a new Project If we already have an appropriate project, then we must only create a new process model: 1. We use the following sequence of options: File->New->Semantic Business Process Models- >BPMO Diagram. 2. When we double click on the BPMO Diagram icon, then a window opens when we should indicate an appropriate project and input a name of a new process model (Figure 6) _SUPER_D8 3_V2_ES.doc PUBLIC Page 17

24 Figure 6: Creating a new BPMO process model Translator Usage To import a XPDL process model to the BPMO Modelling Tool the following steps need to be performed (REQ.MOD.01.M): 1. Import a process description in XPDL by right clicking on Project -> then choose New ->Other ->and specify the location of the XPDL file. 2. Then right click on the XPDL process in the Navigator window and choose Import option. One of the import possibilities is as the translation from XPDL to BPMO is a two-step translation as described in [17]. 3. Before the process is translated to sbpmn, it is validated (if some errors regarding the process model occur e.g. a process is not a well formed one, the user is notified about the changes that should be introduced) (REQ.MOD.02). 4. In the second step of translation a user should right click on the sbpmn process and once more select import from the context menu. Then the sbpmn-to-bpmo translation should be selected. The process translates to BPMO. A user is notified that no layout file was created so the process should be visually updated. If the XPDL model was semantically described i.e. goals were added to tasks, they are still attached to tasks in a BPMO process model (REQ.MOD.03) _SUPER_D8 3_V2_ES.doc PUBLIC Page 18

25 Semantic annotation of business process models The BPMO Editor, a part of the Modelling Tool, is a Semantic Business Process Modelling environment. It consists of: Process Modelling Area WSMO Explorer; BPMO Palette; Properties View; Thumbnail View; Navigator. The Process Modelling Area is the main modelling area, where semantic business process models are graphically represented among others with their tasks, events, block and graphical patterns, as well as connections between components. It presents a control flow of a process. Projects and processes are selected in the Navigator, i.e. a Project Explorer. New elements being the building blocks of a business process model, consistent with BPMN notation, like sub-processes, properties, tasks, gateways, events, connections and others, can be selected and added from the Palette using drag&drop technique. The WSMO Explorer shows in a form of a Three View different WSMO entities like: ontologies, Web Services, goals and mediators. The elements from WSMO entities like: ontology concepts and instances, WSMO goals or semantic constraints (axioms for pre- and post-conditions) can be attached to a business process model in a simple way, just be dragged&dropped. They can be attached respectively: goals to Process and Task element, mediators to Mediation Process, axioms to pre- and post-conditions of a Task or a Process, concepts and instances to inputs and outputs of a Task or a Process. The Properties View is a data flow view. It offers a context view, i.e. independent on a context, for currently selected element in the Process Modelling Area. The properties of elements can be filled in the Properties View by drag&drop from the WSMO Explorer. The Thumbnail View enables an outline of the current process diagram, as a minimised view of the whole process model. By moving an active dark blue rectangle right-left or top-down we can select different fragments of a process model to the visible area _SUPER_D8 3_V2_ES.doc PUBLIC Page 19

26 When we want to prepare a semantic business process model: 1. We should prepare a process flow using building blocks from the Palette by drag&drop them to the Process Modelling Area (Figure 7). After we add all elements needed, we have a business process model ready. Next, we should start adding semantic annotation to the process model; Figure 7: Preparing a process flow using building blocks from the Palette 2. We activate WSMO Explorer to have a possibility of choosing necessary WSMO elements; 3. We use ontology concepts and instances for annotation of inputs and outputs of a Task/Process by drag & drop a concept or instance selected to the relevant property in the Property View (Figure 8) _SUPER_D8 3_V2_ES.doc PUBLIC Page 20

27 Figure 8: Annotating task properties with ontology elements 4. We can attach WSMO goals to Tasks. They will be mapped to SWS at runtime or used for a sub-process/process composition during the SBPC phase (see sub-section 3.2.2) _SUPER_D8 3_V2_ES.doc PUBLIC Page 21

28 When we want to visualise a semantic annotation of a business process model, we use a context menu: 1. We select a business project model and click the right mouse button on it 2. We choose: Open With-> WSMO Visualiser and we receive a semantic visualising of the business process model (Figure 9). Figure 9: Visualising a semantic description of a business process model _SUPER_D8 3_V2_ES.doc PUBLIC Page 22

29 3.2.2 Composer Usage To implement a process using SUPER Tooling the following steps must be performed by a user: 1. Model a process using the Modelling Tool and assign WSMO Goals from a Domain Ontology to tasks in the process. 2. The composer should be enabled (a composer icon on the toolbar should be visible). 3. Then right click on the task and specify non-functional parameters and constraints for each task in the process using pop-up window providing schema for properties definition (Figure 10). Figure 10: Adding Non-functional parameters and Constraints _SUPER_D8 3_V2_ES.doc PUBLIC Page 23

30 4. In the next step a user should right click on each task and from the context menu choose Compose option. The process is being implemented, taking into account the available set of semantic web services based on the task description provided by the domain ontology including defined goals and specified constraints (REQ.COM.01). Figure 11: Modelling environment with BPMN diagram and task sequence for composition The above BPMN diagram used by WSMO Studio (Figure 11) shows the general tasks that should be executed. Each task must be associated with a business goal which contains a semantic description of what is to do. The cascade composition (REQ.COM.02), i.e. the sequential composition of selected tasks would be beneficial to shorten time for analyst to get tasks composed, instead of clicking each time for one task. The red rectangle at the Figure 11 points the sample sequence of two tasks _SUPER_D8 3_V2_ES.doc PUBLIC Page 24

31 Figure 12: Business goals to be edited by an analyst in user friendly manner The description of business goal specifies the pre- and post-conditions that are in other words, the state of the world before and after executing the particular task (Figure 12). At this point we have a complete picture of the process from the business expert point of view. That is we have tasks and business goals but this process notation is completely abstract from the existing web services that may be used to execute the depicted process. Independently of the process, each existing Web Service should be annotated semantically, that is described in a similar way as tasks with pre- and postconditions. It is necessary form business analyst point of view to have business goal editor that makes easier goal definition and goal library management process, much more user-friendly than in text editor environment. In order to execute the process, first we have to use the Composer to transform the set of tasks into a set of existing web services that will be able to perform operations required in each task. In this example we execute the Composer (Figure 13) for the Verify Customer task _SUPER_D8 3_V2_ES.doc PUBLIC Page 25

32 Figure 13: Message after the composition for selected task is accomplished At the end of the composition we receive a message about the composition result. When a composition succeeds, then the message Composition procedure completed successfully is displayed. Otherwise we receive a list of errors. The composition successful run results in finding Semantic Web Services that replace the composed task on the diagram, as shown in Figure _SUPER_D8 3_V2_ES.doc PUBLIC Page 26

33 Figure 14: Services found by The Composer to substitute the task in the BPMN diagram 3.3 Deployment of the Analysis Tool Using the Analysis Tool is very simple. We use the Analysis tool in WWW mode, just running from this link [15]. 3.4 Using the Analysis Tool Uploading log file in the ProM tool We assume that we already have a MXML log file. Uploading of the file is shown on the picture below (Figure 15). The user can either use Open Button or can use the menu File -> Open supported File and then he/she should point the log file to be uploaded. The ProM tool allows opening of MXML log files and also allows importing of process models _SUPER_D8 3_V2_ES.doc PUBLIC Page 27

34 Figure 15: Upload of a log file After the log is uploaded on the screen, the key data for the process is displayed the processes in the log, the cases in it, the number of events etc. Filtering logs One of the requirements was that the Analysis tool should be able to make a discovery over part of a log (REQ.AN.04). For that reason we will filter the log file in order to use it partially (Figure 16) _SUPER_D8 3_V2_ES.doc PUBLIC Page 28

35 Figure 16: Filtering logs After choosing the filter option the tool has option for selecting the advanced or simple filtration. The advanced option provides the functionality that we were looking for in the requirements. It allows the customer to define what part of the log should stay for analysis. Different filters are added to the filter chain by left click for selection Add selected filter. Analysis Menu Analysis gives an access to different kinds of analysis plug ins. The tool gives an option for different kinds of statistics (Basic Performance Analysis), drawing sequence diagrams (Performance Sequence Diagram Analysis) (Figure 17) _SUPER_D8 3_V2_ES.doc PUBLIC Page 29

36 Figure 17: Choosing an exact analysis type Process Mining Figure 18: Process Mining _SUPER_D8 3_V2_ES.doc PUBLIC Page 30

37 The menu Mining provides the mining plug ins. These plug ins are concentrated in discovering from the log information about workflows in the process and networks, see Figure above (Figure 18). Other menus On the figure below (Figure 19) the other two menus are presented that are available Conversion and Exports. Figure 19: Conversion and Exports menu Menu Conversion gives the option for transition between the notations that are supported by ProM tool. The menu Exports is used when all the analysis and mining is done and the results have to be exported _SUPER_D8 3_V2_ES.doc PUBLIC Page 31

38 4 Analysis of the Life-Cycle Tools Use In this section we present our user experience and identify the pros and cons of the tool on the basis of their usage. Tables below contain information about requirements realisation. We use the following abbreviations in the tables for status of realisation: Yes, No, NN means not known, NA means not applied. 4.1 Analysis of the Modelling Tool Use The Modelling Tool is simple to use and very intuitive. It offers a wide range of functionalities that make designing of process models much easier. The functionalities are divided into logical areas (like BPMO editor, WSMO editor, SAWSDL editor) and a set of relevant navigators, which simplify finding things substantially. There are also several context menus accessible at clicking the right mouse-button. The drag&drop technique is used, that is very intuitive for Windows users. The Modelling Tool allows a graphical representation of business processes. It hides all the complexity of WSML descriptions from an End-user. The thumbnails of business processes are accessible, that is a very useful functionality, particularly by huge and complicated process models, that are often the matter of operating by business analyst. The important benefit of the Modelling Tool is possibility to annotate process models with semantics, which is accessible with the WSMO editor, allowing an import of different ontologies, and possibility to translate process models into executable formats (we haven t possibility to check it yet). From TP point of view it is very important as well to have a possibility of importing existing process models from different formats. SUPER realises the functionality. We are not able to provide tests of performance, because it is not a commercial product, only a prototype. It is very interesting for us, what performance and efficiency could offer SUPER platform for everyday work of business analysts. We present below a realisation status of the Modelling Tool requirements. Requirement Realised Comments REQ.MOD.01.M Yes Import a process from XPDL/EPDL format is accessible ( XPDL-to-sBPMN translation ). REQ.MOD.02 NN In case of translation from XPDL format, it is implemented. We don t know how it is realised in other cases. REQ.MOD.03 NN In case of translation from XPDL format, it is implemented. We don t know how it is realised in other cases. It could be very useful when we have already process models annotated in different tools. Then we can execute them by the means of SUPER. REQ.MOD.04 Yes Work in BPMO Studio is intuitive. There are BPMN features accessible (the Palette), as well as a BPMN graphical representation in the Process Modelling Area _SUPER_D8 3_V2_ES.doc PUBLIC Page 32

39 Requirement Realised Comments REQ.MOD.05 Yes It is a key assumption of SUPER and the most important functionality required. The semantic annotation is supported by WSMO Editor. Different ontologies can be imported, incl. Domain and industry-specific ontologies (NGOSS: etom, SID, etc.) REQ.MOD.06 Yes It is possible to import ontologies, like BFO to annotate process. Maybe some additional linking to NGOSS ontologies could be provided. Then a tool could show a list of the most appropriate concepts (a concept in NGOSS ontology suggested where it exists, or if it isn t exist, then the most appropriate concept in BFO ontology) REQ.MOD.07 Yes Processes in the Modelling Tool have a graphical representation; adding a semantic description is also easy by the means of the WSMO editor REQ.MOD.08 Yes The WSMO Editor offers this functionality. It is accessible in BPMO Studio (a part of WSMO Studio) REQ.MOD.09 Yes Composing functionality offered by the Composer (a button of composing accessible in WSMO Studio) REQ.MOD.10 NA It is under development. REQ.MOD.11 Yes It is offered in context menu on a process and in the Property View for the Task REQ.MOD.12 NA It is under development (the Autocompletion functionality). REQ.MOD.13 NN This functionality will allow to check how the particular process models are executed, how to refine them etc. REQ.MOD.14 No Editing functionality for pre- and post-conditions will be extremely demanded. REQ.MOD.15 Yes It is offered by WSMO Studio ( WSMO Visualiser in context menu of a process). Additionally a thumbnail for a visualiser will be very useful, because of a complexity and a size of an ontology being visualised. REQ.MOD.16 Yes The functionality available (drag & drop technique, context menu: New-> Other-> General-> File-> Next-> Advanced button-> selecting BPMO file) REQ.MOD.17 Yes It is offered in the Palette in the BPMO Editor REQ.MOD.18 Yes It is available in the BPMO Editor, particularly in the WSMO Editor that offers WSMO elements to annotate a process (drag&drop) and the Property View for displaying all attributes of a Task marked. REQ.MOD.19 Yes It is possible in the WSMO Editor different ontologies can be imported into the Workspace of the WSMO Studio. REQ.MOD.20 NN The change of an element in an ontology is refreshed in the WSMO Explorer. We didn t identify if the relevant change in the process model annotated with the modified element, is refreshed as well, but we assume that it is provided. REQ.MOD.21 Yes The BPMO Editor (with the WSMO Editor and the Property View) provides mechanisms allowing change of any annotation of the process or the tasks. REQ.MOD.22 Yes See REQ.Mod.01.M _SUPER_D8 3_V2_ES.doc PUBLIC Page 33