Advanced Build System

La programmation orientée composants (POC) consiste à utiliser une approche modulaire au niveau de l'architecture d'un projet informatique, ce qui permet d'assurer au logiciel une meilleure lisibilité et une meilleure maintenance. On priviligie donc l'utilisation de briques réutilisables par opposition à des briques monolithiques. Dans notre contexte, un composant est :

Un projet est une application, il constitue le livrable finale. Il résulte de l'assemblage de plusieurs composants métiers. Il définit les environnements cibles appelés déploiements, ainsi que leur spécificités en terme de configuration.

Un déploiement est un environnement cible utilisé pour livré les war, tar.gz, jnlp. Il est possible de définir plusieurs déploiements au sein d'un même projet. Par exemple : Développement, Test, Pré-production, production ... Les déploiement sont stockés dans le fichier deployment.txt situé à la racine de l'arborescence du projet.

localhost
test
preprod
prod

Le fichier ci-dessous illuste la déclaration de 4 déploiements. Très souvent les environnements présentent des variantes en terme de configuration. Par exemple le serveur SMTP à utiliser pour envoyer un mail peut différer entre 2 environnements. Il est donc nécessaire de variabiliser cette information à l'aide d'un token de remplacement.

smtp.server.name=@@stmp.server.name@@

@@smt.server.name@@=test.mail.sharengo.org

@@smt.server.name@@=mail.sharengo.org

Les fichiers de replace ci-dessous permettent de positionner l'adresse du serveur pour chaque environnement.

La notion de module est équivalente à un composant mais est utilisé à l'intérieur d'un projet. La seule différence est la non réutilisabilité. Bien souvent, les modules sont utilisés uniquement pour définir les dépendances binaires et sources d'un projet. Vous pouvez également les utiliser pour définir du code source très spécifique au projet tels que les reprises ou migration de données. Les modules sont stockés dans le fichier moddep.txt situé à la racine de l'arborescence du projet.

main

Cette exemple illuste la déclaration du module main au sein d'un projet donné.

Nous avons vu en introduction que l'ABS définit des tâches correspondantes à la méthodologie de réalisation de projet. Ainsi il est possible de créer un projet en utilisant la commande abs new.project et en valorisant son nom. A chaque exécution de tâche l'ABS chargera le projet, composant ou module sur lequel porte votre action et l'injectera dans un template velocity contenant les instructions Ant nécessaire à la réalisation du traitement. Ainsi, un script Ant sera générée et exécuté ensuite. L'avantage de cette technique est qu'il n'y a pas d'adhérence forte entre les sources d'un composant ou d'un projet avec un outil de build quelconque. Si vous souhaitez changer le langage de scripting "Ant" par une autre moteur, c'est possible ! Il faut considérer l'ABS comme un "shell" qui vous permet d'invoquer différentes commandes dans le contexte d'un projet. De plus, il a l'avantage d'être très paramétrable et dispose d'un gestionnaire de package permettant de mettre à jour les postes utilisateurs, et donc de diffuser très rapidement de nouvelles tâches. Les développeurs ou autres utilisateurs n'ont plus besoin de modifier des scripts Ant, Maven ou autres lors de la réalisation d'un projet !

ABS requiert java en version 5 ou supérieure.

java -jar workshop-repository-manager-0.6.jar http://sharengo.org/abs/0.7/abs-core
java -jar workshop-repository-manager-0.6.jar http://sharengo.org/abs/0.7/mda
java -jar workshop-repository-manager-0.6.jar http://sharengo.org/abs/0.7/qa
java -jar workshop-repository-manager-0.6.jar http://sharengo.org/abs/0.7/doc

Si, vous souhaitez utiliser un proxy, utilisez ces options : java -jar workshop-repository-manager-0.6.jar repository-url [proxy port [user pwd] ]

TODO vérifier que cette commande existe encore, si oui la supprimer et créer un fichier build.properties par défaut.

cd $ABS_HOME
abs init

Répondre aux questions (Quelques valeurs par défaut sont proposé, laissez-les si vous ne savez pas répondre). Cette phase d'initialisation va créer un fichier build.properties dans votre répertoire ABS_HOME. Voici un exemple de build.properties :

binary.server.url=http://adk.open-model.org/adk-2.2/binary-components
binary-repository.path=/home/jeromeb/dev/abs/binary-repository
jvm.target=1.5

ci.server=build.argia.fr
ci.user=XXXX
ci.password=XXXX

Téléchargez la version d'eclipse Europa (3.3) correspondante à votre système : ici Démarrez eclipse, sélectionnez les menu "Help" -> "Software Updates" -> "Find and Install ..." :

Figure 2.1. Software updates screen shot

Choisissez "Search for news features to install" et cliquez sur "Next" :

Figure 2.2. Update sites screen shot

A l'aide du bouton "New Remote Site", ajoutez le site de mise à jour Sharen'Go : http://sharengo.org/update/europa, puis selectionnez-le et cliquez sur "Finish" Selectionnez ensuite les outils Sharen'Go dans la liste des fonctionnalités offertes et cliquez sur Next :

Figure 2.3. Install features screen shot

Accepter les licences et cliquez sur "Finish"

Un workspace est un espace de travail permettant de cloisonner vos contextes de travail. Il définit un espace physique de stockage d'un projet et de l'ensemble de ses composants dépendants. Une bonne pratique consiste à utiliser un workspace par version de projet. Ainsi lorsque vous réalisez une phase donnée d'un projet, vous devez créer un workspace. Ensuite lorsque vous commencerez une seconde phase, créez un autre workspace afin d'isoler la phase 2 de la phase 1. Ainsi si vous devez revenir sur la première, vous pourrez aisement relivrer une version n'intégrant que votre correction et non les évolutions liées à la phase 2. Vous trouverez ci-après un exemple de création de workspace.

$> cd $ABS_HOME
$> abs new.workspace

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.workspace:
    [input] Enter workspace absolute path :
/home/jeromeb/workspaces/ws-workspace1    

...

BUILD SUCCESSFUL
		

Tout d'abord, vous devez vous placer dans le workspace précèdement créé.

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.project

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.project:
    [input] Enter project name :
project1

...

BUILD SUCCESSFUL

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.scm.project

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.scm.project:
    [input] Enter project name :
project2
    [input] Enter repository name : 
sharengo

...
BUILD SUCCESSFUL

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.scm.project.from.tag

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.scm.project.from.tag:
    [input] Enter project name :
project3
    [input] Enter tag :
version1.0
    [input] Enter repository name : 
sharengo

...
BUILD SUCCESSFUL

Tout d'abord, vous devez vous placer dans le workspace précèdement créé.

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.component

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.component:
    [input] Enter component name :
component1

...

BUILD SUCCESSFUL

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.scm.component

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.scm.component:
    [input] Enter component name :
component2
    [input] Enter repository name : 
sharengo

...
BUILD SUCCESSFUL

$> cd /home/jeromeb/workspaces/ws-workspace1
$> abs new.scm.component.from.tag

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

new.scm.component.from.tag:
    [input] Enter component name :
component3
    [input] Enter tag :
version1.0
    [input] Enter repository name : 
sharengo

...
BUILD SUCCESSFUL

La commande "lib.local" permet de compiler un composant ou un projet. Cette opération construit 3 archives *.jar contenant les fichiers *.class correspondant à la version binaire des fichiers source *.java. Vous pouvez également la commande "lib:all" qui propage l'opération de compilation sur l'ensemble des composants utilisés par la ressource courante. Les 3 archives résultantes sont :

$> cd /home/jeromeb/workspaces/ws-workspace1
$> cd components/component1
$> abs lib:all

...
BUILD SUCCESSFUL

La commande "deploy:new" permet de créer un nouvel environnement cible. Elle ajoute un répertoire portant le nom du déploiement dans le répertoire deployment situés à la racine du projet. Elle crée également les fichiers replace.server.properties et replace.client.properties permettant de variabliser les fichiers de configuration utilisés lors de la construction des livrables relatif à cet environnement.

$> cd /home/jeromeb/workspaces/ws-workspace1/projects/project1
$> abs deploy:new

abs:version:
     [echo] 
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo]   ABS ~ Advanced Build System ~
     [echo] 
     [echo]          ~ Next Generation Build System ...
     [echo] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [echo] 

deploy:new:
    [input] Enter deployment target name :
localhost

...
BUILD SUCCESSFUL

La commande "deploy:build.war" construit une archive WAR permettant de déployer le projet sur un serveur d'application tel que Apache-Tomcat.

La commande "deploy:build.cli" construit une archive .tar.gz permettant de lancer l'application à l'aide d'une exécutable en ligne de commande.

Ces 2 commandes construisent une archive par déploiement spécifiés dans le projet en configurant leurs spécifités à l'aide des fichiers de replace.

A l'aide du menu : "New" -> "Project" -> dans le noeud ABS sélectionnez "New Component"

Figure 4.1. Capture de l'écran de création de composant

Le plug-in eclipse interagit avec l'ABS installé sur votre système, il est donc nécessaire d'indiquer l'emplacement de l'ABS_HOME ainsi que celui du workspace ABS. Si cette information n'est pas renseignée dans les préférences ABS d'eclipse (menu "Window" -> "Preferences ..." -> rubrique "ABS Preference") l'assistant suivant vous sera proposer et se chargera de les mettre à jour :

Figure 4.2. Capture d'écran de sélection de l'ABS HOME

Figure 4.3. Capture d'écran de sélection d'un workspace ABS

Figure 4.4. Capture d'écran de saisi des informations du composant

A l'aide du menu : "New" -> "Project" -> dans le noeud ABS sélectionnez "New Project"

Figure 4.5. Capture de l'écran de création de projet

Figure 4.6. Capture d'écran de saisi des informations du projet

Lorsque vous créez un projet, l'assistant ajoute automatiquement un module nommé "main" et un déploiement nommée "localhost". Vous trouverez dans la vue "PackageExplorer" ci-dessous le module "project1_main", ainsi le déploiement "project1_localhost_server".

Figure 4.7. Capture de la vue package explorer permettant de visualiser les ressources du projet

Vous pouvez créer un modèle de conception UML dans un composant ou un module de projet.

4.3.1. Modéliser en UML

Positionnez-vous dans la répertoire server/model/conception et créez un modèle nommé conception.uml à l'aide du menu "New" -> "Other..." -> "SharenGo Unified Modeling" -> "Step 3 - New Conception Model" et créez le fichier conception.uml :

Figure 4.8. Capture d'écran de la création de modèle de conception

Cette commande créée trois fichiers :

• conception.uml : ce fichier contient les informations structurelles du modèle,

• conception.umldi : ce fichier contient les diagrammes, il utilise le premier pour référencer les éléments utilisés au sein des diagrammes,

• conception.properties : ce fichier permet de paramétrer la stratégie de génération, les valeurs par défaut sont suffisantes pour une utilisation courante.

Note

Il est impératif de nommer le modèle org::sharengo::nom_composant à l'aide de la fenêtre propriétés. (les "::" étant le séparateur de package utilisé en langage UML) Ce nom de modèle permettra de déterminer le nom du paquetage contenant les fichiers générés.

4.3.2. L'architecture logique

Pour modèliser les divers composants nous avons définis une architecture logique qui correspond à un PIM (Plateform Independant Model) selon la dénomination MDA. Le schéma ci-dessous illustre les différentes couches de cette architecture basée sur le patron de conception MVC (Model View Controller) :

Figure 4.9. Schéma d'architecture logique

Ce modèle d'architecture peut être considérer comme un métamodèle puisqu'il sera instancié au sein de chaque composant et module. Pour des raisons historique, nous avons choisi d'instancier ce modèle à l'aide du langage UML et non à l'aide d'un DSM. (Domain Specific Modeler) Nous avons donc réalisé un profile UML pour étendre UML afin d'y intégrer les concepts de notre métamodèle. Pour ce faire nous avons définis une batterie de stéréotypes et propriétés que nous allons décrire dans la section suivante.

4.3.2.1. Les stéréotypes

Les stéréotypes permettent d'apposer une sémantique particulière aux éléments UML. Appliquer un stéréotype dans l'outil de modélisation TopCased :

Figure 4.10. Application d'un stéréotype

Un stéréotype peut définir des propriétés que vous pouvez valoriser dans l'onglet "Stereotype Attributes".

4.3.2.2. Le stéréotype <<Entity>>

Définition.  Ce stéréotype est utilisé pour spécifier les objets du domaine métier (persités par l'application).

Propriétés.  Aucune.

Contexte d'utilisation. 

Figure 4.11. Association entre 2 entités

4.3.2.3. Le stéréotype <<Dto>>

Définition.  Ce stéréotype est utilisé pour spécifier les objets de transfert. Le patron de conception DTO (Data Transfert Object) est utilisé afin de fournir une couche de médiation entre la couche métier et la couche IHM (Interface Homme Machine).

Propriétés.  Aucune.

Contexte d'utilisation.  Souvent utilisé en tant que paramètre d'une opération.

4.3.2.4. Le stéréotype <<EntitiesManager>>

Définition.  Ce stéréotype est utilisé pour spécifier les objets d'accès aux données. Il représente le patron de conception DAO (Data Access Object). Ce type de classe assure la sauvegarde et la restauration des données définit dans les entités métiers.

Propriétés.  Aucune.

Dépendances possibles.  TODO ajouter un screenshot

4.3.2.5. Le stéréotype <<Process>>

Définition.  Ce stéréotype est utilisé pour définir un service métier, un traitement métier.

Propriétés.  Aucune.

Contexte d'utilisation.  Un process peut utiliser d'autres process, ou des EntitiesMgr.

Figure 4.12. Cas d'utilisation d'un EntitiesMgr

4.3.2.6. Le stéréotype <<Controller>>

Définition.  Ce stéréotype est utilisé pour définir l'aiguillage des actions utilisateurs. Il décode les informations transmise et les transmet à l'Ui.

Propriétés.  Aucune.

Contexte d'utilisation. 

Figure 4.13. Cas d'utilisation d'une Ui

4.3.2.7. Le stéréotype <<Ui>>

Définition.  Ce stéréotype est utilisé pour représenter les classes chargées d'orchestrer les appels de services métiers et de transmettre les informations résultantes vers une vue donnée.

Propriétés.  Aucune.

Contexte d'utilisation.  Une Ui peu utiliser d'autres Ui, faire appels à des Process et utiliser des View.

Figure 4.14. Cas d'utilisation d'une Ui

4.3.2.8. Le stéréotype <<View>>

Définition.  Ce stéréotype est utilisé pour définir la notion d'écran utilisateur.

Propriétés.  Aucune.

Contexte d'utilisation.  Une Vue est simplemet utilisée par des Ui.

4.3.2.9. Le stéréotype <<Remote>>

Définition.  Ce stéréotype permet de représenter qu'une opération est joignable de manière distante. Dans le cas d'une Ui pour mettre en oeuvre une communication de type Ajax. Ou de type Web Service si elle est appliquée à une opération d'un Process.

Propriétés.  TODO

4.3.2.10. Le stéréotype <<Transactional>>

Définition.  Ce stéréotype permet de représenter l'aspect transactionnel d'une opération d'un Process.

Propriétés.  Aucune.

4.3.2.11. Le stéréotype <<Config>>

Définition.  Ce stéréotype permet de représenter les classes définissant les variables de configuration. Pour définir l'adresse d'un serveur smtp, il est nécessaire de définir un attribut smtpServer de type String dans une classe portant ce stéréotype.

Propriétés.  Aucune.

Contexte d'utilisation.  Les classes Config peuvent être utiliser par la plupart des classes de l'architecture.

Nous utilisons l'outil de transformation modèle vers texte Acceleo pour générer le code source à partir du modèle UML ci-dessus. Pour lancer une transformation il est nécessaire de définir une chaine de génération. Dans notre cas, nous allons définir une chaine en appelant une autre implémentant une architecture donnée.

Créer la chaîne conception.launch à l'aide du menu "New" -> "Others" -> "Acceleo" -> "Module Launcher" :

Figure 4.15. Capture de l'écran de l'assistant ModuleLauncher, étape 1

Choisir la chaine nommée : "Java Generator for Spring / Hibernate / Velocity Architecture" :

Figure 4.16. Capture de l'écran de l'assistant ModuleLauncher, étape 2

Cliquer sur "Next", nommer la chaîne conception.chain :

Figure 4.17. Capture de l'écran de l'assistant ModuleLauncher, étape 3

Cliquer sur "Next", sélectionner le modèle UML source (soit conception.uml).

Figure 4.18. Capture de l'écran de l'assistant ModuleLauncher, étape 4

Cliquer sur "Next", sélectionner le modèle UML source conception.uml :

Figure 4.19. Capture de l'écran de l'assistant ModuleLauncher, étape 5

Editer la chaîne en double-cliquant sur le fichier créer.(étape optionnel) Elle contient la référence au modèle ainsi que celle correspond à l'architecture choisie :

Figure 4.20. Capture de l'écran du contenu de la chaîne

Lancer la génération du code source à l'aide du menu "Launch" dans le menu contextuel du fichier conception.chain.

Figure 4.21. Capture de l'écran du lancement d'une chaîne de génération

4.4.1. L'architecture physique basée sur Spring

Spring est une librairie java permettant de construire des socles techniques implémentant différentes architectures. Il s'agit d'un "conteneur léger", une infrastructure similaire à celles offertes par les serveurs d'application JEE, fonctionnant de manière autonome. La grande force de Spring est son un système de fabrique de graphe d'objets basé sur le patron de conception "Inversion Of Control" appelé "IoC" et décrit à cette adresse http://www.martinfowler.com/articles/injection.html par le célèbre architecte : Martin Fowler. La documentation de référence du projet est accessible à cette adresse http://www.springframework.org/docs/reference/

4.4.1.1. Les pré-requis

Pour utiliser Spring au sein d'un composant ou module, il est impératif d'ajouter une dépendance source vers le composant middleware/gluon-core. Ce dernier constitue notre socle technique définissant l'ensemble des dépendances binaires nécessaires au bon fonctionnement de Spring.

Tout d'abord, vous devez récupérer ce composant depuis le référentiel à l'aide du menu New / Project ... / ABS / Create a new Component from SCM repository :

Figure 4.22. Capture de l'écran de récupération d'un composant existant, étape 1

Choisir le référentiel et saisir le nom du composant. Dans le cas présent nous utilison la version trunk du composant :

Figure 4.23. Capture de l'écran de récupération d'un composant existant, étape 2

Ensuite ajouter la dépendance vers gluon-core en editant le fichier srcdep.txt à la racine de votre composant ou module, et ajouter la ligne suivante :

Exemple 4.1. Un exemple de fichier srcdep.txt

sharengo:middleware/gluon-core/trunk

Note

Si vous souhaiter utiliser des WebServices, vous devez reproduire la même opération afin d'utiliser le composant middleware/gluon-xfire .

4.4.1.2. Les fichiers générés

Vous trouverez ci-dessous la liste des artefacts générés pour chacun des stéréotypes :

4.4.1.2.1. A partir du stéréotype <<Entity>>

Pour une classe Entity nommée "MyEntity1" stockée dans le paquetage entities d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/entities/MyEntity1.java : classe métier

• server/resources/org/sharengo/component1/entities/hibernate/MyEntity.hbm.xml : fichier de mapping hibernate

• server/test/src/org/sharengo/component1/entities/impl/MyEntityHelper.java : classe utilitaire permettant de créer des instances de cet objet métier. (utilisé dans les tests unitaires)

4.4.1.2.2. A partir du stéréotype <<Dto>>

Pour une classe Dto nommée "MyDto1" stockée dans le paquetage dto d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• /server/main/src/org/sharengo/component1/dto/MyDto1.java : la classe de transfert

4.4.1.2.3. A partir du stéréotype <<EntitiesManager>>

Pour une classe EntitiesManager nommée "MyEntity1Mgr" stockée dans le paquetage entities d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/entities/IMyEntity1Mgr.java : interface d'accès aux données

• server/main/src/org/sharengo/component1/entities/impl/MyEntity1MgrImpl.java : classe d'implémentation des accès aux données

• server/test/src/org/sharengo/component1/entities/impl/MyEntity1MgrTest.java : test unitaire prouvant le bon fonctionnement de l'implémentation

• server/resources/META-INF/spring/org.sharengo.component1/layer-daos-hibernate.xml : fichier de configuration Spring permettant de déclarer l'implémentation courante et ses dépendances requises.

4.4.1.2.4. A partir du stéréotype <<Process>>

Pour une classe Process nommée "MyProcess1" stockée dans le paquetage process d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/process/IMyProcess1.java : interface du service métier

• server/main/src/org/sharengo/component1/process/impl/MyProcess1Impl.java : classe d'implémentation du service métier

• server/test/src/org/sharengo/component1/process/impl/MyProcess1Test.java : test unitaire prouvant le bon fonctionnement de l'implémentation

• server/resources/META-INF/spring/org.sharengo.component1/layer-services.xml : fichier de configuration Spring permettant de déclarer l'implémentation courante et ses dépendances requises. Il définit également la stratégie transactionnelle associée à chaque opération si le stéréotype Transactional est utilisé.

Si certaines méthodes utilisent le stéréotype Remote, les fichiers suivant sont générés :

• server/main/src/org/sharengo/component1/process/IMyProcess1WebService.java : interface contenant uniquement la déclaration des opérations Remote

• server/resources/META-INF/spring/org.sharengo.component1/layer-xfire-services.xml : fichier de configuration Spring permettant de lier l'interface à l'implémentation du process et de définir le mapping des URL permettant d'accèder aux opérations

• server/test/src/org/sharengo/component1/process/impl/MyProcess1WebServiceTest : test unitaire prouvant le bon fonctionnement des méthodes lors d'un appel distant. Ce test utilise le test unitaire du process en fournissant une instance de process obtenu à l'aide d'un appel distant sur un serveur d'application Jetty embarqué.

• server/test/src/org/sharengo/component1/process/impl/MockMyProcess1WebService.java : objet bouchon utilisé par les tests unitaires

• client/main/src/org/sharengo/component1/ws/WSClientFactory.java : fabrique d'objets permettant de récupérer des instance d'IMyProcess1WebService à partir d'une adresse du type http://localhost/project1/services/IMyProcess1WebService

4.4.1.2.5. A partir du stéréotype <<Controller>>

Pour une classe Controller nommée "MyController1" stockée dans le paquetage ui d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/ui/MyController1.java : classe d'aiguillage vers l'Ui

• server/resources/META-INF/spring/org.sharengo.component1/layer-controllers.xml : fichier de configuration Spring permettant de déclarer l'implémentation courante et ses dépendances requises.

4.4.1.2.6. A partir du stéréotype <<Ui>>

Pour une classe Ui nommée "MyUi1" stockée dans le paquetage ui d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/ui/IMyUi1.java : interface de l'Ui

• server/main/src/org/sharengo/component1/ui/impl/MyUi1Impl.java : classe d'implémentation de l'Ui

• server/resources/META-INF/spring/org.sharengo.component1/layer-uis.xml : fichier de configuration Spring permettant de déclarer l'implémentation courante et ses dépendances requises.

4.4.1.2.7. A partir du stéréotype <<View>>

Pour une classe View nommée "MyView1" stockée dans le paquetage ui d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/ui/impl/MyView1.java : classe vue

• server/main/src/org/sharengo/component1/ui/ViewFactory.java : fabrique d'objet vue, la vue étant un objet à état elle ne peut pas être injecté comme les autres composantes de l'architecture

4.4.1.2.8. A partir du stéréotype <<Config>>

Pour une classe Config nommée "MyConfig1" stockée dans le paquetage config d'un modèle nommé org::sharengo::component1, les fichiers suivants sont générés :

• server/main/src/org/sharengo/component1/Confi/MyConfig1.java : classe de configuration

• server/resources/META-INF/spring/org.sharengo.component1/layer-configs.xml : fichier de configuration Spring permettant de déclarer la classe.

4.4.1.2.9. A partir du modèle

• server/resources/META-INF/spring/component.xml : fichier de configuration Spring permettant de définir quels fichiers layer-* sont requis pour ce composant.

• server/resources/META-INF/spring/component-test.xml : rôle identique à composent.xml mais utilisé dans le contexte des tests unitaires et donc paramétrable.

• server/resources/META-INF/spring/org.sharengo.component1/applicationContext-tests.xml : fichier de configuration Spring permettant de définit les ressource hibernate et autres pour les tests unitaires.

• server/test/src/org/sharengo/component1/AbstractBusinessLayerTests.java : classe abstraite utilisée par tous les test unitaires. Elle permet d'initialiser le graphe de composants.