Formation UML. Page N° 2 Introduction Processus de développement Concepts objets UML et les...

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


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


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


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.


Introduction

Processus de développement

Concepts objetsUML et les activités de modélisationL’approche MDA


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


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.


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.


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


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


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.


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


Processus récursif

Le processus de développement est appliqué récursivement à différents niveaux :

– système, – sous-systèmes, – composants,…


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.


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.


IntroductionProcessus de développement objet

Concepts objets

UML et les activités de modélisationL’approche MDA


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.


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.


Structure d’un objet

Un objet non primitif est une structure faite d’autres objets (ses composants).


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, …).


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.


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


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)


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.


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.


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).


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, ...).


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.


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.


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.


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


IntroductionProcessus de développement objetConcepts objets

UML et les activités de modélisation

L’approche MDA


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.


Les quatre niveaux de modélisation


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.


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, …).


IntroductionProcessus de développementConcepts objets


Modélisation des exigences avec UML

L’approche MDA


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


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.


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 ».


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).


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


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


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


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


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


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.




Analyse avec UML

L’approche MDA


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


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.


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


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


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


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 ...


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>>.


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


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


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




Analyse : concepts structuraux

L’approche MDA


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


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


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


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


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


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


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


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


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

*

*


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


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,

– ...


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


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}.


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




Analyse : concepts comportementaux

L’approche MDA


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.


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.


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.


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.


Transition propre

Transition qui mène au même état.


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]


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)


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


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é


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


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


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


Pseudo-états séquentiels

[g2]

H

H*

Final

Point de choix

( Shallow ) Historique

( Deep ) Historique

Initial


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.


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


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– …


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.


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.


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


Diagrammes de séquences (2)


Diagramme de timing


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]


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.


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.


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, …)




Conception

L’approche MDA


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.


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


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.


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


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.


Interfaces et portsRequired

Interface

Provided

Interface


Diagramme de structure composite


Activités de conception

La conception fait intervenir deux niveaux d’activités :

– Conception d’architecture,– Conception détaillée.




Conception d’architecture

L’approche MDA


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.


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 !)


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é, ...


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, …)

– ...


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


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


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


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


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


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


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>>


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


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.


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


Style “Model-view-controller” (3)


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


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


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


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.


Architecture deux-tiers

DonnéesDonnées

IHMIHM

Présentation Présentation ++

partie du partie du traitementtraitement

Persistance Persistance ++

partie du partie du traitementtraitement


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


Architecture trois-tiers

IHMIHM DonnéesDonnées

Client lourdClient lourd

ApplicationApplication

TraitementTraitement

Client légerClient léger


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


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


Objectif des middlewares

Transparence

Intéropérabilité

Portabilité

Intégrabilité et support de l'environnement

existant


Transparence

Accès

Localisation

Persistance

Tolérance aux pannes

Réplication

Transactions


Paradigmes de communication

Synchrone

– Remote Procedure Calls

– Invocation d'objets

Asynchrone

– Message Oriented Middleware

– Publish/Subscribe, Technologies événementielles


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


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)


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


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.


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


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


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


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, ...


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, ...


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, ...


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


Presentation

Browser

HTML_page

FormsInput elements

Server_pages

Active Server PagesJava servletsISAPINSAPICGIJava Server Pages

Web_server

Application_server

FormsInput elements


Client léger

Les composants majeurs du tier présentation résident sur le serveur Web

HTTP


Client lourd

Les scripts et les modules sont exécutés sur le client

Presentation


Browser Web_server

Server_pagesHTML_page

FormsInput elementsJava appletsActiveX controlsJavaScriptVBScript

Application_server

FormsInput elementsJava appletsActiveX controlsJavaScriptVBScript



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


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


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


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.


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.


Diagramme de déploiement

Noeud 3

« senseur »

Nœud 1Composant 2

« processeur »Noeud 2

Composant 3




Conception détaillée

L’approche MDA


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),


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.


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é).


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


Diagramme de collaboration (exemple)


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.


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 ]


Exemple


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.


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


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


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.


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.


Exemple : le profil Etat

traiter()

EtatFeuille

traiter ()

Contexte

Etat concret B

état courant

traiter ()

état courant -> traiter ()

Etat concret A

traiter ()

états possibles *


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.


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.


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


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.


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.


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.


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.


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.


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, …




Tests

L’approche MDA


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.


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 »


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

– …


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


IntroductionProcessus de développementConcepts objetsUML et les activités de modélisation

L’approche MDA


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).


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


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


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.


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

Formation UML. Page N° 2 Introduction Processus de développement Concepts objets UML et les...

Documents

Transcript of Formation UML. Page N° 2 Introduction Processus de développement Concepts objets UML et les...