Admin CliCours
L’informatique industrielle est en pleine expansion. Avec l’accroissement de la puissance de calcul et la miniaturisation des puces électroniques, c’est toute l’industrie qui est aujourd’hui concernée par cette révolution technologique. Une caractéristique importante des applications informatiques industrielles est qu’elles doivent se conformer à des exigences hétérogènes (exigences de fiabilité, d’occupation physique, de performance, de consommation énergétique, etc…). Ces exigences sont souvent contradictoires et dépendent du contexte environnemental dans lequel évolue le système :
baisser la consommation énergétique diminue les performances du système, mais un système devra baisser sa consommation énergétique si son niveau de batterie devient insuffisant. Nous appelons cela un comportement adaptatif : le système modifie son comportement en cours d’utilisation pour répondre aux variations des caractéristiques de son utilisation. Une panne matérielle (ou logicielle), une étape dans le cycle de vie du système, une modification des ressources disponibles (bande passante ou niveau de charge de la batterie par exemple), un besoin de maintenance, une requête utilisateur, sont autant d’exemples de situations qui nécessitent d’adapter le comportement d’un système. Ainsi, la spécification des modes de fonctionnement d’un système constitue le plus souvent une des premières étapes du processus de développement d’un système. Faute de méthodologie outillée pour réutiliser cette spécification lors de la conception logicielle, l’implantation des mécanismes d’adaptation est le plus souvent faite manuellement. Le code ainsi développé est difficile à maintenir, et le comportement associé à ces mécanismes d’adaptation est d’autant plus difficile à analyser qu’il est enfoui dans le code de l’ensemble de l’application.
L’utilisation massive des systèmes informatiques industriels nécessite de développer des méthodes de conception qui augmentent la productivité des équipes de développement logiciel. Depuis le début des années 80, ce besoin a été traité dans de nombreux travaux de recherche qui se sont intéressés à l’automatisation de la production des systèmes TR2E. Le principal objectif de ces travaux est de répondre aux problèmes que pose la variabilité des exigences non-fonctionnelles de ce domaine. Pour répondre à ce problème, les intergiciels ont d’abord fait leur apparition. Couche d’adaptation entre le code applicatif d’une part et le code dépendant de la plate-forme d’exécution d’autre part, les intergiciels facilitent la mise en œuvre de la séparation des préoccupations : le code applicatif peut être développé indépendamment de la plate-forme sur laquelle il s’exécute. Pour améliorer encore cette solution, les modèles à composant répondent au besoin de la décomposition fonctionnelle : une application peut ainsi être développée par parties qui réalisent chacune un sous-ensemble des fonctionnalités du système final. L’ensemble de ces fonctionnalités peut alors être obtenu par assemblage, déploiement et configuration de ces composants.
Enfin, l’utilisation de techniques de modélisation a permis d’automatiser le déploiement et la configuration des applications TR2E. En effet, l’information contenue dans une description d’architecture permet soit (i) de déployer dynamiquement une application logicielle, soit (ii) de générer le code permettant un déploiement statique de cette application. Par ailleurs, le développement de systèmes critiques nécessite de respecter certaines contraintes de réalisation, dont le but est d’augmenter le déterminisme de l’application. Ceci inclus la mise en œuvre d’un processus de conception rigoureux imposant le respect de règles de conception et de développement, et faisant une utilisation exhaustive des procédures de test. Au delà de ces techniques traditionnellement utilisés dans le développement des systèmes critiques, l’utilisation de méthodes formelles s’impose de plus en plus comme une étape nécessaire à la validation des systèmes critiques.
Définition 2.2.1 Système réparti [Coulouris et al., 2005]
Un système réparti est un ensemble de machines autonomes connectées par un réseau, et équipées d’un logiciel dédié à la coordination des activités du système ainsi qu’au partage de ses ressources.
L’utilisation des systèmes répartis présente l’avantage de pouvoir démultiplier le nombre d’unités de calcul, ce qui permet d’augmenter les performances globales du système. La répartition pose cependant un certain nombre de problèmes, comme par exemple la portabilité et l’interopérabilité des différentes applications qui composent un système réparti. Revenons rapidement sur la définition de chacun de ces termes. La portabilité est la capacité d’une application à être utilisable sur différents types de plate-formes au prix d’un effort de portage minimal de son implémentation. L’interopérabilité est la capacité de deux applications différentes à interagir entre elles (même si leur conception a suivi des stratégies différentes).
Définition 2.2.2 Système temps-réel [Stankovic, 1988]
La correction du système ne dépend pas seulement des résultats logiques des traitements, mais dépend en plus de la date à laquelle ces résultats sont produits.
Définition 2.2.3 Système embarqué
Un système embarqué est un système qui possède une quantité de ressources (ressources de calcul, ressources énergétiques) réduite.
L’interopérabilité et la portabilité caractéristiques font partie de ce que nous appelons plus globalement – c’est à dire pour l’ensemble des systèmes TR2E – les exigences non fonctionnelles d’un système. Outre ces caractéristiques, le choix d’une plate forme matérielle, d’un protocole réseaux, d’un langage de programmation, de règles d’implémentation, de l’utilisation d’un standard particulier, ou encore de patrons d’interaction entre les applications réparties, sont des exemples courants des exigences non fonctionnelles de la réalisation d’un système.
I Introduction Générale |
Télécharger le document complet
