La nota es breve, pero abre dos o tres líneas de discusión. No tengo tiempo ahora pero algo más conversaremos. Sin embargo, persiste la idea de comparar y contraponer lenguajes específicos de dominio con UML, que está a un nivel de abstraccción distinto y superior. Si el caso hubiera sido al revés, con DSLs como única herramienta, seguramente hubiéramos visto la aparición de un UML como un alivo capaz de integrar un conjunto inmanejable de dominios específicos. Quisiera destacar del comentario de Sadek, su resumen de los requisitos explicados por Kelly y Tolvanen para un lenguaje de modelado:
El problema es cómo definir el alcance del modelo. La definición de Kelly/Tolvanen asocia estrechamente un dominio específico con el código generable. Esto atomiza el problema.1) It should map to the domain problem concepts and not implementation details.
2) It has to be formalized and helpful not only for communicating with domain experts but also for development tasks by making it possible to generate from the models executable code, documentation and certain classes of tests, as well as by eliminating the need for implementing some other tests and by raising the level of abstraction for code maintainers.
3) It needs to have stand alone tooling support that would allow domain experts to “organize their frameworks and libraries in such a way that the models can be “compiled” into fully functioning code”, and this without them having to think in terms of code. To illustrate this idea, Lispy uses the analogy of compiling C to machine code, where C is in some way "a modeling language for machine code" and where C programmers don't have to modify the machine code compiled using compilers created by machine language experts.
Persistir en una visión más abstracta, sea a través de UML u otra representación, permite expresar modelos de mayor alcance que un teléfono u otro aparato. Lo que puede ser más que adecuado para sistemas embebidos, no es aplicable para grandes sistemas.
No hay comentarios.:
Publicar un comentario