Formation UML. Page N° 2 Introduction Processus de développement Concepts objets UML et les activités de modélisation Lapproche MDA.

Présentation au sujet: "Formation UML. Page N° 2 Introduction Processus de développement Concepts objets UML et les activités de modélisation Lapproche MDA."— Transcription de la présentation:

1 Formation UML

2 Page N° 2 Introduction Processus de développement Concepts objets UML et les activités de modélisation Lapproche MDA

3 Page N° 3 Les systèmes développés sont de plus en plus importants et complexes Il importe davoir des systèmes et des composants : – mieux adaptés aux besoins des utilisateurs – aux coûts de développement et de maintenance moins élevés Objectifs dune méthodologie de développement objet

4 Page N° 4 Langages de programmation objet : SIMULA67, SMALLTALK (1972),... Modèle Entité-Association Réseaux sémantiques Méthodes structurées (SADT/SART, Merise,...) Un grand nombre de méthodes orientées objet (OOSE, OBA, BOOCH, OMT, OOA, Martin-Odell, Classe-Relation, FUSION,...) UML (Unified Modeling Language), normalisé par l'OMG en Novembre 1997, actuellement dans la version 2.0 UML doit être vu comme une fusion et une évolution de formalismes antérieurs. Origines de lobjet et dUML

5 Page N° 5 Quoffre une méthodologie ? Un processus qui : Un langage pour créer, communiquer et réutiliser les produits de chaque activité de ce processus, Une somme de modèles et de connaissances réutilisables. – fournit un guide pour les activités de développement, la gestion des risques, – spécifie quels artefacts doivent être considérés, – offre des critères pour évaluer les activités et les produits des projets.

6 Page N° 6 Introduction Processus de développement Concepts objets UML et les activités de modélisation Lapproche MDA

7 Page N° 7 Le processus de développement objet Ce processus est : –basé sur la réalisation de modèles (Model Driven), –dirigé par les besoins (Cas dutilisation), –centré sur l architecture, –récursif, –itératif et incrémental, … Des enjeux majeurs sont : –la traçabilité entre les différents modèles –la validation et la réutilisabilité des modèles à différents niveaux dabstraction, –lautomatisation de certaines tâches de conception

8 Page N° 8 Quest-ce quun modèle ? Un modèle est une représentation abstraite dun système plus facile à appréhender que la « réalité ». Trois principes dabstraction sont particulièrement utilisés pour modéliser un système : –projection de ses caractéristiques suivant différents points de vue (états, fonctions, …), –restriction du niveau de détails La structure dun système est arborescente, et cette structure est invariante quel que soit le point de vue sur ce système.

9 Page N° 9 Phases de développement Avec une approche objet, un système est développé suivant une démarche progressive, allant des besoins à la réalisation. Cependant, il est impératif de respecter différentes phases : –fournissant chacune une référence pour les différentes personnes participant au projet (technique, logistique, qualité, …) –permettant de découvrir les erreurs le plus tôt possible, –dont les produits sont essentiels pour la maintenabilité et la réutilisabilité. Cette décomposition en phases nimplique pas de rupture dans le processus de développement.

10 Page N° 10 Modèle de réalisation Modèle dexigences Modèle de conception 1 2 Analyse 3 Consolidation des exigences 4 Conception 5 Réalisation 6 Tests Modèle danalyse Capture des exigences Modèle de tests Modèle de déploiement Processus basé sur la réalisation de modèles

11 Page N° 11 Modèles produits par le processus Les modèles produits par les différentes activités du processus sont au minimum : –Le modèle dexigences (besoins) –Le modèle danalyse qui a deux propos : affiner et consolider les Cas dutilisation allouer le comportement du système à un ensemble de composants logiques –Le modèle de conception qui précise larchitecture du système avec ses sous-systèmes et composants physiques, leur contenu, leurs dépendances et leurs interfaces –Le modèle de tests

12 Page N° 12 Processus dirigé par les besoins Les besoins fonctionnels sont décrits sous forme de « Cas dutilisation ». Un Cas dutilisation : –est une capacité globale dun système (ou dun constituant) vu comme un tout, –est décrit comme une séquence dinteractions entre le système et ses acteurs –sert aussi de point dancrage pour décrire des exigences non- fonctionnelles. Un processus dirigé par les besoins suit un flot dactivités : les Cas dutilisation sont spécifiés, puis analysés et à la fin du processus les Cas dutilisation forment la source à partir de laquelle les tests de validation sont construits.

13 Page N° 13 Types dexigences Cas dutilisation Système à développer Architecture Performances Ergonomie Disponibilité Existant Couts/délais Maintenabilité Sécurité daccès Fiabilité Les exigences peuvent être utilisées comme métrique pour la conduite de projet

14 Page N° 14 Processus récursif Le processus de développement est appliqué récursivement à différents niveaux : –système, –sous-systèmes, –composants,…

15 Page N° 15 Processus itératif et incrémental Consiste à diviser le projet en plus petits projets. Chaque sous-projet est une itération qui produit un incrément. Les iterations contrôlées réduisent les risques liés à la durée de développement : – évolution des besoins, – mutations technologiques, – changements au sein des équipes de développement,... Chaque itération ne prend en compte quun certain nombre de Cas dutilisation Les contraintes darchitecture sont prises en compte dès la première itération.

16 Page N° 16 Production de composants Le processus de développement par objets vise dans toutes ses activités à identifier, construire et réutiliser des composants couplés par des interfaces bien définies et réutilisables. La réutilisabilité dun composant ne se construit pas à coût nul.

17 Page N° 17 Introduction Processus de développement objet Concepts objets UML et les activités de modélisation Lapproche MDA

18 Page N° 18 Quest-ce quun objet ? Est objet tout ce qui peut être perçu, nommé, manipulé, … Un objet se définit par : –son existence, –sa structure, –ses états, –son comportement.

19 Page N° 19 Existence dun objet Lexistence dun objet est ce qui permet aux autres objets dy faire référence pour obtenir sa collaboration. Cette existence peut être identifiée par un ou différents noms propres. Différents objets peuvent avoir le même nom. Lexistence dun objet est ce qui lui est propre, ce qui le distingue de tout autre objet.

20 Page N° 20 Structure dun objet Un objet non primitif est une structure faite dautres objets (ses composants).

21 Page N° 21 Etats dun objet Un état dun objet définit sa manière dêtre par rapport à dautres objets dans une situation donnée. Lidentification dun état dun objet nécessite la donnée dun référentiel (type, gamme de valeurs, …).

22 Page N° 22 Evénements Un événement est lavènement dune information. Un objet peut réagir aux événements quil perçoit dans son environnement. Les objets qui perçoivent un événement ne sont pas forcément connus de lémetteur.

23 Page N° 23 Invocation d'objets Les objets peuvent interagir explicitement en senvoyant des messages, suivant un protocole déterminé. Les invocations d'objets diffèrent des appels procéduraux car : –elles fournissent toujours une référence à l'objet auquel le message est envoyé –la réaction de lobjet destinataire dépend de celui-ci et de son état

24 Page N° 24 Comportement Le comportement dun objet est défini par les actions quil entreprend dès sa création ou suite à la perception dun événement ou la réception dun message. Le comportement dun objet peut entraîner la création ou la destruction dautres objets ou des changements détats. Un objet est dit « actif » lorsquil entreprend et contrôle des actions dès sa création et/ou à partir dévénements quil perçoit dans son environnement (et non pas seulement sur réception de messages dautres objets)

25 Page N° 25 Concurrence Différents objets peuvent exécuter leur comportement en parallèle. Si ces objets se partagent une même ressource, ils sont dits « concurrents » : un objet peut être bloqué jusquà ce quun autre objet ait terminé son activité. Différents types de synchronisation permettent de décrire les modalités dinteraction des objets. La notion de concurrence peut sappliquer aux activités parallèles dun même objet.

26 Page N° 26 Encapsulation L'encapsulation consiste à séparer les aspects externes d'un objet, accessibles par les autres objets, des détails de son organisation interne, rendus invisibles aux autres objets. L'interface d'un objet est constituée des opérations que les autres objets peuvent lui demander d'exécuter (par envoi d un message). L interface d un objet peut être modélisée comme un objet.

27 Page N° 27 Classes et objets Ne pas confondre cette notion avec celle de classe déquivalence, qui rassemble des objets existants. Toutes les instances dune classe ont la même structure, les mêmes états possibles et le même comportement, mais leur état et leur activité courants peuvent être différents. Dans une approche objet, une classe est un plan, un moule, un générateur dobjets : la création d'un objet se fait conformément à sa classe (on parle d « instanciation » de sa classe).

28 Page N° 28 Métaclasses Une classe peut être vue comme un objet. En tant qu'objet, une classe est instance de sa classe, qui est appelée métaclasse. Elle possède donc la structure, les états et le comportement définis dans sa métaclasse. Une métaclasse est donc une classe de classe. Le but premier d'une métaclasse est de définir les propriétés d'une classe en tant que générateur d'instances (e.g. type ou classe et valeur par défaut des attributs, méthodes de création et dinitialisation des instances,...).

29 Page N° 29 Spécialisation et généralisation La spécialisation permet de définir une classe à partir d'une classe existante (une superclasse) en lui ajoutant des propriétés ou en spécialisant ses propriétés. Par exemple, la spécialisation d'une classe peut se faire : –par enrichissement de sa structure (ajout d'un composant, ajout d'un composant à un composant, ou encore dune propriété), –par restriction des états possibles dune propriété, –par spécialisation des opérations, … La généralisation est la relation inverse de la spécialisation.

30 Page N° 30 Polymorphisme On parle de polymorphisme lorsque la même opération est réalisée (implémentée) sous différentes formes (méthodes) dans différentes classes. Le mécanisme dhéritage des langages informatiques utilise le polymorphisme.

31 Page N° 31 Mécanisme dhéritage Le mécanisme dhéritage suppose que lopération à appliquer par un objet à la réception dun message soit déterminée seulement au moment de lexécution (liaison dynamique). Si lopération est définie dans la classe de lobjet, elle est exécutée, sinon les superclasses sont examinées en remontant le graphe de spécialisation jusquà ce que lopération soit trouvée. Ainsi, une opération définie dans une classe est héritée par ses sous-classes si seulement celle-ci na pas été spécialisée dans ses sous-classes.

32 Page N° 32 La notion de "type" est généralement utilisée pour désigner l'ensemble des états (valeurs) possibles d'une propriété d'un objet. En ce sens, un type est toujours défini en extension. Un stéréotype permet de classer les classes suivant un critère donné. A un stéréotype correspond souvent une structure arborescente de classes (e.g. stéréotype Collection) Les stéréotypes « Entité », « Frontière » et « Contrôleur » sont particulièrement importants en méthodologie objet. Types et stéréotypes

33 Page N° 33 Introduction Processus de développement objet Concepts objets UML et les activités de modélisation Lapproche MDA

34 Page N° 34 UML - Unified Modeling Language UML offre différents formalismes pour spécifier, analyser et concevoir une solution qui satisfasse les exigences dun système. Pour cela, UML définit différents types de diagrammes divisés en deux catégories : –Diagrammes structuraux, incluant le diagramme de classes, le diagramme de composants et le diagramme de déploiement, –Diagrammes comportementaux incluant le diagramme de Cas dutilisation, le diagramme de séquences, le diagramme dactivités, le diagramme détats et le diagramme de collaboration.

35 Page N° 35 Les quatre niveaux de modélisation

36 Page N° 36 Profils UML Un profil UML est une variante d UML qui utilise le mécanisme d extension d UML pour un besoin particulier. Les profils peuvent contenir des stéréotypes, des définitions de tags et des contraintes. En principe, les profils servent seulement à affiner la sémantique dUML par ajout de contraintes et dinterprétations qui correspondent à un domaine spécifique. Ils najoutent pas de nouveaux concepts fondamentaux.

37 Page N° 37 Exemple de profil : EDOC EDOC (Enterprise Distributed Object Computing) est un profil UML : –destiné à la modélisation de systèmes informatiques répartis à base de composants, –basé sur UML et MDA (Model Driven Architecture), –implémentable sur différentes plates formes (CORBA, J2EE,.NET, …).

38 Page N° 38 Introduction Processus de développement Concepts objets UML et les activités de modélisation Modélisation des exigences avec UML Lapproche MDA

39 Page N° 39 Le développement d'un composant commence par la capture et la description des exigences (fonctionnelles et non fonctionnelles), en relation étroite avec le client. Ne sont retenues que les exigences vérifiables. Les exigences fonctionnelles sont décrites dans les « Cas d'utilisation ». Il peut être utile de prototyper certaines parties du système et linterface utilisateur (mais éviter de faire des choix prématurés de conception).. Comprendre le besoin opérationnel

40 Page N° 40 Cas dutilisation Les Cas dutilisation permettent de capturer les exigences fonctionnelles en se focalisant particulièrement sur les acteurs et les rôles du système. Les exigences non-fonctionnelles spécifiques dun seul Cas dutilisation sont traitées avec celui-ci. Noter que les Cas dutilisation ne sont pas de simples processus algorithmiques : ils définissent également leur contexte dexécution.

41 Page N° 41 Artefacts des Cas d'utilisation Un cas dutilisation spécifie une séquence (ou plusieurs séquences parallèles) dinteractions entre un système (vu comme un tout) et ses acteurs. Un Cas dutilisation inclut un cas nominal et différentes variantes ou exceptions que le système peut traiter et qui fournissent un résultat observable. Les Cas dutilisation qui sont fortement couplés peuvent être organisés en « packages ».

42 Page N° 42 Rôles et acteurs Un rôle se définit comme le comportement dun acteur (qui peut être un opérateur, un sous-système, un composant, …) par rapport à dautres acteurs. Un acteur se définit par lensemble de ses rôles dans un système. Les acteurs sources dévénements sont dits « principaux », les autres étant dits « secondaires » Un cas d'utilisation est initialisé par un et un seul acteur principal, mais peut impliquer plusieurs autres acteurs (principaux ou secondaires).

43 Page N° 43 Un Cas d utilisation comporte un chemin nominal, avec éventuellement des variantes, des inclusions et des extensions. Un cas d'utilisation peut comporter des choix et des itérations; il peut en spécialiser un autre. Un Cas dutilisation décrit aussi les exigences non- fonctionnelles, qui peuvent être attachées à celui-ci. Un glossaire doit définir les principaux termes utilisés. Description des Cas d'utilisation

44 Page N° 44 Modèle de Cas dutilisation Identifiant Objectif Priorité Acteurs principaux Acteurs secondaires Pré-conditions Profil dactivation Description (séquences dinteractions consécutives à lévénement initial) Exigences non-fonctionnelles applicables au cas nominal (contraintes factuelles, QoS) Variante n Exigences non-fonctionnelles applicables à la variante n

45 Page N° 45 Diagramme de Cas dutilisation Présente les acteurs, les Cas dutilisation, leurs liens (dépendance, généralisation) et les regroupe éventuellement en packages. Notation : A1 A2 UC3 UC2 UC1 A3

46 Page N° 46 Relations entre Cas dutilisation Cas dutilisation 1 Cas dutilisation 3 Cas dutilisation 4 Cas dutilisation 2 «extends» «includes» Extension Point : X Le Cas dutilisation 3 étend le Cas dutilisation 1 Généralisation Le Cas dutilisation 2 spécialise le Cas dutilisation 1. Comme lui, il inclut le Cas dutilisation 4 et peut être étendu par le Cas dutilisation 3 Le Cas dutilisation 1 inclut le Cas dutilisation 4

47 Page N° 47 Un scénario est une instance de cas d'utilisation. Les scénarios sont utiles pour illustrer mais aussi pour découvrir (par induction) les Cas dutilisation. Scénario

48 Page N° 48 Points clés de la modélisation des exigences Trouver les Cas dutilisation, les rôles et les acteurs à partir de lexpression de besoins initiale du client et des autres parties prenantes. Ordonner les Cas dutilisation en fonction de leur priorité. Bien identifier les exigences et assurer leur traçabilité avec lexpression de besoins initiale du client. Associer aux Cas dutilisation les exigences non-fonctionnelles qui sy rapportent. Les Cas dutilisation sont si possible répartis en ensembles (packages) faiblement couplés qui correspondent à larchitecture logique du système.

49 Page N° 49 Introduction Processus de développement Concepts objets UML et les activités de modélisation Analyse avec UML Lapproche MDA

50 Page N° 50 Lobjectif de l analyse est double : affiner et consolider des Cas d utilisation, modéliser les objets collaborant pour réaliser ces Cas dutilisation. Le modèle d'analyse est une description logique précise du composant en termes d'objets. Le modèle d'analyse prend en compte les différents aspects d'un objet : structural et comportemental. Analyse des exigences fonctionnelles

51 Page N° 51 Stéréotypes de classes utilisés en analyse Différents stéréotypes sont utilisés pour construire le modèle structural (diagrammes de classes). En particulier : « Entité »« Contrôle »« Frontière » Une erreur souvent commise au début de l'analyse est de détailler trop tôt les objets entités, alors que les objets frontières et les contrôleurs n'ont pas encore été identifiés.

52 Page N° 52 Un contrôleur est un objet responsable dun ou plusieurs cas d'utilisation. Pour un contrôleur, laspect comportemental est généralement prépondérant par rapport à laspect structural. Le comportement dun contrôleur est essentiellement « actif ». Contrôleurs

53 Page N° 53 Un objet frontière est responsable des interactions entre le système et un ou plusieurs de ses acteurs. Un objet frontière représente des rôles dun acteur. Un objet frontière définit un protocole déchange dévénements; il peut mémoriser de linformation. Frontières

54 Page N° 54 Les objets entités correspondent aux informations échangées entre acteurs ou créées/détruites pendant l'exécution des cas d'utilisation. Ils ont un sens pour les experts du domaine et possèdent souvent des noms spécifiquement utilisés dans ce domaine (e.g. piste = avion pour les radaristes). Entités

55 Page N° 55 Entités (2) Pour les objets entités laspect structural est souvent prépondérant par rapport à laspect comportemental. Ils correspondent à des informations qu'il convient généralement de mémoriser et d'historiser. Une objet entité peut avoir un comportement complexe, mais contrairement à un objet de contrôle, il ne pose pas de question aux objets frontières...

56 Page N° 56 Paquetages Un paquetage est un regroupement déléments. Tous les éléments distingués dans UML peuvent être regroupés en paquetages. Les paquetages possèdent leurs éléments et constituent des espaces de nommage. Ils sont à la base de la gestion de configuration. Un paquetage nest pas instanciable. Un paquetage peut dépendre dun autre paquetage. Les types de dépendances sont > ou >.

57 Page N° 57 Paquetages Package_2 Package_4 Package_7 Package_5 Package_6 Classe_2Classe_1 Classe_1a Package_1 Package_6 > Les éléments dun paquetage sont visibles dans ses sous-paquetages

58 Page N° 58 Colla borati on Une collaboration est un regroupement de classes qui participent à la réalisation dun Cas dutilisation. Contrairement aux paquetages et aux sous-systèmes, une collaboration définit un usage de ses éléments mais ne les possède pas. UC Collaboration réalisation

59 Page N° 59 La construction du modèle objet d'un système se fait à l'aide de deux points de vue complémentaires et interdépendants : – structural, décrivant les classes, leurs relations statiques, leurs attributs et leurs opérations. – comportemental, décrivant le comportement des objets. Il est recommandé d'étudier les deux points de vue dans cet ordre, mais la construction dun modèle objet se fait toujours de manière itérative. A la fin de lanalyse, toutes les exigences des Cas dutilisation doivent avoir été allouées aux classes. Activité danalyse

60 Page N° 60 Introduction Processus de développement Concepts objets UML et les activités de modélisation Analyse : concepts structuraux Lapproche MDA

61 Page N° 61 Diagrammes de classes Nom de classe attribut1 attribut:type or classe attribut:type or classe=i_valeur « stéréotype » Nom de classe attribut1 attribut2:type or class attribut3:type or class=i_valeur operation() operation(arg_list): résultat

62 Page N° 62 Attributs Les attributs d'un objet sont définis dans sa classe, mais la valeur d'un attribut est propre à chaque instance. Un attribut peut être : –une valeur (valeur d'un poids, d'une température, d'une vitesse,...) qui s'exprime en fonction d'un référentiel donné (type), –ou une référence à un autre objet. Notation: Nom de classe attribut1 : type ou classe = val.défaut attribut2 : type ou classe = val.défaut

63 Page N° 63 Opérations Tous les objets d'une classe donnée partagent les mêmes opérations. Notation: Nom de classe opération1 (param1 : type ou classe = val. défaut,...) : type ou classe opération2 (param1 : type ou classe = val. défaut,...) : type ou classe

64 Page N° 64 Associations Une association est une relation statique entre classes Notation graphique : Une association peut avoir un ou deux noms avec une petite flèche spécifiant le sens de lecture. Deux classes peuvent être connectées par plusieurs associations. Class 1Class 2 Association name

65 Page N° 65 Rôles Chaque extrémité d'une association est un rôle. Un rôle peut avoir un nom précisant comment la classe à laquelle il est attaché est vue par l'autre classe (manière d'être). Les noms de rôles attachés à une même classe doivent être uniques. Classe 1Classe 2 Rôle

66 Page N° 66 Cardinalité d'un rôle dune association La cardinalité d'un rôle dune association exprime combien d'instances d'une classe peuvent être liées à une seule instance d'une autre classe. (Cette notion est suffisante pour représenter les collections en analyse) Notation: Exactement 1 3..53 à 5 2,42 ou 4 Plusieurs (0 ou plus) Optionnel (0 ou 1) Un ou plus Cardinalité spécifiée 1..* * 0..1 n 1

67 Page N° 67 Classes associations Il peut être utile de préciser la classe d'une association lorsque celle-ci : – possède des attributs et/ou des opérations – participe à d'autres associations Classe 1Classe 2 Attributs Opérations

68 Page N° 68 Association qualifiée Le qualificatif est une variante d'attribut d'association qui permet d'identifier un objet (ou un ensemble d'objets) à atteindre au sein des instances d'une classe. Notation: Classe A Classe B Qualificatif

69 Page N° 69 Agrégation Forme particulière d'association ayant la sémantique de la relation « composé de ». Notation: Les constituants d'un agrégat peuvent être des objets concurrents. Toutes les relations entre les parties dun agrégat appartiennent à cet agrégat. Agrégat Partie * *

70 Page N° 70 Composite La composition est une forme d aggrégation où aucun constituant (partie) ne peut appartenir simulta-nément à un autre composite (mais la classe du constituant peut faire partie de la description d un autre composite). Notations : Composite Partie Composite n rôle : Partie rôle n

71 Page N° 71 Contraintes Une contrainte spécifie une condition qui doit être satisfaite pour que le modèle soit bien formé. Les contraintes peuvent être écrites en langage naturel ou dans le langage OCL (Object Constraint Language) dUML. OCL peut être utilisé pour : –spécifier des invariants sur les classes les types ou les stéréotypes –décrire des pré et post conditions sur les opérations –pour décrire des gardes (conditions booléennes) –parcourir les associations, –...

72 Page N° 72 Spécialisation et généralisation Les instances dune sous-classe peuvent être utilisées partout où une superclasse apparaît. Une sous-classe hérite des propriétés de sa (ses) superclasse(s). Superclass2 Attributes Operations Superclass 1 Subclass 1Subclass 2 Multiple inheritance discriminator

73 Page N° 73 Classes abstraites Classes qui ne sont pas destinées à être explicitement instanciées. Factorisent les propriétés pour leurs sous-classes. Une opération peut aussi être spécifiée comme abstraite si elle doit être spécialisée par une sous- classe. Une classe contenant une opération abstraite est elle-même abstraite. Notation: {abstract}.

74 Page N° 74 Classes paramétrées Les classes paramétrées (aussi appelées templates, patrons, classes génériques, widgets, …) sont des classes abstraites qui permettent de générer des classes par spécialisation de une ou plusieurs de leurs propriétés. Les propriétés spécialisées (paramètres) peuvent représenter des types, des classes, des noms, des nombres, des méthodes, … Exemple : Array C, n

75 Page N° 75 Introduction Processus de développement Concepts objets UML et les activités de modélisation Analyse : concepts comportementaux Lapproche MDA

76 Page N° 76 Modèle comportemental Les objets ayant un comportement simple exécutent des opérations à la demande sans garder mémoire des services précédents. Les objets dont le comportement est dirigé par les états gardent mémoire des services précédents et peuvent assurer seulement un nombre fini de manières d être appelées « états ». UML est un langage de modélisation « discret » et ne permet pas de représenter directement le comportement continu dun système.

77 Page N° 77 Diagrammes comportementaux Ces types de diagrammes permettent de modéliser la dynamique interne et les interactions des objets en termes d'états, d'événements et de messages. Un diagramme d'états sert à modéliser le comportement interne d'un objet, correspondant à un cas d'utilisation. Un diagramme de séquences d'événements et un diagramme de collaboration qui sert à illustrer les interactions dobjets durant l'exécution de scénarios. Un diagramme dactivités est un cas particulier de diagramme détats qui sert à modéliser les interactions entre les acteurs, objets ou composants.

78 Page N° 78 Diagrammes d'états Un diagramme d'états est un automate faisant intervenir des états, des événements, des transitions, des activités,... Un diagramme détats se focalise sur laspect événementiel du comportement des objets, ce qui est particulièrement utile pour modéliser les systèmes réactifs. Chaque diagramme décrit l'évolution d'un objet d'une classe donnée, depuis sa création jusqu'à sa destruction, c'est-à-dire les différentes manières dont un objet réagit en fonction des événements extérieurs. Les diagrammes détats permettent une représentation graphique des Cas dutilisation.

79 Page N° 79 Etats et transitions Chaque état d'un objet représente une manière d'être qui conditionne sa réaction à des événements quil perçoit. Une transition est la réponse d'un objet à un événement extérieur lorsquil est dans un certain état. Notation: Si la transition mène à un nouvel état elle est externe, sinon elle est soit interne soit propre. Etat 1 Etat 2 nom d'événement (paramètres) Un état est responsable de ses transitions sortantes.

80 Page N° 80 Transition propre Transition qui mène au même état.

81 Page N° 81 Transition gardée Transition dont l'exécution est subordonnée non seulement à l'occurrence d'un événement précis, mais aussi à une condition appelée garde. Une garde est une expression booléenne formée à partir de paramètres de l'événement et d'attributs de l'objet. Notation: Etat 1Etat 2 nom d'événement (paramètres) [condition]

82 Page N° 82 Actions Une action est une opération (interne à l'objet ou l'un de ses constituants) déclenchée par une transition. Les actions ne sont pas interruptibles. Elles sont considérées comme instantanées car leur temps dexécution – qui peut être long - nest pas significatif pour le comportement de lobjet modélisé. Notation: Etat 1 Etat 2 événement (paramètres) / action (paramètres)

83 Page N° 83 Actions en entrée et en sortie d'état Sont exécutées automatiquement à chaque fois que l'on entre et que l'on sort de l'état (même dans le cas d'une transition propre). Remarque : un état nest pas « responsable » de ses transitions entrantes. Notation: Nom d'état entry / action 1 exit / action 2

84 Page N° 84 Activités Une activité est une opération dont le temps dexécution est significatif pour le comportement de lobjet modélisé. Du fait de sa durée, une activité n'est pas attachée à une transition mais à un état; elle peut être interrompue par un événement qui cause une transition d'état. Notation: Une transition sortante sans événement et sans garde est déclenchée dès que lactivité de létat est terminée (transition automatique). Nom d'état do / activité

85 Page N° 85 Transitions internes Transitions qui se font à l'intérieur d'un état, sintercalant dans l'activité en cours. Contrairement aux transitions propres, elles n'activent pas les actions en entrée et en sortie de l'état. Notation: Nom d'état événement X / action

86 Page N° 86 Evénement différé Un evénement différé (deferred event) dans un état est un événement qui nest pris en compte que lorsque lobjet passe dans un autre état qui na pas lui-même différé cet événement. Notation : State name defer / event list

87 Page N° 87 Composition d'états Les états peuvent être décomposés en sous-états disjoints. Si un état A possède les sous-états A1, A2,..., alors un objet dans l'état A est forcément dans l'un ou l'autre des sous-états A1, A2, … Notation: Etat A1 Etat A2 Etat A32 Etat A31 Etat A3 Etat A

88 Page N° 88 Pseudo-états séquentiels [g2] H H*H* Final Point de choix ( Shallow ) Historique ( Deep ) Historique Initial

89 Page N° 89 Création et destruction d'objets L'état initial d'un objet est l'état où il entre au moment de son instanciation et où il est initialisé. L'état le plus général d'un objet représente son comportement. L'objet cesse d'exister quand il quitte cet état.

90 Page N° 90 Parallélisme interne Les états orthogonaux (and-states) représentent des états indépendants qui peuvent sexécuter en parallèle avec dautres états. Quand un état orthogonal est terminé, les autres états orthogonaux peuvent rester actifs. Une transition sortant de l'état englobant termine simultanément tous les états orthogonaux. Superstate name State xState q event aevent c State y event d State z event b State 1 State 2 event k And-state line

91 Page N° 91 Etats orthogonaux Quand un objet perçoit un événement, celui-ci est perçu par tous ses états orthogonaux. UML fournit un nombre de moyens pour synchroniser les états othogonaux dans un même objet, ou dans différents objets : –pseudo-état Join –pseudo-état Fork –événements Broadcast –pseudo-état Synch –…

92 Page N° 92 Fork et Join A C D X Y fork join B F événement 1 Toutes les transitions menant à un pseudo-état Join doivent être déclenchées par le même événement.

93 Page N° 93 Diagrammes de séquences Permettent la représentation graphique de scénarios Les diagrammes de séquences utilisent des lignes verticales pour représenter les objets et les flèches horizontales pour représenter la perception par un objet dun événement émis par un autre objet. Le temps sécoule du haut vers le bas.

94 Page N° 94 Diagrammes de séquences rôle1rôle2rôle3 Event X return b - a <= 10 ms a b y y y - y < 500 µs 50 ms ± 2 ms Event Y

95 Page N° 95 Diagrammes de séquences (2)

96 Page N° 96 Diagramme de timing

97 Page N° 97 Diagrammes dactivités Activité B0 Activité C1 Activité B1 Activité A1 Activité B2Activité C2Activité C3 Activité B3 Action C4 Action A2 événement e1 événement e2 [guarde1] [guarde2] Activité A3 a: A [état]

98 Page N° 98 Relations entre points de vue Tous les événements émis par les différents objets doivent être perçus par d'autres objets et réciproquement. Toute donnée utilisée dans une garde, une action ou une activité doit correspondre soit à un objet, soit à un attribut d'un objet. Les diagrammes de séquences doivent être cohérents avec les diagrammes d'états, … Les outils CASE (Computer Aided Sofware Engineering) qui supportent le langage UML permettent d'effectuer un certain nombre de contrôles de cohérence au niveau du modèle d'analyse.

99 Page N° 99 Itérer l'analyse La plupart des problèmes nécessitent plus d'une passe avant que le modèle d'analyse ne soit complet. Ne pas perdre de vue l'un des objectifs majeurs de l'analyse objet, qui est de réaliser des composants répondant à des besoins précis, ayant des couplages structuraux faibles. En fin d'analyse, toutes les exigences fonctionnelles du modèle d'exigences doivent avoir été allouées à des classes.

100 Page N° 100 Modèle dexigences vs modèle danalyse Modèle dexigences – Langage naturel structuré – Vue externe du système – Contrat entre le client et lindustriel – Décrit les fonctionnalités du système sous forme de paquets de Cas dutilisation Modèle danalyse – Langage UML – Vue interne du système – Décrit le système en termes dobjets, détats et dévénements –Structure le système en constituants logiques correspondant aux Cas dutilisation (classes, sous-systèmes, composants, …)

101 Page N° 101 Introduction Processus de développement Concepts objets UML et les activités de modélisation Conception Lapproche MDA

102 Page N° 102 De l'analyse à la conception La conception consiste à passer d'une modélisation logique du besoin à la construction physique dune solution. Le principe à respecter pour le passage de l'analyse à la conception est celui de la monotonie : toute information fournie en analyse doit se retrouver en conception. Il est impératif d'assurer la traçabilité entre les modèles de conception et ceux d'analyse.

103 Page N° 103 Objectifs de la conception La conception dun système suppose la prise en compte des exigences fonctionnelles et non fonctionnelles (performances, fiabilité, ergonomie, …) Elle implique des décisions sur : –La décomposition du système en constituants plus simples (sous-systèmes, composants, …), –L'intégration de l'existant, –Pour la partie logicielle, la répartition en différents exécutables (clients et serveurs), –Le traitement de la concurrence, –La persistance des données, –Les besoins en ressources matérielles, … Il est possible que tout ou partie de la solution soit fournie par la réutilisation de composants existants

104 Page N° 104 Artefacts UML pour la conception Le modèle de conception inclut : –Des diagrammes de classes et de structure composite –Des diagrammes de composants avec leurs interfaces –Des diagrammes de collaboration (communication) illustrant les interactions entre sous-systèmes, composants et objets durant lexécution des scénarios. La conception produit également le modèle de déploiement qui décrit différentes configurations physiques possibles du système.

105 Page N° 105 Quest-ce quun composant ? Un composant est un objet composite qui fournit et requiert à la fois des services basés sur des interfaces spécifiées. Représentation en UML : Interface fournie par ce composant Interface requise

106 Page N° 106 Inte rfac es Une interface spécifie les opérations dune classe ou dun composant. Vue comme une classe, une interface peut être spécialisée, avoir des associations et des dépendances. La réalisation d une interface est une relation sémantique entre une classe dinterface qui spécifie un contrat (rôle) et une classe qui joue ce rôle. Les classes interfaces sont des classes abstraites qui ne peuvent avoir que des opérations.

107 Page N° 107 Interfaces et ports Required Interface Provided Interface

108 Page N° 108 Diagramme de structure composite

109 Page N° 109 Activités de conception La conception fait intervenir deux niveaux dactivités : –Conception darchitecture, –Conception détaillée.

110 Page N° 110 Introduction Processus de développement Concepts objets UML et les activités de modélisation Conception darchitecture Lapproche MDA

111 Page N° 111 Conception darchitecture Lobjectif est de déterminer larchitecture du système, ce qui implique : –des choix technologiques –la conception des sous-systèmes Au travers de cette activité les architectes considèrent différentes possibilités en se basant sur des schémas de conception éprouvés. La conception darchitecture déborde du seul domaine logiciel, et implique des décisions au niveau physique ou matériel qui peuvent avoir un très fort impact sur les qualités de service du système.

112 Page N° 112 Quest-ce quune architecture ? Larchitecture dun système est sa structure, qui comprend : –ses composants –les propriétés externes et visibles de ces composants –les relations entre ceux-ci Noter que larchitecture dun système nest pas une simple collection de ses parties (e.g. habituellement, une voiture nest pas un tas de pièces !)

113 Page N° 113 Points de vue architecturaux Quelques uns des points de vue les plus utilisés : –Logique : les constituants dérivent des exigences fonctionnelles. –Processus : sintéresse aux aspects dynamiques (synchronisation et concurrence, …). –Physique : allocation des fonctionnalités aux constituants physiques. Déploiement des composants logiciels sur le matériel (calculateurs, réseaux, …). La vue logique porte sur les rôles des constituants dun système et leurs collaborations. Les vues processus et physique sont cruciales pour raisonner en termes de performances, de disponibilité, de sécurité,...

114 Page N° 114 Styles darchitectures Les styles darchitectures correspondent à des principes généraux de conception dun système visant à obtenir certaines qualités de service. Généralement, un style darchitecture présente un ensemble de types de composants et de principes visant à contrôler leur comportement et/ou leurs échanges. Exemples de styles darchitectures : –À base de composants (Client/Serveur, Publish/Subscribe, …) –Flot de données (Pipe-and-Filter, Batch,..) –Centrée sur les données (Repository, Blackboard, …) –En couches (Machine virtuelle, …) –...

115 Page N° 115 Style Pipe and filter Les composants sont des filtres –Qui transforment les messages dentrée en messages de sortie –Tous les composants ont la même interface –Généralement une interface provided (entrée) et une inteface required (sortie) –Les filtres sont indépendants Les connecteurs sont des pipes –conduits pour les messages –simple connections entre interfaces required et provided

116 Page N° 116 Style Pipe and filter (2) Avantages –Comportement du système = somme des comportements des –Facilité dajout, de remplacement et de réutilisation des filtres Inconvénients –Organisation batch des traitements –Applications non interactives –La transmission des données se fait suivant un plus petit dénominateur commun Utilisé couramment pour : –Les shells UNIX –Les systèmes distribués –Le traitement du signal –La programmation parallèle Mais également utile pour les systèmes dentreprise

117 Page N° 117 Style Layered architectures Organisation hiérarchique des systèmes –Les composants sont organisés en couches –Chaque couche fournit une interface qui peut être utilisée par les couches supérieures Contraintes: chaque couche a : –Une relation 1-1 avec les autres couches –Chaque couche communique seulement avec la couche inférieure (architecture fermée, fully opaque) Les connecteurs sont les protocoles de communication entre couches Examples –Systèmes dexploitation –Communications réseaux

118 Page N° 118 Exemple: HTTP Application Layer Transport Layer Network Layer Data Link Layer Physical Layer TCP HTTP Request HTTP Request IP TCP HTTP Request Ethernet IP TCP HTTP Request Chaque couche communique avec la couche voisine par une interface, suivant un certain protocole

119 Page N° 119 Style Layered architectures (3) Avantages –Niveaux dabstration ordonnés –Maintainabilité – le rôle de chaque couche est bien déterminé –Réutilisabilité –Portabilité Inconvénients –Ne peut être appliqué pour des composants qui se répartissent sur plusieurs couches –performances –Détermination des niveaux dabstraction –En pratique, une couche peut être amenée à communiquer avec une couche non adjacente

120 Page N° 120 Style Blackboard (Repository) Fait intervenir deux sortes de composants –La structure de données centrale (blackboard or repository) –Les clients Le comportement du système est contrôlé par létat du blackboard Contraintes –Un seul blackboard –1.. n clients

121 Page N° 121 Style Blackboard : exemples –Systèmes dIA –Compilateurs –e-commerce: components stateless dirigés par des composants stateful –IDEs (Integrated Development Environments) (e.g., Visual Studio, Borland Development Environment, Eclipse) >

122 Page N° 122 Style Blackboard (3) Avantages –Les clients relativement indépendants les uns des autres –Les base de données sont indépendantes des clients –Lintégration des données peut se faire à partir du blackboard

123 Page N° 123 Style Model-view-controller Introduit pour la première fois en Smalltalk-80 (créé par Trygve Reenskaug) Trois stéréotypes de composants : –Les composants Model correspondent aux composants métiers –Les composants View sont responsables de la présentation des informations à lutilisateur –Les composants Controller gérent les interactions avec lutilisateur components responsible for managing the sequence of interactions Les composants modèles sont conçus de manière à ne pas dépendre des composants vues et contrôleurs Les changements détats sont propagés aux vues suivant un protocole publish / subscribe.

124 Page N° 124 Style Model-view-controller (2) Intérêts : –Flexibilité (les évolutions de linterface naffecte pas les traitements de lapplication) –Possibilité dajouter des vues et des contrôleurs, –Synchronisation des vues

125 Page N° 125 Style Model-view-controller (3)

126 Page N° 126 Style Client/Serveur Une architecture client/serveur est une infrastructure souple, orientée messages et modulaire visant à améliorer la flexibilité, l'interopérabilité et l'extensibilité par rapport à une architecture centralisée

127 Page N° 127 Style Client / Serveur (2) Introduit une base de données en complément du serveur de fichiers. Réduit le traffic sur le réseau en fournissant la réponse à une requête plutôt qu'un fichier complet Facilite l'accès concurrent aux données partagées

128 Page N° 128 Aspects du Client/Serveur La présentation se rapporte à la logique d'échange d'informations avec les acteurs externes Le traitement se rapporte à la logique applicative. La persistance se rapporte à la logique d'interfaçage avec les systèmes de stockage des données

129 Page N° 129 Architecture un-tier Les trois aspects sont traités dans un même exécutable sur une seule machine Avantages –Facilité d'administration, de contrôle et de sécurisation Inconvénients –Limité en performances –Dépendance par rapport à l'environnement d'exploitation –Très difficile à maintenir.

130 Page N° 130 Architecture deux-tiers Données IHM Présentation+ partie du traitement Persistance+

131 Page N° 131 Avantages et inconvénients de l'architecture deux-tiers Inconvénients Extensibilité Couplage structural Client/Serveur Portabilité Contrôle de versions Avantages Simplicité Facilité de développement

132 Page N° 132 Architecture trois-tiers IHMDonnées Client lourd Application Traitement Client léger

133 Page N° 133 Avantages et inconvénients de l'architecture trois-tiers Avantages Performances Réusabilité Interoperabilité Fiabilité et disponibilité Extensibilité Flexibilité Productivité Temps de développement Inconvénients Complexité de développement et d'administration

134 Page N° 134 Middleware Platform Operating SystemOperating System HardwareHardwarePlatform Operating SystemOperating System HardwareHardware Business application Middleware Application Programming Interfaces Platform Interfaces

135 Page N° 135 Objectif des middlewares Transparence Intéropérabilité Portabilité Intégrabilité et support de l'environnement existant

136 Page N° 136 Transparence Accès Localisation Persistance Tolérance aux pannes Réplication Transactions

137 Page N° 137 Paradigmes de communication Synchrone –Remote Procedure Calls –Invocation d'objets Asynchrone –Message Oriented Middleware –Publish/Subscribe, Technologies événementielles

138 Page N° 138 Object Request Brokers (ORBs) Un ORB agit comme un centre d'échanges téléphoniques. Il fournit un annuaire de services et aide à établir des communications synchrones entre des objets distribués. Avantages –Interopérabilité –Portabilité –Séparation de la spécification de l'implémentation –Les objets distribués sont plug-and-play

139 Page N° 139 Message Oriented Middlewares (MOMs) Un MOM est un middleware basé sur une file d'attente qui autorise une application à interagir de manière asynchrone avec d'autres applications Les MOM traduisent également les messages. Actuellement, les MOM fournissent les meilleures solutions pour l'EAI (Enterprise Application Integration)

140 Page N° 140 Moniteurs transactionnels Un moniteur transactionnel (TPM - Transactionnel Processing Monitor) est un type de middleware qui agit comme un multiplexeur : il permet à des ressources comme les processus et les threads d'être partagés entre des milliers d'utilisateurs concurrents Serveur sans TPMServeur avec TPM 1000 connexions 1000 processus 50 Gbytes de RAM 10 000 fichiers ouverts TPM 1000 clients 50 connexions partagées 50 processus 2,5 Gbytes de RAM 500 fichiers ouverts 1000 clients50 services

141 Page N° 141 Moniteurs transactionnels (2) Les applications qui utilisent des moniteurs transactionnels s'exécutent de manière fiable grâce à des protocoles transactionnels. La technologie des moniteurs transactionnels : apporte de nombreuses possibilités telles que le redémarrage en cas de panne, l'équilibrage des charges, et améliorent la consistance des données partagées. est facilement extensible par l'ajout de serveurs pour faire face à l'augmentation des utilisateurs est indépendante de l'architecture des bases de données Mais les services contrôlés par les moniteurs transactionnels ne sont pas des objets.

142 Page N° 142 Architecture basée composants Un composant est un ensemble d'unités élémentaires de déploiement, de gestion de configuration et d'échange Une architecture basée composants consiste en : –une plate-forme –un ensemble de frameworks (conteneurs de composants) –un ensemble de services pour l'interaction de ces frameworks Execution Platform Component Component framework Component

143 Page N° 143 Frameworks Un framework est une entité logicielle qui supportent des composants se conformant à certains standards et qui autorise ces composants à se connecter à lui. Généralement, un framework accepte le chargement à chaud de composants Un framework établit le contexte nécessaire aux instances de composants et à leurs interactions Component Component framework Component

144 Page N° 144 Frameworks et middlewares Les produits isolés, comme les MOM, les moniteurs transactionnels, disparaissent progressivement Au contraire, des serveurs spécialisés émergent, qui intègrent les fonctions des middlewares dans des frameworks spécifiques –Serveurs d'intégration qui combinent la conversion de protocoles, la conversion des données, le routage des événements, le workflow, … –Les serveurs d'applications qui combinent la gestion transactionnelle, l'équilibrage des charges, … –Ces frameworks sont construits sur l'une des plates-formes majeures telles que CORBA, J2EE ou.NET

145 Page N° 145 Serveurs d'intégration Les serveurs d'intégration sont la dernière approche pour intégrer des applications disparates d'une entreprise, des bases de données, des systèmes de transactions. Les serveurs d'intégration jouent un rôle majeur dans le développement des systèmes distribués qui forment le Web, les enteprises de réseaux, … Ils aident les entreprises à intégrer des applications packagées, des applications existantes,...

146 Page N° 146 Serveurs d'applications Un serveur d'application reçoit les requêtes des clients, exécute les traitements et réalise l'interface avec toute une série de systèmes back-office. Les services applicatifs de base sont : –la gestion transactionnelle –la gestion de la persistance des données –la sécurité –l'équilibrage des charges –la tolérance aux pannes,...

147 Page N° 147 Architecture d'un Système La couche business process utilise des règles pour enchaîner les interactions des composants Business Process Components/ServicesComponents/Services MessagingMessaging TransportTransport Business rules Workflow MQSeries, TIBCO,... CCM, J2EE,.NET,... CORBA, DCOM, Java/RMI,...

148 Page N° 148 Architecture des applications Web Une application Web est typiquement un système client /serveur qui comprend trois composants architecturaux : Presentation Browser Web_server Persistence Business Application_server

149 Page N° 149 Client léger Les composants majeurs du tier présentation résident sur le serveur Web HTTP

150 Page N° 150 Client lourd Les scripts et les modules sont exécutés sur le client

151 Page N° 151 Au delà de HTTP et de HTML Du fait de la nature non connectée de HTTP beaucoup des schémas des objets distribués ne peuvent s'appliquer aux applications Web L'utilisation des protocoles IIOP, RMI, DCOM ou SOAP permet au client de contourner HTTP et de communiquer directement avec des objets serveurs

152 Page N° 152 Simple Object Access Protocol (SOAP) SOAP est un standard W3C basé sur XML qui permet l'invocation d'objets distants en utilisant généralement HTTP SOAP fournit des standards pour : –décrire le destinataire de l'invocation –encoder un large éventail de types de données dans les messages –définir quelles parties d'un message doivent être comprises ou peuvent être ignorées, … En utilisant SOAP, rien ne garantit que la résolution de deux requêtes pour la même URL arrivent sur le même objet

153 Page N° 153 Web services Les Web Services sont des services offert par des serveurs Web en utilisant SOAP Contrairement aux serveurs Web traditionnels qui servent des pages Web, les Web services offrent des services de traitement aux autres systèmes

154 Page N° 154 Modèle de déploiement Décrit la distribution physique du système, cest-à-dire la façon dont les fonctionnalités sont distribuées sur les nœuds du système. Les nœuds ont des relations qui représentent leurs moyens de communication (bus, internet, …). Le modèle de déploiement peut décrire plusieurs configurations, incluant les configurations de test et de simulation.

155 Page N° 155 Deploiement Le déploiement définit : –Les nœuds utilisés, ainsi que leurs capacités en termes de puissance de calcul et de taille mémoire, –Les types de connections établies entre les noeuds, et les protocoles de communication, –Les caractéristiques des connections telles que la bande passante, … –Les besoins en redondance pour les capacités de traitement, la tolérance aux pannes, la sauvegarde des données,... En connaissant les possibilités et les limites des nœuds et des connections, larchitecte peut incorporer des technologies telles que les Object Request Brokers et les services de réplication de données, qui facilitent la réalisation des systèmes distribués.

156 Page N° 156 Diagramme de déploiement Noeud 3 « senseur » Nœud 1 Composant 2 « processeur » Noeud 2 Composant 3

157 Page N° 157 Introduction Processus de développement Concepts objets UML et les activités de modélisation Conception détaillée Lapproche MDA

158 Page N° 158 Quest-ce que la conception détaillée ? Consiste à concevoir les classes de manière à ce quelles remplissent leur rôle dans les Cas dutilisation et en tenant compte des exigences non-fonctionnelles. Ceci implique la définition de leur interface (opérations) et de : –leurs attributs, –leurs associations –leurs méthodes (algorithmes correspondant aux opérations),

159 Page N° 159 Conception détaillée La conception détaillée des classes est faite en partant du modèle danalyse et du modèle de conception darchitecture, en ajoutant des détails de réalisation (en UML). La traçabilité est assurée par rapport au modèle danalyse, mais certaines classes sont ajoutées en phase de conception.

160 Page N° 160 Diagrammes de collaboration Un diagramme de collaboration représente la réalisation dun scenario dun Cas dutilisation en termes de transmissions de messages entre objets ou entre composants. Les diagrammes de collaboration sont très utiles pour déterminer les interfaces des objets et des composants (au nom dun message doit correspondre une opération dans linterface de lobjet invoqué).

161 Page N° 161 Exemple objet1: classe objet3 :classe 1:operation 2.1: operation (liste de paramètres ) 1.1:operation ( liste de paramètres ) 2: r := operation (liste de paramètres ) événement objet2

162 Page N° 162 Diagramme de collaboration (exemple)

163 Page N° 163 Objets actifs En analyse, tous les objets sont considérés comme pouvant avoir a priori des comportements parallèles. En conception, le nombre de fils de contrôle (threads) doit être limité pour des raisons defficacité. Pour cela, chaque thread est habituellement « enraciné » dans un seul objet actif, qui perçoit les événements et les distribue aux objets appropriés.

164 Page N° 164 Stéréotypes de synchronisation Les principaux stéréotypes de synchronisation sont : –"appel": appel bloquant, l'appelé n'ayant pas son propre fil de contrôle –"asynchrone": sans attente –"rendez-vous": l'appelant attend Un message asynchrone est représenté graphiquement par une demi-flèche Chaque fil (thread) de contrôle est repéré par une lettre majuscule. Exemple : B 2 / A 7 : message (liste de paramètres ) [ garde ]

165 Page N° 165 Exemple

166 Page N° 166 Profils de conception (design patterns) Un profil de conception représente une solution type à un problème récurrent de conception. Un profil est une abstraction réutilisable. Ce n'est pas un composant logiciel réutilisable. Un profil de conception doit être adapté à un problème spécifique.

167 Page N° 167 Profils de conception Les profils constituent un vocabulaire commun de conception. Les profils permettent d'obtenir une conception homogène des applications, et favorisent la maintenabilité. Les profils de conception exploitent les possibilités –de spécialisation ou de délégation –de polymorphisme

168 Page N° 168 Catalogue de profils Profils de création –Fabrique –Prototype –Singleton –Proxy Profils de structuration –Adaptateur –Bridge –Composite –Décorateur –Façade –Poids plume Profils de comportement -Etat -Interpréteur -Itérateur -Médiateur -Méthode squelette -Observateur -Stratégie -Visiteur -Commande

169 Page N° 169 Problèmes types traités par les profils Création d'un objet en spécifiant dynamiquement sa classe Fabrique abstraite, Fabrique méthode, Prototype. Dépendance envers des opérations spécifiques Commande. Dépendance envers des plates-formes HW et SW Fabrique abstraite, Bridge. Dépendance entre l'interface et l'implémentation d'un objet Fabrique abstraite, Bridge, Proxy.

170 Page N° 170 Problèmes types traités par les profils Dépendance algorithmique Méthode template, Itérateur, Stratégie, Visiteur. Couplage fort Fabrique abstraite, Bridge, Commande, Façade, Médiateur, Observateur. Extension des fonctionnalités par héritage Bridge, Composite, Décorateur, Observateur, Stratégie. Modifiabilité des classes Adaptateur, Décorateur, Visiteur.

171 Page N° 171 Exemple : le profil Etat traiter() Etat Feuille traiter () Contexte Etat concret B état courant traiter () état courant -> traiter () Etat concret A traiter () états possibles *

172 Page N° 172 Conception des attributs Le type des attributs des objets est généralement simple, car sinon un objet séparé serait créé pour le représenter. La conception détaillée doit spécifier le domaine de valeurs des attributs, leur précision et leur valeur initiale. A côté des attributs définis dans le modèle danalyse, la conception détaillée peut ajouter des attributs pour optimiser les performances.

173 Page N° 173 Conception des attributs Les attributs qui représentent des collections peuvent être conçus de multiples manières, incluant les piles, les files, les vecteurs, les tableaux, … Les contraintes sur les attributs collections peuvent être indiquées sous forme dannotations : {ordered}, {set}, {hashed}, … Les attributs ne devraient jamais être visibles de lextérieur des objets.

174 Page N° 174 Visi bilit é Un attribut peut avoir différents statuts de visibilité : + publique : tout objet peut y accéder (bien que prévu par UML, ce statut est déconseillé) - privé : seul lobjet lui-même peut y accéder # protégé : accessible au niveau des sous-classes $ de classe : dont la valeur est partagée par toutes les instances de la même classe Ces conventions sappliquent également aux opérations

175 Page N° 175 Conception des associations Les associations entre objets permettent aux objets clients dinvoquer les opérations fournies par les objets serveurs. La direction des transmissions de messages entre objets implique des possibilités de navigation correspondantes au niveau de leurs classes. Eviter de traverser les associations. Les noms de rôles peuvent devenir des attributs.

176 Page N° 176 Conception des associations Si une association possède des attributs, trois cas peuvent se présenter : –Si l'association est 1-1, les attributs peuvent être reportés dans l'une ou l'autre classe –Si l'association est 1-n, les attributs peuvent être reportés dans la classe de multiplicité n –Si l'association est n-n, la meilleure approche est d'implémenter l'association comme une classe distincte. Les cas les plus simples sont les associations 1-1 ou 1- (0,1) entre objets dans le même thread. La traversée de la frontière des threads complique la conception des associations, du fait des problèmes de réentrance et dexclusion mutuelle.

177 Page N° 177 Conception des opérations La plupart du temps les opérations dune classe correspondent à des messages qui peuvent être reçus par des objets de cette classe. Ainsi, les diagrammes de collaboration sont très utiles pour trouver les opérations des classes. La conception détaillée ajoute souvent des opérations qui sont utilisées seulement en interne. Si les objets clients en ont besoin, lopération doit être visible, sinon la rendre inaccessible.

178 Page N° 178 Algorithmes et méthodes Une méthode spécifie un algorithme qui réalise une opération. Une méthode peut être décrite en langage naturel, dans une formulation mathématique ou sous forme de pseudo- code. Les diagrammes dactivités peuvent être utiles dans certains cas.

179 Page N° 179 Points clés de la conception Le modèle de conception doit préserver si possible toute structure définie dans le modèle danalyse, et sert lui- même de référence pour limplémentation. Le modèle de conception inclut : –La conception des sous-systèmes et de leurs dépendances –La conception des classes, incluant les classes actives, et leurs attributs, associations et opérations. La conception fournit également le modèle de déploiement, qui décrit chaque configuration possible pour le système. Lutilisation de profils de conception est fortement conseillée.

180 Page N° 180 Modèle danalyse vs modèle de conception Modèle danalyse –Conceptuel, abstraction logique du système –Utilise trois stéréotypes de classes : Entité, Frontière et Contrôleur Modèle de conception –Physique, référence pour limplémentation –Définit le placement du logiciel sur les processeurs, décrit les protocoles et traite les problèmes de concurrence –Intègre les middlewares et les sous-systèmes tels que les systèmes dexploitation, les systèmes de gestion de bases de données, les interfaces graphiques, les technologies de gestion transactionnelle, …

181 Page N° 181 Introduction Processus de développement Concepts objets UML et les activités de modélisation Tests Lapproche MDA

182 Page N° 182 Plans de tests Les plans de test doivent être rédigés en fin : –danalyse pour les tests de validation –de conception d'architecture pour les tests d'intégration –de conception détaillée pour les tests unitaires.

183 Page N° 183 Tests unitaires La conception objet réduit un certain nombre de risques d'erreurs : –Les méthodes tendent à être petites et avec une faible complexité algorithmique –L'encapsulation protège des nombreux problèmes dus à un mauvais contrôle de la visibilité des variables,... Mais elle ne facilite pas les tests unitaires. Les tests unitaires peuvent être des tests « boîte noire » (déquivalence, de robustesse, …) ou « boîte blanche »

184 Page N° 184 Tests unitaires Une classe est, a priori, une unité de test. Toutefois : –En cas d'héritage, on ne peut dissocier les classes filles des classes parentes. Par ailleurs, il peut être nécessaire de tester des méthodes héritées –En cas d'utilisation du profil Etat, l'unité de test correspondra à la classe et à l'ensemble de ses états –…

185 Page N° 185 Test dintégration et de validation Les tests dintégration sont menés au niveau des composants Les tests de validation consistent à tester différents scénarios des cas dutilisation, le système étant vu comme une boîte noire

186 Page N° 186 Introduction Processus de développement Concepts objets UML et les activités de modélisation Lapproche MDA

187 Page N° 187 MDA - Model Driven Architecture MDA distingue les modèles indépendants de la plate forme (PIM) et les modèles spécifiques de la plate forme correspondants (PSM).

188 Page N° 188 Model Driven Architecture Utilise UML et les profiles UML (e.g. EDOC - Enterprise Distributed Object Computing) models Fait une claire séparation entre les spécifications et leurs réalisations PIMModel MiddlewareAbstraction ExistingMiddlewareServices Mapping Tool PSMModel

189 Page N° 189 Points de vue MDA ReqSpecif. Prelim.Design DetailedDesign Coding Validation Integration Integration & Test UnitTest The classical V process Functional reqs spec & analysis Technical reqs spec & analysis Architectural decisions Realisation Functional reqs spec & analysis Technical PIM reqs spec & analysis Architectural decisions PIM design Technical PSM reqs spec & analysis Architectural decisions Realisation

190 Page N° 190 Les plates formes dominantes actuelles CORBA, J2EE and.NET ont un grand nombre de concepts communs qui visent à favoriser lutilisation de composants logiciels. Les standards et les architectures tels que XML, les Web services et MDA relativisent les différences existant entre les différentes plates formes. Des objectifs majeurs pour le développement des nouveaux systèmes est leur interopérabilité (plutôt que leur intégration), leur portabilité, la réutilisabilité des composants et leur maintenabilité Des facteurs clés pour atteindre ces objectifs sont : –Lusage de plates formes orientées composants –Les développements basés sur la réalisation de modèles UML –Une nette séparation entre les activités danalyse et de conception / réalisation.

191 Page N° 191 Bibliographie Buschmann Frank and al. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Ltd., 1996. Edwards Jeri. 3-tier Client/server At Work. John Wiley & Sons, Ltd., 1999 Szyperski Clemens and al. Component software - Beyond Object-Oriented Programming. Addison-Wesley, 2002 Fowler, Martin. Analysis Patterns: Reusable Object Models. Reading, MA: AddisonWesley- Longman, Inc., 1997 Cheesman, John, and John Daniels. UML Components. A Simple Process For Specifying Component-Based Software, Addison-Wesley, 2001. Wallnau, Kurt C., Scott A. Hissam and Robert C. Seacord. Building Systems From Commercial Components, Addison-Wesley, 2001. Heineman, George T., and William T. Councill. Component-Based Software Engineering. Putting The Pieces Together, Addison-Wesley, 2001. Albin Stephen T. Art of Software Architecture. Wiley, 2003 Kleppe Anneke and al. MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley, 2003 Frankel David S. Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley, 2003.