II. Etat de l'art
Dans cette partie, nous allons passer en revue tout ce qui va
nous permettre de développer un programme (ou un site web) sans
écrire une seule ligne de code. Comme expliquer dans la
problématique je distinguerai bien le logiciel, le site web et la base
de données.
1. Le logiciel
Le logiciel contrôle le monde, il est présent
absolument partout : processus métiers (administrative etc.),
gouvernement, l'industrie (Usines, chaines de fabrication), transports,
défense, finance, santé, édition, médias, nouvelles
technologies du web, commerce électronique, et bien plus encore.
Le logiciel a des enjeux aussi bien politiques
qu'économiques, d'autant plus que si un problème survient
à cause d'un logiciel les conséquences peuvent être
très lourdes :
· Therac 25, de 1985 à 1987 : 6 patients
irradiés, 2 morts
· Ariane 5 vol 88/501, en 1996 : le vol est
détruit au bout de 37 secondes et a coûté 850 millions de
dollars
· Mars Climate Orbiter & Mars Polar Lander sont
détruits en 1999
· Le projet d'informatisation de la bourse de Londres a
été abandonné au bout de 4 ans et a coûté 100
millions de livres
Figure 3 : Constat des projets en Génie
Logiciel
Figure 4 : Evolution de ces chiffres
The Standish Group montre qu'en 2009 seulement 32% des projets
en génie logiciel respectent toutes les spécifications
prévues au départ et que 24% ne voient pas la fin. Bien que le
taux de succès reste en constante hausse, le taux d'échec est
quant à lui aléatoire :
Aujourd'hui les logiciels sont de plus en plus complexes car
ils ont plusieurs préoccupations, points de vue et aspects. Ces points
de vues sont noyés dans le code, il est donc impossible de les isoler.
Les applications sont également de plus en plus larges et le nombre de
lignes de code ne cesse d'augmenter, selon Wikipédia et Source Line Of
Code (SLOC) Windows XP c'est 40 millions de lignes de codes, ceci complique
grandement la communication ente les différents intervenants.
Figure 5 : Evolution du nombre de lignes de
code
Le logiciel c'est également des besoins qui
évoluent en cours de route, on a donc des besoins de variabilité.
Pour répondre à ces problématiques et à
l'évolution permanente des technologies, il est apparu, entre autres,
l'ingénierie dirigée par les modèles.
A. Ingénierie
Dirigée par les Modèles (IDM ou MDE) MDE : Model-Driven
Engineering
L'Ingénierie Dirigée par les Modèles
(IDM) est une méthodologie/vision de développement de logiciels
qui met l'accent sur la création de modèles (ou l'abstraction)
plus proche du concept du domaine concerné plutôt
qu'orienté informatique ou algorithmique.
Un paradigme de modélisation pour IDM est
considéré comme efficace si ses modèles ont un sens par
rapport au point de vue de l'utilisateur et peut servir de base pour
l'implémentation de systèmes.
Les principes de l'IDM :
· P1 : «Models as first class entities»
· P2 : Montée en abstraction
· P3 : Séparation des préoccupations
· P4 : Modèles productifs (Vs.
Contemplatifs)
P1 : Les modèles comme des entités de
première classe
Avec l'IDM on veut passer du "tout objet" au "tout
modèle", c'est-à-dire modéliser au lieu de coder. Il y a
un changement d'état d'esprit : on était dans le "coder une fois,
lancer partout" désormais on veut "modéliser une fois,
générer partout".
Le modèle objet a atteint ses limites, les concepts
objets sont plus proches de l'implémentation que du domaine
métier (Gabriel, 2002) et (Nierstrasz, 2010).
Avec le concept de l'objet il est difficile de raisonner et de
communiquer (code) car les aspects qu'ils soient fonctionnels ou pas sont
noyés dans des lignes de codes. Le défi est donc de s'orienter
vers une expertise métier et avoir un bon langage de
modélisation.
La définition d'un modèle : "A Model
represents reality for the given purpose ; the model is an abstraction
of
reality in the sense that it cannot represent all aspects
of reality. This allows us to deal with the world in a simplified manner,
avoiding the complexity,danger and irreversibility of reality" (Rothenber,
1989)
Traduction : un modèle représente une
réalité pour un sujet donné. Le modèle est une
abstraction de la réalité dans le sens où il ne peut pas
représenter tous les aspects de la réalité. Cela nous
permet de traiter le problème de manière simplifiée en
évitant la complexité, les dangers et
l'irréversibilité de la réalité.
La définition de la modélisation : "in the
broadest sense, is the cost-effective use of something in place of something
else for some cognitive purpose. It allows us to use something that is simpler,
safer or cheaper than reality instead of reality for some purpose" -
(Rothenber, 1989)
Traduction : au sens large, c'est l'utilisation rentable de
quelque chose à la place d'une autre dans un but cognitif. Elle nous
permet d'utiliser quelque chose qui est plus simple, plus sûre ou moins
chère que de la réalité.
Il faut cependant faire attention au débat qui dit que
l'abstraction est la même chose que la simplification car ce n'est pas le
cas. En effet, la modélisation simplifie la compréhension et la
communication autour du problème mais elle ne simplifie pas le
problème lui-même.
Figure 6 : Un exemple de modèle, la pipe selon
Magritte
Pour être productifs, les modèles doivent
être utilisés par des machines, on a donc besoin d'un langage
précis pour les définir, on appelle ceci
Méta-Modèle.
D'après l'OMG (Object Management Group. : Association
de professionnels de l'informatique
orientée objet
ayant défini la norme
Corba, ainsi que l'
OMA 1(*)et les
ORB2(*)) a "metamodel is a model that defines the language
for expressing a model". Traduction : un Méta-Modèle est un
modèle qui définit un langage pour définir un
modèle.
Pour Seidewitz, a «metamodel makes statements about
what can be expressed in the valid models of a certain modeling
language». Traduction : un méta-modèle fait des
déclarations sur ce qui peut être exprimé en modèles
valides de certains langages de modélisation.
La relation entre un modèle et son
méta-modèle est une relation "conforme à". Un
modèle est conforme à son méta-modèle si les
éléments et les relations entre ces éléments sont
définis dans le méta modèle
Conforme à
Représente
Méta-modèle
Modèle
Système
Figure 7 : Un exemple de
méta-modèle
Les langages utilisés pour exprimer les
méta-modèles ont eux-mêmes un modèle qu'on appelle
méta-méta-modèle et qui se trouve être
traditionnellement auto-descriptif. C'est en particulier le cas pour MDA (voir
plus loin). Un méta-modèle réflexif est exprimé
dans le même langage de modélisation qu'il décrit. Les
principaux langages de méta-modélisation existants sont MOF (pour
Meta-Objet Facilities), EMOF (pour Essential MOF), CMOF (pour Complete MOF) et
ECore défini par IBM et utilisé dans le framework de
modélisation d'Eclipse EMF (Eclipse Modeling Framework).
La spécification de MOF adopte une architecture de
méta-modélisations à quatre couches :
M0 : Ce niveau représente le
système réel à modéliser.
Exemple : Jeu d'échecs dans la figure ci
après.
M1 : Ce niveau est composé du
modèle représentant le système réel à
modéliser.
Exemple : modèle de jeu d'échecs via un DSL
(Domain Specific Langage)
M2 : Dans ce niveau on trouve le
méta-modèle décrivant le langage de
modélisation.
Exemple : méta-modèle du DSL de jeu
d'échecs.
M3 : Un niveau qui comporte le
méta-méta-modèle décrivant le langage de
méta-modélisation.
Exemple : Ecore, MOF.
Figure 8 : Une architecture à 4
niveaux
On retrouve ces couches dans la figure 9, qui illustre un
système de jeu d'échec. L'échiquier est situé au
niveau M0, chaque élément de ce système est
modélisé au niveau M1. Dans ce niveau on retrouve le
modèle qui représente l'échiquier, les pièces sont
modélisées par une classe nommée pièce et qui a
certains attributs décrivant la pièce, même chose pour le
plateau et les cases. Ensuite on retrouve le méta-modèle au
niveau M2, ce dernier représente le langage de modélisation et il
est conforme à un méta-méta-modèle. Ce
méta-méta-modèle est situé dans le niveau M3, il
est conforme à lui-même et représente le langage de
méta-modélisation.
Figure 9 : Niveaux de modélisation, exemple du
jeu d'échec
P2 : Abstraction
L'abstraction c'est ignorer les détails insignifiants
et ressortir des détails les plus importants. Pour rappel l'importance
c'est décider de ce qui est signifiant et de ce qui ne l'est pas, cela
dépend directement de l'utilisation visée du modèle. Pour
le Larousse l'abstraction c'est l' "Opération intellectuelle qui
consiste à isoler par la pensée l'un des caractères de
quelque chose et à le considérer indépendamment des autres
caractères de l'objet."
Les modèles permettent de s'abstraire de certains
détails qui ne sont pas indispensables pour comprendre le système
selon un point de vue donné. Pour rappel le but du génie logiciel
c'est l'amélioration de la productivité via l'augmentation du
niveau d'abstraction.
Les langages de 3ème génération (
Fortran,
COBOL,
Simula,
APL, etc.) ont
amélioré la productivité du développeur par 450%
(Jones, 2006), alors que l'introduction des langages orientés objets
n'ont pas fait autant. Par exemple Java est 20% plus productif que le BASIC.
Les langages de programmation arrivent aujourd'hui à leur limite en
terme d'abstraction. Ainsi le défi c'est d'assurer la
transformation/transition vers le niveau le plus bas et de choisir le bon
niveau d'abstraction.
P3 : Séparation des
préoccupations
La séparation des préoccupations est
indispensable dans le cas d'applications complexes. Plusieurs aspects et/ou
points de vue signifient que nous avons plusieurs métiers
(sécurité, communication, GUI, QoS,..), mais un point de vue
concerne un modèle.
Figure 10 : Plusieurs vues sur un même
modèle
Chaque vue peut être exprimée en utilisant un
langage de modélisation différent. Il y a du coup plusieurs
intervenants dans la boucle. Le défis de l'IDM est d'intégrer des
vues et d'assurer une cohérence entre ces vues.
Vue plan
Vue satellite
Vue trafic
Un autre niveau d'abstraction
Street view
Figure 11 : Abstraction et séparation des
préoccupations, l'exemple de Google Maps
· P4 : Modèle productifs
La modélisation reste un investissement qu'il faudra
rentabiliser. On se dirige vers de plus en plus de code
généré automatiquement à partir des modèles.
Les défis des modèles productifs consistent en
des langages de modélisation proche du métier et précis,
des générateurs de code fiable, intégration du code
généré à partir de plusieurs vues vers un seul
système, génération du comportement, définition de
la chaine de transformation (raffinement) modèle vers code.
Les promesses de l'IDM sont donc :
· Gérer la complexité : les applications
sont de plus en plus énormes (Windows 2000 c'est 40 millions de lignes
de code) et ne peuvent pas être gérées par un seul
développeur.
· Meilleure communication : le code n'est pas toujours
compréhensible pour les développeurs qui ne l'ont pas produits,
on peut difficilement communiquer avec du code. Comme il y a souvent plusieurs
dizaines de personnes sur un projet cela permet d'avoir un langage commun et
universel (monde). Avec l'apparition de nouvelles façons de travailler
(outsourcing, sous-traitance,...) la communication y apparait comme
très importante.
· Pérenniser un savoir-faire : de part la
durée de certains projets. Les projets peuvent durer plusieurs
années donc ce ne sont pas toujours les mêmes personnes qui
travaillent dessus. Du coup il y a un besoin de capitaliser un savoir-faire
indépendant du code et des technologies. On veut capturer le
métier sans se soucier des détails techniques.
· Augmenter la productivité : On
génère du code à partir de modèles et on
maîtrise la variabilité c'est-à-dire que nous avons une
vision ligne de produits où l'on veut un modèle
générique pour un produit avec plusieurs variantes.
Exemple de NOKIA qui a vendu 1,1 milliard de
téléphones portables avec des milliers de versions logiciels
alors que le délai de mise sur le marché n'est que de 3 mois.
Ainsi se pose la question suivante : Quel langage utiliser
pour modéliser, méta modéliser (créer de nouveaux
langages) ? Pour cela nous allons voir deux approches :
· L'approche MDA : utilisation d'un ensemble de standards
fournis par l'OMG3(*) i.e.
MOF4(*), UML.
· L'approche DSML (Domain-Specific Modeling Languages)
* 1 Object Management
Architecture: désigne une structure de management d'objets
* 2 Object Request
Broke: s'apparente à une tuyauterie permettant les échanges
de messages entre objet
* 3 Object Management Group :
est une association
américaine
à but non lucratif créée en
1989 dont
l'objectif est de standardiser et promouvoir le
modèle
objet sous toutes ses formes.
* 4 Meta-Object Facility :
est un standard de l'
Object
Management Group s'intéressant à la représentation des
méta
modèles et leur manipulation. Le langage MOF
s'auto-définit.
| 
