For example, UML (as a standard de?¬?ned by OMG) does not contain
knowledge of particular problem domain, or component library. Modelers can
therefore connect UML elements together regardless of the domain rules. The same
applies to many other general-purpose modeling languages such as IDEF, Merise,
SSADM, and SysML. A second part of the expert developer??™s skill is in turning those
precise de?¬?nitions into good code that works on top of their target environment. By
specifying that skill into a code generator, the expert developer makes it possible for
full code to be generated directly from models.
Because the investment of building a DSM solution is often made by only one or
two expert developers at any one company, it pays off quickly as all the other
developers can then model in the new language and use the generators to create full
code. For building automation, tools play a crucial role; otherwise speci?¬?cations that
can be used as a source for generating code would not be possible. Tools for DSM
allow experienced developers to specify the automation in a cost-effective manner:
ideally the experienced developer can focus on just de?¬?ning a language that maps
closely to the problem domain and a generator or that produces the implementation;
the DSM tool should provide the rest.
62 DSM DEFINED
CHAPTER 4
ARCHITECTURE OF DSM
In this chapter, we introduce the key elements of a Domain-Speci?¬?c Modeling (DSM)
solution: languages, models, generators, and a domain framework.
Pages:
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139