Models – theory vs. reality

In a previous article, I have discussed the power of models in software engineering. In theory, using models solves the most fundamental problem in software engineering: the communication between business (e.g. client, project manager, business developer) and engineering (e.g. developers, testers). Additionally, theory says that creating representative models unleashes a tremendous automation potential. However, in practice, models are usually seen as a burden by developers. In this article, we discuss this discrepancy between theory and reality, coming up with a description of the underlying problem as well as potential solutions to bring theory into reality.

Theory VS Reality

In this section, I present what is in my opinion the current theory and reality of models.

Theory: In a software project, you can use the visualization power of modelling tools to create a common understanding of requirements between all stakeholders (clients, project managers, developers, testers, team leads, …). If models are created formally, code can be derived from them. This can be achieved to an extent where no code has to be written at all, because all changes to the developed system can be made on a model level, and automatically be propagated to the implementation level (see last article).

Reality: Models are created at the beginning of a project. Usually, drawing tools are used, that do not allow a machine-readable representation of models. This further increases the work required to keep models up to date. This usually leads to a state where models that represent an outdated version of a system rod somewhere in the documentation. In larger development organizations, minimum requirements concerning the existence of models for documentation purpose are sometimes set for each software project. But the real purpose of models is never fulfilled.

The Problem

Why is there such a discrepancy between theory and practice when it comes to modelling?

Cognitive Effort: First, there is the cognitive effort for creating models. Of course, thinking about how a system should look like and formalizing this information in, and most importantly, cognitive effort. We have to focus our minds on what we actually want to do. As developers, however, we want to use our minds to create cool stuff – by entering code into our IDE. Everything besides that (e.g. writing documentation, unit tests, or creating models) is a potential threat to the purpose of our work, and has to be eliminated.

Limited Knowledge: My experience in different software development organizations showed me that 90 % of the developers do not know how to create a model (or what a model actually is – so if you are not sure, check out my article on “The power of models”). If models are created at all, general-purpose drawing tools are used. However, as these tools do not allow the machine-readable representation of modelled information, no further automation is possible.

Outdated Information: But even if models are created at the beginning of a project, the discrepancy between modelled information and actual implementation increases with every day. This leads to models being a graveyard of outdated requirements and implementation details. The following figure visualizes this problem.

If requirements specification in the format of models is created, implementation is based on the modelled information. After implementation of a software increment is finished, it is tested in order to verify whether it satisfies the intended needs of the developed software. If a defect in the implementation is found, feedback is backpropagated to the implementation phase in the form of bugs. The software is adapted based on this feedback, by e.g. improving code, reconsidering design decisions, or even reformulating requirements. The updated software is again sent to the testing stage for retest. However, the made adaptations are never backpropagated to the specification stage, where models are situated. This missing link makes models outdated as soon as a first issue is found during or after implementation. And of course, the more incrementations of this process happen, i.e. the more parts of the software are developed, the more severe these discrepancies (as long as there is no one in the meantime fixing all the issues in the models every time new software parts are specified – which does not really happen in practice).

How can we bring theory into reality?

As of now, you should have an understanding of what I see as the discrepancy between theory and practice when it comes to models, and potential sources for this problem. But how can we make sure to overcome this problem, in order to unleash the full potential of models?

Reducing costs for creation: By making it easier to create models, in the sense of time and cognitive effort, the barrier for actually creating them (discussed in the previous section) is reduced. The less time and effort it takes us to create models, the more likely we are actually doing it. A lot of research is therefore currently focusing on the usability of modelling tools and languages.

Increasing benefits of maintenance: As for every artifact in the software development process (e.g. code, test cases), models to not only require effort during creation, but also during maintenance. However, as discussed above, without maintenance, models have hardly any benefit. So, to make the effort for maintenance worth the required time, we have to increase the benefits for keeping models up to date. How can we do that? By allowing the reuse of models across the whole software development cycle, by automating tasks based on information already stored in those models. Therefore, a lot of research currently focuses on both (i) use cases in which models can be reused, and (ii) tool support for reusing models (e.g. optimizing storage and access facilities).

Enforcing education: But even if the two prerequisites mentioned above are fulfilled, no one will ever properly create and maintain a model, if there is no understanding of the underlying formalisms and requirements, as well as potential benefits within organizations. Therefore, it is in my opinion the responsibility of every organization that wants to seriously do state-of-the-art software development to require employees to have at least a fundamental understanding of (i) requirements and formalisms, (ii) potential, as well as (iii) benefits of creating and maintaining models within software development projects. Your most important takeaway message from this article, with regard to education in modelling: a drawing tool is not a modelling tool!

Conclusion

Although models are a powerful weapon for every software project in theory, they are a graveyard for outdated and incomplete information in practice. This discrepancy between theory and practice stems from … However, we can reduce this discrepancy by enforcing education about modelling, reducing the cost of creating and maintaining models, and increasing the benefits of keeping models up to date.

written by Daniel Lehner