A software blueprint is the final product of a software blueprinting process. It's name derives from the analogy drawn with the popular use of the term blueprint (within traditional construction industry). Therefore, a true software blueprint should share a number of key properties with its building-blueprint counterpart:

Properties common to blueprints

Step-by-step procedure from blueprint to finished article

Software blueprinting processes advocate containing inspirational activity (problem solving) as much as possible to the early stages of a project in the same way that the construction blueprint captures the inspirational activity of the construction architect. Following the blueprinting phase only procedural activity (following prescribed steps) is required. This means that a software blueprint must be prescriptive and therefore exhibit the same formality as other prescriptive languages such as C++ or Java. Software blueprinting exponents claim that this provides the following advantages over enduring inspiration:

• Potential for automatic machine translation to code
• Predictable timescales after blueprinting phase
• Software architect's intentions reflected directly in code

Focused on a single application aspect

Software blueprints focus on one aspect to avoid becoming diluted by compromising choice of description medium and to ensure that all of the relevant logic is localized.

Selection of optimal description medium

The single aspect focus of a software blueprint means that the optimal description medium can be selected. For example, algorithmic code may be best represented using textual code whereas GUI appearance may be best represented using a form design.

The motivation behind selecting an intuitive description medium (i.e. one that matches well with mental models and designs for a particular aspect) is to improve:

• Ease of navigation
• Ease of understanding
• Fault detection rate
• Ability to manage complexity

Localization of aspect logic

The localization of aspect logic promoted by the software blueprinting approach is intended to improve navigability and this is based on the assumption that the application programmer most commonly wishes to browse application aspects independently.

Orthogonalization

Software blueprinting relies on realizing a clean separation between logically orthogonal aspects to facilitate the localization of related logic and use of optimal description media described above.

Examples

GUI form design

The GUI form design (see GUI toolkit) is widely adopted across the software industry and allows the programmer to specify a prescriptive description of the appearance of GUI widgets within a window. This description can be translated directly to the code that draws the GUI (because it is prescriptive). In computer programming, widget toolkits (or GUI toolkits) are sets of basic building elements for graphical user interfaces. ...

Machine translatable co-ordination languages (e.g. CDL)

Languages such as the Concurrent Description Language (CDL) separate an application's macroscopic logic (communication, synchronization and arbitration) from complex multi-threaded and/or multi-process applications into a single contiguous visual representation. The prescriptive nature of this description means that it can be machine translated into an executable framework that may be tested for structural integrity (detection of race conditions, deadlocks etc.) before the microscopic logic is available.

Class designers

Class designers allow the specification of arbitrarily complex data structures in a convenient form and the prescriptive nature of this description allows generation of executable code to perform list management, format translation, endian swapping and so on.

External links

• http://www.software-development-blueprinting.com