La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

2003, revisé 2006, 07 et 08SEG2501 - Chapitre 21 Chapître 2 Principes de base concernant les exigences.

Présentations similaires


Présentation au sujet: "2003, revisé 2006, 07 et 08SEG2501 - Chapitre 21 Chapître 2 Principes de base concernant les exigences."— Transcription de la présentation:

1 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 21 Chapître 2 Principes de base concernant les exigences

2 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 22 Les sections: Introduction au système exemple Nature d’un système Techniques pour gérer la complexité Approches à la description de comportements Quelques approches de description La méthodologie présentée dans ce livre La notation SOON

3 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 23 2.1: Introduction au système exemple Le système de contrôle d’accès (Access Control System (AC-System)) Un point d’accès (Access point) La station locale (Local station) La station centrale (Central station)

4 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 24 Le panneau et la carte

5 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 25 La structure du système

6 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 26 2.2: La nature d’un système C’est quoi, un système ? Comportement Structure Système temps-réel

7 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 27 C’est quoi, un système ? Un système est une partie du monde réel qu’une personne ou un groupe de personnes considèrent, pendant un certain temps et pour un but particulier, comme un tout; il consiste de composantes interreliées, chaque composante étant caractérisée par des propriétés qui ont été sélectionnées parce qu’elles sont pertinentes pour le but considéré.

8 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 28 Système hiérarchique

9 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 29 Un système d’alarme simple

10 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 210 La description du système Il y a deux buts: –Décrire le comportement fonctionnel pour qu’il soit complètement compris –Décrire la réalisation pour que le système puisse être produit Système vs description du système

11 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 211 Système et description du système

12 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 212 Comportement Le comportement d’un système est le développement des états et des transitions entre états générés par les actions du système pendant le laps de temps pour lequel il est étudié Comportement est un développement dynamique à travers le temps

13 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 213 Un segment de comportement

14 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 214 Structure La structure d’un système est l’aspect du système qui reste invariant (fixe) pendant l’intervalle de temps sur laquelle le système est étudié La structure d’un système est la disposition, l’arrangement des parties du système

15 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 215 Systèmes temps-réels Un système est un système temps-réel si un de ses rôles d’usager a des contraintes de temps

16 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 216 Exemple: système de contrôle (real-time) Pipe Flow meter Valve Interface Computer Time Input flow reading Processing Output valve angle

17 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 217 Un four de séchage de grain (real-time) Fuel Tank Furnace Bin Pipe fuel grain

18 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 218 Un système de contrôle de processus (real-time) Process Control Computer Chemicals and Materials Valve Temperature Transducer Stirrer Finished Products PLANT

19 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 219 2.3: Techniques pour gérer la complexité Abstraction –Projection –Composition (agréger) et décomposition –Généralisation et spécialisation

20 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 220 Abstraction Ignorer certains aspects d’un phénomène pour décrire (et comprendre) plus clairement d’autres aspects. Le contraire de concret ou physique L’abstraction devrait être claire et précise, offrir une implantation efficace et supporter l’évolution et la réutilisation

21 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 221 Projection Lors d’une projection, nous regardons le système d’un certain angle Une projection est une description d’un système comme il est aperçu par un sous- ensemble de ses interfaces –Seulement les interfaces visibles sont observables, les autres sont cachés

22 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 222 Agrégation et décomposition (1) Tous les systèmes non triviaux sont composés de composants Le processus de combiner des composants pour en faire un tout est appelé agrégation Le processus opposé est appelé décomposition

23 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 223 Agrégation et décomposition (2)

24 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 224 Généralisation et spécialisation Dans le monde réel, il y a un grand nombre d’objets similaires Au lieu de décrire et comprendre tous les objets individuels en détails, nous pourrions les décrire et les comprendre par leurs traits similaires Un type est une entité conceptuelle qui nous sert à structurer nos descriptions et pensées Un objet individuel est une instance d’un type Un sous-type d’un type définit des traits supplémentaires qui seront satisfaits par toutes ses instances

25 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 225 Hiérarchie de spécialisation / généralisation

26 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 226 Décomposition d’un type (une composante, nommé Ls, a une structure particulière)

27 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 227 Sous-type : Héritage et spécialisation (concepts souvent utilisés avec des sens variés)

28 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 228 2.4: Approches à la description de comportement Le problème Notes sur l’évolution des langages L’orientation objet

29 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 229 Le problème La qualité d’un système temps-réel est déterminée principalement par son comportement Le comportement est l’aspect d’un système le plus difficile à décrire à cause de sa nature dynamique et éphémère Comment peut-on représenter un comportement dynamique et possiblement infini dans une forme statique et finie ?

30 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 230 Exemple d’une description de comportement

31 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 231 Différentes formes de description de comportement Description orientée-état –Met le point sur des états et des transitions –Chaque état est représenté par un nœud –Chaque transition représente un instance d’action Description orientée-action –Met le point sur les types d’actions et leur ordre d’exécution qui peut être influencé par les valeurs de variables –Les états ne sont pas nécessairement représentés explicitement, mais ils peuvent être trouvés en analysant les actions

32 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 232 2.5: Quelques approches de description Description abstraite Description par entités et relations Une notation parlant des instances Diagrammes de flux de données Les diagrammes d’activités (de UML) et “Use Case Maps” (non discutés dans le livre) Machine à états finis

33 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 233 Descriptions abstraites Il y a des approches différentes à la description abstraite des systèmes Conflit entre le besoin de formaliser et de comprendre Les méthodes de description qui ont été le plus utilisées jusqu’à date était celles qui s’attardaient surtout au besoin des utilisateurs pour comprendre La formalisation est une étape nécessaire au développement d’outils (pour l’édition de descriptions, la vérification, le développement d’implantation ou le développement de tests)

34 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 234 Description entité-relationnelle

35 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 235 Entity Relationship Diagram Legend

36 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 236 Another Entity Relationship Diagram

37 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 237 SOON Notation (used in book by Braek)

38 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 238 SOON: classes et instances

39 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 239 UML Class Diagram

40 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 240 Diagramme de flux de données

41 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 241 UML: Diagrammes d’activités Ce type diagramme rassemble aux anciennes diagrammes de flux de données. Voici un exemple:

42 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 242 Use Case Maps Une notation (avec racines à Ottawa) sémantiquement similaire Voici le même exemple: Receive Order Fill Order Send Invoice Ship Order Make Payment Acccept Payment Close Order Warehouse Office Client [ Order rejected ] [ Order accepted ]

43 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 243 Concepts pour décrire les exigences Each Use Case is a scenario –Actions done by actors in some given order Action: Activity / Responsibility Actor: Swimlane / Component Order: sequence, alternatives, concurrency, arbitrary control flows (similar to Petri nets) Abstraction: refinement of activity / Plug-in Data-Flow: Object flow / not in UCMs. Question: what type of data is exchanged (an extension of control flow) –Input assertions for input data flow –Output assertions for output data flow –Conditions for alternatives (also in UCMs)

44 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 244 Machine à états finis (finite state machine, FSM)

45 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 245 Une FSM est définie par: Un ensemble fini d’entrées, I; Un ensemble fini de sorties, O; Un ensemble fini d’états, S; Une fonction du prochain état, F S : S x I  S; Une fonction de sortie, F O : S x I  O*; Un état initial désigné, Initial.

46 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 246 2.6: La méthodologie présentée dans ce livre

47 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 247 Sommaire des notations

48 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 248 2.7: La notation SOON “SISU Object-Oriented Notation” Utilisée pour décrire la structure d’un système où le langage SDL n’est pas approprié Moins formelle et n’implique pas la sémantique de SDL

49 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 249 Les symboles de SOON

50 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 250 La syntaxe de SOON

51 2003, revisé 2006, 07 et 08SEG2501 - Chapitre 251 La syntaxe de SOON (II)


Télécharger ppt "2003, revisé 2006, 07 et 08SEG2501 - Chapitre 21 Chapître 2 Principes de base concernant les exigences."

Présentations similaires


Annonces Google