Discussion :

[killerbot]

Bonjour,

J'ai un projet à réaliser en langage C (programmation système) visant à illustrer la méthode kanban. Le but est de dire combien de produits on souhaite et les postes de travail (production) s'assureront de "produire" la quantité demandée. N'étant pas fort en programmation, c'est pourquoi je sollicite votre aide . L'objectif est d'utiliser les notions vus comme les processus/threads, les files de messages, les sémaphores, les mutex, etc...

D'après le projet, on a au moins 3 niveaux de production (postes amont ou aval, ca dépend comment on voit les choses). Chaque poste dispose de 2 containers et si j'ai bien compris, si l'un venait à se vider, alors on utilise le 2ème container mais on s'assuera d'avoir envoyer un message au fournisseur lui demandant de remplir le container vide.

J'ai pensé illustrer les postes de production par des threads, le message envoyé au fournisseur serait illustré par la file de messages, des sémaphores pour qu'un poste transmette la pièce au poste en amont dès lors que ses sous-postes aient terminé leur travail.

Qu'en pensez-vous ? Si vous avez besoin de précision, n'hésitez pas à me demander car j'ai moi-même eu du mal à comprendre l'énoncé au début.

Merci pour votre aide

[Flodelarab]

Bonjour,

Qu'en pensez-vous ?

C'est un programme en C. Ce n'est pas une question de programmation système sous linux. Si tu travailles aussi mal sur ton projet que tu choisis le forum sur lequel tu poses des questions, abandonne le projet tout de suite. Tu gagneras beaucoup de temps.

Tu demandes une opinion; tu obtiens une opinion.

Maintenant, c'est à toi de bosser. Reviens quand tu auras des points d'accroche.

Ou alors envoie un chèque pour rémunérer ceux qui bossent à ta place.

[killerbot]

Bonjour,



C'est un programme en C. Ce n'est pas une question de programmation système sous linux. Si tu travailles aussi mal sur ton projet que tu choisis le forum sur lequel tu poses des questions, abandonne le projet tout de suite. Tu gagneras beaucoup de temps.

Tu demandes une opinion; tu obtiens une opinion.

Maintenant, c'est à toi de bosser. Reviens quand tu auras des points d'accroche.

Ou alors envoie un chèque pour rémunérer ceux qui bossent à ta place.

En voyant ton message, j'aurai tendance à m'énerver mais j'vais rester calme !
"Qu'en pensez-vous ?" je faisais allusion à "J'ai pensé illustrer les postes de production par des threads..."
Ensuite, la matière pour laquelle j'ai ce projet énonce les notions de programmation système comme les processus (fork), les threads, les synchronisations (sémaphore, files de messages)....

Ou alors envoie un chèque pour rémunérer ceux qui bossent à ta place

Moi qui voulais de l'aide sur un forum, j'espère que les membres de developpez.net sont pas comme toi !

[Flodelarab]

J'espère aussi. Vive la biodiversité. Ça m'évitera de rencontrer trop de primo-postant comme toi

[AdmChiMay]

Ouaip, cela peut sembler vexant en première réponse, mais à la décharge de Flodelarab il faut dire que ta demande est assez similaire à d'autres : on ne voit pas de travail déjà fourni. D'où des réactions un peu tranchantes, mais malheureusement régulièrement compréhensibles.
Pour ma part, je ne suis pas spécialiste Kanban, et cela dépend de ta vision de la décomposition de la chose.

Je pense que si tu faisais (par exemple) un graphique avec le déroulement de la méthode, et ce qui se passe en cours de route (genre use-case), "on" (et "je" en particulier) y verrait plus clair. À partir de là, une autre explication (ou autre graphique) en plaçant les endroits où tu utilises thread, file, etc, serait déjà une première approche à partir de laquelle les spécialistes pourront donner leur avis sur l'organisation. Ensuite viendra le codage, et les questions techniques.
Je ne serai pas le spécialiste qui t'aidera, mais je reste optimiste sur le fait que tu as eu un problème de formulation (dvp n'est pas le sdz, en terme de lecteurs).

[edit] Je dis cela, car je sens le sujet avec du potentiel pour de futurs lecteurs : approche, analyse/décomposition, composants techniques. Alors reprends ta respiration et redémarre.

[killerbot]

Ouaip, cela peut sembler vexant en première réponse, mais à la décharge de Flodelarab il faut dire que ta demande est assez similaire à d'autres : on ne voit pas de travail déjà fourni. D'où des réactions un peu tranchantes, mais malheureusement régulièrement compréhensibles.
Pour ma part, je ne suis pas spécialiste Kanban, et cela dépend de ta vision de la décomposition de la chose.

Je pense que si tu faisais (par exemple) un graphique avec le déroulement de la méthode, et ce qui se passe en cours de route (genre use-case), "on" (et "je" en particulier) y verrait plus clair. À partir de là, une autre explication (ou autre graphique) en plaçant les endroits où tu utilises thread, file, etc, serait déjà une première approche à partir de laquelle les spécialistes pourront donner leur avis sur l'organisation. Ensuite viendra le codage, et les questions techniques.
Je ne serai pas le spécialiste qui t'aidera, mais je reste optimiste sur le fait que tu as eu un problème de formulation (dvp n'est pas le sdz, en terme de lecteurs).

[edit] Je dis cela, car je sens le sujet avec du potentiel pour de futurs lecteurs : approche, analyse/décomposition, composants techniques. Alors reprends ta respiration et redémarre.

Merci AdminChiMay pour ton message calme Je parlai évidemment du début (de l'approche et analyse/décomposition) pas de l'implémentation pour l'instant. Un graphique ? (Peut-être?) que celui-là ferait l'affaire ? : https://www.dropbox.com/s/8bb46o25bj...C3%A9.png?dl=0
Y a une demande (combien de produits souhaités) et la demande est transmise au postes qui débutent alors la production. Dans l'image on a Poste 1, Poste 2 et Poste 3. Dans chacun de ses postes, on a la même chose : prenons par exemple Poste1 : il a 2 sous-postes (Poste1a et Poste1b). Mais ces derniers disposent également de 2 sous-postes chacun

Avant d'aller plus loin, est-ce que c'est plus compréhensible ? N'hésite pas à me le faire savoir

[AdmChiMay]

C'est un pas en avant, je dirai.
Pour moi, Kanban est d'abord associé à "méthode agile". Je ne suis pas certain que ce soit ce dont tu parles.

Quoi qu'il en soit, il faut détailler ce dessin.

-- Trois niveaux de production, genre "amont-aval" : on voit les flèches, ok.
-- Tu parles de <1 poste ↔ 2 containers>, et là, je ne vois pas les deux bacs (containers) pour chaque "niveau".
-- Si un bac est plein, on commence à remplir l'autre : donc le poste précédent "livre" au point d'entrée du suivant, et ce point "d'entrée du suivant" vérifie qu'on s'adresse au bon bac, avec en plus une décision à prendre ("envoyer un message").

Avec un peu de recul :
-- un niveau reçoit dans deux bacs : ça ne snifferait pas la FIFO ?
-- le niveau receveur voit si le bac est plein : la file a donc une "longueur" maximum ? et il sait à quel niveau il doit envoyer un message pour dire file n°1 ou file n°2 ?

Cela donnerait :
- un lanceur (processus d'origine ?) démarre les niveaux, en précisant bien à chacun (thread ?) à qui il peut s'adresser et/ou recevoir des messages ?
- un niveau (thread ?) est créé, il doit savoir à qui envoyer ses livraisons (avec 2 adresses de livraisons ?), et surveiller ses livraisons entrantes, et à qui signaler (terme pas totalement au hasard) qu'il doit changer de bac (file ?).
Bon, avec tout ça, il y a bien un moment où tout cela s'arrête : quelles sont les conditions d'arrêt ? et donc celles d'initialisations de tout ce bazar ?

Tu reprends ton schéma à la main, tu le retravailles, et après soit tu le repostes soit tu en fais une description textuelle. Pour cela, tu remplaces tous mes "?" par des affirmations/choix à toi, que tu justifies selon ta vision.

Comme d'habitude : un papier, un crayon, et on tente de dessiner ce que l'on comprend du sujet. En y allant doucement (et avec une bonne analyse de texte du sujet), on arrive en principe à un bon début de solution. Je ne serai pas de passage avant tard demain, mais si tu es assez clair dans ta description de :
- ce qu'il y a comme éléments (voir "architecture" au sens large),
- quelles sont les règles de comportement de chacun,
- quel composant(s) informatique tu places pour chaque élément,
alors il y a de meilleures chances que d'autres aient matière à t'aider à continuer.