UML : méthode Processus

Introduction(1) ● Cycles ● Spécification par cas d'utilisation ● Identifier les besoins ● Analyse par cas d'utilisation ● Affiner les spécifications ● Identifier les objets conceptuels du système ● classes métier : souvent persistantes

Introduction(2) ● Cycles (suite) ● Conception par cas d'utilisation ● Identifier et définir les objets du système pour qu'ils soient implémentés (classes métier, techniques et d'infrastructure ) ● Implémentation par cas d'utilisation ● Programmation ● Tests par cas d'utilisation

Objet et relationnel ● Démarche objet ● Trouver les objets ● par leur comportement ● Démarche relationnelle ● Trouver les entités ● par leur état

Comportement ● Une classe joue des rôles ● Chaque rôle est réalisé par une ou plusieurs méthodes de la classe ● Un cas d'utilisation du système est réalisé par une collaboration de rôles entre plusieurs classes ● Un système est un ensemble de cas d'utilisation

Encapsulation ● Une classe encapsule une structure: ● Un comportement ( ensemble de méthodes membres ) ● Un état (ensemble de données membres ) ● Comportement ● Il peut avoir pour effet de changer l'état du système ● Etat ● L'état du système est protégé ● Il n'est accessible que via des méthodes (get, set)

Process ● Pas une mais des méthodes ● Adaptées au contexte ● temps réel ● embarqué ● réseau ● gestion ● etc... ● Une méthode « générique » fournie avec UML ● RUP (Rational Unified Process)

RUP :méthode (1) ● Identifier les besoins ● Les acteurs ● Le rôle des acteurs ● Les cas d'utilisation des acteurs (vues acteur) ● Validation des besoins avec les utilisateurs ● Les cas d'utilisation sont des documents contractuels ● Cycles d'analyse ● Factorisation, extension, spécialisation des cas d'utilisation

RUP : méthode (2) ● Identifier les données ● Dictionnaire des données ● Hiérarchiser les données (arbre) ● Identifier les classes d'objet ● Dictionnaire des classes candidates ● Identifier les relations entre les classes candidates ● Spécialisation, dépendance et relation

RUP : méthode (3) ● Virage vers l'objet (des cas d'utilisation aux classes) ● Chaque cas d'utilisation met en scène : ● Des classes ● Des responsabilités ou services ou rôles des classes ● Des collaborations par envoi de messages entre classes ● changements d'état des classes ● Pattern de Jacobson (Interface, contrôleur) ● Diagramme de séquence et de collaboration

RUP : méthode (4) ● Représentation dynamique d'un cas d'utilisation ● Diagramme de séquence et de collaboration ● Représentation statique d'un cas d'utilisation ● Diagramme de classes

RUP : méthode (5) ● Identification des relations entre classes ● Identification des responsabilités ● CRC cartes ● Cycles d'analyse ● Raffinement des diagrammes de classes ● Design pattern

Approche ● Partition ● Vues métier ● Vues système ● Collaborations ● Responsabilités

Approche ● Partition(vues) ● Vues métier ● Vues système ● Collaborations ● Responsabilités ● Partition (composants) ● Cas d'utilisation métier ● Cas d'utilisation système ● Classes ● Méthodes

Emboitement des vues Cas d'utilisation métier Vue métier Acteur métier Vue système Travailleur métier Cas d'utilisation système Cas d'utilisation système Acteur système

Cas d'utilisation : collaboration Contrôle r Calculer prix euroTTC Convertir euros en francs PrésenterEntrer Prix euro hors taxe Prix TTC euros et francs

Patron de conception de Jacobson ● Cycle analyse ● Interface du cas d'utilisation ● Contrôleur ● Classes métier ● Basé sur le modèle MVC (modèle, vue, contrôleur) ● Cycle conception ● Ajout des classes techniques et d'infrastructure ● Prêt à l'implémentation

Diagramme de classes

Diagramme de séquence

Cycles itératifs ● Amélioration des modèles ● Utilisation de patrons de conception ● Design pattern ● Motifs, patrons ou kits de solutions à des problèmes répertoriés ● Singleton, composite, observateur, adaptateur, fabrique,... ● Livre d'Erich Gamma : « Design pattern »

Tous les cycles sont conduits par les cas d'utilisation(0) Cas d'utilisation Spécification Itération +1 Spécification Cas d'utilisation

Tous les cycles sont conduits par les cas d'utilisation(1) Cas d'utilisation Spécification Analyse Attribution des responsabilités par des sessions CRC Enrichissement par design pattern Classes métier

Tous les cycles sont conduits par les cas d'utilisation(2) Analyse Conception + classes techniques et d'infrastructure Design pattern

Tous les cycles sont conduits par les cas d'utilisation(3) ConceptionImplémentation public class Service { public Service(String nom) { this.nom = nom; salaries = new Vector(); } private String nom; private Vector salaries; }

Tous les cycles sont conduits par les cas d'utilisation(4) Implémentation public class Service { public Service(String nom) { this.nom = nom; salaries = new Vector(); } private String nom; private Vector salaries; } Tests Cas d'utilisation

Enrichissement par design pattern Design pattern « composite » AVANT APRES

Session CRC Collaboration &Responsability Cards Convertir () ? Calculer () ? Classe Convertisseur Classe Calculateur Quelle classe doit assumer cette responsabilité ? Comment collaborent-elles ? Super classe : méthodes : données :

Conclusion ● La méthode RUP impose une unité de lieu : ● Le cas d'utilisation ● Des spécifications jusqu'à la livraison du logiciel ● La méthode RUP distingue les cycles : ● Analyse ● Conception ● Implémentation ● Test

Bibliographie(1) ● « Conception et programmation orientées objet » Bertrand Meyer [Eyrolles] ● « The Unified Modeling Language: Reference Manual» James Rumbaugh ● « The Unified Modeling Language: User Guide» Grady Booch ● « The Unified Software Development Process » Yvar Jacobson

Bibliographie(2) ● « Design Patterns » Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ● « Analysis PAtterns » Martin Fowler ● « Using CRC Cards » Nancy M. Wilkinson ● Sites web: ● ● ●