Análisis y Diseño Orientado a Objetos. Enfoque iterativo

Autor:
Jim Booth

Texto original:
When Does It Happen?

Traducido por:
Ana María Bisbé York

---

Introducción

El desarrollo de sistemas orientados a objeto es nuevo para muchos de nosotros. Ser nuevo en esto supone muchos cambios. Entre ellos está el proceso de planificación y dirección del proyecto. La mayoría de nosotros ha desarrollado proyectos antes. En aquellos proyectos trabajábamos con los usuarios para saber cuál era el sistema y cómo era que debían hacerse las cosas. Nosotros diseñábamos los programas y escribíamos las aplicaciones. Entonces, ¿qué tiene de especial la orientación a objetos?

Uno de los aspectos de la orientación a objetos es el hecho de que es relativamente nuevo de usar. Debido a esta novedad estamos casi constantemente encontrando barreras de ideas a superar. Este escrito está diseñado para exponer uno de los muchos aspectos del desarrollo orientado a objetos, el análisis y diseño y para ayudarnos a encontrar el “sendero en la jungla”. El método de análisis y diseño que vamos a examinar es llamado Enfoque iterativo, toma este nombre porque todo el proceso de desarrollo es logrado a través de una serie de iteraciones donde cada una abarca el proceso entero para el análisis a través de pruebas. Durante cada una de estas iteraciones somos capaces de retroalimentar la información de las primeras etapas del proyecto.

¿Cuándo debemos usar un proceso interactivo?

Martin Fowlr, en su libro “UML Distilled" (disponible en www.amazon.com), dice”Debe utilizar un desarrollo iterativo solo en los casos en que desee obtener éxito” El no está exagerando. Nadie puede asegurar completamente ninguna fase del ciclo de desarrollo en un simple paso. Estos son simplemente muchos detalles a los que dirigirse en cada etapa de desarrollo. La metodología puede ser usada tal que no solo permita revisar las etapas anteriores sino que también las complemente. La metodología iterativa es justo eso. Requiere que grandes proyectos sean partidos en pequeñas piezas y que cada pieza sea desarrollada mediante un proceso iterativo de análisis, diseño, implementación y pruebas.

¿Por qué hacer iteraciones?

Las iteraciones nos permiten enfocar un subconjunto del proyecto completo de tal forma que lo podemos terminar en detalle. Frecuentemente vamos a descubrir nuevos problemas y requerimientos durante el proceso de creación de uno de sus subsistemas. Estos nuevos descubrimientos pueden ser fácilmente incorporados en una iteración posterior sin desechar lo que se ha avanzado hasta entonces.

Este proceso nos permite probar cada subsistema independientemente y asegurar su propia funcionalidad. Esto significa que cuando alcancemos la etapa final del desarrollo - la integración entre los subsistemas como un todo - podremos concentrarnos en la integración sabiendo que cada subsistema está ya completamente probado.

Trabajando lo más temprano posible con los aspectos de alto riesgo para el proyecto, seremos capaces de reducir la influencia de estos riesgos en el cronograma completo del proyecto.

Durante la implementación de los subsistemas nuevos casos de uso pueden ser descubiertos. Estas situaciones nuevas pueden ser planificadas para la siguiente iteración.

¿Qué es el enfoque iterativo?

El enfoque iterativo no es nada nuevo ni revolucionario. Muchos de nosotros hemos creado sistemas por esta vía hace mucho tiempo. Martin Fowler clasifica las fases de un proyecto iterativo como Iniciación, Elaboración, Construcción y Transición. Cada una de estas fases constituye un punto diferente en la continuidad del proyecto hasta el final del mismo.

El proyecto comienza con la fase de Iniciación. Durante esta fase, la que discutiremos con más detalle más adelante, vamos a invertir un tiempo explicándonos qué es el proyecto y la mejor idea de cómo hacerlo. Al final de la fase de iniciación debemos tener una idea bastante acertada del alcance del proyecto. Los detalles no serán obtenidos; pero la visión general del sistema está aquí. En este punto podemos hacer nuestro primer corte del proyecto en piezas. Estas piezas deben estar suficientemente encapsuladas que permitan crearlas independientemente. Cada una de estas piezas satisface un subconjunto de requerimiento del sistema completo.

La mayor ventaja de este método es que puede identificar el riesgo involucrado con el proyecto y tenerlo en cuenta en la dirección del mismo. Esto nos ayuda a evitar, que conociendo todas las cosas que podrían ir mal haya que esperar a que empiecen a fallar.

Estos riesgos pueden ser esparcidos por todo el proyecto y continuar teniéndolos en cuenta.

Categorías de riesgo

Los riesgos que enfrentamos en el desarrollo del proyecto los podemos dividir en cuatro categorías. Estas categorías son: riesgos de requerimiento, riesgos tecnológicos, riesgos de habilidades y riesgos políticos. Cualquier proyecto con un alcance relativo tendrá algunos riesgos asociados con cada una de estas características. Ignorar o negar la presencia de estos riesgos significaría matar el proyecto. Estos riesgos pueden ser solo superados si no son bien manejados. Manejar los riesgos requiere de conocer cual es el riesgo y tener un plan para lidiar con ellos.

Miremos las categorías de riesgo

Riesgos de Requerimientos

La categoría de riesgos de requerimientos incluye aquellas cosas que ponen en riesgo el proyecto desde la temprana etapa de descubrimiento de requerimientos del sistema. Podemos crear el mejor sistema de software que nadie ha visto jamás para manipular la logística del papel baño de las fuerzas armadas de los EUA; pero si la necesidad fue administrar la afiliación del club de oficiales su proyecto será un fracaso.

Estar seguro de que estamos creando el proyecto correcto, este es el logro principal de administración de requerimiento de riesgos. Se generarán menores costos en la medida que se reconozcan estos riegos lo antes posible en el proyecto. Solo imagine la cantidad de trabajo (y costo) perdido si nosotros descubrimos sobre el club de oficiales en el día que vamos a instalar la aplicación logística.

El uso de casos es imprescindible en la administración de riesgos de requerimiento. El uso de casos predecirá el comportamiento que será alcanzado por el sistema. Esto le va a dar una clara visión de cómo el sistema y los usuarios interactúan.

Desarrollar un dominio conceptual de los negocios. El dominio conceptual debe darle una clara comprensión de qué cosas y en qué negocios interactúan. Un concepto general de cómo los negocios trabajan.

Luego, puede combinar el uso de casos con el modelo de dominio para crear el modelo de diseño. Tomar tiempo para identificar la información necesaria para crear estos modelos le dará una detallada información de los usuarios y los expertos de negocios sobre el proyecto. Sin dudas, usted reducirá los riesgos de requerimiento considerablemente.

Riesgos Tecnológicos

El primer riesgo tecnológico viene al olvidar la relación con la orientación a objetos. ¿Es la Orientación a Objetos un nuevo paradigma para usted o su equipo? Si es así, entonces el riego tecnológico aquí es bastante grande. ¿Enfrentará ese riesgo? ¿Va a disponer de presupuesto para entrenarse en estas técnicas, usted y su equipo? ¿Se puede permitir tener un consultante que esté disponible para dudas, reuniones, y revisiones periódicas del sistema?

¿Qué hay del problema con las nuevas tecnologías? Este nuevo proyecto requiere que los informes sean publicados en un sitio web. El sitio web debe permitir criterios dinámicos en los informes. Hey, esto de la web debe ser simpático, ¿no?

Si, mucha diversión en lo que usted comienza tratando de seleccionar el software y hardware verá y encontrará los requerimientos. Así podrá calcular la calidad de varias tecnologías que necesita incorporar para el proyecto rápidamente encontrará que este es el próximo mayor riesgo.

¿Qué ocurre si selecciona el mejor software de servicio web y el mejor software de base de datos remota solo para encontrar que no son compatibles y no trabajan bien juntos? Puede asegurar que cualquier nueva tecnología podría causarle problemas. Aquellos problemas tomarán tiempo de su proyecto.

La solución de estos riesgos tecnológicos es similar a los riesgos de requerimientos, consultores, entrenadores o tutores con habilidades específicas en esas tecnologías.

Otro método para minimizar los riesgos tecnológicos en el proyecto es crear prototipos. Crear muchos prototipos, especialmente para aquellos aspectos del sistema que usan las tecnologías más avanzadas y menos entendidas.

Riesgos de Habilidades

¿Tiene su equipo las habilidades para cumplimentar este proyecto? ¿Qué haría si a la única persona que sabe de aspectos de web le ofrecen un trabajo dónde le pagan 10 veces más justo dos semanas antes de que comience el proyecto?

¿Qué recursos existen en su área inmediata para recibir ayuda exterior? Puede necesitarla en distintos momentos de su desarrollo.

Usar un tutor puede colisionar con estos problemas de experiencias. Entrenamientos es otro factor a considerar. Nuevamente, periódicas revisiones del sistema hechos por un reconocido experto son invaluables. Finalmente lea tanto como pueda sobre las nuevas tecnologías y provea a su equipo de abundante material también en esas áreas.

Riesgos políticos

Aunque quiera creerlo o no cada proyecto está cargado de riesgos políticos. Si no tiene experiencia para lidiar con este tipo de problemas, pues tenga pronto a bordo alguien que sepa. Los riesgos políticos tienen un potencial completamente destructivo para el proyecto. Una compañía está llena de gente que tiene sus propias agendas y trabajan muy duro para cumplirlas. Los riesgos políticos se pueden mostrar como simples batallas alrededor del presupuesto en un sabotaje abierto.

Debe saber el entorno político que rodea al proyecto que va a llevar a cabo. Conocer sus amigos y enemigos. Sepa de esta gente de la cual usted puede depender y los que van a luchar contra sus esfuerzos.

Un buen libro para aprender más sobre el manejo de riesgos políticos es “Death March” escrito por Edward Yourdan. El libro es publicado por Prentice-Hall y su ISBN es 0-13-748310-4 (disponible enwww.amazon.com)

Las fases

Ahora vamos a trabajar sobre las fases del ciclo de un desarrollo de proyecto interactivo. Llamará a estas fases: iniciación, elaboración, construcción y transición. Vamos a discutir cada una de estas fases, que serán revisadas como cada punto en el proyecto de desarrollo.

La primera fase de iniciación va a identificar un conjunto de sub-proyectos a construir. Cada uno de estos sub-proyectos va a constar de sus propias fases de elaboración y construcción. Finalmente la fase de transición es donde todos los sub-proyectos se recuperan juntos.

Iniciación

La iniciación es el inicio del proyecto. Esta fase puede manifestarse en una o diferentes formas. Puede abarcar desde una conversación informal tomando un café hasta una reunión bien estructurada con una gran cantidad de personas.

El propósito de esta fase es trabajar en un resumen global del proyecto. Martin Fowler dice: “La iniciación deben ser días de trabajo en los que se debe considerar si vale la pena trabajar durante meses de desarrollo de una mayor investigación durante la elaboración.

El objetivo de la iniciación es tener una buena idea de los casos de negocios para el proyecto. ¿Cuánto puede este proyecto superar la línea principal? Otro aspecto es obtener una idea del alcance del proyecto. ¿Cuánto va a costar este proyecto?

Al final de la fase de iniciación el patrocinador del proyecto está comprometido solo a dar una mirada seria al proyecto.

Dependiendo del tamaño del proyecto puede incluir en si mismo algún grado de análisis con el objetivo de tener la idea del alcance del proyecto en esta etapa. La iniciación puede ser desde una corta conversación hasta un completo análisis de factibilidad que tome muchos meses de trabajo.

Elaboración

Ya cuando está en el punto de comenzar el proyecto, empieza la etapa de elaboración. Este es el punto donde tiene ya una idea muy general de lo que será el proyecto. Quizás usted pueda decir “Vamos a crear una aplicación que va a controlar las actividades de una bolera incluyendo la planificación de las carrileras y las ligas, imprimir los horarios de las ligas los horarios de los trabajadores, guardar la información de la recolección en caja y el control del mantenimiento de los equipos.”

La información requerida puede ser un conjunto de cosas diferente que requerirían mucho texto; pero no nos vamos a detener en este punto.

Las preguntas a responder en este punto son: ¿Qué es realmente lo que va a construir? ¿Cómo lo va a construir? ¿Qué tecnologías estará utilizando para ello?

El mayor enfoque para esta fase debe estar en los riesgos con los que se va a enfrentar. ¿Cuáles son las cosas que pueden descarrilar su proyecto y cómo debe manipularlas? Debe identificar estos riesgos en dependencia de cuánto hay en ellos de problema potencial. El mayor riesgo debe tener la mayor atención.
Estos riesgos deben ser catalogados en los grupos descritos en la sección anterior. Hay que encontrar los riesgos que necesita para comenzar a hacer el análisis y diseño detallado un sistema completo.

En primer punto para comenzar es el modelo de dominio del sistema. Una vez que tenga el modelo de dominio, es necesario moverse entre los casos de uso del sistema y finalmente combinar el modelo de dominio y los casos de estudio en un modelo de diseño.

El Modelo de dominio

El modelo de dominio es un esquema bastante general de cómo opera el negocio. Este modelo describe el mundo en el cual este sistema existirá. Necesitamos una imagen conceptual del negocio de conjunto, como accionar con el, qué cosas haces, cómo hace esas cosas y como encajan todas juntas. El modelo de dominio nos mostrará esto.

El modelo de dominio contiene una mínima cantidad de detalles. Pueden ser diagramas desconectados y estos diagramas pueden ser combinados con libertad con notas y comentarios. El modelo de dominio va a ser la base para un modelo más detallado. La figura1 es un ejemplo de modelo de dominio para un sistema ficticio.

Figura 1 – El modelo de dominio para un sistema de administración de una bolera

Note en la figura 1, no existen detalles dentro de los objetos identificados. Estos objetos son simplemente llamados partes y sus relaciones entre ellos son descritas. El modelo nos muestra una visión general del negocio y cómo funciona.

El éxito de este enfoque es que vamos a lograr una gran imagen del sistema. Para tener la concepción correcta del paquete total, desde el comienzo podemos planificar el impacto de cada pieza del sistema en las otras piezas.

Cuando el modelo de dominio está creado podemos proceder a la identificación de los casos de uso.

Casos de Uso

Martin Fowler describe los casos de uso como “Una interacción típica que el usuario tiene con el sistema para alcanzar resultados. Los casos de estudios proporcionan muchos beneficios al desarrollador. Los casos de estudio son interacciones que el usuario tiene con el sistema, así como es fácilmente comprensible por los usuarios y además provee de una retroalimentación efectiva para este grupo. Los casos de estudio son una especificación funcional. Ya que describen las cosas como se hace de la perspectiva del usuario. Casos de uso para un procesador de texto pueden ser: “hacer texto en negrita”, “hacer texto en cursiva”, “copiar un texto de un lado a otro”, o “crear un índice a un documento”. Estos ejemplos muestran que un caso de uso puede ser una pequeña acción o puede abarcar un proceso largo y complejo.

Ejemplos de casos de uso para nuestra bolera pudieran ser: “El usuario necesita ser capaz de planificar las carrileras para las ligas. Puede existir solo una liga para cada carretera en un momento dado. El espacio de tiempo para cada liga es de 2 horas. Cada liga va a tener la cantidad de carrileras que requiera para un conjunto de juegos de ligas, y “El usuario necesita imprimir la planificación para cada liga” En contra de lo que usted piensa el rango de complejidad para estos casos de uso varían mucho. El texto para el caso de uso debe ser suficientemente específico para los usuarios para comprender la idea del caso y para los desarrolladores a tener una idea de que afecta la implementación y la funcionalidad.

Los casos de uso han sido dibujados como se ve en la figura 2

Figura 2 – Un diagrama de caso de uso.

En la figura 2 puede ver que los casos de uso se representan por un óvalo con el nombre del caso de uso dentro. La “figurita” es llamada el actor y representa la persona o cosa que usa la funcionalidad. El actor puede ser un usuario o puede ser otro sistema de computadoras o incluso una máquina en la empresa.

El diagrama de caso de uso le permite ver una idea general de cómo encajan juntos.

Una vez que el modelo de dominio se ha creado y se han identificado los casos de uso se puede proceder con el modelo de diseño.

El Modelo de Diseño

El modelo de diseño identifica los objetos que el sistema contendrá y los casos de estudios las actividades que el sistema va a automatizar. El modelo de diseño es la combinación de estos dos aspectos. El modelo de diseño es también un modelo abstracto en el que no se incluye un alto nivel de detalle. Los diagramas detallados se crearán más tarde en el ciclo de desarrollo.

El propósito de este modelo de diseño es describir la combinación de la información en el modelo de dominio y el comportamiento de los casos de uso en el estilo que nos muestra cómo estas cosas encajan juntas. El modelo de diseño también provee una arquitectura reutilizable que permite para futuras extensiones del sistema.

La figura 3 es un ejemplo de un modelo de diseño para nuestro sistema de la bolera. El modelo de la figura 3 está muy lejos de ser completo, tiene solo la intención de demostrar la idea de la combinación del modelo de dominio con los casos de uso

Fig3 – Modelo de diseño

Note que la figure 3 añade el comportamiento de los casos de uso a los objetos del modelo de dominios. Los diagramas serán expandidos en el actual diagrama en un momento posterior. Aquí estamos tratando de tener una visión más completa del sistema entero.

¿Cuán lejos iremos con los diagramas?

Cuando leemos acerca de análisis y diseño de sistemas estamos viendo constantemente diferentes diagramas. Un diagrama para esto y diagramas para lo otro. ¿Cuántos diagramas son suficientes y cuántos son demasiado? ¿Qué debemos usar además de estos diagramas para la comunicación?

Los diagramas pueden ser usados cuando aportan al entendimiento del sistema y deben ser evitados cuando causan confusión. Ward Cunningham dijo: “Seleccionar cuidadosamente los memos escritos puede fácilmente sustituirse por la documentación de diseño comprensible y tradicional. Excepto en puntos aislados. Eleve esos puntos y olvídese de lo demás”

¿Qué significa esta cita? ¿Significa que debemos o no dibujar los diagramas? No, significa que los diagramas deben ser hechos cuando ayuden al entendimiento de los sistemas. Si hay diagramas que no enriquecen el entendimiento, entonces debemos olvidarnos de ellos. Muchos de los memos cortos bien escritos pueden mejor y más claramente describir nuestro punto que un complejo y confuso diagrama. En estas situaciones deje el diagrama y escriba el memo.

¿Cuándo está completa la fase de elaboración?

La fase de elaboración de un proyecto está completa cuando todos los riesgos relacionados con el proyecto están bien definidos y existen los planes para manipularlos. Además todas las tecnologías han sido identificadas y los modelos existentes para el dominio, caso de uso y diseño. Además, los desarrolladores están provistos de los estimados para la creación de cada caso de uso.

Cada caso de uso se convertirá en uno de los sub-proyectos en la fase de construcción. Esto es donde la iteración juega su papel. Durante la construcción vamos a crear cada caso de uso por separado y permitir que la experiencia de crear cada uno influya en el diseño en las otras.

Construcción

Una vez que la elaboración está completa entramos en la fase de construcción. En la construcción de cada caso de uso, los manipulamos como un proyecto ya que será construido a través del análisis, diseño, codificación, pruebas y proceso de iteración. Una iteración termina con un demo a los usuarios del subsistema completado.

Durante la construcción de un caso de uso, frecuentemente vamos a descubrir cambios que van a repercutir en nuestro diseño preliminar para otros casos de uso. Estos descubrimientos van a retroalimentar los diseños de casos de uso. También vamos a descubrir nuevos casos de uso que fueron realizados durante la fase de elaboración. Estos pueden adicionarse al proyecto y ser planificados para una construcción posterior.

Cuando completamos la construcción de cada caso de uso vamos a integrarlos con la construcción previa de casos de uso para trabajar a través de sistemas completamente integrados. Podemos reingresar la construcción de los casos de uso previamente completados y las necesidades originadas. Este proceso que da el enfoque del nombre de desarrollo iterativo, como un sistema completo en la construcción del cual hay una serie de iteraciones en cada subsistema.

Transición

La transición es la fase final del enfoque de desarrollo iterativo. La transición manipula esos aspectos que no fueron referenciados durante la construcción. Es posible que no haya alguna integración final a hacer después que todos los subsistemas hayan sido creados. Un buen ejemplo del problema que puede ser referenciado durante la transición es la optimización del rendimiento.

La optimización usualmente sacrifica claramente y facilita la integración a favor del mejoramiento del rendimiento. Esto no es siempre así, ya que nosotros queremos hacer pronto en el proyecto de desarrollo tanto como que el va a incrementar las dificultades en la creación del proyecto. En su lugar dejaremos la optimización para la fase de transición cuando todo el subsistema esté creado y probado.

La optimización es además un logro fugaz. Frecuentemente, nosotros, como desarrolladores, percibimos un problema de rendimiento cuando los usuarios no lo notarían nunca. Nosotros vamos también a sobre ver el problema del rendimiento cuando los usuarios difícilmente lo reconozcan. Si empezamos a optimizar el sistema antes que los usuarios puedan decir dónde son los puntos que ven lentos, gastaremos mucho tiempo y esfuerzo en lugares erróneos.

La transición puede ser pensada como el período de tiempo entre liberar una versión beta y la versión final del proyecto. Será como un bug fijo, en los enganches funcionales. Optimización de rendimiento, y otras cosas hechas durante esta fase. A veces podemos descubrir un caso de uso enteramente nuevo que necesitamos para no ser creado. El enfoque de desarrollo iterativo nos permite facilitar el proceso de este nuevo caso de uso y luego re-entrar en la fase de transición.

Resumen

El análisis y diseño orientado a objetos es frecuentemente visto como un enorme paquete de complejos diagramas que pueden significar poco o nada para los usuarios del sistema. Es frecuentemente visto como un proceso que envuelve una gran cantidad de conceptos abstractos y teóricos modelos que realmente aportan muy poco al proyecto.

No tiene que ser de esta forma. El análisis y diseño orientado a objetos puede ser un enfoque muy pragmático del desarrollo de un sistema. No tienen que ser frases distintas que nunca sean revisadas. El uso de un enfoque iterativo, ya que este proceso puede ser un aspecto que vive y respira en el desarrollo del sistema. Puede enriquecer nuestra habilidad de encontrar la necesidad de los usuarios y el control de los riesgos asociados con el proyecto. Cuando se usan efectivamente, el enfoque iterativo puede realmente reducir el tiempo requerido para la creación de un proyecto.