Discussion :

[littleman]

Bonjour,
Mon niveau en UML se limite à 3j de formation qui sont déjà bien loin... J'ai écrit un intitulé simple que voici "Dans un société des tâches sont affectées à des personnes qui peuvent être des freelance ou des salariés. Une tâche n'est exécuté que par une seule personne. Les salariés travaillent dans des services (commercial, développement, design etc). Les tâches ne peuvent être affectées qu'aux personnes des services correspondant au type de tâche (ex : une livraison ne peut être affectée qu'à un commercial)."

Voici le shéma que j'ai fait

1/ Si salarié et freelance n'ont pas d'attributs ou de méthodes spécifiques est-il plus judicieux d'en faire des sous-classes plutôt que de les voir comme un attribut de la classe personne prenant ses valeur dans une autre classe "type de personne" ?
2/ Comment modéliser la contrainte "Les tâches ne peuvent être affectées qu'aux personnes des services correspondant au type de tâche" ?

Merci d'avance

[bruno_pages]

Bonjour,

il y a une ambigüité dans l'énoncé : il est dit que les salariés travaillent dans des services, par contre on ne sait pas ce qu'il en est pour les freelances, or c'est à priori necessaire à cause de la dernière phrase.

Si salarié et freelance n'ont pas d'attributs ou de méthodes spécifiques est-il plus judicieux d'en faire des sous-classes plutôt que de les voir comme un attribut de la classe personne prenant ses valeur dans une autre classe "type de personne" ?

s'il n'y a aucun traitement spécifique au statut de salarié ou freelance alors une propriété booléenne estUnSalarié est préférable.

Comment modéliser la contrainte "Les tâches ne peuvent être affectées qu'aux personnes des services correspondant au type de tâche" ?

la relation de Tâche vers Service est quelque peu abusive, le service correspondant à une tâche doit être calculé et non mémorisé, la réponse ne dépend pas directement de l'instance, mais de la valeur d'un attribut donnant le type de la tâche (livraison ..., qui est peut être donné par le libellé)

la contrainte peut être modélisée par une contrainte (!)
si tu gardes ta relation être affecté à, alors tu fais une contrainte entre elle et la relation travailler pour disant qu'elles ont la même valeur (représenté par une note reliée aux deux relations), ou une contrainte au niveau Tâche disant que self . être affecté à = self . effectuer par . travailler pour (représenté par une note reliée à Tâche, tu peux aussi utiliser des getters plutôt que directement les relations)
sinon il faut une opération définie sur Tâche retournant le service pouvant la réaliser et l'utiliser dans une contrainte équivalente à ce qui précède

[hegros]

1/ Si salarié et freelance n'ont pas d'attributs ou de méthodes spécifiques est-il plus judicieux d'en faire des sous-classes plutôt que de les voir comme un attribut de la classe personne prenant ses valeur dans une autre classe "type de personne" ?

Si tu fais de la conception alors tu pourras garder ce niveau d'abstraction...

2/ Comment modéliser la contrainte "Les tâches ne peuvent être affectées qu'aux personnes des services correspondant au type de tâche" ?

en uml2 il existe peut-être une façon de modèliser ce type de contrainte mais ne connaissant pas trop j'ai essayé de faire un schéma sans.

voilà le schéma


Ce qu'on voit c'est qu'il y a une boucle (d'une class on peut aller à toutes les autres grace aux associations). En Merise, mais là attention on est en UML, cela signifierait (la présence d'une boucle de contrôle) que tu as la possibilité d'un contrôle sur ce que tu fais. Autrement dis au moment de l'affectation tu pourras effectivement contrôler si le type de tache de la tâche à réaliser corresponds bien à un des types de tâche du service auquel est lié la personne...

[littleman]

Bonjour,
Merci pour vos réponses. J'ai un peu avancé de mon côté. Suite à la première remarque de bruno_pages il apparait en effet que les freelances bossent aussi pour des services chez nous...J'ai finalement fait pour l'instant une classe "type de personne" qui est associée aux personnes. Je reviens là dessus un peu plus loin. Pour mon problème de contrainte j'ai ajouté une note qui concerne certaines associations. Il y a bien des types de tâches, je parle par exemple de "tâche de livraison" et je pense qu'il sera judicieux d'en faire des sous-classes, certaines auront certainement un comportement spécifique. Il y a quelquechose qui est important pour nous, les tâches peuvent être découpées en sous-tâches et peuvent aussi être dans un état "en attente" (de la fin d'une ou plusieurs autres tâches). J'ai géré ces deux éléments nouveaux avec des associations dont j'ai oublié le nom. Réflexives ? Au final j'ai un schéma qui ressemble à ça :



Toute remarque est la bienvenue.

J'y vais bien sûr petit à petit, mon système est en réalité beaucoup plus gros mais quand j'aurais les bons réflexes ca ira mieux je pense. C'est pourquoi j'essaie de bien déterminer avec votre aide cette partie.

Il y a aussi quelquechose qui me cause pas mal de soucis. Ce que j'appelle type de personne, services peuvent pour moi être assimilé à des objets qui ont le même comportement, il s'agit de "catégories" qui permettent de ranger les personnes et aussi d'autre entités. J'ai construit en programmation fonctionnelle un back-office avec une seule gestion de catégorie et une seule gestion d'entités, les catégories et les entités sont définis dans des fichiers de configuration. Le but étant de pouvoir, selon les besoin des clients, faire des back-office avec N entités et P catégories le plus vite possible, tout étant configurable. J'imagine que UML est une phase de conception dans laquelle ce genre de considération n'a pas sa place. Est-ce exact ? Autrement dit je n'ai pas à créer de classe "catégorie" sur mon shéma. Ou alors devrait-il y avoir plusieurs schéma ?

Merci.

Ah oui, au fait j'ai utilisé bouml pour le diagramme, beaucoup plus pratique de dia.

[hed62]

s'il n'y a aucun traitement spécifique au statut de salarié ou freelance alors une propriété booléenne estUnSalarié est préférable.

Je préfère nettement une classe supplémentaire TypeDePersonne , pour le jour où un Vacataire arrivera
Idem pour les taches, tant que, comme dit Bruno, "il n'y a aucun traitement spécifique".

La grosse note au milieu des trois classes peut se gérer par une contrainte OCL
Un truc comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
context Tache:
inv : self.service_affectation in self.personne_affectee->services

Réflexives ?

da.