Capture du besoin et expression des exigences 

Télécharger le fichier pdf d’un mémoire de fin d’études

Revue bibliographique

Une multitude d’approches ont déjà été développées dans la littérature pour faciliter les étapes de conception préliminaires. Quatre types de méthode de résolution de problèmes en conception sont présentés par KRYSSANOV et collab. [1999] :
— Essai-erreur
— Règles empiriques
— Analyse scientifique
— Méthodes de synthèse
La méthode d’essai-erreur appliquée à la génération d’architecture automatique prend beaucoup de temps de calcul car elle parcourt l’ensemble de l’espace des solutions. Ce type de recherche est impossible à mettre en place dès que la taille des bases de données devient trop importante. En supposant que toutes les solutions émanant des bases de données puissent être trouvées, elles ne permettront pas toutes de répondre aux besoins des parties prenantes étant donné qu’elles n’auront pas été générées à partir de ces besoins.
La méthode d’application de règles empiriques sur une base de données dans le but de générer des architectures candidates correspond à une méthode d’essai-erreur appliquée à un espace de conception réduit par les règles.
Les méthodes d’analyse scientifique sont des méthodes mathématiques reposant sur la logique, les statistiques ou encore la théorie des ensembles.
Les méthodes de synthèse sont une façon de traduire les besoins des parties prenantes en exigences sur le système à concevoir puis en solutions technologiques. Ces méthodes permettent aux architectes d’explorer de manière organisée l’espace des solutions en fermant au plus tôt des branches d’alternatives.
Les travaux présentés dans ce manuscrit portent sur l’application d’une méthode de synthèse car nous nous efforçons de transformer en alternatives architecturales un en-semble de besoins exprimés par des parties prenantes. Chaque besoin est transformé en exigences qui permettent de réduire l’espace de recherche. Une fois que l’espace de recherche est réduit à son minimum, alors une combinatoire sous contraintes est utilisée.

La représentation ou modélisation

D’après CAGAN et collab. [2005], lors d’un processus de synthèse, chaque élément constituant le système à concevoir doit être représenté : les fonctions, les objets technolo-giques, les connexions internes à l’architecture, etc… L’utilisation de modèles revient de facto à adresser le problème de représentation soulevé précédemment. Un modèle est un concept très souvent utilisé, mais sa définition générale est difficile à exprimer de manière non ambiguë. La meilleure façon de définir un modèle est de comprendre dans quel but il est utilisé. En effet, un système à concevoir peut être représenté par plusieurs modèles, avec pour objectif la capture de ses différents aspects. C’est pour cela que la première chose à faire lors de la définition d’un modèle est de préciser les aspects qui doivent être étudiés. Un modèle peut être plus ou moins formel mais doit toujours être non ambiguë dans sa définition. Pour ce faire, un langage de modélisation bien défini doit être utilisé pour décrire le modèle. Ce point de vue est partagé avec FAISANDIER [2015b]. Le guide de l’Ingénierie Système, ou The Guide to the Systems Engineering Body of Knowledge (SEBoK) définit deux types de modèles : descriptifs et analytiques. Un modèle descriptif détaille les relations logiques entre différents objets qui peuvent être hétérogènes, tandis qu’un modèle analytique décrit des relations mathématiques entre des variables d’un système. Un autre type de modèle, appelé hybride, peut aussi être décrit dans le but de définir des relations logiques et mathématiques dans une même perspective.
Passons maintenant en revue quelques outils ou méthodes de modélisation qui nous ont aidés à définir nos propres modèles architecturaux.
ZHENG et collab. [2016] décrivent un modèle d’interfaces pour la représentation des connexions entre les différents objets présents dans une architecture. Une interface est une classe décrite par quatre attributs : son nom, son type, sa configuration et sa désirabilité. Le nom assure l’unicité de chaque interface. Le type décrit une interface, comme par exemple une interface géométrique, un échange d’énergie, un échange de données ou une interface de contrôle. La configuration indique entre quels types d’objets une interface s’applique : en effet, on parle toujours d’une interface entre deux objets. Ces configurations sont : interface entre deux AO, interface entre un AO et un environnement, interface entre un AO et une interface, interface entre deux interfaces, interface entre une interface et un environnement. Les configurations présentées ci-dessus permettent la définition de trois types de ports qui sont : le port d’un composant, le port d’un environnement et le port d’une interface. Des règles de compatibilité permettent de vérifier que les connexions entre les différents objets sont possibles.
De leur côté, afin de gérer les interfaces, BONEV et collab. [2015] étendent la représenta-tion DSM avec la définition de plusieurs types de connexions entre les objets composant le système. Les objets composant le système sont de types hétérogènes et sont décrits comme étant : «Composant», «Type de composant», «Attribut» et «Contrainte». Ces objets sont liés par des liens de différents types décrits comme : lien entre composants, lien entre types de composants, collaboration entre composants, lien entre des contraintes et lien entre des attributs. Une collaboration entre deux composants existe quand des attributs de ces composants sont reliés par une contrainte.
Cette représentation prend le parti de créer autant de types de connexions que de types d’objets existants. Dans le présent manuscrit, les connexions ne sont autorisées que sur les ports. Les autres objets constituant nos modèles sont connectés entre eux car il s’agit d’attributs des ports connectés.
CHIKHAOUI [2013] présente d’autres outils de modélisation pour représenter énergéti-quement l’hélicoptère. Cette modélisation doit ensuite servir à analyser le comportement de l’hélicoptère d’un point de vue énergétique. Les langages de modélisation sélectionnés dans la thèse de CHIKHAOUI [2013] sont le multibond graph issu du bond graph décrit par OULD BOUAMAMA et DAUPHINTANGUY [2006] et la Représentation Energétique Macrosco-pique (REM). Ces deux langages sont principalement utilisés pour la modélisation et la simulation physique des systèmes. Dans notre étude, comme cela sera développé plus tard, nous ne traitons pas de simulation, mais de choix architecturaux. C’est-à-dire que les caractéristiques physiques du système ne sont pas des constantes, mais bien des variables d’état qui doivent être déterminées non pas à l’aide de simulations, mais à l’aide de règles de pré-dimensionnement. Lorsqu’on parle de simulation, le modèle à simuler est carré, ses paramètres dimensionnants sont déjà déterminés. Lors d’un pré-dimensionnement ou d’une optimisation, tous les paramètres dimenssionants ne sont pas déterminés. L’utilisa-tion des bond graphs, ou encore de la REM, ne s’avère peut être pas pertinent car ces deux outils sont plus utilisés pour de la simulation que pour du pré-dimensionnement.
La méthodologie bond graph permet la modélisation de systèmes mécatroniques du point de vue des échanges énergétiques. Chaque lien entre deux blocs est modélisé par une variable de potentiel et une variable de flux. Le produit de ces deux variables doit correspondre à une puissance.
De la même manière, le bond graph à mots, présenté par DAUPHIN-TANGUY [2010], re-présente le niveau technologique de la modélisation, avec chaque bloc qui représente une technologie simple. Ce niveau de représentation est intéressant car il permet une modélisation logique d’un système. C’est à dire se focalisant sur les sous-systèmes et leurs interconnexions.
D’un autre côté, les approches Ingénierie des Modèles, ou Model Based System Engi-neering (MBSE) mettent au centre des activités de conception les modèles et non plus la documentation. Durant les différentes phases de conception, il est nécessaire d’enrichir les modèles du système à concevoir. Chaque métier conçoit son propre modèle du système, mais, à la fin, un modèle global doit être construit pour simuler dans sa globalité le système à concevoir. BARBEDIENNE et collab. [2015] mettent en exergue l’apparition de langages spécialisés dans la transformation de modèle du type Modèle à Modèle, ou Model to Model (M2M) et Modèle à Texte, ou Model to Text (M2T). Ces langages permettent l’interopéra-bilité entre les modèles et la rédaction automatique de documentations pour faciliter les échanges entre les experts qui ont conçu les différents modèles. D’autres utilisations des M2M sont possibles, par exemple l’écriture d’un unique modèle devant être résolu par plusieurs solveurs différents. CHENOUARD et collab. [2008] utilisent un langage de modéli-sation nommé s-COMMA qui permet de créer des systèmes de contraintes à résoudre. Ces systèmes peuvent ensuite être résolu avec plusieurs solveurs sans aucun effort de réécriture car la plateforme s-COMMA se charge de réinterpréter les systèmes différemment suivant le solveur qui est utilisé. BARBEDIENNE et collab. [2015] présentent trois approches pour la conception d’une architecture au travers d’échanges d’informations entre un modèle logique, un modèle géométrique et un modèle physique. Les approches abordées dans ce papier peuvent sembler intéressantes mais les modèles ne sont malheureusement pas détaillés, ce qui limite la contribution de cet article.

Les éléments bibliographiques qui supportent la formulation du besoin

L’extraction du besoin des parties prenantes est une tâche importante de la conception d’un produit au sens large pour laquelle des méthodes ont déjà été développées comme le fait remarquer HAMIDA et collab. [2015] dans une analyse non-exhaustive des méthodes de modélisation fonctionnelle. La tâche de capture des besoins des clients est traitée grâce à des outils de l’ingénierie système, tels que des bêtes à cornes pour la méthodologie APTE, des formulaires pour aider à la formulation du besoin KROB [2014] et des études sur l’ensemble des cycles de vie que le système aura à supporter, ainsi que sur l’ensemble des parties prenantes auxquelles il aura affaire durant tous les cycles de vie. Ce dernier point peut être illustré par une méthode décrite par un regroupement entre l’Association Française pour l’Ingénierie Système (AFIS), l’Atelier Inter-Etablissements de Productique et Pôle de Ressources Informatiques pour la MECAnique (aip primeca) et un groupement d’enseignants de l’Education Nationale Française.
Récemment, beaucoup de nouvelles méthodologies de conception ont émergé de la com-munauté, comme celle de MHENNI et collab. [2014]. Cela est dû à l’apparition de nouveaux langages comme le UML et le SysML qui permettent de représenter des concepts com-plexes d’après les nouveaux standards de l’Object Management Group (OMG) et du Conseil International sur l’Ingénierie Système, ou International Council on Systems Engineering (INCOSE). Cet environnement favorable, même s’il n’est pas parfait comme discuté par HAMPSON [2015], permet aux groupes de recherche de présenter des processus de concep-tion innovants qui prennent en compte, ou pas, l’extraction des besoins comme CHAPON et BOUCHEZ [2009] ou MATAR [2013].
Le problème de l’analyse fonctionnelle a été régulièrement traité et différents ou-tils peuvent être utilisés pour capturer, transformer et décomposer les besoins et les contraintes en fonctions indépendantes de toute solution technologique. Néanmoins, il nous semble que les représentations fonctionnelles développées jusqu’à présent ne permettent pas une modélisation suffisamment normée, qui pourrait être utilisée pour de la génération automatique.
En effet, l’expression du besoin fonctionnel d’un produit à concevoir et, surtout, l’intégra-tion des fonctions dans un processus de traitement automatisé est un axe de travail difficile. Il est nécessaire de transformer des connaissances subjectives en éléments objectifs qui seront analysés et transformés par un ordinateur, comme cela est fait dans la thèse de HELMS [2012]. CHAKRABARTI et BLESSING [1996] présentent les résultats de plusieurs groupes de recherche travaillant sur la représentation et l’usage des fonctions dans la phase de concep-tion d’un produit. Il en ressort trois représentations fonctionnelles : la paire verbe-nom qui est la plus ancienne forme encore utilisée, la paire vecteur de ports d’entrée-vecteur de ports de sortie où les ports de sortie peuvent être de type énergie, matière ou information et la paire situation à l’entrée-situation à la sortie. Pour comprendre la différence entre ces trois représentations fonctionnelles, un exemple simple est proposé :
— Paire verbe-nom : Transformer de l’énergie électrique en énergie mécanique,
— Paire vecteur de ports d’entrée-vecteur de ports de sortie : Port électrique en entrée et port mécanique en sortie et
— Paire situation à l’entrée-situation à la sortie : Reçoit de l’électricité, donne de l’éner-gie mécanique.
Ces représentations doivent permettre de trouver facilement des correspondances entre les fonctions et les composants.
UMEDA et TOMIYAMA [1997] rappellent quelques modèles de représentations fonc-tionnelles dont le Langage de Représentation Fonctionnelle Causal, ou Causal Functional Representation Language (CFRL), présenté en détail par IWASAKI et collab. [1993]. Ce lan-gage permet les modélisations fonctionnelle et comportementale en parallèle. Chaque comportement est décrit par une Description de Processus Causal, ou Causal Process Description (CPD), qui représente une séquence d’évènements.
Cette définition fonctionnelle est complexe et ne correspond pas à ce que l’on attend d’une fonction, c’est-à-dire être décorrélée de tout objet. En effet, une fonction est définie par le triplet DF, CF, GF où :
— DF représente le composant technique qui a pour fonction F.
— CF représente le contexte dans lequel le composant doit fonctionner.
— GF décrit le but que la fonction doit atteindre.
Dans la modélisation que nous souhaitons utiliser, nous voulons totalement décorréler la solution technologique, de la fonction. C’est-à-dire que nous ne souhaitons pas utiliser une liste de technologies qui seraient liées à des fonctions et ensuite appelées dans des solutions pour répondre à une liste d’exigences représentant le système à concevoir. Nous souhaitons laisser libre tout le champ des solutions possibles, sans pré-orienter les solu-tions vers des architectures connues.
La méthode de modélisation des fonctions à l’aide des bond graphs, utilisée par l’outil Schemebuilder présenté par BRACEWELL et collab. [1992], est une méthode adaptée à la simulation énergétique, mais n’est pas autant adaptée à des systèmes échangeant des flux d’informations. Dans le présent manuscrit, nous aurons besoin de deux modèles architecturaux, l’un pour représenter les architectures logiques des solutions et l’autre pour faire l’analyse physique de ces dernières. La méthodologie bond graph est habituellement utilisée pour faire de la simulation multiphysique sur des systèmes causaux. Un système est dit causal quand ses sorties ne peuvent être déterminées avant ses entrées. Ce n’est donc pas l’outil idéal pour modéliser les deux vues qui nous intéressent, même si les éléments de langage illustrés par la figure 2.3 pourraient servir à décrire nos AO.
STONE et WOOD [1999] entreprennent avant HIRTZ et collab. [2002] une réduction de l’espace fonctionnel habituel en restreignant l’usage des mots et verbes anglais, pour éviter les ambiguïtés et la redondance des fonctions. La taxonomie ainsi décrite est issue de l’étude de plusieurs autres travaux afin de former une liste exhaustive mais minimaliste de fonctions. Cette réduction du vocabulaire peut permettre la transformation d’exigences textuelles en exigences logiques de manière systématique, surtout si elle est couplée à l’utilisation d’un canevas à respecter dans la construction des phrases, comme cela est préconisé par KROB [2014]. Ce canevas est le suivant : «Le système à concevoir» «doit faire quelque chose» «sous une certaine performance» «dans un certain mode de fonctionnement».
A l’aide de règles, des boîtes fonctionnelles peuvent être créées directement depuis des exigences textuelles portant sur de la transformation de flux, dans le même esprit que CHRISTOPHE et collab. [2009]. La différence dans cette publication est que les auteurs utilisent un dictionnaire de synonymes du Centre National de la Recherche Scientifique (CNRS) dans le but de modifier des fonctions qui ne seraient pas énoncées avec les verbes et flux déclarés dans la taxonomie de Hirtz. De par cette transformation, un ingénieur peut converser sans utiliser un langage dédié, grâce à un programme informatique, puisque les entrées non conformes au dictionnaire de Hirtz seront modifiées avant d’être traitées. Concrètement, cela revient à utiliser un logiciel qui réécrit automatiquement les fonctions renseignées par l’utilisateur à l’aide d’un dictionnaire de synonymes pour se rapporter à des fonctions connues par le logiciel de synthèse architecturale. KANG et TUCKER [2015] utilisent aussi la reconnaissance du texte pour associer une fonction à un système. Pour éviter le bruit dans la détection des fonctions, le texte descriptif des systèmes est nettoyé automatiquement en supprimant tous les termes de liaison. L’objectif est de quantifier les interactions fonctionnelles entre des modules réels représentant des sous-systèmes, à l’aide de la description des modules sous forme de textes. Cela permet de voir quels sont les sous-systèmes étant liés fonctionnellement.
BURGE [2013] explicite une méthode de modélisation fonctionnelle. Il traite de la mo-délisation de diagrammes de contexte, de la modélisation des échanges de flux entre fonctions, de la décomposition fonctionnelle classique et de l’utilisation d’un dictionnaire sur les ports. Ce dictionnaire, contrairement à celui proposé par HIRTZ et collab. [2002], définit en plus une grammaire, de manière à pouvoir composer de nouveaux ports à partir de ceux existants et de règles logiques. Le résultat de la décomposition fonctionnelle est un diagramme de flux entre des fonctions. Le diagramme de contexte permet de connec-ter, à l’aide de flux, le système à concevoir avec les éléments extérieurs, aussi appelés les terminaux. Il s’agit soit de sources, soit de récepteurs externes au système.
Une fonction est représentée à l’aide d’un langage basé sur une liste de verbes, de mots et de mots logiques et de règles de combinaisons possibles.
Après avoir été exprimées à l’aide d’un certain formalisme, les exigences fonctionnelles sont souvent décomposées en sous-fonctions pour être ensuite allouées à des solutions technologiques.
Une des méthodes de décomposition et d’allocation des exigences, fonctionnelles ou non, la plus utilisée est la méthode Functional Analysis Systems Technique (FAST) présentée par WIXSON [1999]. Cette méthode date des années 1960 et est largement diffusée dans la formation des ingénieurs français. Le FAST raffine une fonction principale en plusieurs sous fonctions jusqu’à ce que les fonctions de plus bas niveau ne puissent plus être décom-posées.
Certains groupes de recherche ont rajouté un étage dans cette décomposition fonctionnelle avec l’ajout d’une étape se focalisant sur les comportements du système. Ces méthodes de décomposition prennent l’acronyme Function Behaviour Structure (FBS) pour GERO [1990] ou Function Behaviour State (FBS) pour UMEDA et TOMIYAMA [1997].
Il est à noter, comme le rappellent UMEDA et TOMIYAMA [1997], que les deux méthodes sont indépendantes et que le FBS (Gero) de GERO [1990] ne prend pas en compte la notion d’état, nécessaire à la description des transitions entre deux états.
La méthode Requirement Function Behaviour Structure (RFBS) de CHRISTOPHE et collab. [2010] est une déclinaison du FBS (Gero), où une phase de passage entre les besoins et les fonctions est rajoutée. Les comportements de la structure instanciée sont comparés avec les comportements requis par les besoins exprimés. Si les deux ensembles de comporte-ments ne sont pas assez proches, la structure est rejetée.
L’Axiomatic Design décrit par PARK [2007], et créé par Suh dans les années 1990, est une méthode qui repose principalement sur deux axiomes.
Le premier est l’axiome de l’indépendance. Il annonce qu’une conception optimale s’ef-force de maintenir l’indépendance des fonctions. Cela veut dire que chaque fonction doit être réalisée par un système qui n’affecte pas la réalisation des autres fonctions.
Le deuxième axiome déclare que les flux d’information échangés entre les différents sys-tèmes doivent être minimisés. Cet axiome concernant les échanges minimaux entre deux sous-systèmes est une recommandation récurrente, qui apparait aussi dans RECHTIN [1991].
La méthode de « zigzagging », introduite dans l’Axiomatic Design, doit permettre une décomposition simultanée des fonctions et des solutions physiques. Cette décomposition oblige le concepteur à trouver pour chaque fonction de la décomposition fonctionnelle un système physique qui la satisfera. FAISANDIER [2015a] fait le même constat : à savoir que l’architecture fonctionnelle et l’architecture physique se construisent conjointement. Il est en effet clair que la concrétisation d’une fonction en un AO peut introduire un nouveau besoin fonctionnel lié à ce nouvel objet. Ce nouveau besoin induit doit être exprimé et peut conduire à la nécessité d’un AO supplémentaire afin de satisfaire la nouvelle situation.
Par exemple, JANTHONG et collab. [2010] utilisent le concept de « zigzagging » dans le cadre du raisonnement à partir de cas (Case Based Reasoning (CBR)), où des conceptions fructueuses sont réutilisées et adaptées par rapport aux nouveaux besoins. Les auteurs développent un processus d’adaptation en trois étapes : proposer, évaluer et modifier. Ce processus peut faire penser à la méthodologie RFBS de CHRISTOPHE et collab. [2010] où le comportement désiré est tout d’abord comparé avec le comportement souhaité et où, en-suite, des modifications sont apportées au système à concevoir si les deux comportements sont trop éloignés.
YUAN et collab. [2016] proposent une méthode de décomposition fonctionnelle au-tomatique, basée sur la décomposition de la fonction principale du système en effets fonctionnels, qui sont ensuite décomposés en effets physiques. Les fonctions sont représentées par des boîtes noires transformant des flux d’entrée en flux de sortie.
Les effets fonctionnels décrivent des changements qui s’opèrent sur les ports d’entrées, il y en a donc autant que de changements sur les ports d’entrées. Deux types de changements sont définis, les changements de type de flux et les changements de la valeur d’un flux. Par exemple, un changement de type de flux peut permettre la transformation d’un flux d’énergie électrique en un flux d’énergie mécanique et un changement de valeur d’un flux peut permettre une augmentation d’énergie mécanique.
Les effets physiques sont des principes de solution possibles et ils proviennent de la dé-composition des effets fonctionnels. Certains effets physiques induisent l’apparition de fonctions de support dans la décomposition fonctionnelle. Par exemple, l’effet physique de convection induit l’obligation d’avoir une source de chaleur à disposition.
GIAMPÀ et collab. [2004] utilisent une base de données générée grâce à l’étude des éléments standards de l’INTERNATIONAL ORGANIZATION FOR STANDARDIZATION [2005].
Tous les éléments ont été étudiés et les fonctions élémentaires correspondantes ont été groupées en neuf classes fonctionnelles qui sont : bloquer, placer, contenir, convoyer (de la matière ou du signal), dissiper, fournir, transformer, transmettre (de l’énergie) et employer. L’ingénieur d’étude sélectionne ensuite dans la base de données les fonctions qu’il sou-haite accomplir. L’objectif est de développer une grammaire fonctionnelle où des fonctions peuvent être reliées entre elles pour former un modèle fonctionnel. Ces fonctions sont représentées par une boîte noire qui comporte des ports de types énergie, force, matière et signal. Ces travaux sont intéressants car ils répondent à notre besoin de modélisation des exigences et des architectures logiques. Néanmoins, chaque fonction reste liée à certaines technologies, ce qui veut dire que, dès qu’une fonction sera demandée par l’utilisateur, une des technologies liées sera forcément présente dans la solution finale. Il ne pourra donc pas y avoir de combinaisons de technologies pour répondre à une fonction demandée si cela n’a pas été précédemment défini dans l’outil d’aide à la conception. Les travaux que nous présenterons dans le reste du manuscrit répondent à cette problématique de combinaison de technologies pour répondre à une fonction, sans pour autant avoir défini directement un lien entre l’AO et la fonction élémentaire.
CHIOU et SRIDHAR [1999] présentent la même méthode que GIAMPÀ et collab. [2004] quant à l’étude des éléments standards que l’on peut trouver dans la littérature, mais uniquement pour des blocs de construction de type « mécanisme ». Cela revient à dire que les seules données d’entrée et de sortie du problème à résoudre seront géométriques et cinématiques. Ces travaux aboutissent à la création de quarante-trois blocs de construction physiques de base, qui peuvent ensuite être combinés entre eux pour répondre à un besoin exprimé à partir d’un bloc de construction fonctionnel correspondant à une transformation de mouvement requise. CHIOU et SRIDHAR [1999] définissent trois types de mouvement : la translation, la rotation et le mouvement hélicoïdal qui est un mélange des deux précédents. Les blocs fonctionnels de base sont alors définis au nombre de cinq. Il s’agit des duets : translation/translation, rotation/rotation, translation/rotation, hélicoïdal/translation et hélicoïdal/rotation.
Trois niveaux de représentation sont introduits pour les blocs de construction. Le premier niveau permet la représentation du type de transformation de mouvement, ainsi que la différence d’orientation entre les axes du mouvement d’entrée et de celui de sortie. Le second niveau permet aussi la représentation du type de transformation de mouvement, ainsi que l’orientation des axes d’entrée et sortie des mouvements, mais de manière plus précise. De même, des informations sur la continuité, la linéarité, l’interchangeabilité et la direction des mouvements sont rajoutées à la représentation dans le second niveau. Le troisième niveau rajoute des informations sur les relations géométriques entre les axes d’entrée et de sortie et une équation de mouvement mathématique décrivant le comporte-ment des paramètres d’entrée et de sortie. La résolution d’un problème de conception de mécanisme est traitée en six étapes, qui permettent la décomposition du mécanisme requis en mécanismes de base existants, ainsi que la vérification des contraintes inhérentes aux mécanismes choisis lors de la décomposition. Après ces étapes, une liste d’assemblages possibles de mécanismes peut être exploitée pour de la simulation à l’aide du troisième niveau de représentation présenté plus précédemment.

Les éléments bibliographiques qui supportent la définition des ar-chitectures

L’architecture logique correspond à un assemblage d’AO qui sont des abstractions de systèmes réels. Une méthodologie doit permettre le passage des fonctions formatées exprimant le besoin à des alternatives d’architectures logiques répondant au besoin. La génération de l’architecture logique revient à la réalisation de deux tâches que l’on peut traiter de front ou distinguer. Il s’agit de la sélection des AO et de leur interconnexion. L’assemblage des AO peut être manuel, semi-manuel ou totalement automatisé à partir de données d’entrée judicieusement choisies.
Avant de pouvoir sélectionner des AO et, à fortiori, de pouvoir les connecter, il est nécessaire de les créer et de les trier par classes. PAILHÈS et collab. [2009] font le listing des méta-classes de composants existants. Ce travail est important si l’on souhaite travailler avec une méthodologie objet et profiter du concept d’héritage. Pour plus d’information sur l’héritage, merci de vous référer à cet écrit de SIMONS [2003]. Les classes mises en exergue sont les convertisseurs, les transmetteurs, les composants supports, les composants de liaison et les éléments de contrôle. Néanmoins, dans le présent manuscrit, les AO ne seront pas rangés par classes. Un rangement par classes permettrait uniquement de présenter la base de données de manière organisée, mais cela n’aurait aucun impact sur la résolution du problème de synthèse tel qu’il est défini et sera présenté par la suite.
Une possibilité pour créer l’architecture logique serait maintenant de faire une alloca-tion directe de fonctions de base sur ces AO. Cela permettrait, d’après une spécification donnée, de chercher la correspondance avec les fonctions de base. Ensuite, chaque fonc-tion de base étant liée à des AO, l’allocation serait directe. GERO [1990] affirme qu’un passage direct d’une fonction à une structure physique ne correspond pas à un travail de conception, mais à un simple choix sur catalogue. Ce choix sur catalogue peut faire penser aux méthodes de « case based reasoning ». Chaque prototype possible peut être rangé dans une base de données et indexé par les fonctions qu’il satisfait. Un prototype, d’après GERO [1990], est composé d’un ensemble de fonctions, de comportements, d’une structure et d’un ensemble d’équations qui forment les connaissances que l’on a du prototype et du contexte dans lequel il est utilisé. Un prototype, contrairement à une classe parente, dans la littérature de la programmation objet de SIMONS [2003], est un super conteneur qui contient plus d’information que ses instanciations. Cela permet de travailler à différents niveaux de granularité. Une classe fille est toujours plus détaillée que sa classe parente et donc, si l’on souhaite instancier un objet qui contient moins d’information que dans la définition de sa classe, il est nécessaire de volontairement laisser de côté les attributs qui ne nous intéressent pas. C’est exactement le même principe que pour le super conte-neur de SIMONS [2003]. GERO [1990] expose différents types de conception, la conception routinière, la conception innovante et la conception créative. La conception routinière est basée sur la réutilisation des prototypes dans leur mode de fonctionnement normal. La conception innovante est aussi basée sur la réutilisation des prototypes, mais dans un mode de fonctionnement inhabituel. La conception créative correspond à l’ajout de nouveaux prototypes ou la modification des prototypes habituels. Cette analyse ne semble pas prendre en compte les configurations innovantes, mais uniquement des modifications internes aux objets qui composent un système conçu. Or, il nous semble qu’une archi-tecture peut être considérée comme innovante si elle montre une topologie différente de celles habituellement observées comme le faisait déjà remarquer HENDERSON et CLARK [1990].
Une autre possibilité pour créer l’architecture logique serait d’allouer manuellement les fonctions émanant de la spécification aux différents AO de la base de données. C’est l’objectif de BRACEWELL et collab. [1992], qui offrent « une approche neutre technologi-quement » qui se concentre principalement sur les échanges de flux d’information et de puissance électrique et mécanique, à l’aide de la méthode bond graph. Le logiciel n’est pas une solution automatisée de génération d’architectures, mais il permet aux architectes de construire le modèle à la main, en cherchant les composants dans une bibliothèque triée par les types de ports. Sans cette génération automatique de toutes les configura-tions architecturales possibles, il n’est pas possible d’affirmer que la solution choisie est la meilleure.
DAVID F. WYATT [2011] oppose deux méthodes de génération architecturale. D’un côté, les méthodes informelles du type «brainstorming», qui ne peuvent pas être informatisés, et de l’autre, les méthodes formelles qui sont souvent en partie automatisées. Avec les méthodes formelles, des étapes de formalisation, de synthèse et d’interprétation sont à rajouter aux méthodes informelles. Le but est de donner à l’algorithme de synthèse une entrée formelle qu’il puisse comprendre, et ensuite de traduire sa sortie formelle en configurations compréhensibles pour les architectes. Notons que BONEV et collab. [2015] partagent la même vision que DAVID F. WYATT [2011] concernant les méthodes formelles et informelles. DAVID F. WYATT [2011] propose une méthodologie pour la conception architecturale. L’espace de conception est délimité à l’aide de contraintes exprimées sur le graphe architectural. La méthodologie prend en entrée une architecture générale qui est développée pour finir sur plusieurs configurations instanciées. Il est très difficile d’ap-préhender à la main une telle architecture généralisée. Pour vérifier sa consistance, il est suffisant de vérifier que toutes les architectures possibles peuvent être dérivées de l’architecture généralisée. Le problème avec cette affirmation est qu’il faut connaitre à l’avance toutes les possibilités architecturales que l’on souhaite obtenir. Cela peut avoir un sens si l’on veut seulement effectuer une analyse automatique et un tri entre toutes les architectures que l’on connait déjà et que l’on souhaite étudier. Autrement, si on souhaite générer des architectures nouvelles, l’exhaustivité n’est pas assurée. Un autre problème avec le processus décrit par DAVID F. WYATT [2011] est que la phase de conception ne commence pas par une expression fonctionnelle du besoin, mais directement par une architecture technologique.
Dans le monde des méthodes de génération formelles, CAGAN et collab. [2005] font la liste de quelques méthodes pour l’émergence d’architectures concurrentes. La généra-tion des configurations architecturales peut se faire à l’aide de techniques de recherche optimisées. C’est-à-dire qu’à chaque ajout de composant, le meilleur composant est sélectionné. Le problème de cette technique est qu’il n’est pas acquis que tous les meilleurs composants mis ensemble peuvent fournir la meilleure solution. De même, la sélection d’un meilleur composant se fait par rapport à un unique critère. Il est possible que, pour le même composant, un autre critère soit très défavorable et cause un comportement global hors de la spécification. Une synthèse à partir d’un arbre de décision permet d’obtenir toutes les solutions possibles à un problème. Le point faible de cette méthode est qu’il faut attendre d’atteindre la dernière feuille de l’arbre avant de pouvoir comparer deux solutions voisines. Une autre possibilité est de mettre en place des systèmes experts qui vont prendre des décisions à la manière des humains en fonction de la situation.
CORTELLESSA et FRITTELLA [2007], dans cet état d’esprit, introduisent le concept d’«anti-pattern», en opposition au concept de «design pattern». Un «antipattern» est un assemblage de composants architecturaux qui n’est pas souhaitable dans une architecture en opposi-tion au «design pattern», qui est un assemblage habituellement mis en place dans l’état de l’art. L’utilisation de ce type d’antipattern permet de ne pas contraindre une architecture avec des solutions éprouvées, mais d’assurer que les mauvaises conceptions passées ne se reproduisent plus.
Autrement, MAKKONEN et PERSSON [1994] proposent une méthodologie de synthèse à l’aide de la théorie des graphes et d’une grammaire. On peut parler de langage dans le cadre de la synthèse architecturale comme dans le cadre des langages humains. Les objets techniques élémentaires sont l’équivalent des mots, qui peuvent former des phrases, qui peuvent former des textes. De la même façon on peut former des chaînes à partir d’objets techniques, des arbres à partir des chaînes et aussi des forêts depuis les arbres. Ces assemblages d’objets techniques sont réalisés à partir d’un ensemble de règles fixes.
Une possibilité séduisante est de traiter les problèmes de synthèse à l’aide de contraintes qui pourraient être traduites mathématiquement. GADEYNE et collab. [2014] décrivent un espace de conception d’une synthèse assistée par ordinateur à l’aide de SysML et de contraintes écrites en Langage de Contraintes Objet, ou Object Constraint Language (OCL). Le modèle contient un objet «Système à concevoir» formé d’une agrégation d’objets «Composant». Les contraintes peuvent être de type architectural, avec des contraintes topologiques qui limitent les connexions entre composants et des contraintes dites mixtes car elles s’appliquent non pas à un composant, mais à l’assemblage, comme les contraintes d’interférences géométriques. D’autres contraintes prises en compte dans le modèle sont les règles de conception, ainsi que des contraintes dites statiques qui ne sont pas fonction de l’instanciation du système à concevoir. Par exemple, la taille globale du système peut être spécifiée comme une contrainte statique. Le modèle décrit dans ce papier permet aussi de définir des contraintes par scénario d’utilisation. Par exemple il est possible de spécifier une consommation de carburant différente pour chaque scénario. La dernière pièce du modèle présentée est la fonction objectif, sur laquelle sera joué l’algorithme d’optimisation. Le modèle ainsi décrit semble cohérent, mais il y manque une vue fonctionnelle. En effet, les contraintes décrites sont bien des exigences de performance ou de géométrie ou encore de pures contraintes, mais il n’y a pas de trace d’exigences fonctionnelles. Les composants étudiés sont uniquement de type mécanique car l’exemple porte sur des boîtes de trans-mission simples et non instrumentées. De plus, même si le modèle semble cohérent, il n’est pas supporté par un algorithme de synthèse et il manque l’exigence fonctionnelle pour balayer tous les aspects de l’espace des solutions. Dans ce manuscrit, nous décrirons des modèles dans le même état d’esprit que ceux présentés dans ce papier, mais aussi une méthodologie outillée qui permettra de prouver la véracité de nos modèles.
AL-HAKIM et collab. [2000] proposent une méthode de modélisation de systèmes mécaniques dans différentes configurations à l’aide de graphes logiques. Les boîtes de transmission à plusieurs rapports sont prises en exemple dans la publication. La repré-sentation présentée n’est pas adaptée à des systèmes mécatroniques car il n’y a qu’un seul type de flux possible entre deux objets. Or, un objet complexe possède différents types de ports et peut être connecté plusieurs fois. Les solutions logiques présentées sont uniquement des graphes Entrées uniques Sorties uniques, ou Single Inputs Single Outputs (SISO) et pas des graphes MIMO, requis dans la méthodologie présentée dans ce manuscrit. Néanmoins, la représentation de plusieurs configurations permet d’analyser une phase de « pause » du système ou de déconnexion d’un sous-système du reste du système. Il semble important, et même indispensable, de permettre l’étude des différents situations de vie du système à concevoir dans une méthodologie de synthèse architecturale. En effet, le comportement attendu du système est différent à chaque situation de vie et cela a un impact sur la sélection des sous-systèmes qui vont le composer.
VAN BEEK et collab. [2010] utilisent conjointement une décomposition FBS (Umeda) de UMEDA et collab. [1996] et une matrice DSM dans le but de faciliter la détection d’interac-tions entre des composants d’un même système et de définir des sous-systèmes. Faire cet exercice à la main est souvent difficile, voire impossible, car le risque est fort d’introduire des erreurs lors d’un remplissage manuel d’une matrice de grande taille. Repartir de la décomposition fonctionnelle permet de démarrer d’un état de modélisation avec peu d’éléments et donc de mieux gérer la complexité croissante lors de la décomposition du problème.
Dans le monde des méthodes informelles, des outils ont été imaginés pour guider les architectes. L’objectif est alors d’analyser l’existant pour proposer des solutions à divers problèmes de conception. YANG et collab. [2015] proposent un travail détaillé concernant la création d’une méthodologie d’aide à la conception basée sur la réutilisation de connais-sances sur les fonctions, les comportements et la structure de systèmes existants. Trois processus de conception reprennent treize flux de passage d’un espace à un autre. Il s’agit de la variation d’une conception, de l’adaptation d’une conception ou d’une toute nouvelle conception. Aucune méthodologie de synthèse automatisée n’est proposée, il ne s’agit que d’un système d’aide aux idées. La représentation des modèles est un mélange de la méthode IDEF0 du NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY [1993] et de la représentation boîte noire avec les entrées/sorties de type matière, énergie et signal définies par PAHL et collab. [2007].

Table des matières

1 Introduction 
1.1 Introduction du sujet de recherche, besoin industriel
1.2 Définition des concepts importants utilisés dans le manuscrit
2 Mise en perspective des travaux par rapport à l’état de l’art 
2.1 Revue bibliographique
3 Capture du besoin et expression des exigences 
3.1 Introduction du chapitre
3.2 Expression du besoin des parties prenantes
3.3 Transformation des besoins en exigences
3.4 Définition des ports du système
3.5 Exemple fil rouge
3.6 Conclusion du chapitre
4 La génération des architectures logiques 
4.1 Introduction du chapitre
4.2 Définition des ports de la base de données
4.3 Vue logique de l’AO
4.4 Les méta-architectures
4.5 Les occurrences des objets architecturaux
4.6 Les architectures logiques
4.7 La détection des isomorphismes
4.8 La représentation des architectures logiques
4.9 Exemple fil rouge
4.10 Conclusion du chapitre
5 Analyse des architectures physiques 
5.1 Introduction du chapitre
5.2 Vue physique de l’AO
5.3 La définition du modèle physique
5.4 La génération des modèles physiques
5.5 La résolution des modèles physiques
5.6 Exemple fil rouge
5.7 Analyse des architectures physiques
5.8 Conclusion du chapitre
6 Conclusion 
6.1 Implémentation de la synthèse automatisée
6.2 Apport scientifique
6.3 Pistes à explorer
Bibliographie

Télécharger le rapport complet