Qu’est-ce qu’une bibliothèque distante ?
Une bibliothèque distante (également appelée modèle HTTP) est une partie de modèle indépendante, identifiée et cohérente, issue d’un modèle plus important et disponsible sur un réseau. Le protocol réseau supporté est http.
Les bibliothèques distantes peuvent contenir n’importe quel type de modèle, soit des modèles complets avec toutes les annotations (tags, notes), soit des modèles simplifiés composés de namespaces et de liens d’héritage, comme cela est souvent le cas pour les composants de modèle.
Quels avantages présente l’utilisation des bibliothèques distantes ?
En tant que bibliothèques, les bibliothèques distantes fournissent des éléments de modèle en mode lecture seule, tout comme les composants de modèle (les bibliothèques locales). Elles permettent aux développeurs de partager des modèles à travers un réseau. Par exemple, plusieurs équipes géographiquement distinctes peuvent travailler ensemble, en partageant des modèles sous forme de bibliothèques.
Comparés aux composants de modèle, les modèles HTTP ne sont pas explicitement versionnés. Cependant, comme ils sont directement consultés depuis le réseau (et ne sont pas installés localement), ils bénéficient d’une mise à jour quasiment en temps réel en cas de modification. Plus exactement, leur contenu est rafraîchi à chaque ouverture du projet qui les référence. En outre, la fenêtre de configuration des projets Modelio fournit une commande Rafraîchir explicite dans son onglet Bibliothèques.
Dans un projet multi-utilisateur à grande échelle, avec plusieurs personnes travaillant en même temps dans un même espace de travail, les bibliothèques distantes sont utiles, car elles permettent à chaque équipe de développement de progresser dans son propre espace de travail en fonction de son propre calendrier, sans affecter les autres participants au projet.
Dans l’exemple suivant, chaque équipe développe son propre composant et le publie sur un serveur HTTP commun, afin de partager son travail.
L’équipe d’intégration ne publie aucun modèle, mais regroupe tous les modèles afin de construire l’application finale.
Les bibliothèques locales ou les bibliothèques distantes pour mon projet ?
Il n’y a pas de réponse universelle à cette question.
Pourtant, il peut s’avérer utile de prendre en considération les informations suivantes avant de prendre votre décision.
Les composants de modèle
-
Les composants de modèle sont explicitement versionnés et donc bien identifiés.
-
Une fois déployés, les composants de modèle ne nécessitent pas une connexion active au réseau. Naviguer dans les composants de modèle peut être légèrement plus efficace (l’accès à un disque local comparé à l’accès à un réseau pour les modèles HTTP).
-
Les composants de modèle ont besoin de passer par la phase de deploiement à chaque mise à jour. Même si les opérations de mise à jour sont rapides, elles doivent être effectuées explicitement par l’utilisateur, contrairement aux modèles HTTP qui sont toujours à jour.
Les bibliothèques HTTP
-
Les bibliothèques HTTP ne sont pas explicitement versionnées et ne sont identifiées que par leur URL.
-
Pour accéder au contenu des bibliothèques HTTP, il faut une connexion active au réseau.
-
Les bibliothèques HTTP ne nécessitent ni déploiement ni mise à jour. A chaque ouverture (ou ré-ouverture) du projet, leur contenu est à jour sans l’intervention de l’utilisateur.
Nous recommandons l’utilisation de composants de modèle (bibliothèques locales) pour les composants stables qui sont utilisés dans votre projet et qui sont externes à votre projet, autrement dit, qui ne sont pas développés dans le projet. Par exemple, le JDK ou d’autres logiciels tiers. Si vous avez l’intention d’utiliser des composants de modèle pour des parties de votre projet, ce qui peut être une bonne idée dans certains projets, préparez un processus bien défini pour la gestion de ces composants : livraison de versions, publication de versions, déploiement synchrone pour toute l’équipe, et ainsi de suite. En revanche, nous recommandons l’utilisation de bibliothèques HTTP (bibliothèques distantes) pour vos composants figurant dans les projets. Les différentes équipes peuvent ainsi rester à jour à un coût minimal, tout en gardant une approche modulaire et en évitant le syndrome mortel de "n’importe qui peut modifier n’importe quoi".