analyse des besoins introduction à la notation uml dess cci cours de génie logiciel tronc commun...
TRANSCRIPT
Analyse Des BesoinsIntroduction à la Notation UML
DESS CCI
Cours de Génie Logiciel
Tronc Commun
Octobre – Décembre 2000
Jean-Marie Favre
2Analyse des besoins [email protected]
Avertissement
Ce document regroupe un certain nombre de transparents présentés dans le cadre du cours de Génie Logiciel, du DESS CCI, UFR IMA, à l’Université Joseph Fourier.
Il s’agit de la première partie de ce cours, dictée par Jean-Marie Favre. Certains transparents n’ont pas été présentés. Certaines parties du cours se sont déroulées sans transparents.
L’ordre des transparents et le découpage du cours est lié intimement au calendrier de l’année 2000 et à des contraintes de précédence entre le cours et les travaux dirigés.
Pour plus d’information n’hesitez pas à me contacter : [email protected]
4Analyse des besoins [email protected]
Vous avez dit "Génie Logiciel" ?
Génie logiciel ou Ingénierie du logiciel
• Termes équivalents
• D'ou viennent ces termes ?
• Que recouvrent-ils ?
• Le terme ingénierie est-il adapté ?
• Qu'est ce qu'un logiciel ?
5Analyse des besoins [email protected]
La préhistoire du logiciel
• Années 50 et 60 : programmation empirique– production "artisanale" de logiciels scientifiques
– royaume des "codeurs" et les "grands gourous"
• Fin des années 60 : la "crise du logiciel"– difficulté d'écrire de grands programmes
– difficulté de les utiliser, difficulté de les faire évoluer
– de nombreux projets échouent
6Analyse des besoins [email protected]
La "crise du logiciel"
Etude du gouvernement américain en 1979
• Payés mais jamais livrés $3.2M 47%
• Livrés mais jamais utilisés $2.0M 30%
• Abandonnés ou refaits $1.3M 20%
• Utilisés après modification $0.2M 3%
• Utilisés tel quel $0.1M 2%
7Analyse des besoins [email protected]
Origine du terme "Génie Logiciel"
1968 : "1st Conference on Software Engineering"• Génie Logiciel = Ingénierie + Logiciel• idée : la production de logiciel doit être organisée• contrôle des coûts, contrôle de la qualité, etc.
Idée séduisante• changement de terminologie
– 1950 : codeur – 1970 : programmeur – 1990 : ingénieur logiciel
• correspond réellement à une discipline d’ingénierie ?
8Analyse des besoins [email protected]
Définition : "Ingénierie"
"Creating cost-effective solutions ...... to practical problems ...
... by applying scientific knowledge" [Shaw90]
• ressources limitées (e.g. temps, argent, ...)
• solution utile résolvant un problème concret
• le problème n'est pas inventé par l'ingénieur
• rigueur dans la résolution du problème
• prédictibilité du résultat
9Analyse des besoins [email protected]
Pratique de l'ingénierie
" Engineering practice enables ordinary practitioners so they can create sophisticated systems that work - unspectacularly, perhaps, but
reliably"
• pas besoin d'être un génie pour être un ingénieur !
• résolution de problèmes complexes
• résolution de problèmes récurrents
• catalogue de solutions pour un type de problèmes
• solutions sûres et éprouvées
10
Analyse des besoins [email protected]
Ingénierie et société
“The engineer is expected to demonstrate that the design satisfies the specifications."
• exemple : montrer qu'un pont ne va pas s'écrouler
• contraintes de sécurité imposée par la société
“A highly developed sense of responsability toward his clients and the public”
• n'importe qui ne peut pas faire n'importe quoi
• association, droit d'exercer la profession, etc.
11Analyse des besoins [email protected]
Modèle d'évolution des disciplines d'ingénierie
• L'émergence d'une discipline d'ingénierie est un processus lent
Ingénierie = production de produits industriels basée sur des connaissances scientifiques
(1) Artisanat
(2) Production
(3) Commerce
(4) Science
(5) Ingénierie
temps
12
Analyse des besoins [email protected]
Exemple :Génie Chimique
Production industrielle de produits chimique : fertilisants, solvants, papier, dérivés du pétrole, etc.
(1) Artisanat
(2) Production
(3) Commerce
(4) Science
(5) Ingénierie
alchimiepierre philosophale
1890-1915 : rationalisation
opérations unitaires
1803 : théorie des atomes1790 : 1er procédé industriel
de production d'alcalis
100 ans
13
Analyse des besoins [email protected]
Status duGénie Logiciel
30 ans (seulement) d'expérience et de recherche dans le domaine• trop souvent reste de l'artisanat• souvent atteint un niveau commercial• ingénierie dans certains cas isolés
(1) Artisanat
(2) Production
(3) Commerce
(4) Science
(5) Ingénierie
1950 – 1960programmation ad-hoc
cas isolés : compilateurs,logiciels critiques, ...
1950 : théorie des langages1960 : algèbre relationnelle
1970 : crise du logiciel
1980 : méthodes de développement ...
14
Analyse des besoins [email protected]
Génie Logiciel ?
“The engineer is expected to demonstrate that the design satisfies the specifications."
Méthodes formelles existantes mais encore peu utilisées
“A highly developed sense of responsability toward his clients and the public”
“X-Software Ltd. does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from use of this software...”
15
Analyse des besoins [email protected]
Génie Logiciel ?
" Engineering practice enables ordinary practitioners so they can create sophisticated systems that work -
unspectacularly, perhaps, but reliably"
Etude récente effectuée aux états unis [Standish Group 1995]
• 31% des projets non achevés ou abandonnés à la livraison
• 53% des projets dépassent les ressources allouées
• 16% des projets se déroulent comme prévu
16
Analyse des besoins [email protected]
Echecs logiciels
• AT&T, 1992: interruption du service téléphonie pendant 5 heures à l'est des états unis.
• Aréoport de Denver, 1994:logiciel de suivi des bagages, coût 3 millard de $, retard de 18 mois.
• Oslo, Sept. 1993 : erreur dans le système de contages des votes du parlement => nouvelles éléctions
• etc, etc.
Ari
ane
5
$370 000 000
Out of range
17
Analyse des besoins [email protected]
Echec du Génie Logiciel ?
• Echec du Génie Logiciel ? Non !– de très nombreuses avancées
– les logiciels sont de plus en plus demandés et utilisés
– des logiciels construits sont de plus en plus complexes
• Des progrès restent à faire... Un sujet essentiel !– recherche
– pratique industrielle
– enseignement
18
Analyse des besoins [email protected]
Importance grandissante du logiciel
MATERIEL
LOGICIEL
1950 1970 1990
Coût (%)
50%
10%
100% Valeur du logiciel au états unis
• 1980 : 2% of PNB
• 1985 : 8% of PNB
• 1990 : 13% of PNB
Augmentation de 12% par an
La valeur des logiciels existant sur la planète dépasse la valeur des gisements pétroliers !
Une amélioration de rendement même faiblepeut avoir des répercutions trés importantes
19
Analyse des besoins [email protected]
Définition : "Logiciel"
“Computer programs and the associated documentation required to develop, operate and maintain them”
[Boehm76]
• Erreur courante : logiciel = code source
• Pas uniquement le code source !– binaires, librairies, manuel utilisateurs, etc.
– spécifications, dossier de conception, test, etc.
• Savoir programmer n'est qu'un "détail" !
20
Analyse des besoins [email protected]
Logiciels industriels
• Taille– des millions de lignes de code, milliers de modules, ...
• Durée de vie– 5 à 20 ans ... à 50 ans
• Taille des équipes– 3 à 50 ... à 1000 ingénieurs logiciels
– équipes réparties autour de la planète
• Coût de développement et de maintenance– de centaines de milliers de francs ... à des millards
21
Analyse des besoins [email protected]
Approches
• Gestion du produit et des ressources– gestion de projet, estimation des coûts,...
– assurance qualité, standardisation, ...
• Méthodes– méthodes formelles, semi-formelles, informelles
• Outils– outil de modélisation, génération de code, ...
– gestionnaire de configuration, outil de communication...
22
Analyse des besoins [email protected]
Résumé
• Les logiciels sont de plus en plus complexes
• Le rôle du logiciel dans la société est essentiel
• La programmation empirique mène à l'échec
• La programmation est un « détail » en informatique
• De nombreuses techniques de GL sont disponibles
• L'enseignement du Génie Logiciel est fondamental
Le génie logiciel n'est pas encoreune discipline d'ingénierie très mûre
mais elle doit le devenir
Analyse des besoins
Problématique Capture des besoins
Définition des besoins
(Spécification des besoins)
24
Analyse des besoins [email protected]
Que veux dire Rothschild ?
"There are three ways to loose money:women, gambling and engineers.
The two former are the more comfortable ones, the latter the most certain"
- bankier Rothschild -
25
Analyse des besoins [email protected]
Problématique
• Beaucoup de systèmes informatiques ne sont jamais utilisés car ils ne correspondent pas aux besoins du client !– « Ce n ’est pas ce que je voulais… »
– « Ca ne sert à rien... »
– « Comment je fais ça ?»
– « Ce n’est pas le bon résultat ! »
– « Je vous avais dis que je voulais ça ! »
– ...
26
Analyse des besoins [email protected]
Causes
• Le client ne sais pas ce qu’il veut
• Le client ne sais pas exprimer ce qu’il veut
• L’informaticien ne comprend pas client
• Le client ne comprend pas l’informaticien
• Ce que le client veut n’est pas ce qu’il voulait
27
Analyse des besoins [email protected]
Des difficultés réelles !
• Difficultés de communiquer– difficulté d’être précis, cohérent, complet, ...
– différences de culture : • les utilisateurs ne sont pas informaticiens…
• les informaticiens ne connaissent pas le domaine...
• Complexité du problème– problème non formalisé
– problème complexe
• Évolutivité
28
Analyse des besoins [email protected]
Analyse des besoins
• L ’une des étapes les plus importantes– étape déterminante pour la suite
– aspects contractuels
• L ’une des étapes les plus difficiles– différents intervenants :
le client, les utilisateurs, les développeurs…
– le problème n’est pas encore formalisé
29
Analyse des besoins [email protected]
Différents rôles
• Identifier les différents intervenants :– Le(s) client(s)
– Les utilisateurs
– Le maître d’œuvre
– Les développeurs
– ...
• Identifier le rôle de chacun
• Éventuellement associer des priorités
• Le client est roi (mais quand même)
30
Analyse des besoins [email protected]
Différentes étapes
• Capture des besoins– collecte des informations : interviews, lecture de doc.
– chercher à comprendre : (1) le domaine (2) le problème
• Définition des besoins– restitution dans un langage compréhensible par le client
– identification, structuration, définition d'un dictionnaire
• Spécification des besoins– spécification détaillée des besoins, plus formel
– utile pour le client, mais aussi pour les développeurs
31
Analyse des besoins [email protected]
Capture des besoins : collecter
Objectifs– comprendre le domaine
– comprendre le problème
(1) Collecter le maximum d ’informations– Lecture des documents fournis
– Interviews du client, des utilisateurs, …
– Réunions de travail
– Collecter des exemples pour valider
– Étudier les systèmes existants le cas échéant
32
Analyse des besoins [email protected]
Capture des besoins : interagir
(2) Réagir et être actif !
• Établir la liste des documents consultés, les classer
• Élaborer une liste de questions précises– les numéroter, les dater, …
– faire référence aux documents concernés
• Écrire un ou plusieurs documents et les diffuser
• Provoquer les réunions et les mener– établir l’ordre du jour
– prendre des notes
– faire systématiquement des comptes rendus écrits
33
Analyse des besoins [email protected]
Définition des besoins
• Restituer les informations sous forme synthétique
• Ce qui n’est pas écrit n’existe pas !
• Préciser les besoins, pas la solution
• Préciser ce que doit faire le système – et aussi ce qu’il n ’est pas sensé faire.
– mais surtout pas comment il doit le faire.
• Etablir des priorités
• Arriver à un consensus avec le client
34
Analyse des besoins [email protected]
Différents types de besoins
• Besoins fonctionnels– à quoi sert le système
– ce que doit faire le système, les fonctions utiles
• Besoins non fonctionnels– performance, sûreté, confidentialité, portabilité, etc.
– chercher des critères mesurables
35
Analyse des besoins [email protected]
Quelques conseils
• Les besoins doivent être compris par tous– utiliser la langue naturelle
– utiliser des schémas si nécessaire• tout schéma doit être commenté
• tout schéma doit toujours comporter un légende
• Structurer le document– suivre un plan standard si disponible
– numéroter les sections, références, index, …
36
Analyse des besoins [email protected]
Langue naturelle … mais technique
• Faire des phrases courtes
• Eviter le conditionnel, le futur
• Eviter les termes ambigus ou subjectifs, ...
• Parler en termes de rôles plutôt que de personnes
• Numéroter les paragraphes si nécessaire
• Utilisation de références précises
• Elaborer un dictionnaire
37
Analyse des besoins [email protected]
Elaboration d'un Dictionnaire
• Indispensable d'avoir un langage commun– définition d'un vocabulaire précis
– client, équipe de développement, utilisateurs
• Utilisation dans les documents et aussi le logiciel !– analyse des besoins (clients)
– base pour le développement du logiciel (développeurs)
– base pour l'interface du logiciel (utilisateurs)
• Technique simple mais efficace !
38
Analyse des besoins [email protected]
Format du dictionnaire
Notion Définition Nom info. Type entité
Pilotage Action de piloter un avion en enchaînant des manœuvres élémentaires
Pilotage paquetage
Instrument Organe d'interaction entre le pilote et l'avion
Instrument classe abstraite
Manche à balai Instrument permettant au pilote de diriger l'avion
MancheABalai classe
Action Définition Nom info. Type entité
Augmenter les gaz
Action permettant d'injecter du carburant pour augmenter la vitesse de l'avion
IncrGaz opération
39
Analyse des besoins [email protected]
Intérêt du dictionnaire
• Outil de dialogue
• Informel, facile à réaliser, facile à faire évoluer
• Permet de décrire la terminologie du domaine– réutilisable dans un autre projet
– permet de détecter les ambiguïtés
• Montre l'essentiel du domaine d'application
• Permet d'assurer la traçabilité
40
Analyse des besoins [email protected]
Construction du dictionnaire
• Partir de la description du problème
• Repérer les groupes nominaux -> notion
• Repérer les groupes verbaux -> action ou notion
• Eliminer les synonymes
• Eliminer les termes inutiles
• Donner des définitions simples
• Permet de se concentrer sur l'essentiel
• Doit être complété et mis à jour !
41
Analyse des besoins [email protected]
Spécification des besoins
• Interface entre le client et les développeurs– doit être compris par les deux
– défini dans le détail ce qui doit être réalisé
– doit être précis car contractuel
• Utilisation de techniques semi-formelles– e.g. diagrammes de cas d'utilisation UML
– e.g. diagrammes de classes UML
42
Analyse des besoins [email protected]
Résumé
• L'analyse des besoins est une étape essentielle
• Origine de toute activité de développement
• Problème de communication client / informaticiens
• Capture des besoins : collecter l'information
• Définition des besoins : restituer les besoins
• Spécification des besoins : définir précisément
• Des techniques informelles mais utiles !
• Besoin également de techniques plus précises…
Le langage UML :une vision globale
44
Analyse des besoins [email protected]
UML = Unified Modeling Language
• UML = « Unified Modeling Language »
• Analyse et conception orientée objet
• Une notation
• Une méthode– « The Unified Software Development Process »
• Des outils– Rational Rose, Objecteering, ...
45
Analyse des besoins [email protected]
La notation UML
• LeS notationS UML : plusieurs notations
• Notations graphiques
• Signification précise
• Notation standard
• Notation très générale
• Notation extensible
46
Analyse des besoins [email protected]
Historique
• 80-90 : apparition de nombreuses méthodes
• 90-95 : + de 50 méthodes orientées objets…
• 95 : première version UML (0.8)
• 97 : standardisation OMG– (Dec, Rational, Microsoft, HP, Oracle…)
• 99 : proposition UML 1.3
• 00 : ...
47
Analyse des besoins [email protected]
LeS notationS UML
• Diagrammes des cas d ’utilisation
• Diagrammes de classes
• Diagrammes de séquence
• Diagrammes de collaboration
• Diagrammes d’états
• Diagrammes d’activités
• ...
48
Analyse des besoins [email protected]
Diagrammes des cas d ’utilisation
SystèmeDeContrôleDAcces
CapteurAIncendie
PorteurDeCarte
Entrer
DébloquerLesPortes
GérerLesCartes
Administrateur
ListerLesTentativesDeFraudes
Gardien
Sortir
49
Analyse des besoins [email protected]
Diagrammes de classes
Client1..4 0..*
titulaires
Consortium
Compte
numérosolde...
1..*
0..1
1
Banque
numéronom
Distributeur0..*
1
0..*
1..*
signataire1
0..*CarteBleue
CoderetraitMax
1..*
AcceptéPar>
50
Analyse des besoins [email protected]
Diagrammes d ’objets
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
titulaires
titulaires
: CarteBleue
titulaires
titulaires
signataire
: CarteBleue
sophie : Client
: Banque
: Banque
fred : Client c4 : Comptetitulaires
: Banque
signataire
: Consortium
: Consortium
: Distributeur
: CarteBleue
signataire
: Distributeur
EstAcceptéPar>
EstAcceptéPar>
EstAcceptéPar>
51
Analyse des besoins [email protected]
Diagrammes de séquence
le compte de P.le distrib. la banquepaul
retirer(500)
débiter(500)
la carte de P.
lireN°Compte()
la reserve
retirerDeLArgent(500,88219)
sortirDesBillets(5)
sortirBillets ()
52
Analyse des besoins [email protected]
Diagrammes de collaboration
le compte de paul
le distributeur la banque
la carte de P.
la reserve de billets
paul
4 : débiter(500)1 : retirer(500)
2 : lireN°Compte()
3 : retirerDeLArgent (500,88219)
6 : prendreBillet()
5 : sortirDesBillets(5)
88219
53
Analyse des besoins [email protected]
Diagrammes d ’états
En attente En attente du code
En vérification
En attente du montant
carte insérée
code frappémauvais code
En distribution
code bon
En attente retrait carte
carte retirée
montant correct
montant incorrect
billets retirés
54
Analyse des besoins [email protected]
Les notations UML au cours du Cycle de Vie
• Les notations UML peuvent être utilisées de l ’analyse des besoins à la conception détaillée
• Avantages – cohérence plus simple à vérifier.
– moins de notations à apprendre !
• Inconvénients– confusion entre les niveaux.
– expliquer à quel niveau on est !
55
Analyse des besoins [email protected]
Le Processus Unifié
• Une méthode relativement détaillée– définition des « travailleurs »
– définition des « activités »
– définition des « résultats » à produire
– processus pas à pas : ça, puis ça, puis ça...
• Pas nécessairement applicable à tous les domaines
• Moins général que la notation
UML : Diagrammes de Cas d‘Utilisation
Acteurs, Cas d’utilisation, Système
Diagrammes de Cas d’utilisation
Modèle de Cas d’utilisation
Scénario
57
Analyse des besoins [email protected]
Les diagrammes de cas d ’utilisation
• Une des notations d ’UML (use-cases)
• But :– définir le système du point de vue des utilisateurs
– définir les limites précises du système
• Notation très simple, compréhensible par tous
• Permet de structurer :– les besoins (cahier des charges)
– le reste du développementCasU1
CasU4
CasU5
CasU2
CasU3
A1
A2
S A3
58
Analyse des besoins [email protected]
Exemple de diagrammes de cas d ’utilisation
RetirerDeLArgentAuDistributeur
ConsulterUnCompte
DeposerDeLArgentSurUnCompte
RetirerDeLArgentDUnCompte
Client
Guichetier
Système bancaire
Directeur
GererLesPrets
CréerUnCompte
59
Analyse des besoins [email protected]
Exemple de diagrammes de cas d ’utilisation
DistributeurDeBillet
BanqueCentrale
Client
RetirerDeLArgentAuDistributeur
ConsulterSonCompte
AssurerLaMaintenance
TechnicienAjouterDesBillets
TransporteurDeBillets
60
Analyse des besoins [email protected]
Exemple de diagrammes de cas d ’utilisation
SystèmeDeContrôleDAcces
CapteurAIncendie
PorteurDeCarte
Entrer
DébloquerLesPortes
GérerLesCartes
Administrateur
ListerLesTentativesDeFraudes
Gardien
Sortir
61
Analyse des besoins [email protected]
Modèle des cas d’utilisation
• Un diagramme de cas d’utilisation décrit :– les acteurs
– les cas d’utilisation
– le système
• Un modèle de cas d’utilisation peut être formé– de plusieurs diagrammes,
– de descriptions textuelles.
CasU1
CasU4
CasU5
CasU2
CasU3
A1
A2
S A3
62
Analyse des besoins [email protected]
Cas d’utilisation (CU)
• Cas d’utilisation (CU) – une manière d’utiliser le système
– une suite d’interactions entre un acteur et le systèmeex: le guichetier peut créer un nouveau compte
• Correspond à une fonction visible par l’utilisateur
• Permet d ’atteindre un but pour un utilisateur
• Doit être utile en soi
CasDUtilisationX
63
Analyse des besoins [email protected]
Le système
• Le système est un ensemble de cas d’utilisation
• Le système contient :– les cas d ’utilisation,
– mais pas les acteurs.
• Un modèle de cas d ’utilisation permet de définir :– les fonctions essentielles du système,
– les limites du système,
– le système par rapport à son environnement.
Système
64
Analyse des besoins [email protected]
Acteurs
• Un Acteur = – élément externe qui interagit avec le système
– rôle qu’un utilisateur joue par rapport au systèmeex: un client, un guichetier
• Une même personne peut jouer plusieurs rôlesex: Maurice est directeur mais peut faire le guichetier
• Plusieurs personnes peuvent jouer un même rôleex: Paul et Pierre sont deux clients
• Un acteur n’est pas forcément un être humainex: un distributeur de billet peut être vu comme un acteur
Client
65
Analyse des besoins [email protected]
Différents types d ’acteurs
• Utilisateurs principauxex: client, guichetier
• Utilisateurs secondairesex: contrôleur, directeur, ingénieur système, ...
• Périphériques externesex: un capteur, une horloge externe, ...
• Systèmes externesex: système interbancaires
Client
66
Analyse des besoins [email protected]
Description des acteurs
• Pour chaque acteur :– choisir un identificateur représentatif de son rôle
– donner une brève description textuelle
Client
Guichetier
Un guichetier est un employé de la banque chargé de faire l’interface entre le système informatique et les clients qu’il reçoit au comptoir. Le guichetier peut réaliser les opérations courantes : création d ’un
compte, dépôt et retrait d ’argent, etc.
67
Analyse des besoins [email protected]
Utilité des acteurs
• La définition d’acteurs permet surtout– de trouver les cas d’utilisation
ex: que peut faire un guichetier ? un client ? le directeur ?
• mais peut aussi être utilisée pour– définir différents points de vues sur le système,
– déterminer des droits d’accès par type d’acteur,
– fixer des ordres de priorités entre acteurs,
– ...
Client
68
Analyse des besoins [email protected]
Description des cas d’utilisation
• Pour chaque cas d ’utilisation– choisir un identificateur représentatif
– donner une description textuelle simple
– la fonction réalisée doit être comprise de tous
– pas trop de détails
– préciser ce que fait le système, ce que fait l’acteur
• Les cas d ’utilisation ne doivent pas se chevaucher
CasDUtilisationX
69
Analyse des besoins [email protected]
Exemple de description d ’un cas d ’utilisationCasDUtilisationX
RetirerDeLArgent
AuDistributeur
Lorsqu’un client à besoin de retirer du liquide il peut en utilisant un distributeur retirer de l ’argent de son compte. Pour cela - le client insère sa carte bancaire dans le distributeur- le système demande le code pour l ’identifier- le client choisi le montant du retrait- le système vérifie qu ’il y a suffisamment d ’argent- si c ’est le cas, le système distribue les billets et retire l ’argent du compte du client- le client prend les billets et retire sa carte
70
Analyse des besoins [email protected]
Relations
GuichetierCréerUnCompte
IdentifierLeClientDeposerDeLArgent
« Utilise »
RetirerDeLArgentAuDistributeur
RetirerDeLArgent
« Étend »
• Communication
• Utilisation
• Extension
71
Analyse des besoins [email protected]
Description du modèle de cas d ’utilisation
• Un modèle de cas d’utilisation peut contenir – plusieurs diagrammes
– plusieurs descriptions textuelles
• Permet d’avoir une vision globale du système
• Permet de définir des priorités entre CU
• Utile pour le client, pour la planification,...
• Trop général pour être utilisé par les développeurs
72
Analyse des besoins [email protected]
Exemple de diagramme de CU décoré
RetirerDeLArgentAuDistributeur
ConsulterUnCompte
DeposerDeLArgentSurUnCompte
RetirerDeLArgentDUnCompte
Client
Guichetier
Directeur
GererLesPrets
CréerUnCompte
Système bancaire
P1
P2
Pi : priorité
12/07/99
12/07/99
20/05/99
P1
P1
P3
P2
25/12/99
10/12/00
10/06/00
73
Analyse des besoins [email protected]
Description détaillée de chaque cas d’utilisation
• Chaque cas d ’utilisation doit être décrit en détail
• Commencer par les CU prioritaires
• Description utile pour la suite du développement
• Description détaillée plus où moins formelle– langue naturelle mais structurée, vocabulaire précis
– diagramme d ’états
– ...
74
Analyse des besoins [email protected]
Informations à décrire
• Quand le CU commence, pré-conditions
• Quand le CU se termine, post-conditions
• Le chemin correspondant au déroulement normal
• Les variantes possibles et les cas d’erreurs
• Les interactions entre le système et les acteurs
• Les informations échangées
• Les éventuels besoins non fonctionnels
75
Analyse des besoins [email protected]
Exemple de description détaillée d ’un CU
RetirerDeLArgent
AuDistributeur
Précondition :Le distributeur contient des billets, il est en attente d ’une opération, il n’est ni en panne, ni en maintenance
Début : lorsqu ’un client introduit sa carte bancaire dans le distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition : Si de l ’argent a pu être retiré la somme d’argent sur le compte est égale à la somme d ’argent qu’il y avait avant, moins le montant du retrait. Sinon la somme d ’argent sur le compte est la même qu’avant.
76
Analyse des besoins [email protected]
Exemple de description détaillée d ’un CU
RetirerDeLArgent
AuDistributeur
Déroulement normal :(1) le client introduit sa carte bancaire(2) le système lit la carte et vérifie si la carte est valide(3) le système demande au client de taper son code(4) le client tape son code confidentiel(5) le système vérifie que le code correspond à la carte(6) le client choisi une opération de retrait(7) le système demande le montant à retirer…
Variantes : (A) Carte invalide : au cours de l ’étape (2) si la carte est jugée invalide, le système affiche un message d ’erreur, rejète la carte et le cas d ’utilisation se termine.(B) Code erroné : au cours de l ’étape (5) ...
77
Analyse des besoins [email protected]
Exemple de description détaillée d ’un CU
RetirerDeLArgent
AuDistributeur
Contraintes non fonctionnelles :
(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l ’action de l ’utilisateur.
(B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d ’utilisation, la transaction sera annulée, l ’argent ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d ’argent simultanément...
78
Analyse des besoins [email protected]
Scénario
• Pour décrire ou valider un CU : les scénarios
• Un scénario est un exemple :– une manière particulière d ’utiliser le système …
– … par une personne particulière …
– … dans un contexte particulier.
• cas d ’utilisation = ensemble de scénarios
• scénario = une exécution particulière d’un CU
79
Analyse des besoins [email protected]
Exemple de scénario
RetirerDeLArgent
AuDistributeur
SCENARIO 4• Paul insère sa carte dans le distributeur d2103 • Le système accepte la carte et lit le numéro de compte • Le système demande le code• Paul tape ‘ 1234 ’• Le système indique que ce n ’est pas le bon code• Le système affiche un message et propose de recommencer• Paul tape ‘ 6622’• Le système affiche que le code est correct• Le système demande le montant du retrait• Paul tape 50000 fr• Le système vérifie s ’il y a assez d ’argent sur le compte•...
80
Analyse des besoins [email protected]
Diagrammes de séquences
• Pour décrire un scénario : diagramme de séquence
• Diagramme de séquences :– L’une des notations UML, une notation générale
– Peut être utilisée dans de nombreux contextes
– Permet de décrire une séquence des messages échangés entre différents objets
– Différents niveaux de détails
• Pour décrire un scénario simple,deux objets : l’acteur et le système
81
Analyse des besoins [email protected]
Exemple de scénario
paul : Client le système
Insérer carte
Entrer code ‘1234 ’
Demander code
Message d ’erreur
Demander code
Entrer code ‘6622 ’
Vérifier carte
Vérifier code
...
82
Analyse des besoins [email protected]
Le Processus Unifié
(1) Définir le modèle de cas d’utilisation(1.1) Trouver les acteurs
(1.2) Décrire brièvement chaque acteur
(1.3) Trouver les cas d ’utilisation
(1.4) Décrire brièvement chaque cas d ’utilisation
(1.5) Décrire le modèle comme un tout
(2) Définir des priorités entre CU
(3) Détailler chaque CU (en tenant compte des priorités)
83
Analyse des besoins [email protected]
Résumé
• Différents concepts UML– Modèle des cas d’utilisation
– Diagramme des cas d’utilisation
– Acteur
– Cas d ’utilisation
– Scénario
• Processus Unifié : commencer par les acteurs
• Utiliser les schémas mais aussi la langue naturelle!
Approche orientée-objet
Objets, Classe
Attribut, Méthode, Message
Réification, Encapsulation, Classification
85
Analyse des besoins [email protected]
Evolution du Génie LogicielModèle des vagues [Racoon97]
Innovation Growth Maturity Convention
10 to 15 years
1950 1973
Vague d’intérêt pour les Modules
1980 1988
Interest
Time
Innovation
new development
basic understanding
Growth
increasingly popular
growing enthusiasm
Maturity
balanced understanding
limits become apparent
Convention
core idea accepted
work on new developements
86
Analyse des besoins [email protected]
Vagues des matériels informatiques
ResearchMainframe
CommercialMainframes
Internet,Ubiquitous Computing
1955 1966 1977 20001945
Commercial Mini
Computers
Personal Computers
87
Analyse des besoins [email protected]
Vagues des techniques de structuration
Statement Function Framework
1958 1973 1988 2003?1945
Module Object
88
Analyse des besoins [email protected]
Différentes approches
• Approche Fonctionnelle– l ’important c’est les traitements
• diviser pour régner
• réutilisation difficile, évolution difficile, ...
• Approche Orientée Objet <====– l’important c’est les objets
• objets = données + traitements
• monde réel => modèle du monde
• réutilisation et évolution simplifiée
89
Analyse des besoins [email protected]
La vague de « l’Orienté Objet »
• Programmation orientée objet – Smalltalk, C++, Java...
• Bases de données orientées objet– O2, Object-store, ...
• Méthodes orientée objet– OMT, HOOD, UML, ...
• Tout (et n ’importe quoi mais) orienté objet
90
Analyse des besoins [email protected]
Orienté Objet
Représenter un système commeun ensemble d’objets autonomes mais
interagissant via des envois de messages
Chaque objet– représente un objet ou un concept de la vie réelle
– a une identité unique et invariante
– a un état caractérisé par la valeur de ses attributs
– propose des services sous la forme de méthodes
– exécute un service lorsque l’objet reçoit un message
91
Analyse des besoins [email protected]
Objets
le distributeur
le compte de Paul
la banque
Paul
Pierre
le compte de Pierre
la réserve de billet
la carte bancaire de PaulMarie
Le compte de Pierre et de Marie
Un système peut être vu comme un ensemble d ’objets
92
Analyse des besoins [email protected]
Principe de réification
• Réification = matérialiser un concept par un objet
• Un concept abstrait peut être « réifié »– l’événement « à 10h45 une carte bleue à été introduite »
• Une relation entre deux objets peut être « réifié »– « jean possède la voiture immatriculée 875 QV 38 » est réifié dans le
monde réel par une carte grise
• Réifier un concept permet de le manipuler concrètement
• Question ouverte : quels concepts réifier ?
• Un «bon» modèle réifie les «bons» concepts…
93
Analyse des besoins [email protected]
Attributs et méthodes
Chaque objet• a un état caractérisé par la valeur de ses attributs• propose des services sous la forme de méthodes
la banque
numéro = 2453nom = « banque du sud »…
Créer un compteSupprimer un compteFaire un virementRetirer de l ’argent…
numéro = 88219solde = 2000découvert max = -500
le compte de Paul
ConsulterSoldeCréditerDébiter
le compte de Pierre
numéro = 88213solde = 10découvert max = -100
ConsulterSoldeCréditerDébiter
94
Analyse des besoins [email protected]
Envois de messages
Les objets interagissent par des envois de messages
le compte de paul
le distributeur la banque
la carte de P.
la reserve de billets
paul
4 : débiter1 : retirer
2 : lireN°Compte
3 : retirerDeLArgent
5 : sortirDesBillets
95
Analyse des besoins [email protected]
Principe d’encapsulation
• Chaque objet indique les méthodes qu’il expose (son interface)ex: on sait que le distributeur permet de retirer de l’argent
• mais cache la réalisation concrète des méthodesex: on sait pas ce que fait le distributeur de manière interne lorsqu’il reçoit le
message retirer de l’argent
• et n’expose jamais ses attributs directementex: on ne sait pas si le distributeur garde le nombre d ’opérations effectuées, la
date de la dernière opération, etc.
• sauf via éventuellement des méthodesex: on peut consulter le solde d ’un compte, créditer ou débiter un compte,
mais pas modifier directement l’attribut solde
96
Analyse des besoins [email protected]
Avantages du principe d’encapsulation
• Un client ne connaît que l’interface de l’objet– l’objet est plus simple à comprendre
ex: pas la peine de comprendre le contenu d ’un magnétoscope pour pouvoir l ’utiliser.
– l’objet plus simple à réutiliserex: si l’interface est bien définie on peut le brancher à d ’autres appareils
(chaîne hi-fi, télévision, …)
– l ’objet est protégé contre les mauvaises utilisationsex: on ne peut pas mettre les doigts dans le magnétoscope ni enlever la cassette
pendant que le moteur tourne...
97
Analyse des besoins [email protected]
Avantages du principe d’encapsulation
La réalisation de l’objet peut être modifiée sans impact sur le client
• on peut améliorer l’objet et le faire évoluer ex: mettre un moteur plus rapide dans le magnétoscope,
remplacer un composant par un autre équivalent
• on pourrait remplacer l’objet par un autre équivalentex: pas de problème pour passer d ’un magnétoscope à un autre
98
Analyse des besoins [email protected]
Principe de classification
• Regrouper des objets similaires en classes
• Une classe est un modèle, un «moule»
• Chaque objet est une instance d’une classe
• Une classe permet d’instancier plusieurs objets
• Une classe est caractérisée par– ses attributs
– ses méthodes
99
Analyse des besoins [email protected]
Classes vs. Objets
le compte de Pierrenuméro = 88213solde = 20découvert max = -100
ConsulterSoldeCréditerDébiter
ComptenumérosoldedécouvertConsulterSoldeCréditerDébiter
Niveau des objets(instances)
Niveau des classes(modèle)
le compte de Paulnuméro = 88219solde = 5000découvert max = -500
ConsulterSoldeCréditerDébiter
« InstanceDe »« InstanceDe »
100
Analyse des besoins [email protected]
Exemple de classification
le distrib. D11
le compte de Paul
une banque
paul
pierre
le compte de Pierremarie
le compte de Pierre et de Mariejohn
Client Compte Banque Distributeur
le distrib. D28
Niveau des classes
Niveau des objets
101
Analyse des besoins [email protected]
Avantages du principe de classification
• Modèle plus simple– il y a beaucoup moins de classes que d’objets
– les objets d’une même classe sont similaires
– l’ensemble des classes ne change pas pendant l’exécution
• Modèle plus général– le modèle est indépendant de l’état des objets
– le modèle est indépendant du nombre d’objets
• Modèle réutilisable– une classe est un composant logiciel réutilisable
UML :Diagrammes de Classes
Objet, Classe, Attribut, Méthode
Lien, Association, Cardinalité
Généralisation, Spécialisation Composition
Composition, Classe Associative, …
103
Analyse des besoins [email protected]
Concepts de base
• UML est basé sur différents concepts de base :– Objet, Classe
– Lien, Association
– Contrainte
• UML propose des notations et des diagrammes – Diagramme de classes (description au niveau modèle)
– Diagramme d’objets (description au niveau instance)
104
Analyse des besoins [email protected]
Notation pour les classes
Compte
numéro : entier solde : réeldécouvertMax : entier
consulterSolde() : entiercréditer( somme : entier)débiter( somme : entier)
Nom de la classe
Attributsnomtype
Méthodesnomparamètretype du résultat
Contraintes{ solde > découvertMax }
105
Analyse des besoins [email protected]
Notations simplifiées pour les classes
Compte
numérosolde : réeldécouvertMax : entier
consulterSolde() : entiercréditer( somme : entier)débiter( somme )
Compte
numérosolde...créditer()débiter()...
Compte
numérosolde...
Compte
créditer()débiter()...
Compte
Conventions :• les noms de classes commencent par une majuscule• les noms d ’attributs et de méthodes commencent par une minuscule
106
Analyse des besoins [email protected]
Notations pour les objets
leCompteDePaul : Compte
numéro = 6688 solde = 5000découvertMax = -100
leCompteDePaul
: Compte
leCompteDePaul : Compte
Convention :• les noms d ’objets commencent par une minuscule et sont soulignés
107
Analyse des besoins [email protected]
Liens (entre objets)
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
APourCompte>
APourCompte>
APourCompte>
Un lien indique une connexion entre deux objets
Conventions :• les noms des liens sont des formes verbales et commencent par une majuscule• > indique le sens de la lecture (ex: « paul APourCompte c1 »
108
Analyse des besoins [email protected]
Rôles
c1 : Comptepierre : ClientAPourCompte>
titulaire compte
Chacun des deux objets joue un rôle diffèrent dans le lien
Conventions :• choisir un groupe nominal pour désigner un rôle• si un nom de rôle est omis, le nom de la classe fait office de nom
pierre assume le rôle de titulaire pour le compte c1c1 assume le rôle de compte pour pierre
109
Analyse des besoins [email protected]
Associations (entre classes)
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
APourCompte>
APourCompte>
APourCompte>
Diagramme d ’objets
(instances)
Diagramme de classes(modèle)
Client CompteAPourCompte>
Une association décrit un ensemble de liens de même sémantique
110
Analyse des besoins [email protected]
Liens vs. Associations
• Un lien lie deux objets
• Une association lie deux classes
• Un lien est une instance d’association
• Une association décrit un ensemble de liens
• Des liens peuvent être ajoutés ou créés pendant l ’exécution, ce n ’est pas le cas des associations
111
Analyse des besoins [email protected]
Cardinalités d’une association
• Précise combien d’objets peuvent être liés à un seul objet source
• Cardinalité minimale et cardinalité maximale ( Cmin..Cmax)
Client Compte1
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
APourCompte>
APourCompte>
APourCompte>
APourCompte> 0..*
titulaire comptes
« Un client a 0 ou plusieurs comptes »« Un compte a toujours 1 et 1 seul titulaire »
112
Analyse des besoins [email protected]
Utiliser les rôles pour «naviguer»
Client Compte1 APourCompte> 0..*
titulaire comptes
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
APourCompte>
APourCompte>
APourCompte>
paul.comptes = {c1}pierre.comptes = {c2,c3}marie.comptes = {}c1.titulaire = paulc2.titulaire = pierrec3.titulaire = pierre
113
Analyse des besoins [email protected]
Contraintes entre associations
ClientCompte
numérosolde...
1 0..*titulairePrincipal
co-titulaires0..* 0..*
titulaires1..* 0..*
(1) Un client ne peut pas être à la fois titulaire principal et co-titulaire d ’un même compte.(2) Les titulaires d ’un compte sont le titulaire principal et les co-titulaires le cas échéant
Les cardinalités ne permettent pas d’exprimer toutes les contraintes...
… décrire les contraintes en langue naturelle (ou en OCL le langage de contrainte d’UML)
114
Analyse des besoins [email protected]
Diagramme de classes
Client1..4 0..*
titulaires
Consortium
Compte
numérosolde...
1..*
0..1
1
Banque
numéronom
Distributeur0..*
1
0..*
1..*
signataire1
0..*CarteBleue
CoderetraitMax
1..*
EstAcceptéPar>
(1) Le signataire de la carte bleue associée à un compte est l ’un des titulaires de ce compte.(2) Une carte bleue est acceptée au moins dans tous les distributeurs appartenant aux consortiums de la banque correspondant au compte associé à la carte bleue.(3) Un virement est possible entre deux comptes distincts si les banques correspondantes appartiennent à un même consortium.
virementPossible
0..*
115
Analyse des besoins [email protected]
Diagrammes d’objets
c1 : Compte
c2 : Compte
paul : Client
pierre : Client
marie : Client c3 : Compte
titulaires
titulaires
: CarteBleue
titulaires
titulaires
signataire
: CarteBleue
sophie : Client
: Banque
: Banque
fred : Client c4 : Comptetitulaires
: Banque
signataire
: Consortium
: Consortium
: Distributeur
: CarteBleue
signataire
: Distributeur
EstAcceptéPar>
EstAcceptéPar>
EstAcceptéPar>
116
Analyse des besoins [email protected]
Diagrammes de classes vs. d’objets
• Un diagramme de classes – défini l’ensemble de tous les états possibles
– les contraintes doivent toujours être vérifiées
• Un diagramme d’objets – décrit un état possible à un instant t, un cas particulier
– doit être conforme au modèle de classes
• Les diagrammes d’objets peuvent être utilisés pour– expliquer un diagramme de classe (donner un exemple)
– valider un diagramme de classe
117
Analyse des besoins [email protected]
Diagrammes de classes vs. d’objets
Client1..4 0..*
titulaires
Consortium
Compte
numérosolde...
1..*
0..1
1
Banque
numéronom
Distributeur0..*
1
0..*
1..*
signataire1
0..*CarteBleue
CoderetraitMax
1..*
EstAcceptéPar>
virementPossible
0..*
titulaires
titulaires
: Banque
signataire
: Distributeur
: Compte:
Compte
: Client: Client
: Compte
titulaires
:
titulaires
:
: Client
: Banque
: Banque
: Client
: : : Consortium
: Consortium
: Distributeur
::
>
>
>
...: Compte:
Compte
: Client: Client
: Compte
titulaires
:
titulaires
:
: Client
: Banque
: Banque
: Client
: : : Consortium
: Consortium
: Distributeur
::
>
>
>
: Compte:
Compte
: Client: Client
: Compte
titulaires
:
titulaires
:
: Client
: Banque
: Banque
: Client
: : : Consortium
: Consortium
: Distributeur
::
>
>
>
t1 t2 t3
118
Analyse des besoins [email protected]
Synthèse des concepts de base
• Classe– attribut
– méthode
• Association– rôle
– cardinalité
Objet Lien
Contrainte
119
Analyse des besoins [email protected]
Exemple
Personne Société1..* 0..1
employés
directeur0..1
*
subordonnés
(1) Le directeur de tout employé est employé dans la même société.(2) Dans toute société il y a au moins une personne qui n ’est dirigée par personne (le directeur de la société).(3) Une personne ne peut pas être directeur d ’elle même...
120
Analyse des besoins [email protected]
Exemple
époux
0..1Personne épouse
0..1
père 0..1
parents 0..2
enfants *
paul épouse marieépoux
joe
pére mère
mère 0..1
sexe enfants
parents
enfantsparents
121
Analyse des besoins [email protected]
Navigation
Client Compte1
titulaire
Association unidirectionnelleOn ne peut naviguer que dans un sens
Ce détail n’est a priori utile que lors de la conception détaillée
122
Analyse des besoins [email protected]
Composition
DocumentChapitre Section
Une composition est un cas particulier d’association avec des contraintes en plus permettant de décrire la notion de composant...
Figure
1..*
Un objet composant ne peut être que dans un seul objet compositeUn objet composant n’existe pas sans son objet compositeSi un objet composite est détruit, ses composants aussi
1..*1
0..*
1..*
123
Analyse des besoins [email protected]
Composition
DocumentChapitre Section
Figure
1..* 1..*1
0..*
1..*
: document
: chapitre
: chapitre
: section
: section
: figure
: figure
: section
Les composants forment un arbre
125
Analyse des besoins [email protected]
Classes associatives
Personne Sociétéemployé
* 0..2
Dans certains cas il est utile d’associer des attributs et/ou des méthodes aux associations => classes associatives
Emploi
salaire
augmenter()
Le nom de la classe correspond au nom de l’association
société
126
Analyse des besoins [email protected]
Classes associatives
Personne Sociétéemployé
* 0..2
Emploi
salaire
augmenter()
s1pierre
employémarie
s1
employé
employé e2
salaire = 2000
e1
salaire = 10000
e3
salaire = 16000
Le salaire est une information correspondant • ni à une personne, • ni à une société,
mais à un emploi (un couple personne-société).
société
127
Analyse des besoins [email protected]
Classes associatives
p1 Emploi>
s1
Pour une association donnée, deux objets ne peuvent être connectés que par un seul lien correspondant à cette association.
Emploi>
Cette contrainte reste vraie dans le cas où l’association est décrite à partir d ’une classe associative.
p1 s1
: Emploi
salaire = 10000
: Emploi
salaire = 2000
128
Analyse des besoins [email protected]
Classes associatives
Personne Sociétéemployé
* 0..2
Emploi
salaire
Personne Sociétéemployé
1 1
0..2
société
sociétéEmploi
salaire
*
Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société
Ci-dessus, une personne peut avoir deux emplois dans la même société
e2
p1 s1 e1
p1 s1
e1
129
Analyse des besoins [email protected]
Classes associatives
compte
compteCrédité
*
Virement
montant
*compteDébité
compte
compteCrédité1
Virement
montant
1compteDébité
* *
Ou ?
130
Analyse des besoins [email protected]
Classes associatives
Les classes associatives sont des associations mais aussi des classes. Elles ont donc les mêmes propriétés et peuvent par exemple être liées par des associations.
Personne Sociétéemployé
*
Emploi
salaire
augmenter()
société
responsable
subordonnés
*
0..1
*
131
Analyse des besoins [email protected]
Contraintes sur les associations
Contraintes prédéfinies sur les associations. Par exemple :• { frozen } : fixé lors de la création de l ’objet, ne peut pas changer• { ordered } : les éléments de la collection sont ordonnés• { addOnly } : impossible de supprimer un élément
RelevéDeCompte
LigneOpération*
{ordered,addOnly}
lignes
Il est possible de définir de nouvelles contraintes
132
Analyse des besoins [email protected]
Synthèse sur les associations
<AssociationX
Cardinalités
ClasseA ClasseBroleA 0..*
attributZ
{frozen}
Nom de rôle Nom d ’association
AssociationX
Contrainte
Navigation
Classe associative
Composition
133
Analyse des besoins [email protected]
Généralisation / Spécialisation
Une classe peut être la généralisation d ’une ou plusieurs autres classes. Ces classes sont alors des spécialisations de cette classe.
Super classe
Sous classes
Personne
FemmeHomme
Compte
CompteEpargne
134
Analyse des besoins [email protected]
Généralisation / Spécialisation
Vision ensembliste :tout objet d’une sous-classe appartient également à la super-classe=> inclusion des ensembles d’objets
CompteEpargne
ce1
ce2
ce3
c2
c2
c1
c3Compte
Compte CompteEpargne
135
Analyse des besoins [email protected]
Héritage
Compte
solde
créditer()débiter()
CompteEpargne
tauxIntérêt
ajouterIntérêts ()
Les sous-classes « héritent » des propriétés des super-classes(attributs, méthodes, associations, contraintes)
Banque*CompteEpargne
soldetauxIntérêt
créditer()débiter()calculIntérêts ()
Banque*{solde > -5000}
{tauxIntérêt < 100}
{solde > -5000 et tauxIntérêt < 100}
136
Analyse des besoins [email protected]
Redéfinition
Figure
surface()déplacer()
Cercle
surface()
Polygone
surface()
Une sous classe peut redéfinir une propriété, à condition toutefois de rester compatible avec la définition originale
Carre
surface()
137
Analyse des besoins [email protected]
Héritage multiple
Une classe peut hériter de plusieurs super-classes
Certains langages de programmation interdisent l’héritage multiple
Chauffage AppareilÉlectrique
Chauffage Électrique
PoelAMazout
Appareil
FourAMicroOndes
138
Analyse des besoins [email protected]
Points liés à l’héritage et à la classification
Les modèles orientés-objets ne font pas tous les mêmes hypothèses
Héritage simple vs. héritage multipleUne classe peut elle hériter de plusieurs classes ?
Classification simple vs. classification multipleUn objet peut-il être simultanément instance de plusieurs classes?
Classification statique vs. classification dynamiqueUn objet peut-il changer de classe pendant l’exécution ?
139
Analyse des besoins [email protected]
Points liés à l ’héritage et à la classification
Sauf si le contraire est indiqué explicitement, en UML les hypothèses par défaut sont :
Héritage multipleune classe peut hériter de plusieurs classes
Classification simpleun objet est instance d ’une seule classe
Classification statiqueun objet est créé à partir d’une classe donnée et n’en change pas
140
Analyse des besoins [email protected]
Exemple
Femme Hommeépouse époux
0..1 0..1
Personne
mère père0..1 0..1
* *
parents 0..2 enfants*
141
Analyse des besoins [email protected]
Exemple
Compte
solde
créditer()débiter()
CompteEpargne
tauxIntérêt
ajouterIntérêts ()
Opérationdatemontant
Débit Crédit
{montant<0}
RetraitVirement
RetraitEspèce
RetraitGuichet
RetraitDistributeur Distributeur
{addOnly,ordered}
{montant>0}
*
1
1*
1
destinataire
142
Analyse des besoins [email protected]
Vers une implantation concrète
UML : de l ’analyse à la conception détailléeRaffinement successifs, plus ou moins de détailsChoix d ’implantation
outils utiliséscompromis espace mémoire / rapidité d ’exécution …
Génération manuelle ou automatique de codegénération partielle, squelettes de programmeliaison inverse
143
Analyse des besoins [email protected]
Différentes techniques d’implantation
Différentes techniques d ’implantations possibleslangage de programmation (de préférence orienté objet)base de données (de préférence orientée objet)...
Respecter les contraintes d ’implantationsex: langage java
héritage simple, classification simple et statiquepas d ’associations
Traduction systématique vs. optimisation
144
Analyse des besoins [email protected]
Exemple
Compte
numérosolde
créditer()débiter()
Client
nom
Banque
*
1
1 *
comptes
titulaire
clients*Il doit y avoir suffisamment d ’argent sur le compte lors d ’un débit
145
Analyse des besoins [email protected]
Exemple
Compte
Client
nom
*
1
1 *
comptes
titulaire
clients*
Banque
créerCompte(nom) : intsupprimerCompte(numéro)compteNuméro(numéro) : ComptecompteClient(nom) : Compte
lireSolde() : intcréditer( montant ) débiter( montant )lireTitulaire() : ClientlireBanque() : Banque
comptes
146
Analyse des besoins [email protected]
Exemple
Compte
- solde : int- decouvertMax : int- titulaire : Client
+ lireSolde() : int+ créditer( montant : int )
{ pré-condition : montant >0 post-condition : solde + montant = solde’ }
+ débiter( montant : int ){ pré-condition : montant >0 et solde-montant > decouvertMax post-condition : solde - montant = solde’ }
+ lireClient() : client
147
Analyse des besoins [email protected]
Exemple
class Compte { private int solde ; private int découvertMax ; private Client titulaire ;
public int lireSolde() { return solde ; }
public void débiter( int montant ) { if (montant<=0 || solde-montant < decouvertMax) throw new Exception() ; solde = solde - montant ; } ...}
+ lireSolde() : int+ créditer( montant : int )+ débiter( montant : int )…
Compte
- solde : int- decouvertMax : int- titulaire : Client
148
Analyse des besoins [email protected]
Exemple
class Compte { private Vector opérations ; private int découvertMax ; private Client titulaire ;
public int lireSolde() { int r = 0 ; for (i=0;opérations.size();i++) r = r = opérations.at(i).montant ; return r ; }
public void débiter( int montant ) { if (montant<=0 || lireSolde()-montant < lireSolde) throw new Exception() ; ...}
+ lireSolde() : int+ créditer( montant : int )+ débiter( montant : int )…
Compte
- opérations : Vector- decouvertMax : int- titulaire : Client