Application de Comptabilité

Bonjour,

Je suis étudiant en informatique et je souhaite me lancer dans la réalisation d'un application afin de gérer des finances personnelles (style Money mais en plus simpliste). Pour cela j'ai choisi Java parce que c'est le langage que je connais le mieux et que j'apprécie le plus (documentation fournie, orienté objet, portable, etc...)

Cela fait plusieurs mois que j'essaie différentes choses, sans succès, je suis quelqu'un de perfectionniste mais je me rends compte que rapidement, la taille de mon application m'effraie et m'empêche d'avancer. Actuellement j'essaie de la développer avec le modèle MVC (modèle-vue-contrôleur) mais j'avoue que même après avoir lu des dizaines d'articles et de tutoriels dessus, je suis toujours un peu perdu et je ne sais pas vraiment comment procéder.

Mes problèmes récurrents sont les suivants :
- Comment sauvegarder les données ? J'ai pensé à utiliser une base de donnée style MySQL mais je me demande si c'est une bonne solution et s'il n'y en a pas d'autres.
- Comment commencer ? Est-ce que je dois concevoir l'interface graphique, le dessiner et définir son fonctionnement en détails ? Est-ce que je dois plutôt penser aux classes fondamentales (Transaction, BankAccount, etc.) ? Est-ce que je dois faire un diagramme ? J'avoue que je suis perdu.
- Je n'arrive pas à définir un système MVC convenable pour une application qui contient autant de classes. J'ai déjà conçu une toute petite application Timer qui était basé sur le MVC mais je n'arrive pas à généraliser ma méthode. Est-ce qu'il faut redéfinir des objets SWING en trois couches ? Par exemple, je crée un objet TransactionView, TransactionControler et TransactionModel, que je confine le tout dans un objet Transaction et que je m'en sers comme d'un objet SWING ?

Je ne sais pas si je suis très clair mais voici mes questionnements principaux, si vous pouvez m'aider, soit en me posant des questions pour que j'approfondisse, soit en me donnant des conseils, cela me serait très utile.

Merci d'avance.

Ephasme.

Hello,

Citation:

---

Envoyé par Ephasme

Mes problèmes récurrents sont les suivants :
- Comment sauvegarder les données ? J'ai pensé à utiliser une base de donnée style MySQL mais je me demande si c'est une bonne solution et s'il n'y en a pas d'autres.

---

Oui. y'a pas mieux qu'une base de données pour stocker... des données (lol). Et un bon ORM (iBatis/Hibernate) peut grandement aider à la conception ;)

Citation:

---

Envoyé par Ephasme

- Comment commencer ? Est-ce que je dois concevoir l'interface graphique, le dessiner et définir son fonctionnement en détails ? Est-ce que je dois plutôt penser aux classes fondamentales (Transaction, BankAccount, etc.) ? Est-ce que je dois faire un diagramme ? J'avoue que je suis perdu.

---

Dans ma boîte, on part avec des maquettes des interfaces graphiques. Cela permet de rapidement avoir un aperçu du résultat final, et permet donc aux utilisateurs de plus facilement faire leurs demandes que lorsque rien n'est visible. Ca ne sert à rien de partir comme un fou sur les parties très techniques si on ne sait pas vraiment ce que l'on veut au final.

Citation:

---

Envoyé par Ephasme

- Je n'arrive pas à définir un système MVC convenable pour une application qui contient autant de classes. J'ai déjà conçu une toute petite application Timer qui était basé sur le MVC mais je n'arrive pas à généraliser ma méthode. Est-ce qu'il faut redéfinir des objets SWING en trois couches ? Par exemple, je crée un objet TransactionView, TransactionControler et TransactionModel, que je confine le tout dans un objet Transaction et que je m'en sers comme d'un objet SWING ?

---

MVC est un design pattern que tout le monde implémente un peu comme il l'entend... pas de règles absolues à ce niveau, l'important étant que chaque "concept" général se trouve à la bonne place. Pas de traitement dans le modèle, pas de données dans la vue, et pas d'affichage dans le controlleur. C'est vague mais bon...

Je rajouterais seulement que les débuts sont difficiles en prog... Ce n'est pas grave si les premières applications ont un design imparfaits. C'est avec l'expérience que les réflexes et les automatismes viendront.

C'est en forgeant qu'on devient un expert...


;)

Merci de ta réponse,

D'après toi donc, je devrais commencer par faire l'interface graphique, y mettre les fonctions principales, et ensuite m'en servir pour créer le "fonctionnement" de l'application ?

Mon application sera divisée en plusieurs parties, une partie de gauche qui contiendra la liste des comptes bancaires, une partie qui contiendra toutes les catégories, une partie contenant toutes les transactions.

Les transactions doivent être "composites" c'est à dire qu'elles peuvent être divisées en plusieurs autres transactions qui sont elle-mêmes divisibles en d'autres. Le but étant de pouvoir préciser une transaction autant que l'on souhaite.

Exemple :
Si j'achète à SimpyMarket, des collants, un jeu vidéo et des pommes, les trois objets ne sont pas du même type, par conséquent je dois pouvoir les ranger dans des catégories différentes.
Ainsi, si on fait un bugdet, il peut être très précis.

Autre exemple :
Si je reçois plusieurs chèques, je dois pouvoir identifier chaque chèques séparément en fonction du payeur.
Mettons que je reçois un chèque de Jacques, un chèque de Jean et un de Pierre mais que je dépose les trois d'un seul coup, ma banque mettra la somme totale et ne divisera pas l'opération en trois chèque. Par conséquent mon programme doit pouvoir les regrouper sans perdre les informations.
Je dois pouvoir créer une opération contenant Chèque 1 : payeur Jacques, Chèque 2 : payeur Jean, Chèque 3 : payeur Pierre.

Autre exemple :
Je vais au Mac Do, je suis avec un ami, je lui prête 7,5 € pour payer le sien, je paye avec ma carte bleue, j'ai un total de 15 € dont 7,5 € pour moi et 7,5 € que je lui prête. Je dois avoir une transaction globale (que je peux rapprocher sur mon relevé bancaire) qui contient une transaction "Prêt" pour mon ami, et une transaction 7,5 € pour mac do. Ceci afin d'éviter de compter 7,5 € de FastFood dans mon budget alors que ce n'est pas pour moi. La transaction globale sera bien rapportée au bénéficiaire "Mac Do" mais ne sera pas prise en compte dans le calcul du budget.

De plus, les transactions doivent pouvoir être récurrentes et là je n'ai pas vraiment d'idées pour implémenter quelque chose de correct.

Bref... s'il y a des gens que ça intéresse de m'aider à développer ça. Faites-moi signe.

Citation:

---

Envoyé par Ephasme

D'après toi donc, je devrais commencer par faire l'interface graphique, y mettre les fonctions principales, et ensuite m'en servir pour créer le "fonctionnement" de l'application ?

---

perso j'ai l'opinion exactement inverse: écris tes classes métiers, ecris un (ou des!) testeur(s) de tes codes métiers et ensuite passes à différents niveaux de maquettes graphiques.

hum là d'après moi c'est bien adapté aux cas où l'on sait exactement ce que l'on veut.

le problème c'est que peu de clients savent vraiment ce qu'ils veulent. dans ces cas là (99% du temps) mieux vaut présenter graphiquement des maquettes, laisser l'utilisateur réfléchir, à la limite faire une version graphique fonctionnelle mais bouchonnée avec des données bidons. Les traitements et la recette de ces traitements prend souvent un temps énorme, et pour moi il faut être sûr de ne pas aller dans le mur.

Après bien sûr, je suis également un fervent partisan des tests automatisés ;) mais j'ai toujours pensé qu'il vaut mieux être piloté par l'interface graphique que par le fonctionnel, ne serait-ce que parce qu'il est plus facile de changer l'UI que les codes métiers

Mais bon, bien sûr cela dépend de la situation, certains projets n'ont pas d'UI donc il faut bien s'en passer!


;)

Citation:

---

Envoyé par Pill_S

hum là d'après moi c'est bien adapté aux cas où l'on sait exactement ce que l'on veut.

---

Sauf dans certains cas je maintiens l'opinion inverse: il est tout à fait facile de maquetter le fonctionnel et de passer par des interactions très simplistes, de tatonner jusqu'à ce que les choses s'éclaircissent. J'ai fait ça sur de très gros projets financiers (en C soit dit en passant) sans problèmes.

Commencer par l'interface graphique risque d'être trompeur: c'est plus compliqué qu'on ne le pense et surtout surtout on aboutit à des couplages inacceptables entre le fonctionnel et le graphique (d'où la faiblesse résultante des tests) + on n'accorde plus assez d'importance à la reflexion sur le design de l'interface graphique.

faire du "visual basic" n'est pas fondamentalement mauvais pour faire un truc sur le coin de la table mais n'est pas une démarche à encourager pour passer à la vitesse supérieure.
Ugh! c'était mon pas très humble avis ;)
(en fait je soupçonne qu'il faut se mettre d'accord sur la nature exacte de l'interface graphique de maquettage: il faut savoir la "jeter" pour en réécrire une neuve résultant d'une reflexion sur l'IHM)

Citation:

---

c'est plus compliqué qu'on ne le pense et surtout surtout on aboutit à des couplages inacceptables entre le fonctionnel et le graphique

---

Et là on fait du refactoring. Ce n'est pas un problème. Par contre si tu commences à coder un truc métier sans que le client ne voie quoi que ce soit, tu risques de partir de manière très claire dans une mauvaise direction. C'est dommage, mais là encore pas irrémédiable.

Lol, en fin de compte j'ai la sinistre impression qu'il n'y a pas de règle, c'est un peu comme chacun l'entend quoi.

Si vous avez envie de m'aider à réaliser le projet je suis preneur.

Je voulais poser une autre question à propos du MVC.

Exemple :
J'ai un objet TransactionModel, un objet TransactionControler et TransactionView.

Dans ma vue, je change la catégorie de la transaction... Comment vous coderiez ça ? (En schématique bien sûr, je ne veux pas un code source).