Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Bilal Hussein husseinbilal@ul.edu.lb 2017-2018 SOMMAIRE  Introduction à la con

Bilal Hussein husseinbilal@ul.edu.lb 2017-2018 SOMMAIRE  Introduction à la conception objet  Conception à base de Patrons  Patrons de création (Creational design pattern)  Patrons de structure  Patrons de comportement INTRODUCTION A LA CONCEPTION OBJET Méthodes de conception à base: - Fonctionnelles - Objet - Composant CONCEPTION FONCTIONNELLE  Décomposition en sous systèmes  Hiérarchisation et partage de ressources  Modularité Structuration de l’application en modules fonctionnels  Anciennes méthodes fonctionnelles (SADT, SASD) Principe : Séparation des données et des traitements  Diagramme de Structure (SD, Yourdon) Interaction entre les modules.  Diagramme de flot de données DFD (SA, Yourdon) Exemple de diagramme de Structure entre les modules A, B, C, D, E et F Exemple d’un diagramme DFD CONCEPTION OBJET  Regroupement des données-traitements  Diminution de l’écart entre monde réel et représentation informatique Abstraction  Localisation des responsabilités Encapsulation  Identification des relations entre objets Association, Généralisation, Composition, Agrégation, etc. CONCEPTION OBJET Méthodes Objet  OOA (Cood et Yourdon, 90)  OOD (Booch, 91-93)  OOM merise (Bouzeghoub, 93)  OOSE (Jacobson, 94)  OMT (Rumbaugt, 93)  Unifié en 1995, UML V0.8 Unified Modeling Language Première version standardisé par OMG UML 1.0 en 97 De la version UML 1.2 (1998) à la version UML 2.5(2013) CONCEPTION A BASE DE COMPOSANTS  Identification des parties autonomes du système  Composants réutilisables  Conception par assemblage  Architecture 3-tiers Structuration de l’application en trois niveaux: Présentation, Métier et Données UNIFIED MODELING LANGUAGE UML Rappel Grady Booch James Rumbaugh Ivar Jacobson Le "Langage Unifié de Modélisation" constitue une synthèse des méthodes Booch, OMT et OOSE. 1.3. DE OMT À UML Booch method OMT Unified Method 0.8 OOSE Other methods UML 0.9 UML 1.1 UML 1.3 UML 1.0 2. MODÉLISATION UML 2.1 VUE D ’ENSEMBLE Use Case Diagrams Use Case Diagrams Diagrammes de cas d’utilisation Scenario Diagrams Scenario Diagrams Diagrammes de collaboration State Diagrams State Diagrams Diagramme de composan Component Diagrams Component Diagrams Diagrammes de déploiement State Diagrams State Diagrams Diagrammes d’objets Scenario Diagrams Scenario Diagrams Diagrammes d’états-transitions Use Case Diagrams Use Case Diagrams Diagrammes de séquence State Diagrams State Diagrams Diagramme de Classes Diagrammes d’activités Modèle 2. MODÉLISATION UML 2.2 LE R.U.P. (RATIONAL UNIFIED PROCESS) temps Inception Elaboration Construction Transition  Inception Définir le cadre du projet  Elaboration Analyser le domaine, établir une architecture solide  Construction Développer le système  Transition Fournir le système aux utilisateurs finaux 2. MODÉLISATION UML 2.2 LE R.U.P. (RATIONAL UNIFIED PROCESS) Une itération est une séquence d’activités planifiée et validable aboutissant à une version exécutable. Arch Iteration ... Dev Iteration Dev Iteration ... Trans Iteration ... Version Version Version Version Version Version Version Version Prelim Iteration ... Inception Elaboration Construction Transition 2. MODÉLISATION UML 2.2 LE R.U.P. : RELATION PROCESSUS - MODÈLE UML Exigences Conception Implémentation Test Analyse Dépl. Use Case Concept. Impl. Analyse Test Modèles 2. MODÉLISATION UML 2.2 LE R.U.P. : RELATION MODÈLE - DIGRAMMES UML Use Case Collaboration Composants Déploiement Objets Etats- transitions Séquence Classes Activités Use Case Concept. Dépl. Impl. Analyse Test Diagramme Modèles 2. MODÉLISATION UML 2.2 LE R.U.P. : RELATION MODÈLE - DIGRAMMES UML Use Case Collaboration Composants Déploiement Objets Etats- transitions Séquence Classes Activités Use Case Concept. Dépl. Impl. Analyse Test Diagramme Modèles Inclus . Sous-sytèmes et paquetages 2. MODÉLISATION UML 2.2 LE R.U.P. : RELATION MODÈLE - DIGRAMMES UML Use Case Collaboration Composants Déploiement Objets Etats- transitions Séquence Classes Activités Use Case Concept. Dépl. Impl. Analyse Test Diagramme Modèles 2. MODÉLISATION UML 2.2 LE R.U.P. : RELATION MODÈLE - DIGRAMMES UML Use Case Collaboration Composants Déploiement Objets Etats- transitions Séquence Classes Activités Use Case Concept. Dépl. Impl. Analyse Test Diagramme Modèles Les tests font références à tous les autres modèles et les diagrammes correspondants. 2. MODÉLISATION UML 2.3 MODÉLISATION CONDUITE À PARTIR DES USE CASES Analyse Analyste Conception Architecte Programmeur Tests Testeur Les use cases permettent de communiquer entre différents groupes de personnes suivant les étapes de la réalisation du projet. Ils sont consultés à tout moment. Exigences Client Les cas d ’utilisation Implémentation 2. MODÉLISATION UML 2.4 MESSAGERIE Réalisation d'une messagerie entre plusieurs postes PC Unix interconnectés sur un réseau ETHERNET. Pour pouvoir utiliser la messagerie, il faudra être reconnu par l’application (notion d’abonné). C'est l'administrateur qui décide de l'inscription d'un abonné. Chaque abonné après connexion pourra ainsi saisir un message et l'envoyer à plusieurs autres abonnés. Il pourra consulter les messages qui lui sont destinés. Les messages lus seront conservés 1 mois maximum, les messages non lus, 1 semaine. Si un abonné est connecté, il sera prévenu en temps réel de l'arrivée de nouveaux messages. L'ensemble des informations d'administration seront centralisées sur un serveur. Tout abonné devra pouvoir se connecter depuis n'importe quel poste sur le réseau. 2. MODÉLISATION UML 2.5 MESSAGERIE Représentation des éléments physiques Poste PC Unix Poste PC Unix Serveur Réseau Ethernet Utilisateur utilisateur administrateur connexion connexion Inscription abonné Envoi message Réception message Envoi message Réception message • Vérification abonné • stockage messages • routage messages { 2. MODÉLISATION UML 2.4 MESSAGERIE Objectifs Formaliser la phase en amont de l'analyse et donner des éléments qui permettront de valider cette analyse. Définir les acteurs externes et leur interaction avec le système. Un cas d'utilisation décrit de façon générique et d'un point de vue organisationnel, une transaction complète impliquant plusieurs objets. Les diagrammes de cas d'utilisation associés à un haut niveau d'organisation permettent généralement de définir les limites du système et d'identifier les intervenants extérieurs. Définir les premiers éléments d’architecture système. 2. MODÉLISATION UML 2.4 MESSAGERIE : LES CAS D’UTILISATION création abonné lecture message envoi message déconnexion suppression abonné paramétrage Administrateu r Utilisateur connexion 2.5. DIAGRAMME DE USE CASE DÉFINITION Un diagramme de use case donne la définition des limites du système présente les relations entre des acteurs et des use case (cas d ’utilisations) permet l ’identification des intervenants extérieurs est composé d ’un graphe d ’acteurs, d ’un ensemble de use case, éventuellement d ’interfaces, et des relations entre ces éléments Un use case est un ensemble cohérent de fonctionnalités offertes par le système donne les fonctionnalités d ’un système telles que vues par un intervenant extérieur au système Donne lieu à une description textuelle complète Un actor (acteur) est un ensemble cohérent de rôles que peut avoir un intervenant extérieur interagissant avec le système a un rôle par use case. 2.5. DIAGRAMME DE USE CASE REPRÉSENTATION Confirmer réservation Vérifier planning Emplo yé Pilot e Confirmer vol Acteur Use case 2.5. DIAGRAMME DE USE CASE RELATION DES ACTEURS Relations standards des acteurs association : communication entre les instances d ’un acteur et celles d ’un use case (seule relation entre use case et acteur) généralisation : une généralisation entre un acteur A et un acteur B indique qu ’une instance de A peut communiquer avec les mêmes instances de use case que celles d’une instance de B Bon de commande Ligne de crédit Vendeur Superviseur 1 1 * * 2.5. DIAGRAMME DE USE CASE RELATIONS DES USE CASE Relations standards des use case extension : une extension entre le use case A et le use case B indique qu ’une instance de B peut être étendu (i.e. sujet à des conditions particulières définies par l ’extension) par le comportement de A; stéréotype « extend » généralisation : une généralisation de A vers B indique que A est une spécialisation de B inclusion : une inclusion de A vers B indique qu ’une instance de A inclura aussi le comportement spécifié par B; stéréotype « include » 2.5. DIAGRAMME DE USE CASE RELATIONS DES USE CASE Informations Client Produit commandé Mode de Paiement Extension commande supplémentaire: après création de commande Prise de commande Catalogue produits 1 * Vendeur « include » « include » « include » « extend » le Vendeur veut consulter le Catalogue 2.5. DIAGRAMME DE USE CASE RELATIONS ENTRE LES CAS D ’UTILISATION Virement Virement par minitel <<extend>> Le client utilise un Minitel <<utilise>> Identification Client 2.5. DIAGRAMME DE USE CASE USE CASE ET SCÉNARII Un cas d'utilisation décrit le comportement d’un système, d’un sous-système, voire d’une classe, du point de vue de l’utilisateur (au sens large). Les diagrammes de cas d'utilisation permettent de définir les limites du système et d'identifier les intervenants extérieurs Un scénario est une instance de cas d'utilisation qui sert à décrire les interactions non triviales entre objets. Il décrit un ensemble d'interactions entre des objets impliqués dans une réalisation particulière et inconditionnelle (UML introduit la représentation de conditions) du système Un diagramme de séquences représente un scénario en privilégiant l'aspect temporel des relations entre objets Un diagramme de collaboration représente un scénario en privilégiant l'aspect topologique des relations entre objets. 2.5. DIAGRAMME DE USE CASE LES DIAGRAMMES DYNAMIQUES Rappel : un scénario décrit un ensemble d'interactions entre des objets impliqués dans une réalisation particulière et inconditionnelle d ’un cas d ’utilisation. Développer les scénarios (texte), diagramme de trace d'évènements, diagramme d’interactions entre objets, langage formel (style SDL) : • ils précisent les cas d'utilisation définis au départ en privilégiant l’aspect uploads/Ingenierie_Lourd/ conception-des-si-a-base-d-x27-objets.pdf