Introducción a UML Información tomada de: - Jacobson et al, El proceso unificado de desarrollo de software

Transcripción

1 Introducción a UML Información tomada de: - Jacobson et al, El proceso unificado de desarrollo de software, Adison Wesley, Jacobson et al, El Lenguaje Unificado de Modelado. Manual de referencia, Adison Wesley, Ingeniería de software - 1

2 Conceptos de UML El lenguaje unificado de modelo, UML, es un lenguaje visual que se utiliza para especificar, visualizar, construir y documentar artefactos de un sistema de software, captura decisiones y conocimiento sobre los sistemas lo que permite entender, diseñar, hojear, configurar, mantener y controlar la información sobre los mismos. El objetivo de UML es especificar, diseñar, construir o entender sistemas de software complejos. UML no requiere un proceso de desarrollo particular, aunque fue diseñado para usarse con un proceso iterativo, incremental, guiado por casos de uso y centrado en la arquitectura. Es un estándar de la industria en general. Se ha diseñado realizado combinaciones de una gran cantidad de estándares. Permite modelar sistemas de información y permite generar modelos que contengan aspectos formales sin que resulten complicados por los usuarios a quienes se les modela. Ingeniería de software - 2

3 Conceptos de UML Desde el punto de vista técnico, se tienen las siguientes ventajas: Concurrencia. Ampliamente usado en la industria desde su adopción en OMG, Reemplaza a notaciones usadas en otros lenguajes. Modela estructuras complejas. Se fundamenta en metodologías orientadas a objetos. Emplea operaciones abstractas. Modela el comportamiento de sistemas. Ingeniería de software - 3

4 Conceptos de UML El término unificado significa: A través de los métodos históricos y notaciones: Combina conceptos comúnmente adoptados por muchos métodos orientados a objetos. Puede representar la mayoría de los modelos tan bien o mejor que como lo hacían los métodos originales. A través del ciclo de vida de desarrollo: No tiene saltos ni discontinuidades desde los requisitos hasta la implantación porque se usan los mismos conceptos y notación en las diferentes etapas del proyecto. A través de los dominios de la aplicación: está pensado para modelar la mayoría de los dominios de la aplicación, incluyendo aquellos que implican sistemas grandes, complejos, de tiempo real, distribuidos, con tratamiento intensivo de datos o con cálculo intensivo, entre otros. A través de los lenguajes de implementación y plataformas: Está pensado para ser usado en varios lenguajes de implementación y plataformas, incluyendo lenguajes de programación, bases de datos, 4GLs, documentos de organización, firmware, entre otros. A través de procesos de desarrollo: Es un lenguaje, no la descripción de un proceso de desarrollo detallado. Ingeniería de software - 4

5 Conceptos de UML Las áreas conceptuales de UML son: Estructura estática: Define los conceptos clave de la aplicación, sus propiedades internas y las relaciones entre cada una. Comportamiento dinámico: Unifica la estructura de los datos, el control de flujo y el flujo de los datos en una sola vista. Construcciones de implementación: Los modelo de UML tienen significado para el análisis lógico y para la implementación física. Ciertos constructores(componentes y nodos) representan elementos de implementación. Organización del modelo: Los sistemas grandes, la organización debe ser dividida en piezas coherentes. Los paquetes son unidades organizativas, jerárquicas, y de propósito general. Mecanismos de extensión: Aunque el núcleo del lenguaje no cambia, este permite una limitada dosis de extensión. Ingeniería de software - 5

6 Conceptos de modelos Un modelo es un representación, en cierto medio, del algo en el mismo u otro medio. Captan y enumeran exhaustivamente los requisitos y el dominio de conocimiento, de forma que todos los implicados pueden entenderlos y estar de acuerdo con ellos. Capta los aspectos importantes de lo modelado, desde cierto punto de vista, y simplifica u omite el resto. Los modelos de software tienen semántica y notación. El modelo pretende ser más fácil de usar para ciertos propósitos que el sistema final. Ingeniería de software - 6

7 Conceptos de modelos Se pueden usar varios tipos de modelos en UML: Para pensar el diseño de un sistema. Para capturar decisiones del diseño en una forma mutable a partir de los requisitos. Para generar productos aprovechables para el trabajo. Para organizar, filtrar, recuperar, examinar y corregir la información en grandes sistemas. Para explorar económicamente múltiples soluciones. Para domesticar los sistemas complejos. Ingeniería de software - 7

8 Conceptos de modelos Niveles de los modelos: Guías al proceso de pensamiento: Enfocan el proceso de pensamiento de los participantes y destacan determinadas opciones. Especificaciones abstractas de la estructura esencial de un sistema: Conseguir que los aspectos de alta nivel estén correctos. Especificaciones completas de un sistema final: Genera modelos de implantación. Descripciones completas o parciales de los sistemas. Ingeniería de software - 8

9 Conceptos de modelos Significado de un modelo: Abstracción frente a detalle: Un modelo captura los modelos esenciales de un sistema y omite otros. Especificación frente a implementación: Un modelo puede decir qué hace algo (especificación) y también cómo se logra la función (implementación). Descripción frente a instancia: Los modelos son sobre todo descripción. Las cosas que describen son las instancias. Variaciones en la interpretación: Los modelos pueden definir puntos de variación semántica. Ingeniería de software - 9

10 Vistas de UML Subconjunto de UML que modela construcciones que representan un aspecto de un sistema. En el nivel superior, las vistas se pueden dividir en tres áreas: clasificación estructural, comportamiento dinámico y gestión del modelo. Ingeniería de software - 10

11 Vistas de UML La clasificación estructural describe los elementos del sistema y sus relaciones. Los clasificadores pueden ser clases, casos de uso, componentes y nodos. La clasificación de las vistas incluye vista estática, vista de casos de uso y la vista de implementación. El comportamiento dinámico describe el comportamiento de un sistema en el tiempo real. En las vistas para este comportamiento se incluyen: vista de máquina de estados, la vista de actividad y la vista de interacción. La gestión del modelo describe la organización de los propios modelos en unidades jerárquicas, esta vista cruza a las otras y las organiza para el trabajo de desarrollo y el control de la configuración. Ingeniería de software - 11

12 Vistas de UML Área Vista Diagramas Conceptos principales Estructural Estática De casos de uso Implementación Clase, asociación, generalización, dependencia, Clases realización, interfaz Casos de uso Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso Componente, interfaz, dependencia, realización Componentes Despliegue Despliegue Componente, interfaz, dependencia, localización Máquina de estados Estados Estado, evento, transición, acción Dinámica Actividad Interacción Actividad Secuencia Colaboración Estado, actividad, transición de terminación, división, unión Interacción, objeto, mensaje, activación Colaboración, interacción, rol de colaboración, mensaje Gestión del modelo Extensión de UML Gestión del modelo Todas Clases Todos Paquete, subsistema, modelo Restricción, estreotipo, valores etiquetados Ingeniería de software - 12

13 Vista estática Ingeniería de software - 13

14 Vista de casos de uso Ingeniería de software - 14

15 Vista de interacción Ingeniería de software - 15

16 Vista de la máquina de estados Diagrama de detalles Ingeniería de software - 16

17 Vista de la máquina de estados Diagrama de actividades Ingeniería de software - 17

18 Vista de gestión del modelo Ingeniería de software - 18

19 Constructores de extensión Ingeniería de software - 19

20 La vista estática Los elementos de la vista estática de un modelo son los conceptos significativos en una aplicación, incluyendo conceptos del mundo real, conceptos abstractos, conceptos de computación, etc. Describe las entidades de comportamiento como elementos de modelado discretos, pero no contiene detalles de su comportamiento dinámico. Los elementos clave en la vista estática son: Clasificadores: Elemento del modelado que describe cosas. Relaciones: pueden ser asociación, generalización y dependencias. Ingeniería de software - 20

21 La vista estática La vista estática captura la estructura de los objetos que intervienen en un sistema. Los elementos clave en la vista estática son los clasificadores y las relaciones: Clasificador. Concepto discreto de modelo que tiene identidad, estado, comportamiento y relaciones. Tipos de relaciones: Asociación. Generalización. Realización. Dependencias. Ingeniería de software - 21

22 La vista estática Tipos de clasificadores(1) Ingeniería de software - 22

23 La vista estática Tipos de clasificadores(2) Ingeniería de software - 23

24 La vista estática Tipos de relaciones Ingeniería de software - 24

25 La vista estática Relación de asociación Lleva información sobre las relaciones entre objetos en un sistema. Cada conexión de una asociación a una clase se llama extremo de la asociación. Los extremos de una asociación pueden tener nombres (nombres de rol) y visibilidad. La propiedad más importante de una relación es la multiplicidad. Ingeniería de software - 25

26 La vista estática Relación de asociación Clase de asociación Propiedades del diseño de asociación Asociación calificada Ingeniería de software - 26

27 La vista estática Relación de asociación Agregación y composición: Una agregación es una relación todo-parte, una composición es una relación en la cual el compuesto es el único responsable de gestionar sus partes. Ingeniería de software - 27

28 La vista estática Relación de generalización La generalización es una relación taxonómica entre una descripción más general y una construcción más específica. La descripción más específica es consistente con la general. A la descripción más general se le llama padre y a la más específica hijo. Ingeniería de software - 28

29 La vista estática Relación de realización Conecta a un elemento del modelo con otro, especificando su comportamiento, pero no su estructura. Ingeniería de software - 29

30 La vista estática Relación de realización Hay una notación especial reducida para mostrar interfaces (sin su contenido) y las clases o componentes que las realizan. Ingeniería de software - 30

31 La vista estática Dependencias Indican una relación semántica entre dos o más elementos del modelo, Indican, además, una situación en la cual el cambio al elemento proveedor puede requerir o indicar un cambio en el significado del elemento cliente. Ingeniería de software - 31

32 La vista estática Dependencias Tipos: Ingeniería de software - 32

33 La vista estática Dependencias Tipos: Ingeniería de software - 33

34 La vista estática Restricciones Una restricción es una expresión booleana representada como una cadena interpretable en un determinado lenguaje. Ingeniería de software - 34

35 La vista estática Instancias / diagramas de objeto Una instancia es una entidad de ejecución con identidad. Un diagrama es una imagen de un objeto en un instante en el tiempo. Ingeniería de software - 35

36 La vista de casos de uso Captura el funcionamiento de un sistema, subsistema o clase, tal como se muestra al usuario exterior. Las piezas de funcionalidad interactiva se llaman casos de uso. Un caso de uso describe una interacción con los actores como secuencia de mensajes entre uno y más actores. Ingeniería de software - 36

37 La vista de casos de uso Tipos de relaciones de casos de uso Ingeniería de software - 37

38 La vista de casos de uso Relaciones de casos de uso Ingeniería de software - 38

39 La vista de la máquina de estados Describe el comportamiento dinámico de los objetos, en un cierto plazo, modelando los ciclos de vida de los objetos de cada clase. Un estado es un conjunto de los valores de un objeto para una clase dada, que tiene la misma respuesta cualitativa a los eventos que ocurren. Una máquina de estados es un gráfico de estados y transiciones, también pueden unir operaciones a los casos de uso y a las colaboraciones para describir su ejecución. Ingeniería de software - 39

40 La vista de la máquina de estados Un evento es una ocurrencia significativa que tiene una localización en tiempo y espacio. Tipos de eventos: Ingeniería de software - 40

41 La vista de la máquina de estados Ingeniería de software - 41

42 La vista de la máquina de estados Un estado describe un periodo de tiempo durante la vida de un objeto de una clase. Una transición define la respuesta de un objeto en ese estado a la ocurrencia de un evento. Un evento disparador es un evento cuya ocurrencia permite la transición. Cuando se dispara una transición, su acción(si la hay), es ejecutada. Una acción es un cómputo atómico y normalmente breve. Una condición de guarda es una expresión booleana. Se evalúa cuando ocurre el evento disparador, si dicha evaluación es verdadera, entonces se dispara la transición. Ingeniería de software - 42

43 La vista de la máquina de estados Ingeniería de software - 43

44 La vista de la máquina de estados Tipos de transiciones: Ingeniería de software - 44

45 La vista de la máquina de estados Un estado simple no tiene estructura, apenas un conjunto de transiciones y posiblemente acciones de entrada y salida, un estado compuesto es un estado que se ha descompuesto en subestados secuenciales o concurrentes. Ingeniería de software - 45

46 La vista de la máquina de estados Tipos de estado: Continúa... Ingeniería de software - 46

47 La vista de la máquina de estados Tipos de estado: (...Continuacón) Ingeniería de software - 47

48 La vista de la máquina de estados Ingeniería de software - 48

49 La vista de la máquina de estados Ingeniería de software - 49

50 La vista de actividades Un grafo de actividades es una forma especial de máquina de estados, prevista para modelar cómputo y flujo de datos. Los estados del grafo de actividades representan los estados de ejecución del cómputo, no los estados de un objeto ordinario. Un grafo de actividades asume que los cómputos proceden sin interrupciones externas por eventos. Los grafos de activados contienen estados de actividad. Dichos estados representan la ejecución de una sentencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. Un diagrama de actividades pueden contener bifurcaciones, así como divisiones de control en hilos concurrentes. Ingeniería de software - 50

51 La vista de actividades Ingeniería de software - 51

52 La vista de actividades Calles y flujos de objetos: Ingeniería de software - 52

53 La vista de interacción La vista de interacción prorporciona una versión integral del comporatamiento de un sistema de objetos. En esta vista se modela por colaboraciones. Una máquina de estados es estrecha y profunda, una colaboración es amplia, pero superficial. Una colaboración es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un contexto, describe una sociedad de objetos cooperantes unidos para realizar un cierto propósito. Una interacción es un conjunto de mensajes dentro de una colaboración que son intercambiados por roles de clasificador a través de roles de asociación. Ingeniería de software - 53

54 La vista de interacción Diagramas de secuencia Un diagrama de secuencia representa una interacción como gráfico bidemensional. La dimesión vertical es el eje del tiempo, la horizontal muestra los roles de clasificador que representan objetos individuales en la colaboración. Ingeniería de software - 54

55 La vista de interacción Activación Una activación es la ejecución de un procedimiento, incluyendo el tiempo que espera a los procedimientos anidados para ejecutarse. Ingeniería de software - 55

56 La vista de interacción Diagramas de colaboración Un diagrama de colaboración es un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Ingeniería de software - 56

57 La vista de interacción Diagramas de colaboración Hay que hacer varias consideraciones al usar diagramas de colaboración: Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales («parameter» o «local») o llamadas al mismo objeto («self»). Los objetos se pueden marcar en cuatro grupos: Los que existen con la intereacción entera. Los creados durante la interacción («new»). Los destruidos durante la interacción («destroyed»). Los que se crean y destruyen durante la interacción («transient»). Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Los flujos sirven para hacer explícitos los diversos estados de un objeto. Los diferentes símbolos de objeto que representan un objeto, se pueden conectar usando flujos «become» o «coversion» (en ambos casos, transiciones a partir de un estado de un objeto a otro). El esterotipo «copy» muestra un valor de objeto producido al copiar otro valor de objeto. Ingeniería de software - 57

58 La vista de interacción Patrones Un patrón es una colaborazión parametrizada, junto con las pautas sobre cuándo utilizarlo. Un parámetro puede sustituirse por diversos valores para producir distintas colaboraciones. Ingeniería de software - 58

59 Vistas físicas UML incluye dos tipos de vistas para representar unidades de implementación: La vista de implementación: muestra el empaquetado físico de las partes reutilizables del sistema en unidades sustituibles llamadas componentes. Muestra, además, las interfaces y dependencias entre componentes. La vista de despliegue: muestra la disposición física de los recursos de ejecución computacionales, tales como computadoras y sus interconexiones. Ingeniería de software - 59

60 Vistas físicas Un componente es una unidad física de implementación con interfaces bien definidas pensada para ser utilizada como parte reemplazable de un sistema. Los componentes bien diseñados no depdenden directamente de otros componentes sino de las interfaces que ofrecen los componentes. Ingeniería de software - 60

61 Vistas físicas Un nodo es un objeto físico de ejecución que representa un recurso computacional, que generalmente tiene por lo menos memoria y a menudo también capacidad de proceso. Las asociaciones entre nodos representan líneas de comunicación. Ingeniería de software - 61

62 Vistas físicas Diagrama de emplazamiento: Ingeniería de software - 62

63 La vista de gestión del modelo La gestión del modelo consiste en paquetes y relaciones de dependencias entre paquetes. Un paquete es una parte de un modelo. Contiene elementos del modelo al más alto nivel, tales como clases y sus relaciones, máquinas de estado, diagramas de casos de uso, interaciones y colaboraciones: cualquier elemento que no esté contenido en otro. Los paquetes pueden contener otros paquetes. Las dependencias entre paquetes resumen dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete son derivables a partir de las dependencias entre los elementos individuales. Ingeniería de software - 63

64 La vista de gestión del modelo Paquetes y sus relaciones: Ingeniería de software - 64

65 Mecanismos de extensión Los mecanismos de extensión existen con el fin de que los modeladores hagan algunas extensiones comunes sin tener que modificar el lenguaje de modelado subyacente. Estos mecanismos se dan por medio de las restricciones, valores etiquetados y estereotipos. Ingeniería de software - 65

66 Mecanismos de extensión Restricciones Una restricción es una condición semántica representada como expresión textual. Las restricciones expresan limitaciones y relaciones que no se pueden expresar usando la notación de UML. Ingeniería de software - 66

67 Mecanismos de extensión Valores etiquetados Un valor etiquetado es un par de cadenas -una cadena de etiquetas y una cadena de valor- que almacena parte de la información sobre un elemento. Ingeniería de software - 67

68 Mecanismos de extensión Estereotipos Un estereotipo es un tipo de elemento del modelo definido en el propio modelo. Se basa en elementos del modelo existentes. Los esterotipos se muestran como cadenas de texto entrecomilladas y van puestos dentro o cerca del símbolo normal del elemento. Ingeniería de software - 68

69 El entorno de UML Responsabilidades semánticas. Responsabilidades de notación. Responsabilidades del lenguaje de programación. Modelado con herramientas. Ingeniería de software - 69

70 El proceso unificado de desarrollo de software Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requisitos de usuario en un sistema de software. Es un marco de trabajo genérico que puede especializarse en una gran variedad de sistemas de software. UML es una parte esencial de este proceso. El proceso está basado en componentes, esto es, el sistema de software en construcción está formado por componentes software interconectados con interfaces bien definidas. El proceso unificado Es dirigido por casos de uso Está centrado en la arquitectura Es iterativo e incremental Ingeniería de software - 70

71 El proceso unificado de desarrollo de software Dirigido por casos de uso: Un sistema de software ve la luz para dar servicio a usuarios. El término usuario no sólo hace referencia a otros usuarios, sino también a otros sistemas. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Representa los requisitos funcionales. Todos los casos de uso constituyen un modelo de casos de uso. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo. Los casos de uso se especifican, se diseñan, y los casos de uso son la fuente a partir de la cual los ingenieros de prueba construyen casos de prueba. Aunque es cierto que los casos de uso guían el proceso, no se desarrollan aisladamente. Ingeniería de software - 71

72 El proceso unificado de desarrollo de software Está centrado en la arquitectura: La arquitectura de un sistema de software se describe mediante diferentes vistas del sistema en construcción; es una vista del diseño completo con las características más importantes realzadas, sin importar los detalles. Esta incluye los aspectos estáticos y dinámicos más significativos del sistema, surge de las necesidades de la empresa, como la perciben los usuarios y los inversionistas, y se refleja en los caso de uso. Cada producto tiene una función y una forma, ninguna es autosuficiente, la función corresponde a los caso de uso, mientras que la forma a la arquitectura, debe haber interacción entre los casos de uso y la arquitectura, esto es, evolucionar en paralelo. Ingeniería de software - 72

73 El proceso unificado de desarrollo de software Es iterativo e incremental: Es práctico dividir el trabajo en miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen refrencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Las iteraciones deben estar controladas. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada, implementan el diseño mediante componentes, y verfican que los componentes satisfagan los casos de uso. Si una iteración cumple con sus objetivos el desarrollo continúa con la siguiente. La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los casos de uso definen los objetivos y dirigen el trabajo de cada iteración. Ingeniería de software - 73

74 El proceso unificado de desarrollo de software Cada ciclo produce una versión del sistema, y cada versión es un producto preparado para su entrega. Aunque los componentes ejecutables sean los artefactos más importantes desde la perspectiva del usuario, no son suficientes por si solos. Para llevar a cabo el ciclo siguiente de manera eficiente, los desarrolladores necesitan todas las representaciones del producto de software. Ingeniería de software - 74

75 El proceso unificado de desarrollo de software Fases dentro de un ciclo: Ingeniería de software - 75

76 El proceso unificado de desarrollo de software El resultado de un proyecto software es un producto que toma forma durante su desarrollo gracias a la intervención de muchos tipos distintos de personas. Un proceso de desarrollo de software guía los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que explica los pasos necesarios para terminar el proyecto. Típicamente el proceso está automatizado por una herramienta o un conjunto de ellas. Ingeniería de software - 76

77 El proceso unificado de desarrollo de software Cuando se diseñó UML, se identificaron todos los trabajadores y cada una de las perspectivas que podrían necesitar. La construcción de un sistema es un proceso de construcción de modelos, donde cada uno de ellos describe todas las perspectivas diferentes del sistema. Ingeniería de software - 77

78 El proceso unificado de desarrollo de software Un sistema contiene todas las relaciones y restricciones entre elementos incluidos en diferentes modelos. Cada caso de uso, en el modelo de casos de uso, tiene una relación con una colaboración en el modelo de análisis (y viceversa). Esa relación se llama en UML dependencia de traza, o simplemente traza. Ingeniería de software - 78