[mdt-sbvr.dev] Fw: A proposal for modeling Concepts and related aspects

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

***********************
Warning: Your file, sbvr.zip, contains more than 32 files after decompression and cannot be scanned.
***********************

Over the last few months, I've had a summer intern -- Andrey Soares -- implement the proposal that I made back in May (attached, below). His work is attached in a zip file that contains: (See attached file: sbvr.zip)

* .ppt charts describing our design
* .doc file describing how to install and use his code
* two examples: sbvrModel.java and ECommerceModel.java
* UML model of his design: sbvr.emx, created using RSA v7
* corresponding sbvr.ecore EMF model
* source code and corresponding binaries, contained in internal zip file called completeSBVR.zip

This implements the following aspects of the SBVR Meaning and Representation Vocabulary using the "EMF extension" approach summarized below and in Andrey's charts:
* Meaning
* Concept
* Noun
* Fact Type
* Characteristic
* _expression_
* Text
* Representation
* Definition
* Informal Definition
* Dictionary
* Conceptual Schema

The advantages of this approach include: (a) simpler EMF model than the "conventional" approach, resulting in fewer objects to be managed by a tool; (b) elimination of 1 metamodel layer when implementing SBVR on top of EMF; (c) instances are managed as individual objects, which should simplify things if/when someone wants to implement an instance-level reasoner.

This technique saves domain vocabularies in a file called <name>.sbvr and instances in files called <name>.xml.

I suggest that this is the way to go for the M&R implementation. Comments solicited.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
----- Forwarded by Mark H Linehan/Watson/IBM on 08/20/2008 09:26 PM -----

Mark H Linehan/Watson/IBM

05/16/2008 03:23 PM

To	mdt-sbvr.dev@xxxxxxxxxxx
cc
Subject	A proposal for modeling Concepts and related aspects

My past work on a prototype SBVR tool has been implemented with what I'm calling here the "conventional approach" to modeling in EMF SBVR's "concept" and related features.  This "conventional approach" is basically what's been proposed in this MDT-SBVR work, so far.   My experience is that representing an SBVR vocabulary this way produces an explosion of instances of EMF classes.  This note proposes an alternative design.  The advantage I see in this alternative is a simplification of the EMF model of SBVR, and a substantial reduction in the number of object types and object instances that an SBVR tool must manage.

I've attached several images of UML diagrams.  The first one shows a "conventional" UML model of part of SBVR's metamodel.  This is nowhere near complete, and includes some minor simplifications -- but it shows the idea.  Each concept in SBVR becomes a class in UML and EMF.

The next image shows a fragment of an SBVR vocabulary that defines concepts "driver", "car", "driver owns car", and one instance of each.   As you can see, an SBVR tool done this way has to manage a lot of separate object instances.

The third image summarizes the alternative approach that I am proposing..  The idea is to implement some of the "meaning" aspects of SBVR as extended forms of the corresponding EMF classes.   For example, SBVR's "concept" would inherit directly from EMF's EClass, and add attributes and operations to support SBVR aspects such as "Representation".  In a sense, we would extend EMF itself to represent the equivalent concepts in SBVR.  We would implement other SBVR concepts (e.g. "_expression_") in the conventional way.

The final image illustrates how the same "car", "driver", "driver owns car", and instances thereof would look using my proposed alternative ("EMF-extension") approach.  (There's an instantiation connection missing from the diagram, between the "Driver owns Car" link and the "Binary Fact Type" class.  This is because UML doesn't support the kind of instantiation that I am trying to show.)  

Imagine a user of an SBVR tool creates a new vocabulary entry "Driver".  The tool would represent "Driver" via a dynamically-generated "Concept" (i.e. an "EClass").  The tool would also create a "Representation" and an "_expression_" as instances of predefined EMF classes.  It would use operations on "Meaning" to create the link from the "Driver" Concept to the new "Representation".

Now imagine the user creating the fact type "Driver owns Car"..  The tool would dynamically create a "Binary Fact Type" (i.e. an EMF "EReference") between "Driver" and "Car".  It would then create the "Driver owns Car: Representation" instance and corresponding "_expression_" instance and invoke operations on the "Meaning" to associate the "Representation" to the "Binary Fact Type".

Now imagine further that the tool user creates an instance "Bill" of "Driver", an instance "Car123" of "Car", and an instance "Bill owns Car123" of the fact type "Driver owns Car".  The tool would create instances of the "Driver" and "Car" EClasses, and would link the instances to represent "Bill owns Car123".  As you can see in the image, the result has many fewer object instances than above.  By directly representing some SBVR concepts in EMF, this approach eliminates a modeling level and drastically simplifies what a tool has to do.

Note that the model has several instances where associations cross between modeling levels: "Car" and "Driver" would be realized as regular EClasses in EMF.  "Car:Representation" is an instance of a "Representation" linked to the EClass "Car".  Similarly, the instance-level link "Bill owns Car123" is connected to the model-level information captured in the corresponding Representation.  We would handle these cross-modeling-layer connections via extensions of EMF implemented as attributes and operations of the interface "Meaning".

In this example, the instance link "Bill owns Car123" models an Atomic Formulation that is based on "Driver owns Car" and is bound to the individual concepts "Bill" and "Car123".  Of course, AtomicFormulations can also bind to expressions and variables.   Expressions are just instances of an EClass "Text", so they fit into this scheme easily.  Similarly, SBVR variables should be represented as instances of an EClass "Variable".  That is, each Quantification or Projection would introduce or project an instance of "Variable" that participates in one or more Atomic Formulations.  Our implemention of  "Variable" would have to "know" how to model all the Atomic Formulations (ie EReferences / ELists) in which Variable instances participate.  That may be an interesting programming challenge, but should be doable.

There's much more to this idea, but I think this captures the basic scheme, and illustrates the significant reduction in the number of instance objects that have to be maintained by an SBVR tool implemented this way.  Of course, there is a cost: this involves an extension of EMF itself.  But there are potential further advantages:  EMF has no way to model n-ary fact types and objectifications.   If we are willing to extend EMF, then we could add also support for those and further simplify an SBVR tool.

Comments?

--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx

Attachment: sbvr.zip
Description: Zip archive