Vous êtes sur la page 1sur 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

PolytechNantes 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 systmes lectroniques". Lauteur 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 lIRESTE de NANTES, Professeur IRESTE NANTES, Professeur Facult des Sciences & Technologies UNIVERSIDAD NOVA, LISBONNE, Professeur ETSII Universit dOVIEDO, Directeur MATRA MHS NANTES, Ingnieur Socit ERNITEC, COPENHAGUE, Directeur financier Socit SFERE, PARIS, Ingnieur Socit EID, LISBONNE, Directeur Socit SRI, OVIEDO,

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

NOTA Lauteur a crit un second ouvrage dans la mme collection intitul : "Spcification et conception des systmes. Des tudes de cas". 270 p. Cet ouvrage est un recueil de 13 problmes avec pour chacun une description complte 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 systme quil dsire par analogie avec un des problmes proposs. Ce livre est un complment indispensable au prsent ouvrage. Le prsent 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

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 DUNE 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 LINFORMATIQUE INDUSTRIELLE 2.3. LES SYSTEMES DEDIES 2.4. LES SYSTEMES TEMPS-REEL 2.5. QUALITES DUN SYSTEME 2.6. CATEGORIES DE SYSTEMES 13 14 16 16 18 18

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME


3.1. CONTEXTE DUN DEVELOPPEMENT 3.2. LES PHASES DUN DEVELOPPEMENT 3.3. MODELES DE CYCLE DE VIE 3.3.1. Le Modle "Waterfall" 3.3.2. Le cycle en V 3.3.3. Le Modle "Spirale" 3.3.4. Le modle "Contractuel" 3.4. QUELQUES CONSTATATIONS 3.4.1. Recouvrement des phases 3.4.2. Cot de correction des erreurs 3.4.3. Facteurs de Productivit 3.4.4. Rpartition de l'effort 22 24 26 26 27 28 29 30 30 31 31 32

M.C.S.E

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. Problme: dfinition, rsolution 4.1.2. Modle et modlisation 4.1.3. Mthode et mthodologie 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 DUNE METHODOLOGIE 4.3.1. Modle de description 4.3.2. Mthode et technique pour chaque tape 4.3.3. Modles 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 Modle fonctionnel 5.2.2. Le modle comportemental 5.2.3. Le modle excutif 5.2.4. Intrt de cette modlisation 5.3. LA DEMARCHE 5.3.1. Elaboration des spcifications 5.3.2. Conception fonctionnelle 5.3.3. Dfinition de la ralisation 5.3.4. Ralisation 5.4. CARACTERISTIQUES DE MCSE 45 47 49 50 51 52 53 54 55 55 56 56

Ch 6 - UN EXEMPLE DILLUSTRATION
6.1. CAHIER DES CHARGES 6.1.1. Contrle du rgime de croisire 6.1.2. Suivi de la vitesse moyenne 6.1.3. Suivi de la consommation de carburant 6.1.4. Maintenance 6.1.5. Caractristiques complmentaires 6.2. SPECIFICATIONS 6.2.1. Modlisation de l'environnement 6.2.2. Spcifications fonctionnelles 6.2.3. Spcifications opratoires et technologiques 6.3. CONCEPTION FONCTIONNELLE 6.3.1. Dlimitation du systme 6.3.2. Premire structure fonctionnelle 6.3.3. Raffinement 6.3.4. Comportement de contrle vitesse 6.3.5. Comportement de supervision 6.3.6. Comportement de maintenance 6.3.7. Comportement de gnration_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. Rpartition matriel/logiciel 6.4.4. Spcification de l'implantation logicielle 6.4.5. Spcification de la ralisation matrielle 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 modle 7.2.2. La mthode 7.3. STRUCTURED ANALYSIS 7.3.1. Le modle 7.3.2. La mthode 7.4. STRUCTURED DESIGN 7.4.1. Le modle 7.4.2. La mthode 7.4.3. Remarques 7.5. METHODOLOGIE DE JACKSON (JSD) 7.5.1. Les modles 7.5.2. La dmarche 7.5.3. Remarques 7.6. SREM 7.6.1. Le modle 7.6.2. La mthode SREM pour la spcification 7.6.3. La mthode SYSREM pour la conception 7.6.4. Remarques 7.7. METHODOLOGIE DE WARD ET MELLOR (SDRTS OU RTSA) 7.7.1. Le modle 7.7.2. La dmarche 7.8. METHODOLOGIE de HATLEY et PIRBHAI 7.8.1. Le modle 7.8.2. La dmarche 7.9. METHODOLOGIE DE LAVI ET HAREL (STATEMATE COMME OUTIL) 7.9.1. Le modle ECS (Embedded Computer Systems) 7.9.2. La dmarche 7.9.3. Remarques 7.10. DARTS (DESIGN APPROACH FOR REAL-TIME SYSTEMS) 7.10.1. Le modle pour DARTS 7.10.2. La dmarche 7.11. CONCEPTION ORIENTEE OBJET (O.O.D) 7.11.1. Le modle objet 7.11.2. Dmarche pour la conception 7.12. SYSTEM DESIGN WITH MACHINE CHARTS 7.12.1. Le modle 7.12.2. La mthode 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. Modles 7.13.2. Dmarche 7.13.3. Remarques 7.14. BILAN 137 137 138 138 139

Ch 8 - PANORAMA DES MODELES


8.1. BASES POUR LANALYSE DES MODELES 8.1.1. Qualits des modles 8.1.2. Classification des modles 8.1.3. Modles analytiques 8.1.4. Modles conceptuels 8.2. OBJECTIFS DES MODELES POUR LES SYSTEMES 8.2.1. Modlisation pour les spcifications 8.2.2. Modlisation en conception 8.3. PANORAMA DES MODELES 8.3.1. Modle pour les activits 8.3.2. Modles pour les donnes 8.3.3. Modles pour les fonctions 8.3.4. Modles 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 DUN 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. Systme de contrle 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 DUNE SPECIFICATION


10.1. ROLE D'UNE SPECIFICATION 10.1.1. Distance entre client et concepteur 10.1.2. Diversit des partenaires ct client 10.1.3. Importance d'une vrification 10.1.4. Une spcification comme document formel vrifiable 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 DUNE ENTITE 11.3.1. Nature d'une entit 11.3.2. Nature des lments caractristiques 11.3.3. Dpendance entre lments caractristiques 11.3.4. Nature des entres et des sorties 11.4. TROIS VUES POUR LA DESCRIPTION DUNE ENTITE 11.5. MODELISATION PAR LES DONNEES/INFORMATIONS 11.5.1. Modlisation selon 2 niveaux 11.5.2. Modle pour la description des entits donne 11.5.3. Modle pour la description des relations 11.5.4. Modlisation par les donnes 11.6. MODELISATION PAR LE COMPORTEMENT 11.6.1. Les diffrents modles tats discrets 11.6.2. Modlisation par les tats 11.6.3. Modlisation stimuli/rponse 11.6.4. Rgles prconises pour le modle 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. Modlisation 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 DUN CENTRIFUGEUR 12.6. SPECIFICATIONS FONCTIONNELLES 12.6.1. Nature des spcifications fonctionnelles 12.6.2. Approches pour laborer une spcification fonctionnelle 12.6.3. Mthode pour laborer les spcifications fonctionnelles 12.6.4. Exemples 12.7. SPECIFICATIONS OPERATOIRES 12.8. SPECIFICATIONS TECHNOLOGIQUES 12.9. PROCEDURES DINSTALLATION ET DEXPLOITATION 12.10. EXEMPLE 2: AUTOMATISATION PAR CHARIOT FILOGUIDE 12.10.1. Modlisation de l'environnement 12.10.2. Spcifications du systme 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

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. Reprsentation graphique 13.2.2. Cohrence et lisibilit d'une S.F. 13.2.3. Interprtation d'une S.F. 13.2.4. Raffinement et abstraction d'une S.F. 13.2.5. Dcomposition maximale: fonctions lmentaires ou actions 13.2.6. Rgles de comportement pour une fonction lmentaire 13.2.7. Proprits d'une structure fonctionnelle 13.3. SPECIFICATION DES FONCTIONS ELEMENTAIRES 13.3.1. Objectifs de la spcification 13.3.2. Choix du langage de description 13.3.3. Le modle de description 13.3.4. Interprtation du modle 13.4. SPECIFICATION DES DONNEES 13.4.1. Objectifs de la spcification des donnes 13.4.2. Modle de description 13.4.3. Catgories de donnes: les structures 13.4.4. Dcomposition d'une donne: minimisation et normalisation 13.4.5. Utilisation des donnes 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'interfaage avec l'environnement physique 14.2.2. Fonctions de dialogue homme/machine 14.2.3. Rpartition gographique 14.2.4. Maintenance, sret de fonctionnement 14.2.5. Importance des catgories de spcification 14.3. COMPLEXITE MINIMALE ET INDEPENDANCE 14.3.1. Orthogonalit ou cohrence des fonctions 14.3.2. Rduction des couplages 14.4. DEMARCHE POUR LA DEDUCTION D'UNE SOLUTION 14.4.1. Analyse plutt qu'intuition 14.4.2. Approche par les donnes plutt que par les fonctions 14.4.3. Raffinement plutt 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 spcification 15.2.2. Document de conception 15.3. DELIMITATION DES ENTREES ET SORTIES 15.3.1. Dmarche 15.3.2. Exemple 1: Contrle 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 DUNE PREMIERE DECOMPOSITION FONCTIONNELLE 15.4.1. Importance de la premire dcomposition fonctionnelle 15.4.2. Dmarche pour laborer une solution 15.4.3. Exemple 1: contrle en vitesse dun centrifugeur 15.4.4. Exemple 2: Automatisation par chariot filoguid 15.5. RAFFINEMENT FONCTIONNEL 15.5.1. Critre d'arrt pour le raffinement 15.5.2. Droulement du raffinement 15.5.3. Exemple 1: contrle en vitesse dun centrifugeur 15.5.4. Exemple 2: Automatisation par chariot filoguid 15.6. COMPORTEMENT DES FONCTIONS ELEMENTAIRES 15.6.1. Mthode pour l'obtention d'une description algorithmique 15.6.2. Exemple 1: Contrle en vitesse dun centrifugeur 15.6.3. Exemple 2: Automatisation par chariot filoguid 15.7. DESCRIPTION DES DONNEES 15.7.1. Mthode pour dcrire les donnes 15.7.2. Illustration par un exemple 15.8. CRITERES D'EVALUATION DUNE SOLUTION 15.8.1. Analyse du couplage 15.8.2. Analyse de la cohrence 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 modle 16.2.3. La mthode 16.2.4. Exemple 16.3. MODELE SUPERVISION/CONTROLE-COMMANDE 16.3.1. Principe 16.3.2. Le modle 16.3.3. La mthode 16.3.4. Exemples 16.4. MODELE CLIENT/SERVEUR 16.4.1. Principe 16.4.2. Le modle 16.4.3. La mthode 16.4.4. Exemple: transmission de message par liaison srie 16.5. MODELE D'INTERACTIVITE 16.5.1. Principe 16.5.2. Le modle 16.5.3. La mthode 16.5.4. Exemple 16.5.5. Gnralisation du modle au cas multi-fentres 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 DEXECUTION
17.1. CARACTERISTIQUES DU MODELE DEXECUTION 17.1.1. Le modle d'excution et ses constituants 17.1.2. Signification des lments et des relations 17.2. LE MODELE DE STRUCTURE D'EXECUTION 17.2.1. Reprsentation graphique 17.2.2. Interprtation d'une S.E 17.2.3. Raffinement et abstraction d'une structure d'excution. 17.3. SPECIFICATION DES CONSTITUANTS POUR LA REALISATION 17.3.1. Spcification d'un processeur 17.3.2. Spcification d'une mmoire 17.3.3. Spcification d'un noeud de communication 17.4. PROPRIETES DU MODELE DEXECUTION 17.5. RESUME 352 352 353 355 355 357 358 359 360 360 360 361 362

Ch 18 - LE MODELE DINTEGRATION
18.1. LE MODELE D'INTEGRATION ET SES CONSTITUANTS 18.2. LE MODELE D'ALLOCATION 18.2.1. Correspondance entre les lments des 2 structures 18.2.2. Contraintes pour une allocation 18.3. LE MODELE D'IMPLANTATION POUR CHAQUE PROCESSEUR 18.3.1. Implantation des tches 18.3.2. Implantation de chaque tche 18.3.3. Spcification de chaque lment 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION 18.4.1. Correspondance: Fonctions > Tches 18.4.2. Traduction des relations par partage de variables 18.4.3. Traduction des synchronisations par vnement 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-rel 18.5.2. Implantation avec un excutif temps-rel 18.5.3. Critres 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. Spcifications matrielles 19.1.2. Contraintes de temps 19.1.3. Rduction du cot de dveloppement 19.1.4. Rduction de la partie organisationnelle 19.1.5. Rgles 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. Modle pour lintroduction des interfaces 19.4.2. Introduction des interfaces physiques 19.4.3. Introduction des interfaces homme-machine 19.4.4. Exemple 1 : contrle en vitesse dun 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 DEXECUTION 19.5.1. Evaluation des contraintes de temps 19.5.2. Techniques pour dduire une structure dexcution 19.6. DETERMINATION DE LA STRUCTURE D'EXECUTION 19.6.1. Choix de la rpartition matriel / logiciel 19.6.2. Exemple 1 : contrle en vitesse dun centrifugeur 19.6.3. Exemple 2 : automatisation par chariot filoguid 19.7. SCHEMA D'IMPLANTATION LOGICIELLE POUR CHAQUE PROCESSEUR 19.7.1. Traduction dune dpendance temporelle entre deux actions 19.7.2. Exemple 1 : contrle en vitesse dun centrifugeur 19.7.3. Exemple 2 : automatisation du chariot filoguid 19.7.4. Implantation dune squence dactions 19.7.5. Implantation dune squence boucle dactions 19.7.6. Implantation de plusieurs squences dactions 19.7.7. Capacit des ports 19.7.8. Utilisation des services dun processeur 19.7.9. Implantation de modules 19.8. IMPLANTATION DES DONNEES 19.8.1. Critres pour limplantation des donnes 19.8.2. Implantation pour des donnes structures 19.8.3. Implantation pour des collections et des relations 19.9. SPECIFICATION DE LA REALISATION MATERIELLE 19.9.1. Exemple 1 : contrle en vitesse dun 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. Caractrisation de l'tape de Ralisation 20.1.2. Varit des mthodes et moyens en ralisation 20.1.3. Importance en dure de l'tape de Ralisation 20.2. DEMARCHE POUR LA REALISATION 20.3. VERIFICATION ET ACCEPTATION DES SPECIFICATIONS 20.4. REALISATION MATERIELLE 20.4.1. Dmarche 20.4.2. Les outils 20.4.3. Rgles respecter 20.5. REALISATION LOGICIELLE 20.5.1. Dmarche 20.5.2. Les outils 20.5.3. Rgles 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 ralisation matrielle 20.8.2. Raffinement en ralisation 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. Ralisation avec des composants existants 21.2.2. Dveloppement de composants spcifiques 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 modle 21.6.3. mthode 21.7. LE MODELE COMMANDE/EXECUTION 21.7.1. Principe 21.7.2. Modle 21.7.3. Mthode 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 fonctionnalits 22.1.2. Dmarches 22.2. REUTILISATION POUR LE LOGICIEL 22.3. PRINCIPES DE REALISATION 22.3.1. Qualits 22.3.2. Caractristiques 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 mcanisme de rendez-vous 22.7.2. Implantation des relations du modle fonctionnel 22.7.3. Interruptions et exceptions 22.8. UTILISATION DU LANGAGE OCCAM ET DU TRANSPUTER 22.8.1. Le mcanisme d'change par canal 22.8.2. Implantation des relations du modle fonctionnel 22.9. SERVICES POUR LE MODELE FONCTIONNEL 22.10. REALISATION ORIENTEE OBJET 22.10.1. Catgories d'objets 22.10.2. MCSE et la conception oriente 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. Modlisation d'une tape de dveloppement 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 DUN PROJET


24.1. CONTRAINTES DE DEROULEMENT POUR CHAQUE ETAPE 24.1.1. Etape de spcification 24.1.2. Etape de conception 24.1.3. Etape de dfinition de la ralisation 24.1.4. Etape de ralisation 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 DUN 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/modlisation 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. Dmarche pour le test 25.7. TECHNIQUES POUR L'INTEGRATION 25.7.1. Assemblage par phase 25.7.2. Assemblage incrmental 25.7.3. Tests orients OBJECTIFS 25.7.4. Remarques sur ces dmarches 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 Gnrale 25.12.2. Plan 25.12.3. Spcification 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 dvelopp 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. Mthode de contrle 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 activits 26.6.2. Rgles 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 DUN PROJET


27.1. JUSTIFICATION FONCTIONNELLE 27.2. STRUCTURATION DES DOCUMENTS 27.2.1. Hirarchie des documents 27.2.2. Documents prliminaires 27.2.3. Documents de contrle 27.2.4. Documents de spcification, de conception, de ralisation, 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. Problmes et causes 27.4.2. Niveaux de qualit de la documentation 27.4.3. Procdures 27.5. GUIDE POUR LA REDACTION DES DOCUMENTS 27.5.1. Dfauts d'un document 27.5.2. Principes pour la rdaction 27.5.3. Rdaction 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 DUTILISATION 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. Vrification, 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 DUN 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 LORGANISATION 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 mthodologie reprsente un travail de longue haleine. Seul et sans terrain d'exprimentation, je ne pouvais faire aboutir un tel projet. Je tiens remercier trs chaleureusement mes collgues qui ont contribu efficacement ds le dbut ce travail en accceptant la fois la responsabilit de projets pour des industriels et lexprimentation de la Mthodologie. Il s'agit tout particulirement de Pascal CLODIC, Grard DUCHENE, Jocelyn FRAPPIER, Eric FRIOT, Grard THIBAUT. Je remercie aussi tous les tudiants et auditeurs qui ont suivi en une occasion ou une autre, la formation la Mthodologie. Je citerai tout d'abord les tudiants du DESS "Conception et Mise en oeuvre des Systmes Electroniques". Quatre ans durant, exploitant la mthodologie pour des projets industriels durant leur stage, ils m'ont permis de disposer d'une base exprimentale. Les contacts fructueux que j'entretiens toujours avec un certain nombre d'entre eux, qui dans leur mtier d'ingnieur utilisent cette Mthodologie et arrivent l'imposer comme dmarche de travail dans leurs entreprises, sont significatifs d'une reconnaissance de l'effort pdagogique entrepris durant cette formation. Ensuite, la Conception des Systmes fait partie intgrante du programme de la Formation d'Ingnieur IRESTE en Systmes Electroniques et Informatique Industrielle. Les tudiants durant leur dernire anne, ayant raliser un projet industriel de 6 mois en entreprise, prennent conscience de la vraie dimension de cet enseignement et de son intrt essentiel pour la comptitivit de nos entreprises. Ils disposent ainsi d'un atout majeur qui rpond aux proccupations actuelles et long terme des industriels. Je remercie aussi toutes les socits qui ont fait confiance l'quipe et aux ingnieurs qui ont trouv par la Mthodologie une nouvelle dynamique en dveloppement de systmes. Je ne saurais oublier la lourde tche de frappe que constituent la saisie et la mise en forme d'un tel document. Je remercie trs vivement Marie-Thrse SALOUX qui a assur avec qualit et efficacit le travail de saisie, Olivier DEBON et Franck BERTAUD qui ont ralis les figures et la mise en page.

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

PARTIE

PRESENTATION DE LA METHODOLOGIE

Cette premire partie introduit MCSE comme Mthodologie pour la Conception des Systmes Electroniques, en prsentant la classe des applications concernes, les objectifs viss et les principes essentiels. Le chapitre 1 fixe lobjectif global du document. Sadressant aux concepteurs de systmes et aux spcialistes de lInformatique Industrielle, la mthodologie propose est un outil de travail amliorant la productivit et la qualit en dveloppement de projets. Le chapitre 2 dlimite le champ des applications concernes par MCSE. Pour ces applications, les systmes dits temps-rel sont dfinis par leurs caractristiques. On y voque aussi les techniques mises en oeuvre et les comptences ncessaires. Le chapitre 3 prsente le cycle de vie pour le dveloppement de tout produit. Utile pour introduire les diffrentes phases, le modle de cycle de vie permet de montrer la nature itrative du processus de dveloppement et le domaine couvert par MCSE. Le chapitre 4 explicite les bases sur lesquelles reposent en gnral les mthodologies. Le dcoupage en tapes et la ncessit de modles de description y sont notamment justifis. Le chapitre 5 permet au lecteur d'avoir une vue globale de la mthodologie MCSE incluant les modles et la dmarche. Lors du chapitre 6, la dmarche est introduite sur un exemple simple mais suffisamment raliste pour que le lecteur puisse se faire une ide prcise de la mthodologie , en ayant une vue synthtique des diffrentes tapes.

M.C.S.E

Chapitre 1

INTRODUCTION

Cet ouvrage dcrit une mthodologie appele MCSE pour la Spcification, la Conception et la Ralisation des Systmes en Informatique Industrielle. Les systmes viss intgrent la fois les techniques de l'Electronique et de l'Informatique, et concernent des applications varies quant au domaine et la complexit. Comme exemples, parmi tant d'autres, citons: un systme de commande d'un centrifugeur, la gestion technique centralise d'un grand btiment, la gestion automatique d'un magasin incluant des chariots filoguids, la surveillance des chanes d'ancrage pour plateformes ptrolires. De tels types d'exemples correspondent au domaine de l'Informatique Industrielle. Il s'agit de systmes temps-rel pour des applications ddies: ceci veut dire que le dveloppement se fait spcifiquement pour chaque application, et qu'il doit conduire directement un produit industriel oprationnel respectant la fois les spcifications du client, les cots et dlais prvus. Une mthodologie peut tre vue comme une bote outils dans laquelle le concepteur trouve une varit d'outils: - modles, mthodes, solutions - pour mener bien son travail. Les activits concernes par la Mthodologie MCSE sont toutes celles qui permettent de passer du cahier des charges d'un produit, d'un systme ou d'une application, la dfinition complte de sa ralisation. Ces activits sont structures en 3 tapes: laboration des spcifications, conception fonctionnelle, dfinition de la ralisation. Pour introduire l'apport de cet ouvrage, voquons les objectifs de tout dveloppement puis les difficults de cette activit. Une mthodologie est une rponse cette problmatique.

M.C.S.E

Partie 1 - PRESENTATION DE LA METHODOLOGIE 1.1. LES OBJECTIFS POUR UN DEVELOPPEMENT Nous nous plaons ici dans le cas normal d'un dveloppement de systmes pour un client. Une situation diffrente, consiste dvelopper 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 comptence technique pour traiter le problme, plusieurs points essentiels: - de satisfaire le besoin du demandeur: ceci est un point fondamental. Le demandeur est le client et donc finance contractuellement le dveloppement. Un produit jug satisfaisant par le concepteur peut ne pas rpondre lattente du demandeur. - de respecter des dlais et des cots. Normalement un dveloppement fait l'objet d'un contrat ngoci sur la base de propositions incluant des dlais et des cots. Sur cette base, le client dfinit une stratgie dentreprise, par exemple vente ou intgration dans une gamme. Un non-respect du dlai ou des cots engendre des dpenses supplmentaires ou une perte de parts du march, ainsi qu'une perte de crdibilit pour l'quipe de dveloppement. - de satisfaire des critres de qualit. Au-del du bon fonctionnement bien entendu ncessaire, les principaux critres concernent: la robustesse du produit (fiabilit, tolrance aux pannes), la lisibilit, qui concerne la comprhension du dveloppement la fois des documents et du produit, la maintenabilit de manire corriger les dfauts rsiduels et pouvoir faire voluer les caractristiques du systme. Ainsi la QUALITE dans les systmes a des rpercussions sur le cot global de toutes les oprations 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 procder pour aboutir une ralisation spcifique en tat de fonctionnement et rpondant toutes les caractristiques demandes cites ci-dessus. Il est ais de constater la complexit du travail des concepteurs de systmes. Une triple complexit existe: la premire est due la diversit des techniques et moyens mettre en oeuvre, la deuxime est lie la distance entre le domaine du problme et celui de la technique mise en oeuvre, la troisime est en rapport avec lventail des complexits et tailles des applications. Tout d'abord, il faut matriser les constituants de la ralisation; or le domaine des techniques est tendu: lectronique analogique, lectronique numrique et composants VLSI, informatique et programmation, problmes d'industrialisation... Comme les techniques voluent et se diversifient trs rapidement, un effort important doit tre constamment fait, ne serait-ce que pour se maintenir inform des techniques. La mise en oeuvre des systmes ncessite aussi bien entendu une matrise correcte des moyens de dveloppement pour les parties matrielle et logicielle. Le problme pos peut conduire devoir matriser des techniques autres: traitement du signal, (tl)communications, algorithmique, physique.... 6 M.C.S.E

Ch 1 - INTRODUCTION Ensuite, le concepteur est diffrent du client. Il faut s'intresser au domaine du demandeur: un dialogue est strictement ncessaire. En effet, l'objectif d'un systme est de satisfaire le besoin du client qui n'est probablement ni lectronicien ni informaticien. Pour cela, le concepteur est contraint d'interprter au mieux la demande pour que le systme donne satisfaction. Troisime point: avec l'accroissement de la complexit des applications, les systmes ne peuvent plus tre dvelopps par une seule personne. Apparat alors le problme de la gestion du projet, des ressources humaines, de l'organisation du travail en quipe, de la cohrence d'ensemble... Ajoutons encore, que les systmes lectroniques sont sur un march de concurrence. Ne survivent que les bons produits et les entreprises comptitives. Avec l'volution rapide des techniques et des ides, les dlais de ralisation d'un produit industriel doivent tre les plus courts possibles. Cots et critres de qualit sont devenus essentiels. 20 30 % de leffort de dveloppement devrait tre consacr lanalyse, la spcification et la conception prliminaire. Toute erreur durant ces phases est trs coteuse pour les corrections. Ceci est connu depuis plusieurs annes. Et pourtant, pour bien des projets, la spcification nest pas labore convenablement, entranant par la suite des cots exhorbitants en reconception et modification des ralisations. Pourquoi ceci ? Les ingnieurs sont-ils en cause, ne passant pas suffisamment de temps ou neffectuant pas correctement le travail danalyse ? Il y a bien dautres raisons. Tout dabord, peu de concepteurs sont forms et entrans lanalyse des systmes complexes. Ensuite les concepteurs ne peuvent pas apprendre deux-mmes une ou des mthodes car il existe peu douvrages explicites sur ce sujet. Enfin, la lecture dun ouvrage nest pas suffisante; les ingnieurs inexpriments doivent tre guids durant des projets pour acqurir une bonne exprience. Comment chacun acquiert la comptence? Celle-ci rsulte de l'acquisition d'un savoir faire qui s'toffe au fur et mesure des nouveaux dveloppements. Chaque problme trait contribue enrichir l'exprience du concepteur. Il n'est pas tonnant de constater qu'en Informatique Industrielle le savoir faire est habituellement spcifique de groupes relativement restreints, et la mthode utilise qui dcoule du travail collectif reste de ce fait trs confine. Aussi, une disparit trs importante existe dans la faon de mener bien des ralisations en fonction des entreprises et mme des groupes l'intrieur de celles-ci. La dmarche la plus frquemment constate, procde selon un schma en 3 phases: dfinition du cahier des charges, conception, ralisation. Les concepteurs utilisent directement, sans mthode particulire, le document labor par le demandeur. Procdant une analyse, une solution est labore. La forme de description de la solution est trs varie: organigramme, schmas blocs, emploi de langages de haut-niveau, ou toute autre forme de description. Trs souvent, il est constat que pour un projet donn, les solutions matrielles sont dj choisies explicitement ou implicitement. D'autre part, la dpendance Conception puis Ralisation qui devrait exister n'est pas des plus videntes. Il n'est pas exagr de faire remarquer que bon nombre de fois, les choix de solutions pour la ralisation influent sur la conception et pas l'inverse. M.C.S.E 7

Partie 1 - PRESENTATION DE LA METHODOLOGIE Durant le dveloppement, la sparation des 2 activits: -ralisation matrielle, ralisation logicielle- n'est pas non plus vidente, car le couplage entre les 2 parties est important. S'il n'y a pas au pralable, une dfinition prcise de ce que doit faire chaque partie, le travail d'intgration qui consiste imbriquer les 2 parties, demande, pour un projet men de cette manire, un temps considrable. La situation s'aggrave encore par la suite, car une partie importante du temps doit tre passe assurer la maintenance, l'volution ou l'adaptation des systmes ainsi raliss. Par maintenance, il faut entendre aussi bien l'volution, l'adaptation, la correction, que le dpannage du systme. Cette situation, qui rsulte de la ncessit de corriger a posteriori les erreurs de conception, de spcification, voire de dfinition du produit, nest pas viable. 1.3. INTERETS DUNE METHODOLOGIE Pour rsoudre son problme, le concepteur dispose de techniques et moyens varis. Encore faut-il savoir passer du problme la mise en oeuvre des moyens. Si pendant des annes, la dmarche incrmentale a pu paratre suffisante, l'accroissement des types de problmes, de la varit des techniques et de la complexit des moyens, impose de disposer de mthodes globales qui permettent de passer efficacement du problme la dfinition de la solution. Une telle dmarche constitue une mthodologie. Tout dveloppement ncessite de prendre une multitude de dcisions. Les connaissances sur le problme, les techniques et moyens, constituent les informations ncessaires qui permettent de dcider, tandis qu'une dmarche induit la chronologie des dcisions. Ainsi, face un problme, il est primordial de matriser 3 aspects essentiels que sont: mthodes, techniques, moyens.

METHODES

MOYENS

PROBLEME

TECHNIQUES

-Figure 1.1- Les 3 aspects essentiels pour rsoudre un problme. 8 M.C.S.E

Ch 1 - INTRODUCTION La technique est le support de la ralisation. Les moyens servent mettre en oeuvre la technique. Les mthodes aident passer du problme la ralisation. Que faut-il attendre d'une mthodologie? Celle-ci doit: - garantir lobtention dun rsultat. Elle doit tre suffisamment globale pour couvrir une varit de problmes et de techniques, mais aussi prcise, efficace et simple. - faciliter l'valuation a priori de la faisabilit de l'application, du cot et du temps du dveloppement. - augmenter la productivit des concepteurs et la qualit du rsultat, ceci en favorisant au maximum la production automatique de solutions qui sont alors sans erreur par construction. - accrotre la rflexion un niveau conceptuel qui se veut le plus indpendant possible de la technologie. Ceci conduit une meilleure comprhension du problme, l'laboration de spcifications et de solutions gnrales plus facilement rutilisables. - permettre lorganisation et la conduite de projets, de manire pouvoir grer des dveloppements complexes qui ncessitent la participation d'quipes et de divers spcialistes. 1.4. GENESE DE LA METHODOLOGIE MCSE Pourquoi une mthodologie pour les Systmes Electroniques et l'Informatique Industrielle? Diffrentes raisons ont conduit une telle ncessit. Tout d'abord, durant ces vingt dernires annes, l'volution des techniques disponibles en Electronique et en Informatique a t considrable, et elle ne cessera de s'amplifier. Grce ces techniques, des applications de toute nature et de plus en plus complexes sont devenues ralisables. Pour rpondre une telle demande, la disponibilit de la comptence ou l'acquisition rapide de celle-ci, ainsi que l'organisation des quipes de dveloppement sont devenus des proccupations essentielles. Ensuite, la diffrence des systmes gnraux ou des produits de srie qui sont le rsultat de dveloppements progressifs, les systmes temps-rels pour des applications ddies sont produire immdiatement dans la version dfinitive avec une garantie de rsultat. Aussi, les activits en amont de la ralisation, c'est--dire celles qui concernent la comprhension du besoin, la rdaction des spcifications, la conception, sont essentielles pour satisfaire des contraintes telles que les dlais, les cots, la qualit. En plus des ncessits correspondant aux points prcdents, nous avons constat durant cette dcennie que l'apport d'une mthodologie correspond pour les entreprises un investissement essentiel long terme. Le retour d'investissement, pas facile estimer a priori, se traduit sous des formes varies: rduction des cots et dlais de dveloppement, meilleure satisfaction des clients, plus grande prennit des dveloppements, rduction importante des cots de maintenance. Une mthodologie rsulte d'une volont long terme de chercher mettre la disposition des dveloppeurs une dmarche de travail complte, efficace, cohrente. On peut constater aujourd'hui que pour arriver maturit, toute mthodologie ncessite prs de 10 annes. Une telle dure s'explique aisment. Une mthodologie rsulte pour leurs auteurs, d'une progression M.C.S.E 9

Partie 1 - PRESENTATION DE LA METHODOLOGIE incrmentale ascendante, la seule possible pour analyser les difficults, rechercher des solutions, conceptualiser sous la forme de modles et mthodes, exprimenter pour vrifier et valider chaque proposition, structurer l'ensemble de manire mettre disposition une dmarche globale descendante complte directement exploitable. Sans terrain d'exprimentation, une mthodologie ne peut voir le jour. Pour rpondre au besoin des dveloppeurs, il faut dj connatre leurs problmes: domaine d'activits, nature des difficults... Pour cela, la participation des projets industriels est imprative. Ensuite, l'exprimentation ncessite que soit applique tout ou partie de la Mthodologie pour ces dveloppements industriels. L'observation des problmes, des difficults et des rsultats est aussi une obligation car c'est la source des effets correctifs possibles. Enfin, l'exprimentation concerne les dveloppeurs, utilisateurs de la Mthodologie, et non pas l'auteur de celle-ci ; il faut donc aussi avoir form des concepteurs l'approche mthodologique pour pouvoir observer les rsultats de conception et aussi les difficults d'acquisition des concepts qui subsistent, ainsi que les erreurs d'utilisation. Avec tous ces aspects, la progression est particulirement longue. Depuis 1978, nous avons travaill avec des industriels et pour des industriels: dveloppement de prototypes, formation aux techniques et aux mthodes, transfert de savoir-faire et de mthodologie, cration de produits puis transfert de ceux-ci des industriels pour production et commercialisation. Depuis 1980, la Mthodologie MCSE est enseigne un public d'ingnieurs et de techniciens, bien entendu pas dans sa version actuelle. Ayant dbut par la formation au modle de description des systmes: modles fonctionnel et excutif, nous avons rapidement constat la difficult pour les concepteurs de trouver une solution conforme au modle. L'accent a alors t mis sur l'aspect mthode: comment dduire de spcifications une solution conforme au modle?. Simultanment, nous avons observ l'impossibilit de dissocier la phase de conception des autres phases: en amont, celle de spcification, et en aval celle de ralisation. La Mthodologie a alors t progressivement tendue l'ensemble du cycle de dveloppement. Vers 1985, constatant qu'avec de la mthode, les concepteurs n'laboraient pas obligatoirement des solutions de qualit, nous avons recherch un moyen au-del de l'aspect mthode, ayant la particularit d'induire des ides de solutions (bien entendu de qualit). Une analyse des dveloppements dj entrepris a mis en vidence une relative similitude de solutions par classes de problmes. Ceci a contribu l'introduction des modles gnriques de solutions. L'effort entrepris durant 10 ans ne s'achve pas avec cet ouvrage. Seule une partie du chemin est parcourue. Un effort d'ouverture doit suivre avec pour objectifs: accrotre la formation des concepteurs en nombre et en qualit, poursuivre le dveloppement des concepts et des mthodes pour augmenter les possibilits de production automatique de solutions, induire la cration d'outils informatiques comme support et guide l'utilisation de la mthodologie. 1.5. OBJECTIF DE CE DOCUMENT Aujourd'hui, peu de mthodes, encore moins de mthodologies sont enseignes. Les raisons sont assez simples: il y a peu d'ouvrages disponibles sur le sujet et peu de spcialistes formateurs ont la matrise d'une mthodologie sachant qu'elle ncessite en complment une large connaissance des techniques utilisables et une exprience importante en dveloppement de projets industriels. 10 M.C.S.E

Ch 1 - INTRODUCTION Parmi les mthodologies existantes en rapport avec les systmes temps-rel, citons les principales. Les rfrences bibliographiques et une prsentation succincte de chacune delles sont donnes dans la partie 2. - SADT (structured analysis and design technique) pour la phase de spcification [ROSS-85]. - SA/SD (structured analysis, structured design) de DEMARCO, YOURDON et CONSTANTINE pour la spcification par diagramme flots de donnes et la conception modulaire [DEMARCO-79, JENSEN-79]. - JSD (Jackson system development) de JACKSON couvrant toutes les phases du dveloppement [JACKSON-83] - O.O.D. (object oriented design) de BOOCH pour la conception oriente 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 systmes temps rels ddies [WARD-85, HATLEY-87]. - DARTS (Design Approach for Real Time Systems) pour la spcification et la conception d'applications temps-rel et DARTS/DA pour les applications distribues [GOMAA-84,89]. Utilisation de cette mthode 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 systmes vnementiels (behaviour intensive). Ces mthodologies diffrent quant au domaine d'applications, aux phases du dveloppement, aux modles et mthodes. Que faut-il utiliser? : l'une de celles cites ci-dessus, MCSE, ou faut-il en dvelopper une nouvelle base sur d'autres concepts? Question pertinente. Ce document a pour objectif d'amliorer la connaissance sur un tel plan mthodologique. Son contenu ne concerne donc pas des connaissances techniques mais uniquement celui de l'acquisition de concepts et de mthodes. 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 numrique, les systmes microprocesseurs, les automatismes et systmes de contrle/commande, les outils informatiques et les langages de haut-niveau. Ce document a pour ambition de proposer une mthodologie complte pour le dveloppement des systmes. Aussi, concerne-t-il les industriels et tout particulirement les ingnieurs qui ont en charge la conception de produits ou de systmes, ainsi que les tudiants ingnieurs et techniciens qui s'orientent vers ce type d'activits. Sont concernes par tout ou partie du document, au moins 4 catgories d'ingnieurs et techniciens: - les responsables de projets qui ont en charge: l'estimation, la planification, la conduite de projets, - les spcifieurs et concepteurs chargs d'effectuer tout le travail de dveloppement en amont de la ralisation, M.C.S.E 11

Partie 1 - PRESENTATION DE LA METHODOLOGIE - les ralisateurs qui doivent utiliser et donc comprendre les rsultats de la conception, - les formateurs qui ont pour mission de dvelopper chez leurs auditeurs lesprit mthode en spcification, conception et ralisation de systmes. Pour rpondre ces 4 catgories d'utilisateurs, le document est structur en 3 niveaux d'intrt: - le niveau Prsentation, qui permet de se faire une ide de ce qu'est une mthodologie. Aprs une dlimitation du domaine d'application, la partie 1 dcrit, par une prsentation succincte, la mthodologie MCSE, les concepts et les tapes. Elle est illustre par une tude de cas. La partie 8, montre en conclusion, sur la base de la trilogie: -mthodes, outils, concepteurs en tant qu'utilisateurs de mthodologies-, l'effort long terme et donc la motivation que suppose l'emploi d'une mthodologie, ainsi que les perspectives d'volution des outils comme support. - le niveau Mthodologies et conduite de projets, qui donne une vision assez large pour l'organisation des dveloppements. La partie 2 donne un aperu des mthodologies connues dans le domaine des systmes temps-rel. La partie 7 prsente les problmes et principes essentiels en conduite de projets. - le niveau Manuel de Rfrence, qui explique en dtail les concepts, principes, et dmarches 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, dcrivant le rle et la dmarche pour la premire tape d'laboration des spcifications, la partie 4, qui concerne l'tape de conception fonctionnelle, la partie 5 relative la dfinition de la ralisation, la partie 6, dcrivant les problmes et techniques pour les ralisations matrielle et logicielle. Un rsum la fin de chaque chapitre rappelle les points essentiels. Ainsi, aprs avoir lu le niveau prsentation, il est conseill au lecteur de s'intresser soit au niveau Mthodologies et conduite de projets, soit au niveau Manuel de Rfrence, suivant qu'il dsire avoir une vue globale du sujet mthodologies et projets d'abord, ou qu'il aspire approfondir la Mthodologie en vue de s'en servir. Il nous semble d'emble souhaitable de prvenir le lecteur, que, s'il dsire devenir comptent en conception, il s'agit d'un investissement long terme qui ncessite du temps. Lire un ouvrage ne suffit pas pour mettre en application les concepts lus, il faut aussi dvelopper des projets et prendre le temps de faire une analyse critique des rsultats bons et mauvais de manire enrichir progressivement son exprience.

12

M.C.S.E

Chapitre 2

CARACTERISTIQUES DES SYSTEMES

Ce document concerne les systmes pour lesquels la ralisation rsulte de l'association d'une partie matrielle (lectronique) et dune partie logicielle (informatique). Le terme systme dsigne la partie dvelopper qui n'est en fait qu'une partie de l'application. La dmarche pour concevoir et dvelopper de tels systmes dpend de la nature de son environnement et des caractristiques souhaites pour l'application. Avant de prsenter les principes retenus, il apparat tout d'abord souhaitable de caractriser les systmes pour lesquels la mthodologie MCSE a t dveloppe. Aussi, aprs avoir rappel l'volution des techniques et moyens en Electronique et prcis le domaine de l'Informatique Industrielle, ce chapitre prsente: les classes de problmes concerns et les moyens de ralisation pour les systmes ddis, les caractristiques des systmes temps-rel et les critres de qualit pour un systme. 2.1. EVOLUTION DES TECHNIQUES ET DES MOYENS DE REALISATION A partir du transistor puis des circuits intgrs, une volution considrable de la technologie a conduit une diversification des techniques disponibles pour la mise en oeuvre des systmes lectroniques. Comme point de repre, notons le passage de l'analogique aux techniques digitales et numriques, puis le passage de la logique cble la logique programme ou

M.C.S.E

13

Partie 1 - PRESENTATION DE LA METHODOLOGIE programmable que constituent les rseaux logiques et les microprocesseurs. Les avantages sont vidents: une structure matrielle donne permet de rsoudre, non pas seulement le problme concern, mais toute une famille de problmes. Notons aujourd'hui une distance de plus en plus importante entre les caractristiques techniques et technologiques de la partie matrielle et les fonctionnalits possibles pour les applications ralises avec de tels composants. Ainsi, un mme support peut servir pour une multitude d'applications, et inversement, une varit de technologies existe pour une mme application. La spcification du fonctionnement du systme pour une application particulire se dfinit de plus en plus par programmation. La rutilisation du matriel devient possible, et les possibilits de modification, d'amlioration du produit sont importantes grce au logiciel. Ainsi, progressivement, d'une solution purement matrielle, progressivement les ralisations ont volu vers un partage matriel/logiciel avec un accroissement de la partie logicielle. En moyenne, aujourd'hui pour tous types de systmes confondus, la part du logiciel est estime plus de 70%. De ce fait, par les applications, l'Electronique et l'Informatique se trouvent intimement mls. Plus rcemment, grce 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 centralises par des ralisations dont la structure est trs proche de la rpartition gographique de l'application. Une partie de la complexit est alors prise en charge par un systme de communication inter-fonctions. Naturellement, les systmes auparavant autonomes sont aujourd'hui de plus en plus interconnects. Toutes ces techniques sont relativement bien connues et matrises. Au fur et mesure de l'accroissement de la complexit, les objets disponibles sont de plus en plus proches des fonctionnalits dsires, 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 ralisation des systmes 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 assiste par ordinateur aident les concepteurs dfinir, vrifier, puis raliser les composants et systmes lectroniques. En plus de l'utilisation des composants standards, l'lectronicien a mme la possibilit de dvelopper ses propres composants spcifiques (ASIC). Pour la partie logicielle, le dveloppeur dispose d'une varit d'outils la fois comme supports: microordinateurs, systmes informatiques, ou comme moyens de dveloppement: cross-compilateurs, analyseurs de performances, progiciels varis. 2.2. LE DOMAINE DE LINFORMATIQUE 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 influences ou concernes par l'Electronique. En effet, comme technique de ralisation, il sert de support pour de multiples activits, contribuant ainsi amliorer les fonctionnalits, les performances, la scurit, la souplesse d'exploitation... 14 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES Les techniques mises en oeuvre concernent lANALOGIQUE, le NUMERIQUE et la PROGRAMMATION. Aujourd'hui, plutt que de chercher cerner la frontire entre l'ELECTRONIQUE et l'INFORMATIQUE, toutes deux considres sous l'aspect techniques de ralisation, il est plus raliste de considrer la synergie globale. En effet, pour le premier domaine, les systmes intgrent de plus en plus de moyens informatiques, et pour le deuxime, calculateurs, capteurs, actionneurs, priphriques, interfaces sont ncessaires comme support de ralisation des applications. Ainsi est apparu durant la dcennie passe le domaine de l'INFORMATIQUE INDUSTRIELLE comme discipline intermdiaire. Pour l'Informatique Industrielle, un systme est compos de 2 parties: - une partie matrielle, qui est la partie visible. Elle se dcompose en une partie analogique pour laquelle tensions et courants ont une importance dans le fonctionnement, et une partie numrique pour laquelle au niveau utilisation, seuls les tats logiques ou numriques sont suffisants. La frontire entre les 2 ne dpend que du niveau d'observation, - une partie logicielle, pas directement visible, puisqu'elle se concrtise par des tats logiques 1 et 0 dans les mmoires de l'appareil, ou dans des supports de masse. Des matriels spcifiques (informatiques et logiciels) permettent de produire, manipuler de telles informations. La partie analogique est plus ou moins importante suivant l'application. De toute manire, elle existe toujours, car tout systme est coupl son environnement par des interfaces qui vhiculent courants et tensions. D'autre part, certaines fonctions non ralisables par une technique numrique subsistent: mission-rception haute-frquence, gnration et transformation de signaux... La partie numrique est constitue d'un assemblage de composants LSI et VLSI, ralisant chacun une fonction complexe. Ces composants sont de plus en plus programmables, ce qui justifie une architecture btie autour d'un ou plusieurs microprocesseurs. La part du logiciel peut varier dans des proportions considrables. De plus en plus, la fonctionnalit est obtenue par le logiciel, tandis que le matriel n'en est que le support d'excution. A l'extrme, les systmes informatiques sont considrs comme des supports fonctionnels complets qui permettent de dvelopper une application sans devoir s'intresser la partie matrielle. La fonctionnalit globale rsulte d'une bonne adquation entre toutes les parties: assemblage correct de tous les composants, programmation adapte pour la mise en oeuvre des composants et pour rpondre aux spcificits de l'application. Concevoir et raliser de tels systmes ncessite donc une comptence technique dans les 3 domaines: Electronique analogique, Electronique numrique ou Informatique industrielle, Informatique. A cela peuvent s'ajouter des comptences complmentaires: en composants intgrs lorsqu'il s'agit d'en concevoir, en lectronique de puissance lorsque l'environnement utilise les courants forts, en rseaux et communications lorsque des couplages entre systmes ou ensembles sont ncessaires... Mais il faut aussi ajouter obligatoirement l'aptitude cerner les besoins de demandeurs de tous domaines qui requirent la mise en place d'un systme, ainsi que la matrise d'une dmarche de dveloppement. On peut aisment imaginer la difficult de cette spcialit, ainsi que la responsabilit de cet homme de l'Informatique Industrielle comme matre-d'oeuvre en dveloppement de systmes. M.C.S.E 15

Partie 1 - PRESENTATION DE LA METHODOLOGIE 2.3. LES SYSTEMES DEDIES Pour les applications considres dans le paragraphe prcdent, le demandeur sollicite la ralisation d'un systme dit "ddi". Il faut entendre par l que le systme est dvelopp un instant donn pour rpondre un besoin bien dlimit. Sa dure de fonctionnement est dfinie: plusieurs annes, voire mme des dizaines d'annes. La prennit est donc importante. Ainsi, le systme est dvelopper au mieux, directement dans sa version dfinitive avec la technologie courante. Son volutivit reste limite quelques amliorations pour la mme application. Il ne s'agit donc pas d'un systme gnral comme l'est un ordinateur ou un microordinateur, il ne s'agit pas non plus d'un prototype qui dmontre un bon fonctionnement un moment donn. Un systme ddi est install une fois pour toutes. Aussi, la dmarche pour le dveloppement doit conduire une efficacit directe puisque la solution ne rsulte pas d'un dveloppement incrmental, rsultat d'expriences successives. La technique mettre en oeuvre se doit d'tre juste adapte et suffisante pour le problme de manire rduire le cot et le temps de dveloppement ainsi que le cot de reproduction. Les techniques pour raliser de tels systmes sont varies: - utilisation de systmes complets: micro-ordinateur, automate programmable, systme de rgulation, systme de traitement d'images, terminaux, ordinateurs,..., - utilisation de cartes, sous-ensembles et progiciels: cartes microprocesseurs, alimentation, cartes interface, support de masse, bases de donnes, gnrateurs de rapports, systme multi-fentres... La rutilisation permet de rduire les temps de dveloppement. Elle est strictement ncessaire pour le matriel, car l'utilisateur ne peut pas fabriquer ses composants, et chaque reproduction implique un cot. Moins contraignant pour le logiciel, le concepteur peut vouloir, tort, dvelopper compltement le logiciel de son application, avec l'argumentation que le programme dvelopp sera bien plus appropri que celui qui rsulterait de la rutilisation d'un programme prcdent, d'une bibliothque de logiciel, d'un progiciel plus gnral... 2.4. LES SYSTEMES TEMPS-REEL Intressons-nous aux caractristiques fonctionnelles d'un systme partir des applications. La fonctionnalit est alors explique par le vocabulaire de l'application et non par le vocabulaire de la technique mise en oeuvre. Le terme environnement est utilis pour reprsenter la partie de lapplication exclu le systme. L'environnement d'un systme lectronique ddi est compos d'objets (au sens gnral) de diverses natures: certains sont physiques, d'autres sont humains. Les objets sont dynamiques; ainsi par leurs actions, ils gnrent des vnements, informations, donnes. De mme, ils sont sensibles des sollicitations externes. En consquence, fonctionnellement, les systmes dvelopper sont dits du type ractif, car ils ragissent sur l'environnement partir de sollicitations qui en proviennent. La frquence des sollicitations est alors un paramtre important. 16 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES Pour satisfaire l'objectif qui lui est assign, le systme est coupl ces objets par des interfaces pour l'observation et la commande. Ainsi, ces systmes possdent de multiples entres et sorties. On voit ainsi apparatre 2 classes d'interfaces: les interfaces homme-machine et les interfaces physiques. Les procdures d'change entre le systme et son environnement doivent tenir compte de la nature de ces interfaces. Comme l'environnement physique est souvent compos de plusieurs activits simultanes, parfois mme rparties gographiquement, l'application ncessite l'exploitation d'un systme qui assure simultanment: - l'observation de grandeurs pour suivre l'volution de l'environnement, - la prise en compte d'vnements survenant alatoirement, - l'valuation de dcisions partir des vnements et observations, - la gnration d'actions auprs de l'environnement pour assurer la cohrence de l'ensemble de l'application. Du fait de la multiplicit des entres et sorties qu'il faut suivre globalement, un systme lectronique doit effectuer des traitements simultans. Le degr de simultanit est fonction de la technique de ralisation. Elle est complte lorsque des parties matrielles sont attribues chaque traitement. Elle est pseudo-simultane lorsqu'un processeur partage son activit pour satisfaire plusieurs traitements. Le fonctionnement pour un tel processeur est alors qualifi de multi-tches. Coupl son environnement, un systme lectronique est aussi concern par le temps de raction des objets qui l'entourent. La commande d'un ascenseur, d'un chariot filoguid, d'un avion est intimement lie la vitesse d'volution de ces objets. Si les changes d'informations pour les interfaces du type homme-machine sont plutt de l'ordre de la seconde ou du 1/10e de seconde, la priode de raction d'un systme vis vis de procds physiques est plutt de l'ordre de la milliseconde. Ainsi les temps de rponse requis par les systmes lectroniques sont nettement plus proches de la vitesse de raction de la technologie mise en oeuvre (100 s 1 ms pour les microprocesseurs). De tels systmes sont qualifis de TEMPS-REEL. Par dfinition, un systme est dit du type temps-rel lorsqu'il effectue toutes ses activits en respectant des contraintes de temps. En effet, l'interaction importante avec l'environnement fait apparatre plusieurs natures de contraintes de temps, certaines parfois svres, qu'il s'agit de respecter: - tout d'abord une frquence leve pour les sollicitations en provenance de l'environnement: frquence d'vnements, dbit en donnes... - une frquence leve pour les actions entreprendre auprs de l'environnement, par exemple, frquence leve pour la commande d'un procd faible temps de rponse. - une limite maximale pour le temps de raction entre l'instant d'apparition d'une sollicitation et l'instant d'achvement de l'action consquente (date d'chance). Le non-respect d'une des contraintes peut conduire l'application dans un tat assimilable un tat de panne, ce qui peut engendrer des consquences trs graves, jusqu' la mise en danger de vies humaines. M.C.S.E 17

Partie 1 - PRESENTATION DE LA METHODOLOGIE Ainsi, les systmes temps-rel sont diffrents des systmes dits interactifs. Ces derniers sont plutt qualifis de systmes "on-line". Coupls des oprateurs, ils requirent des temps de rponse courts, qui, s'ils ne sont pas respects, ne conduisent pas des consquences graves. Pour un systme de gestion bancaire par exemple, le temps de rponse pour les transactions doit rester faible pour le confort des utilisateurs. Un retard reste supportable s'il n'est que ponctuel. 2.5. QUALITES DUN SYSTEME Un systme peut aussi tre observ selon ses qualits, chacune contribuant satisfaire un objectif spcifique. Un systme peut notamment tre: - adquat: son comportement avec l'environnement rpond aux souhaits du demandeur, - performant: toutes les contraintes de temps sont satisfaites et les temps de rponse du systme sont acceptables, - robuste: le systme reste oprationnel, compltement ou en mode dgrad mme en prsence de fautes ou d'vnements non-prvus en provenance de l'environnement. - volutif: le systme favorise l'volution de ses caractristiques et de ses fonctionnalits. Ceci est ncessaire pour rpondre aux volutions imprvisibles du cahier des charges. - maintenable: aprs sa ralisation le systme est conserver en fonctionnement durant la vie de l'application. Les corrections et amliorations font aussi partie des tches dvolues la maintenance. - cot optimal: le dveloppement et la production du systme conduisent un cot convenable et accept par le demandeur. Ces qualits servent d'objectifs pour tout dveloppement. Ainsi, une mthodologie pour le dveloppement de systmes temps-rel pour des applications ddies, doit favoriser la dtermination de solutions rpondant de tels critres. 2.6. CATEGORIES DE SYSTEMES Tentons pour conclure ce chapitre d'effectuer un classement des systmes en se basant sur la technique majeure mise en oeuvre. Pour la classification qui ne peut rester qu'approximative, considrons 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 reprsente par un cercle. Les disciplines sont partiellement en recouvrement. Dans ce document, on s'intresse aux systmes qui ncessitent la mise en oeuvre de diffrentes techniques des degrs plus ou moins importants. Ces systmes sont reprsents dans le cercle correspondant l'Informatique Industrielle. Sont exclus les systmes trs spcifiques d'un domaine car ils requirent alors une mthodologie particulire en rapport direct avec les concepts et techniques mettre en oeuvre de la discipline. Ainsi, sont concerns par la mthodologie MCSE, les systmes suivants: - les systmes typiquement lectroniques: qui impliquent essentiellement le dveloppement de matriels tels que conception de fonctions et composants, association de fonctions, 18 M.C.S.E

Ch 2 - CARACTERISTIQUES DES SYSTEMES

AUTOMATIQUE

INFORMATIQUE Systmes

Systmes de contrle/commande

interactifs

INFORMATIQUE
Systmes lectroniques Systmes de communication

INDUSTRIELLE
ELECTRONIQUE

COMMUNICATIONS

Systmes de traitement

TRAITEMENT DU SIGNAL

-Figure 2.1- Disciplines et classes de systmes. - les systmes de contrle-commande, domins par des problmes de suivi et de commande pour des applications incluant des procds physiques en tous genres piloter, - les systmes interactifs concerns par l'exploitation d'interfaces volues pour les dialogues homme-machine, - les systmes de communication: domins par le transfert de donnes. Ces systmes reoivent, transforment et mettent des flots de messages, - les systmes de traitement: concerns principalement par les traitements de toute forme d'information: signal, image, parole...

M.C.S.E

19

Chapitre 3

CYCLE DE DEVELOPPEMENT DUN SYSTEME

Aprs avoir caractris les systmes par leurs domaines d'application, les techniques mises en oeuvre et les particularits du temps-rel, nous devons caractriser le processus de dveloppement d'une application. Il n'est pas utile de dvelopper en prambule toutes les raisons qui font que, mme de bons projets ne convergent pas obligatoirement vers un succs: mdiocre organisation, outils inadapts, manque de mthodes, absence de plans et procdures de test et d'intgration, manque de spcifications, pas d'investissement de la part du demandeur dans le projet. L'objectif plus essentiel est d'exprimer quelle dmarche suivre pour dvelopper efficacement le systme rpondant au besoin du demandeur. Pour caractriser l'activit de dveloppement, celle-ci est tout d'abord replace dans le contexte de l'entreprise. Un dveloppement est une partie des activits d'un projet, et chaque projet s'intgre dans un objectif d'entreprise. L'obtention de rsultats implique la ncessit de disposer d'une dmarche pour planifier, organiser et contrler les dveloppements de projets. Le management de projets ncessite de modliser le processus de dveloppement lui-mme. Le terme gnral "cycle de vie d'une application ou d'un produit" est utilis pour dcrire un tel type de modle. Introduit vers 75, ce type de modle sert de support pour expliciter la procdure suivre, puis pour effectuer des contrles.

M.C.S.E

21

Partie 1 - PRESENTATION DE LA METHODOLOGIE Ce chapitre montre que le dveloppement d'un systme ncessite une organisation plus complexe que le simple squencement des tapes de spcification, de conception et de ralisation. De plus, un modle pour le dveloppement sert aussi de base pour une mthodologie. En fin de chapitre, le modle propos pour les systmes lectroniques permet de dlimiter le domaine dintrt de la mthodologie MCSE. 3.1. CONTEXTE DUN DEVELOPPEMENT Le terme Dveloppement est utilis ici pour caractriser l'ensemble des activits techniques qui permettent de passer d'un cahier des charges au produit industriel rpondant au besoin. Pour l'entreprise ou l'organisme charg du dveloppement, ces activits font partie intgrante d'un projet. Un projet est caractris: d'une part par des objectifs, d'autre part par son droulement. Il a un dbut et une fin qui correspond la satisfaction des objectifs. Un projet est aussi en interaction avec d'autres activits (ou projets), ne serait-ce que par un partage de ressources. Ainsi, caractriser le contexte d'un dveloppement consiste positionner celui-ci dans le contexte de l'entreprise comme le montre la figure suivante.

Management de lentreprise

ENTREPRISE

ACTIVITES

projet i

projets

management du projet

developpement du projet

RESSOURCES

-Figure 3.1- Contexte global d'un dveloppement. L'activit de l'entreprise au sens large concerne un ensemble de projets. Le dveloppement d'une application et d'un systme n'est qu'une partie du projet. Pour son activit, l'entreprise dispose de ressources matrielles et humaines qu'elle rpartit pour les diffrentes activits. Pour mieux caractriser l'activit de dveloppement, prcisons ce qu'est un projet et son management. 22 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME Un projet est caractrisable par son cycle de vie. Ce cycle dbute par une phase dexpression du besoin pour se conclure par une phase de finalisation. En intermdiaire, sajoutent 3 phases comme l'indique la figure 3.2: dfinition du projet, planification et organisation , dveloppement [RUSKIN-82].
Abstrait

Expression du besoin Dfinition du projet Management du projet Planification organisation

Dveloppement du projet

Achvement du projet
Concret Temps

-Figure 3.2- Les phases dun projet.


-A- EXPRESSION DUN BESOIN

Un projet dbute par la ncessit ou le souhait de satisfaire un objectif. L'objectif peut tre trs vari en nature et forme. Par exemple, il peut sagir de dvelopper un systme de conduite de grands btiments, mais lobjectif peut aussi s'exprimer par la volont d'apporter une aide la conduite de btiments. La premire 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 manire d'atteindre ces objectifs. Diffrentes techniques sont utilisables et en particulier les techniques de crativit et d'analyse de la valeur.
-B- DEFINITION DU PROJET

Cette phase concerne une tude prliminaire du projet. Il s'agit tout d'abord de caractriser le projet par une tude de faisabilit sur la base de suppositions sur les diffrentes manires d'atteindre les objectifs, les critres de dcision, les contraintes, les obstacles potentiels, les ressources, budgets et chances. Il s'agit ensuite de slectionner l'approche globale suivre pour satisfaire les objectifs. La dfinition du projet conduit une description suffisamment dtaille pour quune proposition puisse tre labore. M.C.S.E 23

Partie 1 - PRESENTATION DE LA METHODOLOGIE La phase de dfinition du projet ncessite de considrer tous les aspects du dveloppement sans pour cela raliser le projet.
-C- PLANIFICATION ET ORGANISATION

Lorsque le projet est accept, les objectifs, le cot et les dlais sont fixs. La phase suivante concerne sa planification et son organisation. La planification conduit laborer des plans dtaills en identifiant les tches, les chances et dures pour chacune, les budgets et les ressources ncessaires pour chaque tche. Il s'agit aussi d'laborer l'organisation ncessaire pour excuter le projet. Cela concerne l'identification des ressources ncessaires en qualit, quantit et dure.
-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 dtaille dans le paragraphe suivant.
-E- FINALISATION DU PROJET

Cette activit a pour objectif la vrification de la conformit du produit labore vis vis des objectifs, celle-ci doit se faire si possible tout au long du dveloppement. Une fois le produit achev, il s'agit d'aboutir la confirmation que le client est satisfait du rsultat. Ce qui se traduit par une recette. La conclusion du projet permet de librer les ressources utilises et conduit un bilan financier. Ainsi, comme l'indique la figure prcdente, autour du travail de dveloppement, le management d'un projet concerne prcisment les activits de planification et dorganisation, ainsi que la direction du dveloppement et son contrle. L'objet de la mthodologie MCSE ne concerne pas la partie management de projet. Quelques lments sont dcrits dans la partie 7 de manire connaitre la complmentarit des activits de conduite de projet et de dveloppement, car le management est bas sur un modle du processus de dveloppement qui est le cycle de dveloppement ou plus communment le cycle de vie du produit. 3.2. LES PHASES DUN DEVELOPPEMENT Le cycle de vie pour une application ou un produit est une reprsentation purement descriptive. Il dcompose le processus de dveloppement selon une srie d'activits couples entre elles, partant du besoin initial pour aboutir au produit oprationnel. Le terme cycle est li au fait que, habituellement, tout produit dvelopp engendre de nouveaux besoins. Plusieurs modles ont t labors. Avant de s'intresser aux diffrences entre eux, notons que tous ont en commun les phases essentielles de tout dveloppement. Ainsi, avec quelques variations en fonction des auteurs, on distingue, au minimum 5 phases: - dfinition ou spcification, - conception, - ralisation, - production, - fonctionnement. On donne ci-aprs la signification usuelle pour chacune de ces phases. 24 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME


-A- DEFINITION ET SPECIFICATION

Un projet rsulte gnralement d'une demande formule sous la forme d'un document dcrivant les besoins. Le document est appel Cahier des Charges. Pour l'quipe ralisant, c'est une base de dpart, pour exprimer une proposition qui se doit de contenir l'ensemble des spcifications. Si certaines descriptions du cahier des charges paraissent claires pour le demandeur, un tel document ne contient habituellement que peu de dtails, ce qui le rend insuffisant pour caractriser le projet complet. Ainsi, durant la phase de dfinition, les objectifs auxquels doit satisfaire le systme final sont recenss. Il s'agit d'obtenir une description dtaille du comportement externe du systme. Cette description exprime les fonctions remplir, les contraintes respecter, les interfaces exploiter, toutes les informations complmentaires prcisant la taille du systme, la vitesse d'excution, les performances et autres caractristiques satisfaire...
-B- CONCEPTION

Le travail de conception consiste passer des spcifications une dfinition de la ralisation, c'est--dire aux documents ncessaires pour entreprendre la ralisation. Au dpart, le concepteur exploite directement les spcifications pour dduire une dcomposition en termes de fonctions. Au fur et mesure que des dcisions sont prises, le raffinement se poursuit en exprimant comment chaque fonction considre comme "bote noire" contribue atteindre les objectifs. Ceci est une vue simplifie, car pour concevoir il faut passer par plusieurs stades intermdiaires. Pour chaque stade, toute spcification est transforme en une ralisation correspondante et par une suite de dcisions. Si ce schma est maintenant classique en particulier pour des projets logiciels, les stades intermdiaires par lesquels il est judicieux de passer, dpendent de la classe des problmes traits. Pour la catgorie des systmes temps-rel que nous considrons dans ce document, la conception doit produire simultanment la dfinition des solutions matrielle et logicielle, ce qui complique la dmarche.
-C- REALISATION

La phase de ralisation concerne le dveloppement du matriel, celui du logiciel, puis l'intgration du logiciel sur l'infrastructure matrielle. Cette ralisation aboutit un ensemble en tat de fonctionnement reproductible industriellement et rpondant aux spcifications du problme.
-D- PRODUCTION

Cette phase concerne tout d'abord l'exprimentation d'un prototype pour valuer ses caractristiques. La mise en production dcoule ensuite de cette valuation. Des critres complmentaires d'industrialisation sont introduits ce stade.
-E- FONCTIONNEMENT

Une fois le produit dvelopp en srie et commercialis, il se retrouve en fonctionnement. Dbute alors la phase d'exploitation qui implique bien entendu une maintenance. Diverses maintenances sont possibles: corrective pour exclure les erreurs rsiduelles, adaptative pour tenir compte des exigences nouvelles, prventive pour augmenter la fiabilit des systmes. M.C.S.E 25

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les 2 dernires 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 dvelopps. 3.3. MODELES DE CYCLE DE VIE En plus de l'intrt d'une structuration du travail, la dcomposition du projet en tapes facilite le contrle du dveloppement en dfinissant pour chacune des phases des objectifs atteindre planifiables et mesurables. Un modle pour le dveloppement sert donc de base pour la conduite de projet. Plusieurs modles ont t proposs pour reprsenter l'enchanement des phases de dveloppement. Nous dcrivons dans la suite les modles les plus caractristiques prsents pour le dveloppement de logiciels. 3.3.1. Le Modle "Waterfall" Ce premier modle dcrit le cycle de vie comme une succession d'tapes conduisant trouver des niveaux de description, du problme jusqu' la ralisation, en partant de la dfinition jusqu' l'exploitation et la maintenance [BOEHM-76].

SPECIFICATION

Corrections

CONCEPTION PRELIMINAIRE

CONCEPTION DETAILLEE

REALISATION

-Figure 3.3- Le modle Waterfall. Chaque tape est lie l'tape suivante pour reprsenter l'enchanement, et l'tape prcdente pour reprsenter les corrections par retour-arrire. A chaque tape est associe une phase de vrification ayant pour but de s'assurer de la conformit de la solution retenue aux 26 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME spcifications en entre de l'tape. Un dfaut de conformit implique de reprendre l'tape ou de revoir le rsultat de l'tape prcdente. Ce modle fait dj apparatre qu'un dveloppement ne peut pas se faire exclusivement selon une dmarche purement descendante. Comme le suggre la thorie de la commande en boucle ferme, les incertitudes ou erreurs et omissions sont corriges par des retours-arrires ds l'observation d'carts. Bien sr, ceci n'est possible que si, l'issue de chaque tape, le rsultat est observable et comparable un objectif. Un accroissement important de l'effort de validation durant les premires phases favorise une correction rapide des premires erreurs, sinon celles-ci conduisent par la suite un cot de correction considrable. Un peu limit, ce modle ne prend que trs partiellement en compte la vraie nature du dveloppement, c'est--dire son caractre itratif. 3.3.2. Le cycle en V Ce modle considre en supplment les phases de vrification et d'valuation du projet pour chaque stade de sa ralisation. Il montre bien que la dmarche de spcification-conception est globalement descendante tandis que la phase de ralisation-test est globalement ascendante, car il s'agit d'assembler les constituants pour obtenir les fonctionnalits. La figure suivante prsente un exemple type de plan de dveloppement.
Spcification
BESOIN
CERTIFICATION

Conception - developpement

Test et valuation

fonctionnement maintenance
PRODUIT Evaluation et test oprationnel

Cahier des charges

Spcification systme

VALIDATION

Test dintgration systme

Spcification logiciel performances

VALIDATION

Tests de performances

Spcification
Conception prliminaire Corrections
VERIFICATION

Validation
Test intgration

conception

Conception dtaille

Test unitaire

Ralisation

Code

Programme codage

Mise au point

-Figure 3.4- Exemple de cycle de vie en V. L'axe horizontal reprsente les phases du projet et la dure de chacune. L'axe vertical reprsente le niveau d'abstraction pour l'application. Les phases de spcification et de conception conduisent dfinir des niveaux de description de plus en plus dtaills. Pour une M.C.S.E 27

Partie 1 - PRESENTATION DE LA METHODOLOGIE application logicielle, le codage est la forme la plus dtaille. Les phases d'intgration, de test et de vrification, permettent d'valuer la conformit de la ralisation pour chaque niveau de la conception en commenant par les parties les plus lmentaires puis en remontant progressivement jusqu'au produit complet. Pour cela, en correspondance de chaque phase de la conception est associe une phase de test et d'valuation de la conformit. Les 2 dmarches descendante et ascendante sont complmentaires. Ce modle favorise une planification des dates de production et de lecture de documents l'issue de chaque phase, des chances pour les procdures de vrification-validation. Toutefois, il est plutt spcifique d'un dveloppement logiciel. 3.3.3. Le Modle "Spirale" Les modles prcdents concernent la cration d'un seul produit. Ils n'apparaissent pas trs appropris pour la description d'un ensemble de produits et d'activits autour de ces produits: faisabilit, prototypage... Le modle Spirale [BOEHM-86,WILLIAMS-88] dcrit le dveloppement comme un processus itratif selon 4 phases, permettant de combiner diffrentes approches: expression des besoins, faisabilit, prototypage, dveloppement 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 opration Validation des besoins prototype oprationnel

plan du cycle de vie plan de developpement Integration et test

besoin logiciel conception logicielle

conception detaille

Validation de la conception et vrification test

test code uniintgration taire et test DEVELOPPEMENT VERIFICATION NIVEAU N+1 DU PRODUIT

PLANIFICATION DES PHASES SUIVANTES

implmentation

conformit

-Figure 3.5- Le Modle Spirale. Les 4 phases, une par quadrant, concernent: - la planification des phases ultrieures, - la dfinition des objectifs, des variantes et des contraintes, - l'valuation de solutions, analyse des risques, - le dveloppement et la vrification du produit. La distance de tout point de la courbe au centre reprsente le cot cumul qui a conduit un tel stade du dveloppement. 28 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME 3.3.4. Le modle "Contractuel" Tout dveloppement implique une interaction entre le client et les concepteurs. Ce modle prsente ce point de vue. Chaque phase du dveloppement est considre 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

Modle formel Comportement acceptable ?


non preuve

Adquat analytiquement ?
oui

Spcification formelle

Besoin conception
non

conception

Conception

Comportement quivalent ?
preuve

non

Architecture fonctionnelle

Adquate

Proposition
oui

et ralisable ?
oui

de
Besoin ralisation

conception

Construction

non

Schma
non

Implmentation
Comportement adquat ?

preuve

Proposition
oui oui

Ralisable ? reproductible ?

dimplmentation

-Figure 3.6- Le modle contractuel. Une phase du dveloppement conduit passer d'une description la description suivante. La validation du rsultat est faite par le client. L'achvement 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 modle montre que le concepteur est dans la situation de devoir dcouvrir quelque chose qui donnera satisfaction au client. La premire phase apparait particulirement dlicate puisqu'elle consiste formaliser le souhait du client sans que celui-ci l'exprime clairement et compltement. 3.4. QUELQUES CONSTATATIONS 3.4.1. Recouvrement des phases Les modles prcdents tendent induire l'ide que les phases sont nettement identifies et spares. La ralit est plus complexe. Initialement durant chaque phase, des retours-arrire conduisent modifier ou complter des dcisions prises dans les phases prcdentes. Il y a donc ncessairement recouvrement des phases comme l'indique la figure suivante [HATLEY87]. Ainsi, par exemple, la conception dbute sans que la spcification ne soit compltement acheve.
Effort

Spcification

conception

ralisation

test

Temps

-Figure 3.7- Recouvrement souhaitable des phases. Cette figure montre que toutes les phases dbutent presque simultanment mais avec un effort qui varie en fonction de la progression. Entre autres, on peut remarquer que la phase de test dbute trs tt. En effet, durant les premires phases, l'objectif est de prparer les critres et procdures de test et de validation. Ceci peut conduire prendre rapidement des dcisions particulires en conception, ou la ncessit de dvelopper un systme de test. De mme, il est habituel de constater que les spcifications ne sont que rarement acheves car des volutions apparaissent ct demandeur. 30 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME 3.4.2. Cot de correction des erreurs La rduction des cots et dlais passe par la rduction des erreurs. Or il est ais de comprendre que les erreurs dtectes trs 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 coteuses qu'elles peuvent concerner des dcisions premires essentielles: spcifications, performances, besoin. La figure ci-aprs illustre le cot exponentiel de la correction des erreurs.
Cot
Echelle log 10 000

Cot de corrections
1000

100

10

0.1

Instant de dtection des erreurs

Spcification

conception

Ralisation

Production

Exploitation

-Figure 3.8- Courbe du cot de correction des erreurs. Les erreurs de ralisation se dtectent rapidement et se traduisent par une correction au niveau de la conception dtaille. Les erreurs dtectes en industrialisation production sont plus complexes et impliquent une mise en cause de la conception prliminaire et mme certaines spcifications. Les erreurs observes durant l'exploitation sont particulirement graves car elles concernent une mise en cause de l'adquation du produit au besoin. 3.4.3. Facteurs de Productivit L'efficacit est source de productivit. Elle dpend d'une varit de paramtres lis au problme, aux techniques et moyens mis en oeuvre, aux mthodes. La figure 3.9 indique le rsultat 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'exprience: langages, moyens et mme application. Le facteur essentiel est la comptence de l'quipe. Cette comptence est trs intimement lie aux mthodes utilises, d'o l'intrt conomique long terme d'un investissement pour la matrise de mthodes. M.C.S.E 31

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Exprience du langage Containtes de dlai Taille base de donnes Temps de rponse Exprience des moyens Evolution des moyens Outils logiciels Programmation haut niveau Contraintes taille mmoire Exprience de lapplication Contraintes temps rel Complexit du produit COMPETENCE DE LEQUIPE Productivit du Logiciel Paramtres affectant la productivit en developpement logiciel.

-Figure 3.9- Facteurs affectant le cot du logiciel. Les autres facteurs: contraintes de temps, fiabilit exige, complexit du produit, ont tout de mme une importance pour les systmes temps-rel. Une mthodologie doit donc permettre de grer la complexit tout en conduisant un produit possdant qualit, fiabilit et scurit exiges et respectant les contraintes de temps. 3.4.4. Rpartition de l'effort Pour atteindre son objectif, le concepteur a un minimum de travail entreprendre qui correspond au temps d'analyse, de synthse, de vrification, d'exprimentation. Toute variation par rapport ce minimum est grandement dpendante de la mthode utilise. En l'absence de mthode, une approche plutt intuitive conduit commencer rapidement la ralisation. La solution rsulte alors plus d'une dmarche par essais, erreurs et corrections. La dtection des erreurs et leurs corrections engendrent invitablement un surcrot en temps et argent. Dans l'hypothse d'une mthode, le dcoupage en tapes n'est pas suffisant. Il faut aussi s'intresser l'amplitude de l'effort pour chaque phase. Bien sr, la rpartition dpend de la nature du problme, mais aussi de la stratgie de dveloppement souhaite. Si certaines stratgies tendent tre connues travers les principes de l'approche structure 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 premires. En effet, les activits de spcification et de conception sont peu visibles et peuvent tre juges comme improductives. La tendance naturelle est de penser 32 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME qu'ingnieurs et techniciens sont plus efficaces et plus productifs lorsqu'ils sont affairs sur des cartes lectroniques ou sur leurs programmes que lorsqu'ils laborent au pralable des documents de spcification et de conception. Pour rduire au minimum possible le cot des erreurs et pour obtenir de l'efficacit en ralisation, l'effort doit tre port sur les premires phases savoir: la spcification puis la conception. La figure suivante montre 2 stratgies opposes. L'effort chaque instant exprime les ressources humaines attribues au dveloppement. L'intgrale de cet effort donne une image de l'investissement pour le projet.
Effort par unit de temps

effort important en spcification effort en ralisation

Phases

Spcification

Conception

Ralisation

Test

-Figure 3.10- Rpartition de l'effort. La courbe 1 correspond une dmarche traditionnelle pour laquelle un effort important est investi durant la phase de ralisation. Ceci correspond au fait qu'une grande partie du travail d'analyse finit par tre entrepris ce stade. La courbe 2 stipule la ncessit d'un effort important en spcification puis en conception. L'investissement suprieur en ressources ds les premires phases pour la courbe 2, est ensuite trs largement compens par une rduction du cot pour les phases de ralisation, test, production, maintenance. De l'analyse qui prcde, il s'en dduit qu'il est vital de contrler le mieux possible le processus de dveloppement. De surcrot, la planification, l'organisation, la direction, et le contrle du dveloppement sont aussi essentiels pour le succs du projet. 3.5. DEVELOPPEMENT POUR UN SYSTEME ELECTRONIQUE Aprs avoir analys quelques modles d'organisation pour le dveloppement d'un produit, ainsi que certains points essentiels qui influent sur le droulement, intressons-nous plus particulirement la procdure pour le dveloppement des systmes lectroniques pour les applications temps-rel, de manire caractriser le modle de dveloppement retenu pour MCSE. M.C.S.E 33

Partie 1 - PRESENTATION DE LA METHODOLOGIE Rappelons tout d'abord que les systmes lectroniques sont constitus de 2 grandes parties: -le matriel et le logiciel-, et que la cohrence des 2 parties est essentielle pour les systmes ddis. Ensuite, pour grer la complexit, un systme se dcrit suivant un ensemble de niveaux hirarchiques: dfinition, description externe, description sommaire, description dtaille. Pour tenir compte de ces aspects, le dveloppement d'un projet doit tre vu comme un ensemble hirarchique de dveloppements. Au sommet, les premires phases concernent la spcification et la dfinition prliminaire du systme global. Ceci permet de mettre en vidence des sous-ensembles. Chaque sous-ensemble correspond un domaine plus restreint de problme, et se dveloppe alors de la mme manire en commenant par sa spcification. Les dveloppements de sous-ensembles peuvent se faire en parallle. Ainsi, le processus de dveloppement pour un systme lectronique peut se reprsenter comme suit. Cette figure indique que la conception suit des niveaux hirarchiques qui vont du fonctionnel au physique.
SYSTEME

dfinition ralisation Problme Etude Cahier Spcification prliminaire des charges conception fonctionnelle
Sous-ensemble i

Assemblage Test Validation

Produit

SOUS-ENSEMBLE

Domaine de

MCSE

dfinition ralisation Spcification conception fonctionnelle Matriel Logiciel

Intgration Test

MATERIEL

LOGICIEL

Dfinition Ralisation Spcification conception


composant i carte i

Assemblage Test

conception Spcification fonctionnelle

Dfinition Ralisation
Tache i Module i

Assemblage Test

CARTE , COMPOSANT

TACHE , MODULE

Spcification conception

Ralisation

conception Spcification conception prliminaire dtaille

Test unitaire

-Figure 3.11- Modle hirarchique pour le dveloppement d'un systme. Durant le premier stade de la conception, un systme complexe est dcompos en sousensembles interconnects. La conception de chaque sous-ensemble conduit mettre en vidence une partie matrielle et une partie logicielle. Toujours en passant par une spcification puis une conception, la partie matrielle est dcompose en un ensemble de fonctions ou composants. Les composants, s'ils existent, sont directement utilisables, sinon il s'agit de les concevoir. La hirarchie pour le dveloppement du matriel s'arrte lorsque tous les 34 M.C.S.E

Ch 3 - CYCLE DE DEVELOPPEMENT DUN SYSTEME composants retenus existent. La ralisation est alors possible, puis progressivement l'assemblage et le test en remontant la hirarchie. De mme la partie logicielle est dcompose en tches ou modules. Chaque partie se dveloppe selon une dmarche descendante: conception et programmation structure. Les modules cods sont tests puis assembls. Cette prsentation suggre un certain nombre de remarques. - Observant la hirarchie, on constate que toute ralisation est un constituant dvelopp comme un tout mais intgrable dans un ensemble plus complexe. - Chaque constituant se dveloppe selon un processus iteratif: analyse, synthse, vrification, et si ncessaire correction par retour arrire. - Pour chaque constituant, on retrouve les phases de spcification, de conception, de dfinition de la ralisation, d'assemblage et de test. Ainsi, la terminologie: spcification, conception, ralisation- n'est pas lie au niveau de description. Une grande confusion existe sur la dfinition de ces termes particulirement entre spcification et conception. On retiendra ds prsent que , dune manire gnrale, 'une spcification concerne une vue externe de l'objet considr, tandis que les phases ultrieures concernent l'intrieur, donc la solution. - Si au sommet de la hirarchie l'approche est globale (approche systme), en descendant dans la hirarchie, le concepteur d'un constituant devient de plus en plus spcialiste d'un domaine et d'une technique de ralisation: par exemple, conception d'un composant ASIC pour le filtrage d'un signal, ou dveloppement d'un programme effectuant une transforme de FOURIER rapide... - Les dveloppements de constituants peuvent se faire en parallle. La contrainte ncessaire est d'tre capable d'laborer la spcification de chaque constituant pour permettre l'intgration ultrieure. Une dmarche ascendante est aussi possible. Elle consiste alors laborer un constituant pour son utilisation ultrieure. Il faut dans ce cas s'assurer que le constituant est intgrable dans un ensemble plus vaste. - Un systme ne devient oprationnel que lorsque tous ses constituants sont raliss et tests. Le constituant le plus complexe est le systme lui-mme. La ralisation est donc un processus ascendant. Pour un objectif atteindre une date donne, une planification (diagramme PERT par exemple) du projet n'est possible qu'une fois effectue toute la dcomposition. Une modlisation prcise du processus de dveloppement est donc bien utile pour la planification et donc la conduite de projet. 3.6. DOMAINE DE MCSE La figure prcdente permet aussi de prciser le domaine et les niveaux de dveloppement couverts par MCSE. Il s'agit bien d'une mthodologie globale puisqu'elle considre comme point de dpart le besoin exprim par un cahier des charges. Elle couvre les phases de spcification, de conception et de dfinition des ralisations aussi bien au niveau systme que pour les parties matrielle et logicielle. M.C.S.E 35

Partie 1 - PRESENTATION DE LA METHODOLOGIE Toutefois, comme indiqu au dbut du chapitre, elle ne couvre pas la phase initiale ou phase de dfinition du projet, qui concerne l'valuation de la faisabilit, une analyse de la valeur, la ngociation. Le point de dpart est l'existence d'un produit dvelopper dfini par des objectifs, un cot et des dlais. Toutefois, la matrise de la mthodologie propose peut grandement faciliter l'tude prliminaire. Elle ne couvre pas non plus les derniers niveaux de conception qui concernent la ralisation de fonctions spcifiques. Pour le matriel, il peut s'agir de composants ou sous-ensembles qui requirent une comptence spcifique d'un domaine: lectronique de puissance, lectronique analogique... Pour le logiciel, il s'agit du dveloppement de programmes raliss individuellement (programming-in-the-small par opposition programming in the large [NIELSEN-88]). MCSE ne concerne pas les niveaux relativement proches de la ralisation, ceci n'est pas un inconvnient, puisque dj 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 mthodologie conduit laborer les documents ncessaires en entre de ces outils, ce qui est le point essentiel. Il ne s'agit pas non plus d'une mthodologie pour la conduite de projets. Les tches de management pour un projet: planification, organisation, dotation en personnel, direction et contrle, ne sont pas explicites dans MCSE, mais bien entendu, le modle hirarchique propos pour le dveloppement est trs utile comme base pour l'laboration d'une stratgie de conduite de projets. Le domaine d'intrt de MCSE est donc essentiellement le dveloppement de systmes et tout particulirement la spcification et la conception, et ceci pour les niveaux: systme ou application globale, architecture matrielle, architecture logicielle.

36

M.C.S.E

Chapitre 4

BASES POUR UNE METHODOLOGIE

Une mthodologie va au-del d'un simple dcoupage du travail en tapes. Pour aboutir une comprhension correcte et complte de MCSE et avant de s'intresser ses caractristiques, il est utile d'avoir l'esprit ce que veut dire et ce qu'implique le terme mthodologie. Plusieurs aspects sont dvelopps dans ce chapitre. Tout d'abord concevoir est une activit humaine avec tous ses avantages et inconvnients. Ensuite, une mthode ne dcrit pas une solution, mais comment aboutir un rsultat. Toute mthode est donc dpendante de la nature de la solution trouver; ceci induit la ncessit d'un modle de description de toute solution. Ainsi, ce chapitre montre la complmentarit: modles, mthodes, techniques et outils en conception. L'ensemble une fois organis constitue une mthodologie. 4.1. TERMINOLOGIE Dfinissons tout d'abord les termes utiliss dans ce document qui, sans explication, pourraient prter confusion. 4.1.1. Problme: dfinition, rsolution Le terme PROBLEME est toujours relatif un sujet, une situation. Autour de ce terme existent 2 classes d'activits: la dfinition du problme (Que veut-on?, que faut-il? le WHAT), la rsolution du problme (Comment peut-on le faire? le HOW).

M.C.S.E

37

Partie 1 - PRESENTATION DE LA METHODOLOGIE Un problme peut tre bien dfini ou mal dfini. Lorsqu'il est bien dfini, seule existe l'activit de rsolution: c'est le travail du concepteur. Par contre, pour un problme mal dfini, les 2 activits sont ncessaires. Il faut tout d'abord commencer par dfinir le problme pour pouvoir ensuite le rsoudre. Rsoudre un problme consiste analyser la situation dans laquelle existe le problme, dduire des dcisions possibles sur ce qu'il faut faire ou ne faut pas faire, puis dcider d'une solution. 4.1.2. Modle et modlisation La modlisation est une activit que nous faisons tous, consciemment ou inconsciemment. Elle prcde toute dcision ou formulation d'une opinion. Ce n'est pas une fin en soi. Elle doit servir rpondre la question initiale pour laquelle un modle est dvelopp. Un MODELE est une interprtation explicite par son utilisateur de la comprhension d'une situation, ou plus simplement de l'ide qu'il se fait sur une situation. Il peut tre exprim par des mathmatiques, des symboles, des mots, mais essentiellement, c'est une description d'entits et de relations entre elles. Ainsi, modliser revient laborer une vue partielle plus ou moins abstraite de l'existant [WILSON-86]. 4.1.3. Mthode et mthodologie Une mthode ou technique de rsolution de problme est caractrise par un ensemble de rgles bien dfinies qui conduisent pour le problme une solution correcte. Une mthodologie, terme plus large que mthode, est un ensemble structur et cohrent de mthodes, guides, outils permettant de dduire la manire de rsoudre un problme. Une mthodologie conduisant utiliser des techniques permet de dterminer si une technique particulire est approprie ou non. Elle rsulte donc de l'agrgation de mthodes et de techniques de divers domaines. Une mthodologie de conception exprime plus particulirement le cheminement par tapes successives et les outils qui permettent de dvelopper avec efficacit une solution pour le problme pos et qui respecte des critres 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 dcisions. Ralise par l'homme, c'est une activit individuelle cratrice, qui se base sur l'utilisation d'acquis et non sur l'intuition [JENSEN-79]. Toute dmarche normale consiste : formuler le problme, analyser le problme pour faire apparatre suffisamment de dtails, rechercher des solutions potentielles, dduire la solution la plus approprie en valuant et comparant des solutions entre elles, - dcrire en dtail la solution retenue. L'acquis concerne 2 catgories 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 proprits de l'existant. - les mthodes et techniques. Elles s'acquirent et s'assimilent aussi trs progressivement en rsolvant des problmes. Ces 2 catgories a priori trs loignes sont complmentaires et indispensables pour l'activit de dveloppement: les connaissances apportent les informations ncessaires pour prendre des dcisions, tandis que mthodes et techniques structurent la squence des dcisions. Ainsi comme le montre la figure ci-dessous, l'activit de conception est assimilable un processus de transformation, exprim par un ensemble d'actions lies, ncessaires pour passer du problme une solution.
CONNAISSANCES DU DOMAINE METHODES ET TECHNIQUES

PROBLEME

SOLUTION

Rsolution du problme

Acquis

Exprience

-Figure 4.1- Processus de rsolution de problmes. La rsolution de problmes amliore l'acquis en enrichissant l'exprience. Celle-ci a la particularit d'tre rutilisable. Disposer de connaissances, mthodes et techniques nest pas suffisant, l'important pour un concepteur est de savoir utiliser lensemble judicieusement compte-tenu du problme. L'exprience reprsente cette comptence. Comme elle est personnelle, chaque concepteur ne l'acquiert que par un travail individuel. Pour rsoudre des problmes, le concepteur doit avoir des qualits minimales que sont: - l'aptitude raisonner qui est important pour l'analyse et la prise de dcision, - l'aptitude acqurir des connaissances: curiosit, esprit de synthse, - l'aptitude communiquer, car il s'agit de rsoudre le problme du demandeur. Comme l'activit de conception est individuelle, le problme doit tre dcompos jusqu' un stade accessible par chacun et tel que la communication soit possible. Pour un mme projet, toutes les contributions doivent pouvoir s'intgrer, ce qui est l'objet d'une mthodologie, d'une dmarche, de procdures. M.C.S.E 39

Partie 1 - PRESENTATION DE LA METHODOLOGIE De plus, particularit de l'activit humaine, elle est source d'erreurs. Des vrifications sont donc ncessaires pour rduire les erreurs de conception. Une autre manire diffrente mais complmentaire, de voir l'activit de conception est de considrer qu'elle est dcomposable en 2 sous-ensembles coupls [WILSON-86]: - un systme d'activits, reprsentatif des mthodes, techniques, ou d'une mthodologie, - un systme social, reprsentatif des participants l'activit de conception. Ce point de vue est parlant, car il suggre qu'avec un systme d'activits satisfaisant, les rsultats peuvent tre mauvais. Inversement, sans systme d'activits, il est possible d'obtenir des rsultats mais srement avec moins de garantie. Un rsultat satisfaisant n'est possible que si le systme social et donc les individus en tant que concepteurs utilisent correctement les mthodes ou techniques. Ainsi, lorsqu'une mthodologie est juge ncessaire, une responsabilit supplmentaire incombe alors l'organisation qui a en charge l'quipe. Sans une forte volont interne, les chances de succs sont rduites. 4.2.2. Le processus de conception Pour caractriser une mthodologie, il s'agit de modliser 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 intermdiaire sont de 2 natures: - des donnes formelles (m): spcification, diagrammes, schmas, composants... - des donnes moins formelles (c): texte, description, contraintes... Au dbut d'un projet les informations disponibles sont toutes de nature informelle. Durant la conception, elles sont progressivement transformes en donnes formelles, certaines restant encore informelles. Celles-ci sont appeles contraintes puisqu'elles agiront plus tard sur le rsultat final. Ainsi, concevoir consiste accrotre, tape par tape, le niveau de dtail de la description formelle, en intgrant progressivement les contraintes dcrites par la partie informelle, jusqu' faire disparatre toutes les contraintes. De cette manire, la solution finale est observable comme un ensemble de niveaux hirarchiss correspondant la squence des descriptions. A chaque transition entre 2 niveaux de description correspond une tape, comme le montre la figure 4.2. Mi compose de mi et ci est la description de la solution pour le niveau i. Une spcification (S) est considre comme une description formelle du besoin et les proprits et contraintes du systme, tandis qu'une ralisation (R) (ou solution) est une description formelle d'une structure de constituants qui satisfait ces spcifications. La transformation S-->R ncessite de la part du concepteur l'utilisation de connaissances Ki et de mthodes Di. La vrification de conformit de R vis vis de S est une condition essentielle pour rduire les erreurs. L'enchanement des tapes impose qu'une ralisation en sortie d'une tape soit utilisable comme spcification pour l'tape suivante. Selon cette modlisation, on constate bien que le travail durant la conception est plutt de nature crative. 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 prcdente (mi,ci)


Spcification

Mi+1 = Di (mi+1,ci+1)
Ralisation

Etape suivante

Ki

CONNAISSANCES

-Figure 4.2- Une tape durant la conception. 4.2.3. Raffinement et abstraction La dmarche pour passer d'un niveau de description un autre est possible dans les 2 directions, l'une vers un accroissement des dtails (raffinement), l'autre vers la rduction de dtails (abstraction). Pour chaque direction, on peut exprimer des rgles de drivation d'une solution qui peuvent servir comme base pour une mthode: pour le raffinement: - miroir: un modle de l'environnement est plac dans le systme, - enrichissement: des descriptions sont ajoutes l'tat courant, - dcomposition: des fonctions sont dcrites par des sous-ensembles plus lmentaires, - association: il s'agit d'une composition qui suit un travail de dcomposition et/ou d'enrichissement. Ainsi raffiner une description consiste augmenter le niveau de dtail par ajot d'informations supplmentaires qui interviennent ultrieurement comme des contraintes pour la ralisation. pour l'abstraction: - simplification: (oppos enrichissement), des descriptions sont retires pour rduire la complexit. - composition (oppos dcomposition), plusieurs ensembles de descriptions sont combins en un seul. - rduction: des descriptions sont remplaces par une description quivalente moins dtaille. La dmarche par abstraction permet de dcrire un lment par une vue purement externe pour le rendre utilisable dans un ensemble un niveau de description plus lev. La technique du raffinement favorise une dmarche DESCENDANTE du problme vers la solution dtaille, tandis que la technique d'abstraction se justifie plutt comme dmarche ASCENDANTE. M.C.S.E 41

Partie 1 - PRESENTATION DE LA METHODOLOGIE 4.3. CARACTERISTIQUES DUNE METHODOLOGIE Une mthodologie est donc tout d'abord l'expression d'un cheminement par tapes, qui permet d'atteindre l'objectif avec efficacit et en respectant des critres de qualit. Le processus de dveloppement est dcompos en tapes. Le rsultat observable entre 2 tapes permet sa vrification ce qui est essentiel pour liminer au plus tt les erreurs invitables induites par l'activit humaine. Dans ce chapitre, il a t montr que le processus de conception consiste trouver une description plus dtaille partir des donnes d'entre prises comme spcifications. A partir de ces bases, prcisons les caractristiques d'une mthodologie. 4.3.1. Modle de description Observant que l'enchanement des tapes n'est possible que si le rsultat en sortie d'une tape est utilisable comme spcification pour l'tape suivante, et qu'un niveau de description qui rsulte d'une tape est un raffinement du niveau prcdent, une mthodologie globale allant d'un problme sa ralisation est obligatoirement base sur un modle de description hirarchique. Le modle pour chaque niveau de description joue alors le rle 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 spcifications pour l'tape i. Ainsi la description de la solution retenue Ri doit tre conforme au modle de description MDi. Si+1 correspond tout ou partie de Ri. Comme remarque, notons que toute solution respectant le modle possdera les caractristiques et proprits du modle.

MD1 S1

Modle de description

Etape 1
C1 R1

niveau 1

Description
MD2 S2

Etape 2
C2 R2

niveau 2

-Figure 4.3- Enchanement d'tapes et niveaux de description. 42 M.C.S.E

Ch 4 - BASES POUR UNE METHODOLOGIE Pour un systme, la premire description, celle la plus abstraite, est une vue purement externe appele spcification et la description la plus dtaille est celle de la ralisation complte. Une fois le modle de description d'un systme dfini, le schma mthodologique comme expression d'un enchanement d'tapes se dfinit aussi par un modle de description qui est alors le modle de dveloppement. Ce dernier rsulte du premier et pas l'inverse. 4.3.2. Mthode et technique pour chaque tape Spcifier, concevoir, c'est dduire une description partir d'une prcdente plus succincte et d'informations complmentaires comme contraintes. Le rsultat en sortie doit tre conforme au modle de description pour le niveau. Pour cela, la dduction ncessite d'utiliser des rgles, un guide, des conseils qui prcisent les contraintes prendre en compte chaque stade pour les introduire dans la solution. Des critres de dcision sont aussi ncessaires pour rpondre aux divers choix. Ainsi, une ou des mthodes sont associes chaque tape, tandis que l'enchanement des tapes dfinit le schma global de la mthodologie. 4.3.3. Modles de solutions Le processus de conception est une activit humaine. Si parfois, la solution rsulte de pures transformations, il reste une part importante de travail cratif. 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 ides de solutions adaptes au problme. Il est donc intressant de pouvoir disposer de modles de solutions, aussi appels dans ce document modles gnriques, car ils permettent d'induire une varit de solutions, chacune spcifique au problme rsoudre et se dduisant de l'objectif satisfaire. Si les aspects prcdents: modle de description, mthodes, sont classiques, l'intrt des modles gnriques nous est apparu rcemment travers des expriences pdagogiques. Le rsultat est trs prometteur. De plus, en regardant l'avenir, de mme que l'accroissement de la productivit passe par une automatisation de la production des produits et plus en amont des descriptions des solutions, de mme l'automatisation d'une tape ncessite invitablement de baser un outil de production sur un ou des modles de solutions. La mthodologie MCSE prsente dans le chapitre suivant est base sur ces concepts: modle de description d'un systme en 3 dimensions, modle de dveloppement en 4 tapes, mthode associe chaque tape, modles de solutions comme aide au concepteur.

M.C.S.E

43

Chapitre 5

PRESENTATION DE MCSE

Ce chapitre dcrit les lments caractristiques et la dmarche de la Mthodologie MCSE. Tout d'abord, se trouve prsent le modle retenu pour la description de tout systme. Sur la base de ce modle sont ensuite dcrites les tapes de la mthodologie. Un premier bilan sur les points essentiels de MCSE termine ce chapitre. Au pralable, rappelons la dmarche progressive naturellement ascendante faite durant 10 ans pour amener cette mthodologie sa maturit, en situant les stades caractristiques de la rflexion. 5.1. DEVELOPPEMENT DE LA METHODOLOGIE La mthodologie prsente couvre aujourd'hui les phases de Spcification, de Conception Fonctionnelle aussi appele par ailleurs Conception Prliminaire, de dfinition de la Ralisation ou Conception Dtaille. Le point de dpart de ce dveloppement vers 77,78 portait essentiellement sur l'tape de Conception. Dfinir une procdure de conception ncessitait au pralable de dvelopper un modle de description pour toute application et systme temps-rel. Ce modle explicit en 80 est un modle en 3 dimensions: fonctionnel, temporel, excutif. Il a permis de montrer son intrt comme base pour le dveloppement d'une application par raffinements successifs des besoins jusqu' une solution de ralisation incluant du matriel et du logiciel, et rpondant divers critres.

M.C.S.E

45

Partie 1 - PRESENTATION DE LA METHODOLOGIE Avec du recul, il est intressant de constater que le modle retenu est un invariant. Son adquation s'est progressivement confirme travers le dveloppement, pour des industriels, de multiples types de problmes. La rflexion s'est ensuite porte sur le raffinement des dmarches suivre pour trouver une solution possdant des qualits techniques et conomiques. L'tape de Conception ne peut pas non plus tre isole des tapes situes en amont et en aval. En amont, les rflexions ont conduit dvelopper la dmarche pour aboutir un document de spcification utilisable avec efficacit pour la Conception. La mthode de Spcification est base sur une premire approche par la modlisation de l'environnement du systme. Une telle approche facilite grandement par la suite, la dmarche lors de la conception. En aval de la conception, nous avons port notre intrt sur les diffrentes techniques de ralisation de manire expliciter la dmarche qui conduit, partir d'une conception fonctionnelle, choisir la technique de ralisation la plus approprie (type de technologie, rpartition matriel/logiciel, respect des contraintes de temps...). Une large exprimentation de la mthodologie a montr l'importance du modle de description, puis l'importance des rgles et conseils qui engendrent chez les concepteurs des solutions de qualit. Ces dernires annes, dpassant ce stade, nous avons constat, que les solutions de qualit peuvent s'exprimer sous la forme de modles gnriques. Ainsi, la connaissance de tels modles gnriques de solutions pour diverses classes de problmes facilite la tche du concepteur et favorise la production de solutions de qualit au sens lisibilit, maintenabilit, efficacit... et donc cot. La mthodologie de conception MCSE a spcialement t dveloppe pour les applications temps-rel en contrle/commande. Applique de multiples problmes industriels, elle a ainsi pu tre valide. Il en est rsult une bonne adquation du modle la problmatique traite et un intrt certain de la phase de dfinition de la ralisation qui propose une dmarche systmatique pour le choix de la rpartition matriel/logiciel. Si cette mthodologie concerne plus particulirement le domaine des systmes lectroniques temps-rel, il se trouve que la dmarche suivie pour les premires phases du dveloppement: -spcification, conception architecturale- se trouve indpendante de la ralisation, puisqu'il s'agit d'une approche SYSTEME. Des expriences intressantes ont t menes quant son utilisation pour des applications varies: systmes de contrle/commande, rseaux et protocoles, systmes rpartis, outils interactifs, conception de composants intgrs. Elle est utilise de manire systmatique pour la spcification et la conception de systmes, sur la demande d'industriels ou de laboratoires de recherche. On peut citer entre autres les tudes suivantes: - Conception d'un systme lectronique pour la programmation et le contrle/commande de centrifugeurs haut de gamme. - Etude de faisabilit d'une solution totalement numrique pour la commande de convertisseurs continu-continu. - Ralisation d'un systme de test automatique de 6 batteries. Une autre version pour 64 batteries a ensuite t dveloppe. - Systme d'acquisition de donnes pour le contrle de chanes d'ancrage pour plateformes ptrolires. 46 M.C.S.E

Ch 5 - PRESENTATION DE MCSE - Conception d'un systme de gestion technique centralise et de rgulation d'un grand btiment avec mise en place d'un rseau local. Ces problmes sont de taille et complexit varies. Le systme de gestion technique centralise concernait la gestion simultane de 600 entres/sorties. 5.2. LE MODELE DE DESCRIPTION MCSE est base sur l'ide simple que tout systme (sa vue interne, c'est--dire le Comment) est observable selon 3 vues: - une vue fonctionnelle, qui caractrise les fonctions internes du systme, - une vue temporelle, dcrivant l'volution des fonctions internes exprimant ainsi la contribution de chacune d'elles, - une vue matrielle, spcifiant la partie physique du systme. Pour illustrer cette ide, considrons le cas d'un systme de commande pour le chauffage d'un btiment. La vue fonctionnelle fait apparatre les fonctions de dialogue, de supervision du btiment, de rgulation de chaque zone... Ces fonctions sont couples entre elles pour satisfaire l'objectif : change de messages pour le planning de chauffe, accs des grandeurs caractristiques que sont temprature extrieure, temprature d'eau... La vue comportementale explique la contribution de chaque fonction. Par exemple, la rgulation 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 : temprature de consigne, Ti: temprature intrieure, Tex: temprature extrieure, Texprec: temprature extrieure pour la mesure prcdente. La vue matrielle est un ensemble de systmes microprocesseurs coupls entre eux par une paire bifilaire utilise comme bus commun. Chaque vue ne suffit pas elle seule pour comprendre compltement le systme. Chacune explique un aspect particulier et ainsi apporte une dimension supplmentaire d'information pour dcrire le "comment" du systme. Ces 3 vues s'avrent ncessaires et complmentaires. Ainsi, le modle conceptuel retenu est 3 composantes [CALVEZ-82]: - la composante structurelle, dcrite par le modle fonctionnel (ou structure fonctionnelle), - la composante comportementale, qui dcrit, par des modles temporels, le comportement des constituants fonctionnels. - la composante excutive, dcrite par une structure dite d'excution, qui exprime les constituants matriels et les interconnexions ncessaires pour le fonctionnement du systme. Les 2 premires composantes dcrivent la structure et le comportement d'un systme en faisant abstraction des techniques et mthodes de ralisation. La description rsultante, appele DESCRIPTION FONCTIONNELLE, se veut indpendante des techniques de ralisation retenir ou imposes. M.C.S.E 47

Partie 1 - PRESENTATION DE LA METHODOLOGIE La troisime composante dcrit les moyens informatiques et lectroniques mis en oeuvre pour engendrer l'volution dcrite par la description fonctionnelle, tout en satisfaisant toutes les contraintes temporelles, techniques et technologiques de l'application. La figure suivante prsente ce modle 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 excutive
P2

P1 S1

M1 M2

P3 N1 P4 M1

Structure dexcution

Signification des symboles


Structure fonctionnelle VARIABLE PARTAGEE Structure dexcution MEMOIRE

EVENEMENT

SIGNAL

ACTION

PROCESSEUR

PORT

NOEUD DE COMMUNICATION

-Figure 5.1- Le modle 3 dimensions. Cette figure montre que, lassociation structure fonctionnelle et comportement des fonctions est intgre sur le support d'excution selon une correspondance appele intgration ou allocation. Dcrivons succinctement chacune des composantes du modle. 48 M.C.S.E

Ch 5 - PRESENTATION DE MCSE 5.2.1. Le Modle fonctionnel Le modle fonctionnel est une structure construite l'aide de fonctions et de relations entre celles-ci. Une fonction dans sa signification usuelle dsigne l'entit assurant une activit spcifique du systme. La dcomposition en fonctions correspond un dcoupage "topologique" et non un dcoupage temporel des activits de l'application. Entre les fonctions, les relations retenues sont particulirement adaptes pour les systmes temps-rel. Elles sont de 3 types: - la relation de SYNCHRONISATION, matrialise par un vnement. Elle sert dfinir l'ordre total ou partiel selon lequel les diffrentes fonctions doivent intervenir dans l'activit globale du systme. Les instants d'intervention correspondent l'apparition d'vnements qui expriment gnralement des changements d'tat du systme. Ce type de relation convient particulirement bien la description des applications pilotes par les vnements (event-driven). - la relation par partage de VARIABLE (variable d'ETAT). Plusieurs fonctions peuvent, par ce type de relation, connatre une information par consultation, ou modifier instantanment la valeur de cette information. Il s'agit d'une relation importante pour les applications temps-rel, en particulier pour le couplage de procds physiques avec un systme de commande. En effet, certaines fonctions doivent avoir une influence immdiate sur leur environnement, ou une connaissance prcise et instantane de l'tat de cet environnement. - la relation de TRANSFERT DINFORMATION, 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 proprit 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 ncessaire qui lui sera transmise sous la forme d'un message. On peut donc dire que l'activit lie une fonction est synchrone un type particulier d'vnement signalant la disponibilit d'une information. Ce type d'change engendre une relation d'ordre total pour l'activit des fonctions consquentes. Les fonctions considres dans ce modle peuvent tre aussi bien des fonctions lmentaires que des fonctions complexes. Par raffinements successifs, une fonction COMPLEXE se dcompose sous la forme d'une structure. Les fonctions et relations sont celles ncessaires pour satisfaire l'objectif et ne concernent nullement les aspects technologiques. Une bonne description fonctionnelle se doit d'tre indpendante de la technologie. La figure 5.2 illustre ce modle pour lexemple du systme de commande de chauffage. La nature graphique le rend particulirement intressant pour une comprhension globale rapide du modle. La solution est constitue d'une fonction de Supervision lie l'exploitant, et autant de fonctions de Rgulation que de zones de chauffe contrler. M.C.S.E 49

Partie 1 - PRESENTATION DE LA METHODOLOGIE

ordre
Exploitant

Rponse
Exploitant

GESTION - CENTRALISEE

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

Consigne [ 1..n ]

Milieu extrieur

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 modle, qui permet l'abstraction et le raffinement de structure, est du type hirarchique. Cette composante structurelle permet aussi de reprsenter en complmentarit 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 donnes et les dpendances temporelles du niveau. L'intrt des 3 types de relations, plutt que par exemple une version unifie par messages, est son adquation pouvoir dcrire simultanment des comportements du type event-driven et data-driven ainsi que les couplages directs aux processus physiques. 5.2.2. Le modle comportemental Ce modle dcrit la contribution de la fonction pour son environnement. Il s'agit donc de sa spcification. Une fonction est comprendre comme un oprateur de transformation des entres en sorties. Dcrite par un modle comportemental, son volution est obligatoirement squentielle et cyclique. Tous les types de modles temporels squentiels sont utilisables: diagramme tats finis, grafcet, algorithme. Chaque fonction assure une transformation la fois. 2 types de comportement sont considrs: - une volution PERMANENTE: sans entre d'activation par vnement ou message, la fonction joue en permanence son rle de transformation. Il s'agit donc d'une fonction permanente. - une volution TEMPORAIRE: la fonction assure son rle chaque apparition d'une entre du type vnement 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 donne pour la rgulation de temprature pour chaque zone. Celle-ci est pilote par une horloge pour dfinir le pas d'chantillonnage.
Tc

TE

REGULATION
TI

action HORLOGE (sortie vnement PAS); const Dure = 1 mn ; begin cycle : begin attente ( Dure ) ; signal ( PAS ) ; CV end ; end cycle ; end HORLOGE ; action REGULATION sur vnement PAS avec (entre var TC, TE, TI : temprature; sortie var CV : 0 .. CVmax ); const K1, K2, K3 . . . . ; var TE_PREC : temprature ; 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 rgulation. Lvolution permanente est exprime par linstruction CYCLE: <Instruction> endcycle; et lvolution temporaire par linstruction CYCLE <ev>: <Instruction> endcycle;. Une telle description est formelle, et donc vrifiable, et permet de passer rapidement une ralisation, particulirement lorsqu'il s'agit d'une implantation logicielle. 5.2.3. Le modle excutif Ce modle joue le rle d'une spcification de la partie matrielle. Il est bas sur le fait que toute ralisation pour un systme lectronique est compose: - de processeurs comme organe de transformation des informations et de prise de dcision, - de mmoires, pour la conservation des donnes, - de noeuds de communication comme lments intermdiaires pour le transit d'informations. Lis entre eux, ces 3 types d'lments technologiques conduisent dcrire une solution matrielle par une structure appele STRUCTURE D'EXECUTION. Les changes entre processeurs se font: - par signalisation inter-processeurs pour un couplage direct, - par un partage de mmoire pour un couplage indirect, - par l'intermdiaire d'un rseau de noeuds de communication pour le transfert de messages. M.C.S.E 51

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les termes processeur, mmoire, noeud de communications sont prendre dans leur sens le plus gnral. Un processeur est programmable comme le microprocesseur par exemple, ou spcifique tel qu'un ampli oprationnel ou un convertisseur numrique analogique. Une mmoire peut se limiter un simple registre, mais peut aussi tre un support de masse. Un noeud de communication peut tre rduit une ligne RS232 ou reprsente un noeud d'un rseau tlmatique. La figure suivante donne l'exemple d'une structure d'excution 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 srie 1 IT pour H CVn
Adaptation en courant

Sortie 4 . . 20 mA

-Figure 5.4- Structure d'excution pour le chauffage. Le modle pour la composante excutive est similaire celui propos pour la composante fonctionnelle, mais avec une signification diffrente des fonctions et des relations. L'existence de cette troisime dimension permet de rechercher ou d'exprimer pour chaque application, le support matriel le plus appropri. La similitude de modle permet de procder par dduction en dfinissant la structure d'excution comme une rduction partir de la structure fonctionnelle. 5.2.4. Intrt de cette modlisation Ce modle 3 composantes permet une description favorisant la comprhension progressive d'un systme en s'intressant tout d'abord aux relations entre les fonctions internes ncessaires pour satisfaire les objectifs, puis au comportement de chacune d'elles et en final aux ressources gnratrices du fonctionnement du systme. Il permet de structurer la prsentation d'un systme selon une hirarchie de 4 niveaux: - la description externe, comme niveau 0. Elle exprime, avant toute forme de solution interne, les spcifications compltes de l'application. 52 M.C.S.E

Ch 5 - PRESENTATION DE MCSE - la description fonctionnelle, comme niveau 1. Base sur le modle fonctionnel et l'expression du comportement des fonctions internes, elle prsente la solution selon une description indpendante de la technologie. - la description excutive, comme niveau 2. Elle rsulte de l'association de la description du niveau prcdent avec une structure d'excution choisie ou impose comme support matriel. - la description finale, comme dernier niveau o apparaissent les descriptifs des matriels et logiciels de l'application. La description fonctionnelle, qui est une description oriente application ne tient pas compte des caractristiques technologiques. Ainsi, une telle solution favorise ensuite une nouvelle implantation lors de changements technologiques. La description excutive est l'association des 3 composantes lies entre elles par l'allocation qui dcrit l'implantation de la description fonctionnelle sur le support excutif. Le principe est qu'une partie de la description fonctionnelle est implante sur chaque processeur. Lorsque le processeur est programmable, l'implantation du sous-ensemble de la structure fonctionnelle sur ce processeur est dcrit par un schma d'implantation logicielle. La prsentation en niveaux de description accrot la lisibilit et en consquence la maintenabilit. De plus, elle est utilisable comme base pour le dcoupage en tapes de la dmarche de dveloppement. Le modle se prte aussi la description des systmes complexes, car il possde la proprit d'invariance d'chelle: composant ASIC ou application multiprocesseurs, simple ralisation microprocesseurs ou systme tlmatique complexe. 5.3. LA DEMARCHE La dmarche de conception est base sur l'emploi du modle ci-dessus. Elle exprime le processus de rflexion que doit suivre le concepteur pour aboutir une description conforme au modle, tout en rpondant des critres de qualit: robustesse, modularit, lisibilit, maintenabilit. Chaque niveau de description sert d'intermdiaire entre 2 tapes successives. Le dveloppement s'effectue selon 4 tapes: - llaboration des spcifications, de manire exprimer partir du besoin une vue purement externe du systme (WHAT). - La conception fonctionnelle, qui a pour objectif de trouver la description fonctionnelle, compose des 2 premires composantes du modle (HOW). - La dfinition de la ralisation (aussi appele conception dtaille), le but tant de trouver une structure d'excution ainsi qu'une implantation logicielle sur la structure matrielle retenue, en considrant toutes les contraintes technologiques: contraintes de rpartition, contraintes de temps, contraintes lectriques... - La ralisation conduisant un systme oprationnel. M.C.S.E 53

Partie 1 - PRESENTATION DE LA METHODOLOGIE La figure suivante dcrit l'enchanement de ces 4 tapes.


Abstrait Modles Spcification
SPECIFICATION

Cahier des charges

Niveau 1 Spcifications fonctionnelles et opratoires

Spcifications Modle fonctionnel


CONCEPTION FONCTIONNELLE

Niveau 2

Description fonctionnelle Modle dxcution

Spcifications technologiques

DEFINITION de la REALISATION

Niveau 3

Description excutive

PRODUIT

Spcifications technologiques de ralisation Niveau 4


Concret

REALISATION

Temps

-Figure 5.5- Enchanement des tapes pour MCSE. Pour chaque tape, le concepteur dispose en entre: de la description d'un niveau intermdiaire comme rsultat de l'tape prcdente, de renseignements complmentaires que sont les contraintes imposes dans les spcifications. L'tape produit une description pour le niveau suivant. Une vrification de conformit est possible l'issue de chaque tape. Dans les paragraphes suivants et sans entrer dans les dtails, nous passons en revue les diffrentes tapes de la mthodologie en prcisant les principes. 5.3.1. Elaboration des spcifications Pour pouvoir concevoir, il faut tout d'abord disposer des spcifications. Par spcifications, il faut entendre une description complte mais purement externe du systme concevoir. Plus ces spcifications sont dtailles et conformes des modles formels, plus il est facile de dduire une solution. Mais la spcification doit aussi tre vrifiable, en particulier par le demandeur. Le point de dpart est le cahier des charges dcrivant le besoin du demandeur. Pour dcrire ce que doit faire un systme, celui-ci est considr comme observant et agissant sur les objets de son environnement. Il faut donc tout d'abord connatre cet environnement. Le connatre, c'est dans un premier temps modliser les objets sans le systme, et dans un second temps, expliciter les relations entre eux sous la forme d'une description fonctionnelle. Ensuite, expliciter le rle du systme et donc exprimer ses spcifications consiste noncer et caractriser les fonctions demandes. Ceci se fait en dtaillant le comportement souhait des objets de l'environnement sous le contrle du systme, ainsi que toutes les contraintes imposes. 54 M.C.S.E

Ch 5 - PRESENTATION DE MCSE Par cette approche, la mthodologie fait apparatre une similitude de raisonnement entre la dmarche pour obtenir les spcifications et celle pour concevoir. L'analyse de l'environnement conduit une synthse de la ralit sous la forme d'un modle, et l'introduction des objectifs atteindre conduit un enrichissement de la modlisation prcdente en considrant en supplment l'apport du systme. Cette tape permet d'obtenir 3 types de spcifications: - les spcifications fonctionnelles: elles comprennent la liste des fonctions du systme pour l'application (fonctions externes) et la description du comportement de l'environnement sous l'influence du systme pour ces fonctions. - les spcifications opratoires, qui concernent le comportement, les performances, prcisions, les mthodes utiliser dans le systme. - les spcifications technologiques, qui incluent: les contraintes de temps et de rpartition, les caractristiques des interfaces, les contraintes de ralisation. Les spcifications fonctionnelles et opratoires sont utilises durant l'tape de conception fonctionnelle, tandis que les spcifications technologiques ne servent que pour l'tape de dfinition de la ralisation et de ralisation. Certaines spcifications sont propres l'tape de ralisation. 5.3.2. Conception fonctionnelle La solution pour cette tape se dduit d'une analyse des spcifications fonctionnelles. La recherche de la structure fonctionnelle se fait tout d'abord partir de la dlimitation du systme en caractrisant ses entres et ses sorties. Il s'agit ensuite de trouver une premire dcomposition fonctionnelle. Cette premire approche est importante car elle induit la qualit ou non-qualit pour le reste du dveloppement. La dmarche consiste ensuite rechercher par raffinements successifs et pour chaque fonction concevoir, les variables et vnements internes caractristiques ncessaires et si possible suffisants. Se dduisent 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 lmentaires pouvant s'exprimer par une description purement squentielle. L'exprience nous a montr que cette approche base sur les donnes conduit des structures fonctionnelles simples (rduction des couplages exprimant des relations d'ordre) et plus structures que l'approche base sur les fonctions, qui conduit exprimer la structure comme dcrivant un enchanement de transformations. 5.3.3. Dfinition de la ralisation La troisime tape consiste rechercher, d'une part le support excutif, d'autre part la manire d'y implanter les fonctions ralises par logiciel. Tout d'abord, la description fonctionnelle doit tre affine, dtaille, enrichie pour tenir compte des contraintes technologiques que sont: la rpartition gographique (si ncessaire), les interfaces physiques, les interfaces utilisateur. M.C.S.E 55

Partie 1 - PRESENTATION DE LA METHODOLOGIE Les contraintes de temps sont ensuite analyses pour dduire la rpartition matriel/logiciel. La partie matrielle est spcifie par une structure d'excution. L'intgration ou allocation dcrit compltement l'implantation de la description fonctionnelle sur la structure d'excution. Chaque sous-ensemble fonctionnel raliser par logiciel est dcrit par un schma d'implantation logicielle qui exprime la priorit de chaque tche et les relations de dpendance spatiale (par des donnes) ou temporelles. Cette implantation rsulte de l'utilisation de rgles qui permettent d'effectuer des transformations sur la structure fonctionnelle en tenant compte du support matriel. 5.3.4. Ralisation Les 2 parties: - support matriel, implantation du logiciel - favorisent le travail de ralisation d'un prototype, l'intgration et le test. Il faut tre conscient ce stade de la varit des stratgies de ralisation qui dpendent d'au moins 3 facteurs: les spcifications en entre, les techniques mettre en oeuvre, les outils et mthodes disponibles. La ralisation est une dmarche ascendante puisqu'elle consiste assembler. Il s'agit de dvelopper partie par partie la solution en faisant apparatre des fonctionnalits de plus en plus abstraites pour se rapprocher de l'objectif. Chaque niveau de la ralisation est valid par une vrification de la conformit aux spcifications du niveau correspondant de la dmarche descendante. Ralisation matrielle et ralisation du logiciel peuvent se dvelopper simultanment, ce qui permet de rduire le temps de la ralisation et de faire intervenir conjointement des spcialistes des 2 domaines. Pour achever la ralisation, l'intgration et le test ont pour objectif de runir toutes les parties des dveloppements de manire fournir un systme oprationnel conforme aux souhaits du demandeur. 5.4. CARACTERISTIQUES DE MCSE La mthodologie propose est une dmarche complte qui permet de passer du problme une ralisation. Nous reprenons ici les points gnraux prsents comme objectifs dans les chapitres prcdents, pour montrer pourquoi et comment MCSE rpond l'ensemble de ces points.
-A- UN MODELE DE DESCRIPTION COMME BASE

Toute mthodologie est base sur un ou des modles de description, ceci permet une dcomposition en tapes. MCSE est base sur un modle de description interne en 3 composantes. Il incite dcrire tout systme selon une hirarchie de niveaux de description. Chaque niveau sert d'intermdiaire entre 2 tapes. Les modles sont pour la plupart graphiques, favorisant ainsi une comprhension globale et rapide.
-B- UNE DEMARCHE GLOBALEMENT DESCENDANTE POUR LA CONCEPTION

Chaque tape de la mthodologie permet de passer d'un niveau de description un niveau suivant plus dtaill en enrichissant la solution d'une composante supplmentaire. La progression est donc globalement descendante puisqu'elle part du problme pos jusqu' aboutir une ralisation oprationnelle. 56 M.C.S.E

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

Un dveloppement ne peut pas se faire sans erreurs ou omissions. Des corrections sont toujours ncessaires. Base sur la correction par retours arrire, une phase de vrification en fin de chaque tape permet la dtection des erreurs et induit un travail itratif avec des retours l'intrieur de l'tape ou sur les tapes prcdentes.
-D- UNE METHODE SPECIFIQUE POUR CHAQUE ETAPE

Le modle 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 prcis lui expliquant COMMENT passer de la spcification en entre une solution possdant des qualits. Ce guide est la mthode suivre: technique d'analyse, squence des dcisions, critres de choix. Par opposition une recherche intuitive, l'emploi d'une mthode garantit l'obtention plus rapide d'une solution a priori de qualit. Au-del de l'aspect mthode, l'ide de modles gnriques de solutions a un intrt certain. De tels modles ayant la particularit pour la dcomposition fonctionnelle d'tre gnrateurs de multiples solutions, sont retenues car possdant des qualits intrinsques: lisibilit, maintenabilit, simplicit, adquation au modle global MCSE. La connaissance de tels modles, en complment des mthodes, nous a permis de constater que prs de 80 90% des concepteurs peuvent raliser des dveloppements corrects.
-E- UNE DEMARCHE GLOBALEMENT ASCENDANTE POUR LA REALISATION

L'assemblage n'est possible qu'aprs disponibilit des constituants. Ainsi, la ralisation dbute par la ralisation des plus petits sous-ensembles, puis remonte progressivement par assemblage et intgration de fonctions plus globales. Le travail de ralisation est reprsentable par un triangle juxtapos celui de conception comme lindique la figure 5.6. La largeur du triangle pour chaque stade indique la quantit d'informations matriser. Chaque niveau de la ralisation est vrifiable, ce qui assure sa conformit au niveau correspondant de la conception. Il y a donc correspondance entre les 2 dmarches complmentaires.
-F- UN MODELE DE CYCLE DE DEVELOPPEMENT HIERARCHIQUE

Pour un systme relativement complexe, le modle ci-dessus en double triangle n'est pas suffisamment prcis. L'tape de dfinition de la ralisation conduit mettre en vidence les 2 parties: matriel, logiciel. Chaque partie est nouveau dvelopper selon une dmarche en 3 phases: spcification, conception, dfinition de la ralisation, et ceci jusqu' la mise en vidence des constituants disponibles (composants matriels ou logiciels). Ainsi, le modle de cycle de dveloppement est un embotement de dveloppements. La figure suivante illustre le modle hirarchique pour MCSE. Au premier niveau, la conception est gnrale et concerne l'application dans son ensemble. Au fur et mesure du raffinement de la solution les dveloppements concernent des problmes plus spcifiques en rapport avec la ralisation: dveloppement d'un composant, d'une fonction spcifique, d'un module logiciel... Une spcification sert comme objectif pour une ralisation. Le composant ou sous-ensemble est le rsultat utilisable. M.C.S.E 57

Partie 1 - PRESENTATION DE LA METHODOLOGIE

BESOIN

CONFORMITE

PRODUIT

Spcification
VALIDATION
SPECIFICATION RECETTE CERTIFICATION TEST

Validation

conception

CONCEPTION FONCTIONNELLE

VERIFICATION

VALIDATION

Ralisation

DEFINITION DE LA REALISATION

INTEGRATION

TEST
PARTIE MATERIELLE PARTIE LOGICIELLE

REALISATION MATERIELLE

REALISATION LOGICIELLE

-Figure 5.6- Forme en double triangle pour le dveloppement.

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 Ralisation composant i ou carte i


ASSEMBLAGE

SPECIFICATION DU LOGICIEL CONCEPTION DEFINITION DE LA REALISATION Ralisation module ou tche


ASSEMBLAGE

...
TEST MATERIEL

...
TEST LOGICIEL

Intgration - Test - Validation du Systme

PRODUIT

-Figure 5.7- Modle hirarchique pour le cycle de dveloppement. 58 M.C.S.E

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

Le modle de description induit directement la structure des documents produire durant le dveloppement. Chaque document est le rsultat d'une tape et sert comme informations pour l'tape suivante. Ainsi, en respectant la dmarche par tapes successives, la documentation est gnre au fur et mesure du dveloppement et non en final. Elle possde alors une relle qualit quant la forme et au fond puisqu'elle relate, en plus de la solution, la dmarche suivie et l'argumentation qui justifie les dcisions importantes. Produite de cette manire, la documentation est exploitable durant le cycle de dveloppement: pour les phases de vrification selon un cycle auteur-lecteurs, pour l'observation de l'tat d'avancement, mais aussi pour les tapes ultrieures et en particulier pour la maintenance.
-H- GUIDE POUR LA CONDUITE DE PROJET

Le modle de cycle de dveloppement est utilisable pour la mise en place d'une procdure de conduite d'un ensemble de projets. Pour chaque projet, cette activit concerne: - le management: planification, organisation, direction, contrle et suivi du projet, - l'obtention de la conformit: planification des tests, nature des tests techniques utiliser, les rsultats, conformit et certification, - la gestion de la documentation: spcification des documents, planification des revues, mthodes de gestion, mises jour... - la gestion de la maintenance: domaine et procdures de maintenance, solutions et outils, planification, - la gestion de la qualit: assurance qualit, mthode pour l'obtention de la qualit, procdures de contrle.
-I- UNE METHODOLOGIE OUVERTE ET COMPLEMENTAIRE

MCSE ne se trouve pas restreinte un domaine bien spcifique et n'est pas uniquement une mthode particulire. Au contraire, pour chaque tape, plusieurs mthodes sont utilisables et c'est au concepteur de choisir selon des critres, celle qui lui permet de rsoudre au mieux son problme. Dveloppe au dpart pour les systmes de contrle/commande temps-rel microprocesseurs, l'exprience nous a montr son adquation pour une large classe d'applications et de techniques et tout particulirement pour les applications qui utilisent l'Electronique et l'Informatique. MCSE n'est pas opposer aux autres mthodologies, bien au contraire, elle se veut complmentaire. La plupart des modles proposs par diffrents auteurs s'avrent utilisables. Par exemple, SADT, les mthodes de spcification de WARD et MELLOR et de HATLEY favorisent la tche d'analyse du problme. La mthodologie de JACKSON est dans l'esprit et pour certains aspects relativement proche de MCSE. Les mthodologies DARTS de GOMAA et SDWMC de BUHR ont des points communs.
-J- SUPPORT POUR DES OUTILS

Il est difficile aujourd'hui de concevoir une mthodologie sans penser aux outils informatiques comme support de dveloppement et de conduite de projets. M.C.S.E 59

Partie 1 - PRESENTATION DE LA METHODOLOGIE Bas sur un modle formel, MCSE possde toutes les caractristiques favorables pour le dveloppement de tels outils. Il est essentiel de comprendre qu'un outil n'implique pas une mthodologie mais l'inverse. Un outil n'est que le support d'aide l'application d'une mthodologie. Ainsi, un outil comme support ne peut se dvelopper que postrieurement la formalisation d'une mthodologie. Cette prsentation succincte est loin d'tre suffisante pour se faire une ide complte sur la mthodologie. Aussi, pour avoir une vue globale relativement complte de la dmarche, le chapitre suivant illustre son utilisation sur un exemple assez simple.

60

M.C.S.E

Chapitre 6

UN EXEMPLE DILLUSTRATION

De manire illustrer les principes de la mthodologie MCSE, ce chapitre prsente un exemple de problme relativement simple, mais tout de mme suffisamment complexe pour justifier l'utilisation d'une mthode. Il permet de saisir les grandes lignes de la dmarche prconise, le rle de chaque tape. Il facilite la comprhension des 3 vues du modle conceptuel et les niveaux de description de la solution. Il n'est pas demand au lecteur de comprendre en dtail l'exemple. Il est mme plutt conseill de lire rapidement ce chapitre, uniquement pour se faire une ide globale de la mthodologie. Plus tard, une fois lues les parties 3 6 qui concernent lapprofondissement de la mthode pour chacune des tapes, il sera alors judicieux de revenir sur cet exemple pour une comprhension complte. L'exemple trait est un systme pour le contrle de la vitesse de croisire d'un vhicule. Cet exemple est extrait de l'ouvrage: Strategies for Real-time System Specification- de HARTLEY et PIRBHAI dans lequel on trouve une prsentation de solution. On retrouve le mme exemple dans l'ouvrage: Structured Development for Real-time Systems Vol. 2 et Vol. 3 de WARD et MELLOR. Des complments et modifications ont t apports au cahier des charges en particulier pour les spcifications technologiques de manire pouvoir proposer une solution complte et raliste vis vis du besoin.

M.C.S.E

61

Partie 1 - PRESENTATION DE LA METHODOLOGIE 6.1. CAHIER DES CHARGES Ce systme de contrle est considrer comme une option possible sur certains modles de vhicules. Les fonctions essentielles du systme concernent des oprations de routine et des tches de maintenance, savoir: maintien de la vitesse de croisire, suivi de la vitesse moyenne, suivi de la consommation de carburant, maintenance de la voiture.

On dcrit ci-aprs plus en dtail ces fonctions ce qui permettrait par une tude prliminaire, une valuation de la solution, son cot et temps de dveloppement, son cot de reproduction. 6.1.1. Contrle du rgime de croisire Cette fonction permet de conserver au vhicule une vitesse constante lorsque ce mode est sollicit par le conducteur. Elle n'est active que lorsque le moteur est en route. Au dmarrage, la fonction est videmment dans l'tat inactif. Le conducteur dispose de plusieurs commandes: activation du rgulateur, arrt, acclration, retour au rgime prcdent (rgulation de croisire).

Lorsque le conducteur active la rgulation, la vitesse du vhicule cet instant est maintenue si celle-ci est suprieure 50 km/h. La commande ARRET implique une reprise du contrle par le conducteur. La vitesse du vhicule se dduit de la vitesse de rotation d'une roue et le contrle de la vitesse du moteur s'effectue par une valve qui contrle l'injection de carburant. La commande de la valve ne s'effectue que dans le sens ouverture (acclration). Dans l'autre sens, il y a rappel automatique par un ressort. Bien entendu, la pdale d'acclration agit toujours mcaniquement sur la valve; c'est l'action la plus importante en dplacement qui dfinit la vitesse du vhicule. Lorsque le rgulateur 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 mme touche acclration fonctionnant en bistable. Alors le vhicule maintient cette vitesse comme rgime de croisire. Le conducteur peut tout instant, augmenter la vitesse du vhicule en appuyant sur la pdale d'acclration, ou rduire sa vitesse en appuyant sur la pdale de frein. Sur relchement de la pdale d'acclration le vhicule revient la vitesse de croisire. Lorsqu'il s'agit d'un appui sur la pdale de frein ou lors dun retrait du levier de vitesse de sa position enclenche, le systme devient inactif. Sur relchement du frein, et avec le levier de vitesse en position, la commande "Retour au rgime de croisire" fait retrouver au vhicule la vitesse prcdemment slectionne. Si entre temps une commande ARRET est intervenue, la commande RETOUR est sans action. 62 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION Le systme doit possder son propre indicateur de vitesse. Comme la vitesse et donc la distance parcourue est fonction de la taille des pneus, le systme doit pouvoir tre calibr l'installation. 2 commandes supplmentaires sont disponibles en face arrire: START MESURE KM et STOP MESURE KM. Aprs l'appui sur START, le conducteur parcourt 1 km puis appuie sur STOP. Dans ce mode talonnage, le systme doit enregistrer le nombre de tours de roues qui servira ensuite comme rfrence pour les calculs de vitesse et de kilomtrage. 6.1.2. Suivi de la vitesse moyenne Le systme doit fournir au conducteur une indication de sa vitesse moyenne. Pour cela, le conducteur indique au systme le dbut d'un trajet par la commande : START TRAJET, et chaque fois qu'il demandera la vitesse moyenne par DEMANDE VM, le systme lui indiquera la vitesse moyenne depuis le dpart. 6.1.3. Suivi de la consommation de carburant Lorsque le rservoir est rempli, le conducteur indique au systme la quantit de carburant qui vient d'tre ajoute. Le systme calcule et affiche alors la consommation sur la priode entre les 2 pleins. 6.1.4. Maintenance Le systme doit suivre le kilomtrage 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, - Rvision gnrale: 30 000 Km 250 Km avant l'chance, le message appropri doit apparatre en clignotement lent. 50 Km avant, il doit apparatre en continu et persister jusqu' l'acquittement par le conducteur (commande: MAINTENANCE EFFECTUEE). 6.1.5. Caractristiques complmentaires La phase de spcification ncessite bien entendu des discussions avec le demandeur de manire prciser certains points obscurs. On relate ci-aprs les dcisions retenir. - La pdale d'acclrateur est en parallle 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 complte de la valve, et pour 8 volts: ouverture complte. - Le systme mesure la vitesse en comptant les impulsions reues par un capteur dispos au niveau d'une roue. - Quand le systme dtecte que la vitesse est suprieure de 3 Km/h la vitesse slectionne, la valve doit tre compltement ferme (cas de la grande descente). Pour toute autre vitesse, la commande doit tre proportionnelle l'erreur de vitesse, sauf lorsque la valve est compltement ouverte. Ceci ne doit apparatre que pour un cart de 3 Km/h. Pour des problmes 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 acclrations 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 mcaniciens ont estim qu'avec ces contraintes, la voiture peut conserver sa vitesse +ou- 2 Km/h pour des pentes normales. - Quand le systme est en phase d'acclration, celle-ci doit tre maintenue 2 Km/h/s. Si l'acclration atteint 3 Km/h/s, la valve doit tre totalement ferme, et pour 1 Km/h/ s, elle doit tre compltement ouverte. Entre ces 2 valeurs, l'ouverture est proportionnelle l'cart d'acclration. - Le systme 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 valides (quantit de carburant ...). 6.2. SPECIFICATIONS La dmarche consiste tout d'abord s'intresser l'environnement du systme en modlisant pour l'application les entits externes au systme sans celui-ci. Il s'agit ensuite de spcifier les fonctionnalits du systme en dcrivant le comportement des entits avec le systme. Cette premire tape conduit l'obtention d'une description externe du systme concevoir. 6.2.1. Modlisation de l'environnement
-A- LES ENTITES

Les entits concernes par le systme sont: - le conducteur du vhicule, (l'installateur pour l'talonnage), - la voiture restreinte un moteur assurant le dplacement par les roues.
-B- LES EVENEMENTS, CONDITIONS, OBSERVATIONS

On recense ensuite la liste des vnements relats dans le cahier des charges, ceux produits par les entits et qui ncessitent une raction de la part du systme. Mise en marche et arrt du vhicule (conducteur). Activation du rgulateur, arrt du rgulateur (conducteur). Dbut acclration, fin acclration (conducteur). Retour au rgime prcdent (conducteur). Acclration par pdale, freinage, (conducteur). Start Mesure Km, et Stop Mesure Km (installateur). Start Trajet, Demande VM (conducteur). Maintenance effectue (conducteur). Ajot essence (conducteur).

De mme, on peut recenser les conditions prendre en compte: - V> 50 Km/h (vhicule), 64 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION - V = VR: Vitesse de croisire pour la rgulation (vhicule), - Vitesse enclenche (vhicule), - Quantit de carburant (conducteur), - Variation max de la valve: 10 s pour toute la plage en ouverture. Comme observations pour les entits, signalons: - Distance parcourue (D), - Vitesse du vhicule (V), - Vitesse moyenne sur un parcours (Vmoy), - Consommation moyenne (Cmoy), - Clignotement pour chance 250 Km, - Indication permanente pour chance 50 Km.
-C- COMPORTEMENT DES ENTITES

Le conducteur est en droit de dsirer n'importe quel instant un comportement particulier pour son vhicule. Il est donc gnrateur des vnements le concernant et observateur des ractions de son vhicule et des informations. La voiture peut se modliser trs simplement en considrant que lorsque le moteur tourne et qu'une vitesse est enclenche, la vitesse de dplacement est trs sommairement proportionnelle la position de la valve. Bien entendu, des grandeurs comme la pente de la route et la charge sont aussi des paramtres essentiels agissant sur la vitesse. V= F (max (Pacclrateur, Cmd_valve), pente, charge ...) Pacclrateur est la position de la pdale d'acclration et Cmd_valve est la commande lectrique de la valve. La grandeur la plus importante entre la Position de la pdale d'acclrateur et la Position de la commande lectrique de la valve, est prioritaire. L'influence des termes: pente, charge ... imposera obligatoirement une commande en boucle ferme pour obtenir l'effet de rgulation.
-D- DELIMITATION DU CONTEXTE DU SYSTEME

La dlimitation donne sur la figure 6.1 prcise le couplage entre le systme et son environnement. - Pour les commandes en provenance du conducteur, on trouve tous les vnements cits en B ; de mme 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 vhicule, la distance parcourue et la vitesse enclenche. M.C.S.E 65

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Commandes Commandes Information

SYSTEME A SPECIFIER
VOITURE

CONDUCTEUR

Observations

Observations

-Figure 6.1- Dlimitation du contexte du systme. 6.2.2. Spcifications fonctionnelles Il s'agit d'indiquer les fonctions que doit assurer le systme pour son environnement, et dcrire avec le maximum de prcision les caractristiques de ces fonctions. Pour cela, ne pouvant dcrire les fonctions directement (la conception serait alors dj faite), on s'attache tablir une description indirecte en dtaillant le comportement des entits sous l'influence du systme pour les fonctions.
-A- LISTE DES FONCTIONS DU SYSTEME

Le systme doit : - assurer la rgulation de vitesse en rgime de croisire lorsque ncessaire, - fournir des informations de conduite, - fournir une aide la maintenance. On dtaille ci-aprs chacune des fonctions.
-B- REGULATION DE VITESSE

Pour que le conducteur puisse profiter de cette fonction, il devra coordonner (relation d'ordre) les vnements qu'il gnre. Alors la voiture suivra le comportement souhait par le demandeur. Cette spcification est donne figure 6.2. La spcification se fait donc en modlisant les tats souhaits pour le vhicule, sous la sollicitation du conducteur. V est la vitesse courante du vhicule et VR reprsente la vitesse de croisire et sert de consigne pour la rgulation. Acclration est une condition boolenne spcifiant si le conducteur acclre ou non. 66 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION

de tous les tats sur arrt moteur arrt moteur

ARRET

mise en marche stop_mesure_km

Conduite normale

talonnage
start_mesure_km

activation Rgul V>50 km VR = V

Rgulation Vitesse VR (1)


arrt

freinage + retrait vitesse

acclration

dbut acclration

inactif
arrt

acclration manuelle

acclration automatique (3)


fin acclration VR = V

(freinage Vitesse enclenche retour)

acclration

Rattrapage (2) vitesse croisire

arrt

arrt

arrt

V#VR

-Figure 6.2- Comportement du vhicule pour la rgulation. Pour complter la spcification, il faut indiquer les actions entreprendre pour les phases actives du rgulateur. Pour les autres, c'est l'acclrateur qui agit. Donc Cmd_valve =0. M.C.S.E 67

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

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

-PHASE: Rattrapage croisire 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'acclration courante, K : coefficient de rgulation.
-C- INFORMATIONS DE CONDUITE

3 informations sont souhaites: - vitesse du vhicule 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)

Dbut trajet DV=0, TV=0

Demande VM VM = DV / TV

ajout essence CM=Q/DC, DC=0

TV = dure depuis Dbut trajet

Q = quantit ajoute

-Figure 6.3- Comportement impos au conducteur pour laide la conduite.


-D- AIDE A LA MAINTENANCE

L'aide doit concerner les 3 types de maintenance. L'information indique 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 DILLUSTRATION - 7500 Km: huile, filtre huile, - 15000 Km: huile, filtre huile, filtre air, - 30000 Km: rvision gnrale.

Attente maintenance

(D+250) multiple de 7500

Maintenance intermittente D = kilomtrage du vhicule

(D+50) multiple de 7500 Maintenance effectue Maintenance permanente

Maintenance effectue

-Figure 6.4- Comportement vis vis du conducteur pour la maintenance. 6.2.3. Spcifications opratoires et technologiques Les spcifications opratoires concernent la dfinition des grandeurs et prcisions. La prcision sur les grandeurs affiches doit tre de l'unit. Les spcifications technologiques relatent: - les caractristiques lectriques des interfaces, - les contraintes de temps, - les contraintes de ralisation.
-A- INTERFACES

2 types d'interfaces sont considrer: - le couplage entre la voiture et le systme, - le couplage avec l'utilisateur. Pour les interfaces voiture-systme: - codeur incrmental pour les mesures Vitesse et Distance, 10 impulsions par tour de roue, - contact ferm, pour vitesse enclenche 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 dcid d'utiliser un dispositif d'affichage type LCD, et un ensemble de touches pour slectionner le mode souhait. Ci-aprs, voici une esquisse de cette interface. 2 touches sont situes en face arrire pour l'talonnage.

VITESSE km/H
Maintenance Indicateurs Maintenance

Vitesse moyenne km/h

+
Consommation moyenne litres/100km

1
effectue 7500

2
15000

3
30000

SELECTION DU MODE

Activation

Arrt

Acclration

Retour rgime prcdent

Ajout carburant

Dbut trajet

Demande moyenne km

-Figure 6.5- Esquisse de linterface utilisateur. L'entre de la quantit du carburant se fait par les touches + et - au lieu d'un clavier numrique. Pendant cette entre qui dbute ds le premier appui sur +, l'affichage se fait sur l'afficheur de la consommation moyenne. La quantit moyenne pour 100 Km s'obtient aprs appui de la touche "ajout carburant". Le comportement pour cette fonction est le suivant.

Affichage consommation moyenne

appui sur + Q=0

Rglage 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 rgulation, la commande de position de la valve ne doit pas excder une priode de 1s (ce qui n'est pas une contrainte svre). 70 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION Le dlai de raction du systme 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 dvelopp sur la base de la technologie microprocesseur. La quantit de systmes produire pouvant tre leve, le cot de reproduction doit tre le plus faible possible. Le systme est aliment par la batterie. Mme sur dbranchement de celle-ci, le systme doit mmoriser les grandeurs essentielles: Kilomtrage, paramtres d'talonnage ... Les contraintes d'environnement concernent, la temprature, l'hygromtrie, les vibrations. 6.3. CONCEPTION FONCTIONNELLE La conception fonctionnelle dbute par le dveloppement d'une premire approche fonctionnelle. Celle-ci s'labore partir d'une dlimitation des entres/sorties fonctionnelles du systme, en recherchant les fonctions essentielles ncessaires pour satisfaire les spcifications. La recherche de la solution doit tre purement fonctionnelle en dcelant les variables internes caractristiques. Normalement, si les spcifications fonctionnelles ont t bien labores, on doit y retrouver par lecture ces grandeurs essentielles. Il faut viter de considrer les interfaces ncessaires pour l'observation des grandeurs ou pour les commandes, pour ne considrer que les vraies grandeurs de l'application. Cette remarque est essentielle pour une bonne dlimitation des entres/sorties. La mthode prconise conduit ainsi dvelopper une solution indpendante de la technologie. Cette deuxime tape conduit l'obtention du premier niveau interne de la solution. 6.3.1. Dlimitation du systme Beaucoup d'vnements proviennent du conducteur: appui sur des poussoirs, entre de la quantit de carburant. De manire se rendre indpendant de l'interface utilisateur, toutes les commandes sont considres comme des messages. Pour l'affichage, toutes les sorties seront aussi des messages, chacun contenant la nature de la grandeur concerne. Les grandeurs observer sur le vhicule sont: la vitesse, la distance totale parcourue depuis sa mise en service, l'tat freinage et l'tat vitesse enclenche. La dlimitation du systme avec les entres/sorties s'obtient donc en remplaant tous les liens avec l'environnement exprims dans la spcification par les relations appropries du modle fonctionnel: synchronisation, variable d'tat, transfert de messages. La figure 6.7 reprsente cette dlimitation. On considre ce stade que le systme sera aliment par la batterie travers la cl de contact. Ainsi, durant la conception il n'est pas utile de prendre en compte les vnements "Marche" et "Arrt" du moteur. M.C.S.E 71

Partie 1 - PRESENTATION DE LA METHODOLOGIE

CMD Conducteur

AFF Conducteur

SYSTEME
freinage

Vitesse enclenche

CONCEVOIR

Cmd_Valve Voiture

Voiture

V D

-Figure 6.7- Dlimitation du systme. Toutes les variables utilises en entre et sortie doivent tre spcifies: - FREINAGE, VITESSE ENCLENCHEE: boolen - V: 0 199KM/H - D: 0 100000 KM - Cmd_Valve: 0 Max - CMD = [Maintenance assure | Activation rgulateur | Arrt rgulateur | Dbut acclration | Fin acclration | Retour rgime prcdent | 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. Premire structure fonctionnelle Cette premire structure se dduit d'une analyse efficace des spcifications fonctionnelles, en recherchant tout particulirement les grandeurs internes strictement ncessaires pour rsoudre le problme. 72 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION Les phases suivre sont: analyse-dcomposition, laboration, vrification.


-A- ANALYSE

D'aprs les spcifications, les 3 fonctions du systme spcifies en 6.2.2 par des automates s'avrent indpendantes: pas de variables communes. Des grandeurs internes apparaissent dans la spcification (conditions ou actions): - VR: pour la vitesse de croisire suivre, - DV et TV: distance parcourue et temps depuis le dbut du trajet, - DC : distance parcourue depuis le plein prcdent.
-B- ELABORATION DE LA SOLUTION

Proposons la structure fonctionnelle suivante. Elle est base sur l'analyse prcdente en considrant la grandeur VR comme essentielle. Vis vis des 2 entits conducteur et voiture, elle est conforme une dcomposition du type supervision/commande: supervision comme fonction lie au conducteur, et commande comme fonction de contrle du vhicule.

CMD

AFF

SUPERVISION
D

VR

MODE

V CMD_VALVE

PAS HORLOGE

CONTROLE-VITESSE

-Figure 6.8- Premire esquisse fonctionnelle. La fonction CONTROLE_VITESSE est active par un vnement priodique servant de pas d'chantillonnage pour la rgulation. La variable MODE dfinit les 3 cas de fonctionnement de cette fonction: MODE: (ARRET, REGUL, ACCEL). Le mode REGUL correspond aux 2 tats (1) et (2) de la spcification pour le vhicule figure 6.2, le mode ACCEL correspond l'tat (3) pour un accroissement automatique de la vitesse, le mode ARRET aux autres tats. De manire disposer d'une solution homogne pour l'activation de supervision, il a t dcid d'intgrer comme messages dans CMD les vnements FREINAGE ou VITESSE NON ENCLENCHEE et FREINAGE et VITESSE ENCLENCHEE. Ainsi SUPERVISION est une action temporaire qui traite en squence le flot des vnements. Ceci revient considrer comme messages toutes les transitions externes utilises dans les automates de spcification. 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 propose permet de satisfaire les spcifications. Les automates donnes dans la spcification sont implanter dans SUPERVISION. Les 2 phases: Rgulation vitesse (1), et Rattrapage vitesse croisire (2) sont regroupes et implantes dans CONTROLE_VITESSE. Ceci est spcifi par l'tat REGUL de MODE. La transition entre phase 2 et phase 1: V#VR, est labore en interne de CONTROLE_VITESSE. Autre remarque: l'affichage de V doit se faire rgulirement pour une indication correcte de la vitesse: pas possible avec la solution propose car SUPERVISION est une fonction temporaire synchrone CMD. De plus une variable T est ncessaire pour la mesure du temps depuis le dbut du trajet. Enfin SUPERVISION doit avoir un caractre permanent pour suivre le kilomtrage du vhicule D pour la maintenance. Il faut aussi un clignotement du message Maintenance. La solution corrige fait apparatre en supplment, la fonction MAINTENANCE active 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

VR

MODE

Gnration Temps

V V AFF_V CMD_VALVE

CONTROLE-VITESSE

-Figure 6.9- Premire structure fonctionnelle. L'affichage de V ncessite la liaison entre la fonction CONTROLE_VITESSE et la sortie vers le port AFF. Ce type de vrification se fait aussi assez naturellement en poursuivant le raffinement complet; une cohrence en final valide la premire approche. Des retours-arrires sont souvent ncessaires. Toutefois une premire structure simple ds le dpart conduit une meilleure dcomposition. 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 DILLUSTRATION comportementale. Pour chacune, il faut tout dabord se poser la question de savoir sil nest pas possible d'en donner une spcification comportementale. Si la fonction a un comportement squentiel, ceci est possible. C'est le cas de CONTROLE_VITESSE qui est active par l'vnement PAS. SUPERVISION est active par chaque message de CMD. Cette fonction a donc un comportement squentiel. 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 dtaille dans la suite le comportement squentiel de chaque fonction. 6.3.4. Comportement de contrle vitesse Sur passage en mode REGUL, cette action temporaire synchrone PAS (1 seconde) doit assurer tout d'abord le rattrapage de la vitesse de croisire par une acclration constante, puis la rgulation de vitesse. En mode ARRET, le systme ne doit pas agir . Le comportement dduit des spcifications est donc le suivant.

INACTIF

MODE = REGUL

ACCELERATION ( pour rattrapage vitesse)


MODE = ARRET

MODE = ARRET

VVR ( 3km/H prs)

MODE = REGUL

REGULATION

ACCROISSEMENT LINEAIRE

MODE = ARRET

MODE = ACCEL

-Figure 6.10- Spcification pour CONTROLE_VITESSE. Le comportement pour les 2 phases Acclration et Rgulation, a t prcis dans les spcifications fonctionnelles. La grandeur acclration se dduit par diffrence de 2 mesures conscutives de la vitesse (spares d'une seconde). Ltat acclration manuelle par le conducteur (prioritaire) de la figure 6.2 est assur par ltat Rgulation. De cette analyse, la description algorithmique se dduit directement par simple transcription de la spcification ci-dessus. La dfinition 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 vnement PAS avec (entres 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, acclration, rgulation, 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:= acclration; acclration: if MODE = ARRET then begin ETAT:=inactif CMD_VALVE:= 0; end else if (V>VR-3) and (V<VR+3) then ETAT:= Rgulation 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; Rgulation: 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 DILLUSTRATION 6.3.5. Comportement de supervision Pour chaque message extrait de CMD, cette action assure les transitions d'tats et les actions ncessaires. D'aprs les spcifications, cette fonction doit implanter 3 automates et piloter celui de la maintenance. Pour la rgulation, le comportement est simplifi puisque 2 tats sont raliss par la fonction CONTROLE_VITESSE. La spcification de T_CMD est la suivante:
T_CMD = Record NATURE: (Maintenance_assure, quantit_carburant, Start_trajet, demande_VM, activation, arrt,dbut_acclration,fin_acclration, freinage,fin_freinage,start_mesure_Km, stop_mesure_Km,Retour_vitesse_croisire); QUANTITE: 0..100; end; action SUPERVISION sur message E_CMD:T_CMD avec ( entre var D: T_DISTANCE; entre/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,rgulation,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_assure: 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:=Rgulation; end;

M.C.S.E

77

Partie 1 - PRESENTATION DE LA METHODOLOGIE


Arrt_rgulation: begin ETAT:=normal; MODE:=ARRET; end; Dbut_acclration: if ETAT=Rgulation then begin ETAT:=inactif; MODE:=ACCEL; end; fin_acclration: if ETAT=inactif then begin VR:= V; ETAT:=Rgulation; MODE:=REGUL; end; freinage: if ETAT=Rgulation then begin ETAT:=inactif; MODE:=ARRET; ETAT_FREIN:= vrai; end; fin_freinage: ETAT_FREIN:= faux; Retour_vitesse_croisire: if ETAT=inactif and ETAT_FREIN=faux then begin ETAT:=rgulation; 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 reu, l'action vrifie si le systme est dans un tat correct (rceptivit). Si oui, elle ralise les actions correspondantes. Si non, l'vnement est simplement limin. L'algorithme dcoule de la spcification par simple traduction. 6.3.6. Comportement de maintenance Cette fonction est temporaire synchrone PAS de manire suivre l'volution de la distance D et produire tout particulirement l'affichage avec clignotement entre -250 Km et 50 Km. Le comportement a t donn dans les spcifications sous la forme d'un automate en 3 tats. L'initialisation dans l'tat "attente" est effectue par SUPERVISION ds la rception de l'vnement "Maintenance effectue". 78 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION

Type T_Maintenance=(attente, intermittent, permanent); Action MAINTENANCE sur vnement PAS avec (entre/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 gnration_temps Cette action assure simplement la mise jour de T par ajout de la valeur DUREE_PAS sur chaque vnement PAS.
action GENERATION_TEMPS sur vnement PAS avec (entre/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 modle fonctionnel a t obtenu en ignorant volontairement tous les aspects technologiques telles que la nature des capteurs pour D et V, les caractristiques de l'interface utilisateur, ce qui a conduit une solution indpendante de la technologie. Bien entendu, la solution dduire durant cette tape devra tenir compte de toutes ces contraintes technologiques ainsi que des contraintes de temps . Durant cette troisime tape qui permet d'obtenir le niveau 2 de la description interne, ou description excutive, il faut dfinir: - les spcifications du support matriel, - les spcifications de l'implantation logicielle. Pour cela, il s'agit d'exploiter plus particulirement les spcifications technologiques. La dmarche suivre est la suivante: - introduction de la rpartition gographique si ncessaire (ce n'est pas le cas pour ce problme), - introduction des interfaces avec l'environnement, - analyse des contraintes de temps, - rpartition matriel/logiciel, - spcification de l'implantation logicielle, - spcification du support excutif. 6.4.1. Introduction des interfaces Il s'agit d'ajouter en priphrie de la solution fonctionnelle, les couplages avec les 2 entits de l'environnement que sont la voiture et le conducteur. Pour cela, basons-nous sur le modle gnrique propos par HATLEY (Architecture template), qui propose une dcomposition de la solution de ralisation en 4 sous-ensembles telle que lindique la figure 6.11 [HATLEY-87]. Le modle fonctionnel trouv prcdemment est le noyau dur de l'application comme invariant vis vis de la technologie employe. La sparation volontaire de l'interface utilisateur des autres entres/sorties permet d'y attacher un intrt particulier avec comme objectif de rechercher un produit particulirement convivial. Le sous-ensemble: -Maintenance, auto-test...- fait rflchir sur les constituants supplmentaires de manire amliorer la fiabilit et la scurit de l'application. Ce sousensemble n'est pas trait dans cet exemple.
-A- INTERFACES DENTREE

On s'intresse ici toutes les grandeurs observer sur le vhicule. D'aprs les spcifications technologiques, la vitesse V n'est pas directement observable. Un codeur impulsionnel sur une roue est utilis cet effet. Il en est de mme pour D. V se dduit de l'observation du nombre de tours de roue et donc des impulsions du codeur pendant une dure dtermine (qui peut tre la seconde). C'est l'utilisation du principe du frquencemtre. V = K * NB_IMP 80 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION

Interface utilisateur

Modle fonctionnel Entres


procd physique indpendant de la technologie

Sorties
procd physique

Maintenance
auto-test , redondance , ...

-Figure 6.11- Modle gnrique de ralisation. K est une constante qui dpend de la taille des pneus. Cette grandeur K est donc le rsultat de la phase d'talonnage, dj dveloppe dans le modle fonctionnel. K doit correspondre au dplacement pour 1/10e de tour de roue, le codeur fournissant 10 impulsions par tour. D est l'intgrale 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 ltalonnage 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, ncessite l'observation du nombre d'impulsions durant 1 Km, ce qui permet de dduire la longueur d'un tour de roue. Aussi l'interface avec le modle fonctionnel est modifi pour la prise de connaissance de la variable ETAT de SUPERVISION qui indique, si le systme est dans la phase d'talonnage ou non. La spcification se complte par les descriptions comportementales des actions.
action EVALUATION_V_ET_D sur vnements IMP et H avec (entre var K: T_K; entre/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 vnement IMP avec (entre var ETAT_ETALONNAGE:(talonnage, autre); sortie var K: T_K); var ETAT: (arrt,marche); N: integer; begin ETAT:=arrt; cycle IMP: case ETAT of arrt: if ETAT_ETALONNAGE=talonnage then begin ETAT:=marche; N:=0; end; marche: if ETAT_ETALONNAGE<>talonnage then begin ETAT:=arrt: K:= 1000/N; end else N:= N+1; end case; end cycle; end EVALUATION_K; -B- INTERFACE DE SORTIE

La seule sortie vers le vhicule 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 DILLUSTRATION Technologiquement, la conversion numrique analogique peut se faire simplement par une commande du type PWM (modulation de largeur). Les avantages par rapport un convertisseur numrique-analogique conventionnel sont: - fonctionnement purement numrique, - commande de puissance en tout ou rien, - possibilit d'isolation opto-lectronique. La solution fonctionnelle est donne ci-aprs sans dtailler le comportement des actions lmentaires. Le principe pour la fonction est l'utilisation d'un dcompteur P initialis tous les NT la valeur CMD_VALVE et dcrment tous les T. Tant que P est strictement positif , CA est actif.

Cmd_Valve

Gnration 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

-Figure 6.13- Interface de sortie pour la commande Valve.


-C- INTERFACE UTILISATEUR

Pour tre indpendant de la technologie, tous les vnements en provenance ou vers le conducteur ont t spcifis comme messages. Par exemple, la solution pour la mthode retenue dans les spcifications technologiques pour l'entre de la quantit de carburant n'a pas t dveloppe dans le modle fonctionnel car dpendante de l'interface utilisateur. Cette interface a t esquisse figure 6.5. On constate que le conducteur dispose de 10 touches sur lesquelles il peut appuyer volont plus 2 en face arrire. En observation, 4 zones d'affichage existent, ce qui donne au total 8 digits dcimaux et 3 tats binaires. La gestion de l'interface est base sur la scrutation priodique de l'ensemble des touches, avec exclusion pour des appuis simultans. L'affichage s'obtient par dcodage des messages et transmission vers l'afficheur destinataire. Un cas particulier apparait pour la slection de la quantit de carburant: l'affichage doit suivre l'volution engendre par les touches + et -. Pour cela, l'interface produit directement des messages AFF. Pour rpondre ces spcifications, la solution fonctionnelle retenue est donne 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 dtaille pas dans la suite le comportement pour ces 2 fonctions. Il faut savoir que l'interface utilisateur est toujours coteux en lignes de programmation et donc en temps de dveloppement. L'approche fonctionnelle ci-dessus permet de programmer l'interface utilisateur selon un modle gnral, ce qui conduit une meilleure efficacit. 6.4.2. Analyse des contraintes de temps Cette analyse considre: - les frquences d'activation de toutes les actions (frquence des vnements), - les temps de rponse pour les vnements de sortie. Elle doit conduire pouvoir dcider de la rpartition matriel/logiciel, avec comme principe de ralisation d'inclure le maximum de fonctions dans la partie logicielle. Avant de dcider de la rpartition, il faut rduire au maximum le nombre de gnrateurs d'vnements du type horloge. Pour cela, on part d'un gnrateur correspondant la frquence maximale. Les autres vnements s'obtiennent alors par division en frquence. On rappelle par la figure 6.15 la structure fonctionnelle complte considre pour l'analyse des contraintes de temps puis ensuite le choix de la rpartition matriel/logiciel. Les vnements recenss sur la structure fonctionnelle globale ci-dessus sont: - CMD: priode ngligeable dfinie par la raction 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 DILLUSTRATION

Touches Gestion des touches CMD

Interface utilisateur
Afficheurs AFF SUPERVISION AFFICHAGE

Etat Maint

HP VR T
MODE

Mainte nance

Adaptation des entres


ETAT_ ETAL.

Adaptation aux sorties


Gn. temps HP

Etalonnage
K D

Cmd_Valve CA CONTROLE-VITESSE Gnration PWM HP


V

IMP

Evaluation V et D DIV par 1000

HP Horloge

PARTIE LOGICIELLE
H

HP

PARTIE MATERIELLE

-Figure 6.15- Solution fonctionnelle complte. Pour les temps de rponse, on ne retrouve qu'une seule contrainte dans les spcifications technologiques: raction en 1s qui n'est pas du tout une contrainte svre pour une solution lectronique. Par contre, le freinage doit tre immdiat. On prendra pour cela un pas d'chantillonnage de 0,1s. Donc Hp = 10 Hz. 6.4.3. Rpartition matriel/logiciel L'analyse consiste tout d'abord classer les fonctions en 2 catgories: - celles obligatoirement ralises par matriel, par exemple, les horloges, les fonctions rapides c'est--dire priode < 50 100 s, - celles implantables en logiciel ou en matriel. Pour cette deuxime catgorie et pour dcider si une fonction est implantable en logiciel, il faut observer la frquence d'activation et valuer le temps d'excution probable pour la fonction avec l'hypothse technologique choisie ou impose. Les 2 fonctions qui peuvent poser problme sont: - gnration PWM, - Diviseur/1000. On retient ici une solution matrielle pour la fonction Gnration 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 frquences d'activation et des temps d'excution qui restent faibles. Le calcul du taux doccupation du microprocesseur valide un tel choix. 6.4.4. Spcification de l'implantation logicielle 9 fonctions volution parallle sont implanter en logiciel, bien entendu sur un microprocesseur qui "n'est qu'une machine squentielle". M.C.S.E 85

Partie 1 - PRESENTATION DE LA METHODOLOGIE Spcifier l'implantation logicielle revient prciser l'ordonnancement de ces fonctions sur un microprocesseur, c'est--dire le droulement temporel. Pour cela, il faut dfinir, la priorit de toutes les fonctions, celles qui se droulent sous interruption, les synchronisations logicielles entre fonctions temporellement dpendantes. Quelques principes simples aident dfinir la solution. Les fonctions actives par une fonction matrielle sont implantes sous interruption. La priorit d'excution pour ces fonctions est proportionnelle la frquence d'activation. Toutes les fonctions actives par un mme vnement sont traites en squence. Les fonctions logicielles permanentes s'implantent comme tche de fond. Les synchronisations par vnements ou messages s'implantent par appel procdural si la fonction destinatrice peut tre plus prioritaire l'excution. On remarque une difficult due au fait que l'action valuation D et V est active par 2 vnements. La solution consiste scinder cette action en 2 parties, chacune active par un vnement. La variable NB_IMP, commune aux 2 parties, est alors une variable partage ncessitant une exclusion mutuelle. Une dfinition d'implantation est donne ci-dessous selon un graphe qui exprime: - en horizontal: les entres en provenance du matriel gauche, au centre les fonctions logicielles, droite les sorties vers le matriel, - en vertical: la rpartition des tches 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) contrle Gnration vitesse temps Maintenance Gestion touches

Touches

Diviseur H TACHE DE FOND ( vide )

matriel

Logiciel

matriel

-Figure 6.16- Spcification de l'implantation logicielle. La tche la moins prioritaire est la tche de fond. Le double trait vertical reprsente un appel procdural utilisable uniquement dans le sens croissant. 86 M.C.S.E

Ch 6 - UN EXEMPLE DILLUSTRATION L'implantation propose conduit aucune fonction dans la tche de fond. Celle-ci peut alors servir pour introduire des auto-tests par exemple. La vrification de cohrence de l'implantation consiste s'assurer que toutes les contraintes temporelles seront satisfaites dans les cas les plus dfavorables et que le processeur reste oprationnel: taux d'occupation < 1 pour les actions autres que celles incluses dans la tche de fond. Avec le diagramme ci-dessus, la vrification est facile en sasssurant que: - Trponse max < T excution max, - Tocc max = (Texcution max/priode minimum activation) < 1. Des points complmentaires sont tudier pour spcifier compltement l'implantation: il s'agit du format des variables internes pour satisfaire les prcisions, 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 oprations seront ralises en entier. 6.4.5. Spcification de la ralisation matrielle Cette dernire phase conduit dfinir le support matriel par une structure d'excution. Elle se dduit de la structure fonctionnelle complte en remplaant par abstraction, toutes les actions implantes en logiciel par un processeur programmable qui en assurera l'excution.

TOUCHES

AFFICHEURS

Processeur Programmable
RAM interne sauvegarde par batterie
IMP

ROM ou EPROM interne 4Ko 2 entres IT entres et sorties logiques pour Touches , Afficheurs et Cmd_Valve.
Cmd_Valve Gnrateur PWM CA

H HORLOGE

-Figure 6.17- Spcification de la ralisation matrielle. La spcification du processeur pouvait tre plus gnrale en y incluant l'horloge et mme le gnrateur PWM. M.C.S.E 87

Partie 1 - PRESENTATION DE LA METHODOLOGIE C'est partir de ces spcifications que le technicien charg de la ralisation, spcialiste des composants VLSI existant sur le march, tenant compte des contraintes de ralisation imposes, labore une solution matrielle dtaille sous la forme d'un schma logique. Pour cette application, effectue durant 1989, le choix peut se faire par exemple entre les monochips: - famille INTEL 8051 et drivs, - famille NEC 78 XX, - famille MOTOROLA 687XX. 6.5. CONCLUSIONS : QUELQUES REMARQUES A l'issue de cette prsentation de la dmarche sur un exemple de cahier des charges, faisons un point rapide sur l'apport de la mthodologie MCSE. Tout d'abord, aprs avoir pris uniquement connaissance du cahier des charges et donc avant d'avoir lu la solution propose, le lecteur pouvait-il rpondre aux 3 questions essentielles qui intressent le demandeur: - temps de dveloppement (dure du contrat), - cot du dveloppement (obtention d'un prototype caractre industriel), - cot de reproduction de la solution. Pour pouvoir y rpondre, il faut tout de mme avoir une ide assez prcise de la solution: matriel pour l'valuation du cot, 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 exprience importante dans le domaine du dveloppement des systmes microprocesseurs. Concernant la comprhension de la mthode et de la solution, aprs la lecture de ce document de conception, on peut penser que chacun a une ide claire: sur le fonctionnement du systme, sur les principes suivis pour l'laboration de la solution, sur des solutions des problmes classiques trouvs dans une varit d'applications. Si c'est le cas, le lecteur a dj assimil des lments essentiels de la mthodologie, a enrichi ses comptences dans le domaine des applications temps-rel, et ceci par simple lecture d'un document de solution. La facilit de comprhension de la solution rsulte des modles de description utiliss qui sont essentiellement graphiques: automates pour les spcifications, structure fonctionnelle, structure d'excution, schma d'implantation logicielle. Ensuite, la mthodologie part du cahier des charges et fournit toutes les informations ncessaires pour la ralisation: architecture de la solution matrielle, organisation du logiciel, description algorithmique en Pascal du comportement des fonctions. Par vrification, elle garantit a priori l'obtention d'une solution oprationnelle. Dernier point: avant mme de dbuter toute ralisation pratique (maquette, programmation) un document complet existe: comme guide la comprhension, comme support pour une analyse critique de la solution, plus tard comme document de maintenance du produit. Ultrieurement, Il faudra seulement y ajouter les schmas de la ralisation matrielle, et un listing comment pour le logiciel.

88

M.C.S.E

BIBLIOGRAPHIE 1

OUVRAGES [CALVEZ-82] Une mthodologie de conception des systmes multi-microordinateurs pour les applications de commande en temps-rel J.P. CALVEZ Thse 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] Mthodologie de conception pour les systmes complexes de commande en temps-rel 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

MODELES ET METHODOLOGIES

Avant de dcrire en dtail la mthodologie MCSE, il est utile de faire un panorama des Mthodologies existantes et des modles sur lesquels celles-ci sont bases. Cette connaissance se justifie car une mthodologie n'est pas opposer aux autres. Au contraire, certaines approches, certains points de vue et modles sont intressants et exploitables pour la classe des problmes qui nous proccupent. Le concepteur dcouvre ainsi tout ce qu'il peut ou pourrait trouver dans sa "bote outils". En dveloppement, les 3 phases qui nous intressent tout particulirement pour l'analyse des mthodologies sont celles: de spcification, de conception fonctionnelle ou conception prliminaire ou architecturale, de spcification de la ralisation ou conception dtaille. Lorsqu'une Mthodologie est plutt spcifique d'une phase, il est alors prfrable de parler de METHODE. Une mthode est base sur l'emploi d'un modle. La connaissance des modles est donc essentielle. Une mthodologie globale rsulte de la concatnation de plusieurs mthodes, chacune tant plus particulirement adapte une phase. Ceci s'explique par le fait qu'il est ncessaire d'exploiter des concepts diffrents et donc des modles diffrents pour chaque niveau d'abstraction de la solution. Dans cette partie, le chapitre 7 dcrit selon un ordre plutt chronologique les mthodes et mthodologies les plus connues dans le domaine des applications temps-rel. Pour chacune sont indiqus les modles utiliss. Le chapitre 8 est une synthse des catgories de modles les plus employs. Les types de modles pour la spcification et la conception sont dtailles, en montrant les utilisations prfrentielles. Une mthodologie est dcrite par une trajectoire dans un ensemble d'espaces de modlisation. 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 modles utiliss dans MCSE ainsi que la comprhension de la dmarche propose. 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 prsente succinctement les mthodologies existantes dans le domaine des systmes temps-rel. Afin de pouvoir interprter les caractristiques et particularits de chacune, les diffrences entre elles, rappelons tout d'abord les bases pour toute mthodologie introduites dans la partie 1, puis une classification et un historique des mthodologies. Une mthodologie conduit exprimer une solution selon un modle. Elle est donc obligatoirement base sur l'emploi de modles de description en entre et en sortie; ces modles dcoulent d'un ensemble de concepts. La mthode se spcifie elle-mme par un modle de rflexion exprimant comment procder pour spcifier ou concevoir. Les outils comme supports de travail sont ncessaires pour l'analyse, la description, la validation des solutions, la

M.C.S.E

95

Partie 2 - MODELES ET METHODOLOGIES production d'une ralisation. Ils n'ont de signification que comme aide l'application d'une mthode. Ainsi, une mthodologie peut s'analyser en regardant successivement les 3 points : modles, mthodes, outils. On se limitera volontairement dans ce chapitre aux 2 points essentiels que sont modles et mthodes. Concernant le modle de description d'un systme, il ne peut pas se baser sur l'hypothse que des descriptions diffrents niveaux d'abstraction diffrent seulement par l'chelle: principe du ZOOM. En effet, des composantes diffrentes interviennent dans un systme: vue externe, vue fonctionnelle, vue structurelle, vue matrielle... qui dpendent du point de vue adopt pour l'observation: utilisateur, matriel, logiciel, manager. Pour la comprhension des mthodologies, il est donc utile d'avoir l'esprit que diffrents concepts sont ncessaires 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 mthodologie est l'agrgation d'un ensemble de modles et de mthodes. Si une mthodologie peut tre analyse sur la base des 3 composantes: -modle(s), mthode(s), outil(s)-, un autre aspect concerne le style de la procdure de rflexion suivre qui peut varier d'un style "autoritaire" un style "libral". Selon C.J. TULLY, le style doit diffrer selon les objets concerns [TEICHROEW-83]. Pour qu'une mthodologie soit claire, et non ambigu, elle doit tre autoritaire pour les concepts et modles, car ceux-ci induisent la prcision de la description et ensuite lefficacit du processus de dveloppement et les outils. Ainsi, sans modle clair possdant une smantique explicite, il ne peut y avoir de bonne mthode, a fortiori doutil efficace. Par contre, la mthode doit laisser toute libert au concepteur pour les solutions, ceci permet d'exploiter au maximum l'esprit cratif des individus. Ainsi, une mthode se doit d'tre l'expression d'un ensemble de conseils, les rgles tant exprimes par le modle. L'efficacit des conseils est un autre critre important de comparaison des mthodes. En effet, l'objectif d'une mthodologie est de permettre un pourcentage le plus lev possible de concepteurs de russir des dveloppements de qualit. 7.1. CLASSIFICATION DES METHODOLOGIES ET HISTORIQUE La classification propose dans le tableau ci-dessous concerne les mthodologies orientes systmes temps-rel. Il indique approximativement pour chaque mthodologie la ou les phases du cycle de vie concernes et le concept essentiel en tant que modle. 96 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

PHASE Spcification

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 Activits Diagrammes flots de donnes Extension flots de contrle Diagramme de Jackson Graphes stimuli-rponse. Diagrammes flot de donnes et Graphes structurs Structures de donnes et rseaux de process Diagrammes R-NETS et F-NETS Diagrammes flot de donnes et et dcomposition fonctionnelle. Encapsulation d'objets Machine Charts et comportement temporel Algorithmique modle objet

Conception

Ralisation

Programmation structure Programmation oriente objet

La figure suivante rsume la gnse des mthodologies en indiquant quelques dpendances temporelles lies aux modles utiliss.
Encapsulation (Parnas) SMALLTALK (Xerox)

72-75

80
ADA

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

Structured Analysis (DeMarco) Programmation structure (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 ralisation Conception Spcification Mthodologies globales

-Figure 7.1- Evolution dans le domaine des mthodologies. M.C.S.E 97

Partie 2 - MODELES ET METHODOLOGIES L'intrt pour les mthodologies a commenc vers les annes 70 par le niveau le plus proche du produit final, c'est--dire la ralisation. Pour le matriel, la complexit des systmes a conduit les concepteurs dvelopper des composants de plus en plus complexes mais simples ct utilisation, et ceci par rutilisation des "objets matriels" dj conus et en exploitant les possibilits de lintgration. Pour le logiciel, la complexit des programmes et la varit des processeurs a conduit la ncessit de disposer de langages dits de haut-niveau, puis dune mthodologie induisant l'criture de programmes. De cette manire, est apparue la programmation structure. L'apport de cette mthode fut important, mais elle ne rsolvait que partiellement le problme de la complexit. La mthode dcoule de la ncessit d'une structuration en modules. C'est le dbut d'une approche architecturale correspondant la phase de conception. C'est aussi le tout dbut de l'approche Objet avec le concept de l'encapsulation. Presque simultanment, par 2 approches convergentes, fut constate la ncessit de spcifications pour concevoir : - approche par le problme qui se doit d'tre dfini correctement pour pouvoir rechercher une solution. - approche ascendante partir de la conception qui justifie un niveau de description de l'objectif satisfaire. Les mthodes de spcification diffraient par le point de vue adopt: diagrammes d'activits (SADT), diagramme flots de donnes pour les systmes de traitement, diagrammes entitsrelations pour les systmes d'information, diagrammes tats finis et du type stimuli-rponse pour les systmes de commande temps-rel. A partir des annes 80 se sont progressivement dveloppes des mthodologies globales couvrant l'ensemble du cycle de vie et ceci par agrgation des mthodes dj prouves (SA/ SD, JSD, SREM-SYSREM). Le concept Objet et l'apparition du langage ADA ont conduit l'laboration de nouvelles approches dites Orientes Objet et ceci tout d'abord comme techniques de ralisation (SMALLTALK, ADA), puis comme mthode de conception (OOD, GOOD ...). La suite du chapitre dcrit selon un ordre chronologique approximatif les mthodes orientes systmes les plus connues. 7.2. SADT La mthodologie SADT (Structured Analysis and Design Technique) fut dveloppe 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 spcifications, ceci de manire faciliter la communication entre analystes, dveloppeurs et utilisateurs. 7.2.1. Le modle La mthode est base sur l'emploi du modle SADT. Il permet de dcrire, par un ensemble de "botes" lies, l'enchanement des activits (Actigrammes), et la transformation des donnes (Datagrammes). Chaque "bote" du diagramme possde 4 types de liens avec son environnement comme lindique la notation ci-aprs. 98 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

- les entres ( gauche), - les sorties ( droite), - les contrles (au-dessus), - les mcanismes (en-dessous).
entres

contrles sorties

mcanismes

Par exemple pour la fonction Y = (A X + B), X est la donne d'entre, Y le rsultat en sortie, A et B sont des paramtres pour le contrle, les mcanismes sont les oprateurs de calcul. Chaque bote peut se raffiner selon un modle SADT. Il s'agit donc d'un modle hirarchique, mais les relations exprimes sont du type horizontal, le diagramme pouvant se mettre totalement " plat".
Vue globale du systme

3 4

Plus gnral

2 3

Plus dtaill

-Figure 7.2- Exemple de description hirarchique SADT. Ce modle est intermdiaire 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 donnes, sans la notion de mmoire d'informations (data files). Dans SADT, 2 types de modles sont exploitables: - le modle Actigramme, qui exprime les fonctions de transformation (Rectangles) agissant sur les donnes (les liens). Chaque rectangle correspond des verbes, et les liens des noms. - le modle Datagramme, qui donne une reprsentation oppose. Les rectangles correspondent aux donnes (les noms), les liens expriment les transformations sur les donnes. M.C.S.E 99

Partie 2 - MODELES ET METHODOLOGIES Ces modles sont duaux et redondants, ce qui permet de vrifier la compltude d'une analyse. L'un exprime la dcomposition des activits en montrant les objets manipuls, l'autre la dcomposition des donnes en montrant les activits qui les crent ou les utilisent. Comme illustration de ce modle, on donne ci-aprs un exemple d'actigramme.
C1 BASE PERIODIQUE

DONNEES CLINIQUES E2
CHOISIR LE PATIENT

Caractristiques du patient
Numro de lit Type de mesures Frquences des mesures ACQUERIR ET VALIDER LES MESURES

1 MESURES ANALOGIQUES E1

Limites spcifiques autorises Capteurs dfectueux

Donnes administratives Paramtres hors plage


CONTROLER LES VALEURS

Paramtres mesurs

MESSAGE DALERTE
ALERTER

S1 4
ENREGISTRER LES RESULTATS

Heure de lexamen RESULTATS EXAMENS S2

-Figure 7.3- Exemple de diagramme SADT. Ce modle est un outil gnral pour exprimer, comprendre, manipuler et valider des problmes. C'est donc typiquement un outil d'aide la spcification. 7.2.2. La mthode La mthode est celle de l'analyse structure (SA). Il s'agit tout d'abord d'une discipline de pense. La mthode est base sur un travail d'analyse orient flot de donnes qui conduit mettre en vidence les activits. La dmarche prconise un raffinement progressif de chaque activit, ce qui conduit des diagrammes hirarchiques. Le travail d'analyse conduit construire un modle fonctionnel SADT en passant par les phases suivantes: - faire les actigrammes et datagrammes du systme, - tablir les rfrences croises entre diagrammes, - corriger, complter l'analyse fonctionnelle, - introduire le squencement possible des activits, - identifier les mcanismes qui peuvent servir la ralisation des fonctions. 2 principes sont cits comme essentiels : - dlimitation du contexte. Chaque action doit tre vue comme faisant partie d'un systme 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 dcomposition d'un diagramme un maximum de 6 botes. La premire phase est la plus critique. L'obtention des diagrammes rsulte au pralable d'interviews d'experts du problme, de manire rassembler les informations ncessaires. Le travail pouvant se faire en groupe, plusieurs auteurs laborent la spcification de sousensembles simultanment et indpendamment. Les documents ainsi labors sont ensuite assembls et distribus auprs 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 base sur le contrle et la validation par les autres, assure une valuation continue de la qualit des documents produits. Cette mthodologie est considre comme gnrale et applicable toute situation et tout problme. D'autre part, elle est utilisable aussi bien au niveau individuel, qu'au niveau quipes pour des grands projets. Intressante pour l'analyse d'un problme, la mthodologie SADT est limite la phase de spcification. 7.3. STRUCTURED ANALYSIS Dveloppe par DEMARCO, il s'agit d'une mthode pour laborer les spcifications d'un systme ou d'une application [DEMARCO-79]. Elle conduit dcrire l'ensemble des activits et les donnes du problme. Cette mthode qui est typiquement une aide l'analyse est trs apprciable, ce qui explique son utilisation courante en phase de spcification dans plusieurs mthodologies. 7.3.1. Le modle Le diagramme flot de donnes est la base de cette mthode. Il comprend: le diagramme proprement dit qui exprime les relations entre les activits, la spcification des activits en langage naturel structur, la spcification des donnes (diagramme de JACKSON et modle entits-relations). Ce diagramme (Data Flow Diagram: DFD) est appropri pour l'analyse des transformations que subissent des donnes. Il spcifie le flot de donnes travers des fonctions ou des activits partir d'entres pour obtenir les donnes de sortie.4 types d'lments sont utiliss dans un tel diagramme: - l'activit ou processus: ce sont les actions effectues sur les donnes en entre, - la variable mmoire ou la "file": c'est une mmorisation de donnes, - la source et le puits: une source est une entit externe comme origine pour des donnes d'entre, un puit est une destination pour des donnes de sortie. - le lien: arc orient tiquet par les donnes en transit. Le diagramme des activits ainsi dcrit (figure 7.4) exprime les relations d'ordre entre les fonctions par l'intermdiaire de liens entre les donnes de sortie d'une fonction et les entres de fonctions consquentes. La "File" permet de reprsenter une mmorisation d'informations pour une exploitation ultrieure. 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

Raffinement de A2
V2

A2.1

A2.2

A2.3

-Figure 7.4- Exemple de diagramme flot de donnes. Les caractristiques d'un diagramme correct sont: - toutes les entres identifies sont situes gauche, - toutes les sorties sont situes droite, - les donnes doivent tre nommes pour l'identification et la dfinition du contenu, - les fonctions de transformation doivent tre nommes pour la comprhension de ce que subissent les donnes, - il n'y a pas de boucles dans ce type de diagramme. Le modle est hirarchique. Ainsi, il favorise une approche descendante par raffinement, puisque chaque activit peut tre dcrite par un diagramme flot de donnes. Pour une approche ascendante, il permet aussi d'assurer une coordination pour des approches faites sur des sousensembles par plusieurs analystes. Il est trs apprci comme outil de communication entre concepteur et demandeur durant la phase de spcification. Comme limitation, il exprime ni le contrle ni le squencement temporel des actions. Chaque transformation tant procdurale, on peut toutefois y assigner des contraintes de performances le long des chemins d'information. 7.3.2. La mthode La spcification d'une application ncessite tout d'abord d'analyser l'existant pour ensuite caractriser les fonctionnalits souhaites. Ainsi, 2 niveaux de description sont possibles: le niveau physique, le niveau logique ou conceptuel. La dmarche suivre, propose par DEMARCO, est prsente par le diagramme flot de donnes de la figure 7.5. 102 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

2.1 Analyse de lenvironnement

2.5

Diagramme Flot de Donnes (DFD) physique


2.2 BESOINS Transformation quivalence logique

Etude quantitative des options

DFD physique

Etudes des cots et des bnfices

2.4 DFD Etablissement des interfaces homme-machine 2.6 Slection des options

BESOINS PHYSIQUES

logique

DFD physique
2.3 Description logique du systme DOCUMENT DE FAISABILITE

BUDGET PLANIFICATION

Nouveau DFD logique Liste de donnes


2.7 Regroupement des spcifications

DFD slectionn

SPECIFICATION STRUCTUREE

Description de la transformation

-Figure 7.5- Dmarche pour l'analyse dans SA. Lanalyse de lexistant faite au niveau physique conduit par abstraction au niveau logique. Les fonctionnalits 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 systme souhait: spcification des DFD, des donnes, des activits, - drivation du document final qui consiste en une transformation de la description logique en une description physique: interfaces homme-machine, caractristiques oprationnelles et performances. Cette mthode s'avre efficace pour une approche globale des applications, ce qui explique son utilisation courante dans plusieurs mthodologies pour la phase spcification. Son efficacit apparat moindre lorsque l'approche est faite partir des entits de l'environnement du systme. 7.4. STRUCTURED DESIGN Cette mthodologie fut dveloppe par YOURDON et CONSTANTINE puis tendue par MEYERS entre 75 et 80 [JENSEN-79]. Adapte pour la conception prliminaire, elle est base sur une technique de transformation reposant sur les critres de qualit d'une dcomposition. Son intrt 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 modle Le modle diagramme structur (Structure Chart) a pour objectif de dcrire l'organisation d'un systme sous une forme hirarchique. Les relations entre les modules sont dfinies ainsi que les interfaces et la mthode de contrle.
( un module )

FONCTION

OBTENIR (appel conditionnel)

CALCULER

ASSIGNER

STOP DETERMINER EXTRAIRE (inclusion lxicale) FAIRE (2) FAIRE (1) FORMATER (module prdfini) IMPRIMER (priphrique physique) TABLE ( ensemble nomm de modules de donnes) (environnement oprant)

CONTROLE

DONNEES

CONTROLE et ou DONNEES

-Figure 7.6- Exemple d'un diagramme structur. Les rectangles reprsentent les modules. Les formes arrondies reprsentent les donnes accessibles sous la forme de tables. Le diagramme exprime partiellement le droulement temporel. Pour cela, il utilise les structures de contrle de base que sont: squencement, appel, itration, alternance. Sur les liens hirarchiques correspondant aux appels procduraux sont indiques les informations changes comme donnes ou comme contrle. Le rsultat dcoule d'une analyse structure. Utilis comme modle pour la conception prliminaire d'un logiciel squentiel, il se situe en amont de la programmation structure [JENSEN-79, MARTIN-88]. 7.4.2. La mthode Cette mthodologie utilise en entre les diagrammes flot de donnes de DEMARCO comme rsultat de l'analyse, et les diagrammes structures et structures de modules pour exprimer la solution. L'approche est base sur la transformation de diagrammes flots de donnes d'un problme en une structure de modules, ceci en exploitant une technique d'analyse de la spcification et des critres de dcomposition. 104 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES JENSEN et TONIES dcrivent la dynamique du processus de conception comme la conjonction de 2 forces: - la premire engendre la transformation: flot de donnes en structure de modules, - la deuxime engendre le passage d'une description de haut-niveau vers une description dtaille travers des niveaux successifs de raffinement.
Bonne dmarche 1 Mauvaise dmarche

Raffinement

2 2 B B

Flot de donnes
Conception Spcification

Modules
Solution

Flot de donnes
Conception Spcification

Modules
Solution

-Figure 7.7- Dmarches pour la recherche d'une structure de modules. Pour laborer une structure, la technique de transformation consiste identifier sur la spcification les 3 classes d'lments pour les activits: entres, actions, sorties. Le choix de 2 groupes permet de dduire le 3me. Au niveau le plus lev, les entres et sorties proviennent de l'environnement. On peut alors laborer une structure en 3 branches: entres/transformation/ sorties. Ceci correspond diviser le diagramme flot de donnes en 3 parties, comme l'indique la figure 7.8. Plusieurs solutions sont possibles pour la structure suivant le dcoupage adopt. Sur le DFD des critres de dcision sont utiliser, savoir essentiellement : la rduction du couplage entre parties et la cohrence fonctionnelle de chaque partie. Ceci revient placer les lignes de partition sur le diagramme flot de donnes de manire minimiser le nombre de franchissements. Ainsi le diagramme flot de donnes permet de dcouvrir par induction la structure de modules et les relations fonctionnelles. La procdure suivre est donc: - identifier le flot de donnes et construire le diagramme correspondant, - identifier les 3 ensembles de transformation: pour les entres, pour la partie centrale, pour les sorties. M.C.S.E 105

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

entre A donne X entre B donne Y donne Z

Transfor me A A Calcule C C Calcule D D sortie

Programme

A,B A saisie Transforme A A

B A,B

Transfor me B

B D
A

Transforme B

Calcule Calcule C D

Sort D

Calcule E D

Sort E E

Z Z Priph

Calcule E

E sortie
Priph Priph X Y

entre A donne X entre B donne Y donne Z

Transfor me A

Programme A Calcule C C Calcule D D sortie AB D Calcule E E sortie ACQ. AB C Calcule C Y Z Y Z D E Priph C C D Sortie D D E E Calcule D D

Transfor me B

Acq. A B

Sort Calcule Sort D E E

-Figure 7.8- Influence du partitionnement sur la structure. 7.4.3. Remarques Cette mthodologie aussi appel SA/SD, n'a de point commun avec SADT que l'approche du type flots de donnes pour l'analyse. Elle reste limite la conception des programmes squentiels. L'architecture du systme dcoule directement de la premire dcomposition modulaire. Si celle-ci n'est pas judicieuse, ce qui ne s'observe que durant les stades avancs de la conception, le travail doit tre repris au dpart. Ceci provient du fait que la mthode conduit une solution monolithique n'exploitant que des relations hirarchiques verticales. 7.5. METHODOLOGIE DE JACKSON (JSD) Cette mthodologie fut tout d'abord dveloppe vers 75 pour la conception des programmes: JSP (Jackson Structured Programming), puis fut tendue entre 75 et 80 la conception des systmes: JSD (Jackson System Development). Elle couvre aujourd'hui les 3 phases: Spcification, Conception Prliminaire, Conception Dtaille ou Implantation. Elle est approprie pour la conception des systmes d'informations et des systmes temps-rel [JACKSON-83, CAMERON-86]. Cette mthodologie est base sur la modlisation des donnes, par opposition SA qui est base sur la modlisation des activits par flots de donnes.

106

M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES L'ide essentielle de cette mthode est que la structure du systme concevoir se dduit de la structure et de lvolution des donnes que celui-ci doit grer. Le systme est conu comme lment de transformation des donnes d'entre en donnes de sortie. Elle est particulirement efficace lorsque l'ordonnancement des vnements dans le temps est significatif. 7.5.1. Les modles La mthodologie de Jackson utilise plusieurs modles, chacun adapt au niveau souhait pour la description: - diagramme de Jackson pour la structure des donnes et le comportement des entits, lors de la spcification, - rseau de process pour la conception fonctionnelle, - langage JSP pour l'implantation.
-A- DIAGRAMME DE JACKSON POUR LES ENTITES

Le diagramme de JACKSON permet de dcrire l'volution d'un objet ou d'une entit en exprimant le squencement des actions et des vnements pour l'objet. Il s'agit d'une structure d'arbre. Les feuilles sont les actions lmentaires. Les noeuds sont des oprateurs de squencement. Ce diagramme est donc utilisable pour la modlisation dynamique des donnes c'est--dire l'volution temporelle. Le diagramme est construit sur la base de 3 symboles auxquels correspondent 3 structures de contrle: - squence, - itration, - slection. Il dcrit ainsi l'ordre des vnements concernant l'entit, sans exprimer la dure entre chaque. L'exemple prsent sur la figure 7.9 dcrit 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 modle est compos d'entits considres comme "Process". Chaque process possde ses entres et sorties pour les donnes, et assure un traitement. Les process squentiels sont reprsents par des rectangles. Les cercles et losanges utiliss pour les relations, dcrivent 2 mcanismes de communication: - le flot de donnes (Data stream) pour le cercle, par l'intermdiaire de messages produits par un process et exploits par un autre. Le cercle reprsente une file FIFO de taille illimite. - 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 Squence

* o

itration slection

Acquisition

Enregistrement

Cycle de prt

Fin

*
Prt Vente

o
Echange

Dbut de prt

en prt

Fin de prt

Retrait

Expdition

*
Renouvellement

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

Rseau de Jackson
P1

Multiplicit de P1
F Niveau Rseau P2 Flot de donnes

Diagramme de Jackson

P1

P1

Synchronisation
L Niveau Process P2 Exploitation de L sur prsence de T P2 T

Etat
T

consultation de Etat

-Figure 7.10- Exemple de rseau de JACKSON et notation. 108 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Pour un rseau (voir figure 7.10), un rectangle ne reprsente que le type du process et non les instances. La communication se fait toutefois entre les instances. Les doubles-barres (situes du ct 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 concatnation des liens d'entre indique la concatnation des messages avant lecture pour n'en former qu'un seul, ce qui permet d'exprimer une synchronisation. Pour ce modle, chaque process est dcrit par une structure interne base sur des squences, slections, itrations. Ceci peut se reprsenter par tout modle comportemental, et tout particulirement par les diagrammes de JACKSON, ainsi que par une description structure telle que JSP. 7.5.2. La dmarche La mthodologie prconise une dcomposition du travail en 3 phases: - modlisation de l'environnement par recherche et description des entits du monde rel, - spcification des fonctions ncessaires pour obtenir les sorties, - volution des contraintes de temps et dfinition d'une implantation. La procdure de dveloppement consiste en 6 tapes: - recherche des entits/actions, - structure des entits, - recherche du modle initial, - dfinition des fonctions, - introduction des contraintes temporelles, - implantation. On dtaille ci-aprs chacune des tapes de manire avoir un aperu de la dmarche propose.
- A- RECHERCHE DES ENTITES ET ACTIONS

Il s'agit tout d'abord de dfinir le SUJET en dcrivant la ralit en termes d'entits, actions et vnements. Ceux-ci sont trouvs dans l'environnement du systme concevoir. Une entit a sa propre dynamique l'extrieur du systme. Elle est identifiable et peut se dcrire par des vnements et actions selon une relation d'ordre. Une action est considre comme atomique. Un vnement est un changement d'tat.
- B- STRUCTURE DES ENTITES

Chaque entit est ensuite spcifie. La modlisation 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 spcifier la dure entre les actions. Cette modlisation est essentiellement dynamique (what happens?, in what order?), et concerne chaque instance du type de l'entit.
-C- MODELE INITIAL

Le modle initial s'obtient en introduisant dans le systme, pour chaque entit de l'environnement, un processus de simulation de cette entit, ayant le mme comportement que celui dcrit 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 relle, est mis jour par des connexions du systme avec le monde rel de manire tre inform des actions et vnements dans l'environnement. La modlisation faite en -B- permet ainsi de dduire les observations ncessaires. La figure ci-dessous dcrit le modle initial pour un livre en faisant apparaitre les points dattente dvnements en provenance de lenvironnement.
Environnement
Commande Nouveau livre

Systme
Attente

LIVRE

Acquisition

Enregis.

Cycle de prt

Fin

Systme

Arriv livre

Attente

Ev livre

Modle livre

Prt

o Vente

o Echange

Inexistant

Attente

Dbut de prt

en prt

Fin de prt

Retrait

Expdition

Prt ou fin livre Prt ou fin livre Inexistant Renouvellement ou fin prt

Attente

Attente

Attente

* Renouvellement

Attente

-Figure 7.11- Exemple de modle initial pour le livre. Les processus sont rmanents pendant toute la dure de vie de l'entit. Ils restent en permanence en attente des vnements externes. L'tat n'volue que sur apparition d'un vnement. L'tat du processus est interne celui-ci et ne donne aucune information supplmentaire par rapport l'entit relle correspondante. Mais cet tat permet de dfinir les donnes mmoriser pour chaque entit: les actions dfinissent ce qui arrive, les donnes dfinissent ce qui doit tre mmoris sur ce qui arrive. Les informations ou vnements en provenance de l'environnement peuvent ne pas tre conformes la modlisation, par exemple: 2 emprunts suivre pour le mme livre. Cette observation de non-conformit peut servir ensuite l'laboration des procdures d'erreurs, ce qui conduit l'introduction d'un sous-systme d'entre pour la dtection et la correction d'erreurs. Pour l'implantation qui suivra, tous les processus identiques sont implants sous la forme d'une mme procdure travaillant avec des donnes propres chaque entit. Toutes les donnes sont alors mmorises dans une table ou base de donnes. Les actions correspondent ainsi la mise jour de la base de donnes. 110 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Il est important de constater que cette dmarche conduit modliser dans le systme son environnement par un modle de donnes (Data model), et non par un modle vnementiel (event model). Selon JACKSON, la modlisation par les donnes dduite des vnements est beaucoup plus stable que celle faite directement par des vnements, qui eux peuvent changer rapidement suite une volution des spcifications.
-D- DEFINITION DES FONCTIONS

Le concepteur spcifie ensuite les fonctions du systme dans les termes du modle. Ceci se fait par ajout de processus pour satisfaire les besoins du demandeur, et si ncessaire, par volution des processus existants. Plusieurs raisons conduisent devoir ajouter des processus: - l'laboration de donnes rsultats dduites des donnes reprsentatives des entits, - le traitement des erreurs de non-conformit de l'environnement au modle, - la ncessit d'une interactivit avec les utilisateurs: production de sorties en raction aux demandes en entre. Le dveloppement se fait donc d'une manire incrmentale. Les processus sont interconnects conformment au modle de rseau de processus, les relations sont du type: transfert de messages et consultation d'tat. Le transfert de messages est utilis pour spcifier une autre fonction d'effectuer des actions selon une relation d'ordre. Un vecteur d'tat est utilis pour un couplage par des donnes entre fonctions temporellement indpendantes. La figure 7.12 montre les 4 types de processus: - modlisation d'une entit, - traitement d'erreurs, - processus de sortie, - processus interactif.

Fonctions interactives

entit 1

Modle entit 1

Monde rel

Traitement des erreurs

Fonctions de sorties

Sorties

entit 2 Modle entit 2

-Figure 7.12- Exemple de rseau de processus. M.C.S.E 111

Partie 2 - MODELES ET METHODOLOGIES La spcification complte de la solution comprend 2 niveaux de description: - le rseau de processus squentiels communicants, - le comportement de chaque processus exprim par un diagramme structur ou par une description en langage structur. Les fonctions introduites dans le rseau sont gnralement mutuellement indpendantes. Ainsi, elles peuvent tre dveloppes sparment. 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 considration de temps. Or, le monde rel gnre des vnements conformment des spcifications temporelles. Des retards peuvent apparatre ds la solution retenue pour l'implantation. Il faut donc exprimer les retards potentiels et dterminer avec l'utilisateur les dlais acceptables: validit des donnes, retard au traitement d'un vnement, conformit du modle la ralit... Ces dcisions servent de contraintes pour la phase d'implantation.
-F- IMPLANTATION

2 problmes sont rsoudre: - aboutir l'excution de tous les processus sur une structure matrielle possdant moins de processeurs, - assurer la mmorisation des donnes de l'application. Le premier point concerne le partage du ou des processeurs. Pour cela, il faut dcider d'une stratgie d'ordonnancement. Ceci s'effectue par transformation des processus en procdures avec passage du contexte courant comme argument. Cette transformation permet de sparer les donnes du code excutable. Une copie des donnes spcifiques ou contexte doit exister pour chaque processus. De plus, la combinaison des processus permet de simplifier l'implantation. Par exemple, un rseau de processus est transform en un programme principal et une hirarchie de sousprogrammes. JACKSON prconise la technique d'inversion pour la rduction de complexit. La figure suivante montre le rsultat 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 procdural, R sollicite d'abord linformation F P, puis G Q. Dans la technique du pouss, les fonctions sont sollicites toujours par appel de procdures mais dans le sens du flot de donnes. 7.5.3. Remarques JSD conduit une solution hirarchique, sans que cela rsulte d'une dmarche compltement descendante. La spcification et la conception sont plutt du type incrmental. La modlisation de l'environnement sert de contexte pour les spcifications fonctionnelles: l'ensemble des fonctions possibles pour le systme sont induites par le modle. Les modles des entits sont plus stables que les fonctions. Si la vue de la ralit change et donc les spcifications, les fonctions doivent changer, mais pas obligatoirement les modles (diffrence 112 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES entre structure et comportement). La dmarche prconise de dcrire d'abord l'existant. Ensuite, la spcification des fonctions sert dcrire quelque chose de nouveau. Mais, il n'est pas toujours facile de se fixer une modlisation de la ralit sans aussi une certaine ide de l'utilit du modle.
Technique du tir Technique du pouss

F R H

F R H S D

G C

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 limplantation. Les phases A E sont orientes utilisateurs, tandis que la phase F est purement technique. Les phases C et D conduisent dfinir une solution en conception sous la forme d'une structure interne, alors que les spcifications ne sont pas encore labores. La mthode conduit donc mixer par itrations, spcification et conception fonctionnelle. La solution rsultante ne peut donc pas tre optimise, ce qui reporte ce travail vers l'implantation. Cette mthodologie apparat complte et approprie pour la conception des systmes d'information. MCSE dans l'esprit est assez proche de cette dmarche mais sapplique plus particulirement aux systmes temps-rel. 7.6. SREM SREM (Software Requirements Engineering Methodology) a t dveloppe par TRW depuis 1975 [ALFORD-82,-85]. Cette mthodologie est principalement oriente: laboration, vrification, validation des spcifications, et concerne les applications temps-rel et rparties pour le traitement des donnes. Elle permet d'effectuer une laboration progressive des spcifications en transformant le cahier des charges en une description de plus en plus formelle. Les performances attendues du systme peuvent aussi tre inclues dans la spcification. Cette mthodologie a ensuite t tendue par SYSREM pour la conception et l'allocation des ressources, puis DCDS pour les systmes distribus. 7.6.1. Le modle SREM est base sur l'emploi d'un automate tats-finis structur: appel R-NET (Requirement-Net). Il exprime l'volution des sorties et de ltat partir des entres et de l'tat courant. M.C.S.E 113

Partie 2 - MODELES ET METHODOLOGIES Ce modle est issu du diagramme tats finis avec des extensions lui donnant un caractre de structuration de haut-niveau. Il permet de spcifier des traitements sur un ensemble d'entres pour produire un ensemble de sorties. Ce rseau est du type stimuli/rponses. Les entres sont structures en ensembles de messages, chacun tant fourni par une interface connecte l'environnement. Les sorties sont structures de la mme manire. L'tat S du rseau est le produit cartsien des informations connues du systme. Chaque diagramme R-Net dcrit la transformation d'un message d'entre 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 modle utilise les symboles suivants: - le symbole de Dpart (START), - l'interface d'entre, qui accepte un message de l'extrieur, - l'interface de sortie, qui transmet un message l'extrieur, - les fonctions (ALPHA) qui spcifient des transformations, - un sous-rseau (sub-net) dfinissant un graphe de traitement possdant un point d'entre 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 parallles. - un noeud REJOIN-ET pour exprimer une convergence ET, - le noeud SELECT pour la slection d'un message d'entre compte-tenu de l'tat courant, - le noeud FOR-EACH spcifie que tous les lments d'une liste doivent tre traits. Ce modle est hirarchique car il permet le raffinement progressif des noeuds du type sousrseau, l'aide de diagrammes R-NET. Il est appropri pour exprimer les relations: stimulis ==>Rponses, et il permet aussi d'expliciter les performances satisfaire et les contraintes de temps. Les contraintes s'expriment par des temps minimum et maximum attachs des chemins travers le graphe RNET. Les points caractristiques du rseau pour ces vrifications de performances sont appels points de Validation. Les diagrammes sont ensuite traduits en RSM (Requirements Statement Langage) bas sur les lments, attributs, relations et structures. 7.6.2. La mthode SREM pour la spcification La mthodologie SREM pour l'laboration des spcifications stipule de travailler selon les phases suivantes: - Identification de l'interface entre le systme et l'environnement et description des donnes et traitements. - Etablir une premire description en utilisant des R-Nets. - Spcifier les donnes et le comportement des fonctions ALPHA en RSL. - Ajouter les informations de management: chances, points d'analyse, outils. - Valider la spcification par une simulation fonctionnelle en utilisant les points de validation. - Identifier les spcifications de performances et contraintes de temps. - Faire une tude de faisabilit pour garantir le systme. 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

FOR EACH

SUBNET

&

"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 mthode SYSREM pour la conception Se pose ensuite le problme de la transition des spcifications en une solution de conception. C'est l'objectif de SYSREM. M.C.S.E 115

Partie 2 - MODELES ET METHODOLOGIES Une prsentation globale de la mthode est indique par la figure 7.15. Des sous-ensembles de R-Nets sont traduits sous la forme de tches. Les fonctions ALPHA induisent une dcomposition modulaire qui sont des procdures pour les tches. Les tches sont alloues sur une architecture matrielle. Le dveloppement d'une solution se fait selon les phases suivantes: - Dfinition du systme, ceci conformment SREM, - Identification des composants et sous-systmes pouvant intervenir dans le systme, - Dcomposition du systme qui se fait sur la base de principes noncs dans la suite. On exprime ainsi le squencement et le paralllisme des fonctions, - Allocation par association des fonctions sur les sous-systmes ou composants. Plusieurs solutions sont possibles. - Estimation du cot et de la faisabilit. Chaque sous-systme est valuer, comptetenu de l'allocation. Toutes les interfaces sont dfinies pour assurer le couplage fonctionnel entre les sous-systmes, - Evaluation des parties critiques et des ressources, - Introduction de la tolrance aux fautes par addition de fonctions, - Plan d'intgration et de test, - Optimisation de la conception.

SPECIFICATION

&

TACHE 2

TACHE 1 Conception fonctionnelle

Conception Modulaire N1 M2 M1 N3

Utilitaires

N2 Architecture matrielle

-Figure 7.15- Une vue globale de la Mthode SYSREM. 7.6.4. Remarques La mthode SREM est intressante pour la spcification compte-tenu du modle stimulirponse qui permet de faire une approche efficace partir de l'environnement et d'exprimer des contraintes de performances. Des vrifications de cohrence sont aussi possibles. 116 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Comme limitation, n'tant pas bases sur un modle hirarchique, les spcifications doivent tre explicites un niveau de dtail important. Le passage de la spcification une conception prliminaire n'apparat pas vident. Non utilisable pour spcifier la conception d'une solution rpartie, la mthode SYSREM a t tendue par DCDS (Distributed Computing Design System). 7.7. METHODOLOGIE DE WARD ET MELLOR (SDRTS OU RTSA) Cette mthodologie (Structured Development for Real-Time Systems) aussi appele RTSA (Real-time Structured Analysis), a t dveloppe pour la spcification et la conception des applications temps-rel [WARD-85]. Elle apporte les complments ncessaires SA/SD de manire corriger pour les systmes temps-rel, les limitations des diagrammes flots de donnes et celles de la conception structure. 7.7.1. Le modle La mthodologie est base sur l'emploi de 2 modles: - le modle essentiel lui-mme compos de 2 parties: le modle denvironnement qui dcrit lenvironnement dans lequel le systme va oprer, le modle de comportement du systme concevoir. - le modle d'implmentation dcrivant la solution selon 3 niveaux hirarchiques: les processeurs, les tches, les modules. Les 2 modles ci-dessus, appels schmas de transformation, sont bass sur le diagramme flot de donnes de DEMARCO (DFD) auquel est ajout un diagramme complmentaire exprimant le contrle de l'volution du DFD. Cette partie est appele diagramme flot de contrle (CFD reprsent en pointill). Une activit de ce diagramme agissant sur les activits du DFD est spcifie par un modle tats finis (automate, table de dcision...). Le modle utilise aussi les diagrammes entits-relations pour la spcification des donnes et des constituants de l'application. Lexemple de la figure 7.16 illustre ce modle de spcification. Les actions de contrle d'volution des activits sont de 3 types: ENABLE (autorise) pour l'activation, DISABLE (inhibe) pour l'arrt de l'activit, TRIGGER pour une activation ponctuelle. Les lignes de donnes sont de 2 types: vnementiel, ou continu (double flche). Comme pour le diagramme flot de donnes, ce modle permet une approche progressive de la spcification par raffinement des activits comme le montre la figure 7.17. Le modle d'implmentation est structur en 3 niveaux: - le niveau processeurs, qui dcrit toujours par un diagramme du type flot de donnes, les processeurs de l'application, les relations et interfaces entre eux. Chaque processeur sera responsable d'une partie du modle essentiel. - le niveau tches, qui exprime pour chaque processeur, les tches et relations entre elles. Ce niveau modlise l'architecture du logiciel. - le niveau modules, explicitant la dcomposition de chaque tche. Le modle prconis 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 DENTREE 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 DENTREE

STOP INHIBE "MAINTIEN pH"

-Figure 7.16- Le modle de spcification de WARD et MELLOR. 7.7.2. La dmarche Le dveloppement d'une application consiste trouver les 2 modles. Tout d'abord, la phase de recherche du modle essentiel consiste en [WARD-85, vol.2]: - une modlisation de l'environnement ce qui ncessite: de dcrire le diagramme du contexte (dlimitation du systme), de trouver l'ensemble des vnements pour lesquels le systme devra rpondre. - la modlisation du systme qui exprime son comportement en rponse aux vnements de l'environnement. Pour cela, il faut exprimer par raffinements successifs, le schma de transformation (DFD+CFD), puis le schma des donnes, ainsi que les spcifications des activits et des donnes. Ensuite, la phase de recherche du modle d'implmentation consiste assurer la correspondance entre des portions du modle essentiel et chaque lment technologique. Elle ncessite les tapes suivantes [WARD-85, vol.3]: - Identification des processeurs indispensables comme support pour le modle essentiel. Ceci s'obtient partir d'une rorganisation du modle de spcification. - Rorganisation du schma de transformation pour chaque processeur, de manire faire apparatre les tches, les interfaces, la gestion des donnes et l'ordonnancement de celles-ci. - dfinition du schma d'implmentation de chaque tche sous la forme d'une hirarchie de modules (utilisation de la mthode YOURDON et CONSTANTINE). 118 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

Maintien vitesse
contrle valve position valve vitesse de rotation Vitesse Moteur marche / arrt

frein

1 Observation 2
moteur Autorise / inhibe Maintien etat actif

reprise

Start/stop augmentation vitesse

Start / End kilomtre mesur contrle vitesse de croisire

Vitesse

Vitesse de rotation

Autorise/inhibe

2.4 Vitesse actuelle


reprise frein position valve

Autorise / inhibe

2.1 Mode opratoire

Contrle vitesses de croisire

Autorise / inhibe Facteur de conversion vitesse

Autorise / inhibe vitesse de rotation

2.2 Gestion du mode contrle

Start/stop augmentation vitesse

contrle 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 modle 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 suprieur. La figure 7.19 montre un tel rsultat. Selon les auteurs, sur la base des 2 modles, plusieurs dmarches de dveloppement sont possibles. Comme extrmes, citons: - modle essentiel complet, puis modle d'implmentation, - itration par niveaux entre les 2 modles (modle spirale). La figure 7.20 indique la dmarche par itration. 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 tche 1.1.1

Groupe tche 1.1.2

Tche 1.1.1.1

NIVEAU MODULES
Tche 1.1.1.1

-Figure 7.18- Les 3 niveaux du modle d'implmentation.

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 : Spcification de transformation P : Processeur

-Figure 7.19- Rsultat l'issue d'une rorganisation. En conclusion, si l'approche diagramme flot de donnes s'avre efficace, cette mthode apparat complte et adapte aux applications multi-tches temps-rel. Toutefois, elle ne concerne que la partie logicielle, puisque la partie matrielle reste a priori suppose dfinie car dans la mthodologie rien n'indique comment la dduire. 120 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES


.

Modle essentiel

Implmentation

Niveau 1
Spirale du dveloppement

Niveau 2

Niveau 3

Produit final

-Figure 7.20- Les 2 modles et la dmarche spirale. 7.8. METHODOLOGIE de HATLEY et PIRBHAI Cette mthodologie est trs proche de celle de WARD et MELLOR dans l'esprit et par les modles prconiss. Elle est donc aussi adapte la spcification des systmes temps-rel [HATLEY-87]. 7.8.1. Le modle La dfinition d'un systme est compose de 2 parties: - la spcification du systme, - l'architecture du systme. Le modle de spcification est le diagramme flots de donnes (DFD ou process model) auquel a t ajoute une spcification du contrle (CFD ou Control model). La figure 7.21 donne un exemple. Ce modle est trs similaire celui de WARD, mais avec une notation diffrente pour les activits de contrle et une signification diffrente pour spcifier les tats actifs et inactifs des activits de transformation. Il apparat plus structurant pour la partie contrle. Le modle d'architecture spcifie le partitionnement du systme en ses sous-ensembles physiques. Le diagramme des modules (AFD) dfinit les modules et les relations fonctionnelles entre eux. Le diagramme d'interconnexion (AID) dfinit les moyens pour l'change entre les modules. Ce modle est prsent sur la figure 7.22. Le passage de la spcification - qui se veut indpendante de la technologie - l'architecture ncessite d'ajouter les parties interfaces: entre, sortie, utilisation qui elles sont lies la technologie. Le modle de structuration ou de dcomposition prconis est reprsent sur la figure 7.23. Autour du "noyau dur" que constitue la spcification du systme indpendante de la technologie, sont ajouts 4 sous-ensembles rechercher: la gestion des entres, la gestion des sorties, l'interface utilisateur, les fonctions de maintenance sret et test. M.C.S.E 121

Partie 2 - MODELES ET METHODOLOGIES

comptage distance

comptage kilomtre

paramtres de rfrence

Bote de vitesse

Mesure vitesse

Mesure km

vitesse enclenche

Roue
Acclration, vitesse. rotation distance

Freins
Freinage

commande Valve
position valve

panneau de contrle

valve

Affichage Quantit de carburant

Conducteur

dbut acc. fin acc. reprise en marche

commandes

Moteur
(activit de contrle)

-Figure 7.21- Exemple de Spcification (DFD+CFD)

A B K LE SYSTEME H G F J

E DIAGRAMME FONCTIONNEL C B H N MA3 M MA1

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 LARCHITECTURE

SPECIFICATIONS DES INTERCONNEXIONS

-Figure 7.22- Le modle d'architecture d'un systme. 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 modle pour la mthodologie de HATLEY.


OBJECTIFS DU SYSTEME

Besoin du systme

Modle architectural du systme

Spcif. du systme

Spcif. du systme Extensions de larchitecture

Modle architectural du systme

Technologiquement indpendant

Non-spcifique technologiquement

Technologiquement dpendant

-Figure 7.24- Procdure de spcification d'un systme. 7.8.2. La dmarche Elle consiste trouver les 2 parties de la dfinition du systme. La mthode consiste rechercher tout d'abord les spcifications indpendamment de la technologie. Le modle est ensuite enrichi par les interfaces: entres, sorties, utilisateur, et les aspects maintenance et sret. Pour finir, il s'agit de dduire l'architecture du systme avec les 2 parties, le matriel et le logiciel. Cette dmarche est illustre par la figure 7.24. M.C.S.E 123

Partie 2 - MODELES ET METHODOLOGIES Le dveloppement peut se faire en sparant les 2 parties, mais aussi et surtout selon un processus itratif (modle spirale) entre les spcifications et l'architecture pour les 3 parties: systme, matriel, logiciel (idem WARD). 7.9. METHODOLOGIE DE LAVI ET HAREL (STATEMATE COMME OUTIL) Cette mthodologie est base sur l'association de 3 vues pour la modlisation d'un systme: activits, contrle, implantation. Le modle de contrle est le STATECHART de HAREL. Un outil appel STATEMATE a t dvelopp comme support [HAREL-88, LAVI-88]. 7.9.1. Le modle ECS (Embedded Computer Systems) Ce modle permet de dcrire un systme mono ou multi-calculateurs et les sous-ensembles et modules logiciels associs selon une dcomposition multi-niveaux. Il est bas sur le principe de la dcomposition d'un systme en sous-systmes assurant chacun une fonctionnalit, et un contrleur charg de la coordination des sous-ensembles. La figure ci-dessous illustre ce modle.

LE SYSTEME ET SON LOGICIEL

Donnes de contrle externe Contrleur systme Donne de contrle

Environnement du systme

Environnement du systme

soussystme 1

soussystme 2

soussystme 3

soussystme 4

Donnes process Donnes de contrle Information de retour Donnes de contrle externes

-Figure 7.25- Le modle ECS. Ce modle conceptuel reprsente les liens donnes et contrle entre l'environnement et le systme, et en interne entre les sous-systmes. Chaque sous-systme assure une fonction spcifique dfini par son comportement. Il peut aussi se dcomposer selon le modle ECS. Le comportement est dfini par un diagramme type flot de donnes. 124 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Le contrleur dfinit le comportement de l'ensemble des sous-systmes sous sa dpendance: modes, transitions, activations. Son activit est habituellement dcrite par un automate tats finis, ou plus spcifiquement par une extension appele STATECHART. Le STATECHART [HAREL-87] a t dvelopp comme extension du diagramme tats finis de manire rduire ses limitations. Essentiellement, il permet de reprsenter une description hirarchique et structure, des actions ou activits simultanes, des conditions de transition complexes. Pour se limiter aux caractristiques principales de ce modle, il permet: - le raffinement en dtaillant un tat par un ou plusieurs automates. Dans le cas de plusieurs automates, il y a volution parallle (quivalence avec la convergence ET et la divergence ET du Grafcet), - la spcification explicite ou par dfaut d'un tat de dpart 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'intrt et la simplicit de ce modle.
Montre quartz multi-alarme
Bloc principal Alarme 1
arrt alarme on alarme off Arrt marche carillon off carillon on arrt b ^ b marche pile te pile en place Arrt total

Carillon

Lumire

Alarmes Affichage Bip

Alarme 2

Rien 1 heure Bip 2 sec.

Alimentation

arrt alarme on

ok pile faible

pile morte

off

clign.

marche

-Figure 7.26- Spcification pour le fonctionnement d'une montre. Ainsi le modle complet permet la description du systme en cours de dveloppement selon 3 vues comme l'indique la figure suivante: - la spcification de l'architecture (module-charts) qui dcrit les modules logiques et physiques, ainsi que l'environnement. - la spcification des activits (activity-charts) comprenant une partie flot de donnes et une partie contrle (description proche de celle de WARD). - la spcification du contrle (statecharts). M.C.S.E 125

Partie 2 - MODELES ET METHODOLOGIES

Activity chart

State chart

FONCTIONNALITE
Dcomposition fonctionnelle et Flot de donnes

COMPORTEMENT
Contrle et Relations temporelles

Description du systme

STRUCTURE
Dcomposition physique et Flot de donnes

-Figure 7.27- Les 3 vuesM d l la h t pour description d'un systme. 7.9.2. La dmarche La mthodologie prconise une analyse itrative de manire exprimer progressivement toutes les exigences du systme concevoir. Pour chaque niveau de dcomposition, il s'agit d'laborer toutes les vues du systme. La procdure consiste suivre les tapes suivantes: - expression du besoin, faite en collaboration avec le client, - dfinition du systme et de son environnement: dlimitation des entres et sorties et spcification du systme par une analyse flot de donnes. - dfinition des modes de fonctionnement du systme: utilisation de statecharts pour cette spcification. - premire dcomposition modulaire: utilisation du modle ECS pour identifier les soussytmes, selon des critres de modularit favorisant la rutilisation et la sous-traitance, - analyse des performances et revue des documents, - conception de l'architecture du systme. Il s'agit de dfinir la structure matrielle: systme multi-calculateurs, systme de communication..., - identification des activits et flots de donnes: spcification des activits de chaque sous-systme, des modules et le liens entre eux. - analyse dynamique et conception du contrleur. L'analyse dtaille du comportement global du systme selon les modes opratoires (statecharts) et du rle des modules permet de dduire la solution pour le contrleur. - vrification de cohrence, prototypage et simulation. 126 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES 7.9.3. Remarques Cette mthodologie dveloppe pour les besoins de Isral Aircraft Industries et l'outil STATEMATE sont appropris pour la spcification et la conception des systmes temps-rel ddis. Le statechart est un outil efficace pour l'expression d'un comportement. Le modle ECS est similaire dans l'esprit une dcomposition en 2 parties: partie oprative (sous-systmes ou modules), partie commande (contrleur). L'outil semble tre complet. Architectur autour d'une base de donnes, il permet la simulation interactive, la gnration 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 mthodologie concerne le dveloppement de logiciels pour les applications tempsrel. Une version rcente tendue DARTS/DA concerne des applications distribues sur un ensemble de noeuds lis par un rseau local [GOMAA-84,-89]. DARTS utilise comme modles: le diagramme flot de donnes pour la spcification, un modle de description de la structure interne de la solution appel "Process Structure Chart" dduit du diagramme ACP (Activity Channel-Pool) de la mthodologie MASCOT (Modular Approach to Software Construction Operation and Test). DARTS inclut un ensemble de rgles expliquant comment crer le diagramme de tches partir d'un diagramme flot de donnes. 7.10.1. Le modle pour DARTS Le modle graphique pour la conception dcrit la structure du systme comme un ensemble d'objets du type donnes et du type tches chacune associe des activits oprant sur les donnes. Les relations intertches ainsi dcrites reprsentent des mcanismes de communication et de synchronisation. Une simple synchronisation entre tches est reprsente par un vnement, tandis que des communications intertches sont possibles par: - une variable partage (pool), - un canal permettant le transfert d'un seul ou de plusieurs messages, et selon un couplage faible (tches asynchrones) ou selon un couplage serr (envoi avec acquittement: cas de tches synchrones). La figure 7.28 prsente l'exemple d'un tel diagramme. 7.10.2. La dmarche La mthodologie prconise de suivre les tapes suivantes: - Etablir la spcification par des diagrammes flot de donnes. Utilisation de la mthode RTSA. - Dterminer les tches volution parallle partir des DFD sur la base dun ensemble de rgles: dpendance des entres/sorties, excution priodique, cohrence fonctionnelle..., M.C.S.E 127

Partie 2 - MODELES ET METHODOLOGIES - Dfinir les interfaces ou les tches en dterminant les relations de couplage partir des DFD: communication, partage de donnes ou synchronisation. Ceci conduit au diagramme PSC (Process Structure Chart). - Conception pour chaque tche.

Programme

No programme commandes entres ordre


Gestion pupitre Analyse des commandes Interprteur 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

Lgende :
1 place

Contrleur robot

queue message avec rponse

E/S Robot

vnement variable commune

-Figure 7.28- Exemple de diagramme. La technique Structured Design est utilise pour dcrire la structure interne des tches orientes traitements ou transactions. Pour des tches de contrle, une approche par automates tats finis ou statechart est prfrable. L'extension DARTS/DA introduit 2 tapes aprs celle d'laboration de la spcification. Il s'agit tout d'abord d'tablir une dcomposition du systme en sous-systmes. Chaque sous-systme sera implant sur un noeud du rseau. La structuration est base sur les critres de cohrence fonctionnelle, de faible couplage, de performances. Ensuite, il s'agit de dfinir les interfaces entre les sous-systmes. Implants sur des noeuds diffrents, les couplages sont assurs uniquement par des communications par messages. Cette mthodologie est typiquement oriente vers la conception architecturale et dtaille des systmes temps-rel. 7.11. CONCEPTION ORIENTEE OBJET (O.O.D) Cette catgorie de mthodologies est oriente conception partir des donnes [ABBOTT85, BOOCH-83,86, COX-86]. La conception oriente objet est base sur le concept de l'encapsulation dfini initialement par PARNAS puis GUTTAG. Cette approche considre toutes les ressources, donnes et modules comme des objets. 128 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Chaque objet encapsule ses donnes et les procdures de manipulation de celles-ci. Des langages sont bass sur ce concept: SMALLTALK, C++, objective C, SIMULA, ADA, EIFFEL ... Sur ce concept, le dveloppeur peut crer ses propres abstractions ncessaires pour le problme. Le dveloppement orient objet est typiquement ascendant. Un commerce de composants logiciels serait ainsi possible, favorisant alors la rutilisation comme l'indique COX. 7.11.1. Le modle objet Un objet est une abstraction d'un lment du problme trait. Il s'agit d'une entit caractre dynamique possdant un tat interne. Une frontire appele interface, spare son "intrieur" de son "extrieur", seule partie visible pour son utilisation [BOOCH-83-86]. Ct utilisation, l'objet est dcrit par une spcification, c'est--dire les services ou actions qu'il peut assurer pour son environnement. Les demandes sont faites par des entres (gnralement des procdures). En interne, l'objet possde sa propre structure. Il rpond aux sollicitations externes et fait voluer son tat interne. Un objet correspond donc une entit logique forte cohsion fonctionnelle. Le couplage entre objets est faible et chacun est protg par encapsulation. Ainsi, pour cette technique, l'OBJET est l'unit de dcomposition logique, et non plus l'action ou la procdure comme en programmation structure. Selon les auteurs, le terme Objet est prsent sous une terminologie diffrente: - module ou package pour le langage ADA, selon BOOCH, - interprteur pour ABBOTT, - composant logiciel pour FREEMAN, COX. et avec des caractristiques diffrentes: - type abstrait de donnes (encapsulation de donnes), - volution autonome (objet du type tche), - hritage (objet SMALLTALK). Un objet hrite des caractristiques des objets pres. Dans la suite, les objets considrs n'incluent pas la proprit d'hritage. Le langage ADA est l'exemple type d'outil de description favorable pour une ralisation oriente OBJET des applications temps-rel. Toute unit ADA se compose d'une spcification et d'un corps. La seule compilation de la spcification est suffisante avant utilisation. Plusieurs types d'objets existent selon son rle [BOOCH-83]: - l'objet PROCEDURE comme encapsulation d'une suite d'actions squentielles, - l'objet PACKAGE comme encapsulation de ressources: donnes, programmes, - l'objet TACHE comme entit autonome, - l'objet GENERIQUE comme modle de composant logiciel. M.C.S.E 129

Partie 2 - MODELES ET METHODOLOGIES Selon BOOCH, ces types d'objets sont reprsents graphiquement comme ci-dessous:
Procdure Package Tche Procdure gnrique Package gnrique

Spcification

Body

Body avec sous-unit

-Figure 7.29- Symboles pour la reprsentation des types d'objet selon BOOCH. La figure 7.30 donne un exemple de reprsentation d'une solution l'aide de ces objets. Chaque objet est dfini pour son environnement par ses points d'entre et sa partie visible. 7.11.2. Dmarche pour la conception La dmarche propose par BOOCH peut se rsumer par les tapes suivantes: - dfinition du problme, - dveloppement de la solution sur le plan conceptuel, - formalisation de la stratgie. L'tape de formalisation de la stratgie comprend les phases suivantes [BOOCH 86]: - Identification des objets: il s'agit de faire apparatre les objets du problme qu'il faudra raliser, ainsi que leurs proprits caractristiques. Cette phase est bien entendu particulirement dlicate et dpend fortement du travail d'analyse fait en amont par d'autres mthodes. - Identification des oprations: l'objectif est d'identifier les actions que l'objet subit et provoque. Les verbes de la spcification fournissent des indications sur les oprations. - Etablir la visibilit: il s'agit d'tablir partir des caractristiques et des oprations, les relations avec les autres objets. Ceci revient intgrer chaque objet dans la structure de la solution. - Etablir l'interface: ceci revient dfinir les spcifications de l'objet en caractrisant son interface avec l'environnement. 130 M.C.S.E

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

Anmomtre

Capteurs de temprature de lair

Capteurs de temprature de leau

Capteur de position

Interrupteur darrt durgence Rpartiteur des messages

Base de donnes des capteurs

Transmetteur radio

Rcepteur radio

Rapports Voyant lumineux

-Figure 7.30- Exemple de reprsentation des objets et liens entre eux. Autre auteur, ABBOTT prconise aussi la conception oriente Objet comme technique de ralisation des constituants de l'application. Il base sa mthodologie sur l'emploi de 4 catgories de composants logiciels: - les objets donnes: data types, data structures, storage units. Ces objets sont purement passifs, - les objets oprations: ce sont les fonctions de base, - les objets transducteurs: ces composants transforment des donnes d'entre en donnes de sortie, - les objets Drivers: ces composants contrlent les autres composants. Pour dfinir l'architecture de l'application sur la base de tels composants interconnects, l'auteur adopte en amont une conception oriente flot de donnes comme guide. Il suggre d'organiser le systme tel que le flot de donnes dtermine les composants ou objets et leur ordre d'intervention. Ainsi, l'identification des objets se dduit dans ce cas d'une analyse flot de donnes (mthode SA). L'implmentation de chaque objet doit tre conforme sa spcification. Cette conformit est d'autant plus simple obtenir que l'implmentation dcoule d'une traduction la plus systmatique. La nature de la spcification a donc une grande importance. Pour cela, ABBOTT prconise une spcification de chaque objet par un diagramme tats finis qu'il appelle ROADMAP. De cette spcification particulirement adapte au concept d'interprteurs 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 mthode d'ABBOTT. Cet exemple montre les 2 aspects externe et interne dun objet: - le comportement respecter pour l'utilisateur, sous la forme d'un diagramme syntaxique qui spcifie ainsi le langage accept. Les autres squences sont invalides. - le comportement interne suivi par l'objet sous l'influence des sollicitations externes pour imposer le comportement souhait l'utilisateur. Assez rcente, la dmarche objet conduit des avantages certains pour la ralisation: - protection des objets par des interfaces bien spcifies, - rutilisation des objets, ce qui permet de rduire les cots de dveloppement (composants logiciels). - indpendance des objets: une volution interne n'induit pas de changements externes. Le concept OBJET est ainsi trs intressant, mais un travail important sur le plan mthodologique reste faire pour disposer d'une efficacit similaire celle qu'apporte la programmation structure pour l'criture de programmes. La difficult avec cette mthode est la phase d'identification des objets. Quelle analyse fautil faire pour dduire les objets? Une analyse base sur la modlisation des entits relles du problme conduit-elle une solution rationnelle? La rponse n'est srement pas simple. Si on se rfre toujours G. BOOCH dans [BOOCH-86], la mthode dcrite ci-dessus ne concerne que les phases de conception et de ralisation du logiciel et donc ne couvre qu'une partie du cycle de vie. L'auteur stipule qu' ce type de mthode, il faut associer en amont, pour crer une modlisation du problme, des mthodes d'analyse et de spcification tels que: JSD de JACKSON et les techniques orientes flots de donnes de DEMARCO ou GANESARSON. 132 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES Plusieurs autres mthodologies orientes Objet ont t formalises. Entre autres: - GOOD (General Object-Oriented Software Development) labore par SEIDEWITZ et STARK et pour les phases de spcification et de conception pour un dveloppement logiciel orient ADA. Le diagramme flot de donnes conduit une identification des entits [SEIDEWITZ-84]. - HOOD (Hierarchical Object-Oriented Design) drive d'une approche par machines abstraites et retenue par l'Agence Spatiale Europenne [HEITZ-87]. Lintgration des concepts dobjets, de structuration par hirarchie et dexpression du contrle, facilite le dveloppement dapplications de grande taille. - MOOD (Multiple-View Object-Oriented Design Methodology) utilisant la mthode d'analyse RTSA de Ward et Mellor pour l'identification des objets et des tches [KERTH-88]. - OOSD (Object-Oriented Structured Design) dfinie pour la conception architecturale des systmes. Le modle graphique pour la reprsentation de l'architecture permet une transition entre la mthode Structured Design et la conception oriente Objet [WASSERMAN-89]. - PAMELA (Process Abstraction Method for Embedded Large Applications) dveloppe par G. CHERRY et oriente vers les systmes temps-rel ddis. Cette mthodologie est oriente processeurs squentiels communicants, avec une transcription directe selon une structure de tches ADA [KELLY-87]. Pour rpondre la difficult didentifier les objets durant la conception, des rflexions sont entreprises pour induire les objets partir de la phase de spcification. Ceci conduit au dveloppement de mthodes de spcification orientes objet [BAILIN-89, KURTZ-89, WARD-89]. 7.12. SYSTEM DESIGN WITH MACHINE CHARTS Cette mthodologie (SDWMC) est prconise par R.S.A. BUHR comme une volution de SDWA (system design with ADA) qui tait spcifique pour une implantation ADA [BUHR84,-89]. Adapte pour les applications "behaviour-intensive", elle est base, d'une part sur l'ide centrale que l'architecture d'un systme est l'association d'une structure et d'un comportement, d'autre part sur le fait que les diagrammes sont la bonne manire de reprsenter les 2 aspects de manire permettre l'utilisation des outils CASE ou des outils de CAO. La structure est reprsente par des Machine Charts, et la mthode prconise est appele JRBS (Joint Refinement of Behaviour and Structure). 7.12.1. Le modle Le modle prconis pour la reprsentation de l'architecture d'un systme est une description par des Machine Charts. La syntaxe des icones est relativement simple, chacun possde une smantique prcise exprimant le comportement inter-composants. La reprsentation graphique est une mthode naturelle de pense pour les ingnieurs, elle facilite aussi la communication entre participants. La notation est drive des diagrammes de BUHR [BUHR-84]. M.C.S.E 133

Partie 2 - MODELES ET METHODOLOGIES Lobjectif par les Machine Charts est dexprimer: - l'architecture abstraite d'un systme, - le comportement par l'exemple, en exprimant des diagrammes temporels sur la base de scnarios d'vnements, - les spcifications oprationnelles abstraites ou formelles comme base pour l'analyse, l'animation, l'implantation: utilisation d'automates tats finis ou pseudo-code. Les Machine Charts sont bases sur un ensemble de symboles reprsents trs partiellement sur la figure 7.32. Les objets sont: des botes (boxes) correspondant une modularit de structure autonome (packages, modules, units), des "robots" qui sont les objets reprsentant la modularit de comportement (acteurs, process, tches), les "engines" qui sont les composants actifs. Les relations sont reprsentes par les "boutons" (buttons) et les "doigts" (fingers), la terminologie exprime directement la smantique de l'interaction souhaite. 2 types de relations Push et Push-Pull permettent de reprsenter des interactions asynchrones (activation immdiate), 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 smantique des 2 types de liaisons. La notation de BUHR donne ici n'est que trs partielle. La figure 7.34 permet de se faire une ide de la reprsentation graphique prconise et la figure 7.35 montre un diagramme de comportement induit par la structure. 7.12.2. La mthode Selon BUHR, la notation Machine Charts permet grce des outils la "compilation" d'une conception en un squelette de programme pour l'implantation, ceci d'une manire relativement automatique. Une mthodologie a donc pour objectif de permettre aux concepteurs de passer des spcifications 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 simultanes

Bouton activations en squence

-Figure 7.33- Notation et comportement pour les interactions. La mthode JRBS consiste exprimer la solution en recherchant simultanment 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 euxmmes. Ce dernier comportement drive d'un raffinement dit fonctionnel qui se dduit par la suite. La dmarche de conception est la suivante: - Spcifier par des Diagrammes flots d'vnements (EFD). L'application est dcompose en sous-ensembles. Les vnements reprsentent les interactions entre ces sousensembles pour les coordinations et les changes de donnes. Ce diagramme est du type structurel, tandis qu'un DFD est fonctionnel. - Rechercher les composants de l'architecture. Le concepteur est libre de procder squentiellement ou en mixant les approches structurelle et comportementale. L'approche structurelle conduit mettre en vidence les composants. Les relations vnementielles sont ensuite transformes en connexions explicites entre composants. L'approche comportementale est plus aise partir de spcifications comportementales. Les liens flots de donnes sont transformes en connexions induisant ainsi une structure. - Exprimer la fonctionnalit de chaque composant. Distinct de l'interaction entre composants, il s'agit de dcrire les donnes internes, les traitements sur celles-ci. La figure 7.36 rsume cette mthodologie en indiquant les 3 types de vues et les itrations possibles entre les vues. 7.12.3. Remarques Cette mthodologie est spcifique de la phase de conception prliminaire. La solution est recherche et exprime sur le plan architectural. La notation graphique favorise la comprhension, la vrification et une production automatique du squelette de l'application. L'ajot de la fonctionnalit de chaque constituant sous une forme algorithmique est simple. Ceci est donc une dmarche intressante vers l'utilisation d'outils de CAO. M.C.S.E 135

Partie 2 - MODELES ET METHODOLOGIES

Composants bien dfinis

"A"

"B"
M M "B" "A"

RR

RR

FWD

1 DIRECTORY 3
PARTNER GO

FWD

DIRECTORY

3
PARTNER GO "A"

Wait_id

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- Reprsentation du comportement pour l'exemple prcdent. 136 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

STRUCTURE

Automate , StateChart Machine chart

JRBS

STRUCTURE COMPORTEMENT
RB COMPORTEMENT FORMEL

COMPORTEMENT PAR LEXEMPLE

-Figure 7.36- Prsentation de la Mthode SDWMC. La notation graphique est malgr tout complexe, et semble plutt proche des problmes de ralisation: change synchrone ou asynchrone, partage de ressources, et apparait relativement lie aux concepts et mcanismes de ADA. La dmarche n'exprime pas clairement comment passer des spcifications une architecture, les modles de spcification ntant pas prciss. 7.13. METHODOLOGIE DE NIELSEN ET SHUMATE Elle est prconise par leurs auteurs pour la conception des applications temps-rel complexes avec utilisation de ADA (ADA Design Methodology) [NIELSEN-88]. Elle rsulte de l'association de la mthode DARTS pour l'aspect temps-rel, et des approches conception structure et conception oriente objet. Cette mthodologie repose sur les 2 concepts: machines virtuelles (LVM) et conception oriente objet (OOD). 7.13.1. Modles La modlisation d'un systme est base sur l'emploi d'un modle par niveau, des spcifications jusqu' l'implantation: - le diagramme flot de donnes pour les spcifications, - un diagramme de structure des process (PSC pour Process Structure Chart) pour dcrire la solution fonctionnelle (voir la mthode DARTS), - un graphe des tches parallles (CPG pour Concurrent Process Graph) qui dcrit l'implantation du diagramme prcdent, - un graphe des packages ADA (APG pour ADA Package Graph) qui spcifie 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 spcifications en utilisant les diagrammes de BUHR (SG pour Structure Graph), - le diagramme structur (structure chart) pour dcrire la dcomposition de chaque tche en procdures (voir Structured Design). 7.13.2. Dmarche De cette modlisation se dduit aisment la dmarche suivre. On ne donne ici que les diffrentes tapes avec une illustration sommaire pour montrer la nature des modles pour chaque niveau et la dmarche progressive niveau par niveau par alternance entre spcification et conception. 1- dlimitation des interfaces, 2- association d'un process pour chaque priphrique, ou entre, ou sortie, 3- spcification de la partie centrale du systme par un diagramme flot de donnes, 4- dtermination du paralllisme et donc des process (PSC), 5- dtermination des interfaces entre les process, 6- introduction de tches intermdiaires pour l'implantation des relations inter-process (CPG), 7- encapsulation des tches ADA en packages (APG), 8- traduction de la conception en ADA: spcification des objets et diagrammes de BUHR, 9- dcomposition des tches complexes (SD et OOD) et criture de l'implantation, 10-revue de la conception pour vrification. 7.13.3. Remarques Cette mthodologie apparat complte pour des applications temps-rel raliser avec ADA. Ceci n'est pas une contrainte imprative puisqu'une traduction peut aussi se faire dans un autre langage. Toutefois, elle suppose que la partie matrielle en tant que support est dfinie a priori. Elle concerne donc exclusivement la partie logicielle. Il n'est pas fait tat d'une phase prliminaire d'analyse de l'environnement, d'expression des fonctionnalits et des contraintes de temps. C'est donc plutt une mthodologie destine la conception puis l'implantation du logiciel d'un systme temps-rel. L'approche partir des diagrammes flots de donnes conduit une architecture interne relativement complexe au vu du nombre de tches ADA induit par la dmarche. Si la modularit savre bonne, les performances risquent d'tre faibles. 138 M.C.S.E

Ch 7 - PANORAMA DES METHODOLOGIES

1 2 3
vnement

SPECIFICATION

CONCEPTION

A3

Diagramme flot de donnes + contrle

Process Structure Chart

T1

4
A5 T2 A4 T2 T3
ordre

A1 T1

A2

A6

5
T3 ADA Package Graph

P1 T1

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 dmarche par les modles. 7.14. BILAN Aprs ce survol dont le seul objectif tait de fournir des indications sur les mthodologies existantes, il semble utile de faire un point rapide. Constatons tout d'abord que chaque mthodologie a ncessit de l'ordre de 10 ans pour tre relativement complte et connue au point d'tre assez largement utilise. M.C.S.E 139

Partie 2 - MODELES ET METHODOLOGIES Une mthodologie ne couvre pas obligatoirement tout le cycle de dveloppement. Ceci est un point important observer. Toutefois les plus rcentes qui rsultent de l'agrgation de mthodes prouves, ont pour but de couvrir au mieux l'ensemble du cycle. Force est de constater l'absence de mthodologie conduisant une dduction cohrente de solutions la fois pour la partie matrielle et pour la partie logicielle. La plupart des mthodologies supposent connue l'architecture matrielle et de ce fait sont plutt orientes Gnie Logiciel. Bien entendu, des outils se dveloppent comme support pour ces diverses mthodologies. Ceci est une condition ncessaire sur le plan industriel pour faciliter la gestion et le suivi de grands projets de dveloppement. 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 mthodologies. Nous laissons le soin chacun de rechercher au moment du besoin, les informations sur tous les produits susceptibles d'tre intressants. 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 mthodologie, et pas l'inverse: un outil n'induit pas une mthodologie. Aussi, il n'est pas possible de se faire une opinion correcte de l'apport d'un outil sans connaissances sur les mthodologies. Pour cette raison ce chapitre est utile car beaucoup d'outils sont bass sur les modles et mthodes qui y sont dcrits. Ce panorama sur les mthodologies n'est bien sr pas exhaustif; il n'est pas simple de toutes les connatre, puis de les rsumer en quelques lignes. Certaines sont plutt des drives d'autres mthodologies. Vu le nombre, il faut tre conscient qu'il s'agit d'un besoin tout fait rel. Ensuite, il est important de retenir que toutes les mthodologies sont bases sur une modlisation d'un systme. C'est partir des modles qu'il est plus facile de comparer les mthodologies entre elles, en analysant les classes de problmes traits, les modles de spcification, de conception et d'implantation. On peut constater l'importance de 4 catgories de modles qui se retrouvent dans la plupart des mthodologies : - le diagramme flot de donnes pour spcifier les activits, - le diagramme tats finis avec ses variantes pour le contrle, - le diagramme structur pour la dcomposition des programmes. - le diagramme de structure pour exprimer l'architecture. Dans chaque catgorie existe une varit de modles. Quels sont les modles les plus appropris ? Comment se situe la mthodologie M.C.S.E par rapport celles qui viennent d'tre dcrites? C'est l'objectif du chapitre suivant que de prsenter une synthse des modles afin que chacun puissse s'en servir comme guide pour la recherche et la comprhension des mthodes. En mme temps il indique le point de vue retenu pour MCSE.

140

M.C.S.E

Chapitre 8

PANORAMA DES MODELES

Un modle reprsente une description d'un systme rel, ou d'un systme qui deviendra ralit aprs sa conception, et ceci un certain niveau de dtail. Comme vues d'une application, les modles diffrent selon la description exprimer: description externe pour une spcification, description interne abstraite pour une solution de principe, description interne dtaille pour une solution de ralisation. Un modle est aussi utilis pour dcrire les caractristiques d'un systme concevoir. Il sert alors de base pour la vrification de ses proprits. Plus le modle est prcis et donc formalis, plus il facilite le travail d'analyse. Les caractristiques spcifies par un modle dpendent de la nature de celui-ci. Ainsi pour exprimer une proprit particulire, il s'agit de slectionner une classe de modles qui induit cette proprit. Vu la quantit et la varit des modles, ce chapitre prsente tout d'abord une classification des types de modles. Les mthodologies reposent essentiellement sur des modles conceptuels. En se basant sur les mthodologies dcrites dans le chapitre prcdent, les espaces de reprsentation communment utiliss pour exprimer la spcification et la solution sont dtaills dans ce chapitre. Cette prsentation permet de dgager les modles essentiels dcrits par groupe.

M.C.S.E

141

Partie 2 - MODELES ET METHODOLOGIES Comme synthse favorisant la comprhension et la comparaison des mthodologies, il est montr qu'en se basant sur 3 espaces de reprsentation, une mthodologie s'exprime comme une trajectoire dans ces espaces. La fin du chapitre explique la stratgie de dveloppement pour MCSE. 8.1. BASES POUR LANALYSE DES MODELES 8.1.1. Qualits des modles Un modle est une reprsentation abstraite de tout ou partie du rel. Le terme abstrait est prendre dans le sens simplification par limination des dtails non-utiles. Pour tre exploitable, un modle doit possder quelques qualits gnrales: - Abstraction: cette qualit est ncessaire de manire tre utilisable pour la description des systmes complexes. Elle rpond la ncessit d'exprimer le comportement de l'ensemble sans faire rfrence aux dtails de toutes ses parties. - Raffinement: un sous-ensemble du modle doit pouvoir tre dcrit l'aide d'un autre modle: du mme type pour une description progressive, d'un type diffrent pour complter la description ou exprimer un point de vue diffrent. - Lisibilit: le modle doit tre simple interprter. Ainsi les reprsentations graphiques sont gnralement prfres aux descriptions textuelles. Il est intressant de noter tout de suite l'intrt des modles graphiques qui favorisent la lisibilit par une comprhension globale amliorant ainsi la communication et la validation. La plupart des modles donnant lieu une reprsentation graphique dcoulent de la structure de graphe compose de noeuds et de liens entre ces noeuds avec ajot d'une interprtation pour exprimer la smantique du modle. 8.1.2. Classification des modles L'interprtation d'une situation, la comprhension d'un objet ou d'un phnomne conduisent une grande varit de modles possibles. De manire cerner les modles par grandes catgories, nous reprenons ici la classification donne dans [WILSON-86]. La distinction est faite entre 4 formes de modles: - les modles iconiques, qui sont des reproductions en miniature dun objet: voiture, avion, maquette de btiment pour des tudes en soufflerie par exemple. - les modles analogiques, qui exploitent une apparence physique diffrente du phnomne ou objet caractriser: rseau lectrique pour une suspension de voiture par exemple qui est la base du calcul analogique. - les modles analytiques, utilisation de relations mathmatiques et logiques pour reprsenter les lois physiques de comportement. - les modles conceptuels, bass sur l'emploi de symboles pour la reprsentation des aspects qualitatifs. Dans l'ordre, l'approche modlisation fait appel aux modles conceptuels avant d'utiliser les modles analytiques. Les modles analytiques permettent des vrifications par simulation directe ou par transformation en modles analogiques. Un concepteur utilise essentiellement ces 2 catgories. 142 M.C.S.E

Ch 8 - PANORAMA DES MODELES 8.1.3. Modles analytiques Les modles analytiques sont trs rpandus et trs varis. Ils sont utiliss comme moyen pour prdire ou estimer le comportement de certains aspects de l'objet ou de la situation concerne. Ils servent aussi comme moyen de validation. WILSON prsente un classement des modles en 4 catgories comme l'indique la figure ci-dessous.
Statique Dynamique

Relations

Relations diffrentielles

Dterministe

algbriques

Non dterministe

Relations statistiques et probabilistes

Relations stochastiques

-Figure 8.1- Catgories de modles analytiques. Les colonnes de la matrice montrent la diffrence entre les modles indpendants du temps et ceux qui en dpendent. Les lignes sparent les comportements certains et prdictibles des comportements incertains. 8.1.4. Modles conceptuels Dans ce chapitre, on s'intresse tout particulirement la catgorie des modles conceptuels. Ils servent diffrents objectifs: - clarifier une situation: par exemple, structure d'une entreprise et liens entre les services, - illustrer un concept: diagramme en boucle ferme pour l'Automatique par exemple, - dfinir une structure, des relations: interaction de cause effet entre des entits, - dcrire une mthode: les tapes du cycle de vie pour le dveloppement par exemple. Les 2 derniers cas d'utilisation sont les plus frquents en conception. Les types de modles conceptuels diffrent selon la nature des informations ou des situations reprsenter. La classification peut se faire selon plusieurs critres. Les catgories sont complmentaires. On indique ci-aprs quelques types de catgories.
-A- MODELE STRUCTUREL - MODELE COMPORTEMENTAL

Certains modles reprsentent une topologie d'entits. Ce type de modle est dit structurel. Les entits sont lies entre elles par des relations de dpendance. La dpendance peut concerner, des donnes, des activits, des vnements, des ressources... Cette dpendance n'est pas temporelle, elle exprime seulement une dpendance fonctionnelle. M.C.S.E 143

Partie 2 - MODELES ET METHODOLOGIES Une autre grande partie des modles servent dcrire le comportement d'une entit. Il s'agit l d'un modle comportemental, souvent exprim sous la forme d'un comportement temporel. Ces 2 catgories de modles sont considrer comme indpendantes ou "orthogonales". En effet, la dfinition de proprits pour l'une des catgories n'apporte aucune information pour l'autre catgorie.
-B- MODELE ACTIVITES - MODELE DE DONNEES

La modlisation peut concerner: - les activits: c'est--dire l'expression des actions spcifiques de l'entit. Ceci se traduit par une relation d'ordre des actions pour un modle comportemental, ou par une structure fonctionnelle pour un modle structurel. - les donnes: il s'agit d'une description des tats successifs d'une donne qui s'exprime ainsi par une relation d'ordre pour le modle comportemental, ou par la structure des donnes pour le modle structurel. Il est intressant d'avoir l'esprit la dualit qui peut exister entre activits et donnes. En effet, un modle de comportement pour une activit induit la possibilit de dcrire l'volution de la donne produite, et une modlisation pour une donne induit par dualit le comportement de l'activit pour assurer l'volution de la donne.
-C- MODELE VERTICAL - MODELE HORIZONTAL

Une description structurelle peut se faire selon 2 axes: - l'axe vertical: un niveau plus dtaill rsulte du raffinement de chaque entit du niveau suprieur. Les relations n'existent qu'entre niveaux conscutifs. Il s'agit dune dpendance hirarchique. - l'axe horizontal: un raffinement fait apparaitre exclusivement des relations horizontales. Les dpendances sont de nature fonctionnelle.
-D- MODELE CONTINU - MODELE DISCRET

Le modle continu dcrit l'volution permanente d'un comportement, tandis que le modle discret ne reprsente que des tats particuliers des instants spcifiques de l'objet.
-E- SYNTHESE DES CATEGORIES

Chaque modle conceptuel peut se positionner sur la base du tableau figure 8.2 qui bien entendu est utilisable pour positionner les mthodes par analyse de la nature du ou des modles employs. Pour mmoire, les modles analytiques entrent dans la catgorie des modles comportementaux. Si on s'intresse aux 3 phases: spcification, conception, ralisation, on peut dire d'une manire gnrale que: - les modles comportementaux servent plutt exprimer des spcifications de fonctions, - les modles structurels dcrivent l'architecture de la solution pour la conception. 144 M.C.S.E

Ch 8 - PANORAMA DES MODELES

Structurel

Comportemental

Activits

Donnes

Vertical

Horizontal

Continu

Discret

-Figure 8.2- Catgories de modles conceptuels. En s'intressant plus particulirement la conception, comme la solution d'un problme exprime simultanment pour les activits et les donnes des relations sur le plan structurel et celui des comportements, cette classification montre qu'une mthodologie ne peut pas tre base sur un seul modle. En effet, dcrire compltement un systme (et donc le concevoir) ncessite de pouvoir exprimer diffrents 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 prcdent, on retrouve en parcourant l'ensemble des mthodologies une utilisation de la plupart des catgories de modles conceptuels. Aussi aprs avoir donn une premire classification des types de modles, intressons-nous tout particulirement ceux utiles pour dcrire les systmes concevoir. Pour se faire une ide prcise de l'essentiel, diffrencions tout d'abord 2 objectifs pour la modlisation: - spcification: il s'agit d'exprimer les caractristiques de l'"objet" dvelopper et ceci au maximum selon une vue externe: comportement, proprits, contraintes. - conception: il s'agit alors de donner une description interne la plus explicite possible de la solution: structure, comportement des constituants. Dtaillons les principes de modlisation pour chacun des 2 problmes. 8.2.1. Modlisation pour les spcifications Pour respecter la rigueur du terme spcification, une modlisation doit tre purement externe. Elle exprime alors exclusivement le comportement observable, ce qui se dcrit par un ensemble d'noncs dans un langage formel: utilisation de rgles, relations, pr-conditions et post-conditions, prdicats, description axiomatique. De toute vidence, cette technique de modlisation est peu utilise dans les mthodologies 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 faon de modliser consiste exploiter des modles dits explicites. Le terme "explicite" est comprendre dans le sens de l'utilisation de donnes ou dtats priori internes. Par exemple, un diagramme flots de donnes fait tat d'activits et de donnes internes, un automate tats finis considre des tats internes de l'objet spcifi. Pour toutes les mthodologies cites dans le chapitre prcdent, les modles entrent dans cette catgorie. Une raison essentielle justifie ce choix: l'objectif c'est de concevoir partir de la spcification, aussi plus tt dispose-t-on de renseignements internes, plus rapide sera la conception, sans toutefois confondre spcification et solution. La modlisation "explicite" d'un systme dpend du domaine d'applications et par consquent du point de vue adopt. Pour les spcifications on peut noter aujourd'hui un certain consensus pour une modlisation selon 3 vues complmentaires comme l'indique la figure 8.3. Les 3 vues correspondent 3 espaces de reprsentation: - espace des donnes, - espace des tats, - espace des activits.
SYSTEMES ELECTRONIQUES , DAUTOMATISATION

CFD Modle de contrle


S1 E1/A1 S4 E2/A2 S2 E3/A3 S3 E6/A6

SYSTEMES DINFORMATION
E4/A4

E5/A5

SYSTEMES INFORMATIQUES

Automate , Table de dcision


DSD Modle des donnes DFD Modle des activits

E1

P1

P5 P3

R E3

E2

Spcification dun systme


P2

P4

Diagramme Entits/Relations de CHEN

Diagramme flot de donnes

-Figure 8.3- Modlisation selon 3 vues complmentaires. La modlisation des donnes (diagramme de Jackson, diagramme entits/relations) est le point de vue principal pour les systmes d'information. La modlisation des tats (automate tats finis, table de dcision) est le point de vue pour les systmes de contrle tandis que la modlisation des activits (diagramme flots de donnes) est le point de vue pour les systmes de traitement ou de calcul. Les systmes devenant de plus en plus complexes et intgrant de multiples fonctions, les 3 vues sont devenues indispensables et complmentaires. En effet, pour les applications de l'Informatique Industrielle, la multiplicit des traitements conduit s'intresser l'approche flots de donnes. De mme, l'accroissement de la quantit des 146 M.C.S.E

Ch 8 - PANORAMA DES MODELES informations gres implique de devoir s'intresser l'organisation de toutes ces donnes. Ceci explique pourquoi la spcification propose par WARD et MELLOR dans RTSA comprend les 3 composantes: diagramme des activits, ajot d'une partie pour le contrle des activits, spcification des donnes entre activits. 8.2.2. Modlisation en conception La description interne d'un systme requiert d'exprimer 2 types de renseignements: - la structure, qu'il faut comprendre comme un ensemble de constituants plus lmentaires et de relations entre ces constituants, - le comportement pour expliciter une volution. La structure peut concerner des fonctions, des donnes, des ressources. Les ressources sont entendues ici comme les constituants plutt matriels ncessaires pour l'application. Pour l'approche Objet, fonctions et donnes forment un tout. L'expression d'un comportement peut concerner chaque constituant (fonction, donne, ressource) ou les interactions entre constituants. La description dun systme peut donc se faire selon deux vues: la vue fonctionnelle et la vue des ressources. Chaque vue ncessite dassocier une structure et le comportement des constituants. Ceci peut se reprsenter schmatiquement comme lindique la figure suivante.

interaction des fonctions

fonction i

Comportement fonctionnel

Comportement ressources

interaction des ressources

ressource i

comportement

structure

F1

F2

Solution dun systme

R1

Ri

F3

Fi

R2

Fonctions + donnes

Ressources

-Figure 8.4- Modlisation selon 2 types complmentaires. La vue des ressources est ici considre comme diffrente de la vue fonctionnelle, la premire servant comme support ncessaire pour la deuxime. Elle nest pas souvent voque car la plupart des mthodologies considrent le support excutif comme existant. M.C.S.E 147

Partie 2 - MODELES ET METHODOLOGIES 8.3. PANORAMA DES MODELES Lanalyse prcdente a montr que les modles utiles pour la spcification et la conception se classent en 2 catgories: les modles de structure, les modles de comportement. On passe ci-aprs en revue les principaux modles de structure dabord, puis de comportement qu'il est souhaitable de connatre en indiquant pour chacun son utilisation. 8.3.1. Modle pour les activits Le diagramme flots de donnes est un exemple de modle dcrivant les activits. C'est un modle structurel mais pour la spcification. Le comportement global n'est que partiellement exprim par ce modle. Le lecteur peut se reporter la mthode SA pour retrouver les rgles de reprsentation (voir 7.3). Dans plusieurs mthodologies il sert comme spcification de dpart pour la conception. Son intrt est de permettre de modliser globalement une application sans passer par la modlisation de chaque entit. 8.3.2. Modles pour les donnes 2 catgories de modles structurels sont utiliss selon que la donne considre forme un tout indivisible ou correspond une collection de donnes lies entre elles.
-A- DIAGRAMME DE JACKSON

Les donnes de taille importante ou contenant une varit de renseignements doivent tre dcrites par leur structure. Les langages de haut-niveau type PASCAL, ADA permettent ce type de description sous une forme textuelle. Le "typage" des donnes est considrer comme une description logique. A un niveau plus lev d'abstraction (niveau smantique), la structure dune donne peut se dcrire l'aide de 4 symboles. - l'lment Terminal (rectangle), qui est une donne indivisible et type, - l'oprateur de Composition, qui reprsente le produit cartsien des donnes contenues, - l'oprateur Ensemble, qui dsigne un regroupement d'lments identiques (taille dynamique, incluant le cas daucun lment), - l'oprateur Alternative, qui permet d'associer une donne particulire pour chaque valeur d'un attribut. Les liens orients entre symboles reprsentent les chemins d'accs. On donne sur la figure 8.5 un exemple titre d'illustration. La lisibilit de ces diagrammes est intressante. A partir de cette reprsentation, il est particulirement simple de dduire la structure logique en PASCAL par exemple.
-B- MODELE ENTITES-RELATIONS

Ce modle permet de reprsenter un "monde" en termes d'entits, leurs attributs et les relations entre ces entits [MARTIN-88]. Une entit est une "chose": objet, personne, information... Chacune entre dans une catgorie (type de l'entit). Les entits ne sont pas obligatoirement des objets physiques. Il peut ainsi s'agir d'abstractions telles quun vol d'avion. Chaque type d'entit possde ses propres attributs (ou proprits), qui permettent de diffrencier les entits 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

Slection
CERCLE RECTANGLE NOM

itration

-Figure 8.5- Diagramme de JACKSON pour les structures de donnes. Lorsque les entits sont en relation entre elles, les relations expriment des faits pour le "monde" considr. La smantique de chaque lment d'une phrase utilise pour exprimer des caractristiques pour les donnes ou informations considres induit assez naturellement sa catgorie: - les entits sont les sujets, objets, noms, - la relation est le verbe, - les attributs sont les modificateurs. La figure 8.6 donne un exemple de diagramme entits-association pour exprimer une modlisation. Les nombres sur les liens indiquent la cardinalit des entits pour chaque relation. Un seul nombre correspond la notation de CHEN. Pour 2 nombres il sagit de la notation franaise: 0 veut dire que toutes les entits ne sont pas obligatoirement lies par des relations, 1 veut dire que chaque entit nintervient quune fois dans la relation, n veut dire une intervention dans plusieurs relations. Par exemple, toutes les socits ne passent pas des commandes, mais une peut passer plusieurs commandes. Ce modle ne dcrit pas de caractristiques temporelles. Il s'agit d'un modle de description statique. Les bases de donnes, noyau des systmes d'information, sont bases sur ce type de modle dit relationnel. 8.3.3. Modles pour les fonctions Cette classe de modles permet de reprsenter par une structure un ensemble de fonctions interconnectes. Elles peuvent aussi bien tre du niveau fonctionnel que du niveau excutif 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

lment commande

0,n

PRODUIT

-Figure 8.6- Reprsentation d'une modlisation Entits-Associations.


-A- DIAGRAMME HIERARCHIQUE DE FONCTIONS

Ce type de diagramme exprime la dcomposition d'un systme complexe en une collection de sous-ensembles, ceux-ci lis par des relations entres vers sorties. Il permet le raffinement et l'abstraction. Il s'agit d'un modle 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 squencement ou les conditions sur les informations pour les entres: X2 et Z1, X2 ou Z1, X2 suivi de Z1, ni s'il s'agit d'un droulement parallle ou squentiel. L'expression de la hirarchie est donc un ingrdient essentiel de structuration, mais n'est pas suffisant lui seul.
-B- LE MODELE DE STRUCTURE FONCTIONNELLE

Le modle 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 modle est associe une interprtation exprimant le comportement des interactions entre les fonctions (voir partie 4). L'existence de cette interprtation rduit les degrs de libert pour le concepteur, mais lui apporte en contre-partie une efficacit, puisqu'il suffit alors de complter la description par le comportement interne de chaque fonction. Le modle pour la structure d'excution dans MCSE est similaire mais a pour objectif d'exprimer la structure d'un ensemble matriel. Le modle Process Structure Graph utilis dans DARTS et driv de MASCOT est relativement similaire, mais les types de relations pour exprimer le transfert de donnes 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 hirarchie de fonctions.


-C- MODELE DE STRUCTURE OBJET

Dans cette catgorie on trouve les diagrammes de BOOCH, de BUHR, de WASSERMAN, de BISHOP... Ce modle reprsente chaque objet par un diagramme possdant des points d'entre et de sortie. La forme de l'objet et les caractristiques des points d'entre dfinissent assez prcisment son type et donc son rle vis--vis de son environnement. Les connexions entre les objets sont du type demandeur ou transmetteur vers demand ou rcepteur. 8.3.4. Modles pour le comportement Cette catgorie est relativement riche en varits de modles. Le comportement est trs souvent exprim en temporel, mais pas exclusivement.
-A- MODELE MATHEMATIQUE

Il dcrit: - le domaine des variables d'entre et de sortie, - la transformation des entres vers les sorties. La transformation peut tre du type paramtrique: expression par un modle analytique (une relation mathmatique), ou par une relation non-paramtrique: expression des grandeurs de sortie pour des entres particulires. Le premier type de relation utilise habituellement un modle interne explicite, tandis que le deuxime est une vraie description externe. M.C.S.E 151

Partie 2 - MODELES ET METHODOLOGIES


-B- MODELES FORMELS

Un systme peut se spcifier par un ensemble d'noncs exprims dans un langage formel (rgle de grammaire, rgles algbriques...). Par exemple, la mthodologie VDM (Vienna Development Method, IBM Vienne) est base sur l'emploi d'un modle explicite pour exprimer des spcifications [COHEN-86]. Ces spcifications sont composes de 2 parties: - la dfinition abstraite des donnes et des variables pour reprsenter l'tat interne du systme, - la dfinition des oprations et des fonctions agissant sur les donnes et les variables. Ceci se fait en exprimant le nom de l'opration et les paramtres d'entre et de sortie, une pr-condition sur la valeur des paramtres d'entre et de l'tat initial qui dfinit l'excution, une post-condition qui prcise les valeurs prises par les variables et l'tat final l'issue de l'opration.
-C- PSEUDO-CODE

Une autre manire gnrale pour dcrire le comportement consiste utiliser une description textuelle structure. Le langage peut tre trs proche du langage naturel ou plus proche des langages informatiques: PASCAL, ADA par exemple.
-D- AUTOMATE A ETATS FINIS (FSM)

Ce modle permet une description comportementale simple, en exprimant les tats discrets d'une entit et les conditions de changement d'tat. C'est un modle essentiel en Informatique et en Informatique Industrielle. Un automate est caractris par des tats et des liens entre tats reprsentant les transitions possibles. Un des tats est l'tat initial. 2 types de modles sont bien connus, celui de MEALY pour lequel les actions sont associes aux transitions, celui de MOORE pour lequel les actions sont associes aux tats. Ce dernier est plus simple mais moins pratique pour les spcifications. Une combinaison des 2 modles est trs utile pour exprimer un comportement d'une manire concise. La barre sur le lien comme transition est utilise 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 simultanit d'volution ncessite la juxtaposition de plusieurs automates avec des couplages exprims par des conditions de transition qui dpendent des tats des autres automates ou des vnements produits par ceux-ci. Il est similaire au Grafcet quand ce dernier n'exploite pas le paralllisme. Il ne se prte pas la reprsentation de la complexit, car il s'agit d'un modle "plat" et donc limit pour le raffinement. Ce modle est parfois tendu par l'emploi de compteurs: Extended Finite State Machine. Le Grafcet est aussi une extension de ce modle en permettant la reprsentation d'un paralllisme.
-E- LE STATECHART

Dvelopp par HAREL [HAREL-87], le statechart remdie aux limitations essentielles de l'automate tats finis (voir 7.9.1). Nous conseillons aux lecteurs de regarder de prs ce modle, car il apparat extrmement sduisant pour exprimer des comportements squentiels avec simultanit pour des systmes de contrle.
-F- RESEAU DE PETRI

Le rseau de PETRI est un graphe bipartite compos de places et de transitions. La notion de marquage des places permet d'exprimer le squencement temporel et la concurrence [NUSSBAUMER-84]. Les rgles d'volution sont trs simples: une transition n'est franchissable que lorsque toutes les places en amont possdent au moins un jeton. Sur franchissement (rien ne dit quand) il y a retrait d'un jeton de toutes les places prcdentes et ajot d'un jeton dans toutes les places suivantes. Les structures de base sont reprsentes sur la figure 8.9. Lorsquune place est lie 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 dune seule transition.

Squencement

Slection

Synchronisation

Concurrence

-Figure 8.9- Les structures de base pour le rseau de Ptri. Diverses interprtations sont donnes aux places et aux transitions: - place = activit, - place = tat, transition = condition de fin, transition = condition d'volution et Action atomique associe,

- place = ressources, transition = activit. Pour ce 3me cas, chaque activit ne peut intervenir que lorsque les ressources d'entre sont disponibles (jetons dans les places prcdentes), produisant ainsi des ressources en sortie. Ainsi les rseaux de PETRI permettent par exemple de reprsenter des processus de production. La M.C.S.E 153

Partie 2 - MODELES ET METHODOLOGIES figure suivante reprsente le processus des visites dans un laboratoire d'analyse mdicale et le rseau de Ptri correspondant.
Patient Mdecin Secrtaire
Rception autorisation Employ

Autorisation
formulaire de demande danalyse

mdecin patient

Echantillons

Fichier
Echantillons

formulaire mis jour

Analyse

analyse

rsultats

Rsultats

Edition rapport

Edition du rapport

Rapport

Rapport

-Figure 8.10- Exemple de description par rseau de Ptri. Des proprits intressantes pour les systmes parallles peuvent tre vrifies en utilisant les rseaux de PETRI: rseau sauf, propre, vivant. Ce modle est intressant pour exprimer et valider la spcification du comportement d'un ensemble d'entits, puis pour valider une conception qui rsulte de cette spcification. Malgr ces avantages, les limitations essentielles sont similaires celles de l'automate tats finis. Il s'agit d'un modle "plat", le rseau de Petri devient rapidement complexe. Toutefois, si une transition ne possde qu'un point d'entre et un point de sortie, la technique de raffinement est exploitable. D'autre part, il limite la spcification une description de l'volution du contrle, rien concernant les donnes. Or souvent, le contrle dpend de l'tat des donnes.
-G- RESEAUX DE COMMUNICATION

Ce modle est driv du rseau 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 reprsente un tat d'attente. A chaque transition sont associes: - une condition de franchissement, gnralement rception d'un vnement ou dun message, - la gnration d'une action sur franchissement de la transition: exemple mission d'un message. Ce modle est particulirement intressant pour spcifier les protocoles de communication [ORR-88]. Il est du type stimuli/rponses. 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

ou
action A2

ou

ou

A2

A2

A2 SDL

ou

ou

Rception

ou

Emission

-Figure 8.11- Exemples de reprsentation d'un automate de communication. La validation de la spcification et l'valuation des proprits se font habituellement en considrant le rseau de PETRI quivalent. 8.4. CONCLUSION: LES MODELES DE MCSE Nous avions montr dans la partie 1 qu'une mthodologie repose sur un ou plusieurs modles. Ce chapitre a conduit la constatation que la modlisation d'un systme ncessite plusieurs vues et donc plusieurs types de modles. Il en dcoule qu'une mthodologie peut se dfinir par une trajectoire dans un espace de modlisation. Pour illustrer ce point de vue, la figure 8.12 explicite le cas de la mthodologie de NIELSEN et SHUMATE en sparant les 3 types de modlisation: spcification, description fonctionnelle, description excutive ou implantation. La spcification conduit laborer par approches successives des diagrammes flots de donnes. La conception dbute par une recherche des fonctions (process) directement partir des activits. Les donnes sont ensuite spcifies comme interfaces puis dcoule le comportement des fonctions. Le support matriel tant impos, l'implantation logicielle se dduit par transformation de la structure de process. Ensuite il en est de mme pour le comportement. Toutes les mthodologies dcrites dans le chapitre prcdent peuvent se reprsenter de la mme manire, sachant que selon les mthodes les modles utiliss diffrent. La comparaison n'est donc pas des plus immdiate. M.C.S.E 155

Partie 2 - MODELES ET METHODOLOGIES

SPECIFICATION

DESCRIPTION FONCTIONNELLE

IMPLANTATION

Comportement

Comportement

Comportement

activits DFD

structure PSC fonctionnelle

Structure matrielle

DSD donnes Raffinement Donnes

CPG et APG Matriel impos structure logicielle

-Figure 8.12- Trajectoire pour la Mthodologie de NIELSEN et SHUMATE. Nous disposons maintenant de tous les lments pour caractriser l'approche propose dans MCSE. La figure 8.13 reprsente la trajectoire de dveloppement pour les 3 niveaux de modlisation.
SPECIFICATION DESCRIPTION FONCTIONNELLE IMPLANTATION

Comportement

Comportement

Comportement

ou

Structure dactivits (DFD)

Structure fonctionnelle

Structure dxcution ( processeurs)

Structure de donnes

Raffinement DFD

Structure de donnes

Raffinement fonctionnel

Structure des tches logicielles ( implantation logicielle)

-Figure 8.13- MCSE explique par une trajectoire dans 3 espaces. Cette figure permet d'expliquer la mthode dcrite dans les parties qui suivent du prsent ouvrage: - la partie 3 montre que, selon la complexit, la spcification 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) ncessitant alors la caractrisation des activits de l'application. - dans la partie 4, la dmarche pour dduire une description fonctionnelle consiste dbuter par les donnes puis les fonctions, ce qui conduit alors une structure fonctionnelle. Une itration par raffinement est possible. La description est obtenue lorsque le comportement interne des fonctions de base est dfini. 156 M.C.S.E

Ch 8 - PANORAMA DES MODELES - la partie 5 prcise l'ordre de recherche des constituants: tout d'abord les processeurs, ensuite les tches logicielles sur les processeurs programmables, pour finir par le comportement impos chaque processeur par les tches. Concernant les spcifications, l'espace de modlisation en 3 dimensions est similaire la plupart des mthodologies. Adapt pour les systmes temps-rel, MCSE prconise d'exploiter de prfrence la dimension comportementale avant la dimension activits. Ceci se justifie car l'analyse du problme doit se faire partir des entits de l'environnement. Il est alors possible d'exprimer le comportement de ces entits sous l'influence du systme. Si cette approche ne s'avre pas simple (multitude d'entits et mal identifies), la dmarche par les activits est alors plus efficace. Concernant la conception, le modle fonctionnel est simple et indpendant de la technique pour l'implantation. La solution dcoule d'une recherche des donnes et donc des relations au pralable des fonctions. Ceci est un point de diffrence essentiel. Plusieurs mthodologies dduisent par transformation, les fonctions ou process partir des activits de la spcification. MCSE part du principe que la vue interne est trs diffrente de la vue externe. Ainsi, le concepteur doit faire un travail d'analyse et de synthse pour dvelopper une architecture fonctionnelle simple, approprie et efficace. Lorsque, par raffinement, une fonction est de nature squentielle, le comportement est exprim par une description en langage de hautniveau du type PASCAL par exemple. Pour limplantation, MCSE a la particularit de traiter simultanment les 2 aspects matriel et logiciel. La mthode de recherche de la solution pour la ralisation est complte car conduisant l'architecture matrielle et l'implantation logicielle. La dduction se fait par des transformations en utilisant les contraintes de temps comme critre de dcision. L'architecture matrielle est tout dabord dduite avec l'objectif de rduire son cot de reproduction. L'implantation logicielle est ensuite exprime pour tous les processeurs programmables. A nouveau par transformation, celle-ci est adaptable diverses techniques de ralisation: ralisation conventionnelle, utilisation du langage ADA, ralisation oriente 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 paratre 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 linformatique du temps rel 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 confrence 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, Fv.86, P.211-221 [BRACON-88] La spcification 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 Mthode de Conception Hirarchise oriente objets pour le dveloppement des gros logiciels techniques et temps-rel. M. HEITZ Bigre N57 dcembre 1987, Journes 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

SPECIFICATION DUN SYSTEME

La premire phase du travail de dveloppement concerne la dtermination des spcifications du systme souhait, pour ensuite le concevoir et le raliser. A partir du besoin exprim par un demandeur et des utilisateurs, une spcification traduit ce besoin en une description complte externe comprenant toutes les informations ncessaires pour son dveloppement. Il s'agit d'une tape dlicate mais essentielle puisque la premire, mais aussi parce qu'elle implique un dialogue important entre spcifieurs et demandeur. En effet, obtenir la description complte implique un transfert d'expertise et d'informations en provenance du demandeur. D'autre part une spcification doit tre adquate vis vis de la demande, ceci ncessite sa vrification qui ne peut se faire que par les demandeurs et utilisateurs. Cette partie dtaille le contenu du document de spcification et la dmarche suivre pour son laboration. La spcification est dfinie pour tre ensuite directement exploitable pour les tapes suivantes. Le Chapitre 9 prsente sous l'appellation du cahier des charges, la nature de la demande comme expression d'un besoin. Le Chapitre 10 dcrit les objectifs, nature et qualits d'une spcification. Le chapitre 11 prsente les bases de la modlisation et les outils disponibles qui serviront laborer la spcification. Le Chapitre 12 dtaille la structure et l'ensemble des constituants du document ainsi que la dmarche suivre pour construire la spcification. Cette dmarche est illustre sur des exemples pour lesquels les solutions seront dveloppes dans les parties 4 et 5.

M.C.S.E

165

Chapitre 9

LE CAHIER DES CHARGES

Une premire relation s'tablit entre demandeur et concepteurs lorsqu'apparait un besoin. Par demandeur, nous entendons une personne, une socit ou un organisme. Un besoin est la ncessit a priori d'un dispositif du type systme lectronique (pour se limiter au domaine considr dans ce document) conduisant amliorer -qualit, productivit, possibilits- une situation. Les concepteurs (dans le sens le plus gnral) sont les personnes capables d'analyser le besoin et d'y apporter une rponse. Pour les premires phases, le travail concerne des analystes et spcifieurs, et pour les phases suivantes, il concerne des concepteurs et ralisateurs. Les concepteurs peuvent faire partie du mme organisme que le demandeur: ils peuvent par exemple appartenir un autre service lorsque la structure possde la comptence en interne. Mais le plus souvent les concepteurs sont externes; l'tude du produit est dans ce cas soustraite l'extrieur. Ainsi les caractristiques gnrales d'une telle relation sont les suivantes: - le domaine concern par le besoin n'a rien ou peu de choses voir avec les systmes 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 DUN SYSTEME - les concepteurs, spcialistes des systmes lectroniques, n'ont pas a priori de comptences 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 rle de la premire phase de relation autour d'un besoin. A partir de la situation initiale voque ci-dessus, il s'agit plus prcisment d'analyser et de synthtiser les indications et le souhait du demandeur. 9.1. LE DEMANDEUR : SOURCE DU BESOIN Le contexte d'apparition d'un besoin est particulirement vari. En effet, les systmes lectroniques comme technologie de ralisation permettent d'apporter une rponse une immense varit de problmes. Il n'est donc pas surprenant de constater que le demandeur ne possde pas la comptence ncessaire pour dvelopper le systme appropri. De mme, il ne matrise pas le vocabulaire technique utile pour exprimer prcisment son besoin dans un vocable directement exploitable par des concepteurs lectroniciens. Ainsi, pour satisfaire le besoin, le problme rsoudre est soumis l'extrieur. Sa description est alors faite dans un langage propre au domaine d'application. Au pralable de toute sollicitation externe, il faut s'assurer en interne de l'opportunit du besoin. Le besoin estil une ncessit? C'est dj la premire question se poser. Cette tche est de la responsabilit du demandeur qui doit faire une analyse de la valeur. 9.2. LE CONCEPTEUR: EXPERT DU DOMAINE DE REALISATION Le problme est pos des concepteurs spcialistes des systmes lectroniques et de l'Informatique Industrielle. Exprime dans une terminologie propre au domaine du besoin, la dfinition du produit est fort probablement incomplte et pas directement comprhensible. Peut-tre aussi le problme ne ncessite-t-il pas obligatoirement la ralisation d'un systme du type lectronique. Il y a donc peu de chance pour les concepteurs de tomber d'emble sur un problme trs bien cern sur lequel ils peuvent travailler avec efficacit pour dfinir la ralisation. Obligatoirement, un travail important de comprhension du problme et d'analyse du besoin est ncessaire. Ce travail est d'autant plus difficile que la diffrence 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 rdig par le demandeur, dcrit l'environnement dans lequel doit se trouver le systme, les objectifs que celui-ci doit satisfaire, ainsi que ses proprits et contraintes. Il a pour objectif de rpondre la premire question essentielle qui est le pourquoi du systme (WHY). Il sert ainsi comme premier intermdiaire entre des utilisateurs qui expriment leurs besoins et des concepteurs qui y trouvent une description de ce besoin [AMGHAR-89]. La description du besoin rsulte d'une rflexion du demandeur avec ses collaborateurs qui, souhaitant le systme, s'imaginent la place de celui-ci pour dcrire son rle pour l'environnement. La description prsente donc: - une vue de l'environnement du systme dcrit dans la terminologie du demandeur, 168 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES - le problme rsoudre et toutes les informations ncessaires pour lutilisation du systme. - les caractristiques et toutes les contraintes auxquelles doit satisfaire le systme. En gnral, le contenu du cahier des charges est trs variable d'un demandeur un autre et selon le problme concern: trs bref ou particulirement volumineux, trs vague ou trs spcifique. 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 problme, le demandeur attend une rponse rapide sur plusieurs points: - tout d'abord, la faisabilit du problme, - dans le cas positif: dlai pour la ralisation, cot du dveloppement, si ncessaire: le cot de reproduction, description de la fourniture.

A partir de cette rponse, le demandeur peut dcider du dveloppement ou non du systme. Les concepteurs deviennent alors les prestataires, et le demandeur est le client. Le demandeur peut aussi souhaiter procder sur la base d'un cot objectif plafond prdtermin. La dtermination du prix repose principalement sur des donnes extrieures au produit (budget, march). Dans ce cas, le cahier des charges est ouvert et ngociable. La motivation des concepteurs peut tre soutenue par un principe d'intressement aux rsultats. 9.5. BUT ET IMPLICATION DU CAHIER DES CHARGES Tout concepteur souhaite disposer d'un cahier des charges dfinissant correctement l'environnement et les fonctions du systme. Tributaire du bon vouloir du demandeur et de sa comptence rdiger ce type de document, il est plus raliste de se placer dans l'hypothse d'une faiblesse gnrale du cahier des charges. Trs probablement, les concepteurs doivent commencer par laborer un tel document. Apparat donc une question essentielle: quelles informations faut-il inclure dans le cahier des charges?. Pour y rpondre, revenons sur les objectifs. Le cahier des charges contribue clarifier et formaliser les responsabilits relatives du demandeur et des concepteurs. De cette manire, son objectif est de servir comme document contractuel entre le demandeur en tant que personne ou en tant qu'organisation et les dveloppeurs. Les concepteurs se trouvent contraints par le contenu du document car celui-ci dtermine la fourniture. La certification du systme utilisera en final ce document comme rfrence. C'est tout particulirement 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 pralable de la rdaction 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 DUN SYSTEME - d'effectuer une analyse systmatique et exhaustive du besoin, - de dfinir les critres d'apprciation du rsultat. Toutefois, la responsabilit et par consquent la libert du choix des solutions doivent tre rserves aux concepteurs. Le champ de recherche reste alors ouvert au maximum. Pour atteindre un tel objectif, le dialogue entre tous les partenaires est une ncessit. Comme guide, les questions suivantes fixent un premier cadre de dialogue avec le demandeur. - Quelles raisons motivent le dveloppement du systme? 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 caractristiques de l'environnement le systme doit-il tre conforme: interfaces existants ou prvus...? - Quelles fonctions exprimes dans le langage du demandeur devra assurer le systme, quelles informations devra-t-il grer? - Quelles sont toutes les contraintes: matrielles, temporelles, conomiques, auxquelles doit se conformer le systme? - Quelle doit tre la forme finale du produit: maquette, prototype industrialisable, production en srie, esthtique 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 plutt exhaustif, il faut avoir l'esprit qu'une description trop vague conduit une difficult d'estimation de la faisabilit et du cot du dveloppement, et donc peut entrainer un risque important pour le prestataire qui accepterait la ralisation. De mme un document trop prcis contenant en particulier des esquisses de solutions impose des contraintes sur la ralisation. 2 raisons peuvent expliquer un excs de renseignements. - Il apparait plus facile de dcrire un systme qui rsoud un problme que le problme lui-mme. - Le demandeur est tent de croire qu'un document dcrivant uniquement les caractristiques satisfaire, peut rendre plus complexe le travail des concepteurs. Quelles informations faut-il inclure dans le cahier des charges? Les paragraphes suivant prsentent la structure du contenu. 9.6. CONTENU ET GUIDE POUR LE CAHIER DES CHARGES La dmarche 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 compltant par un plan de dveloppement et une valuation du cot, il est utilisable comme rponse la demande de prestation. La procdure 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 premire version du cahier des charges, - tude de faisabilit et affinement du besoin (demandeur-concepteurs), - dcision de dveloppement et rdaction du document dfinitif. 170 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES Comme guide pour la structuration du cahier des charges, on donne ci-aprs une esquisse du plan suivre: 1- Prsentation du document - demandeur, - organisation du document, - conventions, terminologie. 2- Prsentation du produit - prsentation gnrale du problme, - domaine, - march, - objectif, - utilisateurs, organisation, - nonc du besoin, - mise en fonctionnement, - maintenance. 3- Description de lenvironnement - entits: caractristiques, - informations: attributs, relations, - contraintes. 4- Description des fonctions satisfaire - fonctions principales, - fonctions complmentaires, - configurations, options, variantes, - caractristiques et performances. 5- Contraintes - contraintes d'interfaces, - contraintes de temps, - contraintes d'utilisation, - contraintes de ralisation, - maintenance et volutivit, - fiabilit et sret de fonctionnement 6- Documentation - documents de spcification, de conception, de ralisation - manuels utilisateurs, procdures d'installation, maintenance et gestion du systme. 7- Plan de certification - critres d'apprciation du rsultat, - situations de test et scnarios, - limites d'acceptation, flexibilit. 8- Plan de dveloppement - planning du dveloppement, - support pour le dveloppement. M.C.S.E 171

Partie 3 - SPECIFICATION DUN SYSTEME Il est utile de se poser la question de la comptence ncessaire pour rdiger 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 cots, 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 rpondant au besoin. De manire faciliter l'valuation des propositions et si ncessaire d'effectuer une comparaison dans le cas d'une consultation ouverte, on donne ci-aprs un exemple de plan de rponse. 1- Prsentation du prestataire - organisme, - comptences dans le domaine. 2- Descriptif de la proposition - fonction assure, - solution propose (esquisse, avant-projet), - version de base, variantes... - qualit, fiabilit, volutivit... 3- Plan de dveloppement - planning, - support pour le dveloppement. 4- Cot de la prestation - cot du dveloppement (base, variantes), - cot de reproduction, - cot d'installation, de maintenance... Sur la base de telles rponses, le demandeur dispose des lments objectifs lui permettant de dcider de la suite donner pour le produit. Il peut conclure d'arrter ce projet pour diverses raisons: techniques, conomiques, stratgiques... Sinon, faisant connatre sa dcision de travailler avec un prestataire, il entreprend alors la phase finale de ngociation et de signature dun contrat. Le cahier des charges dfinitif joue dans ce cas le rle de document contractuel. 9.8. EXEMPLES DE PROBLEMES Les 2 problmes dcrits 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 dillustrer toutes les tapes de la mthodologie. Il ne s'agit bien-entendu pas de cahiers des charges complets tels que dcrits dans les paragraphes prcdents. Les exemples sont des cas simples par rapport la complexit des problmes soulevs par les industriels, mais suffisants comme support pour favoriser la comprhension de 172 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES la dmarche prconise. Tout concepteur peut aussi rflchir sur diffrents points: que suggrent ces problmes: Ai-je la comptence pour rsoudre ces exemples? Dispose-t-on de toutes les informations? Suis-je capable d'valuer le cot et temps de dveloppement? Quelle solution adopter? dmarche... 9.8.1. Systme de contrle en vitesse d'un centrifugeur L'objectif est de disposer d'un systme assurant la rotation d'un moteur selon un gabarit en vitesse donn. Un centrifugeur est un exemple d'application. Mais ce type de problme se retrouve dans une grande varit d'applications: dplacement en vitesse d'un chariot (ascenseur par exemple), pilotage d'un four selon un gabarit en temprature... Plus prcisment, il s'agit de faire tourner un moteur une vitesse constante fixe par l'utilisateur avant le lancement de l'opration. La rotation a lieu pendant une dure donne, fixe ici, sachant que la monte en vitesse se fait acclration constante, et de mme pour la dclration. Le gabarit d'volution de la vitesse est donn ci-aprs:
V

arrt forc Consigne vitesse

arrt normal

arrt 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 systme. Pour le contrle du systme, l'utilisateur dispose de 4 boutons-poussoirs: - MARCHE et ARRET pour dbuter le cycle et l'interrompre avant la fin s'il le dsire. - PLUS et MOINS, pour effectuer le rglage de la consigne de vitesse. Ce rglage est incrmental chaque appui, mais pour un appui long, la progression devient gomtrique: consigne modifie de 1 en 1, puis de 10 en 10, puis de 100 en 100. Pour le rglage de la vitesse, l'utilisateur dispose d'un affichage en 4 digits de la consigne courante. La consigne est rgler avant un dpart de cycle, et celle-ci n'est pas modifiable durant la rotation. L'afficheur prsente 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 DUN SYSTEME 9.8.2. Automatisation par chariot filoguid Un vhicule filoguid permet d'effectuer, sans intervention humaine, des travaux de manutention dans un atelier. Pour ce problme, il s'agit de faire passer des paquets d'un quai un autre quai. Le vhicule suit une trajectoire ferme dfinie par un fil implant dans le sol. Ce fil est metteur d'une onde haute-frquence. 2 quais sont disposs sur la trajectoire. Un couplage existe entre les quais en tant que donneurs d'ordres et le vhicule comme excutant. La transmission se fait par une technique infra-rouge qui se comporte comme une liaison RS232. La description de l'atelier est reprsente sur la figure suivante.
communication infra-rouge
Quai 1

paquet chariot
Quai 2

paquet fil de guidage

paquet bute pour arrt du paquet tapis tapis chariot Quai roues capteur prsence quai

-Figure 9.2- Description de latelier.


-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, dchargement du paquet, retour au quai 1, attente de l'ordre suivant. Pour un cycle, on impose la squence ci-aprs: - Le quai 1 vrifie tout d'abord la prsence du chariot. Pour cela, il envoie un ordre d'interrogation de prsence. Le chariot lui rpond immdiatement s'il est prsent. Si le quai 1 n'a pas de rponse au bout de TI, une sirne est active 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 arrte la rotation de son tapis et donne l'ordre au chariot de se dplacer vers le quai 2. 174 M.C.S.E

Ch 9 - LE CAHIER DES CHARGES - Arriv au quai 2, la prsence du chariot est dtecte par le quai. Si le quai 2 ne dtecte pas rapidement l'arrive, le chariot active sa sirne. - Le quai 2 lui commande la dcharge: rotation des 2 tapis chariot et quai durant TC. - Aprs TC et sur ordre du quai, le chariot repart vers le quai 1. - Son arrive est dtecte et le cycle peut reprendre. Tous les dialogues quai --> chariot se font par la liaison infra-rouge. La dtection de prsence un quai (et donc d'arrive) se fait par dtection de prsence d'un marque rflchissante. On ne se proccupera pas de ce qui advient lorsqu'une sirne est active. L'exploitant se charge alors en manuel d'une mise en tat de l'installation.
-B- DESCRIPTION DU CHARIOT

Le vhicule possde 3 roues. La roue avant est folle. Chacune des roues arrires est commande directement par un moteur (M1, M2). Une diffrence de vitesse entre les 2 roues engendre une rotation du vhicule. Les quelques renseignements suivants permettent de mieux comprendre le fonctionnement impos: - pour chaque dplacement, la vitesse nominale du vhicule est fixe VC, - la mesure de vitesse pour chaque roue doit se dduire d'un codeur incrmental directement coupl chaque moteur, - pour suivre le fil, 2 capteurs analogiques C1 et C2 sont utiliss. Chaque capteur traduit en amplitude (AC1 et AC2) l'onde Haute-Frquence reue dont l'amplitude est inversement proportionnelle la distance. Si l'onde reue est trop faible, le capteur fournit une amplitude nulle. La position du chariot par rapport au fil sera proportionnelle (AC1-AC2). Ainsi, la vitesse diffrentielle entre les 2 roues devra tre proportionnelle (AC1- AC2). - Le vhicule doit s'arrter et activer sa sirne lorsque l'un des 2 capteurs ne dtecte plus de signal (chariot trop loign), ou lorsque le radar plac l'avant dtecte un obstacle. - le dmarrage et l'arrt doivent se faire en 1s par variation linaire de la vitesse.
-C- CARACTERISTIQUES OPERATOIRES ET TECHNOLOGIQUES

- La vitesse maximale VC est de 5 km/heure, les roues ont un diamtre de 30 cm. - Les codeurs fournissent 128 impulsions/tr. - Pour la qualit du suivi de la trajectoire, il faut commander chaque moteur selon une priode telle que le dplacement n'excde pas 2 cm. - La prcision sur la vitesse doit tre de 5%, les capteurs C1 et C2 ont une prcision de 1%. Le dtecteur 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 DUN SYSTEME

systme 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 vhicule filoguid. 9.9. RESUME Ce premier chapitre a permis de prendre connaissance du contexte et de la procdure 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 dfini. Un travail important de collaboration entre divers partenaires est ncessaire 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 dveloppement permettent de dcider de l'avenir du produit. Si une ralisation est souhaite, un accord de collaboration se traduit par un contrat de dveloppement. - savoir rdiger correctement un cahier des charges rsulte d'une exprience qui ne s'acquiert que progressivement aprs avoir ralis des projets, puis en avoir assum la responsabilit.

176

M.C.S.E

Chapitre 10

OBJECTIF DUNE SPECIFICATION

Le cahier des charges est exprim et rdig par le demandeur. Il sert de base pour les premires discussions avec des concepteurs. Il est donc l'vocation du problme rsoudre. De toute vidence, ce type de document dcrivant plutt le Pourquoi est trs incomplet et ne permet pas d'avoir une base suffisante pour dcider de la ralisation. Pourtant, avant que ne s'engage toute collaboration, il a t ncessaire de faire une valuation financire a priori, qui conduit la signature d'une convention ou d'un contrat de dveloppement. A ce stade, l'erreur d'valuation peut s'avrer importante. A partir du cahier des charges, clients et concepteurs ont effectuer ensemble un premier travail de rflexion pour exprimer clairement l'objectif atteindre. Intermdiaire entre la demande et la conception, une SPECIFICATION ainsi labore sert les 2 partenaires: - Tout d'abord le client, car il s'assure ainsi que son problme a t correctement interprt par les concepteurs, et qu'ainsi la ralisation qui rsultera du dveloppement sera conforme son vouloir. Le travail de spcification peut aussi conduire dceler des besoins non exprims, ce qui induit une qualit meilleure pour le demandeur. - Les concepteurs ensuite, car se faisant de cette manire une ide prcise du problme pos, ils peuvent entreprendre avec efficacit le travail de conception puis de ralisation. Une valuation plus correcte du cot d'tude est aussi possible, ce qui peut conduire une amlioration du contrat de prestation.

M.C.S.E

177

Partie 3 - SPECIFICATION DUN SYSTEME Ce chapitre justifie le rle essentiel jou par une spcification et prcise sa nature par rapport au cahier des charges. Ensuite, sont nonces les qualits d'une spcification et les grandes lignes du contenu du document, ainsi que les bases de son laboration. 10.1. ROLE DUNE SPECIFICATION Analysons tout d'abord la situation des diffrents partenaires dans le cadre d'un dveloppement, pour dduire prcisment le rle d'une spcification. 10.1.1. Distance entre client et concepteur Le client pris dans son sens gnral en tant que demandeur d'un dveloppement, possde l'expertise du domaine d'activit dans lequel va intervenir le systme. Ce domaine peut n'avoir aucun point commun avec le domaine d'expertise des concepteurs qui est celui des systmes lectroniques dans le cas qui nous intresse. Ainsi, le souhait exprim par le client, transform en obligation sous la forme d'un cahier des charges, ne reprsente en gnral que peu d'informations directement comprhensibles et exploitables par les concepteurs. De son ct, le concepteur peut penser avoir compris la demande, en s'tant imagin sur la base de sa comptence, 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 succs sont trs rduites. Le produit dvelopp peut s'avrer correct pour les concepteurs, mais inappropri et inexploitable pour les utilisateurs. 10.1.2. Diversit des partenaires ct client Pour mieux saisir la difficult de comprhension du problme, il est utile de connatre, ct demandeur, les diffrents intervenants concerns par le produit. Ainsi le terme client recouvre les catgories suivantes: - l'acqureur du systme: souvent ngociateur et ordonnateur de la prestation. Il s'agit du responsable technique et/ou financier de l'opration. Son objectif est de satisfaire le problme au moindre cot et dans les dlais impartis, et d'intgrer ce produit dans une perspective de dveloppement de son organisation. - les utilisateurs, trs souvent diffrents du responsable du dveloppement ct client, auront exploiter le systme demand. Ils sont concerns par les fonctionnalits, les performances, les procdures d'exploitation. Suivant la complexit du systme, les utilisateurs peuvent eux-mmes se subdiviser en catgories. La mthode de travail et la comptence de cette catgorie de personnel sont des lments indispensables considrer pour le succs du produit. - les installateurs, qui eux sont proccups par la procdure d'installation du systme sur site. Simplicit et cot rduit font partie des objectifs satisfaire. - l'quipe de maintenance, qui doit se proccuper des qualits de maintenabilit du produit, documentation, comprhensibilit de la solution, moyens pour assurer la maintenance... 178 M.C.S.E

Ch 10 - OBJECTIF DUNE SPECIFICATION - les fabricants, lorsque le systme devra tre reproduit dans l'organisation ou par soustraitance, pour une diffusion en plusieurs exemplaires. Les responsables des mthodes s'intressent aux qualits de reproductibilit industrielle du prototype. Ainsi, vu la diversit des personnes concernes par le produit, chacun ayant des objectifs et contraintes pas obligatoirement compatibles, la conception d'un systme jug satisfaisant pour tous se rvle une tche difficile sans compromis. 10.1.3. Importance d'une vrification Compte-tenu de la situation de chaque partenaire concern par le rsultat, il est vident que la premire tche essentielle pour les concepteurs consiste aboutir une bonne comprhension du problme pos. La dmarche de travail, le dialogue, la rigueur et l'objectivit dans l'analyse sont des points essentiels qui favorisent la russite. Mais, les concepteurs sont-ils garantis d'avoir saisi correctement le problme? Sans vrification intermdiaire, ils procdent au dveloppement puis une ralisation. Le produit rsultant n'est observable qu'en final et bien entendu il est alors vrifi par le client. Fort probablement certains aspects ne seront pas jugs satisfaisants pour diffrentes raisons: - L'expression du besoin au travers du cahier des charges n'est pas exhaustif, ce qui peut conduire des interprtations diffrentes. - Durant la priode de dveloppement, les souhaits du client peuvent voluer. Ce point est essentiel considrer car il s'agit d'une situation invitable. - L'ide que se font les concepteurs du produit peut aussi voluer, mais dans une direction diffrente de celle du client par suite de la diffrence de comptence et de domaine d'activit. - Sans information comprhensible de la part des concepteurs sur ce que sera le systme, durant l'attente du produit le client a tendance progressivement douter du rsultat escompt. De tels risques sont viter. Pour cela, il est indispensable d'assurer une vrification de la bonne comprhension du problme par les concepteurs. Vrification videmment faite par le client, elle conduit: - amliorer la dfinition du systme qui en rsultera, - instaurer un climat de confiance entre le client et les concepteurs, car le demandeur, travers l'analyse de la comprhension, a une vision prcise du produit final, rduisant ainsi le doute. - affiner la dfinition 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 vrification, mme malgr la diffrence de "domaines d'expertise" entre les 2 parties. M.C.S.E 179

Partie 3 - SPECIFICATION DUN SYSTEME 10.1.4. Une spcification comme document formel vrifiable Pour formaliser la comprhension du problme et l'objectif atteindre, il faut disposer d'une description intermdiaire entre le cahier des charges qui exprime plutt le Pourquoi, et la solution dveloppe par les concepteurs: le Comment. Cette description intermdiaire (le Quoi) doit tre vrifiable par le client pour validation, et tre aussi directement exploitable par les concepteurs pour rechercher la solution puis la valider. Cet intermdiaire est appel la SPECIFICATION du problme.
SANS SPECIFICATION

Expression du besoin

Problme

C D C

Developper

Produit

Satisfaction des besoins ?

Verification

AVEC SPECIFICATION

Expression du besoin

Problme

C D C

Spcifier

Satisfaction totale des besoins Vrification

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

Concevoir, raliser

Produit

Vrification

-Figure 10.1- Intrt d'une spcification comme intermdiaire. Dduit du cahier des charges par discussion avec le client et exploitable par les concepteurs pour exprimer une solution, le document de spcification est une interface essentielle entre le client et les concepteurs. Il permet de corriger le fait que ce qui n'est pas spcifi ne peut pas tre vrifi et que ce qui n'est pas vrifi peut tre erron. Pour bien comprendre la signification du terme SPECIFICATION, considrons un produit existant tel qu'un composant intgr VLSI. Pour son utilisation, le fabricant labore un document d'utilisation qui est en fait une spcification du composant. La description disponible est une vue externe du composant, qui dtaille ses proprits. Ici, une spcification est de mme nature, mais laborer au pralable de la conception. Comme dfinition, une SPECIFICATION dcrit les caractristiques externes compltes du systme concevoir qui opre dans l'environnement prcis dans le cahier des charges. Il s'agit donc d'une description du systme vu de l'extrieur, et qui possde les proprits et qualits exprimes par le demandeur (WHAT), tandis que le cahier des charges dcrit les proprits et contraintes satisfaire (WHY). 180 M.C.S.E

Ch 10 - OBJECTIF DUNE SPECIFICATION Ainsi, dans MCSE, une diffrence essentielle est faite entre cahier des charges et spcifications, ce qui est confirm par de nombreux auteurs [ABBOTT-86, LUDEWIG-87, WARD-85, HATLEY-87]. Bien entendu, cet intermdiaire augmente en apparence la quantit de travail ds le dbut du projet. Cit par LUDEWIG et MATHEIS pour le domaine du logiciel, ce qui est extrapolable sans grande erreur aux systmes lectroniques, prs des 2/3 du cot total d'un produit est li des activits qui ont lieu partir de sa mise au point. Ceci se traduit par un cot considrable de maintenance qui peut tre la fois du type correctif et volutif. Ce cot diminue par rduction des corrections et modifications, et par rduction de la complexit du dveloppement: complexit des circuits et cartes pour le matriel, nombre de lignes de programmes pour le logiciel. De mme dans [RAMAMOORTH-87], il est indiqu que 30% des erreurs trouves durant le test et la mise en fonctionnement, sont dues une mauvaise comprhension du problme, et trs souvent la non-compltude d'expression des besoins dans le cahier des charges. Une bonne spcification contribue rduire ces diffrents points. Ainsi, pour rduire le cot global d'un dveloppement, il est souhaitable d'investir du temps par un effort accru en spcification. La figure suivante [LUDEWIG-87] prsente l'intrt d'un tel investissement pour un projet logiciel.
Cot ou ressources / unit de temps

100 %

*
Sans spcification

Avec spcification

besoin

spcification

conception

codage

installation maintenance

-Figure 10.2- Effort par phase avec ou sans spcification. Le point * est critique pour la conduite du projet. Il correspond au stade o la spcification n'est pas encore compltement cohrente, et o la conception est entame sur la base des spcifications incompltes. C'est donc l'instant o l'quipe peut douter de l'intrt d'une bonne spcification. PARNAS cite des raisons supplmentaires en faveur dune spcification complte [PARNAS-86]: - Les duplications et inconsistances sont viter. Sans document, les mmes questions reviennent des stades diffrents et peuvent conduire des rponses non-homognes. M.C.S.E 181

Partie 3 - SPECIFICATION DUN SYSTEME - Un document complet est aussi ncessaire pour faire une bonne estimation du travail et des ressources ncessaires. - C'est aussi une garantie en cas de mobilit du personnel. - Il permet de prparer un plan de test. - Il est utilisable longtemps aprs que le systme soit mis en fonctionnement. - Comme interface entre demandeur et concepteur, les changes sont ainsi rduites. - Il peut servir de document de ngociation et de rfrence pour d'autres affaires similaires (rutilisation). Idalement ce document devrait tre crit par les utilisateurs ou leurs reprsentants. En fait, les utilisateurs n'ont pas souvent la comptence pour effectuer cette tche. Aussi, c'est aux concepteurs d'assurer ce travail, puis de faire analyser le rsultat par le client. 10.2. NATURE DUNE SPECIFICATION Compte-tenu du rle primordial jou par une spcification, la premire tape de comprhension et de formalisation du problme s'avre particulirement dlicate. La comptence du spcifieur est un facteur essentiel pour la russite du projet. Avant de s'intresser la dmarche suivre, il faut tout d'abord s'interroger sur la nature d'une spcification. Le point de dpart de la rflexion consiste considrer qu'il s'agit d'un intermdiaire vrifiable 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 spcification par prototypage. Ensuite et idalement le document de spcification [LUDEWIG-87, ABBOTT-86] doit tre: - correct: il doit reflter les besoins, - complet: toutes les caractristiques et contraintes doivent y figurer, - cohrent: absence d'ambiguit et de contradiction, - comprhensible: structur pour faciliter la lecture, et interprtable la fois par le client et les concepteurs, - vrifiable: la description doit permettre d'affirmer la validit de la spcification, - exploitable par les concepteurs pour dduire efficacement une solution, - rdigeable et modifiable: la spcification doit pouvoir se transcrire sur papier. De plus, compte-tenu des manques ou volutions souhaites, elle doit tre modifiable facilement. Pour satisfaire ces objectifs, une spcification doit respecter des qualits dcrites dans le paragraphe suivant. 10.3. CARACTERISTIQUES DUNE SPECIFICATION La qualit d'un document de spcification peut se juger en s'interrogeant sur les 3 points suivants: 182 M.C.S.E

Ch 10 - OBJECTIF DUNE SPECIFICATION 1- LISIBILITE: une spcification doit tre claire, sans ambituit de comprhension, et crite dans un langage accessible aux 2 groupes de lecteurs. 2- TESTABILITE: Les concepteurs et le client doivent pouvoir vrifier la conformit de la ralisation aux spcifications. 3- MAINTENABILITE: comme gnralement les besoins ont tendance voluer durant la phase de conception et de ralisation, les spcifications doivent pouvoir tre aisment modifies. Si le document ne suit pas toutes les volutions acceptes qui apparaissent durant la conception puis la ralisation, le contrle du rsultat risque d'tre trs difficile. Pour rpondre aux objectifs cits dans le paragraphe prcdent, le document de spcification doit au moins satisfaire aux diffrentes caractristiques suivantes:
-A- SUPPORT DE COMMUNICATION

Une spcification a t justifie comme interface entre client et concepteurs pour rduire la distance et pour tablir une base de vrification. Les problmes de communication ne sont pas vidents rgler en l'absence d'un langage commun. Comme intermdiaire, le document de synthse permet de formaliser la procdure de communication. Ct client, les personnes concernes rpondent tout d'abord aux questions poses par le spcifieur qui extrait ainsi par dialogue les lments essentiels pour les formaliser dans la spcification. Ensuite comme lecteur, le client approuve ou fait corriger les erreurs et manques. Ct concepteurs, le document permet une transmission globale de l'information, vitant ainsi les redites des stades diffrents et l'apparition de rponses non homognes.
-B- STRUCTURATION

Une spcification est une rfrence: il est donc ncessaire, comme pour tout document de ce type, qu'elle obisse un plan logique qui facilite sa lecture, sa consultation ponctuelle, sa modification. Une bonne structuration du document favorise la comprhension, la vrification, l'exploitation par les concepteurs. Pour le client et donc les utilisateurs, la structure d'une spcification doit conduire le lecteur retrouver d'abord l'environnement du systme qu'il matrise bien, puis la description des fonctions du systme agissant sur cet environnement. Pour les concepteurs, la structure du document doit favoriser la recherche progressive de la solution, en s'intressant d'abord au sujet par une approche fonctionnelle, puis au support de ralisation.
-C- SIMPLICITE ET ADEQUATION

La comprhension est lie la simplicit de description des lments contenus dans la spcification. Il est reconnu que tous les outils de description graphique simplifient la comprhension. Toutefois, les symboles doivent tre suffisamment riches pour exprimer compltement et sans ambiguit une signification. Ainsi, le choix des outils de spcification appels dans la suite modles de spcification a une grande importance pour avoir le meilleur compromis entre la simplicit, l'adquation, la lisibilit. M.C.S.E 183

Partie 3 - SPECIFICATION DUN SYSTEME


-D- RIGUEUR DE DESCRIPTION

L'objectif pour un dveloppement est de rduire son cot. Pour cela, il faut tendre vers une automatisation maximale de la production de la solution et de la ralisation correspondante. La production automatique ncessite, comme intermdiaire entre le besoin et le produit, de dcrire la spcification de l'objet d'une manire formelle. Bien sr, en plus, il faut pouvoir formaliser la procdure de production d'une solution. Pour progresser dans ce sens, il faut voluer vers l'utilisation de spcifications formelles, tout en les conservant lisibles par le client pour la vrification.
-E- GESTION DE LA COMPLEXITE

Les modles ou outils de spcification doivent permettre de dcrire tout niveau de complexit des systmes. Du fait des limitations de l'esprit humain grer tous les dtails d'un systme complexe, les outils de spcification doivent favoriser le partitionnement d'un systme en sous-ensembles. Pour cela, la spcification doit reposer sur des modles: hirarchiques pour la description en niveaux, conceptuels ou abstraits plutt que physiques de manire liminer les dtails. Ainsi, une spcification permet de dcrire le systme diffrents niveaux de dtails et par parties. 10.4. GRANDES LIGNES DU CONTENU DUNE SPECIFICATION Tout d'abord, notons 2 points tout fait diffrents: - le document de spcification en tant que rsultat final. - la mthode qui conduit obtenir un tel document. L'essentiel pour le client et les concepteurs est le document final. Toutefois, le cot d'obtention d'un tel document peut se rduire en utilisant une mthode approprie et en possdant des comptences spcifiques d'analyste. Le document de spcification, comme tout document, se doit d'tre structur. Le plan et le contenu doivent rpondre le plus clairement possible au moins aux questions que se posent les lecteurs. Avant toute rdaction, chaque auteur de spcification doit au pralable se poser les quelques questions de bon sens suivantes: - A quelles questions doit rpondre le document? - Quels sont les lecteurs? - Comment vont-ils utiliser le document? - Quelles sont les connaissances ncessaires pour sa lecture? La structure du document dcoule d'une rflexion sur les points prcdents. Le plan suivant est donn comme esquisse pour la rdaction des spcifications. Le lecteur trouvera dans le chapitre 12 le dtail du contenu de chaque partie. 1- Prsentation du problme: cahier des charges, analyse succincte, terminologie. 2- Caractristiques et modlisation de l'environnement du produit raliser. 3- Spcification des entres et sorties du systme. 4- Spcifications fonctionnelles: description des fonctions du systme. 5- Spcifications opratoires: droulement des oprations. 6- Spcifications technologiques: contraintes de ralisation. 7- Informations complmentaires (explications techniques, sources de documentation...). 184 M.C.S.E

Ch 10 - OBJECTIF DUNE SPECIFICATION Ce plan montre que le spcifieur construit progressivement le document partir des rencontres avec tous les acteurs ct client. Il commence tout d'abord par l'acquisition d'expertise ceci par analyse de l'environnement, puis il caractrise le systme progressivement par affinements successifs. Au fur et mesure de sa rdaction, le document est vrifiable par le client. 10.5. DIFFICULTES DU TRAVAIL DE SPECIFICATION En fait, le spcifieur se trouve dans une position intermdiaire dlicate entre le client et les concepteurs. Le client en tant que donneur d'ordre est observateur et juge des rsultats. Les concepteurs et ralisateurs assurent un travail technique bien dfini et intressant, et les relations entre eux sont assez simples puisque matrisant le mme domaine de comptence. Pour le spcifieur, la situation n'est pas du tout la mme. Les relations avec le client (et donc tous les intervenants) ainsi qu'avec les concepteurs ncessitent un travail permanent de ngociation. Il est mme possible de tomber sur des cas de participants hostiles tout dialogue. Une spcification n'est jamais dfinitive ni pleinement satisfaisante. Rsultat fait de compromis, un spcifieur, contraint par le temps, peut prouver des sentiments de frustration. De plus, l'absence de mthodes et d'outils rend la tche particulirement difficile. Pour spcifier correctement, il faut tre mme d'valuer la faisabilit du produit et d'estimer le cot. Pour la faisabilit, le spcifieur doit tre en mesure de dterminer les solutions envisageables, ce qui justifie de sa part une comptence en conception et ralisation. L'estimation du cot est une autre difficult car ce type d'expertise ne peut s'acqurir que sur la base d'expriences. Or, les situations ne sont jamais identiques. Une spcification joue un rle de nature dfensive. Il s'agit beaucoup plus d'viter les erreurs que de garantir le succs. Comme intermdiaire, lorsque des difficults apparaissent, les concepteurs sont tents naturellement de reporter la cause sur les spcifications, de mme pour le client qui considre le spcifieur comme le responsable du projet. Mme si la spcification permet un gain non ngligeable sur le cot du projet en considrant l'ensemble du cycle de vie, rien ne permettra de prouver que ce gain rsulte de la phase de spcification. Peut-tre mme au contraire, il sera voqu le surcot que reprsente cette tche. En dpit de toutes ces difficults, les industriels sont de plus en plus conscients de l'importance d'une bonne spcification, probablement comme rsultante d'une raction dfensive issue de constatations multiples sur les difficults mener bien des projets. Aussi, le mtier de spcifieur 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 youre hooked, the old easy pleasures of system building are never again enough to satisfy you!!" [DEMARCO-79]. 10.6. COMPETENCES POUR SPECIFIER Les spcifications se dduisent des informations indiques par le client. Cette tche n'est pas si simple qu'il n'y parait. C'est probablement la tche la plus difficile dans le cycle de dveloppement d'un systme. Au moins, 3 qualits essentielles sont ncessaires pour aboutir un bon rsultat: adaptatif, communicatif, esprit d'analyse. M.C.S.E 185

Partie 3 - SPECIFICATION DUN SYSTEME


-A- ADAPTATIF

A partir d'une comptence de gnraliste, condition indispensable du fait de la varit des domaines d'application pour les systmes lectroniques, il faut tre capable d'acqurir l'expertise ncessaire du domaine du client pour pouvoir rdiger la spcification. D'autre part, comme le document doit tre exploitable par les concepteurs, il faut aussi tre expert en systmes lectroniques pour tre mme d'valuer la faisabilit et pour exprimer la spcification en termes comprhensibles par les concepteurs.
-B- COMMUNICATIF

Pour acqurir l'expertise du domaine considr, il faut tre l'coute de tous les acteurs ct client. Mais ceux-ci peuvent ne pas tre mme de juger de la pertinence de certains aspects. Aussi, c'est au spcifieur de dterminer les points essentiels et de conduire le dialogue pour extraire efficacement toutes les informations ncessaires. De plus, il doit tre mme d'exprimer clairement et d'une manire synthtique mais suffisante, la description du systme pour la rendre comprhensible aux 2 partenaires.
-C- ESPRIT DANALYSE

Le spcifieur a une responsabilit essentielle dans la russite 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 russite. 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 rflexion pour dduire les points essentiels. Dans les cas o le client n'a pas d'ides bien dfinies, l'esprit cratif du spcifieur peut conduire l'obtention d'une qualit meilleure. 10.7. RESUME Ce chapitre a permis de montrer l'importance de la spcification comme intermdiaire entre le cahier des charges et la ralisation. Les points essentiels prsents sont les suivants : - la spcification est un document vrifiable qui permet de s'assurer de la bonne comprhension du problme, - pour jouer correctement son rle, le document doit tre comprhensible la fois par le client et par les concepteurs. Pour cela, il doit tre facile laborer, facile lire, facile faire voluer, - le spcifieur assume un travail particulirement difficile, dont l'impact sur un projet est essentiel mais peu mesurable. Sa comptence doit tre multiple.

186

M.C.S.E

Chapitre 11

BASES POUR LA MODELISATION

Les chapitres prcdents ont montr l'intrt et la ncessit d'une description intermdiaire entre le client et les concepteurs. Cette description appele spcification est essentiellement un document. Deux points importants sont considrer ensuite: le contenu de ce document (nature et structuration des informations), et la dmarche qui conduit laborer ce type de document. Intressons-nous tout d'abord la forme et au contenu du document pour ensuite expliciter la dmarche. Une spcification a pour objectif de caractriser compltement un systme ou un produit concevoir sans faire tat de sa structure interne: le quoi et non le comment. Dcrire un systme d'un point de vue purement externe revient laborer un modle de comportement de celui-ci. Toute ralisation possdant les proprits de ce modle sera conforme aux spcifications. D'autre part, la spcification doit tre facile laborer, facile comprendre, facile modifier. Pour satisfaire ces objectifs, une spcification doit tre conforme un modle de spcification qui possde les proprits et qualits attendues pour toute spcification. La premire question importante se poser pour disposer d'un modle de spcification est donc: comment peut-on modliser tout systme sans faire tat de sa solution interne, celle-ci tant l'inconnue dfinir par la suite durant la conception?

M.C.S.E

187

Partie 3 - SPECIFICATION DUN SYSTEME C'est l'objectif de ce chapitre que de rpondre cette question essentielle. Prcisons d'emble que le choix d'un modle est une relle difficult compte-tenu du nombre d'articles et douvrages existant sur le sujet. Il s'avre que le type de modle dpend de la classe des problmes considrs. Ceci nous a conduit considrer dans MCSE, dfaut d'un modle unique, l'association de plusieurs types de modles de description. 11.1. QUE FAUT-IL CARACTERISER? Une spcification est une description purement externe de l'objet concern. Pour toute application ncessitant un systme lectronique, celui-ci n'est pas seul, isol du reste du monde. Si c'tait le cas, sans liens externes, donc sans entres ni sorties, mme actif, il ne serait d'aucune utilit; nul ne peut agir sur lui ni constater le rsultat de son activit. Ainsi, tout systme est obligatoirement impliqu dans un environnement comprenant des objets. La figure ci-dessous montre la situation habituelle pour un systme. Les objets peuvent tre de nature varie.

entit 2

Interaction

entit 1 Observation

Action
Systme

entit n

Environnement entit i Application

-Figure 11.1- Le systme spcifier et son environnement. Dfinissons tout d'abord la terminologie employe. Une APPLICATION au sens physique du terme est ici considre comme le systme ferm (ne possdant aucune relation utile avec l'extrieur pour le problme traiter), form du systme concevoir et des objets en relation avec celui-ci. L'ENVIRONNEMENT est l'ensemble des objets de l'application exclu le systme. Les objets de l'environnement sont appels des ENTITES. Un objet a un comportement dynamique et possde sa propre autonomie. Il s'agit obligatoirement d'une ralit fonctionnelle mais pas ncessairement physique. Une entit, tout comme un systme, possde des entres, des sorties, et au moins un tat interne qui caractrise sa situation chaque instant. Elle est modlisable aussi bien par une description externe qu'interne. 188 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Une entit fortement couple par des entres et des sorties sera considre en interaction avec le systme. C'est naturellement le cas par exemple pour l'entit utilisateur. Comme illustration, prenons l'exemple d'un systme de commande pour le chargement automatique d'un chariot. L'objectif de lapplication est de dplacer du matriau de P1 en P2 l'aide d'un chariot. Un systme lectronique permet d'excuter en automatique, sur demande de cycle par un oprateur, un cycle complet: P2 --> P1 --> chargement --> P2 --> vidage.
SYSTEME DE COMMANDE

cycle arrt durgence Matriau trappe de vidage

P2

P1

-Figure 11.2- Exemple dapplication. Cette application comprend 4 entits: le systme de contrle-commande, l'oprateur, le chariot, le tapis-chargeur. Chaque entit possde un tat interne - position pour le chariot, en rotation ou non pour le tapis-chargeur - et a un comportement autonome influenc par ses entres. La fonctionnalit de l'application qui consiste raliser un cycle automatiquement, est obtenue par l'entit systme en assurant un couplage entre les 3 autres entits. Le comportement global ne peut tre correct que si le systme 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 systme est donc obligatoirement li des entits de son environnement. Pour caractriser le systme, il faut ncessairement caractriser ses entres et ses sorties. Les entres du systme sont des sorties d'entits qui permettent de prendre connaissance de leur tat, les sorties du systme sont des entres pour les entits et donc des grandeurs d'action ou de commande pour ceux-ci. Invitablement, la description externe du comportement du systme passe par la caractrisation des entits. Ainsi, pour dduire sa spcification, la caractrisation du systme concerne donc: - son environnement, - ses entres sorties, - son comportement, - son utilisation. M.C.S.E 189

Partie 3 - SPECIFICATION DUN SYSTEME 11.2. NATURE DE LA CARACTERISATION : MODELISATION Les entits de l'environnement existent ou vont exister. Les caractriser revient dcrire la nature et le comportement de chaque entit un niveau donn de dtails. Il s'agit donc de modliser un objet rel sous la forme d'une abstraction. Le concept de modle, les types et qualits ont t prsents dans la partie 2 chapitre 8. Rappelons qu'il existe 2 grandes catgories de modles [COHEN-86, ALFORD-82, ABBOTT-86] : - les modles externes, qui permettent de caractriser un systme en exprimant exclusivement ses proprits (property-oriented): axiomes, relations entre sorties et entres, modles algbriques, prconditions et post-conditions. Ces types de modles sont trs formels, non vidents exprimer et comprendre pour un non-spcialiste et plutt adapts pour exprimer des transformations. A noter que la signification du terme modle externe est diffrente de celle utilise en base de donnes. - les modles explicites qui utilisent des lments caractristiques internes: variable d'tat, activits ou oprations internes. Plus simples laborer et facilement interprtables par des non-spcialistes, ils sont particulirement appropris pour dcrire des objets existants. Le niveau d'abstraction du modle est fonction des dtails de comportement souhaits. Par exemple, le chariot de l'exemple prcdent peut se modliser au moins selon 2 niveaux diffrents: - un niveau macroscopique, pour lequel la vitesse du chariot est reprsentable par 3 valeurs: 0 pour le chariot l'arrt, +VM pour le dplacement droite et -VM pour le dplacement 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 modlisation peut prsenter des vues diffrentes d'un mme objet. Il s'agit alors de diffrentes projections de l'objet sur son espace de description, par exemple: description statique, description dynamique, description des donnes, description des activits... 11.3. CARACTERISATION DUNE ENTITE Avant de dvelopper les modles de description, analysons tout d'abord ce qu'est une entit et les lments essentiels qui permettent de la dcrire. A noter que cette analyse servira aussi comme base pour la spcification du systme car celui-ci peut se considrer comme une entit ayant la particularit de ne pas exister avant sa ralisation. 11.3.1. Nature d'une entit Une entit est un objet conceptuel pour l'application. Elle peut avoir une existence physique ou matrielle tel qu'un oprateur ou le chariot, mais il peut aussi s'agir d'un objet fonctionnel ou logique, tel que par exemple un dpartement dans une entreprise, ou bien un objet purement abstrait: le vol d'un avion par exemple qui rsulte de l'association d'objets physiques et de donnes (avion, passagers, trajectoire...). Une entit possde sa propre identit dfinie par son nom. 190 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Pour faciliter la modlisation, les entits sont groupes en catgories refltant chacune des caractristiques communes. Chaque catgorie est nomme dfinissant ainsi un type d'entit; une entit de nom E est dite de type T. E est aussi appele une instance de T. Toutes les entits d'un mme type sont a priori diffrentes. Ceci est d aux valeurs diffrentes des lments caractristiques. On dit alors que les lments du type d'entit sont ses attributs. Par exemple, une personne comme type d'entit possde les attributs: poids et taille. 11.3.2. Nature des lments caractristiques Un type d'entit est caractrisable par un ensemble d'lments et de relations. Cette caractrisation s'effectue l'aide d'un modle qui exprime les grandeurs caractristiques de l'objet et les relations entre celles-ci. Le type de modle utiliser dpend de la nature des grandeurs caractristiques et des relations. Pour cerner les classes appropries de modles, intressons-nous aux catgories d'lments caractristiques. Pour les types d'entits qui concernent les systmes lectroniques, les lments considrer sont classs en 3 catgories: - les vnements, - les donnes, - les actions et activits. Expliquons la nature de chaque catgorie.
-A- EVENEMENT

Un vnement spcifie linstant dun changement dtat significatif. A cet instant est donc associe une signification. 2 types d'vnements sont utiles pour les systmes: - un changement d'tat. Le nom de l'vnement dfinit directement et compltement la signification. Par exemple, l'vnement T50 veut signifier que la temprature vient de dpasser 50C. - l'apparition d'une donne. A ce type d'vnement est associe une donne. L'vnement dfinit l'instant d'apparition ainsi que la disponibilit de la donne. La donne enrichit la signification de l'vnement. Par exemple l'vnement: la consigne de temprature vient d'tre modifie est associe la nouvelle valeur de la consigne. Pour viter toute ambiguit dans la terminologie lorsque la distinction s'avre ncessaire, le premier type est appel EVENEMENT et le deuxime INFORMATION. Ainsi, une information a une existence limite dans le temps et est caractrise par son type qui est celle de la donne associe.
-B- DONNEE

Une donne est une grandeur (ou un ensemble de grandeurs) dont l'existence est considre permanente. Seule sa valeur volue dans le temps. Par exemple, le chariot est caractris par plusieurs variables que sont les attributs: la position, la vitesse, la quantit de matriau transporte. On dit aussi qu'une donne est une variable caractristique de l'entit. Une donne est dfinie par son type caractris par des attributs. M.C.S.E 191

Partie 3 - SPECIFICATION DUN SYSTEME Comme cas particulier important, une VARIABLE dETAT est une grandeur permanente servant caractriser d'une manire unique et au niveau d'abstraction souhait, la situation de l'entit. L'tat d'une entit est reprsent par l'ensemble des variables strictement ncessaires pour sa caractrisation chaque instant. La nature des variables d'tat dpend du type de modlisation souhait. Par exemple pour le chariot, une modlisation de l'volution du chariot ncessite de considrer sa vitesse et sa position chaque instant. Pour une modlisation 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: arrt, dplacement gauche, dplacement droite.
-C- ACTION ET ACTIVITE

Une action est considre comme une opration ponctuelle agissant un instant donn durant l'volution de l'entit. Elle est indcomposable. On dit aussi qu'il s'agit d'une opration atomique. Une activit reprsente une vue de plus haut niveau. Elle reprsente l'enchanement d'une suite d'actions. Ainsi, une activit couvre une priode de temps aussi qualifie de phase. Une activit peut se caractriser par un tat, tandis qu'une action se caractrise par un vnement. Par exemple, l'action de mise en marche du chariot par le systme gnre un vnement pour l'entit commande, ce qui entraine l'activit de dplacement et donc l'tat en dplacement. La frontire entre ACTION et ACTIVITE n'est pas trs prcise. Selon le niveau de la modlisation (chelle de temps par exemple), une action considre comme ponctuelle pour un niveau macroscopique est une activit pour une modlisation plus dtaille. Par exemple, l'action d'arrt du chariot n'est pas instantane si on tient compte de son inertie. 11.3.3. Dpendance entre lments caractristiques Action et activit sont les seuls types d'lments gnrateurs (et donc actifs). La relation de dpendance est indique sur la figure suivante.

Donnes (pas obligatoire) ACTIVITE ou ACTION Evnement (obligatoire pour une action)

Donnes

Evnements

-Figure 11.3- Dpendance entre les classes d'lments. Une action tant ponctuelle, seul un vnement permet de dcider de son instant d'intervention. Ainsi, une action agit en rponse un vnement. Par contre, une activit est dans l'tat actif ou inactif. Seul un vnement peut la faire changer d'tat. En l'absence d'vnement en entre, l'activit est toujours effective sinon celle-ci n'est d'aucune utilit. 192 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Activits et actions peuvent produire des vnements et des informations, modifier des donnes ou des tats. Pour une entre d'action ou d'activit et de manire distinguer s'il s'agit d'une donne ou d'un vnement, nous utiliserons la simple flche pour les vnements (et donc aussi pour les informations) et la double flche pour les donnes: notation identique celle propose par WARD. 11.3.4. Nature des entres et des sorties Le caractre dynamique d'une entit rsulte des activits et actions internes. Seuls les vnements/informations, donnes et tats assurent le couplage avec son environnement. En entre de l'entit, les donnes et tats sont observables tout instant (consultation). Les vnements et informations sont fugitifs: une information na plus de signification aprs sa prise en compte. En sortie, donnes et tats permettent des observations externes permanentes, tandis qu'vnements et informations engendrent des actions externes. 11.4. TROIS VUES POUR LA DESCRIPTION DUNE ENTITE Compte-tenu de l'analyse prcdente, comment peut-on modliser une entit?. Les 3 lments essentiels sont: donne, vnement, activit, sachant que: - l'tat est un cas particulier de la donne, - l'information est un vnement contenu signifiant dfini par son type de donne, - l'activit est un regroupement d'actions. Une action peut donc aussi se comprendre comme une activit ponctuelle. Il faut ajouter ces lments des relations de dpendance. Une donne ncessite de dcrire sa structure, sauf s'il s'agit d'un type lmentaire. Une activit n'existe qu' des instants ou priodes dans le temps. Caractriser une activit ncessite, d'une part de la dtailler (par exemple par une spcification), d'autre part d'expliciter son intervention dans le temps, ce qui impose d'exprimer ses dpendances temporelles en utilisant des vnements ou des informations. Faute d'un modle unique qui permette de rassembler toutes ces caractristiques (voir en 8.2.1), une description cohrente pour une entit ncessite 3 vues complmentaires reprsentes sur la figure 11.4: - modlisation des donnes et informations (quoi). Il s'agit de dcrire les caractristiques de chaque donne. Lorsque celle-ci est compose, sa structure et les type et domaine de dfinition de chaque constituant de base sont dcrire. Il s'agit donc exclusivement d'une modlisation structurelle. - modlisation des activits (comment). Elle a pour objectif de dcrire les activits de l'entit et les relations avec son environnement par des donnes et des vnements. Il s'agit nouveau d'une modlisation structurelle. - modlisation du comportement (quand). Il s'agit de dcrire les instants d'apparition des vnements et informations, et les changements d'tat des donnes engendrs par les activits. Ceci revient modliser le comportement qui peut tre celui des activits mais aussi celui de l'volution des donnes. M.C.S.E 193

Partie 3 - SPECIFICATION DUN SYSTEME

QUAND

Comportement

Activits ENTITE

Donnes / informations

COMMENT QUOI

-Figure 11.4- Les 3 vues pour une entit. Ces 3 vues sont complmentaires et indissociables. Pour caractriser une activit, il faut connatre les donnes utilises et produites. Pour caractriser une entit, il faut connatre l'ensemble des activits et les ractions de chacune aux stimuli en entre. La cohrence globale rsulte d'une spcification correcte pour chacune des vues, ce qui induit un moyen de vrification. En effet, une redondance existe entre volution des donnes et volution des activits, les activits modifiant les donnes. Il faut reconnatre la prpondrance des donnes sur les activits. En effet, les donnes d'une entit (en tant que type bien-sr) sont plus stables que les fonctions et le comportement de celles-ci. D'o l'importance premire attacher aux donnes dans la modlisation. Le rsultat de cette analyse est en accord avec les principes de modlisation prconiss par d'autres auteurs pour les systmes temps-rel. HATLEY prconise une modlisation selon 2 vues: activits, contrle pour le comportement. Il indique dans l'annexe C de son ouvrage la troisime vue concernant les donnes [HATLEY-87]. WARD et MELLOR considrent les 3 vues pour la modlisation [WARD-85]. Dans la suite du chapitre nous dtaillons la modlisation prconise dans MCSE pour chacun des 3 types en dcrivant les modles utiliser. Certains modles ont dj t prsents dans la partie 2 et sont rappels ici pour que cette partie soit utilisable en autonome. 11.5. MODELISATION PAR LES DONNEES/INFORMATIONS Ne concernant exclusivement que les donnes et les informations, cette modlisation est indpendante des 2 autres vues. Les objectifs du modle sont les suivants: 194 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION - permettre une dfinition complte, concise et comprhensible de la nature et de la structure des donnes: catgorie, composition, type de chaque constituant, - tre appropri pour une large classe de donnes: du boolen jusqu'aux relations, - tre conceptuel pour dcrire exclusivement la signification et non une implantation. 11.5.1. Modlisation selon 2 niveaux La modlisation des donnes est un sujet largement dvelopp dans la littrature. De nombreux auteurs en font tat: [ABBOTT-86, DEMARCO-79, JACKSON-83, WARD-85, HATLEY-87, MARTIN-88]. Lapproche adopte ici est trs proche de celle des modles de donnes orients objet, elle nest donc pas limite des modles du type relationnel [DATE86, GALACSI-86-89, BALLY-87, VELEZ-89]. Elle est base sur l'ide qu'une donne (en tant que type) peut se dcrire partir de 2 catgories d'lments: - l'entit donne (ou aussi objet donne), - la relation. L'entit donne est ici considre comme un ensemble cohrent de grandeurs concernant un mme sujet. Une relation exprime par contre un fait entre plusieurs sujets; il ne s'agit donc pas d'une dpendance hirarchique. Pour viter toute ambiguit d'interprtation, les sujets (ou objets) sont appels entits dans la terminologie de cet ouvrage. Pour la modlisation par les donnes, la connaissance de l'volution n'est pas ncessaire. Seul suffit la connaissance des tats de l'entit tout instant. Dans ce cas, une entit est modlisable par un ensemble dattributs dfinissant la donne qui la caractrise compltement, d'o l'appellation entit donne. Par exemple, pour une voiture, les attributs suffisants peuvent tre: date d'achat, propritaire, numro d'immatriculation. Une relation concerne des donnes lies entre elles pour exprimer un fait. Par exemple pour le fait: une personne est propritaire dune voiture, la relation de proprit lie les 2 entits personne et voiture. Un modle appropri existe pour chacune des 2 catgories (voir 8.3.2): - le modle de composition hirarchique pour les entits donne bas sur les oprateurs: composition, alternative, ensemble. Ce modle est classique. Les auteurs utilisent des notations quelque-peu diffrentes: notation graphique pour JACKSON, notation syntaxique pour DEMARCO, WARD, HATLEY. Il est aussi possible dajouter le concept de dpendance quest lhritage; un objet (et donc comme cas particulier une donne) hrite de toutes les caractristiques de lobjet dont il dpend. Cette dpendance limite la donne se traduit par le concept de type: une donne est dfinie par son type. - le modle entits/relations de CHEN, avec aussi des variantes pour la notation. La figure 11.5 donne une reprsentation graphique du modle pour chaque catgorie. La signification des symboles est explique dans les paragraphes suivants. M.C.S.E 195

Partie 3 - SPECIFICATION DUN SYSTEME

modle entits / relations

Modle de composition hirarchique


alternative

Di

Dj
Dk

composition ensemble Dn Dm

-Figure 11.5- Modlisation d'une donne. Notons que chaque modle permet une description par raffinement en utilisant pour chaque donne Di lun ou lautre des 2 modles: dcomposition en relations, dcomposition en grandeurs plus lmentaires. Ainsi ce modle est plus gnral que le modle relationnel; il est plus proche du modle objet et dune modlisation par des mcanismes dabstraction tels que: lagrgation, la composition-dcomposition, la gnralisation-spcialisation. 11.5.2. Modle pour la description des entits donne Pour caractriser ce type de donnes, 3 aspects essentiels sont expliciter, savoir: la signification, la composition, le type [WARD-85]. Le modle de structuration est bas sur les 3 oprateurs fondamentaux: concatnation, slection, rptition. Une entit donne est reprsente par un rectangle, en particulier lorsquil sagit dune donne de base. Le type de la donne est indiqu dans le rectangle et le nom de la donne est plac lextrieur. Pour la description de la composition on adoptera les conventions de reprsentation syntaxique et graphique suivantes: = est compos de
V

et (TOGETHER WITH)
V1 V2 N V3

[N1 | N2 | N3 | N4] slection d'un parmi


N1 N2 N3 N4

l{V}n

ensemble de

1 i V

196

M.C.S.E

Ch 11 - BASES POUR LA MODELISATION l est le nombre minimum dlments et n le nombre maximum dlments dans l'ensemble. Par dfaut les bornes de l'ensemble vont de 0 l'infini. Lexemple suivant montre le modle graphique pour une donne structure et prsente la notation syntaxique quivalente.
S A1 = X+Y A2 = {C} A = [A1|A2] S = B+A = B+[X+Y|{C}] X : boolen Y : couleur C : entier B : tat couleur = (noir, rouge, blanc) tat = (marche, arrt) X boolen Y couleur C entier A1 A2 Etat

-Figure 11.6- Exemple de description dune entit donne. Ainsi pour la notation syntaxique la composition et le type dune donne sont dfinies par le symbole "=", tandis que le domaine de dfinition est spcifi par ":". S peut aussi scrire globalement: S = B:tat + [X:boolen + Y:couleur | {C:entier}] Pour le modle structurel chaque lment dsign par un lien possde un nom et est dfinie par un type de donne. Une donne particulire comme partie dune entit est dsigne par la concatnation des noms des liens du chemin aboutissant cette donne. Par exemple un lment i de lensemble {C} est dsign par: S.A2.C[i]. Lorsquil sagit dune seule grandeur, on peut confondre dans une structure le nom de la grandeur et le nom de son type. Par exemple le nom B nest pas obligatoire, il est possible dcrire S= Etat:(marche, arrt) + A. La notation propose permet de bien identifier les 3 catgories de donnes. 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 donnes a t donne en 8.3.2. Les donnes considres comme lmentaires car non dcomposables sont des grandeurs spcifies sur un domaine de dfinition. Les types habituels sont ceux connus en programmation: boolen, entier, flottant, numration... M.C.S.E 197

Partie 3 - SPECIFICATION DUN SYSTEME Pour amliorer la spcification des donnes, en particulier vis vis de l'application, il est utile de considrer tous les renseignements qui caractrisent chaque grandeur. Ses attributs sont des proprits qui particularisent cette grandeur dans un ensemble. Une valeur est associe chaque attribut. La figure suivante illustre quelques exemples pour des variables.
Attributs Nom Definition
Unit Gamme Resolution Priode

Signaux continus

POSITION

Position du chariot

mtre

0 - 10

0.01

10 ms

VM

Vitesse du moteur

tr/mn

0 - 6 000

permanent

Attributs Nom Definition


Commande du moteur Nbre de valeurs Noms des valeurs Arrt 3 Avant Arrire Arrt Acclration Constant Dclration 20 ms Priode

Signaux discrets

CMD

ETAT

Evolution de la vitesse

permanent

-Figure 11.7- Exemples de dfinition d'une information ou dune donne. Ainsi, des attributs classiques pour des donnes dans les systmes temps-rels sont: le type de l'information, le domaine de dfinition ou les limites, la prcision (ou la rsolution), l'unit, la priode dvolution de la grandeur (cas des signaux chantillonns). VITESSE = type: rel, limites: 0-200, prcision:1, unit: KM/H* VM: VITESSE. 11.5.3. Modle pour la description des relations Au-del de donnes identifies individuellement, la comprhension dune entit ou dun ensemble dentits peut ncessiter d'exprimer des relations. Ceci est particulirement vrai pour les applications qui ncessitent la mise en place de bases de donnes [WARD-85, MARTIN88]. La comprhension dune entit peut ncessiter de dcrire des relations entre entits. Par exemple, un client dune banque possde un compte, il tablit des chques, il reoit priodiquement 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 entits (voir aussi 8.3.2-B). La notation de la figure suivante reprsente une relation. Les rectangles sont des types dentits donne, le losange et les liens exprime la relation.
1 n

(a)

Personne

Possde

Voiture

Attributs relation

Date dachat

(b)

Personne

Possde

Voiture

-Figure 11.8- Reprsentation graphique d'une relation. Le graphique de la figure 11.8 veut dire: telle Personne possde une voiture. Ce qui peut aussi s'crire par la notation: Possde(Personne, voiture). Ainsi, sujets, objets, noms sont les entits. Le verbe exprime une relation. A noter que pour la notation, chaque rectangle reprsente le type d'entit. A nouveau plusieurs modles graphiques existent, tous correspondant une mme signification. Trs souvent une relation en elle-mme doit en plus possder des attributs. Ces attributs reprsents par un rond sont des modificateurs de proprits pour la relation. A l'exemple de la relation (a), on peut par exemple associer la date dachat. Un lien de relation peut concerner plusieurs entits d'un mme type, chaque entit tant identifiable. Si une personne possde plusieurs voitures, plutt que de se contenter du nombre, chacune des voitures sera dfinie par: son numro dimmatriculation, sa marque,.... La cardinalit d'une entit dans une relation (selon la notation de CHEN) est dfinie 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 propritaire et n spcifie quune personne peut tre propritaire de plusieurs voitures. Trs rcentes, des mthodes de spcifications orientes objet sont bases sur une approche par les relations [BAILIN-89, KURTZ-89]. Elles ont pour objectif de favoriser par la suite une conception oriente objet. 11.5.4. Modlisation par les donnes En se limitant la seule vue des donnes, une entit se trouve dcrite par un modle statique. Elle est alors caractrise par l'ensemble de ses variables spcifiques, chacune possdant des valeurs qui fixent son tat tout instant. Par les sorties de lentit l'environnement peut observer son tat, et par ses entres il peut modifier cet tat en changeant des valeurs. Cette modlisation est la plus simple. Elle correspond une description du type combinatoire ou opratoire: tats dpendant uniquement des entres tout instant. M.C.S.E 199

Partie 3 - SPECIFICATION DUN SYSTEME Une telle modlisation est de toute vidence la premire envisager. Elle permet de dduire les grandeurs essentielles et les variables d'tats dune entit, puis leurs relations avec les entres et les sorties. Mme si elle ne s'avre pas suffisante, elle facilite ensuite une modlisation plus complexe. Comme premire illustration, le chariot de l'exemple prsent en dbut du chapitre en 11.1 est modlisable par une seule variable qui est son tat, celle-ci pouvant prendre 3 valeurs: dplacement_droite, dplacement_gauche, repos. Ltat dpend directement de la commande applique qui est dfinie par 3 valeurs possibles: avant, arrire, arrt. Ainsi la modlisation du chariot peut se modliser par: ETAT_CHARIOT= (cas CMD: AVANT --> Deplacement_droite; ARRIERE --> Deplacement_gauche; ARRET --> repos); Si les valeurs possibles de ltat interne et celles de lentre sont les mmes on peut alors crire: ETAT_CHARIOT: (avant, arrire, arrt) = CMD. Comme deuxime exemple, une voiture pour le contrle automatique de vitesse et pour la maintenance est modlisable par un tat comprenant: - le nombre de kilomtres, - la vitesse courante, - chaque plein, l'information quantit d'essence. Ceci scrit: ETAT_VOITURE = Nb_km: entier + Vitesse : entier + Q_essence : entier. Comme dernier exemple, un oprateur utilisant le centrifugeur dcrit en 9.8.1 peut dcider de la mise en marche, de larrt ou dune modification de la vitesse de consigne. Ceci se traduit par une information spcifie par: ORDRE = [ MARCHE | ARRET | VCONSIGNE: 0..3000 tr/mn ]. 11.6. MODELISATION PAR LE COMPORTEMENT Les modles de comportement ont pour objectif d'exprimer pour une entit les dpendances entre vnements et actions. Sur le plan comportemental, une entit est dans un tat correspondant une phase ou une tape. Un vnement ou une information en entre engendre une volution du comportement et donc induit un changement d'tat. Lorsque lentit est modlise par une donne (un tat comme cas particulier), un modle du type comportemental dcrit l'volution des grandeurs de cette donne sous l'influence d'vnements en entre. Il faut diffrencier les modles tats discrets des modles du type continu (voir 8.3.4). Les modles continus dcrivent une volution permanente tandis que les modles discrets limitent la description des tats particuliers qui ne changent qu des instants particuliers. Lorsqu'une modlisation ne peut pas se faire sur la base d'tats discrets, des modles du type continu sont utiliser: - modles mathmatiques paramtriques: fonction de transfert, quations rcurrentes, quations diffrentielles... - modles non-paramtriques : reprsentation de signaux, gabarit en frquence... 200 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Ces modles servent reprsenter une volution temporelle, mais aussi toute autre type de reprsentation telle quune reprsentation frquentielle par exemple. 11.6.1. Les diffrents modles tats discrets Un graphe du type tat/transition permet une modlisation tats discrets. A chaque transition est associe une condition spcifiant l'instant du franchissement de la transition. Une condition est dfinie par: - l'apparition d'un vnement, - un tat particulier pour des donnes, - la combinaison dun vnement et dtats pour des donnes (cas le plus gnral). Une condition ne peut pas tre dfinie par plusieurs vnements car lexistence de plusieurs vnements na pas de signification. Seule serait possible une relation dordre entre vnements tel que: ev1 puis ev2 par exemple. Par contre, une condition peut inclure toute expression logique entre les donnes. Par exemple la condition: MARCHE.((ETAT = repos)+(ETAT = arrt)) fait intervenir lvnement MARCHE et le rsultat dune expression logique. Les activits tant durables, elles sont associes aux tats ou tapes, tandis que les actions qui sont instantanes sont associes aux transitions. La figure 11.9 explicite la notation pour un diagramme tats finis. Une barre sur le lien entre 2 tats est utilise pour reprsenter la transition. Les tats ou tapes sont habituellement reprsents par des ronds, parfois par des rectangles pour des raisons de commodit de dessin.
V=0

Etape i

exemple
Marche T=0 V = +Vm

arrt
bute droite V = -Vm

condition actions

Etape j

activits

Dplace gauche
T > 10 s T=0

Dplace droite

-Figure 11.9- Notation pour le modle de comportement et exemple. Sur lexemple: Marche, bute droite sont des vnements. T > 10 s est une condition logique, T = 0 est une action ponctuelle, V = 0 est une action durable. T reprsente le temps courant. Tous les modles drivs de ce type de graphe tat/transition sont utilisables. Les modles connus diffrent par ajot de significations complmentaires. Citons en particulier: - le DIAGRAMME A ETATS FINIS (Finite State Machine). Ce diagramme limite la modlisation un comportement squentiel: une seule tape active la fois. Lorsque le nombre d'tats de l'entit modliser 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 DUN SYSTEME (Specification and Description Language) est un exemple de ce type de modle particulirement appropri pour la spcification des protocoles [ORR-88]. Lorsque le nombre d'tats ou de transitions devient important, il est prfrable 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 associes des franchissements de transitions. Par contre des actions impulsionnelles sont possibles en dbut dtape. Par rapport au diagramme tats finis, il permet de reprsenter des volutions simultanes en utilisant les divergence et convergence ET. - le STATECHART [HAREL-87-89] est une extension du diagramme tats finis pour rduire ses limitations. Le STATECHART permet essentiellement de reprsenter la modularit, une description hirarchique, des volutions simultanes, la notion dhistorique. - le RESEAU de PETRI qui, avec la notion de jeton, permet de modliser le comportement temporel de plusieurs entits volution parallle lorsqu'il est ncessaire de faire apparatre des synchronisations et des exclusions mutuelles. Bien connu comme outil mathmatique pour extraire des proprits, ce modle est plus gnral que les prcdents mais non hirarchique. Le modle tat/transition permet le raffinement. En effet, une tape peut se dcomposer pour un niveau plus microscopique en une squence d'tapes ou d'tats. Une action peut aussi se dcrire selon une squence d'actions plus lmentaires. Le STATECHART illustre bien cette possibilit, ce qui est particulirement favorable pour l'laboration progressive d'une spcification et pour la lisibilit du document qui en rsulte. La figure ci-aprs montre l'intrt de ce modle.

Etat initial sur reset


A21

A11 A0

Reset Arrt
A12 A121 A22

Dfaut
A122

Reset

Rinitialisation de A1 et A2 en A11 et A21

Sortie de A1 et A2 et retour en A0

A1

Activation parallle

A2

A
-Figure 11.10- Exemple de spcification par STATECHART. 202 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Sur cette figure, on constate en particulier la possibilit de reprsenter: des activations parallles (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 (dfaut, reset). Dans les paragraphes qui suivent, nous montrons 2 types de modlisation puis nous indiquons les rgles de reprsentation prconises pour ce modle de comportement. 11.6.2. Modlisation par les tats La modlisation dune entit par ses tats permet de dcrire globalement son volution. Il sagit donc dune vue externe. Par opposition une modlisation statique, exprimer une volution correspond une modlisation dynamique. L'volution n'est plus uniquement fonction des entres mais aussi de l'historique sur celles-ci. Pour une entit qui peut se dcrire par des tats discrets, le comportement s'exprime par un ou plusieurs graphes tat/transition. Les tats se dduisent de l'analyse des donnes et des vnements caractristiques de l'entit aprs une modlisation par les donnes. Pour les entits volution continue, des modles mathmatiques ou physiques sont plus appropris. Comme exemple, considrons nouveau la modlisation du chariot pour le transport de matriau dcrit en 11.1. Nous supposerons que le chariot possde une trappe pour le vidage de son contenu. De plus, des butes comme scurits en P1 et P2 arrtent l'volution du chariot mme en prsence des commandes de dplacement. Pour une modlisation macroscopique, l'analyse des donnes/vnements conduit la liste suivante: - vitesse du chariot V: 0, -VM,+VM. - position P: PP2, P2<P<P1, PP1. - l'tat de la commande dplacement: (marche droite (MD), marche gauche (MG), arrt), do CMD : (MD, MG, ARRET). - les vnements de commande trappe: Ouverture, Fermeture. - la position de la trappe: ouverte, ferme. En considrant les deux variables dtat vitesse et position, la modlisation ncessite de considrer 5 tats distincts. Pour P2 < P < P1, 3 tats sont possibles pour la vitesse. Le comportement global du chariot qui en dcoule est donn ci-dessous.
cmd = MD

Arrt bute P2

P P2

cmd = ARRET Dplacement gauche cmd = MG

cmd = ARRET

Repos
cmd = MD

Dplacement droite

P P1

Arrt bute P1

DEPLACEMENT

cmd = MG

TRAPPE Ferme

Ouverture

Ouverte
Fermeture

-Figure 11.11- Modlisation globale du chariot. M.C.S.E 203

Partie 3 - SPECIFICATION DUN SYSTEME Pour la modlisation globale du chariot, 2 variables sont suffisantes pour reprsenter son volution: tat_dplacement_chariot, et tat_trappe. Ces variables sont des tats internes et pas obligatoirement des grandeurs observables; des capteurs sont ncessaires pour rendre ces variables disponibles en sortie. Cette modlisation montre que les 2 rles du chariot - dplacement, vidage - sont indpendants, ce qui conduit lutilisation de 2 diagrammes tats finis indpendants pour le comportement. Une modlisation par les tats peut aboutir des activits (ou rles ou fonctions ou sous-ensembles) non-indpendantes. Dans ce cas, les graphes d'tats sont coupls pour des variables d'tat ou des vnements internes. La dmarche suivre pour obtenir ce type de modlisation consiste rechercher tous les tats successifs de l'entit, puis les conditions de transition et les actions. Cette technique de modlisation est particulirement efficace pour dcrire des entits physiques caractrisables par un vecteur d'tat interne. Elle savre extrmement importante pour la spcification des systmes de contrle/commande temps-rel et les systmes lectroniques. Cette dmarche est celle suivie par les automaticiens qui commencent tout d'abord par modliser le procd physique avant de dduire sa commande. 11.6.3. Modlisation stimuli/rponse Tandis que le modle prcdent est bas sur la notion d'tat, on se place ici dans le cas d'une entit riche en stimuli en entre et assurant pour chacun plusieurs actions. Plutt que de chercher tous les tats de l'entit, il est plus facile de modliser l'enchanement des actions entreprises sur l'apparition de chaque vnement. Ceci revient obtenir une modlisation globale des sorties pour chaque entre d'vnements ou d'informations. Une telle modlisation est particulirement approprie pour les systmes dits ractifs, c'est-dire ceux qui produisent des vnements partir de stimuli. Ces entits possdent des entres et des sorties plutt du type vnements et informations. C'est le cas en particulier pour des entits communicantes: utilisateurs et interfaces homme-machine, systmes de communication, etc. Comme exemple, considrons le cas de 2 entits, lune dmission, lautre de rception de messages. Pour chaque message mis, l'entit de rception doit transmettre un acquittement positif si le message est correct (ACK), ngatif sinon (NACK). Pour obtenir une fiabilit du transfert en cas de perte du message ou de l'acquittement, lmetteur renvoit le message tant quil na pas reu un acquittement indiquant un transfert correct (ACK). Le protocole pour le dialogue et la modlisation de lmetteur et du rcepteur sont dcrits sur la figure 11.12. Le modle est bas sur le diagramme tats finis. Les symboles et reprsentent l'arrive et la production d'une information. Les tats reprsentent des phases d'attente, ce qui correspond lattente dune initiative de la part du correspondant. Les actions reprsentent les ractions de l'entit. La notation utilise est pratique pour la spcification de protocoles entre entits 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

Rcepteur

Envoi de Mess i
Recepteur

Mess i

Rep = [ Ack i | Nack i ]

Tack (temps dattente)

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

Rcepteur

Repos

Attente demande

Nack i Mess i message? correct non correct

Dsir transfert

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

Ack i

-Figure 11.12- Modlisation d'un metteur et d'un rcepteur de messages. Cette modlisation est intressante car elle permet d'ajouter des caractristiques complmentaires au comportement, telles que lindication de temps de rponse ou de contraintes de temps. De telles spcifications expriment des temps minimum et maximum entre l'apparition d'un vnement en entre et en raction la gnration des sorties. La dmarche de spcification pour ce modle consiste exprimer toutes les actions entreprendre sur apparition de chaque vnement, puis dcrire le squencement. 11.6.4. Rgles prconises pour le modle de comportement tats discrets Tous les modles tats discrets sont en principe utilisables. Ce paragraphe rsume la notation prconise partir du diagramme tats finis. Cette notation a pour objectif de clarifier les catgories des lments utiliss de manire favoriser la lecture et la M.C.S.E 205

Partie 3 - SPECIFICATION DUN SYSTEME comprhension d'une spcification faite par un modle graphique. Lintrt de cette notation est de permettre dexprimer toutes les spcifications avec un seul modle plutt que dutiliser un modle spcifique pour chaque catgorie de problme. Cette notation est conseille mais pas obligatoire. Un spcifieur peut devoir se plier des contraintes de notation imposes par le donneur dordre. Ne pas oublier non plus quune spcification doit tre vrifie et donc doit tre comprhensible par le demandeur. Si la notation prconise nest pas connue, il suffit de lexpliciter pour rendre les documents comprhensibles. Les quelques rgles essentielles sont les suivantes: - Tous les lments utiliss (tats, vnements, donnes, actions) possdent un nom significatif pour lobjet modlis. - Les tats sont reprsents par des ronds (ou des rectangles), chacun dsign par un nom significatif pour l'entit modliser. L'tat de dpart est identifi par un contour double. - Les changements possibles entre tats sont reprsents par des liens orients. - Les transitions sont reprsentes par une barre sur le lien orient entre 2 tats. - La condition de changement d'tat est exprim ct de la transition. - Les actions ponctuelles sont associes des transitions. - La notation pour les transitions est la suivante: CONDITION ou CONDITION/ACTIONS ACTIONS - Les actions durables sont associes aux tats (par exemple Vcmd = +VM). La gnration d'vnement ou d'information durant un tat est impossible car linstant nest pas dfini. Les lments en entre, utilisables pour exprimer une condition, sont de 3 catgories: vnement, information, donnes. Rappelons que l'information a la signification d'un vnement porteur d'une donne. Dans une condition, au maximum un vnement est possible, de mme vnement et information sont exclusifs. Pour diffrencier les 2 types de conditions - vnement, information - on utilisera: Ev pour l'vnement (Ev est son nom)

Mess

pour une information (Mess est son nom)

Les valeurs de donnes ou dtats sont utilisables comme condition ou comme complment un vnement. 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 diffrencier les 3 catgories: vnement, information, donne. Pour l'vnement 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 donne. 206 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Pour les informations gnrs, le destinataire peut aussi tre indiqu pour lever les d'ambiguts possibles (M -> entit). Des actions et des tats diffrents peuvent dcouler du contenu d'une information. Pour reprsenter simplement les alternatives, on utilisera un rectangle allong avec en interne la question et en externe diffrentes sorties correspondant aux cas possibles. La figure ci-dessous rsume lensemble de la notation conseille.
entit 1 entit 2
attente rception

Repos

MARCHE T := 0

entit 2

reu

attente limite T > 10 s

M? S = NON_PRET OK NOK REP= erreur

reu

REP = correct

-Figure 11.13- Notation conseille pour une modlisation tats discrets. Lorsque la modlisation ncessite de procder par raffinements successifs, le diagramme tats finis peut apparaitre inappropri. Il est alors conseill dutiliser de prfrence le statechart (voir en 11.6.1). 11.7. MODELISATION PAR LES ACTIVITES La modlisation par les activits a pour objectif de dfinir les relations entre les donnes ou les vnements/informations et les activits de l'entit concerne. Une activit dsigne une transformation de donnes ou d'informations en entre en d'autres donnes ou informations en sortie. La modlisation est base sur l'utilisation d'un graphe des dpendances. Les 2 modles les plus communment cits pour ce type de modlisation sont: - le modle SADT qui permet de modliser les relations donnes/activits selon 2 vues duales: l'actigramme orient vers la spcification des fonctions ou activits, le datagramme orient vers la spcification des donnes et informations [IGL-83, ROSS85] (voir en 7.2). - le Diagramme Flot de Donnes (DFD) prconis par DEMARCO [DEMARCO-79] (voir en 7.3). M.C.S.E 207

Partie 3 - SPECIFICATION DUN SYSTEME Ces 2 modles reprsentent le flot des donnes et des informations, mais n'exprime pas le comportement de l'ensemble. En explicitant les chemins possibles pour les donnes, de tels diagrammes dcrivent qui transforme ou produit des donnes et des informations mais sans prcision de l'instant. Ces modles sont donc plutt structurels. Une activit peut nouveau se dcomposer selon un diagramme flot de donnes; il est donc hirarchique. Au stade final de la dcomposition, une activit ne peut tre dcrite que par sa spcification qui caractrise les transformations des entres. Il s'agit alors d'une modlisation du comportement. Une diffrence essentielle entre les 2 modles SADT et DFD est que le diagramme SADT ne fait pas de diffrence entre donnes et informations conformment la terminologie utilise dans ce chapitre. Pour un DFD, une donne est reprsente par un symbole Mmorisation (file ou data store), tandis qu'une information sert comme label sur un lien direct entre 2 activits. MCSE prconise d'utiliser de prfrence les diagrammes flot de donnes pour une spcification par les activits. Dj prsent dans la partie 2 en 7.3, nous rappelons succintement la notation graphique utiliser pour un diagramme flots de donnes et sa signification [WARD-85].
a
A1

E1

A2

S1

raffinement
E2

f
A3

e d V b c
A21 A23

Liens multiples : Z = X + Y Convention


Z X Y

e
Interprtation

A22

Deux sous-ensembles de Z sont utiliss par les deux activits dsignes. Z est compltement utilis par les deux activits dsignes.
Z

X Y

Z est la composition des deux parties X et Yprovenant dactivits diffrentes. Z est produit par lune des activits sources.

-Figure 11.14- Exemple de diagramme flot de donnes. Pour lexemple ci-dessus: 208 E1, E2 sont des sources et S1 un rcepteur, A1, A2, A3 sont les activits, a, b, c, f sont des informations, d, e, sont des donnes mmorises et lues appartenant V, A2 est raffine par un diagramme flot de donnes. M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Ce diagramme exprime que c rsulte d'une transformation de b aprs exploitation de la donne e appartenant V. b rsulte d'une transformation de a par A1 ou bien dune transformation de f par A3 qui produit aussi la donne d pour V. Rien n'est dit sur les instants d'apparition de b et de c partir de a, de mme pour la mmorisation 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 activits synchrones des informations, c'est--dire que A1 assure la transformation de chaque information a au moment de son apparition. Appropri pour la modlisation des systmes d'information, elle n'est pas suffisante pour la modlisation des systmes physiques. Pour reprsenter la transformation de donnes volution permanente, nous adoptons la notation de la double flche WARD, permettant ainsi de caractriser les entres et sorties d'activits pour des donnes permanentes, comme lindique la figure ci-dessous.
Commande radiateur

Temprature

Rgulation temprature

1/4 h

Enregistrement temprature

Temprature mesure Historique

-Figure 11.15- Notation de WARD pour des donnes volution permanente. L'interprtation de ce diagramme est la suivante: - l'activit Rgulation temprature value en permanence la commande radiateur partir de la temprature, - l'activit Enregistrement temprature s'effectue sur chaque vnement 1/4h pour mettre jour la donne historique. Les caractristiques de ce modle sont les suivantes: - il s'agit d'un modle graphique simple comprendre, ce qui est trs favorable pour une spcification, - il est hirarchique, aussi il favorise l'analyse progressive et la structuration, - il dcrit le point de vue des donnes et des informations et dtaille l'activit globale d'une entit, - il n'est toutefois pas suffisant pour connatre le droulement temporel global. Pour cela, il faut y ajouter la spcification temporelle de chaque activit. Pour remdier ce dernier aspect, WARD et MELLOR ainsi que HATLEY ont complt le diagramme flots de donnes par une spcification du contrle. M.C.S.E 209

Partie 3 - SPECIFICATION DUN SYSTEME Les instants d'volution de chaque activit sont spcifis, non pas par la description de l'activit elle-mme, mais par une spcification du contrle global de toutes les activits du diagramme flot de donnes. Le contrle global est alors spcifi par un modle tel que le diagramme tats finis. Le modle correspondant cette approche pour la spcification d'une entit ou d'un systme est le suivant [HATLEY-87].

Partie oprative

E
Donnes

(Donnes internes et activits)

S
Donnes

evcmd

evobs

eve

evs Partie contrle

Evnements

Evnements

-Figure 11.16- Modle gnrique pour la spcification d'un systme. La partie oprative qui concerne les donnes est dcrite par un diagramme flots de donnes, tandis que la partie contrle dfinissant l'volution temporelle des activits est dcrite par un ou plusieurs diagrammes tats finis. La figure suivante montre un exemple de modlisation selon la notation de HATLEY.
Diagramme Flot de Donnes DFA DFC 2 DFF 3 DFB DFG Action DFH DFE

Entres

Sorties

Diagramme flot de Contrle CFA evobs ev


e

Comportement pour le contrle 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 spcification DFD+contrle. 210 M.C.S.E

Ch 11 - BASES POUR LA MODELISATION Le comportement pour la partie contrle spcifie les tats actifs ou inactifs des activits des diagrammes flot de donnes et les vnements produits, ceci partir des vnements en entre et de ceux rsultant du DFD. Lactivit de contrle du DFD est reprsente par une barre qui se trouve spcifie par un automate tats finis ou une table de transition. La modlisation par les activits concerne le cas le plus gnral; une entit est caractrise par une collection de donnes et d'vnements et une collection d'activits. Lorsque lapproche flot de donnes est souhaitable, ce qui peut tre le cas pour des entits assez complexes, une telle modlisation donnes + contrle est fortement conseille. Comptetenu des 3 vues pour une modlisation, une description par les activits ncessite de dcrire et donc de trouver dans lordre 4 types de renseignements: - l'ensemble des donnes/informations (structure), - les relations donnes/vnements et activits (diagramme flots de donnes), - le comportement de chaque activit incluant la dfinition des entres/sorties. - lvolution des activits par lexpression du contrle. Cette stratgie de modlisation pour un systme est celle prconise par WARD et MELLOR, ainsi que par HATLEY. 11.8. GUIDE POUR LA MODELISATION La complexit de la modlisation selon les 3 vues: - donnes / informations, activits, comportement - est fonction de la nature de l'entit dcrire et du niveau de dtail souhait. Bien entendu, la mthode pour la modlisation en dcoule. A partir des 3 types de modlisation dcrits dans les paragraphes prcdents, il est ais d'expliquer la dmarche suivre pour toute entit. Elle est prsente comme la trajectoire suivre dans l'espace de modlisation 3 dimensions.
Comportement

Activits

1 Donnes informations

Raffinement des activits

-Figure 11.18- Dmarches pour la modlisation. M.C.S.E 211

Partie 3 - SPECIFICATION DUN SYSTEME La modlisation doit commencer par une analyse conduisant une description des donnes, vnements et informations de l'entit. L'approche se fait partir des entres et des sorties et en exprimant les dpendances. Cette modlisation peut suffire pour le problme traiter (cas1); il sagit alors dune modlisation statique. Si ce n'est pas suffisant, il faut poursuivre la modlisation lorsque l'aspect dynamique s'avre essentiel. Si l'volution de l'entit peut se caractriser globalement, donc selon une vue externe qui exprime les dpendances entre sorties et entres, il faut utiliser une modlisation par les tats ou du type stimuli/rponse. La modlisation est alors complte (cas 2). Lorsqu'une entit est complexe, l'approche globale prcdente n'est pas facile. La dmarche (cas 3) consiste alors faire une modlisation progressive par les activits en utilisant la technique de raffinement. Au stade final, chaque activit est dcrite par son comportement. Le comportement pour le systme global ou pour les sous-ensembles est dcrit par un diagramme flot de contrle. Beaucoup de mthodologies adoptent cette dmarche de spcification (voir chapitre 7). Dans certains cas de problmes, mme si lapproche cas 2 est possible, il n'est pas souhaitable de modliser individuellement chaque entit car une telle modlisation n'apporte pas une description suffisante pour l'application. L'approche par les activits est alors la plus approprie. Considrons 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 dmarche par les entits, on trouve les diffrents utilisateurs que sont: le service scolarit charg des emplois du temps, le service gnral responsable de la conduite du btiment et des salles. L'analyse de chaque catgorie d'entit ne conduit pas une vue suffisante pour le problme. Aussi, plutt que de suivre cette dmarche, recherchons le diagramme flot de donnes global pour cette application. Un tel diagramme est donn ci-dessous.
emploi du
Scolarit Alloc des salles

salles alloues

temps

Planification chauffage salles

Rle du systme

Chauffage

Salles disponibles

Planning chauffage

Historique

Config salles

Demande rapport

Bilan occupation des salles

Visu historique

Etat salle Demande historique


Service gnral

Rapport historique Rapport bilan


Service gnral

-Figure 11.19- Diagramme flot de donnes 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 activits, les vnements, les informations et donnes de l'application, sans devoir a priori les affecter telle ou telle entit. Elle s'avre aussi utile pour dcider d'une rpartition des tches et en particulier, il est facile de dlimiter le rle dun systme informatique (par exemple, la partie entoure en pointill). Comme remarque justifiant le guide propos, il est noter que pour des entits simples une modlisation par les activits a plutt tendance conduire une dcomposition trop lmentaire car le spcifieur guid dans son analyse par le diagramme flot de donnes ne dispose pas de critre clair d'arrt de sa dcomposition. Ceci se constate sur les exemples traits dans [WARD-85, HATLEY-87]. En particulier, le systme de rgulation de vitesse pour vhicule, spcifi par un diagramme flots de donnes conduit une complexit qui n'existe pas lorsque la modlisation est faite selon une approche par les tats. La spcification pour cet exemple respectant le point de vue dcrit dans ce chapitre a t donne dans la partie 1 au chapitre 6. 11.9. RESUME Ce chapitre est essentiel pour la comprhension de la dmarche prconise pour l'obtention des spcifications; il justifie les bases de la modlisation qui seront exploites dans le chapitre suivant. Rappelons les ides essentielles: - La spcification du systme commence par la dlimitation de son environnement et la caractrisation des entits qui composent cet environnement. - Les entits sont caractrisables par un modle explicite, tandis que le systme ne peut tre dcrit que selon une vue externe. Ainsi, la modlisation du systme sera base sur le comportement souhait de son environnement. - Une entit se dcrit par un ensemble d'lments caractristiques - vnements, donnes, actions ou activits - et par des relations. - La modlisation est base sur une description selon 3 vues: l'espace des donnes, l'espace des tats, l'espace des activits. - Selon la nature de la caractrisation souhaite, le spcifieur pourra utiliser: la modlisation par les donnes pour une description statique, la modlisation donnes/vnements et tats pour une description dynamique globale, la modlisation donnes/vnements et activits dans le cas le plus gnral lorsque les modlisations prcdentes ne s'avrent pas suffisantes.

M.C.S.E

213

Chapitre 12

DEMARCHE POUR LA SPECIFICATION

Pour l'tape de spcification, l'objectif est de dcrire les spcifications compltes du systme sous la forme d'un document structur, comprhensible, vrifiable. Si l'obtention d'un tel document ncessite un investissement en temps non ngligeable, le gain pour les phases ultrieures est de toute vidence trs apprciable et ceci tout particulirement pour la phase de mise en fonctionnement et de maintenance, car les erreurs seront alors faibles. Les chapitres prcdents ont servi expliciter les bases de la modlisation d'un systme. Le document de spcification, essentiel en aval pour la conception et en amont pour vrifier la bonne comprhension du problme pos, doit respecter un modle de prsentation. Le rle du modle de spcification est de dcrire tous les constituants ncessaires, la signification et l'interprtation de chacun d'eux, ceci pour disposer d'une spcification complte. Le respect d'un ensemble de rgles confre la spcification des proprits et qualits qui favorisent la vrification de celle-ci et son exploitation pour la conception. Ce dernier chapitre dtaille le contenu d'une spcification et la procdure suivre pour construire le document de spcification. Squences d'analyses et de dcisions, la dmarche propose est base tout d'abord sur une comprhension du "monde" dans lequel doit intervenir le systme, puis une description progressive du rle jou par le systme pour l'application. Chaque phase de la dmarche conduit laborer une composante de la spcification.

M.C.S.E

215

Partie 3 - SPECIFICATION DUN SYSTEME La dmarche est illustre par les 2 exemples dcrits la fin du chapitre 9. Pour favoriser la lecture et la comprhension de la mthode, le premier exemple est trait au fur et mesure de la prsentation des phases, tandis que le deuxime exemple est trait compltement en fin de chapitre. 12.1. LES CONSTITUANTS DUNE SPECIFICATION Rappelons tout dabord que la conception sera conduite selon 3 aspects: - l'approche FONCTIONNELLE, pour dfinir les fonctions internes du systme et les relations entre ces fonctions, - l'approche OPERATOIRE, pour exprimer le droulement temporel des fonctions et des actions, - l'approche TECHNOLOGIQUE pour dfinir une solution matrielle 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 spcifications exploiter, d'o l'intrt d'un classement en 3 catgories exprimant les aspects fonctionnel, opratoire et technologique. Une application est compose du systme concevoir et de son environnement. Ainsi une spcification doit comprendre: - une modlisation de l'environnement du systme, - une dfinition des entres-sorties, - le comportement souhait pour le systme, - la description de son utilisation. La modlisation de l'environnement concerne chacune des entits de celui-ci ainsi que les relations entre elles. Structur en 2 parties, une spcification comprend: pour la modlisation de l'environnement: - la description de toutes les entits, incluant pour chacune: la dfinition des donnes et vnements, la description du comportement global, ou si ncessaire, le diagramme flot de donnes et le comportement de toutes les activits. - la description fonctionnelle de l'environnement qui reprsente les relations existant entre toutes les entits sans le systme. pour la description du systme, - la description des entres/sorties, - la spcification fonctionnelle incluant: la liste des fonctions du systme, la spcification de ces fonctions. - les spcifications opratoires, - les spcifications technologiques, - un document prliminaire pour l'utilisation et l'installation. 216 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Les ensembles d'informations ncessaires sont ainsi reprsents ci-dessous.
Environnement Systme

Description fonctionnelle environnement Entres / Sorties Spcification systme Spcifications fonctionnelles entit j Fonction k Spcifications opratoires Spcifications technologiques

Donnes et vnements

Comportement

Comportement entit j

Utilisation

installation

-Figure 12.1- Composition d'une spcification. La prsentation hirarchique suggre dj la dmarche de spcification prsente dans le paragraphe suivant: - dmarche ascendante partir des entits pour l'analyse de l'existant, - dmarche descendante partir des entres/sorties et des fonctionnalits pour le systme. Lorsquil sagit dun systme complexe, la spcification est alors consquente; il nest pas judicieux de conserver une telle structuration. La solution consiste dans ce cas dcomposer tout dabord le problme en sous-ensembles fonctionnels, puis spcifier chacune des parties. La spcification du systme est alors une collection de spcifications de sous-ensembles. Cette structure facilite grandement la recherche des informations pour la conception et la ralisation. 12.2. PRESENTATION DE LA DEMARCHE Cette premire tape de la mthodologie, la plus difficile notre avis, conduit laborer un document complet des spcifications. Comme donnes d'entre, le spcifieur dispose du cahier des charges lorsque celui-ci existe. Il dispose aussi, seulement sur sa demande, des informations en rapport avec le problme connu du client (utilisateurs...). Aussi doit-il conduire son analyse avec efficacit. La dmarche dcrite dans ce chapitre lui sert de guide pour interroger, analyser, puis synthtiser et vrifier. Base sur la structure du document de spcification obtenir, la figure 12.2 rsume l'enchainement des phases de l'tape. Le travail se dcompose en 2 grandes parties : - modlisation de l'environnement, - spcification du systme. M.C.S.E 217

Partie 3 - SPECIFICATION DUN SYSTEME

Analyse environnement Comportement des entits

Modlisation de lenvironnement

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

Description fonctionnelle Dlimitation des entres/sorties

Spcifications fonctionnelles
Fonctions Comportement entits + systme

Elaboration des spcifications

Spcifications opratoires Spcifications technologiques


SPECIFICATIONS

-Figure 12.2- Enchainement des phases pour la spcification.

Pour la premire partie, la phase initiale concerne l'analyse de l'environnement pour identifier les entits utiles pour le problme. La phase suivante conduit une modlisation des entits juste suffisante pour le problme. Cette premire partie se conclut par une description fonctionnelle de l'environnement. Pour la deuxime partie, elle dbute par une dlimitation des entres et sorties. Suit une phase essentielle qui conduit expliciter les spcifications fonctionnelles. Les spcifications opratoires puis technologiques sont construites progressivement ainsi que les documents complmentaires d'utilisation et d'installation. Pour chaque phase de modlisation, le spcifieur procde en 3 temps: - ANALYSE: l'objectif est de faire apparatre par des discussions, par la lecture de documents, par l'observation directe, toutes les informations utiles: donnes, vnements, actions. - SYNTHESE: il s'agit de regrouper toutes les informations utiles sous la forme d'une modlisation en tant que description abstraite, - VERIFICATION: ncessaire, cette tche assure la validit du travail pralable. Les oublis et erreurs sont alors immdiatement corrigs. Il est essentiel de constater que le point de dpart qui consiste trouver les entits utiles, est trs important car c'est sur cette premire base que va reposer ensuite toute la conception puis la ralisation. L'effort en temps pour ce premier travail est ncessaire. Ce n'est pas du temps perdu, contrairement la premire impression que l'on serait tent d'avoir. Une spcification mene trop superficiellement va induire des temps supplmentaires 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 corrlation avec la mdiocrit des spcifications. Les paragraphes suivants dtaillent les caractristiques de chaque constituant ainsi que la dmarche pour laborer sa modlisation. Ayons en permanence l'esprit que le travail de spcification ne peut se faire que par une collaboration troite entre tous les acteurs ct client et le ou les spcifieurs. 12.3. ANALYSE ET MODELISATION DE LENVIRONNEMENT Cette premire partie de la spcification a pour objectif de dcrire l'existant. Savoir dcrire un existant est une premire qualit que doit avoir tout concepteur. Le modle de l'environnement est une ABSTRACTION, c'est--dire une description partielle plus ou moins macroscopique des parties utiles pour le problme. L'environnement est un univers temporel dans lequel voluent une ou plusieurs entits, lies ou pas entre elles. Il faut commencer par dlimiter et comprendre cet existant. Le premier objectif est donc de trouver dans l'environnement les lments qui ont une influence directe avec le systme. Le second objectif est de caractriser les dtails ncessaires et suffisants pour chaque entit. Le premier travail consiste donc faire le bilan des lments caractristiques de l'environnement avec comme finalit la dtermination des entits utiles. Si l'environnement est complexe, l'analyse peut se conclure par une dcomposition hirarchique. Bien entendu, l'analyse ne peut se faire que si l'objectif de l'application est bien connu. La dmarche suivre a t dveloppe dans le chapitre prcdent en 11.8 sous la forme dun guide pour la modlisation. Les informations ncessaires proviennent du demandeur. Fort probablement, le client a beaucoup de renseignements communiquer sur son besoin. Mais ceux-ci sont exprimer comme des suites non corrles. C'est au spcifieur de guider la discussion de manire avancer efficacement dans son analyse. Une visite sur le site est srement trs apprciable pour avoir une vue globale du problme ainsi qu'une reprsentation physique de l'installation tel que le schma d'organisation d'un atelier de production par exemple. 12.3.1. Modlisation de chaque entit En s'intressant plus particulirement une entit, le spcifieur doit produire une modlisation juste suffisante pour le problme rsoudre. Le niveau de description utile dpend de l'objectif du systme. Aussi, c'est de la comptence du spcifieur que de savoir apprcier partir du cahier des charges, le degr de raffinement du modle. Base sur les concepts dcrits dans le chapitre prcdent, la dmarche consiste faire l'inventaire de tous les lments caractristiques de l'entit, puis les classer pour dduire les relations structurelles et temporelles. L'analyse conduit classer les lments selon les catgories suivantes: - donnes/vnements: donnes, variables d'tat, vnements, informations. M.C.S.E 219

Partie 3 - SPECIFICATION DUN SYSTEME - activits: actions, activits. - relations: les relations entre donnes/vnements et actions/activits, les entres et sorties avec son environnement. La comprhension de l'entit en vue de sa modlisation peut passer par la prsentation des informations sous forme de tableaux, tels que par exemple ceux indiqus ci-aprs. Le premier dcrit les caractristiques des grandeurs de chaque entit, tandis que le second dcrit les relations entre les entits par les actions.
Entit
CHARIOT

Entre
CMD

Variable interne

Sortie

Dfinition
(MD, MG, AR)

spcification
Commande dplacement Position absolue du chariot Commande tapis

Position

P2 ... P1 Marche_tapis ou Marche_tapis

TAPIS_CHARGEUR

CT

Source

Entre

Action

Sortie

Destinataire

Oprateur

Cycle

Raliser un cycle de transfert

CMD CT

Chariot Tapis chargeur

Arrt

Arrt durgence

-Figure 12.3- Exemples de tables pour l'aide la modlisation. La modlisation selon les 3 vues: - donnes, activits, comportement - est alors possible. La technique suivre dpend de la nature de l'entit: modle statique pour les donnes/ vnements, modle comportemental global pour une entit assurant une ou peu de fonctions, modle stimuli-rponse pour une entit communicante ou ractive, modle flot de donnes pour une entit oriente transformation d'informations (voir les modles utilisables dans le chapitre prcdent). La procdure suivre consiste s'intresser d'abord une modlisation des donnes/ vnements. Si celle-ci s'avre suffisante, car conduisant dfinir toutes les entres et les sorties pour le systme, un modlisation plus complexe n'est pas ncessaire. Sinon, une modlisation globale est envisager de manire dcrire le comportement dynamique de l'entit. La modlisation par les activits n'est faire que dans le cas d'entits relativement 220 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION complexes (plusieurs activits simultanes), ou lorsque la dcomposition de l'environnement en entits ne s'avre pas judicieuse. Une approche par les relations sous la forme dun schma relationnel peut faciliter le travail de modlisation comme suggr dans [WARD-85, BAILIN89, KURTZ-89]. Comme exemple d'illustration de la dmarche, prenons le cas d'un systme pour la gestion des ouvrages d'une bibliothque. Il s'agit d'un systme d'information, et non d'un systme lectronique, mais la dmarche est similaire. Les entits pour ce systme sont au moins les livres. Tout livre est une instance du type livre. Chaque livre (existant pour la bibliothque bien sr) est caractris par : - son titre, - son auteur, - son numro, - son tat. Les tats possibles du livre sont: prsent, rserv, emprunt, perdu. Les vnements caractristiques pour chaque livre sont: achat, rservation, emprunt, retour, perte. Chaque vnement conduit un changement d'tat. Cette modlisation statique est a priori suffisante. Ceci scrit (voir la notation syntaxique en 11.5.2): LIVRES = {LIVRE} LIVRE = TITRE+AUTEUR+NUMERO+ETAT ETAT: (prsent, rserv, emprunt, perdu) Cette modlisation peut se complter par une description de l'volution de l'tat du livre en fonction des vnements telle que celle indique ci-aprs.
Retour

Emprunt Inexistant Achat Prsent Emprunt perte Perdu

Rservation

Emprunt

Rserv

-Figure 12.4- Modlisation des tats d'un livre. Pour le systme d'information charg de grer les livres, les entits de l'environnement que sont les livres ne sont pas lies au systme (pas d'observation directe de l'tat de chaque livre). En l'absence de cette observation, c'est au gestionnaire de la bibliothque de mettre jour dans le systme l'tat de chaque livre partir des vnements qui s'y rapportent. Pour cela, le systme doit possder en interne le modle d'volution ci-dessus et l'tat courant pour chacun des livres. M.C.S.E 221

Partie 3 - SPECIFICATION DUN SYSTEME Ce type de problme diffre de ceux des systmes lectroniques voqus dans ce document car les entits ne sont pas directement observables, mais la dmarche de spcification reste identique. La modlisation de lutilisateur comme entit est particulire. En effet son comportement nest pas prdictible; il est gnrateur dvnements et dinformations selon son bon vouloir. Face un clavier ou un pupitre rien ne peut lempcher dagir sa guise. Ainsi modliser lutilisateur seul selon un modle dynamique est inutile. La modlisation par les donnes/ informations est alors suffisante en exprimant compltement les actions de lutilisateur et les observations dont il dispose. 12.3.2. Description fonctionnelle de lenvironnement La synthse fonctionnelle a pour but de faire apparatre les relations entre les entits de l'environnement. Elle n'a d'utilit que pour des entits couples. Le premier intrt de cette phase est de prsenter une vue graphique synthtique de tout l'environnement. Un deuxime intrt possible est de pouvoir regrouper des entits de manire simplifier pour la suite la dtermination des spcifications fonctionnelles. Pour illustrer ce point, considrons l'application suivante qui a pour objectif de produire du ciment. Une toupie de ciment rsulte: dune quantit dagrgats (PA1 + PA2 +PA3), dune quantit de ciment (PC1 ou PC2 selon le choix) dune quantit deau QE calcule partir des valeurs prcdentes. La description de linstallation ci-dessous est suffisamment explicite pour que le lecteur puisse comprendre comment se ralise le bton.
Silos agrgats Rservoir deau 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 bton. 222 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Cette application inclut 12 entits. Chaque entit se modlise trs simplement par une relation: entres > tats > sorties, une fois identifies les entres, sorties et variables internes. La description fonctionnelle de l'environnement qui en rsulte fait apparatre un couplage entre toutes les entits sauf avec l'utilisateur. Elle est reprsente par la figure ciaprs.
EA1 EA2 EA3

Matriaux

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 agrgats 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

Rserve deau

QE

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

TPA

Tapis A

Agrgats
DTA DE DTC

Ciments

MLX

Cuve de malaxage
VD

Dciment

-Figure 12.6- Description fonctionnelle de lenvironnement. Compte-tenu de cette topologie et de manire simplifier la recherche de la spcification fonctionnelle, il est prfrable de considrer seulement 5 entits. Les ensembles: silos agrgats, balance et tapis forment une seule entit fonctionnelle produisant les agrgats, de mme pour les silos ciment. Comme autre exemple, la figure 12.7 concerne la description de zones pour le chauffage et montre la notation utilise pour dcrire une collection d'entits et de relations d'un mme type (diffrence faite entre type et instance). Lorsquil sagit dentits abstraites, la description de lenvironnement peut aussi se faire par un schma relationnel en utilisant une modlisation par les relations. 12.4. DELIMITATION DES ENTREES ET SORTIES DU SYSTEME Cette phase conduit dlimiter le systme en dcrivant ses relations avec l'environnement. Les entres du systme sont les informations des entits accessibles par leurs sorties. Les sorties du systme servent agir sur les entits par leurs entres. Ainsi, la nature des entres et des sorties du systme est dj caractrise dans la spcification des entits. M.C.S.E 223

Partie 3 - SPECIFICATION DUN SYSTEME

CLIMAT

Textrieur

Qchaleur[1..n]
ZONE

Tint[1..n]

Salles[1..n]

-Figure 12.7- Description de lenvironnement pour le chauffage des salles. Chaque variable est dfinie par: - son nom, - son utilisation: entre, sortie, - sa nature: vnement, informations, donne, tat, - sa dfinition fonctionnelle: structure, domaine de dfinition, frquence..., - ses caractristiques technologiques, si ncessaire. La dlimitation des entres-sorties se traduit par lexpression des liens entre les entits et le systme. Les liens une flche dsigne un vnement ou une information tandis que les liens double flche concerne les donnes et tats qui sont permanents. Cette phase n'aboutit pas obligatoirement la connaissance de toutes les entres et sorties indispensables. En effet, la spcification fonctionnelle peut conduire la ncessit d'informations supplmentaires non-observes. Dans de tels cas, des capteurs seront ajouter pour l'observation. Par retour-arrire, la dlimitation sera alors modifie. 12.5. EXEMPLE : CONTROLE EN VITESSE DUN CENTRIFUGEUR Illustrons cette premire partie du travail de spcification sur l'exemple du centrifugeur.
-A- ANALYSE DE LENVIRONNEMENT

L'environnement du systme comprend 2 entits: - le MOTEUR, pour lequel la vitesse est une grandeur caractristique, - l'UTILISATEUR, qui peut solliciter le systme en appuyant sur les poussoirs lorsqu'il le dsire.
-B- MODELISATION DU MOTEUR

La vitesse du moteur qui est la grandeur caractristique est fonction de la commande applique et de la charge entraner: Vmoteur = ft (cv, charge). 224 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Le modle doit tre global. Pour cela, il inclut l'lectronique de puissance servant de commande. CV est donc la consigne applique en entre de l'amplificateur. Si une modlisation plus pousse qui tient compte de l'inertie et peut-tre des non-linarits, s'avre ncessaire par la suite, le moteur peut se modliser par une fonction de transfert du 1er ordre par exemple ou par des quations diffrentielles.
-C- COMPORTEMENT POUR LUTILISATEUR

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 arrt. Le comportement de l'utilisateur est sans intrt pour le problme. Par contre, les informations en entre et sortie peuvent se spcifier comme ci-dessous. Toutes les actions de l'utilisateur sont exprimes par l'vnement ORDRE, car les actions ne sont pas simultanes.
Vrotation : 0 .. Vmax UTILISATEUR Erotation : (Rotation, Arrt) ORDRE = [ Marche | Arrt | Consigne : 0 .. Vmax ]

-Figure 12.8- Modlisation de l'entit utilisateur.


-D- DELIMITATION DES ENTREES ET SORTIES DU SYSTEME

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

Erotation : (Rotation, Arrt)

ORDRE = [ marche | arrt | consigne: 0..Vmax ]

Utilisateur Systme spcifier Moteur


CV : 0 .. CVmax

Vmoteur : 0 .. Vmax

-Figure 12.9- Dlimitation des entres et sorties du systme. M.C.S.E 225

Partie 3 - SPECIFICATION DUN SYSTEME 12.6. SPECIFICATIONS FONCTIONNELLES Les spcifications fonctionnelles sont des renseignements essentiels pour clarifier le problme traiter et l'objectif du systme. En effet, c'est partir de cette catgorie de spcification que dbute la conception. Aussi une mauvaise spcification et toute inprcision conduisent invitablement des difficults. Pour faciliter la comprhension, nous dfinissons tout d'abord ce qu'il faut entendre par spcifications fonctionnelles, puis nous dveloppons la dmarche suivre pour les exprimer correctement. 12.6.1. Nature des spcifications fonctionnelles Les spcifications fonctionnelles ont pour objectif de dcrire les fonctions que doit assurer le systme pour son environnement. Les seules fonctions considrer sont les fonctions dites "externes". Il ne sagit surtout pas des fonctions internes ncessaires pour satisfaire les spcifications car dans ce cas il s'agirait dj d'une description de la solution. Par fonction externe il faut entendre une fonction globale de l'application qui rsulte de la collaboration du systme avec des entits de son environnement. Prenons comme exemple d'illustration le cas du chariot pour le transport de matriau: la fonction globale pour l'application est "Ralisation d'un cycle de transport de matriau en automatique". Pour satisfaire cette fonction externe, il faut en interne du systme, une ou deux fonctions de contrle/commande du chariot et du tapis-chargeur. Enoncer les fonctions du systme n'est pas suffisant, chaque fonction ncessite d'tre caractrise pour viter toutes les ambiguts d'interprtation. S'agissant de fonctions externes, la spcification directe de celles-ci est souvent difficile sans voquer les entits. Pour illustrer la signification d'une spcification fonctionnelle, considrons la figure suivante qui reprsente une application comprenant 2 entits et un systme concevoir. Le systme est aussi une entit, mais qui n'existe pas avant son dveloppement.
partie caractriser

Entit 1

SYSTEME

Entit 2

-Figure 12.10- Exemple dapplication. Comme toute entit peut se modliser, la spcification fonctionnelle de l'entit "systme" correspond sa modlisation. Avant sa conception le systme est considrer comme une "boite noire" car on ne connait pas encore sa structure interne, aussi la modlisation ne peut tre que globale et selon une vue externe. Ainsi, une spcification fonctionnelle est donc 226 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION l'expression des actions effectues par les sorties du systme sur les entits de son environnement et ceci conditionnellement ses entres qui, elles, fournissent des observations sur cet environnement. Les modles et techniques de modlisation expliqus dans le chapitre prcdent sont donc utilisables pour exprimer ces spcifications. Pour une spcification exprime par un graphe tat/transition, les rgles respecter sont donc les suivantes: - les tats sont significatifs pour lapplication, - les actions concernent les sorties du systme ou des vnements internes ncessaires pour exprimer la spcification, - les conditions utilisent exclusivement les entres du systme, des tats de la spcification, des vnements internes en particulier le temps absolu ou relatif (cas des dures ). 12.6.2. Approches pour laborer une spcification fonctionnelle L'objectif est donc de dcrire le systme selon une vue externe en exprimant uniquement les relations entre ses entres et ses sorties. De cette manire, pour la conception, le systme pourra tre considr seul sans devoir faire rfrence aux entits. La difficult porte sur le choix du type de modlisation adopter. Contrairement aux entits de l'environnement o il s'agit de dcrire un existant, pour le systme les connaissances internes n'existent pas et donc seule une modlisation globale est possible. Mais comme un systme d'une taille raliste assure plusieurs fonctionnalits, une modlisation exprimant le comportement global du systme est rarement possible. Il faut donc caractriser le systme par sous-ensembles. En se basant sur les 3 types de modlisation dcrits dans le chapitre 11, 3 approches non exclusives sont possibles: - caractriser le systme partir de l'volution de ses sorties et des entres, - caractriser le systme partir de l'volution des entits, - caractriser le systme partir de l'application globale. Dtaillons ces 3 approches.
-A- APPROCHE PAR LES ENTREES/SORTIES

Pour chaque sortie du systme, il s'agit d'exprimer les tats successifs selon une modlisation globale, faisant tat des valeurs des entres du systme. La description peut se faire sparment pour chaque sortie ou globalement en partant alors plutt de chaque entre en utilisant un modle stimuli/rponse. Cette approche est possible lorsque les valeurs des sorties peuvent se dcrire par un modle donnes/informations, cest le cas lorsque le comportement des entits qui exploitent ces sorties n'est pas essentiel. Pour illustrer cette approche, considrons l'exemple d'un systme simple qui est un transmetteur srie. La dlimitation du systme est reprsente sur la figure 12.11. M.C.S.E 227

Partie 3 - SPECIFICATION DUN SYSTEME

DATA

TxD

Producteur

WR

Transmetteur
CTS TxRDY

Consommateur

-Figure 12.11- Dlimitation du systme avec ses entres et sorties. Le transmetteur mmorise la donne DATA sur apparition de l'vnement WR, mais seulement lorsque le transmetteur est disponible (exprim par TxRDY). Le transmetteur produit la donne mmorise sur la sortie TxD sous une forme srie (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.
Spcification transmetteur
PRODUCTEUR volution de TxRDY volution de TxD CONSOMMATEUR

Attente

TxRDY

Repos

TxD

Autre

CTS

WR Autre Dsir transmission et TxRDY DATA, WR

TxRDY.CTS Donne en transmission

prt pour rception

Donne TxRDY transmettre Donne en transmission

transmission

CTS Rception coute de TxD fin transmission fin disponibilit

-Figure 12.12- Spcification de la fonction de transmission. TxRDY prend 2 valeurs, ce qui conduit une modlisation 2 tats. Les conditions de transition dpendent des entres (WR) et d'tats ou vnements internes (Donne en transmission). TxD volue seulement durant l'tat transmission. Cet tat peut se raffiner pour reprsenter les tats successifs: bit start, bit donne (i), parit, bit stop. La reprsentation du comportement des entits Producteur et Consommateur n'est pas ncessaire, mais facilite la comprhension. 228 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION


-B- APPROCHE PAR LES ENTITES

Lorsque les entits sont essentielles pour expliciter le rle du systme, nous prconisons une approche par les entits. Cette approche est facilite par le fait que la premire phase de la dmarche de spcification conduit caractriser les entits chacune prise isolment. Plutt que de chercher dcrire sparment chaque sortie du systme, il est prfrable d'exprimer les tats successifs souhaits pour les entits de l'application. Ainsi, la mthode prconise dans MCSE consiste caractriser le comportement de chaque entit sous la contrainte ou la conduite du systme. Des tats de chaque entit se dduisent alors les commandes produire par le systme, ce qui conduit dfinir les sorties du systme. Cette rgle est trs importante. En dcrivant les effets du systme et les conditions qui les engendrent, cela revient spcifier les fonctions. Il sagit dune description externe du systme puisque les noms des tats ont un rapport avec les tats des entits et ne sont donc pas des tats internes du systme. Illustrons ce point de vue sur l'exemple du chariot assurant le dplacement de matriau (voir 11.1). Les 3 entits de l'environnement sans le systme sont spcifies comme ci-dessous.
Oprateur Dplacement Chariot Tapis_chargeur

Arrt P2 Arrt

P <= P2 cmd=MD

Dpl. gauche Autre


cmd=MG cmd=AR

Marche_tapis

Marche_tapis

Marche

Dsir cycle cycle

Arrt
Dsir arrt Arrt

Ferm
cmd=AR cmd=MD

Dpl. droite
cmd=MG P >= P1

Fermeture

Ouverture

Ouvert

Trappe

Arrt P1

-Figure 12.13- Modlisation des entits de l'application. Les entits ne sont pas lies entre elles en l'absence du systme de commande. Celui-ci est dlimit comme lindique la figure 12.14. Les entres bute_D et bute_G ont t ajoutes tout de suite car elles s'avrent ncessaires pour la ralisation de la fonction. Ceci se dduit des spcifications fonctionnelles par les conditions P P2 et P P1. M.C.S.E 229

Partie 3 - SPECIFICATION DUN SYSTEME

Bute_D (P P1) Bute_G (P P2)

CMD : ( MD , MG , AR )

Chariot
cycle

Systme
CT = [ Ouverture | Fermeture ] Marche_tapis: boolen

Oprateur
arrt

spcifier

Tapis_chargeur

-Figure 12.14- Dlimitation du systme. Pour lapplication le systme n'assure qu'une seule fonction, celle de raliser un cycle automatique de dplacement du matriau. Pour caractriser la fonction du systme, il s'agit de dcrire les actions du systme sur son environnement en fonction des vnements ou observations. Pour cela, partons des entits commandables et dcrivons lvolution de chacune delles sous la contrainte du systme.
Mise sous tension P P2 Arrt cycle.P>P2 Arrt Dpl. en P1 P P1 Rotation_tapis Arrt Attente remplissage Plein Arrt Dpl. en P2 P P2 vidage Arrt Attente vidage Fin_vidage Vidage Marche Retour pos. dpart Repos en P2 P P2 cycle Rotation_tapis (Tremplissage T1) + arrt plein

Chariot - Dplacement Tapis_Chargeur


Arrt

Trappe
Ferm (Touverture T2) + arrt fin_vidage

Ouvert

-Figure 12.15- Modlisation globale pour les entits commandables. 230 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Le comportement pour ces 2 ensembles pour la ralisation dun cycle automatique est reprsent par la figure 12.15. Le systme ne peut agir que sur les 2 entits: chariot et tapis_chargeur. La troisime l'utilisateur - n'est pas commandable car celui-ci a toutes possibilits d'appuyer sur les boutonspoussoirs quand il le dsire. Les 2 ensembles coupls modlisables pour l'application sont donc: systme + chariot et systme + tapis_chargeur. Les diagrammes tats finis ci-dessus dcrivent les tats successifs des 2 entits. Les conditions de transition sont celles de l'application. Certaines sont produites par les entits, elles sont alors ncessairement des entres du systme. D'autres conditions sont internes au systme: dure d'un tat et vnements tel que Rotation_tapis, Vidage, Fin_vidage, pour exprimer des relations dordre. A partir dune telle description globale et compte-tenu de la modlisation faite au pralable pour chaque entit sans le systme, il est possible de dduire facilement pour chaque tat, les actions sur les entits et donc les sorties du systme. Ceci conduit dcrire le comportement du systme par une modlisation globale de l'volution de ses sorties en fonction de ses entres. La dcomposition du modle global en 2 parties: modle d'volution du systme, modle d'volution de l'entit est montre figure 12.16 pour 2 tats de lapplication.

[ SYSTEME + CHARIOT ]

[ SYSTEME ]

[ ENTITES ]

Dplacement cmd=MD cycle cycle dpl. droite dpl. en P1 dpl.en P1 marche_tapis; cmd=MD Repos P >= P1 rotation_tapis Bute_D Tapis chargeur arrt attente remplissage attente remplissage marche_tapis; cmd=AR marche_tapis marche_tapis Arrt P1 cmd=AR P P1

plein

( Tremplissage >= T1) + arrt marche

-Figure 12.16- Relation entre modlisation globale et spcification du systme. La spcification fonctionnelle trouver est celle du systme. Pour exprimer les relations entres --> sorties, la spcification s'obtient en enlevant la modlisation systme + entit la part ralise par l'entit. Habituellement cela revient simplement ajouter pour chaque tat les M.C.S.E 231

Partie 3 - SPECIFICATION DUN SYSTEME valeurs des entres de l'entit pour que celle-ci soit dans cet tat, ou ajouter sur franchissement de transition les actions gnratrices des vnements ncessaires comme entre pour lentit. En dfinitive, il s'agit bien toujours d'une description externe puisque les tats de la description sont ceux des entits, et les conditions d'volution dpendent des entres du systme et donc des tats des entits. L'intrt de cette approche est double. D'une part, elle reste comprhensible et donc vrifiable par le demandeur puisque la description est uniquement base sur la connaissance de l'environnement. D'autre part, la spcification est volutive car pour une modification du comportement d'une entit, seule la partie lie cette entit est modifier.
-C- APPROCHE PAR LAPPLICATION

Lorsque les 2 approches prcdentes ne conduisent pas une expression correcte et complte des spcifications fonctionnelles lapproche globale est ncessaire. Ceci correspond au cas d'entits complexes ou lorsque la dcomposition de l'application en entits n'est pas suffisante (voir 11-8). Dans ce cas, la modlisation globale de l'application par un diagramme des activits sert comme base pour faire apparatre le rle et donc les fonctionnalits du systme. Les sous-ensembles que doit assurer le systme sont ensuite spcifis plus rigoureusement en dcrivant les spcifications des donnes et les spcifications des activits. A ce niveau et un certain stade du raffinement, les 2 approches prcdentes sont utilisables. 12.6.3. Mthode pour laborer les spcifications fonctionnelles Les spcifications fonctionnelles comprennent: l'expression des fonctions du systme, puis une spcification de ces fonctions.
-A- LISTE DES FONCTIONS DU SYSTEME

Premire partie essentielle de la spcification fonctionnelle, il s'agit tout d'abord de faire l'inventaire des fonctions que doit offrir le systme pour son environnement. L'analyse peut se faire en recherchant les activits de l'application. Chaque fonction est dcrite par: - un titre, - une description succinte de son rle, - les entits de lenvironnement concernes par cette fonction. Trs important, il ne faut pas confondre fonction interne et fonction externe. L'exprience de la mthode a montr que cette diffrenciation pose quelques difficults et qu'il est naturellement plus facile d'voquer des fonctions internes; par exemple, la fonction dialogue trs souvent voque 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 systme.
-B- SPECIFICATION DES FONCTIONS DU SYSTEME

Le paragraphe prcdent montr que 3 approches sont utilisables pour dcrire compltement les fonctions du systme. Ces 3 approches ne sont pas exclusives, au contraire, chacune correspond llaboration dune vue diffrente du systme. Lobjectif dune 232 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION spcification est de ramener toute la description des relations entres/sorties pour le systme. Lapproche par les entres/sorties est la plus directe lorsquelle est possible, la modlisation des entits est alors rduite la spcification de leurs entres et sorties. Lapproche par les entits est particulirement approprie pour les applications de contrle/ commande en temps rel. L'expression du comportement de chaque entit sous la contrainte du systme est facilite par l'existence d'une modlisation de celle-ci en l'absence du systme. Habituellement le mme type de modle est utilisable pour la spcification. Il a t montr que la description d'une fonction du systme s'obtient indirectement en dcrivant l'ensemble: fonction + entits. La base de la spcification 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 > entits concernes, il est possible dutiliser un schma relationnel qui servira comme base danalyse pour cette phase de spcification. Nous avons constat que lorsque les entits sont relativement simples (c'est--dire son modle), chacune n'est concerne que par une fonction. Ainsi, caractriser les fonctions revient modliser le comportement souhait de toutes les entits. Les dpendances entres sorties pour le systme sen dduisent. Les modles utiliser sont bien entendu les mmes que ceux prconiss pour les entits. Lorsque cette technique de spcification ne s'avre pas satisfaisante, il faut alors avoir recours une modlisation globale de lapplication du type flot de donnes en dlimitant donnes et activits du systme. A partir de cette approche globale, il est possible daffiner la spcification en sous-ensembles, puis de caractriser chaque sous-ensemble selon les approches 1 et 2. La dmarche pour des spcifications par diagramme tats finis ou par diagramme stimulirponse consiste pour chaque entit dbuter par ltat 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 spcification s'obtient ainsi d'une manire incrmentale par ajout d'tats, de liens, des conditions de transitions et des actions. La recherche de la spcification peut se faire entit par entit. Mais lorsque celles-ci sont couples par le systme, il est prfrable de considrer simultanment toutes les entits. Lorsque l'utilisateur est une entit de l'application, il n'est pas possible de le contraindre suivre une procdure car il n'existe pas de moyen d'action directe. En effet, on ne peut pas par exemple empcher un utilisateur de frapper sur n'importe quelle touche lorsqu'il est face un clavier. Par contre, le systme peut filtrer parmi toutes les actions de l'utilisateur, les squences considres comme correctes. La spcification lie l'utilisateur concerne alors l'expression des squences dvnements en provenance de celui-ci considres comme correctes pour l'application. Cette partie de la spcification est alors plutt exprime par un graphe du type stimuli/rponse qui exprime le comportement du systme vis--vis de lutilisateur. Ceci est expliqu sur l'exemple du centrifugeur ci-aprs en 12.6.4.
-C- VERIFICATION DES SPECIFICATIONS

Une vrification doit suivre le travail de spcification pour s'assurer de la validit globale de la spcification. M.C.S.E 233

Partie 3 - SPECIFICATION DUN SYSTEME Une premire vrification consiste sassurer du respect des rgles "syntaxiques" des modles utilises. En effet une mauvaise utilisation des modles conduit obligatoirement des ambiguts dinterprtation de la spcification. Il faut ensuite sintresser laspect "smantique" et donc la signification de tous les lments utiliss: tats, conditions, actions, etc, et la cohrence de lensemble vis--vis de lobjectif. A l'issue de cette phase, dans certains cas il est utile de revenir sur la dlimitation des entres et sorties du systme. En effet, on peut tre amen constater l'existence de conditions ou d'vnements non-observables auprs de l'environnement. Si ces informations ne peuvent pas tre construites dans le systme, des capteurs sont ajouter pour y accder. 12.6.4. Exemples On donne ci-dessous la spcification fonctionnelle pour le systme de contrle en vitesse dun centrifugeur. La seule fonction du systme est de raliser un cycle de centrifugation une consigne de vitesse fixe au pralable par l'utilisateur. Elle est spcifie en explicitant les contraintes imposes au moteur conformment lapproche par les entits, et le comportement du systme vis--vis de lutilisateur par lapproche entres/sorties.
Systme pour lutilisateur Systme + Moteur

Repos dbut cycle T:=0

Repos

Vmoteur = 0 Erotation = arrt

ORDRE autre marche /si Erotation = arrt alors dbut cycle; ORDRE ? arrt /si Erotation = rotation alors arrt cycle; consigne

CV tel que Vmoteur = Vrot * T Erotation = rotation AcclraTm tion T >= TM T:=0 arrt cycle Vm:=Vmoteur; T:=0;

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

dclraCV tel que tion Vmoteur = Vm - Vrot * T TD Vmoteur # 0

Couplage

-Figure 12.17- Spcification fonctionnelle pour le centrifugeur. La spcification ci-dessus s'obtient en considrant comme point de dpart les tats successifs voulus pour le moteur. Ensuite le comportement du systme li l'utilisateur est celui dun filtre de lentre ORDRE. On exprime pour cela le diagramme stimuli/rponse du systme vis vis de l'utilisateur. Ainsi, ce diagramme reprsente le "filtrage" des vnements en provenance de lutilisateur pour ne retenir que ceux corrects pour lapplication. A noter par exemple qu'une demande Marche ne peut tre prise en compte qu'aprs la fin du cycle prcdent, cest dire lorsque Erotation = arrt. 234 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION A nouveau, comme illustration de lapproche par les entits, est indique ci-dessous la spcification fonctionnelle pour l'obtention en automatique d'une toupie de bton partir de la demande utilisateur (voir le problme en 12.3.2). La spcification s'obtient nouveau en considrant toutes les entits de l'application et les contraintes imposes par le systme.
Systme pour lutilisateur Silos A, Balance A et Tapis A
VA1 VA2 VBA VA3 TPA

Silos C, Balance C et Tapis C


VC1 VC2 VBC TPC

Malaxeur

Rservoir

MLX Repos VD Repos

Repos

Repos

Repos

VE

Dsir bton Entre paramtres ok cycle bton

cycle bton

cycle bton

Etat A=VidageA ou Etat C=VidageC Attente synchro

Etat malaxeur= attente synchro

arrt + dfaut

Pesage A1

VA1

Pesage ciment

VC1 ou VC2 selon choix

MLX

Dbit eau VE

Poids >= PA1

Poids >= PC

Etat A=VidageA Etat C=VidageC


et

quantit dsire = QE

Attente bton

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- Spcifications fonctionnelles pour la production de bton. 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 dmarche conventionnelle qui conduit dcrire directement le comportement du systme ce qui est plus compliqu, et le risque d'erreurs est plus important. La dmarche prconise ici est un stade intermdiaire qui permet de dduire 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 spcification globale. 12.7. SPECIFICATIONS OPERATOIRES Le terme OPERATOIRE est prendre dans le sens: la manire dont une fonction doit oprer et les conditions et domaines de fonctionnement. Les spcifications opratoires comprennent donc: - d'une part toutes les prcisions sur les grandeurs ou donnes qui sont apparues dans les spcifications fonctionnelles (type, domaine de dfinition). Toutes les grandeurs connues doivent tre indiques. On doit aussi y trouver les conditions de M.C.S.E 235

Partie 3 - SPECIFICATION DUN SYSTEME fonctionnement, les performances en prcision et tous les modes particuliers de fonctionnement. Par exemple, il n'est pas identique d'obtenir un rsultat 10 -2 ou un rsultat 10 -5. - d'autre part toutes les informations susceptibles de guider les concepteurs dans le choix de solutions mettre en oeuvre. Les spcifications opratoires peuvent inclure la manire de raliser certaines oprations (mthode de calcul par exemple). Ces spcifications sont gnralement favorables. En effet, le demandeur peut avoir des avis sur les solutions adopter pour la ralisation de fonctions nonces dans les spcifications fonctionnelles. En tant que demandeur, celui-ci matrise son domaine, aussi a-t-il pu par exemple lors de ralisations prcdentes ou l'occasion d'une tude de faisabilit, exprimenter des mthodes et tirer des conclusions. Il est donc opportun de disposer de ses rsultats pour augmenter les chances de russite. Ces spcifications s'obtiennent par un travail d'analyse des spcifications dj labores, de consultation de documents, de discussions avec le demandeur. Selon la nature des renseignements, elles s'expriment de diverses manires: langage naturel, modle mathmatique, algorithme... La spcification des performances d'un systme dpend de la nature du problme. Par exemple pour un systme de vision pour la dtection de dfauts, il n'est pas simple de caractriser les performances attendues. Une technique consiste alors spcifier la procdure de test en dfinissant des objets caractristiques qui permettront de valider le produit. Il peut s'agir par exemple pour une dtection de dfauts, de la dfinition de bonnes et mauvaises pices que le systme devra discriminer pour tre accept. 12.8. SPECIFICATIONS TECHNOLOGIQUES Cette catgorie est vaste puisqu'elle inclut toutes les spcifications qui ont un rapport avec la ralisation matrielle et l'implantation logicielle. Ces spcifications sont toutefois plus classiques et ainsi plus faciles laborer. Dans la suite, on cite pour mmoire les spcifications essentielles auxquelles il faut penser.
-A- CONTRAINTES DE REPARTITION

Lorsque l'application est rpartie gographiquement (distance entre sous-ensembles > 10 m par exemple), ces contraintes dcrivent la topologie de la ralisation, les distances, les moyens de couplage et les contraintes d'utilisation de ces moyens.
-B- SPECIFICATIONS ELECTRIQUES DES INTERFACES PHYSIQUES

Elles concernent la caractrisation des signaux et des informations d'entre et de sortie du systme, ceci en dcrivant les caractristiques lectriques des entres et sorties des entits.
-C- SPECIFICATIONS DES INTERFACES DE DIALOGUE

La plupart des systmes sont accessibles par des oprateurs directement ou via un organe de communication. Cette catgorie de spcification dcrit: - d'une part les lments technologiques utiliser pour ces interfaces homme-machine, - d'autre part la procdure d'utilisation. Ceci revient spcifier le dialogue hommemachine particularis pour l'organe technologique retenu: menu pour un terminal, systme d'icones pour un microordinateur, boutons et afficheurs pour un panneau spcifique... 236 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION Ce type de spcification 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 spcifications. La vrification par le client est alors grandement simplifie.
-D- SPECIFICATIONS TEMPORELLES (CONTRAINTES DE TEMPS)

Pour l'instant, il n'a pas t fait tat des temps de raction du systme aux sollicitations externes. On ne peut pas parler de systmes temps-rel sans considrer ce type de contraintes car l'environnement est un monde rel qui gnre des vnements et modifie des informations sa propre vitesse. Toute fonction en interaction avec cet environnement doit a priori ragir la mme chelle de vitesse. Comme toute ralisation fera intervenir un temps d'excution ou retard, le concepteur doit dterminer avec le client les dlais de raction acceptables pour les diffrentes parties du systme. Ces dcisions servent de contraintes pour la ralisation. Les spcifications temporelles concernent uniquement l'environnement; le systme doit ragir globalement aux stimuli d'entre en agissant sur ses sorties et ceci en un temps maximum. Les contraintes de temps pour le systme sont de plusieurs natures: - la frquence de rptition qui indique pour des vnements en entre la frquence de sollicitation du systme (frquence maximale, car la plus contraignante), pour des sorties la frquence d'action sur l'environnement (frquence minimale pour le bon comportement de l'entit concerne). - le temps de rponse caractrisant le temps maximum de modification de sorties partir d'un vnement ou dune condition en entre. Une modlisation du type stimuli/rponse favorise l'expression de telles contraintes. - des contraintes multiples qui expriment des relations temporelles entre plusieurs signaux (temps minimum, temps maximum). Des chronogrammes sont appropris pour dcrire ces spcifications. De telles spcifications se dcrivent 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 caractriser les fonctions souhaites pour la maintenance ou l'aide au diagnostic: auto-test la mise sous tension, test priodique en cours de fonctionnement, procdure de maintenance rsidente, tl-maintenance... Pour la sret de fonctionnement, l'objectif est de caractriser divers aspects qui auront des influences sur la ralisation: - fiabilit du systme, - disponibilit en cas de panne, - tolrances aux pannes matrielles, logicielles... - scurit de l'environnement et des utilisateurs, - fonctionnement en mode dgrad, en mode manuel... Il ne s'agit pas l de spcifications fonctionnelles car elles dpendent 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 DUN SYSTEME

Nom vnement
PAS

Type
Interne: priode de rgulation entre: priode de rception de caractres entre: surchauffe T < 5 ms

Contraintes

REU

Transmission 9600 bds > T<=1 ms

ALARME

exceptionnel

F_VANNE

sortie: fermeture vanne

Temps de rponse < 1 ms partir de ALARME

Signaux Tmin = 10 ms

entre
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 prcisent les caractristiques lectriques auxquelles doit satisfaire la ralisation telles que: consommation, dissipation, connectique, alimentation, types de composants...
-G- SPECIFICATIONS DIVERSES

Dans cette catgorie entrent des contraintes telles que: - contraintes lies au contexte dans lequel sera fabriqu le produit (utilisation de certains composants, modles de cartes, encombrement, cot, outils de dveloppement...). Ces contraintes sont prendre en compte lors de la phase de recherche de la solution technologique. - des conditions lies l'environnement (coupures secteur, milieu fortement parasit, milieu marin...). Elles peuvent obliger introduire des redondances et des protections particulires. - des conditions en rapport avec la phase d'utilisation ou la dure de vie lorsqu'il s'agit d'une ralisation qu'il faudra maintenir longtemps ou qui devra voluer. Les possibilits potentielles d'volution doivent tre exprimes. Comme illustration, on donne ci-aprs les spcifications pour le systme de contrle en vitesse du centrifugeur. Pour les spcifications opratoires, les temps a priori constants apparaissant dans la spcification 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 dclration restera toujours constante. La vitesse peut voluer entre 0 et 3000 trs/mn. La prcision sur la vitesse doit tre meilleure que 10 tours/mn sur toute l'chelle. Concernant les spcifications technologiques, la visualisation de la consigne de vitesse se fera sur 4 afficheurs BCD. La commande du moteur est du type PWM la frquence de 1 KHz et avec une sortie isole lectriquement. L'observation de la vitesse ncessite l'utilisation d'un codeur incrmental 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 possdant une inertie variable, en particulier faible vide, la commande du moteur doit tre calcule au maximum toutes les 5 ms. 12.9. PROCEDURES DINSTALLATION ET DEXPLOITATION La description du comportement du systme fournit une vue suffisante pour que le lecteur et donc le demandeur puisse dterminer si le systme satisfait ou non son besoin. Il dcrit ce que le systme est capable de faire. Par contre, la description ne permet pas un utilisateur potentiel ou l'organisation qui va exploiter le systme de dduire facilement s'il va rpondre tous les objectifs: utilisation, insertion dans l'organisation de la socit, installation, maintenance... Des informations complmentaires sous la forme de documents sont donc ncessaires, savoir: - une documentation prliminaire d'utilisation. Ce document dcrit le systme tel que vu par les utilisateurs. Il peut tre structur en parties lorsque plusieurs catgories d'exploitants sont concernes par le systme (interface spcifique pour chaque catgorie par exemple). Ce document prfigure le manuel final d'utilisation. - une documentation dinstallation. Il s'agit d'une description explicitant la manire d'exploiter et d'administrer le systme. Au pralable, pour l'installation il peut aussi tre ncessaire d'assurer dans l'organisation du client un transitoire pour tirer rapidement profit du systme, par exemple, passage d'une procdure manuelle une procdure automatique. Ce document doit donc dcrire comment devra fonctionner l'organisation ce qui permet de faire voluer l'environnement du systme. Ces documents se rdigent progressivement partir de l'ensemble des spcifications prcdentes. Rdigs en fin de spcification, ils permettent au client d'avoir une information complte sur le produit qui sera livr. Les utilisateurs peuvent alors prendre les dispositions ncessaires pour faciliter l'installation, la mise en fonctionnement et l'exploitation du systme. 12.10. EXEMPLE 2: AUTOMATISATION PAR CHARIOT FILOGUIDE Afin d'illustrer la dmarche de spcification et le document rsultant, on dcrit ci-aprs l'analyse pour l'exemple d'une automatisation par chariot filoguid, le cahier des charges ayant t dcrit en 9.8.2. M.C.S.E 239

Partie 3 - SPECIFICATION DUN SYSTEME 12.10.1. Modlisation de l'environnement Une analyse succinte du problme conduit considrer les entits suivantes: - les quais en tant que donneurs d'ordre; les 2 ont un comportement identique. - l'atelier en tant que topologie comme support de dplacement: position des quais, trajectoire, obstacles... - le vhicule pour la partie mcanique assurant le dplacement et le chargement/ dchargement. - l'exploitant charg de la bonne marche de l'installation. Celui-ci n'est concern que par la sirne. Dans ce cas, constatant un incident, il repositionne le chariot et rinitialise son systme de commande. Les paquets transports ne sont pas utiles pour la rsolution du problme puisqu'il n'y a pas de dtection de prsence. Le radar, les capteurs C1 et C2, l'metteur-rcepteur infra-rouge et les codeurs incrmentaux ne sont que des interfaces.
-A- COMPORTEMENT DUN QUAI

Pour son environnement, chaque quai assure 2 fonctionnalits: - dialogue avec l'environnement par liaison infra-rouge: mission d'ordre (ORDRE) et rception de messages (MESSAGE), - rotation de son tapis dans les 2 sens pour le dplacement d'un paquet. Le tapis est caractris par 3 tats qui sont dfinis partir de la commande R_tapis: (AR, TG, TD). La modlisation du quai est donc la suivante:
Dialogue Tapis

Repos

Rotation droite

R_tapis=AR Message Dsir transmettre ordre ORDRE

R_tapis=TD

Repos Interprtation R_tapis=TG R_tapis=AR

Rotation fin gauche

-Figure 12.20- Modlisation d'un quai.


-B- COMPORTEMENT DU VEHICULE

Le vhicule est compos de 2 sous-ensembles fonctionnels: - la partie dplacement 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 rsume les caractristiques des variables du vhicule.
Variable interne Sortie Dfinition
Commande des moteurs 0 .. CVMAX

Sous-ensemble

Entres
CVM1, CVM2

Partie Dplacement
P VM1, VM2

Position du chariot en deux dimensions Vitesse de chaque roue 0 .. Vmax Commande du tapis : Avant , Arrire, arrt

C_TAPIS

Tapis
ETAT_TAPIS

Etat du tapis : arrt, chargement, dchargement.

-Figure 12.21- Analyse pour le vhicule. A partir de cette analyse se dduit la modlisation. Un automate 3 tats (vident, non reprsent) caractrise le tapis. Pour la partie dplacement, 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'avre pas utile pour la rsolution du problme.
-C- MODELISATION DE LATELIER

Pour le chariot, l'atelier dfinit la trajectoire suivre ainsi que la position des obstacles tout instant. Les informations utiles pour le systme concernant le chariot sont: - OBSTACLE: information boolenne, - DCA: distance du chariot sa trajectoire de consigne. 12.10.2. Spcifications du systme
-A- DELIMITATION DES ENTREES/SORTIES

Le systme spcifier li aux entits de son environnement est reprsent figure 12.22. Il est assez vident ce stade que des observations manquent pour satisfaire lobjectif puisque le systme agit en boucle ouverte sur le chariot. Elles seront dduites de la spcification fonctionnelle.
-B- SPECIFICATION FONCTIONNELLE

On s'intresse ici uniquement au chariot. Son systme de commande doit assurer une seule fonction qui est celle d'effectuer en automatique le cycle de transfert pour chaque paquet. Interviennent dans la spcification les 2 quais chacun ayant un rle diffrent et le chariot. L'initiative d'un cycle de transfert provient du quai 1. Le rle du systme est explicit par les diagrammes tats finis ci-aprs qui montrent bien que la dduction se fait partir des entits. Le sous-ensemble tapis tant trs simple, la spcification dcrite figure 12.23 considre globalement le chariot comme une seule entit. M.C.S.E 241

Partie 3 - SPECIFICATION DUN SYSTEME

Quai

Ordre

message

Son_Sirne

Exploitant

obstacle

Atelier

DCA

Systme spcifier
c_tapis CVM1 CVM2

Tapis + Dplacement
Chariot

-Figure 12.22- Le systme et les liens avec son environnement.

QUAI 1
intervention oprateur sirne sirne Dfaut Repos Dfaut

CHARIOT
intervention exploitant Repos VC = 0 c_tapis = arrt ok_prsence Attente ordre transport

QUAI 2

I_prsence Dsir transport paquet I_prsence

c_tapis = avant

Repos Priode interrogation


TI

charg.

Charge I_prsence

TC Attente rponse Transport c_tapis = arrt quai 2 ok_prsence

TI

Attente rponse Dfaut chargement

dchargement rotation tapis TC

arrive quai 2 ok_prsence Attente VC = 0 dtection Attente fin transport

Attente fin

rotation tapis

TI I_prsence

ok_prsence dchargement Attente dcharge Dcharge c_tapis = arrire

TC

transport

C_tapis=arrt

TC

dfaut Transport quai 1

transport c_tapis = arrt

arrive quai 1

-Figure 12.23- Spcification fonctionnelle pour la commande du chariot. Les ordres en provenance des quais sont donc I_Prsence pour linterrogation, chargement dun paquet, transport au quai suivant, dchargement dun paquet. Le seul message en provenance du chariot est ok_prsence pour rpondre linterrogation de prsence. Le temps 242 M.C.S.E

Ch 12 - DEMARCHE POUR LA SPECIFICATION TC est la dure de chargement ou de dchargement. TI est un temps maximum dattente dune rponse. La vitesse du chariot VC est celle impose sur la trajectoire dfinie par le fil de guidage. L'tape de dplacement 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 dmarrage, de vitesse constante, d'arrt. D'une dure de 1 s par variation linaire de la vitesse, 5 Km/H, le dmarrage et larrt se font sur 0,7 m.
VC = VCmax * t T >= 1 sec Acclration Vitesse constante VC = VCmax Proximit Dclration VC = VCmax * ( 1 - t ) Arrive quai

Dfaut VC = 0

Dfaut VC = 0

Dfaut VC = 0

avec Dfaut = obstacle + ( DCA > max )

-Figure 12.24- Spcification de l'tape de dplacement. L'arrt sur dtection d'obstacle se fait en annulant la commande des moteurs, ce qui conduit un arrt par inertie. L'analyse des conditions de transition sur cette spcification fait apparatre la ncessit d'observations. - prsence_quai, pour l'arrt, - proximit_quai, pour la phase de dclration, - arrive_quai. Un dialogue avec le client va permettre de dfinir le ou les capteurs ncessaires pour la connaissance de ces variables. De plus, pour que le chariot se dplace selon la consigne VC, une observation de la vitesse de chaque roue est strictement ncessaire.
-C- SPECIFICATIONS OPERATOIRES ET TECHNOLOGIQUES

N'tant qu'un exemple de prsentation de la dmarche, nous ne dtaillerons pas ici ces spcifications technologiques qui sont pour l'essentiel donnes dans le cahier des charges (voir 9.8.2). Il s'agit d'un problme sans rpartition gographique. S'il s'agissait de traiter globalement la commande de l'atelier: quais + chariot, nous aurions faire un systme rparti gographiquement en 3 sites, avec la liaison infra-rouge comme support de communication. Il ne possde pas non plus d'interface utilisateur, mais il s'agit d'un problme temps-rel car la commande des moteurs doit ragir 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 DUN SYSTEME 12.11. VERIFICATION, VALIDATION DES SPECIFICATIONS L'objectif de l'tape de spcification est d'obtenir un document cohrent, vrifi et accept par le client. Cette validit s'obtient par un cycle auteurs-lecteurs. L'intervention des diffrents partenaires ncessite une planification des tches. 12.11.1. Les participants Pour la vrification, le ou les auteurs des spcifications dfinissent avec le responsable du projet et ds le dbut de l'tape, les lecteurs qui conduiront, par des revues de la spcification, l'obtention d'un document de qualit. Les lecteurs doivent reprsenter les catgories concernes par le rsultat savoir: le client, comme donneur d'ordre, les utilisateurs du produit ou systme, les installateurs, hommes d'exploitation et de maintenance, les concepteurs du produit, si ncessaire un spcialiste en spcification.

Cette procdure s'avre efficace car de cette manire, ct 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 ultrieure pourra raisonnablement tre considre comme un avenant au contrat. Ct concepteurs, avant de dbuter le travail, l'quipe prend connaissance dune manire progressive des objectifs atteindre, de l'environnement, des spcifications compltes. Une valuation de la faisabilit peut alors se faire trs rapidement. Un spcialiste en spcification peut aussi raliser une analyse critique des spcifications et de la dmarche suivie. Ceci conduit une amlioration de la qualit du document, une simplification des modlisations et des spcifications, ce qui peut se traduire pour la suite par une rduction de complexit du dveloppement. 12.11.2. Planification du travail et des revues Pour des raisons d'efficacit, au moins trois stades de lecture sont ncessaires: - aprs la modlisation de l'environnement. Cette premire lecture permet de corriger les erreurs d'interprtation du spcifieur, - aprs les spcifications fonctionnelles. Ce stade est essentiel et justifi pour une bonne vrification, - la fin des spcifications, pour corriger et liminer toutes les erreurs et omissions. Avant de dcrire la planification souhaitable, notons que par exprience il a t constat que la dure d'une spcification est nettement plus longue que la somme des temps consacrs ce travail. Approximativement, il faut compter un rapport de l'ordre de 3 entre la dure et le temps consacr. Pour le cycle auteur-lecteurs, chaque lecteur doit lire et annoter tout document qu'il reoit. En retour, chaque auteur effectue la synthse 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
Spcifications fonctionnelles

corrections

2
fin des spcifications

corrections

3 t Lecture 1 Lecture 2 Lecture 3

-Figure 12.25- Planification des phases et des revues. Cette procdure ne donne de bons rsultats que si les lecteurs se sentent responsables de la qualit du rsultat. C'est aussi une manire de former des spcifieurs et de responsabiliser les intervenants ct client. Cette approche des spcifications se veut tre du type participatif. 12.12. CARACTERISTIQUES DE LA SPECIFICATION Pour faire le bilan de ce chapitre, faisons le point sur lintrt d'une spcification en tant que modle et sur la dmarche prsente. Les caractristiques essentielles du modle prconis pour la spcification sont les suivantes: - il s'agit d'un modle conceptuel qui dcrit ce que doit tre le systme et non un modle physique qui dcrirait la ralisation. Les modles sont abstraits, ce qui permet, par une expression simplifie du comportement, d'liminer les dtails. Dapparence complexe pour ceux qui abordent pour la premire fois une mthode de spcification, rapidement le spcifieur est amen constater son efficacit comme aide l'analyse de tous les aspects d'un systme puis son intrt pour les phases ultrieures de conception et de ralisation. - la spcification est structure. Cette qualit favorise une approche progressive des spcifications et des besoins du client jusqu'aux caractristiques compltes du systme. C'est cette structuration qui facilite la lecture du document par le demandeur et les utilisateurs, ce qui est indispensable pour la vrification. La classification des spcifications en catgories conduit aussi une efficacit de la part des concepteurs pour la recherche progressive de la solution en ne considrant que les informations ncessaires pour chaque phase. - la spcification est complte car elle considre tous les aspects du systme. Ainsi, le lecteur peut se faire une ide prcise et juste du rsultat qui en dcoulera en tant que produit ou systme. Etant complte, elle sert avantageusement d'intermdiaire entre le client et le produit final. Avant d'entamer la conception, la spcification se trouve ainsi vrifiable. De mme, lorsque le produit est ralis, une vrification exhaustive de l'adquation du systme aux spcifications est possible. M.C.S.E 245

Partie 3 - SPECIFICATION DUN SYSTEME - la spcification est interprtable. Il ne ncessite qu'une faible connaissance pour la comprhension des diffrentes parties de la spcification. Une partie des modles sont graphiques, ce qui permet d'exploiter notre aptitude analyser plus efficacement des informations. Sans tomber dans un formalisme extrme qui compliquerait la lisibilit pour le non-spcialiste, les modles restent prcis tout en tant explicites. Ainsi, le document de spcification bas sur ce modle est particulirement favorable pour les lecteurs. - la spcification est vrifiable. La structure du modle et les dpendances entre les constituants introduisent des rgles implicites de vrification de la cohrence d'une spcification. Ensuite, la lisibilit du document par plusieurs lecteurs - client, utilisateurs, concepteurs - conduit liminer une grande partie des erreurs ou omissions. De plus, la modlisation des entits sans le systme, puis sous la contrainte du systme, peut se vrifier assez simplement par simulation. De mme, le prototypage pour les interfaces homme-machine est une technique qui favorise la validation des spcifications. 12.13. RESUME La mthode de spcification dcoule directement du modle de description prconise. Rappelons les points essentiels: - llaboration des spcifications est dcompose en 2 grandes phases: la modlisation de l'environnement, la spcification du systme. - l'environnement est caractris sur la base d'une analyse du comportement des entits de l'application. Les entres de ces entits sont des sorties pour le systme et les sorties des entits sont disponibles comme entres. Si ncessaire, cette modlisation peut servir comme base de simulation, en particulier pour le test du bon comportement du systme avant son exprimentation sur site. - le systme est lui-mme considr comme une entit complmentaire rapporte pour effectuer un couplage fonctionnel. Contrairement aux entits, qui elles, compte-tenu de leur existence peuvent se modliser sur la base de la ralit, la spcification du systme ne peut et ne doit pas tre base sur la description des fonctions internes du systme. - le systme est spcifi par une description externe la plus complte possible. Vu de l'extrieur, il assure des fonctions pour l'environnement. Ces fonctions sont caractrises en explicitant leurs influences sur l'volution des entits. La spcification du systme repose donc trs nettement sur la modlisation de l'environnement. - la spcification complte du systme est classe en 3 catgories de renseignements fonctionnel, opratoire, technologique - de manire favoriser son utilisation pour chacune des phases ultrieures du dveloppement. - la mthode conduit laborer progressivement un document complet de spcification. Analyse par des lecteurs, la spcification est ainsi vrifie 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] Mthodes de dveloppement dun systme microprocesseurs A. AMGHAR MASSON collection manuels informatiques, 1989 [BAILLY-87] Les langages orients objets: concepts, langages et applications C. BAILLY, J.F. CHALLINE, P.Y. GLOESS, H.C. FERRI, B. MARCHESIN CEPADUES - Editions, 1987 [CALVEZ-87] Mthodes et Techniques pour l'Electronique numrique 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

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 indpendante des contraintes et solutions technologiques, de manire reprsenter le "noyau dur invariant" pour l'application. Exploitant les spcifications fonctionnelles, le concepteur dbute par la recherche d'une solution interne, ce qui correspond au travail de conception prliminaire ou architecturale. La solution retenue doit tre conforme un modle appel modle Fonctionnel pour que celle-ci puisse tre utilise comme spcification pour l'tape suivante. Ce modle correspond 2 dimensions du modle 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 modle fonctionnel. Dans cette partie, le chapitre 13 prsente tout d'abord le modle fonctionnel. Les grands principes de conception que tout concepteur doit essayer de respecter pour aboutir des solutions de qualit sont ensuite indiqus dans le chapitre 14. Le chapitre 15 dveloppe la mthode suivre, illustre par des exemples. Comme aide aux concepteurs, le chapitre 16 montre l'apport des modles gnriques de solutions pour l'obtention de solutions gnrales de qualit.

M.C.S.E

251

Chapitre 13

LE MODELE FONCTIONNEL

Une description succinte du modle fonctionnel et plus particulirement du modle de structure fonctionnelle, a t faite au pralable dans la partie 1: Prsentation de la Mthodologie (chapitre 5). Le modle fonctionnel exprime un ensemble de rgles que doit respecter toute solution dveloppe par un concepteur pour tre en accord avec la mthodologie. Le respect de ces rgles pour une solution lui confre les proprits du modle. La solution est alors exploitable comme spcification pour l'tape suivante qui concerne la dfinition de la ralisation. De manire pouvoir se consacrer dans un premier temps l'essentiel pour l'application sans se proccuper des contraintes de nature technologique, le modle fonctionnel concerne: - la topologie des constituants fonctionnels, - le comportement de ces constituants. Ce chapitre dcrit compltement ce modle, en explicitant les rgles de description et de comportement, puis prsente ses proprits. Il dtaille les 3 parties: le modle de structure fonctionnelle, le modle de comportement des fonctions, le modle de description des donnes.

M.C.S.E

253

Partie 4 - CONCEPTION FONCTIONNELLE 13.1. LES CONSTITUANTS DU MODELE FONCTIONNEL Rappelons tout d'abord que la mthodologie est base sur un modle 3 composantes. Les 2 premires composantes - structure fonctionnelle et comportement des fonctions - constituent le modle fonctionnel (voir chapitre 5) Proposons tout d'abord une dfinition: - un MODELE FONCTIONNEL est une reprsentation par une structure d'lments de tout ou partie d'un systme. Il exprime la smantique de ses lments et des relations, et le comportement du systme vis vis du sujet de l'application qui l'intgre. Le modle fonctionnel dcrit dans [CALVEZ-82] est la composition de 3 ensembles d'informations: - la structure fonctionnelle, premire dimension du modle global de description, - l'expression du comportement des fonctions lmentaires, deuxime dimension, - la structuration des donnes incluse dans la premire dimension. Structure fonctionnelle et structuration des donnes dcrivent la dimension spatiale, tandis que l'expression du comportement des fonctions dcrit la dimension comportementale, trs souvent par une description temporelle mais pas exclusivement. La dimension spatiale utilise explicitement un modle hirarchique, ce qui permet les oprations de raffinement et d'abstraction. Une approche hirarchique descendante est aussi utilisable pour l'expression du comportement; on se base alors sur l'apport de la programmation structure. Ainsi la composition du modle fonctionnel peut se reprsenter comme ci-aprs:
Donnes
Entres / Sorties

Structure
Dlimitation du systme concevoir
niveau 0

Fonctions

Spcification

Spcification fonctionnelle

Premire structure fonctionnelle

Di

niveau 1

Fi

Solution

(pas obligatoire)

Structure dtaille Fonctions lmentaires (obligatoires)

Dk

niveau n

Fk

-Figure 13.1- Dcomposition hirarchique du modle fonctionnel. 254 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL La partie organisationnelle (ou structure) est un arbre car une fonction non lmentaire est dcrite par une structure de niveau infrieur. La partie Donnes est une collection d'arbres ou dlments terminaux. La partie Fonctions est une collection. Pour chaque niveau, on trouve les spcifications des donnes et des fonctions intervenant dans les structures du mme niveau. Bien entendu, il n'y a pas de fonctions pour le niveau 0 en l'absence de tout raffinement. La spcification fonctionnelle caractrise ce niveau. Cette prsentation hirarchique suggre dj assez naturellement le guide de travail pour la recherche d'une solution. Dans la suite du chapitre, on dtaillera les caractristiques des 3 parties du modle fonctionnel: structure fonctionnelle, fonctions lmentaires, donnes. 13.2. LE MODELE DE STRUCTURE FONCTIONNELLE Une structure FONCTIONNELLE est l'expression topologique par un rseau d'lments d'une ralisation pour une fonction. (On utilisera parfois dans la suite S.F. pour Structure Fonctionnelle). Une FONCTION dans sa signification usuelle dsigne l'entit conceptuelle qui assure une activit spcifique. Ainsi, comme toute fonction peut se dcrire par une structure incluant des fonctions plus lmentaires, une S.F. est un outil de raffinement. Dans la suite du paragraphe, on prsente tout d'abord les conventions de reprsentation (vue statique), puis l'interprtation des symboles pour une comprhension non ambigu de toute S.F. (vue dynamique). 13.2.1. Reprsentation graphique Toute fonction dcrire par un raffinement fonctionnel possde des entres et/ou des sorties. Une structure fonctionnelle se construit partir de 4 types d'lments, savoir: - des fonctions (F), chacune reprsente par un rectangle, - des variables d'tat (VE), reprsentes par le symbole: - des vnements (EV), reprsents par: - des ports (PT), reprsents par:

Il faut y ajouter des liens entre ces lments pour dfinir des relations. Les relations ne sont possibles qu'entre des fonctions et obligatoirement par l'intermdiaire d'un lment du type: variable d'tat, vnement, port. L'lment intermdiaire entre 2 fonctions est strictement ncessaire car les 2 fonctions peuvent tre asynchrones. 3 types de relations sont autorises: - la relation de synchronisation par un vnement, - 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 dcrivant la solution pour la commande dun 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

Contrleur i
Commande de Robot

-Figure 13.2- Exemple de S.F. Un contrleur est associ chaque axe du robot. Il y a donc autant dinstances du type contrleur que daxes. La fonction de coordination transmet chacun les ordres. Une fois chaque ordre ralis, chaque contrleur transmet un compte-rendu. Les variables d'tat et les messages peuvent tre de type quelconque: voir en 13.4 la spcification des donnes. Les instances multiples sont aussi reprsentables pour une bonne lisibilit. Tous les liens sont unidirectionnels, sauf si ncessaire pour l'accs une variable en consultation et mise jour. Pour une fonction dcrite par une structure fonctionnelle, des liens partent de ses entres (U) et aboutissent ses sorties (S). Toute fonction interne une structure fonctionnelle possde aussi des entres et/ou des sorties. Les liens des relations aboutissent aux entres et partent des sorties de ces fonctions internes. Chaque entre ou sortie de fonction possde une nature: vnement, variable, message. Une relation n'est correcte que s'il y a compatibilit de tous ses constituants: types de l'lment de la relation, des liens partant et aboutissant l'lment, des entres et sorties concernes. Formellement on peut dire qu'une fonction Fi, dcrite par une structure fonctionnelle SFi, est dfinie par un triplet: Fi = (U, S, SFi) 13.2.2. Cohrence et lisibilit d'une S.F. Exprimons quelques rgles de bon sens pour la reprsentation de toute structure fonctionnelle.
-A- COMMANDABILITE ET OBSERVABILITE

Une fonction est dite commandable si chacune de ses entres se trouve lie extrieurement une autre fonction. 256 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL Une fonction est dite observable si toutes ses sorties sont lies extrieurement une autre fonction. La reprsentation graphique est cohrente si toutes les entres et sorties de chaque fonction dcrite par une S.F. sont utilises. Ensuite, toutes les fonctions de la S.F. doivent tre commandables et observables, et tous les lments EV, VE, PT participent une relation complte.
-B- SPECIFICATION DE TOUS LES ELEMENTS

La structure fonctionnelle ne doit pas tre ambigu. Pour cela, tous les lments ainsi que les entres et sorties doivent tre nomms. Le choix judicieux par un nom concis est trs important pour l'interprtation, avec une rfrence minimale un texte d'explication. Voici quelques rgles suivre pour la slection des noms: - Les variables d'tat sont des informations ou plus gnralement des objets utiliss par les fonctions. Ces lments doivent donc n'avoir que des noms d'objets. Exemples: VITESSE, CATALOGUE AUTEURS. - les fonctions transforment ou exploitent les lments objets. L'appellation doit donc rsulter d'un verbe suivi d'un nom. Exemple: CONTROLE VITESSE, CONSULTATION AUTEURS. - Le nom d'un vnement doit tre celui d'un changement d'tat. Exemple: ARRET, TEMPS ECOULE. - le nom pour les messages et donc celui des ports qui les reoivent, doit exprimer l'apparition de donnes ou de commandes. Exemples: ORDRE, LIVRE RECU. En dehors de ces rgles, il faut simplement s'efforcer de choisir les mots les plus appropris car fort probablement les appellations retenues suivront le projet pendant toute sa dure de vie, ce qui peut en cas de mauvais choix, engendrer une complexit d'interprtation supplmentaire et inutile. Pour les entres et sorties, le nom peut tre diffrent de celui de l'lment li. Pour un nom identique, ce nom est omis ce qui allge la prsentation.
-C- PRESENTATION

Pour des raisons de clart, une structure fonctionnelle doit avoir une qualit de prsentation. Tout d'abord le nombre de fonctions pour un niveau est obligatoirement limit (5 7), au maximum. Ensuite, une rgle de prsentation simple consiste considrer toutes les entres 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 dduire une topologie des plus lisibles. Une relation fonctionnelle est reprsente horizontalement. Une relation hirarchique est plutt reprsente verticalement. La figure suivante illustre ces rgles de prsentation. M.C.S.E 257

Partie 4 - CONCEPTION FONCTIONNELLE

Reu RxD Reception car. VOrdre M/A Etat Supervision

Dpt 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

Contrle / commande

-Figure 13.3- Exemple de prsentation. 13.2.3. Interprtation d'une S.F. L'interprtation exprime les rgles de comportement sous-jacentes la reprsentation graphique, ceci de manire fixer d'une manire non ambigu les spcifications de tous les constituants et le comportement pour les interactions. Ces rgles permettent d'associer la vue statique d'une structure fonctionnelle, une comprhension de son aspect dynamique. La comprhension du comportement d'une structure fonctionnelle sera ainsi possible chaque niveau de description, sans devoir connatre le comportement dtaill et complet de chaque fonction ainsi que la nature des donnes.
-A- REGLES POUR LES EVENEMENTS

Tout vnement (EV) produit par une fonction sensibilise simultanment toutes les fonctions lies.
-B- REGLES POUR LES VARIABLES DETAT

Les variables d'tat (VE) servent assurer des changes d'informations entre des fonctions qui peuvent tre totalement asynchrones. Aussi, toute variable peut tre modifie ou consulte tout instant et mme simultanment par plusieurs fonctions. Les CONTRAINTES D'INTEGRITE devront tre respectes par la ralisation, savoir que 2 assignations simultanes (d1 et d2) doivent donner comme rsultat 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 dpt temporaire de messages dans le cas d'un transfert entre 2 fonctions asynchrones. Elles sont habituellement appeles PRODUCTEUR et CONSOMMATEUR. Les instants de dpt 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 mmorisation de tous les messages produits et non encore "consomms". La File est suppose de capacit infinie. L'ordre dans la file est du type: premier entr, premier sorti. Par suite de l'effet de mmorisation, le temps de transfert d'un message par ce mcanisme est tout fait quelconque. La figure ci-aprs rsume le comportement pour la relation par transfert de messages.
Producteurs Dpt Port M1 Retrait M2 M3 M4

Attente

Consommateurs

-Figure 13.4- Spcification pour le transfert par port.


-D- REGLES POUR LES FONCTIONS

Une fonction est un oprateur de transformation des informations d'entre pour produire en sortie des informations. Toute fonction est cyclique, c'est--dire qui ralise les mmes transformations mais sur des donnes conscutives. 2 cas de comportement sont considrer suivant la nature des entres: - Fonction PERMANENTE: il s'agit d'une fonction ne possdant aucune entre du type vnement ou message. Ainsi, en l'absence de relation de synchronisation avec son environnement, la fonction joue en permanence son rle de transformation. - Fonction TEMPORAIRE: une ou des entres sont du type vnement ou message. Les transformations sont alors obligatoirement synchrones aux vnements ou messages reus. Durant l'activit d'une fonction, toutes les variables lies par les entres et sorties sont consultables et modifiables. De mme, des vnements et messages peuvent tre produits par les sorties. Ces rgles de comportement sont illustres par la figure 13.5 qui montre bien la diffrence entre une fonction permanente et une fonction temporaire. M.C.S.E 259

Partie 4 - CONCEPTION FONCTIONNELLE

U Fonction permanente

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 lmentaires de transformation ou de synchronisation, le comportement peut s'assimiler : - celui d'une machine squentielle, synchrone aux vnements ou messages d'entre, pour une fonction temporaire, - celui d'un gnrateur pour une fonction permanente. Concernant les temps de transformation, sans spcifications particulires, ils sont considrer comme nuls. Avec cette rgle pour les fonctions temporaires, les gnrations en sortie sont synchrones aux vnements d'entre. Pour les fonctions permanentes, ces gnrations sont spcifies par des caractristiques temporelles. Voici un exemple permettant d'illustrer les rgles prcdentes.

Ordre SUPERVISION

Resultat

M/A Debit CONTROLE CHARGEMENT

Quantit demande 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 sollicite par chaque message ORDRE. Sur excution de sa tche il produit un message RESULTAT. Cette fonction est dcompose en 3 fonctions plus lmentaires: - SUPERVISION comme fonction temporaire, assure pour chaque message ORDRE: son dcodage, la demande d'excution par les variables M/A et QUANTITE DEMANDEE, l'attente de la fin d'excution observe par M/A, la gnration d'un message RESULTAT. Le temps de droulement ne peut donc pas tre nul. - HORLOGE est une fonction permanente pour gnrer un vnement de discrtisation, - CONTROLE_CHARGEMENT comme fonction temporaire, ralise pour chaque vnement PAS, l'observation de la demande M/A, la grandeur d'entre DEBIT, et calcule la consigne POSITION_VANNE. Elle indique par M/A=arrt, l'obtention de la quantit demande. Les variables ne sont modifies que lorsque les fonctions SUPERVISION et CONTROLE_CHARGEMENT sont en volution. 13.2.4. Raffinement et abstraction dune S.F. Le modle de S.F. permet de dcrire 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 dtaille plus prcisment ces 2 mcanismes.
-A- RAFFINEMENT

Lorsqu'une fonction n'est pas suffisamment dtaille pour tre spcifie compltement, elle peut se dtailler elle-mme par une structure fonctionnelle. Appliquant cette dmarche descendante pour un ensemble de fonctions, on aboutit une structure fonctionnelle hirarchise en niveaux de description comme l'indique la figure ci-aprs.
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 hirarchise, numrotation. M.C.S.E 261

Partie 4 - CONCEPTION FONCTIONNELLE Les dlimitations de fonctions pour les niveaux intermdiaires peuvent s'liminer. Elles ne sont d'aucune utilit technique. On dispose alors d'un modle "plat". Ceci n'est pas judicieux car pour un systme, les niveaux intermdiaires facilitent la lisibilit et donc la comprhension. Pour des raisons de reprage dans le cas de structures complexes, les fonctions sont numrotes. La fonction de dpart considre de niveau 0 n'a pas besoin d'tre numrote. Toute fonction d'un raffinement est numrote partir de 1. Toutes les instances pour une fonction possdent le mme numro, puisque la spcification est la mme. Suivant cette rgle, le numro d'une fonction lmentaire inclut le chemin complet dans l'arbre de la hirarchie. 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 manire intgrer des solutions dj connues. Cette dmarche va dans le sens de la rutilisation. Mais la solution peut devenir difficilement comprhensible pour des problmes complexes. Des dtails doivent tre limins pour obtenir une description plus macroscopique. Pour cela, la dmarche d'abstraction consiste: - choisir un sous-ensemble de la structure fonctionnelle en le dlimitant, cohrent en lui-mme vis vis d'objectifs, - remplacer ce sous-ensemble par la spcification d'une fonction non raffine obtenue en liminant toute la description interne.
Ev MS Ev MS

U R

S U S

F
Pas

-Figure 13.8- Techniques pour labstraction. L'approche par abstraction n'est pas des plus videntes, car la cohrence des fonctions regrouper n'est pas immdiate. Toutefois, cette technique n'est pas exclure, car il faut savoir qu'une dmarche purement descendante par raffinement n'est pas toujours raliste pour des applications assez complexes. Des itrations sont ncessaires, et c'est parfois par abstraction qu'apparaissent les meilleures fonctions considrer pour une application. 262 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL 13.2.5. Dcomposition maximale: fonctions lmentaires ou actions Selon la technique de raffinement, par itrations successives, la solution est de plus en plus dtaille. Bien entendu, il faut se poser la question de l'arrt de l'itration pour chaque fonction. Un critre clair doit donc tre prcis. La rgle se veut simple : une fonction possdant un comportement squentiel et obligatoirement cyclique ne doit plus tre raffine. Pourquoi? Simplement parce que l'intrt du modle de structure fonctionnelle est de pouvoir faire apparatre un paralllisme potentiel des fonctions de la solution. Donc, si le comportement est squentiel, le raffinement ne se justifie pas. Une telle fonction est appele FONCTION ELEMENTAIRE ou ACTION. Mais comment peut-on savoir qu'une fonction possde un comportement squentiel alors que, dans une dmarche descendante, celle-ci n'est pas dfinie? C'est effectivement une question dlicate. Pour qu'une description fonctionnelle soit complte et donc vrifiable, chaque fonction doit tre spcifie, ce qui veut dire dcrite selon une vue externe. Si la spcification est base sur un modle squentiel (diagramme d'tat par exemple, modles de transformation), on dispose de la rponse. Sinon, il faut tenter un raffinement qui peut conduire le concepteur vers une structure fonctionnelle ou une spcification ou la fonction est en fait lmentaire. 13.2.6. Rgles de comportement pour une fonction lmentaire Pour la vrification, de manire pouvoir interprter le comportement d'une S.F. complte c'est--dire raffine au maximum, on donne ci-aprs les rgles de comportement imposes pour toute fonction lmentaire. Ainsi, sans devoir dtailler le contenu d'une fonction, l'interprtation sera non-ambigu pour tout niveau de la structure fonctionnelle. Les rgles ci-dessous ont t retenues pour leur simplicit et parce qu'elles facilitent ensuite le travail de ralisation. Les rgles de description interne donnes dans le paragraphe 13.3.3.C (expression du comportement des fonctions) conduisent obtenir un comportement vu de l'extrieur, conforme aux rgles de ce paragraphe.
-A- ACTION PERMANENTE

Toute fonction qui ne possde pas d'entre du type vnement ou message volue en permanence. Si ce n'tait pas le cas, rien ne permettrait d'indiquer le dbut d'volution. Ainsi, l'action permanente est assimilable un processus continu gnrateur de donnes ou gnrateur d'vnements.
-B- ACTION TEMPORAIRE

Les entres du type vnement ou message servent "rythmer" l'volution obligatoirement cyclique de la fonction. Les transformations assures par la fonction se font habituellement en temps nul. Le comportement de la fonction pour plusieurs entres de synchronisation est spcifi par le rseau de Ptri de la figure 13.9. On se place ici dans le cas d'une fonction synchrone plusieurs vnements (EVi) et la rception de messages (MESj). Le marquage initial pour EVi et MESj permet de reprsenter l'effet de mmorisation des vnements et messages. M.C.S.E 263

Partie 4 - CONCEPTION FONCTIONNELLE

Attente activation Mmoire de Ev i Mmoire de Mes j

Ev i

Mes j

Ti

Tj

Fin Ti

Fin Tj

-Figure 13.9- Spcification du comportement pour une action temporaire. Ce rseau de Ptri montre que: - les conditions d'volution peuvent tre aussi bien l'apparition d'vnements que la prsence de messages, - les transformations ou oprations (Ti, Tj) sont ralises en squence (due la prsence d'un seul jeton) et donc en exclusion mutuelle (comportement squentiel), - l'ordre d'volution dans le cas de conditions vraies simultanment n'est pas dterministe (comportement non-dterministe), - tous les vnements ou messages sont pris en compte (effet mmoire). Ce comportement est volontairement restrictif. Aprs avoir appliqu ce modle pour dvelopper de multiples applications, nous avons constat que toutes les solutions peuvent se ramener sans difficults de telles machines squentielles synchrones. Si on se limite ce seul niveau macroscopique de comportement, la solution n'est pas toujours des plus aises dcrire car elle ncessite une dcomposition fonctionnelle importante. En effet, des spcifications ncessitent parfois dans la boucle du processus cyclique, de pouvoir dcrire des attentes conditionnelles sur vnements ou messages. C'est le cas par exemple pour la spcification des protocoles. Pour cette raison, le modle de comportement durant l'volution de la fonction a t enrichi par une phase d'attente sur condition vnementielle simple ou multiple. Ceci se traduit par le fait que, parmi les oprations assures par la fonction, l'attente conditionnelle est utilisable. Le comportement de cette phase d'attente sur un ou plusieurs vnements ou messages est spcifi comme indiqu sur la figure 13.10. Une opration et une seule est assure sur apparition du premier vnement ou message de la condition. Si 2 ou plusieurs vnements (ou messages) apparaissent simultanment, la dcision de la branche utilise est indtermine. 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- Spcification de la phase d'attente. Ce comportement est intressant tout particulirement 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 vnements et messages reus n'ont pas la mme signification: - Les vnements ou messages dits d'ACTIVATION dclenchent un cycle d'activit, - les vnements ou messages dits de CONDITION temporisent le droulement de l'activit dans un cycle. Pour les diffrencier, les entres des premires sont reprsentes par une simple flche, les secondes par une double flche. Ceci permet d'noncer une rgle simple de reprsentation: toute action temporaire possde au moins une entre d'ACTIVATION. 13.2.7. Proprits d'une structure fonctionnelle Citons rapidement les proprits essentielles du modle de structure fonctionnelle.
-A- MODELE STRUCTURE

La dcomposition hirarchique favorise la comprhension progressive de la description ainsi que la recherche d'une solution. Pour le raffinement, chaque fonction se dcrit 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 rutilisation. Le modle structur hirarchique prsente ainsi la solution comme un ensemble de niveaux hirarchiss de structures partant des spcifications (vue purement externe) et allant jusqu' une ralisation fonctionnelle pour l'application. Le niveau i + 1 se dduit du niveau i par ajout de contraintes supplmentaires pour la solution. M.C.S.E 265

Partie 4 - CONCEPTION FONCTIONNELLE


-B- MODELE INTERPRETABLE ET DONC VERIFIABLE

La seule connaissance des rgles de comportement pour tous les lments -fonction lmentaire, variable, port, vnements- cits dans les paragraphes prcdents permet de dduire le comportement complet de la structure fonctionnelle. Cette dduction ne ncessite pas la connaissance prcise pour une application donne de la spcification de chacune des fonctions. Le modle est donc interprtable, ce qui est favorable pour la vrification de conformit vis vis d'une partie des spcifications.
-C- EVOLUTION SYNCHRONE

Avec l'hypothse du temps nul pour l'volution des fonctions temporaires, tous les vnements et messages produits sont synchrones aux vnements et messages d'activation ou de condition. L'analyse est ainsi facilite puisque toutes les volutions sont immdiates et simultanes par catgorie.
-D- CONSERVATION DES RELATIONS DORDRE

Les relations d'ordre partiel sont respectes du gnrateur vers les rcepteurs, ainsi que de chaque producteur vers le consommateur correspondant.
-E- MAXIMUM DE PARALLELISME

La rgle de dcomposition est de poursuivre le raffinement jusqu' l'obtention de fonctions lmentaires. Comme par dfinition, ces fonctions ont un comportement squentiel, le modle de structure fonctionnelle complet reprsente donc a priori le maximum de paralllisme possible pour son volution. Il est noter que pour certains problmes trs fortes contraintes de temps: traitement d'images par exemple, les algorithmes connus sont gnralement squentiels. Mais pour l'implantation, ces algorithmes doivent tre transforms pour mettre en vidence un paralllisme. 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 mme pour le nombre et le type de fonctions. La structure peut donc voluer dans le temps tout en respectant les rgles de comportement nonces. Ainsi, il est donc possible de dcrire, et par dduction de concevoir, des systmes admettant une EVOLUTION STRUCTURELLE (reconfiguration, fonctionnement dgrad, autoadaptation...). Dans la suite, on se limitera la conception de structures statiques. 13.3. SPECIFICATION DES FONCTIONS ELEMENTAIRES La spcification des fonctions lmentaires dcrite dans le paragraphe prcdent exprime un point de vue externe. Ce point de vue est justifi pour permettre, aprs chaque tape du raffinement, une vrification de la solution fonctionnelle. Ce paragraphe a pour objectif de formaliser les rgles de description du comportement interne de toute fonction lmentaire. La description qui sera faite, conforme aux rgles du point de vue externe, jouera pour la phase d'implantation, le rle d'une spcification complte et non-ambigu. Cette spcification sera en elle-mme suffisante pour la suite, sans devoir faire rfrence la structure fonctionnelle qui l'inclut. 266 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL 13.3.1. Objectifs de la spcification Aprs chaque phase de raffinement, le concepteur doit vrifier la solution retenue par rapport aux spcifications. La vrification est faite, sachant qu'il a en tte le comportement qu'il imagine pour la fonction. Pour garantir une cohrence complte de la solution fonctionnelle, une fois le raffinement achev totalement, le comportement de chaque fonction lmentaire doit tre exprim sur papier. Pour clarifier, citons les objectifs essentiels pour cette spcification: - liminer toute ambiguit d'interprtation. Ceci est une condition ncessaire pour garantir la validit de la solution retenue. Pour cela, la description doit tre: concise, comprhensible, non-ambigu, complte. - tre compatible avec le modle fonctionnel, ceci veut dire que cette spcification apporte une dimension supplmentaire de la description (trs souvent temporelle), avec compatibilit des couplages par les entres et sorties des fonctions. - exprimer le "quoi" de prfrence au "comment": spcification plutt qu'implantation. Aussi la spcification doit s'exprimer sans considration de contraintes de temps. - favoriser ultrieurement la recherche d'une solution d'implantation. Incompatible a priori avec l'objectif prcdent, il faut savoir toutefois que le produit final est une ralisation. Aussi, faut-il trouver un juste milieu entre la spcification formelle purement externe et une description de pure implantation. - favoriser la validation. Ceci peut se faire de 2 manires complmentaires: par des lecteurs qui peuvent tre par exemple des rdacteurs de spcifications, voire mme les demandeurs, par des outils informatiques, qui aprs traduction de la description, permettent de vrifier le comportement par simulation partielle ou totale. 13.3.2. Choix du langage de description La mthode de description doit satisfaire au mieux les objectifs ci-dessus. Analysons les solutions possibles par catgories.
-A- DESCRIPTION GRAPHIQUE OU TEXTUELLE

Les descriptions graphiques favorisent particulirement la comprhension. C'est un excellent outil de communication. Toutefois, la description est difficilement complte surtout lorsqu'il s'agit d'exprimer des dtails. Autant c'est un outil essentiel pour les spcifications globales, autant il n'est pas suffisant ce stade si on dsire disposer d'une description fonctionnelle suffisante pour poursuivre vers la ralisation. Une description textuelle perd en qualit de visibilit globale. A son avantage, la description peut tre aussi complte que souhaite. Nous retenons donc cette deuxime forme, sachant que l'unit dcrire sera limite en taille. M.C.S.E 267

Partie 4 - CONCEPTION FONCTIONNELLE


-B- DESCRIPTION DECLARATIVE OU IMPERATIVE

Au sens strict du terme, une spcification ne doit exprimer que le "quoi" et pas du tout le "comment", c'est--dire ne donner qu'une vue externe de l'objet dcrit. Une telle description n'est pas procdurale. Elle peut par exemple s'exprimer par des modles formels (mathmatiques ou autres ...) qui s'expriment en nonant les pr-conditions et les postconditions pour la fonction. L'avantage de cette solution est que pour la suite, les ralisateurs disposent de tous les degrs de libert pour trouver ou choisir la solution la plus approprie pour satisfaire la spcification. En contre-partie, ce type de spcification n'est pas facile crire; il s'avre plus facile d'exprimer le comportement selon un modle interne. Ensuite, la validation est difficile, voire impossible pour des descriptions assez complexes. Enfin, la description est trs loigne d'une description qui favorise l'implantation. Une description imprative est base sur l'utilisation a priori d'un modle 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 particulirement limites. Comme avantage, elle permet de favoriser considrablement l'implantation et la validation par des outils informatiques, ce qui se traduit par un gain de temps apprciable. Pour exprimer comment les variables de sortie doivent tre obtenues partir de celles disponibles en entre, presque obligatoirement, il faut faire intervenir des variables internes qui peuvent se dduire par exemple par une analyse des spcifications. Rpondant le mieux aux objectifs noncs, on retient l'utilisation d'une description du type impratif avec comme modle interne celui de la machine squentielle. Le rdacteur de la spcification devra trouver le juste milieu entre une vue purement externe et une implantation trop stricte de manire conserver des degrs de choix pour l'implantation.
-C- LANGAGE NATUREL OU LANGAGE "EXECUTABLE"

Aprs avoir retenu la forme textuelle et du type impratif, il faut se poser la question de la rigueur syntaxique. Le langage naturel est trs riche, ce qui permet une multitude de possibilits de description d'une mme "chose". La comprhension peut ne pas tre vidente par suite de redondances dans le texte. De mme la vrification de compltude n'est pas du tout vidente. Un langage "excutable" c'est--dire un langage informatique est particulirement strict parce que rgi par des rgles syntaxiques et smantiques prcises. Les degrs de libert sont nettement moindres. Mais par suite de la rigueur, les critres tel que concision, compltude, non-ambigut, non-redondance sont plus facilement satisfaits. A l'avantage des langages excutables aujourd'hui, il faut noter l'existence de langages de haut niveau, et donc structurs et structurants, indpendants des matriels. Citons particulirement: PASCAL et ADA. Indiscutablement, il faut retenir un langage du type excutable. Ce type de langage favorise les critres cits dans les objectifs, rduit le temps de dveloppement car presque excutable tel quel, enfin permet une validation presque complte de la solution par simulation tout en restant indpendant 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 indiques dans la suite. Il est vident qu'un pseudo-langage du type: Si alors Sinon- est tout fait possible; comme inconvnient, la vrification automatique par excution de la description puis l'implantation ne s'en trouvent pas facilites. 13.3.3. Le modle de description Aprs avoir prcis les choix du type de description, ce paragraphe dcrit formellement les rgles de description suivre. Le modle de description est prsent selon 3 niveaux, chacun correspondant un raffinement: - l'interface avec le modle de structure fonctionnelle, - le corps de la description du comportement, - l'expression du contrle des volutions.
Fonction

Interface

Corps de la description

Contrle des volutions

-Figure 13.11- Structure de la description. Au pralable faisons tat de quelques points importants satisfaire: - 2 types de fonctions: temporaires ou permanentes suivant la prsence ou non d'entre(s) du type vnement ou message, - cohrence de nature entre les entres et sorties et les variables lies du modle fonctionnel. - initialisation des variables du modle fonctionnel. Obligatoirement pour que l'application parte d'un tat initial donn, ces variables ne peuvent tre initialises que par les fonctions qui s'y trouvent lies par une sortie.
- A- INTERFACE AVEC LE MODELE DE STRUCTURE FONCTIONNELLE.

Le modle de structure fonctionnelle considre une fonction lmentaire comme un symbole graphique reprsentant une "bote noire" et possdant des entres et sorties de 3 types: vnements, variables, messages. Les entres vnements et messages sont de 2 types (1 flche ou 2 flches) suivant qu'il s'agit d'une entre d'activation ou une entre 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- Reprsentation graphique d'une fonction. La syntaxe retenue pour lexemple ci-dessus est la suivante:
action EXEMPLE sur vnement Eve et message Mea: T_Mea avec (entres message Mee: T_Mee; var Ve: T_ve; entre/sortie var VI: T_VI; sorties vnement Evs; var vs: T_vs; message Ms: T_Ms);

Cet exemple permet de dduire facilement la syntaxe gnrale respecter. Toutes les entres, vnements et messages d'activation sont prciss aprs "sur", les autres entres et sorties aprs "avec". Pour une action permanente "sur" n'existe pas. La nature de chaque entre ou sortie est identifie. Pour les messages et variables, la structure de l'information est dfinie par son type (T_ ... par exemple). L'appellation "action" est retenue plutt que "fonction", "process", "tche", pour viter les confusions avec une terminologie dj employe par ailleurs et peut-tre trop proche de l'implantation. Il faut avoir l'esprit qu'une action est en fait une tche qui volue comme un processus, mais limite une fonction simple et donc relativement instantane.
-B- CORPS DE LA DESCRIPTION

Cette partie dcrit le comportement global de toute fonction. La description doit tre conforme la spcification retenue pour le modle fonctionnel. Ainsi toute fonction se comporte comme une machine squentielle, ce qui implique aussi l'initialisation de toutes les variables internes. D'autre part toutes les variables de sortie doivent tre initialises. La description doit donc respecter le modle 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'excution cyclique de l'instruction <comportement>. 270 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL
- C- EXPRESSION DE LEVOLUTION DE LACTION

Les 2 cas - action permanente, action temporaire - sont diffrencier. Pour l'action PERMANENTE, il n'y a pas de condition d'activation. Le comportement est alors exprim par une suite d'oprations squentielles.
Instruction;

begin

Instruction;

end;

Pour l'action TEMPORAIRE, il faut associer chaque entre vnement ou message d'activation, l'expression du comportement comme une suite d'oprations squentielles.
Nom Ev

Instruction;

Nom Mess

begin

Instruction;

end;

L'volution, qui implique l'excution des oprations exprimes dans <comportement>, n'est effective que sur apparition de l'lment d'activation. Des entres supplmentaires du type vnement ou message peuvent aussi servir comme condition d'attente durant une volution pilote par une activation. La syntaxe est la suivante.
when Nom Ev

Instruction;

end when

Les when imbriqus sont particulirement dconseills. Il est alors srement prfrable de revenir sur la structure fonctionnelle pour simplifier la spcification de la fonction. Pour complter cette prsentation, le comportement au niveau le plus lmentaire s'exprime partir des structures de contrle de la programmation structure, savoir: squence d'instructions, itration (while ou repeat ou boucle do), dcision (if, case). La syntaxe est alors spcifique du langage retenu. Une syntaxe du type langage structur n'est pas toujours la forme la plus approprie. En particulier, c'est le cas lorsque le comportement est du type combinatoire: les sorties dpendent uniquement des entres. Pour des raisons de clart et de concision, il est alors plus judicieux d'utiliser: - une table de dcisions, - un arbre de dcisions. M.C.S.E 271

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

Pour illustrer le modle de description, on donne ci-aprs le dtail de l'exemple introduit au dbut du paragraphe. Le message Mea contient 2 types dinformations CMD ou ACK, ce qui se traduit par T_Mea = [CMD | ACK].
action EXEMPLE sur vnement EVe et Message Mea:T_Mea avec (entres message Mee:T_Mee; var Ve : T_Ve; entre/sortie var VI : T_VI; sorties vnement EVs; var vs: T_vs; message Ms: T_Ms); const K = 10; Var ETAT:(arrt,marche); MESS:string; begin ETAT:= arrt; 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 contrle de lactivation, - "when ... : ... end when;" pour le contrle de l'volution. Ces 2 dernires structures de contrle assurent implicitement la rception des vnements et messages en entre. De plus il est utile de pouvoir dcider dun traitement spcifique pour chaque type de message reu. Pour cela, dune part la description de la structure des messages est identique la notation donne dans les spcifications vitant ainsi dutiliser des records variants, dautre part la signification de linstruction CASE est tendue pour permettre le test du type de message reu. 272 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL S'ajoutent les instructions de gnration d'un vnement (SIGNAL) et de gnration d'un message (SEND), ainsi que, si ncessaire, tables et arbres de dcision. En remarque, nous aurions pu choisir le langage ADA comme rgle de description. Cycle et When se remplacent alors plus ou moins directement par accept et select. Volontairement, nous avons prfr une syntaxe plus indpendante et probablement plus simple de comprhension pour les non-initis ADA. De plus, le mcanisme de communication synchronisation dans ADA est particulier puisque du type Rendez-vous ncessitant ainsi une synchronisation, ce qui est un principe trs diffrent de l'change asynchrone des messages par un tampon intermdiaire prconis par le modle fonctionnel. Bien entendu, si l'implantation doit se faire en ADA, la transcription sera alors relativement immdiate (voir 22.7). 13.3.4. Interprtation du modle Ce paragraphe prcise les rgles de comportement induites par la syntaxe.
-A- INITIALISATION - EVOLUTION

Le systme dcrit par le modle fonctionnel doit dmarrer d'un tat parfaitement dtermin, indpendamment d'un ordre d'excution introduit par l'implantation. Pour cela, les squences d'initialisation de toutes les fonctions sont considrer comme se droulant avant la partie volution dlimite par "cycle". L'tat de dpart se trouve donc correctement dfini si toutes les variables du systme sont initialises ainsi que toutes les variables internes. Ceci est une des rgles de vrification de la description.
-B- ACCES AUX VARIABLES DETAT

Les variables d'tat (ou variables partages) sont tout instant accessibles en consultation ou pour une mise jour. Ainsi toute variable d'tat peut apparatre dans une instruction d'assignation ou d'valuation d'une expression. L'accs est suppos se faire en temps nul. L'exploitation de ces variables suppose en permanence leur cohrence et donc le respect des contraintes d'intgrit. L'implantation devra fournir une solution pour le respect de cette cohrence. En cas d'assignations simultanes par plusieurs fonctions, il est essentiel de dfinir les variables d'tat telles que l'application reste insensible l'ordre d'accs une mme variable.
-C- ECHANGE PAR MESSAGES

Pour un transfert par message, un port sert d'lment intermdiaire. L'instruction SEND (A,B) dpose 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'accs au port. Aucune hypothse n'est faite sur la capacit du port. Ainsi toute opration SEND assure un dpt immdiat. Par contre le retrait peut se faire tout instant postrieur.
-D- ACTIVATION DUNE ACTION

Pour les actions temporaires, les vnements ou messages servant l'activation sont effet mmoire. Le port assure ce rle pour les messages. Ainsi tous les lments d'activation seront pris en compte par l'action, donc pas de perte. M.C.S.E 273

Partie 4 - CONCEPTION FONCTIONNELLE Les squences d'oprations associes chaque condition d'activation sont mutuellement exclusives comme indiqu dans le modle de S.F. Pour 2 conditions simultanes ou plus, il y a droulement squentiel des squences dans un ordre non dterministe. La spcification du comportement de la fonction doit donc tre labore en restant insensible l'ordre. L'intrt de cette structure de contrle d'activation est d'assurer naturellement l'exclusion mutuelle sur toutes les variables internes de l'action.
-E- EVOLUTION CONDITIONNELLE DANS UNE ACTION

Des vnements ou messages peuvent servir au contrle de l'volution. Ces conditions d'volution sont sans effet mmoire, ce qui veut dire que seul un vnement dont l'attente est effective est pris en compte. Si plusieurs conditions existent, seule la premire apparatre est prise en compte. Ceci engendre l'excution d'une seule branche. Les vnements ou messages pour les autres conditions et qui apparatront ultrieurement sont limins. Ce comportement a t explicit par le Rseau de Petri dans le modle fonctionnel (voir 13.2.6.B).
-F- DUREE DEVOLUTION

En dehors de toutes caractristiques technologiques, la seule hypothse raliste 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 spcifications temporelles sont ncessaires lorsqu'il s'agit de prciser la frquence de gnration des sorties. 13.4. SPECIFICATION DES DONNEES Le modle fonctionnel utilise en interne du systme des donnes sous la forme de variables d'tat ou de messages comme intermdiaires entre les fonctions charges d'effectuer des transformations sur celles-ci. Pour que la description fonctionnelle soit complte, ces donnes doivent tre compltement spcifies. Dans ce chapitre, on ne se pose pas la question de l'ordre suivre: faut-il commencer par spcifier les fonctions puis les variables ou l'inverse? Cette question sera voque dans l'expos de la mthode de recherche de la solution. On peut toutefois noter qu'il apparat bien difficile de spcifier compltement une fonction lie des entres et sorties de donnes, sans dfinir au pralable la nature de celles-ci. Dans la suite du paragraphe, aprs avoir prcis les objectifs de cette spcification, sont explicites les rgles de description conseilles, puis les rgles dutilisation de ces donnes. Le modle de spcification des donnes prconis pour la conception fonctionnelle est trs similaire celui dcrit pour les spcifications (voir 11.5). Toutefois, il s'agit ici de caractriser uniquement les donnes internes. 13.4.1. Objectifs de la spcification des donnes Citons les points essentiels auquels doit rpondre le modle de spcification propos: - dfinir compltement la nature des donnes ce qui ncessite d'expliciter: la catgorie (variable d'tat ou message), la signification de la donne, la structure de la donne, le type de chaque constituant de base, 274 M.C.S.E

Ch 13 - LE MODELE FONCTIONNEL - retenir pour chaque donne les constituants ncessaires et suffisants pour le modle fonctionnel. Ceci implique que le modle doit favoriser l'orthogonalit des constituants de manire viter les redondances, - exprimer compltement, sans ambigut et avec concision toutes les caractristiques ncessaires, - tre appropri une large classe de donnes: du boolen jusqu'aux relations entre entits, - tre indpendant de l'implantation, d'o l'utilisation d'un modle conceptuel toutefois facilite la recherche d'une implantation. 13.4.2. Modle de description Pour rpondre 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 utilises pour la phase de spcification peuvent servir de complment ou comme aide la recherche de la solution. Pour formaliser le modle, 3 aspects essentiels sont expliciter [WARD-85], savoir: la signification, la composition, le type. Le modle sera ensuite dtaill sur la base des oprateurs fondamentaux.
-A- SIGNIFICATION

qui

Toute donne est dsigne par un NOM. Pour viter les ambiguts que peut induire ce nom, il doit tre explicit par d'autres mots. Le problme est le mme que celui de devoir dfinir un mot dans un dictionnaire. La signification d'une donne s'obtient par analyse du rle de cette donne dans le systme et donc dans le modle fonctionnel. exemple KILOMETRAGE = * distance en Km parcouru par la voiture *
- B- COMPOSITION

Une donne peut tre: lmentaire, ou compose de donnes plus lmentaires. Par exemple, la position d'un avion peut tre dfini par les 3 grandeurs: latitude, longitude, hauteur. La composition s'obtient en exprimant les constituants et les oprateurs utiliss pour la composition. Les techniques de raffinement et d'abstraction sont donc tout fait utilisables pour aboutir une description structure. La structuration des donnes est base sur les 3 oprateurs fondamentaux de composition: - la concatnation, ou produit cartsien, ou le ET, (TOGETHER WITH). C'est l'association d'au moins 2 composants plus lmentaires, selon un ordre donn (symbole +), - la slection, qui exprime le choix dune structure parmi un ensemble (EITHER OR) (symbole |), - la rptition qui dfinit lensemble pour exprimer lexistence dun mme type de constituant, et ceci 0, 1 ou plusieurs fois (symbole {}). M.C.S.E 275

Partie 4 - CONCEPTION FONCTIONNELLE On adoptera donc les mmes conventions syntaxiques et graphiques que pour les spcifications (voir 11.5). Lexemple V = A + B | { C } signifie que la variable V est la slection de lun des 2 types de donnes: A + B qui est la concatnation de A et de B, ou { C } qui est un ensemble dlments de type C.
-C- TYPE DUN ELEMENT ET ATTRIBUTS

Les donnes considres comme lmentaires sont des grandeurs spcifies sur un domaine de dfinition. Les types classiques sont ceux connus en programmation: boolen, entier, flottant, numration ... Pour amliorer la caractrisation des donnes, des attributs sont ajouts tels que: le type de l'information, le domaine de dfinition ou les limites, la prcision (ou la rsolution), l'unit . 13.4.3. Catgories de donnes: les structures Aprs avoir rappel prcdemment les caractristiques d'une donne, on s'intresse ici aux types fondamentaux de donnes obtenues par composition et utilisables pour la spcification des donnes internes d'un systme. Au-del de donnes identifies individuellement, des descriptions plus complexes peuvent tre obtenues l'aide de relations de couplage. Ces relations conduisent aux structures de donnes.
-A- CATEGORIES DE DONNEES

Nous avons dj vu dans la partie spcification que les 2 catgories de donnes spcifier sont: - les entits donne, - 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 modlise comme une donne dfinie par: son type pour un lment de base, une composition de types pour un objet plus complexe. Les informations caractrisant l'entit sont des ATTRIBUTS qui dfinissent les proprits spcifiques de l'entit [ABBOTT-86]. Une RELATION exprime un fait entre des entits. Avec les relations, les donnes deviennent des structures de donnes qui rsultent d'un ensemble de donnes et de liens de couplage entre celles-ci. Par dualit structure de fonctions <-> structure de donnes, on retrouve tout fait l'quivalent du modle de structure fonctionnelle: fonctions et relations <-> donnes et relations. Pour des donnes, comment peut-on spcifier tout type de structures de donnes ? D'aprs les objectifs, la spcification retenir doit favoriser ensuite l'implantation. Il faut savoir que pour les structures complexes, l'implantation se trouve facilite par l'emploi de bases de donnes du type relationnel ou du type objet. Pour le modle relationnel, les entits d'un mme type sont mmorises dans une table, de mme pour les relations. Une table est en fait une collection de donnes dun mme type et donc un ensemble. Les liens exprims par une relation se traduisent par des rfrences sur les entits concernes. Ainsi les entits donne et les relations peuvent sexprimer par des structures de donnes. On peut donc partir de ce point essentiel qui favorisera l'implantation, pour dfinir la technique de spcification. 276 M.C.S.E

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

Il reste expliciter la syntaxe utiliser pour spcifier des entits et des relations, conformment lide de description introduite dans le paragraphe prcdent. Entits et relations se dfinissent toutes les deux sous la forme de donnes. Ainsi l'analyse des catgories conduit la ncessit de diffrencier 2 niveaux pour les donnes: - la donne individualise, - la collection d'un type dfini de donne (aussi appel ensemble ou SET)
Nom Possesseurs

Voiture

Nom Possesseur voiture Possesseurs = possesseur voiture

-Figure 13.13- Donne individualise et collection. Une donne individualise est dsigne par un NOM qui lui est propre. Pour plusieurs instances du mme type, chaque instance possde son nom spcifique. Par exemple, V1, V2 : voiture; signifie que les objets V1 et V2 sont du type voiture. Dans une collection, toutes les donnes sont du mme type, mais ne sont pas dsignes individuellement. Comme toutefois chaque donne doit tre identifie, sans devoir y associer un nom pour chaque, on peut imaginer plusieurs techniques de dsignation: premier, suivant, dernier dans la collection. Ces mcanismes sont des techniques particulires qui concernent la phase d'implantation. Une autre solution possible, celle retenue ici, consiste y accder par le contenu. Une partie des informations contenues dans la donne permet d'identifier d'une manire unique une donne particulire dans une collection. Cette information minimale est appele la CLE. Sur ce principe, on ne peut trouver dans une collection que des donnes possdant des cls diffrentes. Comme exemple, en supposant que No d'immatriculation et No Scurit Sociale puissent servir de cls pour les voitures et les personnes, les 2 collections voitures et personnes se dfinissent par: voitures = { voiture } voiture = No Immatriculation+ marque + couleur + ... personnes = { personne } personne = No SS + situation + nom + adresse + age + ... L'information utilise comme CLE est souligne. La notation employe ici est celle de WARD [WARD-85]. M.C.S.E 277

Partie 4 - CONCEPTION FONCTIONNELLE La spcification d'une relation ncessite de dsigner les entits concernes. Ceci est dfini par des rfrences sur les entits. Une relation peut se considrer comme une donne individualise, ou faisant partie d'une collection. Ainsi, une relation individualise pour une personne possdant une ou plusieurs voitures s'crit: Possesseur N = Personne_Ref + 1{ voiture_Ref }n + date Cette spcification permet d'exprimer toutes les voitures pour une personne donne. Le suffixe Ref prcise quil sagit dune rfrence. Les bornes 1 et n dfinissent 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 particulire dans une collection, s'identifie alors par la cl de la relation ici forme des 2 informations de dsignation. Si on dsire associer la date dachat pour chaque voiture, il faut alors crire: Possesseur = Personne Ref + 1{voiture Ref + date}n. 13.4.4. Dcomposition d'une donne: minimisation et normalisation Les donnes doivent contenir les informations minimales ncessaires pour le systme. Ceci s'obtient en choisissant des informations dites indpendantes. La modification d'une information n'implique alors aucune modification des autres. On parle de minimisation de la redondance des donnes. Pour la spcification des entits et des relations par des donnes, le mme critre doit tre appliqu. Il faut faire en sorte qu'une information spcifique ne soit dfinie qu'une seule fois. Pour le modle relationnel des rgles sont dfinies pour aboutir une base de donnes dite normalise, par analyse des dpendances fonctionnelles. Si lapplication ncessite des informations plus prcises, le lecteur est invit consulter des ouvrages spcialiss sur les bases de donnes [DATE-86, ROLLAND-88, GALACSI-86-89]. Succintement la mthode prconise plusieurs tapes: - laboration de la liste des champs ou attributs des entits et relations, - transformation selon la 1re forme normale, ceci veut dire dfinition d'une cl primaire pour chaque type d'entits. On recherche pour cela le plus petit ensemble de champs permettant d'identifier de manire unique chaque attribut dans la collection. - transformation selon la 2me forme normale. Pour des relations possdant une cl primaire, tous les attributs en dehors de la cl primaire de l'entit doivent dpendre fonctionnellement et lmentairement de cette cl primaire. Par exemple pour (A,B,C,D,E) et les dpendances suivantes qui doit tre la couverture minimale des dpendances fonctionnelles: (A,B) --> C A --> D B --> E Il faut considrer les 3 entits suivantes: 278 M.C.S.E

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

La 2me 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 dpend pas du code produit. - transformation selon la 3ime forme normale. Pour cette reprsentation, il ne faut pas retrouver de dpendances entre champs qui ne sont pas des cls (pas de dpendances transitives). Si c'est le cas, il faut faire une dcomposition complmentaire. 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 dterminant (partie gauche dune dpendance fonctionnelle) pour les autres doit tre une cl. Ceci permet d'liminer des redondances. 13.4.5. Utilisation des donnes Aprs avoir explicit le modle de description, il reste prsenter la manire de dcrire une utilisation des donnes. Les variables d'un modle fonctionnel sont disponibles en consultation ou pour la mise jour avec respect des contraintes dintgrit. La nature de l'opration possible sur les donnes est dfinie par le sens du lien. Une variable peut tre utilise en totalit ou en partie. Ceci est prcis par le libell du lien comme lindique la figure ci-dessous. V= A + B A B -Figure 13.14- Exemple de libell des liens une variable. Une donne individualise, complte ou partielle, est directement utilisable gauche d'une assignation, ou dans une expression. Une donne dfinie comme une collection ncessite de dsigner le ou les lments concerns. Les oprateurs disponibles pour manipuler un ensemble ou une collection (A) sont par exemple: M.C.S.E 279 V B A

Partie 4 - CONCEPTION FONCTIONNELLE - laffectation dun attribut dune donne: - l'ajout d'lments: - le retrait d'lments: - la mise jour d'un champ pour un ensemble: - la slection d'lments dun ensemble A: A[cl].champ := valeur; A := A + { entit }; A := A - { entit }; champ := valeur for {entit} A where <critre de selection>

- la lecture dun attribut dune donne de nom N: V := A[N].champ;

Ajout, retrait, mise jour et slection concernent un ensemble d'entits. Un ensemble d'entits peut tre la rsultante d'une slection selon un critre 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 donnes relationnelle, ces oprateurs sont disponibles dans le langage d'interrogation SQL: select, insert, delete, update. Les tables du modle relationnel et SQL sont une solution d'implantation pour des spcifications dcrites selon le modle propos. Mais, ce n'est pas la seule solution. 13.5. PROPRIETES GLOBALES DU MODELE FONCTIONNEL Pour conclure la prsentation du modle fonctionnel, citons quelques aspects intressants de ce modle.
-A- INDEPENDANCE TECHNOLOGIQUE

Le modle fonctionnel est gnral. En effet, aucune hypothse n'a t faite sur la nature des donnes. 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 manire modliser des oprateurs tels que amplis oprationnels, multiplieurs, changeurs de frquence ... Dans le cas temporaire, la fonction agit en synchrone un vnement et exploite ou produit des variables continues des instants discrets. Le modle permet ainsi de reprsenter toute nature de technologie.
-B- MODELE HIERARCHIQUE

Contrairement aux modles dits "plats", le modle hirarchique favorise toute dmarche incrmentale. En effet, avec un tel modle, une dmarche peut tre: - purement descendante : on part du niveau le plus lev, puis par dcomposition, apparaissent les niveaux infrieurs, - purement ascendante: la prsentation en niveaux s'obtient par regroupement pour chaque niveau de sous-ensembles du niveau infrieur. - mixte: partir de tout niveau intermdiaire, on peut augmenter ou rduire le niveau de dtail. 280 M.C.S.E

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

Dans la dmarche descendante, le raffinement enrichit tout lment (fonction, variable) par apport de dtails complmentaires. Raffiner un lment revient faire apparatre une vue plus microscopique. Ces dtails jouent le rle de contraintes pour la solution. En effet, ces dtails qui s'imposent ou se choisissent participent l'expression d'une ralisation (dans le sens solution) pour l'lment considr, ce qui limine a priori toute autre ralisation. Concevoir correctement par raffinement impose donc d'envisager toutes les ralisations plausibles, puis slectionner la meilleure sur la base de critres prcis. Construire par ajout de constituants augmente la complexit. Dans la dmarche ascendante, il faut pouvoir rduire cette complexit, ce que permet l'opration d'abstraction. L'opration d'abstraction consiste: - tout d'abord dlimiter ou "encapsuler" une partie de l'ensemble considr, - ensuite remplacer cette partie dlimite par sa spcification. Ainsi l'opration d'abstraction permet de faire disparatre des informations propres une ralisation de l'lment abstrait. Cette technique favorise la dfinition d'objets en vue de leur rutilisation.
-D- INDEPENDANCE ET REDONDANCE

L'indpendance ou orthogonalit est un concept essentiel en conception. D'une manire gnrale, un ensemble d'lments est dit orthogonal si la modification de l'un d'eux n'entrane pas de modification des autres lments de l'ensemble. Lorsque les lments sont des fonctions, on parle alors d'espace de fonctions. Pour des lments du type donnes, on parle d'espace de donnes. Le choix judicieux d'un espace orthogonal minimise: pour les donnes, le nombre de variables, pour les fonctions, la complexit de celles-ci et les couplages inter-fonctions. Bien-entendu, dans un espace orthogonal, la "dfectuosit" d'une variable ou d'une fonction engendre une perte d'information, ce qui conduit une ralisation incomplte et donc incapable de respecter toutes ses spcifications. Pour palier ces dfauts, si ncessaire, des lments supplmentaires sont ajouter. L'espace devient alors REDONDANT. La redondance s'obtient: - par duplication ou plus, de certains lments critiques, - par ajout d'lments reprsentant des compositions partir des lments de base. La redondance contribue amliorer la SURETE de FONCTIONNEMENT, ce qui s'obtient par une augmentation de la complexit.
-E- REPRESENTATION GRAPHIQUE

Parmi les syntaxes ou reprsentations possibles pour un modle -textuelle, graphique- le modle fonctionnel est graphique pour la partie essentielle. Ceci lui confre les qualits de simplicit, concision et efficacit. Compte-tenu des rgles simples d'interprtation, 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 rgles de description, toute solution exprime par un concepteur est une solution particulire du modle fonctionnel. Ainsi la solution hrite de toutes les proprits du modle. 13.6. RESUME Rappelons en fin de ce chapitre qui a permis de formaliser le modle fonctionnel, les points essentiels. - le modle fonctionnel est compos de 3 ensembles: la structure fonctionnelle, la spcification des fonctions, la spcification des donnes, - le modle de structure fonctionnelle est un modle hirarchis qui favorise le raffinement et l'abstraction, - les relations fonctionnelles sont de 3 types: partage de variable, synchronisation par vnement, transfert de messages, - la notation graphique favorise tout particulirement la lisibilit, - une fonction est non dcomposable si son comportement est exprimable selon un modle squentiel, - toute fonction lmentaire est cyclique et permanente (pas d'activation) ou temporaire (activations), - la spcification d'une fonction sous une forme algorithmique favorise sa vrification et son implantation, - le modle pour les donnes est du type relationnel et hirarchique. Il favorise l'implantation (bases de donnes relationnelles et donnes types), - le modle fonctionnel exprime le maximum de paralllisme possible pour la solution, - le modle fonctionnel exprime la solution du problme sans faire tat des caractristiques technologiques.

282

M.C.S.E

Chapitre 14

PRINCIPES EN CONCEPTION

Toute solution dveloppe par un concepteur doit tre conforme au modle fonctionnel. De cette manire, elle peut tre reprise comme spcification pour l'tape suivante de conception dtaille. Le respect du modle conduit aussi l'obtention de proprits, certaines amliorant la qualit, d'autres l'implantation, la testabilit, la suret. Le chapitre prcdent a eu pour objet de formaliser un tel modle. Mais la connaissance du modle n'est pas suffisante. Une solution peut tre conforme au modle et pourtant ne satisfait pas les spcifications ou ne possde aucune qualit de simplicit, de lisibilit, de maintenabilit. En plus de la connaissance d'un modle, le concepteur doit disposer d'un guide qui va l'aider ordonner sa dmarche: les questions se poser, les dcisions prendre et sur quels critres. C'est l'objectif d'une mthode. Une mthode est base sur quelques grands principes qui vont donner toute solution des qualits intrinsques. Globalement, ces qualits visent amliorer l'ensemble du cycle de vie du produit. Avant de dcrire en dtail la mthode associe au modle fonctionnel, ce chapitre prsente un panorama des principes qui facilitent la recherche d'une solution fonctionnelle. Ces principes serviront comme bases pour la mthode prsente dans le chapitre suivant. Il s'agit de rpondre quelques questions essentielles que doit se poser le concepteur: - Comment faut-il dcomposer pour proposer une solution? Quels principes suivre? - Quels lments faut-il rechercher pour aboutir une bonne dcomposition? - Sur quels critres se juge la qualit d'une solution?

M.C.S.E

283

Partie 4 - CONCEPTION FONCTIONNELLE 14.1. CONCEPTION ORIENTEE SUJET Les systmes temps-rel concevoir sont essentiellement des systmes ddis pour une application spcifique. Tout systme rsulte de l'association de multiples constituants. Si on fait une analyse des divers constituants entrant dans la composition d'un tel systme, on trouve: des fonctions proches de la spcificit de l'application (fonction de rgulation, d'observation ...) et des fonctions plus gnrales qui peuvent se retrouver dans de multiples applications (base de donnes, gestionnaire de dialogue, excutif multi-tches ...). Concevoir, c'est rechercher puis slectionner les constituants ncessaires pour exprimer une solution. Cette recherche doit se faire partir du ou des sujets de l'application. ALFORD a dfini les caractristiques des systmes ddis partir d'une vue globale de toute application. D'une manire gnrale, tout systme possde 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 observs, alors le systme agit sur eux, puis ils quittent l'espace d'action [WARD-85].

Perception Action

Perceptions Autres

Actions

Systme
Structure

-Figure 14.1- Le modle Perception/action pour un systme de contrle. Une telle vue du systme concevoir, en terme d'objectif global, permet d'orienter la dmarche d'analyse vers une recherche des constituants essentiels dans les 3 catgories: - perception, - action, - exploitation, transformation, valuation, etc, comme intermdiaires entre les 2 prcdentes. Cette approche est oriente SUJET, car elle part de l'essentiel (WHAT), contrairement une approche ralisation qui consiste rechercher des lments qui devraient permettre de satisfaire les spcifications. Selon les auteurs, on retrouve plusieurs terminologies pour exprimer la mme ide: approche logique plutt que physique, sparation entre l'essentiel et la ralisation (implmentation). 284 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION Une conception doit satisfaire les spcifications du problme. Il faut donc faire l'analyse en se basant sur les spcifications. Une conception oriente sujet se trouve facilite si les spcifications sont bases sur une modlisation de l'environnement et donc du sujet. C'est le cas de la dmarche propose pour laborer les spcifications fonctionnelles. Ainsi, les donnes d'entre pour l'tape de conception, savoir les spcifications fonctionnelles, favorisent l'laboration d'une solution oriente sujet. Cette dmarche oblige rsoudre tout d'abord les problmes trs spcifiques de l'application, en priorit par rapport des problmes plus gnraux rencontrs dans la plupart des applications et pour lesquels les solutions sont connues. L'exemple suivant de contrle de temprature montre la diffrence de rsultat entre une approche SUJET et une approche ralisation.
Correct
Ordre Clavier Modification paramtres Consigne T T Filtrage et rgulation Tm Demande Tm Tltransmission Tm Mess_Tm Demande Interprtation message et rponse Rponse Cmd T Filtre Tm Commande Dialogue

Incorrect
Ecran

Paramtres Cmd

-Figure 14.2- Approche SUJET, approche REALISATION. Dans le premier cas, les fonctions et variables sont dfinies relativement au sujet, tandis que dans le deuxime cas, les fonctions sont plus gnrales. 14.2. CONCEPTION INDEPENDANTE DE LA TECHNOLOGIE Une solution complte inclut la fois des constituants dits fonctionnels et des constituants plus matriels que sont: capteurs, actionneurs, processeurs, mmoires, rseau de communication ... La deuxime catgorie est un support pour la premire catgorie. En conception, il faut tout d'abord trouver l'aspect fonctionnel pour ensuite dduire le support. Contrainte impose, une conception fonctionnelle se doit d'tre totalement indpendante de la technologie. L'avantage de cette approche est de concentrer son effort sur l'essentiel au dpart et de ne considrer les dtails technologiques qu'au dernier moment. Ceci converge avec l'approche oriente sujet. Pour le modle de l'approche SUJET, perception et action sont des fonctions ncessaires au systme qu'il ne faut pas confondre avec des interfaces physiques pour capteurs et actionneurs. M.C.S.E 285

Partie 4 - CONCEPTION FONCTIONNELLE Avantage supplmentaire, la solution tant indpendante de la technologie, une mme conception fonctionnelle peut servir comme point de dpart pour la recherche de plusieurs solutions technologiques. Ceci est ncessaire, par exemple, lorsqu'il s'agit d'optimiser les temps de ralisation, les cots de dveloppement et de reproduction, ou lorsqu'il devient souhaitable de revoir la ralisation par suite de progrs technologiques. Respecter ce principe ncessite de connatre les points que nous considrons comme dpendants de la technologie. Certains points sont vidents (interfaces lectriques par exemple) d'autres nettement moins. Il faut ensuite disposer de spcifications structures qui ne concernent que la partie fonctionnelle, et ne faisant pas tat des contraintes technologiques. Dans la suite de ce paragraphe, sont prsentes les catgories de fonctions ou contraintes dpendantes de la technologie. Ces catgories rsultent d'une longue exprience d'application de la mthodologie sur des problmes industriels avec des comparaisons de solutions qui incluaient ou pas ces caractristiques comme contraintes technologiques. 14.2.1. Fonctions d'interfaage avec l'environnement physique Toute fonction qui ne transforme pas une information, c'est--dire qui nassure pas un changement de sa nature, est une fonction dpendante de la technologie. C'est le cas en particulier de toutes les fonctions d'interfaage qui n'ont pour seul objectif qu'un changement de la reprsentation de l'information et non pas sa nature. Par exemple, lorsque pour un systme, la grandeur Vitesse V est une grandeur essentielle, et que le capteur est du type codeur incrmental, la fonction qui permet de disposer tout instant de V partir de l'vnement INC est une fonction technologique comme lindique la figure ci-dessous.
V

Chariot

Contrle Commande

Indpendant

Chariot + capteur

INC

Evaluation vitesse

Contrle Commande

Dpendant

-Figure 14.3- Indpendance/dpendance vis vis de la technologie. Retenons quune solution se trouve indpendante de la technologie, s'il est possible ultrieurement de mettre tout type de capteurs ou d'actionneurs sans modifier la solution fonctionnelle. Ceci est vrai, si les grandeurs considres 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 catgorie des interfaces. Mais il est intressant de les considrer sparment des prcdentes car l'entit correspondante est un utilisateur et pas un procd physique. Vis vis d'un utilisateur, le systme est ractif aux actions de l'utilisateur. Le couplage ncessite une fonction de nature interactive. Une fonction de dialogue pour un systme dfinit toute la convivialit du systme. Cette convivialit peut tre trs varie selon la technologie utilise et selon la forme du dialogue: - action sur des potentiomtres et observation sur des cadrans, - claviers et afficheurs, - terminal, - dialogue question-rponse, - langage de commande, - menus iconiques, - gestionnaire multi-fentres ... La forme du dialogue a des implications videntes sur la technologie (pas de possibilits de menus iconiques avec un simple terminal alphanumrique). En sens inverse, une technologie donne dlimite les possibilits de formes de dialogue. Pour qu'une solution fonctionnelle soit totalement indpendante de la technologie pour l'interface homme/machine, elle doit permettre de choisir toute forme possible de dialogue. Par la suite, aprs slection d'une forme, se dduira 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 considrer en entre que les informations globales ou vnements significatifs produits par l'utilisateur, et en sortie, celles que lui fournit le systme. Par exemple, il ne s'agit pas de descendre au niveau de la gestion de chaque caractre tap sur un clavier de terminal, mais au contraire il faut se placer au niveau des messages de commandes gnres par l'utilisateur. La figure 14.4 montre la possibilit de mettre tout dispositif de dialogue sans modifier la solution fonctionnelle: clavier-afficheur, terminal, systme d'analyse et synthse de parole ... 14.2.3. Rpartition gographique Avec la technologie du type microprocesseur, les systmes sont de plus en plus conus comme des systmes rpartis, c'est--dire, des fonctions rparties sur des processeurs diffrents coupls entre eux par un systme d'interconnexion. Lorsque la distance dpasse quelques mtres, le couplage entre processeurs se fait obligatoirement par une ligne de communication: bien souvent par une ligne srie, ou par un rseau local, ou par un rseau de tlcommunication. 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 rpartition gographique au niveau fonctionnel pour rechercher une solution adapte ds le dpart la topologie. M.C.S.E 287

Partie 4 - CONCEPTION FONCTIONNELLE

Indpendant

Dpendant

Utilisateur

Utilisateur

Touches

Affichage

Demandes

Rsultats

Gestion des touches

Prsentation rsultats

Demandes

Rsultats

Solution fonctionnelle

Solution fonctionnelle

-Figure 14.4- Indpendance/dpendance pour le dialogue. Pendant plusieurs annes, nous avions adopt ce point de vue sans avoir pens une autre faon de faire. Aprs avoir expriment la mthode en reportant la prise en compte de ce type de contrainte l'tape suivante de dfinition de la ralisation, nous avons constat une qualit intressante des solutions. Le rsultat s'explique. Si on considre au niveau fonctionnel la contrainte de rpartition, la solution est base sur des relations du type transfert de messages. Les messages se trouvent difficiles spcifier puisqu'ils dpendent de la rpartition des fonctions qui sont trouver. En recherchant d'abord les fonctions avec la contrainte de rpartition, il est difficile de dduire les changes strictement ncessaires entre les fonctions. Par contre, en ignorant cette contrainte, on recherche une solution fonctionnelle rpondant aux spcifications. Il est alors possible un stade ultrieur de dcider de la rpartition des fonctions compte-tenu des contraintes gographiques, puis de dduire les informations changer et les mcanismes de communication appropris. La figure 14.5 montre qu'il est ais d'introduire ensuite la rpartition gographique. Le mcanisme de communication choisie (liaison srie) n'assure que la mise jour de V" par suite d'une modification de V'. La solution rsulte d'une duplication gographique de V. 14.2.4. Maintenance, sret de fonctionnement Des fonctionnalits connexes pour l'application mais essentielles pour le systme peuvent apparatre dans les spcifications. Auto-tests, maintenance par exemple, sont des fonctions d'aide au diagnostic et au maintien en bon fonctionnement du systme. 288 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION

Indpendant
V V F1 F2 F1

Dpendant

V" F2

Emission message

Reception message

E_MESS

R_MESS

Emission ligne

Reception ligne

TxD

-Figure 14.5- Indpendance/dpendance vis vis de la rpartition. La sret de fonctionnement, qui inclut au moins les termes disponibilit, fiabilit, peut ncessiter l'ajout de fonctions supplmentaires: redondances matrielles, logicielles, fonctionnelles par exemple. Toutes ces fonctions sont prendre en compte un stade ultrieur, car faisant partie des contraintes technologiques. Pour la sret, elles se dduisent partir de la solution fonctionnelle par analyse des caractristiques de scurit, puis par ajout des redondances ncessaires pour satisfaire les critres imposs. L'exemple donn figure 14.6 montre l'ajout d'un auto-test la mise sous tension et la duplication d'un capteur de temprature pour fiabiliser l'observation. Des tats complmentaires sont ainsi ajouts au systme pour satisfaire les spcifications de nature technologique. 14.2.5. Importance des catgories de spcification La mthode prconise pour l'laboration des spcifications conduit inclure les caractristiques des interfaces physiques, le dialogue homme/machine, les contraintes de rpartition, les contraintes de sret dans les spcifications technologiques. Nous venons d'en donner la justification. Ainsi, l'utilisation exclusive des spcifications fonctionnelles favorise la conception d'une solution indpendante de la technologie. Toutefois, il ne faut pas confondre niveaux de dtails et dpendance technologique: une solution peut tre particulirement dtaille sur le plan fonctionnel sans toutefois exprimer des dpendances technologiques. M.C.S.E 289

Partie 4 - CONCEPTION FONCTIONNELLE

TEMP Environnement Traitement

Indpendant

DEFAUT

TM1 TEMP Environnement Observation TM TM2 ETAT_OK Traitement

Dpendant

Mise en marche Auto-Test

-Figure 14.6- Indpendance/dpendance vis vis de la sret et maintenance. 14.3. COMPLEXITE MINIMALE ET INDEPENDANCE Une solution pour un systme ou pour chaque fonction s'obtient par raffinement. Chaque dcomposition doit se faire en respectant une rgle de complexit maximale qui favorise la lisibilit et donc la comprhension. La rgle de 7 plus ou moins 2 prconise par plusieurs auteurs s'applique ici. Elle veut simplement dire qu'au del de 8 10 lments introduits dans un raffinement (fonctions + variables + ports + vnements) la solution devient difficilement comprhensible. Mais comme le raffinement est itratif, on peut obtenir en final une solution extrmement complexe par suite d'une multitude de niveaux. Il faut donc aussi disposer d'un critre d'valuation de la qualit de la solution lorsque celle-ci est compltement mise "plat", c'est-dire aprs retrait des niveaux. La complexit se doit d'tre minimale. Comment peut-on l'obtenir? La rponse n'est pas unique. 14.3.1. Orthogonalit ou cohrence des fonctions La rduction de complexit s'obtient en recherchant un ensemble orthogonal de fonctions, chacune ayant une fonctionnalit spcifique indpendante des autres. Chaque fonction exploite et produit alors des donnes indpendantes entre elles. L'indpendance rsulte du principe de l'encapsulation de sous-ensembles cohrents entre eux, ce qui conduit dfinir des objets ayant des fonctionnalits propres. La complexit pour un problme donn dpend aussi de la nature du problme. Lorsquil sagit dun problme de contrle, par exemple une automatisation, une approche base sur les donnes peut conduire une solution plus complexe qu'une approche base sur les vnements. 290 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION 14.3.2. Rduction des couplages L'analyse peut conduire mettre en vidence un ensemble de fonctions et de donnes. La construction d'une structure fonctionnelle partir de tout ou partie de ces lments donne diverses solutions qui dpendent des regroupements effectus. 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'indpendance des parties. La comprhension d'une partie de la solution est d'autant plus simple qu'elle se trouve peu lie aux autres parties. La complexit de chaque couplage dpend: d'une part de la nature du couplage -variable d'tat ou vnement-, d'autre part de la structure de l'information change. Un couplage par vnement ou par transfert de message est plus complexe qu'un couplage par variable, car il implique par la suite, dans la ralisation, une synchronisation des fonctions. Ce n'est pas le cas pour les variables. En final, une ralisation est d'autant plus simple que la partie organisationnelle reprsentant les couplages entre les fonctions autres que par variables est faible. La solution la plus intressante est celle qui conduit une partie organisationnelle la plus rduite. Ce point de vue sera dvelopp dans la partie suivante qui concerne la dfinition de la ralisation. La complexit de l'information dfinie par une variable ou un message influe aussi sur la comprhension de la solution. 14.4. DEMARCHE POUR LA DEDUCTION DUNE SOLUTION Dbutant un travail de raffinement, le concepteur est face une fonction dfinie uniquement par ses spcifications. A ce stade, cette fonction (plus ou moins complexe) est quivalente une "bote noire" quant sa structure interne: aucune information interne connue. Raffiner, c'est trouver une description interne comme solution rpondant aux spcifications. Cette solution doit de plus possder des qualits. Certaines ont t dtailles dans les paragraphes prcdents. Il s'agit donc d'une tche cratrice. Comment faut-il s'y prendre? Plusieurs dmarches sont possibles: intuition ou analyse, approche par les fonctions ou par les donnes, raffinement ou abstraction. 14.4.1. Analyse plutt qu'intuition Concevoir est un processus cratif. Aussi peut-on se baser sur son intuition pour proposer une solution. Celle-ci doit ensuite tre vrifie pour assurer sa conformit aux spcifications. Beaucoup d'erreurs seront probablement corriger et la justification des choix sera plutt difficile. Selon cette dmarche, avoir de l'exprience ou du "Mtier" est srement plus favorable car, trs sommairement, l'exprience se traduit par la connaissance de solutions pour des problmes type. Intuition et exprience ont tendance ne pas exploiter trs directement les spcifications, ce qui conduit invitablement des difficults. M.C.S.E 291

Partie 4 - CONCEPTION FONCTIONNELLE L'analyse est opposer l'intuition. Elle est base sur une lecture dtaille, une interprtation "fine" des spcifications, l'emploi d'une mthode. Il se trouve que, dans la plupart des cas, les informations ncessaires qu'il sagit de trouver pour proposer une solution sont dans les spcifications. En effet, spcifier c'est dtailler l'application. Or ces dtails sont indispensables en interne du systme car une partie de celui-ci est le reflet de l'application. Ainsi, l'analyse rduit peut tre le caractre cratif, mais conduit une probabilit leve de qualit de la solution, et ceci plutt indpendamment de la qualit du concepteur. En fait, lorsque les spcifications sont correctement labores, une grande partie du travail de rflexion et de synthse a dj t entreprise durant la phase de spcification. Evidemment les spcifications sont ncessaires pour une dmarche par analyse, ce qui n'est pas une condition ncessaire pour l'intuition. 14.4.2. Approche par les donnes plutt que par les fonctions Par analyse, que faut-il tout d'abord rechercher dans le document de spcifications? 2 dmarches sont opposer: - recherche des fonctions, puis des relations, - recherche des donnes, puis des fonctions. La dmarche par les fonctions est la plus conventionnelle et la plus naturelle. Ceci s'explique par le fait que pour dcrire une tche, notre raisonnement nous conduit naturellement faire apparatre une squence d'activits. Ceci est srement accentu avec l'informatique, car en programmation, les ordinateurs exigent que nous dcomposions un objectif atteindre en oprations plus lmentaires squentielles. Nous avons eu l'occasion de vrifier de multiples reprises auprs de concepteurs que, sans conseil particulier, ceux-ci proposent invariablement une dcomposition base sur les fonctions. Pour observer si une telle dmarche a t suivie, il suffit simplement de regarder la structure fonctionnelle propose. L'exemple suivant reflte une telle approche.

Prt E S

F1
V1

F2

-Figure 14.7- Exemple de structure fonctionnelle base sur les fonctions. Pour cette solution, en rsultat 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 squentielles, la fin du traitement par F1 se traduit par la production de V1. L'vnement PRET s'avre strictement ncessaire pour que F2 ne prenne en compte V1 que lorsque celle-ci est disponible aprs son dpt par F1. La relation squentielle pouvait ici s'exprimer par un transfert de message contenant V1 en utilisant un port comme intermdiaire. 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 dmarche suivie par le concepteur. La dmarche par les variables et donc par les relations plutt que par les fonctions, donne un rsultat bien diffrent. Pour la fonction raffiner, le concepteur doit rechercher une ou des variables internes strictement ncessaires pour exprimer une solution. Ces variables se dduisent par lecture et interprtation des spcifications. Une fois trouve au moins une variable, il faut ensuite dduire 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.

F3
V2

F4

-Figure 14.8- Exemple de structure fonctionnelle base sur les variables. La variable V2 n'a rien voir avec la variable V1 de la figure prcdente de mme 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 comprhension puis par la suite l'implantation. Cette approche ne conduit pas une solution squentielle mais une solution possdant un paralllisme naturel. Or c'est bien l'objectif d'une structure fonctionnelle que d'exprimer un paralllisme, sinon la dcomposition ne s'avre pas ncessaire. Ainsi, cette mthode de dcomposition par les donnes devra tre utilise pour aboutir une solution simple. 14.4.3. Raffinement plutt qu'abstraction Le modle fonctionnel est hirarchique. Une solution peut aussi bien s'obtenir par composition de fonctions plus lmentaires que par dcomposition. Mme si la dmarche purement descendante est difficile, la recherche de solutions par raffinement est prfrable la dmarche ascendante par regroupement. En effet, la solution recherche doit satisfaire une spcification. Dans la dmarche descendante, chaque fonction dcomposer est dfinie par une spcification; par analyse, le travail de dcomposition est simple et la vrification est aussi possible. Selon une dmarche ascendante, l'abstraction conduit identifier une fonction par regroupement de fonctions plus lmentaires. Elle peut alors se dcrire par sa spcification. C'est une dmarche qui ne part pas de l'objectif, mais qui cherche converger vers l'objectif, ce qui est moins simple et probablement conduit plus d'hsitations 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 retoursarrires restent ncessaires pour corriger des erreurs d'analyse dtectes par la suite. 14.5. DECOMPOSITION VERTICALE OU HORIZONTALE Le modle fonctionnel est hirarchique. Ainsi, chaque fonction non-lmentaire se dcrit par une structure fonctionnelle. Dans ce travail de raffinement, la structure fonctionnelle retenue peut correspondre 2 types de dcomposition [ROTENSTREICH-86]: - une dcomposition horizontale, - une dcomposition verticale. La dcomposition dite horizontale est la plus habituelle. Elle revient considrer que toutes les fonctions du raffinement participent sur un mme niveau fonctionnel la ralisation de la fonction du niveau suprieur. Les relations entre les fonctions ont la mme signification que l'organisation fonctionnelle dans les entreprises. Chaque fonction contribue sur le mme plan l'obtention du rsultat. Les relations expriment les transformations des entres vers les sorties.

E F

V1 F3 F1 E Ev F2 V2 S

-Figure 14.9- Reprsentation dune dcomposition horizontale. Toutes les fonctions de F sont reprsentes dans un mme plan horizontal. Les classes de fonctions pour cette dcomposition, assurent: - la structuration par enrichissement (ajout de nouvelles fonctionnalits) ou dduction de fonctionnalits plus lmentaires, - l'introduction de vues moins abstraites de la solution. La dcomposition verticale correspond une relation hirarchique. Pour assurer son rle, une fonction peut avoir besoin de services d'un niveau hirarchique infrieur. Les fonctions sont plutt du type adaptation pour satisfaire une contrainte. Par exemple, une fonction de transmission de messages doit utiliser un service de transmission de caractres. Cette dcomposition peut se reprsenter comme suit, qui montre que les relations se reprsentent 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- Reprsentation d'une dcomposition verticale. Il ne faut pas confondre les niveaux du raffinement qui nont de signification que pour la prsentation favorisant ainsi la lisibilit, et les niveaux d'une dcomposition verticale qui correspondent des services de natures diffrentes. 14.6. MODELES GENERIQUES DE SOLUTIONS Face une tche de raffinement, le concepteur, mme aprs analyse, dispose de degrs de libert importants pour proposer une solution. Au travers de l'analyse, il peut aussi prouver des difficults extraire les lments essentiels. L'approche par les variables n'est en plus pas tout fait naturelle. Peut-on contribuer amliorer la qualit du travail de conception en plus des principes noncs prcdemment? Il est indniable que naturellement, le concepteur travaille par analogie. Lorsqu'il a dj trait un problme similaire, ou lorsqu'il dispose de solutions, il cherche, ce qui est tout fait louable, rutiliser l'existant. Ceci est une forme de ce qui peut s'appeler l'EXPERIENCE. Partant de ce point de vue, nous nous sommes demands s'il n'tait pas possible, par analyse d'une grande varit de solutions obtenues par application de la mthodologie MCSE, de mettre en vidence un certain nombre de solutions gnrales. Ces solutions sont comprendre comme des modles gnriques de solutions. Un modle est appropri une classe de problmes et un niveau donn de fonctionnalits. Il permet d'induire une collection de solutions, chacune personnalise aux spcificits de l'application traite, mais possdant toutes les proprits et qualits du modle. Ce n'est pas l'objectif de ce paragraphe que de dcrire les modles gnriques recenss, ceci fait l'objet du chapitre 16. Toutefois, pour saisir l'ide, prenons l'exemple du modle gnrique qu'est la Machine de MOORE pour la conception de fonctions numriques. M.C.S.E 295

Partie 4 - CONCEPTION FONCTIONNELLE Face au problme de conception d'une fonction numrique spcifie par un diagramme tats finis, plutt que de rechercher une solution intuitive, le concepteur va s'inspirer de la structure de la machine de MOORE. Le modle lui suggre de rechercher la variable interne strictement ncessaire qu'est l'tat interne. Cet tat interne est dfini directement par la spcification: tat du diagramme tats finis par exemple.
Fonction concevoir
Ev

Spcification

Modle gnrique
CLK

Spcification de VI

VI F1 F2

VI Et

Reg

St F1 F2

Solution

-Figure 14.11- Exemple d'apport d'un modle gnrique. Une fois trouve cette variable interne, la structure fonctionnelle tant dfinie par le modle gnrique, le travail de conception se trouve ramen la rsolution de 2 problmes combinatoires: fonction combinatoire d'entre ou rceptivit, fonction combinatoire de sortie ou d'action, chacune tant alors spcifie par la table de transition. La recherche de ces modles nous a permis d'en formaliser plusieurs et de les exprimenter auprs de groupes de concepteurs. L'exprience de comparaison des rsultats est simple. Elle consiste comparer les solutions produites avec et sans la connaissance de modles gnriques. Nous-mmes avons pu comparer pour des mmes problmes les solutions proposes avant l'emploi des modles et plus tard avec ces modles. Les rsultats obtenus jugs sur les critres: adquation aux spcifications, simplicit et lisibilit, sont nettement en faveur de l'emploi de modles gnriques. Ceci s'explique puisque ces modles sont des gnrateurs d'ides et de "bonnes" questions. 14.7. RESUME En synthse de ce chapitre qui a permis de mettre en vidence diffrentes alternatives en conception fonctionnelle, sont reprises les conclusions essentielles suivre: - la conception doit tre guide par le sujet de l'application. Cette approche favorise la dmarche de dcomposition des entres vers les sorties (dcomposition horizontale). - une conception fonctionnelle doit tre indpendante de la technologie. Pour cela, il ne faut utiliser que les spcifications fonctionnelles. Les problmes d'interfaage avec l'environnement et avec les utilisateurs, les contraintes de rpartition gographique, ne sont pas prendre en compte ce stade. 296 M.C.S.E

Ch 14 - PRINCIPES EN CONCEPTION - la solution fonctionnelle doit possder des qualits de simplicit pour sa comprhension et sa ralisation. Pour cela, il faut chercher rduire la complexit en nombre et nature des fonctions et des relations. Effectuer pour cela une approche base sur l'orthogonalit et la cohrence des fonctions et des donnes. - par analyse des spcifications, la dduction d'une solution doit se faire en recherchant des informations (variables, vnements) internes strictement ncessaires pour exprimer la solution et ceci selon une dmarche descendante par raffinement. - le concepteur pourra s'inspirer de modles gnriques de solutions comme guide pour le travail d'analyse et de synthse.

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 complte conforme aux spcifications et possdant des qualits qui auront des rpercussions favorables sur l'ensemble du cycle de vie du produit. Les applications dvelopper, exprimes par leurs spcifications, sont forcment varies. Pour une application donne dcrite par une spcification prcise, les solutions peuvent aussi tre trs diverses. Le travail de conception tant essentiellement un processus cratif, le rsultat est une expression de la rflexion du concepteur. Une production de solution selon un processus automatique n'est pas pour tout de suite; il faudrait au pralable arriver formaliser compltement toutes les rgles de production. En rsultat de la conception, l'important est le document qui en final dcrit la solution et pas le cheminement suivi par le concepteur [PARNAS-85]. Toutefois, le rsultat est d'une certaine manire le reflet des principes et dmarche suivis. Ainsi, la COMPETENCE et la RIGUEUR de REFLEXION du concepteur restent des facteurs importants d'influence sur la qualit du rsultat. Ce chapitre a pour objectif de dtailler la dmarche prconise, de manire aider le concepteur acqurir cette comptence et la rigueur de rflexion. Cette dmarche explicite l'enchanement des dcisions prendre pour s'assurer d'un rsultat de qualit. Disposant du modle fonctionnel, la dmarche est la juxtaposition de phases, chacune servant dduire une composante du modle. Les principes en conception noncs dans le chapitre prcdent servent dfinir les conseils pour chaque phase.

M.C.S.E

299

Partie 4 - CONCEPTION FONCTIONNELLE Le bien fond d'une dmarche ne se prouve pas formellement. Il rsulte plus d'une observation faire sur les exprimentations. Pour cela, il faut traiter une varit de problmes industriels, et par analyse, dduire les apports et difficults. L'laboration d'une dmarche est donc trs lente et rsulte d'une synthse selon une progression ascendante. 15.1. PRESENTATION DE LA DEMARCHE La deuxime tape appele conception fonctionnelle a pour objectif de produire une description fonctionnelle complte du systme concevoir. Conforme au modle, cette description doit tre compose: - d'une structure fonctionnelle, - des spcifications comportementales de toutes les fonctions lmentaires, - des spcifications de toutes les donnes. Les documents considrer en entre sont les spcifications fonctionnelles et opratoires. La figure ci-dessous symbolise cette tape.
Modle fonctionnel

Spcifications fonctionnelles et opratoires

ETAPE DE CONCEPTION FONCTIONNELLE

Document de conception fonctionnelle

Modles gnriques

-Figure 15.1- L'tape de conception. La dmarche prconise procde par raffinements successifs de chaque fonction, le point de dpart tant le systme dans sa globalit, dlimit par ses entres et ses sorties. Le processus de raffinement s'arrte lorsque chacune des fonctions peut se dcrire par une modlisation comportementale squentielle. Les donnes sont spcifies au fur et mesure de leur apparition pour chaque niveau de raffinement. Ainsi la dmarche reprsente figure 15.2 consiste suivre les phases suivantes: 300 dlimitation des entres et sorties du systme, recherche d'une premire dcomposition fonctionnelle, raffinement de chaque fonction (itration sur cette phase), comportement de chaque fonction lmentaire, synthse de la solution globale. M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

Document de spcifications Dlimitation des entres sorties

Premire approche fonctionnelle

premire dcomposition fonctionnelle

Raffinement fonctionnel

Description algorithmique

Raffinement et description des fonctions


Document de conception fonctionnelle Structure fonctionnelle finale

Synthse

-Figure 15.2- Enchanement des phases pour la conception fonctionnelle. Comme le modle fonctionnel est hirarchique, le premier niveau de la dcomposition fonctionnelle est trs important, car il induira par la suite toute la structure de la solution. Il faut donc apporter un soin particulier pour cette premire approche de la solution. Le raffinement fonctionnel de chaque fonction est un processus itratif qui peut se faire selon un ordre a priori quelconque pour les diffrentes branches de la hirarchie. Toutefois, il est toujours conseill de s'attaquer d'emble aux fonctions les plus difficiles plutt que l'inverse. En effet, la solution trouve pour une fonction complexe peut avoir des rpercussions sur son environnement. Une fois toutes les dcompositions ralises, une synthse globale se justifie pour s'assurer de la cohrence de l'ensemble. Il est vrai qu'une dmarche purement descendante est trs difficile suivre. Des retours-arrires et corrections sont invitables en cours de conception. D'o la ncessit de revoir l'ensemble. Le document produit en sortie rsulte de cette synthse. Pour chaque phase de raffinement, le concepteur doit procder selon 3 phases: - analyse: il s'agit de faire apparatre les lments essentiels partir des spcifications, - construction: ce travail de synthse propose une solution sur la base des lments mis en vidence par l'analyse. Plusieurs solutions sont envisageables, la slection est alors base sur divers critres, - vrification: elle consiste s'assurer que la solution retenue pour la fonction rpond aux spcifications du systme. Si au pralable du raffinement une spcification est exprime, le travail de vrification se trouve facilit. M.C.S.E 301

Partie 4 - CONCEPTION FONCTIONNELLE La phase de vrification peut faire apparatre des oublis qui sont corriger en revenant sur la phase prcdente de construction. Si la dmarche est trop incrmentale ou trop intuitive, la solution rsulte plus d'un processus d'essais et corrections d'erreurs. Elle rsulte d'une insuffisance de la phase d'analyse. Dans ce cas, une fois lucids tous les problmes, il est judicieux de reprendre globalement la construction puis la vrification pour amliorer la solution. Chaque phase de la mthode est dtaille dans les paragraphes suivants. Au pralable, des prcisions sont donnes sur les informations en entre de l'tape et le rsultat attendu. 15.2. DOCUMENTS EN ENTREE ET EN SORTIE DE LETAPE Le travail de conception, tout comme celui de spcification, consiste laborer un document papier. Evoquons le contenu des documents en entre et en sortie. 15.2.1. Document de spcification Pour l'tape de conception, les parties utiles du document de spcification sont: - la dlimitation systme/environnement, - les spcifications fonctionnelles, - les spcifications opratoires. La dlimitation du contexte du systme permet de dduire une dlimitation du systme avec ses entres et ses sorties. Les changes entre les 2 parties sont de nature logique ou fonctionnelle, et pas physique. Les spcifications fonctionnelles dfinissent les fonctions du systme pour le sujet de l'application. Il s'agit donc de renseignements orients sujet, et donc favorables pour une conception oriente sujet. Le rle de chaque fonction est explicit par un ou des modles de spcification exprimant le comportement des entits de l'environnement (donc du sujet). Les spcifications opratoires explicitent les grandeurs, les donnes, ainsi que leurs attributs. Si une mthode de rsolution du problme est suggre ou impose, elle se trouve dcrite dans cette partie des spcifications. Ces 3 catgories d'informations n'incluent aucun renseignement de nature physique ou technologique. Un tel document favorise donc l'approche oriente sujet d'une part, l'approche oriente donnes plutt que fonctions d'autre part, car il n'est pas fait tat des fonctions internes, mais uniquement des fonctionnalits pour l'application. 15.2.2. Document de conception Fort probablement la dmarche ne sera pas totalement linaire et descendante. Le document de conception doit exprimer le rsultat, et ceci de manire linaire et descendante. Pour l'exploitation ultrieure, la comprhension et l'acceptation de la pertinence des solutions, seul le rsultat est important. Ainsi le document de conception ne suit pas le droulement temporel des dveloppements entrepris par les concepteurs. C'est une synthse hirarchise et logique dcrivant la solution qui n'a de cohrence qu'une fois acheve la synthse globale. Pour chaque raffinement, on doit retrouver en plus de la description complte de la solution, l'analyse qui a conduit diverses alternatives, les critres de dcision 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 rflexions du concepteur. Ceci permet pour d'autres applications une certaine rutilisation du travail entrepris, pour le concepteur luimme, mais aussi et peut-tre surtout pour la formation de nouveaux concepteurs. Si le document est le rsultat de la synthse, celui-ci se doit toutefois d'tre construit au fur et mesure du dveloppement. Non-ordonns avant le stade final, les points importants sont mmoriss au fur et mesure. Sinon, chacun sait que le temps assure un effet d'oubli conduisant alors une vision particulirement limite et donc un document sans valeur. Le travail de synthse consiste donc ordonner tous les lments de la conception, liminer les parties inutiles et les retours-arrires qui furent ncessaires pour les corrections, introduire une cohrence pour l'ensemble. 15.3. DELIMITATION DES ENTREES ET SORTIES Il s'agit tout d'abord de dfinir avec prcision la sparation entre le systme concevoir et les entits de son environnement. Les entits sont reprsentes par des formes en "nuage", tandis que le systme est reprsent par un rectangle. Le couplage entre les 2 parties se fait uniquement par les 3 types de relations du modle fonctionnel comme le montre lexemple ci-dessous.

Ordre

Reaction

E1
SYSTEME A

E1

CONCEVOIR INC

E2

E2

-Figure 15.3- Exemple de dlimitation du systme. 15.3.1. Dmarche Les observations possibles sur les entits peuvent servir d'entres pour le systme. De mme, aux grandeurs de commande pour les entits vont correspondre des sorties du systme. Observations et grandeurs de commande apparaissent dans les spcifications. Ces grandeurs sont de nature fonctionnelle et non pas physique lorsque les spcifications sont correctement tablies. Il faut ensuite dfinir le type de relation. Le choix dcoule de la nature des grandeurs. Les rgles suivre sont simples: - Lorsque seul un changement d'tat d'une variable ou d'une grandeur est utile, la relation est du type vnement. - Lorsque l'apparition d'une information et son contenu sont considrer simultanment, la relation est du type transfert de messages. - Lorsque la valeur d'une information est ncessaire 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 dduit aussi de la spcification. Par exemple, un lien du type flot de donnes conduit une relation par port. Pour complter la dlimitation, chacune des variables d'tat et chaque type de messages doivent tre spcifis. A noter que cette phase peut conduire oublier des entres comme observations ncessaires pour satisfaire les spcifications. Normalement, ces observations sont utilises dans les spcifications, par exemple comme condition de transition. Un tel oubli sera probablement dtect au plus tard au moment des dcompositions fonctionnelles. Un retour arrire permettra alors d'assurer la correction. Pour favoriser la lisibilit, toutes les entres du systme sont places gauche, les sorties droite. Des entres et sorties de nature identique, provenant de plusieurs instances d'un mme type d'entit peuvent se reprsenter par un vecteur. Illustrons cette phase par les 2 exemples spcifis dans la partie 3. 15.3.2. Exemple 1: Contrle en vitesse d'un centrifugeur La spcification pour cet exemple est rappele ci-dessous. Voir les spcifications dans le chapitre 12 en 12.6.4 comme rappel du problme.
Systme pour lutilisateur Systme + Moteur

Repos dbut cycle T:=0

Repos

Vmoteur = 0 Erotation = arrt

ORDRE ORDRE ? marche /si Erotation = arrt alors dbut cycle; arrt /si Erotation = rotation alors arrt cycle; consigne /si Erotation = arrt alors Vrot:=consigne;

CV tel que Vmoteur = Vrot * T Erotation = rotation AcclraTm tion T >= TM T:=0 CV tel que Vmoteur = Vrot vitesse constante arrt cycle Vm:=Vmoteur; T:=0;

T>= TC ou arrt cycle T:=0; Vm:=Vmoteur; dclraCV tel que tion Vmoteur = Vm - Vrot * T TD Vmoteur # 0

Couplage

-Figure 15.4- Spcification fonctionnelle pour la commande du moteur. Analysons cette spcification pour dduire les entres, les sorties et les types de relations. L'utilisateur gnre les vnements que sont MARCHE et ARRET et fournit lorsqu'il le dsire une nouvelle consigne de vitesse (CONSIGNE). Le couplage doit tre du type vnementiel avec transfert de donnes 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 caractris par sa commande CV et sa vitesse de rotation VMoteur. Ce sont des variables d'tat. La dlimitation des entres-sorties du systme est donc la suivante :

VROTATION Ordre Utilisateur SYSTEME A CONCEVOIR EROTATION Utilisateur

VMOTEUR Moteur

CONTROLE EN VITESSE DUN CENTRIFUGEUR

CV Moteur

-Figure 15.5- Dlimitation du Systme pour le contrle en vitesse. Pour complter cette phase, toutes les variables doivent tre spcifies: ORDRE = [MARCHE | ARRET | CONSIGNE: 0..VMAX]; VROTATION : 0..VMAX; EROTATION : (rotation, arrt); VMOTEUR : 0..VMAX; CV : 0..CVMAX; Le couplage entre l'utilisateur et le systme est de nature fonctionnelle et non pas physique. Il tait possible de considrer ds le dpart les organes physiques mis la disposition de l'utilisateur pour agir sur le systme: boutons-poussoirs MARCHE, ARRET, PLUS et MOINS pour le rglage de la consigne. L'intrt de la solution retenue ici est de pouvoir changer par la suite la nature du dialogue: remplacer les touches + et - par un clavier numrique, mme par une liaison srie pour une commande distance. 15.3.3. Exemple 2: Automatisation par chariot filoguid Les spcifications pour ce problme ont aussi t dcrites dans le chapitre 12 en 12.10.2. Quatre entits ont t recenses dans l'environnement: - le QUAI en tant que donneur d'ordre, - le CHARIOT comme ensemble mcanique assurant le dplacement et le chargement, - l'ATELIER comme support sur lequel se dplace le chariot, - l'EXPLOITANT charg de la bonne marche de l'installation. Pour ce problme, on s'intressera uniquement au chariot et son lectronique de commande. La seule fonction du systme de commande du chariot est de raliser les cycles de transfert des paquets entre les 2 quais. Le lecteur doit se reporter au chapitre 12 pour reprendre connaissance des spcifications du problme. M.C.S.E 305

Partie 4 - CONCEPTION FONCTIONNELLE Partant des entits, analysons la spcification de manire dduire les entres et les sorties du systme lectronique concevoir. Le QUAI est gnrateur d'vnements qui sont des ordres pour le chariot. En rponse, il est sensible aux ractions du chariot. Les ordres et compte-rendus ncessaires apparaissent sur la spcification, 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 mcanique qui assure le dplacement, est command pour le dplacement, 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 linstant il n'est pas fait tat d'observations sur le chariot. L'ATELIER dfinit 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 vits. L'information OBSTACLE en proximit du chariot et sur sa trajectoire est ncessaire pour le bon fonctionnement. En fonctionnement normal, l'EXPLOITANT n'a pas d'action directe sur le systme de commande du chariot. Celui-ci n'est pilot que par le quai. Par contre, si un incident apparait obstacles, pas de rponse du quai ou du chariot - l'exploitant est prvenu par une sirne. Il repositionne alors le chariot et rinitialise le systme de commande. Une analyse complmentaire est faire partir de la spcification, savoir que toutes les conditions de transition autres que des valuations possibles par le systme doivent tre fournies par l'environnement et donc par les entits. On trouve en particulier les tats ou vnements: prsence_quai, proximit_quai. Ces 2 observations sont ncessaires pour la ralisation du systme. Elles proviennent de l'atelier. Toutes les autres conditions sont des ordres, ou des comptes-rendus, ou des conditions temporelles. La dlimitation du systme avec ses entres-sorties est donne figure 15.6. Pour complter cette phase, toutes les variables et messages sont spcifier. ORDRE = [I_PRESENCE | CHARGEMENT | TRANSPORT | DECHARGEMENT]; CR= [OK_PRESENCE]; OBSTACLE, SON_SIRENE : boolen; C_TAPIS : (arrt, arrire, avant); DCA : -Dmax..+Dmax; Il est vident que des informations de couplage manquent entre le chariot et le systme de commande. La dmarche volontairement suivie dans ce chapitre montrera que ces manques apparatront ds 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- Dlimitation du systme de commande du chariot. 15.4. RECHERCHE DUNE PREMIERE DECOMPOSITION FONCTIONNELLE Jusqu' ce stade, aucune information interne au systme n'est connue. Le concepteur doit commencer proposer les premiers lments fonctionnels ncessaires pour rsoudre le problme. Rappelons les points essentiels pour entreprendre ce travail. Tout d'abord, la solution propose doit tre conforme au modle fonctionnel, et plus particulirement au modle de structure fonctionnelle puisque fort probablement une dcomposition est ncessaire. Le modle tant hirarchique, il faut limiter chaque dcomposition une solution comprhensible. Ensuite, l'approche doit tre oriente sujet. La dmarche propose de rechercher des variables, informations, vnements, internes strictement ncessaires, plutt que de rechercher des fonctions internes. La solution doit rester indpendante de la technologie. Mais attention, la premire dcomposition est trs importante et a une influence considrable sur le reste du dveloppement et donc par incidence sur l'ensemble du cot du projet. Dtaillons plus particulirement ce point avant de prsenter la mthode de recherche d'une solution selon les 3 phases: analyse, construction, vrification. 15.4.1. Importance de la premire dcomposition fonctionnelle La dmarche prconise est globalement descendante. Ainsi chaque niveau de description est dtaille en raffinant chacune des fonctions du niveau prcdent. Ceci dcoule de la nature hirarchique du modle. Cette technique s'applique pour la conception fonctionnelle, mais aussi en partie pour la dfinition de la ralisation, tout particulirement pour l'introduction des interfaces et de la rpartition gographique. Les implantations matrielle et logicielle rsultent de transformations appliques sur la solution fonctionnelle dtaille. M.C.S.E 307

Partie 4 - CONCEPTION FONCTIONNELLE Bien entendu, des corrections de solution et retours-arrires sont toujours possibles lorsque des dfauts ou erreurs apparaissent: incohrence, non-respect des spcifications. Toutefois, il faut tre conscient que la technique de raffinement tend conserver la structure de dpart. Ainsi, une fois la premire dcomposition fonctionnelle choisie, celle-ci va se retrouver dans la solution finale. Ce premier choix est donc particulirement important et va influencer la complexit du projet et donc son cot. Comme la solution pour une premire dcomposition est loin d'tre unique, il est utile de disposer d'un critre d'valuation de sa qualit, qui tient compte des consquences en aval. Un tel critre n'est pas simple exprimer. Intressons-nous au produit final pour esquisser un tel critre. La ralisation dans les cas les plus usuels est compose d'une partie matrielle et d'une partie logicielle. Le cot pour la partie matrielle dpend de la quantit produire: - de nombreuses pices: intrt de rduire le cot de reproduction en minimisant le matriel. Ceci s'obtient en reportant le maximum de fonctionnalits sur la partie logicielle, - quelques installations: intrt de rduire le temps de dveloppement la fois pour le matriel et pour le logiciel. Ainsi la minimisation de la complexit fonctionnelle favorise la minimisation du cot pour le matriel. Le cot pour la partie logicielle peut se dcomposer en 2 parties: - la partie OPERATOIRE, qui regroupe toutes les oprations ncessaires pour satisfaire l'application. Cette partie opratoire se trouve minimise si les descriptions algorithmiques des fonctions sont labores avec soin et sans redondance. On peut considrer dans ce cas que cette partie est relativement imcompressible. - la partie ORGANISATIONNELLE, qui assure le couplage entre tous les modules, fonctions, procdures logicielles. Cette partie rsulte de transformations appliques sur la structure fonctionnelle. Ainsi, cette partie sera le reflet de la complexit fonctionnelle. La rduction du dveloppement pour le logiciel passe donc essentiellement par la rduction au maximum de la partie organisationnelle, ce qui implique de rduire au moins ds le dpart la complexit fonctionnelle. La complexit dpend de la nature des relations fonctionnelles. Les relations par partage de variables n'engendrent pas de "cot" organisationnel, contrairement aux relations par synchronisation et transfert de messages qui elles engendrent des dpendances temporelles. Ainsi, l'objectif pour le critre de qualit consiste utiliser comme couplage entre les fonctions, de prfrence les couplages par variables plutt que les couplages par synchronisation et transfert de messages par port. Ce raisonnement est tenir pour tous les niveaux de raffinement. La rpercussion est d'autant plus importante qu'il s'agit des tous premiers niveaux dfinissant l'architecture globale de la solution. 15.4.2. Dmarche pour laborer une solution Plutt que de se fier son intuition, il est suggr de procder en 3 temps: analyse, laboration d'une solution (ou de plusieurs) par construction, vrification. 308 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE


-A- ANALYSE

L'analyse consiste exploiter les spcifications et extraire de celles-ci les lments essentiels qui peuvent tre utiles pour la solution. Une lecture attentive permet d'extraire: des mots, des phases, des actions, des vnements, des donnes. Une classification par ordre d'importance conduit affiner l'analyse. Des modles d'analyse sont aussi utilisables pour cette tche. On peut citer tout particulirement la mthode "Structured Analysis" base sur les diagrammes flots de donnes. Un tel modle est alors utilis pour exprimer les transformations successives pour passer des entres aux sorties. Les informations intermdiaires apparaissent alors comme utilisables pour exprimer la solution. L'analyse doit tre conduite de manire rechercher les donnes et les vnements strictement ncessaires, plutt que les activits, oprations, fonctions qui, elles, dcoulent des prcdentes.
-B- CONSTRUCTION

Une solution s'labore en plaant des lments caractristiques dans la partie raffiner. Si l'analyse est oriente donnes, les lments placer sont des variables ou des vnements avec ou sans information. Comme ces lments 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 complter la structure fonctionnelle de manire utiliser toutes les variables d'entre et toutes les variables de sortie. Si certaines apparaissent inutiles, le niveau suprieur doit tre revu. Enfin, tous les constituants doivent tre correctement nomms, puis spcifis. En particulier, la spcification de chaque fonction servira ensuite comme document d'entre pour son raffinement. Ainsi cette dmarche de construction incrmentale par les variables est simple et conduit une faible complexit de chaque raffinement. En effet, il suffit de trouver une seule variable, un vnement, ou une information pour exprimer une solution. Ce seul lment va induire obligatoirement par sa relation au moins 2 fonctions. Le bon choix de l'lment apparait donc essentiel, d'o l'importance de la phase prcdente d'analyse. Comme la solution est loin d'tre unique, il est conseill d'envisager plusieurs dcompositions fonctionnelles. Le choix d'une solution parmi l'ensemble est alors bas sur le critre dcrit dans le paragraphe prcdent. Si le choix ne s'avre pas vident, il est souhaitable de conduire le raffinement de chaque solution jusqu'au stade o une solution se dgage comme tant la meilleure. Durant la conception fonctionnelle, il ne faut pas non plus hsiter mettre en cause sa solution, car le gain sur le reste du dveloppement peut tre tout fait notable.
-C- VERIFICATION

Une fois exprime une solution, il faut s'assurer qu'elle va permettre de satisfaire les spcifications. L'affirmation: la solution satisfait les spcifications, n'est pas possible, puisque en cours de raffinement, tous les lments de la solution ne sont pas encore identifis et spcifis. La vrification complte qui peut garantir, alors appele validation, n'est possible qu' la fin de la conception fonctionnelle. M.C.S.E 309

Partie 4 - CONCEPTION FONCTIONNELLE La vrification prconise ici, consiste liminer les erreurs flagrantes qu'il faut viter de propager. Pour cela, il s'agit de s'assurer: que toutes les entres et sorties sont utilises, que les relations entre les fonctions sont de type correct, que chaque fonction compte-tenu de son caractre permanent ou temporaire est capable de produire ses sorties partir de ses entres. Une vrification faite par une personne autre que le concepteur lui-mme est aussi un bon moyen pour rduire les erreurs. Ceci justifie l'intrt du cycle Auteur-lecteurs applicable pour tout document. Illustrons la dmarche en 3 phases sur les 2 exemples traiter. 15.4.3. Exemple 1: contrle en vitesse dun centrifugeur
-A- ANALYSE

L'analyse porte sur l'observation des caractristiques que doivent suivre les entits de l'environnement (approche sujet). C'est le cas du moteur qui va tre contraint par le systme, et pas l'utilisateur qui lui est le donneur d'ordres. Le moteur doit respecter un profil de vitesse quelle que soit la charge entraine. La consigne de vitesse fixe par l'utilisateur est donc une grandeur essentielle pour l'application. Le couplage entre les entits: l'utilisateur et moteur, se fait dans un sens par les vnements Marche et Arrt, dans l'autre sens par l'tat Rotation ou Arrt du moteur.
-B- CONSTRUCTION

L'analyse a mis en vidence des lments essentiels qui peuvent se traduire par 3 variables: - CROTATION: 0..VMAX, pour la consigne de vitesse demande (VROT dans la spcification), - M/A: (Marche, Arrt), qui permet d'induire les 2 vnements Dbut_cycle et Arrt_cycle, - ETAT : (Rotation, Arrt), comme observation de l'tat du moteur. La structure fonctionnelle ci-dessous est labore autour de ces 3 variables.

VROTATION ORDRE GESTION CENTRIFUGEUR

M/A

ETAT

CROTATION

EROTATION

VMOTEUR CONTROLE VITESSE CV

Contrle en vitesse centrifugeur

-Figure 15.7- Premire dcomposition fonctionnelle. 310 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE


-C- VERIFICATION

Il s'agit de parcourir la spcification 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 Arrt en fin de cycle, ce qui justifie le lien bidirectionnel. La solution pour cet exemple reste relativement macroscopique, puisque les 3 phases acclration, vitesse constante, dclration n'apparaissent pas. Le raffinement doit rester trs incrmental pour favoriser la qualit. 15.4.4. Exemple 2: Automatisation par chariot filoguid
-A- ANALYSE

En partant des entits, on trouve une certaine similitude de comportement entre le chariot et le moteur de l'exemple prcdent. Il faut respecter un profil de vitesse avec phase d'acclration, vitesse constante, phase de dclration. 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 catgories de phases: dplacement et les autres. Chaque dplacement est caractris par les instants de dbut et de fin .
-B- CONSTRUCTION

De cette analyse, et au vu de l'exemple prcdent, 2 variables sont ncessaires: - M/A: (MARCHE, ARRET), pour dclencher ou arrter un dplacement - ETAT: pour synthtiser toutes les informations concernant le dplacement. La structure fonctionnelle propose est donne figure 15.8. La partition en 2 fonctions n'est pas unique. Les fonctionnalits de ces fonctions diffrent selon les entres utilises pour chacune: par exemple les variables OBSTACLE et POSITION_QUAI au niveau de la SUPERVISION plutt que lies la partie commande conduisent un rle diffrent des fonctions. La commande C_TAPIS est lie SUPERVISION. Sinon, il faut des informations de couplage supplmentaires.
-C- VERIFICATION

Vu la simplicit de l'interface entre les 2 fonctions la vrification est aise. Le blocage du dplacement, par suite d'un cart par rapport la trajectoire ou par un obstacle, est signal SUPERVISION par la variable ETAT. Cette variable est donc dfinie 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- Premire dcomposition 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 dplacement correct, les vitesses des 2 roues VM1 et VM2 sont des informations strictement ncessaires. Elles sont ajouter comme entres du systme. Ceci montre les retours-arrires possibles pour ajuster la dlimitation des entres/sorties. De mme, l'arrt du chariot en face du quai ncessite de connatre la position relative du chariot au quai. 3 tats sont suffisants: loin, approche, prsence. Cette entre appele POSITION_QUAI est donc ajouter. 15.5. RAFFINEMENT FONCTIONNEL Une fois obtenu le premier niveau de la structure fonctionnelle, la dcomposition doit tre poursuivie pour chaque fonction. Le raffinement doit tre suffisant pour aboutir des fonctions lmentaires simples, tout en se limitant au ncessaire. 15.5.1. Critre d'arrt pour le raffinement Rappelons qu'une structure fonctionnelle exprime l'volution parallle de ses constituants. Lorsqu'une fonction ne ncessite pas de paralllisme pour exprimer son comportement, elle ne doit pas tre dcompose. C'est le critre d'arrt utiliser pour le raffinement fonctionnel. C'est par le travail d'analyse qu'il est possible de dduire si un raffinement est ncessaire ou pas. La dduction est gnralement assez simple au vu de la spcification de la fonction. Si cette spcification est exprime par un modle squentiel - diagramme tats finis, grafcet squentiel, modle mathmatique - la rponse est immdiate. 312 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE 15.5.2. Droulement du raffinement L'ordre de dcomposition des fonctions importe peu a priori car les fonctions sont indpendantes, chacune justifie par une spcification gnralement informelle. Toutefois, il est suggr de dtailler 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 rle et la spcification ne sont pas clairement dfinis. Pour cela, il est souhaitable d'approfondir ces fonctions par une analyse qui conduit alors un raffinement. La dmarche suivre pour chaque raffinement est la mme que celle expose pour la recherche de la premire dcomposition fonctionnelle. Procder en 3 temps: analyse, construction, vrification. 15.5.3. Exemple 1: contrle en vitesse dun centrifugeur Procdons tout d'abord au raffinement de CONTROLE_VITESSE. Le moteur doit suivre, indpendamment de la charge, un gabarit en vitesse: acclration, vitesse constante, dclration. Ceci n'est possible qu'en connaissant la vitesse de consigne tout instant. Soit VCONSIGNE cette variable. Pour s'orienter vers des solutions numriques, la variable VCONSIGNE est valuer des instants discrets selon un pas d'chantillonnage (H) qui se dduit de la prcision obtenir. La structure fonctionnelle propose, 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

Contrle vitesse

-Figure 15.9- Raffinement de CONTROLE_VITESSE. La fonction HORLOGE est ncessaire pour produire H. Les 2 fonctions COMMANDE_VITESSE et ASSERVISSEMENT_VITESSE sont temporaires synchrones H, ce qui se justifie pour une solution compltement numrique. M.C.S.E 313

Partie 4 - CONCEPTION FONCTIONNELLE L'entre VMOTEUR est ncessaire pour la fonction COMMANDE_VITESSE de manire indiquer GESTION_CENTRIFUGEUR l'tat ROTATION ou ARRET. La spcification de ASSERVISSEMENT_VITESSE est une rgulation du type proportionnel ou proportionnelleintgrale-drive si ncessaire. La spcification de COMMANDE_VITESSE correspond au diagramme tats finis de la spcification (voir 12.6.3) prcisant le comportement impos au moteur. Ainsi toutes les fonctions ont un comportement squentiel. Le raffinement est donc achev. Pour la fonction GESTION_CENTRIFUGEUR, sa spcification est exprimable partir du comportement impos l'utilisateur (automate tats finis donn en 15.6.4). Le comportement est squentiel. Le raffinement n'est donc pas ncessaire. 15.5.4. Exemple 2: Automatisation par chariot filoguid Commenons nouveau par la fonction COMMANDE_DEPLACEMENT. Les 2 moteurs du chariot sont mcaniquement indpendants. Mais le chariot doit suivre sa trajectoire et simultanment respecter le cycle: acclration, vitesse constante, dclration. Un couplage est donc ncessaire 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 gnres 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 dplacement

-Figure 15.10- Raffinement pour COMMANDE_DEPLACEMENT. Il est vident que plusieurs solutions existent suivant la variable de couplage considre. Entre les diverses solutions, cela revient placer les oprations effectuer dans l'une ou l'autre des fonctions. Ceci influe sur la partie organisationnelle et non pas sur la partie opratoire. 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 dfauts. 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 spcifie par le comportement impos au chariot durant chaque phase de dplacement (voir la spcification en 12.10.2). Un raffinement n'est donc pas ncessaire. De mme, la fonction SUPERVISION est spcifie par le comportement global du chariot, qui est squentiel. Toutefois, des conditions du type dure existent, ce qui ncessite en complment l'accs un Temps. Soit T un temps restant relatif au dbut de la phase d'attente. Ainsi la fonction SUPERVISION ncessite d'tre raffin comme suit:

SON_SIRENE

ORDRE SUPERVISION

CR

C_TAPIS

FIN_T

TEMPORISATION

M/A

ETAT

-Figure 15.11- Raffinement de SUPERVISION La fonction Temporisation gnre l'vnement FIN_T. Cette solution est strictement ncessaire pour tre conforme au modle fonctionnel. En effet, SUPERVISION est active sur apparition de chaque ORDRE. Le temps de droulement de l'activit n'est pas nulle puisqu'il y a des attentes temporelles. Ainsi pour respecter l'hypothse du temps nul pour le droulement des oprations, les attentes temporelles doivent se faire sur l'vnement 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 lmentaires sont dcrire compltement. Il en est de mme 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 lmentaire 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 compltude de la solution. Pour les donnes, la description doit se faire au fur et mesure de leur apparition durant les tapes de raffinement. L'ordre logique veut que les donnes soient dcrites avant les fonctions qui les utilisent ou les produisent. Cette attitude est justifie, d'une part puisque le principe de la conception fonctionnelle est orient donnes, d'autre part puisqu'il n'est pas possible de dcrire une fonction de transformation sans connatre les donnes en entre et en sortie. 15.6.1. Mthode 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 spcification. La solution n'est pas unique et ne traduit pas obligatoirement la solution qui sera par la suite utilise pour la ralisation. Une transformation pourra tre entreprise pour rpondre divers critres: optimisation, simplification ... La description s'obtient partir d'une spcification. Le travail de traduction est fonction de la nature de la spcification: - Pour une spcification trs informelle, la tche est plutt longue et la vrification peu simple, - Pour une spcification formelle, le travail se rduit une simple traduction. Prenons l'exemple d'une spcification exprime par un diagramme tats finis. Cette spcification explicite le comportement externe de la fonction par un ensemble d'tats qui permet de caractriser les sorties partir des entres. Ce type de modle est trs favorable pour l'obtention de la description interne. En effet, il suffit de btir la description autour d'une variable interne qui prend comme valeurs les tats de la spcification. 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 illustre par les 2 exemples traits dans ce chapitre. 15.6.2. Exemple 1: Contrle en vitesse dun centrifugeur 3 fonctions lmentaires dont 1 permanente et 2 temporaires rsultent du raffinement de CONTROLE_VITESSE. GESTION_CENTRIFUGEUR comme action temporaire n'a pas t raffine. On dcrit ci-aprs 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 (entre var V:0..100Km sortie Var INDICATION:(Vert,Rouge); ev Dpassement); Var ETAT:(lent,Rapide); begin INDICATION:=vert; ETAT:=lent; cycle PAS: case ETAT of lent: if V>50Km then begin signal (Dpassement); 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 Dpassement

Rapide

Indication = rouge

Dpassement

Pas

EXEMPLE

Indication

-Figure 15.12- Exemple de traduction d'une spcification par diagramme. Pour laction asservissement simplement du type proportionnel, il faut tenir compte du fait que la variable CV est borne. Si le calcul de la commande donne une grandeur dpassant la valeur maximale, il faut alors limiter CV cette valeur maximale, de mme pour la valeur minimale. Il faut noter quun asservissement en proportionnel nest pas suffisant car un cart permanent subsiste. Des actions intgrale et drive sajoutent sans difficults.
action ASSER_VITESSE sur vnement H avec (entre 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 rle de supervision pour l'volution du moteur, cette fonction doit imposer au moteur un comportement dcrit par la spcification fonctionnelle. Pour cela, il suffit donc que la fonction se comporte comme la spcification. 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 vnement H avec (entre var CROTATION, VMOTEUR: def_vitesse; entre/sortie var M/A: (marche, arrt); sortie var VCONSIGNE: def_vitesse; var ETAT,EROTATION: (Rotation,arrt)); Const PASH = 5 ms; Vmin = 5 trs; TM = 5 s: TC = 20 s; TD = 5 s; Var ETAT_MOTEUR: (Repos, acclration, vit_constante, dclration); VM: 0...VMAX; T: integer; begin ETAT_MOTEUR: = Repos; ETAT:=arrt; EROTATION:=arrt; VCONSIGNE:=0; cycle H: begin T:= T+PASH; Case ETAT_MOTEUR of Repos: if M/A = marche then begin ETAT_MOTEUR:=acclration; VCONSIGNE:= 0; T:=0: ETAT:=Rotation; EROTATION:=rotation; end; acclration: if M/A = arrt then begin ETAT_MOTEUR:= dclration; 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=arrt) or (T>=TC) then begin ETAT_MOTEUR:= dclration; VM:= VMOTEUR; T:=0; end; dclration: if VMOTEUR < Vmin then begin ETAT_MOTEUR:= Repos; M/A:=arrt; ETAT:=arrt; EROTATION:= arrt; 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 spcification donne comme contrainte impose par le systme l'utilisateur. La description algorithmique s'en dduit directement.
action GESTION_CENTRIFUGEUR sur message ORDRE: def_ordre avec (entre var ETAT:(rotation, arrt); sortie var VROTATION, CROTATION: def_vitesse; var M/A: (marche, arrt)); type def_ordre = record nature: (marche, arrt, consigne); val_consigne: def_vitesse; end; Var V_consigne: def_vitesse; begin M/A:=arrt; CROTATION:=0; VROTATION:=0; V_consigne:=0; cycle ORDRE: case ORDRE.nature of marche: if ETAT=Arrt then begin CROTATION:=V_consigne; M/A:= marche; end; consigne: if ETAT=Arrt then begin V_consigne:=ORDRE.val_consigne; VROTATION:=V_consigne; end; arrt: begin M/A:= arrt; 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 lvnement H suivant. Pour cette raison, tout ordre darrt est rpercut auprs de la fonction COMMANDE_VITESSE. La phase de vrification est ainsi importante car elle conduit assurer que limplantation rsultante sera correcte. 15.6.3. Exemple 2: Automatisation par chariot filoguid Il existe une grande ressemblance fonctionnelle entre les 2 exemples. Aussi certaines fonctions dcrites pour l'exemple 1 sont transposables pour cet exemple. C'est le cas des actions HORLOGE et ASSERVISSEMENT_VITESSE. On constate ainsi les aspects rutilisation des dveloppements sur le plan fonctionnnel. La fonction COORDINATION se charge de surveiller l'environnement durant la phase de dplacement: position du fil et dtection d'obstacles. Elle se charge aussi d'imposer le profil: acclration, vitesse constante, dclration, et gre 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 incrment de vitesse chaque pas. De plus, le contrle en vitesse ncessite d'utiliser les 2 positions du chariot par rapport au quai: Approche et Prsence.
action COORDINATION sur vnement PAS avec (entres:var OBSTACLE: boolean; var POSITION_QUAI:(loin, approche, prsence); var DCA: -Dmax..+Dmax; entre/sortie var M/A: boolean; var ETAT: Def_tat; sortie var VC1, VC2 : def_vitesse); const Tpas = dure; 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, acclration, V_constante, dclration, dfaut); 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:= acclration; end else VC:= 0; acclration: 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:= dclration; end; dclration: if POSITION_QUAI=prsence then begin VC:= 0; ETAT:= Repos; M/A:= false; end; else VC:= VC - DEC_VC; dfaut: if M/A= false then ETAT:= Repos; end case; if OBSTACLE or abs(DCA)>=Dmax then begin VC1:= 0; VC2:= 0; ETAT:= dfaut; 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 raliste. Une solution plus robuste n'est pas difficile crire.
action SUPERVISION sur message ORDRE:Def_ordre avec (entre var ETAT:def_etat; evenement fin_T; entre/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_prsence, chargement, dchargement, transport); def_cr = (OK_prsence); def_c_tapis = (arrt, arrire, avant); begin M/A:= false; SON_SIRENE:= false; C_TAPIS:=arrt; cycle ORDRE: case ORDRE of I_prsence: send(OK_prsence, CR); chargement: begin C_TAPIS:= avant; T:= TC; when fin_T: C_TAPIS:= arrt; end when; end; transport: begin M/A:= true; Repeat until (M/A=false) or (ETAT=dfaut); if ETAT= dfaut then SON_SIRENE:= true; else begin T:= TI; when fin_T : SON_SIRENE:= true; I_prsence : send(OK_prsence, CR); end when; end; end; dchargement: begin C_TAPIS:= arrire; T:= TD; when fin_T: C_TAPIS:= arrt; end when; end; end case; end cycle; end SUPERVISION;

Cette fonction utilise un dcompteur de T pour les temporisations TC, TD et TI. 15.7. DESCRIPTION DES DONNEES Les donnes servent dans 2 types de relations: le partage de variables et le transfert de messages. Chaque variable, chaque type de message doivent tre spcifis puis dcrits au fur et mesure du dveloppement de la structure fonctionnelle. M.C.S.E 321

Partie 4 - CONCEPTION FONCTIONNELLE Pour qu'une description de donnes 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 ncessaire pour l'implantation (voir le modle de description en 13.4). Les termes utiliss ici sont diffrents des niveaux utiliss pour les bases de donnes. Le terme description logique est plutt proche du terme schma conceptuel. 15.7.1. Mthode pour dcrire les donnes Une donne dans sa forme la plus gnrale est une structure. Comme il s'agit d'une structure, la dmarche prconise pour la recherche d'une structure fonctionnelle: -analyse, construction, vrification - s'applique aussi pour laborer la description des donnes.
-A- ANALYSE

Une variable ou un type de message apparaissant dans une structure fonctionnelle aprs raffinement rsulte d'une analyse des spcifications. La spcification de chaque donne pour dduire sa description dpend de sa complexit. Le modle dcrit en 13.4 fait tat de 4 niveaux de complexit: - la donne lmentaire: sa spcification et la description correspondante sont directes, car assimilable aux types de base: boolen, entier, numration ... - la donne structure: sa spcification s'exprime par composition de donnes plus lmentaires selon les oprateurs: concatnation, slection, ensemble. Sa description logique est une structure de donnes. - la collection de donnes: chaque donne est identifiable par une cl. - la donne du type RELATION: sa spcification s'exprime par des diagrammes entits/ relations de CHEN. Sa description logique s'exprime par une ou plusieurs collection de donnes. Chaque relation individualise est dsigne par des cls. La tche d'analyse doit tout d'abord situer la complexit de la donne. Elle rsulte d'une interprtation des spcifications fonctionnelles. Dans le cas le plus gnral, l'analyse conduit mettre en vidence le schma conceptuel utilisant le diagramme entits/relations. Ce schma rsulte d'une interprtation des phrases de la spcification en traduisant les noms en type d'entits et les verbes en relations. Chaque entit est ensuite spcifie en identifiant tous les constituants et la structure liant ces constituants. Cette spcification doit tre conduite jusqu' l'obtention des constituants de base.
-B- CONSTRUCTION

Cette phase permet d'obtenir partir de la spcification, une description logique structure de la donne. Ceci rsulte d'une transformation de la spcification. Rappelons que la description doit rester logique et ne doit pas traduire l'implantation de la donne. Les ensembles d'entits et de relations sont transforms en collections. Les relations sont dcrites par des liens entre entits. Utiliser pour cela les rgles de transformation pour obtenir la 3e forme normale. Une CLE est slectionne pour identifier chaque entit. Chaque entit est dcrite sur la base des 3 symboles du modle dcrit en 13.4: compos de, slection parmi, ensemble de. 322 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE


-C- VERIFICATION

Comme pour une structure fonctionnelle, il sagit de sassurer que la structure de chaque donne permet de satisfaire les spcifications. Cette vrification porte sur la compltude, la cohrence, l'orthogonalit des champs ou attributs. Elle ncessite aussi de considrer la ou les fonctions qui produisent la donne et celles qui l'utilisent. Ainsi, la vrification ne sera complte qu'aprs avoir dcrit toutes les fonctions de la structure fonctionnelle qui exploitent et produisent les donnes. 15.7.2. Illustration par un exemple L'exemple retenu est le cas d'un systme de programmation du chauffage pour un btiment. Chaque pice appartient une zone de chauffage. Pour chaque pice, on doit pouvoir connatre: l'ETAT: dfaut, arrt, chauffe, la temprature de consigne, la temprature courante, la temprature externe.

La temprature externe se dduit de la position de la zone qui inclut la pice par rapport aux 4 faades du btiment. Pour la programmation du chauffage, elle se fait aussi pice par pice, selon une programmation hebdomadaire. La rsolution est le 1/4 d'heure sauf de 22h 7h du matin qui ne reprsente qu'une seule plage. Ceci donne 60 priodes de programmation. La programmation pour une pice et l'observation de l'tat des pices sont conformes l'cran ci-dessous.
PROGRAMMATION : 7h Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche CHOIX : F(in A(nnulation VISUALISATION ETAT Dfaut 1 2 3 Mode DATE : 10/9/89 Chauffe Tc 18 16 HEURE : 10:35 Ti 17 5 Te 5 5 8h 10h 12h Pice : 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 prsentation d'cran. M.C.S.E 323

Partie 4 - CONCEPTION FONCTIONNELLE Toutes les pices d'une mme zone sont caractrises par un tat identique. La programmation pour chaque zone se dduit de la programmation des pices comme l'union des priodes de chauffe, la temprature de consigne est la valeur maximale des consignes des pices incluses. L'tat de chaque PIECE se dduit de la dfinition de ZONES et de la relation d'appartenance entre ZONES et PIECES. La modlisation retenue pour les donnes est la suivante.
Pice
Nom
n
appartient

Zone
Nom
1 n
expos

Faade
Nom
1
TE

TC tat_zone prog_pice prog_zone lundi dimanche ETAT TC jour 0 0 60 MODE MODE : (arrt,chauffe) 60

-Figure 15.14- Modlisation des donnes pour un descriptif du chauffage. La description des variables se dduit de cette modlisation. facades = {facade} facade = nom + TE: -30C..+50C zones = {zone} zone = nom + facade_Ref + tat_zone + prog_zone tat_zone = tat + Tc tat : (dfaut, arrt, chauffe) Tc : 0 .. 30C Prog_zone = 60{mode}60 (il y a obligatoirement 60 priodes) Mode : (arrt, chauffe) pices = { pice} pice = nom + zone_ref + TC + prog_pice prog_pice = 7{jour}7 jour = 60{mode}60 Descriptif_chauffage = facades + zones + pices 324 M.C.S.E

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

V_pice[1..n]

V_zone[1..m]

Suivi pice [ i ]

Gestion pices

Descriptif chauffage

Gestion zones

Suivi zone [ i ]

-Figure 15.15- S.F pour la conduite du chauffage pour chaque pice. Pour n pices et m zones les variables V_PIECE et V_ZONE pour chaque zone sont dfinies comme suit: V_PIECE[i] = TC + prog_pice + tat V_ZONE[j] = tat_zone + prog_zone 15.8. CRITERES D'EVALUATION DUNE SOLUTION Plusieurs solutions sont possibles pour satisfaire une mme spcification. Des critres sont donc utiliser pour valuer celle considre comme la meilleure. Les critres habituellement cits concernant l'analyse des structures sont: - l'analyse du couplage, - l'analyse de la cohrence, - l'analyse de la complexit. Le couplage concerne la relation tablie par paire de fonctions. La cohrence et la complexit concernent laspect interne de chaque fonction. Ces analyses sont ralisables pour tous les niveaux du raffinement. A ces critres s'ajoute le critre de lisibilit. 15.8.1. Analyse du couplage Les fonctions de la structure sont couples par des relations du type: variable, vnement, port pour les messages. La complexit du couplage est lie: - au nombre de relations par paire, - la complexit de chaque relation, ceci pour les variables et les messages. Les couplages se rduisent en regroupant diffrentes donnes dans une mme structure de donnes. Les couplages agissant sur le contrle des volutions se rduisent en effectuant une approche oriente donnes, plutt quune 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 engendres par une modification de l'lment intermdiaire. Modifiant la nature et/ou la structure de la variable, quelles sont les modifications faire? Lorsqu'une variable est utilise par beaucoup de fonctions, le couplage s'avre important. 15.8.2. Analyse de la cohrence La cohrence se traduit par une mesure de l'unit fonctionnelle des constituants d'un lment. Cette analyse concerne aussi bien les fonctions que les donnes. L'observation peut se faire de l'extrieur ou en interne. La cohrence externe se traduit par l'adquation du nom la fonction ou la donne. Plus le nom est gnral, moins la cohrence existe. Une bonne cohrence externe favorise la lisibilit. La cohrence interne s'observe par analyse de la structure interne et des relations entre les constituants. Un couplage par des variables conduit une meilleure cohrence qu'un couplage par vnement ou message car ces derniers expriment alors une relation temporelle. Si les donnes servant de liens entre les fonctions ont une unit vis vis de la fonctionnalit, le sous-ensemble possde un fort degr de cohrence. 15.8.3. Analyse de la complexit Il s'agit d'exprimer la complexit de chaque fonction, elle-mme dcompose par une structure fonctionnelle ou dcrite 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 prconise dans ce chapitre limite la complexit entre 5 10 lments, ce qui permet d'avoir une bonne lisibilit. La complexit peut aussi tre observe en vertical. En combien de niveaux une fonction se trouve-t-elle dcompose? Cette analyse met en vidence le nombre de fonctions subordonnes. Plus le nombre est important, plus la lisibilit est faible. La complexit d'une description algorithmique se mesure par: - la complexit des entres et sorties de la fonction, (fan-in, fan-out) - la longueur de la description, - la complexit de l'enchanement des oprations. Des outils de qualimtrie 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 dveloppement ainsi que pour la maintenance sous toutes ses formes. La lisibilit de la structure fonctionnelle est particulirement visuelle. La forme pour la reprsentation est un facteur important pour la comprhension. Elle indique dans une certaine mesure la dmarche suivie par le concepteur ainsi que sa logique d'esprit. Il est conseill de placer toutes les entres gauche et les sorties droite. Les relations doivent aller au maximum des entres vers les sorties. Seules les relations exprimant un bouclage interne sont reprsenter en sens inverse. 326 M.C.S.E

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE La lisibilit rsulte des critres prcdents: faible couplage, cohrence forte et faible complexit. La lisibilit des descriptions algorithmiques s'obtient en respectant les critres de lisibilit d'un programme: longueur d'une description limite une page, au-del utilisation de procdures et fonctions. Utilisation des structures de contrle de la programmation structure, limitation du nombre d'emboitements des structures de contrle, rduction des interfaces avec les procdures et fonctions. Lorsque la solution complte est formule, il est conseill de revoir tous les dtails de la solution sur la base des critres ci-dessus. Des modifications peuvent apparaitre souhaitables pour amliorer la lisibilit et la simplicit. Pour la structure fonctionnelle, il s'agit de rduire les interfaces entre les fonctions ce qui s'obtient par regroupement de variables, regroupement de fonctions, ou dplacement de certaines parties opratoires 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 rles en permettant: - la vrification de l'adquation de la solution aux spcifications, - le transfert de connaissances de la solution dveloppe pour le problme, - le dveloppement d'une ralisation. La vrification est assure par un cycle auteur-lecteurs permettant ainsi de corriger, de modifier, damliorer la solution. Ce mme cycle permet aux lecteurs de prendre connaissance du problme. Ce document sert aussi comme document de rfrence pour le produit. Ceci facilite les tches de maintenance et d'volution de l'application. Pour l'tape suivante de dfinition de la ralisation, le document, associ au document de spcification, va servir comme donnes d'entre. Pour cela, il ne doit pas dcrire l'ordre chronologique des rflexions et des dveloppements. Il doit tout simplement dcrire la solution retenue selon une dmarche descendante pour faciliter la comprhension. Un guide doit favoriser la comprhension globale de la solution: description de la hirarchie des fonctions, des donnes ... 15.10. RESUME La dmarche pour la conception fonctionnelle a t prsente sur 2 exemples qui a priori paraissaient bien diffrents. Dveloppant la solution, des similitudes ont t constates: asservissement de vitesse, gnration de profil de vitesse, coordination ... Ainsi, la dmarche favorise naturellement la rutilisation de sous-ensembles dvelopps dans d'autres projets. En effet, les problmes traiter incluent des classes gnrales de sous-ensembles dont la solution s'identifie par une dmarche sur le plan fonctionnel. Rappelons les points essentiels de la dmarche propose dans ce chapitre. - Tout dabord une bonne conception fonctionnelle ne peut s'entreprendre que si les documents en entre sont complets, valids et de qualit. Les spcifications prendre en compte sont les spcifications fonctionnelles et opratoires. M.C.S.E 327

Partie 4 - CONCEPTION FONCTIONNELLE - La premire phase consiste dlimiter le systme par ses entres et ses sorties. Cellesci ne doivent pas tre technologiques mais fonctionnelles vis vis des entits de l'environnement. - Il faut attacher une grande importance la premire dcomposition 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 ralisation. - la recherche d'une solution par raffinement se fait en 3 temps: analyse des spcifications, construction d'une ou plusieurs solutions, vrification. - Le raffinement fonctionnel ne doit pas tre excessif. Pour une fonction, le raffinement est achev lorsque celle-ci possde un comportement squentiel. - La description algorithmique des actions doit tre de qualit: se limiter au strict ncessaire, favoriser la lisibilit, tre conforme au modle pour les actions permanentes et temporaires. Si possible, cette description ne doit tre qu'une simple traduction de spcifications. - La description de toutes les donnes doit tre complte avant d'entreprendre la description algorithmique. Une structure de donnes s'labore selon une dmarche en 3 temps: analyse, construction, vrification. - la solution complte doit tre value sur la base de critres qui permettent de juger de la qualit: couplage, cohrence, complexit, lisibilit. - La documentation doit tre structure et complte. Elle doit dcrire la solution selon une approche descendante de manire favoriser la comprhension. L'application de la mthode conduit ce rsultat.

328

M.C.S.E

Chapitre 16

MODELES GENERIQUES DE SOLUTIONS

Durant l'tape de conception fonctionnelle, les dveloppeurs doivent rechercher une solution comme raffinement de chaque fonction. Ce travail est li au processus cratif 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 premire dcomposition fonctionnelle est essentielle pour la qualit de l'ensemble du projet. Le chapitre prcdent a montr que cette dcomposition dcoule d'une phase d'analyse. En ralisant des expriences sur une population varie de concepteurs placs face un mme problme de conception (groupe d'tudiants de diffrentes origines par exemple), il est facile de constater que, se basant sur des mmes principes de conception, les solutions proposes sont des plus varies. Ceci veut dire que les concepteurs ne trouvent pas les mmes variables essentielles. Pourtant une solution est plus approprie que les autres. Fort de cette constatation, nous nous sommes attachs rechercher une technique permettant d'augmenter considrablement l'homognit des solutions. Le point de dpart de la rflexion fut de considrer que les concepteurs travaillent plutt par analogie. Ayant trait un problme similaire ou disposant de solutions, chacun est tent tout naturellement de rutiliser cet acquis. Les problmes tant diffrents, il ne suffit pas de disposer d'une riche classe de solutions car une solution ne correspond pas toujours trs exactement au

M.C.S.E

329

Partie 4 - CONCEPTION FONCTIONNELLE problme traiter. Dans lhypothse dune disponibilit de solutions, la technique de conception est alors un travail d'assemblage selon une dmarche ascendante. Cette faon de procder n'est pas en accord avec les principes de conception dvelopps dans les chapitres prcdents. Nous proposons ici l'ide de modles gnriques de solutions. Ces modles en nombre trs rduit s'avrent particulirement adapts la rsolution d'une large classe de problmes. 16.1. ROLE ET APPORT DUN MODELE GENERIQUE Un modle gnrique de solution est l'expression d'une architecture fonctionnelle gnrale comme une esquisse de solution adapte une classe de problmes. Un modle gnrique suggre des fonctions internes et des couplages spcifiques entre ces fonctions. Ainsi, au lieu de rechercher sans guide les variables internes essentielles, le concepteur, lorsqu'il part d'un modle gnrique, recherche les variables essentielles qui vont assurer le couplage entre les fonctions du modle. La varit des variables possibles est alors beaucoup plus rduite. Ensuite, ayant dfini les variables essentielles, il lui suffit de spcifier les fonctions du modle pour l'application. L'exprience montre qu'avec une population varie de concepteurs, pour un problme pos et avec un modle gnrique impos, peu de disparit apparat entre les solutions proposes. L'uniformit est-elle bonne? Pas obligatoirement, car elle peut supprimer l'apparition de solutions meilleures. Aussi, un modle gnrique doit possder en intrinsque des proprits de qualit de manire engendrer les meilleures solutions. L'apport du modle gnrique dans une dmarche de conception descendante est alors considrable car amliorant la solution produite, rduisant ainsi globalement le cot du dveloppement du projet. Comment trouve-t-on un modle gnrique? La cration ex nihilo est trs peu probable. Il faut plutt se baser sur une observation des principes et architectures de solutions imagines par des concepteurs. De cette observation, il faut dduire le caractre gnral, puis formaliser l'approche en tant que modle gnrique. Ensuite un tel modle doit tre valid. Ceci passe par de multiples essais de rsolution de problmes de dimension industrielle l'aide du modle. De ces expriences dcoulent des modifications, des mesures de qualit, des conclusions. Trouver, formaliser, valider un modle gnrique ncessite un travail exprimental important, qu'un concepteur peut conomiser lorsqu'il utilise judicieusement des modles dj valids. C'est l'objectif de ce chapitre que de faire bnficier les concepteurs de tels rsultats. La suite du chapitre dcrit quelques modles gnriques connatre pour la conception fonctionnelle. A noter que cette notion de modle gnrique est aussi utilisable pour l'tape suivante de dfinition de la ralisation. Ces modles sont alors des modles plutt orients vers larchitecture matrielle tels que la Machine de MOORE, la dcomposition partie oprative/ partie commande, ou larchitecture logicielle tel que le modle objet. 16.2. MODELE CONTROLEUR/PROCEDE COMMANDE 16.2.1. Principe Ce premier modle reprend simplement le point de vue de l'Automaticien face un procd ou une entit contrler. Toute commande doit se faire en boucle ferme. En effet, le comportement du procd ne pouvant pas tre parfait - sensibilit des perturbations ou autres 330 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS effets - une commande applique au procd ne va engendrer qu'approximativement l'effet souhait. Pour amliorer le rsultat et satisfaire un objectif avec prcision, il faut se servir d'observations sur le procd pour corriger les dfauts. Ce principe de dpart est reprsent ciaprs.

consigne

+ -

cart

Evaluation action et correction

actions
PROCEDE

observations

-Figure 16.1- Commande en boucle ferme. 16.2.2. Le modle Regardons maintenant le contenu des spcifications d'un problme de commande. La dmarche de spcification prconise dans MCSE invite modliser tout d'abord les entits de l'environnement. Il s'agit donc d'exprimer le comportement approximatif du ou des procds. Ensuite par les spcifications fonctionnelles, se trouve exprim le comportement impos chaque entit par le systme. Conclusion: se basant sur le principe de la boucle ferme, chaque entit pour suivre lvolution impose doit tre pilote par une fonction d'valuation des actions qui doit se comporter comme l'indique la spcification fonctionnelle. Ce raisonnement est faire pour chaque entit. Comme trs souvent des relations de dpendance temporelle doivent tre respectes pour les volutions des entits, des couplages sont ncessaires entre les fonctions internes de contrle. Le modle CONTROLEUR/PROCEDE COMMANDE est alors le suivant:
actions 1

Contrleur 1
observations 1 Etats des contrleurs Couplage actions 2

Entit 1

Contrleur 2
observations 2

Entit 2

-Figure 16.2- Modle gnrique CONTROLEUR/PROCEDE. A chaque entit est associe en interne une fonction contrleur couple cette entit par des relations d'actions et des relations d'observations. Le comportement de chaque fonction contrleur est exprim par la spcification fonctionnelle de l'entit correspondante. Par exemple, si la spcification est du type diagramme tats finis, la description algorithmique du comportement de la fonction de contrle s'obtient par simple traduction du diagramme tats finis. M.C.S.E 331

Partie 4 - CONCEPTION FONCTIONNELLE Les fonctions contrleur peuvent tre couples entre elles par des variables d'tat si des synchronisations apparaissent dans les spcifications. Une dpendance temporelle unidirectionnelle simple entre 2 contrleurs exprime par une condition par exemple, se ralise par l'intermdiaire de la variable interne qui mmorise l'tat prsent du contrleur gnrateur de la condition. Cette variable est alors place l'extrieur de cette fonction contrleur pour la rendre accessible en lecture l'autre contrleur. 16.2.3. La mthode La mthode pour l'emploi de ce modle est la suivante : - tout d'abord analyser les spcifications pour dterminer si ce modle est appropri, - dessiner les fonctions contrleurs, chacune couple son entit contrler au travers des entres et sorties du systme, - rechercher par analyse des spcifications, les couplages par variables d'tat ncessaires pour satisfaire les relations d'ordre. - placer les variables de couplage et complter les relations fonctionnelles, - crire les descriptions algorithmiques des contrleurs par traduction des spcifications, - vrifier la cohrence de l'ensemble de la solution et le respect de toutes les spcifications. 16.2.4. Exemple Illustrons l'emploi de ce modle par l'exemple simple d'un chariot de manutention. La figure suivante montre l'automatisation dvelopper l'aide d'un systme lectronique. L'objectif du systme est d'assurer en automatique le cycle: dplacement 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 entits de l'application. 332 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS La spcification pour cet automatisme est dcrite ci-dessous l'aide de 3 diagrammes tats finis coupls. Les positions P1 et P2 sont dtectes par les fins de course FCG et FCD. Les 2 positions de la benne sont commandes par les vnements C_repos et C_vidage. La variable DEFAUT est gnre par le chariot. Le cycle ne peut dbuter que si le chariot est en P1. Sinon, il revient en cette position. Loprateur gnre lvnement MARCHE avec sa boite bouton.
Systme pour loprateur Chariot Benne

Attente cycle MARCHE cycle exec cycle ETAT(Chariot)= dplacement droite ou dplacement gauche

Repos chariot

AV = 0 AR = 0

Repos benne ETAT (Chariot)= attente remplissage C_vidage Vidage PRcycle

cycleFCG cycleFCG Dplace droite AV = 1 AR = 0

Dfaut

FCD Attente remplis- AV = 0 sage AR = 0

Dure (vidage) =T1


Remonte C_repos benne

PR Dplace AV = 0 gauche AR = 1

PR

FCG+Dfaut

-Figure 16.4- Spcification de l'automatisme. A partir de cette spcification, se dduit la dlimitation des entres et sorties.

MARCHE Dfaut 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- Spcification des entres et sorties du systme. Ensuite le concepteur doit proposer un raffinement. Comme le comportement impos chaque entit est dcrit dans la spcification par un diagramme squentiel, utilisons le modle gnrique CONTROLEUR pour chaque entit. La solution est donc organise autour de 3 contrleurs. Il faut alors trouver les couplages ncessaires entre les contrleurs. Un couplage unidirectionnel existe entre le contrleur utilisateur et le contrleur chariot, un autre bidirectionnel existe entre le contrleur chariot et le contrleur benne. M.C.S.E 333

Partie 4 - CONCEPTION FONCTIONNELLE La structure fonctionnelle obtenue est la suivante :


Dfaut 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 lautomatisation. La solution est complte par une action de gnration du temps T pour raliser la temporisation ncessaire pour le contrle de la dure de l'tat vidage. 16.3. MODELE SUPERVISION/CONTROLE-COMMANDE Le modle prcdent est appropri pour des applications de faible complexit: peu d'entits 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'entres et de sorties du systme, une approche hirarchique est souhaitable. 16.3.1. Principe L'ide est que la conduite d'une installation plutt complexe est globalement prise en charge par le systme. 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 suprieur par rapport la conduite de chaque entit de l'installation. De tels systmes 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 grer toutes les entits physiques de l'application pour qu'elles contribuent satisfaire l'objectif du niveau suprieur. Les 2 niveaux sont donc coupls 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 modle Le modle propos dcoule de ce principe de structuration. La dcomposition se fait en 2 fonctions: SUPERVISION et CONTROLE_COMMANDE. Pour spcifier le modle, il faut dtailler le couplage gnral existant entre les 2 catgories de fonctions, de manire proposer au concepteur un guide d'analyse qui lui permettra de rechercher les variables internes caractristiques.

Niveau suprieur

SUPERVISION

Exploitant

Couplage

Niveau infrieur
Observations

CONTROLE-COMMANDE
Actions

Procd

-Figure 16.7- Modle Supervision/contrle commande. Le couplage descendant, de SUPERVISION vers CONTROLE-COMMANDE ncessite 2 catgories d'informations: - des paramtres, qui vont qualifier les objectifs atteindre pour la partie physique : temprature de consigne, temps de rponse... - des ordres, qui sont des vnements avec association ou non d'informations, pour dsigner les oprations que doit entreprendre la partie CONTROLE-COMMANDE. Le couplage ascendant de CONTROLE-COMMANDE vers SUPERVISION ncessite aussi 2 catgories d'informations: - des observations qui, synthtises par la partie CONTROLE-COMMANDE, permettront de suivre le droulement des oprations. - des ractions, pour signaler au niveau suprieur des situations particulires prendre en compte. Les entres et sorties pour l'exploitation sont associes la supervision. Les autres entres et sorties sont associes la partie contrle_commande. 16.3.3. La mthode Pour l'emploi de ce modle, il faut commencer par dcider si le modle parat appropri. L'exprience nous a montr que beaucoup d'applications, tout particulirement celles faisant intervenir une exploitation sous toutes ses formes (utilisateurs, autres ...), et des entits physiques, peuvent se dvelopper sur la base de ce modle. Ce choix tant fait, la dmarche est la suivante : - Identifier les entits lies chacun des 2 niveaux. M.C.S.E 335

Partie 4 - CONCEPTION FONCTIONNELLE - Rechercher par analyse des spcifications, les variables de couplage ncessaires: paramtres dans un sens, observations dans l'autres sens. - Rechercher ensuite les vnements de couplage, c'est--dire les ordres dans un sens, les ractions dans l'autre sens. - Dessiner la structure fonctionnelle en la compltant: toutes les relations de couplage, et les liens de toutes les entres et des sorties avec l'une ou l'autre des parties. - Vrifier la solution pour s'assurer que toutes les spcifications seront satisfaites. 16.3.4. Exemples Dans ce paragraphe, on se contentera simplement d'analyser les solutions proposes dans le chapitre prcdent pour la commande en rotation du centrifugeur (15.4.3) et pour l'automatisation du chariot filoguid (15.4.4). Au vu de la premire dcomposition fonctionnelle, 2 fonctions ont t trouves aprs avoir dtermines les variables internes essentielles pour la solution. Les structures fonctionnelles proposes sont conformes au modle SUPERVISION/CONTROLE-COMMANDE. Ainsi, plutt que de chercher sans guide prcis les variables internes ncessaires, un tel modle favorise cette tche en proposant 4 catgories de couplage. De plus, il est intressant de constater que pour les 2 exemples, la partie CONTROLECOMMANDE est nouveau dcompose en 2 classes de fonctions. La dcomposition est nouveau conforme au modle supervision/contrle-commande. Ainsi, le modle est utilisable pour plusieurs niveaux de fonctionnalits. Lorsqu'il n'est plus appropri car trop proche de l'entit contrler, fort probablement le modle prcdent CONTROLEUR convient. Cest le cas pour la fonction ASSERVISSEMENT. Beaucoup d'exemples caractre pdagogique, tels que: automatisation par chariot filoguid, conduite de chauffage, commande d'ascenseur, ont t traites sous les 2 formes, il y a quelques annes sans connaissance du modle, depuis en exploitant ce modle. La qualit des solutions bases sur le modle est incontestable au vu des critres de lisibilit, simplicit, couplage et cohrence. Pour des exemples industriels de plus grande dimension - cas de la conduite d'un btiment par une gestion technique centralise possdant 500 entres et sorties - un tel modle permet d'effectuer une premire approche globale oriente donnes essentielles pour l'application, puis permet d'approcher la solution dtaille par affinements successifs de chaque sous-ensemble en utilisant les 2 modles cits. 16.4. MODELE CLIENT/SERVEUR 16.4.1. Principe Pour introduire ce modle, plaons-nous dans le cas d'applications rparties. Le modle OSI (Open Systems Interconnection) a t formalis par lISO (International Organization for Standardization) de manire favoriser l'interconnexion de matriels htrognes comme support de ralisation. Il suggre de dcomposer le couplage entre entits fonctionnelles selon les 7 niveaux hirarchiques reprsents figure 16.8. 336 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS

APPLICATION

PRESENTATION

SESSION

TRANSPORT

RESEAU

Communications
2 LIAISON

PHYSIQUE

-Figure 16.8- Les 7 niveaux du modle OSI. Les niveaux: - Application, Prsentation, Session - sont orients obtention des fonctionnalits pour l'application. Les niveaux: - transport, rseau, liaison, physique - sont orients communication. Ce modle prcise que, pour son fonctionnement chaque niveau doit disposer ou peut exploiter des services du niveau infrieur. Chaque niveau est responsable dun ensemble de fonctions spcifiques. Ce principe, ainsi que l'ide des 7 niveaux, sont la base du modle client/serveur ci-aprs. 16.4.2. Le modle Bien que plutt appropri pour la dfinition de la ralisation dans le cas de fonctionnalits rparties, il nous a sembl souhaitable de proposer un tel modle dans ce chapitre compte-tenu de son caractre gnral. Le modle est du type vertical. Pour assurer sa fonctionnalit, une fonction doit disposer de services. Ainsi, la fonction dcomposer est partage en 2 sous-ensembles: la fonction ellemme assurer, les services ncessaires. Le couplage entre les 2 parties est alors du type vnementiel avec transfert d'informations, ce qui se traduit par des relations par transfert de messages ou de donnes. Le modle propos est reprsent figure 16.9. La fonction SERVICE peut elle-mme se dcomposer l'aide du mme modle. C'est ainsi qu'il est possible de descendre de niveau en niveau, jusqu' identifier des services existants, ou disponibles, ou connus. Le modle OSI suggre la nature des services pour chaque niveau, chacun assurant une fonctionnalit diffrente 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 modle client/serveur. 16.4.3. La mthode Tout d'abord, il faut identifier l'intrt de ce modle pour le problme traiter. Gnralement, il convient lorsqu'il s'agit de mettre en oeuvre des ressources pour satisfaire la fonctionnalit souhaite. Ces ressources sont accessibles par des services, ou mises disposition sous la forme de services. Pour cette classe de problmes, la mthode suggre est la suivante : - Identifier les services strictement ncessaires pour la fonction raliser. Pour cela, se baser par exemple sur le modle OSI lorsqu'il s'agit d'un problme de communication. - Spcifier le comportement de la fonction cliente qui sollicite en se basant sur l'existence des services ci-dessus. - Spcifier ensuite le comportement des services pour rpondre aux sollicitations du niveau suprieur. - Spcifier les informations de couplage ncessaires 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 modle de dcomposition, dcrire la solution fonctionnelle et les informations transitant par l'interface. - Vrifier la cohrence de la solution et son adquation satisfaire les objectifs. La mme dmarche peut nouveau tre utilise pour dcomposer la fonction offrant les services. Au pralable, il sera peut-tre souhaitable de procder un raffinement du niveau sur la base d'un modle fonctionnel du type horizontal. 338 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS 16.4.4. Exemple: transmission de message par liaison srie Cet exemple ne sert que pour illustrer le modle et la mthode. Normalement ce type de problme se traite durant l'tape de dfinition de la ralisation. Supposons qu'une application ncessite 2 fonctions F1 et F2 couples par un port MESS pour un transfert de messages.
Site A Site B

Mess

F1

F2

-Figure 16.10- Exemple d'application rpartie. Comme contrainte de ralisation, F1 et F2 sont distants. Le transfert entre F1 et F2 ne peut plus se faire directement par MESS. La solution ncessite d'avoir recours un service de transfert de messages du site A vers le site B. En se basant sur le modle 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 modle. Il est intressant de constater que la dmarche conduit ii raffiner le port MESS. On poursuit la dcomposition fonctionnelle en recherchant la solution pour raliser le transfert de chaque message. Chaque message tant une suite de caractres, les services ncessaires sont: rception et mission de caractres. De mme, en poursuivant le raffinement, chaque caractre transmis sur un support de communication est une suite de bits. La solution complte dtaille jusqu'au support est donne figure 16.12. Cette solution reste purement fonctionnelle, car aucune hypothse n'est faite sur la taille des ports. Durant l'tape suivante, pour la dfinition de la ralisation, chaque port aura une taille limite. Un asservissement producteur sur consommateur est alors probablement ncessaire, ce qui impose un couplage en retour entre Rception caractre et Emission caractre. M.C.S.E 339

Partie 4 - CONCEPTION FONCTIONNELLE

F1

F2

Mess A

Mess B

Interface messages

Service messages

Emission message

Rception message

Car A

Car B

Interface caractres

Service caractres

Emission caractre TxD

Rception caractre RxD

TxD

-Figure 16.12- Solution complte pour le transfert de messages. Les solutions pour ces problmes sont plus simples dduire partir d'une solution purement fonctionnelle comme celle prsente ci-dessus que par une approche plutt intuitive. 16.5. MODELE DINTERACTIVITE Beaucoup d'applications ncessitent de dvelopper une interface homme-machine pour le couplage du systme avec les utilisateurs, la maintenance ... Une telle interface est diffrente des interfaces avec les entits physiques. L'utilisateur est particulier: d'une part, il est libre de ses actions et donc ncessairement, il faut filtrer celles considres comme correctes pour l'application, d'autre part les informations changes peuvent tre trs complexes et prsentes sous des formes varies. 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-rponse: dialogue pilot par le systme - le dialogue par menus: tous types de prsentation y compris les menus droulants et les menus iconiques. - la manipulation directe. Cette forme est la plus sophistique. La manipulation directe consiste reprsenter les objets de l'application et qui intresseront l'utilisateur. Les actions sur les objets se font par dsignation directe de l'objet puis de l'action raliser. 340 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS Ce principe se retrouve aujourdhui disponible dans un environnement graphique multifentres avec utilisation d'une souris comme pointeur. La ralisation de telles interfaces est drive 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 Mtaphore MVC (Model-View-Controller) [MEVEL87]. Cette mtaphore suggre que tout objet de l'application doit tout d'abord tre reprsent par un modle interne. Ce modle peut ensuite tre prsent sous la forme d'une ou plusieurs vues. La manipulation de l'objet met en oeuvre un contrleur interpos comme filtre entre les actions de l'utilisateur, le modle et les vues. La figure suivante rsume cette mtaphore.
Actions sur les vues

Actions CONTROLEUR utilisateur

actions sur MODELE le modle

reprsentation externe

PRESENTATION VUE

Observations pour utilisateur

reprsentation interne Etat des vues

-Figure 16.13- La mtaphore MVC. 16.5.2. Le modle Le modle d'interactivit prsent dans ce paragraphe est driv de la mtaphore MVC. La reprsentation interne d'un objet de l'application se traduit par une donne ou une structure de donnes (modle). La reprsentation externe ou vue, exploite les grandeurs du modle de l'objet et des informations supplmentaires dfinissant la reprsentation externe. Les actions de l'utilisateur dpendent de la dsignation sur la reprsentation externe. Ainsi, l'tat de la vue est ncessaire pour dcider des actions entreprendre. Un tel modle pour une vue se reprsente par la structure fonctionnelle ci-dessous.
PARAMETRES VUE Evenements

CONTROLEUR MODELE ETATS PRESENTATION DE LA VUE Reprsentation externe

(position) curseur
ETAT_VUE

-Figure 16.14- Le modle d'interactivit pour une vue. Les vnements 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 contrleur de diffrencier les actions demandes compte-tenu de la position du pointeur sur l'cran et donc relativement l'objet reprsent. Les actions possibles de CONTROLEUR concernent la modification du modle, telles que les grandeurs et mme la structure, ainsi que les paramtres de la vue. La fonction PRESENTATION_VUE, calcule tout instant, une reprsentation externe du modle interne en tenant compte des paramtres de reprsentation. Ainsi, si le modle est modifi en temps-rel, sa reprsentation suivra. Ce modle gnrique n'est que fonctionnel. Il n'exprime pas la technique de ralisation. La solution pour la ralisation se dduit ensuite de ce modle. En particulier la fonction PRESENTATION_VUE devra tre dclenche uniquement sur modification du modle ou des paramtres de la vue. 16.5.3. La mthode A partir des spcifications, il faut tout d'abord rechercher la forme d'interactivit souhaite. Si la convivialit voulue implique la mise en oeuvre du principe de la manipulation directe, les phases suivantes sont suggres: - Rechercher tout d'abord les objets de l'application impliqus dans l'interactivit, - Spcifier ces objets en recherchant les grandeurs caractristiques puis dfinir une reprsentation interne, - Spcifier la ou les vues souhaites pour ces objets. En dduire les paramtres de reprsentation et les tats de la reprsentation externe, - Spcifier le comportement des fonctions PRESENTATION_VUE et CONTROLEUR. En dduire une description algorithmique. 16.5.4. Exemple Illustrons l'emploi de ce modle par un exemple simple. On dsire reprsenter en temps-rel le contenu de 2 cuves, l'une dversant dans l'autre par l'intermdiaire d'une vanne ferme ou ouverte et avec un dbit rglable. L'utilisateur observe en temps-rel le niveau de chaque cuve. Il peut agir sur l'tat de la vanne et peut aussi rgler le dbit. Les objets de l'application sont: - les 2 cuves, chacune modlise par son diamtre et la hauteur, - la vanne avec son tat et son dbit quand elle est ouverte. La prsentation souhaite est la suivante :

ON OFF

Cuve 1

Vanne Dbit

253
Cuve 2

-Figure 16.15- Prsentation souhaite pour l'interface homme-systme. 342 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS Linterrupteur ON/OFF fixe la position de la vanne, le changement de position se fait en cliquant dessus. Le dbit est indiqu par sa valeur numrique. Cette grandeur est modifiable sous 2 formes: en changeant la valeur numrique 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 reprsent par une prsentation graphique. La vanne est reprsente ouverte ou ferme suivant la position de l'interrupteur. Tous les objets de la vue -interrupteur, rglage du dbit, les cuves- sont dplaables en cliquant sur l'objet et en la dplaant. Le relchement fixe la position finale. La modlisation interne concerne: - l'tat de l'interrupteur, - la valeur du dbit, - la quantit dans chaque cuve. Les paramtres de la vue sont: - la position de l'interrupteur, - la position du rglage de dbit, - la position de chaque cuve. L'tat de la vue est caractrise par: - la zone ou se situe l'interrupteur, - la zone de modification numrique du dbit, - les zones pour les 2 poussoirs + et -, - les zones pour chaque cuve. La structure fonctionnelle est donc la suivante :
Paramtres Vue Etat poussoir souris CONTROLEUR Modle position curseur des objets DE LA VUE PRESENTATION VUE

Etat_vue

-Figure 16.16- Structure fonctionnelle pour lapplication. L'tat du poussoir de la souris doit tre observable tout instant pour permettre les modifications par appui sur + ou - ou pour les dplacements d'objets. Cette variable peut aussi se remplacer par les 2 vnements APPUI, RELACHEMENT. M.C.S.E 343

Partie 4 - CONCEPTION FONCTIONNELLE 16.5.5. Gnralisation du modle au cas multi-fentres Dans un environnement multi-fentres, une fentre reprsente un cran logique. Plusieurs objets et vues sont alors reprsentables. 2 niveaux sont alors diffrencier: la gestion des fentres, la gestion des reprsentations dans chaque fentre. Le modle ci-dessus peut servir comme base de structuration. Pour cela, il faut contrler chaque objet, produire et contrler sa vue dans une fentre. L'ensemble des vues constitue alors une modlisation logique des objets, qui doit tre traduite en une prsentation physique. La structure fonctionnelle tendue au cas multi-fentres est alors la suivante:
paramtres cran

Modle des vues


Action V1 Contrleur vue 1 objet 1 Prsentation vue 1 Vue 1

Contrleur Actions cran utilisateur


Action Vi Contrleur vue i objet i Prsentation vue i Vue i

Prsentation Ecran cran

Etat_cran

-Figure 16.17- Structure fonctionnelle pour une prsentation multi-fentres Un tel modle doit favoriser la ralisation dapplication graphiques interactives qui passent par la mise en oeuvre dun gestionnaire multi-fentres. 16.6. RESUME Ce chapitre a permis de prsenter des modles gnriques qui peuvent grandement aider le concepteur entreprendre une dcomposition fonctionnelle. La liste des modles n'est pas bien sr exhaustive, elle ne demande qu' tre enrichie. Toutefois, il ne faut pas confondre modle gnrique et solution pour un problme prcis. Les solutions dveloppes pour d'autres applications ont lavantage dtre directement rutilisables. Mais comme peu de problmes sont similaires, le concept du modle gnrique apparait essentiel. Les grandes lignes de ce chapitre sont rappeles ci-aprs: - Un modle gnrique aide le concepteur proposer une dcomposition fonctionnelle de qualit. - Chaque modle tant appropri pour une classe de problmes, il faut tout d'abord rechercher le modle le plus adquat partir des spcifications. 344 M.C.S.E

Ch 16 - MODELES GENERIQUES DE SOLUTIONS - Le modle suggre de rechercher les donnes internes essentielles pour rsoudre l'application. Cette approche est conforme aux principes noncs pour la conception. - Chaque fonction d'un modle peut nouveau se dcompose par le mme modle ou par un autre modle plus lmentaire. - Les modles exposs couvrent les classes de problmes suivants: contrle en boucle ferme, hirarchie en contrle-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 mthodologie de conception des systmes multi-microordinateurs pour les applications de commande en temps-rel J.P. CALVEZ Thse de Doctorat d'Etat, Universit de NANTES, Novembre 1982 [DATE-86] An introduction to Database Systems. vol 1 C.J. DATE Addison-Wesley 4ime dition, 1986 [GALACSI-86] Les sytmes dinformation - Analyse et Conception GALACSI nom collectif DUNOD informatique 1986 [GALACSI-89] Conception de bases de donnes - Du schma conceptuel aux schmas 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 DUN SYSTEME [ROLLAND-88] Conception des systmes dinformation - La mthode 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 Gnie logiciel et systmes 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

DEFINITION DE LA REALISATION

La troisime tape de la mthodologie a pour but de dterminer toutes les spcifications de la ralisation quil faudra entreprendre pour satisfaire les objectifs du systme. Le travail effectuer consiste affiner, dtailler, enrichir la solution fonctionnelle pour satisfaire de nouvelles contraintes exprimes par les spcifications technologiques. Cette tape est aussi appele Conception Dtaille. Le point de dpart est la solution fonctionnelle labore durant l'tape prcdente, qui a la particularit d'tre indpendante de la technologie. Comme rsultat de cette tape, la ralisation se traduira par la mise en oeuvre en complmentaire, d'un ensemble matriel comme support d'excution, et d'un ensemble logiciel spcifiant l'volution impose pour l'application. La dmarche prconise: - d'introduire les interfaces technologiques, - de tenir compte de toutes les contraintes de temps des systmes temps-rel, - de dterminer la rpartition matriel/logiciel - de spcifier les caractristiques de la partie matrielle et les rgles d'implantation pour la partie logicielle. Cette partie prsente tout d'abord le modle d'excution, troisime dimension du modle global de description de toutes solutions (chapitre 17). Le chapitre 18 dcrit le modle d'intgration qui dtaille la correspondance entre le niveau fonctionnel et le niveau excution ainsi que les rgles respecter pour l'implantation du logiciel. Le chapitre 19 prsente les objectifs atteindre, les diffrents critres pour la ralisation, les principes et la dmarche suivre pour le dveloppement de la solution. Les deux exemples sont traits titre dillustration.

M.C.S.E

349

Chapitre 17

LE MODELE DEXECUTION

Une prsentation rapide du modle de description de toute solution faite dans la partie 1 a montr qu'en final une ralisation est compose de 2 parties: une partie matrielle qui engendre l'volution des fonctions du systme, une partie logicielle qui personnalise le comportement du matriel pour que l'volution globale soit conforme aux spcifications dtailles de l'application. La partie matrielle doit tre spcifie. Ceci veut dire qu'il faut produire une description dtaille du matriel mettre en oeuvre, sans qu'il s'agisse pour cela de schmas de cartes, de rfrences de matriels. La description doit se limiter l'expression des caractristiques et contraintes des fonctions matrielles ncessaires, des liens entre ces fonctions. Cette description doit toutefois tre suffisante pour que, durant la phase suivante de ralisation, un spcialiste ou une quipe puisse tablir les schmas, choisir les matriels -sous-ensembles, cartes, composants- et raliser. Ce chapitre a pour objectif de dcrire le modle d'excution comme outil pour la spcification de la partie matrielle d'un systme. Il prsente tout dabord le modle dexcution en caractrisant son comportement global, puis les spcifications de chaque type de constituant.

M.C.S.E

351

Partie 5 - DEFINITION DE LA REALISATION 17.1. CARACTERISTIQUES DU MODELE DEXECUTION Le modle d'excution exprime un ensemble de rgles que doit respecter toute spcification de la partie matrielle pour une ralisation. Pour la description d'un matriel existant connu par ses schmas, sous-ensembles, cartes, ce modle favorise par abstraction, une vision macroscopique de ce matriel. Lorsqu'il s'agit de concevoir la partie matrielle, ce modle dfinit l'ensemble matriel selon une vue purement externe, laissant ainsi le libre choix de toute solution technique rpondant aux contraintes. Bien entendu, cette vue externe n'est plus indpendante de la technologie dans le sens des fonctions, mais se veut encore indpendante des composants du march. 17.1.1. Le modle d'excution et ses constituants Le modle d'excution part de l'hypothse que toute ralisation pour un systme est compose: - de processeurs comme organes de transformation des informations, - de mmoires pour la sauvegarde et la conservation des donnes, - de noeuds de communication comme lments intermdiaires pour le transit d'informations. Ces trois types d'lments technologiques sont ncessairement lis entre eux. Ce modle utilise 3 types de liens que sont: - la signalisation inter-processeurs pour le couplage direct des processeurs, - le partage de mmoire entre processeurs pour un couplage indirect sans relation dordre, - la communication inter-processeurs comme couplage indirect avec relation d'ordre, ralise par l'intermdiaire d'un rseau de noeuds de communication. Ainsi le modle d'excution est une structure appele STRUCTURE D'EXECUTION. L'exemple suivant permet de se faire une ide de ce modle 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'excution. 352 M.C.S.E

Ch 17 - LE MODELE DEXECUTION Cet exemple montre que processeurs et noeuds de communication peuvent eux-mmes se dcrire par une structure d'excution. Une structure d'excution est caractrise par: - une description topologique sur la forme d'un rseau d'interconnexion d'lments. - une spcification de chaque type d'lment et de chaque type de relation tablie par les liens. Du type structurel, ce modle permet une description hirarchique. La composition du modle d'excution est reprsente comme suit:
STRUCTURE DEXECUTION SPECIFICATION DES CONSTITUANTS

Spcification
Description externe

Niveau 0

globale

Description interne

Niveau 1

Spcification processeurs,...

Niveau i

Spcification constituants de base

-Figure 17.2- Dcomposition hirarchique du modle d'excution. La partie organisationnelle est une structure d'arbre car chaque lment - processeur, noeud de communication - est dcomposable selon une structure d'excution. Les objets terminaux sont des lments technologiques de base. Le niveau 0 dlimite le support excutif de l'application. La partie spcification des constituants caractrise tous les types d'lments du modle d'excution: processeur pour chaque niveau de raffinement, noeud de communication et mmoire pour le niveau d'utilisation ainsi que le rle de la relation pour le niveau de dcomposition de la structure d'excution. 17.1.2. Signification des lments et des relations Avant de dtailler les rgles du modle, prenons connaissance des types dlments et de relations ainsi que de leurs significations. L'exemple prcdent a permis de constater la notation graphique et le niveau de description que permet une structure d'excution. Il est intressant d'avoir l'esprit, et tout particulirement pour l'interprtation du rle de chaque constituant, la similitude entre une structure fonctionnelle et une structure d'excution. M.C.S.E 353

Partie 5 - DEFINITION DE LA REALISATION Cette caractristique s'explique car la structure d'excution est le moteur pour l'volution d'une structure fonctionnelle. Ainsi les actions du niveau fonctionnel voluent grce aux processeurs, les relations fonctionnelles sont assures par l'intermdiaire de signalisations, de mmoires, de noeuds de communication.
-A- PROCESSEUR

Le terme PROCESSEUR est utilis ici dans son sens le plus gnral. C'est tout d'abord un objet dynamique qui a sa propre autonomie. Ainsi, il est en mesure d'assurer lui-mme son rle lorsqu'il le souhaite. Son activit dpend de sa fonctionnalit: globalement, il assure des transformations sur les informations en entre pour produire des informations en sortie. Les processeurs peuvent se classer en 2 catgories: - les processeurs gnraux (programmables), - les processeurs spcialiss (paramtrables ou non-paramtrables). Les processeurs gnraux sont programmables ce qui permet de particulariser leurs fonctionnalits. Cette programmation se fait par du logiciel. Ainsi sont considrs comme processeurs programmables: les microprocesseurs, les microcontrleurs, les mini et microordinateurs, les systmes informatiques. Le terme processeur inclut ici tous les lments ncessaires pour son fonctionnement: par exemple pour le microprocesseur s'ajoutent la mmoire locale pour les programmes et les donnes, les entres/sorties. Un processeur spcialis a une fonctionnalit propre non modifiable. Des paramtres peuvent par contre tre modifis pour moduler la fonctionnalit. Entrent dans cette catgorie: les composants VLSI spcialiss, des ensembles programms, un niveau moindre des composants numriques et analogiques tels que additionneur, multiplieur, transposeur de frquence, etc et tout type d'interfaces: gnrateur PWM, horloge programmable...
-B- MEMOIRE

Une mmoire est un objet passif. Elle mmorise 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'intermdiaire entre un ensemble de canaux de communications lis aux processeurs. Son rle est de diriger vers le bon destinataire chaque information qu'il reoit. Les informations reues, qui sont alors des messages, sont temporairement mmorises, analyses, puis retransmises par les canaux de sortie. Pour un message donn, un dlai peut exister entre son entre et sa sortie. Un noeud de communication peut tre de complexit trs varie. Pour le plus simple, une entre et une sortie sans mmoire, il s'agit simplement d'une liaison directe. Pour les plus complexes, un noeud est lui-mme un rseau de noeuds de communication tel que par exemple le rseau TRANSPAC.
-D- SIGNALISATION INTER-PROCESSEURS

Chaque processeur dcide tout instant de son activit. Certaines activits ncessitent des couplages avec l'environnement respectant des relations d'ordre. La signalisation interprocesseurs permet d'assurer des synchronisations entre des activits rparties sur des processeurs diffrents. Elles se ralisent pour le matriel par des signaux de contrle, des lignes d'interruption. 354 M.C.S.E

Ch 17 - LE MODELE DEXECUTION
-E- PARTAGE DE MEMOIRE

Un processeur peut utiliser une mmoire externe pour dposer ou consulter de l'information. Lorsqu'une mmoire 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 mcanisme, mais comme la mmoire est un objet passif, les relations temporelles ne s'obtiennent que par une consultation rgulire 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 rseau de noeuds de communication vers le processeur destinataire dsign 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 DEXECUTION Une structure d'excution est l'expression topologique par un rseau d'lments d'un support matriel (on utilisera parfois la notation S.E). Dans la suite du paragraphe sont dcrits tout d'abord les conventions de reprsentation (vue statique), puis l'interprtation de chaque symbole en spcifiant son comportement vis vis de son environnement (vue dynamique). 17.2.1. Reprsentation graphique La reprsentation d'une structure d'excution dcrit la dcomposition d'un lment du type processeur ou noeud de communication. Ainsi chaque lment dcrire possde des entres et des sorties. Le raffinement d'un lment se dcrit partir de 4 types d'lments: - des processeurs, reprsents chacun par un rectangle
P

- des mmoires, reprsentes par le symbole:

- des signalisations reprsentes par:

- des noeuds de communication reprsents par:

Les relations sont toutes entre processeurs. Elles ne sont possibles que par un lment intermdiaire du type: signalisation, mmoire, noeud de communication. M.C.S.E 355

Partie 5 - DEFINITION DE LA REALISATION Les 3 types de relations autorises utilisent des symboles spcifiques pour les liens: - pour la signalisation: - pour l'accs une mmoire: - pour le transfert des messages: Voici un exemple de structure d'excution reprsentant le support matriel pour une application rpartie ncessitant sur lun 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 Reprsentation d'une Structure d'excution. Les liens sont unidirectionnels sauf pour les accs la mmoire MC. Un lien doit exister entre chaque processeur et noeud (N1-->P2.1 et N1-->P2.2). Une signalisation peut tre produite et exploite par plusieurs processeurs. Un processeur de la structure d'excution peut se raffiner par une structure d'excution (cas de P2). Il en est de mme pour un noeud. Les rgles de bon sens nonces pour la cohrence et la lisibilit d'une structure fonctionnelle sont aussi applicables une structure d'excution: - commandabilit et observabilit de tous les lments: utilisation de toutes les entres et sorties, participation de tous les lments dans une relation. - choix d'un nom signifiant pour tous les constituants: le nom doit avoir un rapport explicite avec la fonctionnalit et le rle jou. - qualit de la prsentation: limitation de la complexit de chaque niveau de raffinement, reprsentation des relations de la gauche vers la droite. 356 M.C.S.E

Ch 17 - LE MODELE DEXECUTION 17.2.2. Interprtation d'une S.E Pour que la comprhension d'une reprsentation soit sans ambigut, nous donnons ci-aprs une explication du rle jou par chaque constituant d'une structure d'excution. Ceci revient modliser le comportement en externe de chaque type de constituant.
-A- COMPORTEMENT POUR LES PROCESSEURS

Les rgles suivantes caractrisent 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'excution. - Contrairement l'hypothse adopte pour les temps de droulement des fonctions du modle fonctionnel, la dure d'excution des oprations pour un processeur n'est pas nulle mais finie. Ces temps sont dfinis par les spcifications du processeur. - Un processeur peut tout instant lire ou modifier le contenu des mmoires qui lui sont connectes. Pour chaque accs, il dsigne l'information concerne. - Un processeur peut tout instant gnrer des signaux par ses sorties et transmettre des messages par ses canaux de communication en sortie. - Lorsqu'il le dsire, un processeur peut modifier son activit sur dtection d'une signalisation ou sur existence d'un message disponible sur l'un de ses canaux de communication en entre. Ainsi, le processeur est toujours matre de son activit.
-B- REGLES POUR LES MEMOIRES

Chaque mmoire se charge d'identifier si la variable concerne par la dsignation lors d'un accs lui appartient. Si c'est le cas, elle assure soit la mmorisation, soit la lecture suivant le sens de l'accs. La dure de chaque accs n'est pas nulle mais gnralement faible. Les accs dans le cas de demandes simultanes supposent que les contraintes d'intgrit se trouvent respectes. Ces conflits potentiels devront tre rsolus par la ralisation.
-C- COMPORTEMENT POUR LES NOEUDS DE COMMUNICATION

Un noeud de communication peut possder plusieurs entres et plusieurs sorties. Chaque entre est lie un processeur de manire offrir un canal de communication. Il en est de mme pour chaque sortie. Tout message mis par un processeur est accept dans son intgralit par le noeud de communication. Tout message demand est aussi accept dans son intgralit. 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 gnre un message vers chaque destinataire. L'identification du type de communication est aussi prcise dans le message. Un dlai quelconque peut exister entre la rception 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 disparat de la structure d'excution. M.C.S.E 357

Partie 5 - DEFINITION DE LA REALISATION Un noeud de communication nassure aucune transformation de linformation. Il peut par contre modifier sa prsentation.
-D- REGLES POUR LES SIGNALISATIONS

Toute signalisation sensibilise tous les processeurs lis. Mais elle n'est prise en compte que si les destinataires le dsirent. 17.2.3. Raffinement et abstraction d'une structure d'excution. Le modle de structure d'excution est hirarchique. Un lment peut se dcrire sur la base d'lments plus simples. En sens inverse, un lment utilisable peut rsulter 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 reprsente plusieurs niveaux de description. On peut montrer trs facilement que toute structure d'excution au niveau le plus microscopique peut se construire l'aide uniquement: de processeurs, de mmoires, de signalisations et de 2 types de relation. La relation par noeud de communication ajoute au modle et construite laide dune mmoire et de signalisations, apporte l'avantage d'une spcification un niveau plus macroscopique.
P0 N1 P1 P2

P2 N1.P1 P2.1

P2.1

-Figure 17.4- Niveaux hirarchiques d'une structure d'excution.


-A- CAS DES PROCESSEURS

Pour la dcomposition d'un processeur, tous les types d'lments et de relations sont utilisables. Le raffinement doit s'arrter lorsque les constituants sont clairement et suffisamment spcifis pour la phase de ralisation. La connaissance des possibilits fonctionnelles offertes par des composants, sous-ensembles, systmes, s'avre ncessaire pour viter un excs de raffinement. 358 M.C.S.E

Ch 17 - LE MODELE DEXECUTION Par abstraction, le concepteur peut dfinir un processeur ou un noeud de communication. Pour ce deuxime cas, la fonctionnalit se trouve dfinie par les rgles de comportement dcrites dans le paragraphe prcdent. D'autre part, les liens avec l'environnement ne peuvent tre que du type liens de communication.
-B- CAS DES NOEUDS DE COMMUNICATION

La dcomposition d'un noeud de communication peut se traduire: - par un rseau de noeuds de communication, - par une structure d'excution incluant des processeurs. Dans ce deuxime cas, le rle de la structure se limite servir de support pour satisfaire les fonctionnalits de communication du noeud. L'abstraction a pour objectif de construire des noeuds de communication partir dun ensemble de processeurs. La technique de raffinement ou d'abstraction pour un noeud de communication est illustre 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 Aprs avoir dcrit le comportement de chaque type dlment de manire disposer dune reprsentation graphique non-ambigu, dtaillons maintenant les spcifications ncessaires pour chaque constituant pour permettre de dduire sa ralisation. La structure d'excution ne peut servir de spcification pour la ralisation matrielle que si tous les constituants sont dcrits par leurs caractristiques externes. Une spcification doit tre suffisante pour dterminer une solution matrielle pour sa ralisation. On passe, ci-aprs en revue chaque catgorie de constituant pour prciser sa spcification. M.C.S.E 359

Partie 5 - DEFINITION DE LA REALISATION 17.3.1. Spcification d'un processeur Pour un processeur, la spcification est particulirement variable compte-tenu du caractre gnral associ ce terme. Un processeur spcialis est caractris par: - la spcification de ses entres et ses sorties sur le plan type et nature de l'information, - sa fonctionnalit: tous les modles de spcification prsents dans ce document sont bien sr utilisables. Par exemple: gabarit en frquence pour un filtre analogique, la prcision, et la vitesse de conversion pour un convertisseur numrique/analogique. Un processeur gnral programmable est caractris par: - la spcification de ses entres et ses sorties, - la spcification de tous les attributs du processeur, savoir: la capacit mmoire pour les instructions, pour les donnes, la classe de processeur (8, 16, 32 bits), la performance pour des oprations type, - la spcification de fonctions internes ncessaires pour l'application: horloge programmable, compteurs, calcul en flottant, ainsi que les fonctions ncessaires pour les entres/sorties: conversion analogique/numrique, transmission-rception srie ... En fait, un processeur programmable peut se dcrire par des spcifications trs varies. Il est possible de cette manire de rduire le travail de raffinement d'une structure d'excution. Ceci va dans le sens de l'volution de la technologie qui met de plus en plus notre disposition des processeurs intgrant dans un seul composant une varit de fonctions spcialises en complment de la fonction typique du microprocesseur comme unit centrale de traitement. 17.3.2. Spcification d'une mmoire Une mmoire est caractrise par: sa capacit en nombre d'informations (octet comme unit), la taille de chaque information manipule par accs, le nombre d'accs simultans en lecture, en criture, le temps maximum pour chaque accs.

17.3.3. Spcification d'un noeud de communication Un noeud de communication est caractris par : - le nombre d'entres et de sorties et le type d'information change. Un type spcifique peut s'associer chaque entre ou sortie, mais il est plus raliste de se limiter si possible un seul type de messages. - la capacit de mmorisation du noeud en nombre de messages. Cette capacit peut tre globale ou spcifique pour chaque paire d'entre/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 transfrables par unit de temps. 360 M.C.S.E

Ch 17 - LE MODELE DEXECUTION 17.4. PROPRIETES DU MODELE DEXECUTION L'objectif du modle d'excution est de servir comme guide pour l'laboration des spcifications du support matriel pour une application. Citons rapidement les proprits essentielles de ce modle.
-A- MODELE DE STRUCTURE

Tout comme le modle fonctionnel, le modle d'excution est hirarchique. Il favorise donc la comprhension ou la recherche progressive de la solution. Les techniques de raffinement et d'abstraction permettent, pour la premire, d'introduire des contraintes supplmentaires pour la ralisation matrielle, pour la seconde, de favoriser la rutilisation par la spcification de processeurs logiques ou virtuels.
-B- MODELE INTERPRETABLE

La seule connaissance des rgles de comportement des constituants et leurs spcifications est suffisante pour dduire une solution technologique pour la ralisation matrielle. Ce document est donc suffisant comme interface entre l'tape de dfinition de la ralisation et l'tape suivante de ralisation. De par sa simplicit, il favorise la lisibilit ce qui est favorable pour la vrification et lutilisation.
-C- INVARIANCE DECHELLE

Ceci veut simplement dire que le modle permet aussi bien de dcrire les spcifications de solutions un niveau trs proche des composants, et mme la structure interne de composants, registres, rseaux combinatoires, horloge ... ,que des spcifications de systmes un niveau trs macroscopique: application rpartie utilisant des calculateurs, rseau local, rseau de tlcommunication.
-D- SIMILITUDE : MODELE FONCTIONNEL/MODELE DEXECUTION

Il y a similitude de reprsentation des 2 modles. Cette caractristique est particulirement favorable pour passer de l'tape 2: solution fonctionnelle, l'tape 3: dfinition des constituants de la ralisation. Dans le cas le plus direct, il suffit simplement de considrer une structure d'excution de topologie identique celle de la structure fonctionnelle.
-E- MAXIMUM DE PARALLELISME

Lorsqu'une structure d'excution est compltement dtaille, et en considrant que chaque processeur n'excute qu'une seule opration la fois, le degr maximum de paralllisme est gal au nombre de processeurs lmentaires. Si les performances ne s'avrent pas suffisantes, il faut revoir la structure d'excution en augmentant soit le nombre de processeurs, soit les performances de certains processeurs.
-F- INTRODUCTION DE REDONDANCES ET DE TESTS

Une structure d'excution peut s'enrichir de constituants supplmentaires de manire rpondre des contraintes telles que sret, 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 dduction des constituants supplmentaires ncessaires se fait en considrant les situations de pannes probables et qui ne doivent pas dgrader les caractristiques de l'application. M.C.S.E 361

Partie 5 - DEFINITION DE LA REALISATION 17.5. RESUME Ce chapitre a permis de prsenter le modle de description utilis pour spcifier la 3me dimension dite excutive du modle global. Rappelons les conclusions essentielles: - le modle d'excution est compos de 2 ensembles d'information: la structure d'excution, la spcification de tous les constituants pour la ralisation, - les techniques de raffinement et d'abstraction sont utilisables pour dfinir les spcifications d'un processeur ou d'un noeud de communication, - la dcomposition ne doit pas tre poursuivie trop loin. Elle doit simplement favoriser la recherche de la solution matrielle dtaille sans imposer de contraintes de choix supplmentaires par rapport aux spcifications technologiques. - le modle d'excution n'est pas suffisant pour la ralisation puisqu'il ne concerne que la partie matrielle. Il faut y ajouter la spcification du logiciel pour les processeurs programmables. C'est l'objectif du modle dintgration dcrit dans le chapitre suivant.

362

M.C.S.E

Chapitre 18

LE MODELE DINTEGRATION

Une description fonctionnelle exprime une solution indpendante de la technologie pour l'application considre. Une structure d'excution dcrit le support matriel. Pour complter la dfinition d'une ralisation, il faut y ajouter la correspondance fonctionnel > matriel et la description de la partie logicielle. L'organisation du logiciel dcoule: d'une part de la description fonctionnelle qui exprime l'objectif satisfaire, d'autre part de la structure d'excution retenue comme support oprationnel. Le modle d'intgration a pour objectif de spcifier compltement l'implantation d'une description fonctionnelle sur une structure d'excution. Si dans la dmarche de conception le but est de dduire une structure d'excution et une implantation partir dune description fonctionnelle, pour la prsentation du modle dintgration, on se place ici dans le cas o la description fonctionnelle et la structure d'excution sont donnes. Comme le montre ce chapitre, l'intgration concerne 2 niveaux: le niveau structure d'excution et le niveau processeur. Pour le niveau global, la structure fonctionnelle complte doit simplanter sur la structure dxcution. Pour chaque processeur programmable, la fonctionnalit rsulte dune implantation sous la forme dun schma dorganisation du logiciel.

M.C.S.E

363

Partie 5 - DEFINITION DE LA REALISATION 18.1. LE MODELE DINTEGRATION ET SES CONSTITUANTS Le modle dintgration spcifie deux niveaux dimplantation. Tout d'abord, tant donn un support d'excution, chacun de ses constituants est le support oprationnel pour un ou plusieurs constituants de la structure fonctionnelle: - un processeur pour une structure fonctionnelle partielle, - une mmoire pour des variables d'tat, - un noeud de communication pour les ports. Cette correspondance S.F.-->S.E. reprsente l'ALLOCATION. Ensuite, pour chaque association du type: processeur gnral<-->structure fonctionnelle partielle, la fonctionnalit est obtenue par logiciel. Aussi dans ce cas, les rgles d'implantation de la structure fonctionnelle sur le processeur sont exprimer. Ainsi le modle d'intgration est constitu de 2 parties: - le modle d'allocation qui dcrit la correspondance entre une structure fonctionnelle et une structure d'excution, - le modle d'implantation qui dcrit les rgles d'implantation de chaque sousensemble de la description fonctionnelle ralis par logiciel sur le processeur programmable allou comme support. La composition du modle d'intgration est reprsente ci-aprs.
FONCTIONNEL INTEGRATION EXECUTIF

Structure fonctionnelle

Allocation

Structure dxcution

Sous-ensembles fonctionnels

implantation

constituants

Structure fonctionnelle partielle pour les processeurs programmables Implantation Processeur

Implantation logicielle

-Figure 18.1- Les constituants du modle d'intgration. Pour une application donne, il n'existe qu'une seule dfinition de l'allocation: elle exprime lensemble des relations entre les constituants de la structure fonctionnelle et ceux de la structure dxcution. Mais il existe autant de dfinitions d'implantation que de processeurs gnraux. 364 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.2. LE MODELE DALLOCATION La similitude des modles - structure fonctionnelle, structure d'excution - favorise la correspondance entre les 2 structures. Chaque structure est compose d'lments et de relations entre ces lments. Ainsi, le modle d'allocation dtaille les correspondances entre lments des 2 structures et les contraintes de correspondance respecter. 18.2.1. Correspondance entre les lments des 2 structures La correspondance entre lments est la suivante : structure fonctionnelle partielle (SF) variables (VE) vnements (EV) ports (PT) liens: fonction <-->EV,VE,PT --> --> --> --> --> processeur (P) mmoire (M) signalisation (S) noeud de communication (N) lien: processeur <-->S,M,N

Les rgles ci-aprs sont respecter pour toute correspondance: - Une fonction lmentaire est une unit de description et de rpartition. De ce fait elle est indivisible pour l'implantation. Son activit rsultera de lutilisation dun seul processeur. Si cette hypothse nest pas possible, la dcomposition 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, mmoire, noeud de communication peuvent chacun supporter plusieurs lments, respectivement : fonctions, variable d'tats, ports. - Un processeur gnral est le support d'une structure fonctionnelle partielle ou complte. Les 2 premires rgles ci-dessus indiquent que la dcomposition fonctionnelle a t pousse suffisamment loin pour permettre l'intgration. Les 2 dernires rgles indiquent la possibilit de rduire la complexit d'une structure d'excution. En effet, un processeur programmable est gnralement trop puissant comme support pour uniquement une fonction lmentaire. Il en est de mme pour la capacit d'une mmoire ou d'un noeud de communication. La rduction du cot du support matriel passe par la rduction du nombre de processeurs, de mmoires, de noeuds de communication, ce qui rduit simultanment le nombre de liaisons physiques raliser. La rduction essentielle s'obtient en implantant sur chaque processeur une structure fonctionnelle la plus importante possible. L'exemple suivant montre 2 formes: la premire graphique, la deuxime textuelle pour dcrire les correspondances entre lments. M.C.S.E 365

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle Structure dexcution 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 lments. Pour les lments: 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 lments d'une structure fonctionnelle doivent obligatoirement avoir un correspondant sur la structure d'excution. Par contre, tant donn une structure d'excution, tous les lments ne servent pas obligatoirement pour l'application. 366 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.2.2. Contraintes pour une allocation Une allocation nest correcte pour lapplication que si pour les correspondances retenues, des rgles sont garanties. 2 types de rgles sont respecter: - tout d'abord comme un processeur peut servir de support excutif pour plusieurs fonctions, celui-ci doit tre apte engendrer les volutions souhaites en respectant toutes les contraintes de temps. Le respect de cette rgle exprime le fait que chaque processeur est OPERATIONNEL pour l'allocation retenue. - ensuite la correspondance entre les lments des 2 structures n'est correcte que si toutes les relations de la structure fonctionnelle sont ralisables par la structure d'excution. Dans ce cas, on dira que la structure fonctionnelle est ACCEPTEE par la structure d'excution. Dtaillons dans la suite du paragraphe, les rgles de vrification pour chaque catgorie.
-A- PROCESSEUR OPERATIONNEL

Un processeur sert de support excutif pour une ou plusieurs actions. S'agissant d'applications temps-rel, des contraintes de temps sont associes chaque action: frquence d'activation, dure d'excution maximale ou date de fin pour les actions temporaires, performances pour les actions permanentes. Un processeur est dit OPERATIONNEL pour une allocation donne si toutes les actions sont effectues et si toutes les contraintes de temps sont satisfaites pour la ralisation qui dcoule de cette allocation. Le caractre oprationnel dpend de plusieurs facteurs: - la complexit de la structure fonctionnelle supporter : nombre et nature des actions et des oprations, - les contraintes de temps respecter, - la performance du processeur. Une allocation se modifie en changeant les correspondances, et/ou en changeant les spcifications du processeur. Les rgles pour la vrification seront dtailles dans le chapitre suivant en 19.5. On retiendra pour l'instant les 2 rgles suivantes : - le taux d'occupation maximum du processeur pour toutes les actions temporaires (i=1,n) doit rester infrieur 1: Tocc = i FAi*TEi < 1. Pour une action, le taux d'occupation maximum (Tocci) est le produit de sa frquence d'activation maximale (FAi) par son temps d'excution maximum (TEi). Le taux dpend donc de la performance du processeur par le terme TEi. - les dures d'excution maximales, dates de fin (deadline), les temps de raction sur vnement externe sont toujours satisfaits. La figure 18.3 illustre le droulement sur un mme processeur de deux actions concurrentes pour une excution de A1 plus prioritaire que A.
-B- STRUCTURE FONCTIONNELLE ACCEPTEE

Pour l'implantation, les relations fonctionnelles internes un processeur sont ralises par celui-ci. Par contre, les relations entre 2 processeurs ncessitent des liens matriels 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 mme processeur


priorit

ev1

A1 ev2 A2

TFin < Tdeadline A2

Temps disponible => Tocc < 1

-Figure 18.3- Illustration des 2 rgles pour une allocation. Pour vrifier qu'une structure fonctionnelle est accepte par une structure d'excution, il faut utiliser les correspondances entre lments pour construire une structure fonctionnelle rduite. La rduction est obtenue par une opration d'abstraction qui consiste regrouper tous les constituants (fonctions, variables, ports) implants sur un mme processeur. La structure ainsi obtenue doit tre inclue au sens des graphes dans la structure d'excution. Ceci veut dire qu'il faut au moins un lien au niveau excutif comme support pour chaque lien fonctionnel. La figure 18.4 montre cette dmarche de vrification. 18.3. LE MODELE DIMPLANTATION POUR CHAQUE PROCESSEUR Pour les processeurs programmables, l'allocation dfinit le sous-ensemble fonctionnel implant sur chaque processeur. Le modle d'implantation dfinit les rgles de prsentation des constituants de ce sous-ensemble fonctionnel pour exprimer l'organisation de tous les constituants du logiciel. Le logiciel implant sur un processeur est dcomposable en 2 niveaux: - le niveau TACHES: une tche est une entit compose d'instructions et de donnes, ayant sa propre autonomie. Pour le processeur, la tche est manipule comme un tout: activation, arrt, suspension. Une tche assure gnralement une fonction ou une action de l'application. Son comportement est squentiel. L'tat d'une tche dfini par une variable appele vecteur d'tat, est mmoris entre 2 activations successives. Une tche a donc un effet mmoire. 368 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION

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 rduite SF*

Structure dexcution

-Figure 18.4- Correspondances: S.F. globale, S.F. rduite et S.E. - le niveau MODULES ou PROCEDURES. Un module est un ensemble dinstructions activ comme une unit par une tche, pour satisfaire une fonction ou une opration. La tche tant squentielle, un seul module est actif la fois. Un module est sans effet mmoire, ce qui veut dire que ses variables internes ont la dure d'excution du module. Le niveau TACHES concerne un ensemble de tches. L'volution est donc potentiellement parallle. Or, habituellement un processeur est squentiel. Aussi une stratgie d'ordonnancement pour le partage du processeur par les tches est donc ncessaire pour que, vue par l'application, l'volution de l'ensemble des tches apparaisse parallle. Pour le niveau MODULES, chaque tche se dcompose comme une hirarchie de modules. Le modle 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 modle est reprsente par la figure 18.5. 18.3.1. Implantation des tches Le niveau tche explique l'implantation retenue pour une structure fonctionnelle donne sur un processeur. Le paralllisme inhrent la structure fonctionnelle (normalement gal au nombre de fonctions) est habituellement suprieur celui-ci du processeur qui trs souvent est de 1. Ensuite les relations entre les fonctions -par vnement, par variable d'tat, par port- ne sont pas des mcanismes directement supports par le processeur. Enfin, le processeur coupl son environnement doit satisfaire par des liens matriels les relations fonctionnelles existant entre la structure fonctionnelle qu'il supporte et lenvironnement de celle-ci. L'implantation est reprsente graphiquement par un rseau de tches. Les tches sont lies entre elles par des variables d'tat, des transferts de contrle, et sont lies avec l'environnement par des variables et des vnements en entre et sortie. M.C.S.E 369

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle partielle Implantation

Processeur programmable

IMPLANTATION LOGICIELLE

Spcification des tches

Implantation des tches

niveau tches

Implantation Spcification des modules des modules

niveau modules

-Figure 18.5- Dcomposition pour l'implantation. Comme habituellement, une seule tche est excute la fois par le processeur, un ordonnancement des tches est ncessaire selon un critre. Pour cela chaque tche est associe une priorit d'excution. Ainsi pour la reprsentation, l'axe vertical reprsente l'axe croissant des priorits. Le processeur tant toujours en activit, en l'absence de tches temporaires excuter, celui-ci excute une tche particulire appele tche de FOND. La figure ci-aprs est un exemple de schma dimplantation.
Priorit croissante

PAS T1

T3 V1

REU T2 T4 B2 V5

T0 TACHE DE FOND

Matriel

Logiciel

Matriel

-Figure 18.6- Exemple d'implantation de tches. 370 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Les tches lies des vnements en entre (vnements matriels situs gauche et donc tches actives par interruption) sont actives sur apparition de chaque vnement. Une telle tche volue lorsqu'elle dispose du processeur, ce qui est le cas lorsquune tche active est plus prioritaire que la tche courante excute par le processeur. Ceci rsume la technique dordonnancement retenue, priorit fixe et processeur allou la tche active la plus prioritaire. Dans le sens vertical, le transfert de contrle entre 2 tches et donc d'allocation du processeur, est reprsent par un lien double trait. Ce type de transfert, qui sera du type appel de procdure (call, return), n'est possible que dans le sens croissant des priorits. La rgle de comportement est la suivante:
Priorit Acquisition du contexte de A2
A2 appel de A2 fin dexcution de A2

Sauvegarde du contexte de A2

A2

A1

suspension de A1

A1

-Figure 18.7- Comportement pour un transfert de contrle. Lorsque A1 disposant du processeur dcide durant son volution de passer le contrle A2 (synchronisation de A2 sur un vnement gnr par A1 par exemple), le processeur est alors pass A2. A2 conserve le processeur jusqu' sa fin d'excution. Le transfert inverse redonne le processeur A1 qui poursuit alors son activit. A2 est donc obligatoirement temporaire, A1 peut tre permanente ou temporaire. Ce mcanisme de transfert de contrle est tout simplement celui de l'appel procdural, A2 est implante comme une procdure, le transfert se fait par un CALL avec sauvegarde du point de ractivation de A1. Le retour se fait par RET en utilisant le point de retour sauvegard. Ainsi ce mcanisme simple permet trs naturellement d'induire des relations d'ordre d'excution pour des tches. Attention tout de mme car pour le modle d'implantation A2 est toujours une tche et non pas simplement une procdure, car il possde ses variables internes propres qui ont une dure de vie suprieure celle de chaque activation. L'excution de A2 par un appel procdural implique donc que cette excution par le processeur dbute par une rcupration du contexte ou vecteur d'tat de A2 et se termine par une mmorisation de son vecteur d'tat pour la prochaine activation. Ce modle est aussi hirarchique. Une tche peut se raffiner par un rseau de tches. 18.3.2. Implantation de chaque tche Une tche lmentaire est considre non dcomposable en tches car le droulement de ses oprations est purement squentiel. La complexit d'une telle tche lmentaire est trs variable selon sa fonctionnalit. Pour quelques oprations, une dcomposition supplmentaire n'est pas ncessaire car l'criture du code est directe. Par contre pour une fonctionnalit qui M.C.S.E 371

Partie 5 - DEFINITION DE LA REALISATION ncessite un programme complexe, une dcomposition est souhaitable pour favoriser une implantation modulaire et structure. Le modle de structure de modules, ou structure chart de Yourdon et Constantine est ici prconis comme modle pour la description de chaque tche (voir 7.4). Rappelons que les lments de base de ce modle sont le module et la donne partage. Ce modle est hirarchique. Il permet de reprsenter la dcomposition d'une tche en units plus lmentaires. Les relations avec les modules subordonns sont reprsentes par les liens d'appel. A chaque lien d'appel sont associs des arguments d'entre et de sortie qui peuvent tre de 2 types: donne ou contrle. Les structures de contrle sont: le squencement, lappel, litration, lalternance. Les donnes internes un module ont la dure de vie de l'appel du module. Des donnes externes sont accessibles aux modules. La dure de vie de ces donnes est celle de l'application. 18.3.3. Spcification de chaque lment En complment des structures de tches et de modules, la spcification de l'implantation n'est complte que si tous les lments sont spcifis. On passe ci-aprs en revue chacune des catgories.
-A- LES TACHES

Chaque tche doit tre spcifie: entres, sorties, les conditions d'activation, le rle pour l'application exprim par la ou les fonctions de la description fonctionnelle que la tche doit assurer, la description de son vecteur d'tat. Les contraintes de temps sont aussi prciser: performances, temps d'excution maximum, dlais de raction.
-B- LES DONNEES PARTAGEES

Il s'agit, d'une part des variables d'tat qui servent pour le couplage entre les tches, et d'autre part des donnes externes ncessaires aux modules. La spcification de ces donnes se dduit de la description fonctionnelle: structure, domaine, prcision, ... Certaines informations d'implmentation peuvent tre ajoutes: dfinition de la reprsentation des donnes, ordonnancement des donnes et mcanisme d'accs.
-C- LES MODULES

Chaque module doit aussi tre dcrit par une spcification. Cette spcification doit permettre par la suite un codage correct sans qu'il s'agisse pour cela d'crire les programmes. La plupart des spcifications des modules dcoulent de la description fonctionnelle ; des fonctions compltes ou des portions de celles-ci se trouvent en fait implantes comme modules. 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION Une implantation reprsente une traduction de la structure fonctionnelle retenue sur le processeur. Tous les lments de la structure fonctionnelle doivent se retrouver dans l'implantation. Lobjectif est aussi de rduire la complexit de la ralisation qui en dcoulera. Ainsi des rgles sont respecter pour obtenir cette traduction. Dtaillons ces rgles pour les catgories d'lments et de relations. 372 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.4.1. Correspondance: Fonctions > Tches Pour l'implantation, une tche est l'unit dexcution. Elle correspond une fonction lmentaire ou un regroupement de plusieurs fonctions de la structure fonctionnelle. Tout dabord le regroupement concerne habituellement plusieurs fonctions actives simultanment par le mme vnement. La figure suivante illustre ce type de regroupement, la dcomposition tant exprime par une structure de modules.
PARAM Contrle Coordination PAS Contrle T T T Mise jour de T PAS Rgulation Mise jour de T T Tche Contrle

Vc

Vc T

Vc

Coordination

Rgulation

Horloge

Structure fonctionnelle

Schma dimplantation

PARAM

-Figure 18.8- Traduction avec regroupement de fonctions. La tche est active par lvnement matriel PAS. Le module principal CONTROLE assure lexcution squentielle des 3 modules qui rsultent dune transformation de chaque fonction en procdure. Ensuite les actions permanentes sont obligatoirement regroupes dans la tche de fond. Le partage du processeur est alors assur par commutation rgulire pour l'allocation du processeur aux diffrentes fonctions de la tche. La tche de fond joue ainsi le rle d'ordonnanceur comme lindique la figure ci-dessous.
Structure fonctionnelle Schma dimplantation

F1

Squenceur
V F2 V F3 F1 F2 F3 V

Tche de fond

-Figure 18.9- Implantation de plusieurs fonctions dans la tche 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 conserves dans l'implantation. Comme les tches ont des priorits diffrentes, le couplage interne par variable se reprsente par des liens verticaux. Le regroupement de fonctions dans une mme tche peut induire le regroupement de variables accessibles en entre et en sortie. D'autre part, pour un regroupement d'actions dans une mme tche, des variables d'tat d'actions deviennent des variables internes globales de la tche. 18.4.3. Traduction des synchronisations par vnement L'vnement peut tre d'origine matrielle (entre pour le processeur) ou d'origine logicielle (interne au processeur). Suivant le cas, 3 principes sont applicables pour la traduction : Premier principe: un vnement est transformable en une variable boolenne. Dans ce cas, la fonction temporaire qui en dpend n'est plus active par l'vnement. Elle doit alors obligatoirement observer l'volution de la variable boolenne quivalente pour dcider des instants d'volution. Dans ce cas, la fonction est alors transforme en une action permanente et est intgre dans la tche de fond. Deuxime principe: une synchronisation interne (donc logicielle) se transforme suivant la priorit des 2 fonctions: - priorit infrieure du gnrateur: appel procdural, - priorit suprieure du gnrateur: positionnement d'une variable boolenne indiquant la gnration de l'vnement. Cette variable doit tre observe rgulirement pour engendrer l'volution du correspondant. Ce rle est affect une tierce fonction, gnralement la tche de fond. Ces 2 cas de transformation sont illustrs par l'exemple ci-aprs.
EV F1 F2

Prior. F2 > Prior. F1


F1 F2

Prior. F1 > Prior. F2

F2 EV EV EV

F1

F3

-Figure 18.10- Illustration pour limplantation dune synchronisation. 374 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Troisime principe: une synchronisation par un vnement externe s'implante efficacement en utilisant le mcanisme d'interruption du processeur. Dans ce cas, aucune transformation n'est faire. Il suffit simplement d'associer la tche un niveau d'interruption correspondant sa priorit relative par rapport aux autres tches implantes sous interruption. 18.4.4. Traduction pour des transferts par messages Un message est l'association d'un vnement et d'une donne. Les principes noncs 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 partage couramment appele Bote lettres (symbole )et compose de 2 parties : - la zone servant au dpot des messages. Cette zone est obligatoirement de capacit finie (tampon ou buffer), - un indicateur prcisant le nombre de messages disponibles dans la zone. Pour se servir de cette bote lettres, les fonctions producteur et consommateur doivent alors tester la valeur de l'indicateur avant dentreprendre une opration de dpt ou de retrait. Le consommateur est dans ce cas obligatoirement transform en une action permanente. Si la bote lettres est pleine, le producteur doit attendre un retrait, si elle est vide le consommateur doit attendre un dpt. Deuxime principe: un transfert de messages entre deux fonctions logicielles se transforme suivant les priorits relatives de celles-ci: - priorit infrieure du producteur: utilisation de l'appel procdural pour activer le consommateur, - priorit suprieure 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 illustrs 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 dimplantation pour un transfert par messages. M.C.S.E 375

Partie 5 - DEFINITION DE LA REALISATION Troisime principe: Le transfert de messages doit se faire avec l'environnement matriel. Il se fait de prfrence lment par lment (par exemple caractre par caractre). La bote lettres de couplage a alors une capacit de 1. Ceci n'est pas une rgle obligatoire (utilisation d'une FIFO par exemple), mais elle est simple sur le plan technologique. Le couplage entre le matriel et le logiciel se fait en transformant la bote lettres en une variable pour le dpt et 2 vnements pour la synchronisation bidirectionnelle. Un vnement peut se transformer en variable boolenne en particulier dans le sens logiciel vers matriel. Les 2 vnements peuvent aussi tre transforms en une seule variable boolenne bidirectionnelle. La figure suivante montre une traduction pour les deux cas: en provenance du matriel pour M1, vers le matriel pour M2. Pt est transform selon le deuxime principe.
Matriel Logiciel Matriel

M1 F1 F2

Pt F3

M2 F4

Emis

M2.Dpt

M1.V F1 F2

(Pt) F3

M2.V F4

M1.retrait

reu

Prior. F3 > Prior. F2

-Figure 18.12- Exemple de traduction. Cette traduction montre les solutions matrielles usuelles assurant un couplage correct entre producteur et consommateur: technique de l'change par poigne de main (handshake). 18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL Un processeur programmable peut avoir des niveaux de complexit trs variables. Dj entre les processeurs 8 bits type 8085 ou microcontrleurs et les processeurs volus 32 bits tels que le transputer T800, des diffrences essentielles existent. Tout microprocesseur est squentiel pour l'excution des instructions. Il n'excute ainsi qu'une seule tche la fois. Si ncessaire, le paralllisme ne s'obtient qu' un niveau macroscopique, par commutation du processeur vis vis de tches laide de mcanismes matriels tel que le systme d'interruption ou grce l'ajout d'un logiciel charg de grer le partage du processeur. 376 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Un systme informatique considr globalement comme un processeur pour les fonctions logicielles implanter, dispose de mcanismes permettant l'excution simultane ou pseudosimultane de tches. Ces mcanismes sont offerts par un noyau excutif appel moniteur multi-tches temps-rel ou excutif temps-rel. La disponibilit de ces mcanismes facilite le travail d'implantation. En effet, l'objectif tant de rduire la partie organisationnelle dvelopper, cette partie se traduit directement sous la forme d'appels l'excutif temps-rel. Ainsi, plusieurs techniques d'implantation sont disponibles pour les tches suivant le niveau du processeur et donc suivant ses spcifications ou ses caractristiques. La suite du paragraphe montre l'implantation d'un mme exemple dans les 2 cas: sans moniteur temps-rel et avec moniteur temps-rel. Sont aussi indiqus les critres considrer pour dcider de la technique utiliser. 18.5.1. Implantation sans moniteur temps-rel Dans ce cas toutes les relations entre les actions de la structure fonctionnelle implanter sur le processeur doivent tre transformes selon les rgles dcrites dans le paragraphe prcdent. L'exemple suivant est donn titre d'illustration d'une implantation complte avec prior T0 > prior T2 > prior T1. Ce mme exemple sera utilis pour prsenter la solution avec un moniteur temps-rel.
Structure fonctionnelle
EV Ev T0 T2 Prt B pour MESS Prt T1 T2 T1 (Mess) T0

priorit

MESS

Tache de fond

-Figure 18.13- Schma d'implantation sans excutif temps-rel. La tche T0 est active par l'vnement matriel EV. Ainsi, elle rcupre inconditionnellement le processeur. T0 est donc plus prioritaire que toutes les autres tches. La synchronisation entre T0 et T1 selon une priorit dcroissante est faite par l'intermdiaire de la Bote lettres B et de la tche de fond. Le comportement de la tche de fond est le suivant:
cycle: if B.Nb_messages>0 then begin Retrait_message (B, Mess); T1(Mess); end; end cycle;

Ainsi la tche de fond scrute rgulirement si un message est disponible dans B. Si oui, le premier message est retir et transmis T1 pour excution. M.C.S.E 377

Partie 5 - DEFINITION DE LA REALISATION La priode de scrutation par la tche de fond dpend de l'occupation du processeur traiter les tches temporaires (ici uniquement T0). Cet exemple montre la simplicit de la mthode d'implantation et la simplicit de la partie organisationnelle qui en dcoule. 18.5.2. Implantation avec un excutif temps-rel L'excutif temps-rel dans ce cas est voir comme une tche ayant la priorit la plus leve et sollicite par toutes les autres tches par appel procdural. La plus grande priorit est justifie pour que cet excutif puisse requrir le processeur lorsqu'il le dsire de manire assurer correctement son rle d'ordonnancement. La figure suivante montre le schma d'implantation d'une structure fonctionnelle avec utilisation de 4 primitives temps-rel: SIGNAL et WAIT pour la synchronisation, SEND et RECEIVE pour le transfert de messages.
priorit
Excutif temps-rel
Ev T0 EV Tit
Wait(EV) Signal(EV) Send (V,MESS) Wait(Prt)

T0 MESS
Receive(V,MESS)

T2
Signal(Prt)

T1 Prt T1 T2

Tache de fond

matriel

logiciel

-Figure 18.14- Schma d'implantation avec un excutif temps-rel. L'implantation ci-dessus montre bien le rle dordonnanceur jou par l'excutif temps-rel. Les vnements externes pris en compte comme interruptions par le processeur sont grs par une tche trs courte (Tit) qui se contente de signaler au moniteur temps-rel les vnements reus. Toutes les demandes faites par les tches l'excutif se font par appel procdural. Si la demande implique une attente, l'instant de retour la tche appelante est dcid par l'excutif. L'ordre de retour et donc d'allocation du processeur la tche appelante est totalement sous le contrle de l'excutif. C'est une raison supplmentaire pour que cette tche soit reprsente comme la plus prioritaire. Pour la comprhension du schma d'implantation, on donne figure 18.15 une squence de droulement pour les 3 actions T0, T1, T2. L'excutif est donc ici vu comme une tche particulire unique sollicite par toutes les tches du processeur pour chaque action particulire. L'excutif possde donc de multiples points d'entre. Il gre l'ordonnancement des retours aux tches appelantes sur la base de variables internes qui reprsentent l'tat de toutes les tches, des relations, des demandes ... 378 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION

Priorit Attributions du processeur


Excutif

Ev
Signal (EV) wait Send (V,MESS) wait (EV) Signal (prt) (prt) Receceive (V,MESS)

TIT

wait (EV)

wait (prt)

Receive (V,MESS)

T0 T2 T1 Tche de fond

T0 T2 T1

Ev

Initialisation

Droulement
T0

T2

T1

-Figure 18.15- Exemple de droulement d'excution. Si pour un cas simple, l'excutif peut se comprendre comme une simple tche, habituellement, compte-tenu des mcanismes offerts: dlai, activation priodique, synchronisation sur vnements externes ..., un excutif est lui-mme compos d'un ensemble de tches. Le couplage entre ces tches peut tout fait se dcrire par le modle d'implantation dcrit dans ce chapitre. La mthode prsente s'avre donc utilisable par les concepteurs d'excutifs. Pour les applications utilisant un excutif temps-rel, le schma d'implantation dcrit par la figure prcdente n'est pas ncessaire. Il a seulement t donn pour expliquer le rle jou par un excutif. Dans ces cas d'applications, il suffit simplement: - de dterminer la priorit de chaque tche, - de traduire chaque relation fonctionnelle par le ou les mcanismes de l'excutif disponibles et appropris. La figure 18.16 montre la reprsentation suffisante pour une telle implantation. Certains processeurs possdent en standard dans leur jeu d'instructions des mcanismes de synchronisation et d'change de donnes. C'est le cas par exemple du TRANSPUTER d'INMOS. La disponibilit de tels mcanismes implique que le processeur assure de lui-mme l'ordonnancement des tches. Le travail du concepteur se trouve alors simplifi (voir 22.8). Pour le concepteur d'applications, la seule diffrence qui existe entre ce type de processeur prvu pour la gestion du paralllisme et un processeur plus classique auquel on associe un excutif temps-rel, est que dans le deuxime cas, il faut ajouter l'excutif comme logiciel. Les performances sont alors moindres par suite du temps ncessaire pour lexcution 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(prt)

MESS

Prt

receive(V,MESS)
T1

signal(prt)

-Figure 18.16- Schma d'implantation bas sur un excutif Temps-Rel 18.5.3. Critres de choix de la technique d'implantation Il est vident que pour rduire le temps de dveloppement d'une application, il est prfrable de disposer d'un excutif. La solution logicielle est plus coteuse en place mmoire, en temps de traitement des sollicitations (temps de commutation ou overhead), et en terme de prix lorsque l'excutif est un produit standard du commerce (VRTX, PSOS, iRMX, noyau SCEPTRE...). L'excutif intgr dans la fonctionnalit du processeur est la solution la plus avantageuse et correspond une tendance qui va probablement se gnraliser. Elle permet au concepteur de voir le processeur comme un excutif direct multi-tches, ce qui rduit le travail d'implantation. Le concepteur n'a pas dans ce cas besoin de descendre au niveau de l'ordonnancement de ses tches. Toutefois, il lui faut toujours dterminer la priorit relative des tches. 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 excutif ou la dfinition complte de l'implantation. C'est au concepteur de dcider la meilleure solution sur la base de critres techniques et conomiques. Les critres considrer sont: - les contraintes de temps pour l'application. Pour de trs fortes contraintes, il faut dfinir une implantation complte sans excutif, car c'est la solution qui rduit au maximum les temps de commutation des taches (overhead). - le nombre d'exemplaires. Pour quelques exemplaires, l'emploi d'un excutif rduit le temps de dveloppement. Pour un grand nombre, comme il faut rduire le cot de chaque exemplaire, ceci implique fort probablement de se passer d'un excutif standard. - la complexit de l'application. Pour de petites applications ddies bien spcifies, l'implantation directe restera simple et efficace. Pour des applications complexes avec des spcifications volutives, un excutif temps-rel est certainement favorable. 380 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.6. CARACTERISTIQUES DU MODELE DINTEGRATION Le modle de description d'un systme est bas sur l'association de 3 dimensions ou 3 vues: topologique, comportementale, excutive. La dimension excutive reprsente le support "matriel" qui engendre l'volution de l'application. Une application oprationnelle rsulte d'une association correcte de la dimension fonctionnelle avec la dimension excutive. C'est l'objectif du modle d'intgration que de spcifier les rgles de correspondance entre ces 2 ensembles, puis pour les ralisations logicielles, la structuration pour l'implantation. Les caractristiques essentielles induites par le modle dintgration sont prsentes ciaprs.
-A- MODELE DE STRUCTURE

Ce modle est compos de 2 parties complmentaires. Tout d'abord le modle d'ALLOCATION dfinit la correspondance : fonctionnel --> excutif, ensuite le modle d'IMPLANTATION dfinit l'organisation d'une structure fonctionnelle sur chaque processeur. Ce dernier modle est hirarchique avec 2 niveaux d'organisation: le niveau TACHES et le niveau MODULES. La spcification de la ralisation en sous-ensembles hirarchiques avec des interfaces compltement spcifies, est favorable pour une rpartition du travail de ralisation sur plusieurs quipes.
-B- ALLOCATION COMME RESULTAT DUNE ABSTRACTION

Le modle d'ALLOCATION dcrit des regroupements d'lments d'une structure fonctionnelle. A chaque regroupement est associ un processeur pour l'excution. Une telle transformation s'obtient par la technique d'abstraction, en se basant sur des critres de regroupement que sont: connexit, contraintes de temps, taux d'occupation du processeur. L'allocation s'avre correcte si chaque processeur est oprationnel et si la structure fonctionnelle complte est ACCEPTEE par la structure d'excution.
-C- IMPLANTATION COMME MODELE DORGANISATION DU LOGICIEL

Le modle d'implantation est utilis pour chaque processeur programmable, dfinissant ainsi sa fonctionnalit par du logiciel en dcrivant l'organisation des lments et des mcanismes utiliss pour les relations entre ces lments. Chaque processeur est le support d'excution d'une structure fonctionnelle comme sousensemble de la structure complte. L'implantation rsulte d'une transformation de la structure fonctionnelle selon un ensemble de rgles. L'objectif d'une bonne implantation est de rduire au maximum la partie organisationnelle du logiciel. Les 2 niveaux d'organisation - TACHES et MODULES - permettent de reprsenter simultanment le pseudo-paralllisme d'excution et l'excution squentielle.
-D- DEPENDANCE ENTRE IMPLANTATION ET CARACTERISTIQUES DU PROCESSEUR

Le modle d'implantation tient compte des caractristiques fonctionnelles du processeur. Celui-ci peut tre vu pour l'utilisateur comme un processeur mono-tche, ou pour certains processeurs comme tant multi-tches. La dmarche adopter pour chacun des 2 cas revient poursuivre l'implantation selon une dmarche descendante jusqu' rejoindre les possibilits des processeurs. M.C.S.E 381

Partie 5 - DEFINITION DE LA REALISATION Le modle 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 trs simple. 18.7. RESUME Ce chapitre, complmentaire au prcdent, a permis de prsenter le modle d'intgration utilis pour la dfinition de la ralisation comme un outil dcrivant lassociation de la description fonctionnelle et d'une structure excution. Cette dernire engendre l'volution spcifie par la solution fonctionnelle. Les points essentiels sont les suivants: - le modle d'intgration inclut, l'allocation de la structure fonctionnelle sur la structure d'excution, la description de l'implantation des actions logicielles sur les processeurs programmables, - une allocation n'est correcte que si la structure fonctionnelle se trouve accepte par la structure d'excution et que si tous les processeurs sont oprationnels avec respect de toutes les contraintes de temps, - le modle 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 dcrire la dcomposition de chaque tche, - des rgles de transformation simples permettent de dcider d'une implantation partir du modle fonctionnel. - l'implantation retenir est fonction du niveau de fonctionnalit du processeur. Les 2 approches avec ou sans excutif temps-rel sont possibles.

382

M.C.S.E

Chapitre 18

LE MODELE DINTEGRATION

Une description fonctionnelle exprime une solution indpendante de la technologie pour l'application considre. Une structure d'excution dcrit le support matriel. Pour complter la dfinition d'une ralisation, il faut y ajouter la correspondance fonctionnel > matriel et la description de la partie logicielle. L'organisation du logiciel dcoule: d'une part de la description fonctionnelle qui exprime l'objectif satisfaire, d'autre part de la structure d'excution retenue comme support oprationnel. Le modle d'intgration a pour objectif de spcifier compltement l'implantation d'une description fonctionnelle sur une structure d'excution. Si dans la dmarche de conception le but est de dduire une structure d'excution et une implantation partir dune description fonctionnelle, pour la prsentation du modle dintgration, on se place ici dans le cas o la description fonctionnelle et la structure d'excution sont donnes. Comme le montre ce chapitre, l'intgration concerne 2 niveaux: le niveau structure d'excution et le niveau processeur. Pour le niveau global, la structure fonctionnelle complte doit simplanter sur la structure dxcution. Pour chaque processeur programmable, la fonctionnalit rsulte dune implantation sous la forme dun schma dorganisation du logiciel.

M.C.S.E

363

Partie 5 - DEFINITION DE LA REALISATION 18.1. LE MODELE DINTEGRATION ET SES CONSTITUANTS Le modle dintgration spcifie deux niveaux dimplantation. Tout d'abord, tant donn un support d'excution, chacun de ses constituants est le support oprationnel pour un ou plusieurs constituants de la structure fonctionnelle: - un processeur pour une structure fonctionnelle partielle, - une mmoire pour des variables d'tat, - un noeud de communication pour les ports. Cette correspondance S.F.-->S.E. reprsente l'ALLOCATION. Ensuite, pour chaque association du type: processeur gnral<-->structure fonctionnelle partielle, la fonctionnalit est obtenue par logiciel. Aussi dans ce cas, les rgles d'implantation de la structure fonctionnelle sur le processeur sont exprimer. Ainsi le modle d'intgration est constitu de 2 parties: - le modle d'allocation qui dcrit la correspondance entre une structure fonctionnelle et une structure d'excution, - le modle d'implantation qui dcrit les rgles d'implantation de chaque sousensemble de la description fonctionnelle ralis par logiciel sur le processeur programmable allou comme support. La composition du modle d'intgration est reprsente ci-aprs.
FONCTIONNEL INTEGRATION EXECUTIF

Structure fonctionnelle

Allocation

Structure dxcution

Sous-ensembles fonctionnels

implantation

constituants

Structure fonctionnelle partielle pour les processeurs programmables Implantation Processeur

Implantation logicielle

-Figure 18.1- Les constituants du modle d'intgration. Pour une application donne, il n'existe qu'une seule dfinition de l'allocation: elle exprime lensemble des relations entre les constituants de la structure fonctionnelle et ceux de la structure dxcution. Mais il existe autant de dfinitions d'implantation que de processeurs gnraux. 364 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.2. LE MODELE DALLOCATION La similitude des modles - structure fonctionnelle, structure d'excution - favorise la correspondance entre les 2 structures. Chaque structure est compose d'lments et de relations entre ces lments. Ainsi, le modle d'allocation dtaille les correspondances entre lments des 2 structures et les contraintes de correspondance respecter. 18.2.1. Correspondance entre les lments des 2 structures La correspondance entre lments est la suivante : structure fonctionnelle partielle (SF) variables (VE) vnements (EV) ports (PT) liens: fonction <-->EV,VE,PT --> --> --> --> --> processeur (P) mmoire (M) signalisation (S) noeud de communication (N) lien: processeur <-->S,M,N

Les rgles ci-aprs sont respecter pour toute correspondance: - Une fonction lmentaire est une unit de description et de rpartition. De ce fait elle est indivisible pour l'implantation. Son activit rsultera de lutilisation dun seul processeur. Si cette hypothse nest pas possible, la dcomposition 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, mmoire, noeud de communication peuvent chacun supporter plusieurs lments, respectivement : fonctions, variable d'tats, ports. - Un processeur gnral est le support d'une structure fonctionnelle partielle ou complte. Les 2 premires rgles ci-dessus indiquent que la dcomposition fonctionnelle a t pousse suffisamment loin pour permettre l'intgration. Les 2 dernires rgles indiquent la possibilit de rduire la complexit d'une structure d'excution. En effet, un processeur programmable est gnralement trop puissant comme support pour uniquement une fonction lmentaire. Il en est de mme pour la capacit d'une mmoire ou d'un noeud de communication. La rduction du cot du support matriel passe par la rduction du nombre de processeurs, de mmoires, de noeuds de communication, ce qui rduit simultanment le nombre de liaisons physiques raliser. La rduction essentielle s'obtient en implantant sur chaque processeur une structure fonctionnelle la plus importante possible. L'exemple suivant montre 2 formes: la premire graphique, la deuxime textuelle pour dcrire les correspondances entre lments. M.C.S.E 365

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle Structure dexcution 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 lments. Pour les lments: 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 lments d'une structure fonctionnelle doivent obligatoirement avoir un correspondant sur la structure d'excution. Par contre, tant donn une structure d'excution, tous les lments ne servent pas obligatoirement pour l'application. 366 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.2.2. Contraintes pour une allocation Une allocation nest correcte pour lapplication que si pour les correspondances retenues, des rgles sont garanties. 2 types de rgles sont respecter: - tout d'abord comme un processeur peut servir de support excutif pour plusieurs fonctions, celui-ci doit tre apte engendrer les volutions souhaites en respectant toutes les contraintes de temps. Le respect de cette rgle exprime le fait que chaque processeur est OPERATIONNEL pour l'allocation retenue. - ensuite la correspondance entre les lments des 2 structures n'est correcte que si toutes les relations de la structure fonctionnelle sont ralisables par la structure d'excution. Dans ce cas, on dira que la structure fonctionnelle est ACCEPTEE par la structure d'excution. Dtaillons dans la suite du paragraphe, les rgles de vrification pour chaque catgorie.
-A- PROCESSEUR OPERATIONNEL

Un processeur sert de support excutif pour une ou plusieurs actions. S'agissant d'applications temps-rel, des contraintes de temps sont associes chaque action: frquence d'activation, dure d'excution maximale ou date de fin pour les actions temporaires, performances pour les actions permanentes. Un processeur est dit OPERATIONNEL pour une allocation donne si toutes les actions sont effectues et si toutes les contraintes de temps sont satisfaites pour la ralisation qui dcoule de cette allocation. Le caractre oprationnel dpend de plusieurs facteurs: - la complexit de la structure fonctionnelle supporter : nombre et nature des actions et des oprations, - les contraintes de temps respecter, - la performance du processeur. Une allocation se modifie en changeant les correspondances, et/ou en changeant les spcifications du processeur. Les rgles pour la vrification seront dtailles dans le chapitre suivant en 19.5. On retiendra pour l'instant les 2 rgles suivantes : - le taux d'occupation maximum du processeur pour toutes les actions temporaires (i=1,n) doit rester infrieur 1: Tocc = i FAi*TEi < 1. Pour une action, le taux d'occupation maximum (Tocci) est le produit de sa frquence d'activation maximale (FAi) par son temps d'excution maximum (TEi). Le taux dpend donc de la performance du processeur par le terme TEi. - les dures d'excution maximales, dates de fin (deadline), les temps de raction sur vnement externe sont toujours satisfaits. La figure 18.3 illustre le droulement sur un mme processeur de deux actions concurrentes pour une excution de A1 plus prioritaire que A.
-B- STRUCTURE FONCTIONNELLE ACCEPTEE

Pour l'implantation, les relations fonctionnelles internes un processeur sont ralises par celui-ci. Par contre, les relations entre 2 processeurs ncessitent des liens matriels 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 mme processeur


priorit

ev1

A1 ev2 A2

TFin < Tdeadline A2

Temps disponible => Tocc < 1

-Figure 18.3- Illustration des 2 rgles pour une allocation. Pour vrifier qu'une structure fonctionnelle est accepte par une structure d'excution, il faut utiliser les correspondances entre lments pour construire une structure fonctionnelle rduite. La rduction est obtenue par une opration d'abstraction qui consiste regrouper tous les constituants (fonctions, variables, ports) implants sur un mme processeur. La structure ainsi obtenue doit tre inclue au sens des graphes dans la structure d'excution. Ceci veut dire qu'il faut au moins un lien au niveau excutif comme support pour chaque lien fonctionnel. La figure 18.4 montre cette dmarche de vrification. 18.3. LE MODELE DIMPLANTATION POUR CHAQUE PROCESSEUR Pour les processeurs programmables, l'allocation dfinit le sous-ensemble fonctionnel implant sur chaque processeur. Le modle d'implantation dfinit les rgles de prsentation des constituants de ce sous-ensemble fonctionnel pour exprimer l'organisation de tous les constituants du logiciel. Le logiciel implant sur un processeur est dcomposable en 2 niveaux: - le niveau TACHES: une tche est une entit compose d'instructions et de donnes, ayant sa propre autonomie. Pour le processeur, la tche est manipule comme un tout: activation, arrt, suspension. Une tche assure gnralement une fonction ou une action de l'application. Son comportement est squentiel. L'tat d'une tche dfini par une variable appele vecteur d'tat, est mmoris entre 2 activations successives. Une tche a donc un effet mmoire. 368 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION

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 rduite SF*

Structure dexcution

-Figure 18.4- Correspondances: S.F. globale, S.F. rduite et S.E. - le niveau MODULES ou PROCEDURES. Un module est un ensemble dinstructions activ comme une unit par une tche, pour satisfaire une fonction ou une opration. La tche tant squentielle, un seul module est actif la fois. Un module est sans effet mmoire, ce qui veut dire que ses variables internes ont la dure d'excution du module. Le niveau TACHES concerne un ensemble de tches. L'volution est donc potentiellement parallle. Or, habituellement un processeur est squentiel. Aussi une stratgie d'ordonnancement pour le partage du processeur par les tches est donc ncessaire pour que, vue par l'application, l'volution de l'ensemble des tches apparaisse parallle. Pour le niveau MODULES, chaque tche se dcompose comme une hirarchie de modules. Le modle 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 modle est reprsente par la figure 18.5. 18.3.1. Implantation des tches Le niveau tche explique l'implantation retenue pour une structure fonctionnelle donne sur un processeur. Le paralllisme inhrent la structure fonctionnelle (normalement gal au nombre de fonctions) est habituellement suprieur celui-ci du processeur qui trs souvent est de 1. Ensuite les relations entre les fonctions -par vnement, par variable d'tat, par port- ne sont pas des mcanismes directement supports par le processeur. Enfin, le processeur coupl son environnement doit satisfaire par des liens matriels les relations fonctionnelles existant entre la structure fonctionnelle qu'il supporte et lenvironnement de celle-ci. L'implantation est reprsente graphiquement par un rseau de tches. Les tches sont lies entre elles par des variables d'tat, des transferts de contrle, et sont lies avec l'environnement par des variables et des vnements en entre et sortie. M.C.S.E 369

Partie 5 - DEFINITION DE LA REALISATION

Structure fonctionnelle partielle Implantation

Processeur programmable

IMPLANTATION LOGICIELLE

Spcification des tches

Implantation des tches

niveau tches

Implantation Spcification des modules des modules

niveau modules

-Figure 18.5- Dcomposition pour l'implantation. Comme habituellement, une seule tche est excute la fois par le processeur, un ordonnancement des tches est ncessaire selon un critre. Pour cela chaque tche est associe une priorit d'excution. Ainsi pour la reprsentation, l'axe vertical reprsente l'axe croissant des priorits. Le processeur tant toujours en activit, en l'absence de tches temporaires excuter, celui-ci excute une tche particulire appele tche de FOND. La figure ci-aprs est un exemple de schma dimplantation.
Priorit croissante

PAS T1

T3 V1

REU T2 T4 B2 V5

T0 TACHE DE FOND

Matriel

Logiciel

Matriel

-Figure 18.6- Exemple d'implantation de tches. 370 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Les tches lies des vnements en entre (vnements matriels situs gauche et donc tches actives par interruption) sont actives sur apparition de chaque vnement. Une telle tche volue lorsqu'elle dispose du processeur, ce qui est le cas lorsquune tche active est plus prioritaire que la tche courante excute par le processeur. Ceci rsume la technique dordonnancement retenue, priorit fixe et processeur allou la tche active la plus prioritaire. Dans le sens vertical, le transfert de contrle entre 2 tches et donc d'allocation du processeur, est reprsent par un lien double trait. Ce type de transfert, qui sera du type appel de procdure (call, return), n'est possible que dans le sens croissant des priorits. La rgle de comportement est la suivante:
Priorit Acquisition du contexte de A2
A2 appel de A2 fin dexcution de A2

Sauvegarde du contexte de A2

A2

A1

suspension de A1

A1

-Figure 18.7- Comportement pour un transfert de contrle. Lorsque A1 disposant du processeur dcide durant son volution de passer le contrle A2 (synchronisation de A2 sur un vnement gnr par A1 par exemple), le processeur est alors pass A2. A2 conserve le processeur jusqu' sa fin d'excution. Le transfert inverse redonne le processeur A1 qui poursuit alors son activit. A2 est donc obligatoirement temporaire, A1 peut tre permanente ou temporaire. Ce mcanisme de transfert de contrle est tout simplement celui de l'appel procdural, A2 est implante comme une procdure, le transfert se fait par un CALL avec sauvegarde du point de ractivation de A1. Le retour se fait par RET en utilisant le point de retour sauvegard. Ainsi ce mcanisme simple permet trs naturellement d'induire des relations d'ordre d'excution pour des tches. Attention tout de mme car pour le modle d'implantation A2 est toujours une tche et non pas simplement une procdure, car il possde ses variables internes propres qui ont une dure de vie suprieure celle de chaque activation. L'excution de A2 par un appel procdural implique donc que cette excution par le processeur dbute par une rcupration du contexte ou vecteur d'tat de A2 et se termine par une mmorisation de son vecteur d'tat pour la prochaine activation. Ce modle est aussi hirarchique. Une tche peut se raffiner par un rseau de tches. 18.3.2. Implantation de chaque tche Une tche lmentaire est considre non dcomposable en tches car le droulement de ses oprations est purement squentiel. La complexit d'une telle tche lmentaire est trs variable selon sa fonctionnalit. Pour quelques oprations, une dcomposition supplmentaire n'est pas ncessaire car l'criture du code est directe. Par contre pour une fonctionnalit qui M.C.S.E 371

Partie 5 - DEFINITION DE LA REALISATION ncessite un programme complexe, une dcomposition est souhaitable pour favoriser une implantation modulaire et structure. Le modle de structure de modules, ou structure chart de Yourdon et Constantine est ici prconis comme modle pour la description de chaque tche (voir 7.4). Rappelons que les lments de base de ce modle sont le module et la donne partage. Ce modle est hirarchique. Il permet de reprsenter la dcomposition d'une tche en units plus lmentaires. Les relations avec les modules subordonns sont reprsentes par les liens d'appel. A chaque lien d'appel sont associs des arguments d'entre et de sortie qui peuvent tre de 2 types: donne ou contrle. Les structures de contrle sont: le squencement, lappel, litration, lalternance. Les donnes internes un module ont la dure de vie de l'appel du module. Des donnes externes sont accessibles aux modules. La dure de vie de ces donnes est celle de l'application. 18.3.3. Spcification de chaque lment En complment des structures de tches et de modules, la spcification de l'implantation n'est complte que si tous les lments sont spcifis. On passe ci-aprs en revue chacune des catgories.
-A- LES TACHES

Chaque tche doit tre spcifie: entres, sorties, les conditions d'activation, le rle pour l'application exprim par la ou les fonctions de la description fonctionnelle que la tche doit assurer, la description de son vecteur d'tat. Les contraintes de temps sont aussi prciser: performances, temps d'excution maximum, dlais de raction.
-B- LES DONNEES PARTAGEES

Il s'agit, d'une part des variables d'tat qui servent pour le couplage entre les tches, et d'autre part des donnes externes ncessaires aux modules. La spcification de ces donnes se dduit de la description fonctionnelle: structure, domaine, prcision, ... Certaines informations d'implmentation peuvent tre ajoutes: dfinition de la reprsentation des donnes, ordonnancement des donnes et mcanisme d'accs.
-C- LES MODULES

Chaque module doit aussi tre dcrit par une spcification. Cette spcification doit permettre par la suite un codage correct sans qu'il s'agisse pour cela d'crire les programmes. La plupart des spcifications des modules dcoulent de la description fonctionnelle ; des fonctions compltes ou des portions de celles-ci se trouvent en fait implantes comme modules. 18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION Une implantation reprsente une traduction de la structure fonctionnelle retenue sur le processeur. Tous les lments de la structure fonctionnelle doivent se retrouver dans l'implantation. Lobjectif est aussi de rduire la complexit de la ralisation qui en dcoulera. Ainsi des rgles sont respecter pour obtenir cette traduction. Dtaillons ces rgles pour les catgories d'lments et de relations. 372 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.4.1. Correspondance: Fonctions > Tches Pour l'implantation, une tche est l'unit dexcution. Elle correspond une fonction lmentaire ou un regroupement de plusieurs fonctions de la structure fonctionnelle. Tout dabord le regroupement concerne habituellement plusieurs fonctions actives simultanment par le mme vnement. La figure suivante illustre ce type de regroupement, la dcomposition tant exprime par une structure de modules.
PARAM Contrle Coordination PAS Contrle T T T Mise jour de T PAS Rgulation Mise jour de T T Tche Contrle

Vc

Vc T

Vc

Coordination

Rgulation

Horloge

Structure fonctionnelle

Schma dimplantation

PARAM

-Figure 18.8- Traduction avec regroupement de fonctions. La tche est active par lvnement matriel PAS. Le module principal CONTROLE assure lexcution squentielle des 3 modules qui rsultent dune transformation de chaque fonction en procdure. Ensuite les actions permanentes sont obligatoirement regroupes dans la tche de fond. Le partage du processeur est alors assur par commutation rgulire pour l'allocation du processeur aux diffrentes fonctions de la tche. La tche de fond joue ainsi le rle d'ordonnanceur comme lindique la figure ci-dessous.
Structure fonctionnelle Schma dimplantation

F1

Squenceur
V F2 V F3 F1 F2 F3 V

Tche de fond

-Figure 18.9- Implantation de plusieurs fonctions dans la tche 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 conserves dans l'implantation. Comme les tches ont des priorits diffrentes, le couplage interne par variable se reprsente par des liens verticaux. Le regroupement de fonctions dans une mme tche peut induire le regroupement de variables accessibles en entre et en sortie. D'autre part, pour un regroupement d'actions dans une mme tche, des variables d'tat d'actions deviennent des variables internes globales de la tche. 18.4.3. Traduction des synchronisations par vnement L'vnement peut tre d'origine matrielle (entre pour le processeur) ou d'origine logicielle (interne au processeur). Suivant le cas, 3 principes sont applicables pour la traduction : Premier principe: un vnement est transformable en une variable boolenne. Dans ce cas, la fonction temporaire qui en dpend n'est plus active par l'vnement. Elle doit alors obligatoirement observer l'volution de la variable boolenne quivalente pour dcider des instants d'volution. Dans ce cas, la fonction est alors transforme en une action permanente et est intgre dans la tche de fond. Deuxime principe: une synchronisation interne (donc logicielle) se transforme suivant la priorit des 2 fonctions: - priorit infrieure du gnrateur: appel procdural, - priorit suprieure du gnrateur: positionnement d'une variable boolenne indiquant la gnration de l'vnement. Cette variable doit tre observe rgulirement pour engendrer l'volution du correspondant. Ce rle est affect une tierce fonction, gnralement la tche de fond. Ces 2 cas de transformation sont illustrs par l'exemple ci-aprs.
EV F1 F2

Prior. F2 > Prior. F1


F1 F2

Prior. F1 > Prior. F2

F2 EV EV EV

F1

F3

-Figure 18.10- Illustration pour limplantation dune synchronisation. 374 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Troisime principe: une synchronisation par un vnement externe s'implante efficacement en utilisant le mcanisme d'interruption du processeur. Dans ce cas, aucune transformation n'est faire. Il suffit simplement d'associer la tche un niveau d'interruption correspondant sa priorit relative par rapport aux autres tches implantes sous interruption. 18.4.4. Traduction pour des transferts par messages Un message est l'association d'un vnement et d'une donne. Les principes noncs 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 partage couramment appele Bote lettres (symbole )et compose de 2 parties : - la zone servant au dpot des messages. Cette zone est obligatoirement de capacit finie (tampon ou buffer), - un indicateur prcisant le nombre de messages disponibles dans la zone. Pour se servir de cette bote lettres, les fonctions producteur et consommateur doivent alors tester la valeur de l'indicateur avant dentreprendre une opration de dpt ou de retrait. Le consommateur est dans ce cas obligatoirement transform en une action permanente. Si la bote lettres est pleine, le producteur doit attendre un retrait, si elle est vide le consommateur doit attendre un dpt. Deuxime principe: un transfert de messages entre deux fonctions logicielles se transforme suivant les priorits relatives de celles-ci: - priorit infrieure du producteur: utilisation de l'appel procdural pour activer le consommateur, - priorit suprieure 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 illustrs 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 dimplantation pour un transfert par messages. M.C.S.E 375

Partie 5 - DEFINITION DE LA REALISATION Troisime principe: Le transfert de messages doit se faire avec l'environnement matriel. Il se fait de prfrence lment par lment (par exemple caractre par caractre). La bote lettres de couplage a alors une capacit de 1. Ceci n'est pas une rgle obligatoire (utilisation d'une FIFO par exemple), mais elle est simple sur le plan technologique. Le couplage entre le matriel et le logiciel se fait en transformant la bote lettres en une variable pour le dpt et 2 vnements pour la synchronisation bidirectionnelle. Un vnement peut se transformer en variable boolenne en particulier dans le sens logiciel vers matriel. Les 2 vnements peuvent aussi tre transforms en une seule variable boolenne bidirectionnelle. La figure suivante montre une traduction pour les deux cas: en provenance du matriel pour M1, vers le matriel pour M2. Pt est transform selon le deuxime principe.
Matriel Logiciel Matriel

M1 F1 F2

Pt F3

M2 F4

Emis

M2.Dpt

M1.V F1 F2

(Pt) F3

M2.V F4

M1.retrait

reu

Prior. F3 > Prior. F2

-Figure 18.12- Exemple de traduction. Cette traduction montre les solutions matrielles usuelles assurant un couplage correct entre producteur et consommateur: technique de l'change par poigne de main (handshake). 18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL Un processeur programmable peut avoir des niveaux de complexit trs variables. Dj entre les processeurs 8 bits type 8085 ou microcontrleurs et les processeurs volus 32 bits tels que le transputer T800, des diffrences essentielles existent. Tout microprocesseur est squentiel pour l'excution des instructions. Il n'excute ainsi qu'une seule tche la fois. Si ncessaire, le paralllisme ne s'obtient qu' un niveau macroscopique, par commutation du processeur vis vis de tches laide de mcanismes matriels tel que le systme d'interruption ou grce l'ajout d'un logiciel charg de grer le partage du processeur. 376 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION Un systme informatique considr globalement comme un processeur pour les fonctions logicielles implanter, dispose de mcanismes permettant l'excution simultane ou pseudosimultane de tches. Ces mcanismes sont offerts par un noyau excutif appel moniteur multi-tches temps-rel ou excutif temps-rel. La disponibilit de ces mcanismes facilite le travail d'implantation. En effet, l'objectif tant de rduire la partie organisationnelle dvelopper, cette partie se traduit directement sous la forme d'appels l'excutif temps-rel. Ainsi, plusieurs techniques d'implantation sont disponibles pour les tches suivant le niveau du processeur et donc suivant ses spcifications ou ses caractristiques. La suite du paragraphe montre l'implantation d'un mme exemple dans les 2 cas: sans moniteur temps-rel et avec moniteur temps-rel. Sont aussi indiqus les critres considrer pour dcider de la technique utiliser. 18.5.1. Implantation sans moniteur temps-rel Dans ce cas toutes les relations entre les actions de la structure fonctionnelle implanter sur le processeur doivent tre transformes selon les rgles dcrites dans le paragraphe prcdent. L'exemple suivant est donn titre d'illustration d'une implantation complte avec prior T0 > prior T2 > prior T1. Ce mme exemple sera utilis pour prsenter la solution avec un moniteur temps-rel.
Structure fonctionnelle
EV Ev T0 T2 Prt B pour MESS Prt T1 T2 T1 (Mess) T0

priorit

MESS

Tache de fond

-Figure 18.13- Schma d'implantation sans excutif temps-rel. La tche T0 est active par l'vnement matriel EV. Ainsi, elle rcupre inconditionnellement le processeur. T0 est donc plus prioritaire que toutes les autres tches. La synchronisation entre T0 et T1 selon une priorit dcroissante est faite par l'intermdiaire de la Bote lettres B et de la tche de fond. Le comportement de la tche de fond est le suivant:
cycle: if B.Nb_messages>0 then begin Retrait_message (B, Mess); T1(Mess); end; end cycle;

Ainsi la tche de fond scrute rgulirement si un message est disponible dans B. Si oui, le premier message est retir et transmis T1 pour excution. M.C.S.E 377

Partie 5 - DEFINITION DE LA REALISATION La priode de scrutation par la tche de fond dpend de l'occupation du processeur traiter les tches temporaires (ici uniquement T0). Cet exemple montre la simplicit de la mthode d'implantation et la simplicit de la partie organisationnelle qui en dcoule. 18.5.2. Implantation avec un excutif temps-rel L'excutif temps-rel dans ce cas est voir comme une tche ayant la priorit la plus leve et sollicite par toutes les autres tches par appel procdural. La plus grande priorit est justifie pour que cet excutif puisse requrir le processeur lorsqu'il le dsire de manire assurer correctement son rle d'ordonnancement. La figure suivante montre le schma d'implantation d'une structure fonctionnelle avec utilisation de 4 primitives temps-rel: SIGNAL et WAIT pour la synchronisation, SEND et RECEIVE pour le transfert de messages.
priorit
Excutif temps-rel
Ev T0 EV Tit
Wait(EV) Signal(EV) Send (V,MESS) Wait(Prt)

T0 MESS
Receive(V,MESS)

T2
Signal(Prt)

T1 Prt T1 T2

Tache de fond

matriel

logiciel

-Figure 18.14- Schma d'implantation avec un excutif temps-rel. L'implantation ci-dessus montre bien le rle dordonnanceur jou par l'excutif temps-rel. Les vnements externes pris en compte comme interruptions par le processeur sont grs par une tche trs courte (Tit) qui se contente de signaler au moniteur temps-rel les vnements reus. Toutes les demandes faites par les tches l'excutif se font par appel procdural. Si la demande implique une attente, l'instant de retour la tche appelante est dcid par l'excutif. L'ordre de retour et donc d'allocation du processeur la tche appelante est totalement sous le contrle de l'excutif. C'est une raison supplmentaire pour que cette tche soit reprsente comme la plus prioritaire. Pour la comprhension du schma d'implantation, on donne figure 18.15 une squence de droulement pour les 3 actions T0, T1, T2. L'excutif est donc ici vu comme une tche particulire unique sollicite par toutes les tches du processeur pour chaque action particulire. L'excutif possde donc de multiples points d'entre. Il gre l'ordonnancement des retours aux tches appelantes sur la base de variables internes qui reprsentent l'tat de toutes les tches, des relations, des demandes ... 378 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION

Priorit Attributions du processeur


Excutif

Ev
Signal (EV) wait Send (V,MESS) wait (EV) Signal (prt) (prt) Receceive (V,MESS)

TIT

wait (EV)

wait (prt)

Receive (V,MESS)

T0 T2 T1 Tche de fond

T0 T2 T1

Ev

Initialisation

Droulement
T0

T2

T1

-Figure 18.15- Exemple de droulement d'excution. Si pour un cas simple, l'excutif peut se comprendre comme une simple tche, habituellement, compte-tenu des mcanismes offerts: dlai, activation priodique, synchronisation sur vnements externes ..., un excutif est lui-mme compos d'un ensemble de tches. Le couplage entre ces tches peut tout fait se dcrire par le modle d'implantation dcrit dans ce chapitre. La mthode prsente s'avre donc utilisable par les concepteurs d'excutifs. Pour les applications utilisant un excutif temps-rel, le schma d'implantation dcrit par la figure prcdente n'est pas ncessaire. Il a seulement t donn pour expliquer le rle jou par un excutif. Dans ces cas d'applications, il suffit simplement: - de dterminer la priorit de chaque tche, - de traduire chaque relation fonctionnelle par le ou les mcanismes de l'excutif disponibles et appropris. La figure 18.16 montre la reprsentation suffisante pour une telle implantation. Certains processeurs possdent en standard dans leur jeu d'instructions des mcanismes de synchronisation et d'change de donnes. C'est le cas par exemple du TRANSPUTER d'INMOS. La disponibilit de tels mcanismes implique que le processeur assure de lui-mme l'ordonnancement des tches. Le travail du concepteur se trouve alors simplifi (voir 22.8). Pour le concepteur d'applications, la seule diffrence qui existe entre ce type de processeur prvu pour la gestion du paralllisme et un processeur plus classique auquel on associe un excutif temps-rel, est que dans le deuxime cas, il faut ajouter l'excutif comme logiciel. Les performances sont alors moindres par suite du temps ncessaire pour lexcution 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(prt)

MESS

Prt

receive(V,MESS)
T1

signal(prt)

-Figure 18.16- Schma d'implantation bas sur un excutif Temps-Rel 18.5.3. Critres de choix de la technique d'implantation Il est vident que pour rduire le temps de dveloppement d'une application, il est prfrable de disposer d'un excutif. La solution logicielle est plus coteuse en place mmoire, en temps de traitement des sollicitations (temps de commutation ou overhead), et en terme de prix lorsque l'excutif est un produit standard du commerce (VRTX, PSOS, iRMX, noyau SCEPTRE...). L'excutif intgr dans la fonctionnalit du processeur est la solution la plus avantageuse et correspond une tendance qui va probablement se gnraliser. Elle permet au concepteur de voir le processeur comme un excutif direct multi-tches, ce qui rduit le travail d'implantation. Le concepteur n'a pas dans ce cas besoin de descendre au niveau de l'ordonnancement de ses tches. Toutefois, il lui faut toujours dterminer la priorit relative des tches. 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 excutif ou la dfinition complte de l'implantation. C'est au concepteur de dcider la meilleure solution sur la base de critres techniques et conomiques. Les critres considrer sont: - les contraintes de temps pour l'application. Pour de trs fortes contraintes, il faut dfinir une implantation complte sans excutif, car c'est la solution qui rduit au maximum les temps de commutation des taches (overhead). - le nombre d'exemplaires. Pour quelques exemplaires, l'emploi d'un excutif rduit le temps de dveloppement. Pour un grand nombre, comme il faut rduire le cot de chaque exemplaire, ceci implique fort probablement de se passer d'un excutif standard. - la complexit de l'application. Pour de petites applications ddies bien spcifies, l'implantation directe restera simple et efficace. Pour des applications complexes avec des spcifications volutives, un excutif temps-rel est certainement favorable. 380 M.C.S.E

Ch 18 - LE MODELE DINTEGRATION 18.6. CARACTERISTIQUES DU MODELE DINTEGRATION Le modle de description d'un systme est bas sur l'association de 3 dimensions ou 3 vues: topologique, comportementale, excutive. La dimension excutive reprsente le support "matriel" qui engendre l'volution de l'application. Une application oprationnelle rsulte d'une association correcte de la dimension fonctionnelle avec la dimension excutive. C'est l'objectif du modle d'intgration que de spcifier les rgles de correspondance entre ces 2 ensembles, puis pour les ralisations logicielles, la structuration pour l'implantation. Les caractristiques essentielles induites par le modle dintgration sont prsentes ciaprs.
-A- MODELE DE STRUCTURE

Ce modle est compos de 2 parties complmentaires. Tout d'abord le modle d'ALLOCATION dfinit la correspondance : fonctionnel --> excutif, ensuite le modle d'IMPLANTATION dfinit l'organisation d'une structure fonctionnelle sur chaque processeur. Ce dernier modle est hirarchique avec 2 niveaux d'organisation: le niveau TACHES et le niveau MODULES. La spcification de la ralisation en sous-ensembles hirarchiques avec des interfaces compltement spcifies, est favorable pour une rpartition du travail de ralisation sur plusieurs quipes.
-B- ALLOCATION COMME RESULTAT DUNE ABSTRACTION

Le modle d'ALLOCATION dcrit des regroupements d'lments d'une structure fonctionnelle. A chaque regroupement est associ un processeur pour l'excution. Une telle transformation s'obtient par la technique d'abstraction, en se basant sur des critres de regroupement que sont: connexit, contraintes de temps, taux d'occupation du processeur. L'allocation s'avre correcte si chaque processeur est oprationnel et si la structure fonctionnelle complte est ACCEPTEE par la structure d'excution.
-C- IMPLANTATION COMME MODELE DORGANISATION DU LOGICIEL

Le modle d'implantation est utilis pour chaque processeur programmable, dfinissant ainsi sa fonctionnalit par du logiciel en dcrivant l'organisation des lments et des mcanismes utiliss pour les relations entre ces lments. Chaque processeur est le support d'excution d'une structure fonctionnelle comme sousensemble de la structure complte. L'implantation rsulte d'une transformation de la structure fonctionnelle selon un ensemble de rgles. L'objectif d'une bonne implantation est de rduire au maximum la partie organisationnelle du logiciel. Les 2 niveaux d'organisation - TACHES et MODULES - permettent de reprsenter simultanment le pseudo-paralllisme d'excution et l'excution squentielle.
-D- DEPENDANCE ENTRE IMPLANTATION ET CARACTERISTIQUES DU PROCESSEUR

Le modle d'implantation tient compte des caractristiques fonctionnelles du processeur. Celui-ci peut tre vu pour l'utilisateur comme un processeur mono-tche, ou pour certains processeurs comme tant multi-tches. La dmarche adopter pour chacun des 2 cas revient poursuivre l'implantation selon une dmarche descendante jusqu' rejoindre les possibilits des processeurs. M.C.S.E 381

Partie 5 - DEFINITION DE LA REALISATION Le modle 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 trs simple. 18.7. RESUME Ce chapitre, complmentaire au prcdent, a permis de prsenter le modle d'intgration utilis pour la dfinition de la ralisation comme un outil dcrivant lassociation de la description fonctionnelle et d'une structure excution. Cette dernire engendre l'volution spcifie par la solution fonctionnelle. Les points essentiels sont les suivants: - le modle d'intgration inclut, l'allocation de la structure fonctionnelle sur la structure d'excution, la description de l'implantation des actions logicielles sur les processeurs programmables, - une allocation n'est correcte que si la structure fonctionnelle se trouve accepte par la structure d'excution et que si tous les processeurs sont oprationnels avec respect de toutes les contraintes de temps, - le modle 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 dcrire la dcomposition de chaque tche, - des rgles de transformation simples permettent de dcider d'une implantation partir du modle fonctionnel. - l'implantation retenir est fonction du niveau de fonctionnalit du processeur. Les 2 approches avec ou sans excutif temps-rel sont possibles.

382

M.C.S.E

Chapitre 19

DEMARCHE POUR LA DEFINITION DE LA REALISATION

Cette troisime tape de la mthodologie MCSE a pour objectif de proposer une solution complte dtaille qui tient compte de toutes les contraintes technologiques. Comme entre pour cette tape, le concepteur dispose: - d'un document complet dcrivant la solution fonctionnelle, - du document de spcifications contenant tout particulirement les spcifications technologiques. En rsultat, la solution dtaille constituant le document de spcification de la ralisation doit contenir: - la description de la structure d'excution avec toutes ses spcifications, - la description de l'implantation de tous les lments de la description fonctionnelle sur la structure d'excution. Les chapitres 17 et 18 ont servis dcrire le modle que doit respecter la solution pour que celle-ci puisse tre prise comme document d'entre pour la ralisation. La conception fonctionnelle a conduit dvelopper la solution la plus approprie pour le problme, sans tenir compte des contraintes et particularits technologiques.

M.C.S.E

383

Partie 5 - DEFINITION DE LA REALISATION La ralisation rsultera de l'association de 2 parties: une partie matrielle comme support d'excution, une partie logicielle servant personnaliser le matriel pour satisfaire les spcifications de l'application. Aujourd'hui, il n'y a pas de solution pour obtenir directement une application oprationnelle partir de la conception fonctionnelle. Aussi le passage de la conception fonctionnelle une ralisation ncessite un travail de 3 ordres: - d'adaptation tout d'abord pour tenir compte de l'environnement du systme avec toutes ses contraintes d'interfaage. - de slection du support technologique pour l'application. Dans certains cas le support est impos, alors une vrification est au moins ncessaire, dans d'autres cas il est dterminer. - de transformation ensuite, pour modeler la solution fonctionnelle de manire la rendre oprationnelle sur la technologie retenue ou impose. Aprs avoir prsent les objectifs complmentaires ou contradictoires satisfaire, ce chapitre dtaille la dmarche prconise pour que le concepteur dtermine avec efficacit une solution conservant les qualits de l'approche fonctionnelle et rduisant au maximum le cot de dveloppement. Contrairement la conception fonctionnelle, la spcification de la ralisation est la rsultante de transformations successives faites partir de la description fonctionnelle. La dmarche est donc plus systmatique. 19.1. LES OBJECTIFS A ATTEINDRE La solution de ralisation doit satisfaire plusieurs types d'objectifs: - des objectifs techniques et technologiques, - des objectifs conomiques. Ces objectifs sont normalement dcrits dans les spcifications technologiques du problme. En complment la solution doit aussi respecter des rgles gnrales de qualit qui induisent des rpercussions sur le plan conomique. Dans la suite, parcourons tout dabord les objectifs techniques satisfaire puis les objectifs conomiques. 19.1.1. Spcifications matrielles Dans cette partie des spcifications se trouvent nonces les contraintes auxquelles la ralisation doit satisfaire.
-A- CONTRAINTES DE REPARTITION

Cette contrainte qui ne se retrouve pas dans toutes les applications, indique que la solution n'est pas regroupe en un mme lieu gographique. La ralisation rsulte de l'association de plusieurs sous-ensembles relis entre eux par des liaisons physiques charges dassurer les changes d'informations. La solution dpend de plusieurs facteurs, savoir: la distance entre sous-ensembles, le dbit 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 dveloppe sans cette contrainte, la dlimitation des sous-ensembles se fait sur la base des contraintes de rpartition qui expriment le lieu o se trouvent les donnes. La dlimitation met en vidence le couplage et donc les informations changer. Une analyse de la nature de ces informations et la frquence d'change conduit spcifier le service de communication ncessaire.
-B- INTERFACES AVEC LENVIRONNEMENT

Le systme raliser est li son environnement par des interfaces physiques. Ces interfaces doivent satisfaire la nature physique des signaux changs. La nature dpend des entits de l'environnement. Retenons 2 catgories diffrentes: - les entits physiques que sont des procds industriels, machines et autres. Ces entits fournissent par des capteurs des signaux lectriques. En sens inverse, des actionneurs commands lectriquement permettent d'agir sur ces entits. On considre ici que les capteurs et actionneurs, mme s'ils sont choisis par le concepteur et inclus dans la prestation, ne font pas partie du systme dvelopper. - les entits autres et tout particulirement les utilisateurs. Pour ce type de couplage, l'interface est trs variable: pupitre conventionnel, clavier-cran, analyse et synthse de parole... La solution doit rpondre au mieux la convivialit souhaite pour l'application. Les caractristiques sont dcrites dans les spcifications technologiques.
-C- CONTRAINTES DE REALISATION

Des rgles peuvent tre imposes par le demandeur et qui limitent les techniques ou technologies possibles pour la ralisation: type de processeurs, de mmoires, de ressources. S'ajoutent ces rgles, un descriptif des caractristiques de l'environnement dans lequel doit fonctionner le systme, la fiabilit et la sret de fonctionnement imposes. 19.1.2. Contraintes de temps Les applications qui nous concernent sont de nature temps-rel. Des contraintes existent et qui expriment: des dlais de raction par rapport l'apparition d'vnements, des performances attendues du systme. Le respect de ces contraintes de temps ncessite de dduire un support matriel suffisamment dimensionn. Des rgles garantissant le respect des contraintes doivent pour cela tre clairement nonces. 19.1.3. Rduction du cot de dveloppement Comme objectif conomique, tout projet doit tre envisag avec l'objectif de rduire son cot. Le cot dpend de certaines donnes qui permettent de choisir un critre pour le dveloppement du produit. La donne essentielle prendre en compte pour cette tape est le nombre d'exemplaires produire. Le cot pour chaque exemplaire est : CT = CRm + (CDm + CDl)/N avec: - CRm - CDm M.C.S.E

le cot de reproduction de chaque exemplaire, le cot de dveloppement du matriel prototype, 385

Partie 5 - DEFINITION DE LA REALISATION - CDl -N le cot de dveloppement 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 matriel) CDm CDl trs faible minimiser minimiser minimiser assez lev minimiser PEU lev (achat du MOYEN moyen IMPORTANT minimiser

Ce tableau montre les 2 cas extrmes: - Pour une faible quantit: il est plutt essentiel de minimiser le temps de dveloppement. Ceci s'obtient en renonant un dveloppement matriel et en rduisant au maximum le temps de dveloppement du logiciel. - Pour une production importante: il faut consacrer le temps ncessaire en dveloppement pour minimiser le cot de reproduction du produit: cot matire + cot de ralisation + cot de test + cot de maintenance. La diffrence entre les 2 cas pour le concepteur est: dans le premier cas, utilisation d'une structure d'excution donne non-optimise, dans le deuxime cas: recherche d'une structure d'excution minimale optimise pour l'application. Ceci induit 2 stratgies de dveloppement qui seront dcrites dans ce chapitre. Dans tous les cas, comme le cot du dveloppement du logiciel prend une part de plus en plus importante, il est utile de chercher rduire ce cot. 19.1.4. Rduction de la partie organisationnelle Globalement et en moyenne, le cot de la ralisation correspond prs de 50 % du cot total pour lobtention dun prototype. Rduire le cot global veut dire quil faut viser rduire la ralisation et donc sa complexit durant les tapes de conception et de dfinition de la ralisation. Pour une application donne, la complexit en conception est essentiellement dpendante de la solution retenue comme premire dcomposition fonctionnelle. Lemploi des modles gnriques favorise llaboration de solutions simples et appropries. La complexit en ralisation dpend du travail effectu durant ltape de dfinition de la ralisation. La solution matrielle peut tre minimise pour rduire le cot de production. La partie logicielle doit aussi tre minimise pour tre simple crire puis valider. En faisant une analyse plus prcise, on constate que la partie logicielle est en fait compose de 2 parties : - la partie dite oprative, cest--dire celle qui exprime toutes les oprations entreprendre. Cest la partie typiquement algorithmique. 386 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - la partie dite organisationnelle, qui correspond lagencement des oprations de la partie oprative au niveau tches et modules (pas au niveau structures de contrle de base du niveau algorithmique). La partie oprative, lorsque les algorithmes sont crits correctement est incompressible. La partie organisationnelle est le rsultat de la transformation de la structure fonctionnelle en vue de limplantation sur un processeur. La complexit dpend donc de la solution retenue pour la structure fonctionnelle mais aussi et surtout des transformations ralises durant cette tape de dfinition de la ralisation. Lobjectif de la dmarche propose pour dduire le schma dimplantation logicielle est de rduire au maximum la partie organisationnelle de manire rduire le temps et donc le cot de dveloppement. Ce point de vue justifie les rgles de transformation proposes dans ce chapitre; il est important pour les applications temps-rel. 19.1.5. Rgles de qualit Comme objectif plus gnral, le respect de rgles de qualit conduit une rduction du cot pour l'ensemble du cycle de vie du produit. Le rsultat l'issue de cette tape de dfinition de la ralisation est un document. Celui-ci joue au moins 2 rles: - il sert comme document de spcification pour l'tape suivante de ralisation, - il servira aussi plus tard pour la phase de maintenance: correction des erreurs, adaptation et amlioration du produit. La rgle de qualit essentielle pour ce document est sa lisibilit. Une bonne lisibilit favorise la comprhension de la solution. Ainsi, les techniciens qui ont en charge la ralisation peuvent utiliser ce document directement avec une sollicitation rduite des concepteurs auteurs. Une bonne comprhension favorise aussi la maintenance. La maintenance volutive conduit des modifications. Il faut donc pouvoir dduire du document les limites de la solution, le pourquoi des choix. Cette rgle de qualit favorise ainsi globalement le cot du produit. 19.1.6. Objectifs contradictoires Les objectifs prcdents sont relativement contradictoires: - rduire le cot de reproduction conduit minimiser le matriel, - rduire le cot du dveloppement conduit minimiser le matriel, 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 dveloppement et de mettre en oeuvre une solution rpondant des performances minimales. Les principes dvelopps dans la suite et la dmarche propose dans ce chapitre conduisent trouver le meilleur compromis entre ces objectifs contradictoires. L'ide globale est d'introduire tout d'abord les interfaces ncessaires pour les contraintes technologiques, puis rechercher la structure d'excution minimale, enfin dfinir une implantation qui rduit le temps de dveloppement. M.C.S.E 387

Partie 5 - DEFINITION DE LA REALISATION 19.2. PRESENTATION DE LA DEMARCHE Cette troisime tape a pour objectif de produire une description dtaille de la ralisation entreprendre. Conforme au modle de ralisation, elle doit tre compose: - d'une structure d'excution avec la spcification de ses constituants, - de l'intgration compose: de l'allocation de la structure fonctionnelle sur la structure d'excution. de l'implantation des constituants logiciels sur les processeurs programmables du systme. Avant de dterminer la structure d'excution, la solution fonctionnelle doit tre modifie et complte pour tenir compte des contraintes technologiques de l'environnement. La structure d'excution est ensuite dduite compte-tenu du critre conomique optimiser. Ensuite pour chaque processeur, est labor le schma d'implantation dfinissant l'organisation du logiciel et des donnes. La dmarche consiste donc suivre les phases suivantes: - introduction des contraintes de rpartition, - introduction des interfaces: interfaces physiques, interfaces homme-machine, fonctions de test, maintenance, sret. - Dtermination de la structure d'excution: valuation des contraintes de temps, rpartition matriel/logiciel. - Schma d'implantation pour chaque processeur. - Spcification de la ralisation matrielle. Le diagramme 19.1 montre l'enchanement de ces phases, les documents utiliser et le rsultat en sortie. Dans la suite du chapitre, nous dtaillons chacune des phases en les illustrant par les 2 exemples traits en conception. Pour l'introduction des adaptations l'environnement, le lecteur est convi si ncessaire revoir les principes noncs pour la conception fonctionnelle (chapitre 14) et qui justifient le report des dtails technologiques ce stade. 19.3. INTRODUCTION DES CONTRAINTES DE REPARTITION Avec l'volution de la technologie, les ralisations peuvent se dvelopper de plus en plus sous la forme de sous-ensembles faiblement coupls, faciles rpartir gographiquement. Pour les ralisations lectroniques, au-del de quelques mtres, on se trouve dans le cas de la rpartition gographique. Si la tendance naturelle consiste prendre en compte la contrainte de rpartition ds la conception, il a t montr dans le chapitre 14 la difficult de cette approche. La dmarche prconise consiste plutt rechercher tout d'abord les couplages fonctionnels, puis aprs analyse des contraintes de rpartition, rechercher les transformations ncessaires. Cette stratgie permet de se limiter au strict ncessaire pour l'application. 388 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

Solution fonctionnelle + spcifications technologiques

rpartition et adaptation Introduction de la rpartition

Introduction des interfaces Solution fonctionnelle dtaille

contraintes de temps

Dtermination de la structure dexcution

allocation

Spcification des implantations logicielles

implantation

Allocation et implantation

Spcification de la ralisation matrielle

structure dexcution

Document pour la ralisation

-Figure 19.1- Enchanement des phases pour la dfinition de la ralisation. Les contraintes de rpartition indiques dans les spcifications technologiques concernent: - des informations ou des vnements de l'environnement. Les entits concernes par ces grandeurs sont alors rparties, ce qui implique des entres et sorties rparties pour le systme. - des informations ou des fonctions internes au systme qui doivent respecter des contraintes de lieu. Avec la contrainte de rpartition, certaines relations fonctionnelles ne sont pas directement ralisables laide dun support matriel disponible pour le transfert des informations entre 2 sites distants. Des transformations de structure sont donc ncessaires. Le principe essentiel respecter consiste considrer que tout change entre 2 sites distants ne peut se faire que par transfert d'information sous la forme de messages. La dmarche qui en dcoule consiste donc: - dlimiter les sous-ensembles de fonctions situs sur des sites diffrents, - transformer toutes les relations de synchronisation et de partage de variables par des relations de transfert de messages. Si divers choix de dlimitation des sous-ensembles sont possibles, avec le souci de minimiser la complexit de la ralisation, il est conseill de rechercher comme dlimitation les couplages minimums. Les 2 types de relations par vnement et par variable sont transforms comme lindique la figure suivante. Un vnement ou une variable est spar en deux et le couplage est assur par une fonction de transfert unitaire. Cette fonction est ensuite raffine en considrant un port interne pour le transfert de message. Lvnement Ev ou la variable V est cod sous la forme dun message par une fonction dmission. Le message est dcod par une fonction de rception. M.C.S.E 389

Partie 5 - DEFINITION DE LA REALISATION

Ev

Ev 1

Ev

V 1

V Ev

Emission

M(Ev)

M(V)

Reception

Ev

Emission

Reception

Interface Rpartition

Interface Rpartition

-Figure 19.2- Principe pour l'introduction de la rpartition. Pour le transfert de Ev, laction mission est temporaire, tandis que dans le cas du transfert de V' en V'', l'action mettrice est permanente. La solution daction permanente n'est bien entendu pas satisfaisante pour l'implantation. En fait, une transmission de V' n'est utile que lorsque celle-ci est modifie. 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 dmarche prconise par un exemple autre que ceux traits en conception qui eux n'incluent pas de contraintes de rpartition. Supposons la structure fonctionnelle ci-aprs:
E1 F1 S1 V E2 F2 V2 F3 V1

E3 F4

-Figure 19.3- Exemple de structure fonctionnelle. 390 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION La contrainte de rpartition est spcifie par la position gographique des entits de lenvironnement. 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 sparer les 2 sites. Plusieurs choix sont possibles, 4 sont reprsents. Les 2 extrmes: 1 et 4, considrent toutes les fonctionnalits sur l'un des 2 sites, tandis que 2 et 3 considrent une rpartition des fonctions du systme. Ensuite, la solution s'obtient en remplaant tous les liens traversant la ligne de sparation pour un seul lien de transfert de messages et ceci pour chaque sens. Pour lexemple ci-dessus, on obtient les 4 solutions suivantes.
V1 E1 E1

F1
M(E1,E2) E2 Emission E1 et E2 Rception E1 et E2 V V2 S1

E1

F3

F1
M(V1,V2) V E2 Rception V1 et V2

V1 S1

F3
V2

F2
E2

F2
E3 Ev M(Ev) E3

F4

F4

CAS 1

CAS 2

E1

V1

E1 M(S1) S1 Rception S1 V E2

V1

F1 F3
V2 E2

F1 F3
V2

M(S1)

Rception 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 dlimitation. Au vu des structures fonctionnelles rsultantes, le concepteur peut faire le choix de la solution la plus simple. Ici le cas 1 semble prfrable car la solution met en jeu uniquement une liaison unidirectionnelle. Le site A n'assure que l'acquisition des donnes E1 et E2 et la transmission au site B. Pour le cas 4, le site B sert pour lacquisition et la transmission des informations E3 et la rception 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 transfre est inclure dans le message lui-mme. En rception, une fonction d'aiguillage assure la mise jour slective de V1 ou de V2. 19.4. INTRODUCTION DES INTERFACES La solution fonctionnelle dveloppe indpendamment de la technologie doit tre modifie pour tenir compte des contraintes technologiques. Comment s'y prendre pour introduire les interfaces ncessaires? 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 cratif. Pour la dfinition de la ralisation, ce n'est pas le cas. Le travail entreprendre porte sur des adaptations et des slections. Il s'agit donc beaucoup plus d'une dmarche dductive qui part de la solution fonctionnelle et qui, visant satisfaire les spcifications technologiques catgorie par catgorie, conduit laborer une solution dtaille. Introduire des lments supplmentaires par dduction rduit la dformation de la solution fonctionnelle qui doit rester le noyau "dur" ou stable de l'application. 19.4.1. Modle pour lintroduction des interfaces Les interfaces ont un rle technologique d'adaptation du systme dcrit 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 catgories suivant le type d'entit de l'environnement: - les interfaces physiques pour les entits physiques, - les interfaces homme-machine pour les dialogues. Compte-tenu de la nature trs diffrente de ces 2 catgories, il est souhaitable de les traiter sparment. Aux interfaces s'ajoutent des fonctions spcifiques la technologie que sont les tests, procdures de maintenance, redondance pour la sret de fonctionnement. HATLEY propose le modle gnrique suivant pour l'introduction des interfaces. Dans ce document, nous suivons l'ide de ce modle [HATLEY-87].
Environnement
Interface utilisateur Interfaces Solution Solution fonctionnelle Auto-test maintenance Redondances Entres physiques fonctionnelle Sorties physiques

-Figure 19.5- Modle gnrique pour l'introduction des interfaces. La dmarche pour introduire les interfaces est identique celle prsente pour la conception fonctionnelle. En effet, chacune des 4 parties se prsente comme une fonction possdant des entres et des sorties dfinies, les unes par la nature physique des informations observes ou commandes, les autres par la nature fonctionnelle des grandeurs d'entre et de sortie. Il s'agit donc pour chaque partie de rechercher une structure fonctionnelle assurant le changement de reprsentation des informations changes. Pour cela, les entres et sorties sont spcifier ainsi que le rle de chaque interface. Une fois ces spcifications exprimes, la mthode de conception fonctionnelle permet ensuite de dduire une solution. La mme mthode 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 rle de raliser un changement de reprsentation de l'information. Comme la variable de couplage utilise en fonctionnel est une variable essentielle pour les 2 parties: environnement et systme, et si cette variable n'est pas directement observable , une transformation unitaire est ncessaire, et qui rsultera de l'association du capteur et de l'interface. Le principe consiste donc raffiner cette variable de couplage. Une fois spcifie chaque interface, la technique consiste utiliser la dmarche de conception fonctionnelle pour dfinir la solution. Celle-ci est rechercher sur le plan fonctionnel, sachant qu'elle sera maintenant dpendante de la technologie puisque recherche pour satisfaire ce type de contraintes. La figure ci-dessous illustre la dmarche pour le cas d'une observation de la position d'un mobile par un codeur incrmental et le cas d'une commande analogique proportionnelle.
P Cmd

P 1

Cmd 1

Cmd

Interface
INC P Codeur Eval uation position P Cmd CNA

Interface
VA Ampli Cmd

SENS

Capteur

Systme

Systme

Actionneur

-Figure 19.6- Introduction des interfaces physiques: exemples. Chaque variable ncessitant une interface est spare en 2. La fonction intermdiaire doit tre unitaire pour conserver lgalit des deux variables. L'interface est ensuite introduite comme variable interne essentielle. Il reste alors reprsenter une fonction inverse de celle du capteur ou de l'actionneur. Cette mme technique est utilisable pour un couplage par transfert de messages. Elle est complmentaire de la phase dintroduction de la rpartition. En effet, une fois la contrainte de rpartition satisfaite, il faut s'adapter aux caractristiques technologiques du support. Ce support est en ralit une interface physique entre sous-ensembles. Habituellement, le support n'est pas quivalent une bote aux lettres capable de mmoriser plusieurs messages. Il sagit plutt dun support pout une transmission srie 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 lapplication. La technique employer est similaire celle utilise pour les interfaces physiques, mais en effectuant une dcomposition du service de communication niveau par niveau. Il est conseill de se baser sur le modle gnrique client/serveur (voir en 16.4), et en recherchant les niveaux successifs de communication sur la base du modle OSI. Comme illustration de cette dmarche par la figure 19.7, le transfert de chaque message se dcompose en un transfert de caractres, chaque caractre tant transfr sur le support physique comme une suite de bits.
PT F1 F2

Introduction du service message

Introduction du service caractre

F1

F2

F1

F2

PT

PT

PT

PT

Service message
Emission message Rception message

Service message
Emission message Rception message

CAR

CAR

CAR

Service caractre Interface caractre Interface


Emission caractre TxD Synchro Rception caractre

Interface bit

-Figure 19.7- Introduction des niveaux de communication jusquau support. Pour le service de communication, il reste en final tudier la capacit ncessaire ou impose pour chaque port. Si la capacit d'un port de rception n'est pas suffisante pour mmoriser tous les messages mis, un asservissement consommateur vers producteur est ncessaire. Ceci s'assure par une ligne de retour: RTS sur CTS pour une synchronisation matrielle 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 lensemble des messages ncessaires. L'utilisateur n'est pas directement gnrateur de ces messages. De mme, l'interprtation directe de message n'est pas possible. Une interface d'adaptation est donc ncessaire. Celle-ci doit tenir compte du type de convivialit souhaite dfini dans les spcifications technologiques, ce qui induit par dduction l'interface technologique. 394 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Supposons que l'interface utilisateur soit compose d'un clavier et d'un cran. L'interface homme-machine est reprsente par la fonction ci-dessous qui assure: lobservation de ltat du clavier, la mise jour de lcran, la production et linterprtation des messages changs avec la solution fonctionnelle.
TOUCHES Interface Homme-Machine ECRAN

Actions Solution fonctionnelle

Observations

-Figure 19.8- Introduction dune interface homme-machine. Le raffinement de la fonction est base sur les spcifications de cette interface qui exprime la procdure dutilisation. La dmarche suivre est celle prsente pour toute conception fonctionnelle, mais cette fois en tenant compte des caractristiques technologiques des entres et des sorties de l'interface. Par exemple, il est possible de se baser sur un modle gnrique tel que le modle dinteractivit prsent en 16.5. Si la solution consiste ajouter une seule fonction comme interface, tout concepteur doit savoir que le dveloppement de ce type dinterface cest dire la programmation pour satisfaire lobjectif est trs coteux en temps de ralisation et de mise au point. Lexistence de telles interfaces est une source derreurs destimation des temps qui peuvent aller du simple au quadruple. Lerreur dvaluation peut dpendre de la difficult cerner la spcification mais aussi de limprcision du souhait du demandeur. Pour que le demandeur soit daccord avec le produit, la spcification du dialogue peut se faire par prototypage. Il sagit de dvelopper rapidement linterface avec des outils appropris qui vont permettre de raliser facilement des modifications. Les applicatifs gnrateurs dinterfaces pour cette classe de problme sont trs utiles ainsi que les langages orients objets. Dans la suite, illustrons l'introduction des 2 catgories d'interfaces: entres/sorties et interfaces utilisateur sur les 2 exemples tudis en conception. 19.4.4. Exemple 1 : contrle en vitesse dun centrifugeur Pour ce problme, les interfaces satisfaire concernent: l'observation de la vitesse qui se fait par un codeur incrmental, la commande en vitesse du moteur qui est du type PWM, et l'interface utilisateur compose d'un ensemble de touches et un afficheur numrique.
-A- INTRODUCTION DES INTERFACES PHYSIQUES

Pour la commande du moteur, il s'agit de transformer la grandeur CV en une grandeur 2 tats de priode 1KHz et de rapport cyclique proportionnel CV. Ceci est assur par une fonction d'interface appele GENERATION_PWM. De mme pour obtenir la vitesse VMOTEUR tout instant, il faut exploiter l'vnement produit par le codeur incrmental. M.C.S.E 395

Partie 5 - DEFINITION DE LA REALISATION La figure ci-aprs montre l'introduction des 2 interfaces.

VROTATION

ORDRE

Contrle en vitesse du centrifugeur


Interface dentre
CV
Gnration 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 mthode prconise pour la conception fonctionnelle. Pour cela, il faut rechercher les variables ou vnements internes caractristiques. Pour gnrer le signal PWM, il faut tout d'abord produire une transition positive selon une priode fixe. Soit HPERIODE l'vnement correspondant. Ensuite, il faut produire la transition ngative au bout d'un temps t fonction de la valeur CV. L'valuation de ce temps ncessite un vnement HB de frquence leve par rapport Hpriode (rapport 1000). Ainsi la structure fonctionnelle utilisable pour cette fonction est la suivante.
Gnration_PWM CV Gnration niveau 1 Hpriode SPWM

HB Horloge

Gnration priode

-Figure 19.10- Structure fonctionnelle pour GENERATION_PWM. Les algorithmes sont faciles crire.
Action GENERATION_PERIODE sur vnement HB avec (sortie vnement 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 dure en rapport avec CV, tat 0 pour le temps restant.
action GENERATION_NIVEAU1 sur evs HB, HPERIODE avec (entre var CV: integer; Sortie var SPWM: 0,1); const K = ...; Coefficient dadaptatation; 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 regroups pour ne former qu'une seule action: RESTE et N sont alors considres comme variables internes GENERATION_NIVEAU1 et modifies sur apparition de HB. Pour dterminer la vitesse, deux principes sont utilisables partir des vnements mis par le codeur incrmental: - le principe du priodemtre, en comptant le nombre de priodes lmentaires entre 2 impulsions du codeur, - le principe du frquencemtre, en comptant le nombre d'impulsions du codeur durant un intervalle de rfrence. Les 2 solutions avec la structure fonctionnelle correspondante sont indiques figure 19.11. Le choix entre les 2 solutions doit se faire sur la base de la prcision et de la vitesse d'obtention de la mesure. - priodemtre: faible prcision grande vitesse, mais temps de mesure faible, temps de mesure long pour les vitesses faibles. - frquencemtre: faible prcision petite vitesse, grande prcision grande vitesse, temps de mesure constant mais plutt faible. Pour la solution frquencemtre: avec une priode T de 5 ms correspondant au pas souhait pour la rgulation avec un codeur 100 points/tr, le nombre maximum d'incrments est de 10 vitesse maximale de 3000 trs. Cette solution ne donnera donc pas une prcision suffisante. Pour cette raison, le choix se porte sur le principe du priodemtre. M.C.S.E 397

Partie 5 - DEFINITION DE LA REALISATION La priode H s'value compte-tenu de la prcision dsire vitesse maximale. D'aprs les spcifications, celle-ci doit tre de 10 trs 3000 trs. Il faut donc au minimum 300 tops de H entre 2 incrments distants alors de 0,2 ms. La priode 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 priodemtre
INC INC

Principe frquencemtre

H V = k / nbH

T (priode 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 dure

Comptage frquence

-Figure 19.11- Structures fonctionnelles pour la mesure vitesse. Pour rsoudre ce problme de prcision, on peut adopter le principe d'un priodemtre autoadaptatif. Ceci veut dire que si le nombre d'impulsions de H compt n'est pas suffisant, on attend l'vnement INC suivant. La priode de H est alors calcule pour que le dpassement des 16 bits corresponde une vitesse infrieure 10 trs/mn. Ainsi la priode 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 (entre/sortie var NBH: integer; Sortie var V: def_vitesse); const NBMIN = 1000; NBMAX = 65535; (dbordement 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 intressant car il rduit la frquence de calcul de la vitesse (qui ncessite au moins une division) une valeur suffisante pour la rgulation, ceci l'aide du choix appropri de NBMIN. Il est suppos que l'action COMPTAGE_DUREE arrte l'incrmentation de NBH lorque la valeur maximale est atteinte.
-B- INTRODUCTION DE LINTERFACE UTILISATEUR

En sortie, les seules grandeurs sont: VROTATION qui indique tout instant la vitesse de consigne, et ROTATION un indicateur prcisant si le moteur tourne ou ne tourne pas. Ces 2 grandeurs sont considres compatibles avec les interfaces physiques que sont: un afficheur dcimal 4 digits et une led. En entre pour le niveau fonctionnel, l'utilisateur a t considr comme gnrateur d'vnements. L'interface fonctionnelle justifie l'emploi d'un port ORDRE. Dans le cas du rglage de la vitesse de consigne, cette grandeur est transmise dans le message qui indique ainsi l'vnement changement de consigne. L'interface physique pour l'utilisateur, dcrite dans les spcifications, est compose de 4 touches: MARCHE et ARRET pour le contrle en rotation, PLUS et MOINS pour le rglage de la vitesse. L'interface utilisateur dvelopper est reprsente figure 19.12.
PLUS MOINS MARCHE ARRET Gestion dialogue VROTATION

ORDRE

ETAT

Contrle en Vitesse du Centrifugeur

EROTATION

-Figure 19.12- Dlimitation de la fonction concevoir. La spcification fonctionnelle indique que la modification de la consigne de vitesse ne peut se faire que lorsque le centrifugeur est arrt. Une variable d'tat (ETAT) est ncessaire en entre de gestion dialogue. Cette variable est directement la variable ETAT issue de CONTROLE_VITESSE. Pour effectuer le rglage par les touches PLUS et MOINS, l'utilisateur doit aussi pouvoir visualiser la consigne durant la modification. VROTATION doit tre couple GESTION_DIALOGUE et nest plus ncessaire pour GESTION_ CENTRIFUGEUR. La fonction GESTION_DIALOGUE peut se dcrire directement par un algorithme, en supposant que cette fonction scrute en permanence les tats des 4 touches en entre et ainsi dtecte les vnements correspondants. La spcification de la fonction est donne figure 19.13. M.C.S.E 399

Partie 5 - DEFINITION DE LA REALISATION

Repos (PLUS ou MOINS ) .MARCHE.ARRET

MARCHE .ARRET (ETAT = arrt) Attente ordre ARRET

Ordre(Marche)

Rglage consigne Ordre(Arrt) 2 sec. sans appuyer sur PLUS ou MOINS

Visualisation par VROTATION

Ordre(Consigne ; Val_consigne := VROTATION)

Attente fin (ETAT = arrt)

-Figure 19.13- Spcification de la fonction GESTION_DIALOGUE. 19.4.5. Exemple 2 : automatisation par chariot filoguid Le chariot est ici un lment d'une application rpartie. 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 rgles de rpartition. Les interfaces introduire servent uniquement de couplage avec des entits physiques, le chariot n'tant pas contrlable 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 srie sur un fil. Les interfaces ncessaires sont reprsentes figure 19.14. Chaque message est simple; un octet suffit. Ainsi, les 2 fonctions: rception et mission sont classiques et se dcomposent pour mettre en vidence les composants physiques adapts pour la transmission tel quun 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 dduire comme la diffrence entre les informations AC1 et AC2 fournies par 2 capteurs situs l'avant de chaque ct du fil de guidage. La solution indique figure 19.15 montre l'emploi d'une seule fonction de conversion pour obtenir DCA par diffrence AC1-AC2. La conversion est synchrone lvnement priodique START. En fin de conversion, EOC engendre lutilisation de VCAN pour le calcul de DCA aprs la mesure des deux voies. 400 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

Interface dentre

Interface de sortie

RxD

Rception des ordres

ORDRE Supervision

CR

Emission des compte-rendus

TxD

E_CAR

RxD

R E C P T E U R

reu

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 numrique


VCAN

Calcul de DCA

DCA

Slection entre

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 priodemtre de manire avoir une observation rapide de la vitesse pour des dplacements rapides (voir figure 19.16). A vitesse maximale, le nombre d'incrments 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

Evaluation_temps

Horloge

-Figure 19.16- Solution pour la mesure de chaque vitesse. la priode minimale de INC est donc: 5,3 ms. Pour une prcision de 5%, il faut TH = 0,26 ms. La gnration des 2 grandeurs analogiques CVM1 et CVM2 ncessite l'utilisation de convertisseurs numrique-analogiques comme fonctions permanentes. 19.5. CONTRAINTES POUR UNE STRUCTURE DEXECUTION L'allocation a pour objectif de dterminer le support excutif ncessaire pour assurer l'volution de l'application. Plusieurs dmarches sont possibles suivant la nature du rsultat attendu. Celui-ci dpend de la stratgie de dveloppement respecter et qui a une influence sur le cot: faible cot de reproduction ou faible cot pour le dveloppement du matriel. Pour tre correcte, une allocation doit conduire un systme respectant toutes les contraintes de temps. Les rgles de vrification sont dtailles tout d'abord. On dcrit ensuite 3 techniques de recherche d'une structure d'excution: par regroupement, par raffinement, par abstraction. 19.5.1. Evaluation des contraintes de temps Le modle fonctionnel utilise l'hypothse du temps nul pour le droulement des oprations des fonctions lmentaires. Cette hypothse ne tient plus ds qu'intervient un support d'excution. Le temps d'excution des instructions (puissance non-infinie du processeur) introduit une distorsion temporelle sous la forme de retards. Certaines distorsions ne sont pas gnantes, 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 spcifications technologiques sous la forme d'un temps sparant l'instant d'apparition d'une sollicitation (traduit par un vnement) de l'instant d'achvement de l'action consquente qui doit rester infrieur un temps maximum donn. Le non-respect de ces contraintes peut conduire l'application dans un tat assimilable un tat de panne matrielle. 402 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION D'autre part, pour rduire le support technologique, si possible, plusieurs actions sont implantes sur un mme processeur. Le partage du processeur pour les actions peut aussi conduire des retards d'excution non-tolrables. Dans le modle d'allocation, un processeur qui satisfait toutes les contraintes de temps pour les actions qu'il supporte, est considr OPERATIONNEL. Un processeur est dit OPERATIONNEL si son taux d'occupation tout instant reste infrieur 1, et si toutes les contraintes de temps pour les actions se trouvent respectes. Pour vrifier le respect des contraintes de temps, lorsqu'une solution est dfinie ou pour en choisir une qui les respecte, il faut valuer 2 paramtres pour chaque action temporaire [CALVEZ-82] : - la frquence maximale d'activation FA, - le temps d'excution maximum TE. Ces 2 paramtres sont indpendants. Le premier, la frquence d'activation, dfinie par les vnements ou messages en entre de l'action, se dduit des spcifications du problme et de l'analyse de la description fonctionnelle. Ce paramtre est indpendant de la structure d'excution. Le temps dexcution par contre, est fonction pour le processeur retenu, des temps d'excution des oprations 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 associes un processeur, - sur les temps d'excution de chaque action et ceci, soit en modifiant l'algorithme, soit en changeant la nature et donc la puissance du processeur d'excution. Seules les valeurs les plus dfavorables pour les 2 paramtres FA et TE sont utiles pour vrifier le respect a priori des contraintes de temps. On se placera ici en plus dans le cas d'actions possdant en entre plusieurs vnements d'activation.
-A- DEMARCHE

Lvaluation des contraintes de temps pose quelques problmes pour au moins 2 raisons: - les actions implantes en logiciel ne sont pas connues ce stade. Au contraire, la solution -matrielle ou logicielle- pour chaque action se dcide partir de cette valuation des contraintes de temps. - le type de processeur n'est pas connu. Ainsi le temps d'excution est difficilement valuable. Malgr cette difficult, pour pouvoir dcider du support matriel, la dmarche propose est la suivante: - analyser la structure fonctionnelle complte et classer les actions en 3 catgories: celles raliser obligatoirement par un processeur spcialis (solution matrielle), celles raliser l'aide d'un processeur programmable, les actions ralisables par les 2 techniques. - valuer les temps d'activation et d'excution pour les actions des 2 dernires catgories en se basant sur une catgorie de processeur (8 bits de prfrence, sinon 16 ou 32 bits). M.C.S.E 403

Partie 5 - DEFINITION DE LA REALISATION Le point de dpart de l'analyse est la structure fonctionnelle complte comprenant les interfaces. Celle-ci reprsente toutes les actions du systme. Toutes les transformations fonctionnelles ont t faites: introduction de la rpartition et des interfaces, discrtisation au maximum des actions permanentes pour en rduire le nombre, rduction du nombre de gnrateurs du type horloge pour augmenter le synchronisme des vnements. L'valuation se traduit par un tableau des valeurs maximales. La frquence d'activation se dduit des spcifications, tandis que le temps d'excution se dduit de la longueur et de la nature de l'algorithme de l'action. Ces temps sont ensuite comparer aux contraintes de temps indiques dans les spcifications technologiques. Les actions qui mritent une attention particulire sont celles qui ont un taux d'occupation lev T0 = FA*TE > 0,2 0,5 et celles pour lesquelles le temps d'excution maximum est de l'ordre de grandeur de la contrainte de temps de fin d'excution.
-B- EVALUATION DES FREQUENCES MAXIMALES DACTIVATION

Le cas le plus dfavorable pour la frquence maximale d'activation FA correspond la valeur maximale des frquences d'apparition des vnements d'activation de l'action. Or ces vnements sont directement lis aux vnements engendrs par les entits de l'environnement ou par d'autres actions. Les spcifications permettent donc de dterminer leurs valeurs. Pour les actions permanentes gnratrices d'vnements, la frquence de gnration en sortie n'est fonction que du comportement de laction. FA se dduit aussi des spcifications. Il est noter que la frquence de production des messages n'intervient pas dans l'valuation des frquences maximales. En effet, le port est utilis comme tampon entre producteur et consommateur. Si toutefois des contraintes existent, telle que la capacit limite du port pour l'implantation, il faut alors faire la mme valuation que celle dcrite ci-dessus, en considrant que la production d'un message correspond la gnration d'un vnement du type "existence d'un message".
-C- EVALUATION DU TEMPS DEXECUTION MAXIMUM

Le temps d'excution maximum pour chaque action est directement li au processeur servant de support dexcution. L'valuation est d'autant plus difficile qu