• Aucun résultat trouvé

2. HiLeS, un formalisme pour la Conception Système de Haut-Niveau

2.4 HiLeS : proposition d’un formalisme

2.4.7 Les représentations associées

Comme on vient de voir, les représentations HiLeS par niveaux de conception sont très riches. Nous verrons dans le chapitre 3 qu’elles permettent un premier niveau de vérification très intéressant. Cependant, cette représentation peut devenir très vite difficile de lecture pour le concepteur, et très certainement peut appropries pour certaines partenaires du projet. Il faut donc que notre sortie HiLeS propose d’autres formes de représentation compatibles entre elles. Nous suivons avec attention les réflexions en cours sur SysML™ dont on attend les résultats aux deux niveaux :

• Celui de la lecture structurale des spécifications textuelles.

• Celui, qui nous concerne, de la représentation des résultats de la formalisation de ces spécifications.

Il faudra, le moment venu, revenir sur cet aspect de la représentation, mais il y a trois types de ces représentations qui sont indispensables d’approfondir :

La représentation fonctionnelle hiérarchique :

N iv e a u 0 N iv e a u - 1 N iv e a u - 2 N iv e a u - 3 N iv e a u 0 N iv e a u - 1 N iv e a u - 2 N iv e a u - 3

Figure 2-7. Décomposition fonctionnelle représentée sous la forme d'un arbre du système.

C’est le résultat de l’application de l’approche « Top-Down ». On oublie les caractéristiques temporelles de HiLeS pour s’attacher à la seule décomposition fonctionnelle. Les fonctions et leurs interconnexions sont représentées à différents niveaux de complexité. Ces niveaux peuvent être caractérisés par le concepteur pour avoir une idée du fonctionnement global du système. Elle possède l’intérêt de pouvoir présenter toutes les fonctions élémentaires et de servir de base pour une première visualisation architecturale. Nous pouvons considérer que cette représentation purement

Chapitre 2 : HiLeS un formalisme pour la conception système de haut-niveau 43

instances les moins techniques d’appui pour une meilleure compréhension du système sans rentrer dans les détails.

La Figure 2-7 montre une représentation fonctionnelle hiérarchique. Les niveaux 0, -1, -2, etc., sont ceux de la décomposition hiérarchique du fonctionnement du système. Le concepteur peut estimer que sur cette forme brute toutes les caractéristiques structurales ne sont pas complètement illustrées. Il faut donc que HiLeS permette une certaine re-localisation hiérarchique des fonctions pour témoigner d’une cohérence technologique ou informationnelle.

La représentation architecturale :

Elle répond aux insuffisances de la représentation précédente. On fait évoluer, la

représentation fonctionnelle du système vers une hypothèse d’architecture opérationnelle grâce à l’agrégation et au regroupement des blocs élémentaires en blocs plus complexes que l’on va pouvoir :

Proposer selon une organisation de fonctions, dans la perspective de définir des composants plus conformes aux pratiques industrielles.

Définir et spécifier précisément toutes les entrées/sorties. Spécifier comme une fourniture multi-fonctionnelle,

Déjà cette représentation architecturale, par sa cohérence technique et opérationnelle doit permettre de formuler des hypothèses sur l’implémentation du système et sur les éventuelles actions ou activités nécessaires pour la réaliser :

Réutilisation : Si le bloc ou composant a été réalisé et validé auparavant. Achat : Si le bloc ou composant est un produit commercial.

Création/conception : Si le bloc ou composant n’existe pas ou s’il faut adapter

un produit existant.

Intégration : Si le bloc ou composant peut être le résultat de l’assemblage de

deux ou plusieurs blocs • La représentation « métier » :

La représentation fonctionnelle est intéressante car elle apporte la liste des fonctions initiales du système en descendant jusqu’aux fonctions élémentaires ou jugées telles selon le niveau d’abstraction souhaité. Elle est l’outil de base du concepteur. L’étape de représentation structurelle précédente est indispensable car elle permet au concepteur d’exprimer au plus tôt une version cohérente du système guidée par son expertise des domaines technologiques qui pourront être envisages dans la matérialisation ultérieure. Mais, pour être utile à la dynamique de projet, il faut aller encore plus loin et pouvoir recomposer ces fonctions pour en faire des blocs structurels

correspondants aux métiers que l’on souhaite solliciter. C‘est à dire, correspondants aux domaines

de compétence de chacun des fournisseurs pressentes dans la matérialisation. Cela suppose des découpages selon des partenariats stratégiques pour l’entreprise ou simplement des découpages techniques comme par exemple :

• Mesure et traitement de signal, • Automatismes,

• Actionneurs,

• Systèmes de surveillance, • Autres.

Evidemment, cette recomposition peut être diverse puisque l’on a encore le choix des technologies et le choix des fournisseurs. Elle va conduire à plusieurs représentations concurrentes.

Des choix devront être réalisés basés sur des considérations des experts ou des expériences antérieures. Le plus naturel sera de consulter les fournisseurs en faisant des lots que l’on

spécifiera à partir des spécifications générales et de la modélisation HiLeS. Cette consultation peut induire différentes hypothèses et permettre des choix plus judicieux en prenant compte des données complémentaires telles que les coûts et les délais. On voit que cette représentation « métier »

débouche aussi sur des questions de conduite de projet ou l’on va construire des scénarios multiples et sélectionner celui qui répond le mieux aux exigences du projet. Ces mécanismes de

sélection se feront à travers des critères combinant des caractéristiques techniques ou autres : délais, coûts, encombrement. C’est le modèle partagé déjà envisagé par [BEY04], [Yac04] [LW98] pour des applications au niveau de l’industrie de la construction de bâtiments.