Discussion :

[miltone]

Salut à tous,

Voilà je viens de finir mes études de développement informatique. J'ai une bonne vision général des langages et j'ai déjà fait un peu de C/C++.

Par contre maintenant j'aimerais continuer à me faire la main mais avec une application graphique.

J'ai donc dans l'idée de développer un logiciel de gestion bancaire personnel en C++ avec Qt (que je connais que de nom).

Mon problème n'est pas tant d'ordre technique mais plutôt organisationnel dans le sens où je ne sais pas comment et par où commencer pour faire mon programme.

Par quoi doit-on commencer pour developper un logiciel graphique ? le graphique / le moteur / les receptions d'évènement de l'utilisateur...?

Voilà en gros comment procédez-vous pour développer vos appli graphiques ? quel sont les étapes que vous effectuez ?



Merci à tous de votre participation

[Astraya]

Et bien je dirais le cahier des charges

Définis tes besoins:
Que pourra faire ton logiciel?
Base de données?
Comment désire tu garder tes données?
Quel devise? Quel langage?
Ce que tu veux que ton applications sache faire.

Pour chaque chose que tu désire rentre un peu plus en profondeur dans l'étude. Analyse vite fait, puis point par point tu analyse avec plus de précision.
Ensuite UML, graphique sur papier de ton application et tes fenêtres. Et codage

[bruno_pages]

Bonjour,

Salut à tous,
Par quoi doit-on commencer pour developper un logiciel graphique ? le graphique / le moteur / les receptions d'évènement de l'utilisateur...?

le fait d'utiliser Qt va relativement guider votre démarche, vous devez donc d'abord regarder les exemples fournis avec celui-ci pour avoir un idée de ce que l'on peut faire avec et comment.

En ce qui concerne le projet lui même comme il a été dit la première chose est bien-sûr de décider du 'quoi' (cahier des charges). Par contre vu que vous utilisez Qt il n'est pas souhaitable de s'occuper de la gestion des événements (slots/signaux) dans une phase spécifique séparée.

UML, graphique sur papier

j'ose espérer que le but n'est pas de faire les diagrammes UML sur papier, sinon à quoi cela sert qu'on se décarcasse à faire des outils

[miltone]

Pour ce qui est des données, mise à part PHP/MySQL, je n'ai jamais eu l'occasion de me pencher sur le sujet. Je ne sais pas du tout comment les organiser et les manipuler à travers C++. Donc effectivement c'est un point à étudier.

Effectivement je vais mieux détailler mon cahier des charges pour arriver à fournir des diagrammes UML utile.

Quel serait l'outil Qt le plus efficace pour maquetter rapidement une application, histoire d'avoir une bonne vision globale du projet ?

[3DArchi]

Salut,
(Les applis graphiques m'interrogent toujours sur leur capacité à rapidement devenir des spaghetti à grosse tendance inflationniste.)
Je me demande si l'esprit agile n'est pas adéquat dans ce genre de démarche : identifier les buts principaux du projet, construire le 'backbone' de l'architecture puis fonctionner par itération courte dev/refactoring. Je ne suis pas persuadé (désolé bruno ) que partir sur de beaux graphes UML (avec Bouml bien sûr) n'aboutisse pas à une belle usine sur 'papier' (fut-il électronique).

[bruno_pages]

Je ne suis pas persuadé (désolé bruno ) que partir sur de beaux graphes UML (avec Bouml bien sûr) n'aboutisse pas à une belle usine sur 'papier' (fut-il électronique).

je ne faisais que réagir à la possibilité de faire de l'UML via papier/crayon, pas plus. Je sais bien que l'outil non plus ne fait pas le moine

[miltone]

J'essai de trouver des explications sur comment gérer les données utilisateur du programme en C++ mais je ne trouve pas grand chose (si ce n'est un tutorial trop complexe sur developpez.com).

Je connais les bases de données, le requêtage SQL etc...et je m'en suis servi avec un site en PHP/MySQL mais cela me paraitrait bizarre d'utiliser la même méthode (ouvrir MySQL pour utiliser mon site PHP en local) avec C++.

Si on prend comme exemple une simple application qui s'installe avec un fichier exécutable, comment ce programme fait pour gérer les données utilisateur alors que celui-ci n'a pas forcement installé de SGBDR sur son système ?

pourriez-vous m'éclairez sur cette aspect sombre de C++ ?

[haraelendil]

Ba y a trois options, soit tu as un serveur et ton programme va taper dans la base de donnée via le net, soit tu installe une base de donnée locale, soit tu gère toi même tes données en interne à la main.

Et tu n'as plus besoin de PHP ici, il est bien sur possible de requeter directement une base de donnée en C++ (heureusement :p)

[miltone]

Je pense que dans un premier temps j'essayerais de stocker les données à la main mais après ce serveur du BDD serait nettement plus pratique.

Ce qui me taraude n'est pas tant le coté développeur du programme mais plutôt le coté utilisateur et sa machine. Ok je peux fonctionner comme PHP/MySQL avec C++ qui à assurément une bibliothèque pour utiliser des SGBDR mais comment cela se passe quand il faut fournir le programme à l'utilisateur ?

Exemple:
Quand j'installe Firefox sur mon poste, il ne m'installe pas de SGBDR en plus du programme. J'ai un dossier unique qui comprend le programme exécutable et c'est tout. Voilà ou réside mon incompréhension

[haraelendil]

Oui parce que toutes les informations sont stockées sur le net, ce qui revient pour à la première option...

Tu ne lui donne que le programme, et il se connecte à un serveur fixe pour récupérer les infos.

Après si c'est l'option que tu retient, autant le faire tout de suite avec une base de donnée, quitte à utiliser une base de donnée locale pour le développement, ça ne change presque rien à ce qui se passe "en vrai"

[miltone]

Je crois que je me suis mal fait comprendre car :

Oui parce que toutes les informations sont stockées sur le net, ce qui revient pour à la première option...

Depuis que j'utilise des programmes informatiques quasiment (voir aucuns) de mes programmes possèdent des données distantes sur le web. Mon logiciel de compte Microsoft Money 2005 ne stock pas mes comptes sur le net bien heureusement.

Après si c'est l'option que tu retient, autant le faire tout de suite avec une base de donnée, quitte à utiliser une base de donnée locale pour le développement, ça ne change presque rien à ce qui se passe "en vrai"

Justement il se passe quoi en vrai pour l'utilisateur ?

[Astraya]

j'ose espérer que le but n'est pas de faire les diagrammes UML sur papier, sinon à quoi cela sert qu'on se décarcasse à faire des outils

Bé bien sur que si... :p mais non je parlais d'UML pour le programme et de diagramme papier pour le design graphique de l'application.

[haraelendil]

Depuis que j'utilise des programmes informatiques quasiment (voir aucuns) de mes programmes possèdent des données distantes sur le web. Mon logiciel de compte Microsoft Money 2005 ne stock pas mes comptes sur le net bien heureusement.

Tu dis ça pour l'instant, mais avec les histoires de cloud computing et autres bureau décentralisés, ça y viendra bien un jour^^

Bah il reste les deux autres solutions, soit le programme gère tout seul ses données, souvent sous la forme d'un serveur de base de données, mais juste interne au programme ce qui fait que tu ne le voit pas.

Justement il se passe quoi en vrai pour l'utilisateur ?

Bah en vrai il se passe que l'utilisateur voit ses données, après où et comment elles sont stocké, il s'en tamponne l'utilisateur (ouai c'est toujours vache un utilisateur^^)
Non mais plus sérieusement, je suis pas sur d'avoir bien compris cette question^^

[miltone]

Justement il se passe quoi en vrai pour l'utilisateur ?

Euh...je confirme cette question est assez ambigüe en fait.

Bah il reste les deux autres solutions, soit le programme gère tout seul ses données, souvent sous la forme d'un serveur de base de données, mais juste interne au programme ce qui fait que tu ne le voit pas.

et comment mettre en oeuvre ce système ?

Ok je sais développer avec une SGBDR à coté que je lance et une bibliothèque C++ pour l'utiliser mais après comment UNIR le tout dans un seul programme que l'utilisateur installera simplement sans installer la SGBDR qui ira avec.

[3DArchi]

Salut,
Beaucoup de programmes ont un exécutable ... et une palanquée de fichiers qui contiennent les données. Selon la stratégie du programme, ces données peuvent :
-> soit être dans le même répertoire que l'exécutable (en général des données de configuration non liées à un utilisateur/projet/travail) ;
-> soit dans un répertoire spécifique fourni par l'utilisateur : par exemple, ton document Word est stocké là où tu dis à Word de le sauvegarder. Ou encore, ton projet Code::Blocks/Visual/Qt/etc... est stocké là où tu demandes à ton I.D.E. de l'enregistrer ;
-> soit certains paramètres peuvent être stockés (sous windows) dans les répertoires de l'utilisateur courant (Mes Documents ou Documents and Settings).
Cela veut dire qu'il faut que tu identifies
1/ Les données de l'application qui servent surtout à la configurer et qui sont indépendantes de l'utilisateur. Ce sont celles qui sont positionnées à l'install, aux éventuelles mises à jour et qui peuvent configurer certains comportements globaux. Ces données seront partagées entre tous les utilisateurs de ton appli sur le même post. ;
2/ Les données de configuration propre à un utilisateur. Ces données sont spécifiques à un utilisateur qu'il retrouve d'une session sur l'autre.
3/ Les données liées à un travail/projet avec ton application. Ce sont les données qu'il a en créant un nouveau 'document'.
Selon le type d'application tous les jeux de données n'ont pas lieu d'être. C'est à toi de voir lesquelles sont pertinentes et de définir leur stratégie de stockage.

Ensuite comment les sauvegarder ?
-> Utiliser une sauvegarde manuelle que tu fais de A à Z. Laborieux et rapidement buggé . Cette sauvegarde peut être brute, textuelle, XML, etc...
-> Utiliser des mécanismes de sérialisation ;
-> Utiliser des bibliothèques comme SQLite qui s'utilise comme une base de donnée mais sans avoir un serveur de BDD.

Certaines données peuvent être déportées sur un serveur Internet mais si tu démarre cela me semble pas la façon la plus simple pour commencer.

[miltone]

Je me suis penché sur SQLite pour lequel il existe assez peu de documentation (mise à part l'officiel bien-sur). Ça me parait donc jouable mais délicat.
Si j'utilise SQLite pour mon programme il faudra donc que l'utilisateur final utilise aussi ce programme. Mais comment gérer cette base de données sur le poste client ?

La plupart des logiciels sous Windows sont fourni avec un simple exécutable d'installation et quand on l'exécute on ne voit pas, sur le système, de SGBDR installé ou autre pour gérer la pertinence des données.
Donc si j'utilise SQLite, comment le mettre en œuvre sur le poste de l'utilisateur sans que celui-ci le voit ou puisse l'utiliser en dehors de mon programme?

Quant à la sérialisation le problème reste identique car ce n'est qu'une technique de découpage et non de sauvegarde à proprement parler des données.

Comment la plupart des logiciels freeware non-professionnels font pour gérer la persistance de leur données ?

[haraelendil]

Ba la plus grande majorité fait comme a dit 3D, sérialisation plus stockage dans un fichier (soit à un emplacement donné, soit choisit par l'utilisateur).

Quand à SQLite, première ligne de la page about:

SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine

Si ça ça répond pas à ce que tu veux, je sais pu quoi faire :p

[miltone]

Ba la plus grande majorité fait comme a dit 3D, sérialisation plus stockage dans un fichier (soit à un emplacement donné, soit choisit par l'utilisateur).

Apparemment, la sérialisation n'est qu'une technique de découpage de données ce qui reviens donc, comme la dit, 3D à faire une sauvegarde manuelle de A à Z, long et laborieux et rapidement buggé.

Si ça ça répond pas à ce que tu veux, je sais pu quoi faire :p

Certes ma mes questions ne reposent pas sur le point de vue du développeur et de l'utilisation de SQLite pour lui car ca ce n'est pas bien compliqué. Mais de savoir comment faire pour proposer une application à l'utilisateur avec SQLite pour la persistence de ses données ?

Vous me répondez toujours du point de vue du développement là ou moi je parle de celui de l'installation pour l'utilisateur.

Si je développe un programme avec persistance des données sous ORACLE c'est bien, c'est beau, et ca ne pose apriori aucun problème, mais comment tu va faire après pour distribuer ton application aux utilisateurs?
Tu ne va quand même pas leur dire d'acheter une licence oracle ?
Tu va joindre Oracle à ton package d'installation ?

Quand on installe un programme on ne voit jamais quel système de persistance de données le développeur à utilisé et il ne nous fait pas installer de SGBDR ou autres outils pour son programme. Pourtant il y a bien un système de sauvegarde dans son programme. Alors soit, il existe des techniques d'installation pour cacher certains outils, soit le développeur à fait lui-même un système long et laborieux de sauvegarde qui est très vite buggé.

[obliveon]

SQLite is a compact library. With all features enabled, the library size can be less than 300KiB, depending on compiler optimization settings. (Some compiler optimizations such as aggressive function inlining and loop unrolling can cause the object code to be much larger.) [...]

Je ne suis pas expert, mais je pense qu'il suffit juste de fournir la "dll" de sqllite et rien d'autre.
Je viens de télécharger le fichier "sqlitedll-3_6_23_1.zip" et dedans il y deux fichiers (sqlite3.dll et sqlite3.def).

[obliveon]

[...]
[...]

Quand on installe un programme on ne voit jamais quel système de persistance de données le développeur à utilisé et il ne nous fait pas installer de SGBDR ou autres outils pour son programme. Pourtant il y a bien un système de sauvegarde dans son programme. Alors soit, il existe des techniques d'installation pour cacher certains outils, soit le développeur à fait lui-même un système long et laborieux de sauvegarde qui est très vite buggé.

Je pense que soit le développeur à utilisé un moteur de base de données intégré (genre Sqlite) soit l'installation d'un moteur de base de données client-serveur un peu plus lourd s'est réalisé en mode "silencieux" (via des scripts), et qu'un service (ou daemon sous linus/unix) en tâche de fond tourne.
Pour le peu que le programme d'installation soit bien réalisé, l'utilisateur ne verra que du feu, la seule chose qu'il aura à faire est de cliquer sur les boutons "suivant" et "Ok".