Deontic Specification Patterns

Deontic Specification Patterns

<p> The Deontic Pattern - A Framework for Analysis Patterns in Information Systems Design</p><p>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, www.dsv.su.se</p><p>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. </p><p>1 Introduction</p><p>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, 31, 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</p><p>1 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 27, 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, 30. 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 40. 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. </p><p>2 Related Research</p><p>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 42, 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, 43, 28. A survey of the applications of these and other deontic systems in computer science can be found in 40. 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 36 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 38. 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 41, 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,24 in the middle of the eighties. They proposed a modelling language for information system design based on the</p><p>2 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,25 and in DEMO (Dynamic Essential Modelling of Organisations) provided by Dietz, Reijswoud and Rijst 8,9,34. 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.</p><p>3 Modelling Formalism</p><p>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 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.</p><p>RA Position EmploymentDO Assignment in > - start date - percent - percent - salary</p><p> employee v employer v P P Person Organisa- tion to v</p><p>P Party - name</p><p>Position R - name - description</p><p>Figure 1 Employment Pattern</p><p>4 A Deontic Analysis Pattern</p><p>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 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</p><p>3 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 DEONTIC OBJECT. 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 start date, percent and salary for the object type EMPLOYMENT in 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” 29. 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 35, 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 PARTY CATEGORY. PARTY is then classified into the operational level with objects like Peter and Stockholm University as instances, while PARTY CATEGORY with Person and University as instances is classified into the knowledge level. Similarly, the class DEONTIC OBJECT is separated from the class DEONTIC OBJECT TEMPLATE by distinguishing between</p><p>4 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. The knowledge level captures the rules established by the culture or the law system that a universe of discourse has to obey, while the operational level keeps information about occurrences following these rules. This means that the operational level is almost symmetrical to the knowledge level, i.e. most of the classes/relationships at the former level have a corresponding class/relationship at the latter level. However, much of the information at the operational level is time sensitive, which means that it is important to keep information about when certain events occur or the time interval for validity periods. 4.3 Managing Deontic Objects</p><p>SA</p><p>Speech R/A Act influences > Resource/ Activity < utterance reception ></p><p>Spontane with > Meaning < grasps Uptake ous Act purpose ^ speaker > < hearer</p><p>RA Role DO Deontic Assignment in > motivates Object for responsible to ^ v responsible for ^ context ^ P Party Atomic Composed Agreement operational level</p><p>SAT Speech R/AT influences on > Resource/ Act Type Activity Type < consists of consists of ></p><p>Spontaneous Uptake with > Meaning < grasps Act Type Type Type purpose ^</p><p> with utterance authorised by > < grasp authorised by</p><p>R DOT Illocutio- Role role within > Deontic Object nary pnt Template motivates role for responsible to ^ v responsible for ^ the context of ^ PC Party Atomic Composed Agreement Category Template Template Template knowledge level</p><p>Figure 2 General Deontic Pattern</p><p>Deontic objects are managed by means of speech acts. The term ‘speech act’ was established by Austin in 1951 4 and designates actions performed by linguistic means. A classical example is the utterance by a priest “I pronounce you husband and wife,” during a wedding ceremony, which changes the universe of discourse (UoD) by changing the marital status for two people. However, in order to change a UoD, an assertion has not only to be uttered by a speaker but it also has to be understood, grasped, by one ore more hearer/s. According to this, the utterances are distinguished from the grasps and the classes SPONTANEOUS ACT (according to Reinach characterising utterances as punctually occurring) and UPTAKE, are introduced to model them in the deontic pattern. Every speech act, or more precisely its spontaneous act, has an illocutionary point that determines the kind of effect of the act. A speech act with declarative point brings about a new state of affairs; in the example above the priest performs a declarative speech act. Two other points relevant for this paper are: directive, when somebody gives orders to someone else, e.g. “Close the door!”; and commissive, when someone commits himself to do something, e.g. “I will look at your homework today”. In addition to its illocutionary point a spontaneous act also has a meaning often called its propositional content. The result of a speech act is that it influences some deontic object, i.e. it can create, modify or terminate the deontic object. In the example above, the priest’s utterance and the grasp of it creates a new marriage with the roles wife and husband involved in it. In order for a speech act to be effective, i.e. to influence a deontic object, certain conditions have to be fulfilled. In information systems design, the most</p><p>5 common conditions concern the roles of the speaker and the hearer within the organisation, which are important factors for the utterance, grasp, and effect of a speech act. For example, a request like “Make coffee!” should result in an obligation when uttered by a boss to her secretary but is little more than a joke when uttered by a secretary to his boss. Thus, for any speech act, there are rules specifying which role a party must play in order to be authorised to utter the spontaneous act part of the speech act. Correspondingly, there are rules for the uptake part of the speech act telling which roles that have to grasp the speech act. These authorisation relationships are modelled on the knowledge level by means of the relationships utterance authorised by and grasp authorised by. 4.4 An Example In order to clarify the effect of speech acts on deontic objects we conclude this section with an example of a project manager requesting new equipment to her project (see also 3). We first give a description at the knowledge level: a project manager at a laboratory at a department has the authority to request the purchase of new equipment to her project. This request is addressed to the head of the laboratory and results in a new deontic object that obliges the head of the laboratory to assess the request and further it to the head of the department. This gives rise to an obligation for the head of the department to make a decision on the proposal. Depending on the outcome of the assessment, the head of the department accepts or rejects the request. The speech acts types in this scenario are; the project leader’s request for new equipment addressed to the head of the department; the assessment from the head of the laboratory to the head of the department; and the acceptance/rejection of the head of the department for purchase of new equipment. On the operational level, we would have the corresponding speech acts and obligations: Ann in the role of project leader at Stockholm University requests the 1 June the purchase of a new computer to her project. The head of the laboratory, Peter, supports this request and furthers it to Alan, the head of the department. Alan decides to accept the request for the additional equipment.</p><p>Ann requests 1 June a new computer from Computer Peter</p><p>Ann requests Peter receives 1 June a new Acquisition of Ann's request computer a computer</p><p>Ann's employment at SU Ann is employed at SU Ann's project management Ann is project manager at DM Peter has to approve request for Peter is head of laboratory at DM computer acquisition Alan is head of DM</p><p>Ann, Peter, Alan Stockholm University (SU) Peter has to approve Ann's Dept. of Mathematics (DM) request for computer employment at operational level acquisition SU</p><p>Project manager requests new equipment of the equipment head of laboratory</p><p>Project manager Acquisition of Head of laboratory requests new equipment receives the equipment request</p><p>University employment, University as employer Project manager at a department request Person as employee Approval of request for equipment Person as head of laboratory acquisition Person as project manager </p><p>Approval of request Person, University University for equipment employment knowledge level acquisition</p><p>Figure 3 An example</p><p>6 5 A Review of a Number of Analysis Patterns</p><p>We introduce a number of typical analysis patterns and show that they all can be viewed as specialisations of the deontic pattern in Section 4, although they superficially look quite different. The label in the right upper corner of each object type shows how this object type is classified according to the deontic pattern from previous section. Employment Pattern In 1, an analysis pattern for employment is given, where the object type EMPLOYMENT is associated to an ORGANISATION that is the employer, a PERSON who is an employee, and one or several POSITION ASSIGNMENTs. A POSITION ASSIGNMENT shows the share of an EMPLOYMENT to a POSITION. For instance, the model has the capacity to represent that a person is employed full-time at a company from a specific date, and that the employment is shared in 40% as project leader and 60% as consultant. An employment gives rise to a large number of obligations, e.g. that the employee should work a specified amount of time and that the employer should pay a salary. Work Order Pattern An analysis pattern for work orders is given in 4. An example of a WORK ORDER is the order that a certain course shall be given by a department during a specified period of time. The department is then obliged to see to it that the course is given during this time period. Furthermore, a number of parties can be involved in a work order where they can play different roles. Examples of different WORK ORDER ROLE TYPEs are head teacher and assistant, where a head teacher is also the examiner and an assistant helps with teaching and administration. The object type WORK ORDER ROLE is introduced to show which role a party has in a work order. Furthermore, a work order gives an obligation to carry out a number of activities, where an ACTIVITY is for instance a specific lecture. </p><p>R/A Activity</p><p> for ^</p><p>RA DO Work Order Work in > Role Order</p><p> played by v</p><p>P Party defined by v operational level</p><p>R Role Type </p><p> knowledge level</p><p>Figure 4 Work Order Pattern</p><p>3.5 Booking Pattern It is common that an object must be booked before it can be lent. Bookings are also needed for planned activities. A BOOKING object type specifies the RESOURCEs that are booked by a PARTY and the period of time for which they are booked (5). When a booking is made for a party, there is an obligation that the booked party will join the activity she is booked for. If a booking is made for equipment, the obligation is that the equipment will be available for the booked period of time. The booking pattern also contains an object type ACTIVITY, which specifies the purpose for making a booking. As an example, a lesson is an activity that requires the booking of a teacher and a classroom. </p><p>7 R/A R/A Equipment Resource</p><p> of ^</p><p>P & R/A DO</p><p>Party < made by Booking</p><p> for v</p><p>DO & R/A Activity</p><p> operational level</p><p> of type v R/AT Activity Type</p><p> knowledge level</p><p>Figure 5 Booking Pattern</p><p>Marriage Pattern The marriage pattern in 6 can represent marriages, the parties involved in marriages, and the events that create and end marriages. A MARRIAGE is created by a WEDDING, which can be seen as a declarative speech act in which two parties, besides the wife and the husband, participate - a priest and a witness. </p><p>SA < initiated by Wedding</p><p>SA Divorce ends up > witness v officiated by officiated by v v</p><p>P DO < husband Party Marriage < wife</p><p> operational level</p><p>Figure 6 Marriage Pattern</p><p>When constructing a concrete analysis pattern from the deontic pattern, it is common to omit some components or collapse one component into another one. Some of the most common omissions are the following:</p><p> ROLE ASSIGNMENT omitted. The object type ROLE ASSIGNMENT is often omitted and replaced by relationships between DEONTIC OBJECT and PARTY. This omission is common when there is only a small and fixed number of established roles, e.g. wife and husband in a marriage, where these roles can be modelled by means of relationships wife and husband. When the number of roles may vary or when information is needed about the roles, the object types ROLE ASSIGNMENT and ROLE are required. </p><p> PURPOSE omitted. The relationship purpose is omitted when the deontic object is an agreement that does not primarily entail obligations for a particular action or object. For example, a marriage entails a large number of obligations in many different circumstances, and it is not possible to single out a specific obligation as more important than all the others. A work order, on the other hand, entails primarily the obligation to carry out a particular activity, while the other obligations in this context are less important, so the object type ACTIVITY is included in the WORK ORDER pattern. </p><p> SPEECH ACT omitted. In many analysis patterns SPEECH ACT is not included. Speech acts are explicitly represented only when they possess relevant properties, and even in these cases they are often collapsed into the deontic objects that they influence.</p><p>8  ACTIVITY/RESOURCE combined with DEONTIC OBJECT. Planned activities occur frequently in conceptual models, and they consist of two different components: an activity and a deontic object stating that someone is obliged to carry out the activity. However, these two components are often collapsed into one single object type, as illustrated in the BOOKING pattern.</p><p> PARTY combined with REASORCE/ACTIVITY. In some cases an object type PARTY has also the function of a resource and is therefore classified as RESOURCE/ACTIVITY. An example can be found in 5, which models bookings made by parties and where at the same time bookings for parties are allowed. </p><p>6 Classification</p><p>In the previous section, a number of analysis patterns was generalised by considering them from the deontic perspective. The concept deontic object type was introduced to cover objects that entail obligations. Furthermore, a number of object types related to a deontic object was identified and described, in order to give a better understanding for the concept of deontic object. The generalisation of deontic objects made in Section 4 emphasises the similarities between different deontic objects. To complete the analysis, we investigate in this section the differences between the deontic objects and classify them into sub-categories. The classification of the deontic objects will be based on a number of distinguishing features. These features can be divided into the following five groups: Formal: the basic category that distinguishes an object within a larger domain Constitutive: the relation between an object and its constituent parts Telic: the purpose and function of an object Agentive: factors involved in the origin of an object Terminative: factors involved in the termination of an object The first four of these groups are identical to the qualia roles of 33, which are there used in the context of generative lexicon theory, 32. These qualia roles are based on the Aristotelian principle of substance. Formal The formal features have to do with the general categories of deontic objects and are identical to the subclasses introduced in Section 4.1. Atomic deontic objects Composed deontic objects Agreements</p><p>Constitutive Conditional component: Some deontic objects contain a conditional component, whereas others do not. Consider for instance the deontic object of giving a quotation. A quotation obliges to delivery if an order according to the quotation has been made. But if no order is made, the deontic object does not entail any obligation. So, the obligation exists only when certain conditions are fulfilled. We can, however, not identify any conditions for lending and ordering, as they always entail obligations independently of the circumstances. These observation results in distinguishing between conditional and unconditional deontic objects, where a quotation is a conditional deontic object and lending and ordering are unconditional ones. Multi-party obligations: Considering quotation, ordering, and lending once again one more difference can be identified, namely how the obligations are distributed over the involved parties. For instance, lending a product brings obligations to only one of the involved parties: to the borrower to return the borrowed product. Even in giving a quotation the entailed obligations concern only one of the parties. In contrast, an order brings obligations to both parties: it obliges one of them to deliver and the other one to pay the delivered product. These considerations motivate a distinction between deontic objects that bring obligations to one party and deontic objects that bring obligations to all parties. Telic The telic features have to do with the purpose or function of a deontic object and are reflected by the relationship purpose in the deontic pattern. Resource control: The purpose of some deontic objects is for some agent to get access to some resource for a period of time. Typical examples of such objects are purchases, bookings, and borrowings. </p><p>9 Activity performance: The purpose of other deontic objects is to get some activity performed. Typical examples are orders of different kinds. Agentive Rule based: Most deontic objects come into existence as the result of a speech act carried out by an agent in a non-predictable way. However, for certain deontic objects it is possible to specify a condition, or rule, that determines when the object is to be created. Some examples of such objects are pensions, citizenships, and military services. Terminative Revocability: One aspect of an agreement is how and by whom it can be revoked. A remarkable example in this sense is a Greek citizenship, which is a deontic object as it entails a number of obligations, but which can not be revoked. Even if this is quite an extreme situation as most deontic objects can be revoked in one way or another, we make a distinction between revocable and not revocable deontic objects. Revocability by party: Moreover, not all of the revocable deontic objects are revocable by all parties. For instance, a citizenship, other than a Greek one, can be revoked only by the state that has issued it. In contrast, an employment can be revoked by both the employer and the employee. So, we divide the revocable deontic objects into revocable by one party and revocable by all parties. Rule based: Many deontic objects cease to exist as the result of a speech act or because one of the agents involved in the deontic object cease to exist. Examples of these are marriages and tenancy rights. However, for certain deontic objects it is possible to specify in advance a condition, or rule, that determines when the objects cease to exist. Some examples of such objects are quotations and military services.</p><p>The features introduced above can be used for a classification of deontic objects. As is easily seen, the features are not orthogonal to each other, e.g. all atomic deontic objects are revocable. In spite of this disadvantage, we believe that the resulting classification is useful for reuse purposes, as it is easy to determine whether a feature holds for a deontic object or not. The classification can be conveniently represented in the form of a decision table. A fragment of this table is shown in 7.</p><p>Agreement X X X X Formal Composed X Atomic X Conditional Constitutive Multy-party X X X X Resource X X Telic Activity X Agentive Rule based X X Revocable X Terminative Revocability by one X X Rule based t n g e n i m r k r e y p o e i d o l r o n d h r p o s o B</p><p> i o n t</p><p> g s m e c k n n E z u i r e i e t d o w P i g o o a r C W r i r P r r o a B M</p><p>Figure 7 A fragment of a decision table</p><p>7 Applications of the Deontic Pattern</p><p>Reuse and Schema Design The deontic pattern introduced in this paper can serve as an abstract pattern in a library of reusable modules. The other modules will contain specialisations of the deontic pattern, such as lending, booking,</p><p>10 and sale. The deontic pattern will serve as an entry point to the library and as a template for structuring the other patterns. An open research question is how to organise the specialisations of the deontic pattern into a structure that is easy to navigate and search. The decision table structure in Section 6 is one possible solution. When a designer wants to identify an analysis pattern for a particular application, she can start by determining for each feature in Section 6 whether it holds for the particular situation or not. When she has completed this she will find an analysis pattern that is directly, or with small modifications, useful for the application. The deontic pattern may be used in schema design in many different ways. First, one of its specialisations can be integrated directly into a schema without any modifications. Secondly, a fragment of a schema can be compared to the deontic pattern in order to check the correctness and completeness of the schema. Utilising the deontic pattern in these manners can improve the quality of schema specification in several respects. In particular, the completeness of a schema can be improved, as comparing a schema fragment to a pattern will assist a designer in identifying aspects of the application that have been left out in the specification. Furthermore, the stability of a schema can be increased by adding components from the deontic pattern, which are not strictly necessary for the current application, but can make later requirements easier to accommodate. The use of the deontic pattern can also support the designer in focusing on the conceptually relevant aspects of an application. For example, a common error in schema specification is to model the physical representation of a deontic object instead of the deontic object itself. Using the deontic pattern will make the distinction clear and prevent this kind of error. Finally, the deontic pattern can facilitate the documentation of a schema by providing templates for the different types of obligations that may occur. Instantiating these templates for a particular application can be a most effective way of constructing a comprehensive documentation. Validation and Explanation Another application of the deontic analysis pattern is in systems validation, i.e. the process of checking whether a model correctly represents a piece of reality and the users’ requirements. In order to ease the validation process, several different techniques have been proposed. One approach is to paraphrase parts of a conceptual model in natural language, 37, 6, 7. In order to validate large models, a technique called complexity reduction has been proposed, which presents views of a conceptual model and hides irrelevant details, 39. Model simulation is still another technique, which can be used for observing and experimenting with the dynamic properties of a model, 16. Explanation generation techniques have been used to integrate the techniques mentioned above and provide a uniform interface to the users. Explanation generation extends paraphrasing by including question–answer facilities that interactively support a user in exploring a model. A common problem in explanation generation is that the terminology included in a conceptual schema can be insufficient to provide an adequate explanation of the schema. The terminology of the schema then needs to be extended by additional terms so that an appropriate explanation can be generated. Making this terminological extension in an ad-hoc way can be difficult and time consuming, and it is therefore valuable to have access to a background vocabulary, which can be used for systematically extending the schema. Such a vocabulary is provided by the deontic pattern, and it enables explanations of schemas in terms of obligations, authorisations, roles, motivations, etc. even if these terms are not included in the given schema. An example of a natural language explanation of a part of a database based on the schema in 5 is: Why has Peter made a booking for B312? Peter has made the booking in order to get access to the room B312 for the period 9 a.m. to 13 p.m. The reason for making this booking is to be able to carry out the planned lecture in cognitive psychology. In the example above, the explanation can in principle be generated automatically from the given database, the schema and the deontic pattern. In other cases, however, it may be necessary to manually add explanations to the schema, for example when an attribute describes some parameter of an obligation. Also in this case, the deontic pattern may assist a designer in producing the explanation by providing a framework in which the explanation can be formulated, i.e. by focussing the designer’s attention on deontic and speech act structures. The schema in 1 could be paraphrased as follows: An employment is an agreement between a person and an organisation. It obliges the employee to work a specified percent of full-time and the employer to pay a salary. Within the employment the employer can be assigned different roles, called positions, that authorises her to certain activities.</p><p>11 8 Summary and Further Research</p><p>In this paper, we have discussed how deontic concepts can be used for modelling social reality in the context of information systems design. We have introduced an analysis pattern, the deontic pattern, that can be viewed as a generalisation of many analysis patterns found in the literature. We have also outlined how this pattern can be used in systems design for the purposes of reuse and validation. The deontic pattern introduced is described solely in terms of objects and relationships, and it therefore provides only a superficial representation of deontic structures. Another limitation is that the pattern describes the creation, modification, and deletion of deontic objects as the result only of single speech acts. This may be an acceptable limitation if the purpose is to find a common structure in analysis patterns as found in current literature, but it means that the deontic pattern fails to capture the fact that many deontic objects are created as the result of processes and conversations. In the terminology of [Weigand98], we have addressed only the speech act and transaction levels, but not the workflow loop and contract levels. In order to address these latter levels, we need a deeper representation of the deontic pattern that includes dynamic aspects in addition to the static structures. Adequate formalisms for this purpose may range from DEMO models, 8, to illocutionary and deontic logics, 2,21,10. Utilising these formalisms, some of the vague notions in the deontic pattern, in particular purpose and motivation, can be made more precise. Furthermore, it will become possible to analyse in greater detail the different variants of the deontic pattern, and thereby construct a systematic structure of these variants that will help to build a library of reusable specifications. The components of the deontic pattern are divided into two levels: the knowledge level and the operational level. However, this division into levels is not absolute but only relative, i.e. one and the same component may be at the knowledge level with respect to another component and at the operational level with respect to a third component. For example, an object ‘university employment’ is at the knowledge level with respect to ‘Peter’s employment’ and at the operational level with respect to ‘civil service’. In other words, the general rules that govern a particular domain may themselves be regulated by other higher order rules. One topic for further work is to study how these levels interact, in particular when one actor can influence objects at several different levels. The deontic pattern describes only the social reality of an organisation. In some organisations, there is no complex reality to manage in addition to the social one, e.g. in the bank and finance sector. However, most organisations also have a physical reality to manage. As a consequence, we need to describe not only social concepts, but also product structures, production processes, and transportation logistics. In fact, most current analysis patterns that do not describe social aspects concern one of these three latter areas. An important topic is to investigate the relationships between the social and physical realities and how these are reflected in analysis patterns. Another line of research is to empirically investigate the usefulness of the deontic pattern. Such an investigation would focus on two distinct issues. First, the applicability of the deontic pattern should be measured by studying how frequently it occurs in applications from different domains. Secondly, one should investigate how well the deontic pattern supports a systems designer in the specification task - this can be done by comparing designers that are familiar with the deontic pattern with those that are not with respect to results and ways of working. </p><p>References [1] A. R. Anderson, “A Reduction of Deontic Logic to Alethic Modal Logic”, Mind, vol. 67, pp. 100- 103, 1958. [2] P. Assenova and P. Johannesson, “First Order Action Logic - An approach for Modelling the Communication Process between Agents”, in First International Workshop on Communications Modelling - The Language/Action Perspective, Ed. J. D. F. Dignum, E. Verharen and H. Weigand, London, Springer Verlag, 1996. [3] E. Auramäki, E. Lehtinen, K. Lyytinen, “A Speech Act Based Office Modelling Approach”, ACM Transactions on Office Information systems, vol. 6, no. 2, pp. 126-152, 1988. [4] J. L. Austin, How to Do Things with Words, Oxford, 1962. [5] B. Burton, R. Aragon, S. Bailey, K. Koehler and L. Mayes, “The Reusable Software Library”, IEEE Software, pp. 25 - 33, 1987. [6] H. Dalianis, P. Johannesson, “Explaning conceptual models – using Toulmin’s argumentation model and RST”, in proceedings of the 3rd International Workshop on The Language Action Perspective on Communication Modelling, Ed G. Goldkuhl, M. Lind, U. Seigerroth, 1998. [7] H. Dalianis and P. Johannesson, “Explaining Conceptual Models -- An Architecture and Design</p><p>12 Principles”, in David W. Embley and Robert C. Goldstein, (Eds.), ER'97, 16th International Conference on Conceptual Modeling, Lecture Notes in Computer Science No. 1331, pp. 215-228, Springer Verlag, 1997 [8] J. Dietz, “Modelling Communication in Organizations”, in Linguistic Instruments in Knowledge Engineering, Ed. R. v. d. Riet, pp. 131 - 142, Elsevier Science Publishers, 1992. [9] J. Dietz, “Business Modeling for Business Redesign”, in proceedings of the 27th Hawaii International Conference on System Sciences, IEE Computer Society Press, pp. 723-732, 1994. [10] F. Dignum and H. Weigand, “Modelling Communication between Cooperative Systems”, in proceedings of Conference of Computer Advanced Information System Engineering (CAiSE) , pp. 1995. [11] M. Fowler, Analysis Patterns - Reusable Object Models, Addison-Wesley, 1997. [12] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns, Addison-Wesley, 1995. [13] G. Goldkuhl, “Generic Business Frameworks and Action Modelling”, in proceedings of conference Language/Action Perspective’96, Springer, Verlag. [14] T. Gruber, “Toward principles for the design of ontologies used for knowledge sharing”, International Journal of Human Computer Studies, No 43, pp. 907 - 928, 1995. [15] M. Gruninger, “Integrated Ontologies for Enterprise Modelling”, url: http://www.ie.utoronto.ca /EIL/tove/onto-sum.fm.html. [16] D. Harel, "Statecharts: a Visual Formalism for Complex Systems", Science of Computer Programming, vol. 8, no. 3, pp. 231 - 274, 1987. [17] D. C. Hay, Data Model Patterns, Dorset House Publishing, New York, 1996. [18] H. Herrestad and C. Krogh, “Deontic Logic Relativised to Bearers and Counterparties”, in Anniversary Anthology in Computers and Law, Ed. J. Bing. and O. Torrund, pp. 453 - 522, 1995. [19] E. Husserl, Logical Investigations, Prometheus books, 1996. [20] P. Johannesson, “Representation and Communication - A Speech Act Based Approach to Information Systems Design”, Information Systems, vol. 20, no. 4, pp. 291 - 303, 1995. [21] P. Johannesson and P. Wohed, “Modelling Agent Communication in a First order Logic”, Accounting, Management and Information Technologies, vol.8, pp 5-22, 1998. [22] P. Johannesson and P. Wohed, “Deontic Analysis Patterns”, in proceedings of the 3rd International Workshop on The Language Action Perspective on Communication Modelling, Ed G. Goldkuhl, M. Lind, U. Seigerroth, 1998. [23] D. Kung, "The Behavior Network Model for Conceptual Information Modelling", Information Systems, vol. 18, no. 1, pp. 1 - 21, 1993. [24] E. Lehtinen, K. Lyytinen, “Action Based Model of Information System”, Information System, vol. 11, no. 4, pp. 299-317, 1986. [25] M. Lind, G. Goldkuhl, “Reconstruction of different Business Processes – A Theory and Method Driven Analysis”, in proceedings of Conference on Language/Action Perspective ’97, Veldhoven, 1997. [26] N. A. Maiden and A. G. Sutcliffe, “Analogical Matching for Specification Reuse”, in 6th Annual Knowledge-Based Software Engineering Conference, pp. 108-116, Syracuse, New York, IEEE Computer Society Press, 1991. [27] N. A. Maiden and A. G. Sutcliffe, “Exploiting Reusable Specifications through Analogy”, Communications of the ACM, vol. 35, no. 4, pp. 55-64, 1992. [28] J.-J. C. Meyer, “A Different Approach to Deontic Logic: Deontic Logic Viewed as a Variant of Dynamic Logic”, Notre Dame J. of Formal Logic, vol. 29, no. 1, pp. 109-136, 1988. [29] K. Mulligan ed., Speech Act and Sachverhalt: Reinach and the Foundations of Realist Phenomenology, pp. 29-90, Martinus Nijhoff, 1987. [30] Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator and W. Swartout, “Enabling Technology</p><p>13 for Knowledge Sharing”, AI Magazine, vol. 12, no. 3, 1991. [31] R. Prieto-Diaz and P. Freeman, “Classifying Software for Reusability”, IEEE Software, vol. no. 1, pp. 6 - 16, 1987. [32] J. Pustojevsky: The Generative Lexicon, MIT Press, Cambridge, 1995. [33] J.Pustojevsky: “Lexical Semantics and Formal Ontology”, in proceedings of the Formal Ontologies for Information System workshop, pp. 328-336, ed. N. Guarino, IOS Press, 1998. [34] V. Reijswoud, N. v. Rijst, “Modelling Business Communication as a Foundation for Business Process Redesign: A case of production logistics”, in procedings of the 28th Hawaii International Conferece on System Sciences, IEEE Computer Society Press, pp. 841-850, 1995. [35] M. Reicher: Works and Realizations, in proceedings of the Formal Ontologies for Information System workshop, pp. 121-134, ed. N. Guarino, IOS Press, 1998. [36] A. Reinach, “Die apriorischen Grundlagen des bürgerlichen Rechtes” (1913), translated by J. Grossby, “The Apriry Foundations of Civil Law” in Aletheia III, pp 1-142, 1983. [37] C. Rolland and C. Proix, "Natural Language Approach to Conceptual Modeling", in Conceptual Modeling, Databases and CASE: An Integrated View of Information Systems Development, Ed. P. Loucopoulos and R. Zicari, pp. John Wiley, New York, 1992. [38] J. R. Searle, Speech Acts – An Essay in the Philosophy of Language, Cambridge University Press, 1969. [39] A. Seltveit, "An Abstraction-based Rule Approach to Large-scale Information Systems Development", in International Conference on Advanced Information Systems Engineering (CAiSE’93), pp. 328 - 351, Springer Verlag, 1993. [40] R. Wieringa and J. Meyer, “Applications of Deontic Logic in Computer Science: A Concise Overview”, in Deontic Logic in Computer Science, eds. R. Wieringa and J. Meyer, Wiley, 1993. [41] T. Winograd and F. Flores, Understanding Computers and Cognition: A New Foundation for Design, Ablex, Norwood, N.J., 1986. [42] G. H. v. Wright “Deontic Logic”, Mind, vol. 60, pp. 1-15, 1951. [43] C. H. v. Wright, A New System of Deontic Logic, Danish Yearbook of Philosophy 1, 1964.</p><p>14</p>

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    14 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us