Génie Logiciel avec UML-1-181 PDF

Génie Logiciel Objectifs du cours  Avoir les notions de base du génie logiciel  Maitriser les différents modèles de processus de développement logiciel  Avoir un aperçu sur les méthodes d’analyse des besoins et spécification du logiciel  Acquérir les techniques de conception,...

Génie Logiciel Objectifs du cours  Avoir les notions de base du génie logiciel  Maitriser les différents modèles de processus de développement logiciel  Avoir un aperçu sur les méthodes d’analyse des besoins et spécification du logiciel  Acquérir les techniques de conception, de programmation et de tests de logiciels. Logiciel – définitions  Logiciel: un ensemble d’entités nécessaires au fonctionnement d’un processus de traitement automatique de l’information:  des programmes (en format code source ou exécutables)  des données  des documentations d’utilisation  des informations de configuration. Logiciel = programmes + utilisation Catégories de logiciels Logiciels génériques vendus comme les produits courants.  Logiciels sans impact économique significatif (logiciels amateurs)  Logiciels jetables ou consommables (par exemple les traitements de texte), leur remplacement n’engendrent pas de risque majeur pour l’entreprise. Logiciels spécifiques développés pour une application précise et destinés à un seul client  Logiciels essentiels au fonctionnement d’une entreprise. Ce type de logiciel est le fruit d’un investissement non négligeable et doit avoir un comportement fiable, sûr et sécurisé.  Logiciels vitaux, c’est-à-dire ceux dont dépend la vie d’êtres humains (domaines du transport et de la médecine). Définitions Qualité : Aptitude d'un produit ou d'un service à satisfaire les besoins des utilisateurs. Non qualité : Les défauts apparaissent lors de l'exploitation du logiciel coût de correction élevé Définitions Assurance qualité : C’est l’ensemble des mesures, procédures, méthodes utilisées dans le cadre du processus de développement du logiciel afin d’obtenir le niveau de qualité souhaitée. Manuel qualité : Document décrivant les dispositions générales prises par l'entreprise pour obtenir la qualité de ses produits ou de ses services. EXEMPLE DE SOMMAIRE DU MANUEL QUALITÉ : Gestion de la documentation Gestion des achats et des sous-traitants Audit Gestion des réclamations clients Elaboration d’offre de service Gestion des missions Etc. Définitions Le Manuel Qualité est ensuite validé par l’AFAQ (organisme indépendant de l’entreprise) qui délivre à l’entreprise une certification. Plan qualité logiciel : Document décrivant les dispositions spécifiques prises par une entreprise pour obtenir la qualité du produit ou du service considéré. Définitions Le Manuel Qualité est ensuite validé par l’AFAQ (organisme indépendant de l’entreprise) qui délivre à l’entreprise une certification. Le Manuel qualité est très général, c’est pour cela que l’on rédige un Plan Qualité Logiciel (PQL) au moment du lancement d’un nouveau projet, qui précise les différents intervenants sur le projet (noms, rôles), et les procédures à appliquer dans le cadre de ce projet particulier. Définitions EXEMPLE DE SOMMAIRE DE PQL :  But du projet  Organisation du projet (Décrit la structure du projet, fixe les responsabilités de management etc.)  Documents (Décrit les documents qui seront produits au cours de ce projet)  Standard (Méthodes à utiliser, normes, procédures à suivre)  Qualité (Définitions des moyens qui seront mis en place pour mesurer la qualité du logiciel.  Suivi des problèmes (Méthodes pour suivre les problèmes, les demandes d’actions correctives).  Etc.  Logiciel de qualité Critères côté client  Validité  Efficacité: Efficacité d'exécution, de stockage  Ergonomie  Facilité d’apprentissage  Fiabilité dans le temps  Sécurité: contrôler les accès au code et aux données ou fichiers.  Intégrité Il ne faut pas confondre « intégrité des données » et « sécurité des données ». La sécurité fait référence à la protection des données, tandis que l’intégrité des données désigne leur fiabilité. Critères côté concepteur  Modularité  Réutilisabilité: être partiellement ou totalement utilisé dans une autre application  Lisibilité  Clarté Facilité d’extension et de maintenance  Portabilité: minimiser l’effort pour se faire transporter dans un autre environnement matériel et/ou logiciel.  Compatibilité  Testabilité  Critère de qualité Fiabilité ou Robustesse (fiabilité, sureté) est la capacité qu’offrent des systèmes logiciels à réagir de manière appropriée à la présence de conditions anormales (i.e. rien de catastrophique ne peut survenir, même en dehors des conditions d’utilisation prévues). Solutions : Utiliser des méthodes formelles, des langages et des méthodes de programmation de haut niveau Vérifications, test  Critère de qualité Facilité d’utilisation(Ergonomie) La facilité d’utilisation est la facilité avec laquelle des personnes présentant des formations et des compétences différentes peuvent apprendre à utiliser les produits logiciels et s’en servir pour résoudre des problèmes. Facilité d’apprentissage : comprendre ce que l’on peut faire avec le logiciel, et savoir comment le faire Facilité d’utilisation : importance de l’effort nécessaire pour utiliser le logiciel à des fins données. Solutions : Analyse du mode opératoire des utilisateurs Adapter l’ergonomie des logiciels aux utilisateurs.  Critère de qualité Compatibilité (Interopérabilité ou coulabilité) La compatibilité est la facilité avec laquelle des éléments logiciels peuvent être combinés à d’autres. Un logiciel doit pouvoir interagir en synergie avec d’autres logiciels Solutions : Bases de données (découplage données/traitements) « Externaliser »certaines fonctions en utilisant des « Middleware »avec une API (Application Program Interface) bien définie Standardisation des formats de fichiers (XML...) et des protocoles de communication (CORBA...)  Critère de qualité Efficacité (performance) L’efficacité est la capacité d’un système logiciel à utiliser le minimum de ressources matérielles, que ce soit le temps machine, l’espace occupé en mémoire externe et interne, ou la bande passante des moyens de communication. Les logiciels doivent satisfaire aux contraintes de temps d’exécution Solutions : Logiciels plus simples Veiller à la complexité des algorithmes Machines plus performantes Critère de qualité Portabilité La portabilité est la facilité avec laquelle des produits logiciels peuvent être transférés d’un environnement logiciel ou matériel à l’autre. Un même logiciel doit pouvoir fonctionner sur plusieurs machines Solutions : Rendre le logiciel indépendant de son environnement d’exécution. Machines virtuelles Critère de qualité Réutilisabilité La réutilisabilité est la capacité des éléments logiciels à servir à la construction de plusieurs applications différentes. On peut espérer des gains considérables car dans la plupart des logiciels :  80 % du code est du « tout venant »qu’on retrouve à peu près partout  20 % du code est spécifique Solutions : Abstraction, généricité Construire un logiciel à partir de composants prêts à l’emploi Design Patterns Critère de qualité Maintenabilité La maintenabilité est le degré de facilité de la maintenance d’un produit logiciel. Pourtant, la maintenance absorbe une très grosse partie des efforts de développement (représente 67 % de l’effort de développement) ; Les coûts de maintenance se jouent très tôt dans le processus d’élaboration du logiciel Solution : Réutilisabilté, modularité Vérifier, tester Anticiper les changements à venir.  Critère de qualité Extensibilité L’extensibilité est la facilité d’adaptation des produits logiciels aux changements de spécifications. Intégrité Aptitude d’un logiciel à protéger son code et ses données contre des accès non autorisé. Ponctualité La ponctualité est la capacité d’un système logiciel à être livré au moment désiré par ses utilisateurs, ou avant. Crise du logiciel  Historiquement, il y a eu une prise de conscience dans les années 70, appelée la crise du logiciel, c’est à cette époque que le coût de construction du logiciel est devenu plus important que celui de la construction du matériel.  Constat du développement logiciel fin années 60 :  Délais de livraison non respectés,  Budgets non respectés,  Logiciel ne répondant pas aux besoins de l'utilisateur,  Logiciel difficile à utiliser, maintenir, et faire évoluer. Étude du DoD 1995 Étude du Department of Defense des États-Unis sur les logiciels produits dans le cadre de 9 gros projets militaires: Génie logiciel - définitions  Ensemble des méthodes, des techniques et des outils dédiés à la conception, au développement et à la maintenance des systèmes informatiques,  Un domaine des sciences de l’ingénieur dont l’objet d’étude est la conception, la fabrication, et la maintenance des systèmes informatiques complexes. Génie logiciel - objectifs  Avoir des procédures systématiques pour des logiciels de grande taille afin que:  la spécification corresponde aux besoins réels du client,  le logiciel respecte sa spécification,  les coûts alloués à la réalisation soient respectés,  les délais de réalisation sont respectés.  Le but du génie logiciel est d’optimiser le coût et la qualité de mise en œuvre (développement, évolution et maintien) du logiciel. Exemples d’échecs Exemples d’abandons  Confirm (1992) : projet d’American Airlines de système de réservation commun (avions, voitures, hôtels, etc.). Investissement : 125 M $ sur 4 ans, plus de 200 ingénieurs. Résultat : les différentes parties n’ont pas pu être assemblées en raison de la diversité des méthodes de développement.  Taurus (1993) : projet d’automatisation des transactions pour la bourse de Londres annulé après 5 années de développement. Pertes estimées à 75 M $ pour la société et 450 M $ pour les clients. Exemple de bug  Ariane V (1996) : explosion de la fusée en vol due à une erreur de débordement lors de la conversion d’un nombre flottant 64 bits vers un entier 16 bits. Raisons de la faible qualité des logiciels  Manque de méthodes et d'outils :  Manque de méthodes de conception,  Négligence et manque de méthodes et d'outils des phases de validation/vérification.  Mauvaise compréhension des besoins :  Négligence de la phase d'analyse des besoins du client  Manque d'implication du client dans le processus Raisons de la faible qualité des logiciels Solution à cette crise  Appliquer les méthodes connues de l’ingénierie au domaine du logiciel, pour établir des méthodes fiables sur lesquelles construire une industrie du logiciel.  Il s’agit de se donner un cadre rigoureux pour : 1. Guider le développement du logiciel, de sa conception à sa livraison. 2. Contrôler les coûts, évaluer les risques et respecter les délais. 3. Établir des critères d’évaluation de la qualité d’un logiciel. Génie logiciel  Idée du Génie Logiciel: Appliquer les méthodes classiques d'ingénierie au domaine du logiciel.  Ingénierie (ou génie) : Ensemble des fonctions allant de la conception et des études à la responsabilité de la construction et au contrôle des équipements d'une installation technique ou industrielle.  Exemples d’ingénieries: génie civil, génie aéronautique, génie mécanique, génie chimique... Spécificités du logiciel  La construction d’un logiciel diffère de celle d’un pont :  une modification infime peut avoir des conséquences critiques ;  les progrès technologiques très rapides peuvent rendre un logiciel caduque ;  les domaines des entrées des logiciels sont trop grands pour le test exhaustif ;  les défaillances des programmes sont en général dues à des erreurs humaines ;  chaque logiciel a son organisation et sa logique propre. Les grands principes du génie logiciel  La décomposition des problèmes en sous-problèmes  La modularité  L’anticipation des évolutions  La généricité  La construction incrémentale Principe 1 — décomposition en sous-problèmes  Il s’agit de :  Décorréler les problèmes pour n’en traiter qu’un seul à la fois;  Simplifier les problèmes (temporairement) pour aborder leur complexité progressivement.  Exemple: Comment créer dynamiquement une page internet pour visualiser et modifier le contenu d’une base donnée sans la corrompre ? Décomposition en trois composants :  Modèle pour gérer le stockage des données.  Vue pour formater les données.  Contrôleur pour n’autoriser que les modifications correctes. Principe 2 — la modularité  C’est une instance cruciale du principe de décomposition des problèmes.  Production de composants assemblables et utilisables dans plusieurs réalisations Principe 3 — l’anticipation des évolutions  Un logiciel a un cycle de vie plus complexe que l’habituel : commande → spécification → production → livraison.  La maintenance est la gestion des évolutions du logiciel.  Il est primordial de prévoir les évolutions possibles d’un logiciel pour que la maintenance soit la plus efficace possible. Principe 4 — la généricité Figure : template  Un logiciel réutilisable a beaucoup plus de valeur qu’un composant dédié.  Un composant est générique lorsqu’il est adaptable. Principe 5 — la construction incrémentale  Un développement logiciel a plus de chances d’aboutir s’il suit un cheminement incrémental.  Exemple: Laquelle de ses deux méthodes de programmation est la plus efficace ? 1) Écrire l’ensemble du code source d’un programme et compiler. 2) Écrire le code source d’une fonction ou module, le compiler, et passer à la suivante. Processus de développement logiciel  Processus: un ensemble structuré d’activités qui conduisent à la production d’un logiciel.  En pratique :  Il n’existe pas de processus idéal,  Choix du processus en fonction des contraintes (taille des équipes, temps, qualité...) Cycle de vie d’un logiciel  Activités du développement logiciel :  Analyse des besoins,  Spécification,  Conception,  Programmation (implémentation),  Validation et vérification,  Livraison,  Maintenance (évolution).  Pour chaque activité : Utilisation et production de documents. Analyse des besoins Objectif : Comprendre les besoins du client :  Elle a pour but de dégager le problème à étudier.  Le résultat de l'analyse est le cahier de charges (exprimé dans une langue naturelle) contenant les besoins du futur système.  3 phases:(Faisabilité, Spécifications des besoins, Organisation du projet) Analyse des besoins Besoins du client Cahier des charges ( + manuel d'utilisation préliminaire) Analyse des besoins Faisabilité  Première étape du cycle de vie d’un logiciel  Répondre à deux questions :  Est-ce que le logiciel est réalisable ?  Est-ce que le développement proposé vaut la peine d’être mis en œuvre ? ►► Étudier le marché pour déterminer s’il existe un marché potentiel pour le produit.  Spécification des besoins 39 Permet de définir ce que doit faire le logiciel et non comment il le fait Quatre types de spécifications  Spécifications générales  Spécifications fonctionnelles  Spécifications d’interface  Spécifications techniques  Spécification des besoins: spécification 40 générale La spécification générale consiste à identifier : Objectifs à atteindre. Contraintes (utilisation du matériel et outils existants). Règles de gestion à respecter.  Spécification des besoins: fonctionnelles et 41 interface Spécification fonctionnelles description des fonctionnalités du futur logiciel de manière détaillée que possible Spécification d’interface décrit les interfaces du logiciel avec le monde extérieur : homme (IHM), autres logiciel (Middleware), machines  Spécification des besoins: Spécification 42 technique Spécification technique :(Étude de l’existant)  Moyens d’accès (local, distant, Internet, …)  Temps de réponse acceptable (gestion des GAB, gestion des emplois de temps, …)  Plateforme (Windows, Unix, …)  Quantité d’informations à stocker (choix du SGBDR, …)  Organisation du projet 43 Appelée aussi Planification et gestion de projet Permet de déterminer la manière de développer le logiciel La phase de planification permet de :  découper le projet en tâches  décrire leur enchaînement dans le temps,  affecter à chacune une durée et un effort  Organisation du projet 44 Plusieurs étapes : Analyse des coûts: estimation du prix du projet Planification: calendrier pour le développement (jours ouvrables, jours fériés, nombre d’heures de travail par jours, …) Répartition des tâches: distribuer les tâches et les sous tâches (affectation des ressources aux tâches) Spécification Spécification Cahier des charges Cahier des charges fonctionnel Conception  Objectif : Élaborer une solution concrète réalisant la spécification  Description architecturale en composants (avec interface et fonctionnalités)  Réalisation des fonctionnalités par les composants (algorithmes, organisation des données)  Réalisation des exigences non fonctionnelles (performance, sécurité…) Conception Cahier des charges Dossier de conception fonctionnel Programmation  Objectif : Implantation de la solution conçue.  Choix de l'environnement de développement, du/des langage(s) de programmation, de normes de développement... Programmation Dossier de conception Code documenté + manuel d'utilisation Validation et vérification  Objectifs :  Validation : assurer que les besoins du client sont satisfaits (au niveau de la spécification, du produit fini...) Concevoir le bon logiciel.  Vérification : assurer que le logiciel satisfait sa spécification. Concevoir le logiciel correctement. Validation Cahier des Besoins charges Logiciel du client fonctionnel Vérification  Validation et vérification 49 On distingue plusieurs types de tests : Test unitaire: tester les parties du logiciel par les développeurs Test d’intégration: tester pendant l’intégration des modules Test système: tester dans un environnement proche à celui de production Test alpha: tests faits par le client sur le site de développement Test bêta: tests faits par le client sur le site de production Test de régression: enregistrer les résultats des tests et les comparer avec ceux des anciens versions pour déterminer si la nouvelle n’a pas apporté de dégradation de performance.  Livraison 50 Fournir au client une solution logiciel qui fonctionne correctement. Plusieurs tâches : Installation: rendre le logiciel opérationnel sur le site du client Formation: enseigner aux utilisateurs à se servir de ce logiciel Assistance: répondre aux questions de l’utilisateur Maintenance  Types de maintenance :  Correction : identifier et corriger des erreurs trouvées après la livraison.  Adaptation : adapter le logiciel aux changements dans l'environnement (format des données, environnement d'exécution...).  Perfection : améliorer la performance, ajouter des fonctionnalités, améliorer la maintenabilité du logiciel. Répartition de l'effort processus de développement d’un logiciel Qu’est ce que le processus de développement d’un logiciel? un ensemble structuré d’activités nécessaires pour développer un logiciel Cycle de vie en cascade Le modèle en cascade est une organisation des activités d'un projet sous forme de phases linéaires et séquentielles, où chaque phase correspond à une spécialisation des tâches et dépend des résultats de la phase précédente. Il comprend les phases d'exigences, de conception, de mise en œuvre et de mise en service. Le cycle en cascade Avantages: simple et logique facilité de planification des étapes et des délais adapté à des petits systèmes Cycle de vie en cascade Spécification Cahier des charges fonctionnel Conception Dossier de conception détaillée Implémentation Code documenté + Rapport de tests unitaires Vérification Validation Rapport de validation Livraison et maintenance  Cycle de vie en cascade Le modèle en cascade se base sur des exigences exprimées en début de projet. Toutefois les exigences et besoins peuvent se montrer incomplets ou de qualité insuffisante (ambiguïté, incohérence, etc.). De plus, le client peut ne pas être pleinement conscient de ses besoins avant d'avoir vu le logiciel fonctionner. Ceci peut conduire à revoir:  La conception  Redévelopper un partie du logiciel  Retester le produit et donc augmenter les coûts. C'est pourquoi le modèle en cascade est particulièrement adapté à des projets dont les exigences sont bien comprises et robustes réalisés avec une technologie bien maîtrisée Cycle de vie en cascade — critiques Critiques:Résumé  Aucune validation intermédiaire  Impossibilité de suivre le déroulement du projet, donc de planifier un travail en équipe;  Augmentation des risques car la validation est tardive : erreur d’analyse ou de conception très coûteuse.  Solution limitée aux petits problèmes  Risques bien délimités dès le début du projet;  Projet court avec peu de participants.  Ce modèle est inadapté au développement de systèmes dont la spécification est difficile à formuler a priori. Cycle de vie en V Le cycle en V est un modèle d'organisation des activités d'un projet qui se caractérise par un flux d'activité descendant qui détaille le produit jusqu'à sa réalisation, et un flux ascendant, qui assemble le produit en vérifiant sa qualité. Cycle de vie en V Avantages: facile à comprendre segmente clairement le projet vérifications adaptées à chaque étape Cycle de vie en V - Niveaux de test  Test unitaire : test de chaque unité de programme (méthode, classe, composant), indépendamment du reste du système.  Test d'intégration : test des interactions entre composants (interfaces et composants compatibles).  Test système : test du système complet par rapport à son cahier des charges.  Test d'acceptation (recette) : fait par le client, validation par rapport aux besoins initiaux. Cycle de vie en V : limitations  Un modèle toujours séquentiel  Prédominance de la documentation sur l’intégration : validation tardive du système global;  Maintenance non intégrée : logiciel jetable.  Adapté aux problèmes bien connu  Idéal quand les besoins sont bien connus, quand l’analyse et la conception sont claires Modèle de prototypage  Principe :  Développement rapide d'un prototype avec le client pour valider ses besoins;  Écriture de la spécification à partir du prototype, puis processus de développement linéaire. Cahier Besoins des charges Prototype Logiciel du client fonctionnel  Avantages : Validation concrète des besoins, moins de risques d'erreur de spécification. Modèles incrémentaux  Principe :  Hiérarchiser les besoins du client  Concevoir et livrer au client un produit implantant un sous- ensemble de fonctionnalités par ordre de priorité Spécification Spéc. Spéc. Spéc. Spéc. Conception Conc. Conc. Conc. Conc. Programmation Prog. Prog. Prog. Prog. Validation et vérification V&V V&V V&V V&V Livraison Livr. Livr. Livr. Livr. Développement en cascade Développement incrémental  Modèles incrémentaux  Avantages :  Capture des besoins continue et évolutive;  Détection des erreurs;  Etat d’avancement connecté à la réalité;  Implication des clients/utilisateurs;  Inconvénients :  Explosion des besoins;  Difficile définition de la dimension d’un incrément ; Modèle en spirale Le modèle en spirale (spiral model) est un modèle de Cycle de développement logiciel qui reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et dur. Modèles de processus- Conclusion Quel est le meilleur modèle ? Pas de modèle idéal, tout dépend des caractéristiques de votre projet ! UML Unified Modeling Language Qu’est ce que UML ? UML (Unified Modeling Language) est un langage (et non pas une méthode) qui permet de représenter les modèles. UML propose donc un ensemble de notations pour que chacun ait à sa disposition les éléments nécessaires à la conception d'une application. L'UML n'est pas un langage de programmation, mais il existe des outils qui peuvent être utilisés pour générer du code en plusieurs langages à partir de diagrammes UML. L'UML a une relation directe avec l'analyse et la conception orientées objet. Modèles Un modèle est une représentation partielle de la réalité:  Abstraction de ce qui est intéressant pour un contexte donné.  Vue subjective et simplifiée d'un système.  Avec UML, on va s'intéresser principalement aux modèles d'applications informatiques.  Un modèle UML = des diagrammes UML Utilité des modèles:  Faciliter la compréhension d'un système  Permettre la communication avec le client  Définir voire simuler le fonctionnement d'un système  Vision de développement, de production. Historique UML est né en octobre 1994 chez Rational Software Corporation à l’initiative de G. Booch et de J. Rumbaugh. UML 1.1 a été standardisé par l’OMG (Object Management Group) le 17 novembre 1997 suite à la demande émanant de la collaboration de plusieurs entreprises (Hewlett-Packard, IBM, i- Logix, ICON Computing, IntelliCorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Rational Software Corporation, Reich Technologies, Softeam, Sterling Software, Taskon et Unisys). Les versions se succèdent : Début 1998:UML 1.2 En 1998:UML 1.3 En 2001:UML1.4 En 2003:UML 1.5 En 2005:UML 2.0 Diagrammes d'UML UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes : Diagrammes structurels ou diagrammes statiques  De classes (class diagram)  D'objets (object diagram)  De composants (component diagram)  De structure composite (composite structure diagram)  De déploiement (deployment diagram)  De paquetages (package diagram) Diagrammes de comportement diagrammes dynamiques  De cas d'utilisation (use case diagram)  D'activité (activity diagram)  D'états-transition (state diagram)  De séquence (sequence diagram)  Vue générale d'interaction (interaction overview diagram)  De communication (communication diagram)  De temps (timing diagram) Diagramme d’UML Les diagramme d’UML peuvent être utilisés pour représenter différents points de vues : Vue externe : vue du système par ses utilisateurs finaux Vue logique statique : structure des objets et leurs relations Vue logique dynamique : comportement du système Vue d’implémentation : composants logiciels Vue de déploiement : répartition des composants Diagramme d’UML UML Diagrammes de cas d'utilisation Diagrammes des cas d'utilisation Décrit, sous forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur. Permet de définir les limites du système et ses relations avec l’environnement. Diagrammes des cas d'utilisation Sert à modéliser les aspects dynamiques d'un système Fait ressortir les acteurs et les fonctions offertes par le système. Utilisé pour modéliser les exigences (besoins) du client Diagrammes des cas d'utilisation Comportent plusieurs éléments : Acteurs Cas d'utilisation Relations de dépendances, de généralisations et d'associations Acteurs UML n’emploi pas le terme d’utilisateur mais d’acteur. Le terme acteur ne désigne pas seulement des utilisateurs humains mais également les autres systèmes (machines, programmes, …) Un acteur est un rôle joué par une entité externe qui agit sur le système (Comptabilité, service commercial, …), en échangeant de l’information (en entrée et en sortie) Les acteurs donc peuvent être de trois types : Humains : utilisateurs du logiciel à travers son interface graphique. Logiciels : disponibles qui communiquent avec le système grâce à une interface logicielle (API, ODBC, …) Matériels : exploitant les données du système ou qui sont pilotés par le système (Imprimante, robots, automates, …) Acteurs Remarques La même personne physique peut jouer le rôle de plusieurs acteurs (Chef d’agence est un client de la banque). D’autres part, plusieurs personnes peuvent jouer le même rôle, et donc agir comme un même acteur (plusieurs personnes peuvent jouer le rôle d’administrateur). Acteurs Peut être représenté de deux manières différentes : Petit personnage (stick man) Nom Acteur Classe stéréotypée Nom Acteur  Acteurs Secrétaire Site Web de l'établissement Etudiant Système de Gestion Scolaire Imprimante Acteurs du point de vue système on distingue deux types : Acteurs principaux : utilisent les fonctions principales du système. Par exemple, le client pour un distributeur de billets. Acteurs secondaires : effectuent des tâches administratives ou de maintenance. Par exemple, la personne qui recharge la caisse contenue dans le distributeur.  Acteurs Un acteur peut être une spécialisation d'un autre acteur déjà défini. Acteur général Dans ce cas, on utilise la relation de généralisation/spécialisation. Acteur spécialisé Cas d'utilisation Introduit par Ivar Jacobson en 1992 dans sa méthode Object- Oriented Software Engineering (OOSE). Repris par UML dans la but de : --Effectuer une bonne délimitation du système --Améliorer la compréhension de son fonctionnement interne Cas d'utilisation Les cas d’utilisations Permettent de modéliser les attentes (besoins) des utilisateurs Représentent les fonctionnalités du système Suite d’événements, initiée par des acteurs, qui correspond à une utilisation particulière du système L’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe. Cas d'utilisation Un cas d'utilisation est représenté par une ellipse en trait plein, contenant son nom. Nom Cas Utilisation Structuration des cas d'utilisation Après avoir identifié les acteurs et les cas d'utilisation, il est utile de restructurer l'ensemble des cas d'utilisation que l'on a fait apparaître afin de rechercher les :  Comportements partagés  Cas particuliers, exceptions, variantes  Généralisations/spécialisations. Structuration des cas d'utilisation UML définit trois types de relations standardisées entre cas d'utilisation : Une relation d'inclusion, formalisée par la dépendance «include» Une relation d'extension, formalisée par la dépendance «extend» Une relation de généralisation/spécialisation Relation d'inclusion Lors de la description des cas d'utilisation, il apparaît qu'il existe des sous-ensembles communs à plusieurs cas d'utilisation, il convient donc de factoriser ces fonctionnalités en créant de nouveaux cas d'utilisation qui sont utilisés par les cas d'utilisation qui les avaient en commun. Relation d'inclusion A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B; permet de factoriser des fonctionnalités partagées. Le cas d'utilisation pointé par la flèche (dans notre cas B) est une sous partie de l'autre cas d'utilisation (A, dans notre exemple). B A Relation d'inclusion Les cas d'utilisation "Déposer de l'argent", "Retirer de l'argent", "Effectuer des virements" et "Consulter Retirer de l'argent solde" incorporent de façon explicite le cas d'utilisation "S'authentifier", à un endroit spécifié dans leurs enchaînements. Déposer de l'argent S'authentifier Effectuer des virements Consulter solde Relation d'inclusion On utilise cette relation pour éviter de décrire plusieurs fois un même enchaînement d'actions. Ainsi, on est amené à factoriser un comportement commun à plusieurs cas d'utilisation dans un cas d'utilisation à part. Relation d'inclusion Résumé Une instance du cas source inclut obligatoirement le comportement décrit par le cas d’utilisation destination Permet de décomposer des comportements et de définir les comportements partagées entre plusieurs cas d’utilisation ▬► Factoriser Relation d'extension La relation stéréotypée «extend» permet d'étendre les interactions et donc les fonctions décrites dans les cas d'utilisation, mais sous certaines contraintes. Relation d'extension Le CU source (B) ajoute, sous certaines conditions, son comportement au CU destination (A) En d’autres termes, le CU B peut être appelé au cours de l’exécution du CU A A B Point d'insertion Le comportement ajouté s’insère au niveau d’un point d’extension définit dans le CU destination Relation d'extension Le cas d'utilisation de destination peut fonctionner tout seul, mais il peut également être complété par un autre cas d'utilisation, sous certaines conditions. On utilise principalement cette relation pour séparer le comportement optionnel (les variantes) du comportement obligatoire. Relation d'extension Exemple : Au moment de l'authentification, il se peut que le guichet retient la carte. S'authentifier Retenir la carte Relations d’inclusion VS d'extension La relation « extend" montre une possibilité d'exécution d'interactions qui augmenteront les fonctionnalités du cas étendu, mais de façon optionnelle, non obligatoire, La relation "include" suppose une obligation d'exécution des interactions dans le cas de base. Relation d'héritage Il peut également exister une relation d'héritage entre cas d'utilisation. Cette relation exprime une relation de spécialisation/généralisation au sens classique. Relation d'héritage : Exemple Dans un système d'agence de voyage, un acteur "Touriste" peut participer à un cas d'utilisation de base qui est "Réserver voyage", qui suppose par exemple, des interactions basiques au comptoir de l'agence. Une réservation peut être réalisée par téléphone ou par Internet. Relation d'héritage : Exemple On voit qu'il ne s'agit pas d'une relation "extend", car la réservation par Internet n'étend pas les interactions ni les fonctionnalités du cas d'utilisation "Réserver voyage". Les deux cas d'utilisation "Réservation voyage" et "Réserver voyage par Internet" sont liés : la réservation par Internet est un cas particulier de réservation. De façon générale en objet, une situation de cas particulier se traduit par une relation de généralisation/spécialisation. Relation d'héritage : Exemple Reserver voyage Réserver voyage par téléphone Réserver voyage par Internet Structuration entre cas d’utilisation Résumé Les cas peuvent être structurées par des relations : A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B; permet de factoriser des fonctionnalités partagées A étend B : le cas A est une extension optionnelle du cas B à un certain point de son exécution. A généralise B : le cas B est un cas particulier du cas A. Relations entre cas d’utilisation : Exemple Un client peut effectuer un retrait bancaire. Le retrait peut être effectué sur place ou par Internet. Le client doit être identifié (en fournissant son code d’accès) pour effectuer un retrait, mais si le montant dépasse 500DH, la vérification du solde de son compte est réalisée. Relations entre cas d’utilisation  Intérêts des cas d’utilisation Les CU obligent les utilisateurs à : Définir la manière dont ils voudraient interagir avec le système Préciser quelles informations ils entendent échanger avec le système Décrire ce qui doit être fait pour obtenir le résultat escompté Diagramme des cas d'utilisation Le diagramme des cas d'utilisation regroupe dans un même schéma les acteurs et les cas d'utilisation en les reliant par des relations. Le système étant délimité par un cadre rectangulaire. La représentation de base d'un cas d'utilisation est une ellipse contenant le nom du cas. L'interaction entre un acteur et un cas d'utilisation se représente comme une association.  Diagramme des cas d'utilisation Déposer de l 'argent Reteni r l a carte Cl i ent Reti rer de l 'argent Consul ter l e sol de S'authenti fi er Effectuer des vi rements entre comptes Agent Fourni r un l ogi n et un mot de passe Ravi tai l l er T echni ci en Réparer  Étapes de construction du diagramme des cas d'utilisation Pour modéliser le diagramme des cas d'utilisation, il faut : Identifier les acteurs qui entourent le système. Certains acteurs utilisent le système pour accomplir des tâches, d'autres effectuent des tâches de maintenance ou d'administration. Organiser les acteurs selon une hiérarchisation de généralisation/spécialisation Structurer les cas d'utilisation pour faire apparaître les comportement partagés (relation d'inclusion), les cas particuliers (généralisation/spécialisation) ou options (relation d'extension) Etude de cas(1) Le DAB (Distributeur Automatique de Billet) Un DAB permet à tout détenteur de carte bancaire de retirer de l’argent. Si le détenteur de carte est un client de la banque propriétaire du DAB, il peut en plus consulter les soldes de ses comptes et effectuer des virements entres ces différents comptes. Les transactions sont sécurisées c’est-à-dire : Le DAB consulte le Système d’Information de la banque (S.I. Banque) pour les opérations que désire effectuer un client de la banque (retraits, consultation soldes et virements). Le DAB consulte le Système d’Autorisation Globale Carte Bancaire (Sys. Auto.) pour les retraits des porteurs de cartes non clients de la banque. Le DAB nécessite des opérations de maintenance tel que la recharge en billet, la récupération des cartes avalée, etc. Après discussion avec l’expert métier, il apparaît que l’une des sous fonctions importantes est l’authentification (systématique et commune au 3 cas d’utilisations Retirer de l’argent, Consulter ses soldes et Effectuer un virement). Le DAB permet à son utilisateur d’imprimer un reçu s’il le désire. L’expert métier précise que le DAB sera situé dans une zone internationale et devra donc pouvoir fournir la somme d’argent en Dollars ou en Euros. Modélisez avec un diagramme de cas d’utilisation le fonctionnement de DAB Etude de cas(1) Etude de cas (2) Dans un magasin, un commerçant dispose d’un système de gestion de son stock d’articles, dont les fonctionnalités sont les suivantes : Edition de la fiche d’un fournisseur Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur est automatiquement éditée. Si le fournisseur n’existe pas, on peut alors le créer) Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer l’inventaire, d’effacer un article ou d’éditer la fiche d’un article). Etude de cas (2) Etude de cas (3) On souhaite développer une application informatique qui permet la gestion des emprunts des Cd-rom contenant des jeux vidéo pour les enfants. Un employé s’occupe d’enregistrer les emprunts des adhérents qui veulent emprunter les cd-rom. L’employé doit d’abord s’authentifier pour effectuer cette opération. Chaque cd emprunté doit être rendu à l’employé de la biblio après une durée de 3 jours. L’adhérent donc peut réserver des cd-rom contenant des jeux, chaque réservation doit mentionner l’emprunteur, le jeu et la date de réservation. L’adhérent est averti quand le jeu (cd) revient en rayon. L’employé peut aussi organiser des événements, pour se faire il doit donner les informations suivantes : le nombre minimal et maximal des participants, les jeux à tester, la date de l’événement et l’heure de début de l’événement. L’adhérent qui souhaite participer à un événement peut s’inscrire à condition qu’il y ait encore de la place disponible. Pour se faire il doit saisir un mot de passe et login. Si l’adhérent trouve une place disponible alors il peut payer sa cotisation en ligne par un système de paiement externe. Etude de cas (3)  Description des cas d’utilisation Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs. Mais il n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.  nécessité de décrire ce dialogue Scénario d’un cas d’utilisation Un scénario représente une succession particulière d’enchaînements, s’exécutant du début à la fin du cas d’utilisation, un enchaînement étant l’unité de description de séquences d’actions. Un cas d’utilisation contient en général un scénario nominal et plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d’erreur (qui se terminent en échec). Description des cas d’utilisation Deux façons sont couramment utilisées pour décrire les cas d’utilisation : Description textuelle Description à l’aide d’un diagramme de séquence Description des cas d’utilisation (description textuelle) Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation. Il est recommandé de rédiger une description textuelle, car c'est une forme souple qui convient dans bien des situations. Description des cas d’utilisation (description textuelle) Une description textuelle couramment utilisée se compose de trois parties: 1. La première partie permet d'identifier le cas, elle doit contenir les informations qui suivent. Nom :  Utiliser un verbe à l'infinitif suivi d'un complément. Objectif :  Une description résumée du cas d'utilisation.  Acteurs principaux : ceux qui vont réaliser le cas d'utilisation  Acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas d'utilisation. Dates :  Les dates de création et de mise à jour de la description courante. Responsable :  Le nom des responsables. Version :  Le numéro de version. Description des cas d’utilisation (description textuelle) La deuxième contient toujours une séquence nominale qui décrit de déroulement normal du cas. À la séquence nominale s'ajoutent fréquemment des séquences alternatives (des embranchements dans la séquence nominale) et des séquences d'exceptions (qui interviennent quand une erreur se produit). Les pré conditions : elles décrivent dans quel état doit être le système (l'application) avant que ce cas d'utilisation puisse être déclenché. Des scénarios : ces scénarios sont décrits sous la forme d'échanges d'événements entre l'acteur et le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas d'erreur, des scénario alternatifs qui sont les variantes du scénario nominal et enfin les scénarios d'exception qui décrivent les cas d'erreurs. Des post conditions : elles décrivent l'état du système à l'issue des différents scénarios. Description des cas d’utilisation (description textuelle) La troisième partie de la description d'un cas d'utilisation est une rubrique optionnelle. Elle contient généralement des spécifications non fonctionnelles (spécifications techniques…). Elle peut éventuellement contenir une description des besoins en termes d'interface graphique.  Description textuelle des cas d'utilisation(exemple) Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’ du DAB. Partie 1 : Description. -Titre : Retirer de l’argent. -Résumé : Ce cas d’utilisation permet aux possesseurs de carte bancaire de retire de l’argent. -Acteur principale : Un porteur de carte bancaire. - Acteurs secondaires : Le Système d’Information de la banque et le Système d’Autorisation Globale Carte Bancaire. -Date : 11/01/2020 - Responsable : E. Hamid - Version : 1.0 Description textuelle des cas d'utilisation(exemple) - Partie 2 : Description des scénarios. - Pré-conditions : - Le DAB contient des billets. - Les connexions avec le Système d’Autorisation et le Système d’information de la banque sont opérationnelles. - Scénario nominale : 1) Le Porteur de carte introduit sa carte dans le DAB. 2) Le DAB vérifie que la carte introduite est bien une carte bancaire. 3) Le DAB demande le code de la carte au Porteur de carte. 4) Le Porteur de carte saisit son code. 5) Le DAB compare ce code avec celui qui est codé sur la carte. 6) Le DAB demande une autorisation au Système Globale d’autorisation. 7) Le Système d’Autorisation globale donne son accord et indique le crédit. 8) Le DAB demande le montant désiré au Porteur de carte. 9) Le Porteur de carte saisit le montant. 10) Le DAB vérifie si le montant demandé est inférieur ou égale au crédit. 11) Le DAB rend la carte et demande au Porteur de carte de la retirer. 12) Le Porteur de carte reprend sa carte. 13) Le DAB demande au Porteur de carte s’il désire un ticket. 14) Le Porteur de carte accepte le ticket. 15) Le DAB délivre le ticket et les billets. 16) Le Porteur de carte prend les billets et le ticket. Description textuelle des cas d'utilisation(exemple) -Scénarios alternatifs : Scénario alternatif SA1: Le code est erroné pour la première ou la deuxième fois. SA1 commence au point 5 du scénario nominale. Le DAB indique que le code est erroné. Le DAB enregistre l’échec. Le scénario reprend au point 3 du scénario nominal. Scénario alternatif SA2: Le montant demandé est trop élevé. SA2 commence au point 10 du scénario nominale. Le DAB affiche le montant max et demande au Porteur de carte de ressaisir un montant. Le scénario reprend au point 9 du scénario nominal. Scénario alternatif SA3: Le ticket est refusé. SA1 commence au point 13 du scénario nominale. 14) L’utilisateur refuse le ticket. 15) Le DAB délivre les billets. 16) L’utilisateur prend les billets. Description textuelle des cas d'utilisation(exemple) -Scénarios d’exception: Scénario d’exception SE1: Carte non valide. SE1 commence au point 2 du scénario nominal. Le DAB Indique que la carte n’est pas valide restitue la carte et met fin au cas. Scénario d’exception SE2: Le code est erroné pour la troisième fois. SE2 commence au point 5 du scénario nominal. Le DAB Indique que le code est erroné pour la troisième fois, confisque la carte et met fin au cas. Scénario d’exception SE3: Retrait non autorisé. SE3 commence au point 6 du scénario nominal. Le DAB Indique que tout retrait est impossible, restitue la carte et met fin au cas. Scénario d’exception SE4: Carte non reprise. SE4 commence au point 11 du scénario nominal. Au bout de 30s, le DAB confisque la carte et met fin au cas. Scénario d’exception SE5: Billets non pris. SE5 commence au point 15 du scénario nominal. Au bout de 30s, le DAB reprend les billets et met fin au cas. Scénario d’exception SE6: Annulation de la transaction. SE6 peut démarrer entre les points 4 et 9 du scénario nominal. Le DAB éjecte la carte et met fin au cas. Description textuelle des cas d'utilisation(exemple) -Post-conditions: Les détails de la transaction doivent être enregistrés (montant, numéro carte, date…) aussi bien en cas de succès que d’échec. - Partie 3 : Exigences non fonctionnelles: La saisie du code confidentiel ne doit pas faire apparaître le code à l’écran. Le compte du client ne doit pas être débité tant que le billets n’ont pas été distribués.  Description textuelle des cas d'utilisation(exercice) fonctionnement d’un distributeur automatique de cassettes vidéo Une personne souhaitant utiliser le distributeur doit avoir une carte magnétique spéciale. Les cartes sont disponibles au magasin qui gère le distributeur. Elles sont créditées d’un certain montant en euros et rechargeables au magasin. Le prix de la location est fixé par tranches de 6 heures (1 euro par tranche). Le fonctionnement du distributeur est le suivant : le client introduit sa carte ; si le crédit est supérieur ou égal à 1 euro, le client est autorisé à louer une cassette (il est invité à aller recharger sa carte au magasin sinon) ; le client choisit une cassette et part avec ; quand il la ramène, il l’introduit dans le distributeur puis insère sa carte ; celle-ci est alors débitée ; si le montant du débit excède le crédit de la carte, le client est invité à régulariser sa situation au magasin et le système mémorise le fait qu’il est débiteur ; la gestion des comptes débiteurs est prise en charge par le personnel du magasin. On ne s’intéresse ici qu’à la location des cassettes, et non à la gestion du distributeur par le personnel du magasin (ce qui exclut la gestion du stock des cassettes). Décrivez sous forme textuelle le cas d’utilisation « Emprunter une vidéo » Description textuelle des cas d'utilisation(exercice) Identification Nom du cas : « Emprunter une vidéo ». Objectif: décrire les étapes permettant au client du magasin d’emprunter une cassette vidéo via le distributeur automatique. Acteur principal : Client. Acteur secondaire : néant. Dates: Date de création : le 1/10/2022. Date de mise à jour : Responsable : X. Y. Version : 1 Description textuelle des cas d'utilisation(exercice) Séquencement Le cas d’utilisation commence lorsqu’un client introduit sa carte. Pré-conditions Le client possède une carte qu’il a achetée au magasin Le distributeur est alimenté en cassettes. Enchaînement nominal 1. Le système vérifie la validité de la carte. 2. Le système vérifie que le crédit de la carte est supérieur ou égal à 1 euro. 3. Appel du cas « Rechercher une vidéo ». 4. Le client a choisi une vidéo. 5. Le système indique, d’après la valeur de la carte, pendant combien de temps (tranches de 6 heures) le client peut garder la cassette. 6. Le système délivre la cassette. 7. Le client prend la cassette. 8. Le système rend la carte au client. 9. Le client prend sa carte. Description textuelle des cas d'utilisation(exercice) Enchaînements alternatifs A1 : Le crédit de la carte est inférieur à 1 euro. L’enchaînement démarre après le point 2 de la séquence nominale : 3. Le système indique que le crédit de la carte ne permet pas au client d’emprunter une vidéo. 4. Le système invite le client à aller recharger sa carte au magasin. La séquence nominale reprend au point 8. Description textuelle des cas d'utilisation(exercice) Enchaînements d’exception E1 : La carte introduite n’est pas valide. L’enchaînement démarre après le point 1 de la séquence nominale : 2. Le système indique que la carte n’est pas reconnue. 3. Le distributeur éjecte la carte. E2 : La cassette n’est pas prise par le client. L’enchaînement démarre après le point 6 de la séquence nominale : 7. Au bout de 15 secondes le distributeur avale la cassette. 8. Le système annule la transaction (toutes les opérations mémorisées par le système sont défaites). 9. Le distributeur éjecte la carte. E3 : La carte n’est pas reprise par le client. L’enchaînement démarre après le point 8 de la séquence nominale : 9. Au bout de 15 secondes le distributeur avale la carte. 10. Le système consigne cette erreur (date et heure de la transaction, identifiant du client, identifiant du film). Post-conditions: Le système a enregistré les informations suivantes : La date et l’heure de la transaction L’identifiant du client. L’identifiant du film emprunté.  Description textuelle des cas d'utilisation(exercice) Rubriques optionnelles Contraintes non fonctionnelles Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7. Contrainte liée à l’interface homme-machine Avant de délivrer la cassette, demander confirmation au client. UML DIAGRAMME DE CLASSES Objectifs de diagramme de classes Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation. Le diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation. Le diagramme de classes est la représentation de la structure statique des classes du modèle et de leurs relations. CLASSE ET OBJET Une classe représente la description abstraite d’un ensemble d’objets possédant les mêmes caractéristiques. On peut parler également de type. Exemples : la classe Voiture, la classe Personne. Un objet est une entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement. Un objet est une instance (ou occurrence) d’une classe. Exemple : Ahmed NOURI est un objet instance de la classe Personne. CLASSE ET OBJET Contrôle d'accès à un bâtiment (notion de classe candidate) Suite à la disparition d'objets divers, il a été décidé de restreindre les accès à certaines salles au moyen de portes à fermeture automatique. L'ouverture de chacune des portes est commandée par un lecteur de badges placé à proximité. Les badges qui permettent l'ouverture des portes ne sont délivrés qu'aux personnes qui doivent accéder aux locaux protégés. Le système de contrôle d'accès doit fonctionner de la manière la plus autonome possible. Un superviseur est responsable de la configuration initiale et de la mise à jour des différentes informations de définition des groupes de personnes et de portes. Un gardien dispose d'un écran de contrôle et est informé des tentatives de passage infructueuses. Les alarmes sont transmises en temps légèrement différé sur l'écran de contrôle (mise à jour toutes les minutes). Déterminer les classes candidates. CLASSE ET OBJET classe candidate Suite à la disparition d'objets divers, il a été décidé de restreindre les accès à certaines salles au moyen de portes à fermeture automatique. L'ouverture de chacune des portes est commandée par un lecteur de badges placé à proximité. Les badges qui permettent l'ouverture des portes ne sont délivrés qu'aux personnes qui doivent accéder aux locaux protégés. Le système de contrôle d'accès doit fonctionner de la manière la plus autonome possible. Un superviseur est responsable de la configuration initiale et de la mise à jour des différentes informations de définition des groupes de personnes et de portes. Un gardien dispose d'un écran de contrôle et est informé des tentatives de passage infructueuses. Les alarmes sont transmises en temps légèrement différé sur l'écran de contrôle (mise à jour toutes les minutes). CLASSE ET OBJET classe candidate Il faut corriger la liste : Les salles ne font pas partie du système, seules les portes sont contrôlées. De même pour les locaux. Les informations de définition de groupes de personnes et de portes deviennent les classes Groupe de Personnes et Groupe de portes. L’écran ne permet que l’affichage et ne fait pas partie du système. Les tentatives infructueuses ne sont utiles que si on veut sauvegarder les informations sur les accès non autorisés.  ATTRIBUT ET OPÉRATION Un attribut représente un type d’information contenu dans une classe. Exemples : vitesse courante, cylindrée, numéro d’immatriculation, etc: sont des attributs de la classe Voiture. Une opération représente un élément de comportement (un service) contenu dans une classe.  Représentation graphique des classes avec UML Une classe est représentée par un rectangle divisé en trois compartiments. Le premier compartiment contient le nom de la classe qui : - Représente le type d’objet instancié. - Débute par une lettre majuscule. - Il est centré dans le compartiment supérieur de la classe. - il est écrit en caractère gras. - il est en italique si la classe est abstraite (IMPOSSIBLE d’instancié un objet). Le deuxième compartiment contient les attributs. Le troisième compartiment contient les méthodes. Si la modélisation ne s’intéresse qu’aux relations entre les différentes classe du système (et pas au contenu des classes), nous pouvons ne pas représenter les attributs et les méthodes de chaque classe (nous ne mettons rien dans le deuxième et troisième compartiment). Encapsulation, visibilité L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d'une structure en cachant l'implémentation de l'objet, c'est-à-dire en empêchant l'accès aux données par un autre moyen que les services proposés. Symbole à placer devant Type de visibilité l’attribut ou la méthode public : élément non encapsulé visible par tous. + private : élément encapsulé visible seulement dans la classe. - protected : élément encapsulé visible dans la classe et dans les sous-classes. # package : élément encapsulé visible dans les classes du même paquetage. ~ Les attributs calculés (dérivé) Une classe peut avoir des attributs calculés, c'est-à-dire que leurs valeurs sont proposées au travers d’une fonction utilisant les autres attributs précédemment exprimés. Un tel attribut possède un nom précédé du signe « / » et suivi d’une contrainte permettant de le calculer. Syntaxe des attributs L’attribut doit être inscrit en minuscule mais s’il s’agit d’un nom composé la première lettre de chaque mot peut être mise en majuscule, à l’exception de la première lettre du premier mot : nomDeLAttribut. La Syntaxe pour un attribut est : Visibilité nomAttribut : modificateurs type multiplicité = valeur_initiale Visibilité : + (public) / # (protégé) / - (privé) / ~(package); Modificateurs : const (constant) / static ou nom de l’attribut souligné (statique). Type : boolean / short / int / char / float / double (types primitifs) / autre classe ( type complexe). Multiplicité : [ ] (tableau) / * (pointeur) / & ( référence); Exemples : - i : int pour un attribut privé + pp : PointPlan pour un attribut public tabI : int[*] pour un tableau d’entiers de taille quelconque et à la visibilité non définie tabPP : PointPlans pour un tableau de 4 points exactement et à la visibilité non définie x : float = 0.0 pour un nombre à virgule initialisé à 0 et à la visibilité non définie Syntaxe des méthodes Les règles d’écriture du nom, la spécification de la visibilité et du type de retour s’effectue de la même manière que pour un attribut. Syntaxe Pour une méthode, la syntaxe est : Visibilité nomMéthode (paramètres) : modificateurs type multiplicité Visibilité : + (public) / # (protégé) / - (privé); Paramètres : type primitifs ou complexe de chaque paramètre, séparés par une virgule, éventuellement avec leur nom Modificateurs : const (constant) / static ou nom de la méthode soulignée (statique) / virtual ( virtuelle) / abstract ou nom de la méthode en italique ( abstraite / virtuelle pure); Type : void / boolean / short / int / char / float / double (types primitifs) / autre classe ( type complexe). Multiplicité : [ ] (tableau) / * (pointeur) / & ( référence);  Associations entre classes Une association désigne le cas où une instance d’une classe utilise un objet d’une autre classe en tant qu’attribut objet. Une association représente une relation sémantique durable entre deux classes. Exemple : une personne peut posséder des voitures. La relation possède est une association entre les classes Personne et Voiture. Attention : même si le verbe qui nomme une association semble privilégier un sens de lecture, une association est par défaut bidirectionnelle. Donc implicitement, l’exemple précédent inclut également le fait qu’une voiture est possédée par une personne.  Associations entre classes Comment les représenter ? Aux deux extrémités d’une association, on doit faire figurer une indication de multiplicité. Elle spécifie sous la forme d’un intervalle d’entiers positifs ou nuls le nombre d’objets qui peuvent participer à une relation avec un objet de l’autre classe dans le cadre d’une association. Exemple : une personne peut posséder plusieurs voitures (entre zéro et un nombre quelconque) ; une voiture est possédée par une seule personne. Multiplicité (cardinalité) La multiplicité précise le nombre possible d’instances reliées à l’autre instance dans la relation. Illustration Lecture de la multiplicité coté Client : « Un Compte est la propriété d’un seul Client (rôle ‘propriétaire’ dans la relation) ». On part toujours de la classe opposée, considérée au singulier (« Un Compte »), pour trouver le nb possible d’objets reliés à cette unique instance. Lecture de la multiplicité coté Compte : « Un Client est propriétaire d’un ou plusieurs Compte(s) ».  Multiplicités 1 : la classe est en relation avec un et un seul objet de l’autre classe 1..* : la classe est en relation avec au moins un objet de l’autre classe 0..* : la classe est en relation avec 0 ou n objets de l’autre classe 0..1 : la classe est en relation avec au plus un objet de l’autre classe Une voiture est achetée par une Une personne peut acheter et une seule personne 0 ou n voitures  Navigabilité La navigabilité indique qu'un objet de la classe cible peut être atteint par un objet de la classe source au travers de l'association. En d’autres termes, elle montre s’il est possible de traverser une association. la terminaison du côté de la classe Commande n’est pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste d’objets du type Commande. Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.  Navigabilité Il est beaucoup plus fréquent d’avoir besoin d’une navigabilité unidirectionnelle. Dans ce cas, une seule classe possède un attribut qui fait référence à l’autre classe, ce qui se traduit par le fait que la première classe peut solliciter une deuxième et que l’inverse est impossible (la deuxième classe ne connaît pas la première). Une relation unidirectionnelle peut se représenter de 3 façons différentes : Une croix du coté de l’objet qui ne peut pas être sollicité. Une flèche du coté de l’objet qui peut être sollicité. Les 2 représentations précédentes à la fois.  Navigabilité  Par défaut une association est navigable dans les deux sens Chaque instance de voiture a un lien vers le propriétaire Chaque instance de Personne a un ensemble de lien vers les voitures  Restriction de la navigabilité Le service de contravention est associé à une ou plusieurs voiture(s) Navigable La voiture ne connaît pas service de contravention  Relation de dépendance Une dépendance peut s’interpréter comme une relation de type «utilise un ». Elle est habituellement utilisée lorsqu'une classe utilise un objet d'une autre classe comme argument dans la signature d’une méthode ou alors lorsque l'objet de l'autre classe est créé à l'intérieur de la méthode. Dans les deux cas la durée de vie de l'objet est très courte, elle correspond à la durée d'exécution de la méthode. Notation : Elle est représentée par un trait discontinu orienté, reliant les deux classes. La dépendance est souvent stéréotypée (« use ») pour mieux expliciter le lien sémantique entre les éléments du modèle.  Relation d’associations L’association signifie qu’une classe contiendra une référence (ou un pointeur) de l'objet de la classe associée sous la forme d’un attribut. L’association est représentée par un simple trait continu, reliant les deux classes. Le fait que deux instances soient ainsi liées permet la navigation d’une instance vers l’autre, et vice versa (chaque classe possède un attribut qui fait référence à l’autre classe).  Relation d’associations: détailler l’association Nous pouvons détailler l’association en indiquant : Le nom de l’association : L’association peut être orné d’un texte, avec un éventuel sens de lecture, qui permet de nous informer de l’intérêt de cette relation. Nous rajoutons une phrase courte permettant de préciser le contexte de cette association. Le nom d’une association doit respecter les conventions de nommage des classeurs : commencer par une lettre majuscule.  Relation d’associations: détailler l’association Le rôle : Chaque extrémité d’une association peut être nommée. Ce nom est appelé rôle et indique la manière dont l’objet est vu de l’autre coté de l’association. Lorsqu’un objet A est lié à un autre objet B par une association, cela se traduit souvent par un attribut supplémentaire dans A qui portera le nom du rôle B. (et inversement).  Relation d’associations: Association réflexives Une association qui lie une classe avec elle-même est une association réflexive  Relation d’associations: Contraintes et associations Exemple1: Contrainte entre 2 associations. Contrainte entre 2 associations. En informatique, un raccourci peut concerner soit un répertoire soit un fichier (mais pas les 2 à la fois). Nous pouvons exprimer cela sous la forme d’une contrainte {xor}  Relation d’associations: Contraintes et associations Exemple2: Contrainte sur une association. Un objet de la classe Personne est associé à un objet de la classe Date. La contrainte {frozen} indique que cette association ne peut plus être modifiée une fois instanciée.  Association n-aire Relation n-aire Une association qui lie plus de 2 classes entre elles, est une association n-aire. L’association n-aire se représente par un losange d’où part un trait allant à chaque classe. L’association n-aire est imprécise, difficile à interpréter et souvent source d’erreur, elle est donc très peu utilisée. Exemple 1 : Une séance de cinéma peut correspondre à l’association ternaire de 3 classes.  Classe association Une association peut apporter de nouvelles informations (attributs et méthodes) qui n’appartiennent à aucune des deux classes qu’elle relie et qui sont spécifiques à l’association. Ces nouvelles informations peuvent être représentées par une nouvelle classe attachée à l’association via un trait en pointillés. Exemple : Lorsqu’une personne utilise un téléphone, il faut pouvoir mesurer la durée de l’appel et savoir à quel moment il a lieu afin de le tarifier. Nous ajoutons donc deux attributs durée et période tarifaire qui n’appartiennent ni à la classe Personne ni à la classe Téléphone. Ces deux attributs sont mis dans une nouvelle classe (la classe Appel) qui est attachée à l’association.  Classe association Remarque : Comme pour l’association ternaire, nous pouvons convertir la classe association en un ensemble d’associations binaires.  Classe-association Exemple 2 L'association Emploie entre une société et une personne possède comme propriétés le salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.  Exercice Pour chacun des énoncés suivants, donnez un diagramme des classes:  Tout écrivain a écrit au moins une œuvre  Les personnes peuvent être associées à des universités en tant qu'étudiants aussi bien qu'en tant que professeurs.  Un rectangle a deux sommets qui sont des points. On construit un rectangle à partir des coordonnées de deux points. Il est possible de calculer sa surface et son périmètre, ou encore de le translater. Types de relation : Corrigé  Associations particulières : Contenance Cas particulier d’association exprimant une relation de contenance Exemples: Une voiture a 4 roues Un dessin contient un ensemble de figures géométriques Une présentation PowerPoint est composé de transparents Une équipe de recherche est composée d’un ensemble de personnes Deux types de relations de contenance en UML Agrégation Composition (Agrégation forte)  Contenance: Agrégation Type de relations A B A « contient » des instances de B, Propriétés de l’agrégation Agrégat La suppression de A n’implique pas la suppression de B L'élément agrégé peut être partagé Exemples : L’enseignant est un composant d’une (ou plusieurs) équipe de recherche d’un seul département La disparition d’une équipe de recherche n’entraine pas la disparition d’un enseignant  Contenance: Composition La suppression de A entraine la suppression de B Exemple: « Une présentation PowerPoint est composé de transparents » La suppression de la présentation entraine la disparition des transparents qui la compose  Associations : Héritage permet de créer une nouvelle classe à partir d'une classe existante Principe classe dérivée contient les attributs et les méthodes de sa superclasse Spécialisation Généralisation étendre les propriétés factoriser les propriétés d'une classe, sous groupe de classes sous forme de sous-classes forme de super-classe Chaque personne de l’université est identifiée par son nom, prénom Les étudiants ont plus un noEtudiant Les enseignants ont un numéro de téléphone interne Diagramme de classes  Implémentation : Associations public class Personne { public String Nom; public String prenom; public java.util.Collection voiture = new java.util.TreeSet(); } public class Voiture { public String immatriculation; public Personne Propriétaire; public void demarer() { } } public class ServiceContraventions { public java.util.Collection Voiture = new java.util.TreeSet(); }  Implémentation : Composition &Agrégation Composition final class Car { Dans le cas de la composition, le Moteur est private final Engine engine; complètement encapsulé par la Voiture. Il n'y a aucun moyen pour le monde extérieur Car(EngineSpecs specs) { d'obtenir une référence au moteur. Le engine = new Engine(specs); } Moteur vit et meurt avec la voiture. void move() { engine.work(); } } Agrégation final class Car { Avec l'agrégation, la voiture remplit également private Engine engine; ses fonctions à travers un moteur, mais le moteur n'est pas toujours une partie interne de la void setEngine(Engine engine) { this.engine = engine; voiture. Les moteurs peuvent être échangés, ou } même complètement enlevé. Pas seulement ça, void move() { mais le monde extérieur peut encore avoir une if (engine != null) référence au moteur, et bricoler avec lui, qu'il soit engine.work(); dans la voiture ou pas. } }  Exercices Exercice 1: Soit un système d'information qui concerne le suivi des personnels d'un ensemble d'agences locales. Chaque agence se trouve dans une région, chaque région est pilotée par une direction régionale. La direction régionale se charge d'un ensemble d'agences locales. une direction régionale est caractérisée par un code et un libellé. Modélisez cette situation par un diagramme de classe. Exercices  Exercices Exercice 2: Soit un document composé d'un ou plusieurs feuillets. Le feuillet comporte des objets géo et des texte. Les objets graphique supportent des opérations de type : sélectionner, copier, couper, coller et déplacer. On suppose les deux objets géométriques suivants: cercle et rectangle. Modélisez cette situation par un diagramme de classe (utiliser la notion d'héritage, composition et agrégation). Exercices  Exercices Exercice 3: Dans une société de transport, on voudrait gérer les bus de ramassage scolaire et les conducteurs. Un lycéen est un enfant, il est caractérisé par son nom, son âge et son sexe. Les informations qui caractérisent le conducteur sont les mêmes que pour le lycéen, avec en plus le numéro de son permis. Quant au bus, on a besoin de connaître son numéro d’immatriculation, sa date de mise en service, nombre d’années de service, et le poids total. Un bus est composé d’une carrosserie (poids, couleur), de 6 roues (pression, diamètre), de plusieurs sièges (couleur) pour passagers, plusieurs vitres (épaisseur, poids). Présentez le diagramme de classes adéquat. Exercices  Exercices Exercice 4: Un hôtel est composé d'au moins deux chambres. Chaque chambre dispose d'une salle d'eau : douche ou bien baignoire. Un hôtel héberge des personnes. Il peut employer du personnel et il est impérativement dirigé par un directeur. On ne connaît que le nom et le prénom des employés, des directeurs et des occupants. Certaines personnes sont des enfants et d'autres des adultes (faire travailler des enfants est interdit). Un hôtel a les caractéristiques suivantes : une adresse, un nombre de pièces et une catégorie. Une chambre est caractérisée par le nombre et de lits qu'elle contient, son prix et son numéro. On veut pouvoir savoir qui occupe quelle chambre à quelle date. Pour chaque jour de l'année, on veut pouvoir calculer le loyer de chaque chambre en fonction de son prix et de son occupation (le loyer est nul si la chambre est inoccupée). La somme de ces loyers permet de calculer le chiffre d'affaires de l'hôtel entre deux dates. Question : Donnez un diagramme de classes pour modéliser le problème de l'hôtel. Exercices