helloworld:architecture:notion
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
| helloworld:architecture:notion [2019/01/03 20:25] – [Structure] : précision sur les exigences non fonctionnelles root | helloworld:architecture:notion [2020/05/10 23:46] (Version actuelle) – Suppression de la taille par défaut pour les images root | ||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| - | =====Architecture fonctionnelle===== | + | =====3 types d' |
| + | ====Architecture fonctionnelle==== | ||
| Cela consiste à décrire les besoins d'un point de vue exclusivement métier sans aborder la partie technique du logiciel. | 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. | On peut déjà imaginer les briques logicielles avec leurs fonctions et leurs interactions mais toujours exclusivement du point de vue métier. | ||
| - | =====Architecture logicielle===== | + | ====Architecture logicielle==== |
| - | ====Structure==== | + | ===Structure=== |
| Un logiciel est composé de sous-systèmes (facultatif), | Un logiciel est composé de sous-systèmes (facultatif), | ||
| Ligne 22: | Ligne 23: | ||
| {{ : | {{ : | ||
| - | ====Aspects dynamiques==== | + | ===Aspects dynamiques=== |
| * Global : scénarios d' | * Global : scénarios d' | ||
| * Constituant : contrainte d' | * Constituant : contrainte d' | ||
| - | ====Déploiement==== | + | ===Déploiement=== |
| Spécifier les contraintes de déploiement et la description de l' | Spécifier les contraintes de déploiement et la description de l' | ||
| - | =====Architecture système===== | + | ====Architecture système==== |
| L' | L' | ||
| Ligne 38: | Ligne 39: | ||
| {{ : | {{ : | ||
| + | |||
| + | =====Composition d'une architecture===== | ||
| + | ====Composant==== | ||
| + | Les composants sont visibles des autres composants exclusivement à travers des interfaces. | ||
| + | |||
| + | ===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' | ||
| + | |||
| + | ===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' | ||
| + | * 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: | ||
| + | * [[helloworld: | ||
| + | |||
| + | ===Enchaînement=== | ||
| + | Il y a plusieurs façons d' | ||
| + | * 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: | ||
| + | * Données : quand A a terminé, il envoie les résultats à un buffer tampon que, soit B va consulter régulièrement, | ||
| + | ====Interface==== | ||
| + | Une interface est attachée à un port de communication du composant. Il existe deux types d' | ||
| + | |||
| + | ====Port==== | ||
| + | Une interface est attachée à un port du composant, noté par un carré. Cela peut être l' | ||
| + | |||
| + | ====Connecteur==== | ||
| + | Les composants interagissent donc sur des ports, par le biais de connecteurs, | ||
| + | * Communication : appel local ou distante, | ||
| + | * Coordination : | ||
| + | * appel synchrone : on attend le retour, | ||
| + | * événement simple : on envoie un évènement, | ||
| + | * événement bufferisé : idem qu'un événement simple sauf que le destinataire stocke le message en attente s'il n'est pas prêt à le traiter tout de suite, | ||
| + | * flots de données : envoie de données en continu peu importe si le destinataire manque quelques messages, | ||
| + | * Appel asynchrone : A envoie la demande à B, le retour arrivera plus tard de B vers A, | ||
| + | * Pub/Sub : A envoie un message à B avec un << | ||
| + | * Conversion de données entre les deux ports, | ||
| + | * 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: | ||
| + | |||
| + | ====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, | ||
| + | |Processus|Allocations et interactions entre processus, threads ou tâches.|Activités, | ||
| + | |Déploiement|Environnement d' | ||
| + | |Cas d' | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | =====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' | ||
| + | |||
| + | Selon Pressman, 7 niveaux de couplage, classé par niveau de dépendances, | ||
| + | ^Couplage^Description^ | ||
| + | |Sans couplage|Les composants n' | ||
| + | |Par données|Les composants échangent de l' | ||
| + | |Par paquet|Les composants échangent de l' | ||
| + | |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' | ||
| + | |Commun (global)|Les composants échangent de l' | ||
| + | |Par contenu (interne)|Les composants échangent de l' | ||
| + | |||
| + | ====Cohésion==== | ||
| + | La cohésion est une mesure d' | ||
| + | |||
| + | 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' | ||
| + | |||
| + | 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. | ||
| + | |||
| + | {{: | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | ===Architecture à flot de données (pipe-line)=== | ||
| + | |||
| + | Exemples : [[helloworld: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | ===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, | ||
| + | |||
| + | 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: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | ===Architecture à Invocation implicite=== | ||
| + | |||
| + | Voir [[helloworld: | ||
| + | |||
| + | ===Architecture multi-couches=== | ||
| + | |||
| + | Chaque couche a accès uniquement à sa (ou des) couches inférieures. | ||
| + | |||
| + | ===Architecture distribuée, | ||
| + | |||
| + | Ici, chaque couche n'a accès qu'au niveau N+1 et N-1. | ||
helloworld/architecture/notion.1546543519.txt.gz · Dernière modification : de root
