Remerciez-le!

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

Démarche d’analyse et de conception avec le langage UML Je tiens à remercier mo

Démarche d’analyse et de conception avec le langage UML Je tiens à remercier mon chat et mon poisson rouge ( jusqu'à ce que mon chat ne le mange ) pour l'aide et le soutien moral qu'ils m'ont apportés. JC CORRE Grenoble Le Pont de Claix 06/02/2022 1 Index Démarche d’analyse et de conception avec le langage UML________________________1 Index______________________________________________________________________2 Préambule__________________________________________________________________3 Objectif global d’une démarche d’analyse et de conception objet______________________4 Les étapes de la démarche_____________________________________________________5 Exemple traité______________________________________________________________14 Définition des besoins________________________________________________________15 première étape : les exigences et les acteurs__________________________________________15 deuxième étape : les intentions d’acteurs_____________________________________________19 troisième étape : le diagramme de use case___________________________________________20 quatrième étape : use case description de haut niveau__________________________________23 L'analyse__________________________________________________________________24 cinquième étape : use case description de bas niveau___________________________________24 septième étape : diagramme de classe d’analyse_______________________________________32 huitième étape : Le glossaire_______________________________________________________36 neuvième étape : les contrats d'opération____________________________________________37 La conception______________________________________________________________43 dixième étape : le diagramme d’état________________________________________________43 onzième étape : le diagramme de collaboration_______________________________________45 1) Syntaxe du diagramme de collaboration_______________________________________________45 2) Visibilité des objets_______________________________________________________________52 3) GRASP patterns__________________________________________________________________54 4) Diagramme de collaboration du magasin_______________________________________________60 douzième étape : le diagramme de classe de conception________________________________65 1) Première étape___________________________________________________________________65 2) Deuxième étape__________________________________________________________________66 Le processus unifié__________________________________________________________70 Notion de lot ( ou de cycle )________________________________________________________70 Notion de phases_________________________________________________________________70 Notion d’itération________________________________________________________________72 conclusion_________________________________________________________________74 bibliographie_______________________________________________________________75 JC CORRE Grenoble Le Pont de Claix 06/02/2022 2 Préambule Cette démarche de conception est la démarche proposée par Craig LARMAN. Je l’ai connue à travers le cours “Analyse et conception avec UML et les Patterns " de la société Valtech. J’ai ici repris cette démarche, je l’ai légèrement simplifiée, et j’ai apporté les informations nécessaires pour que des stagiaires de l’AFPA puissent s’imprégner de cette démarche. Dans un premier temps j’ai repris l’exercice du cours Valtech. Souhaitons qu’il y ait un deuxième temps … Les formateurs qui désirent former leurs stagiaires à cette démarche devraient suivre le cours pré cité, afin de prendre du recul par rapport à la démarche. Je recommande à tous la lecture des ouvrages de Craig LARMAN sur UML. JC CORRE Grenoble Le Pont de Claix 06/02/2022 3 Objectif global d’une démarche d’analyse et de conception objet Le but de cette démarche est d’analyser et de concevoir une application objet. L’objectif est d’avoir une application qui puisse vivre ( évolution de l’application dans le temps ), et qui enrichisse la base de savoir-faire de l’entreprise ( développement de nouveaux applicatifs en s’appuyant sur des objets métiers déjà développés ) . La réutilisabilité est un des soucis principaux pour pouvoir réduire le coût des logiciels et augmenter la puissance de développement des programmeurs. Nous nous appuierons sur le workflow, c’est à dire les règles des processus métier pour débusquer les uses cases, et les acteurs. Dans l’analyse et la conception objet nous cherchons à construire une architecture en couche de la forme suivante : couche I.H.M. présentation couche application ( workflow ) application couche objets métiers métier couche accès aux données accès aux données couche base de données base de données Nous verrons que chaque couche définira un ou des contrôleurs pour la rendre indépendante des autres. Une étude a montré que dans certaines entreprises les règles métier changeaient de 10% par mois ! ! ! Il est facile de comprendre alors la raison de ce découplage des objets métiers. Les objets ont tendance à être stables dans le temps, par contre les IHM et base de données peuvent également être changées sans que l’on touche au métier ni aux règles de l’entreprise. Cette architecture ne s’appliquera bien sûr pas à toutes les applications, c’est à prendre comme un exemple complet. JC CORRE Grenoble Le Pont de Claix 06/02/2022 4 Les étapes de la démarche Ce chapitre est un résumé du processus de développement d’une application. Il est difficile de comprendre ce résumé, sans avoir lu en détail et expérimenté chacun des chapitres auquel il fait référence. Par contre je vous conseille de revenir souvent à ce résumé ( textuel et graphique ) pour bien vous situer dans la démarche, avant l’étude de tout nouveau chapitre.  Lister l’ensemble des exigences du client issues du cahier des charges, ou issu d’une démarche préalable de collecte d’information ( documents électroniques, notes de réunions, notes d’interviews, … ). Chaque exigence sera numérotée et ainsi pourra être tracée.  Deux solutions possibles :  Nous allons regrouper les exigences par intentions d’acteur complètes puis nous allons faire un diagramme de contexte ( nous nous appuierons sur un diagramme de collaboration pour cela )  Si toutes les règles de processus métier sont définies, nous réaliserons un diagramme d’activité en colonnes ( "swim lane" ) où les colonnes sont les acteurs. Cela permet de dégager les responsabilités de chaque acteur, et ainsi de connaître les intentions des acteurs.  Définir les uses cases et construire le diagramme de uses cases.  Faire la description de haut niveau de chaque use case : chercher des scénarios de base.  Faire la description détaillée de chaque use case : donner les séquences nominales puis les séquences alternatives ( Erreurs et exceptions, en limitant au maximum les exceptions). Cette description peut être complétée par un diagramme d’activité qui montre le séquencement des différents scénarios. Cette description détaillée comprend les scénarios, les pré conditions, à partir de quoi se déroule le use case, comment se termine le use case, et enfin les post conditions ( règles métier assurées quand le use case est terminé).  Faire un diagramme de séquence par scénario ( ici c’est un diagramme de séquence boîte noire, où la boîte noire correspond au système informatique à développer ).  Faire un diagramme de classe par use case. Le diagramme de classe final sera la superposition de ces diagrammes de classe. Les classes obtenues sont des classes du monde réel. Nous ne mettons pas les opérations car nous ne connaissons pas l’intérieur du système informatique.  Un contrat est réalisé pour chaque opération du système. Ce contrat contient un nom, des responsabilités, les exigences auxquelles répond notre itération de cycle de vie, les pré conditions, et les post conditions ( décrites sous la forme " has been " ) et enfin les exceptions. Ce contrat peut être réalisé sous forme textuelle, ou plus souvent sous forme d’un diagramme de séquence boîte blanche où les objets échangent des messages pour rendre le service demandé.  A partir des diagrammes de classe et des contrats nous réaliserons les diagrammes de collaboration qui montrent comment les objets collaborent pour rendre le service demandé. Nous appliquerons les patterns de conception pour cela ( GRASP patterns )  En parallèle nous réaliserons les diagrammes d’état des objets les plus complexes, ainsi nous détecterons des méthodes internes à ces objets. JC CORRE Grenoble Le Pont de Claix 06/02/2022 5  Nous réaliserons enfin le diagramme de classe de conception, en tenant compte à nouveau des GRASP patterns. Ceci peut remettre en cause le diagramme de classe précédemment établi. JC CORRE Grenoble Le Pont de Claix 06/02/2022 6 JC CORRE Grenoble Le Pont de Claix 06/02/2022 7 nom : effectuer un achat acteur principal : client acteur secondaire : caissier événement déclencheur : … rôle du use case : … terminaison du use case : … nom : effectuer un achat acteur principal : client acteur secondaire : caissier événement déclencheur : … rôle du use case : … terminaison du use case : … références croisées : … pré conditions : … scénarios et alternatives : … nom : … responsabilité : … exigences : … notes : … pré conditions : … post conditions : … Diagramme de uses cases A N A L Y S E C O N C E P T I O N D E F I N I R B E S O I N S Use case haut niveau Use case bas niveau Diagramme de séquence Diagramme de classe d’analyse Contrat d’opération Diagramme collaboration Diagramme de classe de conception :caissier :magasin :o1 :o2 1 : m() 1.1 : msg() Processus simplifié JC CORRE Grenoble Le Pont de Claix 06/02/2022 8 JC CORRE Grenoble Le Pont de Claix 06/02/2022 9 nom : effectuer un achat acteur principal : client acteur secondaire : caissier événement déclencheur : … rôle du use case : … terminaison du use case : … Diagramme de uses cases Use case haut niveau Diagramme contexte statique Processus de définition des besoins Exigences Diagramme des acteurs Diagramme contexte dynamique Intentions d’acteurs ref R1 fonction payer achat … … magasin payer retourner magasin est dans 0..* 0..1 ref fonction intention acteur JC CORRE Grenoble Le Pont de Claix 06/02/2022 10 nom : effectuer un achat acteur principal : client acteur secondaire : caissier événement déclencheur : … rôle du use case : … terminaison du use case : … références croisées : … pré conditions : … scénarios et alternatives : … nom : … responsabilité : … exigences : … notes : … pré conditions : … post conditions : … Use case bas niveau Diagramme de séquence Diagramme de classe d’analyse Contrat d’opération uploads/Management/ demarche-uml.pdf