J2EE .NET Application Generator
How to Leverage UML/MDA
Investments in the Enterprise?
© fbarbier@netfective.com
1
Theme and Objectives of this Tutorial
Theme: Proving that Model-Driven Development (MDD) is actually a costeffective software development technique, is a current issue. Even if one
may consider that MDD is nowadays mature, there is no in-depth survey
which definitively demonstrates that MDD improves productivity in software
development projects
Key objective: The switch from MDD to Enterprise Model-Driven Development
(EMDD) illustrates the move from a small-scale software development
technique to an authentic industrial process. This means that software must
be constructed based on experienced techniques such as those in the
manufacturing domain for instance. That is our vision of the emergent
notion of “software factory”
What about code generation? Code generation is obviously a key link in the
development chain, but EMDD cannot be reduced to this mechanism. Other
issues are important: requirements engineering, GUI design and integration
in models, end-to-end platform-dependent constraint satisfaction and
cheapest round-trip maintenance
2
Headlines
1st part (this tutorial)
Revisiting MDD
Modeling
Economical Issues
Technical Diagnosis
The controversy is not yet closed…
What MDD really is?
Requirements Engineering Issues
The Seven Sins of Modeling (by B. Meyer)
Enterprise Model-Driven Development, a First Characterization
Validation of Requirements from the End-users’ Viewpoint
GUI Prototyping
GUIs’ Kinematics
Data Processing
Example of a Complex Service
BLU AGE™ Coercive Modeling Framework (Metamodel)
PSM Construction and Management
PSM Construction and Management, cont’d
The BSP Metaphor
BSPs within the BLU AGE™ EMDD Method
Enterprise Model-Driven Developement with BLU AGE™, a Summary
2nd part (case study): Effective time-to-market application delivery with the BLU
AGE™ software factory
This is a demo. which will occur from 09:45 to 11:00 and is intended to illustrate the
emergent idea of Enterprise Model-Driven development laid down in this tutorial
3
Revisiting MDD
Modeling



4
Modeling is based on the following principle: Models are the expression of some observed/captured
properties of a system or a software system to the detriment of other properties which gain by
being (temporarily) hidden; “Approximation” (see above) holds true
The UML and MDA communities (authors, experts, users…) consider “modeling” as a semi-formal
(almost graphical) specification technique; “Denotation” (see above) does not really hold true
These two “imperfections” must to be kept in mind for any analysis of what currently is, and will be
in the future, Model-Driven Development
Revisiting MDD
Economical Issues
•
How to leverage UML/MDA investments in the Enterprise? It is “simple”, by definitively
proving that MDD methods are more beneficial than alternate/competitive software
development methods, such as Rapid Application Development (RAD), no method at all,
<your own method here>…
•
MDD is in essence based on the precepts of software engineering which a priori lead to the
following deductive paths:
•
Models => abstraction => technology independency => quicker adaptation => reduced
maintenance cycles => savings
•
Models => requirements’ formalization supports => early versus late error/mismatch detection and
correction => savings
•
Models => business/domain-focused software development approach => capitalization, lasting
quality => reuse => savings
•
Does this theory really comply with the observed practice? Besides, the cost of entering
MDD is significant. What about the expected return on investment linked to the MDD
adoption (for a company, a division, a team…)?
5
Revisiting MDD
Technical Diagnosis
•
From experience, developers, even engineers, consider the building of models to be a waste
of time:
•
Either models are not executable (i.e., inexpressive, non tangible…)
•
Or this inequality holds true: (time spent on model elaboration + time spent on model transformation
into code) >= direct coding and code tuning
•
Use models sparingly! For instance, modeling GUIs (through UML State Machine Diagrams
for instance) is not realistic in terms of productivity. Interface builders are much too strong
competitors and enable a more efficient requirements’ validation process for end-users
•
Within some MDD processes, code generation often matches to the generation of code
templates whose final touches may become sizeable
•
The integration and satisfaction of platform constraints when deriving Platform-Independent
Models (PIMs) into Platform-Specific Models (PSMs), are subject to tricky software
architecture and configuration problems
•
In the field of software development like in many other disciplines, this adage is always true:
“Keep it simple!” Are models a good solution for making software development simple?
6
Revisiting MDD
The controversy is not yet closed…
“Model multiplicity mandates integrity maintenance among a system’s various models,
increasing exponentially with the number of diagrams. The recursive ripple effect of
changing any model, thus triggering the potential need to modify other diagrams,
renders intractable the problem of keeping coherent all system views.” (D. Dori,
“Why Significant UML Change is Unlikely”, CACM (45)1, pp. 82-85, 2002)
“First, in attempting to address so many disparate needs, UML 2.0 has become
enormous and unwieldy. History has not been kind to kitchen-sink languages, as
their complexity has tended to impede their successful adoption. The use of UML
profiles can help with this significantly by enabling knowledgeable developers to
eliminate any parts of UML that they do not need.” (our underlining, B. Hailpern, P.
Tarr, “Model-driven development: The good, the bad, and the ugly”, IBM Systems
Journal 45(3), pp. 451-461, 2006)
7
Revisiting MDD
What MDD really is?
“It has been said that democracy is the
worst form of government except all the
others that have been tried.”
Sir
Winston Churchill
“MDD is the worst form of software
development except all the others that
have been tried.”
Franck
Barbier (thank you Winston!)
8
Requirements Engineering Issues
 The prominent idea of model transformation which is implied by the MDA
initiative (the “PIMs to PSMs” scheme) has masked the challenge of
modeling/specification itself: Transforming models whose semantics (from
the requirements’ viewpoint) is poor, inevitably leads to low-quality or
incorrect operational models and applications
 One key shortcoming of MDD is the lack or absence of reasoning about
the discovery, capture and consistent formalization of requirements in the
form of models
 In fact, neither UML nor MDA are “intelligent” technologies in the sense
that they guarantee the production of requirement-compliant models; The
latter being more or less close to running environments
 There is however no miracle: Nowadays, requirements engineering
techniques are still “manual” as shown, with in New York City Penitentiary
case study (please read the text…)
9
The Seven Sins of Modeling (by B. Meyer)
Ambiguity
Contradiction
Forward reference
Noise
Over-specification
Silence
Wishful thinking
10
Requirements Engineering Issues
Ambiguity
Ambiguity is characterized by an
element in the requirements
document that makes it possible to
interpret a feature of the problem in
at least two different ways. For
instance, the prison director said:
“However, an incarceration decision
has obviously been taken against
him.” Later in the text, he talked
about another kind of decision: “I
must also tell you that we include all
the judicial decisions related to the
incarceration in the prison file, (…)”.
11
Requirements Engineering Issues
Contradiction
Contradiction covers the idea that two
or more elements define a feature of
the system in an incompatible way.
In the requirements document, “the
motive of the case” is recorded on
each prison file. It represents the
motive of the case for which a given
prisoner was incarcerated. However,
this prisoner may be involved in
other criminal cases with probably
different motives. Later, answering to
a question, the penitentiary director
said: “Yes, it is true that for the
same crime there can be convicts
condemned for different motives.”
12
Requirements Engineering Issues
Forward Reference
Forward reference refers to an
element that uses features of the
problem not defined until later in the
text. A forward reference is not
really a source of errors but
disorients modelers in their thought
process. For instance, the prison
director introduces early in the
conversation the important notion of
“a prisoner under remand” while the
triggering question was not about
this point: “Can one prisoner enter
the prison in relation with several
criminal cases?” In fact, a prisoner
under remand has no conviction
decisions pronounced against him.
13
Requirements Engineering Issues
Noise
Noise is observable through the
presence in the text of an element
that does not carry information
relevant to any feature of the
problem. Like forward references,
noises cause interferences in the
modeling thought and process. For
instance, at a euphoric outbreak, the
director said: “However, since I’ve
been director of this prison, there
have been no more prison breaks!”.
What is the relation with the
information system the modeler is
currently designing? None.
14
Requirements Engineering Issues
Over-specification
Over-specification is the
presence in the text of an
element that does not
correspond to a feature of the
problem, but to features of a
possible solution. The notion of
“a prisoner under remand” is a
possible source of overspecification.
15
Requirements Engineering Issues
Silence
Silence is the worst sin. It is
the existence of a feature of
the problem that is not
covered by any element of
the text.
16
Requirements Engineering Issues
Wishful Thinking
Wishful thinking corresponds to an
element that defines a feature of the
problem in such a way that a
candidate solution cannot realistically
be validated with respect to this
feature. In the requirements text,
the question “For a given criminal
case, can you have several
prisoners?” yields the response “Yes,
but we try to avoid it.”. This answer
is obviously a demand, but it
contradicts reality.
17
Requirements Engineering Issues
EMDD, a First Characterization
 Any requirements’ misunderstanding leads to erroneous entry PIMs. As a
result, the derived PSMs are semantically incorrect even if these PSMs
may be considered as technically sound
 Making mistakes is suited to human beings. The ability to manage the
upstream models (PIMs) with great agility is thus a key expectation of an
EMDD method. In fact, EMDD aims at enhancing MDD with robust
requirements engineering techniques. More simply, these requirements
engineering approaches must be sin-aware
 The intrinsic complexity of the NYCP case study shows that dealing
concurrently with requirements and technology can be extremely
detrimental to productivity. This is the idea of separation of concerns
 What about anticipated/unanticipated maintenance at the requirements’
formalization level? For instance, how to enhance the functionality of the
NYCP information system by being able to know each motive per prisoner
and per incrimination case?
18
Requirements Engineering Issues
Validation of Requirement from the End-users’ Viewpoint
 Models are abstract in the pejorative sense and thus not understandable
by the average layman
 While abstraction is a software quality factor, it often impedes the
validation of the formalized requirements
 Even if some model types, namely UML Use Case Diagrams and UML
Object Diagrams, are much more intelligible, an overdose of models still
exists. How can one counter this phenomenon?
NYCP director
Incarcerate
Take judicial decision
Take conviction decision
Take final discharge decision
Under remand
This use case will be
treated as a
maintenance task which
corresponds to some
requirements’
enhancement
Take shortened sentence decision
decision
 In EMDD, a good balance is to enhance the built models with more
concrete software artifacts: GUIs
19
GUI Prototyping
 Prototyping GUIs is the best solution to attenuate the nebulous look & feel
of models and to efficiently integrate all stakeholders in the development
process
 For instance, use cases may be straightforwardly and easily exemplified:
This use case will be
treated as a
maintenance task which
corresponds to some
requirements’
enhancement
…
Submit
Take conviction
decision
Home
 Based on the RAD paradigm and independently of the proven (but limited
in scope) strengths of this development paradigm, the above approach
succeeds if and only if the GUIs’ XML-based descriptions are intertwined
with similar descriptions of models
20
GUI Prototyping
GUIs’ Kinematics
 In EMDD, the consistent integration of GUIs and models occur through
UML Activity Diagrams, as follows:
 For instance, the take_conviction_decision event above is associated with
an equivalent tag in the XHTML file, which embodies the Home Web page
(home_screen state in the above activity diagram example)
21
Data Processing
 Two supports for data processing exist: Services (which are coarse-grained
functions) and operations of business objects (which are fine-grained
functions, i.e., business rules)
 Complex services may call other elementary services. The latter are
stereotyped by means of BLU AGE™ predefined stereotypes: <<create>>,
<<update>>, <<delete>>… The functional content of complex services are
expressed by means of UML Sequence Diagrams (see next slide)
 Complex services may also call operations of business objects, which are
themselves stereotyped (<<ocl_impl>>, <<ocl_sql>>…). The functional
content of operations of business objects may take different forms:
context PrisonerBO::under_remand() : Set(PrisonerBO) -- pure OCL
body: PrisonerBO.allInstances()->select(p | p.conviction->isEmpty())
context PrisonerBO::under_remand() : List -- native HQL
body:
FROM com.FranckBarbier.UML.New_York_City_Penitentiary.Business_model.Business_objects.PrisonerBO p WHERE
SIZE(p.convictions) = 0
22
Data Processing
Example of a Complex Service
23
BLU AGE™ Coercive Modeling Framework (Metamodel)
1
«metaclass»
Blu Age Use Case
1..*
«metaclass»
{xor}
Blu Age Screen Process
1..*
1
«metaclass»
Blu Age Entity
1
implementation
s
subclass
1
interface
business object’s
operation
context Blu Age Service inv:
implementation->isEmpty() implies user->notEmpty()
signature’s
member
1..*
*
* user
«metaclass»
Blu Age Complex Service
1
*
text : String
type : Blu Age Business Rule Formalism
*
«metaclass»
Blu Age Service
*
«metaclass»
Blu Age Business Rule
24
*
«metaclass»
Blu Age Controller
superclass
1
«metaclass»
Blu Age Screen
external
1
«metaclass»
Blu Age Business Object
main
1
1
*
1
«metaclass»
Blu Age Service Operation
*
/callee
* /caller
«enum»
Blu Age Business Rule Formalism
OCL
HQL
SQL
EJB QL
PSM Construction and Management

Ideally, an EMDD method is able to consistently bind the models and the GUIs
(phases 1-2). This requires that the latter be expressed in an appropriate (i.e., XMLlike) dialect

Moreover (phase 3), the possibility of integrating platform configuration specificities
and parameters can only occur if these specificities/parameters are expressed in
XML-like format

The 4th step (phase 4) is transparent and corresponds to the code generation itself.
Programs are equipped with many environment/deployment files to match
technology constraints (e.g., J2EE), product constraints (e.g., WebSphere), etc.
maintenance
PIMs
transformation
1
2
Platform constraints’
integration and satisfaction
PIMs
transformation
3
PSMs
transformation
Deployable
applications
25
test
4
PSM Construction and Management, cont’d
Technology
Version
Presentation
framework
Persistence
framework
J2EE server
Etc.
J2EE 1.4
Struts
Native
CMP EJBs
SJSAS
…
J2EE 5
JSF
Hibernate
JBoss
…
…
…
…
…
…
J2EE
PIM
transformation
PSM
26
.NET
The BSP Metaphor
 BLU AGE™ proposes the mechanism of BLU AGE™ Shared Plugin or BSP in
order to make models truly independent of a technology, a product or a
product version, etc.
maintenance
PIMs
transformation
1
2
BSPs
PIMs
transformation
3
PSMs
transformation
Deployable
applications
test
27
4
BSPs within the BLU AGE™ EMDD Method
 Writing BSPs in XML requires a high-level skill and knowledge in software
architecture, software configuration, software deployment, proprietary or
non-proprietary technologies…
 BSPs create an open modeling framework. For instance, new BSPs may be
constructed to take into account new technologies or proprietary
technologies with very special properties
 Current BSP design evolve around SOA technologies
 BSPs are in fact an illustration of this recent analysis: “Each type of model
requires a particular set of skills to produce and to evolve effectively. (…)
the interrelationships between multiple types of models, and potentially,
different modeling formalisms, suggests that it will be difficult for any
given stakeholder (e.g., use case developer, architect, implementor,
tester) to understand the impact of a proposed change on all the related
artifacts.” (B. Hailpern, P. Tarr, “Model-driven development: The good, the
bad, and the ugly”, IBM Systems Journal 45(3), pp. 451-461, 2006)
28
Enterprise Model-Driven Developement with BLU AGE™, a
Summary
 The way by which MDD may gain a widespread adoption in the Enterprise
depends upon the observation of effective economical profits
 Technical factors have impacts on economical factors. Based on this
assumption, MDD must generate shorter development/maintenance
cycles, verifiable technology adaptation, reactivity to requirements’ and/or
technology evolutions
 The BLU AGE™ EMDD method aims at tackling this global problem by
providing a coercive (i.e., rigorous) modeling framework to spare oneself
the possible side-effects of “modeling” (abstraction overdose, lack of
concrete material, weariness of stakeholders…)
 The BLU AGE™ application generator is mainly based on a technologyindependent approach. Models are constructed in UML modelers (the
Magic Draw™ modeler in this tutorial) and recorded in a neutral
standardized format: XMI. All completed investments are thus perennial!
 The BLU AGE™ application generator offers a complete development chain
whichleads to a 100% code generation and deployable application if the
accurate modeling rules of BLU AGE™ are respected
 The BLU AGE INSTITUTE™ provides training and consulting for the BLU
AGE™ tool. It also offers skills, expertise and industrial experience on all
facets of EMDD (UML 2, OCL 2, MDA and their associated tools)
29
Thanks for your attention!
Any questions?
PS: See you at 09:45!
30
Effective time-to-market application delivery with the
BLU AGE™ software factory
This demo. consists in building the
Take shortened sentence
decision use case
From the current status of the
NYCP application, we consider
this construction as a
maintenance task which itself
corresponds to some
requirements’ enhancement
31