Your SlideShare is downloading. ×
Definitiondesbesoinsuml
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Definitiondesbesoinsuml

2,005
views

Published on

UML - MOA …

UML - MOA
Maitrise d'oeuvre ouvrage

Published in: Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,005
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
244
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.  
  • 2. Plan du cours
    • Introduction
      • Le problème, Les techniques objet, Genèse d’UML
    • Intro UML
      • Les 13 diagrammes, les diagrammes expression de besoin, notion de modèle
    • Les cas d’utilisation (modélisation métier et application)
    • Les diagrammes statiques
      • Le diagramme de classe et de package
    • Les diagrammes dynamiques
      • Séquence, automate, activité,…
    • Etude de cas
  • 3. Le problème
  • 4. Importance de l’expression des besoins Source Borland (Juin 2003 à Juin 2004)
  • 5. Il faut une méthode
  • 6. 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
  • 7. UML
  • 8. Les cycles de DVP
    • Conceptualisation
    • Analyse
    • Conception
    • Codage
    • Tests unitaires
    • Intégration
  • 9.
    • 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
  • 10.
    • 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é
    Architecte Analyste-Concepteur
  • 11.
    • 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
  • 12. UML & Méthode
  • 13.
  • 14.
    • XP propose une un ensemble de pratiques organisées autour des principes suivants :
    • Le client (maîtrise d'ouvrage) pilote lui-même le projet , et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines).
    • L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements.
    • L'équipe s'organise elle-même pour atteindre ses objectifs , en favorisant une collaboration maximale entre ses membres.
    • L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé.
    • Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides.
    Regis Medina
  • 15. Source : the corporate Use Of Object Technology
  • 16. Dvp = 20% Maintenance = 50%
  • 17. Les Concepts Objet
  • 18.
    • 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 est fait pour:
    • Spécifier
    • Comprendre
    • Communiquer
    • Documenter
    • source : UML-User Guide
    Un dvp Objet
  • 19.
    • 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
  • 20.
    • Un modèle contient :
    • Un diagramme de Use Case
      • Des diagrammes d’interraction
      • Des diagrammes d’automate
      • Des diagrammes d’activité
      • Des diagrammes de vues d’ensemble des interractions
    • Des diagrammes de classes
    • Les contraintes techniques
    • Toutes ces informations sont organisées dans des packages
  • 21. Introduction
  • 22.
  • 23. Les diagrammes pour la définition des besoins
  • 24.
  • 25.
  • 26. Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants
  • 27. 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.
  • 28. {ceci est une contrainte} Rmq : On peut écrire des contraintes en OCL Une contrainte est raccrochée à un élément de modélisation
  • 29. Diagramme de Use case
  • 30.
    • 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
    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.
  • 31. Un Cas d’utilisation ( use case ) est une fonctionnalité importante pour un acteur 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. Description
  • 32.
  • 33.
    • 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
  • 34. 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>>
  • 35.
  • 36. Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
  • 37. 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)
  • 38.
  • 39. Cas d'utilisation : Essentiellement un ensemble d'interactions Acteur: Élément externe qui interagit avec le système (humain ou autre système) Scénario : Une lecture particulière d'un cas d'utilisation, son instanciation Relation de communication : Le vecteur de l'échange (l'interaction) entre acteur et système <<include>> : Relation qui, lorsqu'elle existe entre deux cas, est obligatoirement appliquée. C'est une dépendance entre le cas source qui inclut . <<extend>> : Relation de dépendance optionnelle. Il s'agit d'étendre les interactions d'un cas avec celles d'un autre. Spécialisation de cas : La même finalité, mais obtenue par des interactions différentes .
  • 40. 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.
  • 41. 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 Utilisé par L’entreprise Comment fait l’entreprise Les objets de l’entreprise Utilisateur Employés de L’entreprise Ce que fait l’entreprise
  • 42. Selon Alistair Cockburn , il existe trois niveaux principaux qu'il situe allégoriquement par rapport à un niveau de référence qui est &quot;celui de la mer&quot;. Mouette : Au-dessus de la mer, représente plutôt des cas d'utilisation métier Mer: Le cas d'utilisation &quot;système&quot; dans son acceptation classique : une situation qui génère une bonne valeur ajoutée pour l'un des utilisateurs (acteurs) ; une fonctionnalité au sens habituel du terme (un micro-onde offre deux fonctionnalités principales qui sont &quot;Décongélation&quot; et la &quot;Cuisson&quot;). Crabe : Quelques interactions qui ne constituent pas vraiment une situation d'utilisation en tant que telle. Ce seront généralement des cas qui seront réinjectés dans le modèle via des relations include ou extend .
  • 43.
    • De quelle entreprise s'agit-il?
      • Trouver les acteurs, entités (objets), use case, les employés …..
    • Voyageur
    • Métro
    • Station
    • Couloir
    • Client
    • Inspecteur
    • Wagon
    • Guichetier
    • Panneau publicitaire
    • Conducteur
    • Clochard
    • Commerciaux
    • Voyager
    • Acheter
    • Louer
  • 44. Diagramme de classe
  • 45.
    • 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.
  • 46. Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}
  • 47.
  • 48.
  • 49. Association & Dépendance
    • Les associations (relations) connectent deux ou plusieurs classes.
    • Elles peuvent porter un nom.
    • Si une association connecte une classe à elle-même, elle est dite réflexive.
    • Une classe peut simplement dépendre d’une autre classe
  • 50. 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
  • 51.
  • 52.
  • 53.
  • 54.  
  • 55. 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
  • 56. 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é).
  • 57.
    • 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
  • 58.
  • 59. K L A B I E J G D H C F
  • 60. Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
  • 61.
  • 62.
  • 63. Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Location Vente Nourriture Lapin Whisky Mariage CompteBanquaire Personne
  • 64. Diagrammes dynamiques
  • 65.
    • 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
  • 66. new
  • 67.
  • 68.
  • 69.
  • 70. Un automate est accroché à une classe (ou un UC) et est composé d'états et de transitions. Les transitions permettent de passer d'un état à un autre …
  • 71. É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é
  • 72.
  • 73.
  • 74. 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
  • 75.
  • 76.
  • 77.
    • 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é).  
  • 78. Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Component Deployment Code Code Code Code Tests
  • 79. Patron du dossier d'expression des besoins Projet <<nom du projet>> Version < ?. ?> Historique des révisions Introduction Présentation du document Objectifs du document Contenu du document Description du Métier (Optionnel)  Les entités métiers (diagramme de classe)  Les processus métiers (diagramme d’activité + états des objets) Description du produit  Les objectifs du produit, les avantages qu'apporte le produit  Les fonctionnalités du produit (UC)  Les utilisateurs du produit et leurs caractéristiques (acteurs humains)  Les contraintes du produit, règles métier  Les hypothèses (conditions d'utilisation) et les dépendances (acteurs système)
  • 80. Les besoins-exigences non fonctionnels Exigence en terme de qualité  Utilisabilité (Maniabilité) [ Par exemple: le temps de formation nécessaire à la prise en main du produit, exigence de standardisation, …]  Fiabilité (Conformité) [ On trouve ici les caractéristiques principales de la fiabilité comme, par exemple: temps moyen entre 2 pannes, le temps moyen d'intervention,…]  Performance (Efficacité) [ Par exemple: Temps de réponse moyen et maximal pour une transaction, le nombre d'utilisateurs simultanés, les fonctionnements dégradés acceptables, l'utilisation des ressources (mémoire, disque, communications,...) ]  Documentation et aide en ligne Autres exigences  Contraintes de conception (langage, machine, BD persistence,…..)  Les composants non développés dans l'application (Réutilisation)  Les interfaces (API, Corba,….)  acteurs secondaires?  Les interfaces utilisateurs, érgonomie…..construites à partir des boundary
  • 81. Objectifs  : décrire les besoins d’un système informatique. La première description est faite par le client.   Cas de l’étude  : logiciel de Gestion d’Affaires (GA) demandé par un client tertiaire, 250 personnes, 10000 affaires).   Le logiciel de gestion d’affaires doit permettre de gérer, par collaborateur, les affaires dont il s’occupe. Une affaire peut posséder un nom, un client, une date de création, une date de fin prévue, un état (en cours, en retard, en cours mais en retard, abandonnée, terminée), une description. Les actions possibles sur une affaire sont : création, modification, suppression. Les affaires devront être présentées en 4 listes : en cours et en retard, en retard, toutes, terminées. La sélection doit se faire par collaborateur, ou bien par client.
  • 82.
    •   Faire un diagramme de Use Case
    • Faire un diagramme d’activité, présentant les étapes pour créer, modifier et supprimer une affaire.
    • Faire un diagramme de classe
    • Faire un Automate concernant les affaires
    • Faire un diagramme de séquence
    • Dessiner l’IHM
    1 2 3 4 6 5
  • 83.
  • 84.
  • 85.
  • 86.
  • 87.
  • 88.
  • 89.
  • 90.
  • 91.
  • 92.
  • 93.
  • 94.
  • 95.
  • 96. Business Actor(client) Business Worker(employée)
    • Voyageur
    • Métro
    • Station
    • Couloir
    • Client
    • Inspecteur
    • Wagon
    • Guichetier
    • Panneau publicitaire
    • Conducteur
    • Clochard
    • Commerciaux
    • Voyager
    • Acheter
    • Louer
    • Voyageur
    • Métro
    • Station
    • Couloir
    • Client
    • Inspecteur
    • Wagon
    • Guichetier
    • Panneau publicitaire
    • Conducteur
    • Clochard
    • Commerciaux
    • Voyager
    • Acheter
    • Louer
  • 97.
    • Voyageur
    • Métro
    • Station
    • Couloir
    • Client
    • Inspecteur
    • Wagon
    • Guichetier
    • Panneau publicitaire
    • Conducteur
    • Clochard
    • Commerciaux
    • Voyager
    • Acheter
    • Louer
    • Voyageur
    • Métro
    • Station
    • Couloir
    • Client
    • Inspecteur
    • Wagon
    • Guichetier
    • Panneau publicitaire
    • Conducteur
    • Clochard
    • Commerciaux
    • Voyager
    • Acheter
    • Louer
    Business Entité(les objets) Business use case Les fonctions
  • 98.
  • 99.
  • 100.
  • 101.
  • 102.
  • 103.
  • 104.
  • 105.
  • 106. delete valider