It is by far
the best if these changes can be made quickly, with minimal interruption to the work of
the pilot team. As with laterDSMuse, this is an area where you will see real bene?¬?ts to
having a DSM environment that makes such evolution possible and easy. Useful
features include being able to metamodel and model in the same environment, as
opposed to different environments, and automatic updates of existing models as the
metamodel changes.
While versioning in general has a smaller role in DSM than in code-based
development (see Section 15.3), it is at its most important during the pilot project. At
no other stage will the parts of the DSM solution be evolving so rapidly while there
346 DSM DEFINITION PROCESS
are models that rely on them. You must know at all stages which version of the
metamodel the models correspond to, and which versions of the metamodel,
generators, and domain framework go together. In each of these elements, there are
two kinds of changes: changes that require a change in other elements, and changes
that do not (e.g., simply changing symbols or ?¬?xing a bug in a domain framework
function). Use major and minor version numbers to separate the two kinds of change,
and have elements??™ version comments refer to the versions of the other elements they
depend on. In particular, the generator will depend on both the metamodel and the
domain framework.
Pages:
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654