SlideShare une entreprise Scribd logo
4 D

S U M M I T

E U R O P E

2 0 1 2

Industrialisation du
développement 4D avec les
composants
Presented by : Bruno LEGAY - A&C Consulting

1
INDUSTRIALISATION ?

De quoi parle-t-on lorsqu'on parle d'"industrialisation" ?
L'industrialisation est caractérisée par l'optimisation des processus de fabrications de produits manufacturés. On
est ainsi passé d'une production "artisanale" à une production "industrielle".
Cette évolution remonte au XIXeme siècle (1801) avec la révolution industrielle qui apparaît en Grande Bretagne.
Elle est caractérisée par l'utilisation de machine, la production en série, la standardisation pour abaisser les
coûts de production et améliorer la qualité.
Quelques dates clés et les tendances dans deux domaines spécifiques

•

Automobile :
o 1886 première voiture ;
o 1908 Ford T – Taylorisme : production à la chaîne ;
o 1961 premier robot industriel ;
o 1990 "commonolisation" (partie cachée commune – partie visible personnalisée).

•

Informatique – matériel
o 1943 Colossus
o 1976 Apple I
o 1984 Macintosh - IBM PC/AT
o standardisation des composants (processeurs, mémoire, disques).

On remarque plusieurs tendances : automatisation des taches, standardisation de composants.
Toutefois, ces domaines comportent des différences significatives par rapport au logiciel. La conception d'un
logiciel s'apparente peu à une succession de tâches prédéfinies et répétitives qui peuvent être découpées,
optimisées et enchaînées.
Enfin, ces deux domaines ont pour objectifs de produire des biens matériels alors que l'industrie logicielle relève
plus d'un travail de conception consistant à produire un bien numérique et immatériel. La question de production
en masse ne se pose pas de la même manière.
Qu'en est-il de l'industrialisation appliquée au génie logiciel (utopie ou réalité) ?
Deux axes :

•
•

automatisation de tâches répétitives
standardisation des composants.

2
AUTOMATISATION

Automatisation de tâches répétitives
Pourquoi ?

•
•
•
•

cohérence / consistance
qualité (éviter les erreurs humaines)
éviter les dérives
se concentrer sur les tâches à valeur ajoutées.

Génération de librairies, de code compilé, d'exécutables (construction d'applications avec GENERER
APPLICATION, génération d'installeurs, compression, archivage sources, publication, signature md5,
etc…). Possibilité d'utiliser plusieurs "profils" d'application (fichier xml "BuildApp"), générateur
d'installeur "nsis" sur windows.
Les tests unitaires sont destinés à vérifier le bon fonctionnement d'une partie spécifique d'un logiciel
(et ceci en toutes circonstances). Les tests unitaires doivent aussi permettre de vérifier qu'une
modification du logiciel (modification du code) n'introduit pas de régressions (apparition de nouveaux
dysfonctionnements). Les tests unitaires permettent aussi de vérifier rapidement l'impact des
changements liés aux plateformes ou aux environnements. En cas ce bug, le contexte est ajouté dans le
"test" pour valider la correction et vérifier que ce bug ne réapparaitra plus. Cf méthodes XP (Extreme
Programming) ou TDD (Test Driven Development).
Génération de documentation. Les documentations techniques sont difficiles à maintenir. La
documentation la plus à jour et la plus précise doit se situer au niveau du code. On peut s'inspirer de
Javadoc qui est utilisé dans le monde Java. Il s'agit de structurer des informations sur la méthode dans
les commentaires à l'aide de balises (ou "tags"). Les macros permettent alors de préparer cette zone
avec un "modèle". Le développeur n'a qu'à compléter cette zone.

3
STANDARDISATION DES COMPOSANTS

Préhistoire des composants
4D Insider est l'ancêtre des composants actuels (apparus en v11).
4D Insider était l'outil de prédilection pour déplacer des objets (méthodes, formulaires, etc…) entre
diverses structures.
Avec 4D Insider, on pouvait créer des librairies ou composants (avec une notion de composants
protégés).
4D Insider avait un certain nombre de limites (l'utilisation des composants n'était pas très souple entre
autres).
4D Insider est mort ! Vive les composants !

4
PRINCIPE DES COMPOSANTS

Rappel du fonctionnement des composants
Un composant est une base de données (placée dans le répertoire "Components"). NOTE : à partir de
4D v12, on peut placer des composants dans l'application 4D (comme pour les plugins).
On a une notion de base "hôte" et une (ou plusieurs) base(s) "composant(s)". Pour les sources du
composant on parle parfois de la base "matrice".
Une base interprétée peut utiliser un composant interprété ou compilé. Une base compilée utilise
nécessairement un composant compilé. Attention à la compatibilité des options de compilation
(compilation 64 bits par exemple).
Les modes "Unicode" de la base "hôte" et la base "composant" doivent être compatibles (c'est-à-dire
identique).
Les méthodes du composant visibles par la base "hôte" doivent être "partagées". L'inverse est vrai
aussi, pour qu'un composant appelle/exécute une méthode de la base "hôte", celle-ci doit aussi être
partagée.
Les dépendances des composants doivent être maîtrisées (et documentées).

Certains objets sont utilisables dans un composant, d'autres ne sont pas utilisables.
Objet

Utilisable en mode composant

Méthode

oui

Formulaire projet

oui

Formulaire table

non

Table et champ

non

Trigger

non

Méthode base ("sur ouverture" par exemple)

non

Utilisateur et Groupe

non

Préférences/propriétés de la base

non

De ce fait, certaines commandes n'ont pas de sens (et ne peuvent donc pas être utilisées) comme par
exemple "ECRIRE IMAGE DANS BIBLIOTHEQUE".

5
Certains objets sont partagés, d'autres sont cloisonnés.
Objet

Partagé / cloisonné

Variable (process et interprocess)

cloisonné

Variable système (ok, Document, etc…)

cloisonné

Feuille de style

cloisonné

Infobulle

cloisonné

Enumération

cloisonné

Image bibliothèque

cloisonné

Menu (éditeur menu)

cloisonné

Sémaphore

cloisonné

Ensemble

partagé

Sélection temporaire

partagé

Liste hiérarchique

partagé

Menu (cf Créer menu)

partagé

Référence xml

partagé

Référence fichier

partagé

Pointeur

partagé

6
AVANTAGES DES COMPOSANTS

Quels sont les avantages d'un composant ?
Les composants permettent de partager et réutiliser le code de manière efficace.
Un composant permet de cloisonner les environnements d'exécution et d'éviter des "collisions". C'est
une alternative possible à l'utilisation systématique de préfixes sur les variables.
Un composant compilé peut permettre des gains de performances significatifs dans une base interprétée
(en développement par exemple).

7
CONTRAINTES

Quelles sont les contraintes rencontrées lors de la création de composants ?
L'implémentation de composant nécessite de bien comprendre les mécanismes de dépendances. Par
exemple, si un composant utilise explicitement un plug-in, la base "hôte" devra avoir accès à ce plugin.
On rencontre la même contrainte avec les composants (un composant utilisé explicitement dans la base
"matrice" devra être installé dans la base "hôte").
La documentation est impérative. En effet, il n'est pas possible de consulter le code d'un composant
compilé. Au minimum une description de la méthode avec le détail des paramètres doit figurer dans la
zone "commentaires" de l'explorateur (en v12). Les commentaires situés au début de la méthode d'un
composant ne sont pas visibles depuis la base "hôte" si le composant est compilé (mais ils sont visibles
si le composant est interprété).

8
PIEGES

Quelques pièges liés aux composant (et comment les éviter / contourner) ?
La commande "RESOUDRE POINTEUR" pouvait parfois être utilisée pour comparer si deux
pointeurs pointaient bien sur la même variable. Si l'origine des pointeurs est différente, ils peuvent
porter le même nom et pourtant ils pointent sur des variables différentes. La comparaison de pointeurs
(en passant par RESOUDRE POINTEUR est donc fausse).
Il faut simplement comparer directement les pointeurs :
Si($vp_ptr1=$vp_ptr2)

La commande "Pointeur vers" utilisée dans un composant retournera un pointeur vers une variable du
composant.
Une astuce consiste à utiliser une méthode de "rétro-appel" (ou "callback"). Dans la base "hôte", on
crée une fonction qui fera appel à "Pointeur vers" (on oublie pas de partager cette méthode) et on passe
au composant le nom de cette fonction. Le composant pourra alors appeler cette fonction (via la
commande "EXECUTER METHODE").
La création de cette méthode de "callback" peut même être automatisée.

9
DEPENDANCES SOUPLES

Comment gérer des dépendances souples ?
On peut avoir besoin d'avoir de composants qui font appel de manière optionnelle à un autre
composant. Soit parce que ce composant n'est nécessaire que dans un contexte (contexte de
développement dans la base "matrice") ou parce que ce composant fournit une fonctionnalité
optionnelle lors de l'utilisation. Dans ce cas, si l'appel à ce composant est effectué de manière explicite,
on aura un message d'erreur à l'ouverture de la base "hôte". Le composant doit détecter de manière
transparente la présence de l'autre composant et agir de manière appropriée. C'est ce qu'on appelle une
dépendance souple.
Pour détecter la présence d'un composant, il y a la commande LISTE COMPOSANTS.
On peut ensuite faire appel aux méthodes du composant via la commande EXECUTER METHODE
pour éviter les problèmes de dépendances fortes.
// LOG_debug ($vt_message)
TABLEAU TEXTE($tt_componentsList;0)
LISTE COMPOSANTS($tt_componentsList)
Si(Chercher dans tableau($tt_componentsList;"LOG_component")>0)
EXECUTER METHODE("LOG_debug";*;$vt_message)
Fin de si
TABLEAU TEXTE($tt_componentsList;0)

10
ASTUCES

Quelques astuces
Il est parfois nécessaire de déterminer si le code s'exécute dans le composant ou dans la base "hôte".
Pour cela on peut comparer le résultat de la commande "Fichier structure" avec et sans l'option "*".
Par défaut (sans "*") Fichier structure retourne le nom long/chemin du fichier structure (fichier .4db ou
.4dc) du composant.
Si "*" est passé, Fichier structure retournera le nom long/chemin du fichier structure de la base hôte (si
on est dans un composant)
Si(Fichier structure # Fichier structure(*)) // on est dans un composant
…
Sinon // on est pas dans un composant
…
Fin de si

On peut en faire une fonction, mais attention, par définition cette méthode ne pourra pas s'utiliser
comme une méthode partagée d'un composant. Il faut la copier…
On a parfois besoin de déterminer quelle est la langue du langage 4D utilisée (les commandes sontelles en français ou en anglais) ?
C_ALPHA(2;$va_language)
C_TEXTE($vt_commandNameOfCommandName)
$vt_commandNameOfCommandName:=Nom commande(538) //538  "Command name"
Au cas ou
: ($vt_commandNameOfCommandName="Nom commande")
$va_language:="fr"
: ($vt_commandNameOfCommandName="Command name")
$va_language:="en"
Sinon
$va_language:="en"
Fin de cas

11
LES COMPOSANTS FOURNIS PAR 4D

4D fourni quelques composants standard
4D fourni déjà quelques composants 4D SVG : images vectorielles SVG pour le runtime
4D Widgets propose un datePicker et timePicker pour le runtime
4D Pop propose des fonctionnalités au développeur. Composant orienté vers l'environnement de
développement.
Sans oublier tous les composants fournis par Keisuke Miyako
Au delà des composants fournis par 4D, quel est l'intérêt pour un développeur à créer ses propres
composants ?

12
POURQUOI CREER UN COMPOSANT

Dans quel cas doit-on envisager de créer un composant ?
Dans un logiciel, on peut déterminer un ratio "glue" / "substance" (cf Alexander Stepanov). La
partie "glue" correspond au code qui ne répond pas directement au besoin du projet et la "substance"
correspond à la partie spécifique (au métier). On peut mesurer ceci sur la base du nombre de lignes. Par
exemple, dans un de nos projets, nous avons effectué récemment des métriques et nous avons constaté
que sur 310 000 lignes de code (méthodes projet) 43,5 % du code était du code générique et que le
reste 56,5 % était du code spécifique.
Objectif d'efficacité : se concentrer sur le métier/fonctionnel et simplifier la ré-utilisation du code
technique générique testé et éprouvé (mise en place, maintenance).
Objectif de qualité : en simplifiant la mise en place (et la mise à jour) de code générique, on facilite la
réutilisation. L'amélioration continue du code générique (ajout de fonctionnalités, optimisation,
correction de bugs) est plus facilement mutualisée entre les projets et contribue à une amélioration de la
qualité globale des applications.
Ces objectifs sont surtout intéressant pour les développeurs qui travaillent sur plusieurs projets.

13
QUE PEUT-ON FAIRE AVEC UN COMPOSANT

Un composant, oui, mais pour faire quoi ?
On peut créer des composants pour packager des méthodes bien évidemment (génération de codes
barres), on peut afficher des formulaires (formulaires base) pour l'affichage des thermomètres, une
zone Web area (pour une fenêtre GoogleMaps par exemple) par exemple.
On peut aussi utiliser les composants pour packager des binaires ou outils externes. On peut par
exemple placer les exécutables (OS X et Windows) dans le répertoire "Resources" et les appeler via la
commande LANCER PROCESS EXTERNE. Idem pour des fonctions PHP (scripts php). Par exemple,
7z pour la compression zip, xmllint pour la validation schéma xml avec XInclude, rsync+cygwin,
ImageMagick, wkhtmltopdf, etc…
On peut facilement placer des méta-données dans un composant. Par exemple, on peut placer des
meta-données au format xml dans le répertoire "Resources" qui seront accessibles via une méthode
partagée du composant (par exemple les codes escape url http et/ou html).
Les composants peuvent aussi être utilisés pour wrapper les plugins (4D for OCI par exemple). On peut
créer des composants qui permettent de basculer entre différents plugins similaires (commandes TCP
des Internet Commands, NTK et ITK) ou entre un plug-in et du code 4D pur (ObjectTools, XML
Plugin, etc…).

14
CHOIX

Quelles questions doit-on se poser avant de se lancer ?
Quel type de composant va-t-on créer ? Un seul composant avec toutes les méthodes à l'intérieur
(approche monolithique) ou un plusieurs composants (approche modulaire) ?
Dans le cas d'une approche modulaire, comment seront gérées les dépendances entre les composants ?
Composant interprété ou compilé (si oui pour quelle plateformes) ?
Composant Unicode ?
Comment mettre en place, définir et stabiliser ses API (maturation des points d'entrée,
flexibilité/souplesse de fonctionnement avec l'utilisation de paramètres optionnels et callback, stabilité,
pérennité et rétro-compatibilité) ?

15
NOTRE CONTEXTE

Le contexte dans lequel nous avons été amenés à mettre en place des composants est le suivant
A&C Consulting est une SSII avec 3 développeurs 4D expérimentés.
Nous travaillons sur de nombreux projets spécifiques.
Nous avons construit au fil des années une bibliothèque de code générique, mais les méthodes de
mutualisation de ce code étaient encore artisanales.
A&C Consulting a une expérience de commercialisation d'un composant. Ce composant est lié au plugin 4D for OCI : ociLib. C'est un composant qui a été mis au point pour les besoins d'un de nos clients
et ensuite proposé à des développeurs tiers qui étaient intéressés.
Nous travaillons depuis plusieurs années avec une approche générique modulaire

16
NOTRE APPROCHE

Voici l'approche qui a été retenue :
Dans un premier temps (première phase), nous nous focalisons sur les "couches basses".
Pour ces couches basses, nous avons retenu une approche modulaire (file system, blob, env, http,
html, io, log, objectTools, tableaux, text, zip, etc…)
Nous avons une volonté de limiter les dépendances (quitte à dupliquer du code entre des composants)
pour des raisons de souplesse mais aussi pour éviter les problèmes de compatibilité liées aux versions.
C'est un travail de longue haleine (135 000 lignes de code) qui se fait petit à petit (un ensemble
logique de code générique correspondant à un module est converti en composant et ce code est retiré
des projets pour être remplacé par le nouveau composant). La documentation est impérative et prend du
temps. La re-factorisation prend du temps (module fourre-tout "UTL" qui nécessite d'être réorganiser
de manière plus logique).
Plus tard, nous prévoyons de mettre en place un composant de niveau intermédiaire qui s'appuiera sur
les composants "couches basses" avec des dépendances fortes.

17
CONVENTION DE NOMMAGE

Les conventions de nommage des méthodes sont importantes
Nous utilisons un système de préfixe dans les noms des méthodes pour facilement identifier l'origine
d'une méthode (quel composant). Pour chaque composant nous fixons un code mnémotechnique de
deux à quatre lettres :
HTTP_GET => composant "http_component"
FS_macPathToUnixPath => composant "fs_component"
Dans le composant (base "matrice"), les méthodes qui ne sont pas partagées (et invisibles) contiennent
deux "_" après le préfixe. Ceci permet de s'appuyer sur la convention de nommage pour fixer
rapidement les attributs des méthodes (via l'écran "Modifier attributs globalement") et de les trier
dans l'explorateur.
NOTE : la notion de "partagé entre composant et base hôte" n'est pas visible dans l'explorateur des
méthodes tandis que la notion "visible/invisible" est repérable tout de suite, il est donc judicieux de les
fixer de manière similaire/cohérente.

18
DOCUMENTATION

Comment gérer la documentation des composants
La documentation est fondamentale pour la mise en place de composant (rappel le code source et les
commentaires d'un composant compilé ne sont pas accessibles).
L'approche Javadoc qui est une solution proposée dans un autre langage pour répondre une
problématique similaire (documentation d'API) est une bonne source d'inspiration
Principe basé sur des "balises" (ou tags) placées dans les commentaires en entête
L'entête défaut (avec les tags) est généré par une macro.
Ensuite, un peu d'API Pack pour automatiser tout ça…
Un composant maison "xdoc" (s'appuyant sur API Pack) est utilisé pour lire le contenu de chaque
méthode, identifier les balises/tags de documentation, effectuer une conversion en xml. Cet xml peut
ensuite être utilisé pour générer différents formats de documentation (rtf, html, pdf, etc…). Pour
l'instant, nous utilisons 4D Write pour générer un texte stylé rtf (par méthode) qui est ensuite placé
dans la zone "Commentaires" de la méthode. Attention : c'est un hack (reverse engineering) : il n'y a
malheureusement pas, à ma connaissance, de moyen officiel pour alimenter cette zone.

19
TESTS

Pourquoi tester et valider son composant et comment y arriver ?
Tester son composant avant de le déployer est important si on veut éviter des "aller-retour" superflus.
Les tests permettent de valider le fonctionnement nominal, de vérifier la non-régression, de valider une
optimisation, de valider le comportement lors d'un changement de version de 4D, de tester sur une
plateforme spécifique, etc…).
L'utilisation de tests unitaires permet de valider le fonctionnement du composant en automatisant les
tests.
Les tests unitaires permettent de réduire les tests manuels qu'un développeur consciencieux devrait
faire (parcourir quelques fonctionnalités de l'application pour vérifier le bon fonctionnement).
Pourquoi ? Parce que ces tests sont répétitifs, qu'ils sont chronophages, et qu'ils sont donc rarement
effectués en pratique.
Les tests unitaires permettent d'éviter (ou toutefois de limiter) le nombre d'anomalies/de bugs
contenues dans une application livrée au client.
La mise en place de ces tests unitaires est aussi chronophage… Donc il faut faire preuve de bon sens et
pragmatisme sur les tests unitaires…
Par exemple, il n'est pas prioritaire d'ajouter des tests unitaires sur une méthode simple et qui marche
bien. Par contre, lors de la correction d'un bug lié à un contexte particulier, il est souvent souhaitable
d'ajouter ce contexte dans les tests unitaires en ajoutant un "test case".
Pour les méthodes complexes, l'ajout de tests unitaires permet de garantir leur bon fonctionnement
(vecteur de test md5 par exemple).

20
GESTION DES VERSIONS

Comment gérer les versions de ses composants ?
Une approche simple pour gérer les versions de son composant est de créer une fonction :
xxx_componentVersionGet
Cette fonction retourne la version du composant et on peut commenter l'historique du composant dans
le code source de cette méthode (dans les commentaires).
Si le composant génère des fichiers de logs lors de l'exécution, cette méthode peut être appelée à
l'initialisation du composant et le résultat est envoyé dans le fichier de log.

21
INITIALISATION

Les composants on parfois besoin d'être initialisés. Comment gérer cette initialisation ?
Les composants contiennent des variables (et des tableaux notamment) qui nécessitent des déclarations
et parfois des initialisations. Ces variables peuvent être des variables “process/globales” ou
“interprocess”. Ces opérations sont effectuées dans des méthodes qui correspondent : initialisation
process ou inteprocess. Attention l'appel à une méthode d'initialisation effectué de manière
erronée/inopinée ne doit pas vider les tableaux déclarés (qui peuvent être alimentés). Il faut donc gérer,
avec un flag booléen (un flag process et un flag interprocess), le fait que l'initialisation du composant a
été effectué (ou pas).
Ces initialisations peuvent être publiques et explicites (c'est au développeur qui utilise le composant de
faire appel à la méthode d'initialisation de manière appropriée) ou cette initialisation peut être privée,
elle doit alors être implicite et transparente.

22
MODELE DE COMPOSANT

Lorsqu'on crée régulièrement des composants, on s'aperçoit qu'on utilise souvent des préférences et quelques
méthodes identiques.
Nous avons standardisé l'organisation d'un composant avec trois répertoires :
- build
- src
- test
Des préférences standard sont définies dans la base "modèle de composant".
Les quelques méthodes standard sont pré-installées dans le modèle (xxx_componentVersionGet,
etc…)
Enfin, une petite "checklist" permet de s'assurer qu'on a bien effectué toutes les tâches de
personnalisation du modèle.

23
GESTION DES VERSIONS DE 4D

Comment gérer les composants selon les différentes versions de 4D ?
La transposition directe du code n'est pas toujours évidente (par exemple les caractères de
commentaires ` en v11 et // à partir de v12).
Les composants ont principalement été créés et mis au point en v11. On a donc converti ces
composants en v12 en maintenant les deux versions en parallèle. Les corrections ont été reportées
manuellement au cas par cas.
Certaines commandes ou préférences sont spécifiques à une version. Par exemple la notion
"compilation 64 bits" n'existait pas en v11. Il y a des commandes qui changent de nom (attention à
l'export de code en texte) ou qui apparaissent et peuvent nécessiter une amélioration du code pour en
tenir compte (en v13 : GENERER DIGEST, HTTP Client, etc…).
Le code peut toutefois anticiper et s'adapter. On peut, par exemple, dans une méthode v12 tenir
compte d'un nouveau comportement spécifique à la v13 et s'adapter. Lorsque le composant sera
converti en v13, la méthode s'exécutera de manière optimale sans avoir été modifiée.
Hormis les nouveautés apparues en v13, les composants v12 sont compatibles v13. Les composants
v11 sont compatibles v11 uniquement.

24
CONCLUSION

Quel bilan peut-on tirer de notre expérience avec les composants ?
En quelques mots : "les composants : ça marche !"
Les composants sont une solution adaptée, intéressante et élégante pour la gestion du code générique
lorsqu'on doit gérer plusieurs projets.
Une attention particulière doit être apportée sur la documentation pour faciliter l'utilisation du
composant.

25
BIBLIOGRAPHIE

http://www.cad-magazine.com/content/standardiser-pour-mieux-personnaliser
http://nsis.sourceforge.net/Main_Page
http://fr.wikipedia.org/wiki/Test_unitaire
http://fr.wikipedia.org/wiki/Extreme_programming
http://fr.wikipedia.org/wiki/Test_Driven_Development
http://fr.wikipedia.org/wiki/Javadoc
http://en.wikipedia.org/wiki/Name_collision
http://www.stepanovpapers.com/
http://www.stepanovpapers.com/Industrializing%20Software%20Development.pdf
http://sources.4d.com/trac/4d_keisuke/wiki/Components

26

Contenu connexe

Tendances

AFUP & PHP @ Supelec
AFUP & PHP @ SupelecAFUP & PHP @ Supelec
AFUP & PHP @ Supelecjulien pauli
 
Procédure de configuration et préparation de l’environnement sous windows
Procédure de configuration et préparation de l’environnement sous windowsProcédure de configuration et préparation de l’environnement sous windows
Procédure de configuration et préparation de l’environnement sous windows
Addi Ait-Mlouk
 
Build automatique et distribution OTA avec Xcode 4.x et Jenkins
Build automatique et distribution OTA avec Xcode 4.x et JenkinsBuild automatique et distribution OTA avec Xcode 4.x et Jenkins
Build automatique et distribution OTA avec Xcode 4.x et Jenkins
CocoaHeads France
 
UKO-JAVA1001-slides
UKO-JAVA1001-slidesUKO-JAVA1001-slides
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
Ippon
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven
Arnaud Héritier
 
Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)
Eric SIBER
 
Présentation OSGI
Présentation OSGIPrésentation OSGI
Présentation OSGI
Cynapsys It Hotspot
 

Tendances (8)

AFUP & PHP @ Supelec
AFUP & PHP @ SupelecAFUP & PHP @ Supelec
AFUP & PHP @ Supelec
 
Procédure de configuration et préparation de l’environnement sous windows
Procédure de configuration et préparation de l’environnement sous windowsProcédure de configuration et préparation de l’environnement sous windows
Procédure de configuration et préparation de l’environnement sous windows
 
Build automatique et distribution OTA avec Xcode 4.x et Jenkins
Build automatique et distribution OTA avec Xcode 4.x et JenkinsBuild automatique et distribution OTA avec Xcode 4.x et Jenkins
Build automatique et distribution OTA avec Xcode 4.x et Jenkins
 
UKO-JAVA1001-slides
UKO-JAVA1001-slidesUKO-JAVA1001-slides
UKO-JAVA1001-slides
 
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven
 
Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)
 
Présentation OSGI
Présentation OSGIPrésentation OSGI
Présentation OSGI
 

En vedette

Installation d’un système de vidéosurveillance
Installation d’un système de vidéosurveillanceInstallation d’un système de vidéosurveillance
Installation d’un système de vidéosurveillanceLassaad BENSAAD
 
Communique paris je t'aime
Communique paris je t'aimeCommunique paris je t'aime
Communique paris je t'aimeadecraene
 
ASTORGA
ASTORGAASTORGA
Presentacion sara y reyes
Presentacion sara y reyesPresentacion sara y reyes
Presentacion sara y reyes
IES V CENTENARIO
 
Powerpoint inauguration pour site internet
Powerpoint inauguration pour site internetPowerpoint inauguration pour site internet
Powerpoint inauguration pour site internetSébastien Leroy
 
Convocatorias IMJUVE
Convocatorias IMJUVEConvocatorias IMJUVE
Qu'est-ce qu'un projet de naissance ?
Qu'est-ce qu'un projet de naissance ?Qu'est-ce qu'un projet de naissance ?
Qu'est-ce qu'un projet de naissance ?
sophiegamelin
 
Acheter un appartement en thailande
Acheter un appartement en thailandeAcheter un appartement en thailande
Acheter un appartement en thailandeAlexandre Deguine
 
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montreal
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, MontrealTravail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montreal
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montrealjorgerodrigo.com
 
E book : nouveaux usages IT et nouveaux défis
E book  : nouveaux usages IT et nouveaux défisE book  : nouveaux usages IT et nouveaux défis
E book : nouveaux usages IT et nouveaux défisFrederic Simottel
 
Equipo4 semana2
Equipo4 semana2Equipo4 semana2
Equipo4 semana2
suhany17
 
Barriga
BarrigaBarriga
Un planeta con poca agua
Un planeta con poca aguaUn planeta con poca agua
Un planeta con poca agua
Wendy Perez Badilla
 
Livret propositions
Livret propositionsLivret propositions
Livret propositionsWKTL-Agency
 
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdfM7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
lothomas
 
Boletin Agosto 2009
Boletin Agosto 2009Boletin Agosto 2009
Boletin Agosto 2009
INAH
 
Méthodologie scrum avec Jerry Do it Together
Méthodologie scrum avec Jerry Do it TogetherMéthodologie scrum avec Jerry Do it Together
Méthodologie scrum avec Jerry Do it Together
Florent YOUZAN
 
Presentacion1 alberto villar
Presentacion1 alberto villarPresentacion1 alberto villar
Presentacion1 alberto villar
Alberto Guillermo Villar Paredes
 
Lejournaldesindignes3
Lejournaldesindignes3Lejournaldesindignes3
Lejournaldesindignes3WKTL-Agency
 

En vedette (20)

Installation d’un système de vidéosurveillance
Installation d’un système de vidéosurveillanceInstallation d’un système de vidéosurveillance
Installation d’un système de vidéosurveillance
 
Communique paris je t'aime
Communique paris je t'aimeCommunique paris je t'aime
Communique paris je t'aime
 
Cgv AYUDO 010212
Cgv AYUDO 010212Cgv AYUDO 010212
Cgv AYUDO 010212
 
ASTORGA
ASTORGAASTORGA
ASTORGA
 
Presentacion sara y reyes
Presentacion sara y reyesPresentacion sara y reyes
Presentacion sara y reyes
 
Powerpoint inauguration pour site internet
Powerpoint inauguration pour site internetPowerpoint inauguration pour site internet
Powerpoint inauguration pour site internet
 
Convocatorias IMJUVE
Convocatorias IMJUVEConvocatorias IMJUVE
Convocatorias IMJUVE
 
Qu'est-ce qu'un projet de naissance ?
Qu'est-ce qu'un projet de naissance ?Qu'est-ce qu'un projet de naissance ?
Qu'est-ce qu'un projet de naissance ?
 
Acheter un appartement en thailande
Acheter un appartement en thailandeAcheter un appartement en thailande
Acheter un appartement en thailande
 
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montreal
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, MontrealTravail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montreal
Travail Analytiques Web (Objctif SMART) - Jorge Martins MBA Marketing, Montreal
 
E book : nouveaux usages IT et nouveaux défis
E book  : nouveaux usages IT et nouveaux défisE book  : nouveaux usages IT et nouveaux défis
E book : nouveaux usages IT et nouveaux défis
 
Equipo4 semana2
Equipo4 semana2Equipo4 semana2
Equipo4 semana2
 
Barriga
BarrigaBarriga
Barriga
 
Un planeta con poca agua
Un planeta con poca aguaUn planeta con poca agua
Un planeta con poca agua
 
Livret propositions
Livret propositionsLivret propositions
Livret propositions
 
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdfM7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
M7 lesson 2 1 represent & translate algebraic exprions & equations p art 1 pdf
 
Boletin Agosto 2009
Boletin Agosto 2009Boletin Agosto 2009
Boletin Agosto 2009
 
Méthodologie scrum avec Jerry Do it Together
Méthodologie scrum avec Jerry Do it TogetherMéthodologie scrum avec Jerry Do it Together
Méthodologie scrum avec Jerry Do it Together
 
Presentacion1 alberto villar
Presentacion1 alberto villarPresentacion1 alberto villar
Presentacion1 alberto villar
 
Lejournaldesindignes3
Lejournaldesindignes3Lejournaldesindignes3
Lejournaldesindignes3
 

Similaire à 121102 aetc_consultingconf4d

Outils de construction pour la recherche
Outils de construction pour la rechercheOutils de construction pour la recherche
Outils de construction pour la recherche
Johan Moreau
 
Aspect avec AspectJ
Aspect avec AspectJAspect avec AspectJ
Aspect avec AspectJ
simeon
 
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
 DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
cluelessjoe
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logiciellecyrilgandon
 
Solution d'OTA
Solution d'OTASolution d'OTA
Solution d'OTA
Sidereo
 
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Société ELOSI
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven
Arnaud Héritier
 
Paris Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascriptParis Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascript
Michael Akbaraly
 
sfPot aop
sfPot aopsfPot aop
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
Zineb ELGARRAI
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
Ulrich VACHON
 
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
Atsé François-Xavier KOBON
 
Atelier hadoop-single-sign-on
Atelier hadoop-single-sign-onAtelier hadoop-single-sign-on
Atelier hadoop-single-sign-on
sahar dridi
 
20091020 - Normandy Jug - Builders Battle
20091020 - Normandy Jug - Builders Battle20091020 - Normandy Jug - Builders Battle
20091020 - Normandy Jug - Builders Battle
Arnaud Héritier
 
Comment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open SourceComment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open Source
Christian Charreyre
 
The Spring of Adobe Flex Remoting
The Spring of Adobe Flex RemotingThe Spring of Adobe Flex Remoting
The Spring of Adobe Flex Remoting
François Le Droff
 
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Alexandre Touret
 
Presentation hibernate nfe103
Presentation hibernate nfe103Presentation hibernate nfe103
Presentation hibernate nfe103MRamo2s
 
Présentation GWT et HTML 5 pour l'Offline
Présentation GWT et HTML 5 pour l'OfflinePrésentation GWT et HTML 5 pour l'Offline
Présentation GWT et HTML 5 pour l'Offline
DNG Consulting
 
Spring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'tsSpring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'ts
Julien Wittouck
 

Similaire à 121102 aetc_consultingconf4d (20)

Outils de construction pour la recherche
Outils de construction pour la rechercheOutils de construction pour la recherche
Outils de construction pour la recherche
 
Aspect avec AspectJ
Aspect avec AspectJAspect avec AspectJ
Aspect avec AspectJ
 
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
 DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 
Solution d'OTA
Solution d'OTASolution d'OTA
Solution d'OTA
 
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven
 
Paris Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascriptParis Web 2015 - Atelier desendettement javascript
Paris Web 2015 - Atelier desendettement javascript
 
sfPot aop
sfPot aopsfPot aop
sfPot aop
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
 
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
#J2Code2018 - Mettez du feu à vos applications avec CodeIgniter
 
Atelier hadoop-single-sign-on
Atelier hadoop-single-sign-onAtelier hadoop-single-sign-on
Atelier hadoop-single-sign-on
 
20091020 - Normandy Jug - Builders Battle
20091020 - Normandy Jug - Builders Battle20091020 - Normandy Jug - Builders Battle
20091020 - Normandy Jug - Builders Battle
 
Comment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open SourceComment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open Source
 
The Spring of Adobe Flex Remoting
The Spring of Adobe Flex RemotingThe Spring of Adobe Flex Remoting
The Spring of Adobe Flex Remoting
 
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
 
Presentation hibernate nfe103
Presentation hibernate nfe103Presentation hibernate nfe103
Presentation hibernate nfe103
 
Présentation GWT et HTML 5 pour l'Offline
Présentation GWT et HTML 5 pour l'OfflinePrésentation GWT et HTML 5 pour l'Offline
Présentation GWT et HTML 5 pour l'Offline
 
Spring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'tsSpring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'ts
 

Dernier

OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO Technology
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
UNITECBordeaux
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
OCTO Technology
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
Université de Franche-Comté
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
OCTO Technology
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Laurent Speyser
 

Dernier (6)

OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
 

121102 aetc_consultingconf4d

  • 1. 4 D S U M M I T E U R O P E 2 0 1 2 Industrialisation du développement 4D avec les composants Presented by : Bruno LEGAY - A&C Consulting 1
  • 2. INDUSTRIALISATION ? De quoi parle-t-on lorsqu'on parle d'"industrialisation" ? L'industrialisation est caractérisée par l'optimisation des processus de fabrications de produits manufacturés. On est ainsi passé d'une production "artisanale" à une production "industrielle". Cette évolution remonte au XIXeme siècle (1801) avec la révolution industrielle qui apparaît en Grande Bretagne. Elle est caractérisée par l'utilisation de machine, la production en série, la standardisation pour abaisser les coûts de production et améliorer la qualité. Quelques dates clés et les tendances dans deux domaines spécifiques • Automobile : o 1886 première voiture ; o 1908 Ford T – Taylorisme : production à la chaîne ; o 1961 premier robot industriel ; o 1990 "commonolisation" (partie cachée commune – partie visible personnalisée). • Informatique – matériel o 1943 Colossus o 1976 Apple I o 1984 Macintosh - IBM PC/AT o standardisation des composants (processeurs, mémoire, disques). On remarque plusieurs tendances : automatisation des taches, standardisation de composants. Toutefois, ces domaines comportent des différences significatives par rapport au logiciel. La conception d'un logiciel s'apparente peu à une succession de tâches prédéfinies et répétitives qui peuvent être découpées, optimisées et enchaînées. Enfin, ces deux domaines ont pour objectifs de produire des biens matériels alors que l'industrie logicielle relève plus d'un travail de conception consistant à produire un bien numérique et immatériel. La question de production en masse ne se pose pas de la même manière. Qu'en est-il de l'industrialisation appliquée au génie logiciel (utopie ou réalité) ? Deux axes : • • automatisation de tâches répétitives standardisation des composants. 2
  • 3. AUTOMATISATION Automatisation de tâches répétitives Pourquoi ? • • • • cohérence / consistance qualité (éviter les erreurs humaines) éviter les dérives se concentrer sur les tâches à valeur ajoutées. Génération de librairies, de code compilé, d'exécutables (construction d'applications avec GENERER APPLICATION, génération d'installeurs, compression, archivage sources, publication, signature md5, etc…). Possibilité d'utiliser plusieurs "profils" d'application (fichier xml "BuildApp"), générateur d'installeur "nsis" sur windows. Les tests unitaires sont destinés à vérifier le bon fonctionnement d'une partie spécifique d'un logiciel (et ceci en toutes circonstances). Les tests unitaires doivent aussi permettre de vérifier qu'une modification du logiciel (modification du code) n'introduit pas de régressions (apparition de nouveaux dysfonctionnements). Les tests unitaires permettent aussi de vérifier rapidement l'impact des changements liés aux plateformes ou aux environnements. En cas ce bug, le contexte est ajouté dans le "test" pour valider la correction et vérifier que ce bug ne réapparaitra plus. Cf méthodes XP (Extreme Programming) ou TDD (Test Driven Development). Génération de documentation. Les documentations techniques sont difficiles à maintenir. La documentation la plus à jour et la plus précise doit se situer au niveau du code. On peut s'inspirer de Javadoc qui est utilisé dans le monde Java. Il s'agit de structurer des informations sur la méthode dans les commentaires à l'aide de balises (ou "tags"). Les macros permettent alors de préparer cette zone avec un "modèle". Le développeur n'a qu'à compléter cette zone. 3
  • 4. STANDARDISATION DES COMPOSANTS Préhistoire des composants 4D Insider est l'ancêtre des composants actuels (apparus en v11). 4D Insider était l'outil de prédilection pour déplacer des objets (méthodes, formulaires, etc…) entre diverses structures. Avec 4D Insider, on pouvait créer des librairies ou composants (avec une notion de composants protégés). 4D Insider avait un certain nombre de limites (l'utilisation des composants n'était pas très souple entre autres). 4D Insider est mort ! Vive les composants ! 4
  • 5. PRINCIPE DES COMPOSANTS Rappel du fonctionnement des composants Un composant est une base de données (placée dans le répertoire "Components"). NOTE : à partir de 4D v12, on peut placer des composants dans l'application 4D (comme pour les plugins). On a une notion de base "hôte" et une (ou plusieurs) base(s) "composant(s)". Pour les sources du composant on parle parfois de la base "matrice". Une base interprétée peut utiliser un composant interprété ou compilé. Une base compilée utilise nécessairement un composant compilé. Attention à la compatibilité des options de compilation (compilation 64 bits par exemple). Les modes "Unicode" de la base "hôte" et la base "composant" doivent être compatibles (c'est-à-dire identique). Les méthodes du composant visibles par la base "hôte" doivent être "partagées". L'inverse est vrai aussi, pour qu'un composant appelle/exécute une méthode de la base "hôte", celle-ci doit aussi être partagée. Les dépendances des composants doivent être maîtrisées (et documentées). Certains objets sont utilisables dans un composant, d'autres ne sont pas utilisables. Objet Utilisable en mode composant Méthode oui Formulaire projet oui Formulaire table non Table et champ non Trigger non Méthode base ("sur ouverture" par exemple) non Utilisateur et Groupe non Préférences/propriétés de la base non De ce fait, certaines commandes n'ont pas de sens (et ne peuvent donc pas être utilisées) comme par exemple "ECRIRE IMAGE DANS BIBLIOTHEQUE". 5
  • 6. Certains objets sont partagés, d'autres sont cloisonnés. Objet Partagé / cloisonné Variable (process et interprocess) cloisonné Variable système (ok, Document, etc…) cloisonné Feuille de style cloisonné Infobulle cloisonné Enumération cloisonné Image bibliothèque cloisonné Menu (éditeur menu) cloisonné Sémaphore cloisonné Ensemble partagé Sélection temporaire partagé Liste hiérarchique partagé Menu (cf Créer menu) partagé Référence xml partagé Référence fichier partagé Pointeur partagé 6
  • 7. AVANTAGES DES COMPOSANTS Quels sont les avantages d'un composant ? Les composants permettent de partager et réutiliser le code de manière efficace. Un composant permet de cloisonner les environnements d'exécution et d'éviter des "collisions". C'est une alternative possible à l'utilisation systématique de préfixes sur les variables. Un composant compilé peut permettre des gains de performances significatifs dans une base interprétée (en développement par exemple). 7
  • 8. CONTRAINTES Quelles sont les contraintes rencontrées lors de la création de composants ? L'implémentation de composant nécessite de bien comprendre les mécanismes de dépendances. Par exemple, si un composant utilise explicitement un plug-in, la base "hôte" devra avoir accès à ce plugin. On rencontre la même contrainte avec les composants (un composant utilisé explicitement dans la base "matrice" devra être installé dans la base "hôte"). La documentation est impérative. En effet, il n'est pas possible de consulter le code d'un composant compilé. Au minimum une description de la méthode avec le détail des paramètres doit figurer dans la zone "commentaires" de l'explorateur (en v12). Les commentaires situés au début de la méthode d'un composant ne sont pas visibles depuis la base "hôte" si le composant est compilé (mais ils sont visibles si le composant est interprété). 8
  • 9. PIEGES Quelques pièges liés aux composant (et comment les éviter / contourner) ? La commande "RESOUDRE POINTEUR" pouvait parfois être utilisée pour comparer si deux pointeurs pointaient bien sur la même variable. Si l'origine des pointeurs est différente, ils peuvent porter le même nom et pourtant ils pointent sur des variables différentes. La comparaison de pointeurs (en passant par RESOUDRE POINTEUR est donc fausse). Il faut simplement comparer directement les pointeurs : Si($vp_ptr1=$vp_ptr2) La commande "Pointeur vers" utilisée dans un composant retournera un pointeur vers une variable du composant. Une astuce consiste à utiliser une méthode de "rétro-appel" (ou "callback"). Dans la base "hôte", on crée une fonction qui fera appel à "Pointeur vers" (on oublie pas de partager cette méthode) et on passe au composant le nom de cette fonction. Le composant pourra alors appeler cette fonction (via la commande "EXECUTER METHODE"). La création de cette méthode de "callback" peut même être automatisée. 9
  • 10. DEPENDANCES SOUPLES Comment gérer des dépendances souples ? On peut avoir besoin d'avoir de composants qui font appel de manière optionnelle à un autre composant. Soit parce que ce composant n'est nécessaire que dans un contexte (contexte de développement dans la base "matrice") ou parce que ce composant fournit une fonctionnalité optionnelle lors de l'utilisation. Dans ce cas, si l'appel à ce composant est effectué de manière explicite, on aura un message d'erreur à l'ouverture de la base "hôte". Le composant doit détecter de manière transparente la présence de l'autre composant et agir de manière appropriée. C'est ce qu'on appelle une dépendance souple. Pour détecter la présence d'un composant, il y a la commande LISTE COMPOSANTS. On peut ensuite faire appel aux méthodes du composant via la commande EXECUTER METHODE pour éviter les problèmes de dépendances fortes. // LOG_debug ($vt_message) TABLEAU TEXTE($tt_componentsList;0) LISTE COMPOSANTS($tt_componentsList) Si(Chercher dans tableau($tt_componentsList;"LOG_component")>0) EXECUTER METHODE("LOG_debug";*;$vt_message) Fin de si TABLEAU TEXTE($tt_componentsList;0) 10
  • 11. ASTUCES Quelques astuces Il est parfois nécessaire de déterminer si le code s'exécute dans le composant ou dans la base "hôte". Pour cela on peut comparer le résultat de la commande "Fichier structure" avec et sans l'option "*". Par défaut (sans "*") Fichier structure retourne le nom long/chemin du fichier structure (fichier .4db ou .4dc) du composant. Si "*" est passé, Fichier structure retournera le nom long/chemin du fichier structure de la base hôte (si on est dans un composant) Si(Fichier structure # Fichier structure(*)) // on est dans un composant … Sinon // on est pas dans un composant … Fin de si On peut en faire une fonction, mais attention, par définition cette méthode ne pourra pas s'utiliser comme une méthode partagée d'un composant. Il faut la copier… On a parfois besoin de déterminer quelle est la langue du langage 4D utilisée (les commandes sontelles en français ou en anglais) ? C_ALPHA(2;$va_language) C_TEXTE($vt_commandNameOfCommandName) $vt_commandNameOfCommandName:=Nom commande(538) //538  "Command name" Au cas ou : ($vt_commandNameOfCommandName="Nom commande") $va_language:="fr" : ($vt_commandNameOfCommandName="Command name") $va_language:="en" Sinon $va_language:="en" Fin de cas 11
  • 12. LES COMPOSANTS FOURNIS PAR 4D 4D fourni quelques composants standard 4D fourni déjà quelques composants 4D SVG : images vectorielles SVG pour le runtime 4D Widgets propose un datePicker et timePicker pour le runtime 4D Pop propose des fonctionnalités au développeur. Composant orienté vers l'environnement de développement. Sans oublier tous les composants fournis par Keisuke Miyako Au delà des composants fournis par 4D, quel est l'intérêt pour un développeur à créer ses propres composants ? 12
  • 13. POURQUOI CREER UN COMPOSANT Dans quel cas doit-on envisager de créer un composant ? Dans un logiciel, on peut déterminer un ratio "glue" / "substance" (cf Alexander Stepanov). La partie "glue" correspond au code qui ne répond pas directement au besoin du projet et la "substance" correspond à la partie spécifique (au métier). On peut mesurer ceci sur la base du nombre de lignes. Par exemple, dans un de nos projets, nous avons effectué récemment des métriques et nous avons constaté que sur 310 000 lignes de code (méthodes projet) 43,5 % du code était du code générique et que le reste 56,5 % était du code spécifique. Objectif d'efficacité : se concentrer sur le métier/fonctionnel et simplifier la ré-utilisation du code technique générique testé et éprouvé (mise en place, maintenance). Objectif de qualité : en simplifiant la mise en place (et la mise à jour) de code générique, on facilite la réutilisation. L'amélioration continue du code générique (ajout de fonctionnalités, optimisation, correction de bugs) est plus facilement mutualisée entre les projets et contribue à une amélioration de la qualité globale des applications. Ces objectifs sont surtout intéressant pour les développeurs qui travaillent sur plusieurs projets. 13
  • 14. QUE PEUT-ON FAIRE AVEC UN COMPOSANT Un composant, oui, mais pour faire quoi ? On peut créer des composants pour packager des méthodes bien évidemment (génération de codes barres), on peut afficher des formulaires (formulaires base) pour l'affichage des thermomètres, une zone Web area (pour une fenêtre GoogleMaps par exemple) par exemple. On peut aussi utiliser les composants pour packager des binaires ou outils externes. On peut par exemple placer les exécutables (OS X et Windows) dans le répertoire "Resources" et les appeler via la commande LANCER PROCESS EXTERNE. Idem pour des fonctions PHP (scripts php). Par exemple, 7z pour la compression zip, xmllint pour la validation schéma xml avec XInclude, rsync+cygwin, ImageMagick, wkhtmltopdf, etc… On peut facilement placer des méta-données dans un composant. Par exemple, on peut placer des meta-données au format xml dans le répertoire "Resources" qui seront accessibles via une méthode partagée du composant (par exemple les codes escape url http et/ou html). Les composants peuvent aussi être utilisés pour wrapper les plugins (4D for OCI par exemple). On peut créer des composants qui permettent de basculer entre différents plugins similaires (commandes TCP des Internet Commands, NTK et ITK) ou entre un plug-in et du code 4D pur (ObjectTools, XML Plugin, etc…). 14
  • 15. CHOIX Quelles questions doit-on se poser avant de se lancer ? Quel type de composant va-t-on créer ? Un seul composant avec toutes les méthodes à l'intérieur (approche monolithique) ou un plusieurs composants (approche modulaire) ? Dans le cas d'une approche modulaire, comment seront gérées les dépendances entre les composants ? Composant interprété ou compilé (si oui pour quelle plateformes) ? Composant Unicode ? Comment mettre en place, définir et stabiliser ses API (maturation des points d'entrée, flexibilité/souplesse de fonctionnement avec l'utilisation de paramètres optionnels et callback, stabilité, pérennité et rétro-compatibilité) ? 15
  • 16. NOTRE CONTEXTE Le contexte dans lequel nous avons été amenés à mettre en place des composants est le suivant A&C Consulting est une SSII avec 3 développeurs 4D expérimentés. Nous travaillons sur de nombreux projets spécifiques. Nous avons construit au fil des années une bibliothèque de code générique, mais les méthodes de mutualisation de ce code étaient encore artisanales. A&C Consulting a une expérience de commercialisation d'un composant. Ce composant est lié au plugin 4D for OCI : ociLib. C'est un composant qui a été mis au point pour les besoins d'un de nos clients et ensuite proposé à des développeurs tiers qui étaient intéressés. Nous travaillons depuis plusieurs années avec une approche générique modulaire 16
  • 17. NOTRE APPROCHE Voici l'approche qui a été retenue : Dans un premier temps (première phase), nous nous focalisons sur les "couches basses". Pour ces couches basses, nous avons retenu une approche modulaire (file system, blob, env, http, html, io, log, objectTools, tableaux, text, zip, etc…) Nous avons une volonté de limiter les dépendances (quitte à dupliquer du code entre des composants) pour des raisons de souplesse mais aussi pour éviter les problèmes de compatibilité liées aux versions. C'est un travail de longue haleine (135 000 lignes de code) qui se fait petit à petit (un ensemble logique de code générique correspondant à un module est converti en composant et ce code est retiré des projets pour être remplacé par le nouveau composant). La documentation est impérative et prend du temps. La re-factorisation prend du temps (module fourre-tout "UTL" qui nécessite d'être réorganiser de manière plus logique). Plus tard, nous prévoyons de mettre en place un composant de niveau intermédiaire qui s'appuiera sur les composants "couches basses" avec des dépendances fortes. 17
  • 18. CONVENTION DE NOMMAGE Les conventions de nommage des méthodes sont importantes Nous utilisons un système de préfixe dans les noms des méthodes pour facilement identifier l'origine d'une méthode (quel composant). Pour chaque composant nous fixons un code mnémotechnique de deux à quatre lettres : HTTP_GET => composant "http_component" FS_macPathToUnixPath => composant "fs_component" Dans le composant (base "matrice"), les méthodes qui ne sont pas partagées (et invisibles) contiennent deux "_" après le préfixe. Ceci permet de s'appuyer sur la convention de nommage pour fixer rapidement les attributs des méthodes (via l'écran "Modifier attributs globalement") et de les trier dans l'explorateur. NOTE : la notion de "partagé entre composant et base hôte" n'est pas visible dans l'explorateur des méthodes tandis que la notion "visible/invisible" est repérable tout de suite, il est donc judicieux de les fixer de manière similaire/cohérente. 18
  • 19. DOCUMENTATION Comment gérer la documentation des composants La documentation est fondamentale pour la mise en place de composant (rappel le code source et les commentaires d'un composant compilé ne sont pas accessibles). L'approche Javadoc qui est une solution proposée dans un autre langage pour répondre une problématique similaire (documentation d'API) est une bonne source d'inspiration Principe basé sur des "balises" (ou tags) placées dans les commentaires en entête L'entête défaut (avec les tags) est généré par une macro. Ensuite, un peu d'API Pack pour automatiser tout ça… Un composant maison "xdoc" (s'appuyant sur API Pack) est utilisé pour lire le contenu de chaque méthode, identifier les balises/tags de documentation, effectuer une conversion en xml. Cet xml peut ensuite être utilisé pour générer différents formats de documentation (rtf, html, pdf, etc…). Pour l'instant, nous utilisons 4D Write pour générer un texte stylé rtf (par méthode) qui est ensuite placé dans la zone "Commentaires" de la méthode. Attention : c'est un hack (reverse engineering) : il n'y a malheureusement pas, à ma connaissance, de moyen officiel pour alimenter cette zone. 19
  • 20. TESTS Pourquoi tester et valider son composant et comment y arriver ? Tester son composant avant de le déployer est important si on veut éviter des "aller-retour" superflus. Les tests permettent de valider le fonctionnement nominal, de vérifier la non-régression, de valider une optimisation, de valider le comportement lors d'un changement de version de 4D, de tester sur une plateforme spécifique, etc…). L'utilisation de tests unitaires permet de valider le fonctionnement du composant en automatisant les tests. Les tests unitaires permettent de réduire les tests manuels qu'un développeur consciencieux devrait faire (parcourir quelques fonctionnalités de l'application pour vérifier le bon fonctionnement). Pourquoi ? Parce que ces tests sont répétitifs, qu'ils sont chronophages, et qu'ils sont donc rarement effectués en pratique. Les tests unitaires permettent d'éviter (ou toutefois de limiter) le nombre d'anomalies/de bugs contenues dans une application livrée au client. La mise en place de ces tests unitaires est aussi chronophage… Donc il faut faire preuve de bon sens et pragmatisme sur les tests unitaires… Par exemple, il n'est pas prioritaire d'ajouter des tests unitaires sur une méthode simple et qui marche bien. Par contre, lors de la correction d'un bug lié à un contexte particulier, il est souvent souhaitable d'ajouter ce contexte dans les tests unitaires en ajoutant un "test case". Pour les méthodes complexes, l'ajout de tests unitaires permet de garantir leur bon fonctionnement (vecteur de test md5 par exemple). 20
  • 21. GESTION DES VERSIONS Comment gérer les versions de ses composants ? Une approche simple pour gérer les versions de son composant est de créer une fonction : xxx_componentVersionGet Cette fonction retourne la version du composant et on peut commenter l'historique du composant dans le code source de cette méthode (dans les commentaires). Si le composant génère des fichiers de logs lors de l'exécution, cette méthode peut être appelée à l'initialisation du composant et le résultat est envoyé dans le fichier de log. 21
  • 22. INITIALISATION Les composants on parfois besoin d'être initialisés. Comment gérer cette initialisation ? Les composants contiennent des variables (et des tableaux notamment) qui nécessitent des déclarations et parfois des initialisations. Ces variables peuvent être des variables “process/globales” ou “interprocess”. Ces opérations sont effectuées dans des méthodes qui correspondent : initialisation process ou inteprocess. Attention l'appel à une méthode d'initialisation effectué de manière erronée/inopinée ne doit pas vider les tableaux déclarés (qui peuvent être alimentés). Il faut donc gérer, avec un flag booléen (un flag process et un flag interprocess), le fait que l'initialisation du composant a été effectué (ou pas). Ces initialisations peuvent être publiques et explicites (c'est au développeur qui utilise le composant de faire appel à la méthode d'initialisation de manière appropriée) ou cette initialisation peut être privée, elle doit alors être implicite et transparente. 22
  • 23. MODELE DE COMPOSANT Lorsqu'on crée régulièrement des composants, on s'aperçoit qu'on utilise souvent des préférences et quelques méthodes identiques. Nous avons standardisé l'organisation d'un composant avec trois répertoires : - build - src - test Des préférences standard sont définies dans la base "modèle de composant". Les quelques méthodes standard sont pré-installées dans le modèle (xxx_componentVersionGet, etc…) Enfin, une petite "checklist" permet de s'assurer qu'on a bien effectué toutes les tâches de personnalisation du modèle. 23
  • 24. GESTION DES VERSIONS DE 4D Comment gérer les composants selon les différentes versions de 4D ? La transposition directe du code n'est pas toujours évidente (par exemple les caractères de commentaires ` en v11 et // à partir de v12). Les composants ont principalement été créés et mis au point en v11. On a donc converti ces composants en v12 en maintenant les deux versions en parallèle. Les corrections ont été reportées manuellement au cas par cas. Certaines commandes ou préférences sont spécifiques à une version. Par exemple la notion "compilation 64 bits" n'existait pas en v11. Il y a des commandes qui changent de nom (attention à l'export de code en texte) ou qui apparaissent et peuvent nécessiter une amélioration du code pour en tenir compte (en v13 : GENERER DIGEST, HTTP Client, etc…). Le code peut toutefois anticiper et s'adapter. On peut, par exemple, dans une méthode v12 tenir compte d'un nouveau comportement spécifique à la v13 et s'adapter. Lorsque le composant sera converti en v13, la méthode s'exécutera de manière optimale sans avoir été modifiée. Hormis les nouveautés apparues en v13, les composants v12 sont compatibles v13. Les composants v11 sont compatibles v11 uniquement. 24
  • 25. CONCLUSION Quel bilan peut-on tirer de notre expérience avec les composants ? En quelques mots : "les composants : ça marche !" Les composants sont une solution adaptée, intéressante et élégante pour la gestion du code générique lorsqu'on doit gérer plusieurs projets. Une attention particulière doit être apportée sur la documentation pour faciliter l'utilisation du composant. 25