Foutse Khomh

© Guéhéneuc, 2009; Khomh, 2010Département de génie informatique et de génie logicielÉcole Polytechnique de Montréal

LOG4430 :Architecture logicielle et

conception avancée

Architectures – Partie 2/2

2/19

5. Développer un modèle architectural Commencer par faire une esquisse de l’architecture

– En se basant sur les principaux requis des cas d’utilisation ; décomposition en sous-systèmes

– Déterminer les principaux composants requis

– Sélectionner un style architectural Raffiner l’architecture

– Identifier les principales interactions entre les composants et les interfaces requises

– Décider comment chaque donnée et chaque fonctionnalité sera distribuée parmi les différents composants

– Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si on peut en construire un (réutilisabilité)

Considérer chacun des cas d’utilisation et ajuster l’architecture pour qu’il soit réalisable

Détailler l’architecture et la faire évoluer

3/19

Développer un modèle architectural

Commencer par faire une esquisse de l’architecture– En se basant sur les principaux requis des cas d’utilisation ; décomposition

en sous-systèmes

– Déterminer les principaux composants requis

– Sélectionner un style architectural Raffiner l’architecture

– Identifier les principales interactions entre les composants et les interfaces requises

– Décider comment chaque donnée et chaque fonctionnalité sera distribuée parmi les différents composants

– Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si on peut en construire un (réutilisabilité).

Considérer chacun des cas d’utilisation et ajuster l’architecture pour qu’il soit réalisable

Détailler l’architecture et la faire évoluer

4/19

Développer un modèle architectural

Décrire l’architecture avec UML– Tous les diagrammes UML peuvent être utiles

pour décrire les différents aspects du modèle architectural

– Trois des diagrammes UML sont particulièrement utile pour décrire une architecture logicielle

• Diagramme de packages• Diagramme de composants• Diagramme de déploiement

5/19

Développer un modèle architectural

Diagramme de packages– Paquetage = Collection d’éléments de modélisation UML (e.g.,

classes, use cases, etc.) groupés ensemble car liés logiquement– Il faut essayer de maximiser la cohésion au sein des paquetages

(éléments liés) et minimiser le couplage entre eux

Dépendance : un paquetage est dépendant d’un autre s’il l’utilise…

SimpleChat

ClientCommon

OCSF

ClientServer

<<import>>

6/19

Développer un modèle architectural

Diagramme de composants– Offre une vue de haut niveau de l’architecture du

système– Utilisé pour décrire le système d’un point de vue

implémentation– Permet de décrire les composants d’un système et les

interactions entre ceux-ci– Illustre comment grouper concrètement et physiquement

les éléments (objets, interfaces, etc.) du système au sein de modules qu’on appelle composants

7/19

Développer un modèle architectural

Qu’est-ce qu’un composant?– Unité autonome faisant partie d’un

système ou d’un sous-système qui encapsule un comportement (i.e., implémentation) et qui offre une ou plusieurs interfaces publiques

– Partie constituante d’un système qui peut être remplacée ou/et réutilisée

– Élément d’implémentation (un sous-système, un fichier exécutable, une classe d’implémentation (i.e., non abstraite, etc.) muni d’interface(s)

– Chaque composant est le représentant d’une ou plusieurs classes qui implémentent un service à l’intérieur du système

– Granularité ? Un composant peut représenter quelque chose d’aussi fin qu’un objet, comme il peut représenter un sous-système complexe

– Différence entre composant et instance de composant

– Composant : vue de haut niveau d’un élément logiciel qui compose le système (~classe)

– Instance de composant : le composant effectivement utilisé (~objet)

– Exemples de composants:• Binaire exécutable (<<executable>>),

bibliotheque dynamique/statique (<<librairy>>), un fichier à interpréter (<<file>>)…

Composant

8/19

Développer un modèle architectural

Les composants et le principe de séparation des préoccupations– La séparation des préoccupation est le principe qui assure l’intégrité

fonctionnelle d’un composant• Chaque composant réalise une, et seulement une fonction au sein du

système, mais peut néanmoins exposer plusieurs méthodes. Typiquement, chaque composant est défini par une interface qui constitue son seul moyen d’interagir avec les autres composants

• L’utilisation d’une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu’on peut alors en changer l’implémentation sans affecter les autres composants (induit un couplage plus faible du composant avec le reste du système)

• Les classes d’un composant devrait être vues comme un patron cohésif qui implémente la fonctionnalité du composant

9/19

Développer un modèle architectural

Composants et interfaces - Notation

Commande

EntréeCmdes

PaiementComptes

Personne

composantinterface requise interfaces offertes

Commande

<<provided interfaces>> EntréeCmdes PaiementComptes<<required interface>> Person

10/19

Développer un modèle architectural

Composants et relations – notation– Une flèche de dépendance permet de mettre en relation

des composant via les interfaces requises et fournies

Système de commande

AccèsProduit

RechercheClient

Système d’inventaire

RepositoireClients

RechercheClient

AccèsProduit

(3) dépendance

(1) composant

(2) interface

11/19

Développer un modèle architectural

Composants et relations – notation

Planificateur

réservations

GUI

Gestionnaired’horaires

réservations

mise à jour

mise à jour

Réunions_BD

accèsBD

accèsBD

12/19

Développer un modèle architectural

Composants – Vue de la structure interne– Pour montrer la structure interne d’un composant

:Commande

Personne

:Produit

:Client

ItemCommandable

Magasin

EntréeCmdes

<<delegate>>

Compte

Compte

EntréeCmdes

<<delegate>>

port

Assemblyconnector

Entête

LigneCmde*

13/19

Développer un modèle architectural Diagramme de composants MVC

14/19

Développer un modèle architectural

La Bouquinerie (c.f. démo 9)– Architecture 3-niveaux (client plus lourd que

dans la version 4-niveaux)– Architecture 4-niveaux (version web, basée sur

la technologie JSP)– Remarque : les interfaces n’apparaissent pas

toutes sur les diagrammes

15/19

Développer un modèle architectural

Construction d’un diagramme de composants– Diviser pour régner– Cohésion forte– Faible couplage– Abstraction– Réutilisabilité– Réutilisation– Etc.

16/19

Développer un modèle architectural

Diagramme de déploiement

GPS satellite

M1:MachineX

M2:MachineX

C1:Client

C2:Client

S:Serveur

Communication sans fil

TCP/IP

noeuds

lien

17/19

Machine de Joe:PC

Développer un modèle architectural

Diagramme de déploiement – exemple 1

:Planificateur

GUI

mise à jour

Admin:MachineHote

:Gestionnaire Horaires

:Réunions_BD

réservations

Accès_bd

internet

18/19

Développer un modèle architectural

Diagramme de déploiement – exemple 2

19/19

Parmi les objectifs d’apprentissage

Expliquer les objectifs visés par la conception architecturale– Décrire le fonctionnement et les caractéristiques de

chacun des styles architecturaux– Justifier le choix d’une architecture pour la réalisation d’un

logiciel, en tenant compte de ses exigences fonctionnelles et non fonctionnelles

– Définir ce qu’est un composant– Expliquer le contenu décrit par un diagramme de

paquetages, de composants et de déploiement (UML)– Décrire le modèle d’une architecture avec la notation UML