1

J2EE .NET Application Generator

How to Leverage UML/MDA Investments in the Enterprise?© fbarbier@netfective.com

2

Theme and Objectives of this Tutorial

Theme: Proving that Model-Driven Development (MDD) is actually a cost-effective 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

3

Headlines

1st part (this tutorial)

Revisiting MDDModelingEconomical IssuesTechnical DiagnosisThe controversy is not yet closed…What MDD really is?

Requirements Engineering IssuesThe Seven Sins of Modeling (by B. Meyer)Enterprise Model-Driven Development, a First CharacterizationValidation of Requirements from the End-users’ Viewpoint

GUI PrototypingGUIs’ Kinematics

Data ProcessingExample of a Complex Service

BLU AGE™ Coercive Modeling Framework (Metamodel)PSM Construction and ManagementPSM Construction and Management, cont’dThe BSP MetaphorBSPs within the BLU AGE™ EMDD MethodEnterprise Model-Driven Developement with BLU AGE™, a Summary

2nd part (case study): Effective time-to-market application delivery with the BLU AGE™ software factoryThis 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

4

Revisiting MDDModeling

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

5

Revisiting MDDEconomical 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…)?

6

Revisiting MDDTechnical 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?

7

Revisiting MDDThe 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)

8

Revisiting MDDWhat 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!)

9

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…)

10

The Seven Sins of Modeling (by B. Meyer)

Ambiguity

Contradiction

Forward reference

Noise

Over-specification

Silence

Wishful thinking

11

Requirements Engineering IssuesAmbiguity

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, (…)”.

12

Requirements Engineering IssuesContradiction

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

13

Requirements Engineering IssuesForward 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.

14

Requirements Engineering IssuesNoise

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.

15

Requirements Engineering IssuesOver-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 over-

specification.

16

Requirements Engineering IssuesSilence

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.

17

Requirements Engineering IssuesWishful 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.

18

Requirements Engineering IssuesEMDD, 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?

19

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?

In EMDD, a good balance is to enhance the built models with more concrete software artifacts: GUIs

Take conviction decision Take shortened sentence decision decision

Take final discharge decision

Take judicial decision Under remand Incarcerate

NYCP director

This use case will be treated as a

maintenance task which corresponds to some

requirements’ enhancement

20

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:

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

This use case will be treated as a

maintenance task which corresponds to some

requirements’ enhancement

Take conviction

decision

Home

Submit

…

21

GUI PrototypingGUIs’ 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)

22

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 OCLbody: PrisonerBO.allInstances()->select(p | p.conviction->isEmpty())

context PrisonerBO::under_remand() : List -- native HQLbody:

FROM com.FranckBarbier.UML.New_York_City_Penitentiary.Business_model.Business_objects.PrisonerBO p WHERE SIZE(p.convictions) = 0

23

Data ProcessingExample of a Complex Service

24

BLU AGE™ Coercive Modeling Framework (Metamodel)

1

signature’s member

«metaclass» Blu Age Entity

«metaclass» Blu Age Business Object

1

1

«metaclass» Blu Age Service *

«metaclass» Blu Age Complex Service

«metaclass» Blu Age Controller

1..*

implementations

interface

* superclass

subclass

«metaclass» Blu Age Screen Process

1

1

«metaclass» Blu Age Use Case 1..*

«metaclass» Blu Age Business Rule

text : String type : Blu Age Business Rule Formalism

* business object’s

operation

1

«enum» Blu Age Business Rule Formalism

OCL HQL SQL

EJB QL

«metaclass» Blu Age Service Operation

1

*

«metaclass» Blu Age Screen

1

main

*

external

{xor}

* * user

context Blu Age Service inv: implementation->isEmpty() implies user->notEmpty()

* /caller *

/callee

1 1

1..*

25

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., XML-like) 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.

transformation

PIMs

PIMs

Platform constraints’ integration and satisfaction

transformation

PSMs

Deployable applications

transformation

1

2

3

test

maintenance

4

26

PSM Construction and Management, cont’d

PIM

transformation

PSM

J2EE

.NET

J2EE 1.4

J2EE 5

Struts

JSF

Persistence framework

Presentation framework

Version Technology

Native CMP EJBs

Hibernate

SJSAS

JBoss

J2EE server

…

…

Etc.

… … … … …

27

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.

t r a n s f o r m a t i o n

P I M s

P I M s

B S P s

t r a n s f o r m a t i o n

P S M s

D e p lo y a b le a p p lic a t io n s

t r a n s f o r m a t i o n

1

2

3

t e s t

m a i n t e n a n c e

4

28

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)

29

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 technology-independent 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)

30

Thanks for your attention!

Any questions?

PS: See you at 09:45!

31

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