spécification des systèmes temps réel -...

École Polytechnique Universitaire de MarseilleDépartement Génie Informatique et Industriel

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

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.

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?

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.

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

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.

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,

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.

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

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.

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

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

Notion de contrat

Cahier desCharges

OffreT/O/F

Contrat

Spag/MCE/MCoop/...

Spec1/Spec2/…/Specn

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.

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.

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.

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

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

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

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

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

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.

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 ?

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.

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.

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!

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.

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é

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.

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.

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.

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

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 !

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.

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

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.

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.

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.

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

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

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 !

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

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.

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

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.

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.

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.

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

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.

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.

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.

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

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.

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»

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

Le processus de développement classe les activités en 5 grands types:

SpécificationConceptionRéalisationValidationExploitation

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.

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 !

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

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)

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

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.

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.

3°) Ambiguïté : Connaissance donnant naissance à plusieurs interprétations.

4°) Absence de clarté : Connaissances difficiles à interpréter.

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.

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.

C02 (partie 2):Notion de Spécification

Cycles de Vie en V

Cycle de vie en Spirale

Spécification et Conception

CdV en VSystèmeBesoins

Définition des BesoinsExploitation

Maintenance

Spécification

Codage

Test Unitaire

Intégration

CdV en V

Spécification

Codage

Test Unitaire

Intégration

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

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

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)

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

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)

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)

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

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)

CdV en V : Exploitation/Maintenance

Exploitation du système sur siteSuivit des défautsDéfinition du contour fonctionnel de la prochaine version

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

Définition des Besoins

Spécification

Conception DétailléeDes

Ingénierie Informatique

Cycles de Vie en V

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

CdV en Spirale (vue déployée)

Périmètre

SpécificationConception

RéalisationIntégration

Quadrant du Développement

Spécification

Codage

Test Unitaire

Intégration

Validation (Recette)Spécification

Codage

Test Unitaire

Intégration

ValidationRecette

CdV en Spirale

Version 1 Version 2 Version 3

Composant C2

Composant C1

Fonction Ff

Fonction F2

Fonction F1

Composant Cc

Périmètre

Cycles de Vie en V

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

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

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.

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.

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.

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

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

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

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

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.

Cahier des Charges

Offre Technique

Contrat

Analyse Externe

SPAG, SPEX, COOPSpécifications

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.

C03 (partie 1) :Introduction à 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

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.

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.

DICTIONNAIRE des DONNEES.TABLE de TEMPS de REPONSE.

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

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.

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 ?

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

C04 : Modèle fonctionnel des besoins

Démarche de modélisationNotion de DFDSystème syntaxique de SA-RTCohérence des DFD

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.

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.

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.

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.

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.

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.

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.

RemarqueS

SI2 O1

RemarqueS

Environnement

RemarqueS

Environnement

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

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.

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.

Structure du modèle fonctionnel des Besoins

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.

Ces concepts sont représentés par 4 symboles (ou formes)Terminaison Source

Flot de données

Réservoirs

Terminaison puit

Processus

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

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.

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

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

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

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

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

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

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.

Exemple de DFD

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.

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

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

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

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.

C05 : Processus atomiques

Spécification des processus atomiquesStyles de PspecSynthèse

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

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.

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.

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.

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

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

Spécification des processus atomiquesStyles de PSpecSynthèse

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)

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

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

Symboles mathématiques

Pas besoins d’être définis∀, ∃, ∈, ⊃, …,=, <, >, ≥, ≤, ≠, …,∧, ∨, ⊕, ⇒, ⇔, …Notation des variables libres

« *Type » par exemple

Notation algorithmique

SéquenceSpécifie l’ordre d’exécution des transformations.

ConcurrenceSpécifie l’absence d’ordre d’exécution destransformations

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

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

Exemple de PSpec textuelle

Séquence:INTERET_DU <-- TAUX*DUREE*MONTANTSOLDE <-- SOLDE - INTERET_DURetourner RESTE <-- SOLDE

Remarque :Attention à l’égalitéRetourner RESTE = SOLDE

Alternative:SI ALTITUDE > ALTITUDE_DE_TRANSITIONALORS VITESSE <-- MACHSINON VITESSE <-- VITESSE_DE_L_AIR

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.

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é

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

Le style Décisionnel

a55a41a33

a53a42a32

a52a41a31

a52a41a33

a51a43a32

a55a43a31

a54a43a33

a51a42a32

a51a42a31a22

a53a42a33

a52a41a32

a51a41a31

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

Exemple de style équationel et décisionnel

2ABCosΦ

2ABSinΦ=A

2ABSinΦ

2ABCosΦ<A

A2-B2A2+B2-<0

SortiesEntrées

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

Exemple de style graphique

Spécification des processus atomiquesStyles de PSpecSynthèse

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

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

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

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

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 !

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

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

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.

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

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)

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

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

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.

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.

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.

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

Exemple de DFC

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.

État de l’interrupteur

Exemple de l’interrupteur à 2 positions

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)

Discrétisation spatiale d’un signal

x(t)∈ℜ xd(t)

Evt(Vc)

te1(t1, +1) e2(t2, +2)

e3(t3, +∞)e4(t4, +2)

e5(t5, +1)

xd(t)∈ℵ

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.

Flot de contrôle

Flot de données

Signal discret (ℵ)

Signal continu (ℜ)

Nature de l’information

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.

Exemple de conditions sur les données

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)

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

Représentation des processus de contrôle

Les machines discrètes décrites dans les CSpecpeuvent être de 2 types:

Notion de machine combinatoire

Une machine est combinatoire ssi : Y = F(E)Y vecteur de sortieE vecteur d’entrée

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.

Notion de Machine Séquentielle

Une machine est séquentielle ssi : Y = F(X, E), Xvecteur d’état de la machine

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.

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.

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.

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.

Convention :Les actions sont supposées continuer leurs effetsjusqu’à ce qu’une transition soit franchie

Exemple de machine de Mealy

Exemple de CSpec Séquentielle

Table d’activation des processus

Obtenir une Bonne Séclection

Distribuer le Produit

1Distribuer Produit

0Accepter Nouvelles Pièces

1Rendre Paiement

Rendre la Monaie

Processus

Accepter Sélection

Actions

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

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.

Exemple de machine séquentielle

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

Forme tabulaire des machinesséquentielles

Evt2Evt1Etat

Nouvel Etat

Action

Matrice Etat-Evénements

Nouvel EtatEtat

ActionEvt

Matrice Etat-Nouvel Etat

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

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.

Exemple

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.

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

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.

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.

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

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

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.

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.

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.

Liens Données/Contrôle

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

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

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.

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

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)

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.

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

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.

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.

Lorsque le «coeur» des connaissances estcentré sur le contrôle

Concerne le choix des transformations à opéreren fonction du contexte

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

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

Structure des CSpec complexes

Un comportement complexe est décrit par uneassociation de machines séquentielles et combinatoires

Ecriture des machines séquentielles

Stratégie : Distinguer clairement les événements, lesétats, et les actions

Expression d’une logique temporelle

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.

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

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.

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!

C07 : Synthèse Générale

Dictionnaire des donnéesQualité d’un modèle de besoinDémarche d’ensemble

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.

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

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.

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.

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.

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.

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.

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

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.

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é

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.

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.

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

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.

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)

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)

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

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

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.

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.

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.

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.

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.

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)

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.

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.

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.

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.

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 ?

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

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

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 ?

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.

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.

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.

C08 : Modèle d’Architecture

Processus de développementModèle d’Architecture

Processus de développement

SA-RT distingue les natures logicielle et matérielle du système:

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.

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.

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

Le développement est donc fondé sur un cycle de vie en spirale

C08 : Modèle d’Architecture

Processus de développementModèle d’Architecture

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.

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

Objectif du Modèle d’Architecture

Définir le module d’architecture où seront implantés les processus du Modèle des Besoins

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.

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.

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.

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.

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.

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.

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

Exemple: DFA1 (le système)

Tout module d’architecture est définit selon la même structure

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

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.

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.

Exemple de SMA (suite)

MATRICE de TRACABILITE

XCSpec0

MA3MA2

Composant du modèle d’architecture

Composants du modèle des besoins

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

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:

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.

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.

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.

spécification des systèmes temps réel -...

Documents

spécification et conception de produits nouveaux 1...

spÉcification iso/ts technique 20049-2

spécification comportementale par réseaux de petri

spécification d’un modèle de protocole : promela

le tableau des spécification

une approche basée architecture pour la spécification...

appel d’offres spécification technique concernant les

spécification technique fluxus cryo

colorimétrie et physiologie: la spécification lms

spécification géométrique : la normalisation iso(gps)

liste des fournisseurs approuvés par spécification

spécification des opérations

exemple d'analyse et de spécification

document de spécification

spécification technique

spécification caractéristiques essentielles performances

coo : spécification du logiciel - ocl

crif - spécification technique - socle applicatif

spécification, analyse et vérification formelle des

la spécification géométrique des produits