Project Topics
Get Complete Project Material File(s) Now! »
Implementation and Results
This section is made up of two phrases; the first phrase is to define the language or constructs for Information Demand Context model as given in section 4.1, figure 12, while the second phrase is to implement our developed constructs by coding it in a WorkflowProcess document to show how the representation is presented based on the information demand (ID) context model. XPDL was chosen as the language or formalized representation for the given process model.
Section 2.5 shows how BPMN as a modeling business process notation can be used to represent flow of activities. However, research has also shown how transformations are made from BPMN to XPDL. Thou, it is possible to transform our Information Demand Context model given in figure 12 of section 4.1 using BPMN, in order to be able to give its XPDL specifications, but we will still come to the same phrase as this only extends the process activities. Furthermore, BPMN is a notation (on the same level as the notation in Figure 12), hence there is no point in trying to express a notation in another notation. What we want is a representation, hence XPDL.
The XPDL construct defined in the thesis aims at implementing the flow of activities of the Information Demand Context model as given below.
Description of the Model
The different concepts of notations used for information demand context model as described in the diagram below are just graphical boxes and lines that cannot be used for anything else than human interaction. These can be described as follows:
Role: This is the representation of the notation “role” which is modeled through a swimlane. It is assumed to be a person or thing in a particular situation.
Task: This is an activity with the type of “task” that can be executed within a workflow definition or independently.
Organization unit: This is an activity with the type “Organization unit” used to represent a group of persons. In such cases it is a group with a defined body that plays the role, not the individuals within the group.
Information (object): This is represented as an externalized knowledge needed by a role when performing task. It is used to represent information sources and resources, like documents, books, text files, data bases and such.
Resources: This is represented as a device or entity that contains or provides access to information relevant when performing a specific task and thus utilized by specific roles.
Note: Note in a model diagram can refer to statements of actions to be performed or information being passed to participants.
Flow: This is a flow from one state to another state when certain conditions are satisfied. A connection between two decision points
Indirect flow: This is an indirect flow which indicates one or more activities going on within before getting to the main action is executed.
Information gap: Is an activity where participants are missing the information they need to complete a task and need to talk to each other to find it.
Superfluous flow: This is a flow that shows when two concepts are related even thou they should not.
Association: This is a activity which involves group of participants associating descriptive terms with elements they have identified of an activity, tool, practise or process.
Unknown Task/Resources/Information: This is usually problem statements in concept mapping where problems for which exact solutions are unknown, infeasible or impossible when dealing with task, resource or information.
Why use XPDL structure
XPDL was adopted for defining or developing the formalized representation for Information demand context model (figure 12) because it is an XML-based process definition language like BPML and BPEL which provides a formal model for expressing executable process that address all aspect of enterprise business process. It is based on paradigms which relies on activities as the basic element of process definition (Shapiro, 2002). In each activities are always a part of some particular process with an instance-relevant which is referred to as data fields.
XPDL focuses on issues relevant to the distribution of work where its activity attributes specifies the resource(s) that is required to perform an activity. Its activities attributes also specifies the application(s) required to implement an activity. According to Shapiro (2002), these concepts together supports the notion of a resource (e.g. participant), in conjunction with an application performing the activity. With reference to section 2.6.1 above, XPDL is a process design format based on XML syntax, specified by an XML schema and contains or allows for extensions which is conceived as a graph-structured language with additional concepts to handle blocks.
The main elements of the XPDL language (Wil, 2003) also known as XPDL metamodel (Guelfi and Mammar, 2006) used in our development are: Package elements which is the container holding the other elements; the Application element which is used to specify the applications/tools; the Activity element serves as the basic building block; the Transition elements which connects two activities types together; the Participant (performer) element which specifies the participants in the workflow process and these participants can be Resources, Role, OrganisationalUnit, Human and System. While DataType element is used to specify workflow relevant data. Data is used to make decisions or to refer to data outside of the workflow and is passed between activities and subflows (Wil, 2003).
Defining XPDL construct
When defining the representations for our model, the main elements of an XPDL as explained in section 4.2 above were taken into considerations. The table below shows how the various concepts of notations in our case model were mapped or represented using XPDL.
Translation rules
This section gives a set of formal rules that was used when developing or transforming the Information demand context model into an XPDL specification. In order to obtain an optimal XPDL specification while defining simple constructs rules, the approach used comprises of two successive steps:
A simple translations process from Information demand context diagram into an XPDL specification.
A set of optimization rules acting on the obtained XPDL specification.
From ID Context diagram into an XPDL specification
To translate information demand context model diagram into an XPDL specification, two phrase are required. Our translations begins by first defining the concept of notations into XPDL activities. These activities are linked together in the second phrase with transitions that correspond to the arrows of the related ID context model diagram. The main idea of transforming the process diagram into XPDL specification is to match the different concepts and transitions with the model taking into considerations the different arrow (transition) types.
Optimization of an XPDL specification
Optimization presents a set of formal rules that apply on an XPDL specification in order to produce a concise representation (Guelfi and Mammar, 2006). Optimization rules in this case are the syntax and semantics that apply when using XPDL codes for XPDL metamodel which are WorkflowProcess, Activity, Transition, participant, DataField, DataType, OrganisationalUnit. These rules includes formatting, translation process, syntax and semantics and the use of tags.
Completeness and Correctness
Completeness and correctness are two important properties to be checked when transforming any business process activity to XPDL construct (Guelfi and Mammar, 2006). In our model, the completeness property ensures that each concept in the ID context model verifying the syntax defined in Fig 12 can be mapped to an XPDL specification. The correctness property ensures that our transformation or mapping process together with the optimization rules maintain some structural properties of the ID context model diagram (paths).
The Workflow patterns in XPDL
Based on the constructs developed in section 4.3, the Workflow Process for Information demand context model can be written as follows:
Discussion and Conclusion
In this paper, the author has been able to present representations generated by deriving XPDL specification for an information demand context model. This operates in two stages. The first stage defines the language and maps the elements notations to a new XPDL element. The second stage applies a set of optimizations rules to obtain optimal specifications and also shows how it works together. This chapter presents a brief discussion of the results achieved during the thesis work. Then generalization and limitations of the results are discussed. Finally some recommendations for improvement and for further research were given.
Discussion of the results
As stated in the introduction part of this work, information demand is about the logistics or constantly changing needs of information to support business activities, which is viewed in 3 areas as demand, distribution and context. The context aspect of information demand portrays the settings in which information demand exist and is the major focus of our work. This thesis work was about developing a formalized representation of information demand context for how it can be presented so that it should be able to give a flexible, logical and more defined structure. The author believes that the developed representations for the context model is not perfect but provides a good solution to the problem for analyzing information demand context.
As mentioned in chapter 1 to direct the work, three research formulations were the basic for this thesis; to give a description of what Meta model is; secondly examine if it is possible to employ XPDL specifications to Information Demand Context model; and the third one was to show what extensions are needed if truly XPDL Meta models can be used to represent ID context model. Here is shown the extent to which these questions have been addressed:
To answer the first question, it was concluded that Meta model is capable of describing a language’s concrete syntax and semantics and it also describes the model itself. XPDL meta model –Activity, WorkflowProcess, DataType, DataField, and Tansition describes each level entities contained within the process definition, their relationships and attributes as shown in figure 13. Furthermore, it also defines the various conventions of grouping these process definitions.
XPDL from the above solutions (Figure 13) is able to store and exchange process diagram enabling serialization; and its possible to write out process definition with full fidelity and another person can read it and comprehend and reproduce same diagram. Furthermore, the XPDL schema in the solutions also focuses on relevant work distribution where the activity attributes specifies the resource which is required to perform an activity and also specifies the application required to implement an activity. Furthermore, XPDL gives the solution a flexible, well defined and logical structure.
Finding answer to the third question proved a bit tricky as the author did not include any extensions on the ID context model diagram to enable create the corresponding representations. The answer to the third question is based on previous experience of XML, coupled with the fact that XPDL has the same extensibility feature. Thou as mentioned above, XPDL is “extensible” and the markup symbols are unlimited and self-defining (SearchSOA, 2011). There is still possibilities of adding new and extra information to the workflow process application for example, there can be a sequence flow transition of activity from the task “Register for Exam (id-tag 48)” to the task “Take Exam (id-tag 46)”. The reason for this is because, in a real life situation a student is only allowed to take an exam when he/she has previously registered for that exam. This can thus be added to the application. However, this and many other extra extensions can be added on the workflow process specification, and yet the application will still be able to extract its elements from the XPDL document to produce output without breaking the application, crashing or giving errors.
Consequences and Implications
Based on the ID context model diagram as shown in Fig 12; problem might arise when trying to put different activity concept model together in a single concept environment for example, in “Examiner” role. The connection arrows sometimes intersect each other and make the diagram cumbersome and difficult to comprehend. There might be problems in modelling some cases where a single task can be performed by two or more persons, or when trying to move a concept in the notation from one position to another. Another problem is transitions connecting or going across swimlanes; without a good understanding of the real world scenario, it might be difficult to grasp. The implications with these problems is that it makes it hard for readers to study, understand and interpret the flow process.
These various short comings is what XPDL representations is able to solve in a serialized and well structured manner. The solution is thus simple, logical and flexible.
Generalization
Recently, researches has been carried out on XPDL specifications and how it has been used to map with business process models like BPMN, and how XPDL can be generated from UML Activity diagrams. This thesis contributes to the current research in Workflow Management System by developing a new ways to translate or map Information Demand Context to XPDL.
Limitations
As been mentioned above, the purpose of this work is not intended to build a tool engine for the execution of the workflow process but rather analyzing XPDL specification and provide a mapping between the graphics of the process flow notations to its associated underlying constructs of execution language which is XPDL. However, there is currently no tool to execute the Workflowprocess document for information demand context model developed in this thesis work.
This representations or constructs defined in this thesis work is limited to Information Demand Context model. Thus, these constructs cannot be applicable to other process model. Furthermore some of the constructs defined in Table 6 for example, concepts like sequence flow, extended flow and informal flow where not used in the Workflowprocess application because they were not shown in the ID context model diagram, so it was difficult incorporating the transitions into the Workflowprocess document.
Since, the workflow pattern designed for this thesis is based on the information demand context model given and the transitions diagrams are developed in the same construct with exception of the type that it is defining. There was difficulty translating superfluous flow diagram as used in the model because of lack of understanding of the function it is performing. One thing to note about the workflow pattern result is that in cases where there is an unknown Task/Resource/Information, the mapping constructs is assumed the element notation for the activity and hence defined as thus in the program because this cannot be represented logically.
In addition, despite standardization efforts, diagram interchange across different modeling tools remains an issue. Hence, transforming information demand context model into XPDL specifications could not be implemented or test run because of the limited time frame.
Recommendation and further study
This paper provides the authors’ developed constructs for mapping Information Demand Context model to XPDL document. Since there is currently no tool to execute this constructs, a further research would be performed on that matter.
The result of the workflow pattern defined for the information demand context in this work has not yet being implemented. It will be interesting in further research to text run the XPDL workflow pattern code developed in this work to ensure the validity of the program formulation. This gives rise to a further work on this area.
There was no additional information added to the workflow process document to show the extent to which XPDL can be extensible. The is because the result is limited to the ID context model diagram. Hence, it is also of great interest to have this revisited for further work.
Contents
1 Introduction
1.1 BACKGROUND
1.2 PURPOSE/OBJECTIVES
1.3 LIMITATIONS
1.4 THESIS OUTLINE
1.5 TIME PLAN
2 Theoretical Background
2.1 MODELING
2.2 META MODEL
2.3 INFORMATION DEMAND
2.4 INFORMATION DEMAND CONTEXT
2.5 BUSINESS PROCESS MODELING NOTATION (BPMN)
2.6 EXTENSIBLE MARKUP LANGUAGE (XML)
2.7 XML PROCESS DEFINITION LANGUAGE (XPDL)
2.8 MAPPING
2.9 RELATED WORKS
3 Methods
4 Implementation and Results
4.1 DESCRIPTION OF THE MODEL
4.2 WHY USE XPDL STRUCTURE
4.3 DEFINING XPDL CONSTRUCT
4.4 THE WORKFLOW PATTERNS IN XPDL
5 Discussion and Conclusion
5.1 DISCUSSION OF THE RESULTS
5.2 CONSEQUENCES AND IMPLICATIONS 8
5.3 GENERALIZATION
5.4 LIMITATIONS
5.5 RECOMMENDATION AND FURTHER STUDY
6 References
GET THE COMPLETE PROJECT
DEFINING A FORMALIZED REPRESENTATION FOR INFORMATION DEMAND
