T. Libourel libourel@lirmm.fr Autour des objets T. Libourel libourel@lirmm.fr

Introduction Approche objet Concepts objet et formalisme UML PLAN Introduction Modèles mathématiques versus modèles objets Systèmes et objets Pourquoi des méthodes ? Approche objet Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

Introduction Approche objet Concepts objet et formalisme UML PLAN Introduction Modèles mathématiques versus modèles objets Systèmes et objets Pourquoi des méthodes ? Approche objet Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

Modèles mathématiques versus modèles objets L'approche mathématique Représentation de types, de variables et de fonctions. Culture scientifique L'approche objet Représentation abstraite d'entités ayant une existence matérielle (arbre, personne) ou virtuelle (sécurité sociale, compte bancaire, ...). Culture implicite et philosophique Confluent de plusieurs disciplines informatiques

Taille et complexité des systèmes importantes et croissantes Systèmes et objets Taille et complexité des systèmes importantes et croissantes les besoins et les fonctionnalités augmentent la technologie évolue rapidement les architectures se diversifient Problèmes des spécifications parfois imprécises, incomplètes, ou incohérentes assurer l’interface avec le métier (domaine d’application)

Évolution des applications Systèmes et objets Évolution des applications évolution des besoins des utilisateurs réorientation de l'application évolution de l'environnement technique (matériel et logiciel) Problèmes liés à la gestion des équipes taille croissante des équipes spécialisation technique spécialisation métier

Pourquoi des méthodes ? Rien ne dicte a priori comment modéliser un système de manière pertinente Besoin de méthodologie Outils Informatiques Entreprise

Démarche reproductible pour obtenir des résultats fiables Pourquoi des méthodes ? Démarche reproductible pour obtenir des résultats fiables Construire des modèles à partir d'éléments (concepts) Possibilité de représenter à partir de formalismes Mise en œuvre

Pourquoi des méthodes ? Démarche qui distingue les étapes du développement dans le cycle de vie du logiciel Modularité, réduction de la complexité, réutilisabilité, abstraction Un formalisme de représentation qui facilite la communication, l’organisation et la vérification Production de documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

Introduction Approche objet Concepts objet et formalisme UML PLAN Introduction Modèles mathématiques versus modèles objets Systèmes et objets Pourquoi des méthodes ? Approche objet Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

Universalité de l’Objet Atouts Universalité de l’Objet la notion d’objet, plus proche du monde réel, est compréhensible par tous et facilite la communication entre tous les intervenants d’un projet. Omniprésence technique de l’Objet dans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception.

Regroupement de BOOCH-OMT puis Objectory Historique Plus de 50 méthodes objet sont apparues durant la période 90-95: Booch, Classe-Relation, OMT, OOA, OOD, OOM, OOSE... Grady Booch : OOD, BOOCH'93 (Société RATIONAL) 1987 pour ADA, 1990 générale                         James Rumbaugh : OMT 1990-1991 "Object Modeling Techniques" General Electric Ivar Jacobson : Objectory 1992, Ericsson, suite de OOSE "Object Oriented Software Engineering" Regroupement de BOOCH-OMT puis Objectory

UML (Unified Modeling Language) Historique Recherche d’un langage commun unique utilisable par toute méthode objet dans toutes les phases du cycle de vie, compatible avec les techniques de réalisation actuelles. UML (Unified Modeling Language) http://www.omg.org

Introduction Approche objet Concepts objet et formalisme UML PLAN Introduction Modèles mathématiques versus modèles objets Systèmes et objets Pourquoi des méthodes ? Approche objet Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

Un modèle est une représentation abstraite d’une réalité, Concepts généraux Un modèle est une représentation abstraite d’une réalité, Il fournit une image simplifiée du monde réel. Il permet de comprendre et visualiser (en réduisant la complexité) de communiquer (à partir d ’un « langage » commun à travers un nombre restreint de concepts) de valider (contrôle de la cohérence, simuler, tester …)

Les modèles d'UML Concepts généraux modèle des classes statique modèle des états dynamique des objets modèle des cas d'utilisation besoins utilisateur modèle d'interaction scénarios et flots de messages modèle de réalisation unités de travail modèle de déploiement répartition des processus

La perception des modèles Les vues graphiques (diagrammes ) Concepts généraux La perception des modèles Les vues graphiques (diagrammes ) diagrammes de classes diagrammes d'objets diagrammes de séquences diagrammes de collaboration diagrammes états-transitions diagrammes d'activités diagrammes de cas d'utilisation diagrammes de composants diagrammes de déploiement

Concepts généraux Définir une architecture ……. divers points de vue sur le système Vue   structurelle Vue Implémentation Vue Cas d ’utilisation Vue Architecture (déploiement) Vue dynamique <------- Logique Physique ------>

Processus incrémental Concepts généraux Processus incrémental Analyse Conception Tests - Maintenance Réalisation Même formalisme lors de toutes les phases du cycle de vie

Modèles descriptifs du point de vue des utilisateurs Modèle fonctionnel Les «  USE CASE » Modèles descriptifs du point de vue des utilisateurs Scénarios fonctionnels Focus La manière d’utiliser le système

Deux concepts Acteur Use case Modèle fonctionnel Acteur (rôle 2) Ex: distributeur CB Deux concepts Acteur Use case Acteur (rôle 2) Acteur (rôle 1)

Les cas d’utilisation peuvent être liés par des relations Modèle fonctionnel Les cas d’utilisation peuvent être liés par des relations d’utilisation « use » (décomposition) de raffinement « extend » (traitement d’exceptions) Acteur (rôle 2) Acteur (rôle 1) « use » « extend »

Modèle structurel En UML, le modèle structurel ou statique est décrit à l'aide de deux sortes de diagrammes Diagrammes de classes description de tout ou d'une partie du système d'une manière abstraite, en termes de classes, de structure et d'associations. Diagrammes d'objets description d'exemples de configuration de tout ou partie du système, en termes d'objets, de valeurs et de liens.

Les objets Modèle structurel Objets du monde réel Objets informatiques Comportement visible État Interne caché

Objet Modèle structurel Etat évolue au cours du temps Comportement actions et réactions Identité essence Comportement influe sur l'état Etat reflète les comportements passés

Modèle structurel BD Luc Système Alain : Discipline Sophie Deux objets ou instances Luc Système Alain : Discipline Sophie : Professeur

Première abstraction Une classe peut être vue Modèle structurel la description en intension d'un groupe d'objets ayant même structure (même ensemble d'attributs), ayant même comportement (mêmes opérations), ayant une sémantique commune. la « génitrice » des objets ou instances le « conteneur » (extension) de toutes ses instances

Classe Instance Modèle structurel Attributs (propriétés) Valeurs d'attributs (État) Voiture titine :Voiture « Est-instance-de » type =205 Peugeot rouge type : string marque : string couleur : string

Modèle structurel nom de la classe Voiture attributs type : string marque : string couleur : string opérations Opérations et méthodes Méthodes Implémentations repeindre(c: Couleur) déplacer (d : longueur)

Les types sont optionnels et ne figent pas les choix d'implémentation Modèle structurel Représentation graphique : « les boites » (à différents niveaux de détail) Les types sont optionnels et ne figent pas les choix d'implémentation La description des opérations sera complétée dans les phases de conception

Un objet est instance d'une (seule) classe : Modèle structurel Un objet est instance d'une (seule) classe : il se conforme à la description que celle-ci fournit, il admet une valeur pour chaque attribut déclaré à son attention dans la classe, il est possible de lui appliquer toute opération définie à son attention dans la classe. Tout objet admet une identité qui le distingue pleinement des autres objets : il peut être nommé et être référencé par un nom (mais son identité ne se limite pas à ça).

(analogie Classe / Instance) Modèle structurel Association / Lien (analogie Classe / Instance) Pays Ville a-pour-capitale nom nom Association a-pour-capitale : Pays nom=France :Ville nom = Paris Lien

Association en général binaire (degré = 2) mais .. Modèle structurel Association en général binaire (degré = 2) mais .. nom d'association emprunte Adhérent Exemplaire lire association ternaire association binaire DispositifDeLecture

Multiplicité et rôles d'une association Modèle structurel Multiplicité et rôles d'une association emploie employeur employé Société Personne * 1..* nom adresse nom date de nais. n°SS adresse travaille-pour chef 0..1 encadre 1..* travailleur

aucun, 1 ou plusieurs (défaut) Modèle structurel Multiplicité exactement 1 1 Classe au plus 1 0..1 Classe aucun, 1 ou plusieurs (défaut) 0..* Classe 1..* au moins 1 Classe 2..4 de 2 à 4 Classe 2,4 Classe 2 ou 4

Possession Ligne de portefeuille Modèle structurel Classe association Possède-des-actions Entreprise Personne * 1..* nom adresse capital actionnaire nom date de nais. adresse Possession Ligne de portefeuille quantité

Classe association Modèle structurel Autorisé sur Utilisateur 1..* 1..* Station de travail nom nom Autorisation priorité droits 1..* répertoire de rattachement Répertoire

D ’autres « abstractions » Modèle structurel D ’autres « abstractions » associations particulières (composition / agrégation) spécialisation / généralisation

Composition Modèle structurel Association particulière Tout /partie Fenêtre 0..2 Barre titre Fond Frontière Barre Ascenseur 2 Titre Bouton Ferm Flèche Indicateur

Agrégation Modèle structurel Sémantique Collection/Élément Pays Forêt 1 Forêt 1..n 1 Région 1..n 1 Arbre 1..n Département

Composition / Agrégation Modèle structurel Composition / Agrégation Contraintes - Exclusivité / Partage - Dépendance / Indépendance Propagation / Diffusion

Mécanismes d’inférences intellectuelles de caractéristiques Modèle structurel Généralisation / Spécialisation Mécanismes d’inférences intellectuelles de caractéristiques Soit on affine (spécialisation) Soit on abstrait (généralisation) Sémantique Point de vue ensembliste Point de vue logique

Généralisation / Spécialisation Modèle structurel Généralisation / Spécialisation Personne nom adresse {disjoint} Étudiant num_carte adresse Enseignant grade adresse enseigner

... ... ... Généralisation / Spécialisation Modèle structurel Équipement Type d'équipement ... Pompe Réservoir Échangeur Type de pompe Type de réservoir ... ... Pompe Cent. Pompe Imm. Réservoir Press.

Généralisation / Spécialisation multiple Modèle structurel Généralisation / Spécialisation multiple Véhicule Véhicule aquatique Véhicule terrestre Auto Véhicule amphibie Bateau

Agrégation Généralisation Composition/Agrégation ou généralisation ? Modèle structurel Composition/Agrégation ou généralisation ? Agrégation lien entre instances un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite Généralisation lien entre classes

Généralisation / Spécialisation Modèle structurel Généralisation / Spécialisation Une sous-classe “hérite” des descriptions de sa super-classe : les déclarations d'attributs, les définitions d'opérations, les associations définies sur la super-classe, les contraintes (on en parle plus tard). Une sous-classe peut redéfinir de façon plus spécialisée une partie ou la totalité de la description « héritée ».

Les contraintes sont héritées. Modèle structurel Les contraintes Les contraintes sont des prédicats, pouvant porter sur plusieurs éléments du modèle statique, qui doivent être vérifiés à tout instant. Les contraintes permettent de rendre compte de détails à un niveau de granularité très fin dans un diagramme de classe. Elles peuvent exprimer des conditions ou des restrictions. En UML, les contraintes sont exprimées sous forme textuelle, entre accolades et de préférence en OCL (Object Constraint Language). Les contraintes sont héritées.

Les contraintes: Exemples de contraintes sur associations Modèle structurel Les contraintes: Exemples de contraintes sur associations membreDe Chemin Personne * * Comité * {subset} 1 préside * 1..* {ordered} contrainte entre 2 associations contrainte sur extrémité d'association Arête

Les contraintes: Exemple de contraintes à différents niveaux Modèle structurel Les contraintes: Exemple de contraintes à différents niveaux { actif = passif } contrainte sur classe subordonné employeur Personne Société * 1..* 0..1 0..1 { Personne.employeur = Personne.chef.employeur } actif : Real {value  0} passif : Real <dirige chef contrainte sur attribut contrainte sur 2 associations

Modèle dynamique Décrit les interactions entre objets et les changements au cours du temps - Aspects temporels, comportementaux : Contrôle - Stimuli des objets et leurs réponses

diagrammes de collaboration diagrammes de séquences Modèle dynamique diagrammes de collaboration diagrammes de séquences diagrammes états-transitions diagrammes d'activités (non traités)

La communication Modèle dynamique Systèmes informatiques : Société d'objets travaillant en synergie pour réaliser les fonctions de l'application Communication Client Acteur Serveur message

Les messages Types Synchronisation Modèle dynamique constructeurs destructeurs sélecteurs modificateurs itérateurs asynchrone synchrone retour

Diagramme de collaboration Modèle dynamique Diagramme de collaboration 2: M2 B 1: M1 5: M5 A 4: M4 C 6: M6 message 3: M3

Modèle dynamique Diagramme de séquence B C A M1 M2 M3 M4 M5 M6 TEMPS

La ligne de vie Modèle dynamique « create » :C1 op « destroy » Création par le message «create» Activation de l’objet qui exécute une opération op « destroy » Destruction par un autre objet

Modèle dynamique Pays Région Départ 1.1:Population() Poitou:Région France:Pays 1.2:Population() Bretagne:Région 1:Population() 1.3:Population() LR:Région 4: m4 …. 1.3.3:Population() 1.3.1:Population() 1.3.2:Population() Gard: Départ Aude:Départ Hérault: Départ

Modèle dynamique France Poitou Bretagne LR A H G Popul() Popul() temps Popul() Popul()

Événement Événement et État État d'un objet Modèle dynamique valeurs de ses attributs et de ses liens au cours du temps un objet peut changer d'état Événement stimuli d'un objet vers un autre objet

Graphe : Nœuds (Etat) Arcs (Transitions) Modèle dynamique Diagramme d’état Graphe : Nœuds (Etat) Arcs (Transitions) Événement 1 [Cond1] / Action1 (attrib) État 1 faire : Activité 1 État 2 ...

Notation des états Modèle dynamique Initial Simple Créditeur Final Nom état entry/op1 exit/ op2 on evt1/ op3 on evt2/ op4 do/ activité Activités internes Complexe au début à la fin lors d’evt tout le temps

Notation des arcs Modèle dynamique étiquette étiquette événement(paramètres) [condition] /action

Modèle dynamique Opération elle peut être attachée à une transition ou à un état. elle est exécutée en réponse à l'événement ou à l'état. Action opération instantanée, non interruptible, souvent utilisée pour faire des mises à jour de valeurs, attachée à une transition. Envoyer un événement est une action Activité opération qui prend du temps, interruptible par un événement, perpétuelle ou finie, nécessairement attachée à un état.

Etats d’un compte bancaire Modèle dynamique Diagrammes d'États Etats d’un compte bancaire transitions gardées sous-état demandeCréat() fermer() Ouvert Fermé ouvert Débiteur on retrait/ agios on dépôt/ augmenter solde [Solde >=0] Créditeur on retrait/ debiter solde on dépôt/ augmenter solde [Solde < 0]

Généralisation Modèle dynamique - permet une meilleure structuration des diagrammes d'états Un objet dans un état du diagramme général doit être dans un des états du diagramme imbriqué (relation ou entre les états) E1 E3 E4 E2 E6 E5

Agrégation Modèle dynamique une classe "agrégat" aura un état défini par l'agrégation des états de ses composants. Agrégation concurrente (relation et) Auto Moteur Portière Roue Arrêt Moteur portière roue Ouverte gonflée Marche point mort crevée Marche arrière Marche avant Fermée

Modèle d’implémentation Les packages Un package ou sous-système est un regroupement logique de classes, associations, contraintes .. Un sous-système est généralement défini par les services qu’il rend Les liens entre sous-systèmes sont des liens de dépendance Les « packages » servent à structurer une application Ils sont utilisés dans certains LPO (Java) ce qui assure une bonne « traçabilité » de l ’analyse à l ’implémentation

Modèle d’implémentation Les packages Liens de dépendance Classes avec fort couplage « sémantique »

Introduction Approche objet Concepts objet et formalisme UML PLAN Introduction Modèles mathématiques versus modèles objets Systèmes et objets Pourquoi des méthodes ? Approche objet Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

Des bienfaits de l ’encapsulation …. Discussion Des bienfaits de l ’encapsulation …. Données Encapsulation Messages Opérations Proposer un service et réagir aux messages

La méta-modélisation Discussion Langage pour spécifier Meta-Class, tout métamodèle Meta-Class, Meta-Attribut, etc Meta-Meta Modèle Class, Attribut, etc Langage pour spécifier un modèle Meta-Modèle Langage pour spécifier un domaine d’information Parcelle, Surface, etc Modèle Définition spécifique d’un domaine A120, 50, etc Objets utilisateur

UML n’est pas une méthode comme Merise Discussion UML et Merise UML n’est pas une méthode comme Merise Ne dit rien sur le processus de mise en œuvre ; chaque société peut proposer son processus: RUP « Rational Unified Process » (Rational) EAI (Valtech) MEGA Process (MEGA) UML cible toute application informatique, alors que Merise cible les SI

Schéma de la base relationnelle ou objet Discussion Les outils Modèles UML, ... AGL Schéma de la base relationnelle ou objet re-engineering Squelette de code Environnement de développement: Visual Age (IBM), Delphi, Visual J++, J Builder, VisualWorks, Objets SGBD-R ou SGBD-OO Langages JAVA, C++, ..

Outil de dialogue : Outil ouvert Discussion langage de représentation des modèles graphique et simple formel et normalisé (OMG) Outil ouvert Indépendant des langages de programmation Pas un processus d'élaboration des modèles Adaptable (stéréotype)

Livres UML (1) Booch Grady, Rumbaugh James, and Jacobson Ivar, The Unified Modeling Language User Guide, 0-201-57168-4, Addison Wesley, Fall 1998, traduit : Le guide de l'utilisateur UML, Eyrolles 2000. Jacobson Ivar, Booch Grady and Rumbaugh James, The Unified Software Development Process, 0-201-57169-2, Addison Wesley, Fall 1998, traduit : Le processus unifié de développement logiciel, Eyrolles 2000. Rumbaugh James, Jacobson Ivar, and Booch Grady, The Unified Modeling Language Reference Manual, 0-201-30998-X, Addison Wesley, Fall 1998

Livres UML (2) Conallen Jim, Concevoir des applications Web avec UML, Eyrolles , 2000. Douglass Bruce Powell, Doing Hard Time : Developping Real-Time Systems with UML, Addison Wesley, 1999. Eriksson , UML Toolkit, Wiley, 1997 Fowler Martin, UML Distilled, Applying the Standard Object Modeling Language Addison Wesley, 1997 Kettany N et al, De Merise à UML,Eyrolles , 1998 Larman Craig, Applying UML and Patterns,Prentice Hall, 1998 Lee R, Tepfenhart W, UML et C++, Simon et Schuste , 1998 Lopez N, Intégrer UML dans vos projets, Eyrolles, 1997 Muller Pierre-Alain, Modélisation objet avec UML, Eyrolles, 1997 Roques Pascal, Vallée Franck, UML en action, Eyrolles, 2000. Roques Pascal, UML par la pratique, Eyrolles, 2001. Schmuller Joseph, Teach Yourself UML in 24 Hours, Sams Publishing, 1999 Texel Williams, Uses cases combined with Booch/OMT/UML, Prentice Hall, 1998