SEG-2506 "Construction de logiciel"
Choix pour la conception de l'implantation
(voir livre de Braek et al.: "Engineering Real Time Systems", chapitre 9. Ce livre considère le "co-design" : choix de conception du système concernant le matériel ET le logiciel)
1. C'est quoi, la conception de l'implantation
- But: définir une correspondance entre la spécification
fonctionnelle et le système implanté (en forme de matériel et logiciel)
- Travail à faire: prendre les décisions nécessaires et les documenter
en assez de détail pour définir les propriétés de l'implantation à réaliser
- Résultat: description de la conception de l'implantation qui
explique comment les fonctions abstraites sont à réaliser
La portée de la conception de l'implantation est montrée sur le
diagramme suivant:
![](Fig-9-1.jpg)
Exemple du système de contrôle d'accès - Question: "Quelle partie à implanter
en matériel, quelle partie en logiciel, quelle forme de logiciel ?"
![](Fig-9-2.jpg)
Les deux diagrammes suivantes montrent (a) le cas simple (on choisit une
alternative d'implantation équivalente à la spécification fonctionnelle), et (b)
le cas où la conception de l'implantation nous amène à réviser la spécification
SDL (appelée "SDL description") pour y inclure des aspects de
fonctionnalités qui sont pertinents pour
l'implantation ou de l'adapter aux contraintes d'implantation (exigences non
fonctionnelles).
![](Fig-9-3.jpg)
![](Fig-9-4.jpg)
Les sous-étapes de la conception de l'implantation
- Choix ("trade-off") entre matériel et logiciel
- Définir l'architecture matériel
- Définir l'architecture logiciel
- Réviser et raffiner la conception fonctionnelle
2. Aspects ignorés par la spécification fonctionnelle
La différences entre la spécification fonctionnelle et la description de
l'implantation à élaborer dans cette phase du génie de systèmes ont deux raisons
d'être:
- Les concepts inhérents au langage de description utilisé pour la
spécification fonctionnelle ne correspondent pas toujours aux concepts utilisés
pour l'implantation des parties correspondantes du système. Il faut donc
penser comment ces concepts (par exemple les processus concurrents des machines à états et
leur communication par messages) sont à réaliser dans l'implantation. Ceci n'est pas élaboré dans la suite.
- Certains aspects du système à construire, en relation avec les exigences
non fonctionnelles, sont souvent ignorés par la spécification fonctionnelle. Ces aspects doivent être considérés lors de la conception de
l'implantation, en particulier les aspects suivants:
2.1 Le temps de traitement
- Note: En SDL, le temps d'exécution des transitions et
de propagation des messages est ignoré; dans l'implantation, il faut le
prendre en considération.
- Les exigences non fonctionnelles mentionnent
typiquement les deux aspects suivants:
- temps de réponse du système (délai entre l'envoi d'une
requête et la réception d'une réponse)
- débit (nombres de requêtes à traiter par seconde)
- Lors de la conception de l'implantation, il faut donc
trouver des solutions matérielles / logicielles satisfaisant ces
contraintes
- L'interface entre les parties matérielles et
logicielles requiert une préoccupation particulière: Le logiciel doit être
assez vite pour capter les signaux qui arrivent par les canaux matériels.
C'est le rôle des "drivers" (voir les processus IO-Channel dans la
figure 10.1 ci-dessous, qui sont des processus concurrents qui s'exécutent
dans l'environnement de multiprogrammation fourni par le Concurrency
Support du système d'exploitation).
![](Fig-10-1.jpg)
- Estimer la performance de l'implantation planifiée: Il est important d'estimer la performance de l'implantation future avant qu'elle soit construite. Il est aussi important de considérer que la performance d'un système qui supporte plusieurs usagers, le temps de réponse dépend de la charge (débit) du système, c'est-à-dire, plus qu'il y a des requêtes, plus long sera le temps de réponse; lorsque le débit maximum est atteint, le temps de réponse sera complètement dégradé - le système est débordé. Pour obtenir une estimation de la performance du système, on a besoins des trois points suivants:
- Estimation réaliste de la charge du système: (a) fréquence des requêtes; (b) importance rélative des différents types de requêtes qui pourraient avoir différentes exigences concernant les ressources du système (CPU, accès disque, besoin de communication). Il faut considérer la charge moyenne, aux heures de pointe. Des "benchmarks" sont des scénarios de requêtes qui sont utilisés pour comparer la performance de différents systèmes existants; et pourraient être utilisé pour mesurer la performance d'un prototype.
- Estimation des ressources requises pour chaque type de requête: Ceci pourrait être une estimation du nombre d'instructions CPU réquises pour exécuter une requête simple; si on connait le cycle d'horloge de l'ordinateur, ceci donne une estimation du temps CPU nécessaire pour exécuter la requête. Ceci pourrait impliquer une estimation du nombre de fois qu'une boucle sera exécutée en moyenne. De telle estimations peuvent aussi être faites à un niveau d'abstraction plus haut: par exemple, estimer le nombre de transitions SDL à exécuter d'après la spécification fonctionnelle, et estimation de temps CPU moyen nécessaire pour exécuter une transition SDL.
- Méthodes d'estimation de performance quand la charge et les exigences de ressources sont données: Les méthodes suivantes sont souvent utilisées:
- Raisonnement direct: un exemple est donné dans le livre de Braek et al.:
- déterminer le nombre de transitions SDL impliquées dans
la préparation de la réponse à la requête,
- estimer le temps CPU requis pour une transition SDL en
moyenne,
- et il faut estimer quel fraction de temps le CPU est
alloué à la tâche en question (parmi d'autres tâches concurrentes).
- Si l'on veut aussi estimer le débit qui peut être
offerte par l'implantation, il faut faire cette estimation pour toutes les
types de requêtes et estimer la fréquence relative des différentes requêtes.
- Modèles de file d'attente et modèles de simulation : voir notes de cours ci-haut.
- Note: L'évaluation de la performance d'une conception préliminaire de l'implantation peut aboutir à la proposition d'une nouvelle architecture pour satisfaire les exigences de performance. Un exemple est donné dans le livre de Braek et al.: architecture matérielle initiale, architecture matérielle révisée incluant des unités "Cluster", description en SDL revisée de l'implantation (vue globale, structure de blocs détaillée incluant des blocs fonctionnels pour les protocoles de communication et la validation (banque de données) dans les unités "Cluster").
- Dans le cas d'un système avec des contraintes de
temps-réel dures ("hard real-time systems"), il faut garantir que le temps de
réponse reste toujours en dessous d'une limite maximum. Il faut alors être
plus stricte: au lieu de faire des estimations, il faut démontrer que le temps
de réponse reste en dessous de la limite. Cela est beaucoup plus difficile,
e.g. la machine virtuelle Java normal n'est plus appropriée comme
environnement d'exécution parce que, par exemple, la récupération de mémoire
pourrait interrompre l'exécution d'une tâche et ainsi allonger le temps
d'exécution d'une durée non déterminée.
2.2 Les imperfections du matériel et logiciel: erreurs, fautes, bruit de fond,
etc.
- La spécification fonctionnelle ne considère normalement
pas des erreurs de lectures ou d'écriture matérielles, de communication, ou
des dommages physiques des composantes dus aux accidents ou au vieillissement.
Un cas spécial est qu'une réponse n'arrive pas (à cause d'une perte de message
ou à cause d'une panne de l'ordinateur sur lequel le programme serveur
s'exécute). - Voici un exemple d'exigences concernant l'impact d'erreurs sur le fonctionnement du système de contrôle d'accès (du livre de Braek et al.)
- Si de telles problèmes sont à prévoir, il faut alors
déterminer comment les détecter et quel traitement exceptionnel à prévoir.
Dans ce contexte, on distingue les trois actions suivantes:
- détection de la faute (souvent on utilise aussi le mot
"erreur": quelque observation indique une erreur, une situation non conforme à
la spécification)
- isolation de la faute, c'est-à-dire, la localiser,
trouver la cause de l'erreur observée
- récupération de la faute (si possible), c'est-à-dire,
faire en sorte que le système réalisera sa tâche spécifiée malgré la présence
d'une faute. Dans le cas d'une faute matériel, cela implique ou la réparation
ou le remplacement de la composante fautive (ce qui prend du temps), ou du
matériel redondant qui prend alors la relève.
- Note: Dans le cas de systèmes ultra-fiables, on utilise
souvent des composantes triples qui exécutent tous les trois la même tâche en
parallèle. À la fin de l'opération, une unité de comparaison compare les trois
résultats obtenus et s'ils ne sont pas identiques on peut identifier la
composante fautive (sous l'hypothèse que seulement une seule composante
devient fautive à la fois). On utilise alors de résultats des deux autres
composantes (le système est tolérante à une faute simple); et on essaie
de remplacer la composante fautive aussitôt que possible (avant qu'une autre
composante ne devienne fautive).
- Voici d'autres concepts importants:
- tolérance aux fautes (voir exemple ci-dessus)
- résilience aux fautes: Une faute peut avoir un impact,
mais les fonctions importantes du systèmes continuent à être offertes.
- sûreté dans le cas d'une faute ("a fail-safe system"):
Dans le cas d'une faute, le comportement du système assure qu'il n'y a pas de
"catastrophe", c'est-à-dire, une situation qui ne devrait jamais arriver
(comme par exemple l'explosion d'un réacteur nucléaire, ou l'ouverture d'une
porte d'un train en mouvement).
2.3 La distribution physique
- Avantages d'une implantation distribuée sur plusieurs
ordinateurs:
- La panne d'un ordinateur n'affecte, n'immobilise pas
nécessairement le système au complet. L'isolation de la faute est possible.
- Augmentation du débit du système (en faisant du
traitement parallèle).
- Désavantages:
- Communication entre ordinateurs implique des délais
supplémentaires.
- Des protocoles de communication sont nécessaires pour
récupérer les erreurs de transmission et autres problèmes de communication.
2.4 Les ressources limitées
- Dans l'implantation les ressources sont limitées. Par
exemple: nombre de processus dans un ordinateur, espace mémoire disponible,
longueur maximum de tampons pour la réception de messages.
- Note: Des tampons de longueur limitée peuvent
facilement donner lieu à des blocages (quand un producteur ne peut pas envoyer
son message parce que la file de réception est plaine); il faut être vigilant
lors de la conception de systèmes de communication par messages.
2.5 Autres choix
- La sécurité
- Les exigences concernant l'opération du système et sa maintenance
- Les coûts de développement et de production matériel
- Note: Le coût de développement existe une fois;
le coût de production matériel dépend du nombre d'unités à construire.
- La réutilisation de composantes existantes
- Cela implique que la fonctionnalité de la composante
existante ne devrait pas être dupliquée par les parties nouvelles à
construire.
- Cela implique aussi que les parties nouvelles à
construire devraient prévoir des interfaces appropriés pour la communication
avec les composantes existantes
L'exemple de l'application de ces considérations
d'implantation au système de contrôle d'accès est discuté dans le livre de Braek
et al. (voir section 9.4).
Note: Le livre de Braek et al. utilise certaines notations graphiques
pour décrire les architectures matérielles et logicielles. Ces notations ne sont
pas généralement acceptées dans la communauté; vous n'avez pas besoin de les
apprendre.
Initialement écrit: 22 mars 2003; revisions: 2004; 2011; mars 2015