Software Modelling – a Rhino’s Perspectice

Got carried away by this little picture, I recently found in a tweet, and its correspondence to modelling. So I started fooling around a bit:

Lets consider painting a picture as software modelling, then we have (1.) a viewer’s blind spot since the horn hides a part of the view. We have (2.) redundancy, since the horn always looks the same. Now, we can subdivide (1) into blind spots caused by (1a.) the landscape, like a hill that hides a tree, and blind spots caused by (1b.) the viewer (rhino). (1a) can be handled by taking multiple perspectives (classic modelling trick) but how to handle (1b)? Any systematic ideas?

In the case of a non-rhino modeller (1b) could be a pre-assumption, i.e. it’s not part of the world, but part of the picture. I must admit, I recently really had such a case in a project. In process modelling I assumed that every regular step has to undergo a 4-eyes-check, what was true for all other processes so far, but not for this one. So I had a 4ec step in the process model, an extra status in the state machine, dedicated information in the data model etc. No bad idea to ask the domain expert from time to time ;o)

But wait, is this really an example for the rhino perspective? Clearly it’s a blind spot, but is it redundant in the above sense as well? Hmmm, should think about it …

Have fun (I had)
|=