Contraintes sur les modèles et méta-modèles

La notion de contrainte a pour objectif de créer un cadre restrictif an de facili-ter le travail des experts dans la conception des modèles. Une restriction sous forme de contraintes, telle que nous la proposons, permet donc de dénir des règles spéciques qui ne peuvent être représentées par les capacités explicites d'UML. En eet, les restrictions standards d'UML sont liées aux relations entre les classes et à leurs multiplicités (cardi-nalités). Cette logique a du sens dans la mesure où la complexité se gère directement dans le contexte comportemental des classes (méthodes de classes, diagrammes d'activités et de séquences).

4.2.1 Une typologie des contraintes

Dans la mesure où nous avons plusieurs niveaux de modélisation diérents (CIM, PIM, PSM), il convient de distinguer les types de contraintes. Pour autant, nous pensons que la présentation par niveaux n'aide pas le concepteur, notamment lorsque les acteurs sont diérents (experts SI et experts métiers). Aussi, nous proposons une typologie des contraintes par usage, plutôt que par niveaux :

 Les contraintes de conformité : elles doivent garantir la conformité d'un modèle métier et d'un modèle PLM vis à vis de leurs concepts respectifs.

 Les contraintes de support : ces contraintes sont spéciques à la mise en ÷uvre d'un système PLM. Ce sont des contraintes sur les concepts intrinsèques au PLM (unicité, traçabilité...).

 Les contraintes métier : ces contraintes permettent d'exprimer sur les modèles des règles métier sur les classes ou les relations. Elles sont dénies par les experts métier. Les règles explicites catégorisées sont dénies sur les diérents niveaux de modélisation par le langage OCL [Warmer, 2003] [Cabot and Teniente, 2007]. La gure (g. 4.1) montre les points d'application de ces contraintes dans la démarche MDA [Kleppe et al., 2003].

4.2. Contraintes sur les modèles et méta-modèles Cette gure illustre le fonctionnement des contraintes dans notre démarche MDA. Les contraintes sont des éléments éditables par les diérents experts, à l'exclusion des contraintes dénies sur le méta-modèle. En eet, celles-ci ne sont modiables que par les administrateurs de haut niveau, car elles identient des concepts de conformité générique pour les systèmes PLM. Une modication de ces contraintes nécessite une régénération du module graphique pour la construction des modèles PIM. La présence des contraintes sur plusieurs niveaux enrichit le fonctionnement d'un framework utilisant la démarche MDA (cf chapitre 5). Eectivement, cette manière de fonctionner donne la possibilité aux experts d'ajouter leurs propres contraintes sur les niveaux PIM et/ou PSM. De plus, des contraintes peuvent être ajoutées sur les règles de transformation pour compléter les contraintes dénies sur les modèles. Elles peuvent également être utilisées dans les transformations pour la création de scripts de contrôle ou de codication.

4.2.2 Les contraintes de conformité

Les contraintes de conformité sont des contraintes dénies au niveau des concepts CIM. Elles doivent permettre de compléter, si besoin, les contraintes implicites (relations, multiplicités) de la structure du méta-modèle. Elles sont applicables pour tous les modèles qui seront créés. En eet, étant donné qu'une contrainte de conformité est dénie au niveau du méta-modèle, l'ensemble de ces contraintes doit être respecté lors de la validation d'un modèle conforme à ce méta-modèle. Elles représentent en quelque sorte les contraintes générales, c'est-à-dire des contraintes qui assurent une cohérence logique dans la mise en production des modèles, indépendamment des métiers. Nous pouvons par exemple citer quelques exemples de contraintes de conformité (tab. 4.2.2) :

Titre Description

C1 : Contrainte sur le modèle Il est impossible d'avoir deux BusinessObject ayant le même nom sur un même modèle. En eet, chaque BusinessObject est identié par son nom dans un modèle.

C2 : Contrainte sur les relations Les FunctionalLink doivent impérativement avoir un élément (BusinessObject) père et un élément ls.

Table 4.1  Exemple de contraintes de conformité

Ces exemples de contraintes de conformité sont implémentés avec le langage OCL :

 

contextModel

invBO_uniqueness : self.ListObject−>select(b1, b2 : BusinessObject | b1.name_object <> b2.name_object)



 

context FonctionnalLink

invFL_end : self.father .name_object −> notEmpty() and self.son.name_object −> notEmpty()



Listing 4.2  C2 : Vérication des extrémités des FunctionalLink

4.2.3 Les contraintes de support PLM

Les contraintes de support PLM sont établies par l'expert SI. Elles permettent de dénir un ensemble de règles qui caractérise le fonctionnement global du PLM. L'iden-tication des contraintes de support (tab. 4.2.3) permet de rendre les modèles métier transformables vers un modèle PSM. On peut distinguer deux sous-types de contraintes de support :

 les contraintes de support globales. Elles permettent de dénir des règles applicables indépendamment de toute plateforme, elles s'appliquent au niveau PIM.

 les contraintes de support locales qui sont spéciquement liées à une plateforme PLM.

Type Description

C3 : Contrainte globale Le lien de Composition (de type 'BOM') permet de relier des objets CAO. Les ex-trémités ne contiennent que ('père' avec 'ls') : (ASM,PRT), (ASM,ASM), PRT,ASMPRT), (ASM,ASMPRT) (ASM-PRT,ASM) et (ASMPRT,PRT).

C4 : Contrainte globale Le lien MiseEnPlan permet de décrire les mo-dèles référencés par le Plan CAO (de type 'DOC') et les extrémités ne contiennent que : (DRW avec ASM) (DRW avec PRT) (DRW avec ASMPRT)(DRW avec PLT).

C5 : Contrainte locale Chaque "BusinessObject" doit avoir exac-tement deux attributs système ("Syste-mAttr"), la référence et la désignation. Table 4.2  Exemple de contraintes de support

Dans le tableau suivant, nous présentons quelques extraits de ces contraintes pour un modèle d'une PME (dans le cadre du PLM Audros). Ces exemples descriptifs de contraintes peuvent être modélisés avec OCL.

 

context FonctionnalLink

invbom_link : self.link_type = 'BOM'

and (self. father .type = 'ASM' or self.father .type='ASMPRT') and (self.son.type = 'ASM' or self.son.type='PRT'