Business Process Modelling with OBPM: Combining Soft and Hard Approaches	
	
Fahad Al-Humaidan	
Computing Science, Newcastle University, Newcastle upon Tyne NE1 7RU
Fahad.al-humaidan@ncl.ac.uk	
Nick Rossiter	
Informatics, Northumbria University, Newcastle upon Tyne NE1 8ST
nick.rossiter@unn.ac.uk	
Keywords:	Methodologies, soft systems, hard aspects, business process modelling. 
Abstract:	Following an evaluation of current methodologies for business process modelling, it was concluded that a combination of soft and hard approaches was needed to handle both human and technical factors. The new approach, termed Organisational Business Process Modelling (OBPM), combining a soft systems methodology (SSM) and an object-oriented modelling language (UML), is described. The basic stages involve a detailed determination of the requirements, mainly using soft techniques, followed by a detailed analysis, mainly using hard techniques. The soft and hard techniques are integrated through a mapping from the conceptual model of the soft approach to the use cases of the hard approach. A comparison is made of the outcome from our approach with that from other business process approaches, particularly the Organisational Process Model (OPM) of Warboys. OBPM has significantly added capability in covering hard aspects while still being proficient in soft aspects. 

1	INTRODUCTION
It is generally accepted that complex information systems require a methodology to take their development forward from the initial requirements of users to an implemented documented functioning system, which satisfies the end-users in its functionality and interface. Many kinds of methodologies have been proposed since the 1970s in the area of systems analysis. 
Initially methodologies concentrated on tangible aspects of user problems, that is concepts, which could be readily represented by program code and data structures.  However, such aspects form only a part of the whole user problem. In effect any information system has two aspects namely hard system and soft system. The hard system part includes several elements such as data, events, processes and interfaces. The system also needs some resources (people, money and equipment) to achieve the required objectives that should possess certain qualities. The soft system part includes several elements such as the identification of the problem, the user involvement, the organisational structure, goals and policies, the employee job satisfaction, different points of view, the employee’s values, and the system acceptability and usability.
 In earlier reports (Al-Humaidan & Rossiter 2001, 2002) we developed a taxonomy covering 14 different classification features for methodologies targeted at the workflow area. Features identified include concerns, method structure, data gathering means, people involved, notations, decomposition, policies, reuse, adaptability, flexibility, exception handling, method output, CASE tool and quality assurance. The capabilities of a number of methodologies were expressed in tabular form relative to this general taxonomy dealing with both hard- and soft-system aspects.  It was concluded that there is no methodology that covers all the features in the taxonomy. So it is advisable or recommended to combine some of these methods. Soft Systems Methodology (SSM, Checkland and Holwell 1998) is used to deal with soft system issues and the other methods such as SSADM and UML (Booch 1999, Rumbaugh 1999) are used to cover the hard system issues. SSM is used as a front-end method to develop an information system or a workflow system. Bustard, Dobbin  & Carey (1996) also came to the conclusion that SSM and object-oriented modelling techniques were complimentary. 
2	OBPM: Organisational Business process modelling 
Our intention is to develop an approach OBPM using Organisational Business Process Modelling. The Organisational Business Process is defined as follows. Each organisation has objectives and goals that it tries to achieve. These objectives can be achieved through carrying out the organisation business process. The business process consists of different parts or elements. 
There are many definitions for the business process. Here we consider the business process is ‘a set of partially ordered steps intended to reach a goal’. The business process is ‘the transformation of something from one state to another state through partially coordinated agents, with the purpose of achieving certain goals that are derived from the responsibility of the process owner’ (Feiler & Humphrey 1993).  
The business process consists of the following elements: ordered activities, human and computerised resources, constraints and business rules, a set of related artefacts and organisational structure. These elements aim to achieve the organisation goals and objectives.
The business process can be defined from different views such as:
•	the functional view that deals with the process activities and information flows;
•	the behavioural view that specifies when and how the activities are performed;
•	the organisational view that considers where and who will perform the activities;
•	the informational view that deals with the informational entities (Warboys et al. 1999).
Technology is an important aspect in an organisation, which allows an organisation to respond quickly to the changing environment of the business. The organisation is trying to achieve a competitive advantage through supporting its business process by the suitable latest technology in the market. One aspect of the technology is a software system, which is used to support the business process. The organisation acquires software systems through purchasing information system packages or developing new software systems.
  The development of software systems is a complex process that requires skilled developers, a methodology or method and supporting tools. The development process should consider the organisation and its environment. Also, it should consider soft issues of the organisation that deal with the people or human aspects and hard issues that deal with the more tangible aspects.
3	DETAILS of OBPM
The OBPM methodology is concerned with the requirements capture and the analysis stages of the development process. The first phase is requirements capture which is performed to investigate and analyse the organisation or the problem situation  and the second stage is the analysis of the problem domain of the developed system. 
The approach uses SSM to analyse the organisation and to deal with the soft issues. Unified Modelling Language (UML) as a part of object-oriented technology, is used to deal with the hard issues. This approach may increase the time for requirements acquisition but it is important to include the requirements of the interested people in the system. 
In our approach, the Soft Systems Methodology (SSM) is used as a framework and the Unified Modelling Language (UML), which is a de facto standard modelling language of the object-oriented paradigm, will be embedded into it. 
This approach will cover two stages of the traditional system development life cycle: requirements capture and analysis. Through this approach the organisation business process will be modelled and supported by Workflow Management System (WFMS). 
3.1 Requirements Capture
This stage of the approach will be dominated by the Soft Systems Methodology (SSM) to study the organisation, its business process and the various issues that are related to it. SSM is used when requirements are unclear, there are conflicting interests or the proposed system is contentious. Also, SSM is applied when there are changes in organisational structure or business processes (Agency 1993). In addition, SSM supports the broad view about the situation and the strategic planning for business improvement (Bustard, He et al. 1999). Soft Systems Methodology (SSM) is used in information system design for several reasons such as: 1) the failure of the conventional methods to develop an information system that considers all organisation issues and 2) to deal with the human aspects of the organisation. The requirements capture includes the following steps.

Step 1: Investigation of Problem Situation
The problem situation, which is the organisation and its business process, are investigated and modelled by using the rich picture technique of SSM. This technique assists in improving some of the soft issues, which concentrate on understanding the problem situation, the organisational structure, goals and policies, and the user involvement to gather information and on discussing the problem situation in order to get a clear picture of it. The user involvement will promote the acceptance and usability of the result system.
Step 2: Identification of Mission
The main mission or purpose of the organisation is identified and is used to develop the root definition. This step includes some discussion and debate with the people who have different views regarding the main mission of the organisation. The root definition, representing the organisation mission statement, should be validated by using some rules:. 
•	the root definition should be one sentence in which the major verb represents the transformation process describing the organisation purpose; 
•	the overall structure is tested by using the mnemonic CATWOE; 
•	the elements T (Transformation process) and W (World view) must be identifiable in every RD Root Definition) while the other elements are optional (Wilson 2001).
Step 3: Construction of Conceptual Model
A conceptual model or Consensus Primary Task Model (CPTM) is constructed to represent what such a system would have to do to be the one that is defined in the root definition. The conceptual model or CPTM should contain all the activities, which satisfy the root definition. 
The developed conceptual model should be validated and tested by the rules of the Formal System Model (FSM).  These rules include:
•	complete logical consistency between the activities in the model and the purpose as stated in the root definition;
•	complete logical connections among the activities of the model because it is a system;
There should be monitor and control activities in the model to monitor the performance, collect information and take control activity to rectify any deficiency in the system. The conceptual model consists of the different activities and the logical dependencies among them. 
Step 4: Comparison of Model with Current System
The conceptual model is compared with the current system to identify any missing activities, processes, or introduce new technology and to specify the required change.
Step 5: Conversion of Consensus Model to Use Cases
The activities of the conceptual model or consensus model are examined to convert it to use cases technique that is part of UML, which is the standard notation of object-oriented paradigm. This will be discussed in the next section.
3.2	The transition from SSM conceptual models to UML use cases
An important question for the approach selected is how to integrate the soft and hard aspects. In particular, which concepts in the soft approach map nicely into those of the hard approach? A nice mapping would be robust (all links accurately made) and simple in concept (ideally 1:1 on readily-identifiable features).  Bustard, Zhonglin & Wilkie (1999) suggested that use cases in UML were the obvious feature to link to SSM but saw a number of potential problems, including the scope of use cases: if use cases only dealt with external bodies then they would be incomplete from the total system perspective.  They suggested the connection of UML to SSM via interaction models.  Wade & Hopkins (2002) also saw problems with employing use cases in the simple way envisaged in UML but considered that they could be ‘dressed up’ to some extent. They indicated that the conceptual model in SSM should be the focal point for linking the two techniques. In our approach we also consider that the conceptual model should be the focal point and we make a mapping from activities here to use cases in UML. In order to improve on previous attempts, we give a more detailed prescription for the mapping as described below. 
The conceptual model (CPTM) and use cases techniques can be used to identify and document the different activities of a system. The intention is to convert the activities of the SSM conceptual model into use cases. Before that, it is useful to compare the activity of the conceptual model with a use case. The conceptual model represents the minimum, necessary set of activities that a system must do to be the system defined by a root definition (Wilson 1990). Cambridge Advanced Learner's Dictionary defines an activity as ‘the work of a group or organization to achieve an aim’. There is no specific definition of the activity of the conceptual model in SSM. The following definition is adopted here: activity is a part of human activity system that could be a set of actions or procedures carried out to achieve an aim. On the other hand, a use case is ‘a sequence of actions that an actor performs within a system to achieve a particular goal’ (Rosenberg and Scott 1999). Both are compared by using the three features of composition (its parts), beneficiary and goal as in Table 1. 

Feature	Conceptual model activity	UML use case	
Composition	A sequence of actions or procedures 	A sequence of actions	
Beneficiary	A Customer	An Actor	
Goal	To achieve an aim	To achieve a particular goal	
Table 1: CM activity and UML use case mapping
From this comparison, it is possible to adapt and convert the conceptual model activities into use cases through examining each activity and identifying the required information for each activity, its user and its customer. This information can be presented in a tabular form to show all the activities, their input and its source, output and its destination or target, the activity procedures or steps, the users or agents who are responsible to carry it out and the customer or beneficiary to whom the result is delivered. The list below shows the required information about each activity:

1.	Sub-system Name
2.	Activity from the sub-system
3.	Input & its source
4.	Procedure steps
5.	Output & its destination or target
6.	User or agent
7.	Customer or beneficiary

Next, these activities are mapped into activities with their customers or beneficiaries to facilitate their conversion to use cases. This step may involve decomposing an activity into two or more activities that have different beneficiaries or customers or combining some activities into one activity that has one beneficiary or customer. 
The new activities with their customers are mapped as one to one onto UML use cases. Then, the use cases of the business process will be presented in the use case diagram of UML. 
	3.3 	Analysis
While SSM prevails in the requirements capture, the Unified Modelling Language (UML) prevails in the analysis stage. UML is used to deal with the hard issues of the problem situation. This involves modelling, analysing and specifying the requirements of the organisation business process by using the different diagrams of the UML for the eventual purpose of designing and implementing the business process by a workflow system. This stage consists of the following steps.

Step 1: Analysing use cases of business process
Each identified use case from the conceptual model is considered as a part of the business process that we want to model in a workflow system. A use case contains information about the system behaviour and the organisation groups or roles that will perform this behaviour.
Step 2: Developing activity diagram for use case
A UML activity diagram is developed for each use case, which is a part of the business process that will be modelled as a workflow system. The UML activity diagram models some of the workflow perspectives that exist in the use case through the using of its features, which are suitable to model these perspectives.
Step 3: Developing sequence diagram for each use case 
A sequence diagram is used to depict the interaction of objects to carry out the behaviour of each use case. The sequence diagram is an interaction diagram that shows the time ordering of the messages. It is used to model the dynamic aspect of a system. It shows the objects, their relationships and the messages between them. It has two features. 1) it shows the lifeline of an object; 2) it shows focus of control that represents the period of time that an object is carrying out an action. 
Step 4: Developing a class diagram for the static structure of each use case 
A class diagram is used to model the static structure of each use case. The class diagram models the static part of the system by showing classes, interfaces, and their relationships. It can be used to model the different classes of the use case that collaborate in carrying out its behaviour. 
 Step 5: Developing a class diagram for the organisation structure of each use case 
A class diagram is constructed to model the static structure of the organisation, which represents the different aspects of the organisation perspective. The organisation is divided into groups and each group consists of roles, which represent the different users or agents that carry out the different tasks or activities of the business process. 
Step 6: Constructing an analysis class model
After modelling all use cases, the various class diagrams for the use cases are combined into a single class diagram, which is called an analysis class model. This model includes all the classes of the developed system. These classes will collaborate with each other to carry out the system functionality. The resulted analysis class model will be scattered and complex. To overcome the model complexity and structure it for reuse at the later stages of development, the classes will be arranged into different structures and hierarchies by using the generalisation and aggregation relationships. 
Step 7: Constructing a class model for the organisation structure 
All the class diagrams that model the organisation perspective of each use case are combined together into one class diagram, which is called the organisation structure model that depicts the whole organisation. Also, the package mechanism is used to arrange the various classes of the organisation structure model into different packages. Each package depicts one group in the organisation.
4	DISCUSSION
Table 2 shows a comparison between the Organisation Process Modelling (OPM) method of Warboys et al (1999) and the Organisational Business Process Modelling (OBPM) approach developed in this study with respect to 14 taxonomic features of soft and hard system approaches, identified as relevant for business processes in a system. The OPM method deals with some aspects of the hard system approach and most of the soft system issues. For the latter it uses some of the Soft Systems Methodology (SSM) techniques to deal with the problem. The noticeable failure of the method is its lack of facilities for representing data structures. On the other hand, the OBPM approach developed in this study covers all the soft and hard issues because it integrates the Soft Systems Methodology (SSM) with the Unified Modelling Language (UML). SSM deals with all of the soft system aspects and some elements of hard system aspects, and UML, which is an expressive modelling language, covers all aspects of the system development process and hard issue of the system.
Further work has involved the development of a case study for university course development, which has demonstrated the feasibility of the approach and which will be published in a future report. A case tool is also under development for practical assistance in applying OBPM. 
REFERENCES
Al-Humaidan, F, & Rossiter, B N, 2002, Evaluation of Systems Analysis Methodologies in a Workflow Context, 14th Int Conf Systems Research, Advances in Computer Cybernetics XI, 8-13.
Al-Humaidan, F, & Rossiter, B N, 2001, A Taxonomy and Evaluation for Systems Analysis Methodologies in a Workflow Context: Structured Systems Analysis Design Method (SSADM), Unified Modelling Language (UML), Unified Process, Soft Systems Methodology (SSM) and Organisation Process Modelling (OPM), Computing Science Technical Report no.751, University of Newcastle, 32pp. 
Booch, G., Rumbaugh, J. and Jacobson, I., 1999, The Unified Modelling Language - User Guide, Addison Wesley.
Bustard, D W, Dobbin, T J, and Carey, B N, 1996, Integrating Soft Systems and Object-Oriented Analysis, IEEE Int Conf Requirements Eng 52-59. 
Bustard, D W, Zhonglin He, Wilkie, F G, 1999, Soft Systems and Use-Case Modelling: Mutually Supportive or Mutually Exclusive? Proc 32nd Hawaii International Conference System Sciences IEEE, 8pp..
Checkland, P, and Holwell, S E, 1998, Information, Systems and Information Systems, Wiley, Chichester.
Feiler, P. and Humphrey, W. 1993, Proc 2nd International Conference Software Process IEEE, Berlin 28-40.
Rosenberg, D, & Scott, K, 1999, Use Case Driven Object Modelling with UML, Addison Wesley.
Rumbaugh, J., Jacobson, I. and Booch, G. 1999, The Unified Modelling Language, Reference Manual, Addison Wesley Longman, Inc.
Wade, S, & Hopkins, J, A, 2002, Framework for Incorporating Systems Thinking into Object Oriented Design, 14th International Conference on Advanced Information Systems Engineering, Toronto, May 27-28
Warboys, Brian, Kawalek, Peter, Robertson, Ian, and Greenwood, Mark, 1999, Business Information Systems-A process approach, McGraw-Hill. 
Wilson, B, 2001. Soft Systems Methodology, Conceptual model Building and its Contribution, John Wiley.

			Table 2: Comparison of OPM and OBPM.