École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et Industriel
C235
Spécification des Systèmes Temps Réel
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Marc LE GOCProfesseur à Polytech’MarseilleIntelligence Artificielle, Informatique Temps Réel & Commande des ProcessusChercheur au LSIS, UMR CNRS 6168Intelligence Artificielle appliquée au Diagnostic des systèmes temporels
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Objectifs
Comprendre le (les) discours sur la méthode.Notion de méthodologie.Plaidoyer pour les approches méthodiques.
Donner les bases permettant de maîtriser la complexité des systèmes temps réels.
Problème de la maîtrise de la dynamique d’un système.
Maîtriser les outils méthodologiques de base.Pour décrire et raisonner sur la dynamique d’un système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Objectifs
Le cours est volontairement orienté vers les aspects industriels de la mise en œuvre de méthodes.Les notions évoquées seront concrétisées, illustrées à partir de la méthode SA-RT, mais l’objectif est plus général,... donc moins précis.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C01 : Problématique des STR
Notions de Projet et de contratRecette et validationSpécificité des Systèmes Temps Réel
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de Projet
Un projet est lié à un objectif exprimé dans un Cahier des Charges. Unicité d’un projet car Multiplicité des facettes:
Economiques (financières, commerciales, juridiques,...): Quand? Combien?Techniques (méthodes, technologies, qualité,...): Quoi? Comment?Quels Savoirs? Quels Savoir-Faire?Organisationnelles (sociétés ou des organisations différentes, cultures différentes, éloignement géographique,...): Où? Qui? Quelle structure?
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de Projet
Un projet possède une durée par définition limitée.Un projet n ’est pas une structure pérenne (un service d’exploitation par exemple).Date de départ plus ou moins claire.Date de fin est encore plus floue, beaucoup plus floue...
Echec,Manque de moyens (sous-estimation de l’effort),Réussite.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de Projet
Il faut donc se préoccuper de l’après projet dès son démarrage.
Que deviennent les acteurs du projet?Que devient le système (maintenance)?
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Projet et communication
Question fondamentale: Comment s’assure-t-on que tous les acteurs se comprennent?La communication est au cœur de la problématique soulevée par la notion de projet.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Projet et communication
Communication interne:Entre tous les acteurs du projet (secrétaires, développeurs, experts, chercheurs, qualiticiens, Directeur de projet,...) et vis à vis des éventuels consultants en technologies, en méthodes, en organisation, en qualité,...
Communication externe:Dans l’entreprise, entre l’équipe de projet et les mandants (Directions Générales, Chefs de Services, Juristes,...)Hors de l’entreprise, dans les congrès, dans les démonstrations,
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
Au départ d’un projet, il y a un besoin identifié par une organisation (entreprise, institution,...) comme étant non-satisfait.La valuation du besoin quantifie le montant e l’investissement. Il sera engagé si l’espoir du gain est supérieur à l’investissement.Si l’investissement nécessite des compétences que l’organisation ne possède pas, elle fera appel à un prestataire de service réputé capable de satisfaire le besoin.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
Pour établir la relation Client-Fournisseur, l’organisation doit mener toutes les études permettant d’établir un Cahier des Charges, document qui exprime son besoin de la manière la plus claire et précise que possible.
La finalité première du Cahier des Charges ets l’expressionde l’objectif du projetEnsuite viennent les descriptions de l’organisation, de l’environnement, des fonctions, et des contraintes
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
Le prestataire de service établi une offre technique, organisationnelle et financière susceptible de répondre au besoin de l’organisation:
Le prestataire de service doit convaincre l’organisation que sa maîtrise technique, organisationnelle et financière sont de nature à satisfaire son besoin.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
La relation financière entre l’organisation et le prestataire de service est spécifiée dans le contrat :
Identifier le Client (ici l’organisation), ses droits et ses devoirs.Identifier le Fournisseur (ici le prestataire de service), ses droits et ses devoirs.Définir l’objet de la transaction (i.e. ce pour quoi un Client paie un Fournisseur).Définir les conditions d’achèvement des travaux.Définir les modalités particulières (cas de rupture de contrat, dispositions juridiques,...).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
Le contrat est donc le document de référence «ultime» pour trancher en cas de litige entre un Client et son Fournisseur.Le contrat spécifie la totalité des documents produits au titre du projet (plans qualités, analyse externe, dossiers d’étude de faisabilité, de spécification, de conception, de recette,...)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Notion de contrat
Cahier desCharges
OffreT/O/F
Contrat
Anex
Spag/MCE/MCoop/...
Spec1/Spec2/…/Specn
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Maîtrise d ’Ouvrage vs d’Oeuvre
Le Maître d’Ouvrage est le donneur d’ordre.Il définit ce qui est à faire (le quoi).Il est contraint de donner toutes les informations nécessaires aux travaux menés par le Maître d’Oeuvre.Il est chargé d’exécuter la procédure (ou protocole) de recette de la prestation permettant la déclaration du bon achèvement des travaux.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Maîtrise d ’Ouvrage vs d’Oeuvre
Le Maître d’Oeuvre est l’exécutant.Il définit les moyens à mettre en œuvre (le comment).Il est contraint de donner toutes les informations nécessaires au suivi des travaux par le Maître d’Ouvrage.Il est chargé de mettre en œuvre tous les moyens permettant le déroulement du protocole de recette.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Obligation de moyens vs de résultats
Les droits et devoirs du Maître d’Ouvrage et du Maître d’Oeuvre se déclinent selon 2 grandes familles de contrat :
Obligation de résultats :Le Maître d’Ouvrage transfert le risque sur le Maître d’Oeuvre.
Le Maître d’Oeuvre accepte en se couvrant financièrement.Le Maître d’Ouvrage ne peut pas imposer ses méthodes.
Obligation de Moyens : Partage des risques.Le Maître d’Oeuvre s’engage à employer les moyens les plus adéquats à l’atteinte des objectifs du projet.Le Maître d’Ouvrage et le Maître d’Oeuvre négocient les méthodesà employer.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Obligation de moyens vs de résultats
Mais dans tous les cas :le Maître d’Ouvrage s’engage sur le besoin et la disponibilité des informationset le Maître d’Oeuvre s’engage sur les moyens à mettre en œuvre pour réaliser le développement
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C01 : Problématique des STR
Notions de Projet et de contratRecette et validationSpécificité des Systèmes Temps Réel
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
Le point clé d’un contrat est la recette.Il s’agit d ’acter le bon achèvement des travaux
Cela suppose de vérifier l’atteinte de tous les objectifs du projet :
La livraison du système dans son environnementLa bonne réalisation de toutes les fonctions du système (couverture fonctionnelle)Le respect des propriétés
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
Livraison du système et de son environnement :matériels (machines, écrans, disques,...),logiciels et données (OS, outils de développement, de test et de maintenance, logiciels du commerce, logiciels spécifiques,...).documents (contrats de maintenance, manuels d’installation, de maintenance, d’exploitation, de spécification, de conception, de codage, de qualité,...).Formations, transferts technologiques, ......
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
La bonne réalisation des les fonctions du système (couverture fonctionnelle) :
tableaux de bord (exploitation et maintenance).fonctionnalités.paramétrage.réglage.complétude fonctionnelle (traitement des exceptions).fonctions induites (arrêt brutal, reprises à froid et à chaud,...fonctionnements dégradés (blocage d’un processus, absence de données, remplissage d’une base de données,...)....
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
Le respect des propriétés :capacités (puissance des processeurs, tailles des bases de données et de la mémoire,...).flux (quantités des données en entrée, en sortie, en charge nominal,...).durées d’exécutions.continuité de service (365j/an, 24h24).taux de disponibilité logicielle et matériel.utilisabilité (propriétés ergonomiques).robustesse (tolérance aux pannes, comportements extrêmes,...).stabilité......
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
La recette est une opération contractuelle et purement formelle:
Possède une valeur juridique.Concerne le Maître d’Ouvrage et le Maître d’Oeuvre.Suppose en pré-requis que le système ait été validé.
La recette ne peut être déclarée qu ’après validation du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
La validation du système est la vérification de l’adéquation du système aux besoins exprimés dans le Cahier des Charges:
Vérification de la bonne réalisation des fonctions du système.
Les fonctions du système produisent-elles les résultats attendus...
Le respect des propriétés.... dans des conditions acceptables par l’utilisateur final ?
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
La validation requiert donc une référence reconnue par le Maître d’Ouvrage et le Maître d’Oeuvre qui identifie les fonctions et les propriétés du système à recetter.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
Le Cahier des Charges ne peut pas servir de référence:
Rédigé sous la seule et unique responsabilité du Maître d’Ouvrage.Le Maître d’Oeuvre n’est pas consulté.Document de négociation contractuel.Sa finalité n’est pas technique.Document à vocation «objectif», il ne précise que la finalité du système.Trop imprécis sur les fonctions et les propriétés à valider.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Recette & validation
Il est donc indispensable, dans un projet, que le Maître d’Ouvrage et Maître d’Oeuvre élaborent ensemble la référence de validation.Cette référence doit identifier précisément et exhaustivement:
l’ensemble des besoins que le système doit satisfaire.toutes les fonctions que le système doit remplir pour satisfaire ces besoins.toutes les propriétés que les fonctions du systèmes doivent vérifier.
Quelque soit la complexité d’un système, sa validation est une opération fortement coûteuse car très difficile!
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
«Dans la conversation courante, le mot complexité sert à écarter toute explication, toute compréhension. Quand vous dites «c’est complexe», cela veut dire «je suis incapable de vous expliquer»». E. Morin.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
Tout système est complexe dès lors :qu’il présente des difficultés à être décrit
Pb de représentation
que son comportement est difficile à décrirePb d’interprétation (imprévisibilité : anticipation, prédiction, simulation, …)
ou que son comportement est difficile à contrôlerPb de commandabilité
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
La complexité apparaît lorsqu’il s’agit d’intégrer des composantes techniques, environnementales et humaines.La notion de complexité est étroitement liée à celle de représentation cohérente, nécessaire à la production d’informations alimentant toute réflexion, décision ou action.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
La complexité est conçue comme une barrière s’opposant à la maîtrise du système.
Génie industriel: la complexité est liée à des difficultés de mise en oeuvre (conception, réalisation, exploitation, utilisation, évolutions,...).Génie logiciel: la complexité se situe au niveau des ruptures entre l’expression des besoins, l’élaboration des solutions et la réalisation des applications.Génie cognitif: la complexité réside dans la difficulté à percevoir les processus cognitifs et les schémas de représentation des objets manipulés.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
Le point clé est la capacité à décrire le système pour produire l’information nécessaire à l’engagement d’activités concourant à la réalisation du système:
Il n’est pas possible de réduire la complexité d’un système complexe, car dans le cas contraire, le système n’est pas (plus) complexe.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
La maîtrise de la complexité consiste à identifier des sous-systèmes «autonomes» et les relations qu’ils entretiennent avec leur environnement (dont les autres sous-systèmes).
La décomposition ainsi opérée s’arrête dès lors que des sous-systèmes «non-complexes» ont été identifiés.La construction du système est une opération d’assemblage de systèmes «non-complexe».
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Complexité de la validation
Mais, en présence d’un système réellement complexe, la décomposition est soit "impossible", soit conduit à l’identification de sous-systèmes difficiles à appréhender.Dans tous les cas, un système complexe est un système difficile à percevoir, donc à modéliser, et donc à valider !
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C01 : Problématique des STR
Notions de Projet et de contratRecette et validationSpécificité des Systèmes Temps Réel
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Cas des Systèmes Temps réel
Le concept de système temps réel a été introduit autour des années 70:
peu de mémoire.processeurs peu puissants.fréquence faible.
La conception de systèmes embarqués pose des problèmes techniquement difficiles à résoudre.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Définition intuitive des systèmes temps réel
Un système est temps réel si, en réaction à un stimuli d’entrée, la réponse qu’il élabore est produite en un temps borné, suffisamment faible par rapport à la dynamique de son exo-système (i.e. la capacité de son environnement à prendre en compte sa réponse).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Spécificités des Systèmes Temps Réel
Réactivité.Aptitude à prendre en compte un changement de l’exo-système (stimuli).
Evénement.Aptitude à interpréter (i.e. donner un sens) un changement dans l’exo-système pour produire une réponse adéquate (i.e. inscrite dans la finalité du système et de son exo-système).
Garantie de temps de réponse.Aptitude à répondre en un temps borné quelque soit l’état interne du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Propriétés des Systèmes Temps Réel
Ils se caractérisent par une capacité à prendre en compte le changement, ce qui suppose de les doter de moyens de communication pour échanger des informations :
avec son exo-système, qui doit être informé de la prise en compte de ses stimuli et de la disponibilité des réponses.en interne, entre ses différents processus, pour garantir les temps de réponse.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Propriétés des Systèmes Temps Réel
La problématique de la spécification et de la conception d’un système temps réel peut se résumer à celui de la gestion de ses ressources internes (fonctions, mémoires, et processeurs) et à leur synchronisation.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
La perception des systèmes temps réel
Dimension Statique : Composants et structuresTout ce qui est invariant dans le temps, sa structure (architectures, dictionnaires des données,...).Le quoi ou le ça du système : Besoins, Code, Fonctions, Organes,...
Dimension Dynamique : État et ÉvénementsTout ce qui gère le changement d’état, l’événementiel (le contrôle, le comportement,...).Le comment du système : Contrôle (ordonnancement) des tâches, Optimisation des ressources, Comportement aux limites,...
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
La validation des systèmes temps réels
Statique : Composants et StructuresIl s’agit de vérifier l’existence et l’utilisabilité de ses composants.Existence des fonctions et validité de leurs résultats.Approche exhaustive du type «check-list».
Dynamique : Etats et EvénémentsIl s’agit de vérifier son comportement et ses propriétés temporels.Temps de réponse et datation des résultats.Approche du type «taux de couverture».
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Problématique fondamentale des Systèmes Temps réel
La combinatoire introduite par le temps dans la relation entre le système et son exo système étant généralement si importante, la validation complète du système temps réel est généralement impossible par manque de méthode, de temps et de moyens !
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels
Problématique fondamentale des Systèmes Temps réel
La validation d’un système temps réel est une opération d’une grande complexité, fait de l’extraordinaire combinatoire des relations entre le système et son exo systèmeLa validation des systèmes temps réel est un problème d’une très grande complexité qui s’exprime en premier lieu en terme méthodologique.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 :Notion de Spécification
Projet, activités, Méthodes
Cycles de Vie du Logiciel
Notion de spécification
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Enjeux d ’un projet
Un projet est à la croisée de 2 intérêts en opposition radicale:
Ceux du Maître d’Ouvrage : le meilleur système possible pour un coût minimal.Ceux du Maître d’Oeuvre : une marge la plus grande possible.
Mais ils ont un intérêt commun: la réussite du projet.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Enjeux d ’un projet
Un compromis est donc indispensable:Définir le bon produit…Celui qui satisfait aux besoins réels du Maître d’Ouvrage, ni plus, ni moins.au juste coût.Celui nécessaire et suffisant au développement des fonctions répondant aux besoins réels.
C’est un problème de qualité.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Enjeux d ’un projet
Définition de la qualité (Norme NF X 50-109):La qualité d’un produit (ou d’un service) est son aptitude à satisfaire les besoins des utilisateurs.L’assurance et le contrôle de la qualité sont des instruments visant à s’assurer de l’obtention de la qualité d’un produit ou d’un service.
Une qualité non-maîtrisée engendre un sur-coût considérable et une insatisfaction.
Elle se traduit par une perte de confiance.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Enjeux d ’un projet
Il est donc indispensable de maîtriser la qualité d’un produit dès sa naissance.
En d’autres termes, tout temps passé sur dans un projet doit se traduire par un progrès dans la compréhension et la réalisation du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Enjeux d’un projet
Le problème est donc de:faire bien...faire le bon produit, le QUOI du projet.et de bien faire.bien faire le produit, le COMMENT du projet.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 7
Notion d’Activité (tâche)
La réalisation d’un produit résulte du déroulement d’un ensemble d’activités ou tâches:
Un objectif…une définition, une fonction, un document, un réglage,...à atteindre dans un budget exprimé en Homme.Jour…des moyens humains, organisationnels, techniques et logistiques,...dans un délai (une date de livraison).revue, validation, recette,...
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
Notion d’Activité (tâche)
L’obtention d’un produit de qualité nécessite l’identification des bonnes activités (tâches) et la vérification de l’atteinte de l’objectif dans le délai imparti.
Cette problématique relève de la méthode.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
Notion de Méthode
Définitions:Ensemble de démarches que suit l’esprit pour découvrir et démontrer.Ensemble de démarches raisonnées, suivies pour parvenir à un but.Règles, principes sur lesquels reposent l’enseignement, la pratique d’un art, d’une technique.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
Notion de Méthode
Cadre conceptuel d’expression d’une démarche de résolution de problème.
Identifie des concepts et les met en relation les uns avec les autres.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
Notion de Méthode
La méthode est une aide à la stratégie :Identifie des buts à atteindre pour satisfaire un objectif global.Intègre des segments programmés (procédures) produisant des résultats partiels nécessaires à la suite des travauxMais suppose la découverte et l’innovation.
La méthode permet la définition des activités (objectifs, moyens, délais).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
Notion de Méthodologie
«Discours de la méthode pour bien conduire sa raison et chercher la vérité dans les sciences», Descartes, 1637:
Methodus (latin, 1537): Marche, ensemble de démarche que suit l’esprit pour découvrir et démontrer la vérité.logos (grec): étude.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Notion de Méthodologie
La méthodologie est donc l’épistémologie de la méthode
Étude critique des méthodes, destinée à déterminer leur origine logique, leur valeur et leur portée.du grec epistêmê qui signifie «science»
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 14
Notion de Méthodologie
La méthodologie est donc l’instrument de la maîtrise de la complexité.
Pour le Maître d’Ouvrage, c’est la condition de l’obtention du bon produit (le quoi).Pour le Maître d’Oeuvre, c’est la condition de la bonne réalisation du produit (le comment).
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 :Notion de Spécification
Projet, activités, Méthodes
Cycles de Vie du Logiciel
Notion de spécification
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
Cycles de Vie du Logiciel
Le processus de développement classe les activités en 5 grands types:
SpécificationConceptionRéalisationValidationExploitation
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
Cycles de Vie du Logiciel
Spécification.Définition du système, description détaillée du comportement externe du système.Conception.Définitions des fonctions matérielles et logicielles du système.Réalisation.Construction des fonctions matérielles et logicielles du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Cycles de Vie du Logiciel
Validation.Évaluation des propriétés des fonctions matérielles et logicielles du système.Exploitation.Mise en œuvre du système dans son environnement.
Ces 5 classes d’activités (ou tâches) ne s’enchaînent jamais de manière linéaires !
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
CdV en Cascade
Le modèle de Boehm (1976) conçoit le développement d’un système comme une cascade de phases :
Spécification
Conception
Réalisation
Définitiondes Besoins
Validation
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 20
Généralisation : CdV en V
SystèmeBesoins
Définition des BesoinsExploitationMaintenance
Spécification
Conception Générale
Conception Détaillée
Codage
Test Unitaire
Intégration
Validation (Recette)
Des
ign
Test
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 :Notion de Spécification
Projet, activités, Méthodes
Cycles de Vie du Logiciel
Notion de spécification
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Définition de la Spécification
Définition du système dans son environnement, de sa mission (i.e. sa finalité), de ses processus et de ses propriétés.
« Il s’agit de définir le QUOI du système indépendamment de la technologie. »
Définition du problème à résoudre.Vision externe (boite noire) et globale.Processus de raffinement successif ou descendant (du général au particulier).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
Notion de Spécification
La spécification vise à produire le document qui servira de référence à la validation du système:
Entrée de l’activité de conception.Entrée de toutes les activités de vérification (tests unitaires, tests d’intégration, validation et recette).
L’activité de spécification est un processus d’acquisition et de structuration de connaissances, c ’est-à-dire un processus de modélisation.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Les 7 pièges de la spécification
1°) Incohérence : Connaissances contradictoires ou incompatibles.
2°) Incomplétude : Absence de connaissance opératoire sur le système ou connaissances implicites.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
Les 7 pièges de la spécification
3°) Ambiguïté : Connaissance donnant naissance à plusieurs interprétations.
4°) Absence de clarté : Connaissances difficiles à interpréter.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Les 7 pièges de la spécification
5°) Sur-spécification : Connaissances relevant de la conception (i.e. du comment et non du quoi).6°) Bruit : Connaissances inopérantes, inutiles ni à la modélisation, ni à sa compréhension.7°) Redondance : Connaissances dupliquées en de multiples exemplaires.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Doc. de Spécification = Référence
Quelque soit le modèle de CDV retenu, le dossier de spécification est l’unique document de référence.
La validation consiste à savoir, pour tout élément identifié dans la spécification, s’il a été correctement réalisé ou non.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 (partie 2):Notion de Spécification
Cycles de Vie en V
Cycle de vie en Spirale
Spécification et Conception
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
CdV en VSystèmeBesoins
Définition des BesoinsExploitation
Maintenance
Spécification
Conception Générale
Conception Détaillée
Codage
Test Unitaire
Intégration
Validation (Recette)
Des
ign
Test
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
CdV en V
Spécification
Conception Générale
Conception Détaillée
Codage
Test Unitaire
Intégration
Validation (Recette)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
CdV en V : Définition des besoins
Rédaction du CdCObjectifs, services fonctionnels, contraintes, recette
Phasage du projetMaquettes, prototypes, industrialisation, déploiement, ...
Définition de l ’organisation du projet coté ClientTypage et désignation des intervenantsusers, experts, clients, propriétaires, …
Définition des méthodologies généralesDe développement : spécification, conception, testDe gestion du projet et d ’AQ et de CQ
Planification globale de l ’étape de spécification
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
CdV en V : Spécifications
Définition du système (modélisation fonctionnelle)Données, Fonctions et Contrôle
Définition des besoins en méthodes et outils de développement
AGL, langages, outils de dév. et de test, moteurs, …Définition de la stratégie de validation du système
Logique d’intégration, de validation (test) et de recetteDéfinition de l’organisation du projet coté fournisseur (construire l ’équipe)Planification de la phase de conceptionMise en place du dispositif d’AQ et de CQ
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
CdV en V : Conception Générale
Architectures fonctionnelle, organique et logicielle du systèmeSpécification des environnements de développement et de testChoix des techniques et outils de développement et de testDéfinition de stratégie de testPlanification de la réalisation (conception détaillée, codage, T.U., Intégration)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 7
CdV en V : Conception Détaillée
Spécification des fonctions par rapport aux techniques et outils de développement et de testSpécification des pièces de code, de données et de paramètresSpécification des jeux de testsDéfinition et mise en place des plate-formes de développement, d ’intégration et d ’exécutionDéfinition des outils d ’analyse du système (gestion des défauts et des corrections)Planification du codage et des tests unitaires
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
CdV en V : Codage
Réalisation des pièces de code, de données et de paramètresAssemblage des pièces de code, de données et de paramètres en fonctionsRéalisation des outils d ’analyse du système (gestion des défauts et des corrections)Réalisation des outils de productivité (déboggeursdédiés, outils de visualisation)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
CdV en V : Tests Unitaires
Vérification des propriétés externes des fonctions informatiquesLivraison des pièces de code, données et paramètres en AGL (versionnement)Recette des pièces livrées (code, données et paramètres)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
CdV en V : Intégration
Mise en place de l a plate forme d ’intégration et d ’exécutionAssemblage des pièces en modules (génération d ’exécutables)Exécution des tests de non-régressionRecette (au sens AGL) des modules
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
CdV en V : Validation
Vérification des propriétés fonctionnelles du systèmeQualification du système, soit sur plate-forme, soit sur site (exploitation)Exécution de la procédure de recette (état des lieux, plan de mise à niveau)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
CdV en V : Exploitation/Maintenance
Exploitation du système sur siteSuivit des défautsDéfinition du contour fonctionnel de la prochaine version
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Le CdV en V généralise et étend le CdV en cascade
Ingénierie des Besoins SystèmeBesoins
ExploitationMaintenance
Codage
Test Unitaire
Intégration
Validation (Recette)
Définition des Besoins
Spécification
Conception Générale
Conception DétailléeDes
ign
Test
Ingénierie Informatique
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 :Notion de Spécification
Cycles de Vie en V
Cycle de vie en Spirale
Spécification et Conception
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
CdV en Spirale (Boehm, 1988)Analyse des Risques (re)Planification
DéveloppementRevues
Etudes de faisabilitéÉtude des risquesObjectifs/PérimètresRéduction des Risques
Plannings de développement,de revue
ModèlesBilans de fin de projetsLancement de projets
Logique de maîtrise des risques
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
CdV en Spirale (vue déployée)
Périmètre
SpécificationConception
RéalisationIntégration
Quadrant du Développement
Spécification
Conception Générale
Conception Détaillée
Codage
Test Unitaire
Intégration
Validation (Recette)Spécification
Conception Générale
Conception Détaillée
Codage
Test Unitaire
Intégration
Validation (Recette)
ValidationRecette
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
CdV en Spirale
Version 1 Version 2 Version 3
Composant C2
Composant C1
Fonction Ff
Fonction F2
Fonction F1
Composant Cc
...
...
t
Périmètre
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C02 :Notion de Spécification
Cycles de Vie en V
Cycle de vie en Spirale
Spécification et Conception
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Définition de la Spécification
Définition du système dans son environnement, de sa mission (i.e. sa finalité), de ses processus et de ses propriétés.
« Il s’agit de définir le QUOI du système indépendamment de la technologie. »
Définition du problème à résoudre.Vision externe (boite noire) et globale.Processus de raffinement successif ou descendant (du général au particulier).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 20
Définition de la Conception :
Description des processus du système, tout en vérifiant les propriétés attendues.
« Il s’agit de définir le COMMENT du système par rapport à une technologie. »
Définition de la méthode de résolution d’une partie du problème.Vision interne (boite blanche) et locale.Processus ascendant (du particulier au général).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Définition de la Conception :
L’activité de conception prend en entrée le document de spécification, et produit un document de conception.
Ce dernier document servira de support à la définition des activités de réalisation.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Remarque importante
Lorsque le système est complexe, le découplage des processus de spécification et de conception n’est pas évident ni même souhaitable : Seule la dichotomie documentaire est fondamentale, voir vitale.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
Remarque importante
En pratique, l ’important est de bien distinguer l’activité de production d ’un objet de l’objet produit :
La conception est un processus : activité de modélisation, de transformation de modèles.La spécification est un objet : modèle produit, porté par un document.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Remarque importante
La Conception est un processus qui, en fonction d ’un ensemble de techniques préalablement choisies, transforme une spécification externe en une spécification interne.
Spécification externe
Techniques Conception
Spécification interne
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
Remarque importanteSpécification N1
Le développement doit alors être vu comme un enchaînement de phase de conception et de validation de spécifications
Tech. N2 Conception N2
Spécification N2
Conception N3Tech. N3
Tech. Nn Conception Nn
Spécification Nn
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Application au CdV en VCahier des Charges Système
Validation du ServiceConception Générale
Spécification générale Dossier de test fonctionnel
Spécifications Détaillées
Conception Détaillée
Dossier de conception Technique
Conception Technique
Pièces de Codeet de Paramètre
Codage
Dossier de non-régression
Validation fonctionnelle
Intégration
Dossier de Tests Unitaires
Tests Unitaires
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Doc. de Spécification = Référence
Quelque soit le modèle de CDV retenu, le dossier de spécification est l’unique document de référence.
La validation consiste à savoir, pour tout élément identifié dans la spécification, s’il a été correctement réalisé ou non.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
Doc. de Spécification = Référence
Cahier des Charges
Offre Technique
Contrat
Analyse Externe
SPAG, SPEX, COOPSpécifications
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
Doc. de Spéc. ≡ Référence
En liant tout élément de spécification aux productions du projet, la traçabilité des connaissances est l’outil de base de la validation.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C03 (partie 1) :Introduction à SA-RT
Composants de SA-RT
Composants de SA-RT
Dans SA-RT, la définition d’un système est la donnée de 2 descriptions:
La description des fonctions du système et du contrôle duflux informationnel.La description de l’architecture matérielle du système.
Composants de SA-RT
Les spécifications du système sont constituées:Du modèle des besoins fonctionnels (Données, Fonctions, Contrôle)Du modèle d’architecture (Canaux, Modules, Communication)
Notion de système dans SA-RT
Système ::= Objet structuré capable de :Lire des données en entréeTransformer les valeurs des variables d’entrée en valeur de variable de sortieEcrire des données en sortie (résultats)Présenter les données (IHM)Auto-diagnostic (exploitation & maintenance)
Notion de système dans SA-RT
Le cœur de la structure est composé de:
Structure de donnéesFonctionsContrôle de l’exécution des fonctions
Notion de Spécification dans SA-RT
La spécification décrit le système est terme des besoins fonctionnels que l’exploitation du système doit satisfaire
Composants du Modèle des Besoins Fonctionnels
Composants du Modèle des Besoins Fonctionnels
DCD: Définit le contexte d’interprétation dumodèle des besoins.DFD: Décrit la (dé)composition fonctionnelledu système.PSPEC: Décrit le traitement des données.
Composants du Modèle des Besoins Fonctionnels
DCC: Définit le contexte d’interprétation descontrôles.DFC: Décrit les flots de contrôle.CSPEC: Décrit le traitement des flots de contrôle.
Composants du Modèle des Besoins Fonctionnels
DICTIONNAIRE des DONNEES.TABLE de TEMPS de REPONSE.
Composants du Modèle d’Architecture
Composants du Modèle d’Architecture
DCA: Définit le contexte d’interprétation du modèle d’architecture.DFA: Identifie les Modules (physiques) d’Architecture et les informations qui circulententre eux.SMA: Décrit les Modules d’Architecture (i.e. regroupements fonctionnels).
Composants du Modèle d’Architecture
DIA: Identifie les ports d’E/S sur lesquels les données transitent.SIA: Décrit les propriétés physiques des ports d’E/S.DICTIONNAIRE des données d’ARCHITECTURE.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C03 (partie 2) :Introduction à SA-RT (suite)
Origines de SA-RTPrincipes de base de SA-RT
Introduction à la méthode SA-RT
La méthode SA-RT est une méthode de spécification de systèmes informatiques relevant du domaine du temps réel
Systèmes embarqués (avion, véhicules, etc)Systèmes d’assistance au pilotageSystèmes de commande (asservissement, régulation, etc)Systèmes contraint temporellement
SA-RT : Structured Analysis for Real-Time systems
Divers variantes sont décrites dans la littérature (cf. J.P. Calvez «Spécification et Conception des systèmes: une méthodologie», ed. Masson, 1991):
RTSA Real-Time Structured Analysis.SDTRS pour Structured Design for Real-Time Systems.
Origines de SA-RT
SA-RT est née de 2 courants de travaux indépendant mais contemporains:
Ward etMellor (1985)Hatley et Pirbhai (1987) dans le cadre d’un grand projet d’avionique.
Origines de SA-RT : fin 70
Le point de départ repose sur une analyse relevant du Génie Logiciel:
les projets d’informatique temps réel se terminent, sauf cas exceptionnels, hors délais et hors budget.La cause principale se trouve au niveau d’un manque de connaissance sur le système à construire (manques au niveau des spécifications du système).
Spécificités des systèmes TR
Connaissances nécessaires au contrôle de l’exécution des processus de traitement des informations du fait de l’existence :
Conditions d’exécutionOrdonnancement des événements
Processus asynchronesProcessus concurrents
Modes opératoires des systèmes
Références de SA-RT
SA : Structured Analysis de Demarco, 1979.Notion de Diagramme de Flots de Données (DFD).SD : Structured Design de Yourdon et Constantine.Décomposition modulaire des systèmes séquentiels décrit par des DFD.
SA et SD ne sont pas adaptées aux systèmes temps réel
Méthodes purement fonctionnelle, centrées sur les données et les fonctions (uniquement).Pas d’outils de description des contraintes d’interaction et de gestion des ressources.
Dans SA et dans SD, le contrôleest implicite
Les transformations de données s’exécutent à l’arrivée des données et les sorties sontdisponibles immédiatement («Data Triggered Concept» ou déclenchement par lesdonnées).Comment décrire le contrôle de l’exécution des processus ?
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C03 (partie 2) :Introduction à SA-RT (suite)
Origines de SA-RTPrincipes de base de SA-RT
Principes de base de SA-RT
SA-RT a donc été conçue pour palier à l’incapacité de la méthode SA à spécifier les systèmes réactifs temporellement contraint.Ajout d’outils de description de la dynamique des systèmes
Expression du contrôle de l’exécution des processus de transformation de données
Pour SA-RT, un système TR est un système à 3 dimensions
Expression des connaissances relatives à trois dimensions :
Fonctionnelle: Défini les fonctions et les variables du systèmeInformationnelle : Défini les types de données manipulées par les fonctionsDynamique: Défini le contrôle du flux des données et l’activation des fonctions.
Spécifier = décrire et organiser des connaissances en 3 D
SA-RT offre un point de vue tri-dimensionel sur le système à construire ou à maintenir.
Point clef de SA-RT
Séparation des connaissances selon les 3 axes (fonctionnel, informationel et dynamique)
En particulier, SA-RT sépare explicitement les connaissance de contrôle et celle relatives aux fonctions
Objectif de SA-RT
L’objectif de SA-RT est produire un modèle des besoins permettant la conception des systèmes temps réel:
Conformité aux besoins réels de l’Utilisateur.Communicabilité (i.e. interprétables sans erreurs).Faisabilité.Modifiabilité.Validabilité.Complétude.Cohérence.
SA-RT est donc une méthode de modélisation …
Un guide à l’acquisition des connaissances sur le besoin :
Langage simple combinant diagrammes, tables et textesAbstraction des données et des processus.Décomposition hiérarchisée du système.Encapsulation de l’information.
La technique de base pour l’expression des besoinsest l’entretien oral.
… globalement descendante …
La modélisation part de la description des propriétés du système (l’ensemble), à celles de ses composants (ses éléments).La modélisation est effectuée en 2 étapes :
Construction hiérarchisée du modèle du système(processus et données).Complétion du modèle par le besoin de contrôle.
… adaptée à la classe des systèmes temps réel …
Complexité.Description hiérarchisée des processus.
Simulation nécessaireDescription rigoureuse (non ambiguë) des processus.
Parallélisme dans les traitements de données.Explicitation de contrôle.
Contrôle et communication inter-processus.Description séparée des données, des fonctions et du contrôle.
… dans un CdV en spirale
Le CdV en spirale permet de maîtriser les risques liés aux problèmes:
d’optimisation des ressources.de dépendance des modules
Interface utilisateurAcquisition des entrées, émission des sortiesMaintenance...
de simulation et de prototypage.
SA-RT en 4 points clés
1° Clarification par la séparation des connaissances de nature différentes
Modèle Fonctionnel (modèle des processus de traitement des données).Modèle Dynamique (modèle des processus de traitement du contrôle).Modèle des données.Modèle d’architecture.
SA-RT en 4 points clés
2° Compréhensibilité par la combinaison de graphiques et de textes.3° Hiérarchisation de la description
Interprétation indépendante du contexte.
4° Contrôle de la cohérence par des contraintes de décomposition entre les niveaux d’abstraction.
Mais SA-RT n’est pas
une garantie formelle d’un développement parfaitune technique de gestion de projetune méthode d’implémentation du système
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C04 : Modèle fonctionnel des besoins
Démarche de modélisationNotion de DFDSystème syntaxique de SA-RTCohérence des DFD
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Outils conceptuels de SA-RT
Diagrammes de flots de données (DFD).Décrit un traitement sous la forme d’un réseau de processus s’échangeant des données.Identifie les entrées et les sorties d’un processus (interfaces).Décomposition hiérarchique des processus (encapsulation).
Dictionnaire des données.Définit les interfaces E/S des processus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Outils conceptuels de SA-RT
Dictionnaire des données.Définit les interfaces E/S des processus.
Langage de spécification des propriétés externes des processus.
Description des traitements opérés sur les données, indépendamment de la technique d’implémentation retenue.Langage naturel réifié, structuré et graphique.Tables et arbres de décision.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Démarche de modélisation dans SA-RT
Modélisation fonctionnelle globalement descendante (SA de De Marco) :
Le système perçu depuis son environnement comme une entité à part entière.Le système se compose d’un nombre limité (5 à 7) de modules dont les interfaces sont clairement spécifiés.Chaque module est composé d’un nombre limité (5 à 7) de modules.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Objectif : compréhension progressive du système
Modélisation par raffinement successifs (du général à l’élément).L’interprétation des connaissances s’effectue par étapes, localement.Une étape d’analyse introduit un nombre limité de connaissances nouvelles.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Modèle purement logique (abstrait)
Modèle informationnel et non physique.Un logiciel n’est traversé que par de l’information !
Ensemble structuré de connaissances sur le système.
Connaissances décrites sous forme de diagrammes complétés ou précisés par des textes écrit en langage quasi-naturel.
Représentation du système, réputée nécessaire et suffisante pour répondre aux questions de conception.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 7
Modèle fonctionnel purement abstrait et hiérarchisé
Le diagramme de plus haut niveau positionne le système dans son environnement : il synthétise ou résume l’entièreté du système.Les connaissances sur le système sont introduites progressivement, par couches successives.
Un diagramme n’expose qu’un nombre limité de connaissances.Un diagramme s’interprète localement dans son contexte.Le contexte d’un diagramme est défini par son diagramme père.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
Démarche de modélisation dans SA-RT
Les connaissances sont exprimées dans le langage du domaine d’application.
Le langage utilisé est une réification de celui du domaine d’application.
Le modèle est élaboré pour répondre à la question : «le système est construit pour transformer ces entrées en ces sorties»
Les entrées et les sorties appartiennent à l’environnement.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
RemarqueS
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
RemarqueS
I1
SI2 O1
I3
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
RemarqueS
S O1
I1
I2
I3
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
RemarqueS
S O1
Environnement
Environnement
I1
I2
I3
O1
I1
I2
I3
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
RemarqueS
S O1
Environnement
I1
I2
I3
O1
Environnement
I1
I2
I3
O1S
I1
I2
I3
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C04 : Modèle fonctionnel des besoins
Démarche de modélisationNotion de DFDSystème syntaxique de SA-RTCohérence des DFD
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
Diagrammes de flots de données (DFD)
Un DFD permet de décrire:Les données objet d’une transformation : flots de donnéesLa transformation : Processus
Un processus transforme un flot de données en changeant:
Sa structure (format)Ses valeursSa destination
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
Diagrammes de flots de données (DFD)
Un DFD est un réseau dont :les noeuds sont des processus de transformationles arcs sont des flots de données.
Un DFD définit les fonctions (ou besoins fonctionnels) d’un système.
Les besoins sont décrit en termes de composants fonctionnels.
Un système décrit par un DFD peut être automatisé, manuel ou les deux à la fois.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
Le DFD est le socle de l’approche descendante de SA-RT
ModularitéUn processus se compose de sous-processus.Un flot de données se compose de sous-flots de données.
Masquage de connaissancesMaîtrise de la complexité quantitative.Des centaines de processus ne peuvent être considérés simultanément.
AbstractionUn DFD définit un niveau d’abstraction d’un système.
Abstraire ≡ IsolerLe degré de connaissance du système augmente de niveau en niveau.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Structure du modèle fonctionnel des Besoins
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Diagrammes de flots de données (DFD)
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C04 : Modèle fonctionnel des besoins
Démarche de modélisationNotion de DFDSystème syntaxique de SA-RTCohérence des DFD
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Un DFD est un graphique composé à partir de 4 concepts
Flots de données ::= Canal d’information transportant les données.Processus ::= Transformateurs d’informations.Stockage de données (ou réservoir)::= Organes abstrait de mémorisation des données.
Un réservoir est un flot de données particulier.
Terminaison (source ou puit) ::= Générateurs ou consommateur externes des données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Ces concepts sont représentés par 4 symboles (ou formes)Terminaison Source
Flot de données
Réservoirs
Terminaison puit
Processus
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
Définition sémantique des flots de données
Canal d’information (une sorte de «pipe-line») véhiculant des données ou un assemblage de donnéesMet à disposition d’un processus l’information dont il a besoin pour réaliser la transformationNe porte pas d’événement
n’indique jamais un changement d’état
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Définition syntaxique des flots de données
Notation: un flot de donnée est une flèche étiquetée.
Une étiquette ne peut comporter que des noms et des adjectifs.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
Définition syntaxique des flots de données
«A» circule d’un processus gauche à un processus droite.
«A» représente soit une donnée soit un assemblage de données.
«A» est composé de «B » et «C».
«A» n’a donc pas d’autres composants.
Tout «A» circule sur la branche inférieure.
«B» est «extrait» de A pour être REPRODUIT sur la branche supérieure.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Définition syntaxique des flots de données
«A» est reproduit sur les 2 branches.
«A» circule dans les deux sens de l’arc.
Le flot porte simultanément mais séparément «X», «Y», et «Z».
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Syntaxe des processus
Un processus est noté sous la forme d’un cercle étiqueté et numéroté.L’étiquette d’un processus doit contenir:
Un verbe d’action à l’infinitif signifiant la nature de la transformation des données.
Obtenir Paiement1
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
Sémantique des réservoirs
Il existe 2 types de réservoirs:Réservoirs à données consommables (accès aux données en lecture destructrice).Réservoirs à données permanentes (accès aux données en lecture non destructrice).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
Sémantique des réservoirs
Les réservoirs sont utiles à la désynchronisation de la relation Client/Fournisseur de données :
accéder plusieurs fois à la même donnéeexploiter les informations dans un ordre différent de celui de production
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 30
Syntaxe des Réservoirs
Un réservoir est noté par deux lignes parallèles étiquetées
L’étiquette doit comporter le nom du flot de données qu’il mémorise.L’étiquette du flot de données peut être omis si le réservoir contient toute l’information portée par le flot.
T°Réacteur
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 31
Recommandation concernant les réservoirs
Un réservoir apparaît au niveau le plus élevé ou il est situé entre 2 processus.Un réservoir ne peut apparaître que sur un seul DFD.Si ses entrées ou ses sorties sont nécessaires dans plusieurs diagrammes, elles sont représentées comme des flots de données habituels.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 32
Exemple de DFD
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 33
Le Diagramme de Contexte des Données (DCD)
Le DCD défini la frontière entre le système et son environnement
Le DCD est le DFD père de tous les DFD (DFD de niveau 0)Le système est le processus N°0Le DCD explicite les relations du système avec son environnement.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 34
Le Diagramme de Contexte des Données (DCD)
Le DCD décrit :Le système en un processus unique (N°0)L’environnement sous la forme de terminaisonsLes relations entre le système et son environnement sous la forme de flots de données
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 35
Syntaxe des Terminaisons
Une terminaison est notée sous la forme d’un rectangle ou d’un carré étiqueté.
Une terminaison indique la limite du système
Client
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 36
Exemple de DCD
0*Développerun Système
Développeurs
AGLClient
Composants MétiersSystème Validé& Documenté
Besoins Système DocumentaireExpérience
Questions au Client
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réel
C04 : Modèle fonctionnel des besoins
Démarche de modélisationNotion de DFDSystème syntaxique de SA-RTCohérence des DFD
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 38
Règles de cohérence des DFD
Un processus père possède les mêmes flots de données entrant et sortant que le DFD qui le décrit.Il est possible de décomposer un flot de données entre les 2 niveaux.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C05 : Processus atomiques
Spécification des processus atomiquesStyles de PspecSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Notion de processus atomique
Les DFD décomposent le système en un réseau de processus.Tout processus est fonctionnellement spécifié par :
Ses interfaces, les flots de données entrant et sortantLa transformation opérée sur les flots de données par la décomposition du processus en sous-processus
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Notion de processus atomique
La décomposition fonctionnelle s’arrête aux processus « atomiques » ou terminaux :
Non-décomposé car décomposition inutile
La transformation opérée par un processus atomique doit être décrite par un autre moyen que le DFD.
PSpec, MiniSpec, Primitive ou Composant fonctionnel, Transformateur.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Notion de processus atomique
La PSpec est utilisée uniquement pour spécifier les processus atomiques
Plus bas niveau d’abstraction de la spécification.Ennonce les règles de transformation des données entrantes en données sortantes.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Notion de processus atomique
Une PSpec décrit les propriétés externes de la transformation
En aucun cas la manière dont la transformationdoit être codée
Une PSpec est une description localeElle ne considère que les flots entrant et sortant.La cohérence de chaque PSpec peut donc êtrelocalement vérifiée.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Rôle de la PSpec
Pour un processus atomique donné, Il faut choisir le style qui convient le mieux à une compréhension efficace (rapide et sans ambiguïté).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 7
Rôle de la PSpec
Il est important de noter qu’une PSpec nedoit introduire aucun redondance de spécification (sur-spécification):
Descriptions claires, non confuses.Description complète et cohérente, sans ambiguïté.Description concise (i.e. le nécessaire et suffisant).
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C05 : Processus atomiques
Spécification des processus atomiquesStyles de PSpecSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
Le style textuel
Processus décrit sous une forme procédurale, c-à-d par l’enchaînement d’opérations simplesde transformation de données.Une PSpec textuelle peut être exprimée en langage naturel (langage libre)
Fortement déconseillé (signe d’une décomposition douteuse)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
Le style textuel
Notion de «langage naturel structuré»Réification d’un jargon métierSymboles mathématiquesNotation algorithmiqueRigueur, lisibilité, sans ambiguïté
L’emploi d’un langage naturel structuré requiert :Des commentaires pour faciliter la compréhension.L’indentation pour mettre en évidence les blocs de traitements
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
Jargon métier
Vocabulaire limité, tiré ce celui du métier du clientObjets définit dans le dictionnaire des donnéesVerbes d’action et transitifsStructures grammaticales simplistes et limitées(Sujet- Verbe-Attribut).Termes techniques, spécifiques du domaine(attention à la polysémie).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
Symboles mathématiques
Pas besoins d’être définis∀, ∃, ∈, ⊃, …,=, <, >, ≥, ≤, ≠, …,∧, ∨, ⊕, ⇒, ⇔, …Notation des variables libres
« *Type » par exemple
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Notation algorithmique
SéquenceSpécifie l’ordre d’exécution des transformations.
ConcurrenceSpécifie l’absence d’ordre d’exécution destransformations
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 14
Notation algorithmique
Décision (alternative simple ou multiple)Spécifie la dépendance d’une transformation à l’état du système (i.e. les valeurs des données).Les alternatives peuvent être simples (Si.. Alors...) ou multiples (Selon la valeur de... Faire...).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
Notation algorithmique
RépétitionSpécifie une exécution itérative d’une transformation dans le but d’atteindre un état.Le nombre d’itération peut être connu a priori(Pour Tous les objets de tel type, Faire...) ou non (Tant que tel état n’est pas atteint, Faire...).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
Exemple de PSpec textuelle
Séquence:INTERET_DU <-- TAUX*DUREE*MONTANTSOLDE <-- SOLDE - INTERET_DURetourner RESTE <-- SOLDE
Remarque :Attention à l’égalitéRetourner RESTE = SOLDE
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
Exemple de PSpec textuelle
Alternative:SI ALTITUDE > ALTITUDE_DE_TRANSITIONALORS VITESSE <-- MACHSINON VITESSE <-- VITESSE_DE_L_AIR
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Exemple de PSpec textuelle
Répétition:POUR TOUT élément de AIDNAVS_SELECTIONNE
répéterCalculer distance entre POSITION de l’AVION et la POSITION de l’AIDNAVSauvegarder distances dans le TABLEAU_DE_DISTANCE_NAV dans l’ordre croissant des distances.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Exemple de style Equationnel
Processus décrit sous la forme d’équationsmathématiques.Style particulièrement efficace car précis, concis, et sans ambiguïté
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 20
Exemple de style Equationnel
Algorithme de Viterby :λ(ξk) ≜ -ln(xk+1xk) –ln(zkξk)Initialisation :
k = 0^x(x0) = x0, ^x(m) arbitraire, m ≠ x0;Γ(x0) = 0, Γ(m) = ∞, m ≠ x0;
Récursion :Do : ∀ ξk = (xk+1, xk), Γ(xk+1, xk) ≜ Γ(xk) + λ[ξk=(xk+1, xk)]Until Γ(xk+1) = min Γ(xk+1, xk) sur xk
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Le style Décisionnel
a55a41a33
a53a42a32
a52a41a31
a22
a52a41a33
a51a43a32
a55a43a31
a21
a12
a54a43a33
a51a42a32
a51a42a31a22
a53a42a33
a52a41a32
a51a41a31
a21
a11
V5V4V3V2V1
SortiesEntrées
Adaptés aux processusfortement combinatoires
les valeurs sorties dépendentde la combinaison des valeursdes entrées
Spécifie des fonctions dutype alternativePspec dite combinatoires
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Exemple de style équationel et décisionnel
2ABCosΦ
2ABSinΦ=A
2ABSinΦ
2ABCosΦ<A
0
A2-B2A2+B2-<0
YXBA
SortiesEntrées
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
style graphique
Schémas, diagrammes, dessins …Ne s’utilise que rarement seul, mais en support des autres styles.
Les graphiques aident à faire comprendre unespécification (communication).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Exemple de style graphique
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C05 : Processus atomiques
Spécification des processus atomiquesStyles de PSpecSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Intérêts du langage naturel structuré
Structure le discours de tous les acteurs du du projet
Enjeu stratégique pour le développement du système(analyse, conception, traçabilité des connaissances,maintenance, ...)
Partagé par tous les acteurs du projet, après formation au domaine.
Ecriture rapide et «naturelle» des spécifications.Spécifications validables par le Client
Descriptions concises et précisesFormatage automatique
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Inconvénients du langage naturel structuré
Les spécifications semblent formelles mais ne le sont pas
Pas de génération de codeNe pas aller trop loin dans la formalisation (attention au double codage)
Pas de gardes-fous permettant d’éviter de contraindre la conception
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
Interprétation du modèle des besoins
Le modèle fonctionnel des besoins est un réseau de processus atomiques
Les processus exécutent la transformation à l’arrivée des données d’entrée.La transformation est instantanée (pas de contrainte temporelle, processeurs infinimentrapide et doté d’une mémoire infinie).Le réseau des PSpec doit être cohérent et complet
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
Interprétation du modèle des besoins
Le modèle fonctionnel des besoins est un modèle purement abstrait.
Il n’est ni un modèle physique de conception, nide réalisationLes différents niveaux s’abstraction ne serventqu’à faciliter la description et donc l’analyse dusystème.Il est idéaliste au sens où les contraintestechniques viendront l’altéré.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 30
Paradoxe fondamental d’une spécification
Lisible et compréhensible pour être validable par le client
Le langage doit être du langage naturel du client, c-à-dpas formel, véhiculant de l’implicite, jouant sur la polysémie, etc
Précise et non-ambiguë pour permettre la conception
Le langage doit être formel, c-à-d ne tolérant ni l’impliciteni la polysémie...
Le spécifieur se trouve donc écartelé entre 2 types de contraintes tout à fait antagonistes !
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C06 : Modèle de contrôle
Rôle du modèle de contrôleDiagrammes de Flot de ContrôleReprésentation des processus de contrôleReprésentation du tempsSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Limites du modèle des fonctions
Le modèle fonctionnel décrit des processus et des flots de données
Spécification de fonctions et de types de donnéesSpécification des relations entre fonctions
Il ne décrit pas les modes de fonctionnement du système
Initialisation, arrêt brutal, reprise à chaud/froid, modes dégradés, etcComportement variant dans le temps
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Etat d’un processus
Actif: Etat= 1.Le processus transforme ses données au rythmede l’apparition des entrées (Déclenchement par les données).
Inactif: Etat = 0.La transformation portée par le processus n’estpas effectuée.Il est «temporairement effacé» du diagramme de flots de données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Le modèle de contrôle
SA-RT exploite la stratégie de séparation des connaissances de nature différente (données, fonctions et contrôle) pour maîtriser la complexité des systèmes à comportementévolutifs au cours du temps
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Idée de SA-RT
Décrire les modes de fonctionnement dans un modèle séparé du modèle fonctionnel : le modèle de contrôle
Contient les connaissance décrivant les états du système et les transitions d’états (événements)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Rôles du modèle de contrôle
Définir les modes opératoires du système et les changements de modes
Etat, Transitions, Evénéments
Décrire les conditions d’activation et d’inactivation des processus
Actions
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 7
Position du modèle de contrôle
Le modèle de contrôle complète et se calquesur le modèle fonctionnel :
Un flot de contrôle véhicule les changementsd’état des variablesUn processus de contrôle décrit les conditions d’activation/inactivation des processusfonctionnels et l’élaboration des flots de contrôle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
Position du modèle de contrôle
Le modèle de contrôle est l’esclave du modèlefonctionnel.
Le modèle de contrôle adapte le comportement du système en réponse aux stimulis externes et en fonction du contexte (disponibilité des ressources)Cette stratégie peut s’avérer inadéquate pour les systèmes fortement dirigés par les contrôles.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
Règle de gestion des états
Un processus est actif par défaut.Un processus est actif si son processus-pèreest actif et que la CSpec locale ne le désactivepas.Quand un processus est inactivé, tous sesprocessus fils sont désactivés.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C06 : Modèle de contrôle
Rôle du modèle de contrôleDiagrammes de Flot de ContrôleReprésentation des processus de contrôleReprésentation du tempsSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
Diagramme de Flots de Contrôle
Un Diagramme de Flot de Contrôle, DFC, estassocié au DFD de même niveau.Un DFC contient:
les processus et les stockages du Diagramme des Flots de Données.les flots de contrôle.les processus dédiés à la gestion de ces flots.les réservoirs des flots de contrôle.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
Syntaxe des DFC
Un flot de contrôle est une flèche étiquetéeen trait discontinu.Un processus de contrôle est un trait pleinépais, sans étiquette.Un réservoir de contrôle : idem réservoir de données.Un même diagramme peut recevoir le DFD et le DFC de même niveau
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Exemple de DFC
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 14
Concept de Flot de Contrôle
Un flot de contrôle véhicule les changementsd’état des variables de contrôle.
Notion de signal discret ou discrétiséLa valeur d’un flot de contrôle est toujoursaccessible.
OffOn
État de l’interrupteur
Exemple de l’interrupteur à 2 positions
t
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
Concept de Flot de Contrôle
Les variables de contrôle concernent les modes opératoires des processus:
Permettent d’exprimer les conditions d’(in)activation des processus fonctionnels(activateurs)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
Discrétisation spatiale d’un signal
x(t)
tS1
S2
S3
x(t)∈ℜ xd(t)
t0
+1
+2
+∞
Evt(Vc)
te1(t1, +1) e2(t2, +2)
e3(t3, +∞)e4(t4, +2)
e5(t5, +1)
xd(t)∈ℵ
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
Distinction flot de données vs flot de contrôle
Un signal discret est généralement à considérercomme un flot de contrôle, sauf lorsqu’il véhicule de l’information nécessaire à la transformation de données.
OK
KO
Flot de contrôle
OK
OK
Flot de données
Signal discret (ℵ)
Signal continu (ℜ)
Nature de l’information
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Conditions sur les données
Les flots de contrôle peuvent être exprimés comme des conditions sur les données
Spécifiés dans les PSPEC.Constituent le lien entre DFD et DFC.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Exemple de conditions sur les données
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 20
Spécification des processus de contrôle
Les processus de contrôle sont des machines discrètes
Représentés par des barresCes machines sont décrites à l’intérieur des Cspecs(spécification de contrôle)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Spécification des processus de contrôle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Spécification des processus de contrôle
Un processus de contrôle transforme les flotsde contrôle entrant en:
flot de contrôle sortant, nécessaires aux autres processus du modèle.activateurs de processus («prompts»).
Activent ou désactivent les processus fonctionnels.
Par convention, les activateurs ne sontpas représentés sur les DFC
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C06 : Modèle de contrôle
Rôle du modèle de contrôleDiagrammes de Flot de ContrôleReprésentation des processus de contrôleReprésentation du tempsSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Représentation des processus de contrôle
Les machines discrètes décrites dans les CSpecpeuvent être de 2 types:
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
Notion de machine combinatoire
Une machine est combinatoire ssi : Y = F(E)Y vecteur de sortieE vecteur d’entrée
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Notion de machine combinatoire
Une machine combinatoire est entièrement décrite par :
Table de décision décrivant la logiqued’élaboration des flots de contrôle de sortie.Table d’activation des processus décrivant les conditions d’activation des processus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Notion de Machine Séquentielle
Une machine est séquentielle ssi : Y = F(X, E), Xvecteur d’état de la machine
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
Notion de Machine Séquentielle
Une machine séquentielle est entièrement décrite par :
Machine à états finis décrivant la logiqued’élaboration des flots de contrôle de sortie.Table d’activation des processus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
Notion de Machine Séquentielle
Une machine à états finis est composée d’unemémoire et d’un séquenceur:
La mémoire contient l’état courant de la machine.Le séquenceur détermine le prochain état à mémoriser en fonction des événements courants.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 30
Notion de Machine Séquentielle
Une machine à état est décrite à partir des notions:
État / TransitionÉvénements / Action
Une machine à états finis peut prendre un et un seul état parmi un ensemble fini et dénombrable d’états possibles.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 31
Notion de Machine Séquentielle
2 types de machines à états finis :Machines de Mealy: l’action est attachée au transitions.Machines de Moore: l’action est attachée à l’état.
Ces 2 types de machines sont équivalentes.SA-RT préconise les machines de Mealy.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 32
Notion de Machine Séquentielle
Convention :Les actions sont supposées continuer leurs effetsjusqu’à ce qu’une transition soit franchie
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 33
Exemple de machine de Mealy
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 34
Exemple de CSpec Séquentielle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 35
Exemple de CSpec Séquentielle
Table d’activation des processus
0
0
0
1
Obtenir une Bonne Séclection
5
1
0
0
0
Distribuer le Produit
6
1Distribuer Produit
0Accepter Nouvelles Pièces
1Rendre Paiement
Rendre la Monaie
20
Processus
Accepter Sélection
Actions
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 36
Elaboration des Machines Séquentielles
La construction des machines séquentielles est uneopération complexe et délicate.Elle est facilitée par la spécialisation et la séparation des connaissances liées:
aux transitions d’états.aux actions.
Mais seule la simulation est à même de garantir la cohérence d’une machine à états finis complexe
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 37
Elaboration des Machines Séquentielles
La séparation de ces 2 types de connaissancespermet l’élaboration localisée:
D’une logique d’événement.La logique d’événement traduit les événements véhiculéspar les flots de contrôle entrant en événementsintervenant dans l’expression des transitions.D’une logique d’action.La logique d’action traduit les états en flots d’activationdes processus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 38
Exemple de machine séquentielle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 39
Forme tabulaire des machinesséquentielles
Les tables facilitent l’analyse de la complétude de la machine, donc la conception du code et des tests.
Nouvel Etat
ActionEvtEtatInitial
Table Etat-Transition
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 40
Forme tabulaire des machinesséquentielles
Evt2Evt1Etat
Nouvel Etat
Action
Matrice Etat-Evénements
Nouvel EtatEtat
ActionEvt
Matrice Etat-Nouvel Etat
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 41
Règles de conservation des flotsde contrôle
La cohérence dans les flots de contrôle estobtenue par application de 2 règles de conservation des flots de contrôle:
Un flot de contrôle non traité dans une CSpec doitse trouver au niveau inférieur.Un flot de contrôle ne peut pas entrer dans un processus atomique (i.e. décrit par une PSpec).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 42
Règles de conservation des flotsde contrôle
Pour éviter des incohérences dansl’expression de la dynamique (dans les CSpec), il est recommandé d’adopter et de mettre en oeuvre le principe suivant :
Un flot de contrôle entrant dans une CSpec nepeut pas apparaître au niveau inférieur.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 43
Exemple
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C06 : Modèle de contrôle
Rôle du modèle de contrôleDiagrammes de Flot de ContrôleReprésentation des processus de contrôleReprésentation du tempsSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 45
Prise en compte du temps
L’analyse des aspects temporels du système doit être engagée très tôt dans la phase de spécification pour percevoir au plus tôt le système comme un système dirigé par les événements.Cette analyse doit être permanente en phase de spécification, même si ces informations seront quoi qu’il en soit revues en phase de conception.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 46
Les aspects temporels concernent
Modalités d’acquisition et d’émission des données.
Propriétés des flots de données.Spécifiées dans le dictionnaire des données.
Contraintes de temps de réponse.Liées aux contraintes imposées par l’exo-système.Spécifiées dans la «Table des temps de Réponse».
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 47
Types de variables temporelles
Variable périodiquele nombre de réalisation d’une variable périodique sur une durée donnée est constant et équi-réparti
Variable apériodiquele nombre de réalisation d’une variable apériodique sur une durée donnée est constant mais avec une répartition aléatoire.
Variable événementiellele nombre de réalisation d’une variable apériodique sur une durée donnée est aléatoire.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 48
Table des temps de réponse
Précise la durée autorisée (généralement la durée maximale) entre l’émission d’un événement par l’exo-système à destination du système, et l’émission de la réponse de la part du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 49
Table des temps de réponse
Tous les flots de contrôle externes doivent être listés (cohérence et complétude), même si aucune contrainte temporelle n’est posée.
Temps de RéponseEvénementFC de sortieEvénementFC d’Entrée
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 50
Convention sur l’accès au temps
Une mesure du temps courant est accessible depuis tout processus du modèle des besoins
Tous les processeurs sont équipé d’une horlogeTous les langages proposent des primitives d’accès à l’horlogeInutile de le faire apparaître sous forme de flots de données ou de contrôleInutile de spécifier une horloge interne
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 51
2 mesures du temps : temps absolu
Une horloge pour mesurer le temps absoluNombre de secondes écoulé depuis une date prise pour référence universelle (le 1ier janvier 1970 sous Unix).Fonction délivrant généralement l’heure GMT (Greenwich Meridian Time).Ex: Tous les jours à 5h00, établir le bilan matière du processus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 52
2 mesures du temps : temps relatif
Un chronomètre pour mesurer le temps écoulé depuis un événement
Nombre de secondes entre la date courante et la date de l’événement.Fonction calculant une différence entre le nombre de secondes correspondant à la date courante et celui correspondant à la date de l’événement.Ex: Si aucun message n’est reçu au bout de 10 msec, ré-émettre une demande.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C06 : Modèle de contrôle
Rôle du modèle de contrôleDiagrammes de Flot de ContrôleReprésentation des processus de contrôleReprésentation du tempsSynthèse
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 54
Structure du Modèle des besoins
Le modèle des besoins est composé d’un modèle fonctionnel et d’un modèle de contrôle en interaction par:
Les activateurs de processusElaboration décrite dans le modèle de contrôle.Les processus activés sont décrits dans le modèlefonctionnel.
Les conditions sur les données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 55
Liens Données/Contrôle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 56
Interprétation du modèle des besoins
Le modèle fonctionnel des besoins est un réseau de processus atomiques
Les processus exécutent la transformation à l’arrivée des données d’entrée.La transformation est instantanée (pas de contrainte temporelle, processeurs infinimentrapide et doté d’une mémoire infinie).Le réseau des PSpec doit être cohérent et complet
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 57
Interprétation du modèle des besoins
Le modèle fonctionnel des besoins est un modèlepurement fonctionnel.
Il est composé de fonctions ne transformant que des informationsIl n’est ni un modèle physique, ni de conception, ni de réalisationLes différents niveaux s’abstraction ne servent qu’àfaciliter la description et donc l’analyse du système.Il est idéaliste au sens où les contraintes techniques viendront « l’altéré ».
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 58
Validation du Modèle Fonctionnelpar le Modèle de Contrôle
Le modèle fonctionnel est défini avant le modèle de contrôle
Le modèle de contrôle n’est pas «obligatoire» dans SA-RTC’est la nécessité d’exprimer un contrôle qui conduit une équipe de projet à employer SA-RT comme méthode de spécification.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 59
Validation du Modèle Fonctionnelpar le Modèle de Contrôle
Les aspects fonctionnels sont donc étudiés avant les aspects dynamiques:
Les contrôles peuvent être superflus.Les processus fonctionnels sont conçu comme des «boites noires» définies indépendamment de la manière dont elles sont activées (comment, pourquoi, quand).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 60
Ecriture du modèle de contrôle.
Le modèle de contrôle est «esclave» dumodèle fonctionnel.
Expression du contrôle par référence aux processus fonctionnels.Opération délicate (cf. le pb de la description des machines séquentielles)Risque de sur-spécification du contrôle (prudence, simulation, etc)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 61
Ecriture du modèle de contrôle.
L’étude du contrôle permet de valider la cohérence d’ensemble du modèle fonctionnel.
Cela impose de respecter quelques règlesd’écriture des modèles fonctionnels et dynamiques.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 62
Ecriture d’un modèle des besoins en SA-RT
Analyser conjointement un modèle fonctionnel et un modèle de contrôle
La compréhension d’une spécification SA-RT nécessiteplusieurs «lectures»cycle Auteur-Lecteur
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 63
Modèle de contrôle ?
lorsque le système ne peut pas êtrereprésenté par un modèle fonctionneluniquement.
∃ des raisons de désactiver des processusExploitation : initialisation, arrêt, sauvegarde, interruptions temporaires, ...Optimisation : consommation temps CPU, surcharge de base de données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 64
Modèle de contrôle ?
Lorsque le contrôle est trop complexe pour être incorporée dans les PSpec.
La transformation de données peut prendre en charge son propre contrôle, sauf si celui-cinécessite une vision de l’environnement duprocessus.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 65
Modèle de contrôle ?
Lorsque le «coeur» des connaissances estcentré sur le contrôle
Concerne le choix des transformations à opéreren fonction du contexte
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 66
Nécessité d’une CSpec ?
Moins il y a de CSpec, plus le modèle des besoins est facile à interpréter et donc à valider.
Minimiser la taille du modèle de contrôle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 67
Nécessité d’une CSpec ?
L’expression du contrôle doit être localisée à des endroits stratégiques:
Aux niveaux les plus élevés (généralité, simplicité, donc clarté).Où les processus ont besoin d’activateursOù les flots de contrôles sont nécessaires
Conditions sur les donnéesFlot de contrôle en entrée d’une Cspec
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 68
Structure des CSpec complexes
Un comportement complexe est décrit par uneassociation de machines séquentielles et combinatoires
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 69
Ecriture des machines séquentielles
Stratégie : Distinguer clairement les événements, lesétats, et les actions
Expression d’une logique temporelle
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 70
Démarche d’écriture des machines séquentielles
1°) Identification des événements (noms et définitions).2°) Identification des états (noms et définitions).3°) Définition des transitions par construction du diagramme état-transition.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 71
Démarche d’écriture des machines séquentielles
4°) Complétion du diagramme par exploration systématique de l’espace Etat-Evénement.
Pour chaque état, envisager l’apparition de chaque événement.Pour chaque transition, envisager chaque état.
5°) Détermination des actions associées aux transitions (machines de Mealy) ou au états (machines de Moore).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 72
Ecriture des machines séquentielles
La forme à retenir dépend de la complexité de l’automate:
Par défaut, privilégier d’abord le diagramme état-transition.
Efficacité de la communication
Lorsque que le diagramme est trop complexe ou qu’une garantie de complétude doit être donnée, utiliser une table État-Transition.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 73
Paradoxe de l’interprétation du modèle des besoins
Mais, ce modèle n’échappe pas au paradoxefondamental d’une spécification !
Lisible et compréhensible pour être validable par le clientPrécise et non-ambiguë pour permettre la conception
Le spécifieur se trouve donc à nouveau écartelé entre 2 types de contraintes tout à fait antagonistes!
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C07 : Synthèse Générale
Dictionnaire des donnéesQualité d’un modèle de besoinDémarche d’ensemble
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Rôle du Dictionnaire des Données
Définir tous les concepts manipulés dans le modèle des besoins.
Référentiel unique de la terminologie technique du projetÉlément fondamental de vérification de la cohérence globale du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Rôle du Dictionnaire des Données
Identifier toutes les données et préciser leurs propriétés :
Structure, Fonction et ComportementChaque flot de données et de contrôle, chaque réservoir, chaque terminaison... et tout ce qui est nécessaire pour interpréter sans ambiguïté le modèle
Le dictionnaire des données est donc obligatoire
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Contenu du dictionnaire des données
Description des propriétés intrinsèques des données :Unité (seconde, mètre, °c, etc)Domaine de définition ou ensemble support ou liste des valeurs possibles (ℵ, ℜ, [-10, +40], {Rouge, Bleu, Jaune}, etc)Domaine de variation autorisé ([0°c, 20°c], <250, etc)Résolution ou précision (5°c, 0.1g, etc)Modalité temporelle (périodicité, apériodocité, évenementielle)Commentaires évitant les ambiguïtés.
Ces informations seront enrichies au cours des phases ultérieures du projet.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Contenu du dictionnaire des données
Les formalismes utilisés sont généralement:La notation Backus Naur Form étendue.Les Diagrammes de Structure de Données de Jackson.Le modèle de modélisation conceptuelle Entité-Relation.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Construction du dictionnaire
La construction du dictionnaire s’effectue du général au particulier, de l’ensemble à l’élément:
Généralité : propriétés génériques, partagées par tous les sous-typesEx: Classe ObjetDatéAttributs: Valuer, DateDeDébut, DateDeFin.Méthode: Initialisation, Oubli.
Particularité : propriétés spécifiques aux sous-classes.Ex: Classe ObjetDatéHistorisé.SuperClasse: ObjetDatéAttribut: HistoriqueSurchage la méthode oubliMéthodes : AjouterInstanceHistorique, SupprimerInstanceHistorique.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C07 : Synthèse Générale
Dictionnaire des donnéesQualité d’un modèle de besoinDémarche d’ensemble
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
Qualité d’un modèle
Une «bonne» spécification s’ obtient après plusieurs itérations
Ne pas hésiter à recommencer entièrement plusieurs fois !
Il est généralement plus aisé de définir des fonctions que des flots de données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
Qualité d’un modèle
Propriétés d’un bon modèle de spécification :Permettre une conception localisée
Permettre un conception distribuée sur des équipes travaillant en parallèle.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
Qualité d’un modèle
Le savoir-faire du spécifieur réside dans sa capacité à faire des groupements de processus judicieux (modules)
Minimiser les flux de données
Maximiser la cohérence fonctionnelle interne
Minimiser les interactions entre modules
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
Propriétés d’un « bon » modèle
Niveaux réellement abstrait (logique)Processus considérés comme des boites noire (encapsulation)Les relations avec l’exo-système d’un processus sont uniquement définies en terme des interfaces d’entrée et de sortie.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
Propriétés d’un « bon » modèle
Rôle des processus intuitifs (dénomination)Définir des fonctions claires, évidentes ou intuitivesFlots de données abstraits, explicites et sans ambiguïté.
Nombre de processus restreint5 à 7 maximum par diagrammeModularité
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Guide de regroupement des processus
Minimiser le nombre de flots dans un diagramme (données et contrôle).Équilibrer la distribution des flots entre les processus.Un processus difficile à nommer est un candidat à la décomposition.Éviter les flots entrant partiellement traités dans les PSpecs et les CSpecs.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 14
Guide de groupement des flots de données
Regrouper pour augmenter la lisibilitéAbstraction
Etiqueter à l’aide de termes abstraits, génériques, définis dans le dictionnaire des données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
Guide de groupement des flots de données
Décomposer les flots de données en même temps que les processus
Hériter de l’abstraction des processusDécomposer soit entre 2 niveaux, soit par ramification sur un même diagramme.
Vérifier les règles de conservation des flots entre les niveaux (cohérence).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
Attention aux abréviations!
Les abréviations permettent un discours synthétique
Minimise les longueurs des dénominations pour manipuler de longues listes sans ambiguïté.Les abréviations doivent être définies dans le Dictionnaire des Données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
Attention aux abréviations!
Les abréviations facilitent la communication … entre spécialistes !
Notion de jargonPerte de lisibilité (communicabilité, validabilité, échange, etc):Chercher à les éviter autant que possible
Parfois, il vaut mieux numéroter plutôt que de s’évertuer à définir des mnémoniques (sauf si un langage peut être défini).
Les choisir avec soin (souvent elles s’imposent d’elles mêmes)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Qualité d’une PSpec
Critères d’arrêt de la décomposition :Traitement suffisamment simple pour être décrit par un processus atomiqueTraitement décrit par ailleursUne décision de conception doit être prise (choix d’un composant)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Qualité d’une PSpec
Une PSpec énumère les propriétés logiques externes d’une transformation
Pré-conditions (état des données d’entrées), Traitement, effets sur les sorties (état des données de sortie), post-conditions (éventuels effets de bord)Pas de redondance avec le reste de la spécification
Attention car c’est très tentant!
Cohérence locale, sans ambiguïté et compréhensible
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C07 : Synthèse Générale
Dictionnaire des donnéesQualité d’un modèle de besoinDémarche d’ensemble
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Retour sur le contrat
Les travaux commencent toujours par la définition de l’objet à construire
Rôle du contratEtape est hautement stratégique : toute erreur à ce stade se traduit par un surcoût considérable
Le contrat définit les conditions d’achèvement des travaux, et donc les conditions de la recette du système
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Expression d’un besoin
Le développement d’un modèle SA-RT part de l’expression d’un besoin qu’un Client ne peut seul parvenir à satisfaire.
Il fait appel à un Fournisseur à qui il confie le soin de construire un système susceptible de satisfaire son besoin.L’ensemble des travaux sont encadrés par un contrat qui définit les droits et devoirs du Client et de son Fournisseur.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
Objectifs de la spécification : définir le but du système, sa mission
Acquisition des informations par interview des représentants du Client
Chef de Projet ClientExperts du domaineSpécialistes des systèmes composant l’exo-système du système à construire.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Objectifs de la spécification : définir le but du système, sa mission
Autres sources d’informations :Le Cahier des Charges.La documentation sur le domaine.Observations sur le terrain.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
1°) Définir le contexte
Objectif de la première étape : identifier le périmètre fonctionnel du système :
Identifier les terminaisons.
Identifier les flots de données d’entrée et de sortie en liaison avec les terminaisons.
Séparer données et contrôle, sans oublier que l’on a toujours tendance à sur-spécifier le contrôle.
Remplir dès le départ le dictionnaire des données.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
1°) Définir le contexte
Conseils:Si les terminaisons sont nombreuses, ne représenter qu’un seul flot de données entrant et un seul sortant. La décomposition s’effectuera au niveau inférieur.
Si la complexité du système le permet, confondre DCD et DCC. Cela facilite la compréhension d’ensemble du système.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
2°) Dessiner le DFD0 et le DFC0
Identifier les fonctions principales (de 3 à 7 fonctions maximum).Décomposer les flots de données entrant et sortant
Mettre à jour le dictionnaire.
Identifier les flots de données internes.Ajouter si besoin est les flots de contrôles internes.Mettre à jour le DCD et le DCC si besoin est (dans une démarche globalement descendante)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
2°) Dessiner le DFD0 et le DFC0
Ajouter les éventuels stockagesUn stockage ne se justifie que lorsque le résultat d’un processus ne peut être consommé immédiatement (une mémorisation est nécessaire).Un stockage peut être lu n fois par p processus, dans un ordre quelconque.Un stockage n’est présent qu’à un seul niveau de décomposition.Un stockage doit obligatoirement être définit dans le dictionnaire.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
2°) Dessiner le DFD0 et le DFC0
Identifier la nécessité de la CSpec0Si le contrôle du DCC participe à l’activation d’un des processus du DFD0, alors introduire la CSpec0 qui consomme ce flot de contrôle.Sinon, faire entrer le flot de contrôle dans le processus fonctionnel concerné par l’activation. Il n’y aura pas de CSpec0.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 30
2°) Dessiner le DFD0 et le DFC0
Conseils:Il est toujours préférable de faire un diagramme composite (DFD0 et DCD0).
ce n’est applicable que dans le cas d’un système de complexité «faible» ou «moyenne».
Se préoccuper des temps de réponses dès ce niveau.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 31
3°) Affiner la décomposition (DFDi, DFCi)
Définir chaque flot de données et chaque flot de contrôle dans le dictionnaire, et préciser la composition des groupes de données.Mettre à jour les diagrammes pères.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 32
3°) Affiner la décomposition (DFDi, DFCi)
Vérifier, à chaque niveau, la cohérence du modèle et les principes de qualité :
Nombre de processus (l’idéal est d’avoir 3 à 5 processus par niveau).Chaque processus se trouve-t-il au bon niveau ?
Regroupement/séparation des processus par niveau d’abstraction et de complexité équivalents
Ne manque-t-il pas de flots de données ?Chaque processus peut-il produire ses flots de sortie avec les seuls flots de données entrant représentés ?
Ne manque-t-il pas de flots de contrôle ?Les flots de contrôle arrivant sur la CSpec permettent-il de gérer l’activité des processus ?
Les principes de conservation des flots sont-ils respectés ?
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 33
4°) Ecrire les PSpecs
La décomposition fonctionnelle s’arrête lorsque:une fonction n’est pas décomposable
Il n’est pas utile de la décomposerElle a été décomposée par ailleurs.
une décision de conception doit être prise.la PSpec est considérée comme suffisante à la compréhension d’un processus.
Une PSpec décrit les propriétés externes du processus
Pré-conditions, Traitement, Post-conditions
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 34
4°) Ecrire les PSpecs
Choisir le formalisme adéquat à la communication selon son essence, sa nature :
Traitement procédural ==> Texte en langage naturel structuré (pseudo-code).Calcul ==> Equations mathématiques.Prise de décision ==> Table de décision ou base de règles.Opérations géométriques ==> Graphiques
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 35
5°) Ecrire les CSpec
Avant toute chose déterminer la nécessité de la CSpec à chaque niveau.
Est-il nécessaire d’inactiver les processus de ce niveau ?Le modèle fonctionnel est-il insuffisant ?Le contrôle ne peut-il pas décrit dans les PSpec ?
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 36
5°) Ecrire les CSpec
Choisir le type de CSpec adapté aux modalités du contrôle :
Les sorties ne dépendent que des entrées ==> CSpeccombinatoire.Les entrées dépendent des entrées courantes et des entrées passées :
Les états liés aux entrées passées sont disponibles ==> CSpecCombinatoire.Les états ne sont pas disponibles ==> CSpec Séquentielle.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 37
6°) Instruire les contraintes temporelles
Les contraintes temporelles structurent l’ensemble de la répartition fonctionnelle
Les étudier dès le DCD-DCC et tout au long du processus de modélisation
Spécifier les propriétés temporelles des données dans le dictionnaire:
Les taux de réception des entrées.Les taux d’émission des sorties.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 38
6°) Instruire les contraintes temporelles
Spécifier les temps de réponseTableau Entrée/Événements/Sortie/Événements/Temps de réponse.
Vérifier la cohérence de la table des temps réponse par rapport aux contraintes temporelles exprimées dans le dictionnaire.
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C08 : Modèle d’Architecture
Processus de développementModèle d’Architecture
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 2
Processus de développement
SA-RT distingue les natures logicielle et matérielle du système:
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 3
Développement en parallèle
Les architectures logicielle et matérielle sont intimement liées
L’architecture logicielle définit les composants logicielsStratégie de production et de test unitaires des codes,Stratégie d’intégration et les tests d’assemblage.
L’architecture matérielle définit les composants matérielsStratégie de production et de test des processus matériels,Stratégie d’intégration et les tests d’assemblage.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 4
Développement en parallèle
L’architecture du système est à la base de la stratégie d’intégration du système.
Stratégie de production et de test unitaires des modulesStratégie d’intégration et les tests d’assemblage
Il est donc indispensable de garantir la cohérence des 2 architectures.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 5
Processus de développement
SA-RT préconise un processus de développement itératif et hiérarchique:
1°) Création du modèle des besoins --> Indépendance vis à vis des techniques à mettre en oeuvre.2°) Complétion du modèle des besoins --> Canevas d’architecture.Interfaces E/S, Interface utilisateur, Maintenance et fonctions de diagnostic.3°) Développement du modèle d’architecture
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 6
Processus de développement
Le développement est donc fondé sur un cycle de vie en spirale
École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et IndustrielC235 : Spécification des Systèmes Temps Réels
C08 : Modèle d’Architecture
Processus de développementModèle d’Architecture
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 8
Le Modèle d’Architecture
Le modèle d’architecture modélise la conception du système physique.
Décrire les moyens retenus pour supporter l’exécution des fonctions décrites dans le modèle des besoins compte tenu des techniques mises en oeuvre.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 9
Le Modèle d’Architecture
La conception prend en compte les contraintes imposées par le CdC:
Performances (flux de données, cpu, ...).Validabilité (testabilité, observateurs, ...).Taux de disponibilité (matériel, logiciel, système, service, ...).Maintenabilité (corrective et évolutive).Ergonomie.Interopérabilité.Coûts (de maintenance, d’exploitation, de tests, ...).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 10
Objectif du Modèle d’Architecture
Définir le module d’architecture où seront implantés les processus du Modèle des Besoins
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 11
Objectif du Modèle d’Architecture
Le rôle du modèle d’architecture est donc d’identifier:Les composants physiques.Les processus physiques.Les flux informationnel liant ces processus.Les canaux d’information transporteurs des flux informationnels.
Il montre de plus l’affectation des traitements d’exploitation du système:
Interface utilisateur.Entrées et SortiesMaintenance et auto-diagnostic.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 12
Composants du Modèle d’Architecture
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 13
Eléments du modèle d’Architecture
DCA : Diagramme de Contexte d’ArchitectureContexte d’interprétation de l’architecture.
DFA : Diagramme de Flot d’ArchitectureEntités physiques et les informations qui circulent entre elles.
SMA : Spécification des Modules d’Architecture
Spécifie les modules d’architecture.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 14
Eléments du modèle d’Architecture
DIA : Diagramme d’Interconnection des modules d’Architecture
Identifie les canaux d’informations sur lesquels les données circulent.
SIA : Spécification des Interfaces entre modules d’Architecture
pécifie les canaux d’informations.Dictionnaire des données d’architecture.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 15
DCA & DFA
Le Diagramme de Contexte d’Architecture (DCA) définit la frontière informationnelle entre le système et son environnement.
Montre les communications entre le système et les entités externes.Définit la frontière de l’étude.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 16
DCA & DFA
Le Diagramme de Flots d’Architecture (DFA) est une représentation, sous forme de réseau, de la configuration du système:
Modules physiques du système (les modules d’architecture).Vecteurs (média) support des flots d’information entre ces modules.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 17
DCA & DFA
Tous les objets du modèle d’architecture sont supportés par des spécifications textuelles.
Montrer l’affectation des traitements et des flotsSpécifier les caractéristiques des canaux de communication.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 18
Démarche de Conception
La démarche de conception préconisée par SA-RT est une démarche «récursive globalement descendante».Elle est fondée sur une structure générale de système, un canevas
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 19
Exemple: DFA1 (le système)
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 20
Tout module d’architecture est définit selon la même structure
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 21
Spécification des Modules d’Architecture (SMA)
Notion de module d’architectureEntité (ou un groupe d’entités) à qui est attribuée des processus fonctionnels et de contrôle, et les flots associés.Correspond à un module physiquement individuel, ou à un sous-système (groupement d’entités).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 22
Spécification des Modules d’Architecture (SMA)
Tous les processus du modèle des besoins doivent être affectés à un et un seul module d’architecture.
Matrice de Traçabilité qui définit complètement l’affectation du modèle des besoins au modèle d’architecture.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 23
Exemple de SMA
SMA: Module de l’ordinateur de bord d’une automobile.
Description : L’ordinateur de bord comprend tout le logiciel du système parce que l’on ne peut utiliser qu’un seul processeur.Module : Le système sera construit autour d’un microprocesseur de type M68020.Affectation : Processus 1, 2, 3, 4, 8.6 et la CSpec0.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 24
Exemple de SMA (suite)
MATRICE de TRACABILITE
XCSpec0
X5
X4
X3
X2
MA3MA2
X
MA1
Composant du modèle d’architecture
1
Composants du modèle des besoins
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 25
Spécification d’Interconnexion d’Architecture (SIA)
Le rôle de la SIA est de définir les caractéristiques (propriétés) des canaux d’information.Les supports physiques (les bus) peuvent être de nature différente (bus électrique, mécanique, optique, ...).
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 26
Exemple d’un bus électrique
Bus utilisateurIl transporte les informations dans un format 32 bits série.Les caractéristiques temporelles de la ligne sont les suivantes:
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 27
Dictionnaire des données d’Architecture
Le dictionnaire des données d’architecture contient tous les éléments de données et de contrôle qui circulent sur les canaux d’information.Il ajoute la description physique liées au transport des informations définies dans le dictionnaire des données.Il montre l’utilisation de chaque donnée par les modules d’architecture.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 28
Construction du Modèle d’Architecture
Le but de l’analyse de l’architecture du système est de répartir les composants du Modèle des Besoins sur les processus matériels.La première étape consiste à déterminer la manière dont les modules d’architecture réaliseront leurs tâches. Il convient de choisir entre une solution qui utilise des processus matériels ou logiciels.
©Marc LE GOC 2005, C235, Spécification des systèmes temps réels 29
Construction du Modèle d’Architecture
L’architecture du système est achevée lorsque tous les éléments du Modèle des Besoins ont été attribués à un module d’architecture.La conception détaillée des systèmes matériels et des systèmes logiciels peut commencer, en parallèle.