Discussion :

[Gm7468]

Bonjour,

Je suis grand débutant en programmation C++, bien que j'ai lu de très bons tuto, et que j'ai d'anciennes bases de POO avec java et un peu de php/html.

Je suis sur un projet conséquent d'un programme assez complexe, qui sert à des automatisations de tâches et calculs. J'ai déjà effectué une bonne partie de la phase conception, en réalisant les organigrammes du futur programme. L'architecture de mon projet est composée de différents "modules", qui correspondent à des tâches bien différentes qui s'enchainent, l'enchainement étant déterminé dans un cycle séparé. En somme:

Cycle de fonctionnement: (Début)->|Module 1|->|Module 2|->|Module 3|->(Fin)
Module 1: Chaine d'actions 1
Module 2: Chaine d'actions 2
Module 3: Chaine d'actions 3

Le programme devra avoir une interface graphique, au départ pour lancer l'application, modifier les paramètres, puis lancer le cycle. Et pendant le cycle, uniquement des fenêtres de présentation de l'avancement et de l'action en cours, mais ces dernières ne doivent pas empêcher la mise en pause ou l'arrêt forcé d'un cycle. Les paramètres dont je parle seront stockés dans un fichier XML, qui servira au programme pour le fonctionnement automatique, mais qui devra pouvoir être modifié manuellement (à partir d'une interface).
L'application utilisera des matrices et des calculs relativement poussés, une communication par port COM ainsi que des envois de résultats sur un serveur (ftp ou autre...).

1- Ai-je été suffisamment clair dans la présentation de mon projet?

Après différentes recherches, je pense m'orienter vers:
- une programmation en C++
- l'utilisation de Qt, notamment pour l'interface graphique, la lecture/écriture XML, et le fonctionnement réseau (COM et serveur)
- l'utilisation de la bibliothèque BOOST pour tout ce qui touche aux matrices

2- Ces choix sont-ils a priori pertinents?

3- Les bases sont à présent posées. Pour le développement à proprement parler, quelle est la marche à suivre? C'est-à-dire, d'une part, comment organiser le code, et d'autre part, utiliser les bibliothèques.
Dois-je programmer mes "modules" en C++, séparément, et ne prévoir Qt que pour afficher le tout par la suite, ou dois-je programmer mes modules directement dans Qt (en utilisant les variables de Qt les types, etc...)?

4- L'architecture de mes fichiers de code sera-t-elle la suivante:
- main.cpp: lancement du programme, interface graphique
- cycle.cpp: cycle principal appelé par le main, et appelant les modules
- module1.cpp: module 1, enchainement de tâches
- module2.cpp: module 2, enchainement de tâches
- module3.cpp: module 3, enchainement de tâches
- classeQt1.cpp: interface correspondant au module 1
- classeQt2.cpp: interface correspondant au module 2
- classeQt3.cpp: interface correspondant au module 3
- classePerso1.cpp: une classe d'objets utilisés dans le programme
- classePerso2.cpp: une autre classe d'objets utilisés dans le programme

J'espère avoir été assez clair dans mes interrogations,

Merci pour vos réponses.

[koala01]

Salut, et bienvenue sur le forum

1- Ai-je été suffisamment clair dans la présentation de mon projet?

Tu es certes resté relativement imprécis dans ce qui sera fait dans les différents modules, mais, oui, de manière générale, la présentatin que tu fais permet de se faire une idée assez précise du résultat que tu souhaites obtenir...

Il y aura cependant certaines questions d'ordre beaucoup plus précise qui viendront pour arriver à te proposer le meilleur choix

Après différentes recherches, je pense m'orienter vers:
- une programmation en C++
- l'utilisation de Qt, notamment pour l'interface graphique, la lecture/écriture XML, et le fonctionnement réseau (COM et serveur)
- l'utilisation de la bibliothèque BOOST pour tout ce qui touche aux matrices

2- Ces choix sont-ils a priori pertinents?

Cela semble, en effet, cohérent, même si, à titre tout à fait perso, je préférerais éviter le recours au système COM...:

Qt, tout comme boost, fournissent des ensemble de classes spécialisées dans la gestion du réseau, par exemple, et COM est tout, sauf parfaitement portable (et donc, à n'utiliser qu'en cas d'obligation forcée, selon moi )

3- Les bases sont à présent posées. Pour le développement à proprement parler, quelle est la marche à suivre? C'est-à-dire, d'une part, comment organiser le code, et d'autre part, utiliser les bibliothèques.

L'idéal est d'avancer "pas par pas", "module par module"...

Essaye de faire en sorte qu'un module fonctionne correctement avant de t'attaquer au module suivant

Cela implique de savoir déterminer quel module dépend des autres, meme si, dans un premier temps, tu peux parfaitement te contenter d'une gestion se contentant d'afficher "ici, tel module prend le relais"

N'oublie surtout pas les de mettre en place une politique stricte de tests unitaires, non seulement pour t'assurer que ce que tu fais correspond bien à ce que tu attends, mais aussi pour avoir la certitude que, les évolutions aidant (il arrivera fatalement un moment où tu devras revenir sur "de l'existant" pour l'adapter aux besoins d'une nouvelle fonctionnalité ), tu n'apporte pas une modification qui a pour résultat de "tout casser"

Dois-je programmer mes "modules" en C++, séparément, et ne prévoir Qt que pour afficher le tout par la suite, ou dois-je programmer mes modules directement dans Qt (en utilisant les variables de Qt les types, etc...)?

A titre purement personnel, je dirais que l'idéal est d'essayer de se limiter à ce que fournit le C++ en standard et à boost pour toute la partie "business" de ton projet, et d'essayer de limiter l'utilisation de Qt à la partie purement relative à l'IHM, voire à la partie "controler" de ton application.

Cela permettra plus facilement de garder la partie métier et de ne refaire que la partie propre à l'IHM en cas de besoin

Maintenant, ce conseil est strictement personnel, parce que j'aime l'idée de découpler le plus possible la partie métier de la partie purement graphique, mais d'autres pourraient avoir des avis différents (et pas forcément sans fondement )

4- L'architecture de mes fichiers de code sera-t-elle la suivante:
- main.cpp: lancement du programme, interface graphique
- cycle.cpp: cycle principal appelé par le main, et appelant les modules
- module1.cpp: module 1, enchainement de tâches
- module2.cpp: module 2, enchainement de tâches
- module3.cpp: module 3, enchainement de tâches
- classeQt1.cpp: interface correspondant au module 1
- classeQt2.cpp: interface correspondant au module 2
- classeQt3.cpp: interface correspondant au module 3
- classePerso1.cpp: une classe d'objets utilisés dans le programme
- classePerso2.cpp: une autre classe d'objets utilisés dans le programme

C'est très certainement une base de travaille cohérente, mais il y a de fortes chances que l'idéal soit quand meme de séparer les fonctionnalités de chaque module en autant de fichier (en-tête + implémentation !!! ) qu'il y aura de classes dans le module

Tu pourrais donc très facilement te retrouver avec quelque chose comme

1. [*]module 1 (c++ "pur" + boost éventuel)
   
   • classe1.h + classe1.cpp
   • classe2.h + classe2.cpp
   • classe3.h + classe3.cpp
2. module 2 (c++ "pur" + boost éventuel)
   
   • classe4.h + classe4.cpp
   • classe5.h + classe5.cpp
   • classe6.h + classe6.cpp
3. module 3 (c++ "pur" + boost éventuel)
   
   • classe7.h + classe7.cpp
   • classe8.h + classe8.cpp
   • classe9.h + classe9.cpp
4. module "controleur" (Qt + moduel1 + module2 + module3 + C++ "pur" + boost éventuel )
   
   • controleur1.h + controleur1.cpp
   • controleur2.h + controleur2.cpp
   • controleur3.h + controleur3.cpp
   • controleur4.h + controleur4.cpp
   • controleur5.h + controleur5.cpp
5. module "ihm" (Qt +controleur)
   
   • widget1.h + widget1.cpp
   • widget2.h + widget2.cpp
   • widget3.h + widget3.cpp
   • widget4.h + widget4.cpp
   • widget5.h + widget5.cpp
   • widget6.h + widget6.cpp
   • widget7.h + widget7.cpp
   • widget8.h + widget8.cpp
   • widget9.h + widget9.cpp

Le tout en prévoyant, pourquoi pas, des dossier différents pour les différents modules

[Gm7468]

Tout d'abord, merci beaucoup koala01 pour cette réponse à la fois rapide et très complète!

1- Je suis effectivement resté évasif pour la description de manière à ne pas rentrer dans des détails alourdissant la description. Je trouvais qu'elle était déjà suffisamment longue pour ne pas en rajouter ^^
Si besoin, je peux bien entendu développer plus le concept, si cela peut aider à apporter plus de réponses et/ou suggestions.

2- L'utilisation d'un port COM sera effectivement obligatoire dans mon application, donc cela ne peut pas être écarté. D'où mon intérêt pour Qt qui, en plus du GUI et du XML, permet de gérer cela.

3- Dans le fonctionnement prévu, chaque module a besoin du précédent et est nécessaire au suivant (n dépend de n-1 et permet n+1). Par conséquent, ce que tu me proposes confirme mes premières idées, de faire les modules séparément, de les tester indépendamment, et de fusionner le tout une fois que chacun fonctionne.

4- A priori, l'architecture que j'aurai à utiliser se situe entre ma proposition et la tienne. J'avoue qu'en tant que débutant elle me parait encore un peu (ou beaucoup) floue, car bien plus complexe que tous les tutoriels que j'ai pu parcourir.
Ce que j'ai encore du mal à concevoir, c'est l'enchainement des actions des modules. Dans ma conception du programme, j'ai envisagé que le module de départ charge le fichier XML, crée les objets nécessaires, et passe la main à la suite. Dans cette suite, chaque module ne crée aucun objet, mais utilise les objets initiaux (ou des variables intermédiaires), avant de les passer au suivant. Pour chaque étape, on aurait une interface simple représentant l'avancement.

Suivant cela, on n'a besoin que d'une seule classe d'objets, et à coté de celle-ci, les modules ne feront que des actions sur ces objets.

Je fais peut-être une confusion entre classe et fichier .cpp et .h?
Jusqu'à présent, pour chaque nouvelle classe, je faisais un fichier .cpp et un .h. Là, je devrais créer des fichiers .cpp et .h sans créer de classe, pour chaque module? Ou est-ce que ce que j'appelle "module" sera représenté dans le programme par une classe?
A ce moment là, les actions réalisées seront les méthodes de la classe?

5- Je m'égare peut être un peu dans mes questions, mais toutes sont liées au programme, et à la programmation qui sera choisie.
Qt est sous licence LGPL, par conséquent, mon programme pourrait potentiellement être propriétaire, il suffirait que je fournisse à coté du .exe de mon application les .dll de Qt utilisées et les parties de mon programme qui utilisent Qt, est-ce bien cela?

Si c'est effectivement les conditions, le fait de séparer le "C++ pur" et Qt permettraient de ne divulguer que mes classes qui héritent de Qt, à savoir l'interface graphique, la lecture XML, et les parties serveur, tout en gardant toutes les parties "calcul" confidentielles. Me trompe-je?

6- Tu sépares un module "contrôleur" d'un module "ihm". l'IHM correspond à tout ce qui est affichage? C'est-à-dire fenêtres de progression, d'accueil et de paramétrage. Mais à quoi correspond le contrôleur? Ce sont toutes les fonctions appelées par les boutons de l'interface?

Encore une fois un post un peu long... merci de l'avoir lu jusqu'ici

[koala01]

3- Dans le fonctionnement prévu, chaque module a besoin du précédent et est nécessaire au suivant (n dépend de n-1 et permet n+1). Par conséquent, ce que tu me proposes confirme mes premières idées, de faire les modules séparément, de les tester indépendamment, et de fusionner le tout une fois que chacun fonctionne.

Ce que tu appelles "module" fait quand meme furieusement penser à des fonctionnalités ou à des étapes à respecter

Mais rien n'empêche, effectivement, de créer des modules séparés

4- A priori, l'architecture que j'aurai à utiliser se situe entre ma proposition et la tienne. J'avoue qu'en tant que débutant elle me parait encore un peu (ou beaucoup) floue, car bien plus complexe que tous les tutoriels que j'ai pu parcourir.

Ce qui importe avant tout, c'est de déterminer les bonnes responsabilités pour chaque étape, et de regrouper les fonctionnalités utiles à chaque responsabilité dans le "bon nombre" de classe (ayant chaque fois une responsabilité unique )

A partir de là, il y a généralement deux fichiers à prévoir : un fichier d'en-tête (*.h / *.hpp ) qui fournit qui définit la classe et déclare ses membres et fonctions associées, et un fichier d'implémentation (*.cpp) qui fournit l'implémentation des fonctions membres et associées

Ce que j'ai encore du mal à concevoir, c'est l'enchainement des actions des modules. Dans ma conception du programme, j'ai envisagé que le module de départ charge le fichier XML, crée les objets nécessaires, et passe la main à la suite. Dans cette suite, chaque module ne crée aucun objet, mais utilise les objets initiaux (ou des variables intermédiaires), avant de les passer au suivant. Pour chaque étape, on aurait une interface simple représentant l'avancement.

C'est effectivement cohérent, mais il faut rester conscient que, pour effectuer une partie du traitement, il n'est pas impossible que tu doive recourir à plusieurs classes afin de respecter cette fameuse règle de "responsabilité unique"

Suivant cela, on n'a besoin que d'une seule classe d'objets, et à coté de celle-ci, les modules ne feront que des actions sur ces objets.

Tu auras sans doute une seule classe "donnée", mais tu peux avoir plusieurs classes qui la manipulent, et qui prendront chacune une partie du traitement en charge

Je fais peut-être une confusion entre classe et fichier .cpp et .h?

En fait, le couple fichier *.h + fichier *.cpp est ce qui permet de fournir en C++ l'implémentation du concept représenté par la classe...

Je m'explique : Une classe fournit le concept d'un objet plus ou moins concret que l'on utilise (par exemple :la classe Voiture fournit le concept informatique de l'objet correspondant dans la "vie de tous les jours")

Le couple de fichier *.h + *.cpp est la "traduction" de ce concept dans le langage (ici C++) qui permettra, après traitement (la compilation, dans le cas du C++, ou l'interprétation pour d'autre langages ), à l'ordinateur de manipuler ce concept

Jusqu'à présent, pour chaque nouvelle classe, je faisais un fichier .cpp et un .h.

C'est effectivement ce qu'il faut faire

Là, je devrais créer des fichiers .cpp et .h sans créer de classe, pour chaque module?

Tu ne dois pas créer de fichier pour le plaisir d'en créer, surtout si c'est pour les laisser vide

Ce qui se passe, c'est que le système de fichier est le meilleur moyen pour organiser ton travail : tu mets dans un fichier tout ce qui "va bien ensemble" : une classe, d'éventuelles constantes et d'éventuelles fonctions libres qui utilisent / seront utilisées par la classe.

De cette manière, tu disposes (au travers du fichier d'en-tête) de "tout ce qu'il faut" pour utiliser la classe.

ainsi, on peut estimer que la valeur de PI, les fonctions sinus, cosinus, tangeante et cotangeante sont autant de choses qui "vont bien ensemble" et que l'on peut donc trouver dans un fichier unique : math.h

Un module est à considéré comme un "ensemble de fonctionnalités" nécessaire à l'obtention d'un résultat complexe.

Ainsi, tu pourrais très bien avoir un autre fichier regroupant la structure "date_time" et les fonctions qui permettent de manipuler des dates et des heures (parce que ca "va bien ensemble"), et mettre dans un meme module les fonctionnalités de gestion de date et d'heure d'une part et les fonctionnalités de mathématique parce que tu as besoin de ces deux ensembles de fonctionnalités pour obtenir le résultat qui t'intéresse

A Ou est-ce que ce que j'appelle "module" sera représenté dans le programme par une classe?

Un module a, souvent, de fortes chances d'être meme représenté par un ensemble de classes :

Bien souvent, tu as une ou plusieurs classe "de données" manipulées et une ou plusieurs classes qui les manipule(nt) (des classes "métier" ).

Tu as en effet souvent plusieurs ensembles de fonctionnalités "qui vont bien ensemble" qui permettent, en travaillant "de concert", d'obtenir un résultat donné

A ce moment là, les actions réalisées seront les méthodes de la classe?

En conception orientée objet, on considère généralement que les différentes actions sont des méthodes de la classe qui a la responsabilité correspondante

Maintenant, comme j'ai essayé de te l'expliquer depuis le début, chaque classe doit (devrait, idéalement) n'avoir qu'une responsabilité limitée, "concrétisée" éventuellement par plusieurs fonctions membres, et il faut donc veiller à ce que la "bonne fonction" soit membre de "la bonne classe"

5- Je m'égare peut être un peu dans mes questions, mais toutes sont liées au programme, et à la programmation qui sera choisie.
Qt est sous licence LGPL, par conséquent, mon programme pourrait potentiellement être propriétaire, il suffirait que je fournisse à coté du .exe de mon application les .dll de Qt utilisées et les parties de mon programme qui utilisent Qt, est-ce bien cela?

Si c'est effectivement les conditions, le fait de séparer le "C++ pur" et Qt permettraient de ne divulguer que mes classes qui héritent de Qt, à savoir l'interface graphique, la lecture XML, et les parties serveur, tout en gardant toutes les parties "calcul" confidentielles. Me trompe-je?

Cela va meme plus loin :

La seule chose dont tu dois fournir le code source (ou le moyen de l'obtenir) des classes faisant partie de Qt (ou des éventuelles modifications que tu y apporterait).

Les classes que tu crées qui dépendent de Qt peuvent parfaitement être propriétaires, tout comme le programme en lui-même

6- Tu sépares un module "contrôleur" d'un module "ihm". l'IHM correspond à tout ce qui est affichage? C'est-à-dire fenêtres de progression, d'accueil et de paramétrage.

C'est bien cela

Mais à quoi correspond le contrôleur? Ce sont toutes les fonctions appelées par les boutons de l'interface?

C'est la partie qui va controler toutes les communications entre la partie métier et l'IHM:

Si une erreur survient (au niveau métier) lors de l'exécution, c'est le controleur qui dira à l'IHM comment réagir

Si l'utilisateur introduit un chiffre au lieu d'un texte, par exemple, c'est le controleur qui signalera directement à l'utilisateur (au travers de l'IHM) "qu'il s'est gouru"

C'est encore le controleur qui permettra de mettre certaines données "métier" en forme au niveau de l'IHM

Bref, le controleur, c'est vraiment ce qui fait le lien (dans les deux sens !!! ) entre la partie métier et la partie graphique

[Gm7468]

Encore une fois, merci koala01, des réponses toujours aussi pertinentes et complètes

Ce que tu appelles "module" fait quand meme furieusement penser à des fonctionnalités ou à des étapes à respecter

C'est complètement cela oui. Mais comme ils sont relativement conséquents, souvent même je les ai séparés en sous-modules, je les ai "pensés" indépendamment.

La seule chose dont tu dois fournir le code source (ou le moyen de l'obtenir) des classes faisant partie de Qt (ou des éventuelles modifications que tu y apporterait).
Les classes que tu crées qui dépendent de Qt peuvent parfaitement être propriétaires, tout comme le programme en lui-même

Là je ne suis pas sur de suivre totalement... Que je doive fournir les dll de Qt, d'accord, les modifications, ok également (de toute façon je ne ferai pas de modifications à proprement parler). Cependant, les classes que je crée qui dépendent de Qt, de par l'héritage (par exemple l'IHM dont les fenêtres héritent de classes Qt), sont des "travaux qui dérivent de la bibliothèque" comme le présente la licence, et donc elles doivent être fournies au même titre que Qt non?


J'ai l'impression que nous sommes en phase pour tout le reste, ou du moins que tu as éclairé pour le moment tout ce dont j'avais besoin.

Encore un grand merci pour tes réponses!
Je reviendrai peut-être si d'autres interrogations me viennent en cours de développement ^^

[Gm7468]

Une nouvelle question me vient à l'esprit, je sèche un peu dans le code.
J'ai donc pour le moment cette architecture:
- main.cpp
- objet1.cpp
- objet1.h
- objet2.cpp
- objet2.h

Jusque là, tout va bien. Dans mon main.cpp, j'ai une fonction main qui fait différentes petites choses, et d'autres fonctions à coté pour des calculs (qui utilisent ou non les objets).
Je voudrais mettre ces fonctions annexes ailleurs, et que je puisse les appeler depuis le main, ou depuis n'importe quel module où j'en aurait besoin.

J'ai ainsi créé deux nouveaux fichiers: fonctions.cpp et fonctions.h, pour définir la classe fonctions qui contient les fonctions qui étaient précédemment dans le main. Seulement, lors des appels, le compilateur m'envoie une erreur, car aucun objet fonctions n'est créé. C'est logique.
J'ai pensé à faire une classe abstraite, mais alors faudrait-il que mes classes objetx héritent de fonctions pour pouvoir utiliser les fonctions...?

Comment organiser mon code (fichiers, création de classes ou non) pour que je puisse utiliser les différentes fonctions facilement sur les différents objets?

[koala01]

Là je ne suis pas sur de suivre totalement... Que je doive fournir les dll de Qt, d'accord, les modifications, ok également (de toute façon je ne ferai pas de modifications à proprement parler). Cependant, les classes que je crée qui dépendent de Qt, de par l'héritage (par exemple l'IHM dont les fenêtres héritent de classes Qt), sont des "travaux qui dérivent de la bibliothèque" comme le présente la licence, et donc elles doivent être fournies au même titre que Qt non?

Il faudrait que je relise le contrat de licence, mais, pour autant que je me souvienne, Qt est fourni en licence LGPL.

Si la licence GPL est très virale (tout ce qui utilise quelque chose sous licence GPL doit respecter lui meme la licence GPL et etre fournis selon les règle de la licence GPL), il me semble que la licence LGPL s'arrête au composants fournit sous cette licence.

Ainsi, il est clair que tu ne peux pas prendre les sources de Qt, les compiler et fournir Qt sous une licence propriétaire (ou non GPL).

Il est aussi clair que, si tu rajoute dans Qt une classe de la mort qui tue, tu devras fournir cette classe sous licence LGPL et au moins la proposer à l'équipe de dev de Qt (qui restera libre de l'introduire ou non), et que, tant que tu utiliseras cette classe, tu devras t'assurer que son code source est disponible.

Par contre, il me semble que tu restes totalement libre de choisir la licence que tu veux pour ce qui "ne fait qu'utiliser" une bibliothèque sous licence LGPL, à condition que la bibliothèque sous licence LGPL soit utilisés sous forme de shared lirary (dll sous windows, so sous linux) mais, comme je l'ai dit, il vaut mieux relire le texte et attendre confirmation