«SEG 3501»

D. Amyot uOttawa

SEG 3601- Module 3

Analyse, modélisation et spécification des exigences

(introduction)Basé en partie sur du matériel de

K.E. Wiegers, D. Leffingwell & D. Widrig, P. Heymans, M. Jackson, I.K.

Bray, D. Berry, J. Atlee, B. Selic, G.

Mussbacher

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 2

Analyse des exigences

• Le processus qui consiste à étudier et à analyser les besoins des parties prenantes pour en arriver à une définition des du domaine du problème et des exigences du système (ou logicielles)

• L’analyse va souvent de pair avec la modélisation

«SEG 3501»

D. Amyot uOttawa

Objectifs de l’analyse

• Découvrir les frontières du système/logiciel et comment il doit interagir avec son environnement

• Détecter et résoudre les conflits entre exigences (des utilisateurs)

• Négocier les priorités des intervenants• Élaborer les exigences du système pour en dériver les exigences logicielles utiles pour les gestionnaires (estimés réalistes) et les développeurs (implémentation et test)

• Classifier les exigences• Évaluer les exigences par rapport aux qualités désirables

• S’assurer que rien n’est oublié

Module 3 : Analyse et spécification des exigences 3

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 4

Analyse des exigences

Élicitation

Analyse

Notes d’élicitation

Questions et pointsà considérer

Documents d’exigences

«SEG 3501»

D. Amyot uOttawa

Modélisation des exigences

• Aussi une tâche essentielle de la spécification des exigences― Mène à une forme plus précise des éléments recueillis lors de

l’élicitation― Aide à mieux comprendre le problème― Aide à trouver ce qui reste à discuter

• Différents langages de modélisation― Informels (langage naturel)― Orientés-buts (GRL)― Modélisation fonctionnelle

– UML (Unified Modeling Notation)– SDL (Specification and Description Language)– Logique (Z, CTL et autres logiques temporelles…)– UCM (Use Case Map)– …

Module 3 : Analyse et spécification des exigences 5

«SEG 3501»

D. Amyot uOttawa

Validation et vérification des exigences

•Doivent être faites à toutes les étapes du processus d’ingénierie des exigences― Élicitation

– Vérifier auprès des sources d’élicitation– « Donc, vous dites que… ? »

― Analyse– Vérifier que la description du domaine et que celle

des exigences sont correctes― Spécification

– Vérifier que les exigences définies pour le système vont satisfaire les exigences des intervenant lorsque les hypothèses sur le domaine et l’environnement sont vraies

– Vérifier que les exigences et les documents soient bien formés (règles, gabarits…)

Module 3 : Analyse et spécification des exigences 6

«SEG 3501»

D. Amyot uOttawa

L’utilisation des modèles

Module 3 : Analyse et spécification des exigences 7

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 8

•Selon Bran Selic, un modèle est une représentation réduite (simplifiée, abstraite) d'un (aspect d'un) système qui sert à:―aider à comprendre un problème et/ou

une solution complexe(s)―communiquer des informations sur le

problème/la solution―diriger l'implémentation

•Qualités d’un bon modèle―Abstrait, compréhensible, précis, prédictif,

peu coûteux…

Modèles

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 9

Représentations de modèles• Langue naturelle (français)

+ Pas d’apprentissage spécial nécessaire- Ambigüe, verbeuse, imprécise, obscure…- Pas d’automatisation

• Notation ad hoc (bubbles and arrows)+ Pas d’apprentissage spécial nécessaire- Pas de syntaxe formellement définie, ambigüe - Pas d’automatisation

• Notation semi-formelles (URN, UML…)+ Syntaxe (graphique) bien définie+ Interprétation commune partielle, raisonnablement simple

à apprendre+ Automatisation partielle- Sémantique incomplète, toujours un risque d’ambigüités

• Notation formelle (SDL, Réseaux de Pétri, LOTOS, …)+ Syntaxe et sémantique bien définies+ Grande automatisation (analyse et transformations)- Difficile à apprendre et à comprendre

«SEG 3501»

D. Amyot uOttawa

•Les langages informels sont mieux compris par un vaste éventail d’intervenants― Bons pour les exigences utilisateurs, les contrats― Mais: manque de précision― Possibilité d’ambigüités― Manque d’outils d’analyse

•Les langages formels sont plus précis― Moins de problèmes d’ambigüités― Outils (p.ex., vérification et transformations)― Pour les spécialistes (développeurs, testeurs…)― Mais à portée limitée

Représentations de modèles (2)

Module 3 : Analyse et spécification des exigences 10

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 11

Modélisation de la structure

•Concepts d’entités et de relations. Utilisez l’une des notations suivantes:― Diagrammes entités-relations (ERD)― Diagrammes de classe UML

•Peuvent être utilisés pour modéliser:― le domaine du problème (aussi appelé le

« modèle du domaine »)– Même les systèmes présents et futurs

― Les structures de données― Les données emmagasinées (bases de

données)― La conception architecturales du système futur

«SEG 3501»

D. Amyot uOttawa

Modélisation des entrées et sorties

•Nature des entrées et sorties (E/S):― E/S reliées au problème (données du problème)― Données additionnelles reliées à la solution

– P.ex., options des utilisateurs, messages d’erreurs…

•Regroupées dans un dictionnaire de données― Texte simple (langage naturel)― EBNF― Pseudo-code― Logique (p.ex., Z, CTL…)― …

•Sorties graphiques (écrans, formulaires)― Dessins iconiques, écrans/formulaires prototypes,

affichages produits par prototype opérationnel…

Module 3 : Analyse et spécification des exigences 12

«SEG 3501»

D. Amyot uOttawa

Modélisation du comportement dynamique

• Représentations― Texte (simple, description des fonctions, cas d’utilisation)― Tables de décision ― Diagrammes d’activités UML / Use Case Maps― Machines à états finis

– Machines à états simples (FSM) : diagrammes d’états ou tableau de transitions

– Machines à états étendus (EFSM): diagrammes d’états UML, SDL

– State Charts de Harel (intégrés dans UML)– Réseaux de Pétri

― Logique (p.ex. Z, B, CTL) , pour décrire des assertions due les entrées et sorties, et possiblement sur les états internes des objets modifiés par les opérations

• Il est important de choisir ce qui est le plus approprié pour le système― Pas de « one size fits all »!

Module 3 : Analyse et spécification des exigences 13

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 14

Analyse de modèles

• Par construction― On apprend le système en s’interrogeant et en le

décrivant• Par inspection

― Exécution mentale― Fiable?

• Par analyse formelle― Nécessite une sémantique formelle (mathématique)― Fiable (en théorie), mais coûteux pour certaines

approches et certains problèmes• Par expérimentation

― Exécution, simulation, animation, test…― Requiert une sémantique définie er des outils de

simulation― Plus fiable que l'inspection pour certains aspects― Contact "direct", possible d’interagir (prototype)

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 15

Analyse: Quelques approches typiques

•Analyse structurée (1970)•Analyse orientée-objet (1990)•Cadres de problèmes (Problem Frames, 1995)

•Analyse basée sur les machines à états•Analyse de conflits

― Avec cas de mésusage― Avec modèles GRL/UCM (en laboratoire)

• Il est important de distinguer:― La notation utiliser pour définir le modèle― Le processus par lequel le modèle est créé

«SEG 3501»

D. Amyot uOttawa

Module 3 : Analyse et spécification des exigences 16

Tous les modèles sont faux, mais quelques modèles sont

utiles...

George Edward Pelham Box (1919-)