Cuando se trata de un buen diseño de OO, manténgalo simple

Un antiguo alumno mío soltó una vez la absurda afirmación: "No puedo hacer diseño orientado a objetos (OO); ¡no tengo el dinero!" Investigando más, resultó que, en su opinión, el diseño de OO requería un producto llamado Rational Rose, que en ese momento costaba alrededor de 500,00 por asiento. En su opinión, sin Rational Rose, el diseño no era posible. Desafortunadamente, este tipo de tonterías está muy extendido; demasiada gente piensa que OO es un proceso de alta tecnología que requiere herramientas de alta tecnología. En la práctica, las herramientas con precios exorbitantes no se utilizan en el estante (o están muy infrautilizadas).

Con eso en mente, en este artículo analizo varias herramientas de diseño de OO, cómo funcionan y por qué creo que no son útiles. También explico cómo trabajo y lo que resulta útil (al menos para mí; puede no estar de acuerdo).

Las herramientas no te guían por el proceso

Cada diseño de OO exitoso que se me ha ocurrido ha seguido aproximadamente el mismo proceso:

  • Aprenda sobre el dominio del problema (contabilidad, planificación de lecciones, etc.)
  • Desarrolle, en estrecha consulta con un usuario en vivo, una declaración del problema que describa de manera exhaustiva el problema del usuario, así como cualquier solución a nivel de dominio. Este documento no describe un programa de computadora.
  • Realizo un análisis formal de casos de uso, en el que determino las tareas necesarias para resolver el problema del usuario, nuevamente, trabajando de cerca con un usuario final real. Normalmente, creo un diagrama de actividad UML (Lenguaje de modelado unificado) para cada caso de uso no trivial. (UML es una representación simbólica del software como una imagen).
  • Comience a construir el modelo dinámico que muestre los objetos en el sistema y los mensajes que esos objetos se envían entre sí, mientras se representa un caso de uso particular. Utilizo un diagrama de secuencia UML para este propósito.
  • Capturo simultáneamente información útil en el diagrama del modelo estático . Nota: nunca hago el modelo estático (diagrama de clases) primero. He descartado demasiados modelos estáticos que resultaron inútiles una vez que comencé a hacer el modelo dinámico. Ya no estoy dispuesto a perder el tiempo necesario para hacer el modelo estático en el vacío.
  • Los pasos antes mencionados generalmente producen dos o tres casos de uso, después de los cuales comienzo a codificar, arreglando el modelo si es necesario.
  • Por último, trabajo en otro caso de uso como se describe, refactorizando el diseño y el código según sea necesario para adaptarse al nuevo caso.

Ninguna de las herramientas de diseño actuales le guía a través de este proceso. En su mayor parte, son programas de dibujo caros que no funcionan particularmente bien, incluso como herramientas de dibujo. (Rational Rose, que considero uno de los menos capaces de todos, ni siquiera admite todo UML).

La ingeniería de ida y vuelta es un proceso fundamentalmente defectuoso

Estas herramientas no solo no funcionan bien, sino que el único truco que realizan, generar código, no tiene valor. Casi todas las herramientas de diseño OO siguen la noción de ingeniería de ida y vuelta en la que se comienza en una herramienta de diseño especificando su diseño en UML. Crea dos conjuntos esenciales de diagramas: el modelo estático que muestra las clases en el diseño, sus relaciones entre sí y los métodos que contienen; y el modelo dinámico, que es una pila de diagramas que muestran los objetos del sistema realizando diversas tareas en tiempo de ejecución.

Una vez que completa el modelo, presiona un botón mágico y la herramienta genera código. Sin embargo, el código generado por la herramienta no es particularmente bueno por dos razones: primero, en muchas herramientas, se crean esqueletos para las definiciones de clase, pero los métodos son simplemente códigos auxiliares vacíos; el modelo dinámico se ignora. En segundo lugar, ninguna herramienta es totalmente compatible con UML, principalmente porque ninguna puede hacerlo. UML es un lenguaje por derecho propio, que fomenta la improvisación, y gran parte del contenido real del diseño se expresa en comentarios que la herramienta de diseño suele ignorar.

Como resultado, piratea el código generado (la mayoría de las tiendas realmente lo piratean). En unas pocas semanas, el código normalmente tiene poco o nada que ver con el diseño original. De hecho, efectivamente desechas tu diseño y vuelves a caer en el síndrome del WHISKEY (¿Por qué alguien todavía no está "koding"?). Años y años de programas fallidos me demuestran que codificar sin un diseño aumenta el tiempo de desarrollo general en al menos un factor de tres, y da como resultado un código mucho más defectuoso.

Ahora viene el proceso de ida y vuelta: abre su herramienta, presiona el botón mágico e importa el código, teóricamente reconstruyendo el diseño para que refleje el estado real del código. Sin embargo, tal ingeniería inversa no funciona. Las herramientas suelen crear nuevos diagramas de clases, pero nunca actualizan el modelo dinámico. Dado que el modelo dinámico es fundamental para el proceso, su diseño ahora no tiene valor a menos que lo actualice manualmente, algo que rara vez se hace.

A riesgo de repetirme, el proceso de ida y vuelta anima a los programadores a ignorar el diseño por completo y solo el código, y luego aplicar ingeniería inversa al código en imágenes de vez en cuando. En esta situación, sin embargo, los programadores no están diseñando; están pirateando código y luego creando imágenes del desorden resultante. Hackear no es igual a diseño.

Si bien el diseño es de hecho un proceso iterativo (el diseño cambia a medida que se desarrolla el código), debe comenzar una iteración modificando el diseño primero y luego refactorizando el código para reflejar el nuevo diseño. Para hacer esto, tendría que poder especificar todo el producto de software dentro de la herramienta (cuando presione el botón mágico, se generaría un programa completamente funcional) y el proceso sería unidireccional sin una ingeniería inversa mecanismo.

Las herramientas CASE

Las herramientas CASE (ingeniería de software asistida por computadora) como Rational Rose generalmente colocan la ingeniería de ida y vuelta en el núcleo del producto. Sin embargo, dado que la ingeniería de ida y vuelta no hace nada útil, muchos desarrolladores utilizan las herramientas como costosos programas de dibujo. De las herramientas disponibles, creo que vale la pena considerar tres (aunque no uso ninguna):

  • La herramienta gratuita ArgoUML de código abierto, escrita en Java, hace un trabajo razonablemente bueno en la creación de diagramas UML. La última versión incluso intenta guiarlo a través del proceso (con un éxito marginal hasta ahora, pero es un buen comienzo).
  • El GDPro de Embarcadero, anteriormente distribuido por Advanced Software, ofrece un buen soporte para un grupo que trabaja en un solo diseño de software, pero también tiene deficiencias en este departamento. Por ejemplo, un diseñador no puede verificar un diagrama de modelo dinámico mientras bloquea automáticamente las clases asociadas con objetos en el modelo dinámico.
  • Together ControlCenter de TogetherSoft evita el problema del viaje inverso al no hacerlo. El código y el diseño aparecen en la pantalla simultáneamente, y cuando cambia uno, el otro cambia automáticamente. Sin embargo, ControlCenter no es compatible con grupos de programadores.
  • También debería mencionar brevemente Visio de Microsoft. Visio es un programa de dibujo que admite UML de alguna manera, pero su soporte imita la miserable interfaz de usuario de Rational Rose. Varias plantillas de dibujo para formas UML en Visio funcionan mejor que el soporte UML integrado, incluida una en la sección "Beneficios" de mi sitio web.

Entonces, si pienso tan mal en estas herramientas, ¿qué uso? Con mucho, las herramientas de diseño OO más productivas son una pizarra (una habitación con pizarras blancas de pared a pared, de piso a techo es ideal) y blocs de notas Post-it del tamaño de un rotafolio, cuyas hojas se pueden despegar y pegar en la pared. Los he utilizado para diseñar proyectos importantes con gran éxito. Además, trabajar en una pizarra consume mucho menos tiempo que luchar con una herramienta OO CASE.

La única dificultad con el enfoque de pizarra es capturar la información en la pizarra. Las pizarras blancas que se imprimen existen, pero son caras, desgarbadas y demasiado pequeñas. Un producto de hardware elegante que rastrea el movimiento de un lápiz a través de una pizarra y captura los trazos de lápiz en la computadora. Otras pizarras funcionan como tabletas digitalizadoras gigantes. Sin embargo, estas soluciones resultan demasiado limitantes; el diseño se realiza simultáneamente en pizarras blancas en varias oficinas, en servilletas, en trozos de papel, etc. No puede llevar una pizarra de impresión de 300 libras al café local.

Entonces que funciona

Entonces, ¿qué puede hacer una madre? ¿Cómo se capturan estos artefactos para archivarlos dentro de la computadora, de modo que hagan documentación razonable tal como están, sin tener que transferirlos a un programa de dibujo?

La solución:

  1. Una cámara digital
  2. Un producto de software maravilloso llamado Whiteboard Photo de Pixid

Desafortunadamente, una foto digital produce imágenes que no son satisfactorias para la documentación. Para compensar, Whiteboard Photo convierte las imágenes digitales en algo útil. Las imágenes realmente valen más que mil palabras, aquí. La figura 1 muestra una foto digital típica de una pizarra.

La figura 2 ilustra otro ejemplo.

La Figura 3 muestra cómo Whiteboard Photo transforma la Figura 1.

Y así es como se ve la Figura 2 después de que Whiteboard Photo hizo su magia.

Como muestran las imágenes, la diferencia es asombrosa. Para transformar la imagen original en la versión limpia, simplemente presiono Ctrl-L. El software encontró automáticamente los límites de la pizarra, corrigió la distorsión causada al tomar la imagen desde un ángulo (necesario para evitar el resplandor del flash), seleccionó las líneas del diseño y las dibujó. Todo lo que el producto necesita para lograr la perfección es el reconocimiento de escritura a mano, pero me hace cosquillas tal como está. Ahora puedo producir dibujos con calidad de documentación directamente desde la pizarra original, sin perder horas introduciendo el dibujo en alguna excusa poco convincente para una herramienta CASE.

Mantenlo simple

En mi experiencia, cuando se trata de diseño orientado a objetos, las herramientas de baja tecnología funcionan mejor. De hecho, son más rápidos, fáciles de usar y funcionan bien en entornos colaborativos. Hasta ahora, he descubierto que la combinación de una pizarra, una cámara digital y Whiteboard Photo ofrece el mejor método para introducir diseños de programas en una máquina.

Allen Holub brinda servicios de consultoría, capacitación y tutoría en diseño OO, proceso OO y programación Java. Regularmente presenta un taller intensivo de diseño de OO para aquellos interesados ​​en desarrollar rápidamente sus habilidades de OO. (Encuentre más información en //www.holub.com.) Allen ha trabajado en la industria de la computación desde 1979, más recientemente como director de tecnología en NetReliance, Inc. Tiene muchas publicaciones en revistas (Dr. Dobb's Journal, Programmers Journal, Byte y MSJ, entre otros). Allen tiene ocho libros en su haber, el último de los cuales, Taming Java Threads (APpress, 2000; ISBN: 1893115100), cubre las trampas y las trampas del subproceso de Java. Enseña diseño orientado a objetos y Java para la Universidad de California, Berkeley Extension (desde 1982).

Más información sobre este tema

  • Para obtener la herramienta de diseño ArgoUML de código abierto y gratuita, vaya a

    //argouml.tigris.org/

  • El GDPro de Embarcadero se puede encontrar en

    //www.embarcadero.com

  • Encontrará más información sobre Together ControlCenter de TogetherSoft en

    //www.togethersoft.com

  • La página de inicio de Microsoft Visio

    //www.microsoft.com/office/visio/default.htm

  • Vaya a la página del producto Pixid Whiteboard Photo para obtener más información sobre esta interesante herramienta

    //www.pixid.com/home.html

  • El sitio web de Allen Holub presenta su página "Goodies", donde encontrará consejos de diseño de OO, reglas generales de programación y notas de algunas de las charlas de Allen.

    //www.holub.com/goodies/goodies.html

  • JavaWorld 's orientada a objetos de diseño y programación Índice cuenta con numerosos artículos que abordan el diseño

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Encontrará más grandes comentario en JavaWorld 's críticas Índice de productos

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Leer más comentarios en JavaWorld 's Índice Comentario

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Para obtener consejos y tutoriales sobre patrones de diseño, herramientas de desarrollo, ajuste del rendimiento, seguridad, pruebas y más, suscríbase a nuestro boletín informativo de Java aplicado

    //www.javaworld.com/subscribe

  • Hable en nuestra discusión sobre teoría y práctica de programación

    //forums.idg.net/[email protected]@.ee6b806

  • Encontrará una gran cantidad de artículos relacionados con TI de nuestras publicaciones hermanas en .net

Esta historia, "Cuando se trata de un buen diseño OO, mantenlo simple" fue publicada originalmente por JavaWorld.