Discussion :

[stallaf]

Bonjour à tous,

Je vais tenter de concevoir un projet de gestion de stock en utilisant Qt.

S'appuyant sur des fichiers (pas de BDD), ce programme devra être capable de gérer des informations :
- sur les fournisseurrs (noms, coordonnées...) ;
- sur les articles de stock (noms, références, quantités, dates, prix .....) ;
- sur les commandes en cours ;
Ajouts, suppressions, modifications, recherches et tris de ces éléments seront au menu ainsi que le traitements de certaines données (totaux, moyennes ...).

Comment articuler et concevoir mes différentes données. Quelle type donner aux fournisseurs et/ou aux articles (structures, listes...) ?
Merci d'avance pour votre éclairage.

[koala01]

Salut,

Tu dois normalement voir ton problème sous trois axes principaux (et pas forcément dans l'ordre indiqué ):

• La partie qui concerne la persistance des données (le fait de pouvoir les récupérer au départ de ton / tes fichiers)
• La partie qui concerne la gestion de tes données (que se passe-t-il si je sors un produit du stock, ou si je rajoute un fournisseur ou une client )
• La partie qui concerne "l'ergonomie" de l'application et son interface.

Le premier axe cité devrait te mener à envisager les données que tu dois stocker comme s'il s'agissait d'une base de données (d'ailleurs, c'est le cas, simplement, tu n'utilise pas forcément un système de base de données existant )

L'idée est d'arriver à assurer une certaine cohérence entre les données (par exemple que l'adresse d'un fournisseur soit en relation avec... la commune où il se trouve) tout en évitant, autant que possible une trop forte redondance: il ne sert à rien, si un fournisseur fournit cinq produits différents, d'avoir cinq fois son nom, son adresse, son numéro de téléphone ou de compte bancaire.

De la même manière, il ne sert à rien d'avoir un produit connu sous plusieurs références différentes "simplement" parce que c'est un produit que tu peux te procurer auprès de plusieurs fournisseurs différents

Il t'appartient de décider du format dans lequel les données sont stockées (sous la forme d'un fichier "plat", du genre de CSV, ou plutôt sous une forme "XML like" ... Ou peut être sous une forme proche des fichiers ini de windows...) et de décider si tu crées un seul gros fichier qui contient l'ensemble des informations (comprend: les produits en stock, les fournisseurs, les clients et les factures) ou si tu travailles sur différents fichiers pour chaque type d'information dont tu dois assurer la persistance.

Le cas échéant, si plusieurs utilisateurs sont susceptibles d'utiliser l'application, mais que certains ne peuvent pas tout faire, tu devra également mettre au point un système de permission et d'identification, qui devrait, idéalement, ne pas être écrit en dur dans le programme, mais qui se doit d'être suffisamment "sécurisé" pour éviter que n'importe qui n'aille acquérir des droits auxquels il ne peut prétendre.

Pense en outre au fait que plus tu arrivera à garder des responsabilités unique, plus les évolutions futures seront facilitées.

Plutôt que d'avoir une "mega classe" représentant une donnée particulière capable de s'écrire et de se lire "toute seule" dans un fichier (selon le format que tu aura déterminé), il est souvent intéressant d'avoir trois classes bien distinctes:

• La première représentant la données particulière
• La deuxième permettant d'écrire cette donnée dans ton fichier
• La troisième permettant... de lire cette donnée au départ du fichier

Lorsque tu abordera le deuxième axe de réflection cité, tu devra réfléchir aux règles qui régissent les différentes interactions qui peuvent exister entre toutes tes données.

Par exemple:

• un produit ne peut, en tout état de cause, pas être présent un nombre négatif de fois dans le stock
• toute modification du stock doit provoquer, au minium à terme, une modification au niveau des fichiers
• Certaines étapes doivent être validées sous une forme "atomique" voire sous la forme d'une "transaction" (au sens BDD du terme: soit elles sont toutes validées, soit tout est défait)
• la gestion des autorisations données aux différents utilisateurs, s'il échoit
• ...

Le dernier axe de réflexion cité portera sur l'IHM en elle-même:

• Que fait on au travers de menu, au travers de bouton, ...
• sous quelle forme représente-t-on les différentes données
• S'il échoit, quelle est l'ordre logique d'accès aux différentes données (il faut, peut être, passer par deux étapes intermédiaires imposées avant de pouvoir faire une chose particulière )
• mise en place d'un système de discussion cohérent entre l'application et l'utilisateur: l'utilisateur doit pouvoir donner des instructions, le système doit pouvoir donner des informations sur la bonne prise en compte (ou non) de ces instructions
• ...

Ce dernier axe devrait s'appuyer sur le deuxième axe cité afin de provoquer les changements au niveau... du premier

Fais attention au fait que l'efficacité d'une application sera bien souvent bien plus importante si tu atteint un niveau d'ergonomie important:

Les utilisateurs se foutent le plus souvent pas mal de la machinerie qui est derrière l'IHM qu'ils utilisent, mais râlent très facilement (et quelque part avec raison) si, pour accéder à une donnée particulière, ils doivent passer par cinq ou six écrans différents

Il est d'ailleurs important de travailler en accord avec l'utilisateur final, afin de prendre autant que possible ses habitudes de travail en compte (ce qui n'empêche nullement d'essayer de l'inciter à "optimiser" sa manière de travailler)

Ces trois axes de réflexion entrent dans ce que l'on appelle l'idiome "model view controller".

Maintenant, tu nous demande quelle structure utiliser pour les différentes données que tu va devoir gérer, mais là, nous ne pouvons pas vraiment t'aider... à moins de prendre à notre compte l'intégralité du développement de l'application, ou peu s'en faut.

Il faut bien que tu justifie un tout petit peu ton salaire

Par contre, si tu veux un avis éclairé sur une partie du travail que tu auras fait, que ce soit au niveau de la conception ou au niveau de la mise en oeuvre, ou si tu rencontre un problème un peu plus précis que "je dois créer une application de gestion", n'hésite pas à venir nous demander de l'aide

[Mac LAK]

S'appuyant sur des fichiers (pas de BDD), ce programme devra être capable de gérer des informations :

Pourquoi ne pas embarquer un moteur de type SQLite pour gérer ça ?? Tu auras tes fichiers, pas de SGBD à installer, et au moins, tu pourras réfléchir à un niveau un peu plus efficace que la structure interne des fichiers...

Penses aussi à l'avenir : si ta boîte se développe un peu trop vite, ton système basé sur les fichiers "bruts de fonderie" va vite révéler ses limites, et le coût de refonte sera bien plus important qu'en utilisant un moteur de BDD qui est, finalement, plus facilement remplaçable qu'une gestion bas niveau.

[koala01]

Pourquoi ne pas embarquer un moteur de type SQLite pour gérer ça ?? Tu auras tes fichiers, pas de SGBD à installer, et au moins, tu pourras réfléchir à un niveau un peu plus efficace que la structure interne des fichiers...

Penses aussi à l'avenir : si ta boîte se développe un peu trop vite, ton système basé sur les fichiers "bruts de fonderie" va vite révéler ses limites, et le coût de refonte sera bien plus important qu'en utilisant un moteur de BDD qui est, finalement, plus facilement remplaçable qu'une gestion bas niveau.

+1...

Et cela rend le besoin de clairement distinguer ce qui fait partie des différents axes de réflexion encore plus criant

[stallaf]

Bonjour,

Après une longue absence je reviens sur ce sujet et le projet associé.
Je riens à remercier koala01 pour la qualité de sa réponse et le temps qu'il m'a consacré. Celle-ci a été lue avec beaucoup d'attention et j'ai suivi bon nombre de conseils prodigués par tous comme:
- authentification avec droits utilisateurs;
- fichier ini;
- utilisation d'une base de données MySQL.
Comme c'est en forgeant... je rencontre quelques difficultés que je n'arrive pas à régler seul.
Ceux-ci feront l'objet de nouveaux sujets.
Merci encore.