Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Informatique RepartieChapitre 3 : Conception de Systèmes
RepartisCecilia Zanni-Merk
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
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 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
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.
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
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