dcns mdday2010

d / to

roits r

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.

emmanuel.grivot@dcnsgroup.com

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

BARRACUDA

PA CDG

Frigate

Communication

Combat Management

System

Optronic

Electronic Warfare

Surveillance radarIR

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

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

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

+identification

+kinematic

Identification

<<interface>>

Kinematic

<<interface>>

<<Entity>>

Tracks component decomposition:

Presentation, Logic and Data layers

TracksDataEvents

TrackId

TracksData

<<ProducedComponentEvents>>

<<ProvidedComponentServices>>

theTracks

trackId

TracksLogic

TracksDataServices

<<UsedComponentServices>> 1

TracksServices

TracksPresentationTracksLogicServices

<<UsedComponentServices>>

<<ConsumedComponentEvents>>

TracksEvents

:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

notifyCreatedTrack( )

Tracks component:

MDE, CBSE, ED - SOA

TracksEventsTracksServicesTracks

<<ProducedComponentEvents>> <<ProvidedComponentServices>>

Watch tracks

Delete track

Modify track

Create track

User Manage Tracks

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

TracksPresentation TracksLogic

TracksData

trackId

theTracks

TracksServices TracksEventsTracks

Presentation, Logic and Data layers

TracksDataEvents

TrackId

TracksData

theTracks

trackId

TracksLogic

TracksDataServices

TracksServices

TracksPresentationTracksLogicServices

TracksEvents

:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

TracksPresentation component Overview:

<<Presentation layer>>

Tracks Interface

TracksPresentation

TracksLogic Interface

TracksData Interface

TracksServices TracksEvents

<<ProvidedComponentServices>> <<ProducedComponentEvents>>

TracksLogicServices

TracksDataEvents

TracksView component Detailed

Tracks Interface

TracksPresentation

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

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

TracksDataEvents

TracksDataServices

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

TracksData component unit tests:

black box and white box with JUnit

TracksDataServices

TracksData

tracksDataServices

tracksDataUnderTest

TracksDataServicesTest

testToDo()

Black Box Unit Test

description

TracksDataImplTracksDataServicesImplTest

setup()

White Box Unit Test

description

Annotations

@Before

Local deployment HelloTracksWorld application

TracksPresentation

TracksDataEvents

TracksDataServices

TracksData

TracksLogicServicesTracksLogic

Locale interfaces.Locale interfaces.

Locale

interfaces.

TracksLogicServicesTracksLogic

Remote deployment HelloTracksWorld application:

<<Remotable>> QoS

ServerJVM 1

ClientJVM 2

TracksPresentation

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 {

+TracksLogicServices

<<ComponentServices, >>

Remote QoS components interface

@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

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

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

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

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

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

Component

Software

Engineering

AOPAspect

Oriented

Programming

(Separation of

Concerns)

ED - SOA

Event Driven -

Service

Oriented

Architecture

(multi-tier

architecture)

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”

+ operation()

+ operation ()

+ operation1 ()

+ att5

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

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

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

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() { ... }

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

model driven day

agile method

track user

createtrack tracks

uml tools rex

dcns group

dcns acts

watch tracks

Technology

dossier de presse dcns 2011

questoes sobre dcns

2010 dcns annual report

euronaval2010 dcns

magazine - safran · electromagnetic detection sensor. it...

dcns 62 interieur v4...relevant to neurodevelopmental...

aquo d5.3 assessment urn reduction rev1 · issued by...

naval experts de dcns : fremm

dcns convention

cnd robotisés : les applications à dcns · © dcns june...

for personal use only · a 23.5% equity stake (q1 2010) ......

dcns press kit

ifremer-onr workshop « durability of composites in a...

cyber security in the maritime sector · wednesday, october...

journée innovation dcns - axe central opération du futur

dcns project laser scanner faro ls 420 & model with inovx...

naval equipment warship equipment - naval · pdf filenaval...

dcns 44...

50 emmanuel brochard - dcns

©dcns 2007 - all rights reserved / tous droits réservés...