UML

1. UML Unified Modeling Language

2. Plan du cours • Caractéristiques de l’objet • Modes de développement • Les activités du projet • Généralités sur UML • Diagrammes Cas d’utilisation • Etude d’opportunité • Analyse des besoins • Modélisation logique structurelle • Objets • Classes • Architecture

3. Plan du cours • Modélisation de la dynamique • Diagramme de séquence • Diagramme de communication • Diagramme d’activité • Diagramme Etat-Transition • Modélisation de l’implémentation et du déploiement • Diagramme de composant • Diagramme de déploiement

4. Caractéristiques de l ’objet • PPourquoi le développement objet? • CComment atteindre ces buts? • QQuelles répercussions sur les méthodes de développement?

5. Caractéristiques de l ’objet Pourquoi le développement objet? • RRéutilisation • DDiminution des coûts de développement et de maintenance • FFlexibilité et robustesse du logiciel • QQualité

6. Caractéristiques de l ’objet Comment atteindre ces buts? Propriétés de l’objet Abstraction Héritage Polymorphisme Encapsulation

7. Commande Caractéristiques de l ’objet • La brique de base d’un logiciel objet est la classe • Cette classe est un module qui contient des données (attributs) et les traitements qui manipulent ces données (opérations = méthodes) classe

8. Caractéristiques de l ’objet Il existe des contraintes de visibilité entre les classes, donc entre les objets Un objet ne peut avoir accès aux propriétés d’un autre objet que selon certaines conditions définies dans le programme retour

9. Commande Référence Date cde Ref devis Créer Modifier Ref devis Caractéristiques de l ’objet Un objet est une instance de classe Tous les objets d’une même classe se décrivent avec les mêmesattributs et ils ont le même comportment

10. Quelles répercussions sur Les méthodes de développement? • LLe développement incrémental • LLe développement agile • LLa réutilisation

11. Modèle incrémental Analyse des besoins Analyse du problème Implémentation Déploiement Conception de la solution Modèle de développement Modèle en cascade Analyse des besoins Analyse du problème Conception de la solution ImplémentationDéploiement retour

12. Modèle de développement Avantages du modèle incrémental • L’implication et la satisfaction de l’utilisateur • La gestion des risques • L’intégration progressive

14. Les activités du projet Elles sont identiques quelque soit le modèle: Cascade, incrémental….

15. Opportunité Analysedu besoin Analyse du problème Conception de la solution Implémentation Activités du projet UML est un langage de modélisation • Toutes ces activités du projet ont une part de modélisation. • Modélisation • Du problème • De la solution

16. Activités du projet Opportunité Chaque activité donne lieu a un rapport qui contient les modèles et des commentaires. Chaque rapport est écrit ou validé par le client Le rapport d’étude d’opportunité + rapport d’analyse des besoins+ la V1 du plan projet constituent le cahier des charges Analysedu besoin Analyse du problème Gestionde projet Conception de la solution Le cahier des charges est un élément essentiel du contrat Implémentation

17. Activités du projetDocuments fondamentaux Rapport d’ Étude d’opportunité Cahierdescharges Plan projet Gestionde projet Rapport d’Analyse du besoin Organisation du projet, délais, coûts, contrôles, normes, procédures

18. Les activités du projetEtude d’opportunité Opportunité On souhaite construire un système informatique pour répondre à un besoin • Qui a ce besoin? • Quel est-il? • Est-il justifié? • Bilan gains-coûts estimés Analysedu besoin Analyse du problème Conception de la solution On modélise le périmètre du projet et son contexte Implémentation

19. Les activités du projet Etude d’opportunité Diagramme de contexte Etudes Gestion de production Client Gestion des stocks L’ellipse représente le périmètre du projet Les acteurs représentent les systèmes ou les personnes qui échangent des informations avec le projet Commercial

20. Les activités du projet Analyse des besoins Opportunité Exprimer les fonctionnalités demandées au système d’information +autres besoins (performance, sécurité, flexibilité…) Analysedu besoin Analyse du problème Conception de la solution Implémentation

21. Les activités du projet Analyse des besoins On modélise l’architecture de l’expression des besoins et les acteurs Le domaine de l’étude est découpé selon les fonctions requises par les acteurs Cas d’utilisation Ma gestion des commandes Ma gestion des commandes Ma gestion des stocks Ma gestion des stocks Pour chaque cas d’utilisation, on rédige un texte qui énonce les exigences de la maîtrise d’ouvrage

22. Les activités du projet Analyse du problème Opportunité Exprimer la structure (Entités; données) et la dynamique ( Processus detraitements) du système désiré Analysedu besoin Analyse du problème Conception de la solution Indépendamment de la technologie Implémentation

23. Client Ventes Entrepôt Acteurs Commande Enregistrerlacommande Processus Contrôler Commande Chef des ventes Préparer commande Expédier Commande Commande annulée Commande expédiée Les activités du projet Analyse du problème Entités Modéliser le métier

24. Les activités du projet Conception de la solution Opportunité Déterminer l’architecture technique. Prendre en compte la technologie (conception structurelle et dynamique) Analysedu besoin Analyse du problème Conception de la solution Ne jamais concevoir avant d’analyser Implémentation

25. Accès Réseau Accès Base D Les activités du projet Conception de la solution Modélisation logique structurelle Modéliser l’architecture technique (structurer le logiciel) Isoler les solutions techniques qui évoluent indépendamment Paquetage IHM Métier

26. Les activités du projet Modélisation logique structurelle Architecture technique • Le découpage du logiciel est représenté par des paquetages • Les paquetages contiennent des classes, des composants ou d’autres paquetages. • La visibilité entre les paquetages est limitée (classe façade) • Une bonne architecture permet la fiabilité et la flexibilité du logiciel

27. Commande Les activités du projetModélisation logique dynamique • Que fait le système informatique? • C Comportement des objets • D Demandes de service • C Conditions Objet Article [s’il y a du stock] Réserver un article réservation Contrôle stock J’ai réservé

28. Les activités du projetChronologie • Etude d’opportunité ou InitialisationDéfinition et opportunité du projet • Diagramme de contexte • Recueil et spécification des besoins. Fonctionnalités du système d’information • Cas d’utilisation • Analyse du problème Étude de la logique du système d’information(Indépendant des technologies) • Modélisation métier (vue logique) • Conception de la solution Décisions technologique • Affinement de la vue logiques • Implémentation (Programmation, diagramme de composants) • Déploiement (Diagramme de déploiement) Activité de gestion de projet pendant toute la durée du projet

30. Généralités sur UML Origine Standard Objectifs Outils Contenu .

31. Généralités sur UMLOrigine Issue des méthodes objet de: • Grady Booch • OMT de James Rumbaugh • OOSE d’Ivar Jacobson       

32. Généralités sur UMLStandard UML est une notation standard Elle a été acceptée par l’OMG (Object Management Group), en novembre 97 Un dispositif est en place à l’OMG qui permet d’améliorer UML de façon continue L’OMG est un consortium international, il réunit environ 800 entreprises. Son but est de définir des standards pour le développement orienté objet

33. Généralités sur UMLObjectifs Modélisation des systèmes informatiques Analyse des besoins Analyse du problème Conception de la solution Implémentation , Déploiement  UML est une notation graphique. Une notation permet de décrire le système informatique avec des concepts adaptés et non ambigus.

34. Généralités sur UMLObjectifs UML est une notation non une méthode • Une méthode contient non seulement une notation mais aussi une démarche de projet • Plusieurs démarches peuvent être associées à la notation UML. Nota: Ne pas confondre les concepts de démarche et les concepts UML

35. Généralités sur UMLObjectifs UML est bien adapté à la démarche itérative Analyse du problème Analyse des besoins Implémentation Déploiement Conception de la solution

36. Généralités sur UML Objectifs UML permet la modélisation du système d’information et du système informatique Et il aide: • à la réalisation • à la réflexion • À la documentation Il deviendra peut-être un langagede réalisation (MDA) Un modèle est une représentation schématique de la réalité destiné à montrer son fonctionnement

37. Généralités sur UML Objectifs • Outils UML • Rational Rose • Together • Objectory (Softeam) • Visio … • Les outils • Permettent la modélisation (dessin et contrôle) • Gèrent un référentiel • Produisent le squelette des programmes • Produisent les DDL des SGBDR • Produisent les interfaces des ORB (Object Request Broker) • Se relient à d’autres outils de développement

38. Métier Gestion articles Client raisonSociale calculerRemise Généralités sur UML Contenu: Éléments • UML propose des élémentsde modélisation qui ont une définition sémantique et un graphisme • Exemples Composant Acteur Classe Paquetage

39. Généralités sur UML Contenu: Diagrammes UML propose 9 types de diagrammes (règles de combinaison des élément standards): Cas d’utilisation Classes Objets Séquence Collaboration Activité États-Transitions Composants Déploiement

40. Client facturer() Généralités sur UML Contenu:Diagrammes Exemple: Diagramme de classe 1..* 1..* 1 1 Commande ClientDétaillant ClientGrossiste

41. Généralités sur UML Contenu:Extension de la notation: stéréotypes • UML est une méthode ouverte • Les stéréotypes permettent l’extension • Un stéréotype est une variante d’un élément standard,il hérite de sa sémantique, il spécifie souvent un rôle. • Exemple: Une façade,un acteur sont des stéréotypes de classe Représentation graphique Client Client «Entité » Chef des ventes « Acteur » Représentation textuelle

43. Gestioncommerciale Direction Gestion de production Bureau d’étude Gestion financière Diagrammes: Étuded’opportunité Cas d’utilisation Représentation du contexte du système • Définir les Limites du système à développer • Relations entre le système et son environnement.

44. Gestioncommerciale Direction Gestion de production Bureau d’étude Gestion financière Étuded’opportunité Diagrammes:Cas d’utilisation • Gestion commerciale représente le périmètre de l’étude • Les acteurs sont des personnes ou des systèmes en relation avec le domaine de l’étude. • Les acteurs sont extérieurs au domaine de l’étude.

45. Analysedes besoins Diagrammes:Cas d’utilisation Pour: • Structurer fonctionnellement le domaine pour décrire les exigences • Répartir le travail et les responsabilités pour la spécification et la validation des besoins. Analyse des marges Directeur commercial Chef des ventes Commissions Fidélisation Responsable CRM

46. Contrat Les cas d’utilisation Validation Les cas d’utilisation guident la MOE dans l’analyse, la conception, la réalisation et les tests. Recette Ils sont sous la responsabilité de la MOA, ils sont la référence des validations et recettes.

47. Les cas d’utilisation Opportunité Analysedu besoin Périmètre du projet Analysedu problèmede la solution L’analyse des besoins Conceptionde la solution Validation La conception du système ImplémentationMise en oeuvre Tests

48. Cas d’utilisation • Chaque cas d’utilisation est accompagné d’un texte et éventuellement de diagrammes • Ceux-ci expriment les exigences du client • Les exigences constituent une partie du contrat entre le client (maîtrise d’ouvrage) et les développeurs (maîtrise d’œuvre)

49. Cas d’utilisationExemple de rédaction • Titre: Préparation de la commande fournisseur • But: Déterminer la date de passation de commande • Version, date de rédaction • Auteur de la rédaction • Acteurs du cas d’utilisation: acheteur • Préconditions: Les demandes d’achat sont valides, elles ont été affectées à l’acheteur qui initialise le processus. • Postcondition: La date de passation de commande de la DA est prévue • Événement initial: Affectation des DA nouvellement arrivées à un acheteur • Description du scénario de base • Description des flots alternatifs

50. Diagrammes:Cas d’utilisation. Acteurs Chef des ventes • Le domaine du projet est découpé en cas d’utilisation • Chaque cas d’utilisation représente une fonction du système informatique dont un acteur métier a besoin • Un acteur métier est un rôle. • Dans la démarche: on recherche d’abord les acteurs métier puis les fonctions dont ils ont besoin. Commissions