gratifiant > comp.* > comp.objet

Jogo (23/12/2011, 22h27)
Bonjour,

Deux petites questions dans le cas improbable où l'on des deux forums
serait encore habité (le suivi est sur fco).

J'en suis à l'analyse du processus métier. Je fais le diagramme de
classe des objets métiers. J'ai par exemple des ventes "privés"
auxquelles des clients s'inscrivent. Les ventes recouvrent certaines
activités (surf, neige, plongée etc...). Les clients sont eux aussi
répertoriés dans un certain nombre d'activités. Et bien sûr les clients
ne peuvent s'inscrire à une vente que si elle correspond à une activité
à laquelle ils sont inscrits. C'est cette dernière contrainte qui me
pose problème (et d'autres tout à fait identiques).

Première question : est-ce que je me prend la tête pour rien car à ce
niveau d'analyse, ce genre de contrainte n'a pas à figurer dans le
modèle ?

Je sais qu'en OCL cette contrainte peut s'écrire :
{ client.activité->intersect( vente.activité )->nonEmpty() }.

Le problème c'est le contexte. La seconde question est donc : comment
est-ce que je relie cette contrainte dans mon diagramme ? Pour
l'instant ma solution est de faire une note liée à l'association entre
client et vente (vu que c'est là que peut se faire la vérification).
Mais comme la contrainte implique 3 relations (et 3 classes), je me
demande si je ne dois pas la relier à 3 trucs (classes ou relations).

Voilà, merci déjà de lire ce groupe,
Wykaaa (23/12/2011, 23h52)
Jogo a écrit :
[..]
> Première question : est-ce que je me prend la tête pour rien car à ce
> niveau d'analyse, ce genre de contrainte n'a pas à figurer dans le
> modèle ?


Dans un processus métier on s'intéresse aux acteurs du processus et aux
services métiers composant ce processus. On utilise généralement des
diagrammes d'activités pour représenter les processus métiers. Un
processus métier est un orchestrateur de services métiers qui, eux, vont
appeler des méthodes des objets métiers.

Tu parles de l'analyse DU processus métier. Quel est-il ce processus.
N'y en a-t-il qu'un seul dans ton application ?
> Je sais qu'en OCL cette contrainte peut s'écrire :
> { client.activité->intersect( vente.activité )->nonEmpty() }.


Il semble ici que tu considères que activité est un attribut de Client
mais aussi de Vente. En fait Activité devrait être une classe dite
"d'association" ici entre la classe Client et la classe Vente. Ces 3
classes sont des objets métiers. Dans une architecture SOA, les objets
métiers ne communiquent pas directement entre eux mais passent par les
services métier du processus métiers dans le(s)quel(s) ils interviennent.
C'est donc à l'orchestrateur des services métiers du processus métier de
tenir compte de ces contraintes qui devraient être exprimées dans les
diagrammes d'activité représentant les processus métiers.
> Le problème c'est le contexte. La seconde question est donc : comment
> est-ce que je relie cette contrainte dans mon diagramme ? Pour
> l'instant ma solution est de faire une note liée à l'association entre
> client et vente (vu que c'est là que peut se faire la vérification).
> Mais comme la contrainte implique 3 relations (et 3 classes), je me
> demande si je ne dois pas la relier à 3 trucs (classes ou relations).


Je ne sais pas quel est ton processus métier, donc tout ce que j'ai dit
plus haut pourrait ne pas être juste dans ton contexte.

Est-ce que finalement "Vente" ne pourrait pas plutôt se transformer en
une méthode "acheter" de la classe Client, car un client achète une
activité (ou plutôt "s'inscrit à"). L'entreprise propose des activités
auxquelles les clients s'inscrivent.

Disposes-tu déjà de cas d'utilisation ou as-tu directement embrayé sur
l'analyse. C'est l'élaboration des cas d'utilisation qui est censée
lever ces éventuelles ambigüités. Les cas d'utilisation peuvent être
aussi mieux explicités, pour les plus compliqués, par des diagrammes de
séquences. Les diagrammes d'activités qui représentent les processus
métiers ne viennent qu'après.

En espérant t'avoir été utile avec ces points de réflexion.

> Voilà, merci déjà de lire ce groupe,


De rien.

Je suis assez désespéré de voir que ces groupes "objet" et
"développement" sont aussi déserts alors qu'ils devraient regorger
d'activité. Tous les concepteurs et développeurs sont-ils maintenant en
Inde, voire au Vietnam, comme je l'ai vu pour certaines applications Web ?
Jogo (07/01/2012, 16h51)
Merci beaucoup pour cette réponse rapide. Je n'ai malheureusement
toujours pas le temps de vous répondre longuement.
Discussions similaires