Model Driven Engineering + Aspect Oriented Programming ... · Model Driven Engineering + Aspect...

transcript

Emmanuel GRIVOTArchitecte logiciel

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

Journées NEPTUNE 22-23 mai 2013, V1.1

Model Driven Engineering +Aspect Oriented Programming =Agile Model Driven Architecture

2 / 38 | 23 mai 2013 | Journées NEPTUNE 2013 : Agile Model Driven Architec ture

Resume

Emmanuel GRIVOTSoftware architect

Naval defense industry� Thomson CSF / Naval Combat System France

� THALES Naval France

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

25 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

The slides contain animations in slideshow mode.

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 800 employees working across France.

2,9 billion euros in turnover.

14,5 billion euros of backlog.

1 / 3 of its international business and cooperation .

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

commands

Combat Management System (CMS)Command and Control Information System (CCIS)

Network

Data Link

Navigation System Radar Navigation Radar Sonar Infra RedElectronic Warfare

TorpedoMissiles SurfGunMissile AirDecoy Launcher

System

events

services

AGENDA

1. DCNS

5. UML tools REX

Agility and Model Driven Engineering ?Agility as:

The “Command and Control” Military defines Agility as

“the ability to successfully respond to change” *

Three kinds of change:� Functional changes� Ergonomic changes� Technology changes

Solutions:� Processes: agile method, scrum, xp, …� Tools: MDE, MDA, UML, …� Technologies: AOP, …� …

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

JACOMO component

ComponentBasedArchitecture

SoCSeparation ofConcerns

AspectOrientedProgramming

ED - SOA

Event Driven -Service

OrientedArchitecture

multi-layersarchitecture

Model DrivenArchitecture

Model DrivenEngineering

The four puzzlesto build JACOMO component

JACOMO component

<<Replicable>>

SoC : Quality of Services (AOP)

<<Remotable>>

CBA : composite component model

JACOMO Component

ED – SOA : Services and Events component ports

MDA : UML Platform Independent Model profile

<<ProvidedServices>> <<UsedServices>>

<<ConsumedEvent>> <<ProducedEvent>>

<<ComponentType>>

AGENDA

1. DCNS

4. Demonstration with Modelio : JACOMO

5. UML tools REX

Track:� Domain entity concept

� User can Create, Read, Update and Delete Tracks (CR UD pattern)

HelloTracksWorld applicationTrack domain concept

+identification

+kinematics

Identification

<<Data>>

Kinematics

<<Data>>

<<Entity>>

Tracks component:MDE, CBA, ED - SOA

TracksTracksEvents

<<ProducedEvents>>

TracksServices

<<ProvidedServices>>

Manage TracksUpdate track

<<include>>

Control tracks

<<include>>

Create track

<<include>>

Delete track

<<include>>

:Tracks:User

HelloTracksWorld Services and EventsCRUD pattern (Create Read Update Delete)

createTrack( )

onCreatedTrack( )

Tracks

<<ProducedEvents>>

TracksEvents

<<ComponentEvents>>

TracksServices

<<ComponentServices>>

onDeletedTrack(in aTrackId : TrackId)

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

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

deleteTrack()

updateTrack()

createTrack()

Tracks component decomposition:CBA, three layers components

Tracks Interface

TracksPresentation TracksLogic

TracksData

trackId

theTracks

TracksServices TracksEventsTracks

Tracks component decomposition:Presentation, Logic and Data layers

TracksDataEvents

TrackId

TracksData

<<ProducedEvents>>

theTracks

trackId

TracksLogic

TracksDataServices

<<UsedServices>> 1

TracksServices

TracksPresentationTracksLogicServices

<<UsedServices>>

TracksEvents

<<ProducedEvents>>

<<ConsumedEvents>>

:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

onCreatedTrack( )

TracksData component Overview:<<Data layer>>

TracksDataEvents

TracksDataServices

TracksData

<<ProducedEvents>>

* Track

theTracks

*trackId

TracksData component Detailed

TracksData

<<ProducedEvents>>

theTracks

trackId

TracksDataEvents

<<ComponentEvents>>

TracksDataServices

deleteTrack(in aTrackId : TrackId)

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

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

TracksLogic component Overview:<<Logic layer>>

TracksLogicServices

TracksLogic

TracksData Interface

TracksDataServices

<<UsedServices>>

TracksLogic component Detailed

TracksLogic

TracksLogicServices

createTrack(in aTrack : Track):TrackId

<<UsedServices>> 1

TracksDataServices

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

TracksPresentation component Overview:<<Presentation layer>>

Tracks Interface

TracksPresentation

TracksLogic Interface

TracksServices TracksEvents

<<ProvidedServices>> <<ProducedEvents>>

TracksLogicServices

<<UsedServices>>

TracksDataEvents

<<ConsumedEvents>>

TracksView component Detailed

Tracks Interface

TracksPresentation

<<ConsumedEvents>>

<<UsedServices>>

TracksLogicServices

TracksDataEvents

<<ComponentEvents>>

TracksEventsTracksServices

createTrack(in aTrack : Track):TrackId

<<ProducedEvents>>

TracksDataServices

TracksData

tracksDataServices

tracksDataUnderTest

TracksDataServicesTest

testToDo()

Black Box Unit Test

description

TracksData component unit tests:black box and white box with JUnit

TracksDataImplTracksDataServicesImplTest

setup()

White Box Unit Test

description

Annotations

@Before

Local deployment HelloTracksWorld application

TracksPresentation

TracksDataEvents

TracksDataServices

TracksData

TracksLogicServicesTracksLogic

Locale interfaces.Locale interfaces.

Locale interfaces.

AGENDA

1. DCNS

4. Demonstration with Modelio : Hello Tracks World

5. UML tools REX

TracksLogicServicesTracksLogic

Remote deployment HelloTracksWorld application:<<Remotable>> QoS

ServerJVM 1

ClientJVM 2

TracksPresentation

TracksDataEvents

TracksDataServices

TracksData

Locale interfaces.

Locale interfaces.Remote interfaces.

<<Remotable>>

@ComponentServicespublic interface TracksLogicServices {

PSM@ComponentEventspublic interface TracksDataEvents {

+TracksDataEvents

<<ComponentEvents, >>

PIM+TracksLogicServices

<<ComponentServices, >>

Remote QoS components interface

@Remotable

@Remotable can be weaved to 1 RMI (default), 2 JGroups, … others : Web Services, socket, …

@Remotable

Remotable

Remotable QoS

Remotable

Remotable QoS

AGENDA

1. DCNS

4. Demonstration with Modelio : Remotable

5. UML tools REX

UML JACOMO component profile forArchitecture Description Language (ADL)

UML PIM JACOMO PSM

Analysis concepts:� <<ComponentType>> @ComponentType

� <<ComponentServices>> @ComponentServices

� <<ComponentEvents>> @ComponentEvents

� ...

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

� << Replicable >> @Replicable

� << Persistable >> @Persistable

� << Asynchronous >> @Asynchronous

� ...

Software Design Document : SDD

SDD generation from UML model� Data and DataId

- Class diagrams

� Components decomposition- Class diagrams

� Components interfaces- Class diagrams- Sequences diagram

� Components implementation- Class diagrams

Round trip from .docx

AGENDA

1. DCNS

5. UML tools REX

Objecteering andModelio UML tools

Model Driven Engineering need UML tool :

We use objecteering since 2000 for Model Driven Eng ineering.

100% of the code is inside the UML tool.

JACOMO profile, wizard since 2004.

THALES Airborne Systems 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

MDA: the lesson we learn“raise the level of abstraction of the UML model”

MDE: Raise the level of abstraction:� Put your processes, domain, frameworks, pattern, … i nside UML

tool.� Use UML for the analysis model, and keep the code c onform to the

model, conform to the architecture.� Don’t use UML tool only to input Java code (IDE too ls are better).

MDE + AOP = MDA: Productivity Advantages� The UML profile and wizard are simple to implement.� Use AOP to weave technical code outside the UML mod el.� Up to 70% of the technical code for the PSM is remo ved.

Agility� Functional change, simple architecture and code cha nge� Technology change, only AOP weaver change� Pair modeling, Tests first, …

AGENDA

1. DCNS

5. UML tool REX

Perspectives

Some DCNS metrics� More than 2500 JACOMO components ≠ projects

� More than 3MLoc

Modelio deployment� medium-scale team and model support (svn)

- Bagneux, Toulon

� DCNS Simulation and Formation (Ruelle)

� THALES Airborne Systems (Brest)

UML 2 and modelio 3 migration� Native <<component>> for PIM

� JACOMO UML2 profile and wizard

Questions & Answers

Solve essential complexitywithout introducing accidental complexity * :

“The best UML modelis the one you didn’t need to build **.”

Thank You

* Frederick Phillips 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-orient ed 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 complexitywithout 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 1Platform 1Platform 1Platform 1 PfPfPfPf 2222 Pf 3Pf 3Pf 3Pf 3 Pf 4Pf 4Pf 4Pf 4 Pf 5Pf 5Pf 5Pf 5

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

Rapid technological evolutionRapid technological evolutionRapid technological evolutionRapid technological evolution

NonNonNonNon----functional requirements evolutionfunctional requirements evolutionfunctional requirements evolutionfunctional requirements evolutionResponse time, security, fault tolerance, availability, transactions, persistence …Response time, security, fault tolerance, availability, transactions, persistence …Response time, security, fault tolerance, availability, transactions, persistence …Response time, security, fault tolerance, availability, transactions, persistence …

Non functionalNon functionalNon functionalNon functionalrequirements 1requirements 1requirements 1requirements 1

The Three Lifecycles to connect

Business Model 1Business Model 1Business Model 1Business Model 1 BM 2BM 2BM 2BM 2 BM 3BM 3BM 3BM 3

Functional requirements quasiFunctional requirements quasiFunctional requirements quasiFunctional requirements quasi----stabilitystabilitystabilitystabilityFunction coverage 1, Function coverage 2…Function coverage 1, Function coverage 2…Function coverage 1, Function coverage 2…Function coverage 1, Function coverage 2…

System lifetime10-30 years

Non functional lifetime10-20 years

Platform lifetime5-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 i n 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 d etail)

� 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, …

Modelstransformations

bind a domain modelto a technology

(Query / View / Transformation)

code generation

Runtime:binary

compilationexecution

Model Driven ArchitectureLarge project : we use elaborationist process

Large MDA project feedback:

UML Platform Independent Model (PIM)� 1200 domain classes (data tier)

Platform Definition Model = Corba Component ModelUML 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 transformat ion

and 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 DevelopmentAOSD involves three distinct development steps:

1. Aspectual de-compositionDecompose the requirements to identify different as pects.

3. Aspectual re-compositionThe re-composition process, also known as weaving.

2. Aspect implementationImplement each aspect separately

Bind the Domain Model to the Runtime Platform

Raise the level of abstraction: omitting detailMDA 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 som e”

Domain classes*

platform classes

aspectsweaving

AOP approach

Domain classes

platform classes

modelstransformation

MDA approach

Analysis:

Runtime:

*Plain Ordinary Java Object

AGENDA

1. DCNS

5. 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 toclass 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

Technicalsolutions

Software Architecture

Technical aspects

Functional Architecture

Logical Architecture

FunctionsEntities

Softwarecomponents

ArchitecturalPrinciples

Deployed Architecture

System ArchitectureSoftware

platform

Physicalplatform

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 AP I)

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 differentmiddleware 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 middlewareJava code + @nnotation + behavior

custom Javacode generator

AOPweaver

Platform Specific Model 2: with middleware JVM runtime: behavior + middleware aspects

@nnotation(point cut)

middleware(code advice)

code execution

Platform Definition Model:Java + middleware

@nnotations

1 / 12 LoC

1 / 4 LoC

4 / 4 LoC

<< stereotype >>

UML tool

AOP tool

Aspect-Oriented Model Driven Architecture (AO -MDA)and tools connection

code compilation

1 - Platform Independent Model:UML + Component profile

4 - Platform Specific Model 1: no middlewareJava code + @nnotation + behavior

3 - custom Javacode generator

5 - AOPweaver

6 - Platform Specific Model 2: with middleware JVM runtime: behavior + middleware aspects

@nnotation(point cut)

middleware(code advice)

code execution

2 - Platform Definition Model:Java + middleware

<< stereotype >>

@nnotations

Component-Based Software Engineeringwith component model profile

<<ComponentType>>

<<providedServices>>

<<producedEvents>>

<<consumedEvents>>

<<usedServices>>

<<providedParameters>>

<<usedParameters>>

JACOMOComponent

Multi-layered Event Driven Service Oriented Archite cture

AOP tool

UML tool

JAva COmponent MOdel :the 7 step process

<<ComponentImpl>>

CompAImpl

<<ComponentType>>

1: Platform Independent Model:Domain analysisDesign: QoS

2: Platform Specific Model 1:DesignImplementation (behavior)

7: runtime:JVM

6: code compilationand weaving

3: custom codegeneration

@ComponentImplpublic class CompAImpl { ... }

@ComponentTypepublic interface CompA { ... }

@ComponentImplpublic class CompAImpl {

4: add behavior with IDE

{ Remotable }

public void m() { ... }

UML component profile forArchitecture Description Language (ADL)

UML PIM JACOMO PSM

Analysis component concepts:� <<ComponentType>> @ComponentType

� <<ComponentServices>> @ComponentServices

� <<ComponentEvents>> @ComponentEvents

� ...

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

� << Persistable >> @Persistable

� << Asynchronous >> @Asynchronous

� ...PIM to PSM transformation is done by a custom Java code generation

JACOMO PSMraise 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 Architecture (CBA).

PIM UML <<stereotype>> and PSM JACOMO @nnotationsspecification 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 @nnotationsPSM design and implementation

UML Java<<ComponentImpl>> @ComponentImpl

<<ComponentItem>> @ComponentItem

<<UsedComponentEventsSubscribe>>@UsedComponentEventsSubscribe

<<UsedComponentEventsSubscribeDelegate>>@UsedComponentEventsSubscribeDelegate

<<UsedComponentContext>> @UsedComponentContext

<<Resource>> @Resource

UML <<stereotype>> and JACOMO @nnotations: QoSPIM design

UML Java<< Remotable >> @Remotable

<< Synchronous >> @Synchronous

<< Asynchronous >> @Asynchronous

<< Replicable >> @Replicable

<< NotReplicable >> @NotReplicable

<< Reconfigurable >> @Reconfigurable

UML << stereotype >> and JACOMO @nnotations : QoSPSM design and implementation

UML Java

<< SingleThreaded >> @SingleThreaded

<< MultiThreaded >> @MultiThreaded

<< SynchronizedRead >> @SynchronyzedRead

<< SynchronizedReadWrite >> @SynchronyzedReadWrite

<< Transactional >> @Transactional

Architecture to master the cost

To solve essential complexitywithout introducing accidental complexity .

Complexity

• To reduce accidental complexity =>• reduce cost

reduceaccidentalcomplexity

Metrics

masteressential

complexity

AGENDA

1. DCNS

6. Objecteering / modelio UML tool

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 plugi n, sonar)

UML tool: Objecteering / modelio� Model Driven Engineering: all is inside the UML too l

(specification, analysis, design, implementation co de, unit tests).

� Unique global id of the tool allows diff / merge be tween concurrent development.

More than 2500 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 (ec lipse).

� 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 a pproach� Remove up to 70% LoC for component state replicatio n QoS

Some JACOMO Metricswith UML tool

Model Driven Engineering + Aspect Oriented Programming ... · Model Driven Engineering + Aspect...

Documents