UML - Conception fonctionnelle

UML - Conception fonctionnelle
Formation Industrialisation AS France Commandements de la formation Le processus de formation utilisé dans cette présentation doit reproduire autant que possible le processus de conception (ex : 1/ définir les exigences = apprendre UML, apprendre une méthodologie… 2/ raffiner = utilisation intensive de la modélisation et de la méthode de conception). Contexte : ce support doit être utilisable en clientèle. Limiter les dépendances « Industrialisation Sud » autant que possible. Les zones de commentaires sont destinées aux formateurs. Merci de les enrichir avec les retours d’expérience des formations. Publier aux stagiaires uniquement une version PDF pour les inciter à prendre des notes et pour éviter le piratage également. ATTENTION: vérifier que les illustrations importées sont libres de droit. Wikipedia est une excellente source. FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.

Introduction Présentation du formateur Objectifs de la formation
A la fin de la session je dois être capable de : Traduire un cahier des charges en concepts UML Utiliser : les diagrammes de cas d’utilisation les diagrammes de séquence les diagrammes d’activité les diagrammes d’état-transition les diagrammes de classe Utiliser l’outil Magic Draw FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 2

Présentation des participants
Vos attentes ? FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 3

? ü ü Quiz - UML c’est :  Un langage de programmation
 Une aide pour modéliser  Un nom d’avion motorisé ultraléger ü  Un guide pour faire des petits dessins Réponses : UML c’est? Un langage de programmation : Non. Pour le moment il n’existe pas de compilateur UML. Une aide pour modéliser : Oui. Les diagrammes UML permettent de formaliser des concepts métiers ou techniques qui servent de base au développement. Un avion ultraléger : Non. Il ne faut pas confondre avec Ulra Léger Motorisé Un guide pour faire des dessins : Oui. UML décrit la façon de représenter schématiquement des concepts informatiques (une classe, par exemple, est un ensemble de 1, 3 ou 4 rectangles avec des informations précises à l’intérieur) © 2007 Capgemini - All rights reserved

Quiz - Utiliser UML c’est garantir :
? ü  Une meilleure structuration de l’information ü  Moins de problèmes de barrière de langue  Que le logiciel correspond aux besoins du client  Des intégrations régulières Réponses : Utiliser UML c’est garantir Un meilleure structuration de l’information : Oui. UML permet de représenter un dispositif informatique selon plusieurs vues (dynamique/statique) et avec plusieurs niveaux de précision. Moins de problèmes de barrière de langue : Oui. En utilisant une notation graphique, on diminue le recours au texte et on facilite donc la compréhension par tous. Que le logiciel correspond aux besoins du client : Non. UML facilite la discussion entre les équipes et permet donc de mieux comprendre les besoins du client, mais UML ne contient pas de méthode de production logicielle. Des intégration régulières : Non. UML n’a aucun rapport avec la fréquence du processus d’intégration. Par contre il peut aider à construire le processus d’intégration en déterminant l’ordre d’intégration des modules. © 2007 Capgemini - All rights reserved

Quiz - RUP c’est : ?  Une inscription dans les cimetières anglophones qui signifie « Rest Under Peace » ü  Une méthode de conception  Un logiciel de modélisation ü  Une implémentation de UP Réponses : RUP c’est Un inscription… : Non. C’est R.I.P. (Rest In Peace ou Requiescat In Pace en latin : Repose en paix) qui est inscrit sur les tombes. Une méthode de conception : Oui. Et cela va même au delà puisque cette méthode prend en compte des aspects de gestion de projet (découpage en phase, cycle de vie itératif…). Un logiciel de modélisation : Non. Même si la méthode RUP est supportée par de nombreux logiciel (dont ceux de Rational), RUP n’est pas un logiciel. Une implémentation de UP : Oui. C’est l’interprétation de Rational de la méthode ‘Unified Process’ (ou Process Unifié) © 2007 Capgemini - All rights reserved

Déroulement de la formation
Première demi-journée Introduction Vue d’ensemble Le génie logiciel Recueil des besoins Analyse Deuxième demi-journée Compléments Synthèse Cas pratique Troisième demi-journée Cas pratique (Suite) Clôture Planning à adapter en fonctions des ½ journées prévues © 2007 Capgemini - All rights reserved

Vue d’ensemble Le génie logiciel Recueil des besoins Analyse
Sommaire Vue d’ensemble Le génie logiciel Recueil des besoins Analyse Compléments Synthèse © 2007 Capgemini - All rights reserved

Avantages de la modélisation avec UML
Le modèle est pérenne, et les notations aussi. La vision du système est partagée grâce au fait : Que tout le monde voit la même spécification Que tout le monde contribue à faire évoluer le modèle en introduisant sa propre vision UML est une notation de plus en plus répandue (connue, enseignée, supportée par les outils…). UML permet de répartir simplement le travail de spécification sur de nombreuses personnes. Il n’est pas nécessaire d’avoir des compétences métier pour manipuler des diagrammes UML : fonctionnels et développeurs ont un langage commun. Même les plus gros projets peuvent être spécifiés et maintenus en UML. Formaliser en UML permet De préciser sa pensée, De pousser les intervenants à communiquer et à partager leurs connaissances, D’éviter d’instaurer des gourous. Vieux = il peux partir à n’importe quel moment (retraite, envie de voir autre chose…) Unique = pas de backup. Car si l’on met deux vieux sages ensemble, on part à la catastrophe : pendant un temps ils luttent pour déterminer qui sera le ‘VRAI’ vieux sage puis il s’instaure une relation de hiérarchie dont le vaincu va souhaiter sortir. Il arrive parfois que les sages se répartissent la connaissance (se répartissent les responsabilités) mais dans ce cas, ils se répartissent les responsabilités et on se retrouve à une situation avec un vieux sage sur chaque domaine et leur respect l’un pour l’autre les pousse à ne plus s’intéresser au domaine de l’autre => pas de backup. © 2007 Capgemini - All rights reserved

Les différents cycles de vie
Des cycles linéaires et des cycles itératifs Des ‘cycles longs’ et des ‘cycles courts’ Ne pas hésiter à faire évoluer le cycle et à les combiner Cycles longs Cascade V Y Itératif Rapid prototyping (Robert Balzer) Attention : il faut passer vite sur les cycles de vie (20 minutes maximum) Scrum XP RAD Cycles courts Linéaires Itératifs © 2007 Capgemini - All rights reserved

Cycle de vie linéaire Capgemini : le cycle en V de l'AFCIQ
Exg. Produit Spec.log. DTV Validation Spec. Logiciel DTU DDI Analyse log. Intégration Conception Test unitaires Composant Conc. E/S Code Chronologie AFCIQ : Association Française pour le Contrôle Industriel et la Qualité. Créé en 1957 et devenu en 1991 le MFQ : Mouvement Français pour la Qualité. Activité DTV : Dossier de tests de validation Doc DTU : Dossier de tests de unitaires DDI : Dossier de définition d’interface © 2007 Capgemini - All rights reserved

Cycle de vie en V : B’s Modèle éprouvé car calqué sur la production industrielle classique : permet l'organisation du travail et des équipes => prédiction (Cocomo) et contrôle des coûts facilités favorise la décomposition hiérarchique fonctionnelle propose des étapes clés (documentation, revues) => bon suivi du projet permet de garantir une certaine qualité (plan assurance qualité) existence de standards (MIL-STD-498, GAM-T17(V2), Do 178 B, STAN-CS 055, ESA, ...) adapté à de grands projets Beaucoup d'outils support. COCOMO : (COnstructive COst Model). C'est une méthode pour estimer le coût d'un projet logiciel dans le but d'éviter les erreurs de budget et les retards de livraison, qui sont malheureusement habituels dans l'industrie de développement logiciel. Indexé sur 63 projets de 2000 à lignes de code. Segmenté en : Modèle de base = complexité en lignes de code et type de projet Modèle intermédiaire = estimation des compétences de l’équipe, du matériel, difficulté du produit et attributs du projet Modèle expert = modèle intermédiaire plus estimation de l’impact de la conduite des coûts A noter COCOMO II pour la réutilisation de composants. MIL-STD-498 : militaire américaine, GAM-T17 : marine DGA Do178B : logiciels aéronautique américains (et largement adopté -> airbus) © 2007 Capgemini - All rights reserved

Cycle de vie en V : C’s Hypothèses peu fondées : séquentialité des phases non conforme à la réalité Incapacité à prendre en compte des évolutions du cahier des charges durant la construction du système Absence de vérification et validation à la fin de chaque étape Absence d'une continuité des outils Inadapté aux systèmes non fonctionnels La production de documents ne limite pas beaucoup l’effet tunnel Peu ou pas de possibilité de maquettage et/ou de prototypage. Définitions (Boehm 76): - Validation: « Am I building the right system? » - Verification: « Am I building the system right? » © 2007 Capgemini - All rights reserved

Vue opérationnelle Pilotage Ajustement Méthodes Collecte d’exigences
Architecture conceptuelle Méthodes Ajustement Collecte d’exigences Architecture logique Assurer la compréhension des utilisateurs Analyse Architecture physique Assurer la pérennité des solutions Conception applicative générale Retranscrire fidèlement le besoin Conception technique détaillée Analyser les éléments structurants du dimensionnement de l’architecture Pilotage Codage et tests unitaires Maîtriser la profondeur des documents Intégration Assurer la convergence des branches Recette Nous ne nous intéressons, dans ce cours, qu’au carré en haut à gauche (celui qui tourne au cours de la présentation) Déploiement Architecture Exploitation Maintenance Fonctionnel Developpement © 2007 Capgemini - All rights reserved

Cycle de vie en Y Sépare les analyses fonctionnelles et techniques B’s
Mis en œuvre chez Capgemini Détecte les conflits technique / fonctionnels au plus tôt Peut s’intégrer dans les autres cycles de vie Particulièrement adapté aux nouvelles technologies et à l’utilisation de COTS Utilise toutes les compétences métiers dès le démarrage du projet C’s Impose de définir la totalité des besoins dès le départ L’organisation du projet doit être adaptée Rarement appliqué en l’état © 2007 Capgemini - All rights reserved

Les méthodes agiles (RAD, XP, Scrum…)
Basé sur le principe qu’il vaut mieux adapter que prédire Personnes et interactions Procédures et outils Applications fonctionnelles Documentation pléthorique Collaboration avec le client Négociation de contrat Acceptation du changement Planification Faire vite et simple plutôt que beau et hi-tech Implication permanente du client Communication directe maximale (client, équipes…) Motivation des individus Respect des règles de qualité (code clair et robuste) Ne pas confondre agilité et bricolage : ces méthodes nécessitent beaucoup de compétence, de rigueur et de motivation sans quoi elles mènent droit dans le mur! A privilégier A éviter RAD : Rapid Application Developpment XP : développé en 1996 chez Chrysler. Les développeurs travaillent par binôme sur une machine afin de corriger mutuellement leurs erreurs. Le code appartient à toute l’équipe, n’importe qui pouvant le modifier. Il y a aussi des standards de développement. L’objectif est de garantir une homogénéité du code. Il est recommandé de ne pas dépasser les horaires de travail pour limiter la fatigue donc les erreurs. Un responsable projet du côté client doit être présent sur le site de développement. Une intégration constante est réalisée (petits modules). Orienté autour d’étapes : modélisation du système d’information (business modeling) où l’on définit l’ordre de priorité de création des modules. modélisation des données modélisation du processus génération de l’application test et retours assemblage de petits modules Particulièrement adapté aux environnements changeants ou à des besoins mal connus. Attention : ce n’est pas adapté à de grandes équipes de développement -> petits projets. © 2007 Capgemini - All rights reserved

Les méthodes agiles (RAD, XP, Scrum…)
B’s : Plus d’effet tunnel (présence du client et livraisons fréquentes) Forte capacité à s’adapter aux changements de spécification C’s : Faiblesse de la documentation (difficulté de transfert du projet à une autre équipe) Fortes capacités relationnelles exigées des développeurs (entre eux et avec le client) Souvent inadapté aux gros projets Formation et rigueur imposée aux acteurs Planification et estimations de charge difficiles

Le cycle itératif

Le cycle itératif Réduction du risque par morcellement
Chaque itération : Est fondée sur le résultat stable d’une itération antérieure qu’elle améliore si nécessaire Produit un ‘prototype’ validé B’s : Pas d’effet tunnel Les difficultés d’une itération sont levées dans la suivante Production de résultats visibles très tôt Meilleure traçabilité des exigences Meilleure répartition des tâches sur les ressources C’s : Difficultés à aboutir sur les exigences client Impose des disponibilités de la part du client Tendance à laisser le client valider (réduction de l’effort de test)

Cycle de vie itératif de Capgemini : Unified Process
La vie d’un projet UP se décompose en une série de cycles. A un cycle correspond une livraison. Une livraison contient le résultat des activités menées pendant le cycle Ces activités sont de différentes sortes : Modèles métier, Requirements, …. Comment segmenter les itérations Débuter petit. Une itération trop grosse diminue la visibilité du CdP et les possibilités d’adaptation (l’adaptation en cours d’itération n’est pas souhaitable) Partir des exigences stables. Le client doit sélectionner les exigences les plus abouties. Ne pas commencer par l’IHM principale mais par les systèmes tiers (communications avec les SGBD / autres systèmes informatiques). l’IHM principale impose en général de produire de nombreuses briques élémentaires et constitue un des les plus lourds (sans être forcément la plus stable). Un cycle RUP est-il constitué de N cycles en V? Voici la vue officielle de UP. Pour les clients renvoyer à la littérature. Pour les capgéminiens citer l’URL La caractéristique principale de RUP est l’aspect itératif: le processus global de développement est décomposé en 4 grandes étapes, chacune d’elle pouvant comporter une ou plusieurs itérations. Par rapport à un cycle en V classique, il sera possible par exemple de coder lorsque les spécifications ne sont pas finies, ou encore de valider alors que le codage est en cours sur d’autres domaines fonctionnels. Les disciplines sont des groupes de tâches fortement liées. Ces tâches ainsi que les acteurs qui y contribuent sont détaillées par le processus. Le diagramme présente la charge de travail relative des tâches de chacune des disciplines selon les phases. Les objectifs phases: Inception: vision (métier, technique, coût, ROI, management) du produit Elaboration: planification des ressources et des tâches nécessaires à la construction Construction: construction et gestion des évolutions jusqu’à la livraison Transition: transmission aux utilisateurs Les spécificités. Itératif vu. Incrémental signifie que le produit est construit par intégrations successives de composants. Focalisé sur les exigences signifie que ces dernières justifient les choix et sont gérées (risques, évolutions). Architecture: les exigences techniques sont gérées, l’architecture est définie dès la phase d’élaboration. Enfin UML est le moyen de communication écrite privilégié. Un RUP est-il constitué de N cycles en V? Non. Parce que une itération est trop courte pour matérialiser un cycle V complet, le produit est incomplet jusqu’à la fin de la construction, le cycle en V ne s’intéresse pas du tout à la phase de transition, il n’y a pas de gestion de projet en cycle en V, les activités du V sont parallélisées. Un exemple fréquent: prototype en phase d’élaboration, une livraison intermédiaire en phase de construction. © 2007 Capgemini - All rights reserved

Cycle de vie itératif de Capgemini : Unified Process-suite
Spécificités de UP Itératif et incrémental Un projet est divisé en itérations : une itération est constituée des mêmes étapes Une itération prend en compte un ou plusieurs cas d’utilisation Pour concevoir les itérations le critère de choix c’est d’abord l’élimination des risques On essaie de faire en sorte que les itérations finissent par être des additifs Piloté par les cas d’utilisation Un cas d’utilisation est une fonctionnalité du système offrant un résultat tangible pour l’utilisateur L’utilisateur peut être un être humain, mais un système externe Les modèles décrivent la réalisation d’un cas d’utilisation Centré sur l’architecture L’architecture doit permettre de réaliser les cas d’utilisation L’architecture et les cas d’utilisation doivent évoluer de concert (on retrouve les deux branches du Y du cycle en Y) L’architecte doit avoir une compréhension globale des cas d’utilisation S’appuie sur UML Voici la vue officielle de UP. Pour les clients renvoyer à la littérature. Pour les capgéminiens citer l’URL La caractéristique principale de RUP est l’aspect itératif: le processus global de développement est décomposé en 4 grandes étapes, chacune d’elle pouvant comporter une ou plusieurs itérations. Par rapport à un cycle en V classique, il sera possible par exemple de coder lorsque les spécifications ne sont pas finies, ou encore de valider alors que le codage est en cours sur d’autres domaines fonctionnels. Les disciplines sont des groupes de tâches fortement liées. Ces tâches ainsi que les acteurs qui y contribuent sont détaillées par le processus. Le diagramme présente la charge de travail relative des tâches de chacune des disciplines selon les phases. Les objectifs phases: Inception: vision (métier, technique, coût, ROI, management) du produit Elaboration: planification des ressources et des tâches nécessaires à la construction Construction: construction et gestion des évolutions jusqu’à la livraison Transition: transmission aux utilisateurs Les spécificités. Itératif vu. Incrémental signifie que le produit est construit par intégrations successives de composants. Focalisé sur les exigences signifie que ces dernières justifient les choix et sont gérées (risques, évolutions). Architecture: les exigences techniques sont gérées, l’architecture est définie dès la phase d’élaboration. Enfin UML est le moyen de communication écrite privilégié. Un RUP est-il constitué de N cycles en V? Non. Parce que une itération est trop courte pour matérialiser un cycle V complet, le produit est incomplet jusqu’à la fin de la construction, le cycle en V ne s’intéresse pas du tout à la phase de transition, il n’y a pas de gestion de projet en cycle en V, les activités du V sont parallélisées. Un exemple fréquent: prototype en phase d’élaboration, une livraison intermédiaire en phase de construction. RUP est une Instanciation d’UP par Rational / IBM © 2007 Capgemini - All rights reserved

UP : Focalisation sur l’architecture
Penser en terme d’éléments : couches, sous-systèmes, paquetages, relations, composants… Permet d’acquérir et de conserver un contrôle intellectuel sur un projet, de gérer sa complexité et de maintenir l’intégrité du système Principes de conception : diviser pour mieux régner, couplage, cohésion, réutilisabilité… Procure une base efficace pour réutiliser à grande échelle Procure des bases de gestion de projet – allocation des tâches aux équipes… Facilite des développements basés sur les composants  Les composants remplissent une fonction précise dans une architecture bien définie  Un composant procure et correspond à une implémentation physique d’un ensemble d’interfaces

Processus et méthodes Synthèse Processus Méthode Processus itératifs
Vue simple et concise des objectifs et des résultats Formalisme permet de mesurer la qualité et l’avancement Rigidité externe n’interdit pas une souplesse d’organisation Méthode Vue complexe de la réalité Guide, référentiel d’outils Processus itératifs Alignement besoins pilotage et opérationnels Risques mieux maîtrisés Exigences instables Conception évolutive Planification à temps Processus: La rigidité n’est qu’externe. En interne chaque activité peut être parallélisée avec d’autres. Mais il y a des étapes clés incontournables. Méthode: vue plus opérationnelle. Offre des outils opérationnels. Mais n’offre pas d’outils de management. Les processus itératifs: le prix est une complexité accrue. Du coup le pilotage est moins limpide. Mais on s’y retrouve parce que la gestion des risques est mieux assurée, et le moyen d’y remédier est prévu par le processus. RUP est utilisé comme exemple pour clarifier et parce que c’est un cas fréquent. © 2007 Capgemini - All rights reserved

UML et le processus A la fin de l’iteration E1, on livre des documents/constructions concernant : Le business modeling requirements analysis and design Implementation Tests Le déploiement La gestion de configuration La gestion de projet Environnment Les activités Les phases Temps

Architecture RUP : Le modèle 4+1 vues
Vue logique View Exigences fonctionnelles Traite la conception, paquetages, sous- systèmes, classes, couches, … Vue d’implémentation Traite surtout l’organisation et la programmation des modules statiques et des tests unitaires Vue logique Vue d’implémentation Functional requirements Analystes/ Concepteurs Utilisateur Fonctions Développeurs Management logiciel Structure Vue des cas d’utilisation Vue processus Vue de déploiement Performance ‘Scalability’, Concurrence, Bande passante, Parallélisme… Intégrateurs système Ingénieurs système Topology du système Delivery, installation Communication Une Vue est une description complète (une abstraction) d’un système dans une perspective ou un point de vue particulier – présentant des considérations et en omettant d’autres qui ne sont pas pertinentes pour cette perspective. Différentes ‘vues’ d’intervenants différents => des objectifs différents. Un Modèle est une représentation complète. Les modèles sont constitués de vues.

Synthèse des cycles de vie
Il faut adapter les cycles de vie au projet Un projet peut mixer ou paralléliser plusieurs cycles de vie : Sur le projet ODS, un prototype a été réalisé dans l’esprit ‘méthodes agiles’ tandis que le reste des livraisons s’appuient sur un panachage ‘cycle en V’/’itératif’ Attention par contre à ne pas changer de cycle en cours de réalisation (entraine une perte de visibilité du chef de projet, une confusion du client…) Analyse/conception RUP ne distingue pas clairement analyse et conception En anglais “design” a une connotation plus technique. Sa traduction, "conception", doit donc désigner uniquement la conception technique. Une convention commune mais pas universelle Analyse se limite à la conception des éléments essentiels Conception effectue des choix d’implémentation Pas universel On peut faire de la conception fonctionnelle (exemple domain-driven design) Retenons : Cahier des charges ou de besoins = spécification externe Analyse = modèle des objets du domaine :dossier de cadrage et spécifications internes Conception = terme réservé à l’implémentation Exemples d’exigence contractuelles : nous voulons disposer de formations pour les administrateurs de l’application Rendre l’application paramétrable pour qu’elle puisse évoluer rapidement lors des modifications d’exigences. © 2007 Capgemini - All rights reserved

Définir les rôles Chef de projet (Métier Project manager)
Organiser la spécification sur le projet Valider avec le client l'organisation de la spécification sur le projet Assurer le suivi de la spécification et des engagements en CO projet Vérifier le référentiel de spécification Responsable fonctionnel (Métier IT & Business Analyst) Concevoir l'architecture applicative, ses interfaces et définir les principes qui guident son organisation. Participer à l’élaboration de la stratégie de test Responsable de la qualité et de la faisabilité de l'application Coordonner les efforts des concepteurs Concepteur fonctionnel Raffiner progressivement les exigences afin d'établir une vision précise de la solution et contribuer à la rédaction des documents de test S'assure de la cohérence des spécifications avec la solution technique Responsables des exigences Vérifier la traçabilité entre les référentiel d'exigences, de spécification et de conception et traiter les écarts Responsable Gestion de la configuration Gérer en configuration le référentiel de spécification (versions du référentiel et fiches RQE) Ingénieur Qualité (Métier efficiency manager) Assister le CP à organiser les phases de spécification (PQP) Contrôler la tenue des Revues de Spécification (fiches RQE) des exigences Vérifier la couverture des exigences qualité et traiter les écarts Contrôler le processus de gestion des exigences et s'assurer que le projet et les livrables y répondent

Formation des équipes de concepteurs
Besoins au niveau fonctionnel Vision globale de l’application pour analyser l’impact des évolutions et échanger avec le client Besoin de rentabiliser l’investissement important dans le domaine fonctionnel (i.e. nombre de fonctionnels limité) Besoins au niveau technique Maîtrise de chaque composant de l’environnement technique (ex : composants IHM, administration de données, communication réseau…) Respect du découpage architectural Exg1 Exg2 Exg3 Exg4 Fct1 Fct2 Fct3 IHM1 IHM2 TM3 IHM2 TM3 TM1 TM2 TM2 TD1 TD2

Exercice Vous êtes employé chez un Tour Operator pour organiser les voyages des clients. Mr Hans TREPRISE vous appelle. Il veut aller de Paris à Toulouse. Solution : ? Solution : 1/ Raffiner le cahier des charges : combien sont-ils à partir, combien de temps acceptent-ils d’y passer, combien ont-ils de bagages et quel est leur budget. Pour l’exemple ils sont trois, n’acceptent pas d’y passer plus de 2 jours, ont trois valises et n’ont que 1000 euros. 2/ Prise en compte de l’existant : ont-ils déjà un véhicule, ont-ils un permis? Pour l’exemple ils n’ont pas de véhicule mais ont un permis B. 3/ Définir l’architecture : qu’est ce que l’on utilise comme socle (ici, quel moyen de transport utiliser). Pour l’exemple il y a deux moyens de transport retenus : la voiture et le train. On écarte le vélo, le cheval (trop longs) le bus et l’avion (trop chers). On choisit la voiture. 4/ Raffiner avec la conception fonctionnelle : Comment aller de Paris à Toulouse par la route? Réponse : on définit une carte routière sur laquelle on va raffiner : de Paris à Toulouse on passe par l’autoroute du centre = Limoges. Pour prendre l’autoroute de Limoges, il faut d’abord prendre l’autoroute de Paris. Puis à Toulouse il faudra prendre la rocade, puis à Paris, pour monter sur l’autoroute il faut… Le résultat de la conception fonctionnelle est un itinéraire précis avec tous les points d’intérêt. A chaque fois ce découpage s’accompagne de plusieurs vues : la vue dynamique (tourner à droite, tourner à gauche…) et la vue statique (nombre de kilomètres parcourus, points d’intérêt)… Ces notions sont indépendantes de la plateforme : que l’on y aille en bus, en stop ou à moto on passera par les mêmes étapes. On est donc bien dans le fonctionnel 5/ On raffine la conception détaillée : Comment conduire de Paris à Toulouse? Réponse : il faut intégrer la vitesse limite du véhicule (ou de la route), son autonomie pour prévoir des arrêts aux stations services, que les conducteurs se relaient et/ou se reposent (étapes?)… le résultat de cette conception est un itinéraire précis adapté à l’architecture : combien de tours de volant faire pour aller à droite ou à gauche, les points à éviter, les stations services, éventuellement anticiper sur le besoin de réparateurs. En bref il faut s’adapter à un environnement technique (ex : poids maximum ou taille maximum sous les ponts, circulation de marchandises dangereuses, transports sanitaires ou réfrigérés… les contraintes peuvent être plus ou moins importantes) © 2007 Capgemini - All rights reserved

Gestion des exigences Fonctionnelles Non fonctionnelles
Maîtrise des risques Maîtrise des coûts Matrice de traçabilité Exemple étude de cas © 2007 Capgemini - All rights reserved

Les exigences Les exigences métier, fonctionnelles et techniques
Pourquoi les distingue t on Comment les gère t on Les exigences métier définissent des invariants des besoins essentiels Les exigences fonctionnelles les traduisent d’un point de vue applicatif Permettent d’obtenir une spécification fonctionnelle externe Note: ne pas oublier les besoins d’exploitation et opérationnels induits par la solution Les exigences techniques Permettent d’obtenir une spécification technique externe Mais induisent de nombreux choix d’implémentation © 2007 Capgemini - All rights reserved

Propriétés communes aux exigences
Selon la norme IEEE 830, un référentiel d’exigences doit être : Correct Non ambiguë Complet Cohérent Catégorisé Vérifiable Modifiable Traçable

Correcte Un référentiel d’exigences est correct si et seulement si chaque exigence qu’il décrit doit être satisfait par le logiciel. Comment le savoir: Rencontres Discussions Comparaison avec d’autres documents (Spécification des exigences du système, Logiciel existant…)

Non ambiguë Un référentiel d’exigences est non ambiguë si et seulement si chaque exigence qu’il décrit a une seule interprétation Tâche terriblement difficile. Moyens qui aident : Révision du texte par d’autres personnes Employer une langue de spécification (ex. UML) Employer des outils (ex. MagicDraw)

Complète Un référentiel d’exigences est complet si et seulement si il contient tous ces éléments : Toutes les exigences significatives (sic !) La réponse du logiciel à toutes les classes d’entrées dans toutes les situations possibles. Définition de tous les termes et présence de toutes les légendes et les références aux figures et aux tableaux Pas de « à venir» (S’il y en a, il faut dire comment et quand ils seront enlevés)

Cohérente Un référentiel d’exigences est cohérent si et seulement si aucun sous ensemble d’exigences est en conflit. Conflits possibles: Caractéristiques d’objets physiques en conflits (couleur, format d’impression…) Conflits logiques ou temporels (A avant B et B avant A) Descriptions des mêmes objets du monde réel avec des termes différents

Catégorisée Chaque exigence doit avoir une valeur qui la situe dans une certaine position à l’intérieur d’une catégorie. Minimalement deux catégories Stabilité (grande, moyenne, petite) Nécessité (Essentielle, conditionnelle, optionnelle)

Vérifiable Un référentiel d’exigences est vérifiable si et seulement si chaque exigence qu’il contient est vérifiable. Pas d’adjectifs qualificatifs Pouvoir définir une suite d’action pour vérifier Les énoncés ambigus ne sont généralement pas vérifiables

Modifiable Un référentiel d’exigences est modifiable si et seulement si sa structure et le style d’écriture sont tels que chaque changement aux exigences est facile et laisse le document cohérent sans changer la structure et le style. Doit avoir Table des matières, index, références croisées Pas de redondance Exigences séparées et non mélangées

Traçable Un référentiel d’exigences est traçable si l’origine de chaque exigence est claire et si elle permet d’intégrer les références à l’évolution des exigences et aux artefacts qui la détaille. En arrière : identifier la source En avant : identification unique de l’exigence (pour que les autres documents puisse y faire référence) et quand il est possible identification du/des document(s) qui suivent.

Bonnes pratiques Préparation conjointe : les exigences devraient être rédigée conjointement par les représentants du client et du fournisseur. Connaissances du domaine (client) Limites techniques (fournisseur) => Monter des ateliers de conception Les exigences doivent pouvoir évoluer simplement car il est pratiquement impossible (et dangereux) de « tout » spécifier dès le début. Être le plus complètes possibles à un moment donné Si les exigences ne sont pas complètes il faut le signaler À partir d’un certain moment (dépendant du projet) tout changement doit être officialisé

Facteurs qualité externes du logiciel (B. Meyer)
Validité : aptitude d'un produit logiciel à réaliser exactement les tâches définies par sa spécification Robustesse : aptitude d'un logiciel à fonctionner même dans des conditions anormales Extensibilité : facilité d'adaptation d'un logiciel aux changements de spécification Réutilisabilité : aptitude d'un logiciel à être réutilisé en tout ou partie Compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres Efficacité : aptitude d'un logiciel à bien utiliser les ressources matérielles telles la mémoire, la puissance du CPU, etc. Portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou logiciels Traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges avec un composant d'un logiciel Vérifiabilité : facilité de préparation des procédures de recette et de certification Intégrité : aptitude d'un logiciel à protéger ses différents composants contre des accès ou des modifications non autorisés Facilité d'utilisation : ... Bertrand Meyer est le père du langage Eiffel, un des tous premiers langages objets. Certaines qualités sont plus faciles à interpréter que d’autres. Dans tous les cas, il faut que ces qualités soient mesurables. Donc il faut trouver -un moyen de mesure, -une valeur à obtenir. Demander aux élèves de trouver ces moyens de mesure et des exemples de valeurs. Réponses : Validité mesure par la traçabilité, avec un taux de couverture. Robustesse mesure par un temps de fonctionnement avant erreur (MTBF). Se mesure en heures, jours… On peut le tester sur des durées courtes, puis éventuellement élever la valeur par redondance de systèmes. Extensibilité mesure très difficile car les changements de spécifications peuvent avoir des impacts très importants (ex : diminuer de 1% les exigences de performance peuvent obliger à repenser tout le système) Réutilisabilité mesure tout aussi difficile, mais on peut élever sa valeur en utilisant des technos objets. Compatibilité mesure avec des tests de compatibilité basés sur des définitions d’interface. La valeur est le taux de couverture. Efficacité mesure avec des valeurs de vitesse, de volume… facile à mesurer Portabilité mesure difficile. S’obtiens en utilisant des techno. Java Traçabilité c’est une notion très utilisée en maintenance pour identifier les sources de problèmes. On peut utiliser des gestions d’erreur performantes pour savoir où se situe le problème, des corre dump et bien évidemment de la traçabilité au cours des phases de spécification. Vérifiabilité. C’est ce que nous sommes en train d’essayer de faire. Intégrité. Ou sécurité. On protège avec des composants logiciels et avec des normes qualité. Facilité d’utilisation. Ou ergonomie. On fait tester des maquettes et on demande aux utilisateurs ce qu’ils en pensent. Ou on extrapole des système à partir de systèmes que les utilisateurs connaissent bien (raison pour laquelle il est possible de modifier son bureau Linux pour qu’il ressemble à un Windows). © 2007 Capgemini - All rights reserved

Exercice Déduisez des exigences de ces besoins :
L’IHM du logiciel doit aller vite. Le logiciel devra interagir avec des personnes en situation de handicap. Les résultats semestriels ne sont accessibles qu’aux responsables de centre. Notre voiture doit avoir un régulateur de vitesse robuste. La gestion de mémoire de notre système d’exploitation doit être plus efficace que celle de Windows. Ce nouveau logiciel de paye doit être aussi complet que le précédent mais coûter moins cher. Passer les exigences les unes après les autres, en laissant à chacune une minute de réflexion. Puis interroger individuellement une personne pour connaître sa réponse. Faire ensuite participer les autres et inscrire les réponses au tableau. Voici quelques réponses : L’IHM du logiciel doit aller vite = quel délai (secondes) pour quelle interaction avec l’IHM. Eventuellement on aborde des notions de vitesse pic et vitese moyenne. Le logiciel devra interagir avec des personnes en situation de handicap : c’est l’IHM qui est concernée. Soit on prévoit un dispositif adaptable facilement avec des composants interchangeables du marché. Soit on définit quel est le périmètre des handicaps couverts. Les résultats semestriels ne sont accessibles qu’aux responsables de centre. C’est de la sécurité. Il faut la traiter bien évidemment avec des accréditations sur la fonction correspondante, mais pas seulement : il faut verrouiller les données de toutes part (pas de stockage de ces résultats au format texte, pas d’export…). On peut aussi envisager des systèmes séparés (une machine sécurisée qui calcule les résultats semestriel. Il faut donc évaluer le niveau de sécurité par des échelles. Exemple : l’échelle INES pour les accidents nucléaires. Notre voiture doit avoir un régulateur de vitesse robuste Il faut d’abord savoir ce que veut dire robuste : tous les combien il peut tomber en panne. Y-a-t-il des pannes plus critiques que d’autres (panne lorsque la voiture roule). Un système est robuste lorsqu’il ne tombe pas en panne. On étudie donc la panne associée à chaque élément du système (capteurs, bus de transfert, connecteurs…) et on fait des statistiques de MTBF. On peut associer de la redondance au système pour le rendre plus robuste. De la même façon pour un logiciel, on l’étudie sous forme boite noire en entrant des informations normales et aux limites pour s’assurer que tous les parcours de code ont été réalisés (pensez à la catastrophe d’ARIANE 501 dont le module inertiel provenait d’une ariane 4). Notre système d’exploitation doit être plus efficace que Windows. Plus efficace que… est le cauchemar du concepteur!!! Parce que Windows ne se comporte pas de la même façon selon l’application que l’on utilise, selon la machine sur laquelle il tourne… Il faut donc préciser l’efficacité selon un standard? Par exemple moins d’informations stockées en mémoire impose d’utiliser des tableaux de taille réduite et donc de faire des calculs plus compliqués. Ce logiciel de paye doit coûter moins cher que la dernière fois. 1/ Moins cher à qui? A prestataire qui le produit, à l’entreprise qui le vend ou au client qui l’achète? 2/ Quel est le prix du précédent. 3/ Moins cher à quel niveau? Ne pas oublier les phases de formation, de maintenance, de déploiement qui peuvent être coûteuses 4/ Il existe un logiciel. Il faut donc réutiliser à outrance et réduire les exigences fonctionnelles qui changent de l’un à l’autre. © 2007 Capgemini - All rights reserved

Principes de traçabilité au cours du projet
NIVEAU 0 : EXIGENCES NIVEAU 1 : CONCEPTION GEN. NIVEAU 2: CONCEPTION DET. Cahier Dossier Dossier Demande Spec . A des Propale Conc . Spec . C Spec . B Conc . Modification Spec . D Charges Gen . Det. . c Matrice de Matrice de couverture couverture Exigences REPONSES REPONSES Exigences NIV1 NIV2 Matrice de couverture OU c Plan de Tests © 2007 Capgemini - All rights reserved

Principe de la traçabilité
Document d’exigences Document de réponses Points à souligner: Une exigences peut être couverte par une ou plusieurs réponses Une réponse peut couvrir une ou plusieurs exigences © 2007 Capgemini - All rights reserved

Règles appliquées aux identifiants
L’identifiant de tout type d’exigences doit répondre aux règles suivantes: Utilisation du style Req_ID Nommenclature précise décrite ci-dessous: R07289-CDC-BPR-010_11 Pour approfondir les sujets liés à la traçabilité, reportez vous à la formation : Gestion des exigences - Reqtify [<IdProjetDoc>]-<TypeDoc>-<Decoupage>-< Reference> Groupe Description Format [<RefDoc>] Identifiant du document Optionel: ensemble de chiffres et/ou de caractères (non limité en nombre) <TypeDoc> Type de document Ensemble de chiffres et/ou de caractères (non limité en nombre) <Decoupage> <Reference> Nombre à plusieurs chiffres initialiement numéroté de 10 en 10. Possibilité d’ajouter un second groupe de chiffres Possibilité de suffixer par – ou _ Peut être relatif à un domaine, une fonction… [..] Champ optionel

Dictionnaire des données
Ne fait pas partie des notations UML mais suit la conception et le développement et la maintenance, et évolue tant que le système n'est pas stabilisé Le dictionnaire de données permet de connaître à tout instant les éléments du système se présente sous la forme d'un tableau à 5 champs identificateur retenu pour tout élément description : définition retenue par la MO et la MOE type de l'élément i.e. cas d'utilisation, classe, attributs, relations, etc. référence bibliographique de la description alias : liste des alias de l'identificateur © 2007 Capgemini - All rights reserved

La méthode Si nécessaire, un diagramme d’activité peut précéder cette méthode pour situer la demande du client dans son processus métier global.

Principes de présentation des notations UML
Définition des concepts Présentation des notations point de vue syntaxique point de vue sémantique Règles de Vérification et Validation (V&V) Commentaires sur un exemple

Les diagrammes d’activité – Généralités
Concepts : Activités et contexte Transitions et nœuds Synchronisation Un diagramme d’activité sert à modéliser : les flots de contrôle les flots de données Conséquence : les états représentent des calculs il n’y a pas d’événement externes mais des attentes de fins de calculs il peut y avoir de la concurrence entre activité Un diagramme d’activité traduit un organigramme avec en plus de la concurrence © 2007 Capgemini - All rights reserved

Remarques sur les diagrammes d’activités
Niveau global (modélisation du métier du client) donne une vue macroscopique de l’enchaînement des fonctionnalités correspond à la traditionnelle décomposition hiérarchique fonctionnelle Niveau simple (modélisation technique d’une méthode) permet, pour un objet donné, d’exprimer graphiquement une activité du diagramme d’état en un algorithme traduction directe possible dans un langage de programmation OO (Java, C++, …) l’outil Rapsodhy d’iLogix permet cela © 2007 Capgemini - All rights reserved

Diagrammes d’activité : vue globale
© 2007 Capgemini - All rights reserved

Diagrammes d’activités : les actions et le contexte
Sélectionner la boisson Stéréotype aucun pour l’action, « localPrecondition » et « localPostcondition » pour le contexte Rôle représente la réalisation d’une action métier du processus métier du client les pré et post conditions sont optionnelles Règle de V&V les actions doivent être validées par le client au plus une pré condition et un post condition par action © 2007 Capgemini - All rights reserved

Diagrammes d’activités : transitions et nœuds
Stéréotype aucun Rôle une transition représente un passage d’un action à la suivante. l’état initial est le point de départ de la lecture du diagramme, un point final identifie sa fin le point d’arrêt de flux correspond, dans un diagramme parallélisé, à la fin d’un des traitements parallélisé mais pas sans terminer le processus ‘père’ un nœud conditionnel permet de définir plusieurs possibilités de fonctionnement Règle de V&V un flux connecte toujours deux éléments du diagramme toujours un état initial et au moins un état final par diagramme chaque flux partant d’un nœud décisionnel doit porter des conditions qui doivent décrire l’intégralité de l’espace des solutions © 2007 Capgemini - All rights reserved

Diagrammes d’activités : synchronisation, couloirs d’activités
Stéréotype aucun Rôle Synchronisation : permet la parallélisation des traitements Couloirs : permet l’affectation des traitementsà des responsables différents Les deux concepts sont indépendants Règle de V&V ne pas lier deux activités qui ont été parallélisées © 2007 Capgemini - All rights reserved

Diagramme d’activité simple
Que veut-il dire? Diagramme d’activité simple © 2007 Capgemini - All rights reserved

Présentation générale de MagicDraw
ppt Formation MagicDraw : § Présentation générale +§Les diagrammes © 2007 Capgemini - All rights reserved

Exercice : modélisation d’un téléphone portable
Un fabricant de téléphone portable souhaite réécrire ses spécifications en utilisant UML. Traduisez le texte suivant en diagramme d’activité. Pour utiliser le téléphone il faut d’abord le sortir de sa housse puis l’ouvrir. L’utilisateur compose ensuite le numéro. Lorsque son correspondant décroche il peut engager la conversation. Si le forfait arrive à expiration, la communication est coupée. Sinon l’utilisateur raccroche en fin de communication.

BPMN (Business Process Modeling Notation)
Standardisé par l’OMG et très proche des diagrammes d’activité UML. UML = très complet et orienté objet => rejet de certains clients. BPMN = expression plus simple de la dynamique des processus => mieux accepté. Plus d’informations disponibles sur :

Les diagrammes de cas d'utilisation - Généralités
Composent les itérations des cycles UP Permet de représenter le comportement d'un système vu du côté utilisateur Très utile en phase d'analyse des besoins car structure les besoins des utilisateurs finals Traduit une spécification d'utilisation du système Correspond partiellement à une décomposition fonctionnelle du système Met en évidence les dialogues avec le système Permet de concevoir un système robuste Permet de répartir les fonctionnalités de l’application aux différents membres de l’équipe de production et de déterminer ainsi « Qui fait quoi » © 2007 Capgemini - All rights reserved

Diagrammes de cas d’utilisation : vue globale

Cas d'utilisation – les Concepts
Les acteurs Les cas d'utilisation Les relations entre acteurs et cas d'utilisation Les relations entre acteurs Les relations entre cas d'utilisation Les paquetages Périmètre du système © 2007 Capgemini - All rights reserved

Les acteurs Stéréotype Rôle Règle de V&V
élément extérieur au système ET interagissant avec le système Peut être un humain ou un système ou une réglementation ou …. acteur principal (ex. client) acteur secondaire (ex. agent de maintenance) matériel externe (ex. dispositifs indispensables au fonctionnement du système) système externe (ex. SGBD ou BD) Nécessite une description précise et concise Règle de V&V tout acteur doit communiquer avec le système NB : la présence d'acteurs ne communiquant pas avec le système est tolérée si cela facilite la lisibilité ! © 2007 Capgemini - All rights reserved

Cas d'utilisation (Use case : UC)
Stéréotype aucun Rôle représente un (ensemble de) service(s) rendu(s) par le système est assimilé à une fonction (macroscopique ou microscopique) intervient tout au long du cycle de vie Règle de V&V un cas d'utilisation est toujours en relation soit avec un acteur soit avec un autre cas d'utilisation un UC en tant que fonction est traduit par un verbe d'action correspondant à une notion de traitement NB : une fonctionnalité (UC) isolée traduit une erreur de conception ! © 2007 Capgemini - All rights reserved

Cas d’utilisation : quel niveau de détail?
Règle de base: Le recueil de besoins doit lever toute ambiguïté sur l’analyse et la conception. Le niveau de détail doit être aussi poussé que nécessaire, d’un point de vue métier Comment gérer ce niveau de détail: Ne pas nuire à la clarté en parsemant la description de détails Mettre en commun les règles de gestion générales, avec détails nécessaires Créer un glossaire des concepts communs, avec détails nécessaires Établir un modèle objet préliminaire (orienté données) Donner des exemples de cas d’utilisation suffisamment raffinés mais sans rentrer dans les aspects métier. Par exemple donner les use cases par transaction. © 2007 Capgemini - All rights reserved

Relation entre acteurs et cas d'utilisation
Stéréotype <<communicate>> Rôle représente une communication (signal et données) entre acteur et UC directionnelle ou pas représente l'ensemble de TOUS les dialogues possibles et imaginables entre l'acteur et le cas d’utilisation, i.e. représente l’ENSEMBLE de tous les scénarios nominaux ET non nominaux Règle de V&V doit traduire un dialogue NB : les scénarios permettent de déterminer a priori la robustesse du système © 2007 Capgemini - All rights reserved

Relation entre acteurs ou cas d’utilisations
Rôle la généralisation/spécialisation représente une notion d’héritage : tout ce que sait faire le père, le fils sait aussi le faire ici, pour valider le moyen de paiement, on a trois procédures possibles : vérification de chèque, vérification de carte bleue, vérification de faux billet Règle de V&V B est un cas particulier de A NB : à l’extérieur du périmètre du système (entre acteurs) seules les relations d’héritage sont possibles © 2007 Capgemini - All rights reserved

Relations entre Cas d'Utilisation – include
Stéréotype <<include>> Rôle relation d'inclusion traduisant une obligation et indiquant la réutilisation d’une autre fonctionnalité D contient l’ensemble du comportement de C. Quand on fait une commande sur la Redoute.fr on doit valider le moyen de paiement (contrôle carte bleue). Règle de V&V tout cas d'utilisation doit avoir au moins une relation avec une autre cas d'utilisation ou avec un acteur NB : les relations entre UC correspondent à des demandes de service mais il n'y a pas d'ordre comme dans un graphe d'appels de fonction © 2007 Capgemini - All rights reserved

Relations entre Cas d'Utilisation – extend
Stéréotype <<extend>> Rôle il s’agit d’une relation d’extension non obligatoire : B n’intervient dans le fonctionnement de A que sous certaines conditions. Les deux use cases nécessitent d’être loggé mais on ne se logge que si on n’est pas déjà loggé. L’ « extension point » décrit la condition d’inclusion. Règle de V&V tout cas d'utilisation doit avoir au moins une relation avec une autre cas d'utilisation ou avec un acteur l’utilisateur est connecté au moins avec le cas d’utilisation étendu © 2007 Capgemini - All rights reserved

Paquetage Stéréotype Rôle Règle de V&V
aucun Rôle sert à délimiter le système et ses sous-systèmes Permet de déterminer les frontières du système Règle de V&V aucun paquetage vide ! nombre de relations intra-paquetage plus important que les relations inter-paquetage (notion de cohésion forte des use cases d’un paquetage) NB : tous les éléments ne faisant pas partie d'un paquetage sont externes au système ou sous-système considéré © 2007 Capgemini - All rights reserved

Exercice - suite : modélisation d’un téléphone portable
Notre fabricant souhaite maintenant convertir le texte suivant en diagramme de cas d’utilisation. La principale utilisation du téléphone portable est la communication via le réseau GSM. Cette communication s’obtient en composant un numéro. Il est possible de stocker ce numéro dans le répertoire et de consulter la liste des derniers appels. La sonnerie peut être paramétrée par l’utilisateur.

Validation des spécifications
En interne : Établir une matrice de traçabilité par rapport aux exigences fonctionnelles du cahier des charges Contrôler la complétude de cette matrice. En externe : Les dossiers décrivant les interfaces du système sont-ils corrects? Comportent-ils toutes les interactions? Les maquette des interfaces IHM sont-elle satisfaisantes? Les acteurs sont-ils tous représentés ? L’utilisateur est-il satisfait des séquences présentées ? Y a-t-il des cas d’utilisation manquants ? Les cas présentés font-ils tous partie du système ? Les liens sont-ils tous représentés ? Est ce qu’il en manque ?

Exercice : Trouvez les acteurs
Je suis caché Le système à construire est souligné. Mais quels sont ses acteurs? Notre système de camion à pizza vend des pizzas à des consommateurs en utilisant des produits qui sont achetés chez un grossiste. Il vend aussi du vin italien acheté chez un producteur Le distributeur automatique de billets est alimenté régulièrement par la société ‘l’écureuil’ afin de distribuer des billets à ses clients Nous devons construire un standard téléphonique automatique qui réagit aux appelants La station service distribue à ses clients les carburants qui lui ont été livrés. Elle fournit tous les trimestres un relevé de ses ventes. Camion à pizza : les acteurs sont le consommateur, le grossiste et le producteur. Distributeur de billets : Il y a des clients, mais l’autre acteur n’est pas la banque, c’est un intervenant de la banque. Il faut être précis sur les acteurs. Standard téléphonique : il faut déterminer si le combiné téléphonique est inclus dans le système ou constitue un acteur. Station service : Il y a là deux acteurs sous entendus. Le livreur de carburant DOIT être spécifié parce qu’il va définir une interface avec la station. Le second est le récepteur du relevé. Il y a bien une interface avec l’extérieur pour laquelle il faut définir si c’est le clerc qui l’utilise ou si il y a une communication directe avec les services financiers. © 2007 Capgemini - All rights reserved

Détermination de la robustesse du système : les scénarii
Ne font pas partie d'UML. Ils alimentent les descriptions dynamiques du système (diagrammes d’intéraction UML) les scénarii de test Toute relation de communication entre acteur et UC doit être interprétée comme représentant TOUS les dialogues possibles et imaginables entre l’acteur et l’UC considérés Il faut donc identifier la relation (par exemple lui donner un numéro) identifier tous les événements possibles au sein de ce dialogue associer à chaque événement un scénario distinguer les scénarios nominaux (ce qui est attendu) des scénarios non nominaux (ce qui peut arriver et peut poser problème) montrer que les cas nominaux et les cas non nominaux partitionnent l'espace des cas possibles En pratique un scénario est représenté par un contexte (les hypothèses) une séquence de triplets : date, événement, action (ou réaction ou traitement) du récepteur du signal Important il faut énumérer tous les scénarios et les décrire par une phrase discriminante et très courte inutile de décrire complètement les scénarios © 2007 Capgemini - All rights reserved

Diagrammes de séquences – les Concepts
Sens de lecture vertical : représente la ligne de vie des objets et les périodes d'activité des objets horizontal : représente l'enchaînement des stimuli entre 1 objet émetteur et 1 ou plus objet(s) récepteur(s), i.e. les flots de contrôle (séquence, répétition, alternative) Objet Stimulus Fragments combinés Contraintes temporelles Certains concepts vont à l’encontre de la lecture verticale du diagramme de séquence. Il faut les éviter (Par, Alt) Neg : description de ce qui ne doit pas arriver. Très dangereux : en général traduit une exigence de sécurité qui n’a pas été traduite en fonctionnalité. D’autres sont trop compliqués Le "Weak Sequenceing" est défini par un ensemble de traces ayant ces propriétés : - l'ordre des intéractions présentes dans chaque opérande est maintenu au final, - les intéractions présentes sur des "lignes de vie" (lifeline) différentes dans des opérandes différents peuvent arriver dans n'importe quel ordre, - les intéractions présentes sur des "lignes de vie" (lifeline) identiques dans des opérandes différents sont ordonnées de telle manière que les intéractions du premier opérande arriveront avant celles du second opérande. Donc le "Weak Sequencing" revient à une exécution en parallèle lorsque les participants des opérandes sont disjoints. Le "Weak Sequencing" revient à un "Strict Sequencing" lorsque les opérandes ne font intervenir qu'un seul participant. © 2007 Capgemini - All rights reserved

Diagramme de séquence : vue globale

Les objets et les exécutions
Stéréotype nomObjet : Type Rôle définit un des objets manipulés par le système. un objet peut être anonyme (sans nom). Il représente alors un instance arbitraire de la classe. La ligne pointillée détermine la durée de vie de l’objet Il est possible d’indiquer la création d’un objet en faisant arriver un message sur le rectangle décrivant l’objet Une exécution est matérialisée par un rectangle sur la ligne de vie. C’est la durée où l’objet est actif (le système est occupé par le traitement de cet objet). Les rectangles peuvent être empilés pour indiquer la récursivité des traitements Règle de V&V l’objet doit être contenu dans le système le contexte de l’objet (la valeur des attributs) doit être défini si il a un impact sur la réaction de l’objet dans le diagramme de séquence © 2007 Capgemini - All rights reserved

Les messages Stéréotype Rôle Règle de V&V
Une flèche matérialise un message synchrone un message asynchrone un flux de contrôle (réponse) Rôle le message indique un transfert de contrôle ou d’information entre deux objets. un message peut renvoyer sur l’objet qui l’a généré (cas de l’appel interne d’une des méthodes de l’objet). Eviter les messages vers des acteurs car ils n’ont pas de sens lors des phases de codage Règle de V&V pas d’exécution sans message un message doit être nommé lorsque l’émetteur envoie un message, il doit attendre son la réponse : la durée de l’exécution de l’émetteur est supérieure à celle du récepteur Attention à la règle de V&V « un message doit relier deux objets ou un objet et un acteur ». En effet, UML2 prévoit des ‘messages perdus’ et des ‘messages trouvés’ qui débouchent ou partent d’un simple point. C’est l’exception qui confirme la règle : ces concepts sont peu utilisés. © 2007 Capgemini - All rights reserved

Les fragments combinés
Stéréotype opt, break, loop, par, alt, neg, seq, strict, critical Rôle Indique une rupture dans le déroulement temporel séquentiel du diagramme de séquence Eviter l’utilisation des concepts UML 2.0 suivants : Par (parallèlisation), Alt (alternative), Neg (négative), Seq (weak sequencing), Strict (strict sequencing), Critical (séquence critique), On retiendra par contre : le concept d’Opt (option), de Break et éventuellement de Loop (boucle) © 2007 Capgemini - All rights reserved

Contraintes temporelles
Syntaxe : Flèche oblique vers le bas Rôle : traduit le fait que la transmission du contrôle et des données prend un certain temps Une contrainte temporelle peut s'exprimer sur une durée d'activation par une annotation ou un texte entre { } sur les instants d'émission/réception de messages, par une annotation ou un texte entre { } Sur les différences entre temps, i.e. instants d'émission/réception de messages Règle de V&V les messages ne pointent jamais vers le haut NB : une contrainte temporelle est toujours une expression relationnelle ! © 2007 Capgemini - All rights reserved

Contraintes temporelles : exemple

Exercice : que montre ce diagramme de séquence?
Un objet Un acteur Un message Temps Ligne de vie de l’objet

Diagrammes de séquence : validation d’un cas d’utilisation

Diagrammes de séquence : validation d’un cas d’utilisation
Mise en pratique

Cette fois votre client souhaite que vous lui modélisiez la spécification d’appel en utilisant le répertoire : Le téléphone comporte deux modules. Un pour l’appel et un pour la gestion du répertoire. L’utilisateur commence par accéder au répertoire et sélectionne la fiche d’un de ses correspondants. Il déclenche alors l’appel. Si la fiche comporte plusieurs numéros un menu lui propose de choisir le numéro à appeler. Ceci fait, le module d’appel est mis en œuvre pour effectuer la communication.

Les diagrammes de communication : vue globale
Ce sont des diagrammes équivalents aux diagrammes de séquence, mais avec une vue différente (vue du dessus) 1 2 Le diagramme de collaboration est un diagramme de séquence vu du dessus puisque les messages s’enchaînent d’un objet vers l’autre avec un numéro associé. © 2007 Capgemini - All rights reserved

Diagrammes de séquence : utilisation
Décrire la réalisation des cas d’utilisation à travers des diagrammes de séquence: En phase d’analyse métier: Un diagramme montrant l’exécution de base de chaque séquence du cas d’utilisation Un ou plusieurs diagrammes pour modéliser les exécutions alternatives du cas d’utilisation Un ou plusieurs diagrammes pour modéliser les exécutions exceptionnelles ou optionnelles du cas d’utilisation Les messages sont des opérations sur les objets cibles

Importance des diagrammes d'interaction
Essentiel : un scénario = un diagramme de séquence ou un descriptif textuel détaillé un scénario = 1 et 1 seule suite d'actions (seule la séquence est autorisée) les scénarii doivent décrire TOUS les cas de traitements de TOUS les événements possibles on détermine ainsi la robustesse du système Diagrammes de séquence identification des objets, et donc des classes potentielles identification des échanges entre objets, issus des scénarios Diagrammes de communication identification des responsabilités identification des rôles © 2007 Capgemini - All rights reserved

Les diagrammes de classe
Un élément essentiel (mais ce n'est pas le seul) de l'approche orientée-objet Expriment l'aspect structurel/statique d'un système en termes de classes relations Offrent également les interfaces - comment on voit/utilise le système modélisé les paquetages - comment on peut abstraire le système en (macro) composants © 2007 Capgemini - All rights reserved

Diagramme de classe : vue globale

Les classes Une classe = abstraction pour un ensemble d'objets ayant le même état, offrant le même comportement et ayant les mêmes liens avec d'autres objets UML offre aussi différents types de classes, proches de l’implémentation les classes énumération les métaclasses les processus ou les threads, … NB : une classe doit être spécifiée à au moins 2 niveaux niveau application : classe métier ou classe d'analyse niveau implémentation : traduction informatique d'une classe métier (le mapping peut être 1-1) insertion de classes dédiées (par ex. les conteneurs) assurant les performances ou l'indépendance © 2007 Capgemini - All rights reserved

Représentation d'une classe
1 à 4 champs : nom de la classe : obligatoire 0 ou n attributs 0 ou n opérations 0 ou n invariants de classe, exceptions, … Présence de stéréotype <<class>> : implicite <<utilitaire>> <<interface>> <<signal>> <<acteur>> : ne devrait pas apparaître ! …. NB : l'outillage actuel ne permet pas toujours de respecter UML 2.0 ! Le 4e champ n’est pas directement représentable © 2007 Capgemini - All rights reserved

Les attributs Stéréotype Rôle
aucun Rôle sémantique : constitue un élément de l'état de l'objet visualisé ou pas, selon le niveau de détail souhaité … : liste d'attributs incomplète syntaxe : Visibilité Id [Multiplicité] : Type [InitVal] [{Propriété}] Visibilité = type d'accessibilité + : public - visible et modifiable par tout objet du même paquetage - : private - seulement visible et modifiable par les opérations de l'objet auquel il appartient. # : protected - seulement accessible et modifiable par les opérations des classes descendantes Multiplicité : intervalle ou nombre Propriété : par ex. mutabilité i.e. gelé, variable, ajoutUniquement Règle de V&V le principe de masquage impose de rendre chaque attribut private pas d'attribut redondant autre que les attributs dérivés NB : Attribut dérivé : attribut qui peut être déduit par le calcul (/Attribut) et qui conduit en implémentation à une opération © 2007 Capgemini - All rights reserved

Les opérations Stéréotype Rôle Règle de V&V
aucun a priori <<crée>>, ... existent ! Rôle représente un service spécifique offert par un objet ; peut être considérée comme une fonction au sens mathématique du terme => recopie des paramètres et renvoi d'un résultat et d'un seul ! Syntaxe : Visibilité Id ( [Args] ) : Type [{Propriété}] Visibilité : +, -, # Args : Direction Id : Type [= DefaultVal] Direction : in, out, inout (in est la valeur par défaut) Propriété : requête, concurrence, abstrait, estFeuille, estRacine Règle de V&V sémantique d'une fonction, i.e. correspond à un traitement un seul résultat (contradiction apparente entre in et type retourné par une opération) NB : au niveau métier on ne doit jamais représenter les opérations de création et de suppression © 2007 Capgemini - All rights reserved

Identification des classes, attributs et opérations
C'est lors de la construction des diagrammes d'interaction (séquences et/ou collaboration) que les objets réels sont identifiés Ils sont transformés en classes s'il y a des messages échangés sinon en attribut Les opérations des classes correspondent aux messages échangés entre objets réels Règle de V&V il est essentiel de vérifier que tout classe possède des attributs et/ou des opérations. Dans le cas contraire, il ne s’agit vraisemblablement pas d’une classe mais d’un attribut d’une classe de plus haut niveau. Sachez ne pas aller trop loin dans le raffinement. NB : si ce n'est pas le cas, il faut impérativement justifier pourquoi ! © 2007 Capgemini - All rights reserved

Les classes Interfaces
Stéréotype <<interface>> Rôle décrit le comportement visible de certaines classes représentée par un rond rattaché à une classe ne figurent que des opérations publiques pas d'attribut Règle de V&V s'agit-il bien d'une interface physique ? NB : penser à la notion de menu et sous-menu pour la notion de classe interface une classe interface peut être la réalisation de plusieurs classes © 2007 Capgemini - All rights reserved

Classes paramétrables, classes utilitaires
Classe paramétrable = classe générique représentée par un classe traditionnelle avec un rectangle à traits tiretés dans la coin droit supérieur les paramètres de généricité sont identifiés dans le rectangle à traits tiretés classe sans instance classe surtout utilisée en implémentation une classe instance est liée à une classe paramétrique par une flèche tiretée Classe utilitaire = représente des bibliothèques joue un rôle d'élément global contenant des opérations et/ou des attributs présence du stéréotype <<utilitaire>> Classes paramétrables/génériques : on parle aussi de patrons, de modèles Classe interface : Définit un comportement public et des obligations qu’assure la classes. Elle est représentée par un rond avec le nom de la classe dessous. Classe utilitaire : classe dont ses attributs, opérations sont visible de tous et static. Représentée par le stéréotype <<utilitaire>> dans la classe. Exemple : classe d’opérations mathématique et de PI. © 2007 Capgemini - All rights reserved

Les relations Elles sont de 3 types et traduisent :
la notion d'assemblage/composition le concept de spécialisation/généralisation l'association entre une (réflexivité) ou plusieurs classes Elles représentent des liens statiques/structurels entre objets et à longue durée de vie NB : les associations ne sont en général pas directement supportées par les langages de programmation orienté-objet. © 2007 Capgemini - All rights reserved

Agrégation/composition
Relation non symétrique Une extrémité supporte la notion de responsabilité : toute opération/attribut du responsable peut se propager aux éléments contraints il y a subordination Agrégat/agrégé : durée de vie des agrégés indépendante de l'agrégat Composite/composant : durée de vie des composants dépendante du composite/conteneur - on parle d'embarquement Exemple type d’agrégation : le mur séparant deux pièces. Il est utilisé par deux pièces et est donc partagé. La disparition d’un mur a bien pour effet de faire disparaître la pièce et c’est donc bien un de ses constituants, mais la pièce continue d’exister sous forme d’une mise en commun de deux volumes. Autre exemple : l’employé et l’employeur : l’employé ne disparaît pas forcément lorsqu’il quitte l’employeur, pourtant ce n’est plus un empoyé. © 2007 Capgemini - All rights reserved

Généralisation/spécialisation
Relation de classification entre un élément plus général et des éléments spécialisés L'élément spécialisé hérite des attributs et des opérations et des relations et des contraintes de l'élément dont il est la spécialisation L'élément spécialisé peut avoir ses propres attributs, opérations, relations Spécialisation simple ou multiple B hérite de A si dans tout contexte ou l’on utilise A on peut remplacer A par B Attention si le périmètre du logiciel change, les contextes sont augmentés, et la règle de remplacement peut ne plus être vérifiée © 2007 Capgemini - All rights reserved

L’héritage multiple – à éviter
Une classe peut avoir plus d’une classe mère. Plusieurs parcours d’héritage sont alors possibles. L’objectif est de fusionner en une nouvelle classe, et éventuellement les y spécialiser, des comportements appartenant normalement à des classes différentes. L’intérêt est de pouvoir fusionner des ascendants directs d’importance voisine ou d’ajouter à une classe d’autres fonctionnalités. moyen de transport Attention: L’héritage multiple est rarement nécessaire en phase d’analyse. Certains langages ne le supporte pas (Java). naval aérien hydravion

L’héritage: règle de modélisation
Il n’est pas souhaitable de se focaliser sur les relations d’héritage trop vite L’héritage est une notion très structurante dans un modèle objet. Elle fige la structure sémantique des types d’objet. L’ajout d’une nouvelle classe est obligatoirement influencé par les relations d’héritages existantes. Il faut rester ouvert le plus longtemps possible. C’est uniquement quand on estime que toutes les classes du domaine fonctionnel ont été identifiées que l’on peut commencer à réfléchir sur les abstractions du système et ainsi construire les premières classes abstraites.

Diagrammes de classes lors des phases d’analyse
En phase d'analyse métier, seules des classes métier doivent être identifiées (opérations métier, attributs métier et associations métier). La recherche de classes, attributs, opérations et associations est guidée par la réponse au besoin : expliciter les diagrammes de séquence correspondant aux cas d'utilisation recensés Les paquetages permettent d'organiser l'analyse en domaines métier. La notion de visibilité est absente: en analyse, toutes les propriétés sont publiques (potentiellement visibles par l'utilisateur du système). La notion d'interface est absente (utilisées en architecture et conception uniquement).

Associations et classe association
Représente une propriété statique (se convaincre avec un diagramme d'instances) Lie une ou plusieurs classes : arité 2 ou plus Toute association doit être nommée par un verbe d'état ou comporter des rôles aux extrémités Toute association peut être navigable Multiplicité : 0..1 N M..N *, 0..* 1..* © 2007 Capgemini - All rights reserved

Remarques sur les Associations
Ne prendre en compte que des associations binaires ! Si ce n'est pas possible, il faut privilégier les classes associations Le nommage est indispensable quand il y a plusieurs associations entre 2 classes. Ne s'agit-il pas d'un agrégat ? Importance des contraintes ! Sous-ensemble, et/ou, etc. {ordonné}, ... Attention à ne prendre pour associations que des relations dont le libellé représente un verbe d'état © 2007 Capgemini - All rights reserved

Exercice : Ne pas confondre associations et messages
Trouver, parmi les phrases suivantes, celles qui décrivent des messages échangés et celles qui décrivent des associations entre des classes : Assoc. Mess.  Le livre est composé de pages  La carte grise correspond à une voiture  Le serveur envoie un mail d’alarme  Le feu rouge est équipé d’une boucle de détection dans la chaussée qui est activée par les voitures  J’achète et je bois un café à la machine à café  L’auteur écrit des livres  Le client retire de l’argent  Mr X dirige ces personnes Le livre … : Relation structurelle forte (composition) = association livre-pages La carte grise… : Relation d’association entre carte grise et voiture Le serveur… : C’est bien un message qui est échangé Le feu rouge… : la boucle est en association avec le feu (c’est la boucle du feu) mais l’activation par les voitures constitue un message envoyé par les voitures. Mr X… : On peut le voir de deux façons. Soit il s’agit d’un contexte entreprise, avec une relation durable de subordination (‘Mr X est le directeur’) auquel cas on va créer une association. Soit il s’agit d’une relation brève (Mr X dirige des personnes qui cherchent leur chemin, ou des malvoyants pou traverser la route) et auquel cas il s’agit bien d’un message Je bois un café : cela pourrait être une relation de message puisqu’il s’agit bie d’une action mais comme un café est un consommable ce serait plutôt un paramètre. L’auteur écrit… : relation d’association entre l’auteur et le livre car le fait d’écrire un livre fait que ce livre lui appartient. Le client retire… : c’est un service, donc un message qui transite entre le guichet et le client. © 2007 Capgemini - All rights reserved

Exercice : Ne pas confondre associations et messages
Trouver, parmi les phrases suivantes, celles qui décrivent des messages échangés et celles qui décrivent des associations entre des classes : Assoc. Mess.  Le livre est composé de pages  La carte grise correspond à une voiture  Le serveur envoie un mail d’alarme  Le feu rouge est équipé d’une boucle de détection dans la chaussée qui est activée par les voitures  J’achète et je bois un café à la machine à café  L’auteur écrit des livres  Le client retire de l’argent  Mr X dirige ces personnes      Le livre … : Relation structurelle forte (composition) = association livre-pages La carte grise… : Relation d’association entre carte grise et voiture Le serveur… : C’est bien un message qui est échangé Le feu rouge… : la boucle est en association avec le feu (c’est la boucle du feu) mais l’activation par les voitures constitue un message envoyé par les voitures. Mr X… : On peut le voir de deux façons. Soit il s’agit d’un contexte entreprise, avec une relation durable de subordination (‘Mr X est le directeur’) auquel cas on va créer une association. Soit il s’agit d’une relation brève (Mr X dirige des personnes qui cherchent leur chemin, ou des malvoyants pou traverser la route) et auquel cas il s’agit bien d’un message Je bois un café : cela pourrait être une relation de message puisqu’il s’agit bien d’une action mais comme un café est un consommable ce serait plutôt un paramètre. L’auteur écrit… : relation d’association entre l’auteur et le livre car le fait d’écrire un livre fait que ce livre lui appartient. Le client retire… : c’est un service, donc un message qui transite entre le guichet et le client.   Dépend du contexte MOA © 2007 Capgemini - All rights reserved

Commentaires, notes et dépendances
Commentaires et notes utilisation d'annotation peut être attachée à tout élément UML une note, comme dans l'exemple permet d'introduire des propriétés, des contraintes, etc. Dépendance relation qui traduit que le changement d'un élément quelconque a un impact sur un autre élément © 2007 Capgemini - All rights reserved

Le client désire comprendre comment les éléments de votre système vont être connectés. Vous décidez donc de traduire le cahier des charges suivant en diagramme de classes : Le système du téléphone comporte un gestionnaire de fonctions. C’est lui qui contient les différentes fonctions ( contrôleur d’appels, répertoire, éditeur SMS et calculatrice) et assure la navigation dans les menus. Les différentes fonctions offrent un comportement identique. Le répertoire contient des fiches contact comportant un nom et un numéro de téléphone. Il est possible d’en stocker 200 dans la carte mémoire. L’éditeur SMS contient des SMS formalisés par un numéro de téléphone et un texte. Le contrôleur d’appel stocke les appels émis et reçus sous forme d’une date d’appel et d’un numéro.

Diagramme d’état-transition : vue globale

Les diagrammes d’états-transitions
Un diagramme d’états-transition = représentation d’un automate : tout objet ou tout système possède un état à chaque instant Un diagramme d’états-transition permet de représenter le comportement nominal ET non nominal de toute instance d’une classe Un diagramme d’états-transition devrait permettre également de représenter le comportement global d’une application orientée objet : enchaînement des commandes ! Mais trop souvent le nombre d’états est trop grand pour être représenté ! © 2007 Capgemini - All rights reserved

Diagrammes d’états-transition : les concepts
Etat à tout instant un état représente l’ensemble des valeurs des attributs et des liens avec les autres objets un état est caractérisé par une durée, i.e. une certaine stabilité dans le temps Transition connexion unidirectionnelle reliant 2 états assure le passage d’un état à l’autre est supposée instantanée une transition peut être réflexive Evénement occurrence de quelque chose qui arrive à un instant inconnu ou connu (interruption, envoi de message, …) peut être porteur d’informations doit avoir été prévu par la conception l’événement est le déclencheur d’une transition IT = Interruption Que se passe-t-il si l’événement n’a pas été prévu par la conception ? - il est ignoré (système non conforme) - il fait réagir le système alors que ce n’était pas prévu (système non robuste) © 2007 Capgemini - All rights reserved

Etat Un état est toujours nommé Il comporte : Etats particuliers :
des actions d’entrée des actions de sortie des activités des inclusions de sous-états Etats particuliers : état initial (forcément unique) état final (0, 1 ou plusieurs) © 2007 Capgemini - All rights reserved

Les transitions Une transition est une relation entre un état source et un état cible. Une transition est déclenchée par un objet en réaction à un événement et conduit à un changement d’état. Syntaxe : évènement[garde]/action Les éléments suivants sont tous facultatifs : évènement (trigger) : événement externe déclenchant une réaction du système garde (guard) : expression logique qui conditionne le départ d’un état action : action exécutée lors du franchissement de la transition © 2007 Capgemini - All rights reserved

Evénement Il traduit l’arrivée de quelque chose Types d’événement :
<<signal>> : signal asynchrone <<crée>>, <<détruit>>, … : appel <<top>> : signal synchrone - fin de délai, top horloge, … événement instantané : pas de label - correspond à la fin de l’activité dans l’état de départ Sémantique des événements : à l'arrivée d'un événement prévu, on quitte l'état, que l'activité soit achevée ou pas © 2007 Capgemini - All rights reserved

Compléments sur les diagrammes d’états-transitions
La maîtrise de la complexité des diagrammes états-transitions passe par l’utilisation d’états composite (état englobant) Les sous-états concurrents permettent de représenter la notion de concurrence Les états historiques permettent de conserver l’historique en tant qu’états, et donc d’y revenir © 2007 Capgemini - All rights reserved

Concurrence pour les diagrammes états-transitions

Une partie du cahier des charge du téléphone portable est compliquée et gagnerait à être traduite en diagramme d’état transition : Pour utiliser le téléphone il faut passer du mode veille au mode actif en cliquant sur le bouton on. Le mode appel permet de communiquer vocalement. On y accède en composant un numéro de téléphone et on le quitte en appuyant sur le bouton de fin de communication. On peut passer en mode gestion des SMS en appuyant sur la flèche gauche. Et on le quitte en appuyant sur Ok. Si un appel survient durant l’écriture d’un SMS le SMS est stocké et le téléphone passe en mode appel. De plus le téléphone interroge en permanence le réseau afin de déterminer si il doit émettre avec une puissance de signal forte ou faible.

Diagramme global d’intéraction

Diagramme de composants
Traduit l’aspect implémentation en proposant une structure en composants et paquetages Les composants représentent les éléments de conception réutilisables : ils contiennent des classes ils présentent des interfaces et leurs interdépendances Propriétés importantes au sein d’un composant couplage fort entre composants, couplage lâche Paquetage = ensemble de composants © 2007 Capgemini - All rights reserved

Règles de nommage Objectifs : homogénéiser les informations pour faciliter la lecture la traçabilité vers la conception détaillée et le codage Unicité : Les noms de domaines, de packages et sous-packages doivent être uniques à l’échelle du progiciel pour être réutilisables. Caractères : Les noms du modèle sont formés d’alternances majuscules/minuscules. Les caractères accentués ne doivent pas être utilisés. Les autres caractères (espaces, ponctuation…) sont à éviter mais les chiffres peuvent être utilisés. Nommage des domaines : Les domaines, packages et sous-packages métier sont utilisés en phase de définition des exigences, en phase d’analyse et en phase de conception détaillée. Pour éviter les collisions de nom ces concepts seront préfixés de la façon suivante : BR (Business Requirement) en phase de recueil des besoins. BRCommunication par exemple. BM (Business Model) en phase d’analyse. BMCommunication par exemple. Pas de préfixe en phase de conception technique (Technical Model), afin de faciliter la traçabilité ou la génération de code associée à la modélisation Nommage des classes : Les classes métier sont nommées par leur nom métier naturel, de même que leurs attributs, opérations, associations. Une classe commence par une majuscule. Les autres concepts commencent par des minuscules. Lorsque le nom est composé de plusieurs mots, les mots suivants commencent par des majuscules. Nommage des règles de gestion : Les règles de gestion définies à l’échelle d’un domaine, package ou sous-package seront codifiées de la façon suivante : <nom-domaine>[_<nom-package>[_<nom-souspackage>]]_<numéro-de-règle>

Exercice : le jeu des 7 erreurs

Exercice : le jeu des 7 erreurs - Solution
BRGarage

Synthèse Définir les paquetages des domaines fonctionnels.
Définir les scénarii des fonctionnalités du système Documenter tous ces éléments à chaque étape. Ajuster les liens d’héritage au fur et à mesure. Vérifier la complétude par des diagrammes de séquence mettant en jeu les objets métier. Spécifier les classes, attributs, associations, opérations réalisant les cas d’utilisation. Définir la composante temporelle des objets métier par des diagrammes d’état. Vérifier les dépendances entre classes et les dépendances induites entre paquetages. Éliminer les dépendances croisées. Ajuster le modèle et itérer.

Le dossier de validation
Constitué de cas de test structurés autour de : Un contexte de fonctionnement / des pré requis Des données de test (ou jeu de test) Des scénarii de test découpé en pas de test Des résultats attendus L’outil à utiliser pour réaliser ce dossier est Test Director de HP / Mercury : Accès à Mercury : Pour approfondir les sujets liés aux tests de validation, reportez vous aux formations : Les Tests – Management : outil et process Tests de Validation et Tests de Non-régression : outils & process © 2007 Capgemini - All rights reserved

Relations entre spécifications et tests
La spécification sert de base aux tests de validation Lors de la phase de recueil des besoins, étudier la nécessité de disposer d’un simulateur/bouchon pour chaque association entre le système et un acteur ‘non humain’. Rédiger le dossier de test : Inscrire dans le cas de test la référence de l’exigence à laquelle il correspond. Rédiger un cas de test pour chaque diagramme de séquence ou d’activité. Ces cas de test sont identifiés avec une criticité maximale. Règle : un pas de test pour chaque message du diagramme de séquence. Rédiger un cas de test pour chaque scénario identifié lors des phases de spécification. La criticité du cas de test sera évaluée en fonction de l’importance de la fonctionnalité et de la probabilité d’apparition du scénario Réclamer les jeux de test au client et/ou les construire à partir des paramètres définis dans les scénarii. Faire évoluer les cas de test en ajoutant les résultats attendus. Etablir le contexte de passage du cas de test.

La modélisation et les livrables
Le livrable correspond à une extraction du modèle. Donc tout doit être répertorié dans le modèle UML. En pratique Spécifications générales, préliminaires Vision et vue métier Cas d’utilisation essentiels Quelques diagrammes de séquence Spécifications détaillées Cas d’utilisation réels Besoins d’exploitation Besoins opérationnels induits Diagrammes de séquence Modèle objet du domaine Parfois séparation Spécifications fonctionnelles Spécifications techniques Mise en pratique : Outils/Report Wizard © 2007 Capgemini - All rights reserved

Modèles de documents Modèles Capgemini adaptés à une traçabilité Reqtify (nommés Req_xxx) Dossier de spécifications (DS) Dossier d’architecture (DAR) Dossier de conception (DC) Dossier de tests (DT) Accessibles sur dans le processus « définir les spécifications fonctionnelles et l'architecture » (login f_indus_1 mot de passe F_indus_1) © 2007 Capgemini - All rights reserved

Aperçu de MDA : Transformation de modèles
Ensemble de normes, de standards développés par l’OMG en 2001 étend celui de l’UML(Unified Modeling Language). Utilisation systématique de modèles Permet le passage du PIM (Platform Independant Model) au PSM (Platform Specific Model). Procédé qui permet de convertir d’un modèle à un autre modèle du même système à implémenter. Conversion de manière automatisée avec des outils comme: ATL(Atlas Transformation Language) VIATRA(VIsual Automated model TRAnsformations) Passage du PSM au code : suite logique de MDA au moyen d’outils tels qu’Acceleo, androMDA, MIA… Utilisation systématique de modèles = conception ‘model centric’ © 2007 Capgemini - All rights reserved

Aperçu de MDA : l’ingénierie des modèles
le concept « tout objet » vs le concept « tout modèle ». « remplacer la composition d’objet par la notion de transformation de modèle » Standard MDA: faciliter la production de modèles. Exemple de processus de transformation de modèles: On ne travaille plus sur le modèle, on travaille sur les règles de transformation. A l’origine, MDA a été décliné sur CORBA… probablement pour faire la promotion de cette autre norme de l’OMG? Pour approfondir les sujets liés à MDA, reportez vous à la formation : MDA © 2007 Capgemini - All rights reserved

L’évolution du travail de conception avec UML
L’explorateur, la carte routière et le GPS : Avant – l’époque de l’explorateur (l’expert) passe beaucoup de temps à essayer toutes les routes finit par connaître le coin comme sa poche mais il est perdu lorsqu’il doit s’aventurer ailleurs n’a pas peur de sortir des sentiers battus Maintenant – l’époque de la carte routière (le concepteur) donne un vision d’ensemble (pas de détails sur les feux rouges) permet de se repérer sur de très longues distances Bientôt – l’époque du GPS (le composant) s'occupe de tout l’utilisateur devient incapable de savoir où on est, où il va impossible de juger de la qualité du trajet, de trouver une solution alternative si le système tombe en panne Prendre l’exemple d’une personne qui souhaite aller de Paris à Dakar. On a deux solutions : soit on a une vision d’expert ou de GPS (il faut tourner à gauche, deux fois à droite, la suivante à gauche…), soit on a une vision de concepteur (il faut aller vers le sud par l’autoroute, puis par bateau puis par la piste). © 2007 Capgemini - All rights reserved

A RETENIR Le use case sert de pivot à toute la conception.
Un outil de modélisation est indispensable pour manipuler et stocker le référentiel des objets du modèle La traçabilité se fait sur l'ID de référence du use case (numéro dans le use case ou nom du use case). La bonne granularité est obtenue lorsque l'on peut écrire un scénario fonctionnel nominal pour le use case. Un use case = 4 ou 5 scénarii de test (nominaux et non nominaux). Au delà le use case est trop compliqué et doit être découpé. Penser à appliquer des CRUD lorsque possible (ou des CUD avec le R ailleurs). Créer un glossaire métier avec des liens hypertexte des concepts UML vers ce glossaire Il n’y a pas de correspondance 1 à 1 entre une classe métier et une classe du modèle de base de données. En effet, pour des raisons de performances ou de choix d’implémentation, une classe métier peut être transformée en plusieurs tables ou même plusieurs classes métiers peuvent être transformées en une seule table. CRUD = Création, Recherche, Update, Destruction. Utiliser un CRUD évite de démultiplier les use cases. © 2007 Capgemini - All rights reserved

Quiz – Quel est le terme utilisé pour décrire une exécution conditionnelle dans un diagramme de séquence : ? ü  alt  critical  opt  ref Quiz sur l’ensemble des sujets de la session, plutôt long, pour vérifier l’acquisition des connaissances répéter des messages clés conclure la session © 2007 Capgemini - All rights reserved

Quiz – Qu’est-ce qu’une relation?
ü  Un élément avec au moins un élément relié  Un élément qui connecte deux éléments  Un élément qui connecte au moins deux éléments © 2007 Capgemini - All rights reserved

Quiz – Quelle affirmation est fausse :
?  Un objet est une instance de classe ü  Une classe est une collection d’objets semblables  Un objet est une entité aux frontières bien définies, possédant une identité  Une classe est un descripteur d'objets similaires © 2007 Capgemini - All rights reserved

Quiz – Quelles séquences d’évènements (à partir de l’état initial) conduisent à un blocage du système : ? ü  b  a e a  a e f ü  a e b B AED n’a pas de sens AEB © 2007 Capgemini - All rights reserved

Quiz – L’extension d’un cas d’utilisation UC1 par un autre cas d’utilisation UC2 (avec un lien “extend” d’UC2 vers UC1) : ? ü  UC2 enrichit UC1 sans le modifier  Modifie UC2 en lui ajoutant du comportement  Décrit une généralisation de UC1 vers UC2 © 2007 Capgemini - All rights reserved

Références documentaires
UML 2 en action De l'analyse des besoins à la conception Pascal Roques, Franck Vallée Eyrolles 2007 Guide pratique du RUP Philippe Kruchten et Per Kroll CampusPress 2003 Introduction au Rational Unified Process Philippe Kruchten Eyrolles 2000 Modélisation objet avec UML Pierre-Alain Muller, Nathalie Gaertner Eyrolles 2000 The Unified Modeling Language Reference Manual James Rumbaugh, Ivar Jacobson, Grady Booch Addison-Wesley 1999 Design Patterns: Elements of reusable object-oriented software E.Gamma & al. Addison-Wesley 1995 Exercices corrigés d’UML : Génie logiciel Pascal André, Alain Vailly Ellipses, 2003

Wi http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud
Liens Lien vers le wiki A&D : Wi Lien vers CTF Indus A&D, Modélisation et Magic Draw : FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.

Suivi des modifications
Version Date Auteur Résumé et raisons des modifications 1.0 Octobre 2011 O.Carton P. Blanc Version initiale 1.1 Dec 2011 A.Piccardi Suppression des services Indus Slide masqué permettant de suivre l’évolution des différentes versions. Si vous avez des questions concernant ce document, Merci de contacter le(s) auteur(s) du document FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 152

UML - Conception fonctionnelle

Présentations similaires

Présentation au sujet: "UML - Conception fonctionnelle"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

UML - Conception fonctionnelle

Présentations similaires

Présentation au sujet: "UML - Conception fonctionnelle"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back