Pragmatic Model Driven Development Using Smart Use Cases and Domain-Driven Design
Pragmatic Model Driven Development Using Smart Use Cases and Domain-Driven Design
Pragmatic model-driven
development using smart use cases
and domain-driven design
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page C3
Contents
Introduction 2
Foreword
Model Driven Architecture (MDA) is a fractal system pattern, not only in terms of
software development, but in systems development in general. It focuses on
defining systems behaviors and structures at quite high levels of abstraction.
Assuming that sufficient precision can be maintained, semi-automated (or even fully
automated) software systems can either directly execute, or in other ways interpret,
those abstractions as necessary to achieve implementation of a network structure or
process.
Pragmatic model-driven development using smart use cases and domain-driven design 1
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 2
Introduction
Ever since I started my career, as a young and aspiring C programmer, I have been
fascinated by the struggle that the software engineering profession has been going
through in its long journey towards maturity. Programming languages came (and
some went), later accompanied by ever-advancing techniques for coding, modeling,
analysis, design, and accompanying toolsets. All sorts of schools of thought have
emerged, some of them rigid and formal, others more agile and flexible, and
sometimes their dedicated evangelists seemed to spend more time on writing books
and debating with their opponents than were actually delivering projects.
If you are an evangelist, it may not be so difficult to become a crusader. And the
search for the “Holy Grail” of information technology really started off with the
quest for re-use and productivity: finding ways to produce more code in less time,
on the one hand by building on prefabricated proven components (or even
frameworks of components), and on the other, by generating code from conceptual
or logical models. This introduced even more methods and tools, more
methodological schools of thought, and more methodological wars. Actually, the art
of generating code became so complex, that it introduced a problem space in itself,
completely decoupled from the business challenges that it once aimed to address.
Indeed, nowadays, we may find authors writing books about dealing with the
alignment and mapping problems that they themselves caused in the first place...
And, just as the Holy Grail was never really meant to be found, it seems that we
are still a long way from reaching a mature profession in which we create flexible
software solutions in an industrialized and predictable fashion.
Having said this, I am pleased to confirm that there are plenty of experts out there
who actually prefer to deliver solutions to real-life clients. These experts test their
approaches in hard practice, learn from it, calibrate it and collect best practices
from it. And then they will be willing (and able) to share these pragmatic lessons
with the outside world. Sander Hoogendoorn and Robert de Wolff (both
Capgemini people), and Rody Middelkoop (Avisi) are such experts. Based on the
ideas and experience of Sander, an internationally-recognized thought-leader in
software engineering, they have been delivering software in a highly-productive,
yet down-to-earth style, together with a much bigger team of dedicated
professionals. They model solutions from the user’s perspective, applying smart
use cases: a style of requirements modeling that is particularly repeatable and
measurable, making it much easier to estimate and plan workloads. Combined
with simple, yet effective domain object models, they create a foundation from
which a substantial part of the code is generated. They do not generate
everything: that would not be practical. But the power of simple, focused models,
a large and growing reusable library of over 150 proven patterns and robust code
generation can do miracles to the productivity of a project.
The writers of this paper do not seek to convert the entire world to their approach
(although they may appreciate it!) nor do they claim to have a one-size-fits-all
solution. But the success of their way of pragmatic, model-driven development is
evident, and so it is good to share these insights.
Ron Tolido
Chief Technology Officer, Capgemini Netherlands
Board Member, The Open Group
2
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 3
Pragmatic model-driven development using smart use cases and domain-driven design 3
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 4
Source: Capgemini
custom domains for which a specific modeling language can be defined; think of
Web service definitions or even a language for defining the mortgages or life
assurance domain. With DSLs, again there is 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 being used.
■ UML. The Unified Modeling Language (UML) provides a set of techniques for
4
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 5
Pragmatic model-driven development using smart use cases and domain-driven design 5
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 6
Merge
companies
Merge
mortgage systems
Kite level Summary
Place
order
Sea level User goal
Source: Capgemini
familiar with this level of use cases, also referred 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 part of a sea
level use case and to 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 sea level use cases, are a good head
start for generating code that handles the software's behavior.
■ Clam level. This is where you hit rock bottom. Use cases at this level should
not be defined as use cases, but rather, should appear as steps in another use
case, most likely at fish level. A clear example can be the insertion of new
customers in the database.
Our 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.
6
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 7
Alternatively, when the use cases at user goal level are identified (even better:
when 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 of
smart use cases. Please note that this model is not a work breakdown structure,
the user goal level use case has its own responsibilities.
A (smart) use case diagram, with a single user goal level use case, and a number of
sub-function level use cases
uc Register Outplacement
«Extend» «manage»
Register
Participants
«Include»
«view» «manage»
Register Manage
Outplacement «Include» Outplacement
PLI «Include»
(from Actors)
«Include» «service»
«master detail» Process
Process Outplacement
«Include» Outplacement SAP
Legend
Web application «confirm»
Interaction with
Confirm
third parties Outplacement
«service»
Services in SAP Create
Work Item
Source: Capgemini
Using this approach, each of the elementary business processes is modeled out in
such a diagram, with any number of actors, a single user goal level use case, 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
Pragmatic model-driven development using smart use cases and domain-driven design 7
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 8
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 diagrams in traditional multi-tier scenarios,
but also host service oriented and even cloud scenarios.
In this pragmatic approach, we follow and extend the principles stated by Eric
Evans in his domain-driven design paradigm. As one might expect, the domain
model is expressed in UML class diagrams. Primarily, the domain model models
domain objects (or entities), such as Customer, Order, Subscription or Course
and their relationships, expressed as associations. Next, the properties and their
types are modeled.
We consider five different categories of property types that are all applicable in
different situations:
■ Basic types. In general, people tend to model property types in basic types,
value objects are good for modeling property types that can be validated, such as
Bsn, Isbn or Email.
■ Enumerations. We model property types as an enumeration, if the property can
8
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 9
Name: Budapest.Business
Author: Shoogend
Version: 1.0
Created: 4-4-2008 14:50:09
Updated: 4-4-2009 12:58:51
«business class»
AccountManager
+ FirstName: string
+ LastName: string
+ Mail: Email
+ Phone: PhoneNumber
Source: Capgemini
Each of these categories of property types can be used nicely in code generation.
For instance, enumerations and smart references can be used to fill drop-down
lists, and associations, of course, can be used to generate master-detail behavior or
object-relationship mapping configuration files. Moreover, the multiplicity, role
names and composite parts of associations can all be used in code generation.
used embeds functionality to generate code. On one hand, this approach allows
you to stay close to the original model, but on the other hand, it also may lock
you into using only that specific modeling tool.
■ Development tool code generation. In the second scenario, the development
tool you apply embeds functionality to design the (UML) model and generate
code from that model directly. You could also have a plug-in for your
development tool that helps you out. In both cases in this scenario, however,
you are fixed to a specific development tool and platform.
■ Intermediate code generation. The third scenario uses an intermediate code
generation tool that imports the UML model and spits out code in any way you
see fit. To this end, UML supports a standard export format called XMI. The
code generation then interprets the model elements and can apply templates or
patterns to these elements. Here, although you more or less settle for a specific
code generator, you have the freedom of choice when it comes to modeling and
development tools.
Pragmatic model-driven development using smart use cases and domain-driven design 9
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 10
Although these steps describe the basic process of generating deliverables using
Tobago MDA quite well, there is of course a lot more to tell. A few notes follow:
■ Combine model elements. Different model elements can be combined to
generate even more powerful structures; two associated domain object will
generate relationships in code, and in the database as well.
■ Combine types of model elements. Moreover, combining different types of
applying the same pattern multiple times, remembers the directory where the
deliverables are located.
10
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 11
Source: Capgemini
the generated code can be placed in one file, and the manual code in a second
file, belonging to the same class.
■ Inherited classes. In Java, where partial classes are not available, an inheritance
structure can be applied. There, the manual code is added to a class that inherits
directly from a generated base class. There are a number of design patterns that
support this technique, such as the generation gap design pattern.
■ Marking code. A third option, which can be applied in any programming
language, would be to place code manually between special markers. When re-
generating a particular class, the code generator validates all code between these
markers and merges this old code with the newly generated code.
Note that none of these techniques is waterproof. There are always situations
where a specific technique does not apply. For instance, none of the above works
well if your target deliverables are contained in a Word document or an Excel
spreadsheet.
Pragmatic model-driven development using smart use cases and domain-driven design 11
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 12
Source: Capgemini
This small domain-specific language contains tags that map directly to properties
in the meta model of the imported XMI. For example, the UseCase object in the
meta model has a property called Name. In the template below, the tag
$UseCase.Name$ is used. When Tobago MDA merges this template with an
imported use in the model, the tag is replaced by the actual name of the use case.
Next to the tags, the Tobago’s domain-specific language also applies a number of
operations. Some of these can be applied to the tags directly, such as
$UseCase.Name.Trim$, which trims spaces from the use case name. This might
be needed to be able to create a valid class name from the use case when
generating code.
Other operations are applied inline and use a tag from the meta model as
attribute. Such operations are invoked by Tobago MDA when a template and a
model element are merged into new code. One such example is Tobago.Loop()
operation in the template below. This operation loops through the attributes (or
properties) of a use case, and looks for an additional template in, respectively, the
\DAOs and the \Attributes sub-directories. These templates are then applied to
the attributes. The resulting code is inserted into the main template.
12
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 13
Source: Capgemini
Source: Capgemini
Pragmatic model-driven development using smart use cases and domain-driven design 13
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 14
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 them. 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
Given these minimal settings, there are hardly any limitations to what you can do
with this technology. Whether you are generating an Excel spreadsheet summing
up use cases and estimates, Word documents with test scenarios, complete
functional domain layers or actor-based side bar menus, it is fairly easy to
accomplish. A quick example follows.
14
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 15
The form presented here is a typical master-detail scenario that shows the form
Manage Worker, which shows a worker and his assignments in project. The form
was generated from a smart use case with the same name that was associated with
two domain objects Worker and Assignment.
Source: Capgemini
Pragmatic model-driven development using smart use cases and domain-driven design 15
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 16
The form presented is generated from the appropriate use case Add Employee,
which was combined in the model with a domain object Employee.
Source: Avisi
Note that the Country field (Land in Dutch) is presented in a drop-down list that
was filled using the associated smart reference Country on the domain object
Employee. Moreover, all the required fields get validated through regular
expressions that were included in the UML model. Furthermore, an employee can
add competences and apply for training. This particular form elaborates on the
associations between Employee, Competence and Training in the domain
model.
16
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page 17
Even though some vendors show particular interest in adding code generation
facilities to their modeling or development environments, in this case we
specifically chose 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 a fast pace. Furthermore, it increases traceability between design and code, and
lowers the costs of application maintenance.
We do not expect code generation to be perfect, but it does not 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 on fine tuning the user interface. Because it is fairly easy to create new
templates simply by investigating existing code, this approach saves time and
effort in a varied number of scenarios and development environments. It has
proven successful in (partly) generating solutions 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.
Pragmatic model-driven development using smart use cases and domain-driven design 17
WhitePaper-Grey-PragmaticModel.qxp:V9 4/09/09 12:39 Page C1
www.capgemini.com
About Capgemini
and the Collaborative Business Experience™
Authors:
Sander Hoogendoorn,
Principal Technology Officer, Capgemini
Rody Middelkoop,
Senior Technology Consultant, Avisi
Robert de Wolff,
Senior Technology Consultant, Capgemini
Email:
[email protected]
Web:
www.accelerateddeliveryplatform.com
www.smartusecase.com
www.sanderhoogendoorn.com
Tecno-ST-072009
Copyright© 2009 Capgemini. No part of this document may be modified, deleted or expanded by any process or means
without prior written permission from Capgemini. Rightshore® is a trademark belonging to Capgemini.