InnovAI DataScience UML Unified Modified Language Jimmitry PAYET

Innov-AI Data-Science UML Unified Modified Language Jimmitry PAYET - Researcher / Developer

Plan • A - Découverte • B - Approche fonctionnelle versus approche objet • C - De marche ge ne rale de mode lisation • D - Les Diffe rents types de diagrammes • E - Conclusion

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

Introduction • Complexite croissante des syste mes d’information • • Programmation oriente e objet (P. O. O. ) • • = Méthode créé (MERISE, Booch, OMT, OOSE …) X Méthodes classiques ont des limites Object Management Group (OMG) • > de finir une notation standard

Introduction • UML (Unified Modified Language « langage de mode lisation objet unifie » ) • • fusion des me thodes Booch, OMT (Object Modelling Technique) et OOSE (Object Oriented Software Engineering) 1995 UML est devenu un standard incontournable

Introduction • Simula, premier langage de programmation a imple menter le concept de type abstrait a l'aide de classes (1967) • En 1976 de ja , Smalltalk imple mente les concepts fondateurs de l'approche objet : encapsulation, agre gation, he ritage • Les premiers compilateurs C++ datent du de but des anne es 80 • L'approche objet est devenue une re alite. • Object = outils et de langages performants • Ce n'est plus une mode, mais un re flexe quasi-automatique de s lors qu'on cherche a concevoir des logiciels complexes

Introduction • Point négatifs de l’approche objet : • elle est moins intuitive que l'approche fonctionnelle • Malgre les apparences, il est plus naturel pour l'esprit humain de de composer un proble me informatique sous forme de fonction. • • Or, rien dans les concepts de base de l'approche objet ne dicte comment mode liser la structure objet d'un syste me de manie re pertinente. • Sans un cadre me thodologique approprie , la de rive fonctionnelle de la conception est ine vitable… L'application des concepts objet ne cessite une tre s grande rigueur. • penser objet se n'est pas que par un langage de programmation • Connai tre C++ ou Java c'est bien, mais les utiliser a bon escient, c’est une autre affaire. . .

Introduction • Qui va nous guider dans l'utilisation des concepts objet, si ce ne sont pas les langages oriente s objet ? • UML • un langage (pour s'exprimer clairement a l'aide des concepts objets) • • une de marche d'analyse et de conception objet • • Le langage doit permettre de repre senter des concepts abstraits (graphiquement par exemple), limiter les ambigui te s (parler un langage commun, au vocabulaire pre cis, inde pendant des langages oriente s objet), faciliter l'analyse (simplifier la comparaison et l'e valuation de solutions). penser objet de s le de part une dimension me thodologique

Introduction • une analyse objet passe par une mode lisation objet • Qu’est-ce qu’un mode le ? • Un mode le est une abstraction de la re alite. L'abstraction est un des piliers de l'approche objet. • identifier les caracte ristiques inte ressantes d'une entite en vue d'une utilisation pre cise • L'abstraction de signe aussi le re sultat de ce processus, c'est-a -dire l'ensemble des caracte ristiques essentielles d'une entite , retenues par un observateur.

Introduction • Un mode le est une vue subjective, mais pertinente de la re alite • il en donne donc une vue juste et pertinente • Le caracte re abstrait d'un mode le doit notamment permettre de faciliter la compre hension du syste me e tudie • Il • re duit la complexite du syste me e tudie • permet de simuler le syste me, • le repre sente • et reproduit ses comportements.

Introduction • Concre tement, un mode le re duit (de composé) de la re alite , exploitables par des moyens mathe matiques ou informatiques • UML permet donc de mode liser une application selon une vision objet • L’appre hension d’UML est complexe car UML est a la fois : • une norme • un langage de mode lisation objet • un support de communication • un cadre me thodologique

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

UML est une norme • Fin 1997, UML est devenu une norme OMG (Object Management Group). • L'OMG est un organisme a but non lucratif • cre e en 1989 a l'initiative de grandes socie te s (HP, Sun, Unisys, American Airlines, Philips…) • Aujourd'hui, l'OMG fe de re plus de 850 acteurs du monde informatique • Son ro le est de promouvoir des standards qui garantissent l'interope rabilite entre applications oriente es objet, de veloppe es sur des re seaux he te roge nes

UML est une norme • L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un mode le standard pour la construction d'applications a objets distribue s (re partis sur un re seau). • CORBA fait partie d'une vision globale de la construction d'applications re parties, appele e OMA (Object Management Architecture) • favoriser l'essor industriel des technologies objet • un ensemble de solutions technologiques non proprie taires • UML a e te adopte (normalise ) par l'OMG et inte gre a l'OMA, car il participe a cette vision et parce qu'il re pond a la "philosophie" OMG.

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

UML est un langage de mode lisation objet • Pour penser et concevoir objet il faut • savoir "prendre de la hauteur", • jongler avec des concepts abstraits, • inde pendants des langages d'imple mentation et des contraintes purement techniques • Les langages de programmation ne sont pas un support d'analyse ade quat pour "concevoir objet » . • Ils ne permettent pas de de crire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse ite rative.

UML est un langage de mode lisation objet • Pour conduire une analyse objet cohe rente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de proprie te s et de cardinalite s • Utiliser le langage de programmation comme support de conception est plus contraignant, enfermant. • La feuille de papier vous fera gagner du temps… • L’approche objet ne cessite une analyse re fle chie, qui passe par diffe rentes phases exploratoires.

UML est un langage de mode lisation objet • Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits carte siens… • Voila pourquoi il ne faut pas se contenter d'une imple mentation objet, mais se discipliner a "penser objet" au cours d'une phase d'analyse pre alable. • Sinon se sera du fonctionnelle • Toutes les de rives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation. . . ) ou une utilisation de tourne e de ces concepts (he ritage sans classification…). • programmer en C++ ou en Java n'implique pas force ment concevoir objet… les langages sont permissifs

UML est un langage de mode lisation objet • Les difficulte s de mise en œuvre d'une approche "re ellement objet" ont engendre bien souvent des de ceptions • le code n'est qu'un « moyen" • Le respect des concepts fondamentaux de l'approche objet prime sur la manie re dont on les imple mente. • Ne penser qu'a travers un langage de programmation objet de tourne de l’essentiel. • Pour sortir les technologies objet de cette impasse, l'OMG propose UML.

UML est un langage de mode lisation objet • UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'e laborer des mode les objet, inde pendamment de tout langage de programmation. • UML est un langage formel, de fini par un me tamode le • • Le me tamode le d'UML de crit de manie re tre s pre cise tous les e le ments de mode lisation (les concepts ve hicule s et manipule s par le langage) et la se mantique de ces e le ments (leur de finition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet.

UML est un langage de mode lisation objet • Un me tamode le permet de limiter les ambigui te s et encourage la construction d’outils. • Il permet aussi de classer les diffe rents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. • Enfin, on peut noter que le me tamode le d'UML est lui-me me de crit par un me ta-me tamode le de manie re standardise e, a l'aide de MOF (Meta Object Facility : norme OMG de description des me tamode les).

UML est un langage de mode lisation objet • Ve ritable cle de vou te de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. • UML n'est pas a l'origine des concepts objets, mais il en constitue une e tape majeure, car il unifie les diffe rentes approches et en donne une de finition plus formelle.

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

UML est un support de communication • UML est avant tout un support de communication performant, qui facilite la repre sentation et la compre hension de solutions objet • Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'e valuation de solutions • L'aspect formel de sa notation limite les ambigui te s et les incompre hensions. • Son inde pendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. • La notation graphique d'UML n'est que le support du langage. La ve ritable force d'UML, c'est qu'il repose sur un me tamode le. En d'autres termes : la puissance et l'inte re t d'UML, c'est qu'il normalise la se mantique des concepts qu'il ve hicule !

UML est un support de communication • Qu'une association d'he ritage entre deux classes soit repre sente e par une fle che termine e par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne a votre mode le. • La notation graphique est essentiellement guide e par des conside rations esthe tiques, me me si elle a e te pense e dans ses moindres de tails. • Par contre, utiliser une relation d'he ritage, refle te l'intention de donner a votre mode le un sens particulier. • Un "bon" langage de mode lisation doit permettre a n'importe qui de de chiffrer cette intention de manie re non e quivoque. • Il est donc primordial de s'accorder sur la se mantique des e le ments de mode lisation, bien avant de s'inte resser a la manie re de les repre senter.

UML est un support de communication • Le me tamode le UML apporte une solution a ce proble me fondamental. • UML est donc bien plus qu'un simple outil qui permet de "dessiner" des repre sentations mentales… • Il permet de parler un langage commun, normalise et accessible, car visuel.

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

UML est un cadre me thodologique • Une autre caracte ristique importante d'UML, est qu'il cadre l’analyse. • UML permet de repre senter un syste me selon diffe rentes vues comple mentaires : les diagrammes • Un diagramme UML est une repre sentation graphique, qui s'inte resse a un aspect pre cis du mode le ; c'est une perspective du mode le. • Chaque type de diagramme UML posse de une structure (les types des e le ments de mode lisation qui le composent sont pre de finis) et ve hicule une se mantique pre cise (il offre toujours la me me vue d'un syste me).

UML est un cadre me thodologique • Combine s, les diffe rents types de diagrammes UML offrent une vue comple te des aspects statiques et dynamiques d'un syste me. • Les diagrammes permettent donc d'inspecter un mode le selon diffe rentes perspectives et guident l'utilisation des e le ments de mode lisation (les concepts objet), car ils posse dent une structure. • Une caracte ristique importante des diagrammes UML, est qu'ils supportent l'abstraction. Cela permet de mieux contro ler la complexite dans l'expression et l'e laboration des solutions objet. • UML n'introduit pas d'e le ments de mode lisation propres a une activite (analyse, conception. . . ) ; le langage reste le me me a tous les niveaux d’abstraction.

UML est un cadre me thodologique • Cette approche simplificatrice facilite le passage entre les niveaux d’abstraction. • Un seul langage pour tout • "retours en arrie re" entre niveaux d'abstraction sont facilite s • UML favorise donc le prototypage, et c'est la une de ses forces. • En effet, mode liser une application n'est pas une activite line aire. • Il s'agit d'une ta che tre s complexe, qui ne cessite une approche ite rative, car il est plus efficace de construire et valider par e tapes, ce qui est difficile a cerner et mai triser. • UML permet donc non seulement de repre senter et de manipuler les concepts objet, il sous-entend une de marche d'analyse qui permet de concevoir une solution objet de manie re ite rative, gra ce aux diagrammes, qui supportent l’abstraction.

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

UML n'est pas une me thode • UML est un langage qui permet de repre senter des mode les, mais il ne de finit pas le processus d'e laboration des mode les. Qualifier UML de "me thode objet" n'est donc pas tout a fait approprie • Une me thode propose aussi un processus, qui re git notamment l'enchai nement des activite s de production d'une entreprise. Or UML n'a pas e te pense pour re gir les activite s de l’entreprise. • Les auteurs d'UML sont tout a fait conscients de l'importance du processus, mais ce sujet a e te intentionnellement exclu des travaux de l’OMG. • Comment prendre en compte toutes les organisations et cultures d'entreprises ? • Un processus est adapte (donc tre s lie ) au domaine d'activite de l'entreprise ; me me s'il constitue un cadre ge ne ral, il faut l'adapter au contexte de l’entreprise. • un processus métier est une discipline a part entie re, c'est un objectif qui de passe tre s largement le cadre de l'OMA.

UML n'est pas une me thode • UML gère les processus de développement Objet et c’est tout • les auteurs d'UML pre conisent d'utiliser une de marche : • • guide e par les besoins des utilisateurs du syste me • centre e sur l'architecture logicielle • ite rative et incre mentale D'apre s les auteurs d'UML, un processus de de veloppement qui posse de ces qualite s fondamentales "devrait" favoriser la re ussite d'un projet de manière générale.

UML n'est pas une me thode • UML gère les processus de développement Objet et c’est tout • les auteurs d'UML pre conisent d'utiliser une de marche : • • guide e par les besoins des utilisateurs du syste me • centre e sur l'architecture logicielle • ite rative et incre mentale D'apre s les auteurs d'UML, un processus de de veloppement qui posse de ces qualite s fondamentales "devrait" favoriser la re ussite d'un projet de manière générale.

A - Découverte • Introduction • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • • UML n'est pas une me thode Conclusion

Conclusion • Comme UML n'impose pas de me thode de travail particulie re, il peut e tre inte gre a n'importe quel processus de de veloppement logiciel de manie re transparente • UML est une sorte de boi te a outils • permet d'ame liorer progressivement vos me thodes de travail, tout en pre servant vos modes de fonctionnement. • Inte grer UML par e tapes dans un processus, de manie re pragmatique, est tout a fait possible. • La faculte d'UML de se fondre dans le processus courant, tout en ve hiculant une de marche me thodologique, facilite son inte gration et limite de nombreux risques (rejet des utilisateurs, cou ts…).

Conclusion • Inte grer UML dans un processus ne signifie donc pas re volutionner ses me thodes de travail, mais cela devrait e tre l’occasion de se remettre en question. • se remettre en question = amélioration

Qu’avez vous retenu ? 15 m

Plan • A - Découverte • B - Approche fonctionnelle vs approche objet • C - De marche ge ne rale de mode lisation • D - Les Diffe rents types de diagrammes • E - Conclusion

B - Approche fonctionnelle versus approche objet • Approche fonctionnelle • Approche objet

Approche fonctionnelle • La de coupe fonctionnelle d'un proble me informatique : une approche intuitive • consiste a de couper le proble me en blocs inde pendants • La re utilisabilite du code • Le de coupage d’un proble me en blocs inde pendants (fonctions et proce dures) va permettre aux programmeurs de re utiliser les fonctions de ja de veloppe es • La productivite se trouve donc accrue

Approche fonctionnelle • Le revers de la me daille : maintenance complexe en cas d’e volution • une simple mise a jour du logiciel a un point donne , peut impacter en cascade une multitude d'autres fonctions • e criture du logiciel et sa maintenance plus complexe. • En cas d'e volution majeure du logiciel (passage de la gestion d'une bibliothe que a celle d'une me diathe que par exemple), le sce nario est encore pire • la multiplication des points de maintenance, engendre e par le chai nage des fonctions, rend l'adaptation tre s laborieuse • Le logiciel doit e tre retouche dans sa globalite

B - Approche fonctionnelle versus approche objet • Approche fonctionnelle • Approche objet

Approche objet • Un objet est une entite aux frontie res pre cises qui posse de une identite (un nom) • Un ensemble d'attributs caracte rise l'e tat de l’objet • Un ensemble d'ope rations (me thodes) en de finissent le comportement. • Un objet est une instance de classe (une occurrence d'un type abstrait). • Une classe est un type de donne es abstrait, caracte rise par des proprie te s (attributs et me thodes) communes a des objets et permettant de cre er des objets posse dant ces proprie te s.

Classe et instance • Une classe • Une instance de classe

Approche objet • Les autres concepts importants de l'approche objet • l’encapsulation • L’encapsulation consiste a masquer les de tails d'imple mentation d'un objet, en de finissant une interface. • L'interface est la vue externe d'un objet, elle de finit les services accessibles (offerts) aux utilisateurs de l’objet. • L'encapsulation facilite l'e volution d'une application car elle stabilise l'utilisation des objets : on peut modifier l'imple mentation des attributs d'un objet sans modifier son interface. • L'encapsulation garantit l'inte grite des donne es, car elle permet d'interdire l'acce s direct aux attributs des objets.

Approche objet • Les autres concepts importants de l'approche objet • l’he ritage • L'he ritage est un me canisme de transmission des proprie te s d'une classe (ses attributs et me thodes) vers une sous-classe. • Plusieurs classes peuvent e tre ge ne ralise es en une classe qui les factorise, afin de regrouper les caracte ristiques communes d'un ensemble de classes. • L'he ritage e vite la duplication et encourage la re utilisation. • La spe cialisation et la ge ne ralisation permettent de construire des hie rarchies de classes. L'he ritage peut e tre simple (mono classe mère) ou multiple.

Classe et instance • Exemple Héritage

Approche objet • Les autres concepts importants de l'approche objet • le polymorphisme • Le polymorphisme repre sente la faculte d'une me me ope ration de s'exe cuter diffe remment suivant le contexte de la classe ou elle se trouve. • Ainsi, une ope ration de finie dans une superclasse peut s'exe cuter de fac on diffe rente selon la sous-classe ou elle est he rite e.

Approche objet • Les autres concepts importants de l'approche objet • l’agre gation • Une relation d'agre gation permet de de finir des objets compose s d'autres objets. • L'agre gation permet d'assembler des objets de base, afin de construire des objets plus complexes.

Plan • A - Découverte • B - Approche fonctionnelle vs approche objet • C - De marche ge ne rale de mode lisation • D - Les Diffe rents types de diagrammes • E - Conclusion

C - De marche ge ne rale de mode lisation • Qu'est-ce qu'un mode le ? • Comment mode liser avec UML ? • L’utilisation de diagrammes

Qu'est-ce qu'un mode le ? • Un mode le est une abstraction de la re alite • Le caracte re abstrait d'un mode le doit notamment permettre : • de faciliter la compre hension du syste me e tudie : un mode le re duit la complexite du syste me e tudie. • de simuler le syste me e tudie : un mode le repre sente le syste me e tudie et reproduit ses comportements.

C - De marche ge ne rale de mode lisation • Qu'est-ce qu'un mode le ? • Comment mode liser avec UML ? • L’utilisation de diagrammes

Qu'est-ce qu'un mode le ? • UML est un langage qui permet de repre senter des mode les, mais il ne de finit pas le processus d'e laboration des mode les : UML n’est donc pas une me thode de mode lisation. • Cependant, dans le cadre de la mode lisation d'une application informatique, les auteurs d'UML pre conisent d'utiliser une de marche : • • ite rative et incre mentale, • guide e par les besoins des utilisateurs du syste me, • centre e sur l'architecture logicielle. D'apre s les auteurs d'UML, un processus de de veloppement qui posse de ces qualite s devrait favoriser la re ussite d'un projet.

Qu'est-ce qu'un mode le ? • Une de marche ite rative et incre mentale • Pour mode liser (comprendre et repre senter) un syste me complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par e tapes. • Cette de marche doit aussi s'appliquer au cycle de de veloppement dans son ensemble, en favorisant le prototypage. • Le but est de mieux mai triser la part d'inconnu et d'incertitudes qui caracte risent les syste mes complexes.

Qu'est-ce qu'un mode le ? • Avec UML, ce sont les utilisateurs qui guident la de finition des mode les • Le pe rime tre du syste me a mode liser est de fini par les besoins des utilisateurs (les utilisateurs de finissent ce que doit e tre le syste me). Le but du syste me a mode liser est de re pondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du syste me).

Qu'est-ce qu'un mode le ? • Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de de veloppement (ite ratif et incre mental) : • a chaque ite ration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. • a chaque ite ration de la phase de conception et de re alisation, on veille a la prise en compte des besoins des utilisateurs. • a chaque ite ration de la phase de test, on ve rifie que les besoins des utilisateurs sont satisfaits.

Qu'est-ce qu'un mode le ? • Une de marche centre e sur l’architecture • Une architecture adapte e est la cle de vou te du succe s d'un de veloppement. • Elle de crit des choix strate giques qui de terminent en grande partie les qualite s du logiciel (adaptabilite , performances, fiabilite …). • Ph. Kruchten propose diffe rentes perspectives, inde pendantes et comple mentaires, qui permettent de de finir un mode le d'architecture (publication IEEE, 1995).

Qu'est-ce qu'un mode le ? • Il propose que plusieurs perspectives concourent a l’expression de l’architecture d’un syste me et il explique qu’il est ne cessaire de garantir la se paration et l’inde pendance de ces diffe rentes perspectives. • L’e volution de l’une des perspectives ne doit pas avoir d’impact (sinon limite ) sur les autres. • sche ma 4+1 vues

Qu'est-ce qu'un mode le ?

Qu'est-ce qu'un mode le ?

Qu'est-ce qu'un mode le ?

Qu'est-ce qu'un mode le ?

Qu'est-ce qu'un mode le ? • La vue logique • Cette vue concerne « l’inte grite de conception » . • Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle mode lise les e le ments et me canismes principaux du syste me. • Elle identifie les e le ments du domaine, ainsi que les relations et interactions entre ces e le ments « notions de classes et de relations » • les e le ments du domaine sont lie s au(x) me tier(s) de l’entreprise • ils sont indispensables a la mission du syste me • ils gagnent a e tre re utilise s (ils repre sentent un savoir-faire).

Qu'est-ce qu'un mode le ? • La vue logique • Cette vue organise aussi (selon des crite res purement logiques), les e le ments du domaine en "cate gories" : • pour re partir les ta ches dans les e quipes, • regrouper ce qui peut e tre ge ne rique, • isoler ce qui est propre a une version donne e, etc…

Qu'est-ce qu'un mode le ? • La vue des composants / de développement • Cette vue concerne « l’inte grite de gestion » . • Elle exprime la perspective physique de l’organisation du code en termes de modules, de composants et surtout des concepts du langage ou de l’environnement d’imple mentation. • aspects de gestion du code, d’ordre de compilation, de re utilisation, d’inte gration et d’autres contraintes de de veloppement pur • Pour repre senter cette perspective, UML fournit des concepts adapte s tels que les modules, les composants, les relations de de pendance, l’interface …

Qu'est-ce qu'un mode le ? • La vue des composants / de développement • Cette vue de bas niveau (aussi appele e « vue de re alisation » ), montre ainsi • Cette vue identifie les modules qui re alisent (physiquement) les classes de la vue logique (fichiers sources, bibliothe ques dynamiques, bases de donne es, exe cutables, etc…). • l'organisation des composants, c'est-a -dire la distribution du code en gestion de configuration, les de pendances entre les composants… • les contraintes de de veloppement (bibliothe ques externes…) • l'organisation des modules en "sous-syste mes", les interfaces des soussyste mes et leurs • de pendances (avec d'autres sous-syste mes ou modules).

Qu'est-ce qu'un mode le ? • La vue des processus • Cette vue concerne « l’inte grite d’exe cution » . • Cette vue est tre s importante dans les environnements multita ches ; elle exprime la perspective sur les activite s concurrentes et paralle les. Elle montre ainsi : • la de composition du syste me en terme de processus (ta ches) • les interactions entre les processus (leur communication). • la synchronisation et la communication des activite s paralle les (threads).

Qu'est-ce qu'un mode le ? • La vue de de ploiement • Cette vue concerne « l’inte grite de performance » . • Elle exprime la re partition du syste me a travers un re seau de calculateurs et de nœuds logiques de traitements. Cette vue est particulie rement utile pour de crire la distribution d’un syste me re parti. • Elle montre : • la disposition et nature physique des mate riels, ainsi que leurs performances. • l'implantation des modules principaux sur les nœuds du re seau. • les exigences en terme de performances (temps de re ponse, tole rance aux fautes et pannes…).

Qu'est-ce qu'un mode le ? • La vue des cas d’utilisation • Cette vue est particulie re en ce sens qu’elle guide toutes les autres. • Cette vue permet : • de trouver le « bon » mode le • • Les cas d’utilisation permettent de guider la mode lisation. L’utilisation des sce narios et des cas d’utilisation s’ave re plus rigoureuse et plus syste matique les entretiens et l’analyse des documents pour de couvrir les abstractions du domaine. d’expliquer et de justifier ses choix • Il est en effet ne cessaire d’expliquer le syste me, de justifier les choix qui ont guide sa conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour cela UML offre des concepts adapte s tels que les sce narios et les cas d’utilisation.

C - De marche ge ne rale de mode lisation • Qu'est-ce qu'un mode le ? • Comment mode liser avec UML ? • L’utilisation de diagrammes

L’utilisation de diagrammes • De finition d’un diagramme • Un diagramme UML est une repre sentation graphique, qui s'inte resse a un aspect pre cis du mode le. C'est une perspective du mode le, pas "le mode le » . • Chaque type de diagramme UML posse de une structure (les types des e le ments de mode lisation qui le composent sont pre de finis). • Un type de diagramme UML ve hicule une se mantique pre cise (un type de diagramme offre toujours la me me vue d'un syste me). • Combine s, les diffe rents types de diagrammes UML offrent une vue comple te des aspects statiques et dynamiques d'un syste me. • Par extension et abus de langage, un diagramme UML est aussi un mode le (un diagramme mode lise un aspect du mode le global).

L’utilisation de diagrammes • Caracte ristiques diagrammes UML • Les diagrammes UML supportent l'abstraction. Leur niveau de de tail caracte rise le niveau d'abstraction du mode le. • La structure des diagrammes UML et la notation graphique des e le ments de mode lisation est normalise e (document "UML notation guide » ). • Rappel : la se mantique des e le ments de mode lisation et de leur utilisation est de finie par le me tamode le UML (document "UML semantics").

L’utilisation de diagrammes • Les diffe rents types de diagrammes UML • Il existe 2 types de vues du syste me qui comportent chacune leurs propres diagrammes : • • les vues statiques : • diagrammes de cas d’utilisation • diagrammes d’objets • diagrammes de classes • diagrammes de composants • diagrammes de de ploiement les vues dynamiques : • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Plan • A - Découverte • B - Approche fonctionnelle vs approche objet • C - De marche ge ne rale de mode lisation • D - Les Diffe rents types de diagrammes • E - Conclusion

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes de cas d’utilisation • Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un syste me • Ils centrent l'expression des exigences du syste me sur ses utilisateurs • La de termination et la compre hension des besoins sont souvent difficiles car les intervenants sont noye s sous de trop grandes quantite s d’informations • il faut clarifier et organiser les besoins des clients (les mode liser) • Pour cela, les cas d’utilisation identifient les utilisateurs du syste me (acteurs) et leurs interactions avec le syste me • Ils permettent de classer les acteurs et structurer les objectifs du syste me

Diagrammes de cas d’utilisation • Une fois identifie s et structure s, ces besoins: • de finissent le contour du syste me a mode liser (ils pre cisent le but a atteindre) • permettent d'identifier les fonctionnalite s principales (critiques) du syste me • Les use cases ne doivent donc en aucun cas de crire des solutions d’imple mentation. • Leur but est justement d'e viter de tomber dans la de rive d'une approche fonctionnelle, ou l'on liste une litanie de fonctions que le syste me doit re aliser.

Diagrammes de cas d’utilisation • Un acteur est un type ste re otype repre sentant une abstraction qui re side juste en dehors du syste me a mode liser. • Un acteur repre sente un ro le joue par une personne ou une chose qui interagit avec le syste me. (la me me personne physique peut donc e tre repre sente e par plusieurs acteurs en fonction des ro les qu’elle joue). • Pour identifier les acteurs, il faut donc se concentrer sur les ro les joue s par les entite s exte rieures au pe rime tre. • Enfin, un acteur n’est pas ne cessairement une personne physique : il peut e tre un service, une socie te , un syste me informatique …

Diagrammes de cas d’utilisation • Il existe 4 cate gories d’acteurs : • les acteurs principaux : les personnes qui utilisent les fonctions principales du syste me • les acteurs secondaires : les personnes qui effectuent des ta ches administratives ou de maintenance. • le mate riel externe : les dispositifs mate riels incontournables qui font partie du domaine de l’application et qui doivent e tre utilise s. • les autres syste mes : les syste mes avec lesquels le syste me doit interagir.

Diagrammes de cas d’utilisation • • Le cas d’utilisation (ou use case) correspond a un objectif du syste me, motive par un besoin d’un ou plusieurs acteurs. • L'ensemble des use cases de crit les objectifs (le but) du syste me. La relation • Elle exprime l’interaction existant entre un acteur et un cas d’utilisation.

Diagrammes de cas d’utilisation • Il existe 3 types de relations entre cas d’utilisation : • la relation de ge ne ralisation • la relation d’extension • la relation d’inclusion

Diagrammes de cas d’utilisation • La relation de ge ne ralisation • Dans une relation de ge ne ralisation entre 2 cas d’utilisation, le cas d’utilisation enfant est une spe cialisation du cas d’utilisation parent.

Diagrammes de cas d’utilisation • La relation de ge ne ralisation • NB : un acteur peut e galement participer a des relations de ge ne ralisation avec d’autres acteurs. Les acteurs « enfant » seront alors capables de communiquer avec les me mes cas d’utilisation que les acteurs « parents » .

Diagrammes de cas d’utilisation • La relation d’inclusion • NB : un acteur peut e galement participer a des relations de ge ne ralisation avec d’autres acteurs. Les acteurs « enfant » seront alors capables de communiquer avec les me mes cas d’utilisation que les acteurs « parents » . • Elle indique le cas d’utilisation source contient aussi le comportement de crit dans le cas d’utilisation destination. • Cette relation permet ainsi de de composer des comportements et de de finir des comportements partageables entre plusieurs cas d’utilisation. • Pour re aliser l’objectif « virement » , on utilise obligatoirement « identification » .

Diagrammes de cas d’utilisation • La relation d’extension • Elle indique le cas d’utilisation source ajoute son comportement au cas d’utilisation destination. • L’extension peut e tre soumise a condition. Le comportement ajoute est inse re au niveau d’un point d’extension de fini dans le cas d’utilisation destination. • Cette relation permet de mode liser les variantes de comportement d’un cas d’utilisation (selon les interactions des acteurs et l’environnement du syste me).

Diagrammes de cas d’utilisation • Paquetage • Un paquetage (package) est un groupement d’e le ment de mode lisation. • Un paquetage peut contenir aussi bien des paquetages emboi te s que des e le ments de mode lisation ordinaires.

Diagrammes de cas d’utilisation • Les sce narios • Un cas d’utilisation est une abstraction de plusieurs chemins d’exe cution. Une instance de cas d’utilisation est appele e : « sce nario » . • Chaque fois qu’une instance d’un acteur de clenche un cas d’utilisation, un sce nario est cre e (le cas d’utilisation est instancie ). Ce sce nario suivra un chemin particulier dans le cas d’utilisation. • Un sce nario ne contient pas de branche du type « Si condition. . . alors » car pendant l’exe cution, la condition est soit vraie, soit fausse, mais elle aura une valeur. • Apre s la description des cas d’utilisation, il est ne cessaire de se lectionner un ensemble de sce narios qui vont servir a piloter l’ite ration en cours de de veloppement.

Diagrammes de cas d’utilisation • Les sce narios • Le choix et le nombre de sce narios a retenir est une e tape difficile a re aliser : l’exhaustivite est difficile, voire impossible a atteindre. Le nombre d’instances pour un cas d’utilisation peut e tre s important, voire infini. • Les sce narios peuvent e tre classe s en : • sce narios principaux : il correspond a l’instance principal du cas d’utilisation. C’est souvent le chemin « normal » d’exe cution du cas d’utilisation qui n’implique pas d’erreurs. • Sce narios secondaires : il peut e tre un cas alternatif (un choix), un cas exceptionnel ou une erreur.

Diagrammes de cas d’utilisation • Les sce narios sont utiles pour : • analyser et concevoir le syste me • justifier les choix effectue s (ils serviront a la documentation des cas d’utilisation) • tester : les sce narios constituent le meilleur moyen de spe cifier les tests.

Diagrammes de cas d’utilisation • • Lors de l’e laboration d’un cas d’utilisation, il faut se demande • quelles sont les ta ches de l’acteur ? • quelles informations l’acteur doit-il cre er, sauvegarder, modifier ou lire ? • l’acteur devra-t-il informer le syste me des changements externes ? • le syste me devra-t-il informer l’acteur des conditions internes ? • quelles sont les conditions de de marrage et d’arre t du cas d’utilisation ? La porte e des cas d’utilisation de passe largement la de finition des besoins du syste me. Les cas d’utilisation interviennent tout au long du cycle de vie du projet, depuis le cahier des charges jusqu’aux tests.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagramme de classes • Le diagramme de classes exprime la structure statique du syste me en termes de classes et de relations entre ces classes. • L’inte re t du diagramme de classe est de mode liser les entite s du syste me d’information • Le diagramme de classe permet de repre senter l’ensemble des informations finalise es qui sont ge re es par le domaine. • Ces informations sont structure es, c’est-a -dire qu’elles ont regroupe es dans des classes. Le diagramme met en e vidence d’e ventuelles relations entre ces classes

Diagramme de classes • Le diagramme de classes comporte 6 concepts : • classe • attribut • identifiant • relation • ope ration • ge ne ralisation / spe cialisation

Diagramme de classes • • Repre sentation : les classes sont repre sente es par des rectangles compartimente s : • le 1 er compartiment repre sente le nom de la classe • le 2 e me compartiment repre sente les attributs de la classe • le 3 e me compartiment repre sente les ope rations de la classe La suppression des compartiments reste purement visuelle : elle ne signifie pas qu’il n’y a pas d’attribut ou d’ope ration.

Diagramme de classes • La notion d’attribut • De finition : Une classe correspond a un concept global d’information et se compose d’un ensemble d’informations e le mentaires, appele es attributs de classe. • Un attribut repre sente la mode lisation d’une information e le mentaire repre sente e par son nom et son format.

Diagramme de classes • UML de finit 3 niveaux de visibilite pour les attributs : • public (+) : l’e le ment est visible pour tous les clients de la classe • prote ge (#) : l’e le ment est visible pour les sous-classes de la classe • prive (-) : l’e le ment n’est visible que par les objets de la classe dans laquelle il est de clare.

Diagramme de classes • La notion d’identifiant • L’identifiant est un attribut particulier, qui permet de repe rer de fac on unique chaque objet, instance de la classe. • Commande/numero

Diagramme de classes • La notion d’ope ration • l’ope ration repre sente un e le ment de comportement des objets, de fini de manie re globale dans la classe • Une ope ration est une fonctionnalite assure e par une classe. • La description des ope rations peut pre ciser les parame tres d’entre e et de sortie ainsi que les actions e le mentaires a exe cuter. • editer. Facture. Mensuelle(int)

Diagramme de classes • UML de finit 3 niveaux de visibilite pour les opérations : • public (+) : l’e le ment est visible pour tous les clients de la classe • prote ge (#) : l’e le ment est visible pour les sous-classes de la classe • prive (-) : l’e le ment n’est visible que par les objets de la classe dans laquelle il est de clare.

Diagramme de classes • La notion de relation • S’il existe des liens entre objets, cela se traduit ne cessairement par des relations qui existent entre leurs classes respectives. • Les liens entre les objets doivent e tre conside re s comme des instances de relations entre classes. • Il existe plusieurs types de relations entre classes : • l’association • la ge ne ralisation/spe cialisation • la de pendance

Diagramme de classes • L’association est la relation la plus courante et la plus riche du point de vue se mantique. • Une association est une relation statique n-aire (le plus souvent : elle est binaire) : c’est-a -dire qu’elle relie plusieurs classes entre elles. • L’association existe entre les classes et non entre les instances : elle est introduite pour montrer une structure et non pour montrer des e changes de donne es.

Diagramme de classes • la multiplicite • 1 = Un et un seul • 0. . 1 = Ze ro ou un • N ou * = N (entier naturel) • M. . N = De M a N (entiers naturels) • 0. . * = De ze ros a plusieurs • 1. . * = De 1 a plusieurs

Diagramme de classes • la navigabilite • La navigabilite n’a rien a voir avec le sens de lecture de l’association. Une navigabilite place e sur une terminaison cible indique si ce ro le est accessible a partir de la source. • Par de faut les associations sont navigables dans les 2 sens. • Dans certains cas, une seule direction de navigation est utile : l’extre mite d’association vers laquelle la navigation est possible porte alors une fle che.

Diagramme de classes • L’agre gation • Dans UML, l’agre gation n’est pas un type de relation mais une variante de l’association. • Une agre gation repre sente une association non syme trique dans laquelle une des extre mite s joue un ro le pre dominant par rapport a l’autre extre mite. • L’agre gation permet de mode liser des relations de type mai tre et esclaves. • L’agre gation permet de mode liser une contrainte d’inte grite et de de signer l’agre gat comme contrainte.

Diagramme de classes • Cas particulier des associations re flexives • On peut avoir des cas d’agre gation re flexive de s que l’on mode lise des relations hie rarchiques ou des liens de parente par exemple.

Diagramme de classes • La composition est un cas particulier de l’agre gation dans laquelle la vie des composants. • La composition implique, en plus de l’agre gation, une coi ncidence des dure es de vie des composants : la destruction de l’agre gat (ou conteneur) implique automatiquement la destruction de tous les composants lie s. • ON DELETE CASCADE (SQL)

Diagramme de classes • Le principe de ge ne ralisation / spe cialisation permet d’identifier parmi les objets d’une classe (ge ne rique) des sous-ensembles d’objets (des classes spe cialise es) ayant des de finitions spe cifiques • La classe plus spe cifique (appele e aussi classe fille, classe de rive e, classe spe cialise e, classe descendante . . . ) est cohe rente avec la classe plus ge ne rale (appele e aussi classe me re, classe ge ne rale …) • elle contient par he ritage tous les attributs, les membres, les relations de la classe ge ne rale, et peut contenir d’autres

Diagramme de classes • La spe cialisation multiple • Les classes peuvent avoir plusieurs superclasses • dans ce cas, la ge ne ralisation est dite multiple et plusieurs fle ches partent de la sous-classe vers les diffe rentes superclasses. • La ge ne ralisation multiple consiste a fusionner plusieurs classes en une seule classe. • La classe « client spe cial » est une spe cialisation de client et de salarie. Ce mode le permet d’indiquer que l’on accorde des tarifs pre fe rentiels aux salarie s.

Diagramme de classes • Les contraintes sur les associations • Il existe plusieurs types de contraintes sur les associations : • La contrainte de partition • la contrainte d’exclusion • la contrainte de totalite • la contrainte d’inclusion

Diagramme de classes • La contrainte de partition • Toutes les socie te s sont soit clientes, soit conside re es comme des prospects.

Diagramme de classes • la contrainte d’exclusion • Ici, un employe ne peut pas e tre a la fois directeur commercial et directeur financier. Mais tout employe n’est pas directeur commercial ou directeur financier (contrainte de partition).

Diagramme de classes • la contrainte de totalite • Toute socie te est au moins partenaire ou client privile gie e. Et elle peut e tre les 2 a la fois.

Diagramme de classes • la contrainte d’inclusion • Par exemple, on pourra indiquer que le contractant d’un contrat fait obligatoirement partie des individus assure s.

Diagramme de classes • La de pendance • Les relations de de pendance sont utilise es lorsqu’il existe une relation se mantique entre plusieurs e le ments qui n’est pas de nature structurelle. • Une relation de de pendance de finit une relation unidirectionnelle entre un e le ment source et un e le ment cible • Une de pendance est une relation entre deux e le ments de mode lisation dans laquelle toute modification effectue e sur un e le ment de mode lisation (l'e le ment influent) affecte l'autre e le ment (e le ment de pendant). • UML de finit 4 types de relation de de pendance. Pour chaque type de de pendance, un mot cle ou ste re otype entre guillemets peut e tre ajoute a la relation de de pendance pour pre ciser sa nature.

Diagramme de classes • Les 4 types de relation sont : • abstraction • • Liaison • • Les parame tres formels d’une classe ou collaboration parame trables doivent e tre lie s a des valeurs. Cette de pendance cre e une liaison entre la classe ou collaboration parame trable (la cible) et la classe ou collaboration parame tre e (source). Permission • • Il s’agit d’une relation de de pendance entre e le ments qui repre sentent un me me concept a diffe rents niveaux d’abstraction ou selon des points de vue distincts. Un e le ment (source) a le droit d’acce der a un espace de nommage (cible) Utilisation • Un e le ment (source) requiert la pre sence d’un autre e le ment (cible) pour son bon fonctionnement ou son imple mentation.

Diagramme de classes • Les paramètres possible: • abstraction • « de rive » • • « raffine » • • Repre sente une relation de de pendance entre des e le ments se mantiques diffe rents (analyse et conception par exemple). « re alise » • • Repre sente un e le ment de fini ou calcule a partir d’un autre. Par exemple, un attribut ou un ro le peut de river d’autres attributs ou ro les. Repre sente une relation de de pendance entre une spe cification (cible) et l’e le ment qui imple mente cette spe cification (source) « trace » • Repre sente l’historique des constructions pre sentes dans les diffe rents mode les.

Diagramme de classes • Les paramètres possible: • Liaison • • «lie» Permission • «ami» • • Repre sente un e le ment source (paquetage, classe, ope ration. . . ) qui a acce s a l’e le ment destination (paquetage, classe, ope ration. . . ) quelle que soit la spe cification de visibilite de ce dernier. Utilisation • « utilise » || « «appelle» » • • Repre sente une relation de de pendance entre une ope ration qui invoque une ope ration d’une autre classe. Cette relation est repre sente e en connectant les ope rations ou les classes qui posse dent ces ope rations. «cre e» • Repre sente le classificateur source qui cre e une instance du classificateur cible

Diagramme de classes • L’interface • Une interface de finit le comportement visible d’une classe. • Ce comportement est de fini par une liste d’ope rations ayant une visibilite « public » . • Aucun attribut ou association n’est de fini pour une interface. • Une interface est en fait une classe particulie re (avec le ste re otype « « interface » » ). • UML repre sente les interfaces : • soit au moyen de petits cercles relie s par un trait a l’e le ment qui fournit les services de crits par l’interface • soit au moyen de classes avec le mot cle « « interface » » . Cette notation permet de faire figurer dans le compartiment des ope rations la liste des services de l’interface.

Diagramme de classes • L’interface • Les relations possibles sur une interface sont : • la fourniture • Cette relation spe cifie qu’une classe donne e fournit l’interface a ses clients : c’est-a -dire que la classe posse de cette interface. • Une classe peut fournir plusieurs interfaces a ses clients et chaque interface de finit un des services de la classe. Cette technique permet de re duire la visibilite d’une classe. • En effet, une classe qui expose ses ope rations publiques les expose a toutes les autres classes du mode le. Le concept d’interface permet a une classe de de finir plusieurs profils en permettant a chaque classe de n’utiliser que le profil qui l’inte resse. Une classe peut ainsi e tre vue avec plusieurs perspectives diffe rentes en fonction de la classe qui l’utilise, ce qui augmente la re utilisabilite.

Diagramme de classes • L’interface • Les relations possibles sur une interface sont : • l’utilisation • • Cette relation concerne toute classe client qui souhaite acce der a la classe interface de manie re a acce der a ses ope rations. C’est une relation d’utilisation standard. la re alisation • Cette relation n’est utilise e que pour les interfaces. • Une re alisation est une relation entre une classe et une interface. Elle montre que la classe re alise les ope rations offertes par l’interface. • L’exemple illustre la mode lisation de 2 interfaces cre dit et assurance d’une classe banque. Une relation de re alisation indique la classe banque re alise l’interface assurance.

Diagramme de classes • E laboration d’un diagramme de classes • Un diagramme de classes fait abstraction des aspects dynamiques et temporels. • Pour un mode le complexe, plusieurs diagrammes de classes comple mentaires doivent e tre construits. • On peut par exemple se focaliser sur : • • les classes qui participent a un cas d'utilisation (cf. collaboration), • les classes associe es dans la re alisation d'un sce nario pre cis, • les classes qui composent un paquetage, • la structure hie rarchique d'un ensemble de classes. Pour repre senter un contexte pre cis, un diagramme de classes peut e tre instancie en diagrammes d’objets.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes d’objets • Le diagramme d’objets permet de mettre en e vidence des liens entre les objets. Les objets, instances de classes, sont relie s par des liens, instances d’associations. • A l’exception de la multiplicite , qui est explicitement indique e, le diagramme d’objets utilise les me mes concepts que le diagramme de classes. • Ils sont essentiellement utilise s pour comprendre ou illustrer des parties complexes d’un diagramme de classes.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes de composants • Les diagrammes de composants de crivent les composants et leurs de pendances dans l’environnement de re alisation. • En ge ne ral, ils ne sont utilise s que pour des syste mes complexes. • Un composant est une vue physique qui repre sente une partie imple mentable d’un syste me. • Un composant peut e tre du code, un script, un fichier de commandes, un fichier de donne es, une table … • Il peut re aliser un ensemble d’interfaces qui de finissent alors le comportement offert a d’autres composants.

Diagrammes de composants • • UML de finit 5 ste re otypes aux composants : • « « document » » : un document quelconque • « « exe cutable » » : un programme qui peut s’exe cuter • « « fichier » » : un document contenant un code source ou des donne es • « « bibliothe que » » : une bibliothe que statique ou dynamique • « « table » » : une table de base de donne es relationnelle Pour montrer les instances des composants, un diagramme de de ploiement peut e tre utilise.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes de de ploiement • Les diagrammes de de ploiement montrent la disposition physique des diffe rents mate riels (les nœuds) qui entrent dans la composition d’un syste me et la re partition des instances de composants, processus et objets qui « vivent » sur ces mate riels. • Les diagrammes de de ploiement sont donc tre s utiles pour mode liser l’architecture physique d’un syste me.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes de collaboration • Le diagramme de collaboration permet de mettre en e vidence les interactions entre les diffe rents objets du syste me. • Dans le cadre de l’analyse, il sera utilise : • • pour pre ciser le contexte dans lequel chaque objet e volue • pour mettre en e vidence les de pendances entre les diffe rents objets implique s dans l’exe cution d’un processus ou d’un cas d’utilisation. Un diagramme de collaboration fait apparai tre les interactions entre des objets et les messages qu’ils e changent.

Diagrammes de collaboration • Une interaction de finit la communication entre les objets sous la forme d’un ensemble partiellement ordonne de messages. • L’objet e metteur envoie un message a l’objet re cepteur. • Les objets repre sente s dans les diagrammes de collaboration ne sont pas ne cessairement des instances d’entite s • Certains messages peuvent avoir pour origine des acteurs que l’on pourra repre senter. • Formalisme : l’interaction se repre sente par une fle che avec un texte de crivant le message.

Diagrammes de collaboration • Les messages sont le seul moyen de communication entre les objets. • Ils sont de crits essentiellement par l’objet e metteur et l’objet re cepteur • Leur description peut e tre comple te e par un nom, une se quence, des arguments, un re sultat attendu, une synchronisation, une condition d’e mission. • La se quence permet de pre ciser l’ordre d’e mission des messages.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes de se quence • Le diagramme de se quence est une variante du diagramme de collaboration. • Par opposition aux diagrammes de collaboration, les diagrammes de se quence posse dent intrinse quement une dimension temporelle mais ne repre sente pas explicitement les liens entre les objets. • Ils privile gient ainsi la repre sentation temporelle a la repre sentation spatiale et sont plus aptes a mode liser les aspects dynamiques du syste me.

Diagrammes de se quence • Le diagramme de se quence permet de visualiser les messages par une lecture de haut en bas. L’axe vertical repre sente le temps, l’axe horizontal les objets qui collaborent. • Une ligne verticale en pointille est attache e a chaque objet et repre sente sa dure e de vie. • Les messages sont repre sente s comme dans le diagramme de collaboration. (NB : un message de retour sera repre sente avec des traits en pointille s)

Diagrammes de se quence • Les interactions • • L’interaction se traduit par l’envoi d’un message entre objets. Le diagramme de se quence insiste sur la chronologie des objets en utilisant la ligne de vie des objets. Les activations • Les diagrammes de se quence permettent de repre senter les pe riodes d’activite des objets. • Une pe riode d’activite correspond au temps pendant lequel un objet effectue une action, soit directement, soit par l’interme diaire d’un autre objet qui lui sert de sous-traitant. • Formalisme : les pe riodes d’activite se repre sentent par des bandes rectangulaires place es sur la ligne de vie des objets.

Diagrammes de se quence • Les diagrammes de se quence distinguent 3 cate gories d’envois de message : • flot de contro le a plat • appel de proce dure (ou flot de contro le emboi te ) • Retour de proce dure

Diagrammes de se quence • Les diagrammes de se quence distinguent 3 cate gories d’envois de message : • flot de contro le a plat • appel de proce dure (ou flot de contro le emboi te ) • Retour de proce dure

Diagrammes de se quence • flot de contro le a plat • Cette cate gorie d’envois est utilise e pour indiquer le progression vers la prochaine e tape d’une se quence. • Formalisme : une fle che simple symbolise de tels messages. • Alternativement, une demi-fle che peut e tre utilise e pour repre senter explicitement des messages asynchrones pour des syste mes concurrents (la fle che pleine correspond alors a un message avec attente de prise en compte).

Diagrammes de se quence • appel de proce dure (ou flot de contro le emboi te ) • Dans un contro le emboi te , la se quence emboi te e doit se terminer pour que la se quence englobante reprenne le contro le. • Un objet poursuit donc son exe cution une fois le comportement initie par le message termine. • Formalisme : Des fle ches a extre mite s pleines symbolisent de tels messages. • L’objet 1 re cupe re le contro le quand l’objet 2 a fini sa ta che.

Diagrammes de se quence • Retour de proce dure • Le retour de proce dure est implicite a la fin d’une activation. • Ne anmoins, en cas d’envois de messages asynchrones, il s’ave re utile pour montrer la fin de l’exe cution d’une sous- proce dure et le renvoi e ventuel de parame tres.

Diagrammes de se quence • Les messages re flexifs • Un objet peut s’envoyer un message. • Formalisme : Cette situation se repre sente par une fle che qui revient en boucle sur la ligne de vie de l’objet.

Diagrammes de se quence • Les contraintes temporelles • Une fle che qui symbolise un message peut e tre repre sente e en oblique pour mate rialiser les de lais de transmission ne gligeables par rapport a la dynamique ge ne rale de l’application. • Des annotations temporelles concernent les messages peuvent e galement e tre ajoute es.

Diagrammes de se quence • La ligne de vie des objets est repre sente e par une ligne verticale en traits pointille s, place e sous le symbole de l’objet concerne. Cette ligne de vie pre cise l’existence de l’objet concerne durant un certain laps de temps. • En ge ne ral, une ligne de vie est repre sente e sur toute la hauteur du diagramme de se quence. Par contre, elle peut de buter et s’interrompre a l’inte rieur du diagramme. • Formalisme : la cre ation se repre sente en faisant pointer le message de cre ation sur le rectangle qui symbolise l’objet cre e. • La destruction est indique e par la fin de la ligne de vie et par une croix (X), soit a la hauteur du message qui cause la destruction, soit apre s le dernier message envoye par un objet qui se suicide.

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes d'e tats-transitions • Ils ont pour ro le de repre senter les traitements (ope rations) qui vont ge rer le domaine e tudie. Ils de finissent l'enchai nement des e tats de classe et font donc apparai tre l'ordonnancement des travaux. • Le diagramme d'e tats-transition est associe a une classe pour laquelle on ge re diffe rents e tats : il permet de repre senter tous les e tats possibles ainsi que les e ve nements qui provoquent les changements d’e tat.

Diagrammes d'e tats-transitions • La transition peut e tre soumise a la ve rification d'une expression appele e "expression de garde »

Diagrammes d'e tats-transitions • Les traitements • Les ope rations de description des classes sont de crites dans le diagramme d’e tatstransitions sous forme d'actions et d’activite s. • Une action est une ope ration e le mentaire et instantane e. Elle peut e tre associe e a l'e ve nement lui-me me ou a l'entre e dans l'e tat ou a la sortie de l’e tat • Une activite est une ope ration qui dure et qui est donc associe e a un e tat. Elle peut e tre se quentielle ou cyclique : • La fin d'une activite se quentielle correspond a la sortie de l'e tat : une transition automatique est ge ne re e. • une activite cyclique ne se termine que par une transition de sortie identifie e

Diagrammes d'e tats-transitions

Diagrammes d'e tats-transitions • Les e tats pre de finis • Deux e tats sont pre de finis : • l'e tat initial d'un objet : il est obligatoire et unique • l'e tat final : selon les e ve nements, il peut exister plusieurs e tats finaux

D - Les Diffe rents types de diagrammes • • Vues statiques • Diagrammes de cas d’utilisation • Diagramme de classes • Diagrammes d’objets • Diagrammes de composants • Diagrammes de de ploiement Vues dynamiques • diagrammes de collaboration • diagrammes de se quence • diagrammes d'e tats-transitions • diagrammes d'activite s

Diagrammes d'activite s • Le diagramme d'activite est attache a une cate gorie de classe et de crit le de roulement des activite s de cette cate gorie. • Le de roulement s'appelle "flot de contro le » . • Il indique la part prise par chaque objet dans l'exe cution d'un travail. Il sera enrichi par les conditions de se quencement. • Il pourra comporter des synchronisations pour repre senter les de roulements paralle les. • La notion de couloir d'activite va de crire les responsabilite s en re partissant les activite s entre les diffe rents acteurs ope rationnels.

Plan • A - Découverte • B - Approche fonctionnelle vs approche objet • C - De marche ge ne rale de mode lisation • D - Les Diffe rents types de diagrammes • E - Conclusion

Conclusion • UML est une norme • UML est un langage de mode lisation objet • UML est un support de communication • UML est un cadre me thodologique • UML est incontournable pour du développement objet complexe

Merci. Avez-vous des questions?