U M L Analyse Et Conception Objet

UML Analyse et Conception Objet (C++)

Plan du cours & Objectifs
Les concepts objets (3)
Les concepts de base d'une conception objet (31)
La notation UML (43)
UC (52)
Les classes (64)
Les Packages (97)
Les stéréotypes (114)
Diagrammes d'objet (119)
Diagrammes dynamiques (122)
Automates & Activités (131)
Autres diagrammes (138)
Que faire (comment) avec UML?
Utilisation des diagrammes (148)
La démarche (les démarches)
Process UP, agilité, XP(153)
Les DP(172)
Une étude de cas

Les concepts Objets
Le problème
Les avantages des techniques OO
Les concepts
Abstraction
Un programme objet
Encapsulation
Héritage
Polymorphisme

Les problèmes

Les principales causes de l'échec

Les symptômes de l'échec

Programmation Objet : Avantages (1)
Les objets apportent :
Fiabilité-sécurité
Productivité
Maintenabilité
Adaptabilité-Evolutivité
Simplicité
Autreté (Réutilisation, composant, Pg visuelle)

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 ChateauDeSable couleur : Bleu, Blanc, Rouge poids : int ChateauDeSable(p1 : Couleur, p2 : int)

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 JchaiPasQuoiFaire

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 Crier

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 persistant P P P P P P Enfant College Lycée Enfant Enfant Enfant Usine T T

Les types d’Objet
Les objets du monde réel : (Analyse)
Concret (Voiture, Personne, …)
Abstrait (Vente, Négociation,….)
Les objets informatiques : (Conception)
Les objets visibles par l’utilisateur : (IHM)
Les extensions du langage :
range INT(0:5)
smart pointeur
tableau
les programmes
Les conteneurs :
tableau, listes, piles, ....
bouts d’application, les patterns, ...

Les langages de programmation
Assembleur
Programmation
Fortran (1957) (If-For-Variables )
Programmation fonctionnelle-procédurale
PL1 (If-For-Variables + Procédures)
Programmation Typée (I=2.5) ADA
Programmation structurée
C - Exemple Point(x,y) => p.x & p.y
Programmation Objet
Notion de classe (Regroupement des données et des fonctions)
Programmation Logique (Prologue)

Les langages Objet
Simula (67)
Smalltalk
C++ (83) => (87-98)
Java (90)
C# (2000)
Python
Généricité Object Arithmétique

Compilation-Interprétation
Les langages Compilés
C, ADA, Cobol, Fortran , C++
Les langages interprétés
Logo, Prolog, Basic, VB(3-6), vba
Les langages compilés et interprétés
Java, C#, VB.Net
Source Compilateur Binaire Source Interpréteur Source Compilateur Code Intermédiaire Interpréteur MV JIT

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

Héritage Est un

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

Les concepts d'une bonne conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Séparation des interfaces ISP

Exemple : utilisation de la délégation abstraite ( OCP )
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 :

Exemple : ( OCP ) Personne nom : string age : int Personne(n : string, a : int) Appl1 Appl2 BD Appl3 Avec adr
Rajouter un attribut
Rajouter un constructeur
Rajoute un paramètre au constructeur
Faire une nouvelle classe PersonneAdr
Rajouter une méthode getAdr même ds Personne
ID nom age

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
Jouer sur les méthodes plus tôt que sur les attributs
Les gains :
2 versions dans le même exécutable
pas besoin de faire de VNR (faites la quand même)
Appl3

Principes de substitution de LISKOV ( LSP )
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.
Hériter d’une interface
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.

Principes d’inversion des dépendances ( DIP )
Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :" Le passage à l'abstrait est valorisé"

L’abstraction comme technique d’inversion des dépendances ( DIP )
Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous :
Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :

Principes de séparation des interfaces ( ISP )
Pollution d'interface par agrégation de services
On retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanément, comme l'illustre le schéma ci-dessous :

Techniques de séparation ( ISP )
Il existe deux techniques principales de mise en pratique de l'ISP :
L'héritage multiple,
Le Design Pattern "Adapter".

Séparation par héritage multiple ( ISP )
Dans cette approche chaque service est représenté par une classe d'interface dont dérive la classe qui implémente les services.
Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schéma suivant :

Séparation par adaptateur ( ISP )
Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation :

UML
Introduction : notion de modèle
Diagramme de use case
Acteurs, Use case, Business Modeling
Diagramme de classes
Diagramme d'objets
Diagramme dynamique
Diagramme d'interaction
Automates
Diagramme d'activité
Autres diagrammes
Composants et Déploiement
UML 2.0

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é 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

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
Toutes abstractions qui incluent toutes les
capacités et propriétés, ou les aspects de ce
qui est modélisé sans montrer les détails
superflus
Un ensemble cohérent de spécifications ou
d ’information de conception, consistant
typiquement de diagrammes orientés objet
et d ’informations
Firesmith-Dictionary of object tecnology

Un Modèle
Un modèle contient :
Des éléments de modélisation
Des classes (reliées à d'autres classes) avec des opérations et
des attributs
Des informations supplémentaires sur le comportement des
classes (automates, activité)
Des informations concernant le cahier des charges (UC)
La description des fichiers et des machines supportant l'application
Des dessins (vues) explicatifs liés les uns aux autres
Des diagrammes de classes réduits
Des diagrammes montrant comment les objets se partagent le
travail (interaction)
Des diagrammes montrant les objets existant à un moment donné
Toutes ces informations sont organisées dans des packages

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 Jacobson (use case - sdl) Juillet-96 0.9 Janv-97 1.0 Nov-97 1.0 Sept-97 1.1 (OMG) 2000 1.4

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 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.
Un acteur parle au système (Acteur principal)
Le système parle à un acteur (Acteur secondaire)
Un acteur est :
Un humain (via une IHM)
Du soft
Du hard

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.

Diagramme de Use case Description d'un Use Case
Titre et numérotation
Résumé
Les acteurs
Acteur principal
Acteurs secondaires
Pré-conditions
Description
Exceptions
Post-conditions
(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

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 au restaurant <<include>> <<include>> Caissier Payer <<include>> <<extend>> Sommelier Commander pinard <<extend>> Serveur Retourner plat en cuisine <<extend>>

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 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

Supplément sur UC : User Story
Une User Story est une exigence du système à développer, formulée
en une ou deux phrases dans le langage de l'utilisateur.
Exemples de User stories:
En tant qu'utilisateur, je peux réserver des chambres d'hôtel
En tant que recruteur, je peux déposer des offres d'emploi.
Ron Jeffries utilise les 3 C pour la décrire:
Card (l'histoire est courte et écrite sur une carte 8x13 cm)
Conversation (les détails de l'histoire sont discutés)
Confirmation (l'histoire est confirmée par des tests d'acceptation
rédigés au même moment que celle-ci, au dos de la carte).

Supplément sur UC (1) Un " Use case " 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.
Exemples d'intitulés de Use cases:
S'authentifier,
Rechercher un livre.
Ces titres ne sont qu'une partie du "Use Case" qui comporte d'autres
parties (Acteur, Résumé, Déclencheur, Scénario principal,
Extensions...). Un "Use Case" est donc plus détaillé, et nécessite un
travail approfondi d'analyse et de formalisation.

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 "Constraints Cards" (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)

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

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)

Business use case : Ex2
De quelle entreprise s'agit-il?
Trouver les business actor, business entité, business use case
et les business worker
Voyageur
Métro
Station
Couloir
Client
Inspecteur
Wagon
Guichetier
Panneau publicitaire
Conducteur
Clochard
Commerciaux
Voyager
Acheter
Louer

La notation UML Diagramme de classe

Diagramme de classe
Statique :
Ne pas utiliser de verbes d'action pour relier les classes
Une classe isolée est une classe inutile
Doit être vrai tout le temps
Représente LE programme
On ne peut pas tout montrer sur un seul schéma
Un diagramme de classe montre la structure statique du modèle, les choses qui existent, leur structure interne et les relations aux autres choses.

Diagramme de classe Les classes Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}

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 = Est un Composition et Agrégation = Est composé de

De quoi hérite -t-on ? [ PAM-97 p55 ]

Généralisation multiple (1)
La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoint s .
[ PAM-00 p52 ]

Généralisation multiple (2)
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.
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 ?
Par exemple, JAVA ne supporte pas l’héritage multiple.

Classification dynamique [ PAM-00 p58 ]

L’héritage
L’héritage est une technique offerte par les langages de
programmation pour construire une classe à partir d’une ou de
plusieurs autres classes , en partageant des attributs, des opérations
et parfois des contraintes au sein d’une hiérarchie de classes.
Les classes enfants héritent des caractéristiques de leurs classes
parents; les attributs et les opérations déclarés dans la classe
parent, sont accessibles dans la classe enfant, comme s’ils avaient
été déclarés localement.

Conflit de noms [ PAM-00 p60 ]

Les classes abstraites
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.
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.
[ PAM-00 p146 ]

Les interfaces

Finalité des interfaces [ PAM-00 p120 ]
Une interface décrit le comportement d’une classe, d’un composant,
d’un sous-système, d’un paquetage ou de tout autre classificateur

Finalité et réalisation des interfaces

Finalité et réalisation des interfaces
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.

Le polymorphisme [ PAM-00 p63 ]

Les associations
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 .

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

Association réflexive

Qualité des associations
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.
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…
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.

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

Diagramme de classe Associations exclusives Contraintes

Les qualificateurs (1)
Considérons le schéma suivant. Il décrit le fait qu’un avion contient plusieurs sièges qui ont chacun un numéro.
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 .

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.
Le diagramme se lit de la façon suivante: « un avion contient un siège pour un numéro donné ».

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 = b->DonnerSolde(); Economiser (p : Banque) p->Deposer(10000);

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, 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

Notion de package
Un paquetage est un regroupement d’éléments de modélisation,
mais aussi une encapsulation de ces éléments. A l’image des
classes, les paquetages possèdent une interface et une réalisation .
Chaque élément contenu par un paquetage possède un paramètre
qui signale si l’élément est visible ou non à l’extérieur du paquetage.
Les valeurs prises par le paramètre sont : public ou implémentation (privé).

Packages et dépendances
Cela signifie que :
Un élément de P0 au moins utilise un élément publique de P3 et de P1
Un élément de P3 au moins utilise un élément publique de P1
P0, P3 et P1 peuvent utiliser les éléments publiques de p2

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)
A n'est intéressé
par B que pour lui
faire faire Fqq()
B n'est intéressé
par A que pour lui
faire faire Fqq()

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 Rmq3 : Si nécessaire, on peut laisser l'un des deux Rmq1 Rmq2

Dépendances circulaires (RMQ 1)
L'application :
Crée un objet A
Crée un objet B
Présente B à A en tant
que FqqAble
Présente A à B en tant
que FqqAble

Dépendances circulaires (RMQ 1) op1 fqq fqq() A::AddMonB(FqqAble p) B::AddMonA(FqqAble p)

Conclusion sur les dépendances
Regrouper les classes qui vont bien ensemble
Un package peut contenir 15 classes
Éviter les associations bi-directionnelles
Rajouter des classes
Utiliser les interfaces (ou des classes abstraites)
pour découpler
Utiliser les design pattern suivants:
Singleton
Façade
Observeur
Commande
Simple Luxueux

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.
Exemple : un acteur est "comme" une classe, mais il ne fait pas
partie du système. Un acteur pourrait être un stéréotype d'une classe
On peut stéréotyper les classes, les associations, les packages, …..
On peut associer un nouvel icône pour chaque nouveau stéréotype.

Notion de stéréotypes(2)
Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML.
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 .

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 Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Proprietaire Nourriture Lapin Whisky Mariage CompteBanquaire Personne

Diagramme de classe Exo5

La notation UML Diagramme d'objets

Diagramme d'objets
Rappel : Un diagramme de classe représente le programme, il est vrai
tout le temps.
Un diagramme d'objets ou diagramme d'instances représente
une photo du programme à un moment donné.
Les diagrammes de classe doivent être validées par les diagrammes
d'objets
Une classe -> Un Objet [avec un nom]
Rmq : l'héritage ne se voit plus
Une association -> Zéro, un ou
plusieurs liens (cardinalité)
Une dépendance -> Un lien
Rmq : aucune information sur les liens (cardinalité, rôle, navigation, ….)

Diagramme d'objets Exo5
Famille : Tintin & Milou, locataire
Famille : Haddock qui boit du whisky est marié à la Castafiore
Haddock est propriétaire de Moulinsart
Tournesol est locataire d’une partie de Moulinsart
Reprendre le résultat de l'Exo4 et faire les diagrammes d'objets correspondants Modifier éventuellement le diagramme de classe Locataire proprio

La notation UML Diagrammes dynamiques

Diagramme dynamique
Diagrammes d'interaction (Séquence collaboration) servent à
montrer comment les objets se parlent les une aux autres.
Ils montrent le déroulement d'un ou d'une partie d'un Use case
(cas nominal, cas des exceptions, …)
Automates servent à montrer le comportement d'une classe qui
réagit différemment selon son état.
Activités montrent le déroulement d'une méthode d'une classe ou
celui d'un Use case

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
Faire le diagramme
d'interaction correspondant aux changements.
Mettre à jour le diagramme de classe

Automate
Un automate est accroché à une classe et est composé d'états et
de transitions. Les transitions permettent de passer d'un état à
un autre …

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é

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
C'est un mélange d'automate et de diagramme d'activité

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

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 déploiement(1)

Diagramme de déploiement(2)

Structure Composite :le problème

Structure Composite : exemple

Diagramme de temps

Vue d'ensemble des interactions
Les diagrammes d’interaction générale fusionnent les
diagrammes d’activité et de
séquence en autorisant l’utilisation
de fragments (diagrammes de
séquence) avec des points de
décision et des flots de contrôle
(diagrammes d’activité).

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 à 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

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

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

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
Conceptualisation
Analyse
Architecture
Conception
Implémentation
Y
5 Phases Classiques :

Un processus itératif et incrémental (I)
Guidé par les cas d'utilisation
Conceptualisation Analyse Architecture Définition des incréments Conception Implémentation

Processus en Y Les phases
Le but de la conceptualisation est de définir ce que l’on veut (doit) faire (Affinement du cahier des charges)
Le but de l’analyse est de trouver toutes les propriétés d’un système donné indépendamment de toutes implémentations
Les objets du métier
Le but de l’architecture est de trouver toutes les solutions techniques et ceci indépendamment du problème à traiter.
Les objets des informaticiens
Le but de la conception est le mapping d ’une analyse donnée sur une architecture donnée.
Les objets du métier + objets des informaticiens
L ’implémentation doit être presque rien

Conceptualisation (1)
Décrire ce que l’on doit faire(UC) => langage commun
Langage commun => Glossaire
Glossaire => Tout ce qui est mis dans un modèle doit avoir
une définition associée
ExpertMetier ExpertObjet Train Oméoplasmose Sténotype Classe Polymorphisme Relinker Langage commun

Conceptualisation (2)
Les UC :
Décrire les acteurs et ce qu’ils attendent du système
Décrire l’ensemble des messages entrant et sortant du système
Ne pas décrire comment on fait
Décrire l’ensemble des contraintes
Réutilisation d’un autre système
Problème de capacité-volume (des chiffres)
Problème de temps de réponse (des chiffres)
Choix technique quelconque imposé
RMQ : Ne pas se vautrer dans la PatateOide

Architecture
Faire des choix techniques correspondant aux contraintes
Distribution (Obligatoire ou pour des problèmes de performance)
Fiabilité
Persistance
Faire ces choix sans s’occuper de l’application
Valider ces choix par des protos
Découpe du système en sous-système
Simplifier la vie des utilisateurs
Exemple des classes <<Role>>
Customisation des générateurs de code
Customiser et apprendre les outils aux utilisateurs
Production des Make File
Choix et mise en œuvre des design patterns utilisés pour le projet
Normes de programmation et de modélisation
Réutilisation par le principe de la réduction-expansion

Analyse
Partir des diagrammes de UC
Trouver les classes d’analyse (Boundary et Control)
Partir de la description des UC
Trouver les classes entity
Faire tourner le programme
Diagramme de séquence
Cas nominal
Les cas d’exception
Affiner le diagramme statique
(attributs, opérations, nouvelles classes)
Refaire des sous-systèmes
Affiner les classes complexes : Automate
RMQ : Ne pas se vautrer dans l’héritage

Conception
A partir des résultats de l’analyse et de l’architecture:
Modifier les diagrammes d’analyse pour prendre en compte
les choix techniques de l’architecte
Application des design patterns
Persistance
Distribution
Les classes boundaryForm deviennent des sous systèmes
Certains contrôleurs peuvent disparaître, mais ceux qui restent
doivent rester simple
Utiliser l’héritage pour des problèmes de performance
Refaire des diagrammes statiques et des diagrammes dynamiques
RMQ : Ne pas refaire ce qu’a fait l’architecte

Processus : le RUP : Historique

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
Le RUP est :
Itératif
Basé sur une architecture à base de composants
Dirigé par les UC

Processus : le RUP Les phases

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

Méthode
C'est un ensemble de trucs et de règles :
Analyse :
ne donner que des responsabilités
ne pas se vautrer dans l'héritage
trouver les classes B-C-E
Architecture
Persistance, Distribution, Réutilisation d'ancien système, Fiabilité,
Capacité, performances, …..
Conception
Modifier les (grosses) classes persistantes
Garder les contrôleurs pour mettre les transactions
Transformer les boundary en sous système
Organisation du modèle
Utiliser les Use Case réalisation pour documenter le modèle

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

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 France Eric Groise

Design patterns

Classification des patterns Création Comportement Structure

Les Design patterns de comportement (1)
State : un objet réagit selon son humeur
Stratégie : Faire une chose de différentes manières
Template Methode : Faire une chose de différentes manières
(avec une recette de base)
Observer : certains sont intéresses par ce que je fais, mais pas tout le
temps
Visiteur : Rajouter une responsabilité à une classe avec des sous
traitements identiques
Memento : sauvegarder un objet
Iterateur : Balayer une collection
Chaîne de responsabilité : un élément est attendu par un grand nombre d'objets

Les Design patterns de comportement (2)
Commande : encapsule une requête dans un objet, et permet les files
d'attentes, les journalisassions , et retours en arrière (undo).
Médiateur : définit un objet qui encapsule la manière dont un
ensemble d'objets interagissent.
Interpréteur : définit un langage ainsi que sa grammaire, et fournit un
interpréteur pour utiliser la représentation du langage.

State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) +Op3(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
Rajouter une (ou plusieurs) méthode à un objet
(sans la rajouter) !!!!
A utiliser quand une classe ne sait pas ce qu’elle veut et
qu’elle risque de vouloir beaucoup de choses.
La classe fait déjà beaucoup de petites choses
L'objet visité accepte le visiteur (Accept (Visitor v))
Il dit alors à v de visiter (v.Visit())
v fait son travail

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 Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, "Formation"); Grouillot.ProcessRequest(p); p = new Purchase( 24000, "Voiture"); Grouillot.ProcessRequest(p); p =new Purchase ( 99000, "Maison"); Grouillot.ProcessRequest(p); p = new Purchase( 122100.00, "Usine"); Grouillot.ProcessRequest(p); U M V F

Command : UML Configurateur Utilisateur

Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer

Les Design patterns de Structure
Proxy : cacher la complexité d'un objet
Décorateur : Rajouter une responsabilité à une classe sans changer l'interface
Adaptateur : Adapter un objet à un autre
Composite : permet de traiter une structure d'objets de manière uniforme (Des feuilles et des nœuds)
Façade : Représenter, regrouper et diriger un ensemble d'objets
Poids mouche : Partager de nombreux minis objets
Pont : permet de différencier une abstraction de son implémentation, permettant à chacune d'évoluer indépendamment.

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 classe mais sans en changer l'interface. Comparer avec le composite ComposantConcret.Operation : fin de la chaîne Decorateur.Operation() : monComposant.Operation()

l ’Adaptateur : Uml et Exemple

Composite : Le contexte & UML
On utilise le Composite lorsque on veut :
Représenter une hiérarchie d'objets
Ignorer la différence entre un composant simple et un composant
en contenant d'autres (interface uniforme)
Comparer avec le décorateur

Façade : UML

Flyweight : Poids mouche :UML Utilisation : beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères d'un document PluriGleton

Bridge : UML Rmq : ressemble au state

Les Design patterns de Création
Singleton : un et un seul objet visible par tous
Fabrication : créer un objet en fonction d'un paramètre
Fabrique abstraite : créer une famille d'objets tous cohérents
Monteur : construire un objet en différentes étapes
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.

Le singleton uml

Fabrication : le Design pattern

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

Fabrication Abstraite : Structure Application <<instancie>>

Builder : UML

Prototype
Masque au client les complexités de la création de nouvelles instances
(new, clone, deserialisation, …)
Permet au client de générer des objets dont le type n’est pas connu.
Dans certaines circonstances, la copie d’un objet peut être plus efficace
que la création d’un objet (memberWiseClone du c#)

Etude de cas

Sur le Web de rational : www.rational.com
UML Notation guide
UML Semantics
Object Constraint Language Specification
Le RUP
Livres sur UML
Modélisation Objet avec UML (Muller/Eyrolles)
Visual modeling with rational Rose and UML
Livres sur OMT (James Rumbaugh/Masson)
UML : Bibliographie

UML : Bibliographie (suite)

WWW CETUS

Autres sites web http://www.numbersix.com/ http://www.m2tech.net/

Corrections des exercices

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
Voyageur
Métro
Station
Couloir
Client
Inspecteur
Wagon
Guichetier
Conducteur
Clochard
Commerciaux
Voyager
Acheter
Louer
Voyageur
Métro
Station
Couloir
Client
Inspecteur
Wagon
Guichetier
Conducteur
Clochard
Commerciaux
Voyager
Acheter
Louer

Business use case : Correction Ex2 (2)
Voyageur
Métro
Station
Couloir
Client
Inspecteur
Wagon
Guichetier
Conducteur
Clochard
Commerciaux
Voyager
Acheter
Louer
Voyageur
Métro
Station
Couloir
Client
Inspecteur
Wagon
Guichetier
Conducteur
Clochard
Commerciaux
Voyager
Acheter
Louer
Business Entité Business use case

Diagramme de classe Correction Exo3 (1)

Diagramme de classe Correction Exo3 (2) {or} Construction ContratSimple ContratDouble Contrat Vehicule Maison Couple Roue Personne 0..* 0..* 2 2 Entreprise Voiture 4 4

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 Moulinsart ????????

Diagramme d'objets Correction Exo5 (3) Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart

Diagramme d'objets Correction Exo5 (4) Tournesol est locataire d’une partie de Moulinsart

Diagramme d'interaction Correction Exo6 (1)

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 "culturelle" n'a pas encore eu lieu en France mais nous sommes optimistes.

Supplément sur UC : User Story
Une User Story est une exigence du système à développer, formulée
en une ou deux phrases dans le langage de l'utilisateur.
Exemples de User stories:
En tant qu'utilisateur, je peux réserver des chambres d'hôtel
En tant que recruteur, je peux déposer des offres d'emploi.
Ron Jeffries utilise les 3 C pour la décrire:
Card (l'histoire est courte et écrite sur une carte 8x13 cm)
Conversation (les détails de l'histoire sont discutés)
Confirmation (l'histoire est confirmée par des tests d'acceptation
rédigés au même moment que celle-ci, au dos de la carte).

Supplément sur UC (1) Un " Use case " 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.
Exemples d'intitulés de Use cases:
S'authentifier,
Rechercher un livre.
Ces titres ne sont qu'une partie du "Use Case" qui comporte d'autres
parties (Acteur, Résumé, Déclencheur, Scénario principal,
Extensions...). Un "Use Case" est donc plus détaillé, et nécessite un
travail approfondi d'analyse et de formalisation.

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 "Constraints Cards" (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)

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

U M L Analyse Et Conception Objet

by Amine Chkr

Accessibility

Upload Details

Usage Rights

Statistics