Analyse Des Besoins Introduction à la Notation UML DESS CCI Cours de Génie Logiciel Tronc Commun Octobre – Décembre 2000 Jean-Marie Favre

Avertissement Ce document regroupe un certain nombre de transparents présentés dans le cadre du cours de Génie Logiciel, du DESS CCI, UFR IMA, à l’Université Joseph Fourier. Il s’agit de la première partie de ce cours, dictée par Jean-Marie Favre. Certains transparents n’ont pas été présentés. Certaines parties du cours se sont déroulées sans transparents. L’ordre des transparents et le découpage du cours est lié intimement au calendrier de l’année 2000 et à des contraintes de précédence entre le cours et les travaux dirigés. Pour plus d’information n’hesitez pas à me contacter : jmfavre@imag.fr Analyse des besoins

Du "codeur" ... au "programmeur" … à "l'ingénieur logiciel" Génie Logiciel Du "codeur" ... au "programmeur" … à "l'ingénieur logiciel" Jean-Marie.Favre@imag.fr

Vous avez dit "Génie Logiciel" ? Génie logiciel ou Ingénierie du logiciel Termes équivalents D'ou viennent ces termes ? Que recouvrent-ils ? Le terme ingénierie est-il adapté ? Qu'est ce qu'un logiciel ? Analyse des besoins

La préhistoire du logiciel Années 50 et 60 : programmation empirique production "artisanale" de logiciels scientifiques royaume des "codeurs" et les "grands gourous" Fin des années 60 : la "crise du logiciel" difficulté d'écrire de grands programmes difficulté de les utiliser, difficulté de les faire évoluer de nombreux projets échouent Analyse des besoins

La "crise du logiciel" Etude du gouvernement américain en 1979 Payés mais jamais livrés $3.2M 47% Livrés mais jamais utilisés $2.0M 30% Abandonnés ou refaits $1.3M 20% Utilisés après modification $0.2M 3% Utilisés tel quel $0.1M 2% Analyse des besoins

Origine du terme "Génie Logiciel" 1968 : "1st Conference on Software Engineering" Génie Logiciel = Ingénierie + Logiciel idée : la production de logiciel doit être organisée contrôle des coûts, contrôle de la qualité, etc. Idée séduisante changement de terminologie 1950 : codeur 1970 : programmeur 1990 : ingénieur logiciel correspond réellement à une discipline d’ingénierie ? Analyse des besoins

Définition : "Ingénierie" "Creating cost-effective solutions ... ... to practical problems ... ... by applying scientific knowledge" [Shaw90] ressources limitées (e.g. temps, argent, ...) solution utile résolvant un problème concret le problème n'est pas inventé par l'ingénieur rigueur dans la résolution du problème prédictibilité du résultat Analyse des besoins

Pratique de l'ingénierie " Engineering practice enables ordinary practitioners so they can create sophisticated systems that work - unspectacularly, perhaps, but reliably" pas besoin d'être un génie pour être un ingénieur ! résolution de problèmes complexes résolution de problèmes récurrents catalogue de solutions pour un type de problèmes solutions sûres et éprouvées Analyse des besoins

Ingénierie et société “The engineer is expected to demonstrate that the design satisfies the specifications." exemple : montrer qu'un pont ne va pas s'écrouler contraintes de sécurité imposée par la société “A highly developed sense of responsability toward his clients and the public” n'importe qui ne peut pas faire n'importe quoi association, droit d'exercer la profession, etc. Analyse des besoins

Modèle d'évolution des disciplines d'ingénierie L'émergence d'une discipline d'ingénierie est un processus lent Ingénierie = production de produits industriels basée sur des connaissances scientifiques (1) Artisanat (2) Production (3) Commerce (4) Science (5) Ingénierie temps Analyse des besoins

Exemple : Génie Chimique Production industrielle de produits chimique : fertilisants, solvants, papier, dérivés du pétrole, etc. 1803 : théorie des atomes 1790 : 1er procédé industriel de production d'alcalis (1) Artisanat (2) Production (3) Commerce (4) Science (5) Ingénierie 1890-1915 : rationalisation opérations unitaires alchimie pierre philosophale 100 ans Analyse des besoins

Status du Génie Logiciel 30 ans (seulement) d'expérience et de recherche dans le domaine trop souvent reste de l'artisanat souvent atteint un niveau commercial ingénierie dans certains cas isolés 1950 : théorie des langages 1960 : algèbre relationnelle (1) Artisanat (2) Production (3) Commerce (4) Science (5) Ingénierie 1970 : crise du logiciel cas isolés : compilateurs, logiciels critiques, ... 1980 : méthodes de développement ... 1950 – 1960 programmation ad-hoc Analyse des besoins

Génie Logiciel ? “The engineer is expected to demonstrate that the design satisfies the specifications." Méthodes formelles existantes mais encore peu utilisées “A highly developed sense of responsability toward his clients and the public” “X-Software Ltd. does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from use of this software...” Analyse des besoins

Génie Logiciel ? " Engineering practice enables ordinary practitioners so they can create sophisticated systems that work - unspectacularly, perhaps, but reliably" Etude récente effectuée aux états unis [Standish Group 1995] 31% des projets non achevés ou abandonnés à la livraison 53% des projets dépassent les ressources allouées 16% des projets se déroulent comme prévu Analyse des besoins

Echecs logiciels Out of range AT&T, 1992: interruption du service téléphonie pendant 5 heures à l'est des états unis. Aréoport de Denver, 1994: logiciel de suivi des bagages, coût 3 millard de $, retard de 18 mois. Oslo, Sept. 1993 : erreur dans le système de contages des votes du parlement => nouvelles éléctions etc, etc. 5 e n a i r A $370 000 000 Out of range Analyse des besoins

Echec du Génie Logiciel ? Echec du Génie Logiciel ? Non ! de très nombreuses avancées les logiciels sont de plus en plus demandés et utilisés des logiciels construits sont de plus en plus complexes Des progrès restent à faire... Un sujet essentiel ! recherche pratique industrielle enseignement Analyse des besoins

Importance grandissante du logiciel MATERIEL LOGICIEL 1950 1970 1990 Coût (%) 50% 10% 100% Valeur du logiciel au états unis 1980 : 2% of PNB 1985 : 8% of PNB 1990 : 13% of PNB Augmentation de 12% par an La valeur des logiciels existant sur la planète dépasse la valeur des gisements pétroliers ! Une amélioration de rendement même faible peut avoir des répercutions trés importantes Analyse des besoins

Définition : "Logiciel" “Computer programs and the associated documentation required to develop, operate and maintain them” [Boehm76] Erreur courante : logiciel = code source Pas uniquement le code source ! binaires, librairies, manuel utilisateurs, etc. spécifications, dossier de conception, test, etc. Savoir programmer n'est qu'un "détail" ! Analyse des besoins

Logiciels industriels Taille des millions de lignes de code, milliers de modules, ... Durée de vie 5 à 20 ans ... à 50 ans Taille des équipes 3 à 50 ... à 1000 ingénieurs logiciels équipes réparties autour de la planète Coût de développement et de maintenance de centaines de milliers de francs ... à des millards Analyse des besoins

Approches Gestion du produit et des ressources Méthodes Outils gestion de projet, estimation des coûts,... assurance qualité, standardisation, ... Méthodes méthodes formelles, semi-formelles, informelles Outils outil de modélisation, génération de code, ... gestionnaire de configuration, outil de communication... Analyse des besoins

Résumé Les logiciels sont de plus en plus complexes Le rôle du logiciel dans la société est essentiel La programmation empirique mène à l'échec La programmation est un « détail » en informatique De nombreuses techniques de GL sont disponibles L'enseignement du Génie Logiciel est fondamental Le génie logiciel n'est pas encore une discipline d'ingénierie très mûre mais elle doit le devenir Analyse des besoins

Analyse des besoins Problématique Capture des besoins Définition des besoins (Spécification des besoins) Jean-Marie.Favre@imag.fr

Que veux dire Rothschild ? "There are three ways to loose money: women, gambling and engineers. The two former are the more comfortable ones, the latter the most certain" - bankier Rothschild - Analyse des besoins

Problématique Beaucoup de systèmes informatiques ne sont jamais utilisés car ils ne correspondent pas aux besoins du client ! « Ce n ’est pas ce que je voulais… » « Ca ne sert à rien... » « Comment je fais ça ?» « Ce n’est pas le bon résultat ! » « Je vous avais dis que je voulais ça ! » ... Analyse des besoins

Causes Le client ne sais pas ce qu’il veut Le client ne sais pas exprimer ce qu’il veut L’informaticien ne comprend pas client Le client ne comprend pas l’informaticien Ce que le client veut n’est pas ce qu’il voulait Analyse des besoins

Des difficultés réelles ! Difficultés de communiquer difficulté d’être précis, cohérent, complet, ... différences de culture : les utilisateurs ne sont pas informaticiens… les informaticiens ne connaissent pas le domaine... Complexité du problème problème non formalisé problème complexe Évolutivité Analyse des besoins

Analyse des besoins L ’une des étapes les plus importantes étape déterminante pour la suite aspects contractuels L ’une des étapes les plus difficiles différents intervenants : le client, les utilisateurs, les développeurs… le problème n’est pas encore formalisé Analyse des besoins

Différents rôles Identifier les différents intervenants : Le(s) client(s) Les utilisateurs Le maître d’œuvre Les développeurs ... Identifier le rôle de chacun Éventuellement associer des priorités Le client est roi (mais quand même) Analyse des besoins

Différentes étapes Capture des besoins Définition des besoins collecte des informations : interviews, lecture de doc. chercher à comprendre : (1) le domaine (2) le problème Définition des besoins restitution dans un langage compréhensible par le client identification, structuration, définition d'un dictionnaire Spécification des besoins spécification détaillée des besoins, plus formel utile pour le client, mais aussi pour les développeurs Analyse des besoins

Capture des besoins : collecter Objectifs comprendre le domaine comprendre le problème (1) Collecter le maximum d ’informations Lecture des documents fournis Interviews du client, des utilisateurs, … Réunions de travail Collecter des exemples pour valider Étudier les systèmes existants le cas échéant Analyse des besoins

Capture des besoins : interagir (2) Réagir et être actif ! Établir la liste des documents consultés, les classer Élaborer une liste de questions précises les numéroter, les dater, … faire référence aux documents concernés Écrire un ou plusieurs documents et les diffuser Provoquer les réunions et les mener établir l’ordre du jour prendre des notes faire systématiquement des comptes rendus écrits Analyse des besoins

Définition des besoins Restituer les informations sous forme synthétique Ce qui n’est pas écrit n’existe pas ! Préciser les besoins, pas la solution Préciser ce que doit faire le système et aussi ce qu’il n ’est pas sensé faire. mais surtout pas comment il doit le faire. Etablir des priorités Arriver à un consensus avec le client Analyse des besoins

Différents types de besoins Besoins fonctionnels à quoi sert le système ce que doit faire le système, les fonctions utiles Besoins non fonctionnels performance, sûreté, confidentialité, portabilité, etc. chercher des critères mesurables Analyse des besoins

Quelques conseils Les besoins doivent être compris par tous utiliser la langue naturelle utiliser des schémas si nécessaire tout schéma doit être commenté tout schéma doit toujours comporter un légende Structurer le document suivre un plan standard si disponible numéroter les sections, références, index, … Analyse des besoins

Langue naturelle … mais technique Faire des phrases courtes Eviter le conditionnel, le futur Eviter les termes ambigus ou subjectifs, ... Parler en termes de rôles plutôt que de personnes Numéroter les paragraphes si nécessaire Utilisation de références précises Elaborer un dictionnaire Analyse des besoins

Elaboration d'un Dictionnaire Indispensable d'avoir un langage commun définition d'un vocabulaire précis client, équipe de développement, utilisateurs Utilisation dans les documents et aussi le logiciel ! analyse des besoins (clients) base pour le développement du logiciel (développeurs) base pour l'interface du logiciel (utilisateurs) Technique simple mais efficace ! Analyse des besoins

Format du dictionnaire Notion Définition Nom info. Type entité Pilotage Action de piloter un avion en enchaînant des manœuvres élémentaires paquetage Instrument Organe d'interaction entre le pilote et l'avion classe abstraite Manche à balai Instrument permettant au pilote de diriger l'avion MancheABalai classe Action Augmenter les gaz Action permettant d'injecter du carburant pour augmenter la vitesse de l'avion IncrGaz opération Analyse des besoins

Intérêt du dictionnaire Outil de dialogue Informel, facile à réaliser, facile à faire évoluer Permet de décrire la terminologie du domaine réutilisable dans un autre projet permet de détecter les ambiguïtés Montre l'essentiel du domaine d'application Permet d'assurer la traçabilité Analyse des besoins

Construction du dictionnaire Partir de la description du problème Repérer les groupes nominaux -> notion Repérer les groupes verbaux -> action ou notion Eliminer les synonymes Eliminer les termes inutiles Donner des définitions simples Permet de se concentrer sur l'essentiel Doit être complété et mis à jour ! Analyse des besoins

Spécification des besoins Interface entre le client et les développeurs doit être compris par les deux défini dans le détail ce qui doit être réalisé doit être précis car contractuel Utilisation de techniques semi-formelles e.g. diagrammes de cas d'utilisation UML e.g. diagrammes de classes UML Analyse des besoins

Résumé L'analyse des besoins est une étape essentielle Origine de toute activité de développement Problème de communication client / informaticiens Capture des besoins : collecter l'information Définition des besoins : restituer les besoins Spécification des besoins : définir précisément Des techniques informelles mais utiles ! Besoin également de techniques plus précises… Analyse des besoins

Le langage UML : une vision globale Jean-Marie.Favre@imag.fr

UML = Unified Modeling Language Analyse et conception orientée objet Une notation  Une méthode « The Unified Software Development Process » Des outils Rational Rose, Objecteering, ... Analyse des besoins

La notation UML LeS notationS UML : plusieurs notations Notations graphiques Signification précise Notation standard Notation très générale Notation extensible Analyse des besoins

Historique 80-90 : apparition de nombreuses méthodes 90-95 : + de 50 méthodes orientées objets… 95 : première version UML (0.8) 97 : standardisation OMG (Dec, Rational, Microsoft, HP, Oracle…) 99 : proposition UML 1.3 00 : ... Analyse des besoins

LeS notationS UML Diagrammes des cas d ’utilisation Diagrammes de classes Diagrammes de séquence Diagrammes de collaboration Diagrammes d’états Diagrammes d’activités ... Analyse des besoins

Diagrammes des cas d ’utilisation Entrer Capteur AIncendie DébloquerLesPortes PorteurDeCarte Sortir ListerLes TentativesDeFraudes GérerLesCartes Gardien Administrateur Analyse des besoins SystèmeDeContrôleDAcces

Diagrammes de classes Compte numéro solde ... Banque numéro nom 1..4 0..* 1..* 1..* Client titulaires 0..* 1 signataire 1 Consortium CarteBleue Code retraitMax 0..* 0..1 1 AcceptéPar> 0..* Distributeur 1..* Analyse des besoins

Diagrammes d ’objets Analyse des besoins : Distributeur : CarteBleue EstAcceptéPar> : Distributeur : CarteBleue signataire titulaires fred : Client c4 : Compte : Banque : Consortium : CarteBleue signataire paul : Client c1 : Compte : Banque titulaires titulaires pierre : Client c2 : Compte : Consortium titulaires titulaires marie : Client c3 : Compte : Banque signataire : CarteBleue EstAcceptéPar> sophie : Client : Distributeur EstAcceptéPar> Analyse des besoins

Diagrammes de séquence paul le distrib. la carte de P. la reserve la banque le compte de P. retirer(500) lireN°Compte() retirerDeLArgent(500,88219) débiter(500) sortirDesBillets(5) sortirBillets () Analyse des besoins

Diagrammes de collaboration 6 : prendreBillet() la reserve de billets 5 : sortirDesBillets(5) 1 : retirer(500) 4 : débiter(500) 3 : retirerDeLArgent (500,88219) le distributeur la banque paul 88219 2 : lireN°Compte() le compte de paul la carte de P. Analyse des besoins

Diagrammes d ’états En attente En attente du code carte insérée En attente En attente du code carte retirée code frappé mauvais code En attente retrait carte En vérification code bon montant incorrect En attente du montant montant correct billets retirés En distribution Analyse des besoins

Les notations UML au cours du Cycle de Vie Les notations UML peuvent être utilisées de l ’analyse des besoins à la conception détaillée Avantages cohérence plus simple à vérifier. moins de notations à apprendre ! Inconvénients confusion entre les niveaux. expliquer à quel niveau on est ! Analyse des besoins

Le Processus Unifié Une méthode relativement détaillée définition des « travailleurs » définition des « activités » définition des « résultats » à produire processus pas à pas : ça, puis ça, puis ça... Pas nécessairement applicable à tous les domaines Moins général que la notation Analyse des besoins

UML : Diagrammes de Cas d‘Utilisation Acteurs, Cas d’utilisation, Système Diagrammes de Cas d’utilisation Modèle de Cas d’utilisation Scénario Jean-Marie.Favre@imag.fr

Les diagrammes de cas d ’utilisation Une des notations d ’UML (use-cases) But : définir le système du point de vue des utilisateurs définir les limites précises du système Notation très simple, compréhensible par tous Permet de structurer : les besoins (cahier des charges) le reste du développement CasU1 CasU4 CasU5 CasU2 CasU3 A1 A2 S A3 Analyse des besoins

Exemple de diagrammes de cas d ’utilisation Système bancaire CréerUnCompte ConsulterUnCompte Guichetier Client RetirerDeLArgentAuDistributeur DeposerDeLArgent SurUnCompte Directeur RetirerDeLArgent DUnCompte GererLesPrets Analyse des besoins

Exemple de diagrammes de cas d ’utilisation DistributeurDeBillet Client Banque Centrale RetirerDeLArgentAuDistributeur ConsulterSonCompte Technicien Ajouter DesBillets Assurer LaMaintenance Transporteur DeBillets Analyse des besoins

Exemple de diagrammes de cas d ’utilisation Entrer Capteur AIncendie DébloquerLesPortes PorteurDeCarte Sortir ListerLes TentativesDeFraudes GérerLesCartes Gardien Administrateur Analyse des besoins SystèmeDeContrôleDAcces

Modèle des cas d’utilisation Un diagramme de cas d’utilisation décrit : les acteurs les cas d’utilisation le système Un modèle de cas d’utilisation peut être formé de plusieurs diagrammes, de descriptions textuelles. CasU1 CasU4 CasU5 CasU2 CasU3 A1 A2 S A3 Analyse des besoins

Cas d’utilisation (CU) CasDUtilisationX Cas d’utilisation (CU) une manière d’utiliser le système une suite d’interactions entre un acteur et le système ex: le guichetier peut créer un nouveau compte Correspond à une fonction visible par l’utilisateur Permet d ’atteindre un but pour un utilisateur Doit être utile en soi Analyse des besoins

Le système Le système est un ensemble de cas d’utilisation Le système contient : les cas d ’utilisation, mais pas les acteurs. Un modèle de cas d ’utilisation permet de définir : les fonctions essentielles du système, les limites du système, le système par rapport à son environnement. Analyse des besoins

Acteurs Un Acteur = Une même personne peut jouer plusieurs rôles Client Un Acteur = élément externe qui interagit avec le système rôle qu’un utilisateur joue par rapport au système ex: un client, un guichetier Une même personne peut jouer plusieurs rôles ex: Maurice est directeur mais peut faire le guichetier Plusieurs personnes peuvent jouer un même rôle ex: Paul et Pierre sont deux clients Un acteur n’est pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur Analyse des besoins

Différents types d ’acteurs Client Utilisateurs principaux ex: client, guichetier Utilisateurs secondaires ex: contrôleur, directeur, ingénieur système, ... Périphériques externes ex: un capteur, une horloge externe, ... Systèmes externes ex: système interbancaires Analyse des besoins

Description des acteurs Client Pour chaque acteur : choisir un identificateur représentatif de son rôle donner une brève description textuelle Un guichetier est un employé de la banque chargé de faire l’interface entre le système informatique et les clients qu’il reçoit au comptoir. Le guichetier peut réaliser les opérations courantes : création d ’un compte, dépôt et retrait d ’argent, etc. Guichetier Analyse des besoins

Utilité des acteurs La définition d’acteurs permet surtout Client La définition d’acteurs permet surtout de trouver les cas d’utilisation ex: que peut faire un guichetier ? un client ? le directeur ? mais peut aussi être utilisée pour définir différents points de vues sur le système, déterminer des droits d’accès par type d’acteur, fixer des ordres de priorités entre acteurs, ... Analyse des besoins

Description des cas d’utilisation CasDUtilisationX Pour chaque cas d ’utilisation choisir un identificateur représentatif donner une description textuelle simple la fonction réalisée doit être comprise de tous pas trop de détails préciser ce que fait le système, ce que fait l’acteur Les cas d ’utilisation ne doivent pas se chevaucher Analyse des besoins

Exemple de description d ’un cas d ’utilisation CasDUtilisationX Lorsqu’un client à besoin de retirer du liquide il peut en utilisant un distributeur retirer de l ’argent de son compte. Pour cela - le client insère sa carte bancaire dans le distributeur - le système demande le code pour l ’identifier - le client choisi le montant du retrait - le système vérifie qu ’il y a suffisamment d ’argent - si c ’est le cas, le système distribue les billets et retire l ’argent du compte du client - le client prend les billets et retire sa carte Retirer DeLArgent AuDistributeur Analyse des besoins

RetirerDeLArgentAuDistributeur Relations Communication Utilisation Extension Guichetier CréerUnCompte IdentifierLeClient DeposerDeLArgent « Utilise » RetirerDeLArgentAuDistributeur RetirerDeLArgent « Étend » Analyse des besoins

Description du modèle de cas d ’utilisation Un modèle de cas d’utilisation peut contenir plusieurs diagrammes plusieurs descriptions textuelles Permet d’avoir une vision globale du système Permet de définir des priorités entre CU Utile pour le client, pour la planification,... Trop général pour être utilisé par les développeurs Analyse des besoins

Exemple de diagramme de CU décoré Système bancaire 12/07/99 CréerUnCompte P1 25/12/99 ConsulterUnCompte Guichetier P2 Client 10/06/00 RetirerDeLArgentAuDistributeur P2 20/05/99 DeposerDeLArgent SurUnCompte P1 10/12/00 P3 Directeur 12/07/99 Pi : priorité GererLesPrets RetirerDeLArgent DUnCompte P1 Analyse des besoins

Description détaillée de chaque cas d’utilisation Chaque cas d ’utilisation doit être décrit en détail Commencer par les CU prioritaires Description utile pour la suite du développement Description détaillée plus où moins formelle langue naturelle mais structurée, vocabulaire précis diagramme d ’états ... Analyse des besoins

Informations à décrire Quand le CU commence, pré-conditions Quand le CU se termine, post-conditions Le chemin correspondant au déroulement normal Les variantes possibles et les cas d’erreurs Les interactions entre le système et les acteurs Les informations échangées Les éventuels besoins non fonctionnels Analyse des besoins

Exemple de description détaillée d ’un CU Précondition : Le distributeur contient des billets, il est en attente d ’une opération, il n’est ni en panne, ni en maintenance Début : lorsqu ’un client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Si de l ’argent a pu être retiré la somme d’argent sur le compte est égale à la somme d ’argent qu’il y avait avant, moins le montant du retrait. Sinon la somme d ’argent sur le compte est la même qu’avant. Retirer DeLArgent AuDistributeur Analyse des besoins

Exemple de description détaillée d ’un CU Déroulement normal : (1) le client introduit sa carte bancaire (2) le système lit la carte et vérifie si la carte est valide (3) le système demande au client de taper son code (4) le client tape son code confidentiel (5) le système vérifie que le code correspond à la carte (6) le client choisi une opération de retrait (7) le système demande le montant à retirer … Variantes : (A) Carte invalide : au cours de l ’étape (2) si la carte est jugée invalide, le système affiche un message d ’erreur, rejète la carte et le cas d ’utilisation se termine. (B) Code erroné : au cours de l ’étape (5) ... Retirer DeLArgent AuDistributeur Analyse des besoins

Exemple de description détaillée d ’un CU Contraintes non fonctionnelles : (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l ’action de l ’utilisateur. (B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d ’utilisation, la transaction sera annulée, l ’argent ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine. (C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d ’argent simultanément ... Retirer DeLArgent AuDistributeur Analyse des besoins

Scénario Pour décrire ou valider un CU : les scénarios Un scénario est un exemple : une manière particulière d ’utiliser le système … … par une personne particulière … … dans un contexte particulier. cas d ’utilisation = ensemble de scénarios scénario = une exécution particulière d’un CU Analyse des besoins

Retirer DeLArgent AuDistributeur Exemple de scénario SCENARIO 4 Paul insère sa carte dans le distributeur d2103 Le système accepte la carte et lit le numéro de compte Le système demande le code Paul tape ‘ 1234 ’ Le système indique que ce n ’est pas le bon code Le système affiche un message et propose de recommencer Paul tape ‘ 6622’ Le système affiche que le code est correct Le système demande le montant du retrait Paul tape 50000 fr Le système vérifie s ’il y a assez d ’argent sur le compte ... Retirer DeLArgent AuDistributeur Analyse des besoins

Diagrammes de séquences Pour décrire un scénario : diagramme de séquence Diagramme de séquences : L’une des notations UML, une notation générale Peut être utilisée dans de nombreux contextes Permet de décrire une séquence des messages échangés entre différents objets Différents niveaux de détails Pour décrire un scénario simple, deux objets : l’acteur et le système Analyse des besoins

Exemple de scénario ... paul : Client le système Insérer carte Vérifier carte Demander code Entrer code ‘1234 ’  Vérifier code Message d ’erreur Demander code Entrer code ‘6622 ’  ... Analyse des besoins

Le Processus Unifié (1) Définir le modèle de cas d’utilisation (1.1) Trouver les acteurs (1.2) Décrire brièvement chaque acteur (1.3) Trouver les cas d ’utilisation (1.4) Décrire brièvement chaque cas d ’utilisation (1.5) Décrire le modèle comme un tout (2) Définir des priorités entre CU (3) Détailler chaque CU (en tenant compte des priorités) Analyse des besoins

Résumé Différents concepts UML Modèle des cas d’utilisation Diagramme des cas d’utilisation Acteur Cas d ’utilisation Scénario Processus Unifié : commencer par les acteurs Utiliser les schémas mais aussi la langue naturelle! Analyse des besoins

Approche orientée-objet Objets, Classe Attribut, Méthode, Message Réification, Encapsulation, Classification Jean-Marie.Favre@imag.fr

Evolution du Génie Logiciel Modèle des vagues [Racoon97] Interest Innovation new development basic understanding Growth increasingly popular growing enthusiasm Maturity balanced understanding limits become apparent Convention core idea accepted work on new developements 10 to 15 years Innovation Growth Maturity Convention 1950 1973 1980 1988 Time Vague d’intérêt pour les Modules Analyse des besoins

Vagues des matériels informatiques Internet, Ubiquitous Computing Commercial Mini Computers Personal Computers Commercial Mainframes Research Mainframe 1945 1955 1966 1977 2000 Analyse des besoins

Vagues des techniques de structuration Statement Function Module Object Framework 1945 1958 1973 1988 2003? Analyse des besoins

Différentes approches Approche Fonctionnelle l ’important c’est les traitements diviser pour régner réutilisation difficile, évolution difficile, ... Approche Orientée Objet <==== l’important c’est les objets objets = données + traitements monde réel => modèle du monde réutilisation et évolution simplifiée Analyse des besoins

La vague de « l’Orienté Objet » Programmation orientée objet Smalltalk, C++, Java... Bases de données orientées objet O2, Object-store, ... Méthodes orientée objet OMT, HOOD, UML, ... Tout (et n ’importe quoi mais) orienté objet Analyse des besoins

Orienté Objet Représenter un système comme un ensemble d’objets autonomes mais interagissant via des envois de messages Chaque objet représente un objet ou un concept de la vie réelle a une identité unique et invariante a un état caractérisé par la valeur de ses attributs propose des services sous la forme de méthodes exécute un service lorsque l’objet reçoit un message Analyse des besoins

Objets Un système peut être vu comme un ensemble d ’objets Pierre le distributeur la banque la réserve de billet le compte de Paul le compte de Pierre la carte bancaire de Paul Marie Paul Le compte de Pierre et de Marie Analyse des besoins

Principe de réification Réification = matérialiser un concept par un objet Un concept abstrait peut être « réifié » l’événement « à 10h45 une carte bleue à été introduite » Une relation entre deux objets peut être « réifié » « jean possède la voiture immatriculée 875 QV 38 » est réifié dans le monde réel par une carte grise Réifier un concept permet de le manipuler concrètement Question ouverte : quels concepts réifier ? Un «bon» modèle réifie les «bons» concepts…  Analyse des besoins

Attributs et méthodes Chaque objet a un état caractérisé par la valeur de ses attributs propose des services sous la forme de méthodes la banque numéro = 2453 nom = « banque du sud » … Créer un compte Supprimer un compte Faire un virement Retirer de l ’argent numéro = 88219 solde = 2000 découvert max = -500 le compte de Paul ConsulterSolde Créditer Débiter le compte de Pierre numéro = 88213 solde = 10 découvert max = -100 Analyse des besoins

Les objets interagissent par des envois de messages la reserve de billets 5 : sortirDesBillets 1 : retirer 3 : retirerDeLArgent 4 : débiter le distributeur la banque paul 2 : lireN°Compte le compte de paul la carte de P. Analyse des besoins

Principe d’encapsulation Chaque objet indique les méthodes qu’il expose (son interface) ex: on sait que le distributeur permet de retirer de l’argent mais cache la réalisation concrète des méthodes ex: on sait pas ce que fait le distributeur de manière interne lorsqu’il reçoit le message retirer de l’argent et n’expose jamais ses attributs directement ex: on ne sait pas si le distributeur garde le nombre d ’opérations effectuées, la date de la dernière opération, etc. sauf via éventuellement des méthodes ex: on peut consulter le solde d ’un compte, créditer ou débiter un compte, mais pas modifier directement l’attribut solde Analyse des besoins

Avantages du principe d’encapsulation Un client ne connaît que l’interface de l’objet l’objet est plus simple à comprendre ex: pas la peine de comprendre le contenu d ’un magnétoscope pour pouvoir l ’utiliser. l’objet plus simple à réutiliser ex: si l’interface est bien définie on peut le brancher à d ’autres appareils (chaîne hi-fi, télévision, …) l ’objet est protégé contre les mauvaises utilisations ex: on ne peut pas mettre les doigts dans le magnétoscope ni enlever la cassette pendant que le moteur tourne... Analyse des besoins

Avantages du principe d’encapsulation La réalisation de l’objet peut être modifiée sans impact sur le client on peut améliorer l’objet et le faire évoluer ex: mettre un moteur plus rapide dans le magnétoscope, remplacer un composant par un autre équivalent on pourrait remplacer l’objet par un autre équivalent ex: pas de problème pour passer d ’un magnétoscope à un autre Analyse des besoins

Principe de classification Regrouper des objets similaires en classes Une classe est un modèle, un «moule» Chaque objet est une instance d’une classe Une classe permet d’instancier plusieurs objets Une classe est caractérisée par ses attributs ses méthodes Analyse des besoins

Classes vs. Objets Niveau des classes (modèle) Niveau des objets Compte numéro solde découvert Niveau des classes (modèle) ConsulterSolde Créditer Débiter « InstanceDe » « InstanceDe » le compte de Paul numéro = 88219 solde = 5000 découvert max = -500 ConsulterSolde Créditer Débiter le compte de Pierre numéro = 88213 solde = 20 découvert max = -100 ConsulterSolde Créditer Débiter Niveau des objets (instances) Analyse des besoins

Exemple de classification Client Compte Banque Distributeur Niveau des classes Niveau des objets le compte de Paul pierre une banque le compte de Pierre marie le distrib. D28 paul john le compte de Pierre et de Marie le distrib. D11 Analyse des besoins

Avantages du principe de classification Modèle plus simple il y a beaucoup moins de classes que d’objets les objets d’une même classe sont similaires l’ensemble des classes ne change pas pendant l’exécution Modèle plus général le modèle est indépendant de l’état des objets le modèle est indépendant du nombre d’objets Modèle réutilisable une classe est un composant logiciel réutilisable Analyse des besoins

UML : Diagrammes de Classes Objet, Classe, Attribut, Méthode Lien, Association, Cardinalité Généralisation, Spécialisation Composition Composition, Classe Associative, … Jean-Marie.Favre@imag.fr

Concepts de base UML est basé sur différents concepts de base : Objet, Classe Lien, Association Contrainte UML propose des notations et des diagrammes Diagramme de classes (description au niveau modèle) Diagramme d’objets (description au niveau instance) Analyse des besoins

Notation pour les classes Compte Nom de la classe numéro : entier solde : réel découvertMax : entier Attributs nom type consulterSolde() : entier créditer( somme : entier) débiter( somme : entier) Méthodes nom paramètre type du résultat { solde > découvertMax } Contraintes Analyse des besoins

Notations simplifiées pour les classes Compte numéro solde ... Compte numéro solde : réel découvertMax : entier consulterSolde() : entier créditer( somme : entier) débiter( somme ) Compte numéro solde ... créditer() débiter() Compte Compte créditer() débiter() ... Conventions : les noms de classes commencent par une majuscule les noms d ’attributs et de méthodes commencent par une minuscule Analyse des besoins

Notations pour les objets leCompteDePaul leCompteDePaul : Compte numéro = 6688 solde = 5000 découvertMax = -100 : Compte leCompteDePaul : Compte Convention : les noms d ’objets commencent par une minuscule et sont soulignés Analyse des besoins

Liens (entre objets) Un lien indique une connexion entre deux objets APourCompte> c1 : Compte paul : Client APourCompte> pierre : Client c2 : Compte APourCompte> c3 : Compte marie : Client Conventions : les noms des liens sont des formes verbales et commencent par une majuscule > indique le sens de la lecture (ex: « paul APourCompte c1 » Analyse des besoins

Rôles Chacun des deux objets joue un rôle diffèrent dans le lien APourCompte> c1 : Compte pierre : Client titulaire compte pierre assume le rôle de titulaire pour le compte c1 c1 assume le rôle de compte pour pierre Conventions : choisir un groupe nominal pour désigner un rôle si un nom de rôle est omis, le nom de la classe fait office de nom Analyse des besoins

Associations (entre classes) Une association décrit un ensemble de liens de même sémantique Diagramme de classes (modèle) APourCompte> Client Compte APourCompte> paul : Client c1 : Compte Diagramme d ’objets (instances) APourCompte> pierre : Client c2 : Compte APourCompte> marie : Client c3 : Compte Analyse des besoins

Liens vs. Associations Un lien lie deux objets Une association lie deux classes Un lien est une instance d’association Une association décrit un ensemble de liens Des liens peuvent être ajoutés ou créés pendant l ’exécution, ce n ’est pas le cas des associations Analyse des besoins

Cardinalités d’une association Précise combien d’objets peuvent être liés à un seul objet source Cardinalité minimale et cardinalité maximale ( Cmin..Cmax) 1 APourCompte> 0..* Client Compte titulaire comptes « Un client a 0 ou plusieurs comptes » « Un compte a toujours 1 et 1 seul titulaire » c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte APourCompte> Analyse des besoins

Utiliser les rôles pour «naviguer» 1 APourCompte> 0..* Client Compte titulaire comptes paul.comptes = {c1} pierre.comptes = {c2,c3} marie.comptes = {} c1.titulaire = paul c2.titulaire = pierre c3.titulaire = pierre APourCompte> paul : Client c1 : Compte APourCompte> pierre : Client c2 : Compte APourCompte> marie : Client c3 : Compte Analyse des besoins

Contraintes entre associations Les cardinalités ne permettent pas d’exprimer toutes les contraintes... 1 titulairePrincipal 0..* Compte numéro solde ... Client 0..* co-titulaires 0..* 1..* titulaires 0..* … décrire les contraintes en langue naturelle (ou en OCL le langage de contrainte d’UML) (1) Un client ne peut pas être à la fois titulaire principal et co-titulaire d ’un même compte. (2) Les titulaires d ’un compte sont le titulaire principal et les co-titulaires le cas échéant Analyse des besoins

Diagramme de classes Compte numéro solde ... Banque numéro nom 1..4 0..* 1..* 1..* Client titulaires 0..* 1 signataire 1 0..* Consortium CarteBleue Code retraitMax 0..* 0..1 virementPossible 1 EstAcceptéPar> 0..* Distributeur 1..* (1) Le signataire de la carte bleue associée à un compte est l ’un des titulaires de ce compte. (2) Une carte bleue est acceptée au moins dans tous les distributeurs appartenant aux consortiums de la banque correspondant au compte associé à la carte bleue. (3) Un virement est possible entre deux comptes distincts si les banques correspondantes appartiennent à un même consortium. Analyse des besoins

Diagrammes d’objets Analyse des besoins : Distributeur : CarteBleue EstAcceptéPar> : Distributeur : CarteBleue signataire titulaires fred : Client c4 : Compte : Banque : Consortium : CarteBleue signataire paul : Client c1 : Compte : Banque titulaires titulaires pierre : Client c2 : Compte : Consortium titulaires titulaires marie : Client c3 : Compte : Banque signataire : CarteBleue EstAcceptéPar> sophie : Client : Distributeur EstAcceptéPar> Analyse des besoins

Diagrammes de classes vs. d’objets Un diagramme de classes défini l’ensemble de tous les états possibles les contraintes doivent toujours être vérifiées Un diagramme d’objets décrit un état possible à un instant t, un cas particulier doit être conforme au modèle de classes Les diagrammes d’objets peuvent être utilisés pour expliquer un diagramme de classe (donner un exemple) valider un diagramme de classe Analyse des besoins

Diagrammes de classes vs. d’objets Client 1..4 0..* titulaires Consortium Compte numéro solde ... 1..* 0..1 1 Banque nom Distributeur signataire CarteBleue Code retraitMax EstAcceptéPar> virementPossible ... > : : : Compte : Client titulaires : : Banque : Consortium : Distributeur > > : : : Client : : : Consortium : Client : : : Consortium : : titulaires : Compte : Banque titulaires : Compte : Banque : Client titulaires : Compte : Consortium : Client : Compte : Consortium : Client titulaires titulaires : Compte : Banque : Banque : Client titulaires : Compte : Banque signataire : : : Client > > : Distributeur : Distributeur : Client > > : Distributeur t1 t2 t3 Analyse des besoins

Synthèse des concepts de base Classe attribut méthode Association rôle cardinalité Contrainte Objet Lien Analyse des besoins

Exemple Personne Société subordonnés * 1..* 0..1 employés 0..1 directeur (1) Le directeur de tout employé est employé dans la même société. (2) Dans toute société il y a au moins une personne qui n ’est dirigée par personne (le directeur de la société). (3) Une personne ne peut pas être directeur d ’elle même ... Analyse des besoins

Exemple Personne parents 0..2 mère 0..1 père 0..1 épouse sexe 0..1 paul époux épouse marie mère 0..1 parents pére mère père 0..1 épouse Personne joe sexe 0..1 enfants enfants parents enfants * 0..1 époux Analyse des besoins

Navigation Association unidirectionnelle On ne peut naviguer que dans un sens titulaire Client Compte 1 Ce détail n’est a priori utile que lors de la conception détaillée Analyse des besoins

Composition Une composition est un cas particulier d’association avec des contraintes en plus permettant de décrire la notion de composant... 1..* 1 1..* Section Chapitre Document 0..* Figure 1..* Un objet composant ne peut être que dans un seul objet composite Un objet composant n’existe pas sans son objet composite Si un objet composite est détruit, ses composants aussi Analyse des besoins

Composition Les composants forment un arbre Section Chapitre Document 1..* 1 1..* Section Chapitre Document 0..* Figure 1..* : section : chapitre : section Les composants forment un arbre : figure : document : chapitre : section : figure Analyse des besoins

Composition Point x y Cercle rayon Polygone 3..* 1 Analyse des besoins

Classes associatives Dans certains cas il est utile d’associer des attributs et/ou des méthodes aux associations => classes associatives employé société Personne Société 0..2 * Emploi salaire augmenter() Le nom de la classe correspond au nom de l’association Analyse des besoins

Classes associatives Personne Société Emploi employé société Personne Société 0..2 * Emploi salaire augmenter() e1 salaire = 10000 s1 Le salaire est une information correspondant ni à une personne, ni à une société, mais à un emploi (un couple personne-société). e2 salaire = 2000 employé employé pierre s1 e3 salaire = 16000 marie employé Analyse des besoins

Classes associatives Pour une association donnée, deux objets ne peuvent être connectés que par un seul lien correspondant à cette association. Emploi> p1 s1 Emploi> Cette contrainte reste vraie dans le cas où l’association est décrite à partir d ’une classe associative. : Emploi salaire = 10000 p1 s1 : Emploi salaire = 2000 Analyse des besoins

Classes associatives Personne Société Emploi employé société Personne Société 0..2 * Emploi salaire e1 p1 s1 Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société e2 p1 s1 e1 employé 0..2 société Emploi salaire * Personne Société 1 1 Ci-dessus, une personne peut avoir deux emplois dans la même société Analyse des besoins

Ou ? Classes associatives Virement Virement compte compte montant * * compteDébité compteDébité 1 1 compteCrédité * compte compte * compteCrédité Analyse des besoins

Classes associatives Les classes associatives sont des associations mais aussi des classes. Elles ont donc les mêmes propriétés et peuvent par exemple être liées par des associations. employé société Personne Société * * Emploi salaire augmenter() responsable 0..1 subordonnés * Analyse des besoins

Contraintes sur les associations Contraintes prédéfinies sur les associations. Par exemple : { frozen } : fixé lors de la création de l ’objet, ne peut pas changer { ordered } : les éléments de la collection sont ordonnés { addOnly } : impossible de supprimer un élément lignes RelevéDeCompte Ligne Opération * {ordered,addOnly} Il est possible de définir de nouvelles contraintes Analyse des besoins

Synthèse sur les associations Nom de rôle Nom d ’association Cardinalités <AssociationX 0..* roleA ClasseA ClasseB {frozen} AssociationX Composition attributZ Navigation Contrainte Classe associative Analyse des besoins

Généralisation / Spécialisation Une classe peut être la généralisation d ’une ou plusieurs autres classes. Ces classes sont alors des spécialisations de cette classe. Super classe Personne Compte Homme Femme Compte Epargne Sous classes Analyse des besoins

Généralisation / Spécialisation Vision ensembliste : tout objet d’une sous-classe appartient également à la super-classe => inclusion des ensembles d’objets Compte c3 c2 ce2 c2 ce1 ce3 c1 Compte Epargne Compte CompteEpargne Analyse des besoins

Héritage Les sous-classes « héritent » des propriétés des super-classes (attributs, méthodes, associations, contraintes) Compte * Banque solde CompteEpargne créditer() débiter() solde tauxIntérêt * Banque {solde > -5000} créditer() débiter() calculIntérêts () CompteEpargne tauxIntérêt {solde > -5000 et tauxIntérêt < 100} ajouterIntérêts () {tauxIntérêt < 100} Analyse des besoins

Redéfinition Une sous classe peut redéfinir une propriété, à condition toutefois de rester compatible avec la définition originale Figure surface() déplacer() Polygone surface() Cercle surface() Carre surface() Analyse des besoins

Héritage multiple Une classe peut hériter de plusieurs super-classes Appareil Appareil Électrique Chauffage PoelA Mazout Chauffage Électrique FourA MicroOndes Certains langages de programmation interdisent l’héritage multiple Analyse des besoins

Points liés à l’héritage et à la classification Les modèles orientés-objets ne font pas tous les mêmes hypothèses Héritage simple vs. héritage multiple Une classe peut elle hériter de plusieurs classes ? Classification simple vs. classification multiple Un objet peut-il être simultanément instance de plusieurs classes? Classification statique vs. classification dynamique Un objet peut-il changer de classe pendant l’exécution ? Analyse des besoins

Points liés à l ’héritage et à la classification Sauf si le contraire est indiqué explicitement, en UML les hypothèses par défaut sont : Héritage multiple une classe peut hériter de plusieurs classes Classification simple un objet est instance d ’une seule classe Classification statique un objet est créé à partir d’une classe donnée et n’en change pas Analyse des besoins

Exemple Personne Femme Homme enfants parents 0..2 * * * mère 0..1 0..1 père épouse époux Femme Homme 0..1 0..1 Analyse des besoins

Exemple Opération Compte date montant solde créditer() débiter() Débit 1 Opération Compte {addOnly,ordered} date montant solde * destinataire créditer() débiter() 1 {montant<0} Débit Crédit {montant>0} Retrait Virement Retrait Espèce CompteEpargne tauxIntérêt ajouterIntérêts () Retrait Guichet Retrait Distributeur 1 * Distributeur Analyse des besoins

Vers une implantation concrète UML : de l ’analyse à la conception détaillée Raffinement successifs, plus ou moins de détails Choix d ’implantation outils utilisés compromis espace mémoire / rapidité d ’exécution … Génération manuelle ou automatique de code génération partielle, squelettes de programme liaison inverse Analyse des besoins

Différentes techniques d’implantation Différentes techniques d ’implantations possibles langage de programmation (de préférence orienté objet) base de données (de préférence orientée objet) ... Respecter les contraintes d ’implantations ex: langage java héritage simple, classification simple et statique pas d ’associations Traduction systématique vs. optimisation Analyse des besoins

Exemple Banque 1 comptes * Il doit y avoir suffisamment d ’argent sur le compte lors d ’un débit * clients Compte 1 * Client numéro solde titulaire nom créditer() débiter() Analyse des besoins

Exemple Banque créerCompte(nom) : int supprimerCompte(numéro) compteNuméro(numéro) : Compte compteClient(nom) : Compte 1 comptes * * clients Compte 1 * Client lireSolde() : int créditer( montant ) débiter( montant ) lireTitulaire() : Client titulaire comptes nom lireBanque() : Banque Analyse des besoins

Exemple Compte - solde : int - decouvertMax : int - titulaire : Client + lireSolde() : int + créditer( montant : int ) { pré-condition : montant >0 post-condition : solde + montant = solde’ } + débiter( montant : int ) { pré-condition : montant >0 et solde-montant > decouvertMax post-condition : solde - montant = solde’ } + lireClient() : client Analyse des besoins

Exemple class Compte { private int solde ; private int découvertMax ; private Client titulaire ; public int lireSolde() { return solde ; } public void débiter( int montant ) { if (montant<=0 || solde-montant < decouvertMax) throw new Exception() ; solde = solde - montant ; } ... } + lireSolde() : int + créditer( montant : int ) + débiter( montant : int ) … Compte - solde : int - decouvertMax : int - titulaire : Client Analyse des besoins

Exemple class Compte { private Vector opérations ; private int découvertMax ; private Client titulaire ; public int lireSolde() { int r = 0 ; for (i=0;opérations.size();i++) r = r = opérations.at(i).montant ; return r ; } public void débiter( int montant ) { if (montant<=0 || lireSolde()-montant < lireSolde) throw new Exception() ; ... } + lireSolde() : int + créditer( montant : int ) + débiter( montant : int ) … Compte - opérations : Vector - decouvertMax : int - titulaire : Client Analyse des besoins