1+1 of modeling

Ericsson has been a big supporter and user of modeling techniques – a large share of our 3G systems were developed using modelling tools. Myself, I spent a fair amount of my time at Ericsson using modeling to write code.
Recently I was wondering quite much about what modeling really brings to the table. Is it higher programmer productivity? Efficiency of resulting code? Portability? All of these at the same time? What can modeling offer that you won’t find in competing technologies?
Modeling inherently means that a graphical environment is used to describe the system at various levels of abstraction. I believe this is one of the major benefits of modeling: it’s much more easier to grasp the high level structure of a complex system from a diagram that is integral part of the system itself than from reading actual code or relying on likely outdated descriptions. This quality of modeling is hardly ever disputed – and for me, it was always the most imediate benefit. Obviously, it positively impacts programmer productivity: as the learning curve is easier to climb, programmers are quicker at getting at the point of producing code. But once there, can modeling help them further? Not really. Further benefits come from using higher level action code languages – something that can be easily matched by textual languages.
What about efficiency of target code? We were able to generate quite efficient code that basically matched the performance of hand-crafted code. But, here’s a little secret: much of this efficiency is down to two factors. First, programmers still wrote substantial amount of action code that is preserved as such; but, more importantly, we actually used a specific application model – the actor model – best suited for the type of spplications we were developing. Modeling obviously helped with generating most of the default code (state machine, message passing etc), thus the programmer was able to focus on the actual problem rather than implementation details.
Portability. Well, again, modeling in itself won’t help you, sorry to say that. The programmer has plenty of opportunities to ruin it when writing action code – unless the action language is preventing it. Which brings us back to the need for high level languages, which is again orthogonal to modeling itself.
So, what’s in it for modeling? At the end of the day, it’s the possibility to visualize software in different ways that reduces dramatically the cost of grasping and reasoning about a complex system. The other properties ascribed to modeling – efficiency, portability, some aspects of productivity, automatic code generation – are actually the results of using high level, domain specific approaches that hide non-essential details in the run-time system and the compiler; however, combining these with modeling provide a powerful combination.

2 Responses to “1+1 of modeling”

  1. Mats Brorsson says:

    Aren’t modelling supposed to help out in bridging the gaps between requirement specification, design, implementation, test and maintenance so that you actually know that you are working on the same system in all these phases? A graphical interface can be used without having a model abstraction behind it.

  2. Vajdi says:

    Well, requirement to model transformation is still far from reality (and it will take a looong time to materialize). As for testing, you can’t use the same model for code and test cases, as that inherently means you cannot detect faults. You need a decoupled model for testing.
    Coupling design and implementation is real and that’s what I highlighted when saying that you can visualize the system at different levels of abstraction.