Practical Software Engineering with Models and Blueprints

In software engineering, UML modeling can occupy a great deal of project time. How can modeling be used effectively and how can software blueprinting support the modeling process? Blueprinting and modeling are often confused (probably because they both typically involve visual representations). However, the two processes are fundamentally different and it is critically important to understand the distinction in order to appreciate the value of each within the software engineering lifecycle.

Motivation for modeling

Modeling is an informal process and its primary objective is to stimulate inspirational thought within the mind of the software architect. Depending on the particular type of development, output from the modeling stage could include sketches (e.g. UML), notes, physical mock-ups or any other non-prescriptive, informal items.

Crucially, the relaxed informal methods of this stage of development allow architects to think freely, promoting ideas and innovation. Consider a building architect preparing to describe a house; before he produces a detailed blueprint he is likely to draw some sketches of roughly how the property will look and show them to his customer - perhaps even a 3D model of the property to demonstrate a virtual walk through. At this stage he doesn't want to be overly constrained by details such as joist thickness and heat distribution - he is more concerned with the aesthetics. Of course, he would still have to have these concerns in the back of his mind so as to avoid producing a model without a feasible implementation.

The same principles apply to the world of software engineering. Indeed, the UML was born out of informal sketches by software architects. The products of this stage are therefore necessarily informal and should never try to cross the boundary into precise, prescriptive descriptions and risk stifling creativity. Follow this link to learn about how UML software engineering fits with blueprinting

Model -> Blueprint

The informal products of the modeling stage fuel the blueprinting stage. Unlike informal models, blueprints are both formal and prescriptive. The purpose of the blueprinting stage is to take the ideas generated by the modeling stage and to rationalize and constrain them into a comprehensive description that contains all the detail required to generate executable code.

The ability to blueprint application infrastructure leads to the notion of infrastructure patterns. An infrastructure pattern describes a standard co-ordination pattern such as finite difference time domain and may then be resolved for a specific use such as solving Maxwell's equations or the game of life. This is a powerful concept that facilitates re-use of some of the most complex and therefore expensive parts of an application.

As the application inevitably evolves, the blueprint is updated and as a direct result of its formality and prescriptive nature, the generated code is automatically updated. At this stage the products of the modeling phase have been discarded as they served their purpose in stimulating ideas to generate the blueprint and with a blueprint in hand, updating models that serve no purpose would be expensive and unnecessary.