Processus unifié de développement orienté objet de logiciels :Utilisation du langage de

modélisation unifié

(UML : Unified Modeling Language)

Jean-Marc CIEUTAT

Enseignant-Chercheur ESTIA/LIPSI

Plan

• À quoi sert une méthode de développement de logiciels ?

• Les objets et les classes

• La genèse d'un standard : UML

• La phase d'analyse :- Les cas d'utilisation- Les diagrammes de séquence- Les diagrammes de collaboration- Les diagrammes de classes- Les diagrammes d'états-transitions

Pourquoi une méthode de développement de logiciels ?

Optimisant

Encadré

Défini

Reproductible

Initial

« Une méthode est une démarche reproductible permettant d’obtenir des résultats fiables »

Le Capability Maturity Model (CMM) défini par le Software Engineering Institute (SEI)

Pourquoi l’approche objet ?

• Représentatif de la réalité

• Construction itérative (évolutif)

• Réutilisation (effort de codage et de tests en moins)

• Simplicité (nombre d’instructions par méthode)

Le cycle de vie itératif

Codage

Tests

Conception

n foisAnalyse

Grâce à la programmation orientée objet, on ajoute des propriétés aux classes déjà introduites, ou on ajoute de nouvelles classes, sans avoir à modifier l'existant

L’approche orientée objet

Illustration de Jean-Marc Estay (IMA)

Les objets et les classes

• Le terme Orienté Objet signifie l'organisation du logiciel en un ensemble d'objets incorporant à la fois les structures de données et le comportement. Alors que la programmation conventionnelle n'établit qu'une faible connexion entre structure de données et comportement.

• C'est la classe qui sert à regrouper sous un même terme générique les objets partageant la même structure de données et le même comportement. On dit qu'un objet est une instance d'une classe.

• La classe est séparée en deux parties :- la spécification de la classe qui décrit le domaine de définition et les propriétés

des instances de la classe- la réalisation de la classe qui décrit comment la spécification est réalisée

Que sont les objets ?

• Les objets du monde réel nous entourent ; ils naissent, vivent et meurent. En orienté objet, ils sont alloués, changent d'états et se comportent en conséquence, et sont désalloués. Ce sont les instances des classes.

• Les objets informatiques définissent une représentation simplifiée des entités du monde réel. Ils peuvent représenter des entités concrètes (avec une masse), et même des êtres vivants, ou des entités abstraites (concept).

Les objets sont des abstractions

• Une abstraction est un résumé, un condensé qui met en avant les caractéristiques essentielles et qui dissimulent les détails. Les caractéristiques essentielles d'un objet sont celles qui sont précisées lors de la spécification de la classe dont il est une instance. Les détails, qui sont les détails d'implémentation, sont précisés au moment de la définition des opérations de la classe.

• Une abstraction se définit par rapport à un point de vue. Quel sont les utilisateurs en présence et quel est leur point de vue ?

Exemples de caractéristiques

Pour une voiture : la marque, la puissance, la couleur, le nombre de places assises, …

Le point de vue est exprimé par qui ? Le propriétaire, le mécanicien, le vendeur, …

Des caractéristiques aux attributs et aux méthodes

• Approche fonctionnelle :- Créer une structure qui représente un nombre complexe- Créer une fonction qui retourne un complexe à partir de sa partie

imaginaire et de sa partie réelle passées en arguments- Créer une fonction qui additionne deux nombres complexes- ...

• Approche objet :- Créer une classe NombreComplexe qui contient :

. Ses attributs : partie réelle et partie imaginaire

. Ses méthodes : création à partir de sa partie réelle et de sa partie imaginaire, s’additionne à un autre nombre complexe, ...

Du type abstrait à la classe

• La classe Point

• La classe Vecteur

• La classe Polygone

• La classe Pile

• La classe File

• ...

Les caractéristiques fondamentales des objets

• L'identité

• L'état

• Le comportement

L'identité

• Chaque objet a sa propre identité ; deux objets sont distincts même si toutes les valeurs de leurs attributs sont identiques. Cela se comprend aisément puisque la place mémoire occupée par chaque objet est distincte.

• Pour reconnaître un objet et lever toute ambiguïté, on utilise, en général, un identifiant particulier : notre numéro de sécurité sociale par exemple, le numéro de la plaque d'immatriculation, une clé utilisée dans une base de données, …

L'état et le comportement

Atterrir

Décoller

Tour de contrôle

Avion

en vol

Avion

au sol

Les attributs d'un objet peuvent contenir différentes valeurs. Ce sont les différents états que peut prendre l'objet.

Le comportement regroupe toutes les compétences d'un objet, sous la forme d'opérations. C'est l'ensemble des actions et des réactions d'un objet.

L'état et le comportement sont liés :- le comportement dépend de l'état- l'état est modifié par le comportement

Communication entre objets

• Une application, en orienté objet, est une société d'objets collaborant.

• Comment, dans ces conditions, sont réalisées les fonctions de l'application ? Ce sont les objets, qui travaillent en synergie, pour parvenir à les réaliser.

• Donc, l'achèvement d'une tâche par une application repose sur la communication entre les objets qui la composent. L'unité de communication entre les objets est le message.

• Plus spécialisé et plus coopératif que l'objet, l'agent (implémentation partielle des agents possible en Java). L'agent est plus adapté que l'objet pour représenter des êtres intelligents.

Les objets ne vivent pas en ermites

Objet 1

Objet 3 Objet 4

Objet 2

Message B

Message A

Message C

Message D

Message E

Le concept de message

• Il existe cinq catégories principales de messages :

– les constructeurs qui créent des objets

– les destructeurs qui détruisent des objets (pas en Java)

– les sélecteurs qui renvoient tout ou partie de l'état d'un objet

– les modificateurs qui changent tout ou partie de l'état d'un objet

– les itérateurs qui visitent l'état d'un objet ou le contenu d'une structure de données qui contient plusieurs objets

La programmation orientée objet

• On dit d'un langage de programmation qu'il est un langage orienté objet quand il supporte les mécanismes :

- d'héritage

- de polymorphisme

- d'encapsulation

• Smalltalk, Eiffel, C++, Java, ...

L’héritage

• Les hiérarchies de classes (classification) permettent de gérer la complexité en ordonnant les objets au sein d’arborescence de classes d’abstraction croissante. Les classes descendantes héritent des propriétés des classes ancêtres (exemple : vertébrés, mammifères, hominidés, hommes).

généraliser spécialiser

Une classe descendante (une sous-classe) peut être également vue comme un sous-type du type défini par la classe ancêtre (la sur-classe) (exemple : ensembles et sous-ensembles mathématiques).

Exemples d’héritage

Véhicule

Bateau

Navire

Navire de

guerre

Navire de

pêche

Véhicule aérien

Véhicule roulant

Avion HélicoptèreVoiture Camion

Autre exemple d’héritage

Bicyclette

VTT VTC VéloDeCourse VéloDeVille

Héritage et redéfinition

• Une sous-classe peut spécialiser les fonctionnalités de sa super-classe en définissant de nouveaux attributs et/ou de nouvelles méthodes dont elle hérite de deux manières :

- en remplaçant complètement la méthode héritée par une nouvelle implémentation

- en spécialisant la méthode héritée en proposant une nouvelle implémentation qui réutilise celle héritée

• Exemple : calculer la surface d’un polygone, d’un quadrilatère, d’un triangle, d’un carré, d’un rectangle, d’un triangle isocèle, d’un triangle rectangle, ...

Redéfinition : réutilisation

Etudiant

NomPrenom

Age

Affiche()

EtudiantSportif

SportPratique

Affiche()

Redéfinition : substitution

Polygone

CalculSurface()

Quadrilatere

CalculSurface()

Rectangle

CalculSurface()

Carre

CalculSurface()

Triangle

CalculSurface()

TriangleRectgle

CalculSurface()

TriangleIsocele

CalculSurface()

Le polymorphisme

• Le polymorphisme signifie qu'une même opération peut se traduire différemment selon l'objet sur laquelle elle s'applique : Capacité d’un objet à prendre plusieurs formes.

• On parle également de liaison dynamique. Le polymorphisme associé à la liaison dynamique offre une plus grande simplicité du code (plus besoin de distinguer les cas en fonction des classes) et une plus grande facilité d’évolution du code (les programmes sont plus facilement extensibles comme on peut redéfinir une opération appartenant à une classe dont on hérite, appartenant à une sur-classe).

Liaison dynamique : revenons à l’exemple précédent

Polygone

CalculSurface()

Quadrilatere

CalculSurface()

Rectangle

CalculSurface()

Carre

CalculSurface()

Triangle

CalculSurface()

TriangleRectgle

CalculSurface()

TriangleIsocele

CalculSurface()

Polymorphisme : classes abstraites

• Pour exploiter pleinement le polymorphisme, il est courant de définir des classes dont le seul rôle est de spécifier une interface (un ensemble de méthodes) commune pour toutes les classes qui en seront dérivées.

• Dans de telles classes, les méthodes qui servent à définir cette interface commune sont le plus souvent muettes (elles ne contiennent pas de code effectif).

L’encapsulation

• Il existe trois niveaux de visibilité :

- privé

- protégé

- public

• Cela permet de limiter les effets de bord.

Les autres différences

• La surcharge (prototype de fonctions : plusieurs méthodes portant le même nom à l’intérieur d’une classe)

• Les pré-conditions, les post-conditions, les invariants

• La généricité (« template » en C++)

• Le traitement des situations exceptionnelles (« throw », « try » et « catch » : lever et attraper une exception)

La genèse d'un standard : UML Standardisation par l'OMG UML 2.0depuis 2003

Soumission à l'OMG UML 1.0en Janvier 97 Version bêta UML 0.9 Consortiumen Juin 96 Draft en 95 Méthode unifiée 0.8 OOSE

OMT BOOCH

NB : La notation UML est un langage de modélisation objet et non pas une méthode objet. UML peut se substituer aux méthodes Booch, OMT (Object Modelling Technique) et OOSE (Object Oriented Software Engineering) sans perte d’informations.

La phase d'analyse

• Décrire les cas d'utilisation.

• Pour chaque cas d'utilisation, réaliser de un à n diagrammes d’interactions (les diagrammes de séquence en premier pour statuer sur les fonctionnalités avec le client ; puis, passer aux diagrammes de collaboration pour continuer l’analyse avec l’équipe projet).

• À chaque diagramme de collaboration correspond une ébauche de diagramme de classes. Préciser lors de la création d’une classe à quel package elle appartient.

• Faire la synthèse des diagrammes de classes pour un package donné.

• Pour chaque classe du diagramme de classes, faire un diagramme d'états-transitions (optionnel).

Les apports de la modélisation visuelle

• Meilleure appréhension des besoins

• Facilite la compréhension du problème

• Facilite la communication entre les personnes (client, experts du domaine, analystes, concepteurs, ...)

• Support pour le raisonnement

• Améliore la lisibilité des schémas de conception

• Prépare la documentation et les programmes

• Facilite la maintenance

Guide pour appliquer la méthode

• Recueillir les besoins de l'utilisateur final

• Adopter le point de vue de l'utilisateur final

• Penser à la réutilisation

• Ne préciser que les caractéristiques utiles des classes

• Généralement dans le cahier des charges, les noms sont des classes ou des attributs de classes et les verbes sont des méthodes

• Raffiner la modélisation en éliminant les redondances dues aux synonymes, les informations dérivées qui peuvent être déduites, et en s'efforçant de ne pas introduire de détails d'implémentation

Les cas d’utilisation

Système

Cas d'utilisation X

Cas d'utilisation Y

Conduire

Réparer

Vendre

Client

Mécanicien

Vendeur

Les cas d'utilisation décrivent, sous la forme d'actions et de réactions, le comportement d'un système du point de vue de l'utilisateur, encore appelé acteur.

On recense, de la sorte, l'ensemble des fonctionnalités d'un système en examinant les besoins fonctionnels de chaque acteur.

Les acteurs dans les cas d'utilisation

• Il existe 4 grandes catégories d'acteurs :

- les acteurs principaux. Cette catégorie regroupe les personnes qui utilisent les fonctions principales du système. Dans le cas d'un distributeur de billets, il s'agit des clients.

- les acteurs secondaires. Cette catégorie regroupe les personnes qui effectuent des tâches administratives ou de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la personne qui recharge la caisse du distributeur.

- le matériel externe. Cette catégorie regroupe les dispositifs matériels autres que les ordinateurs comme les périphériques. Dans le cas d'un distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la trieuse de billets.

- les autres systèmes. Cette catégorie regroupe les systèmes avec lesquels le système interagit. Dans le cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère l'ordinateur central qui relie tous les distributeurs.

Les relations entre les cas d'utilisation

Retrait au guichet

Client distant

Client local

Identification

Retrait au distributeur

<< Etend >>

<< Utilise >>

Cas d'utilisation

Déclenche

Cas d'utilisation B

<< Utilise >>

Cas d'utilisation A

Cas d'utilisation A Cas d'utilisation B

<< Etend >>

relation de communication avec le système

relation d'utilisation entre cas

relation d'extension entre cas

Description des cas d'utilisation

• On précise le contenu d'un cas d'utilisation en déroulant tous les scénarios possibles.

• Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation. En pratique, on ne décrit que les scénarios les plus représentatifs.

• On peut décrire un scénario à l'aide d'un diagramme de d’interaction (diagramme de séquence, diagramme de collaboration) où un acteur est un objet particulier.

Les diagrammes de séquence

Tour de contrôle Roissy

Avion A340-002

Piste A1Avion A340-001

Demande décollage

Demande décollage

Attente décollage

Réservation piste

Confirmation

Libération piste

Fin décollage

Autorisation décollage

Les diagrammes de séquence montrent la succession des interactions entre les objets dans le temps.

On distinguer les messages synchrones ( ) des messages asynchrones ( ) pour lesquels l'émetteur n'est pas bloqué et peut continuer son exécution.

Les spécificités des diagrammes de séquence

Un objet

Message réflexif

Un objet

Un autre objetCréer

Détruire

Un objet peut s'envoyer un message

Un message peut entraîner la création ou la destruction d'objets

L'ajout de pseudo code dans les diagrammes

Objet A

[X] Message

Objet B Objet C

[non X] Message

Objet A

Message

Objet B Objet C

Message

if X

else

end if

Les diagrammes de collaboration

:Personne :Ascenseur

:Cabine

1: Venir me chercher au RDC

2: Ajouter destination RDC

1: Entrer dans la cabine

3: Ouvrir

:Personne :Cabine

:Lumière

:Porte

2:Allumer

Dès lors que les besoins utilisateurs ont été recensés et validés, il s'agit maintenant de mettre en œuvre le système qui va satisfaire ces besoins utilisateurs. La transition est assurée par les diagrammes de collaboration qui montrent les interactions entre les objets du système.

Une interaction est réalisée par un groupe d'objets qui collaborent en échangeant des messages.

Le temps est matérialisé ennumérotant les messages.

Les spécificités des diagrammes de collaboration

A B {nouveau}

C {transitoire}

D {détruit}

Instituteur

:Elève

*[tous] : Debout

Durée de vie des objets

Cardinalité

A

B

A.1,B.3 / Message

Plusieurs flots d’exécution

A

:X

*[i := 1..n] : Message

Clause d’itération

Exemples de messages

4 : Afficher (x,y) // message simple

4.2 : âge := Soustraire (Jour, DateNaissance) // message imbriqué

6.2 : [Age >= 18] Voter () // message conditionnel

Guide méthodologique

• Les diagrammes de collaboration sont une extension des diagrammes objets, d'où une cohésion forte de la méthode.

• Dès qu'un diagramme de collaboration est établi, on réalise une ébauche du diagramme de classes correspondant. Pour que cela soit constructif, il faut préciser les attributs, les opérations et la cardinalité des associations entre les classes au fur et à mesure qu'on les met en évidence.

• Sur le plan de l'architecture logicielle, il faut ensuite déterminer à quel package appartient une classe (IHM, objets du domaine, utilitaires, …), de manière à pouvoir faire une synthèse des ébauches de classe par package.

• Les packages offrent un mécanisme général pour la partition des modèles et le regroupement des éléments de modélisation.

Les diagrammes de classes

Classe Objet

Association Lien

Relie Relie

Diagramme de classes

Diagramme d'objets

Une classe décrit un ensemble d'objets ayant des propriétés similaires (attributs), des comportements communs (opérations) et partageant les mêmes liens avec les autres objets.

Exemple de diagramme de classes

départarrivée

composé deVol

NuméroEscaleNom

Heure de départ

AéroportNom

Paris_Nouméa : Vol

AF-5177

Paris_Singapour : Escale

23h15

Singapour Sydney : Escale

10h50

Sydney_Nouméa : Escale

15h30

Roissy : Aéroport

Shangi : Aéroport

Sydney_Airport : Aéroport

Nouméa_Airport : Aéroport

Les attributs et les méthodes

Syntaxe des attributs et des méthodes :

Nom_Attribut : Type_Attribut = Valeur_Initiale

Nom_Méthode (Nom_Argument : Type_Argument = Valeur_Par_Défaut, …) : Type_Retourné

Aéroport

VilleNom

OuvrirEmbarquement()FermerEmbarquement()

nom

attributs

méthodes

Les attributs et les méthodes

• Attributs - Un attribut est une donnée propre aux objets d'une classe particulière- Chaque nom d'attribut est unique à l'intérieur d'une classe- Chaque attribut a une valeur pour toute instance.

• Méthodes- Une méthode est une fonction ou transformation qui peut s'effectuer sur

les objets d'une classe ou être effectuée par ces objets- Tous les objets partagent les mêmes méthodes

• Les règles d’encapsulation (de visibilité) :- public qui rend l'élément visible à tous les éléments de la classe (+)- protégé qui rend l'éléments visibles aux classes dérivées de la classe (#)- privé qui rend l'élément visible à la classe seule (-)

Les stéréotypes de classes

Table générique

Elément

<<Utilitaire>>

Math

Les classes paramétrables (généricité)

Les classes utilitaires (modules non instanciables)

Les associations

est employé par

est employeur de

Compagnie Aérienne

Personneemploie

Compagnie Aérienne

Personne

Avion Personne

est piloté par

transporte

Une association décrit un groupe de liens ayant une structure et une sémantique commune. Elles expriment les relations structurelles entre les classes.

Cardinalité des associations

1 Un et un seul

0..1 Zéro ou un

M..N De M à N (entiers naturels)

* De zéro à plusieurs

0..* De zéro à plusieurs

1..* D'un à plusieurs

La cardinalité spécifie combien d'instances d'une classe peuvent être en relation avec une instance de la classe associée. Elle est à préciser pour chaque rôle.

Multiplicité des associations

1

1

0..*0..*10..*

Diplôme

Mention

Etudiant Travail

Chambre

Numéro

{Ou-exclusif}Université Personne

enseignants

Etudiants

Spécification de contraintes

Les types d'associations : L'agrégation

Classe A Classe B

Une agrégation représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l'autre extrémité. On applique les critères suivants :

- une classe fait partie d'une autre classe,

- les valeurs d'attributs d'une classe se propageant dans les valeurs d'attributs d'une autre classe,

- une action sur une classe implique une action sur une autre classe,

- les objets d'une classe sont subordonnés aux objets d'une autre classe.

La relation de composition

Voiture Moteur

Cylindre Carburateur

Les types d'associations : la généralisation

Personne

Personne naviguante

Personne au sol

Les descendants héritent des propriétés de leurs ancêtres. On va du général au particulier.

Le polymorphisme

Personne

CalculPrime()

Personne naviguant

CalculPrime()

Personne au sol

CalculPrime()

Classe AbstraiteLes classes abstraites : ce sont des classes qui n'ont pas d'instances mais dont les descendants ont des instances

L'héritage multiple

Avion

Hydravion Moyen Courrier

Navire

Cargo

Les diagrammes d'états-transitions

Cas d'utilisation

Diagrammes d'interactions (diagrammes de séquence ou

diagrammes de collaborations)

Diagrammes de classes

Diagrammes d'états-transitions

Validation de la phase d'analyse

Le formalisme retenu est celui des statecharts : Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science of Computer programming vol. 8.

Description des diagrammes d'états-transitions

0..11

Classe A AutomateLe comportement des objets d'une classe est décrit de manière formelle en termes d'états et d'événements, au moyen d'un automate relié à la classe considérée.

Un état

Un autre état Etat final

Les états

Le passage d'un état à un autre s'effectue lorsqu'une transition est déclenchée par un événement qui survient dans le domaine du problème.

Exemple de diagramme d'états-transitions

Atterrit

Fin de service

S'écrase

Décolle

Mis en service

Au sol

En vol

Etat initial

Etat final

Les événements

Embauche

Perte d'emploi

Plus de 60 ans

Plus de 60 ans

En activité

A la retraite

Au chômage

Un événement est par nature une information instantanée qui doit être traitée sans attendre. Il sert de déclencheur pour passer d'un état vers un autre. Sa syntaxe est :

Nom_Evénement (Nom_Paramètre : Type, …)

Transition d'état

Un objet Un autre objet

La réponse

La question

Autorisation décollage [check-list avion OK] / décoller

Au sol En vol

La communication entre automates peut également être de type synchrone

Les gardes, les actions et les activités

Points d'exécution des opérations

En activité

entry : Op2do : Op3

exit : Op4on UnEvt : Op5

/ Op1

/ Op6

l'action associée à la transition d'entrée (Op1)

l'action d'entrée de l'état (Op2)

l'activité dans l'état (Op3)

l'action de sortie de l'état (Op4)

l'action associée aux événements internes (Op5)

l'action associée à la transition de sortie de l'état (Op6)

La généralisation d'états

Arrêt Fin embarquement

Entretien Opérationnel

Fin de service

Atterrit Décolle

Mis en service

En vol

Immobilisé

Roulement

Embarquement

Au sol

Crash

L'agrégation d'états

Avion

Moteur Train d'atterrissage

Décollage

Sorti Entré

Max Croisière

En vol

Guide méthodologique

• Les diagrammes d'états-transitions permettent d'effectuer une vérification du système sous forme textuelle. On déclenche un événement, et on observe les changements d'états des objets du système. En cas d'incohérence, il faut recommencer l'analyse.

• Dans un contexte temps-réel, il est possible d'utiliser des "run-time" pour générer un prototype du système.