diff --git a/content/projet_programmation/4_besoins/index.md b/content/projet_programmation/4_besoins/index.md deleted file mode 100644 index d82efef..0000000 --- a/content/projet_programmation/4_besoins/index.md +++ /dev/null @@ -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. diff --git a/content/reseaux_protocoles/2_couche_applicative/index.md b/content/reseaux_protocoles/2_couche_applicative/index.md deleted file mode 100644 index fb70e6c..0000000 --- a/content/reseaux_protocoles/2_couche_applicative/index.md +++ /dev/null @@ -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*: - -``` - -``` - -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(); -```