Documentando software y… más motivos por los que UML no es la solución

En mi opinión, el código es la única fuente de verdad sobre un proyecto de software a nivel de detalle. Entendidendo como código, la documentación directamente asociada al mismo o embebida en él (comentarios que permitan generar documentación por ejemplo, con NDoc o JDoc) o aquella que se genera de manera automática desde el mismo (por ejemplo diagramas de clases que solo son otra vista del código). Vaste recordar lo que todos hemos hecho para comprender un sistema del que disponíamos de su código fuente y que debíamos mantener o extender, leer el código, aunque exista documentación. Los desarrolladores preferimos leer código por que no es ambiguo. Si no en segundo caso, descripciones textuales, en ningún caso UML. La unica excepción se produce cuando contamos con información directamente generada desde el código en formato textual y descriptivo.

Otra documentación que no emana del código fuente directamente y que es de gran utilidad, si no imprescindible, es la relativa a arquitectura. Es necesario que un nuevo desarrollador o aquel que resucita el proyecto tras un tiempo pueda comprender que decisiones de alto nivel guiaron el desarrollo. Esta documentación si que es valiosa puesto que sirve para comprender por que se tomaron determinadas decisiones que no se cambian con facilidad a lo largo del proyecto y proporciona una primera aproximación que siempre es necesaria. La arquitectura de una aplicación no suele cambiar a menudo, lo que cambia es la implementación, el código. Documentar la arquitectura y que alguien la comprenda es algo que se hace perfectamente en lenguaje textual y utilizando algunos diagramas, no necesitas algo de tanta complejidad como UML. Esta documentación es simple de mantener porque es mucho más estática que la de diseño detallado. Además algo especialmente valioso de la documentación de arquitectura es que establece el lenguaje común, la nomenclatura propia y el estilo que va a guiar del desarrollo.

Pensemos en una pieza de software tan compleja y extensa como el Framework de .Net (lo mismo se aplica en cualquier caso al de J2EE). La única documentación de la que disponemos es la MSDN, que no incluye ni un solo diagrama UML. Sin embargo, pensemos en como actuamos como programadores cuando empezamos a usar un nuevo Framework Lo primero que hacemos es extender el Framework en un sentido genérico (programa algo sobre él) y la principal fuente de información es el nombre de las clases y las funciones, no utilizamos la documentación sino en IntelliSense. La principal documentación con la contamos es el estilo de nomenclatura, la coherencia a la hora de nombrar cosas y una arquitectura general coherente. La principal documentación del software debe emanar de una serie de patrones que se repiten a lo largo del proyecto, tanto a nivel arquitectónico como de diseño y estos patrones donde viven es en el código. Y si tenemos problemas esperamos encontrar articulos y ejemplos, no diagramas UML. Es facil mantener una base de conocimiento sobre nuestro proyecto, basada en articulos cortos y con ejemplos, tipo «knowledge base», de manera que sean facilmente buscables.

Otra cuestión es la captura de requisitos, donde el enfoque de historias sencillas es suficiente. Y documentando el enfoque siempre debe ser: solo lo suficiente y nada más. Aquí el problema de UML es que se queda corto. Los diagramas de casos de uso solo no son suficiente, siempre necesitan una descripción textual asociada. Además en cualquier caso, harto problema es entender los requisitos como para además tener que entender el lenguaje en el que están escritos.

Sin duda el enfoque seguido en Team System es parecido al que describo, y creo que han dado en el clavo.


Por cierto, esta historia empieza aquí.

27 comentarios sobre “Documentando software y… más motivos por los que UML no es la solución”

  1. Amigo Wefw, entiendo que no compartas mi postura, pero no logro ver en tu mensaje los argumentos que manejas. ¿Podrías por favor argumentar tu postura?.

    Porque la conclusión que saco de tu comentario es que no tienes ni puñetera idea de lo que hablas. Y desde luego, si tu documentación es como tus comentarios, esta todo dicho.

  2. He de reconocer que las matizaciones que haces en este segundo post me han dejado bastante satisfecho. Estoy de acuerdo que la documentación a un nivel de abstracción muy bajo sólo sirve si se puede mantener con facilidad, y que la arquitectura y las especificaciones son válidas siempre que se manejen a un nivel de abstracción que permita mantenerlos actualizados. También estoy de acuerdo en que UML sin duda está sobrevalorado, pero sin embargo, sigo pensando que tener un lenguaje común es en general, bueno… y UML, hoy por hoy, es lo mejor que tenemos. Tal vez sería aún mejor si no fuese una herramienta que unos cuantos utilizan para vender más y más libros ;-). De hecho yo daría la vuelta a tu razonamiento y te preguntaría… ¿qué le falta a UML para que Microsoft haya tenido que inventar algo adicional?

    Sin embargo, hay un punto, amigo mío… que no mencionas en tus posts, y es la documentación que se genera durante el «business modelling», y que es puramente conceptual. En esta documentación, en la que básicamente expresas cuales son las clases del negocio y las relaciones que existen entre sí… hay temas de la estructura estática que se DEBEN expresar, y que además son inmutables (por ejemplo, de alguna forma debo «capturar» que en el dominio de la aplicación, un «documento T10» es un tipo de documento financiero, y que todos estos se almacenan en el «perfil» de un «contribuyente»). Cierto es que puedo escribir todo esto, pero lo puedo expresar sin ninguna ambiguedad con un diagrama de clases UML… y además es inmutable. Dices que todos tenemos una capacidad innata de dibujar, pero ya me gustaría a mi ver qué distintos clasificadores aparecen por ahí para referirse a relaciones del estilo «es un tipo de» o «contiene otros elementos» que con UML no me tengo que esforzar en pensar (una vez aprendido, me «salen» los simbilillos de generalización o agregación). El lenguaje gestual es innato, pero sin duda el lenguaje castellano es mucho menos ambiguo y más rico, aunque sea necesario un proceso de aprendizaje.

    Con los casos de uso, sólo puedo decirte que un caso de uso, para mi al menos, es la descripción textual… que va acompañada de un dibujo (y no al revés). De hecho así es como los definió Jacobson. No creo que la diagramación pretenda sustituir a las descripciones textuales. Lo único que puedo achacar a UML es que no defina cómo deben ser estas descripciones. Precisamente para ver la utilidad de UML, sólo tienes que ver la cantidad de opiniones diversas que hay sobre cómo debe escribirse un caso de uso… donde hay un «vacío» de normas hay un «lleno» de discusiones bizantinas sobre cómo se debe homogeneizar la forma de realizar esa labor. Todo el mundo discuto cosas como «cómo numerar los casos de uso», «cómo elegir el escenario principal de un caso CRUD», o «si se debe especificar la condiciíon de activación como un apartado diferente al propio primer paso de un caso de uso». Personalmente pienso que la respuesta a estas preguntas es «DA IGUAL MIENTRAS SE ENTIENDA»… el problema es la cantidad de tiempo que se pierde discutiendo sobre cual es la forma idónea de hacerlo, mientras que cuando algo es estándar y universalmente aceptado, nadie lo discute. No creo que nadie pierda el tiempo discutiendo si la generalización se debe representar con un triangulito o con un cuadradito… ¿no? Pues esa, y sólo esa, es la grandeza del UML.

    Por último me ha parecido entender que opinas que el UML tiende a encorsetarte. Bueno, en este caso sólo puedo decirte que sólo a quien no conoce lo que es el UML le puede llegar a encorsetar: aquel «novato» (con todo el cariño) que tiene que meter una secuencia por narices, porque ha entendido que todo proceso de la aplicación debe estar documentado con una secuencia. Evidentemente quien haga eso pierde el tiempo… porque cuando termine de escribirlo ya estará desfasado (y probablemente tarde siglos en empezar a escribir código, si es que alguna vez empieza). Sin embargo vuelvo al punto de la abstracción: seguro que hay procesos importantes cuya vista dinámica es importante especificar. Podría usarse un diagrama de flujo, o pseudocódigo o lo que sea (de hecho, me parece aceptable cualquiera de las tres opciones). Sin embargo una secuencia (o un diagrama de colaboración, según le guste a cada cual) tiene la ventaja de que se puede especificar con un montón de herramientas CASE (aunque sólo sea porque queda más limpio que el pseudocódigo escrito en una servilleta del «Bar Pepe») y que asegura al menos en gran parte la no ambiguedad de la especificación.

    Por último, esta es una opinión muy personal… pero a mi el UML me parece bastante natural de comprender, y no creo que la curva de aprendizaje sea muy pronunciada. Vamos, a no ser que tengas profesores francamente malos, o te dejes llevar por la cantidad de autores que han decidido enriquecerse escribiendo pomposos libros sobre «el UML» (lo pongo entre comillas porque la verdad es que me da verdadera vergüenza ajena ver la cantidad de cenutrios que aseguran «te van a enseñar a diseñar, porque vas a aprender UML»). Qué descojono, es como si te vendiesen las clases del abecedario del jardin de infancia como un curso de poesía.

  3. Los diagramas UML son tan ambiguos como cualquier otro documento.

    En cuanto al «business modeling», en fin… prefiero unos requisitos descriptivos, en base a personas y escenarios que diagramas UML. ¿Esperas que un operario de una fabrica, fuente de los requisitos, valide unos requisitos expresados en UML? Los requisitos y el modelo de negocio lo deben entender todos los stakeholders, no solo los que conozcon UML.

    En cuanto a la ventaja de la unificación de la notación se pierde por la desventaja de no poder usar terminología o simbología propia del dominio de aplicación. Y las posiblidades de extender UML, que existen no son precisamente claras.

    En cuanto al tiempo discutiendo la notación, no exite, quien recibe un documento es quien juzga si lo puede entender o no. Si alguna persona (persona en el sentido rol) de la audiencia no lo entiene, el documento no vale. Prueba a aplicar esta regla con UML 😉

  4. Business Modeling no es lo mismo que captura de requisitos… trata de definir sin ambiguedad patrones empresariales por medio de literatura escrita, sin que el lector necesite drogas para poder leerlo (y asimilarlo). Cuidado, que no estoy diciendo que TODOS los requisitos deban partir del business modeling… evidentemente las «personas» de Team System (todavía estoy esperando que me cuenten qué aportan sobre los casos de uso) son una herramienta estupenda para especificar. Sin embargo, el business modeling es una excelente forma de documentar las reglas de negocio sobre las que iniciar el análisis de una aplicación. Estan muchísimo antes que la especificación. Por cierto, que el UML no es un campo exclusivo de informáticos… los analistas de negocio usan UML para documentar procesos empresariales (aunque es cierto que hay lenguajes específicos al dominio… pero UML puede ser común a los analistas del negocio y a los desarrolladores de aplicaciones, de ahí su ventaja y su nombre de «universal»).

    En cuanto a las posibilidades de extender el UML, yo las veo bastante claras por medio de los estereotipos (por ejemplo, ver http://www.phptr.com/articles/article.asp?p=29454&rl=1 )

    En cuanto a lo que dices de que «En cuanto al tiempo discutiendo la notación, no exite, quien recibe un documento es quien juzga si lo puede entender o no», es igualmente aplicable a cualquier documento «ad hoc» escrito por cualquiera, y depende, además del lenguaje, del receptor del mensaje. UML será mejor si el receptor es informático, y en ese caso evita discusiones del estilo… «el cuadradito al lado del otro cuadradito, es una clase que hereda?», «¿y qué significa ese bicho que has dibujado con forma de mosca? Coño, no,… que es una mosca». De ahí que digo que es menos ambiguo (evidentemente, nada es TOTALMENTE carente de ambiguedad… nos ha jodio). Si el receptor es «no informático», entonces me temo que muchos de los mensajes no los entenderá, independientemente del lenguaje.

  5. Que gresca se ha montado con esto ¿no? … yo lo veo de una forma más sencilla que todo esto, UML no sirva para documentar un proyecto, solamente sirva para expresar ciertas partes de la documentación.

    Con el paraguas abierto espero las hostias…..

    Unai

  6. yo estoy de acuerdo con Unai, que uml es una parte de la documentacion y como ya exprese en otro post (http://geeks.ms/blogs/csegura/archive/2006/06/20/526.aspx#comments) creo que solo valido para proyectos grandes con donde podemos encontrar diferentes roles..

    hay ciertos debates en los que por regla general siempre se discute sin llegar a un consenso.. por ejemplo las sql en store o en el codigo de la capa de datos o no hacemos 3 capas y hacemos 2 o todo en una .. o no hacemos nada 😀

    PAZ

  7. Bueno, me parece que no haz tenido exito con UML, o que no sabes usarlo, es verdad hay en internet y existen tantos libros impresos que tratan de enseñar UML, pero al final lo que se obtiene es personas mas y cada vez mas confundidas sobre el tema.

    UML es la notación estándar aqui y en la china, y si sabes utilizarlo podrás desarrollar proyectos rápidos y a tiempo.

    Espero que cuando hayas entendido UML, te rectifiques, Saludos…..

  8. Ricardo, no se trata de que yo no haya tenido exito. Se trata de que conozco multitud de proyectos y desarrolladores que no han tendio exito.

    Y cuando mucha gente falla usando una herramienta, metodologío o lenguaje lo que esta fallando es el lenguaje, no quien lo usa.

  9. Como pasa en muchas discusiones todos tienen un poco de razón, pero igualmente en este caso prefiero quedarme con lo que opina Nyeznajomy.
    También creo que es importante usar UML no aisladamente si no como complemento de una metodología de desarrollo como el «Proceso Unificado», despúes que diagrama se usa dependera del tipo de proyecto, aunque de manera casi indiscutible aparecern los diagramas de secuencia y de clases y que una vez que tenemos práctica en su creación nos servirá para crear un código mucho más eficiente y claro porque podemos tener una abstracción de los problemas a resolver y pensar todo el tiempo en «QUE» se debe hacer y no «COMO» hacerlo. El poder representar una solución a un problema gráficamente, no tengo duda que es mucho más beneficioso que querer escribir el código directamente. UML no es tan dificil, lo realmente dificil es aprender el paradigma orientado a objetos pero fundamentalmente las buenas prácticas de programación. Algo que pasa en las Universidades, Institutos etc, es que enseñan UML a alumnos que apenas tienen idea de la programación orientada a objetos. Saber distinguir lo que es una clase, lo que son las propiedades y metodos, no significa saber programar y UML necesita que se sepa del tema y si me enseñan a utilizar una herramienta para representar algo que no entiendo bien, por supuesto la voy a rechazar.
    Vuelvo a repetir lo que decia antes, lo más importante es una buena metodología, yo recomiendo el Proceso Unificado sin importar el tamaño del proyecto.
    Como todo lo más dificil es hacer el primer sistema utilizando dicha metodología y a partir de ahí son todos pros.

  10. UML es muy bonito y puede ser útil, pero no es el descubrimiento del hilo negro de la informática y no es algo que haga que los proyectos sean exitosos, eso es falacia y negocio.

    Es solo una ayuda, una de tantas. Y solo la conjunción de un buen análisis y diseño conceptual,aunado a programadores de excelencia es lo que hace un proyecto exitoso.

    Como gerente de proyectos, valoro mucho más a las buenos codificadores que a los excelentes informáticos UMLeros. He estado al frente de proyectos de decenas de millones de dólares y UML no ha aportado nada diferente a lo que hacíamos antes. Algunos clientes lo requieren, a otros les da igual. Y como siempre, lo importante es que el sistema produzca dinero, que haga lo que el cliente quiere que haga y que sea fácil de mantener/heredar.

    En mi opinión UML es un accesorio más que jamás será imprescindible, como sí lo es un estratega o un puñado de programadores rápidos, eficientes y creativos.

  11. Desde el punto de vista del usuario común que ni idea tiene de que lenguaje se usa, si la aplicacion es de escritorio, web, servicio, etc o si usa BD, para él el UML son dibujos que le sirven a un técnico y necesita un papel con una redacciòn escueta que le describa su problema y la soluciòn o alternativas de soluciòn.

    Por otro lado UML es una herramienta que permite definir «X» elementos y con ello poder automatizar parte del desarrollo de una aplicaciòn. No es toda la panacea o bálsamo para el desarrollador de una aplicaciòn, pero tiene mucho sentido usarlo en proyectos medianos a grandes.

    Sin embargo, una aplicaciòn con comentarios en si no es la documentaciòn de un sistema, depende de lo que el desarrollador quiera documentar (si es que documenta).

    Una buena práctica documentativa se respalda en el conjunto de herramientas que permitan describir y mostrar la abstracciòn de un modelo de sistema en todos sus frentes: bases de datos, capa de negocios, presentaciòn y sobre todo del Manual de Usuario.

    Debemos recordar que los sistemas se desarrollan para usuarios finales, los que pueden ser los comunes usuarios de las aplicaciones u otros usuarios «técnicos».

    Para ambos tipos de usuarios finales, la documentaciòn es vital y permite entender la todalidad o gran parte de los modelos y reglas asociadas.

    ¿Comprarías un aparato electrónico sin manuales?. ¿Viajarías por una carrtera desconocida con poco combustible y sin tener un mapa de la ruta? ¿Usarías un shampoo sin leer las instrucciones? (puedes ser alèrgico a algún componente)

    Estas preguntas en parte se resuelven con algún documento, en ellos viene el conjunto de especificaciones, partes, usos, accesorios y especificaciones tècnicas necesarias para garantizar su uso correcto y completo.

    Por otro lado debes considerar de que si entregas un ejecutable y no las fuentes llenas de comentarios, ¿el usuario puede hacer algo?

    Creo que todo esto se hace en un justo equilibrio, si no te gusta el UML usas alguna otra especificaciòn de documentaciòn u otro medio de publicaciòn, como una Wiki por ejemplo, pero algo hay que hacer para trasmitir la escencia de lo que el usuario no sabe..

  12. Osvaldo, en ningún momento digo que no haya que documentar. Lo que sostengo es que UML es un fracaso y a las pruebas me remito. ¿Cuantos libros sobre UML se han publicado pasado el boom inicial? ¿Qué porcentaje de proyectos lo usan? ¿Cuantos usuarios lo defienden a capa y espada? ¿Cuantas herramientas nuevas lo implementan?

    Sobre si compraria un aparato sin manuales, creo que estas confundiendo documentación de diseño con documentación de usuario. Nunca miro si el aparato trae los esquemas de cirtuitos. Sin duda no compraría nada sin manual de usuario, pero UML no es para el usuario, esto está claro. Ni suquiera aunque este sea un administrador avanzado de la aplicación.

    Un saludo!!!

  13. Rodrigo:

    Estás en lo correcto en varios aspectos y en efecto entendí o leí mal tu expresión.

    Sin embargo, si escalamos, el manual de usuario para un técnico informático puede estar constituido por documentos en UML u otros formatos.

    Por tanto, para alguien que necesita descifrar como «diablos» se diseñó un sistema o aplicación es de vital relevancia que exista, a eso me refiero cuando digo que hay tener un manual de usuario.

    Otro tema es la cantidad de libros que exista de algún tópico informático, posiblemente los autores no están de acuerdo, pero si nos suscribimos a los estándares que se trasmiten oralmente (parecemos una tribu en muchos aspectos) llegamos a la conclusìòn de que lo que prevalece es usar buenas prácticas.

    No sé si te ha tocado revisar un sistema en donde no hay ni una sóla línea de documentaciòn de la misma o manuales y abunda en el código el nombre del desarrollador, empresa, derechos de copia y un montón de basura que no dice nada, pero que te hace odiar al que lo hizo porque no se entiende nada.

    Un saludo y vamos adelante que se puede mejorar!!!

  14. Oslvaldo, de acuerdo contigo en que lo que más importancia tiene es la buenas prácticas. Tengo algún que otro post dedicado a ese tema!!!

    El punto con la documentación es que solo la que está pegada al código, la que evoluciona de manaera paralela a el tiene la frescura necesaria para que podamos confiar en ella.

    Si tu tienes un documento con la documentación de tus clases, el lector de ese documento, en cuanto encuentre una discrepancia entre el documento y el código, perderá la confianza en el documento, y dejará de leerlo para centrarse en el código. Piensa en lo que tu has hecho en esta situación si no me crees…

    Esto nos lleva al punto de que solo la documentación ligada al código (comentarios xml de .net, javadoc o similar) puede evolucionar de manera correcta (el compilador se queja si añades un parámetro y no lo documentas). Además desde el código y esta documentación, usando herramientas como Sand Castle o NDoc y utras, se pueden generar, como parte de proceso de construcción, diagramas y documentación tipo chm o html con enlaces entre los elementos relacionados. Esta documentación así generada siempre está acutalizada!!!.

    Ojo que no hablo de documentación de usuario!!!.

    Un saludo y gracias por participar con tu opinión en este blog!!!

  15. Hola a todos los que han participado en este blog, no soy informático pero también me he tenido que enfrentar al asunto de documentar sistemas, de hecho mi carrera es filosofía y me he dedicado a la consultoría para la toma de decisiones y desarrollo organizacional, en particular me especializo en el desarrollo de sistemas de gestión donde me ha ido muy bien laboralmente.
    Mi trabajo me mantiene en contacto continuo con el personal de informática (como dije, diseño sistemas) y hasta he desarrollado aplicaciones, que para mi sopresa siguen en uso, en Acces mediante los asistentes y una que otra línea de código en Visual.
    Pues bien, les comparto mi experiencia:
    1. Tras un contacto continuo con personal de informática, programadores, analistas, diseñadores, dueños de negocio y demás de todos los niveles profesionales y laborales de la tecnología de la información me animaron a aprender UML para el modelaje de negocios y esas cosas. El punto es que a la fecha no me parece lo suficientemente práctico. Comparto la experiencia con Rodrigo de acompañar a personal de línea, supervisores y otros en el modelado de procesos y !créanme¡ no es práctico eso del UML, es más sencillo una narrativa casi informal, ahí sí nos entendemos.
    2. En el otro extremo tengo que vérmelas con los dueños de negocios y autoridades de la organización cliente, lo mismo, ya estando en reuniones con los que toman las decisiones, y vaya que me ha tocado trabajar con secretarios de estado y gente pesada, los modelitos que presentan algunos informáticos no les resuelven mucho, de hecho tengo qué reconocer que buena parte de mi labor se la debo a este hecho, aquí es cien por ciento verdad lo dicho por Agustín: lo importante es que el sistema produzca dinero, que haga lo que el cliente quiere que haga y que sea fácil de mantener/heredar.
    3. En los pasos que he dado de autodidacta y principiante en el tema de desarrollar programas o aplicaciones, también me cuesta mucho trabajo estar describiendo con UML los conceptos y al mismo tiempo estar aprendiendo lenguaje de programación, más aún yo esperaba que una cosa me facilitara la otra y no ha sido así.
    Por favor, no me malentiendan, sé perfectamente que no es lo mismo las peras y las manzanas, pero ¿se han preguntado porqué hay qué aprender el UML y cómo implementarlo por un lado, por el otro, hay que «asimilar el paradigma orientado a objetos» y por otro más aprender la sintaxis, palabras reservadas, instrucciones, métodos y un largo etcétera en los lenguajes de programación, cuando no es la forma natural de operar de la mente diversificar sus esfuerzos sino al contario, busca ser olística, estructurar, relacionar y esquematizar? Lo que quiero dicir es que hay qué aprender «la lógica del lenguaje unificado», «la lógica de conjuntos en la orientación a objetos» y la «lógica de los lenguajes de programación» y todos presumiblemente equiparados a la «lógica natural del pensamiento humano» cuando en la práctica la que manda, la «lógica» que en realidad opera es la última.
    En conclusión:
    Señores informáticos, sean prácticos, un poco de humildad para reconocer que el esteticismo no es lo mismo que profesionalismo. Reconozcamos que el artículo de Rodrigo nos reta porque puso el dedo en una llaga.
    Reconozcamos que todavía hay mucho camino por recorrer al UML.
    Y reconozamos que, mientras no exista una alternativa lo suficientemente extendida, «con estos bueyes hay que arar».
    Muchas gracias por sus finas atenciones.

  16. Excelentes comentarios. ( desde el 2006.)
    No me gusta el UML, creo entender que a hoy, Ruby propone que la documentacion salga del código, y que las pruebas unitarias son la base del diseño de software. estoy equivocado?
    Agile development, extreme programming.
    Qué pasa con la flexibilidad del software para prototipiar una y otra vez hasta llegar a una version confiable y en donde los involucrados den su visto bueno y aporten soluciones eficaces?.

  17. Algo grande debe venir de MicroSoft con Ruby y Phyton 2008. Para documentación.

    El Unified Modeling Lenguaje 2.0, que convierte un modelo de un sistema de software a código real, ha llegado al conjunto de lenguajes de desarrollo de .Net, de Microsoft. Esto, porque la nueva versión de las herramientas de modelado Together, de Borland Software, llevan el UML 2.0 al conjunto de lenguajes de Visual Studio de Microsoft, incluidos Visual Basic, Visual C++ y Visual C#.

    El futuro esta en ?:

    http://www.sourceforge.net/projects/doublesvsoop

    http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-791.html

    http://alarmingdevelopment.org/?p=6#comment-56281

  18. Estoy de acuerdo con tejón: la lógica natural del pensamiento humano es la que manda en la práctica.

    Buscamos sustitutos a la lógica humana, especialmente en el diseño de grandes sistemas, en el que es muy complicado unificar y mantener criterios lógicos dada la amplitud de escenarios/situaciones que nos podemos encontrar.

    Yo personalmente abogo por atomizar la información al máximo, de manera que reduzcamos todo a su mínima expresión, y de ahí obtendremos la simplicidad que la lógica humana necesita para documentar y controlar un sistema.

    Y a partir de ahí documentar, escuetamente, lo imprescindible en el propio código, generando informes a partir de esta información (ej.: comentarios de Visual C#), y completándolos con descripciones lógicas sencillas.

    Creo que una descripción breve dice más que el diseño más detallado, pero para eso hay que saber expresarse con claridad y eficiencia suficientes para hacerse entender: y eso no se enseña en ningún libro o seminario.

    Estoy de acuerdo, por otro lado, con lo que dice Rodrigo, ya que cuantas veces nos hemos encontrado con diseños detallados en UML, y al final hemos tenido que recurrir al código para estar seguro de que el mismo cumple las especificaciones!!!, por no hablar de mantener estos documentos!!!.

  19. 1990 Model E/R base de datos, en disco.
    1998 OOP, UML diseño en memoria para interactuar con las bases de datos E/R.
    Mucho más dificil que prototipear. Los proyectos inician cuando se instala el desarrollo, todo el mundo empieza a criticar, tan pronto lo usan. Por eso se pretende ser RAD, Etxreme, Agile.

    Saludos.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *