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 que le processeur est luimme un lment choisir, et que mme s'il est impos la transposition: description algorithmique > programme- n'est faite que durant l'tape de ralisation. Le travail de transcription peut se rduire en utilisant des traducteurs automatiques, ce qui justifie l'intrt de s'orienter vers l'utilisation de langages de haut-niveau. En l'absence de contraintes pour les processeurs utiliser, le temps d'excution est valu pour un PROCESSEUR dit de REFERENCE qui correspond une catgorie de performances. Comme type de processeur, on peut prendre le processeur 8 bits, le processeur 16 bits, ou le 32 bits si ncessaire. L'analyse (analyseur de performances) ou la simulation d'une action temporaire permet de dterminer pour un processeur de rfrence, le temps d'excution maximum pour chaque activation de l'action (traitement indcomposable temporellement). Les squences de traitement associes chaque vnement tant matriellement exclusives, le cas le plus 404 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION dfavorable pour l'action apparait lorsque tous les vnements d'activation apparaissent simultanment. Le temps maximum d'excution est gal la somme des temps maximums d'excution de chaque squence. La figure suivante montre ce cas et prsente le droulement squentiel pour satisfaire lexclusion de T1 et T2.
H MESS T1 H T1 T2

cycle H: begin T1; end; MESS : begin T2; end; end cycle;

TAmin

T1 T2

T1

(Tex(T1)+Tex(T2))max

-Figure 19.17- Cas le plus dfavorable pour le temps d'excution. Pour tre correcte, l'valuation du temps d'excution doit inclure les temps de commutation de contexte qui peuvent apparatre lorsque plusieurs actions se partagent un seul processeur. Pour cela, la dure maximale sera obtenue en considrant que le processeur est trouv avec un autre contexte avant l'excution et rendu dans le mme tat en fin d'excution. De cette manire, il y a automatiquement prise en compte du cot en temps de gestion du partage du processeur (overhead). Lorsque lalgorithme est crit en langage de haut-niveau (PASCAL par exemple), une premire approximation des temps dexcution sobtient par la formule suivante: Tex = nb_lignes_de_programme * Facteur_expansion * Temps_moyen_instruction Le facteur dexpansion correspond la transformation dune instruction PASCAL en instructions assembleur. Il est de lordre de cinq pour un processeur 8 bits, de 3 4 pour un processeur 16 bits. Temps_moyen_instruction est le temps moyen dexcution des instructions assembleur. Pour un 8 bits, il est de lordre de 2 s et de 1 s pour un 16 bits. Bien entendu, ceci nest quune formule approximative mais qui permet avec peu dexprience de recenser les actions contraignantes.
-D- TAUX DOCCUPATION MAXIMUM DUN PROCESSEUR POUR PLUSIEURS ACTIONS

Pour chaque action temporaire, la frquence maximale d'activation est FAi et son temps d'excution maximum est TEi. Le taux d'occupation maximum pour n actions excutes sur un processeur requrable (Suspension d'une action au profit d'une autre plus prioritaire) est alors : T0 max =

i=1..n

FAi*TEi

Ce taux doit toujours rester infrieur 1, condition strictement ncessaire mais pas suffisante pour que le processeur soit considr oprationnel. M.C.S.E 405

Partie 5 - DEFINITION DE LA REALISATION

-E- RESPECT DES CONTRAINTES DACTIVATION

La politique d'ordonnancement des tches sur le processeur a une importance sur le respect ou non des contraintes de temps. Pour une action priodique, lexcution de laction doit tre acheve avant que napparaisse lvnement dactivation suivant. On montre ci-dessous 2 cas d'ordonnancement suivant la priorit pour les 2 mmes actions A1 et A2.
MAUVAIS
A1 A2

BON
A1 A2

perdu

Priorit
A2

Priorit

A1

fin de A1

Prior. A1 < Prior. A2

Prior. A1 > Prior. A2

-Figure 19.18- Influence de l'ordonnancement vis vis des contraintes de temps. Pour le premier cas, un vnement dactivation de A1 est perdu car le processeur est alors allou A2. Comme rgle pour l'ordonnancement, on retiendra une stratgie simple et suffisante base sur un ordonnancement priorit fixe. L'utilisation du processeur pour ce critre est alors optimal en choisissant: priorit Ai > priorit Aj pour FAi > FAj i et j Cette stratgie est particulirement adapte aux microprocesseurs qui, compte-tenu de leur faible cot, ne ncessite pas une utilisation maximale de leur puissance, contrairement aux systmes informatiques. Attention toutefois, car cette mthode ne tient pas compte des sections critiques qui peuvent exister avec lemploi des variables partages. Un tournoi conflictuel peut exister entre lordonnancement priorit fixe et lexclusion mutuelle [KAISER-82].
-F- RESPECT DES DATES DE FIN DEXECUTION

Les contraintes de temps du type chance (deadline), sont plus svres que les prcdentes, car la date de fin est normalement antrieure la date dapparition de lvnement suivant. Pour vrifier le respect de telles contraintes, il faut dterminer a priori la date de fin dexcution de chaque action. La dtermination est itrative partir de laction la plus prioritaire. Pour un ordonnancement priorit fixe, supposons les priorits telles que : priorit A1 > ... priorit Ai > ...priorit An Le cas le plus critique apparait lorsque tous les vnements d'activation sont simultans. Soient: - RDi: le retard maximum pour le dbut d'excution de Ai, - RFi: le retard maximum pour la fin d'excution de Ai, 406 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - TOi: le taux doccupation du processeur pour laction Ai et toutes celles plus prioritaires, - TEi: le temps d'excution de Ai sur le processeur totalement disponible. On obtient les rsultats suivants pour les diffrentes actions: RD1 = 0 RD2 = TE1 ... RDi = TEi-1/(1-TOi-2) RF1 = TE1 RF2 = TE2/(1-TO1) ... RFi = TEi/(1 - TOi-1)

Ces valeurs peuvent servir vrifier pour chaque action le respect des contraintes de fin d'excution.
-G- CAS DES TRES FORTES CONTRAINTES DE TEMPS

Il est possible de tomber sur la situation o la contrainte de temps d'une seule action ne peut tre satisfaite: processeurs actuels pas assez performants, action particulirement complexe. Pour un tel cas, il est souhaitable de revenir l'tape prcdente de conception et rechercher pour l'action une solution fonctionnelle en mettant en vidence un paralllisme. Il s'agit alors d'une transformation d'un algorithme squentiel en une structure volution parallle. Ceci se fait partir du graphe flot de donnes qui dcrit les relations d'ordre.
-H- CAS DES ACTIONS PERMANENTES

Normalement, les actions permanentes ncessitent chacune un processeur d'excution. Pour rduire la complexit matrielle, 2 solutions sont exploitables: - Transformer les actions permanentes en actions temporaires. Ceci revient discrtiser dans le temps l'volution de l'action. Pour cela, il suffit de dfinir un pas de discrtisation, la priode se dterminant comme la valeur maximale tolre pour que l'action temporaire donne un comportement suffisamment proche de l'action permanente de dpart, de manire toujours satisfaire les spcifications. Une fois dfinie la priode, il faut ajouter l'action de gnration de l'vnement d'activation. Cette technique est classique pour transformer les fonctions du type continu en fonctions discrtes. - Regrouper plusieurs actions permanentes dans la tche de fond. Cette tche de fond est en fait la seule tche permanente possible pour un processeur programmable. Elle sert alors de squenceur pour allouer priodiquement le processeur aux actions permanentes qu'elle regroupe. La vrification du respect des contraintes de temps pour le deuxime cas ncessite d'valuer: - le taux d'utilisation du processeur disponible pour la tche de fond et les actions qu'elle englobe, - la frquence d'excution de chaque action qui dcoule du taux dutilisation disponible, - la dure maximale d'excution. Pour expliquer ceci, supposons une tche de fond regroupant les 2 actions A1 et A2. Elle s'crit comme suit: M.C.S.E 407

Partie 5 - DEFINITION DE LA REALISATION

cycle: begin P(A1); P(A2); end; end cycle;

P(A1) et P(A2) sont les procdures construites en ne gardant de A1 et de A2 que la squence d'instructions inclue dans linstruction cycle. Soient TE1 et TE2 les temps d'excution de chaque procdure sur un processeur donn. Supposons de plus que le processeur supporte d'autres actions temporaires. Le taux maximum d'utilisation du processeur pour ces actions temporaires est TOmax. Le taux d'utilisation disponible minimum pour la tche de fond est: TU = 1 - TOmax La priode minimale d'excution de P(A1 et P(A2) est donc: Tfond = (TE1 + TE2)/TU La dure maximale d'excution (en moyenne) pour A1 et A2 est: TE1/TU ou TE2/TU Ce calcul simple montre que la tche de fond dispose d'un processeur dont le facteur de puissance est rduit de 1 TU avec les actions temporaires. 19.5.2. Techniques pour dduire une structure dexcution La structure d'excution rsultera de la dmarche suivie pour la dterminer qui est fonction du type de dveloppement: faible nombre d'exemplaires, ou nombre important. Indpendamment de ces 2 cas, une structure d'excution peut s'obtenir: - par regroupement de structures prdfinies, - par raffinement, - par abstraction.
-A- REGROUPEMENT DE STRUCTURES PREDEFINIES

Cette technique consiste exploiter des structures d'excution existantes pour construire des structures plus complexes. Les structures existantes rsultent, soit de dveloppements antrieurs, soit correspondent des produits existant sur le march: carte processeur au format STD, VME, Multibus... Cette technique en faveur de la rutilisation de solutions existantes conduit une rduction considrable du cot de dveloppement de la solution matrielle, mais conduit un cot de reproduction assez lev. Elle est favorable pour un dveloppement en nombre limit.
-B- PAR RAFFINEMENT

Tout processeur spcifi et qui n'est pas directement ralisable avec la technologie actuelle ou impose, peut se dcomposer sous la forme d'une structure d'excution plus lmentaire. Cette technique est exploitable par les concepteurs de circuits ou de cartes et par les techniciens chargs du dveloppement du matriel ncessaire pour satisfaire les spcifications de la structure d'excution. Ceci est possible, car le modle d'excution est un modle hirarchique qui permet de dcrire tout niveau d'architecture, des systmes complexes jusqu'aux composants de base de l'lectronique numrique. 408 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

-C- PAR ABSTRACTION

Pour un sous-ensemble d'une structure d'excution donne, il peut tre intressant de le remplacer par un seul processeur. Dans ce cas, la ralisation se trouve simplifie car le nombre de composants diminue et les interconnexions deviennent internes au processeur. Utilisant cette technique, il faut s'assurer que le processeur de remplacement reste oprationnel pour la description fonctionnelle qu'il doit supporter. L'opration d'abstraction consiste: - dlimiter un ensemble de processeurs, - faire disparaitre tous les lments internes l'ensemble, - remplacer l'ensemble dlimit par un processeur dfini par ses spcifications. Le choix des regroupements doit tenir compte des couplages pour rduire au maximum la complexit de la structure rsultante. Le couplage entre 2 processeurs est fonction des facteurs suivants: le nombre de liens d'interconnexion, la taille des informations changes, la frquence des changes, le cot en temps des changes.

19.6. DETERMINATION DE LA STRUCTURE DEXECUTION Selon lanalyse faite en 19.1, pour une petite srie, le concepteur s'oriente plutt vers l'utilisation de produits existants. il suffit alors de s'assurer qu'une allocation de la description fonctionnelle est possible sur la structure d'excution souhaite. Pour des productions de plus grande srie, l'objectif est de rduire au maximum le cot de reproduction du matriel. Ceci conduit rechercher une structure d'excution minimale. La technique utiliser est celle de l'Abstraction. Le concepteur part d'une structure d'excution similaire la structure fonctionnelle. Ceci veut dire qu'il associe un processeur pour chaque action, en utilisant au maximum des processeurs programmables. Il rduit ensuite progressivement par abstraction la structure d'excution en implantant plusieurs actions sur un mme processeur tout en vrifiant le caractre oprationnel. La recherche des regroupements se fait par couple de processeurs en se laissant guider par les couplages. Ceci n'est bien sr possible que pour les processeurs programmables. Dans la pratique, une telle recherche de solution est relativement simple partir des caractristiques temporelles des actions de la description fonctionnelle, car lexprience nous a montr que pour une application donne, il n'existe en fait que peu d'actions avec de fortes contraintes de temps. 19.6.1. Choix de la rpartition matriel / logiciel La solution retenir dpend donc du critre de dveloppement: faible nombre ou production importante. Dans le cas d'une faible srie, il s'agit de trouver le support matriel capable de supporter toutes les fonctions du systme. On s'oriente alors vers des structures d'excution gnrales extensibles disponibles sur le march. Des interfaces ou des fonctions particulires peuvent manquer. Elles s'ajoutent alors comme extension. M.C.S.E 409

Partie 5 - DEFINITION DE LA REALISATION Lorsqu'il s'agit de rduire le cot de reproduction du matriel, il faut rechercher la structure d'excution minimale. Des choix peuvent aussi apparatre entre solution matrielle ou solution logicielle. Entre les 2, la solution logicielle est prfrable car volutive mais aussi moins coteuse pour la reproduction, condition que le temps de dveloppement ne soit pas excessif et que les performances restent satisfaisantes. La dmarche pour dduire la rpartition matriel/logiciel part du tableau d'valuation des temps pour les actions. Toutes les actions correspondant un taux d'occupation faible et sans contrainte de temps, ce qui est le cas pour au moins 80% des actions si ce n'est pas plus, sont regroupes pour tre implantes sur un mme processeur. Le taux d'occupation du processeur est calcul au fur et mesure de l'ajout d'une action. Mme si la mthode est gnrale et que la dtermination peut se faire d'une manire incrmentale en considrant les actions par couple, l'exprience nous a montr que la solution se dduit assez simplement, car dans la plupart des cas, toutes les actions ralisables par logiciel sont implantables sur un mme processeur. Parfois, lorsque quelques actions sont particulirement contraignantes, il suffit de s'y intresser plus spcifiquement. Plusieurs solutions sont alors possibles: - ralisation par une solution matrielle, - modification des spcifications d'excution (frquence d'activation), - modification de l'approche fonctionnelle pour rduire les contraintes, - choisir un processeur plus performant (16 bits par exemple au lieu de 8 bits). Ces 2 phases -valuation des contraintes et choix de la rpartition- sont illustres sur les deux exemples de conception. 19.6.2. Exemple 1 : contrle en vitesse dun centrifugeur Une fois discrtises toutes les actions utiles, puis aprs rduction des gnrateurs d'vnements priodiques, on aboutit la structure fonctionnelle complte donne figure 19.19.
-A- EVALUATION DES CONTRAINTES DE TEMPS

Pour la rgulation, on supposera que, compte-tenu de l'inertie faible du moteur, une priode d'chantillonnage de 5 ms est correcte. Les priodes des vnements sont donc: T_HB = 0,915 s # 1 s, T_HPERIODE = 1 ms, T_INC = 0,2 ms, T_H = 5 ms.
-B- REPARTITION MATERIEL/LOGICIEL

Les actions DIVISEUR_PERIODE, HORLOGE, COMPTAGE_DUREE, GENERATION_NIVEAU1 sont obligatoirement raliser par matriel. Les autres actions sont ralisables par logiciel. Le type de microprocesseur tant impos par les spcifications: Motorola 68000 par exemple, il est possible de calculer le temps d'excution maximum pour chacune des actions temporaires. Les temps suivants sont approximatifs: 410 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PLUS MOINS MARCHE ARRET Gestion dialogue

VROTATION

ORDRE

Gestion centrifugeur M/A CROTATION ETAT EROTATION Diviseur priode

Hpriode Diviseur

Commande_vitesse

HB Horloge INC CV Comptage dure nbH Calcul vitesse Vmoteur Asservissement vitesse Gnration niveau 1 SPWM H VCONSIGNE HB HPERIODE

-Figure 19.19- Structure fonctionnelle complte pour le centrifugeur. Temps DIVISEUR < 20 s Temps ASSER_VITESSE < 100 s Temps COMMANDE_VITESSE < 100 s Temps CALCUL_VITESSE < 100 s On peut ainsi s'assurer que toutes les contraintes de temps seront satisfaites mme dans le cas le plus dfavorable pour une implantation sur un seul microprocesseur: Tocc = 0,020/1 + (0,1+0,1)/5 + 0,1/0,2 = 0,56. Un contour en pointill sur la structure fonctionnelle permet de dlimiter les 2 parties: matrielle et logicielle. La partie centrale logicielle (figure 19.19) reprsente le rle attribu au microprocesseur. La partie matrielle reprsente les interfaces entre le microprocesseur et lenvironnement du systme. 19.6.3. Exemple 2 : automatisation par chariot filoguid La structure fonctionnelle complte, synthse de lintroduction des interfaces et aprs rduction des gnrateurs dvnement, est reprsente figure 19.20. M.C.S.E 411

Partie 5 - DEFINITION DE LA REALISATION

RxD Rcepteur

E_CAR

S_CAR

Rcep- ORDRE tion ordre Fin_T T

CR Supervision

TxD Emetteur

Emission CR
C_SIRENE

Sirne Tempo obstacle position_quai AC1 MUX AC2

AC EOC DCA

M/A ETAT C_TAPIS_MARCHE C_TAPIS_SENS

PAS Mmorisation
VCAN

CAN

Coordination PAS VC1 VC2 CVM2 CVM2 Asservissement

VM1

INC_VM2

HCAN

No_Voie
VM2 Evaluation vitesse

INC_VM1 Diviseur

T Evolution temps

CNA CVM1 CVM1

vitesse 1

H Horloge

-Figure 19.20- Structure fonctionnelle complte pour le chariot. On fait tout d'abord le bilan des frquences et temps d'excution probables dans le cas d'une implantation logicielle. Tinc = 5,3 ms TH = 260 s Tpas < 15 ms 10 ms THcan = 5 ms Teoc = 5 ms Treu = 4 ms (pour ORDRE) Teval_vitesse = 500 s Tevolution_temps = 50 s Tcoordination < 200 s Tasservissement < 200 s Tmemorisation = 50 s Ttempo = 50 s

Si on exclut SUPERVISION qui est une action sans contrainte, le taux d'occupation d'un processeur 8 bits est trs approximativement : Toccmax < 0,5/5,3+2*50/260 +(0,2+0,2)/10 +2*0,05/5 = 0,32 Ainsi toutes les actions sont implantables en logiciel sur un seul microprocesseur, en dehors des fonctions: gestion de la liaison srie raliser par un transmetteur-rcepteur srie, lensemble multiplexeur et convertisseur A.N. 19.7. SCHEMA DIMPLANTATION LOGICIELLE POUR CHAQUE PROCESSEUR La phase prcdente a permis de dcider les sous-ensembles de la structure fonctionnelle complte implanter sur chaque processeur programmable. L'implantation logicielle dfinit l'organisation du logiciel pour chaque processeur. 412 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Il sagit de dcider: - des regroupements d'actions possibles de manire constituer les tches implanter, - d'une priorit pour chaque tche, - d'une technique d'implantation pour chaque relation fonctionnelle. Dans le chapitre 18 des rgles ont t dcrites pour le modle d'implantation. De plus, L'objectif est de rduire la partie organisationnelle de manire rduire la taille du logiciel et sa complexit et en consquence le temps de dveloppement, de test et de mise au point. La stratgie d'ordonnancement conseille pour les tches est d'adopter une priorit proportionnelle la frquence d'activation. Plus une tche est active frquemment, plus a priori elle est courte, et donc plus rapidement il est souhaitable de l'achever. Pour l'implantation des relations, il est souhaitable d'utiliser le plus possible l'appel procdural, ce qui simplifie la partie organisationnelle. Cette solution n'est possible quentre des actions de priorit relative croissante. Les tches actives par un vnement matriel seront actives par le systme d'interruption du processeur. Les actions permanentes et certaines cycliques sans contraintes de temps sont implantes comme procdures dans la tche de fond. Lorsqu'il est souhaitable d'utiliser un excutif temps-rel ou des services d'un systme d'exploitation, les tches sollicitent ces services par appel procdural. Pour les tches complexes, une structure de modules permet de dcrire la structuration du programme correspondant. Quelques rgles de traduction ont t prsentes dans le chapitre prcdent (voir 18.4), il est conseill au lecteur de revoir ces rgles qui sont essentielles pour cette phase. Rappelons tout dabord la rgle principale, puis celle-ci tant suppose maitrise, on s'intressera plus particulirement aux rgles de transformation pour diverses structures ainsi qu'aux transformations appliquer pour les donnes. La technique prsente est proche de la technique dinversion prconise par JACKSON (voir chapitre 7) [JACKSON-83]. 19.7.1. Traduction dune dpendance temporelle entre deux actions La dpendance temporelle rsulte dune relation par vnement ou par transfert de messages. Les deux actions concernes par la relation sont implantes en logiciel, il en sera donc de mme pour la relation. La solution retenir dpend de la priorit des deux actions: - priorit infrieure de la source : appel procdural. - priorit suprieure de la source : utilisation dune tche intermdiaire pour assurer lattribution du processeur laction dpendante moins prioritaire. Les deux cas de solutions sont rappels par la figure 19.21. La dmarche de transformation sapplique pour chaque couple dactions en commenant par les actions les plus prioritaires. Cette technique a pour intrt de rduire au strict minimum la partie organisationnelle du logiciel. Cette phase est illustre sur les 2 exemples. M.C.S.E 413

Partie 5 - DEFINITION DE LA REALISATION

EV F1 ou bien MESS (ME) F2

Prior. F2 > Prior. F1

F1 F2

Prior. F1 > Prior. F2

F2 EV ou (ME) EV ou MESS EV ou (ME)

F1

F3

-Figure 19.21- Les 2 cas dimplantation pour une dpendance logicielle. 19.7.2. Exemple 1 : contrle en vitesse dun centrifugeur Sur la structure fonctionnelle complte dcrite en 19.6.2, le sous-ensemble central dlimit par les pointills est implanter sur un processeur programmable. Les vnements INC et HPERIODE sont ncessairement matriels puisque gnrs par des actions ralises par matriel. Les actions COMMANDE_VITESSE et ASSERVISSEMENT_VITESSE sont regroupes (excutes en squence) pour former une seule tche active par DIVISEUR. Deux actions sont donc implantes sous interruption: CALCUL_VITESSE et DIVISEUR. La fonction GESTION_DIALOGUE est implante comme tche de fond. Elle appelle pour chaque vnement ORDRE l'action GESTION_CENTRIFUGEUR implante comme procdure. Le choix des priorits et les couplages fonctionnels sont reprsents sur la figure 19.22. L'action dclenche par l'interruption HPERIODE s'crit ainsi:
action DIVISEUR sur vnement HPERIODE; Var N,VCONSIGNE:integer; begin N:=5; cycle HPERIODE: begin N:= N-1; if N=0 then begin N:=5; COMMANDE_VITESSE(VCONSIGNE); ASSER_VITESSE(VCONSIGNE); end; end; end cycle; end DIVISEUR;

414

M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PT2 A1 M1 A2

PT3 A3 M2

PT4 A4 M3

A4

A1

M3

M1

POUSS
M2

A3

A2

TIR
M2

A2

A3

M1

M3

A1

A4

-Figure 19.22- Schma pour l'implantation logicielle. Les 2 actions synchrones DIVISEUR - Commande_Vitesse et Asser_Vitesse - sont ainsi transformes en procdures. Pour obtenir une prcision correcte lors des calculs arithmtiques, les expressions ne doivent pas tre calcules dans n'importe quel ordre. Le calcul: VCONSIGNE := CROTATION*T/TM doit tre calcul dans l'ordre * puis /. En effet CROTATION, T et TM sont reprsentes en entier 16 bits. La multiplication conduit un rsultat sur 32 bits. La division faire est alors 32 bits/16 bits, ce qui donne un rsultat en 16 bits. Le rsultat ainsi obtenu montre que la partie organisationnelle du logiciel est rduite des appels de procdures et la programmation de deux tches sous interruption. 19.7.3. Exemple 2 : automatisation du chariot filoguid La structure fonctionnelle complte et le sous-ensemble implanter en logiciel est reprsente par la figure 19.20. Compte-tenu du nombre d'actions, il faut commencer par regrouper toutes celles actives par un mme vnement. Une premire tche est celle active par H. De mme pour toutes les actions actives par PAS: COORDINATION, les 2 asservissements de vitesse et Temporisation. Les vnements matriels sont: H, INC_VM1, INC_VM2, EOC, RECU. Toutes les tches associes sont actives par le systme d'interruption. La synchronisation par PAS est transforme en un appel procdural. M.C.S.E 415

Partie 5 - DEFINITION DE LA REALISATION La tche SUPERVISION est implante comme tche de fond. Comme l'mission se fait par message dun seul caractre, cette action s'implante comme procdure. Evolution_temps 1 et 2, Evaluation_vitesse 1 et 2, Mmorisation sont implantes sous interruption. On peut donc retenir l'implantation suivante:
priorit
H Evolution temps 1 T1 INC_VM1 Evaluation vitesse1 T2 Evolution temps 2 Diviseur H CAN

INC_VM2

Evaluation vitesse2 VM1 VM2

Asserv. 1 EOC Reu E_CAR Rception ORDRE Mmo- PAS risation

Asserv. 2 Coordination

Tempo.

T Emission CR

produit

ORDRE

(CR) Tche de fond : Supervision

S_CAR

-Figure 19.23- Schma pour l'implantation logicielle. Il est aussi possible d'implanter rception comme procdure non-bloquante. Dans ce cas, appele priodiquement par SUPERVISION, elle teste si un caractre existe. Si oui, l'action correspondante au message reu est entreprise, sinonSUPERVISION poursuit son activit. 19.7.4. Implantation dune squence dactions Supposons des actions couples par des ports pour le transfert de messages. La squence est suppose tout d'abord sans boucle. Deux stratgies d'implantation opposes sont possibles: la technique du pouss ou la technique du tir. Elles sont illustres par la figure 19.24. Pour la premire implantation, A1 joue le rle du moniteur, l'ensemble se comporte comme une seule action qui traite en squence chaque production issue de A1. Pour la deuxime implantation, A4 joue le rle du moniteur en sollicitant un message A3 et ainsi de suite jusqu' A1. La premire solution est plus approprie lorsque le systme est sollicit par ses entres (prise en compte par A1 d'un vnement ou d'un message). Le systme est alors en position d'esclave vis vis de l'environnement. C'est le cas des applications temps-rel et des applications transactionnelles (fonctionnement en ligne). La deuxime solution est plus approprie lorsque le systme est sollicit par ses sorties (demande d'informations). Le systme est alors producteur et donc en situation de matre. Il s'agit plus d'un fonctionnement du type "BATCH". 416 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

PT2 A1 M1 A2

PT3 A3 M2

PT4 A4 M3

A4

A1

M3

M1

POUSS
M2

A3

A2

TIR
M2

A2

A3

M1

M3

A1

A4

-Figure 19.24- 2 implantations opposes pour une squence. 19.7.5. Implantation dune squence boucle dactions Supposons maintenant le cas d'une structure fonctionnelle possdant un bouclage (voir figure 19.25). Aucune des 2 techniques prcdentes nest directement utilisable. Il faut tout d'abord rompre la boucle ce qui s'obtient en conservant obligatoirement un buffer tampon dans la boucle. Soit PT0 le port servant de buffer. On peut ensuite appliquer la technique du pouss ou du tir. Dans les deux cas, A1 est dcideur de l'entre prendre en compte entre PT0 et PT1. 19.7.6. Implantation de plusieurs squences dactions Supposons l'exemple suivant compos de 3 squences: 1 squence principale, une squence de convergence, une squence de divergence (voir figure 19.26). Le lien de A5 vers A2 est similaire au retour de A3 sur A1 de l'exemple prcdent. Il en est de mme pour le lien de A3 vers A6. Ainsi, un buffer est ncessaire entre les couples de squences. Pour la premire solution, A2 joue le rle du moniteur dcidant ainsi de la donne prendre entre PT1 et PT5. Ce rle de moniteur est jou par A4 pour la deuxime solution. M.C.S.E 417

Partie 5 - DEFINITION DE LA REALISATION

PT1 PT2 A1 M1 PT0 M3 A2 M2 PT3 A3

PT4

PT1 A3 A1

M2 M3 A2 PT0 M1 PT1 A1

M1 M3

POUSS

TIR

A2 PT0 M2

A3

-Figure 19.25- Implantation selon les 2 techniques pour une squence boucle.

PT1 PT2 A1 M1 PT5 M5 A5 PT7 M7 A2 M2 A3

PT3 M3 PT6 M6 PT8 M8 A6 A4

PT1 A4 M1 M3 M2 PT6 A3 M6 M2 PT1 A2 M1 M5 PT5 A4 M3 A2

PT5

M7

POUSS

TIR
A3

PT6

M6

-Figure 19.26- Exemple de plusieurs squences d'actions et solutions. 418 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION 19.7.7. Capacit des ports Les ports sont supposs de capacit illimite pour la description fonctionnelle. Cette hypothse n'est plus raliste avec un support matriel. Il faut donc dterminer la capacit des buffers ncessaire pour l'implantation. Cette dtermination se fait sur la base des vitesses relatives des actions. Un buffer peut tre conserv pour satisfaire des arrives par paquets (burst). La capacit maximale pour chaque buffer se dduit alors des spcifications de l'application et des performances en excution. Dans certaines situations, la capacit reste importante ce qui peut ne pas tre convenable pour l'implantation. Dans ce type de cas, il est possible d'obtenir un fonctionnement correct avec un buffer de capacit limite condition de pouvoir ralentir le producteur. Il faut alors implanter un mcanisme d'asservissement du producteur par le consommateur. La technique consiste contrler le producteur par un vnement ou une variable d'tat positionne par le consommateur. La figure suivante prsente deux solutions.

Pt

Producteur

Consommateur

1 place

n places

Bpt Dpt V_pt Prod. Cons. Prod. Cons.

Consomm

XON/XOFF

-Figure 19.27- Implantation avec asservissement consommateur>producteur. Pour la premire solution, le producteur ne dpose un nouveau message dans V_Pt quaprs rception de lvnement consomm qui concerne le message prcdent. Cet vnement peut aussi se transformer en une variable logique. Pour la deuxime solution, la variable XON/ XOFF est modifie par le consommateur en fonction du nombre de places occupes dans la bote lettres B_Pt. La technique de transmission selon le protocole XON/XOFF dcoule de cette spcification. 19.7.8. Utilisation des services dun processeur Un processeur peut mettre disposition de l'application des services qui permettent de rduire le dveloppement. C'est le cas par exemple d'un processeur disposant d'un systme d'exploitation. La technique est alors similaire celle dveloppe pour l'utilisation d'un excutif tempsrel. Les services sont considrs, regroups ou non, comme des procdures de priorit leve par rapport aux tches de l'application. Ces services peuvent eux-mmes tre grs par un excutif charg du partage du processeur. M.C.S.E 419

Partie 5 - DEFINITION DE LA REALISATION L'exemple suivant montre lutilisation en entre dun clavier et en sortie dun cran pour l'affichage des donnes. Le systme utilis met disposition les procdures Read(car) et Write(Mess).
CLAVIER Gestion Clavier Car A MESS Affichage ECRAN

Services disponibles Mess

Read

Car A

Write

-Figure 19.28- Implantation utilisant les services de gestion des E/S d'un systme. Pour cette implantation, le service de gestion du clavier ne restitue le processeur A que lorsqu'un caractre a t lu. Pour l'criture, la restitution du processeur A dpend de l'implantation du service: avec ou sans buffer. 19.7.9. Implantation de modules Pour une tche complexe, une structuration selon une hirarchie de modules peut s'avrer ncessaire. La mthode employer "Structured Design" (voir 7.4) est bien connue et dcrite dans beaucoup d'ouvrages: DEMARCO, JONES, YOURDON et CONSTANTINE, WARD et MELLOR, MARTIN et MC CLURE... Plutt que de dcrire cette mthode en dtail, il est souhaitable que le concepteur se rfre ces ouvrages. On se contente simplement de rappeler l'ide essentielle qui doit guider le concepteur. Une structure de modules s'obtient partir d'une spcification exprime par un diagramme flots de donnes. La premire phase consiste trouver le premier niveau de la dcomposition: le module principal, les modules appels. Cette dduction s'effectue en identifiant sur le diagramme flot de donnes les 3 parties: les entres, la transformation centrale, les sorties. Ceci permet de positionner 2 interfaces de manire minimiser les couplages entre parties. Cette dmarche est rutilisable pour chaque niveau infrieur. La technique est illustre par l'exemple ci-aprs.

O1 A O3 B O2 O1 C D O4 A

Squenceur B

A et B

C C O3 O4

O2

-Figure 19.29- Exemple de transformation pour obtenir une structure de Modules. 420 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION L'exemple montre qu'un module est utilis comme moniteur pour assurer l'enchanement des activits. 19.8. IMPLANTATION DES DONNEES Des donnes servent assurer: des couplages entre tches, la mmorisation d'informations pour l'application. La description fonctionnelle contient une description des donnes ncessaires. Elles sont modlises sous la forme de donnes individualites ou de collections de donnes. Chaque variable est dcrite par une structure de donnes dont la taille peut aussi bien tre petite ou complexe, statique ou dynamique. Des relations entre donnes sont aussi exprimables par des rfrences vers ces donnes. Le modle de description retenu pour le niveau fonctionnel se voulait indpendant de l'implantation. L'objet de ce paragraphe est de montrer les transformations de structure rechercher pour favoriser l'implantation des donnes. Il s'agit donc de passer d'une description logique une description physique. 19.8.1. Critres pour limplantation des donnes Deux objectifs peuvent tre considrs comme importants pour l'implantation des donnes: - l'indpendance, - l'efficacit.
-A- INDEPENDANCE

Considrons une donne partage utilise par plusieurs tches pour un mme processeur.
Partie dpendante de D
D A1 A2 Accs par A1 Accs par A2 D

Encapsulation

-Figure 19.30- Dpendance - indpendance vis vis de D. Si limplantation est la simple traduction de la structure fonctionnelle, 3 critiques essentielles sont prendre en compte [WARD-85]: - absence de protection: la donne D est globalement accessible par les actions lies. Des erreurs sont facilement possibles. - dpendance des actions: toute modification de la dfinition de D implique des modifications pour toutes les actions lies. - mcanisme d'accs spcifique pour chaque action: une technique d'accs est dveloppe pour chacune, ce qui augmente l'effort de dveloppement. Bien entendu ces remarques sont particulirement valables pour des donnes D structures et complexes. M.C.S.E 421

Partie 5 - DEFINITION DE LA REALISATION Pour remdier ces inconvnients, l'objectif est d'aboutir une implantation des tches et des modules indpendante des donnes. Ce rsultat s'obtient en plaant autour de la donne D une couche logicielle assurant l'encapsulation de celle-ci. Cette couche offre aux tches les accs ncessaires sous la forme de services. L'indpendance implique aussi que la position d'une information dans la donne D ne soit connue qu' l'instant de la sollicitation, ce qui est une contrainte plus difficile satisfaire.
-B- EFFICACITE

L'efficacit est une condition souvent ncessaire pour les systmes temps-rel. Elle s'obtient en disposant de mcanismes d'accs aux donnes les plus directs. C'est le cas lorsque pour un accs donn, la position d'une information dans la donne D est connue. Ainsi, les deux objectifs, indpendance et efficacit, s'avrent donc contradictoires. L'implantation a pour but de dcider du meilleur compromis entre ces 2 aspects de manire satisfaire au mieux les spcifications et ceci, en proposant une structure interne et les mcanismes d'accs ncessaires. 19.8.2. Implantation pour des donnes structures Se rfrant au modle fonctionnel pour les donnes, une entit structure est construite sur la base de 3 structures. A chaque cas correspond une technique d'implantation. - la composition: toutes les donnes qui composent cette structure sont implantes dans une zone contig. - la slection: tous les types de donnes sont implants dans une mme zone, s'y ajoute le type de la donne courante. - l'ensemble: cette donne est de taille variable. Dans le cas gnral, la solution est une implantation en file avec un mcanisme d'accs chaque lment. Lorsque la taille maximale est connue et relativement limite, la structure de tableau est plus propice. La structure interne se dduit donc par transformation de la description logique labore durant la conception fonctionnelle en une description physique. 19.8.3. Implantation pour des collections et des relations Les collections permettent de reprsenter un nombre quelconque de donnes de mme type. Des rfrences externes utilises dans les donns permettent aussi de dcrire des relations. Une donne particulire dans une collection est identifie par sa CLE. La technique d'implantation la plus directe pour cette catgorie de donnes est l'utilisation d'une base de donnes relationnelles. Chaque collection est alors implante sous la forme d'une table. Dans ce cas, l'accs une telle base de donnes est indpendante de la technique d'implantation de chaque champ: utilisation par exemple du langage SQL comme langage normalis d'interrogation. En contre-partie, l'efficacit pour des contraintes de temps svres peut ne pas tre suffisante. Si l'efficacit s'avre un objectif important satisfaire, des transformations sont entreprendre partir des collections de donnes: - les collections sont implantes dans des files ou des tableaux. - les rfrences externes pour les relations sont des liens directs par pointeurs sur les entits dsignes. 422 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - l'accs par une CLE doit tre dvelopp pour atteindre une bonne efficacit: table d'index, technique de HASH... L'exemple suivant donne une indication de la transformation sous la forme de tableaux pour une relation.
SALLE No

caractristiques
Nom

Salle
n

1 2 3

Appartient

ZONE No 1 2

caractristiques
Nom

Zone

Liste salle

-Figure 19.31- Exemple dimplantation pour une relation. Connaissant le numro d'une salle ou d'une zone, les caractristiques de la zone se dduisent avec efficacit. Par contre, s'il s'agit de connatre toutes les salles appartenant une zone, la mthode d'accs est plus complexe puisqu'il faut parcourir toute la table des salles. L'accs peut s'amliorer en ajoutant une liste chaine des salles partir de la zone (partie en pointill). 19.9. SPECIFICATION DE LA REALISATION MATERIELLE Cette phase est la dernire de l'tape. Elle consiste caractriser compltement la structure d'excution qui dcoule de la rpartition matriel/logiciel. Elle doit se situer de prfrence aprs celle d'implantation logicielle, car certaines dcisions pour l'implantation ont une influence sur le support matriel. C'est le cas en particulier pour les interruptions. En effet, un vnement matriel peut s'utiliser pour activer une tche sous interruption, mais il peut aussi se transformer en variable logique teste priodiquement par une tche. La structure d'excution rsulte d'une opration d'abstraction faite partir de la structure fonctionnelle complte. Elle consiste remplacer par une seule fonction chaque sous-ensemble ralis par logiciel. Il faut ensuite donner une interprtation pour obtenir la structure d'excution. Pour cela le nom de chaque fonction ou action est remplac par le nom du processeur qui va servir comme support d'excution. Chaque processeur est spcifie au mieux par toutes ses caractristiques pour que la ralisation puisse en dcouler. Certaines optimisations peuvent ensuite tre faites pour simplifier la fois la ralisation matrielle et l'implantation logicielle. M.C.S.E 423

Partie 5 - DEFINITION DE LA REALISATION Illustrons tout dabord cette phase sur les deux exemples, la suite dtaille la dmarche pour la dtermination des couplages entre processeurs dans le cas darchitectures plus complexes. 19.9.1. Exemple 1 : contrle en vitesse dun centrifugeur La structure dexcution s'obtient par le technique dabstraction partir de la structure fonctionnelle dtaille donne en 19.6.2 en remplaant toutes les actions logicielles qui ne forment qu'un seul sous-ensemble, par une fonction dont le support excutif est un processeur programmable. Le rsultat est reprsent ci-aprs.
4 afficheurs pour Sorties logiques EPROM > 1 Ko RAM > 50 oct. HB Horloge Diviseur 16 bits
Hpriode

Processeur programmable
4 entres logiques

VROTATION

EROTATION 1 sortie logique

2 entres dIT

Monostable triggerable programmable compteur 16 bits 16 bits

-Figure 19.32- Spcification de la structure d'excution. De cette structure d'excution peut se dduire assez simplement une solution matrielle conforme aux spcifications technologiques. 19.9.2. Exemple 2 : automatisation du chariot filoguid Pour cet exemple, toujours par abstraction, on aboutit la structure d'excution suivante qui dcoule de la structure fonctionnelle dtaille reprsente par la figure 19.20 sur laquelle la partie logicielle assure par un processeur programmable est en pointill.
RxD TxD

Processeur programmable 260s Horloge Liaison srie fonctionnement sous IT si possible 3 entres dIT Conversion sous IT C_TAPIS_MARCHE C_TAPIS_SENS C_SIRENE

INC_VM1 INC_VM2

EOC AC1 AC2 CAN 8 bits 2 voies 2 CNA 8 bits CVA1 CVA2

-Figure 19.33- Spcification de la structure d'excution. 424 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION Une liaison srie reprsente ici par les noeuds de communications RxD et TxD est ncessaire. Suivant le microprocesseur retenu, elle est inclue ou elle devra tre rajoute (utilisation dun composant UART). 19.9.3. Couplage entre processeurs Une fois dfinis les processeurs utiliser, il faut dterminer les couplages entre ceux-ci. Ce type de problme existe tout particulirement pour des architectures multi-processeurs. D'aprs le modle d'excution, le couplage entre processeurs se fait par 3 types de relations: par signalisation, par mmoire commune, par noeud de communication. Les relations fonctionnelles peuvent ne pas tre directement supportes par les types de relations d'une structure d'excution. En plus, il peut tre judicieux d'entreprendre des transformations de manire minimiser la complexit matrielle. On indique ci-aprs pour chaque type de relation, les transformations possibles facilitant l'implantation.
-A- CAS DES EVENEMENTS

Considrons le cas dune synchronisation par vnements entre des fonctions implantes sur des processeurs diffrents. Plusieurs solutions sont possibles pour le couplage de ces derniers : - Les vnements peuvent se traduire directement par des signalisations. - Les vnements sont transforms en variables boolennes. Le couplage entre processeurs se fait alors par un signal logique (mmoire 1 bit), (cas 1). - Pour plusieurs vnements exclusifs, ils peuvent tre cods en une information numrique. Une seule signalisation est alors suffisante (cas 2). La fonction G laide de VE assure la synchronisation approprie. - Un ensemble d'vnements peut se traduire par le transfert de messages chacun codant l'vnement gnr. Cette solution est favorable pour la rpartition gographique (cas 3). La figure 19.34 illustre par superposition de la relation fonctionnelle obtenu par la transformation et de la structure dexcution, les trois transformations possibles.
B- CAS DES VARIABLES DETAT

Les variables d'tat devant servir de couplage entre processeurs peuvent s'implanter directement dans une mmoire commune. Le regroupement maximum des variables d'tat est souhait pour rduire le nombre de mmoires communes (cas 1, figure 19.35). Le partage d'une mmoire peut conduire des solutions technologiques complexes. Aussi, est-il peut-tre prfrable de considrer qu'une variable d'tat se trouve implante dans un processeur, gnralement ct utilisation. Il faut alors ajouter ct mise jour, un mcanisme de communication par message utilis lors de chaque modification de la variable. On retrouve ainsi une solution identique celle qui rsulte dune rpartion gographique (cas 2). M.C.S.E 425

Partie 5 - DEFINITION DE LA REALISATION

sur P1 EV1

sur P2

A2 A1
EV2

A3

P1

P2

P1 S

P2

P1

P2

M1

G EV1 A1
M2

A2 A1 A3

A2 A1 A3

EV
M

A2 G

ME

EV2

A3

VE

-Figure 19.34- Transformation d'vnements favorisant l'implantation.

sur P1 V1 sur P2

A2 A1
V2

A3

P1

P2

P1

P2

A2 A1 A1 V A3

V1 A2 G

Mv A3 V2

-Figure 19.35- Transformation pour les variables d'tat. Pour cet exemple, le choix entre lune ou lautre solution se fait en analysant : la taille des variables, la frquence des accs, le cot de chaque solution technologique.
-C- CAS DES PORTS

Le couplage par port s'implante naturellement par un lien de communication. Lorsque la frquence de transfert est trs leve ou que la capacit du port peut se rduire 1, un port peut se traduire par une variable partage et 2 synchronisations. Les 2 426 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION synchronisations se remplacent aussi par une seule variable logique. On retrouve ainsi l'change entre 2 processeurs asynchrones avec synchronisation du type handshake comme lindique la figure ci-aprs.
sur P1 Pt sur P2

A1

A2

P1

P2

P1

P2

Prt Vpt A1 A2 A1

Vpt

A2

Consomm

BF

-Figure 19.36- Transformation pour l'change par port. La solution technologique directe consiste utiliser pour le couplage une mmoire double accs qui se charge aussi de grer les synchronisations. 19.10. DOCUMENTATION ET CARACTERISTIQUES DE LA SOLUTION A lissue de cette tape, le concepteur dispose dun document complet dcrivant la spcification de la ralisation. Il comprend: - la spcification de la ralisation matrielle, sous la forme dune structure dexcution, modle qui laisse tous les degrs de libert aux spcialistes des ralisations matrielles. - la spcification des implantations logicielles pour tous les processeurs programmables. Le schma dimplantation pour le logiciel dcrit lorganisation des constituants sans quil sagisse directement des programmes. Il sert donc avantageusement comme guide pour la programmation. Ce document joue le rle dinterface entre les concepteurs et les ralisateurs. Dduit de la structure fonctionnelle, il rsulte de la prise en compte des spcifications technologiques. Solution obtenue par une suite de transformations, la dmarche suivre est relativement systmatique. La vrification est faite au fur et mesure, mais elle est surtout assure par les ralisateurs ds le dbut de la ralisation car ceux-ci doivent tout dabord comprendre cette spcification utiliser, ce qui conduit naturellement sa vrification. M.C.S.E 427

Partie 5 - DEFINITION DE LA REALISATION En plus des objectifs techniques satisfaire, la solution dveloppe tient compte dobjectifs conomiques, en particulier le cot. La solution est fonction de la quantit de systmes produire. Cela passe, soit par la rduction du cot de dveloppement pour des systmes plutt unitaires, soit par la rduction du cot de reproduction pour des produits de srie. 19.11. RESUME La dmarche pour la dfinition de la ralisation dcrite dans ce chapitre a t illustre par les 2 exemples traits en conception. Les rsultats: structure d'excution, implantation sur chaque processeur, dcoule de transformations appliques sur la structure fonctionnelle. Il s'agit donc d'une dmarche dductive base sur des principes et des rgles. Les points essentiels de la dmarche pour cette tape sont rappels ci-aprs. - La structure d'excution doit tre conforme toutes les spcifications technologiques: rpartition, interfaces avec l'environnement, respect des contraintes de temps. Pour cela, il faut commencer par enrichir la structure fonctionnelle avec tous les lments ncessaires pour satisfaire cette conformit. - La premire phase consiste introduire la rpartition car celle-ci fait ensuite apparatre la ncessit d'interfaces physiques pour tre conforme au support. - Un modle gnrique est propos pour l'introduction des interfaces avec l'environnement. Pour chaque sous-ensemble, la recherche de solution se fait selon la dmarche fonctionnelle dtaille dans la partie 4. - L'introduction des interfaces physiques doit tenir compte de la nature des capteurs et des actionneurs utiliss pour le couplage avec l'environnement. - L'interface homme-machine doit satisfaire au mieux la convivialit souhaite pour l'application. - Des fonctions de test, de maintenance, et des redondances s'ajoutent en final pour rpondre aux spcifications ou pour favoriser la mise au point du produit. - La dduction de la structure d'excution passe par le choix de la rpartition matriel/ logiciel. Ce choix est bas sur l'analyse des temps caractristiques: frquences d'activation et temps d'excution probables, par rapport aux contraintes de temps de l'application. - Le support matriel diffre selon le nombre produire. Pour un nombre faible, il faut rduire le cot de dveloppement en se basant le plus possible sur des sous-ensembles existants. Par contre, pour une production en grande srie, l'objectif est de rduire au maximum la partie matrielle. - Plusieurs techniques sont possibles pour la dtermination de la structure d'excution: utilisation de structures existantes, minimisation de la structure. Les couplages entre processeurs doivent aussi tre simples mais permettre de supporter les relations fonctionnelles. 428 M.C.S.E

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION - L'exprience nous a montr que peu d'applications ncessitent une recherche complexe de la structure d'excution. En effet, il n'existe que peu de contraintes de temps et elles sont trs localises. D'autre part, par introduction de la rpartition gographique le dcoupage en plusieurs processeurs se trouve impos. Ainsi la dmarche propose sert beaucoup plus comme mthode de vrification pour garantir le respect de toutes les contraintes temps-rel. - L'implantation logicielle sur chaque processeur se dduit par transformation de la structure fonctionnelle implanter. Le critre suivre consiste viser une rduction maximale de la partie organisationnelle du logiciel de manire rduire le temps de dveloppement. - Une implantation logicielle peut aussi tre base sur l'emploi d'un excutif temps-rel ou sur des services disponibles sur le processeur. Cette technique rduit le temps de dveloppement, mais ne rduit pas le cot de reproduction ni les performances en excution. - L'implantation de chaque tche complexe doit respecter le modle de dcomposition en modules et l'implantation des donnes doit tre recherche en trouvant le juste compromis entre indpendance et efficacit. - Une structure d'excution est spcifie en final aprs avoir dcid de toutes les implantations logicielles. - Structure d'excution et implantations logicielles doivent tre compltement spcifies dans le document rsultat de l'tape, pour que des quipes de techniciens puissent ensuite entreprendre sans ambigut la ralisation des 2 parties.

M.C.S.E

429

BIBLIOGRAPHIE 5

[CALVEZ-82] Une mthodologie de conception des systmes multi-microordinateurs pour les applications de commande en temps-rel J.P. CALVEZ Thse de Doctorat dEtat, Universit de NANTES, novembre 1982 [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 [KAISER-82] Exclusion mutuelle et ordonnancement par priorit C. KAISER Technique et Science Informatiques No 2 1982 P59-68 [WARD-85] Structured Development for real-time systems P.T. WARD, S.J. MELLOR. Vol 3: Implementation modeling techniques Yourdon Computing series -Yourdon Press- Prentice-Hall 1985

M.C.S.E

431

PARTIE

REALISATION

Etape essentielle car finale, la Ralisation conduit produire le produit ou l'application souhaite conforme aux objectifs du demandeur. Dans le cycle de dveloppement, elle reprsente l'tape la plus importante en cot (temps et ressources). L'objectif est donc de minimiser ce cot. Pour ce faire, les spcifications en entre de l'tape doivent tre particulirement dtailles. MCSE comme mthodologie rpond cet objectif. Dans cette partie, le chapitre 20 prsente la dmarche suivre pour la ralisation, et insiste plus particulirement sur les 2 parties: ralisation matrielle, ralisation logicielle. Il est aussi montr ce que reprsente le raffinement en ralisation ceci pour indiquer qu'une ralisation peut ncessiter nouveau un travail de conception mais dans un domaine plus restreint, et que la dmarche de conception fonctionnelle est nouveau utilisable. Le chapitre 21 dtaille les techniques pour la ralisation matrielle, la fois la technique conventionnelle des circuits catalogue et le dveloppement de composants spcifiques. Comme pour la conception fonctionnelle, des modles gnriques appropris pour la conception de fonctions matrielles sont prsents ainsi que les dmarches associes. Le chapitre 22 ddi aux techniques pour la ralisation logicielle permet de prendre connaissance des techniques et mthodes du Gnie Logiciel. Ce chapitre insiste tout particulirement sur la ncessit de la rutilisation mme en Informatique Industrielle, qui passe par l'emploi du concept OBJET et des langages temps-rel supportant ce concept. M.C.S.E 433

Chapitre 20

DEMARCHE POUR LA REALISATION

A l'issue des 3 tapes dcrites dans les parties prcdentes, l'application de la mthodologie MCSE conduit l'obtention d'un document complet de la solution. La ralisation d'un prototype ou d'une srie dcoule de ce document. La ralisation de systmes base d'Electronique et d'Informatique est compose de 2 parties: une partie MATERIELLE, une partie LOGICIELLE. Le produit ou l'application n'est oprationnel que par une association correcte des 2 parties. Cette association rsulte d'un travail d'intgration et de test du logiciel sur le matriel. L'tape de ralisation est importante en cot (temps, ressources) car elle dpasse presque toujours l'ensemble des 3 tapes prcdentes. L'objectif de MCSE est dinduire une rduction substantielle de ce cot. En plus de disposer de spcifications de ralisation compltes, l'quipe de ralisation doit respecter des rgles, utiliser des techniques et des outils qui conduisent efficacement une ralisation oprationnelle. L'objectif de ce chapitre est de dcrire l'organisation des tches, la dmarche suivre, et les rgles et outils pour l'implantation. 20.1. OBJECTIF DE LA REALISATION Avant d'entamer la description de chacune des phases, il est souhaitable de rappeler le rle essentiel de cette tape de ralisation, la dernire qui finalise le produit. Il faut aussi tre sensible 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.

M.C.S.E

435

Partie 6 - REALISATION 20.1.1. Caractrisation de l'tape de Ralisation Tout d'abord, donnons une dfinition gnrale: Raliser c'est produire l'objet souhait dcrit par un ensemble de caractristiques. Un objet ralis (ou une ralisation) est donc un objet rel matrialis. Les caractristiques dcrivant l'objet reprsentent par contre un modle abstrait de l'objet rel. Dans la terminologie de la Mthodologie MCSE, cette modlisation est une spcification de l'objet. Ainsi, raliser c'est donc transformer une spcification de ralisation en un objet rel. L'objet matrialis doit tre oprationnel, ceci veut dire qu'il rpond tous les souhaits et contraintes exprims par le demandeur. Cette tape est donc essentielle pour la russite du dveloppement car elle finalise le projet, tout en tant totalement dpendante des tapes prcdentes car la dernire. La figure suivante situe ltape de ralisation dans l'ensemble du dveloppement d'un produit.
VALIDATION

Vrification en conception

Vrification en ralisation

Cahier des charges

MCSE
Spcification de la ralisation

REALISATION

Objet rel ou produit

Techniques de ralisation

-Figure 20.1- Caractrisation de l'tape de ralisation. Les 3 tapes dj dcrites de la mthodologie MCSE conduisent dvelopper partir du cahier des charges une spcification de ralisation la plus complte possible. Cette spcification a t vrifie par rapport l'objectif atteindre. Toutefois, il faut admettre que des erreurs peuvent subsister. Le travail de ralisation ne pouvant pas tre compltement automatique, la solution n'tant pas non plus unique, des erreurs peuvent aussi s'introduire durant la ralisation. Une vrification s'avre donc ncessaire pour garantir que l'objet rel est conforme la spcification. Comme la spcification en entre de l'tape est probablement elle-mme entache de quelques erreurs, une vrification globale des caractristiques de l'objet final ou du produit par rapport au cahier des charges est ensuite indispensable. Une telle vrification conduit la validation du produit puis sa certification. 436 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION Ainsi l'tape de ralisation sintgre dans le cycle complet de dveloppement. Ce cycle gnralement prsent selon un schma en V a dj t prsent sous la forme dun double triangle (voir figure 5.6). Les 3 premires tapes de la mthodologie MCSE correspondent une dmarche descendante qui, par enrichissements successifs selon le modle 3 dimensions, conduit une description de plus en plus dtaille de l'application. La ralisation a pour objectif de dvelopper progressivement partie par partie la solution en faisant apparatre des fonctionnalits de plus en plus abstraites. La dmarche de construction est donc une dmarche ascendante. A chaque niveau valid de la construction correspond un niveau de description de la solution. Les vrifications et les validations servent assurer l'adquation de la ralisation sa spcification. 20.1.2. Varit des mthodes et moyens en ralisation Raliser c'est aussi mettre en oeuvre des techniques de ralisation. A chaque technique sont associs une ou des mthodes et des outils de transformation ou d'aide la transformation [AMGHAR-89]. L'efficacit en ralisation dpend de plusieurs facteurs importants: - la nature de la spcification, - la technique mise en oeuvre, - les outils et mthodes disponibles pour les transformations. L'idal serait de disposer d'un outil de production automatique, et bien entendu gnrant sans erreur tout produit de la classse des systmes lectroniques, en mettant en oeuvre une grande varit de techniques de ralisation, et ceci en plus, partir de spcifications particulirement abstraites de manire rduire en amont le travail partir du cahier des charges. Il est toujours plaisant de rver, nous sommes encore trs loin de cet idal. Spcifieurs et concepteurs trouveront toujours durant les prochaines dcennies matire dveloppement pour tenter de rpondre cette problmatique. Pour illustrer l'objectif de l'tape et la varit des techniques et des outils, prenons 2 exemples chacun correspondant une classe de techniques, l'un concernant le matriel et l'autre concernant le logiciel.
-A- EXEMPLE DE REALISATION MATERIELLE

Le premier exemple concerne un automatisme squentiel de contrle-commande raliser par une carte lectronique (solution matrielle seule). - nature de la spcification tout d'abord? Plusieurs modles sont tout fait possibles: grafcet, diagramme tats finis, chronogrammes, tables de transition... La nature dpend du travail fait en amont par le concepteur. - technique ou technologie mise en oeuvre? Une grande varit possible, entre autres: carte imprime avec des composants logiques type TTL, des composants plus complexes, rseaux logiques programmables, circuit intgr spcifique, automate programmable ... Le choix dpend de critres et contraintes techniques, industrielles, conomiques. M.C.S.E 437

Partie 6 - REALISATION - Mthodes et outils? Aussi une grande varit, chaque outil tant appropri pour une classe de spcifications et une classe de techniques de ralisation. Pour le dernier point, considrons 2 cas un peu extrmes pour bien montrer le rle de l'tape et la diversit de la nature du travail. Pour le premier cas, la spcification est exprime par des chronogrammes, la technique mettre en oeuvre est une technologie conventionnelle du type TTL SSI. Une analyse des chronogrammes va permettre de construire une solution en termes de fonctions logiques, ce qui conduit au schma. Le circuit imprim peut rsulter du schma et des modles gomtriques des composants l'aide d'un outil de placement-routage pour circuits imprims. Les documents produits par l'outil servent alors raliser le support. Sur ce support sont monts les composants. Le travail fait par l'homme est important: analyse et production du schma, saisie du schma, placement et routage d'autant plus complexe qu'il est fait en manuel, ralisation du support et assemblage, vrification l'issue de chaque phase, correction des erreurs. Les erreurs de ralisation peuvent tre importantes: ds l'entre, mauvaise spcification, analyse trop sommaire ce qui conduit un schma erron, erreur de routage, erreur de fabrication et d'assemblage, erreur de vrification. Pour le deuxime cas, la spcification est un grafcet ou un diagramme tats finis. La technologie retenue et utilisable est un seul rseau logique programmable. La spcification est fournie directement ou aprs quelques adaptations syntaxiques un outil de programmation de rseaux logiques. La spcification est traduite automatiquement en donnes compatibles avec un programmateur du rseau logique choisi. Le travail faire concerne la slection du composant, et la saisie de la spcification si celleci n'est pas directement exploitable en rsultat de la conception. La ralisation est ensuite automatique puisque l'objet une fois programm et retir du programmateur rpond aux spcifications. La ralisation peut quand mme ne pas tre correcte: mauvaise spcification mais ceci est une erreur de conception ou de mauvaise saisie. Les risques d'erreurs sont dans ce cas nettement moindres. Au travers de cet exemple, faut-il conclure qu'il ne faut utiliser que les techniques et procdures qui conduisent une ralisation automatique? Non, pas obligatoirement, l'exemple montre simplement quavec des moyens automatiques les erreurs sont rduites, et donc que le temps et le cot de ralisation sont rduits. Mais le cot conomique n'est pas forcment rduit. Premier point, les outils peuvent tre coteux. Deuxime point, pour une production de grande srie, la technologie traditionnelle peut encore s'avrer moins coteuse.
-B- EXEMPLE DE REALISATION LOGICIELLE

Le deuxime exemple concerne un progiciel simple sur microordinateur. Pour ce problme, commenons aussi par une analyse des 3 facteurs: - nature de la spcification? Plusieurs niveaux de spcification sont tout fait possibles: du simple cahier des charges (extrme qui n'est pas une spcification), diagramme flots de donnes, structure de modules, description en langage structur (PDL), description en langage structur de programmation. 438 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION - technologie mise en oeuvre? Mme si on a tendance penser qu'un microordinateur est automatiquement un compatible PC, la nature du support est variable: plusieurs types de processeurs, d'cran, de disque, d'imprimante, de systmes d'exploitation. - Mthodes et outils? Aussi une grande varit, fonction de la spcification et de la technologie. Intressons-nous nouveau au dernier point en considrant 2 cas assez extrmes. Premier cas: en entre, une ide du progiciel souhait. Comme technologie une carte microprocesseur complte par les priphriques ncessaires. Seul logiciel de dveloppement disponible: un traducteur symbolique dit aussi programme Assembleur et un moniteur de mise au point. Le travail faire est considrable: toute l'analyse du problme, l'criture dpendante du processeur, l'implantation, et srement un travail important et fastidieux de mise au point et de correction des erreurs d'analyse. La possibilit d'erreurs est permanente et le produit obtenu au bout d'efforts considrables est sans intrt, car pas lisible donc peu maintenable, et pas transportable sur une autre technologie. Deuxime cas: en entre, une spcification par une description algorithmique complte dans un langage de programmation du type PASCAL, la technologie est un microordinateur type PC. L'outil de dveloppement est l'environnement et le compilateur Turbo-Pascal. Le travail faire est trs faible, d'autant plus faible que la validation de la conception a pu se faire en Turbo-Pascal. Les seules erreurs ne peuvent venir que de la spcification, de l'adaptation matrielle, de la configuration, exceptionnellement du compilateur. Pour ce deuxime cas, on voit bien que raliser c'est obtenir le produit oprationnel, c'est-dire ici le progiciel fonctionnant sur le microordinateur, partir d'une spcification qui est une description syntaxique. La ralisation est faite par la chane de traduction automatique qu'est l'ensemble compilateur-diteur de lien-chargeur. 20.1.3. Importance en dure de l'tape de Ralisation Etant donn un produit obtenir, la dure de l'tape et le cot en ressources humaines dpendent directement: - de la nature de la spcification en entre, - des techniques et outils mis en oeuvre. On se place ici dans le cas o les spcifications rsultent de l'utilisation de la mthodologie MCSE. Il s'agit donc d'un document complet de dfinition de la ralisation, et des spcifications technologiques propres la ralisation. Les techniques mettre en oeuvre concernent les 2 domaines: le matriel, le logiciel. Pour se faire une ide des dures, considrons une application industrielle de dimension moyenne. La dure du dveloppement est de l'ordre de l'anne avec un cot de l'ordre de 2 hommes/anne. L'tape de ralisation correspond approximativement une dure comprise entre 60 et 80% de la dure totale, et consomme entre 1,2 1,6 hommes/anne. La part du logiciel dans ces temps reprsente aussi en moyenne entre 70% 90%. M.C.S.E 439

Partie 6 - REALISATION Ceci montre d'une part l'importance de l'tape de ralisation sur le cot global, d'autre part l'importance des tapes prcdentes pour rduire ce cot relatif. L'organisation des quipes et la dmarche de travail sont grer pour amliorer la productivit et par voie de consquence la rentabilit des entreprises du domaine. 20.2. DEMARCHE POUR LA REALISATION Comme les 3 facteurs importants pour la ralisation sont: les spcifications, les techniques ou technologies mettre en oeuvre, les mthodes et outils - une dmarche doit proposer un schma de travail qui permette d'optimiser globalement le cot et la qualit du rsultat. Il n'est pas utile ici de revenir sur les spcifications car elles dcoulent de l'utilisation de MCSE et ainsi sont produites de manire structure pour tre exploites efficacement durant la ralisation. La dmarche propose rpond donc aux points: techniques, mthodes et outils. Comme spcification en entre de l'tape, le document de dfinition de la ralisation est compos: - de la spcification de la structure d'excution, - de l'allocation de la solution fonctionnelle sur la structure d'excution, - des spcifications pour les implantations logicielles. S'ajoutent ce document, une partie des spcifications technologiques, qui n'a pas t prise en compte durant l'tape de conception dtaille. Il s'agit plus particulirement des spcifications techniques pour la ralisation: types de composants, normes respecter, mthode de ralisation..., et les contraintes d'environnement: parasitage, environnement hostile, gamme de temprature... L'tape de ralisation prsente sur la figure 20.2 est dcompose en 4 grandes parties avec un enchainement selon 3 phases. La dmarche est un enchanement de 3 phases: 1- vrification et acceptation des spcifications, 2- ralisations, 3- intgration, tests, validation. Cette figure montre le dveloppement simultan des 2 parties: matriel et logiciel. Possible du fait des 2 catgories de spcifications, une telle organisation du travail est fortement conseille pour: - rduire le temps de la ralisation, - pour faire intervenir conjointement des spcialistes des 2 domaines. En effet, pour les projets assez complexes, le travail valu en hommes/mois est si important au point que plusieurs quipes doivent collaborer pour aboutir au rsultat dans les temps impartis. Se pose alors le problme de la structuration des quipes, celui du partage, de la rpartition et de l'ordonnancement des tches. Le document qui rsulte de la conception, du fait de sa structuration en sous-ensembles spcifis, favorise ce type d'organisation du travail en quipes. Le dialogue entre les quipes et tout particulirement entre les 2 types de spcialistes est une condition ncessaire de russite pour viter des problmes dincohrence qui ne se dtecteront alors que durant la phase d'intgration et de test. Les paragraphes suivants dtaillent chacune des 4 parties. 440 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION

Spcifications de ralisation

Structure dxcution

Allocation

Implantation logicielle

VERIFICATION DES SPECIFICATIONS

Schma de Outils Instrumentation Implantation et ralisation Test composants et cartes Ralisation matrielle ralisation Dialogue

Ecriture: tches modules procdures Compilation chargement Test du logiciel Ralisation logicielle

Outils Systme de dveloppement

INTEGRATION et TESTS

produit oprationnel

-Figure 20.2- Dmarche pour l'tape de ralisation. 20.3. VERIFICATION ET ACCEPTATION DES SPECIFICATIONS Cette premire phase a pour objectif de prendre connaissance du problme et de la solution dveloppe en conception. Cette phase n'a d'utilit que lorsque l'quipe de ralisation est diffrente de celle de conception. Elle sert alors de couplage entre les 2 quipes. Le paragraphe OBJECTIFS (20.1) a mis en vidence l'importance d'une bonne spcification dans le sens o elle se veut conforme aux souhaits du demandeur. Toute erreur dans la spcification qui ne sera dtecte que plus tard pendant la ralisation, va introduire un surcrot de travail en mettant en cause les tapes prcdentes de conception. L'objectif de cette phase est donc d'liminer au maximum de telles erreurs dans la spcification de ralisation, d'assurer une bonne comprhension de cette spcification si ncessaire par dialogue avec les concepteurs, d'tablir le dialogue entre les catgories de spcialistes du matriel et du logiciel. Pour assurer le plus simplement le couplage avec la conception, la mthode consiste tablir un recouvrement de personnes entre les 2 parties. Pour cela, un concepteur au moins doit poursuivre en ralisation, ne serait-ce que pour assumer la responsabilit et le suivi du projet. M.C.S.E 441

Partie 6 - REALISATION D'autre part, des ralisateurs, particulirement les responsables de groupes, doivent s'impliquer comme lecteurs des documents de conception et ceci ds le dbut du projet. La comprhension et la vrification des spcifications ncessitent de la part des ralisateurs de connatre les modles de description utilises dans MCSE. Ainsi, les intervenants se trouvent tenus informs sur l'tat du projet et sur les solutions envisages. Ils participent aussi directement la vrification et l'limination des erreurs. De plus ils engagent de cette manire leurs responsabilits. 20.4. REALISATION MATERIELLE La solution matrielle se dduit de la structure d'excution. Suivant le critre de dveloppement du support excutif, le travail de ralisation diffre. Dans le cas d'une construction modulaire sur la base de cartes existantes, le dveloppement consiste en l'assemblage de ces cartes compltes par la ralisation d'interfaces particulires. Lorsqu'il s'agit de minimiser le cot de reproduction du matriel, il faut rechercher tous les lments. Le choix des constituants de base: processeurs utiliser, mmoires, composants priphriques, circuits personnaliss ... doit se faire sur la base du cot, tout en s'assurant que la solution rsultante respectera toutes les contraintes technologiques. Toute ralisation matrielle ncessite une comptence technique et technologique pousse. Du fait de l'volution rapide de la technologie, cette comptence doit s'entretenir par une attitude volontariste : lecture de revues, suivi de stages... 20.4.1. Dmarche La dmarche pour la ralisation matrielle ncessite 3 phases: - laboration du schma de la ralisation, - implantation et ralisation des constituants: circuit imprim, composant spcifique, ... - test de la ralisation matrielle. Cette dmarche est valable aussi bien pour l'ensemble de la ralisation que pour chaque sous-ensemble ou composant. La ralisation des constituants et leur assemblage doivent conduire le plus rapidement possible une version industrialisable. De plus, cette phase pouvant tre coteuse (en temps et argent), elle doit se russir en une seule fois. L'objectif qualit "ZERO ERREUR" est possible pour le matriel. Les composants microprocesseurs et les composants VLSI se prtent l'obtention d'un tel rsultat condition de matriser cette technologie, d'avoir une certaine exprience et de faire l'effort d'entretenir ses connaissances. Lorsque des parties plus dlicates sont dvelopper: analogique par exemple, il est souhaitable de raliser une maquette du sousensemble pour se garantir de la validit du schma de la ralisation. La troisime phase, celle du test est essentielle. Chaque composant, sous-ensemble puis ensemble, doit tre test indpendamment de l'application selon une dmarche d'intgration ascendante. Le test pour des cartes comportant des processeurs programmables conduit au dveloppement de programmes de tests utilisables par la suite pour la vrification en auto-test ou durant la phase de production. Certains tests ncessitent des extensions de la solution; ce travail est de la responsabilit des ralisateurs car il s'agit de satisfaire des contraintes indiques dans les spcifications technologiques. 442 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION 20.4.2. Les outils La ralisation matrielle ncessite la mise en oeuvre d'outils comme support d'aide au dveloppement: - des outils de CAO en lectronique: utilisables pour la saisie de schmas, la simulation si ncessaire pour toute vrification, l'implantation sur circuit imprim ou la ralisation de composants intgrs du type ASIC: rseau prdiffus, rseau logique programmable, circuit spcifique. - une instrumentation pour le test et la mise au point. Il s'agit d'appareils d'analyse et de test que sont: oscilloscope, analyseur logique, analyseur de protocole, mulateurs ... 20.4.3. Rgles respecter Pour tre conforme aux spcifications de la structure d'excution, la solution matrielle dvelopper doit respecter des rgles de ralisation nonces pour le modle d'excution. Rappelons les points essentiels: Chaque processeur a sa propre autonomie, il dcide donc de son activit tout instant. Compte-tenu de cette spcification, la ralisation doit tre telle que: - toutes les signalisations seront prises en compte. - des protections existent contre les conflits d'accs simultans aux mmoires. C'est le cas de la mmoire commune dans une architecture multi-processeurs, pour laquelle le conflit possible ncessite la mise en oeuvre, soit d'un arbitre pour l'attribution du bus, soit d'une mmoire multi-ports. - des protections existent contre les accs simultans une mme entre d'un noeud de communication. C'est le cas du couplage par bus pour lequel une politique de partage du bus est mettre en oeuvre. 20.5. REALISATION LOGICIELLE Le dveloppement du LOGICIEL consiste implanter la description fonctionnelle sur la ralisation matrielle compte-tenu des spcifications de l'implantation logicielle. Durant cette phase le schma d'implantation dfini l'tape prcdente ne doit pas tre dforme. Le travail effectuer est fonction de la nature des spcifications et des contraintes d'implantation satisfaire. 20.5.1. Dmarche Pour la ralisation logicielle, la dmarche gnrale est compose de 3 phases: - Ecriture des procdures, modules, tches en langage de programmation, - Traduction des programmes en code excutable, - Test et mise au point. Lorsque la spcification est une description algorithmique en langage de haut-niveau, l'implantation peut rsulter d'une traduction automatique par simple compilation. La traduction peut aussi se faire en manuel lorsque la programmation exige une criture en langage d'assemblage. Cette faon de faire doit tre vite au maximum car elle est coteuse en temps. Elle conduit aussi une probabilit d'erreurs nettement plus importante, une lisibilit M.C.S.E 443

Partie 6 - REALISATION particulirement faible lorsqu'il s'agit, en maintenance, de corriger ou de faire voluer la solution. Toutefois, une traduction automatique peut conduire des non-satisfactions de contraintes de temps. Dans ces cas prcis, il est souhaitable: soit de passer une traduction manuelle pour optimiser les temps d'excution, soit de revenir sur les spcifications pour modifier la solution. Comme pour la ralisation matrielle, le logiciel doit subir des tests exhaustifs pour rduire au maximum le nombre des erreurs. La vrification concerne: le respect des comportements exigs par les spcifications, le respect des contraintes de temps, le respect des rgles de qualit. Comme tout systme temps-rel possde des entres et des sorties physiques, la procdure de test du logiciel n'est pas simple sans son environnement. Les entres et sorties de l'application n'tant pas obligatoirement disponibles, la structuration du logiciel doit toutefois conduire la plus grande couverture de test possible sans cet environnement. 20.5.2. Les outils La ralisation logicielle se fait en parallle avec la ralisation matrielle. Aussi faut-il considrer que, dans la plupart des cas, le support matriel n'est pas disponible pour le dveloppement et le test du logiciel. Les outils minimums mettre en oeuvre sont: - un outil d'dition des programmes, - un ou des traducteurs-chargeurs produisant du code compatible avec les microprocesseurs retenus pour l'application, - des outils de test et de mise au point. Ces outils sont disponibles sur informatique ou microinformatique. Pour les applications temps-rel base de microprocesseurs, ce type de support est qualifi de systme de dveloppement. Les outils utiliser doivent tre compatibles avec ceux utiliss ensuite pour la phase d'intgration. Complment indispensable, les spcialistes en dveloppement du logiciel doivent matriser les mthodes et techniques dcriture et les outils associs. S'ajoute ces outils, si possible pour des projets assez consquents, un outil de suivi de projet et de gestion de versions. 20.5.3. Rgles respecter L'implantation logicielle doit aussi respecter les rgles de comportement donnes pour le modle fonctionnel et le modle d'implantation. Ces rgles concernent particulirement la gestion des variables partages et la gestion des ports.
-A- COHERENCE DES VARIABLES PARTAGEES

Une variable partage joue le rle d'une ressource pour les tches. Pour respecter les contraintes d'intgrit de cette ressource, il faut dfinir une technique d'ACCES EXCLUSIF, ou dans certains cas un ACCES PARTAGE. La technique mettre en oeuvre diffre suivant la taille et la nature de la variable, et parfois suivant la nature de l'application. 444 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION

-B- ACCES AUX VARIABLES SIMPLES

Une variable simple est caractrise par le fait que le temps de lecture ou de modification de cette variable est trs faible par rapport la dure de la tche qui l'exploite. L'exclusion se rgle alors trs simplement en augmentant ponctuellement la priorit de la tche durant l'accs. Ceci se fait par exemple par invalidation du systme dinterruptions. Pour des variables de taille plus importante, et lorsque le changement de priorit peut impliquer le non-respect des contraintes de temps, l'exclusion peut se faire avec la technique des smaphores gres par un excutif temps-rel.
-C- ACCES A DES VARIABLES COMPLEXES

Une variable est considre complexe lorsqu'elle contient une quantit importante d'informations. Il s'agit par exemple de fichiers, de bases de donnes centralises ou mme rparties. L'accs doit tre tel que les temps correspondants respectent les spcifications et donc, en particulier, qu'il n'existe pas d'interblocage, ni de privation. Pour respecter les contraintes de temps, le paralllisme des accs est parfois ncessaire. Pour une variable compose d'objets disjoints, l'accs simultan ces objets n'introduit pas d'interblocage. Une variable complexe peut se structurer en niveaux d'informations. Chaque niveau est une collection d'objets. Chaque objet de niveau i est dfini comme une collection de niveau i-1. Pour accder un objet de niveau i, il suffit d'assurer l'exclusion d'accs cet objet, ce qui exclut l'utilisation de tous les objets le composant et ceci jusqu'au niveau le plus lmentaire. Par contre, des accs simultans restent possibles pour des objets de niveau i et plus. Dans tous les cas, l'algorithme de rsolution des conflits doit assurer l'absence de privation.
-D- GESTION DES PORTS

Un port accumule les messages qui lui sont transmis. En sens inverse, il fournit un message chaque sollicitation d'un demandeur. Dans le cas le plus gnral, pour un mme port, plusieurs tches peuvent produire des messages et plusieurs consommateurs sollicitent des messages. Pour l'implantation, la taille du port en nombre de messages est obligatoirement limite. La ralisation logicielle doit faire en sorte que: - la file des messages reste cohrente tout instant, - l'change se ralise compte-tenu du nombre de messages dans le port: blocage des producteurs si le port est plein, blocage des consommateurs en l'absence de messages. La technique consiste considrer qu'un port est une variable partage. Le respect de la cohrence de la file s'obtient par les techniques d'exclusion d'accs. Ainsi un port s'implante sur la base des 2 mcanismes: synchronisation et exclusion mutuelle.
-E- PRISE EN COMPTE DES EVENEMENTS ET DES MESSAGES

L'implantation doit aussi tre conforme aux rgles de comportement dfinies pour les instructions CYCLE et WHEN. Pour l'instruction CYCLE, tous les vnements et messages reus doivent tre traits, ce qui implique une mmorisation. Les squences associes chaque cas doivent tre excutes en exclusion mutuelle. M.C.S.E 445

Partie 6 - REALISATION Pour l'instruction WHEN, plusieurs vnements ou messages peuvent tre attendus. Un seul est prendre en considration, le premier arriv. Les autres, s'ils arrivent par la suite, doivent tre limins. 20.5.4. Traitement des erreurs En logiciel, le traitement des erreurs introduit une complexit supplmentaire pour la ralisation. Un programmeur a tendance naturellement dvelopper une solution satisfaisante pour les cas normaux. S'ajoutent ensuite tous les traitements correspondant aux effets dits de "bords" et aux erreurs lies l'environnement. Comme illustration, lorsqu'une application ncessite un service de communication, une erreur peut apparatre au niveau le plus bas du support physique: erreur de transmission, par exemple. L'erreur dtecte est remonte de niveau en niveau. Un niveau donn peut corriger l'erreur. Si ceci n'est pas possible, l'erreur invitablement remonte au niveau de l'application et doit tre traite. Certains traitements d'erreurs sont rsoudre par les concepteurs, d'autres d'ordre plus technologique sont assurer par les ralisateurs. Les erreurs lies l'environnement sont lies aux entres du systme et donc dtectables ce niveau. Selon JACKSON, les entres peuvent se classer en plusieurs catgories [JACKSON83]: - les entres valides ou invalides. Une entre est valide si elle est conforme aux spcifications. - les entres vraies ou fausses. Ces 2 types font partie des entres valides. Une entre est vraie si elle est conforme avec l'tat suppos de l'entit qui gnre cette variable, compte-tenu de l'action entreprise. - les entres dsires ou non attendues. Ces entres font partie des entres vraies. Mais une entre peut ne pas tre attendue et donc doit tre limine. Le traitement des erreurs en rapport avec les entres ncessite donc de placer une couche logicielle d'interprtation pour dabord dtecter la nature de l'erreur puis pour entreprendre l'action associe. Les entres invalides et non attendues doivent tre signales et limines. La conception tient compte de ces cas si elle est base au dpart sur une modlisation du comportement des entits. Les entres fausses correspondent des erreurs de comportement soit de l'entit gnratrice de l'information en entre, soit de l'interface (capteur). Toutes ces erreurs ne sont pas toujours des plus simples dtecter. De plus, le traitement entreprendre peut conduire des implantations complexes car l'application ne doit jamais aboutir dans un tat non-scuritaire. 20.6. INTEGRATION ET TEST Cette dernire phase a pour objectif de runir toutes les parties des dveloppements de manire aboutir un systme oprationnel conforme aux souhaits du demandeur. Il s'agit donc de faire fonctionner le logiciel dj dvelopp et fortement test sur le matriel lui-mme entirement test. L'intgration implique donc la cohrence de tous les dveloppements. 446 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION La vrification puis la validation de l'application se font d'une manire incrmentale selon une procdure ascendante : - test des modules, - test de sous-ensembles, - test de l'ensemble et validation, - certification et recette de l'ensemble. Une validation implique obligatoirement la disponibilit de l'environnement: machine, procds... Or certains procds sont, soit non-disponibles, soit impossibles placer dans des conditions de test car trop dangereux. D'autres moyens sont alors mettre en oeuvre telle que la ralisation d'une simulation. Si la spcification, la conception, la dfinition de la ralisation, les ralisations matrielles et logicielles ont t faites avec srieux, les erreurs dtectes ce stade seront mineures et faciles corriger. Pour des erreurs plus importantes, des retours arrire plus importants peuvent tre jugs ncessaires. L'intgration et le test ncessitent l'emploi des outils utiliss pour les ralisations matrielle et logicielle. Systmes de dveloppement et instrumentation sont associs pour le test d'ensemble. Bien videmment, les 2 catgories de ralisateurs se retrouvent pour assurer cette intgration et le test d'ensemble. Les erreurs peuvent tre dues l'une ou l'autre des parties, peut-tre aussi un point particulier qui concerne les 2 parties. Cohrence de mthode et entente sont donc des conditions de meilleure russite. 20.7. LES SOURCES DERREURS La dmarche propose pour la conception est une dmarche progressive descendante. Au stade de la ralisation se dtectent en final toutes les erreurs rsiduelles et qui doivent invitablement tre corriges. Le cot de correction des erreurs est une fonction approximativment exponentielle de l'cart entre l'instant de gnration de l'erreur et l'instant de dtection. Ainsi, les erreurs et oublis durant la ralisation restent les plus simples corriger, car ne remettant pas en cause les tapes prcdentes. Mais si la technologie de ralisation est coteuse, les consquences peuvent tre importantes: cas d'un circuit intgr ASIC non oprationnel ou d'une carte refaire. Ainsi, gnralement les erreurs de logiciel apparaissent moins coteuses que les erreurs matrielles. Toutefois, la multiplicit des erreurs et des corrections incrmentales possibles en logiciel peuvent conduire un cot trs important difficilement observable, tout aussi difficilement imputable aux ralisateurs qui naturellement reporteront la cause sur les concepteurs. Si l'avancement du matriel est facilement observable, ce n'est pas le cas pour le logiciel. Le logiciel est assimilable un iceberg. La partie visible est contrlable, la partie immerge reprsentant la plus grande partie de la ralisation, est difficile estimer et contrler pour en dduire le stade d'avancement. Les erreurs de conception peuvent conduire une remise en cause de la solution matrielle. De telles erreurs sont pnalisantes, en particulier, une attention spcifique doit tre porte pour les applications contraintes de temps trs svres. Elles conduisent en effet la mise en oeuvre d'une solution matrielle complexe et donc coteuse. Les erreurs de spcification sont aussi particulirement coteuses car elles remettent en cause le produit dvelopp. M.C.S.E 447

Partie 6 - REALISATION Ainsi, le travail avec rigueur est pour cela indispensable de manire rduire toutes les sources d'erreurs. Des vrifications srieuses et approfondies sont entreprendre l'issue de chaque tape et si possible par des personnes diffrentes des concepteurs eux-mmes (cycle auteur-lecteurs). Ces vrifications ne sont possibles que sur la base de documents labors durant chaque tape. On retrouve ainsi lapport dune mthodologie bien suivie. 20.8. RAFFINEMENT EN REALISATION Pour chacun d'entre nous, les termes n'ont pas toujours la mme signification, comme par exemple l'ambiguit entre cahier des charges et spcification. De mme, le terme ralisation est compris comme de la conception pour d'autres. A travers la description de la mthode, nous avons tent de donner une signification claire et unique des termes employs. Il reste toutefois que l'tape de ralisation considre en entre des spcifications. On peut donc se dire que pour passer des spcifications un produit lorsque la transformation n'est pas directe, il faut passer par une tape de conception. Le travail de conception consiste alors trouver des fonctions internes strictement ncessaires pour obtenir la ralisation. Chaque fonction plus lmentaire s'exprime alors par une spcification de ralisation. Il n'y a donc pas de contradiction entre ralisation et conception puisque le premier peut inclure le deuxime. Selon cette analyse, le travail de ralisation peut se raffiner en 3 phases reprsentes par la figure ci-aprs: - une phase de conception de la ralisation, - une phase de ralisation des parties, - une phase d'assemblage, intgration et test.
Spcification Spcification

CONCEPTION Spc. 1 Spc. 2

spc

Spc. 3
CONCEPTION
spc

REALISATION

Composant existant

Composant existant

Comp

Comp

INTEGRATION

C1

C2 INTEGRATION

C3

Produit

Produit

-Figure 20.3- Raffinement du travail de ralisation. Ainsi, chaque niveau conduit une restriction du domaine technique concern par la ralisation, tout en ncessitant: spcification, conception, ralisation. Selon cette prsentation, explicitons un peu plus les activits pour les 2 types de ralisation: matriel, logiciel. 448 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION 20.8.1. Raffinement en ralisation matrielle Pour le niveau de la ralisation matrielle, la spcification est celle de la structure d'excution. La ralisation de cette partie commence par un travail de conception pour obtenir le schma d'assemblage et la spcification de chaque constituant. Elle est suivie d'une phase de ralisation de chaque lment, puis de la phase d'assemblage et de test. Pour tous les lments existants, le travail de ralisation est achev. Le raffinement doit se poursuivre pour tous les autres. Pour illustrer cette dmarche pour la ralisation matrielle, considrons 2 exemples. Tout d'abord, supposons le cas d'une carte microordinateur avec des fonctions de traitement du signal en temps-rel. La structure d'excution comprend un processeur programmable du type 16 bits 68000, et un processeur spcialis de filtrage numrique du 4ime ordre 64 KHz en 16 bits. Selon la dmarche ci-dessus, il faut se poser la question de l'existence ou non d'un tel processeur spcialis, et si oui, rpond-t-il aux critres conomiques? Supposons que la rponse est non, il faut alors rechercher une solution par dcomposition de la fonction. La mthode MCSE est alors utilisable pour la conception fonctionnelle, cette fois un niveau technologique et pour une classe de problme trs spcifique: celui des filtres numriques. Les quations rcurrentes calculer permettent de dduire le comportement algorithmique pour le filtre. Une structure fonctionnelle se dduit d'un modle gnrique appropri pour cette classe de problme: par exemple, le modle partie oprative/partie commande dcrit dans le chapitre suivant. Les 2 parties doivent ensuite tre ralises, assembles et l'ensemble doit tre test. La ralisation ce stade peut se faire selon diverses technologies: composants discrets, MSI, composants spcialiss du type microprocesseur en tranches, rseaux logiques programmables, composant spcifique (ASIC)... Pour le cas d'un ASIC, en exploitant un compilateur de silicium, le raffinement de la ralisation doit tre poursuivi jusqu' pouvoir utiliser directement un assemblage de blocs paramtrables tels que: PLA, registres, additionneurs... Comme deuxime cas, une structure d'excution contient un processeur spcialis appel onduleur ayant pour objectif de fournir une tension alternative sinusodale 220 V 50 Hz partir d'un ensemble de batteries fournissant 48 V. La puissance disponible doit tre de 5 KW. La ralisation de cette fonction ncessite de dcomposer le problme en 2 classes de problmes: un problme d'lectronique de puissance pour la structure de puissance, un problme d'informatique industrielle pour l'lectronique de commande de la partie puissance. La caractrisation de la partie puissance en se basant sur les solutions possibles conduit spcifier la partie commande. La commande est ensuite concevoir par une approche fonctionnelle. 20.8.2. Raffinement en ralisation logicielle Pour le niveau de la ralisation logicielle, la spcification comprend le schma de l'implantation logicielle et les spcifications des tches et des modules. Le travail de ralisation de chaque constituant est fonction de la nature de la spcification et du support utilis. Illustrons aussi ce domaine de ralisation par 2 exemples. M.C.S.E 449

Partie 6 - REALISATION Pour le premier cas, la ralisation est faire en PASCAL. Toutes les tches temps-rel sont dfinies par un algorithme dcrit en PASCAL et valid. La ralisation qui en dcoule est automatique par traduction. S'ajoute une tche de gestion du dialogue pour l'application. Celleci est spcifie par une structure de modules. Le travail de conception consiste en l'utilisation de la mthode: programmation structure pour dcomposer chaque module en procdures et fonctions jusqu' obtenir par traduction une description complte excutable. Les procdures disponibles du systme d'exploitation sont elles-mmes directement utilisables. Pour le deuxime cas, s'agissant d'un prototype, la ralisation est faire en SMALLTALK, langage objet particulirement efficace pour le prototypage. A partir de la spcification, il s'agit de mettre en vidence les objets ncessaires et les interfaces entre ceux-ci pour la ralisation. SMALLTALK disposant d'une collection importante d'objets de tout type, le prototypage est rapide car une grande partie du dveloppement s'obtient par une utilisation approprie d'objets existants. 20.9. INTERET DE LA REUTILISATION Comme la montr le paragraphe prcdent, en ralisation, la dmarche de spcification et de conception doit tre poursuivie jusqu' la disponibilit de composants rpondant aux spcifications, il s'en dduit que pour rduire la dure d'un projet, il faut chercher utiliser le plus tt possible des constituants existants. Du point de vue conomique pour l'application, cette attitude n'est pas obligatoirement la plus intressante. Mais, de manire capitaliser pour les dveloppements suivants, il est souhaitable que les constituants dvelopps pour une application puissent tre nouveau utiliss. Cette stratgie est celle de la REUTILISATION. Pour qu'un constituant soit rutilisable dans d'autres applications, il doit tre dvelopp avec une spcification plus globale que celle du problme prcis qui l'a enduit. Pour le matriel, la rutilisation existe depuis des dizaines d'annes. Des composants de plus en plus complexes sont disponibles sur le march pour les ralisations. Pour le logiciel, ce point de vue est rcent mais essentiel l'avenir pour rduire les cots et temps de dveloppement. Le chapitre 22 prsente ce type dobjectif et une dmarche possible. 20.10. RESUME Ce chapitre a permis d'expliciter la signification prcise du terme ralisation en prsentant sa place dans le cycle de dveloppement d'une application. Les conclusions essentielles sont rappeles ci-aprs: - La ralisation correspond une dmarche ascendante partir de constituants disponibles pour aboutir une application oprationnelle valide et accepte par le demandeur. - Le travail de ralisation est fonction: de la nature des spcifications de ralisation, des techniques mettre en oeuvre, des mthodes et outils disponibles. - Cette tape tant prdominante dans un dveloppement, l'effort doit porter la fois sur les tapes qui prcdent et sur cette tape de manire rduire le cot. 450 M.C.S.E

Ch 20 - DEMARCHE POUR LA REALISATION - La ralisation d'un systme ncessite 3 phases: tout d'abord, la prise de connaissance et l'acceptation des spcifications, puis en parallle le dveloppement des ralisations matrielle et logicielle, enfin l'intgration, le test et la validation de l'ensemble. - La ralisation matrielle consiste produire la structure d'excution de l'application. - La ralisation logicielle permet d'obtenir la fonctionnalit de l'application par programmation des processeurs de la structure d'excution. - La phase d'intgration assure la conformit des diffrents sous-ensembles leurs spcifications, puis la conformit de toute l'application. - Le travail de ralisation dpend de l'cart entre la spcification de chaque fonction et les constituants disponibles utilisables pour cette fonction. La recherche des constituants disponibles se fait par raffinements successifs de chaque spcification et ceci selon un travail de conception. - La rutilisation des constituants, qu'ils soient matriels ou logiciels est favorable la rduction du cot et du temps de dveloppement d'un produit.

M.C.S.E

451

Chapitre 21

TECHNIQUES POUR LA REALISATION MATERIELLE

Le chapitre prcdent a montr que le travail de ralisation est fonction de l'cart entre la spcification de la structure d'excution et les constituants disponibles pour sa ralisation. Lorsque cet cart existe, un raffinement pendant l'tape est ncessaire. Ce raffinement suggre d'entreprendre tout d'abord une conception pour cette ralisation. Les spcifications des constituants de la solution sont alors plus proches de ceux disponibles. Les composants disponibles peuvent tre varis ainsi que les techniques et technologies possibles. Des considrations techniques et conomiques inclues partiellement dans les spcifications technologiques conduisent rduire le spectre des possibilits. L'objet de ce chapitre n'est pas de faire un panorama des solutions envisageables pour les ralisations matrielles, ceci sort du cadre de la mthodologie. Par contre, comme bien raliser c'est d'abord concevoir puis vrifier la solution, il nous semble utile de dvelopper les stratgies possibles ainsi que des modles gnriques et la dmarche associe. Il est ainsi montr que la dmarche MCSE est utilisable pour la conception densembles matriels. Un point est aissi fait sur les ressemblances et diffrences de travail et d'attitude entre une ralisation traditionnelle utilisant des composants existants et la dmarche qui consiste dvelopper des composants intgrs spcifiques.

M.C.S.E

453

Partie 6 - REALISATION 21.1. METHODE POUR LA RECHERCHE DUNE REALISATION Une ralisation matrielle rsulte d'une association judicieuse de composants physiques. Le terme judicieux veut dire que les composants sont choisis de manire rduire globalement le cot de la partie matrielle, tout en respectant des contraintes technologiques telles que disponibilit des composants, fiabilit, cot de reproduction... L'association doit aussi tre telle que les rgles d'interconnexion ainsi que les spcifications fonctionnelles et lectriques des composants soient respectes. Comme une ralisation matrielle est une structure topologique, la mthode pour dterminer une telle structure se dduit de celle propose pour la conception fonctionnelle. Ainsi la dmarche suivre est la suivante: - analyse des spcifications et recherche des variables et vnements caractristiques, - construction d'une solution par assemblage de fonctions autour des variables et vnements retenus, - vrification de la solution et bilan des parties directement ralisables. Cette dmarche peut nouveau tre itre de manire poursuivre le raffinement de chaque fonction jusqu' ne retrouver que des composants existants. Il ne faut pas perdre de vue que pour la ralisation, la rduction du travail passe par une utilisation le plus rapidement possible de composants existants. Ainsi la recherche des fonctions doit favoriser la mise en vidence de tels composants. Ncessairement, les concepteurs en ralisation doivent avoir une bonne connaissance des composants disponibles, la rfrence, le fabricant, les distributeurs, sa spcification sommaire. Avec l'volution de la technologie, les composants sont de plus en plus nombreux, ce qui pose un problme pour ne serait-ce que connatre leur existence. Ils sont aussi de plus en plus performants et de plus en plus gnraux dans le sens o ils deviennent paramtrables sans pour cela tre qualifis de processeur programmable. Comme exemples: en numrique, les rseaux logiques programmables, en analogique: les filtres paramtrables. Ces composants paramtrables conduisent rduire la varit des composants ncessaires pour entreprendre une ralisation: par exemple, toutes les fonctions numriques peuvent se raliser avec un seul type de rseau logique programmable squentiel. 21.2. TECHNIQUES POUR LA REALISATION Nous voquons dans ce paragraphe deux techniques de ralisation pour les systmes: lutilisation exclusive de composants existants, le dveloppement lorsque ncessaire de composants spcifiques. 21.2.1. Ralisation avec des composants existants Classiquement, une ralisation met en oeuvre un ensemble de composants existants. Pour l'lectronicien, cette solution est la seule puisqu'il n'est pas capable de fabriquer lui-mme un cot intressant les composants dont il a besoin. Les composants complexes et si possible ceux paramtrables facilitent son travail: ralisation d'une grande varit de fonctions squentielles avec un PLD, ralisation de fonctions de transfert avec un ampli oprationnel, gnration de signaux avec le PLL. 454 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE Le cot de chaque ralisation est dfini par le cot des composants et du support pour les interconnexions. L'encombrement et la consommation sont difficiles rduire du fait de l'encombrement de chaque boitier et des interfaces pour les couplages externes. Pour son travail, le concepteur d'une ralisation dispose d'outils dIngnierie Assiste par Ordinateur lui facilitant sa tche: saisie de schmas, vrification par simulation, production du support par placement et routage d'un circuit imprim. Une telle dmarche est classique et tout fait connue. 21.2.2. Dveloppement de composants spcifiques Plus rcemment, une nouvelle technique s'avre accessible et qui consiste concevoir soimme ses composants, puis sous-traiter leur ralisation. Ces composants sont appels composants intgrs spcifiques pour une application, ou ASIC. On peut expliquer cette nouveaut par plusieurs raisons complmentaires: - les contraintes de consommation et d'encombrement ne peuvent tre satisfaites que par cette technique, - pour une production de srie, l'intgration rduit le cot et le temps de reproduction et la fiabilit s'en trouve amliore, - la conception de composants intgrs devient de plus en plus automatise, ce qui permet d'en concevoir sans tre spcialiste en micro-lectronique, - les outils de conception, au pralable proprit exclusive des fabricants, aujourd'hui de plus en plus dveloppes par des socits tierces, sont accessibles aux ralisateurs: cot raliste et expertise acquise assez rapidement, - l'objectif des fabricants est de produire un maximum de circuits. D'o l'intrt conomique des ASICS pour les fondeurs. Malgr le cot lev d'une conception intgre et sans oublier le cot des erreurs, la technique d'intgration a un avenir certain. Aussi est-il bon de cerner ds prsent les mthodes et outils utiliser. Tout d'abord, comme une ralisation est une association de composants plus lmentaires, faut-il dans le cas de l'intgration descendre jusqu'au composant de base que sont: transistors, diodes...? Cela dpend. Expliquons cette rponse banale. Le concepteur doit toujours poursuivre le raffinement de sa solution jusqu'aux blocs mis sa disposition par le fabricant. On retrouve donc une situation semblable celle pour les composants discrets. Dans la majorit des cas, des bibliothques de fonctions classiques de llectronique numrique ou analogique sont disponibles. Le travail dadaptation est alors rduit et loutil est simple demploi. Mais lorsque les blocs de base sont de faibles niveau: transistor ou porte par exemple, le travail de conception est important, de mme pour les risques d'erreurs. D'autre part, les applications fortes contraintes, en particulier celles ncessitant de grandes performances, requirent la mise en oeuvre d'une technologie rcente qui n'est pas encore mise la porte des ralisateurs. La conception doit alors tre poursuivie jusqu'au niveau des structures intgres de base. La comptence en lectronique et en micro-lectronique est essentielle pour russir. M.C.S.E 455

Partie 6 - REALISATION Aujourd'hui, les ASICS sont possibles, tout au moins pour des sries moyennes (> 500 ou 1000 pices), avec un investisssement en temps d'acquisition d'expertise assez faible, un temps de conception rduit et un dlai assez faible pour l'obtention des pices, ceci parce que les outils de conception des circuits la demande propose une construction sur la base de blocs fonctionnels de niveau relativement lev, ou l'aide d'une bibliothque de fonctions identiques aux composants utiliss pour une ralisation conventionnelle. Par exemple, un outil de conception pour rseaux prdiffuss et prcaractriss met la disposition des concepteurs la plupart des fonctions numriques usuelles SSI et MSI: portes logiques, bistables, compteurs, multiplexeurs, additionneurs... Comme autre exemple, considrons un compilateur de silicium appel ainsi car capable de produire les dessins des masques pour la fabrication compte-tenu de la technologie partir des spcifications de blocs. Un tel outil de conception met la disposition des ralisateurs, un ensemble de blocs paramtrables tels que: PLA, RAM, ROM, compteurs, unit arithmtique et logique, horloges, Pads d'entre et de sortie, buffers... Concevoir un circuit avec ce type d'outil revient dcrire les blocs retenus, leurs spcifications et les interconnexions. A partir de ces donnes et des caractristiques technologiques du fondeur, un compilateur produit les masques de chaque bloc, positionne les blocs, effectue le routage entre les blocs et avec les broches d'entre et de sortie. Les critres de conception diffrent quelque peu de ceux utiliss en technologie conventionnelle. L'objectif pour le cot est la rduction de la surface de silicium, et comme tous les composants fabriqus ne sont pas fonctionnels, il faut pouvoir les tester efficacement. Pour ces raisons les structures utiliser sont lgrement modifies pour amliorer la testabilit. La premire fabrication tant coteuse (si ncessit de masque), est-on garanti du bon fonctionnement? Pour cela, les outils de conception disposent de moyens de vrification. Le premier outil disponible pour le concepteur est un simulateur qui lui permet de tester et de valider fonctionnellement pas pas chaque bloc, puis l'ensemble du circuit. Des outils complmentaires assurent la vrification des temps et la prise en compte par le simulateur des paramtres d'intgration: capacits parasites, charges, longueurs des interconnexions... Ainsi, le prototype ne se ralise plus. Par contre, le circuit est ncessairement modlis pour permettre sa simulation. En conclusion, la comptence pour concevoir des composants intgrs spcifiques est identique celle ncessaire pour la technologie conventionnelle, puisque le concepteur dispose approximativement des mmes blocs fonctionnels. La diffrence essentielle concerne la technique de validation. Avec la technique conventionnelle des composants discrets, la ralisation passe par le dveloppement d'un prototype construit et test de manire incrmentale. Les erreurs sont rapidement corriges et moindre frais. Avec la technique d'intgration, le prototype n'est plus possible. Toute la conception se fait sur informatique, la vrification est faite par simulation et est de la responsabilit du concepteur. Deux types de test sont ncessaires et extrmement importants: le test fonctionnel pour s'assurer que le circuit qui sera produit rpondra aux fonctionnalits, le test de fabrication qui permet de discriminer les bons des mauvais composants. Le paragraphe suivant dtaille lobjectif de ces tests. 456 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE 21.3. VERIFICATION, VALIDATION DUNE REALISATION Une ralisation est dveloppe pour satisfaire un objectif. La chaine logique est donc: objectif, spcification, conception, ralisation, production. Autour de cette progression logique, il faut se poser 2 questions: 1- en final, la ralisation est-elle conforme l'objectif atteindre? 2- ensuite, comme toute reproduction peut introduire des erreurs, comment peut-on identifier les produits conformes? La figure suivante illustre ces 2 problmes:

OBJECTIF

Spcification

Conception

Ralisation prototype

Produit
Production

? ? ?
Conformit Validation (question 1)

Produit conforme

(question 2)

-Figure 21.1- Squence du dveloppement. Une ralisation (prototype ou produit de srie) est dite conforme si sa fonctionnalit rpond aux objectifs souhaits. La tche pour s'assurer de cette conformit est appele validation. La validation du prototype se ralise par un test dit FONCTIONNEL. Une fois le prototype conforme, chaque produit de srie est valid par un test dit de FABRICATION. Dtaillons la signification de chacun de ces tests et la procdure suivre. 21.3.1. Test fonctionnel Selon la terminologie de la Mthodologie MCSE, un objectif n'est pas une description formelle. Seule la spcification qui s'en dduit est formalisable. Ainsi, la validation ne peut se faire que par rapport la spcification. Il reste bien sr, que toute erreur de conformit de la spcification par rapport l'objectif conduit un produit non-conforme. Malheureusement, un risque d'erreurs subsiste, ces erreurs tant non observables. Pour valider la ralisation, il faut la faire fonctionner, ceci en appliquant une squence d'actions lectriques. L'observation de son volution doit permettre de dduire sa conformit. Mais l'volution observe est intimement dpendante de la squence d'actions choisie. Si celleci est errone ou incomplte, l'observation le sera aussi, la conformit sera par voie de consquence tout fait fausse. Ainsi valider correctement ncessite, en plus de la conception, de dvelopper la procdure de test et tout particulirement la squence des tests ncessaires. Ce travail est de la responsabilit du concepteur et non de celle du ralisateur, car une solution non-testable est mauvaise. M.C.S.E 457

Partie 6 - REALISATION Faut-il obligatoirement raliser un prototype pour garantir la conformit? Pas ncessairement. Avant l'existence d'outils de simulation, le prototype matriel tait obligatoire. Aujourd'hui, il est possible de dvelopper un prototype "immatriel" par un modle sur ordinateur. L'intrt est de pouvoir valider sa conception, mais aussi de dvelopper une procdure de test. La testabilit est alors analysable. Une fois la solution par simulation valide, un prototype est ralis et vrifi l'aide de la mme procdure de test. Cette dmarche est rsume sur la figure suivante:
Validation ralisation Validation modle

Spcification

Conception

Modle en simulation

comportement

?
Test Procdure de test et squence test Test Ralisation

comportement

-Figure 21.2- Procdure conception-validation. Cette figure montre que lorsque l'on dispose d'un modle, la validation du prototype peut se faire par comparaison de son comportement avec celui du modle, les deux sous l'action de la mme squence de test. Un modle par simulation n'est pas une ncessit. Sa justification se dduit d'un calcul de cot conomique. Est-il moins coteux de valider par simulation avec une bonne garantie ou bien en ralisant un prototype. Dans le cas de la technique de ralisation conventionnelle, le prototype reste souvent prfrable. Par contre, lorsqu'il s'agit d'un composant intgr, seule la technique par simulation est raliste compte-tenu du cot lev de fabrication. 21.3.2. Test de fabrication Ce test a pour but d'identifier les produits de srie conformes. Plutt que d'effectuer la vrification par rapport aux spcifications, celle-ci peut se faire par rapport un prototype considr conforme. Les non-conformits provenant de dfauts de fabrication ou de composants dfectueux seront mis en vidence par le test fonctionnel prcdent. Toutefois, un test fonctionnel complet peut s'avrer particulirement coteux en temps et en moyens surtout lorsqu'il s'agit de cartes ou de circuits complexes. Imaginons simplement le cas d'une carte de traitement du signal ou d'un composant microprocesseur. 458 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE L'objectif du test en fabrication est de s'assurer, par un nombre d'observations limit, que tous les lments constituants se comportent correctement. Pour un circuit intgr numrique, ceci veut dire que tous les noeuds du circuit changent d'tat. Un test diffrent est dvelopp et qui a pour objectif: d'engendrer tous les changements d'tats, de les observer et de les comparer aux observations sur le prototype pour la mme squence. Un tel test peut se faire en plaant la ralisation dans une situation diffrente du test fonctionnel, par exemple, ouverture de la boucle d'une machine tats finis. Une ralisation peut ne pas tre compltement testable pour 2 raisons: les entres ne permettent pas, mme avec une squence trs longue, de modifier tous les noeuds internes (commandabilit), les sorties ne permettent pas d'observer les changements d'tats des noeuds (observabilit). On parle alors de taux couverture de test d'une ralisation. C'est encore de la responsabilit du concepteur que de dvelopper une ralisation avec la plus grande couverture de test possible et avec la squence la plus courte. La procdure pour le test en fabrication est reprsente ci-dessous:
comportement

Prototype

?
Squence de test de fabrication Produit de srie comportement

-Figure 21.3- Procdure pour le test en fabrication. En juxtaposant les 2 figures prcdentes, dans le cas d'une validation par simulation, on s'aperoit que la squence de test fabrication peut se dvelopper sur le modle. Si ce modle est suffisamment raliste, le degr de confiance peut tre tel que la ralisation du prototype peut tre supprime. Cette procdure est utilise pour les circuits intgrs, sachant bien entendu qu'une pr-srie est ralise pour s'assurer de la conformit fonctionnelle. 21.4. REUTILISATION POUR LE MATERIEL Pour rduire le temps de ralisation, nous avons vu dans le chapitre 20 qu'il faut s'efforcer de rutiliser les structures existantes. Cette dmarche est visible pour le matriel. En effet, les fabricants de composants mettent progressivement la disposition des ralisateurs des composants de plus en plus complexes utilisables uniquement partir de la connaissance de leurs spcifications. Les composants dvelopps correspondent aux fonctions ncessaires les plus couramment utiles pour les ralisations. Plus un composant est gnral, plus il est utilisable dans diverses applications, d'o son intrt conomique pour les fabricants. Le microprocesseur est un exemple particulirement illustratif, et dans MCSE nous l'avons considr comme le composant ralisant la fonction de processeur programmable. L'amplificateur oprationnel, et le PLL sont d'autres exemples en lectronique analogique. M.C.S.E 459

Partie 6 - REALISATION La rutilisation n'est possible que si les ralisateurs ont connaissance des composants disponibles. L'acquisition de cette comptence est lente et progressive et doit tre entretenue en permanence. Une telle connaissance est facilite par les modles gnriques, car ils fournissent un guide d'analyse et de classification des composants sur la base de leurs spcifications. Le dveloppement de circuits intgrs favorise-t-il la rutilisation? Oui et non. Non, car chaque concepteur peut vouloir dvelopper son propre circuit avec l'ide qu'il sera meilleur que des circuits existants. Mme au niveau des blocs, il peut ne pas tenir compte des blocs fonctionnels dj construits et qui sont la proprit de sa socit. Cette tendance, comme elle existe bien en logiciel, est tout fait imaginable pour les ASICS. Un outil de conception est un outil assez individuel, qui de plus, cache l'objet conu car non matrialis. Pour ces raisons, en l'absence de contraintes, la tendance de dvelopper soi-mme est tout fait raliste en l'absence de contraintes. Pour viter ceci, des garde-fous sont mettre en place par une politique d'information, de coordination de projets, de suivi des dveloppements, similaire une politique qualit. Oui, car si les situations dcrites prcdemment sont vites, chaque concepteur dveloppe des blocs qui peuvent ensuite aprs validation tre mis la disposition des autres concepteurs d'une mme organisation. Au-del, si ces blocs ont un intrt plus large, ils peuvent mme finir par tre disponibles tout utilisateur de l'outil. C'est ainsi que par exemple dans une mme organisation, aprs avoir dvelopp un noyau microprocesseur et une panoplie de blocs fonctionnels priphriques, un circuit trs complexe peut se dvelopper rapidement par juxtaposition des fonctionnalits disponibles. Compris de cette manire et avec une rigueur de conduite d'objectifs, la rutilisation est un facteur de gain conomique essentiel. Comme le montre le paragraphe suivant, une utilisation de modles gnriques favorise cette stratgie de la rutilisation; on peut comme exemple considrer que le noyau microcontrleur qui est un processeur programmable est l'exemple le plus volu de modle gnrique matriel. 21.5. MODELES GENERIQUES POUR LA REALISATION Puisque raliser partir dune structure dexcution peut ncessiter tout d'abord un travail de conception, reprenons ici les ides proposs pour la conception fonctionnelle. Concevoir est un processus cratif. Aussi, la comptence du concepteur est un facteur important d'influence sur la nature du rsultat. Pour raffiner une fonction, il faut analyser la spcification et en dduire les lments essentiels internes strictement ncessaires en recherchant de prfrence les variables plutt que les fonctions. Une autre mthode complmentaire consiste s'inspirer de modles gnriques de solutions capables d'induire une solution de qualit et facilement ralisable. Un modle gnrique rduit alors le travail d'analyse en favorisant la dduction des informations essentielles. De manire illustrer l'intrt de tels modles, nous prsentons dans la suite 2 modles gnriques particulirement appropris pour la conception de fonctions numriques. Cette base est trs utile pour les concepteurs de cartes et de composants intgrs qui doivent rechercher larchitecture de la solution. 460 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE Pour amliorer le travail et la qualit en ralisation et avec le point de vue des modles, un dveloppement important reste encore faire dans tous les domaines de l'lectronique pour faire apparatre des structures gnriques essentielles. De telles structures existent fort probablement dans ces domaines mais n'apparaissent peut-tre pas clairement l'esprit des concepteurs, probablement pour des raisons de prsentation. Les domaines auxquels nous pensons sont au moins ceux de l'lectronique analogique, des transmissions, de l'lectronique de puissance, du traitement du signal. Pour illustrer l'apport d'un modle gnrique, l'exemple type en lectronique numrique est celui de la machine de MOORE prsent dans le paragraphe suivant. Cette structure de machine est un modle gnrique trs ancien pour la ralisation de toute fonction squentielle. Son intrt aujourd'hui est que des composants paramtrables conforme ce modle existent: les rseaux logiques programmables, et que des outils permettent de passer directement d'une spcification - quation, diagramme tats finis - en une programmation des rseaux. Ignorant ce modle en conception, les rseaux logiques diminuent d'intrt et par voie de consquence les outils de production associs. Pourquoi ne pas penser combien un tel modle gnrique mais en lectronique analogique, serait d'un apport considrable pour les lectroniciens. 21.6. LE MODELE DE LA MACHINE DE MOORE 21.6.1. Le principe G.H. MEALY et E.F. MOORE, 2 pionniers en conception de systmes logiques squentiels, ont propos dans les annes 50 une formulation mathmatique pour exprimer la solution de toute fonction squentielle. Xt+1 = F(Xt, Et) Yt=G(Xt, Et) avec: - Et - Xt - Yt - F et G le vecteur des entres, le vecteur d'tat au temps courant, le vecteur des sorties, 2 fonctions combinatoires.

Cette formulation dfinit la mthode suivre pour rsoudre un problme squentiel. En effet, si tous les tats de X sont connus (premier travail de conception), le problme squentiel est alors ramen 2 problmes combinatoires puisqu'il s'agit de trouver F et G. Aux quations ci-dessus correspond une structure de ralisation appele machine de MEALY. Suivant les termes considrs, 4 structures s'obtiennent par dgnrescence, comme le montre la figure 21.4. M.C.S.E 461

Partie 6 - REALISATION

H Et Xt+1 F G Yt

Machine de MEALY

Xt

Machine de MOORE

-Figure 21.4- Structures de ralisation partir de la machine de MEALY. Les 2 dernires structures correspondent des fonctions uniquement combinatoires, qui sont ainsi prsentes comme des cas particuliers du modle gnral. La diffrence essentielle entre la machine de MEALY et celle de MOORE est que les sorties Yt pour la premire sont asynchrones par rapport Xt puisque dpendantes directement de Et. En lectronique numrique, les problmes asynchrones sont bien plus complexes rsoudre. Aussi pour induire une qualit au niveau de la solution et simplifier la tche de recherche de la solution, il est conseill autant que possible de limiter les solutions au cas des systmes synchrones. Pour cette raison, nous considrons la machine de MOORE comme la structure conseille pour la conception des fonctions squentielles [CALVEZ-87]. 21.6.2. Le modle Puisque la structure de MOORE convient pour la conception de toute fonction squentielle, il s'agit bien d'un modle gnrique de solution. Avantage supplmentaire, technologiquement les rseaux logiques programmables (PLD) sont conformes la structure de MOORE. Ainsi, toute fonction squentielle est implantable dans un PLD donn si celui-ci est suffisamment dimensionn. Autre avantage, il existe des outils permettant de traduire une spcification en une programmation et de simuler le comportement pour la vrification. Le modle fonctionnel gnrique induit par la machine de MOORE et la structure de ralisation correspondante sont donns sur la figure 21.5. 462 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE

Ev E F Et X Y G F

Ev

X G

Yt

Xt

-Figure 21.5- Modle gnrique de MOORE et sa ralisation. La variable X est traduite en un registre X. L'vnement EV dfinit les instants d'volution de X et donc de Y (fonctionnement synchrone EV). L'vnement EV peut ne pas exister. F est alors une action permanente valuant Xt+1 tout instant. Ceci correspond un registre X transparent ou inexistant. C'est le cas d'une machine squentielle asynchrone qu'il est dconseill d'utiliser pour les problmes d'alas sous-jacents. 21.6.3. mthode La mthode suivre en conception se dduit du modle. Tout passe par la connaissance du vecteur des tats internes. La dmarche est donc la suivante: - rechercher la variable d'tat X strictement ncessaire pour satisfaire la spcification, - dfinir les 2 fonctions F et G, - vrifier la solution par rapport aux spcifications, - transformer la solution en une ralisation: codage des tats de X, puis quations de F et G. Cette dmarche est tout fait conforme la mthode propose en conception fonctionnelle, et on le voit bien ici, le modle aide trouver dabord la ou les variables essentielles pour rsoudre le problme. Le modle de spcification le plus appropri pour cette mthode est le diagramme tats finis. Lorsque la spcification est plus complexe: rseau de Petri, grafcet avec paralllisme, celleci doit d'abord tre transforme en diagrammes tats finis, a priori au maximum autant de diagrammes que le degr de paralllisme de la spcification. Des simplifications peuvent apparatre, dans ce cas il faut de prfrence transformer la spcification avant de rechercher une solution. A chaque diagramme correspond alors une machine squentielle. La solution globale rsulte d'une interconnexion de ces machines avec couplage par leurs variables d'tat. L'exemple suivant illustre cette dmarche. La spcification est un grafcet avec paralllisme. Il se traduit en deux automates coupls. Le modle de MOORE est alors utilisable, ce qui conduit la solution matrielle. M.C.S.E 463

Partie 6 - REALISATION

D1 Repos
repos

D2

repos

A
A

tat D1 = E1 E2

E1

E1

E2
C tat de D2 = E3 B

B
E4

E3

E3
C C

C E4

Rsultats

H H A,B,C F1 F2 X G1 Y1 H E_D2 G2 Y2 C B Y2 F2 G2 F1 A E_D1 Y1 G1

-Figure 21.6- Dmarche pour la conception d'une fonction squentielle. Pour une spcification avec paralllisme, le passage par la dcomposition en plusieurs diagrammes squentiels peut parfois tre vit. Il faut pour cela chercher transformer le grafcet avec paralllisme en un grafcet sans paralllisme. Ceci est possible pour l'exemple cidessus, en sparant E1 en 2 sous-tats E'1 et E'2 avec comme condition de transition B. Ce travail prliminaire de transformation de la spcification fait partie de l'analyse qui prcde la conception. 464 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE 21.7. LE MODELE COMMANDE/EXECUTION Le modle prcdent a une porte limite aux cas des fonctions peu complexes et pour lesquelles les actions associes aux tats sont du type logique. Lorsque la spcification s'exprime difficilement par un grafcet ou un diagramme tats finis, il est prfrable d'utiliser alors une spcification du type algorithmique. Un tel modle est encore squentielle, mais les actions et les conditions peuvent tre complexes (calculs, comparaison...). Les relations d'ordre peuvent aussi tre complexes. Il faut donc un modle gnrique plus gnral. 21.7.1. Principe Depuis le dbut des ordinateurs, en particulier TURING et VON NEUMANN ont montr que tout algorithme est excutable par une machine squentielle mmoire programme et donnes. La structure de la plupart des calculateurs processeur squentiel dcoule de ce concept. L'analyse de la structure des machines de traitement montre qu'elles sont toutes bases sur l'association de 2 parties: une partie oprative, une partie commande. La partie oprative mmorise les donnes (mmoire, registres), et transforme ces donnes par des oprateurs spcialiss (addition, multiplication, dcalage...). La partie commande dcide pour la partie oprative des transformations et des instants de mmorisation calculs par la partie oprative. La structure gnrale correspondante est la suivante:
donnes

Et PARTIE OPERATIVE

Yt

Ft,Gt

Xt

Evt PARTIE COMMANDE

Sevt

vnements

-Figure 21.7- Structure gnrale pour un processeur squentiel. Se rfrant aux quations de la machine de MEALY, ce modle considre que les vecteurs Et et Yt sont dcomposs en 2 catgories: donnes et vnements, et que les fonctions F et G voluent en fonction du temps pour dfinir le rle de la partie oprative. L'volution de F et de G est fige la conception pour une machine programme, et peut se modifier tout instant pour une machine programmable. Le vecteur des observations faites sur X peut se rduire aux seules conditions utiles pour la partie commande. Ces observations sont appeles indicateurs (flags). M.C.S.E 465

Partie 6 - REALISATION 21.7.2. Modle La structure gnrale prsente dans le paragraphe prcdent ayant permis de servir comme guide aux architectes des machines de traitement pendant plus de 40 ans, correspond bien un modle gnrique. Un tel modle est ici appel modle COMMANDE/EXECUTION, et la structure est du type matre-esclave. Cette structure est aussi rapprocher du modle gnrique SUPERVISION/CONTROLE-COMMANDE prsent dans la partie conception. Si les 2 modles correspondent un mme concept, ils ne sont toutefois pas de mme niveau: - le modle SUPERVISION/CONTROLE-COMMANDE est de niveau lev (niveau applicatif) car trs orient applications du type conduite de procds, - le modle pour les processeurs est de niveau plus lmentaire (niveau technologique), adapt pour le dveloppement de solutions matrielles. Le modle fonctionnel gnrique est le suivant:

Ed EXECUTION

Sd

CMD

IND

Ee Se COMMANDE

-Figure 21.8- Le modle gnrique COMMANDE/EXECUTION. Les entres E sont spares en 2 parties: Ed pour les donnes et Ee pour les vnements externes considrs comme des variables logiques observables. De mme les sorties sont de 2 types: Sd pour les donnes et Sc pour les actions traduites par des variables ou des vnements. Les actions sur la partie excution spcifies par CMD sont aussi de 2 types: des tats pour dsigner par exemple le type d'opration, et des vnements pour dfinir les instants d'action. Les observations ncessaires pour la prise de dcision sont transmises par IND. Pour la ralisation des processeurs spcialiss, la partie commande est dfinie une fois pour toutes vis vis des spcifications. L'vnement H, en agissant sur la partie commande, dfinit les instants d'volution: prise en compte des entres et changement de CMD. Ce modle gnrique favorise la dcomposition en suggrant de rechercher les variables ou vnements essentiels que sont Ed, Sd, Ee, Se, CMD et IND. Les 2 parties peuvent ensuite se raffiner pour mettre en vidence les constituants internes comme lindiquent les paragraphes suivants. 466 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE

-A- RAFFINEMENT DE LA PARTIE EXECUTION

Cette partie est charge de raliser les transformations souhaites sur les variables Ed, de mmoriser des variables utiles par la suite, de gnrer les grandeurs de sortie. La structure interne se dduit d'une analyse de la spcification sous la forme d'un diagramme flot de donnes. De ce diagramme sont extraites les variables internes ncessaires et les oprations de transformation. Les variables internes et variables de sortie sont obtenues par passage dans des oprateurs de transformation puis mmorisation sur une commande. Ainsi la partie excution peut se reprsenter par une structure fonctionnelle compose uniquement de variables internes, de fonctions de transformation, celle-ci pilote par des vnements d'excution. Aux constituants de cette structure fonctionnelle correspondent les lments technologiques que sont: registres ou mmoires pour les variables, oprateurs pour les fonctions, chemins de donnes pour les liens fonctions variables, signaux de commande pour les vnements. L'exemple suivant illustre le schma fonctionnel de la partie oprative d'une unit de traitement, et une traduction selon une structure matrielle organise autour dun bus.
Reg E S

in Sel A La

out

Calcul B Sel B Res

Lb no_reg op

in E bus Mmoire La

out S

Lb Rd no_reg Wr op Res

-Figure 21.9- Exemple de dcomposition de la partie excution. La variable Reg est traduite comme une mmoire. Larchitecture est construite autour dun bus. Les variables de CMD sont No_Reg et Op, tandis que les signaux de CMD sont: Rd, Wr, La, Lb, Res, In, Out. Le modle bas sur la dcomposition en variables et oprateurs de transformation est appel MODELE OPERATOIRE. Une fois acheve la conception de la partie excution, se dduit la spcification de la partie COMMANDE indispensable pour satisfaire la spcification de l'ensemble. Cette spcification est souvent dcrite sous la forme d'un diagramme d'tats. M.C.S.E 467

Partie 6 - REALISATION
-B- RAFFINEMENT DE LA PARTIE COMMANDE

La partie commande synchrone un vnement H est charg de produire les sorties CMD et Se partir des observations IND et Ee. Comme il s'agit d'une fonction squentielle spcifie par un diagramme d'tats, elle est ralisable selon le modle de MOORE. Le modle gnrique prcdent est donc utilisable pour le raffinement. Selon la complexit des spcifications de la commande: nombre d'tats, relations d'ordre, conditions, voire mme paralllisme des actions, la dcomposition peut justifier l'emploi de plusieurs machines squentielles couples. Par exemple, lorsque le graphe des tats est important et inclut des branches squentielles, la dcomposition peut induire: une machine squentielle pour la gestion des branchements et une autre pour la gestion des squences. On retrouve alors la solution suivante.
IND CMD

exec Ee Evaluation droulement Se Squencement

ETAT H

IND

CMD

Ee exec PLA1 PLA2

Se

ETAT H

-Figure 21.10- Exemple de dcomposition de la partie COMMANDE. Les 2 PLA sont squentiels; ils incluent le registre correspondant respectivement aux variables EXEC et ETAT. 21.7.3. Mthode Le modle gnrique induit la mthode de conception. Il s'agit de rechercher tout d'abord les variables internes ncessaires, puis les oprateurs de transformation pour produire ces variables. Se dduit alors l'interface entre les 2 parties. La dmarche est la suivante: - Conception de la partie excution: diagramme flot de donnes, recherche des variables internes, recherche des transformations et spcification, spcification de l'interface, traduction en une solution technologique. 468 M.C.S.E

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE - Conception de la partie commande: spcification de la commande partir de l'excution comme environnement, slection de la structure, conception de chaque machine squentielle, traduction en une solution technologique.

Pour cette mthode conforme aux principes de la conception fonctionnelle, le modle de spcification le plus appropri est une description algorithmique. A partir de cette spcification, l'analyse flot de donnes dcoule naturellement puisque l'algorithme utilise des variables et des oprateurs: calcul, comparaison, affectation. De cette analyse doit se dduire la structure oprative ncessaire pour raliser toutes les oprations de l'algorithme. Cette structure peut s'optimiser pour rduire les lments ncessaires: utilisation par exemple d'un bus commun pour plusieurs transferts. Cette optimisation est faite durant la phase de traduction en une solution technologique et compte-tenu des contraintes de temps. La spcification de la partie commande charge d'enchainer les oprations se dduit en remplaant les oprations par les commandes ou observations. Elle est alors traduite en un diagramme tats finis pour ensuite dduire la structure la plus approprie. Les lecteurs intresss par les techniques et mthodes de ralisation dcrites dans ce chapitre peuvent se reporter au document METHODES ET TECHNIQUES pour l'ELECTRONIQUE NUMERIQUE, chapitre 6. La dmarche ci-dessus est illustre par des exemples [CALVEZ-87]. Pour rduire le temps de ralisation, nous avons vu qu'il faut s'efforcer de rutiliser les structures existantes. Dans ce sens, pour le modle gnrique COMMANDE/EXECUTION, des circuits existent aussi pour chaque partie et qui disposent: - d'une structure oprative gnrale comprenant un ensemble de registres, un oprateur gnral de calcul, des compteurs... - des squenceurs gnraux programmables. Les processeurs en tranches sont les exemples illustratifs les plus anciens. L'emploi de cette technologie justifie des contraintes de performances svres qui ne peuvent pas s'obtenir avec un modle plus gnral qu'est le microprocesseur. La dmarche qui vient dtre prsente est directement applicable pour la conception des ASICS et de processeurs spcialiss. Actuellement, ce travail doit tre ralis par les concepteurs. Lobjet des recherches en compilation de silicium et plus particulirement en synthse architecturale consiste dvelopper des outils de production automatique de larchitecture jusquau layout partir dune spcification algorithmique. Les deux modles gnriques prsents sont la base de ces outils. 21.8. RESUME Ce chapitre a permis d'voquer les techniques et mthodes de ralisation pour la partie matrielle d'une application. Une ralisation ncessite habituellement une phase initiale de conception. Pour illustrer la dmarche de conception suivre, celle-ci respectant les principes de la conception fonctionnelle, 2 modles gnriques appropris pour la ralisation des systmes numriques ont t prsents. M.C.S.E 469

Partie 6 - REALISATION Dcrite pour la conception de processeurs spcialiss, la dmarche prsente est aussi applicable, si ncessaire, pour la conception des processeurs programmables. Ce chapitre, loin d'tre complet, ne rpond pas toutes les classes de fonctions: lectronique analogique, lectronique de puissance... Il reste plus particulirement orient lectronique numrique, ce qui reprsente tout de mme aujourd'hui la part la plus importante des dveloppements matriels. Bien sr, d'autres modles et mthodes sont mettre en vidence pour les autres domaines, de manire favoriser l'acquisition de la comptence et le travail de synthse pour les concepteurs. De ce chapitre, retenons les points essentiels suivants: - Une ralisation rsulte d'un processus de raffinement qui implique pour chaque niveau une conception et ceci jusqu' aboutir des composants existants et utilisables. - La solution est loin d'tre unique. Des critres conomiques, fonction de la quantit produire, sont prendre en compte pour slectionner la meilleure technologie. - Deux techniques de ralisation peuvent tre opposes: ralisation sur la base de composants existants, dveloppement de composants intgrs spcifiques. Les mthodes et techniques de conception sont trs proches, par contre les mthodes de ralisation et de validation diffrent totalement. Des critres conomiques permettent de dcider de la stratgie suivre. - La rduction du cot passe par la rutilisation quelle que soit la stratgie de dveloppement de la ralisation, l'organisation doit favoriser cette rutilisation. - Des modles gnriques favorisent la recherche de solution lors du travail de dcomposition. Aux modles gnriques pour le matriel correspondent des composants, ce qui simplifie la tche de ralisation. - Le responsable de l'quipe de ralisation a une grande responsabilit: qualit et prnit des ralisations, choix des constituants pour rduire le cot de reproduction, politique d'volution et de rutilisation... - La validation pour s'assurer de la conformit est essentielle; le dveloppement de la ralisation pour satisfaire cet objectif ainsi que les procdures de validation sont de la responsabilit du concepteur.

470

M.C.S.E

Chapitre 22

TECHNIQUES POUR LA REALISATION LOGICIELLE

En temps de dveloppement, la ralisation logicielle reprsente une part de plus en plus importante de la ralisation. Plusieurs faits complmentaires expliquent cette situation. Citons entre autres: l'augmentation de la performance du support matriel permettant ainsi performance donne la possibilit d'une ralisation logicielle plutt que matrielle, ensuite, l'augmentation considrable de la demande en termes de fonctionnalits, dernier point cit, la souplesse de dveloppement permise par le logiciel. En voquant la "crise du logiciel", beaucoup d'auteurs [ABBOTT, JONES, FREEMAN, BOOCH, COX...] s'accordent constater que la production en logiciel reste linaire, alors que pour le matriel cette croissance est gomtrique. Des analyses plus fines indiques par JONES ont montr que sur l'ensemble du logiciel dvelopp en 1983, probablement moins de 15% est unique, nouveau et spcifique d'une application. Les 85% restants servent implanter ces applications sur des ordinateurs. Ce chapitre se veut utile pour les dveloppeurs de la ralisation logicielle. Il n'a pas la prtention de couvrir le domaine qu'est le gnie logiciel. Ce document est plus particulirement destin aux concepteurs et ralisateurs d'applications temps-rel, ceux-ci spcialistes d'Informatique Industrielle proviennent probablement plus de l'Electronique que de

M.C.S.E

471

Partie 6 - REALISATION l'Informatique. Aussi est-il souhaitable de montrer comment les mthodes et techniques du gnie logiciel conduisent un gain notable en cot et en qualit. L'objectif est de situer les diffrentes techniques aujourd'hui disponibles pour obtenir efficacement l'implantation de la partie logicielle d'une application temps-rel. Le point de dpart est le document de spcification de la ralisation logicielle avec la contrainte d'un fonctionnement sur un support matriel dvelopp par ailleurs. Ce chapitre insiste particulirement sur le fait que les dveloppements doivent conduire faire voluer les fonctionnalits du support d'excution vers les applications en crant des niveaux de plus en plus abstraits, ce qui conduit la rutilisation, plutt que de devoir systmatiquement pour tous les projets, se conformer aux contraintes du support matriel. Les langages de haut-niveau temps-rel et les excutifs temps-rel, ainsi que la programmation oriente objet sont montrs comme des techniques permettant de rduire le foss entre le niveau fonctionnel et le support d'excution tout en favorisant la rutilisation. La connaissance de ces techniques s'avre ncessaire car elles influent nettement sur le cot de dveloppement de l'application. 22.1. NIVEAUX DE FONCTIONNALITES ET DEMARCHES La mthodologie MCSE conduit par l'tape de conception fonctionnelle dvelopper une solution dite fonctionnelle, dont une de ses grandes caractristiques est d'tre indpendante de la technologie et donc du support excutif. La partie logicielle, objet de ce chapitre, est dduite durant l'tape de dfinition de la ralisation. Ainsi pour l'implantation du logiciel, le support excutif est une contrainte impose, dcide sur la base d'un ensemble de contraintes la fois techniques et conomiques. Notons tout de suite, que le choix du support matriel peut dpendre de la technique de ralisation utilise pour le logiciel. En effet, le cot en temps de dveloppement et le cot de reproduction ont une incidence sur le cot du projet, mais avec une importance qui varie selon le nombre de produits rsultants. Ainsi, pour disposer de tous les lments de dcision, dans la suite sont mis en vidence les diffrents niveaux de fonctionnalits et les dmarches possibles. 22.1.1. Niveaux de fonctionnalits Pour la ralisation du logiciel, les donnes connues sont: - comme spcification, la description fonctionnelle de la partie logicielle avec le schma d'implantation logicielle, - comme contrainte: le support matriel, constitu d'un ou de plusieurs processeurs programmables. Ces 2 ralits sont compltement opposes. La solution fonctionnelle est spcifique d'une application et ne peut servir que pour cette application. Un support informatique par contre est potentiellement capable de satisfaire une grande varit d'applications, mais sans apport d'informations complmentaires sous la forme de programmes, aucune application ne fonctionne. Cette diffrence est illustre par la figure 22.1. 472 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

Application particulire

Solution fonctionnelle

niveau 3
IMPLANTATION ABSTRACTION

niveau 2

niveau 1
Support programmable

niveau 0

Varit des applications potentielles

-Figure 22.1- Diffrenciation des 2 ralits. Compte-tenu du foss existant entre les 2 aspects, il est facile d'imaginer l'intrt de niveaux intermdiaires. Chaque niveau est une abstraction du niveau infrieur, constitu d'un ensemble de services facilitant la ralisation de l'application spcifique, mais restreignant les possibilits en terme de varit d'applications et probablement rduisant aussi les performances. Comme exemple, citons le cas des excutifs temps-rel (ou moniteurs temps-rel). La couche logicielle implante sur un support programmable micro-processeur facilite l'implantation d'une application multi-tches. Les procdures de gestion des tches rduisent les performances temps-rel par suite des temps de commutation de tches et aussi par exemple parce que le mcanisme d'interruption du processeur n'est plus accessible ce qui restreint les possibilits. La finalit de la ralisation logicielle est d'aboutir au fonctionnement de chaque application particulire sur un support programmable. De cette prsentation se dduit des lments de dmarche. 22.1.2. Dmarches Plaons-nous dans le cas d'une application spcifique et d'un support programmable donn. Pour combler le foss entre les 2 ralits, les 2 dmarches opposes sont: la dmarche descendante jusqu'au support, la dmarche ascendante partir du support jusqu' satisfaire l'application.
-A- DEMARCHE DESCENDANTE

La dmarche descendante conduit dvelopper, par raffinements successifs, toutes les couches ncessaires. Chaque couche correspond un niveau d'abstraction donn et a pour objectif d'offrir les services ncessaires pour le ou les niveaux suprieurs. Les services utiles du niveau infrieur se dduisent par analyse des spcifications pour chaque niveau. La mthode conventionnelle la plus connue est celle de la programmation structure pour les programmes, tandis que la mthode Structured Design s'avre plus adapte au dveloppement d'un ensemble de programmes. La recherche des services reste trs dirige car les possibilits du support sont connus. M.C.S.E 473

Partie 6 - REALISATION La dmarche descendante ncessite un travail de conception (mise en vidence de la structure des programmes et des services), et un travail de programmation niveau par niveau jusqu'au support. Il faut noter que la transformation pour passer d'un niveau donn sur le support peut se faire d'une manire automatique si des outils existent. C'est le cas des compilateurs PASCAL, ADA... pour l'obtention du code objet partir d'un langage de haut-niveau.
-B- DEMARCHE ASCENDANTE

A l'oppos, la dmarche ascendante consiste construire partir du support, un ensemble hirarchis de couches, chacune offrant des services dont l'objectif est de faciliter la ralisation de l'application. Les services ainsi dvelopps s'avrent utilisables pour d'autres applications, ce qui est intressant pour rduire le temps de dveloppement. En consquence, disposant de niveaux plus abstraits, il est possible de traiter des problmes plus complexes. Toutefois, pour l'objectif d'une application spcifique, il est vident qu'en partant du support programmable, les possibilits de chaque couche et par consquent les dveloppements seront trs suprieurs ceux strictement ncessaires pour raliser l'application. En consquence, le temps sera nettement plus important et donc le cot qui en dcoule. Cette dmarche ne peut se justifier que si le dveloppement conduit ensuite une rutilisation pour d'autres applications. Pour comparer ces 2 dmarches extrmes, la dmarche descendante est efficace pour chaque application car conduisant ne considrer que le ncessaire par un dveloppement systmatique jusqu'au support, mais introduit une perte d'efficacit pour un ensemble de projets. La dmarche ascendante correspond un investissement plus long terme car elle conduit crer des niveaux de services rutilisables. Moins efficace et donc peu intressante pour une application donne, elle trouve son intrt pour un ensemble de produits en rduisant une fois pour toutes la distance entre l'application et le support. L'volution des techniques et des outils de ralisation rsulte d'une progression globale ascendante qui ne peut tre que lente.
-C- DEMARCHE MIXTE

Les 2 dmarches ne sont pas du tout exclusives. Au contraire, les considrant complmentaires, il est plus raliste de se dire qu'il existe un niveau intermdiaire constitu des services utiles pour la classe d'applications traites. La figure 22.2 illustre les 3 types de situations. La dmarche mixte consiste effectuer une dmarche descendante partir de l'application pour mettre en vidence les services ncessaires et utiliser au mieux et ds que possible des services dj dvelopps. Plus les niveaux de services sont levs, plus le temps de ralisation est rduit. Cette analyse faite pour le logiciel peut se comparer la situation pour le matriel. Pour le matriel, il n'est plus possible conomiquement de dvelopper la ralisation d'un systme numrique jusqu'au constituant de base qu'est le transistor ( comparer l'instruction en logiciel). Les ralisations matrielles sont bases sur des composants de trs grande complexit utilisables car mis la disposition par les fabricants. Ces composants rsultent d'une progression ascendante lente, synthse des dveloppements qui engendre une volution de la technologie. L'investissement long terme favorise la rutilisation, ce qui conduit une progression gomtrique des dveloppements. 474 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

Application 1

Application 1 Excs pour lapplication 1 3 2 1 0

Application 2

Dveloppement

3 2 1 0

Dveloppement

Dmarche descendante

Dmarche ascendante

application 1

application i 4 3

application j 4 3

Dveloppement
2

4 3

Rutilisation
0

Fonctionnalits 1 communes

Dmarche Mixte

-Figure 22.2- Dmarche descendante et ascendante, rutilisation. Un concepteur de matriel, mme s'il juge qu'un composant n'est pas des plus performants, est contraint de l'utiliser car c'est pour lui la seule solution conomique viable. En logiciel par contre, chaque programmeur peut se mettre crire et rcrire des procdures dveloppes par des collgues et mme par lui-mme car ces produits sont des matriaux impalpables, difficilement mesurables. 22.2. REUTILISATION POUR LE LOGICIEL L'analyse prcdente a permis de montrer que l'utilisation de services structurs en niveaux d'abstraction conduit rduire le temps de dveloppement d'une application. La motivation premire est donc d'ordre conomique. Selon FREEMAN [FREEMAN-87], la rutilisation est une activit. Pour le dveloppement de logiciels, il s'agit de toute procdure utilisant tout ou partie d'un dveloppement antrieur. La rutilisation concerne plusieurs niveaux dans le processus de dveloppement: 1- procdures et modules, sous la forme de code excutable alors appels composants logiciels, 2- collections de services permettant de satisfaire un objectif fonctionnel. Exemple: excutif temps-rel, systme d'exploitation, compilateurs..., 3- des applicatifs, qui rpondent un domaine d'application donn et utilisable directement. C'est le cas des progiciels, 4- des gnrateurs d'applications qui sont paramtrs partir de connaissances fournies au logiciel. Dans ce chapitre, on s'intressera tout particulirement aux niveaux 1 et 2. Pour que le concept de rutilisation en logiciel devienne une ralit, il faut rpondre aux problmes suivants [HOROWITZ-87]: M.C.S.E 475

Partie 6 - REALISATION - Mcanismes pour identifier des composants. Comment peut-on dterminer des composants qui peuvent tre d'un intrt gnral et spcifiables de manire tre utiliss par quiconque dans de nombreux projets? - Mthode pour spcifier les composants. Une fois un composant identifi, comment rdiger sa description pour qu'elle soit comprise par tous les utilisateurs potentiels? - Forme des composants. Sous quelle forme mettre disposition ces composants pour qu'ils soient utiliss dans diffrents environnements, savoir: systme d'exploitation, processeur, langage de programmation? - Catalogue des composants. Comment en tant qu'utilisateurs prendre connaissance des composants existants? Une analogie directe est faire avec les composants matriels. Les 4 points prcdents sont satisfaits. Il reste que chaque concepteur doit entreprendre un travail de lecture et de suivi des produits nouveaux pour connatre et exploiter au mieux les composants du march. En logiciel, si le travail ncessaire pour associer des composants est trop important ou ncessite des comptences particulires, l'avantage potentiel de la rutilisation disparait et le programmeur sera confort dans l'ide de dvelopper lui-mme les composants dont il a besoin. Pour les composants matriels, ceci n'est pas possible. L'esprit de rutilisation se dveloppe ainsi que la connaissance des composants en tudiant les catgories et pour chacune leurs spcifications et leurs proprits [COX-85]. Depuis 1980, la rutilisation est devenue le matre-mot pour les dveloppements logiciels. Mais bien des problmes restent rsoudre: d'ordre mthodologique, d'ordre organisationnelle, d'ordre stratgique, d'ordre pdagogique ... On montre dans la suite quelques techniques allant dans le sens de la rutilisation, exploitables pour les applications temps-rel. 22.3. PRINCIPES DE REALISATION Une ralisation logicielle doit satisfaire: - les spcifications dduites du travail de conception fonctionnelle et de dfinition de la ralisation, - des critres de qualit pour respecter des objectifs imposs par l'assurance qualit et qui conduisent amliorer le cycle de vie du produit. Les critres de qualit conduisent dfinir les caractristiques des objets logiciels. De ces caractristiques dcoulent des principes de conception et de ralisation [ABBOTT-85]. 22.3.1. Qualits Les qualits suivantes sont habituellement cites comme essentielles [ABBOTT, TONIES, JONES, BOOCH ...] - adquation: (usefulness). Le logiciel rpond l'objectif exprim par le demandeur. Cette qualit dpend de laptitude des spcifications traduire l'objectif et de la conformit du produit ces spcifications. 476 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE - efficacit: (efficiency). Le logiciel est oprationnel avec les ressources disponibles et de manire optimale. Les ressources mises en oeuvre sont celles imposes et suffisantes pour le problme. Les performances sont satisfaites ainsi que toutes les contraintes temporelles. - fiabilit: (reliability). Lobjectif du produit est atteint en toutes circonstances. Comme qualificatifs sont cits les termes: correct, robuste, tolrant aux fautes. - maintenabilit: Lcriture du logiciel facilite les corrections d'erreurs, les changements et les amliorations ou volutions. Cette qualit est essentielle car le cot de la maintenance s'avre particulirement important puisqu'il est fait tat de chiffres allant jusqu' 70% du cot du produit. - portabilit: ce critre permet de porter trs rapidement tout dveloppement sur d'autres matriels. 22.3.2. Caractristiques Pour satisfaire les objectifs prcdents de qualit, ABBOTT prconise 2 caractristiques essentielles pour le logiciel: - lisibilit: (understandability). La lisibilit favorise la comprhension du logiciel, ce qui permet: de dterminer plus facilement s'il rpond l'objectif (adquation), de vrifier la robustesse (fiabilit), de raliser des modifications (maintenabilit). Il s'en dduit une rduction globale du cot. - rutilisabilit: le logiciel est dvelopp sur la base de composants existants et son dveloppement conduit lui-mme des composants utilisables par d'autres. Le comportement des composants existants est bien connu (fiabilit). Ils sont bien documents (lisibilit) et conomiques puisqu'existants. 22.3.3. Principes A partir des 2 caractristiques ci-dessus, ABBOTT nonce 2 principes essentiels pour la conception du logiciel: - abstraction: l'abstraction consiste crer une reprsentation simplifie suffisante pour le problme d'une ralit plus complexe. L'abstraction conduit la conception de niveaux entre l'application et le support d'excution. Elle satisfait la fois la lisibilit et la rutilisabilit. - encapsulation: l'encapsulation consiste regrouper dans une mme unit (module, objet, ...) toutes les dcisions de conception et d'implantation pour une fonction donne. Par dfinition, un module constituant une entit logique possde en interne une forte cohsion et le couplage inter-modules est faible. De plus, les caractristiques internes ne sont pas visibles pour l'utilisateur. Le principe d'information cache (information hiding) est une autre manire d'exprimer l'encapsulation. Il y a bien ainsi sparation complte entre la spcification et l'implmentation. Abstraction et Encapsulation conduisent la MODULARITE. Un logiciel modulaire est dcompos en modules spcifiques, chacun offrant une fonctionnalit particulire. Une collection de modules permet de construire une abstraction. M.C.S.E 477

Partie 6 - REALISATION En dehors du terme module utilis depuis plusieurs dcades et donc ambig, d'autres appellations plus rcentes sont utilises de prfrence pour dsigner les entits rsultant de l'emploi des principes d'abstraction et d'encapsulation: - paquetage (package) dans ADA, - composant logiciel [ABBOTT-86, COX-85], - objet [BOOCH-83,86, ROSEN-87], dans SMALLTALK et les drivs. 22.4. TECHNIQUES POUR LINFORMATIQUE INDUSTRIELLE Aprs avoir prcis la dmarche de dveloppement et les principes, l'objectif est de dcrire les techniques disponibles pour le dveloppement du logiciel pour des applications temps-rel. Les spcifications du logiciel ont t dduites durant l'tape de dfinition de la ralisation. Elles sont composes du schma pour l'implantation logicielle et des spcifications de chaque constituant: tches et modules. Il s'agit donc de faire tat ici des mthodes et des techniques utilisables pour la ralisation logicielle afin daboutir au fonctionnement de l'application. Deux catgories de techniques sont considres: - les techniques qui permettent d'lever le niveau de fonctionnalits du support excutif. Ces techniques conduisent une rduction du temps de dveloppement. - les techniques qui favorisent la lisibilit et la rutilisation. Concernant les techniques amliorant le niveau de fonctionnalits, nous voquerons 3 catgories de solutions: - l'utilisation d'un excutif temps-rel, - l'utilisation d'un langage temps-rel (ADA et OCCAM), - l'emploi d'un ensemble de services conformes au modle fonctionnel. La figure suivante permet une comparaison des catgories de solutions:
1
Fonctionnel

Services fonctionnels

Langage T.R

Langage T.R

Excutif T.R

Excutif T.R

Excutif T.R

Support programmable

-Figure 22.3- Comparaison en cot de dveloppement pour 4 solutions. A partir du sommet qui reprsente la spcification pour le logiciel, le travail de dveloppement pour chaque application est reprsent par la zone grise. Pour une application donne, la solution 4 est a priori la plus intressante selon le critre du cot en temps de dveloppement. Toutefois, il ne faut pas conclure que c'est la seule raliste. Le tableau suivant permet de se faire une ide des diffrents cots et cas d'utilisation pour les 4 solutions. 478 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

Cot de dveloppement Solution 1 Solution 2 Solution 3 Solution 4 assez important moyen moyen assez faible

Cot de reproduction nul excutif excutif excutif+services

Catgories d'applications petites applications fortes contraintes moyennes moyennes et complexes moyennes et complexes

La solution 1 reste intressante lorsque le nombre de tches est faible. La technique d'implantation logicielle dcrite dans la partie 5 conduit un schma d'implantation sous interruption et tche de fond. Cette solution conduit aux meilleures performances temps-rel. La solution 2 s'utilise avec un langage standard C ou PASCAL. Elle se justifie pour une application compose de plusieurs dizaines de tches et plutt volutive. La solution 3 consiste utiliser directement la fois un langage et son excutif temps-rel. La solution 4 est identique la prcdente mais avec en plus un ensemble de services rutilisables conforme au modle fonctionnel. Les 4 solutions sont dtailles dans les paragraphes suivants. Concernant les techniques favorisant la lisibilit et la rutilisation, la technique la plus conventionnelle est celle de la programmation structure. Aujourd'hui bien connue, cette technique n'est pas assimiler au langage de la programmation structure (PASCAL, ADA). En effet, on peut crire un programme en PASCAL sans pour cela respecter les rgles de la programmation structure. Nous nous intresserons ici plus particulirement la programmation objet et orient objet. En particulier, il est intressant dobserver que la mthodologie MCSE favorise la mise en vidence des objets. La technique OBJET est ainsi prsente dans ce document comme une technique de ralisation trs favorable pour la rutilisation. 22.5. IMPLANTATION DIRECTE Un processeur programmable conventionnel ne sait excuter qu'une seule tche la fois. Sans logiciel complmentaire, seul le mcanisme d'interruption permet de drouter le processeur vers l'excution de tches plus prioritaires. La technique dcrite dans la partie 5 portant sur la dfinition de la ralisation permet, en utilisant uniquement le systme d'interruption, de faire voluer un ensemble de tches. La tche de fond joue le rle de moniteur pour le partage du processeur. Cette technique particulirement simple est efficace pour les performances car elle conduit aux temps de commutation les plus faibles. Elle n'est raliste que pour les applications ddies de faible complexit. Ceci reprsente toutefois probablement prs de 80% des dveloppements de systmes microprocesseurs. Cette tendance va continuer s'accrotre avec l'volution de la technologie et la rpartition des fonctionnalits. En effet, pour une application moyenne ou complexe, il peut tre prfrable d'utiliser plusieurs microprocesseurs plutt que de chercher tout regrouper sur un mme processeur plus puissant. M.C.S.E 479

Partie 6 - REALISATION Intressante connatre et maitriser car base sur des rgles d'implantation simples, la mthode prconise pour limplantation logicielle conduit une ralisation pour laquelle le cot de reproduction du logiciel est nul. Elle est particulirement approprie pour les applications base de microprocesseurs 8 et 16 bits et les microcontrleurs. De plus, elle conduit rduire au minimum la partie organisationnelle, rduisant ainsi le temps de dveloppement. 22.6. UTILISATION DUN EXECUTIF TEMPS-REEL Lorsqu'une application est plus consquente et ncessite de fonctionner sur un seul processeur programmable, il est alors plus judicieux d'utiliser un excutif temps-rel pour grer l'ordonnancement de toutes les tches. Cette solution est particulirement justifie lorsque l'application est volutive: volution de la solution fonctionnelle, ou lorsque des tches doivent tre cres dynamiquement. L'excutif temps-rel correspond une couche logicielle ajoute au processeur programmable pour permettre la gestion d'une application multi-tches [BEN-ARI-86]. A chaque tche est associe une priorit ou une date de fin d'excution (deadline). Un ordonnanceur se charge d'allouer le processeur la tche la plus prioritaire selon le critre d'ordonnancement utilis: priorit ou deadline. L'ordonnancement selon la priorit est la technique la plus conventionnelle. Les primitives minimales ncessaires pour l'implantation d'une description fonctionnelle sont les suivantes: - Signal(EV) et Wait(EV): pour la synchronisation par vnement. Toutes les tches en attente de EV sont actives ds la gnration de cet vnement par signal. - Alloc(V), Release(V): pour l'exclusion mutuelle sur la variable V. Ces 2 primitives permettent l'accs exclusif tout type de ressources. - Send(Mess, Port), Receive(Mess, port): pour l'change asynchrone de messages par une bote aux lettres appele port. - Start(tche, priorit), stop: pour la cration et l'activation, la destruction d'une tche. Tout moniteur temps-rel disponible sur le marche (PSOS, VRTX, noyau SCEPTRE, iRMX ...) possde toutes ces primitives. Elles sont utilisables partir d'un langage de hautniveau comme le C ou le PASCAL, par lien avec une librairie d'interfaage. D'autres primitives sont disponibles et qui peuvent faciliter l'implantation des tches: - activation priodique ou dlai pour attente, intressantes pour l'implantation de tches priodiques ou pour des temporisations, - attente d'un ensemble d'vnements. Ceci permet une implantation efficace de l'instruction WHEN, - utilisation de smaphores, - bote lettres disponibles pour une architecture multi-processeurs, - systme de gestion d'entres/sorties et de fichiers. L'emploi d'un moniteur industriel du march ncessite une licence qui augmente sensiblement le cot de reproduction de l'application. Aussi, n'est-il pas rare de rencontrer des industriels qui, pour ces raisons de cot, dveloppent un noyau d'excutif appropri leurs 480 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE applications. En effet, pour rduire le cot, un moniteur temps-rel avec les primitives de base peut se dvelopper rapidement. Dans ce cas, il est bon de savoir que seules 2 primitives sur smaphore: P(sem) et V(sem) sont suffisantes pour implanter les 3 types de relations du modle fonctionnel. Un smaphore est une variable compose d'une entre et d'une liste des tches en attente. Le lecteur est suppos familiaris avec ces concepts. Les primitives minimales pour les relations fonctionnelles s'implantent comme suit: - une synchronisation est assure par V(SEM_EV) pour le gnrateur et P(SEM_EV) pour le rcepteur. Le smaphore SEM_EV est initialis 0. Cette solution ne permet dactiver quune seule tche la fois. - une exclusion mutuelle est ralise par P(SEM_V) avant l'utilisation et V(SEM_V) aprs l'utilisation. Le smaphore SEM_V est initialis 1, degr de la ressource. - une bote lettres N places est ralise par une variable tampon gre en FIFO, et 2 smaphores: SEM_PLEIN initialis N et SEM_VIDE initialis 0. 22.7. UTILISATION DU LANGAGE ADA Le langage ADA n en 79-80, probablement le dernier langage impratif (ou procdural), rsulte d'une volont du Dpartement de la Dfense des Etats-Unis d'uniformiser les mthodes et outils pour le dveloppement des applications informatiques temps-rel. Ce langage est par nature multi-tches. D'autre part, il est particulirement orient programmation modulaire ou programmation objet. En effet, il favorise la sparation entre spcification et implmentation. Dans ce paragraphe, on se limitera considrer les aspects multi-tches du langage utiles pour l'implantation d'une description fonctionnelle. Le lecteur est suppos avoir une connaissance de base du langage [BOOCH-83, BUHR-84, NIELSEN88, ALSYS-83, etc ]. Une description en ADA est traduite par compilation en code excutable pour le processeur cible dsir. L'excution ncessite l'utilisation d'un excutif temps-rel comme "vhicule" d'excution gnralement fourni avec l'environnement de dveloppement. Compte-tenu de la richesse des mcanismes dans ADA, l'excutif temps-rel est consquent, et le compilateur et son environnement ncessitent un support de dveloppement du type super-microordinateur ou mini-ordinateur. Pour ces seules raisons, ce langage ne se justifie aujourd'hui que pour les applications de moyenne et forte complexit, ou lorsque la portabilit totale est une condition strictement ncessaire. Pour le temps-rel, la tche comme unit de base est syntaxiquement analogue au module aussi appel package. Des instructions permettent l'activation de tches en parallle avec la tche courante. L'achvement est li la tche elle-mme (fin de la description), mais peut aussi tre contrle par d'autres tches. Ces instructions sont: initiate Ti; et abort Ti;. Les relations entre tches sont toutes exprimes par un seul mcanisme appel mcanisme de rendez-vous. Ce mcanisme est dcrit succintement dans la suite pour constater son intrt mais aussi ses limites ou contraintes. 22.7.1. Le mcanisme de rendez-vous Les communications et synchronisations entre tches sont toutes ralises par un mcanisme unique bas sur la technique du rendez-vous. M.C.S.E 481

Partie 6 - REALISATION Le mcanisme est du type client/service. La tche cliente fait un appel sur une entre ou service de la tche correspondante, tandis que la tche comme serveur ralise une acceptation sur ses entres. Ce mcanisme est explicit par la figure ci-dessous pour 2 appels simultans 2 services diffrents mais exclusifs dun mme serveur.
serveur
T1 T0 loop select accept service1 do ... end or accept service2 do ... end end loop;

T0.service1

service1

client1
service2

T2

T0.service2

T2

T1

T0 attente service1 ou service2 T0.service1 accept service1

client2

T0.service2

excution

accept service2

excution

-Figure 22.4- Fonctionnement du mcanisme de rendez-vous. La spcification d'une entre (entry ou service) est syntaxiquement identique celle d'une procdure. Des paramtres peuvent passer entre les 2 tches en rendez-vous. Les paramtres d'entre sont passs de la tche appelante la tche appele au moment du rendez-vous. La tche appelante est suspendue pendant la dure d'excution du service client (entre do et end). Sur fin du service, les paramtres en retour sont transmis la tche appelante, le rendez-vous s'achve et les 2 tches poursuivent sparment leurs excutions. Pour qu'un rendez-vous s'effectue, il faut un appelant et un appel. Le premier demandant le rendez-vous est suspendu jusqu' l'arrive du correspondant. Le mcanisme du rendez-vous est asymtrique puisque seul le demandeur ou client dsigne son correspondant. Ce mcanisme est assez simple retenir, si on considre qu'un demandeur insre dans son droulement temporel au moment de l'appel d'un service, la squence d'instructions du service, sachant que cette squence se trouve excute par la tche appele. Ce mcanisme unique permet la fois la synchronisation puisqu'il tablit une relation d'ordre et une communication bi-directionnelle par le passage de paramtres durant l'appel et le retour du service. Une tche SERVEUR peut se mettre en attente de demandes sur plusieurs entres par l'instruction SELECT. Lorsque plusieurs demandes apparaissent simultanment, celles-ci sont excutes en squence. 482 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE C'est cette possibilit qui permet de dcrire des relations indirectes entre tches telles que celles du modle fonctionnel. A noter que l'instruction CYCLE sur plusieurs vnements s'implante directement par un select, accept sur ces vnements. 22.7.2. Implantation des relations du modle fonctionnel Pour illustrer les possibilits du langage ADA pour une application multi-tches, nous montrons ci-aprs les implantations possibles pour les 3 types de relations du modle fonctionnel que sont: synchronisation, partage de variables, port pour le transfert de messages. Les solutions proposes ne sont bien entendues pas les seules. Pour plus dinformation sur les techniques possibles consulter entre autres [BUHR-84, NIELSEN-88].
-A- SYNCHRONISATION DE 2 TACHES

La synchronisation peut s'exprimer de manire directe ou de manire indirecte. Dans le cas direct, le gnrateur dsigne son correspondant, tandis que dans le cas indirect les 2 tches synchroniser dsignent l'vnement intermdiaire implant obligatoirement comme une tche. L'implantation pour ces 2 cas est donne ci-aprs:
T1 T2
loop . . accept signal; . . end loop;

T2.signal

signal

task EV is new EVENEMENT; T1 EV

task type EVENEMENT is entry signal; entry wait; end EVENEMENT; task body EVENEMENT is ARRIVE : boolean := false; begin loop select accept signal; ARRIVE := true; or when ARRIVE => accept wait; ARRIVE := false; end select; end loop; end;

EV.signal

T2 signal EV.wait

wait

-Figure 22.5- Implantations pour la synchronisation. Dans le premier cas, le gnrateur peut se trouver bloqu en attente du rendez-vous (vnement sans mmoire), ce qui est probablement gnant pour une application temps-rel. Ce dfaut n'existe pas avec la deuxime solution. L'implantation ci-dessus n'assure l'veil que d'une seule tche. Pour tre conforme au modle fonctionnel, il faut veiller toutes les tches; ceci se fait en utilisant la variable COUNT associ l'entre WAIT qui indique le nombre de tches en attente.
-B- PARTAGE DUNE VARIABLE

La variable exploiter en exclusion mutuelle est encapsule dans une tche. 2 entres permettent l'accs pour la lecture et l'criture. On rejoint ici lapproche objet pour une donne. M.C.S.E 483

Partie 6 - REALISATION

task D is new VAR; T1 D

task type VAR is entry read(ELEM : out donne); entry write(ELEM : in donne); end VAR; task body VAR is DATA : donne; begin loop select accept read(ELEM : out donne) do ELEM := DATA; end read; or accept write(ELEM : in donne) do DATA := ELEM; end write; end select; end loop; end VAR;

D.read(V);

T2 read D.write(N);

write

-Figure 22.6- Implantation d'une variable partage.

-C- TRANSFERT DE MESSAGE PAR UN BUFFER

Comme pour la variable partage, la variable BUFFER est encapsule dans une tche. 2 entres SEND et RECEIVE permettent de dposer et d'extraire un message. Comme la taille du tampon est limite, des conditions comme "gardes" prcdent les acceptations.
task M is new PORT; T1 M
task type PORT is entry send(INPORT : in message); entry receive(OUTPORT : out message);

M.send(D);

T2

send

M.receive(V); receive

task body PORT is BUFFER : array[1..SIZE] of message; NEXTIN,NEXTOUT : integer range 1..SIZE := 1; COUNT : integer range 0..SIZE := 0; begin loop select when COUNT < SIZE => accept send(INPORT : in message) do BUFFER(NEXTIN) := INPORT; end send; NEXTIN := NEXTIN mod SIZE +1; COUNT := COUNT+1; or when COUNT >0 => accept receive(OUTPORT : out message) do OUTPORT := BUFFER(NEXTOUT); end receive; NEXTOUT := NEXTOUT mod SIZE +1; COUNT := COUNT-1; end select; end loop; end PORT;

-Figure 22.7- Implantation dun port. 22.7.3. Interruptions et exceptions Des interruptions externes sont gres simplement car interprtes comme des appels externes. Il suffit donc de dclarer une tche avec linterruption comme point dentre. L'exemple suivant illustre la simplicit du mcanisme. 484 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

for IT use at 4; - - - - - - - - - - -> accept IT;

Le mcanisme d'exception a t implant dans le langage ADA pour traiter efficacement les cas d'erreurs. Une exception assure une relation d'ordre entre un gnrateur de l'exception sur dtection d'une condition particulire et la tche ou procdure charge de traiter l'exception. L'criture est la suivante:
Task body T1 is begin raise T2.FAILURE; --Task body T2 is begin --exception when FAILURE ==> end;

end;

22.8. UTILISATION DU LANGAGE OCCAM ET DU TRANSPUTER Le transputer d'INMOS fait partie de la nouvelle gnration des microprocesseurs. Btie sur une architecture RISC, sa performance (10 MIPS et 1,5 MFLOPS pour le T800) et sa simplicit d'interconnexion pour construire une architecture fort degr de paralllisme font de ce processeur l'un des composants essentiels du futur. Il a t qualifi par ses concepteurs comme le "transistor" de l'an 2000 pour linformatique. Pour les applications temps-rel, le transputer est intressant pour au moins 4 raisons: - ses performances sont intressantes pour des applications fortes contraintes de temps. - fonctionnellement et grce son jeu d'instructions, il sait grer une application multitches. Les temps de commutation entre tches sont trs faibles. Le processeur dispose d'un mcanisme unique de rendez-vous par canal pour les synchronisations et transferts de donnes. - comme composant du type monochip, il est simple monter pour raliser des cartes. Il dispose en interne des fonctionnalits essentielles: RAM, timers, canaux DMA, liens srie. Ses 4 liens d'change avec son environnement permettent de construire aisment des structures mailles. - comme outil de programmation, le langage OCCAM est trs simple, proche du PASCAL pour le squentiel, tout en permettant une description naturelle avec paralllisme du comportement souhait aussi bien pour un transputer que pour un rseau de transputers. Dans ce paragraphe, on s'attachera montrer le mcanisme d'change par canal utilisable pour l'implantation d'une description fonctionnelle. Il ne s'agit donc pas d'une prsentation de OCCAM avec comme objectif la matrise du langage. Tout lecteur intress peut se reporter aux ouvrages et articles sur le sujet [INMOS-86, CARLING-88, JONES-88]. 22.8.1. Le mcanisme d'change par canal OCCAM a repris les principes de communication prconiss par HOARE dans "Communicating Sequential Processes" (CSP) [HOARE-78]. M.C.S.E 485

Partie 6 - REALISATION Dans OCCAM, une tche se dclare aussi facilement qu'une instruction. En effet, l'instruction:
PAR inst1 inst2

indique l'excution simultane des 2 instructions. Chaque instruction peut elle-mme tre excution squentielle SEQ ou excution parallle PAR. Chaque instruction lmentaire est: soit une assignation, soit une entre, soit une sortie. Une entre permet de recevoir une valeur en provenance d'un canal (channel). Une sortie transmet une valeur un canal. Ainsi toute transmission entre tches se fait uniquement par canal. La communication entre 2 tches par canal est synchrone. L'change de donne ne se fait que lorsque les 2 tches (metteur, rcepteur) sont prtes communiquer par le mme canal. Ainsi, la premire tche dsignant le canal est suspendue jusqu' la sollicitation par le correspondant. Il s'agit d'un mcanisme de rendez-vous. A l'instant du rendez-vous, la valeur de la variable cot producteur est copie dans la variable cot consommateur. Les 2 tches continuent ensuite sparment leurs droulements. La notation utilise dans OCCAM pour dcrire des changes est la suivante pour 3 tches dpendantes. T2 recoit dans Y la valeur de la variable X
T1 T2 T3

INT X: SEQ chan1 ! X

chan1

INT Y: SEQ chan1 ? Y chan2 ! Y*Y

chan2

INT Z: SEQ chan2 ? Z

-Figure 22.8- Echange entre tches par canaux. Il s'agit l d'une communication unidirectionnelle. La notation graphique utilise ci-dessus indique le sens de chaque communication. Ce mme mcanisme est utilisable pour programmer un rseau de processeurs. Chaque couplage toujours assur par un canal entre tches places sur des processeurs diffrents, est alors ralis par un canal physique utilisant les liens sries des transputers. Ainsi, une application peut tout d'abord se dvelopper sur un seul transputer. Ensuite, par simple modification de la configuration (rpartition des tches et dfinition des adresses des canaux), la mme application est excutable sur un rseau de transputers. Le mcanisme de communication par canal est proche du mcanisme de rendez-vous de ADA. Ce dernier a en effet t inspir de CSP. Toutefois, si dans ADA, seul le client dsigne le serveur (dsignation unidirectionnelle), dans OCCAM, les 2 tches communicantes dsignent l'lment de lien. Un canal diffre aussi de la notion de Port. En effet, un port est une bote aux lettres servant de tampon entre tches asynchrones. Possdant une ou plusieurs places, il assure un effet mmoire. Un canal par contre est sans effet mmoire. Il n'y a pas de dpt ni de retrait dans le canal, il y a transfert direct entre tches. Le canal ne sert donc que pour dfinir la relation. 486 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE La figure suivante illustre la diffrence entre les 2 mcanismes.
T1 send T2 Port receive chan T1 T2

T1
M1 send

port

T2

T1
M1

canal

T2

dpt
receive M1

retrait

attente ! rendez-vous

M1 ?

attente
M2 send

receive ? attente rendez-vous ! M2

dpt

retrait

M2

-Figure 22.9- Comportement pour l'change par port et par canal. Dans le transputer un canal particulier est ddi l'horloge temps-rel. Ainsi, il est trs simple de raliser des attentes sur date ou sur dlai. Le rendez-vous s'effectue la date souhaite ou aprs le dlai coul. Comme autre particularit de OCCAM, une tche peut se mettre en attente simultanment sur plusieurs canaux par linstruction ALT. Dans ce cas, le premier rendez-vous est pris en compte. Cette possibilit permet une implantation directe des instructions CYCLE et WHEN du modle fonctionnel. 22.8.2. Implantation des relations du modle fonctionnel Comme pour le langage ADA, nous montrons dans ce paragraphe comment le langage OCCAM est utilisable pour limplantation des relations de synchronisation, de partage de variables et de transfert de messages du modle fonctionnel. Cette prsentation succinte permet de se faire une ide du langage OCCAM et des mcanismes de communication. Une restriction importante provient du fait quun canal ne peut servir quentre 2 tches: un seul producteur, un seul consommateur.
-A- SYNCHRONISATION DE 2 TACHES

Dans le modle fonctionnel, l'vnement est effet mmoire. Ainsi, la tche gnratrice n'est jamais en attente du correspondant, ce qui est essentiel pour une signalisation en tempsrel. Pour cette raison, avec le transputer, un lment supplmentaire qui ne peut tre qu'une tche en OCCAM est ncessaire comme intermdiaire entre le gnrateur et le rcepteur. 2 canaux sont donc ncessaires pour une synchronisation entre chaque couple de tches. La M.C.S.E 487

Partie 6 - REALISATION solution apparat plutt complexe; la variable ARRIVE sert implanter la mmorisation de lvnement. La structure ALT permet la tche EV dtre lcoute des deux tches synchroniser. La communication avec T2 ne peut se faire que lorsque ARRIVE=vrai.
Tche de gestion EV T1
CHAN OF BOOL S.EV, W.EV: BOOL arriv, any: SEQ arriv := FALSE WHILE TRUE ALT S.EV ? any arriv := TRUE arriv & W.EV ? any arriv := FALSE

T2

S.EV S.EV ! any

W.EV W.EV ! any

-Figure 22.10- Synchronisation entre T1 et T2 par un vnement.

-B- PARTAGE DUNE VARIABLE

En OCCAM, une variable partage est une variable globale qui doit tre accessible par plusieurs tches. Toutefois pour respecter les contraintes d'intgrit, ce type de variable doit tre considr comme une ressource critique. La solution consiste associer un smaphore la variable. Une implantation des 2 primitives P et V sur smaphore permettent alors l'allocation et la libration de la section critique. Une solution possible est la suivante.
Tche gestion variable V Ti VAL INT size IS 20: INT v, val: [size] CHAN OF BOOL PSEM.V, VSEM.V: BOOL any: SEQ WHILE TRUE ALT i=0 FOR size PSEM.V[i] ? any VSEM.V[i] ? any Tj SEQ PSEM.V[j] ! any donne := v VSEM.V[j] ! any

SEQ PSEM.V[i] ! any v := data VSEM.V[i] ! any

PSEM.V[i]

PSEM.V[j] VSEM.V[j]

VSEM.V[i]

-Figure 22.11- Partage dune variable avec exclusion mutuelle. Avec cette solution plusieurs tches peuvent se partager la mme variable V. Une autre solution consiste placer la variable partage V dans une tche charge dassurer sa gestion. Les tches utilisatrices sollicitent alors cette tche pour disposer de la valeur ou pour sa mise jour. Une telle solution est proche de celle dcrite ci-aprs pour les messages.
-C- UTILISATION DUN PORT POUR LE TRANSFERT DE MESSAGES

Le port s'implante comme une bote lettres N places. La zone pour la mmorisation des donnes est une variable globale gre comme un tampon circulaire. 2 indicateurs sont ncessaires: DEBUT dfinissant le premier message dpos, et FIN dsignant la premire place libre. L'change entre les 2 tches producteur et consommateur se ralise par l'intermdiaire de 3 canaux comme l'indique la solution suivante. 488 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

gestion port T1 CHAN OF INT dpt, demande, retrait: [taille] INT boite: INT fin, dbut : BOOL any: SEQ fin := 0 dbut := 0 WHILE TRUE ALT fin <> ((dbut - 1) REM taille) & dpt ? boite[fin] fin := (fin+1) mod taille dbut <> fin & demande ? any retrait ! boite[dbut] dbut := (dbut + 1) REM taille T2 INT r: Demande SEQ demande ! any retrait ? r

INT m : SEQ dpt ! m

Dpt

Retrait

Dbut

Fin

-Figure 22.12- Transfert de messages par un port. Le consommateur signale par le canal "Demande" son souhait de recevoir un message. La rponse lui revient par l'autre canal "Retrait". Un port implant comme ci-dessus nest exploitable quentre un producteur et un consommateur du fait de la restriction dun canal comme lien entre seulement 2 tches. Pour tendre la possibilit daccs pour N producteurs, il faut utiliser N canaux Dpot et utiliser en interne une structure ALT sur tous les canaux. Le dveloppement de mcanismes gnraux conformes aux modle fonctionnel pose donc quelques difficults. En supplment, le nombre de priorits du transputer limit 2 est aussi une restriction qui conduit la difficult de prdire les dates de fin dexcution des tches soumises des contraintes de temps. Des prcautions sont donc prendre pour aboutir une implantation correcte et efficace. La disponibilit dun compilateur ADA pour le transputer est peut-tre une rponse possible ces difficults. 22.9. SERVICES POUR LE MODELE FONCTIONNEL Pour les applications moyennes et complexes, la disponibilit d'un niveau de fonctionnalits dvelopp une fois pour toutes permet de faciliter l'implantation d'une application spcifie par sa description fonctionnelle. Pour les 2 techniques prcdentes: utilisation directe de ADA ou de OCCAM, l'implantation d'une application ncessite une connaissance assez approfondie du langage et tout particulirement des mcanismes de synchronisation et de communication par rendezvous. La prsentation faite dans ce chapitre a pour simple objectif une prise de connaissance de ces mcanismes. Toutefois, pour viter de devoir adapter la description fonctionnelle aux mcanismes (implantation selon une dmarche descendante jusqu'aux moyens du support) et ceci pour chaque application, il est prfrable de disposer une fois pour toutes des services utiles pour le M.C.S.E 489

Partie 6 - REALISATION modle fonctionnel. Ces services regroups dans une librairie seraient alors accessibles sous la forme de procdures ou de tches gnriques. Les quelques procdures utiles sont les suivantes: - Signal(EV) et Wait(EV) pour la synchronisation, - Read(data:def_V,V), Write(data:def_V,V) pour l'accs la variable partage V, - Send(message:def_mess, port), Receive(message:def_mess, port) pour l'accs un port. Comme montr dans les paragraphes prcdents, ces procdures utilisent des objets comme tches serveurs: vnement, variable, bote lettres. Ces objets sont crer en fonction des besoins. Les procdures suivantes serviraient crer et initialiser chaque instance. - init_ev (ev); - init_var (V: type_V); - init_port (port: type_mess; taille: integer); Ces procdures une fois construites sur ADA ou sur OCCAM sont alors utilisables comme primitives d'un moniteur temps-rel. La portabilit sur divers excutifs temps-rel est relativement simple et automatique. Toutes les possibilits du modle fonctionnel ne sont pas implantables par ces services. En particulier, la traduction des instructions: CYCLE et WHEN avec attente sur plusieurs vnements ou messages n'est pas directe. Pour une attente sur un seul vnement ou message, la traduction est immdiate en utilisant Wait ou Receive. Pour une attente multiple, nous citerons 2 solutions possibles pour l'implantation: - traduction de la tche incluant le cycle ou le when, en autant de tches que d'attentes voulues. Les tches doivent alors tre excutes en exclusion mutuelle pour rester conforme au modle fonctionnel. Cette technique est indique ci-dessous.
package body T is Sem_T : semaphore task body I1 is . . loop wait(H); P(sem_T); T1; V(sem_T); end loop; end I1 task body I2 is . . loop receive(M,MESS); P(sem_T); T2; V(sem_T); end loop; end I2;

action T .... ; begin cycle H: T1; MESS : T2; end cycle; end;

490

M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE - utilisation directe des instructions d'attente multiple du langage ADA ou dOCCAM. Plus efficace, cette solution ncessite alors une bonne connaissance des mcanismes multi-tches.Les instructions T1 et T2 sont excutes en exclusion mutuelle gre par le smaphore SEM_T. Quelle solution faut-il utiliser? Cela dpend de la connaissance du langage et des performances souhaites. A noter, toutefois que ce type d'implantation avec attente multiple reprsente une part trs faible des cas. 22.10. REALISATION ORIENTEE OBJET La programmation structure est la mthode la plus conventionnelle pour la maitrise de problmes complexes. En tant que mthodologie, elle favorise le dcoupage du problme en sous-problmes: un programme est constitu d'une suite de modules lmentaires, chaque module est ensuite raffin jusqu' obtenir des actions simples qui s'crivent directement dans le langage de programmation choisi. Le PASCAL est l'exemple type du langage compatible avec les principes de la programmation structure. Selon cette approche, chaque module est dvelopp spcifiquement pour satisfaire les exigences du niveau suprieur. L'architecture du programme qui en dcoule est trs monolithique, semblable un puzzle o chaque morceau est destin rentrer un endroit prcis pour lequel il a t conu [ROSEN-87]. En consquence, la rutilisation s'avre difficile ainsi que la maintenabilit pour rpondre des exigences de modification ou d'volution des fonctionnalits. D'autre part, la programmation structure suppose l'ordonnancement squentiel des actions. La description pour des systmes avec paralllisme ne s'avre donc pas simple. Pour rpondre aux 2 principes: ABSTRACTION et ENCAPSULATION cits en dbut du chapitre et qui permettent de satisfaire les critres de qualit souhaits pour le logiciel, de nombreux auteurs s'accordent considrer l'OBJET comme l'lment de base le plus appropri [ABBOTT-85, BOOCH-83,86,87, COX-85, ROSEN-87]. Une prsentation du concept OBJET et des mthodologies a t faite dans le chapitre 7 (cf 7.11). On se contente ici de rappeler les catgories dobjets pour montrer ensuite comment la mthodologie MCSE conduit mettre en vidence les objets de lapplication. 22.10.1. Catgories d'objets Les objets peuvent se classer selon la nature de la composition qui en rsulte ou selon le rle jou par chacun. L'association d'objets peut se faire: - selon une composition horizontale: un objet assure un rle fonctionnel dans la chane de transformation des entres vers les sorties. - selon une composition verticale: un objet sollicite des services auprs d'objets de niveaux plus lmentaires. Chaque couche de services constitue un niveau d'abstraction. Si on s'intresse au rle jou, les objets peuvent tre classs en 4 catgories [ABBOTT-85, BOOCH-83] - type abstrait de donnes: ce type d'objet dfinit les variables du problme. Il s'agit d'un objet statique utilisable pour: les types de donnes, les structures de donnes, les units de mmorisation tels que les fichiers et les bases de donnes. M.C.S.E 491

Partie 6 - REALISATION - type service (ou opration): ces objets mettent disposition d'un niveau suprieur d'abstraction les fonctions ou oprations ncessaires. Ils peuvent solliciter des services d'un niveau infrieur. - type agent (ou transducteur): un tel objet assure la transformation de donnes. Acceptant une donne en entre, le rsultat est transmis par une de ses sorties. - type acteur (ou driver): ces objets ont une autonomie propre et contrlent l'activit des autres objets. Les 4 types d'objets sont reprsents ci-dessous compte-tenu de leurs rles respectifs avec une notation spcifique permettant de reconnaitre le type de lobjet.
Composition horizontale Acteur

Composition verticale

agent 1

agent 2

service 1

donne 1

-Figure 22.13- Reprsentation des 4 catgories d'objets. On constate sur cette figure les 2 axes de composition pour les objets: vertical selon une hirarchie de services et horizontal selon une chane d'agents. L'acteur ne possde que des sorties, agents et services sont sollicits et sollicitent, l'objet donnes n'est que sollicit. 22.10.2. MCSE et la conception oriente objet Il s'avre que face un problme de dimension raliste, les dmarches actuelles typiquement objet (cf 7.11) ont une efficacit limite du fait de l'absence d'un outil puissant qui conduit par une dcomposition du problme la construction des objets et de l'architecture du systme [ROTENSTREICH-86]. Cherchant utiliser la programmation par objets, le concepteur se trouve partag entre 2 approches extrmes. 492 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE - celle qui consiste invoquer trs rapidement le concept d'objet en effectuant une modlisation de la ralit du problme. Les objets ainsi mis en vidence sont ensuite spcifis par enrichissement progressif [BOOCH-86]. - l'exploitation d'une mthodologie existante de manire suivre une dmarche descendante jusqu' l'identification des objets et relations entre ceux-ci [ABBOTT-85, NIELSEN-88]. La premire approche, tendance naturelle qui reflte le dsir d'entreprendre rapidement une ralisation (cas du prototypage par exemple), conduit construire la solution selon une approche incrmentale, peut-tre plutt intuitive. La construction directe ascendante ne garantit pas de converger efficacement vers l'objectif du problme. Le deuxime point de vue considre que la conception se fait selon une dmarche descendante qui favorise une structuration en niveaux d'abstraction. Pour chaque niveau, la dmarche fait apparatre les entits et les relations ncessaires entre elles. Pour tendre rapidement vers une implmentation OBJET, le modle de dcomposition doit favoriser cette convergence. Comme exemple, la mthode JSD de JACKSON, base sur une modlisation des donnes puis sur une conception base sur un rseau de processus apparat comme particulirement favorable pour la programmation objet. Les mthodologies SDWMC, DARTS et tout particulirement ADM de NIELSEN et SHUMATE (voir chapitre 7) sont des exemples illustrant bien ce point de vue. Lorsque les langages permettent une description multi-tches ou multi-objets, il apparait toutefois pas vident de savoir quand utiliser des tches et des objets au lieu de procdures [D. JONES-89]. Une approche tches peut conduire une complexit suprieure de la solution. D. JONES indique en particulier que lorsquun problme pouvant se rsoudre par une seule tche est spcifi par un diagramme flot de donnes, la solution conduit un ensemble de tches plutt maladroitement couples entre elles. Comme critre, il prconise de distinguer les problmes dterministes des problmes non-dterministes, seuls ces derniers ncessitent lutilisation de tches. On montre dans la suite que la dmarche MCSE est utilisable en amont pour lidentification et la structuration des objets et des tches dune application temps-rel. 22.10.3. MCSE pour lidentification des objets MCSE est une dmarche de spcification et de conception descendante. La dfinition de la ralisation conduit une partition de la solution en un ensemble matriel et un ensemble logiciel. Un schma d'implantation logicielle spcifie l'organisation de tous les modules logiciels. La ralisation du logiciel peut se faire d'une manire conventionnelle selon la programmation structure. Mais est-il possible aussi de dduire une ralisation oriente objet, et partir de quel stade? Pour y rpondre, considrons le schma d'implantation logicielle reprsent sur la figure 22.14. Il s'agit de la solution retenue pour l'exemple du contrle en vitesse d'un centrifugeur (voir 19.7.2). En se basant sur les catgories d'objets cits prcdemment, on constate cette figure plusieurs types de tches: - gestion dialogue, diviseur, calcul vitesse sont des drivers, - gestion centrifugeur est un service ou un agent, - commande et Asservissement_vitesse est un service, voire un agent. M.C.S.E 493

Partie 6 - REALISATION
Priorit
INC nbH Calcul vitesse Vmoteur CV Commande vitesse Asservissement vitesse ROTATION

Priorit

Vconsigne

Hpriode Diviseur

M/A

CROTATION

ETAT

Gestion centrifugeur ORDRE VROTATION Gestion dialogue

Matriel

Entres

Logiciel

Sorties

Matriel

-Figure 22.14- Exemple de schma d'implantation logicielle. De plus, des variables servent de couplage: Vmoteur et lensemble (M/A, ETAT, CROTATION). Comme tout doit tre objet, ces variables sont encapsuler comme objet donnes. En adoptant la notation objet indique figure 12.13 pour chaque catgorie, le schma d'implantation se transforme directement comme indiqu par la figure 22.15. Pour chaque objet, les liens du schma dimplantation logicielle dfinissent les entres ou mthodes ncessaires. Les liens entrants correspondent aux mthodes que doit offrir l'objet dsign. Les liens sortants dsignent les actions sollicites auprs d'autres objets. L'objet du type structure de donnes est un objet passif. Il assure la rsolution des conflits et le respect de la cohrence. Les objets du type acteur servent engendrer l'volution. Ces objets sont obligatoirement implants comme des tches cycliques, voluant en permanence, ou sous interruption. Les objets du type agent et serveur sont en gnral implants comme des tches. Ils sont sollicits par un agent ou un acteur. Gestion_centrifugeur, appel par un seul acteur est implantable comme une procdure. Une autre solution plus optimise peut aussi se dduire. Le point de vue adopt consiste intgrer les donnes partages dans les objets producteurs. Les consultants sollicitent alors lobjet contenant la donne par un point dentre. Cette solution est plus optimise car elle rduit le nombre de tches de lapplication rduisant ainsi la complexit tout en amliorant les performances. Pour montrer lefficacit de cette dmarche, on donne ci-dessous une description partielle du programme ADA qui dcoule directement du schma dimplantation avec optimisation. On donne tout dabord la description de lobjet CALCUL_VITESSE dclar comme un package gnrique, permettant ainsi de spcifier le domaine de dfinition de la variable VITESSE. 494 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

SOLUTION DIRECTE
INC calcul vitesse

SOLUTION OPTIMISEE

V_Moteur write read calcul vitesse

V_Moteur Hpriode Diviseur pas Comm. et Asserv. vitesse read

Diviseur Cmd_moteur tat cmd M/A ETAT CROTATION

Comm. et Asserv. vitesse pas tat cmd M/A ETAT CROTATION

gestion dialogue ordre

gestion centrifugeur

gestion dialogue

gestion centrifugeur ordre

-Figure 22.15- Implantation oriente objet.

with ADDRESSES; use ADDRESSES; with TYPES; use TYPES; generic MAX_NBH : in UNSIGNED_NATURAL; package CALCUL_VITESSE is procedure READ(VITESSE : out natural); end CALCUL_VITESSE; package body CALCUL_VITESSE is subtype DEF_NBH is UNSIGNED_NATURAL range 0..MAX_NBH; task TSK_CALCUL_VITESSE is entry READ(VITESSE : out DEF_VITESSE); entry EVENT; --for EVENT use at TIMER_VITESSE; end TSK_CALCUL_VITESSE; task body TSK_CALCUL_VITESSE is VIT : DEF_VITESSE := 0; begin loop select accept READ(VITESSE : out DEF_VITESSE) do VITESSE := VIT; end READ; or accept EVENT do -- calcul de la vitesse end EVENT; end select; end loop; end TSK_CALCUL_VITESSE;

M.C.S.E

495

Partie 6 - REALISATION
procedure READ(VITESSE : out natural) is begin TSK_CALCUL_VITESSE.READ(VITESSE); end; end CALCUL_VITESSE;

Lapplication comprend GESTION_DIALOGUE comme tche de fond. Les objets GESTION_CENTRIFUGEUR et COMM_ASS_VIT sont des tches. COMM_ASS_VIT gnre une instance de CALCUL_VITESSE. La description de DIVISEUR qui est un package gnrique comme CALCUL_VITESSE, nest pas donne ainsi que les dclarations de types et dadresses et les corps des procdures et tches.
with with with with TYPES; use TYPES; ADDRESSES; use ADDRESSES; DIVISEUR; CALCUL_VITESSE;

procedure GESTION_DIALOGUE is package CALC_VITESSE is new CALCUL_VITESSE (MAX_NBH => 65535); task COMM_ASS_VIT is entry PAS; entry ETAT(ETAT : out ON_OFF); entry CMD(CMD : in DEF_CMD); end COMM_ASS_VIT; task body COMM_ASS_VIT is V : DEF_VITESSE; begin loop select accept PAS do CALC_VITESSE.READ(V); -- reste de lasservissement end PAS; or accept ETAT(ETAT : out ON_OFF) do -- ....; end ETAT; or accept CMD(CMD : in DEF_CMD) do -- ....; end CMD; end select; end loop; end COMM_ASS_VIT; package DIV is new DIVISEUR (MAX_DIV => 5, EVENEMENT => COMM_ASS_VIT.PAS); task GESTION_CENTRIFUGEUR is entry ORDRE(ORDRE : in DEF_ORDRE); end GESTION_CENTRIFUGEUR; task body GESTION_CENTRIFUGEUR is ETAT : ON_OFF; CMD : DEF_CMD;

496

M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

begin loop select accept ORDRE(ORDRE : in DEF_ORDRE) do -- .... COMM_ASS_VIT.ETAT(ETAT); -- .... COMM_ASS_VIT.CMD(CMD); -- .... end ORDRE; end select; end loop; end GESTION_CENTRIFUGEUR; begin loop --scrutation des touches COMM_ASS_VIT.ETAT(ETAT); --modification consigne / affichage V_ROTATION -- .... GESTION_CENTRIFUGEUR.ORDRE(ORDRE); end loop; end GESTION_DIALOGUE;

Comme vient de le montrer lexemple prcdent, une fois un tel schma d'implantation orient objet dfini, la mthode prconise par BOOCH s'applique intgralement pour dfinir les oprations, la visibilit, l'interface et l'implmentation de chaque objet. La notation graphique utilise est spcifique. Ceci est volontaire, vitant ainsi de prendre position pour lune parmi celles prconises par les spcialistes de lapproche objet. Tout autre notation -diagramme de BOOCH, diagramme de BUHR- est bien entendu directement utilisable. Il est par exemple tout fait concevable dutiliser la dmarche MCSE pour dduire les diagrammes Machine Charts de BUHR pour ensuite exploiter les outils de CAO dvelopps pour cette mthodologie. Ainsi, cet exemple simple montre bien que la dmarche prconise dans MCSE favorise aussi une conception oriente objet. En effet, MCSE rpond la question essentielle d'identification des objets, puisque le schma d'implantation logicielle exprime la spcification des objets selon les 4 catgories. D'autre part, la programmation objet est bien considrer comme une technique de ralisation. 22.10.4. Structuration avec la programmation objet Aprs la phase descendante de conception, la ralisation s'obtient selon une construction ascendante. Il est intressant de voir comment la programmation objet permet de conserver la structure trouve en conception. Considrons une fonction simple du type agent selon les 2 dimensions suggres par ROSENTREICH. Une telle fonction peut se considrer: - pour la dimension horizontale, comme une fonction de transformation de donnes, - pour la dimension verticale, comme une fonction d'adaptation entre niveaux d'abstraction (relation client-serveur). On dtaille ci-aprs quelques rgles de traduction objet pour ces 2 cas. M.C.S.E 497

Partie 6 - REALISATION
-A- STRUCTURATION HORIZONTALE

La fonction F considre comme exemple est active par un vnement ou une rception de message dans PORT et se charge d'valuer et de mettre jour une grandeur caractristique V.
FONCTION F

D1 port

D2 V

objet D1
LECTURE

objet Traducteur
MISE A JOUR

objet D2

-Figure 22.16- Fonction de transformation dans un flot de donnes. La sollicitation de la fonction conduit exploiter la ou les donnes d'entre, puis par des traductions successives, produit les donnes en sortie. Pour l'implantation objet, la fonction F est dcomposable en: - 2 parties lmentaires pour l'accs aux donnes. Ces parties sont des procdures propres aux objets D1 et D2 qui encapsulent les donnes d'entre et de sortie. - une partie centrale, implante comme objet agent ou traducteur, lui-mme dcomposable en objets plus lmentaires, chacun ralisant un stade de transformation. La structure est du type flot de donnes et pipe-line. La construction suit le flux d'volution des donnes induit par la dmarche de conception. Chaque objet peut tre une tche ou une procdure.
-B- STRUCTURATION VERTICALE

Pour illustrer l'implantation pour une structuration verticale, prenons comme exemple une relation du type client/serveur, par exemple pour le transfert d'informations entre F1 et F2 par port avec rpartition gographique comme le montre la figure 22.17. Le port du niveau applicatif est globalement implant par l'objet O1 en tant qu'objet abstrait rparti sur les 2 sites. En interne O1 est compos des 2 objets O11 et O12, eux-mmes faisant appel au service communication implant par l'objet O13. Cet objet est aussi dcomposable en objets plus lmentaires jusqu'au support physique. Ainsi, la structuration verticale est conserve en construisant la ralisation comme un embotement d'objets. Les objets dvelopps ont lavantage dtre directement rutilisables pour d'autres applications. 498 M.C.S.E

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

Service transfert message

F1 Dpt Retrait

F2

0F1 P1 011 P2 012

0F2

Service message
Emission Rception

Service ligne

TxD

0131 01 013

-Figure 22.17- Transit dinformation entre niveaux dabstraction. 22.11. RESUME Ce dernier chapitre sur la ralisation a permis de prciser la varit des techniques et des mthodes utilisables pour la ralisation logicielle. L'objectif tait de faire connatre aux concepteurs en Informatique Industrielle les critres, principes et techniques du Gnie Logiciel. Pour combler le foss entre la fonctionnalit de l'application et le support d'excution, plusieurs dmarches sont possibles, mais plus long terme, il savre intressant d'augmenter le niveau fonctionnel du support matriel. Pour cela, une des dmarches les plus prometteuses consiste en la rutilisation sur la base de ralisations orientes objet. Ce chapitre a permis de montrer que la mthodologie MCSE se situe en amont des techniques de ralisation et favorise le choix de la technique la plus approprie mettre en oeuvre conformment aux contraintes de ralisation imposes. Les points essentiels du chapitre sont les suivants: - Les dveloppements en logiciel doivent suivre la dmarche dj suivie pour le matriel, ceci par la rutilisation de composants standardiss. Non obligatoire en logiciel, un tel rsultat ne peut tre que le fruit d'une attitude volontariste. - Pour satisfaire les caractristiques de lisibilit et de rutilisabilit, le dveloppement du logiciel doit au moins respecter les 2 principes: abstraction et encapsulation. - Parmi les techniques possibles, le choix dpend de la complexit de l'application: implantation directe pour de petites applications, utilisation d'un excutif temps-rel ou d'un langage temps-rel tel que ADA pour les applications plus complexes. - Favorable pour la rutilisation, la technique de ralisation oriente objet est possible avec les langages actuels tel que ADA. La difficult de la mthode pour induire les objets concerne lidentification de ceux-ci. M.C.S.E 499

Partie 6 - REALISATION - La mthodologie MCSE permet, aprs la dfinition de la ralisation logicielle, la mise en vidence directe des objets de l'application. Ainsi, la programmation objet se rvle un outil adapt comme technique d'implantation ascendante. Elle conduit conserver la lisibilit et la structuration de la conception. - La rutilisation est favorise par cette dmarche: en conception le raffinement s'arrte ds la mise en vidence d'objets existants. De mme, la programmation engendre de nouveaux objets abstraits pour les applications futures. - Plus gnralement, pour l'Informatique Industrielle, la programmation objet apporte une autre manire de dvelopper les ralisations, qui favorise la rduction des dveloppements par la rutilisation, qui engendre la modularit et donc la sret des systmes, qui augmente la lisibilit et donc la maintenabilit. Cette technique d'implantation vite de devoir descendre un niveau de dtails opratoires, tout comme les langages de haut-niveau ont permis de faire un pas vers l'abstraction par rapport la programmation du type assembleur.

500

M.C.S.E

BIBLIOGRAPHIE 6

[ABBOTT-86] An integrated approach to software development R.J. ABBOTT WILEY Interscience publication John Wiley & Sons 1986 [ALSYS-83] Reference manual for the ADA programming language ALSYS Janvier 1983 [AMGHAR-89] Mthodes de dveloppement dun systme microprocesseurs A. AMGHAR MASSON, collections manuels informatiques 1989 [BEN-ARI-86] Processus concurrents: introduction la programmation parallle M. BEN-ARI MASSON collection manuels informatiques 1986 [BOOCH-83] Software Engineering with ADA G. BOOCH Benjamin/Cummings, Menlo Park, CA 1983 [BOOCH-86] Object-oriented Development G. BOOCH IEEE Transactions on Software Engineering vol SE-12 fev 1986, P.211-221 [BOOCH-87] Composants logiciels rutilisables G. BOOCH Gnie Logiciel N9 Novembre 1987, P.22-26 M.C.S.E 501

Partie 6 - REALISATION [BUHR-84] System Design with ADA R.J.A. BUHR Prentice-Hall Inc, Englewood Cliffs N.J., 1984 [CALVEZ-87] Mthodes et techniques pour llectronique numrique J.P. CALVEZ Support de cours IRESTE Nantes 1987 [COX-85] Object-oriented-programming: An evolutionnary approach B. COX Addison Wesley 1985 [CARLING-88] Parallel processing: The Transputer and OCCAM A. CARLING Sygma Press U.K. 1988 [FREEMAN-87] Tutorial: Software Reusability P. FREEMAN Computer Society Press of IEEE N.W 1987 [HOARE-78] Communicating Sequential Processes C.A.R. HOARE Communications of ACM vol 21 No 8 1978 P.666-676 [HOROWITZ-87] An Expensive View of Reusable Software E. HOROWITZ, J.B. MUNSON IEEE Transactions of Software Engineering sept 1984 P.477-487 [INMOS-86] An Introduction to the Transputer and OCCAM INMOS 1986 [JACKSON-83] System development M. JACKSON C.A.R HOARE series, Prentice Hall 1983 [JENSEN-79] Software Engineering R. JENSEN, C.TONIES Prentice-Hall, Englewood Cliffs, 1979. 502 M.C.S.E

BIBLIOGRAPHIE 6 [M. JONES-88] Practical Guide to Structured Systems Design M. PAGE-JONES Yourdon Press London 1988 [G. JONES-88] Programming in OCCAM 2 G. JONES, M. GOLDSMITH C.A.R. HOARE Series Prentice-Hall, 1988 [D. JONES-89] To Task or not To Task D.W. JONES Journal of Pascal, Ada & Modula-2 sept/oct 1989, P.61-63 [NIELSEN-88] Designing large Real-time systems with ADA K. NIELSEN, K. SHUMATE Intertext Publications Mc Graw Hill N.Y. 1988. [ROSEN-87] Mthode de conception oriente Objets J.P. ROSEN Gnie Logiciel N9 Novembre 1987, P.16-21 [ROTENSTREICH-86] Two-dimensional program design S. ROTENSTREICH IEEE Transactions on Software Engineering vol SE 12 No 3 march 86 P.377-384

M.C.S.E

503

PARTIE

CONDUITE DE PROJET

Traiter compltement un projet ncessite d'immerger la PARTIE TECHNIQUE du travail dans un ensemble plus vaste de problmes qu'il ne faut surtout pas ngliger ni sous-estimer pour aboutir des rsultats satisfaisants. En effet, le dveloppement d'un projet ne consiste pas exclusivement concevoir et raliser le produit. Ceci est d'autant plus vrai que le projet est consquent. Au pralable, une organisation est prvoir compte-tenu de l'objectif recherch et les contraintes imposes. Ensuite, un contrle du suivi du dveloppement permet de s'assurer de la conformit de la ralisation des normes pr-dfinies, en respectant les TEMPS et les COUTS PREVISIONNELS. Si des drives sont dtectes, les CORRECTIONS ncessaires doivent tre apportes. S'assurer que le rsultat est conforme la demande du client et respecte toutes les contraintes, ncessite aussi de dfinir, ds la spcification de chaque niveau de la solution, une procdure de VERIFICATION et de VALIDATION, puis de l'appliquer chaque stade correspondant de l'intgration. Un produit n'est jamais compltement achev en fin de dveloppement. Des modifications, volutions, corrections sont invitables dans le cadre de la MAINTENANCE. De plus, un produit ne peut vivre que s'il est support par une DOCUMENTATION qui doit tre labore tout au long du dveloppement. Pour prsenter ces divers aspects, cette partie permet de prendre conscience des problmes de management (chapitre 23), d'estimation du planning et du cot (chapitre 24), de conformit (chapitre 25), de maintenance (chapitre 26), de documentation (chapitre 27) et de gestion de la qualit (chapitre 28).

M.C.S.E

505

Chapitre 23

MANAGEMENT DE PROJETS

"Adding manpower to a late project makes it later" Brooks Law "Projects progress quickly until they are 90 percent complete, and then remains 90 percent complete forever" Golubs Law On attache plus facilement de l'intrt aux activits individuelles du processus de dveloppement, au dtriment de la charge que reprsente l'organisation et le suivi de l'ensemble du cycle de vie. Celui-ci est pourtant considrer comme un tout, voluant comme un processus continu qui peut et doit tre optimis. Nous considrons ici comme point de dpart, l'obtention d'un contrat de dveloppement. La partie valuation de faisabilit, rduction de proposition est ralise en amont. Chaque projet a son caractre propre : taille, dure, contenu technique, conditions de travail, spcifications satisfaire. Le management devient une ncessit pour des projets moyens et vastes. On considre approximativement comme taille de projet : - petit < 5 hommes/mois - 6 < moyen < 15 - grand > 15 hommes/mois. Pour les petits projets, les informations de gestion de projets, donc autres que la documentation sur les produits, peuvent tre mmorises par le personnel et transmises par des communications verbales. Ceci n'est seulement vrai que pour une toute petite quipe.

M.C.S.E

507

Partie 7 - CONDUITE DE PROJET Avec l'accroissement de la complexit du travail et la taille des quipes, le contrle et la communication augmentent gomtriquement et ne peuvent plus tre satisfaites verbalement et d'une manire informelle. Aussi, de plus en plus d'entreprises acceptent le concept de management de projets comme un outil pour amliorer les dveloppements et exploiter efficacement les ressources. Par le management d'un projet, il faut entendre l'organisation et le contrle de toutes les activits techniques et organisationnelles ncessaires pour obtenir une solution acceptable, conforme aux besoins du demandeur, avec les contraintes spcifies de temps, de ressources et de cots. La fonction de management peut aussi se dcrire l'aide de ses composantes que sont: la planification, l'organisation, la gestion des ressources, la direction et l'encadrement, le contrle [FATHI-85, KOONTZ-80, RUSKIN-82]. L'objectif de ce chapitre est limit une prsentation succinte de ces diffrentes fonctions. Le chapitre 3 avait permis de prsenter le contexte global pour la partie technique de tout dveloppement; l'activit de management de projet a t introduit comme activit englobante. Justifions tout d'abord l'objectif par une prsentation du problme pour ensuite dcrire les fonctions du management. 23.1. UNE PRESENTATION DU PROBLEME L'activit de dveloppement est un enchanement d'tapes dcrit selon un modle de dveloppement aussi appel cycle de vie. Analysons tout d'abord les difficults pour comprendre l'objectif du management. Cette prsentation est donne par JENSEN. Elle utilise une analogie base sur l'ENTROPIE [JENSEN-79]. 23.1.1. Modlisation d'une tape de dveloppement Le processus de dveloppement peut se voir comme une srie de transformations qui introduit des changements d'tat. La transformation durant chaque phase rsulte de l'interaction des ressources appliques pour obtenir la transformation avec les spcifications en entre, et produit une solution. L'interaction est ici la partie intressante du processus. Plusieurs interactions spcifiques agissent : - interaction entre les ressources elles-mmes, - interaction avec le personnel de dveloppement, - interaction avec l'quipe de management, - interactions avec le client, l'utilisateur, les facilits... Le processus de transformation vu selon le concept d'ENTROPIE peut se reprsenter comme suit.

Energie

Processus de transformation

Produit utilisable

Entropie

-Figure 23.1- Reprsentation du processus de transformation. 508 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS Les ressources reprsentent l'nergie d'entre. Les sources tant multiples, des interactions internes existent. L'entropie est l'nergie dissipe durant le processus de transformation, qui n'est pas disponible pour la production du travail ou l'obtention du produit. Invitablement toute interaction produit une certaine quantit d'entropie. En se basant sur l'analogie de la thermodynamique, la quantit d'entropie pour un systme est proportionnelle aux mouvements alatoires. L'entropie exprime le dsordre dans le systme. Ceci veut dire que toute l'nergie introduite n'est pas transforme en un produit exploitable. W=E - s avec s > 0 (personnes non parfaites) W: E: s: 23.1.2. Types dEntropie L'entropie reprsente donc les effets ngatifs. On reprsente sur la figure suivante les entres, sorties et formes d'entropie pour une tape de transformation telle que par exemple le passage des spcifications un rsultat de conception.
R Ressources

est le travail produit est l'nergie d'entre est l'entropie

(0)

SPECIFICATIONS

CONCEPTION

(2) (1) Spcifications non-rsolues (0)

Solution (3)

-Figure 23.2- Modlisation pour la transformation Spcification>Conception. Dtaillons les diverses formes d'entropie prsentes sur cette figure. - La ligne (o) reprsente la production directe ne comportant pas de reconceptions, erreurs, omissions, inefficacits. Elle reprsente donc des donnes correctes et valides. Les autres lignes reprsentent l'entropie. - La ligne (1) reprsente la part des donnes d'entre non transformes (spcifications non rsolues et donc non transformes par la conception). La non-transformation peut tre de : M.C.S.E des inconsistances entre spcifications, des spcifications qui ne peuvent conduire une conception, des spcifications trop coteuses satisfaire, des spcifications incompltes ou errones. 509

Partie 7 - CONDUITE DE PROJET - La ligne (2) reprsente le dsordre de l'activit de transformation. C'est une pure perte d'nergie. Elle est engendre par : les activits spcifiques de chaque individu, dfaut de communication, mauvaise adquation des quipements, des mthodes... - La ligne (3) reprsente le fait que le produit (ou solution) qui rsulte de la phase n'est pas parfaitement complet, adquat.... Ces imperfections introduisent un degr de dsordre ou d'entropie dans la phase suivante. Le changement d'tat est donc incomplet. Cette ligne porte donc de l'entropie vers les phases futures. "Entropy on its way to happen". Les retours aux phases prcdentes (feedback) sont coteux et produisent une entropie leve. La quantit d'entropie gnre est fonction de la phase ou des phases ou elle apparait et de la longueur du bouclage arrire pour sa correction. Plus la phase est tardive, plus l'erreur est coteuse corriger. Un bon management consiste donc trouver une planification et une organisation (ressources et mthodes) qui conduisent une entropie globalement minimale. Bien videmment, il existe des minimums locaux qu'il faut viter. 23.1.3. Causes de lentropie Les premires rflexions pour prparer une stratgie de management consistent identifier dans un systme les causes de l'entropie, pour ensuite rechercher les mthodes et moyens pour les contrler. JENSEN prsente les causes en 2 classes diffrentes : - Les causes INEVITABLES et ACCEPTABLES car relatives des situations non contrlables: absence, moral, maladie, problmes de matriels et logiciels achets en externe, visites... . On peut les limiter par rduction des abus possibles. - Les causes NON ACCEPTABLES que sont: mauvaise coopration, incohrence, confusion et action non dirige. La liste suivante prsente par groupes quelques causes caractristiques. 1- PROJET SOUS-ESTIME - planning trop court, - budget trop faible, - inefficacit et dficiences non comptabilises. 2- RESSOURCES SOUS-DIMENSIONNEES POUR LE PROJET - type et volume de comptence humaine, - rles et responsabilits pas bien dfinies, - mauvais ordonnancement et allocation des ressources. 3- SPECIFICATIONS TROP VAGUES spcifications inadquates entre utilisateurs, clients et matre d'oeuvre, documents de spcification incomplets, codifications non contrles, pas d'apprciation de l'impact des modifications.

4- CONCEPTION TROP SUPERFICIELLE - difficults non identifies, - absence de mthode, 510 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS - absence de document de conception, - absence d'outils de dveloppement, - pas de vrification de la qualit. 5- REALISATION NON-CONTROLEE dveloppement intuitif du matriel, absence de mthode pour l'criture du logiciel, faiblesse des procdures de tests, validation non contrle.

6- COMMUNICATION INEFFICACE entre utilisateur et client, entre client et matre d'oeuvre, entre groupes travaillant sur le projet, entre concepteurs et ralisateurs, programmeurs, entre spcifieurs et les groupes de test.

7- ABSENCE DE CONTROLE SUR LA CONDUITE DU PROJET faible visibilit de l'tat d'avancement, absence de bilans partiels, autorit non effective dans l'organisation du personnel, management non suivi par l'quipe.

LE GROUPE 1 concerne la dfinition des ressources et la quantit de travail: - un mauvais niveau de ressources comme nergie conduirait un produit incomplet et non acceptable, (1re loi de la thermodynamique : la sortie reste infrieure l'nergie d'entre). Il faut donc obligatoirement revoir le niveau des ressources en cours de projet. - Une mauvaise dfinition et un ordonnancement de projet incorrect conduisent invitablement une nouvelle planification et une modification dorganisation un stade donn. Les rles et responsabilits sont modifis, le moral est affect, le taux d'entropie augmente trs srieusement. L'ajout de nouvelles ressources et donc l'assimilation que ncessite l'apport supplmentaire est cause d'une forte entropie. L'effet peut mme tre ngatif. La loi de Brooks dit : "Adding manpower to a late software project makes it later". LE GROUPE 6 identifie les problmes relatifs la communication ; c'est--dire mauvaise communication et incomprhensions. 2 solutions sont envisageables : - rduction des communications ncessaires en partitionnant en tches telles que les interfaces et changes soient les plus simples possibles. - mise en place des mcanismes efficaces et cohrents de communication l o c'est ncessaire. LE GROUPE 7 identifie les sources de retard par rapport une planification. On peut trouver 2 types de causes essentielles : - dfaut de prvision: analyse insuffisante, ce qui implique des tches oublies, mauvaise valuation du cot, du temps, des quipements, M.C.S.E 511

Partie 7 - CONDUITE DE PROJET trop grand optimisme, volution des spcifications, indisponibilit des ressources : hommes et quipements, retard des fournitures, interfrence avec d'autres projets.

- mauvais suivi de l'volution du projet: manque de volont de suivi de la part de la direction, absence d'un tableau de marche pour le contrle d'avancement, absence de fournitures matrialisant les fins d'tapes, camouflage des retards en pensant qu'ils peuvent tre rattraps, invisibilit des activits : c'est le cas du logiciel, de la conception.

Les ractions la constatation de retards peuvent tre de plusieurs ordres: - pression sur les quipes pour brler les tapes, - renforcement inconsidr, - altration arbitraire des spcifications. Globalement et sans entrer dans les dtails du management, les REMEDES aux points soulevs ci-dessus sont au minimum: - prvoir les ressources adquates, - faire correspondre les tches et les ressources en termes de structures, - utiliser des mthodes cohrentes et globales, - tablir un contrle de l'volution du projet, - maintenir une communication cohrente et efficace entre les participants du projet, - rendre effectif et visible le management et le contrle. C'est donc l'objectif du management que de ragir contre toutes les constatations et causes cites prcdemment pour rduire globalement l'entropie. 23.2. ORGANISATION DU MANAGEMENT Une bonne planification et un contrle associ sont les gages d'une bonne russite. Le management se dcompose en 5 activits essentielles [FATHI-85, KOONTZ-80]: - planification, - organisation, - structuration des quipes (staffing), - direction, - contrle. Selon CAPRON, ces fonctions de management peuvent se classer en 3 niveaux de management, comme l'indique la figure 23.3 [CAPRON-86]. Au niveau le plus lev, il s'agit d'une planification long terme pour l'entreprise. Que vont vouloir les clients dans les 5 10 ans venir?, comment atteindre cet objectif? Au niveau intermdiaire, les managers se chargent de runir les matriels et ressources humaines pour satisfaire les objectifs du niveau suprieur. Au niveau le plus bas, la tche consiste diriger et contrler les activits propres aux projets. 512 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS

Niveau suprieur Niveau intermdiaire

Planification Organisation Equipes Direction

Niveau de base

Contrle

-Figure 23.3- Hirarchie des fonctions du management. Il est vident que la comptence varie suivant le niveau. Si elle est plutt gnrale et d'ordre stratgique au niveau suprieur et donc relativement indpendante des produits, la comptence devient particulirement technique et donc plutt spcifique pour le niveau infrieur. Une autre faon de dcrire les fonctions du management consiste prsenter l'organisation fonctionnelle. Le schma suivant dcrit les relations entre les diffrentes activits.
Relation avec Objectifs la direction Rsultats
Dcisions pour correction

PLANIFICATION

PREVISION ORGANISATION

DIRECTION

STRUCTURATION EQUIPES MOYENS Actions(t)

Configuration(t) DEVELOPPEMENT

PRODUIT Observations(t)

CONTROLE

-Figure 23.4- Organisation fonctionnelle du management. La fonction de planification labore partir d'objectifs atteindre, la prvision en ressources humaines et matrielles ainsi que les dures et cot. Les fonctions d'organisation et de structuration des quipes mettent en place les moyens ncessaires pour le dveloppement. M.C.S.E 513

Partie 7 - CONDUITE DE PROJET La direction du projet dfinit les actions sur le dveloppement. Les corrections rsultent d'une observation de l'volution du dveloppement par une fonction de contrle. Dtaillons, dans la suite, les objectifs et les quelques principes de base pour chacune des fonctions. 23.3. PLANIFICATION 23.3.1. Objectifs La planification a pour but d'valuer tous les moyens, les dures et cots: Qui, Quand, O, Comment, Combien. Tout projet doit commencer par l'laboration d'un plan d'action (project plan). Il doit tre en accord avec le plan d'organisation de la socit. Ainsi, planifier, c'est dcider d'avance de ce qui sera fait, de la faon dont cela sera accompli, du moment o cela sera fait et par qui. La planification tablit le pont entre la situation actuelle et la situation dsire. Elle implique l'introduction d'lments nouveaux. REIFFER a identifi 3 phases initiales pour l'laboration de tout plan. 1- dfinition des stratgies de dveloppement et de management: configuration, assurance qualit, documentation, et qui ont une incidence directe sur le management de l'entreprise. 2- un plan d'affaire: dcrivant le travail faire, les contraintes et limitations, identification des quipes en justifiant la politique de management. 3- un plan de projet: il s'agit de dcrire le travail en un ensemble d'activits grables avec une estimation des ressources et cots pour chaque. Ceci permet d'exprimer une bonne connaissance sur le projet pour le manager et pour l'allocation et la gestion des ressources. Il s'obtient par une dcomposition hirarchique du type top-down. Un planning a pour but de placer dans le temps, l'excution de toutes les tches conduisant la ralisation d'un projet. Il s'agit donc d'un modle priori de droulement du projet. Ce modle prvisionnel sert au responsable pour la conduite de l'excution. Le rsultat observ par un suivi sert au contrle du droulement. Le planning n'est qu'un lment auquel peut se rfrer celui qui agit. Il ne suffit pas en luimme. Lorsqu'il est complet, il exprime les 3 dcisions suivantes : - la dfinition d'une relation d'ordre entre les tches accomplir, - l'affectation des ressources matrielles et humaines pour l'excution des tches: nombre, comptences, dure, - le placement dans le temps des tches, Pour laborer correctement un planning, il faut donc : - dfinir clairement les tches effectuer, - dfinir les moyens ncessaires l'excution, - dfinir la dure d'excution avec une prcision suffisante. Ce dernier point est trs important. Combien de projets logiciels divergent faute de ne pouvoir estimer correctement le temps de dveloppement d'un programme. Si l'incertitude sur la dure est grande, la prvision ne peut se faire que sur un horizon trs court. 514 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS Mais si le planning est ncessaire l'organisation, l'organisation est aussi indispensable pour l'laboration d'un planning, ceci pour au moins connaitre les mthodes et temps d'excution. 23.3.2. Principes REIFER indique 3 principes essentiels: 1- principe de prcdence: il faut tout dabord commencer tout projet par une planification. 2- planning effectif: le planning sera applicable et appliqu. Pour cela il doit tre cohrent avec l'organisation et la stratgie de l'entreprise. 3- planification jour: les plannings doivent tre tenus jour pour conserver leurs valeurs et jouer un rle pour le contrle. 23.4. TECHNIQUES POUR LA PLANIFICATION Les mthodes classiquement exploites sont : - Utilisation du diagramme de GANTT qui dcrit en 2 dimensions, chaque tche et sa relation avec les autres. Il permet de faire apparatre la diffrence entre planification et progression effective, comme l'indique l'exemple ci-dessous, mais n'est pas trs adapt pour mettre en vidence les dpendances entre tches.
Numro de semaine Tches
Etude faisabilit Spcification Conception fonctionnelle Dfinition de la ralisation Ralisation matrielle Ralisation logicielle Intgration Test

10

Date courante Tche acheve Tche non termine

-Figure 23.5- Exemple de diagramme GANTT. - Utilisation des diagrammes PERT. C'est un graphe prcisant, les activits et les vnements (dbut et fin), les relations de dpendance. Il fait apparaitre le chemin critique comme lindique la figure 23.6. La mthodologie MCSE est une aide prcieuse pour la prparation d'un planning. En effet, elle indique la dcomposition en tches pour mener bien un projet. Elle propose aussi une dmarche par tapes successives qui facilite l'valuation des temps (voir le chapitre suivant). M.C.S.E 515

Partie 7 - CONDUITE DE PROJET

15
2

Chemin critique 1 17

20
3

16

2 2 6
1

3 1 10 2 12 2

21

22

9
1

13

18

19

5
5

11

N : numro de la tche
N : dure de la tche : chemin critique : droulement dune tche : droulement virtuel (dure nulle)

14

-Figure 23.6- Exemple de diagramme PERT 23.5. ORGANISATION Lorganisation concerne la structure de la socit comme un tout et celle requise pour chaque projet en particulier. Le choix d'une structure pour chaque projet doit rester compatible avec celle de la socit et doit permettre suffisamment de souplesse pour les adaptations. Les individus collaborant la ralisation d'un objectif ont un rle jouer pour contribuer de faon prcise l'effort collectif. Lorganisation dfinit qui doit faire quoi, qui est responsable de quoi et pour quels rsultats. L'organisation doit tre rflchie car elle doit assurer que toutes les tches ncessaires la ralisation de l'objectif sont distribues et ce, dans la mesure du possible, aux personnes les plus aptes s'en acquitter. On peut dfinir l'efficacit d'une organisation pour un projet comme son aptitude gnrer un produit de qualit en un temps minimum et avec des ressources minimales. Citons quelques rgles traditionnelles d'organisation: unit de commandement (pour chaque subordonn), exception (concentration sur urgence importante), limitation du domaine de commandement, structuration en dpartements (regroupement d'activits similaires), chaine hirarchique de commandement.

REIFFER cite nouveau 3 principes de bon sens: 1- assignation initiale des responsabilits: une personne doit tre nomme responsable ds le dbut du cycle de vie du projet. Il faut s'assurer que cette personne occupe une position suffisante dans la hierarchie pour pouvoir assumer ses responsabilits et faire appliquer les dcisions. Il faut aussi tre vigilant sur la comptence technique qui est ncessaire pour que les problmes puissent tre compris et rsolus. 2- rduction des interfaces: l'efficacit est inversement proportionnelle au nombre d'interfaces existantes. 516 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS 3- parit: pour agir, il faut conserver l'quilibre entre l'autorit du manager et la responsabilit des participants au projet. 3 types de structures d'organisation sont classiques : - organisation fonctionnelle. Il s'agit d'un regroupement des activits communes, sous le contrle d'un mme manager. L'organisation est tout fait traditionnelle du type hirarchique. - organisation oriente projet. Il s'agit de former un grand nombre de groupes htrognes, chacun responsable de ses activits pour l'aboutissement du projet. Cette structure conduit immanquablement un gaspillage des ressources, un manque de communications et une difficult trs nette vers la standardisation. - organisation matricielle. L'organisation matricielle rsulte de l'association des bonnes caractristiques des 2 prcdentes. - organisation pour les projets en horizontal, - organisation fonctionnelle en vertical. Elle n'est pas base sur l'unit de commandement: project manager, ou functional manager. Comme avantages, elle permet des planifications long terme, une dfinition de standards et de procdures. 23.6. CONSTITUTION DES EQUIPES Il s'agit de former les groupes ou quipes qui vont mener bien le projet. Ceci implique que soient dfinis au pralable, les besoins en main-d'oeuvre selon le travail accomplir pour valuer et choisir les intervenants. Les principes qui peuvent servir de guide sont : 1- qualit: il vaut mieux quelques expriments pour les tches critiques, plutt que de larges quipes sans comptence particulire. 2- politique de perspective pour le personnel: formations technique et en management sont des investissements de socit qui peuvent engendrer un gain plus long terme. 3- galit des fonctions: il est raliste aujourd'hui de considrer une promotion quivalente pour la technique et pour le management. La politique de formation du personnel existant et la politique de recrutement sont donc trs importants pour la ncessit des projets. 23.7. DIRECTION DE PROJET La direction de projet est une fonction oprationnelle esssentielle pour le management. Elle dfinit les consignes tout instant sur la base des rsultats en provenance du contrle. La gestion et le suivi de chaque projet permettent l'introduction et l'application en temps utile des changements ncessaires au plan principal et ceci d'une manire contrle. Le suivi s'effectue des dates rgulires, de manire contrler les changements et maintenir l'intgrit et la visibilit de la configuration durant tout le cycle de vie. Evidemment, pour qu'une direction soit oprationnelle, tout projet doit tre "commandable" pour prendre en M.C.S.E 517

Partie 7 - CONDUITE DE PROJET compte des modifications de configuration. Ceci veut dire que la direction dispose de moyens de contrle et de moyens d'actions pour influer le dveloppement, en agissant sur les objectifs, les moyens, les mthodes. Les 2 objectifs suivants sont essentiels : - communiquer les objectifs aux subordonns, - motiver ces subordonns pour atteindre les objectifs. Pour cela 3 principes sont nouveau cits dans FATHI et ARMSTRONG: 1- motivation: l'intressement au travail et les possibilits d'avancement sont des sources de motivation qui amliorent la productivit et la qualit. 2- principe du meneur: chacun suit celui qui reprsente un moyen de satisfaire ses objectifs personnels. Le succs est plus probable s'il y a concidence entre ses objectifs personnels et ceux de la socit. 3- communication: la production est lie l'efficacit des communications. La rduction des changes est un moyen pour augmenter la productivit. 23.8. CONTROLE L'objectif du contrle est d'obtenir la convergence : excution planification, malgr l'imprcision de la planification et les perturbations durant le dveloppement. Il s'agit d'une activit rgulire qui doit tre admise par tous et permettant : - la mesure de l'tat d'avancement et la progression, - l'observation des dviations. Contrler ncessite de disposer de points de mesure, d'o la mise en place d'une stratgie de dveloppement conduisant une visibilit [AMGHAR-89]. Le contrle en spcification et en conception est bas sur l'observation des documents analyss lors de revues ou audits. Le contrle conduit des actions correctrices pour respecter les objectifs, ce qui se traduit essentiellement par une modification de la configuration du projet. Deux attitudes un peu extrmes peuvent tre observes : - certains responsables se contentent de savoir o ils en sont. - d'autres cherchent atteindre les objectifs fixs. Pour ces derniers qui ont une attitude volontariste, le planning est un outil ncessaire. Il sert au pilotage de l'entreprise, en permettant l'apport des corrections pour atteindre les buts, ceci en modifiant la stratgie pour converger vers l'objectif. Planification et contrle sont 2 activits indissociables puisque l'un fournit le guide ou la consigne pour l'autre. L'objectif pour le contrle est de dtecter les dviations significatives par rapport la prvision et de suggrer les moyens pour corriger les difficults. Citons pour finir 3 principes pour le contrle: 1- planification significative: les contrles servent informer trs rapidement les managers des dviations significatives par rapport la prvision. 2- excution mesurable: le contrle ne peut se faire qu'avec une politique efficace d'observation de la progression et de la conformit par rapport aux objectifs et standards. 518 M.C.S.E

Ch 23 - MANAGEMENT DE PROJETS 3- action sur exception: le manager doit concentrer ses efforts de contrle sur les exceptions.

En synthse, ce chapitre a permis de dcrire un modle dorganisation pour le dveloppement de projets. Son application est de la responsabilit dun manager. La fonction de manager ncessite de l'exprience. En effet, cette exprience acquise en ayant particip d'autres projets permet au responsable de structurer le travail et les activits du projet d'une manire raliste pour que les ressources mises en jeu permettent de satisfaire les spcifications de chaque tche tous les niveaux. Pour cela, le manager doit comprendre comment toutes les activits interagissent. Le chapitre suivant donne sur la base de MCSE quelques indications sur la manire dlaborer un planning et dvaluer le cot dun projet.

M.C.S.E

519

Chapitre 24

PLANNING ET COUT DUN PROJET

Un projet doit tre men dans le temps imparti et pour le budget assign. Ceci prsuppose donc durant la phase de planification une valuation correcte des temps et des cots. Ce chapitre sert comme base pour l'estimation et la planification d'un projet. Guide par la Mthodologie MCSE, l'valuation des temps et des moyens pour chaque tape conduit alors un calendrier de droulement et un cot de l'opration. Dans ce chapitre sont recenses les contraintes de droulement strictement ncessaires et sont indiques les possibilits d'ordonnancement des phases de dveloppement de manire pouvoir satisfaire au mieux les contraintes externes imposes pour le projet. L'enchanement en squence des tapes correspond une progression linaire descendante du cahier des charges jusqu'au produit oprationnel. Cette nature squentielle s'avre-t-elle strictement ncessaire, ou peut-on, tout en respectant les principes de la mthodologie, procder selon un ordonnancement diffrent? Cette remarque nous a t faite plusieurs reprises par des industriels. Il est utile de se poser la question car le contexte de dveloppement de l'application est lui-mme gnrateur de contraintes qui peuvent tre en contradiction avec le schma idal linaire squentiel. En effet, des contraintes varies sont considrer telles que: - dveloppement du projet incompatible avec l'enchanement des tapes pour des problmes d'indisponibilit de ressources humaines et ou de ressources matrielles, - date de fonctionnement de l'application exige, antrieure la date normale raliste, - dpendance du dveloppement avec d'autres projets en cours ou satisfaire.

M.C.S.E

521

Partie 7 - CONDUITE DE PROJET Lorsque des incompatibilits existent par suite de contraintes diverses, il faut revoir plus en dtail le droulement. La technique consiste donc analyser plus finement chacune des tches des tapes, de manire dduire une stratgie compatible avec les impratifs du demandeur. L'estimation des cots ncessite de dterminer: - l'ensemble des tches accomplir, - la liste des ressources ncessaires pour chaque tche en termes: de personnel (manpower), quipements, facilits, - l'association d'une dure pour chaque tche et l'assignation de dates pour chaque ressource. La dmarche propose dans les paragraphes qui suivent, consiste analyser pour chaque tape: les tches lmentaires, les contraintes temporelles et les relations d'ordre qui permettent ensuite de dduire les planifications possibles et quelques conclusions. 24.1. CONTRAINTES DE DEROULEMENT POUR CHAQUE ETAPE Pour cette analyse, prenons comme point de dpart l'accord de dveloppement entre demandeur (ou client) et concepteurs. Il est vident qu'en amont, des tches: de discussion, d'analyse du problme, d'valuation des cots et des temps, de ngociation sont ncessaires pour aboutir l'instant de dmarrage des spcifications. Il s'agit ici d'une analyse macroscopique plutt thorique, indpendante de la spcificit de chaque projet. Des temps approximatifs sont donns pour dduire quelques conclusions. Il est vident que ces valeurs sont ajuster pour une meilleure estimation. D'autre part, des perturbations sont considrer en complment pour toute situation relle: approvisionnement, absence... Ceci ressort de la tche du manager qui doit prendre en compte tous ces paramtres. Pour chacune des tapes sont valus: les temps en hommes/mois, les dures, les comptences ncessaires. L'valuation est faite en relatif en prenant comme unit de base le mois de conception. 24.1.1. Etape de spcification A partir du cahier des charges, une quipe d'analystes produit un document de spcification. Rencontres, discussions, visite du site pour observer ces entits de l'application sont indispensables pour une bonne comprhension du problme. Les objectifs sont ensuite dduits et affins progressivement. Toutes les informations entrant dans les spcifications sont synthtises sous la forme d'un document. Celui-ci doit tre lu, amend puis accept par tous les partenaires du projet. Les tches les plus importantes durant cette tape sont donc: 1- connaissance du problme, 2- modlisation de l'environnement, 3- rdaction des spcifications, 4- lecture, 5- correction et validation. Notre exprience de la mthodologie a montr que le temps au bout duquel les spcifications se trouvent satisfaisantes (soit Dspec ce temps), n'est pas du tout gal la somme des temps passs pour chacune des tches, mais bien suprieur. D'autre part, le temps cumul 522 M.C.S.E

Ch 24 - PLANNING ET COUT DUN PROJET pour toutes les tches n'est pas inversement proportionnel au nombre d'analystes chargs du travail de spcification. Seules certaines parties de rdaction des spcifications peuvent tre rparties sur une quipe. La figure suivante reprsente une chronologie des tches pour cette tape.
Connaissance problme modlisation environnement spcifications fonctionnelles lecture lecture Dbut possible pour la conception fin des spcif lecture correction temps plein

temps partiel

t=0

DSPEC

fin de la spcification

-Figure 24.1- Chronologie des tches pour la spcification. Comme grandeur approximative, considrons que si une spcification ncessite une dure (fin-dbut) de 3 mois pour Dspec, il faut y consacrer de l'ordre de Tspec=1homme/mois, pour obtenir ce rsultat (ne pas confondre dure en dlai et temps de travail). La dure est habituellement relativement incompresssible, car elle correspond un cumul des dlais ncessaires entre chaque opration: runions, discussions, visites, lecture, correction... L'tape suivante, c'est--dire celle de conception, commenant par une phase d'analyse et de dlimitation des entres-sorties peut dbuter lgrement avant la fin des spcifications. L'instant le plus raliste est situ aprs la rdaction des spcifications fonctionnelles, ce qui correspond approximativement au 2/3 de Dspec. La comptence d'ingnieur est ncessaire pour cette tape. La spcification rsultant d'un transfert d'expertise entre demandeur-utilisateurs et analystes ou concepteurs, un travail important de communication est impratif. L'aptitude synthtiser conduit une rdaction correcte et rapide des spcifications. 24.1.2. Etape de conception Si le document de spcification est bien labor, les concepteurs peuvent travailler d'une manire autonome pour dvelopper la solution fonctionnelle. Les tches lmentaires durant l'tape de conception sont les suivantes: 1- dlimitation des entres-sorties, 2- premire dcomposition fonctionnelle, 3- raffinement de fonctions, 4- synthse globale de la solution, 5- revues du travail de conception. Chaque tche conduit l'laboration d'une partie du document de conception. Les revues servent vrifier par le cycle auteur-lecteurs, la cohrence et la qualit des solutions. En se plaant dans le cas d'une quipe de concepteurs, les tches 1,2,4,5 se font en quipe. Le raffinement d'une fonction peut s'entreprendre d'une manire individuelle. M.C.S.E 523

Partie 7 - CONDUITE DE PROJET La chronologie des tches pour la conception est indique ci-dessous.
Dlimitation E/S premire dcomposition raffinement

Dveloppements simultans
synthse globale

revue

revue

revue finale, documentation

t=0

Dconception

-Figure 24.2- Chronologie des tches pour la conception. Pour avoir un ordre de grandeur des temps de travail en hommes/mois et de la dure pour la conception, considrons trs grossirement que le temps de conception est approximativement 3 fois le temps de spcification. Bien sr, une variation autour de ce coefficient est trs dpendante de la nature du problme. soit Tconception= 3xTspec (en homme/mois) Le travail de conception peut se faire temps complet. Comme les tches de raffinement sont ralisables en parallle en faisant intervenir plusieurs concepteurs, partons de l'hypothse que pour la dure, seule la moiti du cot en temps de dveloppement peut se rduire. L'autre moiti correspond aux activits en quipes: analyse de dpart, synthse, revues. Avec N: le nombre de concepteurs, la dure de la conception est comprise entre: 0,5x (1+1/N) Tconception < Dconception < Tconception N est fonction de la dimension du projet. Il faut savoir que l'efficacit diminue avec le nombre d'intervenants par suite du temps consacrer aux changes. Ainsi, un petit projet se traite plus efficacement par un seul concepteur; gnralement celui-ci est aussi charg des spcifications. En toute logique la dfinition de la ralisation ne peut dbuter qu'aprs la conception fonctionnelle. La comptence ncessaire pour cette tape est celle d'analyste-concepteur. Un responsable de la conception de niveau ingnieur se charge des phases initiale et finale, de la rpartition des tches de raffinement, du suivi des dveloppements... Les tches de raffinement peuvent se rpartir sur des ingnieurs et des techniciens qualifis en conception selon la complexit des problmes traiter. 24.1.3. Etape de dfinition de la ralisation Cette tape conduit un rsultat par une suite d'analyses et de transformations de la solution fonctionnelle. Les tches essentielles sont les suivantes: 1-enrichissement de la structure fonctionnelle avec les contraintes technologiques, 2-valuation des contraintes de temps et rpartition matriel/logiciel, 3-spcification de l'implantation logicielle, 4-spcification de la ralisation matrielle. 524 M.C.S.E

Ch 24 - PLANNING ET COUT DUN PROJET Suivant le nombre de concepteurs, certaines tches peuvent se faire en parallle. La chronologie des tches est donne ci-aprs.
interfaces et rpartition contraintes de temps, rpartition mat./log. spcification du logiciel spcification du matriel synthse, documentation t=0 Ddef_ra.

-Figure 24.3- Chronologie des tches pour la dfinition de la ralisation. D'aprs notre exprience sur des projets industriels, le cot en temps pour cette tape est assez faible comparativement celui ncessaire pour la conception. Comme rapport, on retiendra que: Tdef_rea= Tconception/3 Les concepteurs ayant travaill durant l'tape prcdente interviennent durant cette tape. Selon le nombre, la dure de l'tape est donc comprise entre: 0,5x (1+1/N) Tdef_rea < Ddef_rea < Tdef_rea 24.1.4. Etape de ralisation La ralisation compose des 2 parties matrielle et logicielle est assure par 2 catgories de spcialistes. Sans entrer dans le dtail des activits qui peuvent tre des plus varies, les tches essentielles sont: 1- Ralisation du matriel, 2- Ralisation du logiciel, 3- Intgration et mise au point, 4- Vrification, validation, certification. Les tches 1 et 2 sont ralisables en parallle et par des quipes de techniciens. Les tches 3 et 4 ncessitent la collaboration des 2 types de comptences. La chronologie des tches est la suivante.
Fin du projet ralisation du matriel ralisation du logiciel intgration, mise au point test, validation, certification

Dralisation

-Figure 24.4- Chronologie pour l'tape de ralisation. M.C.S.E 525

Partie 7 - CONDUITE DE PROJET La ralisation du matriel peut conduire des sous-traitances. Il ne s'agit donc pas obligatoirement d'une activit temps complet. Ensuite, l'intgration ne peut dbuter qu' partir de la disponibilit du matriel et lorsqu'une partie importante du logiciel est dveloppe et teste. Le cot en temps pour la ralisation a un rapport avec le temps de conception. Supposons ici un coefficient 3. Tralisation=3*Tconception Des tches pouvant s'effectuer en parallle, une partie du temps peut se rduire en augmentant le nombre de participants. La partie incompressible: runion de concertation, intgration, test..., est proche de la moiti. Ainsi, pour M ralisateurs en simultan, la dure de la ralisation est comprise entre: 0,5x (1+1/M) Tralisation < Dralisation < Tralisation La comptence est essentiellement du type technicien, laquelle s'ajoute un ou des responsables d'quipes de niveau ingnieur. 24.2. DUREE TOTALE DUN PROJET Les chiffres trs approximatifs proposs pour chacune des tapes conduisent une valuation de la dure totale du projet, du cot en temps et en ressources humaines. Pour ce calcul, nous prenons comme unit le mois de conception. Le rsultat est donn par le tableau suivant: - N nombre d'ingnieurs, - M nombre de techniciens, - CI cot du mois ingnieur, - CT cot du mois technicien. Etape Spcification Conception Def ralisation Ralisation Total Ainsi, Dure 1 0,5(1+1/N) 0,17 (1+1/N) 1,5(1+1/M) 3,17+0,67/N+1,5/M Cot temps 0,33 1 0,33 3 4,66 Cot ressources 0,33 CI 0,5(CI+CT) 0,17(CI+CT) CI+2CT 2CI+2,67CT

si N = 1 et M = 1 alors Dure = 5,34 pour un temps de travail de 4,66 si N = 2 et M = 3 alors Dure = 4 si N = et M = alors Dure = 3,17 !!

La formule approximative trouve pour la dure montre que l'apport en hommes ne rduit pas considrablement la dure du projet, tandis que le cot en ressources fort probablement augmente. Le calcul du cot des ressources humaines reste aussi fonction de la qualification exige pour les diffrentes tches. 526 M.C.S.E

Ch 24 - PLANNING ET COUT DUN PROJET 24.3. OPTIMISATION DUN PLANNING Constatant le rsultat trouv sur la base d'un enchanement squentiel des tapes, posonsnous la question de savoir s'il est possible de rduire la dure du projet tout en respectant la mthode. Pour y rpondre, analysons les modifications d'ordonnancement possibles pour chaque tape et entre tapes.
-A- ETAPE DE SPECIFICATION

Un ordonnancement diffrent durant l'tape n'apparat pas raliste. Par contre, la conception peut dbuter aprs la rdaction des spcifications fonctionnelles, soit au 2/3 de la dure de spcification.
-B- ETAPE DE CONCEPTION

L'ordonnancement durant l'tape parat difficilement modifiable. Il est seulement possible de modifier l'ordre des tches de raffinement lorsque le nombre de concepteurs est infrieur au nombre de raffinements entreprendre.
-C- DEFINITION DE LA REALISATION

Si on regarde prcisment les lments ncessaires pour dbuter la dfinition de la ralisation, on constate que ds la premire structure fonctionnelle et en dehors de toutes contraintes de rpartition, il est possible de commencer introduire les interfaces. Ainsi, la limite, une partie de la dfinition de la ralisation peut dbuter la moiti de la conception fonctionnelle, mais au moins la moiti de la 3e tape doit se drouler au-del de la conception. Si le problme possde des contraintes de temps assez svres, l'enrichissement des tches doit tre suivi avec rigueur. Si ce n'est pas le cas, la rpartition matriel/logiciel se dduit rapidement partir des entres/sorties. La spcification de la ralisation peut alors tre anticipe. Peut-tre des risques existent, mais parfois lanticipation est intressante, voire ncessaire si la squence de ralisation du matriel est longue et que le matriel est ncessaire rapidement pour le dveloppement du logiciel et pour les tests.
-D- REALISATION

Le dbut de la ralisation peut tre lgrement anticip. C'est souvent le cas pour la partie matrielle qui se dfinit sur des contraintes autres que celle du projet. La dure de la ralisation se rduit en amliorant la technique et les quipes de dveloppement du logiciel. En moyenne, le cot en dure pour le logiciel est suprieur 70% du cot total de l'tape.
-E- DUREE GLOBALE MINIMALE

Les conclusions prcdentes sont reprsentes sur le diagramme de la figure 24.5. Ainsi, pour N = 1 et M=1 alors pour N = 2 et M = 3 alors Dure = 4,75 Dure = 3,45

Le gain en temps possible est donc de l'ordre de 10% au maximum. Ceci montre que les latitudes d'ordonnancement restent cependant relativement faibles. M.C.S.E 527

Partie 7 - CONDUITE DE PROJET

1 Spcification 0.5(1+1/N) Conception 0.17(1+1/N)

Dfinition de la ralisation

1.5(1+1/M) Ralisation

t=0

2/3 Dspec

2.65+0.6/N+1.5/M

-Figure 24.5- Dates au plus tt pour un projet. 24.4. METHODE OU PAS DE METHODE Faisons une valuation, bien sr toujours approximative, pour comparer les temps estims avec ou sans mthode. L'absence de mthode peut conduire la situation extrme ou le dveloppement du projet dbute directement par la phase de ralisation: dveloppement du support matriel, criture de programmes. Quelle que soit la dmarche, il faut analyser le problme pos, exprimer les objectifs et les contraintes respecter, construire une solution sur le plan architectural. Sans mthode, et selon une progression ascendante, ces points se dvelopperont progressivement au fur et mesure du travail qui conduit au rsultat. Sans beaucoup se tromper, supposons que le temps de ralisation est au minimum le double du temps de ralisation estim avec emploi d'une mthode (ce qui est fort probablement une sous-estimation). Ainsi : cot temps = 6, dure = 3 (1+1/M), Cot ressources humaines= 2 CI + 4 CT. Le cot est donc suprieur mme si la dure n'est pas plus importante. De plus, invitablement, comme des erreurs vont tre dtectes relativement tard dans le cycle de dveloppement, la correction de ces erreurs va augmenter trs notablement le cot de la ralisation. 24.5. ESTIMATION DU COUT DUN PROJET L'estimation des cots de dveloppement est une tche complexe qui ncessite une comprhension dtaille de tous les facteurs varis qui influent directement ou indirectement sur le cot. Citons quelques facteurs identifis par Griffin [FATHI-85] - niveau de dtail du cahier des charges, - stabilit des spcifications, - niveau exig pour la documentation, - existence et comptence du support (personnel, quipement), - ncessit de formation, 528 M.C.S.E

Ch 24 - PLANNING ET COUT DUN PROJET facilit d'accs aux moyens de dveloppement, niveau exig pour les tests (oprationnel, qualification, certification), complexit de l'intgration hard/soft, niveau du support aprs fourniture (maintenance, formation), pour le logiciel: sa taille, la productivit des programmeurs.

Comment peut-on s'y prendre pour faire une valuation des plus ralistes? BOEHM cite diffrentes techniques d'estimation [BOEHM-84]: - estimation par analogie (extrapolation base sur l'historique), - estimation par consultation d'experts, - estimation algorithmique partir de l'valuation de certains facteurs: taille, difficult, nombre dE/S..., - estimation par analyse (descendante ou ascendante), - estimation du prix suffisant pour gagner le contrat (Mthode de "Parkinson"). Il est trs difficile de faire une estimation correcte tant que les spcifications ne sont pas compltement dfinies. Une stratgie possible consiste envisager une varit de produits pour la demande et donc des intervalles de cot. La difficult est trs caractristique pour un dveloppement logiciel et il est plutt frquent de constater des carts allant du simple au quadruple. En effet, l'estimation du nombre de lignes de programmes ne peut pas rsulter d'un calcul explicite partir du cahier des charges, d'autre part, on mesure aussi trs mal la productivit dans cette spcialit. Il n'en reste pas moins qu'un effort important d'valuation sur la base d'une mthode doit tre entrepris car une bonne estimation de dpart est essentielle pour la planification et le contrle. L'estimation du cot ncessite de dterminer [AMGHAR-89]: - l'ensemble des tches pour le projet. Plus la dcomposition est fine, meilleure sera l'estimation rsultante, - la dure de chaque tche, - la liste des ressources ncessaires et leur cot pour chaque tche. Les ressources sont de 3 natures: personnel, quipement, infrastructure et facilits, - la liste des fournitures entrant dans la ralisation du produit. Le cot est alors le total des produits: cot ressource x dure, augment du cot des fournitures. 3 facteurs doivent donc tre bien matriss: tches, ressources, temps. La dcomposition base sur MCSE est ainsi une bonne base pour l'valuation. En plus des lments prcdents, un bon manager considre l'existence de problmes potentiels et certains risques tels que: changement rapide de technologie, dlai d'approvisionnement, une seule source..., ainsi que certaines incertitudes. Un manager expriment ajoute aux 2 niveaux prcdents: une analyse prvisionnelle de toutes les choses qui pourraient "mal se passer".

M.C.S.E

529

Chapitre 25

CONFORMITE DUN PROJET

Pour tre accept, un projet doit tre conforme ses spcifications, celles-ci dfinissent au moins toutes les contraintes tant fonctionnelles que technologiques. Une activit importante et essentielle consiste donc dterminer si la solution est correcte. L'obtention de la conformit du projet ncessite une suite de tches appeles: vrification, test, validation. Elles doivent tre dfinies comme procdures et doivent reposer sur l'emploi de mthodes et outils. C'est l'objet de ce chapitre. L'erreur est humaine. Plus le problme est complexe, plus le nombre d'intervenants est grand et donc plus les risques sont importants. Les erreurs sont aussi en rapport avec l'augmentation des transactions entre personnes. Chaque phase du cycle de vie peut induire des erreurs. La conception introduit des erreurs relativement aux spcifications. L'implantation n'est pas compltement ralise comme l'entendaient les concepteurs. Invitablement des erreurs se glissent dans les ralisations. Des vrifications doivent tre effectues au moins entre chaque phase pour rduire la propagation des erreurs. De plus, comme les humains ne peuvent pas raliser et communiquer la perfection, le processus de dveloppement se doit d'tre accompagn d'une activit de gestion qualit voque dans le chapitre 28. La vrification et la validation participent l'obtention de cette qualit.

M.C.S.E

531

Partie 7 - CONDUITE DE PROJET 25.1. TERMINOLOGIE Pour parler de cette activit qui conduit l'obtention de la conformit, on utilisera la notation VVT pour: Vrification, Validation, Test [FATHI-85]. Dfinissons tout d'abord la signification des termes employs. - Fiabilit: (reliability) C'est la probabilit qu'un systme fonctionne correctement durant une priode T dfinissable par le MTBF. C'est une mesure spcifique de la qualit. Les paramtres qui interviennent sont: le nombre, la frquence, la complexit des erreurs. La vrification et la validation contribuent obtenir un systme fiable et qui ralise les fonctions prvues. - Vrification Cette activit aide garantir que chaque niveau de la solution satisfait correctement les spcifications du niveau suprieur. Elle assure la consistance, la compltude et l'absence d'erreurs chaque stade et entre les stades du dveloppement. - Validation Cette activit assure pour chaque niveau que la ralisation dveloppe pour chaque sousensemble assure les fonctions et satisfait les performances telles que prvues dans les spcifications pour le niveau correspondant. En final, il s'agit de s'assurer que le produit final est conforme aux besoins et attentes du demandeur. - Certification C'est l'acceptation par le demandeur du produit aprs sa validation. Il s'agit pour cela de s'assurer que le produit interagit correctement avec son environnement, ralise les fonctions demandes dans le contexte du demandeur et satisfait les performances. - Test Il s'agit de la phase d'analyse du comportement d'un systme, sous-ensemble, fonction,... en ralisant des excutions sur des ensembles de donnes, de manire mettre en vidence des erreurs et ainsi pouvoir assurer la vrification. - Testabilit C'est l'aptitude d'une conception permettre les tests avec efficacit. Les critres de qualit qui induisent la testabilit pour une conception sont: comprhensibilit, commandabilit, mesurabilit. Lors d'un changement dans un module, combien de modules doivent tre retests?, pour une srie de changements srie quels sont les modules tester? La figure 25.1 illustre la signification des termes et la relation avec les tapes de la conception. 25.2. OBJECTIFS L'activit VVT a pour objectif de dterminer si un systme ralise les fonctions prvues garantissant une fiabilit donne. Les actions de vrification/validation peuvent se dcrire par la structure en V de la figure ci-dessus, qui montre que chaque sous-ensemble ralis doit tre l'image du document de spcification du stade correspondant. L'activit VVT regroupe donc des ensembles: de procdures, d'activits, de techniques, d'outils. Evoquons tout d'abord la nature des erreurs avant d'envisager la manire de les dtecter. 532 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET

VERIFICATION, VALIDATION ET CERTIFICATION Demande CERTIFICATION

fonctionnement maintenance
Evaluation et test oprationnel

Cahier des charges

Spcification systme

VALIDATION

Test dint. systme

Spcification performances

Tests de performances

Conception prliminaire

VALIDATION

Test intgration

Vrifications
Conception dtaille Test unitaire

Ralisation

Mise au point

-Figure 25.1- Cycle de vie incluant Vrification, Validation et Certification. 25.3. TYPE DERREURS Le cot des erreurs, incluant la mise en vidence et la correction, crot exponentiellement avec la distance entre le stade de vrification et le stade de la conception correspondante. Rappelons les types d'erreurs couramment rencontrs en dveloppement: - mauvaise interprtation des spcifications. - mauvaise comprhension et mauvaise utilisation des mthodes et outils de conception et de dveloppement (composants, langage). - imperfection; ceci est trait par l'assurance qualit. - erreurs syntaxiques , logiques, smantiques. - valeurs critiques et effets de bord. - erreurs de timing, overload. - performances, throughput non-tenus. - sret (recovery). Une diffrence est faire entre le TEST et la MISE AU POINT (debugging). La phase de mise au point limine les erreurs "mcaniques" du codage, le sous-ensemble fonctionne et produit des rsultats. Les rsultats ne sont pas obligatoirement justes. C'est le rle du test que de les corriger. M.C.S.E 533

Partie 7 - CONDUITE DE PROJET 25.4. NATURE DES VERIFICATIONS En considrant que pour la vrification, il faut comparer 2 entits: le rsultat produit et une spcification, on peut classer les types de VERIFICATION en 3 catgories: [FATHI-85]: - vrification d'intgrit. Cette vrification porte sur la cohrence de la solution ou d'une spcification pour chaque phase du dveloppement, - vrification de raffinement (check volution). Il s'agit d'une vrification de la compltude et cohrence lors du passage d'un niveau au suivant, - vrification de conformit. Cette vrification assure que la ralisation est ncessaire et suffisante pour le problme.

Vrification de
SPECIFICATION

conformit

REALISATION

Vrification de raffinement

SOLUTION

Vrification dintgrit

-Figure 25.2- Catgories de vrification. Une autre classification est possible suivant la nature de lanalyse: statique, dynamique, formelle.
-A- ANALYSE STATIQUE

Cette technique conduit la dtection des erreurs en examinant le produit, ceci par exemple, par simple lecture du document de conception (cycle auteur/lecteurs).

Spcification Standards, guides, critres

Analyse forme et structure

Rapports et diagnostics

-Figure 25.3- Vrification par analyse statique. Lanalyse est manuelle ou automatique (cas des descriptifs et textes sources). Elle permet de prvenir des erreurs du type manques et de dtecter les anomalies du type syntaxique.
-B- ANALYSE DYNAMIQUE

Elle permet de dterminer la validit d'un sous-ensemble en tudiant sa rponse un ensemble de donnes d'entre ou de commandes. L'activit qui permet d'obtenir des rponses est appele TEST. Cette analyse se dcompose selon les phases suivantes: 534 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET - prparation du test excuter, ce qui inclut: slection des scnarios de test et des squences d'entre, formulation des rsultats attendus. - excution du test. - analyse des rsultats pour dduire le comportement, les performances.
Spcification de la fonctionnalit Spcification Selection des paramtres de test Analyse fonctionnelle Rsultats Comparaison et analyse Evaluation et diagnostics

-Figure 25.4- Vrification par analyse dynamique.

-C- ANALYSE FORMELLE

Elle est base sur l'utilisation de techniques mathmatiques pour analyser les proprits d'une solution. Habituellement cette mthode est limite des sous-ensembles trs prcis pour prouver l'exactitude et l'existence de proprits. Il peut s'agir aussi de tests de complexit. Ces 3 types d'analyse peuvent se coupler pour dfinir une mthode, comme l'indique la figure suivante.
V V et T Analyse Type danalyse (spcifications)

Rsultats Produit tester

- spcification - conception - ralisation Modifications consistance

Rsultats Analyse formelle

Analyse statique

Analyse dynamique

Erreurs

Erreurs

Erreurs

Erreurs de base

Erreurs de fonctionnement

Proprits et qualits

-Figure 25.5- Enchainement des diffrentes analyses. La mthode employer est fonction de l'tape dans le dveloppement. On passe ci-aprs en revue les techniques utilisables pour les phases de conception et de ralisation. 25.5. METHODES EN CONCEPTION Les vrifications et validations sont des activits continues durant la conception. La vrification a pour objectif de s'assurer de la consistance logique de la conception vis--vis de la phase prcdente. La vrification inclut l'analyse du respect des critres de qualit. La M.C.S.E 535

Partie 7 - CONDUITE DE PROJET validation sert garantir l'aptitude d'une conception satisfaire fonctionnellement les besoins du demandeur, c'est--dire l'adquation aux spcifications. Les mthodes exploitables sont [JENSEN-79]: - les revues de conception, - les modlisations et si ncessaire les simulations. En rsultat, 2 types de dfauts peuvent tre rencontrs: - fonctionnement (ou fonctionnalit) incorrect, - mauvaise performance vis--vis des spcifications. 25.5.1. Technique pour les revues de conception Un concepteur, si proche de sa conception, peut avoir dvelopp des erreurs invisibles pour lui, des solutions biaises car prconues, errones ou non. Un lecteur ou reviewer, par contre, n'a pas de connaissance priori sur la conception. Le principe de la mthode consiste utiliser la connaissance intime du concepteur sur le systme, mais en liminant les biais, de manire faire ressortir l'objectivit. Pour cela, il y a ncessit d'une planification et d'une organisation conduites avec des objectifs prcis et dfinis. Pour les objectifs atteindre, trois aspects sont importants: 1- analyse du travail intime du concepteur pour sa consistance et sa conformit aux standards. 2- valuation de la conception individuelle relativement l'ensemble du systme. 3- valuation de la conception individuelle relativement aux spcifications. Pour cela il y a ncessit de plusieurs types de revues.
-A- REVUE FORMELLE

Elle fait partie du plan de management, en particulier pour la documentation. Il y a ncessit d'une dfinition initiale, ce qui implique l'association d'une revue chaque phase du dveloppement.
-B- REVUE INFORMELLE (WALK THROUGHS)

Les ingnieurs doivent tre prpars la participation ces runions. Ce type de travail fait partie du quotidien et permet d'amliorer la connaissance et la matrise des problmes. Les participants constituent un facteur important d'aide la dtection et la rsolution avec succs des problmes. La slection est faite sur la base des objectifs. La responsabilit incombe au reviewer qui doit se charger: d'acqurir les matriaux pour la revue, de lire, d'identifier les domaines d'analyse, de prparer la runion. Les documents pour les revues sont prpars et soumis aux participants au pralable. Il y a lieu de crer un texte historique pour mmoriser les dcisions et liminer les redondances. Pour le droulement d'une REVUE, les reviewers doivent d'abord commenter la compltude et la qualit du travail. Les problmes essentiels sont exprims et identifis pour les rsoudre par la suite. Les concepteurs prsentent leurs rsultats. Ensuite, ils conduisent (walk) les reviewers travers la conception, pas pas, de manire simuler dans l'esprit la fonction sous analyse. Les points qui ncessitent une action complmentaire sont enregistrs et identifis. 536 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET C'est de la responsabilit du review que de solutionner toutes les actions listes. Les reviewers seront informs des actions et/ou corrections. Une suite aux revues est donc ncessaire. La conception rsultante (documentation release) est ensuite transmise pour le contrle qualit. 25.5.2. Simulation/modlisation comme outil d'valuation Cette technique est utilisable pour valuer les diverses alternatives et pour la vrification. Mais attention, le cot en temps voire en moyens est prvoir ds le dpart. La modlisation est une reprsentation selon une forme abstraite, gnralement simplifie d'une partie de la chose relle. Plusieurs niveaux de modles sont possibles: du concept jusqu'au modle raliste. Un modle doit reprsenter les caractristiques dsires du produit valuer. Un modle n'est pas une fin en soi, mais un outil pour prvoir les proprits et performances. Un simulateur est un outil logiciel simple, qui aide au dveloppement d'un produit: simulation de l'environnement (test, maintenance), simulation du systme (test de la conception). La modlisation doit tre utilise lorsque la vrification ne peut pas tre rsolue: par un effort d'analyse manuel, par exprimentation (cots), par intuition et exprience passe. 25.6. METHODES POUR LA PHASE DE REALISATION Le test et donc l'analyse dynamique n'est pas la premire solution employer. L'analyse statique permet au pralable d'liminer une part importante des erreurs. Ces procdures sont valables aussi bien pour le matriel que pour le logiciel. 25.6.1. Analyse statique Des revues et audits placs en des stades prcis du dveloppement permettent l'analyse statique et servent donc de premire tape pour la mthode de vrification et de validation. Les revues doivent porter sur l'analyse des spcifications de la ralisation, de la ralisation et de l'intgration. La simple revue par paire est efficace comme premire analyse. Il s'agit d'une technique d'inspection, car une personne est faible pour trouver ses propres erreurs. 25.6.2. Analyse dynamique Cette analyse se base sur la ralisation de TESTS. Le test met en vidence la prsence d'erreurs, il ne permet toutefois pas de dmontrer l'absence d'erreurs. Ceci peut justifier le stade suivant d'analyse formelle. La squence des oprations de test est la suivante : excution, observation, comparaison. L'excution ncessite une planification pralable, c'est--dire un document qui prcise les points suivants: - type de tests, - scnario, - donnes d'entre, - comment observer, - comment comparer. M.C.S.E 537

Partie 7 - CONDUITE DE PROJET Le choix des scnarios et donnes d'entre n'est pas vident car le nombre de cas est trs souvent infini. Il faut donc choisir un sous-ensemble (test data set). L'objectif est de trouver le sous-ensemble adquat. Les rgles suivantes pourront guider le concepteur : - le scnario doit permettre de visualiser les proprits normales, spciales, les singularits (valeurs extrmes). - il doit permettre d'activer toutes les branches ou composants. 25.6.3. Dmarche pour le test Diviser pour conqurir est la rgle du test. Il faut donc tester les sous-ensembles avant de s'attaquer l'intgration.
-A- TEST DES CONSTITUANTS DE BASE (test unitaire)

Reporter le test jusqu'au stade de l'assemblage complet conduit une exprience dsastreuse. L'ide est qu'un pourcentage important d'erreurs peut se dcouvrir et se corriger au niveau le plus faible (composant matriel ou logiciel). Le cot est alors minimal.
-B- TEST DINTEGRATION

Il s'agit de tester l'assemblage de plusieurs composants de manire constituer des ensembles oprationnels vastes. Le test porte alors sur l'interaction entre composants et les interfaces. Ce type de test est facilit si, au pralable, chaque composant se trouve test et valid. L'assemblage et donc la squence des tests suit l'organisation hirarchique ou structure de l'application. 25.7. TECHNIQUES POUR LINTEGRATION On dtaille plus particulirement les techniques mettre en oeuvre pour la phase finale du dveloppement qu'est l'intgration, car elles sont essentielles pour l'efficacit. Ces techniques sont en grande partie extrapolables pour le matriel. Les techniques peuvent se classer en 2 catgories complmentaires: l'assemblage par phase ou l'assemblage incrmental. 25.7.1. Assemblage par phase L'assemblage par phase consiste assembler le composant d'un niveau donn avec tous les composants tests de niveau infrieur.
A A

partie teste

-Figure 25.6- Assemblage pour test par niveaux. La difficult consiste trouver l'erreur: elle peut provenir du module A non test, ou de l'interaction avec les composants appels. 538 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET 25.7.2. Assemblage incrmental L'assemblage incrmental consiste, partir d'un composant, le tester, puis lui ajouter un autre non test. L'erreur provient alors: soit du nouveau composant, soit de l'interaction entre le nouveau composant et le reste du systme test. L'assemblage peut se faire selon un ordre ascendant ou descendant. Pour les systmes complexes, il est prfrable d'utiliser la technique ascendante (bottom-up). L'intgration ascendante ncessite l'emploi de programmes "Drivers". Un "Driver" active le composant sous test en simulant l'activit du composant de niveau suprieur. L'intgration descendante (top-down) ncessite des "stubs". Il s'agit de composants vides qui simulent le fonctionnement des composants du niveau infrieur.
driver A A stub B Exemple tester driver A A stub C stub B driver A stub C driver B B driver C C

B B C

-Figure 25.7- Assemblage et test ascendant et descendant. Dans la pratique, il est plutt conseill d'utiliser une combinaison des 2 techniques. 25.7.3. Tests orients OBJECTIFS C'est une technique de test fonctionnel diffrente des prcdentes qui permet de dmontrer les possibilits fonctionnelles trs tt dans l'activit de test. C'est une suite de programmes crits tout particulirement pour le test et qui, une fois excute, ralise une fonction donne. La progression vers l'objectif final est contrlable en traant une courbe telle que reprsente figure 25.8 qui indique l'cart entre l'objectif planifi et la situation relle. Les avantages de cette mthode sont les suivants: M.C.S.E tests progressifs, dmonstration anticipe de fonctionnalits, obligation d'avoir des parties oprationnelles (code, matriel), matrise des interfaces et configurations, production rapide d'une documentation dtaille. 539

Partie 7 - CONDUITE DE PROJET

80 Nombre dobjectifs atteints 60 Prvision 40 20 0 Avril Mai Juin Juillet Ralit

-Figure 25.8- Enregistrement de la progression. Il s'agit d'une mthode qui consiste baser les scnarios de test sur la slection de chemins travers la hirarchie de la solution. 25.7.4. Remarques sur ces dmarches Citons quelques rgles de bon sens pour complter la prsentation prcdente: - Tester les choses les plus importantes d'abord. Les modules les plus spcifiques sont la base, car proches de l'environnement, en particulier pour les applications temps-rel avec contraintes de temps. Les problmes d'interfaage sont ainsi anticips puisqu'en rapport avec l'environnement. - Planifier une version prliminaire du systme. Quand la date de fin arrive, que faut-il avoir fini de prfrence: la base ou le squelette? Pour l'assemblage ascendant : le codage est complet mais rien de tangible ne fonctionne. L'assemblage descendant permet de montrer quelque chose de tangible, mais pas oprationnel compltement avec l'environnement. Dans les 2 cas, la situation est dsagrable. - La mise au point est plus facile par l'approche incrmentale. - Codage et test descendants en substitution d'une conception complte. Ceci ne doit se faire que lorsque les delais apparaissent courts. On ne peut alors procder que selon une dmarche descendante puisque les niveaux de base ne sont pas connus. 25.8. ENVIRONNEMENT POUR LE TEST Tout test ncessite un environnement de test. L'environnement rel n'est gnralement pas utilis ds le dpart mais un environnement simul. 2 classes de simulations sont exploitables : - simulation de l'environnement: elle requiert une volution en parallle avec le systme, car ncessaire pour l'activation des entres et l'observation des sorties. - simulation du support excutif: le support dfinitif (calculateur par exemple) n'est pas disponible. Le simulateur peut disposer de fonctions facilitant la mise au point (debugger). 25.9. TESTS AUTOMATIQUES Des outils de test automatique peuvent tre envisags pour les raisons suivantes: - assistance dans la production de tests et analyse des rsultats, - rduction du temps de test, - amlioration et fiabilit des tests. 540 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET Les outils exploiter sont fonction des phases. Pour la phase de conception : analyse automatique de la conception, simulation du systme. Pour la phase de ralisation: analyse statique pour la couverture de test, analyse dynamique pour le test des performances... 25.10. PLANIFICATION DES TESTS La planification des vrifications, validations et tests fait partie intgrante de la tche de planification de l'ensemble du dveloppement. Il s'agit de l'tablissement d'un document dcrivant les spcifications VVT et les procdures pour effectuer les vrifications. L'exigence impose pour les tests peut dpendre de l'application. On peut se baser sur 3 types de caractristiques: - taille de l'application (nombre d'instructions, par exemple : < 5000, entre 5000 et 10000, > 10000 ), - la complexit (faible, moyenne, importante), - contraintes critiques (critique, non-critique). Comme il s'agit d'une opration de contrle, elle doit se planifier simultanment au dveloppement. Le document de conception doit donc inclure la description des procdures de test et les rsultats attendus. L'approche pour la planification des tests est la suivante : - identification des spcifications pour VVT, compte-tenu des objectifs, - dtermination des contraintes pour ces activits, - slection des techniques, - plan dtaill des activits, ordonnancement, budgets, temps, ressources. La dmarche suit l'enchainement : Problme => Mission => Approche => Plan L'objectif de la planification est la production d'un plan d'action sous la forme d'un document. Un exemple de plan pour l'obtention de la CONFORMITE est donn dans le paragraphe suivant titre d'illustration. Pour le test de chaque sous-ensemble il s'agit donc de : - dfinir la ou les mthodes de test, - dfinir les procdures suivre, - aprs les tests, raliser un rapport de test. Un exemple de plan de test est aussi donn en fin du chapitre. Parmi les mthodes, la progression peut-tre: inspection, walkthroughs, revues, tests. Un diagramme temporel rsume le squencement des tests sur la base d'une dcomposition en procdures, modules, tches, comme l'indique la figure 25.9. 25.11. GUIDE POUR LA SPECIFICATION DU TEST On dtaille ci-aprs titre d'exemple [FATHI-85], les points qui doivent tre dcrits dans le document de synthse devant servir comme aide pour la spcification des tests.
-A- OBJECTIFS

- dfinir les rsultats tangibles de l'activit, critres de mesure pour dfinir si le rsultat est satisfaisant, - rles et responsabilits: 1) client et fournisseurs, pour s'assurer que le produit sera accept, 2) dveloppement/management : qualit et activits mesurables. M.C.S.E 541

Partie 7 - CONDUITE DE PROJET

Mois

Fonction i Fonction k

Fonction tester Intgration Test Echance test Echance conformit

-Figure 25.9- Reprsentation d'une planification.

-B- FACTEURS INFLUENCANT LACTIVITE

les ressources, le budget, les contraintes dordonnancement, mthodologies, standards, le personnel.

-C- SELECTION DES OUTILS ET TECHNIQUES

- tablir une liste des techniques et outils possibles pour atteindre chaque objectif, - faire une valuation partir de cette liste puis slectionner la solution.
-D- DEVELOPPEMENT DUN PLAN DETAILLE

- budget, ordonnancement, information, - formation, acquisition des outils, ou dveloppement. 25.12. GUIDE POUR UN DOCUMENT DE TEST Les documents de test doivent tre rdigs durant les phases de spcification et de conception. C'est donc en partie une responsabilit des concepteurs. L'existence de ces documents, et donc au pralable une rflexion sur les procdures de test peut conduire des amliorations du dveloppement pour faciliter les vrifications. On dcrit ci-aprs un modle de document de test pouvant servir comme guide. 25.12.1. Information gnrale - SOMMAIRE Rappeler les fonctions du systme ou du sous-ensemble et les tests assurer. 542 M.C.S.E

Ch 25 - CONFORMITE DUN PROJET - ENVIRONNEMENT ET OBJECTIFS Rappeler l'origine du projet. Identifier la place du systme ou du sous-ensemble pour le client. - REFERENCES Documents dj publi en rapport avec le projet. Documents concernant des projets similaires. 25.12.2. Plan - DESCRIPTION DE LA FONCTIONNALITE A TESTER Dcrit brivement les entres, sorties et fonctions assures par le systme ou lentit tester. - LIEU DE TEST Identifie les participants, le lieu du test. - ORDONNANCEMENT Dcrit en dtail les dates et vnements pour le test.

- LES CONTRAINTES Description des ressources ncessaires: Matriel: priode d'utilisation, type et quantit des quipements indispensables. Logiciel: liste des logiciels permettant les tests. Personnel: nombre et comptence du personnel dsir durant la phase de test. - LES DOCUMENTS POUR LE TEST Documentation sur les tests. Documentation sur la fonction ou entit tester. Les entres pour les tests et les observations faire. Procdures de test. - FORMATION POUR LES TESTS Dcription du plan de formation pour la ralisation des tests : spcification des types de formation, personnel former, et quipe de formateurs. 25.12.3. Spcification des tests - PROCEDURES Rappel des fonctionnalits. Description des fonctions tester. Relation entre fonctions et tests. Enchainement des tests: description du cycle de test. - METHODES ET CONTRAINTES Mthodologie: description de la mthode et de la stratgie pour le test. Conditions: spcifie le type d'entre utiliser, le volume et la frquence des donnes. M.C.S.E 543

Partie 7 - CONDUITE DE PROJET Enregistrement des rsultats: prcise la mthode et les moyens utiliss pour la mmorisation des rsultats des tests. Contraintes: indication des limitations du test, tels que interfaces, quipement. 25.12.4. Evaluation des tests Critres: description des rgles utiliser pour valuer les rsultats. Synthse: description des techniques utiliser pour dduire les diagnostics partir des donnes enregistres. 25.12.5. Description des tests Description pour chaque sous-ensemble tester: type de tests: manuel, automatique, semi-automatique, squencement d'oprations, entres: dcrit les donnes d'entre et commandes pour le test, sorties: dcrit les rsultats attendus et les messages produits, procdures: spcifie pas pas les procdures pour accomplir le test.

544

M.C.S.E

Chapitre 26

MAINTENANCE
"Maintenance should not be used as a training ground where junior staff are left to sink or swim" E. T. FATHI

Le domaine de la MAINTENANCE prend un intrt croissant au vu des articles sur le sujet. L'effort ncessaire vient de la simple constatation que le cot pour maintenir les systmes existants est au moins aussi lev que le cot de dveloppement de nouveaux produits. Les responsables d'applications logicielles estiment mme que le cot de maintenance va jusqu' 60 70 % du cot total de l'application. Les causes sont multiples. D'une part, il y a augmentation considrable des produits maintenir. L'volutivit du logiciel, les volutions des spcifications, le nombre des erreurs bien suprieur zro la fin de la phase de dveloppement sont quelques unes des raisons. D'autre part, le manque de techniques et de mthodes pour la maintenance et en amont pour rduire cette maintenance, conduit amplifier les problmes. Pour obtenir de meilleurs rsultats, les points suivants doivent tre approfondis: - amlioration des outils, des mthodes, des techniques, - mise en place d'un management de la Maintenance. Aprs avoir prsent les divers problmes et dfini la terminologie, ce chapitre voque les mthodes et techniques qui peuvent aider amliorer la maintenance des produits en l'organisant, rduisant ainsi les cots d'exploitation. Ce travail vient en complment par rapport l'apport mthodologique qui contribue par le critre de maintenabilit rduire les problmes de maintenance.

M.C.S.E

545

Partie 7 - CONDUITE DE PROJET 26.1. TYPES DE MAINTENANCE La MAINTENANCE est la ralisation des activits ncessaires pour garder un systme oprationnel et assurer sa responsabilit aprs qu'il ait t accept comme produit l'issue de la production et de la priode de garantie. Il s'agit donc des activits qui introduisent des modifications, changements, rparations du produit aprs son dveloppement. En se basant sur une dfinition fonctionnelle, la maintenance dans son sens large est divisible en 3 catgories: - amlioration: changement, insertion, retrait, modification, extension de fonctions pour rpondre aux besoins. Il s'agit de l'amlioration pour: les fonctionnalits, les performances, la maintenabilit, la comprhension. Elle est applique au minimum suite des modifications de spcifications provenant d'une volution des besoins. Ce travail fait partie de la maintenance plutt que des dveloppements additionnels. Cette maintenance est ncessaire aussi bien en cas de dfauts que de succs: en cas de bon fonctionnement lors d'addition de nouvelles possibilits, en cas de mauvais fonctionnement pour fixer les dfauts. La maintenance prventive assure une amlioration du systme pour sa comprhension (structuration, documentation, mise jour...). L'optimisation conduit l'amlioration des performances et une rduction du cot de reproduction. La mise jour du produit et de toute sa documentation est ncessaire suite de telles modifications de spcification. - adaptation: il s'agit des modifications ncessaires pour satisfaire un nouvel environnement, ou pour s'adapter des changements dans l'environnement. Exemples: volution du matriel, du systme d'exploitation, de capteurs, donnes, des interfaces... - correction: elle concerne la correction des erreurs rsiduelles du dveloppement pour rendre le systme oprationnel. Elle ncessite une raction immdiate. 26.2. LES CAUSES DE LA MAINTENANCE La liste ci-dessous donne une classification des problmes de maintenance selon l'origine: - SYSTEME Manque de Qualit du systme pour la maintenance de : la conception, l'implantation, la ralisation, la documentation. - ENVIRONNEMENT DU SYSTEME Environnement volutif, Environnement perturbant. - MANAGEMENT Absence de politique pour la maintenance, Pas de contrle de la maintenance, Manque de techniques, de procdures, d'outils, Absence de responsabilits.

- UTILISATEURS Augmentation de la demande et des possibilits. 546 M.C.S.E

Ch 26 - MAINTENANCE - PERSONNEL Absence d'expertise, Problmes stratgiques, Absence d'attrait pour la maintenance. D'aprs la liste ci-dessus, les problmes proviennent de 2 catgories: des dfauts techniques, des dfauts d'organisation. On dveloppe dans la suite des rgles pour ces 2 domaines. Au pralable, explicitons tout d'abord quelques-unes des raisons qui induisent des problmes. 26.2.1. Qualit du produit dvelopp Un manque d'attention la qualit durant la conception et l'implantation conduit des cots levs en maintenance. Les concepteurs doivent prendre conscience de cet effet. Ceci justifie la ncessit du contrle et donc de rgles de qualit imposes par l'assurance qualit. Citons pour illustration, quelques exemples de dfauts : - mauvaise comprhension du problme par les concepteurs, - spcifications incorrectes, incompltes, peu claires, - conception primaire et complexe, manque de discipline, conception individualiste, - mauvaise implantation (codage pauvre), peu de structuration, - erreurs de logique qui rsultent de tests incomplets ou incorrects ou mauvaises conclusions, - utilisation d'un matriel dpass, - mauvaise dfinition globale des donnes de l'application, ceci est important pour la comprhension, - utilisation de plusieurs langages de programmation: cas du code machine, - effets de bord pour l'application, - trop de ressources ncessaires. Pour les erreurs qui imposent une correction immdiate, 4 causes sont considrer: - erreurs de spcification, - erreurs de conception, - erreurs de logique, - erreurs de ralisation (ralisation matrielle, codage). Il faut tout particulirement noter l'importance de la QUALITE des SPECIFICATIONS pour l'obtention d'un produit correct. COX cite 2 attitudes possibles des concepteurs vis--vis des spcifications: - attitude dfensive: les spcifications sont considres compltes et non-volutives, ce qui n'est jamais le cas surtout pour des projets consquents. Partant de cette hypothse, le produit sera ralis conforme aux spcifications. Toutes les volutions seront la charge de la maintenance puisqu'elles devront de toutes faons se faire, sinon le produit ne sera pas utilis. - attitude opportuniste: prendre en compte au fur et mesure les volutions souhaites. Pour cela , il faut adopter une mthode de conception qui facilite la prise en compte des modifications. Bien entendu, c'est cette deuxime attitude qu'il faut essayer de suivre pour rduire les cots de correction. M.C.S.E 547

Partie 7 - CONDUITE DE PROJET Les erreurs de conception proviennent dune mauvaise conception ou dune conception incomplte ou trop rapide. Les erreurs de ralisation sont une rsultante de la ngligence ou du manque de responsabilit. Elles sont les plus faciles corriger. 26.2.2. Documentation Elle est ncessaire pour la communication. L'homme de la maintenance doit d'abord comprendre le quoi, le comment et le pourquoi de chaque partie. Des mois ou des annes peuvent sparer la conception de la maintenance. De plus, les hommes de la maintenance ne sont pas les concepteurs. Les concepteurs peuvent aussi ne plus faire partie de la Socit. Sans documentation, l'information qui a disparu doit tre reconstitue. Une bonne documentation est la seule trace et donc le seul moyen de communication. Il s'agit d'un investissement long terme que doivent assumer les concepteurs. 26.2.3. Utilisateurs Trs souvent les utilisateurs sont incapables de dfinir avec prcision ce qu'ils veulent. Les spcifications sont ainsi incompltes et inadaptes. Plus un systme est russi, plus l'utilisateur demande des possibilits supplmentaires. D'o la ncessit d'un management pour filtrer les seules demandes justifies. De mme, si le systme n'est pas oprationnel, la demande est permanente pour obtenir le bon fonctionnement. Pour les demandes de modifications, elles sont souvent excessives, conflictuelles, vagues et exprimes sans connaissance de l'impact sur le travail de maintenance. Une gestion est ncessaire pour contrler le niveau de maintenance en ragissant auprs du demandeur et ceci en lui indiquant le cot et les consquences de sa demande. 26.2.4. Personnel Le travail de maintenance a tendance tre considr: - non important, - non intressant (unchallenging), - non cratif. Il est donc peu apprci par les utilisateurs et le reste de la socit, tout particulirement par les concepteurs. Pourtant ce travail ncessite des qualits particulirement importantes: effort, bonne qualification, exprience. Ce n'est donc pas a priori le travail de novices ou de dbutants car l'objectif est de satisfaire rapidement le demandeur en rendant le systme oprationnel avec efficacit et faible cot. Les qualits requises pour cette catgorie de personnel sont : - flexibilit, auto-motivation, responsable, cratif, disciplin, raisonnement analytique, finesse de raisonnement, expriment, mais aussi intuitif. 26.3. PROCEDURES POUR LA MAINTENANCE La maintenance intervient durant la phase oprationnelle du produit, c'est--dire la dernire phase du cycle de vie qui correspond la phase d'utilisation du produit. 548 M.C.S.E

Ch 26 - MAINTENANCE Le processus de maintenance est complexe et fait intervenir plusieurs personnes et mmes plusieurs quipes. Ce travail commence lorsqu'une demande de changement apparait. Il s'achve lorsque l'utilisateur a accept la modification et la documentation est mise jour. La table ci-dessous dcrit les tapes successives de la procdure de maintenance: 1 - Dtermination du besoin de modifications 2 - Soumission de la demande 3 - Analyse de la demande 4 - Approbation ou rejet de la demande 5 - Planification de l'opration 6 - Analyse pour la conception 7 - Revue pour la conception 8 - Modification et mise au point 9 - Revue des changements proposs 10 - Test 11 - Mise jour de la documentation 12 - Audit 13 - Acceptation par les utilisateurs 14 - Installation des modifications et impact sur le produit 15 - Fin de l'opration Cette liste montre qu'il s'agit de reprendre une partie du cycle de vie: spcification, conception, implantation, test. Des difficults existent. Il s'agit de faire des modifications dans un systme existant. Plus le produit est ancien (peu de documentation, peu d'outils...), plus le problme est difficile: ncessit d'une comprhension par une dmarche rgressive... Parfois mme, il devient plus intressant et plus rentable de redfinir un nouveau produit, surtout avec l'volution actuelle de la technologie. Des critres servent dterminer l'intrt ou non de poursuivre les volutions. D'autre part, une procdure de contrle des modifications doit tre impose pour rduire les cots. 26.3.1. Alternative: maintenance/nouvelle conception La dcision rsulte de la comparaison entre les 2 solutions possibles: poursuivre ou faire une nouvelle conception. La liste ci-aprs indique quelques raisons poussant une nouvelle conception: - pannes frquentes du systme, - conception ancienne 7 10 ans pour le matriel ou le logiciel, - structure et logique complexe du systme, - technologie prime, - modules trop importants, - consommation de trop de ressources, - paramtres non-volutifs, - difficult de conserver une quipe de maintenance, - dficience srieuse de la documentation, - spcifications non satisfaites ou incompltes. M.C.S.E 549

Partie 7 - CONDUITE DE PROJET 26.3.2. Mthode de contrle des changements Pour contrler les volutions, il y a ncessit de dfinir une politique de gestion et de contrle des oprations de maintenance , ce qui implique des rgles. La liste ci-aprs donne quelques suggestions, pour le contrle des modifications: requte formelle et crite pour toutes les modifications, revue de toutes les demandes et limitations aux seules approuves, analyse et valuation du type et frquence des demandes de modification, valuation du degr de ncessit du changement et son usage anticip, valuation des modifications pour s'assurer qu'elles ne sont pas incompatibles avec l'tat du systme, aucun changement ne doit tre excut sans une ide exacte de la complexit et des ramifications, valuer si la modification conduira une amlioration ou dgradation des performances, approuver un changement seulement si le bnfice surpasse le cot, ordonnancement de toute la maintenance, imposer la documentation et l'implantation conformment des standards, imposer que toutes les modifications exploitent les techniques modernes, planification de la maintenance prventive.

La stratgie de maintenance est en partie lie au type de maintenance: amliorations, adaptations, corrections. Selon FATHI, l'estimation de charge pour les amliorations, est de l'ordre de 60 % de l'effort total de maintenance. Les demandes proviennent : de l'utilisateur, de la direction, de l'quipe de maintenance. Trs souvent, l'utilisateur n'est jamais compltement satisfait et la direction peut aussi solliciter des volutions, situation normale dans toute entreprise et qu'il faut planifier. L'quipe de maintenance peut constater des imperfections, des problmes potentiels. Compte-tenu du cot important, le management pour la maintenance est essentiel et doit se charger : d'analyser les demandes, de les spcifier, de leur d'assigner une priorit, de les ordonner. La rduction du cot passe par une politique globale permettant de coordonner les demandes: points communs, points en conflit ... Les adaptations reprsentent 20 % du cot de la maintenance. Cet effort est non-productif pour la socit. Le travail revient-il au dpartement qui a produit le systme ou l'quipe de maintenance? Attention aussi la difficult de communication, les concepteurs se dsintressant de ces problmes. Concernant les corrections (20 % restant), se pose d'abord le problme de l'identification des erreurs. Il est trs rare de produire un systme parfait, ce qui veut dire que ce travail existe toujours. Il se rduit en dfinissant des standards et des procdures durant le dveloppement et la maintenance. Ceci conduit devoir respecter des rgles: c'est le rle de l'assurance qualit. 26.4. SOLUTIONS POUR AMELIORER LA MAINTENANCE Le remde est la MAINTENABILITE qui est un remde technique. La maintenabilit est la facilit que possde un systme supporter des changements pour satisfaire les demandes des utilisateurs et pour corriger les dfauts dtects. 550 M.C.S.E

Ch 26 - MAINTENANCE Elle s'obtient par une considration durant tout le cycle de vie. C'est un des critres de qualit impos tout dveloppement. D'o la ncessit d'avoir la maintenance toujours l'esprit. En conception et en ralisation, les rgles de bon sens et les outils pour induire cette qualit sont par exemple: - guide pour les spcifications et la conception, - guide pour l'criture du code, la ralisation du matriel..., - emploi des langages de haut niveau, - structuration, modularit, cohrence, couplage limit, - standardisation des dfinitions des donnes, - bonne documentation, qui s'observe par la facilit de trouver l'information ncessaire pour la maintenance, documents jour. Apparat alors, le problme de la maintenance de la documentation. Souhaiter cette qualit de maintenabilit ne suffit pas, il faut l'imposer et pour cela elle doit tre observe sur les dveloppements durant les phases initiales. Son observation est dfinie par l'assurance qualit. La technique utiliser est celle des revues avec un spcialiste de la maintenance: - revue par paire: pour la spcification, la conception, la programmation, l'autocorrection. Ceci ne doit surtout pas tre pris comme un moyen d'valuation des aptitudes et performances de la personne reviewe. - wallthroughs: 2 ttes valent mieux qu'une. La personne concerne fait une description dtaille de la solution propose. Les reviewers posent des questions pour clarifier des points et mettent en vidence les erreurs et problmes potentiels. Le responsable de la maintenance doit tre prsent pour: - une bonne acceptation par tous de l'objectif, le raffinement des bonnes ides, llimination des mauvaises. - pour valuer le stade d'avancement, comprendre le systme, juger de la qualit pour la maintenance. 26.5. LES OUTILS DE MAINTENANCE Les tches de maintenance ncessitent des outils identiques ceux utiliss pour le dveloppement. En supplment, il faut disposer de procdures et outils pour le diagnostic des dfauts, l'valuation des performances et autres. Comme le dveloppement impose la cration de tels outils pour les phases de vrification et de validation, ces outils doivent tre utilisables. Pour cela, les hommes de la maintenance doivent participer durant le dveloppement la spcification de ces outils qui leur seront utiles par la suite. En complment, la gestion des corrections et des volutions peut tre facilite par l'emploi d'outils informatiques spcifiques. M.C.S.E 551

Partie 7 - CONDUITE DE PROJET 26.6. MANAGEMENT DE LA MAINTENANCE Grer tous les problmes de maintenance ncessite une organisation similaire celle indispensable pour tout projet de dveloppement. On rappelle ici l'organisation et les activits ncessaires. 26.6.1. Objectif et activits L'objectif est simple: il s'agit de garder tous les systmes en fonctionnement et rpondre aux demandes des utilisateurs en temps voulu et d'une manire satisfaisante. Pour cela, le responsable de la maintenance doit assumer une tche essentielle qui consiste : - conserver l'activit de maintenance ordonne et contrle, - conserver les systmes, produits, et applications oprationnels, - conserver les utilisateurs satisfaits, - conserver les hommes de la maintenance contents, - faire en sorte que la maintenance soit vue comme un aspect positif qui contribue aux objectifs de l'entreprise et non comme une obligation pour compenser les ngligences. Les activits du manager sont: - ordonnancement des changements, - ngociation avec les utilisateurs, - coordination des activits de l'quipe, - dfinition des outils et rgles de travail. Pour chaque modification, les tches entreprendre sont les suivantes: - valuation du travail pour une demande, - estimation de l'effort ncessaire, - assignation d'une priorit, - ordonnancement, - suivi du travail, - vrification de la conformit aux rgles durant la maintenance, - rgler les conflits, - insuffler le moral aux quipes. Le management impose des techniques et mthodologies. Une double comptence en technique et en management est donc un prrequis pour cette fonction dlicate. 26.6.2. Rgles pour la maintenance Pour viter une dispersion de l'nergie de l'quipe de maintenance, citons quelques rgles de bon sens qui conduisent rduire le cot tout en donnant satisfaction aux demandeurs: - Revue et valuation de toutes les demandes. Chacune doit tre pleinement justifie. L'impact sur les autres tches doit tre value. - Planification et ordonnancement des actions de maintenance: assignation d'une priorit, ordonnancement des tches, excution conformment la priorit. 552 M.C.S.E

Ch 26 - MAINTENANCE - Restriction de toute modification la demande approuve et planifie. - Mise jour de la documentation et respect des standards par des revues et des audits. 26.6.3. gestion des quipes Ce point est aussi important que les aspects techniques et mthodes. Compte-tenu de la sparation entre la maintenance et le dveloppement, il est intressant dans sa carrire dexprimenter les deux activits pour tirer les consquences de ses actes. En effet, constater les difficults en maintenance doit avoir ensuite des rpercussions extrmement positives en conception. Les quelques conseils suivants peuvent servir de base la dfinition d'une politique de gestion de la maintenance: - La maintenance est aussi importante que le dveloppement, tout aussi difficile et essentielle. - Les hommes de la maintenance doivent tre particulirement qualifis, comptents et motivs. L'quipe ne doit pas tre isole du reste et le turn-over doit rester faible. - La maintenance ne doit pas tre considre comme un passage oblig o l'on apprend " couler ou nager". - Une rotation du personnel doit permettre le passage du dveloppement la maintenance et rciproquement. Les expriences permettent de prendre conscience de ses actes. - De bonnes performances en maintenance doivent tre correctement rmunres comme en dveloppement. - L'quipe doit tre correctement forme. Ceci entretient la performance et minimise les problmes de moral. - Modifier les affectations et l'organisation pour ne pas permettre une partie du personnel de devenir un domaine priv dans l'organisation, car ceci conduit une perte du contrle et donc une perte defficacit.

M.C.S.E

553

Chapitre 27

DOCUMENTATION DUN PROJET

"Most programmers regard documentation as a necessary evil, written as an afterthought only because some bureaucrat requires it. They do not expect it to be useful." Mathematicians diligently polish their proofs, usually presenting a proof very different from the first one that they discovered..... The simplest proofs are published because the readers are interested in the truth of the theorem, not the process of discovering it. Analogous reasoning applies to software. Those who read the software documentation want to understand the programs, not to relive their discovery." D. L. PARNAS L'laboration de la documentation pour les projets est une tche essentielle qui augmente la dure de vie du produit. Activits indispensables couvrant l'ensemble du cycle de vie du produit, le management et la production de la documentation doivent tre planifis. Pour justifier ce que doit tre la documentation pour un projet, la dmarche suivie est la suivante : 1- justification fonctionnelle : pourquoi, 2- structure hirarchique pour les documents : quoi, 3- planification: quand, 4- mthodes et dmarches : comment.

M.C.S.E

555

Partie 7 - CONDUITE DE PROJET 27.1. JUSTIFICATION FONCTIONNELLE Un document reprsente une mmorisation structure d'une collection d'informations. Tout d'abord un document n'est utile que s'il sert. Il est donc ncessairement un lment d'interface entre 2 ou plusieurs activits, ralises parfois par les mmes personnes, mais le plus souvent par des personnes diffrentes. Le contenu d'un document se dfinit partir du rle qu'il doit jouer dans le projet: quels sont les lecteurs du document?, quelle est la connaissance a priori du contexte pour ces lecteurs?
corrections lecteurs Utilisateur 1

Rdacteurs

Doc.

Catgories dutlisateurs

Utilisateur N

-Figure 27.1- Rle du document comme interface. Pour l'objectif assign, un document doit contenir l'information strictement ncessaire mais suffisante. On peut distinguer 4 fonctions joues par la documentation: - communication, - documentation de rfrence, - support pour l'assurance qualit, - rfrence historique.
-A- COMMUNICATION, INTERACTIVITE

Tout projet fait intervenir plusieurs personnes. Il est ainsi divis en tches ou activits. De manire rduire la perte d'efficacit de aux changes directs entre personnes, le document sert comme moyen indirect et permanent pour l'change. Il s'agit donc d'une formalisation du processus d'change. On obtient de cette manire une indpendance par rapport aux personnes : absence, maladie, dpart de la socit.... Le rle est d'autant plus important que le projet est consquent et long et quil conduit une priode importante de maintenance. On doit pouvoir faire admettre aux concepteurs l'ide que les documents reprsentent l'objet final produire, par analogie avec la mcanique, domaine pour lequel les plans sont reprsentatifs de la pice. Ceci deviendra de plus en plus vrai avec l'volution vers l'lectronique compltement intgre, la production automatique des composants, la production automatique des programmes.
-B- DOCUMENTATION DE REFERENCE

Une telle documentation sert de base pour la formation de nouvelles personnes sur la connaissance du produit. Bien faite, elle reprsente l'accumulation de l'exprience, ce qui permet la transmission. 556 M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET Elle sert aussi pour la maintenance du produit qui est gnralement effectue par d'autres quipes durant les mois et annes qui suivent le dveloppement. Il ne faut pas non plus oublier son exploitation comme notice d'utilisation et comme manuels de rfrence du produit.
-C- SUPPORT PUR LASSURANCE QUALITE

Pour obtenir la qualit, il faut pouvoir observer le produit de prfrence avant sa ralisation finale. Les documents contribuent cette observation: - comprhension de la solution et donc sa structuration, - adquation aux spcifications, compltude, lisibilit. Les documents servent de base pour les runions d'analyse (revues, audits) des stades bien dfinis.
-D- REFERENCE HISTORIQUE

Elle sert comme mmorisation de toutes les phases, des rflexions, des solutions sur le projet. Ceci permet ensuite la rutilisation de ces ides et des solutions pour de nouveaux projets, vitant ainsi les erreurs passes en concentrant son temps et son nergie sur les points prioritaires. 27.2. STRUCTURATION DES DOCUMENTS Aprs avoir dfini l'objectif de la documentation, intressons-nous son contenu et tout particulirement la forme. 27.2.1. Hirarchie des documents Il s'agit de dcrire l'ensemble des documents ncessaires pour un projet. Bien videmment, le contenu de la documentation dpend de la nature et de la complexit du projet, de la mthodologie suivie pour le dveloppement. Pour cela, on se place ici dans le cas d'une certaine complexit de systme temps-rel, dvelopp avec application de la mthodologie MCSE. La figure ci-aprs dcrit la hirarchie des documents ncessaires. La documentation est classe en 2 catgories: - les documents de dveloppement (what, how), - les documents de contrle. Les documents de dveloppement sont techniques. Les documents de contrle servent au management du projet. Cette hirarchie est celle de la documentation exige ou utile lorsque le projet est sign. Au pralable, d'autres documents sont ncessaires pour l'obtention du contrat. Ils peuvent s'inclure dans les prliminaires. On dcrit ci-aprs le rle de chaque type de document. M.C.S.E 557

Partie 7 - CONDUITE DE PROJET

Documents prliminaires Documents de contrle

Plan de projet Management Droulement

Documents de dveloppement
Spcifications Conception fonctionnelle Dfinition de la ralisation Ralisation Tests

Manuels
Manuel opratoire Manuel utilisateurs

Documents de maintenance

-Figure 27.2- Structuration de la Documentation. 27.2.2. Documents prliminaires Ces documents regroupent: - la demande exprimant la raison initiale du projet, - l'tude de faisabilit qui envisage les diverses solutions et options et le cot correspondant. Ceci permet de dduire la meilleure proposition. - le plan du projet initial qui identifie: les ressources ncessaires, temps et cots pour l'aboutissement , personnel et quipement. 27.2.3. Documents de contrle Ces documents ont pour objectif de disposer d'une mthode qui permette de conduire le projet conformment au plan de dpart et de manire constater et informer des dviations significatives par rapport au plan. Ces documents concernent : le plan de projet, le management et le droulement.
-A- PLAN DE PROJET

Il sert essentiellement comme document de coordination entre le manager et tous les participants au projet. Ce document ou ensemble de documents couvre le cycle de vie complet. Il faut noter l'intrt des modles graphiques pour disposer d'une prsentation synthtique (diagramme GANTT, PERT...). On peut citer comme liste des constituants [JENSEN-79]: - Prsentation des documents : objectifs du plan et identification des documents. - Description technique du projet : pour la comprhension du document. 558 M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET - Plan dorganisation : diagramme d'organisation, rles, et responsabilits de chaque lment, arrangement avec d'autres entreprises. - Mthodologie : pratiques, standards, techniques utiliss pour l'assurance qualit. - Configuration pour le management : il dcrit comment sont effectus les contrles pour chaque phase, date pour chaque document, revues. - Plan des informations de management : toutes les donnes transmettre au demandeur et les donnes internes: financier, statuts, logistique.... Comment les donnes sont collectes, formates, transmises. - Description des ressources : toutes les ressources ncessaires et la manire dont elles seront utilises: dfinition de l'nergie, (Manpower et quipements). - Description de la documentation : liste de tous les documents, dates de fourniture et revues, procdures interne et externe de revue. - Plan des tests : plan pour tous les tests unitaires et tests d'intgration. - Plan de formation : des utilisateurs pour le fonctionnement et la maintenance. - Plan de scurit : cas des systmes avec scurit : procdure suivre. - Ordonnancement : (program plan) dcrit les vnements importants du projet : revues, meetings, audits,...)
-B- MANAGEMENT

Ce document prsente 3 ordonnancements qui se dduisent les uns des autres : - Tches : dure, le nombre de personnes, et qualification du personnel, quipement ncessaire, des points de repres temporels dfinissant des stades d'avancement.

- Ressources : en personnel et en quipement pour l'ensemble du projet. - Financier : tat et financier pour cot
-C- DEROULEMENT ET EVALUATION

le personnel pour l'ensemble du projet l'quipement

Ce document contient la mmorisation du droulement du projet et l'ensemble des activits du personnel. - Droulement : apprciation sur la mthode, choix des alternatives, analyse des erreurs, problmes majeurs... M.C.S.E 559

Partie 7 - CONDUITE DE PROJET - Activits : structure des groupes de travail, activit de chacun, temps pass pour chaque phase, erreurs et temps de correction. Compte-tenu du principe de management, la mthode de contrle et qui sert comme base pour la ralisation de la documentation de contrle, peut se rsumer par le diagramme qui suit:
Projet MANAGEMENT Dtail des activits prvues CONFIGURATION

Ressources(t) DEVELOPPEMENT

Rsultats(t)

Dviation(t) + CONTROLE EVALUATION(t)

Documents

-Figure 27.3- Intrt des documents pour le contrle du projet. L'valuation conduit un effet correcteur de manire toujours satisfaire au mieux les objectifs. Elle permet de connatre l'tat d'avancement du projet et incite faire converger vers l'objectif. C'est cette stratgie et son suivi durant le projet qui doivent se retrouver dans la documentation de contrle. 27.2.4. Documents de spcification, de conception, de ralisation, de tests Ces documents dcrivent toutes les caractristiques du produit dvelopper, puis la solution retenue selon une prsentation descendante. On trouve en final, la description complte de la ralisation matrielle et de l'implantation logicielle. Les procdures de tests, de vrification, de validation et les rsultats obtenus sont aussi inclus dans cette partie de la documentation. Le plan de cette documentation est conforme la mthodologie employe. Chaque partie du document est le rsultat l'issue de chaque tape. On donne ci-aprs le plan pour la mthodologie MCSE. 1- SPECIFICATION Modlisation de l'environnement Interface avec le systme spcifications fonctionnelles spcifications opratoires spcifications technologiques

2- CONCEPTION FONCTIONNELLE 560 dlimitation du systme concevoir premire dcomposition fonctionnelle spcification et raffinement fonctionnel pour chaque fonction Description de chaque fonction lmentaire synthse: structure fonctionnelle finale M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET 3- SPECIFICATION DE LA REALISATION introduction des rpartitions gographiques introduction des interfaces avec l'environnement valuation des contraintes de temps rpartition matriel/logiciel structure d'excution implantation logicielle spcification de la ralisation matrielle

4- REALISATION description de la solution matrielle description de la ralisation logicielle 5- TESTS dfinition des rgles spcifiant la vrification, la validation, la certification philosophie des tests et mthodes procdures de test pour chaque sous-ensemble, pour chaque niveau un plan de droulement des tests les rsultats

27.2.5. Les manuels Un systme n'est utilisable et maintenable que si des manuels dcrivent son installation, son exploitation, sa maintenance. Chaque type de manuel est ddi pour une catgorie spcifique d'utilisateurs.
-A- MANUEL OPERATOIRE

Il a pour objectif, la comprhension du comportement du systme, particulirement pour la maintenance. Pour cela, il dcrit le fonctionnement du systme ainsi que l'environnement ncessaire pour qu'il soit oprationnel. Plus prcisment, il dcrit les procdures pour effectuer des fonctions particulires sur le systme. Il peut servir comme manuel d'aide la maintenance.
-B- MANUELS UTILISATEUR

Il dcrit les fonctions du systme sans dcrire comment ces fonctions sont implantes. L'objectif est que tout utilisateur doit tre capable, partir de cette description simple et claire (terminologie non technique), de dterminer l'applicabilit, quand et comment utiliser le produit. On peut citer 3 catgories de manuels : - manuel d'introduction, - manuel d'installation, - manuel d'utilisation. A noter l'importance de la qualit de cette catgorie de document. Il ne doit pas tre ncessaire de lire tout le document pour se servir du systme. Ceci impose une classification des informations selon plusieurs niveaux d'utilisation. M.C.S.E 561

Partie 7 - CONDUITE DE PROJET 27.2.6. Document de maintenance Il sert inventorier : - les demandes de changement ou d'volution, - les corrections, - les adaptations l'environnement. Les demandes sont ensuite analyses et values : cot, temps, priorit. Pour chaque changement, une valuation est faite. Aprs modification du produit, tous les documents prcdents concerns par des changements sont mis jour. 27.3. PLANIFICATION POUR LA DOCUMENTATION La planification est spcifie par des diagrammes. Ils dcrivent les dates de production des documents avec signification de l'tat : par exemple T pour temporaire, F pour final. Les documents sont produits des dates qui correspondent l'ordonnancement du dveloppement. Ils servent aussi pour l'assurance qualit : revues, audits... Le diagramme est prsent en concidence avec le cycle de vie et les tapes du dveloppement. La figure suivante montre la planification pour la documentation en suivant la mthodologie MCSE. Pour chaque tape, le document dfinitif est obtenu aprs 2 ou 3 lectures selon un cycle auteur-lecteurs.
MCSE Documents Spcification Conception fonctionnelle Conception dtaille Ralisation matriel Ralisation logiciel Test unitaire Test ensemble Test application
T T

ETAPE DU CYCLE DE VIE

Conception Spcification fonctionnelle Dfinition de Ralisation la ralisation

T T F T T F

Test et intgration

T T

F F

T T T

F F F

Temporaire

Final

-Figure 27.4- Planification de la documentation pour MCSE. 27.4. PROCEDURES POUR LA DOCUMENTATION 27.4.1. Problmes et causes Citons 3 types de situations anormales pour un projet: - absence de documentation, - documentation incomplte, - documentation inadquate. 562 M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET Les causes peuvent tre multiples: - faible priorit pour la documentation, - absence de ressources pour sa ralisation, - absence de planning, - absence de spcification de la documentation, - attitude du personnel: on n'aime pas, travail non productif et non cratif, peu valoris, travail non visible. Les 4 premiers points correspondent des facteurs impersonnels qui sont lis des attitudes de l'organisation. Le dernier point est dlicat. Au recrutement du personnel, cette aptitude doit tre value. Ensuite, elle doit tre valorise par une politique volontariste des responsables de la socit. 27.4.2. Niveaux de qualit de la documentation Il n'est pas suffisant de produire des documents sous prtexte que la procdure ou le contrat l'exige. Ces documents doivent possder une qualit. Cette qualit doit tre dfinie et planifie. La non-observation des rgles de qualit conduit des documents plus difficiles exploiter. La qualit concerne : - la forme : plan du document, - le fond : consistance et clart de l'argumentation. 4 niveaux de forme peuvent tre considrs selon l'objectif: - niveau minimum: pour le simple usage (projet de 1 mois), - niveau interne: pour la connaissance interne l'entreprise et ceci pour un produit qui ne sera pas partag, - niveau document de travail: pour des projets raliss par plusieurs personnes et quipes (documents taps, reviews), - niveau publication: pour une utilisation gnrale dans l'organisation ou faisant partie du produit livrer: manuel utilisateurs. 27.4.3. Procdures Les solutions pour obtenir une documentation adquate sont d'ordre technique et de management. Tout d'abord, il y a ncessit d'un groupe pour la documentation : - convaincu de son importance, - soutenu par le management, - produisant des donnes et rgles utilisables: dfinition de disciplines, standards, critres de qualit, disponibilit des moyens, intgration de ce travail dans le travail journalier, revues pour assurer la conformit la discipline, procdures, et observation de standards et guides. 563

M.C.S.E

Partie 7 - CONDUITE DE PROJET Pour l'entreprise, les questions importantes se poser sont les suivantes : - Une dcision a-t-elle t prise pour l'obtention d'une documentation adquate? - Des rgles ont-elles t dfinies pour la qualit? - Une personne a-t-elle t charge de la responsabilit: de prparer, de faire dvelopper et valider la documentation? - Des ressources ont-elles t mises disposition? - Qui a la responsabilit de la qualit? - Des relations ont-elles t tablies entre les divers groupes de dveloppement et entre stades? - Le temps et le cot pour la documentation ont-ils t considrs dans l'ordonnancement et le cot du projet? - Des standards existent-ils ou sont-ils dfinis? - Dispose-t-on des outils pour la cration et la gestion de la documentation? Pour obtenir un rsultat convenable, il faut appliquer les mmes principes que ceux utiliss pour obtenir la qualit pour un projet. Il faut donc : - laborer un plan de documentation, - dfinir des procdures et vrifier la conformit. On dcrit ci-aprs chacun de ces points.
-A- PLAN DE DOCUMENTATION

Un plan doit tre labor pour servir comme moyen de communication et comme guide de travail et de contrle. Celui-ci doit dcrire pour chaque document exig: - quel document est produire (what), - comment doit-il tre structur (how), - quand faut-il l'laborer (when), - par qui doit-il tre rdig (by whom). Concernant les informations dcrivant chaque document, on peut trouver : - le type de document, son contenu, son utilisation. - le format et son identification, ceci de manire faciliter la maintenance de la documentation et l'analyse de la qualit. Un certain nombre de socits dveloppent leurs propres standards. - le planning, qui contient un diagramme dcrivant les activits ncessaires pour la production du document: stade de dveloppement, revues,... et la date de gnration du document, puis les cycles auteurs-lecteurs qui conduiront sa validation. Pour des projets consquents, toute la documentation est gre par un gestionnaire qui maintient : - la chronologie des vnements significatifs, - un index des documents sur le projet, - l'ensemble de la documentation.
-B- PROCEDURES

Des revues formelles doivent tre effectues des stades prcis durant le cycle de vie du projet. Celles-ci sont incluses dans la mthode de dveloppement car la production des documents fait partie intgrante de la procdure globale. 564 M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET Les points essentiels pour la bonne russite du projet concernent l'analyse des spcifications et l'analyse de la conception diffrents stades. - Analyse des spcifications L'objectif est de s'assurer que les concepteurs ont bien compris tous les aspects du problme soulev par le client, que toutes les contraintes ont t recenses. Un bon document de spcification contribue la garantie d'un rsultat correct. Le client et les utilisateurs du systme doivent ncessairement participer aux runions et approuver le document. Il sert alors comme base contractuelle. - Analyse des conceptions Plusieurs stades d'analyse sont ncessaires : - revue de la conception fonctionnelle, dite aussi conception prliminaire, - revue de la conception dtaille, qui conduit une analyse complte de la solution, ainsi que des mthodes et procdures de test. - revue de la solution pour la ralisation qui a pour objectif l'analyse de la solution matrielle et de l'implantation logicielle, ainsi que la cohrence de l'ensemble. - Gestion de la documentation Cette gestion de la documentation est base sur un descriptif du cycle de vie pour les documents, savoir : prparation, les stades de gnration, les revues, acceptation, contrle qualit, distribution et contrle de la documentation, archivage et mises jour ultrieures. 27.5. GUIDE POUR LA REDACTION DES DOCUMENTS Trs souvent, la rdaction de la documentation et tout particulirement les manuels d'utilisation et de maintenance, est affecte au personnel le plus jeune, le moins expriment, et comme travail marginal par rapport l'effort investi sur le projet. En rsultat, les manuels sont de mdiocre qualit, incomplets et peu adapts aux utilisateurs. 27.5.1. Dfauts d'un document PARNAS indique quelques points forts concernant la documentation [PARNAS-86]. Une documentation non utilise avant sa publication et considre comme pas importante par son auteur sera toujours mdiocre. Un dfaut caractristique est souvent son manque de compltude, mais il ne s'agit pas l des problmes les plus srieux. Si c'tait le cas, ils pourraient tre complts et corrigs sans difficults. D'autres dfauts sont bien plus difficiles corriger:
-A- MAUVAISE STRUCTURATION

Un document peut rsulter d'un flot de pense ("stream of consciousness") ou d'un flot d'excution ("stream of execution"). Le premier exprime le fait que l'auteur crit dans l'ordre de sa pense, le deuxime dcrit le systme dans l'ordre d'apparition des vnements durant le projet. La difficult avec de tels documents est que les lecteurs ne peuvent pas trouver l'information qui les intressent. On ne peut alors pas savoir s'il manque des informations. Aprs une modification sur le projet, la mise jour n'est pas vidente. M.C.S.E 565

Partie 7 - CONDUITE DE PROJET

-B- DESCRIPTION LIMITEE (MYOPIE)

Un document crit lorsque le projet est presque fini ne contient plus les informations sur les dcisions importantes. On y trouve plutt tous les petits dtails, ce qui le rend uniquement exploitable par les personnes qui connaissent particulirement bien le systme, mais reste impntrable pour les nouveaux. 27.5.2. Principes pour la rdaction Le premier travail consiste comprendre la situation des lecteurs et les tches que ceux-ci doivent entreprendre avec la documentation. En effet, le plan du document est dpendant de la connaissance priori du lecteur et des objectifs viss. On peut citer les remarques suivantes comme rgles [SCHNEIDERMAN-85]: - faciliter la recherche d'informations: prvoir des points d'entre, regrouper les informations cherches. - faciliter la comprhension des informations: rdaction simple, description concrte, expression naturelle. - exprimer l'information suffisante pour chaque tche: inclure toute l'information ncessaire, s'assurer de leur validit, exclure ce qui n'est pas ncessaire. Ayant pris conscience de la diffrence entre un bon et un mauvais document, il s'agit aussi de faire en sorte d'obtenir le document en temps voulu et pour un budget raisonnable. Pour obtenir des documents de qualit, il faut dfinir une politique complte pour la production de la documentation. La rdaction doit tre planifie et un personnel qualifi doit tre affect cette tche.
-A- PLANIFICATION

Un document est produire en temps utile pour qu'il soit exploit: spcification pour l'tape de conception, conception fonctionnelle pour la dfinition de la ralisation ... Tous ces documents sont ensuite utilisables pour la maintenance. L'avantage est certain lorsqu'il s'agit de faire intervenir de nouvelles personnes dans les quipes (Mythical Man Month effect).
-B- DEFINITION DE LA STRUCTURE

Il s'agit d'imposer une structure pour le contenu de chaque document. Celui-ci pose d'abord les questions auxquelles il doit rpondre. On y trouve ensuite la rponse aux questions. Le document ne doit tre rdig qu'aprs l'laboration du plan. Chaque aspect du systme n'est dcrit que dans un seul paragraphe, ce qui facilite la mise jour. 566 M.C.S.E

Ch 27 - DOCUMENTATION DUN PROJET La documentation est le mdium de conception et aucune dcision de conception ne doit tre prise tant que la solution n'a pas t introduite dans les documents. Il est important de pouvoir retrouver dans la documentation, pour chaque problme, toutes les alternatives envisages durant le projet. Pour chaque solution, on doit retrouver la raison du choix de l'une et le rejet des autres. Ralis de cette manire, plusieurs mois ou plusieurs annes aprs, concepteurs et hommes de la maintenance, se posant les mmes questions, trouveront la rponse dans une telle documentation. 27.5.3. Rdaction des manuels utilisateurs Si on s'intresse plus particulirement aux manuels utilisateurs, il faut tre conscient de la diffrence qui existe entre utilisateurs et concepteurs, qu'un bon concepteur n'est pas obligatoirement bon rdacteur, mais que le succs d'un systme peut tre troitement coupl la qualit de la documentation. Rdiger des documents est un travail hautement cratif. Ainsi, ce travail dans l'entreprise doit tre valoris. Les rdacteurs doivent avoir l'esprit que les utilisateurs ne possdent pas tous les mmes connaissances a priori. SCHNEIDERMAN cite 3 catgories de lecteurs: - Le lecteur connaissant la tche effectuer, mais peu familier de l'informatique ou de l'automatisation. Il faut alors partir de la tche et des concepts associs, expliquer les concepts apports par le produit, puis la syntaxe pour l'utilisation. - Le lecteur matrisant la tche et l'apport du systme. Une brve prsentation des concepts est suffisante, tandis qu'il s'agit d'expliciter la syntaxe en relation avec les oprations. - Le lecteur initi, qui ne recherche qu'un aide mmoire d'utilisation. Cette dcomposition en 3 catgories montre l'intrt d'une prsentation des manuels selon 3 parties: - une introduction au produit, - un manuel de rfrence, - un rsum d'utilisation. Un autre guide utile pour l'exploitation d'un systme est un diagramme d'activit de la mise en marche l'arrt. Ce diagramme reprsente les chemins qui orientent l'utilisateur en indiquant les transitions d'une activit aux suivantes. Pour le manuel utilisateur, la rdaction, les revues et tests peuvent se faire avant la fin de la ralisation du produit. En effet, une bonne rdaction peut servir clarifier le travail de dveloppement car il reprsente la rponse l'expression du besoin exprim par le demandeur. Les rdacteurs jouent alors un rle de critique participant ainsi l'obtention de la qualit.

M.C.S.E

567

Chapitre 28

GESTION DE LA QUALITE

Plutt que de dtecter les dfauts rsultants et ensuite faire information en retour et action corrective, zro dfaut sera obtenu seulement si vous dcelez l'erreur en cause derrire le dfaut au stade de l'erreur ; puis, si vous informez en retour, pour qu'une action corrective soit prise afin que l'erreur ne se transforme pas en dfaut. Nous ne pouvons absolument pas viter les erreurs, mais nous pouvons empcher qu'elles se transforment en dfauts. Shigeo Shingo

Le dveloppement de produits et tout particulirement la partie spcification et conception qui nous concerne est la rsultante d'activits humaines. L'erreur est malheureusement invitable. Par contre, les dfauts qui rsultent d'erreurs eux peuvent s'liminer, condition d'viter la propagation des erreurs. La gestion de la qualit est une pratique prventive pour rduire les imperfections, les erreurs et les dfauts qu'elles engendrent, de manire obtenir une augmentation de la productivit et de la qualit, pour minimiser les cots, les dlais, et pour maximiser la satisfaction du client. Le gain de productivit s'obtient en rduisant l'ampleur du processus itratif de correction. Il faut donc valider et contrler ds que possible pour viter la remise en cause ultrieure.

M.C.S.E

569

Partie 7 - CONDUITE DE PROJET En dehors des multiples erreurs de ralisation, des insatisfactions peuvent tre la rsultante de raisons que sont entre autres (le pourquoi): - dlais non tenus, - dpassement de prix, - produit ne correspondant pas au besoin, - manque de fiabilit, - mauvaise tolrance aux pannes matrielles et erreurs humaines, - difficult de mise en oeuvre, - maintenance ruineuse: difficult de maintenance corrective, difficult de maintenance volutive, non-rentabilit de la solution. La qualit est aujourd'hui un terme d'une trs large porte. Lorsqu'on fait tat de la qualit totale, on s'intresse tous les aspects: le produit bien-sr, mais aussi le service rendu, le personnel en charge de sa ralisation ... Dans ce chapitre, l'objectif vis est trs limit par rapport cette large problmatique. Il s'agit seulement de mettre en vidence les critres et rgles de qualit, les principes suivre pour obtenir ces qualits durant les phases de spcification et de conception. Dj, il faut tre conscient que les critres de qualit pour ces tapes ne sont pas simples exprimer, encore moins les mthodes de mesure puis d'induction de la qualit. Le terme qualit n'a pas le mme sens en production, ou en spcification conception. Pour la production, l'objet qui en rsulte est compltement dfini. Sa qualit de ralisation est donc tout fait mesurable. En spcification et conception, le rsultat n'est pas connu, puisque le travail a pour objectif de trouver une solution. La mesure de la qualit est donc bien diffrente. 28.1. TERMINOLOGIE Dfinissons tout d'abord le vocabulaire : - Qualit : elle exprime la totalit des caractristiques et possibilits d'un produit qui contribue satisfaire un besoin (utilisateur, mais aussi producteur, client). - Assurance qualit : C'est l'ensemble des actions planifies et systmatiques ncessaires pour s'assurer qu'un projet est conforme aux spcifications et qu'il possde les qualits voulues. - Contrle Qualit : Ce sont les actions qui dcoulent de l'assurance qualit et qui permettent de mesurer, de contrler la qualit, de dtecter les erreurs pour les corriger. Exemples de types de qualit : conomique, intgrit, document, comprhensible, modifiable, modulaire, sans erreur, fiable, souple, valid, gnral, testable, rutilisable, utilisable, clair, maintenable, portable, efficace, robuste, volutif, optimis. 28.2. PRINCIPE POUR LOBTENTION DE LA QUALITE Le principe de base sur lequel repose la gestion de la qualit consiste faire en sorte que chaque phase du cycle de vie, se concrtise par un produit intermdiaire qui puisse tre observ et recett (vrifications, contrles, mesures) comparativement des rgles de qualit prdfinies et exiges. Le schma d'organisation est donn figure 28.1. 570 M.C.S.E

Ch 28 - GESTION DE LA QUALITE

Dfinition
ASSURANCE QUALITE

rgles de qualit cycle de vie corrections

DEVELOPPEMENT

observation de la qualit

actions

CONTROLE

-Figure 28.1- Organisation de la gestion de la qualit. L'assurance qualit dfinit les rgles que doivent respecter les concepteurs et ralisateurs pour satisfaire les objectifs de la qualit. Durant le cycle de vie, chacune des phases produit des documents et ralisations qui expriment la solution chaque niveau intermdiaire. L'observation des documents et ralisations sert comme base pour le contrle de la qualit en assurant une comparaison entre les rgles imposes et les solutions. Des actions de correction sont alors entreprises pour satisfaire les rgles. 28.3. LES CRITERES DE QUALITE Il s'agit de l'expression des caractristiques en terme de qualit, spcifies par l'assurance qualit, et utiles pour la conception des systmes. Les critres sont trs importants: voir liste non-exhaustive dans la dfinition du mot qualit. Explicitons les principaux.
-A- FIABILITE

Le systme ou le produit ralise les fonctions attendues par l'utilisateur dans les conditions normales et avec les performances attendues. Dans le cas de conditions anormales, les fonctions sont ralises, mais avec des performances qui peuvent tre dgrades tout en restant correctes. Les mots-cls sont: adquat .correct .complet .consistant .faisable robuste (survivance dans un environnement hostile, pas vident de prvoir toutes les situations).

M.C.S.E

571

Partie 7 - CONDUITE DE PROJET

-B- TESTABILITE

Le systme possde les caractristiques facilitant le test et la mesure de performances, conformment aux spcifications. Les mots-cls sont: comprhensible .structur .concis .self-descriptif mesurable .accessible .communicable .quantifiable
-C- UTILISABILITE

Le systme possde une interface conviviale rpondant aux souhaits des utilisateurs.
-D- EFFICACITE

Les performances sont satisfaites sans ressources excessives.

-E- ADAPTABILITE (VOIRE TRANSPORTABILITE)

Ce critre exprime l'indpendance de la solution par rapport aux entres/sorties, (selfcontain), la portabilit sur d'autres matriels. Ceci est particulirement intressant pour le logiciel. Il conduit ensuite une minimisation du cot lors d'une volution de la technologie.
-F- MAINTENABILITE

Lorsque par sa simplicit et sa documentation, le systme est facilement comprhensible par le personnel charg de la maintenance, le produit est facile modifier et tester lorsque des volutions sont demandes, ou pour corriger des dfauts (qualit de la documentation, testabilit).
-G- AUTRE CLASSIFICATION

La liste ci-dessus n'est bien entendu pas exhaustive. Les critres sont ncessairement des notions spcifiables et qui doivent tre mesurables pour l'valuation. Pourtant ils restent trs souvent plutt qualitatifs. Ils correspondent aux caractristiques externes perues par l'utilisateur durant l'utilisation, la maintenance, le transfert (validation, certification). Une autre classification peut donc se faire suivant le stade : - fonctionnement (validit, fiabilit, efficacit, intgrit, convivial). - utilisation (transfrabilit, configurabilit). - modification (maintenabilit, volutivit, testabilit). 28.4. FACTEURS OU ATTRIBUTS DE LA QUALITE Ces facteurs conduisent exprimer les rgles observer comme contraintes pour la partie cratrice du travail, de manire satisfaire les critres de qualit noncs dans le paragraphe prcdent. Pour la conception, JENSEN cite les attributs suivants [JENSEN-89}: - ncessit: Seules les performances et possibilits demandes dans les spcifications, limitation naturelle la demande, sont satisfaites, ce qui conduit la simplicit. 572 M.C.S.E

Ch 28 - GESTION DE LA QUALITE - compltude: La spcification est complte pour tous les modules, les interfaces, lenvironnement. - consistance: Les incompatibilits sont identifies et rsolues. - observabilit: Le suivi de la hirarchie qui lie les fonctions ralises aux fonctions spcifies est possible par analyse des documents. - visibilit: Les liens entre les lments de la conception et les dcisions prises pendant l'tude sont observables. La trace des dcisions prises permet une flexibilit des changements pour s'adapter aux spcifications nouvelles. - faisabilit: Les parties critiques doivent tre dmontres (dmonstration, implmentation, prototypage...) comme ralisables avec les contraintes de cot et d'ordonnancement. 28.5. MESURE DE LA QUALITE La mesure est obligatoire si l'on cherche s'assurer de la conformit aux rgles nonces par l'assurance qualit. Les types de mesures possibles sont : - mesure de la complexit : structurelle, textuelle, comportementale, - mesure des performances : logimtrie, - mesure de la fiabilit : taux de dfaillance. On trouve des dveloppements tout particulirement dans le domaine du logiciel. Il s'agit de mesures de la complexit des programmes et des systmes [NAVLAKHA-87, ROUVE-88]. L'valuation de la complexit du systme doit tre faite durant l'tape de conception. 2 approches au moins sont noter: celle de YIN et WINCHESTER base sur l'analyse du diagramme de structure des modules, et celle de HENRY et KAFURA base sur l'analyse du diagramme flot de donnes. La Mtrique C mesure le COUPLAGE inter-modules pour chaque niveau de la hirarchie. Cette fonction est monotone croissante. Une augmentation importante pour le passage d'un niveau au suivant signale une augmentation trop importante de la complexit, ce qui suggre une modification de la conception. Les mesures de complexit permettent de dtecter des dfauts de conception. NAVLAKHA donne la liste suivante pour les procdures, ce qui peut tre tendu aux actions ou fonctions d'une structure fonctionnelle. - MANQUE de FONCTIONNALITE: un nombre important d'entres (fan-in) et de sorties (fan-out) indique que l'action ou le module assure plus d'une fonction. - POINT CRITIQUE dans le SYSTEME: une trop forte complexit rvle un flot d'information trop important. Ce point est critique vis--vis d'une modification de l'implantation. - RAFFINEMENT INADAPTE: un fan-in ou fan-out trop important peut vouloir exprimer un manque en niveau d'abstraction. 28.6. METHODE 2 mthodes distinctes et complmentaires sont explicables: - s'assurer que la qualit est introduite ds le dpart dans le produit, M.C.S.E 573

Partie 7 - CONDUITE DE PROJET - vrifier et valider. Ceci n'est qu'une technique de diagnostic qui n'introduit pas de qualit. Il s'agit seulement d'une mesure de la qualit existante. Les 2 mthodes sont trs diffrentes, et la deuxime ne devient efficace qu'aprs application de la premire. L'obtention de la qualit comme technique prventive rsulte d'une cohrence des 3 types d'activits : l'assurance qualit, l'laboration de la qualit, le contrle qualit.
-A- ASSURANCE QUALITE

Elle dfinit les principes techniques et rgles, ce qui veut dire : - dfinition et adaptation de rgles, procdures, outils, standards tendant assurer la qualit pour chaque projet, - prvention des causes qui peuvent nuire la qualit, - incitation la bonne application des dispositions, - collecte, archivage et exploitation des donnes.
-B- ELABORATION DE LA QUALITE

Elle rside dans l'application des mthodes, rgles... dfinies pralablement par l'assurance qualit. Elle suppose de plus la vrification continue de la qualit. L'emploi d'une mthode comme MCSE pour la spcification et la conception, conduit assez naturellement satisfaire des rgles de qualit dans les solutions et documents. En effet, elle prconise la COMPLETUDE et la STRUCTURATION pour les spcifications et la mthodologie fournit la dmarche suivre. En conception, elle favorise la slection d'une solution simple en proposant des MODELES GENERIQUES possdant des proprits de qualit. D'autre part, les reprsentations graphiques: diagrammes pour les spcifications, structure fonctionnelle, structure dexcution, schma d'implantation, permettent une mesure qualitative des solutions proposes.
-C- CONTROLE QUALITE

Cette activit conduit l'obtention de rsultats satisfaisants avant le passage l'tape suivante par observation des documents et des ralisations. Cette activit doit tre exerce au terme de chaque tape pour certifier qu'un produit respecte les rgles gnrales et les exigences spcifiques de la qualit. Citons comme technique pour les documents: celle des "lectures croises" par un cycle auteur-lecteurs, qui consiste dcouvrir les erreurs, omissions, incompltudes, etc. La correction est de la responsabilit de l'auteur. Autre avantage qui rsulte de l'introduction des lecteurs dans le cycle de dveloppement, cette technique introduit une bonne cohrence de l'quipe, une bonne connaissance du travail, ce qui permet l'interchangeabilit. 28.7. VERIFICATION DE LA QUALITE 2 types de vrifications sont envisager pour un projet ou une solution: - des techniques qui permettent de vrifier que la solution est en accord avec les attributs prvus par l'assurance qualit. Il s'agit donc d'valuer une "bonne conception". - des techniques de validation pour s'assurer que la solution est conforme aux spcifications du demandeur. 574 M.C.S.E

Ch 28 - GESTION DE LA QUALITE Pour de telles vrifications, les mthodes sont encore trs limites aujourd'hui: - revue et inspection : elles ncessitent des reviewers qualifis, - contrle interne un niveau, contrle de cohrence entre niveaux, - simulation/modlisation : analyse de l'aspect dynamique, - outils de mesure : complexit, testabilit ..., statique et dynamique. De plus en plus, des outils de qualimtrie permettent des mesures sur des descriptions logicielles, ce qui est souhaitable car elles sont plus difficilement observables que les ralisations matrielles.

M.C.S.E

575

BIBLIOGRAPHIE 7

[ABBOTT-86] An integrated approach to Software Development R. J. ABBOTT Wiley-Interscience publication 1986 [AMGHAR-89] Mthodes de dveloppement dun systme microprocesseurs A. AMGHAR MASSON collection manuels informatiques 1989 [AUBRY-86] Prototypage et qualit du logiciel R. AUBRY, Y. MARTINEZ Journes "maquettage et prototypage de Logiciels" BIGRE No 51-1986 [BERNARD-85] Les Plannings J. BERNARD, M. PAKER Les ditions d'organisation 1985. [BOEHM-84] Software Engineering Economics B.W. BOEHM IEEE Transactions on Software Engineering, Vol. SE-10, N1, Janv. 1984, P.4-21 [BUCKLEY-84] Software Quality Assurance and the IEEE Standards Process F.J. BUCKLEY IEEE RCA Government Systems Division 1984 [CAPRON-86] Systems Analysis and Design H. L. CAPRON The Benjamin/Cummings Publishing Compagny, Inc 1986 M.C.S.E 577

Partie 7 - CONDUITE DE PROJET [DUKE-89] V & V of flight and Mission-critical Software E. L. DUKE IEEE Software may 89, P.39-45 [FATHI-85] Microprocessor Software Project Management E. T. FATHI, C. V. W. ARMSTRONG Marcel Dekker inc 1985 [JENSEN-79] Software Engineering R. W. JENSEN, C. C. TONIES Prentice Hall 1979 [LELUC-86] Enqute sur les cots de la maintenance P. LELUC, Y. SALOMON Gnie Logiciel No 5 Juillet 1986, P.68-71 [KOONTZ-80] Management: principes et mthodes de gestion H. KOONTZ, C. O'DONNELL Collection Administration Mc GRAW-HILL 1980 [NAVLAKHA-87] A survey of system Complexity Metrics J.K. NAVLAKHA The computer Journal Vol. 30, N3 1987, P.233-238 [ROUVE-88] Logiscope: Contribution la matrise de la qualit des logiciels C. ROUVE, M. VIALA Gnie Logiciel et Systmes Experts N12 Juin 88, P.36-44 [RUSKIN-82] What every engineer should know about Project Management A.M. RUSKIN, W.E. ESTES Marcel Dekker inc 1982 [PARNAS-86] A rational design process : How and why to fake it D.L. PARNAS, P.C. CLEMENTS IEEE Transactions on Software Engineering Vol. SE-12, N 2 Fv. 86, P.251-257 [SCHNEIDERMAN-85] Designing user Interfaces B. SCHNEIDERMAN Addison Wesley 1985 [SHINGO-87] Le systme POKA-YOKE: zro dfaut=zro contrle S. SHINGO Les Editions d'Organisation 1987 578 M.C.S.E

PARTIE

BILAN ET PERSPECTIVES

Pour conclure sur l'apport de la Mthodologie, nous voquons dans cette dernire partie la contribution de chacun des 3 aspects que sont: une Mthodologie comme guide de travail, l'outil informatique comme support de travail, le concepteur comme acteur pour les dveloppements. Le chapitre 29 rsume les points essentiels de la Mthodologie. Concernant les outils d'aide la conception, plutt que de dcrire les produits existants dans un domaine relativement naissant, il nous a sembl prfrable de caractriser l'outil souhait. C'est l'objectif du chapitre 30 que de prciser un tel cahier des charges. Le chapitre 31 concerne le concepteur. Une mthodologie et des outils ne suffisent pas. La comptence du concepteur est indispensable car la conception est une activit humaine pour encore quelques annes. De mme, l'engagement de l'entreprise est une condition strictement ncessaire pour la russite.

M.C.S.E

579

Chapitre 29

APPORT DE LA METHODOLOGIE

Dans ce chapitre, nous reprenons les points essentiels de la Mthodologie pour synthtiser son apport pour le dveloppement de systmes. Peut-tre d'apparence superflue pour des petites applications, une mthodologie est strictement indispensable pour des projets industriels. Elle ne constitue pas elle seule un tout isol, mais c'est un apport complmentaire l'entreprise pour son organisation et qui doit s'intgrer d'une manire harmonieuse. Rappelons en prliminaire les objectifs essentiels pour un dveloppement et qui a servi de base pour l'laboration de cette Mthodologie. Premier point essentiel, il s'agit de satisfaire le demandeur. Ensuite, des dlais et cots doivent tre respects. Enfin, le produit dvelopp doit satisfaire des critres de qualit que sont: sa robustesse, la comprhensibilit de la solution ce qui implique sa simplicit, sa maintenabilit pour garantir une grande prennit. A partir de ces objectifs, nous montrons comment la mthodologie propose rpond ces souhaits.

M.C.S.E

581

Partie - BILAN ET PERSPECTIVES 29.1. LA BOITE A OUTILS DU CONCEPTEUR Une mthodologie est tout fait assimilable une bote outils. Cette bote contient tous les lments utiles pour le concepteur. Par ce document, MCSE met disposition: - des modles. Il s'agit pour une partie de modles pour la description des spcifications et des solutions, et pour d'autres de modles d'organisation du travail: cycle de dveloppement, enchanement des tapes... - des mthodes. Chaque mthode est un guide pour obtenir un rsultat partir de donnes d'entre ou de spcifications. Une mthodologie est un ensemble de mthodes qui reposent sur l'emploi de modle(s) et est constitue de rgles, conseils, critres et squences de dcisions... - une organisation de projets. C'est un schma pour la dcomposition des tches pour chaque projet, une rpartition de ces tches selon la comptence ncessaire, une procdure pour la planification, l'estimation, l'organisation puis la conduite des projets. - des solutions. Les exemples d'tudes de cas permettent au concepteur de travailler par analogie de manire enrichir son exprience. Au travers de tels exemples, on retrouve un ensemble de problmes classiques habituels. C'est donc un moyen indirect favorisant la rutilisation. Parmi les solutions, certaines sont gnrales au point d'induire une varit de solutions. C'est ce que nous avons appel les modles gnriques. A ces lments peuvent bien entendu tre ajouts tout autre modle, mthode et mthodologie qui pourraient tre utiles pour le concepteur. Trouver facilement l'outil appropri ncessite que la bote soit organise. C'est l'objectif d'une mthodologie que de fournir ce cadre d'organisation. En plus, chaque concepteur est en mesure d'enrichir cette bote outils, en exprimant de nouveaux modles et mthodes, en dveloppant des solutions rutilisables qu'il rend disponibles ses collaborateurs. 29.2. DOMAINES DUTILISATION Pour cerner le domaine dutilisation de la mthodologie, 2 aspects sont considrer: la classe ou les classes des systmes concerns et la complexit des applications. Concernant les classes de systmes, la Mthodologie couvre bien le domaine des systmes en Informatique Industrielle. Les techniques mettre en oeuvre sont celles bien matrises dans les domaines connexes: Electronique, Automatique, Informatique, Communication, Traitement du signal. La difficult vient plus de la diversit des aspects considrer que de la complexit de chaque aspect. Concernant la dimension des applications, parfaitement justifie pour des petits projets, la Mthodologie est aussi essentielle pour des projets complexes. Par l'approche descendante, un projet complexe est dcompos en sous-ensembles interconnectables. Les sous-ensembles peuvent alors se dvelopper sparment avec la certitude que l'intgration de tous les constituants conduira en final une garantie de rsultat. 29.3. ORGANISATION DES PROJETS MCSE est base sur un cycle de dveloppement du type hirarchique: niveau systme, puis sous-ensemble, puis matriel et logiciel. Cette dcomposition sert de base pour l'organisation des dveloppements. 582 M.C.S.E

Ch 29 - APPORT DE LA METHODOLOGIE Comme guide, le cycle de dveloppement facilite les tches en amont du travail technique: estimation, planification, prvision, organisation et gestion des ressources. L'ordonnancement de plusieurs projets en parallle conduit aussi une optimisation du cot et des moyens. Un projet n'est pas obligatoirement un droulement squentiel des tapes, de la spcification la ralisation. Certains projets peuvent ncessiter des cycles prliminaires, telle qu'une phase de spcification prliminaire utile pour l'tude de faisabilit. Pour d'autres projets, le prototypage d'un sous-ensemble est jug indispensable. Ces organisations sont tout fait possibles par rapport au schma idal purement linaire. Le suivi d'un projet ncessite des observations: l'tat d'avancement, la qualit des documents, la qualit des solutions... Une politique de suivi est mettre en place. Pour la documentation gnrale labore au fur et mesure du dveloppement qui est en fait le seul rsultat clairement observable, des revues par un cycle du type auteur-lecteurs sont planifiables de manire valider la production et si ncessaire amliorer la qualit. Comme aide pour le suivi de projet, le lecteur trouvera la fin de ce chapitre un modle de guide simplifi pour la mthodologie. Il montre la ncessit de mener en parallle le dveloppement, les vrifications et tests, llaboration de la documentation. Ce guide est utilisable pour un petit projet, mais aussi pour le dveloppement de chaque sous-ensemble durant un projet plus complexe. Pour la politique d'organisation, si la mthodologie fournit un cadre de rflexion, celle-ci doit tre une volont de la direction de chaque entreprise. Cette responsabilit ne peut pas exclusivement incomber aux concepteurs eux-mmes. Elle est confier chaque responsable de projets qui doit alors disposer des moyens pour l'appliquer. Il s'agit d'une tche de nature technique et pas administrative. En effet, l'organisation ncessite de connatre le contenu technique des projets, chacun ayant ses spcificits. 29.4. REPARTITION DES COMPETENCES La Mthodologie dcompose le travail en 3 types d'activits: la spcification, la conception, la ralisation. L'intrt de cette dcomposition est de clairement faire apparatre des catgories de comptences. La premire phase, celle de spcification, est trs nettement oriente demandeur et utilisateurs. Elle ncessite une comprhension rapide du problme soulev et du besoin. Les comptences ncessaires sont de 3 ordres: - connaissances de gnraliste pour tre mme de comprendre et de formuler un problme d'un domaine tout autre que celui de l'lectronique et de l'informatique, - esprit de synthse pour structurer et formuler clairement les concepts du problme, les contraintes, les souhaits, - communicatif, condition strictement ncessaire de russite. C'est par un dialogue avec le client que le spcifieur arrive comprendre le besoin. Ensuite, c'est par une rdaction claire du document de spcification que se fait la validation de cette comprhension. Bien entendu, la russite n'est possible que si la personne en charge de ce travail est trs intresse par ce type d'activits. M.C.S.E 583

Partie - BILAN ET PERSPECTIVES La phase de conception est une activit essentiellement conceptuelle. Le concepteur doit avoir la facult d'interprter les spcifications pour imaginer la solution approprie. Cette solution se situe au dpart sur un plan purement fonctionnel. Exprimer une solution implique une activit de modlisation de quelque chose dinexistant. Il sagit donc dune activit cratrice. Ce travail est mi-chemin entre la demande du client et la solution technique. Le dialogue avec le client, les utilisateurs et le spcifieur reste ncessaire pour se garantir un rsultat satisfaisant. La comptence technique est bien entendu ncessaire pour induire des solutions ralisables et pour pouvoir dialoguer avec les spcialistes en charge de la ralisation. La phase de ralisation est essentiellement technique. Elle requiert une grande comptence en techniques de ralisation et d'industrialisation : matrise des outils, des composants, de la technologie. La conduite de projet ncessite une comptence globale pour tre mme de prvoir, d'observer, de comprendre, de dcider et de guider les collaborateurs tout au long du projet. 29.5. GUIDE POUR LE DEVELOPPEMENT Une mthodologie est aussi un guide pour le dveloppement de projets. La dmarche propose est globalement descendante (top-down). Elle prconise de partir du problme du client pour rechercher par approches successives, une ralisation approprie. La dcomposition en tapes est base sur la possibilit de dcrire tout systme selon plusieurs niveaux. La description en niveaux est base sur un modle de description interne base sur l'association de 3 composantes, qui permet de s'intresser tout d'abord l'interconnexion des constituants fonctionnels puis l'volution de ceux-ci, enfin aux ressources gnratrices de cette volution. La spcification, qui elle, concerne une description externe du systme, est aussi base sur une modlisation selon 3 vues: l'espace des donnes, l'espace des tats, l'espace des activits. Ces modles servent de base pour spcifier le dcoupage en tapes et induire la mthode suivre durant chaque tape. Une mthode est une structuration de l'analyse et des dcisions prendre pour transformer efficacement une spcification en une solution. Pour rsumer globalement la dmarche prconise et par analogie avec les systmes de communication pour lesquels un modle OSI en 7 couches a t dfini, la structuration d'un systme peut aussi se reprsenter selon un ensemble de 5 niveaux comme l'indique la figure 29.1. le niveau 0, le plus lev, correspond l'expression du besoin. le niveau 1 est une vue externe du systme avec son environnement. le niveau 2 est une description interne fonctionnelle indpendante de la technologie. le niveau 3 est une spcification de la solution pour la ralisation avec la partie matrielle et pour les processeurs programmables, les spcifications d'implantation logicielle. le niveau 4 est la description de la ralisation comme un ensemble de cartes et de logiciels. Au niveau 2 il est intressant dajouter 2 autres sous-niveaux: le sous-niveau 2 qui inclut le transport des informations pour les systmes rpartis. 584 M.C.S.E

Ch 29 - APPORT DE LA METHODOLOGIE le sous-niveau 2" qui correspond lintroduction des interfaces technologiques ncessaires pour le couplage avec l'environnement.
Modle de description dun systme Dmarche

Application
0

Cahier des charges

Etape 1

Spcification
Niveau spcification

Systme

Description externe Etape 2

Niveau fonctionnel

Conception fonctionnelle
Description fonctionnelle Etape 3

Ve

F1

Vi

F2

Vs

Niveau rpartition

Dfinition de la ralisation Partitionnement

MVI

Description
R

fonctionnelle avec rpartition

Niveau interfaces

2"

Description fonctionnelle dtaille

Allocation implantation processeur 2 + logiciel

Adaptation Allocation Implantation

processeur 1 + logiciel

Description

excutive
sous-ensemble 1 sous-ensemble 2

Niveau excutif

Etape 4

Ralisation
Niveau ralisation
carte 1 carte 2 logiciel 2

Description de la ralisation

logiciel 1

-Figure 29.1- Structuration dun systme en 5 niveaux.

M.C.S.E

585

Partie - BILAN ET PERSPECTIVES La reprsentation en niveaux de description permet de montrer la dmarche suivre en indiquant pour chaque passage d'un niveau au niveau infrieur, l'information ajouter ou la transformation effectuer. Si la dmarche prconise est globalement descendante pour la conception, des variantes sont possibles pour tenir compte des objectifs atteindre et des contraintes. En particulier, ds le dbut de l'approche fonctionnelle et pour certains problmes, il est tout de suite possible de dfinir la ralisation, en particulier la partie matrielle. Celle-ci peut alors ncessiter un travail de conception important qui se fait alors en parallle avec la conception au niveau systme. D'autre part, certains dveloppements peuvent rsulter d'une approche ascendante qui conduit mettre en vidence des sous-ensembles exploitables pour d'autres projets. Le dveloppement est aussi un processus itratif voire mme volutif. En effet, l'issue de chaque tape, la phase de vrification peut conduire devoir revoir les dcisions durant l'tape, voire mme celle des tapes prcdentes. Ceci est une attitude normale. Les retours-arrires de correction sont invitables car l'activit est humaine avec les erreurs possibles et que la mthode n'est qu'un guide. Seule une production automatique par transformations liminerait le risque d'erreurs. 29.6. DOCUMENTATION DES PROJETS Un point essentiel de la Mthodologie est de servir de guide pour l'laboration de la documentation. Celle-ci est bien videmment ncessaire pour la prennit du produit. Dvelopp en particulier pour la maintenance, elle est aussi impose pour la mthodologie ellemme de manire permettre les vrifications l'issue de chacune des tapes. Ainsi, la documentation est produite et vrifie de manire incrmentale, tape par tape. Elle contient alors les dcisions pertinentes et les raisons de ces dcisions qui ont conduit la solution retenue. La documentation vise plusieurs objectifs: - la communication. Lisible par tous les participants, la documentation dfinit un standard d'change des informations sur le projet. Elle permet de ce fait d'informer tout autre personne vitant ainsi que l'aboutissement du projet ne soit particulirement dpendant d'un concepteur. - la maintenance. Ralise par d'autres personnes, la maintenance repose sur la connaissance de la solution et des dcisions qui ont conduit certains choix. Pour ces raisons, la documentation est strictement ncessaire. - les rfrences historiques. Il s'agit de garder une trace des dveloppements passs. Ceci constitue une garantie car aucune organisation n'est l'abri d'une mobilit du personnel. Concernant la forme de la documentation, elle prsente la solution selon une approche descendante mme si le dveloppement s'est fait selon une procdure diffrente. L'important est dans le contenu et non dans la manire de l'obtenir. 29.7. LES POINTS DELICATS EN CONCEPTION Nous rappelons ici les principes essentiels de la Mthodologie qu'il est conseill de suivre pour obtenir les meilleurs rsultats. Ces principes rpondent des difficults couramment rencontres par les concepteurs. 586 M.C.S.E

Ch 29 - APPORT DE LA METHODOLOGIE Au pralable, il est bon de rappeler que le dveloppement est une activit humaine mettant en jeu une mthodologie et un systme social. Les 2 parties ont une importance pour la russite. Aussi, l'attitude volontariste des concepteurs est une premire condition strictement ncessaire pour le succs de la dmarche.
-A- ETAPE DE SPECIFICATION

Ltape de spcification est la premire et la plus dlicate. Concernant le travail faire il y a au moins 2 difficults. Tout d'abord pour la modlisation de l'environnement, il faut dcider du modle le plus appropri pour cet environnement, la fois sa nature et son niveau de dtail. Pour tre bonne, l'analyse doit se faire sur un plan fonctionnel et non matriel. Ceci est une erreur frquente. De l'analyse se dduit la nature du modle qu'il faut rechercher dans l'ordre de complexit: modle statique donnes/vnements, modle dynamique global, modle des activits. Le modlisation est faire selon un niveau de dtails ncessaire mais juste suffisant pour rsoudre le problme. Elle ne doit pas faire intervenir le systme concevoir. Ensuite, pour l'laboration des spcifications fonctionnelles, celles-ci doivent se limiter une description externe du systme. Les fonctions du systme ne doivent tre que des fonctions de l'application qu'il ne faut surtout pas confondre avec les fonctions internes du systme.
-B- ETAPE DE CONCEPTION

Pour cette tape, le premier point important est de faire une conception indpendante de la technologie. Pour cela, il faut liminer tous les problmes de rpartition gographique et d'interfaces pour se consacrer au seul aspect fonctionnel. Ensuite, la recherche d'une solution est faire sur la base des variables internes ncessaires et non pas sur la base des fonctions internes. L'approche prconise conduit une solution plus simple comprendre et plus simple implanter. Les ides de solutions peuvent aussi se dduire de modles gnriques de solution. L'intrt est de disposer d'un guide pour la recherche de variables. D'une manire gnrale, le concepteur doit faire abstraction de toutes ses ides a priori, sinon il conduira son dveloppement sur la base de son ide sans chercher valuer d'autres solutions peut-tre meilleures.
-C- ETAPE DE DEFINITION DE LA REALISATION

Cette tape permet de s'adapter aux caractristiques de l'environnement, en introduisant les interfaces. Pour cela, il faut rechercher la solution la plus approprie, c'est particulirement le cas pour l'interface homme-machine. Les contraintes de temps sont valuer correctement de manire pouvoir prouver a priori le bon fonctionnement de l'application. Ensuite, pour la recherche de la rpartition matriel/logiciel, l'objectif est de rduire au maximum le dveloppement. Ceci conduit minimiser le matriel, puis le logiciel. Concernant le logiciel, il est compos de 2 parties: la partie opratoire strictement ncessaire pour le fonctionnement et donc relativement incompressible si la spcification comportementale a t bien labore et la partie dite organisationnelle qui concerne les relations entre les fonctions. Cette deuxime partie est compressible et l'objectif des transformations pour obtenir le schma d'implantation logicielle est de rduire au maximum cette partie. La Mthodologie favorise cette rduction. Cette approche est tout fait justifie pour les applications temps-rel ddies o le dveloppement est assur une fois pour toutes. M.C.S.E 587

Partie - BILAN ET PERSPECTIVES 29.8. PERENNITE DE LA METHODOLOGIE Bien que l'efficacit et les limites de MCSE soient difficiles cerner, une large exprience de son utilisation nous a montr sa relle efficacit. L'efficacit globale est videmment lie aux qualits des concepteurs : aptitude travailler avec rigueur en approfondissant systmatiquement tous les problmes, aptitude acqurir des connaissances techniques et s'informer sur les solutions disponibles, aptitude travailler en groupe. Dautre part, la volont de la direction de chaque entreprise est un facteur dterminant car la mise en application dune mthodologie nest pas seulement un problme technique mais un problme dorganisation ou les facteurs humains sont essentiels. Dveloppe plus particulirement pour les systmes temps-rel, ceci ne restreint pas automatiquement son champ d'application cette seule classe de problmes. Des expriences intressantes dans le domaine des composants VLSI (conception de composants spcifiques et compilation de silicium), des architectures parallles, des systmes interactifs, des systmes de communication, montrent l'tendue de l'apport d'une telle mthodologie. Son caractre d'ouverture la rend tout fait complmentaire des autres mthodologies. La prennit est aussi une caractristique difficile valuer. On notera que les concepts utiliss et la nature des descriptions sont indpendants de la technologie. D'autre part, l'apport essentiel de la Mthodologie concerne les phases en amont des techniques de ralisation. Ainsi, tant que ces phases ne seront pas assures par des outils de production automatique, ce qui n'est pas pour demain, un tel type de mthodologie restera indispensable.

588

M.C.S.E

IRESTE
- DUREE:

GUIDE POUR LE SUIVI DUN PROJET

Mois|Sem|Jours hommes*mois|sem|jour KFrs EQUIPE: RESPONSABLE:

M.C.S.E
CALENDRIER Date de dbut

OBJECTIF

- MOYENS HUMAINS: - BUDGET:

Phases du dveloppement
0- CAHIER DES CHARGES . formulation du besoin, premire version . tude de faisabilit, dcision . cahier des charges dfinitif 1- ELABORATION DES SPECIFICATIONS . analyse de lenvironnement . dlimitation du systme . spcifications fonctionnelles . spcifications opratoires . spcifications technologiques 2- CONCEPTION FONCTIONNELLE . dlimitation des entres et sorties du systme . premire dcomposition fonctionnelle . raffinement de la solution fonctionnelle . synthse globale de la solution 3- DEFINITION DE LA REALISATION . contraintes de rpartition . interfaces physiques . analyse des contraintes de temps . rpartition matriel/logiciel . spcification du logiciel . spcification du matriel 4.1- REALISATION MATERIELLE . schmas de ralisation . implantation . montage, assemblage 4.2- REALISATION LOGICIELLE . structure du logiciel . criture des modules . mise au point 5- INTEGRATION . assemblage . installation sur site

Vrification, test, validation

Documentation
Document cahier des charges Procdure de recette Analyse de lenvironnement

Vrification de lanalyse Spcifications fonctionnelles Vrification des spcifications et accord Vrification de la dcomposition Vrification des raffinements Procdure de test sur site Spcifications compltes dfinitives Architecture de la solution

MCSE
Vrification solution fonctionnelle complte Document de conception complet Manuels prliminaires Vrification des contraintes Vrification des dcisions dimplantation Document de spcification de la ralisation Procdure de test des constituants Document pour la ralisation Document des tests effectus et rsultats Description de lorganisation du logiciel Description des logiciels Description des tests et rsultats Description des tests densemble Manuels utilisateurs et dinstallation Document final Vrification des schmas Test et validation du matriel Vrification de la dcomposition Test et validation des modules Test dintegration Validation densemble sur site Conformit et recette Mois|Sem|Jours hommes*mois|sem|jour KFrs - DUREE: - MOYENS HUMAINS: - BUDGET: NOTE pour utiliser correctement ce guide: - commencer par une valuation de lobjectif, - noircir les 3 chelles au fur et mesure de lavancement et tenir jour le calendrier, - achever par une valuation globale. Date de fin

RESULTAT

Chapitre 30

CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION

Une mthodologie ne suffit pas. Un outil informatique comme support des dveloppements est indispensable. Ceci est une vidence, mais quel doit-tre son rle? L'analyse peut se faire de 2 manires: en regardant l'existant sur le march de tels outils, ou en dfinissant le besoin sur la base d'une mthodologie. Correspondant un march naissant, dj une varit d'outils comme support de mthodes apparaissent avec des caractristiques relativement diffrentes [SCHINDLER-87, FALK-89]. Ces produits plutt orients logiciels sont appels CASE pour Computer-Aided Software Engineering. Pour la partie matrielle, les outils sont appels CAO ou IAO pour Conception ou Ingnierie Assiste par Ordinateur ou CAE pour Computer-Aided Engineering. L'objectif de tous ces outils est bien sr de satisfaire la demande. Quelle est donc la demande? Bien videmment, tout concepteur souhaite disposer de l'outil "magique" qui lui produirait ses solutions matrielles et un code excutable partir de spcifications. Utilisable pour le dveloppement de tout type de systmes, un tel outil permettrait de conevoir, de dvelopper et en final produirait la ralisation. L'homme limiterait son intervention comme interface entre l'expression du besoin et l'outil. Des dcennies nous sparent encore de ce stade.

M.C.S.E

591

Partie 8 - BILAN ET PERSPECTIVES Le march des outils est spar entre des produits dits "Front End" servant pour les premires phases de spcification et de conception, et des produits dits "Back End" pour la production de solutions. Les diteurs de diagrammes flot de donnes, de schmas font partie de la premire catgorie. Les cross-compilateurs, les gnrateurs d'application, les compilateurs de silicium pour les composants font partie de la deuxime catgorie. Des tentatives de couplage des 2 catgories sont en cours pour couvrir au mieux le cycle de dveloppement. Ainsi les possibilits de chaque outil sont analyser en regardant 2 aspects: - la partie du cycle de dveloppement couverte par l'outil, - la ou les mthodes et modles supports. Plutt que d'analyser les possibilits des outils existants, ce qui est difficile pour un domaine en pleine volution, il nous a sembl prfrable de dfinir le besoin. Il peut alors servir comme base pour spcifier les caractristiques des outils et pour faciliter l'analyse des produits existants. 30.1. LES OBJECTIFS Comme notre intrt concerne les systmes composs des 2 aspects matriel et logiciel, les fonctionnalits voques dans la suite sont plus larges que celles des produits "CASE". Elles doivent couvrir la fois l'Electronique et l'Informatique, alors que nous constatons aujourd'hui plutt 2 catgories de produits. En se basant sur le cycle de dveloppement, il est possible de dfinir les phases couvertes par l'outil. Sur le cycle en V, la figure suivante montre l'intrt de couvrir toutes les phases des spcifications jusqu' la maintenance et le suivi des produits.
APPORT DUN OUTIL
BESOIN Cahier des charges PRODUIT

Spcification

VALIDATION, CERTIFICATION

Production Intgration

Vrification

Conception fonctionnelle

VALIDATION

Intgration Test

Vrification

Dfinition de la ralisation

Ralisation MatrielLogiciel

Vrification

-Figure 30.1- Phases dun projet et apport dun outil. 592 M.C.S.E

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION L'impact de l'emploi d'un environnement de dveloppement pour les premires phases, comme l'indique la figure ci-aprs, est particulirement essentiel pour la phase de maintenance [SCHINDLER-87, DECLERFAYT-88].
-60 % -40 % -20 % 0% 20 % 40 % 21 % 16 % 22 % 17 % -13 % -30 % -16 % -29 % -3 % -9 % -69 % Rduction des cots Augmentation des cots

Dfinition des spcifications Conception prliminaire Etude de faisabilit Conception Codage Intgration Contrle de projet Documentation Communication dans lquipe Projet total Maintenance

-Figure 30.2- Gain de cots avec l'emploi d'un outil. Mais ceci ne reste qu'une constatation actuelle. Le point important vis long terme est l'augmentation de la productivit. Dans [MARTIN-88], l'auteur indique que la productivit obtenue par l'emploi de bases de donnes et langages d'interrogation, les gnrateurs de supports, les gnrateurs d'applications, est d'un ordre de 1000 par rapport celle rsultant de la programmation structure qui reste comprise entre 0,25 et 0,75. Ainsi, l'volution passe invitablement par la cration d'outils de production automatique de manire rduire le temps et donc le cot de dveloppement. Dans le paragraphe suivant, nous dtaillons les fonctions ncessaires pour satisfaire les objectifs ci-dessus. 30.2. LES FONCTIONNALITES SOUHAITEES Les fonctions sont dcrites dans l'ordre de ncessit, en partant du rsultat labor par le concepteur pour aller jusqu' la conduite de projets. 30.2.1. Description Une premire fonction indispensable consiste pouvoir dcrire la solution retenue, dveloppe par le concepteur. Cette fonction est aussi bien valable pour une spcification que pour une conception ou une solution de ralisation. Le mode de description est dpendant de la nature du modle: texte pour des descriptions syntaxiques, graphique pour des modles graphiques. Quel est l'intrt de cette seule fonction? Seulement de pouvoir modifier puis ressortir la description. L'outil est alors quivalent en rle un traitement de texte ou une DAO. M.C.S.E 593

Partie 8 - BILAN ET PERSPECTIVES 30.2.2. Documentation La possibilit de description conduit disposer dans l'outil d'un ensemble de documents concernant le projet. La fonction de Documentation a pour objectif d'laborer automatiquement les documents appropris dont la structure et le contenu sont dpendants de l'usage qui en est fait: document de spcification, de conception, de ralisation, de test, de maintenance... Un document est l'association selon un plan prdfini de descriptions textuelles et de graphiques. Toute mise jour de descriptions sera rpercute dans la documentation. Pour cette fonction, l'outil doit tre paramtrable pour adapter la structure et la forme des documents produire aux contraintes de l'organisation ou de l'entreprise. Pour la forme des documents, une telle fonction est l'quivalent d'une Publication Assiste par Ordinateur (PAO), avec en plus un gestionnaire des documents: paramtrage, mise jour. Bien entendu, dans une documentation on ne trouve rien d'autres que les informations fournies par l'utilisateur. Aussi la qualit de cette fonction est trs dpendante de la richesse des outils de description. Imaginons par exemple un dessin de structure fonctionnelle saisie par un diteur graphique. Dans le document de conception, on doit retrouver en plus du simple dessin l'analyse faite par le concepteur et qui justifie cette solution. Ce texte est fournir l'outil. Autre exemple, comme forme de document souhait: l'quivalent de celui donn Partie 1 chapitre 6 pour dcrire la solution pour le rgulateur de vitesse de croisire. 30.2.3. Vrification, validation Dcrire un objet: spcification, structure fonctionnelle, algorithme... ne garantit pas que cet objet est correct. Le terme correct concerne la fois le contenu de l'lment dcrit et son intgration dans l'ensemble de la solution. Une fonction supplmentaire de l'outil concerne donc la vrification et la validation des descriptions. La vrification concerne plutt la forme: vrification statique et l'adquation un modle de description. La validation concerne plus la preuve d'une solution correcte; ceci fait intervenir l'aspect dynamique. Une telle fonctionnalit ncessite des outils spcifiques de vrification bass sur les modles de description et des outils de simulation pour la validation. De tels outils ne sont possibles que pour des descriptions bases sur des modles formels. Pour illustrer le rle de cette fonction, regardons ce que permettent aujourd'hui les outils de CAO en Electronique. Le concepteur dcrit son schma sur la base de symboles disponibles en bibliothque. Une vrification est ensuite faite sur la cohrence du schma pour obtenir la liste des connexions (net-list). Pour valider son schma, le concepteur travaille par simulation. Pour cela, il dfinit sa squence de test appliquer l'entre de son schma. Le montage est simul sur la base du comportement de tous les symboles. Les modles de ces composants font partie de la bibliothque de l'outil. C'est en observant les rsultats que le concepteur dduit le bon ou mauvais fonctionnement de sa solution. Bien sr, un tel outil n'assure pas lui seul la validation, c'est de la responsabilit du concepteur, mais il montre ce que sous-entendent vrification et validation. Cette fonctionnalit serait souhaitable pour d'autres niveaux et d'autres techniques de ralisation: spcification, conception fonctionnelle, implantation logicielle... Elle ncessite de pouvoir disposer d'un simulateur "universel" du type top-down valable aussi bien pour un systme que pour les sous-ensembles matriel et logiciel!! En l'absence de ce type d'outil, ce travail s'effectue plutt en ralisant des prototypes. 594 M.C.S.E

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION 30.2.4. Production Les fonctionnalits prcdentes n'augmentent pas la productivit des concepteurs. Peut-tre mme au contraire, ils passent plus de temps avec les outils pour saisir les descriptions. Or l'augmentation de productivit est une condition essentielle pour le futur. Il faut donc pouvoir disposer d'outils pour la production automatique de solutions partir de descriptions. Les avantages qui en dcoulent sont au moins: - une rduction du temps de recherche de solution. Ceci justifie pleinement l'intrt de la fonction de description. - la rduction du travail de vrification puisque des outils automatiques, s'ils sont corrects, ne produisent que des solutions oprationnelles. A nouveau pour illustrer l'apport de tels outils, prenons 2 exemples, celui de la crosscompilation pour le logiciel et celui de la compilation de silicium pour les composants. Lorsqu'il s'agit de dvelopper une application sur une carte microprocesseur cible, la dmarche consiste dcrire la solution en langage de haut-niveau sur un outil appel systme de dveloppement. Celui-ci possde un processeur qui peut tre diffrent de celui de la carte cible. Le concepteur du programme vrifie et valide son programme pour un jeu d'essais. Une fois le programme au point, il utilise alors un cross-compilateur qui, partir de la description valide, produit un code excutable sur la carte cible. Normalement, aux adaptations prs aux caractristiques matrielles de la carte, la solution est oprationnelle. Il y a donc dans ce cas gain en temps pour le dveloppement, d'une part puisqu'il n'est plus ncessaire de dvelopper son application en langage Assembleur, d'autre part puisque pour un changement de processeur la traduction est automatique. Pour les composants intgrs, le concepteur dcrit et valide son schma comme indiqu dans le paragraphe prcdent. Ensuite, avec un compilateur de silicium, aprs avoir indiqu la technologie du fabricant et le type de botier (packaging), il obtient relativement automatiquement le dessin de toutes les couches du circuit intgr (le layout). Cette description est alors transmise au fondeur pour la fabrication. Dans ce cas, le gain de productivit est considrable puisqu'il n'est plus ncessaire de dessiner chaque transistor, et qu'un circuit 20000 transistors peut se produire en moins d'une semaine. Les deux exemples prcdents ont permis de saisir l'intrt de cette fonction de production. Bien sr, il ne faut pas se contenter de l'existant. Tout concepteur souhaite des outils de plus en plus sophistiqus qui lui vitent de descendre un niveau trop proche de la technologie pour qu'il puisse investir son temps sur les premires phases. Ainsi, observe-t-on dj une progression vers de tels outils. L'objectif est d'aboutir automatiquement partir d'une description, une solution rpondant aux spcifications de la description et possdant des qualits. Le niveau de la description va remonter progressivement pour se rapprocher de l'expression du besoin. Plus le niveau de la description est lev, plus les contraintes augmentent, mais aussi plus il existe de latitudes pour trouver une solution. Ainsi, au fur et mesure, ces outils devront intgrer l'expertise des concepteurs, les caractristiques techniques et technologiques des ralisations. M.C.S.E 595

Partie 8 - BILAN ET PERSPECTIVES Le niveau actuel des outils est trs dpendant du domaine. Des progiciels applicatifs permettent par exemple une production automatique d'une application partir d'une configuration. Dans le domaine des filtres numriques, des prototypes d'outils permettent l'obtention directe d'un composant rpondant aux spcifications du filtre. Comme le montre la figure ci-dessous, cette fonctionnalit est la plus esssentielle l'avenir pour augmenter la productivit. Pour chaque domaine, elle ncessite que soient parfaitement formaliss: les modles de description de l'objet produire, les modles de solutions, les dmarches pour passer de la spcification une ralisation rpondant au mieux au problme. Le dveloppement des mthodologies est l'intermdiaire comme passage oblig.
Besoin Spcification Conception prliminaire Conception dtaille Ralisation Production automatique Production manuelle

1980

1990

2000

-Figure 30.3- Apport des outils de production automatique. La courbe devrait tendre vers une asymptote au niveau des spcifications car, invitablement, il faudra continuer formaliser nous-mmes le besoin du demandeur. Pour le domaine des systmes temps-rel, le chemin parcourir est encore norme. Imaginons seulement l'obtention automatique d'une solution partir d'une description fonctionnelle: structure fonctionnelle saisie par un diteur graphique et comportant des fonctions dcrites en ADA. Pour cela, il faut dj valider l'application, puis aprs avoir exprim les contraintes de temps, il faut dcrire ou trouver la solution matrielle ncessaire pour que l'outil puisse produire automatiquement la partie logicielle. En final, il faut avoir la garantie du bon fonctionnement de l'application avec respect des contraintes de temps, ce qui est une condition essentielle pour le domaine du temps-rel. 30.2.5. Gestion de projets et de versions D'une part les projets deviennent de plus en plus complexes, ce qui implique un dcoupage du travail en quipe. D'autre part, chaque application ou systme a une dure de vie heureusement bien au-del de son dveloppement. Il faut donc assurer une maintenance de ces produits. Pour rpondre ces impratifs, une fonction de gestion de projets et de versions est strictement ncessaire. Elle concerne 2 parties: 596 M.C.S.E

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION - le dveloppement. Chaque dveloppeur apporte sa contribution dans un ou plusieurs projets. L'outil est l'lment d'intgration des parties du dveloppement. Toute modification faite sur un sous-ensemble est rendue disponible pour l'ensemble du projet. La notion de rutilisation est aussi grer pour profiter des dveloppements effectus durant d'autres projets. - la maintenance. Pour des produits qui ont 10 ou 15 ans de dure de vie, il est vident qu'ils diffrent suite des modifications, des amliorations. Matriel et logiciel ne sont peut-tre plus compatibles. Pour assurer correctement la maintenance, il faut tre capable de grer les diffrentes versions des applications. Ainsi, pour cette fonction, l'outil doit tre une plateforme d'intgration des dveloppements, un gestionnaire des versions et du suivi des systmes installs, avec une gestion des droits pour les participants. 30.2.6. Conduite de projets Grer des projets ncessite des activits prliminaires que sont la planification des projets, l'valuation et la rpartition des ressources humaines et matrielles, l'estimation des cots, ainsi que des activits de contrle durant le dveloppement de chaque projet, savoir: l'valuation de l'tat d'avancement, l'observation des dviations par rapport au planning, une mesure de la qualit des dveloppements ... Un outil d'aide doit donc offrir une telle fonctionnalit. Pour les activits prparatoires, il sert dcomposer un projet en ses divers constituants conformment au cycle de dveloppement et la mthodologie suivis. Sur la base d'estimations antrieures, il aide estimer un nouveau projet et permet, compte-tenu des ressources dj utilises pour d'autres projets, de dfinir une politique de rpartition des charges. Les activits de contrle seront bases sur l'observation de l'tat de toutes les descriptions entrant dans le projet: non commenc, date de dbut, date de fin, test, recette... La qualit peut se dduire partir des descriptions et de critres de qualit l'aide d'outils de qualimtrie. Un suivi global du projet permet de ragir en temps utile pour corriger les dviations par rapport au planning ou mme aux erreurs d'estimation. De tels outils existent dj mais doivent tre pleinement intgrs aux autres fonctionnalits pour viter de devoir saisir les informations de contrle utiles pour le suivi et difficiles obtenir des concepteurs. 30.3. SYNTHESE DES FONCTIONNALITES Dans ce paragraphe, nous reprenons chacune des fonctions pour montrer son rle pour le dveloppement de projets. On montre par la figure ci-dessous, que chaque fonction doit tre base sur des modles. Les mthodes servent pour la production, la vrification, la conduite de projets. M.C.S.E 597

Partie 8 - BILAN ET PERSPECTIVES

Modles de description

Modles de documentation

Documentation

Concepteurs

Description

Modles et mthodes

Mthodes et modles de solutions

Vrification validation Production Produits

Gestion de projets et de versions

Responsable de projet

Conduite de projets

Modle cycle de dveloppement

-Figure 30.4- Fonctionnalits d'un outil pour le dveloppement. Cette figure montre l'importance de l'entre des descriptions lorsque celles-ci permettent de produire des rsultats en sortie. La fonction essentielle qui conduit augmenter dans une dynamique de 10 100 est celle de production. Cette figure permet aussi de comprendre la nature des 2 types de produits existants "front end" pour les descriptions en spcification et conception et les produits "back end" situs ct produit. L'volution actuelle vers un couplage des 2 types de produits va donc dans le sens d'une intgration plus complte des fonctionnalits souhaites. 30.4. STRUCTURE ET CARACTERISTIQUES DUN OUTIL A partir des fonctionnalits souhaites, il est assez simple d'esquisser la structure et les caractristiques d'un tel outil. Partons de son couplage avec l'environnement. Pour faciliter la saisie des descriptions, l'outil doit disposer d'interfaces des plus conviviales. Une grande partie des descriptions tant graphique, la station de travail avec un gestionnaire multifentres et un guide iconique pour l'aide au suivi de la mthodologie est l'interface la plus approprie. La documentation en sortie requiert l'emploi de moyens d'impression de haute rsolution que sont les imprimantes laser. La production fournit des documents selon des interfaces appropries vers les outils de ralisation: fabricant de composants ASIC, fabricant de circuits imprims, programmation d'EPLD, dEPROM, mulateurs... 598 M.C.S.E

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION En interne ensuite, l'outil doit grer une grande quantit d'informations sous des formes trs varies. Le noyau du systme est donc une base de donnes, si possible oriente objets, pour favoriser la gestion de la diversit. C'est autour de cette base de donnes que sont installer les divers outils, chacun associ une fonction particulire, et mme un domaine particulier. Ainsi, la structure de l'outil est donne ci-dessous.

Editeurs -textes -graphiques

Bases de donnes

Conduite de projets Gestion de projets

Vrification simulation

Documentation

Gnrateurs de solutions

-Figure 30.5- Structure d'un outil pour le dveloppement de projets. A partir de cette organisation fonctionnelle, peuvent se dduire des caractristiques pour le support. Tout d'abord, l'outil doit servir simultanment tous les participants un ou plusieurs projets. Chaque utilisateur doit disposer localement de son outil de travail, et compte-tenu des qualits des outils de description chaque poste ncessite une puissance de traitement associ l'cran. La station de travail est l'outil appropri. Mais comme toutes les informations du projet doivent tre accessibles de tout point et tout moment, la base de donnes doit tre fonctionnellement centralise (sa ralisation peut tre rpartie). Tous les outils complmentaires doivent aussi tre accessibles aux participants. Ainsi, la structure matrielle est un rseau informatique constitu de serveurs pour la gestion des informations et la mise disposition des outils spcifiques, et un ensemble de stations de travail. Pour cette structure, le systme d'exploitation doit tre une structure d'accueil pour la base de donnes et les outils. Compte-tenu de la complexit des outils dvelopper et de leurs cots de dveloppement, il n'est pas pensable de trouver tous les outils utiles chez un mme vendeur. Pour une organisation ou une socit, un outil appropri rsultera plutt de l'association d'outils provenant de diffrentes origines. Une telle solution n'est convenable que si toute la varit M.C.S.E 599

Partie 8 - BILAN ET PERSPECTIVES d'outils s'interface correctement. Un standard pour l'accs la base de donnes apparat indispensable. Une plateforme homogne et dfinie au pralable est donc une ncessit. Cet effort est aujourd'hui reconnu et les dveloppeurs d'outils recherchent plutt l'ouverture et la complmentarit que la spcificit. 30.5. GUIDE POUR UNE ANALYSE DES OUTILS Pour conclure ce chapitre qui a permis de dfinir le rle et la structure d'un outil comme aide au dveloppement, nous proposons un guide simple pour analyser les caractristiques des outils du march. L'analyse doit se faire selon plusieurs dimensions: - les fonctionnalits, - les phases du cycle de vie, - pour chaque phase, la ou les mthodes et donc les modles. Un tableau tel qu'indiqu ci-aprs permet d'laborer une fiche signaltique pour un ou un ensemble de produits.
Fonction Description Phase S P E C I F I C A T I O N Vrification Production Documentation Gestion de projets Conduite de projets

Modles Mthodes

P R O D U C T I O N

Modles Mthodes

-Figure 30.6- Fiche signaltique pour un outil. A cette fiche doivent tre ajoutes les contraintes d'intgration que sont: - la base de donnes utilise, ses interfaces et accs, - l'interface de chaque outil. Une autre approche par la demande consiste recenser les besoins prcis de l'organisation utilisatrice de manire disposer d'une base d'analyse pour tudier les solutions existantes. Il s'agit alors du problme de spcification et de conception de l'outil. Bien entendu, une approche mthodologique favorise un tel travail.

600

M.C.S.E

Chapitre 31

REALITES ET PERSPECTIVES
In a sense, the programmers job is inhuman because we require him to write a large amount of complex code without errors. Error-free coding is not natural for our animal-like brain. We cannot handle the meticulous detail and the vast numbers of combinatorial paths. Furthermore, if we want 1000 lines of code produced per day, the job is even more inhuman. It is a job for machines not people. Only recently have we understood how to make machines do it. It is likely that historians in the future, looking back on the extraordinary evolution of computing, will say that the true computer revolution was the one that automated the processes of design and programming. Manual structured techniques were a necessary preliminary to the automation but were not by themselves the true revolution. J. MARTIN et C. McCLURE Intressons-nous pour terminer au concepteur lui-mme. Comme il joue un rle essentiel dans le processus de dveloppement, il est utile de s'interroger sur la manire d'acqurir la comptence ncessaire. D'autre part, l'organisation dans laquelle intervient le concepteur a une responsabilit ne pas ngliger puisqu'elle favorise ou non l'utilisation d'une mthodologie. Enfin, projetons-nous quelques annes dans le futur pour tenter de percevoir ce qui sera ncessaire pour que, ds prsent nous cherchions converger vers cet objectif.

M.C.S.E

601

Partie 8 - BILAN ET PERSPECTIVES 31.1. LA COMPETENCE DU CONCEPTEUR La comptence du concepteur a t juge indispensable. Mais comment s'acquiert-elle?. 2 moyens complmentaires sont considrer: - la formation. Il s'agit de suivre un enseignement de mthodologie pour acqurir: les bases, les concepts, les modles, les mthodes. En un mot, il s'agit de disposer de sa bote outils, connaissant et sachant travailler avec chacun des outils. Comme analogie, le bricoleur peut acheter sa bote outils, mais ce n'est pas pour cela qu'il devient un artisan comptent. - la ralisation de dveloppements. Ce deuxime point est strictement ncessaire, car seule la rsolution de problmes conduit enrichir son exprience. L'exprience est la rsultante du suivi de la dmarche, du travail d'analyse et des choix de dcisions. C'est seulement aprs avoir fait des choix lors d'un dveloppement que le concepteur peut valuer l'opportunit de ses propres dcisions. C'est ce rsultat qui conduit enrichir son exprience. La comptence s'acquiert donc en rsolvant des problmes. La formation ncessite de traiter des tudes de cas qui peuvent tre rsolus par analogie avec d'autres exemples de problmes et de solutions. Ainsi, l'exprience s'acquiert aussi par rutilisation de cette comptence en dveloppements. Mais l'exprience est longue acqurir. Sans prendre au dpart conscience de cette difficult, les rsultats resteront mdiocres. En effet, une telle comptence ne pouvant s'acqurir que d'une manire incrmentale, elle ncessite du temps pour la rflexion face des problmes rels et un travail personnel ou en groupes. Une priode de 6 12 mois nous semble un investissement minimum. La comptence repose sur 2 types de connaissances: - les connaissances mthodologiques, ce qui est l'objet de ce document, - les connaissances scientifiques, techniques, technologiques ncessaires pour dfinir et raliser des produits. Cette deuxime catgorie ncessite au dpart l'acquisition d'un niveau minimum, mais aussi ensuite un investissement rgulier en temps pour suivre l'volution des techniques. Ceci implique une attitude volontariste en s'efforant par exemple une lecture rgulire de revues techniques spcialises. Cet effort de travail permet au concepteur d'avoir une culture sur le matriel et sur le logiciel lui permettant ainsi de savoir ce qui existe, pour faire quoi, et avec quels moyens. Face aux problmes rsoudre, le concepteur doit adopter des attitudes favorisant la russite. Premier point, il faut liminer de son esprit toute ide a priori, or ceci est difficile puisque l'exprience conduit connatre des solutions. Ensuite, le rflexe doit tre de s'attaquer aux points les plus difficiles, alors que l'inverse est plutt la tendance naturelle. D'autre part, comme l'erreur est humaine, le concepteur doit savoir mettre en cause sa solution pour liminer les erreurs inhrentes tout dveloppement. 31.2. RESPONSABILITES DE LORGANISATION Seul le concepteur, malgr toute sa bonne volont, n'a qu'un impact trs limit sur les dveloppements au sein d'une entreprise. 602 M.C.S.E

Ch 31 - REALITES ET PERSPECTIVES Comme l'emploi d'une mthodologie implique un accroissement de l'investissement durant les premires phases de dveloppement de manire rduire ensuite trs notablement le cot pour les phases finales, ceci ne peut se faire sans l'accord et surtout sans l'engagement de la direction. Une organisation de projets avec une approche mthodologique est un investissement long-terme (capital-intensive). L'investissement de dpart se fait, d'une part en formation et en temps d'assimilation et d'exprimentation, d'autre part par un accroissement des ressources humaines durant les phases initiales de spcification et de conception. Le retour d'investissement apparat ensuite sous plusieurs formes: une rduction du cot des phases d'achvement des produits, mais aussi et surtout par une rutilisation au niveau des quipes de l'exprience acquise par chaque participant. Le gain se traduit en plus par une rduction des cots de communication du fait de la documentation et de la manire unique et homogne de traiter les problmes et de dcrire les solutions. Tous ces gains sont difficilement mesurables: en effet il faudrait pouvoir effectuer une comparaison, ce qui est relativement impensable. Ainsi, russir sur le plan mthodologique implique une volont interne l'organisation et l'engagement d'un ou plusieurs responsables obtenir les rsultats attendus. Ce problme est tout fait comparable celui de l'approche Qualit dans les entreprises. 31.3. PERSPECTIVES A LONG TERME Pour lvaluation des perspectives long terme, reprenons l'analyse faite par J. MARTIN pour le logiciel et tout particulirement pour la programmation structure [MARTIN-88]. Premire constatation, selon JONES, la programmation structure n'amliore la productivit que de 25 75%. Ainsi, la productivit en logiciel reste trs en dessous de celle ncessaire pour satisfaire les demandes. Rappelons aussi que la progression pour le matriel est gomtrique par la rutilisation des composants, tandis qu'elle reste linaire pour le logiciel. Ensuite, selon J. MARTIN, pour atteindre le stade de maturit, l'volution vers lutilisation dune technique suit 3 phases: - la crise et reconnaissance d'un besoin, - dveloppement des moyens et dbut de la formation, - assimilation et pratique. La figure 31.1 indique cette volution et plus particulirement celle concernant l'emploi des techniques structures en logiciel. J. MARTIN conclut que l'emploi des techniques structures est totalement insuffisant pour rsorber la "crise du logiciel". La solution est la production automatique de code partir de la conception. Par analogie, que se passe-t-il dans le domaine de la conception des systmes? Selon notre point de vue, situons tout d'abord les 3 phases pour l'emploi de mthodologies: - la phase de crise: 75-80, - la phase de dveloppement: 80-87, - la phase de maturit: 88-90. M.C.S.E 603

Partie 8 - BILAN ET PERSPECTIVES

Inadquation des anciennes mthodes Inventions de nouvelles mthodes Exprimentation de nouvelles mthodes Dmonstration de lintrt des mthodes Dveloppement des bases, principes, thories Raffinement des mthodes
Usage

Dveloppement des cours et formation Large comprhension Dmarche accepte Maturit

PHASE 3 : 75-80

Assimilation et pratique
Techniques structures largement utilises PHASE 2 : 70-75

Dveloppement des moyens

Temps

PHASE 1 : 65-70

-Principe de la programmation structure -Procdures de test -Langage de spcification -Mthodologie pour la conception

Crise et reconnaissance dun besoin

Crise du logiciel : principe pour le dveloppement de logiciels de qualit et de faible cot.

-Figure 31.1- Les 3 phases pour l'emploi des techniques structures. Les mthodologies entrent donc dans une phase de maturit. Il s'agit d'une priode o les dmarches sont disponibles pour rpondre aux besoins des dveloppeurs. Progressivement, la formation favorise la diffusion contribuant ainsi accrotre la qualit des dveloppements. Les outils en tant que supports sont un stade de dmarrage et on peut s'attendre voir une certaine homognit et une plus large utilisation vers 92 95. Pendant la phase de maturit, sera constat l'apport des mthodologies. Bien que strictement ncessaire pour la qualit, comme ce fut le cas pour la programmation structure, la productivit ne sera pas grandement augmente. Pour les systmes temps-rel, la solution pour l'accroissement notable de la productivit, comme l'indique J. MARTIN, est aussi la production automatique des solutions. La dmarche est alors: description de la spcification, vrification et validation de celle-ci, production automatique de la solution conforme aux contraintes. La figure 31.2 illustre une vision de cette progression long terme. Le diagramme reprsente: en abscisse la nature de la description qui va de lide au formel, et en ordonne les phases dun dveloppement. La production automatique n'est possible que si "l'objet" obtenir est compltement spcifi d'une manire formelle. Il doit en tre de mme pour la mthode de production. Si la situation actuelle avec utilisation de mthodes correspond une trajectoire intermdiaire, un objectif moyen terme consiste considrer que la description du niveau fonctionnel est l'interface entre l'activit humaine du concepteur et la production automatique. Cette description doit tre valide ce qui ncessite des moyens automatiques, puis il faut disposer de moyens de production. comme exemple pour la conception des composants VLSI, la compilation de silicium pour la synthse dite architecturale montre bien l'volution vers cet objectif. 604 M.C.S.E

Ch 31 - REALITES ET PERSPECTIVES

Activit humaine Besoin

Activit automatique

Objectif long terme

Spcification

Validation Objectif moyen terme

Conception fonctionnelle Dfinition de la ralisation Ralisation

Situation actuelle
Evolution

Validation

Sans mthode

Production automatique de la solution

Production manuelle
Description Ide Informel Structur Formel

-Figure 31.2- Evolution pour la production dune solution. A plus long terme, le mme raisonnement peut tre fait mais en considrant les spcifications comme interface. Ainsi pour le domaine des systmes temps-rel, se dessine la perspective future qui consiste, partir des mthodologies actuelles et sur la base des modles de description de solutions et si possible de spcifications, rechercher des mthodes formelles de vrification de la description car dveloppe par l'homme la solution est entche d'erreurs, et des mthodes de production de solutions toutes implantes dans des outils de conception. Imaginons un instant une spcification fournie un outil. Celui-ci, aprs vrification de la cohrence de ces spcifications, produit en sortie les documents et la ralisation. Dans ce scnario futuriste, la mthodologie MCSE aura t une contribution durant le passage intermdiaire entre la phase de conception humaine et celle de la conception automatique.

M.C.S.E

605

BIBLIOGRAPHIE 8

[DECLERFAYT-88] "Software Through Pictures" de IDE: Outils et Mthodes O. DECLERFAYT Bigre N58 Janvier 1988, Spcification de logiciel, P.57-67 [FALK-89] Software vendors serve up varied palette for CASE users H. FALK Computer Design Janv.1 1989, P.70-80 [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.396-406 [MARTIN-88] Structured Techniques: the basis for CASE J. MARTIN, C. Mc CLURE Prentice Hall, Englewood Cliffs, N.Y. 1988 [SCHINDLER-87] Advanced tools finally start to automate software design M. SCHINDLER Electronic Design, Nov.27, 1987, P.61-68

M.C.S.E

607

INDEX

A ABBOTT 131 abstraction 41, 262, 293, 358, 477 actigrammes 98 action, activit 192 activit de conception 38 activit VVT 532 ADA 481, 494 ADA Design Methodology 137 ALFORD 113 allocation 367 analyse 292, 308, 534 de la cohrence 326 de la complexit 326 du couplage 325 dynamique 534 formelle 535 statique 534 application 188 approche par l'application 232 par les entits 229 par les entres/sorties 227 sujet 285 ASIC 455 assemblage 538 assurance qualit 551, 571, 574 attributs d'une information 198 de la qualit 572 automate tats finis 152 M.C.S.E

B bote outils 582 BOOCH 130 BUHR 133 C cahier des charges 168, 169 canal 486 capacit des ports 419 caractristiques d'une spcification 182, 245 CASE 591 Certification 532 CFD 117, 121 CFSM 154 chariot filoguid 174, 239, 311, 314, 319, 400, 411, 415, 424, client 178 cohrence 290 commandabilit 256 comptences 583 du concepteur 602 composants existants 454 spcifiques 454 composition 196 horizontale 491 verticale 491 concepteurs 168 conception 24, 40, 587 du logiciel 477 fonctionnelle 55, 300 oriente objet 128, 492 609

SPECIFICATION ET CONCEPTION DES SYSTEMES conduite de projets 597 conformit 457, 531 connaissances 39, 602 construction 308 contenu de la documentation 556 contraintes d'intgrit 444 de rpartition 236, 384, 389 de rpartition gographique 287 de temps 17, 237, 385, 402 contrle 518 de la qualit 571, 574 en vitesse dun centrifugeur 173, 224, 234, 310, 313, 395, 410, 424 correction des erreurs 31 correspondance 365 couplage 291 entre processeurs 425 cots 6 de dveloppement 385 en temps 526 critres de qualit 476, 571 cycle auteurs-lecteurs 244 de dveloppement 57, 582 de vie 23, 24 en V 27 D DARTS 127 datagrammes 98 dcomposition horizontale 294 verticale 294 ddi 16 dfauts 547 dfinition de la ralisation 55 dlimitation des entres-sorties 224, 305 demandeur 168 dmarche ascendante 474 de conception 53 descendante 473 mixte 474 par les fonctions 292 par les variables 293 pour la ralisation 440 DEMARCO 101 610 droulement du projet 559 description algorithmique 316 des relations 198 du systme 216 en niveaux 584 excutive 53 externe 52 finale 53 fonctionnelle 53 fonctionnelle de l'environnement 222 dveloppement 22 du logiciel 478 DFD 101, 117, 121 diagramme tats finis 152 de JACKSON 107, 148 flots de donnes 101, 208 GANTT 515 PERT 516 structur 104 direction 517 document de conception 302, 327 de spcification 184 de test 542 d'installation 239 prliminaire d'utilisation 239 de contrle 557 de dveloppement 557 prliminaire 558 documentation 555, 586 donne 191 E chance 406 ECS 124 laboration de la qualit 574 des spcifications 54 lectronique 15 encapsulation 477 entit 148, 188 donne 195 entropie 509 environnement 16, 188 quipes 517 erreurs 447, 547 M.C.S.E

UNE METHODOLOGIE espace de modlisation 211 estimation 521 des cots 528 tape 40 de spcification 216 de conception fonctionnelle 300 de dfinition de la ralisation 384 de ralisation 436 tat d'une entit 192 vnement 49, 191, 255 volutif 18 excutif temps-rel 377, 378, 480 exprience 602 F fiabilit 532 fonction 49, 255, 259 lmentaire 263, 266, 315 permanente 50 temporaire 50 d'interfaage 286 de dialogue 287 fonctionnement 24 frquence maximale d'activation 404 FSM 152 G gestion de la documentation 565 de la qualit 570 de projets 596 GOMAA 127 graphe tat/transition 201 guide pour la modlisation 211 H HAREL 124 HATLEY 121 I identification des objets 493 implantation de modules 420 des tches 369 directe 479 logicielle 412 modulaire 372 M.C.S.E information 191 informatique 15 industrielle 15 intgration 538 interface homme-machine 392, 395 de dialogue 236 physique 385, 392 interprtation 258 intuition 291 J JACKSON 107 JSD 106 L lecteur 536 lisibilit 326 logiciel 368 M Machine Charts 134 maintenabilit 18, 550 maintenance 546 problmes 546 procdure 549 management 24, 508, 559 pour la maintenance 550 manuels 561 MCSE 9, 35, 45, 56, 156, 582 mcanisme de rendez-vous 481 mmoire 52, 354, 357, 360 mesure de la qualit 573 mthode 38, 39, 43 mthodologie 8, 38, 42, 96 de HATLEY et PIRBHAI 121 de JACKSON 106 de LAVI et HAREL 124 de NIELSEN et SHUMATE 137 de WARD et MELLOR 117 modle 38, 142 client/serveur 336 commande/excution 465 comportemental 50 contractuel 29 contrleur/procd command 330 d'allocation 365 611

SPECIFICATION ET CONCEPTION DES SYSTEMES modle d'excution 352 d'implantation 368 d'interactivit 340 dintgration 364, 381 de comportement 151, 200, 264 de composition hirarchique 195 de description 42, 47, 269 entits/relations 148, 195 excutif 51 fonctionnel 49, 254 gnrique 330 machine de MOORE 461 pour les activits 148 Spirale 28 supervision/contrle-commande 334 tats discrets 200 analytiques 143 conceptuels 143 continus 200 de cycle de vie 26 de solutions 43 explicites 190 externes 190 formels 152 gnriques 460 gnriques de solutions 295 pour les fonctions 149 modlisation 38, 190, 537 de l'environnement 216, 219 des activits 193 des donnes 195 des donnes et informations 193 du comportement 193 dune entit 193 par les activits 207 par les tats 203 stimuli/rponse 204 modularit 477 moniteur multi-tches 377 N nature d'une entit 190 niveau modules 369 taches 368 612 niveaux de fonctionnalits 472 noeud de communication 52, 354, 357, 360 O O.O.D 128 objet 129, 491 observabilit 256 OCCAM 485 organisation 516 du logiciel 412 fonctionnelle 517 matricielle 517 oriente projet 517 outil 598 P partage de variable 49 partie oprative 387 organisationnelle 308, 387 performant 18 perspectives 603 phases pour la spcification 218 plan d'affaire 514 de documentation 564 de projet 514, 558 planification 514, 521 pour la documentation 562 planning 514 politique d'ordonnancement 406 port 255, 259 premire dcomposition fonctionnelle 307 problme 37 processeur 52, 354, 357, 360 gnral 354 oprationnel 367 programmable 368 spcialis 354 production 24 automatique 595, 604 productivit 31, 603 programmation objet 497 structure 491 proprits 265 PSC 128 M.C.S.E

UNE METHODOLOGIE Q qualimtrie 326 qualits 6, 18, 142, 570 de la solution 290 R raffinement 41, 261, 293, 358 en ralisation 448 fonctionnel 301, 312 ralisation 24, 56 logicielle 443 matrielle 442, 454 oriente objet 491 Real-time Structured Analysis 117 rdaction de la documentation 565 rgles de comportement 273 de prsentation 257 de qualit 387 de ralisation 443 relations 49 de partage de variable 255 de synchronisation 255 de transfert d'informations 255 rpartition matriel/logiciel 410 rseau de communication 154 de PETRI 153 de process 107 responsabilits 602 ressources humaines 526 rutilisation 16, 450, 460, 475 reviewer 536 revues de conception 536 R-NET 113 robuste 18 rle d'une spcification 178 RTSA 117 S SA/SD 106 SADT 98 schma dimplantation 370 SDWMC 133 slection des noms 257 service 492 dun processeur 419 pour le modle fonctionnel 489 M.C.S.E signalisation 354 simulation 537 solution de ralisation 384 spcifications 24, 54, 145, 178, 180, 587 des fonctions 232 diverses 238 lectriques 236 fonctionnelles 226 opratoires 235 technologiques 236 temporelles 237 spcifieur 185 SREM 113 STATECHART 125, 202 STATEMATE 124 structuration du cahier des charges 171 structure Chart 104 d'excution 52, 355 d'organisation 517 fonctionnelle 255 fonctionnelle accepte 367 structured analysis 101 design 103 sret de fonctionnement 237, 289 synchronisation 49 SYSREM 115 systme 16, 17 systmes ddis 284 lectroniques 14, 34 T taux d'occupation 367, 405 techniques 39 de ralisation 437, 454 temps d'excution maximum 404 temps rel 17 test 457, 531, 537 d'intgration 538 fonctionnel 457, 539 unitaire 538 testabilit 532 traduction de la structure fonctionnelle 372 traitement des erreurs 446 transfert d'information 49 transputer 485 type abstrait de donnes 491 types d'erreurs 533 613

SPECIFICATION ET CONCEPTION DES SYSTEMES V validation 447, 457, 531 des spcifications 244 variable d'tat 255, 258 variables 192 vrification 179, 308, 531, 594 d'intgrit 534 de conformit 534 de la qualite 574 de raffinement 534 des specifications 233 W WARD 117

614

M.C.S.E

Spcification et conception des systmes Une mthodologie

J.P. CALVEZ

La ralisation des systmes en lectronique et en informatique industrielle impose aux concepteurs, au del du travail technique, de satisfaire le besoin du client, de respecter des dlais et des cots, de satisfaire des critres de qualit. Disposant de techniques et moyens varis pour rsoudre chaque problme, le concepteur doit aussi pouvoir procder selon une dmarche qui lui permette de passer efficacement du problme la dfinition dune solution. Une mthodologie rpond cette ncessit sous la forme dun ensemble ordonn doutils que sont: des modles de description, des mthodes, des solutions. La mthodologie MCSE prsente dans cet ouvrage couvre lensemble des problmes du dveloppement des systmes en incluant la partie matrielle et la partie logicielle. Elle structure les activits en 4 tapes: laboration des spcifications, conception fonctionnelle, dfinition de la ralisation, ralisation. Base sur un modle de description trois composantes, la dmarche est globalement descendante. Elle conduit aussi llaboration de toute la documentation et est utilisable pour la mise en place dune procdure de conduite de projets. Un panorama des mthodologies existantes pour les applications temps-rel montre que MCSE nest pas opposer toute autre mthodologie; bien au contraire, elle se veut complmentaire. Cet ouvrage constitue une rfrence et fournit un fil conducteur tous ceux qui ont en charge la conception de produits ou de systmes et ceux qui dsirent acqurir une comptence en spcification et conception. Il est destin aux responsables de projets, aux concepteurs, aux ralisateurs, aux formateurs et aux tudiants en Informatique Industrielle. Jean Paul CALVEZ est ingnieur gnie lectrique et titulaire dun doctorat dtat en Informatique Industrielle. Il est professeur et directeur des tudes lIRESTE (Institut de Recherche et dEnseignement Suprieur aux Techniques de lElectronique) de NANTES. Enseignant linformatique industrielle depuis plus de vingt ans, il a acquis son exprience par de multiples collaborations industrielles.