METHODE SA/ RT

(mthode de spcifica tion 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 DONNEES .................................................................... 4
2. LES DFD DIAGRAMMES DE FLOTS DE DONNEES .......................................................................... 5
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 ET IM .................................................................................................. 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

26/04/2015

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

26/04/2015

La mthode SA/RT

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.

26/04/2015

La mthode SA/RT

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.

26/04/2015

La mthode SA/RT

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)

CAHIER DES
CHARGES

BESOINS
DU SYSTEME

SPECIFICATION

ARCHITECTURE
DU SYSTEME

CONCEPTION
BESOINS
DU
SOUS-SYTEME

SPECIFICATION

ARCHITECTURE
DU
SOUS-SYSTEME

CONCEPTION

BESOINS
DU SYSTEME

SPECIFICATION

ARCHITECTURE
DU LOGICIEL

CONCEPTION

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.

26/04/2015

La mthode SA/RT

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
AUTRE
SYSTEME

MATERIEL

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)1 circulent entre processus et terminaison.

1L'outil

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

26/04/2015

La mthode SA/RT

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

PSPEC2

PSPEC1.2 PSPEC1.2 PSPEC1.3

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:

26/04/2015

La mthode SA/RT

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.

Un DFD peut comprendre galement des RESERVOIRS.

DFD1

F
1.2
VALEUR
CONSTANTE

2
INFORMATION

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.

26/04/2015

La mthode SA/RT

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

AUTRE
SYSTEME

MATERIEL

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.

26/04/2015

La mthode SA/RT
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.

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't a t .
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.

26/04/2015

La mthode SA/RT

9
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)
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.

26/04/2015

La mthode SA/RT

10

V.LE MODELE D'ARCHITECTURE

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)

26/04/2015

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.

26/04/2015

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.

26/04/2015

La mthode SA/RT

Cette phase doit tre r-itre pour chaque processus dcompos.

26/04/2015

13

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.

26/04/2015

La mthode SA/RT

15

VII.PASSAGE A LA CONCEPTION
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.

26/04/2015

La mthode SA/RT

16

VIII.SA/RT et les outils

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.

26/04/2015

La mthode SA/RT

17

Cela semble un bonne outil de complment utilisable en formation ou pour de petites

applications.

26/04/2015

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.

26/04/2015

La mthode SA/RT

19

X.ANNEXES
A. FIGURES

26/04/2015