RE: 16 Mar. Conference Call notice

[Bob Haugen <linkage@interaccess.com>]

Christian Huemer:
>> >think of designing a database to store your models.
Bob Haugen:
>> Got one.  Some top-level classes include:
>>     Party
>>     Resource
>>     Transformation
>>     Exchange
>>     StockFlow
>>     Location
>>     Accountability
>>     Responsibility
>> 
>> >a model for models - that is what we call meta model.
 
Christian:
>bob, you missed my point.

I don't think so.  See below...

>think of providing a software tool, that supports business process
>modelling. so what diagrams should this tool support? and now
>design a database for this software tool. 

Christian, I *have* developed a software tool that supports business
process modeling, and the above are among the top-level classes.
They are also represented directly in the diagrams that the tool
supports; they are the objects you can drop on your canvas..
So yes, that *is* my database for business process modeling.

For examples, see:
http://homepage.interaccess.com/~linkage/ 
(just diagrams, no explanation, sorry.  This is my
personal web page where I share with friends.)
http://homepage.interaccess.com/~linkage/Which.htm 
(diagram in the middle of document, with some
explanation.)

To expand on the point, I am doing *business* modeling,
so I do not need very abstract classes like "Class" or "Entity".
I have only objects and relationships that would occur in a 
business.  However, I can easily develop re-usable templates
for whole industries, so that individual business modelers
within a company can start with a worked-out model of 
their whole industry instead of a few abstract concepts.

It is a different method of doing business modeling than
you may be accustomed to.
However, it is just as flexible as a model with "Class"
and "Entity", as long as you stick to business processes.
And it is much clearer and faster and easier to use.

Ok?
Bob Haugen