bienvenue
dans
la maintenance-multi-techniques

Vous n'êtes pas connecté. Connectez-vous ou enregistrez-vous

Les méthodes de modélisation des systèmes

Aller en bas  Message [Page 1 sur 1]

Admin


Admin
Les méthodes SADT et IDEF0

IDEF0 (Icam [Integrated Computer-Aided Manufacturing] DEFinition) est une méthode conçue pour modéliser les décisions, les actions et les activités d’une organisation ou d’un système. La méthode IDEF0 est dérivée d'un langage graphique bien établi : SADT (Structured Analysis and Design Technique) (Lissandre [94]). L’Armée de l’air des États-Unis a sollicité les développeurs de SADT pour créer une méthode capable d’analyser la perspective fonctionnelle d'un système. En fait IDEF0 n’est autre que SADT adaptée aux besoins du programme ICAM. Lors d’une modélisation fonctionnelle, SADT et IDEF0 cherchent à répondre aux questions suivantes (Vernadat [145]) :

Quelles fonctions sont mises en œuvre par le système ?

Quels objets sont traités par les fonctions ?

Quelles ressources sont nécessaires à l’exécution des fonctions ?

SADT et IDEF0 sont avant tout des langages de communication d’idées et utilisent donc une syntaxe simple : les boîtes représentent les activités et les flèches concrétisent la relation entre les activités. Plusieurs types de flèches sont utilisés par le formalisme, nous citons (figure 3.2 ) :

les entrées : représentent les objets (information ou matière) à traiter ou qui vont subir une transformation,

les contrôles : représentent les informations nécessaires à l’exécution de la fonction et qui ne subissent pas de modification.

les sorties : représentent les objets traités ou qui ont subi une transformation,

les mécanismes : représentent les moyens (ressources humaines et matérielles) nécessaires à l’exécution de la fonction.



Présentation D’IDEF3

La méthode IDEF3 a été proposée en 1992 pour remédier aux limites d’IDEF0 en matière de modélisation du comportement de l’entreprise. IDEF3 modélise les processus sous forme d’un enchaînement d’étapes, appelées unités de comportement. Ces dernières sont connectées entre elles par des boîtes de jonction (asynchrones ou synchrones). Les liens peuvent être de précédence, relationnels ou de flux d’objets. Une unité de comportement est une activité dans le processus, elle est représentée par une boîte rectangulaire qui contient le nom de l'unité et un numéro qui situe l'unité dans la décomposition hiérarchique du processus (figure 3.3).



Les boîtes de jonction sont des connecteurs logiques entre les unités de comportement servant à modéliser les processus. Elles peuvent être convergentes ou divergentes pour représenter deux flux qui se rencontrent ou qui se séparent. Elles peuvent être utilisées en mode synchrone ou asynchrone selon que les flux démarrent ou finissent au même moment ou non. Il existe trois types de boîtes de jonction dans IDEF3 : les connecteurs AND, OR et XOR. Le tableau 3.1 présente les boîtes de jonction avec leurs symboles et leurs descriptions.


Présentation du modèle de processus de CIMOSA

CIMOSA, acronyme de Computer Integrated Manufacturing Open System Architecture, est une architecture qui modélise des systèmes intégrés de production. Elle a été développée par le consortium AMICE (AMICE [9]) dans le cadre du projet ESPRIT. Cette architecture comprend un cadre de modélisation, une plate-forme d’intégration et une méthodologie d’intervention. CIMOSA (Vernadat [145]) considère que toute entreprise se compose :

d’un grand ensemble de processus communicants chargés de réaliser les objectifs fixés par l’entreprise;

d’un ensemble d'entités fonctionnelles (ou agents) réalisant les processus opérationnels en fonction de l'état du système.

De plus, la modélisation en CIMOSA repose sur deux principes fondamentaux. Le premier consiste à séparer clairement les fonctionnalités de l’entreprise et le comportement de l’entreprise. Le deuxième principe consiste à distinguer processus (les tâches à réaliser) et processeurs (les agents qui exécutent les tâches). CIMOSA distingue deux types de processus : le processus structuré et le processus semi-structuré. Le premier est un processus dont nous connaissons parfaitement la structure de contrôle (une procédure de test). Le deuxième type est un processus dont les étapes sont connues, mais dont le flux de contrôle n’est que partiellement connu (opération de maintenance corrective par exemple).

Dans les deux cas, le flux de contrôle est décrit au moyen d’un langage formel permettant l’écriture d’une séquence de la forme when (condition) do action, ce qui veut dire : lorsque l’ensemble des conditions est rempli alors faire les actions indiquées (Vernadat [145]).

Voir le profil de l'utilisateur http://maintenance.yoo7.com

Revenir en haut  Message [Page 1 sur 1]

Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum