Discussion :

[handsome01]

Salut tout le monde,
Je sais pas si je suis sur la bonne section ou non, alors je vous prie de m'excuser
Je suis entrain de réaliser une application desktop, on peut dire une initiation a la création d'un petit ERP. Mon grand soucis est comment dois je me procéder à sa réalisation.
Voici donc mes questions :

L'application doit être composée de modules : Quels sont les techniques valables dans le cas ou le programme doit permettre d'ajouter ou d'enlever de nouveaux modules sans pour autant modifier les modules existant ?

[EDIT] Exemple :

je vous donne un exemple :

un module M1 pour la gestion du personnel d'un organisme... et un autre M2 pour la gestion équipements informatiques
au Niveau de la base de données y'aurai une liaison entre les informations provenant des deux modules...

Si on suppose qu'un organisme n'utilisera que le module M1 il n'aura pas besoin qu'on lui livre le module M2. Mais si par la suite il décide d'etendre le soft, je suppose qu'on devrai uniquement ajouter le M2 sans pour autant réinventer toute la roue ou bien de modifier tout le soft pour une extension des services de l'organisme.

Existe il des méthodes pour cela ?

Où puisse je trouver la documentation pour comprendre ?

Est ce que chaque module doit avoir sa propre Base de données ou bien une seule base de données pour tous les modules ?


Merci d'avance pour vos précieuses réponses.

[DonQuiche]

Bonjour. La question étant assez vague et non-spécifique à un seul langage, voici quelques éléments de réponse :
* Typiquement les modules ont chacun leur propre dll et on découvre celles-ci par une inscription ou en scannant un répertoire. Avec des langages dans lesquels la réflexion est disponible, on exploite cette dernière pour détecter les types implémentant une certaine interface. Par exemple un "IPlugin", en héritant depuis une dll commune aux modules et à l'application.

* On utilise ce qu'on nomme l'injection de dépendances : le programme principal offre aux modules un moyen d'injecter des dépendances dans les points d'extension définis. Cherche "injection de dépendance", "inversion de contrôle", les motifs "factory", "abstract factory", "service locator" ou encore "facade". Note que tous les langages ont leurs frameworks dédiés à l'injection de dépendances, autant ne pas réinventer la roue.

* Je n'ai jamais eu à traiter le cas de modules ajoutant des données à une table mais j'imagine qu'il faut de facto partager une même DB pour éviter la redondance des données, préserver les qualités ACID et obtenir des performances décentes sur les jointures et compagnie. Bien que l'idée soit séduisante il me semble difficile d'avoir plusieurs bases de données.

[handsome01]

D'abord merci pour les précieuses informations : je vais commencer de me documenter sur les points que vous m'avez dit.
J'ai d'autres questions : D'après vous, quel sera le/les meilleur/s langage/s a prendre en considération permettant ainsi d'utiliser les points cités ?

Y'a t'il des cours une documentation permettant de bien assimiler les principes de base ?
Pourriez vous m'orienter par des liens ?

Merci

[souviron34]

Bonjour


Concernant la question initiale, qui est trop vague, plusieurs pistes sont utilisées, suivant les cas....

• Tout d'abord, sur le "créer".. Cette appellation recouvre la conception, qui est indépendante du langage. Pour avoir un logiciel extensible, il faut :
  
  
  
  • analyser les points où il y aura potentiellement extension (données, fonctionalités, etc)
    
    
  • définir suivant les cas des "protocoles" de communication (API si un seul exéctuable et des biblothèques, vrais protocoles si plusieurs exécutables communiquent, etc)
    
    
  • prévoir les fonctionalités - ou structures - pour pouvoir accueillir différent types de choses (potentiellement inconnues)
  
  
  
  
  
• Ensuite vient le temps de la programmation, de l'implémentation. Là encore, cela dépend des cas et des options choisies...
  
  
  
  • ça peut être des fonctionalités, stockées dans divers modules... Qu'ils soient dépendant des compilations (via des bibliothèques), du run-time (DLL : cas particulier), des appels à des logiciels externes (plugins, serveurs externes), etc...
    
    
  • ça peut être des données
    
    
  • ça peut être des services (fonctionalités "inconnues") renfermées dans d'autres exécutables fournis en liste de config ou en paramètres d'appels, ou en liste dynamique (de répertoire ou autres). ou des séries de serveurs (grappes)
    
    
  • Divers moyens d'y accéder/de les appeler peuvent être utilisés : le nom de la fonction est connu (biblothèques ou DLL), inconnu (appel à un autre exécutable, ou un plugin) (dans les outils d'IHM par exemple une fonctionalité de base d'un bouton est le changement des bordures "3D", mais on peut y ajouter (enregsitrer) des "callbacks" sur les "onclick" par exemple... Dans certains softs, on associé une extension d'un type de fichiers avec un "soft" dont juste le nom est donné (par exemple "mpeg = > player"), mais les fonctionalités sont inconnues etc etc....
    
    
  • Enfin, suivant le langage choisi, diverses options existent là aussi : arguments "void" en C, surcharges, classes, créations dynamiques, arrays ou listes dynamiques dans d'autres langages, etc etc...
  
  

:
* Typiquement les modules ont chacun leur propre dll

Tu me sembles bien trop spécifique...

[DonQuiche]

Tu me sembles bien trop spécifique...

"Typiquement" veut dire "typiquement", ni plus ni moins.

[handsome01]

Merci d'avoir répondu a mes questions :

En effet, étendre la base de données est possible... j'ai pris cette condition en considération. et pour vos explications je les ai noté.

Mon soucis majeur n'est pas dans la réalisation de l'application, mais plutôt sur la manière dont laquelle elle sera réalisée, c'est d'ailleurs la raison qui m'a poussé a ouvrir cette discussion.

j'aimerai donc si c'est possible savoir si je devrai choisir JAVA comme langage a coder mon application, quelles seront les bonnes pratiques que je devrai respecter afin de réaliser un soft que nous pouvons l'étendre :

je vous donne un exemple :

un module M1 pour la gestion du personnel d'un organisme... et un autre M2 pour la gestion équipements informatiques
au Niveau de la base de données y'aurai une liaison entre les informations provenant des deux modules...

Si on suppose qu'un organisme n'utilisera que le module M1 il n'aura pas besoin qu'on lui livre le module M2. Mais si par la suite il décide d'étendre le soft, je suppose qu'on devrai uniquement ajouter le M2 sans pour autant réinventer toute la roue ou bien de modifier tout le soft pour une extension des services de l'organisme.

quels seront les moyens que je devrai employer afin d'arriver a un résultat similaire de cette exemple ?

et si des technises existent, j'aimerai avoir des pistes pour assimiler les principes de base

Merci encore une fois.

[souviron34]

et si des technises existent, j'aimerai avoir des pistes pour assimiler les principes de base

Principes de base :

• séparer les choses n'ayant pas de rapports entre elles....
• concevoir les rapports comme des relations éphémères, modulables

Donc dans ton cas :

• Une base équipement
• Une base personnel
• Eventuellement une base organisme

Il serait pour le moins étrange qu'un organisme n'ait NI personnel NI équipement, non ???

Il serait non moins étrange qu'un individu du personnel, si il change de bureau au cours de sa vie, garde le même équipement, non ?

De même, il serait tout aussi étrange que si un équipement est défaillant, ou remplacé, il faille modifier la base du personnel....

Ou que si un nouvel employé arrive, et que il y a un stock d'équipements inutilisés, il faille recréer une entrée dans la base des équipements....

[handsome01]

Merci d'avoir repondu :

vos suggestions sont logiques, mon exemple n'était qu'à titre informatif... ce que je cherche ce n'est pas ce qu'il faut avoir mais plutôt comment utiliser les bonnes pratiques afin de réaliser le bon soft.

Merci

[handsome01]

D'autres suggestions SVP ?

[souviron34]

Principes de base :

• séparer les choses n'ayant pas de rapports entre elles....
• concevoir les rapports comme des relations éphémères, modulables

On peut ajouter :

éviter au maximum ce qui dépend des langages et paradigmes et outils (que ce soit dans l'architecture logicielle, répertoire, la dexription fonctionelle, etc)...

En gros, cela revient à faire une analyse fonctionnelle PROPRE....

[el_slapper]

(.../...)
En gros, cela revient à faire une analyse fonctionnelle PROPRE....

...mais pas gravée dans le marbre. Une erreur est si vite arrivée...

[souviron34]

...mais pas gravée dans le marbre. Une erreur est si vite arrivée...

oui, mais vu le titre du fil, ce que j'appelle "propre" est "propre intellectuellement", c'est à dire prévoyant des "futurs", des "branches", des "instances", non précis.... Pour moi c'est ça, propre...Et donc forcément c'est "souple"...