Conditions d'inconsistance d'une allocation de ressources


o La classe de base
o Inconsistance sur le partage d'une ressource
o Inconsistance sur l'engagement conjoint de ressources dans une activité
o Inconsistance d'allocation sur un jeu d'activités
o Domaine de situations d'engagement inacceptable
o Conjonction de domaines de situations d'engagement inacceptable
Une allocation de ressources aux différentes activités d'un jeu candidat à l'exécution peut être inconsistante. Dans ce cas, la procédure d'allocation va tenter d'allouer un ou plusieurs sous-ensembles du jeu candidat, et ainsi de suite jusqu'à réussir à allouer un jeu (éventuellement réduit à une seule des activités du jeu initial) ou à échouer si aucune activité primitive ne peut recevoir d'allocation.

Il existe diverses causes d'inconsistance d'une allocation :
1) une ressource est allouée à plusieurs activités, alors que sa nature ne le permet pas. Par exemple, un ouvrier ne peut peut pas servir deux activités qui opèrent sur deux lieux éloignés.
2) une ressource est co-engagée avec une autre ressource dans la mise en oeuvre d'un jeu d'activités, alors que sa nature ne le permet pas. Par exemple, il est incompatible de faire utiliser tel instrument par un opérateur qui n'en a pas la compétence.
3) une ressource est allouée à une activité, alors que celle-ci l'exclut explicitement. Par exemple, une activité requiert exclusivement un modèle bien précis d'outil, et pas un autre qui aurait cependant la même fonction.
4) enfin, une allocation pourra être rejetée si et seulement si plusieurs parmi les causes ci-dessus sont conjointement observées.

Les classes d'entités qui permettent de modéliser ces situations sont, respectivement :
- ResourceSharingViolationCondition, pour les causes 1 et 2
; - ActivityInconsistencyCondition, pour la cause 3 ;
- ActivitiesResourcesInconsistentCommitment, pour la cause 4 ;

Ces classes reposent sur deux autres structures de données :
- OccurrenceDomain, pour modéliser un domaine de situations d'engagement inacceptable ou impossible d'une ressource. Par exemple, pour exprimer qu'une ressource R ne doit pas être engagée sur plus d'un lieu à la fois, on créera la structure {LIEU, >, 1} qu'on attachera à R.
- OccurrenceCrossDomain, pour modéliser une conjonction des situations définies ci-dessus.

C'est en fait toujours une instance d'OccurrenceCrossDomain qu'on attachera à une ressource, même si la conjonction ne comporte qu'un seul OccurrenceDomain.

Les contraintes sur les ressources sont attachées au système opérant (instance d'OperatingSystem, qui est un composant du système de production. cet attachement se fait par la valeur du descripteur ResourceConstraintList. Les éléments de cette liste sont les contraintes (des trois types) qui doivent toutes être satisfaites au moment où elles sont testées dans la procédure d'allocation.

Remarque : Il est inutile de faire figurer dans la liste une ActivitiesResourcesInconsistentCommitment A possédant comme élément une contrainte C d'un des deux autres types qui figure aussi elle-même dans la liste. En effet, si C est violée, l'allocation est rejetée quel que soit le résultat du test des autres éléments de A. Si C n'est pas violée, A ne l'est pas non plus. Dans les deux cas, la présence de A ne change pas le résultat de l'allocation.
Par exemple, la liste ResourceConstraintList {aric1(aic1, rsvc1}, aic1) peut se réduire eu {aic1}.


This page was generated with the help of DOC++.