Introduction

Conceptual modelling methods such as ER [4], NIAM [16], OOSA [5] and ORM [9] have traditionally been developed with the aim of providing conceptual models of database structures. More recently, however, such modelling methods have shown their use for modelling (the ontology) of domains in general [19,20]. In the latter case, their use leads to models capturing the concepts of a domain in general, as well as an associated language to express rules (such as business rules) governing the behaviour of the domain.

The above mentioned modelling methods typically take a natural language based perspective on the domain to be modelled. In this perspective, the resulting models are regarded as a domain grammar describing the allowed communication about a domain; the universe of discourse. This way of thinking dates back to the ISO report on Concepts and Terminology for the Conceptual Schema and the Information Base [13], and is at the base of modelling methods such as ER, NIAM, OOSA and ORM. A key advantage of such methods is that having a domain grammer at ones disposal, enables validation of the model by domain experts, since the model can be validated in terms of statements that are close to the language used by these experts.

A domain grammar can be extended to also cover rules (constraints) governing the behaviour of the domain. When combined with a reasoning mechanism, this rule language becomes a domain calculus. In the case of ORM, such a domain calculus has been presented in the form of Lisa-D [10], a formalisation of RIDL [15]. In [18,2] a more practical (from an implementation point of view) version called ConQuer has been introduced. What each of these languages have in common is that they exploit [11] the naturalness of the domain grammer in the construction of rules. As a result, the formulation of rules, as well as chains of reasoning expressed in these rules, closely resembles natural language. Being able to do so, again, enables validation of the models produced.

In the use of domain modelling methods, we observe three important trends which fuel our research activities. Firstly, more and more organisations strive for more mature levels of system development [17]. One of the steps towards maturity involves better defining development processes in order to make them more repeatable. This also applies to modelling processes. Organisations strive to make modelling processes more explicitly defined with the aim of achieving more repeatable results. Modelling methods such as ORM NIAM and OOSA not only feature a way of modelling, but also have a well-defined and explicit way of working based on natural language analysis. The way of working of a method is concerned with processes, guidelines, heuristics, etc, which are to be used in the creation of models, as opposed to its way of modelling which refers to the syntax and semantics of the language in which the models are to be expressed. Having a well-defined and explicit way of working aids towards a defined and more repeatable modelling process.

The second trend fuelling our research, is the use of controlled languages as the basis for unambiguous communication [6,22]. The essential idea of a controlled language is to define a subset of natural language which is rich enough for a specific purpose, but still restrictive enough so as to avoid unambiguities. We claim that a domain grammer and associated domain calculus provide a good starting point in defining controlled languages for domains. To some extend, a domain calculus already provides a (highly) controlled language. Such languages can also be used to represent domain specific reasoning steps, providing an additional form of domain knowledge. In [12] an initial study into the use of a domain calculus for such purposes has been reported.

The third trend we observe is the growing need for integrated models underlying a plethora of viewpoints, fuelled by the demands of MDA [7] and enterprise architecture [14]. UML as well as approaches for enterprise architecting [14] feature a wide variety of diagramming techniques (viewpoints). A domain model can provide a common underpinning of this variety of viewpoints, offering a unified domain ontology. A first elaboration of this role of domain models has been presented in [20]. However, more work needs to be done to make ORM suitable to deal with the modelling of active domains. This is the focus of this paper.

When applying ORM for the purpose of modelling active domains, we are primarily interested in re-using its rigorous way of working in the creation of models. This does require both active aspects (activities, tasks, processes, etc) as well as static aspects (results, documents, actors, tangiable objects, etc) to be expressed as objects playing roles in the domain.

The remainder of this paper is structured allong the overall way of working we suggest when modelling an active domain:

1. (Section 2) using the logbook paradigm the activities taking place in an active domain can be reported in terms of (elementary) facts, which can consequently be used (in principle using ORM's standard approach) to derive a domain grammar, 2. (Section 3) any constraints, temporal dependencies, etc, governing the flow of activities in a domain can then be formulated using a domain calculus referred to as the Object-Role Calculus, 3. (Section 4) finally, special graphical conventions are introduced to provide more compact representations of specific aspects of the active domain, such as the flow of activities, or the involvement of actors.

The logbook paradigm

When focussing on active domains ORM needs to be refined in order to better cater for the active aspects of such domains. The underlying challenge is to extend ORM to be able to cater for such domains, while at the same time maintaining ORM's natural-language based modelling rigour. In doing so, we base ourselves on earlier (partial) results [21,8].

Modelling an active domain does require a modelling language to deal with the notion of time. In the past, ORM has indeed been extended with the concept of time and evolution [21]. In this paper we propose to formalize this in terms of a logbook [8], which is intended to trace/mirror the activities taking place in the domain. Such a logbook will consist of a series of events reporting on the lifecycle of facts in the domain. For example:

Trafic light 20 is green ceased being true at 11:03:20 on 22-05-2006 Employee John works on the completion of order 50 started being true at 09:30 on 19-05-2006 In our view, a logbook approach is a natural extension of the earlier discussed natural language based perspective on modelling. To be more precise, we regard a history as an overview of the events that have taken place in the domain, while a logbook is a description of such a history using some controlled language.

The facts contained in the descriptions of the events are asumed to be expressed in terms of semi-natural language (controlled language) sentences as is normally the case in ORM's way of working. Using a traditional ORM approach, the set of facts used/allowed in a logbook can be generalised to a set of fact types, which together comprise the ORM model underlying the domain. As such, this ORM model then defines the domain grammar of the controlled language in which the facts are to be formulated.

Traditionally, ORM focuses on the modelling of facts in general. In the context of an active domain, these facts correspond to statements about what is the case and/or has happened in the domain at specific points in time. In ORM, the actual modelling process starts out from the verbalisation of such facts. These verbalisations are the starting point for the creation of the domain grammar. When considering an active domain, the set of facts that can be reported about this domain fall into two categories: (1) acts reporting on the performance of actions and (2) effects reporting the results of actions. This dichotomy applies at the instances level (the facts) as well as the type level, leading to act types and effect types respectively as sub-classes of fact types. In the case of acts, the objects involved (i.e. playing a role in the act) can be classified further into actors (objects responsible for performing the act) and actands (objects which are the effect of the act).

We assume that each event described in the logbook and the objects participating in the event, can be uniquely identified in that logbook. We will call this the Event Identification Principle. This identification principle is used as the base for all other identification mechanisms. This principle does not inhibit different events to occur on the same moment. In order to distinguish between accidently coincidence and necessarily coupled events, we assume that events may also have a compound nature, in such a way that: (1) different events in a logbook are independent of each other, (2) events are not splittable into multiple independent events. We take the perspective that the state of an active domain is the result of the sequence of actions leading up to that state. These actions may either take place in the domain, or outside the domain (such as the very creation of the domain). As a result, we take the position that the effects are actually derivable from the set of reported acts. This is what we call the Action Dominance Principle. This principle does lead to the question on how persistent properties, such as the speed of light, are to be treated in our logbook approach. This is covered by the Property Origination Principle, which states that each domain property pertains to: (1) either some act taken place in the domain, (2) or some effect of some act in the domain, (3) or some effect of the domain's creation (i.e. the result of a 'big bang' act). As a consequence, at each moment the state of the system is the result of all the effects of the domain's creation and the acts that were reported since then.

An important consequence of the Property Origination Principle is that (for most objects in the domain), the property of being alive should be the result of some act. Therefore, objects that are not present in the initial state require an explicit birth event. This is called the Birth Principle. Obviously, an object can not be responsible for its own birth, as it can not be active before coming into existence. The consequence is that some other object has to be responsible for causing this event, thus playing a dominant role in that event. If the existence of an object may terminate, then there should be an explicit death action that enforces an object to have the property of being death.

An immediate consequence of the Birth Principle and the Event Identification

Principle is that objects may be identified by their birth event. If an event starts life for more objects, then we require that the individual objects in this case may be identified by this event and their role in this event.

Object-Role Calculus

This section is concerned with a conceptual language in which rules can be expressed describing the behaviour that may be observed in a logbook compatible with the domain being modelled. The language presented, referred to as Object-Role Calculus (ORC) is a variant of Lisa-D [10], a formalisation of RIDL [15]. Lisa-D has originally been designed to describe all computable sets of facts that can be derived from the elementary facts defined in the underlying conceptual schema. The conceptual schema specifies all elementary sentences applicable for that domain. The semantics of Lisa-D have been described in terms of multisets. In this paper we will provide a light-weight definition of the ORC variant of Lisa-D, which is intended to describe temporal and statical aspects of the underlying domain.

Grounding in temporal logic

The semantics of ORC are grounded on Kripke structures [3]. In terms of Kripke structures, an application domain is seen as a Kripke structure S.R.s 0 , Π, L , where:

1. S is a non-empty set of states, 2. R ⊆ S × S is a total transition function, i.e. ∀ s ∃ T [(s, t) ∈ R], 3. s 0 is the initial state, 4. Π is a non-empty set of atomic propositions, and 5. L is a labelling function that maps each state on a subset of Π.

Our main assumption is that the state of an application domain is described by its history so far. As a consequence, a state corresponds uniquely to a logbook. Consequently, the transition function extends a logbook with a new event description, and the initial state is obtained as the empty logbook.

From the structure of the events in the logbook, the elementary object types. Their possible instantiations form the set Π of atomic propositions. The labeling function L then assigns the population of object types that is constructed by a logbook.

A linear-time temporal logic is syntactically described by the following BNF grammar:

φ → true | false | Π | ¬φ | q ∧ φ | φ ∨ φ | φ ⇒ φ | X φ | F φ | G φ | φ U φ

The expression X φ states that φ will hold in the next state, F φ that φ will eventually hold, G φ that φ will globally hold and φ U ψ states that at some point ψ will hold, while in all states before φ is valid. Let M be a Kripke structure over logbook LB, and let σ be a history. We further will assume an environment E for evaluation, consisting of a partial assignment of values to a set V of variables. The standard semantic interpretation of the temporal operators is:

M, E, σ |= X φ M, E, σ 1 |= φ M, E, σ |= φ U ψ ∃ n ∀ 0≤i<n M, E, σ i |= φ ∧M, E, σ n |= ψ

where σ(i) denotes the i-th element of sequence σ and σ i the subsequence of σ starting at position i. The other temporal operators are defined in terms of these base operators: F φ is equivalent with true U φ, and G φ is defined as ¬ F ¬φ. The propositional operators are also interpreted in the standard way:

M, E, σ |= ¬φ not M, E, σ |= φ M, E, σ |= q ∧ ψ M, E, σ |= φ and M, E, σ |= ψ

The constant false is introduced as p∧¬p where p is any proposition from Π, and true is derived by ¬false. The other logical operators (∨ and ⇒) are defined in the usual way. The conversion from a temporal proposition to a static expression requires the evaluation of the static expression for the population L(σ(0)) at the required point of time. This will be further elaborated in section 3.4.

Historical information descriptors

History descriptors in ORC are meant to provide a language construct for reasoning in an historical setting about the application domain. For the purpose of this paper, it will be sufficient to make more or less direct transcriptions of the basic temporal operators. For this the syntactical construct history descriptor is introduced. Let H be a history descriptor, then the semantics of H are denoted as [(H)] :

[(always H)] G [(H)] [(X H)] X [(H)]

In addition we introduce the following abbreviations:

sometime H ¬ always ¬H H 1 precedes H 2 always((F H 1 ) U H 2 ) H 1 during H 2 always(H 1 ⇒ H 2 ) H 1 triggers H 2 always(H 1 ∧ ¬H 2 ⇒ X(¬H1 ∧ H 2 ))

The first rule will be a target for the educational organisation. The later rule states describes a trigger that, whenever the condition H 1 ∧ ¬H 2 is met, will respond by setting the condition ¬H 1 ∧ H 2 at the next moment. Some example expression would be: This latter expression, however, is misleading as it does not bring about a connection between lecturer nor course being set up and being lectured. In natural language, indicatives are used in most cases to make such references. We furthermore introduce:

x

[[D 1 PRECEDES D 2 ]] y (x [[D 1 ]] y) precedes ∃ z [z [[D 2 ]] y] x [[D 1 DURING D 2 ]] y (x [[D 1 ]] y) during ∃ z [z [[D 2 ]] y]

Indicative descriptors

The main idea behind ORC, as present in its early ancestor RIDL [15] is a functional, variable-less description of domain-specific properties (and queries). RIDL did contain a linguistic reference mechanism (the indicative THAT). In ORC variables have been introduced to handle more subtle referential relations that can not be handled by indicatives. Variables are special names that are instantiated once they are evaluated in a context that generates values for this variable. The environment is used to administrate the value of variables, in environment E, the variable v will evaluate to E(v). Some examples of the use of variables:

Lecturer:x being hired precedes x sets up Course Lecturer:x sets up c precedes x lectures Course:c

In this example, the expression Lecturer:x is a defining occurrence of variable x in which Lecturer has the role of value generator. The environment is used to administrate the variable-value assignment (see [10] for more details).

Information descriptors

The syntactic category to retrieve a collection of facts is called information descriptor. We will discuss the semantics of elementary information descriptors, and briefly summarise the construction of information descriptor (for more details, see [10]). Information descriptors are constructed from the names of object types and role type. The base construction for sentences is juxtaposition. By simply concatenating information descriptors, new information descriptors are constructed.

Information descriptors are interpreted as binary relationships, they provide a binary relation between instances of the population induced from the history. A population assigns to each object type its set of instances. Let n be the name of object type N and r the name of a role type R, then n and r are information descriptors with semantics:

M, E, σ |= x [[n]] y x ∈ L(σ(N )) ∧ x = y M, E, σ |= x [[r]] y (x, y) ∈ L(σ(R))

A single role may, in addition to its 'normal' name, also receive a reverse role name. Let v be the reverse role name of role R, then we have:

M, E, σ |= x [[v]] y (y, x) ∈ L(σ(R))

A combination of roles involved from a fact type may receive a connector name.

The connector name allows us to 'traverse' a fact type from one of the participating object types to another one. If c is the connector name for a role pair R, S , then the semantics of the information descriptor c are defined as: Elementary information descriptors can be composed into complex information descriptors using constructions such as concatenation, conjunction, implication, disjunction and complement. These may refer to the fronts alone or both fronts and tails of descriptors. For more details, see [10]. In this paper we will use:

M, E, σ |= x [[c]] z ∃ y [M, E, σ |= x [[R]] y ∧ M, E, σ |= z [[S]] y]

x

[[D 1 D 2 ]] y ∃ z [x [[D 1 ]] z ∧ z [[D 2 ]] y] x [[D 1 AND ALSO D 2 ]] y ∃ z [x [[D 1 ]] z] ∧ ∃ z [x [[D 2 ]] z] ∧ x = y

where D 1 and D 2 are information descriptors and x, y and z are variables. Some example expression would be: Note that the natural language likeness of the ORC expressions used in this paper can be improved considerably.

Rules

ORC has a special way of using information descriptors to describe rules that should apply in a domain. These rules can be used to express constraints and/or business rules. We will use the more general term rule for such expressions. These rules consist of information descriptors that are interpreted in a boolean way; i.e. if no tuple satisfies the relationship, the result is false, otherwise it is true. Some examples of such constructions are:

[[SOME D]] ∃ x,y [x [[D]] y] [[NOT R 1 ]] ¬ [[R 1 ]] [[NO D]] [[NOT SOME D]]

where D is an information descriptor and R 1 a rule.

Graphical representation

Using the ORC temporal dependencies can be formulated governing the behaviour of a domain. Currently, we are experimenting with effective graphical representation of some key classes of temporal dependencies. In [20] we have provided some examples using notations inspired by the field of workflow modelling [1].

! " Fig. 2. Lecturing example An important modelling construct is the notion of a life-cycle type. An example of its use is provided in Figure 2, which contains two inter-linked life-cycle types: Course Offering and Course Attendence. Each of these life-cycle types comprise multiple action types.

In the example domain, courses are offered to students. In offering a course, a lecturer starts by setting up the course offering. This is followed by the actual lecturing. After lecturing the course, the lecturer sets an exam. This exam is given to the students attending the course, after which the lecturer marks the exam papers produced by the students. Students attend the course by enrolling. After their enrollment they attend the course. Once the course is finished, they prepare themselves for the exam, which is following by the actual exam, leading to an exam paper.

Fig. 3. Life cycle types

In general, the life-cycle type typically involves multiple action types, and can best be regarded as an abbreviation as illustrated in Figure 3. The temporal dependency between x and y is defined as follows:

x → → S y

x being act of S PRECEDES y being act S

The enrollment by students in a course should take place during the setup phase of a course. This is enforced by means of the temporal subset constraint from the Enrolling action type to the Setting up action type. The connection between the temporal subset constraint and the Course Offering life-cycle type type signifies that the temporal subset constraint should be evaluated via this object type. In general, the semantics are expressed as: x ⊆ τ y

x DURING y. In the case of Figure 2, we have specified a join path, leading for example to:

Conclusions

The research reported in this paper is part of our effort to find a suitable generalised domain modelling method to model active domains. In this paper we have focussed on a strategy to apply ORM rigour in modelling active domains. In doing so, we have introduced the logbook paradigm as a history-oriented extension of the traditional natural language approach of ORM. To be able to define rules governing the behaviour of active domains, we have introduced the Object-Role Calculus (ORC). The semantics of this rule language has been defined in terms of Kripke structures. Finally, we have shown how ORM can be extended with graphical constructs, in particular life-cycle types, focussing on temporal dependencies in a domain. This notation allows us to also derive specific views on a domain focussing solely on temporal behaviour.