Chapitre VI
Diagrammes physiques
1
Sommaire
Diagramme de packages
Diagramme de composants
Diagramme de déploiement
Architecture n-tiers
2
Diagramme de package (1)
java
IU Saisie des AWT
commande
Domaine
Application Saisie des
commande
Commandes Client
Interface de bas e de commun
données
g lo bal
3
Diagramme de packages (2)
Un paquetage est un regroupement de classes, d’interfaces et de
sous-paquetages.
Les liens de dépendance entre « IU saisie de commande » et « AWT »
indique que des classes du package « IU saisie de commande »,
contiennent des références à des composants du paquetage « AWT ».
Le nom complet du paquetage « AWT » pourrait être [Link]
Le package stéréotypé <<global>> signifie que tous les packages de
ce système ont une dépendance à ce package.
4
Règles de construction de packages
1. Les packages ne doivent pas être
mutuellement dépendant
2. Il ne doit y avoir des dépendances
circulaires entre les packages
5
Interaction entre un acteur et son
interface graphique
Un acteur s'adresse à une interface graphique
Une interface doit passer par un contrôleur pour agir sur
des entités
Stéréotypes
Classe avec le stéréotype <<boundary>>, qui sert à modéliser
les interactions entre le système et ses acteur.
classe avec le stéréotype <<control>> utilisée pour modéliser la
coordination, l’enchaînement et le contrôle d’autres objets, qui
sont en général reliées à un cas d’utilisation particulier
(composants graphiques)
<<entity>> : classe qui sert à modéliser des informations
durables et souvent persistantes.
Fenetre controleur entité
Sommaire
Diagramme de packages
Diagramme de composants
Diagramme de déploiement
Architecture n-tiers
8
Composant (définition)
Un composant est un élément physique qui
représente une partie implémentée d’un système qui
peut être:
Code source,
binaire ou exécutable,
un script, un fichier de commandes,
un fichier de données,
une table, etc.
9
Composant : exemple
Archivage
Fichier
Consultation
Il peut réaliser un ensemble d’interfaces qui définissent le
comportement offert à d’autres composants.
Diagramme de composants
Les diagrammes de composants décrivent les
composants et leurs dépendances dans l’environnement
de réalisation.
Les diagrammes de composants sont des vues statiques
de l’implémentation des systèmes qui montrent les choix
de réalisation.
En général, ils ne sont utilisés que pour des systèmes
complexes.
11
12
Stéréotypes
UML définit cinq stéréotypes standards qui s’appliquent
aux composants:
« document »
« exécutable »
« fichier »
« bibliothèque »
« table »
13
Les dépendances entre composants
Les relations de dépendance sont utilisées dans les
diagrammes de composants pour indiquer qu’un
élément d’implémentation d’un composant fait appel
aux services offerts par les éléments d’implémentation
d’un autre composant
14
Extension des stéréotypes de
composants
15
Stéréotype « Task … »
Les tâches correspondent à des composants qui
possèdent leur propre flot (thread en anglais) de
contrôle.
16
Sommaire
Diagramme de packages
Diagramme de composants
Diagramme de déploiement
Architecture n-tiers
17
Définition
Les diagrammes de déploiement montrent la
disposition physique des différents matériels – les
nœuds – qui entrent dans la composition d’un
système et la répartition des instances de
composants, qui « vivent » sur ces matériels.
18
Les noeuds
Chaque ressource matérielle est représentée par un
nœud.
En général, cette ressource possède au minimum de
la mémoire et parfois aussi des capacités de calcul.
19
Nœuds et composants
Les composants sont des éléments qui participent
à l’exécution d’un système alors que les nœuds
sont des éléments qui exécutent les composants.
Les composants représentent l’emballage physique
d’éléments logiques (exécutables etc.) alors que
les nœuds représentent le déploiement physique
des composants.
20
« support »
21
Les supports de communication
Les différents nœuds qui apparaissent dans le
diagramme de déploiement sont connectés entre eux
par des lignes qui symbolisent un support de
communication, à priori, bidirectionnel.
22
23
Sommaire
Diagramme de packages
Diagramme de composants
Diagramme de déploiement
Architecture n-tiers
24
Les 3 niveaux d’abstraction d’une
application (1)
1. La couche de présentation (IHM), permet
l’interaction avec l’utilisateur. Cette couche gère:
La saisie
La présentations à l’écran
2. La logique applicative (les traitements)
Contrôle et aide à la saisie (traitements locaux)
Logique métier, qui contient les règles internes à
l’entreprise (traitements globaux)
3. Les données, regroupant l’ensemble des
mécanismes pour la gestion des informations
stockées par l’application
Les 3 niveaux d’abstraction d’une
application (2)
Les 3 niveaux peuvent être imbriqués ou répartis
entre plusieurs machines physiques
Le noyau de l’application est composé de:
Logique présentation
Logique des traitements
Le découpage et la répartition de ce noyau
permettent de distinguer des architectures
applicatives qui vont 1-tiers à n-tiers
26
Architecture 3-tiers
L’architecture 3-tiers applique les
principes suivants:
La présentation est toujours prise en
charge par le poste client
La logique applicative est prise en charge
par serveur intermédiaire
Les données sont toujours gérées de façon
centralisée
27
Architecture 3-tiers
Serveur Base de
Client d’application données
Présentation Logique applicative Donnée/ressources
28
Architecture n-tiers (n>3)
L’architecture qualifie la distribution de l’application
entre plusieurs services et non à la multiplication des
niveaux
Les 3 niveaux d’abstraction sont toujours prix en
compte
29
Modèles UML