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
