Application Development Software Blueprinting Tools

Blueprinting application development software allows a software architect to prescriptively describe complex application infrastructures at a high level and translate to code. An effective blueprinting toolset is essential to enable the software architect to capture their application infrastructure efficiently and should provide the following features:

• Language sensitive editing
• Fully automatic machine translation to executable code
• Blueprint-level debugging facilities
• Effective blueprint navigation
• Integrated source code control
• Integration with familiar development environments
• Blueprint static analysis functions
• Reusable blueprint library management

Software blueprinting languages (and therefore their associated tools) could be either visual or textual. Follow this link for a discussion on the pros and cons of visual vs. textual application development software

Language Sensitive Editing

Blueprinting application development software should have a language sensitive editor. Why is this important?

You could argue that Microsoft Visio is an application blueprinting editor because you can draw blueprint diagrams with it. However, crucially, Visio is not aware of the blueprinting language that you are drawing (its model contains lines, curves, boxes etc.) and therefore it is unable to provide the necessary syntactic and semantic checking to maintain the validity of the blueprint.

This means that it is easy to produce a 'blueprint' that has no direct mapping to code. In fact, this would be a model rather than a blueprint because by definition a blueprint must be 100% prescriptive.

So the language sensitive editor constrains the user to produce a syntactically and semantically correct blueprint. The editor is aware of the relationships between entities within the blueprint and can therefore display additional information to assist the architect in the same way that Visual Studio Intellisense provides relevant contextual information. This also facilitates displaying different views of the blueprint (e.g. data-flow, client-server etc.)

Fully Automatic Machine Translation to Executable Code

The ability for the software architect to translate his blueprint to executable code is a crucial feature that underpins the entire blueprinting process.

This because it means that the architect's blueprint is realized directly in the executable code without interpretation or amendment. As the process is fully automated, a change to the blueprint simple involves a retranslation.

Effectively the blueprint has become the code. You can think of the blueprint as having the same relation to C++, as C++ has to C - it is a higher-level of abstraction. Just as C++ is a hybrid with C, a blueprinting language is a hybrid with C++ (or any other such language).

There was no need for C++ to gratuitously re-invent the syntax of C because it was purely concerned with adding object-oriented constructs. Similarly, a blueprinting language need not gratuitously reinvent C++ but rather complements it with the higher-level abstractions that it does not provide. We call this a "hybridized language approach".

Blueprint-Level Debugging Facilities

In the same way that you would not wish to debug C++ by sifting through a pile of its equivalent C code, it is highly unlikely that you would wish to debug blueprint code by sifting through its C++ equivalent. Therefore an essential feature of excellent blueprinting application development software is the ability to debug the blueprint itself, step-by-step. If the blueprint is represented visually (most likely) then this would most probably involve a scheme for highlighting parts of the blueprint as appropriate in order to convey the current application state. The figure to the right shows how color is used to highlight the state of executing CDL blueprints.

Effective Blueprint Navigation

For large projects, blueprints can contain a great deal of complex information and it is important to be able to navigate through the blueprint effectively. This makes it easier to understand the applications behavior and assess the impact of required changes.

Therefore, blueprinting application development software should provide excellent browsing facilities in addition to basic searching for items. It should be possible to view a blueprint in a number of different browsing modes depending on the path that the user wishes to follow. Some examples are:

• Data-flow
• Client-Server
• Top-down
• Provider-Consumer

Integrated Source Code Control

Source code control is an essential part of any software project and the use of blueprinting tools should integrate seamlessly and contribute positively to existing source code control mechanisms.

In order for the blueprint itself to be effectively managed by source code control, it should be modular in composition. Each module can then be contained in a separate file, which means that more than one person can edit different parts of the blueprint at the same time.

In addition the blueprint can provide rich information about how a change will affect the project. This impact analysis allows all the affected files to be checked out simultaneously to minimize subsequent contention on check-in.

Integration with Familiar Development Environments

It is particularly important to preserve the investment that software companies have made in existing tools and training. With this in mind, blueprinting application development software should be integrated with the existing, popular IDEs such as Microsoft Visual Studio and IBM's Eclipse.

In addition, it may be desirable to integrate blueprinting application development software with existing UML tools such as IBM Rational Rose or Artisan Studio. This would provide an extension to the modeling process and in the same way that UML tools currently generate stub C++/Java code, they could produce stub blueprints to be fleshed out by a software architect.

Blueprint Static Analysis Functions

Blueprinting application development software can provide numerous static analyses of a created blueprint prior to execution. These functions could search for anomalies such as the following common concurrent issues:

• Deadlocks
• Deadly embraces
• Log-jams
• Priority inversions

Support for Re-usable Libraries

To reduce software costs it is important to minimize 'reinventing the wheel' from coding the same types of blueprint from scratch each time. To support this, blueprinting application development software must allow modules within a blueprint to be placed in libraries with a view to re-using them across multiple solutions.

It should also be possible to distribute these libraries and let the blueprinting application development software take responsibility for transparently validating the integrity of their interfaces.