presents a SWRL file of above queries and rules .
Figure 9.1: The SWRL rules in Protege-OWL SWRLTab
9.3
Applicability Validation in an Integration Application
The SWRL formulations for requirements are applied in the exemplar studies to validate the applicability of the proposed annotation approach. The validation is described by an application for integrating delivery process from enterprise A and B. The procedure of the implementation of this application is also the procedure of the validation.The following steps have been undertaken for the integration application. In each step, some query questions are described by the application user, and the query ques- tions are then inferred and answered by executing corresponding SWRL rules of the formalized requirements. Results are then analyzed and adjusted based on the semantic relationships of ontologies and models:
• Step 1. Set application goals and get goal-relevant model fragments.
Running QRule-Activity-achievesHardGoal for RE2.4 (Find the model frag- ments of process models that reference to SCOR Goal) to find process model fragments achieving the integration goals.
Query Question: Find model fragments from the PMA, PMB1 and PMB2 which have impact on the goals "Delivery_is_Processed" and "Invoice_to_Customer_is_Processed".
Query Inference: Sub-goals of "Delivery_is_Processed" and "Invoice_to_Customer_is_Processed" are inferred to expand the query, such as "Delivery_is_Scheduled", "Delivery_Terms_are_Generated",
152 CHAPTER 9. VALIDATION OF APPLICABILITY "End_Items_are_Delivered", "Invoice_to_Customer_is_Issued" and "Invoice_to_Customer_is_Paid".
Query Answer: As a result from executing the SWRL query, we have process model fragments (sub-processes) of "Delivering_Processing" in PMA and "De- liver_items_to_franchisee" and "Deliver_items_to_shops" in PMB2 which are relevant to achieve those goals. The screen shot of the exemplified results in Protégé-OWL SWRL Query Tab are illustrated in Figure 9.2 and Figure 9.3.
Figure 9.2: The query result of QRule-Activity-achievesHardGoal on PMA
Figure 9.3: The query result of QRule-Activity-achievesHardGoal on PMB2 • Step 2. Reconcile and align model semantics by using ontology as semantic me-
diator.
SWRL queries and rules are executed for RE4 (Knowledge discovery requirements) to find semantic relationships between Activity, Artifact and Actor-role in those model fragments resulted from step 1. For example, we check the relation- ships between the Actor-roles involved in PMA and PMB2. We need to first find out what Actor-roles are involved in each process.
9.3. APPLICABILITY VALIDATION IN AN INTEGRATION APPLICATION 153 Query Question: Navigate Actor-roles in the processes of "Deliv- ering_Processing" in PMA and "Deliver_items_to_franchisee" and "De- liver_items_to_shops" in PMB2.
Query Inference: In order to later find out the relationships between the Actor- roles of different models based on domain ontology, we need the query results including the model annotations by specifying which domain ontology concepts are referenced by the Actor-roles. Hence, QRule-Activity-hasActor, QRule- Activity-hasActor-sameas, QRule-Activity-hasActor-kindof and QRule- Activity-hasActor-memberof are used to query PMA and PMB2.
Query Answer: As results of QRule-Activity-hasActor, an Actor-role "logistics_department" is associated with the model fragments of "Deliver- ing_Processing" in PMA (Figure 9.4), and for PMB2 the Actor-roles "logis- tics_department", "financial_department", "Orbit_warehouse", "shop" and "fran- chisee" are queried out with respect to those process model fragments of "De- liver_items_to_franchisee" and "Deliver_items_to_shops" (Figure 9.5). The Actor-role "logistics_department" in PMA is annotated with the SCOR ontol- ogy "Logistics" by the annotation relationship "same_as" (Figure 9.6). The Actor-role "logistics_department" in PMB2 is also "same_as" the SCOR ontol- ogy "Logistics" (Figure 9.7), while the Actor-roles "shop" and "franchisee" are both annotated with the SCOR ontology "Customer" by the annotation rela- tionship "kind_of" (Figure 9.8). Besides, "financial_department" is "same_as" the SCOR ontology "Finance" and "Orbit_warehouse" is "kind_of" the SCOR ontology "Warehouse".
Figure 9.4: The query result of QRule-Activity-hasActor on PMA
Result Analysis and Adjustment: There are no semantic relationships be- tween "Logistics" and "Customer" in the SCOR ontology. A further step is hereby taken to search the corresponding Actor-roles for each other model. For example, search PMA for the Actor-roles that have the annotation reference of "Customer", and search PMB2 for the Actor-roles that have the annotation ref- erence of "Logistics".
By taking an example of "Customer",
Query Question: Find the processes which have Actor-roles with the ontological reference of the SCOR ontology "Customer".
154 CHAPTER 9. VALIDATION OF APPLICABILITY
Figure 9.5: The query result of QRule-Activity-hasActor on PMB2
Figure 9.6: The query result of QRule-Activity-hasActor-sameas on PMA Query Answer: The "client" in PMAis same_as "Customer", and the Actor- roles "shop" and "franchisee" are kind_of "Customer" in PMB2.
Query Analysis and Adjustment: "Shop" and "franchisee" in PMB1 (repre- sented by the EEML modeling element Organization) are hence semantically aligned as sub-classes of "client" in PMA (represented by the BPMN modeling element Swimlane).
Similar analysis of semantic relationships between the Activities is made by running QRule-Activity-subActivity to check their sub-activities and super-activities, and also running QRule-Activity-phaseof, QRule-Activity- kindof and QRule-Activity-sameas to find out how those Activities are in- terpreted according to the SCOR ontology. "Deliver_items_to_franchisee" and "Deliver_items_to_shops" in PMB2, and "Delivering_Processing" in PMAare all phase_of "D1-Deliver_Stocked_Product". Since the Actor-roles "shop" and "franchisee" in PMB2 are sub-classes of "client" in PMA, a corresponding adjust- ment of the semantic relationship between two models can be consequently made as "Deliver_items_to_franchisee" and "Deliver_items_to_shops" in PMB2 can be sub-activities of "Delivering_Processing" in PMA.
A possible integration path could be expressed as follows ("→" represents sequence flow, and "{}" represents sub-activities in the expression):
9.3. APPLICABILITY VALIDATION IN AN INTEGRATION APPLICATION 155
Figure 9.7: The query result of QRule-Activity-hasActor-sameas on PMB2
Figure 9.8: The query result of QRule-Activity-hasActor-kindof on PMB2
”Send_inquiry”(PMA) →”Send_quotation”(PMA)
→”Credit_control”(PMB2) →”Delivering_Processing”(PMA)
{”Deliver_items_to_ f ranchisee”(PMB2)}; ”Deliver_items_to_shops”(PMB2)}
→”Ship_items”(PMB2) →”Receive_delivery”(PMA)
→”Issue_invoice”(PMB2).
• Step 3. Re-order the sequence of integrating activities.
In Step 2, we are able to figure out the ontological relationships between the activ- ities, but we need sequential relationship to integrate them as a process. For in- stance, the sequence of activities in the integration can be further refined through checking the sequential Activity and sub-Activities of "Send_quotation" in PMA and the preceding Activities and sub-Activities of "Credit_control" in PMB2. Applying SWRL queries and rules QRule-Activity-hasSucceedingActivities and QRule-Activity-hasPrecedingActivities for RE1 and QRule-Activity- hasPrecedingActivities-hasSubActivity for RE3.2 to rearrange the sequence of integrated process model fragments. Activity sequences are further checked with the SCOR domain ontology, and adjustment of the sequence and hierarchy of activities is made according to the integration context.
Query Question: Navigate the succeeding Activities of "Send_quotation" in PMAand the preceding Activities of "Credit_control" in PMB2.
Query Answer: "Client_quotation_processing" is found as the succeeding Ac- tivity of "Send_quotation" in PMA (Figure 9.9), and "Check_stock" and "Cor- rect_orders" are retrieved as the preceding Activities of "Credit_control" in PMB2
156 CHAPTER 9. VALIDATION OF APPLICABILITY (Figure 9.10).
Figure 9.9: The query result of QRule-Activity-hasSuccedingActivities on PMA
Figure 9.10: The query result of QRule-Activity-hasSuccedingActivities on PMB2 Query Analysis and Adjustment: The integrated sequence depends on i) the activity sequence definitions in original process models, ii) the reference sequence defined in the SCOR ontology, and also iii) the new integration requirements which might need different activity sequence from the former two. Adjustment includes mergence and decomposition of integrating ac- tivities. For instance, "Client_quotation_processing" in PMA is annotated with the SCOR ontology concept of "D1.1-Process_Inquiry_and_Quote" (Figure 9.11), whilst "Correct_orders" in PMB2 is annotated as phase_of "D1.2-Receive_Enter_and_Validate_Order" (Figure 9.12). Therefore, "Correct_orders" in PMB2 can be succeeding activity of "Client_quotation_processing" in PMA and then be adapted as a subAc- tivity of "Standard_order_processing" in PMA. While, the two Activities "Credit_control" in PMAand in PMB2 can be merged into one Activity.
The result of the integration after this step is following ("/" is used to represent mergence): ”Send_inquiry”(PMA) →”Send_quotation”(PMA) → ”Client_quotation_processing”(PMA) →”Standard_order_processing”(PMA) {...; ”Correct_orders”(PMB2)...} →”Credit_control”(PMA/PMB2) → ”Delivering_Processing”(PMA){...; ”Check_stock”(PMB2); ...} → ”Transportation_processing”(PMA)/”Ship_items”(PMB2) → ”Receive_delivery”(PMA) →”Issue_invoice”(PMB2).
9.3. APPLICABILITY VALIDATION IN AN INTEGRATION APPLICATION 157
Figure 9.11: The query result of QRule-Activity-phaseof on PMA
Figure 9.12: The query result of QRule-Activity-phaseof on PMB2 • Step 4. Build output-input flow.
The step can be used to find the missing activities and also re-arrange the sequence of activities based on the output-input flow. For example, we can find an output of "Create_delivery" in in PMAthat matches an input of "Issue_invoice" in PMB2. Query Question: Find out which Activity in PMA produces the input of "Is- sue_invoice" in PMB2.
Query Inference: Such output-input mapping between different models need to be checked with the SCOR ontology as the mapping mediator, because the input/output parameters might be defined quite differently in two models. In- put and Output of activities are checked through running QRule-Activity- Input-mappedto and QRule-Activity-Output-mappedto for RE2.2 (Find the model fragments of process models that reference to SCOR Input/Output). Query Answer: QRule-Activity-Input-mappedto is executed on Activity of "Issue_invoice" in PMB2 and the input is mapped to "Customer_Delivery_Terms" (Figure 9.13). From the result of QRule- Activity-Output-mappedto in PMA(Figure 9.14), Activity "Create_delivery" has an output "delivery" which is mapped to "Customer_Delivery_Terms" too. Query Analysis and Adjustment: Because the input of Activity "Is- sue_invoice" and the output of "Create_delivery" are both mapped to "Customer_Delivery_Terms", it is possible for the two Activities to be inte- grated with each other through the output-input flow. Not all the integrating points have strict integration sequences. For those non-strict integrating model fragments, more analysis have to be done manually based on the application
158 CHAPTER 9. VALIDATION OF APPLICABILITY
Figure 9.13: The query result of QRule-Activity-Input-mappedto on PMB2
Figure 9.14: The query result of QRule-Activity-Output-mappedto on PMA context.
The final result of the integration application after above steps is presented ("|" is used to represent non-strict sequence):
”Send_inquiry”(PMA) →”Send_quotation”(PMA) →
”Client_quotation_processing”(PMA) →”Standard_order_processing”(PMA)
{”Correct_orders”(PMB2)} →”Credit_control”(PMB2) →
”Delivering_Processing”(PMA){...; ”Check_stock”(PMB2); ...; ”Create_delivery”}
→ ”Issue_invoice”(PMB2)|(”Transportation_processing”(PMA)/”Ship_items”
(PMB2) →”Receive_delivery”(PMA)).
More details of the integration process are provided in Appendix F. By running the above SWRL queries and rules, the integration application has been implemented. The realized implementation validated the applicability of the proposed annotation approach through showing the capability of the annotation results to fulfill the require- ments listed in section 9.1.1.