Compare commits
No commits in common. "93b5cc567d38f3fe3aabc4ab73c677cc9591b046" and "6317896a16689669c395293a4eef1789f148d0d7" have entirely different histories.
93b5cc567d
...
6317896a16
2 changed files with 0 additions and 307 deletions
|
|
@ -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 **executables**
|
|
||||||
* 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.
|
|
||||||
|
|
@ -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*:
|
|
||||||
|
|
||||||
```
|
|
||||||
<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();
|
|
||||||
```
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue