The Model is not the Modeling

Some reflections on the work of Dirk Siefkes on formal methods and small systems
Part II (II)

The following seems of particular interest for formal results, since quite often formalism is used to replace understanding.  However, if formalizing is just one kind of formulating, this can be extended to any kind of result.

Lively processes behind strict results
Before formal results can be obtained, there are non-formal processes of creation.  Therefore, it takes several steps (back, forth, aside …), as well as many human factors such as intuition, creativity and ideas, to finally get to the result.  Often these  steps and principles are treated as secondary, when the focus is too much on the result and too little on what enables people to reach it. This is briefly illustrated below.

Model vs. modeling in software development
In software development, models of architecture are the result of a decision process, as well as requirements models arise from bi-directional communication processes.  This is about outlining ideas,  making suggestions, developing alternatives, presenting and prioritizing things etc.
Now, when talking to modeling tool vendors or reading their materials, they are mainly about features, features, features and, very little on the (various) ways in which one may work with the tools in a ‘real’ project environment.  Quite often they merely seem to implement languages or norms like UML or IEEE 830 (for requirements).  Thus many tools seem better suited for model documentation than for modeling.

Proof vs. proofing in mathematics
Inside mathematical proofs, one finds a great deal of human creativity and principles which contain an understanding, far beyond pure formalism.  From my experience as a teacher and a student in general, I strongly believe that principles should be central to every kind of course, since principles are the only thing that can be understood.
Although math courses and materials today already contain a lot more than just formalisms, principles are still not treated as the central thing.  It’s still formalism, with some explanations or an introductory chapter added, instead of explaining the principles in the first place and, in textbooks, merely indicating the proof (or the application?) in the form of exercises.


  • Are these upcoming Social BPM tools still only model documentation tools, with all their collaborative features just added?
  • What about a common math lecture for mathematicians and engineers (on the principles only), just with different homework (proofing or applying) … ?

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in 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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s