Concepts du niveau CIM

Le diagramme (g. 3.2) présente les principaux concepts proposés dans le méta-modèle du niveau CIM. Comme le montrent ces diérents usages, chaque expert manipule des modèles composés de diagrammes et de contraintes. Pour autant les concepts manipulés par chacun des experts ne sont pas forcement disjoints. Si nous prenons le cas du concept BusinessObject, il sera utilisé par l'expert métier pour créer ses propres types d'objets mais il sera également utilisé par l'expert SI pour créer des objets liés au fonctionnement du PLM (par exemple les objets portant des modèles géométriques). A contrario, le concept d'AttrSystem sera manipulé uniquement par l'expert SI, car ils concernent les attributs systèmes des objets imposés par une application. Par la suite, nous montrerons que la distinction apparaît nettement mieux dans la dénition des contraintes.

Figure 3.2  Un méta-modèle pour les systèmes PLM

Les tableaux (tab. 3.1) et (tab. 3.2) récapitulent les principaux concepts de ce méta-modèle :

3.2. Méta-modèle du niveau CIM

Concept Description

Model Stéréotype représentant le modèle créé, il est com-posé de plusieurs éléments : classe d'objets, classe de liens (direct ou indirect), de cycle de vie et de droits utilisateurs.

BusinesObject Permet la représentation des classes d'objets (ob-jets manipulables) dans un modèle de données de type PLM avec leurs attributs. Par exemple PIECE, SOUS-ENSEMBLE ou PRODUIT. Il peut représenter par exemple un modèle CAO.

FunctionalLink Permet de décrire une relation directe entre deux objets (classe de lien), avec leurs attributs et la notion de père et ls. Par exemple un lien de type BOM entre un SOUS-ENSEMBLE (objet père) et une PIECE (objet ls).

Attribute Décrit les attributs d'une classe d'objets ou de liens et peuvent être de deux types : AttrSystem ou At-trSpecic.

AttrSystem Décrit les attributs systèmes d'une classe d'objets ou de liens, c'est-à-dire les attributs imposés par la solution PLM cible. Leurs dénitions ne sont pas modiables par les clients de la MOA. Par exemple : REFERENCE, DESIGNATION, VER-SION et REVIVER-SION.

AttrSpecic Décrit les attributs spéciques d'une classe d'ob-jets ou de liens, c'est-à-dire les attributs contrôlés par le client selon l'objet ou le lien. Par exemple : MATIERE, POIDS, TAILLE.

RelationalLink Permet de décrire une relation entre deux objets de manière indirecte, avec objet source et objet destination.

Concept Description

LifeCycle Permet la dénition d'un cycle de vie pour les ob-jets. Il est composé d'un ou plusieurs états et des transitions entre les diérents états.

LifeCycleState Décrit les diérents états possibles pour un ob-jet. Par exemple VALIDE, OBSOLETE, AP-PROUVE, BROUILLON ou PROTO.

Transition Décrit les diérentes transitions entre les états (avec un état source et un état destination). Par exemple de l'état INITIAL -> EN COURS DE VA-LIDATION ou INITIAL -> ABANDONNE et EN COURS DE VALIDATION -> VALIDE.

BusinessRule Permet de décrire des règles sur les objets et les liens (contraintes).

BusinessView Décrit la présentation des objets et des liens (vue objet ou lien) à l'utilisateur selon ses droits. OrganizationalUnit Utilisé pour dénir plusieurs groupes de personnes

dans la gestion des droits. Par exemple le groupe Bureau d'études ou Achat.

OrganizationalStructure Permet la création de niveau sous les groupes. Par exemple un niveau Administrateur BE et utilisa-teur BE dans le groupe bureau d'études.

Actor Décrit les acteurs intervenant sur le PLM (Admi-nistrateurs ou utilisateurs). Un acteur doit faire partie d'un OrganizationalUnit et d'un Organiza-tionalStructure

Table 3.2  Concepts organisationnels du méta-modèle pour les systèmes PLM

3.3 Caractérisation des modèles métier et d'exécution

3.3.1 Caractérisation du niveau PIM

La perspective PIM doit présenter les modèles décrivant le métier indépendamment de toutes plate-formes. Dans ce contexte, le modèle métier s'appuie sur la caractérisation de stéréotypes issus du modèle. Ainsi, le modèle obtenu devra être conforme au méta-modèle et représenter les concepts métiers qui sont manipulés dans l'entreprise. Le contrôle de la conformité du modèle est assuré par un ensemble de contraintes (exemple : tout objet métier doit posséder au moins quelques caractéristiques systèmes comme la référence, la désignation...). A ce niveau, le concepteur doit identier ses principaux concepts métiers et les liens entre ces concepts. Il doit par ailleurs caractériser les contraintes de conformité en associant chacun de ces concepts aux éléments du méta-modèle CIM. Cette étape consiste à enrichir ou de spécialiser un modèle PIM avec des concepts métiers standards. Par exemple, compléter un modèle avec des objets courants comme des objets documentaires

3.3. Caractérisation des modèles métier et d'exécution ou CAO (g. 3.3). Au nal, le niveau PIM doit permettre au concepteur de produire un modèle adapté aux besoins de l'organisation cible.

Figure 3.3  Exemple d'un modèle PIM conforme au méta-modèle PLM

Ce modèle est basé sur la standard édition du PLM Audros et a été construit grâce à un framework développé dans le cadre de nos travaux ; nous le présenterons dans le chapitre (cf chapitre 5), les détails étant décrits dans les annexes. Les éléments identiés par un quadrilatère correspondent à des classes d'objets et les relations entre ces objets correspondent à des classes de liens. Le PIM est un niveau de modélisation qui permet de mettre en ÷uvre des concepts métiers au sein d'un système PLM. Au niveau PIM, la modélisation n'est pas unique et peut évoluer avec le temps. Les concepts métiers dénissant les modèles de ce niveau caractérisent une terminologie métier contextuelle. Ici le sens contextuel implique un faible niveau d'invariance pour deux raisons :

 les concepts manipulés sont très spéciques d'un secteur d'activité.  les concepts manipulés sont évolutifs dans le temps.

La suite de la démarche consiste à construire un modèle PIM pour un système PLM correspondant à des besoins spéciques. Il doit correspondre à des éléments du méta-modèle et respecter toutes les contraintes. La construction du méta-modèle peut être réalisée par un éditeur graphique prévue à cet eet an qu'il soit plus facile et plus rapide aux concepteurs d'utiliser les concepts du méta-modèle. De plus, un éditeur graphique per-met une visualisation plus rapide et plus pratique d'un modèle. Ainsi, la transformation est implicite et est déterminée par les règles du module graphique. La construction du modèle est contrôlée, les règles implicites ne permettent pas de créer des éléments non dénis dans le méta-modèle source. En eet, il est seulement possible de créer des classes d'objets représentées par le stéréotype "BusinessObject" du méta-modèle (représenté par un rectangle sur la gure) et des liens entre ces derniers identiés par le stéréotype "Fonc-tionalLink" (représenté par une èche orienté sur la gure). Un modèle est donc construit en se basant sur les propriétés du méta-modèle CIM, de ce fait, il est conforme à celui-ci.

Cette démarche ne vise en aucun cas à restreindre la créativité lors de la modélisation mais au contraire à l'inscrire dans un cadre qui garantisse la conformité du modèle PIM avec les standards du PLM, bref à garantir sa cohérence en vue de son implémentation dans un outil PLM identié.