IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

[Conception] Besoin d'avis et de conseils


Sujet :

Java

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 57
    Points : 26
    Points
    26
    Par défaut [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:

    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?

  2. #2
    Membre actif
    Homme Profil pro
    Analyst
    Inscrit en
    Juillet 2008
    Messages
    150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Analyst
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 150
    Points : 217
    Points
    217
    Par défaut Remarque
    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)?

  3. #3
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 138
    Points : 172
    Points
    172
    Par défaut
    tu peux utiliser une base de données embarquée (par exemple hsqldb), rien besoin d'installer

  4. #4
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 138
    Points : 172
    Points
    172
    Par défaut
    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?

  5. #5
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 138
    Points : 172
    Points
    172
    Par défaut
    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?


  6. #6
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 57
    Points : 26
    Points
    26
    Par défaut
    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.

  7. #7
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 57
    Points : 26
    Points
    26
    Par défaut
    @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)



    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.

Discussions similaires

  1. Réponses: 0
    Dernier message: 13/10/2012, 16h49
  2. Besoin d'avis/conseils pour achat d'un ordi portable.
    Par nschoe dans le forum Ordinateurs
    Réponses: 2
    Dernier message: 21/11/2008, 23h59
  3. Réponses: 5
    Dernier message: 07/02/2008, 23h54
  4. [Conception] Besoin d'un conseil pour structurer ma base
    Par pierrot10 dans le forum PHP & Base de données
    Réponses: 7
    Dernier message: 15/01/2008, 15h02
  5. Besoin d'avis sur la conception d'un jeu
    Par MonsieurHelmut dans le forum Développement 2D, 3D et Jeux
    Réponses: 13
    Dernier message: 14/03/2007, 21h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo