Sesión 1. Porque es útil usar UML Sesión 2. Casos de uso Modelo del Negocio Sesión 3. Diagramas de Casos de Uso Sesión 4. Diagrama de Actividad

Transcripción

1

2 Sesión 1. Porque es útil usar UML Sesión 2. Casos de uso Modelo del Negocio Sesión 3. Diagramas de Casos de Uso Sesión 4. Diagrama de Actividad Sesión 5. Diagrama de Secuencia Sesión 6. Diagrama de Estados Sesión 7. Diagrama de Clases Sesión 8. Diagramas de Colaboración Sesión 9. Diagrama de componentes Sesión 10. Diagramas de distribución.

3 Sesión 1. Porque es útil usar UML Es una herramienta de diseño unificada orientada al objeto del software de la lengua que modela (UML) prevista para modelar de la representación visual y la construcción componente de los usos del software.

4 Sesión 1. Porque es útil usar UML Rational Rose racional documenta el diagrama como se está construyendo y después genera código en la opción del diseñador de: C++ Basic Visual Java Oracle8

5 Sesión 1. Porque es útil usar UML Es una Herramienta que posee la capacidad de Crear Ver Modificar Manipular los componentes de un modelo con una de las siguientes notaciones. Como ser UML

6

7

8 INICIO DE TRABAJO

9 LESE-2 Introducción a Rational Rose Interfaz Toolbars Browser Documentation Window Log Diagram Window 9

10 Interfaz Browser Para navegar por los elementos de los modelos Toolbars Para acceder a comandos Diagram Window Para visualizar y editar diagramas Documentation Window Para documentar elementos de los modelos Log Para ver resultados de los comandos

11 Browser Navegar por los elementos de las vistas de Rose Añadir elementos a los modelos Borrar elementos de los modelos Renombrar elementos de los modelos Mover elementos de los modelos Ver asociaciones (son un elemento más) Abrir las especificaciones de algún elemento Agrupar en Paquetes los elementos de los modelos Añadir Diagramas Abrir Diagramas

12 Vistas de Rose 1. Vista de Caso de Uso La vista de Caso de Uso organiza el Modelo de Caso de Uso y opcionalmente el modelo de Casos de Uso del Negocio. 2. Vista lógica El Proceso Unificado Rational usa la Vista lógica para organizar el Modelo de Diseño y la Vista de Proceso en el opcional Modelo del Negocio de objetos y en el Modelo del Análisis.

13 Vistas de Rose 3. Vista de componentes En el Proceso Unificado Rational La Vista de Componentes es usada para organizar el Modelo de Implementación. 4. Vista de Despliegue Este diagrama define la configuración típica de una red física de network, incluyendo componentes típicos de usuarios finales. Ubicación de procesos en varios nodos. Ubicación tomando en cuenta la capacidad de nodos (memoria y procesador), ancho de banda de medios de comunicación (LAN, WAN,bus), y la existencia de hardware de comunicación, etc.

14 Vistas de Rose Use Case View Diagrama de casos de uso Diagramas de interacción Diagramas de actividad Lógical View Diagramas de clases Diagramas de estado Diagramas de interacción Component View Diagramas de componentes Deployment View Diagrama de deployement

15 Operaciones con Diagramas Crear diagramas En la vista, con el botón derecho, seleccionar la opción New -> diagrama En Browse -> XXX Diagram... Y seleccionar <new> Borrar diagramas Seleccionarlo y con el botón derecho, opción delete Mover diagramas de una vista a otra Arrastrándolo Los elementos que había creado quedan en la vista original

16

17 Sesión 2. Casos de uso Modelo del Negocio En el Modelo de Casos de Uso del Negocio cada Caso de Uso del Negocio representa un proceso del negocio, descrito (como texto o diagrama de actividades o ambos) desde un punto de vista externo sin mencionar quien o a quien afecta en la organización.

18 Sesión 2. Casos de uso Modelo del Negocio

21

22 Sesión 3. Diagramas de Casos de Uso 1. Actor Un actor en un caso de uso representa un rol que alguien o algo podría desempeñar y no un alguien o algo específico

23 Sesión 3. Diagramas de Casos de Uso 2. Caso de Uso un caso de uso se puede describir como una forma específica de uso del sistema para la perspectiva de un actor (usuario/rol), se puede caracterizar como: Un modelo de comportamiento que muestra el sistema Una secuencia de transacciones efectuada por el actor y el sistema Envió de resultados a un actor Los Casos de uso dan sentido a: Capturar requerimientos del sistema Comunicación entre usuarios finales y expertos Testear el sistema Con los casos de uso es más fácil examinar y definir que actor hará que en el sistema Como las necesidades de un sistema no pueden ser cubiertas por un solo caso de uso, es usual tener una colección de ellos. Todos los casos de uso reunidos muestran la forma en que el PROYECTO DE SOFTWARE TRABAJAR

24 Sesión 3. Diagramas de Casos de Uso Nombre de Caso de Uso Un Caso de Uso puede tener un nombre, pero no suele ser un nombre cualquiera, es corriente que sea escrito como una descripción informal de los actores y de la secuencia de eventos entre objetos. El nombre de un Caso de Uso suele comenzar con un verbo en infinitivo. El nombre de un Caso de uso se despliega debajo del icono.

25 Sesión 3. Diagramas de Casos de Uso Interrelación Se puede crear una asociación de interrelación entre un Caso de Uso y un Actor. Se puede crear un interrelación de Generalización entre dos Casos de Uso

26 Sesión 3. Diagramas de Casos de Uso Interrelación de Extensión Es una asociación de interrelación entre dos Caso de Uso Es cuando un Caso de uso puede o no recibir un mensaje de otro Caso de Uso que viene a añadir o enriquecer el servicio de caso de uno que está dando el servicio.

27 Sesión 3. Diagramas de Casos de Uso Interrelación de inclusión o uso Es una relación entre dos Caos de Uso. La funcionalidad u operación del primero incluye al segundo Entre doble parentesis angular se especifíca <<include>> o <<use>>

28 Sesión 3. Diagramas de Casos de Uso

29 Sesión 3. Diagramas de Casos de Uso

33

34 Sesión 4. Diagrama de Actividad Es un Esquema, una representación visual de una secuencia simplificada de lo que ocurre durante una operación o proceso. Es un complemento del Diagrama de Estados. En el diagrama de estados se representa las actividades como flechas entre estados. El diagrama de actividades resalta justamente esas actividades.

35 Sesión 4. Diagrama de Actividad Descripción A cada actividad se le representa como un rectángulo con las esquinas redondeadas (mas angosto y ovalado que la representación de estado) El procesamiento dentro de una actividad dentro del la actividad luego pasa a la siguiente actividad. Una flecha representa la transición entre actividad y actividad

36 Sesión 4. Diagrama de Actividad Decisiones

37 Sesión 4. Diagrama de Actividad Rombo es una opción

38 Sesión 4. Diagrama de Actividad Rutas concurrentes Es común que dos procesos deban ejecutarse al mismo tiempo y luego se unan La línea horizontal representa la sincronización al principio o al final o ambos

39 Sesión 4. Diagrama de Actividad

42 Sesión 4. Diagrama de Actividad Definiendo Responsabilidades (swimlane)

43 Sesión 4. Diagrama de Actividad Diagrama Hibrido

46

47 Sesión 5. Diagrama de Secuencia El diagrama de Secuencia ayuda a representar los modelos de interacción Muestra los estados de un objeto durante un proceso También nuestra como los objetos (no las clases) se comunican entre si Normalmente un Modelo de comportamiento capta la acción de un solo Caso de Uso

48 Sesión 5. Diagrama de Secuencia Simbología Reglas de construcción: 1. Determinar que objetos son necesarios para la implementación del escenario. 2. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior. 3.- La distribución horizontal de los objetos es arbitraria. 4.- Un diagrama de secuencia se modela para cada caso de uso.

49 Sesión 5. Diagrama de Secuencia Descripción En la parte superior de cada columna se identifica a los objetos Las flechas representan operaciones o eventos Las flechas de acción son sólidas (izquierda - derecha) Las flechas de respuesta o retorno (derechaizquierda)

50 Sesión 5. Diagrama de Secuencia

53

54 Sesión 6. Diagrama de Estados Es una representación del Proyecto de Software, en el cual se muestra como cambian los procedimientos en el tiempo Este tipo de diagrama es muy importante para los diseños del Proyecto de Software en tiempo real Con esto se obtendrá un modelo de comportamiento, mostrara los cambios en el tiempo

55 Sesión 6. Diagrama de Estados Descripción Las flechas representan una transición, un cambio de estado Circulo relleno representa el inicio Rectángulo de vértices redondeados representa un Estado Circulo relleno dentro de circulo representa el final

56 Sesión 6. Diagrama de Estados

57 Sesión 6. Diagrama de Estados Elementos del Acción Información que muestra un Estado es: Entrada/ (On entry/) prefijo, acción al entrar en estado Hacer/ (Do/) actividad durante el estado En Evento/ (On Event/) Salida/ (On Exit/) prefijo, acción al salir del estado

59 Sesión 6. Diagrama de Estados OBJETIVO: Adquirir familiaridad con los elementos

60 Sesión 6. Diagrama de Estados Entrada Acción Salida Fuente: aprendiendo uml 24 horas

61 Sesión 6. Diagrama de Estados Condición de Seguridad Fuente: aprendiendo uml 24 horas

63 Sesión 6. Diagrama de Estados Diagrama de estados realizar venta

64

65 Sesión 7. Diagrama de Clases Describe gráficamente las especificaciones de las clases de software y de las interfaces en una aplicación. Sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, entre otros. A demás son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en el análisis el diagrama se desarrolla buscando una solución ideal y durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones

66 Sesión 7. Diagrama de Clases

67 Sesión 7. Diagrama de Clases Simbología

68 Sesión 7. Diagrama de Clases Defina los siguientes conceptos: 1.- Asociación: cuando las clases se conectan entre si de acuerdo al mundo real o al mundo conceptual. 2.- Agregación o agregación por referencia: en ocasiones una clase consta de otras clases. Los componentes y la clase que constituyen son una asociación que conforma un todo. Las partes pueden pertenecer a varios todos. Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

69 Sesión 7. Diagrama de Clases Defina los siguientes conceptos: 3.- Composición o agregación por valor: tipo especial de agregación, donde cada componente de una composición puede pertenecer tan solo aun todo. Donde las partes no pueden pertenecer a otros todos. Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

70 Sesión 7. Diagrama de Clases Defina los siguientes conceptos: 4.- Generalización/Herencia: Una subclase puede heredar los atributos y operaciones de otra superclase. Una clase se puede clasificar en dos tipos de clases. 5.- Rol: para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.

71 Sesión 7. Diagrama de Clases Defina los siguientes conceptos: 6.- Multiplicidad: la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada, es decir, una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase.

72 Sesión 7. Diagrama de Clases Reglas de construcción: 1. Cada clase representa una cosa que es administrada para la aplicación modelada. 2. Las clases pueden relacionarse con otras a través de diversas maneras como asociación, agregación, composición y generalización. 3.- La estructura interna de una clase esta conformado por los atributos y operaciones.

74 Sesión 7. Diagrama de Clases

75

76 Sesión 8. Diagramas de Colaboración Explican gráficamente como los objetos interactúan a través de mensajes para realizar tareas. Son considerados como hermanos de los diagramas de secuencia, por ser parecidos cumpliendo la misma función de graficar las interacciones entre los objetos de un mundo real. Los mensajes son detallados identicandolos con un número de orden y usando los mensajes parametrizados. Un diagrama de colaboraciones es una extensión de un diagrama de objetos

77 Sesión 8. Diagramas de Colaboración Simbología

78 Sesión 8. Diagramas de Colaboración

79 Sesión 8. Diagramas de Colaboración Reglas de construcción: 1. Estudiar todos los efectos de un objeto dado durante el escenario. 2. Los mensajes parametrizados indican los valores que se envían entre los objetos. 3. Los enlaces representa una instancia de una asociación entre las clases implicadas. 4. Los cambios de estado en un objeto se pueden mostrar. Aprendiendo UML en 24 horas.

81 Sesión 8. Diagramas de Colaboración

82

83 Sesión 8. Diagramas de Componentes Ilustra las piezas de software, controladores incorporados, etc. que compondrán un sistema. Muestra las relaciones entre los componentes de software, sus dependencias, la comunicación, la localización y otras condiciones. Un diagrama de componente tiene un alto nivel de abstracción que un diagrama de clase