IFT2251 : Génie logiciel

4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre 4 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon, Hiver 2006 Chap.4, Sect.1, p.2 Copyrights Julie Vachon, 2006 4.1.1 Approches de développement La personnalisation du modèle de processus de développement implique le choix d une méthodologie de développement: Processus : Gère l organisation générale du projet et l ordonnancement des activités. Méthodologie: Démarche complète (modèles, techniques, outils) à suivre pour réaliser chaque activité du cycle de vie du système à développer. Processus de développement méthodologie Chap.4, Sect.1, p.3 Copyrights Julie Vachon, 2006 Diagramme entité-associtation Diagramme de flot de données Diagramme de classes Diagramme d activités Etc. Atelier de génie logiciel (outil CASE) Application de gestion de projet Traitement de texte et éditeur Outil de génération de code Outil de réingénérie Etc. modèles Méthodologie méthodologie outils techniques Technique de gestion de projet Technique d entrevue des utilisateurs Technique de modélisation Technique de programmation Etc. Chap.4, Sect.1, p.4 Copyrights Julie Vachon, 2006

Approche de développement Vers une approche orientée objets Les méthodologies reposent sur une «approche» i.e. une façon particulière de concevoir les choses Deux grandes approches existent Presque toutes les méthodologies se basent sur l une ou l autre de ces approches. Approche classique P5 P6 P8 P4 P7 Données A Données B Objet A Données + Traitements Message Objet C Données + Traitements Objet B Données + Traitements Message Approche orientée objets Chap.4, Sect.1, p.5 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.6 Copyrights Julie Vachon, 2006 Approche axée sur la conception modulaire et la programmation structurée. Méthodologies classiques: SADT (Structured Analysis and Design Techniques) OU approche structurée JSD (Jackson System Development) Technique de l information (James Martin) Merise, Axial, IE, etc. Approche structurée Méthode de développement d un système utilisant des techniques d analyse structurée (1960) de conception structurée (1970) de programmation structurée (1960) Chap.4, Sect.1, p.7 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.8 Copyrights Julie Vachon, 2006

Analyse structurée Diagramme entité - association Diagramme de flot de données Dictionnaire Approche structurée Programmation structurée (au moyen de structures de programmation) Pseudo-code Anglais structuré Graphique d acheminement Conception structurée Organigramme Structurogramme Chap.4, Sect.1, p.9 Copyrights Julie Vachon, 2006 Remarques Critiques: Ensemble de techniques nécessitant d être plus complètes et rigoureuses Analyse et conception idéalisées (cascade ) Accent sur les processus, au détriment des données Absence de planification stratégique Approche qui a évoluée avec le temps: différentes variantes sont nées. Chap.4, Sect.1, p.10 Copyrights Julie Vachon, 2006 L approche objet d hier à aujourd hui Les concepts objet sont stables et éprouvés (issus du terrain) Approche de développement qui voit un système comme une collection d objets interdépendants qui fonctionnent de concert pour exécuter des tâches. 1967: Simula, implémente le concept de type abstrait de données (à l'aide de classes). 1976: Smalltalk implémente les concepts fondateurs de l'approche objet (encapsulation, agrégation, héritage) à l'aide de : classes, associations entre classes, hiérarchies de classes, messages entre objets, etc. 1980: 1er compilateur C++, normalisé par l'ansi. Ensuite: de nombreux langages orientés objets académiques ont étayé les concepts objets : Eiffel, Objective C, Loops... Chap.4, Sect.1, p.11 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.12 Copyrights Julie Vachon, 2006

Méthodologies orientées objets UML (notation) Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE Chap.4, Sect.1, p.13 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.14 Copyrights Julie Vachon, 2006 Analyse orientée objets: Définir tous les types d objets qui sont manipulés par le système (les entités) identifier toutes les interactions avec le système montrer comment les objets se comportent. Conception orientée objets: Définir tous les types d objets nécessaires pour communiquer avec les utilisateurs et les périphériques (interfaces) et pour contrôler l exécution des tâches dans le système (contrôleurs). Identifier les packages, les composants, l architecture. Raffiner la définition de chaque type d objet de façon à pouvoir l implanter avec un langage de programmation. Programmation orientée objets: Écrire les instructions dans un langage de programmation pour définir ce que fait chaque type d objets, y compris les messages que les objets se transmettent les uns aux autres. Chap.4, Sect.1, p.15 Copyrights Julie Vachon, 2006 Analyse orientée objets Diagramme de classes Diagramme de cas d utilisation Diagramme d interaction Diagramme d activités Diagramme d états Programmation orientée objets Instructions (Java, C++ SmallTalk, etc.) Conception orientée objets Diagramme de classes Diagramme de cas d utilisation Diagramme d interaction Diagramme d activités Diagramme d états Diagramme de composants Diagramme de déploiement Chap.4, Sect.1, p.16 Copyrights Julie Vachon, 2006

Remarques Avantages: Approche plus intuitive (?) Réutilisation Critiques: Approche ne convient pas toujours au type de bases de données utilisées (bases de données relationnelles) La frontière entre les phases d analyse et de conception pas très bien définie. On parle ici de processus, de procédures & routines, types de données abstraits, de flots de données Séparation des données et des processus qui les traitent. «Diviser pour régner» Conception par décomposition et factorisation des processus. On parle ici d objets, de méthodes, d attributs, d encapsulation, d envoi de message (interactions). Encapsulation des données et leurs traitements dans une même unité. Penser en termes d objets qui s envoient des messages Chap.4, Sect.1, p.17 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.18 Copyrights Julie Vachon, 2006 Outils de développement Outils CASE (atelier de génie logiciel) Outil de génie logiciel assisté par ordinateur conçu pour aider l analyste à réaliser des tâches de développement. Saltzinger et al. p.94-99 Chap.4, Sect.1, p.19 Copyrights Julie Vachon, 2006 Vers une approche orientée objets Pour exploiter les concepts objets pour l analyse et la conception Définir un langage (syntaxe, sémantique) pour exprimer les concepts objet Définir une démarche d analyse et de conception objet pour Éviter de retomber dans une analyse fonctionnelle Définir des vues qui couvrent tous les aspects d un logiciel à objets Chap.4, Sect.1, p.20 Copyrights Julie Vachon, 2006

Vers une approche orientée objets Besoin d une méthodologie de développement orientée objets MÉTHODOLOGIE = Techniques + Modèles (notation) + Outils N.B. Une méthodologie n est pas un processus de développement 4.1.2. Introduction à UML Méthodologies existantes Les premières méthodologies d'analyse (c.1970) Découpe cartésienne (fonctionnelle et hiérarchique) Exemples : méthode structurée, de Jackson L'approche systémique (c.1980) Modélisation des données et des traitements Exemples : Merise, Axial, IE L'émergence des méthodologies objets (c.1990) Plus de 50 méthodes objet sont apparues Exemples : Booch, Classe Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE Aucune ne s'est réellement imposée Chap.4, Sect.1, p.21 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.22 Copyrights Julie Vachon, 2006 Les premiers consensus (1995) OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles À inspiré les diagrammes de classes OOD (Grady Booch) : vues logiques et physiques Introduit le concept de paquetage (élément d'organisation des modèles) À inspiré les diagrammes de composants, de déploiement, de collaboration OOSE (Ivar Jacobson) : couvre tout le cycle de développement Repose sur l'analyse des besoins des utilisateurs À inspiré les diagramme de cas d utilisation Chap.4, Sect.1, p.23 Copyrights Julie Vachon, 2006 Fusion et synthèse de méthodes dominantes: Unified Modeling Language Standardisation par l OMG UML 0.8 (95) UML 0.9 (96) UML 1.5 (Septembre 03) UML 1.0 (Janvier 97) UML 1.1 (Septembre 97) Autres méthodes Booch OMT OOSE Partenaires industriels UML 2.0 (2004) Chap.4, Sect.1, p.24 Copyrights Julie Vachon, 2006

UML c est UML c est Une norme (OMG) Un langage visuel de modélisation pseudo-formel (rigoureux, non formel) Diagrammes et éléments de modélisation (classes, association, agrégation, package ) Un support de communication qui facilite la représentation et la compréhension Notation graphique : facilite la comparaison et l'évaluation de solutions Notation rigoureuse : limite les ambiguïtés et les incompréhensions Notation abstraite : indépendante des langages de programmation, domaines d'application et processus de développement Chap.4, Sect.1, p.25 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.26 Copyrights Julie Vachon, 2006 UML c est Diagrammes UML et vues Un cadre d analyse par objets Différents types de diagrammes pouvant être regroupés pour offrir différentes vues L analyse et la conception se font graduellement par l élaboration de modèles Pas de barrière stricte entre analyse et conception Les modèles d'analyse et de conception ne diffèrent que par leur niveau d abstraction (ajout de détails) Approprié pour une approche de développement incrémentale et itérative Ajout de diagrammes, raffinement, construction de prototype Chap.4, Sect.1, p.27 Copyrights Julie Vachon, 2006 Modèle UML = Ensemble de diagrammes décrivant le logiciel développé Le modèle UML d un logiciel peut être étudié sous différentes perspectives appelées «vues» Vue = Angle particulier sous lequel un participant au développement voit le logiciel Combinaison de diagrammes intéressant (pour) un participant Chap.4, Sect.1, p.28 Copyrights Julie Vachon, 2006

Diagrammes UML et vues structure implémentation Utilisateur Diagramme d objets Diagramme de classes structure Diagramme de cas d utilisation implémentation Diagramme de composants comportement environnement Diagramme de collaboration comportement Utilisateur environnement Chap.4, Sect.1, p.29 Copyrights Julie Vachon, 2006 Diagramme de séquence Diagramme d états Diagramme d activités Diagramme de déploiement Chap.4, Sect.1, p.30 Copyrights Julie Vachon, 2006 Les vues de UML Vue utilisateur Définit les buts et objectifs des utilisateurs du logiciel. Définit les besoins (services & contraintes) requis par la solution. Vue unificatrice des autres vues en ce sens qu elle sert de référence à leur validation. Vue structurelle Décrit les aspects statiques représentant la structure du logiciel. Identification des éléments du domaine (classes, attributs, paquetages) et des relations (association, compositions, dépendance) entre eux Vue comportementale Décrit les aspects dynamiques et le comportement du logiciel. Spécifie les interactions et collaborations entre éléments du système. Montre la décomposition du logiciel en termes de processus, d interactions entre processus, de synchronisation et de communication entre activités Les vues de UML Vue implémentation Décrit les aspects de structure et de comportement de la solution Description de la réalisation, de l organisation en composants, des contraintes de développement Vue environnementale Décrit les aspects de structure et de comportement du domaine dans lequel la solution est réalisée Décrit les ressources matérielles (disposition, nature, performance) et comment elles sont utilisées par le logiciel Chap.4, Sect.1, p.31 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.32 Copyrights Julie Vachon, 2006

Les diagrammes de UML Deux grandes catégories de diagrammes Diagrammes décrivant les aspects statiques Diagramme de classes : décrit les «données» du logiciel (structure, traitements, relations, contraintes, rôles) Diagramme d objets : diagramme de classes instancié utilisé pour illustrer un exemple particulier Diagramme de composants : montre l'architecture physique du logiciel et l'affectation des objets aux différents composants de cette architecture Diagramme de déploiement : montre la configuration des différents composants à l'exécution et leur distribution Chap.4, Sect.1, p.33 Copyrights Julie Vachon, 2006 Les diagrammes de UML Deux grandes catégories de diagrammes Diagrammes décrivant les aspects dynamiques Diagramme de cas d utilisation : montre à un haut niveau d'abstraction une collection de cas d'utilisation caractérisant le comportement de tout le logiciel Diagramme de séquence : montre l'échange de messages entre objets en fonction du temps Diagramme de collaboration : s'intéresse à la structure de collaboration entre les objets (séquence, itération, concurrence) Diagramme d états : permet de décrire le comportement dynamique d'un objet (changements d états) Diagramme d activités : montre l'ensemble des traitements associés à une classe, une opération ou à un cas d'utilisation (workflow) Chap.4, Sect.1, p.34 Copyrights Julie Vachon, 2006 UML ce n est toutefois pas une méthodologie, ni un processus de développement : c est une notation de modélisation. Le choix du processus de développement dépend des contraintes et du domaine de l application Les auteurs de UML suggèrent l utilisation d un processus de nature incrémentale, itérative et dirigé par les besoins de l utilisateur Processus de développement suggéré Comment développer un logiciel avec UML? Processus itératif et incrémental On développe un modèle UML, soit un ensemble de diagrammes de différents types. À chaque itération Tout au long de l analyse et de la conception Compléter le modèle par de nouveaux diagrammes Raffiner les diagrammes déjà développés pour graduellement réduire leur degré d abstraction Développer des prototypes Valider le système par rapport aux cas d utilisation spécifiés Chap.4, Sect.1, p.35 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.36 Copyrights Julie Vachon, 2006

Élaboration des diagrammes pendant l analyse et la conception En phase d analyse Développement des diagrammes de cas d utilisation, de classes, de séquence (ou collaborations), d activités, d états Phase de conception Raffinement des diagrammes de l analyse Développement des diagrammes de paquetages, de composants, et de déploiement. Documentation sur UML Références www.rational.com/uml/resources/documentation/index.jsp Rational Unified Process : Best practices for Software Development teams Quelques outils CASE supportant UML Commerciaux : Rational Rose, Together TogetherJ, NoMagic MagicDraw, I-Logix Rhapsody, Objecteering Objecteering/UML, Embarcadero Describe, PragSoft UML Studio Gratuits : Poseidon, ArgoUML, ClassBuilder Disponible au DIRO : Rational Rose Se connecter à une machine sous Linux Taper «inclure rose» Démarrer à l aide de la commande «rose &» Chap.4, Sect.1, p.37 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.38 Copyrights Julie Vachon, 2006 4.1.3. Rappel de quelques concepts objets Objet Caractéristiques Un état Poil gris-vert, yeux bruns, heureux, nommé_adrien Un comportement Miauler, courir, sauter, manger Identité Adrien_le_chat_de_PierreTremblay_NAS_999999999 Deux objets peuvent être égaux mais ne sont jamais identiques Adrien_le_chat_de_PierreTremblay_NAS_999999999 Rappel de quelques concepts objets Classe Description générale d un ensemble d objets Attributs (état) Opérations (comportements) Moule (prototype) général sur lequel on crée des objets du même type Partie publique : interface Classe Chat Partie cachée : implantation Instance : objet crée de la classe Le chat Adrien est une instance de la classe Chat Chap.4, Sect.1, p.39 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.40 Copyrights Julie Vachon, 2006

Rappel de quelques concepts objets Rappel de quelques concepts objets Héritage Relation entre deux classe Sémantique de l héritage Enrichissement Substitution Type d héritage Simple (hiérarchie) Multiple (risques de conflits) Classe Félin Classe Chat Message Communication entre deux instances Instance émettrice Nom de l opération Arguments et paramètres de sortie roger fido.attrape(ballon) Chap.4, Sect.1, p.41 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.42 Copyrights Julie Vachon, 2006 Rappel de quelques concepts objets Variable, méthode d instance Variable, méthode de classe Rappel de quelques concepts objets Polymorphisme et liaison dynamique Aptitude d'un même message à déclencher des opérations différentes selon le type dynamique (type réel) de l instance auquel il est destiné Surcharge Dans une classe, un même nom est employé pour définir deux opérations (ou attributs) de signatures différentes Chap.4, Sect.1, p.43 Copyrights Julie Vachon, 2006 Chap.4, Sect.1, p.44 Copyrights Julie Vachon, 2006

Parmi les objectifs d apprentissage Expliquer ce qu est une méthodologie. Expliquer la distinction entre processus de développement, méthodologie, modèle, technique et outil. Décrire les techniques et identifier quelques modèles de l approche structurée. Décrire les techniques et identifier quelques modèles de l approche orientée objets. Expliquer les différences conceptuelles entre l approche structurée et l approche orientée objets. Expliquer ce qu est un atelier de génie logiciel et comment cet outil est utilisé pour le développement de systèmes. Chap.4, Sect.1, p.45 Copyrights Julie Vachon, 2006