When the concepts and connections of the modeling language have taken shape,
we turn them into a metamodel by inputting them into theDSMenvironment. For now,
the graphical representations of the objects will be minimal: colored geometrical
shapes with text ?¬?elds within them to showthe values of their properties. While part of
the team is inputting the metamodel, another part often ?¬‚eshes out the sketch model of
the sample application on a whiteboard.
When the metamodel is ready, it is passed off to the model group, who create this
?¬?rst model with the new modeling language in the tool. As they are working on that,
the metamodel group start looking at code generation. By the end of the ?¬?rst day, there
is always a metamodel and a model, and generally a code generator that produces a
signi?¬?cant proportion of the code. Parts of the code produced will still be ?¬?xed, rather
than varying properly based on the information in the model.
Since as visitors we are generally staying in a hotel for the night, we normally take
the chance to work in the evening on things that are objectively less important but, in
practice, give a disproportionate bene?¬?t: pretty symbols for the modeling language,
and slides for the presentation in the meeting the next day. We sometimes do a little
refactoring of the modeling language or generators if they need it, but nothing major.
Pages:
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633