Systèmes d’information dans les entreprises Chargé: JF Couturier Cours # 4 GTI515 Automne 2011 JF Couturier

Retour sur les derniers cours Le document de vision Petit retour sur les diagrammes d’activité et le modèle du domaine Les techniques d’explicitation des exigences (brainstorm, prototypage…) Le modèle du domaine Étude du cas de la formation des employés GTI515 Automne 2011 JF Couturier

Retour sur l’étude de cas Faire le modèle du domaine pour l’étude de cas « Formation d’un employé » Liste des entités Exemples… GTI515 Automne 2011 JF Couturier

Messages Au prochain cours Rappel : Quiz 2 1ere Évaluation du cours, soyez là! Rappel : Les remises se font toujours en format papier ET en format électronique Utiliser la page titre fournie sur le site Web du cours, dans la section laboratoire. GTI515 Automne 2011 JF Couturier

Plan du cours 4 Diagramme des cas d’utilisation Les cas d’utilisation Le SRS Les cas de test Prochain cours GTI515 Automne 2011 JF Couturier

Les modèles du cycle de développement de logiciels Modèle des Processus d’affaires Domaine Modèle des Cas d’utilisation Exigences Modèle d’analyse du système Analyse Modèle de conception du système Conception Code Réalisation

Rappel Processus métier élémentaire (PMÉ) Une tâche accomplie par une personne dans un endroit à un instant donné, en réponse à un événement qui donne un résultat et laisse les données dans un état cohérent (Larman, p.88) Cas d’utilisation Une description des séquences d’actions qu’un système accomplit et qui donnent un résultat observable pour un acteur particulier (Rational) En général, 1 PMÉ = 1 Cas d’utilisation GTI515 Automne 2011 JF Couturier

Les PMÉ du garage GTI515 Automne 2011 JF Couturier

Comprendre les besoins GTI515 Automne 2011 JF Couturier

Digramme des CU Diagramme UML représentant le comportement fonctionnel d’un système. Permet de visualiser les différentes actions des utilisateurs (ici des acteurs) Fait partie des diagrammes proposés par UML 2.0 GTI515 Automne 2011 JF Couturier

Diagramme des CU On décrit les interactions entre les utilisateurs et le système Le système est ici une boîte noire, on ne souhaite pas savoir pour l’instant comment il réalise sa tâche. Diagramme puissant pour communiquer avec le client GTI515 Automne 2011 JF Couturier

Exemple diagramme des CU OMG Unified Modeling LanguageTM (OMG UML), Superstructure GTI515 Automne 2011 JF Couturier

Exemple diagramme des CU OMG Unified Modeling LanguageTM (OMG UML), Superstructure GTI515 Automne 2011 JF Couturier

Diagramme du cas d’utilisation GTI515 Automne 2011 JF Couturier

Acteur Personne, organisation, système externe qui réalise un ou plusieurs cas d’utilisation. Il est important de ne pas mettre un individu, mais plutôt un rôle. GTI515 Automne 2011 JF Couturier

Acteur C’est mal C’est bien GTI515 Automne 2011 JF Couturier

Diagramme des CU 4 types de relation Association Extend Include Généralisation GTI515 Automne 2011 JF Couturier

Association Permet simplement de relier un acteur avec son ou ses cas d’utilisation GTI515 Automne 2011 JF Couturier

Les relations entre cas d’utilisation (Chapitre 30 de Larman) À n’utiliser qu’à bon escient… La relation “extend” Pour représenter un comportement additionnel optionnel. La relation “include” Pour représenter un comportement commun à plusieurs cas. Il est obligatoire dans la réalisation du cas d’utilisation appelant. La relation de généralisation (à éviter) Pour représenter une similarité conceptuelle entre les cas ou les acteurs. GTI515 Automne 2011 JF Couturier

Exemples de « extend » GTI515 Automne 2011 JF Couturier OMG Unified Modeling LanguageTM (OMG UML), Superstructure GTI515 Automne 2011 JF Couturier

Exemple de « include » GTI515 Automne 2011 JF Couturier OMG Unified Modeling LanguageTM (OMG UML), Superstructure GTI515 Automne 2011 JF Couturier

Exemple de « Généralisation » GTI515 Automne 2011 JF Couturier

Le système Vos cas d’utilisation doivent se retrouver dans les limites d’un système Toujours tracer une boîte où placer vos CU. Toujours identifier le système GTI515 Automne 2011 JF Couturier

Le système GTI515 Automne 2011 JF Couturier OMG Unified Modeling LanguageTM (OMG UML), Superstructure GTI515 Automne 2011 JF Couturier

Questions GTI515 Automne 2011 JF Couturier

Réponses GTI515 Automne 2011 JF Couturier

Commentaires Un verbe pour décrire un C.U. Un cadre pour représenter le système Attention aux relations acteur-système Chaque C.U. doit se justifier Titrer et numéroter GTI515 Automne 2011 JF Couturier

Utilisation des relations Scénario alternatif ou Extend Include Généralisation (À éviter) Objectif: la clarté du document Ne pas oublier: le modèle des cas d’utilisation ne reflète pas l’architecture du système GTI515 Automne 2011 JF Couturier

Rappel Rappelez-vous que l’important est d’apprendre quelque chose de votre analyse. Passer des heures à discuter à propos d’un extend ou d’un include n’est pas franchement une activité constructive Le texte du cas d’utilisation est, lui, primordial! GTI515 Automne 2011 JF Couturier

Questions Quelle est la relation entre les acteurs et les rôles dans un diagramme de cas d’utilisation Un acteur représente un rôle, mais pas nécessairement une personne spécifique ou un système spécifique : rôle métier Une personne peut jouer plus qu’un rôle Où la relation « association » est-elle utilisée dans un diagramme de cas d’utilisation? Pour relier les acteurs avec les cas d’utilisation Pourquoi utiliser la dépendance stéréotype « Include »? Lorsqu’un cas d’utilisation délègue à un autre cas d’utilisation, une ligne en pointillé est utilisée. La délégation peut survenir pour 2 raisons: Un autre cas d’utilisation existe déjà et effectue la tâche désirée Plusieurs cas d’utilisation partagent la même tache. GTI515 Automne 2011 JF Couturier

Questions Quand utiliser la dépendance de stéréotype « extends » ? La dépendance stéréotypée « extends » dit qu’il peut y avoir une dépendance: la relation « include » dit qu’il y a toujours une dépendance La direction de la flèche va dans le sens contraire Où utiliser la relation de généralisation dans un diagramme de cas d’utilisation? Lorsqu’un acteur hérite des propriétés d’un autre acteur: la flèche pointe vers l’acteur qui est hérité. GTI515 Automne 2011 JF Couturier

Étude de cas Réaliser le diagramme des cas d’utilisations à partir de Le cas du garage Étapes Identifier les processus métier Faire le diagramme des CU GTI515 Automne 2011 JF Couturier

Le garage Combien de PMÉ? J’en ai identifié 6 Prendre rendez-vous Enregistrer demande de service Préparer bon de travail Exécuter travail Préparer facture Payer GTI515 Automne 2011 JF Couturier

Le garage Que remarquez-vous? Pourquoi exclure le client? Discutable… Il y a aussi de nouveaux acteurs… Nous sommes dans un cycle itératif et il est normal de trouver de nouvelles exigences en cours de route. C’est ce que l’on souhaite! GTI515 Automne 2011 JF Couturier

Plan du cours 4 Diagramme des cas d’utilisation Les cas d’utilisation Le SRS Les cas de test Prochain cours GTI515 Automne 2011 JF Couturier

Cas d’utilisation Le cas d’utilisation a trois sources principales: Le diagramme de cas d’utilisation Le narratif de cas d’utilisation Les scénarios de cas d’utilisation Les acteurs définissent des entités à l’extérieur du système qui vont interagir avec le système Les associations indiquent quels acteurs vont accéder à quelles fonctionnalités du système. Les dépendances décrivent la nature de la relation entre cas d’utilisation La généralisation est utilisée pour illustrer les relations d’héritage entre cas d’utilisation et entre acteurs. GTI515 Automne 2011 JF Couturier

Narratif du cas d’utilisation Le narratif du cas d’utilisation décrit, en terme de l’utilisateur, ce que les utilisateurs s’attendent des cas d’utilisation; les exigences. Le cas d’utilisation représente les fonctionnalités du système avec un début, un traitement et une fin; la description du processus. L’initiation du cas d’utilisation décrit comment commencer le cas d’utilisation GTI515 Automne 2011 JF Couturier

Lignes directrices (adapté de Effective Use Cases de A.Cockburn) Rendez le CU facile à lire Mettez en évidence chaque transaction élémentaire Faites des phrases courtes En général, une seule phrase par étape Limitez-vous aux relations ‘Include’, sous cette forme: Étape X. Le client consulte le catalogue des produits. Plus rarement aux relations ‘Extend’, via les points d’extension Évitez la forme passive Placez-vous au bon niveau (normalement au niveau ‘Système’) Évitez de décrire l’interface utilisateur Identifiez toutes les terminaisons possibles (succès ou échec) Pensez à satisfaire tous les intervenants, pas seulement l’acteur Définissez les préconditions (l’état du système au moment de l’événement déclencheur) Numérotez les étapes du scénario normal et des scénarios alternatifs Recommandé: illustrez tous les scénarios possibles par un diagramme.., cf plus loin N’oubliez pas que les CU sont juste une partie des exigences Pour identifier les extensions, pensez à toutes les conditions d’échec possible, et supposez que 1) la technologie est parfaite 2) les utilisateurs sont honnêtes Le diagramme des CU n’est: Qu’une table des matières Qu’un diagramme de contexte GTI515 Automne 2011 JF Couturier

Cas d’utilisation Élément du CU Titre et numéro (traçabilité) Acteur(s) primaire et secondaires Pré-conditions Scénario normal / nominal Scénario(s) alternatif(s) / erreurs Postcondition Point d’extension GTI515 Automne 2011 JF Couturier

Acteur principal Il s’agit de l’utilisateur qui débute et poursuit l’avancement du CU. Il amorce chaque étape des scénarios et le système réagit à ses actions. Un acteur principal peut être un autre système, externe au système à l’étude. Dans les cas où aucun utilisateur n’intervient, il est possible de désigner un acteur virtuel; il s’agit bien souvent d’un ‘timer’ qui est déclenché à intervalle régulier ou de capteurs externes. (Rare) GTI515 Automne 2011 JF Couturier

Acteur secondaire Un acteur secondaire ne déclenche pas un cas d’utilisation et ne contrôle pas l’avancement des étapes d’un cas d’utilisation, mais réagit aux actions d’un acteur principal ou sous l’action du système. Par exemple, un guichet a comme utilisateur principal le client et comme acteur secondaire, le système central de gestion des transactions GTI515 Automne 2011 JF Couturier

Pré/Post-Condition Pré-condition Postcondition Il s’agit de conditions nécessaires à l’amorce d’un cas d’utilisation Postcondition Il s’agit généralement des conditions en cas de succès du scénario nominal du CU. GTI515 Automne 2011 JF Couturier

Scénario principal Le scénario principal décrit une séquence d’actions, du déclencheur du cas d’utilisation jusqu’à la réalisation complète de l’objectif de l’acteur principal. On l’appelle, selon l’auteur, le scénario principal, nominal ou normal GTI515 Automne 2011 JF Couturier

Scénario alternatif Une ou plusieurs alternatives au scénario nominal Énoncé à part, pour garder le scénario principal le plus lisible possible. Un scénario alternatif peut avoir un point précis d’attache au scénario principal (une condition de déclenchement, à une unique étape d’un cas d’utilisation). GTI515 Automne 2011 JF Couturier

Cas d’utilisation Voir un exemple de gabarit GTI515 Automne 2011 JF Couturier

Les limites du modèle des CU Ne s’applique pas dans tous les cas, notamment s’il y a: Peu d’interfaces Beaucoup d’exigences non fonctionnelles GTI515 Automne 2011 JF Couturier

Les différents modèles de CU D’affaires (Business Use Case) Système (Essentiel) Niveau des nuages (résumé) Niveau de la mer Niveau sous l’eau (fonction) De conception (réel) GTI515 Automne 2011 JF Couturier

Quelques exemples de CU Voir des exemples de CU Le cas de la vente Le cas du garage Le cas de Air Québec GTI515 Automne 2011 JF Couturier

Commentaires sur les ch.1 et 2 Construire le modèle du domaine d’affaires avant celui des cas d’utilisation Identifier le glossaire / les concepts statiques L’identification des cas d’utilisation devrait précéder celle des acteurs Représentation intéressante des scénarios (Fig. 1.3) Recommandation: faire un diagramme de contexte (Fig. 1.4) Le diagramme de séquence système GTI515 Automne 2011 JF Couturier

Plusieurs formats possibles Texte (une colonne, deux colonnes,…) Diagramme d’activité Diagramme de séquence GTI515 Automne 2011 JF Couturier

Modélisation graphique des CU Diagramme d’activité ou diagramme de séquence (Voir Chapitre 1, étape 5 du livre) Recommandation: le diagramme d’activité Pourquoi? Automatisation – Transformation  MDA GTI515 Automne 2011 JF Couturier

Le cas d’utilisation sous forme de diagramme d’activité Correspondance des éléments Acteur – Partition (swimlane)‏ Pré et postconditions: notes reliées au point de début, point de fin Étape - Action Voir article GTI515 Automne 2011 JF Couturier

Représentation visuelle par les diagrammes d’activité On peut véhiculer autant (et même plus) d’informations sous la forme visuelle d’un diagramme d’activité que sous la forme textuelle traditionnelle Le diagramme des cas d’utilisation peut aussi être remplacé par un diagramme d’activité, qui représente le workflow du système Avec le diagramme d’activité, on peut: mettre plus d’informations générer les cas de tests utiliser un outil de modélisation utiliser les mécanismes de transformation de modèle à modèle Avoir plusieurs acteurs GTI515 Automne 2011 JF Couturier

Cas d’utilisation graphique GTI515 Automne 2011 JF Couturier

Utilisations des cas d’utilisation Participation du client Analyse du système Conception de l’interface utilisateur Cas de tests Documentation du système – Manuel? Identification des règles d’affaires Mesure de la taille fonctionnelle GTI515 Automne 2011 JF Couturier

Avec les CU Vous serez en mesure de rédiger des… Diagrammes de séquence Diagrammes d’analyse (Jacobson) Identification des interfaces (à venir) Identification des contrôleurs (à venir) Jeux d’essais Diagramme de flux de données (DFD) … GTI515 Automne 2011 JF Couturier

Que doit-on modéliser? La règle du boss La règle de la taille Modéliser l’identification d’un utilisateur? La règle de la taille Un cas d’utilisation avec une seule étape? Une dizaine d’étape c’est déjà plus intéressant… La règle du PMÉ GTI515 Automne 2011 JF Couturier

Sondage interne Qui utilise ou a déjà utilisé les cas d’utilisations? Si oui, vos impressions… Sinon, comment validez-vous le comportement du système avec le client/utilisateur? Prototype? Et lorsque vous n’en savez rien? GTI515 Automne 2011 JF Couturier

Étude de cas Reprendre le cas AirQuébec Reprendre le cas de réservation d’un billet et faites le cas d’utilisation en considérant qu’un système remplace désormais le préposé du service à la clientèle. GTI515 Automne 2011 JF Couturier

Étude de cas Vous voulez automatiser la prise de rendez-vous Faites le cas d’utilisation qui décrit les actions du responsable de service quand un client veut venir faire réparer sa voiture. Inspirez-vous du diagramme d’activité! GTI515 Automne 2011 JF Couturier

Plan du cours 4 Diagramme des cas d’utilisation Les cas d’utilisation Le SRS Les cas de test Prochain cours GTI515 Automne 2011 JF Couturier

SRS Document de spécification des exigences logicielles. Fait suite au document de vision Rappelez-vous de numéroter vos éléments  Traçabilité! GTI515 Automne 2011 JF Couturier

SRS Besoins Caractéristiques SRS Exigences logicielles Vision Document RMUC Instructor Notes SRS Vision Document Besoins Caractéristiques Supplementary Specifications Use-Case Model SRS SRS Package The SRS (Software Requirement Specification) is a package that contains specifications of software requirements. The specifications are written to a level of detail for handing off to the designers, testers, and user documentation writers. We assume that the requirements are “jointly” developed and agreed upon by the customer and the development team, rather than imposed (or externally specified) by the customer. It is important to adhere to some level of standards for consistency, for example, having standard document templates and standards for the database repository. The Requirements Management Plan is the place to record the standards and styles that will be used. Exigences logicielles Pierre Bourque, mgl-801, cours 7 GTI515 Automne 2011 JF Couturier Module 8 - Refine the System Definition

Exigences dans le SRS Il y a 2 grandes catégories d’exigences fonctionnelles Non fonctionnelles GTI515 Automne 2011 JF Couturier

Exigences fonctionnelles Ce que le système doit faire Ajouter un client Fermer la porte de l’ascenseur Facile de mesurer sa réalisation GTI515 Automne 2011 JF Couturier

Exigences non fonctionnelles Facilité d’utilisation Fiabilité  MTBF, MTTR Performance Facilité d’entretien Hum hum… Beaucoup moins claires Sources de confusion, de discorde avec le client, car difficile à mesurer ou à valider GTI515 Automne 2011 JF Couturier

Exigences non fonctionnelles Il existe des listes d’exigences beaucoup plus détaillées http://www.serc.nl/quint-book/ À utiliser au besoin. Utiles comme outils de réflexion sur les besoins du client. GTI515 Automne 2011 JF Couturier

SRS Voir le gabarit Voir exemples MTI réalisent un SRS en MGL-801 GTI feront un SRS à la fin de la session GTI515 Automne 2011 JF Couturier

Matrice de traçabilité Il peut être intéressant de faire le lien entre le document de vision et le SRS en créant une matrice de traçabilité. Lien avec les caractéristiques identifiées lors de la rédaction du document de vision Voir un exemple GTI515 Automne 2011 JF Couturier

Plan du cours 4 Diagramme des cas d’utilisation Les cas d’utilisation Le SRS Les cas de test Prochain cours GTI515 Automne 2011 JF Couturier

Les cas de test Les tests sont généralement abordés beaucoup plus tard dans le cycle de développement. Pourtant, il est déjà possible d’utiliser les diagrammes d’activité et les cas d’utilisation pour identifier les tests possibles. Penser aux différents scénarios d’un CU… GTI515 Automne 2011 JF Couturier

Les cas de test Étapes Identifier tous les scénarios Pour chaque scénario, identifier les cas de test Pour chaque cas de test, identifier les conditions qui vont créer son exécution Compléter le cas de test en entrant des valeurs pour ces conditions GTI515 Automne 2011 JF Couturier

Les cas de test Identifier tous les scénarios Créer une matrice et numéroter vos scénarios Pour chaque scénario, identifier les cas de test Créer une seconde matrice avec pour chaque scénario ses différents cas de test GTI515 Automne 2011 JF Couturier

Les cas de test Pour chaque cas de test, identifier les conditions qui vont créer son exécution Il doit y avoir une disponibilité La date doit être au format AA-MM-JJ La date doit être inférieure à la date du jour L’étudiant doit avoir un minimum de crédit pour suivre le cours GTI515 GTI515 Automne 2011 JF Couturier

Les cas de test Compléter le cas de test en entrant des valeurs pour ces conditions 3 valeurs possibles I pour invalide V pour valide N\A pour non applicable Saisir des données pour illustrer le cas. GTI515 Automne 2011 JF Couturier

Les cas de test Extraits d’une présentation de Rational GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

Les tests selon le modèle en V GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

GTI515 Automne 2011 JF Couturier

Ressources Livres Sur le web Pour le SRS et les exigences logicielles Use Case Modeling, Bittner « La bible » Larman UML2 par la pratique, chapitres 1 et 2 Managing Software Requirements, D. Leffingwell Sur le web Google Pour le SRS et les exigences logicielles MGL-801 GTI515 Automne 2011 JF Couturier

Plan du cours 4 Diagramme des cas d’utilisation Les cas d’utilisation Les cas de test Prochain cours GTI515 Automne 2011 JF Couturier

Prochain cours Quiz 2 1ere Évaluation du cours, soyez là! Modèle d’analyse Archétypes Modélisation en couleur Lecture Les lectures sont sur le site Web, cours 4 GTI515 Automne 2011 JF Couturier