La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi.

Presentaciones similares


Presentación del tema: "AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi."— Transcripción de la presentación:

1 AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi

2 2 Mitos sobre UML Aprender UML es aprender el paradigma de objetos. UML es una metodología de desarrollo. UML es solo para modelos de objetos.

3 AUS. Gustavo Torossi3 Entonces ¿qué es UML? UML es un lenguaje unificado de modelado para: Visualizar Especificar Construir Documentar los artefactos de un sistema de software. Representar y Comunicar Ideas Modelos precisos, no ambiguos, completos Trasladar en forma directa a un leng. prog. Los artefactos construidos durante un proyecto

4 AUS. Gustavo Torossi4 ¿ Qué significa lenguaje unificado? Lenguaje = sintaxis + semántica Unificado a través de: Métodos y notaciones históricas Etapas del ciclo de desarrollo (requerimientos a implementación) Dominios de aplicación Lenguajes y plataformas de implementación Procesos de desarrollo

5 AUS. Gustavo Torossi5 Evolución histórica Nov 97 UML promulgado por la OMG

6 AUS. Gustavo Torossi6 Influencias

7 AUS. Gustavo Torossi7 Participantes en UML 1.0 Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing (Desmond DSouza) Intellicorp and James Martin & co. (James Odell) MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys

8 AUS. Gustavo Torossi8 Modelos E = M * C 2

9 AUS. Gustavo Torossi9 ¿Qué es un modelo? Una representación en algún medio que captura los aspectos importantes del sistema modelado desde un determinado punto de vista. Un modelo de un sistema software es realizado en un lenguaje de modelado.

10 AUS. Gustavo Torossi10 Propósito de los modelos Capturar y precisar requerimientos de un dominio de conocimiento, que sea comprensible por todos los stakeholders del proyecto. Pensar sobre un diseño de un sistema. Capturar decisiones de diseño de un sistema. Explorar posibles soluciones a un problema económicamente. Generar productos de trabajo útiles. Documentar.

11 AUS. Gustavo Torossi11 UML - Conceptos

12 AUS. Gustavo Torossi12 UML - Vistas Una vista es un subconjunto de construcciones de modelado que se enfocan en un aspecto particular del sistema. Las vistas pueden dividirse en tres áreas: Estructural Comportamiento dinámico Gestión del modelo

13 AUS. Gustavo Torossi13 Vistas – Clasificación estructural Describe los elementos del sistema (clasificadores) y sus relaciones. Clasificadores más comunes: Clases Casos de Uso Componentes Nodos Vistas: Vista Estática – Diagrama de clases Vista de Casos de uso – Diagrama de casos de uso Vista de Implementación – Diagrama de Componentes / despliegue

14 AUS. Gustavo Torossi14 Vistas – Comportamiento dinámico Describe el comportamiento del sistema a través del tiempo. Vista de Interacción: modela como interactúan los objetos para realizar una funcionalidad del sistema Diagrama de Colaboración Diagrama de Secuencia Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de Estados Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades

15 AUS. Gustavo Torossi15 Vistas – Gestión del modelo Describe la organización de los modelos en unidades jerárquicas. Permite manejar la complejidad. Permite organizar el sistema en paquetes, subsistemas, y modelos.

16 AUS. Gustavo Torossi16 Relación Áreas - Vistas

17 AUS. Gustavo Torossi17 Mecanismos de extensión de UML Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos Valores etiquetados Restricciones (OCL)

18 AUS. Gustavo Torossi18 La Vista Estática

19 AUS. Gustavo Torossi19 La Vista Estática Propósito: Captura la estructura de los objetos. Es la base sobre la que se construyen las otras vistas. Es un modelo incremental. Diagrama de Clases

20 AUS. Gustavo Torossi20 Clasificación Clasificador: es un concepto discreto en el modelo que tiene identidad, estado, comportamiento, y relaciones. Tipos de Clasificadores Elementos del Sistema: Clase Interfaz Tipos de datos Conceptos de Comportamiento: Caso de Uso Cosas del entorno: Actor Estructuras de implementación: Componente Nodo Subsistema

21 AUS. Gustavo Torossi21 Clases & Objetos Objeto = estructura + operaciones + estado interno + identidad. Un objeto es una instancia de una clase. Clase: Conjunto de objetos con estructura, comportamiento, relaciones, y semántica común. Ejemplos algo físicoAvión algo del negocio Pedido un concepto lógicoHorario algo de la aplicaciónWindow, Botón, Menú algo del comportamientoTarea, Proceso

22 AUS. Gustavo Torossi22 Clases: Notación Gráfica Cada clase se representa en un rectángulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase

23 AUS. Gustavo Torossi23 Clases: Niveles de visibilidad Determina el nivel de encapsulamiento de los elementos de una clase. (-) Privado : Los atributos/operaciones son visibles solo desde la propia clase. (#) Los atributos/operaciones protegidos están visibles para la propia clase y para las clases derivadas de la original (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)

24 AUS. Gustavo Torossi24 Clases: Niveles de visibilidad Ejemplo

25 AUS. Gustavo Torossi25 Clases: Estereotipos Objetos Entidad Objetos Interfaz Objetos de Control Empleado UIEmplead Control

26 AUS. Gustavo Torossi26 Clases y Objetos Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa una situación concreta del dominio.

27 AUS. Gustavo Torossi27 Diagrama de Objetos Diagrama de Clase Diagrama de Objetos

28 AUS. Gustavo Torossi28 Interfaces Describen un protocolo de comportamiento sin especificar su implementación. Contienen operaciones pero no atributos. Una interfaz puede ser implementada por varias clases.

29 AUS. Gustavo Torossi29 Relaciones Las relaciones entre clasificadores son: Asociación (conocimiento) Agregación / Composición Generalización Dependencias

30 AUS. Gustavo Torossi30 Asociación Asociación: Conexión semántica entre instancias de clases. proporciona una conexión entre los objetos para el envio de mensajes. Enlace: Instancia de una asociación. Lista ordenada de referencias a objetos.

31 AUS. Gustavo Torossi31 Asociación: representación gráfica PersonaCompañía trabaja-para nombre s. nombre dirección jefe Administra empleado * * emplea-a * marido casado-con mujer

32 AUS. Gustavo Torossi32 Asociación: multiplicidad Especificación de multiplicidad (mínima...máxima) 1Uno y sólo uno 0..1Cero o uno M..NDesde M hasta N (enteros naturales) *Cero o muchos 0..*Cero o muchos 1..*Uno o muchos (al menos uno) La multiplicidad mínima >= 1 establece una restricción de existencia

33 AUS. Gustavo Torossi33 Asociación: casos especiales Asociación como clase Asociación calificada Asociación ordenada Restricción Cuenta Persona 1 * or Empresa * *

34 AUS. Gustavo Torossi34 Agregación y composición Representa una relación todo-partes entre objetos. Son una variación de la asociación con mayor fuerza semántica. Una composición es una forma de asociación más fuerte en la cual el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación. La composición implica tres cosas Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto.

35 AUS. Gustavo Torossi35 Representación gráfica Agregación Composición

36 AUS. Gustavo Torossi36 Generalización Relación taxonómica entre una descripción general y otra más específica que la extiende. Relación es un tipo de. Herencia: mecanismo a través del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otras clase denominadas subclases.

37 AUS. Gustavo Torossi37 Representación Gráfica

38 AUS. Gustavo Torossi38 Herencia Múltiple Animal BípedoCuadrúpedo Con Pelos Con Plumas Con Escamas Herbívoro Carnívoro cubertura cobertura comida nro patas comida Conejo

39 AUS. Gustavo Torossi39 Dependencias Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia.

40 AUS. Gustavo Torossi40 Dependencias De traza De refinamiento De uso De importación …

41 AUS. Gustavo Torossi41 Diagrama de clases: ejemplo

42 AUS. Gustavo Torossi42 La Vista de Casos de Uso

43 AUS. Gustavo Torossi43 La Vista de Casos de Uso Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve desde el exterior. Visión de caja negra del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades discretas: los casos de uso. Concepto introducido por I.Jacobson en OOSE. Diagramas de Casos de Uso: Actores + Caso de uso

44 AUS. Gustavo Torossi44 Actor Representa algo que interactúa con el sistema. Puede ser humano u otro sistema. Reside fuera del sistema. Describe el entorno. Describe un rol que asume un usuario. La misma persona física puede asumir distintos roles. Ejemplos: Cliente del Banco Cajero Sistema Link

45 AUS. Gustavo Torossi45 Caso de Uso Secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor. Describe una forma de utilizar el sistema. Funciones: Capturan requerimientos funcionales del sistema. Estructuran los modelos de objetos en vistas manejables. Un caso de uso puede tener varios caminos de acción o escenarios. Los casos de uso sirven como hilo conductor del proceso de desarrollo.

46 AUS. Gustavo Torossi46 Diagrama de Caso de Uso Cajero Automático

47 AUS. Gustavo Torossi47 Descripción textual CU Extracción – Camino Estandard 1Un mensaje de bienvenida está en espera en la pantalla del CA. 2El cliente inserta su tarjeta en el CA. 3El CA lee el codigo de la banda magnética y verifica que sea aceptable. 4Si la tarjeta es aceptable, el CA solicita al cliente su código PIN. 5El cliente ingresa su código PIN. 6Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar. 7El cliente selecciona y el CA envía el código PIN al Sistema bancario solicitando los datos de la cuenta del cliente. 8Los datos de la cuenta recibidos se despliegan en la pantalla. 9El cliente selecciona una cuenta y el monto a extraer. 10El CA envia al sistema bancario el requerimiento de extracción. 11El CA preparan los billetes a ser dispensados. 12El CA imprime el comprobante del movimiento. 13Los billetes son dispensados al cliente.

48 AUS. Gustavo Torossi48 Descripción textual

49 AUS. Gustavo Torossi49 Caso de Uso: Relaciones Inclusión: Secuencias comunes a varios casos de uso.

50 AUS. Gustavo Torossi50 Caso de Uso: Relaciones Extensión: Partes opcionales de un caso de uso.

51 AUS. Gustavo Torossi51 Caso de Uso: Relaciones Generalización: Distintas variantes de un caso de uso. (es un tipo de)

52 AUS. Gustavo Torossi52 Caso de Uso: Relaciones Ejemplo

53 AUS. Gustavo Torossi53 La Vista de Interacción

54 AUS. Gustavo Torossi54 La Vista de Interacción Representa como interactúan cooperativamente los objetos para implementar el comportamiento definido por los casos de uso. Colaboración: Interacción entre un conjunto de objetos para implementar un comportamiento del sistema. Una colaboración > la funcionalidad definida en un casos de uso. Interacción: Una interacción es un conjunto de mensajes que se intercambian dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación).

55 AUS. Gustavo Torossi55 Diagramas de Secuencia Énfasis en la secuencia cronológica de los mensajes.

56 AUS. Gustavo Torossi56 Diagrama de Colaboración Énfasis en la distribución física y relaciones de los objetos.

57 AUS. Gustavo Torossi57 La Vista de Máquina de Estados

58 AUS. Gustavo Torossi58 La Vista de Máquina de Estados Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida. Autómatas finitos con estados y transiciones. Cada objeto se trata en forma aislada, el que se comunica con el resto del mundo detectando eventos y respondiendo a ellos. Es útil modelar solo para objetos con comportamiento estado-dependiente. Uso de Diagramas de Estado.

59 AUS. Gustavo Torossi59 Diagramas de Estado Cada objeto está en un estado en cierto instante. El estado describe un período de tiempo caracterizado por: Conjunto de valores de atributos y relaciones del objeto. Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase. La transición entre estados es instantánea y se debe a la ocurrencia de un evento.

60 AUS. Gustavo Torossi60 Diagramas de Estado Estados y Transiciones A B Evento [condición] / Acción El evento se considera instantáneo

61 AUS. Gustavo Torossi61 Diagramas de Estado Ejemplo: Pila

62 AUS. Gustavo Torossi62 Eventos Acontecimiento significativo que tiene localización en tiempo y espacio. No tiene duración. Instantáneo Tipo de eventos Señal: comunicación asíncrona entre objetos. Llamada: invocación sincrónica de método del objeto que recibe el evento. Cambio: satisfacción de una condición lógica que depende de valores de un atributo. Tiempo: instante absoluto, o lapso transcurrido. Pueden modelarse con clases y jerarquías

63 AUS. Gustavo Torossi63 Acciones Una acción es un cómputo atómico y breve una sentencia de asignación una operación aritmética el envío de una señal a otro objeto la invocación de una operación propia asignación de valores de retorno creación o destrucción de objetos una secuencia de acciones simples Acciones específicas de entrada, salida, durante, un estado o por un evento estado A entry: acción por entrar exit: acción por salir do: acción mientras en estado on evento: acción

64 AUS. Gustavo Torossi64 Estados compuestos

65 AUS. Gustavo Torossi65 La Vista de Actividades

66 AUS. Gustavo Torossi66 La Vista de Actividades Variante de la máquina de estados para modelar flujos de trabajo. Utilización de diagramas de actividad. Caso particular de los diagramas de estado. Los estados representan estados de actividad no de un objeto.

67 AUS. Gustavo Torossi67 Diagrama de Actividades

68 AUS. Gustavo Torossi68 Calles y flujo de objetos

69 AUS. Gustavo Torossi69 Vistas Físicas

70 AUS. Gustavo Torossi70 Vista de Implementación Modela el empaquetado físico del sistema en unidades reutilizables llamadas componentes. Un componente es una unidad física de implementación con interfaces definidas pensada para ser utilizada como parte reemplazable del sistema. Cada componente implementa una o más clases del diseño. Incluyen código fuente, binario, o ejecutable. Los componentes se vinculan por relaciones de dependencia.

71 AUS. Gustavo Torossi71 Diagrama de Componentes

72 AUS. Gustavo Torossi72 Vista de Despliegue Modela la disposición física de los recursos de ejecución computacional (computadores, unidades de com., etc.) Nodo: es un objeto físico de ejecución que representa un recurso computacional. Pueden tener estereotipos (UCP, memorias, disk, etc.) Las asociaciones entre nodos representan líneas de comunicación. Se representan por diagramas de despliegue.

73 AUS. Gustavo Torossi73 Diagrama de Despliegue

74 AUS. Gustavo Torossi74 Diagrama de Despliegue

75 AUS. Gustavo Torossi75 La Vista de Gestión

76 AUS. Gustavo Torossi76 La Vista de Gestión La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes. Paquete: es una unidad de organización del modelo. Los paquetes ofrecen un mecanismo general para la organización de los modelos / subsistemas agrupando elementos de modelado. Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc. Todos los elementos del modelo deben pertenecer a un paquete. Los paquetes tambien pueden contener otros paquetes.

77 AUS. Gustavo Torossi77 La Vista de Gestión Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.) Por subsistema Por etapa del ciclo de desarrollo. Una buena organización refleja la arquitectura de alto nivel del sistema.

78 AUS. Gustavo Torossi vistas de Kruchten Vista Lógica Vista de Procesos Vista de Distribución Vista de Realización Vista de los Casos de Uso

79 AUS. Gustavo Torossi79 Dependencias de acceso / importación Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa El operador :: permite designar una clase definida en un contexto distinto del actual

80 AUS. Gustavo Torossi80 Dependencias de acceso / importación La dependencia de acceso no modifica el espacio de nombres del cliente. Solo concede permiso para establecer referencias. La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos.

81 AUS. Gustavo Torossi81 Modelo y Subsistema Un modelo es un paquete que abarca una descripción completa de una vista particular de un sistema. Proporciona una descripción cerrada de un sistema a partir de un punto de vista. Un subsistema es un paquete que tiene piezas separadas de especificación y de realización. Representa una partición del sistema.

82 AUS. Gustavo Torossi82 Proceso de Desarrollo

83 AUS. Gustavo Torossi83 Proceso de Desarrollo UML no prescribe ningún proceso de desarrollo. Sin embargo se recomienda un proceso: Dirigido por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental Ejemplo: Proceso Unificado (RUP)

84 AUS. Gustavo Torossi84 Ciclo de Vida

85 AUS. Gustavo Torossi85 Ciclo de Vida

86 AUS. Gustavo Torossi86 Ciclo de Vida

87 AUS. Gustavo Torossi87 Ciclo de Vida

88 AUS. Gustavo Torossi88 Herramientas CASE

89 AUS. Gustavo Torossi89 Herramientas CASE UML no es un leguaje de programación visual, pero sus modelos pueden conectarse directamente con una variedad de lenguajes. Forward & reverse engineering. Ingeniería de ida y vuelta.

90 AUS. Gustavo Torossi90 Herramientas CASE Rational Rose (www.rational.com) Rational XDE (www.rational.com) Borland Together (www.borland.com/together/) Embarcadero Describe (www.embarcadero.com/)

91 AUS. Gustavo Torossi91 Herramientas CASE - Libres Argo UML (argouml.tigris.org) Poseidon (www.gentleware.com) Dome (www.htc.honeywell.com/dome ) Comparativa:

92 AUS. Gustavo Torossi92 Bibliografía TítuloAutorISBN El Lenguaje Unificado de Modelado Manual de Referencia James Rumbaugh El Lenguaje Unificado de Modelado Guía del Usuario Grady Booch UML Gota a gotaMartin Fowler UML y PatronesCraig Larman

93 AUS. Gustavo Torossi93 Recursos en la Web UML Resource Center (www.rational.com/uml/index.jsp) The Rational Edge (www.therationaledge.com/)

94 AUS. Gustavo Torossi94 ¿ preguntas ?


Descargar ppt "AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi."

Presentaciones similares


Anuncios Google