Re: Développement d'un logiciel pour le worldbuild, organiser son uni. — VOUS pouvez vous impliquer dans son développeme
Posté : dim. janv. 07, 2018 9:01 pm
Alors ! Attention, ce post va contenir un petit nombre d'explications techniques. J'ai finalement passé la journée sur ce diagramme, m'étant aperçue de faiblesses non négligeables dans la conception du logiciel.
Je suis ouverte à tous avis sur ce diagramme et sur les procédés développés !
Here's the beast:
Par commodité, je l'ai allégé en omettant notamment les accesseurs et mutateurs, les fonctions d'initialisation. Enfin, j'ai enlevé des classes associées aux formulaires notamment (comme ComboBox). Quand je l'ai précisé, je m'étais aperçue de problèmes dans mon ancien modèle, que j'ai essayé de corriger là (lorsque je l'avais conçu, je pensais que ce serait bon mais... Nan. ).
Là, je dois avouer être à moitié satisfaite d'avoir une classe EntityManager pour gérer tout le bourzin lié au projet. Vous pouvez voir qu'il est possible d'étendre le système pour gérer les projets (et donc éventuellement externaliser les managers). J'ai enlevé des méthodes, mais des classes comme Sheet ont des méthodes comme Sheet::save().
Pour le système d'unité, je considère que chaque "champ" possède une unité, facilitant les conversions. Si cette unité est numérique, on pourra effectuer des conversions. Je rajouterai également une classe "CommonUnit" et "CalendarUnit".
Pour la sauvegarde : je crée des sous-dossiers, et chaque instance de classe effectue sa sauvegarde : il y a un fichier xml par template, par fiche (sheet), par note. Pour les sections et catégories c'est un peu plus compliquer. La classe Project possède une méthode Project::filter() qui permet de filtrer les entrées dans la TreeView, et donc les cacher/afficher à notre guise, en fonction d'un texte entré (voir animation ci-dessous). Pour éviter d'avoir des itérations trop longues (en particulier sur les projets avec beaucoup de fiches), j'ai rajouté des grandes catégories que l'on peut cocher/décocher pour la mettre dans la recherche.
Dans le modèle d'unités numériques j'ai inclus la possibilité d'éditer ses propres dimensions (ou grandeurs) fondamentales (vous savez, les MLTINThetaK) ; c'est d'ailleurs à peu près à l'aide de ça que le système effectue une vérification d'homogénéité.
Enfin, j'ai omis ce qui est lié au GUI ; je compte revoir ça avec QML.
Pour la petite note, mes mutateurs et accesseurs sont faits via des décorateurs, en Python. C'est plus élégant, d'un côté.
Si vous avez des questions, n'hésitez pas. Et des critiques, hésitez encore moins !
EDIT : après une nuit de repos et un peu de recul, je me rends compte que la répartition en grandes catégories (Fiches, Templates, Cartes, Notes, etc.) est caduque. En réalité j'ai repris l'idée d'Articy, dans quand on y réfléchit ça complexifie le modèle et implique d'avoir une classe héritée (SectionManager, car chaque section est reliée à une grande catégorie).
Je pensais faire une barre d'onglet sur la gauche, sous forme d'icônes, permettant d'accéder aux entités (fiches/templates), aux grandeurs (unités/grandeurs/constantes), aux outils relationnels (graphes/tableaux), à la cartographie, et à la configuration générale du projet (je ferai un illustration un de ces quatre).
Pour le coup ça m'a permis de revoir un peu les choses. Mieux vaut que ce soit maintenant ; et en plus je peux reprendre sans problème ma base de code.
Je sais que je pourrais ne pas me casser la tête autant, mais je préfère avoir un soft qui fonctionne bien et qui n'aie pas une allure de logiciel bricolé.
Je suis ouverte à tous avis sur ce diagramme et sur les procédés développés !
Here's the beast:
Spoiler:
montrer
Là, je dois avouer être à moitié satisfaite d'avoir une classe EntityManager pour gérer tout le bourzin lié au projet. Vous pouvez voir qu'il est possible d'étendre le système pour gérer les projets (et donc éventuellement externaliser les managers). J'ai enlevé des méthodes, mais des classes comme Sheet ont des méthodes comme Sheet::save().
Pour le système d'unité, je considère que chaque "champ" possède une unité, facilitant les conversions. Si cette unité est numérique, on pourra effectuer des conversions. Je rajouterai également une classe "CommonUnit" et "CalendarUnit".
Pour la sauvegarde : je crée des sous-dossiers, et chaque instance de classe effectue sa sauvegarde : il y a un fichier xml par template, par fiche (sheet), par note. Pour les sections et catégories c'est un peu plus compliquer. La classe Project possède une méthode Project::filter() qui permet de filtrer les entrées dans la TreeView, et donc les cacher/afficher à notre guise, en fonction d'un texte entré (voir animation ci-dessous). Pour éviter d'avoir des itérations trop longues (en particulier sur les projets avec beaucoup de fiches), j'ai rajouté des grandes catégories que l'on peut cocher/décocher pour la mettre dans la recherche.
Spoiler:
montrer
Dans le modèle d'unités numériques j'ai inclus la possibilité d'éditer ses propres dimensions (ou grandeurs) fondamentales (vous savez, les MLTINThetaK) ; c'est d'ailleurs à peu près à l'aide de ça que le système effectue une vérification d'homogénéité.
Enfin, j'ai omis ce qui est lié au GUI ; je compte revoir ça avec QML.
Pour la petite note, mes mutateurs et accesseurs sont faits via des décorateurs, en Python. C'est plus élégant, d'un côté.
Si vous avez des questions, n'hésitez pas. Et des critiques, hésitez encore moins !
EDIT : après une nuit de repos et un peu de recul, je me rends compte que la répartition en grandes catégories (Fiches, Templates, Cartes, Notes, etc.) est caduque. En réalité j'ai repris l'idée d'Articy, dans quand on y réfléchit ça complexifie le modèle et implique d'avoir une classe héritée (SectionManager, car chaque section est reliée à une grande catégorie).
Je pensais faire une barre d'onglet sur la gauche, sous forme d'icônes, permettant d'accéder aux entités (fiches/templates), aux grandeurs (unités/grandeurs/constantes), aux outils relationnels (graphes/tableaux), à la cartographie, et à la configuration générale du projet (je ferai un illustration un de ces quatre).
Pour le coup ça m'a permis de revoir un peu les choses. Mieux vaut que ce soit maintenant ; et en plus je peux reprendre sans problème ma base de code.
Je sais que je pourrais ne pas me casser la tête autant, mais je préfère avoir un soft qui fonctionne bien et qui n'aie pas une allure de logiciel bricolé.