-
METHODE SA/ RT (mthode de spcification des
systmes temps rel)
Version 2.2 (09/93)
-
26/04/2015
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
-
La mthode SA/RT 1
26/04/2015
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.
-
La mthode SA/RT 2
26/04/2015
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.
-
La mthode SA/RT 3
26/04/2015
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)
BESOINSDU SYSTEME
ARCHITECTUREDU SYSTEME
ARCHITECTUREDU SOUS-SYSTEME
BESOINSDU SYSTEMEBESOINSDU SYSTEME
CAHIER DES CHARGES
BESOINSDU SOUS-SYTEME
ARCHITECTUREDU LOGICIEL
SPECIFICATION
CONCEPTION
SPECIFICATION
SPECIFICATION
CONCEPTION
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.
-
La mthode SA/RT 4
26/04/2015
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.
GERERLE SYSTEME
AUTRELOGICIEL
MATERIELAUTRE
SYSTEME
HOMME
DCD/DCC DIAGRAMME DE CONTEXTE DONNEES/CONTROLES
FLOT DISCRETFLOT CONTINU
AUTRE FLOW
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.
-
La mthode SA/RT 5
26/04/2015
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 DFD3
DFD3.2
PSPEC2
PSPEC1.2PSPEC3.1
PSPEC1.2 PSPEC1.3
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:
-
La mthode SA/RT 6
26/04/2015
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.
F1.2
2
F1.1
3
CONSTANTE
VALEUR
INFORMATION
DFD1
STORE
INFORMATION
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.
-
La mthode SA/RT 7
26/04/2015
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.
GERERLE SYSTEME
AUTRELOGICIEL
MATERIELAUTRE
SYSTEME
HOMME
DCD/DCC DIAGRAMME DE CONTEXTE DONNEES/CONTROLES
FLOT DECONTROLE
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.
-
La mthode SA/RT 8
26/04/2015
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'ta 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.
-
La mthode SA/RT 9
26/04/2015
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.
-
La mthode SA/RT 10
26/04/2015
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)
-
La mthode SA/RT 11
26/04/2015
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.
-
La mthode SA/RT 12
26/04/2015
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.
-
La mthode SA/RT 13
26/04/2015
Cette phase doit tre r-itre pour chaque processus dcompos.
-
La mthode SA/RT 14
26/04/2015
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.
-
La mthode SA/RT 15
26/04/2015
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.
-
La mthode SA/RT 16
26/04/2015
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.
-
La mthode SA/RT 17
26/04/2015
Cela semble un bonne outil de complment utilisable en formation
ou pour de petites
applications.
-
La mthode SA/RT 18
26/04/2015
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.
-
La mthode SA/RT 19
26/04/2015
X.ANNEXES
A. FIGURES
