Proposition d’une architecture de plateforme de s-maintenance

 Introduction

Une plateforme de s-maintenance définit une nouvelle génération de systèmes de maintenance permettant la mise en action de la connaissance du domaine, élaborant de nouveaux services répondant à l’évolution des besoins des utilisateurs. Ces services prendront appui sur des fonctionnalités d’auto-apprentissage et d’autogestion pour supporter l’aide à la décision. Il existe un gap entre ce que fournit les plateformes de maintenance et ce que nous attendons des plateformes de s-maintenance. En effet, assurer des fonctionnalités auto-X (auto-apprentissage, autogestion, etc.), n’est pas faisable avec n’importe quelle plateforme. De plus, proposer des mécanismes de collaboration, partager les connaissances dynamiques, garantir une interopérabilité sémantique, nécessite une plateforme orientée connaissances (basée sur l’ingénierie des connaissances). Notre objectif peut s’exprimer donc par la question suivante : « Comment développer une architecture générique et agile capable de répondre aux caractéristiques d’une plateforme générique de s- maintenance ?». Dans la section 2, nous avons brossé une brève description des différentes méthodes de génie logiciel (IEEE, 2004) pour restituer la méthode que nous allons adopter pour proposer une architecture de plateforme de smaintenance. Parmi ces méthodes, l’architecture à base de composants (ABC22) semble le meilleur candidat pour conceptualiser et mettre en place une plateforme de s-maintenance en respectant sa définition. En effet la philosophie des ABC, est centrée sur l’intégration avec un accent particulier sur la sélection des composants qui correspondent aux besoins des intervenants (les acteurs des systèmes) (Mahmood & Lai, 2006). Ainsi le niveau d’abstraction fourni par ce type d’architecture, s’intéresse à la structure du système et non pas aux protocoles de communication et de déploiement. L’argument de choix concernant la méthode ABC est sa généricité qui lui permet d’être déclinée en d’autres types d’architecture comme l’architecture orientée service (AOS). Par conséquent, nous développons dans ce chapitre une architecture à base de composants pour une plateforme de s-maintenance. Pour la conception de ce système, nous avons choisi une méthodologie comportant deux phases principales, une de pré-analyse et une de conceptualisation. La phase de pré-analyse sera décrite dans la troisième section, et développera une étape d’identification et de définition des composants et de leurs fonctionnalités selon les exigences de la s-maintenance. La deuxième phase de conceptualisation concernerar la modélisation de l’architecture du système par la définition des relations ainsi que des interactions entre ces composants. La quatrième section se focalisera sur les fonctionnalités et les opérations liées aux composants sans rentrer dans les détails techniques de l’implémentation. Finalement, la discussion sur la possibilité d’implémentation et de mise en œuvre de cette architecture ainsi que la gestion des risques fera l’objet de la cinquième section. 22 CBA : Component Based Architecture en anglais. 66 Plateforme de maintenance orientée connaissances

Méthodologie adoptée 

Introduction

L’ingénierie des systèmes logiciels est une discipline dédiée à la conception, la mise en œuvre, et la modification des logiciels (Laplante, 2007 ). Ainsi cette discipline englobe différentes sous disciplines comme l’architecture, la conception, le développement des systèmes logiciels et d’autres (Abran, Moore, Bourque, & Dupuis, 2004). La sous discipline qui nous intéresse dans ce travail est la mise en place d’une architecture de système de smaintenance. L’architecture d’un système est un modèle conceptuel qui définit la structure, les comportements et d’autres vues d’un système (IEEE-SA, 2000). Selon Garlan, l’architecture logicielle d’un système définit sa structure de haut niveau, exposant son organisation brute comme une collection de composants en interaction. Une architecture bien définie permet à un ingénieur de raisonner sur les propriétés du système à un haut niveau d’abstraction. Les propriétés typiques de préoccupation incluent la compatibilité entre les composants, les fonctionnalités, la conformité aux normes, la performance, l’orchestration, et la fiabilité (Garlan, Monroe, & Wile, 1997). Ainsi, les détails privés et la mise en œuvre interne des éléments du système ne font pas parties de l’architecture (Bass, Clements, & Kazman, 2003). Une architecture est dite « bonne » si elle répond aux besoins et exigences des parties prenantes (surtout les utilisateurs), à leur satisfaction, ne viole pas les principes établis de l’architecture du système, et prend en compte les propriétés pertinentes permettant la maintenance, l’évolution, le développement, l’intégration, etc. (Pbworks, 2007).

Choix de la méthodologie

La conception de l’architecture a toujours joué un rôle important dans la détermination de la réussite des systèmes basés sur des logiciels complexes : le choix d’une architecture appropriée peut conduire à un système qui satisfait ses exigences et peut être facilement modifié quand de nouvelles exigences se présentent, par contre une architecture inadéquate peut être désastreuse pour le système (Garlan, Monroe, & Wile, 1997). En réponse à ce problème, un certain nombre des méthodes formelles pour représenter et analyser des conceptions architecturales ont était proposées. Ces architectures proposées sont classées selon la catégorie de leurs points d’intérêt que se soit la communication, le déploiement, le domaine ou la structure comme le montre le tableau 3-1. Tableau 3-1 Principaux domaines des styles architecturaux (Microsoft Patterns & Practices Team, 2009) Catégorie Styles d’architecture Communication Architecture orientée service [Service-Oriented Architecture (SOA)], Bus de message [Message Bus] Déploiement Client-serveur [Client/Server], N-Tier, 3-Tier Proposition d’une architecture de plateforme de s-maintenance 67 Domaine Conception dérivée par le domaine [Domain Driven Design] Structure Architecture basée sur les composants [Component-Based], Architecture orientée objets [Object-Oriented], Architecture en couches [Layered Architecture] De ces différentes méthodes, la démarche de développement d’une architecture à base de composants (ABC), qui est une branche du génie logiciel insistant sur la séparation des préoccupations en ce qui concerne les fonctionnalités du système, nous semble la meilleure candidate pour modéliser et mettre en place une plateforme de s-maintenance sachant que le développement d’une ABC est centrée sur l’intégration, tout en mettant l’accent sur la sélection des composants qui correspondent aux besoins des intervenants (caractéristiques de la smaintenance, utilisateurs de la plateforme et/ou applications intégrées dans notre cas) (Mahmood & Lai, 2006). En effet, l’architecture à base de composants (ABC) se focalise sur la structure du système, et permet ainsi de définir une vue globale et générique du systeme sans rentrer dans les détails de déploiement comme dans le cas de l’architecture Client/Serveur et ses dérivées.