GENIE LOGICIEL Détermination du périmètre cible d’une application Hervé DOMALAIN ENSEIRB – 2004 / 2005 Génie logiciel – ENSEIRB – 2004 / 2005

Diagrammes de CU et périmètre cible Le domaine cible d’une application est la couverture fonctionnelle de celle-ci. Le diagramme des cas d’utilisation UML est bien adapté pour évaluer la taille d’un domaine cible. En effet, la phase initiale de construction des cas d’utilisation avec UML consiste à définir l’ensemble des processus métier couverts par le futur système et les bénéficiaires de ces processus. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Les diagrammes de la version 1.5 Le diagramme de cas d’utilisation constitue un des neuf diagrammes définis par la norme UML V 1.5 : Vue utilisation – modèle d’usage Diagramme de cas d’utilisation Vue dynamique – modèle dynamique Diagramme de collaboration Diagramme de séquence Diagramme d’états – transitions Diagramme d’activités Mécanismes récurrents Stéréotypes – notes – contraintes – OCL – relations de dépendance – paquetages Vue statique – modèle objet Diagramme de classes Diagramme d’objets Diagramme de composants Diagramme de déploiement C’est l’OMG (Object Management Group) qui gère le projet UML. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Le passage de UML 1.5 à UML 2.0 Les sémantiques des modèles UML ont été grandement précisées, afin d'éviter tout problème d'interprétation (y compris pour le langage OCL) ; Enrichissement des diagrammes dynamiques pour permettre la construction formelle d’algorithmes ; 4 nouveaux diagrammes : Diagramme de modules permettant de représenter la hiérarchie des modules du projet, leur organisation et leurs interdépendances ; Diagramme de structure composite permettant de décrire la structure interne d'un objet complexe lors de son exécution ; Diagramme global d'interaction permettant de décrire une méthode complexe ; Diagramme de temps permettant de modéliser les contraintes d'interaction entre plusieurs objets, comme le changement d'état en réponse à un évènement extérieur. La version 2.0 qui a fait l’objet de nombreuses publications et qui a été implémentée dans de nombreux ateliers de génie logiciel par les éditeurs n’est pas pour autant publiée officiellement par l’OMG ! ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Problématique des cas d’utilisation Il faut spécifier les fonctionnalités du point de vue de l’utilisateur. Le système est considéré comme une boîte noire : Identifier le périmètre du système (ce qui existe dehors = les acteurs), S’intéresser aux comportements externes visibles (ce qui doit être effectué par le système = cas d’utilisation). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Définition d’un acteur Un acteur interagit avec le système : il a besoin d’échanger des informations avec le système. Il représente le rôle qu’un utilisateur peut jouer : chaque acteur possède sa manière d’utiliser le système. L’acteur au sens UML peut être humain, une entité informatique ou une entité matérielle. L’utilisateur est l’entité qui utilise réellement le système, tandis qu’un acteur représente un certain rôle que peut jouer un utilisateur. Pour identifier les acteurs, il faut éliminer les acteurs « physiques » au profit des acteurs « logiques ». Seules les entités externes qui interagissent directement avec le système (et pas par le biais d’autres acteurs) peuvent être répertoriées en tant qu’acteurs. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de périmètre (1/2) Ce diagramme, non spécifié dans la norme UML, présente le système comme une boîte noire et les acteurs qui interagissent avec lui. Exemple (application de gestion de stages) : Description du diagramme de périmètre ci-dessus : Une application de gestion de stages (la boîte noire) utilisée par plusieurs services, Une application de gestion du personnel considérée comme un acteur (système externe) car elle exploite les informations sur les inscriptions aux stages, Six acteurs (humains jouant des rôles différents) travaillant dans les services sus-mentionnés : Un acteur candidat (pour l’inscription aux stages), Un acteur gestionnaire de stages (publie les stages et gère les inscriptions), Un acteur administrateur de l’application qui hérite de l’acteur précédent (publie les stages, gère les inscriptions … et dispose de fonctionnalités particulières pour gérer l’application), Un acteur valideur abstrait (italique => le valideur n’existe pas en tant que tel dans l’application => le rôle correspondant constitue une partie des rôles réels joués par les deux acteurs suivants), Un acteur valideur hiérarchique (valide les demandes d’inscription des personnes sous sa responsabilité) qui hérite du rôle de valideur et l’enrichit, Un acteur valideur DRH (accepte les demandes d’inscription des candidats travaillant dans un des services) qui hérite du rôle de valideur et l’enrichit. L’acteur « administrateur application » est un acteur qui est rarement identifié par la maîtrise d’ouvrage mais qui est nécessaire dès lors que l’on doit gérer des données de référence dans une application (listes déroulantes de formulaires construites dynamiquement à partir de tables et proposées en sélection seule aux utilisateurs). Il est en quelque sorte le gestionnaire de l’application ou son webmestre ; il a un rôle fonctionnel et n’est en aucun cas un administrateur réseau ou serveur. En général, il peut accéder à tous les CU. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de périmètre (2/2) Autre exemple (plus raffiné) : ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Définition générale d’un cas d’utilisation Un cas d’utilisation représente un ensemble de séquences d’actions réalisées par un système et produisant un résultat intéressant un acteur particulier. Il spécifie les services que le système fournit à ses utilisateurs et les interactions acteurs-système (séquences d’interactions possibles entre un acteur initiateur et le système, pouvant faire intervenir d’autres acteurs). Il définit un comportement du système sans révéler sa structure interne. Le cas d’utilisation prépare la modélisation orientée objet en définissant textuellement les concepts du métier liés à l’utilisation du système. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Les différents niveaux de cas d’utilisation Un cas d'utilisation, comme tout diagramme UML, permet de décrire une réalité selon différents niveaux de raffinement : Niveau stratégique : Présente le contexte général, les grandes fonctions du système (approche métier), ses objectifs. Un cas d'utilisation de niveau stratégique implique plusieurs objectifs utilisateur et s'étale généralement sur plusieurs jours, semaines, mois ou années. Exemples : L'étudiant s'inscrit à une formation - L'étudiant s'inscrit à des modules - L'étudiant passe ses examens - L'étudiant obtient son diplôme Niveau fonctionnalité : C'est l'objectif directement suivi par un acteur en interaction avec le système. Il correspond au processus métier élémentaire en ingénierie des processus métier. Sa durée, de 2 à 20 minutes, peut être réduite si le déclencheur est un système. Exemples : S’inscrire à un module – Consulter un examen blanc - Calculer la note finale Niveau sous-fonctionnalité : Ce sont des cas d'utilisation qui participent au bon déroulement ou complètent des cas d'utilisation de niveau fonctionnalité. Exemples : S’identifier – Éditer un examen blanc ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Cas d’utilisation Vs processus métier Le cas d’utilisation est une abstraction fonctionnelle à 2 niveaux de raffinement : Lors de l’analyse préalable d’un système, il est appelé processus métier : Lors de l’analyse détaillée d’un système, on emploie la terminologie cas d’utilisation : ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

La relation de généralisation Le cas d’utilisation enfant est une spécialisation du cas d’utilisation parent. Exemple : ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

La relation d’inclusion Le cas d’utilisation source comprend le comportement du cas d’utilisation cible. L’inclusion est obligatoire. Elle permet de définir des comportements partageables entre plusieurs cas. Exemple : s’identifier est obligatoire avant de gérer les gestionnaires de stages via le système. On utilise la relation d’inclusion entre CU pour éviter de décrire plusieurs fois le même enchaînement de séquences d‘actions, en factorisant ce comportement comme dans un CU supplémentaire inclus. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

La relation d’extension Le cas d’utilisation source ajoute son comportement au cas d’utilisation cible. L’extension peut être soumise à condition. Elle permet de définir des variantes de comportement. Exemple : il est possible d’éditer un descriptif de stage après avoir recherché ce stage. On utilise la relation d’extension entre CU pour séparer le comportement exceptionnel ou rare d’un comportement obligatoire. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

La réalisation Exemple de réalisation d’un cas d’utilisation par un autre : quand un candidat établit une demande d’inscription via le système, celui-ci génère automatiquement un mail d’information. Cette relation peut également être utilisée pour la traçabilité des modèles, notamment pour associer un processus métier à des cas d’utilisation induits. Liaison uni-directionnelle ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Exemple de diagramme de processus métier ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Traçabilité entre les diagrammes de processus métier et de cas d’utilisation Ce diagramme permet d’identifier les correspondances entre les processus métier et les cas d’utilisation grâce à la réalisation « realize ». Dans cet exemple, le processus « gestion stages » est décliné en 5 cas d’utilisation distincts car le processus est jugé complexe. Par contre, le processus « gestion infos personnelles » ne correspond qu’à un seul cas d’utilisation. Le rôle de l’analyste est donc de décrire l’application dans des cas d’utilisation de tailles équivalentes (c’est-à-dire qui nécessiteront une charge de développement équivalente). Mais cela reste un exercice difficile ... Pour rester synthétique et éviter le piège de la granularité trop fine, il faut garder à l’esprit les chiffres suivants : . Le nombre de cas d’utilisation de base (en dehors des CU de niveau sous-fonctionnalité) doit être compris entre 10 (applications simples) et 40 (applications complexes), . Le nombre de processus métier doit être compris entre 5 (applications simples) et 10 (applications complexes). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme global Génie logiciel – ENSEIRB – 2004 / 2005 Gestion stages et inscriptions Inscriptions Stages Consultation stages Gestion candidatures Envoyer message info S'authentifier Editer infos stage Gestion stages Parametrage application Pour faciliter la lecture des modèles, il peut être nécessaire de construire plusieurs diagrammes de cas d’utilisation ... Comme les exemples des transparents 18 à 22. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de cas d’utilisation – ex. 1 (from Stages) Commentaires : Il est nécessaire de s’identifier pour chaque CU et il est possible d’éditer les infos sur un stage dans chaque CU. Le gestionnaire de stages peut accéder à tous les CU. Lorsqu’il modifie un stage, un message est construit par l’application et envoyé au candidat et au valideur DRH. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de cas d’utilisation – ex. 2 (from Stages) Commentaires : Tous les CU nécessitent une authentification préalable. L’administrateur de l’application peut gérer la nomenclature des stages, les gestionnaires de stages et les services. Il peut en outre gérer les formateurs comme le gestionnaire de stages. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de cas d’utilisation – ex. 3 (from Inscriptions) Commentaires : Seul l’établissement d’une demande d’inscription ne nécessite pas une authentification. Le candidat (le valideur et le gestionnaire de stages par héritage) peut établir une demande d’inscription, annuler sa demande et suivre le processus de validation (CU à partir duquel on peut éditer les informations relatives au candidat, voire consulter l’historique de ses inscriptions). Seul le valideur (et le gestionnaire de stages par héritage) peut valider ou invalider une demande d’inscription. Quand on établit une demande d’inscription, annule une demande d’inscription ou valide/invalide une demande d’inscription, l’application construit un message qui est envoyé au candidat, au gestionnaire de stages et au valideur pour information. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Diagramme de cas d’utilisation – ex. 4 (from Inscriptions) Commentaires : Un candidat peut rechercher un stage et le consulter. Lorsqu’il consulte le stage, il peut aussi l’éditer. Ces CU sont accessibles sans authentification. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Cas d’utilisation et scénarios Scénario nominal Scénarios secondaires Début normal du CU Fin normale Exception Enchaînements de séquences d’actions Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation. Un CU doit au minimum présenter 2 scénarios ou plus. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

Description textuelle d’un cas d’utilisation La description est un patron textuel : Titre Résumé Acteurs (initiateurs + autres) Description des enchaînements (textuelle en langage naturel informel – utiliser une forme active du point de vue de l’utilisateur) Pré-conditions Scénario nominal Scénarios alternatifs Scénarios d’exceptions Post-conditions Cas d’utilisation amont et/ou aval Besoins d’IHM Description des classes candidates Contraintes techniques (temps de réponse, fréquence, confidentialité, concurrence, disponibilité, intégrité, …) Cette description est donnée à titre d’information. Elle est nécessaire au stade de l’analyse (quand on détaille les besoins fonctionnels) mais non au stade de l’étude préalable (quand on définit le périmètre cible). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005

La transition vers les objets CU 3 CU 1 CU 2 Pour info ... Le liens entre les diagrammes de CU et les modèles statiques (diagrammes d’objet et de classe). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – ENSEIRB – 2004 / 2005