Modeling... why bother?
Modeling in software engineering... why bother?
When I first heard about modeling in software engineering, I was quite skeptical. After all, why bother to create models first, when one can jump right into coding the software?
The typical answer I heard was that real engineers always create models before building a product - architects are always drawing blueprints before the bricklayers actually start building the house, mechanical engineers always draw cross-sections and design models before manufacturing the item, etc. This answer never really satisfied me; after all, while building a house or manufacturing an item using the lathe is much costlier to do (and to get wrong) than doing revisions of a floorplan or blueprint, the same can not always be said of software: source code and model that describe source code are all just bytes in a computer, without significant material investment. And it is quite apparent that a part of the software industry, in fact the majority, does quite okay without UML or other kinds of modeling. All in all, it seemed that modeling software is just not worth it.
So what did I miss here? What I failed to take into account at the time was that software engineers always construct a model of the behaviour of a software before writing the software itself - a mental model, that is. And most of the time, the mental model is enough. Software developers receive requirements, think about them for a while, and then produce code, all without leaving a trace of diagrams.
The trick is that under certain circumstances, engineers choose to extract this mental model (or parts of it) from their minds into some kind of document. There are numerous good reasons to do so:
- Often there are multiple software engineers in the team, so that they can finish a project faster. Usually they cannot split their work into completely independent chunks, so they need some form of coordination. They can use documented models to communicate their mental models to each other.
- Sometimes a multi-engineer project grows so large that nobody can fit a sufficiently detailed mental model of the entire system in their heads. A documented model can play an analogous role to an external storage, a subset of which can be cached in the mind of each engineer.
- The engineer who creates a model and the engineer who reads it need not be different people; they can be the same person, at different points of time. Sometimes, a model is useful for recording design decisions that might not be remembered a while later.
So far, the form of this documented version of the mental model was unrestricted - anything goes, as long as the other party will be able to understand it; plain text documentation (such as Javadoc) is actually quite common. Adhering to some conventions of denotation and semantics can be useful and productive, but not absolutely required, especially if the original designer is available for clarification upon requests. Yet, there are other cases where representing the model according to informal or formal conventions is highly recommended, or even mandatory:
- Sometimes a previously designed component or module is reused within, or interfaced with, a new system under design. Proper integration requires some form of communication between the engineers responsible for each of these systems. This time, the engineers involved typically do not belong to the same team or company, and do not have any other way to communicate.
- If the target of the communication is a computer, the model must be formal. The great realization of model-driven engineering (see below) is that automated processing of formal models can provide a lot of help, from analysis to derivation of output artifacts. Depending on the development workflow, such automated steps may increase quality and save time and resources.
Of course, the extraction of the mental model into a documented form (especially in a strict formalism) requires some amount of effort from the engineer. And it is not enough to do it once; whenever the engineer changes her mind, she must (well, should) update said document accordingly. Nevertheless, in certain industries and application domains the advantages (including those listed above) outweigh the costs, and even formal modeling is part of the engineering routine. This is the full answer I can give to my skeptic self.
The paradigm of model-driven engineering
In certain areas of software and system engineering, primarily where faults can lead to human injury or significant damage in property, the discipline of model-driven engineering (MDE) is gaining more and more prominence, as it delivers higher-quality products in a shorter development lifecycle. According to this approach, the focus of the engineering process is on creating and analyzing abstract models, and deriving them from other models; these models conform to various modeling languages.
Modeling may start in an early phase of the engineering process, when requirements against the system under design are elicited. In light of the requirements, system design commences with creating high-level abstract models, then arriving after a series of refining steps upon models enriched with design decisions and realization considerations. The models can be continuously subjected to checks in order to find mistakes and design faults as soon as possible. As components for embedded systems are often required to be realized upon various target platforms corresponding to different technologies, such design processes may involve a platform-independent model (PIM), which encompasses the significant application-specific behavioural principles and realization parameters, but technological aspects are not detailed yet. Afterwards, depending on the available technological context, the PIM may be mapped to various platform-specific models (PSM), from which program modules realizing the designed software components can finally be produced (partially automatically). [OMG Technology Perspective]
The concept of models is vague in the sense that it may even involve differential equations or spatial configurations in certain domains of system engineering; however, models involved in software engineering are essentially labeled graphs, and are typically sparse (i.e. the number of edges is roughly linearly proportional to the number of vertices). The labels applicable for vertices and edges of a modeling language (including types and attributes), along with their rules of interconnection, are defined by the metamodel of the language. It is important to point out that it is the abstract, formal structure of the model (the so-called abstract syntax) that is assumed here to be graph-like; the user-friendly visual depiction of the model (concrete syntax) can independently be of diagram, text, or any other form.
While there are some extensible formalisms intended as a universal way of representing models (such as UML[OMG Spec], SysML[OMG Spec]), industrial practice seems to ever increasingly prefer domain-specific modeling languages (DSML) instead, which can be tailored to the needs of application domains and actual design processes. However, developing such a DSML, along with associated tool support, is a cost-intensive task requiring special skills; therefore so-called DSM technologies have emerged to provide aid. The Eclipse Modeling Framework (EMF[home]), built on the Eclipse platform, is a leading DSM technology that is considered as a de facto industrial standard. A DSML development process with EMF involves defining an own metamodel (using the Ecore formalism), from which several components of the modeling tool can be automatically derived. Numerous generative or generic technologies help in creating tool support for EMF-based DSMLs; one can define a textual concrete syntax using a grammar or a visual concrete syntax using graphical elements, while code generators can be created by specifying textual templates for the modeling language.