Reseña Histórica del Proceso Unificado de Desarrollo (PUD)
El PUD es el resultado de 30 años de desarrollo y uso práctico. Se puede dividir el transcurso de su desarrollo en tres etapas: desde la publicación de “Objectory Method” publicado en 1987 como resultado del éxito del método Ericsson, pasando por el “Objectory Rational Process” (Desarrollado por IBM Rational entre 1996-1997) hasta el Proceso Unificado de Rational (publicado en 1998).
El Método Ericsson
El estudio del origen del PUD, se remonta a 1967, donde la compañía Ericsson modelaba un sistema entero como una serie de bloques interconectados. Los bloques de más bajo nivel se incorporaban a subsistemas de mayor nivel, con lo que se lograba que el sistema fuera más manejable. Los bloques, eran identificados estudiando los “Casos de Negocio” (actuales casos de uso) que se definían con anterioridad. Cada caso de negocio permitía detallar los bloques que debían cooperar para llevarlo a cabo.
Al tener adjudicada la responsabilidad de cada bloque, se preparaba su especificación. Las actividades de diseño generaban un conjunto de diagramas de bloques estáticos con sus interfaces, agrupados en subsistemas (su semejante en la actualidad son los diagramas de clases ó paquetes de UML).
El producto primogénito de las actividades de diseño radica en la descripción de la arquitectura de software, la cual consistía en la comprensión de los requisitos más críticos, junto con una breve descripción de cada bloque y el agrupamiento de éste en subsistemas. Luego, eran representadas en diagramas la descripción e interconexiones de los bloques. El método era adelantado a su tiempo, ya que los clientes no acostumbraban a que se representaran los productos de software en forma similar a los datos de proyectos de ingeniería.
El método Ericsson es esencialmente el que actualmente se conoce como “desarrollo basado en componentes”. Comprobó su efectividad de diseño modular al brindar la posibilidad de instalar cada bloque ejecutable o modificado sobre la marcha de un sistema de telecomunicaciones en ejecución el 100 por ciento de su tiempo (era sumamente improductivo detener un sistema de tal magnitud simplemente para hacer cambios).
Objectory
Ivar Jacobson fue el principal desarrollador de la metodología empleada en Ericsson. Deja la compañía en 1987 y funda Objectory AB en Estocolmo. Como fruto de 8 años de trabajo en su compañía, él y sus colaboradores desarrollan un proceso denominado “Objectory” (Abreviatura de “Object Factory” en español, fábrica de objetos). El empleo de esta metodología se extendió en diversas industrias además de las de telecomunicaciones, y en muchos países aparte de Suecia.
Es en Objectory donde se define con su nombre al Caso de Uso, y se desarrolla una técnica para su representación. La idea se amplió, y como consecuencia los casos de uso que dirigían el desarrollo se hicieron más claros, dando pié al origen de la metodología que guíe al desarrollador e informe al usuario.
Surgen los flujos de trabajo, representados por una serie de modelos: requisitos-casos de uso, análisis, diseño, implementación y prueba. Cada modelo representaba una perspectiva del sistema, éstos permiten al desarrollador realizar una traza sobre un caso de uso a través de la secuencia de modelos hasta el código fuente cuando surgen problemas (incluso puede volverse hacia atrás).
Objectory aportó ideas sobre cómo diseñar procesos generales sobre los que opera un negocio, ya que eran aplicables los mismos principios. El desarrollo de Objectory transcurrió en una serie de versiones, desde la 1.0 de 1988 a la primera versión interactiva: Objectory 3.8. El método fue publicado en un libro en 1995.
El Proceso Objectory de Rational
A finales de 1995, Objectory AB es adquirida por Rational Software Corp. Inmediatamente, surge la especial urgencia de unificar los principios básicos subyacentes en los procesos de desarrollo existentes, y se optó por unir lo mejor de cada uno. Al momento de fusionarse, Objectory 3.8 había probado la creación y modelado de un proceso de producción de software de manera similar a un producto, dando origen a una arquitectura original de desarrollo y contaba con una serie de modelos que documentaban el resultado del proyecto. Sin embargo, aunque correctamente desarrollado en lo referente a modelado de casos de uso, análisis y diseño, no se encontraba bien desarrollado en áreas como la gestión de requisitos aparte de los casos de uso, implementación y pruebas.
Es en esta parte, donde entra la experiencia y práctica de Rational, mejorando el proceso y originando Objectory 4.1 en 1997. Entre las mejoras que lo conforman se encuentran el añadir fases de desarrollo y la aproximación iterativa controlada.
Es de hacer notar, que se desarrolló también una definición muy precisa de la arquitectura, que fue considerada una de las partes más significativas de la organización del sistema, y se representó por medio de vistas arquitectónicas de los modelos. El desarrollo iterativo se convirtió en una metodología que usaba como directriz los riesgos considerados en primer lugar por la arquitectura. Cabe destacar que UML se encontraba en fase de desarrollo, y se une como el lenguaje de modelado del Proceso Objectory de Rational (Rational Objectory Process, ROP). Philippe Kruchten realizó mejoras del ROP, reforzando elementos como la gestión de proyecto.
El Lenguaje Unificado de Modelado
A principios de los 90, surgió la necesidad de un lenguaje de modelado visual y consistente, que permitiera expresar los resultados de las extensas variedades de metodologías Objeto Orientadas que existían.
Por esta razón, Grady Booch, Autor del método Booch y James Rumbaugh, desarrollador principal de OMT (Object Modeling Technique), quienes trabajaban juntos en rational, comenzaron a unificar sus metodologías. El fruto de esta unión es la versión 0.8 del Método Unificado (Unified Modeling Language ó UML), publicado en Octubre de 1995.
Casi en el mismo momento, Ivar Jacobson se incorpora a laborar en Rational y se une para la producción de la versión 0.9 de UML. El esfuerzo de unión incluía a otros expertos en el área e involucró empresas como IBM, HP y Microsoft. Luego de pasar por el proceso de estandarización el OMT (Object Management Group) publica en noviembre de 1997 la versión estándar de UML 1.1.
El Proceso Unificado de Rational
A partir de 1997, Rational se fusiona y adquiere otras empresas fabricantes de herramientas que ampliaron mucho más el proceso Objectory de Rational. Para 1998 Se había convertido en un proceso capaz de soportar el ciclo de vida de desarrollo en su totalidad, integraba una riqueza de aportaciones de las más diversas fuentes de autores.
Reseña Histórica de los Autores del PUD
Grady Booch
Según Rational.com Grady Booch es reconocido internacionalmente por su innovador trabajo en la ingeniería y modelado de software. Recibió su título de grado en ciencias en la Academia de la Fuerza Aérea de los Estados Unidos en 1977, y su maestría de ciencias en ingeniería eléctrica en la Universidad de California en Santa Bárbara en 1979.
Ha pertenecido a la compañía IBM Rational en calidad de Jefe Científico desde su fundación en 1981. Booch es uno de los desarrolladores originales del Lenguaje Unificado de Modelado (UML, en inglés) y fue también desarrollador de varios productos de IBM Rational. Ha servido como arquitecto y mentor arquitectónico de numerosos proyectos de software de intensa complejidad desarrollados alrededor del mundo.
Grady ha sido autor de 6 libros Best Seller, entre los que están: “UML Users Guide” y “Object - Oriented Analysis with Applications”. También ha publicado cientos de artículos técnicos sobre ingeniería de software, incluyendo publicaciones a principios de los 80 que originaron el término y la práctica del Diseño Orientado a Objetos.
Actualmente es miembro de Association for Computing Machinery (ACM), Institute of Electrical and Electronics Engineers (IEEE) , the American Association for the Advancement of Science (AAAS) y Computer Professionals for Social Responsibility (CPSR). Está afiliado en calidad de Fellow en ACM, IBM, World Technology Network y Software Development Forum Visionary.
James Rumbaugh
Según Rational.com ha sido uno de los principales desarrolladores de metodologías para el diseño de software del mundo. Realizó sus estudios en el MIT (Massachusetts Institute of Technology), obteniendo el grado de BS. en física. En Caltech obtuvo el grado de magíster en astronomía y un Ph.D. en ciencias de la computación realizado también en el MIT bajo la dirección del Dr. Jack Dennos. Junto con su colega de IBM Rational, Grady Booch e Ivar Jacobson, desarrollaron el Lenguaje Unificado de Desarrollo (UML por sus siglas en inglés), el cual es el estándar adoptado por “Object Management Group” en 1997. James, ha sido el representante líder de IBM Rational a cargo de desarrollos posteriores de UML para la OMG, y ha contribuido en muchos de los conceptos de UML. También ha laborado junto con otros líderes de Rational de otras áreas como IBM Rational Unified Process® y metodologías de desarrollo en tiempo real.
James, mantiene una experiencia en el campo de metodologías de software de más de 30 años. Fue el desarrollador jefe de “Object Modeling Technique” (OMT), una metodología de análisis y diseño objeto orientada, predecesora de UML. Antes de unirse a IBM Rational (1994), trabajó por 25 años en el Centro de Investigaciones y Desarrollo de General Electric de Schenectady, Nueva York. En su tiempo de trabajo en el centro, desarrolló el lenguaje de programación orientado a objetos DSM, el modelo de control de tres estados, la notación de objetos OMT (Cabe mencionar que los fundamentos para el desarrollo de la notación de dicha metodología se desarrollaron por mas de 10 años con la colaboración de Mary Loomis y Ashwin Shah) y una herramienta para la edición gráfica del modelado de objetos.
Su carrera ha cubierto aspectos de la semántica de la computación, herramientas para la productividad de la programación, y aplicaciones que usan algoritmos complejos y estructuras de datos. Desarrolló el Sistema de Gráfico de Flujo, un sistema de gráfico interactivo genérico por controlar una red de plan que diseña los trabajos, incluso la dirección de versiones múltiples de datos y coordinación de flujo de información entre las aplicaciones; recibiendo una patente por los conceptos mencionados anteriormente. Además, desarrolló algoritmos para la reconstrucción de imágenes, optimizando dicho proceso de manera sorprendente. Algoritmos para el despliegue de imágenes tridimensionales en tiempo real. Finalmente es el autor de los libros: Guía de Usuario de UML Manual de Referencia de UML El Proceso de Desarrollo de Software Unificado.
Ivar Jacobson
Fue el creador del “Objectory method” y fundador de “Objectory AB” En Suecia. Actualmente se encuentra retirado, pero fue anteriormente Vicepresidente de Ingeniería de Negocios en Rational Software, donde se involucró en el desarrollo de UML. Ivar Jacobson es bien conocido por ser pionero y por 25 años de experiencia en el uso de la metodología objeto orientada para el diseño de sistemas de gran escala y de tiempo real. Su trabajo a gran escala y arquitectura de reutilización fue elemento clave para el éxito de “AXE telecommunications switch” de Ericsson.
Es el autor principal de dos libros de gran importancia en la programación Orientada a Objetos: “Object-Oriented Software Engineering” y “Business Process Reengineering with Object Technology”. Jacobson es también conocido por la invención de los Casos de Uso y el proponer modelos separados para el análisis y el diseño, ya que para sistemas complejos a gran escala, es de mayor utilidad mantener un modelo de objetos idealizado del sistema que muestre cómo los objetos pueden colaborar para reunir los requerimientos funcionales.
Aspectos generales de la metodología
Según Booch, Rambaugh y Jacobson, (2000) El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades para transformar los requisitos de un usuario en un sistema software. Sin embargo, el Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud diferentes tamaños de proyectos.
El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas.
El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado. No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres fases claves: dirigido por casos de uso, centrado en la arquitectura, e interactivo e incremental. Esto es lo que hace único al Proceso Unificado.
Características de la metodología
Según Booch, Rambaugh y Jacobson, (2000, p. 4-6) PUD está dirigido por casos de usos, está centrado en la arquitectura y es un proceso iterativo e incremental.
El Proceso Unificado está dirigido por casos de usos
Un sistema de software ve la luz para dar servicios a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. Los casos de uso han sido adaptados casi universalmente para la captura de requisitos de sistemas software en general.
El termino usuario (actores) no sólo hace referencia a usuarios humanos sino a otros sistemas. En este sentido, el termino usuario representa alguien o algo que interactúa con el sistema que estamos desarrollando; como respuesta al usuario el sistema lleva a cabo una secuencia de acciones que proporcionan al usuario un resultado importante.
Una interacción de este tipo es un caso de uso; un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de usos representan los requisitos funcionales. La captura de requisitos tiene dos (2) objetivos: encontrar los verdaderos requisitos y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores,
Todos los casos de uso juntos constituyen el modelo de casos de uso; los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema: También guían su diseño, implementación, y prueba; esto es, guían el proceso de desarrollo.
De este modo, los casos de uso no sólo inician el proceso de desarrollo sino que le proporciona un hilo conductor Dirigido por caso de uso quiere decir que el proceso de desarrollo sigue un hilo; avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de finales son la fuente a partir de la cual se construyen casos de prueba.
Aunque es cierto que los casos de uso guían el proceso no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye en la selección de los casos de uso. Por tanto, tanto la arquitectura del sistema como los cosos de uso maduran según avanza el ciclo de desarrollo.
El proceso unificado está centrado en arquitectura
El papel de la arquitectura software es parecido al papel que juega la arquitectura en la construcción de edificios. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura brinda una clara perspectiva del sistema completo, necesaria para controlar el desarrollo. Un sistema software es una única entidad por lo que es útil presentar el sistema desde diferentes perspectivas para comprender mejor el diseño. Estas perspectivas son vistas del modelo del sistema. Todas estas vistas representan la arquitectura.
La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores y se reflejan en los casos de uso. Sin embargo, también se ve influida por la estructura, el comportamiento y por muchos otros factores, como la funcionalidad, el rendimiento, la flexibilidad, la reutilización, la facilidad de comprensión, las restricciones y los compromisos económico, tecnológicos y la estética. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.
Los sistemas se simulan para darle una forma. Es esta forma, la arquitectura, debe diseñarse para permitir que el sistema evolucione, no sólo en su desarrollo inicial, sino también a lo largo de las futuras generaciones. Para encontrar esa forma se debe trabajar sobre la compresión general de las funciones clave, es decir, sobre los casos de uso clave del sistema. La arquitectura se necesita para: comprender el sistema, organizar el desarrollo, fomentar la reutilización y hacer evolucionar el sistema.
El Proceso Unificado es iterativo e incremental
El desarrollo de un producto software supone gran esfuerzo que puede durar varios meses hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o microproyectos. Cada microproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto; las iteraciones deben estar controladas; esto es, se deben seleccionar y ejecutar de una forma planificada.
La selección de lo que se implementará se basa en una iteración en dos factores. En primer lugar, la iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteración trata los riesgos más importantes
Fases dentro de un ciclo
El desarrollo de un ciclo se realiza a lo largo del tiempo. Según Booch, Rambaugh y Jacobson, (2000) Cada ciclo se divide a su vez en 4 fases:
• Inicio: es la fase en que se plantea una descripción del producto final, a partir de una buena idea y se presenta el análisis de negocio para el producto.
• Elaboración: se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema.
• Construcción: es la fase en que se crea el producto, añadiendo el software terminado a la arquitectura, convirtiendo la línea base de la arquitectura en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado al usuario.
• Transición: abarca el período en el que el producto es una versión beta, en la cual un reducido número de usuarios con experiencia prueba el producto, para informar sus defectos y deficiencias.
Para poder realizar el desarrollo de las fases se deben tomar en cuenta los flujos de trabajo (requisitos, análisis, diseño, implementación y prueba).
Los requisitos
La captura de los requisitos en algunas oportunidades resulta un poco complicada, esta es la acción de descubrir, luego de realizar ciertas averiguaciones, lo que los usuarios desean que los desarrolladores de software construyan.
El flujo de trabajo de los requisitos tiene como objetivo fundamental guiar el desarrollo hacia el sistema correcto. Esto mediante una buena descripción de los requisitos del problema que permite un buen entendimiento entre los clientes o usuarios y los desarrolladores del sistema.
Análisis
En este flujo se representa el análisis de los requisitos que se describen en la captura de los requisitos. El propósito de realizar esta acción es conseguir la comprensión de los requisitos más precisa y una descripción de estos que nos ayude a estructurar mejor el sistema entero.
En el análisis se utiliza un lenguaje que se basa en un modelo de objetos conceptual, al cual se le llama modelo de análisis. El modelo de análisis permite refinar los requisitos y razonar sobre los aspectos internos del sistema.
Una de las razones por las cuales es importante analizar los requisitos en la forma de un modelo de análisis es que el modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación y en forma general, su mantenimiento.
Diseño
El diseño no es más que la modelación del sistema en la cual encontramos su forma para que soporte todos los requisitos. El resultado del análisis, es decir, el modelo de análisis representa una entrada esencial en el diseño. Entre los objetivos del diseño encontramos los siguientes: obtener una comprensión en profundidad de los requisitos y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y concurrencia, tecnología de interfaz de usuario, tecnologías de gestión de transacciones, entre otras.
Implementación
Aquí se toma en cuenta el resultado del diseño y se realiza la implementación del sistema en términos de componentes, es decir, ficheros de código fuente, scripts, ficheros de códigos binarios, ejecutables y similares.
La implementación tiene varios propósitos entre los cuales se pueden citar los siguientes:
• Planificar las integraciones de sistema necesarias en cada iteración.
• Asignar componentes ejecutables a nodos en el diagrama de despliegue para distribuir el sistema.
• Implementar las clases y subsistemas encontrados durante el diseño.
• Probar los componentes individualmente, y a continuación integrarlos compilándolos y enlazándolos en uno o más ejecutables, antes de ser enviados para ser integrados y llevar a cabo las comprobaciones del sistema.
Prueba
En este flujo de trabajo se verifica el resultado de la implementación probándose cada construcción, incluyéndose las construcciones finales del sistema que serán entregadas a los usuarios.
Entre los propósitos de la prueba se tienen:
• Planificar las pruebas necesarias en cada iteración.
• Diseñar e implementar las pruebas creando los casos de pruebas que especifican qué probar, creando los procedimientos de pruebas que especifican como realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
• Llevar a cabo las diferentes pruebas y manejar los resultados de cada una sistemáticamente.
Ventajas y Desventajas del PUD
Ventajas
• Las iteraciones y construcciones proporcionan reducen la proporción de las tareas, grupos de trabajo y permiten un constante control de riesgos y realimentaciones.
• Permite un lenguaje común como lo es UML, convirtiendo al desarrollo de software una disciplina de ingeniería en vez de meramente escribir código.
• Al emplear las tecnologías de componentes, se puede emplear la reutilización, reduciendo el tiempo y los costes de desarrollo.
Desventajas
• Todo el proceso como tal, se encuentra muy ligado al método, lo que puede ocasionar inconvenientes al tratar de combinar con otras metodologías.
• A pesar de su desarrollo, el método aún no incluye una metodología totalmente explícita para el control de las actividades de gestión.
Herramientas de modelado que utilizan la metodología PUD
Según Booch, Rambaugh y Jacobson, (2000) Las herramientas son buenas para automatizar procesos repetitivos, mantener las cosas estructuradas, incrementar la productividad y la calidad, gestionar grandes cantidades de información y guiarnos un camino de desarrollo concreto.
Sin un soporte por herramientas que automatice la consistencia a lo largo del ciclo de vida, será difícil mantener actualizado los modelos y la implementación. El desarrollo iterativo e incremental será más difícil, acabara siendo inconsistente, o requerirá gran cantidad de trabajo manual para actualizar documentos y mantener así la consistencia.
A medida que se introduce un soporte por herramientas, se obtiene un proceso diferente, más formal. Podemos incluir nuevas actividades que seria poco práctico realizar sin herramientas. Podemos trabajar de una manera mas precisa durante el ciclo de vida entero: se puede utilizar un lenguaje de modelado formal como UML para asegurar que caca modelo es consistente internamente con relación a otros modelos. Se puede utilizar un modelo y a partir de el generar partes de otro (por ejemplo del diseño a la implementación y viceversa).
Las herramientas que implementan un proceso automatizado deben ser fáciles de usar. Hacerlas muy manejables significa que los desarrolladores de herramientas deben considerar seriamente la forma en que se lleva acabo el desarrollo del software.
El desarrollo del proceso y su soporte por herramientas debe tener lugar de manera simultánea. En cada versión del proceso debe haber también una versión de las herramientas. En cada versión debe darse ese equilibrio. Alcanzar casi el ideal de este equilibrio nos llevara varias iteraciones, y las sucesivas iteraciones deben guiarse por la retroalimentación de los usuarios entre versiones.
Un ejemplo significativo de una herramienta en el contexto de soporte del proceso unificado es la herramienta de modelado para UML. UML es lenguaje visual. Como tal, se le suponen características comunes en muchos productos de dibujo como edición, dar formato, hacer zoom, imprimir, dar color y diseño automático. Además de esas características UML define reglas sintácticas que especifican como combinar elementos del lenguaje. Por tanto, la herramienta debe ser capaz de garantizar que se cumplen esas reglas. Esta posibilidad esta fuera del alcance de los productos de dibujos habituales donde no se comprueban reglas.
UML requiere un cierto número de reglas semánticas que también requieren soporte. Estas herramientas pueden incluirse en la herramienta de modelado, bien como de cumplimiento obligado inmediato o rutinas bajo demanda que reconocen el modelo y comprueban si hay errores comunes, o buscan faltas de compresión semánticas o sintácticas.
Mediante el uso de UML como lenguaje estándar, el mercado experimentara un soporte por herramientas mucho mejor que el que nunca haya tenido ningún lenguaje de modelado. Esta oportunidad de un soporte mejor es debida en parte a la definición precisa de UML. También puede atribuirse al hecho de que UML es hoy en día un estándar industrial ampliamente utilizado. En lugar de haber fabricantes de herramientas compitiendo para dar soporte a muchos lenguajes de modelado diferentes, el juego esta en encontrar ahora al que mejor soporte UML. Este nuevo juego es mejor para los usuarios y clientes del software. Entre las herramientas que soportan todos los aspectos del ciclo de vida del software:
• Gestión de requisitos: se utiliza para almacenar, examinar, revisar, hacer el seguimiento y navegar por los diferentes requisitos de un proyecto de software.
• Modelado visual: se utiliza para automatizar el uso de UML, es decir, para modelar y ensamblar una aplicación visualmente. Con esta herramienta conseguimos la integración con entornos de programación y aseguramos que el modelo y la implantación siempre son consistentes.
• Herramientas de Programación: proporcionan una gama de herramientas, incluyendo editores, compiladores, depuradores, detectores de errores y analizadores de rendimiento.
• Aseguramiento de la calidad: se utiliza para probar aplicaciones y componentes, es decir, para registrar y ejecutar casos de prueba que dirigen la prueba de un IGU y de las interfaces de un componente. En un ciclo de vida iterativo, la prueba de regresión es aun mas esencial que en el desarrollo convencional. La automatización de los casos de prueba es esencial para conseguir una productividad alta. Además muchas aplicaciones también necesitan ser expuestas a pruebas de estrés y de carga.
Modelos de PUD
En PUD, ofrece una serie de modelos que permiten llevar a cabo todas las representaciones del producto software deseado.
• Modelo de Casos de Uso: un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. El modelo de Casos de Uso brinda la posibilidad de representar los casos de uso y su relación con todos los usuarios involucrados en el sistema.
• Modelo de Análisis: este Modelo tiene dos finalidades: refinar con más detalle los casos de uso y a su vez establecer la asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.
• Modelo de Diseño: con el se definen la estructura estática del sistema en la forma de subsistemas, clases e interfases. También, permite representar los casos de uso en forma de colaboraciones entre los subsistemas, clases e interfaces.
• Modelo de Implementación: incluye componentes, (que representan al código fuente) y la correspondencia de las clases con los componentes.
• Modelo de Despliegue: define todos los nodos físicos (ordenadores) y la correspondencia de los componentes con esos nodos.
• Modelo de Prueba: un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados, desarrollados para un objetivo concreto. El modelo describe los casos de prueba que verifican si el sistema implementa correctamente su especificación, definida en los casos de uso.
Diagramas de UML
Para Booch, Rambaugh y Jacobson (ob. cita, p.82), los distintos diagramas que se pretenden obtener de un sistema mediante UML son:
• Diagramas de casos de uso.
• Diagramas de clases.
• Diagramas de comportamiento o interacción. Entre ellos:
• Diagramas de estado.
• Diagramas de actividad.
• Diagramas de secuencia.
• Diagramas de colaboración.
• Diagramas de implementación.
• Diagrama de componente.
• Diagrama de plataforma.
Explicar cómo se construyen y para qué se utilizan cada uno de los diagramas supondría mucho tiempo. A continuación se procede a explicar brevemente algunos aspectos importantes:
Diagramas de casos de uso.
Para Booch, Rambaugh y Jacobson (ob. cita, p.84), un caso de uso es una secuencia de operaciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y otros sistemas. Un actor es una entidad externa al sistema que se modela y que puede interactuar con él. Un ejemplo de actor puede ser un usuario o cualquier otro sistema.
Diagramas de Clases.
Para Booch, Rambaugh y Jacobson (ob. cita, p.83), muestra un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, junto con sus contenidos y las relaciones que se establecen entre ellos.
Diagramas de interacción o comportamiento.
Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:
• Diagramas de secuencia: para Booch, Rambaugh y Jacobson (ob. cita, p.84), modelan las interacciones entre un conjunto de objetos, ordenadas según el instante en que tienen lugar.
• Diagramas de colaboración: para Booch, Rambaugh y Jacobson (ob. cita, pp.84-85), muestran la interacción entre varios objetos y los enlaces que existen entre ellos.
• Diagramas de actividad: para Booch, Rambaugh y Jacobson (ob. cita, p.85), son similares a los diagramas de flujo de otras metodologías Orientadas a Objetos.
• Diagramas de estado: Para Booch, Rambaugh y Jacobson (ob. cita, p.85), representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a los eventos recibidos.
Diagramas de componentes.
Para Booch, Rambaugh y Jacobson (ob. cita, p.83), muestran las dependencias entre los distintos componentes software, incluyendo componentes de código fuente, binarios y ejecutables. Un componente es un fragmento de código software que se utiliza para mostrar dependencias en tiempo de compilación o en tiempo de ejecución.
Café Sci (2004) Grady Booch
[Documento en línea]
Disponible: http://coloradocafesci.org/Booch.htm
[Consulta, 2004, Octubre 15]
Cangénova, R (2004) Editorial
[Documento en línea].
Disponible: http://www.arcride.edu.ar/appei/revistas/r26a4.htm
[Consulta: 2004, Octubre 17]
Guerrero, L. (2003) Clase 23 - Proceso Unificado de Desarrollo
[Documento en línea].
Disponible: http://www.dcc.uchile.cl/~luguerre/cc51h/clase23.html
[Consulta: 2004, Octubre 10]
Hinchcliffe, D. (2004) Ivar Jacobson
[Documento en línea]
Disponible: http://c2.com/cgi/wiki?IvarJacobson
[Consulta: 2004, Octubre 17]
Jacobson, I.., Booch, G. y Rumbaugh, J. (2000) El Proceso Unificado de Desarrollo de Software. España: Addison Wesley.
Rational (2002) Though Leaders: James Rumbaugh
[Documento en línea]
Disponible: http://www-306.ibm.com/software/rational/bios/rumbaugh.html
[Consulta, 2004, Octubre 10]
