Méthodes avancées pour les systèmes d information

Méthodes avancées pour les systèmes d information Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon ISI3 - Méthodes avancées pour les systèmes d information 2012 1 / 76

Adresses utiles http ://liris.cnrs.fr/laetitia.matignon/enseignementsisi3.html transparents de cours (sans correction des exercices) énoncés de TD/TP (à venir) quelques corrigés de TD bibliographie Laëtitia Matignon ISI3 - Méthodes avancées pour les systèmes d information 2012 2 / 76

Organisation pédagogique 5 séances CM/TD (5 4h) 3 séances TP (3 4h) Contrôle continu : travaux pratiques/projet, contrôles rapides éventuels en cours d année Examen écrit final (08-04-2013) Laëtitia Matignon ISI3 - Méthodes avancées pour les systèmes d information 2012 3 / 76

Objectif Comprendre ce qu est un système d information dans ses différentes dimensions Définition d un Système d Information Un SI est un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures... permettant d acquérir, de traiter, de stocker des informations (sous formes de données, textes, images, sons,...) dans et entre des organisations. Laëtitia Matignon ISI3 - Méthodes avancées pour les systèmes d information 2012 4 / 76

Objectifs Rappels de programmation orientée objet Modélisation, implémentation Exemples en Java et C++ Savoir exprimer les besoins fonctionnels d un système d information Utiliser de façon naturelle les principaux diagrammes UML Diagrammes statiques Diagrammes dynamiques Utiliser des patrons de conception Processus de conception des SI Laëtitia Matignon ISI3 - Méthodes avancées pour les systèmes d information 2012 5 / 76

1. Rappels de programmation orientée objet Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 6 / 76

Objectifs du cours Rappel des concepts fondamentaux de la POO Notion d objet Classe / Abstraction Encapsulation des données / traitements Généralisation / Héritage Polymorphisme de traitement et d héritage Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 7 / 76

Plan Notion d objet informatique 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 8 / 76

Notion d objet informatique Notion d objet en informatique Peut correspondre à une entité concrète (animal, véhicule,...) ou abstraite, conceptuelle (compte utilisateur, unité d enseignement,...) Regrouper dans un composant des caractéristiques qui concernent une entité informatique structure de données ensemble d attributs variables avec nom, type, valeur les opérations liées à cette entité ensemble de fonctions appelées méthodes nom, valeur de retour, paramètres Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 9 / 76

Notion d objet informatique Qu est-ce qu un objet? Etat d un objet Ensemble des valeurs des attributs de l objet à un instant donné L état d un objet évolue au cours du temps Les valeurs sont également des objets ( liens entre objets) Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 10 / 76

Notion d objet informatique Qu est-ce qu un objet? Comportement d un objet Regroupe les compétences d un objet et décrit les actions et réactions de cet objet Ensemble d opérations/méthodes que l objet peut effectuer demarrer, rouler, stopper, ajouter essence Chaque opération est déclenchée par l envoi d un message mavoiture.demarrer(), mavoiture.ajouter essence(15) Etat et comportement liés l état est modifié par le comportement le comportement à un instant donné dépend de l état courant mavoiture.demarrer() ne marchera pas si mavoiture.volume essence==0 Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 11 / 76

Notion d objet informatique Qu est-ce qu un objet? Identité d un objet Existence propre de l objet Ce qui identifie l objet de manière non-ambiguë Indépendante de l état 2 objets différents peuvent avoir le même état Attribuée implicitement à la création de l objet Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 12 / 76

Notion d objet informatique Liens entre objets Pour envoyer un message à un objet, il faut le connaître L objet Le conducteur connaît l objet Ma voiture Connaitre un objet revient à avoir une référence qui lui correspond Attributs, variables, paramètres de méthodes,... Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 13 / 76

Notion d objet informatique Les objets : en bref Cohérence interne des objets données + traitements Faible couplage entre l objet et l environnement envoi de messages entre objets qui se connaissent Insertion dans un scénario de communication par envoi de messages objets clients : à l origine d une interaction objets serveurs : répondent à la sollicitation en général : client et serveur Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 14 / 76

Notion d objet informatique Les objets : en bref Cohérence interne des objets données + traitements Faible couplage entre l objet et l environnement envoi de messages entre objets qui se connaissent Insertion dans un scénario de communication par envoi de messages objets clients : à l origine d une interaction objets serveurs : répondent à la sollicitation en général : client et serveur Que nous manque-t-il? Décrire abstraitement de la même manière des objets ayant même structures de données (attributs) même comportement (méthodes) Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 14 / 76

Plan Notion de classe 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 15 / 76

Les classes Notion de classe Regroupement d objets ayant le même comportement Abstraction décrivant les propriétés communes des objets qui en sont des instances Une classe peut décrire une infinité d instances Un objet sait toujours à quelle classe il appartient Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 16 / 76

Notion de classe Les classes : Implémentation Java Student.java... p u b l i c c l a s s Student { // A t t r i b u t s p r i v a t e i n t number ; p r i v a t e S t r i n g surname ;... // Methodes p u b l i c Student ( ) { number = 0 ; surname = STUDENT ; } p u b l i c v o i d setnumber ( i n t n ) { number = n ; } p u b l i c i n t getnumber ( ) { r e t u r n number ; }... } ; Mode d accès (public, private, protected), également appelé visibilité, spécifié avant chaque attributs ou méthodes (cf. sur l encapsulation) Définition des méthodes (écriture du corps des fonctions) dans la définition de la classe, dans un unique fichier.java Obligatoirement un source.java par classe Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 17 / 76

Notion de classe Les classes : Implémentation C++ Student.h c l a s s Student { // A t t r i b u t s p r i v a t e : i n t number ; s t d : : s t r i n g surname ;... // Methodes p u b l i c : Student ( ) { number = 0 ; surname = STUDENT ; } v o i d SetNumber ( i n t n ) ; i n t GetNumber ( ) c o n s t ;... } ; Student.cpp #i n c l u d e Student. h v o i d Student : : SetNumber ( i n t n ) { number = n ; } i n t Student : : GetNumber ( ) c o n s t { r e t u r n number ; }... Mode d accès (public, private, protected) spécifié par lot Définition des méthodes (écriture du corps des fonctions) Dans la définition de classe (.h) : méthodes inline (plutôt pour les petites fonctions) En dehors de la définition de la classe (.cpp) : le plus courant Autant de classes que l on veut par fichier.h En mémoire, lors de l exécution, une classe est identique à une structure Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 18 / 76

Notion de classe Les classes : Objet courant this Accès à l objet courant au sein d une méthode... p u b l i c Student ( ) { t h i s. number = 0 ; t h i s. surname = STUDENT ; }...... Student ( ) { t h i s >number = 0 ; t h i s >surname = STUDENT ; }... Peut être omis la plupart du temps Utile pour lever l ambiguïté, lorsqu un paramètre porte le même nom qu un attribut Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 19 / 76

Notion de classe Les classes : Instanciation et appel de méthodes Une variable de type Student allouée = une instance de la classe Student Java ne supporte que l allocation dynamique de mémoire (allocation dans le TAS), tandis que C++ gère également l allocation statique (allocation dans la PILE). Student s t 1 = new Student ( ) ; // C r e a t i o n d une n o u v e l l e i n s t a n c e ( dynamiquement dans l e TAS) s t 1. setnumber (20121080) ; Student s t 1 ; // C r e a t i o n d une n o u v e l l e i n s t a n c e ( dans l a p i l e ) Student pst2 = new Student ( ) ; // C r e a t i o n d une n o u v e l l e i n s t a n c e ( dans l e t a s ) v i a p o i n t e u r s t 1. setnumber (20121080) ; pst2 >setnumber (20121081) ; d e l e t e pst2 ; // D e s a l l o c a t i o n Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 20 / 76

Notion de classe Dans un programme OO On définit des classes leurs attributs, et visibilité leurs méthodes, et visibilité On instancie des objets à partir des classes On lance/gère la collaboration envoi de messages à des objets Exécution du programme : des objets qui s envoient des messages qui changent d état Objet = état + comportement + identité Attributs Méthodes (référence) Classe Abstraction Définit une infinité d objets instances Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 21 / 76

Plan Concepts importants en OO 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO Encapsulation Héritage Polymorphisme 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 22 / 76

Plan Concepts importants en OO Encapsulation 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO Encapsulation Héritage Polymorphisme 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 23 / 76

Encapsulation Concepts importants en OO Encapsulation Concept fondamental : protection de l information contenue dans un objet Garantit l intégrité de l objet (exemple : évite les affectations par erreur, = au lieu de ==!) Garantit la cohérence éventuelle entre plusieurs attributs inter-dépendants (exemple : un tableau dynamique et sa taille) Masque en partie le fonctionnement interne d une classe : respecte la notion de Type Abstrait de Donnée (facilite la prise en main du code dans un premier temps) Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 24 / 76

Encapsulation Concepts importants en OO Encapsulation Notion de visibilité L accès aux membres de la classe est différent selon que l on se trouve à l intérieur ou à l extérieur de la classe A l intérieur de la classe, tout est permis A l extérieur de la classe, le programmeur ne voit que ce que la classe veut bien lui montrer 3 niveaux de visibilité pour les membres (attributs et méthodes) : Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 25 / 76

Encapsulation Concepts importants en OO Encapsulation Notion de visibilité L accès aux membres de la classe est différent selon que l on se trouve à l intérieur ou à l extérieur de la classe A l intérieur de la classe, tout est permis A l extérieur de la classe, le programmeur ne voit que ce que la classe veut bien lui montrer 3 niveaux de visibilité pour les membres (attributs et méthodes) : public : accessibles à tous protected : accessibles seulement aux classes dérivées (voir héritage) private : accessibles seulement au sein de la classe elle-même Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 25 / 76

Encapsulation Concepts importants en OO Encapsulation Student.java c l a s s Student { // A t t r i b u t s p r i v a t e : i n t number ; s t d : : s t r i n g surname ;... // Methodes p u b l i c : Student ( ) ; v o i d SetNumber ( i n t n ) ; i n t GetNumber ( ) c o n s t ;... } ; StudentPair.java p u b l i c c l a s s S t u d e n t P a i r { p r i v a t e Student st1, s t 2 ;... p u b l i c S t r i n g getsurnames ( ) { S t r i n g s ; s = s t 1. surname + + s t 2. surname ; } //??? } ; Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 26 / 76

Concepts importants en OO Encapsulation Encapsulation : Accesseurs et mutateurs Accesseurs Méthodes get...() : lecture d un attribut Objet non modifié Retour = une copie (valeur) de l attribut Mutateurs Méthodes set...() : écriture d un attribut (et éventuellement, d attributs dépendants) Objet modifié Type de retour = void ou un type indiquant un statut (modification effectuée ou non,...) Si possible, un couple accesseur/mutateur par attribut Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 27 / 76

Concepts importants en OO Encapsulation Encapsulation : Accesseurs et mutateurs p u b l i c c l a s s Student {... p r i v a t e S t r i n g surname ;... p u b l i c S t r i n g getsurname ( ) { r e t u r n surname ; } p u b l i c v o i d setsurname ( S t r i n g s ) { surname = new S t r i n g ( s ) ; }... } ; c l a s s Student { p r i v a t e :... s t d : : s t r i n g surname ;... p u b l i c : v o i d SetSurname ( s t d : : s t r i n g &s ) { surname = s ; } s t d : : s t r i n g GetSurname ( ) c o n s t { r e t u r n surname ; }... } ; Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 28 / 76

Membre statique Concepts importants en OO Encapsulation Un membre statique est partagé par toutes les instances de la classe Utile pour implémenter une propriété (variable ou constante) commune à toutes les entités d une même classe : attributs/méthodes de classe Similaire à une variable ou fonction globale, mais interne à une classe Accès possible avec ou sans instance de la classe Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 29 / 76

Membre statique Concepts importants en OO Encapsulation Exemple : tout étudiant doit obtenir 180 crédits pour valider une licence Student.h Student.java p u b l i c c l a s s Student {... p u b l i c s t a t i c i n t c r e d i t s = 1 8 0 ;... } ;... Autre.java... Student s t 1 = new Student ( ) ; Student s t 2 = new Student ( ) ; System. out. p r i n t l n ( Student. c r e d i t s ) ; // 180 System. out. p r i n t l n ( s t 1. c r e d i t s ) ; // 180 System. out. p r i n t l n ( s t 2. c r e d i t s ) ; // 180 Student. c r e d i t s = 1 0 0 ;... c l a s s Student {... p u b l i c : s t a t i c i n t c r e d i t s ;... Student.cpp #i n c l u d e Student. hpp i n t Student : : c r e d i t s = 1 8 0 ; // i n i t i a l i s a t i o n o b l i g a t o i r e m e n t en d e h o r s de l a c l a s s e Autre.cpp Student st1, s t 2 ; cout<<student : : c r e d i t s <<e n d l ; // 180 cout<<s t 1. c r e d i t s <<e n d l ; // 180 Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 30 / 76

Plan Concepts importants en OO Héritage 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO Encapsulation Héritage Polymorphisme 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 31 / 76

Héritage Concepts importants en OO Héritage Concept fondamental : transmission des caractéristiques d une classe vers une sous-classe en faisant dériver une nouvelle classe d une classe existante Mise en place d une hiérarchie de classes (spécialisation, généralisation) Une sous-classe hérite des attributs et des méthodes de sa super-classe Une sous-classe peut ajouter/adapter des caractéristiques (attributs et méthodes) Évite la duplication et encourage la réutilisation Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 32 / 76

Concepts importants en OO Héritage Héritage simple : Implémentation Conserve la visibilité Un membre privé sera inaccessible même dans les classes dérivées En Java, par défaut, toute classe hérite de Object A.java p u b l i c c l a s s A { p r i v a t e i n t i ; p r o t e c t e d i n t j ; p u b l i c i n t k ; p u b l i c A( ) { i = 0 ; j = 0 ; k = 0 ; } } ; B.java p u b l i c c l a s s B e x t e n d s A { p u b l i c B( ) { i = 0 ; //??? j = 0 ; //??? k = 0 ; //??? } } ; Autre.java p u b l i c c l a s s Autre { p r i v a t e A a ; p r i v a t e B b ; // a e t b a l l o u e s dans l e c o n s t r u c t e u r... p u b l i c v o i d setalltoone ( ) { a. i = 1 ; //??? a. j = 1 ; //??? a. k = 1 ; //??? b. i = 1 ; //??? b. j = 1 ; //??? b. k = 1 ; //??? } } ; Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 33 / 76

Concepts importants en OO Héritage Héritage simple : Implémentation A.h c l a s s A { p r i v a t e : i n t i ; p r o t e c t e d : i n t j ; p u b l i c : i n t k ; A( ) { i = 0 ; j = 0 ; k = 0 ; } } ; B.h #i n c l u d e A. hpp c l a s s B : p u b l i c A { p u b l i c : B( ) { i = 0 ; // E r r e u r : i e s t p r i v e dans A j = 0 ; // Ok : j e s t p r o t e g e dans A k = 0 ; // Ok : k e s t p u b l i c } } ; En C++, l héritage lui-même peut être privé (pas d équivalent Java, donc non détaillé ici) Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 34 / 76

Plan Concepts importants en OO Polymorphisme 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO Encapsulation Héritage Polymorphisme 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 35 / 76

Polymorphisme Concepts importants en OO Polymorphisme Concept fondamental : une même opération peut s appliquer à des objets de classes différentes et avoir un comportement adapté à ces objets Augmente la généricité et la qualité du code 2 types de polymorphisme : polymorphisme de traitement (ad-doc, overloading) : mécanisme de surcharge des méthodes polymorphisme de données polymorphisme d héritage (redéfinition, sous-typage, masquage, inclusion, spécialisation... overriding) : un même code peut être appliqué à des données de types différents liées entre elles par une relation d héritage polymorphisme paramétrique (généricité, template) : un même code peut être appliqué à n importe quel type Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 36 / 76

Concepts importants en OO Polymorphisme Polymorphisme de traitement : surcharge de méthodes Définir deux méthodes ayant le même nom, mais pas la même signature (type et/ou nombre arguments différents) Le compilateur choisit la méthode à utiliser en fonction du type des paramètres p r i v a t e s t a t i c i n t a d d i t i o n ( i n t x, i n t y ) { System. out. p r i n t l n ( a d d i t i o n n e des i n t ) ; r e t u r n x + y ; } p r i v a t e s t a t i c f l o a t a d d i t i o n ( f l o a t x, f l o a t y ) { System. out. p r i n t l n ( a d d i t i o n n e des f l o a t ) ; r e t u r n x + y ; } Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 37 / 76

Concepts importants en OO Polymorphisme Polymorphisme d héritage : redéfinition de méthodes Possibilité de définir le comportement d une méthode selon le type d objet l invoquant Méthode redéfinie donne une nouvelle implémentation à une méthode héritée sans changer sa signature Une méthode redéfinie peut être complètement différente de la méthode de base, ou bien réutiliser celle-ci en effectuant des opérations supplémentaires (super en Java, :: en C++) Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 38 / 76

Concepts importants en OO Polymorphisme Polymorphisme d héritage : redéfinition de méthodes Point.java p u b l i c c l a s s P o i n t { p r i v a t e i n t x, y ; // A t t r i b u t s de P o i n t... p u b l i c P o i n t ( ) {... } ; p u b l i c v o i d a f f i c h e ( ) { System. out. p r i n t l n ( x+, +y ) ; } } PointCouleur.java Point.h c l a s s P o i n t { p r i v a t e : i n t x, y ; p u b l i c : P o i n t ( ) {... } v o i d a f f i c h e ( ) { cout<<x<< <<y<<e n d l ; }... } ; PointCouleur.h #i n c l u d e P o i n t. h c l a s s P o i n t C o u l e u r : p u b l i c p u b l i c c l a s s P o i n t C o u l e u r P o i n t { e x t e n d s P o i n t { p r i v a t e : p r i v a t e i n t c o u l e u r ; //... // A t t r i b u t s sup A t t r i b u t s p u b l i c : s u p p l e m e n t a i r e s P o i n t C o u l e u r ( ) {... }... v o i d a f f i c h e ( ) @ O v e r r i d e { P o i n t : : a f f i c h e ( ) ; // p u b l i c v o i d a f f i c h e ( ) { Appel a a f f i c h e ( ) de s u p e r. a f f i c h e ( ) ; P o i n t System. out. p r i n t l n ( cout<< C o u l e u r : <<t h i s C o u l e u r : + t h i s. >c o u l e u r ; c o u l e u r ) ; } } } ; Laëtitia } Matignon ISI3-1. Rappels de programmation orientée objet 2012 39 / 76

Concepts importants en OO Polymorphisme Polymorphisme d héritage : méthode virtuelle Méthode virtuelle est destinée à être redéfinie dans une classe dérivée Le type d instance (classe fille ou mère) détermine la méthode réelle à appeler lors de l exécution (résolution dynamique de liens) P o i n t p ; i f (... ) p = new PointCouleur ( ) ; e l s e p = new P o i n t ( ) ; p. a f f i c h e ( ) ; Point pp ; i f (... ) pp = new PointCouleur ( ) ; e l s e pp = new P o i n t ( ) ; pp >a f f i c h e ( ) ; En Java, les méthodes sont virtuelles par défaut. p.affiche() fait appel à la méthode de la classe réellement instanciée avec new même si p a été déclaré de type Point. En C++, les méthodes ne sont pas virtuelles par défaut. pp->affiche() appelle toujours la méthode de Point (résolution statique des liens). Pour y remédier, la méthode doit être déclarée virtual dans Point. Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 40 / 76

Concepts importants en OO Polymorphisme Polymorphisme d héritage : méthode virtuelle pure, classe abstraite Une méthode virtuelle pure ou abstraite est déclarée sans être définie, et est donc destinée à être obligatoirement (re)définie dans une classe dérivée (abstract en Java, =0 en C++) Une classe est dite abstraite si elle contient au moins une méthode virtuelle pure (abstract en Java) Sert à définir des concepts incomplets qui seront complétés dans les sous-classes. Ne peut pas être instanciée, et est donc destinée à être dérivée. En java, une classe peut être déclarée abstraite sans contenir de méthode abstraite p u b l i c a b s t r a c t c l a s s P o i n t { p r i v a t e i n t x, y ;... p u b l i c P o i n t ( ) {... } ; p u b l i c a b s t r a c t v o i d a f f i c h e ( ) ; } c l a s s P o i n t { p r i v a t e : i n t x, y ; p u b l i c : P o i n t ( ) {... } v i r t u a l v o i d a f f i c h e ( ) = 0 ; Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 41 / 76

Héritage multiple Concepts importants en OO Polymorphisme Héritage multiple autorisé en C++, pour bénéficier des opérations de plusieurs classes mères Exemple : un véhicule amphibie est à la fois terrestre et aquatique Terrestre.h Aquatique.h c l a s s T e r r e s t r e {... p u b l i c : v o i d move ( ) ; } c l a s s Aquatique {... p u b l i c : v o i d swim ( ) ; } Amphibie.h c l a s s Amphibie : p u b l i c T e r r e s t r e, p u b l i c Aquatique {... } Amphibie dispose à la fois des méthodes move() et swim(), qu elle peut redéfinir Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 42 / 76

Interface Concepts importants en OO Polymorphisme Héritage multiple impossible en Java : utilisation d interfaces Une interface est un prototype de classe. Elle définit la signature des méthodes qui doivent être implémentées dans les classes construites à partir de ce prototype. Une interface est une classe purement abstraite dont toutes les méthodes sont abstraites et publiques. Une classe peut implémenter plusieurs interfaces Le concept équivalent en C++ est la classe virtuelle pure, où toutes les méthodes sont virtuelles pures. Terrestre.java Aquatique.java p u b l i c i n t e r f a c e T e r r e s t r e {... p u b l i c v o i d move ( ) ; } ; p u b l i c i n t e r f a c e Aquatique {... p u b l i c v o i d swim ( ) ; } Amphibie.java p u b l i c c l a s s Amphibie implements T e r r e s t r e, Aquatique { // Amphibian d o i t d e f i n i r l e s methodes move ( ) e t swim ( ) p u b l i c v o i d move ( ) {... } p u b l i c v o i d swim ( ) {... } } Laëtitia Matignon ISI3-1. Rappels de programmation orientée objet 2012 43 / 76

Concepts importants en OO Polymorphisme 2. Capture des besoins et diagramme de cas d utilisation Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 44 / 76

Objectifs du cours Concepts importants en OO Polymorphisme Rappel des concepts fondamentaux de la POO Notion d objet Classe / Abstraction Encapsulation des données / traitements Généralisation / Héritage Polymorphisme de traitement et d héritage Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 45 / 76

Plan Capture des besoins 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 46 / 76

Capture des besoins Qu est-ce qu un cahier des charges? Définition Le cahier des charges est un document recensant les spécifications et exigences. Il résulte de l analyse et est contractuel entre le client et l entreprise qui va réaliser le logiciel. Il doit donc être validé par les deux. Qualités attendues : non-ambigu complet vérifiable cohérent modifiable traçable utilisable durant la maintenance indépendant des solutions (cf. norme IEEE 830 Pratiques recommandées pour la spécification des exigences logicielles (SEL) ) Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 47 / 76

Plan type Capture des besoins introduction : présentation générale, motivations, définitions des termes contexte : environnement matériels (architecture du parc informatique, débit,...) et humains (futurs utilisateurs, langues,...), acteurs et utilisateurs, interactions spécifications fonctionnelles : grandes fonctionnalités du système, acteurs et autres systèmes impliqués spécifications non fonctionnelles, contraintes : charte graphique, matériel, interfaçage, performances, sécurité, charge à supporter, comportement en cas de panne organisation : priorité des spécifications, versions à prévoir, délais évolutions à prévoir annexes Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 48 / 76

Capture des besoins Comment rédiger un cahier des charges? Conseils fondamentaux être précis et organisé s aider de notations et diagrammes standards De nombreuses méthodes peuvent être utilisées norme IEEE 830 pour la rédaction des spécifications organisation : numérotation, tableaux, schémas, exemples diagrammes UML : présentation des fonctionnalités (diagramme de cas d utilisation) scénarios (d interaction) : illustration des cas d utilisation complexes entretiens réguliers avec le client et validations observation des utilisateurs prototypage rapide Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 49 / 76

Capture des besoins Analyse des besoins Conclusion Expression des besoins Comprendre le contexte du système en s accordant sur ce qui doit être fait dans le système Comprendre et structurer les besoins du client Elaborer un cahier des charges Recenser les besoins fonctionnels et les définir par des cas d utilisations Noter les contraintes, exigences non fonctionnelles Vue orientée utilisateur Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 50 / 76

Plan Introduction aux cas d utilisation 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 51 / 76

Introduction aux cas d utilisation Introduction aux cas d utilisation Décrivent les services rendus par le système du point de vue de l utilisateur Technique pour capturer les exigences fonctionnelles d un système Déterminer ses limites Déterminer le comportement du système : ce que doit faire le système sans spécifier comment il le fait Comprendre l attente des utilisateurs et les experts du domaine Instruments de validation et de tests du système Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 52 / 76

Plan Diagramme de cas d utilisation 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 53 / 76

Diagramme de cas d utilisation Diagramme de cas d utilisation acteur nom du système cas d'utilisation association Un diagramme de cas d utilisation définit : le système les acteurs qui interagissent avec le système les cas d utilisations les relations entre acteurs et cas d utilisations Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 54 / 76

Acteurs Diagramme de cas d utilisation Un acteur représente un rôle joué par une entité extérieure au système (humain ou autre système) et qui interagit directement avec le système étudié Permet de déterminer les limites du système Un utilisateur peut être représenté par plusieurs acteurs Plusieurs utilisateurs peuvent être représentés par le même acteur Catégories d acteurs : acteurs principaux : utilisent les fonctions principales du système, un par CU acteurs secondaires : tâches administratives, maintenance matériel externe : dispositif matériel qui doivent être utilisés (périphériques) autres systèmes avec lesquels le système doit interagir Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 55 / 76

Acteurs Diagramme de cas d utilisation Relations entre acteurs : généralisation (héritage) généralisation (héritage) acteurs Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 56 / 76

Diagramme de cas d utilisation Cas d utilisation Un cas d utilisation représente un service complet attendu du système Un cas d utilisation représente une suite d interactions entre un acteur et le système qui produisent un résultat observable intéressant pour un acteur particulier Chaque cas d utilisation correspond à une fonction métier du système, selon le point de vue d un de ses acteurs Un cas d utilisation a un début et une fin clairement identifiés Un cas d utilisation est décrit par une forme verbale Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 57 / 76

Diagramme de cas d utilisation Cas d utilisation Mauvais diagramme de CU : Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 58 / 76

Diagramme de cas d utilisation Cas d utilisation Exemple des cas d utilisation d un distributeur de boissons limites du système association Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 59 / 76

Diagramme de cas d utilisation Relations entre cas d utilisation Inclusion : précise qu un cas d utilisation contient le comportement défini dans un autre cas d utilisation. Mise en commun des comportements communs à plusieurs CU (décomposer, définir des comportements partageables entre plusieurs CU, factorisation des services rendus) Extension : précise qu un CU (source) peut dans certains cas s ajouter au comportement d un autre CU (destination) Extension soumise à une condition d extension Comportement ajouté inséré au niveau d un point d extension défini dans le CU destination relation d'inclusion <<Include>> Paye Client <<Extend>> relation d'extension l'opéra Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 60 / 76

Diagramme de cas d utilisation Relations entre cas d utilisation Généralisation : héritage du comportement de base héritage Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 61 / 76

Diagramme de cas d utilisation Relations entre cas d utilisation Exercice 1 Une agence de voyages organise des voyages où l hébergement se fait en hôtel. Le client doit disposer d un taxi quand il arrive à la gare pour se rendre à l hôtel. Compléter de diagramme de CU suivant. 2 Certains clients demandent à l agent de voyages d établir une facture détaillée. Cela donne lieu à un nouveau cas d utilisation appelé Établir une facture détaillée. Comment mettre ce cas en relation avec les cas existants? 3 Le voyage se fait soit par avion, soit par train. Comment modéliser cela? Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 62 / 76

Diagramme de cas d utilisation Relations entre cas d utilisation Exercice Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 63 / 76

Diagramme de cas d utilisation Scénarios d un cas d utilisation La description d un CU se fait par des scénarios qui définissent la suite logique des interactions qui constituent ce CU Tous les scénarios d un CU sont issus du même acteur et ont le même objectif Un CU contient en général un scénario nominal et plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d erreur (qui se terminent en échec). enchainements début erreur fin normale Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 64 / 76

Plan Modélisation fonctionnelle 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Etude de cas Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 65 / 76

Modélisation fonctionnelle Modélisation fonctionnelle Identification des acteurs Identification des cas d utilisation Diagrammes de cas d utilisation Description textuelle des cas d utilisation : Identification (titre du cas, acteurs concernés, responsable, date, etc.) Préconditions Scénario nominal : suite d étapes avec objectifs de l acteur bien identifiés et menés à bien Enchainements alternatifs Enchainements d erreurs Postconditions Description de ces scénarios par des diagrammes de séquence (système), d activités. Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 66 / 76

Plan Modélisation fonctionnelle Etude de cas 1 Notion d objet informatique 2 Notion de classe 3 Concepts importants en OO 4 Capture des besoins 5 Introduction aux cas d utilisation 6 Diagramme de cas d utilisation 7 Modélisation fonctionnelle Etude de cas Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 67 / 76

Modélisation fonctionnelle Etude de cas Etude d un système de gestion de comptes bancaires Cahier des charges Cette étude de cas concerne un système simplifié de gestion des comptes bancaires offrant les services suivants : Consultation de solde de compte et retrait d argent au distributeur automatique de billets (DAB) de la banque pour les clients porteurs d une carte bancaire ; Les clients porteurs d une carte bancaire de la banque peuvent effectuer un virement depuis le DAB de la banque ou depuis internet. Ils peuvent aussi faire un dépôt en numéraire ou en chèques et consulter leurs comptes sur internet. Un client qui effectue un virement peut demander à vérifier le solde de son compte. Cette demande est autorisée si le solde est supérieur ) 15 euros. Toute transaction est sécurisée et nécessite par conséquent une authentification. Proposer un diagramme de CU. Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 68 / 76

Modélisation fonctionnelle Identification des acteurs Etude de cas Quelles sont les entités externes qui interagissent directement avec le DAB? Porteur de carte bancaire Client de la banque Cyber-client de la banque SI banque Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 69 / 76

Modélisation fonctionnelle Diagramme des cas d utilisation Etude de cas DAB Retirer de Porteur de carte Consulter Client banque Déposer d Rech Opérateur de maintenance Mainte opéra Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 70 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent sur DAB Identification Titre : retirer de l argent sur DAB Résumé : ce cas d utilisation permet à un Porteur de carte bancaire de retirer de l argent liquide à un DAB. Acteur principal : porteur de carte bancaire Acteur secondiare : SI banque Date : 28-01-2013 Responsable : Laëtitia Matignon Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 71 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent sur DAB Préconditions Le DAB contient des billets Aucune carte ne se trouve déjà coincée dans le lecteur La connexion avec le SI banque est opérationnelle Postconditions La DAB contient moins de billets qu au début du cas d utilisation Une transaction de retrait a été enregistrée par le DAB avec toutes les informations pertinentes (montant, numéro de carte, date, etc.). Les détails de la transaction doivent être enregistrés aussi bien en cas de succès que d échec. Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 72 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent sur DAB Scénario du cas nominal 1. Le porteur de CB introduit sa carte dans le lecteur du DAB 2. Le DAB vérifie que la carte est bien une CB. 3. Le DAB demande au porteur de CB de saisir son code d identification. 4. Le porteur de CB saisit son code. 5. Le DAB vérifie le code. 6. Le DAB demande une autorisation au SI banque. 7. Le SI banque donne son accord et indique le solde hebdomadaire. 8. Le DAB demande au porteur de CB de saisir le montant désiré du retrait. 9. Le porteur de CB saisit le montant. 10. Le DAB contrôle le montant par rapport au solde hebdomadaire. 11. Le DAB demande au porteur de carte s il veut un ticket. 12. Le porteur de CB veut un ticket. 13. Le DAB éjecte la carte. 14. Le porteurcb reprend sa carte. 15. Le DAB délivre ticket/billets. 16. Le porteurcb prend son ticket et ses billets. Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 73 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent Scénario du cas nominal 1. Le porteur de CB introduit sa carte dans le lecteur du DAB 2. Appel du cas S authentifier 3. Le DAB demande une autorisation au SI gestion CB. 4. Le SI gestion CB donne son accord 5. Le DAB demande au porteur de CB et indique le solde hebdomadaire. de saisir le montant désiré du retrait. 6. Le porteur de CB saisit le montant. 7. Le DAB contrôle le montant par rapport au solde hebdomadaire. 8. Le DAB demande au porteur de carte s il veut un ticket. 9. Le porteur de CB veut un ticket. 10. Le DAB éjecte la carte. 11. Le porteur de CB reprend sa 12. Le DAB délivre le ticket et les billets. carte. 13. Le porteur de CB prend son ticket et ses billets. Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 74 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent Enchainements alternatifs A1 : code d identification provisoirement erroné Démarre au point 5 : Le DAB indique au porteur de CB que le code est erroné, pour la première ou deuxième fois, puis enregistre l échec sur la carte. Le scénario reprend au point 3. A2 : montant demandé supérieur au solde hebdomadaire Démarre au point 10 : Le DAB indique au porteur de carte que le montant demandé est supérieur au solde hebdomadaire. Le scénario nominal reprend au point 8. A3 : ticket refusé Démarre au point 11 :... Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 75 / 76

Modélisation fonctionnelle Etude de cas Description textuelle du CU Retirer de l argent Enchainements d erreurs E1 : carte non-valide Démarre au point 2 : Le DAB indique au porteur de CB que sa carte n est pas valide (illisible, périmée, etc.), la confisque. Le CU se termine en échec. E2 : code d identification définitivement erroné Démarre au point 5 : Le DAB indique au porteur de CB que le code est erroné, pour la troisième fois. Le DAB confisque la carte. Le SI est informé ; le cas d utilisation se termine en échec. E3 : retrait non autorisé Démarre au point 6 : Le SI interdit tout retrait. Le DAB éjecte la carte ; le CU se termine en échec. E4 : carte non reprise... E5 : billets non pris... E6 : annulation de la transaction Démarre entre points 4 et 12 :... Laëtitia Matignon ISI3-2. Capture des besoins et diagramme de cas d utilisation 2012 76 / 76