UML

1
(No Transcript)
2
Unified Modeling Language

• UML que l'on peut traduire par langage de
  modélisation unifié est une notation permettant
  de modéliser un problème de façon standard.
• Ingénierie du logiciel

3
Survol de UML

• Modélisation orientée objet
• Couvre toutes les phases d'un projet de lanalyse
  des besoins jusquau déploiement.
• Une synthèse (partielle) de 25 ans de recherche
  en modélisation
• Modélisation selon trois axes
• Structurel
• Comportemental
• Architectural

4
Ingénierie Électrique
Ingénierie du Bâtiment
Ingénierie Mécanique
Ingénierie Logicielle
5
Ingénierie du logiciel orienté-objet
6
Quand faut til modéliser ?

• La niche, la maison familiale et l'immeuble
• (Booch, Jacobson, Rumbaugh)
• pour construire une niche quelques planches, des
  clous, un marteau et quelques outils.
• une maison familiale plans généraux, plans
  d'exécution détaillés (pièces, électricité,
  plomberie, chauffage)
• un immeuble planification détaillée, nombreux
  plans et études

7
Exemple Windows Vista
65 millions de lignes de code, 6 années de
développement, 9000 développeurs (54 000 années
développeurs) http//www.clubic.com/article-66145-
1-microsoft-windows-vista-rtm-dossier.html sur
les vingt années d'existence de Windows, Vista
aura été le système d'exploitation dont le cycle
de développement fut le plus long ! Et pour
cause, puisqu'après avoir démarré le
développement de Longhorn en 2001, Microsoft a du
remettre à plat l'intégralité du projet en 2004,
réalisant alors que celui-ci était par trop
complexe et tentaculaire. En repartant de zéro,
Microsoft a entièrement révisé son cahier des
charges en supprimant au passage certaines
fonctionnalités pourtant très attendues de Vista
on pense bien sûr au système de fichiers WinFS
qui est ainsi tombé purement et simplement aux
oubliettes. C'est au maître d'uvre de Vista, Jim
Allchin, que l'on doit cette décision,
certainement très difficile à prendre vu ses
implications pour l'époque. Lorsque, fin 2004,
les équipes à la tête de Microsoft décident de
repartir de zéro, c'est pratiquement tout le
travail des 9 000 développeurs mobilisés sur
Windows Vista qui est à recommencer
8
Qu'est-ce qu'un modèle ?
Un modèle est une simplification de la réalité
9
Pourquoi modéliser ?

• Mieux comprendre le système en développement
• Objectifs
• nous aider à le visualiser tel qu'il est ou tel
  qu'il devrait être.
• spécifier la structure et le comportement d'un
  système.
• avoir un "patron" pour guider la construction du
  système.
• documenter les décisions qui ont été prises.
• Nous construisons des modèles de systèmes
  complexes parce qu'on nous sommes incapables
  d'appréhender ces systèmes dans leur intégralité.

10
Principes de modélisation

• Le choix de quels modèles nous créons a une
  influence profonde sur la manière d'attaquer le
  problème et de former une solution.
• Tout modèle peut être exprimé à différents
  niveaux de précision.
• Les meilleurs modèles sont bien reliés à la
  réalité.
• Un seul modèle ne suffit pas. Tout système un peu
  compliqué sera mieux appréhendé à travers un
  ensemble de modèles presque indépendants.

11
Problématique

• Taille et complexité des logiciels
• Complexité fonctionnelle
• Évolutions technologiques permanentes
• Complexité architecturale  Client/serveur,
  Intranet, Corba (Common Object Request Broker
  Architecture), Systèmes distribués

12
Solutions

• Découpage du processus de développement 
• phase analyse 
• phase réalisation  aspects technologiques et
  architecturaux.
• Découpage du système en sous systèmes
• diminution de la complexité
• répartition du travail et réutilisation .
• Utilisation dune technologie de haut niveau
• découpage naturel du système .

13
La modélisation orientée objet

• Approche centrée sur les objets et classes
  d'objets.
• En gros
• un objet est une  chose  (du vocabulaire du
  problème à résoudre)
• une classe est un ensemble d'objets ayant des
  propriétés communes.
• les objets peuvent être concrets ou abstraits

14
Historique et contexte

• fin 1960 langages de programmation orientés
  objet
• mi 1970 - fin 1980 langages de modélisation
  orientés objet ("entity-relationship", ...)
• vers 1995 50 méthodes orientées objet
• 1996 des leaders du marché G. Booch, I. Jacobson
  J.Rumbaugh unifient leurs langages pour donner
  Unified Modeling Language (UML)

15
Cycles de développement du logiciel
16
les différentes étapes du développement logiciel

• Expression des besoins
• Spécification
• Analyse
• Conception
• Implémentation
• Tests de vérification
• Validation
• Maintenance et évolution

17

• L Expression des besoins
• - Interview de lexpert métier 
• La Spécification 
• Ce que le système doit être et comment il peut
  être utilisé.
• LAnalyse 
• Lobjectif est de déterminer les éléments
  intervenant dans le système à construire, ainsi
  que leur structure et leurs relations . Elle doit
  décrire chaque objet selon 3 axes 
• Axe fonctionnel  savoir-faire de lobjet.
• Axe statique  structure de lobjet.
• Axe dynamique  cycle de vie de lobjet au cours
  de lapplication (États et messages de lobjet).

Ces descriptions ne tiennent pas compte de
contraintes techniques (informatique).
18

• La Conception 
• Elle consiste à apporter des solutions
  techniques aux descriptions définies lors de
  lanalyse 
• architecture technique 
• performances et optimisation 
• stratégie de programmation
• On y définit les structures et les algorithmes.
• Cette phase sera validée lors des tests.
• Limplémentation
• Cest la réalisation de la programmation.

19

• Les tests de vérification 
• Ils permettent de réaliser des contrôles pour la
  qualité technique du système.
• Il sagit de relever les éventuels défauts de
  conception et de programmation (revue de code,
  tests des composants,...).
• Il faut instaurer ces tests tout au long du
  cycle de développement et non à la fin pour
  éviter des reprises conséquentes du travail
  (programmes de tests robustes  Logiciels de
  tests).

20

• La Validation 
• Le développement dune application doit être lié
  à un contrat ayant une forme de cahier de
  charges, où doivent se trouver tous les besoins
  de lutilisateur. Ce cahier de charge doit être
  rédigé avec la collaboration de lutilisateur et
  peut être par ailleurs complété par la suite.
• Tout au long des ces étapes, il doit y avoir des
  validations en collaboration également avec
  lutilisateur.
• Une autre validation doit aussi être envisagée
  lors de lachèvement du travail de développement,
  une fois que la qualité technique du système est
  démontrée. Elle permettra de garantir la logique
  et la complétude du système.

21

• Maintenance et évolution 
• Deux sortes de maintenances sont à considérer 
• Une maintenance corrective, qui consiste à
  traiter les buggs .
• Une maintenance évolutive, qui permet au système
  dintégrer de nouveaux besoins ou des changements
  technologiques.

22
Exemple Windows Vista
Vista prêt à en découdre avec les failles de
sécurité!C'est inévitable. La découverte de
failles devrait s'accélérer avec le lancement en
grandeur réelle de Windows Vista. Microsoft s'y
prépare  Les failles sont inhérentes au
développement logiciel. Elles reposent sur des
erreurs de programmation. Or, détecter absolument
toutes les erreurs est impossible même avec des
moyens financiers comme ceux dont dispose
Microsoft  8 000 dollars pour chaque trou de
sécurité! Idefense Labs, une filiale de
Verisign, va encore plus loin. Elle promet
8 000 dollars (assortis d'un bonus oscillant
entre 2 000 et 4 000 dollars selon la qualité des
explications fournies) à qui découvrira une
faille critique dans Vista ou Internet Explorer
7 La démarche est pertinente dans la mesure
où elle permet de mobiliser les chercheurs du
monde entier à moindre frais
23
Résumé

• Le développement dun logiciel repose sur les
  activités suivantes
• Détermination des besoins (quel est le cahier des
  charges ?)
• Analyse (que fera le logiciel ?)
• Conception (comment le fera-t-il ?)
• Implémentation (quel code exécutera-t-il ?)
• Test (sera-t-il conforme à lanalyse et au cahier
  des charges ?)
• Une organisation de ces activités forme un
  processus de développement.

24
Le développement en cascade (waterfall)
Principe Chaque activité est relative à
lentièreté du cahier des charges.
Ce processus est bien adapté à certaines
disciplines (mécanique, bâtiment). Il lest
moins pour le développement de logiciels.
25
Le développement en cascade (waterfall)
Inconvénients Ce processus est trop rigide.
Une activité ne peut commencer que si lactivité
précédente est complètement terminée. Cela
conduit à Ne pas détecter certains
problèmes, Négliger intentionnellement des
problèmes non résolus, Détecter des problèmes
trop tard, Contourner des problèmes de façon
peu adéquate. Les risques sont daboutir à un
produit mal structuré, ne correspondant pas bien
aux besoins, et dans lequel des problèmes de
conception sont contournés par des  ruses
dimplémentation .
26
Le développement itératif

• Principe
• Après lanalyse des besoins, on effectue
  plusieurs cycles de développement successifs.
• Chaque cycle conduit à une version utilisable du
  produit.
• Chaque cycle traite un petit nombre de besoins.

27
Le développement itératif

• Avantages
• A chaque étape du développement, la complexité
  reste limitée.
• Des implémentations de parties du système sont
  obtenues rapidement.
• Cela permet de disposer très tôt dinformations
  utiles sur le comportement du produit (early
  feedback) et son adéquation aux besoins.
• Remarque
• Cette méthodologie conduit parfois à réécrire ou
  à réorganiser du code (refactoring).

Cette approche est bien adaptée au génie logiciel.
28
Modèle

• Un modèle est une description abstraite dun
  système, destinée à en préciser certaines
  caractéristiques.
• Rôles dun modèle
• communication entre les différentes phases du
  développement.
• documentation de la structure interne du
  logiciel.
• En pratique, un modèle est représenté par un
  ensemble de documents
• (diagrammes, textes, . . . ).

Il existe un standard industriel pour lécriture
de différents types de modèles UML (Unified
Modeling Language).
29
Modèles dans UML

• UML repose sur 9 modèles (appelés diagrammes).
• Un modèle est une description simplifiée d'un
  système qui permet de le comprendre et de le
  simuler.
• En informatique, la modélisation consiste tout
  d'abord à décrire un problème puis à décrire la
  solution à ce problème.
• Ces activités s'appellent respectivement
  l'analyse et la conception.

30
Les Diagrammes UML

• Diagrammes structurels (Structural Diagrams)
• Diagrammes des classes (Class Diagram)
• Diagrammes des objets (Object Diagram)
• Diagramme des composants (Component Diagram)
• Diagramme de déploiement (Deployment Diagram)
• Diagrammes des comportements (Behavioral
  Diagrams)
• Diagramme des cas dutilisation (Use Case
  Diagram)
• Diagramme des séquences (Sequence Diagram)
• Diagramme des collaborations (Collaboration
  Diagram)
• Diagramme détat (Statechart Diagram)
• Diagramme dactivité (Activity Diagram)

31
Aperçu

• Diagramme de cas dutilisation Décompose le
  cahier des charges en parties significatives.
• Diagramme de structure statique Définit
  lorganisation
• des concepts (représentations mentales déléments
  du problème),
• des types (interfaces déléments logiciels),
• des classes (implémentation de ces éléments).
• Diagramme dactivité Ordonne les tâches devant
  être exécutées par le logiciel.
• Diagramme détat Détaille le comportement
  dynamique dun composant.

32
Aperçu
Diagramme dinteraction Précise les
collaborations entre différents composants
accomplissant une tâche. Deux variantes
diagramme de séquence, diagramme de
collaboration. Diagramme de conditionnement
(package diagram) Met en évidence les
dépendances entre groupes de concepts ou
déléments logiciels. Diagramme de déploiement
Définit la situation physique des composants du
logiciel par rapport aux éléments matériels.
33
Diagramme des Classes
34
Diagramme des Objets
35
Diagramme des Composants
36
Diagramme de Déploiement
37
Diagramme des Cas dutilisation
38
Diagramme des Séquences
39
Diagramme des Collaborations
40
Diagramme détats
41
Diagramme dactivité
42
Exemple logiciel de caisse enregistreuse
43
logiciel de caisse enregistreuse
Cas dutilisation Un client effectue des
achats et paie en espèce, Un client effectue
des achats et paie par carte de crédit, . .
. Structure statique Concepts client,
achat, vente, produit, paiement. . . Types
Magasin, Vente, ProduitAcheté, CatalogueProduits,
... Classes Vente Données date,
enCours, . . . Opérations calculeTotal(),
paie(montant), . . . Magasin Données nom,
adresse, . . . . . .
44
logiciel de caisse enregistreuse
Activités Les produits achetés par le client
sont encodés un par un. Ensuite, la caisse
affiche le total. Ensuite, . . . . . . États
Une vente est soit en cours, soit clôturée.
La clôture est signalée par le vendeur, et est
irrévocable. . . . Interactions Le total
dune vente se calcule en développant
successivement les sous-totaux relatifs à
lensemble des produits achetés, et en
additionnant les résultats. . . .
45
logiciel de caisse enregistreuse
Conditionnement On sépare linterface
utilisateur du traitement. . . . Déploiement
La partie principale du logiciel sexécute
dans la caisse enregistreuse. Seul le catalogue
de produits est géré par lordinateur central du
magasin.
46
Utilisation des diagrammes
Certains diagrammes sappliquent à plus dune
phase de développement.
47
2ème cours
48
Rappel

• LAnalyse détermination des éléments intervenant
  dans le système à construire, ainsi que leur
  structure et leurs relations . Elle doit décrire
  chaque objet selon 3 axes 
• Axe fonctionnel  savoir-faire de lobjet.
• Axe statique  structure de lobjet.
• Axe dynamique  cycle de vie de lobjet au
  cours de lapplication (États et messages de
  lobjet).
• La Conception apporter des solutions techniques
  aux descriptions définies lors de lanalyse 
• architecture technique 
• performances et optimisation 
• stratégie de programmation
• On y définit les structures et les algorithmes.

49
Processus de développement
50
LAnalyse des Besoins

• Spécifications fonctionnelles

51
Lanalyse des besoins
La première étape de lanalyse des besoins
consiste à déterminer les cas dutilisation du
système à développer.
Les use cases (cas dutilisation) sont un concept
de la méthode OOSE de Ivar Jacobson. Ils
permettent deffectuer une délimitation du
système et de décrire son comportement. Un cas
dutilisation est une interaction typique entre
le système et son environnement.
Ils constituent une représentation orientée
 fonctionnalités du système.
52
Traitement de texte

• Des cas dutilisation possibles sont
• la saisie dun nouveau texte.
• la modification dun texte existant.
• la génération dune table des matières.
• Sauvegarde dun texte.

Un cas dutilisation capture une fonction du
système telle quelle est perçue par les
utilisateurs, il montre comment un objectif des
utilisateurs peut être satisfait par le système.
Un cas dutilisation doit toujours correspondre à
un objectif de haut niveau.
Par exemple, la sélection dune police de
caractères ne constitue pas un cas dutilisation
valable.
53
Il est important de distinguer les objectifs des
utilisateurs (i.e., ce quils attendent du
système) de leurs interactions avec le système
(i.e., les mécanismes permettant de satisfaire
ces objectifs). Exemple Objectif obtenir
une présentation uniforme des documents.
Interactions le choix dun style de mise en
page, le choix dune police de caractères, le
transfert du style dun document à un autre, . . .
En pratique, on détermine dabord les objectifs,
et on choisit ensuite un ensemble de cas
dutilisation qui permet de les satisfaire.
54
Téléphone portable cas d'utilisation ?

• Mise en service
• Passer un appel audio
• Répondre à un appel audio
• Envoyer un SMS
• Gérer les contacts (répertoire)
• Gérer les SMS (lire, effacer, )
• Prendre une photo

55
Lanalyse des besoins
La deuxième étape de lanalyse des besoins
consiste à déterminer les acteurs du système à
développer.
Un acteur est le rôle joué par un utilisateur ou
une entité extérieure au cours dinteractions
avec le système. Les notions dutilisateur et
dacteur diffèrent Plusieurs utilisateurs
peuvent correspondre à un seul acteur Les
différents caissiers du supermarché jouent le
même rôle face au système. Un utilisateur peut
correspondre à plusieurs acteurs Une même
personne peut ainsi jouer simultanément les rôles
de gérant et de caissier.
56
Les acteurs 

• Ils ont une bonne connaissance des
  fonctionnalités du système. Ils constituent les
  éléments extérieurs du système. Ils peuvent être
  
• soit des humains 
• soit des logiciels 
• soit des automates.
• On distingue  
• les acteurs primaires  ceux sont les
  utilisateurs du système 
• les acteurs secondaires  ceux qui administrent
  le système.

57
Téléphone portable les acteurs ?

• Le réseau GSM (opérateur de télécommunication)
• L'utilisateur du téléphone
• Le technicien ?

58
Caisse enregistreuse les cas d'utilisation ?

• Identification
• Achat de produits au comptant
• Remboursement de produits
• Mise en route

59
Caisse enregistreuse les acteurs ?

• Client
• Caissier
• Gérant

• Système Informatique du magasin
• Centre de télémaintenance

Périmètre du système étudié
60
Exemple de cas dutilisation
61
Suite
62
Suite
63
Le diagramme des cas dutilisation
décrit les relations entre les cas dutilisation
et les acteurs dun système.
64

• les diagrammes des cas d'utilisation identifient
  les fonctionnalités fournies par le système (cas
  d'utilisation), les utilisateurs qui
  interagissent avec le système (acteurs), et les
  interactions entre ces derniers. Les cas
  d'utilisation sont utilisés dans la phase
  d'analyse pour définir les besoins de "haut
  niveau" du système. Les objectifs principaux des
  diagrammes des cas d'utilisation sont
•  
• fournir une vue de haut-niveau de ce que fait le
  système
• Identifier les utilisateurs (acteurs) du système
• Déterminer des secteurs nécessitant des
  interfaces homme-machine. (IHM)
•  
• Les cas d'utilisation se prolongent au delà des
  diagrammes imagés. En fait, des descriptions
  textuelles des cas d'utilisation sont souvent
  employées pour compléter ces derniers et
  représentent leurs fonctionnalités plus en
  détail.

65
Caisse enregistreuse diagramme des cas
d'utilisation, uses case diagram
66
Téléphone portable uses case diagram
67
Les relations entre cas dutilisation

• UML définit 3 grands types de relations entre cas
  dutilisation
• Extends,
• Include,
• Généralisation/spécialisation

68
La relation dextension ltltextendsgtgt
Il arrive quun cas dutilisation soit similaire
à un autre, mais comprenne des actions
supplémentaires.
69
Ce cas dutilisation Achat de produits avec
paiement par chèque, est une variante du cas
Achat de produits au comptant, mais y ajoute
des actions relatives à lencaissement dun
chèque. Le cas dutilisation Achat de produits
avec paiement par chèque est donc une extension
du cas dutilisation Achat de produits au
comptant.
Remarque Si un cas dutilisation est associé à
un acteur, toutes ses extensions sont également
associées à cet acteur. Les associations
résultant du mécanisme dextension ne sont
généralement pas reprises sur le diagramme.
70
Cela signifie que lors de la prise de commande,
s'il s'agit d'un nouveau client, le processus
permet dabord d'exécuter Enregistrer client
afin que le client soit connu puis ensuite, de
reprendre la prise de commande.
Remarque Dans le cas du extends , le cas
dutilisation qui étend lautre peut avoir un
acteur déclencheur.
71
La relation ltltincludegtgt ou ltltusesgtgt
La relation dinclude na pour seul objectif que
de factoriser une partie de la description dun
cas dutilisation qui serait commune à dautres
cas dutilisation. Le cas dutilisation inclus
dans les autres cas dutilisation nest pas à
proprement parlé un vrai cas dutilisation car il
na pas dacteur déclencheur ou receveur
dévènement. Il est juste un artifice pour faire
de la réutilisation dune portion de texte.
72
ltltincludegtgt / ltltusesgtgt
Exemple On désire accepter les achats au
comptant et à crédit. Chacun des cas
dutilisation Achat de produits au comptant et
Achat de produits à crédit contient une suite
dactions pouvant être décrite par le cas
dutilisation Encodage de produits.
73
Remarque Contrairement à la relation
dextension, deux cas dutilisation impliqués
dans une relation dutilisation ne sont pas
nécessairement associés aux mêmes acteurs.
74
Le classement des cas dutilisation
Une fois les cas dutilisation déterminés, la
deuxième étape de lanalyse des besoins consiste
à leur attribuer des cycles de développement.
Cette attribution seffectue par ordre
dimportance Les cas dutilisation ayant le
plus grand impact prévisible doivent être traités
en premier lieu.
75
Diagrammes d'Activité et/ou séquences

• Le diagramme d'activités n'est autre que la
  transcription dans UML de la représentation du
  processus il montre l'enchaînement des activités
  qui concourent au processus.
• Le diagramme de séquence représente la succession
  chronologique des opérations réalisées par un
  acteur. Il indique les objets que l'acteur va
  manipuler et les opérations qui font passer d'un
  objet à l'autre.

76
Téléphone portable diagramme d'activité
Diagramme des cas d'utilisation
Les diagrammes d'activités permettent de
représenter graphiquement le déroulement d'un cas
d'utilisation ou le comportement d'une méthode.
77
Téléphone portable diagramme d'activité du cas
d'utilisation mise en service
78
Téléphone portable diagramme des séquences du
cas d'utilisation mise en service
79
Le modèle conceptuel

• Aspects statiques

80
Processus de développement
81
Le diagramme de structure statique

• Ce type de diagramme possède plusieurs variantes,
  liées aux différentes perspectives (concept, type
  ou classe).
• Dans la phase danalyse, le diagramme de
  structure statique représente
• Les concepts du domaine étudié,
• Les attributs et les responsabilités de ces
  concepts,
• Les relations entre ces concepts.
• Rappel Un concept est la représentation mentale
  dun objet.
• Un concept est un élément du domaine étudié, et
  non un élément logiciel.
• En particulier, un concept nest pas une classe !
  (cependant, au cours de la phase de conception,
  les classes seront définies sur base des
  concepts).

82
La détermination des concepts
Les concepts devant faire partie du diagramme de
structure statique se déterminent en identifiant
les éléments dont il est nécessaire de retenir
les données, ou de considérer le
comportement. Remarque La détermination des
concepts seffectue sur la base des cas
dutilisation par simple analyse grammaticale de
la description textuelle. D'une manière
générale, les noms représentent des concepts ou
des attributs tandis que les verbes représentent
des comportements (opérations, méthodes)
83
Exemple Caisse enregistreuse
Des concepts possibles sont ? Caisse, Caissier ,
Client, Achats, AchatProduit, Produit, . . .
84
Deux règles utiles

• Règle du cartographe Le modèle conceptuel se
  construit de la même façon quun cartographe
  dessine une carte
• En utilisant le vocabulaire du domaine étudié.
• En excluant les éléments non pertinents.
• En nincluant pas déléments inexistants dans le
  domaine.
• Choix entre concept et attribut Si un élément
  du domaine étudié est autre chose quun nombre ou
  un simple texte, alors il sagit probablement
  dun concept et non dun attribut.

85
Exemple Caisse enregistreuse
Des attributs possibles sont ? dénomination,
prix, nombre,
86
On développe le logiciel dune compagnie
aérienne. Les vols sont matérialisés par une
compagnie, un horaire, une destination, .etc.
La destination dun vol est-elle un attribut du
concept Vol ou bien un concept distinct ?
Réponse La destination dun vol est un
aéroport. Dans la réalité, un aéroport est un
objet matériel, pas un nombre ou un texte. On le
modélise donc par un concept.
87
Les associations entre concepts
Une association représente une relation entre les
instances de plusieurs concepts. Exemple
Lassociation Contient relie les concepts
Catalogue et Produit, et exprime la
correspondance entre les catalogues et les
produits repris dans ces catalogues. Catalogue
bricolage, jardinage, électricité . Produits
tournevis, râteau, gants, tondeuse, . . .
. Contient (bricolage, tournevis),
(bricolage, gants), (jardinage, râteau),
(jardinage, gants), (jardinage, tondeuse),
(électricité, tournevis), . . . .
88
Notation
Association binaire
89
Association entre plus de deux concepts
Remarques La désignation des rôles est
facultative. Dans le cas dune relation binaire,
les rôles peuvent souvent être déduits du nom de
la relation et de son sens de lecture (symbole
?).
90
La multiplicité dun rôle définit le nombre
dinstances possibles de la relation quand les
instances des autres branches sont fixées
91
Les attributs
Les attributs dun concept représentent les
données primitives quil est nécessaire de
considérer pour chaque instance du
concept. Exemple
92
Notes Un attribut ne peut représenter quune
valeur primitive (entier, texte, date,
identificateur, matricule, . . . ). Un attribut
ne peut représenter que des données relatives au
concept auquel il est associé. Exemple
93
Les opérations

• Le modèle conceptuel ne se limite pas à décrire
  les éléments du domaine étudié pour lesquels il
  faut retenir des informations. Les concepts
  possèdent aussi un comportement.
• Le comportement dun concept comprend
• La mise à jour et la gestion de laccès aux
  données associées à une instance du concept
  (attributs et associations).
• Un certain nombre dautres tâches, associées à la
  responsabilité du concept.
• La responsabilité dun concept peut être vue
  comme une description abstraite de la raison
  dêtre de ce concept. Dans le modèle conceptuel,
  on représente la responsabilité par des
  opérations quune instance du concept doit être
  capable deffectuer.

94
Exemple Caisse enregistreuse
Des opérations possibles sont ? acheter,
encoder, entrer le nombre, signaler la fin
95
Remarque La responsabilité liée à une opération
particulière peut être détaillée dans un contrat
accompagnant cette opération. Exemple et notation

96
La spécialisation des concepts
Il arrive quun concept soit essentiellement
identique à un autre, les seules différences
résidant dans un certain nombre de
caractéristiques supplémentaires (des attributs,
des opérations ou des associations avec dautres
concepts). On dit alors que le premier concept
est une spécialisation du second. Notation
97
Remarque La notation suivante est également
permise. (Le regroupement des flèches na pas de
signification particulière).
98
Lhéritage

• Les spécialisations dun concept héritent de
  toutes les caractéristiques de ce concept.
  Celles-ci incluent
• les attributs,
• les opérations,
• les associations avec dautres concepts.
• Exemple

99
Selon ce modèle, les concepts Paiement cash,
Paiement par carte et Paiement par chèque
possèdent lattribut montant, et chacun
dentre-eux est associé au concept Vente par la
relation Règle.
100
Le principe de substitution
Si deux concepts sont liés par une relation de
spécialisation, alors ils doivent satisfaire la
règle suivante Toute instance du concept
spécialisé doit pouvoir jouer le rôle dune
instance du concept général. En dautres termes,
il doit être possible de substituer une instance
du concept spécialisé à une instance du concept
général dans toutes les applications où ce
dernier joue un rôle. De façon informelle, cette
règle peut se vérifier en formant la phrase
ltconcept spécialiségt est un ltconcept
généralgt. Exemple Un paiement par carte est un
paiement.
101
La classification multiple
Un concept général peut souvent être spécialisé
de plusieurs façons différentes. Exemple
Gestion dun hôpital.
Chaque médecin est aussi un homme ou une femme.
Il est donc possible quune instance dun concept
appartienne simultanément à plusieurs
spécialisations de ce concept.
102

• Solution Sur le diagramme de structure
  statique, on associe aux relations de
  généralisation des discriminants qui précisent
  quelles combinaisons de spécialisations sont
  autorisées.
• Principes
• Une instance dun concept général ne peut pas
  être simultanément une instance de deux concepts
  spécialisés associés au même discriminant.
• Si la contrainte mandatory accompagne un
  discriminant, alors toute instance du concept
  général doit obligatoirement être une instance
  dun et dun seul concept spécialisé associé à ce
  discriminant.

103
Remarque Labsence de discriminant peut être
considérée comme étant un discriminant
particulier (le discriminant vide).
104
3ème cours
105
Rappel

• LAnalyse détermination des éléments intervenant
  dans le système à construire, ainsi que leur
  structure et leurs relations . Elle doit décrire
  chaque objet selon 3 axes 
• Axe fonctionnel  savoir-faire de lobjet.
• Axe statique  structure de lobjet.
• Axe dynamique  cycle de vie de lobjet au
  cours de lapplication (États et messages de
  lobjet).
• La Conception apporter des solutions techniques
  aux descriptions définies lors de lanalyse 
• architecture technique 
• performances et optimisation 
• stratégie de programmation
• On y définit les structures et les algorithmes.

106
Processus de développement
107
Les concepts abstraits
Tout comme pour les classes, un concept abstrait
est un concept qui ne peut pas être instancié en
tant que tel, mais uniquement en tant quune de
ses spécialisations. Exemple
Remarque Dans un document manuscrit, il est
permis de remplacer lécriture en italiques du
nom du concept par la contrainte abstract
en dessous du nom du concept.
108
La composition et lagrégation
Les relations de composition et dagrégation sont
deux types particuliers dassociations,
permettant dexprimer lappartenance dune partie
à un tout.
109
Remarques La composition permet dimposer des
contraintes qui ne peuvent pas sexprimer à
laide de la seule multiplicité. Exemple Une
instance de concept Point ne peut pas être
simultanément associée à une instance de
Triangle et à une instance de Cercle.
110
La composition exprime souvent lappartenance
physique de parties à un tout (e.g., les doigts
dune main). En revanche, lagrégation ne
sapplique pratiquement quà des concepts
abstraits. (En cas de doute sur la présence ou
non dagrégation, il vaut mieux lomettre.)
Quand lordre des composants doit être connu par
le concept composite, on adjoint à la branche
correspondante de lassociation la contrainte
ordered . Exemple
111
Les associations qualifiées
Un qualificateur est un attribut (ou un groupe
dattributs) associé à une branche dune
association, et dont la valeur permet de
distinguer les instances du concept
concerné. Exemple Lassociation Contient
exprime la correspondance entre des catalogues et
les produits repris dans ces catalogues.
Chaque produit possède un numéro de référence
unique. Il est donc possible de distinguer les
produits dun catalogue sur base de ce numéro.
112
Le schéma devient alors
113
Les éléments dassociations
Il est possible dadjoindre des attributs et des
opérations à des associations. Chaque instance de
lassociation possède alors ces éléments. Exemple
et notation
114
Note Ajouter des éléments à une association ne
revient pas à transformer lassociation en
concept. Ainsi, le modèle suivant nest pas
équivalent au premier
En effet, le premier diagramme interdit à une
personne de travailler plus de deux fois pour la
même entreprise au cours de sa carrière, alors
que le deuxième modèle ly autorise.
115
Application

• Guichet automatique de banque

116
Le GAB, guichet automatique de banque

• Distribution dargent à tout porteur de carte de
  crédit, via un lecteur de carte et un
  distributeur de billets
• Consultation de solde de compte, dépôt en
  numéraire et dépôt de chèques pour les clients
  porteurs de carte de crédit de la banque adossée
  au GAB
• Toutes les transactions sont sécurisées
• Il est parfois nécessaire de recharger le
  distributeur

• On se propose de
• Identifier les acteurs
• Identifier les cas dutilisation
• Construire un diagramme des cas dutilisation
• Décrire textuellement les cas dutilisation

117
Identification des acteurs
Quelles sont les entités externes qui
interagissent avec le GAB ?

• Porteur de carte
• Carte de crédit
• Lecteur de carte
• Distributeur de billets

Phrase 1

• Porteur de carte client de la banque

Phrase 2

• Le système est sécurisé (par quoi?)
• Le système dautorisation
• Le système dinformation de la banque

Phrase 3
Phrase 4

• Opérateur de maintenance

118
Le GAB est un système fondamentalement
mono-utilisateur à tout instant, il ny a quune
instance de chaque acteur (au maximum) connecté
au système!
Pour simplifier, nous utiliserons le terme Client
banque pour lacteur Porteur de carte client de
la banque.
119
Diagramme de contexte statique
120
Les acteurs humains Client banque et Porteur de
carte sont mutuellement exclusifs, ce qui nest
pas implicite daprès les multiplicités des
associations. On peut ajouter une contrainte
XOR (ou exclusif)
121
Une autre solution, un peu plus élaborée,
consiste à considérer que Client banque est une
spécialisation de Porteur de carte (héritage
entre acteurs)
122
Diagramme des cas dutilisation

• Porteur de carte
• Retirer de largent
• Client banque
• Retirer de largent (bien sûr!)
• Consulter le solde de son compte courant
• Déposer du numéraire
• Déposer de largent (numéraire ou chèque)
• Opérateur de maintenance
• Recharger le distributeur
• Maintenir létat opérationnel
• Système dautorisation (Sys.Auto)
• Néant
• Système dinformation de la banque (SI banque)
• Néant

Acteurs primaires
Acteurs secondaires
123
Diagramme des cas dutilisation sans les acteurs
secondaires
124
Diagramme des cas dutilisation
125
Diagramme des cas dutilisation amélioration
126
Description textuelle du cas d'utilisation
 RETIRER DE LARGENT    

• Sommaire d'identification
• Titre Retirer de l'argent
• Résumé ce cas d'utilisation permet à un porteur
  de carte, qui n'est pas client de la banque, de
  retirer de l'argent, si son crédit hebdomadaire
  le permet.
• Acteurs Porteur de carte non client
  (principal), Sys. Auto. (secondaire).
• Date de création 03/01/07 Date de mise à
  jour 09/02/07
• Version 1.0 Responsable
  Pierre DUMONT
• Description des scénarios
• Pré conditions
• La caisse du GAB est alimentée (il reste au moins
  un billet !).
• Aucune carte ne se trouve déjà coincée dans le
  lecteur.
• Scénario nominal
• 1. Le porteur de carte introduit sa carte dans le
  lecteur de cartes du GAB.
• 2. Le GAB vérifie que la carte introduite est
  bien une carte bancaire.

127
3. Le GAB demande au porteur de carte de saisir
son code d'identification. 4. Le porteur de carte
saisit son code d'identification. 5. Le GAB
compare le code d'identification avec celui qui
est codé sur la puce de la carte. 6. Le GAB
demande une autorisation au système
d'autorisation. 7. Le système d'autorisation
donne son accord et indique le solde
hebdomadaire. 8. Le GAB demande au porteur de
carte de saisir le montant désiré du retrait. 9.
Le porteur de carte saisit le montant désiré du
retrait. 10. Le GAB contrôle le montant demandé
par rapport au solde hebdomadaire. 11. Le GAB
demande au porteur de carte s'il veut un
ticket. 12. Le porteur de carte demande un
ticket. 13. Le GAB rend sa carte au porteur de
carte. 14. Le porteur de carte reprend sa
carte. 15. Le GAB délivre les billets et un
ticket. 16. Le porteur de carte prend les billets
et le ticket. 17. Le GAB enregistre la
transaction de retrait.
128
Description textuelle du cas d'utilisation
RETIRER DE LARGENT  (Représentation de C.Larman)
Une autre présentation dite de Larman consiste à
séparer les actions des acteurs et du système en
deux colonnes
129
(No Transcript)
130
Enchaînements alternatifs
Al code d'identification provisoirement
erroné L'enchaînement Al démarre au point 5 du
scénario nominal. 6. Le GAB indique au porteur de
carte que le code est erroné, pour la première ou
deuxième fois. 7. Le GAB enregistre l'échec sur
la carte. Le scénario nominal reprend au point 3.
A2 montant demandé supérieur au solde
hebdomadaire L'enchaînement A2 démarre au point
10 du scénario nominal. 11. Le GAB indique au
porteur de carte que le montant demandé est
supérieur au solde hebdomadaire. Le scénario
nominal reprend au point 8.
Nous distinguons les enchaînements alternatifs
(Ax) qui reprennent ensuite à une étape du
scénario nominal des enchaînements d'erreur (Ey)
qui terminent brutalement le cas d'utilisation en
échec. L'objectif de l'acteur principal est donc
atteint par les scénarios nominaux et alternatifs
mais pas par ceux d'erreur.
131
A3 ticket refusé L'enchaînement A3 démarre au
point 11 du scénario nominal. 12. Le porteur de
carte refuse le ticket. 13. Le GAB rend sa carte
au porteur de carte. 14. Le porteur de carte
reprend sa carte. 15. Le GAB délivre les
billets. 16. Le porteur de carte prend les
billets. 17. Le GAB enregistre la transaction de
retrait.
Enchaînements derreur
El carte non-valide L'enchaînement El démarre
au point 2 du scénario nominal. 3. Le GAB indique
au porteur que la carte n'est pas valide
(illisible, périmée, etc.), la confisque le cas
d'utilisation se termine en échec.
132
E2 code d'identification définitivement
erroné L'enchaînement E2 démarre au point 5 du
scénario nominal. 6. Le GAB indique au porteur de
carte que le code est erroné, pour la troisième
fois. 7. Le GAB confisque la carte. 8. Le système
d'autorisation est informé le cas d'utilisation
se termine en échec.
E3 retrait non autorisé L'enchaînement E3
démarre au point 6 du scénario nominal. 7. Le
système d'autorisation interdit tout retrait. 8.
Le GAB éjecte la carte le cas d'utilisation se
termine en échec.
E4 carte non reprise L'enchaînement E4 démarre
au point 13 du scénario nominal. 14. Au bout de
15 secondes, le GAB confisque la carte. 15. Le
système d'autorisation est informé le cas
d'utilisation se termine en échec.
133
E5 billets non pris L'enchaînement E5 démarre
au point 15 du scénario nominal. 16. Au bout de
30 secondes, le GAB reprend les billets. 17. Le
système d'autorisation est informé le cas
d'utilisation se termine en échec.
E6 annulation de la transaction L'enchaînement
E6 peut démarrer entre les points 4 et 12 du
scénario nominal. 4 à 12. Le porteur de carte
demande l'annulation de la transaction en
cours. Le GAB éjecte la carte le cas
d'utilisation se termine en échec.
E4 carte non reprise L'enchaînement E4 démarre
au point 13 du scénario nominal. 14. Au bout de
15 secondes, le GAB confisque la carte. 15. Le
système d'autorisation est informé le cas
d'utilisation se termine en échec.
134
Enchaînements alternatifs et derreurreprésentati
on de Cockburn
2a. Carte illisible ou non valable Le
GAB avertit le porteur et éjecte la carte le
cas d'utilisation se termine en échec. 2b.
Carte périmée Le GAB avertit le porteur et
confisque la carte le cas d'utilisation se
termine en échec. 4a. Délai de saisie du
code expiré Le GAB avertit le porteur et
éjecte la carte le cas d'utilisation se termine
en échec. 4-12a. Le porteur annule la
transaction Le GAB éjecte la carte le cas
d'utilisation se termine en échec. 5a. Code
d'identification erroné pour la première ou
deuxième fois 5al. Le GAB enregistre l'échec
sur la carte. 5a2. Le GAB avertit le porteur et
le scénario nominal reprend à l'étape 4. ...etc
135
Description textuelle du cas d'utilisation
 RETIRER DE LARGENT  informations optionnelles
Exigences non fonctionnelles
136
Description textuelle du cas d'utilisation
 RETIRER DE LARGENT  informations optionnelles
Besoins dIHM

• Les dispositifs d'entrée/sortie à la disposition
  du porteur de carte doivent être
• Un lecteur de carte bancaire.
• Un clavier numérique (pour saisir son code), avec
  des touches validation , correction et
  annulation .
• Un écran pour l'affichage des messages du GAB.
• Des touches autour de l'écran pour sélectionner
  un montant de retrait parmi ceux qui sont
  proposés.
• Un distributeur de billets.
• Un distributeur de tickets.

137
Description graphique des cas d'utilisation

• Description graphique de lensemble des uses case
  (uses case diagram)
• Description textuelle de chaque uses case.
• Indispensable
• Permet de communiquer facilement
• Permet de définir clairement le vocabulaire
  métier employé
• Difficile à montrer lenchaînement des évènements
  
• La maintenance des évolutions est fastidieuse
• Il est recommandé de compléter par un ou
  plusieurs diagrammes dynamiques

diagramme dactivités et diagramme de séquences
138
Diagramme dactivité
Le diagramme dactivités représente un cas
dutilisation au niveau de son scénario. Les
utilisateurs le comprennent bien car il ressemble
à un organigramme.
139
Diagramme de séquence
140
Diagramme de séquence
Réaliser un diagramme de séquence qui décrit le
scénario nominal du cas dutilisation RETIRER DE
LARGENT.
Acteurs/ participants
Temps
141
Diagramme dactivité
Réaliser un diagramme dactivité qui décrit la
dynamique du cas dutilisation RETIRER DE
LARGENT.
142
Conseils méthodologiques

• Pour la modélisation fonctionnelle

143
COMMENT IDENTIFIER LES ACTEURS ?

• les utilisateurs humains directs, sans oublier
  l'administrateur, l'opérateur de maintenance,
  etc.
• les autres systèmes connexes qui interagissent
  aussi directement avec le système étudié souvent
  par le biais de protocoles bidirectionnels..
• Éliminez autant que faire se peut les acteurs
  physiques au profit des acteurs logiques
  l'acteur est celui qui bénéficie de l'utilisation
  du système.
• Répertoriez en tant qu'acteurs uniquement les
  entités externes (et pas des composants internes
  au système étudié) qui interagissent directement
  avec le système (et pas indirectement par le
  biais d'autres acteurs).

144
COMMENT REPRÉSENTER LES ACTEURS ?
Utilisez la forme graphique du stick man pour les
acteurs humains, et la représentation
rectangulaire avec le mot-clé actor pour les
systèmes connectés.
LE DIAGRAMME DE CONTEXTE STATIQUE
Réalisez si nécessaire un diagramme de contexte
statique. Il suffit pour cela d'utiliser un
diagramme de classes dans lequel chaque acteur
est relié par une association à une classe
centrale unique représentant le système, ce qui
permet de spécifier le nombre d'instances
d'acteurs connectées au système à un moment donné.
145
COMMENT IDENTIFIER LES CAS D'UTILISATION ?

• délimitez le sujet les frontières du système
  étudié, son périmètre. S'agit-il d'une
  application logicielle, d'un système intégrant du
  matériel et du logiciel, de cet ensemble y
  compris son opérateur?
• identifiez les acteurs principaux, c'est-à-dire
  ceux qui cherchent à obtenir un résultat
  observable, un but, en utilisant les services du
  système
• identifiez les objectifs, les buts, de chaque
  acteur principal
• définissez des cas d'utilisation autonomes qui
  correspondent aux objectifs des acteurs
  principaux.

Ne vous inquiétez pas il est normal que tous
les objectifs et les cas d'utilisation ne soient
pas correctement identifiés d'emblée. Il s'agit
forcément d'un processus de recherche itératif et
évolutif.
146
COMMENT AMÉLIORER LE DIAGRAMME DE CAS
D'UTILISATION ?

• Pour améliorer le contenu informatif du diagramme
  de cas d'utilisation, il est recommandé d'adopter
  les conventions suivantes
• par défaut, le rôle d'un acteur est principal
  si ce n'est pas le cas, indiquez explicitement
  que le rôle est secondaire sur l'association, du
  côté de l'acteur
• dans la mesure du possible, disposez les acteurs
  principaux à gauche des cas d'utilisation, et les
  acteurs secondaires à droite
• si l'acteur ne fait que recevoir des messages du
  système (ou seulement en envoyer), utilisez le
  symbole de restriction de navigabilité sur
  l'association entre le cas d'utilisation et
  l'acteur.

147
COMMENT DÉCRIRE LES CAS D'UTILISATION ?

• Recenser textuellement toutes les interactions
  entre les acteurs et le système.
• Le cas d'utilisation doit avoir un début et une
  fin clairement identifiés.
• Préciser les variantes possibles, telles que le
  scénario nominal, les différents cas
  alternatifs , les cas d'erreurs, tout en
  essayant d'ordonner séquentiellement les
  descriptions, afin d'améliorer leur lisibilité.
• Ne mélangez pas cas d'utilisation essentiel
  (indépendant de tout choix technologique
  d'interface avec les acteurs) et cas
  d'utilisation réel le premier est beaucoup plus
  stable et peut être plus facilement réutilisé.
• Rédigez avec concision en évitant les mots
  inutiles.
• Généralisez l'adoption de conventions communes au
  sein du projet. Celles proposées par A. Cockburn
  ont le mérite d'être largement répandues et
  acceptées.

148
COMMENT DÉCRIRE LES CAS D'UTILISATION ?

• Rédigez des cas d'utilisation en boîte noire
  ne décrivez pas le fonctionnement interne du
  système, ses composants ou sa conception.
  Considérez uniquement ce qui est visible par les
  acteurs.
• Complétez la description textuelle des cas
  d'utilisation par un ou plusieurs diagrammes
  dynamiques UML
• Pour la dynamique globale du cas d'utilisation,
  utilisez un diagramme d'activité ou un diagramme
  de séquence.
• Pour décrire le scénario nominal, utilisez un
  diagramme de séquence. Présentez-le en montrant
  l'acteur principal à gauche, puis un objet qui
  représente le système en boîte noire, et enfin en
  disposant à droite du système les éventuels
  acteurs secondaires sollicités durant le scénario.

149
LES RELATIONS ENTRE CAS D'UTILISATION

• Utilisez la relation d'inclusion entre cas
  d'utilisation pour éviter de devoir décrire
  plusieurs fois le même enchaînement, en
  factorisant ce comportement commun dans un cas
  d'utilisation supplémentaire inclus.
• Utilisez la relation d'extension entre cas
  d'utilisation pour séparer un comportement
  complexe optionnel ou rare du comportement
  obligatoire.
• Utilisez la relation de généralisation/spécialisat
  ion entre cas d'utilisation pour formaliser des
  variations importantes sur le même cas
  d'utilisation.
• N'abusez cependant pas des relations entre cas
  d'utilisation (surtout extension et
  généralisation) elles peuvent rendre les
  diagrammes de cas d'utilisation difficiles à
  décrypter pour les experts métier qui sont censés
  les valider

150
PAS PLUS DE 20 CAS D'UTILISATION !

• Limitez à 20 le nombre de vos cas d'utilisation
  de base (en dehors des cas inclus, spécialisés,
  ou des extensions). Avec cette limite arbitraire,
  on reste synthétique et on ne tombe pas dans le
  piège de la granularité trop fine des cas
  d'utilisation.

SOYEZ AGILES ET ITÉRATIFS !

• Les descriptions textuelles des cas d'utilisation
  et les diagrammes UML ne sont jamais parfaits. Il
  leur manque certains éléments et certaines
  assertions sont fausses. Nadoptez pas l'attitude
  du processus en cascade en voulant obtenir
  d'emblée des spécifications exactes et
  exhaustives
• Préférez le développement itératif et
  incrémental. Les cas d'utilisation et les autres
  modèles sont progressivement affinés, vérifiés et
  clarifiés grâce à la programmation et aux tests.

151
Modélisation statique
152
Objectifs

• Identifier les concepts du domaine et les
  modéliser en tant que classes
• Identifier les associations pertinentes entre les
  concepts
• Réfléchir aux multiplicités à chaque extrémité
  dassociation
• Ajouter des attributs aux classes du domaine
• Différence entre modèle danalyse et de
  conception
• Utilisation des diagrammes de classes et dobjets
• Classes dassociations

153
Diagramme de classes
Cest le point central du développement orienté
objet. En analyse Il permet de décrire la
structure des entités manipulées par les
utilisateurs En conception Il représente la
structure du code orienté objet, ou même les
modules du langage de développement.
154
Un attribut représente une information contenue
dans une classe Une opération représente un
élément de comportement (un service)
La classe représente la description abstraite
dun ensemble dobjets (type)
Une association représente une relation
sémantique durable et symétrique entre deux
classes. (ex  possède )
Une agrégation est un cas particulier
dassociation non symétrique exprimant une
relation de contenance
Généralisation, super-classe sous-classe
représentent la relation dhéritage.
155
Package. Mécanisme de regroupement déléments UML
(classes, associations,.etc.). Les package sont
des espaces de nom  namespace . Les
regroupements en package doivent assurer un bon
compromis entre Cohérence et indépendance pour
limiter les relations entre eux.
156
Application

• Système de réservation de vol

157
Interview des experts métier

• 1. Des compagnies aériennes proposent différents
  vols.
• 2. Un vol est ouvert à la réservation et refermé
  sur ordre de la compagnie.
• 3. Un client peut réserver un ou plusieurs vols,
  pour des passagers différents.
• 4. Une réservation concerne un seul vol et un
  seul passager.
• 5. Une réservation peut être annulée ou
  confirmée.
• 6. Un vol a un aéroport de départ et un aéroport
  d'arrivée.
• 7. Un vol a un jour et une heure de départ, et un
  jour et une heure d'arrivée.
• 8. Un vol peut comporter des escales dans des
  aéroports.
• 9. Une escale a une heure d'arrivée et une heure
  de départ.
• 10. Chaque aéroport dessert une ou plusieurs
  villes.

158
Étape 1 - Modélisation des phrase 1et 2
1. Des compagnies aériennes proposent différents
vols.
CompagnieAerienne et Vol Ils ont des propriétés
et des comportements. Ce sont donc des classes
candidates pour notre modélisation statique.
?
La phrase ne donne pas dindication sur la
multiplicité coté CompagnieAerienne. Il faudra
poser la question à lexpert métier!
159
Nous partirons du principe qu'un vol est proposé
le plus souvent par une seule compagnie aérienne,
mais qu'il peut également être partagé entre
plusieurs affréteurs.
2. Un vol est ouvert à la réservation et refermé
sur ordre de la compagnie.
160
Étape 2 - Modélisation des phrase 6, 7 et 8
7. Un vol a un jour et une heure de départ, et un
jour et une heure d'arrivée.
Java.util.Date

• Objet ou attribut?
• Un objet est un élément plus important qu'un
  attribut.
• si l'on ne peut demander à un élément que sa
  valeur - attribut
• si plusieurs questions s'y appliquent - objet
  (qui possède lui-même plusieurs attributs, ainsi
  que des liens avec d'autres objets.)

161
6. Un vol a un aéroport de départ et un aéroport
d'arrivée.
Contrairement aux notions d'heure et de date qui
sont des types simples , la notion d'aéroport
est complexe elle fait partie du métier. Un
aéroport ne possède pas seulement un nom, il a
aussi une capacité, dessert des villes, etc...
C'est la raison pour laquelle nous préférons
créer une classe Aéroport plutôt que de simples
attributs aeroportDepart et aeroportArrivee dans
la classe Vol.
162
Modélisation de la phrase 10.
10. Chaque aéroport dessert une ou plusieurs
villes.
?
Si desservir consiste simplement à désigner
le moyen de transport par les airs le plus
proche, toute ville est toujours desservie par un
et un seul aéroport. Si desservir vaut par
exemple pour tout moyen de transport aérien se
trouvant à moins de trente kilomètres, alors une
ville peut être desservie par 0 ou plusieurs
aéroports.
1
0..
163
Étape 3 - Modélisation des phrases 8 et 9
8. Un vol peut comporter des