UML Analyse et Conception  Objet (C++)
Plan du cours & Objectifs <ul><li>Les concepts objets (3) </li></ul><ul><li>Les concepts de base d'une conception objet (3...
Les concepts Objets <ul><li>Le problème </li></ul><ul><li>Les avantages des techniques OO </li></ul><ul><li>Les concepts <...
Les problèmes
Les principales causes de l'échec
Les symptômes de l'échec
Programmation Objet : Avantages (1) <ul><li>Les objets apportent : </li></ul><ul><li>Fiabilité-sécurité </li></ul><ul><li>...
Les bénéfices des techniques OO From the corporate Use Of Object Technology
OO Versus Dvp classique Dvp = 20% Maintenance = 50%
C versus C++ en Maintenance
Notion d'abstraction Classe Moule Seau ~ChateauDeSable()  c'est le destructeur Constructeur Objet ChateauDeSable ChateauDe...
Un programme objet (1)
Un programme objet : Réutilisation
Un Objet est Nain et Paresseux et snob !!!
Un programme objet (2) Mere Run Bronzer Enfant Creer JchaiPasQuoiFaire FaisUnChateau ChateauDeSable Creer Garnir Casser Jc...
Un programme objet (3) ChateauDeSable Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Delete
Un programme objet (3) Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Mer Creer AllerDans FaireVagues BoireTasse Cr...
Un programme objet (4) Mere Run Bronzer Enfant Mer Crier Delete
Un programme objet (5) Fuite Mémoire Mere Run Bronzer Mer
Un programme objet (6) Enfant College Lycée Enfant Enfant Enfant Usine
Un programme objet (7) Enfant College Lycée Enfant Enfant Enfant Usine
Un programme objet (8) Enfant College Lycée Enfant Enfant Enfant Usine
Un programme objet persistant P P P P P P Enfant College Lycée Enfant Enfant Enfant Usine T T
Les types d’Objet <ul><li>Les objets du monde réel : (Analyse) </li></ul><ul><ul><li>Concret (Voiture, Personne, …) </li><...
Les langages de programmation <ul><li>Assembleur </li></ul><ul><li>Programmation  </li></ul><ul><ul><li>Fortran (1957)  (I...
Les langages Objet <ul><li>Simula (67) </li></ul><ul><li>Smalltalk </li></ul><ul><li>C++ (83) => (87-98) </li></ul><ul><li...
Compilation-Interprétation <ul><li>Les langages Compilés </li></ul><ul><ul><li>C, ADA, Cobol, Fortran , C++ </li></ul></ul...
Encapsulation Public  : accessible par tout le monde Protected  : accessible par l'objet et par les héritiers Private  : a...
Héritage Est un
Polymorphisme Un petit programme  : Personne p; Dentiste d; Chirurgien c; p = d; p.Travailler(); p = c; p.Travailler(); Ar...
Les concepts d'une bonne conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Sépar...
Exemple : utilisation de la délégation abstraite ( OCP ) <ul><li>A gère les cas c1 et c2. Si un nouveau cas c3 doit être g...
Exemple : ( OCP ) Personne nom : string age : int Personne(n : string, a : int) Appl1 Appl2 BD Appl3 Avec adr <ul><li>Rajo...
Exemple : ( OCP ) Solution Appl1 Appl2 Personne nom : string age : int Personne(n : string, a : int) GetAdresse() : string...
Principes de substitution de LISKOV ( LSP ) <ul><li>Pour prétendre à l'héritage, une sous-classe doit être conçue de sorte...
Principes d’inversion des dépendances ( DIP ) <ul><li>Dans la plupart des applications, les modules de haut niveau (ceux q...
L’abstraction comme technique d’inversion des dépendances ( DIP ) <ul><li>Considérons deux classes A et B, A utilisant B c...
Principes de séparation des interfaces ( ISP ) <ul><li>Pollution d'interface par agrégation de services </li></ul><ul><ul>...
Techniques de séparation ( ISP ) <ul><li>Il existe deux techniques principales de mise en pratique de l'ISP : </li></ul><u...
Séparation par héritage multiple ( ISP ) <ul><li>Dans cette approche chaque service est représenté par une classe d'interf...
Séparation par adaptateur ( ISP ) <ul><li>Lorsque l'héritage multiple n'est pas possible, les services peuvent être représ...
UML <ul><li>Introduction : notion de modèle </li></ul><ul><li>Diagramme de use case </li></ul><ul><ul><li>Acteurs, Use cas...
La notation UML Introduction : notion de modèle
Le but d ’UML Trouver les bons objets
La modélisation : Pourquoi Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité...
Notion de Modèle Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose Le petit robert Top...
Un Modèle <ul><li>Un modèle contient : </li></ul><ul><li>Des éléments de modélisation </li></ul><ul><ul><li>Des classes (r...
Les diagrammes UML + = = = +++ + + +++
Les 13 diagrammes UML2.0
Un outil UML Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants
Historique d'UML 2005 2.0 DOC-PDF UML1.3 =  4,7MB DOC-PDF UML2.0 = 5.8 MB 2006 2.1 Booch-93 Rumbaugh( OMT2) Oct-95 0.8 Jac...
La notation UML Diagramme de Use case
Diagramme de Use case Les acteurs Un  acteur  est un rôle d’un ou plusieurs objets situés à  l’extérieur  du système et qu...
Diagramme de Use case Use Case Un Cas d’utilisation (  use case  ) est une  fonctionnalité  remplie par le système et qui ...
Diagramme de Use case Description d'un Use Case <ul><li>Titre et numérotation </li></ul><ul><li>Résumé </li></ul><ul><li>L...
Diagramme de Use case Description d'un Use Case Les scénarios
Diagramme de Use case Payer cash Payer par carte Manger Demander facture Maitre d'hotel Prendre la commande client Aller a...
Utilisation des Use case Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
Use Case : Ex1 Une société de vente par correspondance vous demande de développer son système informatique. Ce système doi...
Supplément sur UC : User Story <ul><li>Une User Story est une exigence du système à développer, formulée  </li></ul><ul><l...
Supplément sur UC (1) Un &quot; Use case &quot; modélise un service rendu par le système. Il  représente un ensemble de sé...
Supplément sur UC (2) User Stories et Use Cases formalisent  les besoins utilisateurs  et sont  orientés But Ils font faci...
Business use case La première étape de la définition d’un système d’information consiste donc à s’interroger sur   l’organ...
Business use case Une extension UML Que fait l’entreprise Comment fait l’entreprise Sur quoi travaille l’entreprise Qui tr...
Business use case : Ex2 <ul><li>De quelle entreprise s'agit-il? </li></ul><ul><ul><li>Trouver les business actor,  busines...
La notation UML Diagramme de classe
Diagramme de classe <ul><li>Statique : </li></ul><ul><ul><li>Ne pas utiliser de verbes d'action pour relier les classes </...
Diagramme de classe Les classes Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Op...
Les classes : Génération de code
Diagramme de classe Représentation des classes
Diagramme de classe Héritage et agrégation 1 0..32 0..32 Composition Agrégation Héritage Cardinalité multiplicité Héritage...
De quoi hérite -t-on ? [ PAM-97 p55 ]
Généralisation multiple (1) <ul><li>La généralisation  - sous sa forme dite multiple – existe également entre arbres de cl...
Généralisation multiple (2) <ul><li>Pour que la généralisation multiple puisse être mise en œuvre, il faut que les langage...
Classification dynamique [ PAM-00 p58 ]
L’héritage <ul><li>L’héritage est une technique offerte par les langages de  </li></ul><ul><li>programmation pour  constru...
Conflit de noms [ PAM-00 p60 ]
Les classes abstraites <ul><li>Les classes abstraites  ne sont pas instantiables  directement; elles ne donnent pas naissa...
Les interfaces
Finalité des interfaces [ PAM-00 p120 ] <ul><li>Une interface décrit le comportement d’une classe, d’un composant,  </li><...
Finalité et réalisation des interfaces
Finalité et réalisation des interfaces <ul><li>Une interface possède  uniquement  la spécification d’un comportement visib...
Le polymorphisme [ PAM-00 p63 ]
Les associations <ul><li>Les associations représentent des  relations structurelles entre classes d’objets . Une associati...
Diagramme de classe : Associations  Nom d'association Nom de rôle Cardinalité-Multiplicité Personne employeur : Societe So...
Association réflexive
Qualité des associations <ul><li>Naturellement, toute personne a 2 parents. Nous modélisons des systèmes artificiels, une ...
Diagramme de classe Classe d'association Où mettre le salaire??? La classe ContratTravail est une classe normale qui peut ...
Diagramme de classe Associations exclusives Contraintes
Les qualificateurs (1) <ul><li>Considérons le schéma suivant. Il décrit le fait qu’un avion contient plusieurs sièges qui ...
Les qualificateurs (2) <ul><li>En UML, l’analyste peut utiliser la notion de qualificateur pour représenter ce concept. Ce...
Les qualificateurs (3) <ul><li>Le diagramme ci-dessous indique que dans un avion, pour une rangée donnée, il y a 4 sièges....
Trouver un qualificateur?
qualificateur
Association : Génération du code
Diagramme de classe Dépendance Depenser i = Banque::GetInstance()->DonnerSolde(); Acheter(i); Voler b = new Banque(); i = ...
Les classes paramétrées
Diagramme de classe Exo3
Diagramme de packages
Diagramme de packages On peut montrer ce qu’il y a à l’intérieur du package Une classe appartient à un package et un seule...
Notion de package <ul><li>Un paquetage est un regroupement d’éléments de modélisation,  </li></ul><ul><li>mais aussi une e...
Packages et dépendances <ul><li>Cela signifie que : </li></ul><ul><li>Un élément de P0 au moins utilise un élément publiqu...
Packages et dépendances(1)
Organisation des packages RMQ  : On peut rajouter des classes P-AB1B2 P-CD
Trouver trois packages et les relations
Trouver trois packages et les relations (suite) K L A B I E J G D H C F
Trouver trois packages et les relations (suite) K L A B I E J G D H C F p1 P2 P3 Design Pattern Façade
Dépendances circulaires (Pb)
Dépendances circulaires (Solution) <ul><li>A n'est intéressé </li></ul><ul><li>par B que pour lui </li></ul><ul><li>faire ...
Dépendances circulaires (Solution) Rmq : si il y a des méthodes différentes, alors faire plusieurs interfaces
Dépendances circulaires (RMQ 1) Rmq1 : L'objet A ne doit pas créer l'objet B Rmq2 : L'objet B ne doit pas créer l'objet A ...
Dépendances circulaires (RMQ 1) <ul><li>L'application : </li></ul><ul><li>Crée un objet A </li></ul><ul><li>Crée un objet ...
Dépendances circulaires (RMQ 1) op1 fqq fqq() A::AddMonB(FqqAble p) B::AddMonA(FqqAble p)
Conclusion sur les dépendances <ul><li>Regrouper les classes qui vont bien ensemble </li></ul><ul><li>Un package peut cont...
Notion de stéréotypes Un stéréotype est une nouvelle classe d’un élément de  modélisation qui est introduit au moment de l...
Notion de stéréotypes(2) <ul><li>Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML. </li></ul><u...
Diagramme de classe Boundary-Controleur-Entité (1) Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
Diagramme de classe Boundary-Contrôleur-Entité (2)
Diagramme de classe Boundary-Contrôleur-Entité (2)
Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Propriet...
Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Propriet...
Diagramme de classe Exo5
La notation UML Diagramme d'objets
Diagramme d'objets <ul><li>Rappel : Un diagramme de classe représente le programme, il est vrai </li></ul><ul><li>tout le ...
Diagramme d'objets Exo5 <ul><li>Famille : Tintin & Milou, locataire </li></ul><ul><li>Famille : Haddock qui boit du whisky...
La notation UML Diagrammes dynamiques
Diagramme dynamique <ul><li>Diagrammes d'interaction (Séquence collaboration)  servent à  </li></ul><ul><ul><li>montrer co...
Diagramme de Séquence new
Diagramme de Communication Collaboration
Diagramme de communication
Diag. de Séquence :Navigation
Diagramme de communication  Génération de code
Diagramme de Séquence (UML2.0)
Diagramme d'interaction Exo6 Avant Après <ul><li>Faire le diagramme </li></ul><ul><li>d'interaction correspondant aux chan...
Automate <ul><li>Un automate est accroché à une classe et est composé d'états et </li></ul><ul><li>de transitions. Les tra...
Automate État & Transition Événement qui déclenche la transition Garde Action effectuée sur la transition Envoie de Ev2 à ...
Automate imbriqué
Représentation d'un automate imbriqué
Automate:état historique profond
Automate :point de Jonction(1)
Automate :point de Jonction(2)
Automate :point de décision
Automate Parallèle <ul><li>C'est un mélange d'automate et de diagramme d'activité </li></ul>
Automate : exo7 E1 E3 E1 E3 E1 E2 E1 E2 E3   E1 ST1 entry: i  = 0 exit: i++ ST2 entry: i++ exit: i++ on E4: i ++ E1 / i++ ...
Diagramme d'activité(1)
Diagramme d'activité(2)
Diagramme d'activité : nœud d'objet avec état
La notation UML Les autres diagrammes
Diagramme de composants (1)
Diagramme de composants (2)
Diagramme de composants (3)
Diagramme de déploiement(1)
Diagramme de déploiement(2)
Structure Composite :le problème
Structure Composite : exemple
Diagramme de temps
Vue d'ensemble des interactions <ul><li>Les diagrammes d’interaction générale fusionnent les  </li></ul><ul><li>diagrammes...
La notation UML Utilisation des diagrammes
Importance des diagrammes
La notation UML Les diagrammes (1) ==> Les fonctionnalités vues de l'extérieure du  système ==> Les choses qui existent à ...
La notation UML Les diagrammes (2) Diagramme  Automate ==> Comportement des classes  complexes ==> Validation des diagramm...
Cinématique des diagrammes UML Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State A...
La démarche Process Process Qui Quoi Quand Méthode Comment Langage Avec quoi UML Outils Hommes UP XP: Binôme TD Scrum
Processus en V V Winston Royce Addison Wesley
Processus en Y <ul><li>Conceptualisation </li></ul><ul><li>Analyse </li></ul><ul><li>Architecture </li></ul><ul><li>Concep...
Un processus  itératif et incrémental (I) <ul><li>Guidé par les cas d'utilisation </li></ul>Conceptualisation Analyse Arch...
Processus en Y Les phases <ul><li>Le but de la  conceptualisation  est de définir ce que l’on veut (doit) faire (Affinemen...
Conceptualisation (1) <ul><li>Décrire ce que l’on doit faire(UC)  => langage commun </li></ul><ul><li>Langage commun => Gl...
Conceptualisation (2) <ul><li>Les UC : </li></ul><ul><li>Décrire les acteurs et ce qu’ils attendent du système </li></ul><...
Architecture <ul><li>Faire des choix techniques correspondant aux contraintes </li></ul><ul><ul><li>Distribution (Obligato...
Analyse <ul><li>Partir des diagrammes de UC </li></ul><ul><ul><li>Trouver les classes d’analyse (Boundary et Control) </li...
Conception <ul><li>A partir des résultats de l’analyse et de l’architecture: </li></ul><ul><li>Modifier les diagrammes d’a...
Processus : le RUP : Historique
Processus : le RUP Unify Process (Énorme process pour tous) RUP Rational Unify Process  Process customisé à partir du UP C...
Processus : le RUP Les phases
Processus : le RUP Analyse et conception Mettre en place les mécanismes de persistance Méthode Concepteur BD Concepteur An...
Méthode <ul><li>C'est un ensemble de trucs et de règles : </li></ul><ul><li>Analyse :  </li></ul><ul><ul><li>ne donner que...
Méthode Persistance (1) Mapping objet vers Table relationnelle fait automatiquement par les outils (choix de l'architecte)...
Méthode Persistance (2) Data Modeler
Processus Light XP Process Agile RAD Programmation visuelle TV4IT : Pourquoi le poste de développeur est déconsidéré en Fr...
Design patterns
Classification des patterns Création Comportement Structure
Les Design patterns de comportement (1) <ul><li>State  : un objet réagit selon son humeur </li></ul><ul><li>Stratégie  : F...
Les Design patterns de comportement (2) <ul><li>Commande  : encapsule une requête dans un objet, et permet les files  </li...
State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) ...
State + Singleton
Stratègie : UML
Patron de méthode
l’Observer : UML Réutilisable Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
l ’Observer : la dynamique
Visitor <ul><li>Rajouter une (ou plusieurs) méthode à un objet  </li></ul><ul><li>(sans la rajouter) !!!! </li></ul><ul><l...
Visitor : UML
Mémento : UML La classe à surveiller-----La mémoire----Le programme client (main)  UnDo-ReDo
Itérateur: UML
Chain of Resp : Exemple Président <100000 Vice-président <25000 Directeur <10000 Comité >=100000 Director grouillot = new ...
Command : UML Configurateur Utilisateur
Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer
Les Design patterns de Structure  <ul><li>Proxy  : cacher la complexité d'un objet </li></ul><ul><li>Décorateur  : Rajoute...
Proxy : UML Proxy.Operation1() { fait qqchose….. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}
Decorator : UML Decorateur.Operation(): fait qq chose super.Operation() Cela revient à rajouter une responsabilité à une c...
l ’Adaptateur : Uml et Exemple
Composite : Le contexte & UML <ul><li>On utilise le Composite lorsque on veut : </li></ul><ul><li>Représenter une hiérarch...
Façade : UML
Flyweight : Poids mouche :UML Utilisation :  beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères...
Bridge : UML Rmq : ressemble au state
Les Design patterns de Création  <ul><li>Singleton  : un et un seul objet visible par tous </li></ul><ul><li>Fabrication  ...
Le singleton uml
Fabrication : le Design pattern
Fabrication Abstraite : motivation Application IHM Motif IHM windows Application IHM IHM Motif IHM windows L’application u...
Fabrication Abstraite : Structure Application <<instancie>>
Builder : UML
Prototype <ul><li>Masque au client les complexités de la création de nouvelles instances  </li></ul><ul><ul><li>(new, clon...
Etude de cas
<ul><li>Sur le Web de rational : www.rational.com </li></ul><ul><ul><li>UML Notation guide </li></ul></ul><ul><ul><li>UML ...
UML : Bibliographie (suite)
WWW CETUS
Autres sites web http://www.numbersix.com/ http://www.m2tech.net/
Corrections des exercices
Use Case : Correction Ex1
Use Case : Correction Ex1
UC :  Secrétaire
UC: Détails
UC: Suppléments
IHM : Secrétaire
UC Web
 
 
 
 
UC : Requirements
Business use case : Correction Ex2 (1) Business Actor Business Worker <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><...
Business use case : Correction Ex2 (2) <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><l...
Diagramme de classe Correction Exo3 (1)
Diagramme de classe Correction Exo3 (2) {or} Construction ContratSimple ContratDouble Contrat Vehicule Maison Couple Roue ...
Diagramme de classe Correction Exo4
Diagramme d'objets  Correction Exo5 (1) Famille : Tintin & Milou, locataire
Diagramme d'objets  Correction Exo5 (2) Haddock qui boit du whisky est  marié à la Castafiore et est  propriétaire de Moul...
Diagramme d'objets  Correction Exo5 (3) Haddock qui boit du whisky est  marié à la Castafiore et est  propriétaire de Moul...
Diagramme d'objets  Correction Exo5 (4) Tournesol est locataire d’une  partie de Moulinsart
Diagramme d'interaction Correction Exo6 (1)
Diagramme d'interaction Correction Exo6 (2)
Diagramme d'interaction Correction Exo6 (3)
Les développeurs Français Comment revaloriser le métier d'informaticien et d'ingénieur ? Je crois qu'il est important de m...
Supplément sur UC : User Story <ul><li>Une User Story est une exigence du système à développer, formulée  </li></ul><ul><l...
Supplément sur UC (1) Un &quot; Use case &quot; modélise un service rendu par le système. Il  représente un ensemble de sé...
Supplément sur UC (2) User Stories et Use Cases formalisent  les besoins utilisateurs  et sont  orientés But Ils font faci...
Supplément sur UC (3)
Le robot Correction
Le robot correction : les UC
Le robot correction : les UC : jouer(1)
Le robot correction : les UC : jouer(2)
Le robot correction : les UC : Deplacer
Le robot correction : les UC : Prendre
Le robot correction : les UC : Deposer
Le robot correction : les UC : Attaquer
Le robot correction : les UC : IHM
 
 
Prochain SlideShare
Chargement dans…5
×

U M L Analyse Et Conception Objet

3 897 vues

Publié le

1 commentaire
1 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
3 897
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
138
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Nous nous inspirons de l’exemple de la figure 70 pour réaliser une structure de classes respectant le concept d’encapsulation. Les propriétés sont privées et accessibles par des opérations. L’opération ageDansFourchette() permet de déterminer si un livre convient à un enfant dont l’âge est passé en paramètre. Créez un nouveau modèle ou projet. Créez un nouveau diagramme de classes correspondant à la généralisation ci-dessus. Créez les attributs et opérations donnés en exemple.
  • Les propriétés de Y et Z sont protégées. T hérite simultanément des propriétés de Y et Z.
  • Le diagramme de classes ci-dessus modélise l’ensemble naturel des papillons. Chaque papillon du monde réel sera un objet de la classe Papillon.
  • Pour que la classe Z hérite des propriétés de X et Y, les propriétés de X et Y doivent être publiques ou protégées. La classe Z possède 2 attributs A hérités de 2 super-classes différentes!
  • Les 2 représentations ci-dessus reflètent le même contenu du modèle. Rational Rose montre la relation entre la classe Ville et l’interface Representable sous forme de relation de couplage ou de relation de réalisation selon le mode d’affichage choisi pour l’interface. La relation que nous avons intitulée « de couplage » n’est qu’une représentation externe, via le diagramme, de la relation de réalisation. La représentation iconographique de l’interface Representable montre le comportement visible de la classe Ville au travers d’une relation de couplage. La représentation stéréotypée de l’interface Representable montre l’implantation par la classe Ville au travers d’une relation de réalisation.
  • La classe Animal est un exemple de classe abstraite telle que décrite en [PAM-00 p53]. Une classe abstraite est notée en italique. L’opération dormir() de la classe Animal est abstraite; elle est polymorphe et réalisée par chacune des sous-classes Lion, Tigre et Ours. Nous avons complété l’exemple de la figure 98 pour en faire un exercice plus complet, la classe Animal comporte: Une propriété privée Nom Une opération protégée tonNom() qui permet à chacune des sous-classes de récupérer le nom de l’animal. Le nom de chacun des animaux est enregistré par les constructeurs qui ne sont pas indiqués comme opérations dans ce diagramme. Créez un nouveau modèle ou projet. Créez un nouveau diagramme de classes correspondant à la spécialisation ci-dessus.
  • L’utilisation du qualificateur a permis de réduire la cardinalité des instances de la classe Siege. L’utilisation du qualificateur a permis de ne prendre ici qu’un sous-ensemble de sièges réduit à un seul élément. Le rôle du qualificateur est de réduire la cardinalité d’une association. Ainsi, la cardinalité de Siege est passée de plusieurs à 1. Ce n’est pas toujours le cas. Nous rendons, encore une fois, le lecteur attentif à l’introduction de concepts qui nous semblent intéressants dans une vision de « programmation objet » mais sujette à remettre en cause tous les concepts des bases de données relationnelles qui actuellement garantissent la persistance de la majorité des systèmes d’information à base d’objets. Christian Soutou, dans l’ouvrage [SOU-99], propose de considérer le diagramme de classes comme un niveau de représentation conceptuelle et propose un niveau navigationnel à base de pointeurs pour gérer les associations entre classes. La construction de ce niveau navigationnel est inspiré du modèle relationnel et nous semble plus à même de concilier les besoins de la programmation objet et les besoins de persistance des objets par les bases de données relationnelles. Cette représentation à 2 niveaux est mise en œuvre dans l’atelier de génie logiciel d’Oracle, Designer/2000.
  • Le qualificateur permet de partitionner l’ensemble des instances possibles de Siege suivant un critère indiqué par le qualificateur rangee . Le qualificateur est utile lors de la conception et de l’implémentation, il suggère: l’utilisation d’un dictionnaire dans la classe portant le qualificateur, ce dictionnaire étant composé de couples qualificateur(s)  objet ( s ) qualifié(s): 1  siège1, 2  siège2, 3  siège3 etc.; La mise en place de clés primaires lors de l’élaboration du modèle de bases de données. Une partition est la décomposition d’un ensemble E en sous-ensembles disjoints (c’est-à-dire qu’aucun élément n’appartient à deux sous-ensembles) dont la réunion forme l’intégralité de l’ensemble E. Un dictionnaire est une collection d’éléments, chaque élément étant une association entre une clé et une valeur. Une clé primaire est un identifiant unique pour un enregistrement d’une base de données.
  • [RV-00 p147] Où placer l’attribut matricule ? A première vue, il s’agit de la propriété de la classe Personne. Mais en fait, une personne possède un matricule pour chacun de ses employeurs. Il s’agit donc plutôt d’un attribut de l’association, que nous pouvons placer dans la classe Emploi. Créez un nouveau modèle ou projet. Créez le modèle ci-dessus.
  • [RV-00 p147] Poussons l’analyse encore un peu plus loin: à quoi sert l’attribut matricule sinon à référencer un employé au sein de son employeur? Il s’agit d’un identifiant relatif, dont la valeur permet d’accéder à une instance particulière de Personne, pour une (instance de) Société donnée. C’est exactement la notion de qualificatif en UML. Un objet Société doté d’une valeur particulière du qualificatif matricule a accès à un objet Personne au plus, car la multiplicité a été réduite à « 0..1 ». Il peut y avoir des numéros de matricule inutilisés, d’où la limite inférieure à 0. Copiez le modèle précédent sous un nouveau nom de fichier. Adaptez-le pour mettre en place la qualification comme ci-dessus.
  • Créez un nouveau modèle ou projet. Créez les paquetages et les dépendances comme ci-dessus. Spécifiez le paquetage Erreur comme étant d’utilisation globale.
  • U M L Analyse Et Conception Objet

    1. 1. UML Analyse et Conception Objet (C++)
    2. 2. Plan du cours & Objectifs <ul><li>Les concepts objets (3) </li></ul><ul><li>Les concepts de base d'une conception objet (31) </li></ul><ul><li>La notation UML (43) </li></ul><ul><ul><li>UC (52) </li></ul></ul><ul><ul><li>Les classes (64) </li></ul></ul><ul><ul><li>Les Packages (97) </li></ul></ul><ul><ul><li>Les stéréotypes (114) </li></ul></ul><ul><ul><li>Diagrammes d'objet (119) </li></ul></ul><ul><ul><li>Diagrammes dynamiques (122) </li></ul></ul><ul><ul><li>Automates & Activités (131) </li></ul></ul><ul><ul><li>Autres diagrammes (138) </li></ul></ul><ul><li>Que faire (comment) avec UML? </li></ul><ul><ul><li>Utilisation des diagrammes (148) </li></ul></ul><ul><ul><li>La démarche (les démarches) </li></ul></ul><ul><ul><ul><li>Process UP, agilité, XP(153) </li></ul></ul></ul><ul><li>Les DP(172) </li></ul><ul><li>Une étude de cas </li></ul>
    3. 3. Les concepts Objets <ul><li>Le problème </li></ul><ul><li>Les avantages des techniques OO </li></ul><ul><li>Les concepts </li></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Un programme objet </li></ul></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Héritage </li></ul></ul><ul><ul><li>Polymorphisme </li></ul></ul>
    4. 4. Les problèmes
    5. 5. Les principales causes de l'échec
    6. 6. Les symptômes de l'échec
    7. 7. Programmation Objet : Avantages (1) <ul><li>Les objets apportent : </li></ul><ul><li>Fiabilité-sécurité </li></ul><ul><li>Productivité </li></ul><ul><li>Maintenabilité </li></ul><ul><li>Adaptabilité-Evolutivité </li></ul><ul><li>Simplicité </li></ul><ul><li>Autreté (Réutilisation, composant, Pg visuelle) </li></ul>
    8. 8. Les bénéfices des techniques OO From the corporate Use Of Object Technology
    9. 9. OO Versus Dvp classique Dvp = 20% Maintenance = 50%
    10. 10. C versus C++ en Maintenance
    11. 11. Notion d'abstraction Classe Moule Seau ~ChateauDeSable() c'est le destructeur Constructeur Objet ChateauDeSable ChateauDeSable couleur : Bleu, Blanc, Rouge poids : int ChateauDeSable(p1 : Couleur, p2 : int)
    12. 12. Un programme objet (1)
    13. 13. Un programme objet : Réutilisation
    14. 14. Un Objet est Nain et Paresseux et snob !!!
    15. 15. Un programme objet (2) Mere Run Bronzer Enfant Creer JchaiPasQuoiFaire FaisUnChateau ChateauDeSable Creer Garnir Casser JchaiPasQuoiFaire
    16. 16. Un programme objet (3) ChateauDeSable Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Delete
    17. 17. Un programme objet (3) Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Mer Creer AllerDans FaireVagues BoireTasse Crier
    18. 18. Un programme objet (4) Mere Run Bronzer Enfant Mer Crier Delete
    19. 19. Un programme objet (5) Fuite Mémoire Mere Run Bronzer Mer
    20. 20. Un programme objet (6) Enfant College Lycée Enfant Enfant Enfant Usine
    21. 21. Un programme objet (7) Enfant College Lycée Enfant Enfant Enfant Usine
    22. 22. Un programme objet (8) Enfant College Lycée Enfant Enfant Enfant Usine
    23. 23. Un programme objet persistant P P P P P P Enfant College Lycée Enfant Enfant Enfant Usine T T
    24. 24. Les types d’Objet <ul><li>Les objets du monde réel : (Analyse) </li></ul><ul><ul><li>Concret (Voiture, Personne, …) </li></ul></ul><ul><ul><li>Abstrait (Vente, Négociation,….) </li></ul></ul><ul><li>Les objets informatiques : (Conception) </li></ul><ul><ul><li>Les objets visibles par l’utilisateur : (IHM) </li></ul></ul><ul><ul><li>Les extensions du langage : </li></ul></ul><ul><ul><ul><li>range INT(0:5) </li></ul></ul></ul><ul><ul><ul><li>smart pointeur </li></ul></ul></ul><ul><ul><ul><li>tableau </li></ul></ul></ul><ul><ul><ul><li>les programmes </li></ul></ul></ul><ul><ul><li>Les conteneurs : </li></ul></ul><ul><ul><ul><li>tableau, listes, piles, .... </li></ul></ul></ul><ul><ul><ul><li>bouts d’application, les patterns, ... </li></ul></ul></ul>
    25. 25. Les langages de programmation <ul><li>Assembleur </li></ul><ul><li>Programmation </li></ul><ul><ul><li>Fortran (1957) (If-For-Variables ) </li></ul></ul><ul><li>Programmation fonctionnelle-procédurale </li></ul><ul><ul><li>PL1 (If-For-Variables + Procédures) </li></ul></ul><ul><li>Programmation Typée (I=2.5) ADA </li></ul><ul><li>Programmation structurée </li></ul><ul><li>C - Exemple Point(x,y) => p.x & p.y </li></ul><ul><li>Programmation Objet </li></ul><ul><li>Notion de classe (Regroupement des données et des fonctions) </li></ul><ul><li>Programmation Logique (Prologue) </li></ul>
    26. 26. Les langages Objet <ul><li>Simula (67) </li></ul><ul><li>Smalltalk </li></ul><ul><li>C++ (83) => (87-98) </li></ul><ul><li>Java (90) </li></ul><ul><li>C# (2000) </li></ul><ul><li>Python </li></ul>Généricité Object Arithmétique
    27. 27. Compilation-Interprétation <ul><li>Les langages Compilés </li></ul><ul><ul><li>C, ADA, Cobol, Fortran , C++ </li></ul></ul><ul><li>Les langages interprétés </li></ul><ul><ul><li>Logo, Prolog, Basic, VB(3-6), vba </li></ul></ul><ul><li>Les langages compilés et interprétés </li></ul><ul><ul><li>Java, C#, VB.Net </li></ul></ul>Source Compilateur Binaire Source Interpréteur Source Compilateur Code Intermédiaire Interpréteur MV JIT
    28. 28. Encapsulation Public : accessible par tout le monde Protected : accessible par l'objet et par les héritiers Private : accessible seulement par l'objet Les accesseurs : SetAttr et GetAttr
    29. 29. Héritage Est un
    30. 30. Polymorphisme Un petit programme : Personne p; Dentiste d; Chirurgien c; p = d; p.Travailler(); p = c; p.Travailler(); Arracher des dents Opérer Faire du pain
    31. 31. Les concepts d'une bonne conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Séparation des interfaces ISP
    32. 32. Exemple : utilisation de la délégation abstraite ( OCP ) <ul><li>A gère les cas c1 et c2. Si un nouveau cas c3 doit être géré, il faut modifier le code de A en conséquence : </li></ul>
    33. 33. Exemple : ( OCP ) Personne nom : string age : int Personne(n : string, a : int) Appl1 Appl2 BD Appl3 Avec adr <ul><li>Rajouter un attribut </li></ul><ul><ul><li>Rajouter un constructeur </li></ul></ul><ul><ul><li>Rajoute un paramètre au constructeur </li></ul></ul><ul><li>Faire une nouvelle classe PersonneAdr </li></ul><ul><ul><li>Rajouter une méthode getAdr même ds Personne </li></ul></ul>ID nom age
    34. 34. Exemple : ( OCP ) Solution Appl1 Appl2 Personne nom : string age : int Personne(n : string, a : int) GetAdresse() : string PersonneDomicilee adresse : string PersonneDomiciliee(n : string, a : int, adr : string) GetAdresse() : string SetAdresse(p : string) : void Rend une chaîne vide: Appl3 peut alors utiliser des Personnes <ul><li>Jouer sur les méthodes plus tôt que sur les attributs </li></ul><ul><li>Les gains : </li></ul><ul><li>2 versions dans le même exécutable </li></ul><ul><li>pas besoin de faire de VNR (faites la quand même) </li></ul>Appl3
    35. 35. Principes de substitution de LISKOV ( LSP ) <ul><li>Pour prétendre à l'héritage, une sous-classe doit être conçue de sorte que ses instances puissent se substituer à des instances de la classe de base partout où cette classe de base est utilisée. </li></ul><ul><li>Hériter d’une interface </li></ul><ul><li>En insistant sur cette approche de l'héritage, le principe de substitution s'oppose à une pratique répandue dans laquelle l'héritage est mis en oeuvre pour factoriser du code entre plusieurs classes. </li></ul>
    36. 36. Principes d’inversion des dépendances ( DIP ) <ul><li>Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects &quot;métier&quot;) sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :&quot; Le passage à l'abstrait est valorisé&quot; </li></ul>
    37. 37. L’abstraction comme technique d’inversion des dépendances ( DIP ) <ul><li>Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous : </li></ul>Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :
    38. 38. Principes de séparation des interfaces ( ISP ) <ul><li>Pollution d'interface par agrégation de services </li></ul><ul><ul><li>On retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanément, comme l'illustre le schéma ci-dessous : </li></ul></ul>
    39. 39. Techniques de séparation ( ISP ) <ul><li>Il existe deux techniques principales de mise en pratique de l'ISP : </li></ul><ul><ul><li>L'héritage multiple, </li></ul></ul><ul><ul><li>Le Design Pattern &quot;Adapter&quot;. </li></ul></ul>
    40. 40. Séparation par héritage multiple ( ISP ) <ul><li>Dans cette approche chaque service est représenté par une classe d'interface dont dérive la classe qui implémente les services. </li></ul><ul><li>Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schéma suivant : </li></ul>
    41. 41. Séparation par adaptateur ( ISP ) <ul><li>Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation : </li></ul>
    42. 42. UML <ul><li>Introduction : notion de modèle </li></ul><ul><li>Diagramme de use case </li></ul><ul><ul><li>Acteurs, Use case, Business Modeling </li></ul></ul><ul><li>Diagramme de classes </li></ul><ul><li>Diagramme d'objets </li></ul><ul><li>Diagramme dynamique </li></ul><ul><ul><li>Diagramme d'interaction </li></ul></ul><ul><ul><li>Automates </li></ul></ul><ul><ul><li>Diagramme d'activité </li></ul></ul><ul><li>Autres diagrammes </li></ul><ul><ul><li>Composants et Déploiement </li></ul></ul><ul><li>UML 2.0 </li></ul>
    43. 43. La notation UML Introduction : notion de modèle
    44. 44. Le but d ’UML Trouver les bons objets
    45. 45. La modélisation : Pourquoi Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité qui satisfont les besoins des clients (livraison à temps, utilisation des ressources humaines et matérielles optimales) Le but principal n’est donc pas de produire de beaux documents, ni de conduire de nombreuses réunions, ni de proclamer de beaux slogans, ni de gagner des prix Pulitzer sur les lignes de code; mais simplement de produire des programmes capables de satisfaire le client aujourd’hui et demain. Tout le reste est secondaire UML-User Guide
    46. 46. Notion de Modèle Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose Le petit robert Top Model <ul><li>Toutes abstractions qui incluent toutes les </li></ul><ul><li>capacités et propriétés, ou les aspects de ce </li></ul><ul><li>qui est modélisé sans montrer les détails </li></ul><ul><li>superflus </li></ul><ul><li>Un ensemble cohérent de spécifications ou </li></ul><ul><li>d ’information de conception, consistant </li></ul><ul><li>typiquement de diagrammes orientés objet </li></ul><ul><li>et d ’informations </li></ul>Firesmith-Dictionary of object tecnology
    47. 47. Un Modèle <ul><li>Un modèle contient : </li></ul><ul><li>Des éléments de modélisation </li></ul><ul><ul><li>Des classes (reliées à d'autres classes) avec des opérations et </li></ul></ul><ul><ul><ul><li>des attributs </li></ul></ul></ul><ul><ul><li>Des informations supplémentaires sur le comportement des </li></ul></ul><ul><ul><ul><li>classes (automates, activité) </li></ul></ul></ul><ul><ul><li>Des informations concernant le cahier des charges (UC) </li></ul></ul><ul><ul><li>La description des fichiers et des machines supportant l'application </li></ul></ul><ul><li>Des dessins (vues) explicatifs liés les uns aux autres </li></ul><ul><ul><li>Des diagrammes de classes réduits </li></ul></ul><ul><ul><li>Des diagrammes montrant comment les objets se partagent le </li></ul></ul><ul><ul><ul><li>travail (interaction) </li></ul></ul></ul><ul><ul><li>Des diagrammes montrant les objets existant à un moment donné </li></ul></ul><ul><li>Toutes ces informations sont organisées dans des packages </li></ul>
    48. 48. Les diagrammes UML + = = = +++ + + +++
    49. 49. Les 13 diagrammes UML2.0
    50. 50. Un outil UML Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants
    51. 51. Historique d'UML 2005 2.0 DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB 2006 2.1 Booch-93 Rumbaugh( OMT2) Oct-95 0.8 Jacobson (use case - sdl) Juillet-96 0.9 Janv-97 1.0 Nov-97 1.0 Sept-97 1.1 (OMG) 2000 1.4
    52. 52. La notation UML Diagramme de Use case
    53. 53. Diagramme de Use case Les acteurs Un acteur est un rôle d’un ou plusieurs objets situés à l’extérieur du système et qui interagissent avec lui pour remplir une fonctionnalité donnée de ce système. Un acteur caractérise le rôle joué par un objet à l’extérieur du système. <ul><li>Un acteur parle au système (Acteur principal) </li></ul><ul><li>Le système parle à un acteur (Acteur secondaire) </li></ul><ul><li>Un acteur est : </li></ul><ul><ul><li>Un humain (via une IHM) </li></ul></ul><ul><ul><li>Du soft </li></ul></ul><ul><ul><li>Du hard </li></ul></ul>
    54. 54. Diagramme de Use case Use Case Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui se manifeste par un ensemble de messages échangés entre le système et un ou plusieurs acteurs.
    55. 55. Diagramme de Use case Description d'un Use Case <ul><li>Titre et numérotation </li></ul><ul><li>Résumé </li></ul><ul><li>Les acteurs </li></ul><ul><ul><li>Acteur principal </li></ul></ul><ul><ul><li>Acteurs secondaires </li></ul></ul><ul><li>Pré-conditions </li></ul><ul><li>Description </li></ul><ul><li>Exceptions </li></ul><ul><li>Post-conditions </li></ul>(3-5 pages) Ce n ’est pas une description formelle Mais doit être très détaillé Ceci est l ’usage mais ne fait partie de la norme UML
    56. 56. Diagramme de Use case Description d'un Use Case Les scénarios
    57. 57. Diagramme de Use case Payer cash Payer par carte Manger Demander facture Maitre d'hotel Prendre la commande client Aller au restaurant <<include>> <<include>> Caissier Payer <<include>> <<extend>> Sommelier Commander pinard <<extend>> Serveur Retourner plat en cuisine <<extend>>
    58. 58. Utilisation des Use case Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
    59. 59. Use Case : Ex1 Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prendre en compte des commandes passées par la poste et des commandes passées par internet. Il doit suivre les expéditions qui ne sont effectuées que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chèque dans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Le nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stock disponible, l'expédition est faite par un robot existant au quel il suffit de passer les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client. Correction
    60. 60. Supplément sur UC : User Story <ul><li>Une User Story est une exigence du système à développer, formulée </li></ul><ul><li>en une ou deux phrases dans le langage de l'utilisateur. </li></ul><ul><li>Exemples de User stories: </li></ul><ul><li>En tant qu'utilisateur, je peux réserver des chambres d'hôtel </li></ul><ul><li>En tant que recruteur, je peux déposer des offres d'emploi. </li></ul><ul><li>Ron Jeffries utilise les 3 C pour la décrire: </li></ul><ul><li>Card (l'histoire est courte et écrite sur une carte 8x13 cm) </li></ul><ul><li>Conversation (les détails de l'histoire sont discutés) </li></ul><ul><li>Confirmation (l'histoire est confirmée par des tests d'acceptation </li></ul><ul><ul><li>rédigés au même moment que celle-ci, au dos de la carte). </li></ul></ul>
    61. 61. Supplément sur UC (1) Un &quot; Use case &quot; modélise un service rendu par le système. Il représente un ensemble de séquences d'actions qu'un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système. <ul><li>Exemples d'intitulés de Use cases: </li></ul><ul><li>S'authentifier, </li></ul><ul><li>Rechercher un livre. </li></ul><ul><li>Ces titres ne sont qu'une partie du &quot;Use Case&quot; qui comporte d'autres </li></ul><ul><li>parties (Acteur, Résumé, Déclencheur, Scénario principal, </li></ul><ul><li>Extensions...). Un &quot;Use Case&quot; est donc plus détaillé, et nécessite un </li></ul><ul><li>travail approfondi d'analyse et de formalisation. </li></ul>
    62. 62. Supplément sur UC (2) User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés But Ils font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciter Ils vont être priorisés et vont ainsi guider les développements Ils mettent en avant les rôles, les différents profils d'utilisateurs Ils ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires (contexte UP) et dans les &quot;Constraints Cards&quot; (contexte XP)) Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomie Ils aident à organiser le modèle Ils facilitent le choix du contenu des itérations Ils peuvent être rédigés par les analystes (UC) ou le client (US)
    63. 63. Business use case La première étape de la définition d’un système d’information consiste donc à s’interroger sur   l’organisation (l’entreprise) pour laquelle ce système d’information fonctionne, sur son identité, sur ce qui en fait partie et sur ce qui n’en fait pas partie business actor1 business use-case realization business entity business actor business worker business use case
    64. 64. Business use case Une extension UML Que fait l’entreprise Comment fait l’entreprise Sur quoi travaille l’entreprise Qui travaille dans l’entreprise business actor1 business use-case realization business entity business actor business worker business use case Qui utilise l’entreprise Qui est utilisé par  l’entreprise (en externe)
    65. 65. Business use case : Ex2 <ul><li>De quelle entreprise s'agit-il? </li></ul><ul><ul><li>Trouver les business actor, business entité, business use case </li></ul></ul><ul><ul><li>et les business worker </li></ul></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>
    66. 66. La notation UML Diagramme de classe
    67. 67. Diagramme de classe <ul><li>Statique : </li></ul><ul><ul><li>Ne pas utiliser de verbes d'action pour relier les classes </li></ul></ul><ul><ul><li>Une classe isolée est une classe inutile </li></ul></ul><ul><ul><li>Doit être vrai tout le temps </li></ul></ul><ul><ul><li>Représente LE programme </li></ul></ul><ul><ul><li>On ne peut pas tout montrer sur un seul schéma </li></ul></ul>Un diagramme de classe montre la structure statique du modèle, les choses qui existent, leur structure interne et les relations aux autres choses.
    68. 68. Diagramme de classe Les classes Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}
    69. 69. Les classes : Génération de code
    70. 70. Diagramme de classe Représentation des classes
    71. 71. Diagramme de classe Héritage et agrégation 1 0..32 0..32 Composition Agrégation Héritage Cardinalité multiplicité Héritage = Est un Composition et Agrégation = Est composé de
    72. 72. De quoi hérite -t-on ? [ PAM-97 p55 ]
    73. 73. Généralisation multiple (1) <ul><li>La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoint s . </li></ul>[ PAM-00 p52 ]
    74. 74. Généralisation multiple (2) <ul><li>Pour que la généralisation multiple puisse être mise en œuvre, il faut que les langages de programmation « objets » supportent l’héritage multiple. </li></ul><ul><li>Dans notre exemple, comment le compilateur peut-il garantir , lors de l’implémentation de la classe T , qu’il n’y ait pas d’effet de bord ou de conflit entre les propriétés p Z héritée de la classe Z et pY héritée de la classe Y ? </li></ul><ul><li>Par exemple, JAVA ne supporte pas l’héritage multiple. </li></ul>
    75. 75. Classification dynamique [ PAM-00 p58 ]
    76. 76. L’héritage <ul><li>L’héritage est une technique offerte par les langages de </li></ul><ul><li>programmation pour construire une classe à partir d’une ou de </li></ul><ul><li>plusieurs autres classes , en partageant des attributs, des opérations </li></ul><ul><li>et parfois des contraintes au sein d’une hiérarchie de classes. </li></ul><ul><li>Les classes enfants héritent des caractéristiques de leurs classes </li></ul><ul><li>parents; les attributs et les opérations déclarés dans la classe </li></ul><ul><li>parent, sont accessibles dans la classe enfant, comme s’ils avaient </li></ul><ul><li>été déclarés localement. </li></ul>
    77. 77. Conflit de noms [ PAM-00 p60 ]
    78. 78. Les classes abstraites <ul><li>Les classes abstraites ne sont pas instantiables directement; elles ne donnent pas naissance à des objets, mais servent de spécifications plus générale s -de type- pour manipuler les objets instances (d’une) ou plusieurs de leurs sous-classes. </li></ul><ul><li>La propriété abstraite peut également être appliquée à une opération afin d’indiquer que le corps de l’opération doit être défini explicitement dans les sous-classes. </li></ul>[ PAM-00 p146 ]
    79. 79. Les interfaces
    80. 80. Finalité des interfaces [ PAM-00 p120 ] <ul><li>Une interface décrit le comportement d’une classe, d’un composant, </li></ul><ul><li>d’un sous-système, d’un paquetage ou de tout autre classificateur </li></ul>
    81. 81. Finalité et réalisation des interfaces
    82. 82. Finalité et réalisation des interfaces <ul><li>Une interface possède uniquement la spécification d’un comportement visible, sous forme d’un ensemble d’opérations (pas d’attributs et d’associations), et ne fournit aucune implémentation de ses services. </li></ul>
    83. 83. Le polymorphisme [ PAM-00 p63 ]
    84. 84. Les associations <ul><li>Les associations représentent des relations structurelles entre classes d’objets . Une association symbolise une information dont la durée de vie n’est pas négligeable par rapport à la dynamique générale des objets instances des classes associées. La plupart des associations sont binaires, c’est-à-dire qu’elles connectent 2 classes . </li></ul>
    85. 85. Diagramme de classe : Associations Nom d'association Nom de rôle Cardinalité-Multiplicité Personne employeur : Societe Societe employe : ListeOfPersonne Navigabilité Societe Personne 1..* -employes 1..* Societe employes : Personne Personne
    86. 86. Association réflexive
    87. 87. Qualité des associations <ul><li>Naturellement, toute personne a 2 parents. Nous modélisons des systèmes artificiels, une représentation de la réalité, pour lesquels un ou des utilisateurs devront enregistrer dans une base de données les objets instances des classes que nous avons identifiées. </li></ul><ul><li>Il n’est pas possible d’imposer dans un modèle que toute personne a 2 parents, car au moment de la saisie les utilisateurs devront remonter à Adam et Eve… </li></ul><ul><li>Il est juste qu’une personne a 2 parents et peut avoir plusieurs enfants. Toutefois, le rôle doit indiquer « le rôle » joué par une personne par rapport à une autre personne; ainsi une personne est parent ou enfant (au singulier) d’une autre personne. </li></ul>
    88. 88. Diagramme de classe Classe d'association Où mettre le salaire??? La classe ContratTravail est une classe normale qui peut hériter, être associée à d'autres classes, …. L'association et la classe ne forme qu'un élément
    89. 89. Diagramme de classe Associations exclusives Contraintes
    90. 90. Les qualificateurs (1) <ul><li>Considérons le schéma suivant. Il décrit le fait qu’un avion contient plusieurs sièges qui ont chacun un numéro. </li></ul><ul><li>Cependant, ce schéma ne nous permet pas de dire que chaque siège a un numéro qui est unique pour chaque avion . Cette notion proche de la clé primaire du modèle de bases de données relationnelles, nous permet de préciser la cardinalité des associations . </li></ul>
    91. 91. Les qualificateurs (2) <ul><li>En UML, l’analyste peut utiliser la notion de qualificateur pour représenter ce concept. Celui-ci est représenté par un rectangle contenant le qualificateur qui portera l’association entre Siege et la classe Avion qualifiée. </li></ul><ul><li>Le diagramme se lit de la façon suivante: « un avion contient un siège pour un numéro donné  ». </li></ul>
    92. 92. Les qualificateurs (3) <ul><li>Le diagramme ci-dessous indique que dans un avion, pour une rangée donnée, il y a 4 sièges. </li></ul>
    93. 93. Trouver un qualificateur?
    94. 94. qualificateur
    95. 95. Association : Génération du code
    96. 96. Diagramme de classe Dépendance Depenser i = Banque::GetInstance()->DonnerSolde(); Acheter(i); Voler b = new Banque(); i = b->DonnerSolde(); Economiser (p : Banque) p->Deposer(10000);
    97. 97. Les classes paramétrées
    98. 98. Diagramme de classe Exo3
    99. 99. Diagramme de packages
    100. 100. Diagramme de packages On peut montrer ce qu’il y a à l’intérieur du package Une classe appartient à un package et un seule, mais peut être utilisée dans d'autres package. Un package est un regroupement des éléments du model. Cela s’applique à tous les éléments UML ainsi qu’aux différents diagrammes. Les packages sont la base de la gestion de configuration P.13
    101. 101. Notion de package <ul><li>Un paquetage est un regroupement d’éléments de modélisation, </li></ul><ul><li>mais aussi une encapsulation de ces éléments. A l’image des </li></ul><ul><li>classes, les paquetages possèdent une interface et une réalisation . </li></ul><ul><li>Chaque élément contenu par un paquetage possède un paramètre </li></ul><ul><li>qui signale si l’élément est visible ou non à l’extérieur du paquetage. </li></ul><ul><li>Les valeurs prises par le paramètre sont : public ou implémentation (privé). </li></ul>
    102. 102. Packages et dépendances <ul><li>Cela signifie que : </li></ul><ul><li>Un élément de P0 au moins utilise un élément publique de P3 et de P1 </li></ul><ul><li>Un élément de P3 au moins utilise un élément publique de P1 </li></ul><ul><li>P0, P3 et P1 peuvent utiliser les éléments publiques de p2 </li></ul>
    103. 103. Packages et dépendances(1)
    104. 104. Organisation des packages RMQ : On peut rajouter des classes P-AB1B2 P-CD
    105. 105. Trouver trois packages et les relations
    106. 106. Trouver trois packages et les relations (suite) K L A B I E J G D H C F
    107. 107. Trouver trois packages et les relations (suite) K L A B I E J G D H C F p1 P2 P3 Design Pattern Façade
    108. 108. Dépendances circulaires (Pb)
    109. 109. Dépendances circulaires (Solution) <ul><li>A n'est intéressé </li></ul><ul><li>par B que pour lui </li></ul><ul><li>faire faire Fqq() </li></ul><ul><li>B n'est intéressé </li></ul><ul><li>par A que pour lui </li></ul><ul><li>faire faire Fqq() </li></ul>
    110. 110. Dépendances circulaires (Solution) Rmq : si il y a des méthodes différentes, alors faire plusieurs interfaces
    111. 111. Dépendances circulaires (RMQ 1) Rmq1 : L'objet A ne doit pas créer l'objet B Rmq2 : L'objet B ne doit pas créer l'objet A Rmq3 : Si nécessaire, on peut laisser l'un des deux Rmq1 Rmq2
    112. 112. Dépendances circulaires (RMQ 1) <ul><li>L'application : </li></ul><ul><li>Crée un objet A </li></ul><ul><li>Crée un objet B </li></ul><ul><li>Présente B à A en tant </li></ul><ul><ul><li>que FqqAble </li></ul></ul><ul><li>Présente A à B en tant </li></ul><ul><ul><li>que FqqAble </li></ul></ul>
    113. 113. Dépendances circulaires (RMQ 1) op1 fqq fqq() A::AddMonB(FqqAble p) B::AddMonA(FqqAble p)
    114. 114. Conclusion sur les dépendances <ul><li>Regrouper les classes qui vont bien ensemble </li></ul><ul><li>Un package peut contenir 15 classes </li></ul><ul><li>Éviter les associations bi-directionnelles </li></ul><ul><li>Rajouter des classes </li></ul><ul><li>Utiliser les interfaces (ou des classes abstraites) </li></ul><ul><ul><li>pour découpler </li></ul></ul><ul><li>Utiliser les design pattern suivants: </li></ul><ul><ul><li>Singleton </li></ul></ul><ul><ul><li>Façade </li></ul></ul><ul><ul><li>Observeur </li></ul></ul><ul><ul><li>Commande </li></ul></ul>Simple Luxueux
    115. 115. Notion de stéréotypes Un stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élément de modélisation existant avec la même forme, mais avec une intention différente. <ul><li>Exemple : un acteur est &quot;comme&quot; une classe, mais il ne fait pas </li></ul><ul><li>partie du système. Un acteur pourrait être un stéréotype d'une classe </li></ul><ul><li>On peut stéréotyper les classes, les associations, les packages, ….. </li></ul><ul><li>On peut associer un nouvel icône pour chaque nouveau stéréotype. </li></ul>
    116. 116. Notion de stéréotypes(2) <ul><li>Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML. </li></ul><ul><li>Un stéréotype permet la métaclassification d’un élément d’UML. Il permet aux utilisateurs (méthodologistes, constructeurs d’outils, analystes et concepteurs) d’ajouter de nouvelles classes d’él é ments de modélisation, en plus du noyau prédéfini par UML . </li></ul>
    117. 117. Diagramme de classe Boundary-Controleur-Entité (1) Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
    118. 118. Diagramme de classe Boundary-Contrôleur-Entité (2)
    119. 119. Diagramme de classe Boundary-Contrôleur-Entité (2)
    120. 120. Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Proprietaire Nourriture Lapin Whisky Mariage CompteBanquaire Personne
    121. 121. Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Proprietaire Nourriture Lapin Whisky Mariage CompteBanquaire Personne
    122. 122. Diagramme de classe Exo5
    123. 123. La notation UML Diagramme d'objets
    124. 124. Diagramme d'objets <ul><li>Rappel : Un diagramme de classe représente le programme, il est vrai </li></ul><ul><li>tout le temps. </li></ul><ul><li>Un diagramme d'objets ou diagramme d'instances représente </li></ul><ul><li>une photo du programme à un moment donné. </li></ul><ul><li>Les diagrammes de classe doivent être validées par les diagrammes </li></ul><ul><li>d'objets </li></ul><ul><li>Une classe -> Un Objet [avec un nom] </li></ul><ul><li>Rmq : l'héritage ne se voit plus </li></ul><ul><li>Une association -> Zéro, un ou </li></ul><ul><li>plusieurs liens (cardinalité) </li></ul><ul><li>Une dépendance -> Un lien </li></ul>Rmq : aucune information sur les liens (cardinalité, rôle, navigation, ….)
    125. 125. Diagramme d'objets Exo5 <ul><li>Famille : Tintin & Milou, locataire </li></ul><ul><li>Famille : Haddock qui boit du whisky est marié à la Castafiore </li></ul><ul><ul><ul><ul><li>Haddock est propriétaire de Moulinsart </li></ul></ul></ul></ul><ul><li>Tournesol est locataire d’une partie de Moulinsart </li></ul>Reprendre le résultat de l'Exo4 et faire les diagrammes d'objets correspondants Modifier éventuellement le diagramme de classe Locataire proprio
    126. 126. La notation UML Diagrammes dynamiques
    127. 127. Diagramme dynamique <ul><li>Diagrammes d'interaction (Séquence collaboration) servent à </li></ul><ul><ul><li>montrer comment les objets se parlent les une aux autres. </li></ul></ul><ul><ul><li>Ils montrent le déroulement d'un ou d'une partie d'un Use case </li></ul></ul><ul><ul><li>(cas nominal, cas des exceptions, …) </li></ul></ul><ul><li>Automates servent à montrer le comportement d'une classe qui </li></ul><ul><ul><li>réagit différemment selon son état. </li></ul></ul><ul><li>Activités montrent le déroulement d'une méthode d'une classe ou </li></ul><ul><ul><li>celui d'un Use case </li></ul></ul>
    128. 128. Diagramme de Séquence new
    129. 129. Diagramme de Communication Collaboration
    130. 130. Diagramme de communication
    131. 131. Diag. de Séquence :Navigation
    132. 132. Diagramme de communication Génération de code
    133. 133. Diagramme de Séquence (UML2.0)
    134. 134. Diagramme d'interaction Exo6 Avant Après <ul><li>Faire le diagramme </li></ul><ul><li>d'interaction correspondant aux changements. </li></ul><ul><li>Mettre à jour le diagramme de classe </li></ul>
    135. 135. Automate <ul><li>Un automate est accroché à une classe et est composé d'états et </li></ul><ul><li>de transitions. Les transitions permettent de passer d'un état à </li></ul><ul><li>un autre … </li></ul>
    136. 136. Automate État & Transition Événement qui déclenche la transition Garde Action effectuée sur la transition Envoie de Ev2 à un objet Cible Action en entrant dans l'état Action en sortant de l'état Action déclenchée sur réception de Ev1 Activité
    137. 137. Automate imbriqué
    138. 138. Représentation d'un automate imbriqué
    139. 139. Automate:état historique profond
    140. 140. Automate :point de Jonction(1)
    141. 141. Automate :point de Jonction(2)
    142. 142. Automate :point de décision
    143. 143. Automate Parallèle <ul><li>C'est un mélange d'automate et de diagramme d'activité </li></ul>
    144. 144. Automate : exo7 E1 E3 E1 E3 E1 E2 E1 E2 E3 E1 ST1 entry: i = 0 exit: i++ ST2 entry: i++ exit: i++ on E4: i ++ E1 / i++ ST3 ST4 on E2: i = i - 2 E3[ i == 5 ] E2 E1 E1 E3 E3
    145. 145. Diagramme d'activité(1)
    146. 146. Diagramme d'activité(2)
    147. 147. Diagramme d'activité : nœud d'objet avec état
    148. 148. La notation UML Les autres diagrammes
    149. 149. Diagramme de composants (1)
    150. 150. Diagramme de composants (2)
    151. 151. Diagramme de composants (3)
    152. 152. Diagramme de déploiement(1)
    153. 153. Diagramme de déploiement(2)
    154. 154. Structure Composite :le problème
    155. 155. Structure Composite : exemple
    156. 156. Diagramme de temps
    157. 157. Vue d'ensemble des interactions <ul><li>Les diagrammes d’interaction générale fusionnent les </li></ul><ul><li>diagrammes d’activité et de </li></ul><ul><li>séquence en autorisant l’utilisation </li></ul><ul><li>de fragments (diagrammes de </li></ul><ul><li>séquence) avec des points de </li></ul><ul><li>décision et des flots de contrôle </li></ul><ul><li>(diagrammes d’activité).   </li></ul>
    158. 158. La notation UML Utilisation des diagrammes
    159. 159. Importance des diagrammes
    160. 160. La notation UML Les diagrammes (1) ==> Les fonctionnalités vues de l'extérieure du système ==> Les choses qui existent à l'intérieure du système ==> Distribution des fonctionnalités aux choses qui existent. Découverte des opérations des classes, de nouvelles classes, …. Diagramme d'activité ==> Description des opérations complexes Diagramme de UC Diagramme de classe Diagramme d'interaction
    161. 161. La notation UML Les diagrammes (2) Diagramme Automate ==> Comportement des classes complexes ==> Validation des diagrammes de classe ==> Description des fichiers contenant l'application (source, exe, …) ==> Les machines supportant l'application Diagramme d'instance Diagramme de composants Diagramme de déploiement
    162. 162. Cinématique des diagrammes UML Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Component Deployment Code Code Code Code Tests
    163. 163. La démarche Process Process Qui Quoi Quand Méthode Comment Langage Avec quoi UML Outils Hommes UP XP: Binôme TD Scrum
    164. 164. Processus en V V Winston Royce Addison Wesley
    165. 165.
    166. 166. Processus en Y <ul><li>Conceptualisation </li></ul><ul><li>Analyse </li></ul><ul><li>Architecture </li></ul><ul><li>Conception </li></ul><ul><li>Implémentation </li></ul>Y <ul><li>5 Phases Classiques : </li></ul>
    167. 167. Un processus itératif et incrémental (I) <ul><li>Guidé par les cas d'utilisation </li></ul>Conceptualisation Analyse Architecture Définition des incréments Conception Implémentation
    168. 168. Processus en Y Les phases <ul><li>Le but de la conceptualisation est de définir ce que l’on veut (doit) faire (Affinement du cahier des charges) </li></ul><ul><li>Le but de l’analyse est de trouver toutes les propriétés d’un système donné indépendamment de toutes implémentations </li></ul><ul><ul><ul><li>Les objets du métier </li></ul></ul></ul><ul><li>Le but de l’architecture est de trouver toutes les solutions techniques et ceci indépendamment du problème à traiter. </li></ul><ul><ul><ul><li>Les objets des informaticiens </li></ul></ul></ul><ul><li>Le but de la conception est le mapping d ’une analyse donnée sur une architecture donnée. </li></ul><ul><ul><ul><li>Les objets du métier + objets des informaticiens </li></ul></ul></ul><ul><li>L ’implémentation doit être presque rien </li></ul>
    169. 169. Conceptualisation (1) <ul><li>Décrire ce que l’on doit faire(UC) => langage commun </li></ul><ul><li>Langage commun => Glossaire </li></ul><ul><li>Glossaire => Tout ce qui est mis dans un modèle doit avoir </li></ul><ul><ul><li>une définition associée </li></ul></ul>ExpertMetier ExpertObjet Train Oméoplasmose Sténotype Classe Polymorphisme Relinker Langage commun
    170. 170. Conceptualisation (2) <ul><li>Les UC : </li></ul><ul><li>Décrire les acteurs et ce qu’ils attendent du système </li></ul><ul><li>Décrire l’ensemble des messages entrant et sortant du système </li></ul><ul><li>Ne pas décrire comment on fait </li></ul><ul><li>Décrire l’ensemble des contraintes </li></ul><ul><ul><li>Réutilisation d’un autre système </li></ul></ul><ul><ul><li>Problème de capacité-volume (des chiffres) </li></ul></ul><ul><ul><li>Problème de temps de réponse (des chiffres) </li></ul></ul><ul><ul><li>Choix technique quelconque imposé </li></ul></ul><ul><li>RMQ : Ne pas se vautrer dans la PatateOide </li></ul>
    171. 171. Architecture <ul><li>Faire des choix techniques correspondant aux contraintes </li></ul><ul><ul><li>Distribution (Obligatoire ou pour des problèmes de performance) </li></ul></ul><ul><ul><li>Fiabilité </li></ul></ul><ul><ul><li>Persistance </li></ul></ul><ul><li>Faire ces choix sans s’occuper de l’application </li></ul><ul><li>Valider ces choix par des protos </li></ul><ul><li>Découpe du système en sous-système </li></ul><ul><li>Simplifier la vie des utilisateurs </li></ul><ul><ul><li>Exemple des classes <<Role>> </li></ul></ul><ul><ul><li>Customisation des générateurs de code </li></ul></ul><ul><ul><li>Customiser et apprendre les outils aux utilisateurs </li></ul></ul><ul><ul><li>Production des Make File </li></ul></ul><ul><ul><li>Choix et mise en œuvre des design patterns utilisés pour le projet </li></ul></ul><ul><ul><li>Normes de programmation et de modélisation </li></ul></ul><ul><ul><li>Réutilisation par le principe de la réduction-expansion </li></ul></ul>
    172. 172. Analyse <ul><li>Partir des diagrammes de UC </li></ul><ul><ul><li>Trouver les classes d’analyse (Boundary et Control) </li></ul></ul><ul><li>Partir de la description des UC </li></ul><ul><ul><li>Trouver les classes entity </li></ul></ul><ul><ul><li>Faire tourner le programme </li></ul></ul><ul><ul><ul><li>Diagramme de séquence </li></ul></ul></ul><ul><ul><ul><ul><li>Cas nominal </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Les cas d’exception </li></ul></ul></ul></ul><ul><ul><ul><li>Affiner le diagramme statique </li></ul></ul></ul><ul><ul><ul><ul><li>(attributs, opérations, nouvelles classes) </li></ul></ul></ul></ul><ul><li>Refaire des sous-systèmes </li></ul><ul><li>Affiner les classes complexes : Automate </li></ul><ul><li>RMQ : Ne pas se vautrer dans l’héritage </li></ul>
    173. 173. Conception <ul><li>A partir des résultats de l’analyse et de l’architecture: </li></ul><ul><li>Modifier les diagrammes d’analyse pour prendre en compte </li></ul><ul><ul><li>les choix techniques de l’architecte </li></ul></ul><ul><ul><li>Application des design patterns </li></ul></ul><ul><ul><li>Persistance </li></ul></ul><ul><ul><li>Distribution </li></ul></ul><ul><ul><li>Les classes boundaryForm deviennent des sous systèmes </li></ul></ul><ul><ul><li>Certains contrôleurs peuvent disparaître, mais ceux qui restent </li></ul></ul><ul><ul><ul><li>doivent rester simple </li></ul></ul></ul><ul><ul><li>Utiliser l’héritage pour des problèmes de performance </li></ul></ul><ul><li>Refaire des diagrammes statiques et des diagrammes dynamiques </li></ul>RMQ : Ne pas refaire ce qu’a fait l’architecte
    174. 174. Processus : le RUP : Historique
    175. 175. Processus : le RUP Unify Process (Énorme process pour tous) RUP Rational Unify Process Process customisé à partir du UP C'est un outil (site web, customisable) Custom AirFranceUP <ul><li>Le RUP est : </li></ul><ul><li>Itératif </li></ul><ul><li>Basé sur une architecture à base de composants </li></ul><ul><li>Dirigé par les UC </li></ul>
    176. 176. Processus : le RUP Les phases
    177. 177. Processus : le RUP Analyse et conception Mettre en place les mécanismes de persistance Méthode Concepteur BD Concepteur Analyste Architecte Architecte Architecte Trouver et spécifier avec des responsabilités les classes Boundary-Control et entité Trouver les abstractions clés Faire le mapping objet BDR
    178. 178. Méthode <ul><li>C'est un ensemble de trucs et de règles : </li></ul><ul><li>Analyse : </li></ul><ul><ul><li>ne donner que des responsabilités </li></ul></ul><ul><ul><li>ne pas se vautrer dans l'héritage </li></ul></ul><ul><ul><li>trouver les classes B-C-E </li></ul></ul><ul><li>Architecture </li></ul><ul><ul><li>Persistance, Distribution, Réutilisation d'ancien système, Fiabilité, </li></ul></ul><ul><ul><ul><li>Capacité, performances, ….. </li></ul></ul></ul><ul><li>Conception </li></ul><ul><ul><li>Modifier les (grosses) classes persistantes </li></ul></ul><ul><ul><li>Garder les contrôleurs pour mettre les transactions </li></ul></ul><ul><ul><li>Transformer les boundary en sous système </li></ul></ul><ul><li>Organisation du modèle </li></ul><ul><ul><li>Utiliser les Use Case réalisation pour documenter le modèle </li></ul></ul>
    179. 179. Méthode Persistance (1) Mapping objet vers Table relationnelle fait automatiquement par les outils (choix de l'architecte) T_B a c T_B_ID b 50 Raymonde 0 1 55 Casta 1 1 45 Simone 2 1 T_A a c T_A_ID b 55 Robert 0 0 60 Haddock 1 0 35 0 Tintin 2 T_0 T_A_ID T_B_ID 0 1 0 1 1 0 0 2
    180. 180. Méthode Persistance (2) Data Modeler
    181. 181. Processus Light XP Process Agile RAD Programmation visuelle TV4IT : Pourquoi le poste de développeur est déconsidéré en France Eric Groise
    182. 182. Design patterns
    183. 183. Classification des patterns Création Comportement Structure
    184. 184. Les Design patterns de comportement (1) <ul><li>State : un objet réagit selon son humeur </li></ul><ul><li>Stratégie : Faire une chose de différentes manières </li></ul><ul><li>Template Methode : Faire une chose de différentes manières </li></ul><ul><li>(avec une recette de base) </li></ul><ul><li>Observer : certains sont intéresses par ce que je fais, mais pas tout le </li></ul><ul><ul><li>temps </li></ul></ul><ul><li>Visiteur : Rajouter une responsabilité à une classe avec des sous </li></ul><ul><ul><li>traitements identiques </li></ul></ul><ul><li>Memento : sauvegarder un objet </li></ul><ul><li>Iterateur : Balayer une collection </li></ul><ul><li>Chaîne de responsabilité : un élément est attendu par un grand nombre d'objets </li></ul>
    185. 185. Les Design patterns de comportement (2) <ul><li>Commande : encapsule une requête dans un objet, et permet les files </li></ul><ul><ul><li>d'attentes, les journalisassions , et retours en arrière (undo). </li></ul></ul><ul><li>Médiateur : définit un objet qui encapsule la manière dont un </li></ul><ul><ul><li>ensemble d'objets interagissent. </li></ul></ul><ul><li>Interpréteur : définit un langage ainsi que sa grammaire, et fournit un </li></ul><ul><ul><li>interpréteur pour utiliser la représentation du langage. </li></ul></ul>
    186. 186. State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) +Op3(Context)
    187. 187. State + Singleton
    188. 188. Stratègie : UML
    189. 189. Patron de méthode
    190. 190. l’Observer : UML Réutilisable Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
    191. 191. l ’Observer : la dynamique
    192. 192. Visitor <ul><li>Rajouter une (ou plusieurs) méthode à un objet </li></ul><ul><li>(sans la rajouter) !!!! </li></ul><ul><li>A utiliser quand une classe ne sait pas ce qu’elle veut et </li></ul><ul><li>qu’elle risque de vouloir beaucoup de choses. </li></ul><ul><li>La classe fait déjà beaucoup de petites choses </li></ul><ul><li>L'objet visité accepte le visiteur (Accept (Visitor v)) </li></ul><ul><li>Il dit alors à v de visiter (v.Visit()) </li></ul><ul><li>v fait son travail </li></ul>
    193. 193. Visitor : UML
    194. 194. Mémento : UML La classe à surveiller-----La mémoire----Le programme client (main) UnDo-ReDo
    195. 195. Itérateur: UML
    196. 196. Chain of Resp : Exemple Président <100000 Vice-président <25000 Directeur <10000 Comité >=100000 Director grouillot = new Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, &quot;Formation&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 24000, &quot;Voiture&quot;); Grouillot.ProcessRequest(p); p =new Purchase ( 99000, &quot;Maison&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 122100.00, &quot;Usine&quot;); Grouillot.ProcessRequest(p); U M V F
    197. 197. Command : UML Configurateur Utilisateur
    198. 198. Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer
    199. 199. Les Design patterns de Structure <ul><li>Proxy : cacher la complexité d'un objet </li></ul><ul><li>Décorateur : Rajouter une responsabilité à une classe sans changer l'interface </li></ul><ul><li>Adaptateur : Adapter un objet à un autre </li></ul><ul><li>Composite : permet de traiter une structure d'objets de manière uniforme (Des feuilles et des nœuds) </li></ul><ul><li>Façade : Représenter, regrouper et diriger un ensemble d'objets </li></ul><ul><li>Poids mouche : Partager de nombreux minis objets </li></ul><ul><li>Pont : permet de différencier une abstraction de son implémentation, permettant à chacune d'évoluer indépendamment. </li></ul>
    200. 200. Proxy : UML Proxy.Operation1() { fait qqchose….. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}
    201. 201. Decorator : UML Decorateur.Operation(): fait qq chose super.Operation() Cela revient à rajouter une responsabilité à une classe mais sans en changer l'interface. Comparer avec le composite ComposantConcret.Operation : fin de la chaîne Decorateur.Operation() : monComposant.Operation()
    202. 202. l ’Adaptateur : Uml et Exemple
    203. 203. Composite : Le contexte & UML <ul><li>On utilise le Composite lorsque on veut : </li></ul><ul><li>Représenter une hiérarchie d'objets </li></ul><ul><li>Ignorer la différence entre un composant simple et un composant </li></ul><ul><ul><li>en contenant d'autres (interface uniforme) </li></ul></ul>Comparer avec le décorateur
    204. 204. Façade : UML
    205. 205. Flyweight : Poids mouche :UML Utilisation : beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères d'un document PluriGleton
    206. 206. Bridge : UML Rmq : ressemble au state
    207. 207. Les Design patterns de Création <ul><li>Singleton : un et un seul objet visible par tous </li></ul><ul><li>Fabrication : créer un objet en fonction d'un paramètre </li></ul><ul><li>Fabrique abstraite : créer une famille d'objets tous cohérents </li></ul><ul><li>Monteur : construire un objet en différentes étapes </li></ul><ul><li>Prototype : permet de sp é cifier le type d'objets à cr é er en utilisant une instance prototype. Le prototype sera copi é pour cr é er les nouveaux objets. </li></ul>
    208. 208. Le singleton uml
    209. 209. Fabrication : le Design pattern
    210. 210. Fabrication Abstraite : motivation Application IHM Motif IHM windows Application IHM IHM Motif IHM windows L’application utilise IHM sans savoir si il s ’agit de Motif ou bien de Windows
    211. 211. Fabrication Abstraite : Structure Application <<instancie>>
    212. 212. Builder : UML
    213. 213. Prototype <ul><li>Masque au client les complexités de la création de nouvelles instances </li></ul><ul><ul><li>(new, clone, deserialisation, …) </li></ul></ul><ul><li>Permet au client de générer des objets dont le type n’est pas connu. </li></ul><ul><li>Dans certaines circonstances, la copie d’un objet peut être plus efficace </li></ul><ul><ul><li>que la création d’un objet (memberWiseClone du c#) </li></ul></ul>
    214. 214. Etude de cas
    215. 215. <ul><li>Sur le Web de rational : www.rational.com </li></ul><ul><ul><li>UML Notation guide </li></ul></ul><ul><ul><li>UML Semantics </li></ul></ul><ul><ul><li>Object Constraint Language Specification </li></ul></ul><ul><ul><li>Le RUP </li></ul></ul><ul><li>Livres sur UML </li></ul><ul><ul><li>Modélisation Objet avec UML (Muller/Eyrolles) </li></ul></ul><ul><ul><li>Visual modeling with rational Rose and UML </li></ul></ul><ul><li>Livres sur OMT (James Rumbaugh/Masson) </li></ul>UML : Bibliographie
    216. 216. UML : Bibliographie (suite)
    217. 217. WWW CETUS
    218. 218. Autres sites web http://www.numbersix.com/ http://www.m2tech.net/
    219. 219. Corrections des exercices
    220. 220. Use Case : Correction Ex1
    221. 221. Use Case : Correction Ex1
    222. 222. UC : Secrétaire
    223. 223. UC: Détails
    224. 224. UC: Suppléments
    225. 225. IHM : Secrétaire
    226. 226. UC Web
    227. 231. UC : Requirements
    228. 232. Business use case : Correction Ex2 (1) Business Actor Business Worker <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>
    229. 233. Business use case : Correction Ex2 (2) <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>Business Entité Business use case
    230. 234. Diagramme de classe Correction Exo3 (1)
    231. 235. Diagramme de classe Correction Exo3 (2) {or} Construction ContratSimple ContratDouble Contrat Vehicule Maison Couple Roue Personne 0..* 0..* 2 2 Entreprise Voiture 4 4
    232. 236. Diagramme de classe Correction Exo4
    233. 237. Diagramme d'objets Correction Exo5 (1) Famille : Tintin & Milou, locataire
    234. 238. Diagramme d'objets Correction Exo5 (2) Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart ????????
    235. 239. Diagramme d'objets Correction Exo5 (3) Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart
    236. 240. Diagramme d'objets Correction Exo5 (4) Tournesol est locataire d’une partie de Moulinsart
    237. 241. Diagramme d'interaction Correction Exo6 (1)
    238. 242. Diagramme d'interaction Correction Exo6 (2)
    239. 243. Diagramme d'interaction Correction Exo6 (3)
    240. 244. Les développeurs Français Comment revaloriser le métier d'informaticien et d'ingénieur ? Je crois qu'il est important de mieux expliquer ce qu'est le logiciel. Car c'est encore trop abstrait pour beaucoup de monde. Il faut expliquer que c'est une véritable industrie (qui demande donc des investissements et une approche industrielle..) mais également en quelque sorte un art (car les talents sont clés). Ensuite il faut rappeler qu'il y aura plus d'innovation dans les 30 ans qui viennent que dans les 30 ans passés - et que nous sommes donc au cœur d'une industrie qui va générer de la croissance et des emplois . Enfin il faudrait refaire rêver sur les perspectives d'une carrière dans l'informatique et revaloriser les filières techniques . Nous avons chez Microsoft des architectes logiciels qui sont à des niveaux hiérarchiques supérieurs à des managers de grandes divisions. Cette révolution &quot;culturelle&quot; n'a pas encore eu lieu en France mais nous sommes optimistes.
    241. 245. Supplément sur UC : User Story <ul><li>Une User Story est une exigence du système à développer, formulée </li></ul><ul><li>en une ou deux phrases dans le langage de l'utilisateur. </li></ul><ul><li>Exemples de User stories: </li></ul><ul><li>En tant qu'utilisateur, je peux réserver des chambres d'hôtel </li></ul><ul><li>En tant que recruteur, je peux déposer des offres d'emploi. </li></ul><ul><li>Ron Jeffries utilise les 3 C pour la décrire: </li></ul><ul><li>Card (l'histoire est courte et écrite sur une carte 8x13 cm) </li></ul><ul><li>Conversation (les détails de l'histoire sont discutés) </li></ul><ul><li>Confirmation (l'histoire est confirmée par des tests d'acceptation </li></ul><ul><ul><li>rédigés au même moment que celle-ci, au dos de la carte). </li></ul></ul>
    242. 246. Supplément sur UC (1) Un &quot; Use case &quot; modélise un service rendu par le système. Il représente un ensemble de séquences d'actions qu'un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système. <ul><li>Exemples d'intitulés de Use cases: </li></ul><ul><li>S'authentifier, </li></ul><ul><li>Rechercher un livre. </li></ul><ul><li>Ces titres ne sont qu'une partie du &quot;Use Case&quot; qui comporte d'autres </li></ul><ul><li>parties (Acteur, Résumé, Déclencheur, Scénario principal, </li></ul><ul><li>Extensions...). Un &quot;Use Case&quot; est donc plus détaillé, et nécessite un </li></ul><ul><li>travail approfondi d'analyse et de formalisation. </li></ul>
    243. 247. Supplément sur UC (2) User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés But Ils font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciter Ils vont être priorisés et vont ainsi guider les développements Ils mettent en avant les rôles, les différents profils d'utilisateurs Ils ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires (contexte UP) et dans les &quot;Constraints Cards&quot; (contexte XP)) Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomie Ils aident à organiser le modèle Ils facilitent le choix du contenu des itérations Ils peuvent être rédigés par les analystes (UC) ou le client (US)
    244. 248. Supplément sur UC (3)
    245. 249. Le robot Correction
    246. 250. Le robot correction : les UC
    247. 251. Le robot correction : les UC : jouer(1)
    248. 252. Le robot correction : les UC : jouer(2)
    249. 253. Le robot correction : les UC : Deplacer
    250. 254. Le robot correction : les UC : Prendre
    251. 255. Le robot correction : les UC : Deposer
    252. 256. Le robot correction : les UC : Attaquer
    253. 257. Le robot correction : les UC : IHM

    ×