Ingénierie Système

Introduction à l’analyse et et à la conception orientée objet

1 05/12/2013Catherine Letondal catherine.letondal@enac.fr

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

2

Objectifs pédagogiques

3

Crédits, bibliographie

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

4

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)

5

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 »6

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 7

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

8

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++, …)

9

titreauteur

Livre

titreChapitre

*1

Point de vue conceptuel(modèle du domaine)

Livre

getTitre() : StringgetAuteur : StringgetChapitres : List<Chapitres>

titre : Stringauteur : string

getTitre() : Stringtitre : String

Chapitre

Point de vue des spécifications

ou de l'implémentation(diagramme de classes

de conception)

Diagramme de classes servant à visualiser les concepts du monde réel

*

Diagramme de classesservant à visualiser les

éléments logiciels

public class Livre { private String titre; private String auteur; private List<Chapitre> chapitres;

getTitre() { return titre; } ....}

public class Chapitre {private String titre;

....}

Code Java élaboréà partir de la spécification

logicielle(classes conception)

Monde réel

Une « classe » dans les différentes perspectives

Analyse

Conception

Codage

10

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é

11

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

12

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

13

UML mode blueprint ou programmation

bouml.free.fr

14

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,

…

15

Etude de cas A/COO avec UMLGestion du panier d’une librairie web

http://www.dotnetguru.org/articles/UML/agile2/modelisation-agile.htmlhttp://www.dotnetguru.org/articles/UML/AgileDotNet2.htm16

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.

17

A/COO avec UML (UP agile)

Analyse objet

Conception objet

Analyse de besoins

18

Modèle de cas d’utilisation Description du UC « Gérer son panier »

Préconditions : néant. Scénario nominal :

1. L’Internaute enregistre les ouvrages qui l’intéressent dans un panier virtuel (voir le cas d’utilisation Rechercher des ouvrages).

2. L’Internaute demande l’accès à son panier.3. 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.

4. L’Internaute valide son panier en demandant à effectuer une commande. Extensions

3-4a.    Le panier est vide1. 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.

1. L’Internaute revalide le panier en demandant le recalcul du total

2. 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.

1. Exigences non-fonctionnelles1. Le panier de l’internaute est sauvegardé pendant toute la durée de sa visite sur le site

Web.

19

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équence20

Modèle du domaineDiagramme 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

21

Architecture en couches

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 UML – Diagramme

de packages

Cours A/COO

22

Modèle de conception Diagrammes séquence conception (DSC)

DSS DSC23

• 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() )

Modèle de conception Diagrammes séquence conception (DSC)

DSS DSC24

• A faire en parallèle avec les diagrammes de classe conception (DCC)• DSC surtout utile pour les opérations complexes

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 DCC25

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

26