Julie Vachon, Hiver 2003

IFT6803: Génie logiciel du commerce électronique

Chapitre 2: Analyse orientée objetSection 1: Introduction au paradigme objet et à UML

Chap.2, Sect.1, p.2

Sommaire Chapitre 2, Section 1

“Introduction au paradigme objet et à UML”

2.1.1 Vers une approche orientée objet…2.1.2 Introduction à UML2.1.3 Rappel de quelques concepts objets

Chap.2, Sect.1, p.3

2.1.1 Vers une approche orientée objet…

Approche à saveur « fonctionnelle »

(procédures & routines, types de données abstraits, DFD etc.) …

Approche logique, cohérente, intuitive

« Diviser pour régner »Séparation des données et des traitementsConception par décomposition et factorisation respectives des données et traitements.

dfd-0F0

Données AB

F1dfd-1 F2

F3

dfd-2

F4

F6

F7

F5F8

Données BDonnées A

Chap.2, Sect.1, p.4

Vers une approche orientée objet…Approche « orientée

objet »UML

Approche un peu moins intuitive

Penser en termes d’objets qui s’envoient des messagesEncapsulation des données et leurs traitements dans une même unité.

msg

Objet CDonnées + Traitements

Objet ADonnées + Traitements msg

Objet BDonnées + Traitements

Chap.2, Sect.1, p.5

Vers une approche orientée objet…

Tel que vu dans la phase de conception, la modularisationdoit tendre vers

Minimisation du couplageMaximisation la cohésion

Qualités qui facilitent la maintenance du système.

L’approche orientée objet favorise un bon designEncapsulation des données et des traitements (cohésion forte – favorise cohésion fonctionnelle)Masquage d’information (couplage faible – limité au couplage par les données)Héritage (généralisation et réutilisation)

Chap.2, Sect.1, p.6

Vers une approche orientée objet…

L’approche objet d’hier à aujourd’hui

Les concepts objet sont stables et éprouvés (issus du terrain)

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.2, Sect.1, p.7

Vers une approche orientée objet…

Pour exploiter les concepts de l’approche orientée objet lors de l’analyse et de la conception…

Définir un langage (syntaxe et sémantique) pour exprimer les concepts objet qu’on utilise, afin de pouvoir

Représenter concepts abstraits (ex. graphiquement)Limiter ambiguïtés (langage commun)Faciliter l’analyse (modèle pour comparaison et évaluation de solutions)Guider la conception et l’implémentation (développement de types abstraits de données)

Définir une démarche d’analyse et de conception objet pour:Éviter de retomber dans une analyse fonctionnelle.Définir des vues qui permettent de couvrir tous les aspects d’unsystème avec concepts objets.

Chap.2, Sect.1, p.8

Vers une approche orientée objet…

Besoin d’une méthode de développement orientée objet

MÉTHODE

=

concepts +

notation +

processus de développement

Chap.2, Sect.1, p.9

2.1.2 Introduction à UMLMéthodes existantes

Les premières méthodes d'analyse (années 70)Découpe cartésienne (fonctionnelle et hiérarchique)Exemples:

Méthode structurée (DFD, dictionnaire de données, etc.)Méthode de Jackson et programmation structurée

L'approche systémique (années 80)Modélisation des données + modélisation des traitements Exemples: Merise, Axial, IE, etc.

L'émergence des méthodes objet (1990-1995)Plus de 50 méthodes objet sont apparues durant cette périodeExemples: Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE…

-- Aucune méthode ne s'est réellement imposée. --

Chap.2, Sect.1, p.10

Introduction UMLLes premiers consensus (1995)

OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système

Issue du centre de R&D de General Electric. Notation graphique riche et lisible.A inspiré: diagrammes de classes…

OOD (Grady Booch) : vues logiques et physiques du système Définie pour le DOD, afin de rationaliser de développement d'applications ADA, puis C++. Ne couvre pas la phase d'analyse dans ses 1ères versions (préconise SADT). Introduit le concept de package (élément d'organisation des modèles).A inspiré: diagrammes de composants, de déploiement, de collaboration…

OOSE (Ivar Jacobson) : couvre tout le cycle de développement Issue d'un centre de développement d'Ericsson, en Suède. La méthodologie repose sur l'analyse des besoins des utilisateurs.A inspiré: diagramme de cas d’utilisation…

Chap.2, Sect.1, p.11

Introduction UML

Fusion et synthèse de méthodes dominantes:UML (Unified Modeling Language)

UML 0.8 (95)

UML 0.9 (96)

UML 1.0 (Janvier 97)

UML 1.1 (Septembre 97)Standardisation

par l ’OMG

Autres méthodes Booch OOSEOMT Partenaires industriels

Chap.2, Sect.1, p.12

Introduction UMLUML c’est …

une norme (OMG)un langage de modélisation pseudo-formel (rigoureux) visuel

Propose des éléments de modélisation (classes, association, agrégation, package, etc.)Définit (informellement) la sémantique de ces élémentsPropose une représentation graphique de ces éléments

Chap.2, Sect.1, p.13

Introduction UMLUML c’est …

Un support de communication performant, qui facilite la représentation et la compréhension de solutions objets:

Notation graphique: permet d'exprimer visuellement une solutionobjet, ce qui facilite la comparaison et l'évaluation de solutions. Notation rigoureuse: limite les ambiguïtés et lesincompréhensions. Notation abstraite: son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel.

UML permet aux concepteurs de parler un langage commun, normalisé et accessible.

Chap.2, Sect.1, p.14

Introduction UMLUML c’est …

Un cadre d’analyse objetproposant différents types de diagrammes pouvant être regroupés pour offrir différentes vues du système.où l’analyse et la conception se fait graduellement par l’élaboration des 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.2, Sect.1, p.15

Introduction UMLUML c’est…

en BREF

Un langage de modélisation visuelle qui permet de

Spécifier, visualiser et comprendre un problèmeCapturer, communiquer et utiliser des connaissances pour la résolution du problèmeSpécifier, visualiser sous différent angles et construire la solution du problèmeDocumenter la solution.

Chap.2, Sect.1, p.16

Introduction UMLDiagrammes UML et vues

Le modèle UML d’un système peut être étudié sous différentes perspectives appelées « vues ».

Modèle UML = ensemble de diagrammes décrivant le système développé.Vue = angle particulier sous lequel un participant au développement voit le système. Combinaison de diagrammes intéressant un participant.

Utilisateur

structure implémentation

comportement environnement

Chap.2, Sect.1, p.17

Introduction UMLLes vues de UML

Vue utilisateur:Définit les buts et objectifs des clients du système.Définit les besoins (contraintes) requis par la solutionVue 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 problème.Identification des éléments du domaine (classes, attributs, packages, etc.) et des relations (association, compositions, dépendance, etc.) entre eux.

Vue comportementaleDécrit les aspects dynamiques, du comportement du problème et de sa solutionSpécifie les interactions et collaborations entre éléments de la solution.Montre la décomposition du système en termes de processus, d’interactions entre processus, de synchronisation et de communication entre activités.

Chap.2, Sect.1, p.18

Introduction UML

Les vues de UMLVue 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, etc.

Vue environnementaleDé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, etc.) et comment elles sont utilisées par le logiciel.

Chap.2, Sect.1, p.19

Introduction UMLLes diagrammes de UML

Deux grandes catégories de diagrammes

Diagrammes décrivant les aspects statiques: structures et relations.

Diagramme de classes: décrit les données du système (structure, relations, contraintes, qualification, rôle,...)Diagramme d’objets: diagramme de classes instancié. Utilisé pour illustrer un exemple particulier.Diagramme de composants: montre l'architecture physique du matériel 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. Distribution des composants sur le nœuds…

Chap.2, Sect.1, p.20

Introduction UMLLes diagrammes de UML

Deux grandes catégories de diagrammes

Diagrammes décrivant les aspects dynamiques:comportement, collaboration, responsabilités, etc.

Diagramme de cas d’utilisation: montre à un haut niveau d'abstraction une collection de cas d'utilisation caractérisant le comportement de tout le système.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 de classe ou à un cas d'utilisation (workflow).

Chap.2, Sect.1, p.21

Introduction UML

Diagrammes UML et vues

Utilisateur

structure implémentation

comportement environnement

Diagramme de composants

Diagramme d’activitésDiagramme

d’états

Diagramme de séquence

Diagramme de cas d’utilisationDiagramme

de classes

Diagramme d’objets

Diagramme de collaboration

Diagramme de déploiement

Chap.2, Sect.1, p.22

Introduction UMLUML ce N’est toutefois PAS

une méthode standardisée de développement:c’est une NOTATION.

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. Des processus de développement et des techniques de design, basés sur l’utilisation d’UML, ont été proposés :

RUP: Rational Unified Process (pdf ici)2TUP: 2 Tracks Unified ProcessDesign patternsEtc.

Chap.2, Sect.1, p.23

Introduction UMLÉlaboration des vues et diagrammes pendant le

cycle de développement

Comment développer un système avec UML ?On préconise une démarche itérative et incrémentale…

A chaque itération, on verra à :

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.

… et ce, depuis l’analyse jusqu’à l’implémentation

Chap.2, Sect.1, p.24

Introduction UMLÉlaboration des vues et diagrammes

pendant l’analyse et la conceptionPhase d’analyse:

Vues utilisateur, structurelle et comportementale.Accent mis sur diagrammes: cas d’utilisation, classes, séquence,états.

Phase de conceptionConception détaillée:

Révision de la vue utilisateurRaffinement de vues structurelle et comportementaleAnticipation de la vue implémentation.Accent mis sur diagrammes: séquence, collaboration, états, activités, cas d’utilisation et classes. ( … diagramme de packages)

Conception architecturale:Vues implémentation et environnementale.Accent mis sur diagrammes: composants, déploiement.

Chap.2, Sect.1, p.25

Introduction UMLRéférences

Documentation sur UML: http://www.rational.com/uml/resources/documentation/index.jspRational Unified Process: « Best practices for Software Developmentteams ». (pdf ici)Quelques outils CASE supportant UML:

Commerciaux : Rational Rose, Together, MagicDraw, Rhapsody, Objecteering/UML, Describe, UML StudioGratuits: Poseidon, ArgoUML, ClassBuilderDisponible au DIRO: Rational Rose

Se connecter à une machine linux.Taper « inclure rose ».Démarrer à l’aide de la commande « rose & ».

Chap.2, Sect.1, p.26

2.1.3 Rappel de quelques concepts objets

ObjetCaractéristiques

Un état Poil gris-vert, yeux bruns, heureux, nommé_Adrien.

Un comportement miauler, courir, sauter, manger.

IdentitéAdrien_le_chat_de_PierreTremblay_NAS_999999999N.b. Deux objets peuvent être égaux mais ne sont jamais identiques.

Adrien_le_chat_de_PierreTremblay_NAS_999999999

Chap.2, Sect.1, p.27

Rappel de quelques concepts objets

ClasseDescription générale d’un ensemble d’objets

Attributs (état)Opérations (comportements)

Moule (template) général sur lequel on crée des objets du même type.Partie publique: interface. Partie cachée: implémentationInstance (objet) = objet crée sur le modèle de la classe. Le chat Adrien est une instance de la classe Chat.

Classe Chat

Chap.2, Sect.1, p.28

Rappel de quelques concepts objets

HéritageRelation entre deux classe.Sémantique de l’héritage

EnrichissementSubstitution

Type d’héritageSimple (hiérarchie)Multiple (possibilité de conflits…)

Classe Félin

Classe Chat

Chap.2, Sect.1, p.29

Rappel de quelques concepts objets

MessageCommunication entre deux objets

Objet serveurNom de l’opérationArguments et paramètre de sorties.

roger

roger.fait_le_beau()

Chap.2, Sect.1, p.30

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'objet auquel il est destiné.

SurchargeDans une classe, un même nom est employé pour définir deux opérations (ou attributs) de signatures différentes.