7/10/13
1
IUT de LYON
Module Analyse et Conception avec
UML (Unified Modelling Language)
Les Cas
d’Utilisation
(Use Case)
...
7/10/13
2
3
Cas d’utilisation : présentation
  Diagramme de description du QUOI FAIRE
  Quelles sont les fonctionnalités...
7/10/13
3
5
Exemple : diagnostic médical
médecin
patient
secrétaire
Règlement / facturation
Élaboration d’un diagnostic
Pr...
7/10/13
4
7
Cas d’utilisation : construction
  On part des acteurs identifiés dans l’étude
préliminaire
  chercher les i...
7/10/13
5
9
Validation
  Pour chaque cas d’utilisation candidat :
  vérifier qu’il fournit une VA notable à l’acteur
  ...
7/10/13
6
11
Ex. Planification missions
  Acteur principal = répartiteur
  Intentions
  planifier les missions d’une ag...
7/10/13
7
13
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
14
Formalisme des cas d’utilisation
  Différ...
7/10/13
8
15
Héritage entre Acteurs
UML V. Deslandres – IUT de LYON
16
Relations « includes, extends »
Cas de base Cas de ...
7/10/13
9
17
Autres relations entre cas
  Relation d’inclusion « include » :
  La réalisation d’un cas de base passe
obl...
7/10/13
10
19
Corrigés des exemples
Quelles relations utiliser ?
UML V. Deslandres – IUT de LYON
Modification
document
Vér...
7/10/13
11
21
Use Case : Gestion comptabilité
UML V. Deslandres – IUT de LYON
7/10/13
12
23
Package en UML = concept commun de regroupement :
Structuration des cas d’utilisation
Structuration par pack...
7/10/13
13
Relations entre packages
import
include
use
UML V. Deslandres – IUT de LYON
26
Regroupement en packages : SIVEX...
7/10/13
14
1. Contexte d'apprentissage d'UML
2. Développement logiciel
3. Application de téléchargement de Cours
28
Exempl...
7/10/13
15
29
Exemple 2 : cas d’utilisation de
fonctionnement
  Cas d'utilisation de développement de logiciel
Chef de pr...
7/10/13
16
Questions sur l’ex. 3
•  Pourquoi ne voit-on pas le cas « Visualiser un
cours » (description, pré requis, etc.)...
7/10/13
17
33
Quel format de description ?
  Il existe différents modèles de cas d’utilisation détaillé
  Le plus répand...
7/10/13
18
35
Use Cases : réponse
  Les 3 cas du milieu sont utiles à différents niveaux
d’abstraction, en fonction des a...
7/10/13
19
37
Exemple sur l’exercice
  « Se connecter » : processus Métier ? plus value ?
  Non, but secondaire
  « se ...
7/10/13
20
39
Autres risques
  Ne pas mélanger l’IHM et le fonctionnel
  on décrit le métier des acteurs, indépendamment...
7/10/13
21
41
Démarche détaillée
Cas d’Utilisation / Diagramme de Classes
(1) Présentation du contexte et du sujet
(2) Ide...
7/10/13
22
43
(5) Pour chaque cas d'utilisation :
  Détailler son fonctionnement par un diagramme d’activités
  Chaque a...
7/10/13
23
45
6.  Si nécessaire, réunir les objets des
différents cas dans un unique
diagramme de classes
(bien entendu un...
7/10/13
24
47
Site vente en ligne
Client
Maintenance site
Gestion des
Clients
Consultation
Catalogue
Gestion des
Commandes...
7/10/13
25
49
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
50
Ex SIVEX Description du Cas
« Planificati...
7/10/13
26
51
DEF Enchaînements
  Enchaînement nominal = fonctionnement normal
  ex.: dans le processus d’appel téléphon...
7/10/13
27
53
« Planification des missions » (3/5)
  Exceptions identifiées :
– Pour une mission donnée, dépassement de t...
7/10/13
28
55
« Planification des missions » (5/5)
  Contraintes non fonctionnelles : temps de
réponse
– Interface répart...
Prochain SlideShare
Chargement dans…5
×

Cours2 uml usecase

471 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
471
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Cours2 uml usecase

  1. 1. 7/10/13 1 IUT de LYON Module Analyse et Conception avec UML (Unified Modelling Language) Les Cas d’Utilisation (Use Case) 2 Cas d’utilisation : présentation   les « use case » d’Ivar JACOBSON   Décrire une utilisation du système (ensemble de séquences d’actions) par un acteur particulier   Acteurs externes à l’application   Un acteur = un rôle   Modélise l’un des aspects (comportement / service) du système par rapport à cet acteur   doit renseigner sur le rôle particulier de l’acteur (VA) UML V. Deslandres – IUT de LYON
  2. 2. 7/10/13 2 3 Cas d’utilisation : présentation   Diagramme de description du QUOI FAIRE   Quelles sont les fonctionnalités : on décrit les cas précis d'utilisation de l'application Ex.: Utilisations d'un téléviseur   Pour regarder les chaînes publiques   Pour regarder le câble   Pour programmer/enregistrer avec son magnéto-cassette   Pour visionner avec son caméscope   Pour faire de l'internet   Comme miroir ou porte aquarium !   Mais pas du COMMENT   ni manipulation d’IHM, ni gestion des erreurs matérielles UML V. Deslandres – IUT de LYON 4 Cas d’utilisation (2)   L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences attendues du système   Expression des besoins fonctionnels   Chaque « cas » = une fonction Métier du système selon le point de vue d’un des acteurs   C’est un ensemble d’échanges entre l’acteur et le système : un acteur demande des traitements, le système fournit des services   Représentation : acteurs et patates !   Chaque « patate » est un « cas d’utilisation » du système UML V. Deslandres – IUT de LYON
  3. 3. 7/10/13 3 5 Exemple : diagnostic médical médecin patient secrétaire Règlement / facturation Élaboration d’un diagnostic Proposition du traitement Analyse des symptômes Gestion des RDV << include >> << include >> UML V. Deslandres – IUT de LYON 6 Exemple : agence de banque guichetier client responsable clientèle Effectuer opérations sur Les comptes Gérer les clients Planifier des rendez-vous Gestion de commande Ouvrir un compte Prospecter UML V. Deslandres – IUT de LYON
  4. 4. 7/10/13 4 7 Cas d’utilisation : construction   On part des acteurs identifiés dans l’étude préliminaire   chercher les intentions (métier) avec lesquelles il utilise le système   déterminer dans le CdesCh les services fonctionnels attendus UML V. Deslandres – IUT de LYON 8 Construction des cas   On utilise les échanges de messages identifiés dans le contexte dynamique   Distinguer l’acteur principal des acteurs secondaires   Acteur principal: pour lequel le Cas produit la plus- value métier (souvent : le déclencheur)   L'acteur secondaire ne fait que recevoir le résultat obtenu à l'issue de la réalisation de l'utilisation envisagée (en général placé à droite) UML V. Deslandres – IUT de LYON
  5. 5. 7/10/13 5 9 Validation   Pour chaque cas d’utilisation candidat :   vérifier qu’il fournit une VA notable à l’acteur   contrôler qu’un événement externe en déclenche l’exécution   Ne pas descendre trop bas : un UC n’est ni une transaction, ni une fonction du système !   Ex.: saisie des commandes, elles peuvent l’être via le web, via les feuilles issues du service commercial, ou manuellement après contacts téléphoniques.   Ca conduit donc à 3 séquences d’actions différentes mais pour un seul cas d’utilisation : la saisie des commandes.   REGLE : un cas d’utilisation doit regrouper au moins 2 séquences (sans compter les exceptions)   Séquence principale + alternative UML V. Deslandres – IUT de LYON UML V. Deslandres – IUT de LYON 10 Etude de cas SIVEX   On part du diagramme de contexte dynamique   Chercher l’« intention fonctionnelle » de chaque acteur dans son intéraction avec le système   Quelle fonctionnalité le concerne dans l'application ?   S’inspirer des messages   Regrouper les intentions en unités cohérentes
  6. 6. 7/10/13 6 11 Ex. Planification missions   Acteur principal = répartiteur   Intentions   planifier les missions d’une agence, permettant la réalisation des commandes en cours   Actions :   créer une nouvelle mission :   regrouper des commandes, affecter des ressources disponibles, établir un parcours, évaluer les durées, le volume nécessaire pour la camionette, etc…   modifier ou annuler une mission existante UML V. Deslandres – IUT de LYON 12   Acteur principal = Ex. Suivi de mission chauffeur • Intentions • Actions Informer en temps réel de l’état d’avancement de la mission en cours - Transmettre chaque arrêt et départ d’étape - Signaler les événements de mission acquittement client, panne, retard, absence client... UML V. Deslandres – IUT de LYON
  7. 7. 7/10/13 7 13 Use Case : Gestion des missions UML V. Deslandres – IUT de LYON 14 Formalisme des cas d’utilisation   Différents types de relations   Relation entre un acteur et un cas : - trait simple : l'acteur déclenche le cas - flèche vers acteur : l'acteur reçoit le résultat du cas (acteur secondaire)   Relation d’héritage entre cas : un cas d'utilisation (une fonctionnalité) dérive d'une fonctionnalité plus générale   ex.: « Sélection d'une location de vacances » et « Sélection d'une péniche pour un séjour » Relation d’héritage entre cas UML V. Deslandres – IUT de LYON
  8. 8. 7/10/13 8 15 Héritage entre Acteurs UML V. Deslandres – IUT de LYON 16 Relations « includes, extends » Cas de base Cas de base Cas inclus extension <<include>> <<extend>> UML V. Deslandres – IUT de LYON
  9. 9. 7/10/13 9 17 Autres relations entre cas   Relation d’inclusion « include » :   La réalisation d’un cas de base passe obligatoirement par celle d’un cas spécifique inclus   (objectif : factorisation)   Ex. : procédure d’authentification   Relation d’extension « extend » :   Cas de base incorpore une extension, à un point d’extension prévu   (obj.: représenter un comportement optionnel)   Ex. : la prise de commande peut conduire à la création d’un nouveau client UML V. Deslandres – IUT de LYON 18 Exemples Quelles relations utiliser ? UML V. Deslandres – IUT de LYON Modification document Vérification droit d’accès ? Saisie commande Vérification stock ? Développement pages d’un site web Définition charte graphique ? Modification document Vérification droit d’accès include Développement pages d’un site web Définition charte graphique extends Saisie commande Vérification stock include
  10. 10. 7/10/13 10 19 Corrigés des exemples Quelles relations utiliser ? UML V. Deslandres – IUT de LYON Modification document Vérification droit d’accès include Développement pages d’un site web Définition charte graphique extends Saisie commande Vérification stock include 20 Use Case SIVEX : Gestion des Commandes Consultation d'en-cours Client Réceptionniste Gestion de Commande secondaire Gestion des Clients (nouveau client) <<extend>> Point d'extension : nouveau client UML V. Deslandres – IUT de LYON
  11. 11. 7/10/13 11 21 Use Case : Gestion comptabilité UML V. Deslandres – IUT de LYON
  12. 12. 7/10/13 12 23 Package en UML = concept commun de regroupement : Structuration des cas d’utilisation Structuration par package   d’éléments d’un modèle   de diagrammes de ces éléments   d’autres packages   Contraintes :   tout élément n’appartient qu’à un seul paquetage   Ensemble cohérent au niveau sémantique (expertise métier)   Représentation : icône de dossier UML V. Deslandres – IUT de LYON 24 Techniques de regroupement   Par domaine d’expertise métier   regroupement le plus intuitif et efficace   permet de faciliter la spécilisation des analystes   organiser facilement la répartition des experts   Par acteur   facile si chaque cas est relié à UN seul acteur   Par lot de livraison client   dans le cas d’un développement incrémental, c ’est parfois un critère utilisé UML V. Deslandres – IUT de LYON
  13. 13. 7/10/13 13 Relations entre packages import include use UML V. Deslandres – IUT de LYON 26 Regroupement en packages : SIVEX - Par domaine d’expertise métier - Ensembles d’acteurs fortement liés Définition du plan de transport, et des ressources Acteurs: resp. logistique Définition des profils utilisateur Acteur: administrateur Gestion clients, gestion des commandes, consultation des en-cours Acteurs : réceptionniste, client UML V. Deslandres – IUT de LYON
  14. 14. 7/10/13 14 1. Contexte d'apprentissage d'UML 2. Développement logiciel 3. Application de téléchargement de Cours 28 Exemple 1 : cas d’utilisation décrivant un fonctionnement   Cas d'utilisation décrivant le contexte dans lequel vous allez apprendre à concevoir avec UML à l'IUT… Impétrant assister aux cours lire ouvrages rechercher informations Présenter le formalisme UML Proposer des exercices Evaluer impétrants Enseignant UML V. Deslandres – IUT de LYON
  15. 15. 7/10/13 15 29 Exemple 2 : cas d’utilisation de fonctionnement   Cas d'utilisation de développement de logiciel Chef de projet (maîtrise d'œuvre) Maître d'ouvrage Architecte logiciel Architecte technique Utilisateur Développeur Piloter le processus développement Objet Concevoir une architecture technique Organiser le développement logiciel et les tests Définir les besoins Tester UML V. Deslandres – IUT de LYON 30 Exemple 3 : cas d’utilisation d’une application informatique   Décrivant le téléchargement d’un Cours Internaute BD Users / droits Chercher un cours Sélectionner un ou plusieurs cours Télécharger un cours Ouvrir l’application Authentification Serveur de Cours Connexion include extends UML V. Deslandres – IUT de LYON Abonné S’abonner extends
  16. 16. 7/10/13 16 Questions sur l’ex. 3 •  Pourquoi ne voit-on pas le cas « Visualiser un cours » (description, pré requis, etc.) ? ▫  Pourquoi voit-on le cas « Rechercher un Cours » ? •  Que représentent les cas inclus pour l’application ? Pourquoi les isole-t-on ? •  Quel est le choix de conception du Client pour ce site ? (qui pourrait être différent) •  Les cas sont incomplets : lesquels ajouter ? - Contrôler le nb de cours téléchargés - Déposer un commentaire UML V. Deslandres – IUT de LYON 32 Description des Cas d’utilisation On décrit les cas d’utilisation avec des diagrammes d’abord, et éventuellement sous forme textuelle.   Structure de description des cas d’utilisation   qui permet de mieux les exploiter par la suite :   sommaire d’identification (titre, but, résumé, acteurs, dates, version, responsable)   description des enchaînements (nominaux, exceptionnels, pré-post conditions)   éventt : besoins d’IHM   éventt : contraintes non-fonctionnelles (fréquence, volumétrie, disponibilité, confidencialité, performances…) UML V. Deslandres – IUT de LYON
  17. 17. 7/10/13 17 33 Quel format de description ?   Il existe différents modèles de cas d’utilisation détaillé   Le plus répandu est celui de www.usecases.org   (cf SIVEX, et ex. ici)   Description :   Titre, acteur principal, parties prenantes et intérêts, pré et post conditions, scénario principal (happy path, succès) sans condition ni branchement, extensions (scénarios d’exception);   Spécifications particulières (hors contraintes fonctionnelles : interface, langue, temps de réponse);   Technologies envisagées ou évolutions à MT (ex. actuellement chèque accepté, en Juin 2003, plus de chèque), questions à se poser. UML V. Deslandres – IUT de LYON 34 Exercice : quelle validité des UC   Soit un système de vente en ligne   Lesquels de ces cas d’utilisation seraient valides ?   Supprimer un article   Négocier un contrat avec un fournisseur   Traiter les retours   Se connecter   Imprimer un document UML V. Deslandres – IUT de LYON
  18. 18. 7/10/13 18 35 Use Cases : réponse   Les 3 cas du milieu sont utiles à différents niveaux d’abstraction, en fonction des acteurs et des objectifs.   La question plutôt à se poser est :   À quel niveau faut-il exprimer un cas d’utilisation de façon à se qu’il soit utile pour l’analyse des besoins ?   Il faut pour cela identifier les Processus métier élémentaires UML V. Deslandres – IUT de LYON 36 Quels cas d’utilisation créer   Identifier les Processus Métier pour lesquels il y a valeur ajoutée observable et mesurable   Qui laissent le système dans un état stable et cohérent   Définir les acteurs externes et internes et se concentrer sur leurs intentions   Notamment ne pas raisonner en interface utilisateur UML V. Deslandres – IUT de LYON
  19. 19. 7/10/13 19 37 Exemple sur l’exercice   « Se connecter » : processus Métier ? plus value ?   Non, but secondaire   « se connecter pour commander » : OK ( traiter vente)   « se connecter pour enregistrer les ventes du mois » : OK ( enrichir statistiques)   « se connecter pour mettre à jour le catalogue » : OK ( gérer articles)   « Supprimer un article » : secondaire aussi !   Gestion Article plus appropriée   « Imprimer un document » : inutile ici   activité technique, pas un besoin Métier   (L’étape d’authentification n’est jamais un processus métier, sauf pour une modélisation purement informatique !) UML V. Deslandres – IUT de LYON 38 Risques associés aux Cas   Ne pas réinventer la décomposition fonctionnelle !   On fait de l’analyse ORIENTEE OBJET !!   Ne pas aller trop loin dans le détail, on en est à la capture des besoins fonctionnels.   Limiter à 10 le nombre de (« grands ») CU, rester synthétique   Les Cas d’utilisation ne sont pas une fin en soi, leur objectif est de :   dialoguer avec le client, le rassurer sur ce qu’on a compris   analyser les besoins métier,   démarrer l’analyse en identifiant les classes candidates. UML V. Deslandres – IUT de LYON
  20. 20. 7/10/13 20 39 Autres risques   Ne pas mélanger l’IHM et le fonctionnel   on décrit le métier des acteurs, indépendamment des choix d’interface qui pourront évoluer… – ex.: préférer « lors d’une 1ère commande, le réceptionniste enregistre les caractéristiques du nouveau client dans le système » à : – « le réceptionniste saisit le nom du client en 8 car. max, en majuscules, appuie sur ENTER, puis saisit le prénom en minuscules » ou à – « le réceptionniste enregistre par un syst. de reconnaissance vocale les nom, prénom, adresse et code postal du client » UML V. Deslandres – IUT de LYON DEMARCHE UML •  On part d’une étude de contexte ▫  Diagramme de contexte statique ▫  Diagramme de contexte dynamique •  On construit les diagrammes de Cas d’utilisation •  On les regroupe en packages si besoin •  On en déduit les classes, on fait de premiers diagrammes de classes ▫  partiels ou global UML V. Deslandres – IUT de LYON
  21. 21. 7/10/13 21 41 Démarche détaillée Cas d’Utilisation / Diagramme de Classes (1) Présentation du contexte et du sujet (2) Identifier les acteurs externes du système à l’aide d’un diagramme de contexte statique   Acteurs = rôles joués par des personnes ou systèmes externes   Les acteurs internes (ex.: comptables, serveur de BD… ) apparaîtront plus tard dans la modélisation   Penser à l’environnement humain et informatique   Nommer ces acteurs UML V. Deslandres – IUT de LYON 42 Démarche Cas d’utilisation (2) (3) Ajouter les échanges d'informations acteurs / système   les nommer, éventuellement les définir par une phrase   créer ainsi le diagramme de contexte dynamique (4) Construire le diagramme des cas d'utilisation : identifier les services rendus aux acteurs par le système (tâches)   étude plus fine des interactions acteurs / système, en dissociant les grandes fonctions   nommer les services rendus, les définir par une phrase   Règle : avoir plusieurs séquences d’actions par CU (« enregistrer un client » = si c’est juste une saisie, ça n’est pas un CU; préférer « Gestion Client ») UML V. Deslandres – IUT de LYON
  22. 22. 7/10/13 22 43 (5) Pour chaque cas d'utilisation :   Détailler son fonctionnement par un diagramme d’activités   Chaque activité peut être élémentaire   On peut montrer les séquences et les alternatives (6) Associés aux activités, définir les objets partagés entre acteurs et système :   Objets traités, mémorisés, produits, transformés   objets du monde modélisé   objets importants pour les acteurs   objets persistants ou pas   Cela va aider à identifier les classes candidates Démarche Cas d’utilisation / diag Classes (3) UML V. Deslandres – IUT de LYON 44   Lister et nommer les objets (avec le vocabulaire des acteurs), les définir par une phrase   Identifier ensuite les classes candidates et construire un diagramme de classes   par package   Relier les objets, nommer les liens, les définir par une phrase Pour chaque cas d’utilisation (suite) UML V. Deslandres – IUT de LYON
  23. 23. 7/10/13 23 45 6.  Si nécessaire, réunir les objets des différents cas dans un unique diagramme de classes (bien entendu un même objet peut intervenir dans les différents cas d’utilisation envisagés : Ex. dans une application de type « Editeur logiciel », un document sera déposé, validé, fusionné, chaque action correspond à un CU) Démarche Cas d’utilisation / Diag Classes (4) UML V. Deslandres – IUT de LYON 46 Exercice : site vente en ligne   Client : consulte, achète des produits, demande un renseignement, souhaite obtenir un RV personnalisé, etc.   Administrateur : ouvre comptes, etc.   Responsable Produits : MàJ le catalogue, veille   Technicien : répond aux questions techniques sur les produits UML V. Deslandres – IUT de LYON
  24. 24. 7/10/13 24 47 Site vente en ligne Client Maintenance site Gestion des Clients Consultation Catalogue Gestion des Commandes MàJ Catalogue extends extends Veille technologique Renseignements techniques Authentification includes Administrateur Resp. Produits Technicien UML V. Deslandres – IUT de LYON Exemple de Cas d’Utilisation SIVEX SIVEX: Planification des missions (fiche de description)
  25. 25. 7/10/13 25 49 Use Case : Gestion des missions UML V. Deslandres – IUT de LYON 50 Ex SIVEX Description du Cas « Planification des missions » (1/5)   BUT : planification des missions d’enlèvement, de transport ou de livraison, d’une agence à partir du plan de transport, des commandes à assurer quotidiennement et des ressources disponibles • RESUME : création d’une nouvelle mission à partir des cdes confirmées, modification et annulation d’une mission existante. • ACTEURS : • PRE-CONDITIONS : - le répartiteur est authentifié - les commandes à planifer sont confirmées répartiteur (ppal), chauffeur (sec.) UML V. Deslandres – IUT de LYON
  26. 26. 7/10/13 26 51 DEF Enchaînements   Enchaînement nominal = fonctionnement normal   ex.: dans le processus d’appel téléphonique, fonctionnement nominal =   Enchaînement exceptionnel = fonctionnement anormal, traitement des événements exceptionnels   ex.: dans le processus d’appel téléphonique, fonctionnement exceptionnel = Décrocher combiné, entendre sonnerie attente, composer numéro, attendre sonnerie appel, communiquer, raccrocher Décrocher combiné, pas de sonnerie d’attente, vérifier branchement ligne, (suite) UML V. Deslandres – IUT de LYON 52 « Planification des missions » (2/5)   Enchaînements identifiés : – créer une mission en attente – affecter des commandes à une mission – affecter les ressources – modifier une mission en attente (désaffecter une commande, modification des chauffeurs ou véhicule, modification des étapes…) – valider une mission en attente – modifier une mission validée – annuler une mission (en attente ou validée) – éditer les bordereaux de mission UML V. Deslandres – IUT de LYON
  27. 27. 7/10/13 27 53 « Planification des missions » (3/5)   Exceptions identifiées : – Pour une mission donnée, dépassement de tonnage véhicule – Chauffeur sélectionné non qualifié pour conduire le véhi-cule choisi pour la mission – Tonnage de réserve entammé (chaque agence doit se réser-ver un certain tonnage pour pouvoir répondre à des comman-des prioritaires ou de dépannage) – Estimation de temps incomplète pour une étape donnée donc pour la mission comportant cette étape UML V. Deslandres – IUT de LYON 54 « Planification des missions » (4/5)   Post-conditions – Tout ce qui est connu à l’issue du cas – Pour lister les commandes de l’agence, le répartiteur doit pouvoir répertorier les commandes de l’agence par type, poids, site desservi, affectée/non affectée, tarification urgent/ non urgent – Les commandes non affectées doivent être de couleur différente   Besoins d’IHM UML V. Deslandres – IUT de LYON
  28. 28. 7/10/13 28 55 « Planification des missions » (5/5)   Contraintes non fonctionnelles : temps de réponse – Interface répartiteur : moins de 2 secondes – Concurrence : les validations de mission doivent être notifiées aux lecteurs potentiels par un message d’avertissement en TR – Disponibilité : le système doit être accessible au répartiteurs 6 jours sur 7, aux heures d’ouverture des agences   Autres contraintes : UML V. Deslandres – IUT de LYON

×