Vous êtes sur la page 1sur 22

METHODE SA/RT

(mthode de spcification des systmes temps rel)

Version 2.2 (09/93)

I. PRESENTATION.............................................................................................................................1

II. ORIGINE.........................................................................................................................................2

III. SA/RT DANS LE CYCLE DE VIE..............................................................................................3

IV. LE MODELE DES BESOINS.......................................................................................................4 A. LE MODELE FONCTIONNEL......................................................................................................4 1. LE DCD DIAGRAMME DE CONTEXTE DES DONNES....................................................................................4 2. LES DFD DIAGRAMMES DE FLOTS DE DONNES.........................................................................................4 B. LE MODELE DYNAMIQUE..........................................................................................................7 C. LE MODELE DE DONNEES..........................................................................................................8 D. COMBINAISON................................................................................................................................9 V. LE MODELE D'ARCHITECTURE............................................................................................10 A. OBJECTIFS......................................................................................................................................10 B. ENRICHISSEMENT DU MODELE DES BESOINS................................................................10 C. CONSTRUCTION DU MODELE D'ARCHITECTURE........................................................10 VI. LA DEMARCHE SA/RT.............................................................................................................12 A. ACQUERIR LES INFORMATIONS SUR LE SYSTEME......................................................12 B. DEFINIR LE CONTEXTE.............................................................................................................12 C. DECOMPOSER/DESSINER LE PREMIER NIVEAU............................................................12 D. ECRITURE DES PSPECS.............................................................................................................14 E. ECRITURE DES CSPECS.............................................................................................................14 VII. PASSAGE A LA CONCEPTION..............................................................................................15 A. ARCHITECTURE DYNAMIQUE...............................................................................................15 B. ARCHITECTURE PHYSIQUE....................................................................................................15 C. CONCEPTION ORIENTEE OBJET...........................................................................................15 VIII. SA/RT ET LES OUTILS..........................................................................................................16 A. TEAMWORK...................................................................................................................................16 B. CARDTOOLS...................................................................................................................................16 C. SELECT............................................................................................................................................16 IX. CONCLUSION............................................................................................................................18

13/09/2012

X. ANNEXES......................................................................................................................................19 A. FIGURES................................................................................................................................................19

13/09/2012

La mthode SA/RT 1 I. PRESENTATION

Les outils d'aide la spcification (analysis?) et la conception (design ?) proposent aujourd'hui une panoplie de modles permettants de dcrire les diffrents aspects du quoi et du comment d'un systme, d'un matriel ou d'un logiciel. Nous avons choisi deux mthodes complmentaires en privilgiant leur application dans le domaine de la spcification logiciel : SA/RT METHODE D'ANALYSE DES SYSTEMES TEMPS REELS IM MODELE D'INFORMATION BASE SUR LES DIAGRAMMES ENTITES RELATIONS DE CHEN.

13/09/2012

La mthode SA/RT 2 II. ORIGINE

Les premires mthodes de spcification privilgiaient l'aspect fonctionnel. C'tait le cas de SADT (IDF0), et SA(Yourdon/DeMarco). Pourtant trois angles d'analyse sont ncessaires dans la phase de spcification : fonctionnelle, dynamique, donnes.

Aussi les mthodes se sont-elles enrichies des deux autres aspects (ex IDEF1 et IDEF2 pour SADT, ou SA/RT pour SA), ce qui ne signifie pas qu'ils soient tous supports par les outils. SA/RT pour sa richesse au niveau de l'aspect dynamique a actuellement la faveur des dveloppeurs d'outils. Cette mthode est due aux travaux parallles de HATLEY & PIRBHAI et de WARD & MELLOR. L'aspect donnes y est support par la prsence d'un dictionnaire textuel, pine dorsale de la mthode, peut-tre insuffisant vu l'importance prise par les donnes depuis la vogue des dveloppements orients objets. Le modle entit relation de CHEN apporte la reprsentation graphique complmentaire au dictionnaire purement textuel.

13/09/2012

La mthode SA/RT 3 III. SA/RT DANS LE CYCLE DE VIE

SA/RT est une mthode itrative permettant deux descriptions : une spcification des besoins (le quoi) une architecture (le comment)

C A H IE R D E S CH AR G ES

B E S O IN S D U SYSTEM E

S P E C IF IC A T IO N

A R C H IT E C T U R E D U SYSTEM E

C O N C E P T IO N B E S O IN S D U S O U S -S Y T E M E S P E C IF IC A T I O N C O N C E P T IO N A R C H IT E C T U R E D U S O U S -S Y S T E M E

B E S O IN S D U SYSTEM E

S P E C IF IC A T I O N

A R C H IT E C T U R E D U L O G IC IE L

C O N C E P T IO N

A ce titre elle est utilisable en phase de spcification ou conception, systme ou logiciel. HATLEY & PIRBHAY dfinissent deux formalismes : le modle des besoins, utilisable en spcification systme et en spcification du logiciel. le modle d'architecture utilisable en conception du systme. WARD & MEILLOR dfinissent un seul formalisme : le modle des besoins, utilisable en spcification systme la conception du logiciel utilise le mme formalisme pour l'architecture Malheureusement, les outils ne traitent actuellement que la description des besoins. Les phases directement couvertes sont donc les spcifications des besoins systmes ou logiciels.

13/09/2012

La mthode SA/RT 4 IV. LE MODELE DES BESOINS

Ce modle est abstrait et idalis : ce n'est pas une reprsentation de l'implmentation du systme, mais une description en vue externe du systme raliser. A. LE MODELE FONCTIONNEL Ce modle est reprsent par une suite de planches relies en arborescence.

1. Le DCD diagramme de contexte des donnes Ce diagramme permet de situer le systme dans son contexte.
DCD/DCC DIAGRAMME DE CONTEXTE DONNEES/CONTROLES MATERIEL AUTRE SYSTEME FLOT DISCRET FLOT CONTINU

GERER LE SYSTEME

AUTRE FLOW AUTRE LOGICIEL HOMME

Le PROCESSUS central (bulle) est reprsente le systme raliser. Comme tout processus, son nom doit comporter un verbe montrant l'action et un complment d'objet subissant l'action. Cette bulle porte le numro 0. Chaque TERMINAISON reprsente un lment extrieur au systme avec lequel il est en communication. Des FLOTS DE DONNEES (flches continues) circulent entre processus et terminaison.
1

2. Les DFD diagrammes de flots de donnes Le systme (PROCESSUS 0) est dcris par un DFD 0. Il se dcompose en plusieurs PROCESSUS numrot. Chaque processus (bulle) est une sous-fonction du systme nomme par un verbe plus un complment d'objet.
1L'outil

Select distingue par deux symboles diffrents les flots continus disponibles en permanence des flow discrets disponibles par moment.

13/09/2012

La mthode SA/RT 5 Chaque processus peut son tour se dcomposer en plusieurs sous-processus dans un DFD qui porte le numro du DFD pre plus celui du processus pre. DCD DFD0

DFD1
PSPEC1.2 PSPEC1.2 PSPEC1.3

PSPEC2

DFD3
PSPEC3.1

DFD3.2
PSPEC3.2.1 PSPEC3.2.2

Les fonctions suffisamment lmentaire pour ne pas tre dcomposes sont dcrites par une PSPEC textuelle ou graphique. @IN = CASH LIMIT @IN = SERVICE REQUEST @OUT = CASH AMOUNT @OUT = MESSAGE @OUT = SERVICES REQUIRED @PSPEC 2 GET REQUIRED SERVICES Each time triggered, do: Repeatedly, Issue a MESSAGE asking the customer to select a service. Get the customer SERVICE REQUEST and update the SERVICES REQUIRED, ie MINI STATEMENT REQUEST, BALANCE REQUEST, CASH REQUEST or CHEQUE BOOK REQUEST. Then, if a CASH REQUEST has been made, then, do: Issue a message asking for the cash amount, Get the required CASH AMOUNT ensuring that it does not exceed the customers CASH LIMIT. Until, the customer asks to proceed or, all services have been selected. 13/09/2012

La mthode SA/RT 6

Un DFD peut comprendre galement des RESERVOIRS.

DFD1

F 1.2 VALEUR CONSTANTE INFORMATION 2

STORE INFORMATION F1.1 3


Ce sont des zones de stockage o les donnes sont conserves. Il y a deux types d'utilisation possible : Constante : Ce sont des paramtres du systmes, ventuellement rgls par des fonctions de maintenance non reprsentes. Zone de communication asynchrone : En effet deux processus communiquent par flots de donnes de faon synchrone. Lorsque le processus source n'existe plus lorsque le processus destinataire a besoin de l'information, il est ncessaire de passer par des rservoirs. Un rservoir ne se trouve que sur une seul planche. Si ses informations doivent tre accdes d'une autre planche, il faut propager un flot de donnes. Un processus doit transformer une donne. Il reoit des flots de donnes entrant et gnre des flots de donnes en sortie. Aucun flot ne peut la fois entrer et sortir intacte.

13/09/2012

La mthode SA/RT 7 B. LE MODELE DYNAMIQUE Ce modle est symtrique du modle fonctionnel avec les mmes processus sur les mmes planches appeles cette fois-ci DCC diagramme de contexte des contrles, DFC diagrammes de flots de contrle, avec des flots de contrle.

DCD/DCC DIAGRAMME DE CONTEXTE DONNEES/CONTROLES MATERIEL AUTRE SYSTEME

GERER LE SYSTEME FLOT DE CONTROLE AUTRE LOGICIEL HOMME

En gnral, diagrammes des flots de donnes et diagrammes des flots de contrle sont grs dans un mme schma. Un flot de contrle est toujours un signal discontinu. Un changement d'tat provoque une modification dans la dynamique du systme. Des fonctions du systme peuvent tre active ou dsactives. Les interruptions, l'tat d'un bouton, les modes de fonctionnement, les phases d'activits sont de bons candidats. Un flot de contrle n'est jamais trait par la PSPEC d'un processus. Par contre un processus peut tudier des flots de donnes en entre et en dduire un flot de contrle en sortie. L'lment matre d'un DFC est la CSPEC (spcification de contrle) qui dtermine l'activation ou non des processus. Elle exploite les flots de contrle. Rgles : un flot de contrle trait par une CSPEC ne peut pas descendre galement dans les diagrammes de niveau infrieur. un flot de contrle peut descendre de processus en processus, de DFC en DFC de niveau infrieur, mais doit terme tre trait par une CSPEC.

13/09/2012

La mthode SA/RT 8 il ne peut y avoir qu'une CSPEC par diagramme. La CSPEC (figure 6b) peut combiner les tapes suivantes : combinatoire : les contrles d'entre sont combins par des quations logiques ou table de dcision. (figure 9a) automates tats finis (diagramme ou matrice) (figure 9b). Les tats reprsentent un mode de comportement observable de l'extrieur du systme. transition : mouvement d'un tat un autre. vnement : cause de la transition. action : activit quand une transition survient. L'action peut tre associe la transition ou l'tat . table d'activation : En fonction des tats calculs, les processus peuvent tre activs ou dsactivs. Certaines variantes proposent d'autres types d'action (trigger, suspension). C. LE MODELE DE DONNEES Reprsent par un dictionnaire de donnes : Chaque flot (contrle ou donne), chaque rservoir a sa dfinition dans le dictionnaire. Une donne est primitive ou dcomposable. Les donnes primitives sont discrtes ou continues, avec une srie d'attributs (fig 10) : liste des valeurs possibles, tendue, prcision, frquence, priorit, alias si simple renommage, etc. Les autres sont dcrites avec leurs composants et des oprateurs. liste de valeurs : le flot peut prendre plusieurs valeurs ex : flag = ["true"|"false"]. Le flot flag peut prendre les valeurs littrales "true" ou "false". dcomposition : le flot se dcompose en plusieurs sous-flots ex : couple = site + gisement. site et gisement doivent tre dfinis dans le dictionnaire. Dans un diagramme, couple peut se dcomposer en site et gisement. tableaux : le flot est compos d'un tableau de flots lmentaires. ex : vecteur = { coordonne } Le vecteur est dfini par plusieurs coordonnes. Il est possible de spcifi des limites aux nombre d'lments. vecteur = 2 { coordonne } 3. Il pourra y avoir entre 2 et 3 coordonnes. Il est possible d'utiliser le modle d'information entit relation pour complter la reprsentation. (figure 11) 13/09/2012

La mthode SA/RT 9 Chaque classe d'objets est reprsent par un rectangle. La dfinition de l'objet est dans le dictionnaire. L'objet est dcomposable en champs dont certains peuvent tre des clefs d'accs. Connaissant la valeur d'un champ clef on pourra identifier un objet unique dans sa classe. Les objets sont relis par des relations (losanges) qui mmorisent les informations permettant d'identifier les objets qu'elles relient. Eventuellement certaines entits peuvent n'exister que lorsqu'il y a relation entre deux autres entits. Ce type de diagramme peut reprsenter graphiquement des structures de donnes. Ex : des tables de paramtres avec relation (pointeurs) sur des descriptifs de formats. D. COMBINAISON Les modles fonctionnels et dynamiques sont souvent fusionns dans des diagrammes communs. (figures 3c,5c,6c,7c) La figures rappelle la liste des lments des SART.

13/09/2012

La mthode SA/RT 10 V. A. OBJECTIFS Ce modle n'existe que dans la version HATLEY ET PIRBHAI Plaquer le modle des besoins sur l'architecture en tenant compte des CONTRAINTES pour arriver modliser : les composants physiques les processus physiques l'information qui circule entre eux comment cette information circule C'est donc principalement un modle physique. B. ENRICHISSEMENT DU MODELE DES BESOINS Un enrichissement du modle des besoins est ncessaire par l'ajout des couches interface utilisateur, maintenance auto-test, entres-sorties. (fig 13) Ces aspects sont abords ensuite car leurs objectifs sont diffrents. La couche entres-sorties dpend de l'implmentation, les tests reprsentent un processus parallle, l'interface utilisateur doit se dtacher du processus technique. La couche entres-sorties ajoute des processus de traitement physique de ces entres et de ces sorties entre les terminaisons et les processus du systme. La couche interface utilisateur prcisera le format exacte des affichages et des entres utilisateur. La couche de maintenance ajoute des processus de vrification, de diagnostique de panne, d'auto-test, de rglage des constantes. C. CONSTRUCTION DU MODELE D'ARCHITECTURE Au niveau systme : Identification des interfaces externes, des sous-systmes, dcoupage entre les sous-systmes des fonctionnalits du systmes et interfaage entre les sous-systmes. Au niveau sous-systme ultime : Sparation matrielle et logiciel et interfaage entre les deux. Les divers composants sont : DCA diagramme de contexte d'architecture qui montre comment le systme est physiquement insr dans son environnement (utilisation du formalisme du DCC possible) DFA diagramme de flot d'architecture donnant les modules physiques du systme et les flots d'information entre eux. (utilisation du DFD/DFC au niveau tche et Structured Design pour la conception d'une tche) LE MODELE D'ARCHITECTURE

13/09/2012

La mthode SA/RT 11 SMA Spcification de module d'architecture : Spcification textuelle de l'entit ou groupe d'entits qui sont allous des processus fonctionnels, des processus de contrle et leurs flots associs, dcris dans une spcification de module. DIA diagramme d'interconnexion d'architecture montrant les canaux de communication physiques sur lesquels les informations circulent. SIA spcification d'interconnexion d'architecture dfinissant les caractristiques des canaux de communication entre les modules. Le dictionnaire de donnes : on ajoute des informations physiques aux informations dj contenues.

13/09/2012

La mthode SA/RT 12 VI. LA DEMARCHE SA/RT

Les outils ne traitant que la phase spcification, nous allons indiquer ici la dmarche appliquer pour la construction de la spcification des besoins du logiciel. A. ACQUERIR LES INFORMATIONS SUR LE SYSTEME Il faut dans cette phase analyser le cahier des charges. Lui mme peut renvoyer : d'autres documents analyser un existant observer. Il faut aussi interroger les experts sur le sujet utiliser ses propres connaissances.

Il faut formaliser ces lments en prparant des listes : liste des terminaison (nom d'lments extrieurs au systme) liste des fonctions du systme (verbes) liste des donnes d'interface (noms en liaison avec des terminaisons) liste des contrles et vnements externes. (informations discontinue pouvant modifier le fonctionnement du systme, activation, dsactivation de fonctions ) Il faut trier ces listes, en oprant un liminant les synonymes, en sparant ce qui appartient au systme et ce qu'il lui est extrieur. B. DEFINIR LE CONTEXTE Tracer le diagramme de contexte (DCD et DCC) avec la bulle centrale pour le systme et les terminaisons. Placer les flots entre le systme et les terminaisons. Il ne faut pas renseigner trop tt les flots. C. DECOMPOSER/DESSINER LE PREMIER NIVEAU Dcomposer le systme en ses fonctions principales (de 3 7). Placer les flots de donnes provenant du diagramme suprieur sur les sous-fonctions. Si un flot se dcompose ce niveau, renseigner le dictionnaire en spcifiant la dcomposition (a=b+c). Si les processus ne s'excutent pas en permanence, placer une CSPEC sur le diagramme, et y diriger les contrles qui conditionnent l'activation et la dsactivation des processus de ce niveau. Dfinir la CSPEC (voir plus loin). Diriger les autres contrles sur les processus concerns. (attention, le processus est forcment dcompos). Ajouter les flots internes (donnes ou contrles) produits ou consomms entre processus. Ajouter les rservoirs de stockage. Dfinir les PSPECS des processus non redcomposs.

13/09/2012

La mthode SA/RT 13 Cette phase doit tre r-itre pour chaque processus dcompos.

13/09/2012

La mthode SA/RT 14 D. ECRITURE DES PSPECS Un processus ne se dcomposant pas doit tre dcris par une spcification textuelle ou graphique. Il faut rappeler les flots entrant et sortant, puis dcrire le fonctionnement. La dcomposition peut tre arrt parce que : le processus est suffisamment simple la fonction a dj t dcompose sur une autre planche. On renvoie par une note textuelle la dcomposition dj ralise. dtailler plus avant le processus demande des choix de conception. E. ECRITURE DES CSPECS La phase combinatoire est ncessaire si les combinaisons de conditions sont complexes ou si l'outil n'autorise pas les quations logiques comme condition dans les tapes suivantes. La phase automate est ncessaire si la dynamique du niveau courant dpend de son historique. La phase Table d'activation est toujours ncessaire sauf si l'outils permet de spcifier directement les actions au niveau de son automate.

13/09/2012

La mthode SA/RT 15 VII. A. ARCHITECTURE DYNAMIQUE La mthode WARD et MEYLLOR propose d'allouer les fonctions de plus haut niveau aux cpu, puis aux tches. On utilise alors la mthode SA/RT pour rorganiser les premiers niveaux de la spcification, en utilisant une bulle par tche. B. ARCHITECTURE PHYSIQUE Le passage initial l'architecture physique consiste dfinir une fonction pour chaque PSPEC terminale. Pour chaque planche on choisit une fonction matre qui ralise le travail indiqu dans la CSPEC. On utilise souvent la mthode SD pour raliser ce passage. C. CONCEPTION ORIENTEE OBJET Il existe des rgles de passage, mais il faut bien admettre que la mthode SA/RT est peu appropri la conception oriente objets. TEAMWORK propose cependant d'utiliser le mme outil pour travailler dans une mthode de spcification orient objets. PASSAGE A LA CONCEPTION

13/09/2012

La mthode SA/RT 16 VIII. A. TEAMWORK Les outils les plus utiliss dans notre domaine sont STP de IGL et TEAMWORK de DECISION INTERNATIONAL. Une tude comparative mene en 92 a conclut en faveur du second dont nous disposons d'une licence. Il a t utiliser pour spcifier deux petits outils logiciels, un sous-ensemble de viseur et un sous-ensemble de PA avec une relative satisfaction. Les possibilits de simulation ne sont par contre pas convaincantes. Il supporte un modle SA/RT trs complet, le modle relationnel IM, gnre une documentation de bonne qualit, est interfaable assez facilement d'autres outils. B. CARDTOOLS CARDTOOLS est l'outil de spcification et de conception utilis principalement dans le cas de l'utilisation du moniteur VRTX. Il a donn satisfaction dans ce domaine pour la conception. La version 90 supporte la mthode SART avec quelques nuances : Le dictionnaire est renseign par une page d'interrogation avec des rubriques remplir. Le formalisme est diffrent mais il permet galement de dcomposer les flots (record, tableaux, etc) ou de les dcrire. La phase CSPEC ne comprend pas de table d'activation. Si l'outil le permet, je conseil une convention au niveau des actions spcifies dans les automates, avec des mots-clefs activation, dsactivation, etc. Sinon ou peut galement fabriquer des flots en sortie d'automate qui seront tests par les fonctions, mais cette solution me semble moins conforme la mthode. La table de dcision est remplace par des quations logiques dans les automates. La seule utilisation en grandeur relle pour une spcification n'a pas donne satisfaction. C. SELECT SELECT est un outil sur PC dont une licence a t acquise titre d'essai par RD/GM. Il supporte de faon assez complte les mthode HATLEY ou WARD & MELLOR. Il ne gnre pas de documentation mais ses diagrammes sont incorporable WINWORD par couper-coller. Il n'y a pas de couper coller. SA/RT et les outils

13/09/2012

La mthode SA/RT 17 Cela semble un bonne outil de complment utilisable en formation ou pour de petites applications.

13/09/2012

La mthode SA/RT 18 IX. CONCLUSION

La mthode SA/RT va dans le sens de la formalisation des spcifications, avec une garantie de compltude et de non ambigit. Elle n'est probablement pas utilisable pour tous les aspects de la spcification mais demande tre complter sur d'autres : interface homme machine (maquettage) automates trs complexes reprsentation de donnes (IM) modes dgrads testables en validation

Applique fond, l'effort de spcification devient important. Cette mthode demande une certaine rigueur pour viter de faire de la conception. Certains ont choisis de se servir de ce dfaut en utilisant SA/RT en dbut de conception. L'effort consentit en spcification diminue alors beaucoup celui de la conception. On peut galement reprocher cette mthode un couplage difficile avec la conception oriente objets.

13/09/2012

La mthode SA/RT 19 X. A. FIGURES ANNEXES

13/09/2012