IFT6803: Génie logiciel du commerce électronique. Chapitre 2: Analyse orientée objet Section 1: Introduction au paradigme objet et à UML

Transcription

1 IFT6803: Génie logiciel du commerce électronique Chapitre 2: Analyse orientée objet Section 1: Introduction au paradigme objet et à UML Julie Vachon, Hiver 2003

2 Sommaire Chapitre 2, Section 1 Introduction au paradigme objet et à UML Vers une approche orientée objet Introduction à UML Rappel de quelques concepts objets Chap.2, Sect.1, p.2

3 2.1.1 Vers une approche orientée objet Approche à saveur «fonctionnelle» (procédures & routines, types de données abstraits, DFD etc.) dfd-0 F0 Données AB Approche logique, cohérente, intuitive «Diviser pour régner» Séparation des données et des traitements Conception par décomposition et factorisation respectives des données et traitements. dfd-1 dfd-2 F4 F2 F1 F5 F6 F7 Données A F3 F8 Données B Chap.2, Sect.1, p.3

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 messages Encapsulation des données et leurs traitements dans une même unité. Objet A Données + Traitements msg Objet C Données + Traitements Objet B Données + Traitements msg Chap.2, Sect.1, p.4

5 Vers une approche orientée objet Tel que vu dans la phase de conception, la modularisation doit tendre vers Minimisation du couplage Maximisation la cohésion Qualités qui facilitent la maintenance du système. L approche orientée objet favorise un bon design Encapsulation 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.5

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

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 un système avec concepts objets. Chap.2, Sect.1, p.7

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

9 Chap.2, Sect.1, p Introduction à UML Mé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 ( ) Plus de 50 méthodes objet sont apparues durant cette période Exemples: Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE -- Aucune méthode ne s'est réellement imposée. --

10 Chap.2, Sect.1, p.10 Introduction UML Les 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

11 Introduction UML Fusion et synthèse de méthodes dominantes: UML (Unified Modeling Language) Standardisation par l OMG UML 1.0 (Janvier 97) UML 1.1 (Septembre 97) UML 0.9 (96) UML 0.8 (95) Autres méthodes Booch OOSE OMT Partenaires industriels Chap.2, Sect.1, p.11

12 Introduction UML UML 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éments Propose une représentation graphique de ces éléments Chap.2, Sect.1, p.12

13 Introduction UML UML 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 solution objet, ce qui facilite la comparaison et l'évaluation de solutions. Notation rigoureuse: limite les ambiguïtés et les incompré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.13

14 Introduction UML UML c est Un cadre d analyse objet proposant 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.14

15 Introduction UML UML c est en BREF Un langage de modélisation visuelle qui permet de Spécifier, visualiser et comprendre un problème Capturer, communiquer et utiliser des connaissances pour la résolution du problème Spécifier, visualiser sous différent angles et construire la solution du problème Documenter la solution. Chap.2, Sect.1, p.15

16 Introduction UML Diagrammes 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. structure implémentation Utilisateur comportement environnement Chap.2, Sect.1, p.16

17 Introduction UML Les vues de UML Vue utilisateur: Définit les buts et objectifs des clients du système. Définit les besoins (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 problème. Identification des éléments du domaine (classes, attributs, packages, etc.) et des relations (association, compositions, dépendance, etc.) entre eux. Vue comportementale Décrit les aspects dynamiques, du comportement du problème et de sa solution Spé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.17

18 Vue implémentation Introduction UML Les vues de UML 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 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, etc.) et comment elles sont utilisées par le logiciel. Chap.2, Sect.1, p.18

19 Chap.2, Sect.1, p.19 Introduction UML Les 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

20 Chap.2, Sect.1, p.20 Introduction UML Les 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).

21 Introduction UML Diagrammes UML et vues Diagramme d objets Diagramme de classes structure Diagramme de cas d utilisation implémentation Diagramme de composants Diagramme de collaboration comportement Utilisateur environnement Chap.2, Sect.1, p.21 Diagramme de séquence Diagramme d états Diagramme d activités Diagramme de déploiement

22 Chap.2, Sect.1, p.22 Introduction UML UML 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 Process Design patterns Etc.

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

24 Introduction UML Chap.2, Sect.1, p.24 Élaboration des vues et diagrammes pendant l analyse et la conception Phase d analyse: Vues utilisateur, structurelle et comportementale. Accent mis sur diagrammes: cas d utilisation, classes, séquence, états. Phase de conception Conception détaillée: Révision de la vue utilisateur Raffinement de vues structurelle et comportementale Anticipation 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.

25 Introduction UML Références Documentation sur UML: Rational Unified Process: «Best practices for Software Development teams». (pdf ici) Quelques outils CASE supportant UML: Commerciaux : Rational Rose, Together, MagicDraw, Rhapsody, Objecteering/UML, Describe, UML Studio Gratuits: Poseidon, ArgoUML, ClassBuilder Disponible 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.25

26 2.1.3 Rappel de quelques concepts objets Objet Caractéristiques Un état Adrien_le_chat _de_pierretre mblay_nas_ Poil gris-vert, yeux bruns, heureux, nommé_adrien. Un comportement miauler, courir, sauter, manger. Identité Adrien_le_chat_de_PierreTremblay_NAS_ N.b. Deux objets peuvent être égaux mais ne sont jamais identiques. Chap.2, Sect.1, p.26

27 Rappel de quelques concepts objets Classe Description générale d un ensemble d objets Attributs (état) Opérations (comportements) Classe Chat Moule (template) général sur lequel on crée des objets du même type. Partie publique: interface. Partie cachée: implémentation Instance (objet) = objet crée sur le modèle de la classe. Le chat Adrien est une instance de la classe Chat. Chap.2, Sect.1, p.27

28 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 (possibilité de conflits ) Classe Félin Classe Chat Chap.2, Sect.1, p.28

29 Rappel de quelques concepts objets Message Communication entre deux objets Objet serveur Nom de l opération Arguments et paramètre de sorties. roger roger.fait_le_beau() Chap.2, Sect.1, p.29

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é. Surcharge Dans une classe, un même nom est employé pour définir deux opérations (ou attributs) de signatures différentes. Chap.2, Sect.1, p.30