Différences

Ci-dessous, les différences entre deux révisions de la page.

--- helloworld:architecture:notion [2019/01/07 10:46] – [Définitions] : définition des connecteurs root
+++ helloworld:architecture:notion [2020/05/10 23:46] (Version actuelle) – Suppression de la taille par défaut pour les images root
@@ Ligne 41: / Ligne 41: @@
 =====Composition d'une architecture=====
-====Définitions====
+====Composant====
-Composant : les composants sont visibles des autres composants exclusivement à travers des interfaces.
+Les composants sont visibles des autres composants exclusivement à travers des interfaces.
-Interface : 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).
+===Dépendances entre composants===
+  * service : pour obtenir un service ou une information,
+  * réalisation : implémentation par héritage,
+  * manifestation : nécessite un artefact pour s'exécuter / s'implémenter.
-Port : 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.
+===Rôles===
+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.
+  * Stocker des données (composant de type Entité),
+  * Fournir des traitements (composant de type Service),
+  * Contrôle interne (composent de type Contrôleur) : aucun, exécution possible en concurrence par file d'attente ou vraiment en parallèle, vérification des paramètres,
+  * Maintenir un contexte : gérer des informations de sessions, garder un fichier ouvert, système de cache,
+  * Interface graphique,
+  * Gestion d'un matériel physique,
+  * [[helloworld:design_pattern:proxy|Proxy]],
+  * [[helloworld:design_pattern:fabrique_abstraite|Machine abstraite]].
-Connecteur : les composants interagissent donc sur des ports, par le biais de connecteurs, et via des interfaces. Ils fournissent des services :
+===Enchaînement===
+Il y a plusieurs façons d'enchaîner l'exécution de composants de type traitement :
+  * Procédurale : deux lignes de code qui se suivent. Inconvénient : plus difficilement réutilisable dans un autre environnement / projet,
+  * Événement : A signale à B qu'il a terminé et que B peut commencer ([[helloworld:design_pattern:publish_subscribe|publisher/subscriber]], [[helloworld:design_pattern:command|commander]]?)
+  * Données : quand A a terminé, il envoie les résultats à un buffer tampon que, soit B va consulter régulièrement, soit le buffet va contacter B directement.
+====Interface====
+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).
+====Port====
+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.
+====Connecteur====
+Les composants interagissent donc sur des ports, par le biais de connecteurs, et via des interfaces. Ils fournissent des services de :
   * Communication : appel local ou distante,
   * Coordination :
@@ Ligne 60: / Ligne 84: @@
   * Facilitation : régulation de charge, appel concurrent
-Artefact : 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 [[helloworld:architecture:uml#|UML]]
+====Artefact====
+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 [[helloworld:architecture:uml#|UML]]
+====Kruchten : 4+1 vues====
+^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.|
+{{ :helloworld:architecture:kruchten:interaction_vues.png |}}
+{{ :helloworld:architecture:kruchten:interaction_architecture.png |}}
+=====Qualité=====
+====Généralités=====
+  * Interfaces simples, claires, stables et complètes,
+  * Dépendances faibles entre les constituants,
+  * Complexité interne masquée par les interfaces,
+  * Modularité,
+  * Facilité d’intégration,
+  * Durée de vie, upgradablité (remplacement d’une technologie par une autre).
+====Couplage====
+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.|
+====Cohésion====
+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.|
+=====Styles=====
+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:
+===Architectures hiérarchique et orientée objets===
+Arborescence en arbre avec à la racine le main. Chaque descendant sont un sous-module.
+{{:helloworld:architecture:style:fig1_3.png|}}
+[[https://laurent-audibert.developpez.com/Cours-UML/?page=introduction-modelisation-objet|UML 2 - De l'apprentissage à la pratique]] {{ :helloworld:architecture:uml:uml2-apprentissage-pratique.pdf |Archive du 12/01/2009 le 28/04/2020}}
+===Architecture à flot de données (pipe-line)===
+Exemples : [[helloworld:design_pattern:chain_of_responsibility|Chaîne de responsabilité]]
+{{:helloworld:architecture:style:pipeline.png|}}
+[[http://parc.sourceforge.net/intro.html|Pipeline Architecture - Introduction]] {{ :helloworld:architecture:notion:pipeline_architecture_-_introduction_2020-04-28_11_07_03_pm_.html |Archive du 06/01/2004 le 28/04/2020}}
+===Architecture avec référentiel de données (repository centric), Architecture Tableau noir (blackboard)===
+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 ([[helloworld:design_pattern:observer:java|observer]])
+{{:helloworld:architecture:style:cycleenv2.png|}}
+[[http://www.case-france.com/EnvisionArchitectureSysteme.html|Architecture système]] {{ :helloworld:architecture:notion:envision_system_architecture_2020-04-28_11_07_03_pm_.html |Archive du 2016 le 28/04/2020}}
+===Architecture à Invocation implicite===
+Voir [[helloworld:design_pattern:publish_subscribe|pub/sub]], [[helloworld:design_pattern:reactor|reactor]]
+===Architecture multi-couches===
+Chaque couche a accès uniquement à sa (ou des) couches inférieures.
+===Architecture distribuée, spécialisée en architectures N - tiers===
-Dépendances :
+Ici, chaque couche n'a accès qu'au niveau N+1 et N-1.
-  * de service : pour obtenir un service ou une information,
-  * de réalisation : implémentation par héritage,
-  * de manifestation : nécessite un artefact pour s'exécuter / s'implémenter.