Verrouillage
des modèles
Lorsque
de gros projets sont élaborés et particulièrement
lorsque plusieurs personnes y sont impliquées, il devient utile
de pouvoir empêcher des changements à certaines parties du
projet, mais de permettre la modification d'autres parties du modèles.
En utilisant la fonction de Verrouillage de modèles, il est
possible de verrouiller un ou plusieurs modèles, sous-modèles
ou paquetages, dans le but de prévenir un changement dans une partie
particulière du projet.
Tous
les modèles relationnelles, de processus ou de classes, tous les
sous-modèles relationnelles et tous les paquetages Java peuvent
être verrouillés. Pour ce faire, sélectionner
le modèle ou le paquetage approprié dans l'Explorateur,
et activer la propriété Verouillé dans le Panneau
de conception. Une fois le modèle ou paquetage verrouillé,
il n'est plus possible de faire de modification sémantique ou graphique
à son contenu, ou à tous les sous-modèles ou sous-paquetages
sous le modèle/paquetage verouillé.
Voici
quelques cas où le Verrouillage de modèles peut être
utile :
-
Nous
procédons à la rétro-ingénierie de bases de
données relationnelles; le modèle résultant représente
la structure physique de la base de données à un moment donné;
Nous désirons améliorer le modèle, mais nous voulons
conserver la version original intact. Pour faire cela, nous copions le
modèle resultant de la rétro-ingénierie, nous verrouillons
l'original et nous ne travaillons que sur la copie. On peut utiliser la
fonction Comparer/Intégrer pour visualiser les améliorations
apportées depuis que le moment de la rétro-ingénierie.
-
Nous
groupons un contexte d'affaires sous un processus externe dans un autre
fichier de projet. Nous voulons continuer à travailler dans
le contexte d'affaire original, mais nous voulons prévenir tout
changement sous le modèle d'affaire principale afin de faciliter
toute intégration subséquente. Nous sélectionons l'ancien
processus externe et nous le verrouillons afin d'empêcher trout changement.
-
Nous
modélisons du code Java provenant à la fois de développement
interne et de tiers partie. Comme nous n'avons pas le droit de modifier
le code provenant du tiers partie, nous voulons empêcher tout changement
dans le modèle de classe correspondant. Nous sélectionnons
le paquetage principal du tiers partie, et nous le vérrouillons.