3.2. Procesos Basados en UML para OOA&D

Es importante comprender que UML es una notación para OOA&D. No describe ningñun proceso en particular. Cualquier proceso adoptado, llevará al sistema por un número de fases para ser construido.

  1. Captura de Requerimientos. Esto es donde identificamos los requerimientos para el sistema, usando el lenguaje del dominio del probrema. En otras palabras, describimos el problema en los terminos del “cliente”.

  2. Analisis. Tomamos los requerimientos y empezamos a refundirlos en el lenguaje de la solución—el dominio de la solution. En esta etapa, aunque pensando en terminos de una solución, aseguramos mantener las cosas a un alto nivel, lejos de detalles concretos de una solución especifica-lo que es conocido como abstracción.

  3. Diseño. Tomamos la especificación de la fase de Analisis y construimos la solución con todo detalle. Nos estamos moviendo de la abstracción del problema a su realización en terminos concretos.

  4. Fase de Construcción. Tomamos el diseño actual y lo escribimos en un lenguaje de programación real. Esto incluye no solo la programación, si no tambien la prueba de que el programa cumple los requerimientos (verificación), probando que el programa realmente resuelve el problema del cliente (validacion) y escribiendo toda la documentación de usuario.

3.2.1. Tipos de Procesos

En esta sección miramos a los dos tipos principales de procesos en us por la ingeniería del software. Hay otros, pero son menos ampliamente usados.

En años recientes ha habido tambien un movimiento para reducir el esfuerzo requerido en desarrollar software. Esto ha llevado al desarrollo de un numero de variantes ligeras de procesos (a menudo conocidas como computacion agil o programación extrema) que son apropiadas para equipos muy pequeños de ingenieros.

3.2.1.1. El Proceso en Cascada

En este proceso, cada etapa del proceso-requerimientos, analisis y construccion (codigo y prueba) es completada antes que la siguiente comienze. Esto se ilustra en Figura 3.1, “ El Proceso en Cascada.

Figura 3.1. El Proceso en Cascada

El Proceso en Cascada

Este es un proceso muy satisfactorio donde los requerimientos están bien diseñados no se espera que cambien, por ejemplo automatizar un sistema manual bien probado.

La debilidad de este enfoque se muestra problemas menos bien definidos. Invaliablemente algunas de las incertidumbres en los requerimientos no serán clarificados hasta bien entrado el analisis y el diseño, o incluso en fases de codificación, requiriendo volver atras para rehacer trabajo.

El peor aspecto de esto, es que no cuentas con codigo que funcione hasta cerca del final del proyecto, y muy a menudo es solo en esta etapa en la que los problemas con los requerimientos originales (por ejemplo con la interfaz de usuario) se hacen visibles.

Esto está exacerbado, por cada etapa sucesiva requiriendo mas esfuerzo que la anterior, así que los costos del decubrimiento de un problema tardío son enormemente caros. Esto esta ilustrado por la piramide en Figura 3.2, “ Esfuerzo Involucrado en los Pasos del Proceso en Cascada .

Figura 3.2. Esfuerzo Involucrado en los Pasos del Proceso en Cascada

Esfuerzo Involucrado en los Pasos del Proceso en Cascada

El proceso en cascada es probablemente aún el proceso de diseño dominante. Sin embargo debido a sus limitaciones esta cada vez mas siendo sustituido por procesos iterativos, particularmente por proyectos donde los requerimientos nos están bien definidos.

3.2.1.2. Procesos de Desarrollo Iterativo

En años recientes un nuevo enfoque ha sido usado, el cual anima a conseguir al menos una parte del codigo funcionando tan pronto como sea posible, para conseguir descubrir problemas antes en el ciclo de desarrollo.

Estos procesos usan unas series de “mini-cascadas”, definiendo unos pocos requerimientos (los mas importantes) primero, llevandolos a traves del analisis, diseño y construcción para obtener una version temprana del producto, con funcionalidad limitada, relacionada con los requerimientos mas importantes. La retroalimentación de este código puede ser usada para refinar los requerimientos, apuntar problemas, etc antes de hacer mas trabajo.

El proceso es entonces repetido para requerimientos adiciones para construir un producto con un paso mas en funcionalidad. Otra vez retroalimentación adicional puede ser aplicada a los requerimientos.

El proceso es repetido, hasta que finalmente todos los requerimientos han sido implementados y el producto está completo. Es esta iteración lo que da a estos procesos su nombre. Figura 3.3, “ Esfuerzo Involucrado en los Pasos de un Proceso Iterativo muestra como este proceso se compara con la structura piramidal del Proceso en Cascada.

Figura 3.3. Esfuerzo Involucrado en los Pasos de un Proceso Iterativo

Esfuerzo Involucrado en los Pasos de un Proceso Iterativo

El crecimiento en popularidad de los procesos iterativos está estrechamente unido a el crecimiento de OOA&D. Es la encapsulaión limpia de objetos lo que permite a una parte del sistema ser contruida con trozos para el codigo restante claramente definidos.

3.2.1.2.1. El Proceso Racional Unificado

Quizas el Proceso Iterativo mejor conocido es el Proceso Racional Unificado (Rational Unified Process; RUP) de Rational Software (www.rational.com).

Este proceso reconoce que nuestra vista piramidal de porciones iguales de la cascada no es realista. En la practica las iteraciones tempranas tienden a ser pesadas en los asuntos de requerimientos de cosas (necesitas definir una cantidad razonable incluso para comenzar), mientras las iteraciones posteriores tienen mas esfuerzo en las areas de diseño y construcción.

RUP reconoce que las iteraciones pueden ser agrupadas en un numero de fases deacuerdo a su etapa en el proyecto global. Cada fase puede tener una o mas iteraciones.

  • En la fase del principio (inception phase) las iteraciones tienden a ser pesadas en asuntos de requerimientos/analisis, mientras que cualquier actividad de construcción debe estar limitada a la emulación del diseño dentro de una herramienta CASE.

  • En la fase de elaboración (elaboration phase) las iteraciones tienden a ser completar la especificación de los requerimientos, y comenzar a centrarse en el analisis y el diseño, y posiblemente la construcción del primer codigo real.

  • En la fase de construcción (construction phase) los requerimientos y analisis están mas o menos completos, y el esfuerzo de las iteraciones esta mayormente en diseño y construcción.

  • Finalmente, en la fase de desarrollo (deployment phase) las iteraciones están centradas sobre la actividad de la contrucción, y en particular la prueba del software.

[Nota]Nota

Debería estar claro que la prueba es una parte integral de todas las fases. Incluso en las fases tempranas los requerimientos y el diseño deberian ser probados, y esto es facilitado por una buena herramienta CASE.

Usaremos un proceso iterativo en este manual, que está ligeramente basado en RUP.

3.2.1.2.2. Tamaño de Iteración

Una buena regla a primera vista es que una iteración debería tomar entre seis y diez semanas para proyectos comerciales tipicos. Mas largo y probablemente habras abarcado demasiados requerimientos para hacerlos de una vez. Ademas pierdes enfoque en tener la siguiente iteración completa. Mas corto y probablemente no has tomado en cuenta suficientes requerimientos para hacer un avance significativo. En este caso la sobrecarga adicional asociada con una iteración puede hacerse un problema.

El número total de iteraciones depende del tamaño del proyecto. Toma el tiempo estimado (trabajando fuera/adivinando que es un tema completo en si mismo), y dividelo en trozos de 8 semanas. La experiencia parece sugerir que las iteraciones se dividiran en una proporcion de alrededor de 1:2:3:3 dentro del estilo RUP de fases de inception, elaboration, construction y deployment. Un proyecto que tiene una gran imprecisión en su especificación (algunos proyectos de investigación avanzada por ejemplo) tenderan a ser mas pesados en sus fases tempranas.

Cuande se construlle un producto por contrato para un cliente el punto final esta bien definido. Sin embargo, cuando se desarrolla un nuevo producto para el mercado, una estrategia que puede se usada es decidir la fecha de lanzamiento del producto, y por tanto la fecha final para completar las labore de ingenieria (algún tiempo antes). El tiempo está entonces dividido en iteraciones, y la cantidad del producto que puede ser construido en el tiempo desarrollado. El processo iterativo es muy efectivo donde el timepo para la comercialización es mas importante que la funcionalidad exacta.

3.2.1.3. Procesos de Desarrollo Recursivo

Muy pocos sistemas software están concevidos como artefactos monoliticos. Están divididos en subsistemas, modulos, etc.

Los procesos de Software son iguales, con partes tempranas del proceso definiendo una estructura de alto nivel, y reaplicando el proceso para partes de la estructura en turnos para definir cada vez mayores detalles.

Por ejemplo, el diseño inicial de un sistema telefonico puede identificar objetos para i) manejar las lineas de telefono, ii) procesar las llamadas, iii) manejar el sistema y iv) facturar al cliente. Los procesos de software pueden entonces ser reaplicados a cada uno de esos cuatro componentes para identificar su diseño.

OOA&D con sus limites claros a los objetos, soporta naturalmente este enfoque. Esta clase de OOA&D con desarrollo recursivo se abrevia a veces como OOA&D/RD.

El desarrollo Recursivo puede ser aplicado igualmente bien a procesos de cascada o iterativos. No es una alternativa a ellos.

3.2.2. Un Proceso de Desarrollo para este Manual

Para el proposito de este manual usaremos un proceso iterativo descendente con desarrollo recursivo, ligeramente semejante a RUP. El caso de estudio nos llevará a traves de la primera iteración, aunque al final de la sección de tutorial del manual miraremos a como el proyecto se desarrollará hasta su finalización.

Dentro de la primera iteración, abordaremos cada uno de las actividades de captura de requerimientos, analisis, diseño y construcción por turno. No todas las partes del procesos están basadas en UML o ArgoUML. Miraremos a que otro material es necesario.

Dentro de este proceso tendremos una oportunidad para ver los varios diagramas UML en uso. El rango completo de diagramas UML y como están soportados está descrito en el manual de referencia (mira Sección 16.8, “ ” ).

3.2.2.1. Captura de Requerimientos

Nuestra captura de requerimientos usará el concepto UML de Casos de Uso. Empezando con un Vision Document veremos como los Casos de Uso pueden ser desarrollados para describir todos los aspectos del comportamiento del sistema en el dominio del problema.

3.2.2.2. Analisis

Durante la etapa de analisis, introduciremos el concepto de UML de clases para permitirnos construir una visión de alto nivel de los objetos que conformaran la solución—a veces conocida como diagrama de concepto.

Introduciremos el diagrama de sequencia y diagrama de estados para capturar requerimientos por el comportamiento global del sistema.

Finalmente, tomaremos los Casos de Uso de la etapa de captura de requerimientos, y remoldearlos en el lenguaje del dominio de la solución. Esto ilustrará las ideas UML de estereotipado y realización.

3.2.2.3. Diseño

Usamos el diagrama de paquetes UML para organizar los componentes del proyecto. Luego revisaremos el diagrama de clases, diagrama de secuencia y diagrama de estados, para mostrar como pueden ser usados recursivamente para diseñar la solución completa.

Durante esta parte del proceso, necesitamos desarrollar nuestra arquitectura del sistema, para definir como todos los componentes ajustaran juntos y funcionaran.

Aunque no es estrictamente parte de nuestro proceso, miraremos a como el diagrama de colaboración UML puede ser usado como una alternativa para, o complementar el diagrama de secuencia. Similarmente miraremos al diagrama de actividades UML como una alternativa o complemento para el diagrama de estado.

Finalmente usaremos el diagrama de despliege UML para especificar como el sistema será finalmente realizado.

3.2.2.4. Construcción

UML no está realmente afectado con la escritura de codigo. Sin embargo, en esta etapa mostraremos como ArgoUML puede ser usado para generación de codigo.

Tambien miraremos a como el Diagrama de Casos de Uso UML y la Especificación de Casos de Uso son herramientas invalorables para un programa de prueba.