[Artesania del software] UML y el diseño emergente
26 views
Skip to first unread message
José Manuel Beas
Nov 4, 2009, 1:11:52 PM11/4/09
to agile...@googlegroups.com
Je, je... cómo mola que deis pie a hilos nuevos. :-)
Seguramente a Carlos no le gusta UML porque ha tenido experiencias desagradables. :-)
Yo veo UML como una herramienta de modelado más. Reconozco que he sido (y sigo siendo) un gran BDUFfer y que en general abuso del diseño en vez de sentarme a programar y dejar que el diseño emerja por sí solo.
He vivido, seguramente igual que Carlos e igual que otros muchos, demasiada "documentación exhaustiva sobre software que funciona" y por eso también tengo un leve prejuicio contra UML, pero después de leer "The Object Primer, 3rd ed" (Scott Ambler) me di cuenta de que UML puede ser una herramienta muy potente para hablar con tu equipo. Ahorra muchas palabras. Más o menos igual que los patrones de diseño.
Ahora bien, hay que tener cuidado porque es muy fácil "herramientas y procesos sobre personas e interacciones" y, una vez que está dibujado el diagrama de clases en la herramienta de turno, no sé qué pasa que parece que es inamovible. Es más, es como si alguna pulsión nerviosa nos empujase a generar código automáticamente desde ese diagrama y generar no sé qué tablas (sí, tablas de base de datos). Demonios, hay que tener mucho cuidado con estas cosas porque es como poner una sierra de calar en manos de un carpintero novato. :-D
En resumen. Para mi: "UML mola... en la pizarra". :-)
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.blogspot.com
Seguramente a Carlos no le gusta UML porque ha tenido experiencias desagradables. :-)
Yo veo UML como una herramienta de modelado más. Reconozco que he sido (y sigo siendo) un gran BDUFfer y que en general abuso del diseño en vez de sentarme a programar y dejar que el diseño emerja por sí solo.
He vivido, seguramente igual que Carlos e igual que otros muchos, demasiada "documentación exhaustiva sobre software que funciona" y por eso también tengo un leve prejuicio contra UML, pero después de leer "The Object Primer, 3rd ed" (Scott Ambler) me di cuenta de que UML puede ser una herramienta muy potente para hablar con tu equipo. Ahorra muchas palabras. Más o menos igual que los patrones de diseño.
Ahora bien, hay que tener cuidado porque es muy fácil "herramientas y procesos sobre personas e interacciones" y, una vez que está dibujado el diagrama de clases en la herramienta de turno, no sé qué pasa que parece que es inamovible. Es más, es como si alguna pulsión nerviosa nos empujase a generar código automáticamente desde ese diagrama y generar no sé qué tablas (sí, tablas de base de datos). Demonios, hay que tener mucho cuidado con estas cosas porque es como poner una sierra de calar en manos de un carpintero novato. :-D
En resumen. Para mi: "UML mola... en la pizarra". :-)
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.blogspot.com
2009/11/4 Harald Messemer <harr...@gmail.com>
2009/11/4 Carlos Ble <ble.j...@gmail.com>
Eso de UML me pone los pelos de punta :-(
Cada día me gusta mas Robert C. Martin. Para mí el código bonito es el
código que sigue los principios S.O.L.I.D
Poco más que agregar a lo que ya se ha dicho en la lista y se haya
escrito en Clean Code :-)
On 4 nov, 09:26, Harald Messemer <harrin...@gmail.com> wrote:
> Para aportar algo de fundamento teórico, recomiendo este libro "http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Orien...
Disculpa la confusión, pero la recomendación del libro se debe a su aportación en lo que corresponde a métricas de arquitectura. No se trataba de introducir UML en el debate, ya por que UML no lo tenía clasificado como herramienta para producir código, sino más bien como soporte para realizar diseños (salvo en Model-Driven-Development donde UML tiene otro protagonismo).
Mirando un poco lo que significaba SOLID he encontrado en la web de Object Mentor (allí donde trabaja Robert Martin) el siguiente curso: http://www.objectmentor.com/omTraining/dialogs/outline_ood_uml_4.html donde se da un repaso general, incluyendo SOLID y UML. No sé que opinión promueven en este curso, pero me llamó la atención y no creo que dedican un día para machacarlo :-)
Alfredo Casado
Nov 4, 2009, 1:50:28 PM11/4/09
to agile...@googlegroups.com
Que te temas tesnicos ultimamente :P, mola.
El problema de UML es que se le asocia con RUP y procesos pesados, pero por si solo es un lenguaje que no tiene nada de malo, yo le veo dos usos:
- Para discutir sobre un diseño, aunque el diseño haya surgido de forma emergente, si lo quieres compartir con otros y discutirlo UML es una buena herramienta para dibujarlo (en una pizarra o donde quieras).
- Para dejar documentado el diseño del sistema. Tener un diagrama de paquetes, un diagrama de clases, y algunos diagramas de secuencia para explicar partes complejas del sistema puede ayudar a nuevos miembros del equipo a entender algunas cosas. Pero eso si, este UML lo haces DESPUES de escribir el código.
UML tiene una cosa muy buena, te permite ver en un vistazo cosas que recorriendo el código puedes tardar un ratito en descubrir, para tener un primer vistazo del sistema es una herramienta buena.
El problema de UML es que se le asocia con RUP y procesos pesados, pero por si solo es un lenguaje que no tiene nada de malo, yo le veo dos usos:
- Para discutir sobre un diseño, aunque el diseño haya surgido de forma emergente, si lo quieres compartir con otros y discutirlo UML es una buena herramienta para dibujarlo (en una pizarra o donde quieras).
- Para dejar documentado el diseño del sistema. Tener un diagrama de paquetes, un diagrama de clases, y algunos diagramas de secuencia para explicar partes complejas del sistema puede ayudar a nuevos miembros del equipo a entender algunas cosas. Pero eso si, este UML lo haces DESPUES de escribir el código.
UML tiene una cosa muy buena, te permite ver en un vistazo cosas que recorriendo el código puedes tardar un ratito en descubrir, para tener un primer vistazo del sistema es una herramienta buena.
Harald Messemer
Nov 4, 2009, 1:57:44 PM11/4/09
to agile...@googlegroups.com
:-) el clasico debe ser el documento de "analisis funcional" de 300
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
Harald Messemer
Nov 4, 2009, 2:04:07 PM11/4/09
to agile...@googlegroups.com
:-) el clasico debe ser el documento de "analisis funcional" de 300
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
Harald Messemer
Nov 4, 2009, 2:12:15 PM11/4/09
to agile...@googlegroups.com
:-) el clasico debe ser el documento de "analisis funcional" de 300
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
Harald Messemer
Nov 4, 2009, 2:18:15 PM11/4/09
to agile...@googlegroups.com
:-) el clasico debe ser el documento de "analisis funcional" de 300
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
paginas de las cuales 200 hablan de los use-cases crud para gestionar
los datos maestros. Todos lo imprimen, se destruye medio bosque y para
todos es un conazo sin aportacion ninguna.
Por mi parte utilzo UML como herramienta de comunicacion para aclarar
ideas, compartir las con el equipo, incluso con el cliente. En
concreto (y en este orden) diagrama de clases, diagrama de estado,
diagrama de deployment, diagrama event-trace.
En mi opinion los diagramas use-case no tienen gran aportacion, aunque
los use-cases, si los hacemos como descrito en el libro "writing
effective use-cases" de A. Cockburn.
He experimentado con herramientas roundtrip, pero si la parte reverse
(del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
desde entonces no he seguido mucho la evolucion en este tema. Sospecho
que ha avanzado bastante gracias a MDA, aunque creo que necesitas
proyectos grandes para sacar provecho o proyectos siempre con la misma
tecnologia..
En la vida practica mi herramienta uml preferido es pizzara o papel o
visio o powerpoint. Vamos, es de comunicacion del diseno y la
codificacion va a parte.
Un saludo,
Harald
2009/11/4, José Manuel Beas <jose....@gmail.com>:
German DZ
Nov 4, 2009, 2:28:41 PM11/4/09
to agile...@googlegroups.com
UML es un lenguaje! solo eso, pero es importantísimo. Poder comunicar cosas (sobre todo modelo de dominio) de forma unívoca es más que importante.
2009/11/4 Harald Messemer <harr...@gmail.com>
José Manuel Beas
Nov 4, 2009, 2:30:37 PM11/4/09
to agile...@googlegroups.com
Pero como todo lenguaje, debe ser comprendido por todas las partes. La triste realidad es que no se usa ni el 50% de la expresividad que permite UML. ¿Pero a quién le importa? A mi no. :-)
2009/11/4 German DZ <ge...@ndz.com.ar>
Carlos Ble
Nov 4, 2009, 2:45:10 PM11/4/09
to agile-spain
UML no es unívoco. Que yo sepa no hay validadores de UML, no lo
interpreta una máquina. Es ambiguo.
Bueno, en el caso de MDA igual sí pero creo que no es UML sino un UML
particular de ellos.
De todas formas coincido con vosotros, está genial para ojear
diagramas a vista de pajaro.
Creo que coincidimos. Mejor no darle ya muchas mas vueltas, no?
On 4 nov, 19:28, German DZ <g...@ndz.com.ar> wrote:
> UML es un lenguaje! solo eso, pero es importantísimo. Poder comunicar cosas
> (sobre todo modelo de dominio) de forma unívoca es más que importante.
>
> 2009/11/4 Harald Messemer <harrin...@gmail.com>
> > > 2009/11/4 Harald Messemer <harrin...@gmail.com>
>
> > >> 2009/11/4 Carlos Ble <ble.jur...@gmail.com>
interpreta una máquina. Es ambiguo.
Bueno, en el caso de MDA igual sí pero creo que no es UML sino un UML
particular de ellos.
De todas formas coincido con vosotros, está genial para ojear
diagramas a vista de pajaro.
Creo que coincidimos. Mejor no darle ya muchas mas vueltas, no?
On 4 nov, 19:28, German DZ <g...@ndz.com.ar> wrote:
> UML es un lenguaje! solo eso, pero es importantísimo. Poder comunicar cosas
> (sobre todo modelo de dominio) de forma unívoca es más que importante.
>
>
>
>
>
>
> > :-) el clasico debe ser el documento de "analisis funcional" de 300
> > paginas de las cuales 200 hablan de los use-cases crud para gestionar
> > los datos maestros. Todos lo imprimen, se destruye medio bosque y para
> > todos es un conazo sin aportacion ninguna.
>
> > Por mi parte utilzo UML como herramienta de comunicacion para aclarar
> > ideas, compartir las con el equipo, incluso con el cliente. En
> > concreto (y en este orden) diagrama de clases, diagrama de estado,
> > diagrama de deployment, diagrama event-trace.
>
> > En mi opinion los diagramas use-case no tienen gran aportacion, aunque
> > los use-cases, si los hacemos como descrito en el libro "writing
> > effective use-cases" de A. Cockburn.
>
> > He experimentado con herramientas roundtrip, pero si la parte reverse
> > (del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
> > desde entonces no he seguido mucho la evolucion en este tema. Sospecho
> > que ha avanzado bastante gracias a MDA, aunque creo que necesitas
> > proyectos grandes para sacar provecho o proyectos siempre con la misma
> > tecnologia..
>
> > En la vida practica mi herramienta uml preferido es pizzara o papel o
> > visio o powerpoint. Vamos, es de comunicacion del diseno y la
> > codificacion va a parte.
>
> > Un saludo,
> > Harald
>
> > 2009/11/4, José Manuel Beas <jose.m.b...@gmail.com>:
>
>
>
>
> > :-) el clasico debe ser el documento de "analisis funcional" de 300
> > paginas de las cuales 200 hablan de los use-cases crud para gestionar
> > los datos maestros. Todos lo imprimen, se destruye medio bosque y para
> > todos es un conazo sin aportacion ninguna.
>
> > Por mi parte utilzo UML como herramienta de comunicacion para aclarar
> > ideas, compartir las con el equipo, incluso con el cliente. En
> > concreto (y en este orden) diagrama de clases, diagrama de estado,
> > diagrama de deployment, diagrama event-trace.
>
> > En mi opinion los diagramas use-case no tienen gran aportacion, aunque
> > los use-cases, si los hacemos como descrito en el libro "writing
> > effective use-cases" de A. Cockburn.
>
> > He experimentado con herramientas roundtrip, pero si la parte reverse
> > (del codigo a uml) no tira no vale la pena. Pero esto fue en el 2002 y
> > desde entonces no he seguido mucho la evolucion en este tema. Sospecho
> > que ha avanzado bastante gracias a MDA, aunque creo que necesitas
> > proyectos grandes para sacar provecho o proyectos siempre con la misma
> > tecnologia..
>
> > En la vida practica mi herramienta uml preferido es pizzara o papel o
> > visio o powerpoint. Vamos, es de comunicacion del diseno y la
> > codificacion va a parte.
>
> > Un saludo,
> > Harald
>
>
> > >> 2009/11/4 Carlos Ble <ble.jur...@gmail.com>
>
> > >>> Eso de UML me pone los pelos de punta :-(
> > >>> Cada día me gusta mas Robert C. Martin. Para mí el código bonito es el
> > >>> código que sigue los principios S.O.L.I.D
> > >>> Poco más que agregar a lo que ya se ha dicho en la lista y se haya
> > >>> escrito en Clean Code :-)
>
> > >>> On 4 nov, 09:26, Harald Messemer <harrin...@gmail.com> wrote:
> > >>> > Para aportar algo de fundamento teórico, recomiendo este libro "
> > >>>http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Orien.
> > ..
>
> > >> Disculpa la confusión, pero la recomendación del libro se debe a su
> > >> aportación en lo que corresponde a métricas de arquitectura. No se
> > trataba
> > >> de introducir UML en el debate, ya por que UML no lo tenía clasificado
> > >> como
> > >> herramienta para producir código, sino más bien como soporte para
> > realizar
> > >> diseños (salvo en Model-Driven-Development donde UML tiene otro
> > >> protagonismo).
>
> > >> Mirando un poco lo que significaba SOLID he encontrado en la web de
> > Object
> > >> Mentor (allí donde trabaja Robert Martin) el siguiente curso:
>
> >http://www.objectmentor.com/omTraining/dialogs/outline_ood_uml_4.html...
> > >>> Eso de UML me pone los pelos de punta :-(
> > >>> Cada día me gusta mas Robert C. Martin. Para mí el código bonito es el
> > >>> código que sigue los principios S.O.L.I.D
> > >>> Poco más que agregar a lo que ya se ha dicho en la lista y se haya
> > >>> escrito en Clean Code :-)
>
> > >>> On 4 nov, 09:26, Harald Messemer <harrin...@gmail.com> wrote:
> > >>> > Para aportar algo de fundamento teórico, recomiendo este libro "
> > >>>http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Orien.
> > ..
>
> > >> Disculpa la confusión, pero la recomendación del libro se debe a su
> > >> aportación en lo que corresponde a métricas de arquitectura. No se
> > trataba
> > >> de introducir UML en el debate, ya por que UML no lo tenía clasificado
> > >> como
> > >> herramienta para producir código, sino más bien como soporte para
> > realizar
> > >> diseños (salvo en Model-Driven-Development donde UML tiene otro
> > >> protagonismo).
>
> > >> Mirando un poco lo que significaba SOLID he encontrado en la web de
> > Object
> > >> Mentor (allí donde trabaja Robert Martin) el siguiente curso:
>
Harald Messemer
Nov 4, 2009, 3:37:53 PM11/4/09
to agile...@googlegroups.com
Tambien coincido que lo relevante sobre UML 1 como herramienta de
comunicacion y soporte al diseno funcional y tecnico se ha dicho.
Igualmente veo cierta necesidad de profundizar algo en lo que pretende
lograr la OMG con la MDA.
El super-resumen de la iniciativa MDA es que se genera con UML un
domain specific model (vamos un modelo en lenguaje del usuario). Este
modelo se convierte a traves de generadores de codigo en un platform
specific model (pe java con spring y liferay, en consecuencia, en una
aplicacion concreta.
Para que esto funcione la UML debe permitir la descripcion del estado
y del comportamiento (!!!) del modelo con suficiente nivel de detalle
para poder generar codigo ejecutable. Alli entra en juego la
domain-specific-language, el gran avance en UML 2, una especie de
pseudo-codigo que completa el conjunto de elementos de UML.
Por otro lado, se requiere de unos validadores de UML o, siendo algo
mas tecnico, un parseador de los modelos UML para tener un formato
input que un generador de codigo es capaz de interpretar de forma
eficaz.
A nivel de productos MDA el lider debe ser IBM que con Rational Rose
y Telelogic ha comprado dos empresas que mas tecnologia habian
desarrollado en este contexto. Despues hay productos de empresas mas
pequenas, sea libre o de pago como AndroMDA. Vamos, aun no se sabe
quien se va llevar el bacalao (=oportunidad de negocio).
La MDA va dirigido mas bien a empresas grandes con necesidad enorme de
produccion de software o incluso familias de productos software, como
empresas de telecomunicacion y automocion. De hecho los que empujan
son empresas como BMW y Ericsson.
Vamos, este es el autentico movimiento hacia una produccion industrial
de software, donde no hay programacion artesanal, sino generacion de
codigo (ojo: alguien tiene que programar los generadores y los
frameworks).
Espero que haya reproducido mas o menos lo que comprendo como MDA / UML.
Un saludo,
Harald
2009/11/4, Carlos Ble <ble.j...@gmail.com>:
comunicacion y soporte al diseno funcional y tecnico se ha dicho.
Igualmente veo cierta necesidad de profundizar algo en lo que pretende
lograr la OMG con la MDA.
El super-resumen de la iniciativa MDA es que se genera con UML un
domain specific model (vamos un modelo en lenguaje del usuario). Este
modelo se convierte a traves de generadores de codigo en un platform
specific model (pe java con spring y liferay, en consecuencia, en una
aplicacion concreta.
Para que esto funcione la UML debe permitir la descripcion del estado
y del comportamiento (!!!) del modelo con suficiente nivel de detalle
para poder generar codigo ejecutable. Alli entra en juego la
domain-specific-language, el gran avance en UML 2, una especie de
pseudo-codigo que completa el conjunto de elementos de UML.
Por otro lado, se requiere de unos validadores de UML o, siendo algo
mas tecnico, un parseador de los modelos UML para tener un formato
input que un generador de codigo es capaz de interpretar de forma
eficaz.
A nivel de productos MDA el lider debe ser IBM que con Rational Rose
y Telelogic ha comprado dos empresas que mas tecnologia habian
desarrollado en este contexto. Despues hay productos de empresas mas
pequenas, sea libre o de pago como AndroMDA. Vamos, aun no se sabe
quien se va llevar el bacalao (=oportunidad de negocio).
La MDA va dirigido mas bien a empresas grandes con necesidad enorme de
produccion de software o incluso familias de productos software, como
empresas de telecomunicacion y automocion. De hecho los que empujan
son empresas como BMW y Ericsson.
Vamos, este es el autentico movimiento hacia una produccion industrial
de software, donde no hay programacion artesanal, sino generacion de
codigo (ojo: alguien tiene que programar los generadores y los
frameworks).
Espero que haya reproducido mas o menos lo que comprendo como MDA / UML.
Un saludo,
Harald
2009/11/4, Carlos Ble <ble.j...@gmail.com>:
Carlos Ble
Nov 5, 2009, 3:05:08 PM11/5/09
to agile-spain
Ojala que avancen mucho con MDA y esos supergeneradores, asi nos
jubilamos antes :-)
Gran resumen en mi opinion, coincide con lo que tengo entendido.
Thanks
> 2009/11/4, Carlos Ble <ble.jur...@gmail.com>:
jubilamos antes :-)
Gran resumen en mi opinion, coincide con lo que tengo entendido.
Thanks
Juan Carlos Quijano Abad
Nov 6, 2009, 1:55:26 AM11/6/09
to agile...@googlegroups.com
Buenos días.
Los supergeneradores no es CASE II "el retorno"? :)
--
Un saludo
Juan Quijano
Los supergeneradores no es CASE II "el retorno"? :)
--
Un saludo
Juan Quijano
Harald Messemer
Nov 6, 2009, 3:58:03 AM11/6/09
to agile...@googlegroups.com
Con CASE 2 te refieres al Computee Aided Software Engineering??
Diria que UML es el sucesor de todo lo relativo a CASE, aunque hace
tiempo no he oido nadie hablar en estos terminos.
En la Universidad me ensenaban SA (Structured Analysis) y SADT
(Structured Analysis Design Technique), pero despues no encontre a
nadie que lo utilizaba.
Esto fue en el 1997 y ya estaba desfasado porque lo que se empezaba
utilizar era OMT (Rumbaugh) y OOSE (Jacobson) y Booch (Booch:)) hasta
que se pusieron las pilas y estandarizon las ideas en UML con la OMG.
Lo demas ya se sabe: Heavy Metal con RUP, pero con iteraciones e
incremental, XP, SCRUM y Agile Manifest.
Vamos, la idea detras de todo esto siempre era la generacion de codigo
a traves de una descripcion mas ligera que escribir codigo para
agilizar el time-2-market.
La MDA es el ultimo intento, como ya dicho antes interesante para los
que necesitan miles de funcionalidades en muy poco tiempo.
Igualmente quisiera creer que la evolucion de OO, de OODT, de
desarrollo basado en componentes, opensource, software libre y
metodologias agiles, tienen una aportacion mas importante al aumento
de productividad que se siempres se busca.
Un saludo,
Harald
Pd: hay un libro muy bueno sobre gestion de proyectos que se llama
"death march projects" del 2000 aprox. de un tal Ed Yourdon, que era
uno de los padres CASE. Vamos, estos tipos ya sabian de que hablaban.
2009/11/6, Juan Carlos Quijano Abad <juancarl...@gmail.com>:
Diria que UML es el sucesor de todo lo relativo a CASE, aunque hace
tiempo no he oido nadie hablar en estos terminos.
En la Universidad me ensenaban SA (Structured Analysis) y SADT
(Structured Analysis Design Technique), pero despues no encontre a
nadie que lo utilizaba.
Esto fue en el 1997 y ya estaba desfasado porque lo que se empezaba
utilizar era OMT (Rumbaugh) y OOSE (Jacobson) y Booch (Booch:)) hasta
que se pusieron las pilas y estandarizon las ideas en UML con la OMG.
Lo demas ya se sabe: Heavy Metal con RUP, pero con iteraciones e
incremental, XP, SCRUM y Agile Manifest.
Vamos, la idea detras de todo esto siempre era la generacion de codigo
a traves de una descripcion mas ligera que escribir codigo para
agilizar el time-2-market.
La MDA es el ultimo intento, como ya dicho antes interesante para los
que necesitan miles de funcionalidades en muy poco tiempo.
Igualmente quisiera creer que la evolucion de OO, de OODT, de
desarrollo basado en componentes, opensource, software libre y
metodologias agiles, tienen una aportacion mas importante al aumento
de productividad que se siempres se busca.
Un saludo,
Harald
Pd: hay un libro muy bueno sobre gestion de proyectos que se llama
"death march projects" del 2000 aprox. de un tal Ed Yourdon, que era
uno de los padres CASE. Vamos, estos tipos ya sabian de que hablaban.
2009/11/6, Juan Carlos Quijano Abad <juancarl...@gmail.com>:
Juan Carlos Quijano Abad
Nov 6, 2009, 4:10:10 AM11/6/09
to agile...@googlegroups.com
Buenasss.
Joe, que buena memoria tienes!! Efectívamente, uno que ya tiene sus añitos le suena muy familiar lo de los autogeneradores de código que iban a mandar al paro a los picadores de código... de eso hace ya casi 20 años.
--
Un saludo
Juan Quijano
Joe, que buena memoria tienes!! Efectívamente, uno que ya tiene sus añitos le suena muy familiar lo de los autogeneradores de código que iban a mandar al paro a los picadores de código... de eso hace ya casi 20 años.
--
Un saludo
Juan Quijano
Jorge Jimenez
Nov 6, 2009, 4:18:29 AM11/6/09
to agile...@googlegroups.com
Madre mías...también qué mayor soy.
Al hilo de lo que has comentado Juan Carlos, yo recuerdo hacia finales de los 90 una conferencia en la Universidad de Valladolid sobre un proyecto que se estaba haciendo en la de Valencia para la autogeneración de código...joder, según lo contaban parecía que iban a desaparecer los desarrolladores, que con unos ficheritos en XML y dándole a un botón ya tendríamos aplicaciones terminadas, jejejeje, no sé cómo acabaría aquello...es como ver películas en blanco y negro ;-)
Un saludo
Jorge Jiménez
http://azucarenlasvenas.blogspot.com
Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day."
Al hilo de lo que has comentado Juan Carlos, yo recuerdo hacia finales de los 90 una conferencia en la Universidad de Valladolid sobre un proyecto que se estaba haciendo en la de Valencia para la autogeneración de código...joder, según lo contaban parecía que iban a desaparecer los desarrolladores, que con unos ficheritos en XML y dándole a un botón ya tendríamos aplicaciones terminadas, jejejeje, no sé cómo acabaría aquello...es como ver películas en blanco y negro ;-)
Un saludo
Jorge Jiménez
http://azucarenlasvenas.blogspot.com
Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day."
2009/11/6 Juan Carlos Quijano Abad <juancarl...@gmail.com>
Abel Muiño
Nov 6, 2009, 4:26:10 AM11/6/09
to agile...@googlegroups.com
Puede que se haya reencarnado en esto:
http://www.moskitt.org/cas/moskitt0/
Coincidí con los desarrolladores el año pasado en la Eclipse Summit Europe y creo que iban por el camino de MDD y UML ejecutable (aunque mi entendimiento es bastante difuso...)
--
Abel Muiño - http://ramblingabout.wordpress.com/
http://www.moskitt.org/cas/moskitt0/
Coincidí con los desarrolladores el año pasado en la Eclipse Summit Europe y creo que iban por el camino de MDD y UML ejecutable (aunque mi entendimiento es bastante difuso...)
2009/11/6 Jorge Jimenez <sem...@gmail.com>
--
Abel Muiño - http://ramblingabout.wordpress.com/
José Manuel Beas
Nov 6, 2009, 4:28:56 AM11/6/09
to agile...@googlegroups.com
2009/11/6 Harald Messemer <harr...@gmail.com>
Justamente estaba leyendo ayer "Extreme Programming Installed" de Ron Jeffries et al y comentan sobre este libro (traducción libre):
"El libro más deprimente que Chet [se refiere a Chet Hendrikson, a la sazón el marido de @testobsessed], y eso que él era un especialista en economía [1]. Yourdon casi parece que aprueba la marcha e intentar ayudar a la gente a sacar lo mejor de ello. XP va de evitar esta marcha mortal. Vosotros deberíais preferir esto también."
[1] "economics major" ver http://www2.csusm.edu/rarnold/economics_major.htm
Un saludo,
JMB
Pd: hay un libro muy bueno sobre gestion de proyectos que se llama
"death march projects" del 2000 aprox. de un tal Ed Yourdon, que era
uno de los padres CASE. Vamos, estos tipos ya sabian de que hablaban.
Justamente estaba leyendo ayer "Extreme Programming Installed" de Ron Jeffries et al y comentan sobre este libro (traducción libre):
"El libro más deprimente que Chet [se refiere a Chet Hendrikson, a la sazón el marido de @testobsessed], y eso que él era un especialista en economía [1]. Yourdon casi parece que aprueba la marcha e intentar ayudar a la gente a sacar lo mejor de ello. XP va de evitar esta marcha mortal. Vosotros deberíais preferir esto también."
[1] "economics major" ver http://www2.csusm.edu/rarnold/economics_major.htm
Un saludo,
JMB
José Manuel Beas
Nov 6, 2009, 4:31:01 AM11/6/09
to agile...@googlegroups.com
Je, je, y yo recuerdo que tuve mis más y mis menos con un profesor (ahora catedrático y director de departamento) que decía que especificando en Z los algoritmos se derivarían automáticamente y los programadores dejaríamos de programar para dedicarnos a especificar precondiciones y postcondiciones. En fin, la vida es así...
2009/11/6 Jorge Jimenez <sem...@gmail.com>
Harald Messemer
Nov 6, 2009, 4:40:12 AM11/6/09
to agile...@googlegroups.com
Pero que conste que no se ha logrado, ni creo que se va lograr.
Aunque si creo que el tipo de solucion / aplicacion que se programa va
variar hacia la creacion de herramientas y componentes, mientras que
las soluciones de cliente final, tendran cada vez menos parte de
programacion artesanal versus ensamblaje de componentes.
A partir de alli, saco dos conclusiones:
-hay que programar herramientas y componentes (alli esta la
programacion artesanal)
-hay fomentar el papel del arquitecto y del jefe de obra (los clientes
finales necesitan expertos para asegurar la calidad)
Evidentemente se trata solamente de una opinion y, tal vez, tendria
sentido abrir debates nuevos para hablar de estos temas: "que se
programa en el 2020" y "que tipo de soluciones piden nuestros clientes
en el 2020".
Un saludo,
Harald
Pd: creo que estamos bastante off-topic :-))
Aunque si creo que el tipo de solucion / aplicacion que se programa va
variar hacia la creacion de herramientas y componentes, mientras que
las soluciones de cliente final, tendran cada vez menos parte de
programacion artesanal versus ensamblaje de componentes.
A partir de alli, saco dos conclusiones:
-hay que programar herramientas y componentes (alli esta la
programacion artesanal)
-hay fomentar el papel del arquitecto y del jefe de obra (los clientes
finales necesitan expertos para asegurar la calidad)
Evidentemente se trata solamente de una opinion y, tal vez, tendria
sentido abrir debates nuevos para hablar de estos temas: "que se
programa en el 2020" y "que tipo de soluciones piden nuestros clientes
en el 2020".
Un saludo,
Harald
Pd: creo que estamos bastante off-topic :-))
Reply all
Reply to author
Forward
0 new messages