presentation SA/RT/IM

METHODE SA/RT
(méthode de spécification des
systèmes temps réel) 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 données 4
2. Les DFD diagrammes de flots de données 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
X. ANNEXES 19 A. FIGURES 19
PRESENTATION LES OUTILS D'AIDE À LA SPÉCIFICATION (ANALYSIS?) ET À LA CONCEPTION (DESIGN
?) PROPOSENT AUJOURD'HUI UNE PANOPLIE DE MODÈLES PERMETTANTS DE DÉCRIRE LES
DIFFÉRENTS ASPECTS DU QUOI ET DU COMMENT D'UN SYSTÈME, D'UN MATÉRIEL OU
D'UN LOGICIEL. Nous avons choisi deux méthodes complémentaires en privilégiant leur
application dans le domaine de la spécification logiciel :
SA/RT METHODE D'ANALYSE DES SYSTEMES TEMPS REELS
IM MODELE D'INFORMATION BASE SUR LES DIAGRAMMES ENTITES
RELATIONS DE CHEN.
ORIGINE LES PREMIÈRES MÉTHODES DE SPÉCIFICATION PRIVILÉGIAIENT L'ASPECT
FONCTIONNEL. C'ÉTAIT LE CAS DE SADT (IDF0), ET SA(YOURDON/DEMARCO).
POURTANT TROIS ANGLES D'ANALYSE SONT NÉCESSAIRES DANS LA PHASE DE
SPÉCIFICATION :
fonctionnelle,
dynamique,
données. Aussi les méthodes 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 supportés par les outils. SA/RT pour sa richesse au niveau de l'aspect dynamique a actuellement la
faveur des développeurs d'outils. Cette méthode est due aux travaux
parallèles de HATLEY & PIRBHAI et de WARD & MELLOR. L'aspect données y est supporté par la présence d'un dictionnaire textuel,
épine dorsale de la méthode, peut-être insuffisant vu l'importance prise
par les données depuis la vogue des développements orientés objets. Le modèle entité relation de CHEN apporte la représentation graphique
complémentaire au dictionnaire purement textuel.
SA/RT DANS LE CYCLE DE VIE SA/RT EST UNE MÉTHODE ITÉRATIVE PERMETTANT DEUX DESCRIPTIONS :
une spécification des besoins (le quoi)
une architecture (le comment)
[pic] A ce titre elle est utilisable en phase de spécification ou conception,
système ou logiciel. HATLEY & PIRBHAY définissent deux formalismes :
le modèle des besoins, utilisable en spécification système et en
spécification du logiciel.
le modèle d'architecture utilisable en conception du système.
WARD & MEILLOR définissent un seul formalisme :
le modèle des besoins, utilisable en spécification système
la conception du logiciel utilise le même formalisme pour
l'architecture Malheureusement, les outils ne traitent actuellement que la description des
besoins. Les phases directement couvertes sont donc les spécifications des
besoins systèmes ou logiciels.
LE MODELE DES BESOINS CE MODÈLE EST ABSTRAIT ET IDÉALISÉ : CE N'EST PAS UNE REPRÉSENTATION DE
L'IMPLÉMENTATION DU SYSTÈME, MAIS UNE DESCRIPTION EN VUE EXTERNE DU SYSTÈME
À RÉALISER.
1 LE MODELE FONCTIONNEL Ce modèle est représenté par une suite de planches reliées en arborescence. 1 Le DCD diagramme de contexte des données Ce diagramme permet de situer le système dans son contexte. [pic] Le PROCESSUS central (bulle) est représente le système à réaliser. Comme
tout processus, son nom doit comporter un verbe montrant l'action et un
complément d'objet subissant l'action. Cette bulle porte le numéro 0. Chaque TERMINAISON représente un élément extérieur au système avec lequel
il est en communication. Des FLOTS DE DONNEES (flèches continues)[1] circulent entre processus et
terminaison.
2 Les DFD diagrammes de flots de données Le système (PROCESSUS 0) est décris par un DFD 0. Il se décompose en
plusieurs PROCESSUS numéroté. Chaque processus (bulle) est une sous-
fonction du système nommée par un verbe plus un complément d'objet. Chaque processus peut à son tour se décomposer en plusieurs sous-processus
dans un DFD qui porte le numéro du DFD père plus celui du processus père. [pic]
Les fonctions suffisamment élémentaire pour ne pas être décomposées sont
décrites 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.
Un DFD peut comprendre également des RESERVOIRS. [pic]
Ce sont des zones de stockage où les données sont conservées. Il y a deux
types d'utilisation possible :
Constante : Ce sont des paramètres du systèmes, éventuellement réglés
par des fonctions de maintenance non représentées.
Zone de communication asynchrone : En effet deux processus
communiquent par flots de données de façon synchrone. Lorsque le
processus source n'existe plus lorsque le processus destinataire a
besoin de l'information, il est nécessaire de passer par des
réservoirs. Un réservoir ne se trouve que sur une seul planche. Si ses informations
doivent être accédées d'une autre planche, il faut propager un flot de
données. Un processus doit transformer une donnée. Il reçoit des flots de données
entrant et génère des flots de données en sortie. Aucun flot ne peut à la
fois entrer et sortir intacte.
2 LE MODELE DYNAMIQUE Ce modèle est symétrique du modèle fonctionnel avec les mêmes processus sur
les mêmes planches appelées cette fois-ci DCC diagramme de contexte des
contrôles, DFC diagrammes de flots de contrôle, avec des flots de contrôle. [pic] En général, diagrammes des flots de données et diagrammes des flots de
contrôle sont gérés dans un même schéma. Un flot de contrôle est toujours un signal discontinu. Un changement
d'état provoque une modification dans la dynamique du système. Des
fonctions du système peuvent être activée ou désactivées. Les
interruptions, l'état d'un bouton, les modes de fonctionnement, les phases
d'activités sont de bons candidats. Un flot de contrôle n'est jamais traité par la PSPEC d'un processus. Par
contre un processus peut étudier des flots de données en entrée et en
déduire un flot de contrôle en sortie.
L'élément maître d'un DFC est la CSPEC (spécification de contrôle) qui
détermine l'activation ou non des processus. Elle exploite les flots de
contrôle. Règles :
* un flot de contrôle traité par une CSPEC ne peut pas descendre
également dans les diagrammes de niveau inférieur.
* un flot de contrôle peut descendre de processus en processus, de
DFC en DFC de niveau inférieur, 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 contrôles d'entrée sont combinés par des
équations logiques ou table de décision. (figure 9a)
* automates à états finis (diagramme ou matrice) (figure 9b).
* Les états représentent un mode de comportement observable de
l'extérieur du système.
* transition : mouvement d'un état à un autre.
* événement : cause de la transition.
* action : activité quand une transition survient. L'action peut
être associée à la transition ou à l'état.
* table d'activation : En fonction des états calculés, les
processus peuvent être activés ou désactivés. Certaines
variantes proposent d'autres types d'action (trigger,
suspension).
3 LE MODELE DE DONNEES Représenté par un dictionnaire de données : Chaque flot (contrôle ou donnée), chaque réservoir a sa définition dans le
dictionnaire. Une donnée est primitive ou décomposable. Les données primitives sont discrètes ou continues, avec une série
d'attributs (fig 10) : liste des valeurs possibles, étendue, précision,
fréquence, priorité, alias si simple renommage, etc. Les autres sont décrites avec leurs composants et des opérateurs. * liste de valeurs : le flot peut prendre plusieurs valeurs
ex : flag = ["true"|"false"]. Le flot flag peut
prendre les valeurs littérales "true" ou "false". * décomposition : le flot se décompose en plusieurs sous-fl