UML par la pratique Hamid EL GHAZI Adil REFAK

Plan Introduction au langage UML Modèles statiques Modèles dynamiques Une démarche d’abord pour guider un processus Etude de cas: TPV (Terminal Point de Vente) Analyse et conception du TPV Etape par Etape Etape 1: Elicitation du besoin client Etape 2: Analyse du besoin client Etape 3: Conception Etape 4: Implémentation

Les Modèles Statiques

Le Modèle Statique: Définition Représentation de la structure statique du système Les composants du système Les liens sémantiques entre ces composants Contenu Objets et classes Liens et associations Généralisation Modules ou paquetages Représentation graphique des concepts du modèle objet Ensemble de diagrammes de classes

Objet et Classe : définitions Une abstraction Un état et un comportement Une entité qui a un sens propre dans le domaine ou dans l'application Un objet est une instance d'une classe Classe Représente un groupe d'objets qui ont une même sémantique et des caractéristiques communes : attributs, opérations, relations avec d'autres objets Personne Hamid:Personne Adil :Personne Classe Objet de classe

Les autres modèles statiques Lien et Association Modélisation et mise en oeuvre d'une association Cardinalité (ou multiplicité) Rôle et contrainte Attribut de lien, Association modélisée en classe Réduction de la multiplicité Agrégat et composition Généralisation Héritage multiple Classe concrète et classe abstraite Paquetage Dépendance Utilité Attribut et association dérivés Diagrammes d’implémentation Conseils pour la qualité d'un modèle objet

Le Modèle Dynamique : Plan Définition Message, événement Vue globale sur les interactions du système cas d’utilisation, scénario diagramme de séquence diagramme de collaboration Diagramme d'états Diagramme d ’activités

Le Modèle Dynamique : Définition Décrit l'évolution au cours du temps du logiciel Description de la vie de chaque objet dans le temps Changement d'états des objets Modification des valeurs des attributs qui caractérise l'objet Modification des liens entre objets Montre le flux de contrôle dans le temps Séquences d'opérations à exécuter en réponse à des événements extérieurs Interactions dans le temps entre objets Envois de messages et réponses aux événements Appels d'opérations

Exemples de scénarios Appel téléphonique Scénario : le numéro appelé est occupé L'appelant décroche le téléphone L'appelant commence à composer le numéro L'appelant termine de composer le numéro La tonalité "occupée" commence à sonner L'appelant raccroche le téléphone Scénario : le numéro appelé n'est pas occupé L'appelant commence à taper le numéro L'appelant termine de taper le numéro Le téléphone commence à sonner L'appelé décroche La conversation se déroule L'appelé raccroche le téléphone

Diagramme de séquence: représentation Un système téléphonique décrocher débuter tonalité composer chiffre(n) débuter tonalité sonnerie sonner arrêter tonalité ... arrêter tonalité sonnerie arrêter sonnerie appelant:Personne :Ligne appelé:Personne connecter raccrocher déconnecter ligne de vie temps L ’envoie d ’un message est toujours horizontal

Diagramme de collaboration Représenter du point de vue structurel et dynamique les objets impliqués dans la mise en oeuvre “d’un but” Modèle expliquant la coopération entre les objets utilisés pour la réalisation d’une opération ou d’un cas d’utilisation Contient Collaboration Contexte structurel des participants: objets, classes, liens, associations, attributs Interaction Séquence de messages échangés entre les objets Numérotés Informations de contrôle du diagramme de séquence sont applicables

:Contrôleur ascenseur Diagramme de collaboration:numérotation simple objet :Passager message 1: appuyer() 2: mémoriser requête() réquisition pilote :Bouton étage :Contrôleur ascenseur 3: allumer() pilote pilote rôle 7: éteindre() lien 4: déplacer() 9: fermer() 8: ouvrir() 5: étage atteint() 6: immobiliser() séquencement :Ascenseur :Porte Collaboration en réponse à l ’appuie sur le bouton de réquisition d ’un ascenseur

Diagramme d'Etats Un diagramme d'états est associé à une classe Il est valable pour tous les objets de cette classe toutes les instances se comporteront de la même façon Il contient tous les scénarios possibles dans lesquels la classe est considérée Un scénario correspond à un chemin dans un diagramme d'état

Exemple simple de diagramme d'états Diagramme d'états d'un Menu Fantôme (popup) bouton droit enfoncé menu inactif menu visible déplacement curseur bouton droit levé

Diagramme d’activités Couloir d ’activité Distribution des activités sur des classes montrer les différentes responsabilités au sein d ’un traitement ou d ’une organisation Dans le business modeling, correspond à des départements différents Client Service ventes Réserve demander service équivalent à la ligne de vie dans le diagramme de séquence prendre commande payer remplir commande livrer commande percevoir commande

Plan Etude de cas: TPV Introduction au langage UML Modèles statique Modèles dynamique Une démarche d’abord pour guider un processus Etude de cas: TPV Analyse et conception du TPV Etape par Etape Etape 1: Elicitation du besoin client Etape 2: Analyse du besoin client Etape 3: Conception Etape 4: Implémentation

Processus de développement logiciel objet

Le Processus de développement objet Unified Process (UP) Unified Process (UP) est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode itérative et incrémentale PU est une méthode de cycle de vie qui complète le langage de modélisation UML.

Unified Process, Exemple: Rational Unified Process (RUP)

Plan Etude de cas: TPV Introduction au langage UML Modèles statique Modèles dynamique Une démarche d’abord pour guider un processus Etude de cas: TPV Analyse et conception du TPV Etape par Etape Etape 1: Elicitation du besoin client Etape 2: Analyse du besoin client Etape 3: Conception Etape 4: Implémentation

Plan Etude de cas: TPV Introduction au langage UML Modèles statique Modèles dynamique Une démarche d’abord pour guider un processus Etude de cas: TPV Analyse et conception du TPV Etape par Etape Etape 1: Elicitation du besoin client Etape 2: Analyse du besoin client Etape 3: Conception Etape 4: Implémentation

Etude de cas - TPV Etape 1: Elicitation du besoin des clients

TPV Itération 1: Diagramme de Use Cases

Use case: Acheter des articles Acteurs: client (déclencheur), caissier Description: un client arrive à une caisse avec des articles qu'il souhaite acheter. Le caissier enregistre les achats et récupère le paiement. A la fin, le client part avec les articles.

Scénarios avec des diagrammes d’activité: Acheter des articles

Use case détaillé: Acheter des articles

Scénario nominal 3. détermine le prix de l'article et ajoute l'information sur l'article à la transaction en cours. affiche la description et le prix de l'article en question. 5. calcule et affiche le montant total de la vente. 8. Enregistre la vente effectuée. 9. imprime un ticket de caisse. 1. ce use-case commence quand un client arrive à la caisse avec des articles qu'il souhaite acheter. 2. le caissier enregistre chaque article. s'il y a plus d'un exemplaire par article, le caissier indique également la quantité. 4. Après avoir enregistré tous les articles, le caissier indique au TPV que la vente est terminée. 6. Le caissier annonce le montant total au client. 7. Le client choisit le type de paiement: a. en cas de paiement cash, voir la section payer cash. b. en cas de paiement par carte de crédit, voir la section payer par carte de crédit. c. en cas de paiement par chèque, voir la section payer par chèque. 10. le caissier donne le ticket de caisse au client. 11. Le client s'e va avec les articles qu'il a achetés. Réponse du système Actions des acteurs

Scenarios alternatifs section 3: saisie d'un identifiant d'article invalide. affichage d'un message d'erreur. section 7: le client ne peut pas payer. annuler la transaction en cours (=exception).

Section: payer par carte de crédit 3. génèrer une demande de paiement par carte de crédit et la transmettre à un centre d'autorisation. 5. Reçoit une réponse favorable de la part du centre d'autorisation. 6.enregistre les informations concernant le paiement par carte de crédit et la réponse favorable. dans la rubrique crédit de son système de comptabilité il enregsitre le montant à reevoir et le compte à créditer (le centre d'auorisation doit l'argent au magasin donc la rubrique crédit doit garder la trace). 7. affiche un message de confirmation de la transaction. 1. ce use case commence quand un client choist de payer par carte de crédit après avoir été informé du montant total de la vente. 2. le client transmet sa carte de crédit au caissier. 4. le centre d'autorisation reçoit la demande, approuve le paiement, et envoie une réponse. Réponse du système Actions des acteurs

Section: payer par chèque 4. génère une demande de paiement par chèque et l'envoie à un centre d'autorisation. 6. reçoit une réponse favorable de la part du centre d'autorisation. 7. affiche un message de confirmation de la transaction. 1. ce use case commence quand un client choisit de payer par chèque après avoir été informé du montant total de la vente. 2. le client rédige un chèque et fournit la preuve de sont identité. 3. le caissier enregistre les informations sur l'identité du client et fait une demande d'autorisation de paiement, et envoie une réponse. Réponse du système Actions des acteurs

Section - payer cash Scénarios alternative: 4 affiche la somme qui doit être rendue au client. 1. ce use case commence quand un client choisit de payer en espèces, après avoir été informé du montant total de la vente. 2. le client donne en paiement une somme en espèces, elle est éventuellement plus élevée que le montant total de la vente. 3. Le caissier enregistre la somme donnée par le client. 5. le caissier encaisse l'argent reçu et sort la monnaie qu'il doit rendre Réponse du système Actions des acteurs Scénarios alternative: section 2: le client n'a pas assez d'argent liquide. il est possible d'annuler la vente ou de choisir une méthode de paiement. section 3: Le tiroir de la caisse ne contient pas assez d'espèces pour qu'il soit possible de rendre la monnaie. Le caissier demande des espèces supplémentaires à son supérieur ou propose une autre méthode de paiement.

Use case: initialiser Acteurs: manager Description: un manager allume un TPV, qui s'initialise lui-même.

Use case détaillé: Initialiser

Scénario nominal 2. Le système TPV s'initialise. 1. ce use case commence quand un manager allume un système TPV. Réponse du système Actions des acteurs

Etude de cas - TPV Etape 2: Analyse du besoin

Diagramme de Séquence Système: Acheter articles (cash seulement)

Diagramme de Séquence Système: Initialiser

Diagramme de Séquence Système: Login/out

Opérations Système-TPV

Diagramme d’états du TPV

Modèle du domaine ou diagramme de classes d’analyse

Etude de cas - TPV Partie 2: Conception

Contrat d’opération: entrerUnArticle(CPU, qte) Opération: entrerUnArticle (CPU, quantite) Responsabilités: Enregistrer la vente d’un article et l’ajouter à la vente en cours. Afficher la description et le prix de l’article Pré-conditions: Il existe une description d’article avec un code CPU valide Post-conditions: S’il s’agit d’une nouvelle vente, il faut qu’elle ait été créée (création d’instance) Et que la vente ait été enregistrée dans le système TPV (relation établie) Une ligne de vente LdV a été créée (création d’instance) LdV a été associée avec une description d’article basée sur le CPU (relation établie) LdV a été associée avec la vente (relation établie) La quantité demandée a été ajustée à la quantité fournie (attribut modifié) Le montant total a été augmenté du montant de description d’article x quantité (attribut modifié) Le prix et la description d’article ont été affichés (événement d’affichage)

Diagramme de Collaboration: TPV::entrerUnArticle(CPU, qte)

Diagramme de Séquence: TPV::entrerUnArticle(CPU, qte)

Contrat d’Oparation: terminerVente Opération: terminerVente() Responsabilités: Enregistrer ce qui constitue la fin de la saisie d’articles de la vente. Pré-conditions: La vente existe et est composée de une ou plusieurs lignes de vente Post-conditions: L’attribut booléen « estTrminee » est positionné à « true » (attribut modifié)

Diagramme de Collaboration: TPV::terminerVente()

Diagramme de Séquence: TPV::terminerVente()

Contrat d’Oparation: paiementCash(montant) Opération: paiementCash(montant) Responsabilités: Enregistrer le paiement, calculer le solde (la monnaie) à rendre et imprimer le ticket. Pré-conditions: La vente existe, elle est composée d’une ou plusieurs lignes de vente et elle est complète Post-conditions: Un objet « pmt » de type PaimentCash a été créer (création d’instance) « pmt » a été associé à la vente (relation établie) pmt.montant a été affecté à « montant » (attribut modifié) Un ticket a été créé (création d’instance) Le ticket a été associé à la vente (relation établie)

Diagramme de Collaboration: TPV::paiementCash(montant)

Diagramme de Séquence: TPV:: paimentCash(montant)

Diagramme de classes de conception

Etude de cas - TPV Partie 2: Implémentation

Exemple C++: TPV.h class Vente; class TPV { public: Vente *venteCourante; entrerUnArticle(String CPU, int quantite); terminerVente(); traiterPaimentCash(int montant); login(String nom, String password); logout(); initialiser(); };

Exemple C++: TPV.cc TPV::entrerUnArticle(String& CPU, int& quantite) { //un objet catalogue est unique ds toute l’appli: desing pattern Singleton DescriptionArticle* da= Catalogue->instance()->getDescriptionArticle(CPU); // creation nouvelle vente si besoin if(venteCourante == NULL) venteCourante= new Vente(); } venteCourante->ajouterLdV(da, quantite); …

Fin.. Questions ?