Discussion :

[Mike888]

Salut !

Je bloque sur un schéma E-A. Si vous pouviez m'aider, ce serait sympa !!


Explication de mon projet :

Mon application sert (entre autre) à encoder des activités à des dates précises. Une activité est toujours liée à un type d'activité (il existe plusieurs types vu qu'il y a une multitude d'activités bien différentes).
Pour mener à bien une activité, il faut suivre une procédure spécifique à son type. Il y a donc autant de procédure que de type d'activité.
Une procédure est composée de tâche (qu'on peut comparer à des étapes).

Un exemple :

Je décide d'encoder une soirée Jazz pour le 31/12. On peut ranger cette activité dans le type "Animation musicale". Il existe une procédure "Animation musicale". Celle-ci contient les étapes suivantes (liste non-exaustive) :

- Design de l'affiche
- Impression de l'affiche
- Réserver une salle
- Recruter un barman
- ...

Mon problème est que je n'arrive pas à trouver la façon de lier l'entité "activité" avec l'entité "étape". Pour moi, il faut une entité intermédiaire "type" (mais celle-ci devrait contenir tous les IDs des étapes qui lui sont associées, et ça je ne sais pas comment le matérialiser)...


Merci d'avance !

[fsmrel]

Bonsoir,

il faut suivre une procédure spécifique à son type

Ce qui voudrait dire que pour un type d'activité il y a une et une seule procédure.

Il y a donc autant de procédure que de type d'activité.

Le "donc" est un peu prématuré. Voulez-vous dire que pour une procédure il y a un et un seul type d'activité ?

Merci d'être précis et d'utiliser une représentation graphique, Merise ou Chen ou IEF ou UML, ou ce que vous voulez pour exprimer les choses. Les dire en français induit forcément un certain flou qui empêche d'aller plus avant dans l'étude de votre problème.

[Mike888]

Merci d'avoir répondu !


En fait, je n'ai pas encore commencé de schéma avec un outil graphique parce que je n'arrive pas à voir qqch de clair dans son ensemble...

Sinon, il y a bien une et une seule procédure par activité. Mais une même procédure peut correspondre à plusieurs activités.


En gros :

Activité --- 1,1 --- O --- 1,N --- Procédure

[fsmrel]

Par une relecture attentive, vous noterez que ma question ne porte pas sur la relation Activité - Procédure mais sur la relation Type d’activité - Procédure.

[Mike888]

- A un type d'activité correspondra une et une seule procédure (qui sera toujours la même).
- Plusieurs activités différentes peuvent avoir la même procédure.

[fsmrel]

L'activité de modélisation ne peut laisser planer le moindre de doute : on a vu des mises de MCD à la poubelle du fait d'imprécisions et de règles non complètement exprimées.

Vous avez fait mention du concept de type d'activité : merci de mettre à niveau le graphique en conséquence, ou bien précisez que type d'activité et procédure sont synonymes et peuvent être fondus en une seule entité-type (Procédure par exemple).

En effet, quand vous écrivez

un type d'activité correspondra une et une seule procédure

on ne sait toujours pas si pour une procédure on aura un et un seul type d'activité ou plusieurs...

[Mike888]

Non, c'est tout à fait ça; ce sont des synonymes !!

Désolé pour le manque de précision de ma part !


Edit : Enfin, je peux pas vraiment dire que ce sont des synonymes, même si ça y ressemble très fort; le type d'une activité correspond à (induit) une procédure (une procédure étant tout simplement une succession de tâches).
Le type d'une activité n'est qu'un attribut d'une activité.

Je me rends bien compte que c'est fort difficile à exprimer en français; voilà pourquoi je n'avais pas encore créé de schéma dans mon 1er post !

J'en reviens donc à la case départ...

[JPhi33]

Bonjour à tous

Justement, revenons à la case départ :

Une activité est toujours liée à un type d'activité (il existe plusieurs types vu qu'il y a une multitude d'activités bien différentes).

Jusqu'à présent, ceci n'a pas été modélisé. Donc :

[ Activité ]--1,1----( a-un )----0,n->[ Type_activité ]

Pour mener à bien une activité, il faut suivre une procédure spécifique à son type.
Une procédure est composée de tâche (qu'on peut comparer à des étapes).

C'est vrai qu'il est très difficile de décrire formellement la composante statique d'un système d'information avec des règles rédigées en simple français. En l'occurrence il semble qu'on soit confronté à une confusion. fsmrel l'a bien senti en parlant de synonymes pour type d'activité et procédure. La confusion vient (apparamment) du manque de précision dans la définition du terme procédure. Ce manque de précision (ou manque de recul) sur la définition de ce terme conduit Mike888 à vouloir absolument faire de Procédure une entité. Et si ce n'était pas une entité ?

Revenons à la définition :
(1) Il faut suivre une procédure spécifique au type d'activité
(2) Une procédure est composée de tâches = Une procédure est un ensemble de tâches
(2) dans (1) ==> Il faut suivre un ensemble de tâches spécifiques au type d'activité

Cette déduction, qui exclut le terme procédure, se modélise :

[ Type_activité ]--1,n----( A )----1,n--[ Tâche ]

On peut assimiler l'association "A" au terme Procédure.
Mike888 compare les tâches à des étapes. La notion d'étape peut induire un ordonnancement que je traduis par un numéro d'ordre.

MCD :



JPhi33

[Mike888]

Voilà, je pense que JPHI33 a bien cerné la problématique !

Je faisais effectivement une confusion entre la procédure (qui n'est rien d'autre qu'une suite ordonnée de tâches à accomplir) et le type d'une activité.

• Sinon, dans ton MCD, l'association procédure apparaît en vert -> pourquoi ?
• Et à ce propos, cette association ne devrait-elle pas plutôt s'appeller "entraîne une procédure" ?
• Quel est le sens de mettre un attribut "n°" comme attribut de l'association "procédure" ? Cela voudrait-il dire que chaque fois qu'une tâche est liée à un type d'activité, on connaît sa place dans la séquence complète de la procédure ?...

Merci à vous 2 en tous cas !

[JPhi33]

• Sinon, dans ton MCD, l'association procédure apparaît en vert -> pourquoi ?

Parce que c'est plus joli ! Non, sérieusement, c'est pour faire une distinction entre les associations et les DF et CIF. Dans mon MCD, "a-un" entre Activité et Type_activité est une CIF (que je laisse en blanc).

• Et à ce propos, cette association ne devrait-elle pas plutôt s'appeller "entraîne une procédure" ?

Oui, pourquoi pas. MERISE préconise effectivement de nommer les associations par des verbes car une association traduit (généralement) une action. Au fil des modélisations, j'ai pris l'habitude de nommer les associations par des substantifs car :
- ce sont des objets de gestion au même titre que les entités
- dans le MLD elles se traduisent par des tables comme les entités
- ceci peut se faire sans perte sémantique

• Quel est le sens de mettre un attribut "n°" comme attribut de l'association "procédure" ? Cela voudrait-il dire que chaque fois qu'une tâche est liée à un type d'activité, on connaît sa place dans la séquence complète de la procédure ?...

Exactement. Mais je l'avais déjà dit dans mon précédent message...

Mike888 compare les tâches à des étapes. La notion d'étape peut induire un ordonnancement que je traduis par un numéro d'ordre.

... et tu le redis toi aussi

Je faisais effectivement une confusion entre la procédure (qui n'est rien d'autre qu'une suite ordonnée de tâches à accomplir) et le type d'une activité.

D'où le numéro d'ordre. Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
type_activite        tache                     numero_ordre
------------------   -----------------------   ------------
Animation musicale   Design de l'affiche       1
Animation musicale   Impression de l'affiche   2
Animation musicale   Réserver une salle        3
Animation musicale   Recruter un barman        4
Expo. de peinture    Contacter les artistes    1
Expo. de peinture    Design de l'affiche       2
Expo. de peinture    Impression de l'affiche   3

On devrait plutôt avoir des codes pour "type_activite" et "tache" (qui sont plus faciles à manipuler et moins gourmands en espace de stockage). Les libellés, c'est pour l'exemple.

Ce modèle présente la contrainte de ne pas permettre d'avoir plusieurs fois la même tâche pour le même type d'activité. Mais tes règles de gestion ne précisent rien à ce sujet.

JPhi33

[Mike888]

Merci merci merci pour toutes ces précisions !!!

Ce n'est qu'un premier jet parce que je n'ai pas bcp d'infos en main pour le moment... Ca devrait s'étoffer par la suite !

[Mike888]

Hello, c'est encore moi !


J'ai un petit souci de compréhension logique par rapport au schéma E-A de ci-dessus de Jphi33 (qui semble correct de prime abord).

En gros, à chaque type d'activité correspond une procédure avec des tâches prédéfinies et classées dans un ordre précis; ça, c'est ce que j'explique depuis le début.
Il faut savoir que cette procédure est un canevas de base; il doit être possible à tout moment de rajouter des tâches à ce canevas pour une activité précise.

Exemple :

Activité :

• Un concert de Jazz

Type d'activité:

• Animation musicale

Canevas prédéfini pour ce type d'activité:

• contacter le graphiste et l'imprimeur
• sonorisateur,sécurité,croix rouge, police
• louer piano, matériel
• déposer matériel chez le graphiste
• agenda de spectacle,l'agenda,le vif,les mensuels
• déposer les affiches chez l'imprimeur
• autorisation voiture émettrice
• réaliser les tickets d'entrée
• etc...

Et puis là, je décide de rajouter une tâche "louer une décoration style Louisiane" et l'intercaler entre la 3eme et la 4eme tâche.
Je dois donc créer une nouvelle tâche; mais je ne désire pas que cette nouvelle tâche se rajoute définitivement à la procédure (au canevas de base). Elle doit juste exister pour cette activité-là !

NB. Ceci dit, on pourrait imaginer aussi que l'appli permette de rajouter cette nouvelle tâche au canevas de base (ce serait une feature en plus).

Ma question est donc de savoir si le schéma ci-dessus est suffisant pour gérer tout cela !...

[JPhi33]

Il faut savoir que cette procédure est un canevas de base; il doit être possible à tout moment de rajouter des tâches à ce canevas pour une activité précise.

Ca, c'est une nouveauté !

Ma question est donc de savoir si le schéma ci-dessus est suffisant pour gérer tout cela !

Et bien, non ! Et ce n'est pas étonnant puisque les informations utilisées pour construire le modèle n'incluaient pas cette notion.

Tu poses deux questions :
- la gestion des types d'activités (canevas de base)
- la gestion des activités créées à partir d'un type

1) Gestion des types d'activités
Il s'agit de faire évoluer la liste des tâches d'un type d'activité. Parmi les opérations envisageables pour une activité il y a :
- ajout d'une tâche à la liste (pas forcément à la fin)
- suppression d'une tâche de la liste
- réorganisation (réordonnancement) de la liste des tâches

La question à se poser est : le MCD permet-il ces d'effectuer ces opérations ? La réponse est oui, mais pas de manière simple car il faut gérer la numérotation des tâches du type d'activité. Dans ton exemple, l'ajout de la tâche Louer une décoration style Louisiane en 3e position oblige à renuméroter les 6 tâches situées après. C'est le prix à payer pour avoir une "suite ordonnée de tâches".
C'est la même chose pour une suppression (bien que ce ne soit pas obligatoire) et pour un réordonnancement (qui est une succession de suppression/ajout).

Il est peut-être possible de trouver un système de numérotation qui n'oblige pas à mettre à jour le numéro des tâches d'un type d'activité (mais je n'y ai pas réfléchi dans l'immédiat).

2) Gestion des activités
Une activité a un type d'activité qui est le "modèle" (canevas) à partir duquel elle est créée. Mais elle présente des tâches supplémentaires par rapport au canevas.
Là, il y a 2 possibilités :
- soit on utilise le canevas comme cadre de référence
- soit on duplique le type d'activités pour créer l'activité

Ce n'est pas la même manière de voir les choses. Il y a des avantages et des inconvénients pour chaque possibilité. Mais les problèmes principaux viennent de la numérotation des tâches dans les deux cas.

Attention, si la différence entre l'activité et le canevas ne se limite pas à des ajouts de tâches, c'est plus compliqué.

JPhi33

[Mike888]

Merci de t'investir à ce point dans ma problématique !


En fait, je vais voir la personne qui est la base de la demande ce week-end; j'ai déjà préparé une liste de question que je lui soumettrai histoire d'y voir un peu plus clair (vu que c'est un peu brouillon pour le moment).

J'aurai donc des informations claires et précises d'ici une semaine !



Sinon, je n'ai pas compris le sens de ceci :

- soit on duplique le type d'activités pour créer l'activité

[JPhi33]

Merci de t'investir à ce point dans ma problématique !

Ce cas concret est très intéressant.

Sinon, je n'ai pas compris le sens de ceci :

- soit on duplique le type d'activités pour créer l'activité

En clair : une occurrence de l'activité est créée en recopiant une occurrence du type d'activité (y compris les occurrences de l'association Procédure). Ensuite on peut ajouter des tâches, en supprimer, les réorganiser, etc.

[hed62]

Pour moi cette problèmatique pourrait se résoudre ainsi :

1/ un certain nombre de tables sont fixes, et servent au paramétrage (elles peuvent évoluer, mais très peu souvent) : ce sont les types d'activités et les canevas. Il y a donc ces deux entités et la relation précédemment citées.

2/ d'autres tables sont 'classiques' et permettent de mémoriser les différentes procédures associées aux activités.

a/ Notamment, tu auras la table Activité, portant une clé étrangère vers la table Type d'activité, et une table ProcédureASuivre qui portera une référence vers chaque tâche et un numéro d'ordre. Le paramétrage te sers lors de l'instanciation, tu modifies les procédures, et tu le sstocke intégralement. (le + : facile de récupérer la procédure d'une activité donnée. Le - : gourmand en espace)

b/ OU : tu as toujours la table activité, avec une relation vers la table type d'activité (et par transitivité tu as le canevas de base) et tu mémorise uniquement les modifications à ce canevas. Cette table modification doit permettre de reconstruire la procédure finale.
Tu sotcke donc :
- le type de modification (ajout/suppression/ordonnacement)
- la tache concernée
- le numéro d'ordre désiré
(et peut être quelques aurtes colonnes, il faut creuser plus)
L'avantage est la légèreté en base, l'inconvénient est la complexité relative pour reconstruire la procédure à suivre.

J'attend les réactions des autres intervenants, pour que l'on creuse l'idée (cette idée, surtout le b/, est une suggestion, j'aimerais en débattre un peu)