Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Méthode de conception orientée objet http://www.docsflood.com 1 Plan • Présenta

Méthode de conception orientée objet http://www.docsflood.com 1 Plan • Présentation d’UML • Les cas d’utilisation • Les diagramme de classes et diagrammes d’objets • Les diagrammes d’états-transitions • Les diagrammes d’activités • Les diagrammes de séquences • Les diagrammes de communication http://www.docsflood.com 2 Présentation d’UML • Les méthode systémiques comme Merise ont marqué une première évolution dans les années 80 autour des idées de SI, de bases de données, de niveaux de modélisation (conceptuel, organisationnel, logique, physique) et de séparation données- traitements. • Depuis la fin des années 90, l’ACSI connaît une deuxième évolution autour des idées d’objet (regroupant données et traitement), de réutilisation (code et conception). http://www.docsflood.com 3 Présentation d’UML • La démarche ne constitue plus à réécrire un modèle d’un certain niveau dans les termes du niveau suivant au moyen de règles de traduction. • On passe d’un niveau à un autre par enrichissement des éléments existants et adjonction d’éléments nouveaux, en conservant le même formalisme. http://www.docsflood.com 4 Histoire L’apparition du paradigme objet a permis la naissance de plusieurs méthodes de modélisation OMT (Object Modeling Technique), OOSE (Object Oriented Software Engineering), Booch, … Chacune de ces méthodes fournie une notation graphique et des règles pour élaborer les modèles http://www.docsflood.com 5 Présentation d’UML Entre 89 et 94 : le nombre de méthodes orientées objet est passé de 10 à plus de 50 Toutes les méthodes avaient pourtant d’énormes points communs (objets, méthode, paramètres, …) Au milieu des années 90, G. Booch, I. Jacobson et J. Rumbaugh ont chacun commencé à adopter les idées des autres. Les 3 auteurs ont souhaité créer un langage de modélisation unifié http://www.docsflood.com 6 Présentation d’UML - Histoire http://www.docsflood.com 7 Présentation d’UML - Histoire Les différents diagrammes d’UML Un Diagramme est une représentation graphique d'un ensemble d'éléments et de relations qui constituent un système. • UML définit neuf types de diagrammes divisés en deux catégories : 1.diagrammes statiques (appelés aussi diagrammes structurels) : diagrammes de classes, d'objets, de composants, de déploiements et de cas d'utilisation. 2.diagrammes dynamiques (appelés aussi diagrammes comportementaux) : diagrammes d'activités, de séquences, d'états-transitions et de collaborations. http://www.docsflood.com 8 Les cas d’utilisation (use cases) • Un cas d’utilisation représente un ensemble de séquence d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. • Diagramme de cas d’utilisation (use case): il représente les interactions entre le système et les acteurs. http://www.docsflood.com 9 Acteur • Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. • Un acteur peut consulter et/ou modifier l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données. http://www.docsflood.com 10 Les cas d’utilisation • La même personne physique peut jouer le rôle de plusieurs acteurs. • D’autre part, plusieurs personnes peuvent jouer le même rôle, et donc agir comme un même acteur. http://www.docsflood.com 11 Les cas d’utilisation - Acteur comment identifier les acteurs • Les acteurs candidats sont systématiquement : oLes utilisateurs humains directs : faites donc en sorte d’identifier tous les profils possibles, sans oublier l’administrateur, l’opérateur de maintenance, etc. oLes autres systèmes connexes qui interagissent aussi directement avec le système étudié http://www.docsflood.com 12 Les cas d’utilisation - Acteur comment représenter les acteurs • La représentation graphique standard de l’acteur en UML est l’icône appelé « stick man », avec le nom de l’acteur sous le dessin. http://www.docsflood.com 13 Les cas d’utilisation - Acteur • Autres représentations sont possibles : (1) http://www.docsflood.com 14 comment représenter les acteurs • Autres représentations sont possibles : (2) http://www.docsflood.com 15 comment représenter les acteurs • Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme graphique du "stick man" pour les acteurs humains et une représentation rectangulaire pour les systèmes connectés. http://www.docsflood.com 16 comment représenter les acteurs comment identifier les cas d’utilisation • L’objectif est le suivant : l’ensemble des cas d’utilisation doit décrire exhaustivement les exigences fonctionnelles du système. • Chaque cas d’utilisation correspond donc à une fonction métier du système, selon le point de vue d’un de ses acteurs. http://www.docsflood.com 17 Les cas d’utilisation • Pour chaque acteur, il convient de : Rechercher les différentes intentions métier avec lesquelles il utilise le système Déterminer dans le cahier des charges les services fonctionnels attendus du système. Nommer les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du point de vue de l’acteur (et non pas du point de vue du système). http://www.docsflood.com 18 comment identifier Les cas d’utilisation Les cas d’utilisations :comment les analyser Pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente consiste à recenser de façon textuelle toutes les interactions entre les acteurs et le système. • Le cas d’utilisation doit avoir un début et une fin clairement identifiés. • Il faut également préciser les variantes possibles, telles que le cas nominal, les différents cas alternatifs et d’erreurs, tout en essayant d’ordonner séquentiellement les descriptions, afin d’améliorer leur lisibilité. http://www.docsflood.com 19 Les cas d’utilisation :comment les représenter • Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs (icône du « stick man » ou représentation graphique équivalente). • Chaque association signifie simplement « participe à » • Un cas d’utilisation doit être relié à au moins un acteur. http://www.docsflood.com 20 http://www.docsflood.com 21 comment représenter Les cas d’utilisation Les cas d’utilisation scénario Une fois les cas d’utilisation identifiés, il faut encore les décrire. • Scénario : 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 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). http://www.docsflood.com 22 • On peut d’ailleurs proposer une définition différente pour un cas d’utilisation : « ensemble de scénarios d’utilisation d’un système reliés par un but commun du point de vue d’un acteur » http://www.docsflood.com 23 Les cas d’utilisation - scénario Les cas d’utilisation :fiche de description • La fiche de description textuelle d’un cas d’utilisation n’étant pas normalisée par UML, on peut adopter la structuration suivante : http://www.docsflood.com 24 Sommaire d’identification (obligatoire) Inclut titre, résumé, date de création et de modification, version, responsable, acteurs… Description des scénarios (obligatoire) Décrit le scénario nominal, les scénarios (ou enchaînements d’erreur), mais aussi les préconditions et les postconditions. Exigences non- fonctionnelles (optionnel) Ajoute, si c’est pertinent, les informations suivantes : fréquence, volumétrie, disponibilité, fiabilité, intégrité, confidentialité, performances, concurrence, etc. Précise également les contraintes d’interface homme-machine comme des règles d’ergonomie, une charte graphique, etc. Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) • Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque (GAB), Le GAB offre les services suivants : 1.Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de cartes et un distributeur de billets. 2.Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une carte de crédit de la banque adossée au GAB. http://www.docsflood.com 25 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) N’oubliez pas non plus que : 3.Toutes les transactions sont sécurisées. 4.Il est parfois nécessaire de recharger le distributeur, etc. http://www.docsflood.com 26 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) • À partir de ces quatre phrases, nous allons progressivement : •Identifier les acteurs; •Identifier les cas d’utilisation; •Construire un diagramme de cas d’utilisation. http://www.docsflood.com 27 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) •Question : •Identifier les acteurs http://www.docsflood.com 28 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Étape 1 : Identification des acteurs du GAB • Quelles sont les entités externes qui interagissent directement avec le GAB ? http://www.docsflood.com 29 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Porteur de carte Lecteur de cartes Distributeur de billets Carte bancaire Client banque Les transactions sont sécurisées Opérateur de maintenance http://www.docsflood.com 30 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Porteur de carte (externe) Lecteur de cartes (interne) Distributeur de billets (interne) Carte bancaire (externe) Client banque (externe) Les transactions sont sécurisées (par des externes) Opérateur de maintenance (externe) http://www.docsflood.com 31 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Porteur de carte (externe) Lecteur de cartes (interne) Distributeur de billets (interne) Carte bancaire (externe) Client banque (externe) Les transactions sont sécurisées (par des externes) Opérateur de maintenance (externe) http://www.docsflood.com 32 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Porteur de carte (externe) Lecteur de cartes (interne) Distributeur de billets (interne) Carte bancaire (externe) Client banque (externe) Les transactions sont sécurisées (par qui ?) Opérateur de maintenance (externe) http://www.docsflood.com 33 Les cas d’utilisation - Etude de cas Etude d’un guichet automatique de banque (GAB) Porteur de carte Client uploads/Philosophie/ 7478-cour-uml-tutoriel-pdf.pdf