content/projet_programmation/4_besoins/index.md

@@ -1,112 +0,0 @@
----
-title: "PdP: Analyse des besoins"
-date: 2024-01-24
-tags: ["besoins", "analyse", "developpement logiciel"]
-categories: ["Projet de programmation", "Cours"]
----
-
-Avant même de commencer à coder, il faut analyser les besoins du 
-"commanditaire". Il faut maximiser les chances d'être adéquats mais **sans
-formalisme**, il est cependant **nécessaire** d'y mettre de la rigueur.
-
-Il faut définir et décrire les service que notre logiciel doit offrir, il faut
-aussi identifier et décrire ses différentes contraintes (domaine de
-fonctionnement, usage des ressources forme des résultats, etc.).
-
-Il faut cependant décorréler l'analyse des besoins de l'implémentation. Les
-langages doivent être considéré comme des outils, il faut les choisir en
-fonction des besoins (et non pas faire l'analyse en fonction du langage).
-
-L'analyse doit être effectuée *en langage naturel* de façon précise et avec
-rigueur.
-
-## Deux types de besoins
-
-Nous pouvons commencer par classer les besoins en deux catégories :
-
- * **Les besoins fonctionnels**: les services et fonctionnalités comme
-   rechercher dans une base de données, réaliser une sauvegarde... Il sont
-   nécessaires au logiciel (*ceux que logiciel devrait faire*);
- * **Les besoins non-fonctionnels**: caractéristiques de ce que le programma *va
-   faire* comme une réponse rapide de l'interface, la compatibilité avec des
-   formats de fichiers...
-
-Les besoins fonctionnels sont souvent associés à **un verbe**, une action à
-réaliser.
-
-Les besoins non fonctionnels sont souvent critiques et demandent **beaucoup de
-travail**. Ces besoins peuvent aussi être en conflits comme *la rapidité* et la
-*sécurité* par exemple. Ils entraînent souvent des besoins fonctionnels. Ils
-sont eux caractérisés par **un adjectif**.
-
-### Catégoriser des fonctionnalités non fonctionnelles
-
-#### Les besoins non fonctionnels de comportement.
-
-Ils comprennent *les performances*, *la fiabilité*, *la sécurité*, *la facilité
-d'utilisation*, *le domaine d'action*, *la portabilité*
-
-#### Les besoins non fonctionnels organisationnels
-
-Ils comprennent le choix *des processus de développement*, les *langages de
-spécification*, les *techniques de planification du travail*, le *calendrier des
-livrables*, le *cadre budgétaire*.
-
-#### Les besoins non fonctionnels externes
-
-Il dépendent de pré-requis qui ne sont pas dépendants de l'équipe de
-développement. Nous pouvons citer:
-
- * Les **contraintes matérielles** dépendant de l'architecture matérielle sur
-   laquelle le programme tournera (ISA, espace mémoire, carte graphique, etc.);
- * Les **contraintes légales** comme les règlement sur les données personnelles,
-   les différents cadres sur les captations vidéos, etc.
- * Les **contraintes éthiques**: préservation de la vie privée des utilisateur
-   par exemple. 
-
-
-## Autre classement...
-
-Il est aussi possible de classer les besoins entre **utilisateur** et 
-**système**.
-
-Les premiers sont associés à ceux qui vont utiliser le logiciel qu'il soient
-simple utilisateurs, clients, maître d'ouvrage, développeur.
-
-Les seconds sont liés aux contraintes internes du logiciel et ceux qui vont le
-développer (développeur, maître d'œuvre).
-
-Ce type de classement se montre utile lorsque la liste des contraintes est
-longue.
-
-## De la précision ...
-
-Comme nous l'avons vu, l'analyse des besoin se doit d'être précise et
-rigoureuse. Plus elle est précise plus on obtiendra une description adéquate du
-logiciel à produire.
-
-La précision dans l'analyse indique aussi une bonne compréhension du domaine,
-elle permettra une organisation plus efficace du travail.
-
-## ... de la vérification ...
-
-Un besoin doit ouvoir être testé et vérifié sinon il est ineffectif. 
-
-oin qui ne peux pas être vérifié et/ou testé  doit être décomposé en
-sous-besoins (ou être précisés).
-
-Prenons l'exemple: *importer des fichiers*. Ce besoin n'est pas vérifiable,
-validable et testable en l'état. Nous pouvons le décomposer:
-
- * Lire des types de fichiers distinct, mais il faut décrire lesquels;
- * Associer des traitements à chacun des types de fichiers;
- * Ajouter les types de fichiers acceptés dans l'interface;
- * etc.
-
-Un bon exemple de décomposition reste les options associés à la commande `ls`.
-
-## ... et de la caractérisation
-
-En plus de la décomposition, il est important de **caractériser** un besoin en
-le qualifiant et l'associant à des *domaines de fonctionnements stricts*, à des
-*contraintes de faisabilités*, etc.

content/reseaux_protocoles/2_couche_applicative/index.md

@@ -1,195 +0,0 @@
-
----
-title: "Réseaux et Protocole: couche applicative"
-date: 2024-01-22
-tags: ["OSI", "application"]
-categories: ["Réseaux et protocoles", "Cours"]
-mathjax: true
----
-
-On parle ici des protocoles utilisé par les applications comme *SMTP*, *HTTP*,
-*DNS*, *IMAP*, etc. On se place au niveau **application** du modèle *TCP* ou de
-l'ensemble des couches 4 à 7 du modèle *OSI*. Ici il n;est pas question pour les
-dévellopeur de programmer pour le cœur de réseau, mais pour la périphérie.
-
-## Modèle client-serveur
-
-Comme indique le titre, nous avons deux types d'acteur :
-
- * **le serveur**: il est toujours actif avec une adresse IP fixe. La plupart du
-   temps il est dans un *datacenter*;
- * **le client**: il communique avec le serveur uniquement lorsqu'il en a
-   besoin. Le client n'a pas besoin d'adresse IP fixe. C'est lui qui contacte le
-   serveur qui en reponse lui répondra. Les clients n'échangent pas entre eux.
-
-## Modèle P2P
-
-Ici les clients peuvent aussi faire office de serveurs. Les équipements
-terminaux sont aussi **connectés entre eux**. C'est une architecture
-*distribuée* et *auto-scalable*. La gestion des **peers** est complexe.
-
-Dans ce cas il y a deux processus (un serveur et un client) sur la même machine.
-
-## Communication inter-processus
-
-Dans le cadre de programmes qui s'exécutent sur un même équipement, on utilisera
-les mécanismes de communication inter-processus.
-
-Avec des processus répartis sur des machines differentes, les messages sont
-acheminées via le réseau. On utiliseta alors les mécanismes de *sockets*.
-
-## Les sockets
-
-C'est une passerelle entre les couches transport et applications. C'est une
-porte d'envoi / réception de données pour les processus.
-
-## Adressage
-
-La couche réseaux (3) esr représentée par une adresse IP 32 bis en v4 (et 128 en
-v6). Mais cette adresse ne suffit pas pour identifier le processus qui demande 
-les données. Il faut alors le **numéro de port**.
-
-Ces numéros vont de 0 à 65535, les 1024 premiers sont normalement réservés pour
-les serveurs, le reste pour les clients.
-
-## Besoins spécifiques des applications
-
-Les applications n'ont pas toutes les mêmes besoins en ce qui concerne les
-données envoyées ou reçues via un réseau informatique
-
-La VoIP, ou encore le streaming audio / vidéopeuvent se passer des **contrôles
-d'intégrité** par exemple. mais la VoIP elle nécessite d'utiliser des
-communication **temps réel** (ou de s'en approcher) tout comme le jeu en ligne.
-
-## La couche transport
-
-Nous avons ici deux protocoles utilisés:
-
-### TCP
-
-C'est un protocole avec connexion qui vise avant tout **la fiabilité** :
-contrôle de flux, gestion de la congestion, réordonancement des paquets. Avant
-d'acheminer des données, il est nécessaire de lancer une connexion en 3 étapes
-(`SYN`, `SYN-ACK`, `ACK`). Il est aussi nécessaire de mettre fin explicitement 
-à la connexion (`FIN`). Cependant il **n'y a pas de gestion du timing** ni de
-**sécurité**.
-
-#### La sécurité dans TCP
-
-Comme nous l'avons vu il n'y a pas de gestion de la sécurité dans *TCP*. Mais il
-existe une couche intermédiaires entre les couches *application* et *transport*
-: TLS pour **Transport Layer Security**.
-
-*TLS* se charge de l'authentification, du chiffrement, et du contrôle de
-l'intégrité.
-
-### UDP
-
-Ici il n'y a pas de gestion de fiabilité (ordre, sommes de contrôle,
-acquittement, etc.). En contrepartie il y a peu *d'overhead*, il est donc adapté
-our la VoIP par exemple. Il est aussi plus simple à implémenter et supporte le
-*multicast* et le *broadcast*.
-
-## Quelques protocoles
-
-### HTTP
-
-C'est le protocole utilisé pour le **web**, il se base sur *TCP* et les
-mécanismes de connexions sous-jacent. Il est de type client - serveur:
-
- * client: *User Agent*, le navigateur web;
- * serveur: serveur HTTP comme Apache ou Nginx.
-
-Le serveur stocke des objets (fichiers HTML, images, vidéos etc.)
-
-Il existe deux type de connexions HTTP : 
-
- * persistente: 1 connexion pour transférer plusieurs objets;
- * non persistente: 1 connexion pour tranférer un objet.
-
-#### La requête
-
-Elle emmane du client à destination du serveur, la requête est formatée en
-ASCII, elle contient une requête suivi d'élément d'entête:
-
-```
-GET https://ent.u-bordeaux.fr HTTP/2\r\n
-```
-
-Ici on demande `https://ent.u-bordeaux.fr` en HTTP version 2. Les entêtes peuven
-contenir les langies acceptés par le client par exemple.
-
-#### La réponse
-
-Elle contient le code de retour, les entêtes de réponse ainsi que le contenu. La
-réponse peut être conditionnée à la modification de la ressource demandée via un
-*conditionnal GET*. L'entête de la demande contient le champs 
-`If-Modified-Since`. Le serveur peut alors répondre avec un code `304`
-`Not-Modified` et le navigateur utilisera la version dans son cache.
-
-#### Amélioration du protocole
-
-La verion 2 de HTTP permet de découper les ressources demandées en *chunk* et de
-réaliser des envois entrelacés. Ainsi les gros fichiers ne pénalisent pas le
-transfert des plus petits (mécanismes de `first come first served*.
-
-La version 3 propose d'utiliser les protocole UDP et QUIC. Il propose de gérer
-la réupération de paquets perdus (hé oui, il utlise UDP), il propose aussi la
-gestion de la congestion et plus de sécurité (QUIC).
-
-### DNS
-
-C'est le protocole chargé de la résolution des noms de domaines (et des
-résolutions inverses). Il fait le lien entre les adresses IP et les noms de
-domaines. C'est **une base de donnée distribuée** our éviter le *single point
-of failure*
-
-La base de données est hiérarchisée : `Root server` -> `Top level domain` ->
-`authoritative server` -> `recursive resolver`.
-
-
-Deux types de requêtes:
-
- * **itérative**: le résolveur a la charge de la requête et demande les
-   informations du *root* jusqu'au serveur *authoritative*;
- * **recursive**: chaque serveur est responsable de sa réponse. La requête va
-   ainsi passer de serveur en serveur et faire le chemin inverse jusqu'à revenir
-   au client.
-
-#### Les enregistrement DNS et les messages
-
-Il sont au format RR *Ressource Record*:
-
-```
-<nom> <valeur> <type> <TTL>
-```
-
-Les messages du serveur vers le client contiennent le nombre de question, le
-nombre de réponse et enfin les réponses.
-
-## Retour sur les sockets
-
-Comme nous l'avons vu elle serve de point de liaisons entre les applications et
-la couche transport. Elle sont créees par le système.
-
-Pour la création de socket UDP :
-
-```c
-mysock = socket(AF_INET, SOCK_DGRAM);
-mysock.rcevfrom();
-mysock.sendto();
-bind(mysock, &addr, sizeof(addr));
-```
-
-C'est relativement simple car il n'y a pas de connexion.
-
-Pour TCP c'est un peu plus complexe:
-
-```c
-mysock = socket(AF_INET, SOCK_STREAM);
-mysock.listen();
-mysock.connect(addr, port);
-
-// Accept connection result a new one!
-newsocks = mysock.accept();
-```