Cela consiste à décrire les besoins d'un point de vue exclusivement métier sans aborder la partie technique du logiciel.
On peut déjà imaginer les briques logicielles avec leurs fonctions et leurs interactions mais toujours exclusivement du point de vue métier.
Un logiciel est composé de sous-systèmes (facultatif), eux-mêmes composés de composants logiciels.
Un composant peut être :
Un composant possède :
Spécifier les contraintes de déploiement et la description de l'infrastructure : machine, OS, plateforme (java, …)
L'architecture logicielle est la partie de l'architecture système qui détaille la description des éléments applicatifs.
Une architecture système regroupe :
Les composants sont visibles des autres composants exclusivement à travers des interfaces.
Il est préférable mais pas obligatoire qu'un composant ne supporte qu'un rôle à la fois, sauf pour les deux premiers qui sont les fondamentaux de la programmation orientée objet et le troisième qui gère les besoins en concurrence.
Il y a plusieurs façons d'enchaîner l'exécution de composants de type traitement :
Une interface est attachée à un port de communication du composant. Il existe deux types d'interface : le cercle représente l'interface offerte (les différentes méthodes à disposition) et le demi cercle l'interface requise (le prototype des méthodes doit correspondre à l'interface offerte).
Une interface est attachée à un port du composant, noté par un carré. Cela peut être l'exécution de la méthode en local ou via une API distante ou la possibilité d'avoir les deux à la fois.
Les composants interagissent donc sur des ports, par le biais de connecteurs, et via des interfaces. Ils fournissent des services de :
La manifestation concrète d’un composant est appelée artefact. C’est une instance concrète du composant déployée dans l’environnement d’exécution. Voir UML
Vue | Description | Diagrammes |
---|---|---|
Logique | Composants présents et leurs interactions | Paquetages, classes, objets et structures (UML), blocs (SysML) |
Réalisation | Organisation des composants concrets sur une plateforme. | Composants, paquetages, structures composites. |
Processus | Allocations et interactions entre processus, threads ou tâches. | Activités, séquence, communication, états-transitions. |
Déploiement | Environnement d'exécution y compris contraintes géographiques, de bandes passants et de performances du système. | Composants, déploiement. |
Cas d'utilisation | Scénarios correspondant à une fonctionnalité du système s'activant depuis une interaction extérieure. | Cas d'utilisation, activités, séquence, communication, états-transitions. |
Le couplage reprendre le niveau d'interaction entre les composants logiciels.
Selon Pressman, 7 niveaux de couplage, classé par niveau de dépendances, le meilleur est le premier :
Couplage | Description |
---|---|
Sans couplage | Les composants n'échangent pas d'information. |
Par données | Les composants échangent de l'information par des méthodes utilisant des arguments de type simple (entiers, réels, chaînes de caractères, etc.). Compatible entre les différents languages de programmation. |
Par paquet | Les composants échangent de l'information par des méthodes utilisant des arguments de type composé (structure, classe). Nécessite des changements si le language de programmation change d'un coté. |
Par contrôle | Les composants se passent ou modifient leur contrôle par modification d'un drapeau interne au composant invoqué (verrou). |
Externe | Les composants échangent de l'information par un moyen de communication externe (par exemple fichier, queue de message, variable d’environnement, etc.) |
Commun (global) | Les composants échangent de l'information via un ensemble de données communes |
Par contenu (interne) | Les composants échangent de l'information en lisant et écrivant directement dans leurs espaces de données respectifs. |
La cohésion est une mesure d'homogénéité dans un composant ou un sous système.
Selon Pressman, 7 niveaux de cohésion, classé par niveau, le meilleur est le dernier :
Cohésion | Description |
---|---|
Arbitraire | Absence de lien logique entre les éléments. |
Logique | Les fonctions sont de même catégorie ou reliées par un ou plusieurs critères communs. |
Temporelle | Les fonctions s’exécutent dans une même période de temps. |
Procédurale | Les fonctions sont appelées selon une séquence bien déterminée (et non arbitrairement au gré de l’appelant). |
Communicationnelle | Les fonctions ont les mêmes types d’entrées sorties. |
Séquentielle | Les opérations forment des séquences d’exécution bien identifiées (la sortie de l’une est l’entrée de l’autre). |
Fonctionnelle | Les fonctions contribuent à une même fonction de plus haut niveau, ou bien relèvent d’une abstraction commune. |
Les styles architecturaux et les pattern design sont proches. Les pattern s'appliquent à un composant précis alors que les styles s'appliquent à un sous système entier.
Principaux styles de base:
Arborescence en arbre avec à la racine le main. Chaque descendant sont un sous-module.
UML 2 - De l'apprentissage à la pratique Archive du 12/01/2009 le 28/04/2020
Exemples : Chaîne de responsabilité
Pipeline Architecture - Introduction Archive du 06/01/2004 le 28/04/2020
Il y a les composants accesseurs de données d’une part, qui implémentent les traitements, et les composants « référentiels de données » d’autre part, qui maintiennent des données écrites et lues par les premiers.
Dans la version de base, les référentiels sont passifs (vocation de stockage). Dans la version tableau noir, les référentiels informent les accesseurs des modifications (observer)
Chaque couche a accès uniquement à sa (ou des) couches inférieures.
Ici, chaque couche n'a accès qu'au niveau N+1 et N-1.