If you ask people what concepts come to their mind when they think of modelling in software engineering, you usually hear things like “UML”, “Model Driven …”, “Autosar”, etc. Now these are big comprehensive topics, that one cannot handle without having spent some time getting into them.

In contrast, to me, modelling is a way of thinking, based on abstraction, a quite natural skill, and thus is also a quite natural thing to do for every human being, like when you’re abstracting the shape of the screen you’re just looking at as rectangular or using the word “screen” as a concept.

I do not say that seeing modelling one way is better than the other. Both are good to have. I see it like this: There is a modelling at the low-end, that all humans use every day a million times, and there is modelling at the high-end with comprehensive concepts like UML, MDD etc. Perhaps approaching the modelling topic from the low-end would make it easier accessible for most software practitioners.

Have fun
|=

PS
Compared to what has been published on UML, MDD etc, we still know very little about practical abstractional thinking in models, don’t we?

#ModellingFoundations
Formal foundations of modelling and formalisation of modelling languages:
30 Nov: Reading Model Semantics and Mathematical Logic thx to @seidewitz
20 Jul: #WilfridHodges Math foundations for Models #forum #discussion by TY
18 Apr: brief update of my readings list: #ModelTheory basics and related topics

#CognitionModelsSystems
On the trinity of model, world, and information system:
16 Dec: An Architecture model for Cognition, Information Systems as well…
9 Nov: Three Spaces for Entities and Models of Applications by @MountriverTY
2 Feb: RT @alex_lagarde: New post : Intent Discovery – Part 1 : the intents behind softwares

#BusinessAnalysis
From the trenches, for the trenches:
10 Oct: general purpose language vs domain specific lang. – always a trade-off? MoLa #opinion
16 Sep: #blog True story of a MDA paradox via @vhanniet
23 May: New blog post: Lazy modeling?! #li #v
17 May: The Continuum of Social BPM #blog #comment
20 Apr: Software Modeling Forum post: I just discovered that I’m actually doing QVT the whole day (in some way) MoLa

#modelpractice
Some more or less deep thoughts I produced during the year:
20 Dec: If “engineering is producing an artifact to cost”, then how can modelling contribute to it? Complexity Aware Modelling #blog
29 Apr: #blog Completeness is about obtaining an understanding the structure of the domain. Else it is just collecting facts. Are your Requirements complete?
20 Jan:Why finiteness counts #logic #computation

#Readings
Mainly about modelling and related topics:
21 Dec: @PooyanJamshidi some bookmarks for further reading: #ComputationalThinking
4 Oct: Cultural Preferences for Formal vs Intuitive Reasoning This is true for #reasoning, but for #abstraction as well
20 Sep: Reading: Thalheim (2010) Towards a Theory of Conceptual Modelling “Abstraction and[...]are well understood” #disagree
31 Jul: Reading Russ Abbott’s Emergence Explained #Epistemology #Abstraction Implications for Modeling …?
24 May: @kentpalmer enjoyed the Dias & Models part. does Presence Identity Truth Reality refer to a specific definition? paper
17 Mar: this is very much about abstraction and modeling (although not explic. mentioned): #2011TED

#Conferences
More and More people write short reports about conferences they attended. Certainly a commendable trend in 2011:
9 Nov: #er2011 Slides of keynotes and tutorials ER 2011
2 Nov: slides of DSM workshop at #splash2011 DSM 2011
25 Oct: Finally, my report of day 1: http://bit.ly/tqHuFu #GOTOAmsFinally, my report of day 1: GOTO 2011 #GOTOAms
25 Sep: Report from Graph Drawing « 0xDE: GraphDrawing 2011
5 Jul: RT @softmodeling: ICMT/ TOOLS/ SC 2011, take-away from an industrial attendee TOOLS 2011

#Science
Underestimated: the role of understanding in science:
3 Jan: people only get academic credit for creating new knowledge and not for explaining existing knowledge better link
7 Jan: “The act of discovery was not complete for Richard Feynman until he had taught it to someone else.”

#FreeStuff
Mainly books on misc. topics:
26 Dec: #INRIA An awesome free book by +Serge Abiteboul, … Web Data Management
26 Dec: Now our eBook on Use-Case 2.0 – Agility @ Scale is available for free download.
27 May: My venture group just published a free book on Agile Retrospectives
25 Apr: #book #online Fundamentals of Algebraic Graph Transformation Ehrig² Prange Tänzer 2006 #Springer

#MyFavBrainTeaserIn2011
28 Nov: A regex that tests numbers for prime numbers: puzzle

#Finally
So, one special thing about 2011 was certainly:
1 Jan: 2011 is also the sum of 11 CONSECUTIVE prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211 [woot]
2012 will have to try hard to keep up with with so much mathematical witt. However at least we will have an important 455th birthday in 2012:
18 Feb: Equal sign (“=”) was invented in 1557 by Welsh mathematician R. Recorde to replace “is equal to” in his equations.
And of course the other (not less important) anniversary:
18 Feb: Excellent mini-bio The Life of Alan Turing just appeared on YouTube: #Turing Worth a watch!

Thats it mainly for 2011. Have a nice 2012!
|=

#PS
25 Jul: RT @kentpalmer: Periodic Table of Irrational Nonsense #fun
24 Jun: RT @amazedsaint: “Light travels faster than sound, that’s why some people appear bright until you hear them speak” #quote
14 May: With the greatest respect, an essential guide to what the British actually mean when they say…. dictionary (pic)
10 Apr: sitting in cafe doing #ModelTheory on floor above a #ModelCasting going on
21 Jan: @softmodeling I’m a modeler – I can’t see any benefits in programming. just bugs, bugs, bugs

If “engineering is producing an artifact to cost”, then how can modelling contribute to it?

By uncovering complexity, since complexity is what causes the cost! Actually, from a management point of view, cost, and thus mainly complexity, is one of the most interesting attributes of a model. Here, with ‘complexity awareness’ in real world software engineering, I do not mean, computing the exact complexity class of a model (may it be descriptive or algorithmic). Rather it means being able to recognise points where complexity ‘suddenly’ increases by ‘just a little bit’ more of functionality (like the undelete function in the state machine from the last post) This already can proof very beneficial, since finally controlling* complexity means controlling cost.

|=

*where ‘controling’ can mean all sorts of decisions, like refusing the feature, increasing the budget (a priori), considering workarounds, …

Complexity aware people are able to recognize complexity, and regard it over things like size. Why? Because, we’re in the software world. Surely, in the physical world this might be different. Speaking from experience, an analyst can proof very beneficial, if she is able to address complexity issues early in analysis. Then of course ‘addressing’ complexity can lead to anything: accepting it, postponing it, checking it, ignoring it or whatsoever. Important is, the earlier you do it the more options you have.

For detecting complexity in software analysis, modelling is an essential tool, since by definition modelling is about structure (and not about languages, in the first place, as one might think by some of the literature). In the end it’s about having an eye for structure, i.e. to say things like: “ok, mind maps look quite intuitive, but in the end it’s just a taxonomy”.

Thus creating models in analysis should always go along with awareness of their complexity issues.

Have fun
|=

PS
notice that this is about complexity of business logic, and that technical complexity is a different issue. See therefore Part I
PPS
of course balancing business and technical complexities is far from trivial, and is the actual mission of design, as nicely described by Bertrand Meyer here

PS
*If he says ‘yes, I’ve head that a 1000 times’, he’s an educated structural scientist ;o)

Recently was asked to write a little program for the 8-Queens problem. So I wrote a highly scalable, reliable and maintainable app server with a super easy and sexy user interface, all written in an ultra-portable and adaptable language and style, and the solution looked like this:
.
.

8-Queens problem ‘technology driven’ solution.

For some reason my client wasn’t satisfied with this solution. Then I discovered that beyond the actual technology there is something called business logic*, and – most surprising – it was not trivial!

If the above sounds familiar to you, you might agree that business logic is what software development is mainly about in the end, and – yes – it has complexity! Now you can implement the business logic and finally wonder how slow your software runs, or how long it took to implement, or how expensive it became, or alternatively you can try to deal with complexity before you have to bother with its consequences.

Adressing complexity issues in business logic early, that is what ‘Complexity Aware Modelling’ is all about. (more to come …)

Have fun
|=

* or simply ‘functionality’ or …

PS
Related texts:

• “… all of the pure technical features are not the nature of the applications for enterprises”, by TY here
• “What more do we know when we know the complexity of a certain part of UML?”, self

What does Software Modelling – a Rhino’s Perspectice tell us? It is about Modelling, some of its underlying principles and how they relate to practical experiences. To me things like this make nice starting points for thinking and talking about principles like blind spots or redundancy in modelling. However, is this already enough to constitute a Theory of Modelling?

I would argue that the Rhino example is not (part of) a Modelling Theory, solely because it lacks rigour and relevance:

Rigour: When we inspect e.g. the blind spot principle a bit closer, it soon becomes quite ambiguous. We also would like to get rid of all example-specific details. Thus a more rigorous definition would be helpful, that imho should be done on the level of formal logic as far as possible.
Relevance: Modelling is about extracting the most important bits first. Thus a Modelling Theory seen as a model of modelling must prove its relevance. Quoting some author’s experiences might be a first step, although broadening this experience base is highly necessary in order to take relevance seriously.

To me a structure of rigorous and relevant principles is necessary and sufficient to constitute a Modelling Theory. All other things, like processual, behavioural, ontological or linguistic considerations, are optional.

Have fun
|=

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)
|=

Their Framework for Research on Conceptual Modelling comprises four elements:
“1. A conceptual-modeling grammar provides a set of constructs and rules that show how to combine the constructs to model real-world domains. For example, the entity-relationship grammar has the constructs “entity” and “relationship”. A rule in the grammar specifies that two entities can be associated only via a relationship.
2. A conceptual-modeling method provides procedures by which a grammar can be used. Usually one major aspect of a method prescribes how to map observations of a domain into a model of the domain. Ideally methods provide procedures to identify instances of all phenomena that can be modeled via a grammar.
3. A conceptual-modeling script is the product of the conceptual-modeling process. For example, the scripts generated by the entity-relationship grammar are entity-relationship diagrams (ERDs). Each script is a statement in the language generated by the grammar.
4. The context is the setting in which conceptual modeling occurs and scripts are used. … [e.g. stakeholders]“ see the complete paper here.

Let me explain my view by referring to economics. On one hand there is the macro economical perspective, mainly analyzing “the production, distribution, and consumption of goods and services” of economies empirically. On the other hand micro economics takes a structural approach, by studying models of game theory and others.

Analyzing production etc. of goods and services alone is ‘just’ some social science. What makes it economics, is that they are exchanged in a ‘cooperative’ way, as defined structurally by micro economical theory. Similarly, analysing grammars and behaviour alone is ‘just’ some (still valuable) research on engineering. However only based on a >structural< theory of modeling it will become research on modeling.

How might such a modeling theory look like? What might be its formal foundation, corresponding to game theory in economics? Perhaps Finite model theory? (as it has already done quite a good job as foundation of database theory)

To be precised further …

“Are these requirements all that exist, or just all that your expert could think of?” If someone reacts heavily surprised here, he/she is definitely not an analyst. This is about completeness. Completeness is a property of requirements an analyst is definitely aware of (doesn’t mean that his/her requirements have always to be complete). Completeness is one among the characteristics of software requirements specs of IEEE 830:

• Correct
• Complete
• Consistent
• Unambiguous
• Rated
• Maintainable
• Testable
• Traceable

“Great! Now can I measure these characteristics in order to produce some pretty figures for my management?” I don’t think so! (try to proof me wrong, if you like) Therefore, the subject of requirements is much too complex.

“So, are these characteristics good for sth at all?”
The point is, that they provide a valuable basis for communication, like for asking questions like the introductory one, in order to create an awareness of what makes good requirements at all. For example, have you ever tried to discuss the traceability of your requirements with so. who isn’t aware of this concept at all? Such discussions are completely useless, unless you have a common basic understanding of what desirable properties of requirements are.

This way IEEE 830 can help turn discussions about the quality of requirements from completely useless to ‘just’ difficult.