Démarche d application d UML

Transcription

1 Démarche d application d UML Comment bien utiliser UML? Bonnes pratiques Avertissement Il n y a pas UNE démarche officielle Sinon le PU avec ses branches fonctionnelles et techniques disjointes Valable pour les grands projets Mais plusieurs démarches appliquées par les professionnels fonction de leur culture, de leur passé des besoins, du type d applications Démarche synthétique Cas d utilisation Modèle du domaine Diagramme de séquence du système Identification des principales IHM Diagramme d activités de navigation Diagramme de séquence d interaction Diagramme de classes

2 Démarche proposée (1) 1. Cas d utilisation Identifier : les acteurs les cas d utilisation Structurer les cas d utilisation en packages Décrire textuellement chaque cas d utilisation à l aide d une fiche descriptive Démarche proposée (2) 2. Modèle du domaine Identifier les concepts métier manipulés par les acteurs Etablir un glossaire des classes : liste des classes avec leurs attributs Démarche proposée (3) 3. Diagramme de séquence système Détailler chaque cas d utilisation en voyant le système comme une boîte noire. Pour chaque cas d utilisation, on pourra distinguer : le scénario nominal : le chemin le plus direct pour atteindre l objectif du cas d utilisation. les extensions : qui comprennent les chemins moins directs ainsi que les «exceptions». Elles doivent se brancher sur le scénario nominal.

3 Démarche proposée (4) 4.IHM Identifier les principales IHM Définir les principales méthodes à réaliser par chaque IHM Démarche proposée (5) 5.Diagramme d activités de navigation Représenter les différents chemins possibles entre les principaux écrans proposés à l utilisateur Démarche proposée (6) 6. Diagramme de séquence d interaction Détailler chaque diagramme de séquence pour les cas intéressants en faisant apparaître les différents objets (internes au système) qui interagissent

4 Démarche proposée (7) 7. Diagramme de classes Réaliser le diagramme de classes de conception attributs / méthodes / liens entre les classes Exemple : système bancaire Gérer les clients Ouvrir un compte guichetier Créditer compte responsable clientèle Débiter compte Consulter Comptes Gestion de commande client Packages Ouvrir un compte Gestion comptes Créditer compte Débiter compte Consulter Comptes Gestion commandes Gestion clients

5 Diag. séquences pour le cas "Ouvrir un cpte" uncompte: Compte guichetier << create >> fournir(infoclient) client Créditer (50) Éditer_Compte() Diag. d'activités pour "Débiter cpte" Ici on montre la logique du cas d'utilisation Débiter Compte : Débiter(montant) [solde insuffisant] [solde suffisant] Déduire montant du solde Diagr. de classes trivial! Compte numérocpte Solde Créditer(montant) Débiter(montant) getsolde() Éditer() 1..* <possède Client Nom Prénom adresse Éditer() Le constructeur n est pas mentionné ici en analyse, mais il est obligatoire pour les classes concrètes

6 Démarche détaillée des Cas d Utilisation (1) Présentation du contexte et du sujet (2) Acteurs autour du système diagramme de contexte statique identifier les acteurs (rôles abstraits) environnement humain et informatique du système lister et nommer les acteurs, les définir par une phrase Démarche Cas d utilisation (2) (3) Ajouter les échanges d'informations acteurs système les nommer, les définir par une phrase (diagramme de contexte dynamique) (4) Services rendus aux acteurs par le système (diagramme des cas d'utilisation) étude plus fine des interactions acteurs système, en dissociant en grandes fonctions nommer les services rendus, les définir par une phrase Démarche Cas d utilisation (3) (5) Pour chaque cas d'utilisation : Définir les objets partagés entre acteurs et système : Objets traités, mémorisés, produits, transformés objets du monde modélisé objets importants pour les acteurs objets persistants ou pas

7 Pour chaque cas d utilisation (suite) lister et nommer les objets (avec le vocabulaire des acteurs), les définir par une phrase identifier les classes candidates un diagramme de classe par cas d'utilisation relier les objets, nommer les liens, les définir par une phrase Démarche Cas d utilisation (4) (6) Réunir les objets des différents cas un unique diagramme des classes (les mêmes objets interviennent dans les différents cas) Attention! Rappel : UML est une méthode incrémentale et itérative Itérative on modifie et enrichit au fur et à mesure les diagrammes ; Incrémentale on peut livrer des lots utilisables Quelle différence?

8 Analogie la fabrication d'un immeuble Si on construit un immeuble par itérations : On fait les murs. On habille tout l'extérieur. On fait toute l'électricité. On habille tous les intérieurs. Si on construit un immeuble par incréments : On réalise un étage complet puis on passe au suivant. Chaque étage fini est comparable à une version livrable (un prototype -et non une maquette). Meilleures pratiques Pour une analyse conception d une application relativement isolée, démarche top-down : partir des uses case et arriver aux modules Pour un pb «d urbanisme de SI», ie de conception de différents SI qui possèdent des inter-relations entre eux, avec un objectif plus lointain de concevoir des systèmes qui vont être capables d évoluer en fonction des modifications de technologies ou des besoins, préférer une démarche bottom-up. l'urbanisme est moins une affaire de statique des domaines fonctionnels que de dynamique des échanges et de "gestion des flux". Critiques des méthodes de spécification Une autre vision du développement : les méthodes de programmation rapide

9 Approches classiques de développement Développement en cascades (waterfall) Merise Développement itératif et incrémental UML Basées sur la séquence : spécification / conception / réalisation / validation Fondées sur l'idée que le coût de modification du logiciel augmente de manière exponentielle dans le temps Obj.: chercher à définir complètement le produit avant de procéder à sa réalisation Problèmes chroniques Les spécifications sont définies au début du projet, alors qu'on en sait encore peu sur le sujet, Les spécifications différencient rarement ce qui est important de ce qui ne l'est pas, L'application se rigidifie progressivement en un produit "final" souvent difficile à faire évoluer et à maintenir, Les activités sont compartimentées en fonction des spécialités des développeurs ce qui pose des problèmes de répartition des tâches et limite la circulation des connaissances dans l'équipe Une nouvelle hypothèse Certaines pratiques de développement permettent de réduire de manière significative le coût de changement du logiciel il devient ainsi plus rentable de prendre les décisions le plus tard possible en s'appuyant sur l'expérience acquise au cours du développement lui-même

10 extreme Programming: XP Approche radicalement différente du développement fondée sur une ouverture permanente au changement Caractéristiques Spécifications définies au début du projet, puis revues, affinées et complétées tout au long du développement, Le client arbitre en permanence les priorités pour que l'équipe se focalise d'abord sur les tâches les plus importantes, L'application est maintenue simple et évolutive à travers un ensemble de pratiques de programmation strictes, Les développeurs travaillent toujours ensemble, ce qui favorise le transfert de connaissances, améliore la qualité du produit et rend le travail nettement plus motivant Par ex.: programmation en binômes Réf?