Vous êtes sur la page 1sur 51

Les vues

Dr. Rim Negra 1


Rappel
• L’architecture d’un système est sa conception de haut niveau.
• N’importe quel système complexe est composé de sous-systèmes qui
interagissent entre eux.
• La conception de haut niveau est le processus qui consiste à
identifier ces sous-systèmes ainsi que les relations qu’il
entretiennent.
• L’architecture d’un système est le résultat de ce processus.

Dr. Rim Negra 2


Rappel
• L’architecture implique plusieurs choix dont les technologies, les
produits et les serveurs a utiliser.
• Il n’y a pas une architecture unique permettant de réaliser le
système, il y’a plusieurs,
• Le concepteur ou l'architecte tâchera de choisir la meilleure
architecture selon plusieurs critères dont la nature de projet, les
compétences de l’équipe, les budgets, et outils disponibles,…etc.

Dr. Rim Negra 3


Représentation des architectures
• Il existe plusieurs représentations graphiques des architectures.
• Une des représentations les plus utilisées est la représentation C&C:
Composant et Connecteurs.
• Un composant est un module logiciel (application, bibliothèque,
module, …etc.) ou un entrepôt de données (Base de données,
Système de fichiers,…etc.).
• Le connecteur représente les interactions entre les composants.
• La représentation C&C est un graphe contenant des graphes et des
connecteurs.

Dr. Rim Negra 4


Un composant
• Un composant est un module logiciel ou un entrepôt de données.
• Un composant est identifié par son nom qui indique son rôle dans le
système.
• Les composants communique entre eux en utilisant des ports (ou
interface).
• Les architectures utilisent des composants standards: Serveurs, Base
de données, application, clients,…etc

Dr. Rim Negra 5


Serveur et client
• Un serveur est un module logiciel qui repond aux requêtes d’autres
modules appelés clients.
• Généralement, les services et les clients sont hébergés dans des
machines différentes et communiquent via le réseau
(Intranet/Internet).
• Par exemple, le serveur http répond aux requêtes des clients qui sont
les navigateurs Web.

Dr. Rim Negra 6


Application
• Une application est un module logiciel qui a un rôle défini dans le
système logiciel.
• Par exemple, une application d’envoi de mails.

Dr. Rim Negra 7


Base de données
• Une base de données est un entrepôt stockant les données sous un
format normalisé.
• L’interrogation et la modification des données se fait en utilisant un
langage spéciale SQL.
• SQL server, Oracle,Mysql , sont des SGBD connus sur le marché.

Dr. Rim Negra 8


Vue C&C (Vue composant et connecteur)

Dr. Rim Negra 9


Connecteur
• Le connecteur modélise une interaction entre deux composants
• Un connecteur peut modéliser une interaction simple (appel de
procédure) ou une interaction complexe (par exemple utilisation d’un
protocole comme http)

Dr. Rim Negra 10


Exemple: Site JSP

Dr. Rim Negra 11


Vue Physique et Vue Logique
• La vue logique d’une architecture logicielle définit les principaux
composants d’une architecture sans se soucier des détails physiques
(équipements, machines, …etc.)
• La vue physique s’intéresse au déploiement physique des différents
services
• La vue physique est peu précise lors de la conception.
• Elle devient concrète lors de la phase de déploiement.

Dr. Rim Negra 12


Vue Physique et Vue Logique

Dr. Rim Negra 13


Vue Physique et Vue Logique

Dr. Rim Negra 14


UML et l’architecture logicielle
• Plusieurs formalismes peuvent décrire une architecture logicielle
• UML 2 est un bon moyen de représenter une architecture logicielle
• Le diagramme de composants peut servir à représenter la vue logique d’une
architecture
• Le diagramme de déploiement peut servir à représenter la vue physique
d’une architecture

Dr. Rim Negra 15


UML pour la description et la documentation d’une architecture logicielle

Dr. Rim Negra 16


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Structurels ou Diagrammes statiques (Structure
Diagram)
• Diagramme de classes (Class diagram): il représente les classes intervenants dans le système

• Diagramme d'objets (Object diagram): il sert à représenter les instances de classes (objets)
utilisées dans le système

• Diagramme de composants (Component diagram): il permet de montrer les composants du


système d'un point de vue logique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques,
bases de données...)

• Diagramme de déploiement: il sert à représenter les éléments matériels (ordinateurs,


périphériques, réseaux, systèmes de stockage...) et la manière dont les composants du
système sont répartis sur ces éléments matériels et interagissent avec eux

Dr. Rim Negra 17


UML pour la description et la documentation d’une
architecture logicielle
• Diagramme des paquetages (Package Diagram): permet de
représenter la hiérarchie des paquetages du projet, leur organisation
et leurs interdépendances, simplifie les diagrammes (donc plus simple
à comprendre)

• Diagramme de structures composites (Composite Structure


Diagram) : permet de décrire la structure interne d'un objet complexe
lors de son exécution (c'est à dire, décrire l'exécution du programme),
dont ses points d'interaction avec le reste du système

Dr. Rim Negra 18


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Comportementaux ou Diagrammes dynamiques
(BehaviorDiagram)
• Diagramme des cas d'utilisation (Use case diagram): il décrit les possibilités d'interaction
entre le système et les acteurs, c'est-à-dire toutes les fonctionnalités que doit fournir le
système
• Diagramme états-transitions (State Machine Diagram): il montre la manière dont l'état du
système (ou de sous-parties)est modifié en fonction des événements du système
• Diagramme d'activité (Activity Diagram): variante du diagramme d'états-transitions, il
permet de représenter le déclenchement d'événements en fonction des états du système et
de modéliser des comportements parallélisables (multithreads ou multi-processus)

Dr. Rim Negra 19


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Comportementaux ou Diagrammes dynamiques
(BehaviorDiagram)
• Diagramme des cas d'utilisation (Use case diagram): il décrit les possibilités
d'interaction entre le système et les acteurs, c'est-à-dire toutes les
fonctionnalités que doit fournir le système
• Diagramme états-transitions (State Machine Diagram): il montre la manière
dont l'état du système (ou de sous-parties)est modifié en fonction des
événements du système

Dr. Rim Negra 20


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Comportementaux ou Diagrammes dynamiques
(BehaviorDiagram)
• Diagramme d'activité (Activity Diagram): variante du diagramme
d'états-transitions, il permet de représenter le déclenchement
d'événements en fonction des états du système et de modéliser
des comportements parallélisables (multithreads ou multi-
processus)

Dr. Rim Negra 21


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Comportementaux ou Diagrammes dynamiques
(BehaviorDiagram)
• Diagramme d'interactions (Interaction Diagram):
• Diagramme de séquence (Sequence Diagram): la représentation
séquentielle du déroulement des traitements et des interactions entre les
éléments du système et/ou des acteurs.
• Diagramme de communication (Communication Diagram): la représentation
simplifiée d'un diagramme de séquence se concentrant sur les échanges de
messages entre les objets

Dr. Rim Negra 22


UML pour la description et la documentation d’une
architecture logicielle
• Diagrammes Comportementaux ou Diagrammes dynamiques
(BehaviorDiagram)
• Diagramme d'interactions (Interaction Diagram):
• Diagramme global d'interaction (Interaction Overview Diagram): variante du
diagramme d'activité où les noeuds sont des interactions, permet d'associer
les notations du diagramme de séquence à celle du diagramme d'activité, ce
qui permet de décrire une méthode complexe
• Diagramme de temps (Timing Diagram): la représentation des interactions où
l'aspect temporel est mis en valeur; il permet de modéliser les contraintes
d'interaction entre plusieurs objets, comme le changement d'état en réponse
à un évènement extérieur

Dr. Rim Negra 23


Le modèle 4 +1 de Kruchten
• Le modèle de Kruchten dit modèle des 4 + 1 vues est celui adopté
dans le Processus unifié (est une famille de méthodes de
développement de logiciels orientés objets.).
• le modèle d'analyse, mentionné vue des cas d'utilisation, constitue le
lien et motive la création de tous les diagrammes d'architecture.

Dr. Rim Negra 24


1. La vue des cas d'utilisation
• La vue des cas d'utilisation est un modèle d'analyse formalisé par Ivar
Jacobson.
• Un cas d'utilisation est défini comme un ensemble de scénarios
d'utilisation, chaque scénario représentant une séquence
d'interaction des utilisateurs (acteurs) avec le système.

• L'intérêt des cas d'utilisation est de piloter l'analyse par les exigences
des utilisateurs.
• Ceux-ci se sentent concernés car ils peuvent facilement comprendre les cas
d'utilisation qui les concernent.

Dr. Rim Negra 25


1. La vue des cas d'utilisation
• Cette méthode permet donc d'aider à formaliser les véritables
besoins et attentes des utilisateurs; leurs critiques et commentaires
étant les briques de la spécification du système.

• L'ensemble des cas d'utilisation du logiciel en cours de spécification


est représenté par un diagramme de cas d'utilisation, chacun des
scénarios de celui-ci étant décrit par un ou plusieurs diagrammes
dynamiques : diagrammes d'activités, de séquence, diagrammes de
communication ou d'états-transitions.

Dr. Rim Negra 26


2. La vue logique
• La vue logique constitue la principale description architecturale d'un
système informatique et beaucoup de petits projets se contentent de
cette seule vue.
• Cette vue décrit, de façon statique et dynamique, le système en
termes d'objets et de classes.
• La vue logique permet d'identifier les différents éléments et
mécanismes du système à réaliser.
• Elle permet de décomposer le système en abstractions et constitue le
coeur de la réutilisation.

Dr. Rim Negra 27


2. La vue logique
• L'architecte récupérera un maximum de composants des différentes
bibliothèques et cadriciels (framework) à sa disposition.
• La vue logique est représentée, principalement, par des diagrammes
statiques de classes et d'objets enrichis de descriptions dynamiques :
diagrammes d'activités, de séquence, diagrammes de communication
ou d'états-transitions.

Dr. Rim Negra 28


3. La vue des processus (comportement)
• La vue des processus décrit les interactions entre les différents
processus, threads (fils d'exécution) ou tâches
• Elle permet également d'exprimer la synchronisation et l'allocation
des objets.
• Cette vue permet avant tout de vérifier le respect des contraintes de
fiabilité, d'efficacité et de performances des systèmes multitâches.
• Les diagrammes utilisés dans la vue des processus sont exclusivement
dynamiques : diagrammes d'activités, de séquence, diagrammes de
communication ou d'états transitions.

Dr. Rim Negra 29


4. La vue de réalisation (implémentation)
• La vue de réalisation permet de visualiser l'organisation des
composants (bibliothèque dynamique et statique, code source...)
dans l'environnement de développement.
• Cette vue permet également de gérer la configuration (auteurs,
versions...).
• Les seuls diagrammes de cette vue sont les diagrammes de
composants

Dr. Rim Negra 30


5. La vue de déploiement
• La vue de déploiement représente le système dans son
environnement d'exécution.
• Elle traite des contraintes géographiques (distribution des
processeurs dans l'espace), des contraintes de bandes passantes, du
temps de réponse et des performances du système ainsi que de la
tolérance aux fautes et aux pannes. Cette vue est fort utile pour
l'installation et la maintenance régulière du système.
• Les diagrammes de cette vue sont les diagrammes de composants et
les diagrammes de déploiement.

Dr. Rim Negra 31


UML et Architecture logicielle
• Plusieurs formalismes peuvent décrire une architecture logicielle.
• UML2 est un bon moyen de représenter une architecture logicielle.
• Le diagramme de composants peut servir à représenter la vue logique
d’une architecture.
• Le diagramme déploiement permet de servir à représenter la vue
physique d’une architecture

Dr. Rim Negra 32


Diagramme de composants
• Un composant est une unité autonome dans un système.
• Un composant définit un système ou un sous système de n’importe
quel taille.
• Les diagrammes de composants permettent de modéliser les
composants et leurs interactions.
• Les composants d’un système sont facilement réutilisés ou remplacés.

Dr. Rim Negra 33


Diagramme de composants
• Montre la répartition physique du code
• Souvent répartis dans des paquetages
• Les relations s’expriment à travers leurs interfaces et des
dépendances

Dr. Rim Negra 34


Caractéristique d’un composant
• Un composant est une entité modulaire avec des interfaces bien
définies.
• Les interfaces définissent comment le composant peut être appelé ou
intégré.
• L’implémentation de composant est cachée aux entités externes.

Dr. Rim Negra 35


Représentation UML

Dr. Rim Negra 36


Caractéristique d’un composant
• Un composant a un nom unique.
• Un composant peut être étendu par un stréotype (subsystem,
database, executable, serveur, client,…)

Dr. Rim Negra 37


Exemples de stéréotypes

Dr. Rim Negra 38


Caractéristique d’un composant
• Un composant définit l’interface en terme d’interfaces fournies et
d’interfaces requises
• Une interface est une collection d’opérations ayant un lien
sémantique et qui n’ont pas d’implémentation.
• L’implémentation des interfaces se fait par une ou plusieurs classes
implémentant le composant.
• Les noms des interfaces commencent par I.
• Un contrat par C1 et C2 est défini quand C1 fournit une interface I est
requise par C2.

Dr. Rim Negra 39


Interface: Exemple

Dr. Rim Negra 40


Interface: Exemple

Dr. Rim Negra 41


Interface fournie
• Une interface fournie définie les fonctions qu’un composant pourrait
faire.
• Un exemple: un serveur web peut gérer les requêtes HTTP de type get
et post.

Dr. Rim Negra 42


Interface requise
• Définit la (les) interfaces que un composant attend de son
environnement.

Dr. Rim Negra 43


Assemblage
• Un assemblage entre deux composants est lorsqu’une même
interface est requise pour un composant et fournie par l’autre

Dr. Rim Negra 44


Utilisation
• Un composant C1 dépend d’un autre composant C2 lorsque C1
requiert C2 pour son implémentation (C1 appel un des services de C2)
• En d’autres mots, l’exécution de C1 requiert la présence de C2.

Dr. Rim Negra 45


Composition
• Un composant peut être lui-même composé par d’autres composants.
On parle alors de composition.
• Par exemple, le navigateur est composé de GetManager (gestionnaire
des requêtes get), PostManager( gestionnaire des requêtes post) et
Gui (interface).

Dr. Rim Negra 46


Délégation
• Un composant peut avoir des sous-composants qui incluent des
interfaces fournies ou des interfaces requises.
• La délégation consiste a transférer les interfaces/ requises du
composant interne vers le composant externe

Dr. Rim Negra 47


Délégation

Exemple 1

Dr. Rim Negra 48


Exemple

Dr. Rim Negra 49


Paquets
• Les paquets peuvent être utilisés dans les diagrammes de
composants pour organiser les composants

Dr. Rim Negra 50


Dr. Rim Negra 51

Vous aimerez peut-être aussi