2010
UML Y RUP Introducción al análisis, implementación y documentación de sistemas orientados a objetos Alumnos:
Jacqueline Borbón Torres David Esteban Contreras Loreto José Alberto De La Rosa De La Fuente Jorge Isaac Flores López Manuel Antonio Higuera Campaña Rosa Belem Molina Ramírez Francisco Guadalupe Moreno Romero Ernesto Alejandro Orozco Rodríguez
Carrera:
Ing. En Sistemas Computacionales Materia:
Planificación y Modelado Docente:
Héctor David López Páez
INTRODUCCIÓN Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los diseños de forma gráfica. Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una forma más bien personal o con algún modelo gráfico. La falta de estandarización en la manera de representar gráficamente un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores. Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creó el proceso de desarrollo de software, RUP (Rational Unified Process) Process ), que junto con
el Lenguaje Lenguaje Unificado de Modelado
(Unified Modeling Language) Language ), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño. El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.
2
JUSTIFICACIÓN
Con la introducción de los lenguajes orientados a objetos, surge la necesidad de implementar nuevas técnicas de diseño y análisis. Es aquí donde entran en uso el lenguaje UML y RUP.
OBJETIVO Dar a conocer las características y utilidad del lenguaje UML y su metodología RUP, desde sus orígenes hasta el día de hoy.
FUNDAMENTO TEÓRICO ¿CÓMO Y POR QUÉ SURGE UML? Tras la aparición de los lenguajes orientados a objetos se buscaron nuevas metodologías que permitiesen el análisis y diseño de aplicaciones bajo dichos lenguajes; estas metodologías fueron los primeros lenguajes de modelado orientados a objetos. Al no poder cubrir éstos todas las necesidades de los desarrolladores, surgió una nueva generación de lenguajes más potentes, liderados por el método de Booch, el método OOSE de Jacobson y el método OMT de Rumbaugh; cada uno de estos métodos destacaba en algunos puntos pero fallaba en otros. El lenguaje UML comenzó a gestarse en octubre de 1994, cuando James Rumbaugh se unió a la compañía Rational fundada por Grady Booch (dos reputados investigadores en el área de metodología del software ). El objetivo de ambos era 3
unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Ivar Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los ³tres amigos´. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML. La versión 1.0 de UML surgió en 1997 con la contribución de IBM, HP, Oracle, Microsoft y otras organizaciones. El desarrollo de UML continúa actualmente bajo el control de IBM (que adquirió Rational); la última versión de UML es la 2.0.
MODELADO VISUAL Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual. El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos que el ser humano pueda entender.
4
UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas de software como para la arquitectura hardware donde se ejecuten. Otro objetivo de este modelado visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños realizados usando UML se puedan implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos). UML es además un método formal de modelado. Esto aporta las siguientes ventajas:
y
Mayor rigor en la especificación.
y
Permite realizar una verificación y validación del modelo realizado.
y
Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto.
¿QUÉ ES UML? UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo. 5
y
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
y
Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.
y
Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
y
Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.
y
Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.
Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es los suficientemente expresivo como para modelar sistemas que no son informáticos, como flujos de trabajo (workflow ) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware. Un modelo UML está compuesto por tres clases de bloques de construcción: y
Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc. )
y
Relaciones: relacionan los elementos entre sí.
y
Diagramas: Son colecciones de elementos con sus relaciones.
La diferencia entre UML y los lenguajes de programación normales es que UML es
³
un lenguaje que utiliza gráficos para describir objetos. UML también es utilizado para describir patrones de diseño que pueden ser aplicados al entorno .NET.´ 6
DIAGRAMAS UML Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas: Diagramas de estructura:
Diagrama de clases.
y
Diagrama de componentes.
Diagrama de objetos
Diagrama de estructura compuesta
Diagrama de despliegue
Diagrama de paquetes
Diagramas de comportamiento: y
Diagrama de actividades
y
Diagrama de casos de uso
y
Diagrama de estados
Diagramas de interacción: y
Diagrama de secuencia
y
Diagrama de comunicación 7
y
Diagrama de tiempos
y
Diagrama de vista de interacción
Los diagramas más interesantes (y los más usados ) son los de casos de uso, clases y secuencia, por lo que nos centraremos en éstos. El diagrama de casos de uso representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los de interacción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema.
8
¿QUÉ ES RUP? y
Es un proceso de desarrollo de software:
y
Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo ).
y
Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología
estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. y
Es un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
y
RUP es una guía de cómo có mo usar UML de la forma más efectiva.
¿CUÁLES SON LOS CICLOS Y FASES QUE INTERVIENEN EN RUP? RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo. Cada ciclo se divide en 4 fases: y
INICIO: y
y
Establece la oportunidad y alcance el proyecto.
ELABORACIÓN: y
Analizar el dominio del problema
y
Establecer una arquitectura base sólida
y
Desarrollar un plan de proyecto 9
y
Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto
y
CONSTRUCCIÓN O DESARROLLO: y
En esta fase todas las componentes restantes se desarrollan e incorporan al producto.
y
TRANSICIÓN O CIERRE: y
Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.
¿QUÉ SON LOS ROLES? Un Rol define el comportamiento y las responsabilidades de un individuo. Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de cada uno y el resultado (artefactos ) que se espera de ellos. Todos los miembros del equipo comparten: y
Base de conocimiento
y
Proceso
y
Vista de cómo desarrollar software
y
Lenguaje de modelamiento (UML )
10
¿QUÉ SON LAS ACTIVIDADES? Una actividad es una unidad de trabajo que se asigna a un trabajador y lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
¿QUÉ SON ARTEFACTOS? RUP en cada una de sus fases (pertenecientes a la estructura estática ) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros ). Estos artefactos (entre otros ) son los siguientes: y
y
INICIO: y
Documento Visión
y
Especificación de Requisitos
ELABORACIÓN: y
Diagramas de caso de uso
11
y
CONSTRUCCIÓN: y
y
y
y
VISTA LÓGICA: y
Diagrama de clases
y
Modelo E-R (Si el sistema así lo requiere )
VISTA DE IMPLEMENTACIÓN: y
Diagrama de Secuencia
y
Diagrama de estados
y
Diagrama de Colaboración
VISTA CONCEPTUAL: y
y
Documento Arquitectura que trabaja con las siguientes vistas:
Modelo de dominio
VISTA FÍSICA: y
Mapa de comportamiento a nivel de hardware.
12
¿CUÁLES SON LOS PRINCIPIOS DE DESARROLLO DE RUP? El RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados 13
Colaboración
entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks ) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente
14
ORÍGENES DE RUP Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB ). El primer resultado de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.
CONCLUSIÓN Nosotros como equipo consideramos que RUP junto con UML, es una metodología muy completa, de la cual nos dimos cuenta que posee extensa información con lo que pudimos comprender que UML y RUP son, aunque ambas distintas cosas, herramientas que juntas ayudan a crear modelos bastante bien estructurados acerca de un sistema. UML es un lenguaje visual y modelado, ofrece varios diagramas para representar ideas. RUP es un modelo o proceso de desarrollo de software, se basan en desarrollo incremental y suele ser difícil si no se cuenta con la documentación adecuada y suficiente. RUP usa UML para llevar la documentación del sistema, facilitar la etapa de diseño y desarrollo,
a
las
ideas
y
a
ayudar
al
equipo
a
comunicarlas.
15
FUENTES DE INFORMACIÓN y
http://www.wikipedia.org
y
http://html.rincondelvago.com
y
http://www.rational.com.ar/herramientas/rup.html
y
http://www.planetacodigo.com/wiki/glosario:uml
y
http://www.alegsa.com.ar/Dic/uml.php
y
http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs. %20XP.pdf
y
http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
y
http://setepro.googlecode.com/files/Introducción a
y
http://www.monografias.com/trabajos16/lenguaje-modelado-
RUP.ppt
unificado/lenguaje-modelado-unificado.shtml
y
Enterprise Development with Visual Studio .NET, UML, and MSF by John Erik Hansen and Carsten Thomsen
y
G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado", Addison Wesley, 1999
y
Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo",
Addision Wesley, 2000 y
E. Hernández, J. Hernández, C. Lizandra, "C++ Es-tandar", ITP Paraninfo 2001
y
El Lenguaje Unificado de Modelado (UML ) - Enrique Hernández Orallo
16
