What’s next for IDEs?
Over the last few decades a ton of code has been written, and thanks to open source, a large part of it is in the public domain. The capability as well as the complexity of applications has continued to grow exponentially. Most applications are developed in teams, often geographically distributed. Most applications have evolved over a number of years with many nuances, patterns and best practices very specific to each application, and with a tremendous flux of personnel that leave their fingerprints on applications throughout their evolution.One of the biggest challenges in application development today is to factor in application-specific information. The answer lies in the ability to capture application evolution and developers’ knowledge of building and extending the application as metadata so that it’s not lost in time or translation. Once that can be done effectively, the combination of the application code with metadata pertaining to application evolution can be meaningfully packaged into reusable software asset libraries.
Through what we call “Application Factories”, the IDE can be transformed to play a central role in capturing both the application evolution and the developers’ knowledge.
What are Application Factories?
We first need to define some key terms:- Application Factories are a set of tools to enable producing and consuming of Application Modules.
- Application Modules are simply a collection of application source artifacts as standard projects accompanied by Application Factory Metadata.
- Application Factory Metadata is a repository of application-specific artifacts which capture the structure, evolution, and logic used in the development and maintenance of the accompanying application.
Let’s illustrate this phenomenon of transforming the IDE from one that is generic to one that’s application-specific.
In most development tools today, you navigate the application based on a generic explorer paradigm, superimposed by a domain – say Java projects and packages. Diagramming tools navigate to resources based on a modelling construct. Quick search tools jump to known resources quickly. All of these tools are very useful, generic IDE tools which will work with any application.
Application Factories will transform these very tools and add additional ones by applying application-specific metadata. These tools not only let you navigate based on a generic construct, but let you both organise and navigate based on an application-specific construct. Some of these help in manifesting application comprehension, visualisation and anchored navigation. These are some of the features that help others (and the original developer, six months later) remember and understand the nuances of the application. This is illustrated in Figure 1.
Figure 1: Application Factories help with understanding
Let’s use another example to illustrate the transformation from the generic to the application-specific using scripts. But how did the script get created in the first place? The application module producer chose to use a script as an efficient way to deliver new functionality and the Application Factory producer tools help to create such a script. For the sake of this illustration assume that a module contains the collected wisdom from people who needed to do something similar on the same type of framework.
The illustration is a Web application module which contains a script to add AJAX enabled type-ahead capability to a HTML table in your web application. Application Factories reveal the presence of that kind of metadata and let you execute it in the Application Factory framework, prompting for user input as needed. As you do so, Application Factories prepare by generating the code modifications required and present it in an optional learn mode with various kinds of customisation options. One of the primary customisations available now is to modify the code generation itself, adapting it as the application evolves over time. On acceptance of the presented modifications in the learn mode, the application is modified. This is illustrated in Figure 2.
Figure 2: Application Factories generating code
The examples above help illustrate how Application Factories, with the help of metadata, transform the IDE from a generic tool to an application-specific tool. But, how do the Application Module and the accompanying metadata get created in the first place? This is where the consumer part of Application Factories comes into play.
Using the Application Factories tools you can browse pre-created Modules. The browsing of the module is again anchored on metadata – allowing you to filter based on arbitrary facets, resulting look and feel of the application, the architectural view of the application’s internals and others. A view of the module browser is shown in Figure 3.
Figure 3: The module browser in action
An Application-first Development Model
The approach of creating application metadata to capture the intent and knowledge of developers provides an application-driven development model. The IDE now evolves to take the role of manifesting the application-specific metadata with interactive, just-in-time tooling.This approach to creating metadata that easily captures the intent and knowledge of developers working on an application provides a new model for designing software. Applications evolve over a number of years with many nuances, patterns and best practices very specific to each application. Many developers work on an application throughout its lifecycle, gaining knowledge of its inner workings and developing effective ways to maintain and enhance it. These are invaluable assets to hold on to and deploy as modules. Starting from such a base, developers can customise and build applications more efficiently – greatly reducing the cost and overhead associated with the complexity of today’s applications.
Such a model addresses the core challenges in software development today – avoiding constant relearn, capturing valuable data about the application, application reuse, and a meaningful software asset library.
Ravi Kumar is principal architect in the Java tools group at CodeGear, and is responsible for CodeGear’s Eclipse-based JBuilder product line. He is working on making the new paradigm of Application Factories a reality in future versions of CodeGear products.
Comments