Mdaaa

Introduction au génie logiciel
Interv. SERNANE SOUFIANE

PLAN :
 Génie logiciel
 Logiciel
 Qualité du logiciel
 Processus de développement logiciel
 Activités du développement logiciel
 Processus
 Développement
 Méthodes
 Documentation
 Modélisation
Génie logiciel :
Ensemble des méthodes, des

techniques et des outils dédiés à la
conception, au développement et à
la maintenance des systèmes
informatiques.
Génie logiciel :
Objectif :
Avoir des procédures systématiques
pour des logiciels de grande taille afin
que :
- la spécification corresponde aux besoins
réels du client
- le logiciel respecte sa spécification
- les délais et les coûts alloués à la réalisation
soient respectés
Un logiciel :
Ensemble d'entités nécessaires au

fonctionnement d'un processus de
traitement automatique de l'information
- Programmes, données, documentation...
Un logiciel :
Ensemble de programmes qui permet à

un système informatique d’assurer une
tâche ou une fonction en particulier
Logiciel = programme + utilisation
Un logiciel : Les caractéristiques
Environnement:
- utilisateurs :
 Grand public (traitement de texte),
 Spécialistes (calcul météorologique),
 Développeurs (compilateur)
Un logiciel : Les caractéristiques
Spécification:
ce que doit faire le logiciel, ensemble de

critères que doivent satisfaire son
fonctionnement interne et ses
interactions avec son environnement
Crise du logiciel :
Constat du développement logiciel:
 Délais de livraison non respectés.
 Budgets non respectés.
 Ne répond pas aux besoins de l'utilisateur

ou du client.
 Difficile à utiliser, maintenir, et faire évoluer

Étude du DoD :
Étude du Standish group
Enquête sur des milliers de projets, de toutes

tailles et de tous secteurs
Petits vs grands projets
Utilisation des fonctionnalités implantées
Raisons de la faible qualité des logiciels
Tâche complexe :
- Taille et complexité des logiciels
- Taille des équipes de conception/développement
Manque de méthodes et de rigueur :

- Manque de méthodes de conception
- Négligence et manque de méthodes et d'outils des

phases de validation/vérification
Mauvaise compréhension des besoins :

- Négligence de la phase d'analyse des besoins du
client
- Manque d'implication du client dans le processus

Importance de la qualité des logiciels
Fiabilité, sûreté et sécurité des logiciels:

- Transports automobile, ferroviaire, aéronautique
- Contrôle de processus industriels, nucléaire,

armement
- Médical : imagerie, appareillage, télé-surveillance
- e-commerce, carte bancaire sans contact,

passeport électronique
Importance de la qualité des logiciels
Raisons économiques : coût d'un bug

- Coût de la correction, du rappel des appareils
défectueux
- Coût de l'impact sur l'image, de l'arrivée tardive sur

le marché
- Coût en vies, coût de l'impact écologique

Solution : Génie logiciel
Idée : appliquer les méthodes classiques

d'ingénierie au domaine du logiciel
Ingénierie (ou génie) : Ensemble des fonctions

allant de la conception et des études à la
responsabilité de la construction et au contrôle des
équipements d'une installation technique ou
industrielle
Qualité du logiciel
Critères de qualité
 Validité : réponse aux besoins des utilisateurs
 Facilité d'utilisation : prise en main et robustesse
 Performance : temps de réponse, débit, fluidité...
 Fiabilité : tolérance aux pannes

Qualité du logiciel
Critères de qualité
 Sécurité : intégrité des données et protection des
accès
 Maintenabilité : facilité à corriger ou transformer le

logiciel
 Portabilité : changement d'environnement matériel

ou logiciel
Contrôleur de télécommande
Aire caractéristique de
qualité logiciel
(représentative du coût)
Jeu vidéo
Client mail
Simulateur pour Météo
Processus de développement logiciel
Ensemble d'activités successives, organisées

en vue de la production d'un logiciel
En pratique :
 Pas de processus idéal
 Choix du processus en fonction des contraintes
 Adaptation de « processus types » aux besoins réels

Processus de développement logiciel
Activités du développement logiciel:

 Analyse des besoins
 Spécification
 Conception
 Programmation
 Validation et vérification
 Livraison
 Maintenance
Activités du développement logiciel
Analyse des besoins : Comprendre les besoins

du client
 Objectifs généraux, environnement du futur système,
ressources disponibles, contraintes de performance…
 Fournie par le client

Spécification :
 Établir une description claire de ce que doit faire le logiciel
 Clarifier le cahier des charges en listant les exigences

fonctionnelles et non fonctionnelles
Conception : Élaborer une solution concrète

réalisant la spécification
 Description architecturale en composants (avec interface et
fonctionnalités)
 Réalisation des fonctionnalités par les composants

(algorithmes, organisation des données)
 Réalisation des exigences non fonctionnelles (performance,

sécurité…)
Programmation : Implantation de la solution

conçue
 Choix de l'environnement de développement, du/des
langage(s) de programmation, de normes de
développement...
Validation et vérification
Objectifs :
 Validation : assurer que les besoins du client sont satisfaits
(au niveau de la spécification, du produit fini...)
 Vérification : assurer que le logiciel satisfait sa spécification

Maintenance
Types de maintenance :
 Correction : identifier et corriger des erreurs trouvées après
la livraison
 Adaptation : adapter le logiciel aux changements dans

l'environnement (format des données, environnement
d'exécution...)
 Perfection : améliorer la performance, ajouter des

fonctionnalités, améliorer la maintenabilité du logiciel
Répartition de l'effort
Processus en cascade
Processus en V
Caractéristiques :
 Variante du modèle en cascade
 Mise en évidence de la complémentarité des phases

menant à la réalisation et des phases de test
permettant de les valider
Processus en V
Développement par prototypage
Principe :
 Développement rapide d'un prototype avec le client pour
valider ses besoins
 Écriture de la spécification à partir du prototype, puis

processus de développement linéaire
Développement incrémental
Principe :
 Hiérarchiser les besoins du client
 Concevoir et livrer au client un produit implantant un sous-

ensemble de fonctionnalités par ordre de priorité
Méthodes agiles et extreme programming
Principe :
 Implication constante du client
 Programmation en binôme
 Développement dirigé par les tests
 Cycles de développement rapides pour réagir aux

changements
Documentation
Objectif : Traçabilité du projet

Pour l'équipe :
 Regrouper et structurer les décisions prises
 Faire référence pour les décisions futures
 Garantir la cohérence entre les modèles et le produit
Pour le client :
 Donner une vision claire de l'état d'avancement du projet

Documents de spécification et conception
Rédaction : le plus souvent en langage naturel (français)
Problèmes :
 Ambiguïtés : plusieurs sens d'un même mot selon les

personnes ou les contextes
 Contradictions, oublis, redondances difficiles à détecter
 Difficultés à trouver une information
 Mélange entre les niveaux d'abstraction

Alternatives au langage naturel :

Langages informels :
 Langage naturel structuré : modèles de document et règles

de rédaction précis et documentés
 Pseudo-code : description algorithmique de l'exécution d'une

tâche, donnant une vision opérationnelle du système
Langages semi-formels :
 Notation graphique : diagrammes accompagnés de texte

structuré, donnant une vue statique ou dynamique du
système
Langages formels :
 Formalisme mathématique : propriétés logiques ou modèle

du comportement du système dans un langage
mathématique
Modélisation
Modèle : Simplification de la réalité, abstraction, vue subjective
 modèle météorologique, économique, démographique...
Modéliser un concept ou un objet pour :
 Mieux le comprendre
 Mieux le construire
En génie logiciel :
 Modélisation = spécification + conception
 Aider la réalisation d'un logiciel à partir des besoins du client

Modélisation graphique
Pourquoi UML ?
Langage :
 Syntaxe et règles d'écriture
 Notations graphiques normalisées
… de modélisation :
 Abstraction du fonctionnement et de la structure du système
 Spécification et conception
… unifié :
 Fusion de plusieurs notations antérieures : Booch, OMT,
OOSE
 Standard défini par l'OMG (Object Management Group)
 Dernière version : UML 2.5.1 (Décembre 2017)
UML : Unified Modeling Language
Besoin de modéliser pour construire un logiciel

 Modélisation des aspects statiques et dynamiques
 Modélisation à différents niveaux d'abstraction et selon
plusieurs vues
 Indépendant du processus de développement
Besoin de langages normalisés pour la modélisation
 Langage semi-formel
 Standard très utilisé
Conception orientée objet
 Façon efficace de penser le logiciel
 Façon efficace de penser le logiciel
 Indépendance du langage de programmation
Méthodes de conception
Conception fonctionnelle
 Système = ensemble de fonctions
 État du système (données) centralisé et partagé par les
fonctions
Conception guidée par les données
 Système = base de données
 Fonctions communes à toutes les données
 Adaptée à l’élaboration de grandes bases de données
 Système = ensemble d’objets
 Objet = données + fonctions
 État du système distribué entre tous les objets
Principes
 Concept du domaine d'application = objet
 Décrit par état (attributs) + comportement (opérations)
 Liens entre concepts : héritage, agrégation, composition...
Caractéristiques des objets
 Identité : objet = entité unique (mêmes attributs ⇏ même
objet)
 Classification : regroupement des objets de même nature
(attributs + opérations)
 Polymorphisme : comportement différent d'une même
opération dans différentes classes
 Héritage : partage hiérarchique des attributs et opérations
Conception orientée objet avec UML
UML
 Langage graphique : Ensemble de diagrammes permettant
de modéliser le logiciel à selon différentes vues et à
différents niveaux d'abstraction
 Modélisation orientée objet : modélisation du système

comme un ensemble d'objets interagissant
Diagrammes UML
Représentation du logiciel à différents points de vue :

 Vue des cas d'utilisation : vue des acteurs
 Vue logique : vue de l’intérieur
 Vue d'implantation : dépendances entre les modules
 Vue des processus : dynamique du système
 Vue de déploiement : organisation environnementale du

logiciel
Diagrammes UML
Diagrammes UML
14 diagrammes.
Diagrammes structurels :
 Diagramme de classes
 Diagramme d'objets
 Diagramme de composants
 Diagramme de déploiement
 Diagramme de paquetages
 Diagramme de structure composite
 Diagramme de profils
Diagrammes UML
14 diagrammes.
Diagrammes comportementaux :
 Diagramme de cas d'utilisation
 Diagramme états-transitions
 Diagramme d'activité
Diagrammes UML
14 diagrammes.
Diagrammes d'interaction :
 Diagramme de séquence
 Diagramme de communication
 Diagramme global d'interaction
 Diagramme de temps
Exemple d'utilisation des diagrammes
Spécification :
 Diagrammes de cas d'utilisation : besoins des utilisateurs
 Diagrammes de séquence : scénarios d'interactions entre

les utilisateurs et le logiciel, vu de l'extérieur
 Diagrammes d'activité : enchaînement d'actions

représentant un comportement du logiciel
Exemple d'utilisation des diagrammes
Conception :
 Diagrammes de classes : structure interne du logiciel
 Diagrammes d'objet : état interne du logiciel à un instant donné
 Diagrammes états-transitions : évolution de l'état d'un objet
 Diagrammes de séquence : scénarios d'interactions avec les

utilisateurs ou au sein du logiciel
 Diagrammes de composants : composants physiques du logiciel
 Diagrammes de déploiement : organisation matérielle du logiciel

- Séance 2 -

PLAN :
 Rappel
 AGL
 Objectif
 Les Types d’AGL
 CASE TOOLS
 UML
 Diagramme de cas d’utilisation
 TP1
 Diagramme de classe
 TP2
Rappel :
 Le génie logiciel
 « Le génie logiciel est l'ensemble des
activités de conception et de mise en
œuvre des produits et des procédures
tendant à rationaliser la production du
logiciel et son suivi »
 Autrement dit,
 le génie logiciel est « l'art » de produire
de bons logiciels, au meilleur rapport
qualité/prix.
AGL ?
 Logiciel aidant à la réalisation de
logiciels.
 Ensemble d’outils permettant de couvrir

le cycle de vie du logiciel
 Analyse
 Conception
 Réalisation
 Maintenance, …
Objectif des AGL ?
 Améliorer la productivité,
 Améliorer le suivi,
 Améliorer la qualité
 fiabilité,
 maintenance,
 évolutivité.
Comment ?
 En faisant le suivi des différentes

phases du processus logiciel
 En offrant un cadre cohérent et
uniforme de production.
Un AGL intègre des outils
 « Case tools »
 Adaptés aux différentes phases de la production d'un logiciel
 Facilite la communication et la coordination entre ces
différentes phases.
Un AGL est basé sur des méthodologies pour
formaliser
 Le processus logiciel
 Chacune des phases qui le composent.
Vous connaissez quels AGL ?
 PowerDesigner et PowerAMC
 Objecteering
 Rational Rose
 Visual Studio .Net
 Windev
 On distingue essentiellement deux types
d'AGL selon la nature des outils intégrés:
Les environnements de conception Les environnements de développement
(upper-case) (lower-case)
Les upper-case
 Supportent les phases d'analyse et de
conception du processus logiciel.
 Ils intègrent généralement :
 des outils pour l'édition de diagrammes (avec
vérification syntaxique),
 des dictionnaires de données,
 des outils pour l'édition de rapports,
 des générateurs de (squelettes de) code,
 des outils pour le prototypage,
 ...
 Ils sont généralement basés sur une méthode
d'analyse et de conception (UML, Merise, ...)
 Ex:
 Objecteering
Les Lower-Case
 Supportent les phases

d'implémentation et de test du
processus logiciel.
 Ils intègrent généralement
 des éditeurs (éventuellement dirigés par la
syntaxe),
 des générateurs d'interfaces homme/machine,
 des SGBD,
 des compilateurs,
 optimiseurs,
 debugger,
 ...
Exemple :
 Unix/Linux
 Il intègre différents outils pour la programmation et
le test.
 L'intégration des données est faite par
l'intermédiaire des fichiers Unix
 La gestion (limitée) de configurations est faite par
make.
Les environnements dédiés:
 Certains environnement, plus évolués,
sont dédiés à un langage particulier.
 Exemples:
 Eclipse,
 Smalltalk, …
 Ces différents environnements proposent:

 des bibliothèques de composants,
 une interface graphique,
 des éditeurs dédiés au langage,
 des interprètes,
 debuggers,
Les outils « CASE »
Les AGL intègrent différents outils d'aide au

développement de logiciels
 Les « outils CASE »
Certains outils interviennent durant la totalité du
processus logiciel
 Outils horizontaux
Ces différents outils interviennent lors d'une ou
plusieurs phases du cycle de vie du logiciel
 Outils verticaux
Exemples d’outils CASE
Outils horizontaux : Service pour l’ensemble du cycle

de vie
 Éditeurs de texte
 Gestion de projet
 Gestion du dictionnaire de données
 Administration et droits d’accès
 Gestion des configurations
 Documentation
 Service de communication
Outils verticaux: fonctions propres à chaque étapes du

cycle de vie
 Spécification
 Conception
 Génération de code
 IDE
 Compilateurs
 Génération d'interfaces homme-machine
 Génération de tests
 Validation
 Prototypage
 Maintenance
Enfin, il existe des générateurs d'environnements de

programmation:
 À partir de la description formelle d'un
langage, ils génèrent un environnement de
programmation dédié au langage
 Contenant:
 un éditeur dédié au langage,
 un pretty-printer,
 un debugger,
 un interpréteur, ...
 Exemple:
 Centaur
 SmartTools
Modélisation UML
Les diagrammes UML
• Vues statiques
– Les diagrammes de classes
– Les diagrammes d’objets
– Les diagrammes de cas d’utilisation
– Les diagrammes de composants
– Les diagrammes de déploiement
• Vues dynamiques
– Les diagrammes de séquence
– Les diagrammes de collaboration
– Les diagrammes d’états-transition
– Les diagrammes d’activités
Cas d’utilisation
•structurer les besoins des utilisateurs et les objectifs correspondants du système.
•Préoccuper des cas "réels" des utilisateurs ; ils ne présentent pas de solutions
d'implémentation et ne forment pas un inventaire fonctionnel du système.
Notation
Objectif du système, motivé par un besoin

d'un (ou plusieurs) acteur(s)
Cas d’utilisation
Personne ou composant d’origine d’une

Acteur interaction avec le système
Documente un élément du modèle
Note
Le cas source contient aussi le comportement

Relation d’utilisation décrit dans la cas destination
Use cases: concepts
• Acteur : entités externes au système qui
dialoguent avec lui
• Use case : description de la fonctionnalité
du système du point de vue d’utilisateur
• Diagramme de cas d’utilisation : illustre les
liens entre les acteurs et les différents cas
d’utilisation.
Cas d’utilisation
Exercice : Le cas MonAuto
MonAuto est une entreprise qui fait le commerce,
l'entretien et les réparations de voitures.
MonAuto désire exploiter un logiciel de gestion des
réparations; elle dispose déjà d'un logiciel
comptable. Les factures de réparations seront
imprimées et gérées par le logiciel comptable.
Le logiciel de gestion des réparations devra
communiquer avec le logiciel comptable pour lui
transmettre les réparations à facturer.
Exercice 1 : Le cas MonAuto (suite)
Le logiciel de gestion des réparations est destiné en priorité au
chef d'atelier, il devra lui permettre de saisir les fiches de
réparations et le travail effectué par les divers employés de
l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés
de l'atelier vont chercher des pièces de rechange au magasin.
Lorsque le logiciel sera installé, les magasiniers ne fourniront
des pièces que pour les véhicules pour lesquels une fiche de
réparation est ouverte; ils saisiront directement les pièces
fournies depuis un terminal installé au magasin.
Lorsqu'une réparation est terminée, le chef d'atelier va essayer
la voiture. Si tout est en ordre, il met la voiture sur le parc
clientèle et bouclera la fiche de réparation informatisée. Les
fiches de réparations bouclées par le chef d'atelier devront
pouvoir être importées par le comptable dans le logiciel
comptable.
Exercice 1 : Le cas MonAuto (suite)
MonAuto est une entreprise qui fait le commerce, l'entretien et
les réparations de voitures.
MonAuto désire exploiter un logiciel de gestion des
réparations; elle dispose déjà d'un logiciel comptable. Les
factures de réparations seront imprimées et gérées par le
logiciel comptable.
Le logiciel de gestion des réparations devra communiquer
avec le logiciel comptable pour lui transmettre les réparations à
facturer.
Le logiciel de gestion des réparations est destiné en priorité au

chef d'atelier, il devra lui permettre de saisir les fiches de
réparations et le travail effectué par les divers employés de
l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés
Solution possible
Structurer les use cases
• Les relations “extend” et
“include” Enregistrer la commande
– “Extend” : un cas
d’utilisation X étend un cas <<extend>>
d’utilisation Y lorsque le Responsable

cas d’utilisation X peut être Clientèle
appelé au cours de Enregistrer client
l’exécution du cas
d’utilisation Y
– “Include” : un use case est
constitué de “sous” use <<include>>
cases. Retirer argent
<<include>>
• La généralisation
Authentifier client
Client
– Crée une hiérarchie entre Consulter solde

acteurs ou use cases
Modélisation objet
Notion d’Objet
Une abstraction du monde réel c.-à-d. des données informatiques
regroupant des caractéristiques du monde réel
Exemple
une personne, une voiture, une maison, ...
Caractérisation d’un objet

Identité FIAT-UNO-17 : Voiture
permet de le distinguer des autres objets 233434 : Numéro de série
1500 kg : Poids
Attributs 8864 YF 17 : Immatriculation
données caractérisant l'objet 133 000 : kilométrage
Méthodes Démarrer ()
Arrêter()
actions que l'objet est à même de réaliser Rouler()
Modélisation objet
Notion de Classe
• Structure d'un objet, c.-à-d. une déclaration de l'ensemble des entités
qui composeront l’objet
• Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un
moule
Notation
un objet est une instanciation (occurrence) d'une classe
Une classe est composée: Nom_de_la_classe

 attributs attribut1 : Type
données dont les valeurs représentent attribut2 : Type
…
l'état de l'objet
méthode1 ()
 méthodes méthode2 ()
opérations applicables aux objets …
Modélisation objet
Voiture FIAT-UNO-17
Numéro de série : Int 233434 : Numéro de série
Poids : double 1500 kg : Poids
Immatriculation : String 8864 YF 17 : Immatriculation
Kilométrage : double 33 000 : kilométrage
Démarrer ()
Arrêter()
Rouler()
Renault-Clio-17 Peugeot-206-75
5323454 : Numéro de série 3434 : Numéro de série
1500 kg : Poids 1700 kg : Poids
64 YFT 17 : Immatriculation 8634 YGG 75 : Immatriculation
23 000 : kilométrage 15 000 : kilométrage
Types de relation entre classes
Héritage
Association
Contenance
Types de relation : Héritage
permet de créer une nouvelle classe à partir d'une classe existante
Principe
classe dérivée contient les attributs et les méthodes de sa superclasse
Spécialisation Généralisation
étendre les propriétés factoriser les propriétés
d'une classe, sous groupe de classes sous
forme de sous-classes forme de super-classe
Chaque personne de l’université est identifiée par son nom, prénom

Les étudiants ont plus un noEtudiant
Les enseignants ont un numéro de téléphone interne
Types de relation : Association
Connexion sémantique entre deux classes

Navigabilité
 Par défaut une association est navigable dans les deux sens
• Chaque instance de voiture a un lien vers le propriétaire

• Chaque instance de Personne a un ensemble de lien vers les voitures
 Restriction de la navigabilité
• Le service de contravention Navigable
est associé à une ou plusieurs
voiture(s)
• La voiture ne connaît pas service
de contravention
Documentation d’une association
 Nom de l’association
lien sémantique entre les classes
La personne achète la voiture
La voiture est achetée
 Rôle d’une association

Spécification du rôle de la classe
La personne joue le rôle de

propriétaire de la voiture
Relation n-aire
Type particulier d’association qui relie plus de deux classes
Professeur
Symbole d’association
Salle Etudiant
Multiplicités
1 : la classe est en relation avec un et un seul objet de l’autre classe

1..* : la classe est en relation avec au moins un objet de l’autre classe
0..* : la classe est en relation avec 0 ou n objets de l’autre classe
0..1 : la classe est en relation avec au plus un objet de l’autre classe
Une voiture est achetée par une

Une personne peut acheter
et une seule personne
0 ou n voitures
Types de relation : Contenance
Cas particulier d’association exprimant une relation de contenance
Exemples:
• Une voiture a 4 roues
• Un dessin contient un ensemble de figures géométriques
• Une présentation PowerPoint est composé de transparents
• Une équipe de recherche est composée d’un ensemble de personnes
Deux types de relations de contenance en UML

• Agrégation
• Composition (Agrégation forte)
Types de relation : Agrégation
A B
Type de relations
– A « contient » des instances de B,
Agrégat
Propriétés de l’agrégation
• La suppression de A n’implique pas la suppression de B
• L'élément agrégé peut être partagé
Exemples :
• L’enseignant est un composant
d’une (ou plusieurs) équipe de
recherche d’un seul département
• La disparition d’une équipe de

recherche n’entraine pas la
disparition d’un enseignant
Types de relation : Composition
 La suppression de A entraine la suppression de B
Exemple:
« Une présentation PowerPoint est composé de transparents »
La suppression de la présentation entraine la disparition des transparents

qui la compose
Diagramme de classes
Exercice 1 :
Pour chaque exemple ci-dessous, indiquez si la relation
présentée est une généralisation, une agrégation ou une
association :
• Un pays a une capitale
• Une transaction boursière est un achat ou une vente
• Les fichiers contiennent des enregistrements
• Une personne utilise un langage de programmation dans
un projet
• Les modems et les claviers sont des périphériques
d’entrées/sorties
Correction:
A- agrégation
B- généralisation
C- agrégation
D- association
E- généralisation
Exercice 2:
proposez une modélisation de la réalité.
• Une librairie vend des livres, caractérisés
par leur auteur et leur nombre de pages ;
certains livres possèdent également
d’autres caractéristiques : une fourchette
des âges pour les livres pour enfants, et la
discipline et le niveau pour les livres
scolaires.
Correction:
Exercice 3:
Dans une société de transport, on voudrait gérer les bus de
ramassage scolaire et les conducteurs. Un lycéen est un
enfant, il est caractérisé par son nom, son âge et son sexe.
Les informations qui caractérisent le conducteur sont les
mêmes que pour le lycéen, avec en plus le numéro de son
permis. Quant au bus, on a besoin de connaître son
numéro d’immatriculation, sa date de mise en service,
nombre d’années de service, et le poids total.
Un bus est composé d’une carrosserie (poids, couleur), de
6 roues (pression, diamètre), de plusieurs sièges (couleur)
pour passagers, plusieurs vitres (épaisseur, poids).
• Présentez le diagramme de classes adéquat.
- Séance 3 -

PLAN :
 Diagrammes de séquences
 Diagrammes de collaboration
 Diagramme état-transition
 Diagramme d’activités
 Études de cas
UML
Diagrammes de séquences
3
Diagramme de séquences
 Représenter les interactions entre objets en

précisant la chronologie des échanges de
messages
 Représente une instance d’un cas d’utilisation (les
scénarios possible d’un cas d’utilisation donné)
 Montre sous forme de scénarios, la chronologie des
envoies de messages issus d’un cas d’utilisation
 Le diagramme de séquence fait ressortir :
 Les acteurs
 Les objets
 Les messages
4
Obj et_1 Obj et_2 Obj et_3
Message_1
Message_2
Li gne de vi e de
l 'obj et
5
 Un objet est représenté par un rectangle et

une ligne verticale (ligne de vie de l’objet)
 Les objets communiquent en échangeant des
messages représentés par des flèches
orientées de l’émetteur au récepteur
 L’ordonnancement verticale des messages
indique la chronologie
6
 Un message reçu par un objet déclenche

l’exécution d’un opération
 Un message envoyé par objet correspond :
 Demander un service d’un autre objet
 Renvoyer le résultat d’un opération
7
Diagramme de séquences : Exemple
Compte
- N°Compte : String
- Solde : float
+ <<Constructor>> Compte (int n, float s)
+ déposer (float somme) : void
+ retirer (float somme) : float
+ consulter () : float
Le client demande un service (retirer de l’argent) à l’objet Compte

Le compte reçoit le message et déclenche l’opération de même nom
Le compte retourne le résultat
8
Plusieurs concepts additionnels :

 Période d’activité
 Types de messages
 Création et destruction d’objets
 Structures de contrôles
9
Période d’activité
 Correspond au temps pendant lequel un

objet fait une action
 Représentée par une bande rectangulaire
superposée à la ligne de vie de l’objet
Objet_2 Objet_1
Message_1
10
Messages
 Traduisent les interactions (échange

d’informations) entre objets
 Représentés par des flèches orientées de
l’émetteur au récepteur
 Plusieurs types :
 Message simple
 Message minuté (Timeout)
 Message synchrone
 Message asynchrone
 Message récursif
11
Message simple
Message pour lequel on ne spécifie aucune
information d’envoi ou de réception
Objet_1 Objet_2
Message_1
12
Message minuté (Timeout)
 Bloque l’expéditeur pendant un temps donné,
en attendant la prise en compte du message
par le récepteur
 Après le délai, l’expéditeur est libéré et peut
envoyer
Obj et_2 Obj et_1
Message_1 (20 secondes)
13
Message minuté (Timeout) : Exemple
La porte d’un ascenseur s’ouvre pendant un
certain délai avant d’être refermée.
Ascenseur Porte
ouvrir (2 secondes)
fermer
14
Message synchrone (appel de procédure)
 Bloque l’expéditeur jusqu’à la prise en
compte du message par le récepteur
 Le contrôle est passé de l’émetteur au
récepteur qui devient à son tour émetteur
(actif)
Obj et_2 Obj et_1
Message_1
15
Message synchrone (appel de procédure) :
Exemple
Communication client serveur : Sockets
Client Serveur
Sollitation
Acceptation
Requête
Réponse
16
Message asynchrone
 N’interrompt pas l’exécution de l’expéditeur
 L’expéditeur peut émettre sans attendre la
réponse du récepteur
Obj et_2 Obj et_1
M essage_1
17
Message récursif
 Appelé aussi message réflexive
 Message envoyé d’un objet vers lui-même.
Objet_1
Message_1
18
Message récursif : Exemple
Lorsque le client introduit sa carte de guichet,
ce dernier vérifie la validité de la carte avant
de demander le code d’accès
Client GAB
Introduire carte
Vérification validité
Demande code accès
19
Création et destruction d’objets
Un message peut créer ou détruire un objet
Objet_1 Objet_3
Message_1
Objet_2
Création d’objet
Message_2
Objet créé au cours de l’exécution du scénario Destruction d’objet
Objet détruit dans un scénario
20
Traduction des messages
 Envoyer un message c’est demander un

service d’un autre objet (sauf le cas d’un
message de retour).
 Les messages sont traduits par des
opérations dans la classe de l’objet ayant
reçu le message
21
Traduction des messages
class Voiture{
Public void demarrer(){}
}
class Conducteur{
private Voiture voiture;
public void conduire(){
voiture.demarrer();
}
}
… main(String[] arg){
conducteur.conduire();
}
22
Structures de contrôle
Le diagramme de séquences peut inclure un

certain nombre de structures
 Branchements (tests)
 Répétitions (itérations, boucles)
23
Les test (branchements)
La condition précédée le message et elle est
délimitée par des crochets
Objet_1 Objet_2 Objet_3
[condition]: Message
24
Les test (branchements) : Exemple
Pour accéder au centre de recherche, l’utilisateur
doit présenter son badge. S’il a droit d’accès, un
voyant vert est allumé et la porte s’ouvre
Utilisteur Système
Présente son badge
Vérifier droit d'accès

[OK]voyant vert
ouvrir porte
25
Les boucles (répétitions)
La boucle se note comme le test, mais la
condition est précédée d’un astérisque
Objet_1 Objet_2 Objet_3
* [condition]: Message
26
Fragments
 Permet de décomposer une interaction
complexe en fragments simples
 Représenté par un rectangle dont le coin
supérieur gauche contient un pentagone
 Dans le pentagone figure le type du fragment
 loop : boucle
 alt : alternative
 ref : référence
 …
27
Fragments
Tant que x>0 faire
Si x>0 alors
Si x<0 alors
28
UML
Diagrammes de collaboration
29
Diagramme de collaboration
 Représente les interactions entre objets et

relations structurelles permettant celles-ci.
 Permettent la description:
 Du comportement collectif d’un ensemble d’objets
 Des connexions entre ces objets
 Des messages échangés par les objets
 Interaction réalisée par un groupe d’objets
qui collaborent en échangeant des messages
30
 Représentation graphique de l’évolution d’un

ensemble d’objets pour effectuer une action
 Différences avec diagrammes de séquence
 pas d’axe temporel
 temps modélisé par numérotation
31
Éléments d’une interaction

 Instances
 qui collaborent avec d'autres objets en échangeant des
informations
:Classe Objet:Classe
 Représentés par
 liens
 qui sont des supports de messages
 Représentés comme des associations
 messages
 déclenchant les opérations
 Indiqués par des flèches
32
 Exemple : Appel téléphonique
1. Décrocher 4.1b. Sonnerie

:Appelant 2. Tonalité :Ligne 5. Décrocher :Appelé
3. Numérotation 6.1b. Arrêt sonnerie
4.1a. Tonalité sonnerie
6.1a. Arrêt tonalité
33
 Mêmes types contraintes que pour les

diagrammes de séquence
 Itération : *[condition]
 Conditions : [condition]
 Exemple : réservation d’articles

1. commander(n, item) 2. vérifier(n, item)
:Client :Vendeur :Stock
4. livrer(n, item) 3. [disponible]réserver(n, item)
34
 Les objets crées ou détruits au cours d’une

interaction peuvent respectivement porter
les contraintes :
 {Nouveau}
 {Détruit}
<<{Détruit}>> <<{Nouveau}>>
Objet_1 Objet_2
35
Conclusion
 Représentation spatiale
 Aspect temporel plus difficile à suivre que pour les
Diagramme de séquence
 Durée d’exécution d’une contrainte difficile à évaluer
 Diagramme niveau instance
 Limite : taille des diagrammes
 Plus d’instances peuvent être représentées sur un même
diagramme que pour les diagrammes de séquence
36
Exemple : Ascenseur (Séquence)
37
Exemple : Ascenseur (Collaboration)
38
UML
Diagramme état-transition
39
Le diagramme état-transition :
 Fait partie des modèles dynamiques
 Décrit l'enchaînement de tous les états d'un

objet
 Propre à une classe donnée. Il décrit :
 Les états des objets de cette classe
 Les événements auxquels ils réagissent
 Les transitions qu'ils effectuent
40
Le diagramme état-transition manipule

plusieurs concepts :
 État
 Transition
 Événement
 Garde
 …
41
État
 L'état d'un objet est défini par l'ensemble des

valeurs de ses attributs (fenêtre affichée,
fenêtre cachée, …)
 Un état dépend de l'état précédent et de
l'événement survenu
 Un état est représenté par un rectangle aux
coins arrondis Fenêtre
Affichée
- ID : int
- Visible : boolean = True
42
Transition
 C'est le passage d'un état à un autre
 Peut être nommé par un événement
 Représenté par une flèche orientée de l'état
source vers l'état cible
Restaurée
Réduire
Réduite
43
Événement
 Fait (externe) survenu qui déclenche une

transition (changement d'états)
 Peut être réflexif et conduire au même état
 Conduit à l'appel d'une méthode de la classe
de l'objet
 Peut posséder des attributs :
 paramètres portés par des événements
 Représentés entre parenthèses
44
Exemple
Soit le diagramme d’états/transitions de l’objet ‘Fenêtre’
45
Gardiens
 Conditions ou fonctions booléennes
associées à une transition
 Une transition gardée ne peut être effectuée
que si le gardien est vérifié
 Un gardien est représenté entre crochets
Etat1 Etat2
Evénement [Condition]
46
Formalisme et exemple
Etat1 Etat2
Evénement [Condition]
Employé recruté Employé en activité

Prise fonction [Date embauche échue]
47
Actions et activités
 Un objet qui reçoit un événement déclenche

une ou plusieurs opérations
 On distingue deux types d'opérations :
 Action : associée à un état ou à une transition
 Activité : associée à un état
48
Activité
 Opération d'une certaine durée, qui est

exécutée tant que l’objet se trouve dans l’état
 Associée à un état d'un objet
 Représentée dans l'état précédée par la
notation "do/"
49
Action
 Opération instantanée non interrompue

 Peut être associée aussi bien à l'état d'un
objet qu'a une transition
 Elle peut intervenir soit
 En entrée de l'état (préfixe : "entry/")
 En sortie de l'état (préfixe : "exit/")
 En réponse à un événement (préfixe :"evt/")
 Au cours d'une transition (préfixe : "evt/")
50
Formalisme et exemple
Etat 2
Etat_1
entry / Act1
entry / Action_1
do / Act2
do / Action_2
Evénement [Cond]/ Action Evénement() / Act3
Evénement() / Action_3
exit / Act4
exit / Action_4
Embauché
entry / Signer contrat
do / Assurer fonction
Arrivée proposition() / Réponde à la proposition
Mutation() / Changer d'affectation
exit / Rompre contrat de travail
51
État initial et états finaux
Un diagramme état-transition
 Débute toujours par un état initial
 Se termine par un ou plusieurs états finaux (sauf
où le diagramme représente une boucle)
Etat_1
Etat_2
52
Exemple (Feu de signalisation)
Feu
- ID : int
- Couleur : {Vert, Orange, Rouge}
Orange
Vert
Rouge
53
Point de décision
 Permettent de représenter des partages de

transitions ou des alternatives pour le
franchissement d’une transition
 On utilise deux mécanismes :
 Points de jonction (petit cercle plein) : pour
partager des segments de transition
 Points de choix (losange) : pour choisir une ou
une autre transition
54
Point de jonction
55
Points de choix
56
État composite
 Un état composite (#état simple) est

décomposé en deux ou plusieurs sous états
 Cette décomposition est récursive
 Un état composite est représenté comme un
état simple, sauf que les sous états sont
contenus dans le compartiment inférieur.
57
Exemple
58
Historique
 On représente le pseudo état historique par

un H cerclé
 Une transition ayant pour cible l’état
historique est équivalente à une transition
ayant pour cible le dernier état visité dans la
région contenant le H
 H* (historique profond) est un état valable
pour tous les niveaux
59
Concurrences
 Pour représenter la concurrences dans un

diagramme d’états/transitions, on utilise :
 États concurrents
 Transitions concurrentes
60
États concurrents
 État composite pour représenter l’exécution

de plusieurs automates s’exécutant
indépendamment
 On utilise un séparateur en pointillés
 L’objet peut être simultanément dans
plusieurs états concurrents
61
États concurrents
62
Transitions concurrentes
 Deux transitions particulières : fork et join

 La transition fork correspond à la création de
deux états concurrents
 La transition join permet de supprimer la
concurrences (barre de synchronisation)
 Pour pouvoir franchir la barre de
synchronisation, toutes les tâches
concurrentes doivent être achevées
63
Transitions concurrentes
64
UML
Diagramme d'activités
65
Introduction
 Variante des diagrammes d'état-transition

 Permet de décrire le flot de contrôle entre les
opérations :
 Choix
 Séquences
 Itérations
 Parallélisme
 Au niveau macroscopique : décrit les
enchaînements des opérations
 Au niveau microscopique : décrit l'algorithme d'une
action du diagramme d'états
66
Concepts de base
Plusieurs concepts sont manipulés :

 État
 Activité
 Transition (séquentielle, alternatives ou

conditionnelle)
 Synchronisation (disjonction et conjonctions
d’activités)
 Itération
 Swimlanes
67
Comportement conditionnel
 Appelé aussi le branchement

 Symbolise une transition entrante gardée par
une condition et plusieurs transitions
sortantes mutuellement exclusives
68
Comportement conditionnel : Exemple
Demander l'addition
[Prix<=Somme disponible] [Else]
Régler la note
Faire la vaisselle
69
Synchronisation
 Fusion (conjonction) : plusieurs transitions

entrantes et une seule sortante
 Comportement parallèle :
 La barre de synchronisation permet d'ouvrir et de
fermer les branches parallèles au sein d'un flot
d'exécution
 Les transitions partantes d'une barre ont lieu en
même temps
 La barre n'est franchie qu'après réalisation de
toutes les transitions qui s'y rattachent
70
Synchronisation : Exemple
Déserrer le frein à main
Barre de synchronisation
Fusion (conjonction)
Appuyer sur l'embrayage Enclencher la 1ère vitesse

Comportement parallèle
Disjonction
Relâcher l'embrayage
71
Itération : Exemple
Recevoi r commande
Véri fi er arti cl e
Commander arti cl e
[s'i l reste des arti cl es]
[pl us d'arti cl e]
72
Swimlanes
 Extension des diagrammes d'activités
permettant de représenter l'organisation.
 Représente le lieu, le responsable des
activités.
73
Résumé notation
74
Exemple récapitulatif
75
Exercice 1
Représenter les états suivants sous forme de

diagramme d'activité :
 Vérification commande
 Enregistrement commande
 Rejet commande
 Informer erreur au client
76
Exercice 1 : solution
Vérifier commande
Valide
[oui] [non]
Enregistrement commande Rejet commande
Informer erreur au client
77
Exercice 2
Dans le domaine de gestion de stock, on

considère les états suivants indiquant le flot
de contrôle de réception d'une livraison :
Réception livraison, contrôle qualité, contrôle
quantité et enregistrement livraison.
Proposez un diagramme d'activité représentant
ce flot d'information
78
79
Exercice 3
Construire un diagramme d’activité pour

modéliser le processus de commander d’un
produit. Le processus concerne les acteurs
suivants:
 Comptable : enregistrement commande,
envoie la facture et enregistrement paiement
du client
 Client : paiement de la facture
80
81
Exercice 4
Construire un diagramme d’activité pour modéliser le
processus de commander d’un produit. Le
processus concerne les acteurs suivants:
 Client: qui commande un produit et qui paie la
facture
 Caisse: qui encaisse l’argent du client
 Vente: qui s’occupe de traiter et de facturer la

commande du client
 Entrepôt: qui est responsable de sortir les articles
et d’expédier la commande.
82
83
MDE : Ingénierie des models
- Séance 5 -

PLAN :
 Introduction
 Un modèle
 Taxonomie des modèles
 Modèles et métamodèles
 Le MOF : Meta Object Facility
 Ingénierie dirigée par les modèles (IDM)
 Le défi de l’IDM
 Les avantages de l’IDM
 Architecture dirigée par les modèles
 Processus MDA
PLAN :
 MOF et UML
 Extension basée sur le métamodèle
 Techniques et approches de transformation
 QVT
 ATL
 Les transformations ATL
 CIM
 PIM
 Mécanisme de transformation des modèles
 Caractéristiques d’un Archétype
INTRODUCTION
Primordiale lors de l’analyse et de la

conception des systèmes
complexes. Les modèles sont des
abstractions du système et de ses
environnements
INTRODUCTION
Ils permettent de répondre aux

préoccupations des ingénieurs par
la réalisation d’un prototype ou la
modification dans une conception.
Qu’est-ce qu’un modèle ?
un modèle est une abstraction de quelque

chose qui a une existence réelle, il est
différent de ce qui représente et peut être
utilisé pour simplifier la compréhension de
cette.
- Représentation
- Réduction
- Subjectivité
Taxonomie des modèles :
Les définitions présentées sont larges et ne
précisent pas la nature des modèles et des
systèmes modélisés. Il est donc essentiel de
faire une distinction entre les différents types
de modèles notamment dans le contexte de
transformation des modèles.
Taxonomie des modèles :
Trois types de modèles selon leur degré de
précision et leur usage : esquisse, plan et
exécutable.
 Un modèle de type esquisse n’est ni précis
ni complet
 •Un modèle de type plan doit être
suffisamment précis
 Un modèle de type exécutable doit être
précis et non ambiguë
Modèles et métamodèles
Un métamodèle décrit de manière abstraite

une structure possible de modèles.
Le MOF : Meta Object Facility
M3 Le MOF (Meta Object Facility)

metameta
model
Le métamodèle UML et autres MMs

M2
metamodel
Des modèles UML et d'autres
M1
model
Différentes utilisations
de ces modèles
M0
"le monde réel"
Il existe des entités qui peuvent
Niveau M3 Méta-Méta-
Modèle
avoir des relations entre elles
Méta-Modèle Une classe désigne un ensemble

Niveau M2
d’objets qui peuvent avoir des
attributs
Niveau M1 Modèle Une voiture a une couleur et

une immatriculation
Niveau M0
Instances Cette voiture rouge
immatriculée 123A55
Résumé :
Ingénierie dirigée par les modèles
(IDM)
L’ingénierie dirigée par les modèles

(IDM) est une approche de
développement logiciel qui focalise sur
la création et l’exploitation des modèles
plutôt que sur le code source
Le défi de l’IDM :
La communauté du logiciel a été influencée
principalement par trois approches de
développement logiciel :
 Méthode CASE
 Langages de quatrième génération (4GLs)
 L’approche orientée-objet
Les avantages de l’IDM :
L’avantage visé par l’IDM est l’augmentation de la

vitesse du développement logiciel grâce à
l’automatisation.
- Traçabilité et synchronisation
- Meilleure réutilisation des modèles
- Logiciel de qualité
- Séparation des préoccupations

Architecture dirigée par les modèles
l’OMG a lancé une nouvelle approche baptisée

Model Driven Architecture (MDA) qui est une
variante particulière de l’IDM.
Les objectifs majeurs de MDA sont la

portabilité, l’interopérabilité, la réutilisation, la
maintenance et l’augmentation de la
productivité.
MDA préconise l’élaboration des quatre

modèles suivants :
 CIM (Computation Independent Model)
 PIM (Platform Independent Model)
 PSM (Platform Specific Model)

 CODE

modèles suivants :
 CIM (Computation Independent Model)
 PIM (Platform Independent Model)
 PSM (Platform Specific Model)

 CODE
Processus MDA
le MDA prône l’utilisation de ces quatre

modèles dans l’ordre suivant :
 réaliser le modèle des exigences CIM
 réaliser le modèle d’analyse PIM
 enrichir le PIM par des détails techniques
 raffiner le PSM
MOF et UML
UML est une instance et une application de

MOF
UML, en s’appuyant sur le MOF, offre deux

alternatives : extension basée sur le
métamodèle et extension à l’aide des profils
UML2.
Extension basée sur le métamodèle
Extension à l’aide des profils UML2
Un profil UML est un concept qui permet

d’adapter les éléments du métamodèle UML à
un domaine spécifique .
Essentiellement, cela signifie l’introduction de

nouveaux types d’éléments de modélisation en
se basant les éléments originaux d’UML.
Extension à l’aide des profils UML2
Un profil UML est défini par quatre types

d’artefacts :
 metaClass
 Stereotype
 tagged values
 constraint
Transformation des modèles
La deuxième préoccupation clé de l’IDM

consiste à rendre opérationnel les modèles à
l’aide de transformations. En effet, MDA
repose sur le principe de la création d’un
modèle CIM pouvant être raffiné en PIM,
ensuite au PSM pour enfin générer
automatiquement le code source
La transformation ?
D’une manière très large, la transformation des

modèles comme "a program that mutates one
model into another".
L’OMG dans le contexte de MDA, donne la

définition suivante "the process of converting a
model into another model of the same system".
La transformation ?
une définition plus complète "A transformation is the automatic
generation of a target model from a source model, according
to a transformation definition. A transformation definition is a
set of transformation rules that together describe how a model
in the source language can be transformed into a model in the
target language. A transformation rule is a description of how
one or more constructs in the source language can be
transformed into one or more constructs in the target
language".
Transformation endogène versus
transformation exogène
Pour effectuer une transformation de modèles, il est

important que ces modèles soient exprimés par un
certain langage de modélisation, par exemple le
formalisme UML.
une transformation endogène -> modèles =
une transformation exogène -> des langages #

Transformation horizontale
versus transformation verticale
Le niveau d’abstraction est un critère important

permettant de classifier les transformations de
modèles. Une transformation entre deux modèles du
même niveau d’abstraction est dite horizontale.
Quand la transformation concerne deux modèles de

deux différents niveaux d’abstraction, il s’agit d’une
transformation verticale.
Transformation horizontale
versus transformation verticale
Le niveau d’abstraction est un critère important

permettant de classifier les transformations de
modèles. Une transformation entre deux modèles du
même niveau d’abstraction est dite horizontale.
Quand la transformation concerne deux modèles de

deux différents niveaux d’abstraction, il s’agit d’une
transformation verticale.
Techniques et approches de
transformation
Langage impératif versus langage déclaratif
 Un des premiers critères à vérifier est de

savoir si le langage de transformation
repose sur un langage déclaratif ou un
langage opérationnel.
Techniques et approches de
transformation
Langage impératif versus langage déclaratif
 Un des premiers critères à vérifier est de

savoir si le langage de transformation
repose sur un langage déclaratif ou un
langage opérationnel.
Langages de transformation
de modèles
Chaque approche de transformation de
modèle requiert un langage de transformation.
 doit avoir une implémentation efficace
 doit être expressif et non ambiguë
 doit fournir une description précise
 doit différencier les règles de sélection des

éléments du modèle source et les règles de
transformation
 doit proposer des constructions graphiques
Langages de transformation
de modèles
 doit proposer la possibilité de faire des
transformations composites à l’aide des
opérateurs de séquences, de conditions et
de répétions
 doit offrir la possibilité de faire des
transformations bidirectionnelles et une mise
à jour incrémentale des transformations.
QVT (Queries, Views,
Transformations)
Le QVT est un langage de transformation de
modèles standardisé par l’OMG.
ATL (Atlas Transformation
Language)
ATL est un langage de transformation hybride
inspiré du langage QVT.
Il permet à la fois des constructions
déclaratives et impératives.
les auteurs d’ATL recommandent l’utilisation
du style déclaratif qui simplifie l’écriture des
transformations.
Les transformations ATL
Les transformations dans ATL se composent
de trois modules :
 Header
 Helpers
 Rules
Mécanisme de transformation
des modèles
Une transformation de modèles se réalise en
général selon trois étapes:
 Définition des règles de transformation
 Expression des règles de transformation
 Exécution des règles de transformation

Résumé:
LE CIM
le CIM est le modèle qui représente le plus
haut niveau d’abstraction dans l’approche
MDA
 Language Extended Lexicon (LEL)
 Scenario Model
Le PIM
Le PIM est par définition un modèle
indépendant de toute plateforme. Cette notion
d’indépendance de plateforme est liée à la
capacité du modèle à abstraire les
caractéristiques d’une plateforme
technologique particulière.
Caractéristiques d’un
Archétype
Dans la modélisation objet, il existe une différence
fondamentale entre les classes d’analyse et les
classes de conception.
Quatre caractéristiques spécifiant le concept
d’archétype dans le contexte du domaine logiciel :
 Universal
 Pervasive
 Deep history
 Self-evident to domain
MDE : Ingénierie des models
- Séance 6 -

PLAN :
 Les principes de l'approche MDA
 Les modèles CIM, PIM, PDM et PSM
 La transformation des modèles MDA
 Exemple
Les principes MDA :
Lʼinitiative d'architecture dirigée par les
modèles de l'OMG "Model Driven
Architecture" (MDA) est motivée par le
besoin de réduire les tâches de
reconception des applications
Les principes MDA :
Puisque les modèles sont plus pérennes
que les codes, ils permettent de :
 conserver les exigences métiers
 réutiliser les choix dʼarchitecture et de

codage
 assurer lʼintégrité et la cohérence entre
les phases du projet (tests)
Les principes MDA :
 Le principe de MDA est de séparer les

spécifications fonctionnelles des
spécifications de l'implantation sur une
plate-forme donnée
=> interopérabilité des applications
Qu’est-ce qu’un modèle ?
un modèle est une abstraction de quelque

chose qui a une existence réelle, il est
différent de ce qui représente et peut être
utilisé pour simplifier la compréhension de
cette.
- Représentation
- Réduction
- Subjectivité
Modèles et métamodèles
Un métamodèle décrit de manière abstraite

une structure possible de modèles.
M3 Le MOF (Meta Object Facility)

metameta
model
Le métamodèle UML et autres MMs

M2
metamodel
Des modèles UML et d'autres
M1
model
Différentes utilisations
de ces modèles
M0
"le monde réel"
Il existe des entités qui peuvent
Niveau M3 Méta-Méta-
Modèle
avoir des relations entre elles
Méta-Modèle Une classe désigne un ensemble

Niveau M2
d’objets qui peuvent avoir des
attributs
Niveau M1 Modèle Une voiture a une couleur et

une immatriculation
Niveau M0
Instances Cette voiture rouge
immatriculée 123A55
Résumé :

modèles suivants :
 CIM : modèle indépendant de calcul
 PIM : modèle indépendant des plates-
formes
 PDM : modèle des plates-formes
 PSM : modèle dépendant des plates-formes
Processus MDA
le MDA prône l’utilisation de ces quatre

modèles dans l’ordre suivant :
 réaliser le modèle des exigences CIM
 réaliser le modèle d’analyse PIM
 enrichir le PIM par des détails techniques
 raffiner le PSM
Principes MDA :
Le CIM :
 est le modèle d'analyse de base du
métier ou du domaine d’application
 est indépendant de tout système
informatique
 décrit les concepts de l'activité
métier, le savoir faire les processus,
la terminologie et les règles de
gestion (de haut niveau)
Le CIM :
 décrit la situation dans lequel le

système est utilisé
 n'est modifié uniquement que si les
connaissances ou les besoins
métier changent (très longue durée
de vie)
 Les exigences modélisées dans le
CIM seront prise
Le PIM :
 est un modèle de conception

 décrit le système indépendamment
de toute plate-forme technique et de
toute technologie utilisée pour
déployer l’application
 représente la logique métier
spécifique au système
(fonctionnement des entités et des
services)
Le PIM :
 est pérenne dans le temps

 consiste en des diagrammes UML
de classes (avec des contraintes en
OCL)
Le PDM :
 contient des informations pour la

transformation des modèles vers
une plateforme
 est spécifique à une plateforme
 est un modèle de transformation
pour permettre le passage du PIM
vers le PSM
Le PSM :
 sert à la génération du code

exécutable pour les plates-formes
techniques particulières
 décrit comment le système utilisera
la plate-forme
 est dépendant de la plate-forme
Les niveaux du PSM :
 Le premier niveau, issu de la
transformation d’un PIM par
l'adaptation des modèles UML aux
spécificités la plate-forme
 Les autres niveaux PSM sont
obtenus par transformations
successives en prenant en compte
le langage (Java, C#, PHP...), les
choix de conception...
Les niveaux du PSM :
 Le dernier niveau, ou PSM

d’implantation, décrit, en autres, le
code du programme, les schémas
des tables, les bibliothèques
utilisées, les descripteurs de
déploiement...
La transformations en MDA:
 L'approche MDA précise quatre types

de transformations, les modèles
devenant de plus en plus concrets
jusqu’à l’obtention du code
 Par transformations successives, le
PIM, modèle de niveau le plus abstrait,
est transformé en un PSM exécutable
(ou code exécutable)
 Si la démarche MDA a été respectée, il

est possible de générer un PSM, puis
un PIM, à partir du code exécutable
(rétro-ingénierie)
Exemple de CIM :
Flux
Organisation
Exemple PIM:
Exemple de PDM :
Exemple de PSM :

Mdaaa

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mdaaa

Transféré par

Droits d'auteur :

Formats disponibles

Introduction au génie logiciel

Interv. SERNANE SOUFIANE

Ensemble des méthodes, des

Ensemble d'entités nécessaires au

Ensemble de programmes qui permet à

 Spécialistes (calcul météorologique),

ce que doit faire le logiciel, ensemble de

 Délais de livraison non respectés.

 Budgets non respectés.

 Ne répond pas aux besoins de l'utilisateur

 Difficile à utiliser, maintenir, et faire évoluer

Enquête sur des milliers de projets, de toutes

- Taille des équipes de conception/développement

Manque de méthodes et de rigueur :

- Négligence et manque de méthodes et d'outils des

Mauvaise compréhension des besoins :

- Manque d'implication du client dans le processus

Fiabilité, sûreté et sécurité des logiciels:

- Contrôle de processus industriels, nucléaire,

- Médical : imagerie, appareillage, télé-surveillance

- e-commerce, carte bancaire sans contact,

Raisons économiques : coût d'un bug

- Coût de l'impact sur l'image, de l'arrivée tardive sur

- Coût en vies, coût de l'impact écologique

Idée : appliquer les méthodes classiques

Ingénierie (ou génie) : Ensemble des fonctions

 Facilité d'utilisation : prise en main et robustesse

 Performance : temps de réponse, débit, fluidité...

 Fiabilité : tolérance aux pannes

 Maintenabilité : facilité à corriger ou transformer le

 Portabilité : changement d'environnement matériel

Ensemble d'activités successives, organisées

 Choix du processus en fonction des contraintes

 Adaptation de « processus types » aux besoins réels

Activités du développement logiciel:

Analyse des besoins : Comprendre les besoins

 Fournie par le client

 Clarifier le cahier des charges en listant les exigences

Conception : Élaborer une solution concrète

 Réalisation des fonctionnalités par les composants

 Réalisation des exigences non fonctionnelles (performance,

Programmation : Implantation de la solution

 Vérification : assurer que le logiciel satisfait sa spécification

 Adaptation : adapter le logiciel aux changements dans

 Perfection : améliorer la performance, ajouter des

 Mise en évidence de la complémentarité des phases

 Écriture de la spécification à partir du prototype, puis

 Concevoir et livrer au client un produit implantant un sous-

 Développement dirigé par les tests

 Cycles de développement rapides pour réagir aux

Objectif : Traçabilité du projet

 Regrouper et structurer les décisions prises

 Faire référence pour les décisions futures

 Garantir la cohérence entre les modèles et le produit

 Donner une vision claire de l'état d'avancement du projet

Rédaction : le plus souvent en langage naturel (français)

 Ambiguïtés : plusieurs sens d'un même mot selon les

 Contradictions, oublis, redondances difficiles à détecter

 Difficultés à trouver une information

 Mélange entre les niveaux d'abstraction

Alternatives au langage naturel :

 Langage naturel structuré : modèles de document et règles

 Pseudo-code : description algorithmique de l'exécution d'une