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