COM221. Lecture 6.

Business process models

Introduction. We have met a number of different notations and techniques for describing different aspects of systems. How do we decide which to use and when? We have to bear in mind that our analysis is meant to give us greater understanding of the system we are trying to build. We can use this to discuss the draft requirements with the client. However the client will not understand our notations. He/she will probably think of things in relation to their concept of their business process and the potential solution as a collection of screens with some associated functionality with each screen, and the interconnection between them. This is why we will be best to communicate with them through the medium of mock ups of screens and scenarios of activities - in a dynamic way.

It's probably best not to show the client things like Use case diagrams, Data flow diagrams, class diagrams or the more bizarre things such as entity life histories, JSD and entity relationship diagrams. Stick to screens, forms and animations.

In these notes we will look at a model of business process and see how that relates to the screen and interface structure. Then we will take a simple application and consider the use cases and class diagrams. We will describe how the classes, their methods and the operations can be specified quite easily in VDM. This would then provide a reference point for the final requirements, a specification which can be analysed and used to generate powerful functional test sets. It is not likely that anyone would want to reify the specification - it will be too big. You could use Z equally well for the specification of the classes and operations. Neither language is much use when defining the interface - ie. the integration of the processes into a complete system.

Although most will build a solution using Access for the database, the interface to the system could be developed using an object-oriented language (Java) or something like Visual Basic. In both cases the initial part of these notes are relevant.

$1. Businesses and enterprises.

There are many ways in which a business may be modelled some of which have been made into methods supported by tools of various types. There is, however, a lack of precision about these techniques which makes them unsuitable for the sort of analysis that we wish to carry out. We will introduce an alternative and simple method which can be used to derive detailed models of the systems that we wish to build to support the business process. Many processes share the following common features:

· there is some receipt of information or data necessary for the process to operate;

· there are some aspects of the context of the business, internal knowledge of some sort;

· the process then evaluates the received data in the light of this context and produces or generates some resulting observable output, information or other product;

· the context is revised or updated ready for the next time that the process operates.

Examples of this might include the process of updating a customerís records, whereby the new information about the customer is fed into the process, the database provides the context and the output is the confirmation through printout or screen display that the record has been updated. The database updating is the context being revised in the light of the process operating. Another, higher level, example might be a factory receiving orders and raw materials, producing some artefact and delivering this to a customer together with an invoice. The context will include information about the way the factory operates and all the planning, management and production control systems that are involved.

Figure 1.1. A simple business process as a computation.

If we can identify a set Input of data that it is possible to supply the process, a set Output of possible output data and a set Memory consisting of the internal context or data associated with the process then we can model the business process as a partial function of the form:-

process: Memory Input ® Output Memory

In the cases we consider here the sets Memory, Input and Output are all discrete, and with the possible exception of the Memory, are finite.

Definition. 1 A business process is a partial function of the form:

process: Memory Input ® Output Memory

where the sets Memory, Input, Output are defined for that specific process.


Integrating business processes.

A complete business will be made up of many interacting business processes and so we have to construct a more general model that will integrate all of these functions. The organisation will be such that at any one time there will be some, many or no processes operating. in some cases one particular process must be completed before another may begin and so the complete model must reflect this. The way to do this is to arrange the processes into a dynamic network where the interrelationships between them can be described. Before we can do this, however, we need to normalise the processes into a more uniform structure.

Suppose that there are a number of processes

bpi: Memoryi Inputi ® Outputi Memoryi for i = 1,...n

(bp for business process)

We can attempt to integrate all these process functions by using a generalised finite state machine (called an X-machine). This is dependent on the degree of parallelism and synchronisation that there is amongst the business processes. In the simplest case the functions become the basic functions of a single machine model. We will call this an Enterprise model.

In each state of the system only certain of the business processes will be feasible. You cannot generate an invoice for a customer who has not been registered on the system. So the early processes will include enter_new_customer_details etc.

Fig. 1.2. A simple, abstract, enterprise model.

Definition 2. An Enterprise model is an X-machine whose basic functions are business processes. Clearly in this situation we require the Memory, Input and Output sets to be defined for the complete enterprise, which could be achieved, in many cases, by forming a global product from amongst the individual business process sets.

It is not always a simple task to put together a collection of business process functions into a coherent and co-ordinated enterprise machine model. In some complex cases it is better to construct a collection of enterprise models of subsystems of the complete organisation and then to construct a network of collaborating enterprise models. These may or may not synchronise easily with one another. This analysis may identify problems with the way the organisation operates and could suggest a mechanism for improving matters. The communication and synchronisation models built may be analysed to solve some of these problems. It might, for example, be necessary to restrict when some process can operate, perhaps they should be shared by several enterprise machines, to ensure that the overall enterprise is working effectively. There are many complex issues in this area and it is not the focus for this particular investigation. We will assume that we are dealing with a coherent enterprise model, that is one which can be represented as an X-machine.

Note that a business process can itself be representing a machine so we have a hierarchical situation which allows us to consider an enterprise as a collection of component business processes which are, in turn, enterprises and so on. This allows us to move between the macroscopic and the microscopic views of organisations thus providing us with a coherent and flexible mechanism for modelling almost any organisation and its behaviour. So, we are contemplating, the main ingredients of a business model from the perspective of computational processes and a potential computer based solution. The use of computational models is crucial, if we cannot model some business process or enterprise as a computational model we will not be able to implement the any solution relevant to the enterprise faithfully.

There are many aspects of any organisation or application that can be addressed in this way. In all cases there is data associated with the situation, and this can take many forms. This data is being processed in some way, when and how, is dependent on a number of environmental and other considerations which can change during time. It is important that we recognise this as far as possible. Many of the processes will involve and depend on the activities of people in the business. We must think about the people who might be using the system, they will need to understand what is going on and what they are expected to do.

$2. A case study.

The Problem - an education database from Date, 95.

An education database is to contain information about the courses offered by a training company, the possible attendees on the courses and the instructors who teach the courses. For each training course the database contains details of all offerings on the course. For each offering, the system is to contain details of the instructor for that offering and all student enrolments; the date and place of the offering is also to be stored. The system should allow new students to be added to the database, course and offering details and instructor details and their teaching assignments. An attendee (student) on a course will take an exam and their mark will be recorded.

2.1 The Primary use Cases.

Given the brevity of the requirements, some imagination will be required, in your case you can talk to the client to clarify things. The use cases should reflect at a high level some of the business process but without much detail.

Figure 2.1. Use cases for the education database.

new-course: details of a new course.

new-offering: details of an offering of a course.

enrol: enrol a student on an offering.

register-instructor: insert details of a new instructor.

assign-instructor: assign an instructor to teach an offering of a course.

list-offerings: list details of future offerings of a course.

register-grade: register the grade of an attendee for the course assessment.

Each one of these will represent a business process model. We need to identify the memory that the system needs to have to carry out these operations. The initial requirements statement will help us here. In this treatment we will construct a simple class structure to reflect the situation.

$3. The class model.

The next step is to construct a class model. This will define the data state - called Education. Note that we are just identifying classes and their attributes -those that we have identified at the moment. Effectively we are constructing a model of the memory the business processes we have identified in the use cases.

state Education of

where the types of the class attributes are:

Attendee.number : Attendee-no; : Name; Attendee.addr : Address.

Enrolment.number : Enrolment-no; : Date; Enrolment.grade : [Grade].

Instructor.number : Instructor-no; Name; : Telephone-no.

Offering.number : Offering-no; : Date; Offering.loc : locations.

Course.number : Offering-no; Offering.title : Title; Offering.length : Nat.

The types are defined as:


Address = ..--address as recognised by the Post office.....

Name = ..-- person's name .....

Attendee-no = ..-- unique number allocated by company.

Date = ..-- day; month, year (four figures)


[Grade] = FAIL | PASS | DISTINCTION | nil

Instructor-no = ..--

Telephone-no = ..--

Offering-no = ..--

Course-no = ..--

Location = ..--

Title = ..--

Enrolment-no = ..--


$4. Building a user interface.

We will be examining our requirements analysis and constructing a specification of the user interface which will allow for the business process to be made available in a sensible way.

Consider the initial screen. It might look like this:

Fig. 4.1 A first attempt at the first screen.

Thus clicking on the new course button will take us to a screen where the new course use case could be carried out, similarly new offering leads to that use case. The register instructor and assign instructor use cases are behind the instructor button and the attendee button leads to register-attendee, create-enrolment (which are operations that are secondary use cases within enrol) and the register-grade operation. The small buttons at the bottom will be found on most screens and are to provide system wide functions like help and exit the program.

Consider the screen that is displayed when the attendee button is pressed.

Fig. 4.2. The ATTENDEE screen.

The operations to register an attendee, enrol an attendee onto a specific course and the assignment of grades are then accessed form this page. However, perhaps we can put the marks operation on the same page as the enrol operation. The buttons at the bottom allow us to quit, to go back to the opening page and to other pages including the help page. This is not a particularly good design. Users don't always like having to access pages through several others. This is something that could be improved.

The system as it stands can be described as a machine.

Fig 4.3 An enterprise machine describing the top level interface.

Here the events that cause the various state transitions are button clicks - eg. attendee, or unspecified activities that take place in a secondary screen and which will be considered next, for example, edit-attendee.

If we look at the class for Attendee we notice that it possesses three attributes. In this context this means that there must be a mechanism to input the information required. Thus the screen for registering the attendee (found by clicking button register in screen 4.2) might look like this:

Fig. 4.4 The register-attendee screen.

A series of screens with a diagram like Fig. 4.3 can be used to specify the interface. A machine can be defined for each screen.

For example, the machine for Fig. 4.4 which would be a refinement of the edit-attendee business process is:

Fig. 4.5 The machine for the register-attendee screen.

In this case the business process is the input of the attribute values for a specific class. In an implementation this might be done by filling in a row of a table representing the attendee data or creating a persistent instantiation object of the Attendee class in an object-oriented database.

The screens, either on paper or screen displays with no functionality generated using a suitable tool, can be shown to the client. These will have been derived from the requirements analysis. The feedback may require changes.

$5. The class specifications.

We use VDM-SL++ to specify classes, but with some minor changes. An overview of the definition of a class is shown in Figure 5.1. The frame information, prefixed by the keyword ext, of the specification of a method states whether the instance variables are read only access (rd) or read-write access (wr).

The classes for the education database are shown below, for each class used in the state definition is given below, at this point the methods have been left out, but should be added by the time this development has been completed.

class Attendee


number : Attendee-no -- the number of the Attendee;

name : Name -- the name of the attendee ;

addr : Address -- the address of the attendee;

end Attendee

class Enrolment


number : Enrolment-no -- the date of the enrolment;

date : Date -- the date of the enrolment;

grade : [Grade] -~ the course grade;

end Enrolment

class Instructor


number : Instructor-no -- the personnel number of an instructor;

name : Name -- the name of an instructor;

tel : Telephone-no -- the telephone number of the instructor;

end Instructor

class Offering


number : Offering-no -- the offering number;

date : Date -- the date of the offering;

loc : Location -- the location of the offering;

end Offering

class Course


number : Course-no -- the course number;

title : Title -- the course title;

length : À -- the length of the course in days;

end Course

class class-name is subclass of superclass1, superclass2


c: C = val -- define constant values


X = Using- Y -- define new types


f :D ® R

f (d) D E

-- Define new functions, these are to aid any specification,

-- and may become either global or local, private function

-- procedures; or may be removed during refinement.


id : Type;

The name and type of instance variables; the type

-- can be any VDM type but these should be used with care so as not to

-- destroy the usual semantics behind the discovery of objects.

init id D P ;

The initialisation: specifies what initialisation must

-- be done when an object of this class is created.

inv id D C ;

An invariant: specifies constraints on the instance

-- variables of objects of this class.


op (a: A);

fnl (b: B) : R

The signatures of methods, both procedural and

-- functional, can be defined. The bodies of these functions can be specified

-- either inline or later on in the development.

fn2 (c: C) r: R

ext rd id : Type

pre pre-fn2

post post-fn2

end class-name

class-name.op (a : A)

ext wr id : Type

pre pre-op

post post-op

Fig. 5.1. The form of a class definition in VDM.


$6. Specifying the operations.

6.1 An example of one of the business process operations.

The first step is to model very abstract worsens of the various operations that the system should provide to the user, abstract descriptions of what changes to the system each of the abstract use cases makes. No attempt is made at this stage to consider how these operations should be implemented, or made "user-friendly". They assume a perfect user with a perfect memory who does not make mistakes. Once the basic operations haw been designed more detail can be added as part of the design phase to allow for less than perfect users.

A first attempt at an operation to register a new attendee is shown below:

register-attendee (attendee-id : Attendee-no, name : Name, addr: Address)

ext wr attendees: Attendee-class _______

post let new-attendee: Attendee be st new-attendee Ï attendees Ù

new-attendee.number = attendee-id Ù = name Ù

new-attendee..addr = addr in


attendees = attendees È {new-attendee}

To improve this specification we need to include a precondition - the new attendee is not already on the database and to consider how it might be made robust. This could be achieved by looking at the operational semantics, that is the machine that defines this business process and ensuring that errors - such as input of the wrong type - are trapped and dealt with, usually offering the user another try.

Further analysis will reveal the need for secondary use cases such as de registering attendees etc. These are dealt with in the same basic way - stating the pre and post conditions as above and augmenting the machine specifications with suitable screen displays and functionality.