Introduction à l’analyse et et à la conception orientée objet Ingénierie Système Introduction à l’analyse et et à la conception orientée objet 1 Catherine Letondal catherine.letondal@enac.fr 05/12/2013

Objectifs pédagogiques Une 1ère compréhension de l’analyse orientée objet ses raisons, ses objectifs Modélisation du domaine d’une application trouver les classes et leurs relations application en TP (2h) : jeu de monopoly dossier IS : système de gestion de la scolarité pour l’ENAC UML : aperçu de la notation

Objectifs pédagogiques

Crédits, bibliographie Luis Basora et Rémi Lafage (ONERA) Craig Larman Coad & Yourdon Martin Fowler

Qu’est-ce que l’analyse et la conception ? L’analyse met l’accent sur l’investigation du problème et des besoins : Analyse objet : compréhension des concepts du domaine métier Analyse des besoins : fonctions, cas d’utilisation La conception élabore une solution répondant aux besoins à partir de l’analyse L’analyse pour construire le bon système et la conception pour construire bien le système (make the right thing vs make the thing right) analyse en général : vise à comprendre un problème, ou un objet quelconque en le décomposant en ses constituants

Qu’est-ce que l’analyse et la conception orienté objet (A/COO) ? Analyse OO : recherche et description des classes conceptuelles (concepts) du domaine et de leurs relations Ex. bibliothèque : ouvrage, prêt, catalogue… un prêt concerne un ouvrage un catalogue liste des ouvrages Conception OO : spécification des classes logicielles à partir de ces concepts, et de la façon dont leurs instances collaborent pour satisfaire les besoins utilisateurs Ex. l’objet logiciel « Livre » a un attribut « titre : String » et une méthode « getChapitre() : Chapitre » terme de classe : + / - synonyme de type -- définit un ensemble d'objets partageant certaines propriétés conception OO : + proche de la programmation, cours java puis cours de COO au printemps en même temps que le cours java et le projet java

Produits de l’A/COO La conception doit produire la spécification d’une solution implémentable Spécification faite de plus en plus en utilisant des modèles graphiques (diagrammes UML) Un modèle de l’A/COO = ensemble diagrammes UML + éléments du diagramme (classes, cas d’utilisation, objets, etc.) + documents textuels - modèle : assemblage de concepts représentant de manière simplifiée une chose réelle déjà existante (objet, phénomène, etc.), en vue de la comprendre, d’en prédire le comportement, etc.

Notation UML Standard OMG très répandu dans l’industrie Né de la fusion de notations de plusieurs méthodes Langage visuel qui permet l’élaboration de modèles Notation très vaste UML 2 : 13 diagrammes différents UML n’est pas une méthode Méthode = notation (ex. UML) + processus de développement + outils L’utilisation concrète d’UML dépend du processus de développement choisi par le chef du projet fusion : Booch, OMT, OOSE (années 1990) Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'Object Management Group (OMG). La dernière version diffusée par l'OMG est UML 2.4.1 depuis aout 2011 Object Oriented Software Engineering (OOSE) (Ivar Jacobson) OMT : Object Modeling Technique (James Rumbaugh)

Perspectives d’utilisation UML UML peut être utilisé pour modéliser depuis plusieurs perspectives Point de vue conceptuel Les diagrammes sont interprétés comme décrivant des entités du monde réel ou du domaine d’intérêt Point de vue des spécifications (logicielles) Les diagrammes décrivent des composants logiciels sans préciser une implémentation Point de vue de l’implémentation Les diagrammes décrivent les implémentations logicielles dans une technologie particulière (Java, C++, …) Ce cours : point de vue conceptuel uniquement (vous n’avez pas encore vu la programmation objet)

Une « classe » dans les différentes perspectives Analyse Conception classes : même terme utilisé aux différents niveaux du processus de développement classe niveau analyse: représente un concept du monde réel pertinent pour l’analyse : décritdes attributs et des relations entre les objets classe niveau conception : spécifie une solution peut être inspirée d’une - ou liée à une - classe d’analyse, mais pas forcément, comme nous le verrons en cours de COO pas du code précise les responsabilités des objets en terme d’opérations à assurer classe niveau logiciel : du code, par ex en java, en C++, en Smalltalk, etc... Grand intérêt de l’approche OO : il y a des liens très forts entre les étapes du processus Codage

Façons d’appliquer UML (I) UML en mode esquisse (sketching) Diagrammes informels et incomplets (souvent tracés à la main) créés pour expliciter un problème ou pour explorer une solution UML en mode plan (blueprint) Diagrammes de conception détaillés pour la pro-ingénierie (génération de code à partir des diagrammes) ou rétro- ingénierie (génération des diagrammes à partir du code) La génération de code n’est que partielle Le développeur doit compléter (et parfois corriger) le code généré - mode esquisse : soit analyse soit conception

Façons d’appliquer UML (II) UML comme langage de programmation Spécification complète et exécutable d’un système logiciel en UML Code exécutable généré automatiquement à partir des modèles UML qui n’a pas besoin d’être revu ni modifié par les développeurs Requiert des outils UML puissants et des diagrammes très détaillés Toujours en cours de développement en termes de théorie, de robustesse d’outils et de facilité d’utilisation

UML en mode esquisse ne pas hésiter à dessiner, discuter autour d’un tableau blanc (+ photos) les diagrammes servent à réfléchir et visualiser : ils peuvent être partiels - mode esquisse aussi avec des diagrammes dessinés avec un outil bien sûr (?)

UML mode blueprint ou programmation bouml.free.fr

Processus de développement Vu le nombre d’activités possible entre l’analyse des besoins et l’implémentation, comment une équipe de développeurs doivent-ils procéder? Les activités A/COO doivent s’inscrire dans le contexte d’un processus de développement Beaucoup de processus existants : Processus classiques : cascade, cycle en V Processus Unifié (UP) : RUP, 2TUP, … Processus agiles : eXtreme programming, Scrum, … - un mot sur l’itération ? un transpa ?

Etude de cas A/COO avec UML Gestion du panier d’une librairie web http://www.dotnetguru.org/articles/UML/agile2/modelisation-agile.html http://www.dotnetguru.org/articles/UML/AgileDotNet2.htm

Besoins Le site doit permettre aux internautes de : rechercher des ouvrages par thème, auteur, mot-clef, etc., se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web. Nous nous restreindrons à la fonctionnalité de gestion du panier virtuel.

A/COO avec UML (UP agile) Analyse objet Analyse de besoins - 2 parties de l’analyse qui se rejoignent dans la conception - titre = A/COO avec UML (UP agile) ou Processus et artefacts ? Conception objet

Modèle de cas d’utilisation Description du UC « Gérer son panier » Préconditions : néant. Scénario nominal : L’Internaute enregistre les ouvrages qui l’intéressent dans un panier virtuel (voir le cas d’utilisation Rechercher des ouvrages). L’Internaute demande l’accès à son panier. Le Système lui affiche l’état de son panier. Chaque ouvrage qui a été préalablement sélectionné est présenté sur une ligne, avec son titre, son auteur et son numéro ISBN. Son prix unitaire est affiché, la quantité est positionnée à « 1 » par défaut, et le prix total de la ligne est calculé. Le total de la commande est calculé par le Système et affiché en bas du panier avec l’indication des frais de port. L’Internaute valide son panier en demandant à effectuer une commande. Extensions 3-4a.    Le panier est vide Le système affiche un message d’erreur à l’Internaute (« Votre panier est vide ! ») et lui propose de revenir à une recherche d’ouvrage. 4a.       L’Internaute modifie les quantités des lignes du panier, ou en supprime. L’Internaute revalide le panier en demandant le recalcul du total Le Système met à jour le total calculé du panier et le cas d’utilisation reprend à l’étape 4 du scénario nominal. 4b.       L’Internaute effectue une nouvelle recherche d’ouvrage (voir le cas d’utilisation correspondant). Le cas d’utilisation reprend à l’étape 1 du scénario nominal. Exigences non-fonctionnelles Le panier de l’internaute est sauvegardé pendant toute la durée de sa visite sur le site Web.

Modèle de cas d’utilisation Diagramme de séquence système (DSS) Modélise la séquence d’interactions acteur-système correspondant à un scénario d’un UC (« Gérer son panier ») Identifie les événements auxquels le système doit réagir Le système « jeBouquine.com » est représenté comme une boîte noire : Les classes implémentant la fonctionnalité sont identifiées plus tard (modèle conception) UML - Diagramme de séquence

Modèle du domaine Diagramme de classes conceptuel En analysant la description du UC « Gérer son panier », on identifie les concepts métier, comme « Panier » , « Livre », ... On modélise ces concepts sous forme de diagrammes de classes contenant uniquement des attributs et des associations On n’identifie pas d’opérations (à attendre à la conception) UML - Diagramme de classes - attributs dérivés si question / total

Modèle de conception Conception préliminaire - Architecture Architecture modulaire Présentation, interactions : classes IHM Logique applicative, dialogue : isole l’IHM de la complexité de la couche métier Logique Métier : classes métier Stockage : responsable de la persistance des objets en BD ou fichiers Architecture en couches UML – Diagramme de packages Cours A/COO - au niveau de la conception, on définit les classes de la solution, de l’application qui va être développée, et on attribue la réalisation des fonctions réalisées par le système à ces classes on pousse aussi un cran plus loin : on précise l’architecture, comment les classes de l’application (couche dite « métier ») se connectent aux niveau des bases de données pour le stockage, et de l’interface utilisateur

Modèle de conception Diagrammes séquence conception (DSC) Le système est composé de plusieurs classes Les opérations des classes sont identifiées Les objets collaborent avec l’envoi de messages afin d’implémenter les opérations système (ex. supprimerLigne() ) pendant la conception, puisqu’on attribue les fonctions à réaliser aux classes, on détaille également comment les classes vont interagir pour réaliser une fonction le système n’est plus une boite noire DSS DSC

Modèle de conception Diagrammes séquence conception (DSC) A faire en parallèle avec les diagrammes de classe conception (DCC) DSC surtout utile pour les opérations complexes DSS DSC

Modèle de conception Diagrammes classe conception (DCC) A réaliser en parallèle avec les DSC Créer les classes de conception métier et applicatives (présentation, dialogue) dans les packages UML de l’architecture Classes métier créées à partir des classes du modèle du domaine Ajouter les opérations aux classes correspondantes aux messages des DSC Affiner les associations (indication de navigabilité, ajout de dépendances, …) Ajouter des types aux attributs En fonction du nombre de classes, un ou plusieurs DCC pour chaque package de l’architecture 3 DCC

Soyez agile et itératifs ! Les description des cas d’utilisation et des diagrammes UML ne sont jamais parfaits Ne pas adopter l’attitude du processus en cascade en déployant toujours plus d’effort pour obtenir des spécifications exactes et exhaustives Entre la démarche en cascade et la « programmation sauvage » existe le développement itératif et incrémental Dans cet approche, les différents modèles sont progressivement affinés, vérifiés et clarifiés grâce à la programmation et aux tests