A change to that schema will have larger implications for the
existing models and the accumulated experience of the modelers than a change to the
generators or domain framework. To put this another way: if we mess up when
building the generator or domain framework, we will probably be able to correct the
problem with little cost and with an instant and global effect; if we mess up in the
modeling language, the cost of updating models will be signi?¬?cant, and that update
may not be automatic.
DEFINING THE DSM SOLUTION 341
As in the proof of concept, it is thus worth spending more time at the start on
the modeling language. We can divide the modeling language into three areas: its
concepts, its rules, and its visual notation.
Concepts Of the three areas, the main one to concentrate on is the concepts
and their interrelations: the abstract syntax of the modeling language. The concepts
de?¬?ne what information models in this language can store from the domain. The
interrelations specify howthe information is interlinked, for example, via relationships
between objects or an object being described in more detail in a lower-level diagram.
Start by de?¬?ning the concepts. Try to identify the main things that form part of each
product or feature in the domain. Add the clearest and most central properties for each
concept: what information needs to be stored each time that concept occurs.
Pages:
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642