Even if the modeling
language were perfect, there would still be times when two model fragments would be
similar in a number of respects and different in others, but purely by chance rather than
any underlying relationship between them.
Another possible cause is a factor outside of the scope of the DSM solution,
for example, a business agreement or a divergent branch of development. A model
for one client may be similar to that required for a subsequent client, yet the
agreement speci?¬?es that the models must also be editable by the client. If the
development for the previous client is not frozen, the second client obviously cannot
be allowed to edit the same set of models. The models must therefore be copied
deeply, at least for those that will be passed to the second client. Even if the client
does not request the right to edit the models, a project-based organization will often
prefer to keep the two projects disjoint.Although this is not ideal, the situation is still
signi?¬?cantly better than with code-based development: the modeling language and
generators ensure that the majority of commonalities are shared by all from one
central source.
15.2 MODEL SHARING AND SPLITTING
So far, we have largely considered one set of models in one instance of a tool. This
seems to be the theoretical ideal for DSM, taking the greatest advantage of the
possibilities for model reuse.
Pages:
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772