Cours Génie Logiciel et UML
Génie Logiciel - UML
Organisation du cours
- 13 séances de 3 heures
- chaque séance : cours + TDs
Contrôle des connaissances :
- 1 examen de 3 heures (dernier séance)
- pas de contrôle continu
- 1 projet au second semestre
Ressources intéressantes
Livres en français
- UML Modéliser un site e-commerce P. Roques, Eyrolles
- Le guide de l’utilisateur UML
G. Booch, J. Rumbaugh, I. Jacobson, Eyrolles
- Modélisation objet avec UML P. A. Muller, Eyrolles
- Précis de génie logiciel
M.-C. Gaudel, B. Marre, F. Schlienger, G. Bernot, Masson
Sites Web
…
Objectif de l’enseignement
- Analyse et conception de système informatique
- Phase amont de l’activité de programmation
- Utilisation de la notation UML
Assimiler l’importance des activités de spécification, d’analyse et de conception par rapport à l’activité de programmation
Pourquoi un cours GL ?
Vos compétences : « programming-in-the-small »
- Programmation individuellesur de petitsproblèmes
- Algo, langages de programmation, structures de données
- (parfois) un peu de méthodologie : analyse descendante
En entreprise : « programming-in-the-large »
- Travail en équipe sur des projets longs et complexes
- Spécifications de départ peu précises
- Dialogue avec le client/utilisateur : parler métier et non informatique
- Organisation, planification, gestion du risque
Démarche ingénierique : génie logiciel
5
Planning du cours
- Séance 1 - Introduction au GL, approche OO et UML-RUP
- Séance 2 - Cas d’utilisation : cours + TD
- Séance 3 - Diagramme de séquence : cours + TD
- Séance 4 - Diagramme d’interaction : cours + TD
- Séance 5 - Diagramme de classe : cours + TD
- Séance 6 - Diagramme d’états-transitions : cours +TD Séance 7 - Diagramme de composant et de déploiement : cours + TD
- Séance 8 - ??
- Séance 9 - RUP + cas d’étude 1 (1/2) : cours + TD
- Séance 10 cas d’étude 1 (2/2) : TD d’ici fin 2003
- Séance 11 cas d’étude 2 (2/2) : TD
- Séance 12 - cas d’étude 2 (2/2) : TD février 2004
- Séance 13 - Examen
Introduction au Génie Logiciel
Le Génie Logiciel
Le terme Génie Logicielest né entre le 7 et le 11 octobre 1968 à Garmish-Partenkirchen sous le nom de software engineeringsous le parrainage de l’OTAN
Défini par un groupe de scientifiques pour répondre à un problème bien défini s’énonçant en 2 constatations :
- le logiciel n’était pas fiable
- il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges
Le Génie Logiciel
Une définition
Spécifier, concevoir, construire, maintenir de grands systèmes logiciels
Méthodologie de construction en équiped’un logiciel complexe et à multiples versions.
Programmation vs Génie Logiciel(approximation)
- Programmation : activité personnelle
- Génie Logiciel : activité d’équipe
Suivant les projets, la partie programmation (codage) ne représentera qu’entre 10% et 30% du coût total.
Logiciel : aspects économiques
Importance économique du logiciel
- importance croissante de l’informatique dans l’économie (1985 : 150 Mrd$ - 1995 : 450 Mrd$)
- coût du logiciel supérieur à celui du matériel
L’économie de toute nation industrialisée est dépendante du logiciel. La dépense en logiciel représente une partie significative de son PNB
coût maintenance supérieur au coût de conception améliorer la qualité du logiciel !
Erreurs célèbres et projets douloureux (qui justifient l’utilisation de GL)
- 1971 : lors d’une expérience météorologique en France, 72 ballons sondes détruits à cause d’un défaut logiciel
- La sonde Mariner vers Vénus perdue dans l’espace à cause d’une erreur dans un programme (virgule remplacée par un point)
- 1981, le premier lancement orbital de la navette spatiale retardé de 2 jours à cause d’un problème logiciel. Elle fut lancée sans que l’on ait exactement localisé la cause du problème
- du 15 au 16 décembre 1990, les abonnés de ATT sur la côte est des Etats-Unis furent privés de tout appel longue distance à cause d’une réaction en chaîne dans le logiciel du réseau due à un changement de version du logiciel.
Erreurs célèbres et projets douloureux
- Avion F16 retourné au passage de l’équateur : non prise en compte du référentiel hémisphère Sud
- OS-360 d’IBM (années 1960) a été livré en retard, a nécessité plus de mémoire que prévu, son prix de revient dépassant de beaucoup les estimations, et ses premières versions comportant des erreurs.
- Compilateur PL1 chez Control Data jamais abouti (années 1970)
- abandon du projet d’informatisation de la bourse de Londres : 4 années de travail et 100 M£ perdus
- Abandon du système de trafic aérien américain
- Retard (1 an) du système de livraison des bagages de l’aéroport de Denver
- Bogue de l’an 2000, instabilité de Windows 95 …
Enjeux du logiciel
- Nécessité de méthodes, de processus pour le développement des logiciels coûteux et complexes
- Primordial pour les systèmes critiques : nucléaire, transport, systèmes bancaires
Complexité croissante du logiciel
- système offrant de plus en plus de fonctionnalités
- systèmes distribués: machines hétérogènes en réseau
- mutations technologiques rapides : langages et environnements de développement, O.S., matériel.
- évolution des besoins du clienten cours de projet
Qualité du logiciel
Privilégier la qualité à l’efficacité
- la prévention des erreurs coûte des dizaines de fois moins cher que leur correction
- démarche qualité : ISO 9126 ()
- gérer la complexité des logiciels tout au long de leur cycle de vie
- séparer les aspects fonctionnels et technologiques
- décomposition en sous-systèmes
- démarche itérativeapproche objet
Qualité externe vs. Qualité interne
- externe : vision client
- interne : vision du développeur
Génie logiciel : En résumé
Le GL doit fournir des méthodes de conception de systèmes complexes permettant :
- une prise en compte du client
- une démarche qualité
- une organisation du travail en équipe
- une meilleure évolution et maintenance du logiciel un respect des coûts et délais estimés initialement
Le GL, ce sont aussi des outils associés :
- ateliers de génie logiciel
- méthodes de développement
Exemple : Rational Rose (UML)
Facteurs de qualité du logiciel
Qualité externe
- complétude fonctionnelle: réalise les tâches attendues
- maniabilité : facilité d’utilisation
-
- Interface utilisateur appropriée Documentation complète et précise fiabilité :
- fonctionne même dans des cas atypiques
- il ne doit pas causer de dommages physiques ou économiques en cas de défaillance
-
adaptabilité: adaptation aux modifications
- Qualité interne
- réutilisation : il doit être possible de faire évoluer le logiciel pour répondre à de nouveaux besoin
- traçabilité : suivi précis de l’analyse à l’implantation
- efficience : bonne utilisation des ressources matérielles
- portabilité : adaptation à de nouveaux environnements
Modèles / Processus
Une définition
Procédé de production établi comme une suite de descriptionsde plus en plus précises et de plus en plus proches d’un programme exécutable et de sa documentation
- Notion de raffinements successifs (passage d’une description àune autre)
-
Nature itérative, certaines étapes déclenchent la r évision du résultat des étapes précédentes
- Large place pour les phases d’analyse, de conception et de validation
- But : obtenir un processus rationnel, reproductibleet contrôlable
Caractéristiques d’un processus
- Compréhensible :clairement défini et compréhensible
- Observable :l’évolution du produit est visible de l'extérieur
- Accepté par les acteurs du projet
- Sûre :les erreur sont détectées avant la mise en service du produit
- Robuste :les problèmes non prévus ne stoppent pas la réalisation du produit
- Maintenable :le processus évolue en fonction des besoins de changements d’organisation
- Efficace :le temps de réalisation du produit
Activités du processus de développement
si linéaire (nombreux aller-retours)
Défis des processus logiciels
- Généralement, les spécifications sont incomplètes et anormales
- La frontière entre spécification, conception et réalisation est floue
- Les tests ne sont pas réalisés dans l’environnement définitif du système
- Un logiciel ne connaît pas l’usure - maintenir ne veut pas dire remplacer un composant
Analyse des besoins
- But : éviter de développer un logiciel non adéquat
- Étude du domaine d’application, de l’environnement du futur système afin d’en déterminer le rôle, les frontières… Dialogue avec le client qui fournit les données du problème
- Pas de discussion techniques, on cerne les besoins : entretiens, questionnaires, étude de situation similaire…
- Résultat :
- documents décrivant les aspects pertinents de l’environnement du futur système, son rôle et sa future utilisation cahier des charges
- Partage logiciel/matériel déterminé suivant des facteurs qualités : robustesse, efficacité, portabilité…
NB : activité essentielle au début du processus, elle est couplée avec les études de faisabilité et la planification. Elle se poursuit durant tout le cycle de vie du logiciel (questions relatives aux besoins et à l’environnement peuvent émerger).
Spécifications
- But : établir une première description du futur système
- Document précis spécifiant les fonctionnalités attendues, rédigés formellement (spécifications algébriques,…) ou semi-formellement (UML,…)
- Résultat : une description de ce que doit faire le système (et pas comment) compréhensible par le client/utilisateur
- Fortement corrélée avec l’analyse des besoins et la validation
NB :
- Une première version du manuel de référence est parfois produite à cette étape Les spécifications ne sont jamais complètes et définitives (évolution du domaine, besoins supplémentaires)
Conception
- But : enrichir la description du logiciel de détails d’implantation afin d’aboutir à une description très proche d’un programme
- Conception architecturale :
- décomposer le logiciel en composants plus simples.
- Préciser les interfaces et fonctionnalités de chaque composant
- Résultat : description de l’architecture logicielle et spécifications de ses composants
- Conception détaillée :
- Pour chaque composant, on indique comment sont réalisées ses fonctionnalités : représentation des données, algorithmes Expertise informatique : hors compréhension du client
- Frontière floue entre spécifications et conception :
- La conception commence souvent pendant la spécification (contraintes de réalisation à anticiper)
- Elle peut remettre en cause la spécification (aller-retours)
Implantation
- Souvent trop de temps consacré au codageau détriment des phases d’analyse et de conception : mauvaise pratique parfois très coûteuse…
- Dans un projet bien conduit, l’effort se décompose environ comme suit :
- 40% pour la spécification et la conception
- 20% pour l’implantation
- 40% pour la validation et la vérification
- Activité la mieuxmaitrisée, «outillée », voire automatisée
- Savoir user de la réutilisabilitédes composants, voire d’outils de génération de code (mise en place automatique du squelette du code à partir du modèle système)
Correction la validation
- La validation répond à la question : a-t-on décrit le «bon » système ?
- Difficulté : l’imprécision des besoins et des caractéristiques du système à développer
- Elle consiste en des revues et inspectionsde spécifications ou de manuels et du prototypage rapide
- Maquettage ou prototypage rapide : développement rapide d’un programme qui est uneébauche du futur système
- Soumis à des scénarios d’utilisation, il permet de préciser les souhaits du client Maquette exploratoire
- Lors d’une étape de conception, plusieurs maquettes peuvent être comparés pour valider différents choix
Maquette expérimentale
Correction la vérification (1/2)
- Test statique : examen ou analyse du texte
- Test dynamique : exécution sur un sous-ensemble fini de données possibles
- Selon l’avancement du développement, on distingue plusieurs types de test :
- Le test unitaireconsiste à tester des composants isolément
- Le test d’intégration consiste à tester un ensemble de composants qui viennent d’être assemblés
- Le test systèmeconsiste à tester le système sur son futur site d’exploitation dans des conditions opérationnelles et au-delà (surcharge, défaillance matérielle,…)
- Testeur „ concepteur du programme
- Activités souvent sous-estimées
Correction la vérification (1/2)
- La vérification répond à la question : le développement est-il correct par rapport à la spécification initiale ?
- Elle inclut les activités de preuve et de test
- Une preuve porte sur une spécification détaillée ou un programme et permet de prouver qu’il ou elle satisfait bien la spécification de départ
- Le test recherche des erreurs dans une spécification ou un programme
Cycles de vie « classiques»
Basés sur la succession des différentes étapes processus de développement
- Cycles de vie linéaires
- Modèle en cascade
- Modèle en « V »
- Cycle de vie itératif
- Modèle en spirale (ou incrémental) : prototypes
Modèle en cascade
Principes
- Processus linéaire
- On convient d’un certain nombre d’étapes, se terminant à des dates précises par la production de documents ou logiciels
- Les résultats de l’étape sont examinés attentivement avant de passer à l’étape suivante
- Itération : Une étape ne remet en cause que l’étape précédente (validation, vérification)
Modèle en cascade : inconvénient
- Validation limitée à un pas d’itération
- - augmentation des risques : erreur d’analyse ou de conception très coûteuse si détectée trop tard !
- Difficile d’effectuer des modifications en cours de route
- Solution limitée aux petits projets
- - Bien adapté lorsque les besoins sont clairement identifiés et stables i.e. les risques sont bien délimités dès le début du projet - projet court avec peu de participants
Souvent abandonné au profit du modèle en « V », plus récent, qui présente une articulation plus réaliste entre l’activité de réalisation et celle de validation-vérification
Modèle en « V » : limitations
- Un modèle toujours séquentiel…
- Prédominance de la documentation sur l’intégration : validation tardive du système par lui-même
- Les validations intermédiaires n’empêchent pas la transmission des insuffisances des étapes précédentes
- Manque d’adaptibilité
- Maintenance non intégrée : syndrome du logiciel jetable
- … adapté aux problèmes sans zones d’ombres
- Idéal quand les besoins sont bien connus, quand l’analyse et la conception sont claires
Modèle en spirale
Modèle itératif basé sur le prototypage
- Idée : fournir le plus rapidement possible un prototype exécutable permettant une validation concrète et non sur document
- accent mis sur l’analyse de risque
- Progression du projet par incréments successifs de versions successives du prototype : itérations
- 1 itération = 1 mini-cycle de vie en cascade
- Certains prototypes peuvent être montrés aux clients et utilisateurs. Par ailleurs, une maquette peut être réalisée préalablement au premier prototype (Prolog)
- La validation par prototypes ne justifie pas l’absence de recours à la documentation
Exemple : amélioration de la qualité
Objectifs
- Amélioration significative de la qualité
Contraintes
- Sur une échelle de trois ans
- Sans gros investissements
- Sans changement des standards actuels
Alternatives
- Réutiliser des logiciels certifiés existants
- Introduire des spécifications et des vérifications formelles
- Investir dans des outils de test et de vérification
Formulaire d’un tour de spirale
- Objectifs
- Contraintes
- Alternatives
- Risques
- Résolution des risques
- Résultats
- Plans
- Implication
Exemple : amélioration de la qualité
Résultats
- Le manque d’expérience en méthodes formelles rend l’amélioration difficile
- On dispose d’outils limités pour le développement standard de la société
- On dispose de composants réutilisables, mais peu d’outils de support pour la réutilisation
Plans
- Explorer l’option réutilisation plus en détail
- Prototyper des outils de support à la réutilisation
- Etudier les traités de certification de composants
Implication
- Financer 1 mois complémentaires de développement
Exemple : catalogue de composants
Objectifs
- Fournir un catalogue de composants logiciels
Contraintes
- En une année
- Doit gérer les types de composants existants
- Coût total inférieur à $100, 000
Alternatives
- Acheter un logiciel de recherche d’information
- Acheter une base de données et développer un catalogue
- Développer un catalogue dédié
Exemple : catalogue de composants
Risques
- Peut être impossible au vue des contraintes
- Les fonctions du catalogue peuvent être inappropriées
Résolution des risques
- Développer un catalogue prototype pour clarifier les besoins
- Lancer une consultation sur les systèmes existants
- Relâcher les contraintes de temps
Modèle en spirale : intérêts
- Validation concrète et non sur documents
- Limitation du risque à chaque itération
- Concentre l’attention sur les options de réutilisation
- Client partenaire : retour rapide sur attentes
- Progressivité : pas d’explosion des besoins à l’approche de la livraison (pas de «n’importe quoi pourvu que cela passe »)
- Flexibilité :
- Modification des spécifications = nouvelle itération
- Maintenance = forme d’itération
- Planification renforcée
Exemple : catalogue de composants
Résultats
- Les systèmes de recherche d ’information ne sont pas flexibles. On ne peut pas répondre aux besoins
- On peut enrichir un prototype basé sur un SGBD pour compléter le système
- Le développement d’un catalogue dédié n’est pas rentable
Plans
- Enrichir un prototype basé sur un SGBD et améliorer l’interface utilisateur
Implication
- Financer les 12 mois prochains de développement
Quelle architecture logicielle
- Développement logiciel = décomposer / réunir
- Diviser pour comprendre : décomposer le système en sous-parties pour maîtriser la complexité Réunir pour construire : assurer la cohérence globale Architecture logicielle : comment décomposer ?
De l’approche fonctionnelle vers…
- Décomposition fonctionnelle
- Initialement les informaticiens ont raisonné en terme de fonctions du système
- Méthodes inspirées directement de l’architecture des ordinateurs Décomposition hiérarchiquesuivant des critères fonctionnels
- Limitations
- Hiérarchie fonctionnelle : remise en cause difficile
- Adaptibilité limitée et coûts des erreurs important
L’approche OO : avantages
- Stabilité dans la modélisation par rapport aux entités du monde réel
- Adéquation avec un cycle itératifde développement
- Équilibre traitement / données
- Possibilité de réutiliser / porter des éléments d’un autre développement
- Simplicité du modèle 5 concepts :
- Objets, messages, classes, héritage et polymorphisme
… vers l’approche orientée objet
- Décomposition « systémique »
- Ensemble hétérarchique de composants (les objets) indépendants (encapsulation) dont la collaboration dynamique fonde les fonctionnalités du système.
- Objet défini comme une abstraction du monde réel
Concepts objets
- Objets
- État
- Comportement Identité
- Relations entre objets
- Message
- Interface abstraction
- Classe / instance
- Héritage
- Polymorphisme
Objet
Un objet est une entité du monde réel ou du monde informatique
- Exemples d’objets
- Un port, un bateau, un tonneau
- Une fenêtre, un menu, une icône Un entier, un réel, une chaîne de caractères
- Qu’est-ce qui n’est pas un objet ?
- «Tout est objet » [Ferber, 1983]
- Généralement, dans les langages de programmation, on fait le choix du «tout objet » sauf parfois, les types de base (entier, réel, caractère, booléen) pour des raisons d’efficacité
Objet (concrètement)
- Unité atomique formée de l’union d’un état, d’un comportementet d’une identité
- État : décrit les propriétés de l’objet à un moment donné
- Comportement : définit les propriétés dynamiques de l’objet
- Comment il agit et réagit aux informations qui lui parviennent de son environnement
- Identité : caractérise de manière univoque l’existence propre de l’objet (clé en BD)
- L’objet fournit une relation d’encapsulation qui assure à la fois une cohésion interne très forte et un faible couplage avec l’extérieur