Extending the REA-DSL by the Planning Layer of the REA Ontology

Abstract

The Resource-Event-Agent (REA) ontology is a powerful and well accepted approach towards the design of accounting information systems (AIS). However, the REA notation-that is currently based on class diagrams-is not very intuitive for business experts. Accordingly, we aim at a REA domain specific modeling language that facilitates the communication between business experts and IT professionals. In previous work we defined the REA-DSL operational layer reflecting actual business events which "have occurred" or "are occurring". In this paper we extend the REA-DSL by the planning layer capturing what future events "are scheduled" or "are planned" by commitments. Now, our REA-DSL covers all basic concepts to describe a full accounting infrastructure. The REA-DSL may serve as a solid basis for generating a conceptual AIS data model-which is subject to future work.

REA-DSL: Business Model Driven Data-Engineering

“…database designers, system developers, information analysts, and AIS end-users) and showed the effectiveness of REA modeling in the area of AIS. However, we showed in [6] that our REA-DSL was even more intuitive and easier to comprehend than the original class based REA diagrams.…”

“…In previous work [5], [6] we created the REA-DSL designer tool which allows to model REA-DSL models. In a first step we extended the tool with property compartments and primary key tags.…”

“…As for the functional test, we took 32 REA-DSL examples created in [6], extended them by properties and primary keys, and run the automatic T4 text template mapping on them. This resulted in 32 relational models according to the REA ontology and its axioms without any semantic loss.…”

“…In previous publications [5], [6] we have formalized the REA-DSL by means of an underlying meta model and an intuitive graphical representation with dedicated stencils for all REA concepts. However, in its current state the REA-DSL still misses indispensable concepts required for the design of an AIS database scheme -i.e.…”

“…The Payment event is mapped (6) to an event table (E_PaymentEvent) in a similar way as the Sale event. As an additional concept, the single bulk resource Cash is directly added as column CashTypeName in the payment event table referencing the CashType and a CashTypeQuantity column storing the amount of Cash being exchanged.…”