Brevet FR2911976A1 — publié le 20080801

Procédé de conception d'un système comprenant des composants matériels et logiciels La présente invention est relative à l'ingénierie système et logicielle, et plus particulièrement à la validation amont des exigences non fonctionnelles d'un système. Le développement de systèmes complexes nécessite différentes étapes de résolution de problèmes et de conception incrémentales. L'objectif est de construire une solution répondant aux exigences du client. On distingue généralement deux types d'exigences : les exigences fonctionnelles et non fonctionnelles. Les exigences fonctionnelles sont relatives aux fonctionnalités que doit remplir le système. Les exigences non fonctionnelles concernent les paramètres du système tels que la performance, la sûreté de fonctionnement, l'intégrité et la disponibilité. Le cycle en V est une méthode classique de développement de système définissant une succession d'étapes allant de la définition du système jusqu'à sa validation. Un cycle en V, tel qu'illustré à la figure 1, appliqué à la conception d'un système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application comporte les étapes suivantes. L'étape d'analyse fonctionnelle 11, permet d'obtenir une décomposition du besoin fonctionnel relatif à ladite application. La définition de l'architecture 12 définit les briques de base du système, leur agencement et la façon dont celle-ci sont coordonnées. Les deux étapes suivantes consistent à concevoir les composants matériels 13 définis par ladite architecture et les composants logiciels 14 à partir de la décomposition du besoin fonctionnel. L'intégration des composants logiciels aux composants matériels 15 consiste à assembler l'ensemble des composants élémentaires élaborés aux étapes précédentes pour former le système. L'étape suivante est la validation des exigences fonctionnelles 16. L'étape de validation des exigences non fonctionnelles 17 intervient à la fin du cycle de développement. Ce type de méthode de développement ne donne pas entière satisfaction parce qu'il n'existe pas de moyen de garantir dès les phases d'analyse et de conception du système que celuici réponde de manière prédictible aux exigences non fonctionnelles. Les constats sur ce type d'exigences sont faits lors de la phase de validation du système avec des risques et bien souvent des coûts de modifications plus ou moins lourds sur le produit. Une solution consiste à utiliser la simulation fonctionnelle. On procède alors, dès la phase de conception du système, à l'évaluation des caractéristiques non fonctionnelles du système grâce à la mise en oeuvre d'un modèle décrivant simultanément l'application et son implémentation sur 1 o une plate-forme d'exécution. Cependant, le modèle de simulation nécessaire peut s'avérer très pointu et très coûteux à développer. Une telle solution n'est pas viable économiquement lorsqu'elle est mise en oeuvre sur un système complexe. 15 L'invention vise à pallier les problèmes cités précédemment en modifiant la méthode d'analyse et de conception du système et en introduisant une étape supplémentaire de validation amont des exigences non fonctionnelles permettant de pré-valider la bonne conception du système en capitalisant sur des règles d'architectures. En utilisant l'invention, on peut 20 prouver dès les premières phases du cycle de développement que la conception du système est correcte au regard des exigences non fonctionnelles. L'invention permet donc d'optimiser les coûts de conception des systèmes par la détection au plus tôt des erreurs sur les exigences non fonctionnelles et par la capitalisation des règles d'architecture. 25 A cet effet, l'invention a pour objet un procédé de conception d'un système, ledit système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application, ledit système devant 30 répondre à au moins une exigence fonctionnelle et une exigence non fonctionnelle, comportant les étapes suivantes : une étape d'analyse fonctionnelle, permettant d'obtenir une décomposition du besoin fonctionnel relatif à ladite application, une étape de définition de l'architecture, une étape de conception de composants matériels selon ladite architecture, une étape de conception de composants logiciels à partir de l'analyse fonctionnelle, une étape d'intégration des composants logiciels aux composants matériels, une étape de validation de l'exigence fonctionnelle dudit système, une étape de validation de l'exigence non fonctionnelle dudit 1 o système, caractérisé en ce qu'il comporte, en outre, une étape de validation amont de l'exigence non fonctionnelle dudit système, précédant les étapes de conception des composants matériels et des composants logiciels. 15 Avantageusement, l'étape de validation amont de l'exigence non fonctionnelle comporte les étapes suivantes : la modélisation du besoin fonctionnel à partir de ladite décomposition hiérarchique, la modélisation de l'architecture selon des règles d'architecture 20 prédéfinies, l'allocation du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture, le calcul d'au moins un paramètre non fonctionnel à partir du 25 modèle fonctionnel alloué sur le modèle d'architecture, la comparaison du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels et composants logiciels, 30 si l'exigence non fonctionnelle n'est pas respectée, la définition d'une nouvelle architecture ou la recherche d'une nouvelle allocation du modèle du besoin fonctionnel sur le modèle de l'architecture. Avantageusement, le paramètre non fonctionnel calculé concerne la performance du système et comprend au moins un des éléments suivants : la charge de calcul d'un processeur, la consommation de bande passante d'un réseau, le volume mémoire consommé d'un processeur, le temps de traversé du système. Avantageusement, le paramètre non fonctionnel calculé concerne la sûreté de fonctionnement du système et comprend notamment l'application de jeux d'entrées provoquant des événements particuliers. Avantageusement, le paramètre non fonctionnel calculé concerne l'intégrité du système. Avantageusement, le paramètre non fonctionnel calculé concerne 15 la disponibilité du système et comprend notamment le taux de disponibilité de l'architecture. Avantageusement, ledit système est une plate-forme d'exécution et ladite étape de validation amont des exigences non fonctionnelles 20 comporte les étapes suivantes : la modélisation du besoin fonctionnel avec des chaînes fonctionnelles, lesdites chaînes fonctionnelles étant constituées alternativement de traitements et d'échanges, la modélisation de l'architecture avec un groupe de noeuds de 25 calcul reliés par des bus, chacun desdits noeuds de calcul comprenant des partitions, lesdites partitions étant subdivisées en tâches, l'allocation desdits traitements auxdites tâches, permettant d'obtenir un modèle fonctionnel alloué sur le modèle 30 d'architecture, le calcul d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison du paramètre fonctionnel calculé avec l'exigence non fonctionnelle,10 si l'exigence non fonctionnelle est respectée, la conception des composants matériels et logiciels, si l'exigence non fonctionnelle n'est pas respectée, la définition d'une nouvelle architecture ou la recherche d'une nouvelle 5 allocation des traitements aux tâches. L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée et à l'aide des figures parmi lesquelles : ~o La figure 1 représente un procédé de conception d'un système selon l'art connu. La figure 2 représente un procédé de conception d'un système selon l'invention. La figure 3 représente les sous-étapes constituant l'étape de 15 validation amont des exigences non fonctionnelles. La figure 4 correspond aux sous-étapes de la figure 3 appliquées à un niveau plate forme d'exécution. La figure 5 représente un exemple de chaîne fonctionnelle. 20 Le procédé selon l'invention, illustré sur la figure 2, consiste à modifier la méthode d'analyse et de conception du système et à introduire une étape supplémentaire de validation amont 21 des exigences non fonctionnelles permettant de pré-valider la bonne conception du système en capitalisant sur des règles d'architectures. 25 La figure 3 représente les sous-étapes constituant l'étape de validation amont 21 des exigences non fonctionnelles. Lors de cette étape de validation amont 21, l'allocation 33 des besoins fonctionnels sur l'architecture est réalisée. Les règles d'architecture 35 paramétrées par les technologies employées 37 permettent de calculer la valeur des paramètres non 30 fonctionnels du système. Cela rend possible alors la vérification 38 de l'adéquation des paramètres fonctionnels calculés avec des valeurs attendues (i.e. les exigences). En cas d'écart, une remise en cause, soit des technologies employées, soit de l'allocation du besoin fonctionnel sur l'architecture permet dès cette phase de modifier la conception du système. L'étape de validation amont des exigences non fonctionnelles comporte les étapes suivantes : la modélisation 31 du besoin fonctionnel à partir de ladite décomposition hiérarchique 36, la modélisation 32 de l'architecture 37 selon des règles d'architecture prédéfinies 35, l'allocation 33 du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture, le calcul 34 d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture. la comparaison 38 du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels 13 et composants logiciels 14, si l'exigence non fonctionnelle n'est pas respectée, la définition 12 d'une nouvelle architecture ou la recherche d'une nouvelle allocation 33 du modèle du besoin fonctionnel sur le modèle de l'architecture. Le modèle fonctionnel est une représentation simplifiée d'une fonctionnalité comprenant simplement quelques caractéristiques de la fonctionnalité telles que la complexité, les données en entrée et en sortie (mais pas les algorithmes détaillés qui permettent de produire les sorties à partir des entrées). Ce modèle fonctionnel est différent des modèles fonctionnels de simulation qui décrivent la fonctionnalité elle-même de façon très précise. Les modèles de simulations explicitent le lien logique entre les données d'entrée de la fonctionnalité et ses données de sorties. Ce n'est pas le cas du modèle fonctionnel selon l'invention. L'architecture du système est conçue selon un style architectural qui est une loi auto-imposée définissant le comportement des briques de base du système ainsi que la manière dont elles coopèrent. Un des éléments clé du procédé selon l'invention est la formalisation du style architecturale par des lois régissant les paramètres non fonctionnels d'une architecture conçue selon ledit style. L'établissement des ces lois nécessite une connaissance préalable de l'architecture ainsi modélisée ou d'une architecture de référence similaire. Il est nécessaire d'avoir au moins une loi par paramètre non fonctionnel que l'on souhaite calculer : la performance la testabilité, c'est à dire la facilité à localiser les pannes et à tracer les exigences, l'intégrité, la disponibilité. L'ensemble de ces lois est appelé règles d'architecture. Les briques de base du système sont associées à une loi régissant un paramètre non fonctionnel. Le modèle de l'architecture selon l'invention est différent des modèles d'architecture de simulation. Les modèles de simulations spécifient précisément le comportement d'un composant. Ce n'est pas le cas du modèle fonctionnel selon l'invention où seules les lois régissant des paramètres non fonctionnels sont prises en compte. Le calcul du paramètre non fonctionnel est réalisé à partir des caractéristiques synthétiques du modèle fonctionnel et des lois régissant le paramètre non fonctionnel associé à un composant de l'architecture. Ce calcul est différent d'une simulation qui génère, à partir de scénarios d'exécution, une exécution d'un modèle d'une application logicielle sur une architecture matérielle. Le calcul selon l'invention ne nécessite pas de scénario d'exécution. Généralement, on décompose un système en différents niveaux qui correspondent au niveau de détail qu'on apporte à la description des composants du système. Le premier niveau décrit l'agencement du système en sous-système. Le second niveau décrit le regroupement de plate-formes d'exécution en sous-systèmes. Le troisième niveau décrit comment les plate-formes d'exécution sont constituées de plate-formes informatiques. Le dernier niveau concerne les plate-formes informatiques constituées de carte et de modules électroniques. Le procédé selon l'invention peut s'appliquer à tous les niveaux de la conception d'un système. Par exemple, à un niveau plate-forme d'exécution, il existe des lois décrivant la charge de calcul d'un processeur, le taux d'occupation d'un 35 bus ou le temps de réponse d'une fonction. Dans l'exemple décrit ci-après, donné à titre non limitatif, le procédé selon l'invention est appliqué au niveau d'une plate-forme d'exécution. L'étape de validation amont des exigences non fonctionnelles, 5 illustrée par la figure 4, comporte alors les étapes suivantes. La modélisation 41 du besoin fonctionnel est réalisée par l'identification de chaînes fonctionnelles' à partir d'une décomposition fonctionnelle 46. La décomposition fonctionnelle est obtenue lors de la phase d'analyse fonctionnelle par raffinement progressif des comportements io fonctionnels et par l'identification des traitements élémentaires contribuant à la réalisation de la fonction. On suppose que l'analyse fonctionnelle a permis d'identifer une décomposition fonctionnelle comprenant quatre fonctionnalités élémentaires F1, F2, F3 et F4. La modélisation du besoin fonctionnel consiste alors à associer à chacune des fonctionnalités élémentaires un traitement, à 15 définir un ordre sur les traitements ainsi définis et à relier les traitements par des échanges. L'ensemble formé par la succession des traitements et des échanges est appelé chaîne fonctionnelle. La figure 5 illustre la chaîne fonctionnelle obtenue à l'issue de la phase de modélisation. Elle comprend quatre traitements T1, T2, T3 et T4 51 20 et des échanges 52. Un traitement 51 comprend : une complexité, une loi d'activation et des modes. La complexité d'un traitement est définie par rapport à un étalon, par exemple un benchmark de référence tel que dhrystone ou whetstone. Dans le domaine aéronautique, on peut utiliser des benchmark plus spécifiques tels que MIPS-AIR 25 Une exigence non fonctionnelle telle qu'une exigence de temps de réponse se traduit par une valeur de temps de traversée d'une chaîne fonctionnelle. Dans cet exemple, on cherche à satisfaire l'exigence suivante : la chaîne fonctionnelle définie par les traitements et les échanges précédents 30 doit être traversée en 100 millisecondes. La modélisation 42 de l'architecture 47 est réalisée avec des processeurs reliés par des bus, chacun desdits processeurs est divisé en partitions temporelles. Les partitions temporelles sont utilisées pour répartir 35 les temps d'exécution des applications sur les processeurs. On peut, par exemple, imposer qu'un processeur exécute une première application la moitié de son temps et une seconde application l'autre moitié de son temps. Les partitions temporelles sont subdivisées en tâches de calcul. La modélisation de l'architecture est réalisée avec des règles d'architecture. A ce niveau, les règles d'architecture définissent le nombre et la taille des tâches dans chacune des partitions. Dans notre exemple nous utilisons une architecture 47 comprenant un processeur Proc, disposant d'une partition temporelle Par,, subdivisée en 6 tâches de calcul : A,, A2, A3, A4, A5 et A6. Ces tâches sont 10 définies de la façon suivante : La tâche A, est la tâche de priorité maximale et est activée cycliquement à 50 Hz. Les tâches A2, A3, A4, sont harmoniques en fréquence et en puissance de 2 de la tâche A, et de priorité décroissante 15 respective 25Hz, 12.5 Hz et 6.25 Hz. Les tâches A5 et A6 sont des tâches activées à la demande du logiciel hébergé par l'architecture et ont, pour A5, une priorité comprise entre A, et A2 et, pour A6, une priorité inférieure à A4 20 On définit deux règles d'architectures 45 s'appliquant à l'architecture définie précédemment. La première règle d'architecture impose que les communications entre les tâches sont telles que la latence maximale d'une communication entre deux tâches est égale à la période de la tâche périodique de priorité 25 supérieure ou égale à la tâche destination sauf pour les enchaînements de tâches aléatoires où l'on ne compte qu'une fois cette latence. La deuxième règle d'architecture impose que les temps de calcul sont masqués par les latences de communications si les tâches ne débordent pas de cycle de calcul. 30 L'étape suivante consiste à allouer 43 les traitements aux tâches pour obtenir un modèle fonctionnel alloué sur le modèle d'architecture. II existe de nombreuses allocations possibles. Le choix d'une allocation influence les paramètres non fonctionnels du système. 35 Une première allocation est décrite par le tableau ci-après. PROC1 PARI Al A2 A3 A4 A5 A6 complexité TI 2 x T2 1 x T3 3 x T4 1 x La première allocation consiste à exécuter TI sur A3, T2 sur A2, T3 5 sur A4 et T4 sur A6. Le calcul 44 de paramètres non fonctionnels à partir du modèle fonctionnel alloué sur le modèle d'architecture consiste à calculer la latence globale de la chaîne de traitement. Cette première latence globale LI est 10 égale à la somme des temps de calcul des traitements TI, T2, T3 et T4 et des temps de communications entre ces traitements. Le temps d'activation de TI est égal à une période de A3 dont la fréquence est 12.5Hz, soit 80ms. L'application de la deuxième règle d'architecture nous indique que 15 les temps de calcul sont masqués par les temps de communications. Donc les temps de calcul de T2, T3 et T4 sont ignorés pour le calcul de la latence de la chaîne fonctionnelle. Les temps de communications sont égaux aux périodes des tâches destinations soit respectivement 40ms (période de 25Hz), 160ms (période de 6.25Hz), et Oms (en effet, la latence de l'activation 20 de la tâche A6 est masquée par la latence de l'activation de la tâche cyclique A4 précédente de période 160 ms) respectivement pour les communications Ti - T2, T2 - T3, et T3 - T4. On a donc : L1 =80 ms+40 ms+160 ms+0 ms 25 On obtient une première latence globale LI égal à 280 ms. La comparaison 48 de cette valeur avec l'exigence fixée de 100 ms montre que l'exigence fonctionnelle requise n'est respectée. Il donc nécessaire de réitérer l'étape de définition de l'architecture 12 ou l'étape l'allocation des 43 traitements aux tâches. On définit une seconde allocation présentée dans le tableau 5 suivant : PROCI PARI AI A2 A3 A4 A5 A6 complexité TI 2 x T2 1 x T3 3 X T4 1 X La deuxième allocation consiste à exécuter TI et T2 sur A2, T3 sur AI et T4 sur A5. 10 En procédant à un calcul similaire au précédant, on trouve une seconde latence globale L2 pour la chaîne fonctionnelle égale à 100 ms. Cette valeur est conforme à l'exigence fixée. Ce calcul permet donc de vérifier que l'architecture choisie permet 15 d'exécuter l'application en respectant l'exigence en temps de réponse sur la chaîne de traitement. REVENDICATIONS 1. Procédé de conception d'un système, ledit système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application, ledit système comportant des plate-formes informatiques constituées de cartes et de modules électroniques, ledit système devant répondre à au moins une exigence fonctionnelle et une exigence non fonctionnelle, comportant les étapes suivantes : une étape d'analyse fonctionnelle (11), permettant d'obtenir une décomposition du besoin fonctionnel relatif à ladite application, une étape de définition de l'architecture (12), une étape de conception de composants matériels (13) selon ladite architecture, une étape de conception de composants logiciels (14) à partir de la décomposition du besoin fonctionnel, une étape d'intégration des composants logiciels aux composants matériels (15), une étape de validation de l'exigence fonctionnelle dudit système (16), une étape de validation de l'exigence non fonctionnelle dudit système (17), caractérisé en ce qu'il comporte, en outre, une étape de validation amont (21) de l'exigence non fonctionnelle dudit système, précédant les étapes de conception de composants matériels (13) et de composants logiciels (14), ladite étape de validation amont de l'exigence non fonctionnelle comportant les étapes suivantes : la modélisation (31) du besoin fonctionnel à partir de ladite décomposition hiérarchique (36), la modélisation (32) de l'architecture (37) selon des règles d'architecture prédéfinies (35), ladite modélisation de l'architecture étant réalisée avec des processeurs reliés par des bus, l'allocation (33) du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture,le calcul (34) d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison (38) du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels (13) et composants logiciels (14), si l'exigence non fonctionnelle n'est pas respectée, la définition (12) d'une nouvelle architecture (37) ou la recherche d'une nouvelle allocation (33) du modèle du besoin fonctionnel sur le modèle de l'architecture. 2. Procédé selon la revendication 1, caractérisé en ce que le paramètre non fonctionnel calculé concerne la performance du système et comprend au moins un des éléments suivants : la charge de calcul d'un processeur, la consommation de bande passante d'un réseau, le volume mémoire consommé d'un processeur, le temps de traversé du système. 3. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne la sûreté de fonctionnement du système et comprend notamment l'application de jeux d'entrées provoquant des événements particuliers. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne 25 l'intégrité du système. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne la disponibilité du système et comprend notamment le taux de disponibilité de 30 l'architecture. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit système est une plate-forme d'exécution et ladite étape de validation amont (21) des exigences non fonctionnelles comporte 35 les étapes suivantes :la modélisation (41) du besoin fonctionnel avec des chaînes fonctionnelles, lesdites chaînes fonctionnelles étant constituées alternativement de traitements (51) et d'échanges (52), la modélisation (42) de l'architecture (47) avec un groupe de noeuds de calcul reliés par des bus, chacun desdits noeuds de calcul comprenant des partitions, lesdites partitions étant subdivisées en tâches, l'allocation (43) desdits traitements auxdites tâches, permettant d'obtenir un modèle fonctionnel alloué sur le modèle 1 o d'architecture, le calcul (44) de paramètres non fonctionnels à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison (48) du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, 15 si l'exigence non fonctionnelle est respectée, la conception des composants matériels (13) et logiciels (14), si l'exigence non fonctionnelle n'est pas respectée, la définition (12) d'une nouvelle architecture (47) ou la recherche d'une nouvelle allocation (43) des traitements aux tâches. 20