41
Informatique Repartie Chapitre 3 : Conception de Systèmes Repartis Cecilia Zanni-Merk [email protected] Bureau BO B R1 04 Basé sur le cours de M Laurent Vercouter, INSA Rouen Normandie, 2017

Informatique Repartie Chapitre 1 : Conception

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Informatique RepartieChapitre 3 : Conception de Systèmes

RepartisCecilia Zanni-Merk

[email protected]

Bureau BO B R1 04

Basé sur le cours de M Laurent Vercouter, INSA Rouen Normandie, 2017

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing2

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing3

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing4

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

• Le réseau est sécurisé

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing5

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

• Le réseau est sécurisé

• La topologie de l’application est statique

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing6

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

• Le réseau est sécurisé

• La topologie de l’application est statique

• Il y a un seul administrateur du réseau

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing7

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

• Le réseau est sécurisé

• La topologie de l’application est statique

• Il y a un seul administrateur du réseau

• Le coût du transport est nul

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing8

Les huit erreurs conceptuelles des applications reparties• Le réseau est fiable

• La latence est nulle

• La bande passante du réseau est infinie

• Le réseau est sécurisé

• La topologie de l’application est statique

• Il y a un seul administrateur du réseau

• Le coût du transport est nul

• Le réseau est homogène

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing9

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

10

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

• Pour des applications ouvertes, identification et prise en compte de connecteurs externes

11

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

• Pour des applications ouvertes, identification et prise en compte de connecteurs externes

• Prise en compte d’environnements non homogènes avec des langages différents

12

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

• Pour des applications ouvertes, identification et prise en compte de connecteurs externes

• Prise en compte d’environnements non homogènes avec des langages différents

• La qualité de service de la communication

13

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

• Pour des applications ouvertes, identification et prise en compte de connecteurs externes

• Prise en compte d’environnements non homogènes avec des langages différents

• La qualité de service de la communication

• La prise en compte des couches de communication / réseau / SE

14

Complexité accrue dans la conception de logiciels repartis• Réflexion sur la topologie de l’application et sur les interfaces entre

systèmes

• Pour des applications ouvertes, identification et prise en compte de connecteurs externes

• Prise en compte d’environnements non homogènes avec des langages différents

• La qualité de service de la communication

• La prise en compte des couches de communication / réseau / SE

• Des problématiques non fonctionnelles supplémentaires• Problèmes de sécurité et d’identification• Problèmes de répartition de charge, de reprise sur panne, de persistance des

données, de reprise sur erreur15

Rappels UML 2.0

16

Démarche

• Approche similaire à la conception d’un site Web

ou de communication (UML 2,0)

17

Protocoles de communication

• Diagrammes d’interaction entre entités distribuées• Sémantique des messages

• Type• Contenu (arguments)

• Protocole de communication• Enchaînements possibles de messages• Messages attendus• Envois possibles

• Remarque• Tout protocole de communication peut se décomposer en suites de

Requête(s) [-Réponse(s)]• Chaque interaction élémentaire est équivalente à une requête de type

Client/Serveur

18

Diagrammes UML utiles

• De composants : liste les composants logiciels

• De déploiement : définit la répartition des composants sur une architecture matérielle

• D’interaction• De séquence : représente les scenarios d'interactions entre entités du

système

• De communication : version simplifiée de séquences entre objets par l’échange de messages plus détaillé

• Global d'interaction : représente les enchaînements entre scenarios (identifiés dans différents diagrammes de séquence)

19

Diagrammes de séquence (rappel)

• Diagramme qui représente les interactions entre classes par chronologie d'appels de méthode

• Un diagramme de séquence illustre un cas d'utilisation

• Le temps est représente par un axe vertical

20

Diagrammes de séquence (rappel)

21

Diagrammes de composants (rappel)

• Un composant regroupe un ensemble de ressources (objets, fichiers, bibliothèques, ...) de l'application pour en faire une entité réutilisable et/ou à déployer sur un support matériel.

• Il est décrit par des interfaces fournies et requises• Une interface fournie est une fonctionnalité implémentée par le composant

que d'autres composants peuvent appeler.

• Une interface requise est une fonctionnalité que le composant doit pouvoir utiliser et implémentée par d'autres.

22

Diagramme de déploiement

• Un diagramme de déploiement est la description de la configuration matérielle par l'emplacement des composants logiciels et matériels sur les nœuds de l'architecture.

• Il relie les interfaces requises et fournies des composants pour définir la manière dont ils communiquent.

• Les ressources matériels (ordinateur, périphériques, . . . ) sont représentes par des nœuds.

23

Diagramme de déploiement

24

Démarche de mise en oeuvre

https://laurent-audibert.developpez.com/Cours-UML/

25

Identification des besoins

26

Les besoins sont modélisés par un diagramme de cas d'utilisation.

Identification des besoins

27

Les diagrammes de séquence système illustrent la description textuelle des cas d'utilisation.

Identification des besoins

28

Une maquette d'IHM facilite les discussions avec les futurs utilisateurs.

Phase d’analyse

29

La phase d'analyse du domaine permet d'élaborer la première version du diagramme de classes.

Phase d’analyse

30

Le diagramme de classes participantes effectue la jonction entre les cas d'utilisation, le modèle du domaine et les diagrammes de conception logicielle.

Phase d’analyse

31

Les diagrammes d'activités de navigation représentent graphiquement l'activité de navigation dans l'IHM.

Phase de conception

32

Les diagrammes d'interaction permettent d'attribuer précisément les responsabilités de comportement aux classes d'analyse.

Phase de conception

33

Le système des diagrammes de séquences système, vu comme une boîte noire, est remplacé par un ensemble d'objets en collaboration.

Phase de conception

34Le diagramme de classes de conception servira pour l’implémentation

Livrables pour projet

35

Document de spécifications

• Introduction• Il s'agit d'une description informelle du projet et de son contexte.• On doit y trouver notamment comme informations :

• la liste des fonctions principales,• Les différents utilisateurs et leurs caractéristiques,• les contraintes matérielles et logicielles.

• Besoins détaillés• C'est la partie contractuelle à proprement parler puisqu'elle formalise le besoin.• Elle consiste 3 parties distinctes :

• les spécifications fonctionnelles (souvent appelées lotissement)• les spécifications d'interfaces• les spécifications opérationnelles (performance, sécurité, ...)

• Ces différents éléments peuvent s'appuyer en UML sur des diagrammes de cas d'utilisation, d'un diagramme de modèle du domaine, de maquettes et d'un diagramme de navigation, en fonction des besoins.

36

Document de conception

• Trois sections• Introduction

• Conception préliminaire

• Conception détaillée

• Introduction• Il s’agit d’une description informelle du projet et de son contexte. Elle est souvent

relativement similaire à l’introduction d’un document de spécification.

• On doit y donc y trouver notamment comme informations :• la liste des fonctions principales,

• les différents utilisateurs et leurs caractéristiques,

• les contraintes matérielles et logicielles.

37

Document de conception

• Conception préliminaire• Cette étape consiste à réaliser une conception macroscopique, c’est-à-dire permettant de

mener à un découpage en packages avec les signatures externes de chaque package. Cette étape peut s’appuyer en UML sur :• Un diagramme de modèle du domaine (si non spécifié) ;• Des diagrammes de séquence système (si non spécifiés) ;• Des maquettes (si non spécifiées) ;• Des diagrammes d’activités de navigation (si non spécifiés) ;• Des diagrammes d’interaction ;• Un diagramme des classes de conception préliminaire ;• Un découpage en packages et les signatures externes de chaque package.• Un diagramme de déploiement

• Conception détaillée• Cette étape consiste à détailler par package les éléments les constituant.• Concrètement, il s’agit principalement de préciser les attributs et méthodes de classe de

toutes les classes participantes et de les regrouper dans un diagramme de classes. Les méthodes d’un package qui seront considérées comme non triviales devront être commentées et voir leur fonctionnement détaillé par du pseudo-code.

38

Rapport final

• Doit contenir• Spécifications (Document de spécifications mis à jour si nécessaire)

• Conception (Document de conception mis à jour si nécessaire),

• Choix techniques justifiés

• Améliorations possibles (non prévues dans les spécs)

39

Pour s’entrainer …

40

Exercice : Calculatrice distribuée sur complexes en Client-Serveur• Votre calculatrice supportera 4 types d’opération : additions, soustractions,

multiplications et divisions• Vous définirez vous-même les protocoles de communication. Le serveur

devra pouvoir traiter les 4 opérations précédemment citées et tenir compte d’une éventuelle division par zéro. Le client devra également prévenir le serveur s’il se déconnecte ou s’il souhaite éteindre le serveur.

• L’IHM fournie permet la saisie de commandes (‘QUIT’ pour demander une fin de connexion et ‘KILL’ pour éteindre le serveur) et d’opérations sur des complexes, avec parenthèses possibles (ex : ‘(2+4i)/2i’). À noter que la partie imaginaire doit toujours être précisée, même si elle vaut 1 (ex : ‘2+1i’).

• Votre serveur devra pouvoir traiter simultanément des requêtes en provenance de différents clients ; pour un client, la connexion ne sera coupée qu’à la demande de celui-ci.

41