finish first part of software architecture

content/projet_programmation/7_architecture_logicielle/index.md

@@ -1,57 +1,241 @@
 ---
-title: "PdP: Architecture loficielle"
+title: "PdP: Architecture logicielle"
 date: 2024-03-14
 tags: ["besoins", "UML", "developpement logiciel"]
 categories: ["Projet de programmation", "Cours"]
 ---
 
+## Introduction
+
+une architecture logicielle est une structure composite basée sur une
+décomposition de composants distincts et une ensemble de dépendance et/ou
+d'interaction entre ces composants.
+
+La finalité est de répondre un ensemble de besoins logiciels et d'offrir un
+ensemble de services.
+
+> Engineering is all about breaking down big problems into smaller ones
+> and putting the solutions for those problems back together
+
+Boswell and Fouchet, 2011
+
+Il est donc question ici de maitriser la taille et la complexité pour assurer le
+**passage à l'échelle** : décomposer pour maîtriser et faire évoluer. En effet
+les architectures logicielles doivent aussi être modifiables, extensible et
+évolutives. Les composants et leurs dépendances doivent **permetttre et
+faciliter le changement**.
+
+## Dépendances et composants
+
+Un composant, aussi appelé aussi *bloc de construction* est tout élément
+syntaxique qui participe à la structure de son architecture : les intructions,
+les expressions, fonctions, classes, modules, paquetages, etc.
+
+Un composant \\(C_1\\) est dépendant de \\(C_2\\) si \\(C_1\\) utilise \\(C_2\\) 
+dans sa définition ou implémentation.
+
+![Représentation des dépendences](./imgs/dependence_c1_c2.svg)
+
+Voici comment représenter les dépendances entre deux classes, notez le sens de
+la flèche, elle pointe vers \\(C_2\\) : *"dépends de".
+
+Nous avons trois grande famille de dépendances:
+
+ * Les **utilisations simples** d'éléments de composants. Par exemple une
+   fonction \\(f_1\\) appelle une autre fonction \\(f_2\\);
+ * Les **associations** entre composants par imbrications. Par exemple une
+   classe \\(C_1\\) inclut un attribut de la classe \\(C_2\\);
+ * Les **inclusions** ou **héritages** entre composants par réutilisation. Par
+   exemple un sources C \\(s_1\\) inclut via `#include` un autre fichier 
+   \\(s_2\\).
+
+### Taille -- flux et débit -- des dépendances
+
+Les dépendances d'une architecture doivent être utilisable, utilisées et utiles.
+Elles doivent transmettre que le stricte minimum d'informations et de qualité
+suffisante (contrôle et maîtrise).
+
+La **taille** d'une dépendance entre \\(c_{1}\\) et \\(c_{2}\\) reflète la
+quantité d'information qu'elle peut faire transiter ce qui inclus:
+
+ * Le nombre d'éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\);
+ * Le volume des éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\);
+ * La complexité des éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\).
+
+Cette mesure n'as pas vocation être précise.
+
+Dasn une architecture logicielle, il faut favoriser la définition d'une
+dependance **avec une taille minimale**
+
+### Diffusion des changements
+
+Une architecture où les changements dasn les composants sont diffusés aux
+autres composants n'est qu'une *architecture factice*.
+
+Nous devons donc introduire la notion de **force d'une dépendance** entre deux
+composants \\(c_{1}\\) et \\(c_{2}\\):
+
+ * Elle est **forte** si une modification dans \\(c_{2}\\) entraine une 
+   modification dans \\(c_{1}\\).
+ * Elle est faible dans le cas contraire.
+
+La diffusion des changement va toujours dans le *sens inverse* des dépendances.
+
+Dans une architecture logicielle, il faut limiter les dépendances forte pour les
+changements les plus probables dans cette architecture. On est obligé de se
+concentrer sur les changements les plus probables (on ne pourra considérer tous
+les changements). Il faut identifier ces changement possibles par le contexte,
+les besoins non fonctionnels, l'expérience, etc.
+
+Plusieurs techniques d'implémentation sont disponible pour appliquer le principe
+de diffusion minimisée des changements comme: 
+
+ * Les mécanismes de cloisonnement des langages (expression du privée / public);
+ * En appliquant le principe de *taille minimisé*;
+ * En utilisant les moyens d'expression d'abstration des langages comme *les
+   interfaces*.
+
 ### Dépendances et utilisation des interfaces
 
-spécification d'un composant -> description abstraite et rigoureuse de ses
+La spécification d'un composant représente la description abstraite et rigoureuse de
-qualités, de sa manière de se comporter, des services qu'il est censé rendre.
+ses qualités, de sa manière de se comporter, des services qu'il est censé
-Un composant qui satisfait une spécification S est dit réaliser S
+rendre. Un composant qui satisfait une spécification \\(S\\) est dit *réaliser* 
+\\(S\\)
 
 Utilisation de l'interface au lieu d'une classe
 
 ```c++
 class C2 {
     IC1 obj;
-    // ...
+    // This is a simple class
 }
 
 interface IC1 {
-
+    // Interface - kind of specification
 }
 
 class C1 implement IC1 {
-// ...
+    // then iplementation.
 }
 ```
 
+![Introduction d'une interface](./imgs/interface.svg)
+
 Ainsi `C2` ne dépends pas de `C1` mais de l'interface `IC1`. En plus de décrire
 abstraitement les composants à implémenter, elles servent d'intermédiaire dans
 les dépendances.
 
+Les interfaces contrôlent une part des dépendances fortes, on y spécifie les
+éléments les moins susceptibles de changer. Les interfaces ont deux rôles
+important dans une architecture logicielle:
+
+ * Décrire de manière abstraite les composants à implémenter;
+ * Servir d'intermédiaire dans les dépendances et ainsi contrôler la force ou la
+   faiblesse des dépendances.
+
+#### Principe d'inversion des dépendances.
+
+**Une dependance implicite** est une dépendance qui ne se voit pas directement
+dans le source d'un programme pas ses appels et ses annotations. Elle est
+toujours forte par rapport au changement qui la détermine.
+
 > Dans une architecture logicielle, il est préférable de faire dépendre les
-> ocmposants d'interfaces et non les composants implémentés.
+> composants d'interfaces et non les composants implémentés.
 
-Principe d'inversion des dépendances.
+si nous reprenons le schéma précédent, alors \\(IC_{1}\\) a été écrite par
+rapport à l'usage de \\(C_{2}\\) par \\(C_{1}\\), nous pouvons alors en déduire
+que \\(C_{2}\\) dépends de la paire \\((C_{1},IC_{1})\\). C'est notre
+**inversion de dépendance**
 
-Une dependance implicite -> qui ne se voit pas directement dans le source d;un
+### Notion étendue des dépendances
-programme pas ses appels et ses annotations. Elle est toujours forte par rapport
+
-au chamgement qui la détermine.
+Nous avons vu des *dépendances explicites* qui se matérialise par les appels de
+méthodes, les classes etc. Mais il existe aussi les **dépendances implicite**: 
+c'est une dépendance qui ne se voit pas directement dans le code source.
 
 Elles peuvent prendre des formes très différentes des dépendances explicite par
 
- * la duplication de code
+ * La duplication de code;
- * les similarité de services
+ * les similarité de services offerts par des composants distincts;
- * <cf slide>
+ * les similarité de structure entre composants distincts.
+
+ Les dépendances implicites sont toujours des dépendances fortes car se sont les
+ changements qui les définissent. Il est donc préférable de minimiser leur
+ apparition. (on minimise alors la duplication de code et les similarité par
+ des techniques de factorisation de code)
 
-LEs archilogicielles sont généralement des structures hiérarchisées.
 
 ## Granularité de structure, cohésion et couplage
 
-niveau de granularité défini par
+Les architecture logicielles sont généralement des structures hiérarchisées de
+composants, c'est une conséquence naturelle du *décomposer pour maîtriser*.
+Cette hiérarchisation est généralement simplifiée car elle peut être constituée
+essentiellement de niveaux homogène de structure de composants.
 
-Gq et G2 deux niveau de granilarité alirs couplage : ensemble des dépendances
+Son niveau de granularité est déterminé par des composants de même espèce
-entre les composants de G2
+capable d'inclure des composants du niveau inférieur (s'il y en a). Les niveaux
+habituels de granularité offerts par les langages de programmation sont:
+
+ * Les valeurs, données, instructions;
+ * Les variables, attributs, fonctions (ou méthodes);
+ * Les modules, classes, objets,
+ * Les paquetages, clusters, namespace
+ * Les super-paquetages;
+ * Les couches.
+
+Pour des raison de simplification et d'intelligibilité, les dépendances peuvent
+se restreindre à ne s'énoncer qu'au sein de chaque niveau de granularité : un
+composant \\(C1\\) est explicitement dépendant de \\(C2\\) si \\(C1\\) utilise
+\\(C2\\) dans sa définition ou son implémentation et si tous les deux sont au
+même niveau de granularité. Les dépendances sont donc à considérer entre
+fonctions, entre classes, entre paquetages, etc.
+
+### Graphes de dépendances
+
+Les dépendances dans une granularité fixée induisent des **graphes** dont les
+sommets sont d'une seule espèce de composants et les arcs des dépendances
+explicites.
+
+Dans la mesure du possible, il faut favoriser la construction de niveau de
+granularité homogènes donnant lieu à des graphe de dépendances distincts. C'est
+un principe de simplification et d'intelligibilité des architectures logicielles
+mais qui n;est pas applicable tout le temps (et c'est parfois souhaitable). Les
+langages permettent souvent des moyens de déroger à ce principe (*nested
+classes* en Java, lambda expression ...).
+
+### Suites de granularités, consécutivité
+
+Les granularités peuvent donc former des suites constitués des éléments que nous
+avons évoqué plus haut (données, variables, fonctions etc.). Deux **granularité
+consécutives** sont deux granularité qui se suivent dans cette liste, elles
+engendre des **graphes consécutifs de dépendances**.
+
+Il faut veiller à ce que chaque graphes de consécutivité soit plus simple que le
+précédent, ils dessinent alors **une pyramide**. Chaque niveaux est une
+opportunité de simplifier, synthétiser la description d'une architecture. Bien
+entendu il existe des contre-exemples, comme **les classes qui ne contiennent
+qu'une seule méthode**.
+
+Il serait naturel de regrouper un ensemble de méthodes très dépendantes en elles
+dans une seule classe, ou encore des classes très dépendances dans un
+paquetage. C'est le principe **de simplification min-max**: il faut en sorte
+que les composants du niveau de granularité \\(G2\\) englobent le **maximum** de
+dépendances de \\(G1\\) tel qu'il reste un **minimum** de dépendances en
+composants de \\(G2\\).
+
+### Couplage et cohésion
+
+Le couplage représente l'ensemble des dépendances entre composants de \\(G2\\),
+la cohésion celles au sein de chacun des composants de \\(G2\\) entre les
+éléments de \\(G1\\).
+
+Si \\(G2\\) est un ensemble de classes et \\(G1\\) un ensemble d'attributs et de
+méthodes de ces classes alors:
+
+ * le couplage correspond à l'ensemble des dépendances entre classe de \\(G2\\);
+ * la cohésion définie pour chaque classe de \\(G2\\) correspond à l'ensemble
+   des dépendances entre ses attributs et méthodes.
+
+Pour reprendre notre **principe min-max**: dans une architecture logicielle, pour
+toute paire de niveau de granularité, il faut privilégier à la fois **la
+cohésion la plus forte** et **le couplage le plus faible**

content/reseaux_protocoles/5_couche_liaison/index.md

@@ -0,0 +1,215 @@
+---
+title: "Réseaux et Protocole: couche liaison"
+date: 2024-03-29
+tags: ["OSI", "ethernet"]
+categories: ["Réseaux et protocoles", "Cours"]
+mathjax: true
+---
+
+Commençons déjà par la terminologie:
+
+ * *nœuds* : équipement (routeur, host)
+ * *canal de communication* : lien adjacent entre nœuds;
+ * *frame* : paquet de la couche liaison (niveau 2)
+
+La couche 2 transmet une frame entre deux **nœuds ajacents**. Il existe les
+liaisons **filaires** (ethernet) et **sans-fils** (wifi, LTE). Chaque protocole
+propose des caratéristiques différentes (fiabilité, rapidité etc.)
+
+Comme pour les autres couches étudiée jusqu'à maintenant, celle-ci encapsule les
+éléments de celle au dessus en y ajoute son entête. La couche liason ajoute
+ainsi les propres mécanismes de contrôles de flux entre les nœuds adjacent ou
+encore la détection voire la correction d'erreur. Le mode de communication peut
+être *half-duplex* ou *full-duplex*
+
+La couche liason est implémentée sur chacun des nœuds, elle peut l'être
+directement sur le contrôleur réseau de façon matérielle mais aussi logicielle.
+
+## Détection d'erreur
+
+Elle se fait par l'ajout d'un champs *EDC* pour *Error Detection Code* dans la
+frame. C'est un simple ajout de bits de parité. Cependant ajouter un seul bit de
+parité **n'est pas assez fiable**. Il est alors préférable d'utiliser le *two
+dimentionnal parity*, un tableau à deux dimensions pour faire du *calcul de
+parité* permettant non seulement **la correction** mais aussi la **correction**.
+
+## Multiple access link
+
+Nous avons d'abors des protocole utilisé pour la communication entre deux nœuds :
+*PPP* pour *Point to Point Protocol* ou encore *ethernet*. Mais d'autres sont
+fait poue la diffusion (*broadcast*), la communication entre plusieurs nœuds
+comme le *Wifi* ou les communications par *Satellite*
+
+Dans le second cas, il nous faut un algorithme pour déterminer **l'ordre de
+transmisson** : à quel moment un équipement peut envoyer des données sur le
+canal partagé entre tous. Il n'y a pas de canal auxiliaire ( *out of band* )
+pour organiser le partage de la ressource, il faut alors organiser le
+partitionnement
+
+### MAC Protocol
+
+Le canal est divisé en plus petites pièces à l'exclusivité de nœuds. Les accès
+sont aléatoires et au tour par tour.
+
+#### partitionnement en fonction du temps
+
+Chaque station a un slot de temps fixe permettant la transmission, si la station
+n'a pas de donnée à transmettre, alors le slot passe en IDLE.
+
+#### Frequencie division multiple access *FDMA*
+
+Le canal est divisé sur plusieurs fréquences, chaque nœud se voit attribuer une
+fréquence et peut transmettre sur celle-ci en continue.
+
+#### accès aléatoire
+
+Lorqu'un nœud veut émettre, il prend la communication sur l'ensemble du canal,
+il n'y a pas de gestion de la coordination. Donc si deux nœuds ou plus émettent
+en même temps alors il y a **collision**.
+
+Ces types de protocoles définissent alors comment détecter les collisions et ce
+qu'il faut faire dans ce cas.
+
+Vopici des exemples de protocoles de type accès aléatoires: ALOHA, Slotter
+ALOHA, CSMA, CSMA/CD, CSMA/CA
+
+##### Slotted ALOHA
+
+Le temps est divisé en intervalle régulier (intervalle de temps) correspondant au
+temps nécessaire pour la transmission d'une trame. L'émetteur attend donc le
+début d'une intervalle de temps pour transmettre sa trame.
+
+En cas de collision, le nœud retransmet son paquet après avoir attendu un temps
+aléatoire. Au mieux, 37% d'efficacité.
+
+##### Carrier Sense Multiple Access
+
+C'est un protocole simple : écouter avant de transmettre :
+
+ * Si le canal est libre alors on transmet **la trame entière**;
+ * sinon on repousse la transmission
+
+##### Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
+
+Les collision sont possible avec CSMA, à cause du délais de propagation de la
+trame. La probabilité d'une collision est déterminée par la distance et le
+délais de propagation.
+
+Avec CSMA/CD, un hôte annule la transmission d'une trame à l'instant de la
+détection d'une collision. Dans le cadre d'Ethernet par exemple:
+
+ * Vérification du canal;
+ * Envoi d'une trame entière si le canal est libre;
+ * Si aucune collision détectée : fin!
+ * Sinon annule la transmission et envoie le *signal jam*;
+ * Entre dans le *binary exponential backoff* : choisi un nombre \\(K\\) entre
+   \\([1..2^{m-1}]\\) et attend \\(K x 512 \\)temps / bit et relance les étapes
+   à partir de la vérification du canal.
+
+#### à tour de rôle
+
+C'est un protocole reprenant le meilleur de l'accès aléatoire et du partage de
+canal
+
+Deux façons de faire :
+
+ * Un contrôleur décide du partage de la ressource et invite les équipement.
+   C'est le fonctionnent du **Bluetooth** par exemple.
+ * Un jeton donne le droit à transmission et passe d'hôte en hôte. Cette façon
+   de procéder donne lieu à un peu *d'overhead*, de plus que faire si le jeton
+   se perd?
+
+## LAN
+
+### Adressage 
+
+La base de cette des LAN est l'adresse MAC inscrite en dur dans le matériel --
+mais parfois dans le logiciel, pensez aux machines virtuelles par exemple -- sur
+48 bits. Les 3 premiers octets de cette adresse sont alloués par l'IEE en
+fonction du fabricat du périphérique.
+
+### Le protocole ARP
+
+Il fait le lien entre l'adresse Ethernet (couche liaison) et l'adresse IP 
+(couche réseau). La **table ARP** présent sur tous les hôtes connecte au reseau 
+permet de faire le lien entre les adresses MAC et IP en y associant aussi une
+durée de vie , le `TTL`.
+
+Des message de broadcast sont envoyés par les hôtes afin de connaitre l'adresse
+MAC des autres si l'entrée n'est pas disponible dans la table (encapsulé dans
+une trame Ethernet).
+
+### Ethernet
+
+C'est la technologie dominante sur les réseaux locaux depuis les années 90.
+Plusieurs implémentation sont disponibles :
+
+ * **bus** pour les réseaux coaxiaux avec un seul domaine de collision;
+ * **switch** pour les réseaux avec connecteur RJ45, ici un domaine de collision
+   par machine.
+
+D;abors il y a le préambules : une série de 8 octets dont les 7 presiers sont
+`1010101010` puis le dernier à `1010101011`. Son rôle est de  synchroniser les
+hôtes et de délimiter le début de la transmission.
+
+Viens ensuite la *trame* composées de :
+
+ * l'adresse *MAC* de destination;
+ * l'adresse *MAC* source;
+ * le *type* indiquant le protocole de la couche supérieure;
+ * la *charge utile*
+ * le contrôle d'intégrité (*CRC* pour **Cyclic Redundancy Check*).
+
+Ethernet est un protocole sans connexion : il n'y a pas de *handshake*, pas de
+mécanisme d'*ACK*, pas de retransmission. On laisse ça **à la couche supérieure.
+
+Il existe aussi plusieurs standards Ethernet en fonction du type de liaison.
+
+### Les switches
+
+C'est un équipement de la **couche liaison** qui stocket te retransmet les
+trames Ethernet. Il examine les adresse MAC dans les entêtes et envoie les
+trames vers les hôtes concernés. Il est transparent et ne nécessite pas de
+configuration pour un *switching* basique.
+
+Les switches possèdent une **table de transfert** qui contient les tuples
+`MAC:Port:TTL` mis a jour en fonction des trames qu'il voit passer. Le switch
+modifie dynamiquement cette table en fonction des trames qu'il voit passer sur
+ses différents ports. Lorqu'il doit envoyer des trames vers une adresse qu'il ne
+connait pas, alors il va emmetre une demande ARP sur **l'ensemble de ses
+ports**. Cette auto-apprentissage peur fonctionner même un fois les *switches*
+brachés les un aux autres.
+
+Il est capable de communiquer sur plusieurs canaux simultaniement sans
+collisions par exemple, communication A <---> B et C <---> D ( mais A <---> B et 
+A <--> C ne peut se faire en simultané )
+
+### VLAN
+
+Ils permettent de reduire le domaine de broadcast (ARP, DHCP) pour plusieurs
+éventuels objectifs:
+
+ * attacher logiquement des utilisateurs à leur machines / réseau;
+ * faciliter la gestion du réseau
+ * séparer les utilisateurs (sécurité, vie privée)
+
+Mais pour celà il faut des équipement compatibles et de la **configuration**.
+Par exemple avec les *ports based VLAN*  il est possible d'affecter
+dynamiquement les ports à des VLAN.
+
+L'échange de messages entre les VLANs doivent se faire via un **routeur**  ou un
+**switch de niveau 3**. Les connexions entre les différents switches doivent se
+faire va un **lien trunk** permettant de transmettre les informations relatives
+aux VLAN.
+
+Ces information son positionnées dans l'entête Ethernet au format *802,1q*. elle
+se comporte du *tag protocol* et du *vlan id*.
+
+### MPLS
+
+Ce protocole permet d'assurer un routage et un forwarding plus rapide des
+paquets. Il s'intercale entre les couches 2 et 3 et se base sut l'ajout de
+labels de taille fixe entre l'entête Ethernet et la charge utile.
+
+Le routeur MPSL regarde donc le label pour décider quoi faire avec le paquet: le
+routage est plus rapide (pas de décapsulation) et plus flexible.