Rule based design - CiteSeerX

Rule based design

Draft

Stef Joosten November 1, 2007

2

ii

Contents

1 Inspired by Information

I

1

1.1

A vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.4

Further research . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.5

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.6

Reading Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Practice

11

2 Ampersand

13

2.1

Rules in Business . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2

An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.3

Control Principle . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.4

Case Study: Order process . . . . . . . . . . . . . . . . . . . . . .

19

2.5

Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

iii

iv

CONTENTS

II

Theory

25

3 Rules, Relations and Concepts

27

3.1

Why? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.2

Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.3

Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.4

Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.5

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3.6

Derivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.7

Multiplicities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.8

Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.9

Homogeneous relations . . . . . . . . . . . . . . . . . . . . . . . .

50

4 Working with rules

55

4.1

Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.2

Laws for Relations . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.3

More Laws: Complement . . . . . . . . . . . . . . . . . . . . . .

61

4.4

Laws about Inclusion . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.5

Laws about Multiplicities . . . . . . . . . . . . . . . . . . . . . .

65

4.6

Translating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

III

Tools

75

5 ADL manual

77

5.1

A computer language for business rules . . . . . . . . . . . . . . .

77

5.2

How to install . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

5.3

Your first ADL script

. . . . . . . . . . . . . . . . . . . . . . . .

81

5.4

Example: Delivery . . . . . . . . . . . . . . . . . . . . . . . . . .

83

5.5

When you make mistakes . . . . . . . . . . . . . . . . . . . . . .

86

5.6

ADL Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

CONTENTS

v

6 ADL

97

6.1

Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

6.2

Formal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3

Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Chapter 1

Inspired by Information What inspires people to use Second Life, Apple computers or Google? Why are Pixar and Dreamworks successful in animation? Which buzz draws scores of people to e-Bay and Amazon? How did Skype get where it is today? These are questions that occupy the minds of great designers of information systems. Inspiration, beauty, and fun are the common denominator of information technology today and in the years to come. Feelings, perceptions and experiences of users will increasingly drive the design of successful information systems. Inspired design is demanding, however. It requires designers to express themselves, very much like a violinist. Before creating music that touches the hearts of your audience you must have full control over the instrument. This truth holds for any creative profession. Room for creativity comes, once your skills no longer require your attention. Designing business processes and information systems is no exception. Craftsmanship precedes art. Rule based design was developed as a contribution to the profession of designing information systems and business processes. It offers hope to designers who wish to lift their work to the level of artistry. This book proposes a way to produce flawless (i.e. correct, consistent and complete) designs. It shows how you can be sure that your design fully complies with the requirements of your patrons. It promises you can save time by automating design activities and showing you how to get it right the first time. That should free some mental space to spend on inspiration...

1.1

A vision

This book is written in a firm belief that one day, information systems will be designed and built rapidly, at low cost, and 100% compliant to the rules of 1

2

CHAPTER 1. INSPIRED BY INFORMATION

the organization who ordered the system. Guaranteed functionality and more predictable innovation projects are part of that professionalism. One day, informations systems will be a commodity, abundantly available at predictable (low) cost, defined quality and immediate delivery. Such professionalism will create room for inspired design, leading to beautiful information systems. This book was written for designers who share this desire and are willing to invest in this vision. Besides inspiration and talent, genuine artistry requires knowledge, labor, and craftsmanship. This book aims at making you successful, by providing the knowledge. Labor requires you to practice your techniques until you can do them effortlessly and correctly. Craftsmanship is what you get when doing it for real. The next few sections share with you a vision on business rules in different perspectives: business processes, coherence, information technology, and formal methods.

1.1.1

On business processes

Business rules have a high potential for changing the way we design business processes. Since business rules can be communicated so much easier, rule based BPM carries the promise of bringing BPM closer to the business. This solves the problem of confining process modeles, imposed by workflow technology. Case management [37, 9], which is generally seen as the successor of workflow technology because it provides much more flexibility, still requires businesses to invest in process modeling. Rule based BPM does not have these limitations. It enforces nothing but business rules that are required by the business itself. As a consequence, the design can be automated further. It has also become clear that the power of business rules, when represented in a relation algebra, goes well beyond business process management alone.

1.1.2

On coherence

Coherence among stakeholders of an organisation, both internal and external, grows on clear commitments which are kept. After all, commitments bind people. Each commitment contributes to a coherent organisation from the moment it is maintained. Maintaining a commitment requires explicit and controllable phrasing. To distinguish any agreement from an explicitly and controllably phrased commitment, we reserve the word ”rule” for the latter. A rule that business rule reflects a commitment from the business is consequently called a business rule. You will find lots of theory, leads and inspiration about business rules by reading the Business Rules Manifesto (www.businessrulesgroup.org/brmanifesto.htm)

1.1. A VISION

3

and consulting the world wide web. This book uses business rules as requirements (article 1 of the manifesto) from the business (article 9.1), of the business (article 10.1) and for the business (article 8). Besides, we will take it one step further, and enable you to specify software services using business rules.

1.1.3

On information technology

Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity (article 2.3 of the manifesto). This is precisely how information technology contributes to coherence. Computers can enforce all self-evident rules, since these do not require human interference. All other rules, which are the more interesting ones, are maintained by people. Rule violations can then be signalled by computers, prompting people to take action. The entire system of people and computers then shows coherent behavior, which is determined by the set of rules they are maintaining. The role of information technology is to support that. Because each little rule being maintained is one worry less, this vision brings about simplicity and transparency. Consistent implementation of this vision yields unpolluted databases and demonstrable compliance.

1.1.4

On formalism

Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules (article 5.3 of the manifesto). This book uses a relation algebra to analyse requirements and formulate rules, a formalism equivalent to predicate logic but easier to use. Relation algebras were invented in the nineteenth century by mathematicians, such as De Morgan, Peirce, and Schröder [8, 27, 32]. Their efforts have been studied, maintained and enhanced throughout the twentieth century, providing a well established language and well understood language for describing business rules today. Relation algebras enable professionals of today to describe and manipulate relations effectively, quickly, and without mistakes. Proficiency in this skill will allow you to make specifications, conduct conceptual analyses, and search for and invent new rules. This book makes an effort to introduce a relation algebra slowly, taking the reader on the path to understanding one step at a time. The introduction to relation algebras is found in part ‘Theory’ of this book. If you are new to this topic, prepare for some effort, but rest assured that it will be worthwhile.

4


1.1.5

On methods

Design methods were proposed in the early seventies as an answer to the problem of size and complexity. Today, design methods recognize that several perspectives on an information system are required to get a design right. Design patterns are being advocated in order to reuse design knowledge. Designers of information systems even use the word architecture to underscore the complexity of their task. Progress is being made, but very slowly. If anything, design methods have exposed the full scale of the problem. Different representations of a design, depicted graphically, textually or otherwise, have allowed designers to share the full complexity of the task they embarked in. As a reaction, we have seen the advent of packaged enterprise information systems, promising out-ofthe-box solutions on an enterprise scale. This promise too has proven difficult to achieve. By and large, many organisations still have difficulties designing information systems reliably and repeatably. This is precisely the problem addressed by this book.

1.2

Background

Many business rule engines that are available in the marketplace use rules of the type condition-action, or event-condition-action, both of which can be executed by a computer. Such rules are called ”imperative”, because they contain an action that tells a computer what to do (similar to programming languages). The Business Rules Manifesto [29] stresses the importance of declarative rules (as opposed to imperative rules) for the purpose of capturing the rules of the business. This book does not make business analysts write conditions and actions. We will focus on the commitments, rules and agreements of the business instead, and let conditions and actions be derived by computers. This works, presuming we have the technology to generate software for that purpose. Business rules are as close to the business as one can get. They enlarge the scope of requirements engineering to include business goals [24]. Examples of business rules are: • Applications for a new pension plan are decided upon within three days. (e.g. in the context of a life insurance company) • Applications for green cards are put aside if the identity of applicants cannot be established legally. (e.g. in the context of immigration) • Payments must be authorized by two different staff, both of whom are authorized for the full amount paid. (e.g. in the context of a medical benefits administrator)

1.2. BACKGROUND

5

Business rules formalize mutual agreements between stakeholders, commitments of managers, rights and obligations of employees, etc. into ‘laws’, intended to serve the purpose(s) of an organization. The creation and withdrawal of rules is an ongoing process, similar to a legislative process in a state. This book introduces an approach, Ampersand, which is inspired by the belief that compliance with business rules should come automatically, once agreement about rules has been established. Design artifacts such as data models and service specifications ought to be derived from business rules, rather than drawn up by designers. This requires a formal method supplemented with tools, in which designers represent business rules in heterogeneous relation algebra [31]. The Ampersand approach, a successor of CC [10, 20], was developed for that very purpose. In conjunction with this approach, software has been developed that generates functional specifications directly from business rules. Also, there exists software that generates a protype application to enforce all business rules. For practical reasons, Ampersand has been designed such that any formal language is used exclusively by designers only. At no occasion the need arises to confront users with the formalism. Yet, business analists and software architects must learn how to use it, though. Our experience in teaching the method has shown that they can learn to use the language in a 100 hour course. Rule based design draws on research on business rules, software engineering, relation algebra, and design methodology. Let us look at each of these topics briefly. Research on business rules has a long tradition. Much of the research is related to active databases [7], that use the ECA pattern (event-condition-action) to describe rules. In research aimed at automating software design, such as [39], this leads to the assumption that business rules must be executable. From a business perspective, this is not necessarily true. A counterexample: the rule ‘every action performed must be authorized by a superior’, would become quite unworkable if every action performed would trigger an authorization request to a superior. In the Ampersand approach, actions are not specified, but derived. It is a purely declarative approach. All ECA-rules required to make computers work are derived (by a tool), enabling an error-free implementation of requirements. In a comparison of available methodologies for representing business rules, Herbst et.al. [14] show that common methods are insufficient or at least inconvenient for a complete and systematic modeling of business rules. That study remarks that rules in all methodologies can be interpreted as ECA-rules. However, the authors do not identify the imperative nature of ECA-rules as an explanation for the shortcomings of methodologies. Methodologists generally place business rules on the data side of business models [34]. The Ampersand approach uses business rules to actually define the business process, making them relevant to both the data and the process side of information systems. The fact that this

6


requires a formal method has consequences [40]. It means that system boundaries can be articulated, the functional behaviour of the system is defined, and there is proof that the system meets its specification. Outside academia, business rules are increasingly acknowledged as an important development. Several interest groups exist: Business Rules Forum http://www.businessrulesforum.com/ Business Rules Group http://www.businessrulesgroup.org/brghome.htm European Business Rules http://www.eurobizrules.org/ Conference Business Rules Commu- http://www.brcommunity.com/index.shtml nity Market researcher Gartner expects licence revenue in business rules technology to grow by 9.1% until 2010. Most rule engines that are available in the market place provide decision support by means of separating business rules from process logic. Current research on business rules takes similar directions, e.g. [2, 35, 26]. An advantage of separating business rules from process logic is that business processes (such as a mortgage application procedure) can be kept stable as rules and regulations change. By the same count, however, this separation restricts the use of business rules to applications in which the process is not affected, leaving designers with two tasks: rule modeling and process modeling. The Ampersand approach lifts this restriction, because the process is derived from business rules. Our finding that business rules are sufficient to define business processes, corroborates the claim of the Business Rules Group [29] that rules are a first-class citizen of the requirements world (article 1.1 of the manifesto). The phrase ‘sufficient to define business processes’ implies that designers need not communicate with the business in any other way. If desired, they can avoid to discuss technical artifacts (data models, etc.) with the business. As a consequence, requirements engineering can stay much closer to the business, by using the language of the business proper. This supports the Business Rules Group in her claims that business rules are a vital business asset, that rules are more important to the business than hardware/software platforms, and that business rules, and the ability to change them effectively, are fundamental to improving business adaptability. Using relation algebra to describe the rules of an organization is a novel contribution of Ampersand. The formalism has been studied extensively and is well known for over a century [8, 27, 32]. Computer professionals are made familiar with it as part of their discrete mathematics courses. The information systems community is aware (e.g. [28]) that mathematical representations of business rules can be useful. Date [6] has criticized SQL for being unfaithful to relation algebra and advocates declarative business rules instead as an instrument for application development. This book implements some of Date’s ideas, by using relation algebra faithfully to describe business rules and define the application both at the same time.

1.3. PRACTICE

1.3

7

Practice

Various research projects and projects in business have supplied a significant amount of evidence that supports the power of business rules. These projects have been conducted in various locations. Research at the Open University of the Netherlands (OUNL) has focused on two things: developing the method, developing the course, and building a violation detector. Research at Ordina and TNO Informatie- en Communicatie Technologie has been conducted to establish the usability of ADL-rules for representing genuine business rules in genuine enterprises. Collaboration with the university of Eindhoven has produced a first design of a rule base. Experiments conducted at TNO, KPN, Bank MeesPierson, ING-Bank, Rabobank and Delta Lloyd have provided experimental corroboration of the method and insight in the limitations and practicalities involved. This section discusses some of these projects, pointing out which evidence has been acquired by each one of them. The CC-method, the predecessor of Ampersand, was conceived in 1996, resulting in a conceptual model called WorkPAD [19]. The method used relational rules to analyze complex problems in a conceptual way. WorkPAD was used as the foundation of process architecture as conducted in a company called Anaxagoras, which was founded in 1997 and is now part of Ordina. Conceptual analyses, which frequently drew on the WorkPAD heritage, applied in practical situations resulted in the PAM method for business process management [22], which is now frequently used by process architects at Ordina and within her customer organizations. Another early result of the CC-method is an interesting study of van Beek [36], who used CC to provide formal evidence for tool integration problems; work that led to a major policy shift in IT-projects. The early work on CC has provided evidence that an important architectural tool had been found: using business rules to solve architectural issues is large projects. For lack of funding, the CC-method has long been restricted to be used in conceptual analysis and metamodeling [21, 11], although its potential for violation detection became clear as early as 1998. Metamodeling in CC was first used in a large scale, user-oriented investigation into the state of the art of BPM tools [12], which was performed for 12 governmental departments. In 2000, a violation detector was written for the ING-Sharing project, which proved the technology to be effective and even efficient on the scale of such a large software development project. After that, the approach started to take off. In the meantime, TNO Informatie- en Communicatie Technologie (at that time still known as KPN Research) has used CC modeling for various other purposes. For example, CC modeling has been used to create consensus between groups of people with different ideas on various topics related to information security, leading to a security architecture for residential gateways [18]. Another purpose that TNO used CC modeling for was the study of international standardizations

8


efforts such as RBAC (Role Based Access Control) in 2003 and architecture (IEEE 1471-2000) [15] in 2004. Several inconsistencies have been found in the last (draft) RBAC standard [3]. Also, it was noticed that for conformance, the draft standard does not require to enforce protection of objects, which one would expect to be the very purpose of any RBAC system. The analysis of the IEEE 1471-2000 recommendation has uncovered ambiguities in some of the crucial notions defined therein. Fixing these ambiguities and making the rules governing architectural descriptions explicit has resulted in a small and elegant procedure for creating (parts of) such architectural descriptions in an efficient and effective way [17]. Additional research at TNO [38] currently investigates the possibilities for creating context dependent ’cookbooks’ for creating architectural descriptions in a given context, based on CC-modelling. The efforts at TNO have provided the evidence that the CC-method works for its intended purpose, which is to accellerate discussions about complex subjects and produce concrete results from them in practical situations. In 2002 research at the OUNL was launched to further this work in the direction of an educative tool. This resulted in the ADL language, which was first used in practice by Bank MeesPierson [5]. The researcher described rules that govern the trade in securities at MeesPierson. He found that business rules can very well be used to do perpetual audit, solving many problems where control over the business and tolerance in daily operations are in conflict. At Rabobank, in a large project for designing a credit management service center, debates over terminology were settled on the basis of metamodels built in CC. These metamodels resulted in a noticable simplification of business processes and showed how system designs built in Rational Rose should be linked to process models [4]. The entire design of the process architecture [25] was validated in CC. At the same time, CC was used to define the notion of skill based distribution. This study led to the design by Ordina of a skill based insurance back-office for Interpolis. The same CC-models that founded the design at Interpolis were reused in 2004 to design an insurance back office for Delta Lloyd. This work provided useful insights about reuse of design knowledge. It also demonstrated that a collection of business rules may be used as a design pattern [13] for the purpose of reusing design knowledge. In 2005 Ordina started a project to make knowledge reuse in the style demonstrated at Delta Lloyd into a repeatable effort. In 2006, the CC-method was refined into the Ampersand approach at the OUNL by adding the capability to generate functional specifications from rules.

1.4

Further research

This research shows that business rules have a high potential for changing the way business processes and information systems are designed. Since business

1.5. ACKNOWLEDGEMENTS

9

rules can be communicated so much easier, rule based BPM carries the promise of bringing BPM closer to the business. The process control principle introduced in this chapter 2 takes business rules one step further: it shows that business rules can be used to control processes without using a process model. This is achieved by exploiting the implicit temporal constraints that can be derived from (static) business rules. This solves the problem of restrictively ordered activities, imposed by workflow technology. Currently, process modeling techniques force an ordering of activities upon the organization, which can sometimes be too confining. Where case management [37, 9] provides much more flexibility, it still requires process modeling and still requires a significant design effort. Rule based BPM does not have these limitations. It enforces only the rules that an organization is bound to, either by outside sources (e.g. legislation) or by creating rules internally. To use rule based process control, designers must learn to represent business rules in relation algebra. Evidence gathered so far suggests this can be done, but more work is required to make it easy. Further research is planned to make tools that help designers formulate business rules in a graphical manner. Potential benefits are possible in compliance and governance, as required for instance by Sarbanes-Oxley [1] and other legislature. Our findings support a tighter integration of formal methods in software engineering [40]. The increased quality of specifications can make offshoring much easier. It has also become clear that the power of business rules, when represented in relational algebra, goes well beyond business process management alone. Rules have also been used in architectural studies, reusing knowledge in design patterns. Also, rules can be used to describe the modeling techniques and methods themselves; this is referred to as Metamodeling. The Open University of the Netherlands is currently teaching a metamodeling course and a business rule course, both of which employ the tools described in this book. Further research is required to bring this work from principle to production. Work on a business rules repository is ongoing. The ADL-language will be extended beyond relation algebra to enhance support for process design. The prototype generator is being made suitable for use by business analysts, to enhance their ability to make good designs.

1.5

Acknowledgements

I wish to thank all of Ordina’s customers who have contributed to this work. The fact that they must remain anonymous does not diminish their contributions. The issues they raised in their projects have inspired Ampersand directly and indirectly. Besides, I wish to thank TNO in Groningen (the Netherlands) for being the first user of Ampersand.

10

1.6


Reading Guide

(NOG SCHRIJVEN...) Section 2.1 introduced a process control principle that employs business rules, which was illustrated in section 2.2. Section 2.3 explained how this principle is used in an organization. Section 2.4 showed that this principle works in a case study. The consequences of this new principle were addressed in section 2.5 and finally section 1.3 gave an overview of further evidence that has been gathered in practice.

Part I

Practice

11

Chapter 2

Ampersand An Approach to Control Business Processes Abstract This chapter shows how to use business rules for specifying both business processes and the software that supports them. This approach yields a consistent design, which is derived directly from business rules. This leads to software that complies with the rules of the business. The approach, called Ampersand, is specifically suited for business processes with strong compliance requirements, such as financial processes or government processes that execute legislature. Features of Ampersand are: rules define a process, no process modeling is required, compliance with the rules is guaranteed, and rules are maintained by systematically signalling participants in the process. Evidence that this principle works in practice is given by a case study.

2.1

Rules in Business

Business rules can be used to manage and control business processes. In this sense, business rules actually define the process. This yields compliant systems and compliant processes. This chapter explains the principle, which can be summarized as: signal violations (in real time) and act to resolve them. This 13

14

CHAPTER 2. AMPERSAND

defines a process engine that complies with all business rules. The consequence is that business rules are sufficient as an instrument to design compliant business processes and information systems. Whenever and whereever people work together, they connect to one another by making agreements and commitments. These agreements and commitments constitute the rules of the business [29]. A logical consequence is that the business rules must be known and understood by all who have to live by them. From this perspective business rules are the cement that ties a group of individuals together to form a genuine organization. In practice, many rules are documented, especially in larger organizations. Life of a business analist can hardly be made easier: rules are known and discussed in the organization’s own language and all stakeholders know (or are supposed to know) the rules. The role of information technology is to help maintain business rules. That is: if any rule is violated, a computer can signal that and prompt people (inside and outside the organization) to resolve the issue. The Ampersand approach uses this as a principle for controlling business processes. For that purpose two kinds of rules are distinguished: rules that are maintained by people and rules that are maintained by computers. A rule maintained by people may be violated temporarily, for the time required to fix the situation. For example, if a rule says that each benefit application requires a decision, this rule is violated from the moment an application arrives until the corresponding decision is made. This temporary violation allows a person to make a decision. For that purpose, a computer monitors all rules maintained by people and signals them to take appropriate action. Signals generated by the system represent (temporary) violations, which are communicated to people as a trigger for action. A rule maintained by computers need never be violated. Any violation is either corrected or prevented. If for example a credit approval is checked by someone without the right authorization, this can be signalled as a violation of the rule that such work requires authorization. An appropriate reaction is to prevent the transaction (of checking the credit application) from taking place. In another example the credit approval might violate a rule saying that name, address, zip and city should be filled in. In that case, a computer might correct the violation by filling out the credit approval automatically. Since all rules (both the ones maintained by people and the ones maintained by computers) are monitored, computers and persons together form a system that lives by the rules. This establishes compliance. Business process management (BPM) is also included, based on the assumption BPM is all about handling cases. Each case (for instance a credit approval) is governed by a set of rules. This set is called the procedure by which the case is handled (e.g. the credit approval procedure). Actions on that case are triggered by signals, which inform users that one of these rules is (temporarily) violated. When all rules are

2.2. AN EXAMPLE

15

satisfied (i.e. no violations with respect to that case remain), the case is closed. This yields the controlling principle of BPM. This principle rests solely on rules. Computer software is used to derive the actions, generating the business processs directly from the rules of the business. In comparison: workflow management derives actions from a workflow model, which models the procedure in terms of actions. Workflow models are built by modelers, who transform the rules of the business into actions and place these actions in the appropriate order to establish the desired result. This new approach has two advantages: the work to make a workflow model can be saved and potential mistakes made by process modelers can be avoided. It sheds a different light on process models, whose role is reduced to documenting and explaining a process to human participants in the process. Process models no longer serve as a ‘recipe for action’, as is the case in workflow management. The following section discusses an example, that illustrates this process control principle.

2.2

An example

Consider the handling of permit applications by a procedure based solely on rules. Each permit application is seen as a case to be handled, using the principle of rule based process control (section 2.1). First the business rules are given that define the situation. We subsequently discuss a scenario of the demonstration that is given with the generated software and the data model (also generated from the rules) on which that application is based. The example consists of the following business rules. 1.

An application for a permit is accepted only from individuals whose identity is authenticated.

2.

Applications for permits are treated by authorized personnel only.

3.

Every application leads to a decision.

4.

An application for a particular product (the type of permit) leads to a decision about that same product.

5.

Employees get assigned to particular areas. This means that an assigned employee treats request from these areas only.

First, we establish that each statement is indeed a business rule by showing that each rule is falsifiable. For that purpose, one example is given of a violation for each rule:

16


1.

An application for a permit from an individual whose identity is unknown.

2.

An application that is treated by unauthorized personnel.

3.

A permit application without a decision.

4.

An application for a building permit that leads to a decision about a hunting permit.

5.

An employee assigned to Soho who treats a request from East End.

As for the IT consequences, notice that violation 4 can be prevented by a computer, by consistently choosing the type of the permit as the type of the corresponding decision. This causes rule 4 to be free of violations all the time. Rule 3 may be violated for some time, but in the end a decision must be made. So the work is assigned to an employee who makes that decision. Rules 1, 2, and 5 are enforced by blocking any transaction that violates the rules. Thus, a system emerges that complies with all five rules. An application that controls this process has been built by representing the rules in the language ADL, a syntactically sugared version of relation algebra [23]. The functional specification was generated by software that translates a set of relational algebra rules into a conceptual model, a data model (see figure 2.1), and a catalog of services with their services defined formally. This specification defines a software system that maintains all rules mentioned above. The specification guarantees that rules 1, 2, 4, and 5 can never be violated and rule 3 yields a signal as long as a decision on the application is pending. A compliant implementation was obtained by building a prototype generator that produces a database application according to the given specification. A dialog1 between user and computer might proceed as follows: 1.

an employee creates a new application for ‘Joosten’, who wants to have a ‘building permit’.

2.

the system returns an error message for violating rule 1. This means that an application for a permit from an individual whose identity is unknown is not accepted.

3.

the employee remembers he should have checked the identity of the applicant. He asks for identification and enters the applicant’s passport number into the system.

4.

Now the employee can register the new application. As far as this employee is concerned, he is done with the application.

1 This is an actual scenario, that is used in demonstrations of information systems generated by business rules.

2.3. CONTROL PRINCIPLE

17

5.

Now an employee must be allocated for making the decision. If an employee is chosen in violation of rules 2 or 5, that transaction is blocked.

6.

The employee who makes the decision registers it in the system. The fact that this decision is about a building permit is copied (by the computer) from the application, without any interference from the employee.

Notice that this system may be criticized for picking an employee ‘by hand’. This behavior is a logical consequence of not having the rules in place for picking employees. One could argue that the system is incomplete, because there are too few rules. Adding appropriate rules will yield a process in which employees are assigned automatically. This illustrates how a limited (even partial) set of rules can be used already to generate process control. In practice, this means that process control may be implemented incrementally. Automated data analysis also yields a class diagram, generated from the business rules. The result is shown in figure 2.1. The generator also produces a formal

Figure 2.1: Data structure of permit applications specification of the software services required to maintain all rules. This service catalog is not reproduced here for the sake of brevity.

2.3

Control Principle

After discussing rule based design (section 2.1) and illustrating it with an example (section 2.2), let us discuss the consequences of rule based control of business processes in some more detail. The principle of rule based BPM is that any violation of a business rule may be used to trigger actions. This principle implements Shewhart’s Plan-Do-CheckAct cycle (often attributed to Deming) [33]. Figure 2.2 illustrates the princi-

18


Figure 2.2: Principle of rule based process management ple. Assume the existence of an electronic infrastructure that contains data collections, functional components, user interface components and whatever is necessary to support the work. An adapter observes the business by drawing information from any available source (e.g. a data warehouse, interaction with users, or interaction with information systems). The observations are fed to a detector, which checks them against business rules in a rule base. If rules are found to be violated, the detector signals a process engine. The process engine distributes work to people and computers, who take appropriate actions. These actions can cause new signals, causing subsequent actions, and so on until the process is completed. The system as a whole cycles repeatedly through the phases shown in figure 2.3. The detector detects when rules are violated and signals this by analyzing events as they occur. The logic to detect violations dynamically is derived from the business rules. This results in systematic and perpetual monitoring of business rules.

2.4. CASE STUDY: ORDER PROCESS

19

Figure 2.3: Engine cycle for a rule based process engine Signals that are sent to specific actors (either automated or human) will trigger actions. These actions can cause other rules to produce signals by which other actors are triggered. So the actual order of events is determined dynamically.

2.4

Case Study: Order process

This section provides evidence in support of the Ampersand approach. Proof that a business process can be represented in relation algebra is given by showing the actual code in relation algebra. Proof that the corresponding application exists is available on http://86.88.190.85/orderprocess.php, where it can be tried out by the reader. This section supplements that by a screenshot (figure 2.4) and a dialog scenario, for those readers not in a position to inspect the application for themselves. The case study defines an order process between providers and clients. It illustrates a multi-step process involving orders, deliveries, and invoices. First an enumeration of all business rules is given. That constitutes the order process. Then the formal representation is presented in relation algebra. Subsequently, a scenario is presented in which one order is processed from beginning to the end. The process is defined by the following ten business rules: 1.

Ultimately all orders issued to a provider must be accepted by that very provider. The provider will be signalled of orders waiting to be accepted.

20


2.

A provider can accept only orders issued to himself.

3.

No delivery is made to a client without an order accepted by the provider.

4.

Ultimately, each order accepted must be delivered by the provider who has accepted that order. The provider will be signalled of orders waiting to be delivered.

5.

All deliveries are made to the client who ordered the delivery.

6.

A client accepts invoices for delivered orders only.

7.

There must be a delivery for every invoice sent.

8.

For each delivery made, the provider must send an invoice. The provider will be signalled when invoices can be sent.

9.

Accept payments only for invoices sent

10.

Each invoice sent to a client must be paid. Both the client and the provider will be signalled for payments due.

These rules can be used by a computer after translating them to relation algebra. These very rules are used in chapter 3 to introduce the formal notations. The process, which is defined by these rules is best illustrated by the following (typical) scenario: 1.

The client creates a new order. This generates a signal for the provider. The signal is a logical consequence of rule 1, which is (temporarily) violated by an order that has been issued by a client, but is not accepted (yet).

2.

The provider must accept the order, which generates a signal to deliver the order. The signal is a logical consequence of rule 4, which is (temporarily) violated by an order that has been accepted, but is not (yet) delivered.

3.

The provider must deliver the order, generating a signal to send out an invoice. This is a logical consequence of rule 8, which is (temporarily) violated by a delivery made, without a corresponding invoice.

4.

The provider sends an invoice, which creates a signal to the client that an invoice is due for payment. The signal is a logical consequence of rule 10, which is (temporarily) violated by an invoice that has not been paid (yet).

5.

The client pays the invoice, and no more signals are raised. This means that the order has been processed completely and the case is closed.

2.4. CASE STUDY: ORDER PROCESS

21

Figure 2.4: Service layer interface for order process example The prototype generator was used to generate a service layer for rule based process control. It derives the temporal logic as shown above. Together with a generic interface, the service layer yields a fully functional application as shown in figure 2.4. The following scenario gives the flavour for readers who cannot try this for themselves. Initially all four signals (see figure 2.4) are void. 1.

The client creates a new order for ‘Gates Inc.’. He does so by filling out the fields ‘addressedTo’ and ‘from’2 . The effect of this action is that a new order number is issued and a signal is raised for ‘Gates Inc.’ to accept this order.

2.

Provider ‘Gates Inc.’ can accept the order by filling in the name ‘Gates Inc.’ in field ‘accepted’. The effect of this action is that a signal is given to ‘Gates Inc.’ for delivering the order.

3.

Provider ‘Gates Inc.’ will see a delivery record, which is partially filled in: it contains only the order number. The moment the provider tries to fill out the empty fields in this form, the computer fills out all fields in the delivery form which are uniquely determined. That is the name of the client and the name of the provider. For a user, this is natural behaviour, because the computer ‘already knows’ these facts. In the meantime, a signal is raised saying that an invoice can be sent.

4.

When the provider tries to fill out the invoice, again the computer will fill out all know (i.e. uniquely determined) facts. This yields a partially filled invoice registration, and a signal to the client that an invoice is due for payment. 2 These

fields correspond with the relations used in the formalization.

22


5.

When the client pays the invoice, the field ”paidBy” can be filled in and the case is closed. By this time, all signals are empty again.

In the actual application, different orders of events can be tried. For example, a delivery can be made before an order is accepted, or the client can be filled in long after the delivery has been made. The application will accept any order of events until it leads to violations.

2.5

Consequences

Controlling business processes directly by means of business rules has consequences for designers, who will encounter a simplified design process. From a designer’s perspective, the design process is depicted in figure 2.5. The effort of

Figure 2.5: Design process for rule based process management design focuses on requirements engineering. The main task of a designer is to collect rules to be maintained. From that point onwards, a generator (G) produces various design artifacts, such as data models, process models etc. These design artifacts can then be fed into a information system development environment (the other generator, G). That produces the actual system. Alternatively, the design can be built in the conventional way as a database application. The rule base (RAP, currently under development) will help the designer by storing, managing and checking rules, to generate specifications, analyze rule violations, and validate the design. For that purpose, the designer must formalize each business rule (in ADL). He must also describe each rule in natural language for the purpose of communication to users, patrons and other stakeholders.

2.5. CONSEQUENCES

23

From the perspective of an organization, the design process looks like figure 2.6. At the focus of attention is the dialogue between a problem owner and

Figure 2.6: Design process for rule based process management a designer. The former decides which requirements he wants and the latter makes sure they are captured accurately and completely. The designer helps the problem owner to make requirements explicit. Ownership of the requirements remains in the business. The designer can tell with the help of his tools whether the requirements are sufficiently complete and concrete to make a buildable specification. The designer sticks to the principle of one-requirement-one-rule, enabling him to explain the correspondence of the specification to the business.

24


Part II

Theory

25

Chapter 3

Rules, Relations and Concepts From this chapter you can learn how to express rules in terms of relations and concepts. But why would you? The main reason is that rules can describe your business and they can serve as a specification for applications and processes. So, rules are pivotal in bridging the gap between business and IT. They can describe governance issues in banks, pricing policies of retailers, or network security at telecom providers. Any rule that is worth to live by is a rule worth to be described: for example, in the banking business a check must be signed and may not bounce, in the retail business the price on the shelf must cover cost plus profit, and in the telecom business information may not cross the border of a security ring unless sealed and authorized. We call any rule that is used to govern the business a business rule. Essentially, a business rule can be any verifiable agreement among stakeholders. If rules are to specify computer applications and business processes, they must be formalized. Specification is however not the only benefit of formalization. It allows inconsistencies to be uncovered, audits to be held, and differences of interpretation to be exposed. By studying this chapter, you may learn to identify, formulate, and use rules to various ends. For the purpose of writing rules, you will learn to use a relation algebra, a lesser known, but well established branch of mathematics. This text helps you to formulate rules correctly and precisely, establish their relevance, and use them to make useful and relevant specifications. This chapter introduces a relation algebra from the very beginning, assuming only that you have a basic understanding of sets. The text is aimed at engineers 27

business rule

28

CHAPTER 3. RULES, RELATIONS AND CONCEPTS

and designers who are interested in solving business problems in terms of business rules. If you are already familiar with relation algebras, you can safely skip this chapter. This primer was designed for professionals who want to learn just enough formalism to cope. Examples illustrate most of the theory, helping you to understand the formalism. There are numerous textbooks, readers, and scientific literature about relation algebras. In fact, many excellent introductions exist to date. The ”Background Material” of Jipsen, Brink, and Schmidt1 [16] deserves recommendation as a reference manual for relation algebras in general. We will specifically use heterogeneous relation algebras [31]. Both references [16] and [31] are in the same book. Roger Maddux’s book on relation algebras [23] is an excellent encyclopedic resource for those interested in studying the topic itself.

3.1

Why?

Your skills in rule based design will make you a better information systems designer. But how do rules, relations and concepts help you to specify solutions to real problems? This question has many answers: you can make solutions explicit, make rules specific, make designs precise, and disambiguate discussions. Let us discuss each of these answers briefly, identifying their benefits on the way. Explicitly specifying a solution to the real problems of your business can require substantial skills, effort, and perseverance. If you are one of those people who are supposed to deliver solutions, your skill to make things explicit is invaluable. Your learning effort will pay off from the moment you start making rules explicit. Whether your organization has to live up to agreements in an SLA (service level agreement), whether the law or internal regulatory bodies enforce rules upon the organization, or whether people simply agree on a particular way of working, rules represent the mortar that brings people (and institutions) together. specific A business rule is called specific if it is clear in which case the rule is violated.

All other business rules are called generic. For instance, the rule “We always do fair trade” is generic, because it does not specify under which circumstances we consider the trade unfair. On the other hand: “We give associated farmers at least a yearly defined minimum price for every bag of coffee” is a specific business rule, because every bag of coffee that makes less than the yearly defined minimum price is obviously in violation. Rule based design uses specific business rules literally as a set of requirements to define the functionality of computer applications and the allowable behaviour in business processes. By writing business rules in a relation algebra, each rule you write is specific to begin with. Used as a specification language, relation algebras have the power to capture all specific business rules. The formalism gives much ‘for free’. There are tools that 1 In this introduction, the reader may recognize some of the skillfully crafted sentences and formulas from Jipsen, Brink, and Schmidt, whose work is gratefully acknowledged.

3.2. PRELIMINARIES

29

check rules for consistency errors. With other tools, you can even generate a functional specification for such an application, saving you the effort of desiging it yourself. As a specification language, relation algebras have shown great value in analyzing conceptual problems. Precision is required if you want to re-use (parts of) other people’s designs. A car manufacturer uses highly standardized technical drawings to avoid misinterpretations, ensuring that for instance a backlight-assembly can be built in Korea and assembled in Detroit. A pharmaceutical company uses chemical formulae to ensure that a drug is manufactured consistently to specification. Professionals must be able to rely on their notations to ensure that a specification can be interpreted in a unique way. Being a formal language, a relation algebra ensures just that. Thus, rule based design takes business rule technology one step further than condition-action rules and event-condition-action rules, which are typically used for decision-making only. Relation algebras provide rules that are suitable for deriving an entire information system, including decision making. Unambigously agreeing over something, whatever that something might be, can prevent many discussions. If you can bring a group of people to adopt a specific rule, any dispute can be settled by checking whether that rule is violated. As relation algebras are perfectly suited for manipulation by computers, you can even employ automated support to settle possible disputes. This frees the road to flawless business operations, thus removing an important obstacle towards inspired design, artistic beauty, and creativity in information technology.

3.2

Preliminaries

In order to define relations, you need to be familiar with sets. This section merely defines the notations used in the sequel, assuming that you have previously learned about sets. The following typographic conventions are meant to ease your reading effort: Sets are written with names starting with a capital letter, such as Book , A, and PDC . The name itself (e.g. Book ) may provide you with a clue as to which kind of elements are in the set. Lowercase letters, possibly suffixed by apostrophes, denote these elements. Where appropriate, such a lowercase letter will match the first letter of the set. The expression b ∈ Book states the fact that there is a book, which is represented by b. We pronounce: ”b is an instance of Book ”, or ”b is an element of Book ”, or ”b is a member of Book ”. Given a set X and a property P , the set of all instances of X that satisfy P is denoted by: {x ∈ X| P (x)}

or

{x|x ∈ X and P (x)}

(3.1)

set

instance

30


The property P is often described informally, but is understood to be an abbreviation for a precise expression in some formal language. The following relations and operations on sets are used throughout this book: • equality: X = Y if X and Y contain the same instances, • inclusion: X ⊆ Y if every instance of X is also an instance of Y , • union: X ∪ Y is the set of instances in X or Y , • intersection: X ∩ Y is the set of instances in X and Y , • complement: X is the set of instances that are not in X, These notations allow us to manipulate with sets in a formal way, using the well-established laws of set theory. Some of the best known ones are captured by equations 3.2 through 3.10. For any set X, Y , and Z X⊆X X ⊆ Y and Y ⊆ Z imply X ⊆ Z X ⊆ Y and Y ⊆ X imply X = Y X ∪Y =Y ∪X X ∩Y =Y ∩X (X ∪ Y ) ∪ Z = X ∪ (Y ∪ Z) (X ∩ Y ) ∩ Z = X ∩ (Y ∩ Z) (X ∩ Y ) ∪ Z = (X ∪ Z) ∩ (Y ∪ Z) (X ∪ Y ) ∩ Z = (X ∩ Z) ∪ (Y ∩ Z)

(⊆ is reflexive) (⊆ is transitive) (⊆ is antisymmetric) (∪ is commutative) (∩ is commutative) (∪ is associative) (∩ is associative) (∪ distributes over ∩) (∩ distributes over ∪)

(3.2) (3.3) (3.4) (3.5) (3.6) (3.7) (3.8) (3.9) (3.10)

Such laws are useful, because they allow you to manipulate with sets without any reference to their contents.

3.3

Relations

Relations are the ‘bricks’ out of which specifications are built. Think of table 3.1 as an example of a relation that shows which client has paid which invoice. Let us call this relation paid . It actually stands for three facts: Client Applegate has paid invoice number 5362a, Brown has paid invoice 721i, and Conway has paid invoice 9443a. Being so small a relation, paid can be shown in its entirety. However, quoting an entire telephone directory in this way would be very impractical. Relations allow us to talk about the contents without actually quoting

3.3. RELATIONS

31 Client Applegate Brown Conway

Invoice 5362a 721i 9443a

Table 3.1: Contents of paid

those contents. This allows us to discuss large, realistic relations from real life, such as telephone directories, account administrations, and land registries. In this example, paid is a relation that relates two concepts: Client and Invoice. Client is called the source of paid and Invoice is called the target of the relation. Any relation has a name, a source, a target, and contents. By convention, names of relations start with a lowercase letter and names of concepts (i.e. source and target) start with an uppercase letter.

relation concept

If we interpret concepts Client and Invoice as sets, the relation paid is a set of pairs (syn: tuples). In order to introduce (syn: declare) a relation (e.g. paid ), we write: paid : Client×Invoice

(3.11)

This is called a declaration, which means that there exists a relation paid with source Client and target Invoice. If relations r and s have identical name, source, and target, they are actually the same relation and consequently they have the same contents. Different relations may therefore have identical names, provided one or both concepts (either source or target) are different. So name, source, and target determine the contents of a relation uniquely. The notation r[A,B] is always sufficient to refer to a relation. When the context excludes any confusion, it is sufficient to use r to refer to the relation.

declaration

Actually, the notation A × B denotes a set of pairs. Every pair ha, bi that is an instance of A × B satisfies a ∈ A and b ∈ B. So, every relation rel that has source A and target B, is a subset of A × B:

pair

rel[A,B] ⊆ A × B

(3.12)

Instead of hx, yi ∈ rel , the shorter notation x rel y is commonly used. For example, the fact that Applegate and 5362a are related in the relation paid , is written as: Applegate paid 5362a

(3.13)

A relation can be represented in many different ways, such as mathematical forms, tabular forms, in matrix forms, and various graphical forms. Let us look

32


at an example. The mathematical notation of a relation provided reads as follows: provided provided

: Provider × Delivery = {hCandy’s candy, Cookies #0382i, hCarter, Jelly beans #4921i , hCarter, Peanut butter #1993i }

(3.14)

This relation means that a delivery of cookies, marked with delivery number 0382, has come from Candy’s candy, whereas Carter has provided both the jelly beans (delivery number 4921) and the peanut butter (#1993) in two distinct deliveries. Provider and Delivery both are sets. They might be defined by (for instance): Provider Delivery

= {Candy’s candy, Carter, Walmart} = {Cookies #0382 , Jelly beans #4921 , Peanut butter #1993}

(3.15)

Example (3.14) represents the relation provided in a mathematical form. A tabular form tabular representation of the same relation looks like this:

Provider Candy’s candy Carter Carter

Delivery Cookies #0382 Jelly beans #4921 Peanut butter #1993

(3.16)

matrix form A matrix representation looks like this:

Cookies #0382 Jelly beans #4921 Peanut butter #1993

Candy’s candy ×

Carter × ×

Walmart (3.17)

graphical form A Venn-diagram is a graphical form of representing a relation, which is shown

in figure 3.1. Venn-diagrams show the contents of a relation and its source and target. In practice, people write relations in many different forms. A telephone directory relates names and addresses to telephone numbers in a tabular manner and a dictionary does the same with words and their meanings. Still, the representations of telephone directories and dictonaries may vary, even though both are in essence tabular forms. The effort people spend in communicating the contents of such relations underlines the importance of carefully choosing your representations. As a designer, you too will spend that effort once you expose the contents of a relation to the public. Before that time, however, you will work with relations without bothering about their contents.

mathematical

3.3. RELATIONS

33

Figure 3.1: Graphical representation of provided

By abstracting away from the contents, you can oversee the structure of many relations at the same time. For that purpose, you may find it useful to draw conceptual diagram conceptual diagrams. Figure 3.2 contains an example2 , which represents ten

Figure 3.2: conceptual model of trading

relations in one diagram. In conceptual diagrams, arcs represent declarations.

2 The entire example, including the rules in section 3.5, was communicated to the author by Rieks Joosten.

34


Figure 3.2 represents the following declarations: paid sent deliveredto for from from provided of accepted issued

: : : : : : : : : :

Client × Invoice Invoice × Client Delivery × Client Invoice × Delivery Order × Client Invoice × Provider Provider × Delivery Delivery × Order Provider × Order Order × Provider

(3.18) (3.19) (3.20) (3.21) (3.22) (3.23) (3.24) (3.25) (3.26) (3.27)

Each dot in the diagram represents a concept, which is used as source or target of relations. The name of a relation is written near the arc, located such that it is clear which name belongs to which arc. A little arrowhead in the middle of an arc points from source to target. Thus, each arc corresponds to precisely one declaration. The little arrowhead in the middle of an arc helps you to remember which concept is source and which is target. Note that each arc determines a corresponding relation uniquely, because name, source, and target are known for each line (cf. page 31).

3.4

Operators

In order to work with relations, we use the following operators: ∪, ∩, , V, ;, , I, †, `, and ≡. These operators are called relational because they all yield relations. In this section we introduce all but the last two (` and ≡), which are introduced in section 3.5. We define the relational operators in terms of sets3 . `

Relational operators ∪ (union) and ∩ (intersection) are already known as set operators, due to the fact that relations may be perceived as sets. The expression r ∪ s is the set of pairs in r or in s and r ∩ s is the set of pairs in r and in s. Let an example illustrate this. If candyprice = {hJelly, 1.05i, hChocolate, 0.80i, hApples, 2.50i}, for example, and groceryprice = {hChocolate, 0.80i, hApples, 2.95i}, then

3 an

candyprice ∪ groceryprice

= {hJelly, 1.05i, hChocolate, 0.80i, hApples, 2.50i, hApples, 2.95i}

candyprice ∩ groceryprice

= {hChocolate, 0.80i}

algebraic definition is given on page ??.

3.4. OPERATORS

35

Union and intersection are defined as follows: • Let r : A×B and s : A×B , then r ∪ s (the union of r and s) is defined by: r ∪ s : A×B

and

r ∪ s = {ha, bi| a r b or a s b}

(3.28)

• Let r : A×B and s : A×B , then r ∩ s (the intersection of r and s) is defined by: r ∩ s : A×B

and

r ∩ s = {ha, bi| a r b and a s b}

union

intersection

(3.29)

The complement operator is also known from set theory. We define it by: • Let r : A×B , then r (the complement of r) is defined by: r : A×B

and

r = {ha, bi| not(a r b)}

complement

(3.30)

So if a tuple ha, bi is in relation r, then ha, bi is not in relation r and vice versa. The pronunciation of r is “all pairs not in r”. The relation V[A,B] represents the universal relation, which means that it contains every conceivable pair ha, bi, provided a ∈ A and b ∈ B. • V[A,B] (the universal relation over A and B) is defined by: V[A,B] : A×B

and V[A,B] = {ha, bi| a ∈ A and b ∈ B}

universal relation

(3.31)

By convention, if [A, B] is evident from the context or irrelevant for the point to be made, we write V instead of V[A,B] . Take care, however! In cases where V is compared to V, it may not be clear whether V = V. In any situation with a risk of ambiguity, V[A,B] should be written in full to expose the difference with for instance V[B,C] . So there are as many universal relations as there are [A, B] pairs in a given context. Notice that V represents the empty relation. Here too, one empty relation is not necessarily the same as another: V[A,B] is not the same as V[B,C] . Besides the set operators ∪, , and V, a relation algebra must contain the following three relational operators: ` (conversion), ; (composition), and I (identity relation). That is a minimum requirement for claiming the title of relation algebra. These operators are standard in relation algebras, although their notations may vary across different publications and different relation algebras. The conversion operator is denoted by ` and is pronounced as ‘flip’. Conversion merely swaps the left hand side and the right hand side:

empty relation

36

CHAPTER 3. RULES, RELATIONS AND CONCEPTS • Let r : A×B , then r` (the conversion of r) is a relation, which is defined by: r` : B ×A

and

r` = {hb, ai| a r b}

(3.32)

The conversion of a relation swaps the left column and the right column in the tabular form. It mirrors the matrix form of a relation along its diagonal. Let us look at some examples, based on provided (relation 3.14 on page 32), paid (relation 3.1 on page 31), and the relation f or[Invoice,Delivery] , which is defined by: for for

: Invoice × Delivery = {h721i, Cookies #0382i , h5362a, Jelly beans #4921i , h9443a, Peanut butter #1993i}

(3.33)

The conversion of for is: for ` for `

: Delivery × Invoice = {hCookies #0382, 721ii , hJelly beans #4921, 5362ai , hPeanut butter #1993, 9443ai}

(3.34)

The composition operator is denoted by a semicolon (;). It is pronounced as ‘composed with’. Composition turns two relations into one. Here is the definition: composition

• Let r : A×B and s : B ×C , then r; s (the composition of r with s) is a relation, which is defined by: (r; s) : A × C r; s = {ha, ci| there exists b such that a r b and b s c}

(3.35)

Figure 3.3 illustrates this definition. The left part of this figure shows paid . The right part shows for . Each invoice that connects a client with a delivery causes that client and delivery to be en element of the composition. So if c paid i and i for d implies that hc, di ∈ paid ; for Based on the contents of paid (3.1) and for (3.33), the composition of paid and for is obtained by applying definition 3.35. paid ; for paid ; for

: Client × Delivery = {hBrown, Cookies #0382i , hApplegate, Jelly beans #4921i, hConway, Peanut butter #1993i }

(3.36)

So paid ; for represents a relation that connects those clients to deliveries for which there is an invoice that connects both. If (different example) name :

conve

3.4. OPERATORS

37

Figure 3.3: relations paid and for String×Person defines which names belong to which person, and age : Person×Int defines the age of each person, then name; age is a relation that contains names and corresponding ages. If you are familiar with relational databases, you might like to know that composition corresponds to the natural join operator. You cannot compose just any relation. The relation provided ; for is not defined, because definition 3.35 requires the target of provided to be the same as the source of for . Delivery, being the target of provided , is clearly not the same as Invoice, which is the source of for . Nevertheless, composing provided with for ` is defined, and the result can be obtained by applying definition 3.35: provided ; for ` provided ; for `

: Provider × Invoice = {hCandy’s candy, 721ii, hCarter, 5362ai , hCarter, 9443ai }

(3.37)

An identity relation IA is implicitly defined for every concept A. which means that it contains every conceivable pair ha, ai, provided a ∈ A. • IA (the identity relation over A) is defined by: IA : A × A

and

IA = {ha, ai| a ∈ A}

identity relation

(3.38)

By convention, if [A] is evident from the context or irrelevant for the point to be made, we write I instead of IA . Take care, however! In cases where I is compared to I, it may not be clear whether I = I. In any situation with a risk of ambiguity, IA should be written in full to expose the difference with for instance IB . So there are as many identity relations as there are concepts in a given context.

38


In practice, IA stands for equality between elements of A. Only if a and b are equal, then a I b is true. The complement of identity, I is known as diversity relation. Related to composition is the relative addition (†). relative addition

• Let r : A×B and s : B ×C , then r † s (the relative addition of r with s) is a relation, which is defined by: (r † s) : A × C r † s = {ha, ci| for all b, a r b or b s c}

(3.39)

Relative addition is often used in combination with the complement operator. Therefore, † is best explained using the following equation, which is equivalent to definition 3.39: r † s = {ha, ci| for all b, a r b implies b s c}

(3.40)

In order to gain some understanding, let us consider an example in which students go on a study tour. The school offers three different tours, but the requirements for each study tour differ. Figure 3.4 shows two relations. On the left side a relation tour is given between destinations and subjects. It is declared as tour :Destination×Subject and says which subjects are mandatory for which study tour. On the right we have a relation between subjects and students, which we call passed :Subject×Student. It says which subjects have been completed successfully by which students. In order to qualify for a tour,

Figure 3.4: relations tour and passed a student must have passed all subjects that are required for that particular tour. It may be obvious that student Conway qualifies for the study tour to Hawaii, because he has completed the subject Surfing successfully. For the trip to Rome, students need two subjects. Student Brown has completed all three

diversity re

3.4. OPERATORS

39

subjects, so she qualifies for Rome. In fact, the set of subjects needed to go to Rome is included in the set of subjects completed by student Brown. That is precisely what definition 3.39 says. Student Applegate is less fortunate. She cannot go to Rome, because she has missed out on Latin. The set of subjects required for Rome is not included in the set of subjects passed by Applegate. Luckily, all students qualify for the Amsterdam study tour, irrespective of their achievements in class. Based on the contents of tour and passed (as shown in figure 3.4), the relative addition tour † passed is obtained by applying definition 3.39. tour † passed tour † passed

: Destination × Student = {hHawaii, Browni , hHawaii, Conwayi , hAmsterdam, Applegatei, hAmsterdam, Browni , hAmsterdam, Conwayi , hRome, Browni }

(3.41)

In order to decide whether to use composition (;) or relative addition (†), the rule of thumb is to look at the concept in between. That would be Subject in figure 3.4 and Invoice in figure 3.3. If the expression is about one instance in the middle only, as in “there exists an invoice”, then you need to look at composition. If the expression is about all instances of the concept in between, as in “all subjects that need to be completed”, then relative addition is the operator to consider.

Exercises 1

Consider the relation paid (3.1 on page 31) and compare this with the following relation sent: sent sent

: Invoice × Client = {h5362a, Applegatei, h721i, Browni , h8993a, Browni }

Compute the contents of sent ` and compare this with the contents of paid . Identify the differences and discuss whether you feel that any of those differences are unexpected. 2

Consider the relation sent with the following contents: sent sent

: Invoice × Client = {h5362a, Applegatei, h721i, Browni , h5362a, Browni }

Compute sent ` ; sent.

40


3.5

Rules

After an introduction to relations (section 3.3) and the introduction to relarule tional operators (section 3.4), let us turn to rules. A rule is a relation algebra

expression that remains true at all times. What that means is elaborated in this section, based on the example of figure 3.2. In that situation, clients and providers are trading according to a simple pattern of orders, deliveries and invoices. The figure proper does not contain any rules; it is merely a picture in which ten different relations are represented by their declarations. This section proposes rules represented in a relation algebra. The presentation emphasizes your line of reasoning, taking you from informal text to precise formulas. We have tried to present the matter so that you can learn how to write rules of your own, by carefully studying and reproducing the examples in this section. A first example: consider relations accepted and issued from figure 3.2. If pair hp, oi exists in relation accepted , which we denote as p accepted o, this means that provider p has accepted order o. Similarly, pairs ho, pi contained in relation issued represent orders that have been issued to a provider. Now suppose there is a business rule saying that a provider does not accept any order issued to someone other than himself. How we represent that? implication For that purpose, we introduce the operator `, which is called implication or

inclusion. • Let r : A×B and s : A×B , then r ` s (the implication of r with s) is a relation, which is defined by: (r ` s) : A × B r ` s = {ha, bi| a r b implies a s b}

(3.42)

Now let us return to our example, to see what it does. The rule states that providers shall not accept all orders; they are supposed to accept only those orders that were issued to them. If a pair hp, oi is in the relation accepted , then it is also a pair in issued ` . In other words, p accepted o implies p issued ` o. We can write this rule as: accepted ` issued `

(3.43)

Notice that the set of orders that have been accepted by a provider must always be a subset of the orders that were issued to him. In fact the operator ` is closely related to the subset operator ⊆: r`s=V ⇔ r⊆s

(3.44)

If a rule r ` s is to be kept true at all times, we are saying that we want r ` s to be equal to V at all times. By stating that equation 3.43 is a law, meaning

3.5. RULES

41

that accepted ` issued ` is to be kept true (i.e. equal to V) at all times, we have effectively formalized our business rule. So here you have a first example of a rule that represents business knowledge. Let us reflect for a moment on what we have done. Technically, equation 3.43 is just an expression with relations in it. Depending on the contents of accepted and issued , this expression can be either true or false. By stating that this is a rule, you declare that you want this expression to be true all the time. So a rule is a statement about the real world, whose truth we choose to maintain. Consequently, a tuple that makes the rule false is said to violate the rule. Inserting a tuple in a relation that makes the rule false causes a violation. In other parts of this book, you can learn how to use computers for signalling violations and maintaining the truth of a rule. Turning back to the example, rule 3.43 can be violated by a pair hp, oi in the relation accepted that is absent in issued ` . This single pair in accepted that is not in issued ` already constitutes a violation. For any rule you write down, you can try to invent violations to assert that these are examples of things you do not want. Exercise 3.3 is something you can do with every rule you propose. A solution is presented by way of example. Exercise 3.3. Give an example of contents of accepted and issued that violates rule 3.43. Show formally why your example violates this rule. Also, argue informally why this is a violation.

Solution accepted issued

= {hCandy’s candy, order#49i} = V

motivation (argued both formally and informally): • Formally, rule 3.43 says that accepted must be included in issued . This is clearly not the case; {hCandy’s candy, order#49i} is definitely not included in the empty relation V. So, this contents violates rule 3.43. The pair hCandy’s candy, order#49i constitutes a violation because it is in accepted and not in issued . • Informally speaking, this situation represents a situation in which Candy’s candy has accepted an order that was never issued to them. That is a clear violation of the business rule that a provider only accepts an order if it is issued to himself. Having successfully represented a first rule, let us try another one. How can we state that no client should ever pay an invoice that was not addressed to him? First, we establish that this rule involves the relations sent and paid . Then we

rule violation

42


reformulate the rule, stating that invoices paid by a client can be only those invoices that are sent to that client. In other words, every pair hc, ii in the relation paid is also a pair in sent ` . This is represented by: paid ` sent `

(3.45)

This rule is quite similar to rule 3.43, because the reasoning that leads to this rule is quite similar. Note that any invoice paid by a client but not sent to that client constitutes a violation of rule 3.45. Any invoice sent to one client but paid by another client also constitutes a violation. However, an invoice that was sent but not paid does not yield a violation. This is precisely what we want, because the invoice might be still in the mail or waiting on a desk. Exercise 3.4. Give an example of contents of paid and sent that violates rule 3.45. Show formally why your example violates this rule. Also, argue informally why this is a violation. Let us see if other rules can be identified. How can we describe that no delivery is provided without an order? First, let us establish that this rule involves the relations provided , accepted , and of . The relation provided states which provider has provided which delivery. Relation accepted says which provider has accepted which order, and of relates a delivery to an order. If a pair hp, di is in the relation provided , then it must also be a pair in the relation accepted ; of ` that says that there is an order, which was accepted by the provider and upon which the delivery was made. This rule is written as: provided ` accepted ; of `

(3.46)

Let us verify that this is exactly the rule we want. The second part of this rule, accepted ; of ` , represents the relation that contains pairs hp, di of Provider × Delivery for which there exist o ∈ Order such that p accepted o and o (of ` ) d. You may verify this by checking on definition 3.35. Note that o (of ` ) d is equivalent to d of o (by definition 3.32). So, this third rule represents precisely what we intended. Note that a violation of rule 3.46 occurs every time a delivery is made without an order. Exercise 3.5. Give an example of contents of accepted , of and provided that violates rule 3.46. Show formally why your example violates this rule. Also, argue informally why this is a violation. The client, of course, will not accept invoices for orders undelivered. Can we represent that in a fourth rule? Apparently, this involves the relations sent, for , and deliveredto. Relation sent tells us which invoice was sent to which client; relation for tells us for which delivery the invoice was made; and relation deliveredto specifies which delivery was delivered to which client. If there is

3.5. RULES

43

an invoice for delivery d, which was sent to client c, then hd, ci must be in deliveredto. Therefore, we can write: for ` ; sent ` deliveredto

(3.47)

This rule is useful to expose violations just like the previous ones. If an invoice is sent to a client different from the one who received the delivery, we have a violation. If an invoice is about a delivery that was never delivered, that too constitutes a violation. If there is no invoice, there is no violation of this particular rule. It might still be in the mail, after all. Exercise 3.6. Give an example of contents of for , deliveredto and sent that violates rule 3.47. Show formally why your example violates this rule. Also, argue informally why this is a violation. After discussing four rules, let us look back at figure 3.2. You may have noticed that every time we discussed a rule, the relations involved in that rule form a cycle in figure 3.2. This is no coincidence. Each rule has a relation in the left hand side and a relation on the right hand side. These two relations form two different paths in figure 3.2 between the same concepts. Hence, the relations involved form a cycle, which encloses an area in figure 3.2. By turning this principle around, we can chase cycles to discover new rules. For instance, let us investigate the relations f rom[Invoice,P rovider] , for , and provided . These three relations form a cycle in figure 3.2, which has not been covered by any of the previous rules. Can we propose a rule, using these three relations? If there is an invoice for delivery d that comes from provider p, then hp, di must be in provided . One part of this rule, which says whether there is an invoice for delivery d that comes from provider p, is represented by from ` ; for (by definition 3.35). In relational terms, we are saying that any pair hp, di that is in from ` ; for is also in provided . However, the other way around is also useful: for any pair hp, di that is in provided there must be an invoice for delivery d that comes from provider p. The rule works in two directions: the relations provided and from ` ; for are both included in each other. Using property 3.4, we get: provided = from ` ; for

(3.48)

Reflecting on this result, you may have noticed that this rule was discovered merely by following the procedure of inspecting relations in a cycle. There was no flash of ingenuity, no spectacular discovery involved. Also notice that equation 3.48 can be used to define the relation provided . If relations from and for are known, the contents of provided can be computed from their contents. Exercise 3.7. Give an example of contents of from, for and provided that violates rule 3.48. Show formally why your example violates this rule. Also, argue informally why this is a violation.

cycle chasing

44


You might wonder how to represent the rule that all deliveries on an invoice are provided by the sender of that invoice. This rule is clearly different from rule 3.48, but uses the same cycle. Rephrasing this rule yields: If an invoice comes from a provider, all deliveries on that invoice are provided by that provider and vice versa. As this rule is about an invoice from a provider, figure 3.2 gives two paths. One path is directly over from and the other path consists of relations for and provided . The statement is about all deliveries instead of a delivery. Therefore we look at † rather than ; to link for and provided together. The expression for † provided represents every invoice-provider pair hi, pi for which all deliveries d are provided by p or invoice i is not for d (i for d). So this rule yields: from = for † provided

(3.49)

Each of the previous rules 3.43 through 3.47 might have been discovered in a similar way, systematically inspecting the cycles in figure 3.2. In fact, most areas in figure 3.2 are enclosed by the cycles discussed so far. Only the area enclosed by relations f rom[Order,Client] , of and deliveredto remains to be analyzed. So these three relations are a candidate for a rule. By similar reasoning as in the previous rule, our proposal will be: deliveredto = of ; from

(3.50)

This rule says: if a pair hd, ci is in deliveredto, there must be an order for delivery d that comes from client c. Reversely, if there is an order for delivery d that comes from client c, hd, ci must be in deliveredto. So this rule too is a proper candidate for agreement among stakeholders in the business. After studying the rules presented so far, you will have acquired the idea of inventing rules by chasing cycles. This skill is fundamental in your analysis of rule proposals of various stakeholders and making your own proposals concrete.

3.6

Derivations

Let us pursue the following idea: if larger cycles are made up from smaller ones, and if cycles correspond to rules, can we use that to create new rules? The answer is yes, but why take the trouble? After all, if we can derive a new rule from existing ones, the new rule is not something that stakeholders should have to approve. If stakeholders have approved the existing rules, the newly assembled rule is merely a consequence of their own choosing. So derivations are useful to discuss and confront consequences of chosen rules. derivation In this section we show how a derivation works. You can learn to do derivations

by yourself by carefully tracing derivations in this book, making exercises, and

3.6. DERIVATIONS

45

Figure 3.5: conceptual model of trading

by trying. So let us see how it works. Let us take two rules that correspond to adjacent areas and combine them to form a new rule. For example, the cycles that correspond to rules 3.47 and 3.50, drawn again in figure 3.5, form adjacent areas. The relation deliveredto is shared between them. This observation inspires the following derivation: for ` ; sent `

{rule 3.47} deliveredto {rule 3.50}

= of ; from

As a result, we may conclude: for ` ; sent ` of ; from

(3.51)

This result says: if there is an invoice for a delivery, which has been sent to some client c, then there is an order for that delivery, which has come from client c. So the idea has worked: adjacent areas in a conceptual diagram may inspire new rules. The new rule 3.51 is a logical consequence of the existing rules 3.47 and 3.50. In a similar fashion we can explore other parts of 3.2, and do some more rea-

46


soning with rules: from ` ; for {rule 3.48}

= provided `

{rule 3.46} accepted ; of `

`

{rule 3.43} issued ` ; of `

This derivation says: if there is an invoice for a delivery, that came from some provider p, then there is an order for that delivery, which was issued to provider p. Or, in relational terms: from ` ; for ` issued ` ; of `

3.7

(3.52)

Multiplicities

On many occasions, relations are qualified in terms of phrases like ”one-tomany”, ”surjective”, ”1..n”, and the like. Such properties are called multiplicmultiplicity ities, because they provide bits of information about the number of items in a relation. Multiplicities occur in a majority of all relations. For example, the relation paid (3.1) might not allow any combination of clients and invoices. The requirement that each invoice is sent to one customer only yields a many-toone relation. To be precise: for every invoice mentioned in the relation paid , there is precisely one client. Stated in human language: every invoice carries the information of exactly one client. Multiplicities occur so often, that each of them has been given a name of their own: univalent, total, functional, injective, surjective and bijective. In this section we will give their definitions. For now, it is sufficient to know that multiplicities can be expressed as rules, just like any other rule. Later on in this book, we will calculate with rules, using these multiplicity definitions frequently. • univalent A relation r : A×B is univalent if each instance of A corresponds to at most one instance of B. This property is defined by: r` ; r ` IB

(3.53)

The definition says that a r b and a r b0 imply b = b0 for all a, b, and b0 .

3.7. MULTIPLICITIES

47

• total A relation r : A×B is total if each instance of A corresponds to at least one instance of B. This property is defined by: IA ` r; r`

(3.54)

The definition says that for all a ∈ A there exists b ∈ B such that a r b. To denote that relation r is total, we write total (r). • function A relation is a function if it is both univalent and total. That is: a relation r : A×B is functional if every instance of A corresponds to precisely one instance of B. A functional relation is also called a function If r is univalent but not total then it is called a partial function. • injective A relation r : A×B is injective if each instance of B corresponds to at most one instance of A. This property is defined by: r; r` ` IA

(3.55)

The definition says that b r a and b r a0 imply a = a0 for all a, a0 , and b. Notice that the property injective is defined conversely to the property univalent. • surjective A relation r : A×B is surjective if each instance of B corresponds to at least one instance of A. This property is defined by: IB ` r` ; r

(3.56)

The definition says that for all b ∈ B there exists a ∈ A such that a r b. Notice that the property surjective is defined conversely to the property total. • bijective A relation is bijective if it is univalent, total, injective and surjective. That is: every instance of A corresponds to precisely one instance of B and every instance of B corresponds to precisely one instance of A. Notice that a bijective relation is a function, because it is univalent and total.

In our example we can restrict the relations with these properties. We propose

partial

48


the following:

paid sent deliveredto for from from provided of accepted issued

: : : : : : : : : :

Client × Invoice Invoice × Client Delivery × Client Invoice × Delivery Order × Client Invoice × Provider Provider × Delivery Delivery × Order Provider × Order Order × Provider

uni

tot

inj √

sur √

√ √

√

√

√ √

√ √ √ √ √

√ √

√

√ √ √

√

√

√

The relation paid is made both injective and surjective, as discussed. Since each invoice is sent to precisely one client, the relation sent is required to be a function, i.e. both univalent and total. The same goes for deliveredto, because each delivery is made to one client exactly. The relation for is made injective and surjective only, because although we want one delivery to be mentioned on precisely one invoice, we allow that one invoice is sent for multiple deliveries. Besides, we insist on having an invoice for each delivery. Both relations from are functions, and so is issued , for similar reasons. The relation provided is injective and surjective, because a delivery comes from one provider. This implies that a complex delivery that comes from different providers is treated as a number of smaller deliveries, even though they arrive during the same ride. The relation of is restricted such that for every delivery there is an order and for every order there is a delivery. This leaves room for orders that combine multiple deliveries, although every delivery comes from one order only. The relation accepted is restricted to the case that an order is accepted by precisely one provider.

Database designers are familiar with multiplicities, because these properties have significant impact on implementation choices. Figure 3.6 shows two popular ways in which multiplicities are shown in database models. The left hand side shows the convention in the Universal Modelling Language (UML) [30]. On the right, you can see the ”crow’s foot” notation, which has become popular in entity relationship modelling (e.g. James Martin). Multiplicity notations may differ from one graphical modelling technique to another. In some graphical modeling techniques it may not be clear which side of a relation is source and which is target. In those techniques, you may want to write the name of a relation near its target, so you can easily remember the source and target of that relation. In conceptual diagrams (e.g. in figure 3.2) the little arrowhead gives direction to every relation.

3.8. FUNCTIONS

49

Figure 3.6: Graphical notations of multiplicities

Exercises 8

Consider relation for (from example 3.33): for for

: Invoice × Delivery = {h721i, Cookies #0382i , h5362a, Jelly beans #4921i , h9443a, Peanut butter #1993i}

If this relation is required to be injective, is any of the three pairs in conflict with that requirement? What if the requirement is that for be univalent? Please explain your answer. 9

3.8

Based only on the information provided in exercise 3.8, can you tell whether for satisfies the requirement for being total?

Functions

Functions are relations that are total and univalent. This allows for a convenient notation, which makes functions special. If r : A×B is a function, we write r : A→B . We will normally use the symbols f , g, h instead of relational symbols, and the notation b = f (a) instead of a f b. In a conceptual diagram

50


Figure 3.7: multiplicities in conceptual diagrams functions are depicted by an arrow (f in figure 3.7). Every other relation is depicted with the little arrowhead (r in figure 3.7). For example, we may rewrite the relation provided (see 3.14 on page 32) as a function provider : Delivery→Provider in the following way: provider (Cookies #0382) provider (Jelly beans #4921) provider (Peanut butter #1993)

= Candy’s candy = Carter = Carter

(3.57)

Notice the difference. In example 3.14, we defined a relation with no restrictions. In example 3.57 we require provided to be a function, i.e. both univalent and total. This restriction means that each delivery has precisely one provider. Notice that both examples, provided (3.14) and provider (3.57), have the same content, i.e. a provided b ⇔ b = provider (a). Throughout this book, relations that are both univalent and total (i.e. functions) are written in the functional notation, whereas other relations are denoted in the relational notation (3.11).

3.9

Homogeneous relations

Relations with identical source and target are special. Well known examples are = and ADL Delivery1 ADL vs. 0.7.9 (experimental) Arguments: Delivery1 Switches: Delivery1.adl is read. Delivery1.adl has been parsed. Concepts: Client Invoice Delivery Order Provider No type errors or cyclic specializations were found. Generating Atlas for Delivery in the current directory. ... HTML code for HTML code for HTML code for HTML code for HTML code for Done. C:>index.html

REL_Delivery_fromInvoiceProvider.html written REL_Delivery_providedDeliveryProvider.html written REL_Delivery_ofDeliveryOrder.html written REL_Delivery_acceptedProviderOrder.html written REL_Delivery_issuedOrderProvider.html written

The command index.html calls your browser and displays the result. Actually, index.html is the main file of a website which has been generated inside your current working directory. If you take it out to move it elsewhere, make sure you take all .html, .gif, .png, and .map files. Do not forget the directory treemenutils, which is also part of the website. Together, all these files constitute a piece of documentation generated by ADL.exe5 We advise Windows users to enlarge the command line window. Right click on the top bar of this window. Choose Properties to enlarge the number of lines to the maximum, which is 9999 lines. (The standard size is too small for the amount of error messages.) 5 .dot files generated by ADL.exe are intermediate files. They may be deleted without consequences.

5.3. YOUR FIRST ADL SCRIPT

5.2.3

81

Using ADL

Once you have executed the test run successfully, you use the same procedure for analyzing your business rules: 1.

Edit your .adl file, using your favourite editor

2.

Compile it in a command line window, using the ADL command

3.

Show the results in your browser, by displaying index.html

Exercise 5.1. Define a relation r::A*B [UNI]. and a relation s::B*C. Also, define a rule containing r;s. Compile and show that the result contains ’there exists a B called b’. Then, add the multiplicity TOT to the definition of r and observe the ’exists’ disappears. The following sections introduce you to ADL in a step-by-step fashion, introducing features on the way. You may want to run each example to see what ADL does on your computer.

5.3

Your first ADL script

Some computer programmers check whether a computer language works by writing a program that only prints the phrase ”Hello World!”. Since little can go wrong, it proves that you have succeeded in installing the language and using the compiler. Your ’hello world!’ consists of a single relation hello : Person×City. This is what it looks like in ADL: CONTEXT Test PATTERN Test hello :: Person * City. ENDPATTERN ENDCONTEXT An ADL file consists of a context which contains any number of patterns. You are required to give that context a name. In this example the context Test contains one pattern only, which is also named Test. The relation hello is declared in that context, your way of letting your computer know this relation exists. Please pay attention to the dot at the end of a declaration. It is required and causes irritating syntax errors if you forget. The following example is slightly more elaborate. It includes three pairs to populate the relation.

Attention!

82

CHAPTER 5. ADL MANUAL

CONTEXT Test PATTERN Test hello :: Person * City = [ ("John", "Oklahoma City") ; ("Jill", "Newcastle under Lyme") ; ("Jack", "Perth") ]. ENDPATTERN ENDCONTEXT Providing a few examples each time you declare a relation makes your code much more accessible to others. It is a good habit to do so. Your examples effectively help others to imagine your concepts. You can also specify the meaning of your relation in natural language. hello :: Person * City PRAGMA "Person " " says hello to " " on the radio" = [ ("John", "Oklahoma City") ; ("Jill", "Newcastle under Lyme") ; ("Jack", "Perth") ]. By supplying the pragma, you define the meaning of a relation in the real world. This particular example represents three facts: . Person ‘John’ says hello to ‘Oklahoma City’ on the radio. . Person ‘Jill’ says hello to ‘Newcastle under Lyme’ on the radio. . Person ‘Jack’ says hello to ‘Perth’ on the radio. The PRAGMA annotation is required to specify what you mean by a relation. Even though ADL uses this only in documentation, the pragma is of paramount importance to link your relations to your real world. We advise you never to forget the pragma, except when talking about relations in an abstract manner (uncoupled from the real world). Multiplicity restrictions can be added right after the type, and before the pragma (if present): hello :: Person * City [UNI,SUR] PRAGMA "Person " " says hello to " " on the radio" = [ ("John", "Oklahoma City") ; ("Jill", "Newcastle under Lyme") ; ("Jack", "Perth") ].

5.4. EXAMPLE: DELIVERY

83

The available restrictions are UNI, TOT, SUR, INJ, TRN, RFX, SYM and ASY. The last four of these are available for homogeneous relations only. Notice that the symbols used in ADL resembles the mathematics used in chapter 3, but they are restricted to the ASCII alphabet. ADL :: *

5.4

relation algebra : ×

Example: Delivery

The delivery example of chapter 3 (figure 3.2 on page 33) is basically represented by: CONTEXT Delivery PATTERN Deliveries paid :: Client * Invoice. sent :: Invoice * Client. deliveredTo :: Delivery * Client. for :: Invoice * Delivery. from :: Order * Client. from :: Invoice * Provider. provided :: Delivery * Provider. of :: Delivery * Order. accepted :: Provider * Order. issued :: Order * Provider. ENDPATTERN ENDCONTEXT However, if you study the surrounding text carefully, these declarations carry pragmatics and there are numerous examples. This yields: CONTEXT Trading PATTERN Deliveries paid :: Client * Invoice PRAGMA "Client " " has paid invoice " = [ ("Applegate", "5362a");("Brown", "721i") ; ("Conway", "9443a") ]. sent :: Invoice * Client PRAGMA "Invoice " " was paid by ". deliveredto :: Delivery * Client. for :: Invoice * Delivery PRAGMA "Invoice " " covers delivery " = [ ("721i", "Cookies #0382")

84


; ("5362a", "Jelly beans #4921") ; ("9443a", "Peanut butter #1993") ]. from :: Order * Client. from :: Invoice * Provider. provided :: Provider * Delivery PRAGMA "Provider " " has delivered delivery " = [ ("Candy’s candy", "Cookies #0382") ; ("Carter", "Jelly beans #4921") ; ("Carter", "Peanut butter #1993") ]. of :: Delivery * Order. accepted :: Provider * Order PRAGMA "Provider " " has accepted order ". issued :: Order * Provider PRAGMA "Order " " was issued to provider ". ENDPATTERN ENDCONTEXT For representing rules, we use the following ADL notations ADL r\/s r/\s -r V r;s r~ I r!s r|-s r=s

prio 2 3 6 5 6 4 1 0

relation algebra r∪s r∩s r V r; s r` I r†s r`s r≡s

meaning union of r and s intersection of r and s complement of r full relation composition of r and s converse of r identity relation relational addition of r and s r is included in s r equals s

Using these symbols, the entire example from chapter 3 is represented as: CONTEXT Trading PATTERN Deliveries accepted :: Provider * Order PRAGMA "Provider " " has accepted order ". issued :: Order * Provider PRAGMA "Order " " was issued to provider ". accepted |- issued~ EXPLANATION "A provider does not accept an order issued to someone other than himself. (2.36)"

5.4. EXAMPLE: DELIVERY

85

paid :: Client * Invoice PRAGMA "Client " " has paid invoice " = [ ("Applegate", "5362a") ; ("Brown", "721i") ; ("Conway", "9443a") ]. sent :: Invoice * Client PRAGMA "Invoice " " was paid by ". paid |- sent~ EXPLANATION "No client should ever pay an invoice that was not addressed to him. (2.37)" provided :: Provider * Delivery PRAGMA "Provider " " has delivered delivery " = [ ("Candy’s candy", "Cookies #0382") ; ("Carter", "Jelly beans #4921") ; ("Carter", "Peanut butter #1993") ]. of :: Delivery * Order. provided |- accepted;of~ EXPLANATION "No delivery is provided without an order. (2.38)" deliveredto :: Delivery * Client. for :: Invoice * Delivery PRAGMA "Invoice " " covers delivery " = [ ("721i", "Cookies #0382") ; ("5362a", "Jelly beans #4921") ; ("9443a", "Peanut butter #1993") ]. for~;sent |- deliveredto EXPLANATION "A client accepts invoices for delivered orders only. (1.39)" from :: Order * Client. provided = from~;for EXPLANATION "Every delivery corresponds to an invoice from the provider of that delivery. (1.40)" from :: Invoice * Provider. deliveredto = of;from EXPLANATION "Every delivery to a customer must correspond to an order by that customer. (1.41)" ENDPATTERN ENDCONTEXT

86


5.5

When you make mistakes

ADL signals many kinds of mistakes, meant to help you create flawless specifications. You need to distinguish between three kinds of mistake • syntax errors • type errors • mistakes in calling the program ADL A syntax error is recognized by an excessive amount of question marks. Examples: ???????????????????????????????????????????????????????????? ?? Error : before ";" at line 12, column 8 of file "try.adl" ?? Expecting : symbol ) or (symbol , ...)* ?? Repaired by: inserting symbol symbol ) ???????????????????????????????????????????????????????????? A single mistake causes the compiler to stop. Find the location of the mistake in your file and study the error message carefully. The compiler tells what it would have expected you to write at that specific location. It also makes a suggestion for you to repair the mistake. These suggestions are helpful in some cases, but may be totally out of your way in other cases. After correcting your mistake, repeat this procedure until you have corrected all syntax errors. The second type of mistakes are type errors. The compiler looks for type errors only if there are no syntax errors in the file. You get all type errors at once, but no output is produced as long as type errors remain. There are several kinds of type error, each of which may have different causes. We discuss each type of type error individually. Every type error carries a number identifying the type of error made, which corresponds to the following list.

5.5.1

Error: Mismatch in rule

ADL requires that types to the left and the right of the |- or = symbols are compatible. If not, the following error message occurs: !Error of type 1 in line , file Mismatch in rule: :: does not match ::

5.5. WHEN YOU MAKE MISTAKES

87

Here is an example of this type of error: !Error of type 1 in line 29, file "myRules.adl" Mismatch in rule: sender;lineSender~ :: [(Message,Line)] does not match calls~;scope;type~ :: [(Method,Object)] This message says that the left hand side and right hand side of the rule do not match. ADL checks all possible allocations of types, both for the left- and right hand sides. Questions you may use for diagnosis: • Make a drawing (conceptual diagram) for this rule only. Are all relations in a cycle? • Are any relations missing to the left or the right of either the left hand side or right hand side of this rule? • Are the types you intended for either the left hand side or right hand side present in the error message? If your answers to these questions did not expose your problem, and studying your code, error message and your diagram have not yielded a solution, you might carry out the following experiment. Add a type to one of the relations in the erroneous rule. This limits the possibilities for ADL. You may start with one of the relations of which you are sure you know the type. For every type you add, run ADL immediately in order to study the effect on the error message. If this does not lead you to finding a solution, repeat this for the other relations in the rule.

5.5.2

Error: Ambiguous types

ADL requires all relations that are used in a rule are unambiguously determined. Since every relation is determined by its name, source and target, ADL reconstructs the sources and targets of all relations used in a rule. An ambiguous rule results in the following error message !Error of type 2 in line , file Ambiguous types: in right hand side: and left hand side: .

88


Here is an example of this type of error: !Error of type 2 in line 31, file "myRules.adl" Ambiguous types: [Component*Component] or [Comp*Comp] in right hand side: sees;sees and left hand side: sees. The left hand side and right hand side of a rule can be matched in more than one way. The error message gives all possibilities. If several possibilities remain, this is signalled as an ambiguity. ADL requires a unique match. Questions you may use for diagnosis: • Make a drawing (conceptual diagram) for this rule only. Did you choose names for relations that occur in other patterns as well? • Are names of relations sufficiently distinctive? • Might your rule be more understandable by adding a type to one of the relations used in this rule? Study the error message and compare it to your code and to your diagram for this particular rule. Your mistake can always be fixed by adding a type to the offending relation. However, sometimes it may be more appropriate to choose different names for different relations, thus resolving your ambiguity. If you add types to relations, this restricts the possibilities for ADL. For every type you add, run ADL immediately in order to study the effect on the error message. In this way, you can remove all ambiguity step by step.

5.5.3

Error: Relation not defined

All relations that are used in any rule must be defined. If not, ADL generates the following message. !Error of type 3 in line , file Relation is not defined. Here is an example of this type of error: !Error of type 3 in line 33, file "myRules.adl" Relation sendr is not defined.


89

Your code contains no defination of the relation mentioned in this message. Questions you may use for diagnosis: • Where did you define this relation? • Is the spelling correct (case sensitive!)? You must either correct (if misspelled) or define this relation.

5.5.4

Error: Incompatible comparison

In \/ or /\ expressions, types must be compatible. If not, ADL produces the following message: !Error of type 4 in line Incompatible types in

Here is an example of this type of error: !Error of type 4 in line 49, file "myRules.adl" Incompatible types in comparing lineReceiver~;method :: [(Object,Method)] with sees :: [Comp*Comp] or [Component*Comp] The types of the two expressions mentioned in this message are not compatible. The error message points out which expressions have caused the problem and gives their possible types. Questions you may use for diagnosis: • Make a drawing (conceptual diagram) for the two subexpressions mentioned in the error message. Are both expressions in a cycle? • Are relations missing in order to complete the cycle? • Are the types mentioned in the error message the ones you intended? If your answers to these questions did not expose your problem, and studying your code, error message and your diagram have not yielded a solution, you might carry out the following experiment. Add a type to one of the relations in the erroneous rule. This limits the possibilities for ADL. You may start with one of the relations of which you are sure you know the type. For every type you add, run ADL immediately in order to study the effect on the error message. If this does not lead you to finding a solution, repeat this for the other relations in the rule.

90


5.5.5

Error: Incompatible composition of relations

The combination operator (;), when used in an expression (e.g. r;s), requires that the target from its left argument (r) corresponds to the source of its right argument (s)

!Error of type 5 in line , file Type error in composing with Here is an example of this type of error:

!Error of type 5 in line 51, file "myRules.adl" Type error in composing lineSender[(Line,Object)] with method[(Line,Method)] Somewhere in the middle of an expression, you have used a combination operator (semicolon) where the relation left of it does not link to the relation on its right. The two concepts should be compatible. In the example, the concept Object is not compatible with Line. Questions you may use for diagnosis: • In which rule does this occur? Locate the relations in your code. Find the semicolon with the problem. • Are the relations in the error message the ones you intended (compare types)? • The problem may be cause by a missing (or superfluous) ~. Are they correct? Drawing the conceptual diagram helps. Check the direction of the relations carefully, and check whether your ~ operators are correct. You may experiment by adding types to the relations to the left and right of the semicolon. This limits the possibilities for ADL. You may start with one of the relations of which you are sure you know the type. For every type you add, run ADL immediately in order to study the effect on the error message. If this does not lead you to finding a solution, repeat this for the other relations in the rule.


5.5.6

91

Error: Ambiguous composition of relations

The combination operator (;), when used in an expression (e.g. r;s), requires that the target from its left argument (r) corresponds to the source of its right argument (s) in only one way6 . !Error of type 6 in line Ambiguous composition

Here is an example of this type of error: !Error of type 6 in line 49, file "myRules.adl" Ambiguous composition over concepts [Object,Method] of meth :: [Line*Object] or [Line*Method] and send~ :: [Object*Comp] or [Method*Comp] Somewhere in the middle of an expression, you have used a combination operator (semicolon) where the relation left of it can link to the relation on its right in a number of different ways. The list of concepts in the error message gives you the available options. That list is often the most helpful part of the error message There should be only one concept possible, over which combination takes place. In the example, the concept Object and Method would both do, so that constitutes a mistake. Questions you may use for diagnosis: • In which rule does this occur? Locate the relations in your code. Find the semicolon with the problem. • Are the relations in the error message the ones you intended (compare types)? • The problem may be cause by a missing (or superfluous) ~. Are they correct? Drawing the conceptual diagram helps. Check the direction of the relations carefully, and check whether your ~ operators are correct. You may experiment by adding types to the relations to the left and right of the semicolon. This limits the possibilities for ADL. You may start with one of the relations of which you are sure you know the type. For every type you add, run ADL immediately in order to study the effect on the error message. If this does not lead you to finding a solution, repeat this for the other relations in the rule. 6 The reason is: the compiler must be able to allocate precisely one relation to each argument of ;

92


5.5.7

Error: Properties

The properties transitive (TRN), reflexive (RFX), symmetric (SYM) and antisymmetric (ASY) are reserved for homogeneous relations. If you specify them for a heterogeneous relation, you get the following error message.

!Error of type 7 in line , file Heterogeneous relation may not be defined . (This relation is heterogeneous because and are different concepts). Here is an example of this type of error:

!Error of type 7 in line 56, file "myRules.adl" Heterogeneous relation calls[Component*Service] may not be defined transitive and reflexive. (This relation is heterogeneous because Component and Service are different concepts). A relation is homogeneous if its source and target are the same. Otherwise, the relation is called heterogeneous. For each occurrence of this error message, your file contains a relation with different source and target concepts, which is specified to be transitive, reflexive, symmetric or antisymmetric. Questions you may use for diagnosis: • Did you intend this relation to be heterogeneous? • If you meant it to be homogeneous, is there a spelling error in the type which might explain this message? • If you meant it to be heterogeneous, why did you specify TRN, RFX, SYM or ASY in the property list? If you meant the relation to be homogeneous, correct the type and make source and targets identical (case sensitive!) If you meant the relation to be heterogeneous, correct the property list and remove all occurrences of TRN, RFX, SYM and ASY. This concludes the list of possible type errors.

5.6. ADL SYNTAX

5.5.8

93

ADL errors

The last category of errors are caused by mistakes in calling the program ADL. ADL expects you to say in which file you have described your contexts. Please provide a filename (.adl) and a context name. Apparently, you have called the program ADL without specifying an argument. ADL expects the name of a .adl file (such as filename.adl). By the way, you may leave out the extension (.adl). Here are some examples of calling the program: C> ADL mymodels.adl C> ADL mymodels C> ADL mymodels Petrinet In your file you may specify more than one context. If you do so, ADL expects you to state the name of one context as the second argument. The example shows Petrinet in this position. Failure to do so or specifying a name that is not an available context yields the following error message: Please specify the name of a context. Available contexts: . The following example illustrates this message: Please specify the name of a context. Available contexts: Skillbased and DocMan. If you get such a message, your .adl file contains more than one context. ADL requires you to specify the context to be analyzed in the second argument on the command line. If you specified a second argument, check its spelling. All possible choices you have are given in this message.

5.6

ADL Syntax

This section describes the syntax of ADL for reference purposes only. ADL is a case sensitive language. There are two different types of comment: nested comments and line comments. A nested comment is any text between

94


comment brackets ({- and -}). Nested comments may be enclosed in other (larger) nested comments. A line comment is the character sequence following a double hyphen (--) until the next end of line. ADL ignores both types of comment. Tokens (also known as ’terminal symbols’) are identified from the input, and subsequently parsed by ADL. The language distinguishes between keywords, special symbols, strings and identifiers, all of which are considered tokens. ADL contains the following keywords: ASY EXPLANATION SUR

CONCEPT INJ SYM

CONTEXT PATTERN TOT

ENDCONTEXT PRAGMA TRN

ENDPATTERN RFX UNI

The following special symbols are used in ADL: |-

=

;

~

*

::

\/

/\

-

->

(

)

[

]

.

,

ADL has two types of identifiers: A C_identifier begins with a capital letter and an L_identifier begins with a lower case letter. A String is a sequence of characters enclosed by double quotes, with quotes themselves escaped by a backslash. The nonterminal symbols of ADL are enclosed in sharp brackets. The start symbol of ADL is . The metasyntax of the production rules reads (in ascending order of precedence): n ::= e . [ e ] n | m n ; m n+tok n+ n*tok n*

nonterminal n is defined by expression e optionally expression e either expression n or expression m expression n followed by expression m nonterminal n repeated once or more, separated by token tok nonterminal n repeated once or more any number of nonterminals n, separated by token tok any number of nonterminals n

The production rules of ADL are listed below.

::= "CONTEXT" ; C_identifier * "ENDCONTEXT" .

::= | | .

; ;

5.6. ADL SYNTAX

95

::= "PATTERN" ; ; * ; "ENDPATTERN" .

::= C_identifier | String .

::= | | . ::= ; "|-" ; ; [ "EXPLANATION" ; String ] | ; "=" ; ; [ "EXPLANATION" ; String ] | "ALWAYS" ; ; [ "EXPLANATION" ; String ] .

::= +"\/" .

::= +"/\" .

::= +";" .

::= ; "~" "-" ; ; "*" ; "+" "(" ; ; ")"

::= L_identifier ; [ "[" ; ; "*" ; ; "]" ] | L_identifier ; [ "[" ; ; "]" ] .

| | | | | .

::= "CONCEPT" ; ; String ; String . ::= L_identifier ; "::" ; ; "*" ; ; [ ] ; [ ] ; [ ] ; "." .

::= "=" ; "[" ; *";" ; "]" .

::= "[" ; *"," ; "]" .

::= "UNI" | "INJ" | "SUR" | "TOT" | "SYM" | "ASY" | "TRN" | "RFX" .

::= "PRAGMA" ; String ; String

|

96

CHAPTER 5. ADL MANUAL "PRAGMA" ; String ; String ; String .

::= "(" ; String ; "," ; String ; ")" .

Chapter 6

ADL This chapter defines the structure, the syntax and the semantics of ADL. As abbreviation, ADL stands for A Description Language. This specification can be used to define a repository in which to store rules in their contexts. This chapter defines ADL in a formal way. Any implementation that satisfies the properties defined in this chapter is a valid implementation of ADL. This chapter is built up as follows. The first section specifies the terminology of concepts, relations, rules, patterns and contexts informally. It is meant as an introduction to the language used to describe ADL. Section 6.2 specifies the terminology of concepts, relations, rules, valuations, and patterns formally, in a way that a rule repository can be built. Finally, section 6.3 specifies a family of languages that can be used to fill the repository. Any language and any repository that satisfies this specification is a proper implementation of ADL.

6.1

Terminology

This section starts with informal definitions of the words used in ADL. After that, all words are introduced formally, with explanations on the way. The following words are used Atom Concept Context

An object that cannot be divided in smaller parts. A collection of things of one kind. A concept corresponds to a set of atoms. A set of rules with power of law (within that context).

97

98

CHAPTER 6. ADL

Declaration

A statement saying that a relation exists by mentioning the name, source- and target concepts of that relation. (synonym: Relation definition, or Definition) Identifier A string that identifies a concept (if it starts with a capital letter) or a relation (if it starts with a lower case letter). Pair A combination of two atoms, one to the left and one to the right. Pattern A set of rules inside an architecture that represents a generic solution to a design problem. A pattern has a name and can be used within a context. Patterns can be inserted into or removed from an architecture. Relation A set R of pairs, where each pair p contains two atoms, s and t. Pair p represents a fact fact R (p). Atom s is an instance of a concept source(R) and t is an instance of a concept target(R). RelationRef part of a rule that denotes one relation in any context where this rule applies. Usually, the name alone is sufficient to identify the relation uniquely. In some cases it is necessary to write the full signature (i.e. the name together with source- and target concepts) to prevent ambiguity. Rule A statement in relation algebra that restricts the possible interpretations of relations used in the rule. Set A collection of atoms. Valuation An assignment of pairs to every relation reference in a relation. Every particular valuation makes a rule true or false within its context.

6.1.1

Concepts

Concepts are treated as sets. For example, you may think of the concept Person, as a set with elements Abraham, Bob, and Charlotte. All known properties of sets are valid for concepts as well. For instance, if a concept C has element Bob and C ⊆ C 0 , then Bob is an element of C 0 also. The statement Bob ∈ C is pronounced ”Bob is an element of C” and it means that there exists a C atom called Bob. Elements of concepts are called atom, indicating that these elements are the smallest things to consider. The collection of all conceivable atoms is sometimes called ‘universe of discourse’ in the literature. We talk about the type type of an atom as in Abraham, Bob, and Charlotte have type Person. The set population of atoms that corresponds to a concept is called the population of that concept. Since relations are (by definition) sets, a relation has elements too. For example, the pair (Bush, USA) might be an element of a relation president. Two pairs are equal if their left atoms are equal and their right atoms are equal. All pairs in

6.1. TERMINOLOGY

99

a relation have the same types. That is: the left atoms of all pairs in a relation have the same type, and so do the right atoms. The concept to the left is called source and the concept to the right is the target. Within a context, every relation is defined uniquely by its name and the source and target concepts. We write r[A,B] to denote the relation with name r, source A and target B, The type of r[A,B] is defined as [A × B]. We write [A × B] u [C × D] to denote the most specific of two types [A × B] and [C × D]. The notation [A × B] t [C × D] denotes the most generic of both types.

6.1.2

source target type

Rules

ADL uses the idea of patterns to collect a number of rules that describe one particular theme1 . So rules are defined within a pattern, which is therefore a collection of rules. When that pattern is used in a context, all rules defined in that pattern apply within the context. Within the context itself, extra rules may be defined for the purpose of glueing patterns together2 . So, all rules that apply in a context are the ones defined in patterns used by the context plus the rules defined within that context. The syntax of rules is given in Backus Naur Form (BNF): Rule ::= Expression "|-" Expression "." . Rule ::= RelationRef "=" Expression "." . You can read the first line as: a rule can be an expression followed by the |- symbol, followed by another expression and terminated by a dot (full stop symbol). An example of a rule is elem;subset |- elem, in which elem;subset is an expression and elem is an expression too. Similarly, you read the second line as: a rule can be a RelationRef followed by the = symbol, followed by an expression and terminated by a dot. The syntax of expressions is given by: Expression Expression Expression Expression Expression Expression Expression 1 Patterns 2 Glueing

::= ::= ::= ::= ::= ::= ::=

RelationRef . Expression "~" . "-" Expression . Expression ";" Expression . Expression "/\" Expression . Expression "\/" Expression . "(" Expression ")" .

are discussed in section 6.1.5 of patterns is discussed in ??

expression

100

CHAPTER 6. ADL

The unary operators ~ and - bind stronger than any other operator, so the expression r;s~ is different from (r;s)~. Of all three infix operators, ; binds the strongest, followed by /\ and finally \/. This means that r/\s;p is read r/\(s;p) and r/\s\/p is read (r/\s)\/p. A relation reference (RelationRef) is part of a rule that denotes one relation in any context where this rule applies. For instance, the rule elem;subset |- elem contains relation references elem and subset. The source- and target concepts type together are called the type. ADL requires that the type of every relation reference is determined, in order to bind that reference to one specific relation. As ADL can often deduce the type from the context, the name alone is often sufficient to identify a relation uniquely. To prevent ambiguities, you may write a relation reference in full, i.e. the name together with source- and target concepts as (for example) elem[Atom*Set]. Identifiers of a relation always start with a lower case letter (mIdent), but names that identify concepts always start with a capital letter (cIdent). ADL has one special relation: I, represents the identity relation. It is predefined in ADL for every concept. The syntax of relation references is given by: RelationRef RelationRef RelationRef RelationRef RelationRef

::= ::= ::= ::= ::=

mIdent . mIdent "[" cIdent "*" cIdent "]" . mIdent "[" cIdent "]" . "I" . "I" "[" cIdent "]" .

If you specify the type, as in president[Name*Country], you know for sure that this is the type used by ADL. If you specify only one concept, as in friend[Name], ADL interprets this as friend[Name*Name]. If you do not specify any concepts, ADL will try to find out which type you mean. Rules, expressions, and relation references have types. The type of r is denoted by T r. Types are defined as follows:

T m[A*B] T I[A] T r[A*B];s[B*C] T r[A*B]~ T r/\s T r\/s T r|-s T m=r T -r

= = = = = = = = =

[A × B] [A × A] [A × C] [B × A] Tr u Ts Tr u Ts Tr u Ts Tm u Tr Tr

current context You always work in one particular context, called the current context. Every

6.1. TERMINOLOGY

101

relation reference is bound to precisely one relation in your current context. Notice that the same relation reference may be bound to different relations in different contexts, because one rule (which is defined in a pattern) applies in all contexts that use this rule. If you work in a context (e.g. the context of Marlays bank) you may define a new context (e.g. Mortgages) as an extension of an existing context. This means that all rules that apply in the context ‘Marlays bank’ apply in the context ‘Mortgages’ as well. The rules that apply in the generic context (‘Marlays bank’) are a subset of the rules that apply in the specific context (‘Mortgages’).

6.1.3

Relations

Any relation is a set of pairs. For example: president = { ("Bush","USA"), ("Clinton","USA"), ("Sarkozy","France") } This defines the contents of a relation. The following statement is called a declaration. It introduces a new relation and states its type:

declaration

president :: Name * Country The concept on the left hand side is called the source and the right hand side concept is called target. The left atom of every pair in a relation r is an element of the source of r. Similarly every right atom in r is an element of the target concept. Within any context, the name, source and target determine a relation uniquely. A tuple in a relation matches the type of that relation. That is: the left atom of a tuple is atom of the source of the relation in which that tuple resides. Idem for the target. Any pair in relation r is also in relations of which r is a subrelation. The reason is that a relation is a set of pairs, so subsets are subrelations.

6.1.4

Valuations

Any rule is a statement that can be applied to many different atoms. For example, the rule:

source target

102

CHAPTER 6. ADL

president |- citizen . This rule says specifies that the relation president is included in the relation citizen. So it says that you can be a president only if you are a citizen. We can apply this rule to different atoms, to see whether it is true or not. For instance, let president = {("Bush","USA"), ("Clinton","USA"), ("Chirac","France")} citizen = {("Bush","USA"), ("Clinton","USA"), ("Chirac","France"), ("Joosten","Netherlands")} In this example, the rule is obviously true. For every value we choose, we get the expected true or false statement: e.g. "Bush" president "USA" implies that "Bush" citizen "USA". is clearly true. On the other hand: "Joosten" president "USA" implies that "Chirac" citizen "France". is clearly false. In order to discuss semantics of rules precisely, we introduce the notion of valuavaluation tion. A valuation is one particular assignment of atoms to a rule that makes the

rule true or false. For that purpuse, a valuation needs to allocate a value (i.e. a pair) to each relation reference in the rule. In the example we have two relation references (president and citizen), so a valuation gives values to each one. In the first example the following valuation was used: president -> ("Bush","USA"); citizen -> ("Bush","USA") The second example used a different valuation: president->("Joosten","USA"); citizen->("Chirac","France") For every valuation of rule r that contains a pair l, this pair is an element of a relation in each context in which r applies.

6.2. FORMAL SPECIFICATIONS

6.1.5

103

Patterns

Every relation used in a rule is defined in the same pattern as that rule. A relation is bound to its definition, which is written inside a pattern used in the relation’s context. Any relation in a context is also known in more generic contexts. The reason is that a relation is a set of pairs, so subsets are subrelations. A pattern used by a context is implicitly used by more specific contexts. If one relation is a subrelation of another one (the super-relation), it means that they have compatible types and the subrelation is in the same or a more specific context than the super-relation. In the following sections, formal specifications are elaborated that define ADL.

6.2

Formal Specifications

This section defines concepts, relations, rules, valuations, and patterns once again, but now formally.

6.2.1

Concepts

A concept is a collection of things of one kind. The symbol v is called the ‘isa’ relation3 when applied to concepts. For instance Judge v Person means that the concept Judge is more specific than the concept Person. The set of judges (corresponding to Judge) is included in the set of persons (which corresponds to Person). We write A u B to denote the most specific of two concepts A and B. The notation A t B denotes the most generic of both concepts. The relation v (isa) expresses that one concept may be more specific than another. v :: Concept × Concept

(6.1)

For instance: Teacher v Person means that Teacher is a more specific concept than Person. Just like ⊆, v is reflexive, transitive, and antisymmetric. The relation v applies to concepts, whereas ⊆ applies to sets. 3 This relation is familiar to object-oriented programmers and artificial intelligence professionals.

104

CHAPTER 6. ADL

The correspondence between concepts and sets is obtained by the function pop, which associates a set to every concept. pop :: Concept → Set

(6.2)

The relation v must satisfy the following property, for all concepts c and c0 : c v c0 ⇒ pop(c) ⊆ pop(c0 )

(6.3)

This property says for instance that Teacher v Person implies that the set of teachers (corresponding to Teacher) is included in the set of persons (which corresponds to Person). That is: every atom in the set of teachers is also a member of the set of persons. For any atom a that is element of a set that corresponds to a concept c, we say that a has type c. We use the following relation. type :: Atom × Concept

(6.4)

This relation is total, since every atom has a type. A type is a concept in whose population the atom occurs. It is defined by: ∀a :: Atom; c :: Concept :

a type c ⇔ a ∈ pop(c)

(6.5)

pair A combination of two atoms that occurs in a relation is called a pair. One atom left atom is called the left atom and the other one is the right atom. The functions left right atom and right yield the respective atoms.

left, right :: Pair → Atom

(6.6)

Each pair is fully determined by its left and right atoms. ∀l, l0 :: Pair : l = l0 ⇔ right(l) = right(l0 ) ∧ left(l) = left(l0 )

(6.7)

When two atoms are linked in a relation, a pair implicitly links two concepts. source The left concept is called the source and the right concept target. Functions src target and trg map a pair to either concept.

src, trg :: Pair → Concept

(6.8)

These functions are defined by: ∀l :: Pair : src(l) = type(left(l)) ∧ trg(l) = type(right(l))

(6.9)

Figure 6.1 illustrates the structure of the previously defined rules. This diagram shows an arrow for every function and a line for every relation. The tiny arrow halfway a line determines the order of arguments in each relation. The following fragment represents the specification in terms of ADL:


105

Figure 6.1: Structure of Concepts PATTERN Concepts elem :: Atom * Set. subset :: Set * Set [RFX,TRN,ASY]. isa :: Concept * Concept [RFX,TRN,ASY]. pop :: Concept * Set [UNI,TOT]. isa |- pop ; subset ; pop~. type :: Atom * Concept [TOT]. type = elem ; pop~. left :: Pair * Atom [UNI,TOT]. right :: Pair * Atom [UNI,TOT]. I[Pair] = right ; right~ /\ left ; left~. src :: Pair*Concept [UNI,TOT]. trg :: Pair*Concept [UNI,TOT]. left |- src ; pop ; elem~. right |- trg ; pop ; elem~. ENDPATTERN

6.2.2

Rules

Rules are the most prominent feature of ADL. They are defined in patterns and a pattern is used by any number of contexts. Which rule is defined in which pattern is represented by the function definedIn. definedIn :: Rule → Pattern

(6.10)

Which context uses which pattern is given by the relation uses: uses :: Context × Pattern

(6.11)

When a pattern is used in a context, all rules of that pattern apply within that context. So, we introduce a third relation, appliesIn, to express which rules apply in which context: appliesIn :: Rule × Context

(6.12)

106

CHAPTER 6. ADL

These relations satisfy equation 6.13, which states that for each rule r and every context c: r appliesIn c ⇔ c uses definedIn(r)

(6.13)

Within the context itself, extra rules may be defined for the purpose of glueing patterns together. So all rules that apply in a context are the ones defined in patterns used by the context plus the rules defined within that context. New contexts can be defined as extensions of existing contexts. This is represented by the relation specializes. specializes :: Context × Context

(6.14)

This relation is reflexive, transitive, and antisymmetric. If you work in a context (e.g. the context of Marlays bank) you may define a new context (e.g. Mortgages) as an extension of an existing context. This means that all rules that apply in the context Marlays apply in the context Mortgages as well. The rules that apply in the generic context (Marlays) are a subset of the rules that apply in the specific context (Mortgages). This property is defined for every rule r and all contexts c and c0 by equation 6.15. r appliesIn c0 ∧ c specializes c0 ⇒ r appliesIn c

(6.15)

Relations are defined in a context. This information is available by means of the function in: in :: Relation → Context

(6.16)

If, for example (‘Relation 1’, ‘RAP’) occurs in relation in, this means that relation ‘Relation 1’ is available in context ‘RAP’. relation reference A relation reference is part of a rule that denotes a relation in the context of

this rule. The relation in tells us which relation references are used in which rule. in :: RelationRef × Rule

(6.17)

This relation is surjective and total, since every relation reference is used in at least one rule and every rule contains at least one relation reference. The type of a relation reference is given by the function sign: sign :: RelationRef → Definition

(6.18)

Likewise, the type of a relation reference is given by another function sign: sign :: Relation → Declaration

(6.19)


107

This allows us to express in property 6.20 that every relation reference in a rule is bound to a relation in the applicable context. For every rule r, context c, and relation reference m m in r ∧ r appliesIn c ⇒ ∃r0 :: Relation : sign(m) = sign(r0 ) ∧ in(r0 ) = c

(6.20)

current You always work in one particular context, called the current context. Every

relation reference is bound to precisely one relation in the current context4 .

Figure 6.2: Structure of Rules The following fragment represents the specification in terms of ADL:

PATTERN Rules definedIn :: Rule -> Pattern. uses :: Context * Pattern. appliesIn :: Rule * Context. appliesIn = definedIn;uses~. specializes :: Context * Context [RFX,TRN,ASY]. appliesIn ; specializes~ |- appliesIn. sign :: RelationRef -> Declaration. in :: RelationRef * Rule [SUR,TOT]. sign :: Relation -> Declaration. in :: Relation -> Context. in ; appliesIn |- sign ; sign~ ; in. ENDPATTERN 4 TBD:

insert proof here

108

CHAPTER 6. ADL

6.2.3

Relations

Within any context, the name, source, and target determine a relation uniquely. All relations r and s satisfy property 6.21. r = s ⇔ sign(r) = sign(s) ∧ in(r) = in(s)

(6.21)

The definition of in and sign are given in section 6.16 (pg. 106). We introduce subrelation the notion of subrelation to express that any pair in a subrelation of r is also in

r itself. Since a relation is a set of pairs, this corresponds to the subset relation. For this purpose we introduce the relation sub. sub :: Relation × Relation

(6.22)

This relation is reflexive, transitive, and antisymmetric. It satisfies property 6.23 for every pair l and all relations r and s: l ∈ r ∧ r sub s ⇒ l ∈ s

(6.23)

Note that this property has the following consequence. For all relations s and r: s sub r ⇒ s ` r

(6.24)

Since a relation is a set, we use the notation l ∈ r to express that a pair l type is an element of relation r. Every relation has a type, being the source- and

target concepts of that relation. The following functions are used to retrieve the individual components of a declaration: source, target name

:: Declaration → Concept :: Declaration → Identifier

(6.25) (6.26)

A name, source and target identify a relation uniquely, which is expressed for all declarations s and s0 by equation 6.27: s = s0 ⇔ name(s)=name(s0 ) ∧ source(s)=source(s0 ) ∧ target(s)=target(s0 )

(6.27)

Every tuple in a relation must match the declaration of that relation. That is: the type of the left atom of a tuple must be compatible with the source of the relation in which that tuple resides. Idem for the target. This rule states that you cannot put just anything in a relation, but the types of atoms must respect the type of the relation. For every pair l and relation r property 6.28 must hold. l ∈ r ⇒ src(l) = source(sign(r)) ∧ trg(l) = target(sign(r))

(6.28)


109

Relations src and trg are discussed in section 6.8 (pg. 104). One declaration may be more generic than another, which is defined in the relation sub :: Declaration × Declaration

(6.29)

Like before, this relation is reflexive, transitive, and antisymmetric. If one relation s is a subrelation of another relation r, both must have compatible types and s must be in the same or a more specific context than r. This requirement is given by equation 6.30 s sub r ⇔ sign(s) sub sign(r) ∧ in(s) specializes in(r) The relations sign, in, and specializes are discussed in section 6.14. The structure of these rules is given in figure 6.3.

Figure 6.3: Structure of Relations The following fragment represents the specification in terms of ADL: PATTERN Relations source :: Declaration -> Concept. target :: Declaration -> Concept. in :: Pair * Relation. in ; sign |- src ; source~ /\ trg ; target~. I[Relation] = sign;sign~ /\ in;in~. sub :: Relation * Relation [RFX,TRN,ASY]. in ; sub |- in. name :: Declaration -> Identifier. I[Declaration] = name; name~ /\ source; source~ /\ target; target~. sub :: Declaration * Declaration [RFX,TRN,ASY]. sub = sign;sub;sign~ /\ in;specializes;in~. ENDPATTERN

(6.30)

110

CHAPTER 6. ADL

6.2.4

Valuations

In order to discuss semantics of rules precisely, we introduce the notion of valvaluation uation. A valuation is one particular assignment of atoms to a rule that makes

the rule true or false (see also section 6.1.4). For this purpuse, a valuation needs to allocate a value (i.e. a pair) to each relation reference in the rule. val :: RelationRef × Pair

(6.31)

All pairs in a valuation are registered in the relation in in :: Pair × Valuation

(6.32)

The following definition relates rules to valuations. val :: Rule × Valuation

(6.33)

For each rule r, pair l and relation reference m, these relations must satisfy property 6.34. m in r ∧ m val l ⇒ ∃v :: Valuation : r val v ∧ l in v

(6.34)

The definition of in[RelationRef ,Rule] is given in section 6.17 (pg. 106). For every valuation of rule r that contains a pair l, and every valuation v, l is an element of a relation in each context c in which r applies. l in v ∧ r val v ∧ r appliesIn c ⇒ ∃r0 :: Relation : l ∈ r0 ∧ in(r0 ) = c

(6.35)

The definition of appliesIn is given in section 6.12 (pg. 105) and in is discussed in section 6.16 (pg. 106). The structure of these definitions is illustrated in figure 6.4. The following fragment represents the specification in terms of ADL: PATTERN Valuations val val in in~;val in;val~;appliesIn ENDPATTERN

:: :: :: ||-

Rule * Valuation. RelationRef * Pair. Pair * Valuation. val;in~. in;in.

Valuations are used to define the semantics of ADL. We introduce the notation C a r b to denote that the value a r b of a relation r is true in context C.


111

Figure 6.4: Structure of Valuations

Camb C C C C C C C

6.2.5

a a a a a a a

(r;s) b (r!s) b (r/\s) b (r\/s) b (r~) b (-r) b Ib

iff m val (a, b) ∧ ∃r :: Rule : m in r ∧ r appliesIn C ∧ ∃r :: Relation : (a, b) in r ∧ in(r) = C iff there exists c such that C a r c ∧ C c s b iff for all c such that C a r c ∨ C c s b iff C a r b ∧ C a s b iff C a r b ∨ C a s b iff C b r a iff C 6 bra iff C a = b

Patterns

A pattern is a collection of rules plus the declarations of all relation references used in these rules. The structure of the following definitions is illustrated in figure 6.2 on page 107. The function definedIn for rules is discussed on page 105. Besides that one, we need the following function to convey which declarations are defined in which patterns: definedIn :: Declaration → Pattern

(6.36)

Every relation reference m used in a rule r is defined in the same pattern as that rule and every declaration defined in that pattern is used in one of its rules. m in r ⇔ definedIn(sign(m)) = definedIn(r) The relations in and sign are discussed in section 6.17 (pg. 106).

(6.37)

112

CHAPTER 6. ADL

A relation r is bound to a declaration, which is defined in a pattern used in the relation’s context. in(r) uses definedIn(sign(r))

(6.38)

The relations in, sign, and uses in this property are discussed in section 6.16. Any relation r in a context c is also known in more generic contexts than c. The reason is that a relation is a set of pairs, so subsets are subrelations. in(r) specializes c ⇒ in(r) = c

(6.39)

The definition of specializes is given in section 6.14 (pg. 106). A pattern p used by a context c is implicitly used by more specific contexts c0 : c0 specializes c ∧ c uses p ⇒

c0 uses p

(6.40)

The following fragment represents the specification in terms of ADL: PATTERN Patterns definedIn :: Declaration -> Pattern. in |- sign ; definedIn ; definedIn~. in~;sign |- uses ; definedIn~ in ; specializes |- in specializes ; uses |- uses ENDPATTERN The structure of the complete specification is illustrated in figure 6.5.

6.3

Language

ADL is a relation algebra [23], which is used to express business rules. Every business rule is a formal representation of a business requirement. Using definitions from [23], this section introduces a family of languages for expressing business rules suitable for use in the Ampersand approach. The language ADL satisfies the requirements for such a language and is therefore a suitable language for Ampersand. The presentation in this paper assumes that the reader is familiar with relation algebras. Rules are represented in an algebra hR, ∪, , ; , ` , Ii, in which R is a set of relations, ∪ and ; are binary operators of type R × R → R, and ` are unary

6.3. LANGUAGE

113

Figure 6.5: Entire Structure of ADL

operators of type R → R and I represents an identity relation, and satisfying the following axioms for all relations r, s, t ∈ R:

r∪s (r ∪ s) ∪ t x∪y∪x∪y (r; s); t (r ∪ s); t r; I r`

` `

(r ∪ s)

= = = = = =

s∪r r ∪ (s ∪ t) x r; (s; t) r; t ∪ s; t r

= r

(6.41) (6.42) (6.43) (6.44) (6.45) (6.46) (6.47)

`

`

= r ∪s

(6.48)

(r; s) = s` ; r` r ; r; y ∪ s = s

(6.49) (6.50)

`

`

To enrich the expressive power for users, other operators are used as well. These are the binary operators ∩, †, `, and ≡, all of which are of type R × R → R.

114

CHAPTER 6. ADL

They are defined by: r∩s r†s r`s r≡s

= = = =

s∪r s; r r∪s (r ` s) ∩ (s ` r)

(6.51) (6.52) (6.53) (6.54)

An algebra of concepts hC, v, >, ⊥i is used to represent relations, in which C is a set of Concepts, v: C × C, and > ∈ C and ⊥ ∈ C, satisfying the following axioms for all classes A, B, C ∈ C: Av> ⊥vA AvA AvB∧B vA ⇒ A=B AvB∧B vC ⇒ AvC

(6.55) (6.56) (6.57) (6.58) (6.59)

Concept ⊥ is called ‘anything’ and > is called ‘nothing’. Predicate v is called isa. It lets the user specify things such as ‘an affidavit is a document’. A binary relation r : A×B is a subset of the cartesian product A × B, in which A and B are Concepts. In English: a relation r : A×B is a set of pairs ha, bi with a ∈ A and b ∈ B. We call r the name of the relation, A the source of the relation, and B the target of the relation. A relation that is a function (i.e. a univalent and total relation) is denoted as r : A→B For the purpose of defining types, operator u : C × C → C and predicate : C × C are defined: AB AvB BvA ¬(A B)

⇔ ⇒ ⇒ ⇒

AvB∨B vA AuB = B AuB = A AuB = >

(6.60) (6.61) (6.62) (6.63)

Predicate defines whether two types are compatible and operator u (the least upper bound) gives the most specific of two compatible types. Note that the conditions at the left of equations 6.61 through 6.63 are complete, so u is defined in all cases. Also, in case of overlapping conditions A v B ∧ B v A, axiom 6.59 says that A = B. causing A u B to be unique. ADL is restricted to concepts that are not ⊥ nor >, but the two are needed to signal type errors.

6.3. LANGUAGE

115

Let r : A×B and s : P ×Q name relation implication equality complement conversion union intersection composition relative addition identity

notation r r`s r≡s r r` r∪s r∩s r; s r†s IA

condition AP ∧BQ AP ∧BQ

AP ∧BQ AP ∧BQ BC BC

type [A, B] [A u P, B u Q] [A u P, B u Q] [A, B] [A, B] [A u P, B u Q] [A u P, B u Q] [A, C] [A, C] [A, A]

Table 6.2: Definitions for typing Any language with operators that satisfy axioms 6.41 through 6.59 is a suitable language for Ampersand. Table 6.2 gives the names and types of all operators. Not all expressions that can be written are type correct. An expression must satisfy the condition mentioned in table 6.2, otherwise it is undefined. A compiler for a language to be used for this purpose must therefore contain a type checker to ensure that all expressions satisfy the condtions mentioned in table 6.2.

fact

notation xry

declaration declaration

r : A×B f : A→B

implication

r`s

equality complement

r≡s r

conversion union intersection composition r. addition

r` r∪s r∩s r; s r†s r†s r†s I

identity

meaning there is a pair between x and y in relation r. Also: the pair hx, yi is an element of r, (hx, yi ∈ r). There is a relation r with type [A, B]. There is a function f with type [A, B]. (A function is a relation) if x r y then x s y. Alternatively: x r y implies x s y. Alternatively: r is included in s or s includes r. x r y is equal to x s y all pairs not in r. Also: all pairs ha, bi for which x r y is not true. all pairs hy, xi for which x r y. x(r ∪ s)y means that x r y or x s y. x(r ∩ s)y means that x r y and x s y. x(r; s)y means that there is a z such that x r z and z s y. x(r † s)y means that for all z, x r z or z s y. x(r † s)y means that for all z, x r z implies z s y. x(r † s)y means that for all z, z s y implies x r z. equals. Also: a I b means a = b.

Table 6.3: Semantics The complete list of notations with meanings attached to them is given in table

116

CHAPTER 6. ADL

6.3. In some cases, alternative meanings are also given. If x, y, and z are used in an unbound manner, universal quantification (i.e. “for all x, y, and z”) is assumed.

Bibliography [1] Sarbanes-Oxley Act of 2002. [2] S. Ali, B. Soh, and T. Torabi. A novel approach toward integration of rules into business processes using an agent-oriented framework. IEEE Transactions on Industrial Informatics, 2(3):145– 154, August 2006. [3] ANSI/INCITS 359: Information Technology. Role Based Access Control Document Number: ANSI/INCITS 359-2004. InterNational Committee for Information Technology Standards (formerly NCITS), February 2004. [4] Eric Baardman and Stef Joosten. Procesgericht systeemontwerp. Informatie, 47(1):50–55, January 2005. [5] Ron Barends. Activeren van de administratieve organisatie. Research report, Bank MeesPierson and Open University of the Netherlands, November 26, 2003. [6] Chris J. Date. What not how: the business rules approach to application development. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [7] Umeshwar Dayal, Alejandro P. Buchmann, and Dennis R. McCarthy. Rules are objects too: A knowledge model for an active, object-oriented databasesystem. In Lecture notes in computer science on Advances in objectoriented database systems, pages 129–143, New York, NY, USA, 1988. Springer-Verlag New York, Inc. [8] Augustus De Morgan. On the syllogism: Iv, and on the logic of relations. Transactions of the Cambridge Philosophical Society, 10(read in 1860, reprinted in 1966):331–358, 1883. [9] R. Deen. Het nut van case-handling - flexibel afhandelen. Workflow magazine, 6(4):10–12, 2000. [10] Remco M. Dijkman, Luis Ferreira Pires, and Stef M.M. Joosten. Calculating with concepts: a technique for the development of business process 117

118

BIBLIOGRAPHY support. In A. Evans, editor, Proceedings of the UML 2001 Workshop on Practical UML - Basesd Rigorous Development Methods Countering or Integrating the eXstremists, volume 7 of Lecture Notes in Informatics, Karlsruhe, 2001. FIZ.

[11] Remco M. Dijkman and Stef M.M. Joosten. An algorithm to derive use case diagrams from business process models. In Proceedings IASTED-SEA 2002, 2002. [12] W. van Dommelen and S. Joosten. Vergelijkend onderzoek hulpmiddelen beheersing bedrijfsprocessen. Technical report, Anaxagoras and EDP Audit Pool, 1999. [13] M. Fowler. Analysis Patterns - Reusable Object Models. Addison-Wesley, Menlo Park, 1997. [14] Holger Herbst, Gerhard Knolmayer, Thomas Myrach, and Markus Schlesinger. The specification of business rules: A comparison of selected methodologies. In Proceedings of the IFIP WG8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle, pages 29–46, New York, NY, USA, 1994. Elsevier Science Inc. [15] IEEE: Architecture Working Group of the Software Engineering Committee. Standard 1471-2000: Recommended Practice for Architectural Description of Software Intensive Systems. IEEE Standards Department, 2000. [16] Peter Jipsen, Chris Brink, and Gunther Schmidt. Background Material, chapter 1, pages 1–21. Advances in Computing Science. Springer-Verlag, 1997. [17] Rieks Joosten and Berco Beute. Requirements for personal network security architecture specifications. Technical Report Freeband/PNP2008/D2.4, TNO, The Netherlands, 2005. [18] Rieks Joosten, Jan-Wiepke Knobbe, Peter Lenoir, Henk Schaafsma, and Geert Kleinhuis. Specifications for the RGE security architecture. Technical Report Deliverable D5.2 Project TSIT 1021, TNO Telecom and Philips Research, The Netherlands, August 2003. [19] S. Joosten. Workpad - a conceptual framework for workflow process analysis and design. Unpublished, 1996. [20] Stef M.M. Joosten. Rekenen met taal. Informatie, 42:26–32, juni 2000. [21] Stef M.M. Joosten and Sandeep R. Purao. A rigorous approach for mapping workflows to object-oriented is models. Journal of Database Management, 13:1–19, October-December 2002. [22] S.M.M. Joosten et.al. Praktijkboek voor Procesarchitecten. Kon. van Gorcum, Assen, 1st edition, September 2002.

BIBLIOGRAPHY

119

[23] R.D. Maddux. Relation Algebras, volume 150 of Studies in Logic and the Foundations of Mathematics. Elsevier Science, 2006. [24] Tony Morgan. Business Rules and Information Systems: Aligning IT with Business Goals. Addison Wesley, 2002. [25] Ordina and Rabobank. Procesarchitectuur van het servicecentrum financieren. Technical report, Ordina and Rabobank, October 2003. presented at NK-architectuur 2004, www.cibit.nl. [26] Bart Orriëns and Jian Yang. A rule driven approach for developing adaptive service oriented business collaboration. In 2006 IEEE International Conference on Services Computing (SCC 2006), 18-22 September 2006, Chicago, Illinois, USA, pages 182–189. IEEE Computer Society, 2006. [27] Charles Sanders Peirce. Note b: the logic of relatives. In C.S. Peirce, editor, Studies in Logic by Members of the Johns Hopkins University (Boston). Little, Brown & Co., 1883. [28] Sudha Ram and Vijay Khatri. A comprehensive framework for modeling set-based business rules during conceptual database design. Inf. Syst., 30(2):89–118, 2005. [29] Ronald G. Ross. Principles of the Business Rules Approach. AddisonWesley, Reading, Massachussetts, 1 edition, February 2003. [30] James Rumbaugh, Ivar Jakobson, and Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, Reading, Mass., 1999. [31] Gunther Schmidt, Claudia Hattensperger, and Michael Winter. Heterogeneous Relation Algebra, chapter 3, pages 39–53. Advances in Computing Science. Springer-Verlag, 1997. [32] Friedrich Wilhelm Karl Ernst Schröder. Algebra und logik der relative. In Vorlesungen u ¨ber die Algebra der Logik (exacte Logik), volume 3 of 1966. Chelsea, first published in Leipzig, 1895. [33] Walter A. Shewhart. Statistical Method From the Viewpoint of Quality Control. Dover Publications, New York, 1988 (originally published in 1939). [34] J. F. Sowa and J. A. Zachman. Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3):590–616, 1992. [35] Irma Valatkaite and Olegas Vasilecas. On business rules automation: The br-centric is development framework. In Johann Eder, Hele-Mai Haav, Ahto Kalja, and Jaan Penjam, editors, Advances in Databases and Information Systems, 9th East European Conference, ADBIS 2005, Tallinn, Estonia, September 12-15, 2005, Proceedings, volume 3631 of Lecture Notes in Computer Science, pages 349–364. Springer, 2005.

120

BIBLIOGRAPHY

[36] J. van Beek. Generation workflow - how staffware workflow models can be generated from protos business models. Master’s thesis, University of Twente, 2000. [37] R. van der Tol. Workflow-systemen zijn niet flexibel genoeg. Automatiserings Gids, (11):21, 2000. [38] Erik van Essen, Berco Beute, and Rieks Joosten. Service domain design. Technical Report Freeband/PNP2008/D3.2, TNO, The Netherlands, 2005. [39] Wan M. N. Wan-Kadir and Pericles Loucopoulos. Relating evolving business rules to software design. Journal of Systems Architecture, 50(7):367– 382, 2004. [40] Jeannette M. Wing. A symbiotic relationship between formal methods and security. In CSDA ’98: Proceedings of the Conference on Computer Security, Dependability, and Assurance, pages 26–38, Washington, DC, USA, 1998. IEEE Computer Society.

Index atom, 98 Attention, 81 bijective, 47 business rule, 2, 27 complement, 35 composition, 36 concept, 31 conceptual diagram, 33 contents, 31 context, 99 conversion, 36 current, 107 current context, 100 cycle chasing, 43 declaration, 31, 101 derivation, 44 diversity relation, 38 empty relation, 35 equivalence relation, 52 Error of type 1, 86 Error of type 2, 87 Error of type 3, 88 Error of type 4, 89 Error of type 5, 90 Error of type 6, 91 Error of type 7, 92 expression, 99

implication, 40 inclusion, 40 injective, 47 instance, 29 intersection, 35 isa, 114 left atom, 104 mathematical form, 32 matrix form, 32 monotonicity, 64 multiplicity, 46 name, 31 pair, 31, 104 partial, 47 partial order, 52 pattern, 99 population, 98 property, 52 relation, 31 relation reference, 106 relational, 34 relative addition, 38 right atom, 104 rule, 40, 41

generic, 28 graphical form, 32

set, 29 source, 31, 99, 101, 104 specific, 28 subrelation, 108 surjective, 47 symmetric, 51

identity relation, 37

tabular form, 32

function, 47

121

122 target, 31, 99, 101, 104 total, 47 transitive, 51 type, 98–100, 108 union, 35 univalent, 46 universal relation, 35 valuation, 102, 110 violation, 41

INDEX

Rule based design - CiteSeerX

Rule based design - CiteSeerX

Suggest Documents

Rule-Based Design

Interactive Rule-Based Design - Cumincad

Design Rules and Design Rule Checking - CiteSeerX

Rule-based item design of statistical word problems: A ... - CiteSeerX

Rule-Based Service Modeling - CiteSeerX

Rule-based Partner Relationship Management (PRM) - CiteSeerX

Categorizing Approaches Combining Rule-Based and ... - CiteSeerX

A RULE-BASED SPECIFICATION SYSTEM FOR ... - CiteSeerX

ASSOCIATION-RULE-BASED PREDICTION OF OUTER ... - CiteSeerX

Rule-Based Adaptive Problem Generation in ... - CiteSeerX

Rent's Rule Based Switching Requirements - CiteSeerX

2 Ants Constructing Rule-Based Classifiers - CiteSeerX

Foundations of Rule-Based Query Answering - CiteSeerX

RULE-BASED USER CHARACTERISTICS ACQUISITION ... - CiteSeerX

how artifacts rule web based communities - CiteSeerX

Rule-Based Text Categorization Using Hierarchical ... - CiteSeerX

Agile Service-Oriented Applications: Rule-based ... - CiteSeerX

Rule-Based Dialogue Management Systems - CiteSeerX

Rulespect: Language-Independent Rule-Based AOP ... - CiteSeerX

Combining Tabular, Rule-Based, and Procedural ... - CiteSeerX

Rule-Based Programming with Mathematica - CiteSeerX

RULE-BASED USER CHARACTERISTICS ACQUISITION ... - CiteSeerX

Rule-Based Text Categorization Using Hierarchical ... - CiteSeerX

A RULE-BASED SPECIFICATION SYSTEM FOR ... - CiteSeerX