dcns mdday2010

DC

NS

20

07

-a

ll r

igh

ts r

ese

rve

d / to

us d

roits r

ése

rvé

s

Emmanuel GRIVOTArchitecte logiciel

DCNS / Système Information et Sécurité / Direction Technique et Technologique

MDDAY 2010

25 novembre 2010

Model Driven Engineering +

Aspect Oriented Programming =

Agile Model Driven Architecture

2 / 34 | 25 nov 2010 | Model Driven Day 2010 : Agile Model Driven Architecture

Resume

Emmanuel GRIVOT

Software architect

Naval defense industry

Thomson CSF

THALES Naval France

DCNS : Système Information et Sécurité /Direction Technique et Technologique

22 years background inCombat Management System (CMS) software development.

[email protected]


Summary

Model Driven Engineering +

Aspect Oriented Programming =

Agile Model Driven Architecture

ou comment réunir, avec succès,

le MDA pragmatique et l'agilité.


AGENDA

1. DCNS

2. Combat Management System

3. JACOMO component model

4. Demonstration with Modelio

5. UML tools REX

6. Perspectives, Q & A


AGENDA

1. DCNS




5. UML tools REX



DCNS : Naval in Europe and worldwide

The DCNS Group is a leading European player

for naval defense systems.

DCNS acts as prime contractor of the armed vessels and their support.

12 200 employees working across France.

2,4 billion euros in turnover.

9,9 billion euros of backlog.

1 / 3 of its international business and cooperation.

21 Sites:

Paris, Bagneux, Cherbourg, Brest, Toulon, Lorient, Ruelle, …


Different ships and submarines

HORIZON

FREMM

BPC

BARRACUDA

PA CDG


Frigate

Communication

Combat Management

System

Optronic

sonar

Electronic Warfare

Surveillance radarIR

sonar

Navigation radar

missiles

gunmissilesmissiles


AGENDA

1. DCNS




5. UML tools REX



Combat Management System (CMS)

Tailored information system

Network

Data Link

Navigation System Radar Navigation Radar Sonar IRElectronic

Warfare

TLSMissiles SurfGunMissile AirDLS

Combat Management System


AGENDA

1. DCNS




5. UML tools REX



Agility and Model Driven Engineering ?

Agility as:

“ the ability to successfully respond to change ” *

Two kinds of change:

Functional changes

Technology changes

Solutions:

Processes: agile method, scrum, xp, …

Technologies: AOP, …

Tools: MDE, MDA, UML, …

…

* http://www.infoq.com/news/2010/06/c2-military-gets-agile

http://www.agilemodeling.com/


JACOMO component model

AOP : Quality of Services (SoC)

<<Remotable>>

CBSE : JACOMO composite component model

JACOMO Component

MDE : UML profile and middleware independence

<<ProvidedServices>> <<UsedServices>>

<<ConsumedEvent>> <<ProducedEvent>>

ED – SOA : Services and Events ports

*

0..1


AGENDA

1. DCNS




5. UML tools REX



Track:

Domain entity concept

User can Create, Read, Update and Delete Tracks (CRUD pattern)

HelloTracksWorld application

Track domain concept

Track

1

+identification

1

+kinematic

Identification

<<interface>>

Kinematic

<<interface>>

Track

<<Entity>>


Tracks component decomposition:

Presentation, Logic and Data layers

TracksDataEvents

TrackId

Track

TracksData

<<ProducedComponentEvents>>

*

<<ProvidedComponentServices>>

theTracks

*

trackId

TracksLogic

TracksDataServices

<<UsedComponentServices>> 1


TracksServices

TracksPresentationTracksLogicServices

<<UsedComponentServices>>

0..1


<<ConsumedComponentEvents>>

TracksEvents


*


:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

createTrack( )

createTrack( )

notifyCreatedTrack( )



Tracks component:

MDE, CBSE, ED - SOA

TracksEventsTracksServicesTracks

*

<<ProducedComponentEvents>> <<ProvidedComponentServices>>

Watch tracks

Delete track

Modify track

Create track

User Manage Tracks

<<include>>

<<include>>

<<include>>

<<include>>


:Tracks:User

HelloTracksWorld Services and Events

CRUD pattern (Create Read Update Delete)

createTrack( )

Tracks


*


TracksEvents

<<interface, ComponentEvents>>

TracksServices

<<interface, ComponentServices>>

notifyDeletedTrack(in aTrackId : TrackId)

notifyUpdatedTrack(in aTrackId : TrackId, in aTrack : Track)

notifyCreatedTrack(in aTrackId : TrackId, in aTrack : Track)

deleteTrack()

updateTrack()

createTrack()




CBSE, three layers components

Tracks Interface

Track

TracksPresentation TracksLogic

TracksData

trackId

*

theTracks

TracksServices TracksEventsTracks

1 1

1

*



Presentation, Logic and Data layers

TracksDataEvents

TrackId

Track

TracksData


*


theTracks

*

trackId

TracksLogic

TracksDataServices



TracksServices

TracksPresentationTracksLogicServices


0..1



TracksEvents


*


:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

createTrack( )

createTrack( )




TracksPresentation component Overview:

<<Presentation layer>>

Tracks Interface

TracksPresentation

TracksLogic Interface

TracksData Interface

TracksServices TracksEvents

<<ProvidedComponentServices>> <<ProducedComponentEvents>>

*

TracksLogicServices


0..1

TracksDataEvents



TracksView component Detailed

Tracks Interface

TracksPresentation


0..1


TracksLogicServices


TracksDataEvents


TracksEventsTracksServices

deleteTrack(in aTrackId : TrackId)

updateTrack(in aTrackId : TrackId, in aTrack : Track)

createTrack(in aTrack : Track):TrackId





*



TracksLogic component Overview:

<<Logic layer>>

TracksLogicServices

TracksLogic



TracksDataServices


1


TracksLogic component Detailed


TracksLogic


TracksLogicServices




createTrack(in aTrack : Track):TrackId


TracksDataServices




createTrack(in aTrackId : TrackId, in aTrack : Track)


TracksData component Overview:

<<Data layer>>

TracksDataEvents

TracksDataServices

TracksData



* Track

theTracks

*trackId


TracksData component Detailed

TracksData


*


theTracks

*

trackId

Track

TracksDataEvents


TracksDataServices







createTrack(in aTrackId : TrackId, in aTrack : Track)


TracksData component unit tests:

black box and white box with JUnit

TracksDataServices

TracksData

0..1

tracksDataServices

0..1

tracksDataUnderTest

TracksDataServicesTest

testToDo()

Black Box Unit Test

description

TracksDataImplTracksDataServicesImplTest

setup()

White Box Unit Test

description

Annotations

@Before


Local deployment HelloTracksWorld application

TracksPresentation

0..1

TracksDataEvents

TracksDataServices

TracksData

*

TracksLogicServicesTracksLogic

1

JVM

Locale interfaces.Locale interfaces.

Locale

interfaces.


TracksLogicServicesTracksLogic

1

Remote deployment HelloTracksWorld application:

<<Remotable>> QoS

ServerJVM 1

ClientJVM 2

TracksPresentation

0..1

TracksDataEvents

TracksDataServices

TracksData

*

Locale

interfaces.

Locale interfaces.Remote interfaces.

<<Remotable>>

comment

<<Remotable>>

comment


@ComponentEvents

public interface TracksDataEvents {

...

}

PSM +TracksDataEvents

<<ComponentEvents, >>

PIM@ComponentServices

public interface TracksLogicServices {

...

}

PSM

+TracksLogicServices

<<ComponentServices, >>

PIM

Remote QoS components interface

@Remotable

@Remotable

@Remotable can be weaved to

1 RMI (default), 2 JGroups, … others : Web Services, socket, …

Remotable

Remotable QoS

Remotable

Remotable QoS


UML JACOMO component profile for

Architecture Description Language (ADL)

UML PIM JACOMO PSM

Analysis concepts: <<ComponentType>> @ComponentType

<<ComponentServices>> @ComponentServices

<<ComponentEvents>> @ComponentEvents

...

Design concepts: Quality of Service (QoS) << Remotable >> @Remotable

<< Persistable >> @Persistable

<< Asynchronous >> @Asynchronous

...


AGENDA

1. DCNS




5. UML tools REX



Objecteering and Modelio UML tools

Model Driven Engineering need UML tool :

We use objecteering since 2000 for Model Driven Engineering.

100% of the code is inside the UML tool.

JACOMO profile, wizard since 2004.

THALES Systèmes aéroportés collaboration since 2004.

DoD* documents generation (SRS, IRS).

First MDA experiment with AOP since 2005.

Modelio migration: 2010 (JACOMO wizard + SDD)

*DoD: Department of Defense

by


MDE: the lesson we learn

“raise the level of abstraction of the UML model”

MDE: Raise the level of abstraction:

Put your domain, pattern, frameworks, … inside UML tool.

Don’t use UML tool only to input Java code (IDE tools are better).

Use UML for the analysis model only, and keep the code conform to the model, to the architecture.

MDA + AOP: Productivity Advantages

The UML profile and wizard are simple to implement.

Use AOP to weave technical code outside the UML model.

Up to 70% of the technical code for the PSM is removed.

Agility

Functional change, simple code change

Technology change, only AOP weaver change

Pair modeling, Tests first, stand-up meeting, …


AGENDA

1. DCNS




5. UML tool REX



Perspectives

Modelio deployment

medium-scale team and model support (svn)

Some metrics

Total of 1500 JACOMO components (now 700)

Expects to raise productivity x 20 to build software architecture with JACOMO wizard and modelio

UML 2 migration

Native <<component>> for PIM and PSM

JACOMO UML2 profile and wizard for PIM and PSM

by


Questions & Answers

Solve essential complexity

without introducing accidental complexity *:

“The best UML model

is the one you didn’t need to build **.”

Thank You

* Frederick P. Brooks

** “The best line of code is the one you didn't need to write.”


References

References:

Agile Modeling :http://www.agilemodeling.com

Explore Model Driven Architecture and Aspect-oriented Programminghttp://www.devx.com/enterprise/Article/27703/1954?pf=true

The Role of Aspect-Oriented Programmingin OMG’s Model-Driven Architecturehttp://www.aspectprogramming.com/papers/AOP and MDA.pdf

Le point sur la programmation par aspectshttp://www.emn.fr/z-info/ledoux/Publis/tsi01.pdf

http://www.agilemodeling.com/

http://www.devx.com/enterprise/Article/27703/1954?pf=true

http://www.aspectprogramming.com/papers/AOP and MDA.pdf

http://www.emn.fr/z-info/ledoux/Publis/tsi01.pdf




Annexes

The following slides are provided for more details

information.


Software's Chronic Crisis

31% of software are cancel before delivery (Gartner 2002)

52% of software are out of budget: (up to +189% Gartner 2002)

50% of software doesn’t answer to the specification (Gartner 2002)

80% of software are later: (up to x 2..3 Aberdeen)

16% of software arein time, in budget and answer to the specifications

(down to 9% for large software)

Why is this?

complexity


The Cost of Complexity

Complexity augments more quickly than any metrics

Complexity

• more SLoC (Source Line of Code) => more complex

• more complex => more expensive

80..100 KSLoC

SLoC

e1,5


Essential and Accidental complexity

Essential complexityis caused by the problem to be solved.Essential complexity must be mastered.

To solve essential complexity

without introducing accidental complexity.

Accidental complexityis caused by the approach chosen to solve the problem.Accidental complexity must be reduced.

Frederick P. Brooks

The Mythical Man-Month (1975-1995)

Essence and Accidents of Software Engineering


Platform 1 Pf 2 Pf 3 Pf 4 Pf 5

C++, Java, C#, ADA, CORBA, CCM, COM/DCOM, EJB, .NET, XML, Web services, SCA, OSGi, Spring…

Rapid technological evolution

Non-functional requirements evolution

Response time, security, fault tolerance, availability, transactions, persistence …

Non functional

requirements 1

Non functional

requirements 2

Non functional

requirements 3

Non functional

requirements 4

The Three Lifecycles to connect

Business Model 1 BM 2 BM 3

Functional requirements quasi-stability

Function coverage 1, Function coverage 2…

System lifetime

10-30 years

Non functional lifetime

10-20 years

Platform lifetime

5-10 years


AGENDA

1. DCNS


3. Model Driven Architecture approach

4. Aspect Oriented Programming approach

5. JACOMO technology

6. Objecteering UML tool



Model Driven Architecture approach:

How software systems will be build

Model Driven Architecture (MDA)is a software design approachbase on the Model Driven Engineering.

It was launched by the Object Management Group (OMG)in 2001.

MDA provide an approach to the challengeof business and technology change.

MDA separates application logic fromunderlying platform technology inside two different models:

Platform Independent Model (PIM) focus on business logic

Platform Specific Model (PSM) focus on platform technology


Model Driven Architecture: two different flavors

Translationist

PIM abstracts out execution platform technology details

PSM or code is not edited: all behavior expressed in PIM model

Translationist MDA requires executable UML: Action Semantics …

Elaborationist

PIM abstracts out execution platform technology details

PSM is an elaboration (i.e. fills in the platform detail)

PSM or code can be edited: to add behavior

A long way to improve the tools?


UML tool

Model Driven Architecture tools

Platform Independent Model:UML

Platform Definition Model:Java, C#, Ada, Corba, RMI, …

Platform Specific Model:UML

Code:

Java, C#, Ada, …

Models

transformations

bind a domain model

to a technology

(Query / View / Transformation)

code generation

Runtime:

binary

compilation

execution


Model Driven Architecture

Large project : we use elaborationist process

Large MDA project feedback:

UML 1.4 Platform Independent Model (PIM)

1200 domain classes (data tier)

Platform Definition Model = Corba Component Model

UML 1.4 Platform Specific Model (PSM)

UML -> IDL -> Java: 1200 x 3 = 3600 Java classes

Code edition to add behavior (logic tier)

Drawbacks

2..3 days non stop for PIM to PSM model transformationand code generation

Fat PSM model (x3 to x4 size of PIM)

behavior code depends on Corba classes!

Complex tools and not scalable!


AGENDA

1. DCNS








Aspect Oriented Software Development

AOSD involves three distinct development steps:

1. Aspectual de-composition

Decompose the requirements to identify different aspects.

3. Aspectual re-composition

The re-composition process, also known as weaving.

2. Aspect implementation

Implement each aspect separately


Bind the Domain Model to the Runtime Platform

Raise the level of abstraction: omitting detail

MDA and AOP solve this problem differently

MDA says: “let's add another abstraction layer”

AOP says: “no, let's not. In fact, let's remove some”

Domain classes*

platform classes

aspects

weaving

AOP approach

Domain classes

platform classes

models

transformation

MDA approach

Analysis:

Runtime:

*Plain Ordinary Java Object


AGENDA

1. DCNS




5. JACOMO component




JACOMO component

CBSE

Component

Based

Software

Engineering

AOPAspect

Oriented

Programming

(Separation of

Concerns)

ED - SOA

Event Driven -

Service

Oriented

Architecture

(multi-tier

architecture)

MDE

Model Driven

Engineering

(Model Driven

Architecture)

The four puzzles

to build JACOMO component


UML class diagram to Java code:

shared abstraction, shared vocabulary

package demo;

public class B extends A implements I {

public int att1 = 10;

protected boolean att2 = true;

float att3; // = 0.0

private String att4; // = null

public B att5; // = null

public void operation() {};

public static void operation1() {};

}

Only one Java file “./demo/B.java”

demo

A I

+ operation()

B

+ operation ()

+ operation1 ()

+ att5

0..1

<<implements>>

<<extends>>

+ att1 : integer = 10

# att2 : boolean = true

~ att3 : real

- att4 : string

One B UML class

Java PSM close to

class diagram PIM


The middleware include the platform technical code advices,

multi-threading, transaction,

logging and debugging,

remote,

state replication, state persistence,

asynchronous,

…

All code advices are put inside middleware layer

Component =

domain logic +

technical concerns


Architectures:

Functional and Technical Y cycle separation

Design

Engineering

Analysis Technology

Technical

Architecture

Technical

solutions

Software

Architecture

Technical

aspects

Functional

Architecture

Logical

Architecture

Use Cases

Software

components

Architectural

Principles

Deployed

Architecture

System

ArchitectureSoftware

platform

Physical

platform


Domain Logic gap with the Runtime Platform:

How to fill the gap?

Ideal:Domain Logic

Runtime Platform

MDA models transformation:Domain Logic

Runtime Platform

Platform gap:Domain Logic

Runtime Platform

AOP weaving:Domain Logic

Runtime Platformdependency


Problem of dependency:

Application depend on middleware API

middleware X

What goes wrong with classical application layering?

• Application code is build on top of middleware

• No transparency (design dependency on middleware API)

Runtime Platform

If you change the middleware,

you must change some application code.

Application depend on middleware.

Application

middleware Y

Application

Strong dependency with middleware API


+ middleware configuration

middleware X

middleware X bindingmiddleware Y binding

middleware Y

Dependency Inversion:

Application doesn’t depend on middleware

Separate the modules dependency

• Application code is build beside of middleware

Runtime Platform

Application

You can change the middleware without modifying the

application code: separation of concerns.

Application can be used with different

middleware at the same time: interoperability

NO dependency with the PDM API


JACOMO component modelis middleware agnostic to promote

Model Driven Architecture

QoS

events notification between component

remote services and events between components.

asynchronous invocation for services and events .

persistence for components parameters.

component state replication.

software transaction memory.

JACOMO is middleware agnostic


UML tool

AOP tool

Aspect-Oriented Model Driven Architecture (AO-MDA)

and tools connection

code compilation

Platform Independent Model: (no behavior)

UML + Component profile

Platform Specific Model 1: no middleware

Java code + @nnotation + behavior

custom Java

code generator

AOP

weaver

Platform Specific Model 2: with middleware

JVM runtime: behavior + middleware aspects

@nnotation

(point cut)

middleware

(code advice)

code execution

Platform Definition Model:Java + middleware

<< stereotype >>

{ tag }

@nnotations

1 / 12 LoC

1 / 4 LoC

4 / 4 LoC


Component-Based Software Engineering

with component model profile

<<ComponentType>>

<<provided

Services>>

<<produced

Events>><<consumed

Events>>

<<used

Services>>

<<provided

Parameters>>

<<used

Parameters>>

JACOMO

Component

Multi-tier Event Driven Service Oriented Architecture


AOP tool

UML tool

JAva COmponent MOdel :

the 7 step process

<<ComponentImpl>>

CompAImpl

<<ComponentType>>

CompA

1: Platform Independent Model:Domain analysis

Design: QoS

2: Platform Specific Model 1:Design

Implementation (behavior)

7: runtime:

JVM6: code compilation

and weaving

3: custom code

generation

@ComponentImpl

public class CompAImpl { ... }

@ComponentType

public interface CompA { ... }

@ComponentImpl

public class CompAImpl {

}

4: add behavior with IDE

{ Remotable }

public void m() { ... }

5:


JACOMO PSM

raise the PSM level of abstraction

JAva COmponent MOdel

is an Domain Specific Language (internal DSL)for Java platform, which is an

Architecture Description Language (ADL)

with Separation of Concerns (SoC)for multi-tier

Event Driven Service Oriented Architecture(EDSOA) for

Component-Based Software Engineering (CBSE).


PIM UML <<stereotype>> and PSM JACOMO @nnotations

specification and analysis

UML Java<<ComponentType>> @ComponentType

<<ComponentServices>> @ComponentServices

<<ComponentEvents>> @ComponentEvents

<<ComponentParameters>> @ComponentParameters

<<ProvidedComponentServices>> @ProvidedComponentServices

<<UsedComponentServices>> @UsedComponentServices

<<ProducedComponentEvents>> @ProducedComponentEvents

<<ConsumedComponentEvents>> @ConsumedComponentEvents

<<ProvidedComponentParameters>> @ProvidedComponentParameters

<<UsedComponentParameters>> @UsedComponentParameters

<<AggregatedComponent>> @AggregatedComponent

<<ComposedComponent>> @ComposedComponent


PSM UML <<stereotype>> and PSM JACOMO @nnotations

PSM design and implementation

UML Java

<<ComponentImpl>> @ComponentImpl

<<ComponentItem>> @ComponentItem

<<UsedComponentEventsSubscribe>>@UsedComponentEventsSubscribe

<<UsedComponentEventsSubscribeDelegate>>@UsedComponentEventsSubscribeDelegate

<<UsedComponentContext>> @UsedComponentContext

<<Resource>> @Resource


UML <<stereotype>> and JACOMO @nnotations: QoS

PIM design

UML Java

<< Remotable >> @Remotable

<< Synchronous >> @Synchronous

<< Asynchronous >> @Asynchronous

<< Replicable >> @Replicable

<< NotReplicable >> @NotReplicable

<< Reconfigurable >> @Reconfigurable


UML << stereotype >> and JACOMO @nnotations : QoS

PSM design and implementation

UML Java

<< SingleThreaded >> @SingleThreaded

<< MultiThreaded >> @MultiThreaded

<< SynchronizedRead >> @SynchronyzedRead

<< SynchronizedReadWrite >> @SynchronyzedReadWrite

<< Transactional >> @Transactional


Architecture to master the cost

To solve essential complexity

without introducing accidental complexity.

Complexity

• To reduce accidental complexity =>

• reduce costreduce

accidental

complexity

Metrics

master

essential

complexity


AGENDA

1. DCNS








THALES Systèmes aéroportés collaboration

Since 2003, share same point of view

MDA Processes

Architecture: multi-tier SOA and EDA

Component based architecture

Since 2004, co-development,

Technical and domain JACOMO components for HCI

Tools: (UML tool with profile, maven, eclipse plugin, sonar)

UML tool: Objecteering

Model Driven Engineering: all is inside the UML tool(specification, analysis, design, implementation code, unit tests).

Unique global id of the tool allows diff / merge between concurrent development.


More than 1200 JACOMO components from 8 projects

Metrics for one project

78 JACOMO components, 171kLoc (2,19kLoc / component).

40% code generated from UML tool (class diagram).

60% body of the methods hand written inside IDE (eclipse).

17% Loc for components interface.

48% Loc for components implementation.

35% Loc for components unit tests.

100% code inside the UML tool, include unit tests.

Comparison with data distribution traditional MDA approach

Remove up to 70% LoC for component state replication QoS

Some JACOMO Metrics

with objecteering tool

dcns mdday2010

Technology

model driven day

agile method

track user

createtrack tracks

uml tools rex

dcns group

dcns acts

watch tracks