Le Processus Unifi 1 Le Processus Unifi est

Le Processus Unifié 1

Le Processus Unifié est un processus (de développement de) logiciel • Méthode = Processus + Notation • UML est une notation graphique pour décrire les différents aspects d’un logiciel aux différents moments de son cycle de vie • Le Processus Unifié est un exemple de processus logiciel qui utilise la notation UML- Unified Modelling Language 2

Sources http: //en. wikipedia. org/wiki/Rational_Unified_Process 3

Plan du cours • Partie I : le Processus Unifié de développement de logiciel • • • Concepts de base Le processus unifié est piloté par les cas d’utilisation Le processus unifié est centré architecture Le processus unifié est itératif et incrémental Organisation matricielle • Partie II : les phases du développement du logiciel • • La phase de création lance le projet La phase d’élaboration fabrique l’architecture de référence La construction aboutit à un produit opérationnel La phase de transition finalise le produit • Partie III : les activités de développement de logiciel • • Spécification des besoins Analyse Conception Implémentation, Tests • Partie IV : retour sur les phases, croisement phases et activités 4

Le Processus Unifié Principes 5

Le Processus Unifié utilise les notations UML Équipe de développement Langage de Modélisation Processus unifié 6

Le Processus Unifié s’applique à mettre en œuvre les six directives de l’ingénierie logicielle (Best practices) 7

Plusieurs processus logiciel autour des mêmes principes • Il n’existe pas un seul Processus Unifié, mais un ensemble de caractéristiques essentielles: • Pilotage par les cas d’utilisation • Centré sur l’architecture • Itératif et incrémental • Et d’autres processus partagent beaucoup de principes avec RUP 8

Un processus piloté par les cas d’utilisation • Les cas d’utilisation lient les principales activités • L’architecture de référence met en œuvre le(s) cas d’utilisation central(aux) • Les cas d’utilisation organisent les tests de validation 9

Un processus piloté par les cas d’utilisation D’après « Le processus Unifié » Jacobson, Booch, Rumbaugh 10

Progression du développement des cas d’utilisation dans les phases. 11

Un processus centré architecture L’architecture (vue globale) regroupe et organise les différents points de vue du système en construction. Architecture: - Style d’architecture - Standards à utiliser - Sous-systèmes à ré-utiliser - Distribution des sous-systèmes 12

Un processus centré architecture Différentes vues qui s’appuient sur les différents modèles. Vue De réalisation Vue logique Vue des cas d’utilisation Vue du processus Vue de déploiement 13

Un processus centré architecture Architecture de référence • Architecture de référence (initiale) : • Style d’architecture • Cas d’utilisation significatif(s) fonctionnellement, en terme de risques principaux, y compris logiciel (distribution …) • « Squelette muni de quelques muscles » 14

Un processus itératif et incrémental • Incrément fonctionnel : injection d’un nouveau cas dans l’architecture courante • Itération : l’ensemble de l’architecture courante est retravaillée • Chaque itération produit une nouvelle version : • Enrichissement des livrables de l’itération précédente • Eventuellement nouveau cas 15

Un processus itératif et incrémental • Organisation matricielle: • Découpage en phases et en activités • Plusieurs itérations au sein d’une même phase • Chaque itération parcourt toutes las activités avec plus ou moins de profondeur • On définit une architecture de référence avec un (des) cas d’utilisation centraux et on itère en injectant de nouveaux cas. 16

Organisation matricielle Activités de développement Phases Création Élaboration Iter. #1 Iter. #2 #3 Construction Transition Besoins Analyse Conception Implémentation Tests Déploiement … … … Itérations Iter. #n-1 Iter. #n 17

Les phases 18

Un processus itératif et incrémental – Les phases Création Élaboration Construction Transition temps Le Processus Unifié comprend 4 phases : • Création - Définit le champ d’action du projet • Élaboration – Le plan de la construction, il spécifie les exigences, l’architecture • Construction – Réalise le produit • Transition - Transfère le produit vers les utilisateurs finaux « Démarrage » ou « Pré-étude » peut être utilisé à la place de « Création » ( « Elicitation » dans la terminologie anglaise) 19

Phase de « Création » Création Élaboration Construction Transition temps Vision - Besoins • Objectifs • Définir les limites du système • Identifier les usages • cas d’utilisation • interfaces utilisateurs • Esquisser une architecture initiale • Identifier les risques principaux • Résultats • Vision : glossaire, liste des acteurs, liste des cas d’utilisation classée, 10 % des cas d’utilisation représentatifs documentés, contraintes non fonctionnelles, liste des risques principaux, premier diagramme de classes, interfaces utilisateurs 20 • Feu vert du commanditaire

Phase d’ « Elaboration» Création Élaboration Construction Transition temps Vision Besoins Architecture • Objectifs • • Définir l’architecture de référence Préciser les cas d’utilisation (80 % des besoins fonctionnels) Planifier le projet Préciser les risques du projet (besoins, technologiques, compétences, politiques) • Résultats • Architecture de référence : concerne les cas d’utilisation centraux avec l’ensemble de leurs modèles d’analyse • Un planning du projet intégrant le calendrier, les coûts, le personnel • Une évaluation des risques et des éléments de protection 21

Phase de « Construction » Création Élaboration Construction Transition temps Vision Besoins Architecture Produit • Objectifs • Finalisation de la description et de la réalisation des cas d’utilisation • Finalisation de l’analyse, de la conception, de l’implantation et des tests informatiques • Validation par rapport aux risques • Validation par rapport à l’architecture de référence • Résultats • Produit version Béta, logiciel testé en interne, manuels 22

Phase de « Transition » Création Élaboration Construction Transition temps Vision Besoins Architecture Produit validé • Objectifs • Correction des derniers bugs liés au béta test • Validation par rapport aux besoins du cleint • Logiciel • Manuels • Résultats • Produit validé par les utilisateurs 23

Les activités de développement de logiciel. 24

Les activités produisent des modèles Besoins …………. Modèle des cas d’utilisation Analyse ……………. . Modèle d’analyse Conception ………………. Modèle de conception Modèle de déploiement Implémentation ……………………………. . . . Modèle d’implémentation Tests ………………………………. . . . Modèle des tests 25

Les modèles sont principalement constitués de diagrammes UML Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 26

Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 27

Modèle d’analyse Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 28

Modèle de conception Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 29

Modèle de conception Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 30

Modèle d’implémentation Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 31

Modèle d’implémentation Modèle des cas d’utilisation Diagramme de classes Modèle d’analyse Modèle de conception Diagramme d’objets Diagramme de composants Diagrammes de déploiement Diagrammes de séquence Modèle de déploiement Modèle d’implémentation Diagrammes de collaboration Diagrammes Etat-transition Diagrammes d’activité Modèle des tests 32

Les activités et les travailleurs 33

Recueil des besoins 34

La modélisation des besoins • « Modélisation métier » • Clarifier l’existant • Structure de l’organisation (si possible classes du domaine) • Vocabulaire commun • Mise en contexte de la problématique • « Modélisation des besoins » • Recueillir les besoins auprès des clients et des utilisateurs • Exprimer des besoins dans les cas d’utilisation • Définir les limites du système • Définir des interfaces utilisateurs • Définir des contraintes fonctionnelles et non fonctionnelles • Recenser et évaluer les risques 35

Workflow de la Modélisation Des Besoins Analyste système Trouver les acteurs et cas d’utilisation Analyste Cas d’utilisation Structurer le modèle des cas d’utilisation Détailler un d’utilisation Prototyper IHM Concepteur IHM Hiérarchiser les cas d’utilisation Architecte

Identifier les acteurs et les cas d’utilisation 37

Détailler les cas d’utilisation 38

Prototyper l’interface 39

Hiérarchiser les cas d’utilisation 40

Modèle des Besoins Cas d’utilisation * Modèle des cas d’utilisation * Acteurs 41

Modélisation des Besoins : Artefacts • Un document de vision • Liste classée des cas d’utilisation • Scénarios des cas d’utilisation. • Exigences fonctionnelles et non fonctionnelles : ce que va faire précisément le système • Glossaire • Une charte graphique, esquisse des principales interfaces • Un document listant les besoins de chaque jalon • Diagramme de cas d’utilisations (vision, ce que va faire le système …) • Diagrammes de collaboration, de séquence, à changement d’état, d’activités (description des scenarios) 42

Exemple GAB (Analyse des besoins) Aussi, mais très OO 43

L’ Analyse L’analyse synthétise les différents cas d’utilisation et en donne une vision unifiée 44

Recueil des besoins versus Analyse • Recueil des besoins • Formulé dans le langage du client • Structure la vue externe du système • Structuré avec les cas d’utilisation • Contrat entre les clients et les développeurs • Modèle d’analyse • Formulé dans le langage du développeur • Structure la vue interne du système • Structuré avec des packages et des stéréotypes • Indications aux développeurs de la forme du système pour la conception et la réalisation 45

Analyse • Mettre en évidence un (premier) jeu complet de classes • Réaliser les cas d’utilisation • Diagrammes de collaboration • Etendre les classes (attributs, responsabilités, associations …) • Analyser les classes • Synthétiser les classes existantes 46

Workflow d’Analyse Architecte Analyser l’architecture Ingénieur de cas d’utilisation Ingénieur de composants Analyser les cas d’utilisation Analyser les classes Analyser les paquetages

Analyser l’architecture 48

Réalisation des cas d’utilisation • Pour chaque cas d’utilisation : • Identifier les classes d’analyse • Réaliser les scénarios comme des diagrammes d’interaction • Synthétiser les classes, les valider par rapport aux cas d’utilisation 49

Analyser les cas d’utilisation 50

Analyser les classes 51

Analyser le paquetages 52

Modèle d’analyse * * Packages d’analyse * Réalisation de cas d’utilisation (diagrammes de classes, diagrammes de collaborations) Classe d’analyse (attributs, association, responsabilités, stéréotypes Frontière, Contrôle, Entité ) 53

Conseil méthodologique Architecture en couches UML- Unified Modelling Language 54

Architecture en couches T • Patron Entity/Control/Boudary • Patron Model/View/Controller (MVC) « Dialogue » Données saisies/affichées Opérations de l’interface < « Contrôle » Opérations de contrôle « Entité » Données du domaine 55

Architecture en couches T Stéréotype « Dialogue » Données saisies/affichées Opérations de l’interface < « Contrôle » Opérations de contrôle « Entité » Données du domaine 56

Classes d’analyse Elaborées à partir des UC • Classes Entité • Classes frontières T • Les données du système • Interfaces entre utilisateurs et système < • Classes de contrôle • Encapsulent le comportement d’un UC 57

Les classes Contrôle • Correspondent à un scénario d’utilisation • Font le lien entre les classes Interface et les classes Entité • Ont une durée de vie égale à celle de l’UC • Principalement des opérations, éventuellement quelques données de contrôle locales 58

Les classes Entités • Contiennent les données persistantes • La « base de données » , la « mémoire » de l’application • Partagées entre les UC • Un UC n’utilise en général pas toutes les données et toutes les opérations d’une classe • Principalement des attributs (opérations générales de manipulation des données) 59

Les classes Frontières • IHM • Lien entre les utilisateurs et les classes de contrôle, une classe frontière par couple (rôle, UC) • Principalement les opération pour utiliser l’IHM plus des données qui correspondent aux champs de saisie et aux données dérivées 60

Exemple UML- Unified Modelling Language 61

Exemple GAB (Analyse) 62

La conception 63

Analyse versus Conception • Modèle d’analyse • Modèle conceptuel • Autorise plusieurs conceptions • Peu de stéréotypes • Peu de couches • Modèle de conception • Modèle physique • Spécifique à une implantation • Stéréotypes dépendant de l’environnement cible • Plusieurs couches 64

Workflow de Conception Concevoir l’architecture Architecte Ingénieur de cas d’utilisation Ingénieur de composants Concevoir les cas d’utilisation Concevoir les classes Concevoir les sous-systèmes

Concevoir l’architecture • Estimer les besoins (physiques) : • Performance, concurrence, gestion des données, IHM, robustesse • Organiser le système en sous systèmes • Choisir un style architectural • Intégrer l’existant • Choisir un modèle de déploiement 66

Conception architecturale 67

Concevoir les classes • Finalisation des classes • Choix des attributs, des opérations, des associations • Choix de mise en œuvre des attributs, des opérations, des associations • Choix des algorithmes 68

69

70

71

72

Artefacts de conception • Modèle de déploiement 73

Modèle de conception * * Package de conception Modèle de conception * * * Classes d’analyse (méthodes, visibilité des attributs, stéréotypes) Interface (opérations fournies) Réalisation de cas d’utilisation (diagrammes de classes, diagrammes de séquence) 74

Exemple GAB (Conception) 75

Modèle de déploiement * Modèle de déploiement Nœud 76

Exemple GAB (Déploiement) 77

L’Implémentation 78

Implémentation • Mise en œuvre logicielle • S’appuie sur les modèles précédents pour produire des composants logiciels • Mise en place de l’architecture logicielle sur une architecture matérielle conforme au modèle de déploiement • Produit un « modèle d’implantation » 79

Artefacts d’implémentation * Modèle d’implémentation * Sous-système d’implémentation * Interface (opérations fournies) * Composant 80

Exemple GAB (Implémentation) 81

Les Tests 82

Tests • Tester le logiciel produit: • Tests techniques : • Test des composants • Test du système • Validation des besoins • Par rapport aux cas d’utilisation • Produit un « modèle de test » 83

Artefacts de test Cas de test * Modèle des tests * Procédure de test Composant de test 84

Exemple GAB (Tests) 85

Retour sur les phases Croisement phases et activités 86

Organisation matricielle Activités de développement Phases Création Élaboration Iter. #1 Iter. #2 #3 Construction Transition Besoins Analyse Conception Implémentation Tests Déploiement … … … Itérations Iter. #n-1 Iter. #n 87

Les activités et les travailleurs 88

Phase de « Création » Création Élaboration Construction Transition temps Vision - Besoins • Objectifs • Définir les limites du système • Identifier les usages • cas d’utilisation • interfaces utilisateurs • Esquisser une architecture initiale • Identifier les risques principaux • Résultats • Vision : glossaire, liste des acteurs, liste des cas d’utilisation classée, 10 % des cas d’utilisation représentatifs documentés, contraintes non fonctionnelles, liste des risques principaux, premier diagramme de classes, interfaces utilisateurs 89 • Feu vert du commanditaire

Retour sur la phase de création • Besoins • Recensement des besoin et des exigences • Compréhension du contexte (modèle métier ou du domaine) • Formuler les besoins fonctionnels • • Identifier les acteurs et les cas d’utilisation Définir un ordre de priorité Décrire en détail quelques cas d’utilisation représentatifs (~10%) Esquisser l’interface utilisateur • Formuler les besoins non fonctionnels • Identifier les risques • Analyse architecturale : sélectionner les cas d’utilisation représentatifs candidats à l’architecture de référence • Analyse des cas : si besoin, analyser quelques cas (~la moitié des 10% décrits en détail) pour caractériser des besoins de partage, ne pas viser l’exhaustivité 90

Retour sur la phase de création • Conception architecturale : esquisser une architecture candidate sous forme de blocs qui peuvent être organisés en couches, montrer les interfaces • Implémentation • Prototype(s) éventuel(s) de validation des choix (interface, architecture, cas d’utilisation …) • Tests • En fonction des choix précédents • Planification de la phase d’élaboration (des (premières) itérations) 91

Progression du développement des cas d’utilisation dans les phases. 92

Phase d’ « Elaboration» Création Élaboration Construction Transition temps Vision Besoins Architecture • Objectifs • • Définir l’architecture de référence Préciser les cas d’utilisation (80 % des besoins fonctionnels) Planifier le projet Préciser les risques du projet (besoins, technologiques, compétences, politiques) • Résultats • Architecture de référence • Concerne les cas d’utilisation centraux avec l’ensemble de leurs modèles d’analyse • Style architectural • Paquetages, Modèle de composants, Modèle de déploiement • Un planning du projet intégrant le calendrier, les coûts, le personnel • Une évaluation des risques et des éléments de protection 93

Retour sur la phase d’élaboration • Besoins • Compréhension du contexte (modèle métier ou du domaine) : 100% • Formuler les besoins fonctionnels • Décrire en détail 40 à 80 % des cas d’utilisation, dont les cas d’utilisation pilote pour l’architecture de référence • Structurer les cas d’utilisation : simplification, spécialisation/généralisation … (cas semblables, intersection de fonctionnalités …) • Réorganiser les priorités en fonction des nouveaux cas étudiés et de l’architecture de référence choisie • Formuler les besoins non fonctionnels • Préciser les risques 94

Retour sur la phase d’élaboration • Analyse architecturale : • sélectionner les cas d’utilisation représentatifs candidats à l’architecture de référence • décomposer système en sous-systèmes de haut-niveau • Analyse des cas : analyser les cas nécessaires à la compréhension de l’architecture de référence (en général 20 à 40 %) • Analyse des classes : affinage des propriétés • Analyse des paquetages : validation par rapport à l’architecture de référence 95

Retour sur la phase d’élaboration • Conception architecturale : • Décomposition du système en sous-systèmes (un paquetage un sous-système autant que possible, mais il y a d’autres contraintes (ré-utilisation …) • Identification d’un style d’architecture (patron d’architecture) • Pré-selection des mécanismes de conception : langages, bases de données, midleware … • Conception des sous-systèmes, des classes, des interfaces • Approfondir les classes d’analyse utiles à l’architecture de référence en classes de conception • Conception des cas d’utilisation utiles à l’architecture de référence • Implémentation • Identification des composants nécessaires à l’implémentation des soussystèmes de l’architecture de référence • Affectation des composants identifiés aux nœuds du réseau informatique • Planification de la construction (des (premières) itérations) 96

Phase de « Construction » Création Élaboration Construction Transition temps Vision Besoins Architecture Produit • Objectifs • Finalisation de la description et de la réalisation des cas d’utilisation • Finalisation de l’analyse, de la conception, de l’implantation et des tests informatiques • Validation par rapport aux risques • Validation par rapport à l’architecture de référence • Résultats • Produit version Béta, logiciel testé en interne, manuels 97

Retour sur la phase de construction • Besoins • Terminer l’identification des acteurs et des cas d’utilisation (en général l’essentiel est déjà fait) • Prototyper l’interface utilisateur si nécessaire (interface complexe et pas déjà fait) • Réorganiser, structurer les cas d’utilisation si besoin. • Analyse • Actualiser l’architecture si besoin • Analyser les cas d’utilisation, les classes, les paquetages qui n’ont pas été traités dans la phase d’élaboration 98

Retour sur la phase de construction • Conception architecturale : • l’architecture de référence résultat de la phase d’élaboration couvre l’essentiel des cas; mais un sous-système équivalent à un existant peut être ajouté. • L’architecture peut être améliorée en fonction des retours d’implémentation • Concevoir les cas d’utilisation, les classes, les paquetages qui n’ont pas été traités dans la phase d’élaboration • Implémentation des classes / des composants / des sous-systèmes dans le modèle d’implémentation (réseau informatique …) • Faire les test unitaires • Intégrer le système (du bas vers le haut …) • Test • Planifier, concevoir les tests • Effectuer les test d’intégration • Valider les tests 99

« Elaboration vers Construction » Ce peut être un paquetage 100

Synthèse 101

Synthèse On a étudié dans ce cours : • Les notations UML (Unified Modelling Language) • Les activités de développement de logiciel : • Spécification des besoins, Analyse, Conception, Implémentation, Tests • Les phases de développement d’un logiciel • Création : définition des besoins, définition d’une vision globale commune • Elaboration : définition d’une architecture de référence (couvre les différentes dimension conceptuelles et techniques du logiciel à développer) • Construction : développement d’une version Béta du logiciel • Transition • Le processus de développement RUP (Rational Unified Process) : un processus matriciel itératif de développement de logiciel • On a rencontré différents rôles du développement de logiciel : architecte, spécificateur de besoin, ingénieur de composant … 102

Recueil des Besoins : Artefacts (GAB) 103

Description textuelle des cas d’utilisation Identifier des scénarii possibles pour un cas d’utilisation. Scénario nominal Scénario alternatif Scénario exceptionnel Il est généralement impossible d'être exhaustif. Aucune normalisation UML de cette description textuelle. 104 UML- Use cases

Scénario nominal 1. Le porteur de CB introduit sa carte dans le lecteur du GAB. 2. Le GAB vérifie que la carte introduite est bien une CB. 3. Le GAB demande au porteur de saisir son code. 4. Le porteur de CB saisit son code. 5. Le GAB compare le code saisi avec celui inscrit sur la puce. 6. Le GAB demande une autorisation au SA CB. 7. Le SA CB donne son accord et indique le solde hebdomadaire. 8…. . 105 UML- Use cases

Contenu Sommaire d’identification : titre, résumé, dates de création et de mises à jour, version, acteurs concernés, responsables, … Description des scénarios nominals, alternatifs, exceptionnels Besoins en IHM : matériels, copies d’écran, … Contraintes non fonctionnelles : temps de réponse, confidentialité, disponibilité, . . . 106 UML- Use cases

Exemple : GAB : retirer de l’argent avec une CB Sommaire d’identification : titre : retirer de l’argent avec une CB résumé : ce cas permet à un porteur de CB non client de la banque, de retirer de l ’argent, si son crédit hebdomadaire le permet. date de création : 01/09/01 date de mise à jour : 11/09/01 version 1. 2 acteurs concernés : porteur de CB, SA CB responsables : Alfred 107 UML- Use cases

Scénario nominal 1. Le porteur de CB introduit sa carte dans le lecteur du GAB. 2. Le GAB vérifie que la carte introduite est bien une CB. 3. Le GAB demande au porteur de saisir son code. 4. Le porteur de CB saisit son code. 5. Le GAB compare le code saisi avec celui inscrit sur la puce. 6. Le GAB demande une autorisation au SA CB. 7. Le SA CB donne son accord et indique le solde hebdomadaire. 8…. . 108 UML- Use cases

Autres scénarios • Scénario alternatif : code momentanément erroné Cet enchaînement démarre au point 5 du scénario nominal. 6. Le GAB indique au client que le code est erroné, pour la première ou deuxième fois. 7. Le GAB enregistre l’échec sur la carte. Le scénario nominal reprend au point 3. • Scénario exceptionnel : carte non valide Cet enchaînement démarre au point 2 du scénario nominal. 3. Le GAB indique au porteur que la carte n ’est pas valide et la confisque. Le cas d ’utilisation est terminé. 109 UML- Use cases

L'interface Besoins en IHM lecteur de carte bancaire, clavier numérique avec touches validation, correction et annulation, écran, touches autour de l’écran pour la sélection d’un montant, distributeur de billets, distributeur de ticket. 110 UML- Use cases

Autres contraintes Contraintes non fonctionnelles Temps de réponse : l’interface du GAB doit réagir en moins de 2 secondes ; une transaction nominale de retrait ne doit pas durer plus de 2 minutes. Disponibilité : le GAB est accessible 7 jours sur 7, 24 heures sur 24 ; il ne doit pas être immobilisé plus d’une heure par semaine par l’opérateur de maintenance. Intégrité : l’interface du GAB est très robuste. Confidentialité : l’authentification du code doit être fiable (marge d’erreur tolérée de 1 pour 10 millions). 111 UML- Use cases

Formalisation de la description textuelle Avec un diagramme d’interaction Diagramme très simplifié, en tous cas initialement Souvent le système comme seul objet Avec un diagramme d'activités 112 UML- Use cases

: GAB : Porteur. CB : SA CB introduction carte demander code vérification carte code(valeur) demande autorisation(solde) demander montant retrait(valeur) proposer ticket Ok éjecter carte récupérer carte éjecter carte + billets récupérer carte + billets signaler retrait (valeur) 113 UML- Use cases

Diagramme d’activité 114 UML- Use cases

Retour (vers analyse) 115

Analyse : Artefacts (GAB) 116

Analyse : Artefacts (GAB) : Retrait : Distributeur 117

Analyse : Artefacts (GAB) 118

Analyse : Artefacts (GAB) 119

Retour (vers conception) 120

Conception : Artefacts (GAB) 121

Conception : Artefacts (GAB) Classes actives = processus 122

Conception : Artefacts (GAB) 123

Conception : Artefacts (GAB) X 124

Conception : Artefacts (GAB) 125

Conception: Artefacts (GAB) 126

Retour (Déploiement) 127

Modèle de déploiement : Artefacts (GAB) 128

Modèle de déploiement : Artefacts (GAB) 129

Modèle de déploiement : Artefacts (GAB) 130

Retour (vers implémentation) 131

Implémentation : Artefacts (GAB) 132

Retour (vers tests) 133

Tests générés à partir des cas d’utilisation 134

Retour (vers la synthèse) 135

FIN 136