Note. This series of posts is also published as a Capgemini group white paper and published in Software Release Magazine (in Dutch, in two parts).

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:

1. 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.
2. 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.
3. 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».
4. 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.
5. 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.

Modeling 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.

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.

Using this approach each of the elementary business processes is modeled out in such as diagram with any number of actors, 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.

Stereotyping smart use cases

An important step towards generating code from use cases is the recognition of smart use case stereotypes, which describe standard behavior. This extreme requirements standardization streamlines the requirements analysis, but also enables us to define templates per stereotype that implement this behavior 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.