[Conception] Besoin d'avis et de conseils

Bonjour,

je suis en train de développer une application de gestion de Bâtiment. (Location d'appartement et tout le tralala).

Le but est de pouvoir facilement tenir àjour les payements effectué par les locataires ainsi que de savoir quels travaux on été effectués sur quel appartement. Le but ultime est de pouvoir faire des rapports plus ou moins détaillé sur les revenus et dépenses.

Mon problème est que je ne sais pas tout à fait encore comment je vais gérer l'historique de tout ça!

Par exemple d'un mois à l'autre le locataire d'un appartement peut changer! Le prix du loyer aussi.

J'ai donc pensé à quelque chose qui ressemble à ceci: http://img694.imageshack.us/img694/4123/uml.th.png

Ce n'est qu'une ébauche incomplète de la structure.

Ma solution consisterait à créer des BuildingState chaque mois. Cela permettrais de facilement avoir un historique des changements et de conserver les changement de chaque éléments.

Pour ce qui est de la méthode de stockage des données je ne suis pas encore sur non plus. Est-ce que tout sérialiser serait un moyen envisageable?
(Si je compile avec GCJ?)

Serait-je mieux d'utiliser une BDD? (Note: J'aimerais mieux éviter car je souhaiterais que l'installation du programme soit facile.)

Je pourrais toujours utiliser des fichiers xml mais je ne sais pas ce qui serait le mieux.

Donc en résumé:

1- Que pensez-vous de l'ébauche du design? Avez-vous des idées afin de l'améliorer?

2- Est-ce qu'il y as un meilleur moyen de stocker toutes ces données que de tout sérialiser?

Bonjour,
Ne peux-tu pas avoir plusieurs Tenant dans le même mois ? (Il me semble qu'on peut rendre les clés dans le mois et qu'une autre personne prenne place ce même mois)

Pour ton historique, ça dépend de ce que tu veux garder. En effet, pour les paiements, combien de temps doit tu garder trace du paiement d'une personne (avec ces coordonnees -nom,...-), ce qui doit etre différent du fait que X Euros ont été reçus pour Loyer ce mois là (peu importe qui a versé l'argent, ton but étant d'avoir trace des recettes)?

tu peux utiliser une base de données embarquée (par exemple hsqldb), rien besoin d'installer

petite question:

est ce que le système doit connaitre le prix du loyer qu'un locataire doit payer à la fin du mois? ou il faut juste garder traces des paiements effectués?

1) Le but ultime est de pouvoir faire des rapports plus ou moins détaillé sur les revenus et dépenses.

Il faudrait travailler plus sur les spécifications, ce sont elles qui vont influencées les choix de conception. Il faudrait réfléchir aux différents scénarios d'utilisation de l'application, déjà penser aux différents écrans et les données présentées, cela permettra de faire un diagramme des classes adapté.

2) Mon problème est que je ne sais pas tout à fait encore comment je vais gérer l'historique de tout ça!

L'historique se gère avec des dates, il faut que toutes les opérations soient datées (paiment d'un loyer, entrée d'un locataire, sortie, travaux, etc). Ensuite il suffit juste de faire des requetes en mettant des filtres sur les dates.

3) Pour ce qui est de la méthode de stockage des données je ne suis pas encore sur non plus. Est-ce que tout sérialiser serait un moyen envisageable?

pour ce genre d'application il faut une BDDR, utilise une base embarquée pour la simplicité d'installation. Tu peux meme par la suite, donner l'option à l'utilisateur d'utiliser la base embarquée ou alors utiliser une base standalone (mysql par exemple) s'il préfère en lui fournissant les scripts sql de création

4) Que pensez-vous de l'ébauche du design? Avez-vous des idées afin de l'améliorer?

- bosses les specs
- retire application et building manager ça ne sert à rien, il faut se concentrer sur les objets de base de l'application (appartement, locataire, immeuble, etc), une fois que ceux ci seront bien définis et leurs relations, tout coulera de source

De mon côté j'y ai réfléchi, j'ai fait un MCD (modèle conceptuel de données) qui m'a permit de faire un MPD (modèle physique de données), le MPD correspond aux tables dans la base de données, ce qui est souligné sont les clés primaires, et les flèches c'est pour représenter les clés secondaires.

Par contre, je n'ai pas inclu le fait de connaitre le prix du loyer indépendament des versements effectués car je me suis posé une question : dans un contrat de location si le loyer change est ce que ça signifie un nouveau contrat?

http://img12.imageshack.us/img12/628...rammesx.th.jpg

Je viens de lire tes postes toto828 et déjà j'ai quelques réponses.
Je suis pressé dans le temps à l'heure ou j'écris ceci donc je viendrais poster mes commentaires et questions demain.

@toto828

J'ai bien aimé le MPD. Il y avais quelques points auxquels je n'avais pas pensé.

Par contre je n'ai pas trop compris ce qu'était "REFORME". (Changement de contrat?)

Il ne manque que les travaux effectués et le MDP serait relativement complet pour les besoins actuel.

Par contre je n'ai pas trop compris le modèle conceptuel et encore moins comment le transformer en diagramme de classe. J'ai fait un essai en me disant que ce qui est nécessaires est de pouvoir regarder à peut près n'importe quel composant selon une plage de temps. (Surtout mois et années)

http://img9.imageshack.us/img9/4123/uml.png

Avec avec ce modèle et l'utilisation du patron MVC je pourrai facilement me faire des vues afin de voir l'état des payements, le total des revenus / dépenses (et ce par appartement si je le souhaite), voir qui occupe quel appartement, pour combien de temps et même voir qui occupait l'appartement il y as x nombre de temps.

Étant donnée que chaque Payment, Expenditure et TenancyAgreement sont dotés de paramètres qui les définissent dans le temps je pourrais facilement faire les calculs pour une plage de temps donnée.

Pour ce qui est de la relations des payements je ne suis pas encore sur. Dans ma BDD il pourrait être logique de les liés à un contrat. Mais du coté logiciel je ne sais pas trop.

Pour commencé laisse de coté les exceptions sur les bris de contrats ou les changement avant échéance. (Mais d'après moi ça ne sera pas un problème)

Pour ce qui est d'une base de donnée embarqué j'ai fait quelque recherche et suis tombé sur quelques noms. Aurais-tu une préférence particulière?

PS: Merci pour tout tes conseils.

@ElbeDD

Effectivement les contrats peuvent s'effectuer à n'importe quel jour dans le mois. Et je pense même qu'il se pourrait que les délais de versements puissent être différent d'un contrat à l'autre (À vérifier). Ce serait des données à ajouter dans le TenancyAgreement afin de calculer le montant dû par le locataire pour son loyer. Faudra que j'y réfléchisse un peu.