The Deontic Pattern - A Framework for Analysis Patterns in Information Systems Design
Paul Johannesson and Petia Wohed
Department of Computer and Systems Sciences
Stockholm University/Royal Institute of Technology
Electrum 230, 164 40 Kista, Sweden
{pajo, petia}@dsv.su.se,
Abstract: In order to reduce the costs for systems development, methods for the reuse of specification knowledge have been developed. One approach is to build libraries of reusable analysis patterns, i.e. abstract models describing the generic features of a type of situation that may occur in many different domains. In order to systematise libraries of such patterns, we propose a novel analysis pattern based on a deontic perspective. The basic components of this pattern are object types describing obligations, the parties involved in these obligations and their respective roles, and the speech acts that create and delete the obligations. We argue that this pattern captures specification knowledge at an appropriate level of abstraction, has a wide applicability, and effectively supports designers in the construction of models. Furthermore, a number of instances of this pattern are analysed and classified in different categories.
1Introduction
When constructing large information systems, the key to success lies in eliciting and representing requirements. Experience has shown that these activities are difficult as well as time consuming. Even with the use of CASE tools, capturing and representing requirements remain one of the major costs in building information systems. One reason for this is that requirements and domain knowledge are still often captured from scratch for each new system to be built, even for systems within the same general area. This duplication of effort results in high costs and hinders the construction of larger and more knowledge-intensive systems. To overcome these problems, systems analysts and software engineers must find ways of sharing, reusing, and extending systems.
There are many senses in which the knowledge contained in a system can be shared and reused. One form of reuse is code reuse, which can be realised through modules invoking each other as procedures from a function library. Code reuse can also be realised through the inclusion of source specifications, i.e. the content of one module is copied into another module at design time. Another form of reuse is through the exchange of techniques, meaning that the content of a system module is not directly used; instead, the solution approach behind the module is communicated in a way that facilitates its re-implementation.
Essential to all these forms of reuse is the build-up and maintenance of a library of reusable modules. Such a library can be utilised in many different ways. It can be searched through keywords that retrieve and select modules based on their functionality, as suggested in [5]. However, keywords describing the functionality of systems cannot effectively support reuse across different applications. Faceted classification schemes, [30], overcome some of the problems of simple keyword retrieval by describing non-functional features of modules and by providing a lexicon to support differences in terminology. The contents of the modules in a library may vary widely, from source code to generic objects and models. The latter are abstract models that describe the generic features of a type of situation that may occur in many different contexts; these abstract models are commonly known as patterns.
Patterns come in a large number of varieties. One of these is the design pattern, [12], which has received much attention in the software engineering community. A design pattern is a description of “communicating objects and classes that are customised to solve a general design problem in a particular context” [12]. Thus, a design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. While a design pattern addresses the design stage in systems development, an analysis pattern concerns the analysis and specification stage. An analysis pattern consists of an application independent model of a domain structure, e.g. a model of time or causality at a higher level of abstraction, or a model of library systems at a lower level. An analysis pattern describes, at an arbitrary level of abstraction, a set of real-world objects, their interrelationships, and the rules that govern their behaviour and state. Some examples of analysis patterns are domain abstractions as discussed in [26], the analysis patterns in [11], and data model patterns as introduced in [17]. The notion of analysis patterns is similar to that of ontologies in the knowledge representation community, [29]. An ontology is commonly defined as an explicit analysis of a conceptualisation, where a conceptualisation consists of “objects, concepts and other entities that are assumed to exist in some area of interest and the relationships that hold among them”, [14].
An important quality requirement on an analysis pattern is that it be sufficiently general, i.e. it should be sufficiently abstract to be applied to many different application models. Another quality requirement is that it should be easier to understand and apply the analysis pattern than to model a part of the application from scratch. Clearly, these two quality requirements are in conflict as highly abstract patterns may be quite difficult to apply. The difficulty to construct patterns satisfying both these requirements is probably a major reason why analysis patterns are not yet widely used. An important research task is, therefore, to identify analysis patterns at an appropriate level of abstraction.
The purpose of this paper is to show how deontic concepts can be used for modelling fundamental aspects of social reality in the context of information systems design. Deontic concepts have been applied in different areas of computer science; for a survey, see [39]. We believe that deontic concepts have an important role to play also in enterprise modelling, and that they can be used for extending existing ontologies in this area, such as TOVE, [15]. In order to show this, we introduce a novel analysis pattern. The basic components of this pattern are object types describing obligations, the parties involved in these obligations and their respective roles, the speech acts that create and delete these obligations, the subject matters of and the reasons for the obligations. We claim that this analysis pattern is both sufficiently general and easily understandable, which means that it will be useful in a large number of areas as well as simple to apply.
The paper is organised as follows. Section 2 gives an overview of related research in the area. Section 3 describes briefly the formalism used in the paper. Section 4 introduces a general deontic pattern and Section 5 represents and analyses different instances of it. Section 6 classifies the analysis patterns from Section 5 into different categories. Section 7 describes different application scenarios of the general deontic pattern. Finally, Section 8 summarises the paper and gives some directions for further research.
2Related Research
This paper integrates concepts from three different approaches: information systems deign, deontic analysis and the communication action approach. These approaches are combined in order to set the information system development process in perspective by focusing on the organisational and communication structures of enterprises.
The first one who introduced the concept of deontic modes was von Wright who in 1951 [41], distinguished these modes as modes of obligation, permission and prohibition in contrast to the alethic, epistemic and existential modes. He also introduced the first axiomatic system for deontic logic containing the deontic operators P (for permission) and O (for obligation). However, as every innovative system it suffered from several problems, the most notable of which was Chisholm’s paradox. In an attempt to solve these problems, several other deontic systems were developed [1], [42], [27]. A survey of the applications of these and other deontic systems in computer science can be found in [39].
In parallel with this work on deontic systems, speech act theory was established as a new field in philosophy by introducing the idea that some actions are performed in the very moment of speaking. Speech act theory was originally introduced in 1913 by Reinach [35] as a theory of social acts, but it was not widely known until Austin’s [4] independent work, which was continued and popularised by Searle [37]. The main difference between Reinach’s and Austin/Searle’s approach is that Reinach grounded the theory of social acts Husserl’s phenomenological philosophy, [19], whereas Austin and Searle used linguistics as a foundation.
One of the earliest applications of speech act theory to the field of information systems development was made by Winograd and Flores [40], who used the language/action approach in the design of their system Coordinator, which supported the communication process in the work place. The idea of applying the language action approach on system analyses and design was also employed by Auramäki, Lehtinen and Lyytinen within the SAMPO (Speech-Act-based office Modelling aPprOach) project [3],[23] in the middle of the eighties. They proposed a modelling language for information system design based on the language/action perspective in order to enrich the existing techniques by concentrating on the linguistic and communication character of information systems. These ideas were further developed in some recent work on Business Action Theory provided by Goldkuhl and Lind [13],[24] and in DEMO (Dynamic Essential Modelling of Organisations) provided by Dietz, Reijswoud and Rijst [8],[9],[33].
Beside the work on the language/action approach within information systems design, several formalisms combining speech act theory with deontic logic were developed in order to model the creation of deontic modes within the communication process [10],[2],[21]. Similarly, the idea of this paper is to combine deontic logic and speech act theory in order to apply it within information systems design [22]. It is, however, not aiming at building a new modelling language like the previous work. Instead, it constructs a framework for abstracting existing modelling patterns in order to analyse similarities and differences between them with the purpose of simplifying the design and reuse process in systems development.
3Modelling Formalism
The basic concept in conceptual modelling approaches is the object. Objects that are similar are grouped together into object types, such as Person and Department. Objects have different properties, which are modelled by attributes or relationships. In our graphical notation, see Figure 1, object types are represented by rectangles; attributes are represented by bulleted lists inside the object types; and relationships are represented by labelled lines. Both a relationship and its inverse are represented with the same line. The direction of a relationship is shown by the symbols ‘<’, ‘v’, ‘>’ and ‘^’ placed in connection to its label. The object type initiating a relationship is called domain of that relationship and the object type in its end is called the range of it. The graphical notation can only represent cardinality constraints and generalisation relationships. The generalisation constraints are shown by arrows where the head of the arrows point at the super-class. The cardinality constraints specify for each relationship if it is single-valued, injective, total and surjective. A relationship is single-valued when each instance of its domain is connected with at most one instances of its range. A relationship that is not single-valued is multi-valued. A relationship is total when each instance of its domain is connected to at least one instance in its range. A relationship that is not total is partial. A relationship is injective (surjective) when its inverse is single valued (total). However since almost each relationship in our schemas is single valued, not injective, total and not surjective, we have chosen to omit the cardinality constraints graphically in order to keep the figures simple.
Figure 1
Employment Pattern
4A Deontic Analysis Pattern
In this section, we introduce a deontic analysis pattern based on the structure of a social act provided by Reinach and others. The graphical representation of the pattern is shown in Figure 2. The labels in the right upper corner of the rectangles are abbreviations for the corresponding object types.
4.1 Deontic Objects
We start by classifying objects into two categories: concrete and abstract objects. Concrete objects are physical objects with a particular position in space and time. BUILDING, for instance, is a typical example of a concrete class. Every object that is not concrete is an abstract object. An example of an abstract class is ORGANISATION. Note that Stockholm University could appear as an instance of both BUILDING and ORGANISATION, but there still are two different objects, the building in the first case and the institution in the second, both being denoted by the same term.
An important characteristic of certain abstract objects is that they entail obligations. For instance, Peter’s employment at Stockholm University entails that Peter is obliged to work a number of hours for the university, which in turn is obliged to pay him a salary. In contrast, the existence of the institution Stockholm University does not by itself entail any obligations. We refer to an object that entails obligations by DEONTICOBJECT. Typical properties for a deontic object are the period for which it exists and a number of parameters representing important information about the created obligations. For instance, the attributes startdate, percent and salary for the object type EMPLOYMENT in Figure 1 represent information about the entailed obligations, namely the start date for the obligations, the working time an employee is required to do, and the salary the employer has to pay. Deontic objects can further be divided into three subclasses: atomic deontic objects, composed deontic objects, and agreements. An atomic deontic object entails one single obligation, for example the obligation to return a book to a library. A composed deontic object consists of a small number of atomic deontic objects. An example is an order, where the supplier is obliged to deliver a product and the customer is obliged to pay on delivery. Finally, an agreement is a deontic object where it is not possible to specify a small number of obligations that constitute the object. Instead, an agreement provides a context for other deontic objects by regulating how they can be created, destroyed, and modified, and by specifying rules telling how violations of obligations should be handled. An example of an AGREEMENT is an EMPLOYMENT, which regulates the rights and duties of the employee and the employer.
As deontic objects are social objects, they always involve at least two parties. Furthermore, the way in which parties are participating in a deontic object differs between atomic deontic objects and agreements.For an atomic deontic object, there is always one party who is responsible for fulfilling the obligation, and there is another party for whom the obligation is to be fulfilled, which is represented by the attributes responsible for and responsible to, respectively. Normally, the party who requested the deontic object is the same as the one for whom the associated obligation is to be fulfilled, and the party who approved of the creation of the object has the responsibility to fulfil the associated obligation. In contrast, for an agreement a number of roles for different parties are created and the responsibilities are not connected to only one of these roles but are distributed among the different roles. For example, in an employment agreement there is an employee role and an employer role, which both imply responsibilities.
Deontic objects can be related to each other in various ways. First, one deontic object can provide a context for another deontic object, meaning that the latter object can exist only because the former object is already in place. For example, the appointment of a person as teaching assistant can exist only if there is an employment in place for that person. Furthermore, the employment will provide a context for the appointment by regulating how it can be modified and terminated. Another relationship between deontic objects has to do with the reason, or motivation, for creating a deontic object. For example, a room can be booked (one deontic object) in order to fulfil the obligation of giving a lecture (another deontic object). Finally, we model the purpose of a deontic object, where two of the most common purposes are to get access to some resource or to get some activity performed.
4.2 Knowledge Level and Operational Level
The components of the deontic pattern can be viewed as belonging to different levels. We similarly to Fowler [11] distinguish between a knowledge level and an operational level. Husserl and Reinach have made the same distinction by discussing the differences between “essences” and “species” [28]. Briefly, the knowledge level models the kinds of objects (species) that exist, the relations between these, and the general rules in a domain, whereas the operational level captures the every day events and the objects (essences) involved in these. Objects like Peter, Stockholm University and Peter’s employment at Stockholm University are distinguished from objects like Physical person, University and Employment by classifying the former into the operational level and the latter into the knowledge level. Objects at the operational level can be viewed as realisations of objects at the knowledge level. For example, ‘Peter as teaching assistant’ at the operational level is a realisation of the role ‘teaching assistant’ at the knowledge level. This view is consistent with the type-ontology of artefacts proposed by M. Reicher in [34], where artefacts, in particular works of art are seen as a special kind of universals that are realised in concrete particulars, such as performances. Consequently, the classes that group together objects are also divided between these two levels, i.e. classes belonging to the operational level and classes belonging to the knowledge level. For example, the class PARTY is separated from the class PARTYCATEGORY. PARTY is then classified into the operational level with objects like Peter and Stockholm University as instances, while PARTYCATEGORY with Person and University as instances is classified into the knowledge level. Similarly, the class DEONTICOBJECT is separated from the class DEONTICOBJECTTEMPLATE by distinguishing between the concrete occurrence of ‘Peter’s employment at Stockholm University’ as an instance of the former class and the general rule ‘university employment’ as an instance of the latter class.