Database Reference
In-Depth Information
there is nothing more to support. Using ORM, one (only) has to decide which actions will
be supported and how, and which will not.
As a third contribution to ORM, DEMO distinguishes between the dynamics of the
BS and AIS. Every C-fact may serve as an agendum (singular of agenda) to be dealt with
by an actor. Typically, an actor disposes of a set of agendums, or agenda. In dealing with
an agendum, one or more new agendums may be generated. This constitutes the dynamics
of a BS. The dynamics of the AIS are basically
asynchronous
with respect to the dynamics
of the BS. They coincide only when products of the AIS are declared to count as acts in the
BS (like we have seen for an automated stock control system). In all other cases, the C-acts
must be made known to the AIS.
Consider for example the borrowing of a library topic. This transaction of type T04
starts with a member request. The resulting C-fact “requested” is entered in the AIS. At the
same time, a new instance of Loan is created by the AIS, including the facts that existen-
tially depend on it (“the membership of L is M” and “the topic copy of L is C”). Ideally, the
recorded time stamp of the C-fact is the real time (valid time) at which it was created in the
BS. It is, however, common practice to take the time of entering into the AIS (transaction
time) as the time stamp. This usually causes no problems since the order in which the steps
of Figure 10 are entered in the AIS is easily controlled by the AIS. For example, a promise
fact is rejected by the AIS if there is no corresponding request fact. If the transaction suc-
ceeds, the terminal state is the C-fact “ac” (accepted). At the time of establishing this fact,
the production fact becomes existent. From that time on, the loan really exists in the BS.
This defi nition is easily implemented in the AIS: as soon as the accepted fact is entered, the
loan exists (there is only the unavoidable time delay with the BS).
CONCLUSIONS
This chapter outlined the essential features of the DEMO and ORM approaches to
conceptual modeling, then explored various potential benefi ts of synthesizing both methods
to achieve a more complete and productive approach to business and information system
modeling. As both methods treat fact types as fundamental, it seemed judicious to use their
fact models as a basis for integration. With this in mind, a basic library application was
modeled in both DEMO and ORM, and then commonalities and differences between these
models were examined.
As regards the benefi ts of supplementing DEMO with ORM, it seems clear that ORM
offers several advantages for fl eshing out DEMO state models into more comprehensive,
formal data models that can be automatically transformed into application code. In particular,
ORM models can extend DEMO state models by providing identifi cation schemes, addi-
tional constraints, explicit and granular coverage of relevant temporal aspects, and formal
derivation rules, as well as focusing on those features of actual interest to the automated
information system. In addition, various ORM modeling procedures may provide additional
assistance in the task of constructing models.
On the other hand, using DEMO in conjunction with ORM provides a more compre-
hensive modeling approach that goes beyond ORM's data-oriented perspective. In particular,
DEMO provides a clean integration of static and dynamic aspects of business modeling,
offering high level, implementation-independent ways of modeling the essential business
