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 Figure 3.1, “El Proceso en Cascada”.

Figure 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 Figure 3.2, “Esfuerzo Involucrado en los Pasos del Proceso en Cascada”.

Figure 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. Figure 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.

Figure 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.

[Note]Note

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 Section 16.6, “Diagram” ).

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.