Cours modélisation avec UML

Aller au Téléchargement

Développement de logiciel avec UML

Survol et exemples

Pascal ANDRE

MIAGE

Université de Nantes

Master Miage M1

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

Plan

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

Introduction : le contexte

Développement à objets :

- méthodes d’analyse classiques =⇒ orientation objet I programmation à objets (Smalltalk, C++, Eiffel, CLOS, Java,

C# )

Introduction : le contexte

Développement à objets :

- méthodes d’analyse classiques =⇒ orientation objet

- conception à objets = clé du développement à objet

- programmation à objets (Smalltalk, C++, Eiffel, CLOS, Java,

C# )

Introduction : le contexte

Développement à objets :

- méthodes d’analyse classiques =⇒ orientation objet  business process

- conception à objets = clé du développement à objet  encore en mutation

- programmation à objets (Smalltalk, C++, Eiffel, CLOS, Java, C# )

 classes, components, web

Introduction : le contexte

Développement à objets :

- méthodes d’analyse classiques =⇒ orientation objet  business process

- conception à objets = clé du développement à objet  encore en mutation

- programmation à objets (Smalltalk, C++, Eiffel, CLOS, Java, C# )  classes, components, web

∇ concepts et utilisation chapitre 6 [AV01b]

Introduction : le constat

Constat (fin des années 1980)

- évolution rapide des technologies (Web)

- complexité croissante des besoins et des applications

- technologies anciennes limitées pour les nouvelles applications

=⇒ migration technologique

- retour d’expérience sur la technologie à objets

- nombre pléthorique de méthodes (convergence des concepts ?)

- cacophonie pour les DSI

Introduction : le constat

Constat (fin des années 1980)

- évolution rapide des technologies (Web)

- complexité croissante des besoins et des applications

- technologies anciennes limitées pour les nouvelles applications

=⇒ migration technologique

- retour d’expérience sur la technologie à objets

- nombre pléthorique de méthodes (convergence des concepts ?) I cacophonie pour les DSI

UML et UP une réponse à un besoin urgent dans le contexte du développement à objets.

Introduction : vers un standard

Objectifs = Unifier

- langage commun : normalisation

- outils standards, modèles interopérables

- couverture GL et objet

- gestion de projet à objets

Introduction : vers un standard

Objectifs = Unifier

- langage commun : normalisation

- outils standards, modèles interopérables

- couverture GL et objet

- gestion de projet à objets

Deux approches dans la normalisation :

- plus petit dénominateur commun : CORBA/IDL

- rassembleur : UML

Introduction : état des lieux - Notation

Langage = Unified Modeling Language

- convergence, stabilisation : versions 0.8 à 2.0

- acceptation : outils et méthodes compatibles UML

- syntaxe et règles : méta-modèle et MOF

- sémantique informelle

- évolution de la notation : une base et des personnalisations

(profils)

Introduction : état des lieux - Notation

 

Introduction : état des lieux - Notation

Principales influences =

- Booch Catégories et sous-systèmes

- Embley Classes singletons et objets composites

- Fusion Description des opérations, numérotation des messages

- Gamma, et al.Frameworks, patterns, et notes

- Harel Automates (Statecharts)

- Jacobson Cas d’utilisation (use cases)

- Meyer Pré- et post-conditions

- Odell Classification dynamique, éclairage sur les événements

- OMT Associations

- Shlaer-MellorCycle de vie des objets

- Wirfs-Brock Responsabilités (CRC)

Plus récemment

- Composants (CBD)

- Architectures de logiciels (ADL)

Introduction : état des lieux - Processus

Processus = X Unified Process I convergence, stabilisation :

- principes (itératif, incrémental, architecture, UC) I uniquement des solutions propriétaires (RUP, Y ) I pratiques convergentes du développement ?

- fortement lié à l’outils

- une normalisation ? le méta-modèle SPEM

Introduction : domaine d’application

Applicable à tout développement logiciel (à objets)

- Systèmes d’information, SIG

- Systèmes temps réels, embarqués

- Interfaces, simulateurs, calcul

- Applications diverses

Couverture complète du cycle de développement.

- Analyse des besoins I

- Intégration et tests

Bibliographie sommaire

 

Editions Ellipses, 2001. ISBN 2-7298-0774-8.

  [AV03]   Pascal André and Alain Vailly.

Exercices corrigés en UML ; Passeport pour une maˆıtrise de la notation., volume 5 of Collection

 

Editions Ellipses, 2003.

ISBN 2-7298-1725-5.

Plan

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

UML : langage de spécification

- Notation complète et extensible

- Structuration des concepts

- Diagrammes

- Modèles et vues

- Multi-formalisme

- Classification

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

- la conception du logiciel : composants, modules, processus,

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

- la conception du logiciel : composants, modules, processus, I l’implantation : nœuds, liaisons, déploiement.

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

- la conception du logiciel : composants, modules, processus, I l’implantation : nœuds, liaisons, déploiement.

=⇒ décrire des modèles couvrant l’ensemble du cycle de développement.

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

- la conception du logiciel : composants, modules, processus, I l’implantation : nœuds, liaisons, déploiement.

=⇒ décrire des modèles couvrant l’ensemble du cycle de développement. I Extensible

UML : une notation complète et extensible

- Complète

UML inclut un grand nombre de concepts autour de

- l’objet : objets, classes, opérations, attributs, relations, envois de message, etc.

- l’analyse des besoins : acteurs, cas d’utilisation,

- la conception du logiciel : composants, modules, processus, I l’implantation : nœuds, liaisons, déploiement.

=⇒ décrire des modèles couvrant l’ensemble du cycle de développement.

- Extensible

UML autorise l’enrichissement ou la personnalisation de la notation au moyen des stéréotypes.

UML : structuration des concepts

- Paquetages : point de vue utilisateur

- Diagrammes : point de vue langage =⇒ la seule normalisée

- Modèles : point de vue méthode

- Vues : point de vue méthode

La notation UML : diagrammes 1/3

UML 1.x propose neuf types de combinaisons cohérentes et complémentaires : les diagrammes.

- Les diagrammes de cas d’utilisation (UC - Use Case) décrivent les acteurs et l’utilisation du système.

- Les diagrammes de classes représentent les classes et les relations statiques entre ces classes : classe, attribut, opération, visibilité, interface, association, agrégation, héritage, dépendance

- Les diagrammes d’objets (pas toujours considéré comme un diagramme) décrivent des objets et des liens. Les objets peuvent être actifs et définir leur flot de contrôle. Sur ces liens (réels ou virtuels) circulent des messages. Les envois de messages sont synchrones ou asynchrones, avec ou sans résultats.

La notation UML : diagrammes 2/3

- Les diagrammes d’objets se retrouvent sous deux formes dans UML :

- Les diagrammes de séquence, qui donnent une vision temporelle des interactions en objets en mettant l’accent sur l’ordonnancement des échanges entre objets.

- Les diagrammes de collaboration, qui donnent une vision spatiale des interactions en mettant l’accent sur les liaisons entre objets.

La notation UML : diagrammes 3/3

- Les diagrammes états-transitions modélisent le comportement des objets au cours du temps.

- Les diagrammes d’activités décrivent le flot de contrôle interne aux opérations. A grande échelle, ils représentent aussi les échanges entre objets.

- Les diagrammes de composants mettent en évidence les composants d’implémentation et leurs relations. I Les diagrammes de déploiement définissent la structure matérielle et la distribution des objets et des composants.

En plus : stéréotypes, paquetages, notes, contraintes.

La notation UML2

Une notation encore plus complète : 13 diagrammes

- Objets et de Paquetages deviennent des diagrammes à part entière

- Diagramme de collaboration devient (une fois simplifié) Diagramme de communication

La collaboration devient un élément des structures composites. I Les diagrammes de structures composites placent la hiérarchie de composition au premier plan avec une nette orientation composants et architecture de logiciels (ADL). I

La notation UML2 (suite)

I

- Les diagrammes d’interaction sont un mélange d’activités et de séquence.

- Les diagrammes de temps (timing) permettent la description d’évolution temporelle usuelle en génie électrique.

Par ailleurs, les diagrammes d’activités sont fortement enrichis pour inclure les DFD.

Aper¸cu de la notation UML

- Principaux concepts pour chaque diagramme

- Exemples

- Pas de considération métamodèle

- concepts communs (stéréotypes, relations, notes, paquetages, sous-systèmes )

- factorisations ”sémantiques” car ils évoluent en permanence.

Par exemple les stéréotypes sont fortement associés aux profils en UML 2.0 (mots-clés), les paquetages deviennent un diagramme en UML 2.0.

- Principalement les notations UML 1.x I Ne pas oublier les actions et OCL.

Aper¸cu de la notation UML

1. Modèles d’approche

2. Modèles de structure

3. Modèles de la dynamique

4. Modèles des traitements fonctionnels

Modèles d’approche

1. cas d’utilisation

2. scénarios

3. accessoirement : activités

Modèles d’approche : cas d’utilisation 1/8

Définitions [Gro03] :

- A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system (subsystem, class) and one or more outside interactors (called actors) together with actions performed by the system (subsystem, class).[Gro03]

- An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor may be considered to play a separate role with regard to each use case with which it communicates.

- An extension point is a reference to one location within a use case at which action sequences from other use cases may be inserted. Each extension point has a unique name within a use case, and a description of the location within the behavior of the use case.

Modèles d’approche : cas d’utilisation 2/8

 

Modèles d’approche : cas d’utilisation 3/8

Relations :

- Association - The participation of an actor in a use case; that is, instances of the actor and instances of the use case communicate with each other. This is the only relationship between actors and use cases.

- Extend - An extend relationship from use case A to use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B, which is referenced by the extend relationship.

- Generalization - A generalization from use case C to use case D indicates that C is a specialization of D.

- Include - An include relationship from use case E to use case F indicates that an instance of the use case E will also contain the behavior as specified by F. The behavior is included at the location which defined in E.

Modèles d’approche : cas d’utilisation 4/8

 

Figure 1 : Cas d’utilisation, version à relations - Salles

Modèles d’approche : cas d’utilisation 5/8

 

Figure 2 : Cas d’utilisation, version à contexte - Salles

Modèles d’approche : cas d’utilisation 6/8

 

Figure 3 : Cas d’utilisation, extensions

Modèles d’approche : cas d’utilisation 7/8

Points clés du diagramme des cas d’utilisation

- Abstrait

- Granularité : entre découpage fonctionnel et modulaire

- Lisibilité

- Description textuelle

Modèles d’approche : cas d’utilisation 8/8

Modèles d’approche : cas d’utilisation 8/8 (suite)

Modèles d’approche

1. cas d’utilisation

2. scénarios

3. accessoirement : activités

Modèles d’approche : scénarios 1/3

diagramme de séquence simplifié

- voir diagramme de séquence

- objets (acteurs + système)

- envoi de message (paramètres )

- commentaires

Modèles d’approche : scénarios 2/3

vérification d'existence(dem)

client existant

recherche des paramètres

vérification de cohérence du planning

enregistrement de la réservation

Figure 4 : Scénario normal de l’ajout d’une réservation - Salles

Modèles d’approche : scénarios 3/3

 

Modèles d’approche

1. cas d’utilisation

2. scénarios

3. accessoirement : activités

Modèles d’approche : activité étendue 1/2

diagramme d’activité étendu

- voir diagramme d’activité

- activités, actions

- structures de contrôle

- envoi/réception de message ou signaux (paramètres )

- flots et synchronisations

- couloirs (noms, objets, rôles )

 

Aper¸cu de la notation UML

1. Modèles d’approche

2. Modèles de structure

3. Modèles de la dynamique

4. Modèles des traitements fonctionnels

Modèles de structure

1. collaborations

2. classes

3. composants

4. déploiement

Modèles de structure : collaborations 1/6

diagramme d’objet avec messages

- objets et liens, multi-objets, objet actif, instance

- envoi de message (numérotation hiérarchique, paramètres ) I structures de contrôle, synchronisation

UML 2.0 =⇒ diagramme de communication tandis que la

collaboration fait partie des structures composites

UML 2.0 =⇒ diagramme de communication : pas de gardes et d’itération

Modèles de structure : collaborations 2/6

 

Modèles de structure : collaborations 3/6

 

Modèles de structure : collaborations 4/6

 

Figure 6 : Diagramme de collaboration, synchronisation - Club vidéo

Modèles de structure : collaborations 5/6

 

Modèles de structure

1. collaborations

2. classes

3. composants

4. déploiement

Modèles de structure : classes 1/9

diagramme de classes = la référence en UML et dans le MOF (!)

- E-A-P : classes, propriétés (attributs, opérations)

- associations, agrégation, composition,

- propriétés dérivées, classes-associations, qualification

- généralisation/spécialisation, généricité

- classes abstraites, interfaces, héritage multiple

UML 2.0 =⇒ classes orientée composant (ports, interfaces requises, offertes ) + structures composites

UML 2.0 =⇒ composant hérite de classes

Modèles de structure : classes 2/9

 

Figure 7 : Représentations de classes

Modèles de structure : classes 3/9

 

Figure 8 : Diagramme de classes du domaine - Salles

Modèles de structure : classes 4/9

 

Figure 9 : Diagramme des classes, association qualifiée

Modèles de structure : classes 5/9

 

Figure 10 : Diagramme des classes, contraintes

Modèles de structure : classes 6/9

 

Figure 11 : Diagramme des classes, classe-association

Modèles de structure : classes 7/9

 

Figure 12 : Diagramme de classes, abstraction des tables de tarifs - Salles

Modèles de structure : classes 8/9

Figure 13 : Diagramme des classes, héritage et discriminant

Modèles de structure : classes 9/9

 

Figure 14 : Diagramme des classes, héritage et délégation

Modèles de structure

1. collaborations

2. classes

3. composants

4. déploiement

Modèles de structure : composants 1/3

diagramme de composants = vague en UML 1.x

- artifacts de programmation (très vaste)

- architecture du logiciel

- UML 1.x

- composants, processus, applications, bibliothèques

- dépendances

- interfaces, couches

UML 2.0 =⇒ composant de programmation (ports, interfaces requises, offertes ) + structures composites

Modèles de structure : composants 2/3

 

Figure 15 : Diagramme de composants notation étendue

Modèles de structure : composants 3/3

 

Figure 16 : Diagramme de composants partiel - Club vidéo

Modèles de structure

1. collaborations

2. classes

3. composants

4. déploiement

Modèles de structure : déploiement 1/3

diagramme de déploiement =

- architecture physique

- répartition des composants sur les nœuds physiques (processeurs)

- UML 1.x

- répartition des composants sur les nœuds physiques I liaisons =⇒ réseaux

UML 2.0 =⇒ artefacts et non plus composants sur les nœuds

Modèles de structure : déploiement 2/2

 

Aper¸cu de la notation UML

1. Modèles d’approche

2. Modèles de structure

3. Modèles de la dynamique

4. Modèles des traitements fonctionnels

Modèles de la dynamique

1. séquences

2. états-transitions

3. activités

Modèles de la dynamique : séquences 1/5

diagramme de séquences = évolution temporelle des échanges dans une collaboration (MSC)

- vue temporelle des diagrammes de collaboration I objets, envoi de message (numérotation implicite, paramètres ), signaux

- retour, envoi asynchrone, création/suppression d’objets I structures de contrôle, flots parallèles, synchronisation, contraintes temporelles

UML 2.0 =⇒ ajout des ”frames” (structures de contrôle et

références), sources indéterminées, timing

UML 2.0 =⇒ pas de gardes et d’itération, sync/async

 

Modèles de la dynamique : séquences 3/5

   : F. Gestion de  : Ens.    : Ens. Type  : Ens. Salle    : Salle

nouvelleSalle( )

Modèles de la dynamique : séquences 4/5

{b.t_récep - a.t_émis < 1 sec}

{c.t_récep - b.t_émis < 10 sec}

L'appel est routé dans le réseau.

{d.t_récep - d.t_émis < 5 sec}

La communication est

établie

Modèles de la dynamique : séquences 5/5

asynchrone

  non spécifié synchrone   retour

  UML 1.x  

 

Modèles de la dynamique

1. séquences

2. états-transitions

3. activités

Modèles de la dynamique : E-T 1/5

diagramme états-transitions = comportement dynamique des objets (statecharts)

- automates hiérarchiques

- états, transitions, événements, gardes

- actions, activités, opérations

- hiérarchisation (superstate, composite)

- pseudo-états (H*, synchro, jonctions, souches )

UML 2.0 =⇒ machines à états behavior statemachine, protocol statemachine

UML 2.0 =⇒ héritage, points d’E/S et abandon, activités et activité-do

Modèles de la dynamique : E-T 2/5

 

Modèles de la dynamique : E-T 3/5

 

Figure 18 : Diagramme états-transitions d’un objet PosteAbonné

 

Modèles de la dynamique : E-T 5/5

 

Modèles de la dynamique

1. séquences

2. états-transitions

3. activités

Modèles de la dynamique : activités 1/4

diagramme d’activité

- activités, actions états-transitions

- structures de contrôle

- envoi/réception de message ou signaux (paramètres )

- flots et synchronisations

- extension : couloirs (noms, objets, rôles )

++ voir sémantique des actions Action Semantics dans UML 1.5

Modèles de la dynamique : activités 2/4

diagramme d’activité (suite)

UML 2.0 =⇒ enrichi des DFD business process

- couloirs bidimensionnels (groupage de postes)

- conditions et jetons (MCT, Petri, Grafcet)

- signaux temporels

- débranchements, jonctions, décisions, fusions, terminaisons de flots

- arcs et flots

- connecteurs, régions d’expansion

   

Modèles de la dynamique UML 2.0

1. séquences

2. états-transitions

3. activités

4. interactions (séquences + activités) ??

5. timing

Aper¸cu de la notation UML

1. Modèles d’approche

2. Modèles de structure

3. Modèles de la dynamique

4. Modèles des traitements fonctionnels

Modèles des traitements fonctionnels

1. déclaratif : OCL

2. opérationnel : activités + actions

^I diagrammes d’activités (et états-transitions)

^I opérations

^I diagrammes d’activités étendus

3. Action Semantics =⇒ développer

4. Activités UML2 : DFD + DA

^I conditions et jetons (MCT, Petri, Grafcet)

^I signaux temporels

^I débranchements, jonctions, décisions, fusions, terminaisons de flots

^I arcs et flots

^I connecteurs, régions d’expansion

La notation UML : modèles et vues

Les diagrammes décrivent des aspects complémentaires mais non disjoints du système.

Un modèle est un ensemble de diagrammes et de documents. I Modèle des besoins, d’analyse, de conception, de réalisation, d’implantation, de déploiement, de test

- Modèle statique, modèle dynamique, modèle fonctionnel I Modèle de type, modèle d’instances I Méta-modèle I etc.

Les vues sont des aspects des modèles. Les modèles ne dépendent pas de la notation mais de la méthode de développement.

La notation UML : multi-formalisme

Les relations entre diagrammes sont de plusieurs types :

- multi-aspect : classes, états-transitions, activités

- type/instance : classes et objets, UC et scénarios

- abstraction : classes et composant, classes d’analyse et classe d’implantation

- complémentaires : classes et UC

- chevauchement : séquences et collaborations, activités et états-transitions

Les concepts et notations sont variés : l’objet assure la cohésion sémantique.

La notation UML : classification

Les concepts (et diagrammes) peuvent être classés selon plusieurs axes :

- activité de développement : besoins, analyse, conception, réalisation I abstraction : méta-type/type/instance : définitions, exemplaires

- aspect du système : statique, dynamique, fonctionnel I degré de formalisme : cas d’utilisation, classe,

états-transition

Chaque axe reprend une préoccupation des acteurs du développement (méthodologiste, analyste, utilisateur, développeur ).

La notation UML : en résumé

UML est un langage complet mais complexe.

Contrairement à UML 1.x, dans UML 2.0 la sémantique est plus modulaire mais le recouvrement des diagrammes interdit toute sémantique commune.

UML : Esperanto ou Babel ?

Avec un langage

- complexe

- à géométrie variable (sémantique)

- éléments combinables à souhait

UML : Esperanto ou Babel ?

Avec un langage

- complexe

- à géométrie variable (sémantique)

- éléments combinables à souhait

Peut-on écrire des spécifications de qualité ?

- cohérentes

- complètes I lisibles et exploitables I etc.

UML : complexité d’usage

- L’interprétation varie avec le contexte : exemple des diagrammes d’activités I Le contenu varie avec le niveau d’abstraction : exemple des classes en analyse et en implantation, I Dans un modèle, on trouve des préoccupations différentes :

utilisation, classes, objets, composants I L’usage varie avec la méthode de développement :

méthode itérative =⇒ degré de précision.

On fait abstraction des besoins non fonctionnels.

UML : Esperanto ou Babel ?

Chacun a sa sémantique d’UML en fonction de son expérience, des langages et environnements de développement utilisés, des applications développées, des besoins requis.

UML : Esperanto ou Babel ?

Chacun a sa sémantique d’UML en fonction de son expérience, des langages et environnements de développement utilisés, des applications développées, des besoins requis.

UML : Esperanto ou Babel ?

Chacun a sa sémantique d’UML en fonction de son expérience, des langages et environnements de développement utilisés, des applications développées, des besoins requis. C’est encore plus vrai avec UML2

Problème :

de nombreuses modélisations erronées, incohérentes, incomplètes

UML : Esperanto ou Babel ?

Chacun a sa sémantique d’UML en fonction de son expérience, des langages et environnements de développement utilisés, des applications développées, des besoins requis. C’est encore plus vrai avec UML2

Problème :

de nombreuses modélisations erronées, incohérentes, incomplètes

Solutions :

- Gérer la complexité

- Proposer un compilateur (ou un interpréteur) I Proposer un correcteur I Autres solutions

UML : gérer la complexité

1. Grouper les diagrammes par activité :

- modèles d’approche (UC, scénarios, activités)

- modèles logiques (classes, E-T, activités, séquences, collaborations)

- modèles d’implantation (composants, déploiement, classes, collaborations)

UML : gérer la complexité

1. Grouper les diagrammes par activité :

- modèles d’approche (UC, scénarios, activités)

- modèles logiques (classes, E-T, activités, séquences, collaborations)

- modèles d’implantation (composants, déploiement, classes, collaborations)

2. Limiter l’usage des diagrammes par activité.

UML : gérer la complexité

1. Grouper les diagrammes par activité :

- modèles d’approche (UC, scénarios, activités)

- modèles logiques (classes, E-T, activités, séquences, collaborations)

- modèles d’implantation (composants, déploiement, classes, collaborations)

2. Limiter l’usage des diagrammes par activité.

3. Grouper les diagrammes par type Instanciation :

scénario −→ UC / séquence, collab. −→ Classe, E-T, activités

UML : gérer la complexité

1. Grouper les diagrammes par activité :

- modèles d’approche (UC, scénarios, activités)

- modèles logiques (classes, E-T, activités, séquences, collaborations)

- modèles d’implantation (composants, déploiement, classes, collaborations)

2. Limiter l’usage des diagrammes par activité.

3. Grouper les diagrammes par type Instanciation : scénario −→ UC / séquence, collab. −→ Classe, E-T, activités

4. Associer les diagrammes complémentaires :

E-T ↔ activité, E-T ↔ classe, opération ↔ activité, composant ↔ déploiement

UML : proposer un compilateur

- Aspects syntaxiques : le méta-modèle

- problème de classification des concepts

- pas de grammaire complète

- mais un jeu de règle de vérifications (complet ? cohérent ?)

UML : proposer un compilateur

- Aspects syntaxiques : le méta-modèle

- problème de classification des concepts

- pas de grammaire complète

- mais un jeu de règle de vérifications (complet ? cohérent ?)

- Aspects sémantiques : langage naturel

=⇒ pas satisfaisant

- des travaux en cours

- multi-formalisme

UML : proposer un compilateur

- Aspects syntaxiques : le méta-modèle

- problème de classification des concepts

- pas de grammaire complète

- mais un jeu de règle de vérifications (complet ? cohérent ?)

- Aspects sémantiques : langage naturel

=⇒ pas satisfaisant

- des travaux en cours

- multi-formalisme

- Executable UML

- traduction complète (sémantique opérationnelle)

- génération de code par le compilateur

- extraction pour les spécifications formelles

UML : proposer un correcteur

- Objectifs limités : vérifier des propriétés

- de systèmes : redondances, non-blocage

- de modèles : cohérence, complétude

- de processus : équivalences, trac¸abilité

UML : proposer un correcteur

- Objectifs limités : vérifier des propriétés

- de systèmes : redondances, non-blocage

- de modèles : cohérence, complétude

- de processus : équivalences, trac¸abilité

- Evolutif

- le correcteur s’adapte au compilateur

- le correcteur s’intègre dans différents outils

- la base de règles est incrémentale, paramétrable

UML : proposer un correcteur

- Objectifs limités : vérifier des propriétés

- de systèmes : redondances, non-blocage

- de modèles : cohérence, complétude

- de processus : équivalences, trac¸abilité

- Evolutif

- le correcteur s’adapte au compilateur

- le correcteur s’intègre dans différents outils

- la base de règles est incrémentale, paramétrable

- Rigoureux

- formaliser les règles (OCL, spec. formelles)

- vérifier la base de règles (cohérence )

UML : proposer un correcteur

- Objectifs limités : vérifier des propriétés

- de systèmes : redondances, non-blocage

- de modèles : cohérence, complétude

- de processus : équivalences, trac¸abilité

- Evolutif

- le correcteur s’adapte au compilateur

- le correcteur s’intègre dans différents outils

- la base de règles est incrémentale, paramétrable

- Rigoureux

- formaliser les règles (OCL, spec. formelles)

- vérifier la base de règles (cohérence )

- Automatisable, génération de test

Plan

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

Object Constraint Language

Eléments clés

- Langage à objets déclaratifs (relativement) formel

- Inspiré de Syntropy (et donc de Z)

- Typage

- Navigation

- Assertions et contraintes

- Méta Object Protocol

Object Constraint Language

Détails dans le chapitre 9 [AV01]

- Types de base et MOP =⇒ section 2

Object Constraint Language

Détails dans le chapitre 9 [AV01]

- Types de base et MOP =⇒ section 2

- Navigation =⇒ section 3.2

Object Constraint Language

Détails dans le chapitre 9 [AV01]

- Types de base et MOP =⇒ section 2

- Navigation =⇒ section 3.2

- Assertions =⇒ section 3.1, 3.3

OCL : Types 1/7

- OclAny

- Types de base

- Types énumérés enum {v1, v2, v3, v4} #v2.

- Collections

- Types UML (classes, associations, état )

- Types OCL-MOP (réflexion, typage)

OCL : Types 2/7 : Collection

OCL : Types 3/7 : Set

OCL : Types 4/7 : Bag

OCL : Types 5/7 : Sequence

OCL : Système de Types 6/7

- Types UML

^I Classes, Etat,

^I Propriétés (attribut, opération, roˆles)

^I Associations (qualification, classes, collections )

- Type OclAny

^I =, <>

^I OclAsType : transtypage (accès propriété)

^I OclIsTypeOf : test de supertype direct

^I OclIsKindOf : test de supertype

^I OclIsNew : objet créé (dans postcondition) ^I OclIsInState : test d’état OclState

- OclType : tout type OCL

^I name, attributes, operations, associationEnds

^I supertypes, allSupertypes

^I allInstances

- OclExpression : expressions d’OCL

OCL : Types 7/7 : Conformité

OCL : Navigation

- Propriétés (attribut, opération, rôles associationEnd)

- Rôles par défaut

- Notation pointée

- Raccourcis et transitivité

- Cardinalités =⇒ collections

- Exemples

 

OCL : Pratique 1/5

- Expression OCL

- rattachée à un élément de modélisation quelconque

- gardes

- contraintes

- propriété dérivée

- Assertion

- Invariant de classe

- Pré-post condition

- Invariant de système

- Déclaration locale (let in)

Contexte - la variable self

OCL : Pratique 2/5 : Invariant de classe

context Etudiant inv binoˆme: self .binoˆme <>self −− pas de monoˆme, implicite par agrégation

inv âge:

  self .âge ≥ 14   −− les étudiants ont au moins 14 ans

formation = #continue implies âge ≥ 25

−− les étudiants de formation continue ont plus de 25 ans inv durées:

−− l’attribut duréeAutoris donne le nombre maximum jour

−− de prêts pour cet étudiant (crédit maximum) if self . assiste à →isEmpty then duréeAutoris = 0

else if self . assiste à .niveau = #DESS then duréeAutoris = 30

else

duréeAutoris = 20 endif

endif

OCL : Pratique 3/5 : Opération

context Exemplaire::emprunter(date e : Date ; date r : Date ;

étud : Etudiant) : Boolean

pre: self .emprunt→isEmpty and −− disponible date e ≤ date r and −− cohérence des dates

étud.emprunt→size < 3 and −− n’a pas 3 emprunts en cours date r ≤ (date e + ééeAutoris)

−− l’étudiant est autorisé pour cette durée

post:  −− let introduit une variable quantifiée existentiellement let emp : Emprunt in

e = date e and r = date r and

self .emprunt = emp and

étud.emprunt = étud.emprunt@pre→including(emp) and emp.étudiant = étud and emp.exemplaire = self and

result = true

{query} / {abstract} / {concurrency = sequential,

Développement de logiciel avec UML

guarded, concurrent}

OCL : Pratique 4/5 : dérivé / Association

Propriété dérivée

context Etudiant inv nb emprunts:

(nb emp = self.emprunt→size) and (nb emp ≤ 3)

−− le nombre d’emprunts est le cardinal de l’ensemble des emprunts Association

context Exemplaire

( self .emprunt→isEmpty) or (self . réservé→isEmpty)

−− exclusion du prêt d’ouvrages réservés context Etudiant not ( self . inscrit en →isEmpty and self .diploˆmé de→isEmpty)

−− contrainte de totalité (a or b) ¡=¿ not(not a and not b)

−− contexte global diploˆmés. allInstances →excludesAll( inscription . allInstances )

−− xor : les étudiants inscrits à un diploˆme n’en sont pas diplômés inscription . allInstances → includesAll (promotion. allInstances ) −− subset : les étudiants de la promotion d’un diploˆme y sont inscrits

Développement de logiciel avec UML

−− par transitivité, les étudiants de la promotion d’un diploˆme

OCL : Pratique 5/5 (héritage 1/2)

Prédéfini

- exclusion

- overlapping : autorise l’héritage multiple I disjoint : interdit l’héritage multiple

- totalité

- complete : il n’y a pas d’autres sous-classes.

- incomplete : d’autres sous-classes n’ont pas été définies.

- un discriminant définit une vue partielle sur l’héritage.

Employé. allInstances → forAll ( i | not i .oclIsTypeOf(TempsComplet))

OCL : Pratique 5/5 (héritage 2/2)

 

OCL : Redéfinitions

 

Plan

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

UML : méthode

Version simplifiée du processus : 4 activités dans le développement Présentation de la notation utilisée dans les activités.

1. Analyse des besoins : cas d’utilisation et scénarios

2. Analyse : diagrammes d’objets et de classes, états-transitions

3. Conception : classes, composants et déploiement

4. Implantation : composants et déploiement

UML : méthode

1. Analyse des besoins : cas d’utilisation et scénarios

2. Analyse : diagrammes d’objets et de classes, états-transitions

3. Conception : classes, composants et déploiement

4. Implantation : composants et déploiement

Analyse des besoins : aper¸cu

Requirements

- comprendre le contexte du système

- modèle du domaine I modèle du métier

- définir les besoins

- fonctionnels =⇒ Cas d’utilisation, scénarios

- non fonctionnels contraintes matérielles, d’interface, de performance sécurité, disponibilité, accessibilité, qualité

Analyse des besoins : modèles

- diagrammes de cas d’utilisation

- acteurs

- cas d’utilisation

- relations

- par cas d’utilisation

- descriptions textuelles

- illustration : scénarios

^I objets : acteurs, système

^I interactions : séquences

Analyse des besoins : cas d’utilisation 1/5

 

Analyse des besoins : cas d’utilisation 2/5

 

Figure 20 : Cas d’utilisation, version préliminaire - Salles

Analyse des besoins : cas d’utilisation 3/5

 

Figure 21 : Cas d’utilisation, version préliminaire - Salles

Analyse des besoins : cas d’utilisation 4/5

Points clés du diagramme des cas d’utilisation

- Abstrait

- Granularité : entre découpage fonctionnel et modulaire

- Lisibilité

- Description textuelle

Analyse des besoins : cas d’utilisation 5/5

Analyse des besoins : scénarios 1/2

- objectif : illustrer les cas d’utilisation (représentativité)

- un par cas normal

- un par exception

- notation : diagramme de séquence simplifié

- objets (acteurs + système)

- envoi de message (paramètres )

- potentiellement un diagramme d’activité (business model)

Analyse des besoins : scénarios 2/2

 

Analyse des besoins : activités 1/2

- objectif : décomposer des tâches complexes (business process)

- en sous-tâches

- par secteur

- notation : diagramme d’activités étendues par des couloirs

Analyse des besoins : activité 2/2

 

Analyse des besoins : bilan

- description des besoins

- besoins fonctionnels

- besoins non fonctionnels I en option :

^I modèle du domaine

^I modèle du métier

^I glossaires, IHM, prototype

- description validée par l’utilisateur

- support pour les tests

= point de départ de l’analyse

UML : méthode

1. Analyse des besoins : cas d’utilisation et scénarios

2. Analyse : diagrammes d’objets et de classes, états-transitions

3. Conception : classes, composants et déploiement

4. Implantation : composants et déploiement

Analyse : aper¸cu

Analysis

- décrire le système indépendemment de son implantation

- affiner l’analyse des besoins

- décrire la prise en compte des besoins par le système

- décrire l’architecture du système

- modélisation à objets

- structuration en sous-systèmes

Analyse : modèles

- diagrammes d’objets

- acteurs, objets

- séquences

- collaborations

- diagrammes de classes

- classes

- relations

- enrichissements

- diagrammes états-transitions et diagrammes d’activités

Analyse : notations (collaboration)

 

Analyse : notations (séquence)

 

Analyse : notations (séquence)

   : F. Gestion de    : Ens.  : Ens. Type    : Ens. Salle  : Salle

nouvelleSalle( )

Analyse : notations (classes)

 

Analyse : notations (classes)

 

Analyse : notations (classes)

 

Figure 22 : Diagramme des classes, association qualifiée

Analyse : notations (opération OCL)

context Salle :: créerSalle (bat, noEtage, noSalle , superficie , type) : Salle

pre:

−− le bâtiment et la salle existent

Bâtiment. allInstances →includes(bat) and

Type. allInstances →includes(type) post:

−− soit sal l’objet créé let sal : Salle in

Salle . allInstances@pre →excludes(sal) and sal .no étage = noEtage and sal. no salle = noSalle and sal .no bat = bat and sal . superficie = superficie and sal . typeSalle = type and sal.bâtiment = bat and

−− ajout explicite dans l’ensemble des instances

Salle . allInstances = Salle. allInstances@pre →including(sal) result = sal

Analyse : notations (statecharts)

 

raccroche / self.commutateur. raccrocher(self)   PosteAbonné

 

Analyse : notations (activités)

 

Analyse : processus

- Point de départ : analyse des besoins

- Architecture : structuration du système

- Objets Métiers/Interface/Contrôle/Utilitaires : on groupe les classes par nature.

- Héritage/Association/Instanciation : on groupe les classes par type de relation.

- Organisation logique e.g.

Achat/Finance/Approvisionnement/Statistiques.

- Répartition géographique ou d’application (architecture C/S n-tier).

vue en couches

UML : méthode

1. Analyse des besoins : cas d’utilisation et scénarios

2. Analyse : diagrammes d’objets et de classes, états-transitions

3. Conception : classes, composants et déploiement

4. Implantation : composants et déploiement

Conception : aperc¸u

Design

- décrire le système dans le contexte de son implantation

- affiner l’analyse

- décrire la prise en compte des aspects logiciels : persistence, concurrence, sécurité

- décrire l’architecture logicielle et matérielle du système

- modélisation à objets ou composants

- structuration en sous-systèmes, en couches

Conception : modèles

- diagrammes de composants

- composants, processus, applications, bibliothèques

- dépendances

- interfaces, couches

- diagrammes de déploiement

- nœuds et répartition

- liaisons et protocoles

- diagrammes de classes

- diagrammes Etats-transitions et Activités

Conception : notations (composants)

 

Figure 23 : Diagramme de composants partiel - Club vidéo

Conception : notations (déploiement)

 

UML : méthode

1. Introduction

2. Analyse des besoins : cas d’utilisation et scénarios

3. Analyse : diagrammes d’objets et de classes, états-transitions

4. Conception : classes, composants et déploiement

5. Implantation : composants et déploiement

Implantation : aper¸cu

Implementation

- coder la conception

- implanter les algorithmes

- implanter les couches logicielles

- implanter les aspects systèmes, BD, sécurité

- modélisation à objets ou composants

- déploiement

Implantation : modèles

- diagrammes de composants

- composants, processus, applications, bibliothèques

- dépendances

- interfaces, couches

- diagrammes de déploiement

- nœuds et répartition

- liaisons et protocoles

- diagrammes de classes ?

- diagrammes états-transitions et diagrammes d’activités ?

Implantation : notations

- voir conception

- fichiers, bibliothèques, pages web, composants

- documentation de programmation

Implantation : processus

=⇒ lié aux techniques de programmation, aux support technique (frameworks) et à l’environnement de développement

Plan

Introduction

UML : un langage de spécification multi-formalisme

UML : précision avec OCL

UML : une méthode de développement

UML : un processus unifié

UML : outils et vérification

Perspectives

Processus unifié : généralités

Retour sur le développement du logiciel (tome 1, p. 9)

Méthode

- Philosophie = objet I Formalisme = UML

- Démarche = processus unifié (?) ⇐=

- Outils = à suivre ⇓

UML/processus : généralités

qui fait quoi et comment

UML/processus : généralités

qui fait quoi et comment

Quatre approches :

- Méthodes classiques

- de l’analyse aux tests d’intégration

- cycle linéaire, en cascade, en V

- restriction ou pas des diagrammes à chaque niveau

- exemple simple : [AV01b]

UML/processus : généralités

qui fait quoi et comment

Quatre approches : I Méthodes classiques

- Processus unifié (RUP, 2TUP)

- élabore le modèle final par enrichissement progressifs du modèle d’analyse,

- basée sur une notation unique (UML),

- support d’un processus itératif et incrémental, centré sur l’architecture et les cas d’utilisation,

- concepteurs d’UML

UML/processus : généralités

qui fait quoi et comment

Quatre approches :

- Méthodes classiques

- Processus unifié (RUP, 2TUP)

- MDA - Model Driven Approach

- élabore le modèle final par transformations successives de modèles

- les modèles indépendants des plates-formes (PIM) sont transformés des modèles dépendants des plates-formes (PSM) I proposé par l’OMG

UML/processus : généralités qui fait quoi et comment

Quatre approches :

- Méthodes classiques

- Processus unifié (RUP, 2TUP)

- MDA - Model Driven Approach

- méthodes “agiles” (Scrum, XP, Lean, Puma )

- validation rapide : donne la part belle aux programmeurs et aux clients, PDD

- principes de bonne pratique de la programmation à objets

(TDD, pair prog, )

- souple, évolutif, cycles courts (sprints Scrum), kanbans

- adapté aux petites applications et structures (réactifs)

UML/processus : généralités

qui fait quoi et comment

Quatre approches :

- Méthodes classiques

- Processus unifié (RUP, 2TUP)

- MDA - Model Driven Approach

- méthodes “agiles” (Scrum, XP, Lean, Puma )

D’autres sociétés proposent d’autres méthodes : OPEN, Objecteering/Softeam, Rhapsody/I-Logix, Catalysis/ICON Computing, Together/Borland, etc.

Processus unifié : aper¸cu

Pas de processus unifié

- Rational Unified Process

- Two Track Unified Process (2TUP)

- Scrum, Puma (Lean, XP)

- etc

Processus unifié : aper¸cu

Pas de processus unifié

- Rational Unified Process

- Two Track Unified Process (2TUP)

- Scrum, Puma (Lean, XP) I etc

Mais des principes communs

UML/processus : Unified Process

- Itératif

- Incrémental

- Architecture

- Cas d’utilisation

Préoccupations du développement et de la gestion de projet

RUP : architecture 1/2

Deux axes

- Activités

- développement (analyse des besoins =⇒ test)

=⇒ développement du logiciel (tome 1, p. 13) un modèle produit par activité (cf les domaines)

- support

^I Gestion de configuration & versions

^I Gestion de projet (organisation, risques, planification)

^I Environnement (support et méthode)

- Itérations

- Grain fin : itération

- Gros grain : phases

RUP : architecture 2/2

Coordination des deux axes

 

Effort de développement

Entrelacement des activités de développement et de support dans chaque itération.

Processus unifié : itérations et phases

- chaque itération produit une version du système : un jalon mineur

Processus unifié : itérations et phases

- chaque itération produit une version du système : un jalon mineur I les phases définissent les grandes étapes du développement : les jalons majeurs, qui contrôlent ainsi le nombre d’itérations

Processus unifié : itérations et phases

- chaque itération produit une version du système : un jalon mineur I les phases définissent les grandes étapes du développement : les jalons majeurs, qui contrôlent ainsi le nombre d’itérations

- préparation (inception) :

Etablir la faisabilité et le contexte du projet

Résultat : Lifecycle objectives