We can learn several lessons from the less successful parts of the case.With regards
to the ?¬?rst, abortive, day of the workshop, there is always a danger when trying to build
a modeling language that we invent something that is really more of a model, or
simply allows us to draw architectural diagrams. A good rule of thumb to apply is
whether we can realistically generate code from the models made with this language
(assuming code generation is desired). Another test is how many models of this kind
would we be likely to build. If the answer is ???one diagram per product???, the language
does not go deep enough.
Second, even if people talk about the choice of example domain not being
important, it still has a large effect on how the overall feasibility of DSM is
perceived. Seeing DSM work in one domain holds little credibility, if that is not a
domain the customer intends to use it for. People are naturally afraid that the actual
domain they want will turn out to be more complicated than the example shown.
Looking at examples from other companies helps little: for instance, Domatic
were familiar with Nokia??™s use of DSM, but dismissed cell phone development
as not being true embedded development??”far too simple. The truth of the matter
is that most development, when looked at from 10,000 feet, is simple: the
complexity is often in the languages, frameworks, and tools we use.
Pages:
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302