Generating a Tool for Teaching Rule-based Design

Stef Joosten and Gerard Michels

Department of Computer Science, Open University The Netherlands, Valkenburgerweg 177, Heerlen, Netherlands

{stef.joosten, gerard.michels}@ou.nl

Keywords:

Business Rules, Requirements Engineering, Software Generation, Computer Science Education.

Abstract:

Software generation from a formal requirements speciﬁcation has enabled a small research team to develop

a tool set for educational design exercises and didactical research. This approach was needed to obtain a

development environment, which is responsive to changing requirements due to maturing didactics and future

research questions. We use Ampersand, a rule-based design methodology, to specify and generate the tool set

called the Repository for Ampersand Projects (RAP). RAP is being used in a course on Ampersand for master

students of computer science and business management. Analytic tools have been interconnected to RAP to

obtain analytics about student activities in RAP. So, Ampersand is both the subject of teaching and research

as well as an asset used to develop and maintain RAP. In this paper we present how RAP has been generated

with Ampersand and reﬂect upon the value of this design choice.

1 INTRODUCTION

The authors have developed a Repository for Amper-

sand Projects (RAP) to facilitate teaching Ampersand

as well as research on that subject. Ampersand is a

methodology to design information systems and busi-

ness processes as a formal collection of rules. RAP is

a tool set for Ampersand design exercises, which fea-

tures rule-based interfaces to connect analytic tools in

a way that preserves semantics of data. The analytic

tools use semantic data in RAP to produce unambigu-

ous measurement results for our research. The objec-

tive of our research is to understand how to teach Am-

persand to master students of computer science and

business management. The ﬁrst study using data from

RAP has been accepted for publication (Michels and

Joosten, 2013).

This paper reﬂects on our choice to use Amper-

sand to generate RAP from functional requirements.

Ampersand was a prerequisite in this choice c.q. the

question is whether rule-based design has brought us

closer to our research objective. The answer is posi-

tive. By using Ampersand we have obtained a devel-

opment environment for RAP, that enables us to re-

spond to changing requirements in a controlable and

timely fashion. We can adopt new didactical insights

in the exercise tool and facilitate our current and fu-

ture studies with unambiguous analytics from RAP.

Thus, this paper presents the fundament of our envi-

ronment to study and improve the teaching of Amper-

sand i.e. the generation of RAP with Ampersand.

Section 2 provides a background on using rules as

requirements. Section 3 introduces Ampersand as a

rule-based approach on a formal language to design

information systems. Section 4 describes the generic

and speciﬁc issues of generating RAP with Amper-

sand e.g. rule-compliant processes, customized data

access. We conclude with a reﬂection on our accom-

plishments with RAP up to date and expectations for

the future.

2 RULES AS REQUIREMENTS

This paper argues that a rule-based design approach

can reduce the gap between the owners of require-

ments (end users, patrons, auditors, etc.) and the de-

sign of information systems, by giving compliance

guarantees to these owners and by giving the appro-

priate tools to requirements engineers. The Business

Rules Community (Ross, 2003b) has argued since

a long time that natural language provides a bet-

ter means for discussing requirements than graphical

models (e.g. UML (Rumbaugh et al., 1999)). This

vision is the fundament of profound assets like the

Business Rules Manifesto (Ross, 2003a), the Busi-

ness Rules Approach (Ross, 2003b), the SBVR stan-

dard (Object Management Group, Inc., 2008) and

RuleSpeak (Business Rule Solutions, LLC., 2013).

Rule-based design goes beyond requirements by for-

malizing business rules and using them as require-

ments to partially automate information system de-

230

Joosten S. and Michels G.

Generating a Tool for Teaching Rule-based Design.

DOI: 10.5220/0004775902300236

In Proceedings of the Third International Symposium on Business Modeling and Software Design (BMSD 2013), pages 230-236

ISBN: 978-989-8565-56-3

velopment.

Rule-based design uses the word business rule to

denote a formal representation of a business require-

ment. Business rules have been represented in many

different ways. Prolog (Clocksin and Mellish, 1981)

is an early rule-based approach that uses Horn-clauses

as a means to write computer programs. Widespread

are also Event-Condition-Action (ECA) rules of ac-

tive databases, such as (Dayal et al., 1988; Paton and

ıaz, 1999; Widom, 1996), which represent success-

ful results of earlier research into functional depen-

dencies between database transactions in the seven-

ties and eighties. Expert systems and other develop-

ments founded in ontology (Gruber, 1993; Berners-

Lee et al., 2001) can be regarded as ways to represent

business processes by means of rules. Approaches

based on event traces, such as Petri Nets (Reisig,

1985) and ARIS (Scheer, 1998), have dominated the

90’s and are still popular to date (Green and Rose-

mann, 2000). The information systems community is

aware (e.g. (Ram and Khatri, 2005)) that mathemat-

ical representations of business rules can be useful.

For example, Date’s criticism of SQL for being un-

faithful to relational algebra (Date, 2000) advocates a

more declarative approach to information system de-

sign, and puts business rules in the center of the de-

sign process.

This paper argues that business requirements are

sufﬁcient to generate a functional prototype of an in-

formation system. The word ‘sufﬁcient’ suggests that

requirements engineers need not communicate with

the business in any other way. This suggestion is seri-

ously ﬂawed. Models are still useful, but their role

changes. In Ampersand, models are artifacts, pre-

ferrably produced automatically, that document the

design. If desired, a requirements engineer can avoid

to discuss these artifacts (data models, etc.) with the

business, but they are available and undeniably useful

as documentation in the design process. Ampersand

shifts the focus of the design process to requirements

engineering, because a larger part of the process is

automated.

Controlling design processes directly by means of

business rules has consequences for requirements en-

gineers, who will encounter a simpliﬁed design pro-

cess. From their perspective, the design process is de-

picted in ﬁgure 1. The main task of a requirements en-

gineer is to collect rules to be maintained. These rules

are to be managed in a repository (RAP). From that

point onwards, a ﬁrst generator (G) produces various

design artifacts, such as data models, process models

etc. These design artifacts can then be fed into another

generator (an information system development envi-

ronment), that produces the actual system. That sec-

Figure 1: Rule-based design process (engineer).

ond generator is typically a software development en-

vironment, of which many exist and are heavily used

in the industry. Alternatively, the design can be built

in the conventional way as a database application. A

graphical user interface on the repository and gener-

ator will help the requirements engineer by storing,

managing and checking rules, to generate speciﬁca-

tions, analyze rule violations, and validate the design.

From the perspective of an organization, the de-

sign process looks like ﬁgure 2. At the focus of at-

Figure 2: Rule-based design process (organization).

tention is the dialogue between a problem owner and

a requirements engineer. The former decides which

requirements he wants and the latter makes sure they

are captured accurately and completely. The require-

ments engineer helps the problem owner to make re-

quirements explicit. Ownership of the requirements

remains in the business. The requirements engineer

can tell with the help of his tools whether the re-

quirements are sufﬁciently complete and concrete to

Generating a Tool for Teaching Rule-based Design

231

make a buildable speciﬁcation. The requirements en-

gineer sticks to the principle of one-requirement-one-

rule, enabling him to explain the correspondence of

the speciﬁcation to the business.

3 AMPERSAND

The purpose of Ampersand is to have the right inter-

action with stakeholders to deﬁne the right business

rules and represent them unambiguously. Ampersand

looks at business rules not only as an agreement be-

tween parties, but uses them as functional require-

ments to automate an information system as well.

That is: these rules are to be maintained by all parties

at all times and the IT must support that. Maintaining

these rules is done either by people (of any party) or

by computers.

A requirements engineer using Ampersand de-

ﬁnes a suitable relational information structure to de-

ﬁne rules upon. A meaningful speciﬁcation of rules

in Ampersand can be incomplete or even contain

no business rule at all. In that matter, Ampersand

clearly differs from more common relational speci-

ﬁcation languages like Alloy (Jackson, 1999). No

business rules on an information structure represent

ultimate freedom when using that information struc-

ture in business processes. This kind of freedom is

explicitly useful in experimental contexts like the ed-

ucational design exercises in RAP. For example, a stu-

dent can ﬁrst deﬁne an information structure and add

rules one-by-one while studying the impact of adding

another rule. More practical reasons to omit a busi-

ness rule are disagreement between stakeholders, ir-

relevance of the rule, or unawareness of the rule.

Ampersand uses a relation algebra (Maddux,

2006) as a language in which to express business

rules. Relation algebras have been studied extensively

and are well known for over a century (Schr

oder,

1895). The use of existing and well described theory

brings the beneﬁt of a well conceived set of operators

with well known properties.

The Ampersand syntax consists of constant sym-

bols for (business) concepts, (business) elements, re-

lations and relation operators. Relation terms can be

constructed with relations and relation operators.

Let C be a set of concept symbols. A concept is

represented syntactically by an alphanumeric charac-

ter string starting with an upper case character. We

use A, B, and C as concept variables.

Let U be a set of atom symbols. An atom is repre-

sented syntactically by an ASCII string within single

quotes. All atoms are an element of a concept, e.g.

’Peter’ is an element of Person. We use a, b, and c

as atom variables.

Let D be a set of relation symbols. A relation sym-

bol is represented syntactically by an alphanumeric

character string starting with a lower case character.

For every A, B ∈ C, there are special relation symbols,

and V

A×B

. We use r, s, and t as relation variables.

Let ¬,

, t, and

be relation operators of arity 1,

1, 2, and 2 respectively. The binary relation opera-

tors u,⇒ and ≡ are cosmetic and only deﬁned on the

interpretation function.

Let R be the set of relation terms. We use R, S,

and T as variables that denote relation terms.

R is recursively deﬁned by

, V

A×B

, r, ¬R, R

, R t S, R

S ∈ R

provided that R, S ∈ R, r ∈ D, and A, B ∈ C

An Ampersand script for context C is a user-

deﬁned collection of statements where

• RUL ⊆ R is a collection of relation terms called

rules.

• REL is a collection of r : A ∼ B for all r ∈ D such

that A, B ∈ C. The instances of REL are called

relation declarations.

• POP is a collection of a r b such that a ∈ A, b ∈ B

and (r : A ∼ B) ∈ REL.

The relation declarations deﬁne the conceptual struc-

ture and scope of C. Relation elements deﬁne facts

in C. POP is called the population of C. Rules are

constraints on that population.

The interpretation function I(R) deﬁnes the se-

mantics of a relation term R. This function interprets

relation terms based on POP and a relation algebra

hR, ∪, , ;,

, Ii where R ⊆ P (U). All relation sym-

bols used in a relation term are either declared by the

user in REL or I

or V

A×B

. So, the relation algebra

on R is conﬁgured by the user through REL. The in-

terpretation of all relation symbols in D is completely

user-deﬁned through POP. Thus, given some REL

and some POP, I(R) determines whether some rela-

tion holds between two elements.

Given some C, the interpretation function of rela-

tion terms is deﬁned by

relation I(r) = {ha, bi | a r b ∈ POP}

(1)

identity I(I

) = {ha, ai | a ∈ A} (2)

universal I(V

A×B

) = {ha, bi | a ∈ A, b ∈ B}

(3)

complement I(¬R) = I(R) (4)

converse I(R

) = I(R)

(5)

union I(R t S) = I(R) ∪ I(S) (6)

composition I(R

S) = I(R); I(S) (7)

Third International Symposium on Business Modeling and Software Design

232

(the interpretation of the mentioned cosmetic relation

operators)

intersection I(R u S) = I(¬(¬R t ¬S)) (8)

implication I(R ⇒ S) = I(¬R t S) (9)

equivalence I(R ≡ S) = I((R ⇒ S) u (S ⇒ R))

(10)

Relations need to have a type to be more practi-

cal for requirements engineers (Michels et al., 2011).

This way, only a relation term R ∈ R with a type T(R)

has an interpretation. A relation term without a type

T(R) is said to have a type error or to be (seman-

tically) incorrect. Compilers for Ampersand scripts

must reject relation terms with a type error. A require-

ments engineer might call a relation term without a

type nonsense.

Van der Woude and Joosten (van der Woude and

Joosten, 2011) have enhanced the typing function

with subtyping of concepts. Subtyping is useful to

confront two different, but comparable concepts with-

out being rejected as a type error. For example, a re-

quirements engineer can model the concept Client

and Provider to be comparable over a more gen-

eral concept. This might make sense when a client

can be a provider as well. A course book on Amper-

sand (Wedemeijer et al., 2010) also discusses alter-

native patterns in Ampersand to model apparent sub-

types of concepts.

4 GENERATING RAP

RAP includes ﬁrst and second generator functions

and the repository (RAP) of ﬁgure 1. The genera-

tor functions are part of a command-line tool called

the Ampersand compiler. A web application of RAP

for design exercises provides access to the repository

and generator functions. The Ampersand compiler is

manually coded in Haskell. Source and binary ﬁles

of the Ampersand compiler are freely available via

wiki.tarski.nl. The web application and reposi-

tory are generated with the compiler from an Amper-

sand script for RAP. RAP and its full script are freely

available at request.

We claim that the Ampersand compiler can gen-

erate a compliant information system from business

requirements in an Ampersand script. Early versions

of the Ampersand compiler could already generate

a trivial, but compliant system. Such a trivial sys-

tem consists of a relational database, a web interface,

and a rule engine. The database model contains a ta-

ble of two columns for each relation declaration in

the script, to hold its population. An initial popu-

lation for the database is checked to be free of vio-

lations. The web interface provides a user with ba-

sic data functions for the database. A rule engine

checks all the rules before committing changes to the

database in order to remain compliant with the rules

c.q. the requirements. The current version of the Am-

persand compiler takes rules into account and uses

simple syntactic Ampersand constructs to derive more

practical system components. Examples of Amper-

sand constructs for practical enhancements are: an in-

terface construct to customize data access; attributes

to customize violation handling; and plain text at-

tributes to attach meaning or purpose to formal ele-

ments for traceability. In the next subsection we ad-

dress a generic issue: How do business rules yield a

compliant business process? In the remaining subsec-

tions we describe how a system, RAP, could be gen-

erated, which has shown to be sufﬁciently practical

for studies on and design exercises of a course at the

Open University. We use examples from the Amper-

sand script for RAP.

4.1 Compliant Processes

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. The role of infor-

mation technology is to help maintain business rules.

This is what compliance means. If any rule is vio-

lated, a computer can signal the violation and prompt

people or trigger a computer to resolve the issue. This

can be used as a principle for controlling business pro-

cesses. For that purpose two kinds of rules are distin-

guished: rules that are maintained by people and rules

that are maintained by computers. A rule maintained

by a computer is an automated activity within a busi-

ness process.

Since all formalized rules (both the ones main-

tained by people and the ones maintained by comput-

ers) are monitored, computers and persons together

form a system that lives by those rules. This es-

tablishes compliance. Business process management

(BPM) is also included, based on the assumption that

BPM is all about handling cases. Each case (for in-

stance 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 satisﬁed (i.e. no violations with

respect to that case remain), the case is closed. This

yields the controlling principle of BPM, which im-

plements Shewhart’s Plan-Do-Check-Act cycle (often

attributed to Deming) (Shewhart and Deming, 1939).

Generating a Tool for Teaching Rule-based Design

233

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 busi-

ness by drawing digital information from any avail-

able source. The observations are fed to a rule en-

gine, which checks them against business rules in a

repository. If rules are found to be violated, the rule

engine signals a process engine. The process engine

distributes work to people and computers, who take

appropriate actions. These actions can cause new sig-

nals, causing subsequent actions, and so on until the

process is completed. This principle rests solely on

rules, yielding implicit business processes which di-

rectly follow from the rules of the business. In com-

parison: workﬂow management derives actions from

a workﬂow model, which models the procedure in

terms of actions. Workﬂow models are built by mod-

elers, who transform the rules of the business into ac-

tions and place these actions in the appropriate order

to establish the desired result.

4.2 Rule-based Structure of RAP

RAP is an application on a repository of Ampersand

scripts. If RAP was just a storage for scripts, then its

Ampersand structure could remain limited to only one

concept Script ∈ C; no rules; no relations. However,

we want RAP to have functions to facilitate certain

activities. For those functions, concepts, relations and

rules need to be added to the script of RAP.

We have used RAP as:

• a design exercise tool for students. A student user

of RAP has a facility to upload a script to RAP, a

structured view on a script in RAP, and access to a

few compiler functions to run on a script in RAP.

The second release of the exercise tool anticipates

on more roles than students, which are teachers,

advanced students, and requirements engineers.

The second release introduces rule-guided editing

of a script in the structured view;

• a data source for measurements to study student

behaviour;

• a data storage for measurement results to use in

the exercise tool for learning.

No additional structure was needed in the script of

RAP to use RAP as a data source for measurements.

If the results of measurements need to be stored in

RAP, then we need at least a univalent relation from

the source of the measure to the result. For example,

the structured view on a script includes the counters

of rules, relations and concepts, which are measure-

ments needed for a design activity called cycle chas-

ing. Each counter is a functional relation in the script

of RAP e.g. count rules : Script→Number.

Most of the script of RAP relates to student ac-

tivities in the exercise tool. The upload facility is a

handcoded component of RAP, and is thus excluded

from the script of RAP. The structured view follows

the syntactic structure of a script as implemented by

the script parser of the compiler. The compiler in-

cluding parser is coded in Haskell, which is a func-

tional programming language. The functional struc-

ture of a script in Haskell could easily be transposed

into a relational structure in Ampersand, because a

relation is less strict than a function. The view also

contains derivates from a script like conceptual di-

agrams, a diagnosis on the typing function(Michels

et al., 2011), or a report of rule violations. For ex-

ample, the source concept of a relation declaration

is a functional relation in the script of RAP, source :

Concept→Declaration. In the Haskell code of the

compiler, the data structure Declaration has an at-

tribute of type Concept to hold its source concept.

A compiler function on a script is implemented as

a functional relation from a script to a web location

where the compiler output is accessible. For exam-

ple, the script of RAP contains a relation to gener-

ate a functional speciﬁcation from a script, gen fspec :

Script→FSpec.

4.3 Custom Data Access

An interface construct exists in the Ampersand lan-

guage to access the population of relations by means

of relation algebraic expressions. An interface is a

tree of labeled expressions where each node connects

a parent R and child S with a composition operator

S. The interface provides an easy way to conﬁg-

ure data access with the full power of the relation al-

gebra. The relation algebra also has restrictions, for

instance numerical calculations are not possible. At-

tributes can be set to customize data access like who

may use an interface and which relations in an inter-

face can be altered with that interface.

We demonstrate how to conﬁgure an interface by

an example from RAP. The following interface is used

to generate a web page for students to view a context.

-1- INTERFACE "CONTEXT" FOR Student:I[Context]

-2- BOX ["name" : ctxnm

-3- ,"PATTERNs" : ctxpats

-4- ,"concepts" : ctxcs

-5- ,"ISA-relations" : ctxpats;ptgns

-6- ,"relations" : ctxpats;ptdcs

-7- ,"RULEs" : ctxpats;ptrls]

The text elements in double quotes are labels. The

text after a colon is an ASCII-encoded relation al-

gebraic expression. The ﬁrst line deﬁnes a root

Third International Symposium on Business Modeling and Software Design

234

node with the identity relation of a concept Context.

This means that the interface can be used to view

or alter relations of any instance of the domain of

the identity relation of Context. This interface is a

view-only interface, because the attribute to grant ac-

cess to edit certain relations in the interface is not

set. The optional FOR-attribute restricts usage of

this interface to a Student user only. Each instance

of Context represents a context C, that could have

been parsed from a script by the compiler. The

box of line 2 to 7 connects six sibling nodes to the

root by means of a composition operator. The re-

lation ctxnm : Context→ContextName holds the re-

lation of user-friendly names for a C. The relation

ctxpats : Context ∼ Pattern holds the relation to

patterns in the C. Patterns are syntactic containers

for rules, declarations and ISA-relations i.e. ptrls :

Pattern ∼ Rule, ptdcs : Pattern ∼ Declaration,

and ptgns : Pattern ∼ Gen. The relation ctxcs :

Context ∼ Concept holds the relation to concepts in

the C.

4.4 Conﬁgure Layout

The layout of a web page generated from an interface

is conﬁgured in Cascading Style Sheets (CSS). These

web pages contain labels and textual data.

Little efforts were needed to customize the default

style sheets to suit RAP. We experienced that solu-

tions to improve the user experience and comfort are

more difﬁcult to implement in a generated page than

in a hand coded page. But when such a solution is im-

plemented on a good design, then you can easily take

advantage of it in any page.

For example, RAP needs to display non-textual

data like images and handlers to execute parameter-

ized software functions. A view on a concept is in-

vented that allows the requirements engineer to com-

pose non-textual HTML elements based on instances

of a concept. For example instances of the concept

ConceptualDiagram are urls to actual images, which

are embedded in an HTML element to display images.

Likewise, all software functions on data in RAP are

encapsulated by the only manually coded web page

of RAP (index.php). RAP has a concept G refering to

the G in ﬁgure 1, which contains software functions to

compose HTML links to execute software like com-

piler functions. The Ampersand code below conﬁg-

ures a view on an instance of G.

VIEW G:

G(PRIMHTML

"<a href=’../../index.php?operation="

,operation ,PRIMHTML "&file="

,applyto;filepath ,applyto;filename

,PRIMHTML "’>" ,functionname

,PRIMHTML "</a>")

PRIMHTML becomes actual HTML on the gener-

ated web page. Functional relations with the in-

stance of G as a source ﬁll the parameters of the

url. The relation operation : G→Operation relates

instances of G to an operation number. The rela-

tion applyto : G→Script relates instances of G to

the script to which the operation of G must be ap-

plied. The relations ﬁlepath : Script→FilePath and

ﬁlepath : Script→FilePath relate the script to a lo-

cation on a ﬁle system. The relation functionname :

G→String relates instances of G to a textual element

to click on in order to execute a software function.

4.5 Manage Measurements for

Research

The most prominent advantage of using RAP for mea-

surements in our experience is the documentation and

qualitity of input data. The quality of data in RAP is

high, because data is embedded in a formally deﬁned

information structure. The information structure of

data has a clear and compliant relation with business

requirements, such that the purpose and meaning of

data can be documented and veriﬁed easily.

Measurements do not need to be part of the script

of RAP to use RAP as a data source for measure-

ments. This makes it easy to adapt to new measure-

ments, because no development efforts are required.

We do have added a univalent relation for each of our

measurements for studies to the script of RAP. Adding

a univalent relation is a small effort with hardly any

impact on RAP. A small advantage is gained because

measurements can be documented and managed in a

structured way. We have experienced control over our

measurements in their implementatation and use.

Measurements have been implemented as exten-

sions on the compiler and in spreadsheets.

5 CONCLUSIONS

In this paper we have presented an application of rule-

based design to obtain a development environment for

RAP.

Does RAP fulﬁll its purpose to facilitate teach-

ing Ampersand as well as research on that subject?

We have shown that the functional requirements for

RAP can be formalized by means of an Ampersand

script, such that RAP can be generated. Section 4

describes all the details of how RAP has been con-

structed. About 50 students per year have used RAP

to complete a design exercise which deﬁnes 80% of

the ﬁnal grade of a master course on rule-based de-

sign. A ﬁrst study has been accepted for publication

Generating a Tool for Teaching Rule-based Design

235

(Michels and Joosten, 2013), which uses analytics

from RAP based on 52 students who have used RAP

in the period between April 2010 and May 2011. This

publication reports on six hypotheses based on those

analytics in order to explore the possibilities to study

student behaviour with RAP. From the above obser-

vations we conclude that:

• RAP has been generated with Ampersand;

• RAP is sufﬁciently practical for teaching and re-

search.

For further research we have planned to identify di-

dactical requirements for the exercise tool for stu-

dents. Current analytics in RAP will be taken into

account. The objective is to upgrade the ’sufﬁciently

practical exercise tool’ to a ’teaching exercise guide

for students’.

Has the application of Ampersand brought us

closer to understand how to teach Ampersand to mas-

ter students of computer science and business man-

agement? With the development environment of RAP

we created, we are ready to adopt RAP to new didacti-

cal insights and produce unambiguous analytics. Our

ﬁrst study has produced preliminary results on how to

teach Ampersand. Thus, our research has progressed

due to the application of Ampersand because:

• with Ampersand we have created a responsive and

controlable environment for research;

• with Ampersand we could produce unambiguous

analytics to show that meaningful research with

RAP is feasible (Michels and Joosten, 2013).

The next step in research is to deﬁne didactical stud-

ies on how to teach Ampersand, which are based on

analytics in RAP.

REFERENCES

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

semantic web. Scientiﬁc American, 284(5):34–43.

Business Rule Solutions, LLC. (2013). RuleSpeak.

Retrieved Februari 27, 2013, from http://www.

rulespeak.com.

Clocksin, W. F. and Mellish, C. (1981). Programming in

Prolog. Springer.

Date, C. J. (2000). What Not How: the Business Rules Ap-

proach to Application Development. Addison-Wesley

Longman Publishing Co., Inc., Boston.

Dayal, U., Buchmann, A. P., and McCarthy, D. R. (1988).

Rules are objects too: A knowledge model for an

active, object-oriented database system. In Dittrich,

K. R., editor, OODBS, volume 334 of Lecture Notes

in Computer Science, pages 129–143. Springer.

Green, P. F. and Rosemann, M. (2000). Integrated pro-

cess modeling: An ontological evaluation. Inf. Syst.,

25(2):73–87.

Gruber, T. R. (1993). A translation approach to portable on-

tology speciﬁcations. Knowl. Acquis., 5(2):199–220.

Jackson, D. (1999). A comparison of object mod-

elling notations: Alloy, UML and Z. Tech-

nical report, Retrieved Februari 27, 2013,

from http://people.csail.mit.edu/dnj/

publications/alloy-comparison.pdf.

Maddux, R. (2006). Relation Algebras, volume 150 of Stud-

ies in logic. Elsevier, Iowa.

Michels, G. and Joosten, S. (2013). Progressive develop-

ment and teaching with RAP. Accepted at CSERC’13.

Michels, G., Joosten, S., van der Woude, J., and Joosten,

S. (2011). Ampersand: Applying relation algebra in

practice. In Proceedings of the 12th conference on Re-

lational and Algebraic Methods in Computer Science,

Lecture Notes in Computer Science 6663, pages 280–

293, Berlin. Springer-Verlag.

Object Management Group, Inc. (2008). Semantics of Busi-

ness Vocabulary and Business Rules (SBVR), v1.0.

Technical report, Retrieved Februari 27, 2013, from

http://www.omg.org/spec/SBVR/1.0/PDF.

Paton, N. W. and D

ıaz, O. (1999). Active database systems.

ACM Comput. Surv., 31(1):63–103.

Ram, S. and Khatri, V. (2005). A comprehensive framework

for modeling set-based business rules during concep-

tual database design. Inf. Syst., 30(2):89–118.

Reisig, W. (1985). Petri Nets: an Introduction. Springer-

Verlag New York, Inc., New York, NY, USA.

Ross, R. G. (2003a). The Business Rules Manifesto.

Retrieved Februari 27, 2013, from http://www.

businessrulesgroup.org/brmanifesto.htm.

Ross, R. G. (2003b). Principles of the Business Rule Ap-

proach. Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA.

Rumbaugh, J., Jacobson, I., and Booch, G., editors (1999).

The Uniﬁed Modeling Language reference manual.

Addison-Wesley Longman Ltd., Essex, UK, UK.

Scheer, A.-W. W. (1998). Aris-Business Process Frame-

works. Springer-Verlag New York, Inc., Secaucus, NJ,

USA, 2nd edition.

Schr

oder, E. (1895). Algebra und Logik der Relative. Vor-

lesungen

uber die Algebra der Logik (Exakte Logik) /

Ernst Schr

oder. Teubner.

Shewhart, W. and Deming, W. (1939). Statistical Methods

from the Viewpoint of Quality Control. Dover Books

on Mathematics Series. Dover Publications, Incorpo-

rated.

van der Woude, J. and Joosten, S. (2011). Relational hetero-

geneity relaxed by subtyping. In Proceedings of the

12th conference on Relational and Algebraic Methods

in Computer Science, Lecture Notes in Computer Sci-

ence 6663, pages 347–361, Berlin. Springer-Verlag.

Wedemeijer, L., Joosten, S., and Michels, G. (2010). Rule

Based Design. Open Universiteit Nederland, 1st edi-

tion.

Widom, J. (1996). The starburst active database rule system.

IEEE Trans. on Knowl. and Data Eng., 8(4):583–595.

Third International Symposium on Business Modeling and Software Design

236