Analyse et conception orient´ees objet Mohamed FTOUHI 1 Objectifs du cours 1. Analyse et conception orient´ees objet. 2. Mod´elisation avec U M L 2.0. 2 Plan du cours I. Introduction A. Processus de developpement B. Unified Modeling Language II. Analyse A. Identification des besoins : Cas d’utilisation B. Cas d’utilisation et Use Case Diagrams C. Processus metiers´ : A ctivity Diagrams III. Conception A . C om portem ent dynamique ( U M L : Sequence, Communication) B. Visualisation des concepts ( U M L : Class, Package) C. Diagrammes U M L et code Java IV. Autres diagrammes U M L 3 Bibliographie • U M L distilled M . Fowler, Addison-Wesley Pearson Education, 2004. • U M L 2 et les Design Patterns C. Larman, Pearson Education, 2005. • Design Patterns E. Gamma et al., Addison-Wesley, 1995. 4 Chapitre I Introduction 5 Plan du chapitre I I. Introduction A. Processus de developpement 1. Fondements et cycle de vie global 2. D´eveloppement iteratif ou en cascade 3. Langages de modelisation 4. Design Patterns B. Unified Modeling Language 1. Historique et motivations 2. D´efinition et principes 3. Les diagrammes 4. Modes d’utilisation et limites 5. Utilisation des diagrammes dans le processus de d´eveloppement 6 I. I n t r o d u c t i o n A . Processus de d´eveloppement 7 I . A . 1 . G´en´eralit´es Cahier des charges Réalisation Client Maintenance Livraison 8 Test Implantation des charges Conception Cahier Analyse I . A . 2 . D ´ e v e l o p p e m e n t e n cascade Client Temps Livraison 9 I . A . 3 . D ´ e v e l o p p e m e n t it´eratif feed−back Cahier des charges Client Livraisons intermédiaires Livraison finale 10 I . A . 3 . D ´ e v e l o p p e m e n t it´eratif o u e n cascade Avantages du d´eveloppement en Cascade : • Plus simple `am e t t r e en œuvre • Planification plus pr´ecoce Avantages du d´eveloppement It´eratif : • D i m i n u t i o n des échecs, amélioration de la pro ductivité et de la qualit´e • Gestion pr´ecoce des risques ´elev´es • Progr`es imm´ediatement visibles • Feed-back, implication des utilisateurs et adaptation pr´ecoces • Complexit´e mieux g´er´ee 11 I.A.3. Analyse Implantation Itération 1 Conception Test Analyse Implantation Itération 2 Temps Conception Test Analyse Implantation Test Itération n Conception D ´ e v e l o p p e m e n t it´eratif Inception 12 I . A . 3 . L a phase d ’ i n c e p t i o n B u t de l’inception : • E ´ tablir une vision commune du projet. • D´efinir le p´erim`etre de base du projet. Pour cela : → – – – Analyse detaillee´´ d’environ 1 0 % des cas d’utilisation : significatifs pour l’architecture, de grande valeur pour le client, ou `ahaut risque. → Analyse des besoins non fonctionnels critiques. → Realisation´ de l’etude´ d’opportunite.´ 13 I . A . 3 . P r i n c i p e s des it´erations Buts : • Analyser les besoins. • Concevoir une solution. • Implanter le code. • Tester et livrer le produit. Pour cela : → Decoupage´ en phases : ´elaboration ⇒ construction ⇒ transition ⇒ livraison finale. → Augmentation iterative´ des fonctionnalit´es. → Livraisons successives de co de operationneĺ avec feedback du client. 14 I . A . 3 . D ´ e v e l o p p e m e n t it´eratif - s u i t e Inception Phase d’élaboration Temps 15 Logiciel Exigences Logiciel Exigences I . A . 3 . D ´ e v e l o p p e m e n t it´eratif - phase d’´elaboration 90% 90% 50% 20% 30% 2% Itération 1 5% Itération 2 8% 10% Itération 3 Itération 4 20% Itération 5 16 I . A . 3 . D ´ e v e l o p p e m e n t it´eratif - E x e m p l e d’it´eration Lu Ma Me Je Ve Lu Ma Me Je Ve Début du codage et des tests Révision éventuelle des objectifs Lu Ma Me Je Ve Planification de l’itération suivante Vérification et Rappel des objectifs gel du code Démonstrations et Modélisation et conception atelier d’expression des (esquisses UML) besoins 17 I.A.3. Analyse e t Conception Objectifs de l’analyse : • E´ tude du m´etier du client • E´ tude des besoins des utilisateurs • Reformulation du cahier des charges sous une forme exploitable en conception Objectifs de la conception : • Definition´ de l’architecture logicielle • Definition´ du comportement de l’application 18 I . A . 4 . L a n g a g e s d e mod´elisation Int´erˆet : • Formalisation des principes • Communication des id´ees • Repr´esentation graphique Utilisation dans le processus de developp´ement : • Representation´ de cas d’utilisation • Representation´ du modele` du syst`eme • Representation´ des interactions´ • Representation´ des classes de conception • ... 19 I . A . 5 . Design P a t t e r n s - P a t r o n s de conception Int´erˆet : Apporter des solutions `a des problemes` simples connus Utilisation dans le processus de d´eveloppement : Pendant la mod´elisation et l’implantation 20 I. I n t r o d u c t i o n B . Unified Modeling Language 21 I.B.1 Historique e t motivations 2004 UML 2.0 2003 UML 1.5 1999 UML 1.3 1998 UML 1.2 Fin 97 UML 1.1 Début 1997 UML 1.0 1996 1995 UML 0.9 Méthode unifiée 0.8 Booch’93 Autres méthodes Booch’91 OMT−2 OMT−1 OOSE Partenaires 22 I . B . 2 . D´efinition e t pri nci pes D´efinition : U M L est un langage visuel d´edi´e `ala sp´ecification, la construction et la documentation des artefacts d’un syst`eme. Principes : 1. Une famille de notations graphiques... 2. bas´ee sur un m´eta-mod`ele formel... 3 . p e r m e t t a n t la g´en´eration automatique de code. 23 I.B.3. Les diagrammes Six diagrammes de structure ( o u statiques) : • Class • Object • Package • Component • Deployment • Composite Sept diagrammes de comportement ( o u dynamiques) : • Activity Interaction Diagrams • Use Case • State Machine • Sequence • Communication • Interaction Overview • Ti m i n g 24 I.B.3. Les diagrammes - Exemple << actor >> Client Traiter une vente Service d’auto. des paiements Caissier 25 I.B.4. Modes d’utilisation Esquisse : → Informel, dynamique, exploratoire et ´ephemere.`´ Plan : → Direction, processus en cascade, complet et persistant. ⇒ Necessite´ une tres` bonne connaissance d ’ U M L (diagrammes). Langage de programmation : → Le code est g´en´er´e uniquement `apartir d ’ U M L . ⇒ Necessite´ une d ’ U M L meta-mo´ excellente dele).` connaissance (diagrammes et 26 I.B.4. Limites • Le langage de mod´elisation ne remplacera jamais la comp´etence de l’analyste-concepteur. • Une bonne conception illegale´ en U M L est preferable´´ `aune mauvaise conception legale´ en U M L . ⇒ Mieux vaut chercher `ase perfectionner en conception qu’en U M L ! • U M L n’est pas suffisant pour representer´ tous les aspects utiles `ala conception. • Remarque : Dans 80% des cas, seulement 20% d ’ U M L sont necessaire...´ 27 I . B . 5 . Qualit´es des d i a g r a m m e s • Clart´e de pr´esentation. • Coherence´ avec le fond. • Niveau de detail´ homogene.` • Clarte´ de presentation.´ 28 I . B . 6 . U t i l i s a t i o n des d i a g r a m m e s dans le processus d e d´eveloppement Inception : • Use Case • Activity It´eration - Analyse des besoins : • Use Case • Activity • Class • State Machine It´eration - Conception : • Class • Sequence • State Machine • Package • Communication Diagram 29 I . B . 7 . O r d r e d e pr´esentation Importance/Utilit´e Class Sequence Package State Machine Activity Use Case Object Communication Deployment Component Composite Structures Interaction Overview Timing 1 2 3 4 5 6 7 8 9 10 11 12 13 Utilisation Use Case Activity Component Sequence Communication Class Package State Machine Deployment Object Composite Structures Interaction Overview Timing 30