9.3 Démarche projet
9.3.2 Cadre de référence
Dans notre démarche, nous définirons les points suivants (Franck Darras et al., 2003b) : – les dimensions utiles pour notre cadre de référence,
– le cadre de référence et le placement des différents modèles,
– les différents mécanismes mis en œuvre pour passer d’un modèle à l’autre.
9.3.2.1 La base du cadre
La dimension du « degré de généralité » correspond au niveau de détail auquel on associe le modèle. Il y a trois niveaux : le niveau générique, le niveau partiel et le niveau particularisé.
146 CHAPITRE 9. CADRE DE RÉFÉRENCE
C’est la reconnaissance d’une démarche structurée dans la construction du modèle où il est possible de travailler par généralisation (du plus bas niveau vers le plus haut), ou par spé- cialisation (du plus haut vers le plus bas). C’est un mécanisme qui est un fondement de la démarche orientée objet, notamment avec les liens d’héritage ((Pierre Alain Muller, 1999)). La dimension de « l’abstraction » fait référence à l’utilisation du modèle en introduisant trois niveaux :
– le modèle de spécification qui définit les opérations à exécuter dans un contexte donné d’application, en termes d’opérations, d’informations, de ressources nécessaires, de res- ponsabilités et d’autorités sans aucune référence à des options ou des décisions d’implé- mentation ;
– le modèle conceptuel précise les opérations qui seront effectivement réalisées avec les entités de l’entreprise qui seront mises à contribution ;
– le modèle d’implémentation décrit les règles et les moyens pour exécuter les opérations en respectant les spécifications.
C’est une dimension qui est bien connue dans le domaine de l’ingénierie des Systèmes d’Infor- mation et qui est devenue familière aux praticiens de la méthode MERISE ((Hubert Tardieu et al., 1998)). Dans MERISE, les modèles de données et de traitement sont, en effet, déclinés en trois niveaux (conceptuel, logique, physique) qui correspondent aux trois niveaux ci-dessus. Un mécanisme de dérivation successive permet de passer du niveau le plus élevé au niveau le plus bas. Dans une approche orientée objet, c’est le mécanisme d’instanciation de classes qui permet de passer du niveau de spécification au niveau conceptuel.
9.3.2.2 Le cadre
La norme de modélisation d’entreprise CEN 40003 sert de cadre à notre proposition de concep- tion. Nous nous sommes limités à un plan formé par les bases citées ci-dessus, l’axe de géné- ralisation et l’axe d’abstraction, pour expliciter la démarche. L’axe des points de vue est pris en compte dans les diagrammes UML utilisés.
À partir de ce constat, nous avons défini notre cadre de référence comme le montre la figure fig. 9.8. Nous avons positionné sur les neuf faces de ce cadre nos modèles et nos applications. Nous retrouvons le modèle d’entreprise (particulier et spécification) en face du modèle de référence de l’application (générique et spécification).
Pour passer d’une face à l’autre, nous avons défini un certain nombre de mécanismes. Pour passer du modèle de référence au modèle d’entreprise, nous avons défini un mécanisme de spécialisation (a ) permettant la particularisation et la réduction du modèle de référence pour obtenir le modèle de l’entreprise cible. Si des trous fonctionnels sont détectés, nous avons défini le mécanisme d’extension (b) permettant d’étendre le modèle de l’entreprise vers le modèle de référence de l’application. Si ce cas se produit, nous avons défini le mécanisme (d ) permettant l’analyse, la conception et l’implémentation de ces trous fonctionnels.
Bien entendu, l’application logicielle a déjà été développée à partir du modèle de référence de l’éditeur en utilisant le mécanisme (c). Lorsque les modèles sont finalisés, nous pouvons les utiliser pour obtenir le Système d’Information de l’entreprise cible. Pour cela, la solution logicielle possède des paramétrages permettant de traduire un choix au niveau projet en une valeur au niveau du modèle, puis un (ou des) paramètre(s) au niveau applicatif.
Mais ce premier cadre de référence présente deux inconvénients :
– la démarche ne convient peut être pas à tous les types de PME/PMI pour des raisons de charge de travail en conception détaillée, il faut introduire une approche avec des solutions « pré-formatées » ;
– cette démarche ne met pas assez l’accent sur l’influence réelle de la modélisation d’entre- prise sur le modèle de référence, car le modèle de référence doit posséder une architecture proche de celle du modèle d’entreprise pour réussir à établir une communication par mise ne correspondance d’éléments similaires.
À partir de ce constat, nous avons décidé de modifier légèrement la représentation pour obtenir un cadre plus réaliste vis-à-vis de cette cible de clients.
9.3.2.3 Nouvelle proposition de cadre de référence
Dans ce cadre de référence (fig. 9.9), nous avons fait le choix de rajouter un niveau supplé- mentaire à la dimension d’abstraction. Nous avons nommé ce nouveau niveau « spécification métiers » car ce niveau se préoccupe plus particulièrement du fonctionnement stratégique, opérationnel ou organisationnel de l’entreprise.
Au niveau « spécification métiers », nous avons représenté uniquement les concepts de la modélisation d’entreprise, et à un niveau générique. Ces concepts influencent maintenant le modèle d’entreprise et le modèle de référence de la solution logicielle. Au niveau partiel, nous avons le modèle d’entreprise métier représentant une vision globale de l’entreprise et influençant la réalisation du modèle de référence. À ce niveau partiel, nous avons aussi autant de modèles d’entreprise que de typologies d’entreprise, que ce soit des entreprises de production ou des entreprises de services, des entreprises ayant une gestion point de commandes ou des entreprises ayant une gestion à l’affaire...
La démarche est maintenant la suivante :
– les mécanismes de spécialisation (a ) et d’extension (b) permettent de faire évoluer le modèle d’entreprise (niveau « spécifications métiers ») ;
148 CHAPITRE 9. CADRE DE RÉFÉRENCE
Fig. 9.9 – Notre second cadre de conception
– le mécanisme d’implémentation (d et c) permet de passer des différents modèles à une solution implémentée. Le mécanisme d’implémentation (c) permet le développement de l’application avant le déploiement auprès d’un client. Le mécanisme d’implémentation (d ) permet de développement des trous fonctionnels (§ 9.6), si nécessaire ;
– le mécanisme de paramétrage (e) permet de passer d’une solution logicielle au Système d’Information de l’entreprise.
Nous décrirons plus précisément ces mécanismes au moyen d’exemples dans une prochaine section (§ 9.5).