www.objis.com
Formation UML
Page N° 2www.objis.com
Introduction
Processus de développementConcepts objetsUML et les activités de modélisationL’approche MDA
Page N° 3www.objis.com
Les systèmes développés sont de plus en plus
importants et complexes
Il importe d’avoir 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 d’une méthodologie de développement objet
Page N° 4www.objis.com
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 l’objet et d’UML
Page N° 5www.objis.com
Qu’offre 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.
Page N° 6www.objis.com
Introduction
Processus de développement
Concepts objetsUML et les activités de modélisationL’approche MDA
Page N° 7www.objis.com
Le processus de développement objet
Ce processus est :
– basé sur la réalisation de modèles (Model Driven),– dirigé par les besoins (Cas d’utilisation),– 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
d’abstraction, – l’automatisation de certaines tâches de conception
Page N° 8www.objis.com
Qu’est-ce qu’un modèle ?Un modèle est une représentation abstraite d’un système plus facile à appréhender que la « réalité ».
Trois principes d’abstraction 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 d’un système est arborescente, et cette structure est invariante quel que soit
le point de vue sur ce système.
Page N° 9www.objis.com
Phases de développementAvec 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 n’implique pas de rupture dans le processus de développement.
Page N° 10www.objis.com
Modèle de réalisation
Modèle d’exigences
Modèle de conception
1
2Analyse
3Consolidation des exigences 4
Conception5
Réalisation
6
Tests
Modèle d’analyse
Capture des exigences
Modèle de tests
Modèle de déploiement
Processus basé sur la réalisation de modèles
Page N° 11www.objis.com
Modèles produits par le processus
Les modèles produits par les différentes activités du processus sont au minimum :
– Le modèle d’exigences (besoins)– Le modèle d’analyse qui a deux propos :
• affiner et consolider les Cas d’utilisation
• allouer le comportement du système à un ensemble de composants logiques
– Le modèle de conception qui précise l’architecture du système avec ses sous-systèmes et composants physiques, leur contenu, leurs dépendances et leurs interfaces
– Le modèle de tests
Page N° 12www.objis.com
Processus dirigé par les besoinsLes besoins fonctionnels sont décrits sous forme de « Cas d’utilisation ».
Un Cas d’utilisation :
– est une capacité globale d’un système (ou d’un constituant) vu comme un tout,
– est décrit comme une séquence d’interactions entre le système et ses acteurs
– sert aussi de point d’ancrage pour décrire des exigences non-fonctionnelles.
Un processus dirigé par les besoins suit un flot d’activités : les Cas d’utilisation sont spécifiés, puis analysés et à la fin du processus les Cas d’utilisation forment la source à partir de laquelle les tests de validation sont construits.
Page N° 13www.objis.com
Types d’exigences
Cas d’utilisation Système à développer
ArchitecturePerformances
Ergonomie
Disponibilité
ExistantCouts/délais
Maintenabilité
Sécurité d’accès
Fiabilité
Les exigences peuvent être utilisées comme métrique pour la conduite de projet
Page N° 14www.objis.com
Processus récursif
Le processus de développement est appliqué récursivement à différents niveaux :
– système, – sous-systèmes, – composants,…
Page N° 15www.objis.com
Processus itératif et incrémentalConsiste à 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 qu’un certain nombre de Cas d’utilisation
Les contraintes d’architecture sont prises en compte dès la première itération.
Page N° 16www.objis.com
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é d’un composant ne se construit pas à coût nul.
Page N° 17www.objis.com
IntroductionProcessus de développement objet
Concepts objets
UML et les activités de modélisationL’approche MDA
Page N° 18www.objis.com
Qu’est-ce qu’un 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.
Page N° 19www.objis.com
Existence d’un objet
L’existence d’un objet est ce qui permet aux autres objets d’y 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.
L’existence d’un objet est ce qui lui est propre, ce qui le distingue de tout autre objet.
Page N° 20www.objis.com
Structure d’un objet
Un objet non primitif est une structure faite d’autres objets (ses composants).
Page N° 21www.objis.com
Etats d’un objet
Un état d’un objet définit sa manière d’être par rapport à d’autres objets dans une situation donnée.
L’identification d’un état d’un objet nécessite la donnée d’un référentiel (type, gamme de valeurs, …).
Page N° 22www.objis.com
Evénements
Un événement est l’avènement d’une information.
Un objet peut réagir aux événements qu’il perçoit dans son environnement.
Les objets qui perçoivent un événement ne sont pas forcément connus de l’émetteur.
Page N° 23www.objis.com
Invocation d'objets
Les objets peuvent interagir explicitement en s’envoyant 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 l’objet destinataire dépend de celui-ci et de son état
Page N° 24www.objis.com
Comportement
Le comportement d’un objet est défini par les actions qu’il entreprend dès sa création ou suite à la perception d’un événement ou la réception d’un message.
Le comportement d’un objet peut entraîner la création ou la destruction d’autres objets ou des changements d’états.
Un objet est dit « actif » lorsqu’il entreprend et contrôle des actions dès sa création et/ou à partir d’événements qu’il perçoit dans son environnement (et non pas seulement sur réception de messages d’autres objets)
Page N° 25www.objis.com
ConcurrenceDiffé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 qu’un autre objet ait terminé son activité.
Différents types de synchronisation permettent de décrire les modalités d’interaction des objets.
La notion de concurrence peut s’appliquer aux activités parallèles d’un même objet.
Page N° 26www.objis.com
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.
Page N° 27www.objis.com
Classes et objets
Ne pas confondre cette notion avec celle de classe d’équivalence, qui rassemble des objets existants.
Toutes les instances d’une 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 d’objets : la création d'un objet se fait conformément à sa classe (on parle d’ « instanciation » de sa classe).
Page N° 28www.objis.com
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 d’initialisation des instances, ...).
Page N° 29www.objis.com
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 d’une propriété),– par restriction des états possibles d’une propriété,– par spécialisation des opérations, …
La généralisation est la relation inverse de la spécialisation.
Page N° 30www.objis.com
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 d’héritage des langages informatiques utilise le polymorphisme.
Page N° 31www.objis.com
Mécanisme d’héritage
Le mécanisme d’héritage suppose que l’opération à appliquer par un objet à la réception d’un message soit déterminée seulement au moment de l’exécution (liaison dynamique).
Si l’opération est définie dans la classe de l’objet, elle est exécutée, sinon les superclasses sont examinées en remontant le graphe de spécialisation jusqu’à ce que l’opé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 n’a pas été spécialisée dans ses sous-classes.
Page N° 32www.objis.com
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
Page N° 33www.objis.com
IntroductionProcessus de développement objetConcepts objets
UML et les activités de modélisation
L’approche MDA
Page N° 34www.objis.com
UML - Unified Modeling LanguageUML offre différents formalismes pour spécifier, analyser et concevoir une solution qui satisfasse les exigences d’un 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 d’utilisation, le diagramme de séquences, le diagramme d’activités, le diagramme d’états et le diagramme de collaboration.
Page N° 35www.objis.com
Les quatre niveaux de modélisation
Page N° 36www.objis.com
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 d’UML par ajout de contraintes et d’interprétations qui correspondent à un domaine spécifique. Ils n’ajoutent pas de nouveaux concepts fondamentaux.
Page N° 37www.objis.com
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, …).
Page N° 38www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Modélisation des exigences avec UML
L’approche MDA
Page N° 39www.objis.com
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 l’interface utilisateur (mais éviter de faire des choix prématurés de conception)..
Comprendre le besoin opérationnel
Page N° 40www.objis.com
Cas d’utilisation
Les Cas d’utilisation 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 d’un seul Cas d’utilisation sont traitées avec celui-ci.
Noter que les Cas d’utilisation ne sont pas de simples processus algorithmiques : ils définissent également leur contexte d’exécution.
Page N° 41www.objis.com
Artefacts des Cas d'utilisation
Un cas d’utilisation spécifie une séquence (ou plusieurs séquences parallèles) d’interactions entre un système (vu comme un tout) et ses acteurs.
Un Cas d’utilisation 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 d’utilisation qui sont fortement couplés peuvent être organisés en « packages ».
Page N° 42www.objis.com
Rôles et acteursUn rôle se définit comme le comportement d’un acteur (qui peut être un opérateur, un sous-système, un composant, …) par rapport à d’autres acteurs. Un acteur se définit par l’ensemble 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).
Page N° 43www.objis.com
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 d’utilisation 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
Page N° 44www.objis.com
Modèle de Cas d’utilisation• Identifiant• Objectif • Priorité• Acteurs principaux• Acteurs secondaires• Pré-conditions• Profil d’activation• Description (séquences d’interactions 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
Page N° 45www.objis.com
Diagramme de Cas d’utilisation
Présente les acteurs, les Cas d’utilisation, leurs liens (dépendance, généralisation) et les regroupe éventuellement en packages.
Notation :
A1
A2 UC3
UC2
UC1
A3
Page N° 46www.objis.com
Relations entre Cas d’utilisation
Cas d’utilisation 1 Cas d’utilisation 3
Cas d’utilisation 4Cas d’utilisation 2
«extends»
«includes»
Extension Point : X
Le Cas d’utilisation 3 étend le Cas d’utilisation 1
Généralisation
Le Cas d’utilisation 2 spécialise le Cas d’utilisation 1. Comme lui, il inclut le Cas
d’utilisation 4 et peut être étendu par le Cas d’utilisation 3
Le Cas d’utilisation 1 inclut le Cas d’utilisation 4
Page N° 47www.objis.com
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 d’utilisation.
Scénario
Page N° 48www.objis.com
Points clés de la modélisation des exigences
Trouver les Cas d’utilisation, les rôles et les acteurs à partir de l’expression de besoins initiale du client et des autres parties prenantes.
Ordonner les Cas d’utilisation en fonction de leur priorité.
Bien identifier les exigences et assurer leur traçabilité avec l’expression de besoins initiale du client.
Associer aux Cas d’utilisation les exigences non-fonctionnelles qui s’y rapportent.
Les Cas d’utilisation sont si possible répartis en ensembles (packages) faiblement couplés qui correspondent à l’architecture logique du système.
Page N° 49www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Analyse avec UML
L’approche MDA
Page N° 50www.objis.com
L’objectif de l ’analyse est double :
• affiner et consolider des Cas d ’utilisation,• modéliser les objets collaborant pour réaliser ces Cas d’utilisation.
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
Page N° 51www.objis.com
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.
Page N° 52www.objis.com
Un contrôleur est un objet responsable d’un ou plusieurs cas d'utilisation.
Pour un contrôleur, l’aspect comportemental est généralement prépondérant par rapport à l’aspect structural.
Le comportement d’un contrôleur est essentiellement « actif ».
Contrôleurs
Page N° 53www.objis.com
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 d’un acteur.
Un objet frontière définit un protocole d’échange d’événements; il peut mémoriser de l’information.
Frontières
Page N° 54www.objis.com
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
Page N° 55www.objis.com
Entités (2)
Pour les objets entités l’aspect structural est souvent prépondérant par rapport à l’aspect 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 ...
Page N° 56www.objis.com
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 n’est pas instanciable.
Un paquetage peut dépendre d’un autre paquetage. Les types de dépendances sont <<import>> ou <<access>>.
Page N° 57www.objis.com
PaquetagesPackage_2
Package_4
Package_7
Package_5
Package_6
Classe_2Classe_1
Classe_1a
Package_1
Package_6
<<import>>
<<access>>
<<import>>
Les éléments d’un paquetage sont visibles dans ses sous-paquetages
Page N° 58www.objis.com
Collaboration
Une collaboration est un regroupement de classes qui participent à la réalisation d’un Cas d’utilisation.
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
Page N° 59www.objis.com
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 d’un modèle objet se fait toujours de manière itérative.
A la fin de l’analyse, toutes les exigences des Cas d’utilisation doivent avoir été allouées aux classes.
Activité d’analyse
Page N° 60www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Analyse : concepts structuraux
L’approche MDA
Page N° 61www.objis.com
Diagrammes de classes
Nom de classeNom de classe
attribut1attribut:type or classeattribut:type or classe=i_valeur
« stéréotype »Nom de classe
attribut1attribut2:type or classattribut3:type or class=i_valeur
operation()operation(arg_list): résultat
Page N° 62www.objis.com
AttributsLes 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 classeattribut1 : type ou classe = val.défautattribut2 : type ou classe = val.défaut
Page N° 63www.objis.com
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 classeopération2 (param1 : type ou classe = val. défaut, ...) : type ou classe
Page N° 64www.objis.com
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 1 Class 2Association
name
Page N° 65www.objis.com
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 1 Classe 2Rôle
Rôle
Page N° 66www.objis.com
Cardinalité d'un rôle d’une association
La cardinalité d'un rôle d’une 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..5 3 à 52,4 2 ou 4
Plusieurs (0 ou plus)Optionnel (0 ou 1)Un ou plusCardinalité spécifiée
1..*
*0..1
n
1
Page N° 67www.objis.com
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 1 Classe 2
Attributs
Opérations
Page N° 68www.objis.com
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 BQualificatif
Page N° 69www.objis.com
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 d’un agrégat appartiennent à cet agrégat.
Agrégat Partie
*
*
Page N° 70www.objis.com
CompositeLa 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
Page N° 71www.objis.com
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) d’UML.
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,
– ...
Page N° 72www.objis.com
Spécialisation et généralisation
Les instances d’une 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 1 Subclass 2Multiple inheritance
discriminator
Page N° 73www.objis.com
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}.
Page N° 74www.objis.com
Classes paramétréesLes 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
Array <Point,3>
C, n
Page N° 75www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Analyse : concepts comportementaux
L’approche MDA
Page N° 76www.objis.com
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 d’un système.
Page N° 77www.objis.com
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 d’objets durant l'exécution de scénarios.
Un diagramme d’activités est un cas particulier de diagramme d’états qui sert à modéliser les interactions entre les acteurs, objets ou composants.
Page N° 78www.objis.com
Diagrammes d'étatsUn 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 l’aspect é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 d’utilisation.
Page N° 79www.objis.com
Etats et transitionsChaque état d'un objet représente une manière d'être qui conditionne sa réaction à des événements qu’il perçoit.
Une transition est la réponse d'un objet à un événement extérieur lorsqu’il 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 2nom d'événement (paramètres)
Un état est responsable de ses transitions sortantes.
Page N° 80www.objis.com
Transition propre
Transition qui mène au même état.
Page N° 81www.objis.com
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 1 Etat 2nom d'événement (paramètres) [condition]
Page N° 82www.objis.com
ActionsUne 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 d’exécution – qui peut être long - n’est pas significatif pour le comportement de l’objet modélisé.
Notation:
Etat 1 Etat 2événement (paramètres) / action (paramètres)
Page N° 83www.objis.com
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 n’est pas « responsable » de ses transitions entrantes.
Notation: Nom d'état
entry / action 1exit / action 2
Page N° 84www.objis.com
Activités
Une activité est une opération dont le temps d’exécution est significatif pour le comportement de l’objet 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 l’activité de l’état est terminée (transition automatique).
Nom d'étatdo / activité
Page N° 85www.objis.com
Transitions internes
Transitions qui se font à l'intérieur d'un état, s’intercalant 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
Page N° 86www.objis.com
Evénement différé
Un evénement différé (deferred event) dans un état est un événement qui n’est pris en compte que lorsque l’objet passe dans un autre état qui n’a pas lui-même différé cet événement.
Notation :State name
defer / event list
Page N° 87www.objis.com
Composition d'étatsLes é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 A31Etat A3
Etat A
Page N° 88www.objis.com
Pseudo-états séquentiels
[g2]
H
H*
Final
Point de choix
( Shallow ) Historique
( Deep ) Historique
Initial
Page N° 89www.objis.com
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.
Page N° 90www.objis.com
Parallélisme interneLes états orthogonaux (and-states) représentent des états indépendants qui peuvent s’exécuter en parallèle avec d’autres é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 x State qevent a event c
State yevent d
State zevent b
State 1
State 2
event k
And-state line
Page N° 91www.objis.com
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– …
Page N° 92www.objis.com
Fork et Join
A C D
X Yfork
join
B
F
événement 1
événement 1
Toutes les transitions menant à un pseudo-état Join doivent être déclenchées par le même événement.
Page N° 93www.objis.com
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 d’un événement émis par un autre objet.
Le temps s’écoule du haut vers le bas.
Page N° 94www.objis.com
Diagrammes de séquences
rôle1 rôle2 rôle3
Event X
return
return
b - a <= 10 ms
a
b
y
y ’ y ’ - y < 500 µs
50 ms ± 2 ms
Event Y
Page N° 95www.objis.com
Diagrammes de séquences (2)
Page N° 96www.objis.com
Diagramme de timing
Page N° 97www.objis.com
Diagrammes d’activitésActivité B0
Activité C1
Activité B1
Activité A1
Activité B2 Activité C2 Activité C3
Activité B3
Action C4
Action A2
événement e1
événement e2
[guarde1][guarde2]
Activité A3
a: A[état]
Page N° 98www.objis.com
Relations entre points de vueTous 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.
Page N° 99www.objis.com
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.
Page N° 100www.objis.com
Modèle d’exigences vs modèle d’analyse
Modèle d’exigences– Langage naturel structuré– Vue externe du système– Contrat entre le client et l’industriel– Décrit les fonctionnalités du système sous forme de paquets de Cas d’utilisation
Modèle d’analyse– Langage UML– Vue interne du système– Décrit le système en termes d’objets, d’états et d’événements–Structure le système en constituants logiques correspondant aux Cas d’utilisation (classes, sous-systèmes, composants, …)
Page N° 101www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Conception
L’approche MDA
Page N° 102www.objis.com
De l'analyse à la conception
La conception consiste à passer d'une modélisation logique du besoin à la construction physique d’une 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.
Page N° 103www.objis.com
Objectifs de la conceptionLa conception d’un 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
Page N° 104www.objis.com
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 l’exé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.
Page N° 105www.objis.com
Qu’est-ce qu’un 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
Page N° 106www.objis.com
InterfacesUne interface spécifie les opérations d’une classe ou d’un
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 d’interface 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.
Page N° 107www.objis.com
Interfaces et portsRequired
Interface
Provided
Interface
Page N° 108www.objis.com
Diagramme de structure composite
Page N° 109www.objis.com
Activités de conception
La conception fait intervenir deux niveaux d’activités :
– Conception d’architecture,– Conception détaillée.
Page N° 110www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Conception d’architecture
L’approche MDA
Page N° 111www.objis.com
Conception d’architectureL’objectif est de déterminer l’architecture 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 d’architecture 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.
Page N° 112www.objis.com
Qu’est-ce qu’une architecture ?
L’architecture d’un 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 l’architecture d’un système n’est pas une simple collection de ses parties (e.g. habituellement, une voiture n’est pas un tas de pièces !)
Page N° 113www.objis.com
Points de vue architecturauxQuelques uns des points de vue les plus utilisés :
– Logique : les constituants dérivent des exigences fonctionnelles.– Processus : s’inté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 d’un système et leurs collaborations.Les vues processus et physique sont cruciales pour raisonner en termes de performances, de disponibilité, de sécurité, ...
Page N° 114www.objis.com
Styles d’architecturesLes styles d’architectures correspondent à des principes généraux de conception d’un système visant à obtenir certaines qualités de service.
Généralement, un style d’architecture présente un ensemble de types de composants et de principes visant à contrôler leur comportement et/ou leurs échanges.
Exemples de styles d’architectures :– À 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, …)
– ...
Page N° 115www.objis.com
Style “Pipe and filter”Les composants sont des filtres
– Qui transforment les messages d’entré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”
FilterIFilter
FilterIFilter
FilterIFilter
Page N° 116www.objis.com
Style “Pipe and filter” (2)Avantages
– Comportement du système = somme des comportements des – Facilité d’ajout, 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 d’entreprise
Page N° 117www.objis.com
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 d’exploitation– Communications réseaux
Page N° 118www.objis.com
Exemple: HTTP
ApplicationLayer
TransportLayer
NetworkLayer
Data LinkLayer
PhysicalLayer
TCP HTTP Request
HTTP Request
IP TCP HTTP Request
Ethernet IP TCP HTTP Request
ApplicationLayer
TransportLayer
NetworkLayer
DataLinkLayer
PhysicalLayer
IHTTP
ITCP
IIP
IEthernet
BrowserFunctionsChaque couche communique
avec la couche voisine par une
interface, suivant un
certain protocole
Page N° 119www.objis.com
Style “Layered architectures” (3)Avantages
– Niveaux d’abstration 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 d’abstraction– En pratique, une couche peut être amenée à communiquer avec une
couche non adjacente
Page N° 120www.objis.com
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
Page N° 121www.objis.com
CodeRepository
ClassHierarchyView UMLView RawCodeView
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)
<<publish-subscribe>>
Page N° 122www.objis.com
Style “Blackboard” (3)Avantages
– Les clients relativement indépendants les uns des autres
– Les base de données sont indépendantes des clients
– L’intégration des données peut se faire à partir du blackboard
Page N° 123www.objis.com
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 à
l’utilisateur– Les composants “Controller” gérent les interactions avec l’utilisateur
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.
Page N° 124www.objis.com
Style “Model-view-controller” (2)Intérêts :
– Flexibilité (les évolutions de l’interface n’affecte pas les traitements de l’application)
– Possibilité d’ajouter des vues et des contrôleurs,
– Synchronisation des vues
Model
View Controller
State change
User gestures
View selection
State query
Change notification
Page N° 125www.objis.com
Style “Model-view-controller” (3)
Page N° 126www.objis.com
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
Page N° 127www.objis.com
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
Page N° 128www.objis.com
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
Page N° 129www.objis.com
Architecture un-tierLes 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.
Page N° 130www.objis.com
Architecture deux-tiers
DonnéesDonnées
IHMIHM
Présentation Présentation ++
partie du partie du traitementtraitement
Persistance Persistance ++
partie du partie du traitementtraitement
Page N° 131www.objis.com
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
Page N° 132www.objis.com
Architecture trois-tiers
IHMIHM DonnéesDonnées
Client lourdClient lourd
ApplicationApplication
TraitementTraitement
Client légerClient léger
Page N° 133www.objis.com
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
Page N° 134www.objis.com
Middleware
PlatformPlatform•Operating SystemOperating System•HardwareHardware
PlatformPlatform•Operating SystemOperating System•HardwareHardware
Business applicationBusiness application Business applicationBusiness application
MiddlewareMiddleware
Application Programming InterfacesApplication Programming Interfaces
Platform InterfacesPlatform Interfaces
Page N° 135www.objis.com
Objectif des middlewares
Transparence
Intéropérabilité
Portabilité
Intégrabilité et support de l'environnement
existant
Page N° 136www.objis.com
Transparence
Accès
Localisation
Persistance
Tolérance aux pannes
Réplication
Transactions
Page N° 137www.objis.com
Paradigmes de communication
Synchrone
– Remote Procedure Calls
– Invocation d'objets
Asynchrone
– Message Oriented Middleware
– Publish/Subscribe, Technologies événementielles
Page N° 138www.objis.com
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
Page N° 139www.objis.com
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)
Page N° 140www.objis.com
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 TPM Serveur avec TPM
1000 connexions1000 connexions1000 processus1000 processus
50 Gbytes de RAM50 Gbytes de RAM10 000 fichiers ouverts10 000 fichiers ouverts
TPMTPM
1000 clients 50 connexions partagées50 connexions partagées50 processus50 processus
2,5 Gbytes de RAM2,5 Gbytes de RAM500 fichiers ouverts500 fichiers ouverts
1000 clients 50 services
Page N° 141www.objis.com
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.
Page N° 142www.objis.com
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
Page N° 143www.objis.com
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
Page N° 144www.objis.com
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
Page N° 145www.objis.com
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, ...
Page N° 146www.objis.com
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, ...
Page N° 147www.objis.com
Architecture d'un Système
La couche business process utilise des règles pour enchaîner les interactions des composants
Business ProcessBusiness ProcessBusiness ProcessBusiness Process
Components/ServicesComponents/ServicesComponents/ServicesComponents/Services
MessagingMessagingMessagingMessaging
TransportTransportTransportTransport
Business rulesBusiness rulesWorkflowWorkflow
MQSeries, TIBCO, ...MQSeries, TIBCO, ...
CCM, J2EE, .NET, ...CCM, J2EE, .NET, ...
CORBA, DCOM,CORBA, DCOM,Java/RMI, ...Java/RMI, ...
Page N° 148www.objis.com
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
Page N° 149www.objis.com
Presentation
Browser
HTML_page
FormsInput elements
Server_pages
Active Server PagesJava servletsISAPINSAPICGIJava Server Pages
Web_server
Application_server
FormsInput elements
Active Server PagesJava servletsISAPINSAPICGIJava Server Pages
Client léger
Les composants majeurs du tier présentation résident sur le serveur Web
HTTP
Page N° 150www.objis.com
Client lourd
Les scripts et les modules sont exécutés sur le client
Presentation
Active Server PagesJava servletsISAPINSAPICGIJava Server Pages
Browser Web_server
Server_pagesHTML_page
FormsInput elementsJava appletsActiveX controlsJavaScriptVBScript
Application_server
FormsInput elementsJava appletsActiveX controlsJavaScriptVBScript
Active Server PagesJava servletsISAPINSAPICGIJava Server Pages
Page N° 151www.objis.com
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
Page N° 152www.objis.com
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
Page N° 153www.objis.com
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
Page N° 154www.objis.com
Modèle de déploiement
Décrit la distribution physique du système, c’est-à-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.
Page N° 155www.objis.com
DeploiementLe 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, l’architecte 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.
Page N° 156www.objis.com
Diagramme de déploiement
Noeud 3
« senseur »
Nœud 1Composant 2
« processeur »Noeud 2
Composant 3
Page N° 157www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Conception détaillée
L’approche MDA
Page N° 158www.objis.com
Qu’est-ce que la conception détaillée ?
Consiste à concevoir les classes de manière à ce qu’elles remplissent leur rôle dans les Cas d’utilisation 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),
Page N° 159www.objis.com
Conception détaillée
La conception détaillée des classes est faite en partant du modèle d’analyse et du modèle de conception d’architecture, en ajoutant des détails de réalisation (en UML).
La traçabilité est assurée par rapport au modèle d’analyse, mais certaines classes sont ajoutées en phase de conception.
Page N° 160www.objis.com
Diagrammes de collaborationUn diagramme de collaboration représente la réalisation d’un scenario d’un Cas d’utilisation 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 d’un message doit correspondre une opération dans l’interface de l’objet invoqué).
Page N° 161www.objis.com
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
Page N° 162www.objis.com
Diagramme de collaboration (exemple)
Page N° 163www.objis.com
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 d’efficacité.
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.
Page N° 164www.objis.com
Stéréotypes de synchronisationLes 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 ]
Page N° 165www.objis.com
Exemple
Page N° 166www.objis.com
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.
Page N° 167www.objis.com
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
Page N° 168www.objis.com
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
Page N° 169www.objis.com
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.
Page N° 170www.objis.com
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.
Page N° 171www.objis.com
Exemple : le profil Etat
traiter()
EtatFeuille
traiter ()
Contexte
Etat concret B
état courant
traiter ()
état courant -> traiter ()
Etat concret A
traiter ()
états possibles *
Page N° 172www.objis.com
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 d’analyse, la conception détaillée peut ajouter des attributs pour optimiser les performances.
Page N° 173www.objis.com
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 d’annotations : {ordered}, {set}, {hashed}, …
Les attributs ne devraient jamais être visibles de l’extérieur des objets.
Page N° 174www.objis.com
Visibilité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 l’objet 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 s’appliquent également aux opérations
Page N° 175www.objis.com
Conception des associations
Les associations entre objets permettent aux objets clients d’invoquer 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.
Page N° 176www.objis.com
Conception des associationsSi 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 d’exclusion mutuelle.
Page N° 177www.objis.com
Conception des opérations
La plupart du temps les opérations d’une 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, l’opération doit être visible, sinon la rendre inaccessible.
Page N° 178www.objis.com
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 d’activités peuvent être utiles dans certains cas.
Page N° 179www.objis.com
Points clés de la conceptionLe modèle de conception doit préserver si possible toute structure définie dans le modèle d’analyse, et sert lui-même de référence pour l’implé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.L’utilisation de profils de conception est fortement conseillée.
Page N° 180www.objis.com
Modèle d’analyse vs modèle de conception
Modèle d’analyse– 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 l’implé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 d’exploitation, les systèmes de gestion de bases de données, les interfaces graphiques, les technologies de gestion transactionnelle, …
Page N° 181www.objis.com
IntroductionProcessus de développementConcepts objets
UML et les activités de modélisation
Tests
L’approche MDA
Page N° 182www.objis.com
Plans de tests
Les plans de test doivent être rédigés en fin :
– d’analyse pour les tests de validation– de conception d'architecture pour les tests d'intégration– de conception détaillée pour les tests unitaires.
Page N° 183www.objis.com
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 »
Page N° 184www.objis.com
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
– …
Page N° 185www.objis.com
Test d’intégration et de validation
Les tests d’intégration sont menés au niveau des composants
Les tests de validation consistent à tester différents scénarios des cas d’utilisation, le système étant vu comme une boîte noire
Page N° 186www.objis.com
IntroductionProcessus de développementConcepts objetsUML et les activités de modélisation
L’approche MDA
Page N° 187www.objis.com
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).
Page N° 188www.objis.com
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
PIMPIMModelModel
MiddlewareMiddlewareAbstractionAbstraction
ExistingExistingMiddlewareMiddlewareServicesServices
Map
ping
Too
l
PSMPSMModelModel
Page N° 189www.objis.com
Points de vue MDA
ReqReqSpecif.Specif.
Prelim.Prelim.DesignDesign
DetailedDetailedDesignDesign
CodingCoding
ValidationValidation
IntegrationIntegration& Test& Test
UnitUnitTestTest
The classical V processThe classical V process
FunctionalFunctional reqs spec & reqs spec &
analysisanalysis
TechnicaTechnicall reqs reqs
spec & spec & analysisanalysisArchitecturalArchitectural
decisionsdecisions
RealisationRealisation
FunctionalFunctional reqs spec & analysisreqs spec & analysis Technical PIMTechnical PIM
reqs spec & analysisreqs spec & analysisArchitecturalArchitectural
decisionsdecisions
PIM designPIM design
Technical PSMTechnical PSM reqs spec & analysisreqs spec & analysisArchitecturalArchitectural
decisionsdecisions
RealisationRealisation
Page N° 190www.objis.com
Les plates formes dominantes actuelles CORBA, J2EE and .NET ont un grand nombre de concepts communs qui visent à favoriser l’utilisation 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 :– L’usage 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 d’analyse et de conception /
réalisation.
Page N° 191www.objis.com
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