Metodología RUP y Metodología UML
Metodología RUP:
El proceso de desarrollo RUP (Rational Unified Process) aplica varias de las mejores practicas en el desarrollo moderno de software en una forma que se adapta a un amplio rango de proyectos y organizaciones. Provee a cada miembro del equipo, un fácil acceso a una base de conocimiento con guías., plantillas y herramientas para todas las actividades criticas del desarrollo de software. Esta metodología permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cómo desarrollar el software utilizando un lenguaje modelado común: UML.
El RUP es un proceso de desarrollo de software:
Provee un enfoque estructurado para realizar tareas y responsabilidades en una organización de desarrollo. Su principal objetivo es asegurar la producción de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible.
El RUP es un producto:
IBM comercializa un producto que permite instanciar al RUP según las características del proyecto, siendo una referencia en la metodología que sirve como repositorio único de información.
El RUP es un marco de trabajo (Framework):
Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organización que lo utilice seleccionando las fases y interacciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos (artifacts) que se van a construir. Es importante conocer como esta organizado y estructurado el proceso para poder seleccionar el frame work, los elementos del proceso que mas valor darán al proyecto.
El RUP incorpora muchas de las conocidas como “buenas practicas” en el desarrollo de software moderno, lasa cuáles se deben tener presentes en el desarrollo de aplicaciones empresariales para garantizar el éxito del proyecto, tales como: Desarrollo iterativo, Gestión de Requerimientos, Arquitectura basada en componentes, Modelo Visual, Verificación de la calidad en forma continua y control de cambios.
El RUP presenta 3 características que constituyen la esencia de todo el proceso de desarrollo:
1. Dirigido por los casos de uso.
2. Centrado en la arquitectura.
3. Ciclo de vida iterativo.
Otras características o ventajas de la aplicación de esta metodología son las siguientes:
• Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio
• Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema
• Reduce el costo del riesgo a los costos de un solo incremento
• Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo
• Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración.
• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño
El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos y un conjunto de “artefactos” definidos que deben alcanzarse. La duración de cada fase depende del equipo y del producto a generar.
A su vez, cada fase puede tener una o más iteraciones y cada iteración sigue el modelo en cascada pasando por las distintas disciplinas. Cada iteración termina con una liberación del producto.
Las fases son las siguientes:
1) Inicio
2) Elaboración
3) Construcción
4) transición
Metodología UML:
La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST (Modeling and Analysis Suite for Real-Time Applications), que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT.
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
La versión definitiva de la metodología será publicada por Booch, Rumbaugh y Jacobson a finales de este año. Se pueden tener en cuenta las siguientes etapas
En cada etapa se resaltan las actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está
buscando
|
|
Esta información se representa en un diagrama de casos de uso.
| Cómo encontrar un actor?
| |
| Cómo encontrar un caso de uso? | |
| Cómo encontrar relaciones entre actores y casos de uso? Qué casos de uso son similares, diferenciándose en la forma en la cual hacen algunas operaciones? Busque relaciones uses entre casos de uso Que casos de uso son usados como transacciones de otros? |
| Describir la información de entrada y salida de cada caso de uso | |
| Descripción detallada del caso de uso
| |
| Relacionar el caso de uso con la interfaz a usuario que lo representa | |
| Especificar el diálogo que da solución al caso de uso (ver definición de interfaz) |
| Dibujar las pantallas de interacción para los distintos actores-usuarios | |
| Especificar el diálogo que da solución a cada caso de uso que se soluciona con la interacción con esta interfaz. Puede especificarse este diálogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se sugiere escoger el mínimo nivel de detalle posible, para dar más libertad de diseño en las etapas posteriores):
| |
| Definir restricciones para la comunicación con actores y sistemas |
Esta información se representa en un diagrama de estructura estática de clases.
| Identificar Clases
Posibles errores:
| |
Posibles errores
| |
| Identificar mensajes
Posibles errores
| |
Posibles Errores
| |
| Identificar restricciones del modelo
Posibles errores
| |
| Identificar paquetes
| |
| Consideraciones de reutilización
|
| Validar las restricciones descritas para las clases
| |
| Validar atributos y mensajes
| |
| Desarrollar diagramas de interacción (diagramas de secuencia o de colaboración) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes.
| |
| Validar los diagramas de Interacción
| |
| Validar con un experto del dominio
| |
| Validar con un usuario representativo de cada actor
| |
| Iterar si es necesaria más información |
En esta etapa se define una subdivisión en aplicaciones del sistema (si es lo suficientemente grande) y la forma de
comunicación con los sistemas ya existentes con los cuales debe interactuar
|
|
| Definir componentes del sistema, las aplicaciones y su ubicación. Representarlos por medio de nodos, componentes y objetos activos (representando las aplicaciones) dentro de los nodos. | |
| Definir mecanismos de comunicación. Expresarlos por medio de asociaciones de dependencia entre los nodos, componentes o aplicaciones y, si es conocido, agregar un estereotipo para definir el protocolo de comunicación requerido. Agregar notas con restricciones, rendimiento esperado y demás detalles de las conexiones. | |
| Particularizar los casos de uso a la arquitectura planteada. Refinar los casos de uso ya existentes de la etapa anterior para adecuarse a la arquitectura planteada. | |
| Validar arquitectura. Comprobar la validez técnica, económica y organizacional de la propuesta. |
| Diagramas de Ejecución, versión inicial | Procesadores |
En esta etapa se adecúa el análisis a las características específicas del ambiente de implementación y se completan las
distintas aplicaciones del sistema con los modelos de control, interfaz o comunicaciones, según sea el caso.
|
|
| Completar el detalle de las clases: Tipos de los atributos | |
| Enriquecer el modelo con el framework de base en el ambiente de implementación escogido | |
| Incorporar patrones de diseño | |
| Subdividir en paquetes | |
| Definir excepciones | |
| Completar comportamiento de las clases: Constructores, destructores, modificadores, consultores | |
| Adecuar el modelo a las características del lenguaje de programación | |
| Evaluar eficiencia | |
| Validar el sistema |
| Conocer el framework de base | |
| Enlazar las clases de interfaz con las clases del modelo del mundo |
| Conocer los frameworks de base | |
| Enlazar las clases del framework con las demás clases del sistema |
| Diagramas de clases y paquetes, con el detalle de la implementación | |
| Diagramas de interacción con el detalle de las operaciones más importantes del sistema | |
| Diagramas de estados y/o actividades para las clases concurrentes o complejas |
Se desarrolla el código de una manera certificada.
|
|
| Asimilar los idioms aplicables al lenguaje | |
| Conocer y adecuar estándares de programación al lenguaje | |
| Definir estructura de directorios | |
| Diseñar makefiles |
| Revisiones de código | |
| Tratamiento de Trace y Log |
| Casos de prueba | |
| Procedimiento de instalación |
| Código fuente | |
| Soporte de pruebas unitarias | |
| Documentación del código |
/https%3A%2F%2Fassets.over-blog.com%2Ft%2Fcedistic%2Fcamera.png)