Take for example

Activity.m

type Activity : DerivedItem
{
IsLoop : Logical = false;

}

The type Activity inherits from DerivedItem, which is nothing else than an artificial type which has nothing to do with the BPMN inheritance hierarchy.

Instead in BPMN Activity is a subclass of a FlowObject. So what has been done?

Activities : Activity* where
item.Id in FlowObjects.Id;

We have two extents, one for Activities, one for FlowObjects. The have hooked them up by id. Manually!!!!!

Is that a good idea? It makes all impressions of a workaround. Why aren’t they hokked up generically, if Olso had inheritance on the extent level – which is done anyway all over the model files.

It is no solution to merge every attribute of Activity into the extent Activities. There is no use of scattering the FlowObject Aspect (i.e. the fields, that belong to each and every FlowObject) across different extents. That would destroy polymorphy – i.e. getting all FlowObjects with one select.

So the solution ImhO chosen is somewhat smart. The only thing I complain about why there is the need to manually hook up the tables. This should be a built-in feature and there should exist a built-in member collection “super” for this kind of construction. Also there should be a built-in view to get all of an Activity (including the FlowObject aspect) at one select (if needed). (By the way today it is not even possible to construct a join view manually – I did not get it managed. So all the logic has to be in the client coding, which ImhO is bad design.)

I can’t think of a reason why this should not work. But for this M has to learn a little bit more. May be a solution is to better integrate the Entity Framework (EF) with Oslo.
[ad]

After the installation you find the models here:

C:\Program Files\Microsoft Oslo SDK 1.0\Models\Business\BPMN

One could discuss, if the chosen format is the best way to represent BPMN, but at least it is interesting to know and to think about.

It is only a beginning. It is an old BPMN version (BPMN 1.1 I believe), it are only the table structures (MSchema), not Grammar (MGrammar) and no example models (MGraph).
Although BPMN should be modeled using inheritance, the BPMN MSchema does not make use of inheritance. If you read into Microsoft Olso you will find, that in MSchema there is actually some inheritance, but only limited. There are types in MSchema and extents, which are storage locations or database tables, more plainly said. While the types can inherit fields from suptertypes, extents make no use of any inheritance structure. That is if a extent is defined using a subtype, then all fields from all supertypes are also in the extent. Of course that is not, what one wants, because then the supertype information is scattered across many tables, which destroys polymorphy. On their homepage the development team argues, that MSchema can not support inheritance, because the relational paradigm does not. But that is not a very convincing argument, because as you can see in the BPMN models of Olso, they found a canonical way to deal with the logical inheritance by splitting the tables and defining a foreign key relationship. So for me there is not really an argument why they do not offer this method as a resolution of the inheritance problem in MSchema, so that BPMN and other metamodels can be offered in such a way.

[ad]