Virtualité Réelle thierry.leydier@gmail · Tour d ’horizon rapide des diagrammes UML ......

UML

Virtualité Ré[email protected]

Historique des approches : les ancêtres

Pour parer aux difficultés du logiciel, les méthodes en Génie Logiciel sont nombreuses depuis les années 80

Des méthodes précises mais trop limitées, très orientées production de logiciel ou programmation

Parmi les méthodes les plus connues :

1985 : Booch Object Oriented Design (OOD)

1986 : Seidewitz - Stark (NASA) General Object-Oriented design (GOOD)

1987 : CISI - CRI - MATRA (ESA) Hierarchical Object-Oriented Design (HOOD)

1988 : Kerth Multiple-View Object-Oriented Design Methodology (MOOD)

1988 : Jacobsen ObjectOry

1989 : Wasserman Object-Oriented Structured Design (OOSD)

Des méthodes ou des formalismes de plus en plus complets

Durant les années 90, on voit apparaître des méthodes plus complètes, et plus orientées analyse des problèmes

3 méthodes émergent: OMT : J Rumbaugh

OMT 1 (91), OMT 2 (93) formalisme graphique vue fonctionnelle

BOOCH approche méthodologique approfondie 91, 93

OOSE : Jacobson Vue des cas de fonctionnement

En 1996, les 3 méthodes précédentes sont unifiées dans une seule : UML UML devient ainsi un outil de modélisation complet et universel 1997 : Normalisation d’UML (1.0) et Création d’un groupe de prescripteurs (

OMG) Aujourd’hui UML Version 2

Les traits d ’UML

Les traits d ’UML

UML est un langage pas une simple notation

un vrai langage de modélisation

la définition d ’UML est formelle et normalisée

UML n ’est pas une méthode en soi Méthode implicite adossée issue des technologies objets

Conception ascendante

UML ne définit pas un processus Processus implicites issus des technologies objets

cycle en spirale, cycles itératifs

Complément à UML : Unified process défini par l ’OMG

UML est extensible

UML = ensemble

Plus un agglomérat qu’un ensemble homogène

La création d ’UML a pour objectif de rassembler un ensemble de modèle sans vrai volonté de trier ou filtrer

Homogénéité de notation, de documentation

Hétérogénéité

plusieurs notations possibles pour décrire les mêmes concepts

plusieurs diagrammes possibles pour la même idée

Par exemple, la modélisation d ’une séquence d ’actions peut être effectuée de différentes façons

Difficulté :

Comment utiliser cet agglomérat ?

UML = Offre industrielle

UML est difficilement contournable en matière de modélisation

UML est utilisé ou prescrit par les grands industriels

De nombreux outils existent

plus ou moins complets

plus ou moins intégrés à des environnement de développement de logiciels

cibles standard C++ et JAVA

différents objectifs

outils à destination de programmeurs

outils à destination d ’analystes

ouverture à d ’autres métiers

Les éléments généraux d ’UML

Les constituants

UML est composé :

d ’éléments de base du modèle

les atomes de la modélisation

un objet, un lien, etc.

de diagrammes qui permettent de combiner ces éléments

les diagrammes portent une cohésion

par exemple, un diagramme exprime un scénario (cohésion temporelle)

de vues qui permettent de rassembler les diagrammes

les vues correspondent à des étapes de la démarche de modélisation

deux types de vue

macroscopique : vue globale

microscopique : point de vue spécifique

Les constituants d ’UML

Vue fonctionelle

Injecteur

Objet

Cylindre

Objet

Température

Objet

Démarrage Moteur

Diagramme de séquence

Vue du motoriste

Cycle Antipollution

Diagramme de séquence

Vue du constructeur auto

Vue conceptuelle Vue technique

ModèleNiveau Vue

Macroscopique

Niveau Vue Microscopique

Diagramme

Élément de base du modèle

Les éléments de base du modèle

Servent à la modélisation de concepts dans les diagrammes.

Les éléments les plus classiques :

les items une classe : quelque chose de générique. Par exemple un cylindre

un objet : un élément physique. Par exemple le premier cylindre

un acteur : un objet externe au système. Par exemple, la pédale d ’accélérateur est un objet externe au système d ’injection

les liens entre items liens de composition

un cylindre fait partie d ’une ligne d ’échappement

Les associations

Associés à un stéréotype : la façon de représenter chaque élément graphiquement dans le modèle

Associés à des informations textuelles

Extensibles : on peut rajouter de nouveaux éléments, ou personnaliser les éléments standard

Les diagrammes

Définis à priori

Neuf diagrammes résultant de l’unification des méthodes

Certains diagrammes sont « redondants » ou corrélés

Liste exhaustive :

diagrammes des cas d ’utilisation

diagrammes de séquence

diagrammes de collaboration

diagramme d ’objets

diagrammes de classe

diagrammes d ’activité

diagrammes état transitions

diagrammes de composants

diagrammes de déploiement

Tour d ’horizon rapide des diagrammes UML

Contexte d’utilisation d’UML

On peut utiliser UML pour trois grandes catégories de travaux

Analyser un problème

Modéliser un problème

Synthèse du problème sous forme d’objets

Modéliser une solution

Description « logicielle » de la solution

Analyser un problème

Modéliser un problème

Modéliser une solution

Tour d ’horizon rapide des diagrammes UML

Diagrammes permettant d ’analyser un problème

diagramme des cas

diagramme de séquence et de collaboration

Diagrammes permettant de modéliser le problème diagramme d ’objets

Diagrammes permettant de modéliser une solution

au niveau conceptuel

diagramme de classes diagramme d activité et états-transition

au niveau informatique

diagramme des composants

diagramme de déploiement

Diagrammes des cas d ’utilisation

Diagramme de base de l ’analyse d’un problème

Décrit un ensemble de cas d ’utilisations

acteurs

cas

scénarios

Point de vue utilisateur

système = boite noire

Diagrammes des cas d ’utilisation

<<communique>>

<<Include>><< Extend>>

Freine

(Cas utilisé)Verglas détecté

(Cas complémentaire)

Conduit Automobile

(Cas)Conducteur

(Acteur)

ABS

(Acteur interne)

Diagrammes de séquence

Décrit une séquence d ’action ou un enchaînement d événements

Complément en général de la description d ’un cas d ’utilisation

Orientation temporelle

organisation dans le temps des actions, des messages

Parallèle au diagramme de collaboration


Conducteur

ABSGestionnaire

de trajectoire

Appuie Pédale Frein

[t°>0] Consigne

[t° <=0] Alarme

Information

Les objets

Le temps

Calcul

Disques

t0

t1

t1-t0<100 ms

Diagrammes de collaboration

Décrit la collaboration entre objets

Complément en général de la description d ’un cas d ’utilisation

Orientation communicationnelle

messages entre objets ou classes

Parallèle au diagramme de séquence


Conducteur ABS

1 : Appuie pédale

2 : Consigne

5 : Information

4 : CalculObjet C

: Objet ADisque 1

2 : Alarme

Diagrammes de classe

Diagramme de base des vues logiques

Décrit :

des classes

des attributs,

des opérations

des associations entre classes

d ’autres relations

héritage

composition

Diagramme d ’objets

Proche du diagramme de classe (s ’applique aux objets)

Diagramme complémentaire aux diagrammes de classes

Décrit :

des objets

des attributs,

des opérations

des associations entre classes

d ’autres relations

héritage

composition

Diagramme de classes et d ’objets

Conduire ()

nom

age : entier

Conducteur

rouler()Véhicule

Camion Voiture

Roue Système de

Frein

possède►

*0..1

4 à 8 41 à 2

Diagrammes état transitions

Base de la description de la dynamique

Décrit un ensemble d ’états

Décrit les transitions entre états

Très riche en formalisation

Complément au diagramme de classe ou d ’objet

Parallèle au diagramme d ’activité

Diagrammes d ’activité

Base de la description de la dynamique

Décrit un enchaînement d ’opérations

Pour une classe ou un objet donné

Scénario précis

Complément au diagramme de classe ou d ’objet

Parallèle au diagramme états transitions

Diagrammes état transitions

Appuie Pédale Frein

État 1

Entry : Diagnostic Freins

État 2

Do : Commande Disques

État 3

Diag Terminé [Pas de panne]

Pédale relâchée

Sous machine

Diagrammes de composants

Base de la description de la réalisation

Décrit :

les composants

les relations de dépendance

les relation de réalisation

classes

objets

associations

Diagrammes de déploiement

Base de la description du déploiement

Décrit :

les cibles

les tâches

Syntaxe UML standard limitée

nécessite généralement des compléments

Les vues

Les vues

Concept général en UML

La façon de voir le système

Un moyen, plus qu’un standard du modèle

Deux niveaux

macroscopique correspondent à des étapes du cycle de production

les vues macroscopiques servent généralement de base à l ’organisation des modes opératoires des outils UML

microscopique correspondent à des points de vue différents

vues orthogonales d ’une même analyse, d ’une même solution

Vue fonctionelle

Vue du motoriste Vue du constructeur auto

Vue conceptuelle Vue technique

Modèle

Macroscopique : l’organisation 4+1

A un niveau macroscopique, on peut représenter un système sous 5 points de vue :

vue des cas d'utilisation,

vue statique ou logique,

vue dynamique (processus),

vue des composants,

vue de déploiement (matériel).

Cette vue s’appelle 4 + 1 dans le jargon UML

Variante 3+1 (sans la vue dynamique)

Les vues 4+1 organisent l ’interface utilisateur des outils

Dans UML Rose par exemple, 4 niveaux de modélisation (4 vues)

A ne pas confondre avec les phases de modélisation

Macroscopique 4+1: les cas au centre de la modélisation

Vue

statiqueVue

dynamique

Vue descomposants Vue du

déploiement

Vue

des

Cas

d ’Util.

Vue macroscopique : autre exemple basé sur les étapes du développement

On utilise les phases de définition du produit

analyse système

analyse sous-système

une vue par sous-système

conception système

une vue par sous-système

intégration système

vue centrée sur la conception des interfaces entre les sous-systèmes

A chaque vue vont correspondre des niveaux de détail différents

Liens entre les vues macroscopiques et les diagrammes

Pas d ’association standard entre vues et diagrammes Pas de préconisation donc quant aux diagrammes à utiliser pour analyser ou

modéliser un problème ou une solution Dans le cours, on recommandera cependant certains usages

Quand utiliser quoi, et pourquoi

Les outils qui proposent des organisations standard peuvent éventuellement imposer des associations

Exemples d’associations possibles pour le 4+1: vue des cas d'utilisation:

diagrammes des cas d ’utilisation, de séquence, de collaboration, d ’objets

vue statique ou logique: diagrammes de classes, d ’objets, de séquence, de collaboration, d ’activités, d ’états

transitions

vue dynamique (processus): diagrammes de séquence, de collaboration, d ’activités, d ’états transitions, de déploiement

(tâches)

vue des composants : diagrammes de composants

vue de déploiement (matériel): diagrammes de composants, de déploiement

Microscopique = Les points de vues

A un niveau microscopique, il est souvent possible d'utiliser plusieurs points de vues :

plusieurs éléments de modélisation,

plusieurs syntaxes pour représenter les mêmes concepts ou des concepts complémentaires.

On utilise généralement un point de vue principal pour conduire une analyse ou une conception :

c'est le point de vue des utilisateurs en analyse ou le point des concepteurs en conception.

On peut compléter une modélisation en utilisant d'autres points de vue :

par exemple, utiliser le point de vue de l'exploitant d’un logiciel lors de l'analyse ou utiliser le point de vue des mainteneurs en phase de conception.

Les vues et la documentation UML

Le concept de vue peut conduire la documentation UML à une organisation complexe ni synoptique

ni hiérarchique

Conséquences information répartie

avec duplication possible

Cette souplesse peut conduire à des difficultés dans un contexte industriel

dans un contexte critique

Pour éviter tout problème, l’utilisation d’UML débute généralement par la mise en place d’une convention d’utilisation, dans laquelle on définit : Les vues macroscopiques ;

Les points de vue possibles

Les diagrammes associés a priori aux vues et aux étapes du développement

Autres éléments d ’UML

Les paquetages

Unité d ’organisation des constituants d ’UML Récursif Peut contenir

des éléments de modélisation de base des diagrammes des paquetages

Exemples : un paquetage de classes : catégorie un paquetage de composants : librairie un paquetage de cibles : cluster un paquetage de diagrammes de cas d ’utilisation : une

fonction un paquetage d ’acteurs : un ensemble d ’utilisateurs

Les stéréotypes

Unité de représentation associée à des concepts

critères de classification

Des stéréotypes standard

classe

classe paramétrée

acteur

travailleur d ’interface

etc.

Des extensions possibles

Principales extensions conseillées

acteurs

cibles (vue de déploiement)

Champ d ’application UML

UML Outil de Génie Logiciel

Par nature et par origine, UML est naturellementorientée vers le logiciel

De nombreux outils logiciels existent

De nombreux liens vers les langages de programmation

JAVA, C++

Homéomorphisme technologique

les langages de programmation actuels contiennent les éléments conceptuels contenus dans UML

Transition immédiate entre conception et réalisation

UML Outil d ’analyse Généraliste

UML est utilisé pour l ’analyse des problèmes

techniques

ou d ’autre nature

En dehors du Génie Logiciel

UML est utilisé comme « chapeau de l ’analyse »

On complète par des analyses plus ciblées effectuées par des méthodes complémentaires

analyse fonctionnelle : complément fonctionnel

AMDEC : complément sûreté et sécurité

analyse de la valeur : complément marketing

UML Outil de conception de système complexe

UML est utilisé pour la conception des systèmes complexes. Par exemple, des systèmes

à plusieurs composantes technologiques

Ou réalisés sur plusieurs sites

Ou réalisés dans le cadre de montage industriels complexes

Un exemple : conception système d ’un satellite

UML est utilisé pour l ’analyse système et la définition des sous-systèmes sous-systèmes fonctionnels et structurels

plate-forme, charge utile

définition et modélisation de l ’interface entre sous-système

prototypage, préparation de l ’intégration

On complète par la conception de chaque sous-système Avec des moyens et techniques propres aux technologies utilisées par les sous

systèmes Mécanique, thermique, électronique, etc.

Concepts Objets de Base

Approche objet :

L ’approche objet est le résultat de l ’unification entre les différentes approches de modélisation des logiciels (plus généralement de modélisation des problèmes)

Approches fonctionnelles et données

Approches non procédurales

L ’unification est présente dans l ’essence de l ’objet

L’approche objet a évolué au fil du temps pour suivre les courants technologiques

L’approche objet a permis une révolution dans le domaine de la production des logiciels

Aujourd’hui la production d’un logiciel est une activité de type analyse, intégration et personnalisation, plus qu’une activité de création et de développement

L’objet

L ’objet peut être expliqué de façon théorique ou pratique

Théorique

Le principe est dérivé de la notion de Type Abstrait Algébrique(TAA)

L’objet prend donc racine dans une théorie mathématique précise et complète

Pratique

Le terme « objet » est un terme volontairement simple emprunté au monde réel pour « vulgariser » la notion de type abstrait

L ’objet est la formalisation basique d ’un problème ou d’une solution

L ’objet est un moyen unifié de décrire simplement les données et les traitements en utilisant le même formalisme

Type Abstrait : Définitions

Un type abstrait décrit un type de données en masquant la manière dont il est réalisé

pour décrire un type concret on dit de quoi il est fait ; exemples : entier codé sur 32 bits

tableau = ensemble contigu d'éléments de même taille

pour décrire un type abstrait on dit quelles opérations il sait faire

Spécification algébrique d'un type abstrait

opérations supportées par le type + ensemble d'axiomes portant sur ces opérations

ces axiomes doivent former un tout complet et cohérent

de cette manière on axiomatise le domaine du problème

Un type abstrait algébrique permet donc de dire à la fois quels services rend un type et comment ces services s'articulent entre eux : le type est entièrement décrit par ses opérations

Description précise d'un TAA

Un Type abstrait est décrit par des signatures et des axiomes.

Signature = sortes + opérations sortes = symbolise formellement le domaine de définition

opérations = moyen d ’interagir avec l ’objet deux types d ’opération

les générateurs

les observateurs

Axiomes = système d'équations en logique du premier ordre, mettant en jeu variables et symboles fonctionnels les axiomes expriment des invariants

Exemple : le TAA Booléen

sortesBool

opérationsvrai : Bool (générateur)faux : Bool (générateur)_ : Bool Bool__ : Bool Bool Bool__ : Bool Bool Bool

axiomesa, b, c : Bool(b1) vrai = faux(b2) a = a(b3) a vrai = a(b4) a faux = faux(b5) a (b c) = (a b) c(b6) a b = b a(b7) a b = ( a b)

En Pratique : Qu’est ce qu’un bon objet ?

Un objet qui va de soi

Habituel, Naturel

L’objet appartient au vocabulaire du métier Un capteur, Une bielle, etc.

L’objet est le plus souvent homogène à une chose Concrète : Un constituant d’un moteur

Abstraite : Un cycle de combustion

L’objet peut être également homogène à des actions Un processus de fabrication

Un objet que l ’on peut appréhender sans le décrire en détail

effort d ’abstraction

Un objet que l ’on peut décrire sans parler a priori de son contenu

de ses opérations

de ses données

Exemple d ’objet - haut niveau

En phase d’analyse d’un problème, on effectue la description des objets à haut niveau

Nom de l’objet

Responsabilités de l’objet ce que l’objet sait faire, les services qu’il rend

Exemple

Objet Nombre Complexe

Description des responsabilités de l ’objet additionner deux complexes

calculer la norme d ’un complexe

donner la partie réelle, la partie imaginaire d ’un complexe

donner l’angle et le rayon d ’un complexe (coordonnées polaires)

Exemple d ’objet - bas niveau

En phase de modélisation d’une solution, on effectue la description des objets à bas niveau Nom de l’objet

Description des données contenues dans l’objet

Descriptions des opérations fournies

Exemple : Objet Nombre Complexe

les données x : la partie réelle

y : la partie imaginaire

les fonctions de l ’objet complexe norme : la norme du complexe (renvoie un réel positif)

addition : l ’addition de deux complexes (renvoie un complexe)

Une représentation possible pour un objet

Complexe

Addition ()

Norme ()

x

y

Le nom de l’objet

Les services proposés par l’objet

La partie cachée de

l’objet

Les notions objets élémentaires

Les notions Objets élémentaires

La notion d’abstraction

La notion d’encapsulation

Les notions de classe et d’instance

Attributs et Opérations

Héritage

Les relations

La notion d ’abstraction

Un objet est issu de l ’analyse du monde réel (le monde du problème)

On obtient les objets du problème par un effort d ’abstractionsur le dit problème

La qualité des objets décrits ne se limite pas ainsi à la fidélité de reproduction des objets du monde réel, mais également à la capacité à s ’extraire de ce monde réel par esprit d ’abstraction

Objets

du monde réel

Objets

du modèle

Domaine, métier

Domaine

« le domaine applicatif »

Un ensemble de connaissances ou d'activités caractérisé par des concepts et une terminologie propres aux praticiens de ce domaine. Une application (un projet) restreint un domaine aux besoins d'un projet.

associé à un domaine de compétence

Métier

le savoir faire d ’un domaine

décrit par les experts

Application et Projet

Application

l ’objectif du projet

une partie du domaine

décrit par les utilisateurs

Projet

le processus de fabrication de l ’application

Peut nécessiter une analyse du domaine (=> extension du cadre applicatif)

Objets

du domaine

Objets

du projet

Abstraction : illustration

Complexe peut être un objet du domaine du problème (e.g. problème = création d’un bibliothèque de calcul) on utilise le complexe tel quel

on devra alors décrire l ’ensemble des responsabilités du complexe (au sens mathématique du terme) On décrit par exemple tous les opérateurs du complexe

Complexe peut être un objet du monde de la solution on utilise un complexe pour des calculs électriques

on limite la portée de la description des responsabilité

on oriente le complexe Le complexe est un élément de solution : on ne décrit que

opérateurs utiles à la solution

Abstraction : illustration

Autre exemple :

Pour un mathématicien, un complexe est un élément du corps des complexes : il doit ainsi proposer des opérations comme trouver le complexe inverse

Pour un électronicien, un complexe est un outil d’expression algébrique des lois électriques : une restriction des opérations est suffisante






Héritage

Encapsulation

La notion d’encapsulation permet de faire la distinction lors de la modélisation entre :

ce qui est visible à l ’extérieur de l ’objet (public),

ce qui est caché à l ’intérieur de l ’objet (privé).

L’interface de l ’objet est composé de la partie visible

L ’interface peut contenir des données ou des fonctions

La notion d ’encapsulation est un moyen de séparer entre implémentation et interface (pour fournir par exemple plusieurs implémentations)

La séparation est forte et stricte

Encapsulation : exemple

Sur l ’objet Complexe, on décide de cacher x et y

principe de masquage de l ’information

On rajoute deux fonctions d ’accès à x et y

Get_x

Get_y

On rajoute également deux fonctions d ’accès au rayon et à l ’angle

Cela permet de modifier ultérieurement l ’implémentation du nombre complexe

utiliser des cordonnées polaires

Illustration de l ’encapsulation

Complexe

Addition ()

Norme ()

Get_x ()

Get_y ()

Get_ro ()

Get_theta ()x

yX et Y sont masqués

L’interface publique d’un

complexe






Héritage

Classe et Instance

Une classe décrit un ensemble potentiellement infini d'objets individuels : tous les objets qui ont les mêmes attributs, les mêmes opérations, relations, contraintes et le même comportement.

Un objet est une instance d'une classe : les données de l'objet correspondent aux attributs de la classe auxquels on a affecté des valeurs. Le comportement et les opérations s'appliquant sur un objet sont ceux décrits pour la classe que l'objet instancie.

Une classe instanciée en un seul objet est un singleton

Classe et Instance

Complexe

Addition ()

Norme ()

Get_x ()

Get_y ()

Get_ro ()

Get_theta ()X

y

1

X = 1

Y = 0

i

X = 0

Y = 1

Affectation des données

membres

Objets et Instances

On utilise souvent le terme « objet » dans un sens générique (instance ou classe)

Les propriétés d’un objet

Approche objet

Lorsque l’on veut lever l’ambiguïté on utilisera explicitement les termes instances et classes

Création et destruction d ’instances

Les instances naissent, vivent et meurent

La création d ’instance peut être statique ou dynamique

On associe généralement des opérations déclenchées lors de la création et la destruction

Une instance persistance est une instance dont la durée de vie dépasse celle de l'application et donc qui doit être stocké sur un support permanent (dans un fichier, une base de données...).

Exemples de création le complexe 1 (x=1,y=0)

le complexe j ( x=0,y=1)






Héritage

Attributs, Opérations et Méthodes

Un attribut d'une classe est une des données de la classe.

Une opération est un service offert par une classe. Une opération peut comporter des paramètres.

Une méthode est la réalisation d’une opération (L’algorithme ou la procédure qui donne le résultat d’une opération)

Opérations particulières

Les constructeurs

création d ’instance

Les copies

copie une instance dans une autre instance

clone une instance

Les conversions (d ’une classe c1 vers une classe c2)

créer une instance temporaire de c2 initialisée avec les données d ’une instance de la classe c1

Les destructeurs

destruction d ’instances

généralement unique par simplicité

Opérations particulières (suite)

Les sélecteurs

Accès aux données (généralement cachées)

Support au masquage d’information (encapsulation)

Exemple : Get_x ()

Les modifieurs

Modification des données (généralement publiques)

Centralisation de la modification

Support au masquage d’information (encapsulation)

Exemple : Set_x ()






Héritage

Les relations

Héritage

L’héritage est une technique de classification pour les classes : une classe A hérite d ’une classe B si A « est une sorte » de B.

A est la classe fille ; B la classe mère ( la classe ancêtre ou la super-classe)

La classe ancêtre factorise des propriétés communes aux classes héritières

La relation d’héritage exprime ainsi une idée de spécialisation / généralisation entre des classes

la classe fille spécialise la classe mère

la classe mère généralise la classe fille

Héritage : exemple

Figure

Polygone

Dessin ()

Couleur

ListeSommets

Héritage : exemple discutable

Polygone

Dessin ()

Polygone régulier

?

ListeSommets

Il est difficile d ’exprimer ce qui

caractérise un polygone régulier

par rapport à un polynome en

termes de :

fonctions

données

L ’héritage dépend donc du contexte

et des techniques utilisées

?

Héritage : meilleure approche

Polygone

Dessin ()

Polygone régulier

Dessin ()

ListeSommets Nb de sommetsCentreSommet Origine

Figure

Divers types d ’héritage

Héritage multiple : une classe fille hérite de plusieurs classes ancêtres

Héritage répété : Une classe dérivée hérite « plusieurs fois » d’une même classe de base, via plusieurs chemins dans un arbre d’héritage (D hérite de B1 et B2 qui héritent de A).

Héritage multiple

Polygone

Dessin ()

ListeSommets

Figure Surface

Surcharge et redéfinition

On parle de surcharge d ’opération, ou de redéfinition de méthode lorsque qu’une sous-classe donne une nouvelle implémentation à une méthode définie dans sa super classe, en respectant scrupuleusement sa signature (nom de la méthode, type de retour, liste de paramètres et d’exceptions).

On distingue la surcharge au niveau opération, de la redéfinition (ou ré implémentation) au niveau méthode.

Il est conseillé de garder la même sémantique pour chaque opération surchargée

Exemple de surcharge

Figure Encadrée

Dessin ()

Figure Titrée

Dessin ()

Donne une

implémentation

de base à

la fonction de dessin

(dessin d ’un cadre)

x,ycx,cy

Exemple de redéfinition

Figure Encadrée

Dessin ()

Cercle

Dessin ()

x,ycx,cy

Renonce à

l ’ implémentation

de base

(dessin d ’un cadre)

Classe racine

Une classe qui n’a pas de mère dans la hiérarchie d’héritage et qui a des filles est appelée racine (racine de l’arbre d’héritage).

On définit généralement plusieurs racines dans un projet

base de la décomposition du projet en classes

Certaines racines sont fournies par l ’environnement de programmation :

classe Object dans JAVA = racine de tout objet

Object

ThrowableString

Exception

RuntimeException

Error

Integer






Héritage

Les relations

Association

Une relation sémantique entre deux ou plusieurs classes, ou catégories, qui implique des connexions au niveau instance.

Une association est généralement binaire Dans une association, les extrémités ont un poids

équivalent.

Moteur Boite1:n 1:n

boite moteur

Agrégation

Une forme spéciale d’association qui spécifie une relation « tout - partie » entre l’agrégat (tout) et une partie.

Exemple :

Voiture Personne1 n

passagers

Composition

Une forme d’agrégation qui exprime une forte propriété entre le tout et les parties, ainsi qu’une subordination entre l’existence des parties et du tout.

Exemple :

Moteur Cylindre1 n

cylindres moteur

UML

Analyse d ’un problème avec UML

Analyse avec UML

L ’analyse d ’un problème en UML repose sur une démarche de description sur la base de scénarios

scénarios d’utilisation définis sous forme de cas

élaborés en prenant le point de vue des utilisateurs

L’analyse conduit généralement à la fabrication d ’une vue macroscopique :

la vue des cas d ’utilisation

Analyse sans UML

L ’approche fonctionnelle est celle utilisée le plus couramment dans l ’analyse des problèmes, hors UML

Rappels :

L ’analyse fonctionnelle consiste à décomposer le problème en sous-problèmes, jusqu’à aboutir à des problèmes élémentaires que l ’on sait résoudre

L ’analyse fonctionnelle est une approche

itérative

hiérarchique

descendante

on part d ’un gros problème et on le divise

Comparaison de l ’approche « objet » avec l ’approche fonctionnelle

Approche fonctionnelle point de vue « fonctions »

possibilité de confusions entre le quoi et le comment le quoi : le problème

le comment : une solution

difficultés pour arrêter la décomposition fonctionnelle

Approche par cas d ’utilisation (UML) on revient toujours au point de vue « utilisateur »

tout cas est relié à un acteur (qui est externe au système)

évite la description du « comment »

parfois insuffisant pour une spécification industrielle besoin de décrire également des mécanismes

Démarche d’analyse d’un problème avec UML

On suit avec UML la démarche suivante :

Identification de la périphérie du problème

les acteurs

Identification des événements

Les événements dont déclenchés par les acteurs (stimuli)

Table des évènements

Détail des cas d’utilisation

Les cas sont les actions conséquences des stimulis

On décrit dans le détail chaque scénario

Synthèse des cas

On donne une vue d’ensemble sur les scénarios

Vue des cas d ’utilisation

Identification des acteurs

La description des acteurs permet d'identifier précisément la " frontière " du système à analyser en définissant les personnes, matériels ou autres systèmes qui interagissent avec le système courant.

L ’acteur est un utilisateur dans un rôle particulier (ex. opérateur, client, administrateur,…) ou, plus généralement, toute entité externe à l'application et qui interagit avec elle (sous-système ou matériel de l'environnement…).

Les acteurs sont en dehors du système à modéliser.

Les acteurs sont représentés pas des stéréotypes

On peut avoir recours dans certains cas à l ’utilisation d ’acteurs « internes »

complémentaires

utiles pour simplifier la description

Exemple

Modélisation du fonctionnement d’un ascenseur

Acteurs :

Utilisateur de l’ascenseur (passager)

Technicien (chargé de la maintenance de l’ascenseur)

Agent de sécurité (prévenu en cas d’appel d’urgence)

Identification des Evenements

L'identification des événements est un travail complémentaire à la description des acteurs.

Ce travail va permettre une bonne préparation de la description des cas d'utilisation.

Un événement est attaché au monde réel : il représente sous forme abstraite un incident ou un signal qui marque un changement d'état. Un événement est ainsi toujours associé à un récepteur: ce récepteur est généralement un acteur ou un objet du monde réel.

Table des événements

On remplit une table d’événement avec : La signification de l'événement : c'est la description de ce qui

se passe dans le monde réel lorsque l'événement se produit

L’acteur principal (déclencheur du cas)

Les acteurs auxiliaires

Le cas déclenché (homogène à un scénario)

des paramètres éventuels

ParamètresCasAutres acteurs

Acteur principal

Évènement

Exemple

Ascenseur :

On / OffArrêterUtilisateurStop

AlerterAgent de sécurité

UtilisateurAlerte

Haut / BasAppelerUtilisateurAppel

nChoisir Étage

UtilisateurChoix Étage

Numéro de testTesterTechnicienAction clé

ParamètresCasAutres acteurs

Acteur principal

Évènement

Détail des cas d’utilisation

La description textuelle des cas d'utilisation est effectuée à l'aide d'un modèle de cas d'utilisation. Vue de détail

L’essentiel du travail

La description graphique des cas d'utilisationconsiste à regrouper sur un diagramme les objets qui participent à un scénario et à montrer leurs interactions sans entrer dans le détail des messages échangés. Elle est formalisée à l'aide de diagrammes de collaboration

et de séquences

Elle n’est pas systématique : on ne l’effectue que pour quelques scénarios complexes

Synthèse des cas d’utilisation

La description graphique des cas d'utilisation est effectuée avec les diagrammes de cas d'utilisation d'UML.

Vue de synthèse

Synthèse : vue des cas

Appeler<<Appel (Haut, Bas)>>

Utilisateur

Choisir<<Choix (n)>>

Arrêter

<<Stop (On/Off)>>

Alerter

<<Alerte>>

Agent de

sécurité

Technicien

Tester

<<Action Clé (n)>>

Etude de cas

Recherche des acteurs, des événements et des cas d'utilisation

« Fonctionnement d’un calculateur de contrôle moteur»

On joue le rôle de l ’équipementier (= fabriquant du calculateur)

Informations complémentaires

Le calculateur est un équipement électronique connecté à d ’autres

équipements du véhicule comme le Système de Freinage, la

commande de boite à vitesses, la commande d ’accélération, etc.

Il réagit indirectement aux actions du conducteur, et directement aux

stimulis de capteurs d ’état (température, pression, etc.) et de position

moteur (angle vilebrequin et arbre à cames )

Il commande des organes électriques comme les injecteurs, des

vannes, ect.

Le calculateur peut être diagnostiqué et calibré

Modélisation UML de la vue des cas d’utilisation

Analyse d’un problème

La vue des cas d ’utilisation : contenu

Cette vue est composée principalement de trois types de diagrammes UML :

les diagrammes de cas d’utilisation

les diagrammes de séquence

les diagrammes de collaboration.

Cette vue peut également contenir d’autres diagrammes UML comme des diagrammes de classes qui illustrent la participation des objets aux cas d’utilisation

Diagrammes des Cas d ’utilisation

Diagrammes de cas d’utilisation

Les diagrammes de cas d'utilisation mettent en jeu des cas d'utilisation et des acteurs.

Un cas d'utilisation représente une séquence d'actions que le système va exécuter lorsqu'il interagit avec un acteur.

Les cas sont représentées dans des « ovales ».

Le diagramme est une vue graphique assez pauvre(vue synthétique des interactions)

Le diagramme doit être complété par un texte plus précis

Exemple de diagramme des cas

<<communique>>

<<Include>>

<<Extend>>

Cas utilisé

Cas complémentaire

Cas décrit

Acteur

Acteur internePoint d ’extension

autre

Scénario

Séquences spécifiques d'actions qui illustrent des comportements

Ils sont déclenchés par des acteurs

Ils manipulent des objets

Un cas est souvent composé de plusieurs scénarios

Le scénario principal

Des scénarios alternatifs

Les messages

Les acteurs interagissent avec ce système par des messages :

les message de type <<communique>>.

On peut décider d'orienter ou de ne pas orienter la relation <<communique>>.

Lorsque la relation est orientée, on fait la distinction entre acteur actif qui déclenche un scénario, et acteur passif qui reçoit simplement un message.

On peut préciser la nature de cette communication en donnant un nom au message

Les relations d ’ extension

La relation <<Etend>> exprime l'idée que l'on peut compléter l'exécution du cas d'utilisation courant par des actions complémentaires (afin de prendre en compte une alternative).

<<communique>>

<<Etend>>

Cas complémentaire

Acteur

Point d ’extension

autre

Les relations d ’inclusion

La relation <<Utilise>> exprime l'idée qu'un cas d'utilisation va utiliser un autre cas d'utilisation pour s'exécuter.

<<communique>>

<<Utilise>>

Cas utilisé

Acteur

Point d ’extension

autre

Le point de vue

Le diagramme de cas d'utilisation est orienté par la vue que l'utilisateur a du système à analyser et des services qu'il en attend

On peut décrire des parties propres au fonctionnement interne du système s'il s'agit de préciser l'interaction entre l'acteur et le système.

Dans ce cas, cette précision n'est pas vue comme une description du " COMMENT " mais comme un complément au " QUOI " qui sera éventuellement remis en cause lors de la recherche d’une solution au problème.

Besoin de préciser le point de vue

Les mécanismes

Il est possible d'utiliser un mécanisme pour structurer le modèle UML

Les mécanismes sont :

soit des acteurs identifiés à la périphérie du système, mais qui en font partie (on parle d'acteurs d'interface)

soit des agents (comme des processus) qui sont responsables du déclenchement de cas d'utilisation

soit un autre sous-système pour le sous-système courant.

les mécanismes servent à la modélisation des cas d'utilisation

on utilise un stéréotype particulier pour le repérer.

Les points d ’extension

Le compartiment optionnel " Point d'extension " permet de préciser des extension complémentaires propre à un cas.

Utilisé pour la description d ’alternatives

Vocabulaire complémentaire

Alternative

Partie d'un cas d'utilisation qui sort du déroulement normal. Une alternative peut être une exception.

Déroulements/ Enchaînement

Normal

L'enchaînement des activités standard d'un cas ou d'un scénario.

Alternatif

Tout enchaînement autre que le déroulement normal.

La représentation Textuelle des cas d ’utilisation

Représentation Textuelle des cas

La vue graphique UML est pauvre concernant les cas d ’utilisation et doit être complétée par un texte

Le texte n ’est pas standard en UML

La rédaction d ’un texte de cas de fonctionnement doit respecter l ’orientation « utilisation » du système

On utilisera pour chaque projet un format standard

fiche de cas

template documentaire (.dot par exemple)

Cette description permettra par la suite l ’analyse du vocabulaire (identification des objets)

Exemple de canevas pour une description textuelle

Cas d’utilisation

Acteurs

Point de vue

Préconditions

Description

détaillée

Déroulement

normal

Postconditions

Exceptions Déroulement

alternatif

Variantes

Cas d’utilisation

Acteurs

Point de vue

Préconditions

Description

détaillée

Déroulement

normal

Postconditions

Exceptions Déroulement

alternatif

Variantes

Les rubriques d ’un UC textuel (1)

L'identification : numéro d'ordre, nom. Cette identification est utilisée en traçabilité.

Les acteurs et mécanismes impliqués. Pour les cas d'utilisation reliés par des relations de type " Include " ou " Extend ", cette rubrique peut être vide.

Le point de vue adopté : est ce le point de vue externe ? le point de vue d'un développeur ?


Le déclenchement : quel est l'événement (ou les événements) qui déclenche(nt) le cas d'utilisation

Les préconditions : on décrit l'état du système avant le déroulement du cas. Cet état se limite généralement à la description des données qui sont utilisées par le cas d'utilisation.

La description détaillée du cas : Interactions et messages échangées,

actions effectuées

Sous forme de liste d’actions élémentaires

Le plus souvent Ping-Pong (acteur – système)

La description peut faire apparaître des alternatives (variantes ou exceptions)


Les postconditions : on décrit l'état du système après le déroulement du cas.

On se limite généralement à la description des données qui sont modifiées par le déroulement du cas d'utilisation.

Les exceptions : on décrit le traitement éventuel des exceptions levées.

Une exception est assimilée à un cas d'erreur ou à un fonctionnement dégradé.

Les variantes : on décrit le traitement associé aux variantes détectées.

Une variante correspond à un comportement alternatif au comportement standard, sans être une exception.

Exemple de détail : cas de l’ascenseur

Cas = Appel

Acteur = Utilisateur

Point de vue = Utilisateur

Déclenchement = L’utilisateur appuie sur le bouton d’appel de l’ascenseur

Pré-condition = Ascenseur en état de marche

Détail 1 . Si l’ascenseur est déjà présent à l’étage d’appel => variante A, sinon l’ascenseur

enregistre la demande d’appel si elle n’est pas déjà enregistrée

2. L’ascenseur consulte la file des demandes, et se rend à l’étage correspondant à la demande la plus prioritaire

3. La porte de l’ascenseur s’ouvre

4. Si l’étage d’arrêt de l’ascenseur correspond à la demande de l’utilisateur, le scénario prend fin.

5. L’ascenseur supprime de la file des appels la demande courante et reprend en 2.

Variante A A1 . La porte de l’ascenseur s’ouvre

Post-condition : L’ascenseur est présent à l’étage d’appel, porte ouverte

Règles complémentaires d ’écriture d ’un UC

On n'utilisera pas de forme impersonnelle, ni de forme passivesans préciser qui fait l'action.

Une formulation impersonnelle ou passive cache les acteurs, ce qui nuit à l'identification des responsabilités et des objets.

Les formes impersonnelles sont moins précises

On utilisera un texte court (1 ou 2 pages au format A4 pour le cas d'utilisation complet). Des méthodes de réduction de texte standard peuvent être appliquées : supprimer les adverbes inutiles, supprimer les constructions littéraires, supprimer les paraphrases.

une description courte limite les incohérences

une description courte permet d'éviter les paraphrases

une description courte permet d'éviter le style littéraire

Les scénarios

Notion de scénario

Un scénario est une instance de cas d'utilisation ou un sous ensemble de cas :

dans un scénario, l'alternative est exclue ou très limitée.

La modélisation des scénarios devra être effectuée soit de façon textuelle , soit de façon graphique.

La modélisation textuelle d'un scénario s'effectue en complétant la rubrique " Description textuelle des cas d'utilisation ".

Modélisation graphique des scénarios

Les diagrammes utilisés pour modéliser les scénarios sont les diagrammes de séquence et les diagrammes de collaboration

On peut décomposer un scénario soit :

en interactions entre objets : on suit alors la voie qui conduit à un diagramme de collaboration

en séquences d'activités : on préfère alors le diagramme de séquence

Généralement on choisit un seul diagramme

Dans certains cas, les deux diagrammes pourront être décrits car il seront complémentaires.

Point de vue

La modélisation d'un scénario doit s'effectuer selon un point de vue identifié

Le point de vue choisi doit être décrit : dans le cas d'une modélisation graphique, on devra faire figurer ce point de vue sous forme de note attachée au diagramme.

Ce point de vue oriente le diagramme et illustre ce sur quoi on veut mettre l'accent.

Un diagramme de séquence ou un diagramme de collaboration n'exprime pas tout le scénario mais seulement un point de vue

Cohérence entre diagrammes

Lorsque la cohérence entre un diagramme de collaboration et un diagramme de séquence n'est pas assurée par l'outil, on devra choisir entre les deux:

Les diagrammes de séquence et de collaboration expriment les mêmes idées avec des nuances.

Assurer la cohérence signifie par exemple, que le changement de l'ordonnancement des actions sur un diagramme de séquence doit entraîner une re-numérotation des séquences sur le diagramme de collaboration.

Dans le cas ou l'outil support assure la cohérence, on pourra en revanche multiplier les diagrammes ce qui permet de multiplier les points de vue.

Les diagrammes de séquence


Un diagramme de séquence montre les interactions entre les objets en fonction du temps.

Les objets communiquent par messages :

un message va d'un objet vers un autre.

un message peut être éventuellement réflexif.

Une ligne de message horizontale montre une transmission immédiate du message ; une ligne inclinée montre une transmission avec un délai.

Exemple de diagramme

Les objets

Le temps

Acteur

: Objet A : Objet C

Message 1

[x>0] Message

2

[x <=0] Message 3

Message 4

Réflexif

: Objet B

t0

t1

t1-t0<100 ms

Autres possibilités du diagramme (1)

Le déclenchement d'un message peut être conditionné : message 2 n'est effectivement déclenché que si x>0

Acteur

: Objet A : Objet C

Message 1

[x>0] Message

2

[x <=0] Message 3

Message 4

Réflexif

: Objet B


Chaque objet a une ligne de vie symbolisée par un trait pointillé. L'objet B est créé par le déclenchement du message 2 et détruit lors de l'exécution du scénario : la croix symbolise sa fin de vie.

Acteur

: Objet A : Objet C

Message 1

[x>0] Message

2

[x <=0] Message 3

Message 4

Réflexif

: Objet B


Les boites blanches représentent les périodes de temps au cours desquelles l'objet est actif : activation des objets

Acteur

: Objet A : Objet C

Message 1

[x>0] Message

2

[x <=0] Message 3

Message 4

Réflexif

: Objet B


Il est possible d'associer des datescomme t0 et t1 et des contraintes sur les dates comme (t1-t0<100ms)

Le temps

Acteur

: Objet A

Message 1

Message 4

t0

t1

t1-t0<100 ms

Intérêt de ce type de diagramme

On choisira un diagramme de séquence plutôt qu'un diagramme de collaboration lorsque l'on veut mettre en évidence l'organisation des événements dans le temps et l'enchaînement des événements du scénario :

La visualisation du temps et des séquences est immédiate sur un diagramme de séquence

La visualisation des créations et destruction d'instances est immédiate

Structuration : approche par contrôleur

Dans cette approche, le premier objet contrôle tous les suivants

Structuration : approche par délégation

Dans cette approche, chaque objet contrôle l'objet suivant auquel il délègue une partie des traitement

Les diagrammes de collaboration


Le diagramme de collaboration met l'accent sur l'interaction entre les objets

On relie les objets et acteurs

La communication est décrite par des flèches,

On peut indiquer le message échanger

On peut indiquer éventuellement le numéro d'ordre du message dans la séquence des messages


Acteur

Objet B : Classe B

1 : Message 1

2 : Message 2

3 : Message 3

5 : Message 4

4 : RéflexifObjet C

: Objet AObjet A

Objet BC


On représente les agrégations par une boîte englobante : sur le schéma, les objets B et C sont rassemblés dans l'agrégation objet BC

Objet B : Classe B

3 : Message 3

4 : RéflexifObjet CObjet BC


On peut représenter les classes auxquelles appartiennent les objets dans le cas où ces classes ont été définies : l'objet B appartient à la classe B

Objet B : Classe B

3 : Message 3



On peut présenter la notion d'instance multiple pour un objet : c'est le cas pour l'objet A.

Objet B : Classe B

2 : Message 2

3 : Message 3


: Objet AObjet A

Objet BC


On peut préciser la nature des liens entre objets : s'agit- t 'il d'un lien par donnée membre, par paramètre, par donnée globale ?

Objet B : Classe B

2 : Message 2

3 : Message 3


: Objet AObjet A

Objet BC


On peut associer d'autres propriétés aux objets comme leur persistance ou leur activité (les objets actifs sont autonomes en terme de comportement et sont représentés avec un contour épais)

3 : Message 3



On peut définir le mode de transmission de chaque message : simple (le cas général), synchrone, asynchrone, avec time out , etc. La différence entre modes de transmission est marquée par le type de flèche.

Objet B : Classe B

3 : Message 3



La séquence peut être exprimée de façon assez complète : on peut préciser des conditions de synchronisation, des séquences parallèles, etc.

Acteur

Objet B : Classe B

1 : Message 1

2 : Message 2

3 : Message 3

5 : Message 4


: Objet AObjet A

Intérêt de ce type de diagramme

On choisira un diagramme de collaboration plutôt qu'un diagramme de séquence lorsque l'on veut mettre en évidence la communication entre les objets plutôt que l'organisation des événements dans le temps

Il y a deux façon d'exprimer la communication dans un diagramme de collaboration :

de façon simple et immédiate : en exprimant les liens entre les acteurs et les objets. Ces liens sont la base de la communication ; ils se traduisent par des messages échangés entre les objets

de façon plus élaborée

Organisation générale d ’une vue des cas d ’utilisation

Structuration

La vue des cas d'utilisation sera structurée à l'aide de paquetages afin d'améliorer sa lisibilité.

On décrira un paquetage minimum par sous-système

On utilisera la décomposition en paquetages pour distribuer le travail de modélisation

On pourra utiliser les paquetages pour multiplier les points de vues

Chaque paquetage ainsi décrit contiendra un ensemble de cas d'utilisation. On appellera ce paquetage un " paquetage de cas ".

Contenu d ’un paquetage de cas

Un paquetage de cas peut contenir :

des acteurs (propres ou attachés au cas)

des cas

description textuelle des cas

des scénarios

complément descriptif aux cas

des diagrammes

de cas d ’utilisation

de séquence

de collaboration

d ’autres paquetages

UML

Modélisation d ’un problème avec UML

Modélisation d ’un problème avec UML

La modélisation d ’un problème avec UML est le résultat définitif de l ’analyse

Cette modélisation consiste à :

identifier les objets du problèmes

représenter ces objets en utilisant des diagrammes appropriés

En particulier le diagramme d ’objets

Cette modélisation s’effectue à partie des résultats de l’analyse du problème

Les diagrammes de cas

Les diagrammes de séquence et de collaboration

Le détail des cas (partie textuelle)

Étapes de la modélisation du problème

La modélisation du problème s’effectue en trois étapes

La recherche des objets initiaux du monde du problème à partir de ceux du monde réel

La consolidation de l’analyse

On arbitre le résultat de l’étape précédente

La formalisation du problème

On crée des diagrammes UML qui permettront de représenter de détailler les objets du problème

Étape 1 : Identification des objets initiaux du problème

L’identification des objets du problème consiste à chercher dans le résultat de l’analyse le objets possibles

Certains objets apparaissent déjà dans des scénarios Diagrammes de séquence ou de collaboration

On va compléter ces objets déjà identifiés par une analyse exhaustive de tous les objets possibles pour notre problème Démarche aveugle

Démarche « par le bas » On identifie des candidats : les objets initiaux

On consolidera ces objets dans une seconde étape

Technique utilisée : l’analyse du vocabulaire

Analyse du vocabulaire

Technique classique pour la recherche des objets initiaux

Principe : faire une analyse grammaticale du résultat de l’analyse (le détail des cas en particulier)

Détermination des objets et des classes potentiels du système

Cette technique est très simple, ne demande pas de formation particulière

Cette technique est très rapide

Cette technique oblige à une mise à plat de l ’ensemble du vocabulaire

L’analyse du vocabulaire est un travail brut et mécanique :

on n’élimine a priori aucun terme de l’analyse

La synthèse d’effectuera dans un premier temps

Analyse du vocabulaire : la démarche

Obtenir ou décrire de façon informelle le vocabulaire du domaine ou de l'application A partir de description textuelles

Identifier les objets et les classes en utilisant les noms, pronoms, etc. Les noms précis (noms propres, singuliers) sont utilisés pour trouver les objets (les instances). Les noms généraux sont utilisés pour trouver les classes.

Repérer les constructions de type "est composé de ", " fait partie de ", etc. pour identifier les agrégations

Repérer les compléments de temps pour déterminer les évènements

Identifier les groupes verbaux peut isoler des services et des responsabilités

Généraliser les instances pour créer de nouvelles classes par repérage des adverbes et des adjectifs

Associer les services à des classes

Grouper tous les résultats dans une table

Analyse du vocabulaire : exemple(extrait d’un cas d’utilisation)

Sur événement Clé-On vers Clé-Off, le calculateurprincipal envoie un message de «Coupure-Alimentation» aux autres calculateurs auxiliaires.

Chaque calculateur auxiliaire envoie un message d’acquittement et effectue la sauvegarde des données.

Les groupes nominaux

Les groupes verbaux

Les évènements

Résultat de l’analyse du vocabulaire

Envoyer message « Coupure alimentation »

calculateurCalculateur principal

Envoyer message « Acquittement »

Sauver les données

calculateurCalculateur auxiliaire

Responsabilités et services

ClasseObjet

Étape 2 : Consolidation de l’analyse

La consolidation s’effectue en deux temps Complément éventuel de la table des objets et

des classes On complète indépendamment des cas en rajoutant des

compléments naturels qui ne sont pas décrits dans les cas mais qui sont logiques par rapport à la cohérence des objets

Synthèse On regroupe des objets

En classes plus génériques

On regroupe des service En service plus standard, moins détaillés, plus génériques

Exemples de compléments

Pour chaque service rendu, on se pose la question de l’intérêt du service réciproque

Sauver les données => Restaurer les données

On rajoute donc restaurer les données à l’objet calculateur auxiliaire

Pour chaque service rendu, on rajoute les services liés au fonctionnement dégradé s’ils ne sont pas décrits dans les cas d’utilisation

Sauver les données => Sauver les données critiques (mode dégradé)

Pour chaque objet passif, on se pose la question du déclencheur des service : on crée si besoin le déclencheur comme nouvel objet

Qui est le déclencheur de l’ « événement Clé-On vers Clé-Off » Création de l’objet « Centrale de condamnation des portes »

Étape 3 : formalisation

La formalisation s’effectue principalement au travers de deux diagrammes Les diagrammes d’objets

Le point central

Les diagramme de classe plus rares dans le cas de la modélisation du problème

On peut éventuellement compléter ces diagrammes par des compléments Diagramme de séquence ou de collaboration

complémentaires à ceux de la vue des cas

L’ensemble de ces diagrammes constitue la vue logique

Structuration de la vue logique

On structure la vue logique en paquetages en respectant les décompositions en sous-systèmes et catégories :

La notion de sous système en UML permet de structurer la vue logique à haut niveau

La notion de paquetage en UML permet de structurer chaque sous-système

Attention : dans UML les paquetages ne sont qu’un simple regroupement logique

Pour améliorer la lisibilité d’un modèle, on doit faire coïncider la structuration de la vue logique (niveau modèle) et la structuration de la décomposition statique (niveau conceptuel).

Exemple de structuration correcte

Capteurs de portières Capteurs de capot

Condamnation des portes

Injecteurs

Commande d'injection

Système

La structuration du modèle logique correspond à la structuration en organes

« Système »

Exemple de structuration confuse

Capteurs de portières

Condamnation des portes

Capteurs de capot Injecteurs

Commande d'injection

Système

La structuration du modèle logique ne correspond pas à la structuration en

organes « Système »

Diagrammes de classes et d’objets

Vue logique

Diagramme de classes et d ’objets

Les diagrammes de classes représentent les classes, leurs propriétés et leurs relations.

Les diagrammes permettre de représenter les relations d'héritage (entre mère et fille), les relations d'agrégation, les associations, les compositions et les liens de dépendance.

Les diagrammes d'objets sont comparables aux diagrammes de classes mais contiennent des instances. Ils sont généralement moins techniques et plus applicatifs

Description d ’une classe

Chaque classe ou objet est représenté par une boite qui contient des « compartiments » :

Le compartiment " nom " est le premier : il décrit le nom de la classe ou de l'objet, auquel on peut joindre des propriétés comme " la classe est elle abstraite ou pas ". On peut également utiliser un stéréotype pour identifier le type de la classe (exemple de la classe Mère).

Les compartiments suivants sont des listes : on peut les utiliser pour décrire des listes d'opérations, d'attributs, de responsabilités, d'exceptions, etc. Les outils apportent des limitations à l'utilisation des listes et proposent généralement des listes standard.

En phase d’analyse du problème, on n’utilise généralement que le compartiment opérations pour décrire les responsabilités des objets

Classe

Attributs

Responsabilités

Classe

Responsabilités

Description textuelle des classes

Les caractéristiques de chaque classe sont décrites sous forme de rubriques informatives.

Certaines informations sont déduites de la modélisation graphique (les relations par exemple). Les autres sont à renseigner par le biais de texte ou de boites de dialogue.

Informations textuelles possibles

le type de la classe : classe simple, métaclasse, classe abstraite

son stéréotype UML,

la cardinalité de son ensemble d'instance (instance unique ou non)

son autonomie de traitement : classe active, passive

Description des responsabilités

En analyse d’un problème, on décrit uniquement les responsabilités des objets :

souvent exprimées comme des verbes , avec ou sans complément

On ne décrit donc généralement pas de paramètres, pas de valeurs de retours, pas d'attributs

On se limite à une liste de services : ces services pourront être traduit en phase de modélisation du problème par des opérations dans le cas ou l'on conserve la même décomposition.

Cette limite permet de ne pas empiéter sur les solutions : on reste à un niveau de modélisation du problème

Types de classes

UML propose des types de classe qui permettent de distinguer Classe de contrôle : homogène à un traitement, ce type de

classe sert à représenter un gestionnaire

Classe entité : homogène à une donnée, ce type de classe est utilisé pour représenter une donnée (généralement structurée et persistante)

Classe interface : La description d'une classe peut se limiter à son interface

Classe utilitaire : elles sont utilisées pour rassembler des opérations de bas niveau afin d'exprimer une notion de bibliothèque de fonction ou pour exprimer une cohésion de coïncidence.

Les objets

Les objets sont les instances associées aux classes

La description des classes n’est pas obligatoire, mais recommandée pour simplifier les diagrammes, sauf pour les singletons

Les instances sont reliées aux classes par des liens d’instanciation

Lors de la description d'un objet sur un diagramme de classe, on peut donner le nom de la classe associée : " objet : classe ".

Objet :Classe

Responsabilités

Héritage

Les relations d'héritage sont représentées par le lien de généralisation.

Entre classes

Elles illustrent la relation « est un » ou « est une sorte de »

Classe Fille 2

Attributs

Opérations

Classe Fille 1

Attributs

Opérations

Mère

Agrégations et Composition

Les agrégationsexpriment en UML un lien « faible » entre container et contenus

Les compositionsexpriment en UML un lien « forte » entre container et contenus

Le tout n’existe pas sans les parties

Salle de cours

Responsabilités

Élèves n

Responsabilités

Promotion

Responsabilités

Élèves n

Responsabilités

Associations

Les associations supportent un nom, un rôle pour chaque extrémité et une cardinalité.

On peut décrire des " qualifier " (les rôles) associés aux associations qui sont des attributs spécifiques qui vont permettre de compléter la description des relations, ou qui vont préparer l'implémentation.

Classe

Attributs

Opérations

Classe reliée

Attributs

Opérations

0..1

1

+ rôle 1

+ rôle 2

Associations : rôles

Les noms de rôles doivent être uniques et distincts des noms des attributs de la classe opposée (i.e. de la classe située à l'autre extrémité de l'association).

Toutes les associations issues d'une même classe doivent avoir, à leur extrémité, des noms de rôle différents et distincts des noms des attributs de la classe opposée.

Pour éviter des conflits de nom (en particulier à la génération de code) :

un rôle correspond implicitement à un attribut de la classe associée.

Associations complexes

Lorsque la relation est complexe ou que de l'information complémentaire doit lui être affectée, on peut attacher une classe à la relation

Classe

Attributs

Opérations

Classe reliée

Attributs

Opérations

0..1

1

+ rôle 1

+ rôle 2

Classe association

Attributs

Opérations

Classe Association

Si un attribut est une caractéristique d'une association entre deux classes, il est plus lisible de le définir comme un attribut de la classe association et non de l'une des classes.

Définir un attribut d'association dans une des classes est une implémentation possible qu'il est prématuré de considérer dans un diagramme d'analyse du problème.

Le diagramme est plus évolutif : en effet, si la cardinalité de l'association est transformée en "plusieurs-plusieurs", il n'est plus possible de conserver l'attribut de l'association dans l'une des classes.

Catégorie

Une catégorie est un ensemble de classes

Une catégorie est une unité de découpage conceptuelle

Elle devrait correspondra à une unité de découpage du modèle

On ne confondra pas :

Catégorie

Agrégation et composition

Modélisation d’une catégorie Catégorie

Exemple à commenter

SeReposer()

Travailler()

Conduire ()

nom

age : entier

Personne

rouler()Véhicule

Vélo Voiture

Roue Moteur

possède►

roues

roue_secours

moteur

roues

*0..1

24

11

Multiplication des points de vue

Multiplication des points de vues

Le multiplication des points de vue contribuent à l'amélioration de la qualité de l'analyse du problème

Chaque point de vue (ou chaque angle de vue) donne lieu à un nouveau diagramme

Les outils de modélisation peuvent assurer la cohérence entre les diagrammes

Jusqu’à une certaine limite

Attention à ne pas tendre vers l’excès de modélisation

Exemple de point de vue : le Diagramme Interface

Il montrera l'ensemble des relations entre les classes de la catégorie courante et les classes externes (n'appartenant pas à cette catégorie).

Il est réservé à l'expression de l'interface d'un paquetage afin de préparer l'intégration de ce paquetage avec les autres parties du système analysé.

On décrira par exemple systématiquement un paquetage d'interface pour chaque sous système, ou par chaque unité d'intégration (développement séparé réalisé en parallèle par une autre équipe par exemple).

Il permet de détailler les relations entre les paquetages

Autre exemple de point de vue : Diagramme de Synthèse

Il concerne les paquetages qui regroupent d'autres paquetages (comme les sous-système)

Il décrit les relations entre les paquetages contenus.

Il est utilisé au sein d'une même unité d'intégration.

On utilisera un seul paquetage de plus haut niveau pour exprimer l'interface entre l'ensemble des paquetages de l'unité d'intégration.

Autres diagramme spécifiques

D’autres diagrammes de classes spécifiques pourront être ajoutés à tout paquetage afin d'exprimer une idée ou d'insister sur un élément de modélisation

un diagramme associé à un scénario précis : on montre les classes qui participent au scénario et leurs liens

un diagramme qui montre une hiérarchie d'héritage

un diagramme qui exprimer une agrégation

un diagramme qui exprimera une relation

Concepts Objets Avancés

Les notions Objets élaborées

Catégories et Paquetages

Attributs et fonctions statiques

État

Liaison dynamique et Polymorphismes

La généricité

La dynamique et le flot de contrôle

Catégorie et Paquetage

La paquetage est un mécanisme général désignant un regroupement d’éléments dans un ensemble

Une catégorie est un paquetage de classes (et de catégories) et moyen de structuration hiérarchique d'un modèle Objet.

L’ensemble des catégories réalisent un recouvrement des classes et des relations entre classes (pas forcément une partition)

Une catégorie peut comprendre à la fois des catégories filles et des classes

On utilise les catégories pour regrouper sémantiquement des classes

Catégorie et Paquetage

Transporter ()

Véhicule

Trottinette Voiture

Roue Moteur

roues

Roue de secours

moteur

roues

2

4

1

1

Paquetage Moyen de Transport

Sous-système

Partie d’un système telle que l’ensemble des sous-systèmes constitue une partition du système.

La nature des sous-systèmes peut être très variée et n’est pas généralement un résultat de l’analyse ou de la conception.




État


La généricité


Attribut statique

Une donnée partagée entre tous les objets de la classe

On parle d'attribut statique ou attribut de classe (par opposition à un attribut d’instance)

Tous les objets (les instances) peuvent accéder à un attribut statique

La modification d ’un attribut statique doit être contrôlée

Exemple :

Le nombre d ’instances courantes pour la classe complexe est une donnée statique

Cette donnée est modifiée par les constructeurs et destructeurs

Attribut statique

Complexe

Addition ()

Norme ()

Get_x ()

Get_y ()

Get_ro ()

Get_theta ()X, y

NbInstance

1

X = 1

Y = 0

i

X = 0

Y = 1

La donnée NbInstance n’est pas définie dans

les instances

Opération statique

Une opération de la classe que l’on peut utiliser sans instance

Une opération statique s’applique aux données statiques de la classe

Exemple :

La fonction d’accès au nombre d’instances

Opération statique

Complexe

Addition ()

Norme ()

Get_x ()

Get_y ()

GetNbInstance ()

X, y

NbInstance

1

X = 1

Y = 0

i

X = 0

Y = 1




État


La généricité


État interne

L ’état interne d ’une instance caractérise le comportement complet de l ’objet

L ’état est caractérisé lui même par un ensemble d ’attributs non statiques (les attributs d ’état)

La modification des attributs d ’état entraîne la modification de l ’état de l ’objet

Exemples

le complexe est caractérisé par x et y

un attribut NbUse qui compte le nombre d ’accès en lecture à une instance (incrémenté par les opérations d ’accès) n ’est pas un attribut d ’état

État interne : exploitation

La partition des attributs entre attributs d ’états et autres attributs améliore la fiabilité

On différenciera les opérations :

qui modifient l ’état d ’un objet

opérations non constantes

qui ne modifient pas l ’état d ’un objet

opérations constantes




État


La généricité


Liaisons statique et dynamique

Liaison statique :

liaison qui s ’effectue lors de l ’édition de classique standard

Liaison dynamique :

Liaison qui ne s’effectue pas lors de l’édition de lien statique, mais lors de l’exécution. L’héritage dynamique demande une liaison dynamique.

Mécanisme nécessitant l ’utilisation de pointeurs, ou d ’autres mécanismes spécifiques

Méthode Virtuelle

Méthode d'une classe, sur laquelle s'applique la liaison dynamique.

Le mécanisme d ’appel à une méthode virtuelle repose sur le principe des pointeurs de fonction

Méthode Virtuelle Pure : méthode virtuelle que l ’on doit forcément redéfinir dans une classe fille.

Une méthode virtuelle pure peut ne pas avoir de définition (uniquement une déclaration)

On ne peut utiliser directement une méthode virtuelle pure.

Exemple de méthode virtuelle

Volume Droit

Surface ()

Volume ()

Prisme Droit Régulier

Surface ()

Hauteur

Dans le cas général, on ne sait pas calculer une surface. La fonction surface est virtuelle, on doit la définir dans toutes les classes filles.

Cylindre

Surface ()

RayonCoté, Nombre

Le volume en revanche peut être calculé de façon

générique pour tout volume droit

Volume=surface()*hauteur

Classe abstraite

Une classe qui possède au moins une méthode virtuelle, soit directement, soit dans la liste des méthodes héritées.

La liaison dynamique s ’applique ainsi à toute classe abstraite

Une technique pour rendre une classe abstraite est souvent de décrire l ’opération de destruction virtuelle

Objets Polymorphes

Possibilité d’utiliser une même référence pour des objets de structures différentes.

Cette possibilité est offerte par les langages de programmation objet et permet une programmation générique

Le polymorphisme s ’appuie sur les classes abstraites et utilise la liaison dynamique

Dans l ’exemple précédent, une référence vers un volume droit est polymorphe

soit un prisme droit

soit un cylindre

Les autres notions d’objet



État


La généricité


Concept de Template

Classe paramétrable

Opération ou méthode paramétrable (hors arguments)

Les paramètres

des types, des classes

des opérations

Exemples

une classe de gestion de Pile

paramètre : le type de l ’élément empilé

une classe de gestion de dictionnaire

paramètre : une méthode d ’indexation

Plus généralement, une technique de méta modélisation

Les autres notions d’objet



État


La généricité


Objet Persistant

Objet qui continue à exister après un traitement ou un fil qui l’a créé. Un objet persistant s’oppose à un objet transitoire.

La persistance est souvent synonyme de sauvegarde dans une mémoire de masse.

La sauvegarde suppose généralement une transformation de l’objet de sa forme dynamique vers une forme homogène à un flot de caractères facilement stockable.

Cette transformation s’appelle la mise en série de l’objet (ou sérialisation).

Objet transitoire

Un objet fugitif qui n’existe que pendant l’exécution d’une méthode, d’un fil ou d’un processus.

Contraire d ’un objet persistant

Les instances transitoires doivent être créées et détruites avec précision

mécanismes de gestion des instances

« fabrique »

Objet actif ou passif

Objet Actif

Un objet autonome ou capable de modifier son état sans intervention externe.

Un objet actif contient généralement un automate qui modélise son comportement

Objet passif

Un objet incapable de modifier son état sans intervention externe.

Un objet passif est vue comme un ensemble de services sans contrôle dynamique associé

Supports logiciels de la dynamique

Processus : Flot de contrôle (exécutable) qui peut s’exécuter en parallèle avec d’autres processus. On parle parfois de tâche

Thread : Flot de contrôle léger qui peut s’exécuter en parallèle avec d’autres threads dans un même processus.

Processus et Thread peuvent posséder des propriétés comme la priorité, la récurrence, le mode d’activation, en accord avec les possibilités de l’operating system support.

Un processus ou un thread est associé aux objets actifs

Synchronismes

La communication entre objets (messages) peut empiéter sur le déroulement du flot courant de l ’objet

Action synchrone

Action sous forme de requête qui interrompt le cours du flot courant pour attendre la fin de son exécution. On parle également d’action exécutée de façon synchrone.

Action asynchrone

Action sous forme de requête qui n’interrompt pas le cours du flot courant pour attendre la fin de son exécution. On parle également d’action exécutée de façon asynchrone.

UML

Modélisation d ’une solution avec UML


Contrairement aux activités tournant autour du problème, les activités d’UML tournant autour de la solution sont orientées principalement vers la production de logiciel

Certaines parties de la modélisation peuvent éventuellement être appliquées à d’autres domaines

La modélisation d ’une solution comprend trois grandes parties

L’approfondissement de l’analyse

Éventuellement la remise en cause

Le détail de la vue logique

La modélisation dynamique


Première Étape : Approfondissement de l’analyse

Principe de l’approfondissement de l’analyse

Principe général

On va critiquer la vue logique obtenu en phase d’analyse du problème afin de dégager une solution

La solution Doit répondre au problème

Mais peut répondre à d’autres problèmes du même type

Peut également réutiliser des éléments de réponses mis au point sur d’autres projets (et qui n’ont rien à voir a priori avec le problème courant)

Principes techniques

Des itérations sur les catégories et les classes permettent : de créer de nouvelles classes, de remettre en cause les classes existantes

Recherche de réutilisation de composants existant

Utilisation des schémas standard design patterns

Il existe des règles que l’on peut suivre et qui guident la démarche d’approfondissement


Exemples de règles applicables

Classes façades

Introduire des classes façade pour simplifier ou améliorer l'interface des catégories.

La classe façade d'une catégorie donne une interface simplifiée pour ses clients.

services de création et de destruction d'objets,

accès régulé aux autres classes publiques de la catégorie.

Exceptions :

Les classes thématiques

Les classes composites

Schéma(s) : Façade

Classes façades : intérêt

Fournir un point d'entrée privilégié pour les classes d'une catégorie, ce qui la rend plus facile d'utilisation

Minimiser les relations de dépendance entre un client et les classes de la catégorie

Limiter le couplage

Améliorer la primitivité

Classes de services

Introduire des catégories et des classes techniquesdédiées à la fourniture de services transversaux et essayer de les concevoir avec une cohésion forte

Dans la plupart des applications, des services ou mécanismes communs aux différentes catégories doivent être mis en œuvre. Ces services peuvent être regroupés dans une ou plusieurs classes dédiées.

On essayera d'améliorer la cohésion de ces catégories en groupant fonctionnellement les services fournis.

Classes de services : intérêt

Elle assure l'homogénéité de l'application : elle permet de réutiliser une même solution dans les différentes parties de l'applicatif où le même problème technique se pose.

La conception est plus lisible et plus évolutive.

La traçabilité de la conception vis à vis de l'analyse est facilitée

Les composants de ces catégories transversales ont la particularité d'être réutilisables. Le fait de les concevoir dans des catégories dédiées favorise leur réutilisation dans le contexte d'autres projets.

Classes de services : exemples

Composants dédiés à la gestion de processus (communication, partage de ressources, service de nommage, ...).

Composants encapsulant les "appels système" (mécanisme de verrouillage, gestion des droits d'accès au fichier, ...),

Mécanismes facilitant la mise en place de machines à état, la gestion des événements ou des exceptions.

Séparation Domaine

Les classes de responsabilité thématique (issue du domaine) doivent être séparées des classes de catégorie informatique (implémentation de la solution) afin d'améliorer la réutilisabilité et la maintenabilité

Il est recommandé de ne pas mélanger dans un même paquetage des classes issues du domaine avec les autres types de classes (techniques, informatiques)

Les classes du domaine doivent être identifiées

Attribut du modèle ou une règle de nommage

Séparation Domaine/Informatique : Intérêt

Meilleure maintenabilité

Meilleure traçabilité entre les classes d'analyse et les classes de conception.

Le développement des deux types de classes (informatiques et du domaine) ne demande pas les mêmes compétences. Séparation des équipes

Les composants informatiques sont souvent réutilisables quel que soit le domaine d'application(réutilisation horizontale) alors que le spectre de réutilisation des objets du domaine est restreint au domaine d'application (réutilisation verticale).

Créations

Repérer les classes à structure complexe, évolutive ou générique et créer une classe spécifique qui prend en charge la création et éventuellement la gestion de leurs instances

classe complémentaire qui prend en charge complètement la gestion de toutes les instances de la classe.

classe qui fournit les services basiques de créations et de destructions, en s'appuyant éventuellement sur un schéma de classe.

Des services complémentaires peuvent prendre en charge la gestion des instances comme le comptage des instances, l'itération sur les instances, etc.

Schémas : " Fabrique Abstraite ", " Fabrication ", " Monteur ", " Prototype "

Créations : Intérêt

La centralisation des instances permet d'avoir une seule interface quel que soit l'objet construit, sa structure, sa complexité ce qui facilite l'utilisation de la création d'instance

La centralisation facilite également la maintenancecar on a une très bonne séparation entre l'interface de création et l'implémentation de la création

Enfin, cette centralisation supporte la création dynamique d'objet : la centralisation permet de contrôler l'ensemble des instances créées afin d'éviter ainsi des problèmes de mémoire, de pointeurs en l'air, etc.


Deuxième Étape : Détails de la vue logique

Principe du détail de la vue logique

Lors de la modélisation de la solution, la vue logique sera plus précise, plus complète que lors de la modélisation du problème

Les classes seront plus nombreuses

On utilisera des possibilités de modélisations plus avancées

Idée

Préparation de l’activité de programmation

En pratique, cette activité est très liée aux possibilités des outils UML et leur capacité à générer du code à partir des modèles UML

Attributs

On détaille les classes en donnant les attributs

La description des attributs comprend un nom, un type, une valeur par défaut, une cardinalité: On va préciseer la visibilité des attributs

si l'attribut est public (+), privé (-) ou protégé (#).

Un attribut peut être dérivé d'un autre attribut.

Pour améliorer la maintenabilité, les attributs sont généralement privés ou protégés Principe de masquage de l’information

Les outils utilisés peuvent proposer des représentations graphiques plus adaptéesà la représentation de ces propriétés.

+Visible:int = 10

# Protégé : float = 0.7

+Get (in x: int = 0)

# Display () {abtrait}

Classe

Description des attributs

En phase de modélisation du problème, la vue logique devra décrire les caractéristiques de chaque attribut afin d'améliorer la complétude et préparer la phase de codage

On décrit précisément les attributs de chaque classe.

Cette description est effectuée en fonction des possibilités de l'outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre).

Description des attributs

Informations associées aux attributs :

sa visibilité et son mode (" statique " par exemple)

son type

sa valeur par défaut (associé au constructeur par défaut = initialisation sur démarrage à froid)

ses autres valeurs d'initialisation possibles (initialisation sur démarrage à chaud, réinitialisation, etc.)

un lien éventuel avec des opérations d'accès

la description des attributs est utilisée pour compléter la génération du code

Opérations

On détaille les classes en donnant les opérations Plus précis que les simples responsabilités

La description des opérations comprend un nom, un type de retour, une liste de paramètres. On peut préciser si l'opération est publique (+), privée (-)

ou protégée (#).

Pour chaque paramètre, on peut décrire un nom, un type, un mode (in , out ou in-out) et une valeur de défaut.

On peut préciser si l'opération est abstraite ou pas.

Les outils utilisés peuvent là aussi proposer des représentations graphiques plus adaptéesà la représentation de ces propriétés. +Visible:int = 10

# Protégé : float = 0.7

+Get (in x: int = 0)

# Display () {abtrait}

Classe

Description des opérations

En phase d’explicitation d’une solution, la vue logique devra décrire les caractéristiques de chaque opération afin d'améliorer la complétude et préparer la phase de codage

Cette description est effectuée en fonction des possibilités de l'outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre). On peut aller jusqu’à définir toutes les opérations de niveau

langage de programmation, si l’on dispose d’un outil efficace en terme de génération de code

Sinon, on ne décrira que les opérations principales, avec une syntaxe simplifiée

Description des opérations

Informations associées à une opération :

sa visibilité

sa signature (type de retour, paramètres, mode de passage)

le protocole d'appel

les exceptions éventuelles levées et traitées par l'opération

les pré conditions et post conditions

la description des opérations est utilisée pour générer les squelettes de code pour chaque fonction

Description du comportement

La description d'une opération doit être réalisée à l'aide d ’assertions (pré conditions et post conditions), et non pas à l'aide d'algorithme ou de flot de donnée

L'utilisation des pré conditions et post conditions est conseillée pour chaque opération.

Des principes éventuels de conception peuvent être également ajoutés à la description de l'opération, sans entrer dans une description algorithmique précise.

Description des exceptions

On établira pour chaque opération et pour chaque classe, la liste des exceptions afin de compléter la description du comportement statique

Pour spécifier le contrôle, on doit faire la liste des exceptions locales (privées) et non locales (publiques).

Les exceptions privées sont traitées localement.

Les exceptions publiques seront référencées globalement.


Dernière Étape : Modélisation de la dynamique des classes

Modélisation de la dynamique

La modélisation de la dynamique s’effectue par une vue complémentaire

La vue de la dynamique

La vue dynamique consiste à compléter la vue logique et la vue des cas d'utilisation par des informations plus précises qui visent à décrire la dynamique du logiciel et de certaines classes.

Diagrammes UML possibles

diagramme états – transitions et diagramme d'activités

Éventuellement diagramme de séquence et diagramme de collaboration

Compléments UML possibles

diagrammes des cas d ’utilisation

Niveaux de modélisation

La rajout d 'éléments de modélisation pour exprimer la dynamique peut être effectué à trois niveaux

Niveau Classe et Objet :

on décrit le fonctionnement interne d'une classe

Niveau Paquetage :

on décrit le fonctionnement interne d'un paquetage

Niveau Logiciel ou Sous Système :

on décrit le fonctionnement interne d'un sous système

le fonctionnement du logiciel complet et l ’interface dynamique entre les sous systèmes

Diagramme États Transitions

Diagrammes états - transitions

Les diagrammes états - transition permettent de modéliser des machines à états.

Ils permettent de modéliser la dynamique des systèmes réactifs ou événementiels de façon semi-formelle.

Inspirés par : les Statechart de Harel,

les Réseaux de Pétri,

le Grafcet.

Si leur description est rigoureuse, les diagrammes états transitions sont déterministes et se prêtent bien à la génération de code.

Diagrammes états - transitions (1)

Les diagrammes états - transitions permettent de décrire des états stables dont 2 particuliers : l'état initial et l'état final.

Événement initial

Événement Final


Les états peuvent être reliés par des transitions qui expriment le changement d'état. Ce changement peut être déclenché par un événement, une condition ou la conjonction des deux.

État 1

État 2

Événement [condition]


Une transition peut être également directement déclenchée par la fin d'une activité : on parle alors de transition automatique.

État 1

État 2


On peut associer à chaque transition des actions ; de la même façon , on peut associer des traitements aux états.

État 1

Entry : Activité

État 2

Do : activité

Événement / Action


Événement initial

État 1

Entry : Activité

État 2

Do : activité

État 3

Evénement [condition]

[condition]

Événement / Action

Sous machine

Diagrammes états - transitions : possibilités

La modélisation que UML propose pour les diagrammes états transitions est très riche :

pour chaque état, on peut définir des actions associées à l'état, mais aussi des actions en entrée et en sortie de l'état ; on peut également définir des actions sur transition interne : on ne change pas d 'état mais on effectue une action lorsque un événement survient. Cette transition interne peut même être associée à une condition de garde

pour chaque transition simple, on peut définir un événement déclenchant, mais aussi une condition de garde, une action sur transition et une liste de messages

Diagrammes états - transitions : possibilités

il est possible d'utiliser des disjonctions et conjonctions afin d'exprimer un parallélisme :

le franchissement d'une transition de type disjonction entraîne l'activité de deux états concurrents supportés par deux fils (threads) distincts

il est possible d'associer des propriétés aux événements :

le stéréotype signal permet de décrire des événements en utilisant les diagrammes de classes.

On peut utiliser les relations d'héritage pour hiérarchiser les événements.

Possibilités d ’incohérences

La puissance d'expression d'UML est très riche en ce qui concerne les diagrammes états transitions

La richesse peut conduire à des incohérences lors de la description des éléments du modèle :

incohérences entre la description des actions sur état et la description des actions sur transition

incohérences entre la description des actions en sortie d'une état, et la description des actions en entrée d'un autre état

incohérences entre la description des événements et la description des actions

UML est un langage semi formel

Non comparable à des formalismes comme le Grafcet ou les réseaux de Pétri

Non interprété

Utilisation en cas de rigueur exigée forte

Si le niveau de rigueur exigé pour le diagramme est fort, on utilisera une restriction des diagrammes états - transitions pour représenter la dynamique complète de la classe

Si le niveau de rigueur exigé est fort, il faudra que la représentation du comportement soit non ambiguë. Dans certains cas, on préférera même une modélisation parallèle avec un outil adapté à base de Réseaux de Pétri ou de LDS qui prendra en charge une génération du code, ou une preuve de bon comportement.

Restriction de la modélisation

utiliser uniquement des transitions simples : on remplace les transitions multiples par des transitions simples en rajoutant des états de synchronisation utiles pour supprimer le parallélisme induit par les transitions multiples

utiliser des conditions simples ou des événements simples pour chaque transition : on supprime les disjonctions / conjonctions d'événement ou les disjonctions / conjonctions de conditions en rajoutant des états intermédiaires.

Restriction de la modélisation (suite)

utiliser des attributs de la classe pour décrire les conditions : on supprime les effets de bord quitte à avoir une image des

données externes à la classe utiles à la description du comportement. La création d'une donnée image permet de décrire précisément la disponibilité de la donnée (quand est elle mise à jour ? )

ne pas utiliser pour exprimer les transitions les attributs de la classe qui décrivent son état : les conditions doivent être totalement indépendantes des

variables d'états de la classe qui elles sont associées aux états. Il faudra rajouter des états complémentaires pour prendre en compte ces conditions particulières.

Restriction de la modélisation (fin)

éviter le mélange d'événements et de conditions sur une même transition : on crée autant d'états intermédiaires que de combinaisons

événements - conditions

utiliser : soit des traitements sur états uniquement (les activités) , (pas de

traitement en entrée, ni en sortie, ni sur événement interne, ni sur transition)

soit des traitements en entrée uniquement (les activités) , (pas de traitement sur état, ni en sortie, ni sur événement interne, ni sur transition)

dans les traitements, ne pas utiliser des attributs d'état de la classe : si c'est la cas, on doit éclater les actions pour ne retenir que les actions élémentaires associées aux états courants

Restriction de la modélisation : intérêt

La restriction de la modélisation évite les incohérences de description précitées

Elle impose une duplication des états permettant une meilleure sémantique pour chaque état

Cette restriction simplifie l'expression des actions et des conditions, améliorant ainsi la robustesse

Exemple : Description non rigoureuse

Off->On

Démarrage

Do : Diagnostic

Nominal

Do : Diagnostic

IT0 [!Panne périphérique]

On->Off

Description non rigoureuse (commentaire)

Sur l'événement " Off->On ", on passe dans l'état démarrage. Cet état se termine lorsque l'IT0 est déclenchée s'il n'y a pas de pannes.

On passe alors dans l'état Nominal d'où l'on sort sur l'événement On->Off.

Dans chacun des états, on exécute la même activité qui consiste à diagnostiquer les événements.

Off->On Démarrage

Do : Diagnostic

Nominal

Do : Diagnostic


On->Off

Description non rigoureuse (commentaire suite)

Incohérences ou ambiguïtés : " Panne périphérique " est un attribut d'état : il ne doit pas être utilisé dans une

condition mais donner lieu à la création d'états complémentaires. Cela permet notamment de décrire le fonctionnement du logiciel en mode dégradé lorsque les pannes apparaissent.

L'activité de diagnostic exécutée dans chacun des états dépend de l'état. Il faut la découper : diagnostic en démarrage, diagnostic en nominal.

Que se passe t il si l'interruption IT0 survient et si la donnée Panne périphérique n'est pas disponible ou si sa valeur n'est pas cohérente avec l'état des périphériques ?

Que se passe t il si la panne périphérique survient 1 seconde après le déclenchement de l'IT0 ?

Off->On Démarrage

Do : Diagnostic

Nominal

Do : Diagnostic


On->Off

Description plus rigoureuse

Off->On

Démarrage

Entry : Diagnostic

en démarrage

Nominal

Do : Diagnostic

en Nominal

IT0

On->Off

Panne Détectée :

Entry : Diagnostic

de confirmation

Panne Confirmée :

Entry : Diagnostic

de confirmation

[Diagnostic positif]

[!Confirmation]

[Confirmation]

Diagramme d'activités

Diagramme d ’activités

Un diagramme d'activités est une machine à étatsdans laquelle les états sont des activitésreprésentant les opérations, et les transitions sont déclenchées par la terminaison des opérations.

Les états d'un diagramme d'activité sont appelés des états actions :

la fin de l'exécution d'un traitement entraîne le déclenchement d'un événement implicite qui conduit au changement d'état.

Diagramme d ’activités (1)

On peut utiliser des conjonctions et des disjonctionsafin de modéliser des cheminements d'actions. Il est possible d'aiguiller l'enchaînement en rajoutant des conditions.

État Action 3

État Action 5État Action 4

[Condition B][Condition A]


On peut modéliser des objets dont la mise à jour est associée au changement d'état : ces objets peuvent être décrits à l'aide de leur état interne.

État Action 1

État Action 2 État Action 3

Objet [État 1]


Les objets peuvent être également en entrée d'un état action : on veut signifier dans ce cas là que l'enchaînement vers une nouvelle activité est déclenché par le changement d'état de l'objet.

État Action 3



Objet [État 2]

État Action 8


On peut découper un diagramme en couloirs pour exprimer un parallélisme d ’actions

Couloir 2Couloir 1

État Action 1


Objet [État 1]

Diagramme d ’ activités complet

État Action 1





Objet [État 1]

Objet [État 2]

État Action 8

Utilisation des diagrammes d ’activités

Le diagramme d'activité pourra être utilisé afin de mettre en lumière un enchaînement de traitementsinternes à une classe.

On le réservera pour des modélisations peu rigoureuses, purement informatives, dans lesquelles on veut mettre en lumière des contraintes de synchronisation entre opérations

éviter la multiplicité des formalismes

on référera le diagramme états transitions

Le sémantique du concept de couloir est trop faible et ne permet pas par exemple de définir des fils (threads)

Diagramme États Transitions

Règles et Recommandations

États homogènes

Dans un diagramme états - transitions, les états doivent être homogènes afin de faciliter la description des transitions et la compréhension du comportement

Dans un diagramme ou les états sont hétérogènes, on mélange généralement les comportements

Simplification d ’un diagramme / États homogènes

Des états homogènes d'un diagramme correspondent aux différents valeurs ou classes de valeurs (au sens d'une relation d'équivalence) de l'état interne de la classe.

L'état interne peut être associé à une notion de mode, de temps, etc..

La recherche d'une meilleure homogénéité consiste par exemple à séparer les états " internes " des états liés à des déclenchements d'événements externes.

On utilisera une sous machine pour décrire des états de niveaux différents

États homogènes : contre exemple

Off->On

Démarrage

Mode Superviseur

IT0 [!Panne Périphérique && SuperviseurPassword

On->Off

Mode Utilisateur

Standard

IT0 [!Panne Périphérique && !SuperviseurPassWord]

IT0 [Panne Périphérique]

États homogènes : contre exemple

Il mélange deux notions :

celle de gestion du mode de fonctionnement du système (démarrage- normal),

celle de gestion des modes d'utilisation du logiciel (utilisateur standard, superviseur)

Pour améliorer le diagramme, on devra créer deuxmachines.

Une machine de Gestion des Modes

Une machine de Traitement du diagnostic

Refonte : Gestion des modes

Off->On

Démarrage

Mode Superviseur

[SuperviseurPassword]

On->Off

Mode Utilisateur

Standard

IT0

Connexion

Entry : GetPassword

[!SuperviseurPassword]

On->Off

Refonte : Traitement du diagnostic

Off->On

Démarrage

Entry : Diagnostic

en démarrage

Nominal

Do : Diagnostic

en Nominal

IT0

On->Off

Panne Détectée :

Entry : Diagnostic

de confirmation

Panne Confirmée :

Entry : Diagnostic

de confirmation

[Diagnostic positif]

[!Confirmation]

[Confirmation]

Simplification des diagrammes

Le nombre de chemins indépendant dans un diagramme états transitions sera limité à 15 si l'on veut maîtriser le comportement qu'il décrit.

La complexité d'une machine se mesure par le nombre de chemins linéairement indépendants qui conduisent de l'état initial à l'état final.

Théorie des graphes

nombre cyclomatique : v(G)

Si le nombre de chemins est trop important, la machine devient difficilement testable.

Limitation du nombre de chemins

Pour limiter le nombre de chemins , on structure les diagrammes état transitions en faisant apparaître des sous - machines et en reportant la règle sur les sous machines

L'enchaînement entre les sous - machines est une machine de plus haut niveau que l'on peut appeler machine maître.

Lors d'une telle organisation, la machine maître doit être très simple.

Réversibilité

On doit toujours pouvoir revenir dans n'importe quel état, autre que l'état initial si on veut améliorer la fiabilité

La réversibilité exprime la possibilité pour une machine à état de pouvoir toujours revenir directement ou indirectement dans un état que l'on a quitté.

Ce principe peut exprimer par exemple la possibilité d'annuler une action (" undo "), de pouvoir effectuer une action inverse afin d'annuler l'effet d'une action passée, de se recaler sur un état plus stable ou de se récupérer après une erreur.

Réversibilité (suite)

Ce principe est essentiel en conception sûre.

La réversibilité améliore la sûreté de fonctionnement

Attention, cette propriété est formelle et nécessite une formalisation très stricte de la machine, en termes d'actions et de conditions.

Restriction d ’UML

Synchronisation

Quel que soit l'état courant, il doit exister un moyen de rejoindre l'état final afin d'améliorer la sûreté de fonctionnement

" séquence de synchronisation ".

L'existence de séquence de synchronisations exprime les capacités de non blocage d'une machine à états.

Une machine capable de ne pas se bloquer améliore la sûreté de fonctionnement

Attention, propriété formelle

Évaluation de la qualité d ’un modélisation

Évaluation de la qualité des objets et des classes

Cohésion

La cohésion de chaque classe doit être forte afin d'améliorer la maintenabilité

La cohésion mesure la pertinence des liens entre les informations (méthodes et attributs) internes à un objet. Une forte cohésion est le signe d'une très bonne abstraction et minimise l'impact des modifications.

Une classe ou catégorie doit représenter une et une seule abstraction : c'est le cas de la cohésion fonctionnelle ou Type abstrait

Mesure de la cohésion

On peut définir une échelle de la cohésion, de la plus faible à la plus forte de 0 à 6.

0Arbitraire (Coïncidence)

1Logique

2Temporel

3Procédural

4Communication

5Séquentiel

6Type abstrait

Niveau 0 : Arbitraire (Coïncidence)

Les traitements (méthodes) n'ont aucun lien logique entre eux

Les attributs sont accolés sans lien structurel ou fonctionnel.

Exemple : On rassemble dans une classe tout ce qui est développé

par une même personne, ou tout ce qui est développé sur un site, ou tout ce qui est développé en utilisant un langage particulier.

Commentaires et actions d'amélioration : Ce type de cohésion doit être évité à tout prix : il faut

redistribuer les attributs et les opérations dans d'autres classes

Niveau 1 : Logique

Les traitements sont de même nature mais il n'existe pas d ’autre lien entre eux.

Exemple :

On regroupe dans une classe l’ensemble des fonctions mathématiques

Commentaires et actions d'amélioration :

Ce genre d'approche n'est pas souhaitable en approche orientée objet : il faudra réorganiser les opérations en les associations à des types de données précis. Par exemple, on pourrait découper la classe en regroupant les opérations sur les nombres réels ce qui permettrait de cacher l'implémentation. On pourrait isoler les opérations trigonométriques, ce qui permettrait une liberté supplémentaire sur la représentation des données (implémentation polaire par exemple).

Niveau 2 : Temporel

Les traitements s'exécutent dans la même période. Il peut exister des liens faiblement synchrones.

Exemple : On a regroupé les actions de type initialisation dans une

même classe ; on a regroupé les actions déclenchées par un même événement dans une même classe

Commentaires et actions d'amélioration : Ce genre de cohésion est à éviter : il va poser des

problèmes de maintenance énormes. On découpe les traitements de la classe en sous - traitements centrés sur les données utilisées par ces traitements. On distribue les traitements dans des classes séparées associées aux données.

Niveau 3 : Procédural

Les traitements forment une procédure et sont appelés dans un ordre défini sans qu'il y ait un lien de cause à effet entre ces traitements.

Exemple :

On a regroupé dans une classe les opérations élémentaires qui entrent dans la composition de plusieurs calculs afin d'avoir un point d'appel unique.


On peut généralement toujours améliorer une classe de cohésion procédurale, en l'éclatant en une classe de cohésion communication et une classe de cohésion séquentielle.

Niveau 4 : Communication

Les traitements ont les mêmes paramètres d'entrée-sortie

Exemple :

On regroupe l’ensemble des fonctions trigonométriques dans une classe sans définir formellement les types de données associés aux domaine de définition


Pour améliorer une cohésion de communication, il faut compléter par une définition des données : par exemple définir le type angle, et lui associer les opérations trigonométriques.

Niveau 5 : Séquentiel

Les traitements se suivent : la sortie de l'un est l'entrée de l'autre

Exemple :

On crée une classe de contrôle pour synchroniser plusieurs autres classes indépendantes : acquérir une donnée brute, formater la donnée brute, calculer un terme correctif


si le déplacement de la synchronisation vers d'autres classes introduit un déséquilibre dans la responsabilité des classes, alors cette cohésion est correcte

s'il existe une ou plusieurs classes qui peuvent prendre en charge la synchronisation (cas de classes maîtres), alors on déplacera la synchronisation vers ces classes en supprimant la classe courante.

Niveau 6 : Type abstrait

La classe correspond à un type de donnée abstrait : c'est l'objet parfait

Exemple :

La classe String de Java qui cache l'implémentation des chaînes de caractères et fournit tous les services possibles pour la manipuler.

La classe Stack qui fournit les opérations de manipulation de pile


Une classe de cohésion type abstrait est l'objectif qu'il faut atteindre lors de la modélisation d'une abstraction homogène à une donnée.

Primitivité

La vue publique de chaque classe doit être primitive afin d 'améliorer maintenabilité, fiabilité et réutilisabilité

Avec une classe primitive, on ne peut pas simplifier l'interface fournie par la classe sans perdre une fonctionnalité proposée par l'objet (c'est à dire qu'il n'y a pas de redondance dans l'interface de l'objet).

On parle aussi de « primitivité de l'interface »

Primitivité : Intérêt

Une interface primitive simplifie l'utilisation des classes et donc joue favorablement sur la réutilisabilité

Une interface primitive simplifie les implémentationset donc la maintenabilité et la fiabilité (meilleure cohérence des services rendus)

La réutilisation d'une classe non primitive entraîne des incohérences qui nuisent à la compréhension : on peut avoir dans un même projet des réutilisations du même service sous des formes différentes (voir exemple)

Primitivité : Mesure

Pour mesurer la primitivité d'un objet, on essaie de simplifier l'interface de l'objet par itérations successives. On peut ainsi essayer de masquer des attributs, de supprimer des paramètres associés aux méthodes, de supprimer des méthodes elles-mêmes. Si l'on n'arrive pas à une primitivité de 100%, c'est que les méthodes associées ne sont pas les bonnes ; il faut alors essayer de la changer.

Pour la recherche de la primitivité, un point de vue externe est souvent nécessaire.

Lors de la recherche de la primitivité, on envisage l'interface d'un objet comme un tout.

Primitivité arbitrage : une classe primitive

Creer

InsererElementTete (element)

SupprimerElementTete

TeteListe

ElementSuivant

Liste

Dans ce premier exemple, une structure de liste est gérée entièrement au travers de la classe Liste.

La liste est supposée simplement chaînée.

L’interface de Liste est primitive :

On a uniquement les services de base pour créer, mettre à jour, supprimer des éléments et parcourir la liste.

Primitivité arbitrage : une façade non primitive

Creer



TeteListe

ElementSuivant

Liste

Dans ce second exemple, une façade a été créée afin de proposer des services complémentaires.

L ’interface de MaListe n ’est pas primitive, mais les nouvelles opérations fournies respectent les principes de fonctionnement d ’une liste

EstVide

SupprimerElements

RechercherElement (element)

Creer

EstVide



SupprimerElements

TeteListe

ElementSuivant


MaListe

Primitivité arbitrage : une façade non appropriée

Creer



TeteListe

ElementSuivant

Liste

Dans ce troisième exemple, une façade inappropriée a été créée.

En effet, les deux nouvelles opérations fournies ne respectent pas les principes de fonctionnement d ’une liste

DonneElement (index)

AffecteElement (index)

Ces deux opérations ne sont pas efficaces, et peuvent induire une utilisation d ’une structure de liste, à la place d’une structure de table.

TaListe

Creer

EstVide



SupprimerElements

TeteListe

ElementSuivant


DonneElement (index)

AffecteElement (index)

Couplage

Le couplage mesure le degré d'interconnexion entre les classes et les catégories. Un couplage exprime généralement une complexité des relations entre classes ou entre catégories : les liens sont nombreux, la nature des liens est complexe.

Le couplage entre deux catégories doit être minimal; Le couplage entre deux classes doit être minimisé

Un couplage réduit facilite les modifications locales à un composant : il améliore la maintenabilité.

Un couplage faible améliore la réutilisabilité.

Mesure du couplage

Pour évaluer le couplage, on peut définir une échelle du couplage, du plus fort au plus faible.

Niveau A : Contenu

Niveau B: Global

Niveau C : Contrôle

Niveau D : Structure

Niveau E : Données

Niveau A : Couplage de contenu

Le couplage de contenu est le couplage le plus fort.

Il met en lumière l'intrusion d'une classe dans le comportement d'une autre.

Il montre généralement de gros défauts de conception ou de réalisation qui peuvent être liés à un besoin d'optimisation et de configuration excessif.

Ce couplage peut être également dynamique : il se révèle à l'exécution du logiciel.

C ’est également souvent un problème de codage

Couplage de contenu : Exemples

référence à des données internes d'un autre composant (utilisation de friend par exemple, non-respect de l'encapsulation)

branchement direct d'un composant dans un autre (non respect de l'encapsulation du code, utilisation en C/C++ de SetJmp / LongJmp, etc.)

modification des instructions d'un composant par un autre(exportation de macros, abus de fonctions inline, etc..)

utilisation des mêmes constantes dans le code (partage de constantes de configuration, de switch de compilation)

non maîtrise des chaînes de responsabilités : traitement des exceptions non locales mal maîtrisé, messages entre fenêtres mal acheminés,

Amélioration du couplage de contenu

On améliore un couplage de contenu :

en respectant l'encapsulation existante concernant les données, les traitements, les exceptions

en hiérarchisant les événements et les exceptions

en clarifiant et simplifiant les chaînes de responsabilitémises en œuvre dans le logiciel (exception, messages, délégation)

en redécoupant les classes afin d'encapsuler les données de configurations et les macros

en interdisant certaines tournures de programmation (saut entre modules, classes amies, etc.)

Niveau B : Couplage global

le couplage global exprime un manque de structuration de la décomposition : on a décrit une structure à plat sans utiliser les hiérarchies ou l'encapsulation. Contrairement au couplage de contenu qui exprime une non-utilisation de l'encapsulation ou un détournement de l'encapsulation par des mécanismes intrusifs, le couplage global exprime le respect d'une mauvaise encapsulation.

Exemples

groupe de n modules partageant la même donnée commune

utilisation excessive de catégories de bas niveau

Amélioration du couplage global

On améliore un couplage global :

en isolant des classes à cohésion plus forte qui regroupent différemment les données et les traitements

en évitant les classes et catégories de type coïncidence

On pourra accepter le couplage global lorsque les données et les méthodes de bas niveau utilisées sont réutilisées ou vraiment globales au logiciel.

Niveau C : Couplage de contrôle

Le couplage de contrôle exprime la possibilité qu'a une classe de modifier le comportement d'une autre.

Contrairement au couplage de contenu qui exprime la possibilité de modifier le comportement d'une autre classe par un mécanisme intrusif, le couplage de contrôle exprime l'utilisation correcte des méthodes d'une classe pour modifier son comportement.

Exemples :

exportation d'informations destinées à contrôler la logique interne d'un composant

utilisation de données externes pour contrôler l'état d'une classe

Amélioration du couplage de contrôle

On améliore un couplage de contrôle :

en séparant dans les données de la classe celles qui sont associées à l'état de la classe, des autres données membres

en cachant les données associées à l'état de la classe

en décrivant des machines à états rigoureuses

en créant une classe de contrôle

Niveau D : Couplage de Structure

Le couplage de structure exprime la communication vers d'autres classes de la structure de la classe.

Exemples :

exportation de données membres à structure

exportation de types

exportation d'énumérations

Amélioration du couplage de structure

On améliore un couplage de structure :

en encapsulant les structures de donnée, les types, les énumérations

en décrivant des méthodes d'accès primitives aux champs éléments des données membres à structure complexe

On pourra dans certains cas accepter le couplage par énumérations : l'énumération devra dans ce cas être un concept commun aux classes ou catégories couplées.

Niveau E : Couplage de Données

Le couplage de donnée est le couplage minimal. C'est le résultat qu'il faut atteindre.

Exemple :

les données membres de la classe sont masquées

les méthodes de la classe utilisent des paramètres qui ont des types standard

Complétude

Une classe réutilisable doit être complète

L'interface fournie par l'objet est complète en ce sens qu'elle peut être réutilisée telle quelle dans un autre projet de type projet fils, projet filière commune, ou tout autre projet.

Pour mesurer la complétude d'un objet, on analyse l'interface proposée par l'objet du point de vue de sa réutilisation potentielle dans un autre projet.

Cette analyse peut être conduite par une personne hors du projet, adoptant le point de vue d'un réutilisateur.

Héritage : Est un

L'héritage doit exprimer une relation conceptuelle "est un". ou "est une sorte de".

En particulier ne pas confondre héritage et agrégation ("se compose de").

L'utilisation à tort de l'héritage pour spécifier d'autres types de relation, conduit à une mauvaise compréhension de la modélisation et limite les possibilités de réutilisation.

Héritage : Restriction

Dans une classe descendante, ne pas restreindre les propriétés des classes ancêtres. Une classe descendante peut redéfinir des méthodes

publiques de la classe ancêtre (dans le but d'optimiser l'implantation ou spécialiser le comportement) et étendre l'interface publique par de nouvelles méthodes.

Par contre, il est interdit de concevoir des classes héritières qui suppriment des méthodes publiques des classes ancêtres ou masque des attributs

Il doit être possible d'utiliser n'importe quelle classe à la place de sa super-classe.

Les clients d'une hiérarchie d'héritage doivent pouvoir développer du code qui s'applique à toutes les classes filles sans provoquer d'erreur dynamique.

Restriction : Exemples

Soit une classe "Oiseau" avec la méthode "Vole()".

Il est déconseillé de faire hériter la classe "Manchot" de cette classe "Oiseau" (chacun sait que les manchots ne volent pas).

Il est préférable de créer une classe "OiseauNonVolant" dont on dérivera "Manchot".

Il est déconseillé de créer une classe Carré qui hérite d'une classe rectangle en imposant la contrainte longueur = largeur.

Restriction : Exemples

a

b

c

Racines (r1,r2)

Optimum ()

Polynome 2nd Degré

Racine (r)

Polynome 1er Degré

La définition d ’un polynome du premier degré comme un polynome du deuxième degré (avec a = 0) est une solution qui restreint les propriétés du polynome du 2nd degré.

La recherche des racines peut conduire à une erreur si l ’implémentation de polynôme 2nd degré n ’est pas robuste (a=0).

De plus, Optimum n ’existe pas pour un polynome de 1er degré (un polynome du 1er degré est strictement monotone, sauf si b est nul)

UML

Modélisation Physique

Principe de la modélisation physique

Il s’agit de décrire la solution Sous forme physique

Fichiers de développement

Machines de développement

Fichiers d’exploitation

Machines d’exploitation (machines cibles)

Réseaux et autres périphérique

Cette partie d’UML est propre donc au logiciel

Elle donne lieu à deux types de vue La vue des composants

Vue du logiciel en développement

La vue de déploiement Vue du logiciel en exploitation

Vue des composants

La Vue des composants

La vue des composants présente la distribution du logiciel en composants (fichiers de code), librairies statiques et dynamiques et exécutables

Un composant à un nom, et un type : le type est par exemple source, librairie, etc.

Chaque composant à une interface : un diagramme de composants peut montrer les liens de dépendances entres composants.

Un composant réalise des objets et / ou des services décrits dans l'activité de conception : cette relation de traçabilité particulière s 'appelle la relation de réalisation.

Un composant peut décrire graphiquement les objets et classes qu'il implémente.

La Vue des composants

Composant 1

Composant 2

Composant utilisé Service 1

Service 2Objet 1

Objet 2 : Classe

Vue de déploiement

La vue de déploiement

La vue de déploiement montre le déploiement du logiciel sur le matériel

les machines,

les processeurs,

les calculateurs,

les disques,

les mécanismes de transport,

les tâches,

les fils.

Capacités des outils UML

Les vues déploiement sont généralement très limitées par les outils UML

Selon le contexte et le besoin, on pourra compléterle formalisme ; par exemple :

créer des stéréotypes

décider de représenter manuellement la vue du déploiement en décidant d'éléments de modélisation propre

Exemples de stéréotypes

Disques Listing

Bande

Machine

Cpu

Cpu

Thread

Processus

Mémoire (RAM)

Mémoire (Flash)

Exemple de diagramme de déploiement

C:

LPT1

X-Tape

ATBxx

CpuAction

FABRIQUER

XRAM

8000:837Fh

Eflash

0000:7FFFh

Sauver

Virtualité Réelle thierry.leydier@gmail · Tour d ’horizon rapide des diagrammes UML ......

Documents

Transcript of Virtualité Réelle thierry.leydier@gmail · Tour d ’horizon rapide des diagrammes UML ......