a Run-Time View (ou vue d'exécution) se concentre sur le comportement dynamique du
système pendant son fonctionnement, c'est-à-dire
lorsqu'il est en cours d'exé[Link] montre comment les composants interagissent
en temps réel pour réaliser des fonctionnalités
spécifiques
Diagrammes utilisés :
Diagramme de séquence : Montre l'ordre des interactions entre les objets ou les
composants dans un scénario donné.
La Deployment View (ou vue de déploiement) se concentre sur l'infrastructure
matérielle et logicielle requise pour héberger le système.
Elle montre comment les composants logiciels sont distribués sur les ressources
matérielles, comme les serveurs, les réseaux et les bases
de données.
Diagrammes utilisés :
Diagramme de déploiement : Représente les nœuds matériels (serveurs, machines
virtuelles) et les composants logiciels déployés sur ces
nœuds. Il montre aussi les connexions réseau entre les différents nœuds.
3. Building Block View (Vue des blocs de construction)
La Building Block View (ou vue des blocs de construction) se concentre sur la
structure
interne du système, en décrivant les composants logiciels principaux et leurs
responsabilités.
Diagrammes utilisés :
Diagramme de composants : Représente les modules ou composants du système et leurs
interactions.
Diagramme de classes : Utilisé pour détailler les classes et les relations entre
elles dans chaque module.
La Context View (ou vue de contexte) présente le système dans son ensemble et
décrit la manière dont il interagit avec son environnement.
Cette vue montre les acteurs externes (utilisateurs, autres systèmes) qui
interagissent avec le système
Diagrammes utilisés :
Diagramme de contexte : Montre le système comme un "boîte noire" avec ses relations
avec les systèmes externes, utilisateurs et autres
parties prenantes.
Diagramme de cas d'utilisation : Peut également être utilisé pour décrire les
interactions de haut niveau entre les utilisateurs (acteurs)
et les fonctionnalités principales du système.
L'arbre FCM (Facteur - Critère - Métrique) est un modèle de qualité utilisé pour
évaluer les caractéristiques de qualité d'un système
logiciel.
Facteurs - Criteres - Metriques
avantages : Clareté Mesurabilite facilité d'évaluation
1. Building Block View (Vue des blocs de construction)
La Building Block View est une représentation de l’architecture logicielle qui
décrit la structure interne d’un système sous forme de blocs
fonctionnels. Chaque bloc représente un composant ou un sous-système ayant une
responsabilité spécifique et interagit avec d'autres blocs.
Boîte Noire (Black Box)
Définition : Dans une vue en boîte noire, l'accent est mis uniquement sur les
entrées, sorties, et comportements externes d'un composant
ou d'un système, sans exposer la logique interne.
Boîte Blanche (White Box)
Définition : Une vue en boîte blanche dévoile l'intérieur du composant, y compris
sa structure, sa logique, et ses interactions internes.
Critères d'évaluation :
Performance ,Scalabilité,Fiabilité et Disponibilité,Sécurité
S : Single Responsibility Principle (Principe de Responsabilité Unique)
Chaque classe doit avoir une seule responsabilité, c'est-à-dire une seule raison de
changer.
Les entités logicielles (classes, modules, fonctions) doivent être ouvertes à
l'extension mais fermées à la modification.
L : Liskov Substitution Principle (Principe de Substitution de Liskov)
Les objets d'une classe dérivée doivent pouvoir remplacer des objets de la classe
de base sans altérer le bon fonctionnement du programme. Autrement dit, les sous-
classes doivent respecter le contrat établi par la classe parente.
I : Interface Segregation Principle (Principe de Ségrégation des Interfaces)
Il vaut mieux avoir plusieurs interfaces spécifiques, qui répondent chacune à un
besoin particulier, plutôt qu’une seule interface générale.
D : Dependency Inversion Principle (Principe d'Inversion des Dépendances)
Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau, mais
plutôt d’abstractions.
Stimulus
Dans l'architecture logicielle, un stimulus est un élément déclencheur ou un
événement qui provoque une réaction du système
Rôles et Responsabilités de l'Architecte
Conception de l'Architecture :
Définition des Standards et Bonnes Pratiques :
Collaboration avec les Parties Prenantes :
Évaluation des Risques :
Supervision et Suivi de l’Implémentation :
Évaluation et Validation de l'Architecture :
Input (Éléments d'Entrée) pour l'Architecte
Spécifications Fonctionnelles :
Exigences Non Fonctionnelles :
Contraintes Techniques :
Budget et Délai :
Besoin des Parties Prenantes :
