Analyse Des Besoins Introduction à la Notation UML

Présentation au sujet: "Analyse Des Besoins Introduction à la Notation UML"— Transcription de la présentation:

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

2 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 : Analyse des besoins

3 Du "codeur" ... au "programmeur" … à "l'ingénieur logiciel"
Génie Logiciel Du "codeur" ... au "programmeur" … à "l'ingénieur logiciel"

4 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

5 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

6 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 % Utilisés tel quel $0.1M % Analyse des besoins

7 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

8 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

9 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

10 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

11 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

12 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 : rationalisation opérations unitaires alchimie pierre philosophale 100 ans Analyse des besoins

13 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

14 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

15 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

16 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 : erreur dans le système de contages des votes du parlement => nouvelles éléctions etc, etc. 5 e n a i r A $ Out of range Analyse des besoins

17 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

18 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

19 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

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

21 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

22 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

23 Analyse des besoins Problématique Capture des besoins
Définition des besoins (Spécification des besoins)

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 Le langage UML : une vision globale

44 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

45 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

46 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

47 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

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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 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

57 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

58 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

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

60 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

61 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

62 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

63 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

64 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

65 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

66 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

67 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

68 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

69 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

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

71 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

72 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

73 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

74 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

75 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

76 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

77 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

78 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

79 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 fr Le système vérifie s ’il y a assez d ’argent sur le compte ... Retirer DeLArgent AuDistributeur Analyse des besoins

80 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

81 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

82 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

83 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

84 Approche orientée-objet
Objets, Classe Attribut, Méthode, Message Réification, Encapsulation, Classification

85 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

86 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

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

88 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

89 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

90 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

91 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

92 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

93 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

94 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

95 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

96 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

97 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

98 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

99 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

100 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

101 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

102 UML : Diagrammes de Classes
Objet, Classe, Attribut, Méthode Lien, Association, Cardinalité Généralisation, Spécialisation Composition Composition, Classe Associative, …

103 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

104 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

105 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

106 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

107 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

108 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

109 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

110 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

111 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

112 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

113 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

114 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

115 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

116 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

117 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

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

119 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

120 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

121 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

122 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

123 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

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

125 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

126 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

127 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

128 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

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

130 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

131 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

132 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

133 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

134 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

135 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 > et tauxIntérêt < 100} ajouterIntérêts () {tauxIntérêt < 100} Analyse des besoins

136 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

137 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

138 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

139 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

140 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

141 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

142 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

143 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

144 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

145 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

146 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

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

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