diff --git a/content/projet_programmation/5_representations/index.md b/content/projet_programmation/5_representations/index.md deleted file mode 100644 index 0b62f54..0000000 --- a/content/projet_programmation/5_representations/index.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: "PdP: Représentations et présentations" -date: 2024-01-24 -tags: ["besoins", "UML", "developpement logiciel"] -categories: ["Projet de programmation", "Cours"] ---- - -Une longue liste de besoin, même classées de plusieurs manières comme nous -l'avons vu dans le chapitre précédent, n'est pas toujours claire. - -Mais nous pouvons représenter ces besoins sous forme graphique et utiliser les -avantages de cette représentation (qui peut être partielle, et meme multiple): - - * Clarifier la structure des besoins; - * Identifier les liens entre eux; - * Synthétiser. - -Les représentation peuvent être **multiple** et **formalisées*. Ici encore pas -besoin de formalisme mais de la **rigueur**. Elles sont aussi appelées **modèles -systèmes**. - -## Les diagrammes de flux de données - -C'est un graphe de dépendances entre processus / fonctionnalités (formes -arrondies), les fichiers (barres) et les données/inputs/outputs (rectangles). -Ce type de graphe fonctionne bien pour les scénarios. - -Il est tout à fait possible de créer ses propres représentations graphiques mais -il faut penser **impérativement** à légender. La nature des sommets et des -arrêtes doit être fixée, décrite et appliquée uniformément. - -## UML - -Pour *Unified Modeling Language*, c'est un langage de modélisation graphique à -base de pictogramme. Il sert à représenter, concevoir et documenter beaucoup -d'aspect d'un logiciel. Nous en sommes actuellement à la version 2.5.1 (2017). - -UML Propose 14 type de diagrammes divisés en trois familles: - - * **Les diagrammes de structures**: essentiellements liés aux codes sources - pour les paquetages, les classes, les déploiements, les composants ... - * **les diagrammes de comportements**: liés à l'exécution (dynamique) des - programmes comme l'activité, les cas d'utilisations, les états-transitions. - Cette famille comprend aussi les **diagrammes d'interaction**: séquences, - communications etc. - -**5 diagrammes** sont utiles pour l'expression des besoins. Il existe trois -modes de programmation: - - * Langage de programmation UML avec étape de compilation qui permet de produire - des **executables** - * Project director où les diagrammes produits permettent d'être utilisés dans - des outils d'aide et de synthèses. - * mode esquisse afin d'inclure seulement les éléments principaux sans être - obligatoirement exhastifs. - -Les diagrammes UML sont utiles pour représenter des ensembles de besoins en -présentant les différents aspects de manière synthetique sans faire référence à -une implémentation. Nous pouvons voir: - - * Les diagrammes de comportements comprenant les diagrammes de *cas - d'utilisations*, diagrammes de *séquences*, les diagrammes *d'activités*, les - diagrammes *de machines à états*; - * Les diagrammes de structures: les diagrammes *de déploiement*. - -### LEs diagrames de cas d'usages - -Modélisent les interactions sympa entre les fonctionnalités proposées par le -programme et les utilisateurs. Il sont constitués de: - - * **use cases** représentant les fonctionnalités (besoins fonctionnels - généraux), il faut les nommer sans pour autant les décrire; - * **actors** représentant les utilisateurs et autres élements déclencheurs des - cas d'utilisation - * **associations** représentant les arrêtes entre nos acteurs et cas - d'utilisation. - -Les contraines de temps n'ont pas lieu d'êtres ici (enchaînement). Les cas -d'utilisations sont indépendants et le déclenchement ne se fait que par un seul -acteur à la fois. - -Il est possible d'affiner ces graphes: - - * par des **inclusions** via `include` (arcs pointillés), par exemple - relations entre cas d'usage et ses sous-cas; - * Par des **extentions** via `extends` (arcs pointillés avec étiquette - *extends*), par exemple pour étendre un cas (les étendus ne connaissent pas - cesux les étandant) - * Par des **généralisations** (arcs pleins et flêches en pointillet)pour les - cas d'utilisations précisés en cas *spécifiques* d'utilisation. - -Ces diagrammes dont des représentation **simplifiées** de scénarios sans les -descriptions associés - -### Diagrammes de séquences - -Modélisents une suite d'interactions entre les éléments avec comme éléments: - - * les **participants**: éléments ou objets associés à une ligne de temps - verticale en pointillés afin d'indiquer leur activité; - * les **interactions**: requêtes, messages, appels de méthodes envoyés entre - les participants dans un ordre déterminés, symbolisés par des arcs - étiquettés. Les origines et destinations pointent vers les rectangles des - *participants*. - -Il precisent et complètent les scénario. chaque diagrammes se focalisent sur un -cas d'usage / scénario à la fois. - -### Diagrammes d'activités - -eprésentent une suites d'activités parfois parallèles d'un processus avec des -possibilités de contrôle de flux. diff --git a/content/reseaux_protocoles/3_couche_transport/index.md b/content/reseaux_protocoles/3_couche_transport/index.md deleted file mode 100644 index 99e362f..0000000 --- a/content/reseaux_protocoles/3_couche_transport/index.md +++ /dev/null @@ -1,195 +0,0 @@ - ---- -title: "Réseaux et Protocole: couche transport" -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(); -```