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

DC

NS

201

3 -

all r

ight

s re

serv

ed /

tous

dro

its r

éser

vés

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 .

[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

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

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

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

data


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

CBA

ComponentBasedArchitecture

SoCSeparation ofConcerns

AspectOrientedProgramming

ED - SOA

Event Driven -Service

OrientedArchitecture

multi-layersarchitecture

MDA

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

*

0..1

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

Track

1

+identification

1

+kinematics

Identification

<<Data>>

Kinematics

<<Data>>

Track

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

Track

TracksPresentation TracksLogic

TracksData

trackId

*

theTracks

TracksServices TracksEventsTracks

1 1

1

*


Tracks component decomposition:Presentation, Logic and Data layers

TracksDataEvents

TrackId

Track

TracksData

<<ProducedEvents>>

*


theTracks

*

trackId

TracksLogic

TracksDataServices

<<UsedServices>> 1


TracksServices

TracksPresentationTracksLogicServices

<<UsedServices>>

0..1


TracksEvents

<<ProducedEvents>>

*

<<ConsumedEvents>>


:TracksPresentation

Tracks components sequence diagram

:User :TracksData:TracksLogic

createTrack( )

createTrack( )

createTrack( )

onCreatedTrack( )

onCreatedTrack( )


TracksData component Overview:<<Data layer>>

TracksDataEvents

TracksDataServices

TracksData


<<ProducedEvents>>

* Track

theTracks

*trackId


TracksData component Detailed

TracksData


*

<<ProducedEvents>>

theTracks

*

trackId

Track

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

1


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

0..1

TracksDataEvents

<<ConsumedEvents>>


TracksView component Detailed

Tracks Interface

TracksPresentation

<<ConsumedEvents>>

0..1

<<UsedServices>>

TracksLogicServices


TracksDataEvents

<<ComponentEvents>>

TracksEventsTracksServices



createTrack(in aTrack : Track):TrackId





*

<<ProducedEvents>>


TracksDataServices

TracksData

0..1

tracksDataServices

0..1

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

0..1

TracksDataEvents

TracksDataServices

TracksData

*

TracksLogicServicesTracksLogic

1

JVM

Locale interfaces.Locale interfaces.

Locale interfaces.


AGENDA

1. DCNS



4. Demonstration with Modelio : Hello Tracks World

5. UML tools REX



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

<<Remotable>>


@ComponentServicespublic interface TracksLogicServices {

...}

PSM@ComponentEventspublic interface TracksDataEvents {

...}

PSM

+TracksDataEvents

<<ComponentEvents, >>

PIM+TracksLogicServices

<<ComponentServices, >>

PIM

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

SLoC

e1,5


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”

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

CompA

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

5:


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

Date post:	20-May-2020
Category:	Documents
Upload:	others
View:	14 times
Download:	0 times

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

Documents