You are on page 1of 620

SPECIFICATION ET CONCEPTION

DES SYSTEMES UNE METHODOLOGIE : MCSE

Ouvrage publié par Masson en 1990 actuellement épuisé

JEAN PAUL CALVEZ
jean-paul.calvez@polytech.univ-nantes.fr

Polytech’Nantes Rue Christian Pauc BP 50609 44306 NANTES Cedex 03

Cet ouvrage a été élaboré dans le cadre du contrat COMETT 89R/88/3/1724/C-1 "outils de formation industrielle à la conception de systèmes électroniques". L’auteur remercie toutes les personnes ayant participé à ce contrat, notamment: - Y. THOMAS - B. REMAUD - R. MARTINS - G. OJEA - M. BETHENOD - F. CARSTEN - P. GOLBERG - D.M. NUNES - M. GARCIA NORIEGA Directeur de l’IRESTE de NANTES, Professeur IRESTE NANTES, Professeur Faculté des Sciences & Technologies UNIVERSIDAD NOVA, LISBONNE, Professeur ETSII Université d’OVIEDO, Directeur MATRA MHS NANTES, Ingénieur Société ERNITEC, COPENHAGUE, Directeur financier Société SFERE, PARIS, Ingénieur Société EID, LISBONNE, Directeur Société SRI, OVIEDO,

- M.F. SANCHEZ-REFUSTA Directeur FICYT, OVIEDO,

NOTA L’auteur a écrit un second ouvrage dans la même collection intitulé : "Spécification et conception des systèmes. Des études de cas". 270 p. Cet ouvrage est un recueil de 13 problèmes avec pour chacun une description complète de la solution. Il est voulu didactique. Ainsi le concepteur peut plus facilement apprendre, comprendre et assimiler MCSE par des exemples, et ceci en concevant le système qu’il désire par analogie avec un des problèmes proposés. Ce livre est un complément indispensable au présent ouvrage. Le présent ouvrage est aussi publié en version anglaise sous le titre " Embedded RealTime Systems. A Specification and Design Methodology". 630 p. John WILEY and Sons limited, 1992.

TABLE DES MATIERES

AVANT-PROPOS

1

Partie 1 : PRESENTATION DE LA METHODOLOGIE
Ch 1 - INTRODUCTION
1.1. LES OBJECTIFS POUR UN DEVELOPPEMENT 1.2. LES DIFFICULTES DU METIER DE CONCEPTEUR 1.3. INTERETS D’UNE METHODOLOGIE 1.4. GENESE DE LA METHODOLOGIE MCSE 1.5. OBJECTIF DE CE DOCUMENT 6 6 8 9 10

Ch 2 - CARACTERISTIQUES DES SYSTEMES
2.1. EVOLUTION DES TECHNIQUES ET DES MOYENS DE REALISATION 2.2. LE DOMAINE DE L’INFORMATIQUE INDUSTRIELLE 2.3. LES SYSTEMES DEDIES 2.4. LES SYSTEMES TEMPS-REEL 2.5. QUALITES D’UN SYSTEME 2.6. CATEGORIES DE SYSTEMES 13 14 16 16 18 18

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME
3.1. CONTEXTE D’UN DEVELOPPEMENT 3.2. LES PHASES D’UN DEVELOPPEMENT 3.3. MODELES DE CYCLE DE VIE 3.3.1. Le Modèle "Waterfall" 3.3.2. Le cycle en V 3.3.3. Le Modèle "Spirale" 3.3.4. Le modèle "Contractuel" 3.4. QUELQUES CONSTATATIONS 3.4.1. Recouvrement des phases 3.4.2. Coût de correction des erreurs 3.4.3. Facteurs de Productivité 3.4.4. Répartition de l'effort 22 24 26 26 27 28 29 30 30 31 31 32

M.C.S.E

i

SPECIFICATION ET CONCEPTION DES SYSTEMES
3.5. DEVELOPPEMENT POUR UN SYSTEME ELECTRONIQUE 3.6. DOMAINE DE MCSE 33 35

Ch 4 - BASES POUR UNE METHODOLOGIE
4.1. TERMINOLOGIE 4.1.1. Problème: définition, résolution 4.1.2. Modèle et modélisation 4.1.3. Méthode et méthodologie 4.2. CARACTERISATION DU TRAVAIL DE CONCEPTION 4.2.1. La Conception: une activité humaine 4.2.2. Le processus de conception 4.2.3. Raffinement et abstraction 4.3. CARACTERISTIQUES D’UNE METHODOLOGIE 4.3.1. Modèle de description 4.3.2. Méthode et technique pour chaque étape 4.3.3. Modèles de solutions 37 37 38 38 38 38 40 41 42 42 43 43

Ch 5 - PRESENTATION DE MCSE
5.1. DEVELOPPEMENT DE LA METHODOLOGIE 5.2. LE MODELE DE DESCRIPTION 5.2.1. Le Modèle fonctionnel 5.2.2. Le modèle comportemental 5.2.3. Le modèle exécutif 5.2.4. Intérêt de cette modélisation 5.3. LA DEMARCHE 5.3.1. Elaboration des spécifications 5.3.2. Conception fonctionnelle 5.3.3. Définition de la réalisation 5.3.4. Réalisation 5.4. CARACTERISTIQUES DE MCSE 45 47 49 50 51 52 53 54 55 55 56 56

Ch 6 - UN EXEMPLE D’ILLUSTRATION
6.1. CAHIER DES CHARGES 6.1.1. Contrôle du régime de croisière 6.1.2. Suivi de la vitesse moyenne 6.1.3. Suivi de la consommation de carburant 6.1.4. Maintenance 6.1.5. Caractéristiques complémentaires 6.2. SPECIFICATIONS 6.2.1. Modélisation de l'environnement 6.2.2. Spécifications fonctionnelles 6.2.3. Spécifications opératoires et technologiques 6.3. CONCEPTION FONCTIONNELLE 6.3.1. Délimitation du système 6.3.2. Première structure fonctionnelle 6.3.3. Raffinement 6.3.4. Comportement de contrôle vitesse 6.3.5. Comportement de supervision 6.3.6. Comportement de maintenance 6.3.7. Comportement de génération_temps 6.4. DEFINITION DE LA REALISATION 6.4.1. Introduction des interfaces 6.4.2. Analyse des contraintes de temps 62 62 63 63 63 63 64 64 66 69 71 71 72 74 75 77 78 79 80 80 84

ii

M.C.S.E

UNE METHODOLOGIE
6.4.3. Répartition matériel/logiciel 6.4.4. Spécification de l'implantation logicielle 6.4.5. Spécification de la réalisation matérielle 6.5. CONCLUSIONS : QUELQUES REMARQUES 85 85 87 88 89

BIBLIOGRAPHIE 1

Partie 2 : MODELES ET METHODOLOGIES
Ch 7 - PANORAMA DES METHODOLOGIES
7.1. CLASSIFICATION DES METHODOLOGIES ET HISTORIQUE 7.2. SADT 7.2.1. Le modèle 7.2.2. La méthode 7.3. STRUCTURED ANALYSIS 7.3.1. Le modèle 7.3.2. La méthode 7.4. STRUCTURED DESIGN 7.4.1. Le modèle 7.4.2. La méthode 7.4.3. Remarques 7.5. METHODOLOGIE DE JACKSON (JSD) 7.5.1. Les modèles 7.5.2. La démarche 7.5.3. Remarques 7.6. SREM 7.6.1. Le modèle 7.6.2. La méthode SREM pour la spécification 7.6.3. La méthode SYSREM pour la conception 7.6.4. Remarques 7.7. METHODOLOGIE DE WARD ET MELLOR (SDRTS OU RTSA) 7.7.1. Le modèle 7.7.2. La démarche 7.8. METHODOLOGIE de HATLEY et PIRBHAI 7.8.1. Le modèle 7.8.2. La démarche 7.9. METHODOLOGIE DE LAVI ET HAREL (STATEMATE COMME OUTIL) 7.9.1. Le modèle ECS (Embedded Computer Systems) 7.9.2. La démarche 7.9.3. Remarques 7.10. DARTS (DESIGN APPROACH FOR REAL-TIME SYSTEMS) 7.10.1. Le modèle pour DARTS 7.10.2. La démarche 7.11. CONCEPTION ORIENTEE OBJET (O.O.D) 7.11.1. Le modèle objet 7.11.2. Démarche pour la conception 7.12. SYSTEM DESIGN WITH MACHINE CHARTS 7.12.1. Le modèle 7.12.2. La méthode 7.12.3. Remarques 96 98 98 100 101 101 102 103 104 104 106 106 107 109 112 113 113 114 115 116 117 117 118 121 121 123 124 124 126 127 127 127 127 128 129 130 133 133 134 135

M.C.S.E

iii

SPECIFICATION ET CONCEPTION DES SYSTEMES
7.13. METHODOLOGIE DE NIELSEN ET SHUMATE 7.13.1. Modèles 7.13.2. Démarche 7.13.3. Remarques 7.14. BILAN 137 137 138 138 139

Ch 8 - PANORAMA DES MODELES
8.1. BASES POUR L’ANALYSE DES MODELES 8.1.1. Qualités des modèles 8.1.2. Classification des modèles 8.1.3. Modèles analytiques 8.1.4. Modèles conceptuels 8.2. OBJECTIFS DES MODELES POUR LES SYSTEMES 8.2.1. Modélisation pour les spécifications 8.2.2. Modélisation en conception 8.3. PANORAMA DES MODELES 8.3.1. Modèle pour les activités 8.3.2. Modèles pour les données 8.3.3. Modèles pour les fonctions 8.3.4. Modèles pour le comportement 8.4. CONCLUSION: LES MODELES DE MCSE 142 142 142 143 143 145 145 147 148 148 148 149 151 155 159

BIBLIOGRAPHIE 2

Partie 3 : SPECIFICATION D’UN SYSTEME
Ch 9 - LE CAHIER DES CHARGES
9.1. LE DEMANDEUR : SOURCE DU BESOIN 9.2. LE CONCEPTEUR: EXPERT DU DOMAINE DE REALISATION 9.3. LE CAHIER DES CHARGES: EXPRESSION DU BESOIN 9.4. SOUHAIT DU DEMANDEUR 9.5. BUT ET IMPLICATION DU CAHIER DES CHARGES 9.6. CONTENU ET GUIDE POUR LE CAHIER DES CHARGES 9.7. REPONSE A UN CAHIER DES CHARGES 9.8. EXEMPLES DE PROBLEMES 9.8.1. Système de contrôle en vitessse d'un centrifugeur 9.8.2. Automatisation par chariot filoguidé 9.9. RESUME 168 168 168 169 169 170 172 172 173 174 176

Ch 10 - OBJECTIF D’UNE SPECIFICATION
10.1. ROLE D'UNE SPECIFICATION 10.1.1. Distance entre client et concepteur 10.1.2. Diversité des partenaires côté client 10.1.3. Importance d'une vérification 10.1.4. Une spécification comme document formel vérifiable 10.2. NATURE D'UNE SPECIFICATION 10.3. CARACTERISTIQUES D'UNE SPECIFICATION 10.4. GRANDES LIGNES DU CONTENU D'UNE SPECIFICATION 10.5. DIFFICULTES DU TRAVAIL DE SPECIFICATION 10.6. COMPETENCES POUR SPECIFIER 10.7. RESUME 178 178 178 179 180 182 182 184 185 185 186

iv

M.C.S.E

UNE METHODOLOGIE Ch 11 - BASES POUR LA MODELISATION
11.1. QUE FAUT-IL CARACTERISER? 11.2. NATURE DE LA CARACTERISATION : MODELISATION 11.3. CARACTERISATION D’UNE ENTITE 11.3.1. Nature d'une entité 11.3.2. Nature des éléments caractéristiques 11.3.3. Dépendance entre éléments caractéristiques 11.3.4. Nature des entrées et des sorties 11.4. TROIS VUES POUR LA DESCRIPTION D’UNE ENTITE 11.5. MODELISATION PAR LES DONNEES/INFORMATIONS 11.5.1. Modélisation selon 2 niveaux 11.5.2. Modèle pour la description des entités donnée 11.5.3. Modèle pour la description des relations 11.5.4. Modélisation par les données 11.6. MODELISATION PAR LE COMPORTEMENT 11.6.1. Les différents modèles à états discrets 11.6.2. Modélisation par les états 11.6.3. Modélisation stimuli/réponse 11.6.4. Règles préconisées pour le modèle de comportement à états discrets 11.7. MODELISATION PAR LES ACTIVITES 11.8. GUIDE POUR LA MODELISATION 11.9. RESUME 188 190 190 190 191 192 193 193 194 195 196 198 199 200 201 203 204 205 207 211 213

Ch 12 - DEMARCHE POUR LA SPECIFICATION
12.1. LES CONSTITUANTS D'UNE SPECIFICATION 12.2. PRESENTATION DE LA DEMARCHE 12.3. ANALYSE ET MODELISATION DE L'ENVIRONNEMENT 12.3.1. Modélisation de chaque entité 12.3.2. Description fonctionnelle de l'environnement 12.4. DELIMITATION DES ENTREES ET SORTIES DU SYSTEME 12.5. EXEMPLE : CONTROLE EN VITESSE D’UN CENTRIFUGEUR 12.6. SPECIFICATIONS FONCTIONNELLES 12.6.1. Nature des spécifications fonctionnelles 12.6.2. Approches pour élaborer une spécification fonctionnelle 12.6.3. Méthode pour élaborer les spécifications fonctionnelles 12.6.4. Exemples 12.7. SPECIFICATIONS OPERATOIRES 12.8. SPECIFICATIONS TECHNOLOGIQUES 12.9. PROCEDURES D’INSTALLATION ET D’EXPLOITATION 12.10. EXEMPLE 2: AUTOMATISATION PAR CHARIOT FILOGUIDE 12.10.1. Modélisation de l'environnement 12.10.2. Spécifications du système 12.11. VERIFICATION, VALIDATION DES SPECIFICATIONS 12.11.1. Les participants 12.11.2. Planification du travail et des revues 12.12. CARACTERISTIQUES DE LA SPECIFICATION 12.13. RESUME 216 217 219 219 222 223 224 226 226 227 232 234 235 236 239 239 240 241 244 244 244 245 246 247

BIBLIOGRAPHIE 3 M.C.S.E

v

SPECIFICATION ET CONCEPTION DES SYSTEMES

Partie 4 : CONCEPTION FONCTIONNELLE
Ch 13 - LE MODELE FONCTIONNEL
13.1. LES CONSTITUANTS DU MODELE FONCTIONNEL 13.2. LE MODELE DE STRUCTURE FONCTIONNELLE 13.2.1. Représentation graphique 13.2.2. Cohérence et lisibilité d'une S.F. 13.2.3. Interprétation d'une S.F. 13.2.4. Raffinement et abstraction d'une S.F. 13.2.5. Décomposition maximale: fonctions élémentaires ou actions 13.2.6. Règles de comportement pour une fonction élémentaire 13.2.7. Propriétés d'une structure fonctionnelle 13.3. SPECIFICATION DES FONCTIONS ELEMENTAIRES 13.3.1. Objectifs de la spécification 13.3.2. Choix du langage de description 13.3.3. Le modèle de description 13.3.4. Interprétation du modèle 13.4. SPECIFICATION DES DONNEES 13.4.1. Objectifs de la spécification des données 13.4.2. Modèle de description 13.4.3. Catégories de données: les structures 13.4.4. Décomposition d'une donnée: minimisation et normalisation 13.4.5. Utilisation des données 13.5. PROPRIETES GLOBALES DU MODELE FONCTIONNEL 13.6. RESUME 254 255 255 256 258 261 263 263 265 266 267 267 269 273 274 274 275 276 278 279 280 282

Ch 14 - PRINCIPES EN CONCEPTION
14.1. CONCEPTION ORIENTEE SUJET 14.2. CONCEPTION INDEPENDANTE DE LA TECHNOLOGIE 14.2.1. Fonctions d'interfaçage avec l'environnement physique 14.2.2. Fonctions de dialogue homme/machine 14.2.3. Répartition géographique 14.2.4. Maintenance, sûreté de fonctionnement 14.2.5. Importance des catégories de spécification 14.3. COMPLEXITE MINIMALE ET INDEPENDANCE 14.3.1. Orthogonalité ou cohérence des fonctions 14.3.2. Réduction des couplages 14.4. DEMARCHE POUR LA DEDUCTION D'UNE SOLUTION 14.4.1. Analyse plutôt qu'intuition 14.4.2. Approche par les données plutôt que par les fonctions 14.4.3. Raffinement plutôt qu'abstraction 14.5. DECOMPOSITION VERTICALE OU HORIZONTALE 14.6. MODELES GENERIQUES DE SOLUTIONS 14.7. RESUME 284 285 286 287 287 288 289 290 290 291 291 291 292 293 294 295 296

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE
15.1. PRESENTATION DE LA DEMARCHE 15.2. DOCUMENTS EN ENTREE ET EN SORTIE DE L'ETAPE 15.2.1. Document de spécification 15.2.2. Document de conception 15.3. DELIMITATION DES ENTREES ET SORTIES 15.3.1. Démarche 15.3.2. Exemple 1: Contrôle en vitesse d'un centrifugeur 300 302 302 302 303 303 304

vi

M.C.S.E

UNE METHODOLOGIE
15.3.3. Exemple 2: Automatisation par chariot filoguidé 15.4. RECHERCHE D’UNE PREMIERE DECOMPOSITION FONCTIONNELLE 15.4.1. Importance de la première décomposition fonctionnelle 15.4.2. Démarche pour élaborer une solution 15.4.3. Exemple 1: contrôle en vitesse d’un centrifugeur 15.4.4. Exemple 2: Automatisation par chariot filoguidé 15.5. RAFFINEMENT FONCTIONNEL 15.5.1. Critère d'arrêt pour le raffinement 15.5.2. Déroulement du raffinement 15.5.3. Exemple 1: contrôle en vitesse d’un centrifugeur 15.5.4. Exemple 2: Automatisation par chariot filoguidé 15.6. COMPORTEMENT DES FONCTIONS ELEMENTAIRES 15.6.1. Méthode pour l'obtention d'une description algorithmique 15.6.2. Exemple 1: Contrôle en vitesse d’un centrifugeur 15.6.3. Exemple 2: Automatisation par chariot filoguidé 15.7. DESCRIPTION DES DONNEES 15.7.1. Méthode pour décrire les données 15.7.2. Illustration par un exemple 15.8. CRITERES D'EVALUATION D’UNE SOLUTION 15.8.1. Analyse du couplage 15.8.2. Analyse de la cohérence 15.8.3. Analyse de la complexité 15.8.4. Lisibilité d'une solution 15.9. DOCUMENTATION 15.10. RESUME 305 307 307 308 310 311 312 312 313 313 314 315 316 316 319 321 322 323 325 325 326 326 326 327 327

Ch 16 - MODELES GENERIQUES DE SOLUTIONS
16.1. ROLE ET APPORT D'UN MODELE GENERIQUE 16.2. MODELE CONTROLEUR/PROCEDE COMMANDE 16.2.1. Principe 16.2.2. Le modèle 16.2.3. La méthode 16.2.4. Exemple 16.3. MODELE SUPERVISION/CONTROLE-COMMANDE 16.3.1. Principe 16.3.2. Le modèle 16.3.3. La méthode 16.3.4. Exemples 16.4. MODELE CLIENT/SERVEUR 16.4.1. Principe 16.4.2. Le modèle 16.4.3. La méthode 16.4.4. Exemple: transmission de message par liaison série 16.5. MODELE D'INTERACTIVITE 16.5.1. Principe 16.5.2. Le modèle 16.5.3. La méthode 16.5.4. Exemple 16.5.5. Généralisation du modèle au cas multi-fenêtres 16.6. RESUME 330 330 330 331 332 332 334 334 335 335 336 336 336 337 338 339 340 340 341 342 342 344 344 347

BIBLIOGRAPHIE 4 M.C.S.E

vii

SPECIFICATION ET CONCEPTION DES SYSTEMES

Partie 5 : DEFINITION DE LA REALISATION
Ch 17 - LE MODELE D’EXECUTION
17.1. CARACTERISTIQUES DU MODELE D’EXECUTION 17.1.1. Le modèle d'exécution et ses constituants 17.1.2. Signification des éléments et des relations 17.2. LE MODELE DE STRUCTURE D'EXECUTION 17.2.1. Représentation graphique 17.2.2. Interprétation d'une S.E 17.2.3. Raffinement et abstraction d'une structure d'exécution. 17.3. SPECIFICATION DES CONSTITUANTS POUR LA REALISATION 17.3.1. Spécification d'un processeur 17.3.2. Spécification d'une mémoire 17.3.3. Spécification d'un noeud de communication 17.4. PROPRIETES DU MODELE D’EXECUTION 17.5. RESUME 352 352 353 355 355 357 358 359 360 360 360 361 362

Ch 18 - LE MODELE D’INTEGRATION
18.1. LE MODELE D'INTEGRATION ET SES CONSTITUANTS 18.2. LE MODELE D'ALLOCATION 18.2.1. Correspondance entre les éléments des 2 structures 18.2.2. Contraintes pour une allocation 18.3. LE MODELE D'IMPLANTATION POUR CHAQUE PROCESSEUR 18.3.1. Implantation des tâches 18.3.2. Implantation de chaque tâche 18.3.3. Spécification de chaque élément 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION 18.4.1. Correspondance: Fonctions —> Tâches 18.4.2. Traduction des relations par partage de variables 18.4.3. Traduction des synchronisations par événement 18.4.4. Traduction pour des transferts par messages 18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL 18.5.1. Implantation sans moniteur temps-réel 18.5.2. Implantation avec un exécutif temps-réel 18.5.3. Critères de choix de la technique d'implantation 18.6. CARACTERISTIQUES DU MODELE D'INTEGRATION 18.7. RESUME 364 365 365 367 368 369 371 372 372 373 374 374 375 376 377 378 380 381 382

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION
19.1. LES OBJECTIFS A ATTEINDRE 19.1.1. Spécifications matérielles 19.1.2. Contraintes de temps 19.1.3. Réduction du coût de développement 19.1.4. Réduction de la partie organisationnelle 19.1.5. Règles de qualité 19.1.6. Objectifs contradictoires 19.2. PRESENTATION DE LA DEMARCHE 19.3. INTRODUCTION DES CONTRAINTES DE REPARTITION 19.4. INTRODUCTION DES INTERFACES 19.4.1. Modèle pour l’introduction des interfaces 19.4.2. Introduction des interfaces physiques 19.4.3. Introduction des interfaces homme-machine 19.4.4. Exemple 1 : contrôle en vitesse d’un centrifugeur 384 384 385 385 386 387 387 388 388 391 392 393 394 395

viii

M.C.S.E

UNE METHODOLOGIE
19.4.5. Exemple 2 : automatisation par chariot filoguidé 19.5. CONTRAINTES POUR UNE STRUCTURE D’EXECUTION 19.5.1. Evaluation des contraintes de temps 19.5.2. Techniques pour déduire une structure d’exécution 19.6. DETERMINATION DE LA STRUCTURE D'EXECUTION 19.6.1. Choix de la répartition matériel / logiciel 19.6.2. Exemple 1 : contrôle en vitesse d’un centrifugeur 19.6.3. Exemple 2 : automatisation par chariot filoguidé 19.7. SCHEMA D'IMPLANTATION LOGICIELLE POUR CHAQUE PROCESSEUR 19.7.1. Traduction d’une dépendance temporelle entre deux actions 19.7.2. Exemple 1 : contrôle en vitesse d’un centrifugeur 19.7.3. Exemple 2 : automatisation du chariot filoguidé 19.7.4. Implantation d’une séquence d’actions 19.7.5. Implantation d’une séquence bouclée d’actions 19.7.6. Implantation de plusieurs séquences d’actions 19.7.7. Capacité des ports 19.7.8. Utilisation des services d’un processeur 19.7.9. Implantation de modules 19.8. IMPLANTATION DES DONNEES 19.8.1. Critères pour l’implantation des données 19.8.2. Implantation pour des données structurées 19.8.3. Implantation pour des collections et des relations 19.9. SPECIFICATION DE LA REALISATION MATERIELLE 19.9.1. Exemple 1 : contrôle en vitesse d’un centrifugeur 19.9.2. Exemple 2 : automatisation du chariot filoguidé 19.9.3. Couplage entre processeurs 19.10. DOCUMENTATION ET CARACTERISTIQUES DE LA SOLUTION 19.11. RESUME 400 402 402 408 409 409 410 411 412 413 414 415 416 417 417 419 419 420 421 421 422 422 423 424 424 425 427 428 431

BIBLIOGRAPHIE 5

Partie 6 : REALISATION
Ch 20 - DEMARCHE POUR LA REALISATION
20.1. OBJECTIF DE LA REALISATION 20.1.1. Caractérisation de l'étape de Réalisation 20.1.2. Variété des méthodes et moyens en réalisation 20.1.3. Importance en durée de l'étape de Réalisation 20.2. DEMARCHE POUR LA REALISATION 20.3. VERIFICATION ET ACCEPTATION DES SPECIFICATIONS 20.4. REALISATION MATERIELLE 20.4.1. Démarche 20.4.2. Les outils 20.4.3. Règles à respecter 20.5. REALISATION LOGICIELLE 20.5.1. Démarche 20.5.2. Les outils 20.5.3. Règles à respecter 20.5.4. Traitement des erreurs 20.6. INTEGRATION ET TEST 20.7. LES SOURCES D'ERREURS 435 436 437 439 440 441 442 442 443 443 443 443 444 444 446 446 447

M.C.S.E

ix

SPECIFICATION ET CONCEPTION DES SYSTEMES
20.8. RAFFINEMENT EN REALISATION 20.8.1. Raffinement en réalisation matérielle 20.8.2. Raffinement en réalisation logicielle 20.9. INTERET DE LA REUTILISATION 20.10. RESUME 448 449 449 450 450

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE
21.1. METHODE POUR LA RECHERCHE D'UNE REALISATION 21.2. TECHNIQUES POUR LA REALISATION 21.2.1. Réalisation avec des composants existants 21.2.2. Développement de composants spécifiques 21.3. VERIFICATION, VALIDATION D'UNE REALISATION 21.3.1. Test fonctionnel 21.3.2. Test de fabrication 21.4. REUTILISATION POUR LE MATERIEL 21.5. MODELES GENERIQUES POUR LA REALISATION 21.6. LE MODELE DE LA MACHINE DE MOORE 21.6.1. Le principe 21.6.2. Le modèle 21.6.3. méthode 21.7. LE MODELE COMMANDE/EXECUTION 21.7.1. Principe 21.7.2. Modèle 21.7.3. Méthode 21.8. RESUME 454 454 454 455 457 457 458 459 460 461 461 462 463 465 465 466 468 469

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE
22.1. NIVEAUX DE FONCTIONNALITES ET DEMARCHES 22.1.1. Niveaux de fonctionnalités 22.1.2. Démarches 22.2. REUTILISATION POUR LE LOGICIEL 22.3. PRINCIPES DE REALISATION 22.3.1. Qualités 22.3.2. Caractéristiques 22.3.3. Principes 22.4. TECHNIQUES POUR L'INFORMATIQUE INDUSTRIELLE 22.5. IMPLANTATION DIRECTE 22.6. UTILISATION D'UN EXECUTIF TEMPS-REEL 22.7. UTILISATION DU LANGAGE ADA 22.7.1. Le mécanisme de rendez-vous 22.7.2. Implantation des relations du modèle fonctionnel 22.7.3. Interruptions et exceptions 22.8. UTILISATION DU LANGAGE OCCAM ET DU TRANSPUTER 22.8.1. Le mécanisme d'échange par canal 22.8.2. Implantation des relations du modèle fonctionnel 22.9. SERVICES POUR LE MODELE FONCTIONNEL 22.10. REALISATION ORIENTEE OBJET 22.10.1. Catégories d'objets 22.10.2. MCSE et la conception orientée objet 22.10.3. MCSE pour l'identification des objets 22.10.4. Structuration avec la programmation objet 22.11. RESUME 472 472 473 475 476 476 477 477 478 479 480 481 481 483 484 485 485 487 489 491 491 492 493 497 499 501

BIBLIOGRAPHIE 6 x

M.C.S.E

UNE METHODOLOGIE

Partie 7 : CONDUITE DE PROJET
Ch 23 - MANAGEMENT DE PROJETS
23.1. UNE PRESENTATION DU PROBLEME 23.1.1. Modélisation d'une étape de développement 23.1.2. Types d'Entropie 23.1.3. Causes de l'entropie 23.2. ORGANISATION DU MANAGEMENT 23.3. PLANIFICATION 23.3.1. Objectifs 23.3.2. Principes 23.4. TECHNIQUES POUR LA PLANIFICATION 23.5. ORGANISATION 23.6. CONSTITUTION DES EQUIPES 23.7. DIRECTION DE PROJET 23.8. CONTROLE 508 508 509 510 512 514 514 515 515 516 517 517 518

Ch 24 - PLANNING ET COUT D’UN PROJET
24.1. CONTRAINTES DE DEROULEMENT POUR CHAQUE ETAPE 24.1.1. Etape de spécification 24.1.2. Etape de conception 24.1.3. Etape de définition de la réalisation 24.1.4. Etape de réalisation 24.2. DUREE TOTALE D'UN PROJET 24.3. OPTIMISATION D'UN PLANNING 24.4. METHODE OU PAS DE METHODE 24.5. ESTIMATION DU COUT D'UN PROJET 522 522 523 524 525 526 527 528 528

Ch 25 - CONFORMITE D’UN PROJET
25.1. TERMINOLOGIE 25.2. OBJECTIFS 25.3. TYPE D'ERREURS 25.4. NATURE DES VERIFICATIONS 25.5. METHODES EN CONCEPTION 25.5.1. Technique pour les revues de conception 25.5.2. Simulation/modélisation comme outil d'évaluation 25.6. METHODES POUR LA PHASE DE REALISATION 25.6.1. Analyse statique 25.6.2. Analyse dynamique 25.6.3. Démarche pour le test 25.7. TECHNIQUES POUR L'INTEGRATION 25.7.1. Assemblage par phase 25.7.2. Assemblage incrémental 25.7.3. Tests orientés OBJECTIFS 25.7.4. Remarques sur ces démarches 25.8. ENVIRONNEMENT POUR LE TEST 25.9. TESTS AUTOMATIQUES 25.10. PLANIFICATION DES TESTS 25.11. GUIDE POUR LA SPECIFICATION DU TEST 25.12. GUIDE POUR UN DOCUMENT DE TEST 25.12.1. Information Générale 25.12.2. Plan 25.12.3. Spécification des Tests 532 532 533 534 535 536 537 537 537 537 538 538 538 539 539 540 540 540 541 541 542 542 543 543

M.C.S.E

xi

SPECIFICATION ET CONCEPTION DES SYSTEMES
25.12.4. Evaluation des Tests 25.12.5. Description des tests 544 544

Ch 26 - MAINTENANCE
26.1. TYPES DE MAINTENANCE 26.2. LES CAUSES DE LA MAINTENANCE 26.2.1. Qualité du produit développé 26.2.2. Documentation 26.2.3. Utilisateurs 26.2.4. Personnel 26.3. PROCEDURES POUR LA MAINTENANCE 26.3.1. Alternative: maintenance/nouvelle conception 26.3.2. Méthode de contrôle des changements 26.4. SOLUTIONS POUR AMELIORER LA MAINTENANCE 26.5. LES OUTILS DE MAINTENANCE 26.6. MANAGEMENT DE LA MAINTENANCE 26.6.1. Objectif et activités 26.6.2. Règles pour la maintenance 26.6.3. gestion des équipes 546 546 547 548 548 548 548 549 550 550 551 552 552 552 553

Ch 27 - DOCUMENTATION D’UN PROJET
27.1. JUSTIFICATION FONCTIONNELLE 27.2. STRUCTURATION DES DOCUMENTS 27.2.1. Hiérarchie des documents 27.2.2. Documents préliminaires 27.2.3. Documents de contrôle 27.2.4. Documents de spécification, de conception, de réalisation, de tests 27.2.5. Les manuels 27.2.6. Document de maintenance 27.3. PLANIFICATION POUR LA DOCUMENTATION 27.4. PROCEDURES POUR LA DOCUMENTATION 27.4.1. Problèmes et causes 27.4.2. Niveaux de qualité de la documentation 27.4.3. Procédures 27.5. GUIDE POUR LA REDACTION DES DOCUMENTS 27.5.1. Défauts d'un document 27.5.2. Principes pour la rédaction 27.5.3. Rédaction des manuels utilisateurs 556 557 557 558 558 560 561 562 562 562 562 563 563 565 565 566 567

Ch 28 - GESTION DE LA QUALITE
28.1. TERMINOLOGIE 28.2. PRINCIPE POUR L'OBTENTION DE LA QUALITE 28.3. LES CRITERES DE QUALITE 28.4. FACTEURS OU ATTRIBUTS DE LA QUALITE 28.5. MESURE DE LA QUALITE 28.6. METHODE 28.7. VERIFICATION DE LA QUALITE 570 570 571 572 573 573 574 577

BIBLIOGRAPHIE 7 xii

M.C.S.E

UNE METHODOLOGIE

Partie 8 : BILAN ET PERSPECTIVES
Ch 29 - APPORT DE LA METHODOLOGIE
29.1. LA BOITE A OUTILS DU CONCEPTEUR 29.2. DOMAINES D’UTILISATION 29.3. ORGANISATION DES PROJETS 29.4. REPARTITION DES COMPETENCES 29.5. GUIDE POUR LE DEVELOPPEMENT 29.6. DOCUMENTATION DES PROJETS 29.7. LES POINTS DELICATS EN CONCEPTION 29.8. PERENNITE DE LA METHODOLOGIE 582 582 582 583 584 586 586 588

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION
30.1. LES OBJECTIFS 30.2. LES FONCTIONNALITES SOUHAITEES 30.2.1. Description 30.2.2. Documentation 30.2.3. Vérification, validation 30.2.4. Production 30.2.5. Gestion de projets et de versions 30.2.6. Conduite de projets 30.3. SYNTHESE DES FONCTIONNALITES 30.4. STRUCTURE ET CARACTERISTIQUES D’UN OUTIL 30.5. GUIDE POUR UNE ANALYSE DES OUTILS 592 593 593 594 594 595 596 597 597 598 600

Ch 31 - REALITES ET PERSPECTIVES
31.1. LA COMPETENCE DU CONCEPTEUR 31.2. RESPONSABILITES DE L’ORGANISATION 31.3. PERSPECTIVES A LONG TERME 602 602 603 607

BIBLIOGRAPHIE 8

M.C.S.E

xiii

SPECIFICATION ET CONCEPTION DES SYSTEMES

CONTENTS
Part 1 : Methodology Overview 1 - Introduction 2 - Systems characteristics 3 - System development life cycle 4 - Methodology basis 5 - MCSE overview 6 - An example Part 2 : Models and Methodologies 7 - Methodologies survey 8 - Models survey Part 3 : System Specification 9 - System requirements 10 - System specification 11 - Modeling concepts 12 - The specification process Part 4 : Functional Design 13 - The functional model 14 - Design principles 15 - The functional design process 16 - Template models for design Part 5 : Implementation Specification 17 - The executive model 18 - The integration model 19 - The implementation specification process Part 6 : Implementation 20 - Implementation steps 21 - Hardware development tools 22 - Software development tools Part 7 : Project Management 23 - The project management process 24 - Project planning and cost 25 - Project verification and validation 26 - Maintenance management 27 - Project documentation 28 - Quality management Part 8 : Conclusion and Perspectives 29 - Methodology contribution 30 - Requirements for a computer-aided design tool 31 - Realities and perspectives

xiv

M.C.S.E

AVANT-PROPOS

La formalisation d'une méthodologie représente un travail de longue haleine. Seul et sans terrain d'expérimentation, je ne pouvais faire aboutir un tel projet. Je tiens à remercier très chaleureusement mes collègues qui ont contribué efficacement dès le début à ce travail en accceptant à la fois la responsabilité de projets pour des industriels et l’expérimentation de la Méthodologie. Il s'agit tout particulièrement de Pascal CLODIC, Gérard DUCHENE, Jocelyn FRAPPIER, Eric FRIOT, Gérard THIBAUT. Je remercie aussi tous les étudiants et auditeurs qui ont suivi en une occasion ou une autre, la formation à la Méthodologie. Je citerai tout d'abord les étudiants du DESS "Conception et Mise en oeuvre des Systèmes Electroniques". Quatre ans durant, exploitant la méthodologie pour des projets industriels durant leur stage, ils m'ont permis de disposer d'une base expérimentale. Les contacts fructueux que j'entretiens toujours avec un certain nombre d'entre eux, qui dans leur métier d'ingénieur utilisent cette Méthodologie et arrivent à l'imposer comme démarche de travail dans leurs entreprises, sont significatifs d'une reconnaissance de l'effort pédagogique entrepris durant cette formation. Ensuite, la Conception des Systèmes fait partie intégrante du programme de la Formation d'Ingénieur IRESTE en Systèmes Electroniques et Informatique Industrielle. Les étudiants durant leur dernière année, ayant à réaliser un projet industriel de 6 mois en entreprise, prennent conscience de la vraie dimension de cet enseignement et de son intérêt essentiel pour la compétitivité de nos entreprises. Ils disposent ainsi d'un atout majeur qui répond aux préoccupations actuelles et à long terme des industriels. Je remercie aussi toutes les sociétés qui ont fait confiance à l'équipe et aux ingénieurs qui ont trouvé par la Méthodologie une nouvelle dynamique en développement de systèmes. Je ne saurais oublier la lourde tâche de frappe que constituent la saisie et la mise en forme d'un tel document. Je remercie très vivement Marie-Thérèse SALOUX qui a assuré avec qualité et efficacité le travail de saisie, Olivier DEBON et Franck BERTAUD qui ont réalisé les figures et la mise en page.

Le 18 janvier 1990 Jean Paul CALVEZ M.C.S.E 1

PARTIE

1

PRESENTATION DE LA METHODOLOGIE

Cette première partie introduit MCSE comme Méthodologie pour la Conception des Systèmes Electroniques, en présentant la classe des applications concernées, les objectifs visés et les principes essentiels. Le chapitre 1 fixe l’objectif global du document. S’adressant aux concepteurs de systèmes et aux spécialistes de l’Informatique Industrielle, la méthodologie proposée est un outil de travail améliorant la productivité et la qualité en développement de projets. Le chapitre 2 délimite le champ des applications concernées par MCSE. Pour ces applications, les systèmes dits temps-réel sont définis par leurs caractéristiques. On y évoque aussi les techniques mises en oeuvre et les compétences nécessaires. Le chapitre 3 présente le cycle de vie pour le développement de tout produit. Utile pour introduire les différentes phases, le modèle de cycle de vie permet de montrer la nature itérative du processus de développement et le domaine couvert par MCSE. Le chapitre 4 explicite les bases sur lesquelles reposent en général les méthodologies. Le découpage en étapes et la nécessité de modèles de description y sont notamment justifiés. Le chapitre 5 permet au lecteur d'avoir une vue globale de la méthodologie MCSE incluant les modèles et la démarche. Lors du chapitre 6, la démarche est introduite sur un exemple simple mais suffisamment réaliste pour que le lecteur puisse se faire une idée précise de la méthodologie , en ayant une vue synthétique des différentes étapes.

M.C.S.E

3

Chapitre 1

INTRODUCTION

Cet ouvrage décrit une méthodologie appelée MCSE pour la Spécification, la Conception et la Réalisation des Systèmes en Informatique Industrielle. Les systèmes visés intègrent à la fois les techniques de l'Electronique et de l'Informatique, et concernent des applications variées quant au domaine et à la complexité. Comme exemples, parmi tant d'autres, citons: un système de commande d'un centrifugeur, la gestion technique centralisée d'un grand bâtiment, la gestion automatique d'un magasin incluant des chariots filoguidés, la surveillance des chaînes d'ancrage pour plateformes pétrolières. De tels types d'exemples correspondent au domaine de l'Informatique Industrielle. Il s'agit de systèmes temps-réel pour des applications dédiées: ceci veut dire que le développement se fait spécifiquement pour chaque application, et qu'il doit conduire directement à un produit industriel opérationnel respectant à la fois les spécifications du client, les coûts et délais prévus. Une méthodologie peut être vue comme une boîte à outils dans laquelle le concepteur trouve une variété d'outils: - modèles, méthodes, solutions - pour mener à bien son travail. Les activités concernées par la Méthodologie MCSE sont toutes celles qui permettent de passer du cahier des charges d'un produit, d'un système ou d'une application, à la définition complète de sa réalisation. Ces activités sont structurées en 3 étapes: élaboration des spécifications, conception fonctionnelle, définition de la réalisation. Pour introduire l'apport de cet ouvrage, évoquons les objectifs de tout développement puis les difficultés de cette activité. Une méthodologie est une réponse à cette problématique.

M.C.S.E

5

Partie 1 - PRESENTATION DE LA METHODOLOGIE 1.1. LES OBJECTIFS POUR UN DEVELOPPEMENT Nous nous plaçons ici dans le cas normal d'un développement de systèmes pour un client. Une situation différente, consiste à développer un produit pour ses besoins propres. Il s'agit d'un cas particulier plus simple puisque le concepteur est aussi le demandeur. Que demande-t-on à un concepteur? En dehors de la compétence technique pour traiter le problème, plusieurs points essentiels: - de satisfaire le besoin du demandeur: ceci est un point fondamental. Le demandeur est le client et donc finance contractuellement le développement. Un produit jugé satisfaisant par le concepteur peut ne pas répondre à l’attente du demandeur. - de respecter des délais et des coûts. Normalement un développement fait l'objet d'un contrat négocié sur la base de propositions incluant des délais et des coûts. Sur cette base, le client définit une stratégie d’entreprise, par exemple vente ou intégration dans une gamme. Un non-respect du délai ou des coûts engendre des dépenses supplémentaires ou une perte de parts du marché, ainsi qu'une perte de crédibilité pour l'équipe de développement. - de satisfaire des critères de qualité. Au-delà du bon fonctionnement bien entendu nécessaire, les principaux critères concernent: la robustesse du produit (fiabilité, tolérance aux pannes), la lisibilité, qui concerne la compréhension du développement à la fois des documents et du produit, la maintenabilité de manière à corriger les défauts résiduels et pouvoir faire évoluer les caractéristiques du système. Ainsi la QUALITE dans les systèmes a des répercussions sur le coût global de toutes les opérations intervenant dans le cycle de vie du produit. 1.2. LES DIFFICULTES DU METIER DE CONCEPTEUR La situation habituelle du concepteur est la suivante: Comment faut-il procéder pour aboutir à une réalisation spécifique en état de fonctionnement et répondant à toutes les caractéristiques demandées citées ci-dessus. Il est aisé de constater la complexité du travail des concepteurs de systèmes. Une triple complexité existe: la première est due à la diversité des techniques et moyens à mettre en oeuvre, la deuxième est liée à la distance entre le domaine du problème et celui de la technique mise en oeuvre, la troisième est en rapport avec l’éventail des complexités et tailles des applications. Tout d'abord, il faut maîtriser les constituants de la réalisation; or le domaine des techniques est étendu: électronique analogique, électronique numérique et composants VLSI, informatique et programmation, problèmes d'industrialisation... Comme les techniques évoluent et se diversifient très rapidement, un effort important doit être constamment fait, ne serait-ce que pour se maintenir informé des techniques. La mise en oeuvre des systèmes nécessite aussi bien entendu une maîtrise correcte des moyens de développement pour les parties matérielle et logicielle. Le problème posé peut conduire à devoir maîtriser des techniques autres: traitement du signal, (télé)communications, algorithmique, physique.... 6 M.C.S.E

Ch 1 - INTRODUCTION Ensuite, le concepteur est différent du client. Il faut s'intéresser au domaine du demandeur: un dialogue est strictement nécessaire. En effet, l'objectif d'un système est de satisfaire le besoin du client qui n'est probablement ni électronicien ni informaticien. Pour cela, le concepteur est contraint d'interpréter au mieux la demande pour que le système donne satisfaction. Troisième point: avec l'accroissement de la complexité des applications, les systèmes ne peuvent plus être développés par une seule personne. Apparaît alors le problème de la gestion du projet, des ressources humaines, de l'organisation du travail en équipe, de la cohérence d'ensemble... Ajoutons encore, que les systèmes électroniques sont sur un marché de concurrence. Ne survivent que les bons produits et les entreprises compétitives. Avec l'évolution rapide des techniques et des idées, les délais de réalisation d'un produit industriel doivent être les plus courts possibles. Coûts et critères de qualité sont devenus essentiels. 20 à 30 % de l’effort de développement devrait être consacré à l’analyse, la spécification et la conception préliminaire. Toute erreur durant ces phases est très coûteuse pour les corrections. Ceci est connu depuis plusieurs années. Et pourtant, pour bien des projets, la spécification n’est pas élaborée convenablement, entraînant par la suite des coûts exhorbitants en reconception et modification des réalisations. Pourquoi ceci ? Les ingénieurs sont-ils en cause, ne passant pas suffisamment de temps ou n’effectuant pas correctement le travail d’analyse ? Il y a bien d’autres raisons. Tout d’abord, peu de concepteurs sont formés et entraînés à l’analyse des systèmes complexes. Ensuite les concepteurs ne peuvent pas apprendre d’eux-mêmes une ou des méthodes car il existe peu d’ouvrages explicites sur ce sujet. Enfin, la lecture d’un ouvrage n’est pas suffisante; les ingénieurs inexpérimentés doivent être guidés durant des projets pour acquérir une bonne expérience. Comment chacun acquiert la compétence? Celle-ci résulte de l'acquisition d'un savoir faire qui s'étoffe au fur et à mesure des nouveaux développements. Chaque problème traité contribue à enrichir l'expérience du concepteur. Il n'est pas étonnant de constater qu'en Informatique Industrielle le savoir faire est habituellement spécifique de groupes relativement restreints, et la méthode utilisée qui découle du travail collectif reste de ce fait très confinée. Aussi, une disparité très importante existe dans la façon de mener à bien des réalisations en fonction des entreprises et même des groupes à l'intérieur de celles-ci. La démarche la plus fréquemment constatée, procède selon un schéma en 3 phases: définition du cahier des charges, conception, réalisation. Les concepteurs utilisent directement, sans méthode particulière, le document élaboré par le demandeur. Procédant à une analyse, une solution est élaborée. La forme de description de la solution est très variée: organigramme, schémas blocs, emploi de langages de haut-niveau, ou toute autre forme de description. Très souvent, il est constaté que pour un projet donné, les solutions matérielles sont déjà choisies explicitement ou implicitement. D'autre part, la dépendance Conception puis Réalisation qui devrait exister n'est pas des plus évidentes. Il n'est pas exagéré de faire remarquer que bon nombre de fois, les choix de solutions pour la réalisation influent sur la conception et pas l'inverse. M.C.S.E 7

Partie 1 - PRESENTATION DE LA METHODOLOGIE Durant le développement, la séparation des 2 activités: -réalisation matérielle, réalisation logicielle- n'est pas non plus évidente, car le couplage entre les 2 parties est important. S'il n'y a pas au préalable, une définition précise de ce que doit faire chaque partie, le travail d'intégration qui consiste à imbriquer les 2 parties, demande, pour un projet mené de cette manière, un temps considérable. La situation s'aggrave encore par la suite, car une partie importante du temps doit être passée à assurer la maintenance, l'évolution ou l'adaptation des systèmes ainsi réalisés. Par maintenance, il faut entendre aussi bien l'évolution, l'adaptation, la correction, que le dépannage du système. Cette situation, qui résulte de la nécessité de corriger a posteriori les erreurs de conception, de spécification, voire de définition du produit, n’est pas viable. 1.3. INTERETS D’UNE METHODOLOGIE Pour résoudre son problème, le concepteur dispose de techniques et moyens variés. Encore faut-il savoir passer du problème à la mise en oeuvre des moyens. Si pendant des années, la démarche incrémentale a pu paraître suffisante, l'accroissement des types de problèmes, de la variété des techniques et de la complexité des moyens, impose de disposer de méthodes globales qui permettent de passer efficacement du problème à la définition de la solution. Une telle démarche constitue une méthodologie. Tout développement nécessite de prendre une multitude de décisions. Les connaissances sur le problème, les techniques et moyens, constituent les informations nécessaires qui permettent de décider, tandis qu'une démarche induit la chronologie des décisions. Ainsi, face à un problème, il est primordial de maîtriser 3 aspects essentiels que sont: méthodes, techniques, moyens.

METHODES

MOYENS

PROBLEME

TECHNIQUES

-Figure 1.1- Les 3 aspects essentiels pour résoudre un problème. 8 M.C.S.E

Ch 1 - INTRODUCTION La technique est le support de la réalisation. Les moyens servent à mettre en oeuvre la technique. Les méthodes aident à passer du problème à la réalisation. Que faut-il attendre d'une méthodologie? Celle-ci doit: - garantir l’obtention d’un résultat. Elle doit être suffisamment globale pour couvrir une variété de problèmes et de techniques, mais aussi précise, efficace et simple. - faciliter l'évaluation a priori de la faisabilité de l'application, du coût et du temps du développement. - augmenter la productivité des concepteurs et la qualité du résultat, ceci en favorisant au maximum la production automatique de solutions qui sont alors sans erreur par construction. - accroître la réflexion à un niveau conceptuel qui se veut le plus indépendant possible de la technologie. Ceci conduit à une meilleure compréhension du problème, à l'élaboration de spécifications et de solutions générales plus facilement réutilisables. - permettre l’organisation et la conduite de projets, de manière à pouvoir gérer des développements complexes qui nécessitent la participation d'équipes et de divers spécialistes. 1.4. GENESE DE LA METHODOLOGIE MCSE Pourquoi une méthodologie pour les Systèmes Electroniques et l'Informatique Industrielle? Différentes raisons ont conduit à une telle nécessité. Tout d'abord, durant ces vingt dernières années, l'évolution des techniques disponibles en Electronique et en Informatique a été considérable, et elle ne cessera de s'amplifier. Grâce à ces techniques, des applications de toute nature et de plus en plus complexes sont devenues réalisables. Pour répondre à une telle demande, la disponibilité de la compétence ou l'acquisition rapide de celle-ci, ainsi que l'organisation des équipes de développement sont devenus des préoccupations essentielles. Ensuite, à la différence des systèmes généraux ou des produits de série qui sont le résultat de développements progressifs, les systèmes temps-réels pour des applications dédiées sont à produire immédiatement dans la version définitive avec une garantie de résultat. Aussi, les activités en amont de la réalisation, c'est-à-dire celles qui concernent la compréhension du besoin, la rédaction des spécifications, la conception, sont essentielles pour satisfaire des contraintes telles que les délais, les coûts, la qualité. En plus des nécessités correspondant aux points précédents, nous avons constaté durant cette décennie que l'apport d'une méthodologie correspond pour les entreprises à un investissement essentiel à long terme. Le retour d'investissement, pas facile à estimer a priori, se traduit sous des formes variées: réduction des coûts et délais de développement, meilleure satisfaction des clients, plus grande pérennité des développements, réduction importante des coûts de maintenance. Une méthodologie résulte d'une volonté à long terme de chercher à mettre à la disposition des développeurs une démarche de travail complète, efficace, cohérente. On peut constater aujourd'hui que pour arriver à maturité, toute méthodologie nécessite près de 10 années. Une telle durée s'explique aisément. Une méthodologie résulte pour leurs auteurs, d'une progression M.C.S.E 9

Partie 1 - PRESENTATION DE LA METHODOLOGIE incrémentale ascendante, la seule possible pour analyser les difficultés, rechercher des solutions, conceptualiser sous la forme de modèles et méthodes, expérimenter pour vérifier et valider chaque proposition, structurer l'ensemble de manière à mettre à disposition une démarche globale descendante complète directement exploitable. Sans terrain d'expérimentation, une méthodologie ne peut voir le jour. Pour répondre au besoin des développeurs, il faut déjà connaître leurs problèmes: domaine d'activités, nature des difficultés... Pour cela, la participation à des projets industriels est impérative. Ensuite, l'expérimentation nécessite que soit appliquée tout ou partie de la Méthodologie pour ces développements industriels. L'observation des problèmes, des difficultés et des résultats est aussi une obligation car c'est la source des effets correctifs possibles. Enfin, l'expérimentation concerne les développeurs, utilisateurs de la Méthodologie, et non pas l'auteur de celle-ci ; il faut donc aussi avoir formé des concepteurs à l'approche méthodologique pour pouvoir observer les résultats de conception et aussi les difficultés d'acquisition des concepts qui subsistent, ainsi que les erreurs d'utilisation. Avec tous ces aspects, la progression est particulièrement longue. Depuis 1978, nous avons travaillé avec des industriels et pour des industriels: développement de prototypes, formation aux techniques et aux méthodes, transfert de savoir-faire et de méthodologie, création de produits puis transfert de ceux-ci à des industriels pour production et commercialisation. Depuis 1980, la Méthodologie MCSE est enseignée à un public d'ingénieurs et de techniciens, bien entendu pas dans sa version actuelle. Ayant débuté par la formation au modèle de description des systèmes: modèles fonctionnel et exécutif, nous avons rapidement constaté la difficulté pour les concepteurs de trouver une solution conforme au modèle. L'accent a alors été mis sur l'aspect méthode: comment déduire de spécifications une solution conforme au modèle?. Simultanément, nous avons observé l'impossibilité de dissocier la phase de conception des autres phases: en amont, celle de spécification, et en aval celle de réalisation. La Méthodologie a alors été progressivement étendue à l'ensemble du cycle de développement. Vers 1985, constatant qu'avec de la méthode, les concepteurs n'élaboraient pas obligatoirement des solutions de qualité, nous avons recherché un moyen au-delà de l'aspect méthode, ayant la particularité d'induire des idées de solutions (bien entendu de qualité). Une analyse des développements déjà entrepris a mis en évidence une relative similitude de solutions par classes de problèmes. Ceci a contribué à l'introduction des modèles génériques de solutions. L'effort entrepris durant 10 ans ne s'achève pas avec cet ouvrage. Seule une partie du chemin est parcourue. Un effort d'ouverture doit suivre avec pour objectifs: accroître la formation des concepteurs en nombre et en qualité, poursuivre le développement des concepts et des méthodes pour augmenter les possibilités de production automatique de solutions, induire la création d'outils informatiques comme support et guide à l'utilisation de la méthodologie. 1.5. OBJECTIF DE CE DOCUMENT Aujourd'hui, peu de méthodes, encore moins de méthodologies sont enseignées. Les raisons sont assez simples: il y a peu d'ouvrages disponibles sur le sujet et peu de spécialistes formateurs ont la maîtrise d'une méthodologie sachant qu'elle nécessite en complément une large connaissance des techniques utilisables et une expérience importante en développement de projets industriels. 10 M.C.S.E

Ch 1 - INTRODUCTION Parmi les méthodologies existantes en rapport avec les systèmes temps-réel, citons les principales. Les références bibliographiques et une présentation succincte de chacune d’elles sont données dans la partie 2. - SADT (structured analysis and design technique) pour la phase de spécification [ROSS-85]. - SA/SD (structured analysis, structured design) de DEMARCO, YOURDON et CONSTANTINE pour la spécification par diagramme flots de données et la conception modulaire [DEMARCO-79, JENSEN-79]. - JSD (Jackson system development) de JACKSON couvrant toutes les phases du développement [JACKSON-83] - O.O.D. (object oriented design) de BOOCH pour la conception orientée objet [BOOCH-83], et des variantes que sont GOOD, HOOD, MOOD, OOSD. - RTSA (real-time structured analysis) qui est une extension de SA/SD par WARD et MELLOR, et par HATLEY et PIRBHAI pour les systèmes temps réels dédiées [WARD-85, HATLEY-87]. - DARTS (Design Approach for Real Time Systems) pour la spécification et la conception d'applications temps-réel et DARTS/DA pour les applications distribuées [GOMAA-84,89]. Utilisation de cette méthode avec implantation ADA [NIELSEN88]. - SDWA (System design with ADA) [BUHR-84] et actuellement SDWMC (System design with Machine Charts [BUHR-89] pour la conception des systèmes événementiels (behaviour intensive). Ces méthodologies diffèrent quant au domaine d'applications, aux phases du développement, aux modèles et méthodes. Que faut-il utiliser? : l'une de celles citées ci-dessus, MCSE, ou faut-il en développer une nouvelle basée sur d'autres concepts? Question pertinente. Ce document a pour objectif d'améliorer la connaissance sur un tel plan méthodologique. Son contenu ne concerne donc pas des connaissances techniques mais uniquement celui de l'acquisition de concepts et de méthodes. Pour tirer un profit maximum, le lecteur est supposé avoir acquis par ailleurs des connaissances dans les domaines et techniques que sont: l'électronique analogique, l'électronique numérique, les systèmes à microprocesseurs, les automatismes et systèmes de contrôle/commande, les outils informatiques et les langages de haut-niveau. Ce document a pour ambition de proposer une méthodologie complète pour le développement des systèmes. Aussi, concerne-t-il les industriels et tout particulièrement les ingénieurs qui ont en charge la conception de produits ou de systèmes, ainsi que les étudiants ingénieurs et techniciens qui s'orientent vers ce type d'activités. Sont concernées par tout ou partie du document, au moins 4 catégories d'ingénieurs et techniciens: - les responsables de projets qui ont en charge: l'estimation, la planification, la conduite de projets, - les spécifieurs et concepteurs chargés d'effectuer tout le travail de développement en amont de la réalisation, M.C.S.E 11

Partie 1 - PRESENTATION DE LA METHODOLOGIE - les réalisateurs qui doivent utiliser et donc comprendre les résultats de la conception, - les formateurs qui ont pour mission de développer chez leurs auditeurs l’esprit méthode en spécification, conception et réalisation de systèmes. Pour répondre à ces 4 catégories d'utilisateurs, le document est structuré en 3 niveaux d'intérêt: - le niveau Présentation, qui permet de se faire une idée de ce qu'est une méthodologie. Après une délimitation du domaine d'application, la partie 1 décrit, par une présentation succincte, la méthodologie MCSE, les concepts et les étapes. Elle est illustrée par une étude de cas. La partie 8, montre en conclusion, sur la base de la trilogie: -méthodes, outils, concepteurs en tant qu'utilisateurs de méthodologies-, l'effort à long terme et donc la motivation que suppose l'emploi d'une méthodologie, ainsi que les perspectives d'évolution des outils comme support. - le niveau Méthodologies et conduite de projets, qui donne une vision assez large pour l'organisation des développements. La partie 2 donne un aperçu des méthodologies connues dans le domaine des systèmes temps-réel. La partie 7 présente les problèmes et principes essentiels en conduite de projets. - le niveau Manuel de Référence, qui explique en détail les concepts, principes, et démarches pour chaque étape de MCSE. Ce niveau qui constitue le corps du document est l'outil de travail du concepteur. Il comprend: La partie 3, décrivant le rôle et la démarche pour la première étape d'élaboration des spécifications, la partie 4, qui concerne l'étape de conception fonctionnelle, la partie 5 relative à la définition de la réalisation, la partie 6, décrivant les problèmes et techniques pour les réalisations matérielle et logicielle. Un résumé à la fin de chaque chapitre rappelle les points essentiels. Ainsi, après avoir lu le niveau présentation, il est conseillé au lecteur de s'intéresser soit au niveau Méthodologies et conduite de projets, soit au niveau Manuel de Référence, suivant qu'il désire avoir une vue globale du sujet méthodologies et projets d'abord, ou qu'il aspire à approfondir la Méthodologie en vue de s'en servir. Il nous semble d'emblée souhaitable de prévenir le lecteur, que, s'il désire devenir compétent en conception, il s'agit d'un investissement à long terme qui nécessite du temps. Lire un ouvrage ne suffit pas pour mettre en application les concepts lus, il faut aussi développer des projets et prendre le temps de faire une analyse critique des résultats bons et mauvais de manière à enrichir progressivement son expérience.

12

M.C.S.E

Chapitre 2

CARACTERISTIQUES DES SYSTEMES

Ce document concerne les systèmes pour lesquels la réalisation résulte de l'association d'une partie matérielle (électronique) et d’une partie logicielle (informatique). Le terme système désigne la partie à développer qui n'est en fait qu'une partie de l'application. La démarche pour concevoir et développer de tels systèmes dépend de la nature de son environnement et des caractéristiques souhaitées pour l'application. Avant de présenter les principes retenus, il apparaît tout d'abord souhaitable de caractériser les systèmes pour lesquels la méthodologie MCSE a été développée. Aussi, après avoir rappelé l'évolution des techniques et moyens en Electronique et précisé le domaine de l'Informatique Industrielle, ce chapitre présente: les classes de problèmes concernés et les moyens de réalisation pour les systèmes dédiés, les caractéristiques des systèmes temps-réel et les critères de qualité pour un système. 2.1. EVOLUTION DES TECHNIQUES ET DES MOYENS DE REALISATION A partir du transistor puis des circuits intégrés, une évolution considérable de la technologie a conduit à une diversification des techniques disponibles pour la mise en oeuvre des systèmes électroniques. Comme point de repère, notons le passage de l'analogique aux techniques digitales et numériques, puis le passage de la logique câblée à la logique programmée ou

M.C.S.E

13

Partie 1 - PRESENTATION DE LA METHODOLOGIE programmable que constituent les réseaux logiques et les microprocesseurs. Les avantages sont évidents: une structure matérielle donnée permet de résoudre, non pas seulement le problème concerné, mais toute une famille de problèmes. Notons aujourd'hui une distance de plus en plus importante entre les caractéristiques techniques et technologiques de la partie matérielle et les fonctionnalités possibles pour les applications réalisées avec de tels composants. Ainsi, un même support peut servir pour une multitude d'applications, et inversement, une variété de technologies existe pour une même application. La spécification du fonctionnement du système pour une application particulière se définit de plus en plus par programmation. La réutilisation du matériel devient possible, et les possibilités de modification, d'amélioration du produit sont importantes grâce au logiciel. Ainsi, progressivement, d'une solution purement matérielle, progressivement les réalisations ont évolué vers un partage matériel/logiciel avec un accroissement de la partie logicielle. En moyenne, aujourd'hui pour tous types de systèmes confondus, la part du logiciel est estimée à plus de 70%. De ce fait, par les applications, l'Electronique et l'Informatique se trouvent intimement mêlés. Plus récemment, grâce aux techniques et moyens de communication, l'accroissement de la complexité des composants et la diversité des fonctions disponibles ont permis de remplacer les solutions centralisées par des réalisations dont la structure est très proche de la répartition géographique de l'application. Une partie de la complexité est alors prise en charge par un système de communication inter-fonctions. Naturellement, les systèmes auparavant autonomes sont aujourd'hui de plus en plus interconnectés. Toutes ces techniques sont relativement bien connues et maîtrisées. Au fur et à mesure de l'accroissement de la complexité, les objets disponibles sont de plus en plus proches des fonctionnalités désirées, et la mise en oeuvre se simplifie. Un microprocesseur finit par être plus facile à mettre en fonctionnement qu'un étage d'amplification à 2 transistors. Les moyens pour la réalisation des systèmes ont aussi suivi l'évolution des techniques. Si auparavant le poste de travail de l'électronicien se reconnaissait à son instrumentation et à son outillage tel que le fer à souder, il est aujourd'hui beaucoup plus proche de celui de l'informaticien. L'Informatique comme outil de travail est utilisé par tous. Les outils de conception assistée par ordinateur aident les concepteurs à définir, à vérifier, puis à réaliser les composants et systèmes électroniques. En plus de l'utilisation des composants standards, l'électronicien a même la possibilité de développer ses propres composants spécifiques (ASIC). Pour la partie logicielle, le développeur dispose d'une variété d'outils à la fois comme supports: microordinateurs, systèmes informatiques, ou comme moyens de développement: cross-compilateurs, analyseurs de performances, progiciels variés. 2.2. LE DOMAINE DE L’INFORMATIQUE INDUSTRIELLE Les SYSTEMES ELECTRONIQUES (au sens large) entrent dans la constitution d'un grand nombre d'applications. Il n'est pas utile de rappeler ici la diversité des domaines influencées ou concernées par l'Electronique. En effet, comme technique de réalisation, il sert de support pour de multiples activités, contribuant ainsi à améliorer les fonctionnalités, les performances, la sécurité, la souplesse d'exploitation... 14 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES Les techniques mises en oeuvre concernent l’ANALOGIQUE, le NUMERIQUE et la PROGRAMMATION. Aujourd'hui, plutôt que de chercher à cerner la frontière entre l'ELECTRONIQUE et l'INFORMATIQUE, toutes deux considérées sous l'aspect techniques de réalisation, il est plus réaliste de considérer la synergie globale. En effet, pour le premier domaine, les systèmes intègrent de plus en plus de moyens informatiques, et pour le deuxième, calculateurs, capteurs, actionneurs, périphériques, interfaces sont nécessaires comme support de réalisation des applications. Ainsi est apparu durant la décennie passée le domaine de l'INFORMATIQUE INDUSTRIELLE comme discipline intermédiaire. Pour l'Informatique Industrielle, un système est composé de 2 parties: - une partie matérielle, qui est la partie visible. Elle se décompose en une partie analogique pour laquelle tensions et courants ont une importance dans le fonctionnement, et une partie numérique pour laquelle au niveau utilisation, seuls les états logiques ou numériques sont suffisants. La frontière entre les 2 ne dépend que du niveau d'observation, - une partie logicielle, pas directement visible, puisqu'elle se concrétise par des états logiques 1 et 0 dans les mémoires de l'appareil, ou dans des supports de masse. Des matériels spécifiques (informatiques et logiciels) permettent de produire, manipuler de telles informations. La partie analogique est plus ou moins importante suivant l'application. De toute manière, elle existe toujours, car tout système est couplé à son environnement par des interfaces qui véhiculent courants et tensions. D'autre part, certaines fonctions non réalisables par une technique numérique subsistent: émission-réception haute-fréquence, génération et transformation de signaux... La partie numérique est constituée d'un assemblage de composants LSI et VLSI, réalisant chacun une fonction complexe. Ces composants sont de plus en plus programmables, ce qui justifie une architecture bâtie autour d'un ou plusieurs microprocesseurs. La part du logiciel peut varier dans des proportions considérables. De plus en plus, la fonctionnalité est obtenue par le logiciel, tandis que le matériel n'en est que le support d'exécution. A l'extrême, les systèmes informatiques sont considérés comme des supports fonctionnels complets qui permettent de développer une application sans devoir s'intéresser à la partie matérielle. La fonctionnalité globale résulte d'une bonne adéquation entre toutes les parties: assemblage correct de tous les composants, programmation adaptée pour la mise en oeuvre des composants et pour répondre aux spécificités de l'application. Concevoir et réaliser de tels systèmes nécessite donc une compétence technique dans les 3 domaines: Electronique analogique, Electronique numérique ou Informatique industrielle, Informatique. A cela peuvent s'ajouter des compétences complémentaires: en composants intégrés lorsqu'il s'agit d'en concevoir, en électronique de puissance lorsque l'environnement utilise les courants forts, en réseaux et communications lorsque des couplages entre systèmes ou ensembles sont nécessaires... Mais il faut aussi ajouter obligatoirement l'aptitude à cerner les besoins de demandeurs de tous domaines qui requièrent la mise en place d'un système, ainsi que la maîtrise d'une démarche de développement. On peut aisément imaginer la difficulté de cette spécialité, ainsi que la responsabilité de cet homme de l'Informatique Industrielle comme maître-d'oeuvre en développement de systèmes. M.C.S.E 15

Partie 1 - PRESENTATION DE LA METHODOLOGIE 2.3. LES SYSTEMES DEDIES Pour les applications considérées dans le paragraphe précédent, le demandeur sollicite la réalisation d'un système dit "dédié". Il faut entendre par là que le système est développé à un instant donné pour répondre à un besoin bien délimité. Sa durée de fonctionnement est définie: plusieurs années, voire même des dizaines d'années. La pérennité est donc importante. Ainsi, le système est à développer au mieux, directement dans sa version définitive avec la technologie courante. Son évolutivité reste limitée à quelques améliorations pour la même application. Il ne s'agit donc pas d'un système général comme l'est un ordinateur ou un microordinateur, il ne s'agit pas non plus d'un prototype qui démontre un bon fonctionnement à un moment donné. Un système dédié est installé une fois pour toutes. Aussi, la démarche pour le développement doit conduire à une efficacité directe puisque la solution ne résulte pas d'un développement incrémental, résultat d'expériences successives. La technique à mettre en oeuvre se doit d'être juste adaptée et suffisante pour le problème de manière à réduire le coût et le temps de développement ainsi que le coût de reproduction. Les techniques pour réaliser de tels systèmes sont variées: - utilisation de systèmes complets: micro-ordinateur, automate programmable, système de régulation, système de traitement d'images, terminaux, ordinateurs,..., - utilisation de cartes, sous-ensembles et progiciels: cartes à microprocesseurs, alimentation, cartes interface, support de masse, bases de données, générateurs de rapports, système multi-fenêtres... La réutilisation permet de réduire les temps de développement. Elle est strictement nécessaire pour le matériel, car l'utilisateur ne peut pas fabriquer ses composants, et chaque reproduction implique un coût. Moins contraignant pour le logiciel, le concepteur peut vouloir, à tort, développer complètement le logiciel de son application, avec l'argumentation que le programme développé sera bien plus approprié que celui qui résulterait de la réutilisation d'un programme précédent, d'une bibliothèque de logiciel, d'un progiciel plus général... 2.4. LES SYSTEMES TEMPS-REEL Intéressons-nous aux caractéristiques fonctionnelles d'un système à partir des applications. La fonctionnalité est alors expliquée par le vocabulaire de l'application et non par le vocabulaire de la technique mise en oeuvre. Le terme environnement est utilisé pour représenter la partie de l’application exclu le système. L'environnement d'un système électronique dédié est composé d'objets (au sens général) de diverses natures: certains sont physiques, d'autres sont humains. Les objets sont dynamiques; ainsi par leurs actions, ils génèrent des événements, informations, données. De même, ils sont sensibles à des sollicitations externes. En conséquence, fonctionnellement, les systèmes à développer sont dits du type réactif, car ils réagissent sur l'environnement à partir de sollicitations qui en proviennent. La fréquence des sollicitations est alors un paramètre important. 16 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES Pour satisfaire l'objectif qui lui est assigné, le système est couplé à ces objets par des interfaces pour l'observation et la commande. Ainsi, ces systèmes possèdent de multiples entrées et sorties. On voit ainsi apparaître 2 classes d'interfaces: les interfaces homme-machine et les interfaces physiques. Les procédures d'échange entre le système et son environnement doivent tenir compte de la nature de ces interfaces. Comme l'environnement physique est souvent composé de plusieurs activités simultanées, parfois même réparties géographiquement, l'application nécessite l'exploitation d'un système qui assure simultanément: - l'observation de grandeurs pour suivre l'évolution de l'environnement, - la prise en compte d'événements survenant aléatoirement, - l'évaluation de décisions à partir des événements et observations, - la génération d'actions auprès de l'environnement pour assurer la cohérence de l'ensemble de l'application. Du fait de la multiplicité des entrées et sorties qu'il faut suivre globalement, un système électronique doit effectuer des traitements simultanés. Le degré de simultanéité est fonction de la technique de réalisation. Elle est complète lorsque des parties matérielles sont attribuées à chaque traitement. Elle est pseudo-simultanée lorsqu'un processeur partage son activité pour satisfaire plusieurs traitements. Le fonctionnement pour un tel processeur est alors qualifié de multi-tâches. Couplé à son environnement, un système électronique est aussi concerné par le temps de réaction des objets qui l'entourent. La commande d'un ascenseur, d'un chariot filoguidé, d'un avion est intimement liée à la vitesse d'évolution de ces objets. Si les échanges d'informations pour les interfaces du type homme-machine sont plutôt de l'ordre de la seconde ou du 1/10e de seconde, la période de réaction d'un système vis à vis de procédés physiques est plutôt de l'ordre de la milliseconde. Ainsi les temps de réponse requis par les systèmes électroniques sont nettement plus proches de la vitesse de réaction de la technologie mise en oeuvre (100 µs à 1 ms pour les microprocesseurs). De tels systèmes sont qualifiés de TEMPS-REEL. Par définition, un système est dit du type temps-réel lorsqu'il effectue toutes ses activités en respectant des contraintes de temps. En effet, l'interaction importante avec l'environnement fait apparaître plusieurs natures de contraintes de temps, certaines parfois sévères, qu'il s'agit de respecter: - tout d'abord une fréquence élevée pour les sollicitations en provenance de l'environnement: fréquence d'événements, débit en données... - une fréquence élevée pour les actions à entreprendre auprès de l'environnement, par exemple, fréquence élevée pour la commande d'un procédé à faible temps de réponse. - une limite maximale pour le temps de réaction entre l'instant d'apparition d'une sollicitation et l'instant d'achèvement de l'action conséquente (date d'échéance). Le non-respect d'une des contraintes peut conduire l'application dans un état assimilable à un état de panne, ce qui peut engendrer des conséquences très graves, jusqu'à la mise en danger de vies humaines. M.C.S.E 17

Partie 1 - PRESENTATION DE LA METHODOLOGIE Ainsi, les systèmes temps-réel sont différents des systèmes dits interactifs. Ces derniers sont plutôt qualifiés de systèmes "on-line". Couplés à des opérateurs, ils requièrent des temps de réponse courts, qui, s'ils ne sont pas respectés, ne conduisent pas à des conséquences graves. Pour un système de gestion bancaire par exemple, le temps de réponse pour les transactions doit rester faible pour le confort des utilisateurs. Un retard reste supportable s'il n'est que ponctuel. 2.5. QUALITES D’UN SYSTEME Un système peut aussi être observé selon ses qualités, chacune contribuant à satisfaire un objectif spécifique. Un système peut notamment être: - adéquat: son comportement avec l'environnement répond aux souhaits du demandeur, - performant: toutes les contraintes de temps sont satisfaites et les temps de réponse du système sont acceptables, - robuste: le système reste opérationnel, complètement ou en mode dégradé même en présence de fautes ou d'événements non-prévus en provenance de l'environnement. - évolutif: le système favorise l'évolution de ses caractéristiques et de ses fonctionnalités. Ceci est nécessaire pour répondre aux évolutions imprévisibles du cahier des charges. - maintenable: après sa réalisation le système est à conserver en fonctionnement durant la vie de l'application. Les corrections et améliorations font aussi partie des tâches dévolues à la maintenance. - à coût optimal: le développement et la production du système conduisent à un coût convenable et accepté par le demandeur. Ces qualités servent d'objectifs pour tout développement. Ainsi, une méthodologie pour le développement de systèmes temps-réel pour des applications dédiées, doit favoriser la détermination de solutions répondant à de tels critères. 2.6. CATEGORIES DE SYSTEMES Tentons pour conclure ce chapitre d'effectuer un classement des systèmes en se basant sur la technique majeure mise en oeuvre. Pour la classification qui ne peut rester qu'approximative, considérons les disciplines connexes de l'Informatique Industrielle que sont: l'Electronique, l'Automatique, le Traitement du Signal (de la parole et des Images), les Communications, l'Informatique. Sur la figure 2.1, chaque discipline est représentée par un cercle. Les disciplines sont partiellement en recouvrement. Dans ce document, on s'intéresse aux systèmes qui nécessitent la mise en oeuvre de différentes techniques à des degrés plus ou moins importants. Ces systèmes sont représentés dans le cercle correspondant à l'Informatique Industrielle. Sont exclus les systèmes très spécifiques d'un domaine car ils requièrent alors une méthodologie particulière en rapport direct avec les concepts et techniques à mettre en oeuvre de la discipline. Ainsi, sont concernés par la méthodologie MCSE, les systèmes suivants: - les systèmes typiquement électroniques: qui impliquent essentiellement le développement de matériels tels que conception de fonctions et composants, association de fonctions, 18 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES

AUTOMATIQUE

INFORMATIQUE Systèmes

Systèmes de contrôle/commande

interactifs

INFORMATIQUE
Systèmes électroniques Systèmes de communication

INDUSTRIELLE
ELECTRONIQUE

COMMUNICATIONS

Systèmes de traitement

TRAITEMENT DU SIGNAL

-Figure 2.1- Disciplines et classes de systèmes. - les systèmes de contrôle-commande, dominés par des problèmes de suivi et de commande pour des applications incluant des procédés physiques en tous genres à piloter, - les systèmes interactifs concernés par l'exploitation d'interfaces évoluées pour les dialogues homme-machine, - les systèmes de communication: dominés par le transfert de données. Ces systèmes reçoivent, transforment et émettent des flots de messages, - les systèmes de traitement: concernés principalement par les traitements de toute forme d'information: signal, image, parole...

M.C.S.E

19

Chapitre 3

CYCLE DE DEVELOPPEMENT D’UN SYSTEME

Après avoir caractérisé les systèmes par leurs domaines d'application, les techniques mises en oeuvre et les particularités du temps-réel, nous devons caractériser le processus de développement d'une application. Il n'est pas utile de développer en préambule toutes les raisons qui font que, même de bons projets ne convergent pas obligatoirement vers un succès: médiocre organisation, outils inadaptés, manque de méthodes, absence de plans et procédures de test et d'intégration, manque de spécifications, pas d'investissement de la part du demandeur dans le projet. L'objectif plus essentiel est d'exprimer quelle démarche suivre pour développer efficacement le système répondant au besoin du demandeur. Pour caractériser l'activité de développement, celle-ci est tout d'abord replacée dans le contexte de l'entreprise. Un développement est une partie des activités d'un projet, et chaque projet s'intègre dans un objectif d'entreprise. L'obtention de résultats implique la nécessité de disposer d'une démarche pour planifier, organiser et contrôler les développements de projets. Le management de projets nécessite de modéliser le processus de développement lui-même. Le terme général "cycle de vie d'une application ou d'un produit" est utilisé pour décrire un tel type de modèle. Introduit vers 75, ce type de modèle sert de support pour expliciter la procédure à suivre, puis pour effectuer des contrôles.

M.C.S.E

21

Partie 1 - PRESENTATION DE LA METHODOLOGIE Ce chapitre montre que le développement d'un système nécessite une organisation plus complexe que le simple séquencement des étapes de spécification, de conception et de réalisation. De plus, un modèle pour le développement sert aussi de base pour une méthodologie. En fin de chapitre, le modèle proposé pour les systèmes électroniques permet de délimiter le domaine d’intérêt de la méthodologie MCSE. 3.1. CONTEXTE D’UN DEVELOPPEMENT Le terme Développement est utilisé ici pour caractériser l'ensemble des activités techniques qui permettent de passer d'un cahier des charges au produit industriel répondant au besoin. Pour l'entreprise ou l'organisme chargé du développement, ces activités font partie intégrante d'un projet. Un projet est caractérisé: d'une part par des objectifs, d'autre part par son déroulement. Il a un début et une fin qui correspond à la satisfaction des objectifs. Un projet est aussi en interaction avec d'autres activités (ou projets), ne serait-ce que par un partage de ressources. Ainsi, caractériser le contexte d'un développement consiste à positionner celui-ci dans le contexte de l'entreprise comme le montre la figure suivante.

Management de l’entreprise

ENTREPRISE

ACTIVITES

projet i

projets

management du projet

developpement du projet

RESSOURCES

-Figure 3.1- Contexte global d'un développement. L'activité de l'entreprise au sens large concerne un ensemble de projets. Le développement d'une application et d'un système n'est qu'une partie du projet. Pour son activité, l'entreprise dispose de ressources matérielles et humaines qu'elle répartit pour les différentes activités. Pour mieux caractériser l'activité de développement, précisons ce qu'est un projet et son management. 22 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME Un projet est caractérisable par son cycle de vie. Ce cycle débute par une phase d’expression du besoin pour se conclure par une phase de finalisation. En intermédiaire, s’ajoutent 3 phases comme l'indique la figure 3.2: définition du projet, planification et organisation , développement [RUSKIN-82].
Abstrait

Expression du besoin Définition du projet Management du projet Planification organisation

Développement du projet

Achèvement du projet
Concret Temps

-Figure 3.2- Les phases d’un projet.
-A- EXPRESSION D’UN BESOIN

Un projet débute par la nécessité ou le souhait de satisfaire un objectif. L'objectif peut être très varié en nature et forme. Par exemple, il peut s’agir de développer un système de conduite de grands bâtiments, mais l’objectif peut aussi s'exprimer par la volonté d'apporter une aide à la conduite de bâtiments. La première phase concerne donc l'expression d'un besoin pour satisfaire des objectifs, ce qui conduit à exprimer un concept et à identifier des contraintes essentielles. Cette phase n'indique rien sur la manière d'atteindre ces objectifs. Différentes techniques sont utilisables et en particulier les techniques de créativité et d'analyse de la valeur.
-B- DEFINITION DU PROJET

Cette phase concerne une étude préliminaire du projet. Il s'agit tout d'abord de caractériser le projet par une étude de faisabilité sur la base de suppositions sur les différentes manières d'atteindre les objectifs, les critères de décision, les contraintes, les obstacles potentiels, les ressources, budgets et échéances. Il s'agit ensuite de sélectionner l'approche globale à suivre pour satisfaire les objectifs. La définition du projet conduit à une description suffisamment détaillée pour qu’une proposition puisse être élaborée. M.C.S.E 23

Partie 1 - PRESENTATION DE LA METHODOLOGIE La phase de définition du projet nécessite de considérer tous les aspects du développement sans pour cela réaliser le projet.
-C- PLANIFICATION ET ORGANISATION

Lorsque le projet est accepté, les objectifs, le coût et les délais sont fixés. La phase suivante concerne sa planification et son organisation. La planification conduit à élaborer des plans détaillés en identifiant les tâches, les échéances et durées pour chacune, les budgets et les ressources nécessaires pour chaque tâche. Il s'agit aussi d'élaborer l'organisation nécessaire pour exécuter le projet. Cela concerne l'identification des ressources nécessaires en qualité, quantité et durée.
-D- DEVELOPPEMENT DU PROJET

Cette phase constitue la partie technique du travail qui conduit à l'obtention du produit ou de l'application à partir du cahier des charges. Cette phase est détaillée dans le paragraphe suivant.
-E- FINALISATION DU PROJET

Cette activité a pour objectif la vérification de la conformité du produit élaborée vis à vis des objectifs, celle-ci doit se faire si possible tout au long du développement. Une fois le produit achevé, il s'agit d'aboutir à la confirmation que le client est satisfait du résultat. Ce qui se traduit par une recette. La conclusion du projet permet de libérer les ressources utilisées et conduit à un bilan financier. Ainsi, comme l'indique la figure précédente, autour du travail de développement, le management d'un projet concerne précisément les activités de planification et d’organisation, ainsi que la direction du développement et son contrôle. L'objet de la méthodologie MCSE ne concerne pas la partie management de projet. Quelques éléments sont décrits dans la partie 7 de manière à connaitre la complémentarité des activités de conduite de projet et de développement, car le management est basé sur un modèle du processus de développement qui est le cycle de développement ou plus communément le cycle de vie du produit. 3.2. LES PHASES D’UN DEVELOPPEMENT Le cycle de vie pour une application ou un produit est une représentation purement descriptive. Il décompose le processus de développement selon une série d'activités couplées entre elles, partant du besoin initial pour aboutir au produit opérationnel. Le terme cycle est lié au fait que, habituellement, tout produit développé engendre de nouveaux besoins. Plusieurs modèles ont été élaborés. Avant de s'intéresser aux différences entre eux, notons que tous ont en commun les phases essentielles de tout développement. Ainsi, avec quelques variations en fonction des auteurs, on distingue, au minimum 5 phases: - définition ou spécification, - conception, - réalisation, - production, - fonctionnement. On donne ci-après la signification usuelle pour chacune de ces phases. 24 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME
-A- DEFINITION ET SPECIFICATION

Un projet résulte généralement d'une demande formulée sous la forme d'un document décrivant les besoins. Le document est appelé Cahier des Charges. Pour l'équipe réalisant, c'est une base de départ, pour exprimer une proposition qui se doit de contenir l'ensemble des spécifications. Si certaines descriptions du cahier des charges paraissent claires pour le demandeur, un tel document ne contient habituellement que peu de détails, ce qui le rend insuffisant pour caractériser le projet complet. Ainsi, durant la phase de définition, les objectifs auxquels doit satisfaire le système final sont recensés. Il s'agit d'obtenir une description détaillée du comportement externe du système. Cette description exprime les fonctions à remplir, les contraintes à respecter, les interfaces à exploiter, toutes les informations complémentaires précisant la taille du système, la vitesse d'exécution, les performances et autres caractéristiques à satisfaire...
-B- CONCEPTION

Le travail de conception consiste à passer des spécifications à une définition de la réalisation, c'est-à-dire aux documents nécessaires pour entreprendre la réalisation. Au départ, le concepteur exploite directement les spécifications pour déduire une décomposition en termes de fonctions. Au fur et à mesure que des décisions sont prises, le raffinement se poursuit en exprimant comment chaque fonction considérée comme "boîte noire" contribue à atteindre les objectifs. Ceci est une vue simplifiée, car pour concevoir il faut passer par plusieurs stades intermédiaires. Pour chaque stade, toute spécification est transformée en une réalisation correspondante et par une suite de décisions. Si ce schéma est maintenant classique en particulier pour des projets logiciels, les stades intermédiaires par lesquels il est judicieux de passer, dépendent de la classe des problèmes traités. Pour la catégorie des systèmes temps-réel que nous considérons dans ce document, la conception doit produire simultanément la définition des solutions matérielle et logicielle, ce qui complique la démarche.
-C- REALISATION

La phase de réalisation concerne le développement du matériel, celui du logiciel, puis l'intégration du logiciel sur l'infrastructure matérielle. Cette réalisation aboutit à un ensemble en état de fonctionnement reproductible industriellement et répondant aux spécifications du problème.
-D- PRODUCTION

Cette phase concerne tout d'abord l'expérimentation d'un prototype pour évaluer ses caractéristiques. La mise en production découle ensuite de cette évaluation. Des critères complémentaires d'industrialisation sont introduits à ce stade.
-E- FONCTIONNEMENT

Une fois le produit développé en série et commercialisé, il se retrouve en fonctionnement. Débute alors la phase d'exploitation qui implique bien entendu une maintenance. Diverses maintenances sont possibles: corrective pour exclure les erreurs résiduelles, adaptative pour tenir compte des exigences nouvelles, préventive pour augmenter la fiabilité des systèmes. M.C.S.E 25

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les 2 dernières phases ne font pas obligatoirement partie du projet. Mais quelle que soit l'organisation, la responsabilité incombe dans tous les cas à l'entreprise. D'autres groupes ou services peuvent par exemple avoir en charge la production et la maintenance des produits développés. 3.3. MODELES DE CYCLE DE VIE En plus de l'intérêt d'une structuration du travail, la décomposition du projet en étapes facilite le contrôle du développement en définissant pour chacune des phases des objectifs à atteindre planifiables et mesurables. Un modèle pour le développement sert donc de base pour la conduite de projet. Plusieurs modèles ont été proposés pour représenter l'enchaînement des phases de développement. Nous décrivons dans la suite les modèles les plus caractéristiques présentés pour le développement de logiciels. 3.3.1. Le Modèle "Waterfall" Ce premier modèle décrit le cycle de vie comme une succession d'étapes conduisant à trouver des niveaux de description, du problème jusqu'à la réalisation, en partant de la définition jusqu'à l'exploitation et la maintenance [BOEHM-76].

SPECIFICATION

Corrections

CONCEPTION PRELIMINAIRE

CONCEPTION DETAILLEE

REALISATION

-Figure 3.3- Le modèle Waterfall. Chaque étape est liée à l'étape suivante pour représenter l'enchaînement, et à l'étape précédente pour représenter les corrections par retour-arrière. A chaque étape est associée une phase de vérification ayant pour but de s'assurer de la conformité de la solution retenue aux 26 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME spécifications en entrée de l'étape. Un défaut de conformité implique de reprendre l'étape ou de revoir le résultat de l'étape précédente. Ce modèle fait déjà apparaître qu'un développement ne peut pas se faire exclusivement selon une démarche purement descendante. Comme le suggère la théorie de la commande en boucle fermée, les incertitudes ou erreurs et omissions sont corrigées par des retours-arrières dès l'observation d'écarts. Bien sûr, ceci n'est possible que si, à l'issue de chaque étape, le résultat est observable et comparable à un objectif. Un accroissement important de l'effort de validation durant les premières phases favorise une correction rapide des premières erreurs, sinon celles-ci conduisent par la suite à un coût de correction considérable. Un peu limité, ce modèle ne prend que très partiellement en compte la vraie nature du développement, c'est-à-dire son caractère itératif. 3.3.2. Le cycle en V Ce modèle considère en supplément les phases de vérification et d'évaluation du projet pour chaque stade de sa réalisation. Il montre bien que la démarche de spécification-conception est globalement descendante tandis que la phase de réalisation-test est globalement ascendante, car il s'agit d'assembler les constituants pour obtenir les fonctionnalités. La figure suivante présente un exemple type de plan de développement.
Spécification
BESOIN
CERTIFICATION

Conception - developpement

Test et évaluation

fonctionnement maintenance
PRODUIT Evaluation et test opérationnel

Cahier des charges

Spécification système

VALIDATION

Test d’intégration système

Spécification logiciel performances

VALIDATION

Tests de performances

Spécification
Conception préliminaire Corrections
VERIFICATION

Validation
Test intégration

conception

Conception détaillée

Test unitaire

Réalisation

Code

Programme codage

Mise au point

-Figure 3.4- Exemple de cycle de vie en V. L'axe horizontal représente les phases du projet et la durée de chacune. L'axe vertical représente le niveau d'abstraction pour l'application. Les phases de spécification et de conception conduisent à définir des niveaux de description de plus en plus détaillés. Pour une M.C.S.E 27

Partie 1 - PRESENTATION DE LA METHODOLOGIE application logicielle, le codage est la forme la plus détaillée. Les phases d'intégration, de test et de vérification, permettent d'évaluer la conformité de la réalisation pour chaque niveau de la conception en commençant par les parties les plus élémentaires puis en remontant progressivement jusqu'au produit complet. Pour cela, en correspondance de chaque phase de la conception est associée une phase de test et d'évaluation de la conformité. Les 2 démarches descendante et ascendante sont complémentaires. Ce modèle favorise une planification des dates de production et de lecture de documents à l'issue de chaque phase, des échéances pour les procédures de vérification-validation. Toutefois, il est plutôt spécifique d'un développement logiciel. 3.3.3. Le Modèle "Spirale" Les modèles précédents concernent la création d'un seul produit. Ils n'apparaissent pas très appropriés pour la description d'un ensemble de produits et d'activités autour de ces produits: faisabilité, prototypage... Le modèle Spirale [BOEHM-86,WILLIAMS-88] décrit le développement comme un processus itératif selon 4 phases, permettant de combiner différentes approches: expression des besoins, faisabilité, prototypage, développement du produit final.
DETERMINATION DES OBJECTIFS , DES CHOIX ET CONTRAINTES. COUT CUMULE EVALUATION IDENTIFICATION RESOLUTION

Analyse des risques

Analyse des risques prototype Analyse des risques prototype R proto A type concept d’ opération Validation des besoins prototype opérationnel

plan du cycle de vie plan de developpement Integration et test

besoin logiciel conception logicielle

conception detaillée

Validation de la conception et vérification test

test code uniintégration taire et test DEVELOPPEMENT VERIFICATION NIVEAU N+1 DU PRODUIT

PLANIFICATION DES PHASES SUIVANTES

implémentation

conformité

-Figure 3.5- Le Modèle Spirale. Les 4 phases, une par quadrant, concernent: - la planification des phases ultérieures, - la définition des objectifs, des variantes et des contraintes, - l'évaluation de solutions, analyse des risques, - le développement et la vérification du produit. La distance de tout point de la courbe au centre représente le coût cumulé qui a conduit à un tel stade du développement. 28 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME 3.3.4. Le modèle "Contractuel" Tout développement implique une interaction entre le client et les concepteurs. Ce modèle présente ce point de vue. Chaque phase du développement est considérée comme le sujet d'un contrat entre les 2 parties: le client et le fournisseur (concepteurs) [COHEN-86].

Phase

Client
Besoins du client
non

Fournisseur

Besoin (non formel)

analyse

Analyse des besoins
oui

Modèle formel Comportement acceptable ?
non preuve

Adéquat analytiquement ?
oui

Spécification formelle

Besoin conception
non

conception

Conception

Comportement équivalent ?
preuve

non

Architecture fonctionnelle

Adéquate

Proposition
oui

et réalisable ?
oui

de
Besoin réalisation

conception

Construction

non

Schéma
non

Implémentation
Comportement adéquat ?

preuve

Proposition
oui oui

Réalisable ? reproductible ?

d’implémentation

-Figure 3.6- Le modèle contractuel. Une phase du développement conduit à passer d'une description à la description suivante. La validation du résultat est faite par le client. L'achèvement de chaque phase est signalé par un accord du client signifiant que la fourniture satisfait les termes du contrat. M.C.S.E 29

Partie 1 - PRESENTATION DE LA METHODOLOGIE Ainsi, ce modèle montre que le concepteur est dans la situation de devoir découvrir quelque chose qui donnera satisfaction au client. La première phase apparait particulièrement délicate puisqu'elle consiste à formaliser le souhait du client sans que celui-ci l'exprime clairement et complètement. 3.4. QUELQUES CONSTATATIONS 3.4.1. Recouvrement des phases Les modèles précédents tendent à induire l'idée que les phases sont nettement identifiées et séparées. La réalité est plus complexe. Initialement durant chaque phase, des retours-arrière conduisent à modifier ou à compléter des décisions prises dans les phases précédentes. Il y a donc nécessairement recouvrement des phases comme l'indique la figure suivante [HATLEY87]. Ainsi, par exemple, la conception débute sans que la spécification ne soit complètement achevée.
Effort

Spécification

conception

réalisation

test

Temps

-Figure 3.7- Recouvrement souhaitable des phases. Cette figure montre que toutes les phases débutent presque simultanément mais avec un effort qui varie en fonction de la progression. Entre autres, on peut remarquer que la phase de test débute très tôt. En effet, durant les premières phases, l'objectif est de préparer les critères et procédures de test et de validation. Ceci peut conduire à prendre rapidement des décisions particulières en conception, ou à la nécessité de développer un système de test. De même, il est habituel de constater que les spécifications ne sont que rarement achevées car des évolutions apparaissent côté demandeur. 30 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME 3.4.2. Coût de correction des erreurs La réduction des coûts et délais passe par la réduction des erreurs. Or il est aisé de comprendre que les erreurs détectées très tard dans le cycle de vie et en particulier durant la production et le fonctionnement sont difficiles à cerner et à corriger. Elles sont aussi d'autant plus coûteuses qu'elles peuvent concerner des décisions premières essentielles: spécifications, performances, besoin. La figure ci-après illustre le coût exponentiel de la correction des erreurs.
Coût
Echelle log 10 000

Coût de corrections
1000

100

10

1

0.1

Instant de détection des erreurs

Spécification

conception

Réalisation

Production

Exploitation

-Figure 3.8- Courbe du coût de correction des erreurs. Les erreurs de réalisation se détectent rapidement et se traduisent par une correction au niveau de la conception détaillée. Les erreurs détectées en industrialisation production sont plus complexes et impliquent une mise en cause de la conception préliminaire et même certaines spécifications. Les erreurs observées durant l'exploitation sont particulièrement graves car elles concernent une mise en cause de l'adéquation du produit au besoin. 3.4.3. Facteurs de Productivité L'efficacité est source de productivité. Elle dépend d'une variété de paramètres liés au problème, aux techniques et moyens mis en oeuvre, aux méthodes. La figure 3.9 indique le résultat d'une analyse faite par Barry BOEHM, indiquant la contribution d'un ensemble de facteurs à la productivité. Elle montre clairement la faible contribution des facteurs d'expérience: langages, moyens et même application. Le facteur essentiel est la compétence de l'équipe. Cette compétence est très intimement liée aux méthodes utilisées, d'où l'intérêt économique à long terme d'un investissement pour la maîtrise de méthodes. M.C.S.E 31

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Expérience du langage Containtes de délai Taille base de données Temps de réponse Expérience des moyens Evolution des moyens Outils logiciels Programmation haut niveau Contraintes taille mémoire Expérience de l’application Contraintes temps réel Complexité du produit COMPETENCE DE L’EQUIPE Productivité du Logiciel Paramètres affectant la productivité en developpement logiciel.

-Figure 3.9- Facteurs affectant le coût du logiciel. Les autres facteurs: contraintes de temps, fiabilité exigée, complexité du produit, ont tout de même une importance pour les systèmes temps-réel. Une méthodologie doit donc permettre de gérer la complexité tout en conduisant à un produit possédant qualité, fiabilité et sécurité exigées et respectant les contraintes de temps. 3.4.4. Répartition de l'effort Pour atteindre son objectif, le concepteur a un minimum de travail à entreprendre qui correspond au temps d'analyse, de synthèse, de vérification, d'expérimentation. Toute variation par rapport à ce minimum est grandement dépendante de la méthode utilisée. En l'absence de méthode, une approche plutôt intuitive conduit à commencer rapidement la réalisation. La solution résulte alors plus d'une démarche par essais, erreurs et corrections. La détection des erreurs et leurs corrections engendrent inévitablement un surcroît en temps et argent. Dans l'hypothèse d'une méthode, le découpage en étapes n'est pas suffisant. Il faut aussi s'intéresser à l'amplitude de l'effort pour chaque phase. Bien sûr, la répartition dépend de la nature du problème, mais aussi de la stratégie de développement souhaitée. Si certaines stratégies tendent à être connues à travers les principes de l'approche structurée et l'exploitation de langages de haut-niveau, ce n'est pas le cas pour toutes les phases du cycle de vie, en particulier les premières. En effet, les activités de spécification et de conception sont peu visibles et peuvent être jugées comme improductives. La tendance naturelle est de penser 32 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME qu'ingénieurs et techniciens sont plus efficaces et plus productifs lorsqu'ils sont affairés sur des cartes électroniques ou sur leurs programmes que lorsqu'ils élaborent au préalable des documents de spécification et de conception. Pour réduire au minimum possible le coût des erreurs et pour obtenir de l'efficacité en réalisation, l'effort doit être porté sur les premières phases à savoir: la spécification puis la conception. La figure suivante montre 2 stratégies opposées. L'effort à chaque instant exprime les ressources humaines attribuées au développement. L'intégrale de cet effort donne une image de l'investissement pour le projet.
Effort par unité de temps

effort important en spécification effort en réalisation

2

1

Phases

Spécification

Conception

Réalisation

Test

-Figure 3.10- Répartition de l'effort. La courbe 1 correspond à une démarche traditionnelle pour laquelle un effort important est investi durant la phase de réalisation. Ceci correspond au fait qu'une grande partie du travail d'analyse finit par être entrepris à ce stade. La courbe 2 stipule la nécessité d'un effort important en spécification puis en conception. L'investissement supérieur en ressources dès les premières phases pour la courbe 2, est ensuite très largement compensé par une réduction du coût pour les phases de réalisation, test, production, maintenance. De l'analyse qui précède, il s'en déduit qu'il est vital de contrôler le mieux possible le processus de développement. De surcroît, la planification, l'organisation, la direction, et le contrôle du développement sont aussi essentiels pour le succès du projet. 3.5. DEVELOPPEMENT POUR UN SYSTEME ELECTRONIQUE Après avoir analysé quelques modèles d'organisation pour le développement d'un produit, ainsi que certains points essentiels qui influent sur le déroulement, intéressons-nous plus particulièrement à la procédure pour le développement des systèmes électroniques pour les applications temps-réel, de manière à caractériser le modèle de développement retenu pour MCSE. M.C.S.E 33

Partie 1 - PRESENTATION DE LA METHODOLOGIE Rappelons tout d'abord que les systèmes électroniques sont constitués de 2 grandes parties: -le matériel et le logiciel-, et que la cohérence des 2 parties est essentielle pour les systèmes dédiés. Ensuite, pour gérer la complexité, un système se décrit suivant un ensemble de niveaux hiérarchiques: définition, description externe, description sommaire, description détaillée. Pour tenir compte de ces aspects, le développement d'un projet doit être vu comme un ensemble hiérarchique de développements. Au sommet, les premières phases concernent la spécification et la définition préliminaire du système global. Ceci permet de mettre en évidence des sous-ensembles. Chaque sous-ensemble correspond à un domaine plus restreint de problème, et se développe alors de la même manière en commençant par sa spécification. Les développements de sous-ensembles peuvent se faire en parallèle. Ainsi, le processus de développement pour un système électronique peut se représenter comme suit. Cette figure indique que la conception suit des niveaux hiérarchiques qui vont du fonctionnel au physique.
SYSTEME

définition réalisation Problème Etude Cahier Spécification préliminaire des charges conception fonctionnelle
Sous-ensemble i

Assemblage Test Validation

Produit

SOUS-ENSEMBLE

Domaine de

MCSE

définition réalisation Spécification conception fonctionnelle Matériel Logiciel

Intégration Test

MATERIEL

LOGICIEL

Définition Réalisation Spécification conception
composant i carte i

Assemblage Test

conception Spécification fonctionnelle

Définition Réalisation
Tache i Module i

Assemblage Test

CARTE , COMPOSANT

TACHE , MODULE

Spécification conception

Réalisation

conception Spécification conception préliminaire détaillée

Test unitaire

-Figure 3.11- Modèle hiérarchique pour le développement d'un système. Durant le premier stade de la conception, un système complexe est décomposé en sousensembles interconnectés. La conception de chaque sous-ensemble conduit à mettre en évidence une partie matérielle et une partie logicielle. Toujours en passant par une spécification puis une conception, la partie matérielle est décomposée en un ensemble de fonctions ou composants. Les composants, s'ils existent, sont directement utilisables, sinon il s'agit de les concevoir. La hiérarchie pour le développement du matériel s'arrête lorsque tous les 34 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME composants retenus existent. La réalisation est alors possible, puis progressivement l'assemblage et le test en remontant la hiérarchie. De même la partie logicielle est décomposée en tâches ou modules. Chaque partie se développe selon une démarche descendante: conception et programmation structurée. Les modules codés sont testés puis assemblés. Cette présentation suggère un certain nombre de remarques. - Observant la hiérarchie, on constate que toute réalisation est un constituant développé comme un tout mais intégrable dans un ensemble plus complexe. - Chaque constituant se développe selon un processus iteratif: analyse, synthèse, vérification, et si nécessaire correction par retour arrière. - Pour chaque constituant, on retrouve les phases de spécification, de conception, de définition de la réalisation, d'assemblage et de test. Ainsi, la terminologie: spécification, conception, réalisation- n'est pas liée au niveau de description. Une grande confusion existe sur la définition de ces termes particulièrement entre spécification et conception. On retiendra dès à présent que , d’une manière générale, 'une spécification concerne une vue externe de l'objet considéré, tandis que les phases ultérieures concernent l'intérieur, donc la solution. - Si au sommet de la hiérarchie l'approche est globale (approche système), en descendant dans la hiérarchie, le concepteur d'un constituant devient de plus en plus spécialiste d'un domaine et d'une technique de réalisation: par exemple, conception d'un composant ASIC pour le filtrage d'un signal, ou développement d'un programme effectuant une transformée de FOURIER rapide... - Les développements de constituants peuvent se faire en parallèle. La contrainte nécessaire est d'être capable d'élaborer la spécification de chaque constituant pour permettre l'intégration ultérieure. Une démarche ascendante est aussi possible. Elle consiste alors à élaborer un constituant pour son utilisation ultérieure. Il faut dans ce cas s'assurer que le constituant est intégrable dans un ensemble plus vaste. - Un système ne devient opérationnel que lorsque tous ses constituants sont réalisés et testés. Le constituant le plus complexe est le système lui-même. La réalisation est donc un processus ascendant. Pour un objectif à atteindre à une date donnée, une planification (diagramme PERT par exemple) du projet n'est possible qu'une fois effectuée toute la décomposition. Une modélisation précise du processus de développement est donc bien utile pour la planification et donc la conduite de projet. 3.6. DOMAINE DE MCSE La figure précédente permet aussi de préciser le domaine et les niveaux de développement couverts par MCSE. Il s'agit bien d'une méthodologie globale puisqu'elle considère comme point de départ le besoin exprimé par un cahier des charges. Elle couvre les phases de spécification, de conception et de définition des réalisations aussi bien au niveau système que pour les parties matérielle et logicielle. M.C.S.E 35

Partie 1 - PRESENTATION DE LA METHODOLOGIE Toutefois, comme indiqué au début du chapitre, elle ne couvre pas la phase initiale ou phase de définition du projet, qui concerne l'évaluation de la faisabilité, une analyse de la valeur, la négociation. Le point de départ est l'existence d'un produit à développer défini par des objectifs, un coût et des délais. Toutefois, la maîtrise de la méthodologie proposée peut grandement faciliter l'étude préliminaire. Elle ne couvre pas non plus les derniers niveaux de conception qui concernent la réalisation de fonctions spécifiques. Pour le matériel, il peut s'agir de composants ou sous-ensembles qui requièrent une compétence spécifique d'un domaine: électronique de puissance, électronique analogique... Pour le logiciel, il s'agit du développement de programmes réalisés individuellement (programming-in-the-small par opposition à programming in the large [NIELSEN-88]). MCSE ne concerne pas les niveaux relativement proches de la réalisation, ceci n'est pas un inconvénient, puisque déjà des outils de production automatique existent: CAO électronique et compilateurs de silicium pour les composants et cartes, cross-compilateurs pour les programmes. A noter que la méthodologie conduit à élaborer les documents nécessaires en entrée de ces outils, ce qui est le point essentiel. Il ne s'agit pas non plus d'une méthodologie pour la conduite de projets. Les tâches de management pour un projet: planification, organisation, dotation en personnel, direction et contrôle, ne sont pas explicites dans MCSE, mais bien entendu, le modèle hiérarchique proposé pour le développement est très utile comme base pour l'élaboration d'une stratégie de conduite de projets. Le domaine d'intérêt de MCSE est donc essentiellement le développement de systèmes et tout particulièrement la spécification et la conception, et ceci pour les niveaux: système ou application globale, architecture matérielle, architecture logicielle.

36

M.C.S.E

Chapitre 4

BASES POUR UNE METHODOLOGIE

Une méthodologie va au-delà d'un simple découpage du travail en étapes. Pour aboutir à une compréhension correcte et complète de MCSE et avant de s'intéresser à ses caractéristiques, il est utile d'avoir à l'esprit ce que veut dire et ce qu'implique le terme méthodologie. Plusieurs aspects sont développés dans ce chapitre. Tout d'abord concevoir est une activité humaine avec tous ses avantages et inconvénients. Ensuite, une méthode ne décrit pas une solution, mais comment aboutir à un résultat. Toute méthode est donc dépendante de la nature de la solution à trouver; ceci induit la nécessité d'un modèle de description de toute solution. Ainsi, ce chapitre montre la complémentarité: modèles, méthodes, techniques et outils en conception. L'ensemble une fois organisé constitue une méthodologie. 4.1. TERMINOLOGIE Définissons tout d'abord les termes utilisés dans ce document qui, sans explication, pourraient prêter à confusion. 4.1.1. Problème: définition, résolution Le terme PROBLEME est toujours relatif à un sujet, une situation. Autour de ce terme existent 2 classes d'activités: la définition du problème (Que veut-on?, que faut-il? le WHAT), la résolution du problème (Comment peut-on le faire? le HOW).

M.C.S.E

37

Partie 1 - PRESENTATION DE LA METHODOLOGIE Un problème peut être bien défini ou mal défini. Lorsqu'il est bien défini, seule existe l'activité de résolution: c'est le travail du concepteur. Par contre, pour un problème mal défini, les 2 activités sont nécessaires. Il faut tout d'abord commencer par définir le problème pour pouvoir ensuite le résoudre. Résoudre un problème consiste à analyser la situation dans laquelle existe le problème, déduire des décisions possibles sur ce qu'il faut faire ou ne faut pas faire, puis décider d'une solution. 4.1.2. Modèle et modélisation La modélisation est une activité que nous faisons tous, consciemment ou inconsciemment. Elle précède toute décision ou formulation d'une opinion. Ce n'est pas une fin en soi. Elle doit servir à répondre à la question initiale pour laquelle un modèle est développé. Un MODELE est une interprétation explicite par son utilisateur de la compréhension d'une situation, ou plus simplement de l'idée qu'il se fait sur une situation. Il peut être exprimé par des mathématiques, des symboles, des mots, mais essentiellement, c'est une description d'entités et de relations entre elles. Ainsi, modéliser revient à élaborer une vue partielle plus ou moins abstraite de l'existant [WILSON-86]. 4.1.3. Méthode et méthodologie Une méthode ou technique de résolution de problème est caractérisée par un ensemble de règles bien définies qui conduisent pour le problème à une solution correcte. Une méthodologie, terme plus large que méthode, est un ensemble structuré et cohérent de méthodes, guides, outils permettant de déduire la manière de résoudre un problème. Une méthodologie conduisant à utiliser des techniques permet de déterminer si une technique particulière est appropriée ou non. Elle résulte donc de l'agrégation de méthodes et de techniques de divers domaines. Une méthodologie de conception exprime plus particulièrement le cheminement par étapes successives et les outils qui permettent de développer avec efficacité une solution pour le problème posé et qui respecte des critères de qualité. 4.2. CARACTERISATION DU TRAVAIL DE CONCEPTION 4.2.1. La Conception: une activité humaine L'activité de conception est un processus de prise de décisions. Réalisée par l'homme, c'est une activité individuelle créatrice, qui se base sur l'utilisation d'acquis et non sur l'intuition [JENSEN-79]. Toute démarche normale consiste à: formuler le problème, analyser le problème pour faire apparaître suffisamment de détails, rechercher des solutions potentielles, déduire la solution la plus appropriée en évaluant et comparant des solutions entre elles, - décrire en détail la solution retenue. L'acquis concerne 2 catégories d'informations: 38 M.C.S.E -

Ch 4 - BASES POUR UNE METHODOLOGIE - les connaissances dans un ou plusieurs domaines. Elles sont acquises progressivement, et concernent la description, le comportement, les propriétés de l'existant. - les méthodes et techniques. Elles s'acquièrent et s'assimilent aussi très progressivement en résolvant des problèmes. Ces 2 catégories a priori très éloignées sont complémentaires et indispensables pour l'activité de développement: les connaissances apportent les informations nécessaires pour prendre des décisions, tandis que méthodes et techniques structurent la séquence des décisions. Ainsi comme le montre la figure ci-dessous, l'activité de conception est assimilable à un processus de transformation, exprimé par un ensemble d'actions liées, nécessaires pour passer du problème à une solution.
CONNAISSANCES DU DOMAINE METHODES ET TECHNIQUES

PROBLEME

SOLUTION

Résolution du problème

Acquis

Expérience

-Figure 4.1- Processus de résolution de problèmes. La résolution de problèmes améliore l'acquis en enrichissant l'expérience. Celle-ci a la particularité d'être réutilisable. Disposer de connaissances, méthodes et techniques n’est pas suffisant, l'important pour un concepteur est de savoir utiliser l’ensemble judicieusement compte-tenu du problème. L'expérience représente cette compétence. Comme elle est personnelle, chaque concepteur ne l'acquiert que par un travail individuel. Pour résoudre des problèmes, le concepteur doit avoir des qualités minimales que sont: - l'aptitude à raisonner qui est important pour l'analyse et la prise de décision, - l'aptitude à acquérir des connaissances: curiosité, esprit de synthèse, - l'aptitude à communiquer, car il s'agit de résoudre le problème du demandeur. Comme l'activité de conception est individuelle, le problème doit être décomposé jusqu'à un stade accessible par chacun et tel que la communication soit possible. Pour un même projet, toutes les contributions doivent pouvoir s'intégrer, ce qui est l'objet d'une méthodologie, d'une démarche, de procédures. M.C.S.E 39

Partie 1 - PRESENTATION DE LA METHODOLOGIE De plus, particularité de l'activité humaine, elle est source d'erreurs. Des vérifications sont donc nécessaires pour réduire les erreurs de conception. Une autre manière différente mais complémentaire, de voir l'activité de conception est de considérer qu'elle est décomposable en 2 sous-ensembles couplés [WILSON-86]: - un système d'activités, représentatif des méthodes, techniques, ou d'une méthodologie, - un système social, représentatif des participants à l'activité de conception. Ce point de vue est parlant, car il suggère qu'avec un système d'activités satisfaisant, les résultats peuvent être mauvais. Inversement, sans système d'activités, il est possible d'obtenir des résultats mais sûrement avec moins de garantie. Un résultat satisfaisant n'est possible que si le système social et donc les individus en tant que concepteurs utilisent correctement les méthodes ou techniques. Ainsi, lorsqu'une méthodologie est jugée nécessaire, une responsabilité supplémentaire incombe alors à l'organisation qui a en charge l'équipe. Sans une forte volonté interne, les chances de succès sont réduites. 4.2.2. Le processus de conception Pour caractériser une méthodologie, il s'agit de modéliser le processus de conception [DASGUPTA-89]. Elle est classiquement faite sous la forme d'une succession d'étapes [KOOMEN-85]. Une forme de description de la solution sert d'interface entre 2 étapes successives. Entre chaque étape, les informations de description comme intermédiaire sont de 2 natures: - des données formelles (m): spécification, diagrammes, schémas, composants... - des données moins formelles (c): texte, description, contraintes... Au début d'un projet les informations disponibles sont toutes de nature informelle. Durant la conception, elles sont progressivement transformées en données formelles, certaines restant encore informelles. Celles-ci sont appelées contraintes puisqu'elles agiront plus tard sur le résultat final. Ainsi, concevoir consiste à accroître, étape par étape, le niveau de détail de la description formelle, en intégrant progressivement les contraintes décrites par la partie informelle, jusqu'à faire disparaître toutes les contraintes. De cette manière, la solution finale est observable comme un ensemble de niveaux hiérarchisés correspondant à la séquence des descriptions. A chaque transition entre 2 niveaux de description correspond une étape, comme le montre la figure 4.2. Mi composée de mi et ci est la description de la solution pour le niveau i. Une spécification (S) est considérée comme une description formelle du besoin et les propriétés et contraintes du système, tandis qu'une réalisation (R) (ou solution) est une description formelle d'une structure de constituants qui satisfait ces spécifications. La transformation S-->R nécessite de la part du concepteur l'utilisation de connaissances Ki et de méthodes Di. La vérification de conformité de R vis à vis de S est une condition essentielle pour réduire les erreurs. L'enchaînement des étapes impose qu'une réalisation en sortie d'une étape soit utilisable comme spécification pour l'étape suivante. Selon cette modélisation, on constate bien que le travail durant la conception est plutôt de nature créative. Dans certains cas particuliers, il peut être du type transformation; alors formalisable, la transformation peut s'effectuer automatiquement. 40 M.C.S.E

Ch 4 - BASES POUR UNE METHODOLOGIE

CONCEPTION

Mi = Etape précédente (mi,ci)
Spécification

Mi+1 = Di (mi+1,ci+1)
Réalisation

Etape suivante

S

Ki

R

CONNAISSANCES

-Figure 4.2- Une étape durant la conception. 4.2.3. Raffinement et abstraction La démarche pour passer d'un niveau de description à un autre est possible dans les 2 directions, l'une vers un accroissement des détails (raffinement), l'autre vers la réduction de détails (abstraction). Pour chaque direction, on peut exprimer des règles de dérivation d'une solution qui peuvent servir comme base pour une méthode: pour le raffinement: - miroir: un modèle de l'environnement est placé dans le système, - enrichissement: des descriptions sont ajoutées à l'état courant, - décomposition: des fonctions sont décrites par des sous-ensembles plus élémentaires, - association: il s'agit d'une composition qui suit un travail de décomposition et/ou d'enrichissement. Ainsi raffiner une description consiste à augmenter le niveau de détail par ajoût d'informations supplémentaires qui interviennent ultérieurement comme des contraintes pour la réalisation. pour l'abstraction: - simplification: (opposé à enrichissement), des descriptions sont retirées pour réduire la complexité. - composition (opposé à décomposition), plusieurs ensembles de descriptions sont combinés en un seul. - réduction: des descriptions sont remplacées par une description équivalente moins détaillée. La démarche par abstraction permet de décrire un élément par une vue purement externe pour le rendre utilisable dans un ensemble à un niveau de description plus élevé. La technique du raffinement favorise une démarche DESCENDANTE du problème vers la solution détaillée, tandis que la technique d'abstraction se justifie plutôt comme démarche ASCENDANTE. M.C.S.E 41

Partie 1 - PRESENTATION DE LA METHODOLOGIE 4.3. CARACTERISTIQUES D’UNE METHODOLOGIE Une méthodologie est donc tout d'abord l'expression d'un cheminement par étapes, qui permet d'atteindre l'objectif avec efficacité et en respectant des critères de qualité. Le processus de développement est décomposé en étapes. Le résultat observable entre 2 étapes permet sa vérification ce qui est essentiel pour éliminer au plus tôt les erreurs inévitables induites par l'activité humaine. Dans ce chapitre, il a été montré que le processus de conception consiste à trouver une description plus détaillée à partir des données d'entrée prises comme spécifications. A partir de ces bases, précisons les caractéristiques d'une méthodologie. 4.3.1. Modèle de description Observant que l'enchaînement des étapes n'est possible que si le résultat en sortie d'une étape est utilisable comme spécification pour l'étape suivante, et qu'un niveau de description qui résulte d'une étape est un raffinement du niveau précédent, une méthodologie globale allant d'un problème à sa réalisation est obligatoirement basée sur un modèle de description hiérarchique. Le modèle pour chaque niveau de description joue alors le rôle de contrainte pour la description de la solution en sortie de l'étape qui la produit. Sur la figure 4.3, Si et Ci constituent les spécifications pour l'étape i. Ainsi la description de la solution retenue Ri doit être conforme au modèle de description MDi. Si+1 correspond à tout ou partie de Ri. Comme remarque, notons que toute solution respectant le modèle possèdera les caractéristiques et propriétés du modèle.

MD1 S1

Modèle de description

Etape 1
C1 R1

niveau 1

Description
MD2 S2

Etape 2
C2 R2

niveau 2

-Figure 4.3- Enchaînement d'étapes et niveaux de description. 42 M.C.S.E

Ch 4 - BASES POUR UNE METHODOLOGIE Pour un système, la première description, celle la plus abstraite, est une vue purement externe appelée spécification et la description la plus détaillée est celle de la réalisation complète. Une fois le modèle de description d'un système défini, le schéma méthodologique comme expression d'un enchaînement d'étapes se définit aussi par un modèle de description qui est alors le modèle de développement. Ce dernier résulte du premier et pas l'inverse. 4.3.2. Méthode et technique pour chaque étape Spécifier, concevoir, c'est déduire une description à partir d'une précédente plus succincte et d'informations complémentaires comme contraintes. Le résultat en sortie doit être conforme au modèle de description pour le niveau. Pour cela, la déduction nécessite d'utiliser des règles, un guide, des conseils qui précisent les contraintes à prendre en compte à chaque stade pour les introduire dans la solution. Des critères de décision sont aussi nécessaires pour répondre aux divers choix. Ainsi, une ou des méthodes sont associées à chaque étape, tandis que l'enchaînement des étapes définit le schéma global de la méthodologie. 4.3.3. Modèles de solutions Le processus de conception est une activité humaine. Si parfois, la solution résulte de pures transformations, il reste une part importante de travail créatif. Comment faire en sorte qu'une grande majorité de concepteurs produisent des solutions correctes et si possible de qualité? Pour cela, il faut être capable d'induire des idées de solutions adaptées au problème. Il est donc intéressant de pouvoir disposer de modèles de solutions, aussi appelés dans ce document modèles génériques, car ils permettent d'induire une variété de solutions, chacune spécifique au problème à résoudre et se déduisant de l'objectif à satisfaire. Si les aspects précédents: modèle de description, méthodes, sont classiques, l'intérêt des modèles génériques nous est apparu récemment à travers des expériences pédagogiques. Le résultat est très prometteur. De plus, en regardant l'avenir, de même que l'accroissement de la productivité passe par une automatisation de la production des produits et plus en amont des descriptions des solutions, de même l'automatisation d'une étape nécessite inévitablement de baser un outil de production sur un ou des modèles de solutions. La méthodologie MCSE présentée dans le chapitre suivant est basée sur ces concepts: modèle de description d'un système en 3 dimensions, modèle de développement en 4 étapes, méthode associée à chaque étape, modèles de solutions comme aide au concepteur.

M.C.S.E

43

Chapitre 5

PRESENTATION DE MCSE

Ce chapitre décrit les éléments caractéristiques et la démarche de la Méthodologie MCSE. Tout d'abord, se trouve présenté le modèle retenu pour la description de tout système. Sur la base de ce modèle sont ensuite décrites les étapes de la méthodologie. Un premier bilan sur les points essentiels de MCSE termine ce chapitre. Au préalable, rappelons la démarche progressive naturellement ascendante faite durant 10 ans pour amener cette méthodologie à sa maturité, en situant les stades caractéristiques de la réflexion. 5.1. DEVELOPPEMENT DE LA METHODOLOGIE La méthodologie présentée couvre aujourd'hui les phases de Spécification, de Conception Fonctionnelle aussi appelée par ailleurs Conception Préliminaire, de définition de la Réalisation ou Conception Détaillée. Le point de départ de ce développement vers 77,78 portait essentiellement sur l'étape de Conception. Définir une procédure de conception nécessitait au préalable de développer un modèle de description pour toute application et système temps-réel. Ce modèle explicité en 80 est un modèle en 3 dimensions: fonctionnel, temporel, exécutif. Il a permis de montrer son intérêt comme base pour le développement d'une application par raffinements successifs des besoins jusqu'à une solution de réalisation incluant du matériel et du logiciel, et répondant à divers critères.

M.C.S.E

45

Partie 1 - PRESENTATION DE LA METHODOLOGIE Avec du recul, il est intéressant de constater que le modèle retenu est un invariant. Son adéquation s'est progressivement confirmée à travers le développement, pour des industriels, de multiples types de problèmes. La réflexion s'est ensuite portée sur le raffinement des démarches à suivre pour trouver une solution possédant des qualités techniques et économiques. L'étape de Conception ne peut pas non plus être isolée des étapes situées en amont et en aval. En amont, les réflexions ont conduit à développer la démarche pour aboutir à un document de spécification utilisable avec efficacité pour la Conception. La méthode de Spécification est basée sur une première approche par la modélisation de l'environnement du système. Une telle approche facilite grandement par la suite, la démarche lors de la conception. En aval de la conception, nous avons porté notre intérêt sur les différentes techniques de réalisation de manière à expliciter la démarche qui conduit, à partir d'une conception fonctionnelle, à choisir la technique de réalisation la plus appropriée (type de technologie, répartition matériel/logiciel, respect des contraintes de temps...). Une large expérimentation de la méthodologie a montré l'importance du modèle de description, puis l'importance des règles et conseils qui engendrent chez les concepteurs des solutions de qualité. Ces dernières années, dépassant ce stade, nous avons constaté, que les solutions de qualité peuvent s'exprimer sous la forme de modèles génériques. Ainsi, la connaissance de tels modèles génériques de solutions pour diverses classes de problèmes facilite la tâche du concepteur et favorise la production de solutions de qualité au sens lisibilité, maintenabilité, efficacité... et donc coût. La méthodologie de conception MCSE a spécialement été développée pour les applications temps-réel en contrôle/commande. Appliquée à de multiples problèmes industriels, elle a ainsi pu être validée. Il en est résulté une bonne adéquation du modèle à la problématique traitée et un intérêt certain de la phase de définition de la réalisation qui propose une démarche systématique pour le choix de la répartition matériel/logiciel. Si cette méthodologie concerne plus particulièrement le domaine des systèmes électroniques temps-réel, il se trouve que la démarche suivie pour les premières phases du développement: -spécification, conception architecturale- se trouve indépendante de la réalisation, puisqu'il s'agit d'une approche SYSTEME. Des expériences intéressantes ont été menées quant à son utilisation pour des applications variées: systèmes de contrôle/commande, réseaux et protocoles, systèmes répartis, outils interactifs, conception de composants intégrés. Elle est utilisée de manière systématique pour la spécification et la conception de systèmes, sur la demande d'industriels ou de laboratoires de recherche. On peut citer entre autres les études suivantes: - Conception d'un système électronique pour la programmation et le contrôle/commande de centrifugeurs haut de gamme. - Etude de faisabilité d'une solution totalement numérique pour la commande de convertisseurs continu-continu. - Réalisation d'un système de test automatique de 6 batteries. Une autre version pour 64 batteries a ensuite été développée. - Système d'acquisition de données pour le contrôle de chaînes d'ancrage pour plateformes pétrolières. 46 M.C.S.E

Ch 5 - PRESENTATION DE MCSE - Conception d'un système de gestion technique centralisée et de régulation d'un grand bâtiment avec mise en place d'un réseau local. Ces problèmes sont de taille et complexité variées. Le système de gestion technique centralisée concernait la gestion simultanée de 600 entrées/sorties. 5.2. LE MODELE DE DESCRIPTION MCSE est basée sur l'idée simple que tout système (sa vue interne, c'est-à-dire le Comment) est observable selon 3 vues: - une vue fonctionnelle, qui caractérise les fonctions internes du système, - une vue temporelle, décrivant l'évolution des fonctions internes exprimant ainsi la contribution de chacune d'elles, - une vue matérielle, spécifiant la partie physique du système. Pour illustrer cette idée, considérons le cas d'un système de commande pour le chauffage d'un bâtiment. La vue fonctionnelle fait apparaître les fonctions de dialogue, de supervision du bâtiment, de régulation de chaque zone... Ces fonctions sont couplées entre elles pour satisfaire l'objectif : échange de messages pour le planning de chauffe, accès à des grandeurs caractéristiques que sont température extérieure, température d'eau... La vue comportementale explique la contribution de chaque fonction. Par exemple, la régulation de chaque zone calcule toutes les minutes, la commande de la vanne selon la formule: cv = k1*(Tc-Ti) - k2*Tex - k3*(Tex-Texprec). avec Tc : température de consigne, Ti: température intérieure, Tex: température extérieure, Texprec: température extérieure pour la mesure précédente. La vue matérielle est un ensemble de systèmes à microprocesseurs couplés entre eux par une paire bifilaire utilisée comme bus commun. Chaque vue ne suffit pas à elle seule pour comprendre complètement le système. Chacune explique un aspect particulier et ainsi apporte une dimension supplémentaire d'information pour décrire le "comment" du système. Ces 3 vues s'avèrent nécessaires et complémentaires. Ainsi, le modèle conceptuel retenu est à 3 composantes [CALVEZ-82]: - la composante structurelle, décrite par le modèle fonctionnel (ou structure fonctionnelle), - la composante comportementale, qui décrit, par des modèles temporels, le comportement des constituants fonctionnels. - la composante exécutive, décrite par une structure dite d'exécution, qui exprime les constituants matériels et les interconnexions nécessaires pour le fonctionnement du système. Les 2 premières composantes décrivent la structure et le comportement d'un système en faisant abstraction des techniques et méthodes de réalisation. La description résultante, appelée DESCRIPTION FONCTIONNELLE, se veut indépendante des techniques de réalisation à retenir ou imposées. M.C.S.E 47

Partie 1 - PRESENTATION DE LA METHODOLOGIE La troisième composante décrit les moyens informatiques et électroniques mis en oeuvre pour engendrer l'évolution décrite par la description fonctionnelle, tout en satisfaisant toutes les contraintes temporelles, techniques et technologiques de l'application. La figure suivante présente ce modèle à 3 composantes.
V1 V2

A2

A3 M1

Composante fonctionnelle

A1 E2 A5

E1 A4

Structure fonctionnelle Composante comportementale Algorithmes
A2 A4

A3 A1 et A5

Composante exécutive
P2

P1 S1

M1 M2

P3 N1 P4 M1

Structure d’exécution

Signification des symboles
Structure fonctionnelle VARIABLE PARTAGEE Structure d’exécution MEMOIRE

EVENEMENT

SIGNAL

ACTION

PROCESSEUR

PORT

NOEUD DE COMMUNICATION

-Figure 5.1- Le modèle à 3 dimensions. Cette figure montre que, l’association structure fonctionnelle et comportement des fonctions est intégrée sur le support d'exécution selon une correspondance appelée intégration ou allocation. Décrivons succinctement chacune des composantes du modèle. 48 M.C.S.E

Ch 5 - PRESENTATION DE MCSE 5.2.1. Le Modèle fonctionnel Le modèle fonctionnel est une structure construite à l'aide de fonctions et de relations entre celles-ci. Une fonction dans sa signification usuelle désigne l'entité assurant une activité spécifique du système. La décomposition en fonctions correspond à un découpage "topologique" et non à un découpage temporel des activités de l'application. Entre les fonctions, les relations retenues sont particulièrement adaptées pour les systèmes temps-réel. Elles sont de 3 types: - la relation de SYNCHRONISATION, matérialisée par un événement. Elle sert à définir l'ordre total ou partiel selon lequel les différentes fonctions doivent intervenir dans l'activité globale du système. Les instants d'intervention correspondent à l'apparition d'événements qui expriment généralement des changements d'état du système. Ce type de relation convient particulièrement bien à la description des applications pilotées par les événements (event-driven). - la relation par partage de VARIABLE (variable d'ETAT). Plusieurs fonctions peuvent, par ce type de relation, connaître une information par consultation, ou modifier instantanément la valeur de cette information. Il s'agit d'une relation importante pour les applications temps-réel, en particulier pour le couplage de procédés physiques avec un système de commande. En effet, certaines fonctions doivent avoir une influence immédiate sur leur environnement, ou une connaissance précise et instantanée de l'état de cet environnement. - la relation de TRANSFERT D’INFORMATION, par échange de messages. Elle sert à assurer le passage de chaque information d'une fonction à une autre. Ce type de relation sous-entend le changement de propriété de l'information. Il s'agit d'une relation du type producteur → consommateur. Une fonction n'entrera en activité que lorsqu'elle disposera de l'information nécessaire qui lui sera transmise sous la forme d'un message. On peut donc dire que l'activité liée à une fonction est synchrone à un type particulier d'événement signalant la disponibilité d'une information. Ce type d'échange engendre une relation d'ordre total pour l'activité des fonctions conséquentes. Les fonctions considérées dans ce modèle peuvent être aussi bien des fonctions élémentaires que des fonctions complexes. Par raffinements successifs, une fonction COMPLEXE se décompose sous la forme d'une structure. Les fonctions et relations sont celles nécessaires pour satisfaire l'objectif et ne concernent nullement les aspects technologiques. Une bonne description fonctionnelle se doit d'être indépendante de la technologie. La figure 5.2 illustre ce modèle pour l’exemple du système de commande de chauffage. La nature graphique le rend particulièrement intéressant pour une compréhension globale rapide du modèle. La solution est constituée d'une fonction de Supervision liée à l'exploitant, et autant de fonctions de Régulation que de zones de chauffe à contrôler. M.C.S.E 49

Partie 1 - PRESENTATION DE LA METHODOLOGIE

ordre
Exploitant

Réponse
Exploitant

GESTION - CENTRALISEE

Mesures[1..n]
CONTROLE ZONE [1..n]

Consigne [ 1..n ]

Milieu extérieur

TE FILTRAGE

TEF TE Pas
HORLOGE

CV[j]

TI[j]
Zone [i] TI

REGULATION

CV

Zone [i]

TI[i]

CONTROLE ZONE I

-Figure 5.2- Exemple de structure fonctionnelle pour la commande de chauffage. Ce modèle, qui permet l'abstraction et le raffinement de structure, est du type hiérarchique. Cette composante structurelle permet aussi de représenter en complémentarité les 2 dimensions d'organisation, à savoir la dimension verticale pour exprimer une structure en niveaux de services, et la dimension horizontale exprimant le flot de données et les dépendances temporelles du niveau. L'intérêt des 3 types de relations, plutôt que par exemple une version unifiée par messages, est son adéquation à pouvoir décrire simultanément des comportements du type event-driven et data-driven ainsi que les couplages directs aux processus physiques. 5.2.2. Le modèle comportemental Ce modèle décrit la contribution de la fonction pour son environnement. Il s'agit donc de sa spécification. Une fonction est à comprendre comme un opérateur de transformation des entrées en sorties. Décrite par un modèle comportemental, son évolution est obligatoirement séquentielle et cyclique. Tous les types de modèles temporels séquentiels sont utilisables: diagramme à états finis, grafcet, algorithme. Chaque fonction assure une transformation à la fois. 2 types de comportement sont considérés: - une évolution PERMANENTE: sans entrée d'activation par événement ou message, la fonction joue en permanence son rôle de transformation. Il s'agit donc d'une fonction permanente. - une évolution TEMPORAIRE: la fonction assure son rôle à chaque apparition d'une entrée du type événement ou message. Il s'agit donc d'une fonction temporaire. 50 M.C.S.E

Ch 5 - PRESENTATION DE MCSE L'exemple suivant montre la description algorithmique donnée pour la régulation de température pour chaque zone. Celle-ci est pilotée par une horloge pour définir le pas d'échantillonnage.
Tc

TE

REGULATION
TI

action HORLOGE (sortie événement PAS); const Durée = 1 mn ; begin cycle : begin attente ( Durée ) ; signal ( PAS ) ; CV end ; end cycle ; end HORLOGE ; action REGULATION sur événement PAS avec (entrée var TC, TE, TI : température; sortie var CV : 0 .. CVmax ); const K1, K2, K3 . . . . ; var TE_PREC : température ; begin TE_PREC := TE ; CV:= 0; cycle PAS :begin CV:=K1*(Tc-Ti) - K2*TE - K3*(TE-TE_PREC); TE_PREC := TE ; end; end cycle ; end REGULATION;

HORLOGE PAS

-Figure 5.3- Comportement pour la régulation. L’évolution permanente est exprimée par l’instruction CYCLE: <Instruction> endcycle; et l’évolution temporaire par l’instruction CYCLE <ev>: <Instruction> endcycle;. Une telle description est formelle, et donc vérifiable, et permet de passer rapidement à une réalisation, particulièrement lorsqu'il s'agit d'une implantation logicielle. 5.2.3. Le modèle exécutif Ce modèle joue le rôle d'une spécification de la partie matérielle. Il est basé sur le fait que toute réalisation pour un système électronique est composée: - de processeurs comme organe de transformation des informations et de prise de décision, - de mémoires, pour la conservation des données, - de noeuds de communication comme éléments intermédiaires pour le transit d'informations. Liés entre eux, ces 3 types d'éléments technologiques conduisent à décrire une solution matérielle par une structure appelée STRUCTURE D'EXECUTION. Les échanges entre processeurs se font: - par signalisation inter-processeurs pour un couplage direct, - par un partage de mémoire pour un couplage indirect, - par l'intermédiaire d'un réseau de noeuds de communication pour le transfert de messages. M.C.S.E 51

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les termes processeur, mémoire, noeud de communications sont à prendre dans leur sens le plus général. Un processeur est programmable comme le microprocesseur par exemple, ou spécifique tel qu'un ampli opérationnel ou un convertisseur numérique analogique. Une mémoire peut se limiter à un simple registre, mais peut aussi être un support de masse. Un noeud de communication peut être réduit à une ligne RS232 ou représente un noeud d'un réseau télématique. La figure suivante donne l'exemple d'une structure d'exécution pour la conduite de chauffage.
Clavier Micro-ordinateur écran

TxD

RxD

liaison bifilaire

Sous-station de zone i H = 1 ms Horloge Processeur Programmable 4 Ko EPROM Capteur TE Capteur TI 256 oct. RAM Conversion R -> U Conversion F -> U liaison série 1 IT pour H CVn
Adaptation en courant

Sortie 4 . . 20 mA

-Figure 5.4- Structure d'exécution pour le chauffage. Le modèle pour la composante exécutive est similaire à celui proposé pour la composante fonctionnelle, mais avec une signification différente des fonctions et des relations. L'existence de cette troisième dimension permet de rechercher ou d'exprimer pour chaque application, le support matériel le plus approprié. La similitude de modèle permet de procéder par déduction en définissant la structure d'exécution comme une réduction à partir de la structure fonctionnelle. 5.2.4. Intérêt de cette modélisation Ce modèle à 3 composantes permet une description favorisant la compréhension progressive d'un système en s'intéressant tout d'abord aux relations entre les fonctions internes nécessaires pour satisfaire les objectifs, puis au comportement de chacune d'elles et en final aux ressources génératrices du fonctionnement du système. Il permet de structurer la présentation d'un système selon une hiérarchie de 4 niveaux: - la description externe, comme niveau 0. Elle exprime, avant toute forme de solution interne, les spécifications complètes de l'application. 52 M.C.S.E

Ch 5 - PRESENTATION DE MCSE - la description fonctionnelle, comme niveau 1. Basée sur le modèle fonctionnel et l'expression du comportement des fonctions internes, elle présente la solution selon une description indépendante de la technologie. - la description exécutive, comme niveau 2. Elle résulte de l'association de la description du niveau précédent avec une structure d'exécution choisie ou imposée comme support matériel. - la description finale, comme dernier niveau où apparaissent les descriptifs des matériels et logiciels de l'application. La description fonctionnelle, qui est une description orientée application ne tient pas compte des caractéristiques technologiques. Ainsi, une telle solution favorise ensuite une nouvelle implantation lors de changements technologiques. La description exécutive est l'association des 3 composantes liées entre elles par l'allocation qui décrit l'implantation de la description fonctionnelle sur le support exécutif. Le principe est qu'une partie de la description fonctionnelle est implantée sur chaque processeur. Lorsque le processeur est programmable, l'implantation du sous-ensemble de la structure fonctionnelle sur ce processeur est décrit par un schéma d'implantation logicielle. La présentation en niveaux de description accroît la lisibilité et en conséquence la maintenabilité. De plus, elle est utilisable comme base pour le découpage en étapes de la démarche de développement. Le modèle se prête aussi à la description des systèmes complexes, car il possède la propriété d'invariance d'échelle: composant ASIC ou application multiprocesseurs, simple réalisation à microprocesseurs ou système télématique complexe. 5.3. LA DEMARCHE La démarche de conception est basée sur l'emploi du modèle ci-dessus. Elle exprime le processus de réflexion que doit suivre le concepteur pour aboutir à une description conforme au modèle, tout en répondant à des critères de qualité: robustesse, modularité, lisibilité, maintenabilité. Chaque niveau de description sert d'intermédiaire entre 2 étapes successives. Le développement s'effectue selon 4 étapes: - l’élaboration des spécifications, de manière à exprimer à partir du besoin une vue purement externe du système (WHAT). - La conception fonctionnelle, qui a pour objectif de trouver la description fonctionnelle, composée des 2 premières composantes du modèle (HOW). - La définition de la réalisation (aussi appelée conception détaillée), le but étant de trouver une structure d'exécution ainsi qu'une implantation logicielle sur la structure matérielle retenue, en considérant toutes les contraintes technologiques: contraintes de répartition, contraintes de temps, contraintes électriques... - La réalisation conduisant à un système opérationnel. M.C.S.E 53

Partie 1 - PRESENTATION DE LA METHODOLOGIE La figure suivante décrit l'enchaînement de ces 4 étapes.
Abstrait Modèles Spécification
SPECIFICATION

Cahier des charges

Niveau 1 Spécifications fonctionnelles et opératoires

Spécifications Modèle fonctionnel
CONCEPTION FONCTIONNELLE

Niveau 2

Description fonctionnelle Modèle d’éxécution

Spécifications technologiques

DEFINITION de la REALISATION

Niveau 3

Description exécutive

PRODUIT

Spécifications technologiques de réalisation Niveau 4
Concret

REALISATION

Temps

-Figure 5.5- Enchaînement des étapes pour MCSE. Pour chaque étape, le concepteur dispose en entrée: de la description d'un niveau intermédiaire comme résultat de l'étape précédente, de renseignements complémentaires que sont les contraintes imposées dans les spécifications. L'étape produit une description pour le niveau suivant. Une vérification de conformité est possible à l'issue de chaque étape. Dans les paragraphes suivants et sans entrer dans les détails, nous passons en revue les différentes étapes de la méthodologie en précisant les principes. 5.3.1. Elaboration des spécifications Pour pouvoir concevoir, il faut tout d'abord disposer des spécifications. Par spécifications, il faut entendre une description complète mais purement externe du système à concevoir. Plus ces spécifications sont détaillées et conformes à des modèles formels, plus il est facile de déduire une solution. Mais la spécification doit aussi être vérifiable, en particulier par le demandeur. Le point de départ est le cahier des charges décrivant le besoin du demandeur. Pour décrire ce que doit faire un système, celui-ci est considéré comme observant et agissant sur les objets de son environnement. Il faut donc tout d'abord connaître cet environnement. Le connaître, c'est dans un premier temps modéliser les objets sans le système, et dans un second temps, expliciter les relations entre eux sous la forme d'une description fonctionnelle. Ensuite, expliciter le rôle du système et donc exprimer ses spécifications consiste à énoncer et à caractériser les fonctions demandées. Ceci se fait en détaillant le comportement souhaité des objets de l'environnement sous le contrôle du système, ainsi que toutes les contraintes imposées. 54 M.C.S.E

Ch 5 - PRESENTATION DE MCSE Par cette approche, la méthodologie fait apparaître une similitude de raisonnement entre la démarche pour obtenir les spécifications et celle pour concevoir. L'analyse de l'environnement conduit à une synthèse de la réalité sous la forme d'un modèle, et l'introduction des objectifs à atteindre conduit à un enrichissement de la modélisation précédente en considérant en supplément l'apport du système. Cette étape permet d'obtenir 3 types de spécifications: - les spécifications fonctionnelles: elles comprennent la liste des fonctions du système pour l'application (fonctions externes) et la description du comportement de l'environnement sous l'influence du système pour ces fonctions. - les spécifications opératoires, qui concernent le comportement, les performances, précisions, les méthodes à utiliser dans le système. - les spécifications technologiques, qui incluent: les contraintes de temps et de répartition, les caractéristiques des interfaces, les contraintes de réalisation. Les spécifications fonctionnelles et opératoires sont utilisées durant l'étape de conception fonctionnelle, tandis que les spécifications technologiques ne servent que pour l'étape de définition de la réalisation et de réalisation. Certaines spécifications sont propres à l'étape de réalisation. 5.3.2. Conception fonctionnelle La solution pour cette étape se déduit d'une analyse des spécifications fonctionnelles. La recherche de la structure fonctionnelle se fait tout d'abord à partir de la délimitation du système en caractérisant ses entrées et ses sorties. Il s'agit ensuite de trouver une première décomposition fonctionnelle. Cette première approche est importante car elle induit la qualité ou non-qualité pour le reste du développement. La démarche consiste ensuite à rechercher par raffinements successifs et pour chaque fonction à concevoir, les variables et événements internes caractéristiques nécessaires et si possible suffisants. Se déduisent alors les fonctions qui exploitent et assurent la mise à jour de ces variables ainsi que le comportement de chaque fonction. Le raffinement est poursuivi jusqu'à l'obtention de fonctions élémentaires pouvant s'exprimer par une description purement séquentielle. L'expérience nous a montré que cette approche basée sur les données conduit à des structures fonctionnelles simples (réduction des couplages exprimant des relations d'ordre) et plus structurées que l'approche basée sur les fonctions, qui conduit à exprimer la structure comme décrivant un enchaînement de transformations. 5.3.3. Définition de la réalisation La troisième étape consiste à rechercher, d'une part le support exécutif, d'autre part la manière d'y implanter les fonctions réalisées par logiciel. Tout d'abord, la description fonctionnelle doit être affinée, détaillée, enrichie pour tenir compte des contraintes technologiques que sont: la répartition géographique (si nécessaire), les interfaces physiques, les interfaces utilisateur. M.C.S.E 55

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les contraintes de temps sont ensuite analysées pour déduire la répartition matériel/logiciel. La partie matérielle est spécifiée par une structure d'exécution. L'intégration ou allocation décrit complètement l'implantation de la description fonctionnelle sur la structure d'exécution. Chaque sous-ensemble fonctionnel à réaliser par logiciel est décrit par un schéma d'implantation logicielle qui exprime la priorité de chaque tâche et les relations de dépendance spatiale (par des données) ou temporelles. Cette implantation résulte de l'utilisation de règles qui permettent d'effectuer des transformations sur la structure fonctionnelle en tenant compte du support matériel. 5.3.4. Réalisation Les 2 parties: - support matériel, implantation du logiciel - favorisent le travail de réalisation d'un prototype, l'intégration et le test. Il faut être conscient à ce stade de la variété des stratégies de réalisation qui dépendent d'au moins 3 facteurs: les spécifications en entrée, les techniques à mettre en oeuvre, les outils et méthodes disponibles. La réalisation est une démarche ascendante puisqu'elle consiste à assembler. Il s'agit de développer partie par partie la solution en faisant apparaître des fonctionnalités de plus en plus abstraites pour se rapprocher de l'objectif. Chaque niveau de la réalisation est validé par une vérification de la conformité aux spécifications du niveau correspondant de la démarche descendante. Réalisation matérielle et réalisation du logiciel peuvent se développer simultanément, ce qui permet de réduire le temps de la réalisation et de faire intervenir conjointement des spécialistes des 2 domaines. Pour achever la réalisation, l'intégration et le test ont pour objectif de réunir toutes les parties des développements de manière à fournir un système opérationnel conforme aux souhaits du demandeur. 5.4. CARACTERISTIQUES DE MCSE La méthodologie proposée est une démarche complète qui permet de passer du problème à une réalisation. Nous reprenons ici les points généraux présentés comme objectifs dans les chapitres précédents, pour montrer pourquoi et comment MCSE répond à l'ensemble de ces points.
-A- UN MODELE DE DESCRIPTION COMME BASE

Toute méthodologie est basée sur un ou des modèles de description, ceci permet une décomposition en étapes. MCSE est basée sur un modèle de description interne en 3 composantes. Il incite à décrire tout système selon une hiérarchie de niveaux de description. Chaque niveau sert d'intermédiaire entre 2 étapes. Les modèles sont pour la plupart graphiques, favorisant ainsi une compréhension globale et rapide.
-B- UNE DEMARCHE GLOBALEMENT DESCENDANTE POUR LA CONCEPTION

Chaque étape de la méthodologie permet de passer d'un niveau de description à un niveau suivant plus détaillé en enrichissant la solution d'une composante supplémentaire. La progression est donc globalement descendante puisqu'elle part du problème posé jusqu'à aboutir à une réalisation opérationnelle. 56 M.C.S.E

Ch 5 - PRESENTATION DE MCSE
-C- UNE PROGRESSION ITERATIVE

Un développement ne peut pas se faire sans erreurs ou omissions. Des corrections sont toujours nécessaires. Basée sur la correction par retours arrière, une phase de vérification en fin de chaque étape permet la détection des erreurs et induit un travail itératif avec des retours à l'intérieur de l'étape ou sur les étapes précédentes.
-D- UNE METHODE SPECIFIQUE POUR CHAQUE ETAPE

Le modèle de description de la solution à l'issue de chaque étape n'est pas suffisant (le quoi). Le concepteur doit disposer pour chaque étape d'un guide précis lui expliquant COMMENT passer de la spécification en entrée à une solution possédant des qualités. Ce guide est la méthode à suivre: technique d'analyse, séquence des décisions, critères de choix. Par opposition à une recherche intuitive, l'emploi d'une méthode garantit l'obtention plus rapide d'une solution a priori de qualité. Au-delà de l'aspect méthode, l'idée de modèles génériques de solutions a un intérêt certain. De tels modèles ayant la particularité pour la décomposition fonctionnelle d'être générateurs de multiples solutions, sont retenues car possédant des qualités intrinsèques: lisibilité, maintenabilité, simplicité, adéquation au modèle global MCSE. La connaissance de tels modèles, en complément des méthodes, nous a permis de constater que près de 80 à 90% des concepteurs peuvent réaliser des développements corrects.
-E- UNE DEMARCHE GLOBALEMENT ASCENDANTE POUR LA REALISATION

L'assemblage n'est possible qu'après disponibilité des constituants. Ainsi, la réalisation débute par la réalisation des plus petits sous-ensembles, puis remonte progressivement par assemblage et intégration de fonctions plus globales. Le travail de réalisation est représentable par un triangle juxtaposé à celui de conception comme l’indique la figure 5.6. La largeur du triangle pour chaque stade indique la quantité d'informations à maîtriser. Chaque niveau de la réalisation est vérifiable, ce qui assure sa conformité au niveau correspondant de la conception. Il y a donc correspondance entre les 2 démarches complémentaires.
-F- UN MODELE DE CYCLE DE DEVELOPPEMENT HIERARCHIQUE

Pour un système relativement complexe, le modèle ci-dessus en double triangle n'est pas suffisamment précis. L'étape de définition de la réalisation conduit à mettre en évidence les 2 parties: matériel, logiciel. Chaque partie est à nouveau à développer selon une démarche en 3 phases: spécification, conception, définition de la réalisation, et ceci jusqu'à la mise en évidence des constituants disponibles (composants matériels ou logiciels). Ainsi, le modèle de cycle de développement est un emboîtement de développements. La figure suivante illustre le modèle hiérarchique pour MCSE. Au premier niveau, la conception est générale et concerne l'application dans son ensemble. Au fur et à mesure du raffinement de la solution les développements concernent des problèmes plus spécifiques en rapport avec la réalisation: développement d'un composant, d'une fonction spécifique, d'un module logiciel... Une spécification sert comme objectif pour une réalisation. Le composant ou sous-ensemble est le résultat utilisable. M.C.S.E 57

Partie 1 - PRESENTATION DE LA METHODOLOGIE

BESOIN

CONFORMITE

PRODUIT

Spécification
VALIDATION
SPECIFICATION RECETTE CERTIFICATION TEST

Validation

conception

CONCEPTION FONCTIONNELLE

VERIFICATION

VALIDATION

Réalisation

DEFINITION DE LA REALISATION

INTEGRATION

TEST
PARTIE MATERIELLE PARTIE LOGICIELLE

REALISATION MATERIELLE

REALISATION LOGICIELLE

-Figure 5.6- Forme en double triangle pour le développement.

CAHIER DES CHARGES
DEVELOPPEMENT DU SYSTEME

SPECIFICATION CONCEPTION FONCTIONNELLE DEFINITION DE LA REALISATION
Developpement MATERIEL

REALISATION DU SYSTEME

Developpement LOGICIEL

SPECIFICATION DU MATERIEL CONCEPTION DEFINITION DE LA REALISATION Réalisation composant i ou carte i
ASSEMBLAGE

SPECIFICATION DU LOGICIEL CONCEPTION DEFINITION DE LA REALISATION Réalisation module ou tâche
ASSEMBLAGE

...
TEST MATERIEL

...
TEST LOGICIEL

Intégration - Test - Validation du Système

PRODUIT

-Figure 5.7- Modèle hiérarchique pour le cycle de développement. 58 M.C.S.E

Ch 5 - PRESENTATION DE MCSE
-G- GUIDE POUR LA DOCUMENTATION

Le modèle de description induit directement la structure des documents à produire durant le développement. Chaque document est le résultat d'une étape et sert comme informations pour l'étape suivante. Ainsi, en respectant la démarche par étapes successives, la documentation est générée au fur et à mesure du développement et non en final. Elle possède alors une réelle qualité quant à la forme et au fond puisqu'elle relate, en plus de la solution, la démarche suivie et l'argumentation qui justifie les décisions importantes. Produite de cette manière, la documentation est exploitable durant le cycle de développement: pour les phases de vérification selon un cycle auteur-lecteurs, pour l'observation de l'état d'avancement, mais aussi pour les étapes ultérieures et en particulier pour la maintenance.
-H- GUIDE POUR LA CONDUITE DE PROJET

Le modèle de cycle de développement est utilisable pour la mise en place d'une procédure de conduite d'un ensemble de projets. Pour chaque projet, cette activité concerne: - le management: planification, organisation, direction, contrôle et suivi du projet, - l'obtention de la conformité: planification des tests, nature des tests techniques à utiliser, les résultats, conformité et certification, - la gestion de la documentation: spécification des documents, planification des revues, méthodes de gestion, mises à jour... - la gestion de la maintenance: domaine et procédures de maintenance, solutions et outils, planification, - la gestion de la qualité: assurance qualité, méthode pour l'obtention de la qualité, procédures de contrôle.
-I- UNE METHODOLOGIE OUVERTE ET COMPLEMENTAIRE

MCSE ne se trouve pas restreinte à un domaine bien spécifique et n'est pas uniquement une méthode particulière. Au contraire, pour chaque étape, plusieurs méthodes sont utilisables et c'est au concepteur de choisir selon des critères, celle qui lui permet de résoudre au mieux son problème. Développée au départ pour les systèmes de contrôle/commande temps-réel à microprocesseurs, l'expérience nous a montré son adéquation pour une large classe d'applications et de techniques et tout particulièrement pour les applications qui utilisent l'Electronique et l'Informatique. MCSE n'est pas à opposer aux autres méthodologies, bien au contraire, elle se veut complémentaire. La plupart des modèles proposés par différents auteurs s'avèrent utilisables. Par exemple, SADT, les méthodes de spécification de WARD et MELLOR et de HATLEY favorisent la tâche d'analyse du problème. La méthodologie de JACKSON est dans l'esprit et pour certains aspects relativement proche de MCSE. Les méthodologies DARTS de GOMAA et SDWMC de BUHR ont des points communs.
-J- SUPPORT POUR DES OUTILS

Il est difficile aujourd'hui de concevoir une méthodologie sans penser aux outils informatiques comme support de développement et de conduite de projets. M.C.S.E 59

Partie 1 - PRESENTATION DE LA METHODOLOGIE Basé sur un modèle formel, MCSE possède toutes les caractéristiques favorables pour le développement de tels outils. Il est essentiel de comprendre qu'un outil n'implique pas une méthodologie mais l'inverse. Un outil n'est que le support d'aide à l'application d'une méthodologie. Ainsi, un outil comme support ne peut se développer que postérieurement à la formalisation d'une méthodologie. Cette présentation succincte est loin d'être suffisante pour se faire une idée complète sur la méthodologie. Aussi, pour avoir une vue globale relativement complète de la démarche, le chapitre suivant illustre son utilisation sur un exemple assez simple.

60

M.C.S.E

Chapitre 6

UN EXEMPLE D’ILLUSTRATION

De manière à illustrer les principes de la méthodologie MCSE, ce chapitre présente un exemple de problème relativement simple, mais tout de même suffisamment complexe pour justifier l'utilisation d'une méthode. Il permet de saisir les grandes lignes de la démarche préconisée, le rôle de chaque étape. Il facilite la compréhension des 3 vues du modèle conceptuel et les niveaux de description de la solution. Il n'est pas demandé au lecteur de comprendre en détail l'exemple. Il est même plutôt conseillé de lire rapidement ce chapitre, uniquement pour se faire une idée globale de la méthodologie. Plus tard, une fois lues les parties 3 à 6 qui concernent l’approfondissement de la méthode pour chacune des étapes, il sera alors judicieux de revenir sur cet exemple pour une compréhension complète. L'exemple traité est un système pour le contrôle de la vitesse de croisière d'un véhicule. Cet exemple est extrait de l'ouvrage: Strategies for Real-time System Specification- de HARTLEY et PIRBHAI dans lequel on trouve une présentation de solution. On retrouve le même exemple dans l'ouvrage: Structured Development for Real-time Systems Vol. 2 et Vol. 3 de WARD et MELLOR. Des compléments et modifications ont été apportés au cahier des charges en particulier pour les spécifications technologiques de manière à pouvoir proposer une solution complète et réaliste vis à vis du besoin.

M.C.S.E

61

Partie 1 - PRESENTATION DE LA METHODOLOGIE 6.1. CAHIER DES CHARGES Ce système de contrôle est à considérer comme une option possible sur certains modèles de véhicules. Les fonctions essentielles du système concernent des opérations de routine et des tâches de maintenance, à savoir: maintien de la vitesse de croisière, suivi de la vitesse moyenne, suivi de la consommation de carburant, maintenance de la voiture.

On décrit ci-après plus en détail ces fonctions ce qui permettrait par une étude préliminaire, une évaluation de la solution, son coût et temps de développement, son coût de reproduction. 6.1.1. Contrôle du régime de croisière Cette fonction permet de conserver au véhicule une vitesse constante lorsque ce mode est sollicité par le conducteur. Elle n'est active que lorsque le moteur est en route. Au démarrage, la fonction est évidemment dans l'état inactif. Le conducteur dispose de plusieurs commandes: activation du régulateur, arrêt, accélération, retour au régime précédent (régulation de croisière).

Lorsque le conducteur active la régulation, la vitesse du véhicule à cet instant est maintenue si celle-ci est supérieure à 50 km/h. La commande ARRET implique une reprise du contrôle par le conducteur. La vitesse du véhicule se déduit de la vitesse de rotation d'une roue et le contrôle de la vitesse du moteur s'effectue par une valve qui contrôle l'injection de carburant. La commande de la valve ne s'effectue que dans le sens ouverture (accélération). Dans l'autre sens, il y a rappel automatique par un ressort. Bien entendu, la pédale d'accélération agit toujours mécaniquement sur la valve; c'est l'action la plus importante en déplacement qui définit la vitesse du véhicule. Lorsque le régulateur est actif, le conducteur peut demander une augmentation progressive de la vitesse par la commande ACCELERATION. Cette action se maintient jusqu'à la commande FIN ACCELERATION: utilisation de la même touche accélération fonctionnant en bistable. Alors le véhicule maintient cette vitesse comme régime de croisière. Le conducteur peut à tout instant, augmenter la vitesse du véhicule en appuyant sur la pédale d'accélération, ou réduire sa vitesse en appuyant sur la pédale de frein. Sur relâchement de la pédale d'accélération le véhicule revient à la vitesse de croisière. Lorsqu'il s'agit d'un appui sur la pédale de frein ou lors d’un retrait du levier de vitesse de sa position enclenchée, le système devient inactif. Sur relâchement du frein, et avec le levier de vitesse en position, la commande "Retour au régime de croisière" fait retrouver au véhicule la vitesse précédemment sélectionnée. Si entre temps une commande ARRET est intervenue, la commande RETOUR est sans action. 62 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION Le système doit posséder son propre indicateur de vitesse. Comme la vitesse et donc la distance parcourue est fonction de la taille des pneus, le système doit pouvoir être calibré à l'installation. 2 commandes supplémentaires sont disponibles en face arrière: START MESURE KM et STOP MESURE KM. Après l'appui sur START, le conducteur parcourt 1 km puis appuie sur STOP. Dans ce mode étalonnage, le système doit enregistrer le nombre de tours de roues qui servira ensuite comme référence pour les calculs de vitesse et de kilométrage. 6.1.2. Suivi de la vitesse moyenne Le système doit fournir au conducteur une indication de sa vitesse moyenne. Pour cela, le conducteur indique au système le début d'un trajet par la commande : START TRAJET, et chaque fois qu'il demandera la vitesse moyenne par DEMANDE VM, le système lui indiquera la vitesse moyenne depuis le départ. 6.1.3. Suivi de la consommation de carburant Lorsque le réservoir est rempli, le conducteur indique au système la quantité de carburant qui vient d'être ajoutée. Le système calcule et affiche alors la consommation sur la période entre les 2 pleins. 6.1.4. Maintenance Le système doit suivre le kilométrage de la voiture et indiquer au conducteur les instants de maintenance selon les contraintes suivantes: - Huile et filtre: 7500 Km, - Filtre à air: 15 000 Km, - Révision générale: 30 000 Km 250 Km avant l'échéance, le message approprié doit apparaître en clignotement lent. 50 Km avant, il doit apparaître en continu et persister jusqu'à l'acquittement par le conducteur (commande: MAINTENANCE EFFECTUEE). 6.1.5. Caractéristiques complémentaires La phase de spécification nécessite bien entendu des discussions avec le demandeur de manière à préciser certains points obscurs. On relate ci-après les décisions à retenir. - La pédale d'accélérateur est en parallèle sur la commande électrique de la valve. L'action demandant la plus grande vitesse est prioritaire. La commande électrique est du type proportionnelle avec pour 0 volt: fermeture complète de la valve, et pour 8 volts: ouverture complète. - Le système mesure la vitesse en comptant les impulsions reçues par un capteur disposé au niveau d'une roue. - Quand le système détecte que la vitesse est supérieure de 3 Km/h à la vitesse sélectionnée, la valve doit être complètement fermée (cas de la grande descente). Pour toute autre vitesse, la commande doit être proportionnelle à l'erreur de vitesse, sauf lorsque la valve est complètement ouverte. Ceci ne doit apparaître que pour un écart de 3 Km/h. Pour des problèmes de stabilité, la mise à jour de la commande ne doit se faire que toutes les secondes. M.C.S.E 63

Partie 1 - PRESENTATION DE LA METHODOLOGIE - Pour éviter des accélérations trop rapides, l'actionneur de la valve ne doit pas évoluer plus rapidement qu'en 10 s pour toute la plage de variation en ouverture. Par contre, la fermeture peut se faire à n'importe quelle vitesse. Les mécaniciens ont estimé qu'avec ces contraintes, la voiture peut conserver sa vitesse à +ou- 2 Km/h pour des pentes normales. - Quand le système est en phase d'accélération, celle-ci doit être maintenue à 2 Km/h/s. Si l'accélération atteint 3 Km/h/s, la valve doit être totalement fermée, et pour 1 Km/h/ s, elle doit être complètement ouverte. Entre ces 2 valeurs, l'ouverture est proportionnelle à l'écart d'accélération. - Le système pour le dialogue utilisateur doit être muni d'un ensemble de touches fonctions et d'un écran type LCD. - L'interface utilisateur doit être du type "intelligent": toutes les grandeurs saisies doivent être validées (quantité de carburant ...). 6.2. SPECIFICATIONS La démarche consiste tout d'abord à s'intéresser à l'environnement du système en modélisant pour l'application les entités externes au système sans celui-ci. Il s'agit ensuite de spécifier les fonctionnalités du système en décrivant le comportement des entités avec le système. Cette première étape conduit à l'obtention d'une description externe du système à concevoir. 6.2.1. Modélisation de l'environnement
-A- LES ENTITES

Les entités concernées par le système sont: - le conducteur du véhicule, (l'installateur pour l'étalonnage), - la voiture restreinte à un moteur assurant le déplacement par les roues.
-B- LES EVENEMENTS, CONDITIONS, OBSERVATIONS

On recense ensuite la liste des événements relatés dans le cahier des charges, ceux produits par les entités et qui nécessitent une réaction de la part du système. Mise en marche et arrêt du véhicule (conducteur). Activation du régulateur, arrêt du régulateur (conducteur). Début accélération, fin accélération (conducteur). Retour au régime précédent (conducteur). Accélération par pédale, freinage, (conducteur). Start Mesure Km, et Stop Mesure Km (installateur). Start Trajet, Demande VM (conducteur). Maintenance effectuée (conducteur). Ajoût essence (conducteur).

De même, on peut recenser les conditions à prendre en compte: - V> 50 Km/h (véhicule), 64 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION - V = VR: Vitesse de croisière pour la régulation (véhicule), - Vitesse enclenchée (véhicule), - Quantité de carburant (conducteur), - Variation max de la valve: 10 s pour toute la plage en ouverture. Comme observations pour les entités, signalons: - Distance parcourue (D), - Vitesse du véhicule (V), - Vitesse moyenne sur un parcours (Vmoy), - Consommation moyenne (Cmoy), - Clignotement pour échéance à 250 Km, - Indication permanente pour échéance à 50 Km.
-C- COMPORTEMENT DES ENTITES

Le conducteur est en droit de désirer à n'importe quel instant un comportement particulier pour son véhicule. Il est donc générateur des événements le concernant et observateur des réactions de son véhicule et des informations. La voiture peut se modéliser très simplement en considérant que lorsque le moteur tourne et qu'une vitesse est enclenchée, la vitesse de déplacement est très sommairement proportionnelle à la position de la valve. Bien entendu, des grandeurs comme la pente de la route et la charge sont aussi des paramètres essentiels agissant sur la vitesse. V= F (max (Paccélérateur, Cmd_valve), pente, charge ...) Paccélérateur est la position de la pédale d'accélération et Cmd_valve est la commande électrique de la valve. La grandeur la plus importante entre la Position de la pédale d'accélérateur et la Position de la commande électrique de la valve, est prioritaire. L'influence des termes: pente, charge ... imposera obligatoirement une commande en boucle fermée pour obtenir l'effet de régulation.
-D- DELIMITATION DU CONTEXTE DU SYSTEME

La délimitation donnée sur la figure 6.1 précise le couplage entre le système et son environnement. - Pour les commandes en provenance du conducteur, on trouve tous les événements cités en B ; de même pour les observations. Il faut y ajouter la quantité de carburant. - Pour les commandes agissant sur la voiture, il s'agit de la position de la valve, - Comme observations, on trouve: la vitesse du véhicule, la distance parcourue et la vitesse enclenchée. M.C.S.E 65

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Commandes Commandes Information

SYSTEME A SPECIFIER
VOITURE

CONDUCTEUR

Observations

Observations

-Figure 6.1- Délimitation du contexte du système. 6.2.2. Spécifications fonctionnelles Il s'agit d'indiquer les fonctions que doit assurer le système pour son environnement, et décrire avec le maximum de précision les caractéristiques de ces fonctions. Pour cela, ne pouvant décrire les fonctions directement (la conception serait alors déjà faite), on s'attache à établir une description indirecte en détaillant le comportement des entités sous l'influence du système pour les fonctions.
-A- LISTE DES FONCTIONS DU SYSTEME

Le système doit : - assurer la régulation de vitesse en régime de croisière lorsque nécessaire, - fournir des informations de conduite, - fournir une aide à la maintenance. On détaille ci-après chacune des fonctions.
-B- REGULATION DE VITESSE

Pour que le conducteur puisse profiter de cette fonction, il devra coordonner (relation d'ordre) les événements qu'il génère. Alors la voiture suivra le comportement souhaité par le demandeur. Cette spécification est donnée figure 6.2. La spécification se fait donc en modélisant les états souhaités pour le véhicule, sous la sollicitation du conducteur. V est la vitesse courante du véhicule et VR représente la vitesse de croisière et sert de consigne pour la régulation. Accélération est une condition booléenne spécifiant si le conducteur accélère ou non. 66 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION

de tous les états sur arrêt moteur arrêt moteur

ARRET

mise en marche stop_mesure_km

Conduite normale

étalonnage
start_mesure_km

activation Régul • V>50 km VR = V

Régulation Vitesse VR (1)
arrêt

freinage + retrait vitesse

accélération

début accélération

inactif
arrêt

accélération manuelle

accélération automatique (3)
fin accélération VR = V

(freinage • Vitesse enclenchée • retour)

accélération

Rattrapage (2) vitesse croisière

arrêt

arrêt

arrêt

V#VR

-Figure 6.2- Comportement du véhicule pour la régulation. Pour compléter la spécification, il faut indiquer les actions à entreprendre pour les phases actives du régulateur. Pour les autres, c'est l'accélérateur qui agit. Donc Cmd_valve =0. M.C.S.E 67

Partie 1 - PRESENTATION DE LA METHODOLOGIE -PHASE:Régulation vitesse 0 Cmd_valve = Max (VR - V)/6 + Max/2; max; avec max= 8volts, V: la vitesse mesurée.

pour V - VR >3 Km/h pour |VR - V|<3 Km/h pour VR - V > 3 Km/h

-PHASE: Rattrapage croisière 0 pour A>3 Km/h/s Cmd_Valve = K(2Km/h/s - A) sinon max; pour A<1 Km/h/s avec A: l'accélération courante, K : coefficient de régulation.
-C- INFORMATIONS DE CONDUITE

3 informations sont souhaitées: - vitesse du véhicule à tout instant (simplement affichage), - vitesse moyenne sur un parcours et sur demande, - consommation moyenne au moment du plein. Le comportement imposé au conducteur pour ces 2 fonctions est indiqué par les diagrammes ci-dessous.

Attente demande (comptage temps TV et distance DV)

Attente plein (comptage distance DC)

Début trajet DV=0, TV=0

Demande VM VM = DV / TV

ajout essence CM=Q/DC, DC=0

TV = durée depuis Début trajet

Q = quantité ajoutée

-Figure 6.3- Comportement imposé au conducteur pour l’aide à la conduite.
-D- AIDE A LA MAINTENANCE

L'aide doit concerner les 3 types de maintenance. L'information indiquée au conducteur est fonction de la valeur en Km: multiple de 7500, 15000 ou 30000 Km. 68 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION - 7500 Km: huile, filtre à huile, - 15000 Km: huile, filtre à huile, filtre à air, - 30000 Km: révision générale.

Attente maintenance

(D+250) multiple de 7500

Maintenance intermittente D = kilométrage du véhicule

(D+50) multiple de 7500 Maintenance effectuée Maintenance permanente

Maintenance effectuée

-Figure 6.4- Comportement vis à vis du conducteur pour la maintenance. 6.2.3. Spécifications opératoires et technologiques Les spécifications opératoires concernent la définition des grandeurs et précisions. La précision sur les grandeurs affichées doit être de l'unité. Les spécifications technologiques relatent: - les caractéristiques électriques des interfaces, - les contraintes de temps, - les contraintes de réalisation.
-A- INTERFACES

2 types d'interfaces sont à considérer: - le couplage entre la voiture et le système, - le couplage avec l'utilisateur. Pour les interfaces voiture-système: - codeur incrémental pour les mesures Vitesse et Distance, 10 impulsions par tour de roue, - contact fermé, pour vitesse enclenchée et freinage, - commande électrique entre 0 et 8V pour la position de la valve. M.C.S.E 69

Partie 1 - PRESENTATION DE LA METHODOLOGIE Pour l'interface utilisateur, il a été décidé d'utiliser un dispositif d'affichage type LCD, et un ensemble de touches pour sélectionner le mode souhaité. Ci-après, voici une esquisse de cette interface. 2 touches sont situées en face arrière pour l'étalonnage.

VITESSE km/H
Maintenance Indicateurs Maintenance

Vitesse moyenne km/h

+
Consommation moyenne litres/100km

1
effectuée 7500

2
15000

3
30000

SELECTION DU MODE

Activation

Arrêt

Accélération

Retour régime précédent

Ajout carburant

Début trajet

Demande moyenne km

-Figure 6.5- Esquisse de l’interface utilisateur. L'entrée de la quantité du carburant se fait par les touches + et - au lieu d'un clavier numérique. Pendant cette entrée qui débute dès le premier appui sur +, l'affichage se fait sur l'afficheur de la consommation moyenne. La quantité moyenne pour 100 Km s'obtient après appui de la touche "ajout carburant". Le comportement pour cette fonction est le suivant.

Affichage consommation moyenne

appui sur + Q=0

Réglage quantité par + et - de Q et affichage quantité

T = 10 s sans appui sur + ni -

ajout carburant CM = Q * 100 / D

-Figure 6.6- Comportement pour le dialogue consommation moyenne.
-B- CONTRAINTES DE TEMPS

Pour la stabilité de la régulation, la commande de position de la valve ne doit pas excéder une période de 1s (ce qui n'est pas une contrainte sévère). 70 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION Le délai de réaction du système pour les demandes du conducteur doit être de l'ordre de 1s au maximum, sauf pour le freinage qui doit être le plus court possible.
-C- CONTRAINTES DE REALISATION

L'ensemble doit être développé sur la base de la technologie à microprocesseur. La quantité de systèmes à produire pouvant être élevée, le coût de reproduction doit être le plus faible possible. Le système est alimenté par la batterie. Même sur débranchement de celle-ci, le système doit mémoriser les grandeurs essentielles: Kilométrage, paramètres d'étalonnage ... Les contraintes d'environnement concernent, la température, l'hygrométrie, les vibrations. 6.3. CONCEPTION FONCTIONNELLE La conception fonctionnelle débute par le développement d'une première approche fonctionnelle. Celle-ci s'élabore à partir d'une délimitation des entrées/sorties fonctionnelles du système, en recherchant les fonctions essentielles nécessaires pour satisfaire les spécifications. La recherche de la solution doit être purement fonctionnelle en décelant les variables internes caractéristiques. Normalement, si les spécifications fonctionnelles ont été bien élaborées, on doit y retrouver par lecture ces grandeurs essentielles. Il faut éviter de considérer les interfaces nécessaires pour l'observation des grandeurs ou pour les commandes, pour ne considérer que les vraies grandeurs de l'application. Cette remarque est essentielle pour une bonne délimitation des entrées/sorties. La méthode préconisée conduit ainsi à développer une solution indépendante de la technologie. Cette deuxième étape conduit à l'obtention du premier niveau interne de la solution. 6.3.1. Délimitation du système Beaucoup d'événements proviennent du conducteur: appui sur des poussoirs, entrée de la quantité de carburant. De manière à se rendre indépendant de l'interface utilisateur, toutes les commandes sont considérées comme des messages. Pour l'affichage, toutes les sorties seront aussi des messages, chacun contenant la nature de la grandeur concernée. Les grandeurs à observer sur le véhicule sont: la vitesse, la distance totale parcourue depuis sa mise en service, l'état freinage et l'état vitesse enclenchée. La délimitation du système avec les entrées/sorties s'obtient donc en remplaçant tous les liens avec l'environnement exprimés dans la spécification par les relations appropriées du modèle fonctionnel: synchronisation, variable d'état, transfert de messages. La figure 6.7 représente cette délimitation. On considère à ce stade que le système sera alimenté par la batterie à travers la clé de contact. Ainsi, durant la conception il n'est pas utile de prendre en compte les événements "Marche" et "Arrêt" du moteur. M.C.S.E 71

Partie 1 - PRESENTATION DE LA METHODOLOGIE

CMD Conducteur

AFF Conducteur

SYSTEME
freinage

A

Vitesse enclenchée

CONCEVOIR

Cmd_Valve Voiture

Voiture

V D

-Figure 6.7- Délimitation du système. Toutes les variables utilisées en entrée et sortie doivent être spécifiées: - FREINAGE, VITESSE ENCLENCHEE: booléen - V: 0 à 199KM/H - D: 0 à 100000 KM - Cmd_Valve: 0 à Max - CMD = [Maintenance assurée | Activation régulateur | Arrêt régulateur | Début accélération | Fin accélération | Retour régime précédent | Start Mesure Km | Stop Mesure Km | Start Trajet | Demande VM | Quantité carburant : 0 à 99l ] - AFF= [Vitesse : 0 à 199 Km | Vitesse Moyenne: 0 à 199 Km | Consommation: 0 à 99 l | Maintenance + cas ] avec cas indiquant l'un des 3 cas de maintenance. Le clignotement s'obtient par affichage successif des messages "Maintenance" et "nul". 6.3.2. Première structure fonctionnelle Cette première structure se déduit d'une analyse efficace des spécifications fonctionnelles, en recherchant tout particulièrement les grandeurs internes strictement nécessaires pour résoudre le problème. 72 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION Les phases à suivre sont: analyse-décomposition, élaboration, vérification.
-A- ANALYSE

D'après les spécifications, les 3 fonctions du système spécifiées en 6.2.2 par des automates s'avèrent indépendantes: pas de variables communes. Des grandeurs internes apparaissent dans la spécification (conditions ou actions): - VR: pour la vitesse de croisière à suivre, - DV et TV: distance parcourue et temps depuis le début du trajet, - DC : distance parcourue depuis le plein précédent.
-B- ELABORATION DE LA SOLUTION

Proposons la structure fonctionnelle suivante. Elle est basée sur l'analyse précédente en considérant la grandeur VR comme essentielle. Vis à vis des 2 entités conducteur et voiture, elle est conforme à une décomposition du type supervision/commande: supervision comme fonction liée au conducteur, et commande comme fonction de contrôle du véhicule.

CMD

AFF

SUPERVISION
D

VR

MODE

V CMD_VALVE

PAS HORLOGE

CONTROLE-VITESSE

-Figure 6.8- Première esquisse fonctionnelle. La fonction CONTROLE_VITESSE est activée par un événement périodique servant de pas d'échantillonnage pour la régulation. La variable MODE définit les 3 cas de fonctionnement de cette fonction: MODE: (ARRET, REGUL, ACCEL). Le mode REGUL correspond aux 2 états (1) et (2) de la spécification pour le véhicule figure 6.2, le mode ACCEL correspond à l'état (3) pour un accroissement automatique de la vitesse, le mode ARRET aux autres états. De manière à disposer d'une solution homogène pour l'activation de supervision, il a été décidé d'intégrer comme messages dans CMD les événements FREINAGE ou VITESSE NON ENCLENCHEE et FREINAGE et VITESSE ENCLENCHEE. Ainsi SUPERVISION est une action temporaire qui traite en séquence le flot des événements. Ceci revient à considérer comme messages toutes les transitions externes utilisées dans les automates de spécification. M.C.S.E 73

Partie 1 - PRESENTATION DE LA METHODOLOGIE
-C- VERIFICATION

Avant de poursuivre le raffinement, il s'agit de s'assurer que la solution proposée permet de satisfaire les spécifications. Les automates données dans la spécification sont à implanter dans SUPERVISION. Les 2 phases: Régulation vitesse (1), et Rattrapage vitesse croisière (2) sont regroupées et implantées dans CONTROLE_VITESSE. Ceci est spécifié par l'état REGUL de MODE. La transition entre phase 2 et phase 1: V#VR, est élaborée en interne de CONTROLE_VITESSE. Autre remarque: l'affichage de V doit se faire régulièrement pour une indication correcte de la vitesse: pas possible avec la solution proposée car SUPERVISION est une fonction temporaire synchrone à CMD. De plus une variable T est nécessaire pour la mesure du temps depuis le début du trajet. Enfin SUPERVISION doit avoir un caractère permanent pour suivre le kilométrage du véhicule D pour la maintenance. Il faut aussi un clignotement du message Maintenance. La solution corrigée fait apparaître en supplément, la fonction MAINTENANCE activée toutes les secondes et la fonction GENERATION_TEMPS.

CMD

SUPERVISION
AFF_S V D VR MODE T T Etat maintenance Maintenance AFF_M HORLOGE PAS

AFF

D

VR

MODE

Génération Temps

V V AFF_V CMD_VALVE

CONTROLE-VITESSE

-Figure 6.9- Première structure fonctionnelle. L'affichage de V nécessite la liaison entre la fonction CONTROLE_VITESSE et la sortie vers le port AFF. Ce type de vérification se fait aussi assez naturellement en poursuivant le raffinement complet; une cohérence en final valide la première approche. Des retours-arrières sont souvent nécessaires. Toutefois une première structure simple dès le départ conduit à une meilleure décomposition. 6.3.3. Raffinement Pour poursuivre la conception, il s'agit de reprendre chacune des fonctions pour exprimer une solution, qui peut à nouveau être une structure fonctionnelle, ou sinon une description 74 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION comportementale. Pour chacune, il faut tout d’abord se poser la question de savoir s’il n’est pas possible d'en donner une spécification comportementale. Si la fonction a un comportement séquentiel, ceci est possible. C'est le cas de CONTROLE_VITESSE qui est activée par l'événement PAS. SUPERVISION est activée par chaque message de CMD. Cette fonction a donc un comportement séquentiel. Toutefois, plusieurs automates sont à inclure dans sa description comportementale. Ainsi, à ce stade, le raffinement fonctionnel n'est pas conseillé car il introduirait alors une complexité non utile pour l'implantation. On détaille dans la suite le comportement séquentiel de chaque fonction. 6.3.4. Comportement de contrôle vitesse Sur passage en mode REGUL, cette action temporaire synchrone à PAS (1 seconde) doit assurer tout d'abord le rattrapage de la vitesse de croisière par une accélération constante, puis la régulation de vitesse. En mode ARRET, le système ne doit pas agir . Le comportement déduit des spécifications est donc le suivant.

INACTIF

MODE = REGUL

ACCELERATION ( pour rattrapage vitesse)
MODE = ARRET

MODE = ARRET

V≈VR (à ± 3km/H près)

MODE = REGUL

REGULATION

ACCROISSEMENT LINEAIRE

MODE = ARRET

MODE = ACCEL

-Figure 6.10- Spécification pour CONTROLE_VITESSE. Le comportement pour les 2 phases Accélération et Régulation, a été précisé dans les spécifications fonctionnelles. La grandeur accélération se déduit par différence de 2 mesures consécutives de la vitesse (séparées d'une seconde). L’état accélération manuelle par le conducteur (prioritaire) de la figure 6.2 est assuré par l’état Régulation. De cette analyse, la description algorithmique se déduit directement par simple transcription de la spécification ci-dessus. La définition des types de variables est la suivante:

M.C.S.E

75

Partie 1 - PRESENTATION DE LA METHODOLOGIE
T_VITESSE=0.. 199; T_AFF= Record NATURE:("vitesse","vitesse moyenne", "consommation","nul","maintenance"); VITESSE: T_VITESSE; CONSOMMATION: T_QUANTITE; end; action CONTROLE_VITESSE sur événement PAS avec (entrées var V, VR: T_VITESSE; var MODE: (ARRET,REGUL,ACCEL); Sorties var CMD_VALVE: 0..Max; message AFF_V: T_AFF); const Max, K, INC:... ; var ETAT:(inactif, accélération, régulation, accroissement); R:0...Max; A, VPREC: T_VITESSE; A_MESS: T_AFF; begin ETAT:=inactif; CMD_VALVE:= 0; VPREC:=V; CYCLE PAS: begin case ETAT of inactif: if MODE = REGUL then ETAT:= accélération; accélération: if MODE = ARRET then begin ETAT:=inactif CMD_VALVE:= 0; end else if (V>VR-3) and (V<VR+3) then ETAT:= Régulation else begin A:= V-VPREC; if A>3 then CMD_VALVE:=0 else if A<1 then CMD_VALVE:=Max else CMD_VALVE:=K*(2-A); end; Régulation: if MODE = ARRET then ETAT:=inactif else if MODE = ACCEL then ETAT:= accroissement else begin if V-VR>3 then CMD_VALVE:=0 else if V-VR<-3 then CMD_VALVE:=Max else CMD_VALVE:= (Max*(VR-V)/3+Max)/2; end; accroissement: if MODE = ARRET then ETAT:= inactif else if MODE = REGUL then ETAT:= regulation else VR:= VR+INC; end case; VPREC:=V; A_MESS.NATURE = "vitesse"; A_MESS.VITESSE:= V; send(A_MESS,AFF_V); end; end cycle end CONTROLE_VITESSE;

76

M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION 6.3.5. Comportement de supervision Pour chaque message extrait de CMD, cette action assure les transitions d'états et les actions nécessaires. D'après les spécifications, cette fonction doit implanter 3 automates et piloter celui de la maintenance. Pour la régulation, le comportement est simplifié puisque 2 états sont réalisés par la fonction CONTROLE_VITESSE. La spécification de T_CMD est la suivante:
T_CMD = Record NATURE: (Maintenance_assurée, quantité_carburant, Start_trajet, demande_VM, activation, arrêt,début_accélération,fin_accélération, freinage,fin_freinage,start_mesure_Km, stop_mesure_Km,Retour_vitesse_croisière); QUANTITE: 0..100; end; action SUPERVISION sur message E_CMD:T_CMD avec ( entrée var D: T_DISTANCE; entrée/sortie var T: integer; Sortie var VR:T_Vitesse; var MODE:(ARRET,REGUL,ACCEL); var ETAT_MAINTENANCE:(attente ...); message AFF_S:T_AFF); Var ETAT:(normal,régulation,manuel,inactif,étalonnage); DC,DT,DM: T_Distance; A_MESS:T_AFF; ETAT_FREIN:= (vrai,faux); begin DC:= 0; DM:=0; DT:=0; MODE:=ARRET; ETAT_MAINTENANCE:=attente; ETAT:=normal; cycle E_CMD: case E_CMD.NATURE of Maintenance_assurée: ETAT_MAINTENANCE:=Attente; Quantité_carburant: begin A_MESS.NATURE:="consommation"; A_MESS.consommation:= E_CMD.quantité/(D-DC); send(A_MESS,AFF_S); DC:=D; end; Start_trajet: begin DT:=D; T:=0; end; Demande_VM: begin A_MESS.NATURE:="vitesse_moyenne"; A_MESS.vitesse := (D-DT)/T; Send (A_MESS,AFF_S); end; activation: if (ETAT = normal)and (V>50) then begin VR:=V; MODE:=REGUL; ETAT:=Régulation; end;

M.C.S.E

77

Partie 1 - PRESENTATION DE LA METHODOLOGIE
Arrêt_régulation: begin ETAT:=normal; MODE:=ARRET; end; Début_accélération: if ETAT=Régulation then begin ETAT:=inactif; MODE:=ACCEL; end; fin_accélération: if ETAT=inactif then begin VR:= V; ETAT:=Régulation; MODE:=REGUL; end; freinage: if ETAT=Régulation then begin ETAT:=inactif; MODE:=ARRET; ETAT_FREIN:= vrai; end; fin_freinage: ETAT_FREIN:= faux; Retour_vitesse_croisière: if ETAT=inactif and ETAT_FREIN=faux then begin ETAT:=régulation; MODE:=REGUL; end; Start_Mesure_Km: if ETAT=normal then ETAT:=Etalonnage; Stop_Mesure_Km: if ETAT=Etalonnage then begin Calcul constante étalonnage; ETAT:=normal; end; end case; end cycle; end SUPERVISION;

On constate que l'écriture est relativement simple puisque pour chaque message reçu, l'action vérifie si le système est dans un état correct (réceptivité). Si oui, elle réalise les actions correspondantes. Si non, l'événement est simplement éliminé. L'algorithme découle de la spécification par simple traduction. 6.3.6. Comportement de maintenance Cette fonction est temporaire synchrone à PAS de manière à suivre l'évolution de la distance D et produire tout particulièrement l'affichage avec clignotement entre -250 Km et 50 Km. Le comportement a été donné dans les spécifications sous la forme d'un automate en 3 états. L'initialisation dans l'état "attente" est effectuée par SUPERVISION dès la réception de l'événement "Maintenance effectuée". 78 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION

Type T_Maintenance=(attente, intermittent, permanent); Action MAINTENANCE sur événement PAS avec (entrée/sortie Var ETAT_MAINTENANCE:T_Maintenance; sortie message AFF_M:T_AFF); Var ETAT: (éteint,allumé); A_MESS:T_AFF; begin ETAT:= éteint; cycle PAS: case ETAT_MAINTENANCE of attente: begin A_MESS.NATURE:= "nul"; Send(A_MESS, AFF_M); if (D+250) DIV 7500 = 0 then ETAT_MAINTENANCE:=intermittent; end; intermittent: if (D+50)DIV 7500 = 0 then ETAT_MAINTENANCE:=permanent else case ETAT of allumé: begin ETAT:=éteint; A_MESS.NATURE:="nul"; Send(A_MESS,AFF_M); end; éteint: begin ETAT:=allumé; A_MESS.NATURE:= "maintenance"; Send(A_MESS,AFF_M); end; end case; permanent: begin A_MESS.NATURE:="maintenance"; Send(A_MESS,AFF_M); end; end case; end cycle; end MAINTENANCE;

6.3.7. Comportement de génération_temps Cette action assure simplement la mise à jour de T par ajout de la valeur DUREE_PAS sur chaque événement PAS.
action GENERATION_TEMPS sur événement PAS avec (entrée/sortie T:integer); const DUREE_PAS= 1s; begin cycle PAS: T:= T + DUREE_PAS; end cycle; end GENERATION_TEMPS;

M.C.S.E

79

Partie 1 - PRESENTATION DE LA METHODOLOGIE 6.4. DEFINITION DE LA REALISATION Le modèle fonctionnel a été obtenu en ignorant volontairement tous les aspects technologiques telles que la nature des capteurs pour D et V, les caractéristiques de l'interface utilisateur, ce qui a conduit à une solution indépendante de la technologie. Bien entendu, la solution à déduire durant cette étape devra tenir compte de toutes ces contraintes technologiques ainsi que des contraintes de temps . Durant cette troisième étape qui permet d'obtenir le niveau 2 de la description interne, ou description exécutive, il faut définir: - les spécifications du support matériel, - les spécifications de l'implantation logicielle. Pour cela, il s'agit d'exploiter plus particulièrement les spécifications technologiques. La démarche à suivre est la suivante: - introduction de la répartition géographique si nécessaire (ce n'est pas le cas pour ce problème), - introduction des interfaces avec l'environnement, - analyse des contraintes de temps, - répartition matériel/logiciel, - spécification de l'implantation logicielle, - spécification du support exécutif. 6.4.1. Introduction des interfaces Il s'agit d'ajouter en périphérie de la solution fonctionnelle, les couplages avec les 2 entités de l'environnement que sont la voiture et le conducteur. Pour cela, basons-nous sur le modèle générique proposé par HATLEY (Architecture template), qui propose une décomposition de la solution de réalisation en 4 sous-ensembles telle que l’indique la figure 6.11 [HATLEY-87]. Le modèle fonctionnel trouvé précédemment est le noyau dur de l'application comme invariant vis à vis de la technologie employée. La séparation volontaire de l'interface utilisateur des autres entrées/sorties permet d'y attacher un intérêt particulier avec comme objectif de rechercher un produit particulièrement convivial. Le sous-ensemble: -Maintenance, auto-test...- fait réfléchir sur les constituants supplémentaires de manière à améliorer la fiabilité et la sécurité de l'application. Ce sousensemble n'est pas traité dans cet exemple.
-A- INTERFACES D’ENTREE

On s'intéresse ici à toutes les grandeurs à observer sur le véhicule. D'après les spécifications technologiques, la vitesse V n'est pas directement observable. Un codeur impulsionnel sur une roue est utilisé à cet effet. Il en est de même pour D. V se déduit de l'observation du nombre de tours de roue et donc des impulsions du codeur pendant une durée déterminée (qui peut être la seconde). C'est l'utilisation du principe du fréquencemètre. V = K * NB_IMP 80 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION

Interface utilisateur

Modèle fonctionnel Entrées
procédé physique indépendant de la technologie

Sorties
procédé physique

Maintenance
auto-test , redondance , ...

-Figure 6.11- Modèle générique de réalisation. K est une constante qui dépend de la taille des pneus. Cette grandeur K est donc le résultat de la phase d'étalonnage, déjà développée dans le modèle fonctionnel. K doit correspondre au déplacement pour 1/10e de tour de roue, le codeur fournissant 10 impulsions par tour. D est l'intégrale de V. Elle s'obtient aussi par cumul du nombre de tours de roue multiplié par la distance parcourue par tour. Ainsi pour chaque impulsion du codeur: D=D+K. La solution fonctionnelle pour les 2 observations D et V est la suivante.
ETAT ETALONNAGE

Evaluation de K
produit durant l’étalonnage par SUPERVISION K D IMP

Evaluation de V et D
V

H (1 s)

Horloge
Observation V et D

-Figure 6.12- Structure fonctionnelle pour les observations de V et D. M.C.S.E 81

Partie 1 - PRESENTATION DE LA METHODOLOGIE Il faut remarquer que l'évaluation de K qui ne se fait que durant l'état d'étalonnage, nécessite l'observation du nombre d'impulsions durant 1 Km, ce qui permet de déduire la longueur d'un tour de roue. Aussi l'interface avec le modèle fonctionnel est modifié pour la prise de connaissance de la variable ETAT de SUPERVISION qui indique, si le système est dans la phase d'étalonnage ou non. La spécification se complète par les descriptions comportementales des actions.
action EVALUATION_V_ET_D sur événements IMP et H avec (entrée var K: T_K; entrée/sortie var D:T_DISTANCE; sortie var V :T_VITESSE); Var NB_IMP:integer; begin V:=0; NB_IMP:=0; cycle H: begin V:= K * NB_IMP; NB_IMP:=0; end; IMP: begin NB_IMP:= NB_IMP + 1; D:= D + K; end; end cycle; end EVALUATION_V_ET_D; action EVALUATION_K sur événement IMP avec (entrée var ETAT_ETALONNAGE:(étalonnage, autre); sortie var K: T_K); var ETAT: (arrêt,marche); N: integer; begin ETAT:=arrêt; cycle IMP: case ETAT of arrêt: if ETAT_ETALONNAGE=étalonnage then begin ETAT:=marche; N:=0; end; marche: if ETAT_ETALONNAGE<>étalonnage then begin ETAT:=arrêt: K:= 1000/N; end else N:= N+1; end case; end cycle; end EVALUATION_K; -B- INTERFACE DE SORTIE

La seule sortie vers le véhicule est la commande de la valve. Il s'agit d'une commande électrique comprise entre 0 et 8 V. Il faut donc transformer la grandeur CMD_VALVE en une grandeur analogique. 82 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION Technologiquement, la conversion numérique analogique peut se faire simplement par une commande du type PWM (modulation de largeur). Les avantages par rapport à un convertisseur numérique-analogique conventionnel sont: - fonctionnement purement numérique, - commande de puissance en tout ou rien, - possibilité d'isolation opto-électronique. La solution fonctionnelle est donnée ci-après sans détailler le comportement des actions élémentaires. Le principe pour la fonction est l'utilisation d'un décompteur P initialisé tous les N∗T à la valeur CMD_VALVE et décrémenté tous les T. Tant que P est strictement positif , CA est actif.

Cmd_Valve

Génération PWM
pour Cmd_Valve = max => P = N pour Cmd_Valve = 0 => P = 0 Sinon P = Cmd_Valve

CA

HORLOGE

HT ( 100 µs à 1 ms )

8v

CA HT

ov

PxT NxT

T

-Figure 6.13- Interface de sortie pour la commande Valve.
-C- INTERFACE UTILISATEUR

Pour être indépendant de la technologie, tous les événements en provenance ou vers le conducteur ont été spécifiés comme messages. Par exemple, la solution pour la méthode retenue dans les spécifications technologiques pour l'entrée de la quantité de carburant n'a pas été développée dans le modèle fonctionnel car dépendante de l'interface utilisateur. Cette interface a été esquissée figure 6.5. On constate que le conducteur dispose de 10 touches sur lesquelles il peut appuyer à volonté plus 2 en face arrière. En observation, 4 zones d'affichage existent, ce qui donne au total 8 digits décimaux et 3 états binaires. La gestion de l'interface est basée sur la scrutation périodique de l'ensemble des touches, avec exclusion pour des appuis simultanés. L'affichage s'obtient par décodage des messages et transmission vers l'afficheur destinataire. Un cas particulier apparait pour la sélection de la quantité de carburant: l'affichage doit suivre l'évolution engendrée par les touches + et -. Pour cela, l'interface produit directement des messages AFF. Pour répondre à ces spécifications, la solution fonctionnelle retenue est donnée figure 6.14. M.C.S.E 83

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Interface utilisateur

Touches [1..12]

HORLOGE HS GESTION DES TOUCHES AFFICHAGE

AFFICHEURS

CMD SUPERVISION

AFF

-Figure 6.14- Interface utilisateur. On ne détaille pas dans la suite le comportement pour ces 2 fonctions. Il faut savoir que l'interface utilisateur est toujours coûteux en lignes de programmation et donc en temps de développement. L'approche fonctionnelle ci-dessus permet de programmer l'interface utilisateur selon un modèle général, ce qui conduit à une meilleure efficacité. 6.4.2. Analyse des contraintes de temps Cette analyse considère: - les fréquences d'activation de toutes les actions (fréquence des événements), - les temps de réponse pour les événements de sortie. Elle doit conduire à pouvoir décider de la répartition matériel/logiciel, avec comme principe de réalisation d'inclure le maximum de fonctions dans la partie logicielle. Avant de décider de la répartition, il faut réduire au maximum le nombre de générateurs d'événements du type horloge. Pour cela, on part d'un générateur correspondant à la fréquence maximale. Les autres événements s'obtiennent alors par division en fréquence. On rappelle par la figure 6.15 la structure fonctionnelle complète considérée pour l'analyse des contraintes de temps puis ensuite le choix de la répartition matériel/logiciel. Les événements recensés sur la structure fonctionnelle globale ci-dessus sont: - CMD: période négligeable définie par la réaction de l'utilisateur, - IMP: 500 Hz approximativement pour 200 Km/h et des pneus de 1m, - H: 10 KHz (pour HT), - HP: 10 à 100 Hz (pour HS, PAS et H1s). 84 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION

Touches Gestion des touches CMD

Interface utilisateur
Afficheurs AFF SUPERVISION AFFICHAGE

Etat Maint

HP VR T
MODE

Mainte nance

Adaptation des entrées
ETAT_ ETAL.

Adaptation aux sorties
Géné. temps HP

Etalonnage
K D

Cmd_Valve CA CONTROLE-VITESSE Génération PWM HP
V

IMP

Evaluation V et D DIV par 1000

H

HP Horloge

PARTIE LOGICIELLE
H

HP

PARTIE MATERIELLE

-Figure 6.15- Solution fonctionnelle complète. Pour les temps de réponse, on ne retrouve qu'une seule contrainte dans les spécifications technologiques: réaction en 1s qui n'est pas du tout une contrainte sévère pour une solution électronique. Par contre, le freinage doit être immédiat. On prendra pour cela un pas d'échantillonnage de 0,1s. Donc Hp = 10 Hz. 6.4.3. Répartition matériel/logiciel L'analyse consiste tout d'abord à classer les fonctions en 2 catégories: - celles obligatoirement réalisées par matériel, par exemple, les horloges, les fonctions rapides c'est-à-dire période < à 50 à 100 µs, - celles implantables en logiciel ou en matériel. Pour cette deuxième catégorie et pour décider si une fonction est implantable en logiciel, il faut observer la fréquence d'activation et évaluer le temps d'exécution probable pour la fonction avec l'hypothèse technologique choisie ou imposée. Les 2 fonctions qui peuvent poser problème sont: - génération PWM, - Diviseur/1000. On retient ici une solution matérielle pour la fonction Génération PWM pour des raisons technologiques, diviseur/1000 étant implantable facilement en logiciel. S'ajoute obligatoirement la fonction Horloge. Toutes les autres fonctions sont implantables sur un seul microprocesseur, ceci au vu des fréquences d'activation et des temps d'exécution qui restent faibles. Le calcul du taux d’occupation du microprocesseur valide un tel choix. 6.4.4. Spécification de l'implantation logicielle 9 fonctions à évolution parallèle sont à implanter en logiciel, bien entendu sur un microprocesseur qui "n'est qu'une machine séquentielle". M.C.S.E 85

Partie 1 - PRESENTATION DE LA METHODOLOGIE Spécifier l'implantation logicielle revient à préciser l'ordonnancement de ces fonctions sur un microprocesseur, c'est-à-dire le déroulement temporel. Pour cela, il faut définir, la priorité de toutes les fonctions, celles qui se déroulent sous interruption, les synchronisations logicielles entre fonctions temporellement dépendantes. Quelques principes simples aident à définir la solution. Les fonctions activées par une fonction matérielle sont implantées sous interruption. La priorité d'exécution pour ces fonctions est proportionnelle à la fréquence d'activation. Toutes les fonctions activées par un même événement sont traitées en séquence. Les fonctions logicielles permanentes s'implantent comme tâche de fond. Les synchronisations par événements ou messages s'implantent par appel procédural si la fonction destinatrice peut être plus prioritaire à l'exécution. On remarque une difficulté due au fait que l'action évaluation D et V est activée par 2 événements. La solution consiste à scinder cette action en 2 parties, chacune activée par un événement. La variable NB_IMP, commune aux 2 parties, est alors une variable partagée nécessitant une exclusion mutuelle. Une définition d'implantation est donnée ci-dessous selon un graphe qui exprime: - en horizontal: les entrées en provenance du matériel à gauche, au centre les fonctions logicielles, à droite les sorties vers le matériel, - en vertical: la répartition des tâches selon une priorité croissante et les relations logicielles.
Priorité croissante

IMP Etalonnage

Evaluation V et D (1) Affichage
NB_IMP (AFF)

Afficheurs

K VR

SUPERVISION
MODE T ETAT (CMD)

Cmd_Valve Evaluation V et D (2) contrôle Génération vitesse temps Maintenance Gestion touches

Touches

Diviseur H TACHE DE FOND ( vide )

matériel

Logiciel

matériel

-Figure 6.16- Spécification de l'implantation logicielle. La tâche la moins prioritaire est la tâche de fond. Le double trait vertical représente un appel procédural utilisable uniquement dans le sens croissant. 86 M.C.S.E

Ch 6 - UN EXEMPLE D’ILLUSTRATION L'implantation proposée conduit à aucune fonction dans la tâche de fond. Celle-ci peut alors servir pour introduire des auto-tests par exemple. La vérification de cohérence de l'implantation consiste à s'assurer que toutes les contraintes temporelles seront satisfaites dans les cas les plus défavorables et que le processeur reste opérationnel: taux d'occupation < 1 pour les actions autres que celles incluses dans la tâche de fond. Avec le diagramme ci-dessus, la vérification est facile en s’asssurant que: - Tréponse max < T exécution max, - Tocc max = Σ(Texécution max/période minimum activation) < 1. Des points complémentaires sont à étudier pour spécifier complètement l'implantation: il s'agit du format des variables internes pour satisfaire les précisions, puis les techniques de calcul. En particulier, il faut élucider le format de K, V, D, CMD_VALVE puis les calculs de multiplication et de division. Bien entendu, les formats seront entier ou fractionnaire et les opérations seront réalisées en entier. 6.4.5. Spécification de la réalisation matérielle Cette dernière phase conduit à définir le support matériel par une structure d'exécution. Elle se déduit de la structure fonctionnelle complète en remplaçant par abstraction, toutes les actions implantées en logiciel par un processeur programmable qui en assurera l'exécution.

TOUCHES

AFFICHEURS

Processeur Programmable
RAM interne sauvegardée par batterie
IMP

ROM ou EPROM interne 4Ko 2 entrées IT entrées et sorties logiques pour Touches , Afficheurs et Cmd_Valve.
Cmd_Valve Générateur PWM CA

H HORLOGE

-Figure 6.17- Spécification de la réalisation matérielle. La spécification du processeur pouvait être plus générale en y incluant l'horloge et même le générateur PWM. M.C.S.E 87

Partie 1 - PRESENTATION DE LA METHODOLOGIE C'est à partir de ces spécifications que le technicien chargé de la réalisation, spécialiste des composants VLSI existant sur le marché, tenant compte des contraintes de réalisation imposées, élabore une solution matérielle détaillée sous la forme d'un schéma logique. Pour cette application, effectuée durant 1989, le choix peut se faire par exemple entre les monochips: - famille INTEL 8051 et dérivés, - famille NEC 78 XX, - famille MOTOROLA 687XX. 6.5. CONCLUSIONS : QUELQUES REMARQUES A l'issue de cette présentation de la démarche sur un exemple de cahier des charges, faisons un point rapide sur l'apport de la méthodologie MCSE. Tout d'abord, après avoir pris uniquement connaissance du cahier des charges et donc avant d'avoir lu la solution proposée, le lecteur pouvait-il répondre aux 3 questions essentielles qui intéressent le demandeur: - temps de développement (durée du contrat), - coût du développement (obtention d'un prototype à caractère industriel), - coût de reproduction de la solution. Pour pouvoir y répondre, il faut tout de même avoir une idée assez précise de la solution: matériel pour l'évaluation du coût, complexité du logiciel pour l'évaluation du temps. Il est fort à parier que peu de lecteurs se sont sentis "à l'aise" face à ce cahier des charges, sauf expérience importante dans le domaine du développement des systèmes à microprocesseurs. Concernant la compréhension de la méthode et de la solution, après la lecture de ce document de conception, on peut penser que chacun a une idée claire: sur le fonctionnement du système, sur les principes suivis pour l'élaboration de la solution, sur des solutions à des problèmes classiques trouvés dans une variété d'applications. Si c'est le cas, le lecteur a déjà assimilé des éléments essentiels de la méthodologie, a enrichi ses compétences dans le domaine des applications temps-réel, et ceci par simple lecture d'un document de solution. La facilité de compréhension de la solution résulte des modèles de description utilisés qui sont essentiellement graphiques: automates pour les spécifications, structure fonctionnelle, structure d'exécution, schéma d'implantation logicielle. Ensuite, la méthodologie part du cahier des charges et fournit toutes les informations nécessaires pour la réalisation: architecture de la solution matérielle, organisation du logiciel, description algorithmique en Pascal du comportement des fonctions. Par vérification, elle garantit a priori l'obtention d'une solution opérationnelle. Dernier point: avant même de débuter toute réalisation pratique (maquette, programmation) un document complet existe: comme guide à la compréhension, comme support pour une analyse critique de la solution, plus tard comme document de maintenance du produit. Ultérieurement, Il faudra seulement y ajouter les schémas de la réalisation matérielle, et un listing commenté pour le logiciel.

88

M.C.S.E

BIBLIOGRAPHIE 1

OUVRAGES [CALVEZ-82] Une méthodologie de conception des systèmes multi-microordinateurs pour les applications de commande en temps-réel J.P. CALVEZ Thèse de Doctorat d'Etat, Université de NANTES novembre 1982 [COHEN-86] The specification of complex systems B. COHEN, W.T. HARWOOD, M.I. JACKSON Addison-Wesley publishing Company 1986 [DASGUPTA-89] The Structure of Design Processes S. DASGUPTA Advances in Computers vol 26 Academic press 1989, P.1-67 [FATHI-85] Microprocessor software Project Management E.T. FATHI, C.V.W. ARMSTRONG Marcel DEKKER, INC N.Y. 1985 [HATLEY-87] Strategies for Real-time System Specification D.J. HATLEY, I.A. PIRBHAI Dorset House Publishing New-York 1987 [JENSEN-79] Software Engineering R.W. JENSEN, C.C. TONIES Prentice Hall International, INC. 1979 M.C.S.E 89

Partie 1 - PRESENTATION DE LA METHODOLOGIE [NIELSEN-88] Designing large Real-time Systems with ADA K. NIELSEN, K. SHUMATE Mac Graw Hill Book Company N.Y. 1988 [RUSKIN-82] What every engineer should know about Project Management A.M. RUSKIN, W.E. ESTES Marcel DEKKER, Inc N.Y. 1982 [WARD-85] Structured Development for real-time systems P.T. WARD, S.J. MELLOR. Vol1: Introduction and Tools Vol.2: Essential modeling Techniques Yourdon Computing series-YOURDON PRESS-Prentice-Hall 1985 [WILSON-86] Systems: Concepts, methodologies and applications B. WILSON John WILEY & SONS N.Y. 1986 ARTICLES [BOASSON-87] Modeling in Real-time Systems M. BOASSON Computer Standards & Interfaces 6-1987, P.107-114 [CALVEZ-84] Méthodologie de conception pour les systèmes complexes de commande en temps-réel J.P. CALVEZ, Y. THOMAS RAIRO Automatique Vol 18 No 2 1984, P.251-266 [CALVEZ-86] Some microsystems design methodology and its application to industrial problems J.P. CALVEZ, E.FRIOT, Y.THOMAS Proceedings of IECON'86, Twelfth annual IEEE industrial Electronics Society Conference MILWAUKEE USA 29 sept-3 oct 1986 P.675-680 [KOOMEN-85] The entropy of Design: A Study on the Meaning of Creativity C.J. KOOMEN IEEE Transaction on Systems, Man, and cybernetics V15 N1 Janv. 1985, P.16-30 [NADLER-85] Systems Methodology and Design G. NADLER IEEE Transactions on Systems, Man, and cybernetics Vol15 N6 nov.1985, P.685-697 90 M.C.S.E

BIBLIOGRAPHIE 1 [WILLIAMS-88] Software Process Modeling: A Behavioral Approach L.G. WILLIAMS Proceedings of 10th International Conference on Software Engineering Singapore 1-15 Avril 1988, P. 174-186

M.C.S.E

91

PARTIE

2

MODELES ET METHODOLOGIES

Avant de décrire en détail la méthodologie MCSE, il est utile de faire un panorama des Méthodologies existantes et des modèles sur lesquels celles-ci sont basées. Cette connaissance se justifie car une méthodologie n'est pas à opposer aux autres. Au contraire, certaines approches, certains points de vue et modèles sont intéressants et exploitables pour la classe des problèmes qui nous préoccupent. Le concepteur découvre ainsi tout ce qu'il peut ou pourrait trouver dans sa "boîte à outils". En développement, les 3 phases qui nous intéressent tout particulièrement pour l'analyse des méthodologies sont celles: de spécification, de conception fonctionnelle ou conception préliminaire ou architecturale, de spécification de la réalisation ou conception détaillée. Lorsqu'une Méthodologie est plutôt spécifique d'une phase, il est alors préférable de parler de METHODE. Une méthode est basée sur l'emploi d'un modèle. La connaissance des modèles est donc essentielle. Une méthodologie globale résulte de la concaténation de plusieurs méthodes, chacune étant plus particulièrement adaptée à une phase. Ceci s'explique par le fait qu'il est nécessaire d'exploiter des concepts différents et donc des modèles différents pour chaque niveau d'abstraction de la solution. Dans cette partie, le chapitre 7 décrit selon un ordre plutôt chronologique les méthodes et méthodologies les plus connues dans le domaine des applications temps-réel. Pour chacune sont indiqués les modèles utilisés. Le chapitre 8 est une synthèse des catégories de modèles les plus employés. Les types de modèles pour la spécification et la conception sont détaillées, en montrant les utilisations préférentielles. Une méthodologie est décrite par une trajectoire dans un ensemble d'espaces de modélisation. Le lecteur peut passer rapidement sur le chapitre 7, par contre il est conseillé de lire plus attentivement le chapitre 8 car il favorise la connaissance des modèles utilisés dans MCSE ainsi que la compréhension de la démarche proposée. M.C.S.E 93

Chapitre 7

PANORAMA DES METHODOLOGIES

Some Methodologies concentrate on the management framework rather than on its technical substance. The danger is that the development team gets locked into a framework that is totally inappropriate for their project. That is why many developers do not like methodologies and think them a waste of time. J.R. CAMERON Ce chapitre présente succinctement les méthodologies existantes dans le domaine des systèmes temps-réel. Afin de pouvoir interpréter les caractéristiques et particularités de chacune, les différences entre elles, rappelons tout d'abord les bases pour toute méthodologie introduites dans la partie 1, puis une classification et un historique des méthodologies. Une méthodologie conduit à exprimer une solution selon un modèle. Elle est donc obligatoirement basée sur l'emploi de modèles de description en entrée et en sortie; ces modèles découlent d'un ensemble de concepts. La méthode se spécifie elle-même par un modèle de réflexion exprimant comment procéder pour spécifier ou concevoir. Les outils comme supports de travail sont nécessaires pour l'analyse, la description, la validation des solutions, la

M.C.S.E

95

Partie 2 - MODELES ET METHODOLOGIES production d'une réalisation. Ils n'ont de signification que comme aide à l'application d'une méthode. Ainsi, une méthodologie peut s'analyser en regardant successivement les 3 points : modèles, méthodes, outils. On se limitera volontairement dans ce chapitre aux 2 points essentiels que sont modèles et méthodes. Concernant le modèle de description d'un système, il ne peut pas se baser sur l'hypothèse que des descriptions à différents niveaux d'abstraction diffèrent seulement par l'échelle: principe du ZOOM. En effet, des composantes différentes interviennent dans un système: vue externe, vue fonctionnelle, vue structurelle, vue matérielle... qui dépendent du point de vue adopté pour l'observation: utilisateur, matériel, logiciel, manager. Pour la compréhension des méthodologies, il est donc utile d'avoir à l'esprit que différents concepts sont nécessaires pour la description selon plusieurs niveaux d'abstraction. A chacun correspond un point de vue: - point de vue externe, - point de vue organisationnel ou structurel, - point de vue temporel, - point de vue des moyens et des ressources Ainsi, une méthodologie est l'agrégation d'un ensemble de modèles et de méthodes. Si une méthodologie peut être analysée sur la base des 3 composantes: -modèle(s), méthode(s), outil(s)-, un autre aspect concerne le style de la procédure de réflexion à suivre qui peut varier d'un style "autoritaire" à un style "libéral". Selon C.J. TULLY, le style doit différer selon les objets concernés [TEICHROEW-83]. Pour qu'une méthodologie soit claire, et non ambiguë, elle doit être autoritaire pour les concepts et modèles, car ceux-ci induisent la précision de la description et ensuite l’efficacité du processus de développement et les outils. Ainsi, sans modèle clair possédant une sémantique explicite, il ne peut y avoir de bonne méthode, a fortiori d’outil efficace. Par contre, la méthode doit laisser toute liberté au concepteur pour les solutions, ceci permet d'exploiter au maximum l'esprit créatif des individus. Ainsi, une méthode se doit d'être l'expression d'un ensemble de conseils, les règles étant exprimées par le modèle. L'efficacité des conseils est un autre critère important de comparaison des méthodes. En effet, l'objectif d'une méthodologie est de permettre à un pourcentage le plus élevé possible de concepteurs de réussir des développements de qualité. 7.1. CLASSIFICATION DES METHODOLOGIES ET HISTORIQUE La classification proposée dans le tableau ci-dessous concerne les méthodologies orientées systèmes temps-réel. Il indique approximativement pour chaque méthodologie la ou les phases du cycle de vie concernées et le concept essentiel en tant que modèle. 96 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

PHASE Spécification

METHODE SADT (Ross) SA (DeMarco) RTSA (Ward, Hatley) JSD (Jackson) SREM (Alford) SD (Yourdon) JSD (Jackson) SYSREM (Alford) DARTS (Gomaa) OOD (Booch) SDWMC (Buhr)

CONCEPT Activités Diagrammes flots de données Extension flots de contrôle Diagramme de Jackson Graphes stimuli-réponse. Diagrammes flot de données et Graphes structurés Structures de données et réseaux de process Diagrammes R-NETS et F-NETS Diagrammes flot de données et et décomposition fonctionnelle. Encapsulation d'objets Machine Charts et comportement temporel Algorithmique modèle objet

Conception

Réalisation

Programmation structurée Programmation orientée objet

La figure suivante résume la génèse des méthodologies en indiquant quelques dépendances temporelles liées aux modèles utilisés.
Encapsulation (Parnas) SMALLTALK (Xerox)

72-75

80
ADA

O.O.D (Booch, Abbott,...)

Structured Analysis (DeMarco) Programmation structurée (Dijkstra,Wirth,Hoare) Structured Design (Yourdon et Constantine) JSP (Jackson) JSD (Jackson) ADA : Nielsen et Shumate SDWA et SDWMC (Buhr) SADT (Ross) RTSA (Ward et Mellor, Hatley et Pirbhai) DARTS (Gomaa) STATEMATE (Lavi et Harel) SREM- SYSREM (Alford)

70 75

75 80

75-77

77 78 70 74 78

M.C.S.E
80 84

88

88

Techniques de réalisation Conception Spécification Méthodologies globales

-Figure 7.1- Evolution dans le domaine des méthodologies. M.C.S.E 97

Partie 2 - MODELES ET METHODOLOGIES L'intérêt pour les méthodologies a commencé vers les années 70 par le niveau le plus proche du produit final, c'est-à-dire la réalisation. Pour le matériel, la complexité des systèmes a conduit les concepteurs à développer des composants de plus en plus complexes mais simples côté utilisation, et ceci par réutilisation des "objets matériels" déjà conçus et en exploitant les possibilités de l’intégration. Pour le logiciel, la complexité des programmes et la variété des processeurs a conduit à la nécessité de disposer de langages dits de haut-niveau, puis d’une méthodologie induisant l'écriture de programmes. De cette manière, est apparue la programmation structurée. L'apport de cette méthode fut important, mais elle ne résolvait que partiellement le problème de la complexité. La méthode découle de la nécessité d'une structuration en modules. C'est le début d'une approche architecturale correspondant à la phase de conception. C'est aussi le tout début de l'approche Objet avec le concept de l'encapsulation. Presque simultanément, par 2 approches convergentes, fut constatée la nécessité de spécifications pour concevoir : - approche par le problème qui se doit d'être défini correctement pour pouvoir rechercher une solution. - approche ascendante à partir de la conception qui justifie un niveau de description de l'objectif à satisfaire. Les méthodes de spécification différaient par le point de vue adopté: diagrammes d'activités (SADT), diagramme flots de données pour les systèmes de traitement, diagrammes entitésrelations pour les systèmes d'information, diagrammes à états finis et du type stimuli-réponse pour les systèmes de commande temps-réel. A partir des années 80 se sont progressivement développées des méthodologies globales couvrant l'ensemble du cycle de vie et ceci par agrégation des méthodes déjà éprouvées (SA/ SD, JSD, SREM-SYSREM). Le concept Objet et l'apparition du langage ADA ont conduit à l'élaboration de nouvelles approches dites Orientées Objet et ceci tout d'abord comme techniques de réalisation (SMALLTALK, ADA), puis comme méthode de conception (OOD, GOOD ...). La suite du chapitre décrit selon un ordre chronologique approximatif les méthodes orientées systèmes les plus connues. 7.2. SADT La méthodologie SADT (Structured Analysis and Design Technique) fut développée entre 1972 et 1977 par SOFTECH [ROSS-85, IGL-82]. Elle couvre essentiellement la phase d'analyse des besoins, celle de conception et de documentation des spécifications, ceci de manière à faciliter la communication entre analystes, développeurs et utilisateurs. 7.2.1. Le modèle La méthode est basée sur l'emploi du modèle SADT. Il permet de décrire, par un ensemble de "boîtes" liées, l'enchaînement des activités (Actigrammes), et la transformation des données (Datagrammes). Chaque "boîte" du diagramme possède 4 types de liens avec son environnement comme l’indique la notation ci-après. 98 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

- les entrées (à gauche), - les sorties (à droite), - les contrôles (au-dessus), - les mécanismes (en-dessous).
entrées

contrôles sorties

mécanismes

Par exemple pour la fonction Y = (A ∗ X + B), X est la donnée d'entrée, Y le résultat en sortie, A et B sont des paramètres pour le contrôle, les mécanismes sont les opérateurs de calcul. Chaque boîte peut se raffiner selon un modèle SADT. Il s'agit donc d'un modèle hiérarchique, mais les relations exprimées sont du type horizontal, le diagramme pouvant se mettre totalement "à plat".
Vue globale du système

1

3 4

Plus général

2

1

2 3

Plus détaillé

-Figure 7.2- Exemple de description hiérarchique SADT. Ce modèle est intermédiaire entre une description structurelle et une description comportementale puisqu'il n'exprime que partiellement des relations d'ordre. Il est proche du diagramme flots de données, sans la notion de mémoire d'informations (data files). Dans SADT, 2 types de modèles sont exploitables: - le modèle Actigramme, qui exprime les fonctions de transformation (Rectangles) agissant sur les données (les liens). Chaque rectangle correspond à des verbes, et les liens à des noms. - le modèle Datagramme, qui donne une représentation opposée. Les rectangles correspondent aux données (les noms), les liens expriment les transformations sur les données. M.C.S.E 99

Partie 2 - MODELES ET METHODOLOGIES Ces modèles sont duaux et redondants, ce qui permet de vérifier la complétude d'une analyse. L'un exprime la décomposition des activités en montrant les objets manipulés, l'autre la décomposition des données en montrant les activités qui les créent ou les utilisent. Comme illustration de ce modèle, on donne ci-après un exemple d'actigramme.
C1 BASE PERIODIQUE

DONNEES CLINIQUES E2
CHOISIR LE PATIENT

Caractéristiques du patient
Numéro de lit Type de mesures Fréquences des mesures ACQUERIR ET VALIDER LES MESURES

1 MESURES ANALOGIQUES E1

Limites spécifiques autorisées Capteurs défectueux

2

Données administratives Paramètres hors plage
CONTROLER LES VALEURS

Paramètres mesurés

3

MESSAGE D’ALERTE
ALERTER

S1 4
ENREGISTRER LES RESULTATS

Heure de l’examen RESULTATS EXAMENS S2

5

-Figure 7.3- Exemple de diagramme SADT. Ce modèle est un outil général pour exprimer, comprendre, manipuler et valider des problèmes. C'est donc typiquement un outil d'aide à la spécification. 7.2.2. La méthode La méthode est celle de l'analyse structurée (SA). Il s'agit tout d'abord d'une discipline de pensée. La méthode est basée sur un travail d'analyse orienté flot de données qui conduit à mettre en évidence les activités. La démarche préconise un raffinement progressif de chaque activité, ce qui conduit à des diagrammes hiérarchiques. Le travail d'analyse conduit à construire un modèle fonctionnel SADT en passant par les phases suivantes: - faire les actigrammes et datagrammes du système, - établir les références croisées entre diagrammes, - corriger, compléter l'analyse fonctionnelle, - introduire le séquencement possible des activités, - identifier les mécanismes qui peuvent servir à la réalisation des fonctions. 2 principes sont cités comme essentiels : - délimitation du contexte. Chaque action doit être vue comme faisant partie d'un système plus large qui lui sert de contexte. 100 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES - limitation de la quantité d'informations. Ceci conduit à limiter la décomposition d'un diagramme à un maximum de 6 boîtes. La première phase est la plus critique. L'obtention des diagrammes résulte au préalable d'interviews d'experts du problème, de manière à rassembler les informations nécessaires. Le travail pouvant se faire en groupe, plusieurs auteurs élaborent la spécification de sousensembles simultanément et indépendamment. Les documents ainsi élaborés sont ensuite assemblés et distribués auprès des lecteurs (au moins les autres auteurs). Chaque auteur, compte-tenu des remarques, corrige et perfectionne son analyse puis le soumet à nouveau pour approbation. Ainsi cette formule de travail basée sur le contrôle et la validation par les autres, assure une évaluation continue de la qualité des documents produits. Cette méthodologie est considérée comme générale et applicable à toute situation et tout problème. D'autre part, elle est utilisable aussi bien au niveau individuel, qu'au niveau équipes pour des grands projets. Intéressante pour l'analyse d'un problème, la méthodologie SADT est limitée à la phase de spécification. 7.3. STRUCTURED ANALYSIS Développée par DEMARCO, il s'agit d'une méthode pour élaborer les spécifications d'un système ou d'une application [DEMARCO-79]. Elle conduit à décrire l'ensemble des activités et les données du problème. Cette méthode qui est typiquement une aide à l'analyse est très appréciable, ce qui explique son utilisation courante en phase de spécification dans plusieurs méthodologies. 7.3.1. Le modèle Le diagramme flot de données est à la base de cette méthode. Il comprend: le diagramme proprement dit qui exprime les relations entre les activités, la spécification des activités en langage naturel structuré, la spécification des données (diagramme de JACKSON et modèle entités-relations). Ce diagramme (Data Flow Diagram: DFD) est approprié pour l'analyse des transformations que subissent des données. Il spécifie le flot de données à travers des fonctions ou des activités à partir d'entrées pour obtenir les données de sortie.4 types d'éléments sont utilisés dans un tel diagramme: - l'activité ou processus: ce sont les actions effectuées sur les données en entrée, - la variable mémoire ou la "file": c'est une mémorisation de données, - la source et le puits: une source est une entité externe comme origine pour des données d'entrée, un puit est une destination pour des données de sortie. - le lien: arc orienté étiqueté par les données en transit. Le diagramme des activités ainsi décrit (figure 7.4) exprime les relations d'ordre entre les fonctions par l'intermédiaire de liens entre les données de sortie d'une fonction et les entrées de fonctions conséquentes. La "File" permet de représenter une mémorisation d'informations pour une exploitation ultérieure. M.C.S.E 101

Partie 2 - MODELES ET METHODOLOGIES

Entité 1
SOURCE

Activité 1
E1
Analyse E1

Activité 2
B
Transformation B en C

Entité 2
C
PUITS

A1 V1 V2

A2 D

Entité 3
PUITS

File

B

Raffinement de A2
V2

A2.1

A2.2

C

A2.3

D

-Figure 7.4- Exemple de diagramme flot de données. Les caractéristiques d'un diagramme correct sont: - toutes les entrées identifiées sont situées à gauche, - toutes les sorties sont situées à droite, - les données doivent être nommées pour l'identification et la définition du contenu, - les fonctions de transformation doivent être nommées pour la compréhension de ce que subissent les données, - il n'y a pas de boucles dans ce type de diagramme. Le modèle est hiérarchique. Ainsi, il favorise une approche descendante par raffinement, puisque chaque activité peut être décrite par un diagramme flot de données. Pour une approche ascendante, il permet aussi d'assurer une coordination pour des approches faites sur des sousensembles par plusieurs analystes. Il est très apprécié comme outil de communication entre concepteur et demandeur durant la phase de spécification. Comme limitation, il exprime ni le contrôle ni le séquencement temporel des actions. Chaque transformation étant procédurale, on peut toutefois y assigner des contraintes de performances le long des chemins d'information. 7.3.2. La méthode La spécification d'une application nécessite tout d'abord d'analyser l'existant pour ensuite caractériser les fonctionnalités souhaitées. Ainsi, 2 niveaux de description sont possibles: le niveau physique, le niveau logique ou conceptuel. La démarche à suivre, proposée par DEMARCO, est présentée par le diagramme flot de données de la figure 7.5. 102 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

2.1 Analyse de l’environnement

2.5

Diagramme Flot de Données (DFD) physique
2.2 BESOINS Transformation équivalence logique

Etude quantitative des options

DFD physique

Etudes des coûts et des bénéfices

2.4 DFD Etablissement des interfaces homme-machine 2.6 Sélection des options

BESOINS PHYSIQUES

logique

DFD physique
2.3 Description logique du système DOCUMENT DE FAISABILITE

BUDGET PLANIFICATION

Nouveau DFD logique Liste de données
2.7 Regroupement des spécifications

DFD sélectionné

SPECIFICATION STRUCTUREE

Description de la transformation

-Figure 7.5- Démarche pour l'analyse dans SA. L’analyse de l’existant faite au niveau physique conduit par abstraction au niveau logique. Les fonctionnalités introduites au niveau logique sont ensuite transcrites au niveau physique. Les phases successives sont donc: - description de l'environnement physique actuel par analyse de cet environnement, - transformation en une description logique équivalente, pour obtenir ce qui est fait (WHAT) et non pas le comment (HOW), - élaboration de la description logique du système souhaité: spécification des DFD, des données, des activités, - dérivation du document final qui consiste en une transformation de la description logique en une description physique: interfaces homme-machine, caractéristiques opérationnelles et performances. Cette méthode s'avère efficace pour une approche globale des applications, ce qui explique son utilisation courante dans plusieurs méthodologies pour la phase spécification. Son efficacité apparaît moindre lorsque l'approche est faite à partir des entités de l'environnement du système. 7.4. STRUCTURED DESIGN Cette méthodologie fut développée par YOURDON et CONSTANTINE puis étendue par MEYERS entre 75 et 80 [JENSEN-79]. Adaptée pour la conception préliminaire, elle est basée sur une technique de transformation reposant sur les critères de qualité d'une décomposition. Son intérêt est certain pour la conception de l'architecture d'un programme. M.C.S.E 103

Partie 2 - MODELES ET METHODOLOGIES 7.4.1. Le modèle Le modèle diagramme structuré (Structure Chart) a pour objectif de décrire l'organisation d'un système sous une forme hiérarchique. Les relations entre les modules sont définies ainsi que les interfaces et la méthode de contrôle.
( un module )

FONCTION

OBTENIR (appel conditionnel)

CALCULER

ASSIGNER

STOP DETERMINER EXTRAIRE (inclusion léxicale) FAIRE (2) FAIRE (1) FORMATER (module prédéfini) IMPRIMER (périphérique physique) TABLE ( ensemble nommé de modules de données) (environnement opérant)

CONTROLE

DONNEES

CONTROLE et ou DONNEES

-Figure 7.6- Exemple d'un diagramme structuré. Les rectangles représentent les modules. Les formes arrondies représentent les données accessibles sous la forme de tables. Le diagramme exprime partiellement le déroulement temporel. Pour cela, il utilise les structures de contrôle de base que sont: séquencement, appel, itération, alternance. Sur les liens hiérarchiques correspondant aux appels procéduraux sont indiquées les informations échangées comme données ou comme contrôle. Le résultat découle d'une analyse structurée. Utilisé comme modèle pour la conception préliminaire d'un logiciel séquentiel, il se situe en amont de la programmation structurée [JENSEN-79, MARTIN-88]. 7.4.2. La méthode Cette méthodologie utilise en entrée les diagrammes flot de données de DEMARCO comme résultat de l'analyse, et les diagrammes structurées et structures de modules pour exprimer la solution. L'approche est basée sur la transformation de diagrammes flots de données d'un problème en une structure de modules, ceci en exploitant une technique d'analyse de la spécification et des critères de décomposition. 104 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES JENSEN et TONIES décrivent la dynamique du processus de conception comme la conjonction de 2 forces: - la première engendre la transformation: flot de données en structure de modules, - la deuxième engendre le passage d'une description de haut-niveau vers une description détaillée à travers des niveaux successifs de raffinement.
Bonne démarche 1 Mauvaise démarche

1

A

A

Raffinement

2 2 B B

Flot de données
Conception Spécification

Modules
Solution

Flot de données
Conception Spécification

Modules
Solution

-Figure 7.7- Démarches pour la recherche d'une structure de modules. Pour élaborer une structure, la technique de transformation consiste à identifier sur la spécification les 3 classes d'éléments pour les activités: entrées, actions, sorties. Le choix de 2 groupes permet de déduire le 3ème. Au niveau le plus élevé, les entrées et sorties proviennent de l'environnement. On peut alors élaborer une structure en 3 branches: entrées/transformation/ sorties. Ceci correspond à diviser le diagramme flot de données en 3 parties, comme l'indique la figure 7.8. Plusieurs solutions sont possibles pour la structure suivant le découpage adopté. Sur le DFD des critères de décision sont à utiliser, à savoir essentiellement : la réduction du couplage entre parties et la cohérence fonctionnelle de chaque partie. Ceci revient à placer les lignes de partition sur le diagramme flot de données de manière à minimiser le nombre de franchissements. Ainsi le diagramme flot de données permet de découvrir par induction la structure de modules et les relations fonctionnelles. La procédure à suivre est donc: - identifier le flot de données et construire le diagramme correspondant, - identifier les 3 ensembles de transformation: pour les entrées, pour la partie centrale, pour les sorties. M.C.S.E 105

Partie 2 - MODELES ET METHODOLOGIES - construire une décomposition en modules ou fonctions basée sur les 3 ensembles de transformation. - poursuivre le raffinement pour chaque sous-ensemble et optimiser la structure globale.

entrée A donnée X entrée B donnée Y donnée Z

Transfor me A A’ Calcule C C Calcule D D sortie

Programme

A,B A saisie Transforme A A’

B’

B A’,B’

C

D

D

E

E

Transfor me B

B’ D
A

Transforme B

Calcule Calcule C D

Sort D

Calcule E D

Sort E E

B

X

X

Y

Z Z Périph

Calcule E

E sortie
Périph Périph X Y

entrée A donnée X entrée B donnée Y donnée Z

Transfor me A

Programme A’ Calcule C C Calcule D D sortie A’B’ D Calcule E E sortie ACQ. A’B’ C Calcule C Y Z Y Z D E Périph C C D Sortie D D E E Calcule D D

Transfor me B

B’

Acq. A’ B’

Sort Calcule Sort D E E

-Figure 7.8- Influence du partitionnement sur la structure. 7.4.3. Remarques Cette méthodologie aussi appelé SA/SD, n'a de point commun avec SADT que l'approche du type flots de données pour l'analyse. Elle reste limitée à la conception des programmes séquentiels. L'architecture du système découle directement de la première décomposition modulaire. Si celle-ci n'est pas judicieuse, ce qui ne s'observe que durant les stades avancés de la conception, le travail doit être repris au départ. Ceci provient du fait que la méthode conduit à une solution monolithique n'exploitant que des relations hiérarchiques verticales. 7.5. METHODOLOGIE DE JACKSON (JSD) Cette méthodologie fut tout d'abord développée vers 75 pour la conception des programmes: JSP (Jackson Structured Programming), puis fut étendue entre 75 et 80 à la conception des systèmes: JSD (Jackson System Development). Elle couvre aujourd'hui les 3 phases: Spécification, Conception Préliminaire, Conception Détaillée ou Implantation. Elle est appropriée pour la conception des systèmes d'informations et des systèmes temps-réel [JACKSON-83, CAMERON-86]. Cette méthodologie est basée sur la modélisation des données, par opposition à SA qui est basée sur la modélisation des activités par flots de données.

106

M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES L'idée essentielle de cette méthode est que la structure du système à concevoir se déduit de la structure et de l’évolution des données que celui-ci doit gérer. Le système est conçu comme élément de transformation des données d'entrée en données de sortie. Elle est particulièrement efficace lorsque l'ordonnancement des événements dans le temps est significatif. 7.5.1. Les modèles La méthodologie de Jackson utilise plusieurs modèles, chacun adapté au niveau souhaité pour la description: - diagramme de Jackson pour la structure des données et le comportement des entités, lors de la spécification, - réseau de process pour la conception fonctionnelle, - langage JSP pour l'implantation.
-A- DIAGRAMME DE JACKSON POUR LES ENTITES

Le diagramme de JACKSON permet de décrire l'évolution d'un objet ou d'une entité en exprimant le séquencement des actions et des événements pour l'objet. Il s'agit d'une structure d'arbre. Les feuilles sont les actions élémentaires. Les noeuds sont des opérateurs de séquencement. Ce diagramme est donc utilisable pour la modélisation dynamique des données c'est-à-dire l'évolution temporelle. Le diagramme est construit sur la base de 3 symboles auxquels correspondent 3 structures de contrôle: - séquence, - itération, - sélection. Il décrit ainsi l'ordre des événements concernant l'entité, sans exprimer la durée entre chaque. L'exemple présenté sur la figure 7.9 décrit l'évolution de l'état d'un livre. Ce type de diagramme se traduit directement en une description syntaxique du type pseudocode (Jackson Programming Language).
-B- RESEAU DE PROCESS DE JACKSON

Ce modèle est composé d'entités considérées comme "Process". Chaque process possède ses entrées et sorties pour les données, et assure un traitement. Les process séquentiels sont représentés par des rectangles. Les cercles et losanges utilisés pour les relations, décrivent 2 mécanismes de communication: - le flot de données (Data stream) pour le cercle, par l'intermédiaire de messages produits par un process et exploités par un autre. Le cercle représente une file FIFO de taille illimitée. - le vecteur d'état d'un process (losange), qui est une forme de variable globale. Tout process ne peut que lire l'état d'un autre process (un seul écrivain, multiples lecteurs). M.C.S.E 107

Partie 2 - MODELES ET METHODOLOGIES

LIVRE Séquence

* o

itération sélection

Acquisition

Enregistrement

Cycle de prêt

Fin

*
Prêt Vente

o
Echange

o

Début de prêt

en prêt

Fin de prêt

Retrait

Expédition

*
Renouvellement

-Figure 7.9- Exemple de diagramme de JACKSON pour l'évolution d'une entité.

Réseau de Jackson
P1

Multiplicité de P1
F Niveau Réseau P2 Flot de données

Diagramme de Jackson

P1

P1

Synchronisation
L Niveau Process P2 Exploitation de L sur présence de T P2 T

Etat
T

consultation de Etat

-Figure 7.10- Exemple de réseau de JACKSON et notation. 108 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Pour un réseau (voir figure 7.10), un rectangle ne représente que le type du process et non les instances. La communication se fait toutefois entre les instances. Les doubles-barres (situées du côté des producteurs) indiquent la multiplicité de la communication, et donc la multiplicité des process producteurs, c'est-à-dire toutes les instances du type de ce Process. La concaténation des liens d'entrée indique la concaténation des messages avant lecture pour n'en former qu'un seul, ce qui permet d'exprimer une synchronisation. Pour ce modèle, chaque process est décrit par une structure interne basée sur des séquences, sélections, itérations. Ceci peut se représenter par tout modèle comportemental, et tout particulièrement par les diagrammes de JACKSON, ainsi que par une description structurée telle que JSP. 7.5.2. La démarche La méthodologie préconise une décomposition du travail en 3 phases: - modélisation de l'environnement par recherche et description des entités du monde réel, - spécification des fonctions nécessaires pour obtenir les sorties, - évolution des contraintes de temps et définition d'une implantation. La procédure de développement consiste en 6 étapes: - recherche des entités/actions, - structure des entités, - recherche du modèle initial, - définition des fonctions, - introduction des contraintes temporelles, - implantation. On détaille ci-après chacune des étapes de manière à avoir un aperçu de la démarche proposée.
- A- RECHERCHE DES ENTITES ET ACTIONS

Il s'agit tout d'abord de définir le SUJET en décrivant la réalité en termes d'entités, actions et événements. Ceux-ci sont trouvés dans l'environnement du système à concevoir. Une entité a sa propre dynamique à l'extérieur du système. Elle est identifiable et peut se décrire par des événements et actions selon une relation d'ordre. Une action est considérée comme atomique. Un événement est un changement d'état.
- B- STRUCTURE DES ENTITES

Chaque entité est ensuite spécifiée. La modélisation se fait en utilisant le diagramme de JACKSON qui exprime son évolution temporelle, c'est-à-dire l'expression des contraintes temporelles qui peuvent exister entre les actions, sans pour cela spécifier la durée entre les actions. Cette modélisation est essentiellement dynamique (what happens?, in what order?), et concerne chaque instance du type de l'entité.
-C- MODELE INITIAL

Le modèle initial s'obtient en introduisant dans le système, pour chaque entité de l'environnement, un processus de simulation de cette entité, ayant le même comportement que celui décrit par diagramme. M.C.S.E 109

Partie 2 - MODELES ET METHODOLOGIES L'état du processus interne, pour qu'il suive l'état de l'entité réelle, est mis à jour par des connexions du système avec le monde réel de manière à être informé des actions et événements dans l'environnement. La modélisation faite en -B- permet ainsi de déduire les observations nécessaires. La figure ci-dessous décrit le modèle initial pour un livre en faisant apparaitre les points d’attente d’événements en provenance de l’environnement.
Environnement
Commande Nouveau livre

Système
Attente

LIVRE

Acquisition

Enregis.

Cycle de prêt

Fin

Système

Arrivé livre

Attente

Ev livre

Modèle livre

Prêt

*

o Vente

o Echange

Inexistant

Attente

Début de prêt

en prêt

Fin de prêt

Retrait

Expédition

Prêt ou fin livre Prêt ou fin livre Inexistant Renouvellement ou fin prêt

Attente

Attente

Attente

* Renouvellement

Attente

-Figure 7.11- Exemple de modèle initial pour le livre. Les processus sont rémanents pendant toute la durée de vie de l'entité. Ils restent en permanence en attente des événements externes. L'état n'évolue que sur apparition d'un événement. L'état du processus est interne à celui-ci et ne donne aucune information supplémentaire par rapport à l'entité réelle correspondante. Mais cet état permet de définir les données à mémoriser pour chaque entité: les actions définissent ce qui arrive, les données définissent ce qui doit être mémorisé sur ce qui arrive. Les informations ou événements en provenance de l'environnement peuvent ne pas être conformes à la modélisation, par exemple: 2 emprunts à suivre pour le même livre. Cette observation de non-conformité peut servir ensuite à l'élaboration des procédures d'erreurs, ce qui conduit à l'introduction d'un sous-système d'entrée pour la détection et la correction d'erreurs. Pour l'implantation qui suivra, tous les processus identiques sont implantés sous la forme d'une même procédure travaillant avec des données propres à chaque entité. Toutes les données sont alors mémorisées dans une table ou base de données. Les actions correspondent ainsi à la mise à jour de la base de données. 110 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Il est important de constater que cette démarche conduit à modéliser dans le système son environnement par un modèle de données (Data model), et non par un modèle événementiel (event model). Selon JACKSON, la modélisation par les données déduite des événements est beaucoup plus stable que celle faite directement par des événements, qui eux peuvent changer rapidement suite à une évolution des spécifications.
-D- DEFINITION DES FONCTIONS

Le concepteur spécifie ensuite les fonctions du système dans les termes du modèle. Ceci se fait par ajout de processus pour satisfaire les besoins du demandeur, et si nécessaire, par évolution des processus existants. Plusieurs raisons conduisent à devoir ajouter des processus: - l'élaboration de données résultats déduites des données représentatives des entités, - le traitement des erreurs de non-conformité de l'environnement au modèle, - la nécessité d'une interactivité avec les utilisateurs: production de sorties en réaction aux demandes en entrée. Le développement se fait donc d'une manière incrémentale. Les processus sont interconnectés conformément au modèle de réseau de processus, les relations sont du type: transfert de messages et consultation d'état. Le transfert de messages est utilisé pour spécifier à une autre fonction d'effectuer des actions selon une relation d'ordre. Un vecteur d'état est utilisé pour un couplage par des données entre fonctions temporellement indépendantes. La figure 7.12 montre les 4 types de processus: - modélisation d'une entité, - traitement d'erreurs, - processus de sortie, - processus interactif.

Fonctions interactives

entité 1

Modèle entité 1

Monde réel

Traitement des erreurs

Fonctions de sorties

Sorties

entité 2 Modèle entité 2

-Figure 7.12- Exemple de réseau de processus. M.C.S.E 111

Partie 2 - MODELES ET METHODOLOGIES La spécification complète de la solution comprend 2 niveaux de description: - le réseau de processus séquentiels communicants, - le comportement de chaque processus exprimé par un diagramme structuré ou par une description en langage structuré. Les fonctions introduites dans le réseau sont généralement mutuellement indépendantes. Ainsi, elles peuvent être développées séparément. Ceci facilite le travail en équipe et l'ajout de nouvelles fonctions.
-E- EXPRESSION DES CONTRAINTES TEMPORELLES

Jusqu'à ce stade, la conception est faite sans considération de temps. Or, le monde réel génère des événements conformément à des spécifications temporelles. Des retards peuvent apparaître dûs à la solution retenue pour l'implantation. Il faut donc exprimer les retards potentiels et déterminer avec l'utilisateur les délais acceptables: validité des données, retard au traitement d'un événement, conformité du modèle à la réalité... Ces décisions servent de contraintes pour la phase d'implantation.
-F- IMPLANTATION

2 problèmes sont à résoudre: - aboutir à l'exécution de tous les processus sur une structure matérielle possédant moins de processeurs, - assurer la mémorisation des données de l'application. Le premier point concerne le partage du ou des processeurs. Pour cela, il faut décider d'une stratégie d'ordonnancement. Ceci s'effectue par transformation des processus en procédures avec passage du contexte courant comme argument. Cette transformation permet de séparer les données du code exécutable. Une copie des données spécifiques ou contexte doit exister pour chaque processus. De plus, la combinaison des processus permet de simplifier l'implantation. Par exemple, un réseau de processus est transformé en un programme principal et une hiérarchie de sousprogrammes. JACKSON préconise la technique d'inversion pour la réduction de complexité. La figure suivante montre le résultat de cette technique de transformation. Pour l'exemple figure 7.13, R n'est actif que lorsque F et G existent. Dans la technique du tiré, par appel procédural, R sollicite d'abord l’information F à P, puis G à Q. Dans la technique du poussé, les fonctions sont sollicitées toujours par appel de procédures mais dans le sens du flot de données. 7.5.3. Remarques JSD conduit à une solution hiérarchique, sans que cela résulte d'une démarche complètement descendante. La spécification et la conception sont plutôt du type incrémental. La modélisation de l'environnement sert de contexte pour les spécifications fonctionnelles: l'ensemble des fonctions possibles pour le système sont induites par le modèle. Les modèles des entités sont plus stables que les fonctions. Si la vue de la réalité change et donc les spécifications, les fonctions doivent changer, mais pas obligatoirement les modèles (différence 112 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES entre structure et comportement). La démarche préconise de décrire d'abord l'existant. Ensuite, la spécification des fonctions sert à décrire quelque chose de nouveau. Mais, il n'est pas toujours facile de se fixer une modélisation de la réalité sans aussi une certaine idée de l'utilité du modèle.
Technique du tiré Technique du poussé

P

F R H

A

P

F R H S D

Q

G

B

Q

G C

P

Q

A,B,C A

MAIN B C P Q

F R

G H F

G R H S D

-Figure 7.13- Exemples de transformation pour l’implantation. Les phases A à E sont orientées utilisateurs, tandis que la phase F est purement technique. Les phases C et D conduisent à définir une solution en conception sous la forme d'une structure interne, alors que les spécifications ne sont pas encore élaborées. La méthode conduit donc à mixer par itérations, spécification et conception fonctionnelle. La solution résultante ne peut donc pas être optimisée, ce qui reporte ce travail vers l'implantation. Cette méthodologie apparaît complète et appropriée pour la conception des systèmes d'information. MCSE dans l'esprit est assez proche de cette démarche mais s’applique plus particulièrement aux systèmes temps-réel. 7.6. SREM SREM (Software Requirements Engineering Methodology) a été développée par TRW depuis 1975 [ALFORD-82,-85]. Cette méthodologie est principalement orientée: élaboration, vérification, validation des spécifications, et concerne les applications temps-réel et réparties pour le traitement des données. Elle permet d'effectuer une élaboration progressive des spécifications en transformant le cahier des charges en une description de plus en plus formelle. Les performances attendues du système peuvent aussi être inclues dans la spécification. Cette méthodologie a ensuite été étendue par SYSREM pour la conception et l'allocation des ressources, puis DCDS pour les systèmes distribués. 7.6.1. Le modèle SREM est basée sur l'emploi d'un automate à états-finis structuré: appelé R-NET (Requirement-Net). Il exprime l'évolution des sorties et de l’état à partir des entrées et de l'état courant. M.C.S.E 113

Partie 2 - MODELES ET METHODOLOGIES Ce modèle est issu du diagramme à états finis avec des extensions lui donnant un caractère de structuration de haut-niveau. Il permet de spécifier des traitements sur un ensemble d'entrées pour produire un ensemble de sorties. Ce réseau est du type stimuli/réponses. Les entrées sont structurées en ensembles de messages, chacun étant fourni par une interface connectée à l'environnement. Les sorties sont structurées de la même manière. L'état S du réseau est le produit cartésien des informations connues du système. Chaque diagramme R-Net décrit la transformation d'un message d'entrée et de l'état courant, en un nombre de messages de sortie et un nouvel état. On donne sur la figure 7.14 un exemple de graphe. Le modèle utilise les symboles suivants: - le symbole de Départ (START), - l'interface d'entrée, qui accepte un message de l'extérieur, - l'interface de sortie, qui transmet un message à l'extérieur, - les fonctions (ALPHA) qui spécifient des transformations, - un sous-réseau (sub-net) définissant un graphe de traitement possédant un point d'entrée et un point de sortie, - un noeud OU pour introduire des conditions d'état, - un noeud REJOIN-OU pour exprimer une convergence OU, - un noeud ET pour introduire des traitements parallèles. - un noeud REJOIN-ET pour exprimer une convergence ET, - le noeud SELECT pour la sélection d'un message d'entrée compte-tenu de l'état courant, - le noeud FOR-EACH spécifie que tous les éléments d'une liste doivent être traités. Ce modèle est hiérarchique car il permet le raffinement progressif des noeuds du type sousréseau, à l'aide de diagrammes R-NET. Il est approprié pour exprimer les relations: stimulis ==>Réponses, et il permet aussi d'expliciter les performances à satisfaire et les contraintes de temps. Les contraintes s'expriment par des temps minimum et maximum attachés à des chemins à travers le graphe RNET. Les points caractéristiques du réseau pour ces vérifications de performances sont appelés points de Validation. Les diagrammes sont ensuite traduits en RSM (Requirements Statement Langage) basé sur les éléments, attributs, relations et structures. 7.6.2. La méthode SREM pour la spécification La méthodologie SREM pour l'élaboration des spécifications stipule de travailler selon les phases suivantes: - Identification de l'interface entre le système et l'environnement et description des données et traitements. - Etablir une première description en utilisant des R-Nets. - Spécifier les données et le comportement des fonctions ALPHA en RSL. - Ajouter les informations de management: échéances, points d'analyse, outils. - Valider la spécification par une simulation fonctionnelle en utilisant les points de validation. - Identifier les spécifications de performances et contraintes de temps. - Faire une étude de faisabilité pour garantir le système. 114 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

R_NET START

II V1

INPUT INTERFACE

VALIDATION POINT
R_NET SAMPLE. STRUCTURE: INPUT INTERFACE II VALIDATION POINT V1 ALPHA A ALPHA A SELECT ENTITY CLASS IMAGE SUCH IMAGE THAT (Y-Z) DO S ENTITY SELECTION ALPHA D CONSIDER DATA STATUS IF (READY) "AND" ALPHA E & OR (NOT READY) ALPHA F END END D IF (X > 5.0) CONSIDER "OR" ALPHA G HISTORY VALIDATION_POINT V2 STATUS OUTPUT INTERFACE 01 OR (X = 5.0) DO (READY) (NOT READY) ALPHA H OUPUT INTERFACE 02 AND E F ALPHA J TERMINATE OTHERWISE EVENT Q TERMINATE "OR" REJOIN END END

B

FOR EACH

F

SUBNET

C

&

"AND" REJOIN

"OR" (X > 5.0) (X = 5.0) G V2 H J & OTHERWISE Q E EVENT

TERMINATE 01 02

OUTPUT INTERFACE

-Figure 7.14- Exemple de graphe R-NET. 7.6.3. La méthode SYSREM pour la conception Se pose ensuite le problème de la transition des spécifications en une solution de conception. C'est l'objectif de SYSREM. M.C.S.E 115

Partie 2 - MODELES ET METHODOLOGIES Une présentation globale de la méthode est indiquée par la figure 7.15. Des sous-ensembles de R-Nets sont traduits sous la forme de tâches. Les fonctions ALPHA induisent une décomposition modulaire qui sont des procédures pour les tâches. Les tâches sont allouées sur une architecture matérielle. Le développement d'une solution se fait selon les phases suivantes: - Définition du système, ceci conformément à SREM, - Identification des composants et sous-systèmes pouvant intervenir dans le système, - Décomposition du système qui se fait sur la base de principes énoncés dans la suite. On exprime ainsi le séquencement et le parallélisme des fonctions, - Allocation par association des fonctions sur les sous-systèmes ou composants. Plusieurs solutions sont possibles. - Estimation du coût et de la faisabilité. Chaque sous-système est à évaluer, comptetenu de l'allocation. Toutes les interfaces sont définies pour assurer le couplage fonctionnel entre les sous-systèmes, - Evaluation des parties critiques et des ressources, - Introduction de la tolérance aux fautes par addition de fonctions, - Plan d'intégration et de test, - Optimisation de la conception.

SPECIFICATION

&

TACHE 2

TACHE 1 Conception fonctionnelle

Conception Modulaire N1 M2 M1 N3

Utilitaires

N2 Architecture matérielle

-Figure 7.15- Une vue globale de la Méthode SYSREM. 7.6.4. Remarques La méthode SREM est intéressante pour la spécification compte-tenu du modèle stimuliréponse qui permet de faire une approche efficace à partir de l'environnement et d'exprimer des contraintes de performances. Des vérifications de cohérence sont aussi possibles. 116 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Comme limitation, n'étant pas basées sur un modèle hiérarchique, les spécifications doivent être explicitées à un niveau de détail important. Le passage de la spécification à une conception préliminaire n'apparaît pas évident. Non utilisable pour spécifier la conception d'une solution répartie, la méthode SYSREM a été étendue par DCDS (Distributed Computing Design System). 7.7. METHODOLOGIE DE WARD ET MELLOR (SDRTS OU RTSA) Cette méthodologie (Structured Development for Real-Time Systems) aussi appelée RTSA (Real-time Structured Analysis), a été développée pour la spécification et la conception des applications temps-réel [WARD-85]. Elle apporte les compléments nécessaires à SA/SD de manière à corriger pour les systèmes temps-réel, les limitations des diagrammes flots de données et celles de la conception structurée. 7.7.1. Le modèle La méthodologie est basée sur l'emploi de 2 modèles: - le modèle essentiel lui-même composé de 2 parties: • le modèle d’environnement qui décrit l’environnement dans lequel le système va opérer, • le modèle de comportement du système à concevoir. - le modèle d'implémentation décrivant la solution selon 3 niveaux hiérarchiques: les processeurs, les tâches, les modules. Les 2 modèles ci-dessus, appelés schémas de transformation, sont basés sur le diagramme flot de données de DEMARCO (DFD) auquel est ajouté un diagramme complémentaire exprimant le contrôle de l'évolution du DFD. Cette partie est appelée diagramme flot de contrôle (CFD représenté en pointillé). Une activité de ce diagramme agissant sur les activités du DFD est spécifiée par un modèle à états finis (automate, table de décision...). Le modèle utilise aussi les diagrammes entités-relations pour la spécification des données et des constituants de l'application. L’exemple de la figure 7.16 illustre ce modèle de spécification. Les actions de contrôle d'évolution des activités sont de 3 types: ENABLE (autorise) pour l'activation, DISABLE (inhibe) pour l'arrêt de l'activité, TRIGGER pour une activation ponctuelle. Les lignes de données sont de 2 types: événementiel, ou continu (double flèche). Comme pour le diagramme flot de données, ce modèle permet une approche progressive de la spécification par raffinement des activités comme le montre la figure 7.17. Le modèle d'implémentation est structuré en 3 niveaux: - le niveau processeurs, qui décrit toujours par un diagramme du type flot de données, les processeurs de l'application, les relations et interfaces entre eux. Chaque processeur sera responsable d'une partie du modèle essentiel. - le niveau tâches, qui exprime pour chaque processeur, les tâches et relations entre elles. Ce niveau modélise l'architecture du logiciel. - le niveau modules, explicitant la décomposition de chaque tâche. Le modèle préconisé est le diagramme structuré (Structure Chart). M.C.S.E 117

Partie 2 - MODELES ET METHODOLOGIES

DEBUT PH A ATTEINT X

OBSERVE pH CONTROLE pH
INHIBE

STOP

ATTENTE PH AUTORISE DEBUT AUTORISE "AUGMENTE pH" AUTORISE INHIBE CONTROLE VALVE D’ENTREE pH A ATTEINT X INHIBE "AUGMENTE pH" AUTORISE "MAINTIEN pH" MAINTIEN AUGMENTATION

AUGMENTE pH

STOP INHIBE "AUGMENTE pH"

MAINTIEN pH

COMPORTEMENT DE CONTROLE pH
CONTROLE VALVE D’ENTREE

STOP INHIBE "MAINTIEN pH"

-Figure 7.16- Le modèle de spécification de WARD et MELLOR. 7.7.2. La démarche Le développement d'une application consiste à trouver les 2 modèles. Tout d'abord, la phase de recherche du modèle essentiel consiste en [WARD-85, vol.2]: - une modélisation de l'environnement ce qui nécessite: • de décrire le diagramme du contexte (délimitation du système), • de trouver l'ensemble des événements pour lesquels le système devra répondre. - la modélisation du système qui exprime son comportement en réponse aux événements de l'environnement. Pour cela, il faut exprimer par raffinements successifs, le schéma de transformation (DFD+CFD), puis le schéma des données, ainsi que les spécifications des activités et des données. Ensuite, la phase de recherche du modèle d'implémentation consiste à assurer la correspondance entre des portions du modèle essentiel et chaque élément technologique. Elle nécessite les étapes suivantes [WARD-85, vol.3]: - Identification des processeurs indispensables comme support pour le modèle essentiel. Ceci s'obtient à partir d'une réorganisation du modèle de spécification. - Réorganisation du schéma de transformation pour chaque processeur, de manière à faire apparaître les tâches, les interfaces, la gestion des données et l'ordonnancement de celles-ci. - définition du schéma d'implémentation de chaque tâche sous la forme d'une hiérarchie de modules (utilisation de la méthode YOURDON et CONSTANTINE). 118 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

Maintien vitesse
contrôle valve position valve vitesse de rotation Vitesse Moteur marche / arrêt

frein

1 Observation 2
moteur Autorise / inhibe Maintien etat actif

reprise

Start/stop augmentation vitesse

Start / End kilomètre mesuré contrôle vitesse de croisière

Vitesse

Vitesse de rotation

Autorise/inhibe

2.4 Vitesse actuelle
reprise frein position valve

Autorise / inhibe

2.1 Mode opératoire

Contrôle vitesses de croisière

Autorise / inhibe Facteur de conversion vitesse

Autorise / inhibe vitesse de rotation

2.2 Gestion du mode contrôle

Start/stop augmentation vitesse

contrôle valve vitesse de rotation

2.3 Gestion du mode mesure

Start/End kilometre mesuré

2.2.1

2.2.2

2.2.3

-Figure 7.17- Exemple de raffinement pour le modèle essentiel. La figure 7.18 illustre ces 3 niveaux de description et montre que chaque sous-ensemble d'un niveau est le raffinement d'une entité du niveau supérieur. La figure 7.19 montre un tel résultat. Selon les auteurs, sur la base des 2 modèles, plusieurs démarches de développement sont possibles. Comme extrêmes, citons: - modèle essentiel complet, puis modèle d'implémentation, - itération par niveaux entre les 2 modèles (modèle spirale). La figure 7.20 indique la démarche par itération. M.C.S.E 119

Partie 2 - MODELES ET METHODOLOGIES

NIVEAU PROCESSEURS
Groupe processeur 1 Groupe processeur 2

processeur 2.1

processeur 2.2 Processor 1.1

NIVEAU TACHES

Processeur 1.1

Groupe tâche 1.1.1

Groupe tâche 1.1.2

Tâche 1.1.1.1

NIVEAU MODULES
Tâche 1.1.1.1

-Figure 7.18- Les 3 niveaux du modèle d'implémentation.

AVANT

APRES

G1

G2

T3

P1

P2

T1.1

T1.2

T2.1

S3
T2.2

G1

T2.1

T3a T2.2

T3b

S1.1

S1.2
T1.1

S2.1 S2.1 S2.2
T1.2

S3a

S2.2

S3b

S1.1

S1.2

G : Groupe de transformation esssentielle T : Transformation essentielle simple S : Spécification de transformation P : Processeur

-Figure 7.19- Résultat à l'issue d'une réorganisation. En conclusion, si l'approche diagramme flot de données s'avère efficace, cette méthode apparaît complète et adaptée aux applications multi-tâches temps-réel. Toutefois, elle ne concerne que la partie logicielle, puisque la partie matérielle reste a priori supposée définie car dans la méthodologie rien n'indique comment la déduire. 120 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES
.

Modèle essentiel

Implémentation

Niveau 1
Spirale du développement

Niveau 2

Niveau 3

Produit final

-Figure 7.20- Les 2 modèles et la démarche spirale. 7.8. METHODOLOGIE de HATLEY et PIRBHAI Cette méthodologie est très proche de celle de WARD et MELLOR dans l'esprit et par les modèles préconisés. Elle est donc aussi adaptée à la spécification des systèmes temps-réel [HATLEY-87]. 7.8.1. Le modèle La définition d'un système est composée de 2 parties: - la spécification du système, - l'architecture du système. Le modèle de spécification est le diagramme flots de données (DFD ou process model) auquel a été ajoutée une spécification du contrôle (CFD ou Control model). La figure 7.21 donne un exemple. Ce modèle est très similaire à celui de WARD, mais avec une notation différente pour les activités de contrôle et une signification différente pour spécifier les états actifs et inactifs des activités de transformation. Il apparaît plus structurant pour la partie contrôle. Le modèle d'architecture spécifie le partitionnement du système en ses sous-ensembles physiques. Le diagramme des modules (AFD) définit les modules et les relations fonctionnelles entre eux. Le diagramme d'interconnexion (AID) définit les moyens pour l'échange entre les modules. Ce modèle est présenté sur la figure 7.22. Le passage de la spécification - qui se veut indépendante de la technologie - à l'architecture nécessite d'ajouter les parties interfaces: entrée, sortie, utilisation qui elles sont liées à la technologie. Le modèle de structuration ou de décomposition préconisé est représenté sur la figure 7.23. Autour du "noyau dur" que constitue la spécification du système indépendante de la technologie, sont ajoutés 4 sous-ensembles à rechercher: la gestion des entrées, la gestion des sorties, l'interface utilisateur, les fonctions de maintenance sûreté et test. M.C.S.E 121

Partie 2 - MODELES ET METHODOLOGIES

comptage distance

comptage kilomètre

paramètres de référence

Boîte de vitesse

Mesure vitesse

Mesure km

vitesse enclenchée

Roue
Accélération, vitesse. rotation distance

Freins
Freinage

commande Valve
position valve

panneau de contrôle

valve

Affichage Quantité de carburant

Conducteur

début acc. fin acc. reprise en marche

commandes

Moteur
(activité de contrôle)

-Figure 7.21- Exemple de Spécification (DFD+CFD)

A B K LE SYSTEME H G F J

C

D

E DIAGRAMME FONCTIONNEL C B H N MA3 M MA1

K

MA4

A BUS INTERNE R P MA2 E D

MA4

MA3

MA1

MA2

L G H F DIAGRAMME DES MODULES MA5 J

MA5

BUS DE MAINTENANCE

DIAGRAMME DES INTERCONNEXIONS

SPECIFICATIONS DES MODULES DICTIONNAIRE DE L’ARCHITECTURE

SPECIFICATIONS DES INTERCONNEXIONS

-Figure 7.22- Le modèle d'architecture d'un système. 122 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

MODELE DE SPECIFICATION DE SYSTEME
ARCHITECTURE

INTERFACE UTILISATEUR BESOINS

ACTIVITES ENTREES CONTROLE

ACTIVITES SORTIES CONTROLE

MAINTENANCE, AUTO-TEST, REDONDANCE, GESTION DE FONCTIONS.

-Figure 7.23- Structure du modèle pour la méthodologie de HATLEY.
OBJECTIFS DU SYSTEME

Besoin du système

Modèle architectural du système

Spécif. du système

Spécif. du système Extensions de l’architecture

Modèle architectural du système

Technologiquement indépendant

Non-spécifique technologiquement

Technologiquement dépendant

-Figure 7.24- Procédure de spécification d'un système. 7.8.2. La démarche Elle consiste à trouver les 2 parties de la définition du système. La méthode consiste à rechercher tout d'abord les spécifications indépendamment de la technologie. Le modèle est ensuite enrichi par les interfaces: entrées, sorties, utilisateur, et les aspects maintenance et sûreté. Pour finir, il s'agit de déduire l'architecture du système avec les 2 parties, le matériel et le logiciel. Cette démarche est illustrée par la figure 7.24. M.C.S.E 123

Partie 2 - MODELES ET METHODOLOGIES Le développement peut se faire en séparant les 2 parties, mais aussi et surtout selon un processus itératif (modèle spirale) entre les spécifications et l'architecture pour les 3 parties: système, matériel, logiciel (idem à WARD). 7.9. METHODOLOGIE DE LAVI ET HAREL (STATEMATE COMME OUTIL) Cette méthodologie est basée sur l'association de 3 vues pour la modélisation d'un système: activités, contrôle, implantation. Le modèle de contrôle est le STATECHART de HAREL. Un outil appelé STATEMATE a été développé comme support [HAREL-88, LAVI-88]. 7.9.1. Le modèle ECS (Embedded Computer Systems) Ce modèle permet de décrire un système mono ou multi-calculateurs et les sous-ensembles et modules logiciels associés selon une décomposition multi-niveaux. Il est basé sur le principe de la décomposition d'un système en sous-systèmes assurant chacun une fonctionnalité, et un contrôleur chargé de la coordination des sous-ensembles. La figure ci-dessous illustre ce modèle.

LE SYSTEME ET SON LOGICIEL

Données de contrôle externe Contrôleur système Donnée de contrôle

Environnement du système

Environnement du système

soussystème 1

soussystème 2

soussystème 3

soussystème 4

Données process Données de contrôle Information de retour Données de contrôle externes

-Figure 7.25- Le modèle ECS. Ce modèle conceptuel représente les liens données et contrôle entre l'environnement et le système, et en interne entre les sous-systèmes. Chaque sous-système assure une fonction spécifique défini par son comportement. Il peut aussi se décomposer selon le modèle ECS. Le comportement est défini par un diagramme type flot de données. 124 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Le contrôleur définit le comportement de l'ensemble des sous-systèmes sous sa dépendance: modes, transitions, activations. Son activité est habituellement décrite par un automate à états finis, ou plus spécifiquement par une extension appelée STATECHART. Le STATECHART [HAREL-87] a été développé comme extension du diagramme à états finis de manière à réduire ses limitations. Essentiellement, il permet de représenter une description hiérarchique et structurée, des actions ou activités simultanées, des conditions de transition complexes. Pour se limiter aux caractéristiques principales de ce modèle, il permet: - le raffinement en détaillant un état par un ou plusieurs automates. Dans le cas de plusieurs automates, il y a évolution parallèle (équivalence avec la convergence ET et la divergence ET du Grafcet), - la spécification explicite ou par défaut d'un état de départ pour un ensemble d'automates, et de synchronisations multiples, - l'association de contraintes de temps à des états, tels que des chiens de garde (time-out). La figure suivante montre sur un exemple l'intérêt et la simplicité de ce modèle.
Montre quartz multi-alarme
Bloc principal Alarme 1
arrêt alarme on alarme off Arrêt marche carillon off carillon on arrêt b ^ b marche pile ôtée pile en place Arrêt total

Carillon

Lumière

Alarmes Affichage Bip

Alarme 2

Rien 1 heure Bip 2 sec.

Alimentation

arrêt alarme on

ok pile faible

pile morte

off

clign.

marche

-Figure 7.26- Spécification pour le fonctionnement d'une montre. Ainsi le modèle complet permet la description du système en cours de développement selon 3 vues comme l'indique la figure suivante: - la spécification de l'architecture (module-charts) qui décrit les modules logiques et physiques, ainsi que l'environnement. - la spécification des activités (activity-charts) comprenant une partie flot de données et une partie contrôle (description proche de celle de WARD). - la spécification du contrôle (statecharts). M.C.S.E 125

Partie 2 - MODELES ET METHODOLOGIES

Activity chart

State chart

FONCTIONNALITE
Décomposition fonctionnelle et Flot de données

COMPORTEMENT
Contrôle et Relations temporelles

Description du système

STRUCTURE
Décomposition physique et Flot de données

-Figure 7.27- Les 3 vuesM d l la h t pour description d'un système. 7.9.2. La démarche La méthodologie préconise une analyse itérative de manière à exprimer progressivement toutes les exigences du système à concevoir. Pour chaque niveau de décomposition, il s'agit d'élaborer toutes les vues du système. La procédure consiste à suivre les étapes suivantes: - expression du besoin, faite en collaboration avec le client, - définition du système et de son environnement: délimitation des entrées et sorties et spécification du système par une analyse flot de données. - définition des modes de fonctionnement du système: utilisation de statecharts pour cette spécification. - première décomposition modulaire: utilisation du modèle ECS pour identifier les soussytèmes, selon des critères de modularité favorisant la réutilisation et la sous-traitance, - analyse des performances et revue des documents, - conception de l'architecture du système. Il s'agit de définir la structure matérielle: système multi-calculateurs, système de communication..., - identification des activités et flots de données: spécification des activités de chaque sous-système, des modules et le liens entre eux. - analyse dynamique et conception du contrôleur. L'analyse détaillée du comportement global du système selon les modes opératoires (statecharts) et du rôle des modules permet de déduire la solution pour le contrôleur. - vérification de cohérence, prototypage et simulation. 126 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES 7.9.3. Remarques Cette méthodologie développée pour les besoins de Israël Aircraft Industries et l'outil STATEMATE sont appropriés pour la spécification et la conception des systèmes temps-réel dédiés. Le statechart est un outil efficace pour l'expression d'un comportement. Le modèle ECS est similaire dans l'esprit à une décomposition en 2 parties: partie opérative (sous-systèmes ou modules), partie commande (contrôleur). L'outil semble être complet. Architecturé autour d'une base de données, il permet la simulation interactive, la génération de rapports et documents, le test, la production de code. Les saisies se font à l'aide d'éditeurs graphiques. 7.10. DARTS (DESIGN APPROACH FOR REAL-TIME SYSTEMS) Cette méthodologie concerne le développement de logiciels pour les applications tempsréel. Une version récente étendue DARTS/DA concerne des applications distribuées sur un ensemble de noeuds liés par un réseau local [GOMAA-84,-89]. DARTS utilise comme modèles: le diagramme flot de données pour la spécification, un modèle de description de la structure interne de la solution appelé "Process Structure Chart" déduit du diagramme ACP (Activity Channel-Pool) de la méthodologie MASCOT (Modular Approach to Software Construction Operation and Test). DARTS inclut un ensemble de règles expliquant comment créer le diagramme de tâches à partir d'un diagramme flot de données. 7.10.1. Le modèle pour DARTS Le modèle graphique pour la conception décrit la structure du système comme un ensemble d'objets du type données et du type tâches chacune associée à des activités opérant sur les données. Les relations intertâches ainsi décrites représentent des mécanismes de communication et de synchronisation. Une simple synchronisation entre tâches est représentée par un événement, tandis que des communications intertâches sont possibles par: - une variable partagée (pool), - un canal permettant le transfert d'un seul ou de plusieurs messages, et selon un couplage faible (tâches asynchrones) ou selon un couplage serré (envoi avec acquittement: cas de tâches synchrones). La figure 7.28 présente l'exemple d'un tel diagramme. 7.10.2. La démarche La méthodologie préconise de suivre les étapes suivantes: - Etablir la spécification par des diagrammes flot de données. Utilisation de la méthode RTSA. - Déterminer les tâches à évolution parallèle à partir des DFD sur la base d’un ensemble de règles: dépendance des entrées/sorties, exécution périodique, cohérence fonctionnelle..., M.C.S.E 127

Partie 2 - MODELES ET METHODOLOGIES - Définir les interfaces ou les tâches en déterminant les relations de couplage à partir des DFD: communication, partage de données ou synchronisation. Ceci conduit au diagramme PSC (Process Structure Chart). - Conception pour chaque tâche.

Programme

No programme commandes entrées ordre
Gestion pupitre Analyse des commandes Interpréteur Gestion des capteurs

capteurs

fin stop, suite sorties affichage affichage
Gestion affichage Gestion du robot

ordre robot acquittement mouvement

Etats capteurs

Gestion des actionneurs

actionneurs

cmd robot

acquittement

Légende :
1 place

Contrôleur robot

queue message avec réponse

E/S Robot

événement variable commune

-Figure 7.28- Exemple de diagramme. La technique Structured Design est utilisée pour décrire la structure interne des tâches orientées traitements ou transactions. Pour des tâches de contrôle, une approche par automates à états finis ou statechart est préférable. L'extension DARTS/DA introduit 2 étapes après celle d'élaboration de la spécification. Il s'agit tout d'abord d'établir une décomposition du système en sous-systèmes. Chaque sous-système sera implanté sur un noeud du réseau. La structuration est basée sur les critères de cohérence fonctionnelle, de faible couplage, de performances. Ensuite, il s'agit de définir les interfaces entre les sous-systèmes. Implantés sur des noeuds différents, les couplages sont assurés uniquement par des communications par messages. Cette méthodologie est typiquement orientée vers la conception architecturale et détaillée des systèmes temps-réel. 7.11. CONCEPTION ORIENTEE OBJET (O.O.D) Cette catégorie de méthodologies est orientée conception à partir des données [ABBOTT85, BOOCH-83,86, COX-86]. La conception orientée objet est basée sur le concept de l'encapsulation défini initialement par PARNAS puis GUTTAG. Cette approche considère toutes les ressources, données et modules comme des objets. 128 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Chaque objet encapsule ses données et les procédures de manipulation de celles-ci. Des langages sont basés sur ce concept: SMALLTALK, C++, objective C, SIMULA, ADA, EIFFEL ... Sur ce concept, le développeur peut créer ses propres abstractions nécessaires pour le problème. Le développement orienté objet est typiquement ascendant. Un commerce de composants logiciels serait ainsi possible, favorisant alors la réutilisation comme l'indique COX. 7.11.1. Le modèle objet Un objet est une abstraction d'un élément du problème traité. Il s'agit d'une entité à caractère dynamique possédant un état interne. Une frontière appelée interface, sépare son "intérieur" de son "extérieur", seule partie visible pour son utilisation [BOOCH-83-86]. Côté utilisation, l'objet est décrit par une spécification, c'est-à-dire les services ou actions qu'il peut assurer pour son environnement. Les demandes sont faites par des entrées (généralement des procédures). En interne, l'objet possède sa propre structure. Il répond aux sollicitations externes et fait évoluer son état interne. Un objet correspond donc à une entité logique à forte cohésion fonctionnelle. Le couplage entre objets est faible et chacun est protégé par encapsulation. Ainsi, pour cette technique, l'OBJET est l'unité de décomposition logique, et non plus l'action ou la procédure comme en programmation structurée. Selon les auteurs, le terme Objet est présenté sous une terminologie différente: - module ou package pour le langage ADA, selon BOOCH, - interpréteur pour ABBOTT, - composant logiciel pour FREEMAN, COX. et avec des caractéristiques différentes: - type abstrait de données (encapsulation de données), - évolution autonome (objet du type tâche), - héritage (objet SMALLTALK). Un objet hérite des caractéristiques des objets pères. Dans la suite, les objets considérés n'incluent pas la propriété d'héritage. Le langage ADA est l'exemple type d'outil de description favorable pour une réalisation orientée OBJET des applications temps-réel. Toute unité ADA se compose d'une spécification et d'un corps. La seule compilation de la spécification est suffisante avant utilisation. Plusieurs types d'objets existent selon son rôle [BOOCH-83]: - l'objet PROCEDURE comme encapsulation d'une suite d'actions séquentielles, - l'objet PACKAGE comme encapsulation de ressources: données, programmes, - l'objet TACHE comme entité autonome, - l'objet GENERIQUE comme modèle de composant logiciel. M.C.S.E 129

Partie 2 - MODELES ET METHODOLOGIES Selon BOOCH, ces types d'objets sont représentés graphiquement comme ci-dessous:
Procédure Package Tâche Procédure générique Package générique

Spécification

Body

Body avec sous-unité

-Figure 7.29- Symboles pour la représentation des types d'objet selon BOOCH. La figure 7.30 donne un exemple de représentation d'une solution à l'aide de ces objets. Chaque objet est défini pour son environnement par ses points d'entrée et sa partie visible. 7.11.2. Démarche pour la conception La démarche proposée par BOOCH peut se résumer par les étapes suivantes: - définition du problème, - développement de la solution sur le plan conceptuel, - formalisation de la stratégie. L'étape de formalisation de la stratégie comprend les phases suivantes [BOOCH 86]: - Identification des objets: il s'agit de faire apparaître les objets du problème qu'il faudra réaliser, ainsi que leurs propriétés caractéristiques. Cette phase est bien entendu particulièrement délicate et dépend fortement du travail d'analyse fait en amont par d'autres méthodes. - Identification des opérations: l'objectif est d'identifier les actions que l'objet subit et provoque. Les verbes de la spécification fournissent des indications sur les opérations. - Etablir la visibilité: il s'agit d'établir à partir des caractéristiques et des opérations, les relations avec les autres objets. Ceci revient à intégrer chaque objet dans la structure de la solution. - Etablir l'interface: ceci revient à définir les spécifications de l'objet en caractérisant son interface avec l'environnement. 130 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES - Implémenter les objets: cette phase finale conduit à l'écriture du comportement interne de l'objet.
Horloge

Anémomètre

Capteurs de température de l’air

Capteurs de température de l’eau

Capteur de position

Interrupteur d’arrêt d’urgence Répartiteur des messages

Base de données des capteurs

Transmetteur radio

Récepteur radio

Rapports Voyant lumineux

-Figure 7.30- Exemple de représentation des objets et liens entre eux. Autre auteur, ABBOTT préconise aussi la conception orientée Objet comme technique de réalisation des constituants de l'application. Il base sa méthodologie sur l'emploi de 4 catégories de composants logiciels: - les objets données: data types, data structures, storage units. Ces objets sont purement passifs, - les objets opérations: ce sont les fonctions de base, - les objets transducteurs: ces composants transforment des données d'entrée en données de sortie, - les objets Drivers: ces composants contrôlent les autres composants. Pour définir l'architecture de l'application sur la base de tels composants interconnectés, l'auteur adopte en amont une conception orientée flot de données comme guide. Il suggère d'organiser le système tel que le flot de données détermine les composants ou objets et leur ordre d'intervention. Ainsi, l'identification des objets se déduit dans ce cas d'une analyse flot de données (méthode SA). L'implémentation de chaque objet doit être conforme à sa spécification. Cette conformité est d'autant plus simple à obtenir que l'implémentation découle d'une traduction la plus systématique. La nature de la spécification a donc une grande importance. Pour cela, ABBOTT préconise une spécification de chaque objet par un diagramme à états finis qu'il appelle ROADMAP. De cette spécification particulièrement adaptée au concept d'interpréteurs correspond assez directement une structure de programme comme l'indique l'exemple suivant. M.C.S.E 131

Partie 2 - MODELES ET METHODOLOGIES

SPECIFICATION
Local conceptual Model Internal_Number : Number Current_opeartion : Operation Start null : Clear Display

IMPLEMENTATION

Number : Store and Display Number

Arith Operation : Save Op

Number : Perform Op. Display Result Clear : Clear Display Equal : null

component type Calculator is Display.Clear ; - Clears the display Set(0); - Sets the internal number to 0 loop communication_editor. communication_Request(Number,Value,Input); Set(Input); - Set the internal number to input loop communication_Editor. communication_Request(Operation or operation(Number),nil,Op); case Operation | Operation(Number) when Equal ⇒ Exit; when Clear ⇒ Set(0); display.clear; exit; when Plus(N) ⇒ Add(N); when Minus(N) ⇒ Sub(N); when Times(N) ⇒ Mul(N); when Divides(N) ⇒ Div(N); end case; display.Set _Value(Value); end_loop; end_loop; end Calculator;

-Figure 7.31- Exemple d'objet par la méthode d'ABBOTT. Cet exemple montre les 2 aspects externe et interne d’un objet: - le comportement à respecter pour l'utilisateur, sous la forme d'un diagramme syntaxique qui spécifie ainsi le langage accepté. Les autres séquences sont invalides. - le comportement interne suivi par l'objet sous l'influence des sollicitations externes pour imposer le comportement souhaité à l'utilisateur. Assez récente, la démarche objet conduit à des avantages certains pour la réalisation: - protection des objets par des interfaces bien spécifiées, - réutilisation des objets, ce qui permet de réduire les coûts de développement (composants logiciels). - indépendance des objets: une évolution interne n'induit pas de changements externes. Le concept OBJET est ainsi très intéressant, mais un travail important sur le plan méthodologique reste à faire pour disposer d'une efficacité similaire à celle qu'apporte la programmation structurée pour l'écriture de programmes. La difficulté avec cette méthode est la phase d'identification des objets. Quelle analyse fautil faire pour déduire les objets? Une analyse basée sur la modélisation des entités réelles du problème conduit-elle à une solution rationnelle? La réponse n'est sûrement pas simple. Si on se réfère toujours à G. BOOCH dans [BOOCH-86], la méthode décrite ci-dessus ne concerne que les phases de conception et de réalisation du logiciel et donc ne couvre qu'une partie du cycle de vie. L'auteur stipule qu'à ce type de méthode, il faut associer en amont, pour créer une modélisation du problème, des méthodes d'analyse et de spécification tels que: JSD de JACKSON et les techniques orientées flots de données de DEMARCO ou GANESARSON. 132 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Plusieurs autres méthodologies orientées Objet ont été formalisées. Entre autres: - GOOD (General Object-Oriented Software Development) élaborée par SEIDEWITZ et STARK et pour les phases de spécification et de conception pour un développement logiciel orienté ADA. Le diagramme flot de données conduit à une identification des entités [SEIDEWITZ-84]. - HOOD (Hierarchical Object-Oriented Design) dérivée d'une approche par machines abstraites et retenue par l'Agence Spatiale Européenne [HEITZ-87]. L’intégration des concepts d’objets, de structuration par hiérarchie et d’expression du contrôle, facilite le développement d’applications de grande taille. - MOOD (Multiple-View Object-Oriented Design Methodology) utilisant la méthode d'analyse RTSA de Ward et Mellor pour l'identification des objets et des tâches [KERTH-88]. - OOSD (Object-Oriented Structured Design) définie pour la conception architecturale des systèmes. Le modèle graphique pour la représentation de l'architecture permet une transition entre la méthode Structured Design et la conception orientée Objet [WASSERMAN-89]. - PAMELA (Process Abstraction Method for Embedded Large Applications) développée par G. CHERRY et orientée vers les systèmes temps-réel dédiés. Cette méthodologie est orientée processeurs séquentiels communicants, avec une transcription directe selon une structure de tâches ADA [KELLY-87]. Pour répondre à la difficulté d’identifier les objets durant la conception, des réflexions sont entreprises pour induire les objets à partir de la phase de spécification. Ceci conduit au développement de méthodes de spécification orientées objet [BAILIN-89, KURTZ-89, WARD-89]. 7.12. SYSTEM DESIGN WITH MACHINE CHARTS Cette méthodologie (SDWMC) est préconisée par R.S.A. BUHR comme une évolution de SDWA (system design with ADA) qui était spécifique pour une implantation ADA [BUHR84,-89]. Adaptée pour les applications "behaviour-intensive", elle est basée, d'une part sur l'idée centrale que l'architecture d'un système est l'association d'une structure et d'un comportement, d'autre part sur le fait que les diagrammes sont la bonne manière de représenter les 2 aspects de manière à permettre l'utilisation des outils CASE ou des outils de CAO. La structure est représentée par des Machine Charts, et la méthode préconisée est appelée JRBS (Joint Refinement of Behaviour and Structure). 7.12.1. Le modèle Le modèle préconisé pour la représentation de l'architecture d'un système est une description par des Machine Charts. La syntaxe des icones est relativement simple, chacun possède une sémantique précise exprimant le comportement inter-composants. La représentation graphique est une méthode naturelle de pensée pour les ingénieurs, elle facilite aussi la communication entre participants. La notation est dérivée des diagrammes de BUHR [BUHR-84]. M.C.S.E 133

Partie 2 - MODELES ET METHODOLOGIES L’objectif par les Machine Charts est d’exprimer: - l'architecture abstraite d'un système, - le comportement par l'exemple, en exprimant des diagrammes temporels sur la base de scénarios d'événements, - les spécifications opérationnelles abstraites ou formelles comme base pour l'analyse, l'animation, l'implantation: utilisation d'automates à états finis ou pseudo-code. Les Machine Charts sont basées sur un ensemble de symboles représentés très partiellement sur la figure 7.32. Les objets sont: des boîtes (boxes) correspondant à une modularité de structure autonome (packages, modules, units), des "robots" qui sont les objets représentant la modularité de comportement (acteurs, process, tâches), les "engines" qui sont les composants actifs. Les relations sont représentées par les "boutons" (buttons) et les "doigts" (fingers), la terminologie exprime directement la sémantique de l'interaction souhaitée. 2 types de relations Push et Push-Pull permettent de représenter des interactions asynchrones (activation immédiate), et des interactions synchrones type rendez-vous (activation conditionnelle).
PUSH (IMMEDIATE) BUTTON

FUZZY MACHINE

BOX

EVENT

ACTIVE ROBOT

PASSIVE ROBOT

PUSH-PULL (GATE) BUTTON

CHANNEL

(

)

DATA FLOW

ENGINE

STORE

Basic machines CHOICE FRAME

WAITING PLACE

PUSH

PULL Basic connections (fingers)

-Figure 7.32- Les icones de base des Machine Charts. La figure 7.33 illustre la sémantique des 2 types de liaisons. La notation de BUHR donnée ici n'est que très partielle. La figure 7.34 permet de se faire une idée de la représentation graphique préconisée et la figure 7.35 montre un diagramme de comportement induit par la structure. 7.12.2. La méthode Selon BUHR, la notation Machine Charts permet grâce à des outils la "compilation" d'une conception en un squelette de programme pour l'implantation, ceci d'une manière relativement automatique. Une méthodologie a donc pour objectif de permettre aux concepteurs de passer des spécifications à une conception. C'est l'objectif de SDWMC. 134 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

A B C

A B C

Bouton activations simultanées

Bouton activations en séquence

-Figure 7.33- Notation et comportement pour les interactions. La méthode JRBS consiste à exprimer la solution en recherchant simultanément les 2 composantes: structure et comportement. Le comportement concerne celui de la solution globale et donc des interactions entre les objets de la structure et non celui des objets euxmêmes. Ce dernier comportement dérive d'un raffinement dit fonctionnel qui se déduit par la suite. La démarche de conception est la suivante: - Spécifier par des Diagrammes flots d'événements (EFD). L'application est décomposée en sous-ensembles. Les événements représentent les interactions entre ces sousensembles pour les coordinations et les échanges de données. Ce diagramme est du type structurel, tandis qu'un DFD est fonctionnel. - Rechercher les composants de l'architecture. Le concepteur est libre de procéder séquentiellement ou en mixant les approches structurelle et comportementale. L'approche structurelle conduit à mettre en évidence les composants. Les relations événementielles sont ensuite transformées en connexions explicites entre composants. L'approche comportementale est plus aisée à partir de spécifications comportementales. Les liens flots de données sont transformées en connexions induisant ainsi une structure. - Exprimer la fonctionnalité de chaque composant. Distinct de l'interaction entre composants, il s'agit de décrire les données internes, les traitements sur celles-ci. La figure 7.36 résume cette méthodologie en indiquant les 3 types de vues et les itérations possibles entre les vues. 7.12.3. Remarques Cette méthodologie est spécifique de la phase de conception préliminaire. La solution est recherchée et exprimée sur le plan architectural. La notation graphique favorise la compréhension, la vérification et une production automatique du squelette de l'application. L'ajoût de la fonctionnalité de chaque constituant sous une forme algorithmique est simple. Ceci est donc une démarche intéressante vers l'utilisation d'outils de CAO. M.C.S.E 135

Partie 2 - MODELES ET METHODOLOGIES

Composants bien définis

"A"

"B"
M M "B" "A"

RR

RR

FWD

1 DIRECTORY 3
PARTNER GO

FWD

DIRECTORY

3
PARTNER GO "A"

Wait_id

2

2
"A"

1
M "B" "A" SEND WAIT

"B" M

ack
DONE SEND WAIT DONE

RR_MGR PUT

RR_MGR PUT

fwd

fwd ack
NOTIFIER NOTIFIER

RRM RRM

RRM RRM

SEND

RCVE

SEND

RCVE

Emetteur

COMM

COMM

Recepteur

-Figure 7.34- Exemple de structure pour un échange distant par rendez-vous.
.
EMETTEUR "A"
SEND WAIT Wait 10 11

RR_MGR
1

PUT SEND

NOTIFIER

RCVE

RCVE Wait 2 9 Wait

COMM

RECEPTEUR COMM
RCVE 3 Wait SEND PUT 8

NOTIFIER

RR_MGR
4 7 GO DONE

PARTNER
5 Wait 6

"B"

-Figure 7.35- Représentation du comportement pour l'exemple précédent. 136 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

STRUCTURE

Automate , StateChart Machine chart

JRBS

STRUCTURE COMPORTEMENT
RB COMPORTEMENT FORMEL

COMPORTEMENT PAR L’EXEMPLE

-Figure 7.36- Présentation de la Méthode SDWMC. La notation graphique est malgré tout complexe, et semble plutôt proche des problèmes de réalisation: échange synchrone ou asynchrone, partage de ressources, et apparait relativement liée aux concepts et mécanismes de ADA. La démarche n'exprime pas clairement comment passer des spécifications à une architecture, les modèles de spécification n’étant pas précisés. 7.13. METHODOLOGIE DE NIELSEN ET SHUMATE Elle est préconisée par leurs auteurs pour la conception des applications temps-réel complexes avec utilisation de ADA (ADA Design Methodology) [NIELSEN-88]. Elle résulte de l'association de la méthode DARTS pour l'aspect temps-réel, et des approches conception structurée et conception orientée objet. Cette méthodologie repose sur les 2 concepts: machines virtuelles (LVM) et conception orientée objet (OOD). 7.13.1. Modèles La modélisation d'un système est basée sur l'emploi d'un modèle par niveau, des spécifications jusqu'à l'implantation: - le diagramme flot de données pour les spécifications, - un diagramme de structure des process (PSC pour Process Structure Chart) pour décrire la solution fonctionnelle (voir la méthode DARTS), - un graphe des tâches parallèles (CPG pour Concurrent Process Graph) qui décrit l'implantation du diagramme précédent, - un graphe des packages ADA (APG pour ADA Package Graph) qui spécifie les objets avec leurs contenus et leurs interfaces, M.C.S.E 137

Partie 2 - MODELES ET METHODOLOGIES - un graphe structuré des objets ADA et leurs spécifications en utilisant les diagrammes de BUHR (SG pour Structure Graph), - le diagramme structuré (structure chart) pour décrire la décomposition de chaque tâche en procédures (voir Structured Design). 7.13.2. Démarche De cette modélisation se déduit aisément la démarche à suivre. On ne donne ici que les différentes étapes avec une illustration sommaire pour montrer la nature des modèles pour chaque niveau et la démarche progressive niveau par niveau par alternance entre spécification et conception. 1- délimitation des interfaces, 2- association d'un process pour chaque périphérique, ou entrée, ou sortie, 3- spécification de la partie centrale du système par un diagramme flot de données, 4- détermination du parallélisme et donc des process (PSC), 5- détermination des interfaces entre les process, 6- introduction de tâches intermédiaires pour l'implantation des relations inter-process (CPG), 7- encapsulation des tâches ADA en packages (APG), 8- traduction de la conception en ADA: spécification des objets et diagrammes de BUHR, 9- décomposition des tâches complexes (SD et OOD) et écriture de l'implantation, 10-revue de la conception pour vérification. 7.13.3. Remarques Cette méthodologie apparaît complète pour des applications temps-réel à réaliser avec ADA. Ceci n'est pas une contrainte impérative puisqu'une traduction peut aussi se faire dans un autre langage. Toutefois, elle suppose que la partie matérielle en tant que support est définie a priori. Elle concerne donc exclusivement la partie logicielle. Il n'est pas fait état d'une phase préliminaire d'analyse de l'environnement, d'expression des fonctionnalités et des contraintes de temps. C'est donc plutôt une méthodologie destinée à la conception puis l'implantation du logiciel d'un système temps-réel. L'approche à partir des diagrammes flots de données conduit à une architecture interne relativement complexe au vu du nombre de tâches ADA induit par la démarche. Si la modularité s’avère bonne, les performances risquent d'être faibles. 138 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

1 2 3
événement

SPECIFICATION

CONCEPTION

A3

Diagramme flot de données + contrôle

Process Structure Chart

T1

4
A5 T2 A4 T2 T3
ordre

A1 T1

A2

A6

5
T3 ADA Package Graph

6

P1 T1

8

7

P1 T1 T2

P2 T3 Buffer T3 P2 T2 P3 Structure Graph
Buffer ordre

P3

9
T1

Structure chart

-Figure 7.37- Illustration de la démarche par les modèles. 7.14. BILAN Après ce survol dont le seul objectif était de fournir des indications sur les méthodologies existantes, il semble utile de faire un point rapide. Constatons tout d'abord que chaque méthodologie a nécessité de l'ordre de 10 ans pour être relativement complète et connue au point d'être assez largement utilisée. M.C.S.E 139

Partie 2 - MODELES ET METHODOLOGIES Une méthodologie ne couvre pas obligatoirement tout le cycle de développement. Ceci est un point important à observer. Toutefois les plus récentes qui résultent de l'agrégation de méthodes éprouvées, ont pour but de couvrir au mieux l'ensemble du cycle. Force est de constater l'absence de méthodologie conduisant à une déduction cohérente de solutions à la fois pour la partie matérielle et pour la partie logicielle. La plupart des méthodologies supposent connue l'architecture matérielle et de ce fait sont plutôt orientées Génie Logiciel. Bien entendu, des outils se développent comme support pour ces diverses méthodologies. Ceci est une condition nécessaire sur le plan industriel pour faciliter la gestion et le suivi de grands projets de développement. Compte-tenu de l'effervescence dans ce domaine des outils dits CASE (Computer-Aided Software Engineering), volontairement nous n'avons pas voulu évoquer les outils existants comme support des méthodologies. Nous laissons le soin à chacun de rechercher au moment du besoin, les informations sur tous les produits susceptibles d'être intéressants. Comme aide, dans la partie 8 de ce document, nous proposons un guide sous la forme d'un cahier des charges pour un outil. Mais, il est utile de rappeler au lecteur que les outils servent comme support pour l'application d'une méthodologie, et pas l'inverse: un outil n'induit pas une méthodologie. Aussi, il n'est pas possible de se faire une opinion correcte de l'apport d'un outil sans connaissances sur les méthodologies. Pour cette raison ce chapitre est utile car beaucoup d'outils sont basés sur les modèles et méthodes qui y sont décrits. Ce panorama sur les méthodologies n'est bien sûr pas exhaustif; il n'est pas simple de toutes les connaître, puis de les résumer en quelques lignes. Certaines sont plutôt des dérivées d'autres méthodologies. Vu le nombre, il faut être conscient qu'il s'agit d'un besoin tout à fait réel. Ensuite, il est important de retenir que toutes les méthodologies sont basées sur une modélisation d'un système. C'est à partir des modèles qu'il est plus facile de comparer les méthodologies entre elles, en analysant les classes de problèmes traités, les modèles de spécification, de conception et d'implantation. On peut constater l'importance de 4 catégories de modèles qui se retrouvent dans la plupart des méthodologies : - le diagramme flot de données pour spécifier les activités, - le diagramme à états finis avec ses variantes pour le contrôle, - le diagramme structuré pour la décomposition des programmes. - le diagramme de structure pour exprimer l'architecture. Dans chaque catégorie existe une variété de modèles. Quels sont les modèles les plus appropriés ? Comment se situe la méthodologie M.C.S.E par rapport à celles qui viennent d'être décrites? C'est l'objectif du chapitre suivant que de présenter une synthèse des modèles afin que chacun puissse s'en servir comme guide pour la recherche et la compréhension des méthodes. En même temps il indique le point de vue retenu pour MCSE.

140

M.C.S.E

Chapitre 8

PANORAMA DES MODELES

Un modèle représente une description d'un système réel, ou d'un système qui deviendra réalité après sa conception, et ceci à un certain niveau de détail. Comme vues d'une application, les modèles diffèrent selon la description à exprimer: description externe pour une spécification, description interne abstraite pour une solution de principe, description interne détaillée pour une solution de réalisation. Un modèle est aussi utilisé pour décrire les caractéristiques d'un système à concevoir. Il sert alors de base pour la vérification de ses propriétés. Plus le modèle est précis et donc formalisé, plus il facilite le travail d'analyse. Les caractéristiques spécifiées par un modèle dépendent de la nature de celui-ci. Ainsi pour exprimer une propriété particulière, il s'agit de sélectionner une classe de modèles qui induit cette propriété. Vu la quantité et la variété des modèles, ce chapitre présente tout d'abord une classification des types de modèles. Les méthodologies reposent essentiellement sur des modèles conceptuels. En se basant sur les méthodologies décrites dans le chapitre précédent, les espaces de représentation communément utilisés pour exprimer la spécification et la solution sont détaillés dans ce chapitre. Cette présentation permet de dégager les modèles essentiels décrits par groupe.

M.C.S.E

141

Partie 2 - MODELES ET METHODOLOGIES Comme synthèse favorisant la compréhension et la comparaison des méthodologies, il est montré qu'en se basant sur 3 espaces de représentation, une méthodologie s'exprime comme une trajectoire dans ces espaces. La fin du chapitre explique la stratégie de développement pour MCSE. 8.1. BASES POUR L’ANALYSE DES MODELES 8.1.1. Qualités des modèles Un modèle est une représentation abstraite de tout ou partie du réel. Le terme abstrait est à prendre dans le sens simplification par élimination des détails non-utiles. Pour être exploitable, un modèle doit posséder quelques qualités générales: - Abstraction: cette qualité est nécessaire de manière à être utilisable pour la description des systèmes complexes. Elle répond à la nécessité d'exprimer le comportement de l'ensemble sans faire référence aux détails de toutes ses parties. - Raffinement: un sous-ensemble du modèle doit pouvoir être décrit à l'aide d'un autre modèle: du même type pour une description progressive, d'un type différent pour compléter la description ou exprimer un point de vue différent. - Lisibilité: le modèle doit être simple à interpréter. Ainsi les représentations graphiques sont généralement préférées aux descriptions textuelles. Il est intéressant de noter tout de suite l'intérêt des modèles graphiques qui favorisent la lisibilité par une compréhension globale améliorant ainsi la communication et la validation. La plupart des modèles donnant lieu à une représentation graphique découlent de la structure de graphe composée de noeuds et de liens entre ces noeuds avec ajoût d'une interprétation pour exprimer la sémantique du modèle. 8.1.2. Classification des modèles L'interprétation d'une situation, la compréhension d'un objet ou d'un phénomène conduisent à une grande variété de modèles possibles. De manière à cerner les modèles par grandes catégories, nous reprenons ici la classification donnée dans [WILSON-86]. La distinction est faite entre 4 formes de modèles: - les modèles iconiques, qui sont des reproductions en miniature d’un objet: voiture, avion, maquette de bâtiment pour des études en soufflerie par exemple. - les modèles analogiques, qui exploitent une apparence physique différente du phénomène ou objet à caractériser: réseau électrique pour une suspension de voiture par exemple qui est à la base du calcul analogique. - les modèles analytiques, utilisation de relations mathématiques et logiques pour représenter les lois physiques de comportement. - les modèles conceptuels, basés sur l'emploi de symboles pour la représentation des aspects qualitatifs. Dans l'ordre, l'approche modélisation fait appel aux modèles conceptuels avant d'utiliser les modèles analytiques. Les modèles analytiques permettent des vérifications par simulation directe ou par transformation en modèles analogiques. Un concepteur utilise essentiellement ces 2 catégories. 142 M.C.S.E

Ch 8 - PANORAMA DES MODELES 8.1.3. Modèles analytiques Les modèles analytiques sont très répandus et très variés. Ils sont utilisés comme moyen pour prédire ou estimer le comportement de certains aspects de l'objet ou de la situation concernée. Ils servent aussi comme moyen de validation. WILSON présente un classement des modèles en 4 catégories comme l'indique la figure ci-dessous.
Statique Dynamique

Relations

Relations différentielles

Déterministe

algébriques

Non déterministe

Relations statistiques et probabilistes

Relations stochastiques

-Figure 8.1- Catégories de modèles analytiques. Les colonnes de la matrice montrent la différence entre les modèles indépendants du temps et ceux qui en dépendent. Les lignes séparent les comportements certains et prédictibles des comportements incertains. 8.1.4. Modèles conceptuels Dans ce chapitre, on s'intéresse tout particulièrement à la catégorie des modèles conceptuels. Ils servent différents objectifs: - clarifier une situation: par exemple, structure d'une entreprise et liens entre les services, - illustrer un concept: diagramme en boucle fermée pour l'Automatique par exemple, - définir une structure, des relations: interaction de cause à effet entre des entités, - décrire une méthode: les étapes du cycle de vie pour le développement par exemple. Les 2 derniers cas d'utilisation sont les plus fréquents en conception. Les types de modèles conceptuels diffèrent selon la nature des informations ou des situations à représenter. La classification peut se faire selon plusieurs critères. Les catégories sont complémentaires. On indique ci-après quelques types de catégories.
-A- MODELE STRUCTUREL - MODELE COMPORTEMENTAL

Certains modèles représentent une topologie d'entités. Ce type de modèle est dit structurel. Les entités sont liées entre elles par des relations de dépendance. La dépendance peut concerner, des données, des activités, des événements, des ressources... Cette dépendance n'est pas temporelle, elle exprime seulement une dépendance fonctionnelle. M.C.S.E 143

Partie 2 - MODELES ET METHODOLOGIES Une autre grande partie des modèles servent à décrire le comportement d'une entité. Il s'agit là d'un modèle comportemental, souvent exprimé sous la forme d'un comportement temporel. Ces 2 catégories de modèles sont à considérer comme indépendantes ou "orthogonales". En effet, la définition de propriétés pour l'une des catégories n'apporte aucune information pour l'autre catégorie.
-B- MODELE ACTIVITES - MODELE DE DONNEES

La modélisation peut concerner: - les activités: c'est-à-dire l'expression des actions spécifiques de l'entité. Ceci se traduit par une relation d'ordre des actions pour un modèle comportemental, ou par une structure fonctionnelle pour un modèle structurel. - les données: il s'agit d'une description des états successifs d'une donnée qui s'exprime ainsi par une relation d'ordre pour le modèle comportemental, ou par la structure des données pour le modèle structurel. Il est intéressant d'avoir à l'esprit la dualité qui peut exister entre activités et données. En effet, un modèle de comportement pour une activité induit la possibilité de décrire l'évolution de la donnée produite, et une modélisation pour une donnée induit par dualité le comportement de l'activité pour assurer l'évolution de la donnée.
-C- MODELE VERTICAL - MODELE HORIZONTAL

Une description structurelle peut se faire selon 2 axes: - l'axe vertical: un niveau plus détaillé résulte du raffinement de chaque entité du niveau supérieur. Les relations n'existent qu'entre niveaux consécutifs. Il s'agit d’une dépendance hiérarchique. - l'axe horizontal: un raffinement fait apparaitre exclusivement des relations horizontales. Les dépendances sont de nature fonctionnelle.
-D- MODELE CONTINU - MODELE DISCRET

Le modèle continu décrit l'évolution permanente d'un comportement, tandis que le modèle discret ne représente que des états particuliers à des instants spécifiques de l'objet.
-E- SYNTHESE DES CATEGORIES

Chaque modèle conceptuel peut se positionner sur la base du tableau figure 8.2 qui bien entendu est utilisable pour positionner les méthodes par analyse de la nature du ou des modèles employés. Pour mémoire, les modèles analytiques entrent dans la catégorie des modèles comportementaux. Si on s'intéresse aux 3 phases: spécification, conception, réalisation, on peut dire d'une manière générale que: - les modèles comportementaux servent plutôt à exprimer des spécifications de fonctions, - les modèles structurels décrivent l'architecture de la solution pour la conception. 144 M.C.S.E

Ch 8 - PANORAMA DES MODELES

Structurel

Comportemental

Activités

Données

Vertical

Horizontal

Continu

Discret

-Figure 8.2- Catégories de modèles conceptuels. En s'intéressant plus particulièrement à la conception, comme la solution d'un problème exprime simultanément pour les activités et les données des relations sur le plan structurel et celui des comportements, cette classification montre qu'une méthodologie ne peut pas être basée sur un seul modèle. En effet, décrire complètement un système (et donc le concevoir) nécessite de pouvoir exprimer différents concepts selon plusieurs niveaux d'abstraction. Chacun correspond à un point de vue: organisationnel, temporel, ressources. 8.2. OBJECTIFS DES MODELES POUR LES SYSTEMES Comme constatation du chapitre précédent, on retrouve en parcourant l'ensemble des méthodologies une utilisation de la plupart des catégories de modèles conceptuels. Aussi après avoir donné une première classification des types de modèles, intéressons-nous tout particulièrement à ceux utiles pour décrire les systèmes à concevoir. Pour se faire une idée précise de l'essentiel, différencions tout d'abord 2 objectifs pour la modélisation: - spécification: il s'agit d'exprimer les caractéristiques de l'"objet" à développer et ceci au maximum selon une vue externe: comportement, propriétés, contraintes. - conception: il s'agit alors de donner une description interne la plus explicite possible de la solution: structure, comportement des constituants. Détaillons les principes de modélisation pour chacun des 2 problèmes. 8.2.1. Modélisation pour les spécifications Pour respecter la rigueur du terme spécification, une modélisation doit être purement externe. Elle exprime alors exclusivement le comportement observable, ce qui se décrit par un ensemble d'énoncés dans un langage formel: utilisation de règles, relations, pré-conditions et post-conditions, prédicats, description axiomatique. De toute évidence, cette technique de modélisation est peu utilisée dans les méthodologies compte-tenu de la complexité et du manque de lisibilité en particulier par le demandeur. M.C.S.E 145

Partie 2 - MODELES ET METHODOLOGIES Une autre façon de modéliser consiste à exploiter des modèles dits explicites. Le terme "explicite" est à comprendre dans le sens de l'utilisation de données ou d’états à priori internes. Par exemple, un diagramme flots de données fait état d'activités et de données internes, un automate à états finis considère des états internes de l'objet spécifié. Pour toutes les méthodologies citées dans le chapitre précédent, les modèles entrent dans cette catégorie. Une raison essentielle justifie ce choix: l'objectif c'est de concevoir à partir de la spécification, aussi plus tôt dispose-t-on de renseignements internes, plus rapide sera la conception, sans toutefois confondre spécification et solution. La modélisation "explicite" d'un système dépend du domaine d'applications et par conséquent du point de vue adopté. Pour les spécifications on peut noter aujourd'hui un certain consensus pour une modélisation selon 3 vues complémentaires comme l'indique la figure 8.3. Les 3 vues correspondent à 3 espaces de représentation: - espace des données, - espace des états, - espace des activités.
SYSTEMES ELECTRONIQUES , D’AUTOMATISATION

CFD Modèle de contrôle
S1 E1/A1 S4 E2/A2 S2 E3/A3 S3 E6/A6

SYSTEMES D’INFORMATION
E4/A4

E5/A5

SYSTEMES INFORMATIQUES

Automate , Table de décision
DSD Modèle des données DFD Modèle des activités

E1

P1

P5 P3

R E3

E2

Spécification d’un système
P2

P4

Diagramme Entités/Relations de CHEN

Diagramme flot de données

-Figure 8.3- Modélisation selon 3 vues complémentaires. La modélisation des données (diagramme de Jackson, diagramme entités/relations) est le point de vue principal pour les systèmes d'information. La modélisation des états (automate à états finis, table de décision) est le point de vue pour les systèmes de contrôle tandis que la modélisation des activités (diagramme flots de données) est le point de vue pour les systèmes de traitement ou de calcul. Les systèmes devenant de plus en plus complexes et intégrant de multiples fonctions, les 3 vues sont devenues indispensables et complémentaires. En effet, pour les applications de l'Informatique Industrielle, la multiplicité des traitements conduit à s'intéresser à l'approche flots de données. De même, l'accroissement de la quantité des 146 M.C.S.E

Ch 8 - PANORAMA DES MODELES informations gérées implique de devoir s'intéresser à l'organisation de toutes ces données. Ceci explique pourquoi la spécification proposée par WARD et MELLOR dans RTSA comprend les 3 composantes: diagramme des activités, ajoût d'une partie pour le contrôle des activités, spécification des données entre activités. 8.2.2. Modélisation en conception La description interne d'un système requiert d'exprimer 2 types de renseignements: - la structure, qu'il faut comprendre comme un ensemble de constituants plus élémentaires et de relations entre ces constituants, - le comportement pour expliciter une évolution. La structure peut concerner des fonctions, des données, des ressources. Les ressources sont entendues ici comme les constituants plutôt matériels nécessaires pour l'application. Pour l'approche Objet, fonctions et données forment un tout. L'expression d'un comportement peut concerner chaque constituant (fonction, donnée, ressource) ou les interactions entre constituants. La description d’un système peut donc se faire selon deux vues: la vue fonctionnelle et la vue des ressources. Chaque vue nécessite d’associer une structure et le comportement des constituants. Ceci peut se représenter schématiquement comme l’indique la figure suivante.

interaction des fonctions

fonction i

Comportement fonctionnel

Comportement ressources

interaction des ressources

ressource i

comportement

structure

F1

F2

Solution d’un système

R1

Ri

F3

Fi

R2

Fonctions + données

Ressources

-Figure 8.4- Modélisation selon 2 types complémentaires. La vue des ressources est ici considérée comme différente de la vue fonctionnelle, la première servant comme support nécessaire pour la deuxième. Elle n’est pas souvent évoquée car la plupart des méthodologies considèrent le support exécutif comme existant. M.C.S.E 147

Partie 2 - MODELES ET METHODOLOGIES 8.3. PANORAMA DES MODELES L’analyse précédente a montré que les modèles utiles pour la spécification et la conception se classent en 2 catégories: les modèles de structure, les modèles de comportement. On passe ci-après en revue les principaux modèles de structure d’abord, puis de comportement qu'il est souhaitable de connaître en indiquant pour chacun son utilisation. 8.3.1. Modèle pour les activités Le diagramme flots de données est un exemple de modèle décrivant les activités. C'est un modèle structurel mais pour la spécification. Le comportement global n'est que partiellement exprimé par ce modèle. Le lecteur peut se reporter à la méthode SA pour retrouver les règles de représentation (voir 7.3). Dans plusieurs méthodologies il sert comme spécification de départ pour la conception. Son intérêt est de permettre de modéliser globalement une application sans passer par la modélisation de chaque entité. 8.3.2. Modèles pour les données 2 catégories de modèles structurels sont utilisés selon que la donnée considérée forme un tout indivisible ou correspond à une collection de données liées entre elles.
-A- DIAGRAMME DE JACKSON

Les données de taille importante ou contenant une variété de renseignements doivent être décrites par leur structure. Les langages de haut-niveau type PASCAL, ADA permettent ce type de description sous une forme textuelle. Le "typage" des données est à considérer comme une description logique. A un niveau plus élevé d'abstraction (niveau sémantique), la structure d’une donnée peut se décrire à l'aide de 4 symboles. - l'élément Terminal (rectangle), qui est une donnée indivisible et typée, - l'opérateur de Composition, qui représente le produit cartésien des données contenues, - l'opérateur Ensemble, qui désigne un regroupement d'éléments identiques (taille dynamique, incluant le cas d’aucun élément), - l'opérateur Alternative, qui permet d'associer une donnée particulière pour chaque valeur d'un attribut. Les liens orientés entre symboles représentent les chemins d'accès. On donne sur la figure 8.5 un exemple à titre d'illustration. La lisibilité de ces diagrammes est intéressante. A partir de cette représentation, il est particulièrement simple de déduire la structure logique en PASCAL par exemple.
-B- MODELE ENTITES-RELATIONS

Ce modèle permet de représenter un "monde" en termes d'entités, leurs attributs et les relations entre ces entités [MARTIN-88]. Une entité est une "chose": objet, personne, information... Chacune entre dans une catégorie (type de l'entité). Les entités ne sont pas obligatoirement des objets physiques. Il peut ainsi s'agir d'abstractions telles qu’un vol d'avion. Chaque type d'entité possède ses propres attributs (ou propriétés), qui permettent de différencier les entités entre elles. Les attributs prennent des valeurs, par exemple: mesures d'un objet telles que hauteur et poids. 148 M.C.S.E

Ch 8 - PANORAMA DES MODELES

DESSIN

composition

COULEUR

CARACTERISTIQUES

PROPRIETAIRES

Sélection
CERCLE RECTANGLE NOM

*

itération

X

Y

-Figure 8.5- Diagramme de JACKSON pour les structures de données. Lorsque les entités sont en relation entre elles, les relations expriment des faits pour le "monde" considéré. La sémantique de chaque élément d'une phrase utilisée pour exprimer des caractéristiques pour les données ou informations considérées induit assez naturellement sa catégorie: - les entités sont les sujets, objets, noms, - la relation est le verbe, - les attributs sont les modificateurs. La figure 8.6 donne un exemple de diagramme entités-association pour exprimer une modélisation. Les nombres sur les liens indiquent la cardinalité des entités pour chaque relation. Un seul nombre correspond à la notation de CHEN. Pour 2 nombres il s’agit de la notation française: 0 veut dire que toutes les entités ne sont pas obligatoirement liées par des relations, 1 veut dire que chaque entité n’intervient qu’une fois dans la relation, n veut dire une intervention dans plusieurs relations. Par exemple, toutes les sociétés ne passent pas des commandes, mais une peut passer plusieurs commandes. Ce modèle ne décrit pas de caractéristiques temporelles. Il s'agit d'un modèle de description statique. Les bases de données, noyau des systèmes d'information, sont basées sur ce type de modèle dit relationnel. 8.3.3. Modèles pour les fonctions Cette classe de modèles permet de représenter par une structure un ensemble de fonctions interconnectées. Elles peuvent aussi bien être du niveau fonctionnel que du niveau exécutif ou ressources. M.C.S.E 149

Partie 2 - MODELES ET METHODOLOGIES

1,n

SOCIETE

0,n

Appartient

passe commande

1,1
ETABLISSEMENT

1,1
COMMANDE

0,n

1,n

élément commande

0,n

PRODUIT

-Figure 8.6- Représentation d'une modélisation Entités-Associations.
-A- DIAGRAMME HIERARCHIQUE DE FONCTIONS

Ce type de diagramme exprime la décomposition d'un système complexe en une collection de sous-ensembles, ceux-ci liés par des relations entrées vers sorties. Il permet le raffinement et l'abstraction. Il s'agit d'un modèle vertical. La figure 8.7 est un exemple. Il n'indique pas pour ses constituants la chronologie temporelle. Par exemple, il n'exprime pas le séquencement ou les conditions sur les informations pour les entrées: X2 et Z1, X2 ou Z1, X2 suivi de Z1, ni s'il s'agit d'un déroulement parallèle ou séquentiel. L'expression de la hiérarchie est donc un ingrédient essentiel de structuration, mais n'est pas suffisant à lui seul.
-B- LE MODELE DE STRUCTURE FONCTIONNELLE

Le modèle structurel proposé dans MCSE permet aussi le raffinement et l'abstraction. Les relations entre les fonctions sont de trois types : synchronisation, partage de variables, transfert de messages. Au modèle est associée une interprétation exprimant le comportement des interactions entre les fonctions (voir partie 4). L'existence de cette interprétation réduit les degrés de liberté pour le concepteur, mais lui apporte en contre-partie une efficacité, puisqu'il suffit alors de compléter la description par le comportement interne de chaque fonction. Le modèle pour la structure d'exécution dans MCSE est similaire mais a pour objectif d'exprimer la structure d'un ensemble matériel. Le modèle Process Structure Graph utilisé dans DARTS et dérivé de MASCOT est relativement similaire, mais les types de relations pour exprimer le transfert de données sont plus nombreux. 150 M.C.S.E

Ch 8 - PANORAMA DES MODELES

ENTREE X

FONCTION A

SORTIE Y

DECOMPOSITION

ENTREE X

X1

FONCTION A1

SORTIE

Y1 Z1

SORTIE Y

X2

ENTREE

FONCTION A2

SORTIE Z2

X3

ENTREE

FONCTION A3

Y2 SORTIE

-Figure 8.7- Exemple de hiérarchie de fonctions.
-C- MODELE DE STRUCTURE OBJET

Dans cette catégorie on trouve les diagrammes de BOOCH, de BUHR, de WASSERMAN, de BISHOP... Ce modèle représente chaque objet par un diagramme possédant des points d'entrée et de sortie. La forme de l'objet et les caractéristiques des points d'entrée définissent assez précisément son type et donc son rôle vis-à-vis de son environnement. Les connexions entre les objets sont du type demandeur ou transmetteur vers demandé ou récepteur. 8.3.4. Modèles pour le comportement Cette catégorie est relativement riche en variétés de modèles. Le comportement est très souvent exprimé en temporel, mais pas exclusivement.
-A- MODELE MATHEMATIQUE

Il décrit: - le domaine des variables d'entrée et de sortie, - la transformation des entrées vers les sorties. La transformation peut être du type paramétrique: expression par un modèle analytique (une relation mathématique), ou par une relation non-paramétrique: expression des grandeurs de sortie pour des entrées particulières. Le premier type de relation utilise habituellement un modèle interne explicite, tandis que le deuxième est une vraie description externe. M.C.S.E 151

Partie 2 - MODELES ET METHODOLOGIES
-B- MODELES FORMELS

Un système peut se spécifier par un ensemble d'énoncés exprimés dans un langage formel (règle de grammaire, règles algébriques...). Par exemple, la méthodologie VDM (Vienna Development Method, IBM Vienne) est basée sur l'emploi d'un modèle explicite pour exprimer des spécifications [COHEN-86]. Ces spécifications sont composées de 2 parties: - la définition abstraite des données et des variables pour représenter l'état interne du système, - la définition des opérations et des fonctions agissant sur les données et les variables. Ceci se fait en exprimant le nom de l'opération et les paramètres d'entrée et de sortie, une pré-condition sur la valeur des paramètres d'entrée et de l'état initial qui définit l'exécution, une post-condition qui précise les valeurs prises par les variables et l'état final à l'issue de l'opération.
-C- PSEUDO-CODE

Une autre manière générale pour décrire le comportement consiste à utiliser une description textuelle structurée. Le langage peut être très proche du langage naturel ou plus proche des langages informatiques: PASCAL, ADA par exemple.
-D- AUTOMATE A ETATS FINIS (FSM)

Ce modèle permet une description comportementale simple, en exprimant les états discrets d'une entité et les conditions de changement d'état. C'est un modèle essentiel en Informatique et en Informatique Industrielle. Un automate est caractérisé par des états et des liens entre états représentant les transitions possibles. Un des états est l'état initial. 2 types de modèles sont bien connus, celui de MEALY pour lequel les actions sont associées aux transitions, celui de MOORE pour lequel les actions sont associées aux états. Ce dernier est plus simple mais moins pratique pour les spécifications. Une combinaison des 2 modèles est très utile pour exprimer un comportement d'une manière concise. La barre sur le lien comme transition est utilisée pour plus de clarté.
E1 E1 E1

EV/ACT1

EV

EV/ACT1

E2

E2

ACT2

E2

ACT2

Notation de MEALY

Notation de MOORE

Combinaison des deux

-Figure 8.8- Notation pour l'automate à états finis. 152 M.C.S.E

Ch 8 - PANORAMA DES MODELES L'expression d'une simultanéité d'évolution nécessite la juxtaposition de plusieurs automates avec des couplages exprimés par des conditions de transition qui dépendent des états des autres automates ou des événements produits par ceux-ci. Il est similaire au Grafcet quand ce dernier n'exploite pas le parallélisme. Il ne se prête pas à la représentation de la complexité, car il s'agit d'un modèle "plat" et donc limité pour le raffinement. Ce modèle est parfois étendu par l'emploi de compteurs: Extended Finite State Machine. Le Grafcet est aussi une extension de ce modèle en permettant la représentation d'un parallélisme.
-E- LE STATECHART

Développé par HAREL [HAREL-87], le statechart remédie aux limitations essentielles de l'automate à états finis (voir 7.9.1). Nous conseillons aux lecteurs de regarder de près ce modèle, car il apparaît extrêmement séduisant pour exprimer des comportements séquentiels avec simultanéité pour des systèmes de contrôle.
-F- RESEAU DE PETRI

Le réseau de PETRI est un graphe bipartite composé de places et de transitions. La notion de marquage des places permet d'exprimer le séquencement temporel et la concurrence [NUSSBAUMER-84]. Les règles d'évolution sont très simples: une transition n'est franchissable que lorsque toutes les places en amont possèdent au moins un jeton. Sur franchissement (rien ne dit quand) il y a retrait d'un jeton de toutes les places précédentes et ajoût d'un jeton dans toutes les places suivantes. Les structures de base sont représentées sur la figure 8.9. Lorsqu’une place est liée en sortie à plusieurs transitions, il y a possibilité de conflit (cas de la concurrence). Dans ce cas le jeton ne sert que pour le franchissement d’une seule transition.

b

a

Séquencement

Sélection

Synchronisation

Concurrence

-Figure 8.9- Les structures de base pour le réseau de Pétri. Diverses interprétations sont données aux places et aux transitions: - place = activité, - place = état, transition = condition de fin, transition = condition d'évolution et Action atomique associée,

- place = ressources, transition = activité. Pour ce 3ème cas, chaque activité ne peut intervenir que lorsque les ressources d'entrée sont disponibles (jetons dans les places précédentes), produisant ainsi des ressources en sortie. Ainsi les réseaux de PETRI permettent par exemple de représenter des processus de production. La M.C.S.E 153

Partie 2 - MODELES ET METHODOLOGIES figure suivante représente le processus des visites dans un laboratoire d'analyse médicale et le réseau de Pétri correspondant.
Patient Médecin Secrétaire
Réception autorisation Employé

Autorisation
formulaire de demande d’analyse

médecin patient

Echantillons

Fichier
Echantillons

formulaire mis à jour

Analyse

analyse

résultats

Résultats

Edition rapport

Edition du rapport

Rapport

Rapport

-Figure 8.10- Exemple de description par réseau de Pétri. Des propriétés intéressantes pour les systèmes parallèles peuvent être vérifiées en utilisant les réseaux de PETRI: réseau sauf, propre, vivant. Ce modèle est intéressant pour exprimer et valider la spécification du comportement d'un ensemble d'entités, puis pour valider une conception qui résulte de cette spécification. Malgré ces avantages, les limitations essentielles sont similaires à celles de l'automate à états finis. Il s'agit d'un modèle "plat", le réseau de Petri devient rapidement complexe. Toutefois, si une transition ne possède qu'un point d'entrée et un point de sortie, la technique de raffinement est exploitable. D'autre part, il limite la spécification à une description de l'évolution du contrôle, rien concernant les données. Or souvent, le contrôle dépend de l'état des données.
-G- RESEAUX DE COMMUNICATION

Ce modèle est dérivé du réseau de PETRI pour le cas particulier du graphe d'état (1 lien entrant et 1 lien sortant pour chaque transition). Il est aussi appelé automate de communication (CFSM). La place représente un état d'attente. A chaque transition sont associées: - une condition de franchissement, généralement réception d'un événement ou d’un message, - la génération d'une action sur franchissement de la transition: exemple émission d'un message. Ce modèle est particulièrement intéressant pour spécifier les protocoles de communication [ORR-88]. Il est du type stimuli/réponses. Selon les auteurs, il est exprimé sous diverses formes comme le montre la figure 8.11. 154 M.C.S.E

Ch 8 - PANORAMA DES MODELES

A1

A1

A1

A1

a
condition

a

b

a

b

b

ou
action A2

ou

ou

A2

A2

A2 SDL

ou

ou

Réception

ou

Emission

-Figure 8.11- Exemples de représentation d'un automate de communication. La validation de la spécification et l'évaluation des propriétés se font habituellement en considérant le réseau de PETRI équivalent. 8.4. CONCLUSION: LES MODELES DE MCSE Nous avions montré dans la partie 1 qu'une méthodologie repose sur un ou plusieurs modèles. Ce chapitre a conduit à la constatation que la modélisation d'un système nécessite plusieurs vues et donc plusieurs types de modèles. Il en découle qu'une méthodologie peut se définir par une trajectoire dans un espace de modélisation. Pour illustrer ce point de vue, la figure 8.12 explicite le cas de la méthodologie de NIELSEN et SHUMATE en séparant les 3 types de modélisation: spécification, description fonctionnelle, description exécutive ou implantation. La spécification conduit à élaborer par approches successives des diagrammes flots de données. La conception débute par une recherche des fonctions (process) directement à partir des activités. Les données sont ensuite spécifiées comme interfaces puis découle le comportement des fonctions. Le support matériel étant imposé, l'implantation logicielle se déduit par transformation de la structure de process. Ensuite il en est de même pour le comportement. Toutes les méthodologies décrites dans le chapitre précédent peuvent se représenter de la même manière, sachant que selon les méthodes les modèles utilisés diffèrent. La comparaison n'est donc pas des plus immédiate. M.C.S.E 155

Partie 2 - MODELES ET METHODOLOGIES

SPECIFICATION

DESCRIPTION FONCTIONNELLE

IMPLANTATION

Comportement

Comportement

Comportement

activités DFD

structure PSC fonctionnelle

Structure matérielle

DSD données Raffinement Données

CPG et APG Matériel imposé structure logicielle

-Figure 8.12- Trajectoire pour la Méthodologie de NIELSEN et SHUMATE. Nous disposons maintenant de tous les éléments pour caractériser l'approche proposée dans MCSE. La figure 8.13 représente la trajectoire de développement pour les 3 niveaux de modélisation.
SPECIFICATION DESCRIPTION FONCTIONNELLE IMPLANTATION

Comportement

Comportement

Comportement

1

ou

2

Structure d’activités (DFD)

Structure fonctionnelle

Structure d’éxécution ( processeurs)

Structure de données

Raffinement DFD

Structure de données

Raffinement fonctionnel

Structure des tâches logicielles ( implantation logicielle)

-Figure 8.13- MCSE expliquée par une trajectoire dans 3 espaces. Cette figure permet d'expliquer la méthode décrite dans les parties qui suivent du présent ouvrage: - la partie 3 montre que, selon la complexité, la spécification s'obtient suivant 2 trajectoires possibles: faible complexité (1), car il est alors possible d'exprimer directement le comportement global pour chaque entité, complexité plus importante (2) nécessitant alors la caractérisation des activités de l'application. - dans la partie 4, la démarche pour déduire une description fonctionnelle consiste à débuter par les données puis les fonctions, ce qui conduit alors à une structure fonctionnelle. Une itération par raffinement est possible. La description est obtenue lorsque le comportement interne des fonctions de base est défini. 156 M.C.S.E

Ch 8 - PANORAMA DES MODELES - la partie 5 précise l'ordre de recherche des constituants: tout d'abord les processeurs, ensuite les tâches logicielles sur les processeurs programmables, pour finir par le comportement imposé à chaque processeur par les tâches. Concernant les spécifications, l'espace de modélisation en 3 dimensions est similaire à la plupart des méthodologies. Adapté pour les systèmes temps-réel, MCSE préconise d'exploiter de préférence la dimension comportementale avant la dimension activités. Ceci se justifie car l'analyse du problème doit se faire à partir des entités de l'environnement. Il est alors possible d'exprimer le comportement de ces entités sous l'influence du système. Si cette approche ne s'avère pas simple (multitude d'entités et mal identifiées), la démarche par les activités est alors plus efficace. Concernant la conception, le modèle fonctionnel est simple et indépendant de la technique pour l'implantation. La solution découle d'une recherche des données et donc des relations au préalable des fonctions. Ceci est un point de différence essentiel. Plusieurs méthodologies déduisent par transformation, les fonctions ou process à partir des activités de la spécification. MCSE part du principe que la vue interne est très différente de la vue externe. Ainsi, le concepteur doit faire un travail d'analyse et de synthèse pour développer une architecture fonctionnelle simple, appropriée et efficace. Lorsque, par raffinement, une fonction est de nature séquentielle, le comportement est exprimé par une description en langage de hautniveau du type PASCAL par exemple. Pour l’implantation, MCSE a la particularité de traiter simultanément les 2 aspects matériel et logiciel. La méthode de recherche de la solution pour la réalisation est complète car conduisant à l'architecture matérielle et à l'implantation logicielle. La déduction se fait par des transformations en utilisant les contraintes de temps comme critère de décision. L'architecture matérielle est tout d’abord déduite avec l'objectif de réduire son coût de reproduction. L'implantation logicielle est ensuite exprimée pour tous les processeurs programmables. A nouveau par transformation, celle-ci est adaptable à diverses techniques de réalisation: réalisation conventionnelle, utilisation du langage ADA, réalisation orientée objet.

M.C.S.E

157

BIBLIOGRAPHIE 2

OUVRAGES [ABBOTT-86] An integrated approach to SOFTWARE DEVELOPMENT R.J. ABBOTT WILEY -interscience publication- JOHN WILEY&SONS 1986 [ALFORD-82] Distributed Systems. Methods and Tools for Specification M.W. ALFORD, J.P. ANSART, G. HOMMEL, L. LAMPORT, B. LISKOV, G.P. MULLERY, F.B. SCHNEIDER. Lectures notes in Computer science. Springer-Verlag 1982 [BOOCH-83] Software Engineering with ADA G. BOOCH Benjamin/Cummings, Menlo Park,CA. 1983 [BUHR-84] System Design with ADA R.J.A. BUHR Prentice-Hall, Englewood Cliffs N.J. 1984 [BUHR-89] System Design with Machine Charts: A CAD approach with ADA examples R.J.A. BUHR à paraître chez Prentice-Hall 1989 [CAPRO-86] Systems analysis and design H.L. CAPRO The Benjamin/cummings Publishing Company, Inc 1986 M.C.S.E 159

Partie 2 - MODELES ET METHODOLOGIES [COHEN-86] The specification of complex systems B. COHEN, W.T. HARWOOD, M.I. JACKSON Addison-Wesley publishing Company 1986 [COX-86] Object oriented programming: an evolutionnary approach B.S. COX Addison-Wesley 1986 [DEMARCO-79] Structured analysis and system specification T. DEMARCO Yourdon computing series -YOURDON PRESS- Prentice-Hall 1979 [HATLEY-87] Strategies for Real-time System Specification D.J. HATLEY, I.A. PIRBHAI Dorset House Publishing New-York 1987 [JACKSON-83] System development M. JACKSON C.A.R HOARE series, Prentice-Hall 1983 [JENSEN-79] Software Engineering R.W. JENSEN, C.C. TONIES Prentice-Hall International Editions 1979 [MARTIN-88] Structured techniques-the basis for CASE J. MARTIN, C. Mc CLURE Prentice-Hall 1988 [NIELSEN-88] Designing large real-time systems with ADA K. NIELSEN , K. SHUMATE Intertext Publications Inc. Mc GRAW HILL, N.Y 1988 [NUSSBAUMER-84] Informatique Industrielle II. Introduction à l’informatique du temps réel H. NUSSBAUMER Presses Polytechniques Romandes, Collection Informatique 1984 [TEICHROEW-83] System description Methodologies édité par D. TEICHROEW, G. DAVID NORTH-HOLLAND Proceedings of the IFIP TC2 conférence Hongrie 1983 160 M.C.S.E

BIBLIOGRAPHIE 2 [WARD-85] Structured Development for real-time systems P.T. WARD, S.J. MELLOR. Vol.1: Introduction and Tools Vol.2: Essential modeling Techniques Vol.3: Implementation modeling techniques Yourdon Computing series -YOURDON PRESS- Prentice-Hall 1985 [WILSON-86] Systems: Concepts, methodologies and applications B. WILSON John WILEY & SONS N.Y. 1986

ARTICLES [ABBOTT-81] Software requirements and specifications: A survey of needs and languages. R.J. ABBOTT, D.K. MOORHEAD The Journal of Systems and software No 2 1981, P. 297-316 [ALFORD-85] SREM at the age of Eight; The distributed Computing Design System M. ALFORD Computer April 1985, P. 36-46 [BAILIN-89] An Object-Oriented Requirements Specification Method S.C. BAILIN Communication of the ACM vol 32 N5, 1989 P.608-623 [BOASSON-86] Modeling in Real-Time Systems L. BOASSON Computer Standards & Interfaces NORTH-HOLLAND, Vol.1 1987, P. 107-114 [BOOCH-86] Object-Oriented Development G. BOOCH IEEE Transactions on Software Engineering Vol. SE-12 N2, Fév.86, P.211-221 [BRACON-88] La spécification du logiciel dans l'industrie G. BRACON Bigre N58 Janvier 1988, P.12-19 [CAMERON-86] An overview of JSD J.R. CAMERON IEEE Transactions on Software Engineering Vol SE-12 N2 Fev. 1986, P. 222-240 M.C.S.E 161

Partie 2 - MODELES ET METHODOLOGIES [DAVIS-86] A practical Approach to Specification Technology Selection M.J. DAVIS, D.R. ADDLEMAN The Journal of Systems and Software N6 1986, P. 285-294 [DAVIS-88] A comparison of techniques for the specification of external system behaviour A.M. DEVIS Communications of the ACM vol 31 N9 sept 1988, P.1098-1115 [FREEMAN-86] Reusable Software Engineering Concepts and Research Directions P. FREEMAN Software Reusability: tutorial, computer society Press of the IEEE n750, P10-23 [GOMAA-84] A Software Design Method for the Real-Time Systems H. GOMAA Communications of the ACM vol 27 N9 sept 1984 [GOMAA-89] A Software Design Method for Distributed Real-Time Applications H. GOMAA Journal of systems and software N9 1989, P.81-94 [GOMAA-89] Structuring Criteria for Real-Time Systems Design H. GOMAA Proceedings of the 11th International Conference on Software Engineering1989, P.290-301 [HAGEMANN-88] Requirements Analysis for Real-time automation projects M. HAGEMANN Proceedings of 10TH International Conference on Software Engineering Singapore 11-15 Avril 1988, P. 122-129 [HAREL-87] Statecharts: a visual formalism for complex systems D. HAREL Science of computer programming North Holland, Vol.8, 1987, P. 231-274 [HAREL-88] STATEMATE: A working Environment for the development of complex reactive systems. D. HAREL, H. LACHOVER, and others. Proceedings of 10th International conference on Software Engineering Singapore 11-15 Avril 1988, P. 122-129 162 M.C.S.E

BIBLIOGRAPHIE 2 [HEITZ-87] HOOD, une Méthode de Conception Hiérarchisée orientée objets pour le développement des gros logiciels techniques et temps-réel. M. HEITZ Bigre N57 décembre 1987, Journées ADA France P.42-61 [IGL-82] Introduction à SADT Documentation IGL 1982 [JOHNSON-88] Deriving Specifications from requirements W.L. JOHNSON Proceedings of 10th International Conference on Software Engineering, Singapore 11-15 Avril 1988, P.428-438 [KELLY-87] A comparison of four Design Methods for Real-Time Systems J.C. KELLY Proceedings of the 9th International Conference on Softward Engineering Monterey, avril 1987, P. 238-252 [KERTH-88] MOOD: a Methodology for structured Object-Oriented Design N. KERTH OOPSLA 88, San Diego 1988 [KURTZ-89] An Object-Oriented Methology for Systems Analysis and Specification B.D. KURTZ, D. HO, T.A. WALL HELWETT-PACKARD JOURNAL April 1989, P.86-90 [LAVI-88] Embedded Computer Systems: Requirements Analysis & Specification An Industrial Course J.Z. LAVI, M. WINOKUR Proceedings of SEI Conference VIRGINIA Avril 1988 Lecture Notes in Computer Science: Software Engineering Education No 327 G.A. FORD Springer-Verlag p.81-105 [LUDEWIG-87] Specification techniques for Real-time Systems J. LUDEWIG, H. MATHEIS Computer standard & interfaces N6 1987, P.115-133 [ORR-88] Systematic method for Real-time system design R.A. ORR, M.T.ORRIS, R. TINKER, C.D.V. ROUCH Microprocessors and Microsystems Vol 12 N7 Sept 1988, P. 391-396 M.C.S.E 163

Partie 2 - MODELES ET METHODOLOGIES [RAMAMOORTHY-87] Issues in the development of large, distributed, and reliable software C.V. RAMAMOORTHY, A. PRAKASH, V. GARG, T. YAMAURA, A. BHIDE Advances in Computers, Vol 26 -Purdue (LD-26), P.393-443 [ROSS-85] Applications and Extensions of SADT D.T. ROSS Computer april 1985, P. 25-34 [SANDEN-89] An entity-life modeling approach to the design of concurrent software B. SANDEN Communications of the ACM vol 32 N3 march 89, P.330-343 [SEIDEWITZ-88] General Object-oriented Software Development: Background and Experience E. SEIDEWITZ 21st Hawaï International Conference and Systems Sciences 1988, P.262-270 [SHEMER-87] Systems analysis: a systemic analysis of a conceptual model I. SHEMER Communications of the ACM Vol 30 N6, June 87, P.506-512 [SOMMERVILLE-87] Describing Software Design Methodologies I. SOMMERVILLE, R. WELLAND, S. BEER The Computer Journal Vol 30, N2 1987, P. 128-133 [TSE-86] Integrating the Structured Analysis and Design Models: an Initial Algebra Approach T.H. TSE The Australian Computer Journal, Vol.18-N3, August 1986, P. 121-127 [WASSERMAN-89] Concepts of Object-Oriented Structured Design A.I. WASSERMAN, P.A. PIRCHER, R.J. MULLER Interactive Development Environments INC, 1989 [WARD-89] How to integrate Object-Orientation with Structured Analysis and Design P.T. WARD IEEE software March 1989, P.74-82 [YAU-86] A survey of Software Design Techniques S.S. YAU, J.J.P. TSAI IEEE Transactions on Software Engineering Vol. SE 12 N6 June 86, P.713-721 164 M.C.S.E

PARTIE

3

SPECIFICATION D’UN SYSTEME

La première phase du travail de développement concerne la détermination des spécifications du système souhaité, pour ensuite le concevoir et le réaliser. A partir du besoin exprimé par un demandeur et des utilisateurs, une spécification traduit ce besoin en une description complète externe comprenant toutes les informations nécessaires pour son développement. Il s'agit d'une étape délicate mais essentielle puisque la première, mais aussi parce qu'elle implique un dialogue important entre spécifieurs et demandeur. En effet, obtenir la description complète implique un transfert d'expertise et d'informations en provenance du demandeur. D'autre part une spécification doit être adéquate vis à vis de la demande, ceci nécessite sa vérification qui ne peut se faire que par les demandeurs et utilisateurs. Cette partie détaille le contenu du document de spécification et la démarche à suivre pour son élaboration. La spécification est définie pour être ensuite directement exploitable pour les étapes suivantes. Le Chapitre 9 présente sous l'appellation du cahier des charges, la nature de la demande comme expression d'un besoin. Le Chapitre 10 décrit les objectifs, nature et qualités d'une spécification. Le chapitre 11 présente les bases de la modélisation et les outils disponibles qui serviront à élaborer la spécification. Le Chapitre 12 détaille la structure et l'ensemble des constituants du document ainsi que la démarche à suivre pour construire la spécification. Cette démarche est illustrée sur des exemples pour lesquels les solutions seront développées dans les parties 4 et 5.

M.C.S.E

165

Chapitre 9

LE CAHIER DES CHARGES

Une première relation s'établit entre demandeur et concepteurs lorsqu'apparait un besoin. Par demandeur, nous entendons une personne, une société ou un organisme. Un besoin est la nécessité a priori d'un dispositif du type système électronique (pour se limiter au domaine considéré dans ce document) conduisant à améliorer -qualité, productivité, possibilités- une situation. Les concepteurs (dans le sens le plus général) sont les personnes capables d'analyser le besoin et d'y apporter une réponse. Pour les premières phases, le travail concerne des analystes et spécifieurs, et pour les phases suivantes, il concerne des concepteurs et réalisateurs. Les concepteurs peuvent faire partie du même organisme que le demandeur: ils peuvent par exemple appartenir à un autre service lorsque la structure possède la compétence en interne. Mais le plus souvent les concepteurs sont externes; l'étude du produit est dans ce cas soustraitée à l'extérieur. Ainsi les caractéristiques générales d'une telle relation sont les suivantes: - le domaine concerné par le besoin n'a rien ou peu de choses à voir avec les systèmes électroniques. - le demandeur et autres personnes telles que les utilisateurs ont l'expertise du domaine d'application du produit.

M.C.S.E

167

Partie 3 - SPECIFICATION D’UN SYSTEME - les concepteurs, spécialistes des systèmes électroniques, n'ont pas a priori de compétences dans le domaine du besoin. - le besoin n'est habituellement ni clairement ni totalement exprimé pour être exploitable directement par les concepteurs. L'objectif de ce chapitre est de clarifier le rôle de la première phase de relation autour d'un besoin. A partir de la situation initiale évoquée ci-dessus, il s'agit plus précisément d'analyser et de synthétiser les indications et le souhait du demandeur. 9.1. LE DEMANDEUR : SOURCE DU BESOIN Le contexte d'apparition d'un besoin est particulièrement varié. En effet, les systèmes électroniques comme technologie de réalisation permettent d'apporter une réponse à une immense variété de problèmes. Il n'est donc pas surprenant de constater que le demandeur ne possède pas la compétence nécessaire pour développer le système approprié. De même, il ne maîtrise pas le vocabulaire technique utile pour exprimer précisément son besoin dans un vocable directement exploitable par des concepteurs électroniciens. Ainsi, pour satisfaire le besoin, le problème à résoudre est soumis à l'extérieur. Sa description est alors faite dans un langage propre au domaine d'application. Au préalable de toute sollicitation externe, il faut s'assurer en interne de l'opportunité du besoin. Le besoin estil une nécessité? C'est déjà la première question à se poser. Cette tâche est de la responsabilité du demandeur qui doit faire une analyse de la valeur. 9.2. LE CONCEPTEUR: EXPERT DU DOMAINE DE REALISATION Le problème est posé à des concepteurs spécialistes des systèmes électroniques et de l'Informatique Industrielle. Exprimée dans une terminologie propre au domaine du besoin, la définition du produit est fort probablement incomplète et pas directement compréhensible. Peut-être aussi le problème ne nécessite-t-il pas obligatoirement la réalisation d'un système du type électronique. Il y a donc peu de chance pour les concepteurs de tomber d'emblée sur un problème très bien cerné sur lequel ils peuvent travailler avec efficacité pour définir la réalisation. Obligatoirement, un travail important de compréhension du problème et d'analyse du besoin est nécessaire. Ce travail est d'autant plus difficile que la différence des domaines d'expertise entre les 2 parties est importante. 9.3. LE CAHIER DES CHARGES: EXPRESSION DU BESOIN Le cahier des charges, premier document rédigé par le demandeur, décrit l'environnement dans lequel doit se trouver le système, les objectifs que celui-ci doit satisfaire, ainsi que ses propriétés et contraintes. Il a pour objectif de répondre à la première question essentielle qui est le pourquoi du système (WHY). Il sert ainsi comme premier intermédiaire entre des utilisateurs qui expriment leurs besoins et des concepteurs qui y trouvent une description de ce besoin [AMGHAR-89]. La description du besoin résulte d'une réflexion du demandeur avec ses collaborateurs qui, souhaitant le système, s'imaginent à la place de celui-ci pour décrire son rôle pour l'environnement. La description présente donc: - une vue de l'environnement du système décrit dans la terminologie du demandeur, 168 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES - le problème à résoudre et toutes les informations nécessaires pour l’utilisation du système. - les caractéristiques et toutes les contraintes auxquelles doit satisfaire le système. En général, le contenu du cahier des charges est très variable d'un demandeur à un autre et selon le problème concerné: très bref ou particulièrement volumineux, très vague ou très spécifique. Comme guide, le demandeur peut s'inspirer de documents de Recommandation pour l'élaboration d'un cahier des charges fonctionnel tel que par exemple la norme AFNOR x 50.151. 9.4. SOUHAIT DU DEMANDEUR Exprimant son problème, le demandeur attend une réponse rapide sur plusieurs points: - tout d'abord, la faisabilité du problème, - dans le cas positif: • • • • délai pour la réalisation, coût du développement, si nécessaire: le coût de reproduction, description de la fourniture.

A partir de cette réponse, le demandeur peut décider du développement ou non du système. Les concepteurs deviennent alors les prestataires, et le demandeur est le client. Le demandeur peut aussi souhaiter procéder sur la base d'un coût objectif plafond prédéterminé. La détermination du prix repose principalement sur des données extérieures au produit (budget, marché). Dans ce cas, le cahier des charges est ouvert et négociable. La motivation des concepteurs peut être soutenue par un principe d'intéressement aux résultats. 9.5. BUT ET IMPLICATION DU CAHIER DES CHARGES Tout concepteur souhaite disposer d'un cahier des charges définissant correctement l'environnement et les fonctions du système. Tributaire du bon vouloir du demandeur et de sa compétence à rédiger ce type de document, il est plus réaliste de se placer dans l'hypothèse d'une faiblesse générale du cahier des charges. Très probablement, les concepteurs doivent commencer par élaborer un tel document. Apparaît donc une question essentielle: quelles informations faut-il inclure dans le cahier des charges?. Pour y répondre, revenons sur les objectifs. Le cahier des charges contribue à clarifier et à formaliser les responsabilités relatives du demandeur et des concepteurs. De cette manière, son objectif est de servir comme document contractuel entre le demandeur en tant que personne ou en tant qu'organisation et les développeurs. Les concepteurs se trouvent contraints par le contenu du document car celui-ci détermine la fourniture. La certification du système utilisera en final ce document comme référence. C'est tout particulièrement le cas pour les appels d'offres (cahier des clauses techniques par exemple). Aussi le document doit contenir uniquement ce que doit être le produit, mais aussi tout ce que doit être le produit. Ainsi, au préalable de la rédaction du cahier des charges, le demandeur, sinon les concepteurs, se doivent: - de recueillir les informations pertinentes sur le produit envisagé, M.C.S.E 169

Partie 3 - SPECIFICATION D’UN SYSTEME - d'effectuer une analyse systématique et exhaustive du besoin, - de définir les critères d'appréciation du résultat. Toutefois, la responsabilité et par conséquent la liberté du choix des solutions doivent être réservées aux concepteurs. Le champ de recherche reste alors ouvert au maximum. Pour atteindre un tel objectif, le dialogue entre tous les partenaires est une nécessité. Comme guide, les questions suivantes fixent un premier cadre de dialogue avec le demandeur. - Quelles raisons motivent le développement du système? Quelles sont les attentes du client: marché, qualité, image de marque...? - Qui seront les utilisateurs, et comment comptent-ils s'en servir? Qu'en attendent-ils? Nature de leur expertise? - A quelles caractéristiques de l'environnement le système doit-il être conforme: interfaces existants ou prévus...? - Quelles fonctions exprimées dans le langage du demandeur devra assurer le système, quelles informations devra-t-il gérer? - Quelles sont toutes les contraintes: matérielles, temporelles, économiques, auxquelles doit se conformer le système? - Quelle doit être la forme finale du produit: maquette, prototype industrialisable, production en série, esthétique du produit? Questions utiles pour inciter le concepteur à dialoguer avec le demandeur ou pour faciliter l'analyse d'un document existant si celui-ci est plutôt exhaustif, il faut avoir à l'esprit qu'une description trop vague conduit à une difficulté d'estimation de la faisabilité et du coût du développement, et donc peut entrainer un risque important pour le prestataire qui accepterait la réalisation. De même un document trop précis contenant en particulier des esquisses de solutions impose des contraintes sur la réalisation. 2 raisons peuvent expliquer un excès de renseignements. - Il apparait plus facile de décrire un système qui résoud un problème que le problème lui-même. - Le demandeur est tenté de croire qu'un document décrivant uniquement les caractéristiques à satisfaire, peut rendre plus complexe le travail des concepteurs. Quelles informations faut-il inclure dans le cahier des charges? Les paragraphes suivant présentent la structure du contenu. 9.6. CONTENU ET GUIDE POUR LE CAHIER DES CHARGES La démarche pour l'obtention du cahier des charges n'a a priori pas d'importance. L'essentiel est la qualité du document et la pertinence de son contenu. En le complétant par un plan de développement et une évaluation du coût, il est utilisable comme réponse à la demande de prestation. La procédure logique est la suivante: - formulation du besoin (faite par le demandeur), ce qui inclut: une analyse du marché, une analyse fonctionnelle et une analyse de la valeur, - édition d'une première version du cahier des charges, - étude de faisabilité et affinement du besoin (demandeur-concepteurs), - décision de développement et rédaction du document définitif. 170 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES Comme guide pour la structuration du cahier des charges, on donne ci-après une esquisse du plan à suivre: 1- Présentation du document - demandeur, - organisation du document, - conventions, terminologie. 2- Présentation du produit - présentation générale du problème, - domaine, - marché, - objectif, - utilisateurs, organisation, - énoncé du besoin, - mise en fonctionnement, - maintenance. 3- Description de l’environnement - entités: caractéristiques, - informations: attributs, relations, - contraintes. 4- Description des fonctions à satisfaire - fonctions principales, - fonctions complémentaires, - configurations, options, variantes, - caractéristiques et performances. 5- Contraintes - contraintes d'interfaces, - contraintes de temps, - contraintes d'utilisation, - contraintes de réalisation, - maintenance et évolutivité, - fiabilité et sûreté de fonctionnement 6- Documentation - documents de spécification, de conception, de réalisation - manuels utilisateurs, procédures d'installation, maintenance et gestion du système. 7- Plan de certification - critères d'appréciation du résultat, - situations de test et scénarios, - limites d'acceptation, flexibilité. 8- Plan de développement - planning du développement, - support pour le développement. M.C.S.E 171

Partie 3 - SPECIFICATION D’UN SYSTEME Il est utile de se poser la question de la compétence nécessaire pour rédiger un tel document. Pas toujours possible par le demandeur, ce n'est pas non plus logiquement de la responsabilité des concepteurs. Probablement, le profil le plus approprié est celui de concepteurs qui ont évolué vers des études de faisabilité, la conduite et la responsabilité de projets, et qui ainsi ont pris conscience de l'importance d'un bon cahier des charges. 9.7. REPONSE A UN CAHIER DES CHARGES Le demandeur est le responsable des coûts, tandis que les concepteurs proposent une solution pour atteindre l'objectif. Le cahier des charges sert de base pour la consultation de prestataires potentiels. Il est demandé aux concepteurs de fournir une proposition répondant au besoin. De manière à faciliter l'évaluation des propositions et si nécessaire d'effectuer une comparaison dans le cas d'une consultation ouverte, on donne ci-après un exemple de plan de réponse. 1- Présentation du prestataire - organisme, - compétences dans le domaine. 2- Descriptif de la proposition - fonction assurée, - solution proposée (esquisse, avant-projet), - version de base, variantes... - qualité, fiabilité, évolutivité... 3- Plan de développement - planning, - support pour le développement. 4- Coût de la prestation - coût du développement (base, variantes), - coût de reproduction, - coût d'installation, de maintenance... Sur la base de telles réponses, le demandeur dispose des éléments objectifs lui permettant de décider de la suite à donner pour le produit. Il peut conclure d'arrêter ce projet pour diverses raisons: techniques, économiques, stratégiques... Sinon, faisant connaître sa décision de travailler avec un prestataire, il entreprend alors la phase finale de négociation et de signature d’un contrat. Le cahier des charges définitif joue dans ce cas le rôle de document contractuel. 9.8. EXEMPLES DE PROBLEMES Les 2 problèmes décrits dans ce paragraphe ont pour objectif, d'une part de montrer la nature des informations fournies par le demandeur, d'autre part de servir comme description des 2 études de cas qui vont permettre d’illustrer toutes les étapes de la méthodologie. Il ne s'agit bien-entendu pas de cahiers des charges complets tels que décrits dans les paragraphes précédents. Les exemples sont des cas simples par rapport à la complexité des problèmes soulevés par les industriels, mais suffisants comme support pour favoriser la compréhension de 172 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES la démarche préconisée. Tout concepteur peut aussi réfléchir sur différents points: que suggèrent ces problèmes: Ai-je la compétence pour résoudre ces exemples? Dispose-t-on de toutes les informations? Suis-je capable d'évaluer le coût et temps de développement? Quelle solution adopter? démarche... 9.8.1. Système de contrôle en vitesse d'un centrifugeur L'objectif est de disposer d'un système assurant la rotation d'un moteur selon un gabarit en vitesse donné. Un centrifugeur est un exemple d'application. Mais ce type de problème se retrouve dans une grande variété d'applications: déplacement en vitesse d'un chariot (ascenseur par exemple), pilotage d'un four selon un gabarit en température... Plus précisément, il s'agit de faire tourner un moteur à une vitesse constante fixée par l'utilisateur avant le lancement de l'opération. La rotation a lieu pendant une durée donnée, fixe ici, sachant que la montée en vitesse se fait à accélération constante, et de même pour la décélération. Le gabarit d'évolution de la vitesse est donné ci-après:
V

arrêt forcé Consigne vitesse

arrêt normal

arrêt forcé

marche
t TM = 5 s TC = 20 s TD = 5 s

-Figure 9.1- Description du cycle de rotation. Les temps TM, TC, TD sont fixes mais modifiables pour chaque système. Pour le contrôle du système, l'utilisateur dispose de 4 boutons-poussoirs: - MARCHE et ARRET pour débuter le cycle et l'interrompre avant la fin s'il le désire. - PLUS et MOINS, pour effectuer le réglage de la consigne de vitesse. Ce réglage est incrémental à chaque appui, mais pour un appui long, la progression devient géométrique: consigne modifiée de 1 en 1, puis de 10 en 10, puis de 100 en 100. Pour le réglage de la vitesse, l'utilisateur dispose d'un affichage en 4 digits de la consigne courante. La consigne est à régler avant un départ de cycle, et celle-ci n'est pas modifiable durant la rotation. L'afficheur présente alors la valeur de la consigne. De plus un voyant rouge est allumé durant toute rotation du moteur. M.C.S.E 173

Partie 3 - SPECIFICATION D’UN SYSTEME 9.8.2. Automatisation par chariot filoguidé Un véhicule filoguidé permet d'effectuer, sans intervention humaine, des travaux de manutention dans un atelier. Pour ce problème, il s'agit de faire passer des paquets d'un quai à un autre quai. Le véhicule suit une trajectoire fermée définie par un fil implanté dans le sol. Ce fil est émetteur d'une onde haute-fréquence. 2 quais sont disposés sur la trajectoire. Un couplage existe entre les quais en tant que donneurs d'ordres et le véhicule comme exécutant. La transmission se fait par une technique infra-rouge qui se comporte comme une liaison RS232. La description de l'atelier est représentée sur la figure suivante.
communication infra-rouge
Quai 1

paquet chariot
Quai 2

paquet fil de guidage

paquet butée pour arrêt du paquet tapis tapis chariot Quai roues capteur présence quai

-Figure 9.2- Description de l’atelier.
-A- CYCLE DE FONCTIONNEMENT POUR LE CHARIOT

Au repos le chariot est au quai 1. Il doit être capable d'effectuer automatiquement un cycle complet: chargement d'un paquet sur le chariot, transport du paquet à l'emplacement du quai 2, déchargement du paquet, retour au quai 1, attente de l'ordre suivant. Pour un cycle, on impose la séquence ci-après: - Le quai 1 vérifie tout d'abord la présence du chariot. Pour cela, il envoie un ordre d'interrogation de présence. Le chariot lui répond immédiatement s'il est présent. Si le quai 1 n'a pas de réponse au bout de TI, une sirène est activée pour alerter l'exploitant. - Si tout est correct, le quai 1 donne un ordre de chargement au chariot, ce qui se traduit par la rotation pendant TC (temps de chargement) du tapis situé sur le plateau du chariot. - Le quai 1 arrête la rotation de son tapis et donne l'ordre au chariot de se déplacer vers le quai 2. 174 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES - Arrivé au quai 2, la présence du chariot est détectée par le quai. Si le quai 2 ne détecte pas rapidement l'arrivée, le chariot active sa sirène. - Le quai 2 lui commande la décharge: rotation des 2 tapis chariot et quai durant TC. - Après TC et sur ordre du quai, le chariot repart vers le quai 1. - Son arrivée est détectée et le cycle peut reprendre. Tous les dialogues quai --> chariot se font par la liaison infra-rouge. La détection de présence à un quai (et donc d'arrivée) se fait par détection de présence d'un marque réfléchissante. On ne se préoccupera pas de ce qui advient lorsqu'une sirène est activée. L'exploitant se charge alors en manuel d'une mise en état de l'installation.
-B- DESCRIPTION DU CHARIOT

Le véhicule possède 3 roues. La roue avant est folle. Chacune des roues arrières est commandée directement par un moteur (M1, M2). Une différence de vitesse entre les 2 roues engendre une rotation du véhicule. Les quelques renseignements suivants permettent de mieux comprendre le fonctionnement imposé: - pour chaque déplacement, la vitesse nominale du véhicule est fixe VC, - la mesure de vitesse pour chaque roue doit se déduire d'un codeur incrémental directement couplé à chaque moteur, - pour suivre le fil, 2 capteurs analogiques C1 et C2 sont utilisés. Chaque capteur traduit en amplitude (AC1 et AC2) l'onde Haute-Fréquence reçue dont l'amplitude est inversement proportionnelle à la distance. Si l'onde reçue est trop faible, le capteur fournit une amplitude nulle. La position du chariot par rapport au fil sera proportionnelle à (AC1-AC2). Ainsi, la vitesse différentielle entre les 2 roues devra être proportionnelle à (AC1- AC2). - Le véhicule doit s'arrêter et activer sa sirène lorsque l'un des 2 capteurs ne détecte plus de signal (chariot trop éloigné), ou lorsque le radar placé à l'avant détecte un obstacle. - le démarrage et l'arrêt doivent se faire en 1s par variation linéaire de la vitesse.
-C- CARACTERISTIQUES OPERATOIRES ET TECHNOLOGIQUES

- La vitesse maximale VC est de 5 km/heure, les roues ont un diamètre de 30 cm. - Les codeurs fournissent 128 impulsions/tr. - Pour la qualité du suivi de la trajectoire, il faut commander chaque moteur selon une période telle que le déplacement n'excède pas 2 cm. - La précision sur la vitesse doit être de 5%, les capteurs C1 et C2 ont une précision de 1%. Le détecteur radar fournit un niveau logique TTL. - Les échanges par liaison infra-rouge se font à 2400 Bds. - La technologie microprocesseur peut être du 8 bits. M.C.S.E 175

Partie 3 - SPECIFICATION D’UN SYSTEME

système de transmission infra-rouge pivot de la roue avant

pare-choc et radar M1 fil de guidage

M2

Moteur du tapis roulant

capteurs c1 et c2

Chariot
Roue avant "folle"

-Figure 9.3- Description du véhicule filoguidé. 9.9. RESUME Ce premier chapitre a permis de prendre connaissance du contexte et de la procédure qui conduisent à l'établissement d'une relation contractuelle entre un demandeur et des concepteurs. Les points essentiels à retenir sont les suivants: - un besoin n'est jamais clairement défini. Un travail important de collaboration entre divers partenaires est nécessaire pour aboutir à un document explicite. - le document appelé cahier des charges, s'il est suffisamment explicite, sert de base pour la consultation des prestataires potentiels. - cahier des charges et propositions de développement permettent de décider de l'avenir du produit. Si une réalisation est souhaitée, un accord de collaboration se traduit par un contrat de développement. - savoir rédiger correctement un cahier des charges résulte d'une expérience qui ne s'acquiert que progressivement après avoir réalisé des projets, puis en avoir assumé la responsabilité.

176

M.C.S.E

Chapitre 10

OBJECTIF D’UNE SPECIFICATION

Le cahier des charges est exprimé et rédigé par le demandeur. Il sert de base pour les premières discussions avec des concepteurs. Il est donc l'évocation du problème à résoudre. De toute évidence, ce type de document décrivant plutôt le Pourquoi est très incomplet et ne permet pas d'avoir une base suffisante pour décider de la réalisation. Pourtant, avant que ne s'engage toute collaboration, il a été nécessaire de faire une évaluation financière a priori, qui conduit à la signature d'une convention ou d'un contrat de développement. A ce stade, l'erreur d'évaluation peut s'avérer importante. A partir du cahier des charges, clients et concepteurs ont à effectuer ensemble un premier travail de réflexion pour exprimer clairement l'objectif à atteindre. Intermédiaire entre la demande et la conception, une SPECIFICATION ainsi élaborée sert les 2 partenaires: - Tout d'abord le client, car il s'assure ainsi que son problème a été correctement interprété par les concepteurs, et qu'ainsi la réalisation qui résultera du développement sera conforme à son vouloir. Le travail de spécification peut aussi conduire à déceler des besoins non exprimés, ce qui induit une qualité meilleure pour le demandeur. - Les concepteurs ensuite, car se faisant de cette manière une idée précise du problème posé, ils peuvent entreprendre avec efficacité le travail de conception puis de réalisation. Une évaluation plus correcte du coût d'étude est aussi possible, ce qui peut conduire à une amélioration du contrat de prestation.

M.C.S.E

177

Partie 3 - SPECIFICATION D’UN SYSTEME Ce chapitre justifie le rôle essentiel joué par une spécification et précise sa nature par rapport au cahier des charges. Ensuite, sont énoncées les qualités d'une spécification et les grandes lignes du contenu du document, ainsi que les bases de son élaboration. 10.1. ROLE D’UNE SPECIFICATION Analysons tout d'abord la situation des différents partenaires dans le cadre d'un développement, pour déduire précisément le rôle d'une spécification. 10.1.1. Distance entre client et concepteur Le client pris dans son sens général en tant que demandeur d'un développement, possède l'expertise du domaine d'activité dans lequel va intervenir le système. Ce domaine peut n'avoir aucun point commun avec le domaine d'expertise des concepteurs qui est celui des systèmes électroniques dans le cas qui nous intéresse. Ainsi, le souhait exprimé par le client, transformé en obligation sous la forme d'un cahier des charges, ne représente en général que peu d'informations directement compréhensibles et exploitables par les concepteurs. De son côté, le concepteur peut penser avoir compris la demande, en s'étant imaginé sur la base de sa compétence, le produit utile pour le client. Compte-tenu de la distance en terme d'expertise entre les 2 types de partenaires, sans un travail commun de transfert de connaissances entre client et concepteurs, les chances de succès sont très réduites. Le produit développé peut s'avérer correct pour les concepteurs, mais inapproprié et inexploitable pour les utilisateurs. 10.1.2. Diversité des partenaires côté client Pour mieux saisir la difficulté de compréhension du problème, il est utile de connaître, côté demandeur, les différents intervenants concernés par le produit. Ainsi le terme client recouvre les catégories suivantes: - l'acquéreur du système: souvent négociateur et ordonnateur de la prestation. Il s'agit du responsable technique et/ou financier de l'opération. Son objectif est de satisfaire le problème au moindre coût et dans les délais impartis, et d'intégrer ce produit dans une perspective de développement de son organisation. - les utilisateurs, très souvent différents du responsable du développement côté client, auront à exploiter le système demandé. Ils sont concernés par les fonctionnalités, les performances, les procédures d'exploitation. Suivant la complexité du système, les utilisateurs peuvent eux-mêmes se subdiviser en catégories. La méthode de travail et la compétence de cette catégorie de personnel sont des éléments indispensables à considérer pour le succès du produit. - les installateurs, qui eux sont préoccupés par la procédure d'installation du système sur site. Simplicité et coût réduit font partie des objectifs à satisfaire. - l'équipe de maintenance, qui doit se préoccuper des qualités de maintenabilité du produit, documentation, compréhensibilité de la solution, moyens pour assurer la maintenance... 178 M.C.S.E

Ch 10 - OBJECTIF D’UNE SPECIFICATION - les fabricants, lorsque le système devra être reproduit dans l'organisation ou par soustraitance, pour une diffusion en plusieurs exemplaires. Les responsables des méthodes s'intéressent aux qualités de reproductibilité industrielle du prototype. Ainsi, vu la diversité des personnes concernées par le produit, chacun ayant des objectifs et contraintes pas obligatoirement compatibles, la conception d'un système jugé satisfaisant pour tous se révèle une tâche difficile sans compromis. 10.1.3. Importance d'une vérification Compte-tenu de la situation de chaque partenaire concerné par le résultat, il est évident que la première tâche essentielle pour les concepteurs consiste à aboutir à une bonne compréhension du problème posé. La démarche de travail, le dialogue, la rigueur et l'objectivité dans l'analyse sont des points essentiels qui favorisent la réussite. Mais, les concepteurs sont-ils garantis d'avoir saisi correctement le problème? Sans vérification intermédiaire, ils procèdent au développement puis à une réalisation. Le produit résultant n'est observable qu'en final et bien entendu il est alors vérifié par le client. Fort probablement certains aspects ne seront pas jugés satisfaisants pour différentes raisons: - L'expression du besoin au travers du cahier des charges n'est pas exhaustif, ce qui peut conduire à des interprétations différentes. - Durant la période de développement, les souhaits du client peuvent évoluer. Ce point est essentiel à considérer car il s'agit d'une situation inévitable. - L'idée que se font les concepteurs du produit peut aussi évoluer, mais dans une direction différente de celle du client par suite de la différence de compétence et de domaine d'activité. - Sans information compréhensible de la part des concepteurs sur ce que sera le système, durant l'attente du produit le client a tendance progressivement à douter du résultat escompté. De tels risques sont à éviter. Pour cela, il est indispensable d'assurer une vérification de la bonne compréhension du problème par les concepteurs. Vérification évidemment faite par le client, elle conduit: - à améliorer la définition du système qui en résultera, - à instaurer un climat de confiance entre le client et les concepteurs, car le demandeur, à travers l'analyse de la compréhension, a une vision précise du produit final, réduisant ainsi le doute. - à affiner la définition et les limites de la prestation de contrat, ce qui évitera des litiges en fin de contrat. Aussi, est-il essentiel de disposer d'une base de description permettant une vérification, même malgré la différence de "domaines d'expertise" entre les 2 parties. M.C.S.E 179

Partie 3 - SPECIFICATION D’UN SYSTEME 10.1.4. Une spécification comme document formel vérifiable Pour formaliser la compréhension du problème et l'objectif à atteindre, il faut disposer d'une description intermédiaire entre le cahier des charges qui exprime plutôt le Pourquoi, et la solution développée par les concepteurs: le Comment. Cette description intermédiaire (le Quoi) doit être vérifiable par le client pour validation, et être aussi directement exploitable par les concepteurs pour rechercher la solution puis la valider. Cet intermédiaire est appelé la SPECIFICATION du problème.
SANS SPECIFICATION

Expression du besoin

Problème

C D C

Developper

Produit

Satisfaction des besoins ?

Verification

AVEC SPECIFICATION

Expression du besoin

Problème

C D C

Spécifier

Satisfaction totale des besoins Vérification

S P E C I F I C A T I O N

Concevoir, réaliser

Produit

Vérification

-Figure 10.1- Intérêt d'une spécification comme intermédiaire. Déduit du cahier des charges par discussion avec le client et exploitable par les concepteurs pour exprimer une solution, le document de spécification est une interface essentielle entre le client et les concepteurs. Il permet de corriger le fait que ce qui n'est pas spécifié ne peut pas être vérifié et que ce qui n'est pas vérifié peut être erroné. Pour bien comprendre la signification du terme SPECIFICATION, considérons un produit existant tel qu'un composant intégré VLSI. Pour son utilisation, le fabricant élabore un document d'utilisation qui est en fait une spécification du composant. La description disponible est une vue externe du composant, qui détaille ses propriétés. Ici, une spécification est de même nature, mais à élaborer au préalable de la conception. Comme définition, une SPECIFICATION décrit les caractéristiques externes complètes du système à concevoir qui opère dans l'environnement précisé dans le cahier des charges. Il s'agit donc d'une description du système vu de l'extérieur, et qui possède les propriétés et qualités exprimées par le demandeur (WHAT), tandis que le cahier des charges décrit les propriétés et contraintes à satisfaire (WHY). 180 M.C.S.E

Ch 10 - OBJECTIF D’UNE SPECIFICATION Ainsi, dans MCSE, une différence essentielle est faite entre cahier des charges et spécifications, ce qui est confirmé par de nombreux auteurs [ABBOTT-86, LUDEWIG-87, WARD-85, HATLEY-87]. Bien entendu, cet intermédiaire augmente en apparence la quantité de travail dès le début du projet. Cité par LUDEWIG et MATHEIS pour le domaine du logiciel, ce qui est extrapolable sans grande erreur aux systèmes électroniques, près des 2/3 du coût total d'un produit est lié à des activités qui ont lieu à partir de sa mise au point. Ceci se traduit par un coût considérable de maintenance qui peut être à la fois du type correctif et évolutif. Ce coût diminue par réduction des corrections et modifications, et par réduction de la complexité du développement: complexité des circuits et cartes pour le matériel, nombre de lignes de programmes pour le logiciel. De même dans [RAMAMOORTH-87], il est indiqué que 30% des erreurs trouvées durant le test et la mise en fonctionnement, sont dues à une mauvaise compréhension du problème, et très souvent à la non-complétude d'expression des besoins dans le cahier des charges. Une bonne spécification contribue à réduire ces différents points. Ainsi, pour réduire le coût global d'un développement, il est souhaitable d'investir du temps par un effort accru en spécification. La figure suivante [LUDEWIG-87] présente l'intérêt d'un tel investissement pour un projet logiciel.
Coût ou ressources / unité de temps

100 %

*
Sans spécification

Avec spécification

besoin

spécification

conception

codage

installation maintenance

-Figure 10.2- Effort par phase avec ou sans spécification. Le point * est critique pour la conduite du projet. Il correspond au stade où la spécification n'est pas encore complètement cohérente, et où la conception est entamée sur la base des spécifications incomplètes. C'est donc l'instant où l'équipe peut douter de l'intérêt d'une bonne spécification. PARNAS cite des raisons supplémentaires en faveur d’une spécification complète [PARNAS-86]: - Les duplications et inconsistances sont à éviter. Sans document, les mêmes questions reviennent à des stades différents et peuvent conduire à des réponses non-homogènes. M.C.S.E 181

Partie 3 - SPECIFICATION D’UN SYSTEME - Un document complet est aussi nécessaire pour faire une bonne estimation du travail et des ressources nécessaires. - C'est aussi une garantie en cas de mobilité du personnel. - Il permet de préparer un plan de test. - Il est utilisable longtemps après que le système soit mis en fonctionnement. - Comme interface entre demandeur et concepteur, les échanges sont ainsi réduites. - Il peut servir de document de négociation et de référence pour d'autres affaires similaires (réutilisation). Idéalement ce document devrait être écrit par les utilisateurs ou leurs représentants. En fait, les utilisateurs n'ont pas souvent la compétence pour effectuer cette tâche. Aussi, c'est aux concepteurs d'assurer ce travail, puis de faire analyser le résultat par le client. 10.2. NATURE D’UNE SPECIFICATION Compte-tenu du rôle primordial joué par une spécification, la première étape de compréhension et de formalisation du problème s'avère particulièrement délicate. La compétence du spécifieur est un facteur essentiel pour la réussite du projet. Avant de s'intéresser à la démarche à suivre, il faut tout d'abord s'interroger sur la nature d'une spécification. Le point de départ de la réflexion consiste à considérer qu'il s'agit d'un intermédiaire vérifiable par le client et exploitable par les concepteurs, et ceci malgré la distance d'expertise entre les 2 parties. Tout d'abord, il s'agit d'un document papier. A celui-ci peut parfois s'ajouter un prototype pour un sous-ensemble du projet. C'est le cas d'une approche de spécification par prototypage. Ensuite et idéalement le document de spécification [LUDEWIG-87, ABBOTT-86] doit être: - correct: il doit refléter les besoins, - complet: toutes les caractéristiques et contraintes doivent y figurer, - cohérent: absence d'ambiguité et de contradiction, - compréhensible: structuré pour faciliter la lecture, et interprétable à la fois par le client et les concepteurs, - vérifiable: la description doit permettre d'affirmer la validité de la spécification, - exploitable par les concepteurs pour déduire efficacement une solution, - rédigeable et modifiable: la spécification doit pouvoir se transcrire sur papier. De plus, compte-tenu des manques ou évolutions souhaitées, elle doit être modifiable facilement. Pour satisfaire ces objectifs, une spécification doit respecter des qualités décrites dans le paragraphe suivant. 10.3. CARACTERISTIQUES D’UNE SPECIFICATION La qualité d'un document de spécification peut se juger en s'interrogeant sur les 3 points suivants: 182 M.C.S.E

Ch 10 - OBJECTIF D’UNE SPECIFICATION 1- LISIBILITE: une spécification doit être claire, sans ambituité de compréhension, et écrite dans un langage accessible aux 2 groupes de lecteurs. 2- TESTABILITE: Les concepteurs et le client doivent pouvoir vérifier la conformité de la réalisation aux spécifications. 3- MAINTENABILITE: comme généralement les besoins ont tendance à évoluer durant la phase de conception et de réalisation, les spécifications doivent pouvoir être aisément modifiées. Si le document ne suit pas toutes les évolutions acceptées qui apparaissent durant la conception puis la réalisation, le contrôle du résultat risque d'être très difficile. Pour répondre aux objectifs cités dans le paragraphe précédent, le document de spécification doit au moins satisfaire aux différentes caractéristiques suivantes:
-A- SUPPORT DE COMMUNICATION

Une spécification a été justifiée comme interface entre client et concepteurs pour réduire la distance et pour établir une base de vérification. Les problèmes de communication ne sont pas évidents à régler en l'absence d'un langage commun. Comme intermédiaire, le document de synthèse permet de formaliser la procédure de communication. Côté client, les personnes concernées répondent tout d'abord aux questions posées par le spécifieur qui extrait ainsi par dialogue les éléments essentiels pour les formaliser dans la spécification. Ensuite comme lecteur, le client approuve ou fait corriger les erreurs et manques. Côté concepteurs, le document permet une transmission globale de l'information, évitant ainsi les redites à des stades différents et l'apparition de réponses non homogènes.
-B- STRUCTURATION

Une spécification est une référence: il est donc nécessaire, comme pour tout document de ce type, qu'elle obéisse à un plan logique qui facilite sa lecture, sa consultation ponctuelle, sa modification. Une bonne structuration du document favorise la compréhension, la vérification, l'exploitation par les concepteurs. Pour le client et donc les utilisateurs, la structure d'une spécification doit conduire le lecteur à retrouver d'abord l'environnement du système qu'il maîtrise bien, puis la description des fonctions du système agissant sur cet environnement. Pour les concepteurs, la structure du document doit favoriser la recherche progressive de la solution, en s'intéressant d'abord au sujet par une approche fonctionnelle, puis au support de réalisation.
-C- SIMPLICITE ET ADEQUATION

La compréhension est liée à la simplicité de description des éléments contenus dans la spécification. Il est reconnu que tous les outils de description graphique simplifient la compréhension. Toutefois, les symboles doivent être suffisamment riches pour exprimer complètement et sans ambiguité une signification. Ainsi, le choix des outils de spécification appelés dans la suite modèles de spécification a une grande importance pour avoir le meilleur compromis entre la simplicité, l'adéquation, la lisibilité. M.C.S.E 183

Partie 3 - SPECIFICATION D’UN SYSTEME
-D- RIGUEUR DE DESCRIPTION

L'objectif pour un développement est de réduire son coût. Pour cela, il faut tendre vers une automatisation maximale de la production de la solution et de la réalisation correspondante. La production automatique nécessite, comme intermédiaire entre le besoin et le produit, de décrire la spécification de l'objet d'une manière formelle. Bien sûr, en plus, il faut pouvoir formaliser la procédure de production d'une solution. Pour progresser dans ce sens, il faut évoluer vers l'utilisation de spécifications formelles, tout en les conservant lisibles par le client pour la vérification.
-E- GESTION DE LA COMPLEXITE

Les modèles ou outils de spécification doivent permettre de décrire tout niveau de complexité des systèmes. Du fait des limitations de l'esprit humain à gérer tous les détails d'un système complexe, les outils de spécification doivent favoriser le partitionnement d'un système en sous-ensembles. Pour cela, la spécification doit reposer sur des modèles: hiérarchiques pour la description en niveaux, conceptuels ou abstraits plutôt que physiques de manière à éliminer les détails. Ainsi, une spécification permet de décrire le système à différents niveaux de détails et par parties. 10.4. GRANDES LIGNES DU CONTENU D’UNE SPECIFICATION Tout d'abord, notons 2 points tout à fait différents: - le document de spécification en tant que résultat final. - la méthode qui conduit à obtenir un tel document. L'essentiel pour le client et les concepteurs est le document final. Toutefois, le coût d'obtention d'un tel document peut se réduire en utilisant une méthode appropriée et en possédant des compétences spécifiques d'analyste. Le document de spécification, comme tout document, se doit d'être structuré. Le plan et le contenu doivent répondre le plus clairement possible au moins aux questions que se posent les lecteurs. Avant toute rédaction, chaque auteur de spécification doit au préalable se poser les quelques questions de bon sens suivantes: - A quelles questions doit répondre le document? - Quels sont les lecteurs? - Comment vont-ils utiliser le document? - Quelles sont les connaissances nécessaires pour sa lecture? La structure du document découle d'une réflexion sur les points précédents. Le plan suivant est donné comme esquisse pour la rédaction des spécifications. Le lecteur trouvera dans le chapitre 12 le détail du contenu de chaque partie. 1- Présentation du problème: cahier des charges, analyse succincte, terminologie. 2- Caractéristiques et modélisation de l'environnement du produit à réaliser. 3- Spécification des entrées et sorties du système. 4- Spécifications fonctionnelles: description des fonctions du système. 5- Spécifications opératoires: déroulement des opérations. 6- Spécifications technologiques: contraintes de réalisation. 7- Informations complémentaires (explications techniques, sources de documentation...). 184 M.C.S.E

Ch 10 - OBJECTIF D’UNE SPECIFICATION Ce plan montre que le spécifieur construit progressivement le document à partir des rencontres avec tous les acteurs côté client. Il commence tout d'abord par l'acquisition d'expertise ceci par analyse de l'environnement, puis il caractérise le système progressivement par affinements successifs. Au fur et à mesure de sa rédaction, le document est vérifiable par le client. 10.5. DIFFICULTES DU TRAVAIL DE SPECIFICATION En fait, le spécifieur se trouve dans une position intermédiaire délicate entre le client et les concepteurs. Le client en tant que donneur d'ordre est observateur et juge des résultats. Les concepteurs et réalisateurs assurent un travail technique bien défini et intéressant, et les relations entre eux sont assez simples puisque maîtrisant le même domaine de compétence. Pour le spécifieur, la situation n'est pas du tout la même. Les relations avec le client (et donc tous les intervenants) ainsi qu'avec les concepteurs nécessitent un travail permanent de négociation. Il est même possible de tomber sur des cas de participants hostiles à tout dialogue. Une spécification n'est jamais définitive ni pleinement satisfaisante. Résultat fait de compromis, un spécifieur, contraint par le temps, peut éprouver des sentiments de frustration. De plus, l'absence de méthodes et d'outils rend la tâche particulièrement difficile. Pour spécifier correctement, il faut être à même d'évaluer la faisabilité du produit et d'estimer le coût. Pour la faisabilité, le spécifieur doit être en mesure de déterminer les solutions envisageables, ce qui justifie de sa part une compétence en conception et réalisation. L'estimation du coût est une autre difficulté car ce type d'expertise ne peut s'acquérir que sur la base d'expériences. Or, les situations ne sont jamais identiques. Une spécification joue un rôle de nature défensive. Il s'agit beaucoup plus d'éviter les erreurs que de garantir le succès. Comme intermédiaire, lorsque des difficultés apparaissent, les concepteurs sont tentés naturellement de reporter la cause sur les spécifications, de même pour le client qui considère le spécifieur comme le responsable du projet. Même si la spécification permet un gain non négligeable sur le coût du projet en considérant l'ensemble du cycle de vie, rien ne permettra de prouver que ce gain résulte de la phase de spécification. Peut-être même au contraire, il sera évoqué le surcoût que représente cette tâche. En dépit de toutes ces difficultés, les industriels sont de plus en plus conscients de l'importance d'une bonne spécification, probablement comme résultante d'une réaction défensive issue de constatations multiples sur les difficultés à mener à bien des projets. Aussi, le métier de spécifieur est essentiel, au point de le trouver fascinant. Sur ce point, citons le propos de DEMARCO: "So analysis is frustating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it is fascinating. Once you’re hooked, the old easy pleasures of system building are never again enough to satisfy you!!" [DEMARCO-79]. 10.6. COMPETENCES POUR SPECIFIER Les spécifications se déduisent des informations indiquées par le client. Cette tâche n'est pas si simple qu'il n'y parait. C'est probablement la tâche la plus difficile dans le cycle de développement d'un système. Au moins, 3 qualités essentielles sont nécessaires pour aboutir à un bon résultat: adaptatif, communicatif, esprit d'analyse. M.C.S.E 185

Partie 3 - SPECIFICATION D’UN SYSTEME
-A- ADAPTATIF

A partir d'une compétence de généraliste, condition indispensable du fait de la variété des domaines d'application pour les systèmes électroniques, il faut être capable d'acquérir l'expertise nécessaire du domaine du client pour pouvoir rédiger la spécification. D'autre part, comme le document doit être exploitable par les concepteurs, il faut aussi être expert en systèmes électroniques pour être à même d'évaluer la faisabilité et pour exprimer la spécification en termes compréhensibles par les concepteurs.
-B- COMMUNICATIF

Pour acquérir l'expertise du domaine considéré, il faut être à l'écoute de tous les acteurs côté client. Mais ceux-ci peuvent ne pas être à même de juger de la pertinence de certains aspects. Aussi, c'est au spécifieur de déterminer les points essentiels et de conduire le dialogue pour extraire efficacement toutes les informations nécessaires. De plus, il doit être à même d'exprimer clairement et d'une manière synthétique mais suffisante, la description du système pour la rendre compréhensible aux 2 partenaires.
-C- ESPRIT D’ANALYSE

Le spécifieur a une responsabilité essentielle dans la réussite du projet. La pertinence de son analyse, le conduisant à diriger ses interrogations et ses dialogues avec les partenaires du projet, est une qualité essentielle de réussite. D'autre part, il doit éliminer de son esprit toute solution a priori. C'est aussi avec une part importante d'imagination qu'il peut construire une réflexion pour déduire les points essentiels. Dans les cas où le client n'a pas d'idées bien définies, l'esprit créatif du spécifieur peut conduire à l'obtention d'une qualité meilleure. 10.7. RESUME Ce chapitre a permis de montrer l'importance de la spécification comme intermédiaire entre le cahier des charges et la réalisation. Les points essentiels présentés sont les suivants : - la spécification est un document vérifiable qui permet de s'assurer de la bonne compréhension du problème, - pour jouer correctement son rôle, le document doit être compréhensible à la fois par le client et par les concepteurs. Pour cela, il doit être facile à élaborer, facile à lire, facile à faire évoluer, - le spécifieur assume un travail particulièrement difficile, dont l'impact sur un projet est essentiel mais peu mesurable. Sa compétence doit être multiple.

186

M.C.S.E

Chapitre 11

BASES POUR LA MODELISATION

Les chapitres précédents ont montré l'intérêt et la nécessité d'une description intermédiaire entre le client et les concepteurs. Cette description appelée spécification est essentiellement un document. Deux points importants sont à considérer ensuite: le contenu de ce document (nature et structuration des informations), et la démarche qui conduit à élaborer ce type de document. Intéressons-nous tout d'abord à la forme et au contenu du document pour ensuite expliciter la démarche. Une spécification a pour objectif de caractériser complètement un système ou un produit à concevoir sans faire état de sa structure interne: le quoi et non le comment. Décrire un système d'un point de vue purement externe revient à élaborer un modèle de comportement de celui-ci. Toute réalisation possédant les propriétés de ce modèle sera conforme aux spécifications. D'autre part, la spécification doit être facile à élaborer, facile à comprendre, facile à modifier. Pour satisfaire ces objectifs, une spécification doit être conforme à un modèle de spécification qui possède les propriétés et qualités attendues pour toute spécification. La première question importante à se poser pour disposer d'un modèle de spécification est donc: comment peut-on modéliser tout système sans faire état de sa solution interne, celle-ci étant l'inconnue à définir par la suite durant la conception?

M.C.S.E

187

Partie 3 - SPECIFICATION D’UN SYSTEME C'est l'objectif de ce chapitre que de répondre à cette question essentielle. Précisons d'emblée que le choix d'un modèle est une réelle difficulté compte-tenu du nombre d'articles et d’ouvrages existant sur le sujet. Il s'avère que le type de modèle dépend de la classe des problèmes considérés. Ceci nous a conduit à considérer dans MCSE, à défaut d'un modèle unique, l'association de plusieurs types de modèles de description. 11.1. QUE FAUT-IL CARACTERISER? Une spécification est une description purement externe de l'objet concerné. Pour toute application nécessitant un système électronique, celui-ci n'est pas seul, isolé du reste du monde. Si c'était le cas, sans liens externes, donc sans entrées ni sorties, même actif, il ne serait d'aucune utilité; nul ne peut agir sur lui ni constater le résultat de son activité. Ainsi, tout système est obligatoirement impliqué dans un environnement comprenant des objets. La figure ci-dessous montre la situation habituelle pour un système. Les objets peuvent être de nature variée.

entité 2

Interaction

entité 1 Observation

Action
Système

entité n

Environnement entité i Application

-Figure 11.1- Le système à spécifier et son environnement. Définissons tout d'abord la terminologie employée. Une APPLICATION au sens physique du terme est ici considérée comme le système fermé (ne possédant aucune relation utile avec l'extérieur pour le problème à traiter), formé du système à concevoir et des objets en relation avec celui-ci. L'ENVIRONNEMENT est l'ensemble des objets de l'application exclu le système. Les objets de l'environnement sont appelés des ENTITES. Un objet a un comportement dynamique et possède sa propre autonomie. Il s'agit obligatoirement d'une réalité fonctionnelle mais pas nécessairement physique. Une entité, tout comme un système, possède des entrées, des sorties, et au moins un état interne qui caractérise sa situation à chaque instant. Elle est modélisable aussi bien par une description externe qu'interne. 188 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Une entité fortement couplée par des entrées et des sorties sera considérée en interaction avec le système. C'est naturellement le cas par exemple pour l'entité utilisateur. Comme illustration, prenons l'exemple d'un système de commande pour le chargement automatique d'un chariot. L'objectif de l’application est de déplacer du matériau de P1 en P2 à l'aide d'un chariot. Un système électronique permet d'exécuter en automatique, sur demande de cycle par un opérateur, un cycle complet: P2 --> P1 --> chargement --> P2 --> vidage.
SYSTEME DE COMMANDE

cycle arrêt d’urgence Matériau trappe de vidage

P2

P1

-Figure 11.2- Exemple d’application. Cette application comprend 4 entités: le système de contrôle-commande, l'opérateur, le chariot, le tapis-chargeur. Chaque entité possède un état interne - position pour le chariot, en rotation ou non pour le tapis-chargeur - et a un comportement autonome influencé par ses entrées. La fonctionnalité de l'application qui consiste à réaliser un cycle automatiquement, est obtenue par l'entité système en assurant un couplage entre les 3 autres entités. Le comportement global ne peut être correct que si le système observe des grandeurs dans son environnement telles que position du chariot et demande de l'utilisateur, et agit sur le chariot et le tapischargeur. Un système est donc obligatoirement lié à des entités de son environnement. Pour caractériser le système, il faut nécessairement caractériser ses entrées et ses sorties. Les entrées du système sont des sorties d'entités qui permettent de prendre connaissance de leur état, les sorties du système sont des entrées pour les entités et donc des grandeurs d'action ou de commande pour ceux-ci. Inévitablement, la description externe du comportement du système passe par la caractérisation des entités. Ainsi, pour déduire sa spécification, la caractérisation du système concerne donc: - son environnement, - ses entrées sorties, - son comportement, - son utilisation. M.C.S.E 189

Partie 3 - SPECIFICATION D’UN SYSTEME 11.2. NATURE DE LA CARACTERISATION : MODELISATION Les entités de l'environnement existent ou vont exister. Les caractériser revient à décrire la nature et le comportement de chaque entité à un niveau donné de détails. Il s'agit donc de modéliser un objet réel sous la forme d'une abstraction. Le concept de modèle, les types et qualités ont été présentés dans la partie 2 chapitre 8. Rappelons qu'il existe 2 grandes catégories de modèles [COHEN-86, ALFORD-82, ABBOTT-86] : - les modèles externes, qui permettent de caractériser un système en exprimant exclusivement ses propriétés (property-oriented): axiomes, relations entre sorties et entrées, modèles algébriques, préconditions et post-conditions. Ces types de modèles sont très formels, non évidents à exprimer et à comprendre pour un non-spécialiste et plutôt adaptés pour exprimer des transformations. A noter que la signification du terme modèle externe est différente de celle utilisée en base de données. - les modèles explicites qui utilisent des éléments caractéristiques internes: variable d'état, activités ou opérations internes. Plus simples à élaborer et facilement interprétables par des non-spécialistes, ils sont particulièrement appropriés pour décrire des objets existants. Le niveau d'abstraction du modèle est fonction des détails de comportement souhaités. Par exemple, le chariot de l'exemple précédent peut se modéliser au moins selon 2 niveaux différents: - un niveau macroscopique, pour lequel la vitesse du chariot est représentable par 3 valeurs: 0 pour le chariot à l'arrêt, +VM pour le déplacement à droite et -VM pour le déplacement à gauche. - un niveau plus microscopique, pour lequel la vitesse du chariot est une fonction continue de la commande et de la charge qui introduit un effet d'inertie. D'autre part, une modélisation peut présenter des vues différentes d'un même objet. Il s'agit alors de différentes projections de l'objet sur son espace de description, par exemple: description statique, description dynamique, description des données, description des activités... 11.3. CARACTERISATION D’UNE ENTITE Avant de développer les modèles de description, analysons tout d'abord ce qu'est une entité et les éléments essentiels qui permettent de la décrire. A noter que cette analyse servira aussi comme base pour la spécification du système car celui-ci peut se considérer comme une entité ayant la particularité de ne pas exister avant sa réalisation. 11.3.1. Nature d'une entité Une entité est un objet conceptuel pour l'application. Elle peut avoir une existence physique ou matérielle tel qu'un opérateur ou le chariot, mais il peut aussi s'agir d'un objet fonctionnel ou logique, tel que par exemple un département dans une entreprise, ou bien un objet purement abstrait: le vol d'un avion par exemple qui résulte de l'association d'objets physiques et de données (avion, passagers, trajectoire...). Une entité possède sa propre identité définie par son nom. 190 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Pour faciliter la modélisation, les entités sont groupées en catégories reflétant chacune des caractéristiques communes. Chaque catégorie est nommée définissant ainsi un type d'entité; une entité de nom E est dite de type T. E est aussi appelée une instance de T. Toutes les entités d'un même type sont a priori différentes. Ceci est dû aux valeurs différentes des éléments caractéristiques. On dit alors que les éléments du type d'entité sont ses attributs. Par exemple, une personne comme type d'entité possède les attributs: poids et taille. 11.3.2. Nature des éléments caractéristiques Un type d'entité est caractérisable par un ensemble d'éléments et de relations. Cette caractérisation s'effectue à l'aide d'un modèle qui exprime les grandeurs caractéristiques de l'objet et les relations entre celles-ci. Le type de modèle à utiliser dépend de la nature des grandeurs caractéristiques et des relations. Pour cerner les classes appropriées de modèles, intéressons-nous aux catégories d'éléments caractéristiques. Pour les types d'entités qui concernent les systèmes électroniques, les éléments à considérer sont classés en 3 catégories: - les événements, - les données, - les actions et activités. Expliquons la nature de chaque catégorie.
-A- EVENEMENT

Un événement spécifie l’instant d’un changement d’état significatif. A cet instant est donc associée une signification. 2 types d'événements sont utiles pour les systèmes: - un changement d'état. Le nom de l'événement définit directement et complètement la signification. Par exemple, l'événement T50 veut signifier que la température vient de dépasser 50°C. - l'apparition d'une donnée. A ce type d'événement est associée une donnée. L'événement définit l'instant d'apparition ainsi que la disponibilité de la donnée. La donnée enrichit la signification de l'événement. Par exemple à l'événement: la consigne de température vient d'être modifiée est associée la nouvelle valeur de la consigne. Pour éviter toute ambiguité dans la terminologie lorsque la distinction s'avère nécessaire, le premier type est appelé EVENEMENT et le deuxième INFORMATION. Ainsi, une information a une existence limitée dans le temps et est caractérisée par son type qui est celle de la donnée associée.
-B- DONNEE

Une donnée est une grandeur (ou un ensemble de grandeurs) dont l'existence est considérée permanente. Seule sa valeur évolue dans le temps. Par exemple, le chariot est caractérisé par plusieurs variables que sont les attributs: la position, la vitesse, la quantité de matériau transportée. On dit aussi qu'une donnée est une variable caractéristique de l'entité. Une donnée est définie par son type caractérisé par des attributs. M.C.S.E 191

Partie 3 - SPECIFICATION D’UN SYSTEME Comme cas particulier important, une VARIABLE d’ETAT est une grandeur permanente servant à caractériser d'une manière unique et au niveau d'abstraction souhaité, la situation de l'entité. L'état d'une entité est représenté par l'ensemble des variables strictement nécessaires pour sa caractérisation à chaque instant. La nature des variables d'état dépend du type de modélisation souhaité. Par exemple pour le chariot, une modélisation de l'évolution du chariot nécessite de considérer sa vitesse et sa position à chaque instant. Pour une modélisation plus macroscopique, on peut se contenter des 2 variables à états discrets P et V avec: - pour la position P: P<P2, P2<P<P1, P>P1 - pour la vitesse V: arrêt, déplacement gauche, déplacement droite.
-C- ACTION ET ACTIVITE

Une action est considérée comme une opération ponctuelle agissant à un instant donné durant l'évolution de l'entité. Elle est indécomposable. On dit aussi qu'il s'agit d'une opération atomique. Une activité représente une vue de plus haut niveau. Elle représente l'enchaînement d'une suite d'actions. Ainsi, une activité couvre une période de temps aussi qualifiée de phase. Une activité peut se caractériser par un état, tandis qu'une action se caractérise par un événement. Par exemple, l'action de mise en marche du chariot par le système génère un événement pour l'entité commandée, ce qui entraine l'activité de déplacement et donc l'état en déplacement. La frontière entre ACTION et ACTIVITE n'est pas très précise. Selon le niveau de la modélisation (échelle de temps par exemple), une action considérée comme ponctuelle pour un niveau macroscopique est une activité pour une modélisation plus détaillée. Par exemple, l'action d'arrêt du chariot n'est pas instantanée si on tient compte de son inertie. 11.3.3. Dépendance entre éléments caractéristiques Action et activité sont les seuls types d'éléments générateurs (et donc actifs). La relation de dépendance est indiquée sur la figure suivante.

Données (pas obligatoire) ACTIVITE ou ACTION Evénement (obligatoire pour une action)

Données

Evénements

-Figure 11.3- Dépendance entre les classes d'éléments. Une action étant ponctuelle, seul un événement permet de décider de son instant d'intervention. Ainsi, une action agit en réponse à un événement. Par contre, une activité est dans l'état actif ou inactif. Seul un événement peut la faire changer d'état. En l'absence d'événement en entrée, l'activité est toujours effective sinon celle-ci n'est d'aucune utilité. 192 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Activités et actions peuvent produire des événements et des informations, modifier des données ou des états. Pour une entrée d'action ou d'activité et de manière à distinguer s'il s'agit d'une donnée ou d'un événement, nous utiliserons la simple flèche pour les événements (et donc aussi pour les informations) et la double flèche pour les données: notation identique à celle proposée par WARD. 11.3.4. Nature des entrées et des sorties Le caractère dynamique d'une entité résulte des activités et actions internes. Seuls les événements/informations, données et états assurent le couplage avec son environnement. En entrée de l'entité, les données et états sont observables à tout instant (consultation). Les événements et informations sont fugitifs: une information n’a plus de signification après sa prise en compte. En sortie, données et états permettent des observations externes permanentes, tandis qu'événements et informations engendrent des actions externes. 11.4. TROIS VUES POUR LA DESCRIPTION D’UNE ENTITE Compte-tenu de l'analyse précédente, comment peut-on modéliser une entité?. Les 3 éléments essentiels sont: donnée, événement, activité, sachant que: - l'état est un cas particulier de la donnée, - l'information est un événement à contenu signifiant défini par son type de donnée, - l'activité est un regroupement d'actions. Une action peut donc aussi se comprendre comme une activité ponctuelle. Il faut ajouter à ces éléments des relations de dépendance. Une donnée nécessite de décrire sa structure, sauf s'il s'agit d'un type élémentaire. Une activité n'existe qu'à des instants ou périodes dans le temps. Caractériser une activité nécessite, d'une part de la détailler (par exemple par une spécification), d'autre part d'expliciter son intervention dans le temps, ce qui impose d'exprimer ses dépendances temporelles en utilisant des événements ou des informations. Faute d'un modèle unique qui permette de rassembler toutes ces caractéristiques (voir en 8.2.1), une description cohérente pour une entité nécessite 3 vues complémentaires représentées sur la figure 11.4: - modélisation des données et informations (quoi). Il s'agit de décrire les caractéristiques de chaque donnée. Lorsque celle-ci est composée, sa structure et les type et domaine de définition de chaque constituant de base sont à décrire. Il s'agit donc exclusivement d'une modélisation structurelle. - modélisation des activités (comment). Elle a pour objectif de décrire les activités de l'entité et les relations avec son environnement par des données et des événements. Il s'agit à nouveau d'une modélisation structurelle. - modélisation du comportement (quand). Il s'agit de décrire les instants d'apparition des événements et informations, et les changements d'état des données engendrés par les activités. Ceci revient à modéliser le comportement qui peut être celui des activités mais aussi celui de l'évolution des données. M.C.S.E 193

Partie 3 - SPECIFICATION D’UN SYSTEME

QUAND

Comportement

Activités ENTITE

Données / informations

COMMENT QUOI

-Figure 11.4- Les 3 vues pour une entité. Ces 3 vues sont complémentaires et indissociables. Pour caractériser une activité, il faut connaître les données utilisées et produites. Pour caractériser une entité, il faut connaître l'ensemble des activités et les réactions de chacune aux stimuli en entrée. La cohérence globale résulte d'une spécification correcte pour chacune des vues, ce qui induit un moyen de vérification. En effet, une redondance existe entre évolution des données et évolution des activités, les activités modifiant les données. Il faut reconnaître la prépondérance des données sur les activités. En effet, les données d'une entité (en tant que type bien-sûr) sont plus stables que les fonctions et le comportement de celles-ci. D'où l'importance première à attacher aux données dans la modélisation. Le résultat de cette analyse est en accord avec les principes de modélisation préconisés par d'autres auteurs pour les systèmes temps-réel. HATLEY préconise une modélisation selon 2 vues: activités, contrôle pour le comportement. Il indique dans l'annexe C de son ouvrage la troisième vue concernant les données [HATLEY-87]. WARD et MELLOR considèrent les 3 vues pour la modélisation [WARD-85]. Dans la suite du chapitre nous détaillons la modélisation préconisée dans MCSE pour chacun des 3 types en décrivant les modèles à utiliser. Certains modèles ont déjà été présentés dans la partie 2 et sont rappelés ici pour que cette partie soit utilisable en autonome. 11.5. MODELISATION PAR LES DONNEES/INFORMATIONS Ne concernant exclusivement que les données et les informations, cette modélisation est indépendante des 2 autres vues. Les objectifs du modèle sont les suivants: 194 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION - permettre une définition complète, concise et compréhensible de la nature et de la structure des données: catégorie, composition, type de chaque constituant, - être approprié pour une large classe de données: du booléen jusqu'aux relations, - être conceptuel pour décrire exclusivement la signification et non une implantation. 11.5.1. Modélisation selon 2 niveaux La modélisation des données est un sujet largement développé dans la littérature. De nombreux auteurs en font état: [ABBOTT-86, DEMARCO-79, JACKSON-83, WARD-85, HATLEY-87, MARTIN-88]. L’approche adoptée ici est très proche de celle des modèles de données orientés objet, elle n’est donc pas limitée à des modèles du type relationnel [DATE86, GALACSI-86-89, BALLY-87, VELEZ-89]. Elle est basée sur l'idée qu'une donnée (en tant que type) peut se décrire à partir de 2 catégories d'éléments: - l'entité donnée (ou aussi objet donnée), - la relation. L'entité donnée est ici considérée comme un ensemble cohérent de grandeurs concernant un même sujet. Une relation exprime par contre un fait entre plusieurs sujets; il ne s'agit donc pas d'une dépendance hiérarchique. Pour éviter toute ambiguité d'interprétation, les sujets (ou objets) sont appelés entités dans la terminologie de cet ouvrage. Pour la modélisation par les données, la connaissance de l'évolution n'est pas nécessaire. Seul suffit la connaissance des états de l'entité à tout instant. Dans ce cas, une entité est modélisable par un ensemble d’attributs définissant la donnée qui la caractérise complètement, d'où l'appellation entité donnée. Par exemple, pour une voiture, les attributs suffisants peuvent être: date d'achat, propriétaire, numéro d'immatriculation. Une relation concerne des données liées entre elles pour exprimer un fait. Par exemple pour le fait: une personne est propriétaire d’une voiture, la relation de propriété lie les 2 entités personne et voiture. Un modèle approprié existe pour chacune des 2 catégories (voir 8.3.2): - le modèle de composition hiérarchique pour les entités donnée basé sur les opérateurs: composition, alternative, ensemble. Ce modèle est classique. Les auteurs utilisent des notations quelque-peu différentes: notation graphique pour JACKSON, notation syntaxique pour DEMARCO, WARD, HATLEY. Il est aussi possible d’ajouter le concept de dépendance qu’est l’héritage; un objet (et donc comme cas particulier une donnée) hérite de toutes les caractéristiques de l’objet dont il dépend. Cette dépendance limitée à la donnée se traduit par le concept de type: une donnée est définie par son type. - le modèle entités/relations de CHEN, avec aussi des variantes pour la notation. La figure 11.5 donne une représentation graphique du modèle pour chaque catégorie. La signification des symboles est expliquée dans les paragraphes suivants. M.C.S.E 195

Partie 3 - SPECIFICATION D’UN SYSTEME

modèle entités / relations

Modèle de composition hiérarchique
alternative

Di

R

Dj
Dk

composition ensemble Dn Dm

-Figure 11.5- Modélisation d'une donnée. Notons que chaque modèle permet une description par raffinement en utilisant pour chaque donnée Di l’un ou l’autre des 2 modèles: décomposition en relations, décomposition en grandeurs plus élémentaires. Ainsi ce modèle est plus général que le modèle relationnel; il est plus proche du modèle objet et d’une modélisation par des mécanismes d’abstraction tels que: l’agrégation, la composition-décomposition, la généralisation-spécialisation. 11.5.2. Modèle pour la description des entités donnée Pour caractériser ce type de données, 3 aspects essentiels sont à expliciter, à savoir: la signification, la composition, le type [WARD-85]. Le modèle de structuration est basé sur les 3 opérateurs fondamentaux: concaténation, sélection, répétition. Une entité donnée est représentée par un rectangle, en particulier lorsqu’il s’agit d’une donnée de base. Le type de la donnée est indiqué dans le rectangle et le nom de la donnée est placé à l’extérieur. Pour la description de la composition on adoptera les conventions de représentation syntaxique et graphique suivantes: = est composé de
V

+

et (TOGETHER WITH)
V1 V2 N V3

[N1 | N2 | N3 | N4] sélection d'un parmi
N1 N2 N3 N4

l{V}n

ensemble de

1 i V

m

≤n

196

M.C.S.E

Ch 11 - BASES POUR LA MODELISATION l est le nombre minimum d’éléments et n le nombre maximum d’éléments dans l'ensemble. Par défaut les bornes de l'ensemble vont de 0 à l'infini. L’exemple suivant montre le modèle graphique pour une donnée structurée et présente la notation syntaxique équivalente.
S A1 = X+Y A2 = {C} A = [A1|A2] S = B+A = B+[X+Y|{C}] X : booléen Y : couleur C : entier B : état couleur = (noir, rouge, blanc) état = (marche, arrêt) X booléen Y couleur C entier A1 A2 Etat

B

A

-Figure 11.6- Exemple de description d’une entité donnée. Ainsi pour la notation syntaxique la composition et le type d’une donnée sont définies par le symbole "=", tandis que le domaine de définition est spécifié par ":". S peut aussi s’écrire globalement: S = B:état + [X:booléen + Y:couleur | {C:entier}] Pour le modèle structurel chaque élément désigné par un lien possède un nom et est définie par un type de donnée. Une donnée particulière comme partie d’une entité est désignée par la concaténation des noms des liens du chemin aboutissant à cette donnée. Par exemple un élément i de l’ensemble {C} est désigné par: S.A2.C[i]. Lorsqu’il s’agit d’une seule grandeur, on peut confondre dans une structure le nom de la grandeur et le nom de son type. Par exemple le nom B n’est pas obligatoire, il est possible d’écrire S= Etat:(marche, arrêt) + A. La notation proposée permet de bien identifier les 3 catégories de données. Ces conventions sont classiques, avec des symboles ressemblants chez d'autres auteurs [DEMARCO-79], [JACKSON-83], [WARD-85], [HATLEY-87]. La notation de JACKSON pour les données a été donnée en 8.3.2. Les données considérées comme élémentaires car non décomposables sont des grandeurs spécifiées sur un domaine de définition. Les types habituels sont ceux connus en programmation: booléen, entier, flottant, énumération... M.C.S.E 197

Partie 3 - SPECIFICATION D’UN SYSTEME Pour améliorer la spécification des données, en particulier vis à vis de l'application, il est utile de considérer tous les renseignements qui caractérisent chaque grandeur. Ses attributs sont des propriétés qui particularisent cette grandeur dans un ensemble. Une valeur est associée à chaque attribut. La figure suivante illustre quelques exemples pour des variables.
Attributs Nom Definition
Unité Gamme Resolution Période

Signaux continus

POSITION

Position du chariot

mètre

0 - 10

0.01

10 ms

VM

Vitesse du moteur

tr/mn

0 - 6 000

1

permanent

Attributs Nom Definition
Commande du moteur Nbre de valeurs Noms des valeurs Arrêt 3 Avant Arrière Arrêt Accélération Constant Décélération 20 ms Période

Signaux discrets

CMD

ETAT

Evolution de la vitesse

4

permanent

-Figure 11.7- Exemples de définition d'une information ou d’une donnée. Ainsi, des attributs classiques pour des données dans les systèmes temps-réels sont: le type de l'information, le domaine de définition ou les limites, la précision (ou la résolution), l'unité, la période d’évolution de la grandeur (cas des signaux échantillonnés). VITESSE = ∗type: réel, limites: 0-200, précision:1, unité: KM/H* VM: VITESSE. 11.5.3. Modèle pour la description des relations Au-delà de données identifiées individuellement, la compréhension d’une entité ou d’un ensemble d’entités peut nécessiter d'exprimer des relations. Ceci est particulièrement vrai pour les applications qui nécessitent la mise en place de bases de données [WARD-85, MARTIN88]. La compréhension d’une entité peut nécessiter de décrire des relations entre entités. Par exemple, un client d’une banque possède un compte, il établit des chèques, il reçoit périodiquement un état. Ces phrases peuvent se traduire directement sous forme de relations. 198 M.C.S.E

exemple:

Ch 11 - BASES POUR LA MODELISATION Une RELATION exprime un fait entre des entités (voir aussi 8.3.2-B). La notation de la figure suivante représente une relation. Les rectangles sont des types d’entités donnée, le losange et les liens exprime la relation.
1 n

(a)

Personne

Possède

Voiture

Attributs relation

Date d’achat

(b)

Personne

1

Possède

n

Voiture

-Figure 11.8- Représentation graphique d'une relation. Le graphique de la figure 11.8 veut dire: telle Personne possède une voiture. Ce qui peut aussi s'écrire par la notation: Possède(Personne, voiture). Ainsi, sujets, objets, noms sont les entités. Le verbe exprime une relation. A noter que pour la notation, chaque rectangle représente le type d'entité. A nouveau plusieurs modèles graphiques existent, tous correspondant à une même signification. Très souvent une relation en elle-même doit en plus posséder des attributs. Ces attributs représentés par un rond sont des modificateurs de propriétés pour la relation. A l'exemple de la relation (a), on peut par exemple associer la date d’achat. Un lien de relation peut concerner plusieurs entités d'un même type, chaque entité étant identifiable. Si une personne possède plusieurs voitures, plutôt que de se contenter du nombre, chacune des voitures sera définie par: son numéro d’immatriculation, sa marque,.... La cardinalité d'une entité dans une relation (selon la notation de CHEN) est définie par un chiffre sur le lien de la relation. Pour la figure 11.8, 1 veut dire que chaque voiture a un et un seul propriétaire et n spécifie qu’une personne peut être propriétaire de plusieurs voitures. Très récentes, des méthodes de spécifications orientées objet sont basées sur une approche par les relations [BAILIN-89, KURTZ-89]. Elles ont pour objectif de favoriser par la suite une conception orientée objet. 11.5.4. Modélisation par les données En se limitant à la seule vue des données, une entité se trouve décrite par un modèle statique. Elle est alors caractérisée par l'ensemble de ses variables spécifiques, chacune possédant des valeurs qui fixent son état à tout instant. Par les sorties de l’entité l'environnement peut observer son état, et par ses entrées il peut modifier cet état en changeant des valeurs. Cette modélisation est la plus simple. Elle correspond à une description du type combinatoire ou opératoire: états dépendant uniquement des entrées à tout instant. M.C.S.E 199

Partie 3 - SPECIFICATION D’UN SYSTEME Une telle modélisation est de toute évidence la première à envisager. Elle permet de déduire les grandeurs essentielles et les variables d'états d’une entité, puis leurs relations avec les entrées et les sorties. Même si elle ne s'avère pas suffisante, elle facilite ensuite une modélisation plus complexe. Comme première illustration, le chariot de l'exemple présenté en début du chapitre en 11.1 est modélisable par une seule variable qui est son état, celle-ci pouvant prendre 3 valeurs: déplacement_droite, déplacement_gauche, repos. L’état dépend directement de la commande appliquée qui est définie par 3 valeurs possibles: avant, arrière, arrêt. Ainsi la modélisation du chariot peut se modéliser par: ETAT_CHARIOT= (cas CMD: AVANT --> Deplacement_droite; ARRIERE --> Deplacement_gauche; ARRET --> repos); Si les valeurs possibles de l’état interne et celles de l’entrée sont les mêmes on peut alors écrire: ETAT_CHARIOT: (avant, arrière, arrêt) = CMD. Comme deuxième exemple, une voiture pour le contrôle automatique de vitesse et pour la maintenance est modélisable par un état comprenant: - le nombre de kilomètres, - la vitesse courante, - à chaque plein, l'information quantité d'essence. Ceci s’écrit: ETAT_VOITURE = Nb_km: entier + Vitesse : entier + Q_essence : entier. Comme dernier exemple, un opérateur utilisant le centrifugeur décrit en 9.8.1 peut décider de la mise en marche, de l’arrêt ou d’une modification de la vitesse de consigne. Ceci se traduit par une information spécifiée par: ORDRE = [ MARCHE | ARRET | VCONSIGNE: 0..3000 tr/mn ]. 11.6. MODELISATION PAR LE COMPORTEMENT Les modèles de comportement ont pour objectif d'exprimer pour une entité les dépendances entre événements et actions. Sur le plan comportemental, une entité est dans un état correspondant à une phase ou à une étape. Un événement ou une information en entrée engendre une évolution du comportement et donc induit un changement d'état. Lorsque l’entité est modélisée par une donnée (un état comme cas particulier), un modèle du type comportemental décrit l'évolution des grandeurs de cette donnée sous l'influence d'événements en entrée. Il faut différencier les modèles à états discrets des modèles du type continu (voir 8.3.4). Les modèles continus décrivent une évolution permanente tandis que les modèles discrets limitent la description à des états particuliers qui ne changent qu’à des instants particuliers. Lorsqu'une modélisation ne peut pas se faire sur la base d'états discrets, des modèles du type continu sont à utiliser: - modèles mathématiques paramétriques: fonction de transfert, équations récurrentes, équations différentielles... - modèles non-paramétriques : représentation de signaux, gabarit en fréquence... 200 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Ces modèles servent à représenter une évolution temporelle, mais aussi toute autre type de représentation telle qu’une représentation fréquentielle par exemple. 11.6.1. Les différents modèles à états discrets Un graphe du type état/transition permet une modélisation à états discrets. A chaque transition est associée une condition spécifiant l'instant du franchissement de la transition. Une condition est définie par: - l'apparition d'un événement, - un état particulier pour des données, - la combinaison d’un événement et d’états pour des données (cas le plus général). Une condition ne peut pas être définie par plusieurs événements car l’existence de plusieurs événements n’a pas de signification. Seule serait possible une relation d’ordre entre événements tel que: ev1 puis ev2 par exemple. Par contre, une condition peut inclure toute expression logique entre les données. Par exemple la condition: MARCHE.((ETAT = repos)+(ETAT = arrêt)) fait intervenir l’événement MARCHE et le résultat d’une expression logique. Les activités étant durables, elles sont associées aux états ou étapes, tandis que les actions qui sont instantanées sont associées aux transitions. La figure 11.9 explicite la notation pour un diagramme à états finis. Une barre sur le lien entre 2 états est utilisée pour représenter la transition. Les états ou étapes sont habituellement représentés par des ronds, parfois par des rectangles pour des raisons de commodité de dessin.
V=0

Etape i

exemple
Marche T=0 V = +Vm

arrêt
butée droite V = -Vm

condition actions

Etape j

activités

Déplace gauche
T > 10 s T=0

Déplace droite

-Figure 11.9- Notation pour le modèle de comportement et exemple. Sur l’exemple: Marche, butée droite sont des événements. T > 10 s est une condition logique, T = 0 est une action ponctuelle, V = 0 est une action durable. T représente le temps courant. Tous les modèles dérivés de ce type de graphe état/transition sont utilisables. Les modèles connus diffèrent par ajoût de significations complémentaires. Citons en particulier: - le DIAGRAMME A ETATS FINIS (Finite State Machine). Ce diagramme limite la modélisation à un comportement séquentiel: une seule étape active à la fois. Lorsque le nombre d'états de l'entité à modéliser n'est pas fini, il est possible d'utiliser une version étendue en associant des variables aux étapes (Extended Finite State Machine). SDL M.C.S.E 201

Partie 3 - SPECIFICATION D’UN SYSTEME (Specification and Description Language) est un exemple de ce type de modèle particulièrement approprié pour la spécification des protocoles [ORR-88]. Lorsque le nombre d'états ou de transitions devient important, il est préférable d'utiliser soit une table de transition, soit une matrice de transition. - le GRAFCET est conforme à la signification ci-dessus, excepté pour les actions qui ne peuvent pas être associées à des franchissements de transitions. Par contre des actions impulsionnelles sont possibles en début d’étape. Par rapport au diagramme à états finis, il permet de représenter des évolutions simultanées en utilisant les divergence et convergence ET. - le STATECHART [HAREL-87-89] est une extension du diagramme à états finis pour réduire ses limitations. Le STATECHART permet essentiellement de représenter la modularité, une description hiérarchique, des évolutions simultanées, la notion d’historique. - le RESEAU de PETRI qui, avec la notion de jeton, permet de modéliser le comportement temporel de plusieurs entités à évolution parallèle lorsqu'il est nécessaire de faire apparaître des synchronisations et des exclusions mutuelles. Bien connu comme outil mathématique pour extraire des propriétés, ce modèle est plus général que les précédents mais non hiérarchique. Le modèle état/transition permet le raffinement. En effet, une étape peut se décomposer pour un niveau plus microscopique en une séquence d'étapes ou d'états. Une action peut aussi se décrire selon une séquence d'actions plus élémentaires. Le STATECHART illustre bien cette possibilité, ce qui est particulièrement favorable pour l'élaboration progressive d'une spécification et pour la lisibilité du document qui en résulte. La figure ci-après montre l'intérêt de ce modèle.

Etat initial sur reset
A21

A11 A0

Reset Arrêt
A12 A121 A22

Défaut
A122

Reset

Réinitialisation de A1 et A2 en A11 et A21

Sortie de A1 et A2 et retour en A0

A1

Activation parallèle

A2

A
-Figure 11.10- Exemple de spécification par STATECHART. 202 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Sur cette figure, on constate en particulier la possibilité de représenter: des activations parallèles (A1 et A2 à partir de A0), le raffinement d'un état (A, A1, A2, A12), des conditions pour activer et quitter un ensemble d'états (défaut, reset). Dans les paragraphes qui suivent, nous montrons 2 types de modélisation puis nous indiquons les règles de représentation préconisées pour ce modèle de comportement. 11.6.2. Modélisation par les états La modélisation d’une entité par ses états permet de décrire globalement son évolution. Il s’agit donc d’une vue externe. Par opposition à une modélisation statique, exprimer une évolution correspond à une modélisation dynamique. L'évolution n'est plus uniquement fonction des entrées mais aussi de l'historique sur celles-ci. Pour une entité qui peut se décrire par des états discrets, le comportement s'exprime par un ou plusieurs graphes état/transition. Les états se déduisent de l'analyse des données et des événements caractéristiques de l'entité après une modélisation par les données. Pour les entités à évolution continue, des modèles mathématiques ou physiques sont plus appropriés. Comme exemple, considérons à nouveau la modélisation du chariot pour le transport de matériau décrit en 11.1. Nous supposerons que le chariot possède une trappe pour le vidage de son contenu. De plus, des butées comme sécurités en P1 et P2 arrêtent l'évolution du chariot même en présence des commandes de déplacement. Pour une modélisation macroscopique, l'analyse des données/événements conduit à la liste suivante: - vitesse du chariot V: 0, -VM,+VM. - position P: P≤P2, P2<P<P1, P≥P1. - l'état de la commande déplacement: (marche droite (MD), marche gauche (MG), arrêt), d’où CMD : (MD, MG, ARRET). - les événements de commande trappe: Ouverture, Fermeture. - la position de la trappe: ouverte, fermée. En considérant les deux variables d’état vitesse et position, la modélisation nécessite de considérer 5 états distincts. Pour P2 < P < P1, 3 états sont possibles pour la vitesse. Le comportement global du chariot qui en découle est donné ci-dessous.
cmd = MD

Arrêt butée P2

P ≤ P2

cmd = ARRET Déplacement gauche cmd = MG

cmd = ARRET

Repos
cmd = MD

Déplacement droite

P ≥ P1

Arrêt butée P1

DEPLACEMENT

cmd = MG

TRAPPE Fermée

Ouverture

Ouverte
Fermeture

-Figure 11.11- Modélisation globale du chariot. M.C.S.E 203

Partie 3 - SPECIFICATION D’UN SYSTEME Pour la modélisation globale du chariot, 2 variables sont suffisantes pour représenter son évolution: état_déplacement_chariot, et état_trappe. Ces variables sont des états internes et pas obligatoirement des grandeurs observables; des capteurs sont nécessaires pour rendre ces variables disponibles en sortie. Cette modélisation montre que les 2 rôles du chariot - déplacement, vidage - sont indépendants, ce qui conduit à l’utilisation de 2 diagrammes à états finis indépendants pour le comportement. Une modélisation par les états peut aboutir à des activités (ou rôles ou fonctions ou sous-ensembles) non-indépendantes. Dans ce cas, les graphes d'états sont couplés pour des variables d'état ou des événements internes. La démarche à suivre pour obtenir ce type de modélisation consiste à rechercher tous les états successifs de l'entité, puis les conditions de transition et les actions. Cette technique de modélisation est particulièrement efficace pour décrire des entités physiques caractérisables par un vecteur d'état interne. Elle s’avère extrêmement importante pour la spécification des systèmes de contrôle/commande temps-réel et les systèmes électroniques. Cette démarche est celle suivie par les automaticiens qui commencent tout d'abord par modéliser le procédé physique avant de déduire sa commande. 11.6.3. Modélisation stimuli/réponse Tandis que le modèle précédent est basé sur la notion d'état, on se place ici dans le cas d'une entité riche en stimuli en entrée et assurant pour chacun plusieurs actions. Plutôt que de chercher tous les états de l'entité, il est plus facile de modéliser l'enchaînement des actions entreprises sur l'apparition de chaque événement. Ceci revient à obtenir une modélisation globale des sorties pour chaque entrée d'événements ou d'informations. Une telle modélisation est particulièrement appropriée pour les systèmes dits réactifs, c'està-dire ceux qui produisent des événements à partir de stimuli. Ces entités possèdent des entrées et des sorties plutôt du type événements et informations. C'est le cas en particulier pour des entités communicantes: utilisateurs et interfaces homme-machine, systèmes de communication, etc. Comme exemple, considérons le cas de 2 entités, l’une d’émission, l’autre de réception de messages. Pour chaque message émis, l'entité de réception doit transmettre un acquittement positif si le message est correct (ACK), négatif sinon (NACK). Pour obtenir une fiabilité du transfert en cas de perte du message ou de l'acquittement, l’émetteur renvoit le message tant qu’il n’a pas reçu un acquittement indiquant un transfert correct (ACK). Le protocole pour le dialogue et la modélisation de l’émetteur et du récepteur sont décrits sur la figure 11.12. Le modèle est basé sur le diagramme à états finis. Les symboles et représentent l'arrivée et la production d'une information. Les états représentent des phases d'attente, ce qui correspond à l’attente d’une initiative de la part du correspondant. Les actions représentent les réactions de l'entité. La notation utilisée est pratique pour la spécification de protocoles entre entités communicantes (voir les diverses notations possibles en 8.3.4-G). 204 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION

Emetteur
Envoi = Mess i Emetteur

Récepteur

Envoi de Mess i
Recepteur

Mess i

Rep = [ Ack i | Nack i ]

Tack (temps d’attente)

Ack i ou Nack i

Perte Mess i ou Ack i

Transfert correct si ACK

Mess i Exploitation de Mess i si message correct

Mess i si Tack ou Nack i

Emetteur

Récepteur

Repos

Attente demande

Nack i Mess i message? correct non correct

Désir transfert

Mess i Ack i Tack Attente ACK Nack i Mess i fin exploitation Mess i Exploitation Mess i

Ack i

-Figure 11.12- Modélisation d'un émetteur et d'un récepteur de messages. Cette modélisation est intéressante car elle permet d'ajouter des caractéristiques complémentaires au comportement, telles que l’indication de temps de réponse ou de contraintes de temps. De telles spécifications expriment des temps minimum et maximum entre l'apparition d'un événement en entrée et en réaction la génération des sorties. La démarche de spécification pour ce modèle consiste à exprimer toutes les actions à entreprendre sur apparition de chaque événement, puis à décrire le séquencement. 11.6.4. Règles préconisées pour le modèle de comportement à états discrets Tous les modèles à états discrets sont en principe utilisables. Ce paragraphe résume la notation préconisée à partir du diagramme à états finis. Cette notation a pour objectif de clarifier les catégories des éléments utilisés de manière à favoriser la lecture et la M.C.S.E 205

Partie 3 - SPECIFICATION D’UN SYSTEME compréhension d'une spécification faite par un modèle graphique. L’intérêt de cette notation est de permettre d’exprimer toutes les spécifications avec un seul modèle plutôt que d’utiliser un modèle spécifique pour chaque catégorie de problème. Cette notation est conseillée mais pas obligatoire. Un spécifieur peut devoir se plier à des contraintes de notation imposées par le donneur d’ordre. Ne pas oublier non plus qu’une spécification doit être vérifiée et donc doit être compréhensible par le demandeur. Si la notation préconisée n’est pas connue, il suffit de l’expliciter pour rendre les documents compréhensibles. Les quelques règles essentielles sont les suivantes: - Tous les éléments utilisés (états, événements, données, actions) possèdent un nom significatif pour l’objet modélisé. - Les états sont représentés par des ronds (ou des rectangles), chacun désigné par un nom significatif pour l'entité à modéliser. L'état de départ est identifié par un contour double. - Les changements possibles entre états sont représentés par des liens orientés. - Les transitions sont représentées par une barre sur le lien orienté entre 2 états. - La condition de changement d'état est exprimé à côté de la transition. - Les actions ponctuelles sont associées à des transitions. - La notation pour les transitions est la suivante: CONDITION ou CONDITION/ACTIONS ACTIONS - Les actions durables sont associées aux états (par exemple Vcmd = +VM). La génération d'événement ou d'information durant un état est impossible car l’instant n’est pas défini. Les éléments en entrée, utilisables pour exprimer une condition, sont de 3 catégories: évènement, information, données. Rappelons que l'information a la signification d'un évènement porteur d'une donnée. Dans une condition, au maximum un événement est possible, de même événement et information sont exclusifs. Pour différencier les 2 types de conditions - événement, information - on utilisera: Ev pour l'événement (Ev est son nom)

Mess

pour une information (Mess est son nom)

Les valeurs de données ou d’états sont utilisables comme condition ou comme complément à un événement. On exprime alors l'expression logique qui correspond à la condition vraie, par exemple (T > 10H).(Jour = dimanche). Pour les actions, il est aussi utile de différencier les 3 catégories: événement, information, donnée. Pour l'événement seul le nom est utilisé. - Le symbole est utilisé pour indiquer qu'il s'agit d'une information,

- le symbole ":=" ou "=" exprime la modification de la valeur d'une donnée. 206 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Pour les informations générés, le destinataire peut aussi être indiqué pour lever les d'ambiguïtés possibles (M -> entité). Des actions et des états différents peuvent découler du contenu d'une information. Pour représenter simplement les alternatives, on utilisera un rectangle allongé avec en interne la question et en externe différentes sorties correspondant aux cas possibles. La figure ci-dessous résume l’ensemble de la notation conseillée.
entité 1 entité 2
attente réception

Repos

MARCHE T := 0

M

entité 2

M

reçu

attente limitée T > 10 s

M? S = NON_PRET OK NOK REP= erreur

reçu

REP = correct

-Figure 11.13- Notation conseillée pour une modélisation à états discrets. Lorsque la modélisation nécessite de procéder par raffinements successifs, le diagramme à états finis peut apparaitre inapproprié. Il est alors conseillé d’utiliser de préférence le statechart (voir en 11.6.1). 11.7. MODELISATION PAR LES ACTIVITES La modélisation par les activités a pour objectif de définir les relations entre les données ou les événements/informations et les activités de l'entité concernée. Une activité désigne une transformation de données ou d'informations en entrée en d'autres données ou informations en sortie. La modélisation est basée sur l'utilisation d'un graphe des dépendances. Les 2 modèles les plus communément cités pour ce type de modélisation sont: - le modèle SADT qui permet de modéliser les relations données/activités selon 2 vues duales: l'actigramme orienté vers la spécification des fonctions ou activités, le datagramme orienté vers la spécification des données et informations [IGL-83, ROSS85] (voir en 7.2). - le Diagramme Flot de Données (DFD) préconisé par DEMARCO [DEMARCO-79] (voir en 7.3). M.C.S.E 207

Partie 3 - SPECIFICATION D’UN SYSTEME Ces 2 modèles représentent le flot des données et des informations, mais n'exprime pas le comportement de l'ensemble. En explicitant les chemins possibles pour les données, de tels diagrammes décrivent qui transforme ou produit des données et des informations mais sans précision de l'instant. Ces modèles sont donc plutôt structurels. Une activité peut à nouveau se décomposer selon un diagramme flot de données; il est donc hiérarchique. Au stade final de la décomposition, une activité ne peut être décrite que par sa spécification qui caractérise les transformations des entrées. Il s'agit alors d'une modélisation du comportement. Une différence essentielle entre les 2 modèles SADT et DFD est que le diagramme SADT ne fait pas de différence entre données et informations conformément à la terminologie utilisée dans ce chapitre. Pour un DFD, une donnée est représentée par un symbole Mémorisation (file ou data store), tandis qu'une information sert comme label sur un lien direct entre 2 activités. MCSE préconise d'utiliser de préférence les diagrammes flot de données pour une spécification par les activités. Déjà présenté dans la partie 2 en 7.3, nous rappelons succintement la notation graphique à utiliser pour un diagramme flots de données et sa signification [WARD-85].
a
A1

E1

b

A2

c

S1

raffinement
E2

f
A3

e d V b c
A21 A23

Liens multiples : Z = X + Y Convention
Z X Y

e
Interprétation

A22

Deux sous-ensembles de Z sont utilisés par les deux activités désignées. Z est complètement utilisé par les deux activités désignées.
Z

Z

X Y

Z est la composition des deux parties X et Yprovenant d’activités différentes. Z est produit par l’une des activités sources.

Z

-Figure 11.14- Exemple de diagramme flot de données. Pour l’exemple ci-dessus: 208 E1, E2 sont des sources et S1 un récepteur, A1, A2, A3 sont les activités, a, b, c, f sont des informations, d, e, sont des données mémorisées et lues appartenant à V, A2 est raffinée par un diagramme flot de données. M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Ce diagramme exprime que c résulte d'une transformation de b après exploitation de la donnée e appartenant à V. b résulte d'une transformation de a par A1 ou bien d’une transformation de f par A3 qui produit aussi la donnée d pour V. Rien n'est dit sur les instants d'apparition de b et de c à partir de a, de même pour la mémorisation de d et l'utilisation de e. La figure 11.14 indique aussi la signification des conventions pour des liens multiples convergents ou divergents. Cette notation ne concerne que des activités synchrones à des informations, c'est-à-dire que A1 assure la transformation de chaque information a au moment de son apparition. Approprié pour la modélisation des systèmes d'information, elle n'est pas suffisante pour la modélisation des systèmes physiques. Pour représenter la transformation de données à évolution permanente, nous adoptons la notation de la double flèche WARD, permettant ainsi de caractériser les entrées et sorties d'activités pour des données permanentes, comme l’indique la figure ci-dessous.
Commande radiateur

Température

Régulation température

1/4 h

Enregistrement température

Température mesurée Historique

-Figure 11.15- Notation de WARD pour des données à évolution permanente. L'interprétation de ce diagramme est la suivante: - l'activité Régulation température évalue en permanence la commande radiateur à partir de la température, - l'activité Enregistrement température s'effectue sur chaque événement 1/4h pour mettre à jour la donnée historique. Les caractéristiques de ce modèle sont les suivantes: - il s'agit d'un modèle graphique simple à comprendre, ce qui est très favorable pour une spécification, - il est hiérarchique, aussi il favorise l'analyse progressive et la structuration, - il décrit le point de vue des données et des informations et détaille l'activité globale d'une entité, - il n'est toutefois pas suffisant pour connaître le déroulement temporel global. Pour cela, il faut y ajouter la spécification temporelle de chaque activité. Pour remédier à ce dernier aspect, WARD et MELLOR ainsi que HATLEY ont complété le diagramme flots de données par une spécification du contrôle. M.C.S.E 209

Partie 3 - SPECIFICATION D’UN SYSTEME Les instants d'évolution de chaque activité sont spécifiés, non pas par la description de l'activité elle-même, mais par une spécification du contrôle global de toutes les activités du diagramme flot de données. Le contrôle global est alors spécifié par un modèle tel que le diagramme à états finis. Le modèle correspondant à cette approche pour la spécification d'une entité ou d'un système est le suivant [HATLEY-87].

Partie opérative

E
Données

(Données internes et activités)

S
Données

evcmd

evobs

eve

evs Partie contrôle

Evénements

Evénements

-Figure 11.16- Modèle générique pour la spécification d'un système. La partie opérative qui concerne les données est décrite par un diagramme flots de données, tandis que la partie contrôle définissant l'évolution temporelle des activités est décrite par un ou plusieurs diagrammes à états finis. La figure suivante montre un exemple de modélisation selon la notation de HATLEY.
Diagramme Flot de Données DFA DFC 2 DFF 3 DFB DFG Action DFH DFE

Entrées

1

Sorties

Diagramme flot de Contrôle CFA evobs ev
e

Comportement pour le contrôle CFB
CFE = 0

1 CFC CFE 3

2 ev CFG ev
cmd s

Etat 1
CFC Activation processus 1 CFC = 0 CFG = On

Etat 2
CFE Activation processus 2

Etat 3 CFF

-Figure 11.17- Exemple de spécification DFD+contrôle. 210 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Le comportement pour la partie contrôle spécifie les états actifs ou inactifs des activités des diagrammes flot de données et les événements produits, ceci à partir des événements en entrée et de ceux résultant du DFD. L’activité de contrôle du DFD est représentée par une barre qui se trouve spécifiée par un automate à états finis ou une table de transition. La modélisation par les activités concerne le cas le plus général; une entité est caractérisée par une collection de données et d'événements et une collection d'activités. Lorsque l’approche flot de données est souhaitable, ce qui peut être le cas pour des entités assez complexes, une telle modélisation données + contrôle est fortement conseillée. Comptetenu des 3 vues pour une modélisation, une description par les activités nécessite de décrire et donc de trouver dans l’ordre 4 types de renseignements: - l'ensemble des données/informations (structure), - les relations données/événements et activités (diagramme flots de données), - le comportement de chaque activité incluant la définition des entrées/sorties. - l’évolution des activités par l’expression du contrôle. Cette stratégie de modélisation pour un système est celle préconisée par WARD et MELLOR, ainsi que par HATLEY. 11.8. GUIDE POUR LA MODELISATION La complexité de la modélisation selon les 3 vues: - données / informations, activités, comportement - est fonction de la nature de l'entité à décrire et du niveau de détail souhaité. Bien entendu, la méthode pour la modélisation en découle. A partir des 3 types de modélisation décrits dans les paragraphes précédents, il est aisé d'expliquer la démarche à suivre pour toute entité. Elle est présentée comme la trajectoire à suivre dans l'espace de modélisation à 3 dimensions.
Comportement

2

3

Activités

1 Données informations

Raffinement des activités

-Figure 11.18- Démarches pour la modélisation. M.C.S.E 211

Partie 3 - SPECIFICATION D’UN SYSTEME La modélisation doit commencer par une analyse conduisant à une description des données, événements et informations de l'entité. L'approche se fait à partir des entrées et des sorties et en exprimant les dépendances. Cette modélisation peut suffire pour le problème à traiter (cas1); il s’agit alors d’une modélisation statique. Si ce n'est pas suffisant, il faut poursuivre la modélisation lorsque l'aspect dynamique s'avère essentiel. Si l'évolution de l'entité peut se caractériser globalement, donc selon une vue externe qui exprime les dépendances entre sorties et entrées, il faut utiliser une modélisation par les états ou du type stimuli/réponse. La modélisation est alors complète (cas 2). Lorsqu'une entité est complexe, l'approche globale précédente n'est pas facile. La démarche (cas 3) consiste alors à faire une modélisation progressive par les activités en utilisant la technique de raffinement. Au stade final, chaque activité est décrite par son comportement. Le comportement pour le système global ou pour les sous-ensembles est décrit par un diagramme flot de contrôle. Beaucoup de méthodologies adoptent cette démarche de spécification (voir chapitre 7). Dans certains cas de problèmes, même si l’approche cas 2 est possible, il n'est pas souhaitable de modéliser individuellement chaque entité car une telle modélisation n'apporte pas une description suffisante pour l'application. L'approche par les activités est alors la plus appropriée. Considérons comme exemple le cas d'une application de gestion du chauffage de salles dans un établissement d'enseignement. A partir des emplois du temps et de la configuration des salles disponibles, il s'agit d'assurer la conduite du chauffage. En appliquant la démarche par les entités, on trouve les différents utilisateurs que sont: le service scolarité chargé des emplois du temps, le service général responsable de la conduite du bâtiment et des salles. L'analyse de chaque catégorie d'entité ne conduit pas à une vue suffisante pour le problème. Aussi, plutôt que de suivre cette démarche, recherchons le diagramme flot de données global pour cette application. Un tel diagramme est donné ci-dessous.
emploi du
Scolarité Alloc des salles

salles allouées

temps

Planification chauffage salles

Rôle du système

Chauffage

Salles disponibles

Planning chauffage

Historique

Config salles

Demande rapport

Bilan occupation des salles

Visu historique

Etat salle Demande historique
Service général

Rapport historique Rapport bilan
Service général

-Figure 11.19- Diagramme flot de données pour la gestion du chauffage des salles. 212 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Cette approche globale permet de mieux cerner les diverses activités, les événements, les informations et données de l'application, sans devoir a priori les affecter à telle ou telle entité. Elle s'avère aussi utile pour décider d'une répartition des tâches et en particulier, il est facile de délimiter le rôle d’un système informatique (par exemple, la partie entourée en pointillé). Comme remarque justifiant le guide proposé, il est à noter que pour des entités simples une modélisation par les activités a plutôt tendance à conduire à une décomposition trop élémentaire car le spécifieur guidé dans son analyse par le diagramme flot de données ne dispose pas de critère clair d'arrêt de sa décomposition. Ceci se constate sur les exemples traités dans [WARD-85, HATLEY-87]. En particulier, le système de régulation de vitesse pour véhicule, spécifié par un diagramme flots de données conduit à une complexité qui n'existe pas lorsque la modélisation est faite selon une approche par les états. La spécification pour cet exemple respectant le point de vue décrit dans ce chapitre a été donnée dans la partie 1 au chapitre 6. 11.9. RESUME Ce chapitre est essentiel pour la compréhension de la démarche préconisée pour l'obtention des spécifications; il justifie les bases de la modélisation qui seront exploitées dans le chapitre suivant. Rappelons les idées essentielles: - La spécification du système commence par la délimitation de son environnement et la caractérisation des entités qui composent cet environnement. - Les entités sont caractérisables par un modèle explicite, tandis que le système ne peut être décrit que selon une vue externe. Ainsi, la modélisation du système sera basée sur le comportement souhaité de son environnement. - Une entité se décrit par un ensemble d'éléments caractéristiques - événements, données, actions ou activités - et par des relations. - La modélisation est basée sur une description selon 3 vues: l'espace des données, l'espace des états, l'espace des activités. - Selon la nature de la caractérisation souhaitée, le spécifieur pourra utiliser: • la modélisation par les données pour une description statique, • la modélisation données/événements et états pour une description dynamique globale, • la modélisation données/événements et activités dans le cas le plus général lorsque les modélisations précédentes ne s'avèrent pas suffisantes.

M.C.S.E

213

Chapitre 12

DEMARCHE POUR LA SPECIFICATION

Pour l'étape de spécification, l'objectif est de décrire les spécifications complètes du système sous la forme d'un document structuré, compréhensible, vérifiable. Si l'obtention d'un tel document nécessite un investissement en temps non négligeable, le gain pour les phases ultérieures est de toute évidence très appréciable et ceci tout particulièrement pour la phase de mise en fonctionnement et de maintenance, car les erreurs seront alors faibles. Les chapitres précédents ont servi à expliciter les bases de la modélisation d'un système. Le document de spécification, essentiel en aval pour la conception et en amont pour vérifier la bonne compréhension du problème posé, doit respecter un modèle de présentation. Le rôle du modèle de spécification est de décrire tous les constituants nécessaires, la signification et l'interprétation de chacun d'eux, ceci pour disposer d'une spécification complète. Le respect d'un ensemble de règles confère à la spécification des propriétés et qualités qui favorisent la vérification de celle-ci et son exploitation pour la conception. Ce dernier chapitre détaille le contenu d'une spécification et la procédure à suivre pour construire le document de spécification. Séquences d'analyses et de décisions, la démarche proposée est basée tout d'abord sur une compréhension du "monde" dans lequel doit intervenir le système, puis une description progressive du rôle joué par le système pour l'application. Chaque phase de la démarche conduit à élaborer une composante de la spécification.

M.C.S.E

215

Partie 3 - SPECIFICATION D’UN SYSTEME La démarche est illustrée par les 2 exemples décrits à la fin du chapitre 9. Pour favoriser la lecture et la compréhension de la méthode, le premier exemple est traité au fur et à mesure de la présentation des phases, tandis que le deuxième exemple est traité complètement en fin de chapitre. 12.1. LES CONSTITUANTS D’UNE SPECIFICATION Rappelons tout d’abord que la conception sera conduite selon 3 aspects: - l'approche FONCTIONNELLE, pour définir les fonctions internes du système et les relations entre ces fonctions, - l'approche OPERATOIRE, pour exprimer le déroulement temporel des fonctions et des actions, - l'approche TECHNOLOGIQUE pour définir une solution matérielle et l'implantation sur celle-ci de la solution fonctionnelle, qui tiennent compte de toutes les contraintes technologiques. Il est donc judicieux pour chaque approche, de n'avoir à utiliser qu'un sous-ensemble des spécifications à exploiter, d'où l'intérêt d'un classement en 3 catégories exprimant les aspects fonctionnel, opératoire et technologique. Une application est composée du système à concevoir et de son environnement. Ainsi une spécification doit comprendre: - une modélisation de l'environnement du système, - une définition des entrées-sorties, - le comportement souhaité pour le système, - la description de son utilisation. La modélisation de l'environnement concerne chacune des entités de celui-ci ainsi que les relations entre elles. Structuré en 2 parties, une spécification comprend: pour la modélisation de l'environnement: - la description de toutes les entités, incluant pour chacune: • la définition des données et événements, • la description du comportement global, ou si nécessaire, le diagramme flot de données et le comportement de toutes les activités. - la description fonctionnelle de l'environnement qui représente les relations existant entre toutes les entités sans le système. pour la description du système, - la description des entrées/sorties, - la spécification fonctionnelle incluant: • la liste des fonctions du système, • la spécification de ces fonctions. - les spécifications opératoires, - les spécifications technologiques, - un document préliminaire pour l'utilisation et l'installation. 216 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Les ensembles d'informations nécessaires sont ainsi représentés ci-dessous.
Environnement Système

Description fonctionnelle environnement Entrées / Sorties Spécification système Spécifications fonctionnelles entité j Fonction k Spécifications opératoires Spécifications technologiques

Données et événements

Comportement

Comportement entité j

Utilisation

installation

-Figure 12.1- Composition d'une spécification. La présentation hiérarchique suggère déjà la démarche de spécification présentée dans le paragraphe suivant: - démarche ascendante à partir des entités pour l'analyse de l'existant, - démarche descendante à partir des entrées/sorties et des fonctionnalités pour le système. Lorsqu’il s’agit d’un système complexe, la spécification est alors conséquente; il n’est pas judicieux de conserver une telle structuration. La solution consiste dans ce cas à décomposer tout d’abord le problème en sous-ensembles fonctionnels, puis à spécifier chacune des parties. La spécification du système est alors une collection de spécifications de sous-ensembles. Cette structure facilite grandement la recherche des informations pour la conception et la réalisation. 12.2. PRESENTATION DE LA DEMARCHE Cette première étape de la méthodologie, la plus difficile à notre avis, conduit à élaborer un document complet des spécifications. Comme données d'entrée, le spécifieur dispose du cahier des charges lorsque celui-ci existe. Il dispose aussi, seulement sur sa demande, des informations en rapport avec le problème connu du client (utilisateurs...). Aussi doit-il conduire son analyse avec efficacité. La démarche décrite dans ce chapitre lui sert de guide pour interroger, analyser, puis synthétiser et vérifier. Basée sur la structure du document de spécification à obtenir, la figure 12.2 résume l'enchainement des phases de l'étape. Le travail se décompose en 2 grandes parties : - modélisation de l'environnement, - spécification du système. M.C.S.E 217

Partie 3 - SPECIFICATION D’UN SYSTEME

Analyse environnement Comportement des entités

Modélisation de l’environnement

C A H I E R D E S C H A R G E S

Description fonctionnelle Délimitation des entrées/sorties

Spécifications fonctionnelles
Fonctions Comportement entités + système

Elaboration des spécifications

Spécifications opératoires Spécifications technologiques
SPECIFICATIONS

-Figure 12.2- Enchainement des phases pour la spécification.

Pour la première partie, la phase initiale concerne l'analyse de l'environnement pour identifier les entités utiles pour le problème. La phase suivante conduit à une modélisation des entités juste suffisante pour le problème. Cette première partie se conclut par une description fonctionnelle de l'environnement. Pour la deuxième partie, elle débute par une délimitation des entrées et sorties. Suit une phase essentielle qui conduit à expliciter les spécifications fonctionnelles. Les spécifications opératoires puis technologiques sont construites progressivement ainsi que les documents complémentaires d'utilisation et d'installation. Pour chaque phase de modélisation, le spécifieur procède en 3 temps: - ANALYSE: l'objectif est de faire apparaître par des discussions, par la lecture de documents, par l'observation directe, toutes les informations utiles: données, événements, actions. - SYNTHESE: il s'agit de regrouper toutes les informations utiles sous la forme d'une modélisation en tant que description abstraite, - VERIFICATION: nécessaire, cette tâche assure la validité du travail préalable. Les oublis et erreurs sont alors immédiatement corrigés. Il est essentiel de constater que le point de départ qui consiste à trouver les entités utiles, est très important car c'est sur cette première base que va reposer ensuite toute la conception puis la réalisation. L'effort en temps pour ce premier travail est nécessaire. Ce n'est pas du temps perdu, contrairement à la première impression que l'on serait tenté d'avoir. Une spécification menée trop superficiellement va induire des temps supplémentaires qui vont se diluer dans les 218 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION phases suivantes avec un effet d'amplification, sans pouvoir clairement prouver la corrélation avec la médiocrité des spécifications. Les paragraphes suivants détaillent les caractéristiques de chaque constituant ainsi que la démarche pour élaborer sa modélisation. Ayons en permanence à l'esprit que le travail de spécification ne peut se faire que par une collaboration étroite entre tous les acteurs côté client et le ou les spécifieurs. 12.3. ANALYSE ET MODELISATION DE L’ENVIRONNEMENT Cette première partie de la spécification a pour objectif de décrire l'existant. Savoir décrire un existant est une première qualité que doit avoir tout concepteur. Le modèle de l'environnement est une ABSTRACTION, c'est-à-dire une description partielle plus ou moins macroscopique des parties utiles pour le problème. L'environnement est un univers temporel dans lequel évoluent une ou plusieurs entités, liées ou pas entre elles. Il faut commencer par délimiter et comprendre cet existant. Le premier objectif est donc de trouver dans l'environnement les éléments qui ont une influence directe avec le système. Le second objectif est de caractériser les détails nécessaires et suffisants pour chaque entité. Le premier travail consiste donc à faire le bilan des éléments caractéristiques de l'environnement avec comme finalité la détermination des entités utiles. Si l'environnement est complexe, l'analyse peut se conclure par une décomposition hiérarchique. Bien entendu, l'analyse ne peut se faire que si l'objectif de l'application est bien connu. La démarche à suivre a été développée dans le chapitre précédent en 11.8 sous la forme d’un guide pour la modélisation. Les informations nécessaires proviennent du demandeur. Fort probablement, le client a beaucoup de renseignements à communiquer sur son besoin. Mais ceux-ci sont exprimer comme des suites non corrélées. C'est au spécifieur de guider la discussion de manière à avancer efficacement dans son analyse. Une visite sur le site est sûrement très appréciable pour avoir une vue globale du problème ainsi qu'une représentation physique de l'installation tel que le schéma d'organisation d'un atelier de production par exemple. 12.3.1. Modélisation de chaque entité En s'intéressant plus particulièrement à une entité, le spécifieur doit produire une modélisation juste suffisante pour le problème à résoudre. Le niveau de description utile dépend de l'objectif du système. Aussi, c'est de la compétence du spécifieur que de savoir apprécier à partir du cahier des charges, le degré de raffinement du modèle. Basée sur les concepts décrits dans le chapitre précédent, la démarche consiste à faire l'inventaire de tous les éléments caractéristiques de l'entité, puis à les classer pour déduire les relations structurelles et temporelles. L'analyse conduit à classer les éléments selon les catégories suivantes: - données/événements: • données, • variables d'état, • événements, • informations. M.C.S.E 219

Partie 3 - SPECIFICATION D’UN SYSTEME - activités: • actions, • activités. - relations: • les relations entre données/événements et actions/activités, • les entrées et sorties avec son environnement. La compréhension de l'entité en vue de sa modélisation peut passer par la présentation des informations sous forme de tableaux, tels que par exemple ceux indiqués ci-après. Le premier décrit les caractéristiques des grandeurs de chaque entité, tandis que le second décrit les relations entre les entités par les actions.
Entité
CHARIOT

Entrée
CMD

Variable interne

Sortie

Définition
(MD, MG, AR)

spécification
Commande déplacement Position absolue du chariot Commande tapis

Position

P2 ... P1 Marche_tapis ou Marche_tapis

TAPIS_CHARGEUR

CT

Source

Entrée

Action

Sortie

Destinataire

Opérateur

Cycle

Réaliser un cycle de transfert

CMD CT

Chariot Tapis chargeur

Arrêt

Arrêt d’urgence

-Figure 12.3- Exemples de tables pour l'aide à la modélisation. La modélisation selon les 3 vues: - données, activités, comportement - est alors possible. La technique à suivre dépend de la nature de l'entité: modèle statique pour les données/ événements, modèle comportemental global pour une entité assurant une ou peu de fonctions, modèle stimuli-réponse pour une entité communicante ou réactive, modèle flot de données pour une entité orientée transformation d'informations (voir les modèles utilisables dans le chapitre précédent). La procédure à suivre consiste à s'intéresser d'abord à une modélisation des données/ événements. Si celle-ci s'avère suffisante, car conduisant à définir toutes les entrées et les sorties pour le système, un modélisation plus complexe n'est pas nécessaire. Sinon, une modélisation globale est à envisager de manière à décrire le comportement dynamique de l'entité. La modélisation par les activités n'est à faire que dans le cas d'entités relativement 220 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION complexes (plusieurs activités simultanées), ou lorsque la décomposition de l'environnement en entités ne s'avère pas judicieuse. Une approche par les relations sous la forme d’un schéma relationnel peut faciliter le travail de modélisation comme suggéré dans [WARD-85, BAILIN89, KURTZ-89]. Comme exemple d'illustration de la démarche, prenons le cas d'un système pour la gestion des ouvrages d'une bibliothèque. Il s'agit d'un système d'information, et non d'un système électronique, mais la démarche est similaire. Les entités pour ce système sont au moins les livres. Tout livre est une instance du type livre. Chaque livre (existant pour la bibliothèque bien sûr) est caractérisé par : - son titre, - son auteur, - son numéro, - son état. Les états possibles du livre sont: présent, réservé, emprunté, perdu. Les événements caractéristiques pour chaque livre sont: achat, réservation, emprunt, retour, perte. Chaque événement conduit à un changement d'état. Cette modélisation statique est a priori suffisante. Ceci s’écrit (voir la notation syntaxique en 11.5.2): LIVRES = {LIVRE} LIVRE = TITRE+AUTEUR+NUMERO+ETAT ETAT: (présent, réservé, emprunté, perdu) Cette modélisation peut se compléter par une description de l'évolution de l'état du livre en fonction des événements telle que celle indiquée ci-après.
Retour

Emprunt Inexistant Achat Présent Emprunté perte Perdu

Réservation

Emprunt

Réservé

-Figure 12.4- Modélisation des états d'un livre. Pour le système d'information chargé de gérer les livres, les entités de l'environnement que sont les livres ne sont pas liées au système (pas d'observation directe de l'état de chaque livre). En l'absence de cette observation, c'est au gestionnaire de la bibliothèque de mettre à jour dans le système l'état de chaque livre à partir des événements qui s'y rapportent. Pour cela, le système doit posséder en interne le modèle d'évolution ci-dessus et l'état courant pour chacun des livres. M.C.S.E 221

Partie 3 - SPECIFICATION D’UN SYSTEME Ce type de problème diffère de ceux des systèmes électroniques évoqués dans ce document car les entités ne sont pas directement observables, mais la démarche de spécification reste identique. La modélisation de l’utilisateur comme entité est particulière. En effet son comportement n’est pas prédictible; il est générateur d’événements et d’informations selon son bon vouloir. Face à un clavier ou un pupitre rien ne peut l’empêcher d’agir à sa guise. Ainsi modéliser l’utilisateur seul selon un modèle dynamique est inutile. La modélisation par les données/ informations est alors suffisante en exprimant complètement les actions de l’utilisateur et les observations dont il dispose. 12.3.2. Description fonctionnelle de l’environnement La synthèse fonctionnelle a pour but de faire apparaître les relations entre les entités de l'environnement. Elle n'a d'utilité que pour des entités couplées. Le premier intérêt de cette phase est de présenter une vue graphique synthétique de tout l'environnement. Un deuxième intérêt possible est de pouvoir regrouper des entités de manière à simplifier pour la suite la détermination des spécifications fonctionnelles. Pour illustrer ce point, considérons l'application suivante qui a pour objectif de produire du ciment. Une toupie de ciment résulte: d’une quantité d’agrégats (PA1 + PA2 +PA3), d’une quantité de ciment (PC1 ou PC2 selon le choix) d’une quantité d’eau QE calculée à partir des valeurs précédentes. La description de l’installation ci-dessous est suffisamment explicite pour que le lecteur puisse comprendre comment se réalise le béton.
Silos agrégats Réservoir d’eau Silos ciments

VA1

VA2

VA3

VC1

VC2

Balance A
VBA VBC

Balance C

Tapis A

VE

Tapis C

TPA

TPC

Malaxeur

MLX

VD

Camion

-Figure 12.5- Installation pour une centrale à béton. 222 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Cette application inclut 12 entités. Chaque entité se modélise très simplement par une relation: entrées —> états —> sorties, une fois identifiées les entrées, sorties et variables internes. La description fonctionnelle de l'environnement qui en résulte fait apparaître un couplage entre toutes les entités sauf avec l'utilisateur. Elle est représentée par la figure ciaprès.
EA1 EA2 EA3

Matériaux

EC1

EC2

Apport ciment

VA1 VA2 VA3 E N T R E E S
A1 A2 A3 DA1 DA2 DA3

VC1 NA[1..3] Silos agrégats NC[1..2] Silos ciments VC2 Eeau
C1 C2

Niveaux

DC1 PA VBC Balance C DBC TPC Tapis C

DC2 PC

VBA

Balance A DBA

VE

Réserve d’eau

QE

O B S E R V A T I O N S

TPA

Tapis A

Agrégats
DTA DE DTC

Ciments

MLX

Cuve de malaxage
VD

Dciment

-Figure 12.6- Description fonctionnelle de l’environnement. Compte-tenu de cette topologie et de manière à simplifier la recherche de la spécification fonctionnelle, il est préférable de considérer seulement 5 entités. Les ensembles: silos agrégats, balance et tapis forment une seule entité fonctionnelle produisant les agrégats, de même pour les silos ciment. Comme autre exemple, la figure 12.7 concerne la description de zones pour le chauffage et montre la notation utilisée pour décrire une collection d'entités et de relations d'un même type (différence faite entre type et instance). Lorsqu’il s’agit d’entités abstraites, la description de l’environnement peut aussi se faire par un schéma relationnel en utilisant une modélisation par les relations. 12.4. DELIMITATION DES ENTREES ET SORTIES DU SYSTEME Cette phase conduit à délimiter le système en décrivant ses relations avec l'environnement. Les entrées du système sont les informations des entités accessibles par leurs sorties. Les sorties du système servent à agir sur les entités par leurs entrées. Ainsi, la nature des entrées et des sorties du système est déjà caractérisée dans la spécification des entités. M.C.S.E 223

Partie 3 - SPECIFICATION D’UN SYSTEME

CLIMAT

Textérieur

Qchaleur[1..n]
ZONE

Tint[1..n]

Salles[1..n]

-Figure 12.7- Description de l’environnement pour le chauffage des salles. Chaque variable est définie par: - son nom, - son utilisation: entrée, sortie, - sa nature: événement, informations, donnée, état, - sa définition fonctionnelle: structure, domaine de définition, fréquence..., - ses caractéristiques technologiques, si nécessaire. La délimitation des entrées-sorties se traduit par l’expression des liens entre les entités et le système. Les liens à une flèche désigne un événement ou une information tandis que les liens à double flèche concerne les données et états qui sont permanents. Cette phase n'aboutit pas obligatoirement à la connaissance de toutes les entrées et sorties indispensables. En effet, la spécification fonctionnelle peut conduire à la nécessité d'informations supplémentaires non-observées. Dans de tels cas, des capteurs seront à ajouter pour l'observation. Par retour-arrière, la délimitation sera alors modifiée. 12.5. EXEMPLE : CONTROLE EN VITESSE D’UN CENTRIFUGEUR Illustrons cette première partie du travail de spécification sur l'exemple du centrifugeur.
-A- ANALYSE DE L’ENVIRONNEMENT

L'environnement du système comprend 2 entités: - le MOTEUR, pour lequel la vitesse est une grandeur caractéristique, - l'UTILISATEUR, qui peut solliciter le système en appuyant sur les poussoirs lorsqu'il le désire.
-B- MODELISATION DU MOTEUR

La vitesse du moteur qui est la grandeur caractéristique est fonction de la commande appliquée et de la charge à entraîner: Vmoteur = ft (cv, charge). 224 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Le modèle doit être global. Pour cela, il inclut l'électronique de puissance servant de commande. CV est donc la consigne appliquée en entrée de l'amplificateur. Si une modélisation plus poussée qui tient compte de l'inertie et peut-être des non-linéarités, s'avère nécessaire par la suite, le moteur peut se modéliser par une fonction de transfert du 1er ordre par exemple ou par des équations différentielles.
-C- COMPORTEMENT POUR L’UTILISATEUR

Celui-ci est observateur de l'état du centrifugeur: observation de la consigne de vitesse et de l'état rotation ou pas. A tout instant, il peut souhaiter agir sur le centrifugeur: - fixer une consigne de rotation, - demander un cycle, - demander un arrêt. Le comportement de l'utilisateur est sans intérêt pour le problème. Par contre, les informations en entrée et sortie peuvent se spécifier comme ci-dessous. Toutes les actions de l'utilisateur sont exprimées par l'événement ORDRE, car les actions ne sont pas simultanées.
Vrotation : 0 .. Vmax UTILISATEUR Erotation : (Rotation, Arrêt) ORDRE = [ Marche | Arrêt | Consigne : 0 .. Vmax ]

-Figure 12.8- Modélisation de l'entité utilisateur.
-D- DELIMITATION DES ENTREES ET SORTIES DU SYSTEME

En l'absence du système, il n'y a aucun couplage entre l'utilisateur et le moteur. Le système va permettre de prendre en compte les demandes de l'utilisateur et agir sur le moteur. La délimitation pour cet exemple est la suivante. Elle suppose l'observation de la vitesse du moteur.
Vrotation : 0..Vmax

Erotation : (Rotation, Arrêt)

ORDRE = [ marche | arrêt | consigne: 0..Vmax ]

Utilisateur Système à spécifier Moteur
CV : 0 .. CVmax

Vmoteur : 0 .. Vmax

-Figure 12.9- Délimitation des entrées et sorties du système. M.C.S.E 225

Partie 3 - SPECIFICATION D’UN SYSTEME 12.6. SPECIFICATIONS FONCTIONNELLES Les spécifications fonctionnelles sont des renseignements essentiels pour clarifier le problème à traiter et l'objectif du système. En effet, c'est à partir de cette catégorie de spécification que débute la conception. Aussi une mauvaise spécification et toute inprécision conduisent inévitablement à des difficultés. Pour faciliter la compréhension, nous définissons tout d'abord ce qu'il faut entendre par spécifications fonctionnelles, puis nous développons la démarche à suivre pour les exprimer correctement. 12.6.1. Nature des spécifications fonctionnelles Les spécifications fonctionnelles ont pour objectif de décrire les fonctions que doit assurer le système pour son environnement. Les seules fonctions à considérer sont les fonctions dites "externes". Il ne s’agit surtout pas des fonctions internes nécessaires pour satisfaire les spécifications car dans ce cas il s'agirait déjà d'une description de la solution. Par fonction externe il faut entendre une fonction globale de l'application qui résulte de la collaboration du système avec des entités de son environnement. Prenons comme exemple d'illustration le cas du chariot pour le transport de matériau: la fonction globale pour l'application est "Réalisation d'un cycle de transport de matériau en automatique". Pour satisfaire cette fonction externe, il faut en interne du système, une ou deux fonctions de contrôle/commande du chariot et du tapis-chargeur. Enoncer les fonctions du système n'est pas suffisant, chaque fonction nécessite d'être caractérisée pour éviter toutes les ambiguïtés d'interprétation. S'agissant de fonctions externes, la spécification directe de celles-ci est souvent difficile sans évoquer les entités. Pour illustrer la signification d'une spécification fonctionnelle, considérons la figure suivante qui représente une application comprenant 2 entités et un système à concevoir. Le système est aussi une entité, mais qui n'existe pas avant son développement.
partie à caractériser

Entité 1

SYSTEME

Entité 2

-Figure 12.10- Exemple d’application. Comme toute entité peut se modéliser, la spécification fonctionnelle de l'entité "système" correspond à sa modélisation. Avant sa conception le système est à considérer comme une "boite noire" car on ne connait pas encore sa structure interne, aussi la modélisation ne peut être que globale et selon une vue externe. Ainsi, une spécification fonctionnelle est donc 226 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION l'expression des actions effectuées par les sorties du système sur les entités de son environnement et ceci conditionnellement à ses entrées qui, elles, fournissent des observations sur cet environnement. Les modèles et techniques de modélisation expliqués dans le chapitre précédent sont donc utilisables pour exprimer ces spécifications. Pour une spécification exprimée par un graphe état/transition, les règles à respecter sont donc les suivantes: - les états sont significatifs pour l’application, - les actions concernent les sorties du système ou des événements internes nécessaires pour exprimer la spécification, - les conditions utilisent exclusivement les entrées du système, des états de la spécification, des événements internes en particulier le temps absolu ou relatif (cas des durées ). 12.6.2. Approches pour élaborer une spécification fonctionnelle L'objectif est donc de décrire le système selon une vue externe en exprimant uniquement les relations entre ses entrées et ses sorties. De cette manière, pour la conception, le système pourra être considéré seul sans devoir faire référence aux entités. La difficulté porte sur le choix du type de modélisation à adopter. Contrairement aux entités de l'environnement où il s'agit de décrire un existant, pour le système les connaissances internes n'existent pas et donc seule une modélisation globale est possible. Mais comme un système d'une taille réaliste assure plusieurs fonctionnalités, une modélisation exprimant le comportement global du système est rarement possible. Il faut donc caractériser le système par sous-ensembles. En se basant sur les 3 types de modélisation décrits dans le chapitre 11, 3 approches non exclusives sont possibles: - caractériser le système à partir de l'évolution de ses sorties et des entrées, - caractériser le système à partir de l'évolution des entités, - caractériser le système à partir de l'application globale. Détaillons ces 3 approches.
-A- APPROCHE PAR LES ENTREES/SORTIES

Pour chaque sortie du système, il s'agit d'exprimer les états successifs selon une modélisation globale, faisant état des valeurs des entrées du système. La description peut se faire séparément pour chaque sortie ou globalement en partant alors plutôt de chaque entrée en utilisant un modèle stimuli/réponse. Cette approche est possible lorsque les valeurs des sorties peuvent se décrire par un modèle données/informations, c’est le cas lorsque le comportement des entités qui exploitent ces sorties n'est pas essentiel. Pour illustrer cette approche, considérons l'exemple d'un système simple qui est un transmetteur série. La délimitation du système est représentée sur la figure 12.11. M.C.S.E 227

Partie 3 - SPECIFICATION D’UN SYSTEME

DATA

TxD

Producteur

WR

Transmetteur
CTS TxRDY

Consommateur

-Figure 12.11- Délimitation du système avec ses entrées et sorties. Le transmetteur mémorise la donnée DATA sur apparition de l'événement WR, mais seulement lorsque le transmetteur est disponible (exprimé par TxRDY). Le transmetteur produit la donnée mémorisée sur la sortie TxD sous une forme série (bit start + 8 bits + parité + 2 bits stop). Ceci n'est possible que lorsque CTS est vrai. L'approche par les sorties consiste à exprimer pour cet exemple les états successifs des 2 sorties TxD et TxRDY.
Spécification transmetteur
PRODUCTEUR évolution de TxRDY évolution de TxD CONSOMMATEUR

Attente

TxRDY

Repos

TxD

Autre

CTS

WR Autre Désir transmission et TxRDY DATA, WR

TxRDY.CTS Donnée en transmission

prêt pour réception

Donnée à TxRDY transmettre Donnée en transmission

transmission

CTS Réception écoute de TxD fin transmission fin disponibilité

-Figure 12.12- Spécification de la fonction de transmission. TxRDY prend 2 valeurs, ce qui conduit à une modélisation à 2 états. Les conditions de transition dépendent des entrées (WR) et d'états ou événements internes (Donnée en transmission). TxD évolue seulement durant l'état transmission. Cet état peut se raffiner pour représenter les états successifs: bit start, bit donnée (i), parité, bit stop. La représentation du comportement des entités Producteur et Consommateur n'est pas nécessaire, mais facilite la compréhension. 228 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION
-B- APPROCHE PAR LES ENTITES

Lorsque les entités sont essentielles pour expliciter le rôle du système, nous préconisons une approche par les entités. Cette approche est facilitée par le fait que la première phase de la démarche de spécification conduit à caractériser les entités chacune prise isolément. Plutôt que de chercher à décrire séparément chaque sortie du système, il est préférable d'exprimer les états successifs souhaités pour les entités de l'application. Ainsi, la méthode préconisée dans MCSE consiste à caractériser le comportement de chaque entité sous la contrainte ou la conduite du système. Des états de chaque entité se déduisent alors les commandes à produire par le système, ce qui conduit à définir les sorties du système. Cette règle est très importante. En décrivant les effets du système et les conditions qui les engendrent, cela revient à spécifier les fonctions. Il s’agit d’une description externe du système puisque les noms des états ont un rapport avec les états des entités et ne sont donc pas des états internes du système. Illustrons ce point de vue sur l'exemple du chariot assurant le déplacement de matériau (voir 11.1). Les 3 entités de l'environnement sans le système sont spécifiées comme ci-dessous.
Opérateur Déplacement Chariot Tapis_chargeur

Arrêt P2 Arrêt

P <= P2 cmd=MD

Dépl. gauche Autre
cmd=MG cmd=AR

Marche_tapis

Marche_tapis

Marche

Désir cycle cycle

Arrêt
Désir arrêt Arrêt

Fermé
cmd=AR cmd=MD

Dépl. droite
cmd=MG P >= P1

Fermeture

Ouverture

Ouvert

Trappe

Arrêt P1

-Figure 12.13- Modélisation des entités de l'application. Les entités ne sont pas liées entre elles en l'absence du système de commande. Celui-ci est délimité comme l’indique la figure 12.14. Les entrées butée_D et butée_G ont été ajoutées tout de suite car elles s'avèrent nécessaires pour la réalisation de la fonction. Ceci se déduit des spécifications fonctionnelles par les conditions P ≤ P2 et P ≥ P1. M.C.S.E 229

Partie 3 - SPECIFICATION D’UN SYSTEME

Butée_D (P ≥ P1) Butée_G (P ≤ P2)

CMD : ( MD , MG , AR )

Chariot
cycle

Système à
CT = [ Ouverture | Fermeture ] Marche_tapis: booléen

Opérateur
arrêt

spécifier

Tapis_chargeur

-Figure 12.14- Délimitation du système. Pour l’application le système n'assure qu'une seule fonction, celle de réaliser un cycle automatique de déplacement du matériau. Pour caractériser la fonction du système, il s'agit de décrire les actions du système sur son environnement en fonction des événements ou observations. Pour cela, partons des entités commandables et décrivons l’évolution de chacune d’elles sous la contrainte du système.
Mise sous tension P ≤ P2 Arrêt cycle.P>P2 Arrêt Dépl. en P1 P ≥ P1 Rotation_tapis Arrêt Attente remplissage Plein Arrêt Dépl. en P2 P ≤ P2 vidage Arrêt Attente vidage Fin_vidage Vidage Marche Retour pos. départ Repos en P2 P ≤ P2 cycle Rotation_tapis (Tremplissage ≥ T1) + arrêt plein

Chariot - Déplacement Tapis_Chargeur
Arrêt

Trappe
Fermé (Touverture ≥ T2) + arrêt fin_vidage

Ouvert

-Figure 12.15- Modélisation globale pour les entités commandables. 230 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Le comportement pour ces 2 ensembles pour la réalisation d’un cycle automatique est représenté par la figure 12.15. Le système ne peut agir que sur les 2 entités: chariot et tapis_chargeur. La troisième l'utilisateur - n'est pas commandable car celui-ci a toutes possibilités d'appuyer sur les boutonspoussoirs quand il le désire. Les 2 ensembles couplés modélisables pour l'application sont donc: système + chariot et système + tapis_chargeur. Les diagrammes à états finis ci-dessus décrivent les états successifs des 2 entités. Les conditions de transition sont celles de l'application. Certaines sont produites par les entités, elles sont alors nécessairement des entrées du système. D'autres conditions sont internes au système: durée d'un état et événements tel que Rotation_tapis, Vidage, Fin_vidage, pour exprimer des relations d’ordre. A partir d’une telle description globale et compte-tenu de la modélisation faite au préalable pour chaque entité sans le système, il est possible de déduire facilement pour chaque état, les actions sur les entités et donc les sorties du système. Ceci conduit à décrire le comportement du système par une modélisation globale de l'évolution de ses sorties en fonction de ses entrées. La décomposition du modèle global en 2 parties: – modèle d'évolution du système, modèle d'évolution de l'entité – est montrée figure 12.16 pour 2 états de l’application.

[ SYSTEME + CHARIOT ]

[ SYSTEME ]

[ ENTITES ]

Déplacement cmd=MD cycle cycle dépl. droite dépl. en P1 dépl.en P1 marche_tapis; cmd=MD Repos P >= P1 rotation_tapis Butée_D Tapis chargeur arrêt attente remplissage attente remplissage marche_tapis; cmd=AR marche_tapis marche_tapis Arrêt P1 cmd=AR P ≥ P1

plein

( Tremplissage >= T1) + arrêt marche

-Figure 12.16- Relation entre modélisation globale et spécification du système. La spécification fonctionnelle à trouver est celle du système. Pour exprimer les relations entrées --> sorties, la spécification s'obtient en enlevant à la modélisation système + entité la part réalisée par l'entité. Habituellement cela revient simplement à ajouter pour chaque état les M.C.S.E 231

Partie 3 - SPECIFICATION D’UN SYSTEME valeurs des entrées de l'entité pour que celle-ci soit dans cet état, ou à ajouter sur franchissement de transition les actions génératrices des événements nécessaires comme entrée pour l’entité. En définitive, il s'agit bien toujours d'une description externe puisque les états de la description sont ceux des entités, et les conditions d'évolution dépendent des entrées du système et donc des états des entités. L'intérêt de cette approche est double. D'une part, elle reste compréhensible et donc vérifiable par le demandeur puisque la description est uniquement basée sur la connaissance de l'environnement. D'autre part, la spécification est évolutive car pour une modification du comportement d'une entité, seule la partie liée à cette entité est à modifier.
-C- APPROCHE PAR L’APPLICATION

Lorsque les 2 approches précédentes ne conduisent pas à une expression correcte et complète des spécifications fonctionnelles l’approche globale est nécessaire. Ceci correspond au cas d'entités complexes ou lorsque la décomposition de l'application en entités n'est pas suffisante (voir 11-8). Dans ce cas, la modélisation globale de l'application par un diagramme des activités sert comme base pour faire apparaître le rôle et donc les fonctionnalités du système. Les sous-ensembles que doit assurer le système sont ensuite spécifiés plus rigoureusement en décrivant les spécifications des données et les spécifications des activités. A ce niveau et à un certain stade du raffinement, les 2 approches précédentes sont utilisables. 12.6.3. Méthode pour élaborer les spécifications fonctionnelles Les spécifications fonctionnelles comprennent: l'expression des fonctions du système, puis une spécification de ces fonctions.
-A- LISTE DES FONCTIONS DU SYSTEME

Première partie essentielle de la spécification fonctionnelle, il s'agit tout d'abord de faire l'inventaire des fonctions que doit offrir le système pour son environnement. L'analyse peut se faire en recherchant les activités de l'application. Chaque fonction est décrite par: - un titre, - une description succinte de son rôle, - les entités de l’environnement concernées par cette fonction. Très important, il ne faut pas confondre fonction interne et fonction externe. L'expérience de la méthode a montré que cette différenciation pose quelques difficultés et qu'il est naturellement plus facile d'évoquer des fonctions internes; par exemple, la fonction dialogue très souvent évoquée est une fonction interne. Pour éviter ce type d'erreur, il faut faire l'effort de se placer au niveau de l'application et non pas au niveau du système.
-B- SPECIFICATION DES FONCTIONS DU SYSTEME

Le paragraphe précédent à montré que 3 approches sont utilisables pour décrire complètement les fonctions du système. Ces 3 approches ne sont pas exclusives, au contraire, chacune correspond à l’élaboration d’une vue différente du système. L’objectif d’une 232 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION spécification est de ramener toute la description à des relations entrées/sorties pour le système. L’approche par les entrées/sorties est la plus directe lorsqu’elle est possible, la modélisation des entités est alors réduite à la spécification de leurs entrées et sorties. L’approche par les entités est particulièrement appropriée pour les applications de contrôle/ commande en temps réel. L'expression du comportement de chaque entité sous la contrainte du système est facilitée par l'existence d'une modélisation de celle-ci en l'absence du système. Habituellement le même type de modèle est utilisable pour la spécification. Il a été montré que la description d'une fonction du système s'obtient indirectement en décrivant l'ensemble: fonction + entités. La base de la spécification est donc habituellement l'expression du comportement de chaque entité de l'environnement sous la contrainte ou l'influence des fonctions. Pour clarifier les relations fonctions —> entités concernées, il est possible d’utiliser un schéma relationnel qui servira comme base d’analyse pour cette phase de spécification. Nous avons constaté que lorsque les entités sont relativement simples (c'est-à-dire son modèle), chacune n'est concernée que par une fonction. Ainsi, caractériser les fonctions revient à modéliser le comportement souhaité de toutes les entités. Les dépendances entrées → sorties pour le système s’en déduisent. Les modèles à utiliser sont bien entendu les mêmes que ceux préconisés pour les entités. Lorsque cette technique de spécification ne s'avère pas satisfaisante, il faut alors avoir recours à une modélisation globale de l’application du type flot de données en délimitant données et activités du système. A partir de cette approche globale, il est possible d’affiner la spécification en sous-ensembles, puis de caractériser chaque sous-ensemble selon les approches 1 et 2. La démarche pour des spécifications par diagramme à états finis ou par diagramme stimuliréponse consiste pour chaque entité à débuter par l’état inactif ou état de repos. On ajoute ensuite un nouvel état pour chacune en le nommant puis en recherchant la condition de transition vers cet état. La spécification s'obtient ainsi d'une manière incrémentale par ajout d'états, de liens, des conditions de transitions et des actions. La recherche de la spécification peut se faire entité par entité. Mais lorsque celles-ci sont couplées par le système, il est préférable de considérer simultanément toutes les entités. Lorsque l'utilisateur est une entité de l'application, il n'est pas possible de le contraindre à suivre une procédure car il n'existe pas de moyen d'action directe. En effet, on ne peut pas par exemple empêcher un utilisateur de frapper sur n'importe quelle touche lorsqu'il est face à un clavier. Par contre, le système peut filtrer parmi toutes les actions de l'utilisateur, les séquences considérées comme correctes. La spécification liée à l'utilisateur concerne alors l'expression des séquences d’événements en provenance de celui-ci considérées comme correctes pour l'application. Cette partie de la spécification est alors plutôt exprimée par un graphe du type stimuli/réponse qui exprime le comportement du système vis-à-vis de l’utilisateur. Ceci est expliqué sur l'exemple du centrifugeur ci-après en 12.6.4.
-C- VERIFICATION DES SPECIFICATIONS

Une vérification doit suivre le travail de spécification pour s'assurer de la validité globale de la spécification. M.C.S.E 233

Partie 3 - SPECIFICATION D’UN SYSTEME Une première vérification consiste à s’assurer du respect des règles "syntaxiques" des modèles utilisées. En effet une mauvaise utilisation des modèles conduit obligatoirement à des ambiguïtés d’interprétation de la spécification. Il faut ensuite s’intèresser à l’aspect "sémantique" et donc à la signification de tous les éléments utilisés: états, conditions, actions, etc, et à la cohérence de l’ensemble vis-à-vis de l’objectif. A l'issue de cette phase, dans certains cas il est utile de revenir sur la délimitation des entrées et sorties du système. En effet, on peut être amené à constater l'existence de conditions ou d'événements non-observables auprès de l'environnement. Si ces informations ne peuvent pas être construites dans le système, des capteurs sont à ajouter pour y accéder. 12.6.4. Exemples On donne ci-dessous la spécification fonctionnelle pour le système de contrôle en vitesse d’un centrifugeur. La seule fonction du système est de réaliser un cycle de centrifugation à une consigne de vitesse fixée au préalable par l'utilisateur. Elle est spécifiée en explicitant les contraintes imposées au moteur conformément à l’approche par les entités, et le comportement du système vis-à-vis de l’utilisateur par l’approche entrées/sorties.
Système pour l’utilisateur Système + Moteur

Repos début cycle T:=0

Repos

Vmoteur = 0 Erotation = arrêt

ORDRE autre marche /si Erotation = arrêt alors début cycle; ORDRE ? arrêt /si Erotation = rotation alors arrêt cycle; consigne

CV tel que Vmoteur = Vrot * T Erotation = rotation AccéléraTm tion T >= TM T:=0 arrêt cycle Vm:=Vmoteur; T:=0;

/si Erotation vitesse CV tel que = arrêt Vmoteur = Vrot constante alors Vrot:=consigne; Vrotation:=Vrot; T>= TC ou arrêt cycle T:=0; Vm:=Vmoteur;

décéléraCV tel que tion Vmoteur = Vm - Vrot * T TD Vmoteur # 0

Couplage

-Figure 12.17- Spécification fonctionnelle pour le centrifugeur. La spécification ci-dessus s'obtient en considérant comme point de départ les états successifs voulus pour le moteur. Ensuite le comportement du système lié à l'utilisateur est celui d’un filtre de l’entrée ORDRE. On exprime pour cela le diagramme stimuli/réponse du système vis à vis de l'utilisateur. Ainsi, ce diagramme représente le "filtrage" des événements en provenance de l’utilisateur pour ne retenir que ceux corrects pour l’application. A noter par exemple qu'une demande Marche ne peut être prise en compte qu'après la fin du cycle précédent, c’est à dire lorsque Erotation = arrêt. 234 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION A nouveau, comme illustration de l’approche par les entités, est indiquée ci-dessous la spécification fonctionnelle pour l'obtention en automatique d'une toupie de béton à partir de la demande utilisateur (voir le problème en 12.3.2). La spécification s'obtient à nouveau en considérant toutes les entités de l'application et les contraintes imposées par le système.
Système pour l’utilisateur Silos A, Balance A et Tapis A
VA1 VA2 VBA VA3 TPA

Silos C, Balance C et Tapis C
VC1 VC2 VBC TPC

Malaxeur

Réservoir

MLX Repos VD Repos

Repos

Repos

Repos

VE

Désir béton Entrée paramètres ok cycle béton

cycle béton

cycle béton

Etat A=VidageA ou Etat C=VidageC Attente synchro

Etat malaxeur= attente synchro

arrêt + défaut

Pesage A1

VA1

Pesage ciment

VC1 ou VC2 selon choix

MLX

Débit eau VE

Poids >= PA1

Poids >= PC

Etat A=VidageA Etat C=VidageC
et

quantité désirée = QE

Attente béton

Pesage A2

VA1 VA2

Vidage ciment

VC1 VC2 VBC TPC

Malaxage

fin vidage

Poids>=PA1+PA2

Etat malaxeur = Malaxage avec ouverture

T >= Temps Malaxage

Pesage A3

VA2 VA3

Malaxage avec ouverture

MLX VD

Poids >=PA1+PA2+PA3

T >= Temps Vidage fin vidage

Vidage A

VA3 VBA TPA Etat malaxeur = Malaxage avec ouverture

-Figure 12.18- Spécifications fonctionnelles pour la production de béton. Les états sont faciles à trouver pour chaque entité. Le lecteur pourrait penser qu'il est plus simple d'exprimer directement le diagramme global pour l'automatisation de l'ensemble. Il s'agirait là d'une démarche conventionnelle qui conduit à décrire directement le comportement du système ce qui est plus compliqué, et le risque d'erreurs est plus important. La démarche préconisée ici est un stade intermédiaire qui permet de déduire le diagramme global. Notons aussi qu'une modification du cahier des charges de la part du client se traduit par une modification simple à localiser alors qu'elle est bien plus complexe pour la spécification globale. 12.7. SPECIFICATIONS OPERATOIRES Le terme OPERATOIRE est à prendre dans le sens: la manière dont une fonction doit opérer et les conditions et domaines de fonctionnement. Les spécifications opératoires comprennent donc: - d'une part toutes les précisions sur les grandeurs ou données qui sont apparues dans les spécifications fonctionnelles (type, domaine de définition). Toutes les grandeurs connues doivent être indiquées. On doit aussi y trouver les conditions de M.C.S.E 235

Partie 3 - SPECIFICATION D’UN SYSTEME fonctionnement, les performances en précision et tous les modes particuliers de fonctionnement. Par exemple, il n'est pas identique d'obtenir un résultat à 10 -2 ou un résultat à 10 -5. - d'autre part toutes les informations susceptibles de guider les concepteurs dans le choix de solutions à mettre en oeuvre. Les spécifications opératoires peuvent inclure la manière de réaliser certaines opérations (méthode de calcul par exemple). Ces spécifications sont généralement favorables. En effet, le demandeur peut avoir des avis sur les solutions à adopter pour la réalisation de fonctions énoncées dans les spécifications fonctionnelles. En tant que demandeur, celui-ci maîtrise son domaine, aussi a-t-il pu par exemple lors de réalisations précédentes ou à l'occasion d'une étude de faisabilité, expérimenter des méthodes et tirer des conclusions. Il est donc opportun de disposer de ses résultats pour augmenter les chances de réussite. Ces spécifications s'obtiennent par un travail d'analyse des spécifications déjà élaborées, de consultation de documents, de discussions avec le demandeur. Selon la nature des renseignements, elles s'expriment de diverses manières: langage naturel, modèle mathématique, algorithme... La spécification des performances d'un système dépend de la nature du problème. Par exemple pour un système de vision pour la détection de défauts, il n'est pas simple de caractériser les performances attendues. Une technique consiste alors à spécifier la procédure de test en définissant des objets caractéristiques qui permettront de valider le produit. Il peut s'agir par exemple pour une détection de défauts, de la définition de bonnes et mauvaises pièces que le système devra discriminer pour être accepté. 12.8. SPECIFICATIONS TECHNOLOGIQUES Cette catégorie est vaste puisqu'elle inclut toutes les spécifications qui ont un rapport avec la réalisation matérielle et l'implantation logicielle. Ces spécifications sont toutefois plus classiques et ainsi plus faciles à élaborer. Dans la suite, on cite pour mémoire les spécifications essentielles auxquelles il faut penser.
-A- CONTRAINTES DE REPARTITION

Lorsque l'application est répartie géographiquement (distance entre sous-ensembles > à 10 m par exemple), ces contraintes décrivent la topologie de la réalisation, les distances, les moyens de couplage et les contraintes d'utilisation de ces moyens.
-B- SPECIFICATIONS ELECTRIQUES DES INTERFACES PHYSIQUES

Elles concernent la caractérisation des signaux et des informations d'entrée et de sortie du système, ceci en décrivant les caractéristiques électriques des entrées et sorties des entités.
-C- SPECIFICATIONS DES INTERFACES DE DIALOGUE

La plupart des systèmes sont accessibles par des opérateurs directement ou via un organe de communication. Cette catégorie de spécification décrit: - d'une part les éléments technologiques à utiliser pour ces interfaces homme-machine, - d'autre part la procédure d'utilisation. Ceci revient à spécifier le dialogue hommemachine particularisé pour l'organe technologique retenu: menu pour un terminal, système d'icones pour un microordinateur, boutons et afficheurs pour un panneau spécifique... 236 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Ce type de spécification peut s'exprimer sous la forme d'un document papier, ce qui peut être un travail laborieux, mais aussi sous la forme d'un prototype. En effet, la technique de prototypage est un moyen pour élaborer des spécifications. La vérification par le client est alors grandement simplifiée.
-D- SPECIFICATIONS TEMPORELLES (CONTRAINTES DE TEMPS)

Pour l'instant, il n'a pas été fait état des temps de réaction du système aux sollicitations externes. On ne peut pas parler de systèmes temps-réel sans considérer ce type de contraintes car l'environnement est un monde réel qui génère des événements et modifie des informations à sa propre vitesse. Toute fonction en interaction avec cet environnement doit a priori réagir à la même échelle de vitesse. Comme toute réalisation fera intervenir un temps d'exécution ou retard, le concepteur doit déterminer avec le client les délais de réaction acceptables pour les différentes parties du système. Ces décisions servent de contraintes pour la réalisation. Les spécifications temporelles concernent uniquement l'environnement; le système doit réagir globalement aux stimuli d'entrée en agissant sur ses sorties et ceci en un temps maximum. Les contraintes de temps pour le système sont de plusieurs natures: - la fréquence de répétition qui indique pour des événements en entrée la fréquence de sollicitation du système (fréquence maximale, car la plus contraignante), pour des sorties la fréquence d'action sur l'environnement (fréquence minimale pour le bon comportement de l'entité concernée). - le temps de réponse caractérisant le temps maximum de modification de sorties à partir d'un événement ou d’une condition en entrée. Une modélisation du type stimuli/réponse favorise l'expression de telles contraintes. - des contraintes multiples qui expriment des relations temporelles entre plusieurs signaux (temps minimum, temps maximum). Des chronogrammes sont appropriés pour décrire ces spécifications. De telles spécifications se décrivent sous forme de tables ou sous forme de chronogrammes. La figure 12.19 illustre quelques exemples.
-E- MAINTENANCE ET SURETE DE FONCTIONNEMENT

Il s'agit de caractériser les fonctions souhaitées pour la maintenance ou l'aide au diagnostic: auto-test à la mise sous tension, test périodique en cours de fonctionnement, procédure de maintenance résidente, télé-maintenance... Pour la sûreté de fonctionnement, l'objectif est de caractériser divers aspects qui auront des influences sur la réalisation: - fiabilité du système, - disponibilité en cas de panne, - tolérances aux pannes matérielles, logicielles... - sécurité de l'environnement et des utilisateurs, - fonctionnement en mode dégradé, en mode manuel... Il ne s'agit pas là de spécifications fonctionnelles car elles dépendent de la technologie mise en oeuvre. Elles conduisent à modifier ou à enrichir la solution pour tenir compte de ces souhaits. M.C.S.E 237

Partie 3 - SPECIFICATION D’UN SYSTEME

Nom événement
PAS

Type
Interne: période de régulation entrée: période de réception de caractères entrée: surchauffe T < 5 ms

Contraintes

REÇU

Transmission à 9600 bds —> T<=1 ms

ALARME

exceptionnel

F_VANNE

sortie: fermeture vanne

Temps de réponse < 1 ms à partir de ALARME

Signaux Tmin = 10 ms

entrée
TOP 10 ns max 10 ns max 1 µs min 5 µs max

100 +/- 10 ns

sortie
S 1 ms +/- 100 ns 100 ns max

-Figure 12.19- Exemples de contraintes de temps.
-F- SPECIFICATIONS ELECTRIQUES

Elles précisent les caractéristiques électriques auxquelles doit satisfaire la réalisation telles que: consommation, dissipation, connectique, alimentation, types de composants...
-G- SPECIFICATIONS DIVERSES

Dans cette catégorie entrent des contraintes telles que: - contraintes liées au contexte dans lequel sera fabriqué le produit (utilisation de certains composants, modèles de cartes, encombrement, coût, outils de développement...). Ces contraintes sont à prendre en compte lors de la phase de recherche de la solution technologique. - des conditions liées à l'environnement (coupures secteur, milieu fortement parasité, milieu marin...). Elles peuvent obliger à introduire des redondances et des protections particulières. - des conditions en rapport avec la phase d'utilisation ou la durée de vie lorsqu'il s'agit d'une réalisation qu'il faudra maintenir longtemps ou qui devra évoluer. Les possibilités potentielles d'évolution doivent être exprimées. Comme illustration, on donne ci-après les spécifications pour le système de contrôle en vitesse du centrifugeur. Pour les spécifications opératoires, les temps a priori constants apparaissant dans la spécification fonctionnelle seront modifiables par le fournisseur sur demande d'évolution du client. 238 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Les temps sont: TM=5s TD=5s TC=20s La pente de décélération restera toujours constante. La vitesse peut évoluer entre 0 et 3000 trs/mn. La précision sur la vitesse doit être meilleure que 10 tours/mn sur toute l'échelle. Concernant les spécifications technologiques, la visualisation de la consigne de vitesse se fera sur 4 afficheurs BCD. La commande du moteur est du type PWM à la fréquence de 1 KHz et avec une sortie isolée électriquement. L'observation de la vitesse nécessite l'utilisation d'un codeur incrémental 100 pts/tour. La sortie du codeur est du type collecteur ouvert. L'entité moteur inclut: l'ampli classe D, le moteur et le capteur. Comme contrainte de temps, le moteur possédant une inertie variable, en particulier faible à vide, la commande du moteur doit être calculée au maximum toutes les 5 ms. 12.9. PROCEDURES D’INSTALLATION ET D’EXPLOITATION La description du comportement du système fournit une vue suffisante pour que le lecteur et donc le demandeur puisse déterminer si le système satisfait ou non son besoin. Il décrit ce que le système est capable de faire. Par contre, la description ne permet pas à un utilisateur potentiel ou à l'organisation qui va exploiter le système de déduire facilement s'il va répondre à tous les objectifs: utilisation, insertion dans l'organisation de la société, installation, maintenance... Des informations complémentaires sous la forme de documents sont donc nécessaires, à savoir: - une documentation préliminaire d'utilisation. Ce document décrit le système tel que vu par les utilisateurs. Il peut être structuré en parties lorsque plusieurs catégories d'exploitants sont concernées par le système (interface spécifique pour chaque catégorie par exemple). Ce document préfigure le manuel final d'utilisation. - une documentation d’installation. Il s'agit d'une description explicitant la manière d'exploiter et d'administrer le système. Au préalable, pour l'installation il peut aussi être nécessaire d'assurer dans l'organisation du client un transitoire pour tirer rapidement profit du système, par exemple, passage d'une procédure manuelle à une procédure automatique. Ce document doit donc décrire comment devra fonctionner l'organisation ce qui permet de faire évoluer l'environnement du système. Ces documents se rédigent progressivement à partir de l'ensemble des spécifications précédentes. Rédigés en fin de spécification, ils permettent au client d'avoir une information complète sur le produit qui sera livré. Les utilisateurs peuvent alors prendre les dispositions nécessaires pour faciliter l'installation, la mise en fonctionnement et l'exploitation du système. 12.10. EXEMPLE 2: AUTOMATISATION PAR CHARIOT FILOGUIDE Afin d'illustrer la démarche de spécification et le document résultant, on décrit ci-après l'analyse pour l'exemple d'une automatisation par chariot filoguidé, le cahier des charges ayant été décrit en 9.8.2. M.C.S.E 239

Partie 3 - SPECIFICATION D’UN SYSTEME 12.10.1. Modélisation de l'environnement Une analyse succinte du problème conduit à considérer les entités suivantes: - les quais en tant que donneurs d'ordre; les 2 ont un comportement identique. - l'atelier en tant que topologie comme support de déplacement: position des quais, trajectoire, obstacles... - le véhicule pour la partie mécanique assurant le déplacement et le chargement/ déchargement. - l'exploitant chargé de la bonne marche de l'installation. Celui-ci n'est concerné que par la sirène. Dans ce cas, constatant un incident, il repositionne le chariot et réinitialise son système de commande. Les paquets transportés ne sont pas utiles pour la résolution du problème puisqu'il n'y a pas de détection de présence. Le radar, les capteurs C1 et C2, l'émetteur-récepteur infra-rouge et les codeurs incrémentaux ne sont que des interfaces.
-A- COMPORTEMENT D’UN QUAI

Pour son environnement, chaque quai assure 2 fonctionnalités: - dialogue avec l'environnement par liaison infra-rouge: émission d'ordre (ORDRE) et réception de messages (MESSAGE), - rotation de son tapis dans les 2 sens pour le déplacement d'un paquet. Le tapis est caractérisé par 3 états qui sont définis à partir de la commande R_tapis: (AR, TG, TD). La modélisation du quai est donc la suivante:
Dialogue Tapis

Repos

Rotation droite

R_tapis=AR Message Désir transmettre ordre ORDRE

R_tapis=TD

Repos Interprétation R_tapis=TG R_tapis=AR

Rotation fin gauche

-Figure 12.20- Modélisation d'un quai.
-B- COMPORTEMENT DU VEHICULE

Le véhicule est composé de 2 sous-ensembles fonctionnels: - la partie déplacement incluant les 2 moteurs, - le tapis qui évolue dans les 2 sens. 240 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Le tableau ci-dessous résume les caractéristiques des variables du véhicule.
Variable interne Sortie Définition
Commande des moteurs 0 .. CVMAX

Sous-ensemble

Entrées
CVM1, CVM2

Partie Déplacement
P VM1, VM2

Position du chariot en deux dimensions Vitesse de chaque roue 0 .. Vmax Commande du tapis : Avant , Arrière, arrêt

C_TAPIS

Tapis
ETAT_TAPIS

Etat du tapis : arrêt, chargement, déchargement.

-Figure 12.21- Analyse pour le véhicule. A partir de cette analyse se déduit la modélisation. Un automate à 3 états (évident, non représenté) caractérise le tapis. Pour la partie déplacement, on peut simplement dire que la variation de position dans la direction suivie est proportionnelle à la moyenne des vitesses des 2 roues et donc des moteurs et que la variation de la direction est proportionnelle à l'écart des vitesses VM1 et VM2. Ceci peut se traduire par une formulation qui ne s'avère pas utile pour la résolution du problème.
-C- MODELISATION DE L’ATELIER

Pour le chariot, l'atelier définit la trajectoire à suivre ainsi que la position des obstacles à tout instant. Les informations utiles pour le système concernant le chariot sont: - OBSTACLE: information booléenne, - DCA: distance du chariot à sa trajectoire de consigne. 12.10.2. Spécifications du système
-A- DELIMITATION DES ENTREES/SORTIES

Le système à spécifier lié aux entités de son environnement est représenté figure 12.22. Il est assez évident à ce stade que des observations manquent pour satisfaire l’objectif puisque le système agit en boucle ouverte sur le chariot. Elles seront déduites de la spécification fonctionnelle.
-B- SPECIFICATION FONCTIONNELLE

On s'intéresse ici uniquement au chariot. Son système de commande doit assurer une seule fonction qui est celle d'effectuer en automatique le cycle de transfert pour chaque paquet. Interviennent dans la spécification les 2 quais chacun ayant un rôle différent et le chariot. L'initiative d'un cycle de transfert provient du quai 1. Le rôle du système est explicité par les diagrammes à états finis ci-après qui montrent bien que la déduction se fait à partir des entités. Le sous-ensemble tapis étant très simple, la spécification décrite figure 12.23 considère globalement le chariot comme une seule entité. M.C.S.E 241

Partie 3 - SPECIFICATION D’UN SYSTEME

Quai

Ordre

message

Son_Sirène

Exploitant

obstacle

Atelier

DCA

Système à spécifier
c_tapis CVM1 CVM2

Tapis + Déplacement
Chariot

-Figure 12.22- Le système et les liens avec son environnement.

QUAI 1
intervention opérateur sirène sirène Défaut Repos Défaut

CHARIOT
intervention exploitant Repos VC = 0 c_tapis = arrêt ok_présence Attente ordre transport

QUAI 2

I_présence Désir transport paquet I_présence

c_tapis = avant

Repos Période interrogation
TI

charg.

Charge I_présence

TC Attente réponse Transport c_tapis = arrêt quai 2 ok_présence

TI

Attente réponse Défaut chargement

déchargement rotation tapis TC

arrivée quai 2 ok_présence Attente VC = 0 détection Attente fin transport

Attente fin

rotation tapis

TI I_présence

ok_présence déchargement Attente décharge Décharge c_tapis = arrière

TC

transport

C_tapis=arrêt

TC

défaut Transport quai 1

transport c_tapis = arrêt

arrivée quai 1

-Figure 12.23- Spécification fonctionnelle pour la commande du chariot. Les ordres en provenance des quais sont donc I_Présence pour l’interrogation, chargement d’un paquet, transport au quai suivant, déchargement d’un paquet. Le seul message en provenance du chariot est ok_présence pour répondre à l’interrogation de présence. Le temps 242 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION TC est la durée de chargement ou de déchargement. TI est un temps maximum d’attente d’une réponse. La vitesse du chariot VC est celle imposée sur la trajectoire définie par le fil de guidage. L'étape de déplacement est identique qu'il s'agisse d'aller du quai 1 au quai 2, ou l'inverse. Elle se raffine en faisant apparaitre les phases de démarrage, de vitesse constante, d'arrêt. D'une durée de 1 s par variation linéaire de la vitesse, à 5 Km/H, le démarrage et l’arrêt se font sur 0,7 m.
VC = VCmax * t T >= 1 sec Accélération Vitesse constante VC = VCmax Proximité Décélération VC = VCmax * ( 1 - t ) Arrivée quai

Défaut VC = 0

Défaut VC = 0

Défaut VC = 0

avec Défaut = obstacle + ( DCA > max )

-Figure 12.24- Spécification de l'étape de déplacement. L'arrêt sur détection d'obstacle se fait en annulant la commande des moteurs, ce qui conduit à un arrêt par inertie. L'analyse des conditions de transition sur cette spécification fait apparaître la nécessité d'observations. - présence_quai, pour l'arrêt, - proximité_quai, pour la phase de décélération, - arrivée_quai. Un dialogue avec le client va permettre de définir le ou les capteurs nécessaires pour la connaissance de ces variables. De plus, pour que le chariot se déplace selon la consigne VC, une observation de la vitesse de chaque roue est strictement nécessaire.
-C- SPECIFICATIONS OPERATOIRES ET TECHNOLOGIQUES

N'étant qu'un exemple de présentation de la démarche, nous ne détaillerons pas ici ces spécifications technologiques qui sont pour l'essentiel données dans le cahier des charges (voir 9.8.2). Il s'agit d'un problème sans répartition géographique. S'il s'agissait de traiter globalement la commande de l'atelier: quais + chariot, nous aurions à faire à un système réparti géographiquement en 3 sites, avec la liaison infra-rouge comme support de communication. Il ne possède pas non plus d'interface utilisateur, mais il s'agit d'un problème temps-réel car la commande des moteurs doit réagir rapidement (entre 1 à 5 ms) pour que le chariot suive correctement la trajectoire à la vitesse de 5 Km/H. M.C.S.E 243

Partie 3 - SPECIFICATION D’UN SYSTEME 12.11. VERIFICATION, VALIDATION DES SPECIFICATIONS L'objectif de l'étape de spécification est d'obtenir un document cohérent, vérifié et accepté par le client. Cette validité s'obtient par un cycle auteurs-lecteurs. L'intervention des différents partenaires nécessite une planification des tâches. 12.11.1. Les participants Pour la vérification, le ou les auteurs des spécifications définissent avec le responsable du projet et dès le début de l'étape, les lecteurs qui conduiront, par des revues de la spécification, à l'obtention d'un document de qualité. Les lecteurs doivent représenter les catégories concernées par le résultat à savoir: le client, comme donneur d'ordre, les utilisateurs du produit ou système, les installateurs, hommes d'exploitation et de maintenance, les concepteurs du produit, si nécessaire un spécialiste en spécification.

Cette procédure s'avère efficace car de cette manière, côté client, toutes les personnes ont connaissance du produit. Si les objectifs ne sont pas convergents, une discussion aboutira à un compromis accepté. Le document sera ainsi validé et accepté comme base contractuelle. Toute modification ultérieure pourra raisonnablement être considérée comme un avenant au contrat. Côté concepteurs, avant de débuter le travail, l'équipe prend connaissance d’une manière progressive des objectifs à atteindre, de l'environnement, des spécifications complètes. Une évaluation de la faisabilité peut alors se faire très rapidement. Un spécialiste en spécification peut aussi réaliser une analyse critique des spécifications et de la démarche suivie. Ceci conduit à une amélioration de la qualité du document, à une simplification des modélisations et des spécifications, ce qui peut se traduire pour la suite par une réduction de complexité du développement. 12.11.2. Planification du travail et des revues Pour des raisons d'efficacité, au moins trois stades de lecture sont nécessaires: - après la modélisation de l'environnement. Cette première lecture permet de corriger les erreurs d'interprétation du spécifieur, - après les spécifications fonctionnelles. Ce stade est essentiel et justifié pour une bonne vérification, - à la fin des spécifications, pour corriger et éliminer toutes les erreurs et omissions. Avant de décrire la planification souhaitable, notons que par expérience il a été constaté que la durée d'une spécification est nettement plus longue que la somme des temps consacrés à ce travail. Approximativement, il faut compter un rapport de l'ordre de 3 entre la durée et le temps consacré. Pour le cycle auteur-lecteurs, chaque lecteur doit lire et annoter tout document qu'il reçoit. En retour, chaque auteur effectue la synthèse de toutes les remarques et met à jour son document qu'il rediffuse ensuite pour acceptation. 244 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION

PHASE Environnement

corrections

1
Spécifications fonctionnelles

corrections

2
fin des spécifications

corrections

3 t Lecture 1 Lecture 2 Lecture 3

-Figure 12.25- Planification des phases et des revues. Cette procédure ne donne de bons résultats que si les lecteurs se sentent responsables de la qualité du résultat. C'est aussi une manière de former des spécifieurs et de responsabiliser les intervenants côté client. Cette approche des spécifications se veut être du type participatif. 12.12. CARACTERISTIQUES DE LA SPECIFICATION Pour faire le bilan de ce chapitre, faisons le point sur l’intérêt d'une spécification en tant que modèle et sur la démarche présentée. Les caractéristiques essentielles du modèle préconisé pour la spécification sont les suivantes: - il s'agit d'un modèle conceptuel qui décrit ce que doit être le système et non un modèle physique qui décrirait la réalisation. Les modèles sont abstraits, ce qui permet, par une expression simplifiée du comportement, d'éliminer les détails. D’apparence complexe pour ceux qui abordent pour la première fois une méthode de spécification, rapidement le spécifieur est amené à constater son efficacité comme aide à l'analyse de tous les aspects d'un système puis son intérêt pour les phases ultérieures de conception et de réalisation. - la spécification est structurée. Cette qualité favorise une approche progressive des spécifications et des besoins du client jusqu'aux caractéristiques complètes du système. C'est cette structuration qui facilite la lecture du document par le demandeur et les utilisateurs, ce qui est indispensable pour la vérification. La classification des spécifications en catégories conduit aussi à une efficacité de la part des concepteurs pour la recherche progressive de la solution en ne considérant que les informations nécessaires pour chaque phase. - la spécification est complète car elle considère tous les aspects du système. Ainsi, le lecteur peut se faire une idée précise et juste du résultat qui en découlera en tant que produit ou système. Etant complète, elle sert avantageusement d'intermédiaire entre le client et le produit final. Avant d'entamer la conception, la spécification se trouve ainsi vérifiable. De même, lorsque le produit est réalisé, une vérification exhaustive de l'adéquation du système aux spécifications est possible. M.C.S.E 245

Partie 3 - SPECIFICATION D’UN SYSTEME - la spécification est interprétable. Il ne nécessite qu'une faible connaissance pour la compréhension des différentes parties de la spécification. Une partie des modèles sont graphiques, ce qui permet d'exploiter notre aptitude à analyser plus efficacement des informations. Sans tomber dans un formalisme extrême qui compliquerait la lisibilité pour le non-spécialiste, les modèles restent précis tout en étant explicites. Ainsi, le document de spécification basé sur ce modèle est particulièrement favorable pour les lecteurs. - la spécification est vérifiable. La structure du modèle et les dépendances entre les constituants introduisent des règles implicites de vérification de la cohérence d'une spécification. Ensuite, la lisibilité du document par plusieurs lecteurs - client, utilisateurs, concepteurs - conduit à éliminer une grande partie des erreurs ou omissions. De plus, la modélisation des entités sans le système, puis sous la contrainte du système, peut se vérifier assez simplement par simulation. De même, le prototypage pour les interfaces homme-machine est une technique qui favorise la validation des spécifications. 12.13. RESUME La méthode de spécification découle directement du modèle de description préconisée. Rappelons les points essentiels: - l’élaboration des spécifications est décomposée en 2 grandes phases: la modélisation de l'environnement, la spécification du système. - l'environnement est caractérisé sur la base d'une analyse du comportement des entités de l'application. Les entrées de ces entités sont des sorties pour le système et les sorties des entités sont disponibles comme entrées. Si nécessaire, cette modélisation peut servir comme base de simulation, en particulier pour le test du bon comportement du système avant son expérimentation sur site. - le système est lui-même considéré comme une entité complémentaire rapportée pour effectuer un couplage fonctionnel. Contrairement aux entités, qui elles, compte-tenu de leur existence peuvent se modéliser sur la base de la réalité, la spécification du système ne peut et ne doit pas être basée sur la description des fonctions internes du système. - le système est spécifié par une description externe la plus complète possible. Vu de l'extérieur, il assure des fonctions pour l'environnement. Ces fonctions sont caractérisées en explicitant leurs influences sur l'évolution des entités. La spécification du système repose donc très nettement sur la modélisation de l'environnement. - la spécification complète du système est classée en 3 catégories de renseignements fonctionnel, opératoire, technologique - de manière à favoriser son utilisation pour chacune des phases ultérieures du développement. - la méthode conduit à élaborer progressivement un document complet de spécification. Analysée par des lecteurs, la spécification est ainsi vérifiée pour devenir un document contractuel.

246

M.C.S.E

BIBLIOGRAPHIE 3

OUVRAGES [ABBOTT-86] An integrated approach to software development R.J. ABBOTT WILEY -interscience publication- JOHN WILEY&SONS, 1986 [ALFORD-82] Distributed Systems. Methods and Tools for Specification. An advanced course. Lecture notes in computer science. M.W. ALFORD, J.P. ANSART, G. HOMMEL, L. LAMPORT, B. LISKOV, G.P. MULLERY, F.B. SCHNEIDER. Springer-Verlag, 19 [AMGHAR-89] Méthodes de développement d’un système à microprocesseurs A. AMGHAR MASSON collection manuels informatiques, 1989 [BAILLY-87] Les langages orientés objets: concepts, langages et applications C. BAILLY, J.F. CHALLINE, P.Y. GLOESS, H.C. FERRI, B. MARCHESIN CEPADUES - Editions, 1987 [CALVEZ-87] Méthodes et Techniques pour l'Electronique numérique J.P. CALVEZ Support de Cours IRESTE NANTES, 1987 [CAPRON-86] Systems analysis and design H.L. CAPRON The Benjamin/cummings Publishing Company Inc, 1986 M.C.S.E 247

PARTIE

4

CONCEPTION FONCTIONNELLE

L'objectif de cette étape est de constituer un dossier complet de la solution retenue en se limitant aux aspects purement fonctionnels. Elle se doit de rester totalement indépendante des contraintes et solutions technologiques, de manière à représenter le "noyau dur invariant" pour l'application. Exploitant les spécifications fonctionnelles, le concepteur débute par la recherche d'une solution interne, ce qui correspond au travail de conception préliminaire ou architecturale. La solution retenue doit être conforme à un modèle appelé modèle Fonctionnel pour que celle-ci puisse être utilisée comme spécification pour l'étape suivante. Ce modèle correspond à 2 dimensions du modèle global. - la dimension fonctionnelle qui est de nature spatiale ou topologique, - la dimension comportementale. Pour faciliter son travail, le concepteur doit disposer d'un guide pour élaborer des solutions de qualité et conformes au modèle fonctionnel. Dans cette partie, le chapitre 13 présente tout d'abord le modèle fonctionnel. Les grands principes de conception que tout concepteur doit essayer de respecter pour aboutir à des solutions de qualité sont ensuite indiqués dans le chapitre 14. Le chapitre 15 développe la méthode à suivre, illustrée par des exemples. Comme aide aux concepteurs, le chapitre 16 montre l'apport des modèles génériques de solutions pour l'obtention de solutions générales de qualité.

M.C.S.E

251

Chapitre 13

LE MODELE FONCTIONNEL

Une description succinte du modèle fonctionnel et plus particulièrement du modèle de structure fonctionnelle, a été faite au préalable dans la partie 1: Présentation de la Méthodologie (chapitre 5). Le modèle fonctionnel exprime un ensemble de règles que doit respecter toute solution développée par un concepteur pour être en accord avec la méthodologie. Le respect de ces règles pour une solution lui confère les propriétés du modèle. La solution est alors exploitable comme spécification pour l'étape suivante qui concerne la définition de la réalisation. De manière à pouvoir se consacrer dans un premier temps à l'essentiel pour l'application sans se préoccuper des contraintes de nature technologique, le modèle fonctionnel concerne: - la topologie des constituants fonctionnels, - le comportement de ces constituants. Ce chapitre décrit complètement ce modèle, en explicitant les règles de description et de comportement, puis présente ses propriétés. Il détaille les 3 parties: le modèle de structure fonctionnelle, le modèle de comportement des fonctions, le modèle de description des données.

M.C.S.E

253

Partie 4 - CONCEPTION FONCTIONNELLE 13.1. LES CONSTITUANTS DU MODELE FONCTIONNEL Rappelons tout d'abord que la méthodologie est basée sur un modèle à 3 composantes. Les 2 premières composantes - structure fonctionnelle et comportement des fonctions - constituent le modèle fonctionnel (voir chapitre 5) Proposons tout d'abord une définition: - un MODELE FONCTIONNEL est une représentation par une structure d'éléments de tout ou partie d'un système. Il exprime la sémantique de ses éléments et des relations, et le comportement du système vis à vis du sujet de l'application qui l'intègre. Le modèle fonctionnel décrit dans [CALVEZ-82] est la composition de 3 ensembles d'informations: - la structure fonctionnelle, première dimension du modèle global de description, - l'expression du comportement des fonctions élémentaires, deuxième dimension, - la structuration des données incluse dans la première dimension. Structure fonctionnelle et structuration des données décrivent la dimension spatiale, tandis que l'expression du comportement des fonctions décrit la dimension comportementale, très souvent par une description temporelle mais pas exclusivement. La dimension spatiale utilise explicitement un modèle hiérarchique, ce qui permet les opérations de raffinement et d'abstraction. Une approche hiérarchique descendante est aussi utilisable pour l'expression du comportement; on se base alors sur l'apport de la programmation structurée. Ainsi la composition du modèle fonctionnel peut se représenter comme ci-après:
Données
Entrées / Sorties

Structure
Délimitation du système à concevoir
niveau 0

Fonctions

Spécification

Spécification fonctionnelle

Première structure fonctionnelle

Di

niveau 1

Fi

Solution

(pas obligatoire)

Structure détaillée Fonctions élémentaires (obligatoires)

Dk

niveau n

Fk

-Figure 13.1- Décomposition hiérarchique du modèle fonctionnel. 254 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL La partie organisationnelle (ou structure) est un arbre car une fonction non élémentaire est décrite par une structure de niveau inférieur. La partie Données est une collection d'arbres ou d’éléments terminaux. La partie Fonctions est une collection. Pour chaque niveau, on trouve les spécifications des données et des fonctions intervenant dans les structures du même niveau. Bien entendu, il n'y a pas de fonctions pour le niveau 0 en l'absence de tout raffinement. La spécification fonctionnelle caractérise ce niveau. Cette présentation hiérarchique suggère déjà assez naturellement le guide de travail pour la recherche d'une solution. Dans la suite du chapitre, on détaillera les caractéristiques des 3 parties du modèle fonctionnel: structure fonctionnelle, fonctions élémentaires, données. 13.2. LE MODELE DE STRUCTURE FONCTIONNELLE Une structure FONCTIONNELLE est l'expression topologique par un réseau d'éléments d'une réalisation pour une fonction. (On utilisera parfois dans la suite S.F. pour Structure Fonctionnelle). Une FONCTION dans sa signification usuelle désigne l'entité conceptuelle qui assure une activité spécifique. Ainsi, comme toute fonction peut se décrire par une structure incluant des fonctions plus élémentaires, une S.F. est un outil de raffinement. Dans la suite du paragraphe, on présente tout d'abord les conventions de représentation (vue statique), puis l'interprétation des symboles pour une compréhension non ambiguë de toute S.F. (vue dynamique). 13.2.1. Représentation graphique Toute fonction à décrire par un raffinement fonctionnel possède des entrées et/ou des sorties. Une structure fonctionnelle se construit à partir de 4 types d'éléments, à savoir: - des fonctions (F), chacune représentée par un rectangle, - des variables d'état (VE), représentées par le symbole: - des événements (EV), représentés par: - des ports (PT), représentés par:

Il faut y ajouter des liens entre ces éléments pour définir des relations. Les relations ne sont possibles qu'entre des fonctions et obligatoirement par l'intermédiaire d'un élément du type: variable d'état, événement, port. L'élément intermédiaire entre 2 fonctions est strictement nécessaire car les 2 fonctions peuvent être asynchrones. 3 types de relations sont autorisées: - la relation de synchronisation par un événement, - la relation de partage de variable par une variable d'état, - la relation de transfert d'informations (ou messages) par un port.

M.C.S.E

255

Partie 4 - CONCEPTION FONCTIONNELLE Voici un exemple de structure fonctionnelle décrivant la solution pour la commande d’un robot multi-axes.
(U)
Ordre [1.. n]

(S) Etat Supervision Coordination
CR M/A Point

Consigne

Mode

Interpolation Cmd i

T H Evaluation temps Horloge 1

Horloge 2 Pas

Contrôleur i
Commande de Robot

-Figure 13.2- Exemple de S.F. Un contrôleur est associé à chaque axe du robot. Il y a donc autant d’instances du type contrôleur que d’axes. La fonction de coordination transmet à chacun les ordres. Une fois chaque ordre réalisé, chaque contrôleur transmet un compte-rendu. Les variables d'état et les messages peuvent être de type quelconque: voir en 13.4 la spécification des données. Les instances multiples sont aussi représentables pour une bonne lisibilité. Tous les liens sont unidirectionnels, sauf si nécessaire pour l'accès à une variable en consultation et mise à jour. Pour une fonction décrite par une structure fonctionnelle, des liens partent de ses entrées (U) et aboutissent à ses sorties (S). Toute fonction interne à une structure fonctionnelle possède aussi des entrées et/ou des sorties. Les liens des relations aboutissent aux entrées et partent des sorties de ces fonctions internes. Chaque entrée ou sortie de fonction possède une nature: événement, variable, message. Une relation n'est correcte que s'il y a compatibilité de tous ses constituants: types de l'élément de la relation, des liens partant et aboutissant à l'élément, des entrées et sorties concernées. Formellement on peut dire qu'une fonction Fi, décrite par une structure fonctionnelle SFi, est définie par un triplet: Fi = (U, S, SFi) 13.2.2. Cohérence et lisibilité d'une S.F. Exprimons quelques règles de bon sens pour la représentation de toute structure fonctionnelle.
-A- COMMANDABILITE ET OBSERVABILITE

Une fonction est dite commandable si chacune de ses entrées se trouve liée extérieurement à une autre fonction. 256 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL Une fonction est dite observable si toutes ses sorties sont liées extérieurement à une autre fonction. La représentation graphique est cohérente si toutes les entrées et sorties de chaque fonction décrite par une S.F. sont utilisées. Ensuite, toutes les fonctions de la S.F. doivent être commandables et observables, et tous les éléments EV, VE, PT participent à une relation complète.
-B- SPECIFICATION DE TOUS LES ELEMENTS

La structure fonctionnelle ne doit pas être ambiguë. Pour cela, tous les éléments ainsi que les entrées et sorties doivent être nommés. Le choix judicieux par un nom concis est très important pour l'interprétation, avec une référence minimale à un texte d'explication. Voici quelques règles à suivre pour la sélection des noms: - Les variables d'état sont des informations ou plus généralement des objets utilisés par les fonctions. Ces éléments doivent donc n'avoir que des noms d'objets. Exemples: VITESSE, CATALOGUE AUTEURS. - les fonctions transforment ou exploitent les éléments objets. L'appellation doit donc résulter d'un verbe suivi d'un nom. Exemple: CONTROLE VITESSE, CONSULTATION AUTEURS. - Le nom d'un événement doit être celui d'un changement d'état. Exemple: ARRET, TEMPS ECOULE. - le nom pour les messages et donc celui des ports qui les reçoivent, doit exprimer l'apparition de données ou de commandes. Exemples: ORDRE, LIVRE RECU. En dehors de ces règles, il faut simplement s'efforcer de choisir les mots les plus appropriés car fort probablement les appellations retenues suivront le projet pendant toute sa durée de vie, ce qui peut en cas de mauvais choix, engendrer une complexité d'interprétation supplémentaire et inutile. Pour les entrées et sorties, le nom peut être différent de celui de l'élément lié. Pour un nom identique, ce nom est omis ce qui allège la présentation.
-C- PRESENTATION

Pour des raisons de clarté, une structure fonctionnelle doit avoir une qualité de présentation. Tout d'abord le nombre de fonctions pour un niveau est obligatoirement limité (5 à 7), au maximum. Ensuite, une règle de présentation simple consiste à considérer toutes les entrées à gauche des fonctions et les sorties à droite. Si possible, le positionnement des fonctions doit être tel que les relations aillent au maximum de la gauche vers la droite. Lorsque des boucles internes existent, ceci n'est évidemment pas possible. Une analyse des relations intervenant comme retour conduit à déduire une topologie des plus lisibles. Une relation fonctionnelle est représentée horizontalement. Une relation hiérarchique est plutôt représentée verticalement. La figure suivante illustre ces règles de présentation. M.C.S.E 257

Partie 4 - CONCEPTION FONCTIONNELLE

Reçu RxD Reception car. VOrdre M/A Etat Supervision

Dépôt CR Emission Emission car. Emis TxD

AC1 AC2
Horloge 2

Coordination
Hp VC1 VM2 Evaluation vitesse VM1 Horloge 1 H Asservissement vitesse

VC2

Inc2 Inc1

CVM2 CVM1

Contrôle / commande

-Figure 13.3- Exemple de présentation. 13.2.3. Interprétation d'une S.F. L'interprétation exprime les règles de comportement sous-jacentes à la représentation graphique, ceci de manière à fixer d'une manière non ambiguë les spécifications de tous les constituants et le comportement pour les interactions. Ces règles permettent d'associer à la vue statique d'une structure fonctionnelle, une compréhension de son aspect dynamique. La compréhension du comportement d'une structure fonctionnelle sera ainsi possible à chaque niveau de description, sans devoir connaître le comportement détaillé et complet de chaque fonction ainsi que la nature des données.
-A- REGLES POUR LES EVENEMENTS

Tout événement (EV) produit par une fonction sensibilise simultanément toutes les fonctions liées.
-B- REGLES POUR LES VARIABLES D’ETAT

Les variables d'état (VE) servent à assurer des échanges d'informations entre des fonctions qui peuvent être totalement asynchrones. Aussi, toute variable peut être modifiée ou consultée à tout instant et même simultanément par plusieurs fonctions. Les CONTRAINTES D'INTEGRITE devront être respectées par la réalisation, à savoir que 2 assignations simultanées (d1 et d2) doivent donner comme résultat de valeur soit d1, soit d2, mais pas une composition des 2. 258 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL
-C- REGLES POUR LES PORTS

Le PORT (PT) sert pour le dépôt temporaire de messages dans le cas d'un transfert entre 2 fonctions asynchrones. Elles sont habituellement appelées PRODUCTEUR et CONSOMMATEUR. Les instants de dépôt et de retrait, message par message par les fonctions sont tout à fait quelconques. Un retrait ne peut se faire que si au moins un message existe. Ainsi contrairement à la variable d'état qui ne peut prendre qu'une seule valeur à tout instant, le port est une FILE de mémorisation de tous les messages produits et non encore "consommés". La File est supposée de capacité infinie. L'ordre dans la file est du type: premier entré, premier sorti. Par suite de l'effet de mémorisation, le temps de transfert d'un message par ce mécanisme est tout à fait quelconque. La figure ci-après résume le comportement pour la relation par transfert de messages.
Producteurs Dépôt Port M1 Retrait M2 M3 M4

Attente

Consommateurs

-Figure 13.4- Spécification pour le transfert par port.
-D- REGLES POUR LES FONCTIONS

Une fonction est un opérateur de transformation des informations d'entrée pour produire en sortie des informations. Toute fonction est cyclique, c'est-à-dire qui réalise les mêmes transformations mais sur des données consécutives. 2 cas de comportement sont à considérer suivant la nature des entrées: - Fonction PERMANENTE: il s'agit d'une fonction ne possédant aucune entrée du type événement ou message. Ainsi, en l'absence de relation de synchronisation avec son environnement, la fonction joue en permanence son rôle de transformation. - Fonction TEMPORAIRE: une ou des entrées sont du type événement ou message. Les transformations sont alors obligatoirement synchrones aux événements ou messages reçus. Durant l'activité d'une fonction, toutes les variables liées par les entrées et sorties sont consultables et modifiables. De même, des événements et messages peuvent être produits par les sorties. Ces règles de comportement sont illustrées par la figure 13.5 qui montre bien la différence entre une fonction permanente et une fonction temporaire. M.C.S.E 259

Partie 4 - CONCEPTION FONCTIONNELLE

U Fonction permanente

S

U

S Ev Ev
t1 t2 t3 t4 t5

U Fonction temporaire H

S U H Ev S Ev

-Figure 13.5- Comportement permanent, comportement temporaire. Pour des fonctions élémentaires de transformation ou de synchronisation, le comportement peut s'assimiler à : - celui d'une machine séquentielle, synchrone aux événements ou messages d'entrée, pour une fonction temporaire, - celui d'un générateur pour une fonction permanente. Concernant les temps de transformation, sans spécifications particulières, ils sont à considérer comme nuls. Avec cette règle pour les fonctions temporaires, les générations en sortie sont synchrones aux événements d'entrée. Pour les fonctions permanentes, ces générations sont spécifiées par des caractéristiques temporelles. Voici un exemple permettant d'illustrer les règles précédentes.

Ordre SUPERVISION

Resultat

M/A Debit CONTROLE CHARGEMENT

Quantité demandée Position_vanne

Horloge Pas CHARGEMENT

-Figure 13.6- Exemple de structure fonctionnelle. 260 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL La fonction CHARGEMENT est sollicitée par chaque message ORDRE. Sur exécution de sa tâche il produit un message RESULTAT. Cette fonction est décomposée en 3 fonctions plus élémentaires: - SUPERVISION comme fonction temporaire, assure pour chaque message ORDRE: son décodage, la demande d'exécution par les variables M/A et QUANTITE DEMANDEE, l'attente de la fin d'exécution observée par M/A, la génération d'un message RESULTAT. Le temps de déroulement ne peut donc pas être nul. - HORLOGE est une fonction permanente pour générer un événement de discrétisation, - CONTROLE_CHARGEMENT comme fonction temporaire, réalise pour chaque événement PAS, l'observation de la demande M/A, la grandeur d'entrée DEBIT, et calcule la consigne POSITION_VANNE. Elle indique par M/A=arrêt, l'obtention de la quantité demandée. Les variables ne sont modifiées que lorsque les fonctions SUPERVISION et CONTROLE_CHARGEMENT sont en évolution. 13.2.4. Raffinement et abstraction d’une S.F. Le modèle de S.F. permet de décrire une fonction par une structure incluant des fonctions plus simples. Il s'agit donc d'un outil de raffinement. Inversement, une abstraction sur une structure fonctionnelle permet des simplifications de structure. On détaille plus précisément ces 2 mécanismes.
-A- RAFFINEMENT

Lorsqu'une fonction n'est pas suffisamment détaillée pour être spécifiée complètement, elle peut se détailler elle-même par une structure fonctionnelle. Appliquant cette démarche descendante pour un ensemble de fonctions, on aboutit à une structure fonctionnelle hiérarchisée en niveaux de description comme l'indique la figure ci-après.
V1

Ve Ev1

F1 F2

F3 V2

Vs

Ev2 Ev F2.1 Vr F2.2 V

Ev Ve

Vc F2.2.1 F2.2.2 Vs

-Figure 13.7- Exemple de structure fonctionnelle hiérarchisée, numérotation. M.C.S.E 261

Partie 4 - CONCEPTION FONCTIONNELLE Les délimitations de fonctions pour les niveaux intermédiaires peuvent s'éliminer. Elles ne sont d'aucune utilité technique. On dispose alors d'un modèle "plat". Ceci n'est pas judicieux car pour un système, les niveaux intermédiaires facilitent la lisibilité et donc la compréhension. Pour des raisons de repérage dans le cas de structures complexes, les fonctions sont numérotées. La fonction de départ considérée de niveau 0 n'a pas besoin d'être numérotée. Toute fonction d'un raffinement est numérotée à partir de 1. Toutes les instances pour une fonction possèdent le même numéro, puisque la spécification est la même. Suivant cette règle, le numéro d'une fonction élémentaire inclut le chemin complet dans l'arbre de la hiérarchie. Le niveau de la fonction se retrouve alors en comptant le nombre de chiffres.
-B- ABSTRACTION

Une structure fonctionnelle peut se construire par association de sous-ensembles de manière à intégrer des solutions déjà connues. Cette démarche va dans le sens de la réutilisation. Mais la solution peut devenir difficilement compréhensible pour des problèmes complexes. Des détails doivent être éliminés pour obtenir une description plus macroscopique. Pour cela, la démarche d'abstraction consiste: - à choisir un sous-ensemble de la structure fonctionnelle en le délimitant, cohérent en lui-même vis à vis d'objectifs, - à remplacer ce sous-ensemble par la spécification d'une fonction non raffinée obtenue en éliminant toute la description interne.
Ev MS Ev MS

V

V

F

U R

S U S

F
Pas

-Figure 13.8- Techniques pour l’abstraction. L'approche par abstraction n'est pas des plus évidentes, car la cohérence des fonctions à regrouper n'est pas immédiate. Toutefois, cette technique n'est pas à exclure, car il faut savoir qu'une démarche purement descendante par raffinement n'est pas toujours réaliste pour des applications assez complexes. Des itérations sont nécessaires, et c'est parfois par abstraction qu'apparaissent les meilleures fonctions à considérer pour une application. 262 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL 13.2.5. Décomposition maximale: fonctions élémentaires ou actions Selon la technique de raffinement, par itérations successives, la solution est de plus en plus détaillée. Bien entendu, il faut se poser la question de l'arrêt de l'itération pour chaque fonction. Un critère clair doit donc être précisé. La règle se veut simple : une fonction possèdant un comportement séquentiel et obligatoirement cyclique ne doit plus être raffinée. Pourquoi? Simplement parce que l'intérêt du modèle de structure fonctionnelle est de pouvoir faire apparaître un parallélisme potentiel des fonctions de la solution. Donc, si le comportement est séquentiel, le raffinement ne se justifie pas. Une telle fonction est appelée FONCTION ELEMENTAIRE ou ACTION. Mais comment peut-on savoir qu'une fonction possède un comportement séquentiel alors que, dans une démarche descendante, celle-ci n'est pas définie? C'est effectivement une question délicate. Pour qu'une description fonctionnelle soit complète et donc vérifiable, chaque fonction doit être spécifiée, ce qui veut dire décrite selon une vue externe. Si la spécification est basée sur un modèle séquentiel (diagramme d'état par exemple, modèles de transformation), on dispose de la réponse. Sinon, il faut tenter un raffinement qui peut conduire le concepteur vers une structure fonctionnelle ou une spécification ou la fonction est en fait élémentaire. 13.2.6. Règles de comportement pour une fonction élémentaire Pour la vérification, de manière à pouvoir interpréter le comportement d'une S.F. complète c'est-à-dire raffinée au maximum, on donne ci-après les règles de comportement imposées pour toute fonction élémentaire. Ainsi, sans devoir détailler le contenu d'une fonction, l'interprétation sera non-ambiguë pour tout niveau de la structure fonctionnelle. Les règles ci-dessous ont été retenues pour leur simplicité et parce qu'elles facilitent ensuite le travail de réalisation. Les règles de description interne données dans le paragraphe 13.3.3.C (expression du comportement des fonctions) conduisent à obtenir un comportement vu de l'extérieur, conforme aux règles de ce paragraphe.
-A- ACTION PERMANENTE

Toute fonction qui ne possède pas d'entrée du type événement ou message évolue en permanence. Si ce n'était pas le cas, rien ne permettrait d'indiquer le début d'évolution. Ainsi, l'action permanente est assimilable à un processus continu générateur de données ou générateur d'événements.
-B- ACTION TEMPORAIRE

Les entrées du type événement ou message servent à "rythmer" l'évolution obligatoirement cyclique de la fonction. Les transformations assurées par la fonction se font habituellement en temps nul. Le comportement de la fonction pour plusieurs entrées de synchronisation est spécifié par le réseau de Pétri de la figure 13.9. On se place ici dans le cas d'une fonction synchrone à plusieurs événements (EVi) et à la réception de messages (MESj). Le marquage initial pour EVi et MESj permet de représenter l'effet de mémorisation des événements et messages. M.C.S.E 263

Partie 4 - CONCEPTION FONCTIONNELLE

Attente activation Mémoire de Ev i Mémoire de Mes j

Ev i

Mes j

Ti

Tj

Fin Ti

Fin Tj

-Figure 13.9- Spécification du comportement pour une action temporaire. Ce réseau de Pétri montre que: - les conditions d'évolution peuvent être aussi bien l'apparition d'événements que la présence de messages, - les transformations ou opérations (Ti, Tj) sont réalisées en séquence (due à la présence d'un seul jeton) et donc en exclusion mutuelle (comportement séquentiel), - l'ordre d'évolution dans le cas de conditions vraies simultanément n'est pas déterministe (comportement non-déterministe), - tous les événements ou messages sont pris en compte (effet mémoire). Ce comportement est volontairement restrictif. Après avoir appliqué ce modèle pour développer de multiples applications, nous avons constaté que toutes les solutions peuvent se ramener sans difficultés à de telles machines séquentielles synchrones. Si on se limite à ce seul niveau macroscopique de comportement, la solution n'est pas toujours des plus aisées à décrire car elle nécessite une décomposition fonctionnelle importante. En effet, des spécifications nécessitent parfois dans la boucle du processus cyclique, de pouvoir décrire des attentes conditionnelles sur événements ou messages. C'est le cas par exemple pour la spécification des protocoles. Pour cette raison, le modèle de comportement durant l'évolution de la fonction a été enrichi par une phase d'attente sur condition événementielle simple ou multiple. Ceci se traduit par le fait que, parmi les opérations assurées par la fonction, l'attente conditionnelle est utilisable. Le comportement de cette phase d'attente sur un ou plusieurs événements ou messages est spécifié comme indiqué sur la figure 13.10. Une opération et une seule est assurée sur apparition du premier événement ou message de la condition. Si 2 ou plusieurs événements (ou messages) apparaissent simultanément, la décision de la branche utilisée est indéterminée. 264 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL

Attente condition

Ev i

Mes j

Ti

Tj

Fin Ti

Fin Tj

-Figure 13.10- Spécification de la phase d'attente. Ce comportement est intéressant tout particulièrement dans les protocoles de communication, lorsque l'on veut exprimer par exemple que l'évolution doit se poursuivre quand un message d'acquittement arrivera ou sur apparition d'un "chien de garde".
-C- NOTATION COMPLEMENTAIRE

Compte-tenu du comportement imposé expliqué ci-dessus pour une action temporaire, tous les événements et messages reçus n'ont pas la même signification: - Les événements ou messages dits d'ACTIVATION déclenchent un cycle d'activité, - les événements ou messages dits de CONDITION temporisent le déroulement de l'activité dans un cycle. Pour les différencier, les entrées des premières sont représentées par une simple flèche, les secondes par une double flèche. Ceci permet d'énoncer une règle simple de représentation: toute action temporaire possède au moins une entrée d'ACTIVATION. 13.2.7. Propriétés d'une structure fonctionnelle Citons rapidement les propriétés essentielles du modèle de structure fonctionnelle.
-A- MODELE STRUCTURE

La décomposition hiérarchique favorise la compréhension progressive de la description ainsi que la recherche d'une solution. Pour le raffinement, chaque fonction se décrit par une structure. Pour l'abstraction, le regroupement d'un ensemble de fonctions est remplacé par une fonction plus abstraite en vue par exemple de sa réutilisation. Le modèle structuré hiérarchique présente ainsi la solution comme un ensemble de niveaux hiérarchisés de structures partant des spécifications (vue purement externe) et allant jusqu'à une réalisation fonctionnelle pour l'application. Le niveau i + 1 se déduit du niveau i par ajout de contraintes supplémentaires pour la solution. M.C.S.E 265

Partie 4 - CONCEPTION FONCTIONNELLE
-B- MODELE INTERPRETABLE ET DONC VERIFIABLE

La seule connaissance des règles de comportement pour tous les éléments -fonction élémentaire, variable, port, événements- cités dans les paragraphes précédents permet de déduire le comportement complet de la structure fonctionnelle. Cette déduction ne nécessite pas la connaissance précise pour une application donnée de la spécification de chacune des fonctions. Le modèle est donc interprétable, ce qui est favorable pour la vérification de conformité vis à vis d'une partie des spécifications.
-C- EVOLUTION SYNCHRONE

Avec l'hypothèse du temps nul pour l'évolution des fonctions temporaires, tous les événements et messages produits sont synchrones aux événements et messages d'activation ou de condition. L'analyse est ainsi facilitée puisque toutes les évolutions sont immédiates et simultanées par catégorie.
-D- CONSERVATION DES RELATIONS D’ORDRE

Les relations d'ordre partiel sont respectées du générateur vers les récepteurs, ainsi que de chaque producteur vers le consommateur correspondant.
-E- MAXIMUM DE PARALLELISME

La règle de décomposition est de poursuivre le raffinement jusqu'à l'obtention de fonctions élémentaires. Comme par définition, ces fonctions ont un comportement séquentiel, le modèle de structure fonctionnelle complet représente donc a priori le maximum de parallélisme possible pour son évolution. Il est à noter que pour certains problèmes à très fortes contraintes de temps: traitement d'images par exemple, les algorithmes connus sont généralement séquentiels. Mais pour l'implantation, ces algorithmes doivent être transformés pour mettre en évidence un parallélisme. Ce travail se fait au-delà de la phase de conception fonctionnelle.
-F- MODELE DE STRUCTURE DYNAMIQUE

Les relations entre les fonctions peuvent aussi bien être statiques que dynamiques, de même pour le nombre et le type de fonctions. La structure peut donc évoluer dans le temps tout en respectant les règles de comportement énoncées. Ainsi, il est donc possible de décrire, et par déduction de concevoir, des systèmes admettant une EVOLUTION STRUCTURELLE (reconfiguration, fonctionnement dégradé, autoadaptation...). Dans la suite, on se limitera à la conception de structures statiques. 13.3. SPECIFICATION DES FONCTIONS ELEMENTAIRES La spécification des fonctions élémentaires décrite dans le paragraphe précédent exprime un point de vue externe. Ce point de vue est justifié pour permettre, après chaque étape du raffinement, une vérification de la solution fonctionnelle. Ce paragraphe a pour objectif de formaliser les règles de description du comportement interne de toute fonction élémentaire. La description qui sera faite, conforme aux règles du point de vue externe, jouera pour la phase d'implantation, le rôle d'une spécification complète et non-ambiguë. Cette spécification sera en elle-même suffisante pour la suite, sans devoir faire référence à la structure fonctionnelle qui l'inclut. 266 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL 13.3.1. Objectifs de la spécification Après chaque phase de raffinement, le concepteur doit vérifier la solution retenue par rapport aux spécifications. La vérification est faite, sachant qu'il a en tête le comportement qu'il imagine pour la fonction. Pour garantir une cohérence complète de la solution fonctionnelle, une fois le raffinement achevé totalement, le comportement de chaque fonction élémentaire doit être exprimé sur papier. Pour clarifier, citons les objectifs essentiels pour cette spécification: - éliminer toute ambiguité d'interprétation. Ceci est une condition nécessaire pour garantir la validité de la solution retenue. Pour cela, la description doit être: concise, compréhensible, non-ambiguë, complète. - être compatible avec le modèle fonctionnel, ceci veut dire que cette spécification apporte une dimension supplémentaire de la description (très souvent temporelle), avec compatibilité des couplages par les entrées et sorties des fonctions. - exprimer le "quoi" de préférence au "comment": spécification plutôt qu'implantation. Aussi la spécification doit s'exprimer sans considération de contraintes de temps. - favoriser ultérieurement la recherche d'une solution d'implantation. Incompatible a priori avec l'objectif précédent, il faut savoir toutefois que le produit final est une réalisation. Aussi, faut-il trouver un juste milieu entre la spécification formelle purement externe et une description de pure implantation. - favoriser la validation. Ceci peut se faire de 2 manières complémentaires: • par des lecteurs qui peuvent être par exemple des rédacteurs de spécifications, voire même les demandeurs, • par des outils informatiques, qui après traduction de la description, permettent de vérifier le comportement par simulation partielle ou totale. 13.3.2. Choix du langage de description La méthode de description doit satisfaire au mieux les objectifs ci-dessus. Analysons les solutions possibles par catégories.
-A- DESCRIPTION GRAPHIQUE OU TEXTUELLE

Les descriptions graphiques favorisent particulièrement la compréhension. C'est un excellent outil de communication. Toutefois, la description est difficilement complète surtout lorsqu'il s'agit d'exprimer des détails. Autant c'est un outil essentiel pour les spécifications globales, autant il n'est pas suffisant à ce stade si on désire disposer d'une description fonctionnelle suffisante pour poursuivre vers la réalisation. Une description textuelle perd en qualité de visibilité globale. A son avantage, la description peut être aussi complète que souhaitée. Nous retenons donc cette deuxième forme, sachant que l'unité à décrire sera limitée en taille. M.C.S.E 267

Partie 4 - CONCEPTION FONCTIONNELLE
-B- DESCRIPTION DECLARATIVE OU IMPERATIVE

Au sens strict du terme, une spécification ne doit exprimer que le "quoi" et pas du tout le "comment", c'est-à-dire ne donner qu'une vue externe de l'objet décrit. Une telle description n'est pas procédurale. Elle peut par exemple s'exprimer par des modèles formels (mathématiques ou autres ...) qui s'expriment en énonçant les pré-conditions et les postconditions pour la fonction. L'avantage de cette solution est que pour la suite, les réalisateurs disposent de tous les degrés de liberté pour trouver ou choisir la solution la plus appropriée pour satisfaire la spécification. En contre-partie, ce type de spécification n'est pas facile à écrire; il s'avère plus facile d'exprimer le comportement selon un modèle interne. Ensuite, la validation est difficile, voire impossible pour des descriptions assez complexes. Enfin, la description est très éloignée d'une description qui favorise l'implantation. Une description impérative est basée sur l'utilisation a priori d'un modèle interne et donc exprime une partie du "comment". Le danger de cette solution est de tomber sur une solution typiquement d'implantation. Pour la suite, les alternatives d'implantation deviennent particulièrement limitées. Comme avantage, elle permet de favoriser considérablement l'implantation et la validation par des outils informatiques, ce qui se traduit par un gain de temps appréciable. Pour exprimer comment les variables de sortie doivent être obtenues à partir de celles disponibles en entrée, presque obligatoirement, il faut faire intervenir des variables internes qui peuvent se déduire par exemple par une analyse des spécifications. Répondant le mieux aux objectifs énoncés, on retient l'utilisation d'une description du type impératif avec comme modèle interne celui de la machine séquentielle. Le rédacteur de la spécification devra trouver le juste milieu entre une vue purement externe et une implantation trop stricte de manière à conserver des degrés de choix pour l'implantation.
-C- LANGAGE NATUREL OU LANGAGE "EXECUTABLE"

Après avoir retenu la forme textuelle et du type impératif, il faut se poser la question de la rigueur syntaxique. Le langage naturel est très riche, ce qui permet une multitude de possibilités de description d'une même "chose". La compréhension peut ne pas être évidente par suite de redondances dans le texte. De même la vérification de complétude n'est pas du tout évidente. Un langage "exécutable" c'est-à-dire un langage informatique est particulièrement strict parce que régi par des règles syntaxiques et sémantiques précises. Les degrés de liberté sont nettement moindres. Mais par suite de la rigueur, les critères tel que concision, complétude, non-ambiguïté, non-redondance sont plus facilement satisfaits. A l'avantage des langages exécutables aujourd'hui, il faut noter l'existence de langages de haut niveau, et donc structurés et structurants, indépendants des matériels. Citons particulièrement: PASCAL et ADA. Indiscutablement, il faut retenir un langage du type exécutable. Ce type de langage favorise les critères cités dans les objectifs, réduit le temps de développement car presque exécutable tel quel, enfin permet une validation presque complète de la solution par simulation tout en restant indépendant de la technique. 268 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL On adoptera comme base, peut-être aussi plus par habitude, le langage PASCAL avec quelques extensions mineures indiquées dans la suite. Il est évident qu'un pseudo-langage du type: Si alors Sinon- est tout à fait possible; comme inconvénient, la vérification automatique par exécution de la description puis l'implantation ne s'en trouvent pas facilitées. 13.3.3. Le modèle de description Après avoir précisé les choix du type de description, ce paragraphe décrit formellement les règles de description à suivre. Le modèle de description est présenté selon 3 niveaux, chacun correspondant à un raffinement: - l'interface avec le modèle de structure fonctionnelle, - le corps de la description du comportement, - l'expression du contrôle des évolutions.
Fonction

Interface

Corps de la description

Contrôle des évolutions

-Figure 13.11- Structure de la description. Au préalable faisons état de quelques points importants à satisfaire: - 2 types de fonctions: temporaires ou permanentes suivant la présence ou non d'entrée(s) du type événement ou message, - cohérence de nature entre les entrées et sorties et les variables liées du modèle fonctionnel. - initialisation des variables du modèle fonctionnel. Obligatoirement pour que l'application parte d'un état initial donné, ces variables ne peuvent être initialisées que par les fonctions qui s'y trouvent liées par une sortie.
- A- INTERFACE AVEC LE MODELE DE STRUCTURE FONCTIONNELLE.

Le modèle de structure fonctionnelle considère une fonction élémentaire comme un symbole graphique représentant une "boîte noire" et possédant des entrées et sorties de 3 types: événements, variables, messages. Les entrées événements et messages sont de 2 types (1 flèche ou 2 flèches) suivant qu'il s'agit d'une entrée d'activation ou une entrée de condition d'évolution. M.C.S.E 269

Partie 4 - CONCEPTION FONCTIONNELLE Une description textuelle de l'interface doit être compatible avec cette notation symbolique.
EVe Mea Mee Ve
EVe EVs

EVs

Mea

Exemple
Mee Ve Vi

Vs

Vs

Ms

Ms

-Figure 13.12- Représentation graphique d'une fonction. La syntaxe retenue pour l’exemple ci-dessus est la suivante:
action EXEMPLE sur événement Eve et message Mea: T_Mea avec (entrées message Mee: T_Mee; var Ve: T_ve; entrée/sortie var VI: T_VI; sorties événement Evs; var vs: T_vs; message Ms: T_Ms);

Cet exemple permet de déduire facilement la syntaxe générale à respecter. Toutes les entrées, événements et messages d'activation sont précisés après "sur", les autres entrées et sorties après "avec". Pour une action permanente "sur" n'existe pas. La nature de chaque entrée ou sortie est identifiée. Pour les messages et variables, la structure de l'information est définie par son type (T_ ... par exemple). L'appellation "action" est retenue plutôt que "fonction", "process", "tâche", pour éviter les confusions avec une terminologie déjà employée par ailleurs et peut-être trop proche de l'implantation. Il faut avoir à l'esprit qu'une action est en fait une tâche qui évolue comme un processus, mais limitée à une fonction simple et donc relativement instantanée.
-B- CORPS DE LA DESCRIPTION

Cette partie décrit le comportement global de toute fonction. La description doit être conforme à la spécification retenue pour le modèle fonctionnel. Ainsi toute fonction se comporte comme une machine séquentielle, ce qui implique aussi l'initialisation de toutes les variables internes. D'autre part toutes les variables de sortie doivent être initialisées. La description doit donc respecter le modèle suivant:
Declaration constantes, types, variables; (internes) begin initialisation des variables de sortie et des variables internes; cycle <comportement> end cycle; end nom action;

L'instruction - cycle <comportement> end cycle; - exprime l'exécution cyclique de l'instruction <comportement>. 270 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL
- C- EXPRESSION DE L’EVOLUTION DE L’ACTION

Les 2 cas - action permanente, action temporaire - sont à différencier. Pour l'action PERMANENTE, il n'y a pas de condition d'activation. Le comportement est alors exprimé par une suite d'opérations séquentielles.
Instruction;

:

begin

Instruction;

end;

Pour l'action TEMPORAIRE, il faut associer à chaque entrée événement ou message d'activation, l'expression du comportement comme une suite d'opérations séquentielles.
Nom Ev

:

Instruction;

Nom Mess

begin

Instruction;

end;

L'évolution, qui implique l'exécution des opérations exprimées dans <comportement>, n'est effective que sur apparition de l'élément d'activation. Des entrées supplémentaires du type événement ou message peuvent aussi servir comme condition d'attente durant une évolution pilotée par une activation. La syntaxe est la suivante.
when Nom Ev

:

Instruction;

end when

Les when imbriqués sont particulièrement déconseillés. Il est alors sûrement préférable de revenir sur la structure fonctionnelle pour simplifier la spécification de la fonction. Pour compléter cette présentation, le comportement au niveau le plus élémentaire s'exprime à partir des structures de contrôle de la programmation structurée, à savoir: séquence d'instructions, itération (while ou repeat ou boucle do), décision (if, case). La syntaxe est alors spécifique du langage retenu. Une syntaxe du type langage structuré n'est pas toujours la forme la plus appropriée. En particulier, c'est le cas lorsque le comportement est du type combinatoire: les sorties dépendent uniquement des entrées. Pour des raisons de clarté et de concision, il est alors plus judicieux d'utiliser: - une table de décisions, - un arbre de décisions. M.C.S.E 271

Partie 4 - CONCEPTION FONCTIONNELLE La meilleure solution pourra ensuite être recherchée pour l'implantation: implantation de la table, traduction en langage de programmation...
-D- EXEMPLE ET REMARQUES

Pour illustrer le modèle de description, on donne ci-après le détail de l'exemple introduit au début du paragraphe. Le message Mea contient 2 types d’informations CMD ou ACK, ce qui se traduit par T_Mea = [CMD | ACK].
action EXEMPLE sur événement EVe et Message Mea:T_Mea avec (entrées message Mee:T_Mee; var Ve : T_Ve; entrée/sortie var VI : T_VI; sorties événement EVs; var vs: T_vs; message Ms: T_Ms); const K = 10; Var ETAT:(arrêt,marche); MESS:string; begin ETAT:= arrêt; VS:= 0; VI:= 15; cycle Mea: case Mea of CMD: ACK:

VS:= 1; begin VI:= VI + 1; signal(EVS); end;

end case; EVe : begin MESS:= "OK"; Send(MESS,Ms); when Mee : ETAT:= marche; end when; end; end cycle; end EXEMPLE;

Cet exemple, sans signification vis à vis d'une application, permet de voir les extensions retenues par rapport au langage PASCAL. On retrouve donc les 3 constructions: - "action ... sur ... avec (...);" pour l'interface, - "cycle ... end cycle;" pour le contrôle de l’activation, - "when ... : ... end when;" pour le contrôle de l'évolution. Ces 2 dernières structures de contrôle assurent implicitement la réception des événements et messages en entrée. De plus il est utile de pouvoir décider d’un traitement spécifique pour chaque type de message reçu. Pour cela, d’une part la description de la structure des messages est identique à la notation donnée dans les spécifications évitant ainsi d’utiliser des records variants, d’autre part la signification de l’instruction CASE est étendue pour permettre le test du type de message reçu. 272 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL S'ajoutent les instructions de génération d'un événement (SIGNAL) et de génération d'un message (SEND), ainsi que, si nécessaire, tables et arbres de décision. En remarque, nous aurions pu choisir le langage ADA comme règle de description. Cycle et When se remplacent alors plus ou moins directement par accept et select. Volontairement, nous avons préféré une syntaxe plus indépendante et probablement plus simple de compréhension pour les non-initiés à ADA. De plus, le mécanisme de communication synchronisation dans ADA est particulier puisque du type Rendez-vous nécessitant ainsi une synchronisation, ce qui est un principe très différent de l'échange asynchrone des messages par un tampon intermédiaire préconisé par le modèle fonctionnel. Bien entendu, si l'implantation doit se faire en ADA, la transcription sera alors relativement immédiate (voir 22.7). 13.3.4. Interprétation du modèle Ce paragraphe précise les règles de comportement induites par la syntaxe.
-A- INITIALISATION - EVOLUTION

Le système décrit par le modèle fonctionnel doit démarrer d'un état parfaitement déterminé, indépendamment d'un ordre d'exécution introduit par l'implantation. Pour cela, les séquences d'initialisation de toutes les fonctions sont à considérer comme se déroulant avant la partie évolution délimitée par "cycle". L'état de départ se trouve donc correctement défini si toutes les variables du système sont initialisées ainsi que toutes les variables internes. Ceci est une des règles de vérification de la description.
-B- ACCES AUX VARIABLES D’ETAT

Les variables d'état (ou variables partagées) sont à tout instant accessibles en consultation ou pour une mise à jour. Ainsi toute variable d'état peut apparaître dans une instruction d'assignation ou d'évaluation d'une expression. L'accès est supposé se faire en temps nul. L'exploitation de ces variables suppose en permanence leur cohérence et donc le respect des contraintes d'intégrité. L'implantation devra fournir une solution pour le respect de cette cohérence. En cas d'assignations simultanées par plusieurs fonctions, il est essentiel de définir les variables d'état telles que l'application reste insensible à l'ordre d'accès à une même variable.
-C- ECHANGE PAR MESSAGES

Pour un transfert par message, un port sert d'élément intermédiaire. L'instruction SEND (A,B) dépose le message A élaboré dans l'action dans le port lié à la sortie B. B peut être compris comme le canal de communication pour l'accès au port. Aucune hypothèse n'est faite sur la capacité du port. Ainsi toute opération SEND assure un dépôt immédiat. Par contre le retrait peut se faire à tout instant postérieur.
-D- ACTIVATION D’UNE ACTION

Pour les actions temporaires, les événements ou messages servant à l'activation sont à effet mémoire. Le port assure ce rôle pour les messages. Ainsi tous les éléments d'activation seront pris en compte par l'action, donc pas de perte. M.C.S.E 273

Partie 4 - CONCEPTION FONCTIONNELLE Les séquences d'opérations associées à chaque condition d'activation sont mutuellement exclusives comme indiqué dans le modèle de S.F. Pour 2 conditions simultanées ou plus, il y a déroulement séquentiel des séquences dans un ordre non déterministe. La spécification du comportement de la fonction doit donc être élaborée en restant insensible à l'ordre. L'intérêt de cette structure de contrôle d'activation est d'assurer naturellement l'exclusion mutuelle sur toutes les variables internes de l'action.
-E- EVOLUTION CONDITIONNELLE DANS UNE ACTION

Des événements ou messages peuvent servir au contrôle de l'évolution. Ces conditions d'évolution sont sans effet mémoire, ce qui veut dire que seul un événement dont l'attente est effective est pris en compte. Si plusieurs conditions existent, seule la première à apparaître est prise en compte. Ceci engendre l'exécution d'une seule branche. Les événements ou messages pour les autres conditions et qui apparaîtront ultérieurement sont éliminés. Ce comportement a été explicité par le Réseau de Petri dans le modèle fonctionnel (voir 13.2.6.B).
-F- DUREE D’EVOLUTION

En dehors de toutes caractéristiques technologiques, la seule hypothèse réaliste est une évolution de l'action en temps nul. Ainsi pour les actions temporaires toutes les sorties sont produites en synchrone aux conditions d'évolution. Pour les actions permanentes, des spécifications temporelles sont nécessaires lorsqu'il s'agit de préciser la fréquence de génération des sorties. 13.4. SPECIFICATION DES DONNEES Le modèle fonctionnel utilise en interne du système des données sous la forme de variables d'état ou de messages comme intermédiaires entre les fonctions chargées d'effectuer des transformations sur celles-ci. Pour que la description fonctionnelle soit complète, ces données doivent être complètement spécifiées. Dans ce chapitre, on ne se pose pas la question de l'ordre à suivre: faut-il commencer par spécifier les fonctions puis les variables ou l'inverse? Cette question sera évoquée dans l'exposé de la méthode de recherche de la solution. On peut toutefois noter qu'il apparaît bien difficile de spécifier complètement une fonction liée à des entrées et sorties de données, sans définir au préalable la nature de celles-ci. Dans la suite du paragraphe, après avoir précisé les objectifs de cette spécification, sont explicitées les règles de description conseillées, puis les règles d’utilisation de ces données. Le modèle de spécification des données préconisé pour la conception fonctionnelle est très similaire à celui décrit pour les spécifications (voir 11.5). Toutefois, il s'agit ici de caractériser uniquement les données internes. 13.4.1. Objectifs de la spécification des données Citons les points essentiels auquels doit répondre le modèle de spécification proposé: - définir complètement la nature des données ce qui nécessite d'expliciter: la catégorie (variable d'état ou message), la signification de la donnée, la structure de la donnée, le type de chaque constituant de base, 274 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL - retenir pour chaque donnée les constituants nécessaires et suffisants pour le modèle fonctionnel. Ceci implique que le modèle doit favoriser l'orthogonalité des constituants de manière à éviter les redondances, - exprimer complètement, sans ambiguïté et avec concision toutes les caractéristiques nécessaires, - être approprié à une large classe de données: du booléen jusqu'aux relations entre entités, - être indépendant de l'implantation, d'où l'utilisation d'un modèle conceptuel toutefois facilite la recherche d'une implantation. 13.4.2. Modèle de description Pour répondre aux objectifs ci-dessus, comme premier point, la forme de description est du type textuel pour des raisons similaires au choix effectué pour la description des fonctions. En plus, des aides graphiques utilisées pour la phase de spécification peuvent servir de complément ou comme aide à la recherche de la solution. Pour formaliser le modèle, 3 aspects essentiels sont à expliciter [WARD-85], à savoir: la signification, la composition, le type. Le modèle sera ensuite détaillé sur la base des opérateurs fondamentaux.
-A- SIGNIFICATION

qui

Toute donnée est désignée par un NOM. Pour éviter les ambiguïtés que peut induire ce nom, il doit être explicité par d'autres mots. Le problème est le même que celui de devoir définir un mot dans un dictionnaire. La signification d'une donnée s'obtient par analyse du rôle de cette donnée dans le système et donc dans le modèle fonctionnel. exemple KILOMETRAGE = * distance en Km parcouru par la voiture *
- B- COMPOSITION

Une donnée peut être: élémentaire, ou composée de données plus élémentaires. Par exemple, la position d'un avion peut être défini par les 3 grandeurs: latitude, longitude, hauteur. La composition s'obtient en exprimant les constituants et les opérateurs utilisés pour la composition. Les techniques de raffinement et d'abstraction sont donc tout à fait utilisables pour aboutir à une description structurée. La structuration des données est basée sur les 3 opérateurs fondamentaux de composition: - la concaténation, ou produit cartésien, ou le ET, (TOGETHER WITH). C'est l'association d'au moins 2 composants plus élémentaires, selon un ordre donné (symbole +), - la sélection, qui exprime le choix d’une structure parmi un ensemble (EITHER OR) (symbole |), - la répétition qui définit l’ensemble pour exprimer l’existence d’un même type de constituant, et ceci 0, 1 ou plusieurs fois (symbole {}). M.C.S.E 275

Partie 4 - CONCEPTION FONCTIONNELLE On adoptera donc les mêmes conventions syntaxiques et graphiques que pour les spécifications (voir 11.5). L’exemple V = A + B | { C } signifie que la variable V est la sélection de l’un des 2 types de données: A + B qui est la concaténation de A et de B, ou { C } qui est un ensemble d’éléments de type C.
-C- TYPE D’UN ELEMENT ET ATTRIBUTS

Les données considérées comme élémentaires sont des grandeurs spécifiées sur un domaine de définition. Les types classiques sont ceux connus en programmation: booléen, entier, flottant, énumération ... Pour améliorer la caractérisation des données, des attributs sont ajoutés tels que: le type de l'information, le domaine de définition ou les limites, la précision (ou la résolution), l'unité . 13.4.3. Catégories de données: les structures Après avoir rappelé précédemment les caractéristiques d'une donnée, on s'intéresse ici aux types fondamentaux de données obtenues par composition et utilisables pour la spécification des données internes d'un système. Au-delà de données identifiées individuellement, des descriptions plus complexes peuvent être obtenues à l'aide de relations de couplage. Ces relations conduisent aux structures de données.
-A- CATEGORIES DE DONNEES

Nous avons déjà vu dans la partie spécification que les 2 catégories de données à spécifier sont: - les entités donnée, - les relations. Une ENTITE est un "objet" physique, logique, ou autres (on parle alors d'objet abstrait) qui a sa propre identité: une personne, un service, un vol d'avion ... Elle est modélisée comme une donnée définie par: son type pour un élément de base, une composition de types pour un objet plus complexe. Les informations caractérisant l'entité sont des ATTRIBUTS qui définissent les propriétés spécifiques de l'entité [ABBOTT-86]. Une RELATION exprime un fait entre des entités. Avec les relations, les données deviennent des structures de données qui résultent d'un ensemble de données et de liens de couplage entre celles-ci. Par dualité structure de fonctions <-> structure de données, on retrouve tout à fait l'équivalent du modèle de structure fonctionnelle: fonctions et relations <-> données et relations. Pour des données, comment peut-on spécifier tout type de structures de données ? D'après les objectifs, la spécification à retenir doit favoriser ensuite l'implantation. Il faut savoir que pour les structures complexes, l'implantation se trouve facilitée par l'emploi de bases de données du type relationnel ou du type objet. Pour le modèle relationnel, les entités d'un même type sont mémorisées dans une table, de même pour les relations. Une table est en fait une collection de données d’un même type et donc un ensemble. Les liens exprimés par une relation se traduisent par des références sur les entités concernées. Ainsi les entités donnée et les relations peuvent s’exprimer par des structures de données. On peut donc partir de ce point essentiel qui favorisera l'implantation, pour définir la technique de spécification. 276 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL
-B- SPECIFICATION DES STRUCTURES DE DONNEES

Il reste à expliciter la syntaxe à utiliser pour spécifier des entités et des relations, conformément á l’idée de description introduite dans le paragraphe précédent. Entités et relations se définissent toutes les deux sous la forme de données. Ainsi l'analyse des catégories conduit à la nécessité de différencier 2 niveaux pour les données: - la donnée individualisée, - la collection d'un type défini de donnée (aussi appelé ensemble ou SET)
Nom Possesseurs

Voiture

Nom Possesseur voiture Possesseurs = possesseur voiture

-Figure 13.13- Donnée individualisée et collection. Une donnée individualisée est désignée par un NOM qui lui est propre. Pour plusieurs instances du même type, chaque instance possède son nom spécifique. Par exemple, V1, V2 : voiture; signifie que les objets V1 et V2 sont du type voiture. Dans une collection, toutes les données sont du même type, mais ne sont pas désignées individuellement. Comme toutefois chaque donnée doit être identifiée, sans devoir y associer un nom pour chaque, on peut imaginer plusieurs techniques de désignation: premier, suivant, dernier dans la collection. Ces mécanismes sont des techniques particulières qui concernent la phase d'implantation. Une autre solution possible, celle retenue ici, consiste à y accéder par le contenu. Une partie des informations contenues dans la donnée permet d'identifier d'une manière unique une donnée particulière dans une collection. Cette information minimale est appelée la CLE. Sur ce principe, on ne peut trouver dans une collection que des données possédant des clés différentes. Comme exemple, en supposant que No d'immatriculation et No Sécurité Sociale puissent servir de clés pour les voitures et les personnes, les 2 collections voitures et personnes se définissent par: voitures = { voiture } voiture = No Immatriculation+ marque + couleur + ... personnes = { personne } personne = No SS + situation + nom + adresse + age + ... L'information utilisée comme CLE est soulignée. La notation employée ici est celle de WARD [WARD-85]. M.C.S.E 277

Partie 4 - CONCEPTION FONCTIONNELLE La spécification d'une relation nécessite de désigner les entités concernées. Ceci est défini par des références sur les entités. Une relation peut se considérer comme une donnée individualisée, ou faisant partie d'une collection. Ainsi, une relation individualisée pour une personne possédant une ou plusieurs voitures s'écrit: Possesseur N = Personne_Ref + 1{ voiture_Ref }n + date Cette spécification permet d'exprimer toutes les voitures pour une personne donnée. Le suffixe Ref précise qu’il s’agit d’une référence. Les bornes 1 et n définissent les nombres minimum et maximum de voitures. La relation est donc du type 1-n. Date est un attribut de la relation. Pour exprimer toutes les relations du type possesseur, on utilise alors une collection: Possesseurs = { Possesseur } Possesseur = Personne_Ref + 1{ voiture_Ref }n + date Chaque relation particulière dans une collection, s'identifie alors par la clé de la relation ici formée des 2 informations de désignation. Si on désire associer la date d’achat pour chaque voiture, il faut alors écrire: Possesseur = Personne Ref + 1{voiture Ref + date}n. 13.4.4. Décomposition d'une donnée: minimisation et normalisation Les données doivent contenir les informations minimales nécessaires pour le système. Ceci s'obtient en choisissant des informations dites indépendantes. La modification d'une information n'implique alors aucune modification des autres. On parle de minimisation de la redondance des données. Pour la spécification des entités et des relations par des données, le même critère doit être appliqué. Il faut faire en sorte qu'une information spécifique ne soit définie qu'une seule fois. Pour le modèle relationnel des règles sont définies pour aboutir à une base de données dite normalisée, par analyse des dépendances fonctionnelles. Si l’application nécessite des informations plus précises, le lecteur est invité à consulter des ouvrages spécialisés sur les bases de données [DATE-86, ROLLAND-88, GALACSI-86-89]. Succintement la méthode préconise plusieurs étapes: - élaboration de la liste des champs ou attributs des entités et relations, - transformation selon la 1ère forme normale, ceci veut dire définition d'une clé primaire pour chaque type d'entités. On recherche pour cela le plus petit ensemble de champs permettant d'identifier de manière unique chaque attribut dans la collection. - transformation selon la 2ème forme normale. Pour des relations possédant une clé primaire, tous les attributs en dehors de la clé primaire de l'entité doivent dépendre fonctionnellement et élémentairement de cette clé primaire. Par exemple pour (A,B,C,D,E) et les dépendances suivantes qui doit être la couverture minimale des dépendances fonctionnelles: (A,B) --> C A --> D B --> E Il faut considérer les 3 entités suivantes: 278 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL (A, B, C) (A, D) (B, E) Supposons par exemple une commande définie par: CDE ( No_cde, code produit, date, quantité)
1,N 0,N

La 2ème forme normale est:

CDE No_cde

CMD

produit

CDE ( No_cde, date)

date quantité

code produit

CMD (No_cde, code_produit, quantité) car date ne dépend pas du code produit. - transformation selon la 3ième forme normale. Pour cette représentation, il ne faut pas retrouver de dépendances entre champs qui ne sont pas des clés (pas de dépendances transitives). Si c'est le cas, il faut faire une décomposition complémentaire. Pour (A, B, C, D) avec B → D il faut utiliser: (A, B, C) et (B, D). - transformation selon la forme normale de BOYCE-CODD (BCNF). Pour cette forme, tout champ qui est déterminant (partie gauche d’une dépendance fonctionnelle) pour les autres doit être une clé. Ceci permet d'éliminer des redondances. 13.4.5. Utilisation des données Après avoir explicité le modèle de description, il reste à présenter la manière de décrire une utilisation des données. Les variables d'un modèle fonctionnel sont disponibles en consultation ou pour la mise à jour avec respect des contraintes d’intégrité. La nature de l'opération possible sur les données est définie par le sens du lien. Une variable peut être utilisée en totalité ou en partie. Ceci est précisé par le libellé du lien comme l’indique la figure ci-dessous. V= A + B A B -Figure 13.14- Exemple de libellé des liens à une variable. Une donnée individualisée, complète ou partielle, est directement utilisable à gauche d'une assignation, ou dans une expression. Une donnée définie comme une collection nécessite de désigner le ou les éléments concernés. Les opérateurs disponibles pour manipuler un ensemble ou une collection (A) sont par exemple: M.C.S.E 279 V B A

Partie 4 - CONCEPTION FONCTIONNELLE - l’affectation d’un attribut d’une donnée: - l'ajout d'éléments: - le retrait d'éléments: - la mise à jour d'un champ pour un ensemble: - la sélection d'éléments d’un ensemble A: A[clé].champ := valeur; A := A + { entité }; A := A - { entité }; champ := valeur for {entité} A where <critère de selection>

- la lecture d’un attribut d’une donnée de nom N: V := A[N].champ;

Ajout, retrait, mise à jour et sélection concernent un ensemble d'entités. Un ensemble d'entités peut être la résultante d'une sélection selon un critère sur les valeurs de champs. Exemples: A := A + { possesseurs where possesseur.voiture_ref.N_immatriculation > ???MI44}; ETAT := 'Retraité' for { Personnes where personne.age > 60ans}; Pour une base de données relationnelle, ces opérateurs sont disponibles dans le langage d'interrogation SQL: select, insert, delete, update. Les tables du modèle relationnel et SQL sont une solution d'implantation pour des spécifications décrites selon le modèle proposé. Mais, ce n'est pas la seule solution. 13.5. PROPRIETES GLOBALES DU MODELE FONCTIONNEL Pour conclure la présentation du modèle fonctionnel, citons quelques aspects intéressants de ce modèle.
-A- INDEPENDANCE TECHNOLOGIQUE

Le modèle fonctionnel est général. En effet, aucune hypothèse n'a été faite sur la nature des données. Celles-ci peuvent être du type continu ou discret. Dans le cas continu, la fonction de transformation peut être du type permanent ou temporaire. Dans le cas permanent, il s'agit d'une fonction continue. On peut de cette manière modéliser des opérateurs tels que amplis opérationnels, multiplieurs, changeurs de fréquence ... Dans le cas temporaire, la fonction agit en synchrone à un événement et exploite ou produit des variables continues à des instants discrets. Le modèle permet ainsi de représenter toute nature de technologie.
-B- MODELE HIERARCHIQUE

Contrairement aux modèles dits "plats", le modèle hiérarchique favorise toute démarche incrémentale. En effet, avec un tel modèle, une démarche peut être: - purement descendante : on part du niveau le plus élevé, puis par décomposition, apparaissent les niveaux inférieurs, - purement ascendante: la présentation en niveaux s'obtient par regroupement pour chaque niveau de sous-ensembles du niveau inférieur. - mixte: à partir de tout niveau intermédiaire, on peut augmenter ou réduire le niveau de détail. 280 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL
-C- RAFFINEMENT ET ABSTRACTION

Dans la démarche descendante, le raffinement enrichit tout élément (fonction, variable) par apport de détails complémentaires. Raffiner un élément revient à faire apparaître une vue plus microscopique. Ces détails jouent le rôle de contraintes pour la solution. En effet, ces détails qui s'imposent ou se choisissent participent à l'expression d'une réalisation (dans le sens solution) pour l'élément considéré, ce qui élimine a priori toute autre réalisation. Concevoir correctement par raffinement impose donc d'envisager toutes les réalisations plausibles, puis sélectionner la meilleure sur la base de critères précis. Construire par ajout de constituants augmente la complexité. Dans la démarche ascendante, il faut pouvoir réduire cette complexité, ce que permet l'opération d'abstraction. L'opération d'abstraction consiste: - tout d'abord à délimiter ou "encapsuler" une partie de l'ensemble considéré, - ensuite à remplacer cette partie délimitée par sa spécification. Ainsi l'opération d'abstraction permet de faire disparaître des informations propres à une réalisation de l'élément abstrait. Cette technique favorise la définition d'objets en vue de leur réutilisation.
-D- INDEPENDANCE ET REDONDANCE

L'indépendance ou orthogonalité est un concept essentiel en conception. D'une manière générale, un ensemble d'éléments est dit orthogonal si la modification de l'un d'eux n'entraîne pas de modification des autres éléments de l'ensemble. Lorsque les éléments sont des fonctions, on parle alors d'espace de fonctions. Pour des éléments du type données, on parle d'espace de données. Le choix judicieux d'un espace orthogonal minimise: pour les données, le nombre de variables, pour les fonctions, la complexité de celles-ci et les couplages inter-fonctions. Bien-entendu, dans un espace orthogonal, la "défectuosité" d'une variable ou d'une fonction engendre une perte d'information, ce qui conduit à une réalisation incomplète et donc incapable de respecter toutes ses spécifications. Pour palier à ces défauts, si nécessaire, des éléments supplémentaires sont à ajouter. L'espace devient alors REDONDANT. La redondance s'obtient: - par duplication ou plus, de certains éléments critiques, - par ajout d'éléments représentant des compositions à partir des éléments de base. La redondance contribue à améliorer la SURETE de FONCTIONNEMENT, ce qui s'obtient par une augmentation de la complexité.
-E- REPRESENTATION GRAPHIQUE

Parmi les syntaxes ou représentations possibles pour un modèle -textuelle, graphique- le modèle fonctionnel est graphique pour la partie essentielle. Ceci lui confère les qualités de simplicité, concision et efficacité. Compte-tenu des règles simples d'interprétation, son utilisation favorise la lisibilité des documents produits par les concepteurs. M.C.S.E 281

Partie 4 - CONCEPTION FONCTIONNELLE
-F- CONSERVATION DES PROPRIETES

En respectant les règles de description, toute solution exprimée par un concepteur est une solution particulière du modèle fonctionnel. Ainsi la solution hérite de toutes les propriétés du modèle. 13.6. RESUME Rappelons en fin de ce chapitre qui a permis de formaliser le modèle fonctionnel, les points essentiels. - le modèle fonctionnel est composé de 3 ensembles: la structure fonctionnelle, la spécification des fonctions, la spécification des données, - le modèle de structure fonctionnelle est un modèle hiérarchisé qui favorise le raffinement et l'abstraction, - les relations fonctionnelles sont de 3 types: partage de variable, synchronisation par événement, transfert de messages, - la notation graphique favorise tout particulièrement la lisibilité, - une fonction est non décomposable si son comportement est exprimable selon un modèle séquentiel, - toute fonction élémentaire est cyclique et permanente (pas d'activation) ou temporaire (activations), - la spécification d'une fonction sous une forme algorithmique favorise sa vérification et son implantation, - le modèle pour les données est du type relationnel et hiérarchique. Il favorise l'implantation (bases de données relationnelles et données typées), - le modèle fonctionnel exprime le maximum de parallélisme possible pour la solution, - le modèle fonctionnel exprime la solution du problème sans faire état des caractéristiques technologiques.

282

M.C.S.E

Chapitre 14

PRINCIPES EN CONCEPTION

Toute solution développée par un concepteur doit être conforme au modèle fonctionnel. De cette manière, elle peut être reprise comme spécification pour l'étape suivante de conception détaillée. Le respect du modèle conduit aussi à l'obtention de propriétés, certaines améliorant la qualité, d'autres l'implantation, la testabilité, la sureté. Le chapitre précédent a eu pour objet de formaliser un tel modèle. Mais la connaissance du modèle n'est pas suffisante. Une solution peut être conforme au modèle et pourtant ne satisfait pas les spécifications ou ne possède aucune qualité de simplicité, de lisibilité, de maintenabilité. En plus de la connaissance d'un modèle, le concepteur doit disposer d'un guide qui va l'aider à ordonner sa démarche: les questions à se poser, les décisions à prendre et sur quels critères. C'est l'objectif d'une méthode. Une méthode est basée sur quelques grands principes qui vont donner à toute solution des qualités intrinsèques. Globalement, ces qualités visent à améliorer l'ensemble du cycle de vie du produit. Avant de décrire en détail la méthode associée au modèle fonctionnel, ce chapitre présente un panorama des principes qui facilitent la recherche d'une solution fonctionnelle. Ces principes serviront comme bases pour la méthode présentée dans le chapitre suivant. Il s'agit de répondre à quelques questions essentielles que doit se poser le concepteur: - Comment faut-il décomposer pour proposer une solution? Quels principes suivre? - Quels éléments faut-il rechercher pour aboutir à une bonne décomposition? - Sur quels critères se juge la qualité d'une solution?

M.C.S.E

283

Partie 4 - CONCEPTION FONCTIONNELLE 14.1. CONCEPTION ORIENTEE SUJET Les systèmes temps-réel à concevoir sont essentiellement des systèmes dédiés pour une application spécifique. Tout système résulte de l'association de multiples constituants. Si on fait une analyse des divers constituants entrant dans la composition d'un tel système, on trouve: des fonctions proches de la spécificité de l'application (fonction de régulation, d'observation ...) et des fonctions plus générales qui peuvent se retrouver dans de multiples applications (base de données, gestionnaire de dialogue, exécutif multi-tâches ...). Concevoir, c'est rechercher puis sélectionner les constituants nécessaires pour exprimer une solution. Cette recherche doit se faire à partir du ou des sujets de l'application. ALFORD a défini les caractéristiques des systèmes dédiés à partir d'une vue globale de toute application. D'une manière générale, tout système possède un espace de PERCEPTION et un espace d'ACTION. Les ENTITES de l'environnement qui sont les SUJETS de l'application, entrent dans l'espace de perception, sont observés, alors le système agit sur eux, puis ils quittent l'espace d'action [WARD-85].

Perception Action

Perceptions Autres

Actions

Système
Structure

-Figure 14.1- Le modèle Perception/action pour un système de contrôle. Une telle vue du système à concevoir, en terme d'objectif global, permet d'orienter la démarche d'analyse vers une recherche des constituants essentiels dans les 3 catégories: - perception, - action, - exploitation, transformation, évaluation, etc, comme intermédiaires entre les 2 précédentes. Cette approche est orientée SUJET, car elle part de l'essentiel (WHAT), contrairement à une approche réalisation qui consiste à rechercher des éléments qui devraient permettre de satisfaire les spécifications. Selon les auteurs, on retrouve plusieurs terminologies pour exprimer la même idée: approche logique plutôt que physique, séparation entre l'essentiel et la réalisation (implémentation). 284 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION Une conception doit satisfaire les spécifications du problème. Il faut donc faire l'analyse en se basant sur les spécifications. Une conception orientée sujet se trouve facilitée si les spécifications sont basées sur une modélisation de l'environnement et donc du sujet. C'est le cas de la démarche proposée pour élaborer les spécifications fonctionnelles. Ainsi, les données d'entrée pour l'étape de conception, à savoir les spécifications fonctionnelles, favorisent l'élaboration d'une solution orientée sujet. Cette démarche oblige à résoudre tout d'abord les problèmes très spécifiques de l'application, en priorité par rapport à des problèmes plus généraux rencontrés dans la plupart des applications et pour lesquels les solutions sont connues. L'exemple suivant de contrôle de température montre la différence de résultat entre une approche SUJET et une approche réalisation.
Correct
Ordre Clavier Modification paramètres Consigne T T Filtrage et règulation Tm Demande Tm Télétransmission Tm Mess_Tm Demande Interprétation message et réponse Réponse Cmd T Filtre Tm Commande Dialogue

Incorrect
Ecran

Paramètres Cmd

-Figure 14.2- Approche SUJET, approche REALISATION. Dans le premier cas, les fonctions et variables sont définies relativement au sujet, tandis que dans le deuxième cas, les fonctions sont plus générales. 14.2. CONCEPTION INDEPENDANTE DE LA TECHNOLOGIE Une solution complète inclut à la fois des constituants dits fonctionnels et des constituants plus matériels que sont: capteurs, actionneurs, processeurs, mémoires, réseau de communication ... La deuxième catégorie est un support pour la première catégorie. En conception, il faut tout d'abord trouver l'aspect fonctionnel pour ensuite déduire le support. Contrainte imposée, une conception fonctionnelle se doit d'être totalement indépendante de la technologie. L'avantage de cette approche est de concentrer son effort sur l'essentiel au départ et de ne considérer les détails technologiques qu'au dernier moment. Ceci converge avec l'approche orientée sujet. Pour le modèle de l'approche SUJET, perception et action sont des fonctions nécessaires au système qu'il ne faut pas confondre avec des interfaces physiques pour capteurs et actionneurs. M.C.S.E 285

Partie 4 - CONCEPTION FONCTIONNELLE Avantage supplémentaire, la solution étant indépendante de la technologie, une même conception fonctionnelle peut servir comme point de départ pour la recherche de plusieurs solutions technologiques. Ceci est nécessaire, par exemple, lorsqu'il s'agit d'optimiser les temps de réalisation, les coûts de développement et de reproduction, ou lorsqu'il devient souhaitable de revoir la réalisation par suite de progrès technologiques. Respecter ce principe nécessite de connaître les points que nous considérons comme dépendants de la technologie. Certains points sont évidents (interfaces électriques par exemple) d'autres nettement moins. Il faut ensuite disposer de spécifications structurées qui ne concernent que la partie fonctionnelle, et ne faisant pas état des contraintes technologiques. Dans la suite de ce paragraphe, sont présentées les catégories de fonctions ou contraintes dépendantes de la technologie. Ces catégories résultent d'une longue expérience d'application de la méthodologie sur des problèmes industriels avec des comparaisons de solutions qui incluaient ou pas ces caractéristiques comme contraintes technologiques. 14.2.1. Fonctions d'interfaçage avec l'environnement physique Toute fonction qui ne transforme pas une information, c'est-à-dire qui n’assure pas un changement de sa nature, est une fonction dépendante de la technologie. C'est le cas en particulier de toutes les fonctions d'interfaçage qui n'ont pour seul objectif qu'un changement de la représentation de l'information et non pas sa nature. Par exemple, lorsque pour un système, la grandeur Vitesse V est une grandeur essentielle, et que le capteur est du type codeur incrémental, la fonction qui permet de disposer à tout instant de V à partir de l'événement INC est une fonction technologique comme l’indique la figure ci-dessous.
V

Chariot

Contrôle Commande

Indépendant

Chariot + capteur

INC

V

Evaluation vitesse

Contrôle Commande

Dépendant

-Figure 14.3- Indépendance/dépendance vis à vis de la technologie. Retenons qu’une solution se trouve indépendante de la technologie, s'il est possible ultérieurement de mettre tout type de capteurs ou d'actionneurs sans modifier la solution fonctionnelle. Ceci est vrai, si les grandeurs considérées sont des grandeurs fonctionnelles et non pas physiques. 286 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION 14.2.2. Fonctions de dialogue homme/machine Les fonctions de dialogue entrent dans la catégorie des interfaces. Mais il est intéressant de les considérer séparément des précédentes car l'entité correspondante est un utilisateur et pas un procédé physique. Vis à vis d'un utilisateur, le système est réactif aux actions de l'utilisateur. Le couplage nécessite une fonction de nature interactive. Une fonction de dialogue pour un système définit toute la convivialité du système. Cette convivialité peut être très variée selon la technologie utilisée et selon la forme du dialogue: - action sur des potentiomètres et observation sur des cadrans, - claviers et afficheurs, - terminal, - dialogue question-réponse, - langage de commande, - menus iconiques, - gestionnaire multi-fenêtres ... La forme du dialogue a des implications évidentes sur la technologie (pas de possibilités de menus iconiques avec un simple terminal alphanumérique). En sens inverse, une technologie donnée délimite les possibilités de formes de dialogue. Pour qu'une solution fonctionnelle soit totalement indépendante de la technologie pour l'interface homme/machine, elle doit permettre de choisir toute forme possible de dialogue. Par la suite, après sélection d'une forme, se déduira alors la technologie. Une solution convenable ne s'obtient que si, pour l'aspect dialogue, le concepteur se place à un niveau élevé. Pour cela, il ne faut considérer en entrée que les informations globales ou événements significatifs produits par l'utilisateur, et en sortie, celles que lui fournit le système. Par exemple, il ne s'agit pas de descendre au niveau de la gestion de chaque caractère tapé sur un clavier de terminal, mais au contraire il faut se placer au niveau des messages de commandes générées par l'utilisateur. La figure 14.4 montre la possibilité de mettre tout dispositif de dialogue sans modifier la solution fonctionnelle: clavier-afficheur, terminal, système d'analyse et synthèse de parole ... 14.2.3. Répartition géographique Avec la technologie du type microprocesseur, les systèmes sont de plus en plus conçus comme des systèmes répartis, c'est-à-dire, des fonctions réparties sur des processeurs différents couplés entre eux par un système d'interconnexion. Lorsque la distance dépasse quelques mètres, le couplage entre processeurs se fait obligatoirement par une ligne de communication: bien souvent par une ligne série, ou par un réseau local, ou par un réseau de télécommunication. L'emploi des lignes de communication impose des couplages entre fonctions par un transfert de messages. Il peut donc sembler naturel d'inclure les contraintes de répartition géographique au niveau fonctionnel pour rechercher une solution adaptée dès le départ à la topologie. M.C.S.E 287

Partie 4 - CONCEPTION FONCTIONNELLE

Indépendant

Dépendant

Utilisateur

Utilisateur

Touches

Affichage

Demandes

Résultats

Gestion des touches

Présentation résultats

Demandes

Résultats

Solution fonctionnelle

Solution fonctionnelle

-Figure 14.4- Indépendance/dépendance pour le dialogue. Pendant plusieurs années, nous avions adopté ce point de vue sans avoir pensé à une autre façon de faire. Après avoir expérimenté la méthode en reportant la prise en compte de ce type de contrainte à l'étape suivante de définition de la réalisation, nous avons constaté une qualité intéressante des solutions. Le résultat s'explique. Si on considère au niveau fonctionnel la contrainte de répartition, la solution est basée sur des relations du type transfert de messages. Les messages se trouvent difficiles à spécifier puisqu'ils dépendent de la répartition des fonctions qui sont à trouver. En recherchant d'abord les fonctions avec la contrainte de répartition, il est difficile de déduire les échanges strictement nécessaires entre les fonctions. Par contre, en ignorant cette contrainte, on recherche une solution fonctionnelle répondant aux spécifications. Il est alors possible à un stade ultérieur de décider de la répartition des fonctions compte-tenu des contraintes géographiques, puis de déduire les informations à échanger et les mécanismes de communication appropriés. La figure 14.5 montre qu'il est aisé d'introduire ensuite la répartition géographique. Le mécanisme de communication choisie (liaison série) n'assure que la mise à jour de V" par suite d'une modification de V'. La solution résulte d'une duplication géographique de V. 14.2.4. Maintenance, sûreté de fonctionnement Des fonctionnalités connexes pour l'application mais essentielles pour le système peuvent apparaître dans les spécifications. Auto-tests, maintenance par exemple, sont des fonctions d'aide au diagnostic et au maintien en bon fonctionnement du système. 288 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION

Indépendant
V’ V F1 F2 F1

Dépendant

V" F2

Emission message

Reception message

E_MESS

R_MESS

Emission ligne

Reception ligne

TxD

-Figure 14.5- Indépendance/dépendance vis à vis de la répartition. La sûreté de fonctionnement, qui inclut au moins les termes disponibilité, fiabilité, peut nécessiter l'ajout de fonctions supplémentaires: redondances matérielles, logicielles, fonctionnelles par exemple. Toutes ces fonctions sont à prendre en compte à un stade ultérieur, car faisant partie des contraintes technologiques. Pour la sûreté, elles se déduisent à partir de la solution fonctionnelle par analyse des caractéristiques de sécurité, puis par ajout des redondances nécessaires pour satisfaire les critères imposés. L'exemple donné figure 14.6 montre l'ajout d'un auto-test à la mise sous tension et la duplication d'un capteur de température pour fiabiliser l'observation. Des états complémentaires sont ainsi ajoutés au système pour satisfaire les spécifications de nature technologique. 14.2.5. Importance des catégories de spécification La méthode préconisée pour l'élaboration des spécifications conduit à inclure les caractéristiques des interfaces physiques, le dialogue homme/machine, les contraintes de répartition, les contraintes de sûreté dans les spécifications technologiques. Nous venons d'en donner la justification. Ainsi, l'utilisation exclusive des spécifications fonctionnelles favorise la conception d'une solution indépendante de la technologie. Toutefois, il ne faut pas confondre niveaux de détails et dépendance technologique: une solution peut être particulièrement détaillée sur le plan fonctionnel sans toutefois exprimer des dépendances technologiques. M.C.S.E 289

Partie 4 - CONCEPTION FONCTIONNELLE

TEMP Environnement Traitement

Indépendant

DEFAUT

TM1 TEMP Environnement Observation TM TM2 ETAT_OK Traitement

Dépendant

Mise en marche Auto-Test

-Figure 14.6- Indépendance/dépendance vis à vis de la sûreté et maintenance. 14.3. COMPLEXITE MINIMALE ET INDEPENDANCE Une solution pour un système ou pour chaque fonction s'obtient par raffinement. Chaque décomposition doit se faire en respectant une règle de complexité maximale qui favorise la lisibilité et donc la compréhension. La règle de 7 plus ou moins 2 préconisée par plusieurs auteurs s'applique ici. Elle veut simplement dire qu'au delà de 8 à 10 éléments introduits dans un raffinement (fonctions + variables + ports + événements) la solution devient difficilement compréhensible. Mais comme le raffinement est itératif, on peut obtenir en final une solution extrêmement complexe par suite d'une multitude de niveaux. Il faut donc aussi disposer d'un critère d'évaluation de la qualité de la solution lorsque celle-ci est complètement mise à "plat", c'està-dire après retrait des niveaux. La complexité se doit d'être minimale. Comment peut-on l'obtenir? La réponse n'est pas unique. 14.3.1. Orthogonalité ou cohérence des fonctions La réduction de complexité s'obtient en recherchant un ensemble orthogonal de fonctions, chacune ayant une fonctionnalité spécifique indépendante des autres. Chaque fonction exploite et produit alors des données indépendantes entre elles. L'indépendance résulte du principe de l'encapsulation de sous-ensembles cohérents entre eux, ce qui conduit à définir des objets ayant des fonctionnalités propres. La complexité pour un problème donné dépend aussi de la nature du problème. Lorsqu’il s’agit d’un problème de contrôle, par exemple une automatisation, une approche basée sur les données peut conduire à une solution plus complexe qu'une approche basée sur les événements. 290 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION 14.3.2. Réduction des couplages L'analyse peut conduire à mettre en évidence un ensemble de fonctions et de données. La construction d'une structure fonctionnelle à partir de tout ou partie de ces éléments donne diverses solutions qui dépendent des regroupements effectués. Une solution fonctionnelle satisfaisante par un niveau donné de raffinement est celle qui a priori, minimise les couplages et donc les interfaces. Cette minimisation porte à la fois sur le nombre de couplages et sur la complexité de chaque couplage. La minimisation du nombre de couplages converge vers l'indépendance des parties. La compréhension d'une partie de la solution est d'autant plus simple qu'elle se trouve peu liée aux autres parties. La complexité de chaque couplage dépend: d'une part de la nature du couplage -variable d'état ou événement-, d'autre part de la structure de l'information échangée. Un couplage par événement ou par transfert de message est plus complexe qu'un couplage par variable, car il implique par la suite, dans la réalisation, une synchronisation des fonctions. Ce n'est pas le cas pour les variables. En final, une réalisation est d'autant plus simple que la partie organisationnelle représentant les couplages entre les fonctions autres que par variables est faible. La solution la plus intéressante est celle qui conduit à une partie organisationnelle la plus réduite. Ce point de vue sera développé dans la partie suivante qui concerne la définition de la réalisation. La complexité de l'information définie par une variable ou un message influe aussi sur la compréhension de la solution. 14.4. DEMARCHE POUR LA DEDUCTION D’UNE SOLUTION Débutant un travail de raffinement, le concepteur est face à une fonction définie uniquement par ses spécifications. A ce stade, cette fonction (plus ou moins complexe) est équivalente à une "boîte noire" quant à sa structure interne: aucune information interne connue. Raffiner, c'est trouver une description interne comme solution répondant aux spécifications. Cette solution doit de plus posséder des qualités. Certaines ont été détaillées dans les paragraphes précédents. Il s'agit donc d'une tâche créatrice. Comment faut-il s'y prendre? Plusieurs démarches sont possibles: intuition ou analyse, approche par les fonctions ou par les données, raffinement ou abstraction. 14.4.1. Analyse plutôt qu'intuition Concevoir est un processus créatif. Aussi peut-on se baser sur son intuition pour proposer une solution. Celle-ci doit ensuite être vérifiée pour assurer sa conformité aux spécifications. Beaucoup d'erreurs seront probablement à corriger et la justification des choix sera plutôt difficile. Selon cette démarche, avoir de l'expérience ou du "Métier" est sûrement plus favorable car, très sommairement, l'expérience se traduit par la connaissance de solutions pour des problèmes type. Intuition et expérience ont tendance à ne pas exploiter très directement les spécifications, ce qui conduit inévitablement à des difficultés. M.C.S.E 291

Partie 4 - CONCEPTION FONCTIONNELLE L'analyse est à opposer à l'intuition. Elle est basée sur une lecture détaillée, une interprétation "fine" des spécifications, l'emploi d'une méthode. Il se trouve que, dans la plupart des cas, les informations nécessaires qu'il s’agit de trouver pour proposer une solution sont dans les spécifications. En effet, spécifier c'est détailler l'application. Or ces détails sont indispensables en interne du système car une partie de celui-ci est le reflet de l'application. Ainsi, l'analyse réduit peut être le caractère créatif, mais conduit à une probabilité élevée de qualité de la solution, et ceci plutôt indépendamment de la qualité du concepteur. En fait, lorsque les spécifications sont correctement élaborées, une grande partie du travail de réflexion et de synthèse a déjà été entreprise durant la phase de spécification. Evidemment les spécifications sont nécessaires pour une démarche par analyse, ce qui n'est pas une condition nécessaire pour l'intuition. 14.4.2. Approche par les données plutôt que par les fonctions Par analyse, que faut-il tout d'abord rechercher dans le document de spécifications? 2 démarches sont à opposer: - recherche des fonctions, puis des relations, - recherche des données, puis des fonctions. La démarche par les fonctions est la plus conventionnelle et la plus naturelle. Ceci s'explique par le fait que pour décrire une tâche, notre raisonnement nous conduit naturellement à faire apparaître une séquence d'activités. Ceci est sûrement accentué avec l'informatique, car en programmation, les ordinateurs exigent que nous décomposions un objectif à atteindre en opérations plus élémentaires séquentielles. Nous avons eu l'occasion de vérifier à de multiples reprises auprès de concepteurs que, sans conseil particulier, ceux-ci proposent invariablement une décomposition basée sur les fonctions. Pour observer si une telle démarche a été suivie, il suffit simplement de regarder la structure fonctionnelle proposée. L'exemple suivant reflète une telle approche.

Prêt E S

F1
V1

F2

-Figure 14.7- Exemple de structure fonctionnelle basée sur les fonctions. Pour cette solution, en résultat de son travail d'analyse, le concepteur a trouvé que pour obtenir S à partir de E, il faut 2 fonctions: F1 effectuant une partie du traitement, F2 achevant la transformation. F1 et F2 étant séquentielles, la fin du traitement par F1 se traduit par la production de V1. L'événement PRET s'avère strictement nécessaire pour que F2 ne prenne en compte V1 que lorsque celle-ci est disponible après son dépôt par F1. La relation séquentielle pouvait ici s'exprimer par un transfert de message contenant V1 en utilisant un port comme intermédiaire. 292 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION Comme remarque essentielle à retenir, cette approche conduit invariablement à des synchronisations entre fonctions. Cette marque dans une structure fonctionnelle est le reflet de la démarche suivie par le concepteur. La démarche par les variables et donc par les relations plutôt que par les fonctions, donne un résultat bien différent. Pour la fonction à raffiner, le concepteur doit rechercher une ou des variables internes strictement nécessaires pour exprimer une solution. Ces variables se déduisent par lecture et interprétation des spécifications. Une fois trouvée au moins une variable, il faut ensuite déduire au moins 2 fonctions, sinon cette variable n'apporte rien dans le raffinement fonctionnel. Selon cette approche, on retrouve habituellement une structure fonctionnelle conforme à la suivante.

E

S

F3
V2

F4

-Figure 14.8- Exemple de structure fonctionnelle basée sur les variables. La variable V2 n'a rien à voir avec la variable V1 de la figure précédente de même pour F3 et F4 par rapport à F1 et F2. Ici, la variable a une signification de permanence, ce qui n'est pas le cas pour V1. V2 étant permanente, les 2 fonctions F3 et F4 sont asynchrones. Aucune synchronisation n'apparait, ce qui facilite la compréhension puis par la suite l'implantation. Cette approche ne conduit pas à une solution séquentielle mais à une solution possédant un parallélisme naturel. Or c'est bien l'objectif d'une structure fonctionnelle que d'exprimer un parallélisme, sinon la décomposition ne s'avère pas nécessaire. Ainsi, cette méthode de décomposition par les données devra être utilisée pour aboutir à une solution simple. 14.4.3. Raffinement plutôt qu'abstraction Le modèle fonctionnel est hiérarchique. Une solution peut aussi bien s'obtenir par composition de fonctions plus élémentaires que par décomposition. Même si la démarche purement descendante est difficile, la recherche de solutions par raffinement est préférable à la démarche ascendante par regroupement. En effet, la solution recherchée doit satisfaire une spécification. Dans la démarche descendante, chaque fonction à décomposer est définie par une spécification; par analyse, le travail de décomposition est simple et la vérification est aussi possible. Selon une démarche ascendante, l'abstraction conduit à identifier une fonction par regroupement de fonctions plus élémentaires. Elle peut alors se décrire par sa spécification. C'est une démarche qui ne part pas de l'objectif, mais qui cherche à converger vers l'objectif, ce qui est moins simple et probablement conduit à plus d'hésitations et donc à un travail plus important. M.C.S.E 293

Partie 4 - CONCEPTION FONCTIONNELLE Il est donc conseillé de travailler surtout par raffinement, sachant toutefois que des retoursarrières restent nécessaires pour corriger des erreurs d'analyse détectées par la suite. 14.5. DECOMPOSITION VERTICALE OU HORIZONTALE Le modèle fonctionnel est hiérarchique. Ainsi, chaque fonction non-élémentaire se décrit par une structure fonctionnelle. Dans ce travail de raffinement, la structure fonctionnelle retenue peut correspondre à 2 types de décomposition [ROTENSTREICH-86]: - une décomposition horizontale, - une décomposition verticale. La décomposition dite horizontale est la plus habituelle. Elle revient à considérer que toutes les fonctions du raffinement participent sur un même niveau fonctionnel à la réalisation de la fonction du niveau supérieur. Les relations entre les fonctions ont la même signification que l'organisation fonctionnelle dans les entreprises. Chaque fonction contribue sur le même plan à l'obtention du résultat. Les relations expriment les transformations des entrées vers les sorties.

E F

S

V1 F3 F1 E Ev F2 V2 S

-Figure 14.9- Représentation d’une décomposition horizontale. Toutes les fonctions de F sont représentées dans un même plan horizontal. Les classes de fonctions pour cette décomposition, assurent: - la structuration par enrichissement (ajout de nouvelles fonctionnalités) ou déduction de fonctionnalités plus élémentaires, - l'introduction de vues moins abstraites de la solution. La décomposition verticale correspond à une relation hiérarchique. Pour assurer son rôle, une fonction peut avoir besoin de services d'un niveau hiérarchique inférieur. Les fonctions sont plutôt du type adaptation pour satisfaire une contrainte. Par exemple, une fonction de transmission de messages doit utiliser un service de transmission de caractères. Cette décomposition peut se représenter comme suit, qui montre que les relations se représentent dans un plan vertical. 294 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION

Ordre

CR

Services applications Niveau i

Emission message

Reception message

Raffinement

E_MESS

S_MESS

Services Messages

Niveau i -1

-Figure 14.10- Représentation d'une décomposition verticale. Il ne faut pas confondre les niveaux du raffinement qui n’ont de signification que pour la présentation favorisant ainsi la lisibilité, et les niveaux d'une décomposition verticale qui correspondent à des services de natures différentes. 14.6. MODELES GENERIQUES DE SOLUTIONS Face à une tâche de raffinement, le concepteur, même après analyse, dispose de degrés de liberté importants pour proposer une solution. Au travers de l'analyse, il peut aussi éprouver des difficultés à extraire les éléments essentiels. L'approche par les variables n'est en plus pas tout à fait naturelle. Peut-on contribuer à améliorer la qualité du travail de conception en plus des principes énoncés précédemment? Il est indéniable que naturellement, le concepteur travaille par analogie. Lorsqu'il a déjà traité un problème similaire, ou lorsqu'il dispose de solutions, il cherche, ce qui est tout à fait louable, à réutiliser l'existant. Ceci est une forme de ce qui peut s'appeler l'EXPERIENCE. Partant de ce point de vue, nous nous sommes demandés s'il n'était pas possible, par analyse d'une grande variété de solutions obtenues par application de la méthodologie MCSE, de mettre en évidence un certain nombre de solutions générales. Ces solutions sont à comprendre comme des modèles génériques de solutions. Un modèle est approprié à une classe de problèmes et à un niveau donné de fonctionnalités. Il permet d'induire une collection de solutions, chacune personnalisée aux spécificités de l'application traitée, mais possédant toutes les propriétés et qualités du modèle. Ce n'est pas l'objectif de ce paragraphe que de décrire les modèles génériques recensés, ceci fait l'objet du chapitre 16. Toutefois, pour saisir l'idée, prenons l'exemple du modèle générique qu'est la Machine de MOORE pour la conception de fonctions numériques. M.C.S.E 295

Partie 4 - CONCEPTION FONCTIONNELLE Face au problème de conception d'une fonction numérique spécifiée par un diagramme à états finis, plutôt que de rechercher une solution intuitive, le concepteur va s'inspirer de la structure de la machine de MOORE. Le modèle lui suggère de rechercher la variable interne strictement nécessaire qu'est l'état interne. Cet état interne est défini directement par la spécification: état du diagramme à états finis par exemple.
Fonction à concevoir
Ev

Spécification

Modèle générique
CLK

Spécification de VI

VI F1 F2

VI Et

Reg

St F1 F2

Solution

-Figure 14.11- Exemple d'apport d'un modèle générique. Une fois trouvée cette variable interne, la structure fonctionnelle étant définie par le modèle générique, le travail de conception se trouve ramené à la résolution de 2 problèmes combinatoires: fonction combinatoire d'entrée ou réceptivité, fonction combinatoire de sortie ou d'action, chacune étant alors spécifiée par la table de transition. La recherche de ces modèles nous a permis d'en formaliser plusieurs et de les expérimenter auprès de groupes de concepteurs. L'expérience de comparaison des résultats est simple. Elle consiste à comparer les solutions produites avec et sans la connaissance de modèles génériques. Nous-mêmes avons pu comparer pour des mêmes problèmes les solutions proposées avant l'emploi des modèles et plus tard avec ces modèles. Les résultats obtenus jugés sur les critères: adéquation aux spécifications, simplicité et lisibilité, sont nettement en faveur de l'emploi de modèles génériques. Ceci s'explique puisque ces modèles sont des générateurs d'idées et de "bonnes" questions. 14.7. RESUME En synthèse de ce chapitre qui a permis de mettre en évidence différentes alternatives en conception fonctionnelle, sont reprises les conclusions essentielles à suivre: - la conception doit être guidée par le sujet de l'application. Cette approche favorise la démarche de décomposition des entrées vers les sorties (décomposition horizontale). - une conception fonctionnelle doit être indépendante de la technologie. Pour cela, il ne faut utiliser que les spécifications fonctionnelles. Les problèmes d'interfaçage avec l'environnement et avec les utilisateurs, les contraintes de répartition géographique, ne sont pas à prendre en compte à ce stade. 296 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION - la solution fonctionnelle doit posséder des qualités de simplicité pour sa compréhension et sa réalisation. Pour cela, il faut chercher à réduire la complexité en nombre et nature des fonctions et des relations. Effectuer pour cela une approche basée sur l'orthogonalité et la cohérence des fonctions et des données. - par analyse des spécifications, la déduction d'une solution doit se faire en recherchant des informations (variables, événements) internes strictement nécessaires pour exprimer la solution et ceci selon une démarche descendante par raffinement. - le concepteur pourra s'inspirer de modèles génériques de solutions comme guide pour le travail d'analyse et de synthèse.

M.C.S.E

297

Chapitre 15

DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

Pour l'étape de conception fonctionnelle, l'objectif est de proposer une solution complète conforme aux spécifications et possédant des qualités qui auront des répercussions favorables sur l'ensemble du cycle de vie du produit. Les applications à développer, exprimées par leurs spécifications, sont forcément variées. Pour une application donnée décrite par une spécification précise, les solutions peuvent aussi être très diverses. Le travail de conception étant essentiellement un processus créatif, le résultat est une expression de la réflexion du concepteur. Une production de solution selon un processus automatique n'est pas pour tout de suite; il faudrait au préalable arriver à formaliser complètement toutes les règles de production. En résultat de la conception, l'important est le document qui en final décrit la solution et pas le cheminement suivi par le concepteur [PARNAS-85]. Toutefois, le résultat est d'une certaine manière le reflet des principes et démarche suivis. Ainsi, la COMPETENCE et la RIGUEUR de REFLEXION du concepteur restent des facteurs importants d'influence sur la qualité du résultat. Ce chapitre a pour objectif de détailler la démarche préconisée, de manière à aider le concepteur à acquérir cette compétence et la rigueur de réflexion. Cette démarche explicite l'enchaînement des décisions à prendre pour s'assurer d'un résultat de qualité. Disposant du modèle fonctionnel, la démarche est la juxtaposition de phases, chacune servant à déduire une composante du modèle. Les principes en conception énoncés dans le chapitre précédent servent à définir les conseils pour chaque phase.

M.C.S.E

299

Partie 4 - CONCEPTION FONCTIONNELLE Le bien fondé d'une démarche ne se prouve pas formellement. Il résulte plus d'une observation à faire sur les expérimentations. Pour cela, il faut traiter une variété de problèmes industriels, et par analyse, déduire les apports et difficultés. L'élaboration d'une démarche est donc très lente et résulte d'une synthèse selon une progression ascendante. 15.1. PRESENTATION DE LA DEMARCHE La deuxième étape appelée conception fonctionnelle a pour objectif de produire une description fonctionnelle complète du système à concevoir. Conforme au modèle, cette description doit être composée: - d'une structure fonctionnelle, - des spécifications comportementales de toutes les fonctions élémentaires, - des spécifications de toutes les données. Les documents à considérer en entrée sont les spécifications fonctionnelles et opératoires. La figure ci-dessous symbolise cette étape.
Modèle fonctionnel

Spécifications fonctionnelles et opératoires

ETAPE DE CONCEPTION FONCTIONNELLE

Document de conception fonctionnelle

Modèles génériques

-Figure 15.1- L'étape de conception. La démarche préconisée procède par raffinements successifs de chaque fonction, le point de départ étant le système dans sa globalité, délimité par ses entrées et ses sorties. Le processus de raffinement s'arrête lorsque chacune des fonctions peut se décrire par une modélisation comportementale séquentielle. Les données sont spécifiées au fur et à mesure de leur apparition pour chaque niveau de raffinement. Ainsi la démarche représentée figure 15.2 consiste à suivre les phases suivantes: 300 délimitation des entrées et sorties du système, recherche d'une première décomposition fonctionnelle, raffinement de chaque fonction (itération sur cette phase), comportement de chaque fonction élémentaire, synthèse de la solution globale. M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

Document de spécifications Délimitation des entrées sorties

Première approche fonctionnelle

première décomposition fonctionnelle

Raffinement fonctionnel

Description algorithmique

Raffinement et description des fonctions
Document de conception fonctionnelle Structure fonctionnelle finale

Synthèse

-Figure 15.2- Enchaînement des phases pour la conception fonctionnelle. Comme le modèle fonctionnel est hiérarchique, le premier niveau de la décomposition fonctionnelle est très important, car il induira par la suite toute la structure de la solution. Il faut donc apporter un soin particulier pour cette première approche de la solution. Le raffinement fonctionnel de chaque fonction est un processus itératif qui peut se faire selon un ordre a priori quelconque pour les différentes branches de la hiérarchie. Toutefois, il est toujours conseillé de s'attaquer d'emblée aux fonctions les plus difficiles plutôt que l'inverse. En effet, la solution trouvée pour une fonction complexe peut avoir des répercussions sur son environnement. Une fois toutes les décompositions réalisées, une synthèse globale se justifie pour s'assurer de la cohérence de l'ensemble. Il est vrai qu'une démarche purement descendante est très difficile à suivre. Des retours-arrières et corrections sont inévitables en cours de conception. D'où la nécessité de revoir l'ensemble. Le document produit en sortie résulte de cette synthèse. Pour chaque phase de raffinement, le concepteur doit procéder selon 3 phases: - analyse: il s'agit de faire apparaître les éléments essentiels à partir des spécifications, - construction: ce travail de synthèse propose une solution sur la base des éléments mis en évidence par l'analyse. Plusieurs solutions sont envisageables, la sélection est alors basée sur divers critères, - vérification: elle consiste à s'assurer que la solution retenue pour la fonction répond aux spécifications du système. Si au préalable du raffinement une spécification est exprimée, le travail de vérification se trouve facilité. M.C.S.E 301

Partie 4 - CONCEPTION FONCTIONNELLE La phase de vérification peut faire apparaître des oublis qui sont à corriger en revenant sur la phase précédente de construction. Si la démarche est trop incrémentale ou trop intuitive, la solution résulte plus d'un processus d'essais et corrections d'erreurs. Elle résulte d'une insuffisance de la phase d'analyse. Dans ce cas, une fois élucidés tous les problèmes, il est judicieux de reprendre globalement la construction puis la vérification pour améliorer la solution. Chaque phase de la méthode est détaillée dans les paragraphes suivants. Au préalable, des précisions sont données sur les informations en entrée de l'étape et le résultat attendu. 15.2. DOCUMENTS EN ENTREE ET EN SORTIE DE L’ETAPE Le travail de conception, tout comme celui de spécification, consiste à élaborer un document papier. Evoquons le contenu des documents en entrée et en sortie. 15.2.1. Document de spécification Pour l'étape de conception, les parties utiles du document de spécification sont: - la délimitation système/environnement, - les spécifications fonctionnelles, - les spécifications opératoires. La délimitation du contexte du système permet de déduire une délimitation du système avec ses entrées et ses sorties. Les échanges entre les 2 parties sont de nature logique ou fonctionnelle, et pas physique. Les spécifications fonctionnelles définissent les fonctions du système pour le sujet de l'application. Il s'agit donc de renseignements orientés sujet, et donc favorables pour une conception orientée sujet. Le rôle de chaque fonction est explicité par un ou des modèles de spécification exprimant le comportement des entités de l'environnement (donc du sujet). Les spécifications opératoires explicitent les grandeurs, les données, ainsi que leurs attributs. Si une méthode de résolution du problème est suggérée ou imposée, elle se trouve décrite dans cette partie des spécifications. Ces 3 catégories d'informations n'incluent aucun renseignement de nature physique ou technologique. Un tel document favorise donc l'approche orientée sujet d'une part, l'approche orientée données plutôt que fonctions d'autre part, car il n'est pas fait état des fonctions internes, mais uniquement des fonctionnalités pour l'application. 15.2.2. Document de conception Fort probablement la démarche ne sera pas totalement linéaire et descendante. Le document de conception doit exprimer le résultat, et ceci de manière linéaire et descendante. Pour l'exploitation ultérieure, la compréhension et l'acceptation de la pertinence des solutions, seul le résultat est important. Ainsi le document de conception ne suit pas le déroulement temporel des développements entrepris par les concepteurs. C'est une synthèse hiérarchisée et logique décrivant la solution qui n'a de cohérence qu'une fois achevée la synthèse globale. Pour chaque raffinement, on doit retrouver en plus de la description complète de la solution, l'analyse qui a conduit à diverses alternatives, les critères de décision qui ont amené à retenir une solution parmi celles possibles. 302 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE Le document est donc aussi une trace des réflexions du concepteur. Ceci permet pour d'autres applications une certaine réutilisation du travail entrepris, pour le concepteur luimême, mais aussi et peut-être surtout pour la formation de nouveaux concepteurs. Si le document est le résultat de la synthèse, celui-ci se doit toutefois d'être construit au fur et à mesure du développement. Non-ordonnés avant le stade final, les points importants sont mémorisés au fur et à mesure. Sinon, chacun sait que le temps assure un effet d'oubli conduisant alors à une vision particulièrement limitée et donc à un document sans valeur. Le travail de synthèse consiste donc à ordonner tous les éléments de la conception, éliminer les parties inutiles et les retours-arrières qui furent nécessaires pour les corrections, introduire une cohérence pour l'ensemble. 15.3. DELIMITATION DES ENTREES ET SORTIES Il s'agit tout d'abord de définir avec précision la séparation entre le système à concevoir et les entités de son environnement. Les entités sont représentées par des formes en "nuage", tandis que le système est représenté par un rectangle. Le couplage entre les 2 parties se fait uniquement par les 3 types de relations du modèle fonctionnel comme le montre l’exemple ci-dessous.

Ordre

Reaction

E1
SYSTEME A

E1

CONCEVOIR INC

I

E2

E2

-Figure 15.3- Exemple de délimitation du système. 15.3.1. Démarche Les observations possibles sur les entités peuvent servir d'entrées pour le système. De même, aux grandeurs de commande pour les entités vont correspondre des sorties du système. Observations et grandeurs de commande apparaissent dans les spécifications. Ces grandeurs sont de nature fonctionnelle et non pas physique lorsque les spécifications sont correctement établies. Il faut ensuite définir le type de relation. Le choix découle de la nature des grandeurs. Les règles à suivre sont simples: - Lorsque seul un changement d'état d'une variable ou d'une grandeur est utile, la relation est du type événement. - Lorsque l'apparition d'une information et son contenu sont à considérer simultanément, la relation est du type transfert de messages. - Lorsque la valeur d'une information est nécessaire quel que soit l'instant, la relation est du type variable d'état. M.C.S.E 303

Partie 4 - CONCEPTION FONCTIONNELLE La nature de la relation se déduit aussi de la spécification. Par exemple, un lien du type flot de données conduit à une relation par port. Pour compléter la délimitation, chacune des variables d'état et chaque type de messages doivent être spécifiés. A noter que cette phase peut conduire à oublier des entrées comme observations nécessaires pour satisfaire les spécifications. Normalement, ces observations sont utilisées dans les spécifications, par exemple comme condition de transition. Un tel oubli sera probablement détecté au plus tard au moment des décompositions fonctionnelles. Un retour arrière permettra alors d'assurer la correction. Pour favoriser la lisibilité, toutes les entrées du système sont placées à gauche, les sorties à droite. Des entrées et sorties de nature identique, provenant de plusieurs instances d'un même type d'entité peuvent se représenter par un vecteur. Illustrons cette phase par les 2 exemples spécifiés dans la partie 3. 15.3.2. Exemple 1: Contrôle en vitesse d'un centrifugeur La spécification pour cet exemple est rappelée ci-dessous. Voir les spécifications dans le chapitre 12 en 12.6.4 comme rappel du problème.
Système pour l’utilisateur Système + Moteur

Repos début cycle T:=0

Repos

Vmoteur = 0 Erotation = arrêt

ORDRE ORDRE ? marche /si Erotation = arrêt alors début cycle; arrêt /si Erotation = rotation alors arrêt cycle; consigne /si Erotation = arrêt alors Vrot:=consigne;

CV tel que Vmoteur = Vrot * T Erotation = rotation AccéléraTm tion T >= TM T:=0 CV tel que Vmoteur = Vrot vitesse constante arrêt cycle Vm:=Vmoteur; T:=0;

T>= TC ou arrêt cycle T:=0; Vm:=Vmoteur; décéléraCV tel que tion Vmoteur = Vm - Vrot * T TD Vmoteur # 0

Couplage

-Figure 15.4- Spécification fonctionnelle pour la commande du moteur. Analysons cette spécification pour déduire les entrées, les sorties et les types de relations. L'utilisateur génère les événements que sont MARCHE et ARRET et fournit lorsqu'il le désire une nouvelle consigne de vitesse (CONSIGNE). Le couplage doit être du type événementiel avec transfert de données pour la consigne. 304 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE L'utilisateur est aussi observateur à tout instant de la consigne courante pour la vitesse et d'une indication si le moteur tourne ou ne tourne pas. Ces grandeurs sont du type variable d'état. L'ensemble tournant pour la centrifugation est caractérisé par sa commande CV et sa vitesse de rotation VMoteur. Ce sont des variables d'état. La délimitation des entrées-sorties du système est donc la suivante :

VROTATION Ordre Utilisateur SYSTEME A CONCEVOIR EROTATION Utilisateur

VMOTEUR Moteur

CONTROLE EN VITESSE D’UN CENTRIFUGEUR

CV Moteur

-Figure 15.5- Délimitation du Système pour le contrôle en vitesse. Pour compléter cette phase, toutes les variables doivent être spécifiées: ORDRE = [MARCHE | ARRET | CONSIGNE: 0..VMAX]; VROTATION : 0..VMAX; EROTATION : (rotation, arrêt); VMOTEUR : 0..VMAX; CV : 0..CVMAX; Le couplage entre l'utilisateur et le système est de nature fonctionnelle et non pas physique. Il était possible de considérer dès le départ les organes physiques mis à la disposition de l'utilisateur pour agir sur le système: boutons-poussoirs MARCHE, ARRET, PLUS et MOINS pour le réglage de la consigne. L'intérêt de la solution retenue ici est de pouvoir changer par la suite la nature du dialogue: remplacer les touches + et - par un clavier numérique, même par une liaison série pour une commande à distance. 15.3.3. Exemple 2: Automatisation par chariot filoguidé Les spécifications pour ce problème ont aussi été décrites dans le chapitre 12 en 12.10.2. Quatre entités ont été recensées dans l'environnement: - le QUAI en tant que donneur d'ordre, - le CHARIOT comme ensemble mécanique assurant le déplacement et le chargement, - l'ATELIER comme support sur lequel se déplace le chariot, - l'EXPLOITANT chargé de la bonne marche de l'installation. Pour ce problème, on s'intéressera uniquement au chariot et à son électronique de commande. La seule fonction du système de commande du chariot est de réaliser les cycles de transfert des paquets entre les 2 quais. Le lecteur doit se reporter au chapitre 12 pour reprendre connaissance des spécifications du problème. M.C.S.E 305

Partie 4 - CONCEPTION FONCTIONNELLE Partant des entités, analysons la spécification de manière à déduire les entrées et les sorties du système électronique à concevoir. Le QUAI est générateur d'événements qui sont des ordres pour le chariot. En réponse, il est sensible aux réactions du chariot. Les ordres et compte-rendus nécessaires apparaissent sur la spécification, pour les premiers comme actions du quai et conditions pour le chariot, pour les autres comme actions du chariot et condition pour le quai. La relation de couplage est donc du type transfert de messages (ORDRE et CR). Le CHARIOT, pour la partie mécanique qui assure le déplacement, est commandé pour le déplacement, par les consignes de vitesse des 2 moteurs CVM1 et CVM2, et pour la rotation du tapis par une variable logique C_TAPIS fixant les 2 états possibles. Pour l’instant il n'est pas fait état d'observations sur le chariot. L'ATELIER définit la trajectoire que doit suivre le chariot entre les 2 quais. La commande du chariot tiendra compte de la distance du chariot par rapport à cette trajectoire (DCA). L'atelier est aussi parsemé d'obstacles mobiles qui doivent être évités. L'information OBSTACLE en proximité du chariot et sur sa trajectoire est nécessaire pour le bon fonctionnement. En fonctionnement normal, l'EXPLOITANT n'a pas d'action directe sur le système de commande du chariot. Celui-ci n'est piloté que par le quai. Par contre, si un incident apparait obstacles, pas de réponse du quai ou du chariot - l'exploitant est prévenu par une sirène. Il repositionne alors le chariot et réinitialise le système de commande. Une analyse complémentaire est à faire à partir de la spécification, à savoir que toutes les conditions de transition autres que des évaluations possibles par le système doivent être fournies par l'environnement et donc par les entités. On trouve en particulier les états ou événements: présence_quai, proximité_quai. Ces 2 observations sont nécessaires pour la réalisation du système. Elles proviennent de l'atelier. Toutes les autres conditions sont des ordres, ou des comptes-rendus, ou des conditions temporelles. La délimitation du système avec ses entrées-sorties est donnée figure 15.6. Pour compléter cette phase, toutes les variables et messages sont à spécifier. ORDRE = [I_PRESENCE | CHARGEMENT | TRANSPORT | DECHARGEMENT]; CR= [OK_PRESENCE]; OBSTACLE, SON_SIRENE : booléen; C_TAPIS : (arrêt, arrière, avant); DCA : -Dmax..+Dmax; Il est évident que des informations de couplage manquent entre le chariot et le système de commande. La démarche volontairement suivie dans ce chapitre montrera que ces manques apparaîtront dès la conception . 306 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

ORDRE

CR

Quai
SON_SIRENE

Quai

Exploitant
OBSTACLE COMMANDE

Atelier
DCA

DU CHARIOT C_TAPIS FILOGUIDE CVM1 CVM2

Chariot

Chariot

-Figure 15.6- Délimitation du système de commande du chariot. 15.4. RECHERCHE D’UNE PREMIERE DECOMPOSITION FONCTIONNELLE Jusqu'à ce stade, aucune information interne au système n'est connue. Le concepteur doit commencer à proposer les premiers éléments fonctionnels nécessaires pour résoudre le problème. Rappelons les points essentiels pour entreprendre ce travail. Tout d'abord, la solution proposée doit être conforme au modèle fonctionnel, et plus particulièrement au modèle de structure fonctionnelle puisque fort probablement une décomposition est nécessaire. Le modèle étant hiérarchique, il faut limiter chaque décomposition à une solution compréhensible. Ensuite, l'approche doit être orientée sujet. La démarche propose de rechercher des variables, informations, événements, internes strictement nécessaires, plutôt que de rechercher des fonctions internes. La solution doit rester indépendante de la technologie. Mais attention, la première décomposition est très importante et a une influence considérable sur le reste du développement et donc par incidence sur l'ensemble du coût du projet. Détaillons plus particulièrement ce point avant de présenter la méthode de recherche d'une solution selon les 3 phases: analyse, construction, vérification. 15.4.1. Importance de la première décomposition fonctionnelle La démarche préconisée est globalement descendante. Ainsi chaque niveau de description est détaillée en raffinant chacune des fonctions du niveau précédent. Ceci découle de la nature hiérarchique du modèle. Cette technique s'applique pour la conception fonctionnelle, mais aussi en partie pour la définition de la réalisation, tout particulièrement pour l'introduction des interfaces et de la répartition géographique. Les implantations matérielle et logicielle résultent de transformations appliquées sur la solution fonctionnelle détaillée. M.C.S.E 307

Partie 4 - CONCEPTION FONCTIONNELLE Bien entendu, des corrections de solution et retours-arrières sont toujours possibles lorsque des défauts ou erreurs apparaissent: incohérence, non-respect des spécifications. Toutefois, il faut être conscient que la technique de raffinement tend à conserver la structure de départ. Ainsi, une fois la première décomposition fonctionnelle choisie, celle-ci va se retrouver dans la solution finale. Ce premier choix est donc particulièrement important et va influencer la complexité du projet et donc son coût. Comme la solution pour une première décomposition est loin d'être unique, il est utile de disposer d'un critère d'évaluation de sa qualité, qui tient compte des conséquences en aval. Un tel critère n'est pas simple à exprimer. Intéressons-nous au produit final pour esquisser un tel critère. La réalisation dans les cas les plus usuels est composée d'une partie matérielle et d'une partie logicielle. Le coût pour la partie matérielle dépend de la quantité à produire: - de nombreuses pièces: intérêt de réduire le coût de reproduction en minimisant le matériel. Ceci s'obtient en reportant le maximum de fonctionnalités sur la partie logicielle, - quelques installations: intérêt de réduire le temps de développement à la fois pour le matériel et pour le logiciel. Ainsi la minimisation de la complexité fonctionnelle favorise la minimisation du coût pour le matériel. Le coût pour la partie logicielle peut se décomposer en 2 parties: - la partie OPERATOIRE, qui regroupe toutes les opérations nécessaires pour satisfaire l'application. Cette partie opératoire se trouve minimisée si les descriptions algorithmiques des fonctions sont élaborées avec soin et sans redondance. On peut considérer dans ce cas que cette partie est relativement imcompressible. - la partie ORGANISATIONNELLE, qui assure le couplage entre tous les modules, fonctions, procédures logicielles. Cette partie résulte de transformations appliquées sur la structure fonctionnelle. Ainsi, cette partie sera le reflet de la complexité fonctionnelle. La réduction du développement pour le logiciel passe donc essentiellement par la réduction au maximum de la partie organisationnelle, ce qui implique de réduire au moins dès le départ la complexité fonctionnelle. La complexité dépend de la nature des relations fonctionnelles. Les relations par partage de variables n'engendrent pas de "coût" organisationnel, contrairement aux relations par synchronisation et transfert de messages qui elles engendrent des dépendances temporelles. Ainsi, l'objectif pour le critère de qualité consiste à utiliser comme couplage entre les fonctions, de préférence les couplages par variables plutôt que les couplages par synchronisation et transfert de messages par port. Ce raisonnement est à tenir pour tous les niveaux de raffinement. La répercussion est d'autant plus importante qu'il s'agit des tous premiers niveaux définissant l'architecture globale de la solution. 15.4.2. Démarche pour élaborer une solution Plutôt que de se fier à son intuition, il est suggéré de procéder en 3 temps: analyse, élaboration d'une solution (ou de plusieurs) par construction, vérification. 308 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE
-A- ANALYSE

L'analyse consiste à exploiter les spécifications et à extraire de celles-ci les éléments essentiels qui peuvent être utiles pour la solution. Une lecture attentive permet d'extraire: des mots, des phases, des actions, des événements, des données. Une classification par ordre d'importance conduit à affiner l'analyse. Des modèles d'analyse sont aussi utilisables pour cette tâche. On peut citer tout particulièrement la méthode "Structured Analysis" basée sur les diagrammes flots de données. Un tel modèle est alors utilisé pour exprimer les transformations successives pour passer des entrées aux sorties. Les informations intermédiaires apparaissent alors comme utilisables pour exprimer la solution. L'analyse doit être conduite de manière à rechercher les données et les événements strictement nécessaires, plutôt que les activités, opérations, fonctions qui, elles, découlent des précédentes.
-B- CONSTRUCTION

Une solution s'élabore en plaçant des éléments caractéristiques dans la partie à raffiner. Si l'analyse est orientée données, les éléments à placer sont des variables ou des événements avec ou sans information. Comme ces éléments doivent obligatoirement appartenir à des relations, il faut alors placer autour de celles-ci des fonctions, certaines pour produire et mettre à jour, d'autres pour les exploiter. Il faut ensuite compléter la structure fonctionnelle de manière à utiliser toutes les variables d'entrée et toutes les variables de sortie. Si certaines apparaissent inutiles, le niveau supérieur doit être revu. Enfin, tous les constituants doivent être correctement nommés, puis spécifiés. En particulier, la spécification de chaque fonction servira ensuite comme document d'entrée pour son raffinement. Ainsi cette démarche de construction incrémentale par les variables est simple et conduit à une faible complexité de chaque raffinement. En effet, il suffit de trouver une seule variable, un événement, ou une information pour exprimer une solution. Ce seul élément va induire obligatoirement par sa relation au moins 2 fonctions. Le bon choix de l'élément apparait donc essentiel, d'où l'importance de la phase précédente d'analyse. Comme la solution est loin d'être unique, il est conseillé d'envisager plusieurs décompositions fonctionnelles. Le choix d'une solution parmi l'ensemble est alors basé sur le critère décrit dans le paragraphe précédent. Si le choix ne s'avère pas évident, il est souhaitable de conduire le raffinement de chaque solution jusqu'au stade où une solution se dégage comme étant la meilleure. Durant la conception fonctionnelle, il ne faut pas non plus hésiter à mettre en cause sa solution, car le gain sur le reste du développement peut être tout à fait notable.
-C- VERIFICATION

Une fois exprimée une solution, il faut s'assurer qu'elle va permettre de satisfaire les spécifications. L'affirmation: la solution satisfait les spécifications, n'est pas possible, puisque en cours de raffinement, tous les éléments de la solution ne sont pas encore identifiés et spécifiés. La vérification complète qui peut garantir, alors appelée validation, n'est possible qu'à la fin de la conception fonctionnelle. M.C.S.E 309

Partie 4 - CONCEPTION FONCTIONNELLE La vérification préconisée ici, consiste à éliminer les erreurs flagrantes qu'il faut éviter de propager. Pour cela, il s'agit de s'assurer: que toutes les entrées et sorties sont utilisées, que les relations entre les fonctions sont de type correct, que chaque fonction compte-tenu de son caractère permanent ou temporaire est capable de produire ses sorties à partir de ses entrées. Une vérification faite par une personne autre que le concepteur lui-même est aussi un bon moyen pour réduire les erreurs. Ceci justifie l'intérêt du cycle Auteur-lecteurs applicable pour tout document. Illustrons la démarche en 3 phases sur les 2 exemples à traiter. 15.4.3. Exemple 1: contrôle en vitesse d’un centrifugeur
-A- ANALYSE

L'analyse porte sur l'observation des caractéristiques que doivent suivre les entités de l'environnement (approche sujet). C'est le cas du moteur qui va être contraint par le système, et pas l'utilisateur qui lui est le donneur d'ordres. Le moteur doit respecter un profil de vitesse quelle que soit la charge entrainée. La consigne de vitesse fixée par l'utilisateur est donc une grandeur essentielle pour l'application. Le couplage entre les entités: l'utilisateur et moteur, se fait dans un sens par les événements Marche et Arrêt, dans l'autre sens par l'état Rotation ou Arrêt du moteur.
-B- CONSTRUCTION

L'analyse a mis en évidence des éléments essentiels qui peuvent se traduire par 3 variables: - CROTATION: 0..VMAX, pour la consigne de vitesse demandée (VROT dans la spécification), - M/A: (Marche, Arrêt), qui permet d'induire les 2 événements Début_cycle et Arrêt_cycle, - ETAT : (Rotation, Arrêt), comme observation de l'état du moteur. La structure fonctionnelle ci-dessous est élaborée autour de ces 3 variables.

VROTATION ORDRE GESTION CENTRIFUGEUR

M/A

ETAT

CROTATION

EROTATION

VMOTEUR CONTROLE VITESSE CV

Contrôle en vitesse centrifugeur

-Figure 15.7- Première décomposition fonctionnelle. 310 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE
-C- VERIFICATION

Il s'agit de parcourir la spécification fonctionnelle et de s'assurer que toutes les conditions de transition existent et que toutes les actions sont possibles. Pour GESTION_CENTRIFUGEUR, les 2 ordres MARCHE et ARRET vont servir à modifier l'état de M/A. L'ordre CONSIGNE va provoquer la modification de la visualisation et la mise à jour de CROTATION. L'observation de l'état du moteur par ETAT permet de valider un nouveau cycle et d'informer l'utilisateur de la fin de rotation. La fonction CONTROLE_VITESSE est capable d'assurer sur demande, quand M/A = marche, la commande du moteur selon le gabarit imposé avec comme vitesse constante CROTATION. M/A doit être remis à Arrêt en fin de cycle, ce qui justifie le lien bidirectionnel. La solution pour cet exemple reste relativement macroscopique, puisque les 3 phases accélération, vitesse constante, décélération n'apparaissent pas. Le raffinement doit rester très incrémental pour favoriser la qualité. 15.4.4. Exemple 2: Automatisation par chariot filoguidé
-A- ANALYSE

En partant des entités, on trouve une certaine similitude de comportement entre le chariot et le moteur de l'exemple précédent. Il faut respecter un profil de vitesse avec phase d'accélération, vitesse constante, phase de décélération. Mais ici la valeur pour la vitesse constante n'est pas modifiable. Cette grandeur n'est donc pas essentielle. L'analyse du comportement imposé pour le chariot met en évidence 2 catégories de phases: déplacement et les autres. Chaque déplacement est caractérisé par les instants de début et de fin .
-B- CONSTRUCTION

De cette analyse, et au vu de l'exemple précédent, 2 variables sont nécessaires: - M/A: (MARCHE, ARRET), pour déclencher ou arrêter un déplacement - ETAT: pour synthétiser toutes les informations concernant le déplacement. La structure fonctionnelle proposée est donnée figure 15.8. La partition en 2 fonctions n'est pas unique. Les fonctionnalités de ces fonctions diffèrent selon les entrées utilisées pour chacune: par exemple les variables OBSTACLE et POSITION_QUAI au niveau de la SUPERVISION plutôt que liées à la partie commande conduisent à un rôle différent des fonctions. La commande C_TAPIS est liée à SUPERVISION. Sinon, il faut des informations de couplage supplémentaires.
-C- VERIFICATION

Vu la simplicité de l'interface entre les 2 fonctions la vérification est aisée. Le blocage du déplacement, par suite d'un écart par rapport à la trajectoire ou par un obstacle, est signalé à SUPERVISION par la variable ETAT. Cette variable est donc définie par: ETAT: (DEPLACEMENT, REPOS, BLOCAGE). M.C.S.E 311

Partie 4 - CONCEPTION FONCTIONNELLE

SON_SIRENE

ORDRE SUPERVISION

CR

Chariot C_TAPIS M/A OBSTACLE Atelier ETAT

DCA

CVM1

Chariot POSITION_QUAI COMMANDE DEPLACEMENT CVM2 VM1 Chariot VM2

-Figure 15.8- Première décomposition fonctionnelle. Le chariot doit suivre un gabarit en vitesse. La structure fonctionnelle conduit à la constatation qu'il s'agit d'une commande en boucle ouverte, faute d'observation de la vitesse du chariot. Pour pouvoir assurer un déplacement correct, les vitesses des 2 roues VM1 et VM2 sont des informations strictement nécessaires. Elles sont à ajouter comme entrées du système. Ceci montre les retours-arrières possibles pour ajuster la délimitation des entrées/sorties. De même, l'arrêt du chariot en face du quai nécessite de connaître la position relative du chariot au quai. 3 états sont suffisants: loin, approche, présence. Cette entrée appelée POSITION_QUAI est donc à ajouter. 15.5. RAFFINEMENT FONCTIONNEL Une fois obtenu le premier niveau de la structure fonctionnelle, la décomposition doit être poursuivie pour chaque fonction. Le raffinement doit être suffisant pour aboutir à des fonctions élémentaires simples, tout en se limitant au nécessaire. 15.5.1. Critère d'arrêt pour le raffinement Rappelons qu'une structure fonctionnelle exprime l'évolution parallèle de ses constituants. Lorsqu'une fonction ne nécessite pas de parallélisme pour exprimer son comportement, elle ne doit pas être décomposée. C'est le critère d'arrêt à utiliser pour le raffinement fonctionnel. C'est par le travail d'analyse qu'il est possible de déduire si un raffinement est nécessaire ou pas. La déduction est généralement assez simple au vu de la spécification de la fonction. Si cette spécification est exprimée par un modèle séquentiel - diagramme à états finis, grafcet séquentiel, modèle mathématique - la réponse est immédiate. 312 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE 15.5.2. Déroulement du raffinement L'ordre de décomposition des fonctions importe peu a priori car les fonctions sont indépendantes, chacune justifiée par une spécification généralement informelle. Toutefois, il est suggéré de détailler les fonctions les moins évidentes d'abord. En effet, pour les fonctions simples et donc évidentes, il n'y aura pas de surprise. Par contre, pour les autres, si elles n'apparaissent pas simples, peut-être est-ce dû au fait que le rôle et la spécification ne sont pas clairement définis. Pour cela, il est souhaitable d'approfondir ces fonctions par une analyse qui conduit alors à un raffinement. La démarche à suivre pour chaque raffinement est la même que celle exposée pour la recherche de la première décomposition fonctionnelle. Procéder en 3 temps: analyse, construction, vérification. 15.5.3. Exemple 1: contrôle en vitesse d’un centrifugeur Procédons tout d'abord au raffinement de CONTROLE_VITESSE. Le moteur doit suivre, indépendamment de la charge, un gabarit en vitesse: accélération, vitesse constante, décélération. Ceci n'est possible qu'en connaissant la vitesse de consigne à tout instant. Soit VCONSIGNE cette variable. Pour s'orienter vers des solutions numériques, la variable VCONSIGNE est à évaluer à des instants discrets selon un pas d'échantillonnage (H) qui se déduit de la précision à obtenir. La structure fonctionnelle proposée, construite autour de VCONSIGNE et de H est la suivante:
M/A ETAT CROTATION

EROTATION COMMANDE VITESSE

VMOTEUR

VCONSIGNE

VMOTEUR H ASSERVISSEMENT VITESSE CV

HORLOGE

Contrôle vitesse

-Figure 15.9- Raffinement de CONTROLE_VITESSE. La fonction HORLOGE est nécessaire pour produire H. Les 2 fonctions COMMANDE_VITESSE et ASSERVISSEMENT_VITESSE sont temporaires synchrones à H, ce qui se justifie pour une solution complètement numérique. M.C.S.E 313

Partie 4 - CONCEPTION FONCTIONNELLE L'entrée VMOTEUR est nécessaire pour la fonction COMMANDE_VITESSE de manière à indiquer à GESTION_CENTRIFUGEUR l'état ROTATION ou ARRET. La spécification de ASSERVISSEMENT_VITESSE est une régulation du type proportionnel ou proportionnelleintégrale-dérivée si nécessaire. La spécification de COMMANDE_VITESSE correspond au diagramme à états finis de la spécification (voir 12.6.3) précisant le comportement imposé au moteur. Ainsi toutes les fonctions ont un comportement séquentiel. Le raffinement est donc achevé. Pour la fonction GESTION_CENTRIFUGEUR, sa spécification est exprimable à partir du comportement imposé à l'utilisateur (automate à états finis donné en 15.6.4). Le comportement est séquentiel. Le raffinement n'est donc pas nécessaire. 15.5.4. Exemple 2: Automatisation par chariot filoguidé Commençons à nouveau par la fonction COMMANDE_DEPLACEMENT. Les 2 moteurs du chariot sont mécaniquement indépendants. Mais le chariot doit suivre sa trajectoire et simultanément respecter le cycle: accélération, vitesse constante, décélération. Un couplage est donc nécessaire entre les commandes des 2 moteurs. Une grandeur essentielle est la consigne de vitesse de chaque roue à tout instant. Soient VC1 et VC2 ces 2 variables. Les commandes à appliquer pour chaque roue sont aussi générées à instants discrets. Une solution pour le raffinement est la suivante:
M/A OBSTACLE POSITION_QUAI COORDINATION DCA ETAT

PAS HORLOGE

VC1

VC2

roue 2 roue 1 VM2 ASSERVISSEMENT

CVM2

CVM1 VM1 VITESSE

Commande déplacement

-Figure 15.10- Raffinement pour COMMANDE_DEPLACEMENT. Il est évident que plusieurs solutions existent suivant la variable de couplage considérée. Entre les diverses solutions, cela revient à placer les opérations à effectuer dans l'une ou l'autre des fonctions. Ceci influe sur la partie organisationnelle et non pas sur la partie opératoire. 314 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE Pour la solution retenue, le couplage des 2 roues pour suivre le fil à partir de DCA se trouve dans COORDINATION, ce qui permet ainsi de prendre en compte les cas de défauts. Si la variable de couplage des fonctions choisie est Vc: consigne du chariot, et que le suivi de la trajectoire est assuré par les fonctions Asservissement, celles-ci sont alors plus complexes; il faut en plus faire remonter une indication des cas d'erreurs: écart trop important de la trajectoire par exemple. Pour cet exemple, la fonction COORDINATION est spécifiée par le comportement imposé au chariot durant chaque phase de déplacement (voir la spécification en 12.10.2). Un raffinement n'est donc pas nécessaire. De même, la fonction SUPERVISION est spécifiée par le comportement global du chariot, qui est séquentiel. Toutefois, des conditions du type durée existent, ce qui nécessite en complément l'accès à un Temps. Soit T un temps restant relatif au début de la phase d'attente. Ainsi la fonction SUPERVISION nécessite d'être raffiné comme suit:

SON_SIRENE

ORDRE SUPERVISION

CR

C_TAPIS

T

FIN_T

TEMPORISATION

M/A

ETAT

-Figure 15.11- Raffinement de SUPERVISION La fonction Temporisation génère l'événement FIN_T. Cette solution est strictement nécessaire pour être conforme au modèle fonctionnel. En effet, SUPERVISION est activée sur apparition de chaque ORDRE. Le temps de déroulement de l'activité n'est pas nulle puisqu'il y a des attentes temporelles. Ainsi pour respecter l'hypothèse du temps nul pour le déroulement des opérations, les attentes temporelles doivent se faire sur l'événement FIN_T du type condition (attente passive au lieu d'une attente active). 15.6. COMPORTEMENT DES FONCTIONS ELEMENTAIRES Pour achever la solution fonctionnelle, toutes les fonctions élémentaires sont à décrire complètement. Il en est de même pour toutes les variables de la structure fonctionnelle. M.C.S.E 315

Partie 4 - CONCEPTION FONCTIONNELLE L'ordre pour ces descriptions peut a priori être quelconque. Toutefois, durant un raffinement, comme il faut se poser la question de savoir si une fonction est élémentaire ou pas, la preuve apparait lorsque la description comportementale par un algorithme est établie. D'autre part, il se trouve qu'exprimer la description algorithmique est plus difficile que d'établir un raffinement fonctionnel, car plus contraignant mais par ce fait plus favorable pour s'assurer de la complétude de la solution. Pour les données, la description doit se faire au fur et à mesure de leur apparition durant les étapes de raffinement. L'ordre logique veut que les données soient décrites avant les fonctions qui les utilisent ou les produisent. Cette attitude est justifiée, d'une part puisque le principe de la conception fonctionnelle est orienté données, d'autre part puisqu'il n'est pas possible de décrire une fonction de transformation sans connaître les données en entrée et en sortie. 15.6.1. Méthode pour l'obtention d'une description algorithmique La description algorithmique exprime le comportement interne de la fonction. Cette description est une solution possible pour que la fonction se comporte en externe comme sa spécification. La solution n'est pas unique et ne traduit pas obligatoirement la solution qui sera par la suite utilisée pour la réalisation. Une transformation pourra être entreprise pour répondre à divers critères: optimisation, simplification ... La description s'obtient à partir d'une spécification. Le travail de traduction est fonction de la nature de la spécification: - Pour une spécification très informelle, la tâche est plutôt longue et la vérification peu simple, - Pour une spécification formelle, le travail se réduit à une simple traduction. Prenons l'exemple d'une spécification exprimée par un diagramme à états finis. Cette spécification explicite le comportement externe de la fonction par un ensemble d'états qui permet de caractériser les sorties à partir des entrées. Ce type de modèle est très favorable pour l'obtention de la description interne. En effet, il suffit de bâtir la description autour d'une variable interne qui prend comme valeurs les états de la spécification. Cette variable permet alors d'exprimer les conditions de transition et les états des sorties. L'exemple de la figure 15.12 montre la simplicité de la traduction. Cette technique d'écriture est illustrée par les 2 exemples traités dans ce chapitre. 15.6.2. Exemple 1: Contrôle en vitesse d’un centrifugeur 3 fonctions élémentaires dont 1 permanente et 2 temporaires résultent du raffinement de CONTROLE_VITESSE. GESTION_CENTRIFUGEUR comme action temporaire n'a pas été raffinée. On décrit ci-après les 4 algorithmes.
action HORLOGE avec (sortie ev H); const PASH = 5 ms; begin cycle :begin attendre (PASH); signal (H); end; end cycle; end HORLOGE;

316

M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

action EXEMPLE sur ev PAS avec (entrée var V:0..100Km sortie Var INDICATION:(Vert,Rouge); ev Dépassement); Var ETAT:(lent,Rapide); begin INDICATION:=vert; ETAT:=lent; cycle PAS: case ETAT of lent: if V>50Km then begin signal (Dépassement); INDICATION:=Rouge; ETAT:=rapide; end; rapide: if V < 40 Km then begin INDICATION:=vert; ETAT:=lent; end; end case; end cycle; end EXEMPLE;

Lent

Indication = vert

V < 40 km

V > 50 km Dépassement

Rapide

Indication = rouge

V

Dépassement

Pas

EXEMPLE

Indication

-Figure 15.12- Exemple de traduction d'une spécification par diagramme. Pour l’action asservissement simplement du type proportionnel, il faut tenir compte du fait que la variable CV est bornée. Si le calcul de la commande donne une grandeur dépassant la valeur maximale, il faut alors limiter CV à cette valeur maximale, de même pour la valeur minimale. Il faut noter qu’un asservissement en proportionnel n’est pas suffisant car un écart permanent subsiste. Des actions intégrale et dérivée s’ajoutent sans difficultés.
action ASSER_VITESSE sur événement H avec (entrée var VCONSIGNE, VMOTEUR: def_vitesse; Sortie var CV:0 ... CVMAX); const KP = coefficient proportionnel; CVMAX = 999; Var C: integer; begin CV:=O; cycle H:begin C:=Kp*(VCONSIGNE-VMOTEUR); if C>CVMAX then CV:=CVMAX else if C<0 then CV:=0 else CV:=C; end; end cycle; end ASSER_VITESSE;

Comme la fonction COMMANDE_VITESSE joue le rôle de supervision pour l'évolution du moteur, cette fonction doit imposer au moteur un comportement décrit par la spécification fonctionnelle. Pour cela, il suffit donc que la fonction se comporte comme la spécification. Ceci conduit à une écriture algorithmique directe comme une simple traduction du diagramme à états finis. M.C.S.E 317

Partie 4 - CONCEPTION FONCTIONNELLE
action COMMANDE_VITESSE sur événement H avec (entrée var CROTATION, VMOTEUR: def_vitesse; entrée/sortie var M/A: (marche, arrêt); sortie var VCONSIGNE: def_vitesse; var ETAT,EROTATION: (Rotation,arrêt)); Const PASH = 5 ms; Vmin = 5 trs; TM = 5 s: TC = 20 s; TD = 5 s; Var ETAT_MOTEUR: (Repos, accélération, vit_constante, décélération); VM: 0...VMAX; T: integer; begin ETAT_MOTEUR: = Repos; ETAT:=arrêt; EROTATION:=arrêt; VCONSIGNE:=0; cycle H: begin T:= T+PASH; Case ETAT_MOTEUR of Repos: if M/A = marche then begin ETAT_MOTEUR:=accélération; VCONSIGNE:= 0; T:=0: ETAT:=Rotation; EROTATION:=rotation; end; accélération: if M/A = arrêt then begin ETAT_MOTEUR:= décélération; VM:= VMOTEUR; T:= 0; end else if T>=TM then begin ETAT_MOTEUR:= Vit_constante; VCONSIGNE:= CROTATION; T:= 0; end else VCONSIGNE:= (CROTATION*T)/TM; Vit_constante: if (M/A=arrêt) or (T>=TC) then begin ETAT_MOTEUR:= décélération; VM:= VMOTEUR; T:=0; end; décélération: if VMOTEUR < Vmin then begin ETAT_MOTEUR:= Repos; M/A:=arrêt; ETAT:=arrêt; EROTATION:= arrêt; VCONSIGNE:= 0; end else VCONSIGNE:= VM - (CROTATION*T)/TD; end case; end; end cycle; end COMMAND_VITESSE;

318

M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE La fonction de gestion du centrifugeur doit être conforme à la spécification donnée comme contrainte imposée par le système à l'utilisateur. La description algorithmique s'en déduit directement.
action GESTION_CENTRIFUGEUR sur message ORDRE: def_ordre avec (entrée var ETAT:(rotation, arrêt); sortie var VROTATION, CROTATION: def_vitesse; var M/A: (marche, arrêt)); type def_ordre = record nature: (marche, arrêt, consigne); val_consigne: def_vitesse; end; Var V_consigne: def_vitesse; begin M/A:=arrêt; CROTATION:=0; VROTATION:=0; V_consigne:=0; cycle ORDRE: case ORDRE.nature of marche: if ETAT=Arrêt then begin CROTATION:=V_consigne; M/A:= marche; end; consigne: if ETAT=Arrêt then begin V_consigne:=ORDRE.val_consigne; VROTATION:=V_consigne; end; arrêt: begin M/A:= arrêt; end; end case; end cycle; end GESTION_CENTRIFUGEUR;

Il faut noter que les variables M/A et ETAT ne sont pas synchrones. En effet, lorsque M/A est affecté à Marche, ETAT ne passe à Rotation que sur l’événement H suivant. Pour cette raison, tout ordre d’arrêt est répercuté auprès de la fonction COMMANDE_VITESSE. La phase de vérification est ainsi importante car elle conduit à assurer que l’implantation résultante sera correcte. 15.6.3. Exemple 2: Automatisation par chariot filoguidé Il existe une grande ressemblance fonctionnelle entre les 2 exemples. Aussi certaines fonctions décrites pour l'exemple 1 sont transposables pour cet exemple. C'est le cas des actions HORLOGE et ASSERVISSEMENT_VITESSE. On constate ainsi les aspects réutilisation des développements sur le plan fonctionnnel. La fonction COORDINATION se charge de surveiller l'environnement durant la phase de déplacement: position du fil et détection d'obstacles. Elle se charge aussi d'imposer le profil: accélération, vitesse constante, décélération, et gère la coordination des 2 roues. M.C.S.E 319

Partie 4 - CONCEPTION FONCTIONNELLE Ici le profil en vitesse est obtenu par ajout ou retrait d'un incrément de vitesse à chaque pas. De plus, le contrôle en vitesse nécessite d'utiliser les 2 positions du chariot par rapport au quai: Approche et Présence.
action COORDINATION sur événement PAS avec (entrées:var OBSTACLE: boolean; var POSITION_QUAI:(loin, approche, présence); var DCA: -Dmax..+Dmax; entrée/sortie var M/A: boolean; var ETAT: Def_état; sortie var VC1, VC2 : def_vitesse); const Tpas = durée; VCMAX = vitesse maximale; km = coeff; Dmax = distance maximale; INC_VC = 0.75*Tpas m/s; DEC_VC = 0.7*Tpas m/s; type Def_état=(repos, accélération, V_constante, décélération, défaut); var vc: def_vitesse; begin VC1:=0; VC2:= 0; ETAT:= repos; cycle PAS: begin case ETAT of Repos: if M/A and not OBSTACLE then begin ETAT:= accélération; end else VC:= 0; accélération: if VC+INC_VC >= VCmax then begin VC:= VCmax; ETAT:= V_constante; end else VC:= VC + INC_VC; V_constante: if POSITION_QUAI=approche then begin ETAT:= décélération; end; décélération: if POSITION_QUAI=présence then begin VC:= 0; ETAT:= Repos; M/A:= false; end; else VC:= VC - DEC_VC; défaut: if M/A= false then ETAT:= Repos; end case; if OBSTACLE or abs(DCA)>=Dmax then begin VC1:= 0; VC2:= 0; ETAT:= défaut; end else begin VC1:= VC + km*(DCA); VC2:= VC - km*(DCA); end; end; end cycle; end COORDINATION;

320

M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

Cet algorithme suppose que les 2 quais sont distants d'au moins 1,5 m, ce qui est réaliste. Une solution plus robuste n'est pas difficile à écrire.
action SUPERVISION sur message ORDRE:Def_ordre avec (entrée var ETAT:def_etat; evenement fin_T; entrée/sortie var M/A: boolean; T:integer; Sortie message CR: def_cr; var C_TAPIS:def_c_tapis; SON_SIRENE: boolean); const TC=3s; TI = 10s; TD=4s; type def_ordre = (I_présence, chargement, déchargement, transport); def_cr = (OK_présence); def_c_tapis = (arrêt, arrière, avant); begin M/A:= false; SON_SIRENE:= false; C_TAPIS:=arrêt; cycle ORDRE: case ORDRE of I_présence: send(OK_présence, CR); chargement: begin C_TAPIS:= avant; T:= TC; when fin_T: C_TAPIS:= arrêt; end when; end; transport: begin M/A:= true; Repeat until (M/A=false) or (ETAT=défaut); if ETAT= défaut then SON_SIRENE:= true; else begin T:= TI; when fin_T : SON_SIRENE:= true; I_présence : send(OK_présence, CR); end when; end; end; déchargement: begin C_TAPIS:= arrière; T:= TD; when fin_T: C_TAPIS:= arrêt; end when; end; end case; end cycle; end SUPERVISION;

Cette fonction utilise un décompteur de T pour les temporisations TC, TD et TI. 15.7. DESCRIPTION DES DONNEES Les données servent dans 2 types de relations: le partage de variables et le transfert de messages. Chaque variable, chaque type de message doivent être spécifiés puis décrits au fur et à mesure du développement de la structure fonctionnelle. M.C.S.E 321

Partie 4 - CONCEPTION FONCTIONNELLE Pour qu'une description de données durant cette étape soit correcte, il est important de ne pas confondre la description logique seule utile pour le niveau fonctionnel, et la description physique nécessaire pour l'implantation (voir le modèle de description en 13.4). Les termes utilisés ici sont différents des niveaux utilisés pour les bases de données. Le terme description logique est plutôt proche du terme schéma conceptuel. 15.7.1. Méthode pour décrire les données Une donnée dans sa forme la plus générale est une structure. Comme il s'agit d'une structure, la démarche préconisée pour la recherche d'une structure fonctionnelle: -analyse, construction, vérification - s'applique aussi pour élaborer la description des données.
-A- ANALYSE

Une variable ou un type de message apparaissant dans une structure fonctionnelle après raffinement résulte d'une analyse des spécifications. La spécification de chaque donnée pour déduire sa description dépend de sa complexité. Le modèle décrit en 13.4 fait état de 4 niveaux de complexité: - la donnée élémentaire: sa spécification et la description correspondante sont directes, car assimilable aux types de base: booléen, entier, énumération ... - la donnée structurée: sa spécification s'exprime par composition de données plus élémentaires selon les opérateurs: concaténation, sélection, ensemble. Sa description logique est une structure de données. - la collection de données: chaque donnée est identifiable par une clé. - la donnée du type RELATION: sa spécification s'exprime par des diagrammes entités/ relations de CHEN. Sa description logique s'exprime par une ou plusieurs collection de données. Chaque relation individualisée est désignée par des clés. La tâche d'analyse doit tout d'abord situer la complexité de la donnée. Elle résulte d'une interprétation des spécifications fonctionnelles. Dans le cas le plus général, l'analyse conduit à mettre en évidence le schéma conceptuel utilisant le diagramme entités/relations. Ce schéma résulte d'une interprétation des phrases de la spécification en traduisant les noms en type d'entités et les verbes en relations. Chaque entité est ensuite spécifiée en identifiant tous les constituants et la structure liant ces constituants. Cette spécification doit être conduite jusqu'à l'obtention des constituants de base.
-B- CONSTRUCTION

Cette phase permet d'obtenir à partir de la spécification, une description logique structurée de la donnée. Ceci résulte d'une transformation de la spécification. Rappelons que la description doit rester logique et ne doit pas traduire l'implantation de la donnée. Les ensembles d'entités et de relations sont transformés en collections. Les relations sont décrites par des liens entre entités. Utiliser pour cela les règles de transformation pour obtenir la 3e forme normale. Une CLE est sélectionnée pour identifier chaque entité. Chaque entité est décrite sur la base des 3 symboles du modèle décrit en 13.4: composé de, sélection parmi, ensemble de. 322 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE
-C- VERIFICATION

Comme pour une structure fonctionnelle, il s’agit de s’assurer que la structure de chaque donnée permet de satisfaire les spécifications. Cette vérification porte sur la complétude, la cohérence, l'orthogonalité des champs ou attributs. Elle nécessite aussi de considérer la ou les fonctions qui produisent la donnée et celles qui l'utilisent. Ainsi, la vérification ne sera complète qu'après avoir décrit toutes les fonctions de la structure fonctionnelle qui exploitent et produisent les données. 15.7.2. Illustration par un exemple L'exemple retenu est le cas d'un système de programmation du chauffage pour un bâtiment. Chaque pièce appartient à une zone de chauffage. Pour chaque pièce, on doit pouvoir connaître: l'ETAT: défaut, arrêt, chauffe, la température de consigne, la température courante, la température externe.

La température externe se déduit de la position de la zone qui inclut la pièce par rapport aux 4 façades du bâtiment. Pour la programmation du chauffage, elle se fait aussi pièce par pièce, selon une programmation hebdomadaire. La résolution est le 1/4 d'heure sauf de 22h à 7h du matin qui ne représente qu'une seule plage. Ceci donne 60 périodes de programmation. La programmation pour une pièce et l'observation de l'état des pièces sont conformes à l'écran ci-dessous.
PROGRAMMATION : 7h Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche CHOIX : F(in A(nnulation VISUALISATION ETAT Défaut 1 2 3 Mode DATE : 10/9/89 Chauffe Tc 18 16 HEURE : 10:35 Ti 17 5 Te 5 5 8h 10h 12h Pièce : 5 14h ETAGE : 2 16h AILE : SUD 18h 20h TC = 18 C 22h 7h

N CHOIX : M(odification P(rogrammation S(election

-Figure 15.13- Exemple de présentation d'écran. M.C.S.E 323

Partie 4 - CONCEPTION FONCTIONNELLE Toutes les pièces d'une même zone sont caractérisées par un état identique. La programmation pour chaque zone se déduit de la programmation des pièces comme l'union des périodes de chauffe, la température de consigne est la valeur maximale des consignes des pièces incluses. L'état de chaque PIECE se déduit de la définition de ZONES et de la relation d'appartenance entre ZONES et PIECES. La modélisation retenue pour les données est la suivante.
Pièce
Nom
n
appartient

Zone
Nom
1 n
exposé

Façade
Nom
1
TE

TC état_zone prog_pièce prog_zone lundi dimanche ETAT TC jour 0 0 60 MODE MODE : (arrêt,chauffe) 60

-Figure 15.14- Modélisation des données pour un descriptif du chauffage. La description des variables se déduit de cette modélisation. facades = {facade} facade = nom + TE: -30°C..+50°C zones = {zone} zone = nom + facade_Ref + état_zone + prog_zone état_zone = état + Tc état : (défaut, arrêt, chauffe) Tc : 0 .. 30°C Prog_zone = 60{mode}60 (il y a obligatoirement 60 périodes) Mode : (arrêt, chauffe) pièces = { pièce} pièce = nom + zone_ref + TC + prog_pièce prog_pièce = 7{jour}7 jour = 60{mode}60 Descriptif_chauffage = facades + zones + pièces 324 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE Cette description des données reste fonctionnelle. A partir de celle-ci se déduit la structure fonctionnelle et par la suite la description pour l'implantation. La structure fonctionnelle serait par exemple la suivante:

V_pièce[1..n]

V_zone[1..m]

Suivi pièce [ i ]

Gestion pièces

Descriptif chauffage

Gestion zones

Suivi zone [ i ]

-Figure 15.15- S.F pour la conduite du chauffage pour chaque pièce. Pour n pièces et m zones les variables V_PIECE et V_ZONE pour chaque zone sont définies comme suit: V_PIECE[i] = TC + prog_pièce + état V_ZONE[j] = état_zone + prog_zone 15.8. CRITERES D'EVALUATION D’UNE SOLUTION Plusieurs solutions sont possibles pour satisfaire une même spécification. Des critères sont donc à utiliser pour évaluer celle considérée comme la meilleure. Les critères habituellement cités concernant l'analyse des structures sont: - l'analyse du couplage, - l'analyse de la cohérence, - l'analyse de la complexité. Le couplage concerne la relation établie par paire de fonctions. La cohérence et la complexité concernent l’aspect interne de chaque fonction. Ces analyses sont réalisables pour tous les niveaux du raffinement. A ces critères s'ajoute le critère de lisibilité. 15.8.1. Analyse du couplage Les fonctions de la structure sont couplées par des relations du type: variable, événement, port pour les messages. La complexité du couplage est liée: - au nombre de relations par paire, - à la complexité de chaque relation, ceci pour les variables et les messages. Les couplages se réduisent en regroupant différentes données dans une même structure de données. Les couplages agissant sur le contrôle des évolutions se réduisent en effectuant une approche orientée données, plutôt qu’une approche par les fonctions. M.C.S.E 325

Partie 4 - CONCEPTION FONCTIONNELLE La complexité d'un couplage peut aussi se mesurer au travers des implications engendrées par une modification de l'élément intermédiaire. Modifiant la nature et/ou la structure de la variable, quelles sont les modifications à faire? Lorsqu'une variable est utilisée par beaucoup de fonctions, le couplage s'avère important. 15.8.2. Analyse de la cohérence La cohérence se traduit par une mesure de l'unité fonctionnelle des constituants d'un élément. Cette analyse concerne aussi bien les fonctions que les données. L'observation peut se faire de l'extérieur ou en interne. La cohérence externe se traduit par l'adéquation du nom à la fonction ou à la donnée. Plus le nom est général, moins la cohérence existe. Une bonne cohérence externe favorise la lisibilité. La cohérence interne s'observe par analyse de la structure interne et des relations entre les constituants. Un couplage par des variables conduit à une meilleure cohérence qu'un couplage par événement ou message car ces derniers expriment alors une relation temporelle. Si les données servant de liens entre les fonctions ont une unité vis à vis de la fonctionnalité, le sous-ensemble possède un fort degré de cohérence. 15.8.3. Analyse de la complexité Il s'agit d'exprimer la complexité de chaque fonction, elle-même décomposée par une structure fonctionnelle ou décrite par un algorithme. La complexité d'une structure fonctionnelle pour chaque niveau de raffinement se mesure au nombre de fonctions internes et au nombre de relations. La technique de raffinement préconisée dans ce chapitre limite la complexité entre 5 à 10 éléments, ce qui permet d'avoir une bonne lisibilité. La complexité peut aussi être observée en vertical. En combien de niveaux une fonction se trouve-t-elle décomposée? Cette analyse met en évidence le nombre de fonctions subordonnées. Plus le nombre est important, plus la lisibilité est faible. La complexité d'une description algorithmique se mesure par: - la complexité des entrées et sorties de la fonction, (fan-in, fan-out) - la longueur de la description, - la complexité de l'enchaînement des opérations. Des outils de qualimétrie existent aujourd'hui pour mesurer cette complexité algorithmique [ROUVE-88]. 15.8.4. Lisibilité d'une solution La lisibilité est essentielle pour la suite du développement ainsi que pour la maintenance sous toutes ses formes. La lisibilité de la structure fonctionnelle est particulièrement visuelle. La forme pour la représentation est un facteur important pour la compréhension. Elle indique dans une certaine mesure la démarche suivie par le concepteur ainsi que sa logique d'esprit. Il est conseillé de placer toutes les entrées à gauche et les sorties à droite. Les relations doivent aller au maximum des entrées vers les sorties. Seules les relations exprimant un bouclage interne sont à représenter en sens inverse. 326 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE La lisibilité résulte des critères précédents: faible couplage, cohérence forte et faible complexité. La lisibilité des descriptions algorithmiques s'obtient en respectant les critères de lisibilité d'un programme: longueur d'une description limitée à une page, au-delà utilisation de procédures et fonctions. Utilisation des structures de contrôle de la programmation structurée, limitation du nombre d'emboitements des structures de contrôle, réduction des interfaces avec les procédures et fonctions. Lorsque la solution complète est formulée, il est conseillé de revoir tous les détails de la solution sur la base des critères ci-dessus. Des modifications peuvent apparaitre souhaitables pour améliorer la lisibilité et la simplicité. Pour la structure fonctionnelle, il s'agit de réduire les interfaces entre les fonctions ce qui s'obtient par regroupement de variables, regroupement de fonctions, ou déplacement de certaines parties opératoires d'une action dans une autre. 15.9. DOCUMENTATION En final, l'essentiel de l'étape de conception est le document produit. Ce document de conception joue plusieurs rôles en permettant: - la vérification de l'adéquation de la solution aux spécifications, - le transfert de connaissances de la solution développée pour le problème, - le développement d'une réalisation. La vérification est assurée par un cycle auteur-lecteurs permettant ainsi de corriger, de modifier, d’améliorer la solution. Ce même cycle permet aux lecteurs de prendre connaissance du problème. Ce document sert aussi comme document de référence pour le produit. Ceci facilite les tâches de maintenance et d'évolution de l'application. Pour l'étape suivante de définition de la réalisation, le document, associé au document de spécification, va servir comme données d'entrée. Pour cela, il ne doit pas décrire l'ordre chronologique des réflexions et des développements. Il doit tout simplement décrire la solution retenue selon une démarche descendante pour faciliter la compréhension. Un guide doit favoriser la compréhension globale de la solution: description de la hiérarchie des fonctions, des données ... 15.10. RESUME La démarche pour la conception fonctionnelle a été présentée sur 2 exemples qui a priori paraissaient bien différents. Développant la solution, des similitudes ont été constatées: asservissement de vitesse, génération de profil de vitesse, coordination ... Ainsi, la démarche favorise naturellement la réutilisation de sous-ensembles développés dans d'autres projets. En effet, les problèmes à traiter incluent des classes générales de sous-ensembles dont la solution s'identifie par une démarche sur le plan fonctionnel. Rappelons les points essentiels de la démarche proposée dans ce chapitre. - Tout d’abord une bonne conception fonctionnelle ne peut s'entreprendre que si les documents en entrée sont complets, validés et de qualité. Les spécifications à prendre en compte sont les spécifications fonctionnelles et opératoires. M.C.S.E 327

Partie 4 - CONCEPTION FONCTIONNELLE - La première phase consiste à délimiter le système par ses entrées et ses sorties. Cellesci ne doivent pas être technologiques mais fonctionnelles vis à vis des entités de l'environnement. - Il faut attacher une grande importance à la première décomposition fonctionnelle; elle va induire l'architecture de l'ensemble de la solution. La meilleure est celle qui permettra de minimiser la partie organisationnelle de la réalisation. - la recherche d'une solution par raffinement se fait en 3 temps: analyse des spécifications, construction d'une ou plusieurs solutions, vérification. - Le raffinement fonctionnel ne doit pas être excessif. Pour une fonction, le raffinement est achevé lorsque celle-ci possède un comportement séquentiel. - La description algorithmique des actions doit être de qualité: se limiter au strict nécessaire, favoriser la lisibilité, être conforme au modèle pour les actions permanentes et temporaires. Si possible, cette description ne doit être qu'une simple traduction de spécifications. - La description de toutes les données doit être complète avant d'entreprendre la description algorithmique. Une structure de données s'élabore selon une démarche en 3 temps: analyse, construction, vérification. - la solution complète doit être évaluée sur la base de critères qui permettent de juger de la qualité: couplage, cohérence, complexité, lisibilité. - La documentation doit être structurée et complète. Elle doit décrire la solution selon une approche descendante de manière à favoriser la compréhension. L'application de la méthode conduit à ce résultat.

328

M.C.S.E

Chapitre 16

MODELES GENERIQUES DE SOLUTIONS

Durant l'étape de conception fonctionnelle, les développeurs doivent rechercher une solution comme raffinement de chaque fonction. Ce travail est lié au processus créatif de conception. La qualité du concepteur reste donc un facteur important d'influence sur la nature de la solution. Or, il se trouve que la première décomposition fonctionnelle est essentielle pour la qualité de l'ensemble du projet. Le chapitre précédent a montré que cette décomposition découle d'une phase d'analyse. En réalisant des expériences sur une population variée de concepteurs placés face à un même problème de conception (groupe d'étudiants de différentes origines par exemple), il est facile de constater que, se basant sur des mêmes principes de conception, les solutions proposées sont des plus variées. Ceci veut dire que les concepteurs ne trouvent pas les mêmes variables essentielles. Pourtant une solution est plus appropriée que les autres. Fort de cette constatation, nous nous sommes attachés à rechercher une technique permettant d'augmenter considérablement l'homogénéité des solutions. Le point de départ de la réflexion fut de considérer que les concepteurs travaillent plutôt par analogie. Ayant traité un problème similaire ou disposant de solutions, chacun est tenté tout naturellement de réutiliser cet acquis. Les problèmes étant différents, il ne suffit pas de disposer d'une riche classe de solutions car une solution ne correspond pas toujours très exactement au

M.C.S.E

329

Partie 4 - CONCEPTION FONCTIONNELLE problème à traiter. Dans l’hypothèse d’une disponibilité de solutions, la technique de conception est alors un travail d'assemblage selon une démarche ascendante. Cette façon de procéder n'est pas en accord avec les principes de conception développés dans les chapitres précédents. Nous proposons ici l'idée de modèles génériques de solutions. Ces modèles en nombre très réduit s'avèrent particulièrement adaptés à la résolution d'une large classe de problèmes. 16.1. ROLE ET APPORT D’UN MODELE GENERIQUE Un modèle générique de solution est l'expression d'une architecture fonctionnelle générale comme une esquisse de solution adaptée à une classe de problèmes. Un modèle générique suggère des fonctions internes et des couplages spécifiques entre ces fonctions. Ainsi, au lieu de rechercher sans guide les variables internes essentielles, le concepteur, lorsqu'il part d'un modèle générique, recherche les variables essentielles qui vont assurer le couplage entre les fonctions du modèle. La variété des variables possibles est alors beaucoup plus réduite. Ensuite, ayant défini les variables essentielles, il lui suffit de spécifier les fonctions du modèle pour l'application. L'expérience montre qu'avec une population variée de concepteurs, pour un problème posé et avec un modèle générique imposé, peu de disparité apparaît entre les solutions proposées. L'uniformité est-elle bonne? Pas obligatoirement, car elle peut supprimer l'apparition de solutions meilleures. Aussi, un modèle générique doit posséder en intrinsèque des propriétés de qualité de manière à engendrer les meilleures solutions. L'apport du modèle générique dans une démarche de conception descendante est alors considérable car améliorant la solution produite, réduisant ainsi globalement le coût du développement du projet. Comment trouve-t-on un modèle générique? La création ex nihilo est très peu probable. Il faut plutôt se baser sur une observation des principes et architectures de solutions imaginées par des concepteurs. De cette observation, il faut déduire le caractère général, puis formaliser l'approche en tant que modèle générique. Ensuite un tel modèle doit être validé. Ceci passe par de multiples essais de résolution de problèmes de dimension industrielle à l'aide du modèle. De ces expériences découlent des modifications, des mesures de qualité, des conclusions. Trouver, formaliser, valider un modèle générique nécessite un travail expérimental important, qu'un concepteur peut économiser lorsqu'il utilise judicieusement des modèles déjà validés. C'est l'objectif de ce chapitre que de faire bénéficier les concepteurs de tels résultats. La suite du chapitre décrit quelques modèles génériques à connaître pour la conception fonctionnelle. A noter que cette notion de modèle générique est aussi utilisable pour l'étape suivante de définition de la réalisation. Ces modèles sont alors des modèles plutôt orientés vers l’architecture matérielle tels que la Machine de MOORE, la décomposition partie opérative/ partie commande, ou l’architecture logicielle tel que le modèle objet. 16.2. MODELE CONTROLEUR/PROCEDE COMMANDE 16.2.1. Principe Ce premier modèle reprend simplement le point de vue de l'Automaticien face à un procédé ou une entité à contrôler. Toute commande doit se faire en boucle fermée. En effet, le comportement du procédé ne pouvant pas être parfait - sensibilité à des perturbations ou autres 330 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS effets - une commande appliquée au procédé ne va engendrer qu'approximativement l'effet souhaité. Pour améliorer le résultat et satisfaire un objectif avec précision, il faut se servir d'observations sur le procédé pour corriger les défauts. Ce principe de départ est représenté ciaprès.

consigne

+ -

écart

Evaluation action et correction

actions
PROCEDE

observations

-Figure 16.1- Commande en boucle fermée. 16.2.2. Le modèle Regardons maintenant le contenu des spécifications d'un problème de commande. La démarche de spécification préconisée dans MCSE invite à modéliser tout d'abord les entités de l'environnement. Il s'agit donc d'exprimer le comportement approximatif du ou des procédés. Ensuite par les spécifications fonctionnelles, se trouve exprimé le comportement imposé à chaque entité par le système. Conclusion: se basant sur le principe de la boucle fermée, chaque entité pour suivre l’évolution imposée doit être pilotée par une fonction d'évaluation des actions qui doit se comporter comme l'indique la spécification fonctionnelle. Ce raisonnement est à faire pour chaque entité. Comme très souvent des relations de dépendance temporelle doivent être respectées pour les évolutions des entités, des couplages sont nécessaires entre les fonctions internes de contrôle. Le modèle CONTROLEUR/PROCEDE COMMANDE est alors le suivant:
actions 1

Contrôleur 1
observations 1 Etats des contrôleurs Couplage actions 2

Entité 1

Contrôleur 2
observations 2

Entité 2

-Figure 16.2- Modèle générique CONTROLEUR/PROCEDE. A chaque entité est associée en interne une fonction contrôleur couplée à cette entité par des relations d'actions et des relations d'observations. Le comportement de chaque fonction contrôleur est exprimé par la spécification fonctionnelle de l'entité correspondante. Par exemple, si la spécification est du type diagramme à états finis, la description algorithmique du comportement de la fonction de contrôle s'obtient par simple traduction du diagramme à états finis. M.C.S.E 331

Partie 4 - CONCEPTION FONCTIONNELLE Les fonctions contrôleur peuvent être couplées entre elles par des variables d'état si des synchronisations apparaissent dans les spécifications. Une dépendance temporelle unidirectionnelle simple entre 2 contrôleurs exprimée par une condition par exemple, se réalise par l'intermédiaire de la variable interne qui mémorise l'état présent du contrôleur générateur de la condition. Cette variable est alors placée à l'extérieur de cette fonction contrôleur pour la rendre accessible en lecture à l'autre contrôleur. 16.2.3. La méthode La méthode pour l'emploi de ce modèle est la suivante : - tout d'abord analyser les spécifications pour déterminer si ce modèle est approprié, - dessiner les fonctions contrôleurs, chacune couplée à son entité à contrôler au travers des entrées et sorties du système, - rechercher par analyse des spécifications, les couplages par variables d'état nécessaires pour satisfaire les relations d'ordre. - placer les variables de couplage et compléter les relations fonctionnelles, - écrire les descriptions algorithmiques des contrôleurs par traduction des spécifications, - vérifier la cohérence de l'ensemble de la solution et le respect de toutes les spécifications. 16.2.4. Exemple Illustrons l'emploi de ce modèle par l'exemple simple d'un chariot de manutention. La figure suivante montre l'automatisation à développer à l'aide d'un système électronique. L'objectif du système est d'assurer en automatique le cycle: déplacement du chariot de P1 en P2, vidage de la benne, retour du chariot en P1.
Position
Repos

Benne

MARCHE

AV AR Position vidage

Chariot

P1

P2

-Figure 16.3- Les 3 entités de l'application. 332 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS La spécification pour cet automatisme est décrite ci-dessous à l'aide de 3 diagrammes à états finis couplés. Les positions P1 et P2 sont détectées par les fins de course FCG et FCD. Les 2 positions de la benne sont commandées par les événements C_repos et C_vidage. La variable DEFAUT est générée par le chariot. Le cycle ne peut débuter que si le chariot est en P1. Sinon, il revient en cette position. L’opérateur génère l’événement MARCHE avec sa boite à bouton.
Système pour l’opérateur Chariot Benne

Attente cycle MARCHE cycle exec cycle ETAT(Chariot)= déplacement droite ou déplacement gauche

Repos chariot

AV = 0 AR = 0

Repos benne ETAT (Chariot)= attente remplissage C_vidage Vidage PR•cycle

cycle•FCG cycle•FCG Déplace droite AV = 1 AR = 0

Défaut

FCD Attente remplis- AV = 0 sage AR = 0

Durée (vidage) =T1
Remontée C_repos benne

PR Déplace AV = 0 gauche AR = 1

PR

FCG+Défaut

-Figure 16.4- Spécification de l'automatisme. A partir de cette spécification, se déduit la délimitation des entrées et sorties.

MARCHE Défaut SYSTEME DE

AR

Chariot
AV

position Repos pour la benne (P<=P1) (P>=P2)

PR FCG FCD

C_Vidage COMMANDE C_repos

Benne

-Figure 16.5- Spécification des entrées et sorties du système. Ensuite le concepteur doit proposer un raffinement. Comme le comportement imposé à chaque entité est décrit dans la spécification par un diagramme séquentiel, utilisons le modèle générique CONTROLEUR pour chaque entité. La solution est donc organisée autour de 3 contrôleurs. Il faut alors trouver les couplages nécessaires entre les contrôleurs. Un couplage unidirectionnel existe entre le contrôleur utilisateur et le contrôleur chariot, un autre bidirectionnel existe entre le contrôleur chariot et le contrôleur benne. M.C.S.E 333

Partie 4 - CONCEPTION FONCTIONNELLE La structure fonctionnelle obtenue est la suivante :
Défaut AV FCG CONTROLEUR FCD CHARIOT MARCHE GESTION DEMANDE cycle AR

ETAT_Chariot

ETAT_Benne

PR CONTROLEUR T GENERATION TEMPS BENNE

C_Vidage

C_Repos

-Figure 16.6- Structure fonctionnelle pour l’automatisation. La solution est complétée par une action de génération du temps T pour réaliser la temporisation nécessaire pour le contrôle de la durée de l'état vidage. 16.3. MODELE SUPERVISION/CONTROLE-COMMANDE Le modèle précédent est approprié pour des applications de faible complexité: peu d'entités et couplage fonctionnelle relativement faible. Pour des applications plus importantes, ce qui par exemple se mesure par l'importance des fonctions et le nombre d'entrées et de sorties du système, une approche hiérarchique est souhaitable. 16.3.1. Principe L'idée est que la conduite d'une installation plutôt complexe est globalement prise en charge par le système. L'utilisateur ou exploitant se contente de fournir les objectifs à atteindre et observe à un niveau macroscopique le comportement de l'installation. La conduite par l'exploitant est une fonctionnalité de niveau supérieur par rapport à la conduite de chaque entité de l'installation. De tels systèmes se structurent en au moins 2 niveaux: - un niveau SUPERVISION qui assure l'interface avec l'exploitant pour la conduite globale de l'application. - un niveau CONTROLE-COMMANDE chargé de gérer toutes les entités physiques de l'application pour qu'elles contribuent à satisfaire l'objectif du niveau supérieur. Les 2 niveaux sont donc couplés entre eux: dans le sens descendant pour l'assignation d'objectifs, dans le sens ascendant pour rendre compte de l'avancement vers les objectifs. 334 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS 16.3.2. Le modèle Le modèle proposé découle de ce principe de structuration. La décomposition se fait en 2 fonctions: SUPERVISION et CONTROLE_COMMANDE. Pour spécifier le modèle, il faut détailler le couplage général existant entre les 2 catégories de fonctions, de manière à proposer au concepteur un guide d'analyse qui lui permettra de rechercher les variables internes caractéristiques.

Niveau supérieur

SUPERVISION

Exploitant

Couplage

Niveau inférieur
Observations

CONTROLE-COMMANDE
Actions

Procédé

-Figure 16.7- Modèle Supervision/contrôle commande. Le couplage descendant, de SUPERVISION vers CONTROLE-COMMANDE nécessite 2 catégories d'informations: - des paramètres, qui vont qualifier les objectifs à atteindre pour la partie physique : température de consigne, temps de réponse... - des ordres, qui sont des événements avec association ou non d'informations, pour désigner les opérations que doit entreprendre la partie CONTROLE-COMMANDE. Le couplage ascendant de CONTROLE-COMMANDE vers SUPERVISION nécessite aussi 2 catégories d'informations: - des observations qui, synthétisées par la partie CONTROLE-COMMANDE, permettront de suivre le déroulement des opérations. - des réactions, pour signaler au niveau supérieur des situations particulières à prendre en compte. Les entrées et sorties pour l'exploitation sont associées à la supervision. Les autres entrées et sorties sont associées à la partie contrôle_commande. 16.3.3. La méthode Pour l'emploi de ce modèle, il faut commencer par décider si le modèle paraît approprié. L'expérience nous a montré que beaucoup d'applications, tout particulièrement celles faisant intervenir une exploitation sous toutes ses formes (utilisateurs, autres ...), et des entités physiques, peuvent se développer sur la base de ce modèle. Ce choix étant fait, la démarche est la suivante : - Identifier les entités liées à chacun des 2 niveaux. M.C.S.E 335

Partie 4 - CONCEPTION FONCTIONNELLE - Rechercher par analyse des spécifications, les variables de couplage nécessaires: paramètres dans un sens, observations dans l'autres sens. - Rechercher ensuite les événements de couplage, c'est-à-dire les ordres dans un sens, les réactions dans l'autre sens. - Dessiner la structure fonctionnelle en la complétant: toutes les relations de couplage, et les liens de toutes les entrées et des sorties avec l'une ou l'autre des parties. - Vérifier la solution pour s'assurer que toutes les spécifications seront satisfaites. 16.3.4. Exemples Dans ce paragraphe, on se contentera simplement d'analyser les solutions proposées dans le chapitre précédent pour la commande en rotation du centrifugeur (15.4.3) et pour l'automatisation du chariot filoguidé (15.4.4). Au vu de la première décomposition fonctionnelle, 2 fonctions ont été trouvées après avoir déterminées les variables internes essentielles pour la solution. Les structures fonctionnelles proposées sont conformes au modèle SUPERVISION/CONTROLE-COMMANDE. Ainsi, plutôt que de chercher sans guide précis les variables internes nécessaires, un tel modèle favorise cette tâche en proposant 4 catégories de couplage. De plus, il est intéressant de constater que pour les 2 exemples, la partie CONTROLECOMMANDE est à nouveau décomposée en 2 classes de fonctions. La décomposition est à nouveau conforme au modèle supervision/contrôle-commande. Ainsi, le modèle est utilisable pour plusieurs niveaux de fonctionnalités. Lorsqu'il n'est plus approprié car trop proche de l'entité à contrôler, fort probablement le modèle précédent CONTROLEUR convient. C’est le cas pour la fonction ASSERVISSEMENT. Beaucoup d'exemples à caractère pédagogique, tels que: automatisation par chariot filoguidé, conduite de chauffage, commande d'ascenseur, ont été traitées sous les 2 formes, il y a quelques années sans connaissance du modèle, depuis en exploitant ce modèle. La qualité des solutions basées sur le modèle est incontestable au vu des critères de lisibilité, simplicité, couplage et cohérence. Pour des exemples industriels de plus grande dimension - cas de la conduite d'un bâtiment par une gestion technique centralisée possédant 500 entrées et sorties - un tel modèle permet d'effectuer une première approche globale orientée données essentielles pour l'application, puis permet d'approcher la solution détaillée par affinements successifs de chaque sous-ensemble en utilisant les 2 modèles cités. 16.4. MODELE CLIENT/SERVEUR 16.4.1. Principe Pour introduire ce modèle, plaçons-nous dans le cas d'applications réparties. Le modèle OSI (Open Systems Interconnection) a été formalisé par l’ISO (International Organization for Standardization) de manière à favoriser l'interconnexion de matériels hétérogènes comme support de réalisation. Il suggère de décomposer le couplage entre entités fonctionnelles selon les 7 niveaux hiérarchiques représentés figure 16.8. 336 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS

7

APPLICATION

6

PRESENTATION

5

SESSION

4

TRANSPORT

3

RESEAU

Communications
2 LIAISON

1

PHYSIQUE

-Figure 16.8- Les 7 niveaux du modèle OSI. Les niveaux: - Application, Présentation, Session - sont orientés obtention des fonctionnalités pour l'application. Les niveaux: - transport, réseau, liaison, physique - sont orientés communication. Ce modèle précise que, pour son fonctionnement chaque niveau doit disposer ou peut exploiter des services du niveau inférieur. Chaque niveau est responsable d’un ensemble de fonctions spécifiques. Ce principe, ainsi que l'idée des 7 niveaux, sont à la base du modèle client/serveur ci-après. 16.4.2. Le modèle Bien que plutôt approprié pour la définition de la réalisation dans le cas de fonctionnalités réparties, il nous a semblé souhaitable de proposer un tel modèle dans ce chapitre compte-tenu de son caractère général. Le modèle est du type vertical. Pour assurer sa fonctionnalité, une fonction doit disposer de services. Ainsi, la fonction à décomposer est partagée en 2 sous-ensembles: la fonction ellemême à assurer, les services nécessaires. Le couplage entre les 2 parties est alors du type événementiel avec transfert d'informations, ce qui se traduit par des relations par transfert de messages ou de données. Le modèle proposé est représenté figure 16.9. La fonction SERVICE peut elle-même se décomposer à l'aide du même modèle. C'est ainsi qu'il est possible de descendre de niveau en niveau, jusqu'à identifier des services existants, ou disponibles, ou connus. Le modèle OSI suggère la nature des services pour chaque niveau, chacun assurant une fonctionnalité différente des autres niveaux. M.C.S.E 337

Partie 4 - CONCEPTION FONCTIONNELLE

CLIENT

niveau i

interface i,i-1
SERVICE i

FONCTIONS niveau i-1

niveau i-1

interface i-1,i-2

Plusieurs services niveau i-2

-Figure 16.9- Le modèle client/serveur. 16.4.3. La méthode Tout d'abord, il faut identifier l'intérêt de ce modèle pour le problème à traiter. Généralement, il convient lorsqu'il s'agit de mettre en oeuvre des ressources pour satisfaire la fonctionnalité souhaitée. Ces ressources sont accessibles par des services, ou mises à disposition sous la forme de services. Pour cette classe de problèmes, la méthode suggérée est la suivante : - Identifier les services strictement nécessaires pour la fonction à réaliser. Pour cela, se baser par exemple sur le modèle OSI lorsqu'il s'agit d'un problème de communication. - Spécifier le comportement de la fonction cliente qui sollicite en se basant sur l'existence des services ci-dessus. - Spécifier ensuite le comportement des services pour répondre aux sollicitations du niveau supérieur. - Spécifier les informations de couplage nécessaires pour solliciter les services et les informations attendues en retour. Ceci permet de mettre en évidence l'interface entre les 2 niveaux. - Se basant sur le modèle de décomposition, décrire la solution fonctionnelle et les informations transitant par l'interface. - Vérifier la cohérence de la solution et son adéquation à satisfaire les objectifs. La même démarche peut à nouveau être utilisée pour décomposer la fonction offrant les services. Au préalable, il sera peut-être souhaitable de procéder à un raffinement du niveau sur la base d'un modèle fonctionnel du type horizontal. 338 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS 16.4.4. Exemple: transmission de message par liaison série Cet exemple ne sert que pour illustrer le modèle et la méthode. Normalement ce type de problème se traite durant l'étape de définition de la réalisation. Supposons qu'une application nécessite 2 fonctions F1 et F2 couplées par un port MESS pour un transfert de messages.
Site A Site B

Mess

F1

F2

-Figure 16.10- Exemple d'application répartie. Comme contrainte de réalisation, F1 et F2 sont distants. Le transfert entre F1 et F2 ne peut plus se faire directement par MESS. La solution nécessite d'avoir recours à un service de transfert de messages du site A vers le site B. En se basant sur le modèle client/serveur, la structure fonctionnelle est la suivante.
Site A Site B

F1

F2

Mess B Mess A

Interface

SERVICE TRANSPORT MESSAGES

-Figure 16.11- Raffinement de la solution sur la base du modèle. Il est intéressant de constater que la démarche conduit içi à raffiner le port MESS. On poursuit la décomposition fonctionnelle en recherchant la solution pour réaliser le transfert de chaque message. Chaque message étant une suite de caractères, les services nécessaires sont: réception et émission de caractères. De même, en poursuivant le raffinement, chaque caractère transmis sur un support de communication est une suite de bits. La solution complète détaillée jusqu'au support est donnée figure 16.12. Cette solution reste purement fonctionnelle, car aucune hypothèse n'est faite sur la taille des ports. Durant l'étape suivante, pour la définition de la réalisation, chaque port aura une taille limitée. Un asservissement producteur sur consommateur est alors probablement nécessaire, ce qui impose un couplage en retour entre Réception caractère et Emission caractère. M.C.S.E 339

Partie 4 - CONCEPTION FONCTIONNELLE

F1

F2

Mess A

Mess B

Interface messages

Service messages

Emission message

Réception message

Car A

Car B

Interface caractères

Service caractères

Emission caractère TxD

Réception caractère RxD

TxD

-Figure 16.12- Solution complète pour le transfert de messages. Les solutions pour ces problèmes sont plus simples à déduire à partir d'une solution purement fonctionnelle comme celle présentée ci-dessus que par une approche plutôt intuitive. 16.5. MODELE D’INTERACTIVITE Beaucoup d'applications nécessitent de développer une interface homme-machine pour le couplage du système avec les utilisateurs, la maintenance ... Une telle interface est différente des interfaces avec les entités physiques. L'utilisateur est particulier: d'une part, il est libre de ses actions et donc nécessairement, il faut filtrer celles considérées comme correctes pour l'application, d'autre part les informations échangées peuvent être très complexes et présentées sous des formes variées. 16.5.1. Principe Plusieurs formes de dialogue homme-machine existent. On peut citer: - le langage de commande: type MSDOS ou UNIX par exemple. - un dialogue question-réponse: dialogue piloté par le système - le dialogue par menus: tous types de présentation y compris les menus déroulants et les menus iconiques. - la manipulation directe. Cette forme est la plus sophistiquée. La manipulation directe consiste à représenter les objets de l'application et qui intéresseront l'utilisateur. Les actions sur les objets se font par désignation directe de l'objet puis de l'action à réaliser. 340 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS Ce principe se retrouve aujourd’hui disponible dans un environnement graphique multifenêtres avec utilisation d'une souris comme pointeur. La réalisation de telles interfaces est dérivée des travaux entrepris par XEROX autour du langage objet SMALLTALK. Dans ce langage, une interactivité par manipulation directe s'implante facilement en se basant sur la Métaphore MVC (Model-View-Controller) [MEVEL87]. Cette métaphore suggère que tout objet de l'application doit tout d'abord être représenté par un modèle interne. Ce modèle peut ensuite être présenté sous la forme d'une ou plusieurs vues. La manipulation de l'objet met en oeuvre un contrôleur interposé comme filtre entre les actions de l'utilisateur, le modèle et les vues. La figure suivante résume cette métaphore.
Actions sur les vues

Actions CONTROLEUR utilisateur

actions sur MODELE le modèle

représentation externe

PRESENTATION VUE

Observations pour utilisateur

représentation interne Etat des vues

-Figure 16.13- La métaphore MVC. 16.5.2. Le modèle Le modèle d'interactivité présenté dans ce paragraphe est dérivé de la métaphore MVC. La représentation interne d'un objet de l'application se traduit par une donnée ou une structure de données (modèle). La représentation externe ou vue, exploite les grandeurs du modèle de l'objet et des informations supplémentaires définissant la représentation externe. Les actions de l'utilisateur dépendent de la désignation sur la représentation externe. Ainsi, l'état de la vue est nécessaire pour décider des actions à entreprendre. Un tel modèle pour une vue se représente par la structure fonctionnelle ci-dessous.
PARAMETRES VUE Evenements

CONTROLEUR MODELE ETATS PRESENTATION DE LA VUE Représentation externe

(position) curseur
ETAT_VUE

-Figure 16.14- Le modèle d'interactivité pour une vue. Les événements peuvent être des appuis sur des poussoirs ou des boutons d'une souris. Les états peuvent être la position de la souris sur l'écran. M.C.S.E 341

Partie 4 - CONCEPTION FONCTIONNELLE La variable ETAT_VUE permet au contrôleur de différencier les actions demandées compte-tenu de la position du pointeur sur l'écran et donc relativement à l'objet représenté. Les actions possibles de CONTROLEUR concernent la modification du modèle, telles que les grandeurs et même la structure, ainsi que les paramètres de la vue. La fonction PRESENTATION_VUE, calcule à tout instant, une représentation externe du modèle interne en tenant compte des paramètres de représentation. Ainsi, si le modèle est modifié en temps-réel, sa représentation suivra. Ce modèle générique n'est que fonctionnel. Il n'exprime pas la technique de réalisation. La solution pour la réalisation se déduit ensuite de ce modèle. En particulier la fonction PRESENTATION_VUE devra être déclenchée uniquement sur modification du modèle ou des paramètres de la vue. 16.5.3. La méthode A partir des spécifications, il faut tout d'abord rechercher la forme d'interactivité souhaitée. Si la convivialité voulue implique la mise en oeuvre du principe de la manipulation directe, les phases suivantes sont suggérées: - Rechercher tout d'abord les objets de l'application impliqués dans l'interactivité, - Spécifier ces objets en recherchant les grandeurs caractéristiques puis définir une représentation interne, - Spécifier la ou les vues souhaitées pour ces objets. En déduire les paramètres de représentation et les états de la représentation externe, - Spécifier le comportement des fonctions PRESENTATION_VUE et CONTROLEUR. En déduire une description algorithmique. 16.5.4. Exemple Illustrons l'emploi de ce modèle par un exemple simple. On désire représenter en temps-réel le contenu de 2 cuves, l'une déversant dans l'autre par l'intermédiaire d'une vanne fermée ou ouverte et avec un débit réglable. L'utilisateur observe en temps-réel le niveau de chaque cuve. Il peut agir sur l'état de la vanne et peut aussi régler le débit. Les objets de l'application sont: - les 2 cuves, chacune modélisée par son diamètre et la hauteur, - la vanne avec son état et son débit quand elle est ouverte. La présentation souhaitée est la suivante :

ON OFF

Cuve 1

Vanne Débit

253
Cuve 2

-Figure 16.15- Présentation souhaitée pour l'interface homme-système. 342 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS L’interrupteur ON/OFF fixe la position de la vanne, le changement de position se fait en cliquant dessus. Le débit est indiqué par sa valeur numérique. Cette grandeur est modifiable sous 2 formes: en changeant la valeur numérique et ceci en pointant sur la zone contenant cette valeur, ou par les touches + ou -, en pointant dessus puis en appuyant sur la souris. L'état des 2 cuves est représenté par une présentation graphique. La vanne est représentée ouverte ou fermée suivant la position de l'interrupteur. Tous les objets de la vue -interrupteur, réglage du débit, les cuves- sont déplaçables en cliquant sur l'objet et en la déplaçant. Le relâchement fixe la position finale. La modélisation interne concerne: - l'état de l'interrupteur, - la valeur du débit, - la quantité dans chaque cuve. Les paramètres de la vue sont: - la position de l'interrupteur, - la position du réglage de débit, - la position de chaque cuve. L'état de la vue est caractérisée par: - la zone ou se situe l'interrupteur, - la zone de modification numérique du débit, - les zones pour les 2 poussoirs + et -, - les zones pour chaque cuve. La structure fonctionnelle est donc la suivante :
Paramètres Vue Etat poussoir souris CONTROLEUR Modèle position curseur des objets DE LA VUE PRESENTATION VUE

Etat_vue

-Figure 16.16- Structure fonctionnelle pour l’application. L'état du poussoir de la souris doit être observable à tout instant pour permettre les modifications par appui sur + ou - ou pour les déplacements d'objets. Cette variable peut aussi se remplacer par les 2 événements APPUI, RELACHEMENT. M.C.S.E 343

Partie 4 - CONCEPTION FONCTIONNELLE 16.5.5. Généralisation du modèle au cas multi-fenêtres Dans un environnement multi-fenêtres, une fenêtre représente un écran logique. Plusieurs objets et vues sont alors représentables. 2 niveaux sont alors à différencier: la gestion des fenêtres, la gestion des représentations dans chaque fenêtre. Le modèle ci-dessus peut servir comme base de structuration. Pour cela, il faut contrôler chaque objet, produire et contrôler sa vue dans une fenêtre. L'ensemble des vues constitue alors une modélisation logique des objets, qui doit être traduite en une présentation physique. La structure fonctionnelle étendue au cas multi-fenêtres est alors la suivante:
paramètres écran

Modèle des vues
Action V1 Contrôleur vue 1 objet 1 Présentation vue 1 Vue 1

Contrôleur Actions écran utilisateur
Action Vi Contrôleur vue i objet i Présentation vue i Vue i

Présentation Ecran écran

Etat_écran

-Figure 16.17- Structure fonctionnelle pour une présentation multi-fenêtres Un tel modèle doit favoriser la réalisation d’application graphiques interactives qui passent par la mise en oeuvre d’un gestionnaire multi-fenêtres. 16.6. RESUME Ce chapitre a permis de présenter des modèles génériques qui peuvent grandement aider le concepteur à entreprendre une décomposition fonctionnelle. La liste des modèles n'est pas bien sûr exhaustive, elle ne demande qu'à être enrichie. Toutefois, il ne faut pas confondre modèle générique et solution pour un problème précis. Les solutions développées pour d'autres applications ont l’avantage d’être directement réutilisables. Mais comme peu de problèmes sont similaires, le concept du modèle générique apparait essentiel. Les grandes lignes de ce chapitre sont rappelées ci-après: - Un modèle générique aide le concepteur à proposer une décomposition fonctionnelle de qualité. - Chaque modèle étant approprié pour une classe de problèmes, il faut tout d'abord rechercher le modèle le plus adéquat à partir des spécifications. 344 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS - Le modèle suggère de rechercher les données internes essentielles pour résoudre l'application. Cette approche est conforme aux principes énoncés pour la conception. - Chaque fonction d'un modèle peut à nouveau se décomposée par le même modèle ou par un autre modèle plus élémentaire. - Les modèles exposés couvrent les classes de problèmes suivants: contrôle en boucle fermée, hiérarchie en contrôle-commande, exploitation de ressources et communication, interactivité.

M.C.S.E

345

BIBLIOGRAPHIE 4

[ABBOTT-86] An integrated approach to software development R.J. ABBOTT WILEY -interscience publication- JOHN WILEY&SONS 1986 [CALVEZ-82] Une méthodologie de conception des systèmes multi-microordinateurs pour les applications de commande en temps-réel J.P. CALVEZ Thèse de Doctorat d'Etat, Université de NANTES, Novembre 1982 [DATE-86] An introduction to Database Systems. vol 1 C.J. DATE Addison-Wesley 4ième édition, 1986 [GALACSI-86] Les sytèmes d’information - Analyse et Conception GALACSI nom collectif DUNOD informatique 1986 [GALACSI-89] Conception de bases de données - Du schéma conceptuel aux schémas physiques GALACSI nom collectif DUNOD informatique 1989 [MEVEL-87] Smalltalk-80 A. MEVEL, T. GUEGUEN EYROLLES 1987 [PARNAS-85] A rational design process: How and why to fake it D.L. PARNAS, P.C. CLEMENTS IEEE Transactions on Software Engineering Vol SE-12 No 2, fev 1986, P.251-257 M.C.S.E 347

Partie 4 - SPECIFICATION D’UN SYSTEME [ROLLAND-88] Conception des systèmes d’information - La méthode REMORA C. ROLLAND, O. FOUCAULT, G. BENCI EYROLLES 1988 [ROTENSTREICH-86] Two-dimensional program design S. ROTENSTREICH IEEE Transactions on Software Engineering Vol SE-12 No 3 march 1986, P.377-384 [ROUVE-88] LOGISCOPE: Contribution à la maitrise de la qualité des logiciels C. ROUVE, M. VIALA Génie logiciel et systèmes experts No 12 juin 1988, P.36-44 [WARD-85] Structured Development for real-time systems P.T. WARD, S.J. MELLOR Vol 1: Introduction and Tools Yourdon Computing series -YOURDON PRESS- Prentice-Hall 1985

348

M.C.S.E

PARTIE

5

DEFINITION DE LA REALISATION

La troisième étape de la méthodologie a pour but de déterminer toutes les spécifications de la réalisation qu’il faudra entreprendre pour satisfaire les objectifs du système. Le travail à effectuer consiste à affiner, détailler, enrichir la solution fonctionnelle pour satisfaire de nouvelles contraintes exprimées par les spécifications technologiques. Cette étape est aussi appelée Conception Détaillée. Le point de départ est la solution fonctionnelle élaborée durant l'étape précédente, qui a la particularité d'être indépendante de la technologie. Comme résultat de cette étape, la réalisation se traduira par la mise en oeuvre en complémentaire, d'un ensemble matériel comme support d'exécution, et d'un ensemble logiciel spécifiant l'évolution imposée pour l'application. La démarche préconise: - d'introduire les interfaces technologiques, - de tenir compte de toutes les contraintes de temps des systèmes temps-réel, - de déterminer la répartition matériel/logiciel - de spécifier les caractéristiques de la partie matérielle et les règles d'implantation pour la partie logicielle. Cette partie présente tout d'abord le modèle d'exécution, troisième dimension du modèle global de description de toutes solutions (chapitre 17). Le chapitre 18 décrit le modèle d'intégration qui détaille la correspondance entre le niveau fonctionnel et le niveau exécution ainsi que les règles à respecter pour l'implantation du logiciel. Le chapitre 19 présente les objectifs à atteindre, les différents critères pour la réalisation, les principes et la démarche à suivre pour le développement de la solution. Les deux exemples sont traités à titre d’illustration.

M.C.S.E

349

Chapitre 17

LE MODELE D’EXECUTION

Une présentation rapide du modèle de description de toute solution faite dans la partie 1 a montré qu'en final une réalisation est composée de 2 parties: une partie matérielle qui engendre l'évolution des fonctions du système, une partie logicielle qui personnalise le comportement du matériel pour que l'évolution globale soit conforme aux spécifications détaillées de l'application. La partie matérielle doit être spécifiée. Ceci veut dire qu'il faut produire une description détaillée du matériel à mettre en oeuvre, sans qu'il s'agisse pour cela de schémas de cartes, de références de matériels. La description doit se limiter à l'expression des caractéristiques et contraintes des fonctions matérielles nécessaires, des liens entre ces fonctions. Cette description doit toutefois être suffisante pour que, durant la phase suivante de réalisation, un spécialiste ou une équipe puisse établir les schémas, choisir les matériels -sous-ensembles, cartes, composants- et réaliser. Ce chapitre a pour objectif de décrire le modèle d'exécution comme outil pour la spécification de la partie matérielle d'un système. Il présente tout d’abord le modèle d’exécution en caractérisant son comportement global, puis les spécifications de chaque type de constituant.

M.C.S.E

351

Partie 5 - DEFINITION DE LA REALISATION 17.1. CARACTERISTIQUES DU MODELE D’EXECUTION Le modèle d'exécution exprime un ensemble de règles que doit respecter toute spécification de la partie matérielle pour une réalisation. Pour la description d'un matériel existant connu par ses schémas, sous-ensembles, cartes, ce modèle favorise par abstraction, une vision macroscopique de ce matériel. Lorsqu'il s'agit de concevoir la partie matérielle, ce modèle définit l'ensemble matériel selon une vue purement externe, laissant ainsi le libre choix de toute solution technique répondant aux contraintes. Bien entendu, cette vue externe n'est plus indépendante de la technologie dans le sens des fonctions, mais se veut encore indépendante des composants du marché. 17.1.1. Le modèle d'exécution et ses constituants Le modèle d'exécution part de l'hypothèse que toute réalisation pour un système est composée: - de processeurs comme organes de transformation des informations, - de mémoires pour la sauvegarde et la conservation des données, - de noeuds de communication comme éléments intermédiaires pour le transit d'informations. Ces trois types d'éléments technologiques sont nécessairement liés entre eux. Ce modèle utilise 3 types de liens que sont: - la signalisation inter-processeurs pour le couplage direct des processeurs, - le partage de mémoire entre processeurs pour un couplage indirect sans relation d’ordre, - la communication inter-processeurs comme couplage indirect avec relation d'ordre, réalisée par l'intermédiaire d'un réseau de noeuds de communication. Ainsi le modèle d'exécution est une structure appelée STRUCTURE D'EXECUTION. L'exemple suivant permet de se faire une idée de ce modèle qui est de nature graphique.

P2 S1 E1 P1 M1 P2.2 S1 L2 P2.1

S3 N1

L1
N1 P1 N1 P2

P3

-Figure 17.1- Exemple de structure d'exécution. 352 M.C.S.E

Ch 17 - LE MODELE D’EXECUTION Cet exemple montre que processeurs et noeuds de communication peuvent eux-mêmes se décrire par une structure d'exécution. Une structure d'exécution est caractérisée par: - une description topologique sur la forme d'un réseau d'interconnexion d'éléments. - une spécification de chaque type d'élément et de chaque type de relation établie par les liens. Du type structurel, ce modèle permet une description hiérarchique. La composition du modèle d'exécution est représentée comme suit:
STRUCTURE D’EXECUTION SPECIFICATION DES CONSTITUANTS

Spécification
Description externe

Niveau 0

globale

Description interne

Niveau 1

Spécification processeurs,...

Niveau i

Spécification constituants de base

-Figure 17.2- Décomposition hiérarchique du modèle d'exécution. La partie organisationnelle est une structure d'arbre car chaque élément - processeur, noeud de communication - est décomposable selon une structure d'exécution. Les objets terminaux sont des éléments technologiques de base. Le niveau 0 délimite le support exécutif de l'application. La partie spécification des constituants caractérise tous les types d'éléments du modèle d'exécution: processeur pour chaque niveau de raffinement, noeud de communication et mémoire pour le niveau d'utilisation ainsi que le rôle de la relation pour le niveau de décomposition de la structure d'exécution. 17.1.2. Signification des éléments et des relations Avant de détailler les règles du modèle, prenons connaissance des types d’éléments et de relations ainsi que de leurs significations. L'exemple précédent a permis de constater la notation graphique et le niveau de description que permet une structure d'exécution. Il est intéressant d'avoir à l'esprit, et tout particulièrement pour l'interprétation du rôle de chaque constituant, la similitude entre une structure fonctionnelle et une structure d'exécution. M.C.S.E 353

Partie 5 - DEFINITION DE LA REALISATION Cette caractéristique s'explique car la structure d'exécution est le moteur pour l'évolution d'une structure fonctionnelle. Ainsi les actions du niveau fonctionnel évoluent grâce aux processeurs, les relations fonctionnelles sont assurées par l'intermédiaire de signalisations, de mémoires, de noeuds de communication.
-A- PROCESSEUR

Le terme PROCESSEUR est utilisé ici dans son sens le plus général. C'est tout d'abord un objet dynamique qui a sa propre autonomie. Ainsi, il est en mesure d'assurer lui-même son rôle lorsqu'il le souhaite. Son activité dépend de sa fonctionnalité: globalement, il assure des transformations sur les informations en entrée pour produire des informations en sortie. Les processeurs peuvent se classer en 2 catégories: - les processeurs généraux (programmables), - les processeurs spécialisés (paramétrables ou non-paramétrables). Les processeurs généraux sont programmables ce qui permet de particulariser leurs fonctionnalités. Cette programmation se fait par du logiciel. Ainsi sont considérés comme processeurs programmables: les microprocesseurs, les microcontrôleurs, les mini et microordinateurs, les systèmes informatiques. Le terme processeur inclut ici tous les éléments nécessaires pour son fonctionnement: par exemple pour le microprocesseur s'ajoutent la mémoire locale pour les programmes et les données, les entrées/sorties. Un processeur spécialisé a une fonctionnalité propre non modifiable. Des paramètres peuvent par contre être modifiés pour moduler la fonctionnalité. Entrent dans cette catégorie: les composants VLSI spécialisés, des ensembles programmés, à un niveau moindre des composants numériques et analogiques tels que additionneur, multiplieur, transposeur de fréquence, etc et tout type d'interfaces: générateur PWM, horloge programmable...
-B- MEMOIRE

Une mémoire est un objet passif. Elle mémorise une information de tout type transmise par un processeur, et sur demande fournit sa valeur.
-C- NOEUD DE COMMUNICATION

Un noeud de communication est un objet actif servant d'intermédiaire entre un ensemble de canaux de communications liés aux processeurs. Son rôle est de diriger vers le bon destinataire chaque information qu'il reçoit. Les informations reçues, qui sont alors des messages, sont temporairement mémorisées, analysées, puis retransmises par les canaux de sortie. Pour un message donné, un délai peut exister entre son entrée et sa sortie. Un noeud de communication peut être de complexité très variée. Pour le plus simple, une entrée et une sortie sans mémoire, il s'agit simplement d'une liaison directe. Pour les plus complexes, un noeud est lui-même un réseau de noeuds de communication tel que par exemple le réseau TRANSPAC.
-D- SIGNALISATION INTER-PROCESSEURS

Chaque processeur décide à tout instant de son activité. Certaines activités nécessitent des couplages avec l'environnement respectant des relations d'ordre. La signalisation interprocesseurs permet d'assurer des synchronisations entre des activités réparties sur des processeurs différents. Elles se réalisent pour le matériel par des signaux de contrôle, des lignes d'interruption. 354 M.C.S.E

Ch 17 - LE MODELE D’EXECUTION
-E- PARTAGE DE MEMOIRE

Un processeur peut utiliser une mémoire externe pour déposer ou consulter de l'information. Lorsqu'une mémoire est accessible par au moins 2 processeurs, des échanges d'informations sont possibles par ce type de relation. Ainsi, synchronisation, transfert de messages sont possibles par ce mécanisme, mais comme la mémoire est un objet passif, les relations temporelles ne s'obtiennent que par une consultation régulière de la part de processeurs.
-F- COMMUNICATION INTER-PROCESSEURS

Ce type de relation est approprié pour le transfert de messages entre processeurs. Un message produit par un processeur par un canal de sortie sera dirigé par le noeud ou le réseau de noeuds de communication vers le processeur destinataire désigné dans le message. Un noeud de communication permet de faire du point à point (un seul destinataire), ou de la diffusion (un ensemble de destinataires). 17.2. LE MODELE DE STRUCTURE D’EXECUTION Une structure d'exécution est l'expression topologique par un réseau d'éléments d'un support matériel (on utilisera parfois la notation S.E). Dans la suite du paragraphe sont décrits tout d'abord les conventions de représentation (vue statique), puis l'interprétation de chaque symbole en spécifiant son comportement vis à vis de son environnement (vue dynamique). 17.2.1. Représentation graphique La représentation d'une structure d'exécution décrit la décomposition d'un élément du type processeur ou noeud de communication. Ainsi chaque élément à décrire possède des entrées et des sorties. Le raffinement d'un élément se décrit à partir de 4 types d'éléments: - des processeurs, représentés chacun par un rectangle
P

- des mémoires, représentées par le symbole:

M

- des signalisations représentées par:

S

- des noeuds de communication représentés par:

N

Les relations sont toutes entre processeurs. Elles ne sont possibles que par un élément intermédiaire du type: signalisation, mémoire, noeud de communication. M.C.S.E 355

Partie 5 - DEFINITION DE LA REALISATION Les 3 types de relations autorisées utilisent des symboles spécifiques pour les liens: - pour la signalisation: - pour l'accès à une mémoire: - pour le transfert des messages: Voici un exemple de structure d'exécution représentant le support matériel pour une application répartie nécessitant sur l’un des sites, une architecture multi-processeurs.

P2

P2.1

N1 P1 MC

S1 S2

N2

P2.2

Site A

Site B

-Figure 17.3- Exemple de Représentation d'une Structure d'exécution. Les liens sont unidirectionnels sauf pour les accès à la mémoire MC. Un lien doit exister entre chaque processeur et noeud (N1-->P2.1 et N1-->P2.2). Une signalisation peut être produite et exploitée par plusieurs processeurs. Un processeur de la structure d'exécution peut se raffiner par une structure d'exécution (cas de P2). Il en est de même pour un noeud. Les règles de bon sens énoncées pour la cohérence et la lisibilité d'une structure fonctionnelle sont aussi applicables à une structure d'exécution: - commandabilité et observabilité de tous les éléments: utilisation de toutes les entrées et sorties, participation de tous les éléments dans une relation. - choix d'un nom signifiant pour tous les constituants: le nom doit avoir un rapport explicite avec la fonctionnalité et le rôle joué. - qualité de la présentation: limitation de la complexité de chaque niveau de raffinement, représentation des relations de la gauche vers la droite. 356 M.C.S.E

Ch 17 - LE MODELE D’EXECUTION 17.2.2. Interprétation d'une S.E Pour que la compréhension d'une représentation soit sans ambiguïté, nous donnons ci-après une explication du rôle joué par chaque constituant d'une structure d'exécution. Ceci revient à modéliser le comportement en externe de chaque type de constituant.
-A- COMPORTEMENT POUR LES PROCESSEURS

Les règles suivantes caractérisent le comportement de chaque processeur: - Un processeur en état de fonctionnement est toujours en activité. Les cas de panne, de non-alimentation, se traduisent par la disparition du processeur dans la structure d'exécution. - Contrairement à l'hypothèse adoptée pour les temps de déroulement des fonctions du modèle fonctionnel, la durée d'exécution des opérations pour un processeur n'est pas nulle mais finie. Ces temps sont définis par les spécifications du processeur. - Un processeur peut à tout instant lire ou modifier le contenu des mémoires qui lui sont connectées. Pour chaque accès, il désigne l'information concernée. - Un processeur peut à tout instant générer des signaux par ses sorties et transmettre des messages par ses canaux de communication en sortie. - Lorsqu'il le désire, un processeur peut modifier son activité sur détection d'une signalisation ou sur existence d'un message disponible sur l'un de ses canaux de communication en entrée. Ainsi, le processeur est toujours maître de son activité.
-B- REGLES POUR LES MEMOIRES

Chaque mémoire se charge d'identifier si la variable concernée par la désignation lors d'un accès lui appartient. Si c'est le cas, elle assure soit la mémorisation, soit la lecture suivant le sens de l'accès. La durée de chaque accès n'est pas nulle mais généralement faible. Les accès dans le cas de demandes simultanées supposent que les contraintes d'intégrité se trouvent respectées. Ces conflits potentiels devront être résolus par la réalisation.
-C- COMPORTEMENT POUR LES NOEUDS DE COMMUNICATION

Un noeud de communication peut posséder plusieurs entrées et plusieurs sorties. Chaque entrée est liée à un processeur de manière à offrir un canal de communication. Il en est de même pour chaque sortie. Tout message émis par un processeur est accepté dans son intégralité par le noeud de communication. Tout message demandé est aussi accepté dans son intégralité. Un message pour la communication est donc indivisible. Chaque message est porteur des informations de routage, à savoir: le destinataire et l'émetteur. 2 types de communications sont possibles par un noeud de communication. - le transfert POINT à POINT: un message ne concerne qu'un seul destinataire. - le transfert pour DIFFUSION: un message concerne un ensemble de destinataires. Dans ce cas, le noeud génère un message vers chaque destinataire. L'identification du type de communication est aussi précisée dans le message. Un délai quelconque peut exister entre la réception d'un message et sa restitution par le noeud. Ainsi le temps de transfert n'est pas connu à l'avance. Un noeud est toujours en activité. En cas de panne, il disparaît de la structure d'exécution. M.C.S.E 357

Partie 5 - DEFINITION DE LA REALISATION Un noeud de communication n’assure aucune transformation de l’information. Il peut par contre modifier sa présentation.
-D- REGLES POUR LES SIGNALISATIONS

Toute signalisation sensibilise tous les processeurs liés. Mais elle n'est prise en compte que si les destinataires le désirent. 17.2.3. Raffinement et abstraction d'une structure d'exécution. Le modèle de structure d'exécution est hiérarchique. Un élément peut se décrire sur la base d'éléments plus simples. En sens inverse, un élément utilisable peut résulter d'une structure. On parle alors de processeur ou noeud de communication logique ou virtuel. Raffinement et abstraction sont utilisables pour les processeurs et pour les noeuds de communication. L'exemple ci-dessous représente plusieurs niveaux de description. On peut montrer très facilement que toute structure d'exécution au niveau le plus microscopique peut se construire à l'aide uniquement: de processeurs, de mémoires, de signalisations et de 2 types de relation. La relation par noeud de communication ajoutée au modèle et construite à l’aide d’une mémoire et de signalisations, apporte l'avantage d'une spécification à un niveau plus macroscopique.
P0 N1 P1 P2

P2 N1.P1 P2.1

P2.1

-Figure 17.4- Niveaux hiérarchiques d'une structure d'exécution.
-A- CAS DES PROCESSEURS

Pour la décomposition d'un processeur, tous les types d'éléments et de relations sont utilisables. Le raffinement doit s'arrêter lorsque les constituants sont clairement et suffisamment spécifiés pour la phase de réalisation. La connaissance des possibilités fonctionnelles offertes par des composants, sous-ensembles, systèmes, s'avère nécessaire pour éviter un excès de raffinement. 358 M.C.S.E

Ch 17 - LE MODELE D’EXECUTION Par abstraction, le concepteur peut définir un processeur ou un noeud de communication. Pour ce deuxième cas, la fonctionnalité se trouve définie par les règles de comportement décrites dans le paragraphe précédent. D'autre part, les liens avec l'environnement ne peuvent être que du type liens de communication.
-B- CAS DES NOEUDS DE COMMUNICATION

La décomposition d'un noeud de communication peut se traduire: - par un réseau de noeuds de communication, - par une structure d'exécution incluant des processeurs. Dans ce deuxième cas, le rôle de la structure se limite à servir de support pour satisfaire les fonctionnalités de communication du noeud. L'abstraction a pour objectif de construire des noeuds de communication à partir d’un ensemble de processeurs. La technique de raffinement ou d'abstraction pour un noeud de communication est illustrée par la figure suivante.
L1 N L4 L2 ABSTRACTION RAFFINEMENT L3

N1

N3

N2

L20 N0

L04

N4

N0 L20 P1 P2 L04

-Figure 17.5- Niveaux de description pour un noeud de communication. 17.3. SPECIFICATION DES CONSTITUANTS POUR LA REALISATION Après avoir décrit le comportement de chaque type d’élément de manière à disposer d’une représentation graphique non-ambiguë, détaillons maintenant les spécifications nécessaires pour chaque constituant pour permettre de déduire sa réalisation. La structure d'exécution ne peut servir de spécification pour la réalisation matérielle que si tous les constituants sont décrits par leurs caractéristiques externes. Une spécification doit être suffisante pour déterminer une solution matérielle pour sa réalisation. On passe, ci-après en revue chaque catégorie de constituant pour préciser sa spécification. M.C.S.E 359

Partie 5 - DEFINITION DE LA REALISATION 17.3.1. Spécification d'un processeur Pour un processeur, la spécification est particulièrement variable compte-tenu du caractère général associé à ce terme. Un processeur spécialisé est caractérisé par: - la spécification de ses entrées et ses sorties sur le plan type et nature de l'information, - sa fonctionnalité: tous les modèles de spécification présentés dans ce document sont bien sûr utilisables. Par exemple: gabarit en fréquence pour un filtre analogique, la précision, et la vitesse de conversion pour un convertisseur numérique/analogique. Un processeur général programmable est caractérisé par: - la spécification de ses entrées et ses sorties, - la spécification de tous les attributs du processeur, à savoir: la capacité mémoire pour les instructions, pour les données, la classe de processeur (8, 16, 32 bits), la performance pour des opérations type, - la spécification de fonctions internes nécessaires pour l'application: horloge programmable, compteurs, calcul en flottant, ainsi que les fonctions nécessaires pour les entrées/sorties: conversion analogique/numérique, transmission-réception série ... En fait, un processeur programmable peut se décrire par des spécifications très variées. Il est possible de cette manière de réduire le travail de raffinement d'une structure d'exécution. Ceci va dans le sens de l'évolution de la technologie qui met de plus en plus à notre disposition des processeurs intégrant dans un seul composant une variété de fonctions spécialisées en complément de la fonction typique du microprocesseur comme unité centrale de traitement. 17.3.2. Spécification d'une mémoire Une mémoire est caractérisée par: sa capacité en nombre d'informations (octet comme unité), la taille de chaque information manipulée par accès, le nombre d'accès simultanés en lecture, en écriture, le temps maximum pour chaque accès.

17.3.3. Spécification d'un noeud de communication Un noeud de communication est caractérisé par : - le nombre d'entrées et de sorties et le type d'information échangée. Un type spécifique peut s'associer à chaque entrée ou sortie, mais il est plus réaliste de se limiter si possible à un seul type de messages. - la capacité de mémorisation du noeud en nombre de messages. Cette capacité peut être globale ou spécifique pour chaque paire d'entrée/sortie. - les performances en traitement des messages. Cette performance peut par exemple s'exprimer par un temps moyen de transit ou un nombre minimum de messages transférables par unité de temps. 360 M.C.S.E

Ch 17 - LE MODELE D’EXECUTION 17.4. PROPRIETES DU MODELE D’EXECUTION L'objectif du modèle d'exécution est de servir comme guide pour l'élaboration des spécifications du support matériel pour une application. Citons rapidement les propriétés essentielles de ce modèle.
-A- MODELE DE STRUCTURE

Tout comme le modèle fonctionnel, le modèle d'exécution est hiérarchique. Il favorise donc la compréhension ou la recherche progressive de la solution. Les techniques de raffinement et d'abstraction permettent, pour la première, d'introduire des contraintes supplémentaires pour la réalisation matérielle, pour la seconde, de favoriser la réutilisation par la spécification de processeurs logiques ou virtuels.
-B- MODELE INTERPRETABLE

La seule connaissance des règles de comportement des constituants et leurs spécifications est suffisante pour déduire une solution technologique pour la réalisation matérielle. Ce document est donc suffisant comme interface entre l'étape de définition de la réalisation et l'étape suivante de réalisation. De par sa simplicité, il favorise la lisibilité ce qui est favorable pour la vérification et l’utilisation.
-C- INVARIANCE D’ECHELLE

Ceci veut simplement dire que le modèle permet aussi bien de décrire les spécifications de solutions à un niveau très proche des composants, et même la structure interne de composants, registres, réseaux combinatoires, horloge ... ,que des spécifications de systèmes à un niveau très macroscopique: application répartie utilisant des calculateurs, réseau local, réseau de télécommunication.
-D- SIMILITUDE : MODELE FONCTIONNEL/MODELE D’EXECUTION

Il y a similitude de représentation des 2 modèles. Cette caractéristique est particulièrement favorable pour passer de l'étape 2: solution fonctionnelle, à l'étape 3: définition des constituants de la réalisation. Dans le cas le plus direct, il suffit simplement de considérer une structure d'exécution de topologie identique à celle de la structure fonctionnelle.
-E- MAXIMUM DE PARALLELISME

Lorsqu'une structure d'exécution est complètement détaillée, et en considérant que chaque processeur n'exécute qu'une seule opération à la fois, le degré maximum de parallélisme est égal au nombre de processeurs élémentaires. Si les performances ne s'avèrent pas suffisantes, il faut revoir la structure d'exécution en augmentant soit le nombre de processeurs, soit les performances de certains processeurs.
-F- INTRODUCTION DE REDONDANCES ET DE TESTS

Une structure d'exécution peut s'enrichir de constituants supplémentaires de manière à répondre à des contraintes telles que sûreté, testabilité, maintenabilité ... Ceci se traduirait par exemple, par une duplication de processeurs (ou 3 pour le vote majoritaire), ou par une duplication de chemins de transfert d'information. La déduction des constituants supplémentaires nécessaires se fait en considérant les situations de pannes probables et qui ne doivent pas dégrader les caractéristiques de l'application. M.C.S.E 361

Partie 5 - DEFINITION DE LA REALISATION 17.5. RESUME Ce chapitre a permis de présenter le modèle de description utilisé pour spécifier la 3ème dimension dite exécutive du modèle global. Rappelons les conclusions essentielles: - le modèle d'exécution est composé de 2 ensembles d'information: la structure d'exécution, la spécification de tous les constituants pour la réalisation, - les techniques de raffinement et d'abstraction sont utilisables pour définir les spécifications d'un processeur ou d'un noeud de communication, - la décomposition ne doit pas être poursuivie trop loin. Elle doit simplement favoriser la recherche de la solution matérielle détaillée sans imposer de contraintes de choix supplémentaires par rapport aux spécifications technologiques. - le modèle d'exécution n'est pas suffisant pour la réalisation puisqu'il ne concerne que la partie matérielle. Il faut y ajouter la spécification du logiciel pour les processeurs programmables. C'est l'objectif du modèle d’intégration décrit dans le chapitre suivant.

362

M.C.S.E

Chapitre 18

LE MODELE D’INTEGRATION

Une description fonctionnelle exprime une solution indépendante de la technologie pour l'application considérée. Une structure d'exécution décrit le support matériel. Pour compléter la définition d'une réalisation, il faut y ajouter la correspondance fonctionnel —> matériel et la description de la partie logicielle. L'organisation du logiciel découle: d'une part de la description fonctionnelle qui exprime l'objectif à satisfaire, d'autre part de la structure d'exécution retenue comme support opérationnel. Le modèle d'intégration a pour objectif de spécifier complètement l'implantation d'une description fonctionnelle sur une structure d'exécution. Si dans la démarche de conception le but est de déduire une structure d'exécution et une implantation à partir d’une description fonctionnelle, pour la présentation du modèle d’intégration, on se place ici dans le cas où la description fonctionnelle et la structure d'exécution sont données. Comme le montre ce chapitre, l'intégration concerne 2 niveaux: le niveau structure d'exécution et le niveau processeur. Pour le niveau global, la structure fonctionnelle complète doit s’implanter sur la structure d’éxécution. Pour chaque processeur programmable, la fonctionnalité résulte d’une implantation sous la forme d’un schéma d’organisation du logiciel.

M.C.S.E

363

Partie 5 - DEFINITION DE LA REALISATION 18.1. LE MODELE D’INTEGRATION ET SES CONSTITUANTS Le modèle d’intégration spécifie deux niveaux d’implantation. Tout d'abord, étant donné un support d'exécution, chacun de ses constituants est le support opérationnel pour un ou plusieurs constituants de la structure fonctionnelle: - un processeur pour une structure fonctionnelle partielle, - une mémoire pour des variables d'état, - un noeud de communication pour les ports. Cette correspondance S.F.-->S.E. représente l'ALLOCATION. Ensuite, pour chaque association du type: processeur général<-->structure fonctionnelle partielle, la fonctionnalité est obtenue par logiciel. Aussi dans ce cas, les règles d'implantation de la structure fonctionnelle sur le processeur sont à exprimer. Ainsi le modèle d'intégration est constitué de 2 parties: - le modèle d'allocation qui décrit la correspondance entre une structure fonctionnelle et une structure d'exécution, - le modèle d'implantation qui décrit les règles d'implantation de chaque sousensemble de la description fonctionnelle réalisé par logiciel sur le processeur programmable alloué comme support. La composition du modèle d'intégration est représentée ci-après.
FONCTIONNEL INTEGRATION EXECUTIF

Structure fonctionnelle

Allocation

Structure d’éxécution

Sous-ensembles fonctionnels

implantation

constituants

Structure fonctionnelle partielle pour les processeurs programmables Implantation Processeur

Implantation logicielle

-Figure 18.1- Les constituants du modèle d'intégration. Pour une application donnée, il n'existe qu'une seule définition de l'allocation: elle exprime l’ensemble des relations entre les constituants de la structure fonctionnelle et ceux de la structure d’éxécution. Mais il existe autant de définitions d'implantation que de processeurs généraux. 364 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.2. LE MODELE D’ALLOCATION La similitude des modèles - structure fonctionnelle, structure d'exécution - favorise la correspondance entre les 2 structures. Chaque structure est composée d'éléments et de relations entre ces éléments. Ainsi, le modèle d'allocation détaille les correspondances entre éléments des 2 structures et les contraintes de correspondance à respecter. 18.2.1. Correspondance entre les éléments des 2 structures La correspondance entre éléments est la suivante : structure fonctionnelle partielle (SF) variables (VE) événements (EV) ports (PT) liens: fonction <-->EV,VE,PT --> --> --> --> --> processeur (P) mémoire (M) signalisation (S) noeud de communication (N) lien: processeur <-->S,M,N

Les règles ci-après sont à respecter pour toute correspondance: - Une fonction élémentaire est une unité de description et de répartition. De ce fait elle est indivisible pour l'implantation. Son activité résultera de l’utilisation d’un seul processeur. Si cette hypothèse n’est pas possible, la décomposition fontionnelle doit être poursuivie. Cette situation peut apparaitre pour des applications de grandes performances ou à fortes contraintes de temps. - Les variables d'état et les messages sont aussi des objets indivisibles. - Processeur, mémoire, noeud de communication peuvent chacun supporter plusieurs éléments, respectivement : fonctions, variable d'états, ports. - Un processeur général est le support d'une structure fonctionnelle partielle ou complète. Les 2 premières règles ci-dessus indiquent que la décomposition fonctionnelle a été poussée suffisamment loin pour permettre l'intégration. Les 2 dernières règles indiquent la possibilité de réduire la complexité d'une structure d'exécution. En effet, un processeur programmable est généralement trop puissant comme support pour uniquement une fonction élémentaire. Il en est de même pour la capacité d'une mémoire ou d'un noeud de communication. La réduction du coût du support matériel passe par la réduction du nombre de processeurs, de mémoires, de noeuds de communication, ce qui réduit simultanément le nombre de liaisons physiques à réaliser. La réduction essentielle s'obtient en implantant sur chaque processeur une structure fonctionnelle la plus importante possible. L'exemple suivant montre 2 formes: la première graphique, la deuxième textuelle pour décrire les correspondances entre éléments. M.C.S.E 365

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle Structure d’exécution E1 V1 A1 A2 P1 S1

V2

V4

E3

M1 P3

A3

A4 N1 P2 V3

PT1 A5

-Figure 18.2- Description d'une correspondance entre éléments. Pour les éléments: S1 P1 M1 P2 P3 N1 et pour les liens: P1->M1 P2->N1 N1->P3 (M1->P2) (M1->P3) (P3->S1) (S1->P1) <=== <=== <=== <=== <=== <=== <=== (A1->V2, A1->V4) (A3->PT1) (PT1->A5) V2->A3 V4->A4 A4->E3 E3->A2 <=== <=== <=== <=== <=== <=== (E3) (SF[A1, A2, E1, V1]) (V2, V4) (A3) (A4, A5) (PT1)

Cet exemple montre que tous les éléments d'une structure fonctionnelle doivent obligatoirement avoir un correspondant sur la structure d'exécution. Par contre, étant donné une structure d'exécution, tous les éléments ne servent pas obligatoirement pour l'application. 366 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.2.2. Contraintes pour une allocation Une allocation n’est correcte pour l’application que si pour les correspondances retenues, des règles sont garanties. 2 types de règles sont à respecter: - tout d'abord comme un processeur peut servir de support exécutif pour plusieurs fonctions, celui-ci doit être apte à engendrer les évolutions souhaitées en respectant toutes les contraintes de temps. Le respect de cette règle exprime le fait que chaque processeur est OPERATIONNEL pour l'allocation retenue. - ensuite la correspondance entre les éléments des 2 structures n'est correcte que si toutes les relations de la structure fonctionnelle sont réalisables par la structure d'exécution. Dans ce cas, on dira que la structure fonctionnelle est ACCEPTEE par la structure d'exécution. Détaillons dans la suite du paragraphe, les règles de vérification pour chaque catégorie.
-A- PROCESSEUR OPERATIONNEL

Un processeur sert de support exécutif pour une ou plusieurs actions. S'agissant d'applications temps-réel, des contraintes de temps sont associées à chaque action: fréquence d'activation, durée d'exécution maximale ou date de fin pour les actions temporaires, performances pour les actions permanentes. Un processeur est dit OPERATIONNEL pour une allocation donnée si toutes les actions sont effectuées et si toutes les contraintes de temps sont satisfaites pour la réalisation qui découle de cette allocation. Le caractère opérationnel dépend de plusieurs facteurs: - la complexité de la structure fonctionnelle à supporter : nombre et nature des actions et des opérations, - les contraintes de temps à respecter, - la performance du processeur. Une allocation se modifie en changeant les correspondances, et/ou en changeant les spécifications du processeur. Les règles pour la vérification seront détaillées dans le chapitre suivant en 19.5. On retiendra pour l'instant les 2 règles suivantes : - le taux d'occupation maximum du processeur pour toutes les actions temporaires (i=1,n) doit rester inférieur à 1: Tocc = Σi FAi*TEi < 1. Pour une action, le taux d'occupation maximum (Tocci) est le produit de sa fréquence d'activation maximale (FAi) par son temps d'exécution maximum (TEi). Le taux dépend donc de la performance du processeur par le terme TEi. - les durées d'exécution maximales, dates de fin (deadline), les temps de réaction sur événement externe sont toujours satisfaits. La figure 18.3 illustre le déroulement sur un même processeur de deux actions concurrentes pour une exécution de A1 plus prioritaire que A.
-B- STRUCTURE FONCTIONNELLE ACCEPTEE

Pour l'implantation, les relations fonctionnelles internes à un processeur sont réalisées par celui-ci. Par contre, les relations entre 2 processeurs nécessitent des liens matériels entre ces processeurs. M.C.S.E 367

Partie 5 - DEFINITION DE LA REALISATION

Objectif à satisfaire
ev1 A1 TE1 ev2 A2 TE2

TA1

TA2 Tdeadline A2

Implantation de A1 et A2 sur un même processeur
priorité

ev1

A1 ev2 A2

TFin < Tdeadline A2

Temps disponible => Tocc < 1

-Figure 18.3- Illustration des 2 règles pour une allocation. Pour vérifier qu'une structure fonctionnelle est acceptée par une structure d'exécution, il faut utiliser les correspondances entre éléments pour construire une structure fonctionnelle réduite. La réduction est obtenue par une opération d'abstraction qui consiste à regrouper tous les constituants (fonctions, variables, ports) implantés sur un même processeur. La structure ainsi obtenue doit être inclue au sens des graphes dans la structure d'exécution. Ceci veut dire qu'il faut au moins un lien au niveau exécutif comme support pour chaque lien fonctionnel. La figure 18.4 montre cette démarche de vérification. 18.3. LE MODELE D’IMPLANTATION POUR CHAQUE PROCESSEUR Pour les processeurs programmables, l'allocation définit le sous-ensemble fonctionnel implanté sur chaque processeur. Le modèle d'implantation définit les règles de présentation des constituants de ce sous-ensemble fonctionnel pour exprimer l'organisation de tous les constituants du logiciel. Le logiciel implanté sur un processeur est décomposable en 2 niveaux: - le niveau TACHES: une tâche est une entité composée d'instructions et de données, ayant sa propre autonomie. Pour le processeur, la tâche est manipulée comme un tout: activation, arrêt, suspension. Une tâche assure généralement une fonction ou une action de l'application. Son comportement est séquentiel. L'état d'une tâche défini par une variable appelée vecteur d'état, est mémorisé entre 2 activations successives. Une tâche a donc un effet mémoire. 368 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION

E1 V1 A1
1 2

S1 A2
1 A*1 2

P1 E3 M1 P3

V*1 V2 V4 E3

A3

A4

A*2

A*3 N1 P2

V3 PT1 A5

W*1

Structure fonctionnelle

Structure fonctionnelle réduite SF*

Structure d’exécution

-Figure 18.4- Correspondances: S.F. globale, S.F. réduite et S.E. - le niveau MODULES ou PROCEDURES. Un module est un ensemble d’instructions activé comme une unité par une tâche, pour satisfaire une fonction ou une opération. La tâche étant séquentielle, un seul module est actif à la fois. Un module est sans effet mémoire, ce qui veut dire que ses variables internes ont la durée d'exécution du module. Le niveau TACHES concerne un ensemble de tâches. L'évolution est donc potentiellement parallèle. Or, habituellement un processeur est séquentiel. Aussi une stratégie d'ordonnancement pour le partage du processeur par les tâches est donc nécessaire pour que, vue par l'application, l'évolution de l'ensemble des tâches apparaisse parallèle. Pour le niveau MODULES, chaque tâche se décompose comme une hiérarchie de modules. Le modèle d'implantation a pour objectif de proposer pour chaque processeur programmable un moyen de description pour les 2 niveaux: TACHES et MODULES. La composition du modèle est représentée par la figure 18.5. 18.3.1. Implantation des tâches Le niveau tâche explique l'implantation retenue pour une structure fonctionnelle donnée sur un processeur. Le parallélisme inhérent à la structure fonctionnelle (normalement égal au nombre de fonctions) est habituellement supérieur à celui-ci du processeur qui très souvent est de 1. Ensuite les relations entre les fonctions -par événement, par variable d'état, par port- ne sont pas des mécanismes directement supportés par le processeur. Enfin, le processeur couplé à son environnement doit satisfaire par des liens matériels les relations fonctionnelles existant entre la structure fonctionnelle qu'il supporte et l’environnement de celle-ci. L'implantation est représentée graphiquement par un réseau de tâches. Les tâches sont liées entre elles par des variables d'état, des transferts de contrôle, et sont liées avec l'environnement par des variables et des événements en entrée et sortie. M.C.S.E 369

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle partielle Implantation

Processeur programmable

IMPLANTATION LOGICIELLE

Spécification des tâches

Implantation des tâches

niveau tâches

Implantation Spécification des modules des modules

niveau modules

-Figure 18.5- Décomposition pour l'implantation. Comme habituellement, une seule tâche est exécutée à la fois par le processeur, un ordonnancement des tâches est nécessaire selon un critère. Pour cela à chaque tâche est associée une priorité d'exécution. Ainsi pour la représentation, l'axe vertical représente l'axe croissant des priorités. Le processeur étant toujours en activité, en l'absence de tâches temporaires à exécuter, celui-ci exécute une tâche particulière appelée tâche de FOND. La figure ci-après est un exemple de schéma d’implantation.
Priorité croissante

PAS T1

T3 V1

REÇU T2 T4 B2 V5

T0 TACHE DE FOND

Matériel

Logiciel

Matériel

-Figure 18.6- Exemple d'implantation de tâches. 370 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Les tâches liées à des événements en entrée (événements matériels situés à gauche et donc tâches activées par interruption) sont activées sur apparition de chaque événement. Une telle tâche évolue lorsqu'elle dispose du processeur, ce qui est le cas lorsqu’une tâche activée est plus prioritaire que la tâche courante exécutée par le processeur. Ceci résume la technique d’ordonnancement retenue, priorité fixe et processeur alloué à la tâche active la plus prioritaire. Dans le sens vertical, le transfert de contrôle entre 2 tâches et donc d'allocation du processeur, est représenté par un lien double trait. Ce type de transfert, qui sera du type appel de procédure (call, return), n'est possible que dans le sens croissant des priorités. La règle de comportement est la suivante:
Priorité Acquisition du contexte de A2
A2 appel de A2 fin d’exécution de A2

Sauvegarde du contexte de A2

A2

A1

suspension de A1

A1

-Figure 18.7- Comportement pour un transfert de contrôle. Lorsque A1 disposant du processeur décide durant son évolution de passer le contrôle à A2 (synchronisation de A2 sur un événement généré par A1 par exemple), le processeur est alors passé à A2. A2 conserve le processeur jusqu'à sa fin d'exécution. Le transfert inverse redonne le processeur à A1 qui poursuit alors son activité. A2 est donc obligatoirement temporaire, A1 peut être permanente ou temporaire. Ce mécanisme de transfert de contrôle est tout simplement celui de l'appel procédural, A2 est implantée comme une procédure, le transfert se fait par un CALL avec sauvegarde du point de réactivation de A1. Le retour se fait par RET en utilisant le point de retour sauvegardé. Ainsi ce mécanisme simple permet très naturellement d'induire des relations d'ordre d'exécution pour des tâches. Attention tout de même car pour le modèle d'implantation A2 est toujours une tâche et non pas simplement une procédure, car il possède ses variables internes propres qui ont une durée de vie supérieure à celle de chaque activation. L'exécution de A2 par un appel procédural implique donc que cette exécution par le processeur débute par une récupération du contexte ou vecteur d'état de A2 et se termine par une mémorisation de son vecteur d'état pour la prochaine activation. Ce modèle est aussi hiérarchique. Une tâche peut se raffiner par un réseau de tâches. 18.3.2. Implantation de chaque tâche Une tâche élémentaire est considérée non décomposable en tâches car le déroulement de ses opérations est purement séquentiel. La complexité d'une telle tâche élémentaire est très variable selon sa fonctionnalité. Pour quelques opérations, une décomposition supplémentaire n'est pas nécessaire car l'écriture du code est directe. Par contre pour une fonctionnalité qui M.C.S.E 371

Partie 5 - DEFINITION DE LA REALISATION nécessite un programme complexe, une décomposition est souhaitable pour favoriser une implantation modulaire et structurée. Le modèle de structure de modules, ou structure chart de Yourdon et Constantine est ici préconisé comme modèle pour la description de chaque tâche (voir 7.4). Rappelons que les éléments de base de ce modèle sont le module et la donnée partagée. Ce modèle est hiérarchique. Il permet de représenter la décomposition d'une tâche en unités plus élémentaires. Les relations avec les modules subordonnés sont représentées par les liens d'appel. A chaque lien d'appel sont associés des arguments d'entrée et de sortie qui peuvent être de 2 types: donnée ou contrôle. Les structures de contrôle sont: le séquencement, l’appel, l’itération, l’alternance. Les données internes à un module ont la durée de vie de l'appel du module. Des données externes sont accessibles aux modules. La durée de vie de ces données est celle de l'application. 18.3.3. Spécification de chaque élément En complément des structures de tâches et de modules, la spécification de l'implantation n'est complète que si tous les éléments sont spécifiés. On passe ci-après en revue chacune des catégories.
-A- LES TACHES

Chaque tâche doit être spécifiée: entrées, sorties, les conditions d'activation, le rôle pour l'application exprimé par la ou les fonctions de la description fonctionnelle que la tâche doit assurer, la description de son vecteur d'état. Les contraintes de temps sont aussi à préciser: performances, temps d'exécution maximum, délais de réaction.
-B- LES DONNEES PARTAGEES

Il s'agit, d'une part des variables d'état qui servent pour le couplage entre les tâches, et d'autre part des données externes nécessaires aux modules. La spécification de ces données se déduit de la description fonctionnelle: structure, domaine, précision, ... Certaines informations d'implémentation peuvent être ajoutées: définition de la représentation des données, ordonnancement des données et mécanisme d'accès.
-C- LES MODULES

Chaque module doit aussi être décrit par une spécification. Cette spécification doit permettre par la suite un codage correct sans qu'il s'agisse pour cela d'écrire les programmes. La plupart des spécifications des modules découlent de la description fonctionnelle ; des fonctions complètes ou des portions de celles-ci se trouvent en fait implantées comme modules. 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION Une implantation représente une traduction de la structure fonctionnelle retenue sur le processeur. Tous les éléments de la structure fonctionnelle doivent se retrouver dans l'implantation. L’objectif est aussi de réduire la complexité de la réalisation qui en découlera. Ainsi des règles sont à respecter pour obtenir cette traduction. Détaillons ces règles pour les catégories d'éléments et de relations. 372 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.4.1. Correspondance: Fonctions —> Tâches Pour l'implantation, une tâche est l'unité d’exécution. Elle correspond à une fonction élémentaire ou à un regroupement de plusieurs fonctions de la structure fonctionnelle. Tout d’abord le regroupement concerne habituellement plusieurs fonctions activées simultanément par le même événement. La figure suivante illustre ce type de regroupement, la décomposition étant exprimée par une structure de modules.
PARAM Contrôle Coordination PAS Contrôle T T T Mise à jour de T PAS Régulation Mise à jour de T T Tâche Contrôle

Vc

Vc T

Vc

Coordination

Régulation

Horloge

Structure fonctionnelle

Schéma d’implantation

PARAM

-Figure 18.8- Traduction avec regroupement de fonctions. La tâche est activée par l’événement matériel PAS. Le module principal CONTROLE assure l’exécution séquentielle des 3 modules qui résultent d’une transformation de chaque fonction en procédure. Ensuite les actions permanentes sont obligatoirement regroupées dans la tâche de fond. Le partage du processeur est alors assuré par commutation régulière pour l'allocation du processeur aux différentes fonctions de la tâche. La tâche de fond joue ainsi le rôle d'ordonnanceur comme l’indique la figure ci-dessous.
Structure fonctionnelle Schéma d’implantation

F1

Séquenceur
V F2 V F3 F1 F2 F3 V

Tâche de fond

-Figure 18.9- Implantation de plusieurs fonctions dans la tâche de fond. M.C.S.E 373

Partie 5 - DEFINITION DE LA REALISATION 18.4.2. Traduction des relations par partage de variables Ces relations sont conservées dans l'implantation. Comme les tâches ont des priorités différentes, le couplage interne par variable se représente par des liens verticaux. Le regroupement de fonctions dans une même tâche peut induire le regroupement de variables accessibles en entrée et en sortie. D'autre part, pour un regroupement d'actions dans une même tâche, des variables d'état d'actions deviennent des variables internes globales de la tâche. 18.4.3. Traduction des synchronisations par événement L'événement peut être d'origine matérielle (entrée pour le processeur) ou d'origine logicielle (interne au processeur). Suivant le cas, 3 principes sont applicables pour la traduction : Premier principe: un événement est transformable en une variable booléenne. Dans ce cas, la fonction temporaire qui en dépend n'est plus activée par l'événement. Elle doit alors obligatoirement observer l'évolution de la variable booléenne équivalente pour décider des instants d'évolution. Dans ce cas, la fonction est alors transformée en une action permanente et est intégrée dans la tâche de fond. Deuxième principe: une synchronisation interne (donc logicielle) se transforme suivant la priorité des 2 fonctions: - priorité inférieure du générateur: appel procédural, - priorité supérieure du générateur: positionnement d'une variable booléenne indiquant la génération de l'événement. Cette variable doit être observée régulièrement pour engendrer l'évolution du correspondant. Ce rôle est affecté à une tierce fonction, généralement la tâche de fond. Ces 2 cas de transformation sont illustrés par l'exemple ci-après.
EV F1 F2

Prior. F2 > Prior. F1
F1 F2

Prior. F1 > Prior. F2

F2 EV EV EV

F1

F3

-Figure 18.10- Illustration pour l’implantation d’une synchronisation. 374 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Troisième principe: une synchronisation par un événement externe s'implante efficacement en utilisant le mécanisme d'interruption du processeur. Dans ce cas, aucune transformation n'est à faire. Il suffit simplement d'associer la tâche à un niveau d'interruption correspondant à sa priorité relative par rapport aux autres tâches implantées sous interruption. 18.4.4. Traduction pour des transferts par messages Un message est l'association d'un événement et d'une donnée. Les principes énoncés pour les synchronisations sont donc applicables. A nouveau, 3 principes sont utilisables suivant les cas: Premier principe: un port interne au processeur (donc logiciel) est transformé en une variable partagée couramment appelée Boîte à lettres (symbole )et composée de 2 parties : - la zone servant au dépot des messages. Cette zone est obligatoirement de capacité finie (tampon ou buffer), - un indicateur précisant le nombre de messages disponibles dans la zone. Pour se servir de cette boîte à lettres, les fonctions producteur et consommateur doivent alors tester la valeur de l'indicateur avant d’entreprendre une opération de dépôt ou de retrait. Le consommateur est dans ce cas obligatoirement transformé en une action permanente. Si la boîte à lettres est pleine, le producteur doit attendre un retrait, si elle est vide le consommateur doit attendre un dépôt. Deuxième principe: un transfert de messages entre deux fonctions logicielles se transforme suivant les priorités relatives de celles-ci: - priorité inférieure du producteur: utilisation de l'appel procédural pour activer le consommateur, - priorité supérieure du producteur: utilisation d'une action tierce pour observer la disponibilité d'un message et la disponibilité du consommateur. Ces deux cas de transformation sont illustrés ci-dessous.
MESS F1 F2

Prior. F2 > Prior. F1
F1 F2

Prior. F1 > Prior. F2

F2 (ME) MESS (ME)

F1

F3

-Figure 18.11- Les 2 cas d’implantation pour un transfert par messages. M.C.S.E 375

Partie 5 - DEFINITION DE LA REALISATION Troisième principe: Le transfert de messages doit se faire avec l'environnement matériel. Il se fait de préférence élément par élément (par exemple caractère par caractère). La boîte à lettres de couplage a alors une capacité de 1. Ceci n'est pas une règle obligatoire (utilisation d'une FIFO par exemple), mais elle est simple sur le plan technologique. Le couplage entre le matériel et le logiciel se fait en transformant la boîte à lettres en une variable pour le dépôt et 2 événements pour la synchronisation bidirectionnelle. Un événement peut se transformer en variable booléenne en particulier dans le sens logiciel vers matériel. Les 2 événements peuvent aussi être transformés en une seule variable booléenne bidirectionnelle. La figure suivante montre une traduction pour les deux cas: en provenance du matériel pour M1, vers le matériel pour M2. Pt est transformé selon le deuxième principe.
Matériel Logiciel Matériel

M1 F1 F2

Pt F3

M2 F4

Emis

M2.Dépôt

M1.V F1 F2

(Pt) F3

M2.V F4

M1.retrait

reçu

Prior. F3 > Prior. F2

-Figure 18.12- Exemple de traduction. Cette traduction montre les solutions matérielles usuelles assurant un couplage correct entre producteur et consommateur: technique de l'échange par poignée de main (handshake). 18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL Un processeur programmable peut avoir des niveaux de complexité très variables. Déjà entre les processeurs 8 bits type 8085 ou microcontrôleurs et les processeurs évolués 32 bits tels que le transputer T800, des différences essentielles existent. Tout microprocesseur est séquentiel pour l'exécution des instructions. Il n'exécute ainsi qu'une seule tâche à la fois. Si nécessaire, le parallélisme ne s'obtient qu'à un niveau macroscopique, par commutation du processeur vis à vis de tâches à l’aide de mécanismes matériels tel que le système d'interruption ou grâce à l'ajout d'un logiciel chargé de gérer le partage du processeur. 376 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Un système informatique considéré globalement comme un processeur pour les fonctions logicielles à implanter, dispose de mécanismes permettant l'exécution simultanée ou pseudosimultanée de tâches. Ces mécanismes sont offerts par un noyau exécutif appelé moniteur multi-tâches temps-réel ou exécutif temps-réel. La disponibilité de ces mécanismes facilite le travail d'implantation. En effet, l'objectif étant de réduire la partie organisationnelle à développer, cette partie se traduit directement sous la forme d'appels à l'exécutif temps-réel. Ainsi, plusieurs techniques d'implantation sont disponibles pour les tâches suivant le niveau du processeur et donc suivant ses spécifications ou ses caractéristiques. La suite du paragraphe montre l'implantation d'un même exemple dans les 2 cas: sans moniteur temps-réel et avec moniteur temps-réel. Sont aussi indiqués les critères à considérer pour décider de la technique à utiliser. 18.5.1. Implantation sans moniteur temps-réel Dans ce cas toutes les relations entre les actions de la structure fonctionnelle à implanter sur le processeur doivent être transformées selon les règles décrites dans le paragraphe précédent. L'exemple suivant est donné à titre d'illustration d'une implantation complète avec prior T0 > prior T2 > prior T1. Ce même exemple sera utilisé pour présenter la solution avec un moniteur temps-réel.
Structure fonctionnelle
EV Ev T0 T2 Prêt B pour MESS Prêt T1 T2 T1 (Mess) T0

priorité

MESS

Tache de fond

-Figure 18.13- Schéma d'implantation sans exécutif temps-réel. La tâche T0 est activée par l'événement matériel EV. Ainsi, elle récupère inconditionnellement le processeur. T0 est donc plus prioritaire que toutes les autres tâches. La synchronisation entre T0 et T1 selon une priorité décroissante est faite par l'intermédiaire de la Boîte à lettres B et de la tâche de fond. Le comportement de la tâche de fond est le suivant:
cycle: if B.Nb_messages>0 then begin Retrait_message (B, Mess); T1(Mess); end; end cycle;

Ainsi la tâche de fond scrute régulièrement si un message est disponible dans B. Si oui, le premier message est retiré et transmis à T1 pour exécution. M.C.S.E 377

Partie 5 - DEFINITION DE LA REALISATION La période de scrutation par la tâche de fond dépend de l'occupation du processeur à traiter les tâches temporaires (ici uniquement T0). Cet exemple montre la simplicité de la méthode d'implantation et la simplicité de la partie organisationnelle qui en découle. 18.5.2. Implantation avec un exécutif temps-réel L'exécutif temps-réel dans ce cas est à voir comme une tâche ayant la priorité la plus élevée et sollicitée par toutes les autres tâches par appel procédural. La plus grande priorité est justifiée pour que cet exécutif puisse requérir le processeur lorsqu'il le désire de manière à assurer correctement son rôle d'ordonnancement. La figure suivante montre le schéma d'implantation d'une structure fonctionnelle avec utilisation de 4 primitives temps-réel: SIGNAL et WAIT pour la synchronisation, SEND et RECEIVE pour le transfert de messages.
priorité
Exécutif temps-réel
Ev T0 EV Tit
Wait(EV) Signal(EV) Send (V,MESS) Wait(Prêt)

T0 MESS
Receive(V,MESS)

T2
Signal(Prêt)

T1 Prêt T1 T2

Tache de fond

matériel

logiciel

-Figure 18.14- Schéma d'implantation avec un exécutif temps-réel. L'implantation ci-dessus montre bien le rôle d’ordonnanceur joué par l'exécutif temps-réel. Les événements externes pris en compte comme interruptions par le processeur sont gérés par une tâche très courte (Tit) qui se contente de signaler au moniteur temps-réel les événements reçus. Toutes les demandes faites par les tâches à l'exécutif se font par appel procédural. Si la demande implique une attente, l'instant de retour à la tâche appelante est décidé par l'exécutif. L'ordre de retour et donc d'allocation du processeur à la tâche appelante est totalement sous le contrôle de l'exécutif. C'est une raison supplémentaire pour que cette tâche soit représentée comme la plus prioritaire. Pour la compréhension du schéma d'implantation, on donne figure 18.15 une séquence de déroulement pour les 3 actions T0, T1, T2. L'exécutif est donc ici vu comme une tâche particulière unique sollicitée par toutes les tâches du processeur pour chaque action particulière. L'exécutif possède donc de multiples points d'entrée. Il gère l'ordonnancement des retours aux tâches appelantes sur la base de variables internes qui représentent l'état de toutes les tâches, des relations, des demandes ... 378 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION

Priorité Attributions du processeur
Exécutif

Ev
Signal (EV) wait Send (V,MESS) wait (EV) Signal (prêt) (prêt) Receceive (V,MESS)

TIT

wait (EV)

wait (prêt)

Receive (V,MESS)

T0 T2 T1 Tâche de fond

T0 T2 T1

Ev

Initialisation

Déroulement
T0

T2

T1

-Figure 18.15- Exemple de déroulement d'exécution. Si pour un cas simple, l'exécutif peut se comprendre comme une simple tâche, habituellement, compte-tenu des mécanismes offerts: délai, activation périodique, synchronisation sur événements externes ..., un exécutif est lui-même composé d'un ensemble de tâches. Le couplage entre ces tâches peut tout à fait se décrire par le modèle d'implantation décrit dans ce chapitre. La méthode présentée s'avère donc utilisable par les concepteurs d'exécutifs. Pour les applications utilisant un exécutif temps-réel, le schéma d'implantation décrit par la figure précédente n'est pas nécessaire. Il a seulement été donné pour expliquer le rôle joué par un exécutif. Dans ces cas d'applications, il suffit simplement: - de déterminer la priorité de chaque tâche, - de traduire chaque relation fonctionnelle par le ou les mécanismes de l'exécutif disponibles et appropriés. La figure 18.16 montre la représentation suffisante pour une telle implantation. Certains processeurs possèdent en standard dans leur jeu d'instructions des mécanismes de synchronisation et d'échange de données. C'est le cas par exemple du TRANSPUTER d'INMOS. La disponibilité de tels mécanismes implique que le processeur assure de lui-même l'ordonnancement des tâches. Le travail du concepteur se trouve alors simplifié (voir 22.8). Pour le concepteur d'applications, la seule différence qui existe entre ce type de processeur prévu pour la gestion du parallélisme et un processeur plus classique auquel on associe un exécutif temps-réel, est que dans le deuxième cas, il faut ajouter l'exécutif comme logiciel. Les performances sont alors moindres par suite du temps nécessaire pour l’exécution des fonctions du moniteur. M.C.S.E 379

Partie 5 - DEFINITION DE LA REALISATION

Priorité
ITEV

wait(EV)
T0

signal(EV)

send(V,MESS)
T2 wait(prêt)

MESS

Prêt

receive(V,MESS)
T1

signal(prêt)

-Figure 18.16- Schéma d'implantation basé sur un exécutif Temps-Réel 18.5.3. Critères de choix de la technique d'implantation Il est évident que pour réduire le temps de développement d'une application, il est préférable de disposer d'un exécutif. La solution logicielle est plus coûteuse en place mémoire, en temps de traitement des sollicitations (temps de commutation ou overhead), et en terme de prix lorsque l'exécutif est un produit standard du commerce (VRTX, PSOS, iRMX, noyau SCEPTRE...). L'exécutif intégré dans la fonctionnalité du processeur est la solution la plus avantageuse et correspond à une tendance qui va probablement se généraliser. Elle permet au concepteur de voir le processeur comme un exécutif direct multi-tâches, ce qui réduit le travail d'implantation. Le concepteur n'a pas dans ce cas besoin de descendre au niveau de l'ordonnancement de ses tâches. Toutefois, il lui faut toujours déterminer la priorité relative des tâches. Dans l'état actuel de la technologie, beaucoup de microprocesseurs ne disposent pas de cette fonctionnalité. Le choix doit alors se faire entre: l'emploi d'un exécutif ou la définition complète de l'implantation. C'est au concepteur de décider la meilleure solution sur la base de critères techniques et économiques. Les critères à considérer sont: - les contraintes de temps pour l'application. Pour de très fortes contraintes, il faut définir une implantation complète sans exécutif, car c'est la solution qui réduit au maximum les temps de commutation des taches (overhead). - le nombre d'exemplaires. Pour quelques exemplaires, l'emploi d'un exécutif réduit le temps de développement. Pour un grand nombre, comme il faut réduire le coût de chaque exemplaire, ceci implique fort probablement de se passer d'un exécutif standard. - la complexité de l'application. Pour de petites applications dédiées bien spécifiées, l'implantation directe restera simple et efficace. Pour des applications complexes avec des spécifications évolutives, un exécutif temps-réel est certainement favorable. 380 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.6. CARACTERISTIQUES DU MODELE D’INTEGRATION Le modèle de description d'un système est basé sur l'association de 3 dimensions ou 3 vues: topologique, comportementale, exécutive. La dimension exécutive représente le support "matériel" qui engendre l'évolution de l'application. Une application opérationnelle résulte d'une association correcte de la dimension fonctionnelle avec la dimension exécutive. C'est l'objectif du modèle d'intégration que de spécifier les règles de correspondance entre ces 2 ensembles, puis pour les réalisations logicielles, la structuration pour l'implantation. Les caractéristiques essentielles induites par le modèle d’intégration sont présentées ciaprès.
-A- MODELE DE STRUCTURE

Ce modèle est composé de 2 parties complémentaires. Tout d'abord le modèle d'ALLOCATION définit la correspondance : fonctionnel --> exécutif, ensuite le modèle d'IMPLANTATION définit l'organisation d'une structure fonctionnelle sur chaque processeur. Ce dernier modèle est hiérarchique avec 2 niveaux d'organisation: le niveau TACHES et le niveau MODULES. La spécification de la réalisation en sous-ensembles hiérarchiques avec des interfaces complètement spécifiées, est favorable pour une répartition du travail de réalisation sur plusieurs équipes.
-B- ALLOCATION COMME RESULTAT D’UNE ABSTRACTION

Le modèle d'ALLOCATION décrit des regroupements d'éléments d'une structure fonctionnelle. A chaque regroupement est associé un processeur pour l'exécution. Une telle transformation s'obtient par la technique d'abstraction, en se basant sur des critères de regroupement que sont: connexité, contraintes de temps, taux d'occupation du processeur. L'allocation s'avère correcte si chaque processeur est opérationnel et si la structure fonctionnelle complète est ACCEPTEE par la structure d'exécution.
-C- IMPLANTATION COMME MODELE D’ORGANISATION DU LOGICIEL

Le modèle d'implantation est utilisé pour chaque processeur programmable, définissant ainsi sa fonctionnalité par du logiciel en décrivant l'organisation des éléments et des mécanismes utilisés pour les relations entre ces éléments. Chaque processeur est le support d'exécution d'une structure fonctionnelle comme sousensemble de la structure complète. L'implantation résulte d'une transformation de la structure fonctionnelle selon un ensemble de règles. L'objectif d'une bonne implantation est de réduire au maximum la partie organisationnelle du logiciel. Les 2 niveaux d'organisation - TACHES et MODULES - permettent de représenter simultanément le pseudo-parallélisme d'exécution et l'exécution séquentielle.
-D- DEPENDANCE ENTRE IMPLANTATION ET CARACTERISTIQUES DU PROCESSEUR

Le modèle d'implantation tient compte des caractéristiques fonctionnelles du processeur. Celui-ci peut être vu pour l'utilisateur comme un processeur mono-tâche, ou pour certains processeurs comme étant multi-tâches. La démarche à adopter pour chacun des 2 cas revient à poursuivre l'implantation selon une démarche descendante jusqu'à rejoindre les possibilités des processeurs. M.C.S.E 381

Partie 5 - DEFINITION DE LA REALISATION Le modèle est donc adaptatif vis à vis des évolutions futures de la technologie. On peut imaginer à plus long terme que les processeurs accepteront directement une description fonctionnelle. Le travail de recherche d'implantation deviendra alors très simple. 18.7. RESUME Ce chapitre, complémentaire au précédent, a permis de présenter le modèle d'intégration utilisé pour la définition de la réalisation comme un outil décrivant l’association de la description fonctionnelle et d'une structure exécution. Cette dernière engendre l'évolution spécifiée par la solution fonctionnelle. Les points essentiels sont les suivants: - le modèle d'intégration inclut, l'allocation de la structure fonctionnelle sur la structure d'exécution, la description de l'implantation des actions logicielles sur les processeurs programmables, - une allocation n'est correcte que si la structure fonctionnelle se trouve acceptée par la structure d'exécution et que si tous les processeurs sont opérationnels avec respect de toutes les contraintes de temps, - le modèle d'implantation est structuré en 2 niveaux: le niveau TACHES pour l'implantation des actions et des relations de la structure fonctionnelle, le niveau MODULES pour décrire la décomposition de chaque tâche, - des règles de transformation simples permettent de décider d'une implantation à partir du modèle fonctionnel. - l'implantation à retenir est fonction du niveau de fonctionnalité du processeur. Les 2 approches avec ou sans exécutif temps-réel sont possibles.

382

M.C.S.E

Chapitre 18

LE MODELE D’INTEGRATION

Une description fonctionnelle exprime une solution indépendante de la technologie pour l'application considérée. Une structure d'exécution décrit le support matériel. Pour compléter la définition d'une réalisation, il faut y ajouter la correspondance fonctionnel —> matériel et la description de la partie logicielle. L'organisation du logiciel découle: d'une part de la description fonctionnelle qui exprime l'objectif à satisfaire, d'autre part de la structure d'exécution retenue comme support opérationnel. Le modèle d'intégration a pour objectif de spécifier complètement l'implantation d'une description fonctionnelle sur une structure d'exécution. Si dans la démarche de conception le but est de déduire une structure d'exécution et une implantation à partir d’une description fonctionnelle, pour la présentation du modèle d’intégration, on se place ici dans le cas où la description fonctionnelle et la structure d'exécution sont données. Comme le montre ce chapitre, l'intégration concerne 2 niveaux: le niveau structure d'exécution et le niveau processeur. Pour le niveau global, la structure fonctionnelle complète doit s’implanter sur la structure d’éxécution. Pour chaque processeur programmable, la fonctionnalité résulte d’une implantation sous la forme d’un schéma d’organisation du logiciel.

M.C.S.E

363

Partie 5 - DEFINITION DE LA REALISATION 18.1. LE MODELE D’INTEGRATION ET SES CONSTITUANTS Le modèle d’intégration spécifie deux niveaux d’implantation. Tout d'abord, étant donné un support d'exécution, chacun de ses constituants est le support opérationnel pour un ou plusieurs constituants de la structure fonctionnelle: - un processeur pour une structure fonctionnelle partielle, - une mémoire pour des variables d'état, - un noeud de communication pour les ports. Cette correspondance S.F.-->S.E. représente l'ALLOCATION. Ensuite, pour chaque association du type: processeur général<-->structure fonctionnelle partielle, la fonctionnalité est obtenue par logiciel. Aussi dans ce cas, les règles d'implantation de la structure fonctionnelle sur le processeur sont à exprimer. Ainsi le modèle d'intégration est constitué de 2 parties: - le modèle d'allocation qui décrit la correspondance entre une structure fonctionnelle et une structure d'exécution, - le modèle d'implantation qui décrit les règles d'implantation de chaque sousensemble de la description fonctionnelle réalisé par logiciel sur le processeur programmable alloué comme support. La composition du modèle d'intégration est représentée ci-après.
FONCTIONNEL INTEGRATION EXECUTIF

Structure fonctionnelle

Allocation

Structure d’éxécution

Sous-ensembles fonctionnels

implantation

constituants

Structure fonctionnelle partielle pour les processeurs programmables Implantation Processeur

Implantation logicielle

-Figure 18.1- Les constituants du modèle d'intégration. Pour une application donnée, il n'existe qu'une seule définition de l'allocation: elle exprime l’ensemble des relations entre les constituants de la structure fonctionnelle et ceux de la structure d’éxécution. Mais il existe autant de définitions d'implantation que de processeurs généraux. 364 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.2. LE MODELE D’ALLOCATION La similitude des modèles - structure fonctionnelle, structure d'exécution - favorise la correspondance entre les 2 structures. Chaque structure est composée d'éléments et de relations entre ces éléments. Ainsi, le modèle d'allocation détaille les correspondances entre éléments des 2 structures et les contraintes de correspondance à respecter. 18.2.1. Correspondance entre les éléments des 2 structures La correspondance entre éléments est la suivante : structure fonctionnelle partielle (SF) variables (VE) événements (EV) ports (PT) liens: fonction <-->EV,VE,PT --> --> --> --> --> processeur (P) mémoire (M) signalisation (S) noeud de communication (N) lien: processeur <-->S,M,N

Les règles ci-après sont à respecter pour toute correspondance: - Une fonction élémentaire est une unité de description et de répartition. De ce fait elle est indivisible pour l'implantation. Son activité résultera de l’utilisation d’un seul processeur. Si cette hypothèse n’est pas possible, la décomposition fontionnelle doit être poursuivie. Cette situation peut apparaitre pour des applications de grandes performances ou à fortes contraintes de temps. - Les variables d'état et les messages sont aussi des objets indivisibles. - Processeur, mémoire, noeud de communication peuvent chacun supporter plusieurs éléments, respectivement : fonctions, variable d'états, ports. - Un processeur général est le support d'une structure fonctionnelle partielle ou complète. Les 2 premières règles ci-dessus indiquent que la décomposition fonctionnelle a été poussée suffisamment loin pour permettre l'intégration. Les 2 dernières règles indiquent la possibilité de réduire la complexité d'une structure d'exécution. En effet, un processeur programmable est généralement trop puissant comme support pour uniquement une fonction élémentaire. Il en est de même pour la capacité d'une mémoire ou d'un noeud de communication. La réduction du coût du support matériel passe par la réduction du nombre de processeurs, de mémoires, de noeuds de communication, ce qui réduit simultanément le nombre de liaisons physiques à réaliser. La réduction essentielle s'obtient en implantant sur chaque processeur une structure fonctionnelle la plus importante possible. L'exemple suivant montre 2 formes: la première graphique, la deuxième textuelle pour décrire les correspondances entre éléments. M.C.S.E 365

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle Structure d’exécution E1 V1 A1 A2 P1 S1

V2

V4

E3

M1 P3

A3

A4 N1 P2 V3

PT1 A5

-Figure 18.2- Description d'une correspondance entre éléments. Pour les éléments: S1 P1 M1 P2 P3 N1 et pour les liens: P1->M1 P2->N1 N1->P3 (M1->P2) (M1->P3) (P3->S1) (S1->P1) <=== <=== <=== <=== <=== <=== <=== (A1->V2, A1->V4) (A3->PT1) (PT1->A5) V2->A3 V4->A4 A4->E3 E3->A2 <=== <=== <=== <=== <=== <=== (E3) (SF[A1, A2, E1, V1]) (V2, V4) (A3) (A4, A5) (PT1)

Cet exemple montre que tous les éléments d'une structure fonctionnelle doivent obligatoirement avoir un correspondant sur la structure d'exécution. Par contre, étant donné une structure d'exécution, tous les éléments ne servent pas obligatoirement pour l'application. 366 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.2.2. Contraintes pour une allocation Une allocation n’est correcte pour l’application que si pour les correspondances retenues, des règles sont garanties. 2 types de règles sont à respecter: - tout d'abord comme un processeur peut servir de support exécutif pour plusieurs fonctions, celui-ci doit être apte à engendrer les évolutions souhaitées en respectant toutes les contraintes de temps. Le respect de cette règle exprime le fait que chaque processeur est OPERATIONNEL pour l'allocation retenue. - ensuite la correspondance entre les éléments des 2 structures n'est correcte que si toutes les relations de la structure fonctionnelle sont réalisables par la structure d'exécution. Dans ce cas, on dira que la structure fonctionnelle est ACCEPTEE par la structure d'exécution. Détaillons dans la suite du paragraphe, les règles de vérification pour chaque catégorie.
-A- PROCESSEUR OPERATIONNEL

Un processeur sert de support exécutif pour une ou plusieurs actions. S'agissant d'applications temps-réel, des contraintes de temps sont associées à chaque action: fréquence d'activation, durée d'exécution maximale ou date de fin pour les actions temporaires, performances pour les actions permanentes. Un processeur est dit OPERATIONNEL pour une allocation donnée si toutes les actions sont effectuées et si toutes les contraintes de temps sont satisfaites pour la réalisation qui découle de cette allocation. Le caractère opérationnel dépend de plusieurs facteurs: - la complexité de la structure fonctionnelle à supporter : nombre et nature des actions et des opérations, - les contraintes de temps à respecter, - la performance du processeur. Une allocation se modifie en changeant les correspondances, et/ou en changeant les spécifications du processeur. Les règles pour la vérification seront détaillées dans le chapitre suivant en 19.5. On retiendra pour l'instant les 2 règles suivantes : - le taux d'occupation maximum du processeur pour toutes les actions temporaires (i=1,n) doit rester inférieur à 1: Tocc = Σi FAi*TEi < 1. Pour une action, le taux d'occupation maximum (Tocci) est le produit de sa fréquence d'activation maximale (FAi) par son temps d'exécution maximum (TEi). Le taux dépend donc de la performance du processeur par le terme TEi. - les durées d'exécution maximales, dates de fin (deadline), les temps de réaction sur événement externe sont toujours satisfaits. La figure 18.3 illustre le déroulement sur un même processeur de deux actions concurrentes pour une exécution de A1 plus prioritaire que A.
-B- STRUCTURE FONCTIONNELLE ACCEPTEE

Pour l'implantation, les relations fonctionnelles internes à un processeur sont réalisées par celui-ci. Par contre, les relations entre 2 processeurs nécessitent des liens matériels entre ces processeurs. M.C.S.E 367

Partie 5 - DEFINITION DE LA REALISATION

Objectif à satisfaire
ev1 A1 TE1 ev2 A2 TE2

TA1

TA2 Tdeadline A2

Implantation de A1 et A2 sur un même processeur
priorité

ev1

A1 ev2 A2

TFin < Tdeadline A2

Temps disponible => Tocc < 1

-Figure 18.3- Illustration des 2 règles pour une allocation. Pour vérifier qu'une structure fonctionnelle est acceptée par une structure d'exécution, il faut utiliser les correspondances entre éléments pour construire une structure fonctionnelle réduite. La réduction est obtenue par une opération d'abstraction qui consiste à regrouper tous les constituants (fonctions, variables, ports) implantés sur un même processeur. La structure ainsi obtenue doit être inclue au sens des graphes dans la structure d'exécution. Ceci veut dire qu'il faut au moins un lien au niveau exécutif comme support pour chaque lien fonctionnel. La figure 18.4 montre cette démarche de vérification. 18.3. LE MODELE D’IMPLANTATION POUR CHAQUE PROCESSEUR Pour les processeurs programmables, l'allocation définit le sous-ensemble fonctionnel implanté sur chaque processeur. Le modèle d'implantation définit les règles de présentation des constituants de ce sous-ensemble fonctionnel pour exprimer l'organisation de tous les constituants du logiciel. Le logiciel implanté sur un processeur est décomposable en 2 niveaux: - le niveau TACHES: une tâche est une entité composée d'instructions et de données, ayant sa propre autonomie. Pour le processeur, la tâche est manipulée comme un tout: activation, arrêt, suspension. Une tâche assure généralement une fonction ou une action de l'application. Son comportement est séquentiel. L'état d'une tâche défini par une variable appelée vecteur d'état, est mémorisé entre 2 activations successives. Une tâche a donc un effet mémoire. 368 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION

E1 V1 A1
1 2

S1 A2
1 A*1 2

P1 E3 M1 P3

V*1 V2 V4 E3

A3

A4

A*2

A*3 N1 P2

V3 PT1 A5

W*1

Structure fonctionnelle

Structure fonctionnelle réduite SF*

Structure d’exécution

-Figure 18.4- Correspondances: S.F. globale, S.F. réduite et S.E. - le niveau MODULES ou PROCEDURES. Un module est un ensemble d’instructions activé comme une unité par une tâche, pour satisfaire une fonction ou une opération. La tâche étant séquentielle, un seul module est actif à la fois. Un module est sans effet mémoire, ce qui veut dire que ses variables internes ont la durée d'exécution du module. Le niveau TACHES concerne un ensemble de tâches. L'évolution est donc potentiellement parallèle. Or, habituellement un processeur est séquentiel. Aussi une stratégie d'ordonnancement pour le partage du processeur par les tâches est donc nécessaire pour que, vue par l'application, l'évolution de l'ensemble des tâches apparaisse parallèle. Pour le niveau MODULES, chaque tâche se décompose comme une hiérarchie de modules. Le modèle d'implantation a pour objectif de proposer pour chaque processeur programmable un moyen de description pour les 2 niveaux: TACHES et MODULES. La composition du modèle est représentée par la figure 18.5. 18.3.1. Implantation des tâches Le niveau tâche explique l'implantation retenue pour une structure fonctionnelle donnée sur un processeur. Le parallélisme inhérent à la structure fonctionnelle (normalement égal au nombre de fonctions) est habituellement supérieur à celui-ci du processeur qui très souvent est de 1. Ensuite les relations entre les fonctions -par événement, par variable d'état, par port- ne sont pas des mécanismes directement supportés par le processeur. Enfin, le processeur couplé à son environnement doit satisfaire par des liens matériels les relations fonctionnelles existant entre la structure fonctionnelle qu'il supporte et l’environnement de celle-ci. L'implantation est représentée graphiquement par un réseau de tâches. Les tâches sont liées entre elles par des variables d'état, des transferts de contrôle, et sont liées avec l'environnement par des variables et des événements en entrée et sortie. M.C.S.E 369

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle partielle Implantation

Processeur programmable

IMPLANTATION LOGICIELLE

Spécification des tâches

Implantation des tâches

niveau tâches

Implantation Spécification des modules des modules

niveau modules

-Figure 18.5- Décomposition pour l'implantation. Comme habituellement, une seule tâche est exécutée à la fois par le processeur, un ordonnancement des tâches est nécessaire selon un critère. Pour cela à chaque tâche est associée une priorité d'exécution. Ainsi pour la représentation, l'axe vertical représente l'axe croissant des priorités. Le processeur étant toujours en activité, en l'absence de tâches temporaires à exécuter, celui-ci exécute une tâche particulière appelée tâche de FOND. La figure ci-après est un exemple de schéma d’implantation.
Priorité croissante

PAS T1

T3 V1

REÇU T2 T4 B2 V5

T0 TACHE DE FOND

Matériel

Logiciel

Matériel

-Figure 18.6- Exemple d'implantation de tâches. 370 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Les tâches liées à des événements en entrée (événements matériels situés à gauche et donc tâches activées par interruption) sont activées sur apparition de chaque événement. Une telle tâche évolue lorsqu'elle dispose du processeur, ce qui est le cas lorsqu’une tâche activée est plus prioritaire que la tâche courante exécutée par le processeur. Ceci résume la technique d’ordonnancement retenue, priorité fixe et processeur alloué à la tâche active la plus prioritaire. Dans le sens vertical, le transfert de contrôle entre 2 tâches et donc d'allocation du processeur, est représenté par un lien double trait. Ce type de transfert, qui sera du type appel de procédure (call, return), n'est possible que dans le sens croissant des priorités. La règle de comportement est la suivante:
Priorité Acquisition du contexte de A2
A2 appel de A2 fin d’exécution de A2

Sauvegarde du contexte de A2

A2

A1

suspension de A1

A1

-Figure 18.7- Comportement pour un transfert de contrôle. Lorsque A1 disposant du processeur décide durant son évolution de passer le contrôle à A2 (synchronisation de A2 sur un événement généré par A1 par exemple), le processeur est alors passé à A2. A2 conserve le processeur jusqu'à sa fin d'exécution. Le transfert inverse redonne le processeur à A1 qui poursuit alors son activité. A2 est donc obligatoirement temporaire, A1 peut être permanente ou temporaire. Ce mécanisme de transfert de contrôle est tout simplement celui de l'appel procédural, A2 est implantée comme une procédure, le transfert se fait par un CALL avec sauvegarde du point de réactivation de A1. Le retour se fait par RET en utilisant le point de retour sauvegardé. Ainsi ce mécanisme simple permet très naturellement d'induire des relations d'ordre d'exécution pour des tâches. Attention tout de même car pour le modèle d'implantation A2 est toujours une tâche et non pas simplement une procédure, car il possède ses variables internes propres qui ont une durée de vie supérieure à celle de chaque activation. L'exécution de A2 par un appel procédural implique donc que cette exécution par le processeur débute par une récupération du contexte ou vecteur d'état de A2 et se termine par une mémorisation de son vecteur d'état pour la prochaine activation. Ce modèle est aussi hiérarchique. Une tâche peut se raffiner par un réseau de tâches. 18.3.2. Implantation de chaque tâche Une tâche élémentaire est considérée non décomposable en tâches car le déroulement de ses opérations est purement séquentiel. La complexité d'une telle tâche élémentaire est très variable selon sa fonctionnalité. Pour quelques opérations, une décomposition supplémentaire n'est pas nécessaire car l'écriture du code est directe. Par contre pour une fonctionnalité qui M.C.S.E 371

Partie 5 - DEFINITION DE LA REALISATION nécessite un programme complexe, une décomposition est souhaitable pour favoriser une implantation modulaire et structurée. Le modèle de structure de modules, ou structure chart de Yourdon et Constantine est ici préconisé comme modèle pour la description de chaque tâche (voir 7.4). Rappelons que les éléments de base de ce modèle sont le module et la donnée partagée. Ce modèle est hiérarchique. Il permet de représenter la décomposition d'une tâche en unités plus élémentaires. Les relations avec les modules subordonnés sont représentées par les liens d'appel. A chaque lien d'appel sont associés des arguments d'entrée et de sortie qui peuvent être de 2 types: donnée ou contrôle. Les structures de contrôle sont: le séquencement, l’appel, l’itération, l’alternance. Les données internes à un module ont la durée de vie de l'appel du module. Des données externes sont accessibles aux modules. La durée de vie de ces données est celle de l'application. 18.3.3. Spécification de chaque élément En complément des structures de tâches et de modules, la spécification de l'implantation n'est complète que si tous les éléments sont spécifiés. On passe ci-après en revue chacune des catégories.
-A- LES TACHES

Chaque tâche doit être spécifiée: entrées, sorties, les conditions d'activation, le rôle pour l'application exprimé par la ou les fonctions de la description fonctionnelle que la tâche doit assurer, la description de son vecteur d'état. Les contraintes de temps sont aussi à préciser: performances, temps d'exécution maximum, délais de réaction.
-B- LES DONNEES PARTAGEES

Il s'agit, d'une part des variables d'état qui servent pour le couplage entre les tâches, et d'autre part des données externes nécessaires aux modules. La spécification de ces données se déduit de la description fonctionnelle: structure, domaine, précision, ... Certaines informations d'implémentation peuvent être ajoutées: définition de la représentation des données, ordonnancement des données et mécanisme d'accès.
-C- LES MODULES

Chaque module doit aussi être décrit par une spécification. Cette spécification doit permettre par la suite un codage correct sans qu'il s'agisse pour cela d'écrire les programmes. La plupart des spécifications des modules découlent de la description fonctionnelle ; des fonctions complètes ou des portions de celles-ci se trouvent en fait implantées comme modules. 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION Une implantation représente une traduction de la structure fonctionnelle retenue sur le processeur. Tous les éléments de la structure fonctionnelle doivent se retrouver dans l'implantation. L’objectif est aussi de réduire la complexité de la réalisation qui en découlera. Ainsi des règles sont à respecter pour obtenir cette traduction. Détaillons ces règles pour les catégories d'éléments et de relations. 372 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.4.1. Correspondance: Fonctions —> Tâches Pour l'implantation, une tâche est l'unité d’exécution. Elle correspond à une fonction élémentaire ou à un regroupement de plusieurs fonctions de la structure fonctionnelle. Tout d’abord le regroupement concerne habituellement plusieurs fonctions activées simultanément par le même événement. La figure suivante illustre ce type de regroupement, la décomposition étant exprimée par une structure de modules.
PARAM Contrôle Coordination PAS Contrôle T T T Mise à jour de T PAS Régulation Mise à jour de T T Tâche Contrôle

Vc

Vc T

Vc

Coordination

Régulation

Horloge

Structure fonctionnelle

Schéma d’implantation

PARAM

-Figure 18.8- Traduction avec regroupement de fonctions. La tâche est activée par l’événement matériel PAS. Le module principal CONTROLE assure l’exécution séquentielle des 3 modules qui résultent d’une transformation de chaque fonction en procédure. Ensuite les actions permanentes sont obligatoirement regroupées dans la tâche de fond. Le partage du processeur est alors assuré par commutation régulière pour l'allocation du processeur aux différentes fonctions de la tâche. La tâche de fond joue ainsi le rôle d'ordonnanceur comme l’indique la figure ci-dessous.
Structure fonctionnelle Schéma d’implantation

F1

Séquenceur
V F2 V F3 F1 F2 F3 V

Tâche de fond

-Figure 18.9- Implantation de plusieurs fonctions dans la tâche de fond. M.C.S.E 373

Partie 5 - DEFINITION DE LA REALISATION 18.4.2. Traduction des relations par partage de variables Ces relations sont conservées dans l'implantation. Comme les tâches ont des priorités différentes, le couplage interne par variable se représente par des liens verticaux. Le regroupement de fonctions dans une même tâche peut induire le regroupement de variables accessibles en entrée et en sortie. D'autre part, pour un regroupement d'actions dans une même tâche, des variables d'état d'actions deviennent des variables internes globales de la tâche. 18.4.3. Traduction des synchronisations par événement L'événement peut être d'origine matérielle (entrée pour le processeur) ou d'origine logicielle (interne au processeur). Suivant le cas, 3 principes sont applicables pour la traduction : Premier principe: un événement est transformable en une variable booléenne. Dans ce cas, la fonction temporaire qui en dépend n'est plus activée par l'événement. Elle doit alors obligatoirement observer l'évolution de la variable booléenne équivalente pour décider des instants d'évolution. Dans ce cas, la fonction est alors transformée en une action permanente et est intégrée dans la tâche de fond. Deuxième principe: une synchronisation interne (donc logicielle) se transforme suivant la priorité des 2 fonctions: - priorité inférieure du générateur: appel procédural, - priorité supérieure du générateur: positionnement d'une variable booléenne indiquant la génération de l'événement. Cette variable doit être observée régulièrement pour engendrer l'évolution du correspondant. Ce rôle est affecté à une tierce fonction, généralement la tâche de fond. Ces 2 cas de transformation sont illustrés par l'exemple ci-après.
EV F1 F2

Prior. F2 > Prior. F1
F1 F2

Prior. F1 > Prior. F2

F2 EV EV EV

F1

F3

-Figure 18.10- Illustration pour l’implantation d’une synchronisation. 374 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Troisième principe: une synchronisation par un événement externe s'implante efficacement en utilisant le mécanisme d'interruption du processeur. Dans ce cas, aucune transformation n'est à faire. Il suffit simplement d'associer la tâche à un niveau d'interruption correspondant à sa priorité relative par rapport aux autres tâches implantées sous interruption. 18.4.4. Traduction pour des transferts par messages Un message est l'association d'un événement et d'une donnée. Les principes énoncés pour les synchronisations sont donc applicables. A nouveau, 3 principes sont utilisables suivant les cas: Premier principe: un port interne au processeur (donc logiciel) est transformé en une variable partagée couramment appelée Boîte à lettres (symbole )et composée de 2 parties : - la zone servant au dépot des messages. Cette zone est obligatoirement de capacité finie (tampon ou buffer), - un indicateur précisant le nombre de messages disponibles dans la zone. Pour se servir de cette boîte à lettres, les fonctions producteur et consommateur doivent alors tester la valeur de l'indicateur avant d’entreprendre une opération de dépôt ou de retrait. Le consommateur est dans ce cas obligatoirement transformé en une action permanente. Si la boîte à lettres est pleine, le producteur doit attendre un retrait, si elle est vide le consommateur doit attendre un dépôt. Deuxième principe: un transfert de messages entre deux fonctions logicielles se transforme suivant les priorités relatives de celles-ci: - priorité inférieure du producteur: utilisation de l'appel procédural pour activer le consommateur, - priorité supérieure du producteur: utilisation d'une action tierce pour observer la disponibilité d'un message et la disponibilité du consommateur. Ces deux cas de transformation sont illustrés ci-dessous.
MESS F1 F2

Prior. F2 > Prior. F1
F1 F2

Prior. F1 > Prior. F2

F2 (ME) MESS (ME)

F1

F3

-Figure 18.11- Les 2 cas d’implantation pour un transfert par messages. M.C.S.E 375

Partie 5 - DEFINITION DE LA REALISATION Troisième principe: Le transfert de messages doit se faire avec l'environnement matériel. Il se fait de préférence élément par élément (par exemple caractère par caractère). La boîte à lettres de couplage a alors une capacité de 1. Ceci n'est pas une règle obligatoire (utilisation d'une FIFO par exemple), mais elle est simple sur le plan technologique. Le couplage entre le matériel et le logiciel se fait en transformant la boîte à lettres en une variable pour le dépôt et 2 événements pour la synchronisation bidirectionnelle. Un événement peut se transformer en variable booléenne en particulier dans le sens logiciel vers matériel. Les 2 événements peuvent aussi être transformés en une seule variable booléenne bidirectionnelle. La figure suivante montre une traduction pour les deux cas: en provenance du matériel pour M1, vers le matériel pour M2. Pt est transformé selon le deuxième principe.
Matériel Logiciel Matériel

M1 F1 F2

Pt F3

M2 F4

Emis

M2.Dépôt

M1.V F1 F2

(Pt) F3

M2.V F4

M1.retrait

reçu

Prior. F3 > Prior. F2

-Figure 18.12- Exemple de traduction. Cette traduction montre les solutions matérielles usuelles assurant un couplage correct entre producteur et consommateur: technique de l'échange par poignée de main (handshake). 18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL Un processeur programmable peut avoir des niveaux de complexité très variables. Déjà entre les processeurs 8 bits type 8085 ou microcontrôleurs et les processeurs évolués 32 bits tels que le transputer T800, des différences essentielles existent. Tout microprocesseur est séquentiel pour l'exécution des instructions. Il n'exécute ainsi qu'une seule tâche à la fois. Si nécessaire, le parallélisme ne s'obtient qu'à un niveau macroscopique, par commutation du processeur vis à vis de tâches à l’aide de mécanismes matériels tel que le système d'interruption ou grâce à l'ajout d'un logiciel chargé de gérer le partage du processeur. 376 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION Un système informatique considéré globalement comme un processeur pour les fonctions logicielles à implanter, dispose de mécanismes permettant l'exécution simultanée ou pseudosimultanée de tâches. Ces mécanismes sont offerts par un noyau exécutif appelé moniteur multi-tâches temps-réel ou exécutif temps-réel. La disponibilité de ces mécanismes facilite le travail d'implantation. En effet, l'objectif étant de réduire la partie organisationnelle à développer, cette partie se traduit directement sous la forme d'appels à l'exécutif temps-réel. Ainsi, plusieurs techniques d'implantation sont disponibles pour les tâches suivant le niveau du processeur et donc suivant ses spécifications ou ses caractéristiques. La suite du paragraphe montre l'implantation d'un même exemple dans les 2 cas: sans moniteur temps-réel et avec moniteur temps-réel. Sont aussi indiqués les critères à considérer pour décider de la technique à utiliser. 18.5.1. Implantation sans moniteur temps-réel Dans ce cas toutes les relations entre les actions de la structure fonctionnelle à implanter sur le processeur doivent être transformées selon les règles décrites dans le paragraphe précédent. L'exemple suivant est donné à titre d'illustration d'une implantation complète avec prior T0 > prior T2 > prior T1. Ce même exemple sera utilisé pour présenter la solution avec un moniteur temps-réel.
Structure fonctionnelle
EV Ev T0 T2 Prêt B pour MESS Prêt T1 T2 T1 (Mess) T0

priorité

MESS

Tache de fond

-Figure 18.13- Schéma d'implantation sans exécutif temps-réel. La tâche T0 est activée par l'événement matériel EV. Ainsi, elle récupère inconditionnellement le processeur. T0 est donc plus prioritaire que toutes les autres tâches. La synchronisation entre T0 et T1 selon une priorité décroissante est faite par l'intermédiaire de la Boîte à lettres B et de la tâche de fond. Le comportement de la tâche de fond est le suivant:
cycle: if B.Nb_messages>0 then begin Retrait_message (B, Mess); T1(Mess); end; end cycle;

Ainsi la tâche de fond scrute régulièrement si un message est disponible dans B. Si oui, le premier message est retiré et transmis à T1 pour exécution. M.C.S.E 377

Partie 5 - DEFINITION DE LA REALISATION La période de scrutation par la tâche de fond dépend de l'occupation du processeur à traiter les tâches temporaires (ici uniquement T0). Cet exemple montre la simplicité de la méthode d'implantation et la simplicité de la partie organisationnelle qui en découle. 18.5.2. Implantation avec un exécutif temps-réel L'exécutif temps-réel dans ce cas est à voir comme une tâche ayant la priorité la plus élevée et sollicitée par toutes les autres tâches par appel procédural. La plus grande priorité est justifiée pour que cet exécutif puisse requérir le processeur lorsqu'il le désire de manière à assurer correctement son rôle d'ordonnancement. La figure suivante montre le schéma d'implantation d'une structure fonctionnelle avec utilisation de 4 primitives temps-réel: SIGNAL et WAIT pour la synchronisation, SEND et RECEIVE pour le transfert de messages.
priorité
Exécutif temps-réel
Ev T0 EV Tit
Wait(EV) Signal(EV) Send (V,MESS) Wait(Prêt)

T0 MESS
Receive(V,MESS)

T2
Signal(Prêt)

T1 Prêt T1 T2

Tache de fond

matériel

logiciel

-Figure 18.14- Schéma d'implantation avec un exécutif temps-réel. L'implantation ci-dessus montre bien le rôle d’ordonnanceur joué par l'exécutif temps-réel. Les événements externes pris en compte comme interruptions par le processeur sont gérés par une tâche très courte (Tit) qui se contente de signaler au moniteur temps-réel les événements reçus. Toutes les demandes faites par les tâches à l'exécutif se font par appel procédural. Si la demande implique une attente, l'instant de retour à la tâche appelante est décidé par l'exécutif. L'ordre de retour et donc d'allocation du processeur à la tâche appelante est totalement sous le contrôle de l'exécutif. C'est une raison supplémentaire pour que cette tâche soit représentée comme la plus prioritaire. Pour la compréhension du schéma d'implantation, on donne figure 18.15 une séquence de déroulement pour les 3 actions T0, T1, T2. L'exécutif est donc ici vu comme une tâche particulière unique sollicitée par toutes les tâches du processeur pour chaque action particulière. L'exécutif possède donc de multiples points d'entrée. Il gère l'ordonnancement des retours aux tâches appelantes sur la base de variables internes qui représentent l'état de toutes les tâches, des relations, des demandes ... 378 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION

Priorité Attributions du processeur
Exécutif

Ev
Signal (EV) wait Send (V,MESS) wait (EV) Signal (prêt) (prêt) Receceive (V,MESS)

TIT

wait (EV)

wait (prêt)

Receive (V,MESS)

T0 T2 T1 Tâche de fond

T0 T2 T1

Ev

Initialisation

Déroulement
T0

T2

T1

-Figure 18.15- Exemple de déroulement d'exécution. Si pour un cas simple, l'exécutif peut se comprendre comme une simple tâche, habituellement, compte-tenu des mécanismes offerts: délai, activation périodique, synchronisation sur événements externes ..., un exécutif est lui-même composé d'un ensemble de tâches. Le couplage entre ces tâches peut tout à fait se décrire par le modèle d'implantation décrit dans ce chapitre. La méthode présentée s'avère donc utilisable par les concepteurs d'exécutifs. Pour les applications utilisant un exécutif temps-réel, le schéma d'implantation décrit par la figure précédente n'est pas nécessaire. Il a seulement été donné pour expliquer le rôle joué par un exécutif. Dans ces cas d'applications, il suffit simplement: - de déterminer la priorité de chaque tâche, - de traduire chaque relation fonctionnelle par le ou les mécanismes de l'exécutif disponibles et appropriés. La figure 18.16 montre la représentation suffisante pour une telle implantation. Certains processeurs possèdent en standard dans leur jeu d'instructions des mécanismes de synchronisation et d'échange de données. C'est le cas par exemple du TRANSPUTER d'INMOS. La disponibilité de tels mécanismes implique que le processeur assure de lui-même l'ordonnancement des tâches. Le travail du concepteur se trouve alors simplifié (voir 22.8). Pour le concepteur d'applications, la seule différence qui existe entre ce type de processeur prévu pour la gestion du parallélisme et un processeur plus classique auquel on associe un exécutif temps-réel, est que dans le deuxième cas, il faut ajouter l'exécutif comme logiciel. Les performances sont alors moindres par suite du temps nécessaire pour l’exécution des fonctions du moniteur. M.C.S.E 379

Partie 5 - DEFINITION DE LA REALISATION

Priorité
ITEV

wait(EV)
T0

signal(EV)

send(V,MESS)
T2 wait(prêt)

MESS

Prêt

receive(V,MESS)
T1

signal(prêt)

-Figure 18.16- Schéma d'implantation basé sur un exécutif Temps-Réel 18.5.3. Critères de choix de la technique d'implantation Il est évident que pour réduire le temps de développement d'une application, il est préférable de disposer d'un exécutif. La solution logicielle est plus coûteuse en place mémoire, en temps de traitement des sollicitations (temps de commutation ou overhead), et en terme de prix lorsque l'exécutif est un produit standard du commerce (VRTX, PSOS, iRMX, noyau SCEPTRE...). L'exécutif intégré dans la fonctionnalité du processeur est la solution la plus avantageuse et correspond à une tendance qui va probablement se généraliser. Elle permet au concepteur de voir le processeur comme un exécutif direct multi-tâches, ce qui réduit le travail d'implantation. Le concepteur n'a pas dans ce cas besoin de descendre au niveau de l'ordonnancement de ses tâches. Toutefois, il lui faut toujours déterminer la priorité relative des tâches. Dans l'état actuel de la technologie, beaucoup de microprocesseurs ne disposent pas de cette fonctionnalité. Le choix doit alors se faire entre: l'emploi d'un exécutif ou la définition complète de l'implantation. C'est au concepteur de décider la meilleure solution sur la base de critères techniques et économiques. Les critères à considérer sont: - les contraintes de temps pour l'application. Pour de très fortes contraintes, il faut définir une implantation complète sans exécutif, car c'est la solution qui réduit au maximum les temps de commutation des taches (overhead). - le nombre d'exemplaires. Pour quelques exemplaires, l'emploi d'un exécutif réduit le temps de développement. Pour un grand nombre, comme il faut réduire le coût de chaque exemplaire, ceci implique fort probablement de se passer d'un exécutif standard. - la complexité de l'application. Pour de petites applications dédiées bien spécifiées, l'implantation directe restera simple et efficace. Pour des applications complexes avec des spécifications évolutives, un exécutif temps-réel est certainement favorable. 380 M.C.S.E

Ch 18 - LE MODELE D’INTEGRATION 18.6. CARACTERISTIQUES DU MODELE D’INTEGRATION Le modèle de description d'un système est basé sur l'association de 3 dimensions ou 3 vues: topologique, comportementale, exécutive. La dimension exécutive représente le support "matériel" qui engendre l'évolution de l'application. Une application opérationnelle résulte d'une association correcte de la dimension fonctionnelle avec la dimension exécutive. C'est l'objectif du modèle d'intégration que de spécifier les règles de correspondance entre ces 2 ensembles, puis pour les réalisations logicielles, la structuration pour l'implantation. Les caractéristiques essentielles induites par le modèle d’intégration sont présentées ciaprès.
-A- MODELE DE STRUCTURE

Ce modèle est composé de 2 parties complémentaires. Tout d'abord le modèle d'ALLOCATION définit la correspondance : fonctionnel --> exécutif, ensuite le modèle d'IMPLANTATION définit l'organisation d'une structure fonctionnelle sur chaque processeur. Ce dernier modèle est hiérarchique avec 2 niveaux d'organisation: le niveau TACHES et le niveau MODULES. La spécification de la réalisation en sous-ensembles hiérarchiques avec des interfaces complètement spécifiées, est favorable pour une répartition du travail de réalisation sur plusieurs équipes.
-B- ALLOCATION COMME RESULTAT D’UNE ABSTRACTION

Le modèle d'ALLOCATION décrit des regroupements d'éléments d'une structure fonctionnelle. A chaque regroupement est associé un processeur pour l'exécution. Une telle transformation s'obtient par la technique d'abstraction, en se basant sur des critères de regroupement que sont: connexité, contraintes de temps, taux d'occupation du processeur. L'allocation s'avère correcte si chaque processeur est opérationnel et si la structure fonctionnelle complète est ACCEPTEE par la structure d'exécution.
-C- IMPLANTATION COMME MODELE D’ORGANISATION DU LOGICIEL

Le modèle d'implantation est utilisé pour chaque processeur programmable, définissant ainsi sa fonctionnalité par du logiciel en décrivant l'organisation des éléments et des mécanismes utilisés pour les relations entre ces éléments. Chaque processeur est le support d'exécution d'une structure fonctionnelle comme sousensemble de la structure complète. L'implantation résulte d'une transformation de la structure fonctionnelle selon un ensemble de règles. L'objectif d'une bonne implantation est de réduire au maximum la partie organisationnelle du logiciel. Les 2 niveaux d'organisation - TACHES et MODULES - permettent de représenter simultanément le pseudo-parallélisme d'exécution et l'exécution séquentielle.
-D- DEPENDANCE ENTRE IMPLANTATION ET CARACTERISTIQUES DU PROCESSEUR

Le modèle d'implantation tient compte des caractéristiques fonctionnelles du processeur. Celui-ci peut être vu pour l'utilisateur comme un processeur mono-tâche, ou pour certains processeurs comme étant multi-tâches. La démarche à adopter pour chacun des 2 cas revient à poursuivre l'implantation selon une démarche descendante jusqu'à rejoindre les possibilités des processeurs. M.C.S.E 381

Partie 5 - DEFINITION DE LA REALISATION Le modèle est donc adaptatif vis à vis des évolutions futures de la technologie. On peut imaginer à plus long terme que les processeurs accepteront directement une description fonctionnelle. Le travail de recherche d'implantation deviendra alors très simple. 18.7. RESUME Ce chapitre, complémentaire au précédent, a permis de présenter le modèle d'intégration utilisé pour la définition de la réalisation comme un outil décrivant l’association de la description fonctionnelle et d'une structure exécution. Cette dernière engendre l'évolution spécifiée par la solution fonctionnelle. Les points essentiels sont les suivants: - le modèle d'intégration inclut, l'allocation de la structure fonctionnelle sur la structure d'exécution, la description de l'implantation des actions logicielles sur les processeurs programmables, - une allocation n'est correcte que si la structure fonctionnelle se trouve acceptée par la structure d'exécution et que si tous les processeurs sont opérationnels avec respect de toutes les contraintes de temps, - le modèle d'implantation est structuré en 2 niveaux: le niveau TACHES pour l'implantation des actions et des relations de la structure fonctionnelle, le niveau MODULES pour décrire la décomposition de chaque tâche, - des règles de transformation simples permettent de décider d'une implantation à partir du modèle fonctionnel. - l'implantation à retenir est fonction du niveau de fonctionnalité du processeur. Les 2 approches avec ou sans exécutif temps-réel sont possibles.

382

M.C.S.E

Chapitre 19

DEMARCHE POUR LA DEFINITION DE LA REALISATION

Cette troisième étape de la méthodologie MCSE a pour objectif de proposer une solution complète détaillée qui tient compte de toutes les contraintes technologiques. Comme entrée pour cette étape, le concepteur dispose: - d'un document complet décrivant la solution fonctionnelle, - du document de spécifications contenant tout particulièrement les spécifications technologiques. En résultat, la solution détaillée constituant le document de spécification de la réalisation doit contenir: - la description de la structure d'exécution avec toutes ses spécifications, - la description de l'implantation de tous les éléments de la description fonctionnelle sur la structure d'exécution. Les chapitres 17 et 18 ont servis à décrire le modèle que doit respecter la solution pour que celle-ci puisse être prise comme document d'entrée pour la réalisation. La conception fonctionnelle a conduit à développer la solution la plus appropriée pour le problème, sans tenir compte des contraintes et particularités technologiques.

M.C.S.E

383

Partie 5 - DEFINITION DE LA REALISATION La réalisation résultera de l'association de 2 parties: une partie matérielle comme support d'exécution, une partie logicielle servant à personnaliser le matériel pour satisfaire les spécifications de l'application. Aujourd'hui, il n'y a pas de solution pour obtenir directement une application opérationnelle à partir de la conception fonctionnelle. Aussi le passage de la conception fonctionnelle à une réalisation nécessite un travail de 3 ordres: - d'adaptation tout d'abord pour tenir compte de l'environnement du système avec toutes ses contraintes d'interfaçage. - de sélection du support technologique pour l'application. Dans certains cas le support est imposé, alors une vérification est au moins nécessaire, dans d'autres cas il est à déterminer. - de transformation ensuite, pour modeler la solution fonctionnelle de manière à la rendre opérationnelle sur la technologie retenue ou imposée. Après avoir présenté les objectifs complémentaires ou contradictoires à satisfaire, ce chapitre détaille la démarche préconisée pour que le concepteur détermine avec efficacité une solution conservant les qualités de l'approche fonctionnelle et réduisant au maximum le coût de développement. Contrairement à la conception fonctionnelle, la spécification de la réalisation est la résultante de transformations successives faites à partir de la description fonctionnelle. La démarche est donc plus systématique. 19.1. LES OBJECTIFS A ATTEINDRE La solution de réalisation doit satisfaire plusieurs types d'objectifs: - des objectifs techniques et technologiques, - des objectifs économiques. Ces objectifs sont normalement décrits dans les spécifications technologiques du problème. En complément la solution doit aussi respecter des règles générales de qualité qui induisent des répercussions sur le plan économique. Dans la suite, parcourons tout d’abord les objectifs techniques à satisfaire puis les objectifs économiques. 19.1.1. Spécifications matérielles Dans cette partie des spécifications se trouvent énoncées les contraintes auxquelles la réalisation doit satisfaire.
-A- CONTRAINTES DE REPARTITION

Cette contrainte qui ne se retrouve pas dans toutes les applications, indique que la solution n'est pas regroupée en un même lieu géographique. La réalisation résulte de l'association de plusieurs sous-ensembles reliés entre eux par des liaisons physiques chargées d’assurer les échanges d'informations. La solution dépend de plusieurs facteurs, à savoir: la distance entre sous-ensembles, le débit d'information à échanger, les types de supports disponibles. 384 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Comme la solution fonctionnelle a été développée sans cette contrainte, la délimitation des sous-ensembles se fait sur la base des contraintes de répartition qui expriment le lieu où se trouvent les données. La délimitation met en évidence le couplage et donc les informations à échanger. Une analyse de la nature de ces informations et la fréquence d'échange conduit à spécifier le service de communication nécessaire.
-B- INTERFACES AVEC L’ENVIRONNEMENT

Le système à réaliser est lié à son environnement par des interfaces physiques. Ces interfaces doivent satisfaire la nature physique des signaux échangés. La nature dépend des entités de l'environnement. Retenons 2 catégories différentes: - les entités physiques que sont des procédés industriels, machines et autres. Ces entités fournissent par des capteurs des signaux électriques. En sens inverse, des actionneurs commandés électriquement permettent d'agir sur ces entités. On considère ici que les capteurs et actionneurs, même s'ils sont choisis par le concepteur et inclus dans la prestation, ne font pas partie du système à développer. - les entités autres et tout particulièrement les utilisateurs. Pour ce type de couplage, l'interface est très variable: pupitre conventionnel, clavier-écran, analyse et synthèse de parole... La solution doit répondre au mieux à la convivialité souhaitée pour l'application. Les caractéristiques sont décrites dans les spécifications technologiques.
-C- CONTRAINTES DE REALISATION

Des règles peuvent être imposées par le demandeur et qui limitent les techniques ou technologies possibles pour la réalisation: type de processeurs, de mémoires, de ressources. S'ajoutent à ces règles, un descriptif des caractéristiques de l'environnement dans lequel doit fonctionner le système, la fiabilité et la sûreté de fonctionnement imposées. 19.1.2. Contraintes de temps Les applications qui nous concernent sont de nature temps-réel. Des contraintes existent et qui expriment: des délais de réaction par rapport à l'apparition d'événements, des performances attendues du système. Le respect de ces contraintes de temps nécessite de déduire un support matériel suffisamment dimensionné. Des règles garantissant le respect des contraintes doivent pour cela être clairement énoncées. 19.1.3. Réduction du coût de développement Comme objectif économique, tout projet doit être envisagé avec l'objectif de réduire son coût. Le coût dépend de certaines données qui permettent de choisir un critère pour le développement du produit. La donnée essentielle à prendre en compte pour cette étape est le nombre d'exemplaires à produire. Le coût pour chaque exemplaire est : CT = CRm + (CDm + CDl)/N avec: - CRm - CDm M.C.S.E

le coût de reproduction de chaque exemplaire, le coût de développement du matériel prototype, 385

Partie 5 - DEFINITION DE LA REALISATION - CDl -N le coût de développement du logiciel, le nombre d'exemplaires à produire.

Le tableau suivant indique l'objectif à atteindre pour chaque terme en fonction de la quantité à produire: NBRE CRm matériel) CDm CDl très faible à minimiser à minimiser à minimiser assez élevé à minimiser PEU élevé (achat du MOYEN moyen IMPORTANT à minimiser

Ce tableau montre les 2 cas extrêmes: - Pour une faible quantité: il est plutôt essentiel de minimiser le temps de développement. Ceci s'obtient en renonçant à un développement matériel et en réduisant au maximum le temps de développement du logiciel. - Pour une production importante: il faut consacrer le temps nécessaire en développement pour minimiser le coût de reproduction du produit: coût matière + coût de réalisation + coût de test + coût de maintenance. La différence entre les 2 cas pour le concepteur est: dans le premier cas, utilisation d'une structure d'exécution donnée non-optimisée, dans le deuxième cas: recherche d'une structure d'exécution minimale optimisée pour l'application. Ceci induit 2 stratégies de développement qui seront décrites dans ce chapitre. Dans tous les cas, comme le coût du développement du logiciel prend une part de plus en plus importante, il est utile de chercher à réduire ce coût. 19.1.4. Réduction de la partie organisationnelle Globalement et en moyenne, le coût de la réalisation correspond à près de 50 % du coût total pour l’obtention d’un prototype. Réduire le coût global veut dire qu’il faut viser à réduire la réalisation et donc sa complexité durant les étapes de conception et de définition de la réalisation. Pour une application donnée, la complexité en conception est essentiellement dépendante de la solution retenue comme première décomposition fonctionnelle. L’emploi des modèles génériques favorise l’élaboration de solutions simples et appropriées. La complexité en réalisation dépend du travail effectué durant l’étape de définition de la réalisation. La solution matérielle peut être minimisée pour réduire le coût de production. La partie logicielle doit aussi être minimisée pour être simple à écrire puis à valider. En faisant une analyse plus précise, on constate que la partie logicielle est en fait composée de 2 parties : - la partie dite opérative, c’est-à-dire celle qui exprime toutes les opérations à entreprendre. C’est la partie typiquement algorithmique. 386 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - la partie dite organisationnelle, qui correspond à l’agencement des opérations de la partie opérative au niveau tâches et modules (pas au niveau structures de contrôle de base du niveau algorithmique). La partie opérative, lorsque les algorithmes sont écrits correctement est incompressible. La partie organisationnelle est le résultat de la transformation de la structure fonctionnelle en vue de l’implantation sur un processeur. La complexité dépend donc de la solution retenue pour la structure fonctionnelle mais aussi et surtout des transformations réalisées durant cette étape de définition de la réalisation. L’objectif de la démarche proposée pour déduire le schéma d’implantation logicielle est de réduire au maximum la partie organisationnelle de manière à réduire le temps et donc le coût de développement. Ce point de vue justifie les règles de transformation proposées dans ce chapitre; il est important pour les applications temps-réel. 19.1.5. Règles de qualité Comme objectif plus général, le respect de règles de qualité conduit à une réduction du coût pour l'ensemble du cycle de vie du produit. Le résultat à l'issue de cette étape de définition de la réalisation est un document. Celui-ci joue au moins 2 rôles: - il sert comme document de spécification pour l'étape suivante de réalisation, - il servira aussi plus tard pour la phase de maintenance: correction des erreurs, adaptation et amélioration du produit. La règle de qualité essentielle pour ce document est sa lisibilité. Une bonne lisibilité favorise la compréhension de la solution. Ainsi, les techniciens qui ont en charge la réalisation peuvent utiliser ce document directement avec une sollicitation réduite des concepteurs auteurs. Une bonne compréhension favorise aussi la maintenance. La maintenance évolutive conduit à des modifications. Il faut donc pouvoir déduire du document les limites de la solution, le pourquoi des choix. Cette règle de qualité favorise ainsi globalement le coût du produit. 19.1.6. Objectifs contradictoires Les objectifs précédents sont relativement contradictoires: - réduire le coût de reproduction conduit à minimiser le matériel, - réduire le coût du développement conduit à minimiser le matériel, le logiciel, la documentation, - une bonne documentation et toutes les contraintes technologiques à satisfaire: contraintes de temps, adaptation à l'environnement- imposent de consacrer suffisamment de temps au développement et de mettre en oeuvre une solution répondant à des performances minimales. Les principes développés dans la suite et la démarche proposée dans ce chapitre conduisent à trouver le meilleur compromis entre ces objectifs contradictoires. L'idée globale est d'introduire tout d'abord les interfaces nécessaires pour les contraintes technologiques, puis rechercher la structure d'exécution minimale, enfin définir une implantation qui réduit le temps de développement. M.C.S.E 387

Partie 5 - DEFINITION DE LA REALISATION 19.2. PRESENTATION DE LA DEMARCHE Cette troisième étape a pour objectif de produire une description détaillée de la réalisation à entreprendre. Conforme au modèle de réalisation, elle doit être composée: - d'une structure d'exécution avec la spécification de ses constituants, - de l'intégration composée: • de l'allocation de la structure fonctionnelle sur la structure d'exécution. • de l'implantation des constituants logiciels sur les processeurs programmables du système. Avant de déterminer la structure d'exécution, la solution fonctionnelle doit être modifiée et complétée pour tenir compte des contraintes technologiques de l'environnement. La structure d'exécution est ensuite déduite compte-tenu du critère économique à optimiser. Ensuite pour chaque processeur, est élaboré le schéma d'implantation définissant l'organisation du logiciel et des données. La démarche consiste donc à suivre les phases suivantes: - introduction des contraintes de répartition, - introduction des interfaces: • interfaces physiques, • interfaces homme-machine, • fonctions de test, maintenance, sûreté. - Détermination de la structure d'exécution: • évaluation des contraintes de temps, • répartition matériel/logiciel. - Schéma d'implantation pour chaque processeur. - Spécification de la réalisation matérielle. Le diagramme 19.1 montre l'enchaînement de ces phases, les documents à utiliser et le résultat en sortie. Dans la suite du chapitre, nous détaillons chacune des phases en les illustrant par les 2 exemples traités en conception. Pour l'introduction des adaptations à l'environnement, le lecteur est convié si nécessaire à revoir les principes énoncés pour la conception fonctionnelle (chapitre 14) et qui justifient le report des détails technologiques à ce stade. 19.3. INTRODUCTION DES CONTRAINTES DE REPARTITION Avec l'évolution de la technologie, les réalisations peuvent se développer de plus en plus sous la forme de sous-ensembles faiblement couplés, faciles à répartir géographiquement. Pour les réalisations électroniques, au-delà de quelques mètres, on se trouve dans le cas de la répartition géographique. Si la tendance naturelle consiste à prendre en compte la contrainte de répartition dès la conception, il a été montré dans le chapitre 14 la difficulté de cette approche. La démarche préconisée consiste plutôt à rechercher tout d'abord les couplages fonctionnels, puis après analyse des contraintes de répartition, à rechercher les transformations nécessaires. Cette stratégie permet de se limiter au strict nécessaire pour l'application. 388 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

Solution fonctionnelle + spécifications technologiques

répartition et adaptation Introduction de la répartition

Introduction des interfaces Solution fonctionnelle détaillée

contraintes de temps

Détermination de la structure d’exécution

allocation

Spécification des implantations logicielles

implantation

Allocation et implantation

Spécification de la réalisation matérielle

structure d’exécution

Document pour la réalisation

-Figure 19.1- Enchaînement des phases pour la définition de la réalisation. Les contraintes de répartition indiquées dans les spécifications technologiques concernent: - des informations ou des événements de l'environnement. Les entités concernées par ces grandeurs sont alors réparties, ce qui implique des entrées et sorties réparties pour le système. - des informations ou des fonctions internes au système qui doivent respecter des contraintes de lieu. Avec la contrainte de répartition, certaines relations fonctionnelles ne sont pas directement réalisables à l’aide d’un support matériel disponible pour le transfert des informations entre 2 sites distants. Des transformations de structure sont donc nécessaires. Le principe essentiel à respecter consiste à considérer que tout échange entre 2 sites distants ne peut se faire que par transfert d'information sous la forme de messages. La démarche qui en découle consiste donc: - à délimiter les sous-ensembles de fonctions situés sur des sites différents, - à transformer toutes les relations de synchronisation et de partage de variables par des relations de transfert de messages. Si divers choix de délimitation des sous-ensembles sont possibles, avec le souci de minimiser la complexité de la réalisation, il est conseillé de rechercher comme délimitation les couplages minimums. Les 2 types de relations par événement et par variable sont transformés comme l’indique la figure suivante. Un événement ou une variable est séparé en deux et le couplage est assuré par une fonction de transfert unitaire. Cette fonction est ensuite raffinée en considérant un port interne pour le transfert de message. L’événement Ev’ ou la variable V’ est codé sous la forme d’un message par une fonction d’émission. Le message est décodé par une fonction de réception. M.C.S.E 389

Partie 5 - DEFINITION DE LA REALISATION

Ev

V

Ev’ 1

Ev’’

V’ 1

V’’

V’ Ev’

Emission

M(Ev)

M(V’)

V’’

Reception

Ev’’

Emission

Reception

Interface Répartition

Interface Répartition

-Figure 19.2- Principe pour l'introduction de la répartition. Pour le transfert de Ev’, l’action émission est temporaire, tandis que dans le cas du transfert de V' en V'', l'action émettrice est permanente. La solution d’action permanente n'est bien entendu pas satisfaisante pour l'implantation. En fait, une transmission de V' n'est utile que lorsque celle-ci est modifiée. Pour cela, soit que l'émetteur se trouve chargé de cette observation, soit que le producteur de V' signale à l'émetteur chaque modification. Illustrons la démarche préconisée par un exemple autre que ceux traités en conception qui eux n'incluent pas de contraintes de répartition. Supposons la structure fonctionnelle ci-après:
E1 F1 S1 V E2 F2 V2 F3 V1

E3 F4

1

2

3

4

-Figure 19.3- Exemple de structure fonctionnelle. 390 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION La contrainte de répartition est spécifiée par la position géographique des entités de l’environnement. Supposons E1 et E2 sur le site A, et E3 et S1 sur le site B. Dans un premier temps, il s'agit de placer sur la figure 19.3 une ligne pour séparer les 2 sites. Plusieurs choix sont possibles, 4 sont représentés. Les 2 extrêmes: 1 et 4, considèrent toutes les fonctionnalités sur l'un des 2 sites, tandis que 2 et 3 considèrent une répartition des fonctions du système. Ensuite, la solution s'obtient en remplaçant tous les liens traversant la ligne de séparation pour un seul lien de transfert de messages et ceci pour chaque sens. Pour l’exemple ci-dessus, on obtient les 4 solutions suivantes.
V1 E1 E’1

F1
M(E1,E2) E2 Emission E1 et E2 Réception E1 et E2 V V2 S1

E1

F3

F1
M(V1,V2) V E2 Réception V1 et V2

V1 S1

F3
V2

F2
E’2

F2
E3 Ev M(Ev) E3

F4

F4

CAS 1

CAS 2

E1

V1

E1 M(S1) S1 Réception S1 V E2

V1

F1 F3
V2 E2

F1 F3
V2

M(S1)

Réception S1

S1

F2
M(EV) E3

F2
M(EV) E3 Emission E1

Ev

F4

F4

CAS 3

CAS 4

-Figure 19.4- 4 solutions possibles en fonction de la délimitation. Au vu des structures fonctionnelles résultantes, le concepteur peut faire le choix de la solution la plus simple. Ici le cas 1 semble préférable car la solution met en jeu uniquement une liaison unidirectionnelle. Le site A n'assure que l'acquisition des données E1 et E2 et la transmission au site B. Pour le cas 4, le site B sert pour l’acquisition et la transmission des informations E3 et la réception de S1. Le cas 2 est le plus complexe, car le message transitant entre les sites A et B concerne le transfert de V1 ou de V2. Un codage du type de la variable transférée est à inclure dans le message lui-même. En réception, une fonction d'aiguillage assure la mise à jour sélective de V1 ou de V2. 19.4. INTRODUCTION DES INTERFACES La solution fonctionnelle développée indépendamment de la technologie doit être modifiée pour tenir compte des contraintes technologiques. Comment s'y prendre pour introduire les interfaces nécessaires? M.C.S.E 391

Partie 5 - DEFINITION DE LA REALISATION En conception, partant d'aucune connaissance a priori sur la solution, le concepteur élabore une proposition. Il s'agit d'un travail créatif. Pour la définition de la réalisation, ce n'est pas le cas. Le travail à entreprendre porte sur des adaptations et des sélections. Il s'agit donc beaucoup plus d'une démarche déductive qui part de la solution fonctionnelle et qui, visant à satisfaire les spécifications technologiques catégorie par catégorie, conduit à élaborer une solution détaillée. Introduire des éléments supplémentaires par déduction réduit la déformation de la solution fonctionnelle qui doit rester le noyau "dur" ou stable de l'application. 19.4.1. Modèle pour l’introduction des interfaces Les interfaces ont un rôle technologique d'adaptation du système décrit sur le plan fonctionnel à son environnement. Ces interfaces forment donc une couche concentrique entre les 2 parties de l'application. Les interfaces peuvent se classer en 2 catégories suivant le type d'entité de l'environnement: - les interfaces physiques pour les entités physiques, - les interfaces homme-machine pour les dialogues. Compte-tenu de la nature très différente de ces 2 catégories, il est souhaitable de les traiter séparément. Aux interfaces s'ajoutent des fonctions spécifiques à la technologie que sont les tests, procédures de maintenance, redondance pour la sûreté de fonctionnement. HATLEY propose le modèle générique suivant pour l'introduction des interfaces. Dans ce document, nous suivons l'idée de ce modèle [HATLEY-87].
Environnement
Interface utilisateur Interfaces Solution Solution fonctionnelle Auto-test maintenance Redondances Entrées physiques fonctionnelle Sorties physiques

-Figure 19.5- Modèle générique pour l'introduction des interfaces. La démarche pour introduire les interfaces est identique à celle présentée pour la conception fonctionnelle. En effet, chacune des 4 parties se présente comme une fonction possédant des entrées et des sorties définies, les unes par la nature physique des informations observées ou commandées, les autres par la nature fonctionnelle des grandeurs d'entrée et de sortie. Il s'agit donc pour chaque partie de rechercher une structure fonctionnelle assurant le changement de représentation des informations échangées. Pour cela, les entrées et sorties sont à spécifier ainsi que le rôle de chaque interface. Une fois ces spécifications exprimées, la méthode de conception fonctionnelle permet ensuite de déduire une solution. La même méthode s'applique pour l'introduction des auto-tests, des fonctions de maintenance et pour l'introduction des redondances. 392 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION 19.4.2. Introduction des interfaces physiques Ces interfaces ont pour seul rôle de réaliser un changement de représentation de l'information. Comme la variable de couplage utilisée en fonctionnel est une variable essentielle pour les 2 parties: environnement et système, et si cette variable n'est pas directement observable , une transformation unitaire est nécessaire, et qui résultera de l'association du capteur et de l'interface. Le principe consiste donc à raffiner cette variable de couplage. Une fois spécifiée chaque interface, la technique consiste à utiliser la démarche de conception fonctionnelle pour définir la solution. Celle-ci est à rechercher sur le plan fonctionnel, sachant qu'elle sera maintenant dépendante de la technologie puisque recherchée pour satisfaire ce type de contraintes. La figure ci-dessous illustre la démarche pour le cas d'une observation de la position d'un mobile par un codeur incrémental et le cas d'une commande analogique proportionnelle.
P Cmd

P’ 1

P’’

Cmd’ 1

Cmd’’

Interface
INC P’ Codeur Eval uation position P’’ Cmd’ CNA

Interface
VA Ampli Cmd’’

SENS

Capteur

Système

Système

Actionneur

-Figure 19.6- Introduction des interfaces physiques: exemples. Chaque variable nécessitant une interface est séparée en 2. La fonction intermédiaire doit être unitaire pour conserver l’égalité des deux variables. L'interface est ensuite introduite comme variable interne essentielle. Il reste alors à représenter une fonction inverse de celle du capteur ou de l'actionneur. Cette même technique est utilisable pour un couplage par transfert de messages. Elle est complémentaire de la phase d’introduction de la répartition. En effet, une fois la contrainte de répartition satisfaite, il faut s'adapter aux caractéristiques technologiques du support. Ce support est en réalité une interface physique entre sous-ensembles. Habituellement, le support n'est pas équivalent à une boîte aux lettres capable de mémoriser plusieurs messages. Il s’agit plutôt d’un support pout une transmission série bit à bit de la suite d'octets de chaque message. M.C.S.E 393

Partie 5 - DEFINITION DE LA REALISATION La communication est ici vue comme un service disponible pour l’application. La technique à employer est similaire à celle utilisée pour les interfaces physiques, mais en effectuant une décomposition du service de communication niveau par niveau. Il est conseillé de se baser sur le modèle générique client/serveur (voir en 16.4), et en recherchant les niveaux successifs de communication sur la base du modèle OSI. Comme illustration de cette démarche par la figure 19.7, le transfert de chaque message se décompose en un transfert de caractères, chaque caractère étant transféré sur le support physique comme une suite de bits.
PT F1 F2

Introduction du service message

Introduction du service caractère

F1

F2

F1

F2

PT’

PT’’

PT’

PT’’

Service message
Emission message Réception message

Service message
Emission message Réception message

CAR

CAR’

CAR’’

Service caractère Interface caractère Interface
Emission caractère TxD Synchro Réception caractère

Interface bit

-Figure 19.7- Introduction des niveaux de communication jusqu’au support. Pour le service de communication, il reste en final à étudier la capacité nécessaire ou imposée pour chaque port. Si la capacité d'un port de réception n'est pas suffisante pour mémoriser tous les messages émis, un asservissement consommateur vers producteur est nécessaire. Ceci s'assure par une ligne de retour: RTS sur CTS pour une synchronisation matérielle par exemple, ou par une liaison TxD en sens inverse pour un protocole du type XON/ XOFF. 19.4.3. Introduction des interfaces homme-machine La conception fonctionnelle conduit à retenir comme couplage avec les utilisateurs l’ensemble des messages nécessaires. L'utilisateur n'est pas directement générateur de ces messages. De même, l'interprétation directe de message n'est pas possible. Une interface d'adaptation est donc nécessaire. Celle-ci doit tenir compte du type de convivialité souhaitée défini dans les spécifications technologiques, ce qui induit par déduction l'interface technologique. 394 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Supposons que l'interface utilisateur soit composée d'un clavier et d'un écran. L'interface homme-machine est représentée par la fonction ci-dessous qui assure: l’observation de l’état du clavier, la mise à jour de l’écran, la production et l’interprétation des messages échangés avec la solution fonctionnelle.
TOUCHES Interface Homme-Machine ECRAN

Actions Solution fonctionnelle

Observations

-Figure 19.8- Introduction d’une interface homme-machine. Le raffinement de la fonction est basée sur les spécifications de cette interface qui exprime la procédure d’utilisation. La démarche à suivre est celle présentée pour toute conception fonctionnelle, mais cette fois en tenant compte des caractéristiques technologiques des entrées et des sorties de l'interface. Par exemple, il est possible de se baser sur un modèle générique tel que le modèle d’interactivité présenté en 16.5. Si la solution consiste à ajouter une seule fonction comme interface, tout concepteur doit savoir que le développement de ce type d’interface c’est à dire la programmation pour satisfaire l’objectif est très coûteux en temps de réalisation et de mise au point. L’existence de telles interfaces est une source d’erreurs d’estimation des temps qui peuvent aller du simple au quadruple. L’erreur d’évaluation peut dépendre de la difficulté à cerner la spécification mais aussi de l’imprécision du souhait du demandeur. Pour que le demandeur soit d’accord avec le produit, la spécification du dialogue peut se faire par prototypage. Il s’agit de développer rapidement l’interface avec des outils appropriés qui vont permettre de réaliser facilement des modifications. Les applicatifs générateurs d’interfaces pour cette classe de problème sont très utiles ainsi que les langages orientés objets. Dans la suite, illustrons l'introduction des 2 catégories d'interfaces: entrées/sorties et interfaces utilisateur sur les 2 exemples étudiés en conception. 19.4.4. Exemple 1 : contrôle en vitesse d’un centrifugeur Pour ce problème, les interfaces à satisfaire concernent: l'observation de la vitesse qui se fait par un codeur incrémental, la commande en vitesse du moteur qui est du type PWM, et l'interface utilisateur composée d'un ensemble de touches et un afficheur numérique.
-A- INTRODUCTION DES INTERFACES PHYSIQUES

Pour la commande du moteur, il s'agit de transformer la grandeur CV en une grandeur à 2 états de période 1KHz et de rapport cyclique proportionnel à CV. Ceci est assuré par une fonction d'interface appelée GENERATION_PWM. De même pour obtenir la vitesse VMOTEUR à tout instant, il faut exploiter l'événement produit par le codeur incrémental. M.C.S.E 395

Partie 5 - DEFINITION DE LA REALISATION La figure ci-après montre l'introduction des 2 interfaces.

VROTATION

ORDRE

Contrôle en vitesse du centrifugeur
Interface d’entrée
CV
Génération PWM

EROTATION

Interface de sortie

Moteur Vmoteur

INC_ROT Evaluation Vmoteur Codeur vitesse

SPWM Ampli

CV
Moteur

G=1

G=1

-Figure 19.9- Introduction des interfaces physiques. Chaque fonction se raffine par la méthode préconisée pour la conception fonctionnelle. Pour cela, il faut rechercher les variables ou événements internes caractéristiques. Pour générer le signal PWM, il faut tout d'abord produire une transition positive selon une période fixe. Soit HPERIODE l'événement correspondant. Ensuite, il faut produire la transition négative au bout d'un temps t fonction de la valeur CV. L'évaluation de ce temps nécessite un événement HB de fréquence élevée par rapport à Hpériode (rapport 1000). Ainsi la structure fonctionnelle utilisable pour cette fonction est la suivante.
Génération_PWM CV Génération niveau 1 Hpériode SPWM

HB Horloge

Génération période

-Figure 19.10- Structure fonctionnelle pour GENERATION_PWM. Les algorithmes sont faciles à écrire.
Action GENERATION_PERIODE sur événement HB avec (sortie événement HPERIODE); const NMAX = 1000; Var N: integer; begin N:=NMAX;

396

M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION
cycle HB: begin N:= N - 1; if N = 0 then begin N:=NMAX; Signal(HPERIODE); end; end; end cycle; end GENERATION_PERIODE;

Pour l'action GENERATION_NIVEAU1, il s'agit d'un comportement en 2 états; état1 pour une durée en rapport avec CV, état 0 pour le temps restant.
action GENERATION_NIVEAU1 sur evs HB, HPERIODE avec (entrée var CV: integer; Sortie var SPWM: 0,1); const K = ...; Coefficient d’adaptatation; var RESTE: integer; begin SPWM := 0; cycle HPERIODE: RESTE:= K*CV; HB: if RESTE > 0 then begin SPWM:= 1; RESTE:= RESTE - 1; end else SPWM:= 0; end cycle; end GENERATION_NIVEAU1;

Ces 2 algorithmes peuvent bien entendu être regroupés pour ne former qu'une seule action: RESTE et N sont alors considérées comme variables internes à GENERATION_NIVEAU1 et modifiées sur apparition de HB. Pour déterminer la vitesse, deux principes sont utilisables à partir des événements émis par le codeur incrémental: - le principe du périodemètre, en comptant le nombre de périodes élémentaires entre 2 impulsions du codeur, - le principe du fréquencemètre, en comptant le nombre d'impulsions du codeur durant un intervalle de référence. Les 2 solutions avec la structure fonctionnelle correspondante sont indiquées figure 19.11. Le choix entre les 2 solutions doit se faire sur la base de la précision et de la vitesse d'obtention de la mesure. - périodemètre: faible précision à grande vitesse, mais temps de mesure faible, temps de mesure long pour les vitesses faibles. - fréquencemètre: faible précision à petite vitesse, grande précision à grande vitesse, temps de mesure constant mais plutôt faible. Pour la solution fréquencemètre: avec une période T de 5 ms correspondant au pas souhaité pour la régulation avec un codeur 100 points/tr, le nombre maximum d'incréments est de 10 à vitesse maximale de 3000 trs. Cette solution ne donnera donc pas une précision suffisante. Pour cette raison, le choix se porte sur le principe du périodemètre. M.C.S.E 397

Partie 5 - DEFINITION DE LA REALISATION La période H s'évalue compte-tenu de la précision désirée à vitesse maximale. D'après les spécifications, celle-ci doit être de 10 trs à 3000 trs. Il faut donc au minimum 300 tops de H entre 2 incréments distants alors de 0,2 ms. La période max de H est donc de 0,66 µs. Avec un comptage en 16 bits, la vitesse minimale mesurable est de: 13,8 trs/mn. Or il est imposé d'avoir 10 trs sur toute la gamme.
Principe périodemètre
INC INC

Principe fréquencemètre

H V = k / nbH

T (période de mesure) V = k * nbINC / T

Calcul vitesse INC V := k / nbH nbH := 0
H O R L O G E

Calcul vitesse V
H O R L O G E

V H V := k * nbINC nbINC := 0 nbINC

nbH H INC Comptage durée

Comptage fréquence

-Figure 19.11- Structures fonctionnelles pour la mesure vitesse. Pour résoudre ce problème de précision, on peut adopter le principe d'un périodemètre autoadaptatif. Ceci veut dire que si le nombre d'impulsions de H compté n'est pas suffisant, on attend l'événement INC suivant. La période de H est alors calculée pour que le dépassement des 16 bits corresponde à une vitesse inférieure à 10 trs/mn. Ainsi la période de H doit être de: 0,915 µs. L'algorithme de CALCUL_VITESSE s'écrit alors comme suit.
Action CALCUL_VITESSE sur ev INC avec (entrée/sortie var NBH: integer; Sortie var V: def_vitesse); const NBMIN = 1000; NBMAX = 65535; (débordement 16 bits) K = 659340; ( 60/nb_pts/tr * pas H(s) ) Var N, NB, N1:integer; begin V:=0; N:=0; NBH:=0; cycle INC: begin N:=N+1; if NBH>NBMIN then begin NB:= NBH; N1:=N; N:=0; NBH:=0; if NB > NBMAX then V:=0 else V:=(K*N1)/NB; end; end; end cycle; end CALCUL_VITESSE;

398

M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Cet algorithme est intéressant car il réduit la fréquence de calcul de la vitesse (qui nécessite au moins une division) à une valeur suffisante pour la régulation, ceci à l'aide du choix approprié de NBMIN. Il est supposé que l'action COMPTAGE_DUREE arrête l'incrémentation de NBH lorque la valeur maximale est atteinte.
-B- INTRODUCTION DE L’INTERFACE UTILISATEUR

En sortie, les seules grandeurs sont: VROTATION qui indique à tout instant la vitesse de consigne, et ROTATION un indicateur précisant si le moteur tourne ou ne tourne pas. Ces 2 grandeurs sont considérées compatibles avec les interfaces physiques que sont: un afficheur décimal 4 digits et une led. En entrée pour le niveau fonctionnel, l'utilisateur a été considéré comme générateur d'événements. L'interface fonctionnelle justifie l'emploi d'un port ORDRE. Dans le cas du réglage de la vitesse de consigne, cette grandeur est transmise dans le message qui indique ainsi l'événement changement de consigne. L'interface physique pour l'utilisateur, décrite dans les spécifications, est composée de 4 touches: MARCHE et ARRET pour le contrôle en rotation, PLUS et MOINS pour le réglage de la vitesse. L'interface utilisateur à développer est représentée figure 19.12.
PLUS MOINS MARCHE ARRET Gestion dialogue VROTATION

ORDRE

ETAT

Contrôle en Vitesse du Centrifugeur

EROTATION

-Figure 19.12- Délimitation de la fonction à concevoir. La spécification fonctionnelle indique que la modification de la consigne de vitesse ne peut se faire que lorsque le centrifugeur est arrêté. Une variable d'état (ETAT) est nécessaire en entrée de gestion dialogue. Cette variable est directement la variable ETAT issue de CONTROLE_VITESSE. Pour effectuer le réglage par les touches PLUS et MOINS, l'utilisateur doit aussi pouvoir visualiser la consigne durant la modification. VROTATION doit être couplée à GESTION_DIALOGUE et n’est plus nécessaire pour GESTION_ CENTRIFUGEUR. La fonction GESTION_DIALOGUE peut se décrire directement par un algorithme, en supposant que cette fonction scrute en permanence les états des 4 touches en entrée et ainsi détecte les événements correspondants. La spécification de la fonction est donnée figure 19.13. M.C.S.E 399

Partie 5 - DEFINITION DE LA REALISATION

Repos (PLUS ou MOINS ) .MARCHE.ARRET

MARCHE .ARRET (ETAT = arrêt) Attente ordre ARRET

Ordre(Marche)

Réglage consigne Ordre(Arrêt) 2 sec. sans appuyer sur PLUS ou MOINS

Visualisation par VROTATION

Ordre(Consigne ; Val_consigne := VROTATION)

Attente fin (ETAT = arrêt)

-Figure 19.13- Spécification de la fonction GESTION_DIALOGUE. 19.4.5. Exemple 2 : automatisation par chariot filoguidé Le chariot est ici un élément d'une application répartie. Le couplage entre ce chariot et le quai avec qui il dialogue est du type transfert de messages. Ainsi, la conception fonctionnelle est conforme aux règles de répartition. Les interfaces à introduire servent uniquement de couplage avec des entités physiques, le chariot n'étant pas contrôlable directement par l'utilisateur.
-A- INTRODUCTION DES INTERFACES POUR LA COMMUNICATION

Le couplage pour la communication est assuré par une transmission infra-rouge bidirectionnelle. Ce support est similaire à une transmission série sur un fil. Les interfaces nécessaires sont représentées figure 19.14. Chaque message est simple; un octet suffit. Ainsi, les 2 fonctions: réception et émission sont classiques et se décomposent pour mettre en évidence les composants physiques adaptés pour la transmission tel qu’un UART.
-B- INTRODUCTION DES INTERFACES POUR LES ENTREES ET SORTIES

Les grandeurs à observer sont: les vitesses de chacune des roues et la distance DCA. Les commandes pour la vitesse de chaque roue sont des grandeurs analogiques. La distance DCA va se déduire comme la différence entre les informations AC1 et AC2 fournies par 2 capteurs situés à l'avant de chaque côté du fil de guidage. La solution indiquée figure 19.15 montre l'emploi d'une seule fonction de conversion pour obtenir DCA par différence AC1-AC2. La conversion est synchrone à l’événement périodique START. En fin de conversion, EOC engendre l’utilisation de VCAN pour le calcul de DCA après la mesure des deux voies. 400 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

Interface d’entrée

Interface de sortie

RxD

Réception des ordres

ORDRE Supervision

CR

Emission des compte-rendus

TxD

E_CAR

RxD

R E C P T E U R

reçu

R E C E P T I O N

O R D R E

ORDRE Supervision

CR

produit E M S_CAR I S S I O N C R émis

E M E T T E U R

TxD

-Figure 19.14- Introduction des interfaces pour la communication.

Mesure de DCA Horloge
START EOC AC AC2

AC1

Conversion analogique numérique
VCAN

Calcul de DCA

DCA

Sélection entrée

NO_VOIE

-Figure 19.15- Exemple de solution pour la mesure de DCA. La mesure de la vitesse pour chaque roue se fera selon le principe du périodemètre de manière à avoir une observation rapide de la vitesse pour des déplacements rapides (voir figure 19.16). A vitesse maximale, le nombre d'incréments fourni par le codeur est: 128 x (5000/3600)/ 0,94 = 189 M.C.S.E 401

Partie 5 - DEFINITION DE LA REALISATION

Mesure_vitesse
INC

Evaluation_vitesse

VM

T

Evaluation_temps

Horloge

H

-Figure 19.16- Solution pour la mesure de chaque vitesse. la période minimale de INC est donc: 5,3 ms. Pour une précision de 5%, il faut TH = 0,26 ms. La génération des 2 grandeurs analogiques CVM1 et CVM2 nécessite l'utilisation de convertisseurs numérique-analogiques comme fonctions permanentes. 19.5. CONTRAINTES POUR UNE STRUCTURE D’EXECUTION L'allocation a pour objectif de déterminer le support exécutif nécessaire pour assurer l'évolution de l'application. Plusieurs démarches sont possibles suivant la nature du résultat attendu. Celui-ci dépend de la stratégie de développement à respecter et qui a une influence sur le coût: faible coût de reproduction ou faible coût pour le développement du matériel. Pour être correcte, une allocation doit conduire à un système respectant toutes les contraintes de temps. Les règles de vérification sont détaillées tout d'abord. On décrit ensuite 3 techniques de recherche d'une structure d'exécution: par regroupement, par raffinement, par abstraction. 19.5.1. Evaluation des contraintes de temps Le modèle fonctionnel utilise l'hypothèse du temps nul pour le déroulement des opérations des fonctions élémentaires. Cette hypothèse ne tient plus dès qu'intervient un support d'exécution. Le temps d'exécution des instructions (puissance non-infinie du processeur) introduit une distorsion temporelle sous la forme de retards. Certaines distorsions ne sont pas gênantes, d'autres par contre peuvent conduire à un non-respect des contraintes de temps. Lorsque pour une application, des contraintes de temps existent, elles s'expriment dans les spécifications technologiques sous la forme d'un temps séparant l'instant d'apparition d'une sollicitation (traduit par un événement) de l'instant d'achèvement de l'action conséquente qui doit rester inférieur à un temps maximum donné. Le non-respect de ces contraintes peut conduire l'application dans un état assimilable à un état de panne matérielle. 402 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION D'autre part, pour réduire le support technologique, si possible, plusieurs actions sont implantées sur un même processeur. Le partage du processeur pour les actions peut aussi conduire à des retards d'exécution non-tolérables. Dans le modèle d'allocation, un processeur qui satisfait toutes les contraintes de temps pour les actions qu'il supporte, est considéré OPERATIONNEL. Un processeur est dit OPERATIONNEL si son taux d'occupation à tout instant reste inférieur à 1, et si toutes les contraintes de temps pour les actions se trouvent respectées. Pour vérifier le respect des contraintes de temps, lorsqu'une solution est définie ou pour en choisir une qui les respecte, il faut évaluer 2 paramètres pour chaque action temporaire [CALVEZ-82] : - la fréquence maximale d'activation FA, - le temps d'exécution maximum TE. Ces 2 paramètres sont indépendants. Le premier, la fréquence d'activation, définie par les événements ou messages en entrée de l'action, se déduit des spécifications du problème et de l'analyse de la description fonctionnelle. Ce paramètre est indépendant de la structure d'exécution. Le temps d’exécution par contre, est fonction pour le processeur retenu, des temps d'exécution des opérations qui composent l'algorithme de l'action et donc de la puissance du processeur utilisé. Pour satisfaire les contraintes de temps, le concepteur peut agir: - sur le nombre et la nature des actions associées à un processeur, - sur les temps d'exécution de chaque action et ceci, soit en modifiant l'algorithme, soit en changeant la nature et donc la puissance du processeur d'exécution. Seules les valeurs les plus défavorables pour les 2 paramètres FA et TE sont utiles pour vérifier le respect a priori des contraintes de temps. On se placera ici en plus dans le cas d'actions possédant en entrée plusieurs événements d'activation.
-A- DEMARCHE

L’évaluation des contraintes de temps pose quelques problèmes pour au moins 2 raisons: - les actions implantées en logiciel ne sont pas connues à ce stade. Au contraire, la solution -matérielle ou logicielle- pour chaque action se décide à partir de cette évaluation des contraintes de temps. - le type de processeur n'est pas connu. Ainsi le temps d'exécution est difficilement évaluable. Malgré cette difficulté, pour pouvoir décider du support matériel, la démarche proposée est la suivante: - analyser la structure fonctionnelle complète et classer les actions en 3 catégories: celles à réaliser obligatoirement par un processeur spécialisé (solution matérielle), celles à réaliser à l'aide d'un processeur programmable, les actions réalisables par les 2 techniques. - évaluer les temps d'activation et d'exécution pour les actions des 2 dernières catégories en se basant sur une catégorie de processeur (8 bits de préférence, sinon 16 ou 32 bits). M.C.S.E 403

Partie 5 - DEFINITION DE LA REALISATION Le point de départ de l'analyse est la structure fonctionnelle complète comprenant les interfaces. Celle-ci représente toutes les actions du système. Toutes les transformations fonctionnelles ont été faites: introduction de la répartition et des interfaces, discrétisation au maximum des actions permanentes pour en réduire le nombre, réduction du nombre de générateurs du type horloge pour augmenter le synchronisme des événements. L'évaluation se traduit par un tableau des valeurs maximales. La fréquence d'activation se déduit des spécifications, tandis que le temps d'exécution se déduit de la longueur et de la nature de l'algorithme de l'action. Ces temps sont ensuite à comparer aux contraintes de temps indiquées dans les spécifications technologiques. Les actions qui méritent une attention particulière sont celles qui ont un taux d'occupation élevé T0 = FA*TE > 0,2 à 0,5 et celles pour lesquelles le temps d'exécution maximum est de l'ordre de grandeur de la contrainte de temps de fin d'exécution.
-B- EVALUATION DES FREQUENCES MAXIMALES D’ACTIVATION

Le cas le plus défavorable pour la fréquence maximale d'activation FA correspond à la valeur maximale des fréquences d'apparition des événements d'activation de l'action. Or ces événements sont directement liés aux événements engendrés par les entités de l'environnement ou par d'autres actions. Les spécifications permettent donc de déterminer leurs valeurs. Pour les actions permanentes génératrices d'événements, la fréquence de génération en sortie n'est fonction que du comportement de l’action. FA se déduit aussi des spécifications. Il est à noter que la fréquence de production des messages n'intervient pas dans l'évaluation des fréquences maximales. En effet, le port est utilisé comme tampon entre producteur et consommateur. Si toutefois des contraintes existent, telle que la capacité limitée du port pour l'implantation, il faut alors faire la même évaluation que celle décrite ci-dessus, en considérant que la production d'un message correspond à la génération d'un événement du type "existence d'un message".
-C- EVALUATION DU TEMPS D’EXECUTION MAXIMUM

Le temps d'exécution maximum pour chaque action est directement lié au processeur servant de support d’exécution. L'évaluation est d'autant plus difficile que le processeur est luimême un élément à choisir, et que même s'il est imposé la transposition: description algorithmique —> programme- n'est faite que durant l'étape de réalisation. Le travail de transcription peut se réduire en utilisant des traducteurs automatiques, ce qui justifie l'intérêt de s'orienter vers l'utilisation de langages de haut-niveau. En l'absence de contraintes pour les processeurs à utiliser, le temps d'exécution est évalué pour un PROCESSEUR dit de REFERENCE qui correspond à une catégorie de performances. Comme type de processeur, on peut prendre le processeur 8 bits, le processeur 16 bits, ou le 32 bits si nécessaire. L'analyse (analyseur de performances) ou la simulation d'une action temporaire permet de déterminer pour un processeur de référence, le temps d'exécution maximum pour chaque activation de l'action (traitement indécomposable temporellement). Les séquences de traitement associées à chaque événement étant matériellement exclusives, le cas le plus 404 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION défavorable pour l'action apparait lorsque tous les événements d'activation apparaissent simultanément. Le temps maximum d'exécution est égal à la somme des temps maximums d'exécution de chaque séquence. La figure suivante montre ce cas et présente le déroulement séquentiel pour satisfaire l’exclusion de T1 et T2.
H MESS T1 H T1 T2

cycle H: begin T1; end; MESS : begin T2; end; end cycle;

TAmin

T1 T2

T1

(Tex(T1)+Tex(T2))max

-Figure 19.17- Cas le plus défavorable pour le temps d'exécution. Pour être correcte, l'évaluation du temps d'exécution doit inclure les temps de commutation de contexte qui peuvent apparaître lorsque plusieurs actions se partagent un seul processeur. Pour cela, la durée maximale sera obtenue en considérant que le processeur est trouvé avec un autre contexte avant l'exécution et rendu dans le même état en fin d'exécution. De cette manière, il y a automatiquement prise en compte du coût en temps de gestion du partage du processeur (overhead). Lorsque l’algorithme est écrit en langage de haut-niveau (PASCAL par exemple), une première approximation des temps d’exécution s’obtient par la formule suivante: Tex = nb_lignes_de_programme * Facteur_expansion * Temps_moyen_instruction Le facteur d’expansion correspond à la transformation d’une instruction PASCAL en instructions assembleur. Il est de l’ordre de cinq pour un processeur 8 bits, de 3 à 4 pour un processeur 16 bits. Temps_moyen_instruction est le temps moyen d’exécution des instructions assembleur. Pour un 8 bits, il est de l’ordre de 2 µs et de 1 µs pour un 16 bits. Bien entendu, ceci n’est qu’une formule approximative mais qui permet avec peu d’expérience de recenser les actions contraignantes.
-D- TAUX D’OCCUPATION MAXIMUM D’UN PROCESSEUR POUR PLUSIEURS ACTIONS

Pour chaque action temporaire, la fréquence maximale d'activation est FAi et son temps d'exécution maximum est TEi. Le taux d'occupation maximum pour n actions exécutées sur un processeur requérable (Suspension d'une action au profit d'une autre plus prioritaire) est alors : T0 max =

Σ
i=1..n

FAi*TEi

Ce taux doit toujours rester inférieur à 1, condition strictement nécessaire mais pas suffisante pour que le processeur soit considéré opérationnel. M.C.S.E 405

Partie 5 - DEFINITION DE LA REALISATION
-E- RESPECT DES CONTRAINTES D’ACTIVATION

La politique d'ordonnancement des tâches sur le processeur a une importance sur le respect ou non des contraintes de temps. Pour une action périodique, l’exécution de l’action doit être achevée avant que n’apparaisse l’événement d’activation suivant. On montre ci-dessous 2 cas d'ordonnancement suivant la priorité pour les 2 mêmes actions A1 et A2.
MAUVAIS
A1 A2

BON
A1 A2

perdu

Priorité
A2

Priorité

A1

fin de A1

Prior. A1 < Prior. A2

Prior. A1 > Prior. A2

-Figure 19.18- Influence de l'ordonnancement vis à vis des contraintes de temps. Pour le premier cas, un événement d’activation de A1 est perdu car le processeur est alors alloué à A2. Comme règle pour l'ordonnancement, on retiendra une stratégie simple et suffisante basée sur un ordonnancement à priorité fixe. L'utilisation du processeur pour ce critère est alors optimal en choisissant: priorité Ai > priorité Aj pour FAi > FAj ∀i et j Cette stratégie est particulièrement adaptée aux microprocesseurs qui, compte-tenu de leur faible coût, ne nécessite pas une utilisation maximale de leur puissance, contrairement aux systèmes informatiques. Attention toutefois, car cette méthode ne tient pas compte des sections critiques qui peuvent exister avec l’emploi des variables partagées. Un tournoi conflictuel peut exister entre l’ordonnancement à priorité fixe et l’exclusion mutuelle [KAISER-82].
-F- RESPECT DES DATES DE FIN D’EXECUTION

Les contraintes de temps du type échéance (deadline), sont plus sévères que les précédentes, car la date de fin est normalement antérieure à la date d’apparition de l’événement suivant. Pour vérifier le respect de telles contraintes, il faut déterminer a priori la date de fin d’exécution de chaque action. La détermination est itérative à partir de l’action la plus prioritaire. Pour un ordonnancement à priorité fixe, supposons les priorités telles que : priorité A1 > ... priorité Ai > ...priorité An Le cas le plus critique apparait lorsque tous les événements d'activation sont simultanés. Soient: - RDi: le retard maximum pour le début d'exécution de Ai, - RFi: le retard maximum pour la fin d'exécution de Ai, 406 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - TOi: le taux d’occupation du processeur pour l’action Ai et toutes celles plus prioritaires, - TEi: le temps d'exécution de Ai sur le processeur totalement disponible. On obtient les résultats suivants pour les différentes actions: RD1 = 0 RD2 = TE1 ... RDi = TEi-1/(1-TOi-2) RF1 = TE1 RF2 = TE2/(1-TO1) ... RFi = TEi/(1 - TOi-1)

Ces valeurs peuvent servir à vérifier pour chaque action le respect des contraintes de fin d'exécution.
-G- CAS DES TRES FORTES CONTRAINTES DE TEMPS

Il est possible de tomber sur la situation où la contrainte de temps d'une seule action ne peut être satisfaite: processeurs actuels pas assez performants, action particulièrement complexe. Pour un tel cas, il est souhaitable de revenir à l'étape précédente de conception et rechercher pour l'action une solution fonctionnelle en mettant en évidence un parallélisme. Il s'agit alors d'une transformation d'un algorithme séquentiel en une structure à évolution parallèle. Ceci se fait à partir du graphe flot de données qui décrit les relations d'ordre.
-H- CAS DES ACTIONS PERMANENTES

Normalement, les actions permanentes nécessitent chacune un processeur d'exécution. Pour réduire la complexité matérielle, 2 solutions sont exploitables: - Transformer les actions permanentes en actions temporaires. Ceci revient à discrétiser dans le temps l'évolution de l'action. Pour cela, il suffit de définir un pas de discrétisation, la période se déterminant comme la valeur maximale tolérée pour que l'action temporaire donne un comportement suffisamment proche de l'action permanente de départ, de manière à toujours satisfaire les spécifications. Une fois définie la période, il faut ajouter l'action de génération de l'événement d'activation. Cette technique est classique pour transformer les fonctions du type continu en fonctions discrètes. - Regrouper plusieurs actions permanentes dans la tâche de fond. Cette tâche de fond est en fait la seule tâche permanente possible pour un processeur programmable. Elle sert alors de séquenceur pour allouer périodiquement le processeur aux actions permanentes qu'elle regroupe. La vérification du respect des contraintes de temps pour le deuxième cas nécessite d'évaluer: - le taux d'utilisation du processeur disponible pour la tâche de fond et les actions qu'elle englobe, - la fréquence d'exécution de chaque action qui découle du taux d’utilisation disponible, - la durée maximale d'exécution. Pour expliquer ceci, supposons une tâche de fond regroupant les 2 actions A1 et A2. Elle s'écrit comme suit: M.C.S.E 407

Partie 5 - DEFINITION DE LA REALISATION
cycle: begin P(A1); P(A2); end; end cycle;

P(A1) et P(A2) sont les procédures construites en ne gardant de A1 et de A2 que la séquence d'instructions inclue dans l’instruction cycle. Soient TE1 et TE2 les temps d'exécution de chaque procédure sur un processeur donné. Supposons de plus que le processeur supporte d'autres actions temporaires. Le taux maximum d'utilisation du processeur pour ces actions temporaires est TOmax. Le taux d'utilisation disponible minimum pour la tâche de fond est: TU = 1 - TOmax La période minimale d'exécution de P(A1 et P(A2) est donc: Tfond = (TE1 + TE2)/TU La durée maximale d'exécution (en moyenne) pour A1 et A2 est: TE1/TU ou TE2/TU Ce calcul simple montre que la tâche de fond dispose d'un processeur dont le facteur de puissance est réduit de 1 à TU avec les actions temporaires. 19.5.2. Techniques pour déduire une structure d’exécution La structure d'exécution résultera de la démarche suivie pour la déterminer qui est fonction du type de développement: faible nombre d'exemplaires, ou nombre important. Indépendamment de ces 2 cas, une structure d'exécution peut s'obtenir: - par regroupement de structures prédéfinies, - par raffinement, - par abstraction.
-A- REGROUPEMENT DE STRUCTURES PREDEFINIES

Cette technique consiste à exploiter des structures d'exécution existantes pour construire des structures plus complexes. Les structures existantes résultent, soit de développements antérieurs, soit correspondent à des produits existant sur le marché: carte processeur au format STD, VME, Multibus... Cette technique en faveur de la réutilisation de solutions existantes conduit à une réduction considérable du coût de développement de la solution matérielle, mais conduit à un coût de reproduction assez élevé. Elle est favorable pour un développement en nombre limité.
-B- PAR RAFFINEMENT

Tout processeur spécifié et qui n'est pas directement réalisable avec la technologie actuelle ou imposée, peut se décomposer sous la forme d'une structure d'exécution plus élémentaire. Cette technique est exploitable par les concepteurs de circuits ou de cartes et par les techniciens chargés du développement du matériel nécessaire pour satisfaire les spécifications de la structure d'exécution. Ceci est possible, car le modèle d'exécution est un modèle hiérarchique qui permet de décrire tout niveau d'architecture, des systèmes complexes jusqu'aux composants de base de l'électronique numérique. 408 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION
-C- PAR ABSTRACTION

Pour un sous-ensemble d'une structure d'exécution donnée, il peut être intéressant de le remplacer par un seul processeur. Dans ce cas, la réalisation se trouve simplifiée car le nombre de composants diminue et les interconnexions deviennent internes au processeur. Utilisant cette technique, il faut s'assurer que le processeur de remplacement reste opérationnel pour la description fonctionnelle qu'il doit supporter. L'opération d'abstraction consiste: - à délimiter un ensemble de processeurs, - à faire disparaitre tous les éléments internes à l'ensemble, - à remplacer l'ensemble délimité par un processeur défini par ses spécifications. Le choix des regroupements doit tenir compte des couplages pour réduire au maximum la complexité de la structure résultante. Le couplage entre 2 processeurs est fonction des facteurs suivants: le nombre de liens d'interconnexion, la taille des informations échangées, la fréquence des échanges, le coût en temps des échanges.

19.6. DETERMINATION DE LA STRUCTURE D’EXECUTION Selon l’analyse faite en 19.1, pour une petite série, le concepteur s'oriente plutôt vers l'utilisation de produits existants. il suffit alors de s'assurer qu'une allocation de la description fonctionnelle est possible sur la structure d'exécution souhaitée. Pour des productions de plus grande série, l'objectif est de réduire au maximum le coût de reproduction du matériel. Ceci conduit à rechercher une structure d'exécution minimale. La technique à utiliser est celle de l'Abstraction. Le concepteur part d'une structure d'exécution similaire à la structure fonctionnelle. Ceci veut dire qu'il associe un processeur pour chaque action, en utilisant au maximum des processeurs programmables. Il réduit ensuite progressivement par abstraction la structure d'exécution en implantant plusieurs actions sur un même processeur tout en vérifiant le caractère opérationnel. La recherche des regroupements se fait par couple de processeurs en se laissant guider par les couplages. Ceci n'est bien sûr possible que pour les processeurs programmables. Dans la pratique, une telle recherche de solution est relativement simple à partir des caractéristiques temporelles des actions de la description fonctionnelle, car l’expérience nous a montré que pour une application donnée, il n'existe en fait que peu d'actions avec de fortes contraintes de temps. 19.6.1. Choix de la répartition matériel / logiciel La solution à retenir dépend donc du critère de développement: faible nombre ou production importante. Dans le cas d'une faible série, il s'agit de trouver le support matériel capable de supporter toutes les fonctions du système. On s'oriente alors vers des structures d'exécution générales extensibles disponibles sur le marché. Des interfaces ou des fonctions particulières peuvent manquer. Elles s'ajoutent alors comme extension. M.C.S.E 409

Partie 5 - DEFINITION DE LA REALISATION Lorsqu'il s'agit de réduire le coût de reproduction du matériel, il faut rechercher la structure d'exécution minimale. Des choix peuvent aussi apparaître entre solution matérielle ou solution logicielle. Entre les 2, la solution logicielle est préférable car évolutive mais aussi moins coûteuse pour la reproduction, à condition que le temps de développement ne soit pas excessif et que les performances restent satisfaisantes. La démarche pour déduire la répartition matériel/logiciel part du tableau d'évaluation des temps pour les actions. Toutes les actions correspondant à un taux d'occupation faible et sans contrainte de temps, ce qui est le cas pour au moins 80% des actions si ce n'est pas plus, sont regroupées pour être implantées sur un même processeur. Le taux d'occupation du processeur est calculé au fur et à mesure de l'ajout d'une action. Même si la méthode est générale et que la détermination peut se faire d'une manière incrémentale en considérant les actions par couple, l'expérience nous a montré que la solution se déduit assez simplement, car dans la plupart des cas, toutes les actions réalisables par logiciel sont implantables sur un même processeur. Parfois, lorsque quelques actions sont particulièrement contraignantes, il suffit de s'y intéresser plus spécifiquement. Plusieurs solutions sont alors possibles: - réalisation par une solution matérielle, - modification des spécifications d'exécution (fréquence d'activation), - modification de l'approche fonctionnelle pour réduire les contraintes, - choisir un processeur plus performant (16 bits par exemple au lieu de 8 bits). Ces 2 phases -évaluation des contraintes et choix de la répartition- sont illustrées sur les deux exemples de conception. 19.6.2. Exemple 1 : contrôle en vitesse d’un centrifugeur Une fois discrétisées toutes les actions utiles, puis après réduction des générateurs d'événements périodiques, on aboutit à la structure fonctionnelle complète donnée figure 19.19.
-A- EVALUATION DES CONTRAINTES DE TEMPS

Pour la régulation, on supposera que, compte-tenu de l'inertie faible du moteur, une période d'échantillonnage de 5 ms est correcte. Les périodes des événements sont donc: T_HB = 0,915 µs # 1 µs, T_HPERIODE = 1 ms, T_INC = 0,2 ms, T_H = 5 ms.
-B- REPARTITION MATERIEL/LOGICIEL

Les actions DIVISEUR_PERIODE, HORLOGE, COMPTAGE_DUREE, GENERATION_NIVEAU1 sont obligatoirement à réaliser par matériel. Les autres actions sont réalisables par logiciel. Le type de microprocesseur étant imposé par les spécifications: Motorola 68000 par exemple, il est possible de calculer le temps d'exécution maximum pour chacune des actions temporaires. Les temps suivants sont approximatifs: 410 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PLUS MOINS MARCHE ARRET Gestion dialogue

VROTATION

ORDRE

Gestion centrifugeur M/A CROTATION ETAT EROTATION Diviseur période
Hpériode Diviseur

Commande_vitesse

HB Horloge INC CV Comptage durée nbH Calcul vitesse Vmoteur Asservissement vitesse Génération niveau 1 SPWM H VCONSIGNE HB HPERIODE

-Figure 19.19- Structure fonctionnelle complète pour le centrifugeur. Temps DIVISEUR < 20 µs Temps ASSER_VITESSE < 100 µs Temps COMMANDE_VITESSE < 100 µs Temps CALCUL_VITESSE < 100 µs On peut ainsi s'assurer que toutes les contraintes de temps seront satisfaites même dans le cas le plus défavorable pour une implantation sur un seul microprocesseur: Tocc = 0,020/1 + (0,1+0,1)/5 + 0,1/0,2 = 0,56. Un contour en pointillé sur la structure fonctionnelle permet de délimiter les 2 parties: matérielle et logicielle. La partie centrale logicielle (figure 19.19) représente le rôle attribué au microprocesseur. La partie matérielle représente les interfaces entre le microprocesseur et l’environnement du système. 19.6.3. Exemple 2 : automatisation par chariot filoguidé La structure fonctionnelle complète, synthèse de l’introduction des interfaces et après réduction des générateurs d’événement, est représentée figure 19.20. M.C.S.E 411

Partie 5 - DEFINITION DE LA REALISATION

RxD Récepteur

E_CAR

S_CAR

Récep- ORDRE tion ordre Fin_T T

CR Supervision

TxD Emetteur

Emission CR
C_SIRENE

Sirène Tempo obstacle position_quai AC1 MUX AC2
AC EOC DCA

M/A ETAT C_TAPIS_MARCHE C_TAPIS_SENS

PAS Mémorisation
VCAN

CAN

Coordination PAS VC1 VC2 CVM2 CVM2 Asservissement
VM1

INC_VM2

HCAN

No_Voie
VM2 Evaluation vitesse

INC_VM1 Diviseur

T Evolution temps

CNA CVM1 CVM1

vitesse 1

H Horloge

-Figure 19.20- Structure fonctionnelle complète pour le chariot. On fait tout d'abord le bilan des fréquences et temps d'exécution probables dans le cas d'une implantation logicielle. Tinc = 5,3 ms TH = 260 µs Tpas < 15 ms ⇒ 10 ms THcan = 5 ms Teoc = 5 ms Treçu = 4 ms (pour ORDRE) Teval_vitesse = 500 µs Tevolution_temps = 50 µs Tcoordination < 200 µs Tasservissement < 200 µs Tmemorisation = 50 µs Ttempo = 50 µs

Si on exclut SUPERVISION qui est une action sans contrainte, le taux d'occupation d'un processeur 8 bits est très approximativement : Toccmax < 0,5/5,3+2*50/260 +(0,2+0,2)/10 +2*0,05/5 = 0,32 Ainsi toutes les actions sont implantables en logiciel sur un seul microprocesseur, en dehors des fonctions: gestion de la liaison série à réaliser par un transmetteur-récepteur série, l’ensemble multiplexeur et convertisseur A.N. 19.7. SCHEMA D’IMPLANTATION LOGICIELLE POUR CHAQUE PROCESSEUR La phase précédente a permis de décider les sous-ensembles de la structure fonctionnelle complète à implanter sur chaque processeur programmable. L'implantation logicielle définit l'organisation du logiciel pour chaque processeur. 412 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Il s’agit de décider: - des regroupements d'actions possibles de manière à constituer les tâches à implanter, - d'une priorité pour chaque tâche, - d'une technique d'implantation pour chaque relation fonctionnelle. Dans le chapitre 18 des règles ont été décrites pour le modèle d'implantation. De plus, L'objectif est de réduire la partie organisationnelle de manière à réduire la taille du logiciel et sa complexité et en conséquence le temps de développement, de test et de mise au point. La stratégie d'ordonnancement conseillée pour les tâches est d'adopter une priorité proportionnelle à la fréquence d'activation. Plus une tâche est activée fréquemment, plus a priori elle est courte, et donc plus rapidement il est souhaitable de l'achever. Pour l'implantation des relations, il est souhaitable d'utiliser le plus possible l'appel procédural, ce qui simplifie la partie organisationnelle. Cette solution n'est possible qu’entre des actions de priorité relative croissante. Les tâches activées par un événement matériel seront activées par le système d'interruption du processeur. Les actions permanentes et certaines cycliques sans contraintes de temps sont implantées comme procédures dans la tâche de fond. Lorsqu'il est souhaitable d'utiliser un exécutif temps-réel ou des services d'un système d'exploitation, les tâches sollicitent ces services par appel procédural. Pour les tâches complexes, une structure de modules permet de décrire la structuration du programme correspondant. Quelques règles de traduction ont été présentées dans le chapitre précédent (voir 18.4), il est conseillé au lecteur de revoir ces règles qui sont essentielles pour cette phase. Rappelons tout d’abord la règle principale, puis celle-ci étant supposée maitrisée, on s'intéressera plus particulièrement aux règles de transformation pour diverses structures ainsi qu'aux transformations à appliquer pour les données. La technique présentée est proche de la technique d’inversion préconisée par JACKSON (voir chapitre 7) [JACKSON-83]. 19.7.1. Traduction d’une dépendance temporelle entre deux actions La dépendance temporelle résulte d’une relation par événement ou par transfert de messages. Les deux actions concernées par la relation sont implantées en logiciel, il en sera donc de même pour la relation. La solution à retenir dépend de la priorité des deux actions: - priorité inférieure de la source : appel procédural. - priorité supérieure de la source : utilisation d’une tâche intermédiaire pour assurer l’attribution du processeur à l’action dépendante moins prioritaire. Les deux cas de solutions sont rappelés par la figure 19.21. La démarche de transformation s’applique pour chaque couple d’actions en commençant par les actions les plus prioritaires. Cette technique a pour intérêt de réduire au strict minimum la partie organisationnelle du logiciel. Cette phase est illustrée sur les 2 exemples. M.C.S.E 413

Partie 5 - DEFINITION DE LA REALISATION

EV F1 ou bien MESS (ME) F2

Prior. F2 > Prior. F1
F1 F2

Prior. F1 > Prior. F2

F2 EV ou (ME) EV ou MESS EV ou (ME)

F1

F3

-Figure 19.21- Les 2 cas d’implantation pour une dépendance logicielle. 19.7.2. Exemple 1 : contrôle en vitesse d’un centrifugeur Sur la structure fonctionnelle complète décrite en 19.6.2, le sous-ensemble central délimité par les pointillés est à implanter sur un processeur programmable. Les événements INC et HPERIODE sont nécessairement matériels puisque générés par des actions réalisées par matériel. Les actions COMMANDE_VITESSE et ASSERVISSEMENT_VITESSE sont regroupées (exécutées en séquence) pour former une seule tâche activée par DIVISEUR. Deux actions sont donc implantées sous interruption: CALCUL_VITESSE et DIVISEUR. La fonction GESTION_DIALOGUE est implantée comme tâche de fond. Elle appelle pour chaque événement ORDRE l'action GESTION_CENTRIFUGEUR implantée comme procédure. Le choix des priorités et les couplages fonctionnels sont représentés sur la figure 19.22. L'action déclenchée par l'interruption HPERIODE s'écrit ainsi:
action DIVISEUR sur événement HPERIODE; Var N,VCONSIGNE:integer; begin N:=5; cycle HPERIODE: begin N:= N-1; if N=0 then begin N:=5; COMMANDE_VITESSE(VCONSIGNE); ASSER_VITESSE(VCONSIGNE); end; end; end cycle; end DIVISEUR;

414

M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PT2 A1 M1 A2

PT3 A3 M2

PT4 A4 M3

A4

A1

M3

M1

POUSSÉ
M2

A3

A2

TIRÉ
M2

A2

A3

M1

M3

A1

A4

-Figure 19.22- Schéma pour l'implantation logicielle. Les 2 actions synchrones à DIVISEUR - Commande_Vitesse et Asser_Vitesse - sont ainsi transformées en procédures. Pour obtenir une précision correcte lors des calculs arithmétiques, les expressions ne doivent pas être calculées dans n'importe quel ordre. Le calcul: VCONSIGNE := CROTATION*T/TM doit être calculé dans l'ordre * puis /. En effet CROTATION, T et TM sont représentées en entier 16 bits. La multiplication conduit à un résultat sur 32 bits. La division à faire est alors 32 bits/16 bits, ce qui donne un résultat en 16 bits. Le résultat ainsi obtenu montre que la partie organisationnelle du logiciel est réduite à des appels de procédures et la programmation de deux tâches sous interruption. 19.7.3. Exemple 2 : automatisation du chariot filoguidé La structure fonctionnelle complète et le sous-ensemble à implanter en logiciel est représentée par la figure 19.20. Compte-tenu du nombre d'actions, il faut commencer par regrouper toutes celles activées par un même événement. Une première tâche est celle activée par H. De même pour toutes les actions activées par PAS: COORDINATION, les 2 asservissements de vitesse et Temporisation. Les événements matériels sont: H, INC_VM1, INC_VM2, EOC, RECU. Toutes les tâches associées sont activées par le système d'interruption. La synchronisation par PAS est transformée en un appel procédural. M.C.S.E 415

Partie 5 - DEFINITION DE LA REALISATION La tâche SUPERVISION est implantée comme tâche de fond. Comme l'émission se fait par message d’un seul caractère, cette action s'implante comme procédure. Evolution_temps 1 et 2, Evaluation_vitesse 1 et 2, Mémorisation sont implantées sous interruption. On peut donc retenir l'implantation suivante:
priorité
H Evolution temps 1 T1 INC_VM1 Evaluation vitesse1 T2 Evolution temps 2 Diviseur H CAN

INC_VM2

Evaluation vitesse2 VM1 VM2

Asserv. 1 EOC Reçu E_CAR Réception ORDRE Mémo- PAS risation

Asserv. 2 Coordination

Tempo.

T Emission CR

produit

ORDRE

(CR) Tâche de fond : Supervision

S_CAR

-Figure 19.23- Schéma pour l'implantation logicielle. Il est aussi possible d'implanter réception comme procédure non-bloquante. Dans ce cas, appelée périodiquement par SUPERVISION, elle teste si un caractère existe. Si oui, l'action correspondante au message reçu est entreprise, sinonSUPERVISION poursuit son activité. 19.7.4. Implantation d’une séquence d’actions Supposons des actions couplées par des ports pour le transfert de messages. La séquence est supposée tout d'abord sans boucle. Deux stratégies d'implantation opposées sont possibles: la technique du poussé ou la technique du tiré. Elles sont illustrées par la figure 19.24. Pour la première implantation, A1 joue le rôle du moniteur, l'ensemble se comporte comme une seule action qui traite en séquence chaque production issue de A1. Pour la deuxième implantation, A4 joue le rôle du moniteur en sollicitant un message à A3 et ainsi de suite jusqu'à A1. La première solution est plus appropriée lorsque le système est sollicité par ses entrées (prise en compte par A1 d'un événement ou d'un message). Le système est alors en position d'esclave vis à vis de l'environnement. C'est le cas des applications temps-réel et des applications transactionnelles (fonctionnement en ligne). La deuxième solution est plus appropriée lorsque le système est sollicité par ses sorties (demande d'informations). Le système est alors producteur et donc en situation de maître. Il s'agit plus d'un fonctionnement du type "BATCH". 416 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PT2 A1 M1 A2

PT3 A3 M2

PT4 A4 M3

A4

A1

M3

M1

POUSSÉ
M2

A3

A2

TIRÉ
M2

A2

A3

M1

M3

A1

A4

-Figure 19.24- 2 implantations opposées pour une séquence. 19.7.5. Implantation d’une séquence bouclée d’actions Supposons maintenant le cas d'une structure fonctionnelle possédant un bouclage (voir figure 19.25). Aucune des 2 techniques précédentes n’est directement utilisable. Il faut tout d'abord rompre la boucle ce qui s'obtient en conservant obligatoirement un buffer tampon dans la boucle. Soit PT0 le port servant de buffer. On peut ensuite appliquer la technique du poussé ou du tiré. Dans les deux cas, A1 est décideur de l'entrée à prendre en compte entre PT0 et PT1. 19.7.6. Implantation de plusieurs séquences d’actions Supposons l'exemple suivant composé de 3 séquences: 1 séquence principale, une séquence de convergence, une séquence de divergence (voir figure 19.26). Le lien de A5 vers A2 est similaire au retour de A3 sur A1 de l'exemple précédent. Il en est de même pour le lien de A3 vers A6. Ainsi, un buffer est nécessaire entre les couples de séquences. Pour la première solution, A2 joue le rôle du moniteur décidant ainsi de la donnée à prendre entre PT1 et PT5. Ce rôle de moniteur est joué par A4 pour la deuxième solution. M.C.S.E 417

Partie 5 - DEFINITION DE LA REALISATION

PT1 PT2 A1 M1 PT0 M3 A2 M2 PT3 A3

PT4

PT1 A3 A1

M2 M3 A2 PT0 M1 PT1 A1

M1 M3

POUSSÉ

TIRÉ

A2 PT0 M2

A3

-Figure 19.25- Implantation selon les 2 techniques pour une séquence bouclée.

PT1 PT2 A1 M1 PT5 M5 A5 PT7 M7 A2 M2 A3

PT3 M3 PT6 M6 PT8 M8 A6 A4

PT1 A4 M1 M3 M2 PT6 A3 M6 M2 PT1 A2 M1 M5 PT5 A4 M3 A2

PT5

M7

POUSSÉ

TIRÉ
A3

PT6

M6

-Figure 19.26- Exemple de plusieurs séquences d'actions et solutions. 418 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION 19.7.7. Capacité des ports Les ports sont supposés de capacité illimitée pour la description fonctionnelle. Cette hypothèse n'est plus réaliste avec un support matériel. Il faut donc déterminer la capacité des buffers nécessaire pour l'implantation. Cette détermination se fait sur la base des vitesses relatives des actions. Un buffer peut être conservé pour satisfaire des arrivées par paquets (burst). La capacité maximale pour chaque buffer se déduit alors des spécifications de l'application et des performances en exécution. Dans certaines situations, la capacité reste importante ce qui peut ne pas être convenable pour l'implantation. Dans ce type de cas, il est possible d'obtenir un fonctionnement correct avec un buffer de capacité limitée à condition de pouvoir ralentir le producteur. Il faut alors implanter un mécanisme d'asservissement du producteur par le consommateur. La technique consiste à contrôler le producteur par un événement ou une variable d'état positionnée par le consommateur. La figure suivante présente deux solutions.

Pt

Producteur

Consommateur

1 place

n places

Bpt Dépôt V_pt Prod. Cons. Prod. Cons.

Consommé

XON/XOFF

-Figure 19.27- Implantation avec asservissement consommateur—>producteur. Pour la première solution, le producteur ne dépose un nouveau message dans V_Pt qu’après réception de l’événement consommé qui concerne le message précédent. Cet événement peut aussi se transformer en une variable logique. Pour la deuxième solution, la variable XON/ XOFF est modifiée par le consommateur en fonction du nombre de places occupées dans la boîte à lettres B_Pt. La technique de transmission selon le protocole XON/XOFF découle de cette spécification. 19.7.8. Utilisation des services d’un processeur Un processeur peut mettre à disposition de l'application des services qui permettent de réduire le développement. C'est le cas par exemple d'un processeur disposant d'un système d'exploitation. La technique est alors similaire à celle développée pour l'utilisation d'un exécutif tempsréel. Les services sont considérés, regroupés ou non, comme des procédures de priorité élevée par rapport aux tâches de l'application. Ces services peuvent eux-mêmes être gérés par un exécutif chargé du partage du processeur. M.C.S.E 419

Partie 5 - DEFINITION DE LA REALISATION L'exemple suivant montre l’utilisation en entrée d’un clavier et en sortie d’un écran pour l'affichage des données. Le système utilisé met à disposition les procédures Read(car) et Write(Mess).
CLAVIER Gestion Clavier Car A MESS Affichage ECRAN

Services disponibles Mess

Read

Car A

Write

-Figure 19.28- Implantation utilisant les services de gestion des E/S d'un système. Pour cette implantation, le service de gestion du clavier ne restitue le processeur à A que lorsqu'un caractère a été lu. Pour l'écriture, la restitution du processeur à A dépend de l'implantation du service: avec ou sans buffer. 19.7.9. Implantation de modules Pour une tâche complexe, une structuration selon une hiérarchie de modules peut s'avérer nécessaire. La méthode à employer "Structured Design" (voir 7.4) est bien connue et décrite dans beaucoup d'ouvrages: DEMARCO, JONES, YOURDON et CONSTANTINE, WARD et MELLOR, MARTIN et MC CLURE... Plutôt que de décrire cette méthode en détail, il est souhaitable que le concepteur se réfère à ces ouvrages. On se contente simplement de rappeler l'idée essentielle qui doit guider le concepteur. Une structure de modules s'obtient à partir d'une spécification exprimée par un diagramme flots de données. La première phase consiste à trouver le premier niveau de la décomposition: le module principal, les modules appelés. Cette déduction s'effectue en identifiant sur le diagramme flot de données les 3 parties: les entrées, la transformation centrale, les sorties. Ceci permet de positionner 2 interfaces de manière à minimiser les couplages entre parties. Cette démarche est réutilisable pour chaque niveau inférieur. La technique est illustrée par l'exemple ci-après.

O1 A O3 B O2 O1 C D O4 A

Séquenceur B

A et B

C C O3 O4

O2

-Figure 19.29- Exemple de transformation pour obtenir une structure de Modules. 420 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION L'exemple montre qu'un module est utilisé comme moniteur pour assurer l'enchaînement des activités. 19.8. IMPLANTATION DES DONNEES Des données servent à assurer: des couplages entre tâches, la mémorisation d'informations pour l'application. La description fonctionnelle contient une description des données nécessaires. Elles sont modélisées sous la forme de données individualitées ou de collections de données. Chaque variable est décrite par une structure de données dont la taille peut aussi bien être petite ou complexe, statique ou dynamique. Des relations entre données sont aussi exprimables par des références vers ces données. Le modèle de description retenu pour le niveau fonctionnel se voulait indépendant de l'implantation. L'objet de ce paragraphe est de montrer les transformations de structure à rechercher pour favoriser l'implantation des données. Il s'agit donc de passer d'une description logique à une description physique. 19.8.1. Critères pour l’implantation des données Deux objectifs peuvent être considérés comme importants pour l'implantation des données: - l'indépendance, - l'efficacité.
-A- INDEPENDANCE

Considérons une donnée partagée utilisée par plusieurs tâches pour un même processeur.
Partie dépendante de D
D A1 A2 Accès par A1 Accès par A2 D

Encapsulation

-Figure 19.30- Dépendance - indépendance vis à vis de D. Si l’implantation est la simple traduction de la structure fonctionnelle, 3 critiques essentielles sont à prendre en compte [WARD-85]: - absence de protection: la donnée D est globalement accessible par les actions liées. Des erreurs sont facilement possibles. - dépendance des actions: toute modification de la définition de D implique des modifications pour toutes les actions liées. - mécanisme d'accès spécifique pour chaque action: une technique d'accès est développée pour chacune, ce qui augmente l'effort de développement. Bien entendu ces remarques sont particulièrement valables pour des données D structurées et complexes. M.C.S.E 421

Partie 5 - DEFINITION DE LA REALISATION Pour remédier à ces inconvénients, l'objectif est d'aboutir à une implantation des tâches et des modules indépendante des données. Ce résultat s'obtient en plaçant autour de la donnée D une couche logicielle assurant l'encapsulation de celle-ci. Cette couche offre aux tâches les accès nécessaires sous la forme de services. L'indépendance implique aussi que la position d'une information dans la donnée D ne soit connue qu'à l'instant de la sollicitation, ce qui est une contrainte plus difficile à satisfaire.
-B- EFFICACITE

L'efficacité est une condition souvent nécessaire pour les systèmes temps-réel. Elle s'obtient en disposant de mécanismes d'accès aux données les plus directs. C'est le cas lorsque pour un accès donné, la position d'une information dans la donnée D est connue. Ainsi, les deux objectifs, indépendance et efficacité, s'avèrent donc contradictoires. L'implantation a pour but de décider du meilleur compromis entre ces 2 aspects de manière à satisfaire au mieux les spécifications et ceci, en proposant une structure interne et les mécanismes d'accès nécessaires. 19.8.2. Implantation pour des données structurées Se référant au modèle fonctionnel pour les données, une entité structurée est construite sur la base de 3 structures. A chaque cas correspond une technique d'implantation. - la composition: toutes les données qui composent cette structure sont implantées dans une zone contigü. - la sélection: tous les types de données sont implantés dans une même zone, s'y ajoute le type de la donnée courante. - l'ensemble: cette donnée est de taille variable. Dans le cas général, la solution est une implantation en file avec un mécanisme d'accès à chaque élément. Lorsque