Even niks meer toevoegen, heb m eruit getrokken om m af te maken...
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 assumptons can be made on the target environment. In general such development environments deliver highly proprieraty 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 behaviour 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.
===A pragmatic approach to model driven development===
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 exsit, 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.
Motive
There are several examples in which model driven development (MDD) can be (and is) a great help in software development. In the past two years Avisi has been investigating several alternatives to kick start Java applications. Most important requirements for the kickstart-tools for use were:
- Model based, we prefer UML
- Adjustible and flexible stack so other frameworks can be applied
- Code quality equal to our handwritten code quality
- Based on Ant, rather than Maven
After having looked at JBoss Seam and AppFuse, we tried the tool of Capgemini named Tobago MDA generator. The tool comes with a simple but powerful object model and an easy to understand templating mechanism. Tobago is able to parse an UML XMI metamodel containing smart use cases and a UML class diagram containing business classes, value objects and smartreferencse and applies our own templates (instead of the tobago templates for .NET projects) to the parsed metamodel.
===Modeling behaviour===
In general we model the behaviour of the software to build in use cases. We define use cases exist at different levels of granularity. Alistair Cockburn, leading authority on use cases, describes five levels of granularity.
 Levels of use cases |
These five levels are known as:
- Cloud level. Very high level summary, such as Sell books online. Too high up to be of interest to software development projects, and far too high level to generate code.
- Kite level. Summary level. Again, too high level to be interesting to software development projects and generating code.
- Sea level. People familiar with the Rational Unified Process (RUP) should be familiar with this level of use cases, also refered to as user goal level. A single use case at this level describes a single elementary business process, and realizes a single user (actor) goal. An example could be Place order.
- Fish level. At this level, use cases are often used and re-used as a part of a sea level use case and describe processes that for instance handle selecting a customer, or validating credit cards with a credit card company. This level is also referred to as sub-function level, and includes use cases such as Select product and Pay order. These use cases, including the sea level use cases, are a good head start for generating code that handles the software's behaviour.
- Clam level. This is where you hit rock bottom. Use cases at this level should not be defined as use cases, but rather appear as steps in another use case, most likely at fish level. A clear example can be inserting new customers in the database.
Smart use cases comprise both the use cases at sea and fish level. Together these two levels form an ideal, and equal-granular technique for capturing functional requirements, and for estimating, planning, generating, building and testing your software product.
Model smart use cases
Primarily use cases are identified at user goal level. Here, each use cases typically captures a single elementary business process. Normally for this use case the successful scenario is described (also called the happy day scenario), and additionally all deviations to this scenario are described as alternative flows.
 Regular use case |
Using this approach, very limited use is made of the UML use case diagram modeling technique. Requirements are captured in text, and are mostly described in Word documents. As a good example of this type of use cases, at a large international financial institution a use case called
Change Address was written. It covered 65 pages of text, 12 screens and numerous alternative flows. As these types of use cases vary enormously in scope, complexity and size, it is very hard, if not impossible to generate code from user goal level use cases.
Alternatively, when the use cases at user goal level are identified (even better: the elementary business processes for the project have been identified), it is possible to use the use case diagram technique to add use cases at fish level to the diagram. We have defined a number of clear guidelines on when these additional use cases apply. These include not handling more than one form per use case, handling complex calculations, handling services in service oriented projects, or even handling ETL in BI projects. The following diagram is a good example smart use case diagram. Please note that this model is not a work breakdown, the user goal level use case has it's own responsibilities.
 Smart use case diagram |
Using this approach each of the elementary business processes is modeled out in such as diagram with any number of acors, a single user goal level use cases, and a number of accompanying use cases at sub-function level. The collection of these use cases (at both levels) is referred to as smart use cases. Again, for each of these smart use cases a description is written. However, these are much more lightweight than in the previous scenario and often contain only a few (or even no) alternative flows. We not only model these smart use case diagram in traditional multi-tier scenario's, but also host service oriented and even cloud scenario's.
An important step towards generating code from use cases is the recognition of smart use case stereotypes, which describe standard behaviour. This extreme requirements standardization streamlines the requirements analysis, but also enables us to define templates per stereotype that implement this behaviour in for instance Java or C#. Currently we harvested over 30 of these smart use case stereotypes, including maintenance use case in
Manage,
Master Detail,
Select or
Search, such as in the depicted diagram, but also
Collect in BI projects, and several types of service handling stereotypes in service oriented projects.
Create the domain model¶
The domain model is created in order to document the key concepts, and the domain-vocabulary of the system. The model identifies the relationships among all major domain entities within the system. The domain model provides a structural view of the system. In projects that are executed using the Accelerated Delivery Platform the use cases models and the domains models are input for the code generation.
The domain model is a UML class model. Normally classed are modeled for domain entities like Customer, Order, Product and enumerations like Gender. For the classes different properties are modeled, just basic types like string, integer, date but also specific property types named value objects are used. Examples are Email, Amount, Zipcode, Telephone, Url and also domain specific value object like personelnumber and departmentcode.
The use of value objects in the domain model is a very usefull part of the model. Especially when you have the value object already implemented in your reference architecture. All the validations and UI components for the value object are already in place. So you don't have to model or implement again.
The domain model also shows the relation ship between the classes. Multiplicity, role names and composite relationships are all used for code generation.
Modeling the domain entities in the domain model often are done together with modeling the use cases. An use case searc customer probably needs a domain entity customer.
Transform models to working software with the code generator
Using the code generator for transorfingmodel in codegenerator – deel metamodel UML in geheugen (gebruiken Tobago MDA)Within a ADP application the UML model is the heart of the development life cycle. When modeled correctly, the model is an exact representation of the requirements. The owner of the application gets a clear view of the functionality and the relations between parts of the software when viewing the model. This model is the input generating code. Whenever anything changes in the applications architecture it will be changed in the model first. From the model code can be generated over and over again. This save lots of time and makes the risk of failure extremely low.
When using the Tobago Generator for code generation you need to create your model to the ADP modeling guidelines. Different entities of the model act on different layers in the ADP architecture. Based on the stereotypes assigned to classes and use cases, corresponding patterns are used to generate code.
The approach for generating applications is pretty simple. The first step is to model the use cases and use case diagrams. Then model your domain model as class diagrams. When using a regular UML modeling tool you export the models as an XMI file and import this file into the code generator. The code generator is then merging the generation templates and the imported models to usefull source code and documentation. After generation the last step is to finalize your application.
Before generating and finalizing your application you need to configure your application. Setup the framework, configure the connections to your datasources and probably some generic UI work.
Tobago Template Syntax
The Tobago Generator is a very simple text templating engine. The templates are easy to understand text files. The text files are almost the same as the generated files. Simplicity is the goal.
The Tobago Generator uses different mechanisms for generating code from templates
- Tobago Tags
- Tobago Methods
- Adaptive selection of templates
Here is an example of using the Tobago tags and methods:
package nl.$UseCase.Model.Name.Lower$.service;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import nl.$UseCase.Model.Name.Lower$.model.*;
import nl.$UseCase.Model.Name.Lower$.dao.*;
import org.jboss.annotation.ejb.LocalBinding;
import java.util.List;
@Stateless
@LocalBinding(jndiBinding = "$UseCase.Model.Name.Lower$/$UseCase.Name.Trim$Service")
public class $UseCase.Name.Trim$ServiceImpl implements $UseCase.Name.Trim$Service {
<Tobago.Loop(UseCase.Attributes, "DAOs")>
<Tobago.Loop(UseCase.Attributes, "Attributes")>
}
The codeexample above illustrates a Java implementation of a Value Object and uses mainly the Class-tag together with several properties like Name (which in fact has its own properties like Lower and Pascal) and Model. In the same example a Tobago method is used, specificly the Tobago.Loop method.
Another example for a value object property of a domain object in c#
<Tobago.If($Attribute.IsNullable$,"", "[NonEmpty]")>
public $Attribute.Type$ $Attribute.Name$
{
get
{
return state.GetValue<$Attribute.Type$>($Attribute.Owner$Describer.$Attribute.Name$);
}
set
{
state.SetValue($Attribute.Owner$Describer.$Attribute.Name$, value);
}
}
Examples of generated deliverables – in .Net and in Java¶
We have been using Tobago for kickstarting our software development mainly for propositions and refactoring. The main application we used Tobago for is an HR-application which can be used by HR-managers to manage competenties, employees, administrate agreements with employees etc. The whole application is generated using the same Java open source stack: Freemarker, Sitemesh, Struts2/XWork, Spring, JPA/Hibernate, MySQL (for development, in production we might use Oracle) and JBoss. This stack is illustrated with the following diagram:
 Avisi Java Stack |
Using this stack the application is generated using Ant and deployed on JBoss Appserver and can be used instantly:
 Maintenance of Smart References |
Generated management of Smart References, like Country and Classification.
 Adding an Employee |
Adding an Employee which refers to the Country Smart Reference. All the required fields get validated through regular expressions that are included in the UML model.
 Adding a Training |
Adding an Training to an Employee, in addition to the single attributes the associations from the model are used, in this case Training and Competency. The UI-controls are a result of the software generation process looking at n-m assocations.
Conclusions
In our experience, applying a highly pragmatic approach to model driven development, such as the one described here, can be very effective. 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 interface. 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, such an approach will save work in a varied number of scenario's and development environments.
Moreover, a pragmatic approach such as this fits well within running agile projects. It this case fast delivery of working software is desirable.