Application Development Using Blueprinting
In order for development to proceed smoothly and in line with the principles of blueprinting there are a number of prerequisite features required of any blueprinting technology. General ApplicabilityA good blueprinting language should not be tied to a particular class of application development. Returning once again to the building analogy, suppose an architect was trained in blueprinting schools and a completely different type of diagram was used for blueprinting hospitals. It would be difficult to specialize horizontally because an architect would have to learn every type of diagram from every domain. A building firm looking to build a hospital would have to find and recruit an architect with previous experience of building hospitals thus raising the cost of the project.The same logic applies within the software industry. A single blueprint language that is general enough to describe any application means that the software architect can specialize horizontally. Obviously domain expertise is still required and the architect can work with consultants, his customer or may have the necessary domain knowledge himself. A fully trained software architect equipped with the right blueprinting technology and supplemented with the required domain expertise should be able to blueprint applications from domains as wide as:
Connective Logic Systems have provided the following interesting three part article discussing the application of blueprinting process and technology to the defense and aerospace sector: Part 1: Open Architecture - Technology, Process or Both? The primitives provided by a blueprinting language therefore must be at a fairly low level in order to support this general applicability. For example, providing components such as beamformer, pixelator etc. may provide everything a sonar developer needs but would not constitute a general blueprinting language but rather a sonar library. This is similar to the approach that Labview takes and even if this library contained everything that was needed today, it is inevitable that it would not tomorrow. It would, however, be desirable to produce such libraries using a general blueprinting language. PortabilityA key purpose of an application development blueprint is to describe the application at a sufficiently high level of abstraction to avoid it being unduly tied to a particular platform, topology or contemporary technologies such as web services.A good blueprinting language should allow us to describe the high level behavior of an application so as to be prescriptive and therefore able to generate code but without assuming any underlying platform or topology. In other words, the same blueprinted infrastructure should be capable either being translated to a different platform or translated to platform independent code that is subsequently linked with an appropriate platform runtime library. There is a caveat to this however; there is always likely to be platforms to which a particular non-trivial application development cannot be ported due to the physical restrictions of the platform. In particular the amount of data that can be held in the local memory of the IBM Cell's synergistic processors is prohibitive for many applications and requires special tiling logic to break the data down into small enough chunks. On the other hand it is possibly quite feasible to port an application development between the following platforms without the need for infrastructure variants:
In addition to portability across platforms, it is desirable to be portable across languages. That is, the sequential code that is plugged into the framework and the generated infrastructure code (if visible) should not be restricted to a particular language but may consist of:
Efficient Re-useThe ability to re-use existing software is crucial to minimizing application development costs and should be supported by good blueprinting languages.There are two types of re-use in object-oriented languages. Firstly, the ability to create a definition and instantiate it allows multiple instances to be created from a single definition. A definition can be placed in a library and re-used across projects. Secondly, object-oriented languages support re-use through inheritance. This allows existing code to be modified and extended to create variants and build components that are similar to existing ones without having to 're-invent the wheel'. Both types of re-use must be considered as a highly desirable feature for any blueprinting language.
|
