You can test our claim by trying to
applyUMLto automate the development of any of the ?¬?ve examples presented in Part
III. We should keep in mind, however, that UML was originally set up not
for automating development but for agreement on modeling concepts, their naming,
and symbols. The emphasis of the language was on ???specifying, visualizing, and
documenting the artifacts??? (Booch and Rumbaugh, 1995, page 1) rather than on
supporting developers in making the design decisions or automating development
with generators. Within a narrow domain, DSM aims to do all these.
The central concepts of UML originate from the code world: classes, methods,
attributes. Each company that uses UML also has its own domain: its own set of
DIFFERENCE FROM OTHER MODELING APPROACHES 55
concepts that make up the products it produces. Furthermore, even two companies
making similar products will each have their own kind of code. UML tries to offer a
???one size ?¬?ts all??? set of concepts and generators, making it a ???jack of all trades but
master of none.??? From most UML models, virtually no code can be produced, and
even if the full set of UML models is made, only a small fraction of the total code can
be generated. Test and see by trying to implement generators from the models
described in Chapter 1.
Ifweturn fromcode generation to inspect thewider development process, the lack of
support available from a general-purpose language is evident.
Pages:
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125