IFT 2251 Génie Logiciel Analyse: Principes & Concepts

Présentation au sujet: "IFT 2251 Génie Logiciel Analyse: Principes & Concepts"— Transcription de la présentation:

1 IFT 2251 Génie Logiciel Analyse: Principes & Concepts
Hiver Petko Valtchev

2 L’Analyse dans Contexte
Spécification du système Ingénierie système RESULTAT Document de spécification + plan de projet/qualité = CONTRAT Analyse du logiciel Conception du logiciel Plan de projet/qualité

3 Pour commencer… Une idée reçue très répandue:
On doit déterminer ce que le client veut « I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! » G. Romney, candidat à la présidence des É.-U., 1967 On doit déterminer ce dont le client a besoin

4 Motivation : éviter de produire un logiciel non adéquat.
Le Problème Logiciel Comprendre le problème (en termes de besoins) définition du problème status développement quo technique Analyse = Ingénierie des besoins intégration de la solution Motivation : éviter de produire un logiciel non adéquat.

5 Les Difficultés Le consommateur n’a qu’une idée vague de ce dont il a besoin. Le développeur est prêt à commencer à partir de cette «idée vague» assumant que les détails viendront… Le client change sans cesse d’idée… Le développeur tente maladroitement de faire ces changements… et introduit des erreurs dans la spécification et le développement…

6

7 Définition Mais qu’est-ce que c’est qu’un besoin?
« (1) A condition or capability needed by a user to solve a problem or achieve an objective (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents (3) A documented representation of such a condition or capability. » IEEE Standards Collection: Software Engineering

8 Types de Besoins Les principaux types de besoins sont:
Besoins très généraux : expriment en termes généraux ce que le système doit faire, Besoins fonctionnels : définissent des aspects du fonctionnement du système, Besoins d’implantation : indiquent comment le système doit être implanté, Besoins en performances : établissent des performances minimales pour que le système soit acceptable. Distinction importante: Besoins fonctionnels: QUE doit faire le système Besoins non-fonctionnels: DE QÉUELLE FAÇON doit le faire: Contraintes: temps, espace, performances, etc. Propriétés: maintenabilité, fiabilité, etc.

9 Le Processus L’ingénierie des besoins (IdB) ?
« The systematic process of developing requirements through an iterative cooperative process of analysing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained. » K. Pohl, 1993

10 Les Acteurs « Les acteurs d’un processus sont les individus impliqués
dans son exécution. Ils sont identifiés par leur rôles et non individuellement.  » L’ingénierie des besoins fait apparaître des acteurs qui sont intéressés par le problème à résoudre ou par sa solution: Clients, usagers, experts du domaine Ingénieurs en logiciel, Ingénieurs des besoins Chefs de projets

11 Ingénierie des besoins logiciel
Entrées et Sorties Documents d’analyse Infos sur le système existant Ingénierie des besoins logiciel Besoins agréés Demandes des participants Spécifications Standards Modèle du système Réglementations Connaissance du domaine

12 Les Activités Activité Objectif Acquisition des Besoins
Déterminer avec précision ce que le client désire et ce dont il a besoin. Analyse & Négociation S’assurer de la bien-fondée de chaque besoin exprimés par le client et comprendre les relations entre les différents besoins. Spécification Fournir une description tangible (précise et complète) des besoins. Modélisation Construire une représentation du système (maquettes, diagrammes). Validation Vérifier le document des besoins pour sa correction, complétude et cohérence. Maintenance Identifier, contrôler et tracer les besoins et leurs changements. Permet d’identifier quels aspects d’un système sont affectés par un changement des besoins initiaux. Mise à jour des besoins: - PROBLEMES: pbm de portée. Pbm de compréhension, pbm de volatilité (besoins changent…) PRODUIRE: (1) Un énoncé clair de faisabilité, (2) une définition de la portée du système ou du produit, (3) une liste des clients, des usagers et des personnes ayant participé à cette analyse. (4)une description de l’environnement technique, (5) une liste des besoins et exigeances, (6)un ensemble de scénarios d’utilisation, (7)prototypes… Analyse et negociations. Vérification de la cohérence et de la non-ambiguïté des besoins. Besoins essentiels?? Besoins conflictuels? Besoins peuvent être testé? Requirement specification

13 Le Modèle d’Après Pressman
Construction d’un prototype Expression et saisie des besoins Développement d’une spécification Le problème Révision Créer un modèle d’analyse

14 Un Modèle Approximatif
Analyse et négociation Acquisition Documentation Validation Infos sur le système existant, Souhaits des intéressés, Standards, Règlements, Connaissance du domaine Modèle du système Besoins agréés Spécifications du système

15 Un Modèle en Spirale Portée : tout le cycle de vie (modèle en spirale)
q u i r m n t s l c a o y d g v I f A D D e c i s i o n p o i n t : A c c e p t d o c u m e n t o r r e - e n t e r s p i r a l R e q u i r e m e n t s S T A R T d o c u m e n t a n d v a l i d a t i o n r e p o r t Portée : tout le cycle de vie (modèle en spirale) juste première étape (modèle en cascade, par prototypage) n t

16 Activités d’Acquisition
Comprendre le domaine d’application La connaissance du domaine est de la connaissance sur le secteur d’application pour le système. Comprendre le problème On doit comprendre le problème spécifique rencontré par les clients que le système doit résoudre. Comprendre l’activité d’affaires (le business) On doit comprendre la manière dont le système interagit et s’intègre dans l’activité globale de l’organisation. Comprendre les attentes et les contraintes des intéressés On doit comprendre, avec précision, les attentes spécifiques des personnes qui seront assistés par le système dans leur activité.

17 Techniques d’Acquisition
Techniques utilisées pour collecter des connaissance sur les besoins: Entrevues, Scénarios et Cas d’Utilisation (« Use Cases »), Réutilisation de besoins existants, Construction de prototypes, La connaissance doit être structurée selon les principes suivants: Partition - agréger les connaissances liées Abstraction – reconnaître les rapports de général-spécifique Projection – organiser selon une perspective Problèmes de l’acquisition Manque de temps Préparation insuffisante de la part des ingénieurs Les intéressés ne sont pas convaincus par la nécessité d’avoir un système

18 Cas d’Utilisation «  Cas d’utilisation: document narratif qui décrit la séquence d’intéractions dans laquelle un acteur utilise le système pour réaliser un processus. » Jacobson, 1992 Un acteur: un agent humain ou un système automatisé, externe au système, ensemble cohérent de rôles que l’usager joue lors de sa communication avec le système, associé à un ou plusieurs CdU. N.B. Un utilisateur concrèt du système peut jouer le rôle de plusieurs acteurs (vendeur, client)

19 Cas d’Utilisation (suite)
La technique des Cas d’utilisation: Identification des acteurs. ActeurA: emprunteur de journaux ActeurB: personne consultant le catalogue Usager: Paul ActeurC: emprunteur de livres 2) Pour chaque acteur, identification des cas d’utilisation. 3) Décrire en détail chacun des cas d’utilisation: Objectifs (fonctions, tâches, etc.) réalisées par l’acteur. Les données manipulées ou produites par l’acteur. Les changements d’état du système que l’acteur doit signaler ou ceux dont il dépend. Pondération: Pour chaque cas d’utilisation, on évalue l’importance de ce cas pour chaque acteur du système. On fait une moyenne. Permet d`identifier les cas prioritaires.

20 Cas d’Utilisation (exemple)
Prêt de documents Acteurs Lecteur, libraire Type Primaire Description Le lecteur se présente au comptoir avec sa carte. L’employé vérifie son identité. Il enregistre les documents empruntés et établi leurs dates de retour. Forme textuelle le lecteur arrive et l’employé prend sa carte l’employé choisit dans le menu principal la fonction prêt il lit le code du lecteur avec le crayon optique ou il l’entre au clavier si le lecteur est connu du système, ses données personnelles et ses droits d empreints sont alors affichés l’employé entre ensuite pour chaque document à prêter le code du document, le système lui affiche la date de retour en fonction du type de document, ensuite le document est marqué « en prêt » Rôles correspondent aux différent mode du système: Mode programmation, mode test, mode monitoring, mode expert (troubleshooting)

21 Technique FAST Technique: Facilitated Application Specification Technique (FAST) Groupe de génie logiciel Groupe client Approche orientée « équipe » pour mettre en lumière les besoins logiciels. Les équipes: - Travaille ensemble pour identifier le problème clairement - Proposer des pistes de solutions - Négocier différentes approches - Spécifier les besoins, exigences et contraintes de la solution logicielle

22 Technique FAST (suite)
Règle de participation établies: Tous les participants doivent assister aux réunions. Tous les participants ont un droit de parole égal. Un modérateur est nommé pour mener la réunion. On préfèrera un lieu de rencontre neutre. Un agenda des activités et réunions est élaboré. Un médium de définition est choisi pour prendre notes des travaux de la réunion. Le travail de préparation est aussi important que la réunion elle-même. Tous les documents élaborés avant la réunion sont considérés comme des propositions. On essaie d’éviter de se perdre dans les détails techniques.

23 Technique FAST (fin) - 1re étape: Première réunion.
Initiation du processus (choix d’un modérateur, agenda des réunions, etc.) Définition de la demande de logiciel (2 pages). - 2e étape: Chacun étudie la demande de logiciel. Il dresse la liste des objets, services, contraintes (prix, règles, etc.) et critères de performance. - 3e étape: Acceptation unanime de la pertinence de la demande. Présentation des listes par thème (objets, services, etc.) Discussion. Élaboration d’une liste consensus pour chaque thème. - 4e étape: Chacun élabore une mini-spécification (informelle) pour chacun des éléments des listes « consensus ». Discussion. - 5e étape: Chacun élabore une liste de critères de validation. Discussion. Une liste consensus est définie pour ces critères. - 6e étape: Rédaction d’une première version de la spécification du logiciel.

24 Principes d’analyse Le domaine des données doit être décrit et bien compris. Les fonctions du logiciel doivent être définies. Le comportement du logiciel, c’est-à-dire la réaction du logiciel aux divers événements qui peuvent survenir, doit être décrit. Les modèles utilisés pour représenter les données, les fonctions et le comportement du logiciel doivent être partitionnés de façon à présenter l’information sous forme hiérarchique. Le processus d’analyse devrait se faire par raffinements successifs, en présentant graduellement l’information depuis ses fondements jusqu’aux détails d’implantation.

25 Analyse: Les Bonnes Pratiques
S’assurer d’avoir compris le problème avant de créer le modèle d’analyse. Développer des prototypes qui permettent au client de comprendre les interactions avec le logiciel. Prendre note des raisons motivant chacun des besoins et contraintes. Utiliser différentes vues pour représenter les besoins: vue des données, vue fonctionnelle, vue comportementale. Ordonner les besoins et les fonctionnalités à réaliser selon leur importance. S’efforcer d’éliminer systématiquement les ambiguïtés.

26 Modélisation Caractéristiques désirées d’un modèle:
Abstraction : Permet de cacher les détails moins pertinents pour une meilleure compréhension de l’essentiel. Expressivité: Permet d’exprimer avec nuance les informations. Rigueur: Sémantique précise, absence d’ambiguïté. Structuration: Offre des mécanismes flexibles pour structurer et hiérarchiser l’information. Automatisation: Offre des possibilité de simulation, de vérification automatique ou de traduction dans un langage de programmation exécutable.

27 Modélisation des Données
Domaine des données traitées Quelles sont les données utilisées, transformées ou produites? images événement -clic de souris -signal -etc. texte vidéo sons Modèle des données: Description de leur contenu Quels sont les objets, leurs attributs, leurs relations avec les autres données, etc. (2) Description de leur flux dans le système Comment les données circulent dans le système? (3) Description de leur structure interne Comment l’information est-elle organisée à l’intérieur de chaque donnée? Arbre, tableau, etc. Nous verrons différents types de modèle pour représenter les données (contenu, flux, structure).

28 Modélisation des Fonctions
Données en entrée traitement Données en sortie Quelles sont les différentes fonctions du système? Fonction: transforme l’information. Description des fonctions, du flux des données et des producteurs/consommateurs

29 Modélisation du Comportement
Un programme est toujours dans un état (en attente, en calcul, en train d’émettre ou d’interroger…) Le changement d’état est toujours dû à l’occurrence d’un événement: Type d’événement: (1) tic de l’horloge interne, (2) événement externe (e.g. clic de souris), (3) signal système externe (signal d’erreur émis par l’environnement). Événement Z Comment le logiciel se comporte-t-il? État X État Y

30 Modélisation Quelle utilité?
Facilite et structure la compréhension et l’analyse des données traitées, des fonctions et des comportements du logiciel. Constitue l’outil clef de référence pour la vérification de la complétude, la cohérence et l’exactitude de la spécification du logiciel. Constitue la base pour la conception du logiciel. Cette représentation abstraite du logiciel pourra être projetée dans le contexte d’implémentation.

31 Décomposition fonctionnelle du domaine
Partitionnement Afin de bien comprendre un problème, il est utile de pouvoir le décomposer. Décomposer le domaine du logiciel en ses parties constituantes. Décomposer en groupes et raffiner chaque modèle pour représenter différents niveaux d’abstraction: - raffiner la description des données - créer une hiérarchie fonctionnelle - représenter le comportement du logiciel à des niveaux de détail différents. Augmentation du niveau de détail Décomposition fonctionnelle du domaine

32 Partitionnement (Exemple)
Système d’alarme Système de configuration Contrôle des capteurs Interactions avec l’usager Activer les fonctions d’alarme Sonder les capteurs Pour des événements Lire l’état du capteur Identifier le type d’événement Activer/ désactiver le capteur Activer l’alarme sonore Composer no. tél.

33 De l’Essentiel à l’Implémentation
Vue « essentielle » du problème: Représentation des données, des fonctions, des comportement sans égard à leurs détails d’implémentation. Vue d’« implémentation » du problème: Représentation tenant compte de la façon dont seront concrètement réalisées les fonctions, les données et les comportements.

34 Spécification du Logiciel
Le processus d’analyse doit se conclure par la production d’un dossier d’analyse appelé: Document de spécification du logiciel (parfois appelé cahier des charges du projet) Document de spécification du logiciel + plan de projet/qualité = CONTRAT avec le client

35 Spécifications du Logiciel
Contenu du document de spécification Introduction: Buts, objectifs généraux, contexte informatique, etc. Description des données (contenu, flux, structure) Description fonctionnelle (description de chacune des fonctions du logiciel, des contraintes de conception, critères de performance) Description comportementale (description des changements d’état du système selon les événements) Critères de validation. (définition des tests de validation, déterminer comment on peut vérifier que le système répond bien aux attentes) Bibliographie et annexes. Bibliographie: documents de référence Annexe: algorithmes, diagrammes, graphes, etc.

36 Spécification: Bonnes Pratiques
Le format de la spécification (notation, symboles, diagrammes, etc.) devrait être adapté au problème. L’information décrite dans la spécification devrait être hiérarchisée et présentée selon différents niveaux d’abstraction. Les diagrammes et autres notations devraient être utilisée de façon pertinente et cohérente (limiter le nombre de notations…) La spécification devrait être facilement révisée (outils CASE pour repérer les dépendances, etc.)

37 Techniques de Spécification
Quelques grands types de techniques, souvent utilisés conjointement: Énoncés informels = Descriptions en langage naturel pouvant respecter des plans types (standardisés ou propres à une entreprise ou à un projet). Présentations formatées: Dictionnaires de données ou glossaires, Tables de décision, Tables états-transitions. Techniques graphiques ou semi-formelles: Diagrammes d’entité-association, de flot de données et de transitions d’état, Diagrammes OO: classes, objets, interaction, contexte, etc. Méthodes formelles: Méthodes centrées-données: B, Z, VDM; Méthodes centrées-processus: CTL, Lotos;

38 Examen des Spécification
Niveau macroscopique Considérant la spécification du domaine des données, des fonctions et des comportements, la spécification est-elle complète, cohérente et exacte? Niveau microscopique Pour chaque domaine, examiner en détail la spécification pour éliminer toute erreur, tout terme vague ou contradictoire…

39 Un Modèle Approximatif
«  Ensemble des spécifications, des besoins et des objectifs relatifs à un projet.  » Office de la langue française, 2000 Le cahier des charges : utilisé pour communiquer les besoins entre clients, ingénieurs et managers. Il décrit: Les services et les fonctions que le système doit fournir, Les contraintes sous lesquelles le système doit opérer, Les propriétés globales du système, Définitions d’autres systèmes avec lesquels le système décrit doit coopérer.