Discussion :

[Tristan Zwingelstein]

Je viens de découvrir OCL et l'intérêt énorme qu'il apporte pour spécifier les contraintes d'une application.

En faisant quelques recherches je n'ai pas trouvé de langages qui implémente clairement ce modèle.

Mon idée est d'avoir d'un côté ses objets métiers et d'un autre côté l'expression des contraintes sur ces objets (OCL).
A chaque contrainte on associe un exception qui est levée automatiquement lorsque cette contrainte n'est plus respectée dans lors d'opérations sur les objets métiers.

Mais peut être que ma vision des choses est fondamentalement mauvaise ?

[Hephaistos007]

Trois remarques à propos de ton problème :

- Il existe des frameworks orienté modélisation UML qui permettent de spécifier des contraintes OCL et de les vérifier.
- On peut toujours traduire les contraintes OCL dans un langage de programmation à l'aide d'assertions ou tout bêtement de portions de code bien placés. (si XXX alors exception)
- Sans parler d'OCL, il existe aussi des frameworks qui permettent de spécifier des règles métier dans un fichier à part, bien décorrélé des classes métiers.

[Tristan Zwingelstein]

il existe aussi des frameworks qui permettent de spécifier des règles métier dans un fichier à part, bien décorrélé des classes métiers.

C'est ça qui m'intéresse.
Des exemples ?

[Hephaistos007]

Je pense à JBoss Rules : http://www.jboss.com/products/platforms/brms/

[Vlade]

Il y a plusieurs besoin sur les contraintes mais en phase de modèlisation d'une application le plus simple est de tout à faire à la main.
Je veux dire que le modeleur/architect mets les contraintes directement dans l'UML et le développeur intégree celle-ci dans le code. C'est simple et ca marche vraiment bien
On peut par exemple crée sa classe, ses méthodes et écrire les contraintes directement dans le fichier du métamodel UML. Une fois que celle-ci est codée le développeur change à la main le statut de la contrainte dans le modèle qui se synchronize au niveau de tout le projet. Si on a 10 diagrammes ayant l'objet métier modéliser, en changeant l'information dans le metamodel cela le change aussi dans tous les diagrammes. Cette synchronization multi diagramme est vriament puissante car l'information est prise à la source du MOF et non dans le modèle du graphisme.
Si on défini au début du projet les mots clés qui siginifie contraintes résolue ou pas, alors juste en parsans le fichier xmi avec un editeur xml on regarde si les mots clés ont été tous résolue dans le modèle UML.
Le modèle UML est syncrhonisé en permanence avec les éditeurs, donc toute les informations du projets se trouvent dans un même fichier qui est parsable. Cette tracabilité à la main est vraiment plus facile que ce que j'ai vu et simplifie de manière importante la complexité unitile et non productive de certains outils de développement dédiés aux contraintes. Maintenant attention, il s'agit de contraintes de développement, et il faudra bien sure ajouter des contraintes de deploiment et dans ce cas les outils Jboss sont un choix judicieux.

Les outils de validations programatiques des contraintes créer sur le language OCL sont vraiment complexe a mettre en place et vu qu'il y a pas d'OCL officiel pour UML 2 défini par l'OMG, il vaut mieux le faire à la main en enrichissant directement dans le métamodel UML des informations ne modélisable en UML graphiquement.

[ego]

Je viens de découvrir OCL et l'intérêt énorme qu'il apporte pour spécifier les contraintes d'une application.

En faisant quelques recherches je n'ai pas trouvé de langages qui implémente clairement ce modèle.

Mon idée est d'avoir d'un côté ses objets métiers et d'un autre côté l'expression des contraintes sur ces objets (OCL).
A chaque contrainte on associe un exception qui est levée automatiquement lorsque cette contrainte n'est plus respectée dans lors d'opérations sur les objets métiers.

Mais peut être que ma vision des choses est fondamentalement mauvaise ?

L'utilisation des contraintes UML est plus complexe que tu imagines peut être.
Par exemple, il n'existe pas de typologie de contrainte et cependant cela est nécessaire. En effet, tu peux définir des contraintes qui exprime un calcul d'attribut dérivé ou une contrainte qui exprime une obligation sur la valeur d'un attribut ou sur l'existance d'un lien par exemple.
En fonction du type de la contrainte, celle-ci devra être "vérifiée" ou "calculer" à différents moments dans ton application. Par exemple lors de la création d'un objet (obligation) ou lors de la demande d'une valeur d'attribut (règle de calcul).
Tout ça pour dire qu'OCL ne fait pas tout, il faut ajouter des choses et avoir des règles de transformation pour exploiter à fond les contraintes UML.

[Tristan Zwingelstein]

tu peux définir des contraintes qui exprime un calcul d'attribut dérivé ou une contrainte qui exprime une obligation sur la valeur d'un attribut ou sur l'existance d'un lien par exemple.
En fonction du type de la contrainte, celle-ci devra être "vérifiée" ou "calculer" à différents moments dans ton application.

Dans l'absolu et au niveau programmation, même si cela peut paraître complètement aberrant niveau performances, ne peut - on pas imaginer la chose suivante :

- on écrit nos contraintes en dehors de nos classes métiers
- dès lors que qu'un objet est modifié on vérifie si toutes les contraintes sont respectées

?

[Hephaistos007]

Dans l'absolu et au niveau programmation, même si cela peut paraître complètement aberrant niveau performances, ne peut - on pas imaginer la chose suivante :

- on écrit nos contraintes en dehors de nos classes métiers
- dès lors que qu'un objet est modifié on vérifie si toutes les contraintes sont respectées

?

...

c'est ce que permet Jboss Rule ...

[ego]

Dans l'absolu et au niveau programmation, même si cela peut paraître complètement aberrant niveau performances, ne peut - on pas imaginer la chose suivante :

- on écrit nos contraintes en dehors de nos classes métiers
- dès lors que qu'un objet est modifié on vérifie si toutes les contraintes sont respectées

?

Ben non car contrainte ne veut pas dire "Qq chose à vérifier", cf. mon exemple d'une contrainte qui est une règle de calcul. Tu peux aussi avoir des règles de "Valorisation" qui exprime "l'espace des possibles" pour mettre une entité B en relation avec une entité A.

Prenons un exemple :

A ----->0..* B

tu peux exprimer une contrainte qui va dire si un A est bleu alors seuls les B rouge et vert peuvent être mis en relation avec un A.
Puis une autre contrainte qui dit si A n'est pas bleu, tous les B peuvent être mis en relation avec A.
Tu devras ici vérifier l'affectation des B à A