The
interface between teams should be slight in this case, as it will be limited to the legacy
MODEL SHARING AND SPLITTING 403
approach of design documentation and code. (Admittedly, the situation is thus no
worse than it has been earlier, but it will certainly appear worse when it sits next to the
shiny new DSM solution!)
In a more complicated case, there may be a set of core models that all users should
have access to. These can be maintained in a separate repository and periodically
exported and distributed to all satellite repositories. There they are imported, making
them available for transparent access in those repositories. Since that access will
almost certainly include reusing and referring to elements from those models, a
simple import and export will not suf?¬?ce.
When an updated version of the core models is reimported to the satellite
repositories, the existing elements must be updated in place, so that any references
from the local models to the core models will now point to the updated elements.
Based on our experiences with a system like this, which has been in MetaEdit+ since
1997, such an approach works well, provided it is used as part of a de?¬?ned process.
Uncontrolled import and export in all directions is more likely to lead to a mess than to
the miracle of making disconnected repositories appear connected, by automatically
merging their differences into a cohesive whole.
Pages:
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780