DEFINING A FORMALIZED REPRESENTATION FOR INFORMATION DEMAND

Innocent Idiahi

MASTER THESIS 2011 INFORMATICS

DEFINING A FORMALIZED REPRESENTATION FOR INFORMATION DEMAND

Innocent Idiahi

Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom ämnesområdet informatik. Arbetet är ett led i teknologie magisterutbildningen med inriktning informationsteknik och management. Författarna svarar själva för framförda åsikter, slutsatser och resultat. Handledare: Magnus Lundqvist Examinator: Vladimir Tarasov Omfattning: 30 poäng (D-nivå) Datum: 2011-06-22 Arkiveringsnummer: Postadress: Box 1026 551 11 Jönköping

Besöksadress: Gjuterigatan 5

Telefon: 036-10 10 00 (vx)

Abstract

Abstract Information demand is a part of comprehensive business logistics which encompass logistics of information. The demand for information has provided a unifying framework for different needs on enterprise modeling. Hence, the problems organizations faces relating to flow and distribution has lead to the development of various framework for analyzing information demand and this is guided by a set of rules, methods and even a unified representation. This thesis work defines a specification for enterprise Information Demand Context model using XPDL as the language of construct. The paper gives reasons why XPDL was preferred for such a representation and show how mapping is carried out from the constructs of notations to its associated XPDL specifications, so that when we are defining a representation we are as well defining its meta model. The resulting specification is presented in such a way that it should be able to give a flexible, logical and more defined structure.

i

Sammanfattning

Sammanfattning Information efterfrågan är en del av omfattande verksamhet logistik som omfattar logistik av information. Efterfrågan på information har utgjort en samlande ram för olika behov på företag modellering. Därför står inför problem som organisationer som avser att flöda och distribution har lett till utvecklingen av olika system för att analysera information efterfrågan och detta styrs av en uppsättning regler, metoder och även en samlad representation. Detta examensarbete definierar en specifikation för företagsinformation Efterfrågan Sammanhang modell med XPDL som språket i konstruktionen. Papperet ger skäl till varför XPDL var att föredra för en sådan representation och visa hur kartläggning görs från konstruktioner av anteckningar till dess associerade XPDL specifikationer, så att när vi definierar en representation är vi liksom definiera dess meta modell. Den resulterande specifikationen presenteras på ett sådant sätt att det skulle kunna ge ett flexibelt, logiskt och mer definierade struktur.

ii

Acknowledgements

Acknowledgements I would like to thank my supervisor Magnus Lundqvist for his advices, support and facilitator role throughout this final project despite his busy schedule. I would also like to thank Vladimir Tarasov for his constructive criticism and useful comments he gave to improve my work. Many thanks also to my parents and siblings for their love and support both morally and financially. I would also like to thank my friends who have always been there for encouragement and contribution in order to achieve this project.

iii

Key words

Key words Meta Models – Information demand – Information Demand Context – Business Process Modelling Notations (BPMN) – XML Process Definition Language (XPDL)

iv

Contents

Contents 1 

Introduction................................................................................. 1  1.1  1.2  1.3  1.4  1.5 

2 

BACKGROUND............................................................................................................................. 1  PURPOSE/OBJECTIVES ................................................................................................................ 3  LIMITATIONS ............................................................................................................................... 3  THESIS OUTLINE.......................................................................................................................... 4  TIME PLAN .................................................................................................................................. 4 

Theoretical Background .............................................................. 6  2.1  MODELING ................................................................................................................................. 6  2.2  META MODEL ............................................................................................................................. 7  2.2.1  Characteristics of Meta Models ................................................................................................. 8  2.2.2  Why Meta Model? ................................................................................................................. 9  2.3  INFORMATION DEMAND ............................................................................................................. 9  2.3.1  Determinants of information demand........................................................................................ 10  2.3.2  User profiles........................................................................................................................ 10  2.3.3  Situation-based .................................................................................................................... 11  2.4  INFORMATION DEMAND CONTEXT........................................................................................... 11  2.4.1  Role .................................................................................................................................. 13  2.4.2  Task ................................................................................................................................. 13  2.4.3  Responsibility ...................................................................................................................... 13  2.4.4  Resources............................................................................................................................ 13  2.4.5  Information (Object) ............................................................................................................. 14  2.5  BUSINESS PROCESS MODELING NOTATION (BPMN) ................................................................ 14  2.5.1  BPMN Basics .................................................................................................................... 15  2.5.2  BPD Set ............................................................................................................................ 16  2.5.3  BPMN Limitations ............................................................................................................. 19  2.5.4  Uses of BPMN ................................................................................................................... 19  2.6  EXTENSIBLE MARKUP LANGUAGE (XML)................................................................................. 21  2.6.1  XML Document Structure .................................................................................................... 21  2.6.2  Design Goals for XML ........................................................................................................ 22  2.6.3  Why use XML ................................................................................................................... 22  2.7  XML PROCESS DEFINITION LANGUAGE (XPDL) ...................................................................... 23  2.7.1  XPDL Goals ..................................................................................................................... 23  2.7.2  XPDL Requirements ........................................................................................................... 24  2.7.3  Structure of XPDL ............................................................................................................. 24  2.8  MAPPING................................................................................................................................... 25  2.9  RELATED WORKS ....................................................................................................................... 25  2.9.1  Mapping to XPDL ............................................................................................................. 26  2.9.2  XPDL Code for E-Order Process........................................................................................... 27 

3 

Methods..................................................................................... 29 

4 

Implementation and Results ...................................................... 30  4.1  DESCRIPTION OF THE MODEL ................................................................................................... 30  4.2  WHY USE XPDL STRUCTURE ..................................................................................................... 32  4.3  DEFINING XPDL CONSTRUCT................................................................................................... 32  4.3.1  Translation rules.................................................................................................................. 34 4.3.1.1 4.3.1.2

From ID Context diagram into an XPDL Specification ………………………….…………………..……… 35 Optimization of an XPDL specification …………………………………………………………..………… 35

4.3.2  Completeness and Correctness ................................................................................................. 35  4.4  THE WORKFLOW PATTERNS IN XPDL ...................................................................................... 35 

v

Contents

5 

Discussion and Conclusion........................................................ 47  5.1  5.2  5.3  5.4  5.5 

DISCUSSION OF THE RESULTS .................................................................................................... 47  CONSEQUENCES AND IMPLICATIONS......................................................................................... 48  GENERALIZATION..................................................................................................................... 49  LIMITATIONS ............................................................................................................................. 49  RECOMMENDATION AND FURTHER STUDY ................................................................................ 49 

6 

References ................................................................................. 51 

7 

Appendix ................................................................................... 54  7.1  APPENDIX I: INFORMATION DEMAND CONTEXT MODEL ......................................................... 54  (GIVING ID-TAG NUMBERS TO THE TRANSITIONS (ARROWS)). ............................................................ 54  7.2  APPENDIX I: INFORMATION DEMAND CONTEXT MODEL ......................................................... 55  (GIVING ID-TAGS NUMBERS TO THE DIFFERENT CONCEPTS OF NOTATIONS). ..................................... 55 

vi

List of Figures

List of Figures Figure 1 – Relationship between model and meta model systems ....................... .8 Figure 2 – Conceptual refinement of information demand context ……………12 Figure 3 – Simple BPMN diagram ……………………………………..…….. 15 Figure 4 – BPMN main symbols ……………………………………..……… 16 Figure 5 – An Example of a Collaborative B2B process …………….… .…….. 20 Figure 6 - Example of Private Business Process ………………………………. 21 Figure 7 – Simple BPMN Process (WfMC) ………………………………….. 22 Figure 8 - Example of XML document structure ……………………...……… 24 Figure 9 – The Start of the E-Order process ………………………………….. 26 Figure 10 –Start of the E-Order process and the Object mappings to XPDL..... 27 Figure 11 – XPDL sample for E-order process ……………………………….. 26 Figure 12 – Information Demand Context model………..……………….….. 31 Figure 13 – WorkflowProcess for Information Demand Context Model …… 46

vii

List of Figures

List of Tables Table 1 – Time plan…………………………………….……………............. 5 Table 2 – Core BPD Flow Objects………………………………………….. 16 Table 3 – Core BPD Connecting Objects …………………..……………… 17 Table 4 – BPD Swimlane Objects …………………………………..……… 18 Table 5 – BPD artifacts Objects ………………………………………….… 19 Table 6 – Mapping process diagram to XPDL ………………………....…… 34

viii

List of Abbreviations

List of Abbreviations ID – Information Demand BPMN – Business Process Management Notation XML – Extensible Markup Language XPDL – XML Process Definition Language WfMC – Workflow Management Coalition OMG – Object Management Group BPD – Business Process Diagram Id-tag – Identification Number W3C – World Wide Web Consortium

ix

Introduction

1 Introduction Information demand is a part of comprehensive business logistics which encompass logistics of information. The availability of information beginning from the charting theory in the early 1920’s (Graham 2004), lead organisations to adopt process engineering/reengineering methodologies and supporting notations for the elicitation, documentation and analysis of organizational processes (ScholzReiter and Stockel 1996). Hence development of theories for notation is the key to Information System and to any scientific endeavour pertaining to the development of a deep and meaningful understanding of certain real-world phenomena that we observe in day-to-day life (Seidel & Recker 2009). In developing a model for an enterprise, theory development has taken many forms, ranging from the analyses of available literatures and existing theoretical models to the use of tacit knowledge in the form of common sense and experience (Eisenhardt, 1989). Over the years, other forms of theory development have also emerged through the use of study research (Eisenhardt, 1989). In addition, there has been many theories or notations that are used to give a visual description or representations of the flow of information such as Models, Meta Models for example. The problem with this is that, these representations are only limited to certain functionalities. It gives only a visual notation of what we want people to see. Hence, there is a need for a structured requirement specification of these Meta Models; a structure that can define the idea, the property and the type of any process flow. This structure should be able to have a background that works in parallel with the visual aspects of our notations. These structured representations should be able to map with the model notations in a flexible, well defined and logical way so that whatever action performed on the visual is effected accordingly on the background. The objective of this report is to introduce a formalized modelling representation known as XML Process Definition Language (XPDL), a formal internal representation for models. This paper also shows how XPDL structure is used to effectively represent information demand (ID) context model. This is done by mapping the process flow notations of the ID context model to its associated XPDL structured representations. The resulting specification, presented in associated XPDL structure should be able to give a flexible, logical and more defined structure.

1.1 Background Over the years, the demand for information has become apparent in different aspect of life. In order to provide a unifying framework for different needs on enterprise modelling (Decker et al, 1997), this thesis work defines a specification for enterprise information demand context. There is no defined meaning associated to the word information as information can be acquired through tacit or explicit knowledge. The concept of information is so vast that we find it hard to

1

Introduction

narrow. Information can be related to notions of constraint, communication, control, data, form, instruction, knowledge and even representations for example. The goal of any information got is for result to be acquired and for needs to be satisfied. In an organisational point of view, availability of information is necessary for making decisions, solving problems and performing relevant task. Thus, providing such information to users is to simply make any existing information available and let the users themselves find what they want or need (Levashova et al, 2006). This leads us to ask questions such as; what is information demand? Why do we need to model information? And what is information demand context? In order to get a full understanding of information demand and its context in an enterprise environment, the logistics areas of demand modelling needs to be looked into. These three areas as described by Lundqvist (2005) are; Demand which ensures that the information required meets the needs at the right time, in the right content, location, quality and presentation; Distribution which deals with the transportation of information to the place where it is needed; and Content or Context which is the formalized representations of information about the setting in which information demand exist and these comprises of roles, related activities and resources available to that role. There are some common problems organisations face related to information demand in some way or another which are quite independent of the organisation (Lundqvist et al, 2009). In effect, most of these problems can be reduced relatively by visualizing the information demand of the organisation in question. Some of these problems can be summarized as follows: Superfluous information which is the constant stream of information being supplied to roles despite there being no need for it, and the reason for this is because the information once needed but the demand for it changed over time (Lundqvist et al, 2009); Another problem as described by Lundqvist et al. (2009) is a Gap in the information flow which arises when the roles needing the information are not receiving it when information is supplied – this might be as a result of lack of technical support or information supplied through a wrong gateway or not distributed accordingly; Information gathered at the wrong time is also a problem as this is where roles are not gathering their information at the right time or are not aware they should; and lastly Outdated and/or incorrect information – which is due to the fact that individuals do not use the correct source of information (Lundqvist et al, 2009). Based on the different organisational cases and the typical problem they face, various approaches to modelling information demand have been used. According to Lundqvist et al (2009), the results of these approaches is based on a suggestion of a highly flexible component-based method which defines a framework for analysing information demand guided by a set of important principles through the application of a number of methods components and a unified representation.

2

Introduction

Representations or notions for modelling an enterprise information demand should fulfil the following objectives as: it should be understandable and widely accepted, it should be useful for different types of software systems (e.g. information systems and knowledge based systems) and powerful enough to model all relevant aspects (Decker et al, 1997). Different notations have been used to represent information context model, but many depend on the theory the author is trying to establish. In some cases the adoption of the visual representations form of notion forms an integral part of the language of requirement (Moody 2009). Indulska et al. proposes graphical models which are used to depict various aspects of enterprise. This is the use of flow chats which comprises the use of diagrammatic symbols to increase the complexity evaluation (Indulska et al. 2009). Furthermore, there is the need to relate these notations to a specification that is intuitive to business users and yet able to represent complex process semantics (White, 2004). This notation should be able to provide a mapping between the graphics of the notation to underlying the construct of execution language (XPDL). In order to fulfil the purpose of the thesis work, a number of research questions will be looked into like: • What are Meta Models? • Can XPDL meta models be used to represent information demand context model? • If XPDL is such a suitable representation construct, what extensions are needed?    

1.2 Purpose/Objectives This thesis work focuses on defining formalized representations for information demand context model using XPDL. Base on these, gives reasons why XPDL is preferred for such representations. This work will also help us to understand how we can map process activities to XPDL in such a way that when we define a representation, we are as well defining the meta model. In order to achieve this aim, the following objectives should be reached: •

Define a language or construct for Information Demand Context model using XPDL specification. • Implement the defined constructs by coding it in a WorkflowProcess document to show how the representation is presented based on the information demand (ID) context model.

1.3 Limitations The purpose of this thesis work is not intended to build a tool engine for the execution of the workflow process. This reason for this is because of the time frame that the thesis work is supposed to take. The novelty of my study lies on

3

Introduction

analyzing XPDL specification and also provides a mapping between the graphics of the process flow notations to its associated underlying constructs of execution language which is XPDL. Thus, the requirement elicitation phrase this thesis will take will be based from the perspective view, so there will be need for the requirement elicitation from the graphical phase of the tool as a future work.

1.4 Thesis outline This outline describes the different part executed during the thesis work. This is divided into five main parts. The first part gives a brief introduction of the subject matter, the goals that are expected to achieve and the limitations of the thesis work. The second part, literature review gives an overview of some modeling concepts that has been established. It also dealt in details with the concept of discuss; information demand context, what they are and what reason they are needed. In addition, this part discusses meta-models theories, Business Process Modeling Notations BPMN and XML Process Definition Language XPDL. The third phrase is the Methodology part where I describe how information are got for writing the thesis work and how I went about in solving the research problems. The forth part will be made up of the implementation phrase, which describes how I will relate ID context model notations using XPDL. This section also discusses the result of the implementation phrase and discussion. Finally, this section draws conclusion about the result achieved during the thesis work.

1.5 Time Plan

Task Name

Literature review

Meeting with Magnus More research and write-up

Task Description

Research about different modeling tools and terms like meta-models, XML, BPMN, XPDL and trying to analyze and give new ideas Discussing my understanding and new ideas Start research about Information Demand (ID) context and XPDL

Deliverable

Brief description of these terms and how they are used and new ideas

Duration

15 days

Start Time 2011-02-02

2011-02-24

Brief description of my understanding about Information Demand context

4

End time

2011-02-22

Introduction Relating ID context using models

Relating ID context using BPMN and XPDL

Requirement specifications and including scenarios

Meeting with Magnus

Asking questions where necessary and discussions. XPDL Defining XPDL structure structure for the (Development) representation of ID context Meeting with Presenting the defined Magnus constructs and mapping solutions and further discussions Report writing Report writing Revising the model

Meeting with Magnus

Half way presentation Revising the report Report submission Final presentation Report revision

I observed, analyzed and revised the implementation construct based on the model Presenting the second version of implementation solution and discussing about report comments Presentation of project Revising report and completion Submit report via Ping-Pong Presentation of project

2011-03-15

Defining XPDL 1 month structure for the representation of ID context First version of the 1 day implementation solution First version of report

2011-03-17

2011-04-24

20 days 10 days

The second version of the implementation solution

1 day

2011-04-26

1 day

2011-04-28

15 days Final report

1 day

2011-06-20

Final presentation

1 day

2011-06-22

Report revision and resubmission

2 days

Table 1: Time plan

5

2011-04-21

Theoretical Background

2 Theoretical Background During the course of writing this thesis, the question of “how to proceed?” and “what to do it?” became a critical issue (Ghauri & Gronhaug, 2005). This chapter introduces some existing knowledge through a state of the art of discussion by giving an overview of some existing theories or concepts used in modeling. It also dealt in details with the concept of discuss; information demand context, what they are and what reason they are needed. Basically, this chapter is divided into the flowing sub-sections: • • • • • • • • •

Modeling (section 2.1) Meta Models (section 2.2) Information demand (section 2.3) Information demand context (section 2.4) Business Process Modeling Notations (Section 2.5) Extensible Markup Language XML (section 2.6) XML Process Definition Language (Section 2.7) Mapping (Section 2.8) Related Works (Section 2.9)

2.1 Modeling Modeling plays a critical role in solving problems. Simply put, modeling is a way of simplifying the real world to enable us solves problems. It is part of our everyday life that we don’t even notice we are doing it. For example, a street directory is a model of a city’s roads, a diagram is a model of how something is made and a calendar is a model of a month (Nova 2008). These various models are what people use to solve problems such as ‘What is the shortest route? , ‘How do I put things together?’, ‘How long until summer holiday?’ (Nova 2008). The act of modeling enables us to build representations of things in the ‘real world’ and allowing ideas to be investigated. Furthermore, it is central to all activities that are involved in the process for building or creating an artifact of some form or other. Bubenko’s (1992) definition stated; “Modeling means essentially to describe a set of abstract or concrete phenomena in a structured and eventually in a formal way”. “Describing, modeling and drawing is a key technique to support human understanding, reasoning and communication.” Models serves as an aid to communication between users involved in any process activity. It is simplified version of something complex used in analyzing and solving problems or making predictions (MSN Encarta 2009) and are mostly used for understanding, evaluation, designing and for implementation. Modeling deals 6

Theoretical Background

with an abstraction which allows people to concentrate on the essentials of a problem. Many theories for modeling have been established for enterprise modeling as a means of understanding and to support communication. For example, the use of visual notations; where diagrams play a critical role in specifying, documenting and communicating user requirements (Moody 2009) was found to be more effective than text especially for notation novices like end users or business experts (Avison & Fitzgerld 2003). The problem with the visual notation according to Moody et al. (2010) is that majority of effort is spend designing the semantics notations (what constructs to include and what they mean), with design of visual syntax (how to perceptually represent these construct) taking place largely as an afterthought. Indulska et al. (2009) also selected an appropriate business process modelling forms by using a model based on the Bunge ontology for knowledge representation because it deals directly with concepts relevant to the information systems and computer and domain. For this thesis framework, modeling information demand is about using the context-based demand flow model to support business activities; by embodying different ways of capturing, representing and evaluating information flow during business activities.

2.2 Meta Model The word “meta” originates from the Greek word meaning ‘after’ or ‘beyond’. Meta Model is a model that describes a model. It is said to be a model in itself because its syntax and semantics are governed by the formalism it is described in and that formalism can be modelled in a meta-meta model (Vangheluwe, 2002). A Meta Model has two main distinguishing characteristics. Firstly, it must capture the essential features and properties of the language it is modelled in. That is, a Meta Model should be capable of describing a language’s concrete syntax, abstract syntax and semantics (Clark et al, 2008). Secondly, a Meta Model must be part of a Meta Model architecture (Clark et al, 2008); these architecture enables a Meta Model to be viewed as a model which itself has been defined by another model. Irrespective of how it is written; ‘metamodel’ or ‘meta model’ or ‘meta-model’, it is similar to a regular domain model. A meta model can be viewed from three different perspectives; (1) as a set of building blocks and rules used to build models, (2) as a model of a domain of interest, and (3) as an instance of another model (InfoGrid). The relation between a model and its meta equivalent is that between an instance and a class when dealing with ontology. When we try to model a set of related system belonging to the same domain, it is often realized that these models share many constructs. Meta modeling is about looking through these constructs and generalizes across these different models to come up with a model of what the related models should conform to.

7

Theoretical Background

Figure 1: Relationship between model and meta model systems (Miilen, 1999) 2.2.1

Characteristics of Meta Models

A model is an immaterial representation of an object system and it is created for the purpose of a subject, relating to two systems together and consisting of three components (Miilen, 1999) which are; The object system represents the subjective interpretation of a selected part of the real world (domain of discourse) including the relevant part of the environment. The model system represents the subjective representation of the object system. A syntax (notation, language) is needed to create the model system. The projection formulates the relationship between the object system and the model system. From the diagram in Figure 1, if a model system M1 represents the object system of a model system M2, then the model system M2 represents the meta model system of the object system M1 is based upon (Miilen, 1999). Hence, because of this abstraction, meta model is seen as a design framework that describes the basic elements and the relationships between the model elements and their semantics. In addition, this design framework also defines the rules for use and specialization of models elements and their relationships. In the context of information modeling, meta models are used to describe notations. Meta data models characterize notations that can be used for information modeling purposes. Meta process model can also be used for describing modeling process using specific method. Hence, every meta model is based on another meta model which can be of the same kind (Miilen, 1999).

8

2.2.2

Why Meta Model?

As meta model is itself a model, its syntax and semantics are usually governed by the form it is described in and that form can thus be modeled in a meta-metamodel. Meta models possess all the attributes of a model itself. It can be used for reasoning, for manipulating, designing, for implementation and its properties can be formally proven. One benefit of meta modelling is its ability to describe the languages it is modelled, in a unified way. This means that the languages can be uniformly managed and manipulated thus tackling the problem diversity (Clark et al, 2008). Another benefit is the ability to define semantically rich languages that abstract from implementation specific technologies and focus on the problem at hand (Clark et al, 2008). With the use of meta models, different abstractions can be defined and combined to create new languages that can be tailored for a specific application domain thus improving productivity results.

2.3 Information Demand Information demand is a recently emerging area in the IT industry. It is a users’ need or demand for information. The ability to provide users with information to certain locations at a particular point in time is not of much value if the information the user really needs is unknown (Lundqvist 2004). Organizations, agents, persons or systems demand information from a variety of sources and this demand is often connected to a task. Readily available information is a crucial basis for making decision, solving problems, or performing knowledge work (Lundqvist et al. 2005) and ensuring that the information gets to the right place at the right time is also of necessary importance. Hence, providing such information to meet the needs of the user has to based on an accurate, purpose-oriented and up-to-date representation of the demand in question (Lundqvist et al. 2005). In order to capture an understanding of information demand, information need is a concept that helps us to understand different situations to information seeking by individuals with the same or similar task. Thus information demand can be defined as: Information demand is the constantly changing need for current, accurate and integrated information to support (business) activities, when ever and where it is needed – Lundqvist & Sandkukl (2004) According to Lundqvist (2005) when analyzing Information Demand, different aspect based on the definition needs to be considered such as: • changing means that the resulting models need to be able to capture the dynamics of information demand in order to reflect changes over time.

9

Theoretical Background

• current and accurate requires some form of quality and relevance measurements • integrated as well as (business) activities implies a need for awareness of the context in which the demand exists as well as some mechanism for understanding when a switch in context takes place. When ever and where ever states the importance of timing and location aspect of the information demand are important to analyze. 2.3.1

Determinants of information demand

It is interesting to note also that there are factors that determine our information demand, such as described by Lundqvist et al. (2005) can be likening to: • Topic of interest: This has to do with studying a subject (disciplines and sub disciplines) of interest. Information on the definitions of the subject concerned are collected from different authoritative sources bringing out similarities and differences, scope of the subject that are tool subjects and are applicable for development are demanded for. • Task we are working on: This is achieved when we source for information relevant for the required task we are working on. Information can be from directories, handbooks, review documents, databases etc. • Skills and education background: This is about why do people need information? People’s need for information can be viewed as what is needed to fulfill basic human need and acquire knowledge. • Role and position: This is often the function or part a person or thing plays in a particular situation to ensure the information meets the demands. • Time relevant to an even: In order to provide information necessary for any task, time is necessary the information to meets its purpose. • Location: The location of the user requesting for information is taken into consideration at the moment some particular information is needed. • Social environment: This has to do with social gatherings like seminars, conferences, symposiums and the like where certain subject matters are discussed in order to meet certain requirements. 2.3.2

User profiles

In demand oriented information, the need and preferences of a user are usually captured in order to satisfy their demand for information. One of the approaches used for this purpose is the user profile. User profile is a collection of personal data in a predefined structured way associated to a specific user by taking his/her different personal characteristics into account. The profile are usually created for functionality provided by a specific application, service or system (Lundqvist et al. 2005), thus enabling the system to behave in a personalized way. The capability to model a user profile is at the heart of personalization systems Zeina et al. (2007) because it can be used to sort and organize result query results during filtering. Adaptation of such profiles requires either an explicit adjustment of the preference

10

Theoretical Background

values by the user, or involves deducing attribute values for a specific user through logging and interpreting of user actions (Setten et al. 2002). Applying user profiles for representing information demand requires a relatively large set of attributes, as the profile should cover all perspectives given in the information demand definition, like content, time, location or quality (Lundqvist et al. 2005). 2.3.3

Situation-based

The second approach of the demand oriented information to consider when capturing the need and preference of a user is the situation based approach. This approach depends on current events and the environment. It is achieved by dividing a user’s daily schedule into several situations that comprises a duration of time, topics of interests, and if relevant, location, as well as technical resources available for receiving or retrieving information it is possible to decide under which circumstances a user can manage information needed to perform specific tasks (Levashova et al. 2006). However, situation-based captures aspects of users information demand like the time, location and context which makes it more sophisticated when compared to user profile. Information value is a relation between a message and a situation, which is based on relevance of the topics of a message for the situation, utility of the message in specific situations and acceptance (Lundqvist et al. 2005).

2.4 Information Demand Context Context is under what circumstance the communication will be received, interpreted or consumed (Lambert, 2009). There have been some problems associated with information demand independently of the organization, and the effect of these problems can be reduced relatively simply to visualizing the flow of the demand for information within the organization. Lundqvist et al. (2009) went on to summarize these problems as follows: • Superfluous Information: This is the constant flow of information to roles even if there is no need for it. The reason might be that information once needed, but the demand of that information changed over time. • Gap in the Information Flow: This occurs as a result that information supplied is not getting to the desired destination that is, the roles that needs the information are not receiving it. The reason for this might be lack of technical support, roles supplying the information is not aware of the roles needing the information or the roles demanding the information do not know how the information is distributed or where it is available. • Information Gathered at the Wong Time: The reason can be said that roles which are meant to gather information at the right time is not aware they should. • Outdated and/or Incorrect Information: This is when individuals do not use the correct source of information.

11

Theoretical Background

In order to solve the above mention problems, attempts are made to capture and support business activities of an enterprise/organization in terms of identification, distribution and management of information necessary for information demand. Hence the concept of information demand should be seen as role-based that is defined by the responsibility it has within a specific context. According to Dey (2001): Context is any information that can be used to characterize the situation of an entity. An entity being a person, a place or object that is considered relevant to the interaction between a user and an application including the user and the application themselves. Furthermore, in order to be able to support business activities by providing integrated information, which is the intended purpose of demand-driven information supply (Levashoval et al. 2006), the various organizational roles having the demand and for what task the information is demanded as well as the setting in which such task are preformed (Lundqvist et al. 2009) need to be considered. This has to do with the information flow; that is providing the right information to the right user, at the right time and place. In the light if this, ID Contexts can be defined as: An Information Demand Context is the formalized representation of information about the setting in which information demand exists and comprises the organizational role of the party having the demand, work activities related, and any resources and informal exchange channels available, to that role – Lundqvist 2009

Figure 2: Conceptual refinement of information demand contexts. (Lundqvist 2009) Role is considered to be the central concept when analyzing and modeling information demand. (Levashoval et al. 2006). The figure 3 above shows the relationship the aspect ‘role’ has in a given information demand context with that of other context-related concepts. This enable us to identify, model and analyze ID when building various solutions for providing demand-driven information supply. Thus, understanding information demand requires the understanding of

12

Theoretical Background

information demand contexts; as it allows for all activities performed by a specific role to be grouped together with any relevant resources for doing so (Levashoval et al. 2006) 2.4.1

Role

The concept role may be played by an individual or organizations units in different context. The New Oxford American Dictionary (NOAD) define role as the function assumed or part played by a person or thing in a particular situation. Roles may belong to one or more organizational unit and may be generalized or specialized to perform processes and may also be responsible for performing processes and achieving desired goals. From ID contextual perspective, the concept role is defined as a function of the assignment of task within as area of responsibility to an individual or group of individuals (Lundqvist, 2007) 2.4.2

Task

New Oxford American Dictionary (NOAD) define task as a piece of work to be done or undertaken. Task can also be any piece of work that is undertaken or attempted or a specific piece of work required to be done as a duty or for a specific fee (WorldNet). Task may at times require a role to utilize a specific resource to fulfill a relevant task which can be performed during a time interval and at specific location. From ID contextual perspective, task is defined as the smallest possible set of activities performed by a single role, fulfilling a specific goal, requirement or purpose expressed by a responsibility (Lundqvist, 2007). 2.4.3

Responsibility

The concept of responsibility shows the relationship between roles and between roles and the business processes (tasks). It defines the task to be performed within the organization and also the different roles individuals have to take in accordance to the goals defined by the organization(Lundqvist, 2007). Responsibility as often defined, can also said to be the state of being accountable for something, the ability to independently make decisions, the state of having duty or a thing that one is required to do as part of a job, role or legal obligation (Lundqvist 2007). Responsibility can thus be transferred or delegated among role. From ID contextual perspective, the concept of responsibility is defined as the set of all activities to be performed by a role in accordance to organizational requirements and goals (Lundqvist, 2007). 2.4.4

Resources

Resources can be any physical or virtual entity of limited availability that is required to perform a task. But from the concept of information demand, resources are those entities that provides or facilitate access to information and the availability of resources might also constitute information. From ID contextual perspective, a resource is a device or entity that contains or provides access to

13

Theoretical Background

information relevant when performing a specific task and therefore utilized by specific roles (Lundqvist, 2007). 2.4.5

Information (Object)

The availability of information leads to fulfilling the demand of a role as defined by the task that role performed. Information is any kind of representation of externalized knowledge stored and provided by a resource of some kind which might be used as a role when performing a task or produced as a consequence of a task being performed (Lundqvist, 2007). From ID contextual perspective, information is the externalized representation of knowledge needed by a role when performing tasks and such information can be a procedural type, i.e. descriptive in nature or of an operational type, i.e. declarative in nature (Lundqvist, 2007)

2.5 Business Process Modeling Notation (BPMN) Business Process Modeling Notation (BPMN) is one of the most common processes currently promoted in the world for business process modeling. It is a visual process notation standard from the OMG1, endorsed by WfMC2 and broadly adopted across the industry*. Developed from the Business Process Management Initiative (BPMI), the BPMN 1.0 was released in May 2004 (White, 2004). The development of BPMN was influenced by the demand for a graphical notation that complements the BPEL standard for executable business processes (Muchlen & Recker, 2008). The reason for introducing BPMN in this thesis work is to show and explain how process flow in BPMN like every other process notations as shown in section 2.7 below gives a good example of how one can express the mapping relationship between any process diagrams to its associated construct. BPMN as a modeling notation, talks about midway between a procedure modeling notation, a process modeling notation, and information from data modeling notation. It defines business Process Diagram (BPD), which is based on a flowcharting technique tailored for creating graphical models of business process operations (White, 2004).

1

Object Management Group (OMG) http://www.omg.org/

2

Workflow Management Coalition (WfMC) is a global organization of adopters, developers, consultants, analysts as well as university and research group engaged in the work flow and BPM. http://www.wfmc.org/ * http://www.wfmc.org/xpdl.html

14

Theoretical Background

Thou, it has the familiar looking feel of traditional swilling diagrams but add powerful new features like events to allow exceptions the hidden cost of real world business processes to be modeled explicitly in a diagram giving business process a voice in describing how those exceptions should be handled. Support for events also makes BPMN a better fit to today’s so implementation architecture than traditional process models.

Figure 3: Simple BPMN diagram (White, 2004) BPMNs primary goal is to provide a notation that is readily understandable by all business users, from the business analyst that create the initial drafts of the processes, to the technical developers responsible for implanting the technology and finally, to the business people who will manage and monitor those processes (White S, 2004; Muchlen & Recker, 2008). Another goal of BPMN is to ensure that XML language designed for the execution of business processes can be visualized with a business-oriented notation (OMG). Many existing BPM notations primarily focus on technical process aspects including the flow of activity execution/information and/or resource usage/consumption (Yu E, 1995). This perspective is aimed at describing the sequence of activities, events and decisions that are made during process execution. (Bhuiyan & Krishna 2010).

2.5.1

BPMN Basics

Processes in BPMN are represented using graphical elements or constructs which enable the easy development of simple diagrams. There are about 53 constructs defined by BPMN plus attributes which are grouped into four basic categories: flow nodes like events (circle), activities (rounded boxes) and decisions (diamonds); connecting objects such as flow links (un-broken directed lines) and message flow links (broken directed lines); swim-lanes such as pools (high-level rectangle container) and lanes partition pools and artifacts (Bhuiyan & Krishna 2010). This is shown in the diagram below:

15

Theoretical Background

Figure 4: BPMN main symbols (Bhuiyan & Krishna 2010)

2.5.2

BPD Set

The tables 2, 3, 4 and 5 below displays a few set core elements of business process modeling or concepts that could be depicted through a business process modeling notation (White, 2003). Flow Objects: These are the main describing elements within BPMN, and consist of three core elements (Events, Activities, and Gateways) Element Event

Activity

Gateway

Description

Notation

A Event is something that “happens” during the course of a business process represented by a circle, these events affect the flow of the process and usually have a course trigger or a result. They can start, intermediate and end a flow. An Activity is work that is performed with a business process. Activities are rounded rectangles that can be performed once or have internally defined loops. Task and sub-process are activities that are part of a process model. Gateways are modeling elements that are used to control how Sequence Flows interact as they converge and diverge within a Process. Table 2: Core BPD Flow Objects (White, 2003)

16

Theoretical Background

Connecting Objects: These are connected together to create the basic skeletal structure of a business process. Element

Description

Notation

Sequence Flow Represented by a solid line with a solid arrow head, Sequence Flow is used to show the order that activities will be performed in a Process. The source and target must be one of the following objects: Events, Activities and Gateways. A sequence cannot cross a sub-process boundary or a Pool boundary.. Message Flow A Message Flow is used to show the flow of messages between two entities (separate pools) that are prepared to send and receive them. Message Flow are not allowed between object within a single pool but can connect to boundary of the pool or to an object within the pool. It is a dashed broken line with open arrowhead. Association An Association is used to associate data, information and artifacts with flow objects and it shows how data is input to and output from Activities. It is represented by a dotted line with a arrowhead. Table 3: Core BPD Connecting Objects (White, 2003)

17

Theoretical Background

Swimlanes: BPMN uses the concept of “swimlanes” to help partition and organize activities. There are two types of swimlanes as demonstrated by White (2003): Element Pool

Lane

Description

Notation

Pools represent Participants in an interactive Business Process. A participant is either a business role (e.g. ‘buyer’ or ‘seller’) or a business entity (e.g. IBM). Interactions in Pools are handled through Message Flow and the Sequence Flow cannot cross the boundary of a pool (i.e. a Process is fully contained within a Pool). A Lane represents sub-partitions for the objects within a pool and will extend the entire length of a Pool either vertically or horizontally. They represent organization role (e.g. Manager, Associate), but can also represent any desired process characteristics. Here, Sequence Flow can cross Lane boundaries. Table 4: BPD Swimlane Objects (White, 2003)

Artifacts: These notations provide the capability beyond the basic flow-chat structure of the Process as shown by White (2003). Element

Description

Notation

Data Objects

Data Objects are Artifacts that are used to show how data and documents are used within a Process. They are used to define activities’ input and output and can be given a “state” that shows how a document may be changed or updated within the Process.

18

Theoretical Background

Groups

These are also Artifacts that are used to highlight certain sections of a Diagram without adding constraints for performance as a Sub-Process would. Groups are not restricted by Pools and Lanes and can be used to categorize elements for reporting purposes.

Annotations

Text Annotations are a mechanism for a modeler to provide additional information about a process and it can be connected to a specific object on the diagram with an Association Table 5: BPD Artifacts Objects (White, 2003)

2.5.3

BPMN Limitations

The BPMN specification provides a model for business analyst and It to collaborate but however still has some limitations. First, it does not include organizational structure and resources and their functional breakdown. BPMN shows the flow of data and association of data to artifacts but it is not a data flow diagram; hence it is not also possible to describe the data that are manipulated and the data transformation in the process in a BPMN. This is usually left to the discretion of the BPMN designers. Secondly, BPMN specifies notations only but does not provide a wire interchange format that is it is not possible to export a BPMN diagram from a tool and import it to another one in a standardized manner (Crusson, 2006). This serves as a big limitation for BPMN as its scope is big that no tool will be able to provide all required functions and it is where XPDL or XML could be applied (Crusson, 2006). 2.5.4

Uses of BPMN

BPMN is simple a notation for diagrammatic processes. It is not a modeling method because it does not tell how to start, how to proceed or how end up in a right place. Rather it is designed to cover many types of modeling and allows creating of process segments as well as end-to-end processes (White, 2004). used to communicate a wide verity of information in a simple, understandable

19

Theoretical Background

diagrammatic way by supporting the various levels of a process model which are: Process Maps – simple flow chats of the activities; Process description – flow chats extended with enough information; and Process model – flow chats extended with enough information so that the process can be analyzed, simulated and/or executed. White (2004) elaborated two basic types of models can be created from a BPMN: • Collaborative (Public) B2B Processes • Internal (Private) Business Process

2.5.4.1

Collaborative (Public) B2B Processes

A collaboration process depicts the interactions between two or more business entities (White, 2004). These interactions are defined as a sequence of activities that represent the message exchange patterns between the participants involved in the interaction. The collaboration process can be shown as two or more abstract processes communicating with each other (see Figure 5 below) and it defines the interactions that are visible. With an abstract process, the activities for the collaboration participants can be considered the “touch-points” between the participants (White, 2004). The actual (executable) processes are likely to have much more activity and detail than what is shown in the abstract processes.

Figure 5: An Example of a Collaborative B2B Process (White, 2004) 2.5.4.2

Internal (Private) Business Process

The internal business process focuses on a single business organization. They define the activities that are not generally visible to the public which actually makes them private and also often show interactions with external participants. If swimlanes are used, then an internal business process will be contained within a single pool (White, 2004) thus making the he Sequence Flow to be contained 20

Theoretical Background

within the pool and cannot cross the boundaries of the pool. When the Message Flow crosses the boundary, this shows the interaction between separate interaction business processes. Hence, a simple Business Process Diagram may show multiple private business process each with a separate mapping (OMG).

Figure 6 – Example of Private Business Process (White, 2004)

2.6 Extensible Markup Language (XML) XML is a software- and hardware-independent tool for carrying information (W3C 2011). Keogh & Davidson (2005) gave more emphasis to the definition by stating that XML is a language that is used to represent data in a way that it should be easily shared among different applications running on different operating systems. It enables the structure of information to be represented in an open, system-independent form. Designed to transport and store date, it enables users to define tags by prescribing only the syntax (how tags look and how they are used) and not the semantics (what they mean), stated McDonald et al (2006). XML is derived from SGML (Standard Generalized Markup Language), which provides hierarchical structure that makes it easy to use. Furthermore, it is a standard, simple, self-describing way of encoding text and data so that its content can be processed with relatively little human intervention and exchanged across diverse hardware, operating systems and application (Software, 2011). The extensibility feature of XML can be used to create other markup language where tags can be defined and used by individuals to surround or mark up text. 2.6.1

XML Document Structure

XML document possess both a logical and a physical structure. The logical structure of an XML document allows elements to be contained within a root element comprised of parents, children and siblings (McDonald et al 2006) and the boundaries are delimited by tags or empty elements. The physical structures of XML documents consist of storage unit which are called entities that have contents identified by entity name. XML is a metalanguage which can create other markup languages. Markup give meaning to documents while markup language is a set of rules (ICommerce, 2010) for marking or tagging content –text, graphics or elements. Tags are used to identify elements and contain attributes about the elements. Example of an XML element is provided below where is the opening parent tag to the elements Requiem and Mozaet and is the closing tag.

21

Theoretical Background

Requiem Mozart Figure 7: Example of XML document structure (ICommerce, 2010) 2.6.2

Design Goals for XML

XML was developed by the W3C as a way to create markup languages to meet the needs of developers Kyrnin (2011). The 10 design goals as defined by W3C describe how elements and attributes should be written when using XML and these are: 1. 2. 3. 4. 5.

XML shall be straightforwardly usable over the internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write programs which process XML documents. The number of optional features in XML is to kept to the absolute minimum, ideally zero. 6. XML documents should be human-legible and reasonably clear. 7. The XML design should be prepared quickly. 8. The design of XML shall be formal and concise. 9. XML documents shall be easy to create. 10. Terseness in XML markup is of minimal importance. Furthermore, XML view of the structure of information is that represented by a tree having a root which contain the unit of information, the document containing the subordinates and each subordinates having sub-units as depicted in figure 7 above. 2.6.3

Why use XML

XML is wide spread with the change of time through different technologies in many aspect of web development for data storage and sharing. There are many reasons coupled with the advantages it offers that makes organizations to adopt its usage. Some of this reasons are stated below: 1. XML is very simple, flexible and easy to learn without the training in IT. Keogh & Davidson, (2005) argues that the flexibility of XML allows users to update and structure the XML document without breaking existing processes. 2. XML is designed to be self descriptive (W3C 2011), meaning that you can create your own tags, or use the tags which have already been created; this make XML is an extendable language as the markup symbols are unlimited and self-defining

22

Theoretical Background

3. XML is portable, accessible and precise. W3C (2011) XML specification states that a XML document stop processing once an error is detected.

2.7 XML Process Definition Language (XPDL) XML Process Definition Language (XPDL) is a language proposed by WfMC to interchange process definitions between different workflow products. It is s standard XML based process design format for application exchange of different Business Process definitions among various process workflow and modeling tools (Toolbox.com 2011); so it uses an XML-based syntax specified by XML schema used for specifying the declaration part of workflow in a business process. BPMN only defines how process definition are displayed on the screen but how the process definitions are stored and interchanged is outside the scope of the standard of BPMN, and this where XPDL comes in (Aalst, 2003). The main objective of XPDL is to store and exchange process diagram enabling serialization of BPMN and also any other process model or process design tool which are compatible to and capable of using XPDL meta model definitions (Toolbox.com 2011). It also provides a file format that supports every aspect of the BPMN process definition notation including graphical descriptions of the diagram, as well as executable properties used at run time. With XPDL, it is possible for a product to write out a process definition with full fidelity and another product can as well read it and reproduce the same diagram that was sent. XPDL’s extensibility feature allows for different tool to store implementation specific information within the XPDL and also preserved those information values even when it is manipulated by tools that do not understand the extensions thus providing for a “round trip” and still return the original tool with complete fidelity. 2.7.1

XPDL Goals

XPDL is a process design format based on XML, and contains extensions in order to be able to represent all aspects of BPMN. Basically, a process can be designed in a modeling tool using the BPMN notation, then be exported in the XPDL format (XML document), and opened with another tool, for example a process simulation tool, with exactly the same layout (Crusson, 2006). According to WfMC (2008), the goals of XPDL can be sated as follows: ¾ Allow tools to exchange process models ¾ Format to exchange Process Definitions between o components in a Workflow/BPM Products o different BPM/Workflow Products o Process Modeling / Simulation tools and BPM/Workflow Products ¾ Implemented by commercial products

23

Theoretical Background

¾ Interoperability demonstrated by WfMC member organizations at public events 2.7.2

XPDL Requirements

The requirements of XPDL according to WfMC can be categorized into the following: 1. Large variety of tools • Many differing requirements on what must be stored • Not acceptable if XPDL could store only a subset • Must be able to store all the information 2. XPDL is extensible • Handle information used by a variety of different tools 3. Different dialects of XPDL • Use extended attributes to define vendor specific features 4. Can transform from one dialect to another 2.7.3

Structure of XPDL

The WfMC has been developing workflow specifications for many years and these specifications are designed for the developers to implement solutions that are consistent, complete and interoperable with other systems (White, 2004). XPDL uses the format and structure of XML which is formal, concise, human-legible and reasonably clear. Mostly, XPDL’s structures are from the translation or transformation of business process models notations. WfMC (2011) demonstrated with an example a simple business process model that has a start node, an activity node and an end node and its associated XPDL construct. The arrows 1 and 2 shows the translations linking the events and activity together.

Figure 8: Simple BPMN Process (WfMC 2008) However, all nodes in the diagram above are represented with an tag and each activity has a name and an ID which has to be unique. Thus omitting the over XPDL structure of model, the structural representation can be shown as this:

24

Theoretical Background

... ... ...

Furthermore, representing the arrows in the model with tag removing the over XPDL structure of model, the structural representation can be shown as this: ...

2.8 Mapping Mapping describes how models or programs in one language are transformed or related to models or programs in another. No languages exist in isolation as they often have a relationship to other languages. According to Clark et al (2008) this may be via translation (concepts in one language are translated into concepts in another language); semantic equivalence (a language may have concepts whose meaning overlaps with concepts in another language) or abstraction (a language may be related to another language that is at a different level of abstraction).

2.9 Related works Since XPDL is a new field of area in the information technology sector and there are limited works that’s has been done. White (2003) demonstrated how BPMN process notation for E-Order can be mapped to XPDL. The BPD presented is a process for a customer order electronically (White, 2003). Part of the process diagram is taken and shown below.

25

Theoretical Background

Figure 9: The Start of the E-Order Process (White, 2003)

Based on the diagram above, the order data is sent through an application where the data is transformed through a “Transform Data” task to return result. During the process transformation, the Task may generate a Process Error as showed by the Intermediate Event attached to the boundary of the Task which may in turn rise an alarm (White, 2003). If the data is transformed properly, then a task that uses the application to check the data is performed. The order information is then passed and the status information is returned. After the “Check Data” task, the process continues to a decision and follow-up tasks (White, 2003). 2.9.1

Mapping to XPDL

White (2003) defined some XPDL constructs for the E-Order process models based on the notations used in the model. The BPD objects the properly mapped to XPDL as shown in the figure below. Each activity is given a unique id for identification. The Task is mapped to the implementation activity and its name and implementation elements (White, 2003). The Intermediate Event attached to the boundary of the Task results in an XOR Split TransitionRestriction within the implementation activity. TransistionRestrictions is used in implementation activities for exceptional and compensation handling (white, 2003). The exception flow transition thus have a Condition of type “EXCEPTION”.

26

Theoretical Background

Figure 10: The Start of the E-Order Process and the Object Mappings to XPDL (White, 2003)

2.9.2

XPDL Code for E-Order Process

Based on the mapping in section 2.8.1, a XPDL structured that reflects the portion of the E-order Process is generated (White, 2003) and stated below:

27

Theoretical Background

Figure 11: XPDL sample for E-order process (White, 2003)

28

Methods

3 Methods This chapter presents the overall strategy i went about in addressing the topic of discuss and providing solution to the research problem. The subject matter is more of research as I will not be developing any tool for information demand. The method of collecting data for this thesis work was more of explicit knowledge. Data were collected from books, databases (Julia), documents, Journals and papers and then analyzed. There was also need for an intensive study of different materials to be able to understand the subject matter and make a literature review. The first step was the drafting of my synopsis which stated my concept building where I had to construct my research questions and give the purpose for my work. Furthermore, a thorough review of necessary literatures were made to get an understanding of the research work and what effect has been done by scholars so far in the field. This implies that I search, found, synthesized and documented the exiting knowledge in order to identity the scope of the work. Major concepts like meta models, BPMN, ID context and XPDL were majorly studied and presented above in the theoretical background section. Based on the knowledge and understanding acquired from my study of XML and the ID context model example given, I started to define XPDL constructs for the different notations blocks of the process flow diagram example. These constructs were defined in a way so suit the example Information demand context model diagram and flexible enough so that a particular construct can as well be used in another role where it has also been used by another activity. In order to show how my developed constructs works on the given case model, I had to draw out the model layout again using Microsoft visio to enable me give id-tag numbers to the different concepts of notations. These id-tag numbers serves as primary keys for the various activities that are being performed in the process flow diagram.

29

Implementation and Results

4 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.

4.1 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.

30

Implementation and Results

• 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.

Figure 12: Information Demand Context Model

31

Implementation and Results

4.2 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).

4.3 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.

Mapping to XPDL

Element notation Role





32

Implementation and Results

Task



Organization Unit



External Party



Information Object

Resources:



Note



Flow

For example:

Indirect flow