A Modelling Approach for Handling Business Rules and Exceptions K ECHENG L IU
AND
T INA O NG
School of Computing, Staffordshire University, Beaconside, Stafford ST18 0DG, UK Email:
[email protected] A modelling approach for handling business rules and exceptions to support the development of information systems (IS) is presented to enable business rules to be captured rigorously and at the same time to allow handling exceptions. The approach is developed by extending the workflow modelling with Norm Analysis. The workflow modelling is one of the methods of object-oriented information engineering (OOIE), whereas Norm Analysis is one of the methods of a semiotic approach towards IS. The workflow modelling is concerned with the behavioural perspective of IS and describes the sequence of events of a business process. As for Norm Analysis, it identifies responsibilities and rules that govern human behaviour. It also recognizes conditions and constraints of the actions driven by their responsibilities. The paper describes the base methods briefly and illustrates the applications of these two methods on their own. Added value for extending the workflow modelling with Norm Analysis is then identified, and the extended method is presented. The extended method is applied in a case study of an equipment servicing company for analysis of the work processes and designing a computer support system. The results of the project show that the method provides an effective way to model the business processes rigorously and yet the business users still have the control and flexibility to handle exceptions. Received December 8, 1998; revised April 21, 1999
1. INTRODUCTION Modelling is a process that constructs a limited representation of a system that represents the larger system in question. Its aim is to increase an understanding of the system and to clarify the requirements so as to reduce the effect of misinterpretation of the business needs of an organization. Typically, there are two things that can be achieved through modelling: first, an understanding of a larger problem by focusing on one part at a time; second, an amplification of the human intellect which allows analysts to work at higher levels of abstraction [1, 2]. In organizational modelling, conditions and constraints that control the operation of a system are usually identified and captured. These conditions and constraints are known as business rules which are shorthand expressions of business knowledge. Despite these benefits, there are many instances which show that the models constructed do not define the business rules rigorously and do not include a facility for specifying how exceptions can be handled. Although such instances have not caused serious problems in systems modelling, they exhibit a lack of completeness in analysis and design in information system engineering. The modelling approach proposed is mainly based on workflow modelling, a method of object-oriented information engineering (OOIE). The approach is extended with norm analysis, a semiotic approach to information systems [3]. OOIE [4, 5], a resulting approach from a recent development of information engineering [6], is a method T HE C OMPUTER J OURNAL,
that claims to provide full coverage of the IS development process across the whole organization. Workflow modelling in OOIE is a process that is concerned with the behavioural perspective of the IS and models the sequence of events of a business process. As for the analysis of norms, it identifies responsibilities and rules that govern human behaviour. It also recognizes the conditions and constraints of the actions driven by their responsibilities. The extended method aims to enable analysts to model business processes and facilitate exceptions which have not been dealt with by other conventional methods. In achieving this, the analysts manage to incorporate business rules and exceptions with the behavioural aspect of the business process in an OO model. The extended method is applied in a case study of an equipment servicing company for an analysis of work processes and the design of a computer support system. The result demonstrates that the method provides an effective way to model business processes rigorously and, moreover, business users still have control and flexibility in the handling of exceptions. 2. OOIE OOIE approaches systems modelling from an enterprisewide perspective by using OO techniques. Its aim is to support the building of business systems effectively and efficiently by reusing the organization’s information models. In order to achieve such reuse, OOIE creates models of an organization’s information system and stores Vol. 42, No. 3, 1999
222
K. L IU
AND
T. O NG
FIGURE 1. OOIE modelling (after [9]).
those models in a central repository. As in Figure 1, the pyramid illustrates the types of activities being carried out in IS development. The pyramid covers all aspects of the life cycle and progresses steadily into more detail. It is divided into four levels—Enterprise Planning; Business Area Analysis; System Design and Construction. The lefthand side of the pyramid deals with the aspect of object structure, whereas the right-hand side addresses the aspect of object behaviour. The Enterprise Planning level takes a corporate-wide viewpoint and focuses on how systems will be integrated. It is concerned with creating a system architecture so that changes in procedures can be designed and implemented quickly while preserving the integration along the value chain. At this level, an overview model is built that prompts the organization to think about its structure, its goals and the information needed. The representations at this level are class diagrams and object-flow activity diagrams. The Business Area Analysis level relates to a business area or streams of related activities. Whereas the Enterprise Planning level relates to the enterprise as a whole, the Business Area Analysis level relates to a specific area of the enterprise. This level does not attempt to design solutions; it merely attempts to understand and model the processes and objects required to operate the business. It creates detailed models of the objects and events in the business area, and the representations at this level are class diagrams and workflow activity diagrams. The System Design level comprises two stages, the Business System Design stage and the Technical System Design stage. The Business System Design defines the behaviour and structure of the system, and produces a detailed design specification for the system. The Technical System Design defines the system’s T HE C OMPUTER J OURNAL,
efficiency, taking into account the available technology and the system’s requirements. The Construction level involves building and implementing the designed system. 3. OOIE MODELLING OOIE offers techniques for Object Structure Analysis (OSA) and Object Behaviour Analysis (OBA) at the level of Enterprise Planning and Business Area Analysis; and Object Structure Design (OSD) and Object Behaviour Design (OBD) at the System Design level (Figure 1). OSA relates to object types and their associations, and it expresses the elements in class diagrams. The class diagrams represent the structure knowledge as they focus on static conceptual configurations that are applied to objects. OBA is concerned with what happens to the objects over a period of time and it expresses the elements in activity diagrams. As for OSD, it describes classes, methods, and inheritance, and these elements are expressed in detailed class diagrams. OBD specifies the methods in a diagrammatic representation supplemented with text. Notably, inspired by the emergence of Unified Modelling Language, or UML [7], OOIE has recently introduced some new developments into its graphical notation [8]. The activity diagrams which are constructed in OBA define the behaviour of objects and have two variations— the object-flow and the workflow activity diagrams [4, 8, 9]. The object-flow activity diagrams represent the business processes at a very high and strategic level by organizing each process around a group of object types; whereas the workflow activity diagrams show precisely the flow of information of the business processes. In our research, an emphasis is placed on workflow modelling and its extension Vol. 42, No. 3, 1999
A M ODELLING A PPROACH
FOR
H ANDLING B USINESS RULES AND E XCEPTIONS
223
FIGURE 2. Example of insurance workflow activity diagram.
for handling business rules and exceptions. An elaboration of its notions is discussed in the following. The intention is to gain a basic understanding of this activity prior to the discussion of the extension. 4. WORKFLOW MODELLING A workflow is defined as a sequence of events and it describes the flow of information and work through one or more organizational entities involved in business processes (see, for example, [10, 11, 12]). From an object-oriented point of view, a workflow involves a set of objects. These objects are involved in a certain sequence and each object contributes to the workflow by its behaviour or functions. The modelling of a workflow employs several processrelated notions such as operations, events, triggers and control conditions [8]. An operation is a process that can be described as a unit and can result in a state change. Defining such a unit provides a way of referring to, delimiting, specifying and reusing processes. Each operation requires objects to operate on. The events define state changes that result from operations and invoke other operations via triggers. They serve as markers for the points in time when state changes occur. Every event affects an object and is the result of an operation. A trigger specifies that when a specific event occurs, a particular operation will be invoked. It is a link between the event and the reactive process that is being invoked. Control conditions ensure that a certain state T HE C OMPUTER J OURNAL,
exists before a certain operation can be triggered. A control condition is a mechanism that, when triggered, evaluates a specified condition to determine how processing flow should proceed. Typically, control conditions are expressed in an ‘if. . . then. . . ’ form. There are three forms of control conditions: guards, decisions and synchronizations. A guard condition is indicated by a bracketed label that determines the condition that must be checked for its associated trigger to be valid. A decision condition is indicated by a diamond that determines that the condition will branch out as a series of operations. A synchronization condition is indicated by a bar notation that illustrates a series of operations being synchronized. Figure 2 shows an example of a workflow activity diagram of applying for an insurance policy. In the diagram, there are several decision points where business rules are applied in the process of approval of an insurance policy. The rules can normally be programmed and handled by the computer system if they are explicit and clearly defined. For example, from the diagram, when Take form and fill operation is invoked, it will trigger one of the following operations if the control condition pre-attached to them is true:
if the insurance application form is not filled completely, then reject the form. if the insurance application form is filled completely, then assess the form. Vol. 42, No. 3, 1999
224
K. L IU
AND
If the Assess form operation is invoked, it will trigger one of the following operations if the control condition pre-attached to them is true:
if all criteria are not met, then reject the assessed form. if all criteria are met, then accept the assessed form. if one of the criteria is not met, then accept the assessed form with proviso. If the Form accepted event occurs, operations like Issue invoice and Issue policy will be invoked concurrently. If the following conditions are true, the Delivery operation will be activated.
if the invoice is issued and policy is issued, then deliver the policy documents. if the form accepted with proviso is issued, then deliver the policy documents. The depiction of the flow of information of the business processes has shown the usefulness of the workflow activity diagrams. In addition, the diagrams can describe complex behaviour and parallel activities, which is highly desirable in IS modelling [4, 8, 13]. However, the diagrams do not facilitate situations where decisions are made solely on human judgement. These decisions are called for by unexpected situations and occur on an ad hoc basis, and are therefore impossible to handle automatically by computer systems without human intervention. This kind of situation, which cannot be dealt with by computer systems as they are difficult to anticipate and specify in advance, are called exceptions. To handle these exceptions, an extension of the modelling technique by incorporating Norm Analysis [14] is suggested so as to accommodate the exceptional situations.
5. NORM ANALYSIS A norm is more like a field of force that makes members of a society tend to behave or think in a certain way. It defines the responsibilities and authorities for each member, and establishes regularities of behaviour. As [15] explains: “Norm” has several partial synonyms which are good English. “Pattern”, “standard”, “type” are such words. So are “regulation”, “rule”, and “law”. In an organization, norms reflect regularities in the behaviour of members allowing them to co-ordinate their actions. Norms can be formal and informal, and they cover broader areas in an organization than the rules and regulations. The analysis of norms provides a means for one to anticipate and predict behaviour, so as to collaborate with others in performing co-ordinated actions. It also recognizes the central role and ultimate responsibility of an individual actor, and provides a mechanism for specifying such responsibility [3, 15, 16]. T HE C OMPUTER J OURNAL,
T. O NG There are five types of norm that influence certain aspects of human behaviour. They are perceptual norms, cognitive norms, evaluative norms, behavioural norms and denotative norms. The perceptual norms deal with how people receive signals from the environment via their senses through media such as light, sound and taste. The cognitive norms enable one to incorporate the beliefs and knowledge of a culture, to interpret what is perceived, and to gain an understanding based on existing knowledge. The evaluative norms help explain why people have certain beliefs, values and objectives. The behavioural norms govern people’s behaviour within regular patterns. Finally the denotative norms direct the choices of signs for signifying such choices are culture-dependent, e.g. the choice of a colour to signify happiness or sadness. The perceptual norms reside in a business organization’s culture convention practice, and they generally assist in forming other kinds of norms. The perceptual norms will be involved in the selection of the relevant words which people use to describe their percepts. From here the cognitive norms will address the structures and causeand-effect relationships. Their consequences will be the interpretation of the forms and functions of the structure that will affect the beliefs and knowledge. The evaluative norms involve the reasoning and the finding of intentions. They enable discussion and are disposed in favour or against something in value terms. The behavioural norms will reflect the processes and regulations cited in the organization. They help to articulate business rules and regulations such as must, may and must not behave in certain ways. The denotative norms guide the use of terms and language in communication. This type of norm is normally consistent with the perceptual norms. Of all the norms discussed, particular attention is given to the behavioural norms since they are expressed as business rules and have direct impact on business operations. Three fundamental deontic operators—permitted, obliged and prohibited, equivalent to ‘may’, ‘must’ and ‘must not’— have been implemented in a few systems that distinguish actual facts and normative behaviour, for example see [17, 18]. Typically, this type of norm consists of the following components:
whenever if then is to do . The condition describes a matching situation where the norm is to be applied, and is sometimes further specified with a state-clause (this clause is optional). The agentclause specifies the responsible agent for the operation. The agent can be a staff member, or a customer, or a computer system if the right of decision-making is delegated to it. As for the next clause, it quantifies a deontic state and usually is expressed in one of the three operators— permitted, prohibited and obliged. The next clause defines Vol. 42, No. 3, 1999
A M ODELLING A PPROACH
FOR
H ANDLING B USINESS RULES AND E XCEPTIONS
225
FIGURE 3. Workflow activity diagram of the insurance organization.
the consequence of the norm. The consequence possibly leads to an action or to the generation of information for others to act upon. Using the insurance policy example, some norms controlling the process are identified:
whenever insurance application form is not complete then the customer is prohibited to buy an insurance policy.
These norms describe responsibilities and obligations. They are fundamentally different from the cause–effect relationship, which normally states that if the conditions are met, certain events will happen or actions will be taken [19]. The conditions and consequences in these logical expressions are always bound, with no room for human discretion. Therefore, these norms reflect better how people behave in a business context, and are more suitable for modelling organizations and business objects [20]. 6. EXTENSION OF WORKFLOW MODELLING WITH NORMS
whenever the sum assured exceeds 1,000,000 if the income is above 10,000 then the customer is permitted to buy an insurance policy. whenever the customer exceeds the agreed weight then the insurance agent is obliged to charge a tariff. T HE C OMPUTER J OURNAL,
The extension is carried out by incorporating norms into the workflow activity diagram. In the diagram, each control condition is labelled as [N#] where # is the number for identification. The labels are then elaborated in the norm specifications to indicate the condition, the agent and action to be undertaken. Figure 3 depicts the extended workflow activity for applying for an insurance policy and Textbox 1 shows a list of norms for the control conditions of the business process. Phrases in curly brackets are comments Vol. 42, No. 3, 1999
226
K. L IU
AND
T. O NG
TEXTBOX 1. Norm specification for the insurance organization.
TEXTBOX 2. Additional norm for Norm N1.
to help the reader to refer to the workflow diagram in the corresponding figures. On the list, the norms define business rules that are imposed on the particular process. For example, from the list in Textbox 1, Norm N1 reflects the straightforward rules that have to be followed after the Take form and fill operation has been invoked. In addition, the norms allow exceptions to be specified in them. For example, Norm N2 includes both the business rules and an exception that will be triggered when the Access form operation has been invoked. The exception identified here is that a customer applies for insurance for a sum that exceeds the maximum allowable amount in a certain condition (c.f. N1 and N2 in Textbox 1). T HE C OMPUTER J OURNAL,
Besides handling the business rules and exceptions, the norm provides a degree of flexibility that allows analysts to introduce additional exceptions that may have been discovered in the later stages of analysis. For example, customers below 18 years of age are normally required to provide a consent form signed by their parents or guardians. There may occur a situation where the application form is filled completely and a verbal consent from the parents has been acquired. To handle this exceptional situation, the analyst adds an additional norm into Norm N1 as shown in Textbox 2. Note that the action prompted by the norm to hold the application, as an exception, is detected. Rather than processing the form automatically, it calls a claim Vol. 42, No. 3, 1999
A M ODELLING A PPROACH
FOR
H ANDLING B USINESS RULES AND E XCEPTIONS
227
FIGURE 4a. Workflow activity diagram for handling pre-delivery inspection.
TEXTBOX 3a. Norm specification for handling pre-delivery inspection.
officer to deal with the case using his or her experience, or by consultation with a supervisor. The examples show that the norms specify the rules of an operation in a specific manner since they include the condition, the state and the actions with specified deontic states. Moreover, exceptional situations are able to be handled and elaborated in the model. This establishment increases the understanding of the business processes. On the other hand, as with other approaches, this modelling approach has its drawbacks. One lies in where there are a lot of exceptions to handle, and then it becomes tedious to look into every possible exception. Another problem is that there may occur a circumstance where some of the exceptions T HE C OMPUTER J OURNAL,
conflict with each other to a certain degree. To reduce these problems, it is appropriate to involve the manager to delimit the number of exceptions to be handled, and to set aside those exceptions if a conflict occurs. With the extension of the workflow activity diagram with the Norm Analysis, the business rules are rigorously specified, and exceptions can be handled and modelled. The following is a discussion of a case study in which the modelling approach is applied. 7. CASE STUDY—THE SERVICE COMPANY The Service Company (the case documents originated by Dingley [21]) is a subsidiary of an international organization Vol. 42, No. 3, 1999
228
K. L IU
AND
T. O NG
FIGURE 4b. Workflow activity diagram for handling repair service request.
which is a leading manufacturer of construction plant equipment. The primary business of the Service Company is to provide service support to plant equipment in the construction industry. Other functions of the company include undertaking pre-delivery inspections of all new equipment before the new owners take them over; repair service for customers; undertaking warranty and servicing of equipment sold; damage assessment for insurance purposes and providing specialist services like designing T HE C OMPUTER J OURNAL,
and modifying specific machinery to meet the customer’s requirements. Recently, there has been a plan for restructuring the subsidiaries of the organization. The responsibilities of the service manager at one branch (the Service Company) will be extended to manage the service departments of all branches, under the new title of ‘regional service director’, replacing the service managers at these branches. The strategy here is to breach the geographical boundaries of Vol. 42, No. 3, 1999
A M ODELLING A PPROACH
FOR
H ANDLING B USINESS RULES AND E XCEPTIONS
229
TEXTBOX 3b. Norm specification for handling repair service request.
all the branches. In the restructuring plan, two systems are addressed and they are the call log system and the staff skill system. The intention is to maximize the utilization of the complete asset base across the geographical branches so as to provide the best possible service to customers. The call log system maintains information about the customer, machine and the type of problem. It addresses the business requirements in providing a wide range of flexible services to the customer and maintains high standards in keeping with the company image. The aims of the system are to improve customer service and customer relations, which relate to the business requirements, to increase the customer base, sales and the number of long-term contracts. The staff skill system maintains information regarding the allocation of experienced and available engineers from across the branches of the company. It supports the business requirement to maintain a sufficient level of trained engineers in order to provide a responsive and flexible service to the customers. The system aims to assist T HE C OMPUTER J OURNAL,
in balancing customer needs against the skilled resources available to improve customer service and thus assist in increasing the customer base, increasing sales and increasing the number of long-term contracts. This requires the system to be responsive to customer needs. In correspondence to the restructuring plan for the Service Company, the extended modelling approach is applied to produce the workflow activity diagrams and identify norms. The diagrams provide a stepping stone to designing the call log system and the staff skill system. 7.1. Workflow activity diagrams The workflow activity diagrams show precisely the flow of information and the control conditions of the three processes—carrying out a pre-delivery inspection (PDI); handling the repair service request; and updating staff skill. In each diagram, each control condition is labelled as [N#] where # is the number for identification. The corresponding Vol. 42, No. 3, 1999
230
K. L IU
AND
T. O NG
FIGURE 4c. Workflow activity diagram for updating staff skill.
TEXTBOX 3c. Norm specification for updating staff skill.
norms are acquired by studying business processes and are represented in the textbox. Figure 4a shows the workflow activity of carrying out predelivery inspection. When a PDI requested event occurs, the Undertake PDI operation will be invoked and it triggers the norm [N1.1]. This may lead to the Return Machinery operation or the machinery accepted event which depends on the control condition pre-attached to them. For the machinery accepted event, the norm [N1.2] will trigger the Prepare Insurance operation and the Prepare Warranty operation concurrently. Whenever the insurance prepared event and the warranty prepared event occur, the norm [N1.3] will be invoked and it will activate the Deliver Machinery operation (see Textbox 3a). Figure 4b shows the workflow activity of handling repair service requests. When a Services requested event occurs, the Create Customer operation will start the flow of T HE C OMPUTER J OURNAL,
information for the call log system. The call log system is one of the proposed systems for the restructuring plan. The Create Customer operation will trigger the Create New Customer Details operation or the Update Customer Details operation that depends on the norm [N2.1] preattached to them (see Textbox 3b). Nevertheless, both operations will trigger the Create Log Call operation. The Create Log Call operation will trigger the Evaluate Log Problem operation that will be invoked the norm [N2.2] subsequently. When the norm [N2.2] is incurred, the Allocate Engineer operation and the Check Service Agreement operation will invoke concurrently. The Allocate Engineer operation will trigger the Record Action Report operation that subsequently triggers the norm [N2.3]. When the norm [N2.3] occurs, the Allocate Engineer operation or the log problem solved event will be invoked which depend on the pre-attached condition. When the log problem solved Vol. 42, No. 3, 1999
A M ODELLING A PPROACH
FOR
H ANDLING B USINESS RULES AND E XCEPTIONS
event occurs, the norm [N2.4] will trigger the Produce Action Report operation and the Update Machine History operation simultaneously. Finally, when the Action report produced event and the Machine history updated event occur, the norm [N2.5] will invoke and activate the Update Log Call Report operation. Figure 4c shows the workflow activity for updating staff skill for all engineers who have attended the course arranged by the parent company. The diagram shows the flow of information for the staff skill system which is another proposed system for the restructuring plan. When the Update staff skill requested event occurs, the Create Engineer Details operation will invoke and subsequently trigger the norm [N3.1], as described in Textbox 3c. The norm [N3.1] triggers the Update Engineer Detail operation and the Create Course Entry operation concurrently. The Create Course Entry operation triggers the Update Course Entry operation that subsequently triggers the Update Experience operation. When the Experience updated event and Engineer details updated event occur, the norm [N3.2] will invoke that will trigger the Update Staff Skill Record operation subsequently. 8. CONCLUSIONS Models are constructed from views of the entire system. Their primary uses are seen as communication tools so as to increase understanding of the problem and improve the quality of the design of a system. While constructing IS models, business rules are also identified. A business rule is a shorthand language for expressing business knowledge that includes condition and constraint. However, in many cases they are not expressed rigorously in the model. In this paper, an approach for capturing business rules rigorously and at the same time dealing with exceptions has been developed. The approach is constructed by extending the workflow activity diagram with Norm Analysis. The strength of this modelling approach lies in two base methods, both of which are sound and well tested. The OOIE is a rigorous approach that provides a rich set of techniques for process modelling. Norm Analysis enables one to specify business rules, which is necessary in systems design. The specification of norms allows the recognition of human responsibilities and obligations and even the ultimate power of decision-making in exceptional cases. The extended method of OOIE with Norm Analysis leads to a powerful modelling approach for information systems analysis and design. ACKNOWLEDGEMENTS We would like to thank James Odell for his comments on an early version of the paper. We are also thankful to the anonymous referees for their constructive comments. REFERENCES [1] Gale, T. and Eldred, J. (1996) Getting Results with the ObjectOriented Enterprise Model. SIGS Books, Cambridge.
T HE C OMPUTER J OURNAL,
231
[2] Rumbaugh, J. (1997) Models through the development process. J. Object-Oriented Programming, 10, 5–8. [3] Stamper, R. K. (1996) Signs, information, norms and systems. In Holmqvist, B. and Andersen, P. B. (eds), Sign of Work: Semiotics and Information Processing in Organisations. Walter de Gruyter, New York. [4] Martin, J. and Odell, J. J. (1995) Object-Oriented Methods: A Foundation. Prentice-Hall, Englewood Cliffs, NJ. [5] Martin, J. and Odell, J. J. (1996) Object-Oriented Methods: Pragmatic Considerations. Prentice-Hall, Englewood Cliffs, NJ. [6] Martin, J. (1989) Information Engineering. Prentice-Hall, Englewood Cliffs, NJ. [7] Rational Software Corporation (1997) Unified Modelling Language, version 1.1, http://www.rational.com/uml/documentation.html [accessed 28 March 1998]. [8] Martin, J. and Odell, J. J. (1998) Object-Oriented Methods: A Foundation, UML Edition (2nd edn). Prentice-Hall, Englewood Cliffs, NJ. [9] Martin, J. (1993) Principles of Object-Oriented Analysis and Design. Prentice-Hall, Englewood Cliffs, NJ. [10] Basu, A. and Blanning, R. (1997) Metagraph transformations and workflow analysis. In Nunamaker, J. F. and Spargue, R. H. (eds), Proc. 30th Ann. Hawaii Int. Conf. on System Sciences, Vol. IV, pp. 359–366. IEEE Computer Society Press, Los Alamitos, CA. [11] Kwan, M. K. and Balasubramanian, P. R. (1997) Dynamic workflow management: a framework for modelling workflows. In Nunamaker, J. F. and Spargue, R. H. (eds), Proc. 30th Ann. Hawaii Int. Conf. on System Sciences, Vol. IV, pp. 367–376. IEEE Computer Society Press, Los Alamitos, CA. [12] Grasso, A., Meunier, J.-L., Pagani, D. and Pareschi, R. (1997) Distributed coordination and workflow on the world wide web. J. Collaborative Computing, 6, 175–200. [13] Fowler, M. and Scott, K. (1997) UML Distilled: Applying the Standard Object Modelling Language. Addison-Wesley Longman, Harlow, UK. [14] Liu, K. and Dix, A. (1997) Norm governed agents in CSCW. 1st Int. Workshop on Computational Semiotics, Paris. University of De Vince, Paris. [15] Wright, V. G. H. (1963) Norms and Action—a logical enquiry. Routledge & Kegan Paul, New York. [16] Stamper, R. K., Liu, K., Hafkamp, M. and Ades, Y. (1997) Signs plus norms—one paradigm for organisation semiotics. 1st Int. Workshop on Computational Semiotics, Paris. [17] Meyer, J. C. and Wieringa, R. J. (eds) (1993) Deontic Logic in Computer Science. Wiley, Chichester, UK. [18] Krogh, C. (1995) The rights of agents. In Woodrige, M., Muler, J. P. and Tambe, M. (eds), Intelligent Agents II. Springer, Berlin. [19] Liu, Kecheng (2000) Semiotics in Information Systems Engineering, in press. Cambridge University Press, Cambridge, UK. [20] Gillibrand, D. and Liu, K. (1998) Specification of the dynamics of object behaviour. Report on Object Analysis and Design, 1, 28–32. [21] Dingley, S. (1996) A Composite Framework for the Strategic Alignment of Information Systems Development. PhD Thesis, Aston University, Birmingham.
Vol. 42, No. 3, 1999
