M'ethode de conception Orient'ee Objet UML Course Notes PDF

# M'ethode de conception Orient'ee Objet UML ## M'ethode de Conception Orient'ee Objet UML Bennani Mohamed Taj Facult'e des sciences Dhar El Mahraz Fes 2022/2023 ## Section I: Introduction ### Contexte * L'apprehension d'une problematique complexe telle que le d'eveloppement d'applications repose...

# M'ethode de conception Orient'ee Objet UML ## M'ethode de Conception Orient'ee Objet UML Bennani Mohamed Taj Facult'e des sciences Dhar El Mahraz Fes 2022/2023 ## Section I: Introduction ### Contexte * L'apprehension d'une problematique complexe telle que le d'eveloppement d'applications repose de plus en plus sur le recours `a la modelisation informatique. * L'acc'el'eration du renouvellement des technologies conjugu ee avec la pression 'economique et concurrentielle qui s'exerce sur les entreprises, obligent les acteurs du monde informa- tique `a produire des solutions de plus en plus rapidement, dans un contexte d'am´elioration continue de la qualit'e et de la performance des syst`emes d'information. * Internet a 'et'e un vecteur favorasant le d 'eveloppement de tr`es nombreuses applications dont une grande partie utilise des solutions `a base de langage de programmation objet comme Java, C++ ou C#. ### Objectif * Depuis longtemps, le langage UML (Unified Modelling Lan- guage) est d'eveloppée pour formaliser des besoins clients aux programmes qu'ils r´ealisent. * Cette m'ethode est proposée comme moyen de communication entre mod'elisateurs ou informaticiens et les autres m'etiers ind ´ependamment des disciplines et de la technique informa- tique. * UML a apport'e tout naturellement le support m 'ethodologique qui manquait `a tous les concepteurs et d'eveloppeurs, qui voulaient formaliser l'analyse et la conception technique de leur logiciel. ### Sp´ecifications * Depuis plus de 30 ans, la conception des bases de donn'ees est realis´ee `a l'aide du mod`ele entit 'e-association. Ce mod`ele a fait ses preuves et la plupart des outils informatiques de conception l'utilisent encore aujourd'hui. * La notation UML s'est impos´ee depuis quelques ann'ees pour la mod elisation et le d ´eveloppement d'applications 'ecrites dans un langage objet (C++ et Java principalement). * Initialement, UML n'a pas 'et'e con cue pour les bases de donn'ees. Cependant, elle offre un m^eme formalalisme aux concep- teurs d'objets m'etiers et aux concepteurs de bases de donn´ees. * UML s'est impos´ee en tant que langage graphique de mod´elisation puisqu'il r´epond `a un veritable besoin et devenu un standard car il s'appuie sur une norme tr`es structurante. ## Historique de l'UML * II h´erite principalement des m´ethodes objets de Booch OMT (Object Modeling Technique en francais Technique de mod´elisation objet) et OOSE (Object Oriented Software En- gineering) invent´ees respectivement par Grady Booch, Rum- baugh et Jacobson. * UML est une fusion de OOA/OOSE/OMT. * Adopt´e par l' OMG en Novembre 1997 devient un standard. ## Evolution des versions d'UML * **OMT-2**: James Rumbaugh * **UML 0.8**: OOSPLA'95 * **Booch 93**: Grady Booch * **UML 0.9**: WWW Juin 96 * **UML 1.0**: Proposé à un standard OMG fin 1997 * **UML 1.1**: Standard OMG ADTF fin 1997 * **Partenaires divers**: Task force * **OOSE**: Ivar Jacobson * **UML 1.2**: 1998 * **UML 1.3**: 1999 * **UML 1.4**: 2001 * **UML 1.5**: 2003 * **UML 2.0**: 2005 * **UML 2.3**: 2010 * **UML 2.4.1**: 2013 ## Section II: Le g´enie logiciel ### Pr´esentation du g´enie #### D'efinition d'un logiciel * un logiciel est un ensemble de s'equences d'instructions interpretables par une machine et d'un jeu de donn'ees n'ecessaires `a ces operations. #### G'enie logiciel * Un Ensemble de m'ethodes, de techniques et d'outils d 'edi´es `a la conception, au d'eveloppement et `a la maintenance des syst`emes informatiques. ### Les objectifs du g´enie logiciel #### Objectifs du g´enie * Avoir des proc´edures syst´ematiques pour cr´eer des logiciels de grande taille qui respectent les r`egles impos´ees par CQFD : * **Cou^ts**: les cou^ts allou´es `a la r´ealisation doivent ^etre res- pect´es. * **Qualit´e**: il doit respecter les qualit´es suivantes : * **Validit´e**: capacit´e `a ex´ecuter les t^aches pour lesquelles il a 'et'e cr'e'e. * **Fiabilit´e**: capacit´e de fournir les r´esultats attendus. * **Extensibilit´e**: capacit´e d'ajouter de nouvelles fonctionnalit´es. **Compatibilit´e**: capacit´e de coop 'erer avec d'autres logiciels. * **Efficacit´e**: capacit´e de fournir de bon r´esultats dans les d 'elais pr´evus. * **Portabilit'e**: capacit´e d'^etre port´e sur d'autre OS. * **Fonctionnalit´es**: La sp´ecification doit correspondre aux be- soins r´eels du client. * **D´elais**: le d´elais ne doit pas ^etre d'epass'e. ### Les 'etapes de r´ealisation d'un logiciel #### Les phases de r´ealisation d'un * La realisation d'un logiciel se resume en 6 phases : 1. La phase d'analyse. 2. La phase de conception. 3. La phase de r´ealisation. 4. La phase de mise en place. 5. La phase d'exploitation et maintenance. 6. La phase de d'emontage. #### La phase d'Analyse * Pour cr´eer un nouveau logiciel, On effectue l''etude de faisabilit´e qui consiste `a d'eterminer : * Les avantages. * Les inconvenients. * Elle est destin´ee aux d ´ecideurs qui: * Valident les orientations. * Chiffrent l'effort, cou^t de r'ealisation, gestion des d 'elais, temps de formation des utilisateurs, cou^ts d'achat de nouveaux materiels, recuperation des anciennes donn´ees. #### Le cahier des charges * Le Cahier des charges est une phase importante qui permet de: Faire une 'etude de l'existence des logiciels. * Est un guide qui permet de d'efinir les logiciels dans ses grandes lignes (pas trop techniques). * Indique ce qui doit ^etre fait mais sans dire vraiment com- ment. Permettra au concepteur de valider chaque 'etape de la r´ealisation du logiciel. Indique les specifications du projet. #### La phase de conception * C'est la phase la plus importante, elle d'efinit l'architecture du logiciel (son squelette, son comportement, etc.). Il y'a 2 architectures : * **L'architecture global du logiciel**: qui consiste a faire une representation globale du logiciel (d 'ecrire le logiciel de fa con global). * **L'architecture d'etaillee**: d'ecrit les composants du logiciel et le lien entre les differents composants du logiciel. * L'architecture d'un logiciel concerne 2 aspects : * **L'aspect statique**: d'ecrit les parties non variables du logiciel une fois valid´e. * **L'aspect dynamique**: d'ecrit le comportement du logiciel de fa con globale et de chaque composant du logiciel. #### La phase de realisation * Une fois la conception termin´ee et valid´ee, la r ´ealisation du logiciel doit ^etre effective. * Il s'agit de transformer le schema du logiciel en un produit (executable). * Cette phase consiste `a conduire le logiciel. * **La specification consiste `a d'ecrire toutes les sp ´ecifications :** * **Fonctionnelles**: ce que doit realiser le logiciel (sous- pro- grammes / traitements `a r´ealiser). * **Non fonctionnelles**: contraintes d'environnements, perfor- mance, s'ecurit´e. * **La conception consiste `a apporter une r´eponse `a l''etape Pr´ec´edente :** * **Architecture**: (modules, objets, classes, fonctions). * **Materiel**: (environnement de d'eveloppement, application ex- ternes utilis´ees). * **L'implantation (implementation ou codage) consiste `a coder les donnees.** * La validation sert `a v'erifier chaque module. * Il faut garder la trace de ce qui a 'et´e fait. #### La phase de mise en place * Maintenant que le logiciel est realis'e (l'ex ´ecutable obtenu), il faut passer `a sa mise en œuvre. * Mettre en œuvre un logiciel veut dire le d'eployer : * Installer le logiciel dans l'environnement de production. * D`es le d'ebut de la phase de r´ealisation, il faudrait pouvoir disposer d'une machine dans l'environnement de production. * Le d'eploiement d'un logiciel exige la preparation de son en- vironnement de production. * Interconnecter tous les syst`emes et processus devant com- muniquer avec le logiciel. * Transfert de donn'ees et conversion dans un nouveau format (Recup´eration). #### La phase d'exploitation * Une fois le logiciel est en place, son exploitation devient fon- damentale. * Cette phase resume deux t'aches qui doivent ser ealiser depuis la mise en place du logiciel jusqu'`a sa fin. * Pour commencer l'exploitation du logiciel, on fait le param´etrage du logiciel (l'insertion des donn´ees). * Ensuite faire le traitement de donn´ees (tester le logiciel) pour d'etecter les erreurs s'ils y existent. #### La phase de maintenance * Une fois les erreurs d'etect´ees, il faut passer`a la correction (la maintenance du logiciel). * La maintenance doit se tenir r ´eguli`erement. Il existe 3 types de maintenance : * **Corrective**: consiste `a corriger les erreurs d'etect ees lors de l'exploitation. Bugs qui apparaissent. * **Adaptative**: consiste `a adapter le logiciel `a un besoin ou `a un environnement : Besoins exprim´es par les utilisateurs pour faciliter leurs travail. * **Perfective**: le logiciel satisfaisant toutes les exigences du ca- hier des charges, il est necessaire de penser `a son 'evolution. Il s'agit de le rendre plus performant. Mise en place d'un systeme de tra cage des bugs (date/conditions de reproduc- tion/solution et correction). #### La phase d'emontage * Malgr'e toutes les maintenances realis´ees, le logiciel ne peut plus satisfaire les besoins du client donc r´evolue : c'est la fin de vie du logiciel, on parle alors de d'emontage. * Un logiciel est qualifi´e de r´evolue lorsque : * Il ne satisfait plus les besoins des utilisateurs et aucune main- tenance ne peut palier au probl`eme. * Il est d'epass'e par la technologie. * Le client n'a plus besoin du logiciel. * Le d'emontage du logiciel est assimil'e comme la fin de vie du logiciel. * Il faut donc supprimer les executables, les drivers et les donnees. ### Autres mod`eles de d´eveloppements logiciels #### Le mod`ele en Waterfall * Expression des besoins * Spécifications * Conception * Développement * Tests * Maintenance #### Le mod`ele en V * Etude préalable * Spécification * Conception général'o * Conception détaillée * Codage * Tests unitaires * Tests d'intégration * Validation recette * Exploitation #### Cycle de vie it´eratif et incremental * Expression des besoins * Spécifications * Développement * Evaluation * Validation * Développement ## Section III: M´ethode de conception orient'ee objet UML ### Introduction `a l’UML #### Presentation de UML * UML (Unified Modeling Language) est normalis´e par l'OMG (Object Management Group). * http://www.omg.org/spec/UML/ * Derni`ere version : 2.5.1 (D'ecembre 2017) * UML est une notation standard pour la mod 'elisation d'ap- plications `a base d'objets (et de composants depuis la version 2). * UML est utilisable dans de nombreux autres contextes de conception ou specification. * Exemple : `sch'ema de BDD`. * UML est un langage utilisant une notation graphique. #### Le mod`ele(diagramme) * Un mod`ele est une repr´esentation partielle de la r 'ealit'e. * Abstraction de ce qui est interessant pour un contexte donne. Vue subjective et simplifi´ee d'un syst`eme. * Avec UML, on va s'int'eresser principalement aux mod`eles d'applications informatiques : * Un mod`ele UML = des diagrammes UML #### L'utilit´e des * Faciliter la comprehension d'un syst`eme : * Permettre 'egalement la communication avec le client. Vision de communication, de documentation. * D´efinir voire simuler le fonctionnement d'un syst`eme : * Dans ce cas, on se doit d'etre le plus precis possible dans le contenu des mod`eles pour s'approcher du code. * Vision de d'eveloppement, de production. ### Les diagrammes de UML #### Introductio * Afin d'assurer un bon niveau de coherence et d'homogen´eit´e sur l'ensemble des mod`eles, UML propose : * D'une part un certain nombre de r`egles d''ecriture ou de representations graphiques normalis´ees. * Et d'autre part des m'ecanismes ou des concepts communs applicables `a l'ensemble des diagrammes. * Çertains 'el'ements, comme les st´er'´eotypes, sont sp ecifiquement pr´evus pour assurer une réelle capacit e: * D'adaptation. * Et d''evolution. * La notation pour prendre en compte les particularit´es des differentes situations `a mod´eliser. #### Les diff´erents types de diagrammes * UML, dans sa version 2, propose 13 diagrammes qui peuvent ^etre utilises dans la description d'un systeme. * Les diagrammes sont regroup'es dans deux grands ensembles. * Les diagrammes Structurels. * Les diagrammes comportementaux. * Les diagrammes d'interactions. #### Diagrammes selon les axes de mod´elisation * **Diagrammes de cas d'utilisation**: FONCTIONNEL * **Diagrammes de séquence**: STATIQUE * **Diagrammes d'états-transitions**: DYNAMIQUE * **Diagrammes de classes**: STATIQUE * **Diagrammes d'objets**: STATIQUE * **Diagrammes de déploiement**: STATIQUE * **Diagrammes de composants**: STATIQUE * **Diagrammes de collaborations**: DYNAMIQUE * **Diagrammes d'activités**: DYNAMIQUE #### Hi´erarchie des diagrammes UML * **Diagramme**: * **Diagramme structurel**: * **Diagramme de classes**: * **Diagramme de structure composite**: * **Diagramme de composants**: * **Diagramme d'objets**: * **Diagramme de paquetages**: * **Diagramme de déploiement**: * **Diagramme de comportement**: * **Diagramme d'activité**: * **Diagramme des cas d'utilisation**: * **Diagramme états-transitions**: * **Diagramme d'interaction**: * **Diagramme de sequence**: * **Diagramme global d'interaction**: * **Diagramme de communication**: * **Diagramme de temps**: #### Les 5 vues de Kruchten * **Aspect statique**: classes et objets paquetages * **Aspect dynamique**: d'interaction (séquences, collaboration), d'états-transitions et d'activité * **Aspect statique**: les paquetages les méthodes les threads * **Vue logique**: * **Vue des cas d'utilisation**: * **Vue implantation**: * **Vue de déploiement**: * **Vue des processus**: * **Aspect parallélisme**: threads processus tâches interactions * **Aspect fonctionnel**: Cas d'utilisations acteurs classes collaboration * **Aspect répartition**: diagramme de déploiement nœuds, modules #### Les diagrammes * Ces diagrammes, au nombre de six, ont vocation `a representer l'aspect statique d'un systeme (classes, objets, composants. . . ). * **Diagramme de classes**: represente la description statique du systeme en integrant dans chaque classe la partie d'edi'ee aux donn'ees et celle consacree aux traitements. C'est le dia- gramme pivot de l'ensemble de la mod´elisation d'un systeme. * **Diagramme d'objets**: permet la repr´esentation d'instances des classes et des liens entre instances. * **Diagramme de composant (modifi´e dans UML 2)**: repr ´esente les differents constituants du logiciel au niveau de l'impl ´ementation d'un syst`eme. * **Diagramme de d'eploiement (modifi'e dans UML 2)**: d'ecrit l'architecture technique d'un syst`eme avec une vue centr´ee sur la repartition des composants dans la configuration d'ex- ploitation. * **Diagramme de paquetage (nouveau dans UML 2)** ; donne une vue d'ensemble du systeme structur´e en paquetage. Chaque paquetage represente un ensemble homog`ene d''el'ements du syst`eme (classes, composants...). * **Diagramme de structure composite**: permet de d 'ecrire la structure interne d'un ensemble complexe composée par exemple de classes ou d'objets et de composants techniques. Ce dia- gramme met aussi l'accent sur les liens entre les sous en- sembles qui collaborent. * Ces diagrammes representent la partie dynamique d'un syst`eme r´eagissant aux 'ev'enements et permettant de produire les resultats attendus par les utilisateurs. Sept diagrammes sont propos´es par UML: * **Diagramme des cas d'utilisation**: est destin'e `a representer les besoins des utilisateurs par rapport au syst`eme. II constitute un des diagrammes les plus structurants dans l'analyse d'un syst`eme. * **Diagramme d''etat-transition (machine d''etat)**: montre les differents 'etats des objets en r 'eaction aux 'ev'enements. * **Diagramme d'activit'es (modifi'e dans UML 2)**: donne une vi- sion des encha^inements des activit´es propres a une operation ou un cas d'utilisation. Il permet aussi de representer les flots de contr^ole et les flots de donn'ees. * **Diagramme global d'interaction (nouveau dans UML 2)**: fournit une vue generale des interactions d'ecrites dans le diagramme des 'equence et des flots de contr^ole d'ecrits dans le diagramme d'activit´es. * **Diagramme de temps (nouveau dans UML 2)** : permet de repr´esenter les 'etats et les interactions d'objets dans un contexte ou`le temps a une forte influence sur le comportement du syst`eme `a g'erer. #### Organisation d'un * Quand on veut realiser un projet en utilisant la m ethode UML, on divise le projet sous plusieurs mod 'eles. Chaque mod´ele peut contenir un nombre de diagrammes. Ces mod´eles sont list'es comme suit : * **Mod'ele des besoins**: Mod'ele d'analyse * **Mod'ele de metier**: * **Mod'ele de conc ´eption**: Mod´ele de r'ealisation * Le modele des besoins : Ce modele regroupe les principales fonctionnalit´es du projet en se basant sur le cahier des charges. Il peut contenir le diagramme de cas d'utilisations. On peut faire un diagramme de cas d'utilisation g'eneral et un dia- gramme de cas d'utilisation d'etaill´e. * Le modele d'analyse : Dans ce mod´ele on trouve la structure du systeme, les acteurs qui interagissent dans le systeme et le traitement du systeme. Ce modele peut contenir le dia- gramme de classe, le diagramme ramme de s'equence. * Le mod´ele metier : Ce mod´ele contient le diagramme d'acti- vit´e qui decrit les processus du systeme. On utilise un dia- gramme d'activit´e par processus. * Le modele de conc´eption : II d'ecrit le cot´e logiciel du pro- jet. Ce modele contient le diagramme de classe du cot´e lo- giciel(ex : les classes java ). Ce dernier peut generer la base de donnee et les classes. * Le modele physique : Ce modele contient les diagrammes de d'eploiment et de composants pour d'ecrire la realisation du projet dans la r ealit´e. ### Notion d'objet #### Introductio * On construit des mod`eles de systemes complexes parce que nous ne pouvons pas comprendre un systeme dans sa totalit´e. Des techniques de mod elisation performantes sont n'ecessaires face `a l'augmentation de la complexit'e des syst`emes. Il ya de nombreux facteurs `a la r'eussite d'un projet et avoir une m'ethodologie rigou- reuse est un facteur essentiel. Un langage de mod'elisation doit comprendre : * Les 'el'ements du mod`ele : des concepts de mod ´elisation fon- damentaux et une s'emantique. * Une notation : une interpr´etation visuelle des 'el 'ements du mod`ele .