This user interface will be highly reliant on the tool support
facilities provided by the DSM framework or environment you use. We will look at
this in more detail in the next chapter, but for now the main issue is that if there are
things you can improve in the UI, now is the time to do that.
Next you should look to the other visible parts of the DSM solution. Check that
the generated code and domain framework follow in-house standards for coding
style, formatting, and so on. Although developers should not have to look at these,
they will certainly be turning a sharp eye on them at this stage as they form their
opinions about the DSM solution. The other side of the coin is process automation:
making an autobuild script or generator so that developers can go straight from models
to running the ?¬?nished product, without having to look at the code or run commands
on it.
If the preceding topics were about making things aesthetically pleasing and
making visible ???seams??? in the process invisible, we now want to consider making
things visible that are currently hard to see or invisible. For instance, there will be
model structures that are not acceptable to the generator, but which the modeling
language allows you to create. During earlier stages, we have advised you against
adding too many rules to the modeling language.
Pages:
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660