uml présentation

UMLLe langage de modélisation unifié

Stéphane [email protected]

2011-2012

mailto:[email protected]

http://www.uvsq.fr

http://www.isty.uvsq.fr

Chapitre I : Préambule

1 Objectifs et prérequis

2 Plan

3 Références

Objectifs et prérequis

Objectifs du cours

Présenter la notation UMLSuivre une progression proche d’un processus de développementPrésenter le langage OCLAborder la méta-modélisation

Stéphane Lopes (UVSQ/ISTY) UML 2011-2012 1 / 197


http://www.uvsq.fr


Objectifs et prérequis

Prérequis

Connaissance des concepts objets



http://www.uvsq.fr


Plan

Plan général

IntroductionExprimer les besoinsModéliser le domaineSpécifier l’architecture de l’applicationConception OOArchitecture de déploiementLangage OCLMétamodélisation



http://www.uvsq.fr


Références

RéférencesBibliographie

UML 2 et les design patterns, Craig Larman, Pearson, 2005 (UVSQ :005.12 LAR)UML 2.0, Martin Fowler, CampusPress, 2004 (UVSQ : 005.12 FOW)UML 2 - de l’apprentissage à la pratique, Laurent Audibert, Ellipses,2009 (UVSQ : 005.12 AUD)UML 2 par la pratique , Pascal Roques, Eyrolles, 2009 (UVSQ :005.12 ROQ)MDA en action, Xavier Blanc, Eyrolles, 2005 (UVSQ : 005.12 BLA)


http://www.craiglarman.com/wiki/index.php?title=Book_Applying_UML_and_Patterns

http://www.craiglarman.com/

http://martinfowler.com/

http://gurau-audibert.hd.free.fr/josdblog/2009/11/livre-uml-2-de-lapprentissage-a-la-pratique/

http://gurau-audibert.hd.free.fr/josdblog/

http://www.editions-eyrolles.com/Livre/9782212125658/uml-2-par-la-pratique

http://www.dotnetguru2.org/proques/index.php

http://www.eyrolles.com/Informatique/Livre/mda-en-action-9782212115390


http://www.uvsq.fr


Références

RéférencesWebographie

Ressources sur UML sur le site de l’OMGUML Infrastructure 2.4.1 (août 2011)UML Superstructure 2.4.1 (août 2011)

UML sur Wikipedia (fr, en)Le site UML en françaisCours UML 2 de Laurent Audibert sur Developpez.comIntroduction to the Diagrams of UML 2.0, Scott W. Ambler, AgileModelingSite UML-DiagramsBest Practices for Applying UML


http://www.uml.org/

http://www.omg.org/

http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF

http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF

http://fr.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://uml.free.fr/

http://laurent-audibert.developpez.com/Cours-UML/html/index.html

http://www.agilemodeling.com/essays/umlDiagrams.htm

http://www.ambysoft.com/scottAmbler.html

http://www.agilemodeling.com/

http://www.agilemodeling.com/

http://www.uml-diagrams.org/

http://www.magicdraw.com/files/whitepapers/Best_Practices_for_Applying_UML_Part1.pdf


http://www.uvsq.fr


Chapitre II : Introduction

4 Qu’est-ce qu’UML ?

5 Modes d’utilisation

6 Historique

7 Mise en œuvre d’UML

8 Notions transversales


4 Qu’est-ce qu’UML ?Définition et contenuDiagrammesAutres standards


6 Historique



Qu’est-ce qu’UML ? Définition et contenu

UML

DefinitionUML (Unified Modeling Language) est un ensemble de notationsgraphiques s’appuyant sur un métamodèle et permettant de spécifier,visualiser et documenter des systèmes logiciels orientés-objet.

UML est un standard contrôlé par l’OMG (Object ManagementGroup)UML est le fruit de l’unification de plusieurs langages graphiques demodélisation objet


http://www.uml.org/

http://www.omg.org/


http://www.uvsq.fr



Contenu

UML définit une notation et un métamodèleLa notation est la représentation graphique des modèlesElle représente la syntaxe du langage de modélisationLe métamodèle apporte des éléments complémentaires pour préciserla signification des notations, i.e. leur sémantiqueLe métamodèle d’UML est représenté par des diagrammes de classeset des descriptions textuelles



http://www.uvsq.fr



ExempleUn extrait du métamodèle d’UML

source : Sample UML Metamodel (eclipse)


http://www.eclipse.org/m2m/atl/usecases/MMIndApproachtoDiffRep/img/umlMetamodel.png


http://www.uvsq.fr



Ce que n’est pas UML

UML n’est pas l’A/COOconnaître UML n’implique pas de savoir analyser et concevoir unsystème OO

UML n’est pas une méthodela précification UML ne donne pas d’indice sur la façon d’utiliser lesdiagrammes

UML n’est pas une approche formelleles éléments du langage ne sont pas définis formellement



http://www.uvsq.fr



UML ne suffit pas

Tous les diagrammes UML ne sont pas utiles dans chaque applicationIl existe d’autres documents utiles pour la description d’uneapplication

glossaires, enchaînement des écrans, . . .Il ne faut pas confondre un modèle et le diagramme le représentant

on représente généralement un cas d’utilisation par un documenttextuel



http://www.uvsq.fr


Qu’est-ce qu’UML ? Diagrammes

Diagrammes UML

UML définit deux grandes familles de diagrammesles diagrammes de structure spécifient les aspects statiques d’unsystèmeles diagrammes de comportement s’intéressent aux aspects dynamiquesdans cette catégorie, les diagrammes d’interaction décrivent leséchanges entre objets

UML 2.4.1 (août 2011) définit 14 diagrammes



http://www.uvsq.fr



Liste des diagrammes I

Activités processus métier ou logique d’une partie du systèmeCas d’utilisation relations entre les acteurs et les cas d’utilisation

Classes éléments statiques du modèle et leurs relationsCommunication intéractions entre instances (organisation structurelle)Composants composants, interfaces et relations entre les éléments du

systèmeDéploiement architecture d’exécution du systèmeEtats-transitions états et changements d’état d’un objet

Objets instantané de la structure des objetsPaquetages organisation des éléments de modélisation

Profil extension d’UMLSéquence intéractions entre instances (ordre des messages dans le

temps)Stéphane Lopes (UVSQ/ISTY) UML 2011-2012 12 / 197


http://www.uvsq.fr



Liste des diagrammes II

Structure composite structure interne d’un classeur avec ses pointsd’intéraction

Temps changements d’états d’un classeur dans le tempsVue d’ensemble des interactions flôt de contrôle d’un système (à grande

échelle)



http://www.uvsq.fr



Structuration des diagrammes

source : UML diagrams overview (Wikipedia)


http://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg


http://www.uvsq.fr


Qu’est-ce qu’UML ? Autres standards

UML et les autres standards

BPMN Business Process Modeling Notation est une notation pourreprésenter l’orchestration des processus métier d’uneorganisation

EMF Eclipse Modeling Framework est une framework demodélisation de la fondation Eclipse proche de MDA

MDA Model Driven Architecture est une approche dudéveloppement logiciel s’appuyant sur les modèles et leurstransformations

MOF Meta-Object Facility est un métamétamodèle proposé parl’OMG

SYSML Systems Modeling Language est un profil UMl pour ladescription de systèmes

XMI XML Metadata Interchange permet l’échange de modèlesMOF



http://www.uvsq.fr





6 Historique



Modes d’utilisation

Différents modes d’utilisation

UML peut être utilisé en pro-ingénierie ou en rétro-ingénierie selon troismodes :

Esquisse support de discussionPlan spécification pour l’équipe de programmeurs

Spécification exécutable spécification de la totalité du système



http://www.uvsq.fr



UML en mode esquisse

Les diagrammes servent de base à la discussionUniquement les aspects les plus importantsUtilise un sous-ensemble de la syntaxeLa syntaxe est parfois approximativeFait « à la main » ou avec des outils simples



http://www.uvsq.fr



UML en mode plan

Représentation exhaustive de la conceptionSert de référence pour les programmeursNécessite des outils évolués



http://www.uvsq.fr



UML pour des spécifications exécutables

Permet d’automatiser la tâche de programmationUML est alors vu comme un langage de programmationNécessite des outils sophistiquésApproche MDA (Model Driven Architecture) et MDE (Model DrivenEngineering)



http://www.uvsq.fr





6 Historique



Historique

Avant UML

Début des années 90Coexistence de plusieurs méthodes d’A/COODes concepts similaires sont représentés par des notations variées



http://www.uvsq.fr


Historique

Avant UMLQuelques méthodes

OOAD, Grady BoochObject-oriented analysis and design (OOAD), Grady Booch,Addison-Wesley, 1994

OOA/OOD, Peter Coad et Edward YourdonObject-Oriented Analysis, Peter Coad, Edward Yourdon, YourdonPress, 1991Object-Oriented Design, Peter Coad, Edward Yourdon, YourdonPress, 1991

OOSE, Ivar Jacobson pour ObjectoryObject-Oriented Software Engineering : A Use Case Driven Approach,Ivar Jacobson, Magnus Christerson, Patrik Jonsson, GunnarOvergaard, Addison-Wesley, 1992

OMT, Jim RumbaughObject-Oriented Modeling and Design, James Rumbaugh, MichaelBlaha, William Premerlani, Frederick Eddy, William Lorensen,Prentice Hall, 1991


https://www.ibm.com/developerworks/mydeveloperworks/blogs/gradybooch/?lang=en

http://www.informit.com/store/product.aspx?isbn=020189551X

http://yourdon.com/

http://blog.ivarjacobson.com/ivarblog/


http://www.uvsq.fr


Historique

Les prémisses d’UML

En 1994, Rumbaugh rejoint Booch chez RationalEn 1995, version 0.8 de la « méthode unifiée », rachat d’Objectorypar Rational, Jacobson se joint à l’équipeEn 1996, l’OMG s’implique dans le développement de la méthodeEn 1997, Rational publie la version 1.0 d’UML et la soumet à l’OMG



http://www.uvsq.fr


Historique

Historique des méthodes d’A/COO

source : History of object-oriented methods and notations (Wikipedia)


http://en.wikipedia.org/wiki/File:OO-historie-2.svg


http://www.uvsq.fr





6 Historique

7 Mise en œuvre d’UMLCycles de développementProcessus unifiéUML et processus unifié


Mise en œuvre d’UML Cycles de développement

Cycle de vie d’une application

La gestion du cycle de vie d’une application (Application lifecyclemanagement ou ALM) est un processus continu de suivi d’uneapplicationL’ALM regroupe la gestion de processus métier et les processus dedéveloppement logicielOrganise les activités de développement tout au long de la vie d’uneapplication



http://www.uvsq.fr



Principales activités

Modélisation métierGestion des exigencesAnalyse et conceptionImplémentationTestsDéploiementGestion des configurationsGestion de projet



http://www.uvsq.fr



Cycle linéaire

Les activités sont enchaînées avec peu de possibilités de retour enarrièreChaque activité est censée être terminée avant qu’une autre nedémarreCycle en cascade (années 1970)

les livrables d’une phase servent de point de départ pour la suivanteCycle en V (années 1980)

à chaque phase correspond une phase de validation



http://www.uvsq.fr



Cycle itératif et incrémental

Le processus global est un ensemble d’itérationsChaque itération conduit à une version exécutable de l’application quipeut être testéeUne itération peut introduire de nouveaux besoinsCycle en spirale

1 itération : définir les objectifs, identifier les risques, développer ettester, plannifier l’itération suivante

Processus unifiéméthode pilotée par les cas d’utilisation, centrée sur l’architecture,itérative et incrémentale

Méthode agileManifesto for Agile Software Developmentvaleurs fondamentales : les individus et leurs interactions, des logicielsopérationnels, la collaboration avec les clients, l’adaptation auchangementquelques méthodes : Scrum, eXtreme Programming


http://agilemanifesto.org/


http://www.uvsq.fr


Mise en œuvre d’UML Processus unifié

Introduction

UP (Unified Process) est né de la fusion des travaux de Booch,Rumbaugh et JacobsonLr processus unifié fournit un cadre général qu’il faut instancierLe Rational UP en est la version commerciale la plus répandueD’autres déclinaisons existent : Agile UP, Open UP


http://www-01.ibm.com/software/awdtools/rup/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://epf.eclipse.org/wikis/openup/


http://www.uvsq.fr



Caractéristiques

Piloté par les cas d’utilisation la réalisation du logiciel s’appuie sur lesbesoins fonctionnels

Centré sur l’architecture les choix d’architecture sont cruciaux pour laréussite du projet

itératif et incrémental la priorité est donnée aux cas d’utilisation les plusrisqués



http://www.uvsq.fr



Phases

Inception (initialisation) définition des objectifs et plannificationÉlaboration stabilisation de l’architecture, identification et élimination

des risques majeuresConstruction conception et réalisation des cas d’utilisation

Transition finalisation et livraison



http://www.uvsq.fr



Disciplines

Une discipline est un ensemble d’activité qui produisent des artefactsDisciplines d’ingénierie (workflows du processus)

Modélisation métierGestion des exigencesAnalyse et conceptionImplémentationTestsDéploiement

Disciplines de support (workflows de soutien)Gestion de la configuration et des changementsGestion de projetEnvironnement



http://www.uvsq.fr



Phases, disciplines et itérations

source : Rational Unified Process


http://en.wikiversity.org/wiki/File:RationalUnifiedProcess.png


http://www.uvsq.fr


Mise en œuvre d’UML UML et processus unifié

Mise en œuvre d’UML dans UP

Les disciplines d’UP produisent des artefactsCertains de ces artefacts peuvent être représentés partiellement oucomplétement par des diagrammes UMLUn diagramme peut être commencé durant une itération et complétépar la suiteLes artefacts et donc les diagrammes utilisés dépendent de la varianted’UP choisie



http://www.uvsq.fr





6 Historique



Notions transversales

Espace de noms

Un espace de noms (namespace) est un conteneur pour des élémentsnommésUn espace de noms peut être contenu dans un autre espace de nomsUn élément nommé peut être référencé par son nom qualifié(namespace-name::element-name)Un espace de noms ne possède pas de représentation graphique



http://www.uvsq.fr



Classeur

Un classeur (classifier) permet de décrire un ensemble d’instancespossédant des caractéristiques communes (propriétés ou opérations)Un classeur est un espace de nomIl est possible de définir des relations de généralisation entre classeursUn classeur est représenté graphiquement par un rectangle contenantle nom du classeur et d’éventuels compartimentsLe type de classeur peut apparaître entre guillemets avant son nom

+operation()

Classe

-attributCasUtilisation

<<use case>> CasUtilisation



http://www.uvsq.fr



Paquetage

Un paquetage (package) est un espace de nom regroupant desélémentsLes paquetages peuvent être imbriquésIl est représenté comme une pochette à ongletLe nom du paquetage apparaît sur la pochette ou dans l’onglet

Util IHM

Application



http://www.uvsq.fr



Mot-clé, stéréotype et tagged value

Un mot-clé (keyword) est définit dans le métamodèle UML etapparaît entre guillemets ou entre accoladesUn stéréotype (stereotype) fait partie des mécanismes d’extensiond’UMLIl précise comment une métaclasse existante est étendue par un profilIl est appliqué à un élément de modèle en le faisant apparaître entreguillemets devant le nom de l’élémentIl peut posséder des propriétésCes propriétés apparaissent comme des couples (attribut, valeur)(tagged value) au niveau de l’instance du stéréotype



http://www.uvsq.fr



Note

Un commentaire (note) est un élément représentant une annotationtextuelleUne note peut être attachée à plusieurs élémentsUne note est représentée par un rectangle corné et reliée aux élémentsannotés par une ligne pointillée

ClasseNote sur la classe.



http://www.uvsq.fr


Chapitre III : Exprimer les besoins

9 Généralités

10 Besoins fonctionnels

11 Autres besoins

Généralités

Définition

Les besoins sont les conditions qu’un projet doit satisfaireDans une approche itérative, les besoins évoluent durant le projetLa collecte des besoins est une tâche cruciale faisant appel àdifférentes techniques (rédaction des cas d’utilisation avec le client,ateliers d’expressions des besoins, . . . )



http://www.uvsq.fr


Généralités

Classification des besoinsL’exemple du modèle FURPS+

Functionality Fonctionnalité, capacités et sécuritéUsability Facteurs humains, aide et documentationReliability Fiabilité, fréquence des pannes, récupération

Performance Temps de réponse, disponibilitéSupportability Adaptabilité, internationalisation, facilité de maintenanceImplémentation Langages et outils, matériel

Interface Interactions avec des systèmes externesExploitation Gestion du système dans l’environnement de productionConditionnementAspects juridiques Licences

IntérêtCes classifications ont pour objectif d’éviter de négliger un aspect dusystème.



http://www.uvsq.fr


Généralités

Expressions des besoins dans UPLes artefacts

Modèle de cas d’utilisation décrit les besoins fonctionnelsSpécifications supplémentaires exprime les besoins non fonctionnels

Glossaire représente le dictionnaire de donnéesVision donne un aperçu de haut niveau du projet

Règles métier décrivent les règles du domaine non spécifiques à uneapplication



http://www.uvsq.fr


Généralités

Analyse des besoins et UPPhases d’inception et d’élaboration

La phase d’inception n’est pas la phase de définition des besoinsC’est une courte phase initiale qui permet de déterminer l’opportunitédu projetElle comprend l’analyse

d’une petite partie des besoins fonctionnelles,des besoins non fonctionnels critiques.

Les besoins sont ensuite enrichis durant la phase d’élaboration voirede construction



http://www.uvsq.fr



9 Généralités

10 Besoins fonctionnelsCas d’utilisationDiagramme de cas d’utilisationDiagramme de séquence système

11 Autres besoins

Besoins fonctionnels Cas d’utilisation

Qu’est qu’un cas d’utilisation ?

Un cas d’utilisation est une description textuelle de la façon dont desacteurs vont utiliser le système pour atteindre un butLes cas d’utilisation ne sont pas des diagrammes mais bien des textes

RemarqueLes cas d’utilisation ne sont pas orientés objet



http://www.uvsq.fr



Concepts

Sujet système en cours d’étudeActeur entité qui possède un comportement (personne ou système)

principal possède des buts qu’il atteint en utilisant lesystème

auxiliaire fournit un service au systèmehors-champs est concerné mais n’est pas principal ou

auxiliaireScénario séquence d’actions et d’interactions entre un ou plusieurs

acteurs et le système. On parle aussi d’instance de casd’utilisation.

Cas d’utilisation collection de scénarios décrivant la façon dont un ouplusieurs acteurs va utiliser le système pour atteindre un but



http://www.uvsq.fr



Niveaux de détails

abrégé résumé succinct du scénario de base en un paragrapheinformel un paragraphe par scénariodétaillé les étapes et les variantes sont détaillées



http://www.uvsq.fr



Sections d’un cas d’utilisation I

Nom Nom du cas d’utilisation (commence par un verbe).Périmètre Le système en cours de conception (cas d’utilisation

système). Un cas d’utilisation peut aussi décrire lesinteractions au sein d’un domaine (cas d’utilisation métier).

Niveau But utilisateur ou sous-fonction (factorise les étapescommunes à plusieurs cas d’utilisation).

Acteur principal Atteint son but grâce au système.Parties prenantes et intérêts Qui est concerné par ce cas d’utilisation ? Ce

que ça leur apporte.Préconditions Conditions initiales à remplir pour que le cas d’utilisation se

déroule.Garanties en cas de succès Ce qui est réalisé (postconditions).



http://www.uvsq.fr



Sections d’un cas d’utilisation II

Scénario principal Scénario de succès (« happy path ») sans conditions nibranchements.

Extensions Scénarios alternatifs de succès ou d’échec. Ce sont desbranches qui partent du scénario principal.

Spécifications particulières Besoins non fonctionnels directement liés aucas d’utilisation.

Liste de variantes des données et des technologies Méthdes d’E/S etformats de données.

Fréquence d’occurence « Importance » du cas d’utilisation.Divers Questions ouvertes.



http://www.uvsq.fr



Recommandation pour la rédaction de cas d’utilisation

Utiliser le style « essentiel » : se concentrer sur l’intention de l’acteuret non sur l’IHM.Rédiger avec concision.Rédiger des cas d’utilisation en « boîte noire » : ne pas décrire lefonctionnement interne du système (le comment) mais lesresponsabilités (le quoi).Doit être centré sur les acteurs et leurs buts : les résultats doiventavoir de la valeur pour les acteurs.



http://www.uvsq.fr


Besoins fonctionnels Diagramme de cas d’utilisation

Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation d’UML permet de représenter :les noms de cas d’utilisation,les acteurs,les relations entre acteur et cas d’utilisation.

Il fait partie des diagrammes de comportement d’UML



http://www.uvsq.fr



Exemple de diagramme de cas d’utilisation

Extrait d’un diagramme de cas d’utilisation pour l’étude de cas stages



http://www.uvsq.fr



Notations du diagramme de cas d’utilisation

Un cas d’utilisation est représenté par une ellipse contenant le nom ducas d’utilisation ou comme un classeur marqué par le stéréotype« use case »Un rectangle contenant les cas d’utilisation et le nom du sujetmodélisé marque les limites du systèmeLes acteurs se trouvent à l’extérieur de ces limitesUn acteur est représenté par un symbole spécifique ou par un classeurmarqué par le stéréotype « actor »Des relations d’association relient acteurs et cas d’utilisation



http://www.uvsq.fr



Relations entre cas d’utilisation

Un cas d’utilisation A inclut un cas B si le comportement décrit par lecas A inclut le comportement du cas BLorsque A est sollicité, B l’est obligatoirement aussiCette relation est représentée par une dépendance (flêche pointillée)de A vers B marquée par le stéréotype « include »Un cas d’utilisation A étend un cas B si le cas A peut être appelé aucours de l’exécution de BCette relation est représentée par une dépendance de A vers Bmarquée par le stéréotype « extend »Un cas d’utilisation A est une généralisation d’un cas B si B est uncas particulier de ACette relation est représentée comme un lien d’héritage entre B et A



http://www.uvsq.fr



Exemple de relation d’inclusion




http://www.uvsq.fr



Exemple de relation d’extension




http://www.uvsq.fr



Exemple de généralisation entre cas d’utilisation




http://www.uvsq.fr



Relations entre acteurs

Un acteur A est une généralisation d’un acteur B si A peut sesubstituer à BCette relation est représentée comme un lien d’héritage entre B et ATous les cas d’utilisation accessibles à A le sont aussi à B



http://www.uvsq.fr



Exemple de généralisation entre acteurs




http://www.uvsq.fr



Recommandations à propos du diagramme de casd’utilisation

Ne pas consacrer trop d’efforts aux diagrammes mais plutôt auxdescriptions textuellesCe diagramme sert de table des matières graphique pour les casd’utilisation du système et permet de visualiser les limites du systèmeLes relations d’inclusion, d’extension, . . . sont à utiliser avecparcimonie : elles rendent le diagramme plus complexe et il estpréférable de se focaliser sur le texte.



http://www.uvsq.fr


Besoins fonctionnels Diagramme de séquence système

Diagramme de séquence système

Un diagramme de séquence système (DSS) est un artefact illustrantles entrées/sorties du systèmeIl fait parti du modèle de cas d’utilisationLe diagramme de séquence d’UML est bien adapté à la représentationde cet artefact



http://www.uvsq.fr



Intérêt des DSS

Un DSS explicite un scénario de cas d’utilisationIl représente les évènements générés par les acteurs et leur ordre vis àvis de systèmeLes systèmes sont considérés comme des boites noiresUn DSS est créé pour chaque scénario complexe d’un cas d’utilisation



http://www.uvsq.fr



Introduction au diagramme de séquence UML

Un diagramme de séquence fait parti des diagrammes d’interactiond’UMLL’objectif des diagrammes d’interaction est de mettre en évidence lerôle des participants ainsi que les messages échangésUn diagramme de séquence permet de représenter l’ordre deséchanges de messages entre des instancesDans un DSS, les instances représentent le système et les acteursLors de la conception, les instances sont les objets logiciels del’application



http://www.uvsq.fr



Principaux concepts

Participant élément impliqué dans l’interactionLigne de vie représente un participant de l’interaction

Message description d’une interactionÉvènement envoie/réception d’un message, signal, . . .



http://www.uvsq.fr



Exemple de DSS

Diagramme de séquence « Tutorer un stage »



http://www.uvsq.fr



Notation

Une ligne de vie est représentée par un rectangle accroché à une ligneverticale pointilléeLe rectangle contient le nom du participant et/ou son type (séparépar « : »)Un message est représenté par une flèche en trait plein dirigée vers lacible

pointe ouverte : message asynchronepointe pleine : message synchrone

Un message synchrone peut être suivi d’une réponse (flèche enpointillée)Un rectangle sur une ligne de vie marque l’exécution d’un traitement



http://www.uvsq.fr



9 Généralités

10 Besoins fonctionnels

11 Autres besoins

Autres besoins

Besoins non fonctionnels

Les besoins fonctionnels ne couvrent qu’une partie des besoins d’uneapplicationLes besoins restant sont nommés besoins non fonctionnelsLa classification FURPS en montre différents types (performance, . . . )Ces besoins ne sont pas décrits par le modèle de cas d’utilisation maispar d’autres documents



http://www.uvsq.fr


Autres besoins

Expressions des besoins non fonctionnels dans UPLes artefacts

Spécifications supplémentaires capturent les autres besoins comme lepackaging, les licences, . . .

Glossaire représente le dictionnaire de donnéesVision communique les idées importantes du projet

Règles métier décrivent les règles du domaine non spécifiques à uneapplication



http://www.uvsq.fr


Chapitre IV : Modéliser le domaine

12 Généralités

13 Diagramme de classes

14 Diagramme d’activités

Généralités

Modélisation métier

La modélisation métier est une discipline de UPElle rend compte de la « structure et la dynamique de l’organisationoù doit être déployé un système »Le modèle objet métier (Business Objet Model ou BOM) est unartefact de cette disciplineIl représente à la fois les aspects statiques (modèle du domaine) etdynamiques (modèle des processus métier) d’un domaine



http://www.uvsq.fr


Généralités

Modèle du domaine

Le modèle du domaine est un modèle statique très important enA/COOIl permet de visualiser les concepts métier (classes conceptuelles) etleurs relationsIl servira de source d’inspiration pour un certain nombre d’objetslogicielsCet artefact UP peut êre constitué d’un ensemble de diagrammes declasses UML (sans opération)



http://www.uvsq.fr


Généralités

Ce que n’est pas le modèle du domaine

Il ne représente pas des objets logicielsCe n’est pas un ensemble de diagrammes décrivant les classeslogiciellesCe n’est pas une représentation de la couche domaine d’unearchitecture logicielleCe n’est pas un modèle de données



http://www.uvsq.fr


Généralités

Classe conceptuelle

Une classe conceptuelle est une entité du domaine étudiéElle comporte :

un nom qui identifie le concept,une intension qui la définit en terme de propriétés,une extension qui précise l’ensemble des instances de ce concept.



http://www.uvsq.fr


Généralités

Modèle des processus métier

Le modèle des processus métier (Business Process Model ou BPM)est un modèle dynamiqueIl permet de visualiser l’enchaînement des activités dans un domainedonnéCet artefact UP peut être constitué d’un ensemble de diagrammesd’activités UML



http://www.uvsq.fr



12 Généralités

13 Diagramme de classesIntroductionClasseRelations entre classes

14 Diagramme d’activités

Diagramme de classes Introduction

Diagramme de classes UML

Un diagramme de classe décrit les types des objets qui composent unsystème et les différents types de relations statiques qui les relientDans le contexte de la modélisation métier, ce diagramme sert dedictionnaire de données visuel



http://www.uvsq.fr


Diagramme de classes Classe

Classe

Une classe est un classeur décrivant un type d’objetsUne classe possède des propriétés et des opérations globalementnommées caractéristiquesDans le modèle du domaine, seules les propriétés sont utilisées



http://www.uvsq.fr



Notation

Une classe est représentée comme un rectangle comportant plusieurscompartimentsLe premier compartiment montre le nom de la classe, le second sespropriétés et le troisième les opérationsSeul le compartiment du nom est obligatoire et d’autrescompartiments peuvent être ajoutés (responsabilités, exceptions)Le nom de la classe débute par une majucule et peut être qualifié pardes espaces de nomsLa classe peut être associée à des mots-clés entre accolades après sonnom ({abstract})



http://www.uvsq.fr



Exemple de classe

Une classe de l’application SIGS



http://www.uvsq.fr



Propriété

Les propriétés décrivent les caractéristiques structurelles d’une classeElles peuvent apparaître sur le diagramme sous la forme d’attribut oude terminaison d’association (cf. section suivante)



http://www.uvsq.fr



Attribut

Un attribut apparaît dans un compartiment d’une classe sous la formed’une chaîne de caractères :visibilité / nom : type multiplicité = valeurParDéfaut {mots-clé}

Seul le nom est obligatoireLa visibilité contrôle l’accès à l’attribut : public (+), protected (#),package (˜), private (-)Le caractère « / » précise que l’attribut est calculéLa multiplicité précise le nombre d’instances de l’attributIl est possible d’indiquer une borne inférieure et une borne supérieurepour la multiplicité (* pour illimité) ([0..1], [1], [1..*], . . . )Les mots-clé modifient les caractéristiques de l’attribut ({readOnly},. . . )Un attribut de classe est représenté en soulignant l’attribut



http://www.uvsq.fr


Diagramme de classes Relations entre classes

Association

Une association est un lien structurel entre deux (association binaire)ou plusieurs (association n-aire) classesCe lien est visualisé comme un trait continu reliant les classesUne flêche pointe sur la classe cible (type de la propriété) et exprimela navigabilité de l’associationLa plupart des informations d’un attribut peuvent être utilisées surune terminaison d’association (extrémité)Le nom et la multiplicité de la propriété apparaîssent près de la flèchedu côté cibleL’association peut être bidirectionnelle (flèche des deux côtés) etreprésente une paire de propriétés liéesUne association peut aussi être nommée avec un groupe verbal et lesens de lecture peut être indiqué



http://www.uvsq.fr



Exemple d’association

Représentation des associations



http://www.uvsq.fr



Association ou attribut

Les attributs sont en général utilisés pour des propriétés simples(chaîne, date, booléen, . . . )Les associations relient plutôt des classes du domaine



http://www.uvsq.fr



Association n-aire et classe d’association

Représentation des associations n-aires



http://www.uvsq.fr



Interprétation de la multiplicité

La multiplicité d’une terminaison d’association indique le nombred’objets pouvant occuper la position de la terminaisonPour une association binaire, la multiplicité contraint le nombred’objets de la classe cible, associé à un objet de la classe sourcePour une association n-aire, la multiplicité d’une terminaisoncontraint le nombre d’objets de la classe liée à cette terminaison,associé à un n-1-uplet d’instances des autres participantsLa spécification de multiplicité (en particulier minimale) pour uneassociation n-aire peut imposer des contraintes complexes à percevoir⇒ se limiter à une multiplicité minimale de 0 et maximale de 1 ou *



http://www.uvsq.fr



Multiplicité et cardinalité d’entité/association

Pour une association binaire, la notation de la multiplicité est inverséepar rapport à la notation de la cardinalité d’entité/associationPour une association n-aire, les sémantiques des deux notions sontdifférentes



http://www.uvsq.fr



Agrégation et composition

L’agrégation et la composition représente une relation tout/partieDans l’agrégation,

le cycle de vie de l’agrégat et des parties n’est pas lié,la navigabilité et la multiplicité ne sont pas contraintes.

Dans la composition,le cycle de vie de l’agrégat et des parties est lié,la multiplicité côté agrégat est d’au plus 1.

Graphiquement, l’agrégation se représente par un losange vide et lacomposition par un losange plein du côté de l’agrégat



http://www.uvsq.fr



Exemple d’agrégation et de composition

Représentation de l’agrégation et de la composition



http://www.uvsq.fr



12 Généralités


14 Diagramme d’activitésIntroductionFlot de contrôleFlot de donnéesStructuration des activitésInterruption d’activités

Diagramme d’activités Introduction

Diagramme d’activités UML

Un diagramme d’activité UML visualise un modèle de traitements, i.e.l’enchaînement des activités d’un processusIl permet de représenter la séquence et le parallèlismeIl peut être utiliser pour modéliser des processus métier, desworkflows, des flots de données ou des algorithmes complexes



http://www.uvsq.fr



Principaux concepts

Action traitement élémentaireActivité séquence organisée d’actions

Transition spécifie l’enchaînement des traitements (flot de contrôle)



http://www.uvsq.fr



Exemple de diagramme d’activités

Un diagramme d’activités pour l’application SIGS



http://www.uvsq.fr


Diagramme d’activités Flot de contrôle

Activité et action

Une action est un traitement élémentaire (call operation, create, . . . )Une action est représentée par un nœud actionUne activité est un ensemble organisé d’actions et/ou de sous-activitésLe flot d’exécution est modélisé par des nœuds reliés par destransitionsUne activité est un comportement



http://www.uvsq.fr



Nœud et transition

Un nœud d’activité représente graphiquement les phases d’uneactivitésIl en existe trois types :

un nœud action visualise une action,un nœud objet visualise les échanges de données,un nœud de contrôle modélise le flot d’exécution.

Une transition représente le passage d’une action à une autreElle est déclenchée dès que l’action source se termine, provoque ledébut de l’action suivante et est instantanée



http://www.uvsq.fr



Nœuds de contrôle

Les nœuds de contrôle modifie le flot d’exécution d’une activitéIl en existe plusieurs types :

initial début d’une activitéfin d’activité fin d’une activité

fin de flot fin d’un flot d’exécution sans terminer l’activitédécision choix entre plusieurs flotsfusion regroupement de plusieurs flots

bifurcation début d’activités en paralèlleunion synchronisation de plusieurs flots



http://www.uvsq.fr



Représentaton graphique des nœuds de contrôle

initial cercle pleinfin d’activité cercle plein entouré d’un cercle vide

fin de flot cercle barré d’un X

décision/fusion losange videbifurcation/union barre pleine



http://www.uvsq.fr



Exemple de diagramme d’activités




http://www.uvsq.fr



Nœud de décision et de fusion

Un nœud de décision marque un choix entre plusieurs flots de sortieChaque flot de sortie est conditionné par une garde (prédicat)Cette garde est évaluée pour savoir quel flot est franchissableL’ensemble des gardes doit normalement former une partition del’ensemble des décisions possibles

si aucune transition n’est franchissable, le modèle est mal formési plusieurs sont franchissables, le choix est non déterministe

Un nœud de fusion regroupe plusieurs flots alternatifs en un seul



http://www.uvsq.fr



Nœud de bifurcation et d’union

un nœud de bifurcation (ou débranchement) sépare un flot en tranten plusieurs flots sortants concurrentsun nœud d’union (ou jointure) synchronise plusieurs flots en trantsconcurrents



http://www.uvsq.fr


Diagramme d’activités Flot de données

Flot d’objets

Le flot d’objet représente explicitement les éléments échangés par lesactionsSur le diagramme d’activité, on peut visualiser les paramètres d’uneaction ainsi que les objets échangés



http://www.uvsq.fr



Exemple de flots de données




http://www.uvsq.fr



Nœud objet

Un nœud objet permet de représenter le flot d’objets échangés entreles actionsIl possède un nom, un type, une éventuelle liste d’états etd’éventuelles contraintesIl peut être représenté comme

un paramètre d’entrée ou de sortie d’une action (petit carré sur labordure d’une action),un rectangle sur une transition précisant l’ensemble des informationsassociéesun tampon central (central buffer) qui accepte plusieurs entrées ousorties d’objetsun stockage de données (datastore) qui est un tampon central assurantla persistance



http://www.uvsq.fr


Diagramme d’activités Structuration des activités

Partition

Une partition (ou couloir ou ligne d’eau) permet de regrouper lesnœuds d’activitéLe regroupement peut se faire selon divers critères (responsable del’action, . . . )La partition peut être bidimensionnelle



http://www.uvsq.fr



Exemple de partitions




http://www.uvsq.fr



Nœud structuré

Un nœud structuré représente une portion structurée d’une activitéGraphiquement, c’est un rectangle en trait pointillé (stéréotype« structured »)Il en existe quatre types :

séquentiel (stéréotype « sequence »)conditionnel (stéréotype « conditional »)boucle (stéréotype « loop »)zone d’expansion



http://www.uvsq.fr



Exemple de nœud structuré




http://www.uvsq.fr



Zone d’expansion

Une zone d’expansion représente une activité s’appliquant à unecollection d’objetsLa collection est passée en paramètre de la zone d’expansion et unecollection est produite en sortieUn stéréotype précise le fonctionnement de la zone (« parallel »,« iterative », « stream »)



http://www.uvsq.fr



Exemple de zone d’expansion




http://www.uvsq.fr


Diagramme d’activités Interruption d’activités

Signaux

Des nœuds d’action spécifique permettent de manipuler des signauxIl en existe trois types :

réception d’un signal (accept event)envoi d’un signal (send signal)attente d’un évènement temporel (accept time event)



http://www.uvsq.fr



Exemple de signaux




http://www.uvsq.fr



Exceptions

Les exceptions peuvent être représentées sur le diagramme d’activitéUne activité pouvant lever un exception l’indique à l’aide d’un pin desortie surmonté d’un petit triangle et précisant le type de l’exceptionUn gestionnaire d’exception est une action possédant un pin d’entréedu type de l’exception et les mêmes pins de sortie que l’activitésurveilléeL’activité surveillée est reliée au gestionnaire par un trait en zigzag ousurmonté d’un zigzag



http://www.uvsq.fr



Région interruptible

Une région interruptible est une zone délimité d’une activité dont leflot peut être interrompue par un évènement nommé interruptionCette zone est délimitée par un rectangle pointillé aux coins arrondisLorsque l’interruption se produit, l’exécution se poursuit dans ungestionnaire d’interruptionl’émission de l’évènement et le gestionnaire sont reliés par un trait enzigzag



http://www.uvsq.fr


Chapitre V : Architecture de l’application

15 Généralités

16 Diagramme de packages UML

Généralités

Définition

L’architecture logique d’une application donne une vue globale de laconception d’un systèmeElle précise les modules dans lequels vont être créées les classeslogiciellesElle n’implique pas de décision technique (OS, distribution,. . . )

les décisions techniques font parties de l’architecture de déploiementEn général, une application OO est composée de plusieurs couches(interface, métier, . . . )



http://www.uvsq.fr


Généralités

Principales couches d’une architecture logique

Présentation éléments de l’interface utilisateur (fenêtres, rapports, . . . )Application gestion des interactions avec la couche présentation, gestion

des processus métier, transformation de donnéesDomaine règles et services du domaine

Infrastructure métier services (éventuellement externe) liés au métierServices techniques services techniques de haut niveau (persistance,

sécurité, journalisation, . . . )Fondation services et bibliothèques de bas niveau (I/E, threads, . . . )



http://www.uvsq.fr


Généralités

Architecture dans UP

la spécification de l’architecture appartient au Modèle de Conception(discipline Conception)représentée sous la forme de diagramme de packages UML ou dans leDocument d’Architecture Logiciels’appuie sur les Spécifications Supplémentaires



http://www.uvsq.fr


Chapitre V : Architecture de l’application

15 Généralités

16 Diagramme de packages UML

Diagramme de packages UML

Introduction

Un diagramme de package permet de réprésenter les couches,sous-systèmes ou modules d’un logicielIl montre le regroupement d’élément de modélisation (classes, casd’utilisation, autres packages, . . . )Il visualise également l’imbrication de modules



http://www.uvsq.fr



Notation

Un package est représenté par une sorte de pochette à ongletLe nom du package apparaît soit dans l’onglet, soit directement sur lapochetteLe diagramme de package montre également les dépendances entrepackageUne dépendance est visualisée comme une flèche pointillée (ligne dedépendance) partant du package dépendant vers le package dont ildépendUn package est aussi un espace de nom



http://www.uvsq.fr



ExempleUn diagramme de packages pour une architecture en couche

source : Layered application model diagram


http://www.uml-diagrams.org/package-diagrams-examples.html


http://www.uvsq.fr



ExempleTrois façons de représenter l’imbrication

source : Package org.hibernate


http://www.uml-diagrams.org/package-diagrams.html


http://www.uvsq.fr


Chapitre VI : Conception OO

17 Généralités

18 Diagramme d’interaction UML


20 Diagramme d’objets

21 Diagramme de machine à états

Généralités

Définition

La conception OO consiste à identifier les classes logicielles et à leurattribuer des responsabilitésDifférentes approchesconcevoir en codant utilise par exemple des outils comme le

refactoring (approche TDD) et des diagrammes enmode esquisse

tracer des diagrammes et coder UML est un support de discussionet/ou de documentation

tracer uniquement les diagrammes approche de type MDELa question est de savoir quels diagrammes apportent une valeurajoutée pour la conception OO



http://www.uvsq.fr


Généralités

Modèle objet statique et dynamique

Les modèles dynamiques comme les diagrammes d’interaction UMLreprésentent la logique comportementaleLes modèles statiques comme les diagrammes de classes ou d’objetsUML visualisent la structure de l’applicationLe plus difficile et le plus intéressant est la réalisation du modèledynamique (création d’objets, échange de message, . . . )Il faut pour cela identifier les responsabilités des classes logiciellesCes modèles sont en général réalisés en « parallèle »Tous ces modèles font partis du Modèle de Conception UP



http://www.uvsq.fr


Généralités

Quelques techniques de conception OO

Conception piloté par les responsabilitésréfléchir à la façon d’affecter des responsabilités aux objetsce qu’un objet sait et ce qu’il faitcommunauté d’objets responsables qui collaborent

Principes GRASP (General Responsibility Assignment SoftwarePrinciples)Modèles de conception GoFCartes CRC (Classe-Responsabilité-Collaboration) fiches cartonnées(une par classe) détaillant les responsabilités et les collaborations



http://www.uvsq.fr



17 Généralités

18 Diagramme d’interaction UMLConcepts communsNotation des diagrammes de séquenceNotation des diagrammes de communicationAutres diagrammes d’interaction




Diagramme d’interaction UML

Introduction

Un diagramme d’interaction représente un modèle dynamiqueSon rôle est de visualiser les objets interagissant par l’intermédiaire demessagesUML en propose quatre types

diagramme de séquencediagramme de communicationdiagramme de vue d’ensemble des interactionsdiagramme de temps

RemarqueLes diagrammes de séquence ont déjà été introduits dans la section sur lesdiagrammes de séquence système



http://www.uvsq.fr


Diagramme d’interaction UML

Diagramme de séquence ou diagramme decommunication ?

Diagramme de séquence+ représentation claire de l’ordonnancement des messages+ notation riche- gestion du schéma difficile

Diagramme de communication+ gestion du schéma simple- la numérotation rend plus difficile la lecture de l’ordre des messages- notation plus limitée



http://www.uvsq.fr


Diagramme d’interaction UML Concepts communs

Ligne de vie

Une ligne de vie (lifeline) représente un participant dans uneinteractionEn général, une ligne de vie correspond à une instance d’une classeUne ligne de vie est représentée graphiquement par un rectangle danslequel se trouve le libellé de l’élémentLe libellé peut prendre différentes formes: Convention instance anonyme de la classe Conventionc1 : Convention instance nommée c1conventions : List<Convention> instance de collection

paramétréeconventions[i] : Convention instance sélectionnée dans la

collection collections

Dans un diagramme de séquence, le rectangle est connecté à uneligne vertical représentant le temps (de haut en bas)



http://www.uvsq.fr


Diagramme d’interaction UML Concepts communs

Message

Une interaction entre participants est représentée par un messageUn message UML possède une syntaxe standardretour = message (param : TypeParam) : TypeRetour

A part le nom du message, tous les éléments sont optionnels



http://www.uvsq.fr


Diagramme d’interaction UML Notation des diagrammes de séquence

Message

Un message relie deux lignes de vieUn message est représenté par une flèche en trait plein dirigée vers lacible

pointe ouverte : message asynchronepointe pleine : message synchrone

Un message synchrone peut être suivi d’une réponse (flèche enpointillée)L’invocation d’une méthode de classe a pour cible un participantinstance de métaclasse (stéréotypé « metaclass »)



http://www.uvsq.fr



Spécification d’excution

Une barre de spécification d’exécution marque l’exécution d’untraitementElle est visualisée par un rectangle sur une ligne de vie



http://www.uvsq.fr



ExempleDiagramme de séquence

Sequence diagram major elements.


http://www.uml-diagrams.org/sequence-diagrams.html


http://www.uvsq.fr



Création et destruction de participants

Un message de création est représenté par une flèche pointilléeLa ligne de vie de l’objet créé est placé à la hauteur du message decréationUn message de destruction est annoté par le stéréotype « destroy »Le moment de la destruction d’un participant et repéré par une croixsur sa ligne de vie



http://www.uvsq.fr



Cadre

Un diagramme de séquence peut comporter des cadresUn cadre permet de regrouper ensemble des échanges de messagesUn cadre comporte un opérateur et éventuellement une gardeLes principaux opérateurs sont l’alternative (alt), la boucle (loop),le fragment optionnel (opt), le parallélisme (par) et la région critique(region)Les cadres peuvent être imbriqués



http://www.uvsq.fr



ExempleLes principaux cadres

Combined fragments.




http://www.uvsq.fr



Utilisation d’interaction

Une utilisation d’interaction est une référence à une interaction ausein d’une autreLes utilisations d’interaction s’appuie sur deux cadres

un cadre étiqueté sd suivi d’un nom et contenant un diagrammeclassiqueun cadre étiqueté ref contenant le nom de l’interaction référencée



http://www.uvsq.fr



ExempleUtilisation d’interaction

Interaction Use.




http://www.uvsq.fr


Diagramme d’interaction UML Notation des diagrammes de communication

Lien

Un lien est une connexion entre deux objetsC’est une instance d’associationIl est représenté par une ligne continue entre les lignes de viePlusieurs messages peuvent circuler sur le même lien



http://www.uvsq.fr



Message

Un message est une expression associée à une flèche pointant vers ledestinataireUn numéro de séquence est associé à chaque messageChaque numéro précise l’ordre dans lequel les messages sont échangésainsi que l’imbrication des appelsUn message peut posséder une garde



http://www.uvsq.fr



ExempleDiagramme de séquence

An example of communication diagram for online bookshop.


http://www.uml-diagrams.org/communication-diagrams-examples.html


http://www.uvsq.fr


Diagramme d’interaction UML Autres diagrammes d’interaction

Diagramme de vue d’ensemble des interactions

Ce diagramme représente le flot de contrôle entre les interactionsC’est un diagramme d’interaction mais il est également proche dudiagramme d’activité



http://www.uvsq.fr



ExempleUn diagramme de vue d’ensemble des interactions

source : An example of interaction overview diagram for online shopping.


http://www.uml-diagrams.org/interaction-overview-diagrams-examples.html


http://www.uvsq.fr



Diagramme de temps

Le diagramme de temps met l’accent sur la représentation desinteractions dans le temps



http://www.uvsq.fr



ExempleUn diagramme de temps

source : User Experience Website Latency.


http://www.uml-diagrams.org/timing-diagrams-examples.html


http://www.uvsq.fr



17 Généralités





Diagramme de classes

Diagramme de classes de conception

RemarqueLes diagrammes de classes ont déjà été introduits dans la section sur lamodélisation du domaine.

Le Diagramme de Classes de Conception représente les classeslogicielles d’une application



http://www.uvsq.fr



Opérations

Le troisième compartiment d’une classe contient la signature desopérations supportées par la classeLa syntaxe complète est la suivante :visibilité opération (liste de param.) : TypeRetourpropriétés

Les propriétés indiquent par exemple les exceptions lancées parl’opération, l’indication d’une opération abstraite, . . .Une méthode est l’implémentation d’une opération



http://www.uvsq.fr



ExempleUn diagramme de classes

source : Classes, interfaces, associations, usage, realization.


http://www.uml-diagrams.org/class-diagrams-overview.html


http://www.uvsq.fr



Généralisation, classes abstraites et polymorphisme

La relation de généralisation est représentée par une ligne continueterminée par une triangle blanc pointant sur la classe la plus généraleCe lien exprime une relation taxonomique entre une classe plusspécifique et une classe plus généraleDans un diagramme de classes de conception, ce lien est assimilé à lanotion d’héritage d’un langage de programmationUne classe ou une opération abstraite est annotée avec le mot-clé{abstract} ou écrite en italique



http://www.uvsq.fr



Interface

Une interface est représentée comme un classeur avec le stéréotype« interface »La réalisation d’une interface par une classe est visualisée par une lignepointillée terminée par une triangle blanc pointant vers l’interfaceIl est aussi possible d’utiliser une notation abrégée (socket)



http://www.uvsq.fr



Type de données

Un type de données UML est un classeur dont les instances sontidentifiées uniquement par leurs valeurs (objet-valeur)Un type de données est représenté par un rectangle avec le stéréotype« dataType »Un type de donées peut posséder des attributs et des opérationsUn type primitif est une type de données utilisé pour représenter desvaleurs atomiques (entier, flottant, . . . )Un type primitif est visualisé grâce au stéréotype « primitive »Une énumération est un type de données dont les valeurs sont définiesdans le modèleUne énumération apparaît avec le stéréotype « enumeration » etpeut posséder un compartiment listant les valeurs



http://www.uvsq.fr



17 Généralités





Diagramme d’objets


Un diagramme d’objets montre des objets et les liens qui les relientC’est une instance d’un diagramme de classeIl permet de représenter le contexte d’une interaction, i.e. l’état del’application avant ou après une interactionC’est un instantané de l’état d’un système à un instant donnéLes objets sont représentés par des rectangles contenant le nom del’objet souligné



http://www.uvsq.fr



ExempleUn diagramme d’objets

source : Instance specifications, value specifications, slots, and links.


http://www.uml-diagrams.org/class-diagrams-overview.html


http://www.uvsq.fr



17 Généralités





Diagramme de machine à états


Une machine à états présente les états intéressants d’un objet ainsique son comportement face à des événementsUn état est visualisé par un rectangle aux bords arrondisUne machine à état comporte en général un pseudo-état initial et unétat final (même notation que pour le diagramme d’activité)



http://www.uvsq.fr



ExempleUn diagramme de machine à états

source : High level behavioral state machine for bank ATM.


http://www.uml-diagrams.org/state-machine-diagrams.html


http://www.uvsq.fr



Transition

Une transition représente un changement d’état de l’élément modéliséElle peut comporter une étiquette (libellé [garde]/activité)dont chaque composant est optionnel

libellé est le nom de l’événement provoquant le changeent d’étatgarde conditionne le changementactivité est un comportement qui se déroule lors du changement

Une transition est représentée par une flèche entre deux états et portele nom de l’événement qui l’a provoqué



http://www.uvsq.fr



Activité interne

Un état peut réagir à des événements par l’intermédiaire d’activitésinternesUne activité interne est représentée par une chaîne de caractères dansun état (libellé [garde]/activité)

la signification est la même qu’une étiquette de transitionles événements entry et exit permettent de déclencher une activitélors de l’entrée, respectivement la sortie, de l’étatUn événement do précise que l’activité se déroule en continue durantl’état (état d’activité)



http://www.uvsq.fr



ExempleUn diagramme de machine à états

source : Behavioral state machine example - Bank ATM.


http://www.uml-diagrams.org/state-machine-diagrams-examples.html


http://www.uvsq.fr


Chapitre VII : Architecture de déploiement

22 Généralités

23 Diagramme de composants UML

24 Diagramme de déploiement UML

Généralités

Architecture physique

L’architecture de déploiement d’une application représente sonarchitecture physiqueElle montre l’affectation d’artefacts logiciels à des machines physiquesansi que les communication entre ces artefactsUn diagramme de déploiement UML a pour rôle de représenter cettearchitecture physiqueElle appartient à la Description de l’Architecture Logicielle de UPLe diagramme de composants quant à lui permet de représenter àgrande échelle les éléments d’un systèmeLe diagramme de composants est utilisé pour le développementorienté composants pour les architectures orientées services (SOA)



http://www.uvsq.fr



22 Généralités



Diagramme de composants UML

Composant

Un composant est une partie modulaire d’un système qui peut êtreremplacéeIl définit des interfaces fournies et requisesEn UML, il est possible de modéliser les composants avec des classeset des interfacesLa modélisation par composants a pour objectifs

de mettre l’accent sur les interfaces,d’insister sur l’aspect modulaire, autonome et remplaçable et sur laréutilisabilité.

Un composant est représenté par un rectangle avec le stéréotype« component » ou un symbole spécifiqueUne relation de dépendance est utilisée pour montrer qu’uncomposant en utilise un autre



http://www.uvsq.fr


Diagramme de composants UML

ExempleUn diagramme de composants

source : An example of component diagram for a retail website.


http://www.uml-diagrams.org/component-diagrams-examples.html


http://www.uvsq.fr



22 Généralités



Diagramme de déploiement UML

Introduction

Un diagramme de déploiement montre la répartition des composantslogiciels sur des composants physiquesUn nœud est une unité susceptible d’héberger un logiciel

un équipement est un matérielun environnement d’exécution est une plateforme d’exécution

Un nœud héberge des artefacts représentants des produits dudéveloppement (exécutables, bibliothèques, fichiers de configuration,. . . )Une voie de communication montre les nœuds communicantLe type de protocole peut être précisé comme label de la voie decommunication



http://www.uvsq.fr


Diagramme de déploiement UML

ExempleUn diagramme de déploiement

source : An example of deployment diagram for web application.


http://www.uml-diagrams.org/deployment-diagrams-examples.html


http://www.uvsq.fr


Chapitre VIII : Le langage de contraintes OCL

25 Généralités

26 Contraintes OCL

27 Types et opérateurs OCL

Généralités

exprimer des contraintes en UML

Un contrainte est une restriction sémantique sur un élément demodèle qui limite les implémentations possibles d’un systèmeUML permet d’exprimer un certains nombres de contraintesstructurelles comme les attributs, les types de relations ou la

multiplicitéde type comme les types des propriétésdiverses comme la visibilité, les classes abstraites (« abstract »)

En complément, il est aussi possible d’exprimer d’autres contraintesen langage naturel, avec un langage de programmation ou avec unlangage formelUn contrainte apparaît dans un modèle entre accolades et est placéesoit à proximité de l’élément concerné soit dans une note reliéeOCL (Object Constraint Language) est un langage formeld’expression de contraintes adapté aux modèles UML



http://www.uvsq.fr


Généralités

ExempleContraintes OCL pour une application bancaire

context Compteinv : solde > 0

context Compte :: débiter(somme : int)pre : somme > 0post : solde = solde@pre - somme

context Compteinv : banque.clients -> includes (propriétaire)

source : Exemple d’utilisation du langage de contrainte OCL sur l’exemple bancaire.


http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML023.html


http://www.uvsq.fr



25 Généralités

26 Contraintes OCL


Contraintes OCL

Contexte d’une contrainte

Le contexte d’une contrainte est l’élément de modèle concerné parcette contrainteLe contexte peut s’exprimer de deux façons

en plaçant la contrainte à proximité de l’élément entre accolades,en utilisant la syntaxe context <élément> dans un document externe.

On peut utiliser la notation :: pour qualifier le nom de l’élément



http://www.uvsq.fr


Contraintes OCL

Invariant

Un invariant exprime une condition toujours vérifiée pour un élémentLa syntaxe est inv: <prédicat>



http://www.uvsq.fr


Contraintes OCL

Précondition et postcondition

Une précondition exprime une condition qui doit être vérifiée avant unappel de méthodeLa syntaxe est pre: <prédicat>

Une postcondition exprime une condition qui doit être vérifiée aprèsun appel de méthodeLa syntaxe est post: <prédicat>Éléments particuliers utilisable dans l’expression

result est le résultat de l’opération<attribut>@pre est la valeur de l’attribut avant l’appel



http://www.uvsq.fr


Contraintes OCL

Résultat d’un opération

La contrainte body permet de spécifier une expression décrivant lerésultat d’une opérationLa syntaxe est body: <expression>

Le type de l’expression doit correspondre au type de retour del’opération



http://www.uvsq.fr


Contraintes OCL

Définition d’attribut et d’opération

La contrainte let ...in permet de définir des attributs pouvant êtreutilisés dans l’expression suivant le in

La syntaxe est let <attribut> = <expression> in<expression>

La contrainte def permet de définir des attributs ou des méthodes auniveau d’un classeurLa syntaxe est def <déclaration> = <expression>



http://www.uvsq.fr


Contraintes OCL

Initialisation et attribut calculé

La contrainte init définit la valeur d’une propriétéLa syntaxe est init: <expression>

La contrainte derive exprime la valeur d’un attribut calculéLa syntaxe est derive: <expression>

Exemplecontext Personne::marie : Booleaninit: false

context Personne::age : Integerderive: Date::current().getYear() - dateNaiss.getYear()



http://www.uvsq.fr



25 Généralités

26 Contraintes OCL


Types et opérateurs OCL

Types et opérateurs prédéfinis

OCL supporte un ensemble de types et d’opérations classiques sur cestypesLes types prédéfinis sont Boolean, Integer, Real et StringParmi les opérateurs, on trouve

pour les booléens, and, or, xor, not, implies et if ...then...else ...endifpour les entiers et les flottants, +, -, . . .pour les chaînes, concat(), size(), . . .



http://www.uvsq.fr



Type défini

Tout type défini dans un modèle UML est utilisable avec OCLPour les énumérations, la syntaxe est<TypeEnuméré>::<constante>



http://www.uvsq.fr



Collection

OCL supporte les types de collection suivantsSet ensemble au sens mathématique

Ordered Set ensemble ordonnéBag collection non ordonnée

Sequence collection ordonnée



http://www.uvsq.fr



Accès aux attributs, aux méthodes et navigation

Un attribut ou une opération est accessible par son nom ou en lepréfixant par self.

La navigation sur une relation utilise la notation « . » préfixé par lenom du rôle

Exemplesoldeself.soldeself.getSolde()self.propriétaire.nom



http://www.uvsq.fr



Opérations prédéfinies

Les opérations suivantes sont applicables à tous les objets

oclIsTypeOf(<type>) exactement le même type ?oclIsKindOf(<type>) le même type ou un dérivé ?oclInState(<state>) dans l’état donné ?oclIsNew() créé pendant l’opération ?

oclAsType(<type>) conversion de typeallInstances() retourne toutes les instances d’un type



http://www.uvsq.fr



Manipulation de collections

L’opérateur -> permet d’accéder aux caractéristiques d’une collectionQuelques opérations supportées : size(), includes(<object>),isEmpty()Quelques opérations sur les membres d’une collection

<collection>->select(<condition>) filtre la collection<collection>->forall(<condition>) et<collection>->exists(<condition>)



http://www.uvsq.fr


Chapitre IX : Notions de métamodélisation

28 Introduction

29 Métaformalisme

30 Métaformalisme et UML

31 Ingénierie dirigée par les modèles

Introduction

Qu’est-ce qu’un métamodèle ?

Un métamodèle définit les éléments utilisables dans un modèleIl précise la structure que doit avoir un modèle le respectantL’OMG utilise la notation des diagrammes de classes UML pourexprimer des métamodèlesUn métamodèle ne décrit pas (ou peu) la sémantique d’un modèleCette dernière est en général précisée en langage naturel



http://www.uvsq.fr


Introduction

Intérêt de la métamodélisation

Un métamodèle permet de décrire que qu’est un modèle valideDéfinir des traitements (transformation par exemple) au niveau dumétamodèle permet de les appliquer à un ensemble de modèles



http://www.uvsq.fr


Introduction

Modèles d’ordre supérieur

On peut imaginer créer des métamétamodèles et desméta. . . métamodèlesLa question est de savoir où se trouve la limiteLe principe consiste à faire en sorte qu’un niveau soit auto-descriptif,i.e. il se décrit lui-mêmeLa réponse de l’OMG est de définir quatre niveaux



http://www.uvsq.fr



28 Introduction

29 MétaformalismeIntroductionMOFEMF



Métaformalisme Introduction

Définition

Un métaformalisme est un modèle d’un métamodèle, i.e. unmétamétamodèleIl définit donc les concepts de base d’un métamodèle



http://www.uvsq.fr


Métaformalisme MOF

Meta Object Facility

Le Meta Object Facility (MOF) est le métaformalisme proposé parl’OMGIl est auto-descriptifIl définit les concepts de classe, relation, . . . utilisés dans lesmétamodèleC’est l’unique métaformalisme de l’OMG servant de base à tous lesmétamodèles



http://www.uvsq.fr


Métaformalisme MOF

Niveaux du MOF

L’OMG définit quatre niveaux de modélisationM0 système réelM1 modèle du système réelM2 métamodèleM3 métamétamodèle (M3) auto-descriptif



http://www.uvsq.fr


Métaformalisme MOF

ExempleLes niveaux du MOF

source : Illustration of the Meta-Object Facility.


http://en.wikipedia.org/wiki/Meta-Object_Facility


http://www.uvsq.fr


Métaformalisme MOF

Modélisation à quatre niveaux

OMG Lang. de prog. XMLM0 instances exécution données réellesM1 diag. de classes prog. données en XMLM2 MM UML grammaire schéma XMLM3 MOF EBNF XML



http://www.uvsq.fr


Métaformalisme EMF

Eclipse Modeling Framework

Le projet Eclipse EMF est une variante du MOF pour EclipseCe projet fournit une infrastructure de génération de code en sebasant sur des modèlesA partir de modèles exprimés avec XMI, il est par exemple possible degénérer des classes JavaLe niveau M3 de EMF est nommé ECore



http://www.uvsq.fr



28 Introduction

29 Métaformalisme

30 Métaformalisme et UMLMétamodèle d’UML et du MOFÉtendre UML


Métaformalisme et UML Métamodèle d’UML et du MOF

UML et le MOF

MOF 2 est le métaformalisme de l’OMG pour la description demétamodèlesUML 2 est le métamodèle dédié à la modélisation d’applications OOet basé sur le MOFUn sous-ensemble du diagramme de classe UML est utilisée pourdéfinir le MOFLa spécification UML 2 Infrastructure regroupe les définitionscommunes à UML et au MOFLa spécification UML 2 Superstructure réutilise certaines parties deUML 2 Infrastructure



http://www.uvsq.fr



UML 2 Infrastructure

La spécification UML 2 Infrastructure définit un ensemble de packagesÀ la racine, on trouve les packages InfrastructureLibrary etPrimitiveTypes

InfrastructureLibrary définit le métalangage (package Core) et desméchanismes d’extensions (package Profile)PrimitiveTypes regroupe des types de bases

Les packages peuvent être réutilisés grâce à l’opération de merge



http://www.uvsq.fr



ExempleUML 2 Infrastructure



http://www.uvsq.fr



ExempleLe package Core



http://www.uvsq.fr



ExempleDiagramme de classes défini dans Core::Basic



http://www.uvsq.fr



UML 2 Superstructure

UML 2 Superstructure définit les concepts nécessaires à l’ensembledes diagrammes UMLIl utilise l’opération de merge pour importer des packages de UML 2InfrastructureIl est découpé en de nombreux packages (Classes, Components,Deployments, . . . )



http://www.uvsq.fr



ExemplePackages de UML 2 Infrastructure fusionné dans Classes::Kernel



http://www.uvsq.fr



ExempleDiagramme de classes dans Classes::Kernel



http://www.uvsq.fr



MOF 2

MOF 2 a été décomposée en deux partiesEMOF Essential MOF décrit des métamodèles sans associationCMOF Complete MOF décrit des métamodèles avec association

EMOF intègre le package Core::Basic de UML 2 InfrastructureCMOF intègre le package Core::Construct de UML 2 Infrastructure



http://www.uvsq.fr


Métaformalisme et UML Étendre UML

Profil UML

Les concepts génériques d’UML peuvent être appliqués dans denombreux domaines (application OO, métamodèle, schéma de BD,. . . )Le problème est alors de déterminer le sens du modèleUn profil UML permet de préciser le sens de ces modèlesIl permet d’adapter dynamiquement (sans changer le métamodèle)UML à un domaine particulierUn profil UML définit un ensemble de stéréotypes qui seront ensuiteutilisés pour préciser la signaification de concepts UML



http://www.uvsq.fr



Vue d’ensemble

source : Meta Meta Models, UML and Profiles.


http://www.uml-diagrams.org/uml-meta-models.html


http://www.uvsq.fr



Diagramme de profil

Un diagramme de profil est un diagramme de structure permettant dedéfinir des stéréotypes, des mots-clés ou des contraintesUn profil utilise la notation des packages avec le mot-clé « profile »Il peut uniquement introduire des stéréotypes, des mots-clés ou descontraintes sur des métaclasses existantesUn stéréotype est représenté comme une classe avec le stéréotype« stereotype »Le lien d’extension entre un stéréotype et une métaclasse estreprésenté par une flèche continue terminée par un triangle plein(association extension)Un stéréotype peut comporter des propriétés (mots-clé)



http://www.uvsq.fr



ExempleUn profil UML pour EJB 3

source : Simplified example of unofficial Java EJB 3.0 Profile.Stéphane Lopes (UVSQ/ISTY) UML 2011-2012 191 / 197

http://www.uml-diagrams.org/profile-diagrams-examples.html


http://www.uvsq.fr



Quelques profils existants

SysML System Modeling Language pour l’ingénierie de systèmeCWM Common Warehouse Metamodel pour l’échange de

métadonnées BIUTP UML testing profile pour les tests



http://www.uvsq.fr



28 Introduction

29 Métaformalisme



Ingénierie dirigée par les modèles

Introduction

L’ingénierie dirigée par les modèles (Model-Driven Engineering ouMDE) est une approche pour le développement logiciel s’appuyant surles modèles et leurs transformationsL’approche Model-Driven Architecture (MDA) est la proposition del’OMG dans ce cadreMDA inclut plusieurs standards comme UML, MOF et XMILes objectifs de MDA sont

élaborer des modèles perennes,indépendants des détails techniques,permettre la génération automatique du code,obtenir un gain de productivité.

MDA repose sur trois modèlesCIM le modèle des exigencesPIM le modèle d’analyse et de conceptionPSM le modèle de code



http://www.uvsq.fr



CIM

Le modèle des exigences (Computation Independant Model ou CIM)spécifie les exigences du clientA partir de ces besoins, un lien de traçabilité est maintenu tout aulong du processusCe modèle ne comprend pas d’information sur la réalisation del’application ou les traitements



http://www.uvsq.fr



PIM

Le modèle d’analyse et de conception (Platform Independant Modelou PIM)Ce modèle décrit les modules et sous-modules composant l’applicationIl demeure indépendant de toute plateforme d’implémentation(JavaEE, .NET, PHP, . . . )



http://www.uvsq.fr



PSM

Le modèle de code (Platform Specific Model ou PSM) décritl’implémentation d’une application sur une plateforme techniqueIl a pour objectif de faciliter la génération de codeIl s’appuie sur les profils UML pour les plateformes.



http://www.uvsq.fr



Transformation de modèles

MDA utilise la transformation de modèles pour dériver le PIM à partirdu CIM et le PSM à partir du PIMCes transformations sont également modélisées dans MDA



http://www.uvsq.fr


uml présentation

Documents