analyse des besoins introduction à la notation uml dess cci cours de génie logiciel tronc commun...

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]

Génie Logiciel

Du "codeur"

... au "programmeur"

… à "l'ingénieur logiciel"

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


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


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%


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 ?


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


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.


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


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


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


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


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


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


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


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


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


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


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


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)

[email protected]

24


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


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


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


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

• 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

[email protected]

44


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


La notation UML

• LeS notationS UML : plusieurs notations

• Notations graphiques

• Signification précise

• Notation standard

• Notation très générale

• Notation extensible

46


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


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


Diagrammes des cas d ’utilisation

SystèmeDeContrôleDAcces

CapteurAIncendie

PorteurDeCarte

Entrer

DébloquerLesPortes

GérerLesCartes

Administrateur

ListerLesTentativesDeFraudes

Gardien

Sortir

49


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


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


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


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


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


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


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

[email protected]

57


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


Exemple de diagrammes de cas d ’utilisation

RetirerDeLArgentAuDistributeur

ConsulterUnCompte

DeposerDeLArgentSurUnCompte

RetirerDeLArgentDUnCompte

Client

Guichetier

Système bancaire

Directeur

GererLesPrets

CréerUnCompte

59



DistributeurDeBillet

BanqueCentrale

Client


ConsulterSonCompte

AssurerLaMaintenance

TechnicienAjouterDesBillets

TransporteurDeBillets

60



SystèmeDeContrôleDAcces

CapteurAIncendie

PorteurDeCarte

Entrer

DébloquerLesPortes

GérerLesCartes

Administrateur

ListerLesTentativesDeFraudes

Gardien

Sortir

61


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


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


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


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


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


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


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


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


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


Relations

GuichetierCréerUnCompte

IdentifierLeClientDeposerDeLArgent

« Utilise »


RetirerDeLArgent

« Étend »

• Communication

• Utilisation

• Extension

71


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


Exemple de diagramme de CU décoré


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


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


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


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



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



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


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


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


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


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


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


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

[email protected]

85


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


Vagues des matériels informatiques

ResearchMainframe

CommercialMainframes

Internet,Ubiquitous Computing

1955 1966 1977 20001945

Commercial Mini

Computers

Personal Computers

87


Vagues des techniques de structuration

Statement Function Framework

1958 1973 1988 2003?1945

Module Object

88


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


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


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


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


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


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


94


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


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


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


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


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


Classes vs. Objets

le compte de Pierrenuméro = 88213solde = 20découvert max = -100


ComptenumérosoldedécouvertConsulterSoldeCréditerDébiter

Niveau des objets(instances)

Niveau des classes(modèle)

le compte de Paulnuméro = 88219solde = 5000découvert max = -500


« InstanceDe »« InstanceDe »

100


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


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

[email protected]

103


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


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


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


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


Liens (entre objets)

c1 : Compte

c2 : Compte

paul : Client

pierre : Client


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


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


Associations (entre classes)

c1 : Compte

c2 : Compte

paul : Client

pierre : Client


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


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


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


APourCompte>

APourCompte>

APourCompte>

APourCompte> 0..*

titulaire comptes

« Un client a 0 ou plusieurs comptes »« Un compte a toujours 1 et 1 seul titulaire »

112


Utiliser les rôles pour «naviguer»

Client Compte1 APourCompte> 0..*

titulaire comptes

c1 : Compte

c2 : Compte

paul : Client

pierre : Client


APourCompte>

APourCompte>

APourCompte>

paul.comptes = {c1}pierre.comptes = {c2,c3}marie.comptes = {}c1.titulaire = paulc2.titulaire = pierrec3.titulaire = pierre

113


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


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


Diagrammes d’objets

c1 : Compte

c2 : Compte

paul : Client

pierre : Client


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


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


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


Synthèse des concepts de base

• Classe– attribut

– méthode

• Association– rôle

– cardinalité

Objet Lien

Contrainte

119


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


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


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


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


Composition

DocumentChapitre Section

Figure

1..* 1..*1

0..*

1..*

: document

: chapitre

: chapitre

: section

: section

: figure

: figure

: section

Les composants forment un arbre

124


Composition

Point

xy

Polygone 3..* Cercle

rayon1

125


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




* 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



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




* 0..2

Emploi

salaire


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



compte

compteCrédité

*

Virement

montant

*compteDébité

compte

compteCrédité1

Virement

montant

1compteDébité

* *

Ou ?

130



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.


*

Emploi

salaire

augmenter()

société

responsable

subordonnés

*

0..1

*

131


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


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


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


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


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


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


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


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


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


Exemple

Femme Hommeépouse époux

0..1 0..1

Personne

mère père0..1 0..1

* *

parents 0..2 enfants*

141


Exemple

Compte

solde


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


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


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


Exemple

Compte

numérosolde


Client

nom

Banque

*

1

1 *

comptes

titulaire

clients*Il doit y avoir suffisamment d ’argent sur le compte lors d ’un débit

145


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


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


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


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

analyse des besoins introduction à la notation uml dess cci cours de génie logiciel tronc commun...

Documents