Processus unifi de dveloppement orient objet de logiciels : Utilisation du langage de modlisation un

1
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

2
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

3
Pourquoi une méthode de développement de
logiciels ?
Une méthode est une démarche reproductible
permettant dobtenir des résultats fiables Le
Capability Maturity Model (CMM) défini par le
Software Engineering Institute (SEI)
4
Pourquoi lapproche objet ?

• Représentatif de la réalité
• Construction itérative (évolutif)
• Réutilisation (effort de codage et de tests en
  moins)
• Simplicité (nombre dinstructions par méthode)

5
Le cycle de vie itératif
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
6
Lapproche orientée objet
Illustration de Jean-Marc Estay (IMA)
7
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

8
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).

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

10
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,
11
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, sadditionne à
  un autre nombre complexe, ...

12
Du type abstrait à la classe

• La classe Point
• La classe Vecteur
• La classe Polygone
• La classe Pile
• La classe File
• ...

13
Les caractéristiques fondamentales des objets

• L'identité
• L'état
• Le comportement

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

15
L'état et le comportement
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.
Avion en vol
Atterrir
L'état et le comportement sont liés - le
comportement dépend de l'état - l'état est
modifié par le comportement
Décoller
Avion au sol
16
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.

17
Les objets ne vivent pas en ermites
18
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

19
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, ...

20
Lhéritage

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

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).
21
Exemples dhéritage
22
Autre exemple dhéritage
23
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 dun polygone, dun
  quadrilatère, dun triangle, dun carré, dun
  rectangle, dun triangle isocèle, dun triangle
  rectangle, ...

24
Redéfinition  réutilisation
25
Redéfinition substitution
26
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é dun 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).

27
Liaison dynamique  revenons à lexemple précédent
28
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).

29
Lencapsulation

• Il existe trois niveaux de visibilité 
• privé
• protégé
• public
• Cela permet de limiter les effets de bord.

30
Les autres différences

• La surcharge (prototype de fonctions  plusieurs
  méthodes portant le même nom à lintérieur dune
  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)

31
La genèse d'un standard UML
Standardisation par l'OMG UML 2.0 depuis
2003 Soumission à l'OMG UML 1.0 en Janvier
97


Version
bêta UML 0.9 Consortium en 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
dinformations.
32
La phase d'analyse

• Décrire les cas d'utilisation.
• Pour chaque cas d'utilisation, réaliser de un à n
  diagrammes dinteractions (les diagrammes de
  séquence en premier pour statuer sur les
  fonctionnalités avec le client  puis, passer aux
  diagrammes de collaboration pour continuer
  lanalyse avec léquipe projet).
• À chaque diagramme de collaboration correspond
  une ébauche de diagramme de classes. Préciser
  lors de la création dune 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).

33
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

34
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

35
Les cas dutilisation
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.
36
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.

37
Les relations entre les cas d'utilisation
relation de communication avec le
systèmerelation d'utilisation entre
cas relation d'extension entre cas
ltlt Utilise gtgt
Cas d'utilisation B
Cas d'utilisation A
38
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 dinteraction (diagramme de
  séquence, diagramme de collaboration) où un
  acteur est un objet particulier.

39
Les diagrammes de séquence
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.
40
Les spécificités des diagrammes de séquence
Un objet peut s'envoyer un message
Un message peut entraîner la création ou la
destruction d'objets
41
L'ajout de pseudo code dans les diagrammes
42
Les diagrammes de collaboration
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é
en numérotant les messages.
43
Les spécificités des diagrammes de collaboration
Plusieurs flots dexécution
Durée de vie des objets
Cardinalité
Clause ditération
44
Exemples de messages

• 4 Afficher (x,y) // message simple
• 4.2 âge Soustraire (Jour, DateNaissance) //
  message imbriqué
• 6.2 Age gt 18 Voter () // message
  conditionnel

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

46
Les diagrammes de classes
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.
47
Exemple de diagramme de classes
48
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é

49
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 dencapsulation (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 (-)

50
Les stéréotypes de classes
Les classes paramétrables (généricité)
Les classes utilitaires (modules non
instanciables)
ltltUtilitairegtgt Math
51
Les associations
Une association décrit un groupe de liens ayant
une structure et une sémantique commune. Elles
expriment les relations structurelles entre les
classes.
52
Cardinalité des associations
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.
53
Multiplicité des associations
Spécification de contraintes
54
Les types d'associations L'agrégation

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

55
La relation de composition
56
Les types d'associations la généralisation
Les descendants héritent des propriétés de leurs
ancêtres. On va du général au particulier.
57
Le polymorphisme
Les classes abstraites ce sont des classes qui
n'ont pas d'instances mais dont les descendants
ont des instances
58
L'héritage multiple
59
Les 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.
60
Description des diagrammes d'états-transitions
Le 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.
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.
61
Exemple de diagramme d'états-transitions
62
Les événements
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, )
63
Transition d'état
La communication entre automates peut également
être de type synchrone
Les gardes, les actions et les activités
64
Points d'exécution des opérations
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)
65
La généralisation d'états
66
L'agrégation d'états
67
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.