MALIN Nicolas DESS SIRAD. Rapport de Stage. Septembre /61

Transcription

1 MALIN Nicolas DESS SIRAD Rapport de Stage Septembre /61

2 Table des matières 1. Introduction Présentation de l'entreprise Objectifs du Stage...5 PREMIERE PARTIE : OFBiz 1. Découverte d'ofbiz Fonctionnement général d'ofbiz...7 Architecture...7 Organisation d'un module...8 Architecture d'un module...8 Description des fichiers et répertoires...9 Cheminement lors d'une requête...10 Mon intervention sur OFBiz Forces et faiblesses du PGI...14 Ses Forces...14 Ses Faiblesses...15 Mon sentiment sur le PGI La naissance d'un projet : Neogia...16 Un changement de programmation...16 Qu'apporte LutinGenerator dans le cas d'ofbiz?...17 Ce que remplit Neogia...17 Une conception de haut niveau...18 Une programmation orientée Objet...18 Un gain de temps sur le développement...18 Une réactivité du développement...18 Au final Fonctionnement de Neogia...19 L'arborescence de fichier...19 Explication de l'arborescence de Neogia...20 Les dépendances du projet...21 Comment fonctionne la génération Création du module de comptabilité...22 Diagramme UML...22 Diagramme de classe : CharOfAccount...23 Diagramme de classe : AccountingTransaction...24 Première génération...24 Création de l'arborescence du module...25 Développement du module...25 Renseigner le model UML...26 Effectuer le développement spécifique...26 Dans le cas de la comptabilité...28 Les comptes comptables (NGlAccount)...28 Les périodes comptables (GlPeriod)...28 Les transactions (AcctgTransaction)...28 Les écritures (AcctgTransactionItem) Les lignes d'écritures (GlEntry)...29 Les problèmes d'intégration dans OFBiz...29 Un projet en pleine croissance...29 Au niveau de la licence Conclusion /61

3 DEUXIEME PARTIE : REORGANISATION DE L'INFRASTRUCTURE DE NEREIDE 1. Description de l'existant et des besoins...32 Structure du réseau existant...32 Quels besoins doit couvrir la nouvelle architecture? Analyse des choix pour une nouvelle architecture...33 Harmonisation des systèmes d'exploitation...33 Authentification centralisée des utilisateurs...35 Centralisation des données utilisateurs...36 Sécurisation du réseau...37 Protection du réseau des attaques extérieures Sécurisation des informations...37 Continuité des services du réseau de Néréide Nouvelle architecture du réseau de Néréide...40 Services réseau offerts Mise en place de la nouvelle architecture...42 Première étape : passage sur un serveur auxiliaire...42 Deuxième étape : une migration progressive...42 Dernière étape : le basculement final Les sauvegardes...42 Le script de synchronisation des disques: vue_journaliere.sh...43 Le script de sauvegarde sur le serveur secondaire : balance_push.sh Problèmes rencontrés...44 Le serveur LDAP...44 Le serveur DNS : MaraDNS...44 Migration des données utilisateurs...44 Erreur humaine ou piraterie réussie Une migration non finie Conclusion...45 Conclusion du stage...47 Remerciements...47 Bibliographie...49 Références utilisées dans le cadre du développement Sites internets...49 Livre O'reilly...49 Autre livre...49 Références utilisées dans le cadre de la migration du réseau de Néréide...49 Sites internets...49 Livre O'reilly...49 Annexes 1.Migration du réseau de Néréide...51 But du document...51 Etapes de la migration...51 Première étape...52 Export des répertoires via NFS...52 Configuration de la machine cliente (imbros)...53 Reallocation des $HOME :...53 Après réallocation des $HOME des utilisateurs, /61

4 Deuxième étape...54 Troisième étape...55 Quatrième étape...55 Migration du service ldap...55 Migration des services de fichiers...55 Migration des données...55 Re-positionnement du serveur...55 Cinquième étape...56 Préparation de la migration...56 Migration des machines Migration de serveur principal pour la nouvelle architecture réseau...57 But du document...57 Analyse de l'existant...57 /dev/hda : /dev/hdc :...57 Étapes de la migration de serveur principal...58 Installation de Debian Sarge sur serveur principal...58 Sauvegarde des données restante...58 Réorganisation des disques durs de serveur principal...58 Installation des services...58 Configuration des services...59 Migration des données utilisateurs Sauvegarde des données du serveur...60 But du document...60 Deux types de sauvegarde...60 Sauvegarde disque à disque Explication...60 Fonctionnement de la sauvegarde...60 Fonctionnement du script...60 Sauvegarde sur serveur secondaire...60 Explication...60 Fonctionnement de la sauvegarde /61

5 1. Introduction L'informatique d'entreprise a longtemps ignoré les logiciels libres, pas assez "pro", pas assez sérieux, pas assez rémunérateur. Actuellement, le système d'éditeur de logiciel propriétaire entame un déclin dû à un coût de licence prohibitif. En effet, les entreprises qui investissent dans des solutions logicielles propriétaires pour améliorer leur système d'information, doivent justifier auprès de leur direction des retours sur investissement. Le peu d'argument expliquant le coût de licence de ces logiciels devient flagrant. De plus en plus de chefs d'entreprise arrivent effectivement à ce constat. Seule, les offres de service associées trouvent des justifications. Les logiciels libres commencent à prendre une part de marché dans les logiciels d'entreprise. Ceci est particulièrement vrai pour les serveurs, et commence timidement pour la bureautique. Il reste des secteurs où des solutions libres ne sont pas encore disponibles et notamment dans le secteur des Progiciels de Gestion Intégré. Néréide est une Société de Services du Logiciel Libre, spécialisée dans le domaine de l'intégration de PGI open source à destination des PME, qui m'a prise en stage dans le but de m'investir sur le développement d'un PGI libre nommé OFBiz. Mon travail doit, dans un premier temps, porter sur la compréhension du fonctionnement du PGI sur la couche fonctionnelle, puis sur le développement d'un module de comptabilité. Néréide étant une société naissante, mon maître de stage m'a confié la tâche de réorganiser leur réseau de façon à le rendre plus performant et plus souple par rapport à leurs méthodes de travail. 2. Présentation de l'entreprise Néréide est une SSLL sous le statut SARL. Créée en mars 2004, elle comporte 4 personnes et couvre principalement la mise en oeuvre, le développement et les services sur le PGI libre à l'attention des PME : OFBiz. 3. Objectifs du Stage Premier Objectif : Comprendre le fonctionnement du PGI Libre OFBiz et y développer un module de comptabilité. Second Objectif : Mettre en place une nouvelle architecture réseau opérationnelle pour la société Néréide. 5/61

6 PREMIERE PARTIE : OFBiz 6/61

7 1. Découverte d'ofbiz OFBiz est un Progiciel de Gestion Intégré libre, développé sur une architecture JAVA - J2EE. Son développement a été pensé dès le début pour être le plus modulaire possible, surtout avec l'utilisation de technologie libre pré-existante. Ainsi OFBiz est compatible avec : - tous les serveurs d'applications J2EE ( Jboss, Tomcat, Jetty, etc... ) - toutes les bases de données (MySql, PostgresSql, SapDB, Firebird, DB2, etc...) De plus, il utilise de nombreux projets libres, dont : Jetty : serveur d'applications par défaut Jpublish, Freemark, BeanShell : pour la gestion des écrans utilisateurs HyperSonicDB: base de données par défaut Jasper Report : génération de fichier pdf OFBiz fonctionne sur une architecture J2EE orientée web via l'utilisation des servelets donc le client a juste besoin d'un navigateur internet quelconque pour pouvoir se connecter au PGI. 2. Fonctionnement général d'ofbiz Architecture OFBiz repose sur une architecture à plusieurs niveaux où chaque niveau est spécialisé dans un domaine. Applications Composants applicatifs de base Composants applicatifs - techniques Composants techniques de base J2EE container SGBD Java OS Chaque niveau possède des éléments spécialisés dans une fonction. Le niveau nous intéressant étant les composants applicatifs. 7/61

8 Comptabilité Générale Gestion Commerciale Gestion Maintenance Applications Composants Acteur applicatif de base Commun Contenu Sécurité Services ECA Entity WorkFlow Employé - Ressource Humaine Gestion Projet Relation Client Relation Fournisseur Gestion du service E-Commerce Comptabilité Analytique Comptabilité Tiers Article Ordre Stock Tâche Comptabilité Trésorerie Catalogue Produit Gestion Achat Gestion Production J2EE container SGBD Java OS Ce niveau est structuré en modules qui ont pour spécialisation une application métier de l'entreprise. Organisation d'un module Un module est un programme fonctionnel s'appuyant sur les couches techniques du PGI. Le module contient toutes les informations nécessaires à son bon fonctionnement : description des entités, source java, description des services, fichier de définition d'écran, etc... Toutes ces informations sont organisées dans une arborescence propre au module. Cette arborescence la même structure quelque soit le module et sera détaillée au chapitre suivant. Les modules peuvent inter-agir entre eux via des mécanismes simples (service), permettant de bien spécialiser les fonctionnalités de chacun. Architecture d'un module Les modules sont tous structurés de la même façon. Ci-dessous suit une présentation de l'architecture d'un module d'ofbiz : module +- config +- data +- entitydef +- lib 8/61

9 +- servicedef +- src +- webapp `-module +-error +-sous-module +-templates +-WEB-INF +-actions +-pagedefs -controller.xml -jpublish.xml `-web.xml `-login.ftl `- OFBiz-components.xml Description des fichiers et répertoires module : config : ce répertoire contient les fichiers d'internationalisation et les fichiers «properties» de configuration. data : ce répertoire contient des fichiers xml de données utilisateurs relatif au module. Ces données sont d'ordre d'obligation ou de démonstration entitydef : ce répertoire contient deux fichiers qui décrivent les entités qu'utilisent ce module. Ces fichiers sont directement utilisés pour la description et la construction des tables de la base de données. servidef : ce répertoire contient un fichier, services.xml qui associe des fonctions java, ou d'autres langages, présentes dans les sources du module à un nom de service. src : ce répertoire contient les sources des fichiers java relatif au module. C'est dans ces fichiers que sont définies les fonctions appelées via le fichier services.xml. webapp : ce répertoire contient une arborescence de fichiers qui sont utilisés pour la génération des écrans utilisateurs. OFBiz-components.xml : ce fichier décrit le module pour son intégration dans OFBiz. module/webapp/module : error : ce répertoire contient les messages à afficher suivant 9/61

10 l'erreur générée par le serveur d'applications. sous-module : un module est organisé en sous-parties, suivant l'application faite dans le module avec un objectif de description. Ce répertoire contient les fichiers de structure des forms et les fichiers de structure d'écrans utilisateurs (fichiers ftl). templates : ce répertoire contient les fichiers de structure de base comme l'écran d'accueil du module ou encore les écrans de recherche. WEB-INF : ce répertoire contient une arborescence contenant les fichiers effectuant les traitements nécessaires sur les informations avant leur affichage. login.ftl : ce fichier décrit la structure de l'écran de connexion au module. module/webapp/module/web-inf : actions : ce répertoire contient des fichiers source java interprétés : des fichiers beanshell. Ces derniers servent à remplir le contexte d'informations, nécessaire à l'affichage des informations dans les écrans utilisateurs. Ces informations peuvent provenir d'un appel à la base de données ou d'un traitement quelconque sur des informations déjà présentes dans le contexte. pagedefs : ce répertoire contient la définition d'un écran utilisateur. Ceci comprend les informations initiales et/ou à rajouter au contexte pour l'utilisation de cette page ainsi que diverses définitions des fichiers de structure et des fichiers BeanShell à appeler pour la génération de l'écran. controller.xml : ce fichier met en relation les urls envoyées par le client et la page à renvoyer. Cette page est le résultat d'un enchaînement d'opérations qui sont indiquées dans ce fichier. jpublish.xml : fichier de configuration pour la fusion du contexte avec les fichiers de strucutre ftl. web.xml : configuration du serveur web. Deux fichiers sont extrêmement importants dans un module : le fichier controller.xml et le fichier services.xml. Le premier : controller.xml sert à OFBiz pour savoir quel service et action puis quelle vue doit être appelés suivant une requête effectuée. Le second : services.xml sert à OFBiz pour mettre en relation l'appel à un service et la fonction associée se trouvant dans les sources du module Cheminement lors d'une requête Le développement effectué sur OFBiz ne se situe pas dans les couches basses du PGI mais au niveau de l'interaction entre l'utilisateur et OFBiz, sur la partie fonctionnelle. Pour cela, il est nécessaire de bien cerner l'ordre des fichiers qu'ofbiz va lire suivant une requête afin de construire la page de réponse. 10/61

11 Voici le cheminement d'une requête simple pour la construction de l'écran en réponse. L'utilisateur saisit un objet et valide son édition : 11/61

12 1) L'utilisateur valide l'édition de l'objet; la requête est alors envoyée au serveur d'application d'ofbiz. A la réception de la requête, le serveur lit le fichier controller.xml du module concerné pour savoir ce qui doit être exécuté. Voici les lignes nous intéressants, contenues dans le fichier controller.xml : <request-map uri="editobjet"> <security https="true" auth="true"/> <event type="service" invoke="editobjet"/> uri reçu par le serveur service appelé <response name="success" type="view" value="editobjet"/> <response name="error" type="view" value="editobjet"/> </request-map> retour du service et action à effectuer <view-map name="editobjet" type="jpublish" page="/sousmodule/editobjet.ftl"/> Ecran à générer via le fichier ftl indiqué 2) Suivant les informations contenues dans le fichier controller.xml, un service et/ou une création d'écran est appelé. Création de l'écran de réponse : Le fichier controller.xml indique le chemin vers un fichier, ici EditObjet.ftl. Ce fichier va servir de structure pour l'écran de retour. Est associé implicitement à ce fichier, un autre fichier : EditObjet.xml, qui définit diverses informations de l'écran. C'est à partir de ce fichier que sont mentionnés différents fichiers qui vont être lus pour remplir le contexte des informations nécessaires et ainsi satisfaire la demande. Voici en exemple le contenu du fichier EditObjet.xml: <page> <template>main</template> <property name="titleproperty">editobjet</property> <property name="headeritem">exemple</property> <property name="submenu">/exemple/tabbarobjet.ftl</property> <property name="viewsize">20</property> <property name="permission">objet</property> <property name="entityoperation">_update</property> <property name="permissiontype">simple</property> <content-action name="/includes/checkpermission.bsh"/> <content-action name="/exemple//editobjet.bsh"/> 12/61 propriétés de la page mises dans le contexte Liste des fichiers bsh à appeler pour le remplissage des informations dans la page

13 <content-action name="/includes/pagelistprep.bsh"/> </page> Appel d'un service : Lorsqu'un service est appelé, OFBiz lit le fichier service.xml du module afin de déterminer la fonction à appeler. Voici l'entrée de notre exemple : <service name="editobjet" default-entity-name="objet" engine="java" location="org.ofbiz.exemple.sousmodule.objetservices" invoke="editobjet" auth="true"> description de <description>editer un Objet</description> l'appel de fonction <auto-attributes include="all" mode="inout" optional="true"/> <attribute name="actionform" type="string" mode="in" optional="false"/> </service> description des paramètres passés à la fonction et ses valeurs de retour 3) Les différents fichiers bsh (beanshell) sont appelés dans l'ordre de leur rencontre dans le fichier de description de la page (EditObjet.xml dans notre cas). Dans ce dernier se trouve aussi le chemin vers un fichier de form. Ce fichier FormObjet.xml, dans notre cas, contient les différentes formes qui peuvent apparaître pour l'affichage de l'écran. Durant l'exécution des fichiers bsh, diverses informations sont inscrites dans le contexte. Ces dernières peuvent provenir des résultats d'une recherche dans la base de données, d'un appel de fonction ou encore de l'utilisation d'algorithme. Voici un exemple de la description de la forme pour l'editobjet contenue dans le fichier FormObjet.xml: description de la forme, notamment l'uri appelé lors du submit <form name="editobjet" type="single" target="editeditobjet" title="" default-map-name="formsdata" default-title-style="tableheadtext" default-widgetstyle="tabletext" default-tooltip-style="tabletext"> <field name="actionform"><hidden value="commit$ {actionform}"/></field> <field name="description" title="${uilabelmap. ExempleDescription}"><text/></field> <field name="submitbutton" title="${uilabelbutton}" widgetstyle="smallsubmit" ><submit button-type="button"/></field> </form> bouton de liste des champs soumission de la forme 13/61

14 4) Le fichier EditObjet.bsh effectue les opérations nécessaires sur les données à afficher, appelant le cas échéant des fonctions java, puis met en relation la forme et les données, ensuite injecte le tout dans le contexte. 5) OFBiz transpose le contenu du contexte avec la structure contenue dans le fichier EditObjet.ftl. Le flux obtenu en sortie est transmis au serveur d'application qui l'envoie à l'utilisateur. Mon intervention sur OFBiz Au début du mois d'avril, M. Heintz travaillait sur la création d'un module de gestion de production. J'ai donc participé à ce développement sur de petites parties afin de découvrir au fur et à mesure le fonctionnement d'ofbiz. Ce travail a consisté à modifier ou créer des écrans utilisateur, comme l'ajout d'un bouton de recherche, la traduction d'une page, etc... Ces petits exercices de découverte du PGI m'ont fait appréhender un bon nombre des technologies mentionnées ci-dessus et m'ont permis de comprendre la philosophie du PGI ainsi que d'entrevoir ses forces et ses faiblesses. 3. Forces et faiblesses du PGI Ses Forces Une des grandes forces du PGI est sa modularité. Chaque requête passe tout d'abord par un contrôleur qui résout la demande suivant les indications d'un fichier xml. Ce procédé rend la gestion des requêtes d'une grande simplicité, tout en permettant une grande amplitude de mouvement pour la résolution d'une requête. L'indépendance entre chaque niveau du PGI implique des configurations plus nombreuses afin d'obtenir une abstraction du fonctionnement entre différents niveaux. L'utilisation de nombreuses interfaces et façades permet aux développeurs de se concentrer uniquement sur le niveau développé. La gestion des accès à la base de données est réalisée par une façade. Cette dernière utilise énormément la mise en cache afin d'optimiser les accès fréquents à une table. La modularité du PGI fait qu'il évolue souvent dans les couches inférieures, en utilisant de nouvelles technologies. Ses Faiblesses 14/61

15 OFBiz est développé dans un langage de programmation fortement orienté objet qui est : JAVA. Lors de mon apprentissage du PGI, j'ai eu énormément de mal à en comprendre le fonctionnement dû à une utilisation non conforme, par rapport à la philosophie de ce langage. Alors que les couches techniques sont bien développées sur le modèle objet, l'utilisation des tables de la base de données via la façade se fait par interrogation directe. Les entités de la base ne sont pas générées comme un objet. Ceci implique que la programmation des fichiers bsh et java des modules est développée sur un modèle relationnel. On se retrouve à faire un développement en relationnel sur un langage objet. Personnellement, lors de la réalisation de projet durant mon cursus informatique, j'ai beaucoup plus utilisé l'approche objet pour la conception et la programmation que l'approche relationnelle. Cette dernière approche ne me paraît pas adaptée pour des développements de cette importance. Cette non compréhension a impliqué que, lors de mes nombreuses rencontres avec M. Heintz pour l'apprentissage d'ofbiz, nous avions du mal à nous comprendre, puisque lui ne connaissant pas beaucoup la modélisation objet et moi ne comprenant pas l'utilisation d'une approche relationnelle dans un langage objet, nos visions n'étaient pas concordantes. Il nous a fallu un bon mois pour arriver à bien nous comprendre. La modularité du PGI en fait sa force mais aussi sa faiblesse. Pour le développement d'un module, de nombreux fichiers sont à renseigner, et souvent d'informations répétitives. Cette quantité d'informations à renseigner dans les différents fichiers implique un risque de fautes de frappe non négligeable qui conduisent un débuggage souvent long pour des erreurs minimes. Lors de mon intégration au développement du PGI, je me suis retrouvé avec une quantité de technologies et de concepts totalement nouveaux comme les freemarkers ou encore les bsh. Pour les technologies externes au projet OFBiz, la documentation se trouve souvent sur les sites officiels. Lors de technologie propre à OFBiz, une documentation n'est pas toujours présente, surtout dans le cas de technologies récentes ou avancées. Ainsi, on se retrouve souvent à regarder les fichiers sources des développeurs principaux du projet, afin de cerner l'utilisation de certaine API ou autres technologies. Dans certain cas, l'utilisation de technologies développées n'est pas encore faite par ces développeurs. Dans ce dernier cas, la seul solution pour comprendre les fonctionnalités d'une technologie est d'effectuer les testes pas à pas afin d'en analyser les résultats mais ceci est très coûteux en temps. Mon sentiment sur le PGI OFBiz est un PGI possédant un potentiel vraiment important avec une conception technique vraiment poussée. Mais cette capacité est aussi son défaut puisque les développeurs travaillent beaucoup plus sur cette technique au détriment de la partie fonctionnelle du PGI. Le manque de documentation sur les technologies avancées, de même que l'utilisation d'une approche relationnelle et le nombre important de fichiers à renseigner, font que le développement des interfaces utilisateurs n'est pas vraiment d'une grande facilité, ce qui est surprenant au vue des efforts faits pour l'abstraction des niveaux inférieurs du PGI. 15/61

16 4. La naissance d'un projet : Neogia Les développements à venir sur OFBiz ne concernent que le dernier niveau du PGI : la création de la couche métier. Or, les faiblesses indiquées au chapitre précédent ne nous poussent guère à lancer un développement massif pour combler les manques fonctionnels du PGI. C'est pour ces raisons que début mai commença un nouveau projet nommé Neogia. Que doit apporter Neogia afin de faciliter le développement de la couche métier : une sur-couche objet pour appliquer un développement objet et ignorer la structure de la base de données. remplir automatiquement le plus de fichiers de configuration possibles dont les informations sont répétitives, pour les écrans standard. Un changement de programmation Neogia utilise un projet nommé LutinGenerator, développé par l'entreprise Code Lutin, qui est un «préparateur» à la génération. LutinGenerator fonctionne en deux temps : 1 er temps : LutinGenerator lit des fichiers scripts, typés sur java, et construit une librairie avec les informations contenues dans ces fichiers. 2 ème temps : LutinGenerator lit un diagramme de classe UML et formate le flux récupéré. Ensuite le formatage est appliqué à la librairie qui génère une structure de fichiers sources définie. Quels sont les intérêts de LutinGenerator : La génération se fait à partir d'un diagramme de classe UML, ce qui apporte une conception du logiciel de haut niveau. La génération n'est pas figée à un langage de programmation comme beaucoup de logiciels de création de schéma UML. Les générateurs sont écrits suivant ce que l'on désire générer, avant la première génération du diagramme. Qu'apporte LutinGenerator dans le cas d'ofbiz? La génération de fichier peut vraiment être intéressante dans le cas d'ofbiz puisque le nombre d'informations génériques à renseigner dans les différents fichiers de configuration est assez important. Ceci peut faire gagner un temps énorme en terme de développement. L'utilisation d'un diagramme de classe UML est aussi non négligeable. Actuellement, le développement d'un module (notamment celui de manufacturing) se fait sur la connaissance de l'informaticien fonctionnel, en l'occurrence M. Heintz. Les autres développeurs, en cas d'incertitude dans l'avancement du projet, doivent souvent le déranger pour savoir quelle direction prendre afin de ne pas développer hors du contexte. Je parle notamment pour ma personne puisque ne connaissant pas du tout le monde de l'entreprise de production, l'incertitude était vraiment grande (couplé à une découverte au fur et à mesure d'ofbiz et un développement 16/61

17 en relationnel : un vrai bonheur). Le manque d'ingénierie logiciel dans un tel développement se fait cruellement ressentir et une conception UML des modules ne peut être qu'un plus pour faciliter et structurer le développement, sans parler des nombreux apports à l'utilisation d'une conception de haut niveau. Ce que remplit Neogia Neogia est une sur-couche d'ofbiz dont le développement s'effectue en parallèle du développement de ce dernier. Il a pour objectif de combler les faiblesses d'ofbiz pour le développement de la couche fonctionnelle du PGI et d'en accélérer son évolution. Neogia est un ensemble de composants complémentaires à la plate-forme d'application d'entreprise OFBiz. Ces composants sont de 3 types: Des composants fonctionnels soient en tant que composant nouveau, soient remplacant un composant OFBiz existant. manufacturing : remplace le composant OFBiz existant, c'est une refactorisation de celui-ci, avec la définition d'un modéle UML propre et une ré-écriture compléte du code. facility : remplace le composant OFBiz existant pour toute la gestion des stocks, il n'inclut pas la gestion des expéditions qui reste réalisée par OFBiz. Il fournit une gestion des inventaires physiques complète. Ce composant est apparu suite à une refactorisation complète du modéle de données réalisé avec UML permettant de gérer les stocks actuels et planifiés. accounting : remplace le sous-composant OFBiz existant, pour la gestion comptable et analytique. La modélisation UML est entièrement nouvelle. La gestion des paiements reste réalisée par OFBiz servicemgnt : nouveau composant permettant de gérer des activités de service ou de projet. Le composant étant nouveau, son modéle UML est également nouveau. Des composants permettant de se connecter aux composants OFBiz existants. Les diagrammes UML reprennent les éléments de OFBiz. common : utilisé pour les liaisons avec les entity enum et status content : utilisé pour unifier certaines règles de développement et pour la gestion des champs en multi-langue. order : utilisé pour accéder aux objets commandes et ligne de commandes party : utilisé pour accéder aux objets acteurs, rôle, acteur-rôle et adresse, et aux objets communications product : utilisé pour accéder à l'objet article et pour la liaison entre OFBiz et le composant facility de Neogia Un composant technique, permettant de générer la majeure partie du code OFBiz à partir des diagrammes de classe UML. Cela permet d'avoir des 17/61

18 composants développés à partir d'une modélisation objet. La génération permet de généraliser les bonnes pratiques OFBiz et mets à disposition des développeurs les éléments nécessaires au développement objet. Les développements complémentaires sont réalisés dans des sur-charges objets et pas sur les éléments générés garantissant ainsi la possibilité de régénérer certains éléments lors de l'apparition de nouvelle bonne pratique. Une conception de haut niveau L'utilisation de LutinGenerator implique l'utilisation de schéma UML. Chaque module développé dans Neogia est conçu depuis un schéma UML, et, pour être plus précis, d'un diagramme de classe, offrant ainsi une vue globale sur l'interaction entre entités et la direction du développement. Pour pallier à la limitation d'uml dans la description des informations nécessaires à la génération, des balises ont été définies. Une programmation orientée Objet Pour pallier au défaut du développement par approche relationnelle, une surcouche objet est généré par dans Neogia afin que le développement sur la couche fonctionnelle se fasse totalement indépendamment des tables de la base de données. Un gain de temps sur le développement La génération des fichiers remplace les tâches répétitives comme le remplissage des fichiers de configuration nécessaire au bon fonctionnement du module. Ainsi, le temps en développement est optimisé, tout en évitant toute sorte de bug lié à des erreurs de frappes. Une réactivité du développement J'ai déjà indiqué qu'ofbiz était en constante évolution grâce à l'intégration de nouvelles technologies. Bien que souvent ces améliorations ne touchent que rarement la couche fonctionnelle du PGI, dans le cas d'un changement majeur dans cette couche, comme le changement de la gestion des interfaces utilisateurs, il suffira de modifier les générateurs et de relancer la génération des modules pour avoir la nouvelle technologie intégrée. Il restera bien sûr quelques retouches, dans les 20% ou 30% de fichiers non générés mais le gain de temps pour intégrer une nouvelle technologie est vraiment important. Au final Le développement via Neogia des modules fonctionnels d'ofbiz permet : une conception de haut niveau de chaque module. une génération de 70% à 80% des fichiers sources nécessaires au fonctionnement du module. une écriture des fichiers sources propre, structurée et directement en 18/61

19 relation avec la conception. une sur-couche objet pour faciliter le reste du développement. 5. Fonctionnement de Neogia L'arborescence de fichier Neogia possède une arborescence de fichiers totalement séparée de celle d'ofbiz: neogia +- components +- module1 +- module2 +-dist +-target +-src +-build.xml +-project.xml +-project.properties `- maven.xml +- doc +- generators +-src +-target +- neogiaproject.xml +- project.xml +- project.properties `- maven.xml +- neogiaproject.xml +- project.xml +- neogiaofbiz.patch 19/61

20 +- maven.xml `- build.xml Explication de l'arborescence de Neogia Neogia : répertoire racine du projet components : ce répertoire contient tous les modules en développement qui seront intégrés à OFBiz module dist : ce répertoire contient le module développé de Neogia qui est opérationnel dans OFBiz (fichiers générés + développements spécifiques) src : ce répertoire contient le diagramme UML décrivant le module ainsi que quelques informations non générables comme des labels pour l'internationalisation du module target : ce répertoire contient les fichiers générés à partir du diagramme UML, une fois la génération finie. project.xml et project.properties : ce sont deux fichiers de configuration utilisés par LutinGenerator pour la génération maven.xml : fichier de configuration pour le lancement de la génération via maven build.xml : fichier d'instruction pour ant afin de déplacer les fichiers voulus dans l'arborescence d'ofbiz, utilisé seulement par les développeurs du module generators src : répertoire contenant les sources des générateurs target : répertoire contenant les générateurs compilés neogiaproject.xml, project.xml et project.properties : ce sont trois fichiers de configuration utilisés par LutinGenerator pour préparer les générateurs maven.xml : fichier de configuration utilisé par maven pour compiler les générateurs build.xml : ce fichier d'instruction ant déplace le contenu des répertoires components/*/dist vers l'arborescence OFBiz pour intégrer les modules Neogia dans le PGI. neogiaofbiz.patch : patch à appliquer à la racine d'ofbiz pour préparer le PGI à l'intégration des modules développés via Neogia project.xml et project.properties : ce sont deux fichiers de configuration utilisés par LutinGenerator pour la description du projet maven.xml : fichier de configuration pour la configuration du projet via maven. 20/61