This project aims at producing an executable version of the Resource-Event-Agent ontology. This executable version is built with the MERODE methodology, which guarantees coherence between class and state diagrams. Where the MERODE CASE tool supports generating Java code from conceptual diagrams, our aim is to produce fully REAcompliant blockchain code with this methodology. This project's main innovation is the use of existence dependency and event propagation to model increment and decrement as fundamental stand-alone concepts that simultaneously a ect economic resources, event, agents and the nature of the stock- ows, participations and dualities between them. The second { and most probably the most important { contribution of this paper is the formalisation of the REA axioms as executable nite state machines. In the future, both of these innovations are believed to contribute to the reliability of a generic semantic blockchain technology for both the nance and logistics domain in both the traditional and the sharing economy. As such it is expected to promote both traceability and accountability in value networks and supply chains.
MERODE Blockchain Model Driven 1.1
Blockchain is { by some { believed to be the silver bullet to solve almost any issue in the world. The blockchain technology is particularly known for it's applications in nance (e.g. Bitcoin), although it's impact on the non- nancial economy (e.g. logistics) is also growing rapidly (e.g. Provenance3). Where blockchain has an impact in both nance and logistics, the full power of the technology has to the best of our knowledge not been realised in both domains simultaneously. What is needed is an approach that can link nancial and logistical processes to each other, to promote transparency, fair trade, and ght money laundering, counterfeit and the funding of terrorism. 1.2
Introduction to REA & REA2
The Resource-Event-Agent (REA) ontology [
Content of this paper Section 2 introduces the methodology of this project, discussing the model mediated transformation of the ontology to blockchain code in subsection 2.1, and model coherence checking in subsection 2.2. The paper concludes with a summary of the contribution (i.e. subsection 3.1), an overview of the progress (i.e. subsection 3.2), and a discussion of the limitations (i.e. subsection 3.3) in section 3. 2 2.1
This project aims at building a truthful implementation of the REA ontology in
blockchain technology. To this end a Model-Driven Architecture (MDA) [
4 which is a formal subset of class diagrams (FSM)). This projects considers these static and behavioural models to be a single PIM as the MERODE methodology explained in section 2.2 guarantees the consistency of the EDG and FSMs. Finally, the PIM is implemented as a platform speci c model (PSM), which is suited for a chosen technological platform. The JMermaid5 CASE6 tool, which is used for building the MERODE compliant PIM in this project, is able to generate Java code, where Hyperledger Fabric7, which has been chosen as the blockchain technology platform for this project, is used for building the PSM codes (i.e. Hyperledger Fabric code, composed of CTO, JavaScript, acl). In absence of a Hyperledger Fabric code generator in JMermaid, the Java code is used for validating the run-time behaviour of the model and Hyperledger Fabric code compliant with the Java code and is produced manually. Figure 1 summarises the project approach.
CIM
Resource-Event-Agent Ontology PIM
Merode Computer Aided Software Engineering PSM
Hyperledger Fabric (Java) The MERODE methodology relies on the concept of existence dependency for its static conceptual model (i.e. the EDG).
\The existence-dependency relation is a partial ordering on objects and object types which is de ned as follows: Let P and Q be object types. P is existence dependent on Q if and only if the life of each occurence p of type P is embedded in the life of one single and always the same occurence q of type Q. p is called the dependent object (P is the dependent object type) and is existence dependent on q, called the master object (Q is the master object type). " [8, p.83-84] \A more informal way of de ning existence dependency is as follows: If each object of a class P always is associated with minimum one, maximum one and always the same occurrence of class Q, then P is existence dependent on Q. In terms of life cycles, existence dependency means that the life of the existencedependent object cannot start before the life of its master. Similarly, the life of an existence-dependent object ends at the latest at the same time that the life of its master ends."[8, p.83-84]
6 Computer-Aided Software Engineering 7 https://www.hyperledger.org/projects/fabric
For example, \a hotel customer and a room object will have to be created before a reservation object by that customer for that room can be created, and reversely, due to referential integrity rules, the reservation object will have to be terminated before life of the customer or the room object can be ended." [8, p.83]
Next to existence dependency, MERODE relies on event propagation to check the coherence of EDG and FSMs.
The event propagation rule implies that if P is existence dependent on Q, then Q participates in each event in which P participates. In other words, each event marked for the dependent P must also be marked for the master Q. This can be explained as follows. When an existence-dependent object is involved in an event, its master objects are automatically involved in this event as well. For example, if a copy is created, the corresponding title is (implicitly) involved as well, as we now count one more copy for this title. Similarly, a state change of a loan, e.g. because of the return of the copy, automatically implies a state change of the related copy and member: the copy is back on shelf and the member has one copy less in loan. By marking each event type the dependent object type participates in also for the master object type, all implicit participations are made explicit, and as a result, all possible places for information gathering and constraint de nition are identi ed. For example, the borrow method of the class MEMBER is the right place to update the number of copies a member has in loan and to check a rule such as a member can have at most ve copies in loan at the same time. The borrow method of the class COPY is the right place to count the number of times a copy has been borrowed. At implementation time, methods that are empty because no relevant business rule or e ect was identi ed can be removed to increase e ciency. [8, p.115] 3 3.1
This project aims at producing a platform independent model that formalises the REA ontology8 and allows for the generation of executable code with the help of the MERODE methodology and JMermaid tool. This project's main contribution is the formalisation of the REA ontology using existence dependency and event propagation to expose increment, decrement and duality as the behavioural fundaments of the REA ontology. A second contribution of this paper is that it formalises the REA axioms as executable nite state machines. 3.2
Progress This project was launched with a workshop at CHUO university (Japan) in March 2018 and continued with a workshop at universit Saint-Louis - Brussels (Belgium) in December 2018. The approach was developed at the workshop in Japan together with a rst generation of PIMs (i.e. a set of coherent EDGs 8 which served as a computation independent model and FSMs) in JMermaid and a rst generation of PSMs in Hyperledger Fabric. A second generation of PIMs was presented and discussed at the workshop in Brussels and a third generation of PIMs and a second generation of PSMs will be shown at the VMBO workshop in Stockholm.
Limitations Currently, the JMermaid tool only allows for generating Java code. Consequently, the generated code was used to validate the EDG, OET and FSMs, testing the behaviour of the generated Java code. After this validation, blockchain code (i.e. Hyperledger Fabric) exhibiting the same behaviour was written manually. Full compliance with the REA literature still needs to be validated, and mappings with e3value and DEMO might be useful.
We would like to acknowledge Jun Azumi, and Satoshi Shimiza for their contribution at the workshop held at CHUO university (Japan), and Geert Poels, Monique Snoeck, and Graham Gal for their contribution at the workshop held at universit Saint-Louis Brussels (Belgium), and Hugues Dumont and Geert Poels for sponsoring the workshop in Belgium.