I. presentation








télécharger 65.55 Kb.
titreI. presentation
date de publication20.03.2018
taille65.55 Kb.
typeDocumentos
ar.21-bal.com > droit > Documentos



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

X. ANNEXES 19

A. Figures 19

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

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

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



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.

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

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

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.



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.


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.

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

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



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


ex : couple = site + gisement. site et gisement doivent être définis dans le dictionnaire. Dans un diagramme, couple peut se décomposer en site et gisement.


  • tableaux : le flot est composé d'un tableau de flots élémentaires.


ex : vecteur = { coordonnée } Le vecteur est défini par plusieurs coordonnées. Il est possible de spécifié des limites aux nombre d'éléments. vecteur = 2 { coordonnée } 3. Il pourra y avoir entre 2 et 3 coordonnées.
Il est possible d'utiliser le modèle d'information entité relation pour compléter la représentation. (figure 11)
Chaque classe d'objets est représenté par un rectangle. La définition de l'objet est dans le dictionnaire. L'objet est décomposable en champs dont certains peuvent être des clefs d'accès. Connaissant la valeur d'un champ clef on pourra identifier un objet unique dans sa classe.
Les objets sont reliés par des relations (losanges) qui mémorisent les informations permettant d'identifier les objets qu'elles relient. Eventuellement certaines entités peuvent n'exister que lorsqu'il y a relation entre deux autres entités.
Ce type de diagramme peut représenter graphiquement des structures de données. Ex : des tables de paramètres avec relation (pointeurs) sur des descriptifs de formats.

D.COMBINAISON


Les modèles fonctionnels et dynamiques sont souvent fusionnés dans des diagrammes communs. (figures 3c,5c,6c,7c)
La figures rappelle la liste des éléments des SART.

V.LE MODELE D'ARCHITECTURE

A.OBJECTIFS


Ce modèle n'existe que dans la version HATLEY ET PIRBHAI
Plaquer le modèle des besoins sur l'architecture en tenant compte des CONTRAINTES pour arriver à modéliser :

les composants physiques

les processus physiques

l'information qui circule entre eux

comment cette information circule
C'est donc principalement un modèle physique.

B.ENRICHISSEMENT DU MODELE DES BESOINS


Un enrichissement du modèle des besoins est nécessaire par l'ajout des couches interface utilisateur, maintenance auto-test, entrées-sorties. (fig 13)
Ces aspects sont abordés ensuite car leurs objectifs sont différents. La couche entrées-sorties dépend de l'implémentation, les tests représentent un processus parallèle, l'interface utilisateur doit se détacher du processus technique.
La couche entrées-sorties ajoute des processus de traitement physique de ces entrées et de ces sorties entre les terminaisons et les processus du système.
La couche interface utilisateur précisera le format exacte des affichages et des entrées utilisateur.
La couche de maintenance ajoute des processus de vérification, de diagnostique de panne, d'auto-test, de réglage des constantes.

C.CONSTRUCTION DU MODELE D'ARCHITECTURE


Au niveau système : Identification des interfaces externes, des sous-systèmes, découpage entre les sous-systèmes des fonctionnalités du systèmes et interfaçage entre les sous-systèmes.
Au niveau sous-système ultime : Séparation matérielle et logiciel et interfaçage entre les deux.
Les divers composants sont :

  • DCA diagramme de contexte d'architecture qui montre comment le système est physiquement inséré dans son environnement (utilisation du formalisme du DCC possible)




  • DFA diagramme de flot d'architecture donnant les modules physiques du système et les flots d'information entre eux. (utilisation du DFD/DFC au niveau tâche et Structured Design pour la conception d'une tâche)




  • SMA Spécification de module d'architecture : Spécification textuelle de l'entité ou groupe d'entités à qui sont alloués des processus fonctionnels, des processus de contrôle et leurs flots associés, décris dans une spécification de module.




  • DIA diagramme d'interconnexion d'architecture montrant les canaux de communication physiques sur lesquels les informations circulent.




  • SIA spécification d'interconnexion d'architecture définissant les caractéristiques des canaux de communication entre les modules.




  • Le dictionnaire de données : on ajoute des informations physiques aux informations déjà contenues.



VI.LA DEMARCHE SA/RT


Les outils ne traitant que la phase spécification, nous allons indiquer ici la démarche à appliquer pour la construction de la spécification des besoins du logiciel.

A.ACQUERIR LES INFORMATIONS SUR LE SYSTEME


Il faut dans cette phase analyser le cahier des charges. Lui même 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 éléments en préparant des listes :
liste des terminaison (nom d'éléments extérieurs au système)

liste des fonctions du système (verbes)

liste des données d'interface (noms en liaison avec des terminaisons)

liste des contrôles et événements externes. (informations discontinue pouvant modifier le fonctionnement du système, activation, désactivation de fonctions )
Il faut trier ces listes, en opérant un éliminant les synonymes, en séparant ce qui appartient au système et ce qu'il lui est extérieur.

B.DEFINIR LE CONTEXTE


Tracer le diagramme de contexte (DCD et DCC) avec la bulle centrale pour le système et les terminaisons.

Placer les flots entre le système et les terminaisons. Il ne faut pas renseigner trop tôt les flots.

C.DECOMPOSER/DESSINER LE PREMIER NIVEAU


Décomposer le système en ses fonctions principales (de 3 à 7). Placer les flots de données provenant du diagramme supérieur sur les sous-fonctions. Si un flot se décompose à ce niveau, renseigner le dictionnaire en spécifiant la décomposition (a=b+c).
Si les processus ne s'exécutent pas en permanence, placer une CSPEC sur le diagramme, et y diriger les contrôles qui conditionnent l'activation et la désactivation des processus de ce niveau. Définir la CSPEC (voir plus loin). 

Diriger les autres contrôles sur les processus concernés. (attention, le processus est forcément décomposé).
Ajouter les flots internes (données ou contrôles) produits ou consommés entre processus.
Ajouter les réservoirs de stockage.
Définir les PSPECS des processus non redécomposés.
Cette phase doit être ré-itérée pour chaque processus décomposé.


D.ECRITURE DES PSPECS


Un processus ne se décomposant pas doit être décris par une spécification textuelle ou graphique. Il faut rappeler les flots entrant et sortant, puis décrire le fonctionnement.
La décomposition peut être arrêté parce que :

le processus est suffisamment simple

la fonction a déjà été décomposée sur une autre planche. On renvoie par une note textuelle à la décomposition déjà réalisée.

détailler plus avant le processus demande des choix de conception.

E.ECRITURE DES CSPECS


La phase combinatoire est nécessaire 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 nécessaire si la dynamique du niveau courant dépend de son historique.
La phase Table d'activation est toujours nécessaire sauf si l'outils permet de spécifier directement les actions au niveau de son automate.

VII.PASSAGE A LA CONCEPTION

A.ARCHITECTURE DYNAMIQUE


La méthode WARD et MEYLLOR propose d'allouer les fonctions de plus haut niveau aux cpu, puis aux tâches. On utilise alors la méthode SA/RT pour réorganiser les premiers niveaux de la spécification, en utilisant une bulle par tâche.

B.ARCHITECTURE PHYSIQUE


Le passage initial à l'architecture physique consiste à définir une fonction pour chaque PSPEC terminale. Pour chaque planche on choisit une fonction maître qui réalise le travail indiqué dans la CSPEC.
On utilise souvent la méthode SD pour réaliser ce passage.

C.CONCEPTION ORIENTEE OBJET


Il existe des règles de passage, mais il faut bien admettre que la méthode SA/RT est peu approprié à la conception orientée objets.
TEAMWORK propose cependant d'utiliser le même outil pour travailler dans une méthode de spécification orienté objets.


VIII.SA/RT et les outils

A.TEAMWORK


Les outils les plus utilisés dans notre domaine sont STP de IGL et TEAMWORK de DECISION INTERNATIONAL. Une étude comparative menée en 92 a conclut en faveur du second dont nous disposons d'une licence.
Il a été utiliser pour spécifier deux petits outils logiciels, un sous-ensemble de viseur et un sous-ensemble de PA avec une relative satisfaction. Les possibilités de simulation ne sont par contre pas convaincantes.
Il supporte un modèle SA/RT très complet, le modèle relationnel IM, génére une documentation de bonne qualité, est interfaçable assez facilement à d'autres outils.


B.CARDTOOLS


CARDTOOLS est l'outil de spécification 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 méthode SART avec quelques nuances :


  • Le dictionnaire est renseigné par une page d'interrogation avec des rubriques à remplir. Le formalisme est différent mais il permet également de décomposer les flots (record, tableaux, etc) ou de les décrire.




  • La phase CSPEC ne comprend pas de table d'activation. Si l'outil le permet, je conseil une convention au niveau des actions spécifiées dans les automates, avec des mots-clefs activation, désactivation, etc. Sinon ou peut également fabriquer des flots en sortie d'automate qui seront testés par les fonctions, mais cette solution me semble moins conforme à la méthode.




  • La table de décision est remplacée par des équations logiques dans les automates.


La seule utilisation en grandeur réelle pour une spécification n'a pas donnée satisfaction.

C.SELECT


SELECT est un outil sur PC dont une licence a été acquise à titre d'essai par RD/GM.
Il supporte de façon assez complète les méthode HATLEY ou WARD & MELLOR.
Il ne génère pas de documentation mais ses diagrammes sont incorporable à WINWORD par couper-coller.
Il n'y a pas de couper coller.
Cela semble un bonne outil de complément utilisable en formation ou pour de petites applications.

IX.CONCLUSION


La méthode SA/RT va dans le sens de la formalisation des spécifications, avec une garantie de complétude et de non ambigüité.
Elle n'est probablement pas utilisable pour tous les aspects de la spécification mais demande à être compléter sur d'autres :


  • interface homme machine (maquettage)

  • automates très complexes

  • représentation de données (IM)

  • modes dégradés testables en validation


Appliquée à fond, l'effort de spécification devient important. Cette méthode demande une certaine rigueur pour éviter de faire de la conception.
Certains ont choisis de se servir de ce défaut en utilisant SA/RT en début de conception. L'effort consentit en spécification diminue alors beaucoup celui de la conception.
On peut également reprocher à cette méthode un couplage difficile avec la conception orientée objets.

X.ANNEXES

A.Figures




1L'outil Select distingue par deux symboles différents les flots continus disponibles en permanence des flow discrets disponibles par moment.


similaire:

I. presentation iconAdh [Doazan+Hirschberger & associés] Présentation & Moyens Présentation

I. presentation iconPrésentation et objectifs
«Musiciens et partenaires» accessible depuis la page d’accueil et sont également joints à cette présentation

I. presentation iconPrésentation

I. presentation iconPrésentation

I. presentation iconPresentation

I. presentation iconI présentation

I. presentation iconPresentation

I. presentation iconI. 1- présentation de l’institution

I. presentation iconRapport de Présentation

I. presentation iconRapport de presentation








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com