Partie 2 Chap 4 Conception Et Analyse UML (Pr. Mansour)

Diagrammes structurels (suite)
Chapitre 4
I. DIAGRAMME DE COMPOSANT (DCP)
1. Présentation générale
 Le diagramme de composant permet de représenter les composants logiciels

d’un système ainsi que les liens existant entre ces composants.
 Les composants logiciels peuvent être de deux origines : soit des composants
métiers propres à une entreprise soit des composants disponibles sur le
marché comme par exemple les composants EJB, CORBA, .NET, WSDL.
Chapitre 4
DIAGRAMMES STRUCTURELS (SUITE)
Professeur HAMID MANSOUR FPE-ERRACHIDIA 2019-2020 110 Professeur HAMID MANSOUR FPE-ERRACHIDIA 2019-2020 111
Diagrammes structurels (suite) Diagrammes structurels (suite)
Chapitre 4
Chapitre 4
I. DIAGRAMME DE COMPOSANT (DCP) I. DIAGRAMME DE COMPOSANT (DCP)
1. 2. Composant 1. 3. Les deux types de représentation
 Chaque composant est assimilé à un élément exécutable du système. Il est Représentation « boîte noire »
caractérisé par : • C’est une vue externe du composant qui présente ses interfaces fournies
• un nom ; et requises sans entrer dans le détail de l’implémentation du composant.
• une spécification externe sous forme soit d’une ou plusieurs interfaces • Une interface requise est une interface nécessaire au bon fonctionnement
requises, soit d’une ou plusieurs interfaces fournies; du composant.
• un port de connexion.
• Une interface fournie est une interface proposée par le composant aux
Formalisme: autres composants.
 Exp1 : Connecteurs d’assemblage:
 Un composant est représenté par un classeur avec le mot-clé « composant »
ou bien par un classeur comportant une icône représentant un module.
Chapitre 4
Chapitre 4
1. 3. Les deux types de représentation 1. 3. Les deux types de représentation
Représentation « boîte noire » Représentation « boîte noire »
 Exp2 : Connecteurs d’interface:  Exp3 : Compartiment
 pour une interface fournie, c’est une relation de réalisation partant du  Une dernière manière de modéliser un composant avec une
composant et allant vers l’interface ; représentation boîte noire est de décrire sous forme textuelle les
interfaces fournies et requises à l’intérieur d’un second compartiment.
 pour une interface requise, c’est une dépendance avec le mot-clé «utilise»
partant du composant et allant vers l’interface.
Chapitre 4
Chapitre 4
1. 3. Les deux types de représentation 1. 3. Les deux types de représentation
Représentation « boîte Blanche» Représentation « boîte Blanche»
 Exp2 : Dépendance
 C’est une vue interne du composant qui décrit son implémentation à l’aide de
classificateurs (classes, autres composants) qui le composent.  les classificateurs qui composent le composant sont reliés à celui-ci par
une relation de dépendance.
 Exp1 : Compartiment
 Les relations entre les classificateurs (association, composition,
agrégation) sont aussi modélisées.
Chapitre 4
Chapitre 4
I. DIAGRAMME DE COMPOSANT (DCP)
1. 3. Les deux types de représentation II. DIAGRAMME DE DÉPLOIEMENT (DPL)
Représentation « boîte Blanche» 1. Présentation générale
 Exp3 : Ports et connecteurs
 Le diagramme de déploiement permet de représenter l’architecture physique
 Le port est représenté par un petit carré sur le composant. Les
supportant l’exploitation du système.
connecteurs permettent de relier les ports aux classificateurs. Ils sont
représentés par une association navigable
 Cette architecture comprend des nœuds correspondant aux supports
physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels
(bibliothèques, exécutables…) sur ces nœuds.
Chapitre 4
Chapitre 4
II. DIAGRAMME DE DÉPLOIEMENT (DPL) II. DIAGRAMME DE DÉPLOIEMENT (DPL)
2. Nœud 2. Nœud
 Un nœud correspond à une ressource matérielle de traitement sur laquelle Types de nœuds en UML:
des artefacts seront mis en œuvre pour l’exploitation du système.
 Unité de traitement – Ce nœud est une unité physique disposant de
capacité de traitement sur laquelle des artefacts peuvent être déployés.
 Les nœuds peuvent être interconnectés pour former un réseau d’éléments mot-clé « device ».
physiques.
 Environnement d’exécution – Ce nœud représente un environnement
Formalisme : d’exécution particulier sur lequel certains artefacts peuvent être exécutés.
mot clé « executionEnvironment ».
 Un nœud ou une instance de nœud se représente par un cube ou
parallélépipède
Chapitre 4
Chapitre 4
3. Artefact 4. Spécification de déploiement
 Un artefact est la spécification d’un élément physique qui est utilisé ou  Une spécification de déploiement peut être associée à chaque artefact.
produit par le processus de développement du logiciel ou par le déploiement
du système. C’est donc un élément concret comme par exemple : un fichier,  Elle permet de préciser les conditions de déploiement de l’artefact sur le
un exécutable ou une table d’une base de données. nœud sur lequel il va être implanté.
Formalisme : Formalisme :
 Un artefact se représente par un rectangle caractérisé par le mot-clé  Une spécification de déploiement se représente par un rectangle avec le mot-
«artifact» et/ou une icône particulière dans le coin droit du rectangle. clé « deployment spec »
Chapitre 4
Chapitre 4
5. Liens entre un artefact et les autres éléments du diagramme Exercice:

implémentation d’une architecture J2EE avec quatre nœuds est donné :
 Un serveur web où se trouvent les éléments statiques du site dans une archive :
représentation inclusive d’artefact représentation d’artefact avec lien
images, feuilles de style, pages html (static.zip).
de dépendance
 Un serveur d’application « front » sur le lequel est déployée l’archive « front.ear »
composée de l’application web « front.war » et d’autres composants nécessaires au
fonctionnement de cette archive web comme « clientejb.jar » (classes permettant
l’appel aux EJB) et « commun.jar » (classes communes aux deux serveurs
d’application).
 Un serveur d’application métier sur lequel sont déployés les composants :
«ejb.jar». Ils sont packagés dans l’archive « metier.ear ». Deux autres archives sont
nécessaires au fonctionnement des EJB : « dao.jar » (classes qui permettent l’accès
à la base de données) et « commun.jar » (classes communes aux deux serveurs
d’application).
 Un serveur BDD (base de données) sur lequel sont stockées des procédures
stockées PL/SQL : « scripts.sql ».
Chapitre 4
Chapitre 4
III. DIAGRAMME DE PAQUETAGE (DPA)
1. Paquetage
 Un paquetage regroupe des éléments de la modélisation appelés aussi

membres, portant sur un sous-ensemble du système.
 Le découpage en paquetage doit traduire un découpage logique du système à

construire qui corresponde à des homogènes. espaces de nommage
 Les éléments d’un paquetage peuvent avoir une visibilité déclarée soit de type
public (+) soit privé (-).
 Un paquetage peut importer des éléments d’un autre paquetage. Un

paquetage peut être fusionné avec un autre paquetage.
Chapitre 4
Chapitre 4
III. DIAGRAMME DE PAQUETAGE (DPA) III. DIAGRAMME DE PAQUETAGE (DPA)
1. Paquetage 2. Utilisation des packages
 Un package  Organiser
 Un nom  Introduire des niveaux d’abstraction
 Structurer en couches
 Contient des diagrammes  Découper un problème en sous-problèmes
 Dont d’autres packages  Découper en sous-systèmes
 Interfaces et comportement
 Peut importer des packages  Structurer pour réutiliser et pour comprendre
 Peut posséder des interfaces  Unités logiques
 Unités homogènes
 Règles de nommage
 Vision claire des dépendances
 Un package = un espace de noms  Maintenance des diagrammes
 Maintenance du code
Chapitre 4
Chapitre 4
3. Règles de construction des packages 4. Formalisme
 Nommage  Représentation globale – Le nom du paquetage se trouve à l’intérieur du

 Cohérent grand rectangle.
 Unicité des noms au sein du package
 Regroupement logique  Représentation détaillée – Les membres du paquetage sont représentés et le
nom du paquetage d’ensemble s’inscrit dans le petit rectangle.
 Un changement impacte les éléments d’un package
 Les éléments sont réutilisés ensemble
 Représentation éclatée – Les membres du paquetage sont reliés par un lien
 Faible couplage connecté au paquetage par le symbole ⊕.
 Les éléments peuvent utiliser d’autres notions définis dans d’autres
packages mais leur définition est indépendante des autres packages
 Simplicité
 Un package contient au maximum 10 éléments
 Utiliser la hiérarchie
Chapitre 4
Chapitre 4
3. Formalisme Exemple
Chapitre 4
Chapitre 4
5. Dépendance entre paquetages Exemple
 La dépendance entre paquetages peut être qualifiée par un niveau de visibilité

qui est soit public soit privé. Par défaut le type de visibilité est public.
 À chaque type de visibilité est associé un lien de dépendance. Les deux types
de dépendances entre paquetages sont :
 « import » – tous les membres du paquetage donné ont accès à tous les
noms des membres du paquetage importé.
 les éléments de Clients externes sont importés dans Domaine client et
 « access » – L’espace de nommage n’est donc pas importé et ne peut être ensuite dans Domaine tiers. Cependant, les éléments de Clients internes sont
transmis à d’autres paquetages par transitivité. seulement accessibles par le paquetage Domaine client et donc pas à partir
du paquetage Domaine tiers.
Chapitre 4
Chapitre 4
III. DIAGRAMME DE PAQUETAGE (DPA) IV. DIAGRAMME DE STRUCTURE COMPOSITE (DSC)
5. fusion entre paquetages. 1. Généralités
 Le lien de dépendance comporte dans ce cas le mot-clé « merge ».  Le diagramme de structure composite permet de décrire des collaborations
d’instances (de classes, de composants…) constituant des fonctions
particulières du système à développer.
 Une collaboration représente un assemblage de rôles d’éléments qui

interagissent en vue de réaliser une fonction donnée.
 Il existe deux manières de représenter une collaboration :
 représentation par une collaboration de rôles,
 représentation par une structure composite : le diagramme de structure

composite.
Chapitre 4
Chapitre 4
IV. DIAGRAMME DE STRUCTURE COMPOSITE (DSC) IV. DIAGRAMME DE STRUCTURE COMPOSITE (DSC)
2. Représentation par une collaboration de rôles 3. Représentation par un diagramme de structure composite
 une collaboration est formalisée par une ellipse en pointillé dans laquelle on  la collaboration représentée par une ellipse en pointillé ;
fait figurer les rôles des éléments qui interagissent en vue de réaliser la
fonction souhaitée.  les éléments participant à la collaboration (classe, composant…) représentés à
l’extérieur de la collaboration ;
 les rôles considérés dans chaque participation représentés sur les liens entre
les éléments participants et la collaboration.
 Dans cet exemple, la fonction Persistance objets métier résulte d’une

collaboration entre deux rôles d’éléments :
 mapping : classeMétier,
 stockage : tableBDD.
Chapitre 4
IV. DIAGRAMME DE STRUCTURE COMPOSITE (DSC)
Exemple
Professeur HAMID MANSOUR FPE-ERRACHIDIA 2019-2020 140

Partie 2 Chap 4 Conception Et Analyse UML (Pr. Mansour)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Partie 2 Chap 4 Conception Et Analyse UML (Pr. Mansour)

Transféré par

Droits d'auteur :

Formats disponibles

Diagrammes structurels (suite)

 Le diagramme de composant permet de représenter les composants logiciels

Diagrammes structurels (suite) Diagrammes structurels (suite)

Diagrammes structurels (suite) Diagrammes structurels (suite)

Diagrammes structurels (suite) Diagrammes structurels (suite)

Diagrammes structurels (suite) Diagrammes structurels (suite)

5. Liens entre un artefact et les autres éléments du diagramme Exercice:

 Un paquetage regroupe des éléments de la modélisation appelés aussi

 Le découpage en paquetage doit traduire un découpage logique du système à

 Un paquetage peut importer des éléments d’un autre paquetage. Un

Diagrammes structurels (suite) Diagrammes structurels (suite)

 Nommage  Représentation globale – Le nom du paquetage se trouve à l’intérieur du

Diagrammes structurels (suite) Diagrammes structurels (suite)

 La dépendance entre paquetages peut être qualifiée par un niveau de visibilité

Diagrammes structurels (suite) Diagrammes structurels (suite)

 Une collaboration représente un assemblage de rôles d’éléments qui

 Il existe deux manières de représenter une collaboration :

 représentation par une collaboration de rôles,

 représentation par une structure composite : le diagramme de structure

 Dans cet exemple, la fonction Persistance objets métier résulte d’une

Diagrammes structurels (suite)

Professeur HAMID MANSOUR FPE-ERRACHIDIA 2019-2020 140

Vous aimerez peut-être aussi