Introduction à la modélisation objet avec UML

13/02/2015 Mme CHALOUAH Anissa 14

<!-- Slide number: 15 --> # Qu'est-ce qu'un modèle ? C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur, utilise et enrichit le modèle différemment. En outre, les systèmes devenant de plus en plus complexes, leur compréhension et leur maîtrise globale dépassent les capacités d’un seul individu. 13/02/2015 Mme CHALOUAH Anissa 15

<!-- Slide number: 16 --> # Qu'est-ce qu'un modèle ? Le modèle présente notamment l’atout de faciliter la traçabilité du système, à savoir la possibilité de partir d’un de ses éléments et de suivre ses interactions et liens avec d’autres parties du modèle. 13/02/2015 Mme CHALOUAH Anissa 16

<!-- Slide number: 17 --> # Qualité d’un bon modèle Un bon modèle doit : faciliter la compréhension du programme étudié, en réduisant la complexité. permettre de simuler le comportement du programme Un bon modèle doit donc être construit: au bon niveau de détail, selon le bon point de vue. 13/02/2015 Mme CHALOUAH Anissa 17

Notes: Pensez à l’analogie de la carte routière. Pour circuler dans Toulouse, la carte de France serait de peu d’utilité. En revanche, pour aller de Toulouse à Paris, la carte de la Haute-Garonne ne suffit pas… À chaque voyage correspond la « bonne » carte

<!-- Slide number: 18 --> # Rôles du modèle Il permet de : Visualiser le système comme il est ou comme il devrait être. Valider le modèle vis-à-vis des clients. Spécifier les structures de données et le comportement du système. Fournir un guide pour la construction du système. Documenter le système et les décisions prises.

13/02/2015 Mme CHALOUAH Anissa 18

<!-- Slide number: 19 --> # Approche de modélisation Il existe deux approches de modélisation (démarches de conception) pour un logiciel : L'approche fonctionnelle L'approche objet. 13/02/2015 Mme CHALOUAH Anissa 19

<!-- Slide number: 20 --> # L’approche fonctionnelle Cette approche dérive des langages de programmation procéduraux. Décomposition d'une tâche en termes de sous-programmes. Analyse du problème de manière descendante ("Top-Down"). Avantages : Lisibilité et modularité Inconvénients : La spécialisation des fonctions ne favorise pas leur réutilisation. conception plat de spaghettis dans les appels de procédures. Il serait bien de "responsabiliser" nos parties de programmes

13/02/2015 Mme CHALOUAH Anissa 20

<!-- Slide number: 21 --> # L’approche fonctionnelle

 13/02/2015 Mme CHALOUAH Anissa 21

<!-- Slide number: 22 --> # La modélisation objet La modélisation objet consiste à créer une représentation informatique des éléments du monde réel, sans se préoccuper de l’implémentation. Il s’agit donc de déterminer les objets présents et d’isoler leurs données et les fonctions qui les utilisent.

13/02/2015 Mme CHALOUAH Anissa 22

<!-- Slide number: 23 --> # Intérêt du modèle objet La force de la programmation objet, c’est qu’elle s’appuie sur un modèle calqué sur la réalité physique du monde. Les objets se comportent comme des entités indépendantes, auto-suffisantes qui collaborent par échange de message.

13/02/2015 Mme CHALOUAH Anissa 23

<!-- Slide number: 24 --> Chapitre 1 : Introduction à la modélisation objet avec UML # Le paradigme Orientée objet 13/02/2015 Mme CHALOUAH Anissa 24

<!-- Slide number: 25 --> # Paradigme objet Programmation Objet : Un programme = une société d'entités Son exécution : les entités collaborent pour résoudre le problème final en s'envoyant des messages. une entité = un objet qui prend en compte sa propre gestion (objet responsable) Liaison inévitable entre données et procédures opérant sur ces données. Avantages Faciliter le développement en mode «boite noire» Maximiser la localité des changements Permettre la réutilisation de code 13/02/2015 Mme CHALOUAH Anissa 25

<!-- Slide number: 26 --> # Concepts Objet Les concepts objets se traduisent par les notions suivantes : Objet Classe Encapsulation Abstraction Héritage Polymorphisme

13/02/2015 Mme CHALOUAH Anissa 26

<!-- Slide number: 27 --> # L’objet Toute entité identifiable, concrète ou abstraite, peut être considérée comme un objet.

Un objet réagit à certains messages qu’on lui envoie de l’extérieur ; la façon dont il réagit détermine le comportement de l’objet.

Il ne réagit pas toujours de la même façon à un même message ; sa réaction dépend de l’état dans lequel il est. 13/02/2015 Mme CHALOUAH Anissa 27

<!-- Slide number: 28 --> # L’objet Caractérisé par : son comportement : que peut-on faire avec cet objet? Méthodes Son état : comment réagit l’objet quand on applique ces méthodes?  Attributs (Champs) son identité : comment distinguer les objets qui ont le même état et le même comportement?  Identifiant A les mêmes réactions et la même modularité que le monde réel. L’objet informatique est une projection de l’objet du monde réel.

13/02/2015 Mme CHALOUAH Anissa 28

<!-- Slide number: 29 --> # La classe Une classe est la description des caractéristiques communes à tous les objets. Une classe est un modèle de définition pour des objets ayant même structure (même ensemble d'attributs), ayant même comportement (mêmes opérations, méthodes), ayant une sémantique commune. Classe = schéma/moule/modèle d’objets, elle décrit : partie privée structure de données interne (attributs) corps des méthodes (algorithmes) partie publique (interface) noms et paramètres des méthodes 13/02/2015 Mme CHALOUAH Anissa 29

<!-- Slide number: 30 --> # La classe Les objets (instances) sont créés (instanciés) à partir de "moules" : les classes. Classe = générateur d’objets par instanciation, on peut fabriquer des objets obéissant à ce schéma/moule/modèle.

 13/02/2015 Mme CHALOUAH Anissa 30

<!-- Slide number: 31 --> # Exemple : classe et objet

 13/02/2015 Mme CHALOUAH Anissa 31

<!-- Slide number: 32 --> # Abstraction Une abstraction est un résumé, un condensé Mise en avant des caractéristiques essentielles Dissimulation des détails Une abstraction se définit par rapport à un point de vue Exemple d’abstraction : carte routière 13/02/2015 Mme CHALOUAH Anissa 32

<!-- Slide number: 33 --> # Encapsulation Mécanisme consistant à rassembler, au sein d’une même structure, les données et les traitements Définition des attributs et méthodes au niveau de la classe L’implémentation de la classe est cachée pour l’utilisateur Définition d’une interface : vue externe de l’objet Possibilité de modifier l’implémentation sans modifier l’interface Facilité de l’évolution de l’objet Préservation de l’intégrité des données L’accès direct aux attributs est interdit L’interaction entre les objets se fait uniquement grâce aux méthodes. 13/02/2015 Mme CHALOUAH Anissa 33

<!-- Slide number: 34 --> # Héritage Un objet spécialisé bénéficie ou hérite des caractéristiques de l’objet le plus général, auquel il rajoute ses éléments propres Création de nouvelles classes basées sur des classes existantes. Transmission des propriétés (attributs et méthodes) de la classe mère vers la classe fille. Traduit la relation « est un … » Deux orientations possibles Spécialisation : Ajout / adaptation des caractéristiques Généralisation : Regroupement des caractéristiques communes Avantages Éviter la duplication du code Encourager la réutilisation du code 13/02/2015 Mme CHALOUAH Anissa 34

<!-- Slide number: 35 --> # Héritage : Exemple

 13/02/2015 Mme CHALOUAH Anissa 35

<!-- Slide number: 36 --> # Polymorphisme Définition : Poly : plusieurs Morphisme : Forme Faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes. Capacité d’une classe à redéfinir une méthode héritée à partir d’une classe mère Surcharge Avantages Lisibilité du code Généricité du code 13/02/2015 Mme CHALOUAH Anissa 36

<!-- Slide number: 37 --> # Polymorphisme : exemple

 float surface(float rayon) { return (3,14*rayon*rayon); } float surface(float longueur, float largeur) { return (longueu*largeur); } 13/02/2015 Mme CHALOUAH Anissa 37

<!-- Slide number: 38 --> Chapitre 1 : Introduction à la modélisation objet avec UML # UML : UNIFIED MODELINGLANGUAGE 13/02/2015 Mme CHALOUAH Anissa 38

<!-- Slide number: 39 --> # Historique Années 80 Méthodes pour organiser la programmation fonctionnelle (Merise) Séparation des données et des traitements Début des années 90 Apparition de la programmation objet: nécessite d’une méthodologie adaptée Apparition de plus de 50 méthodes entre 1990 et 1995 1994 Consensus sur 3 méthodes OMT de James Rumbaugh : représentation graphique des aspects statiques, dynamiques et fonctionnels d’un système OOD de Grady Booch: concept de package OOSE de Ivar Jacobson : description des besoins de l’utilisateur. 13/02/2015 Mme CHALOUAH Anissa 39

<!-- Slide number: 40 --> # Genèse de UML(Unified Modeling Langage)

 13/02/2015 Mme CHALOUAH Anissa 40

<!-- Slide number: 41 --> # UML(Unified Modeling Langage) UML est un langage universel de modélisation orientée objet. UML est une notation, un outil de communication visuelle (diagrammes) UML est une norme maintenue par l’OMG (Object Management Group) UML est dans le domaine public, c’est un standard.

13/02/2015 Mme CHALOUAH Anissa 41

<!-- Slide number: 42 --> # UML UML est un langage pour : Visualiser Chaque symbole graphique possède une sémantique. Spécifier De manière précise et complète, sans ambiguïté. Construire Une partie du code des classes peut être généré automatiquement. Documenter Les différents diagrammes, notes, contraintes, exigences sont conservés dans un document.

13/02/2015 Mme CHALOUAH Anissa 42

<!-- Slide number: 43 --> # UML(Unified Modeling Langage) UML n’est pas une méthode. UML n’est pas un processus de développement. UML n’est pas un langage de programmation.

13/02/2015 Mme CHALOUAH Anissa 43

<!-- Slide number: 44 --> # Objectifs d’UML Fournir un langage visuel et expressif. Fournir des mécanismes d’extension. Etre indépendant des technologies et langages d’implémentation Fournir une base formelle pour la modélisation. 13/02/2015 Mme CHALOUAH Anissa 44

Notes:

<!-- Slide number: 45 --> # Les diagrammes UML

 13/02/2015 Mme CHALOUAH Anissa 45

<!-- Slide number: 46 --> # Les diagrammes UML Diagrammes de cas d’utilisation : décrivent les services rendus par le système du point de vue de l’utilisateur. Diagrammes de classes : décrivent les classes d’une application et leurs relations statiques. Diagrammes d’objets : montrent l’état d’une application à un instant donné. (Instances des classes) 13/02/2015 Mme CHALOUAH Anissa 46

<!-- Slide number: 47 --> # Les diagrammes UML Diagrammes de séquence : Scénario d’un cas d’utilisation : chronologie des opérations. Diagrammes de collaboration : sont une représentation spatiale des interactions entre objets. Diagrammes d’´etats-transitions : représentent le comportement d’un objet sous la forme d’un automate à états

13/02/2015 Mme CHALOUAH Anissa 47

<!-- Slide number: 48 --> # Les diagrammes UML Diagrammes de composants : Représentation des composants logiciels d’un système. Diagrammes de déploiement : Description de l’architecture technique du système . Diagrammes d’activités : Vue des enchaînements des activités d’un cas d’utilisation ou d’une opération 13/02/2015 Mme CHALOUAH Anissa 48

<!-- Slide number: 49 --> # Les 3 axes de modélisation d’un système Axe fonctionnel (ce que le système FAIT) Diagramme de cas d’utilisations

Diagramme de classes Diagramme d’objets Diagramme de composants

Diagramme d’états-transitions Diagramme de séquence Diagramme d’activité

Axe dynamique (comment le système évolue) Axe statique (ce que le système EST) 13/02/2015 Mme CHALOUAH Anissa 49

<!-- Slide number: 50 --> # Les Vues en UML Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se superposer pour collaborer à la définition du système. Ce sont des formulations du problème selon un certain point de vue. Elles peuvent se chevaucher pour compléter une description. Leur somme représente le modèle en entier : 4 vues plus 1. 13/02/2015 Mme CHALOUAH Anissa 50

<!-- Slide number: 51 --> # Les Vues en UML

 Le modèle « 4+1 » vues de Kruchten 13/02/2015 Mme CHALOUAH Anissa 51

<!-- Slide number: 52 --> # Les Vues en UML Vue des cas d’utilisation : c'est la description du modèle vu par les acteurs du système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI). Vue logique : c'est la définition du système vu de l'intérieur. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT). Vue d'implémentation : cette vue définit les dépendances entre les modules.

13/02/2015 Mme CHALOUAH Anissa 52

<!-- Slide number: 53 --> # Les Vues en UML Vue des processus : c'est la vue temporelle et technique Elle met en œuvre les notions de tâches concurrentes, contrôle, synchronisation…

Vue de déploiement : cette vue décrit la position géographique et l'architecture physique de chaque élément du système (c'est le OÙ).

13/02/2015 Mme CHALOUAH Anissa 53