Cours GL-L3NTIE Lakhrissi

Le Génie Logiciel
IUP NTIE
2010/2011
Sophie Ebersold & Younes Lakhrissi
Le génie logiciel
Partie I
Notions de base & Principes
Plan de la Partie I
1 - Définitions de base
Logiciel
Génie logiciel
Critères de la qualité logicielle
2 - Cycle de vie de logiciel

Objectif
Phases nominales du développement logiciel
3 - Modè
Modèles de cycle de vie
Modèles linéaires
Modèles non linéaires
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 3

Logiciel ?
Définition :
Un logiciel ou une application est un ensemble de programmes, qui
permet à un ordinateur ou à un système informatique d'assurer une
tâche ou une fonctionnalité
Physiquement :
Une suite d’items ou d’objets
une structure d’informations Incluant programmes, données, documents, …
Le logiciel n’est pas seulement un ensemble de programmes, mais

aussi la documentation pour :
l’installation,
l’utilisation,
le développement,
la maintenance.
Les différentes catégories de logiciel (1/3)
Sur mesure
Pour un client spécifique
Générique
Vendu sur le marché
• un tableur (spreadsheet), un outil de base de donnée (database)
• un outil de traitement de texte (word processor)
•…
Embarqué
Embarqués
Exécutent dans du matériel électronique isolé
machine à laver, télévision, lecteur DVD, téléphone mobile,
magnétoscope, four à micro-ondes, réfrigérateur, joueur MP3, ...
Difficile à modifier

Logiciel à temps ré
réel
Systèmes de contrôle et de surveillance
Manipulent et contrôlent le matériel technique
Réaction immédiate requise
Environnement contraignant
Logiciel de traitement de donné

données
Ils stockent, recherchent, transforment et présentent l'information aux
utilisateurs
Grandes quantités de données avec des corrélations complexes,
enregistrées dans les bases de données
Largement utilisés en administration des affaires
Fiabilité des résultats
Sécurité dans l’accès aux données
Quelques fois les 2 aspects sont pré

présents dans un logiciel
Les systè
systèmes distribué
distribués
Synchronisent la transmission, assurent l’intégrité des données et la
sécurité, ...
Technologies utilisées
CORBA, DOM/DCOM/.NET, SOAP, EJB, …
Les systè
systèmes de maté
matériel
Systèmes d'exploitation, exécutions de matériel de bas niveau
Les systè
systèmes d'entreprise
Décrivent les buts, les ressources, les règles et le travail réel dans une
entreprise

La nature du logiciel (1/3)
Le logiciel est facile à reproduire

Tout le coût se trouve dans son développement
Pour d’autres produits, la fabrication est souvent le processus le plus
coûteux
Le logiciel est intangible

Il est difficile d'estimer l’effort de développement
Le processus de dé
développement est difficile à automatiser
L’industrie du logiciel exige beaucoup de main d’œuvre
qualifiés peuvent arriver à bricoler

Même des informaticiens peu qualifié
quelque chose qui semble fonctionner
La qualité d’un logiciel n’est pas apparente
Un logiciel semble facile à modifier

La tentation est forte d’effectuer des changements rapides sans
vraiment en mesurer la portée
Un logiciel ne s’
s’use pas
Il se détériore à mesure que des changements sont effectués
en raison de l’introduction d’erreurs
ou par une complexification indue
Beaucoup de logiciels sont mal conç

conçus et se dé
détériorent
rapidement
La demande pour du logiciel est toujours croissante

Raisons pour lesquelles le logiciel vieillit :

Maintenance (bug fixes)
Erosion architecturale
Inflexibilité dès le début
Documentation insuffisante ou inconsistante
Manque de modularité
Complexité croissante, …
Un logiciel est fiable s’

s’il :
Répond aux spécifications
Ne produit jamais de résultat erroné
Ne jamais entrer dans un état incohérent
Réagir de façon sensée et utile en présence d’une situation inattendue
Le Génie Logiciel ?
Art de produire du logiciel

Art de spécifier, concevoir, réaliser, et de faire évoluer, avec des
moyens et dans des délais raisonnables, des programmes, des
documentations, et des procédures de qualité en vue d’utiliser un
ordinateur pour résoudre certains problèmes.
Art de bien faire de bons Logiciel

Art : technique, créativité, esthétique,…
Bien faire : réussite, rentabilité,…
Bons : performance, fiabilité,…
On parle de processus de dé
développement de logiciels et gestion de
projets
Gestion du personnel : Efforts
Gestion des ressources : Coûts
Aspects techniques : Conception & Réalisation
Contraintes de réalisations : Planification

Le génie logiciel
Les points communs des dé

définitions
Travail de groupe et non d’un individu isolé
Besoins techniques et non-techniques
Connaissances informatiques
Capacité de communication
Gestion de projet
Objectif du GL
Développer des logiciels considérés comme :
Logiciels fiables
Logiciels satisfaisant les besoins
Logiciels maintenables
Logiciels exploitables dans différents environnement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 12 12
Le génie logiciel - Origine
Origine : Apparu en 1968, devant les insatisfactions gé

générales en
matiè
matière de logiciel :
Fiabilité douteuse
Dépassement des délais
Dépassement des coûts
Erreurs résiduelles persistantes
Sensibilité aux erreurs humaines, aux pannes matérielles
Difficultés de conversion, de mise en œuvre
Difficultés d'évolution
+
Complexité croissante du logiciel
Coût croissant lié en grande partie à la maintenance (excessive)
+
Criticité des secteurs d'activité

Le génie logiciel - Risques
Risques majeurs du dé
développement logiciel
Défaillance humaine
Calendrier et Budget irréaliste
Développement de fonction inappropriées
Développement IHM inapproprié
Produit « plaqué-or »
Volatilité des besoins
Composants externes manquants
Problèmes de performances,
….
Quelques statistiques
Étude du gouvernement amé

américain en 1979
Payés mais jamais livrés 45%
Livrés mais jamais utilisés 30%
Abandonnés ou refaits 20%
Utilisés après modification 3%
Utilisés tel quel 2%
Part des erreurs
36%
erreurs de définition.
erreurs de codage
64%

Les critères de qualité du logiciel
Validité : Conformité d'un logiciel avec sa spécification

Robustesse : Capacité à fonctionner même dans des conditions anormales
Extensibilité : Facilité d'adaptation à des changements de spécifications
Réutilisabilité : Capacité à être réutilisé en tout ou partie dans une nouvelle
application
Compatibilité : Facilité avec laquelle des composants logiciels peuvent être
combinés
Efficacité : Utilisation optimale des ressources matérielles
Portabilité : Facilité de transfert dans différents environnements
Vérifiabilité : Facilité de préparation des procédures de validation
Intégrité : Aptitude à protéger codes et données
Facilité d'utilisation : Ergonomie, Facilité d'apprentissage
Cycle de vie du logiciel ?
Le développement d’un grand système logiciel prend un temps

considérable
On identifie un certain nombre d’étapes dans la période de
développement
Ces étapes constituent le cycle de vie du logiciel
Définition :
C’est le processus qui couvre le déroulement des phases de
développement, de distribution et de disparition d’un logiciel
Le logiciel est le résultat d’un processus d’élaboration constitué d’une
suite d’étapes ou phases ayant pour objectifs de passer du QUOI
(Spécification) au COMMENT (Conception).
Chaque phase utilise des produits en entrée et génère des produits en
sortie, qui sont utilisés dans les phases ultérieures.

Cycle de vie du logiciel
Objectifs
Maîtriser les coûts en terme de délai et de budget
Maîtriser les risques
Avoir une qualité conforme aux exigences
C’est la feuille de route du développement logiciel
Le cycle de vie est fortement lié à l’assurance qualité
Il faudra en permanence assurer la vérification et la validation

Vérification : Est-ce que nous construisons bien le produit ?
Validation : Est-ce que nous construisons le bon produit ?
Cycle de vie du logiciel
Phases du cycle de vie

Définition des objectifs
Définition des besoins
Analyse des besoins
Planification et gestion de projet
Conception globale
Codage et tests unitaires
Intégration
Qualification
Maintenance

Phase de définition des objectifs/besoins
But : Première description du futur système

Description de ce que doit faire le logiciel, indépendamment de l'implantation
(QUOI et non COMMENT)
Définition des objectifs

Étude de faisabilité
Stratégie
Décider du besoin de produire le logiciel
Élaboration du schéma directeur (vue globale, orientations, suggestion,
planification)
Définition des besoins

Établir le Cahier des Charges (CDC)
Lancement d’appel d’offres
Le CDC décrit les fonctionnalités attendues du produit, les contraintes non
fonctionnelles (temps de réponse, contraintes matérielles,…)
Produits issus de cette phase : Le cahier des charges

charges
Le cahier des charges
Définition
C’est un document technique
Rédigé par l’équipe marketing ou par le client
S’adresse au client et aux développeurs et sera à la base du contrat
Les besoins relevés dans le CDC doivent être :

Précis
Cohérents
Complets
Testables par une métrique
Maintenables et flexibles

Le cahier des charges
Critè
Critères de succè
succès
Se placer à un bon niveau de généralité
Décrire bien le problème posé
Définir les critères de validation
Exprimer facilement les changements au niveau des besoins
Le rédacteur du CDC doit avoir les qualités suivantes :

Capable d’abstraction et de structuration
Capable de connaître et anticiper le processus de développement
Avoir un recul
Phase d’analyse des besoins
But
Étude du domaine d'application et de l'état actuel de l'environnement du futur
système :
Frontières
Rôle
Ressources disponibles et requises
Contraintes d'utilisation et de performance
Démarche
Élaboration des spécifications
Description des contraintes de réalisation
Ébauche du manuel d’utilisation
Produits issus de cette phase :
Une ébauche du manuel d’utilisateur
Une ébauche du glossaire propre au projet
Le dossier d’analyse
Doit fournir une description complète et détaillée des fonctions du produit dans sa
relation avec l’environnement
Sera utilisé par le client et par les développeurs
Définit les termes du contrat passé entre le client et le fournisseur du logiciel

Dossier d’analyse (DA): principes de base
Le DA contient la description du produit vu de l’l’exté

extérieur, pour en dé
dériver :
La documentation client
Les jeux de test
Dossier d’
d’analyse : plan type
Introduction
Objectifs, fonctionnalités attendues, environnement, faisablité, éléments de coûts,…
Fonctions du produit
Concepts et terminologie, description fonctionnelle externe (entrées-sorties, IHM,…)
Description interne
Interaction avec environnement, contraintes,…
Questions ouvertes et réponses apportées par les développeurs
Éléments de livraison
Cahier provisoire de recette
Phase de planification et gestion de projet
Démarche
Découpage du projet en tâches
Enchaînement de tâches dans le temps
Attribution de durée et d’effort à chaque tâche

Le plan qualité
Le plan projet destiné aux développeurs
Une estimation des coûts réels
Un devis destiné au client

Phase de conception
Conception architecturale
Définition de l’architecture du logiciel
Décomposition du logiciel en composants plus simples et spécification
modulaire
Élaboration des interfaces entre les différents modules
Le dossier de conception
Le plan d’intégration
Les plans de test
Le planning mis à jour
Conception détaillée
Enrichir la description du logiciel de détails d'implantation afin d'aboutir
à une description proche de la programmation.
Pour chaque composant : description des fonctions à réaliser : algorithmes,
représentation des données
Phase de codage et tests unitaires
Chaque module est codé individuellement

Entrée : Résultat de la conception détaillée
Produit : Ensemble de programmes ou de composants de programme
Chaque module est testé indépendamment des autres

Les modules codés et testés
La documentation de chaque module
Les résultats des tests unitaires
Le planning mis à jour
Part de chaque activité dans l'effort total de développement
20%
40%
programmation
Spécification et Conception
Validation et Vérification
40%

Phase de gestion de configuration et Intégration
Gestion de configuration
Permettre la gestion des composants
En maîtriser l'évolution
En faire les mises à jour tout au long du processus de développement
Documents relatifs au développement du logiciel
Intégration : Assemblage de composants pour obtenir un système exécutable

Chaque module testé est intégré avec les autres selon le plan d’intégration
L’ensemble des modules est testé conformément au plan de tests
Le logiciel testé
Les tests de régression
Le manuel d’installation
La version finale du manuel utilisateur
Phase de Qualification et Maintenance
Qualification
Le produit est testé en vraie grandeur dans des conditions d’utilisation
normales
À l’issue de cette phase, le logiciel est prêt à l’exploitation
Maintenance
Après livraison, le logiciel entre dans la phase de maintenance
Au fur et à mesure que l’environnement change, le système doit
s’adapter à ces changements
Ce processus de changement s’appelle l’évolution du logiciel
La maintenance d’un logiciel consiste à en corriger les erreurs et à
modifier le système pour refléter les changements de l’environnement

Activités transversales
Validation et vé
vérification
But :
Validation : Contrôler l'adéquation entre les besoins des utilisateurs spécifiés
lors de l'analyse des besoins et les fonctionnalités du logiciel
Vérification : Contrôler l'adéquation de la spécification globale et du logiciel
Moyens :
Revues, Inspections de manuels et Maquettage pour la validation
Preuves et Tests pour la vérification (tests unitaires, tests d'intégration, tests
système)
Maquettage
Utilisé lors de la validation, afin de fournir un aperçu des fonctionnalités
du système final (prototype rapide).
Soumis à de scénarii en liaison avec les futurs utilisateurs : permet de
préciser leurs souhaits ou leurs choix (maquette exploratoire)
Expérimentation et confrontation de choix de conception différents
(maquette expérimentale)

Modèles ?
J-L. Lemoigne,
Lemoigne, 1990
«Action d’élaboration et de construction intentionnelle, par composition
de symboles, de modèles susceptibles de rendre intelligible un
phénomène perçu complexe et d’amplifier le raisonnement de l’acteur
projetant une intervention délibérée au sein du phénomène :
raisonnement visant notamment à anticiper les conséquences de ces
projets d’action possibles»
Définition :
Un modèle est une abstraction de quelque chose de réel qui permet de
comprendre avant de construire, ou de retrouver les informations
nécessaires pour effectuer des modifications et extensions
Le modèle simplifie la gestion de la complexité en offrant des points de
vue et niveaux d’abstractions + ou - détaillés selon les besoins
Définition :
Permettent d'avoir une méthodologie commune entre le client et la
société de développement
Définissent et concrétisent les étapes du développement
Définit et planifier les documents à produire permettant de valider
chacune des étapes avant de passer à la suivante
Le rôle des modè

modèles
Faciliter la compréhension humaine et la communication
Supporter l’amélioration des processus de développement et de
maintenance
Supporter la conduite et la gestion des processus de développement et
de maintenance
Assurer un guidage automatique des acteurs
Faciliter l’automatisation des processus de développement et de
maintenance

Les modè
modèles liné
linéaires
La cascade
Le modèle transformationnel
Le modèle en Y
Le modèle en V
Le modèle en X
Le modèle en W
Les modè
modèles non liné
linéaires
Le prototypage
Le modèle en spirale
Le modèle par incréments
Le modèle évolutif
Modèles de cycle de vie linéaires

La cascade
Principe
toutes les étapes doivent être réalisées
ordre respecté
passage de l'étape n à l'étape n+1 qu'après acceptation de l'étape n
remises en cause de l'étape n propagées uniquement jusqu'à l'étape n-1
Définition
des besoins
Conception
Logiciel
Intégration et
Validation
Maintenance
La cascade
Avantages
Facile à comprendre
Ce modèle est approprié lorsque les besoins sont bien clarifiés et les
changements sont très limités durant la conception du processus
Plus utilisé dans l’industrie
Limites
Pas transparent au client lors du développement
Difficulté de répondre aux besoins changeants du client
Pas de frontières claires entre conception et développement
Difficulté d’apporter des changements après finalisation du processus
Une phase doit être achevée avant de pouvoir passer à la phase suivante
Î Ce modè
modèle est en gé
général abandonné
abandonné au profit du modè
modèle en V plus
récent et actuellement, dans les mé
méthodes objet

Le modèle en V
Principe :
La représentation en V tient d'avantage compte de la réalité
part du principe que les procédures de vérification de la conformité du
logiciel aux spécifications doivent être élaborées dès les phases de
conception
Il montre que:
c'est en phase de spécification que l'on se préoccupe des procédures de
qualification
c'est en phase de conception globale que l'on se préoccupe des procédures
d'intégration
c'est en phase de conception détaillée que l'on prépare les tests unitaires
Chaque étape prend en entrée les résultats de l'étape précédente et les

documents produits.
Le modèle en V

Le modèle en V
Modèle en W

Le modèle en Y
Un processus en 2 chemins ou modè

modèle en Y
La branche fonctionnelle correspond à la tâche traditionnelle de

modé
modélisation
du domaine
du problème à résoudre
des besoins des utilisateurs.
L'ajout d'une branche technique indé

indépendante
il faut faire des choix en matière de techniques
La troisiè
troisième branche : une synthè
synthèse des 2 chemins :
articuler le mieux possible des composants "métier" avec des
composants technologiques pour produire une solution logicielle
Le modèle en Y

Le modèle en Y
La branche technique ; exemples de choix :

Une BD centrale unique ou des BD réparties qui communiquent entre
elles.
mise en œuvre de composants autres que le seul stockage et accès
sécurisé aux données :
interfaces utilisateurs,
communication de l'information via des réseaux (locaux, intranet, internet...),
présentation de l'information sur les postes de travail, etc.
Le modèle transformationnel
Suppose un systè
système automatique de transformation des
spé
spécifications validé
validées en programmes.
Trois scé
scénarios d’
d’automatisation
1. les spécifications formelles des besoins sont traduites à l’aide d’outils
appropriés en un logiciel opérationnel
2. les spécifications formelles des besoins sont décrites et traduites à
l’aide d’outils appropriés en des spécifications détaillées exécutables
3. le code est généré à l’aide d’outils logiciels tels que les générateurs de
code
Spécification
Validation
Transformation

Le modèle en X
Repose sur le principe de la ré

réutilisabilité
utilisabilité
Propose deux processus de dé développement concurrents des
logiciels
Le premier processus consiste en la réalisation de solutions logicielles
réutilisables (DER ou « Build for Reuse »)
Le second processus consiste à produire des solutions logicielles à
partir d’une base de solutions existantes (DAR ou « Build with Reuse »)
La ré
réutilisabilité
utilisabilité dans le modè
modèle « en X » peut être ré
réalisé
alisée à
plusieurs niveaux :
au niveau de l’architecture logique ou physique des composants
au niveau de l’architecture conceptuelle (domaine d’intérêt du sujet)
au niveau des modèles du domaine
au niveau des spécifications
Les modèles de cycle de vie linéaire

- Synthèse -
Avantages :
Processus ordonné et discipliné du développement
Conception robuste
Meilleur contrôle de la qualité et la maintenance
Inconvé
Inconvénients :
Pas de recouvrement des phases
Effort de documentation important à chaque phase
Reprises coûteuses en cas de divergences par rapport à la
compréhension des besoins utilisateur

Les modèles de cycle de vie non linéaires
Principe
Les logiciels réalisés suivant ces modèles sont développés par
itérations ou incréments successifs
Les détails de réalisation peuvent être reportés afin de produire une
version opérationnelle du logiciel le plus tôt possible au cours du
processus de développement
Ces modèles semblent plus appropriés pour prendre en compte le
caractère évolutif des besoins des utilisateurs et les applications
novatrices
Exemples de modè
modèles non liné
linéaires
Le prototypage
Le modèle par incréments
Le Prototypage
Définition :
l’élaboration de versions opérationnelles du futur logiciel dès le début du
cycle de vie
la mise en évidence et la clarification par expérimentation des problèmes
les plus significatifs
l’élaboration de prototypes qui constituent une base de discussion et de
communication entre les utilisateurs, les informaticiens et les autres acteurs
de l’organisation
Le logiciel est ensuite dé

développé
veloppé à nouveau dans le souci de satisfaire
les critè
critères de qualité
qualité
Consulter Construire ou
Client modifier prototype
Tester le
prototype

Le prototypage
Spécifications Réalisation Evaluation Spécification

Grossières du Prototype du système
Conception et Validation du
Implantation Système
Le prototypage
Avantages
Client est acteur dans le processus
Client reçoit des résultats rapidement
Permettre de se concentrer sur les points critiques, les zones
d’incertitudes très tôt dans le développement
Simplifier l’élaboration des spécifications, de l’interface H/M: les
spécifications ne sont plus écrites mais montrées
Inconvé
Inconvénients :
Problèmes relatifs à la conduite du développement
Problèmes relatifs à la gestion de projet
Qualité du produit développé est souvent faible
Produit non commercialisable

Le modèle par incréments ou par grappes
Principe :
Développement du logiciel noyau puis développement et intégration des
composants, successivement.
Avantages :
Développement moins complexe et itératif
Développement ascendant : des incréments généraux (fonctions utilitaires)
aux incréments spécifiques (proches de l’application)
Intégrations progressives : Ordonnancement flexible des incréments
(fonctions des ressources, de l’expérience de l’équipe, des demandes de la
direction, et des clients, …)
Ordre des étapes du cycle de vie respecté pour chaque incrément
Relations entre incréments : chaque incrément peut être client d’incréments
de niveau inférieur
Livraison et mise en service possibles après chaque intégration d’incrément
Effort de maintenance dune version provisoire généralement négligeable

Inconvé
Inconvénients :
Il faut spécifier dès le début du développement de l’architecture globale du
logiciel et les différents lots qui seront développés: le noyau, les incréments
(qui doivent être indépendants fonctionnellement), leur intégration
Risque de voir remettre en cause le noyau ou les incréments précédents un
développement
L ’ajout de composants peut être complexe
Chaque développement est de + en + complexe, du point de vue de
l ’intégration
Solutions :
Spécification noyau, incréments et interactions au début du projet
Incréments aussi indépendants que possible (fonctionnellement et dans le
temps) : Contradiction
Le dé
développement évolutif consiste à Version n
réaliser :
une version provisoire du logiciel
(prototype) qui sera mise en Détermination des besoins
exploitation
des nouvelles versions de ce logiciel

opérationnel (prototype) comprenant Programmation
de nouvelles fonctionnalités ou une
version modifiée des fonctionnalités
déjà installées
La version finale comportera toute la Expérimentation

documentation, la formation, ...pour
la mise en exploitation du logiciel
Version n +1

Inconvé
Inconvénients
Comme dans le modèle incrémental, la réalisation d’une nouvelle version
comporte plus de risques que celle de la version précédente
Difficulté d’obtenir dans les délais les résultats de l’évaluation par les
utilisateurs de la nouvelle version du prototype
Difficulté de gestion des différentes versions du logiciel et de traçabilité
de leurs composants
Difficulté de déterminer le niveau de qualité du prototype et de sa
documentation
Principe :
Cycles de développement successifs du logiciel
Un prototype identifié par cycle
Quatre quadrants représentant quatre phase de développement pour
chaque cycle
Analyse préliminaire, détermination des objectifs du cycle, des alternatives,
des contraintes
Analyse des risques, Evaluation des alternatives, Prototypage
Développement et Vérification de la solution
Tests, Revue des résultats, Planification du cycle suivant

Avantages :
Produit rapidement un logiciel opérationnel minimal. Permet de ce concentrer
sur les aspects les plus incertains du développement
Suppose une discipline stricte pour éviter de « coder/finaliser ». Il faut accepter
les remises en cause de la part du client à chaque nouvelle évaluation
Ouverture à l ’ensemble des approches et technologies de développement
existantes
Inconvé
Inconvénients:
Difficultés pour mener à bien les premiers cycles de la spirale
Risque de remise en cause des spécifications des modules/versions déjà
réalisés lors de l ’analyse de nouveaux modules/versions
Difficultés de mise en oeuvre au niveau procédural et de contrôle du processus
Organisation opérationnelle du développement souvent modifiée pour le client

Les modèles de cycle de vie non linéaires
- Synthèse -
Avantages
Permettre de livrer rapidement une version opérationnelle du logiciel
Permettre de cerner les besoins des utilisateurs et des développeurs avant
d ’engager des dépenses plus importantes
Eliminer la maintenance: le logiciel entre dans un cycle de développement-
évolution permanent
Inconvé
Inconvénients
Risque de blocage dans le cas où il y beaucoup d’utilisateurs pour évaluer
les versions
Risque d’itérations sans fin
Conduit à coder avant de finaliser
Problèmes relatifs à la gestion de projet: (dérive des coûts et des délais,
changement du mode opérationnel du développement fréquent pour les
clients, pb de gestion de versions, ... )
Les modèles de cycle de vie

- Synthèse -
Dilemme :
Quel modèle pour quel projet ?

Le génie logiciel
Partie II
Techniques d’Analyse/Conception
62
Plan de la partie II
1- Techniques de Spé
Spécification
2- Techniques d’
d’Analyse et de Conception
3- Techniques de Vé
Vérification

Spécification ?
Définition :
Méthodes développées pour répondre à l’évolution des matériels, des
systèmes, des langages de programmation et essentiellement à la
complexité croissante des logiciels.
Elles permettent de «normaliser » et «formaliser » les différentes
activités afin de limiter les problèmes d’incompréhension entre les
différents intervenants
On distingue 3 types de spé

spécifications :
spécifications informelles
en langue naturelle
semi formelles
souvent graphiques, dont la sémantique est plus ou moins précise
formelles
quand la syntaxe et la sémantiques sont définies formellement par des outils
mathématiques
Différentes techniques de spécification
Techniques informelles
Le dictionnaire des données ou glossaire,
La table de décision,
…
Techniques semi-
semi-formelles
Le modèle entité-association (Entity Relationship Model),
Les diagrammes de flots de données (Data Flow),
Les diagrammes de structure (Structured Charts),
…
Techniques Formelles
Les diagrammes états-transitions,
Les réseaux de Pétri,
…

Techniques de spécification informelles
Définition
Elles sont très souples, conviennent pour tous les aspects, sont très
facilement communicables à des non spécialistes.
Elles manquent de structuration, de précision et sont difficiles à
analyser.
Des efforts peuvent être faits pour les structurer (spécifications
standardisées) :
chapitres, sections, items, justifications, etc
Exemples
Le dictionnaire des données ou glossaire :
Ensemble des spécifications des données utilisées aux différents niveaux
d’analyse et de conception
La table de décision
Représentation tabulaire de tous les cas des valeurs d’entrée d’un
processus et des valeurs de sortie correspondant à chacune de ces
combinaisons
Techniques semi-formelles
Souvent graphiques, dont la sémantique est plus ou moins précise
Le modèle entité-association (Entity Relationship Model),

Les diagrammes de flots de données (Data Flow Diagram),
Les diagrammes de structure (Structured Charts), …

Le modèle entité-association
Utilisé dans de nombreuses méthodes d’analyse sous sa forme initiale ou

dans des méthodes à objets sous sa forme étendue
parfaitement adapté à la conception de bases de données
Concepts mis en œuvre :

classe d’entité : regroupement des propriétés communes à plusieurs
entités
occurrence d’entité : représentation d'un objet matériel ou immatériel du
monde réel
attribut : propriété (champ)
identifiant (clé) : attribut d’une entité dont la valeur permet de la désigner
sans ambiguïté.
relation ou association : lien entre deux classes d’entité
cardinalité de la relation : spécification du nombre d’occurrence d’entités
concernées
Le modèle entité-association
au plus un Y
Cardinalités
un et un seul Y
à tout X correspond :
0 ou plusieurs Y
1 ou plusieurs Y
Exemple
concerne est_concer
PROPOSITION concerner né
PROJET
(1,1)
est_envoyé
num_prop (0,n)
date_arrivée (1,1)
code_projet
nom_projet
état Envoyer nom_responsable
(0,n) date_limite
envoie
SOC-SERVICE
code_société
nom_société
adresse_société

Les diagrammes de flots de données
(Data Flow Diagramm)
Caracté
Caractéristiques
Modélisation des traitements
Permettent de montrer comment chaque processus transforme ses
entrées successives (flots de données entrants) en sorties
correspondantes (flots de données sortants)
Les DFD décrivent des collections de données manipulées par des
fonctions.
Les données peuvent être persistantes (dans des stockages) ou
circulantes (flots de données).
La représentation graphique classique distingue :
les fonctions par des cercles
les stockages par des boîtes ouvertes
les flots par des flèches
les entités externes par des rectangles

Un DFD est souvent accompagné

accompagné d'un diagramme de contexte
Représentation des échanges de flots de données avec les acteurs
extérieurs au système à modéliser
Proposition
Responsable du Lettre d'acceptation Société de

critères de Sélection
Projet sélection des services
Lettre de refus
propositions

Exemple de DFD
Proposition Lettre d'acceptation
Saisie Acceptation
PROPOSITION
SOC_SERVICES
critères de sélection Note
Refus
Evaluation
Lettre de refus
PROJET
Techniques de spécification formelles
La syntaxe et la sémantiques sont définies formellement par des outils

mathématiques
Exemples
Les diagrammes états-transitions
Les réseaux de Pétri

Matérialisent l’incidence des événements sur les différents états du

système en indiquant les actions à effectuer
Sont particulièrement bien adaptés pour modéliser le cycle de vie d’un

objet
permettent de préciser les valeurs d'un attribut (ex : état soumis, en

examen, accepté ou refusé) défini dans le modèle entité/association
Sont plus adaptés aux systèmes synchrones qu’asynchrones
C’est une technique formelle très largement répandu pour décrire les
aspects liés au contrôle
Exercice :
Réaliser un diagramme
états/transitions sur le
déroulement d’un appel
téléphonique.
Quelques états :
En attente,
En Tonalité,
En numérotation,
En connexion,
En sonnerie,
…

Définition
Outil mathématique permettant de modéliser le comportement d'un
système dynamique à événements discrets.
Technique formelle est particulièrement bien adaptée pour décrire le
comportement des systèmes asynchrones avec des évolutions
parallèles
Constituants :
Places ( ) : états du système
transitions ( ) : changements d'état
marquage ( jeton ) : permettent de définir l'état du système à un
instant donné
Sémantique
Chaque place peut contenir un
ou des jetons
L’état du RdP est défini par le

marquage de ses places.
Si toutes les places d’entrée

contiennent au moins un jeton,
la transition est franchissable :
ce qui retire un jeton de
chaque place d’entrée
ajoute un jeton dans chaque
place de sortie.
Attention aux interblocages !

Exercice
P1
P2
P1 : Appel d'offre en cours
P2 : Enregistrement proposition
P3 : Examen proposition
P4 : Proposition acceptée
T4 T1
P5 : Proposition refusée
P6 : Appel d'offre terminé (annulé) P6 P3
T1 : Début d'examen
(transition simple)
T2 : Critères Satisfaits
(condition) T2 T3
T3 : Critères non satisfaits
P5
(condition) P4
T4 : Arrivée date limite
(événement)
Plan
Spécification
2- Techniques d’
Méthodes fonctionnelles
Méthodes orientées objet
Vérification

Méthodes d'analyse et de conception
On distingue les approches ascendantes et les approches

descendantes.
Méthode descendante :
Démarche par affinages successifs consistant à partir de l’expression la
plus générale du problème et à décomposer de façon itérative les
tâches à réaliser en sous tâches jusqu’à un niveau d’expression assez
élémentaire pour pouvoir être traduit dans un langage de
programmation
Méthode ascendante :
Réutilisation de composants logiciels préexistants et construction de
nouveaux systèmes par combinaison d’éléments prédéfinis
Certaines approchent combinent les deux, notamment dans le

domaine «objet »
Méthodes fonctionnelles
Caracté
Caractéristiques
Plus orientées vers les traitements que vers les données,
mettent en évidence les fonctions à assurer et proposent une approche
hiérarchique, descendante et modulaire, en précisant les liens entre les
différents modules
Utilisent des notations de type DFD
Exemples
SADT (Structured Analysis and Design Technique)
SA (Structured Analysis )
SD (Structured Design)

SADT
(Structured Analysis and Design Technique)
Couvre essentiellement la première partie du cycle de vie
Suite cohérente et hiérarchisée de diagrammes obtenus par

raffinements successifs
Datagramme : Représentation des données (boites) et des activités qui
les créent ou les utilisent (flèches)
Actigramme : description de l’enchaînement des activités (boites) et des
données qu’elles manipulent (flèches).
Activités de Données de
Contrôle Contrôle
Activités Activités Données ACTIVITES Données

DONNEES
Productrices Consommatrices d'entrée de sortie
Contrôle Contrôle
Unité de stockage Unité de traitement
Datagramme Actigramme
SADT
(Structured Analysis and Design Technique)
Chaque boite peut être dé

décomposé
composée en un diagramme plus dé
détaillé
taillé
Î Vérification de chaque étape de décomposition : Respect des
informations liées aux flèches
Remarque : Plusieurs modè

modèles SADT correspondant à diffé
différents
points de vue sur le systè
système sont ré
réalisé
alisés pour une meilleure
compré
compréhension
Î Vérification de la cohérence entre les différents modèles : par
vérification systématique de la cohérence entre données et traitements
au moyen de contrôles croisés d’actigrammes et de datagrammes.

L'analyse structurée SA
(Structured Analysis )
méthode descendante par raffinages successifs des traitements et
des processus.
A chaque niveau de décomposition, utilisation de la notation des

DFD :
Niveau le plus haut : ensemble du problème : diagramme de contexte
Niveaux inférieurs : décomposition en plusieurs processus des
processus des niveaux juste supérieurs, en respectant les flots de
données entrant et sortant.
Niveau de granularité maximale :

processus non décomposés : une mini spécification leur est attachée,
sous une forme plus ou moins formelle, afin de préciser comment les
sorties sont obtenues à partir des entrées.
Un dictionnaire des données précise également la définition des

données, des processus et des fichiers (ou zones de stockage).
L'analyse structurée SA
(Structured Analysis )
1 2
3 4
1.1 1.2 2.2

2.1
1.3
3.1 3.2 4.3

3.3 3.4 4.1 4.2

Méthodes d’analyse conception
orientées objet
Méthodes d'Analyse et de conception

orientées objet
La conception propose une solution au problème spécifié lors de

l’analyse :
architecture de l’application (architecture logicielle et architecture
physique),
description détaillée des modules, des interfaces utilisateurs, des
données.
L'objet outil de modélisation :

Une méthode d'analyse et de conception par objets apporte en plus une
démarche pour faire émerger un modèle de données et une analyse de
leur comportement.
Idée : objet = unité principale de décomposition de systèmes
Point de départ : Travaux de G. Booch sur la conception de logiciels
avec ADA

orientées objet - Concepts
Classe :
Décrit une collection d'objets ayant même structure et même comportement.
La structure (ensemble des données) est constituée des attributs
Le comportement est décrit par des méthodes
Les instances de la classe sont les objets
Possède une interface (publique, protégée, privée)
Objet :
Instance d’une entité particulière
A une identité unique
Possède un état : valeurs particulières de ses attributs
Communique avec les autres objets par envoi de messages, activation de
méthodes
Seules les méthodes de l'objet sont habilitées à modifier ses valeurs d'attributs
La réalisation de l'action associée à un envoi de message dépend de l'objet récepteur
qui gère ses propres attributs avec ses propres méthodes

Héritage :
Relation d'inclusion conceptuelle entre classes : les sous-classes
héritent de la structure et du comportement de leurs super-classes.
Enrichissement, spécialisation, fusion font partie du concept d'héritage.
Associations et liens :
Représentation au niveau des classes des liens qui unissent les objets
(association, agrégation, composition)

Trois aspects :
Dimension Fonctionnelle :
fonctions réalisées par les objets par
l'intermédiaire des méthodes
Dimension Structurelle :
propriétés des objets et liens
Dimension Temporelle
Comportement des objets :
description des changements d'états
(valeurs, événements)

orientées objet
Quelques mé
méthodes :
OOA -OOD (Coad et Yourdon)
OODa, OOADa (Booch)
OOSA (Shlaer et Mellor)
OOSE (Jacobson)
OOM (Rochfeld)
OMT (Rumbaugh)
HOOD (ESA)
RAD(Rationnal)
RUP (Rationnal)

OMT (Object Modeling Technique)
Description
Couvre les phases d'analyse et de conception en utilisant le même
formalisme
Trois points de vue analytiques (statique, dynamique, fonctionnel)
Trois modèles : objet, dynamique, fonctionnel.
Avantages de OMT:
modèle statique très riche
nombreux domaines d'applications
Unifiée avec la méthode OODa Î UML
OMT - Le modèle objet
Description graphique de la structure :

diagramme des classes
Processus de construction du modè

modèle objet :
Identifier les classes d'objets
Faire un dictionnaire des données
Identifier et ajouter les associations entre les classes
Identifier et ajouter les attributs aux classes et aux associations
Organiser et simplifier les classes grâce à l'héritage
Tester les chemins d'accès en utilisant des scénarii
Grouper les classes en modules

OMT - Le modèle objet
ENTREPRISE
PERSONNE travaille-pour nom
salarié
nom adresse
INSEE employeur
adresse
déménager salaire SERVICES
………
fonction
OMT - Le modèle dynamique
Décrit les aspects temporels et le séquencement des opé

opérations :
événements, scénarii, états, organisation des événements et des états
Formalisme graphique de repré

représentation :
Diagrammes états-transitions
Processus de construction :
Préparer les scénarii de séquences d'événements typiques
Identifier les événements entre objets et préparer pour chaque scénario
une trace des événements
Préparer un diagramme de flots d'événements pour le système
Développer un diagramme d'états pour chaque classe
Vérifier la complétude et la cohérence des événements communs à
plusieurs diagrammes d'états

OMT - Le modèle fonctionnel
Décrit les aspects lié

liés à la transformation des valeurs des objets
Fonctions, contraintes, dépendances fonctionnelles
Formalisme de repré
représentation :
Diagrammes de flots de données
Processus de construction :
Identifier les valeurs d'entrée-sortie
Utiliser des DFD pour montrer les dépendances fonctionnelles
Décrire ce que fait chaque fonction
Identifier les contraintes
Spécifier les critères d'optimisation
La méthode MERISE
Version 1 :
Approche systémique (liens système d'information - système opérant,
SI - système de pilotage)
Couverture de tout le cycle de vie du logiciel (schéma directeur, études

préalable, étude détaillée, étude technique, production de logiciels, mise
en œuvre, maintenance)
Cycle d'abstraction sur trois niveaux (conceptuel, organisationnel,

physique)
Séparation modèles de données et modèles de traitements

Merise : Les modèles
Merise - Niveau conceptuel
Modèle conceptuel des données (ou MCD),

schéma représentant la structure du système d'information, du point de
vue des données
les dépendances ou relations entre les différentes données du système
d'information
par exemple : le client, la commande, la ligne de commande, etc.,
Modèle conceptuel des traitements (ou MCT),

schéma représentant les traitements, en réponse aux événements à
traiter
par exemple : la prise en compte de la commande d'un client

Merise - Niveau logique ou organisationnel
Modèle Logique des Données (MLD),

reprend le contenu du MCD précédent,
mais précise la volumétrie, la structure et l'organisation des données
telles qu'elles pourront être implémentées.
Par exemple, à ce stade, il est possible de connaître la liste exhaustive
des tables qui seront à créer dans une base de données relationnelle
Modèle Logique des Traitements (MLT ou MOT),

précise les acteurs et les moyens qui seront mis en œuvre. C'est ici que
les traitements sont découpés en procédures fonctionnelles.
décrit avec précision l’organisation à mettre en place pour réaliser une
ou, le cas échéant, plusieurs opérations figurant dans le MCT. Il répond
aux questions suivantes : qui ? quoi ? où ? quand ? À un MCT
correspondent donc généralement plusieurs MOT.
Merise - Niveau physique
Modèle Physique des Données (MPD)

permet de préciser les systèmes de stockage employés
(implémentation du MLD dans le SGBD retenu)
le Modèle Physique des Traitements (MPT)

permet de spécifier les fonctions telles qu'elles seront ensuite réalisées
par le programmeur.

Merise
Version 2 :
Enrichissement des traitements au niveau conceptuel par l'introduction :
de diagrammes de flots de données
d'un Modèle Conceptuel des Traitements Analytiques (considération des
données qui s'y rattachent dés la conception Î préparation de la validation)
de la notion de Cycle de Vie d'un Objet
Enrichissement au niveau logique par

la prise en compte des structures , des moyens matériels et humains à
mettre en place
la définition des interfaces avec les utilisateurs
les ressources logiques de traitements et de stockage, la répartition des
données
Orientation Objet dans Merise
Version 3 :
Trois dimensions : statique, dynamique, fonctionnelle
Processus :
Développement de la dimension fonctionnelle : permet de représenter les
frontières du système à modéliser par rapport à son environnement.
Utilisation d'un diagramme de contexte.
Définition des besoins par des DFD
Importance de la dimension statique, la plus stable dans le temps
Repose sur un modèle E/A étendu
Association à chaque objet de son comportement, par l'intermédiaire des
méthodes apparues dans le DFD
Représentation de l'enchaînement des opérations dans différents scénarii, les
opérations pouvant rassembler les services de plusieurs objets : modèles de
traitements classiques de MERISE + objets sur lesquels portent les traitements

Méthode Macao
(IUT Blagnac)
Démarche participative par prototypage incrémental (spirale)

MACAO utilise la notation UML
structure du logiciel en termes de classes et de composants,
dynamique à l'aide de diagrammes d'interactions ou d'états/transitions
A partir des Cas d'Utilisation obtenus par interviews des utilisateurs,

deux types de modèles originaux sont utilisés pour représenter l'IHM
du logiciel :
un modèle conceptuel construit à partir du diagramme des classes et de patrons
de conception
un modèle de réalisation permettant une mise en œuvre optimum en langage
JAVA sous Windows ou LINUX, ou en HTML pour les applications Intranet.
Afin de limiter les tests de non régression toujours très lourds et

coûteux, MACAO applique à chaque prototype réalisé le principe de
non régression basé sur l'encapsulation et l'héritage
Méthodes d'analyse/conception
- Synthèse -
Tentative de standardisation des mé

méthodes :
Applicables quel que soit le secteur d’activité
Harmonisation des méthodes existantes
Terminologie unique
Normalisation
Définition d’un métamodèle : le modèle structurel
Nécessité
cessité d’introduire des techniques formelles et des outils pour
spé
spécifier et prouver les ré
résultats de l’l’analyse et couvrir tout le
cycle de vie.

UML
Unified Modelling Language
Description
Il est né en début de 1997 dans l'optique d'unifier les méthodes
d'analyse et de conception des systèmes.
Consensus autour des méthodes existantes (OMT, OOSE, OOA/OOD)
se définit comme le langage, standard, universel de modélisation

graphique et textuelle.
Notation couvrant toutes les phases du cycle de vie logiciel
Issu de la recherche de l’OMG
L'OMG adopte en novembre 1997 UML 1.1 comme langage de

modélisation des systèmes d'information à objets.
La version d'UML actuelle est UML 2.3 (mai 2010)
UML
Diagrammes UML utilisables tout au long du projet

analyse → conception → implantation
la structuration les
des objets composants
Vue logique Vue logiciels
statique implantation
Diagrammes
classes, objets, Diagrammes
collaborations, composants
séquences
les fonctions Vue externe
du systè
système cas
d’utilisation
Vue logique Vue
dynamique déploiement
la dynamique l’architecture
des objets Diagrammes Diagrammes physique
états, activités déploiement

UML 2.3 (Mai 2010)
Diagramme UML2
Diagramme structurel Diagramme comportemental
Diagramme de Diagramme Diagramme

Diagramme Diagramme de Diagramme cas d'utilisation d'activités d'états
de classes composants d'objets
Diagramme
Diagramme Diagramme de Diagramme de d'interaction
de packages déploiement structure composite
Diagramme de Diagramme de Diagramme Diagramme de

séquence communication de temps vue d'ensemble
des interactions
UML – Cas d’Utilisation
Permet d'identifier les fonctionnalités que doit fournir le système

Identifier les acteurs interagissant avec le système
Exemple :
Gérer les voitures
enregistrer
Client
ChefAgence
<<include>>
effectuer maintenance
M aintenicien
ResponsableAtelier
effectuer le test
proceder à l'expertise
Electricien M ecanicien <<extend>> réparer <<extend>>

UML – Diagramme de classes
représentant la Structure statique d'un modèle, à savoir les éléments

classes et types, et leurs relations les uns par rapport aux autres.
UML- Diagramme de Séquences
Exemple qui modélise l'envoi, par un enseignant, des notes d'une

classe d'étudiants à l'administration et le traitement effectué sur ces
notes.

UML – Diagramme états/transitions
montre les différents états d’un objet ainsi que les transitions entre ces
états
UML - diagramme de composants
Exemple :

UML
Synthè
Synthèse
La version d'UML actuelle est UML 2.3 (mai 2010)
Les travaux d'amélioration d’UML se poursuivent !
Plan
Spécification
2- Techniques d’
Vérification

Test de Logiciel
Définition
Recherche d'inadéquation d'un logiciel par rapport à des références
établies : spécifications du logiciel, normes ou règles portant sur son
code ou les documents le concernant
Classification des mé
méthodes
Tests statiques ( traitent le texte du logiciel : spécifications ou
programmes)
Tests dynamiques (exécution effective du logiciel sur un sous-ensemble
du domaine de ses entrées possibles)
Approches de Vérification
Vérification dynamique :
expérimenter le comportement de l’application (la tester) avec un
ensemble bien choisi de données;
Les tests ont pour but de mettre en évidence les erreurs.
Les tests peuvent prouver la présence d’erreurs mais ne peuvent pas
prouver leur absence
Vérification statique :
analyser les propriétés du système, sans exécution ;
Les techniques informelles
Les techniques formelles

Test ou vérification dynamique
Les test unitaires de programmes ou de modules

test d’un programme isolé
effectué par simulation des comportement des modules appelés
et par simulation les appels du module
Les tests d’intégration

Après avoir testé unitairement les modules il faut tester leur intégration
progressive jusqu’à obtenir le système complet
Les test de réception

effectué par le client, avec la participation du fournisseur, pour vérifier
que les dispositions contractuelles sont bien respectées
Les tests de non régression

effectué à la suite de la modification d'un logiciel
Il a pour but de montrer que les autres parties du logiciel n'ont pas été
affectées par cette modification
Vérifications statiques
Lectures croisées et inspection :

vérification d'un document par des relecteurs différents des auteurs,
puis vérification par des groupes de relecteurs ayant des rôles différents
sur le projet (chef de projet, auteur du document, responsables de
tests,…)
Analyse d'anomalies :
Établissement d'un critère d'acceptabilité des programmes testés
Construction d'un graphe (graphe de contrôle, flot de données, graphe de
dépendances, réseau de Pétri, graphe de transitions,…) représentant un
sous-ensemble des informations pour vérifier les critères choisis
Étude des chemins du graphe avec un prédicat portant sur la satisfaction
des critères établis

Les techniques informelles

Il s’agit d’activités réalisées par un groupe d’inspecteurs qui examinent
un document à la recherche d’erreurs
parmi les erreurs classiques en programmation on peut citer :

l’utilisation de variables non initialisées,
les affectations incompatibles,
les boucles infinies,
les débordements de tableaux,
les allocations et libérations impropres de zones mémoire,
etc.
Les techniques formelles

prouver formellement la correction d’un programme
Le programme est caractérisé par sa précondition (condition éventuelle à
respecter par les données du programme) et sa postcondition (condition
vraie à la fin du programme qui définit donc son objectif)
Technique basée sur les assertions logiques
Évaluation symbolique
Simulation de l'exécution du programme sur des données symboliques
Î expressions symboliques correspondant au texte des programmes
Utilisation de graphe de contrôle
Parcours du graphe à partir de données en entrée, jusqu'aux données de
sortie : production d'une expression symbolique retraçant les calculs
effectués et les conditions associées

Le génie logiciel
Partie III
Génie Logiciel Avancé
122
Plan
1- Évolution des technologies d’

d’analyse conception
OCL Object Constraint Language
Patrons (patterns)
Technologie des composants
L’architecture MVC
Programmation par Aspect (Aspect Oriented Programming)
OMG-MDA Model Driven Architecture
2- Évolution des processus de dé

développement
Processus Unifié
Méthodes agiles

Les limites de la programmation par objets
Absence de vision globale de l'application

les principaux concepts sont définis au niveau d'un objet individuel
pas de notion de description globale de l'architecture
Difficulté
Difficulté d'é
d'évolution
conséquence de l'absence de vision globale
Absence de services
les services nécessaires doivent être réalisés ''à la main'' (persistance,
sécurité, etc.)
Conclusion
charge importante pour le programmeur
incidence sur la qualité de l'application
une partie du cycle de vie n'est pas couverte
Construction des systèmes complexes
Les nouvelles Exigences :

Besoins fonctionnels en constante augmentation
Besoins techniques complexes et évolutifs
Multiples acteurs, …
Conséquence :
des composants complexes et hétérogènes …
Symptômes :
Dispersion : une fonctionnalité est distribuée dans tout le système, et
non pas placée dans une unité bien identifiée
Couplage des fonctionnalités : le cas où une unité contient des
éléments provenant de différentes préoccupations
Réutilisation
! Évolution
Traçabilité

Évolution des technologies en Génie Logiciel
Abandon de la Technologie Objets pour la Technologie Modèles (J. Bézivin)
1980 1995 2000

Technologie des Technologie Technologie des Technologie des
Procédures à Objets Composants Modèles
Modèles, Méta-
Procédures, Objets, Packages, modèles,
Pascal, Classes, Frameworks, UML, MOF,
C, Smalltalk, C++, Patterns, XML, XMI,,…
... ... …
Raffinement Composition Transformation

Procédural Des Objets De Modèles
Qualité du logiciel :
Evolution des technologies
Parlons les mêmes langages et partageons les mêmes technologies !
Æ Les standard de l’OMG : UML, XMI, CWM, CORBA, IDL, …
Expression de contraintes sur les modè

modèles UML
Æ OMG-OCL
Adaptabilité
Adaptabilité, extension d’
d’UML
Æ Profils UML
Interopé
Interopérabilité
rabilité
Æ Méta-modélisation
Æ OMG-MDA
Réutilisation des solutions

Æ Composants, Patrons de conception
Séparation des pré

préoccupations
Æ Aspect, pt vue

Object Constraint Language
OCL
OMG - OCL
(Object Constraint Language)
Pour spécifier complètement une application :
Diagrammes UML seuls sont généralement insuffisants
Nécessité de rajouter des contraintes
Comment exprimer ces contraintes ?

Langue naturelle mais manque de précision Æ compréhension pouvant
être ambigüe
Langage formel avec sémantique précise : par exemple OCL
OCL : Object Constraint Language

OCL est un langage formel pour l’expression de contraintes,
standardisé par l’OMG.

OCL (Object Constraint Language)
Description
Langage de contraintes orienté-objet

S'applique sur les diagrammes UML
OCL se veut un langage formel permettant de décrire ces contraintes
de façon déterministe.
Il se veut simple à écrire ainsi qu’à comprendre.
Langage formel (mais simple à utiliser) avec une syntaxe,
une grammaire, une sémantique (manipulable par un outil)
OCL est purement un langage interrogatif : en aucun cas il ne peut
modifier le modèle auquel il se rapporte.
On parle de langage sans effet de bord, ou side-effect free.
Utilisation d’OCL
OCL permet principalement d'exprimer des contraintes sur l'état

d'un objet ou d'un ensemble d'objets :
Des invariants qui doivent être respectés en permanence
Des pré et post-conditions pour une opération :
Précondition : doit être vérifiée avant l'exécution
Postcondition : doit être vérifiée après l'exécution
Gardes sur transitions de diagrammes d'états ou de messages de
diagrammes de séquence/collaboration
Des ensembles d'objets destinataires pour un envoi de message
Des attributs dérivés
Des stéréotypes
...

OCL par des exemples (1/3)
Contexte
Une expression OCL est toujours définie dans un contexte
Ce contexte est une instance d'une classe
Mot-clé : context
Un invariant
exprime une contrainte sur un objet ou un groupe d'objets qui doit être respectée
en permanence
Mot-clé : inv:
Exemple :
Pour toutes les instances de la classe Company, le nombre des employés doit
toujours être supérieur à 50
context Company inv:
self.numberOfEmployees > 50

Pour spécifier une opération :

Précondition : état qui doit être respecté avant l'appel de l'opération
Postcondition : état qui doit être respecté après l'appel
Mots-clés : pre: et post:
Exemple : La somme à débiter doit être positive pour que l'appel de l'opération
soit valide :
context Compte::débiter(somme : int)
pre: somme > 0
post: solde = solde@pre – somme
Dans une contrainte OCL associée à un objet, on peut :

Accéder à l'état interne de cet objet (ses attributs)
Naviguer dans le diagramme : accéder de manière transitive à tous les
objets (et leur état) avec qui il est en relation
context Company
inv: self.manager.isUnemployed = false
inv: self.employee->notEmpty()
La réutilisation dans l’ingénierie logicielle

Patrons(patterns)

Réutilisation dans l’ingénierie logicielle
Définition :
Un composant réutilisable :
traite un problème récurrent de l’ingénierie des SI,
capitalise un fragment de produit ou de processus,
offre une solution conceptuelle et/ou logicielle testée, acceptée et adaptable.
La réutilisation ne doit plus être limitée aux produits logiciels
Une très grande variété de composants réutilisables.
Conséquences :
Nécessité de classifier, documenter, organiser, composer les composants…
Nécessité de démarches centrées réutilisation.
Consé
Conséquences sur les produits :
Plus rapides à développer,
Plus faciles à maintenir,
Certainement meilleurs,
Moins originaux.

Patrons (Design patterns)
Expression Spécifications
des besoins Informelles Patrons d’analyse
Modèles de domaine
Composants métiers conceptuels
Analyse (abstraction du Modèle

Descriptif & Normatif
monde réel) Informatisable
Patrons d’architecture
Patrons de conception
Conception ERP, Frameworks
Modèle
(solution technique) Effectif Informatisé
Patrons d’implantation
Composants métiers logiciels
Implantation (solution Bibliothèques de classes
Logiciel
opérationnelle)

Technologie des patrons
Patron
Introduction
La beauté est-elle subjective ou existe-t-il des critères permettant de
distinguer ce qui est beau de ce que ne l’ai pas ?
Par exemple, si une personne doit concevoir l’entrée d’une maison,

peut-elle savoir objectivement si son projet est bon ?
les individus d’une même culture sont généralement d’accord sur ce qui
peut être considéré comme une bonne conception.
Ces raisonnements peuvent être appliqués à la qualité d’un logiciel ?
en quoi une conception est-elle bonne au mauvaise? Quels aspects les

différentient ?
les bonnes constructions qui ré

résolvent le même problè
problème ont des
points communs (qualifié
(qualifiés de patrons).

Patron
Définition:
« une solution apportée à un problème dans un contexte donné »
« chaque patron décrit un problème récurrent dans notre
environnement, puis le cœur de la solution qui sera réutilisable
indéfiniment, quelle que soit la mise en pratique choisie »
Exemple: Cré
Création textile
Difficile !!!! Solutions prédéfinies Projet réussi
Intérêt des patrons
Réutiliser les solutions :

En utilisant des solutions prédéfinies, on évite les pièges de début de
projet et on bénéficie de l’expérience d’autre concepteurs. On n’a pas à
réinventer des solutions à des problèmes récurrents.
Amé
Améliorer la communication et l’l’apprentissage :
Les patrons impliquent l’adoption d’une approche commune au sein
d’une équipe de développeurs. Ils constituent une même référence pour
tous lors des phases d’analyse et de conception d’un projet, ce qui
simplifie bien évidement la communication.
Souplesse du logiciel :
La plupart des design patterns facilitent la modification ultérieur du
logiciel.
Ils apportent donc des solutions plus facilement modifiables que

celles auxquelles vous pouvez penser en dé début de projet.

Systèmes de patrons
processus Ambler
générique
Coad GoF
Coad GoF
domaine SIP
entreprise
e n
lys on t io
ana c e pti lanta
con im p
[ LSR-IMAG ]
Systèmes de patrons
“Un patron processus fournit une collection de techniques, d’actions et/ou

de tâches à suivre pour le développement des logiciels”. Ambler 98
« Un langage de patrons est une collection structurée de patrons

construits l’un sur l’autre pour transformer les besoins et les contraintes
dans une architecture ».
C. Alexander / J. Coplien
Un patron constitue une base de savoir et de savoir-faire pour résoudre un

problème récurrent dans un domaine
Un système de patrons est une collection de patrons coordonnés intégrant

une démarche de conception pour résoudre un problème complexe

Patrons de Conception de GOF :
GOF: Gang of Four = la bande des quatre

Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
Creational Structural Behavioral

• Factory Method • Adapter • Interperter
Class
• Abstract • Adapter • Chain of Responsibility
Factory • Bridge • Command
• Builder • Composite • Iterator
Scope • Prototype • Decorator • Mediator
Object • Singleton • Facade • Momento
• Flyweight • Observer
• Proxy • State
• Strategy
• Vistor
Exemple 1 : Patron Composite
Exercice

Exemple 1 : Patron Composite
Structure du patron Composite
Exemple 2 : Patron Observateur (E. Gamma)
Objectif
Permettre à un objet de prévenir un ensemble d'autres objets inconnus
au moment de sa conception de certains changements de son état
Problème
Certains changements d'état d'un objet O sont susceptibles d'en
intéresser d'autres
Ces autres objets sont inconnus lors de la conception de O
Solution
Faire gérer à O une liste d'observateurs (ou écouteurs) et les prévenir
lors des changements d'états intéressants

Exemple 2 : Patron Observateur
Patron de conception Observateur (E. Gamma)
3 observateurs
1 sujet
2003
50
Ouest = 33,5
Est
45
40
35 Oues t
30
Nord = 12,4 25
20
15 Nord
Est = 44,0
Sud
10
Sud=10,1
Oues t
Nord
Es t
Sud
Exemple 2 : Patron Observateur
Structure du patron Observateur

Structure d’un patron
Description d’
d’un patron
Problem
Problem
Nom
Intention
Motivation Context
Indication d’utilisation
Structure
Constituants Solution
Solution
Conséquences
Benefits Consequences
Implémentation
Related Patterns
Exemples de code
Modèles apparentés
Ingénierie des patrons
Spécifier les solutions
Problème déjà traité

Intégrer le patron associé
dans le catalogue
Identifier les problèmes
Définir de nouveaux
Construire un raffinement d'un patrons dérivant des
référentiel problème
patrons existants
Identifier les
problèmes
Analyser les
modèles existants Définir nouvelle
solution
Nouveau problème
Problème décomposable
Décomposer le problème
en sous-problèmes

Composants : description
classe avec ses connexions figées (les associations avec les autres
classes matérialisent des liens structurels), ne constitue pas une
réponse adaptée à la problématique de la réutilisation
Description
La réutilisation est l’aptitude d’un logiciel à être réutilisé, en tout ou en
partie, dans de nouvelles applications
Les composants permettent la construction d'applications par
composition de briques de base configurables
Un composant est un module logiciel autonome
unité de déploiement (installation sur différentes plates-formes)
unité de composition (combinaison avec d'autres composants)
Facilite la compréhension globale du système
outil de documentation
Facilite le processus d'évolution
modification des composants (interface, réalisation)
modification des relations entre composants
modification du déploiement

Composants : description
Proprié
Propriétés
spécifie explicitement la ou les interface(s) fournie(s)
spécifie explicitement la ou les interface(s) requise(s)
peut être configuré
La programmation par composants constitue une évolution technologique

soutenue par de nombreuses plateformes :
EJB (Enterprise JavaBeans)
CORBA (Common Object Request Broker Architecture)
WSDL (Web Services Description Language)
.Net,
,…
Ce type de programmation met l’l’accent sur la ré

réutilisation du composant et
l’indé
indépendance de son évolution vis-
vis-à-vis des applications qui l’l’utilisent.
Composants : modèle générique
Propriété configurables
(interfaces spéciales avec accès restreint)
Interfaces requises
Interfaces fournies Composant (fournies par d’autres
composants)
Contraintes techniques
• placement, sécurité
• transactionnel, persistance
• interfaces fournies par le système (bibliothèques, etc.)

Support logiciel pour composants
Pour assurer leurs fonctions, les composants ont besoin d'un support
support
logiciel
Conteneur
encapsulation d'un composant
prise en charge des services du système
nommage, sécurité, transactions, persistance, etc.
prise en charge partielle des relations entre composants (connecteurs)
invocations, événements
techniques utilisées : interposition, délégation
Structure d'accueil
espace d'exécution des conteneurs et composants
médiateur entre conteneurs et services du système
Mise en œuvre des composants
Composant
Conteneur
Composant
Client
Composant
Conteneur
Conteneur
Structure d’accueil Structure d’accueil
Bus logiciel + services (désignation, persistance, transaction, sécurité,etc.)

Composants : situation
Premiers produits, ne ré
répondent pas encore à tous les besoins
Java Beans, (Enterprise Java Beans)
COM (Component Object Model ) Æ DCOM (Distributed COM ) Æ .NET
Début de normalisation
Composants CORBA (OMG), normalisation en cours (CORBA 3)
Ce qui manque encore

Descriptions d'architectures
prototypes de recherche, produits encore attendus
Support pour déploiement, évolution, configuration
travaux en cours à l'OMG (OSD : Open Software Description)
Aide à la conception
travaux sur l'extension de l'UML
Exemple : CORBA
(Common Object Request Broker Architecture)
Standard de l’l’OMG

Expression Spécifications
des besoins Informelles
C
Analyse O
(abstraction du
Modèle M
monde réel) Descriptif & Normatif
Informatisable P
Conception
O
(solution technique) S
A
Modèle
Effectif Informatisé
Implantation N
(solution T
opérationnelle) Logiciel
S

- Synthèse -
Développement pour et par la ré

réutilisation
Pour la Réutilisation Par réutilisation
Concepteur de composants Ingénieur d’applications

d’applications
Ingénierie de
composants
Ingénierie
Application

But
Isoler la donnée elle-même de sa présentation
Distinguer la consultation de la modification
Principe
Pour une donnée, trois composantes distinguées et séparées
Le modèle (sa structure)
La vue (sa représentation pour affichage)
Le contrôleur (les moyens de modifier la valeur)

Structure
Utilisateur
présente le résultat utilise
Contrôleur
Vue
Choisi la vue appropriée
manipule,
met à jour,
envoi de requête
réponse
Modèle Métier
MVC - Le modèle
Rôle
Encapsuler les propriétés d'une donnée
Être indépendant des vues et contrôleurs
Conséquences
Définir les accesseurs aux propriétés de cette donnée
Maintenir une liste d'écouteurs (vues et contrôleurs se déclarent comme
écouteurs)
Prévenir les écouteurs lorsque la donnée est modifiée
Implantation du design pattern Observer

MVC - Le contrôleur
Rôle
Permettre à l'utilisateur de modifier la donnée encapsulée dans le
modèle
Conséquences
Doit éventuellement s'enregistrer comme écouteur du modèle pour être
mis à jour si le modèle est modifié
Doit appeler les accesseurs du modèle en fonction des actions de
l'utilisateur
MVC – la vue
Rôle
Représenter la donnée encapsulée via un modèle
Se maintenir à jour lorsque le modèle est modifié
Conséquences
Doit s'enregistrer comme écouteur au niveau du modèle

Exemple : Application du MVC au web
La multi-modélisation
Programmation par Aspect

(Aspect Oriented Programming)

La multi-modélisation
Séparation des préoccupations pour simplifier la modélisation

Æ Décomposition des exigences
Assemblage du système global

Æ Composition de modèles partiels
Approches basées sur la séparation des préoccupations :

Modélisation par aspect
Modélisation par points de vue
Modélisation par sujet
Etc.
Programmation par aspects
Motivations
le principal problème dans l’évolution et la réutilisation des logiciels est
un problème d’organisation des programmes
Dans toutes les approches de développement traditionnelles
(fonctionnelle ou objet) la structuration d’une application repose sur sa
décomposition en unités fonctionnelles.
Application basée sur l’orientée objet :

• Divers classes
Logger.log(‘SEVERE’, ‘appel 1’);
• Chacune des classes possède son propre
code
Ce n’est peut
•Du code non fonctionnel pas du
venir
‘polluer’ code métier!
polluer’ le code métier

Programmation par aspects
Principe de découpage
les services de base d’une application et ses propriétés
(fonctionnalités transversales), correspondent à des fonctions
indépendantes qui doivent être découplées
Un logiciel contient :
Des préoccupations métier
Des préoccupations de niveau système
AOP - Exemple
Exemple : paiement par carte de crédit

Préoccupations métier :
Effectuer des paiements : débiter un montant d'un compte défini
Préoccupations techniques :
Intégrité de la transaction
Identification / authentification
Sécurité (confidentialité)
Performances
etc

AOP
Dispersion du code
Copyright © aspectj.org
Le rouge montre les lignes de code qui traitent du logging

Très mal modularisé
AOP
Definition d’un aspect
Point de jonction (join point) : désigne un

endroit du programme où l’on souhaite
ajouter un aspect.
Coupe (pointcut) : désigne un ensemble de

point de jonction.
Code advice : bloc de code définissant le

comportement d’un aspect (i.e ce que
l’aspect greffe dans l’application).

AOP
Definition d’un aspect
Composants
C1 C2 C3 … Cn
A1
A2
Aspects
A3
….
An
Point de jonction
AspectJ
Extension Java permettant la programmation par Aspects

http://aspectJ.org
Principe de développment
Identifier le préoccupations métier (classes) et techniques (aspects)
Implémenter chaque préoccupation séparément
Tisser les différentes préoccupations
Code Métier
Code final
Compilateur
AspectJ
Définition
des aspects

Un aspect en Concret
package aop.aspectj;
aop.aspectj; coupe
public aspect tracer

{
pointcut tobetraced():
tobetraced(): call(public void Client.newClient(..))||
Client.newClient(..))|| call (public void Commande.newCde(..));
Commande.newCde(..));;;
before() : tobetraced()
tobetraced() Advice
{ de
System.out.println("Premier Aspect executer le 01/10/2010”
01/10/2010”); type
} before
}
OMG-MDA
Model Driven Architecture

OMG - MDA
l’OMG, consortium de plus 1000 entreprises, initie la démarche

MDA.
L’approche MDA
Description
Le MDA est l'outil qui permet à une industrie de décrire ses fonctions
indépendamment des implémentations
Penser l'application au niveau du modèle et laisser le soin de

l'implémentation aux outils
Interopérabilité au niveau des modèles : Il s'agit d'avoir la possibilité

d'écrire et de faire évoluer le modèle en fonction de l'organisation métier
de l’application et non plus par les plate-formes.
Au niveau de l'organisation : PIM (Plateform Independant Model)
Au niveau des plate-formes : PSM (Plateform Specific Model).
Une application complè

complète de MDA : un PIM et un ou plusieurs PSM
Langage de description du MDA : UML.
L'application sera ensuite implémentée sur un large éventail de
systèmes.

L’approche MDA
Les PSM peuvent communiquer entre eux en faisant intervenir plusieurs

plate-formes qui ont à échanger des données ( CORBA par exemple)
MDA est implémenté dans un outil qui intègre la modélisation et le
développement. Il gère des classes servant les objets métiers, leur
présentation et leur persistance.

avantages du MDA :
une architecture basée sur MDA est prête pour les évolutions
technologiques.
plus grande facilité d'intégration des applications et des systèmes
autour d'une architecture partagée.
une interopérabilité plus large permettant de ne pas être lié à une plate-
forme.
Les standards de l’OMG
Architecture à quatre niveaux.

Evolution des processus de développement
Les processus unifié
unifiés
UP
RUP
2TUP
L’agilité
agilité
XP
RAD
UP - le Processus Unifié
Description
UP (Unified Process) est une méthode générique de développement de
logiciel.
Générique signifie qu'il est nécessaire d'adapter UP au contexte du

projet, de l'équipe, du domaine et/ou de l'organisation (exemple:
R.UP : Rational Unified Process
X.UP : Extreme Unified Process

UP - le Processus Unifié
Cadre gé
général
Le processus unifié est un processus de développement logiciel : il
regroupe les activités à mener pour transformer les besoins d’un
utilisateur en système logiciel
Caracté
Caractéristiques essentielles du processus unifié
unifié :
A base de composants
Utilise le langage UML
Piloté par les cas d’utilisation
Centré sur l’architecture
Itératif et incrémental.
Le processus unifié : RUP
Rational Unified Process,

Process,
Instanciation par Rational Software (IBM) des préceptes UP

Le 2 TUP
Cadre gé
général
Two Track Unified Process
Caracté
unifié :
Itératif
S’articule autour de l’architecture
Propose un cycle de développement en Y
« Détaillé dans UML en action »
Pour des projets de toutes tailles
Le 2 TUP

Méthodes agiles
Définition
méthodes de développement informatique permettant de concevoir des
logiciels en impliquant au maximum le demandeur (client)
se veulent plus pragmatiques que les méthodes traditionnelles.
Le développement agile tire son nom du Manifeste Agile, document
rédigé en février 2001 et signé par 17 personnalités du domaine.
Douze principes ont été définis, dont :
Parvenir à la satisfaction du client par le biais d'un cycle de développement
rapide, récurrent et incrémental de versions fonctionnelles;
Se montrer apte à prendre en compte les changements de dernière minute
à tout moment du projet;
Mettre en place une coopération quotidienne entre développeurs et
décideurs/commerciaux
Faire simple, mais pas simpliste;
Laisser l'équipe s'organiser au mieux de ses possibilités.
Méthodes agiles
Exemples
Méthodes adaptées aux petites équipes
Crystal,
XP,
Scrum,
…
Méthodes prévues pour des groupes conséquents
RAD
ASD
…

XP (eXtreme Programming)
cadre gé
général
Méthode agile
Ensemble de « best practices » de développement (travail en équipes,
transfert de compétences, …)
Caracté
unifié :
Itératif
Pas de phase d’analyse
Plutôt pour des projets à effectif restreint (10 personnes max)
Valeurs :
Communication
Simplicité
Feedback
XP (eXtreme Programming)
Cycle de dé
développement

RAD (Rapid Application Development)
1 - Initialisation
Préparer l’organisation du
projet
2 - Cadrage
3 - Conception
Cerner et stabiliser les
objectifs Conception globale
et modélisation
4 - Construction 5 - Finalisation
Modélisation détaillée, Intégration, déploiement et
prototypage et test maintenance
Initialisation
Cette phase permet de définir le périmètre général du projet :
structurer le travail par thèmes
sélectionner les acteurs pertinents
amorcer une dynamique de projet
Cadrage
Phase d’analyse et expression des exigences
Exprime les besoins des utilisateurs lors d’entretiens de groupe
Conception
Les utilisateurs sont également impliqués dans cette étape.
Ils participent à l’affinage et à la validation des modèles organisationnels :
flux
traitements
données
Ils valident également le premier niveau de prototype présentant l’ergonomie et
la cinématique générale de l’application

Construction
Phase de prototypage et réalisation,
Durant cette phase, l’équipe RAD doit construire l’application module
par module.
L’utilisateur participe toujours activement aux spécifications détaillées et
à la validation des prototypes.
Plusieurs sessions itératives sont nécessaires.
Finalisation
Phase de recette et déploiement
Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit
dans cette phase d’officialiser une livraison globale et de transférer le
système en exploitation et maintenance
RAD – Répartition des charges
50 %
23%
12 %
9%
6%
n ge n n n
ti o ra ti o io t io
lis
a
ad ep ct sa
a C nc ru l i
it i st na
In co on Fi
C

Conclusion Générale
Le génie logiciel a apporté un cadre formel au développement logiciel
Toutes les activités identifiées sont supportés par des techniques, des
méthodes, des outils.
Encore des efforts à faire au niveau :
Réutilisation
Traçabilité (remonter jusqu’à l’origine d’un problème)
Interopérabilité
Evolution
La phase de capture des exigences (analyse des besoins) n’est pas assez
valorisée dans les processus : elle devient une discipline à part entière.
Conclusion Générale
Dernier conseil : s’ouvrir !
Parce que les technologies et les méthodes avancent en vitesse,

il faut :
Se tenir au courant,
Être curieux
Lire …

Cours GL-L3NTIE Lakhrissi

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours GL-L3NTIE Lakhrissi

Uploaded by

Copyright:

Available Formats

Le Génie Logiciel

Notions de base & Principes

2 - Cycle de vie de logiciel

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 3

Le logiciel n’est pas seulement un ensemble de programmes, mais

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 4

Les différentes catégories de logiciel (1/3)

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 5

 Logiciel de traitement de donné

 Quelques fois les 2 aspects sont pré

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 6

Les différentes catégories de logiciel (3/3)

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 7

 Le logiciel est facile à reproduire

 Le logiciel est intangible

 qualifiés peuvent arriver à bricoler

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 8

La nature du logiciel (2/3)

 Un logiciel semble facile à modifier

 Beaucoup de logiciels sont mal conç

 La demande pour du logiciel est toujours croissante

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 9

 Raisons pour lesquelles le logiciel vieillit :

 Un logiciel est fiable s’

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 10

 Art de produire du logiciel

 Art de bien faire de bons Logiciel

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 11

 Les points communs des dé

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 12 12

Le génie logiciel - Origine

 Origine : Apparu en 1968, devant les insatisfactions gé

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 13

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 14

 Étude du gouvernement amé

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 15

 Validité : Conformité d'un logiciel avec sa spécification

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 16

Cycle de vie du logiciel ?

Le développement d’un grand système logiciel prend un temps

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 17

Il faudra en permanence assurer la vérification et la validation

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 18

Cycle de vie du logiciel

 Phases du cycle de vie

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 19

 But : Première description du futur système

 Définition des objectifs

 Définition des besoins

Produits issus de cette phase : Le cahier des charges

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 20

Le cahier des charges

 Les besoins relevés dans le CDC doivent être :

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 21

Le rédacteur du CDC doit avoir les qualités suivantes :

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 22

Phase d’analyse des besoins

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 23

 Le DA contient la description du produit vu de l’l’exté

Questions ouvertes et réponses apportées par les développeurs

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 24

Phase de planification et gestion de projet

 Produits issus de cette phase :

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 25

Logiciel de traitement de donné

Quelques fois les 2 aspects sont pré

Le logiciel est facile à reproduire

Le logiciel est intangible

qualifiés peuvent arriver à bricoler

Un logiciel semble facile à modifier

Beaucoup de logiciels sont mal conç

La demande pour du logiciel est toujours croissante

Raisons pour lesquelles le logiciel vieillit :

Un logiciel est fiable s’

Art de produire du logiciel

Art de bien faire de bons Logiciel

Les points communs des dé

Origine : Apparu en 1968, devant les insatisfactions gé

Étude du gouvernement amé

Validité : Conformité d'un logiciel avec sa spécification

Phases du cycle de vie

But : Première description du futur système

Définition des objectifs

Définition des besoins

Les besoins relevés dans le CDC doivent être :

Le DA contient la description du produit vu de l’l’exté

Produits issus de cette phase :

Chaque module est codé individuellement

Chaque module est testé indépendamment des autres

Intégration : Assemblage de composants pour obtenir un système exécutable

Le rôle des modè

Un processus en 2 chemins ou modè

La branche fonctionnelle correspond à la tâche traditionnelle de

L'ajout d'une branche technique indé

La branche technique ; exemples de choix :

Repose sur le principe de la ré

Le logiciel est ensuite dé

On distingue 3 types de spé

Souvent graphiques, dont la sémantique est plus ou moins précise

Concepts mis en œuvre :