Autour des objets et du formalisme UML

Autour des objetset du formalisme UML T. Libourel libourel@lirmm.fr

PLAN • Introduction • 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

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

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

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.

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

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

PLAN • Introduction • 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

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

Concepts généraux Les modèles d'UML 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

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

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

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

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

Acteur (rôle 1) 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) « use » « extend »

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

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.

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

Modèle structurel Objet 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 Site2 Deux objets ou instances Palmier1 Site1 Palmier2 : Site Palmier3 : Palmier

Modèle structurel Première abstraction • Une classepeut être vue • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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 actif : Real {value  0} passif : Real { Personne.employeur = Personne.chef.employeur } chef <dirige contrainte sur attribut contrainte sur 2 associations

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

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

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

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

Autour des objets et du formalisme UML