latestblueprint toolsetlatest
logo for software-development-blueprinting.com
latestblueprint toolsetlatest
Home
Infrastructure
Engineering
Outsourcing
Applications
Tools
Services
PC Development
Custom Software
Improve Process
Project Management
Contact
leftimage for software-development-blueprinting.com
 

Software Development UML Models Generate Stub Blueprints

Software development UML models and blueprinting are entirely complementary. In the same way that UML models can generate stub code, they could also generate stub blueprints.

At present, software development UML models can partially generate code. However, in contrast to a formal blueprint, such models are not even nearly 100% prescriptive. This means that the code that can be generated from them is very limited. In fact, this is a good thing...

Why? Using informal models to generate code detracts from their greatest strength - their informality. Code generation requires formality, and by introducing formality we are constraining the architect to consider details that he may wish to defer until the blueprinting stage. In short, we are turning the model into a partial-blueprint. This is the worst of both worlds because now it is too formal to help the architect express his inspirational thoughts freely but too informal to generate significant amounts of code. This is very similar to the approach adopted by the Model Driven Architecture (MDA) initiative.

By freeing the modeling language from the full rigour required for fully automatic machine translation, we end up with a stage that effectively bridges the gap between the architects thoughts and his final blueprint. This also allows communication between stakeholders at a less formal level.

Having said that, certain basic information can be inferred from a software development UML model and stubs created in the blueprint as a starting point that the architect can then flesh out with the necessary detail, rendering the blueprint complete and prescriptive. However conversion from models to blueprints must be viewed as a time-saver rather than a fundamental part of the process. This conversion is a one-off, one way process that leaves the model behind and subsequent efforts focus on the blueprint. There is no value in maintaining models that will never truly reflect the executable code when a blueprint is available that does by definition.

So in the same way that software development UML diagrams are used to generate stub code presently, they can also be used to generate stub blueprints. After all, a blueprint is code really - just at a higher level of abstraction. Follow this link to read more about the comparison between software development UML models and blueprints and analogies with mature industries.


footer for software development page