With the economy at a low point in time, organizations and project are clearly resetting their goals. Long term multimillion projects are being halted, in favor of short, agile projects, with feasible goals and good time-to-target. To realize these stringent goals, projects are striving for lower costs and higher productivity. On the one hand these goals might be reached by outsourcing, on the other hand standardization, industrialization and reuse could also contribute. A long term promise in the field of increasing productivity and reuse is to handcraft less code, but to generate code from the project's design or model.
Generating code from a model can be done in a wide variety of ways, and with a even wider range of goals and deliverables to strive for:
- Proprietary techniques. Traditionally there's tools such as Oracle Designer and Developer or Cool:GEN that host both the model as the coding environment. Using these environment high productivity can be achieved, because a lot of assumptions can be made on the target environment. In general such development environments deliver highly proprietary models and code.
- DSL's. Domain Specific Language (DSL) are textual or visual representations of custom domains, for which specific modeling language can be defined, think of web service definition or even a language for defining the mortgages or life assurance domain. With DSL's again has the promise of high productivity, if and only if, the target environment can be clearly defined, for instance in the software architecture and framework that are used.
- UML. The Unified Modeling Language (UML) provides a set of techniques for modeling behavior and structure of applications. These standardized techniques, such as use case or class diagrams are used in projects around the world, however in different variations and dialects. Generating code or other deliverables from a UML model is highly possible, again if the target environment is well defined.
- Database. With proper modeling techniques lacking, many tools take the approach of generating (parts of) applications from the database structure. Although this approach seems appealing and fast, there are limitations. The generated application will mimic the database, and thus will be very data-centric, instead of providing support for the work processes to be automated. Besides that, in the current era of service orientation and cloud computing, many application do not even have their own database.
A pragmatic approach
In projects that are executed using the Accelerated Delivery Platform, Capgemini's open knowledge platform for agile software development, a lightweight, pragmatic approach to model driven development is used. This approach can be expressed in a small number of steps:
- Model smart use cases. We model our functional requirements using highly standardized smart use cases. A growing collection of over 30 standard types of smart use cases exist, making life easier when it comes to requirements analysis, project estimation, testing, but also code generation.
- Create the domain model. Next we create the domain model, containing the entities, value objects and other classes from the problem domain of the project.
- Decorate the model. To be able to generate code we combine the smart use cases with the elements from the domain model, and a the appropriate stereotypes. For instance, we associate the smart use case
Search Customer with the Customer class, and decorate this association with the stereotype «search». - Import model. Then we import the model in Tobago MDA, our code generator of choice. Tobago MDA can apply text templates to the model, and generate any desired text based deliverable, ranging from Word documents and Excel spread sheet to the actual code.
- Generate code based on reference architecture. To sort maximum effect, we base most of the application we develop on a straightforward reference architecture, that is supported by a number of frameworks, both in Java and in .Net, although other technology also apply.
When does a pragmatic model driven development scenario fit?
We refer to the above approach a highly pragmatic. It is not difficult to create new patterns, even for newbies. You simply start with existing piece of code that represents the type of work you want to generate. Next you identify which parts of this code (or other deliverable) should be replaced by tags. And next you pull out the repetitive parts, such as properties or operations, add in Tobago’s looping or conditional constructs and move the repetitive parts into sub-directories. that’s it. You’re now ready to generate code and import that code into your application. This whole process takes about 15 minutes, and can be repeated for all re-occurring element in your software architecture.
Glancing over this scenario makes you realize that this type of code generation is easy to achieve, given some minimal settings:
- UML. You will need to know how to model in UML; which modeling techniques to use, and how to use these. Here, we apply and combine two of the most basic modeling techniques available, the use case diagram and the class diagram.
- Software architecture. You will need to know what code to generate. This largely depends on the underlying software architecture; which layers does it comprise, which layer supertypes appear in those layers. In general it’s these layer supertypes that are transformed in to code generation patterns. Think of domain objects, repositories, factories, table create statements, controllers, views. Besides code generation, having a sound software architecture in place is a must anyway to build good and maintainable software.
- Frameworks. To speed up development further, it is recommended to use standard vendor or open source frameworks, such as Spring, Enterprise Library, ADF, Castle or nHibernate. Mind you, it is considered good practice to have these frameworks match your software architecture, and not the other way around.
Given these minimal settings, there are hardly limitations to what you can do with this technology. Whether you are generating an Excel spread sheet summing up use cases and estimates, Word documents with test scenario’s, complete functional domain layers or actor based side bar menu’s, it’s a fairly easy to accomplish.
As simple as possible, but not simpler
In our experience, applying a highly pragmatic approach to model driven development, such as the one described here, can be very effective. Although many alternative strategies towards model driven development exist, we feel that a pragmatic approach works best. The more theoretical an approach gets, the harder it is to implement in everyday life. Here, we mainly model smart use cases and the domain model, and decorate that by combining the two, and adding stereotypes.
Even though some vendors show particular interest in adding code generation facilities to their modeling or development environments, we specifically choose to use an independent intermediate tool, such as Tobago MDA, to be able to target multiple platforms with the same strategy. All patterns that we collected for use with Tobago MDA come from live code, and thus apply proven technology. Generating code from such patterns, raises the quality of the software at high pace.
We do not expect your code generation to be perfect, but it doesn't have to be. Code and other deliverables are generated to avoid having to do tedious repetitive work, such as web forms, panels, domain objects, table create statements, service interfaces and even documentation. This allows developers to focus on business logic, or fine tuning the user interface. Because it is fairly easy to create new templates simply by investigating your existing code, this approach saves time and effort in a varied number of scenario's and development environments. It has proven successful in (partly) generating solution for various types of projects, including ASP.Net, Silverlight, SharePoint, Visual Basic Window Forms, Java, service oriented applications (.Net and SAP), and even back end functionality. It’s an approach that adheres perfectly to one of Albert Einstein’s famous quotes:
everything should be made as simple as possible, but not simpler.