Dcns mdday2010

DCNS2007-allrightsreserved/tousdroitsréservés
Emmanuel GRIVOT
Architecte 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 in
Combat 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
FREMM
BPC
BARRACUDA
PA CDG

Frigate
Communication
Combat Management
System
Optronic
sonar
Electronic Warfare
Surveillance radar
IR
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 IR
Electronic
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
*
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
TracksPresentation
TracksLogicServices
<<UsedComponentServices>>
0..1
<<ConsumedComponentEvents>>
TracksEvents
*

:TracksPresentation
Tracks components sequence diagram
:User :TracksData:TracksLogic
createTrack( )
createTrack( )
createTrack( )
notifyCreatedTrack( )

Tracks component:
MDE, CBSE, ED - SOA
TracksEventsTracksServices
Tracks
*
<<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 TracksEvents
Tracks
1 1
1
*

Presentation, Logic and Data layers
TracksDataEvents
TrackId
Track
TracksData
*
theTracks
*
trackId
TracksLogic
TracksDataServices
<<UsedComponentServices>> 1
TracksServices
TracksPresentation
TracksLogicServices
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
<<UsedComponentServices>>1
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
TracksDataImpl
TracksDataServicesImplTest
setup()
White Box Unit Test
description
Annotations
@Before

Local deployment HelloTracksWorld application
TracksPresentation
0..1
TracksDataEvents
TracksDataServices
TracksData
*
TracksLogicServices
TracksLogic
1
JVM
Locale interfaces.Locale interfaces.
Locale
interfaces.

TracksLogicServices
TracksLogic
1
Remote deployment HelloTracksWorld application:
<<Remotable>> QoS
Server
JVM 1
Client
JVM 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
Programming
http://www.devx.com/enterprise/Article/27703/1954?pf=true
The Role of Aspect-Oriented Programming
in OMG’s Model-Driven Architecture
http://www.aspectprogramming.com/papers/AOP and MDA.pdf
Le point sur la programmation par aspects
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 are
in 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 complexity
is caused by the problem to be solved.
Essential complexity must be mastered.
To solve essential complexity
without introducing accidental complexity.
Accidental complexity
is 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 approach
base on the Model Driven Engineering.
It was launched by the Object Management Group (OMG)
in 2001.
MDA provide an approach to the challenge
of business and technology change.
MDA separates application logic from
underlying 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 transformation
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 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
AOP
Aspect
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 Platform
dependency

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 model
is 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:
JVM
6: 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 cost
reduce
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

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Dcns mdday2010

Semelhante a Dcns mdday2010 (20)

Mais de MD DAY

Mais de MD DAY (18)

Último

Último (20)

Dcns mdday2010