Discussion :

[SKZ81]

Bonjour Bruno (comment va depuis le temps ? ) bonjour tout le monde...

Voilà j'explique mon soucis : nous utilisons Bouml en environement professionel. Pour l'instant, je suis le seul utilisateur car architecte, l'analyse est maintenant terminée.

Nous allons attaquer l'implémentation, au sein du modèle le plus longtemps possible pour faciliter la production d'un Global Design en phase avec le code. L'idée est bien évidemment de versioner le modèle pour n'avoir aucune perte.

Là se pose une question : étant donné qu'on travaille en vue locale (normal avec tortoise/SVN) le méchanisme multi-utilisateur risque d'être mis à mal : pas de méchanisme de protection, "lock".
L'idée serais que chacun travaille sur une classe donnée à un instant T, i.e. entre un update et un commit, l'équipe n'est pas grosse, c'est gérable.

Mais s'il advenait tout de même un conflit ? Est-ce que le merge est aisé ? Ca me semble gérable grâce au découpage en 1 fichier texte par classe du modèle, mais si quelqu'un à un retour d'expérience...


De deux : l'idée serait de partager le modèle sur le serveur (bon là on a un petit soucis de redondance entre le back-up et la gConf, m'enfin...).
Quel est le méchanisme de protection multi-utilisateur (s'il y en a un comme dans mes souvenirs) ?? Je demande ça car on a eu quelque soucis du fait que nos PC sont sous Windows, alors que les serveurs sont linux, et le mechanisme de notification je pense intrinsèque Access pédalait dans la semoule (on pouvait se marcher sur les pieds alors que normalement -- comprennez avec des serveurs NT -- c'est impossible).

D'avance merci !!

[bruno_pages]

Bonjour,

Versionement du modèle

Pour te simplifier la vie je te conseille vivement d'utiliser File control, la granularité étant le package.

Tu as parlé d'un fichier par classe : ce fichier contient seulement le corps des opérations, le 'vrai' fichier de mémorisation est celui associé aux packages, même s'il y a d'autres fichiers annexes (voir le chapitre project files de la doc).

Protection multi-utilisateurs

Concernant la question principale, le moyen le plus sure et n'imposant pas de partager un disque supportant des droits d'écriture pour une seule personne fichier par fichier est d'utiliser Project control. Celui-ci modifie l'en-tête des fichiers liés aux package pour éventuellement indiquer que seul un utilisateur donné (en fait un BOUML_ID) a un droit de modification. Cet en-tête est bien-sur utilisé par le modeleur.

Dans une utilisation normale et sure, chaque package doit être modifiable par un seul utilisateur, ou par aucun, bref pas de package noir.

Le second outil associé est Project synchro, qui permet de synchroniser les modifications faites en parallele sur des copies du projet. Si vous travaillez tous sur une même image du projet (tous le monde tape sur les mêmes fichiers du même disque partagé) alors celui-ci est inutile. Si vous utilisez la synchronisation attention de bien respecter les règles de la doc, sous peine d'avoir des modifications d'un même fichier du modèle faites en parallele, j'ai des utilisateurs qui se sont retrouvé avec des objets dupliqués pour ne pas l'avoir fait, et cela peut provoquer un crash, ou une destruction silencieuse du modèle.

Project synchro ne fait donc pas de merge, il ne modifie pas le contenu des fichiers mais resynchronise les images d'un projet pour que tout le monde est la version la plus récente de chacun.

Ceci dit, je connais des personnes faisant des merges avec des outils classiques, les fichiers de mémorisation du modèle sont des fichiers texte et non binaire pour permettre ce genre de chose.

[SKZ81]

Merci beaucoup pour ta réponse et tes précisions.

Au temps pour moi concernant les fichiers, j'avais regardé vite fait avant de poster, j'm'a trompé

Etant donné les caractéristiques de notre organisation (planning qui craque aux coutures et des interventions presque simultanées sur certains élements du modèle afin de boucler le projet) nous n'aurons pas de temps pour plannifier la synchronisation ni le project control (sauf peut-être pour rapatrier le travail de la jeune recrue qui assurera l'intérim pendant nos vacances, pour éviter, à tout hasard, qu'il ne casse tout... )

A priori nous allons donc plutôt partir sur une image unique et partagée.

Donc une petite question : quelle limite au fait que différents utilisateurs "tape" dans la même image ? Mettons qu'ils éditent concurremment le même élement de modèle ? (Propriétés d'une classe, body d'une methode, etc.)
Est-ce tout simplement possible ?

Si oui, une fois le OK pressé, que se passe-t-il ?

Je vais faire quelques tests mais ton avis éclairé me sera utile. Merci d'avance !

[bruno_pages]

A priori nous allons donc plutôt partir sur une image unique et partagée.

Donc une petite question : quelle limite au fait que différents utilisateurs "tape" dans la même image ? Mettons qu'ils éditent concurremment le même élement de modèle ? (Propriétés d'une classe, body d'une methode, etc.)
Est-ce tout simplement possible ?

Si oui, une fois le OK pressé, que se passe-t-il ?

Au moment du OK rien de particulier au niveau global

Par contre c'est dernier qui sauve qui gagne

il faut donc impérativement que vous utilisiez Project control pour qu'un package donné ne soit en écriture pour personne ou pour une seule personne, et tout changement de droit autre que écriture -> pas écriture doit se faire en même temps pour tout le monde

[SKZ81]

Aïe aïe aïe !

Bon, ça ira pour le début en augmentant la granularité des packages (en divisant plus en sous packages), mais pour la phase de test / correction, ça va être sûrement assez pénible...

Je pense qu'on va aalors être obligés de travailler directement sur le code, et mettre à jour en parallèle le modèle...

Ce serait vraiment plus pratique avec une granularité de contrôle au niveau de la classe (voire plus fine, mais bon) et dynamique (un système de mutex : dès que quelqu'un édite un élément, il le vérouille, jusqu'à ce qu'il relâche son édition).

Si ça pouvait éventuellement être fait dans des versions ulterieures (sans forcément se passer du project control qui a aussi une utilité mais différente) bouml gagnerait en utilisabilité...
A voir

Merci en tout cas pour ces précisions

[bruno_pages]

Bon, ça ira pour le début en augmentant la granularité des packages (en divisant plus en sous packages), mais pour la phase de test / correction, ça va être sûrement assez pénible...

Je pense qu'on va aalors être obligés de travailler directement sur le code, et mettre à jour en parallèle le modèle...

je suis assez etonné de cette réaction, a priori à plusieurs (et même seul) on ne met pas tout a plat mais on fait des découpages en packages rendant les choses plus claires. Tout le monde travaillant sur le même sujet cela me parait bizarre et peut laiser transparaitre un problème d'architecture, non ?

Note : ce n'est pas parce que l'on place des classes dans deux packages Bouml différent que les classes seront produites dans les répertoires ou même fichiers différents, ou des packages Java / namespace C++ / module Idl différents. Le découpage du modèle n'implique pas forcement un découpage en déploiment. Ceci dit il est plus clair de faire ainsi lorsqu'on a le choix

Ce serait vraiment plus pratique avec une granularité de contrôle au niveau de la classe (voire plus fine, mais bon) et dynamique (un système de mutex : dès que quelqu'un édite un élément, il le vérouille, jusqu'à ce qu'il relâche son édition).

comment veux-tu que je mettre un mutex alors que je ne sais meme pas si les utilisateurs travailles sur les memes fichiers ? d'autre part cela demandrait des relectures à la volée d'une sous partie du modèle pour prendre en compte les modifs des autres avant de faire ses propres modifs

Si ça pouvait éventuellement être fait dans des versions ulterieures (sans forcément se passer du project control qui a aussi une utilité mais différente) bouml gagnerait en utilisabilité...

désolé mais ce que tu demandes est plus proche de la bidouille que d'un mode de fonctionnement professionnel

[SKZ81]

je suis assez etonné de cette réaction, a priori à plusieurs (et même seul) on ne met pas tout a plat mais on fait des découpages en packages rendant les choses plus claires. Tout le monde travaillant sur le même sujet cela me parait bizarre et peut laiser transparaitre un problème d'architecture, non ?

Non. En fait je suis maitre du modèle, les autres personnes (outre le technical product manager qui se trouve être aussi un codeur et presta, héhé) ne font que remplir les méthodes.

Le découpage en package est net et il y a un "resposable" désigné pour chaque, mais le timing est tellement serré que les personnes seront à coup sûr, vers la fin, amené à switcher fréquemment, en fonction des compétances et des disponibilités.
De plus en période de tests, ces "responsabilités" sont dissoutes, et chaque membre du projet sera amené à corriger des choses qu'il n'aura pas forcément codé, le system du project control deviendrais plus handicapant qu'autre chose. Tout ça parceque le planning est trop sérré.
Dans un mode de fonctionnement où l'on gère un fault reporting, et où le responsable de tel ou tel module apporte la correction nécessaire, ça aurait été faisable, mais là, clairement non.

Note : ce n'est pas parce que l'on place des classes dans deux packages Bouml différent que les classes seront produites dans les répertoires ou même fichiers différents, ou des packages Java / namespace C++ / module Idl différents. Le découpage du modèle n'implique pas forcement un découpage en déploiment. Ceci dit il est plus clair de faire ainsi lorsqu'on a le choix

Tout à fait, c'est ce que je voulais dire en parlant d'augmenter la granularité du modèle. Il y a des sous-ensembles cohérents, qui se retrouveront dans le même répertoire au final, mais que je peux isoler dans un package uniquement logique (ce que j'ai fait cet aprèm).

comment veux-tu que je mettre un mutex alors que je ne sais meme pas si les utilisateurs travailles sur les memes fichiers ?

Je parlais dans le cas d'un image partagée : l'information de qui édite quoi pourrait être stockée dans le fichier session, au même titre que les diagrammes ouverts !!
Au moment où un utilisateur veut éditer (ou supprimer) un élément, il suffit de vérifier les sessions des autres

d'autre part cela demandrait des relectures à la volée d'une sous partie du modèle pour prendre en compte les modifs des autres avant de faire ses propres modifs

Arf !!
Oui, là j'avais pas mesuré l'impact, qui est effectivement assez lourd...
Ne pourrait-t-il pas y avoir un genre d'historique des modifs, afin de les importer dans chaque bouml pour synchroniser les différents bouml ?
(Bon, j'admets que ça change radicalement la philosophie de l'outil, que ça implique de multiples modifications afin d'éviter tout effet de bord...)

désolé mais ce que tu demandes est plus proche de la bidouille que d'un mode de fonctionnement professionnel

Pas sûr de comprendre...
J'espère que tu comprends les raisons qui m'ont amenées à souhaiter une synchronisation des différents modèles à la volée, quasiment en temps réél.
Difficultés d'organisation, de planning, et de compétances/formation des ressources : en gros moi je conçois et code, le CDP manage et code un peu, plus deux autres gars (dont un qui débarque complètement) qui codent comme ils peuvent pour qu'on finisse dans les temps. Alors OUI le découpage des tâches n'est carrément pas rigoureux, si on pouvait, on s'organiserait autrement... Néanmoins si travailler dans l'urgence (et avec les moyens du bord) n'a rien de pro, j'apprends quelque chose !
En tout cas, ça ne mets pas en cause la qualité de l'archi, ni de MON code à moi

Au final, tout ça pour des raisons de délais, ça aurait parfait si on avait eu 3 ou 4 mois à 2 mais non, on n'a que 1,5 mois alors on récupère deux bras cassés qui nécessiteront aide et assistance.

En quoi ça m'implique ??

PS : Et comprends que mes propositions restent des idées, pas des requêtes !!
PPS : une caresse de ma part à la petite mère féline

[bruno_pages]

je suis en grande partie avec toi, mais à la fin de la phase de developpement et donc en phase de test il est à priori peu probable que tout le monde travaille de facon séparée, c'est plus du travail de groupe avec plusieurs personnes derrière celle qui a le clavier (les roles étant interchangeable).
D'autre part dans cette phase il y a plus de changement de code (corps des operations) que de changements de profile d'operation, de creation d'operation ou de classe. Il faut alors éditer le code des opérations en dehors de Bouml après avoir mis preserve operation's body et fait une génération de code générale (il est même probable que cela sera fait dés le début du developpement car cela simplifie énormément le travail de correction des erreurs de syntaxe). Ainsi les changements de 'propriete' via project control restent limités.