GEF499 - Concep.on de systèmes intégrés en temps-réel. Méthodologie de développement des exigences

Transcription

1 GEF499 - Concep.on de systèmes intégrés en temps-réel Méthodologie de développement des exigences

2 Plan Ingénierie des exigences Implica7ons Raisons Résultat Par7es prenantes Processus Spécifica7ons Méthodes de développement et communica7on Ges7on des exigences Valida7on

3 Ingénierie des exigences L ingénierie des exigences est le processus où l on «détermine les objec7fs, fonc7onnalités et contraintes des systèmes logiciels dans le domaine du problème ainsi que la représenta.on de ces aspects dans un format qui peut être modélisé et analysé.» 1

4 Ingénierie des exigences Pourquoi doit-on se soucier de l ingénierie des exigences? Comment sait-on quoi construire? Comment sait-on qu on a terminé?

5 Ingénierie des exigences

6 Ingénierie des exigences Le résultat du processus de développement des exigences est un document de spécifica7on des exigences du logiciel (So#ware Requirement Specifica3on SRS) Le but est d avoir un document qui est: Complet Balancé Non-ambigüe Correcte Compréhensible Représenta7f des contraintes temporelles et de performances

7 Ingénierie des exigences Qui est impliqué? Représentants des organisa7ons de développement (développeurs, testeurs, ges7onnaires, etc.) Groupe appropriés de représentants du client Exemple Dans un projet de logiciel aéronau7que, les représentant du client peuvent inclure les ingénieurs de maintenance et les pilotes.

8 Processus Il existe plusieurs processus de développement des exigences Étude préliminaire Découverte des exigences Défini7on des exigences Valida7on des exigences Rapport de faisabilité Modèle du domaine Défini7on des exigences Spécifica7ons des exigences

9 Processus Il existe plusieurs processus de développement des exigences Modèle du domaine Défini7on des exigences Spécifica7on des exigences Document des exigences

10 Communiquer les spécifica7ons Même pour de pe7ts projets, le nombres d exigences peut être assez grand Nous pouvons les organiser par type Il y a tradi7onnellement 2 types d exigences: Fonc7onnelles, et Non-fonc7onnelles.

11 Communiquer les spécifica7ons IEEE Std Pra7ques recommandées pour la spécifica7on des exigences logicielles définit 6 classes d exigences: 1. Fonc7onnelle 2. Interface externe 3. Performance 4. Base de données logique 5. Contraintes de design 6. Afribut du système logiciel

12 Communiquer les spécifica7ons Nous pouvons représenter les exigences de plusieurs façons qui ont toutes des avantages et désavantages: 1. Méthode formelle 2. Machine à états finie (FSM) 3. Diagramme d état 4. Réseau de Petri 5. Analyse structurée et design structuré (SA/SD) 6. Analyse orienté-objet et UML

13 Nota7on logique U7lise un langage formel pour décrire les exigences. R1. Si l interrup7on A survient, la tâche B arrête alors son exécu7on. R2. La tâche A commence son exécu3on lorsque l interrup3on A survient. R3. Soit la tâche A exécute et la tâche B n exécute pas ou la tâche B exécute et la tâche A n exécute pas ou les deux n exécutent pas p q p r ( r q) ( q r) ( q r) p: L interrup7on A survient q: La tâche B exécute r: La tâche A exécute

14 Nota7on logique Avantages Peut prouver qu une exigence est correcte Non ambigüe Désavantages Difficile à écrire N est pas approprié pour toutes les exigences

15 Machine à états finie E2/O2 M = {S, i, T, Σ, δ, Γ} E1/O1 S1 E2/O2 S2 E1/O1 E2/O2 S = {S1, S2, S3} i = S1 T = Σ = {E1, E2, E3} δ est représenté dans le diagramme Γ = {O1, O2, O3} E3/O3 E3/O3 E1/O1 S3 E1 E2 E3 S1 S1/O1 S2/O2 S3/O3 S2 S1/O1 S2/O2 S3/O3 E3/O3 S3 S1/O1 S2/O2 S3/O3 Source: Laplante 2012

16 Machine à états finie Avantages Il est possible de les op7miser avec des techniques mathéma7ques rigoureuses Désavantages Les aspects internes ne peuvent pas être représentés Difficile de représenter les communica7ons intertâche Le nombre d état peut devenir très nombreux (devient alors difficile à lire)

17 Diagramme d état (statechart) Afin de corriger certains problèmes des FSM pour pouvoir représenter les spécifica7ons de systèmes en temps-réel Naviga7on Tâche d arrière-plan Interrup7on 5 ms 5 ms 40 ms Lecture et compensa7on des pulses bruts de l accéléromètre Interrup7on 40 ms Lecture et compensa7on des données de gyro Compensa7on de toutes les données 1 s Mise à jour de l affichage Interrup7on 1 s Source: Laplante 2012

18 Diagramme d état (statechart) Avantages Rend facile la représenta7on de tâches concurrentes Modulaire Permet la représenta7on facile des communica7ons inter-tâche (broadcast comms) Possible de s en servir pour générer du code Désavantages Tout comme pour les FSM, peut être difficile à lire s il y a trop d états (diviser-les) Le problème du puit de pétrole

19 Réseaux de Petri P 1 P 4 marquage: indique un état du réseau après une série d événements P 3 m 0 P 2 P 5 Emplacement: représente des contenants de donnés ou des condi7ons Transi.on: représente un événement qui fait passer d un emplacement à un autre

20 Réseaux de Petri P 1 P 3 P 4 m 0 P 2 P 5 P 1 P 3 P 4 m 1 P 1 P 2 P 3 P 4 P 5 m m P 2 P 5 m P 1 P 3 P 4 m 2 P 2 P 5 Source: Laplante 2012

21 Réseaux de Petri Avantages Excellent pour représenter des systèmes distribués ou piloté par les événements Il existe des techniques rigoureuses pour les op7miser et faire des preuves Possible de s en servir pour générer du code Désavantages Peuvent être difficile à lire s il y a trop d emplacements et de transi7ons

22 Analyse structurée et design structuré Vieille technique (SA/SD) Très populaire dans les STR car associée avec les langages procéduraux U7lisée pour décrire le: contexte du système processus contenu (les données)

23 Analyse structurée et design structuré (SA/SD) Yourdon iden7fit trois points de vue (modèle) pour décrire les STR: Modèle environmental Diagramme de contexte, liste d événements, etc. Modèle comportemental Diagramme de flot de données, diagramme de flot de contrôle, diagramme en7té-rela7on, spécifica7ons de processus, spécifica7ons de contrôle, diagramme de transi7on d état, dic7onnaire de données, etc. Modèle d implémenta7on Graphe de structure, pseudo-code, logique temporelle, etc.

24 Analyse structurée et design structuré (SA/SD) Unité de contrôle du mouvement Statut du mouvement Statut de l ascenssur Ground Dispatcher Commandes de départ/arrêt Commandes de la porte Système de contrôle de l ascenseur Appels assignés Informa7on spécifique à la course Opérateur de la porte Statut de la porte Appels du chariot et statut opéra7onnel Panneau d opéra7on du chariot Source: Laplante 2012 Exemple de diagramme de contexte

25 Analyse structurée et design structuré Avantages (SA/SD) Plusieurs ou7ls d ingénierie matures pour SA/SD Bonne correspondance avec les langages procéduraux Désavantages Peu de sou7ent à la concurrence Peut amener l implémenta7on de processus supplémentaites

26 Analyse orienté-objet et UML Opéra7on analy7que u7lisant les diagrammes UML Débute normalement avec la représenta7on des fonc7onnalités externes en tant que cas d usage Plusieurs diagrammes différents: Structurel: diagramme de classe, d objet, de paquets, de déploiement, etc. Comportemental: diagramme d ac7vité, de machine d état, de cas d usage, de communica7on, de séquence, etc.

27 Analyse orienté-objet et UML Avantages Il est possible de prendre en compte la distribu7on et la concurrence Ges7on efficace de la complexité Améliore la réu7lisa7on Désavantages Les concepts OO peuvent amener des systèmes imprévisible (collecte d ordures) et inefficace Difficile à op7miser

28 Les spécifica7ons décrivent quoi faire et pas comment le faire

29 Spécifica7on des exigences logicielles (SRS) Le SRS est comme un contrat (souvent u7lisé à cefe fin) entre les par7es prenantes. Modèle du domaine Défini7on des exigences Spécifica7on des exigences Document des exigences

30 Structura7on du SRS Il existe de nombreuses structures, mais IEEE Std est un bon gabarit 1. Introduc7on 1. But 2. Étendue 3. Défini7ons and Acronymes 4. Références 5. Vue d ensemble 2. Descrip7on de l ensemble 1. Perspec7ve du produit 2. Fonc7ons du produit 3. Caractéris7ques de l u7lisateur 4. Contraintes 5. Supposi7on and Dépendances 3. Exigences spécifiques Appendices Index

31 Exigences De bonnes exigences devraient être: Correctes Sans ambiguïtés Complètes Consistantes Ordonnées par importance et/ou stabilité Vérifiable

32 Exigences Mal rédigé : 1. Le système devrait être fiable 2. Le système devrait être rapide 3. Le système devrait être précis Bien rédigé : 1. Le MTBF doit être au moins 500 heures de fonc7onnement con7nu 2. Le temps de réponse pour toutes les opéra7ons de premier niveau doit être 250 ± 50 ms. 3. L erreur d amplitude dans les valeurs es7més doit être moins que 3.5%.

33 Ges7on des exigences Le volume des exigences peut être écrasant Doivent donc être organisées N est pas un problème simple Bases de données et hyperliens aident jusqu à un certain point Un ou7l automa7sé est généralement nécessaire pour faire le suivi des spécifica7ons et leur sa7sfac7on

34 Source: eccam.com Ges7on des exigences

35 Ges7on des exigences Base de référence (baseline): Les spécifica7ons doivent avoir une base de référence: à tout moment, les développeurs doivent savoir quelle spécifica7ons ils u7lisent Les changements de spécifica7on devraient nécessités une approba7on formelle, normalement par un conseil de contrôle de la configura7on Un système de ges7on des changements est essen7el

36 Ges7on des exigences

37 Valida7on Comment l analyste l a conçu Comment le programmeur l a écrit

38 Valida7on Comment l analyste l a conçu Comment le programmeur l a écrit La ques7on que la valida7on pose est: A-t-on construit le bon système Ce que le client voulait vraiment

39 Valida7on Quelques techniques Vérifica7on automa7sée de la consistance Prototypage Révision (walkthrough) Généra7on de cas de test U7lisa7on de modèles exécutables (ex.: RoseRT)

40 Références [1] Laplante, P. A. and Ovaska, S. J. Real-Time Systems Design and Analysis, 4 th Edi7on. Wiley, 2012.