Autour des objets et du formalisme UML

Présentation au sujet: "Autour des objets et du formalisme UML"— Transcription de la présentation:

1 Autour des objets et du formalisme UML
T. Libourel

2 Introduction Concepts objet et formalisme UML Discussion PLAN
Pourquoi des méthodes ? Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

3 Introduction Concepts objet et formalisme UML Discussion PLAN
Pourquoi des méthodes ? Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

4 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

5 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

6 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

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

8 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 "Object Modeling Techniques" General Electric Ivar Jacobson : Objectory 1992, Ericsson, suite de OOSE "Object Oriented Software Engineering" Regroupement de BOOCH-OMT puis Objectory

9 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)

10 Introduction Concepts objet et formalisme UML Discussion PLAN
Pourquoi des méthodes ? Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

11 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 …)

12 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

13 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

14 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 >

15 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

16 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

17 Deux concepts Acteur Use case Modèle fonctionnel Acteur (rôle 2)

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

19 - ce qui est extérieur et qui communique avec le système
Modèle fonctionnel Délimiter le système - ce qui est extérieur et qui communique avec le système - ce qui est interne au système Définir les fonctionnalités du système du point de vue des utilisateurs Donner une description cohérente de toutes les vues que l ’on peut avoir du système

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

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

22 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

23 Modèle structurel Site2 Palmier1 Site1 Palmier2 : Site Palmier3
Deux objets ou instances Palmier1 Site1 Palmier2 : Site Palmier3 : Palmier

24 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

25 Classe Instance Modèle structurel Attributs (propriétés)
Valeurs d'attributs (État) Palmier palmier1 :Palmier « Est-instance-de » type =« dattier » taille= 2 type : string taille : float

26 Modèle structurel nom de la classe Palmier attributs type : string taille : float opérations Opérations et méthodes Méthodes Implémentations croitre() arroser (qtte : float)

27 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

28 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 : Identité fixée par le système (oid) mais il peut être nommé et être référencé par un nom

29 (analogie Classe / Instance)
Modèle structurel Association / Lien (analogie Classe / Instance) Palmier Site a-pour-localisation type Association nom a-pour-localisation : Palmier type=dattier :Site nom = Djerba Lien

30 Association en général binaire (degré = 2) mais ..
Modèle structurel Association en général binaire (degré = 2) mais .. nom d'association a-pour-localisation Palmier Site soumit association ternaire association binaire Dispositif-Arrosage

31 Multiplicité et rôles d'une association
Modèle structurel Multiplicité et rôles d'une association A-pour-localisation Palmier plantation lieu Site * 1..* type taille nom Lat Long comporte englobant 0..1 englobe 1..* englobé

32 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

33 Classe association Modèle structurel Palmier Site type nom Gestion
A pour localisation Palmier Site 1..* 1..* type nom Gestion type 1..* gestionnaire Personne

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

35 Composition Modèle structurel Association particulière Tout /partie
Palmier 0..2 Couronne Stipe Racine 0..1 0..* Régime Feuille Inflorescence 0..1

36 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 Site

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

38 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

39 Généralisation / Spécialisation
Modèle structurel Généralisation / Spécialisation Personne nom adresse {disjoint} Gestionnaire num adresse Chercheur grade adresse Exposer()

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

41 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

42 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

43 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 ».

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

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

46 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

47 Opérations abstraites
Modèle structurel Classes abstraites Une classe abstraite est une classe non instanciable, c'est à dire qu'elle n'admet pas d'instances directes. La factorisation optimale des propriétés communes à plusieurs classes par généralisation nécessite le plus souvent l'utilisation de classes abstraites. Opérations abstraites Une opération abstraite est une opération n'admettant pas d'implémentation Les opérations abstraites pour mettre en œuvre le polymorphisme. Patrons

48 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

49 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)

50 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

51 Les messages Types Synchronisation Modèle dynamique simple
synchrone dérobant minuté asynchrone constructeurs destructeurs sélecteurs modificateurs itérateurs

52 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

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

54 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

55 É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

56 Modèle dynamique :Palmier :Feuille :Inflorescence :Régime temps

57 Diagramme d ’état Modèle dynamique Événement 1 [Cond1] / Action1
(attrib) État 1 faire : Activité 1 État 2 ... État d'un objet 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

58 Modèle dynamique Créé Avec inflorescence Avec feuille Avec régime
création e2 Créé Avec inflorescence Avec feuille e1 [C] Avec régime

59 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

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

61 Introduction Concepts objet et formalisme UML Discussion PLAN
Pourquoi des méthodes ? Atouts Historique Concepts objet et formalisme UML Concepts généraux Modèle fonctionnel Modèle structurel Modèle dynamique Discussion

62 L'approche mathématique vs approche objet
Discussion Les points « épineux » L'approche mathématique vs approche objet Représentation de types, de variables et de fonctions. Culture scientifique Traitement du « continu » Simulations. Vers les agents ?

63 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

64 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 Palmier, Site, etc Modèle Définition spécifique d’un domaine A120, 50, etc Objets utilisateur

65 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

66 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++, ..

67 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)

68 Livres UML (1) Booch Grady, Rumbaugh James, and Jacobson Ivar, The Unified Modeling Language User Guide, , 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, , 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, X, Addison Wesley, Fall 1998

69 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