UML Y RUP

1. Desarrollo de Proyectos de Software UML Y RUP Integrantes: Coate Rosales Edmundo Saavedra Medina Nidia Carolina Valencia Magaña Javier Enrique

2. ¿Qué es UML? Lenguaje Unificado de Modelado (UML, Unified Modelling Language). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. El UML ofrece un estándar para escribir un "plano" del sistema, incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

3. ¿Por qué usar UML? Como la estrategia de evaluación incrementa en muchas compañías, las industrias la observa como técnicas de automatización la producción del Software y para mejorar la calidad y reducir los costos y el tiempo del mercado. Éstas técnicas incluyen el componente tecnológico, la programación visual, modelos y sistemas. Los negocios también observan técnicas para manejar la complexión de sistemas, así ellos aumentan en ámbito y en escala. En particular, ellos reconocen la necesidad de resolver problemas que ocurran en la arquitectura, tales como la distribuciónfísica, concurrencia, réplicas, seguridad, carga balanceada y tolerancia de culpa.

4. Objetivos de UML • Modelar sistemas (y no solo software) utilizando conceptos orientados a objetos. • . Establecer un acoplamiento explícito tanto a los artefactos conceptuales como los ejecutables. • . Resolver los problemas de escala inherente en sistemas complejos de misión crítica. • . Crear un lenguaje de modelaje utilizable por los humanos y las máquinas.

5. Historia de UML

6. Metas de UML Proporcionar a los usuarios un lenguaje de modelaje visual listo para usarse y expresivo de tal forma que permita desarrollar e intercambiar modelos con significado. Proporcionar mecanismos de extensibilidad y especialización para extender los conceptos centrales. Ser independiente de lenguajes de programación particulares y procesos de desarrollo. Proporcionar una base formal para entender el lenguaje de modelaje. Incentivar el crecimiento del mercado de herramientas orientadas a objetos. Soportar conceptos de desarrollo de más alto nivel tales como colaboraciones, estructuras, patrones y componentes. Integrar las mejores prácticas en la industria.

7. Tipos de sistemas El objetivo del UML es describir cualquier tipo de sistema, en términos de diagramas orientados a objetos. Naturalmente, el uso más común es crear modelos de sistemas de software, pero el UML también es utilizado para describir sistemas mecánicos sin ningún software o la organización de un negocio. Sistemas de información, técnicos, de tiempo real empotrados, distribuidos, software de sistemas, sistema de negocios.

8. Partes de UML • Vistas: Las vistas muestran diferentes aspectos de los sistemas que son modelados. Una vista no es un gráfico, pero es una abstracción que consiste en una serie de diagramas. • Diagramas: Son los gráficos que describen los contenidos en una vista. • Elementos del modelo: Los conceptos utilizados en los diagramas son los elementos del modelo los cuales representan conceptos orientados a objetos comunes, tales como clases, objetos, mensajes, y las relaciones entre estos conceptos incluyendo asociación, dependencia y generalización. • Mecanismo Generales: Los mecanismos generales proporcionan comentarios extras, información, o semántica acerca de un elemento del modelo.

9. Vistas • Vista de Casos de Uso: Es una vista que muestra la funcionalidad de un sistema como es percibida por los actores externos. • Vista Lógica: Es una vista que muestra como es diseñada la funcionalidad dentro del sistema, en términos de las estructuras estáticas del sistema y su comportamiento dinámico. • Vista de Componentes: Es una vista que muestra la organización de los componentes de código. • Vista de Procesos: Es una vista que muestra la concurrencia en el sistema, resolviendo problemas de comunicación y sincronización que estén presentes en un sistema concurrente. • Vista de Despliegue: Es una vista que muestra el despliegue de un sistema dentro de una arquitectura física con computadoras y dispositivos llamados nodos.

10. Diagramas • Los diagramas son los gráficos actuales que muestran los símbolos de los elementos del modelo arreglados para ilustrar una parte particular o aspecto del sistema. Un modelo del sistema típicamente tiene varios diagramas de cada tipo. • Diagramas de casos de uso • Diagrama de clases • Diagrama de objetos • Diagrama de estados • Diagrama de secuencia • Diagrama de colaboración • Diagrama de actividades • Diagrama de componentes • Diagrama de despliegue

11. Elementos del modelo Los conceptos utilizados en los diagramas son llamados elementos del modelo.

12. Relaciones • Las relaciones son también elementos del modelo, y son utilizadas para interconectar otros elementos del modelo unos a otros. Algunas relaciones diferentes son: • Asociación: Conecta elementos y enlaza instancias. • Generalización: También llamada herencia, esto significa que un elemento puede ser la especialización de otro elemento. • Dependencia: Muestra que un elemento depende de alguna manera de otro elemento. • Agregación: Es una forma de asociación en la cual un elemento contiene otros elementos. • Refinamiento: Es una forma de generalización entre un elemento a mayor nivel de detalle que otro pero que representan lo mismo.

13. Relaciones La siguiente figura muestra ejemplos de las relaciones antes descritas:

14. Diagrama de Casos de Uso • Es una vista gráfica de algunos o todos los actores, casos de uso y sus interacciones, identificados para un sistema. • Un diagrama que muestre todos los casos de uso para un actor determinado. • Un diagrama que muestre todos los casos de uso implementados en una iteración. • Un diagrama que muestre un caso de uso y sus relaciones.

15. Diagrama de Casos de Uso

16. Diagrama de Clases • Es un tipo de modelo estático. Un diagrama de clases describe la vista estática del sistema. • Vista de todas las clases de implementación en un paquete. • Vista de la estructura y comportamiento de una o más clases. • Vista de una jerarquía de herencia.

17. Diagrama de Clases

18. Diagrama de Objetos Es una variante del diagrama de clases y utiliza casi la misma notación. La diferencia entre los dos es que el diagrama de objetos muestra una serie de objetos (instancias de las clases), en vez de las clases actuales. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma, Nombre de objeto: Nombre de clase.

19. Diagrama de Objetos

20. Diagrama de Estados Un diagrama de estados es típicamente un complemento de la descripción de una clase. Muestra todos los estados posibles que los objetos de la clase puedan tener, y qué eventos causan un cambio de estado. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.

21. Diagrama de Estado

22. Diagrama de Secuencia Un diagrama de secuencia muestra una colaboración dinámica entre una serie de objetos. El aspecto importante de este diagrama es mostrar una secuencia de mensajes enviados entre los objetos. También son mostradas las interacciones entre los objetos, algo que sucederá en un punto específico de la ejecución de un sistema. Los diagramas consisten en una serie de objetos mostrados con líneas verticales.

23. Diagrama de Secuencia

24. Diagrama de Colaboración Un diagrama de colaboración muestra una colaboración dinámica, como el diagrama de secuencia. Es a menudo una elección mostrar una colaboración ya sea con un diagrama de secuencia o un diagrama de colaboración.

25. Diagrama de Colaboración

26. Diagrama de Actividades Un diagrama de actividades muestra el flujo secuencial de las actividades. El diagrama de actividades es utilizado típicamente para describir las actividades realizadas en una operación, aunque puede ser también utilizado para describir otros diagramas, tal como un caso de uso o de interacción. El diagrama de actividades consiste de estados de acción, los cuales contienen una especificación de la actividad que va a ser realizada (una acción).

27. Diagrama de Actividades

28. Diagrama de Componentes Un diagrama de componentes muestra la estructura física del código en términos de los componentes de código. Un componente puede ser un componente de código fuente, un componente binario, o un componente ejecutable. Un componente contiene información sobre la clase lógica o las clases que implementa, creando un mapeo de la vista lógica a la vista de componentes.

29. Diagrama de Componentes

30. Diagrama de Despliegue El diagrama de despliegue muestra la arquitectura física del hardware y el software en el sistema. Se pueden mostrar las computadoras y los dispositivos (nodos), junto con las conexiones que tienen unos con otros; también se puede mostrar el tipo de conexión.

31. Diagrama de Despliegue

32. RUP El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) Que Es: Es un proceso de desarrollo de software 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.

33. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.

34. Historia 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.

35. Principios De Desarrollo El RUP está basado en 5 principios clave que son: • Adaptar el proceso. • Balancear prioridades • Demostrar valor iterativamente • Elevar el nivel de abstracción • Enfocarse en la calidad

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

37. Balancear Prioridades Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Debido a este balanceo se podrán corregir desacuerdos que surjan en el futuro.

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

39. 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 requerimientos y sin comenzar desde un principio pensando en la reutilización del código.

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

41. Ciclo De Vida

42. Principales Caracteristicas • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) • Pretende implementar las mejores prácticas en Ingeniería de Software • Desarrollo iterativo • Administración de requisitos • Uso de arquitectura basada en componentes • Control de cambios • Modelado visual del software • Verificación de la calidad del software

43. El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso)....

44. Aspectos De RUP RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: • Proceso • Soporte

45. Proceso Las etapas de esta sección son: • Modelado de negocio • Requisitos • Análisis y Diseño • Implementación • Pruebas • Despliegue

46. Soporte En esta parte nos conseguimos con las siguientes etapas: • Gestión del cambio y configuraciones • Gestión del proyecto • Entorno

47. 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:

48. Inicio: Documento Visión Especificación de Requerimientos Elaboración: Diagramas de caso de uso Construcción: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lógica: Diagrama de clases Modelo E-R (Si el sistema así lo requiere) Vista de Implementación: Diagrama de Secuencia Diagrama de estados Diagrama de Colaboración Vista Conceptual: Modelo de dominio Vista física: Mapa de comportamiento a nivel de hardware.