La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Analyse Des Besoins Introduction à la Notation UML DESS CCI Cours de Génie Logiciel Tronc Commun Octobre – Décembre 2000 Jean-Marie Favre."— 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 2Analyse des besoins 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, à lUniversité Joseph Fourier. Il sagit de la première partie de ce cours, dictée par Jean-Marie Favre. Certains transparents nont pas été présentés. Certaines parties du cours se sont déroulées sans transparents. Lordre des transparents et le découpage du cours est lié intimement au calendrier de lannée 2000 et à des contraintes de précédence entre le cours et les travaux dirigés. Pour plus dinformation nhesitez pas à me contacter :

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

4 4Analyse des besoins 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 ?

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

6 6Analyse 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%

7 7Analyse des besoins Origine du terme "Génie Logiciel" 1968 : "1 st 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 dingénierie ?

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

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

10 10Analyse 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.

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

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

13 13Analyse 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 (1) Artisanat (2) Production (3) Commerce (4) Science (5) Ingénierie 1950 – 1960 programmation ad-hoc cas isolés : compilateurs, logiciels critiques, : théorie des langages 1960 : algèbre relationnelle 1970 : crise du logiciel 1980 : méthodes de développement...

14 14Analyse 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...

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

16 16Analyse des besoins Echecs logiciels 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. A r i a n e 5 $ Out of range

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

18 18Analyse des besoins Importance grandissante du logiciel MATERIEL LOGICIEL 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

19 19Analyse 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" !

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

21 21Analyse des besoins Approches Gestion du produit et des ressources –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...

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

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

24 24Analyse des besoins 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 -

25 25Analyse 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 nest pas le bon résultat ! » –« Je vous avais dis que je voulais ça ! » –...

26 26Analyse des besoins Causes Le client ne sais pas ce quil veut Le client ne sais pas exprimer ce quil veut Linformaticien ne comprend pas client Le client ne comprend pas linformaticien Ce que le client veut nest pas ce quil voulait

27 27Analyse 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é

28 28Analyse 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 nest pas encore formalisé

29 29Analyse 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)

30 30Analyse des besoins Différentes étapes Capture 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

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

32 32Analyse 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 lordre du jour –prendre des notes –faire systématiquement des comptes rendus écrits

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

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

35 35Analyse 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, …

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

37 37Analyse 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 !

38 38Analyse des besoins Format du dictionnaire NotionDéfinition Nom info.Type entité Pilotage Action de piloter un avion en enchaînant des manœuvres élémentaires Pilotagepaquetage Instrument Organe d'interaction entre le pilote et l'avion Instrumentclasse abstraite Manche à balai Instrument permettant au pilote de diriger l'avion MancheABalaiclasse ActionDéfinition Nom info.Type entité Augmenter les gaz Action permettant d'injecter du carburant pour augmenter la vitesse de l'avion IncrGazopération

39 39Analyse 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é

40 40Analyse 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 !

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

42 42Analyse 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…

43 Le langage UML : une vision globale

44 44Analyse des besoins UML = Unified Modeling Language 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,...

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

46 46Analyse des besoins Historique : apparition de nombreuses méthodes : + 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 :...

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

48 48Analyse des besoins Diagrammes des cas d utilisation SystèmeDeContrôleDAcces Capteur AIncendie PorteurDeCarte EntrerDébloquerLesPortesGérerLesCartes Administrateur ListerLes TentativesDeFraudes Gardien Sortir

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

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

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

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

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

54 54Analyse 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 !

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

56 UML : Diagrammes de Cas dUtilisation Acteurs, Cas dutilisation, Système Diagrammes de Cas dutilisation Modèle de Cas dutilisation Scénario

57 57Analyse des besoins 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

58 58Analyse des besoins Exemple de diagrammes de cas d utilisation RetirerDeLArgentAu Distributeur ConsulterUnCompteDeposerDeLArgent SurUnCompte RetirerDeLArgent DUnCompte Client Guichetier Système bancaire Directeur GererLesPretsCréerUnCompte

59 59Analyse des besoins Exemple de diagrammes de cas d utilisation DistributeurDeBillet Banque Centrale Client RetirerDeLArgentAu Distributeur ConsulterSonCompteAssurer LaMaintenance Technicien Ajouter DesBillets Transporteur DeBillets

60 60Analyse des besoins Exemple de diagrammes de cas d utilisation SystèmeDeContrôleDAcces Capteur AIncendie PorteurDeCarte EntrerDébloquerLesPortesGérerLesCartes Administrateur ListerLes TentativesDeFraudes Gardien Sortir

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

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

63 63Analyse des besoins Le système Le système est un ensemble de cas dutilisation 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. Système

64 64Analyse des besoins Acteurs Un Acteur = –élément externe qui interagit avec le système –rôle quun 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 nest pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur Client

65 65Analyse des besoins Différents types d acteurs 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 Client

66 66Analyse des besoins Description des acteurs Pour chaque acteur : –choisir un identificateur représentatif de son rôle –donner une brève description textuelle Client Guichetier Un guichetier est un employé de la banque chargé de faire linterface entre le système informatique et les clients quil 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.

67 67Analyse des besoins Utilité des acteurs La définition dacteurs permet surtout –de trouver les cas dutilisation 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 daccès par type dacteur, –fixer des ordres de priorités entre acteurs, –... Client

68 68Analyse des besoins Description des cas dutilisation 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 lacteur Les cas d utilisation ne doivent pas se chevaucher CasDUtilisationX

69 69Analyse des besoins Exemple de description d un cas d utilisation CasDUtilisationX Retirer DeLArgent AuDistributeur Lorsquun 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

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

71 71Analyse des besoins Description du modèle de cas d utilisation Un modèle de cas dutilisation peut contenir –plusieurs diagrammes –plusieurs descriptions textuelles Permet davoir 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

72 72Analyse des besoins Exemple de diagramme de CU décoré RetirerDeLArgentAu Distributeur ConsulterUnCompteDeposerDeLArgent SurUnCompte RetirerDeLArgent DUnCompte Client GuichetierDirecteur GererLesPretsCréerUnCompte Système bancaire P1 P2 Pi : priorité 12/07/99 20/05/99 P1 P3 P2 25/12/99 10/12/00 10/06/00

73 73Analyse des besoins Description détaillée de chaque cas dutilisation 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 –...

74 74Analyse 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 derreurs Les interactions entre le système et les acteurs Les informations échangées Les éventuels besoins non fonctionnels

75 75Analyse des besoins Exemple de description détaillée d un CU Retirer DeLArgent AuDistributeur Précondition : Le distributeur contient des billets, il est en attente d une opération, il nest 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 dargent sur le compte est égale à la somme d argent quil y avait avant, moins le montant du retrait. Sinon la somme d argent sur le compte est la même quavant.

76 76Analyse des besoins Exemple de description détaillée d un CU Retirer DeLArgent AuDistributeur 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)...

77 77Analyse des besoins Exemple de description détaillée d un CU Retirer DeLArgent AuDistributeur 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...

78 78Analyse 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 dun CU

79 79Analyse des besoins Exemple de scénario Retirer DeLArgent AuDistributeur 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...

80 80Analyse des besoins Diagrammes de séquences Pour décrire un scénario : diagramme de séquence Diagramme de séquences : –Lune 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 : lacteur et le système

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

82 82Analyse des besoins Le Processus Unifié (1) Définir le modèle de cas dutilisation (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)

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

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

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

86 86Analyse des besoins Vagues des matériels informatiques Research Mainframe Commercial Mainframes Internet, Ubiquitous Computing Commercial Mini Computers Personal Computers

87 87Analyse des besoins Vagues des techniques de structuration StatementFunction Framework ?1945 ModuleObject

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

89 89Analyse des besoins La vague de « lOrienté 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

90 90Analyse des besoins Orienté Objet Représenter un système comme un ensemble dobjets 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 lobjet reçoit un message

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

92 92Analyse 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…

93 93Analyse 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 = solde = 2000 découvert max = -500 le compte de Paul ConsulterSolde Créditer Débiter le compte de Pierre numéro = solde = 10 découvert max = -100 ConsulterSolde Créditer Débiter

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

95 95Analyse des besoins Principe dencapsulation Chaque objet indique les méthodes quil expose (son interface) ex: on sait que le distributeur permet de retirer de largent mais cache la réalisation concrète des méthodes ex: on sait pas ce que fait le distributeur de manière interne lorsquil reçoit le message retirer de largent et nexpose 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 lattribut solde

96 96Analyse des besoins Avantages du principe dencapsulation Un client ne connaît que linterface de lobjet –lobjet est plus simple à comprendre ex: pas la peine de comprendre le contenu d un magnétoscope pour pouvoir l utiliser. –lobjet plus simple à réutiliser ex: si linterface 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...

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

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

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

100 100Analyse des besoins Exemple de classification le distrib. D11 le compte de Paul une banque paul pierre le compte de Pierre marie le compte de Pierre et de Mariejohn ClientCompteBanqueDistributeur le distrib. D28 Niveau des classes Niveau des objets

101 101Analyse des besoins Avantages du principe de classification Modèle plus simple –il y a beaucoup moins de classes que dobjets –les objets dune même classe sont similaires –lensemble des classes ne change pas pendant lexé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 dobjets Modèle réutilisable –une classe est un composant logiciel réutilisable

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

103 103Analyse des besoins 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 dobjets (description au niveau instance)

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

105 105Analyse des besoins Notations simplifiées pour les classes 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 numéro solde... Compte créditer() débiter()... Compte Conventions : les noms de classes commencent par une majuscule les noms d attributs et de méthodes commencent par une minuscule

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

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

108 108Analyse des besoins Rôles c1 : Compte pierre : Client APourCompte> titulairecompte Chacun des deux objets joue un rôle diffèrent dans le lien 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 pierre assume le rôle de titulaire pour le compte c1 c1 assume le rôle de compte pour pierre

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

110 110Analyse des besoins Liens vs. Associations Un lien lie deux objets Une association lie deux classes Un lien est une instance dassociation 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

111 111Analyse des besoins Cardinalités dune association Précise combien dobjets peuvent être liés à un seul objet source Cardinalité minimale et cardinalité maximale ( C min..C max ) ClientCompte 1 c1 : Compte c2 : Compte paul : Client pierre : Client marie : Clientc3 : Compte APourCompte> 0..* titulairecomptes « Un client a 0 ou plusieurs comptes » « Un compte a toujours 1 et 1 seul titulaire »

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

113 113Analyse des besoins Contraintes entre associations Client Compte numéro solde * titulairePrincipal co-titulaires0..* titulaires1..*0..* (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 Les cardinalités ne permettent pas dexprimer toutes les contraintes... … décrire les contraintes en langue naturelle (ou en OCL le langage de contrainte dUML)

114 114Analyse des besoins Diagramme de classes Client * titulaires Consortium Compte numéro solde * Banque numéro nom Distributeur 0..* 1 1..* signataire 1 0..* CarteBleue Code retraitMax 1..* EstAcceptéPar > (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. virementPossible 0..*

115 115Analyse des besoins Diagrammes dobjets c1 : Compte c2 : Compte paul : Client pierre : Client marie : Clientc3 : Compte titulaires : CarteBleue titulaires signataire : CarteBleue sophie : Client : Banque fred : Clientc4 : Compte titulaires : Banque signataire : Consortium : Distributeur : CarteBleue signataire : Distributeur EstAcceptéPar>

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

117 117Analyse des besoins Diagrammes de classes vs. dobjets Client * titulaires Consortium Compte numéro solde * Banque numéro nom Distributeur 0..* 1 1..* signataire 1 0..* CarteBleue Code retraitMax 1..* EstAcceptéPar > virementPossible 0..* titulairestitulaires titulairestitulaires :Banque:Banque signatairesignataire : Di stri but eu r : Co mp te : Cli ent : Co mp te titulairestitulaires : titulairestitulaires : : Cli ent :Banque:Banque :Banque:Banque ::: Co ns orti um : Di stri but eu r : : > > >... : Co mp te : Cli ent : Co mp te titulairestitulaires : titulairestitulaires : : Cli ent :Banque:Banque :Banque:Banque ::: Co ns orti um : Di stri but eu r : : > > > : Co mp te : Cli ent : Co mp te titulairestitulaires : titulairestitulaires : : Cli ent :Banque:Banque :Banque:Banque ::: Co ns orti um : Di stri but eu r : : > > > t1t1 t2t2 t3t3

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

119 119Analyse des besoins Exemple PersonneSociété 1..*0..1 employés directeur 0..1 * subordonnés (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...

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

121 121Analyse des besoins Navigation ClientCompte 1 titulaire Association unidirectionnelle On ne peut naviguer que dans un sens Ce détail nest a priori utile que lors de la conception détaillée

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

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

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

125 125Analyse des besoins Classes associatives PersonneSociété employé * 0..2 Dans certains cas il est utile dassocier des attributs et/ou des méthodes aux associations => classes associatives Emploi salaire augmenter() Le nom de la classe correspond au nom de lassociation société

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

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

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

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

130 130Analyse 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. PersonneSociété employé * Emploi salaire augmenter() société responsable subordonnés * 0..1 *

131 131Analyse 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 RelevéDe Compte Ligne Opération * {ordered,addOnly} lignes Il est possible de définir de nouvelles contraintes

132 132Analyse des besoins Synthèse sur les associations

133 133Analyse 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 Sous classes Personne FemmeHomme Compte Compte Epargne

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

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

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

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

138 138Analyse des besoins Points liés à lhé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 lexécution ?

139 139Analyse 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 dune classe donnée et nen change pas

140 140Analyse des besoins Exemple FemmeHomme épouseépoux 0..1 Personne mère père 0..1 ** parents0..2 enfants *

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

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

143 143Analyse des besoins Différentes techniques dimplantation 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

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

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

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

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

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


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

Présentations similaires


Annonces Google