Modeling for Understanding and/xor/etc Execution

Inspired by the discussion on “Executable models are models or programs? (and does it matter?)” on Modeling Languages.

Say, we have a list of a few thousand requirements, each nicely and precisely formulated e.g. like this*:
(1) p∈Personc∈Car drives(p, c)

From a purely logical perspective, we would be fine, since such sentences can be processed by e.g. a model checker in order to check its logical qualities etc. However, from a human point of view, such a list of requirements is impossible to understand, e.g. to discuss with the requirements provider. Therefore, describing the requirements in a restricted, easy to visualize language, i.e. modeling, is very helpful. For example, think of the above sentence as part of an ER-diagram. Thus, modeling solely for the purpose of understanding can have a value.

An even larger value could be achieved if the same models were used for understanding and generating (other models or code) or even direct execution. This is the big promise of various tool vendors and language standards. Due to the nature of their interests (perhaps) they appear quite reluctant towards certain practical difficulties that come with such an approach.

ER Tree and Org ChartThe following example is inspired by a software project situation I recently encountered. Say, we develop a database application that holds the organization structures of companies. They are all assumed as hierarchical, i.e. tree-like. So, firstly, we model a general tree structure as an ER model, as in (er-tree). For example, every r must have leafs l in L or forks f in F. Every such f must have further forks or leafs, until all leafs are reached (the 1:… cardinality guarantees that it’s acyclic). Secondly, we enrich this solely structural model with some business specific properties, as in (er-org). For example, the team entity type inherits the structural (tree) properties from the board, but not its business properties, so we have to put the latter into a subclass of R, Board.

Now, say, you are the requirements provider from the business side, how would you think of an org chart? Certainly, not like this. In general, it is definitely no bad idea to establish a common language of discourse between analyst and requirements provider, even if it is new to the latter. This is always a trade-off between effort of getting used to it and benefit for communication and thinking. However, models like the above clearly push it too far.

Thus, we have two concerns in the application domain, precision of processing towards execution, as well as ease of understanding towards the requirements provider. In simple development approaches, we can perhaps use a simplified model for the customer, and maintain the actual model manually ‘behind the scenes’. However, a sophisticated approach – as executable modeling – should be able to handle a consistent mapping between the two, as it does between business and architectural concerns – at least if it wants to go the whole (ambitious) way, from biz to exe.

So long

* If you don’t like the first order logic, you may think of it in natural language.


About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Requirements, Software_Engineering and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s