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