Generative Programming: A Model Driven Approach

R. Azimi,Farid Hosseini

Abstract:ions to implementation components. In GP techniques, programmers define a model of the system that just defines the data contents and logic of the applications. Then programs similar to compilers translate such models to the actual programs or machine codes automatically. As of traditional compilers, there can be several model compilers that translate a single model to various platforms, depending on the needs of different users (Figure 1). Figure 1 Trend in raising the level of abstraction in computer programming. In order to achieve portability, a model must be abstract. That means it should not include any platform-dependent information. Instead, it defines specification of the system that is inherent to the system independent from the way it can be implemented. Also, a model has to be both complete and precise. It may not ignore any important details of the application data content and flow and events logic. Moreover, it should leave no ambiguity in the definitions of the data items and system behavior. Finally, translation of a model to the conventional software development platforms must be possible most of the time. In some possibly rare cases in which such translation is not computable, application programmers have to write the programs in the current programming languages, and link such components with the rest of the system that is automatically generated. In this report, we provide a overview of techniques, tools, and methodologies that are used in building systems using GP. The focus of the report is more on model-driven GP. The rest of this report is organized as follows. We first provide a closer look at the current GP techniques. Then, describe the desired characteristics of a model for building general-purpose applications. Then, we review Executable UML as an example of such model and analyze its capabilities and weaknesses. Next, we describe the requirements for building model compilers, and analyze the existing tools. Finally, we describe techniques that use GP in building middleware software in particular. 2. GP: A CLOSER LOOK A widely accepted definition for GP is that it is the automatic selection, customization, and assembly of prebuilt templates and components on demand. This process is in contrast with the current practice of manually searching, adopting, and integrating components [3]. There are some skepticisms about that GP will not widely be used since it requires skills that are not mainstream, which could be true, in one sense. Actually, most developers prefer not to use GP in their design and implementation since they want control on the development process. Probably, we need to wait for a few years to see whether many vendors move to GP software engineering. However, there are clear incentives in using techniques such as GP. As hardware and network technologies become faster and cheaper at a predictable pace, software, particularly distributed software, is becoming slower, buggier, and more expensive and it is hard to predict how long it takes to build. A key reason for these different trends is that hardware and networks are now heavily built based on components off the shelf (COTS). While, as for software, current practice is to build the custom components for each product specifically. The interface of hardware COTS are usually standard, whereas distributed software components are usually built in a custom manner, or follow standards that are specific to a company. Applying COTS standards to distributed software is not easy, and many tough R&D issues must be resolved [4]. GP 1 Due to our time limits, such an overview is neither complete nor accurate. However, we tried to cover some of the most techniques and technologies that are around. Too hard to program and debug Too machinespecific Still hard to program Still platform-specific Hard to reuse Easy to use Platform independent "! #$! % &(' )+*+) , -/. 0 1 # 2 3 +452 ! -6% Compiler Model Compiler