1 Repaso de UML Análisis y Diseño de Sistemas de Información II Enero de 2004.

Presentación del tema: "1 Repaso de UML Análisis y Diseño de Sistemas de Información II Enero de 2004."— Transcripción de la presentación:

1 1 Repaso de UML Análisis y Diseño de Sistemas de Información II Enero de 2004

2 2 Objetivo Al finalizar el repaso los participantes recordarán el uso de todos los diagramas de UML para realizar modelos visuales orientados a objetos para generar proyectos de software de mayor calidad.

3 3 Contenidos del Taller 1. Introducción 2. Diagrama de Actividades 3. Modelo de Casos de Uso 4. El Modelo Conceptual y el Análisis de Sustantivos 5. Diagramas de Interacción 6. Diagrama de Clases 7. Diagrama de Estados 8. Modelo de Componentes 9. Modelo de Distribución

4 4 Introducción

5 Qué Necesita el Usuario

6 6 Qué Pidió el Usuario

7 7 Cómo lo Vio el Analista

8 8 Cómo se Diseñó

9 9 Cómo lo Escribió el Programador

10 10 Cómo Funciona el Sistema (en ocasiones...)

11 11 La Moraleja La moraleja de la historia  Comunicación  Efectiva comunicación multi- disciplinaria La Torre de Babel  Cada participante maneja su propio lenguaje

12 12 El Proceso de Desarrollo “Escribir código es sólo una parte del total de esfuerzo de desarrollo”

13 13 Análisis Orientado a Objetos con UML

14 14 Diagramas de Actividad Modelado de Negocios y Comportamiento de Casos de Uso

15 15 Objetivo El alumno aprenderá a describir un proceso utilizando los diagramas de actividad Entenderá los elementos que conforman un diagrama de actividad Aprenderá a describir escenarios y procesos utilizando diagramas de actividad

16 16 Utilidad Modelar el flujo de trabajo de un proceso de negocio Modelar información de codificación específica (Operación de una Clase) Modelar la secuencia de actividades dentro de un proceso

17 17 Propósito Entender la estructura y dinámica de una organización Asegurar que los clientes, usuarios finales y desarrolladores tienen un entendimiento común de la organización Determinar requerimientos sobre el sistema que den soporte a la organización

18 18 Elementos Estados y Actividades Transición de Estados Sincronizaciones Decisiones Carriles Objetos y Flujos de Objetos

19 19 Estados y Actividades Estado Inicial  Muestra el principio de un flujo de trabajo Actividad  Representa el desarrollo de una tarea dentro del flujo de trabajo Estado Final  Muestra el término de un flujo de trabajo en un diagrama de actividad Estado Inicial Actividad Estado Final

20 20 Transición  Paso de una actividad a otra al ser completada Estado Inicial Estado Final Actividad 1Actividad 2

21 21 Sincronizaciones Ver un flujo de trabajo simultaneo Definen bifurcaciones y uniones Se representan mediante barras horizontales o verticales

22 22 Decisiones Lugar específico donde el flujo de trabajo puede ramificarse según una condición de guarda Pueden existir más de dos transacciones salientes, aunque la mayoría de las decisiones tendrán sólo dos

23 23 Carriles Útiles para modelar flujos de trabajo de negocio Similares a un objeto Indican responsable de ejecutar una actividad específica

24 24 Objetos y Flujos de Objetos Objeto  Representan algo tangible  Diagramar relaciones de entrada y salida entre actividades Flujo de Objeto  Representa la relación entre una actividad y el objeto que la crea (como una salida) o usa (como una entrada)

25 25 Diagrama de Actividad

26 26 Ejercicio Modele un diagrama de actividad para el caso de estudio

27 27 Conclusiones El diagrama de actividades se utiliza para mostrar la secuencia de pasos en un proceso, en un caso de uso o en una operación Puede utilizarse para analizar y modelar procesos de negocio Permite mostrar los cambios de estados al entrar o salir de una actividad

28 28 El Modelo Conceptual y el Análisis de Sustantivos El Análisis del Dominio

29 29 Objetivos El alumno aprender á a identificar los conceptos del negocio y los datos que los definen. Aprender á a desarrollar un modelo conceptual para representar gr á ficamente los conceptos importantes de un dominio.

30 30 Modelo Conceptual Es la representaci ó n de conceptos en el dominio de un problema.  Muestra los conceptos relevantes en el dominio de un problema. La identificaci ó n de los conceptos del negocio es la base para el desarrollo orientado a objetos. Su prop ó sito en esta fase consiste en clarificar el dominio o las reglas del negocio.

31 31 Elementos del Modelo Conceptual Los elementos que se muestran en un modelo conceptual son:  Conceptos  Atributos  Asociaciones entre conceptos El artefacto que se utiliza en UML para representar el modelo conceptual es el diagrama de clases

32 32 Representación del Mundo Real Una característica básica de un modelo conceptual es que es una representación de cosas del mundo real, NO de elementos de software BaseDeDatosDeVenta Venta Fecha Total Venta Fecha Total Imprimir ( )

33 33 Concepto Es cualquier cosa, idea u objeto del mundo real PersonaEmpresa

34 34 Atributos de Conceptos Son los datos simples que representan las caracter í sticas de un concepto (objeto) Persona Nombre Edad Empresa Razón Social RFC

35 35 ¿Atributo o Concepto? Un error bastante común en los modelos conceptuales consiste en presentar los conceptos como atributos de otros conceptos.  Si no pensamos en un atributo como algo simple, tal como un texto o un número, entonces lo más probable es que se trate de un concepto.  Ante la duda es mejor ponerlo como concepto, en lugar de atributo. Dirección Calle Colonia Empresa Razón Social RFC

36 36 Llaves Foráneas como Atributos Los atributos no deberían de ser usados para relacionar conceptos en el modelo conceptual ¿¿¿Llaves Foráneas??? !! NO !! Tarjeta Clave NumeroCuenta Cuenta Numero Tarjeta Clave 11 Pertenece Tarjeta

37 37 Asociaciones entre Conceptos Muestran la relaci ó n l ó gica o f í sica que existe en el mundo real entre dos conceptos. Se puede nombrar a las asociaciones para clarificar el modelo Persona Nombre Edad Empresa Razón Social Dirección Emplea-a

38 38 Multiplicidad Describe cu á ntas instancias de un concepto (objeto) existen con respecto a otro objeto en una asociaci ó n en un momento dado. Persona Nombre Edad Empresa Razón Social Dirección Emplea-a1..*1

39 39 Multiplicidades ¿Cuántas instancias participan en la relación?  exactamente 1  exactamente 3  desde 1 hasta 5  exactamente 3, 5 ó 10  cero o más  1 o más Concepto 1 3 1..5 Concepto 3,5,10 Concepto n * 1..*

40 40 Identificaci ó n de Conceptos Se obtienen a partir de casos de uso y documentos con informaci ó n del problema  Puede utilizarse la t é cnica de an á lisis de casos de uso.  Es mejor sobre especificar un modelo conceptual con conceptos muy granulares a que falten conceptos.

41 41 Análisis de Casos de Uso Es el proceso de examinar los casos de uso para descubrir objetos y clases para el sistema a desarrollar  Selecciona un caso de uso  Identificación de conceptos 1. Sacar una lista de los sustantivos 2. Clasificar los sustantivos en objetos, actores, clases, atributos o ninguno 3. Seleccionar conceptos o clases candidatos 4. Para los objetos abstraer sus clases correspondientes  Representar los conceptos y atributos en un diagrama de clases

42 42 Lectura del Modelo Conceptual Una regla no escrita es que el modelo se lee de arriba hacia abajo y de izquierda a derecha Aerolínea PersonaVueloAvión 1 Emplea 1..* 1* Asignada-a *1 Asignado-a 1* Supervisa El nombre de la asociación comienza con mayúscula y si arma una frase se separa con guión

43 43 Glosario de T é rminos El glosario de t é rminos es un artefacto de RUP que sirve para especificar el significado de los t é rminos manejados en el proyecto  Incluye la definici ó n de los conceptos y atributos Es un diccionario de t é rminos donde se describe de forma breve los t é rminos o conceptos manejados en el negocio. Es necesario para que tanto usuarios como desarrolladores manejen la misma terminolog í a.

44 44 Glosario de T é rminos ConceptoDefinición Empresa Entidad constituida legalmente que se crea para comercializar productos o servicios Empleado Persona que ofrece sus servicios a una empresa a cambio de una retribución económica Dirección Ubicación de la empresa, que consta de Colonia, Calle, Delegación y Ciudad

45 45 Descripci ó n de Actores Como parte del glosario de t é rminos se tiene que describir de forma breve a los actores. ConceptoDefinición Administrador Usuario del sistema que mantiene los catálogos de la empresa Gerente de Recursos Humanos Persona que dirige el área de RH y que está autorizada para realizar movimientos críticos del área en la empresa, tales como la generación de la nómina

46 46 Ejemplo Desarrollar el modelo conceptual del caso de estudio.

47 47 Conclusiones Un concepto es cualquier cosa idea u objeto El modelo conceptual es la representación de los conceptos del mundo real relevantes en el dominio Un concepto modelado para el sistema debe representar información útil dentro del contexto analizado Los atributos son los datos simples que describen al concepto Dos conceptos están asociados cuando existe una relación entre ellos en el contexto analizado

48 48 Conclusiones La multiplicidad entre dos conceptos indica el número de repeticiones de un concepto en relación al otro El análisis de sustantivos es la técnica utilizada para identificar posible conceptos del dominio a partir de los sustantivos identificados en los casos de uso y otros documentos El glosario de términos es el artefacto donde se describe y estandariza el significado de la terminología o conceptos del sistema a desarrollar

49 49 El Modelo de Casos de Uso El Eje de la Calidad

50 50 Objetivos El alumno aprenderá a describir el comportamiento general de un sistema por medio de casos de uso Entenderá qué es un actor y cómo representar su interacción con el sistema Comprenderá las formas de granularizar los casos de uso Conocerá los mecanismos de extensión de UML en los diagramas de casos de uso

51 51 Diagrama de Casos de Uso Muestra el Comportamiento del Sistema Muestra el Alcance del Sistema Interacciones con entidades externas Mantenimiento ATM Operador ATM Conducir Transacciones Bancarias Correr Reportes ClienteSist.Bancario

52 52 Elementos del Diagrama de Casos de Uso Actor Caso de Uso Asociación

53 53 Actor Actores No son parte del sistema, representan roles que un usuario puede jugar Intercambian información con el sistema Puede ser un recipiente pasivo de información Puede representar un humano, una máquina u otro sistema Se nombran generalmente con sustantivos en singular  Cliente, vendedor, administrador, alumno, Sistema de nómina, etc.

54 54 Carlos saca dinero de su cuenta y le da mantenimiento al sistema 1 2 3 4 5 6 7 8 9 * 0 # Inserta tarjeta Operador Cliente Carlos como cliente Carlos como Operador Un Usuario/Dos Actores

55 55 Carlos saca dinero de su cuenta y Roberto saca de la suya 1 2 3 4 5 6 7 8 9 * 0 # Inserta tarjeta Cliente Carlos como cliente Dos Usuarios/Un Actor Roberto como cliente

56 56 Caso de Uso Casos de Uso Un caso de uso modela el diálogo entre los actores y el sistema Un caso de uso es iniciado por un actor al invocar cierta funcionalidad en el sistema Un caso de uso es un flujo de eventos completo y con significado para el usuario Un caso de uso debe proporcionar valor real al usuario Al unir todos los casos de uso se tienen todas las formas posibles de usar el sistema Se nombran generalmente con un verbo en infinitivo:  Realizar venta, Cotizar seguro, Generar nómina, etc.

57 57 Mantenimiento ATM Operador ATM Conducir Transacciones Bancarias Correr Reportes ClienteSist. Bancario Cajero Automático

58 58 Granularidad de los Casos de Uso ¿Realizar Ventas es demasiado genérico? ¿Es suficientemente claro para los stakeholders? Realizar Venta Vendedor Aplicar Descuento Autorizar Crédito ?????

59 59 Estereotipos Mecanismos para extender el significado de los elementos de UML  Algunos existentes en UML  El desarrollador puede crear nuevos Se escribe entre “ > ” y se coloca junto al elemento de UML a extender >

60 60 Estereotipos para Casos de Uso Dentro de la especificaci ó n de UML el modelo de casos de uso incluye estereotipos para especificar con mayor claridad la relaci ó n entre los casos de uso >

61 61 Relaci ó n Include Indica que un caso de uso incluye dentro de su funcionalidad a otro caso de uso  ¿ Es suficientemente obvio si el caso de uso Realizar Venta incluye la Autorizaci ó n de Cr é ditos o es necesario hacerlo expl í cito? Realizar Venta Vendedor Autorizar Crédito >

62 62 Caso de Uso Base e Inclu í do El Caso de Uso inclu í do forma parte del caso de uso base Realizar Venta Vendedor Caso de Uso Base Caso de Uso Incluído Autorizar Crédito >

63 63 Relaci ó n Extend Cuando un caso de uso extiende a otro caso de uso, significa que le agrega pasos o actividades adicionales, pero el caso de uso base est á completo a ú n si no existiera el que lo extiende Realizar Venta Vendedor Aplicar descuento >

64 64 Paquetes Los paquetes sirven para agrupar de una manera l ó gica elementos de UML y reducir la complejidad  Casos de uso  Clases  Componentes

65 65 Paquetes de Casos de Uso NóminaAdministración Un paquete de casos de uso representa agrupación lógica de funcionalidad. Ejemplo: módulos, subsistemas, sistemas.

66 66 Ejercicio Desarrollar un diagrama de casos de uso con todos sus elementos para el caso de estudio.  Actores  Casos de uso  Relaciones entre actores y casos de uso  Relaciones > y > entre casos de uso

67 67 Conclusiones El diagrama de casos de uso muestra el comportamiento del sistema y las interacciones con las entidades externas Los tipos de relaciones entre casos de uso están definidos por los estereotipos extends e includes Un actor es una entidad externa que interactúa con el sistema Un caso de uso es un conjunto de interacciones entre el sistema y uno o más actores Los casos de uso se pueden agrupar en paquetes para reducir la complejidad y organizarlos en subsistemas y módulos

68 68 Documentación de Casos de Uso Flujos de Eventos y Glosario de Términos

69 69 Objetivos El alumno aprender á a documentar los requerimientos del sistema mediante el uso de flujos de eventos y escenarios Entender á la estructura de un flujo de eventos Comprender á la ventaja de los flujos de eventos sobre el enfoque basado en listas de requerimientos Comprender á el uso que tiene este artefacto para mejorar la comunicaci ó n entre las partes involucradas en el proyecto

70 70 Documentación de los Casos de Uso Los casos de uso se documentan con:  Una breve descripción El propósito del caso de uso en unas cuantas líneas  El flujo detallado de los eventos Descripción detallada de eventos Terminología y redacción simple orientada al negocio/usuario

71 71 Estructura de los Flujos de Eventos Las secciones que forman el flujo de eventos de un caso de uso:  Precondiciones  Flujo Principal  Flujos Alternos  Flujos Excepcionales  Postcondiciones

72 72 Precondiciones Es el estado en que se encuentra el sistema antes de iniciar el caso de uso, y que es necesario para poder llevarlo a cabo exitosamente  Generalmente son aspectos que no van a ser validados durante el caso de uso, sino que se dan por ciertos  Ejemplo: Precondiciones para Retirar Efectivo:  Que el cajero cuente con efectivo  Que el cliente haya accesado a su cuenta  Que haya conecci ó n con el sistema bancario central

73 73 Contenido del Flujo de Eventos Describe sólo los eventos que ocurren dentro del caso de uso y no lo que pasa en otros casos de uso Evita terminología vaga como por ejemplo, “información” y “etc.” El flujo de eventos debe describir:  Cómo y cuándo comienza y termina el caso de uso  Cuándo interactúa el sistema con el actor en el caso de uso  Qué información es intercambiada entre un actor y el sistema No describir los detalles de la interface de usuario  El flujo básico de eventos  Cualquier flujo alterno

74 74 Cada caso de uso –Tiene un flujo primario, normal de transacciones, pasos o interacciones (el happy path) –Puede tener varios flujos alternos –Normalmente tiene flujos excepcionales de eventos para el caso de situaciones erróneas Tipos de Secuencias o Flujos Flujo principal Flujos excepcionales Flujos alternos

75 75 Post Condiciones Es el estado en el que debe quedar el sistema despu é s de haber llevado a cabo exitosamente un caso de uso  En Retiro de Efectivo: La cuenta del cliente queda reducida con el monto retirado La transacci ó n queda registrada en el log del cajero

76 76 Usuarios de los Casos de Uso Clientes – validan que los desarrolladores comprendieron el problema Usuarios – clarifican sus ideas respecto al problema Desarrolladores – comprenden lo que el usuario espera del sistema a desarrollar Revisores – verifican la calidad de los requerimientos Analistas y diseñadores – base para el análisis y el diseño Tester – a partir de estos validan que el sistema hace lo que el cliente/usuario pidió Líder de proyecto – es la base para el plan de trabajo Documentador – lo usan como base aproximada de un manual de usuario

77 77 Prototipo GUI Facilita el levantamiento de requerimientos  Al usuario y a los desarrolladores les ayuda a aterrizar y esclarecer ideas  Reduce riesgos de requerimientos mal entendidos Realizarlos en paralelo con los casos de uso

78 78 El Prototipo y el Caso de Uso Caso de Uso: Cotizar Seguro de Vida Descripción: El caso de uso comienza cuando el ejecutivo registra los datos del asegurado, el sistema utiliza los parámetros de cotización para indicar el monto...

79 79 Ejercicio Desarrollar para el caso de uso especificado:  Las precondiciones  El flujo de eventos primario  Los flujos de eventos alternos  Un flujo excepcional  Las postcondiciones

80 80 Conclusiones Los flujos de eventos son la forma en que se describen textualmente y a detalle los casos de uso Los flujos de eventos permiten especificar el funcionamiento del sistema Es uno de los principales artefactos de entrada utilizados por los diferentes stakeholders Los prototipos GUI facilitan la identificaci ó n de requerimientos y casos de uso, y ayudan a eliminar riesgos tempranamente

81 81 Diseño Orientado a Objetos

82 82 Diagramas de Interacción El Diagrama de Secuencia y de Colaboración

83 83 Objetivos Aprender cómo modelar la estructura dinámica de un sistema Aprender a desarrollar un diagrama de secuencia para modelar el comportamiento de los objetos en un sistema Aprender a desarrollar un diagrama de colaboración Entender las diferencias y similitudes entre los 2 tipos de diagramas de interacción

84 84 Diagrama de Interacción Son los artefactos de UML mediante los cuales se modelan las interacciones entre las clases para llevar a cabo (o realizar) un caso de uso, una parte de este o un escenario en particular. Es la representación gráfica de un flujo de eventos.

85 85 Tipos de Diagramas de Interacción Existen 2 tipos de diagramas de Interacción:  Diagramas de Secuencia  Diagramas de Colaboración Cada uno de estos diagramas se enfoca en ciertos aspectos especiales del sistema.

86 86 Diagramas de Interacción Diagrama de SecuenciaDiagrama de Colaboración

87 87 Diagrama de Secuencia Es el artefacto de UML que se utiliza para mostrar las interacciones entre los objetos, enfocándose en el orden o la secuencia de pasos del caso de uso.

88 88 Elementos del D. de Secuencia

89 89 Objetos y Clases Existen 3 formas de mostrar un objeto o clase en un diagrama de secuencia Únicamente el nombre del objeto o instancia nombre del objeto y clase asociada Únicamente el nombre de la clase

90 90 Línea de Vida Línea vertical punteada que representa la existencia de un objeto en un momento determinado. Es posible indicar la creación y destrucción del objeto. :Avion :Vuelo create destroy

91 91 Mensaje Las flechas que van de una línea de vida a otra son mensajes entre los objetos  El objeto que recibe el mensaje es el servidor y el que envía el mensaje es el cliente Un mensaje puede corresponder a una operación en una clase o a un trigger en un diagrama de estados :Avion:Vuelo Asignar (IdAvion) Vuelo Asignar (IdAvion) VerificarSalida ()

92 92 Foco de Control Periodo de tiempo en el que un objeto está realizando una acción, ya sea directamente o mediante un procedimiento subordinado Foco de control del procedimiento Asignar(IdAvion) Tiempo en que se está ejecutando Asignar(IdAvion) :Avion:Vuelo Asignar (IdAvion) :Plan Verificar (IdAvion)

93 93 Foco de Control Jerárquico Sirve para remarcar el control que tiene un subprocedimiento de un objeto :Avion:Vuelo Asignar (IdAvion) Foco de control del procedimiento Asignar(IdAvion) Tiempo en que se ejecuta VerificarSalida VerificarSalida ( )

94 94 Notación de Mensajes [predecesor]+[condición de guardia]+[variable :=]+mensaje (parámetros) :Avion:Vuelo 1. blnVueloAbierto:= FueAbierto (IdVuelo:Integer):Boolean 1.1 VerificarSalida ( ) 2. [blnVueloAbierto] Asignar (IdAvion)

95 95 Numeración de Mensajes Enteros secuenciales Jerárquicos :Cajero:Cuenta 1. AplicarRetiro ( ) 3. CrearTransaccion ( ) :PersCuenta 2. ValidarCuenta ( ) :Cajero:Cuenta 1. AplicarRetiro ( ) 1.2. GuardarTransaccion ( ) :PersCuenta 1.1. ValidarCuenta ( )

96 96 Numeración de Mensajes Sin numeración Alternativos :Cajero:Cuenta AplicarRetiro ( ) CrearTransaccion ( ) :PersCuenta ValidarCuenta ( ) :Cajero:Cuenta 1. AplicarRetiro ( ) 1.1b. [Not NIPValido]CrearTransaccion ( ) :PersCuenta 1.1a. [NIPValido]ValidarCuenta( )

97 97 Mensajes Iterativos Para expresar que un mensaje se envía repetidamente al objeto receptor se utiliza un ‘*’ :POST:Venta 1*: li:= siguienteRenglonVenta():RenglonVenta :POST :Venta 1*: [i:=1..10]li:= siguienteRenglonVenta():RenglonVenta

98 98 Mensajes Mensaje Llamada a procedimiento Retorno de una llamada a procedimiento AsignarVuelo (IdVuelo) Verificar edad del empleado AsignarVuelo (IdVuelo)

99 99 Relación entre el Diagrama de Secuencia y el de Clases

100 100 Ejercicio Desarrollar el diagrama de secuencia del caso de uso especificado.

101 101 Diagrama de Colaboración Al igual que el diagrama de secuencia modela las interacciones entre las clases, y entre actores y clases en un caso de uso o escenario. A diferencia de los diagramas de secuencia que dan más énfasis al orden de los pasos, este se enfoca más en la parte estructural o la relación entre las clases.

102 102 Diagrama de Colaboración Ligas

103 103 Objetos y Clases Indica el objeto y/o clase que interviene en la interacción Puede estar descrito de 3 formas diferentes:  :Clase  Objeto  Objeto:Clase

104 104 Colecciones de Objetos En el diagrama de colaboración las colecciones de objetos aparecen gráficamente con la siguiente notación Representan grupos de objetos con multiplicidad mayor a uno

105 105 Colecciones de Objetos Colección en Diagrama de Clases Colección en Diagrama de Colaboración

106 106 Ligas Sirve para indicar que dos objetos pueden realizar interacciones entre sí  Junto a la liga se indica cada uno de los mensajes que se envían los objetos

107 107 Mensajes Es una llamada de un objeto a otro Se coloca junto a la liga entre dos objetos Una liga puede servir como medio para transmitir más de un mensaje Un mensaje puede representar una operación del objeto receptor Un mensaje puede ser reflexivo, cuando el cliente y el servidor es la misma clase

108 108 Analogías Diagrama de SecuenciaDiagrama de Colaboración

109 109 Ejercicio Desarrollar el Diagrama de Colaboración del caso de uso especificado.

110 110 Conclusiones Los diagramas de interacción muestran la forma en que se da la comunicación entre las clases participantes en un caso de uso o escenario. Existen 2 tipos de diagramas de interacción: de secuencia y de colaboración. Cada uno de los tipos de diagramas de colaboración se enfoca a aspectos específicos de la colaboración entre los objetos.

111 111 El Diagrama de Clases La Estructura Estática del Sistema

112 112 Objetivos Conocer los elementos de UML para modelar un diagrama de clases El alumno podrá desarrollar un diagrama de clases con base en los artefactos generados durante el análisis El alumno conocerá los elementos de un diagrama de clases

113 113 Diagrama de Clases Es el artefacto principal en el desarrollo orientado a objetos Muestra las clases en las que se implementará el sistema, sus relaciones, atributos y operaciones

114 114 Elementos en un Diagrama de Clases (1/2) Clases Atributos Operaciones Scope o alcance de atributos y operaciones

115 115 Elementos en un Diagrama de Clases (2/2) Relaciones Elementos de las Asociaciones y Agregaciones  Navegabilidad  Roles  Multiplicidad Visibilidad entre clases

116 116 Atributos Descripción de un dato que define a una clase El atributo debe tener especificado un nombre, tipo de dato y scope Cada objeto instanciado de una clase tiene su propio valor para el atributo

117 117 Operaciones Especificación de una transformación o query que puede ser solicitado a un objeto Consta de un nombre y una serie de parámetros (firma de la operación) Un método es la implementación de una operación

118 118 Scope de Atributos y Operaciones Es la visibilidad que tienen las clases hacia los atributos y operaciones de una clase con la cual están relacionadas. Existen 3 tipos de scope:  Público  Privado  Protegido

119 119 Control de Acceso y Encapsulamiento El control de acceso se emplea para reforzar el encapsulamiento

120 120 Especificación del Control de Acceso Se pueden usar símbolos de acceso en una clase para indicar la accesibilidad a sus atributos y operaciones  + Acceso Público  # Acceso Protegido  - Acceso Privado El acceso es concedido, de manera explícita, por la misma clase y no forzado por el cliente

121 121 Especificación del Control de Acceso Curso - maxAlumnos - Nombre + agregarAlumno () + estaLleno () # determinarTamañoCurso ()

122 122 Tipos de Relaciones entre Clases Asociación Agregación y Composición Generalización Dependencia Curso Diplomado Modulo Alumno

123 123 Asociación Es la relación más simple entre dos clases Indica que 2 clases pueden verse o solicitar sus servicios

124 124 Clases Asociación Una clase asociación contiene información perteneciente a un vínculo entre objetos Alumno Curso 3..10 4 Calificación Promedio

125 125 Roles En términos de análisis indica el rol que toma una clase con respecto a otra en una relación de asociación En términos de implementación es el nombre de la instancia u objeto que se utilizará para solicitar los servicios de la clase y para asignarle valores a sus atributos

126 126 Navegabilidad La asociación sin flechas indica que ambas clases pueden verse y comunicarse entre sí Pero, en ocasiones no es necesario eso, sino que una sola clase es la que requiere comunicarse con la otra, en este caso indicamos que existe navegabilidad hacia un solo lado por medio de una punta de flecha al final de la asociación

127 127 Agregación Es una clase especial de asociación donde una clase “contiene” a otra clase, o donde una clase “es parte de” otra clase  Un Motor “contiene” Válvulas (o las válvulas son parte del motor)

128 128 Composición Es un tipo de agregación más sólido donde las partes sólo existen cuando existe el contenedor  Una mano está compuesta de dedos Si la mano desaparece los dedos no sirven de nada Sólo puede ser parte de un contenedor

129 129 Herencia Es una relación donde una clase es un tipo especial de otra clase. Es decir, tiene todas las características (atributos, operaciones y relaciones) de la súperclase más otras especiales  Un carro es un tipo especial de transporte Existen dos formas de identificar la herencia:  Generalización  Especialización

130 130 Generalización Cuando obtenemos características comunes de varias clases para crear una súperclase de la cual van a heredar todas las subclases las características comunes Carro Motor Llantas Barco Motor Aspas

131 131 Generalización Transporte Motor Carro Llantas Barco Aspas

132 132 Especialización Es la técnica mediante la cual se identifica que una clase puede comportarse o tener características diferentes dependiendo de cierta situación o condición  Identificamos cuáles son las características que nunca cambian y las dejamos en una súperclase, y las características especiales las ponemos en nuevas clases llamadas subclases Transporte Motor Llantas Aspas Transporte Motor Carro Llantas Barco Aspas

133 133 Dependencia Es un tipo de relación menos duradera que una asociación o una agregación  La comunicación sólo es posible en momentos específicos de la clase dependiente (p.ej. cuando instancía o recibe como parámetro a la 2a clase)

134 134 Visibilidad Existen cuatro opciones de visibilidad  Global El objeto servidor es un objeto global  Parámetro El objeto servidor es un parámetro de una operación del objeto cliente  Local El objeto servidor se declara localmente  Campo El objeto servidor es un campo contenido en el objeto cliente

135 135 Visibilidad Indica cómo y bajo que circunstancias pueden comunicarse dos clases relacionadas VisibilidadTipo de Relación Globaldependencia Por parámetrodependencia Localdependencia Por campoasociación, agregación o composición

136 136 Elaboración del Diagrama de Clases Identificar operaciones y su scope (usar d. de interacción) Identificar atributos con su tipo de dato y scope Identificar relaciones entre clases (usar d. de interacción) Organizar clases en paquetes lógicos

137 137 Información en Diagrama de Interacción El diagrama de interacción es uno de los productos de entrada más importantes para elaborar el de clases Pasos para Refinar el Diagrama de Clases a partir del de interacción  Convertir mensajes en operaciones  Definir scope de las operaciones  Decidir visibilidad requerida entre 2 clases comunicándose en el d. De interacción  Si es global, local o por parámetro mostrar una dependencia en el d. De clases  Si es por campo Identificar si es una relación de un todo con sus partes  Si la parte, sólo es “parte” en una relación de composición, marcarla como composión  Si no marcarla como agregación Si no, marcarla como asociación Mostrar la multiplicidad, navegabilidad y rol

138 138 Paquetes de Clases Las clases se pueden agrupar lógicamente en paquetes  Las clases que se agrupan son las que guardan una relación cercana entre sí, ya sea de funcionalidad o de datos  Estos grupos o paquetes lógicos de clases son los que suelen convertirse en componentes

139 139 VentasEmpresaNómina Paquete de Clases EmpleadoEmpresa Dirección Venta Nómina Producto Cliente Impuestos Factura

140 140 Ejercicio Desarrollar el diagrama de clases del caso de estudio.

141 141 Conclusiones El diagrama de clases muestra la estructura estática del sistema Un diagrama de clases muestra las clases y sus relaciones Existen diferentes tipos de relaciones y visibilidad entre las clases Las clases se pueden agrupar lógicamente en paquetes para reducir la complejidad

142 142 Diagrama de Estados

143 143 Objetivos Aprenderá a modelar los posibles estados de una clase por medio de un diagrama de transición de estados Entenderá el comportamiento de un sistema a partir de sus cambios de estado Podrá interpretar el diagrama de estados en código

144 144 Definición El diagrama de estados muestra:  La biografía de un objeto  Los eventos que causan la transición de un estado a otro  Las acciones resultantes de un cambio de estado Muestra todos los posibles estados de un objeto

145 145 Ejemplos Simples

146 146 Estado Un estado es una condición o situación en la vida de un objeto durante la cual  satisface alguna condición,  realiza algunas actividades o  está en espera de algún evento

147 147 Elementos Estados Transiciones Eventos Condiciones de Guarda Acciones Estados Anidados Historia

148 148 Estado Es una de las posibles condiciones en la que un objeto puede existir y está determinada por una de las 3:  Valores de atributos  Espera de algún evento  Ejecución de alguna acción Nombre único a nivel de clase o a nivel de superestado Estados con el mismo nombre en un diagrama representan el mismo estado Abierto

149 149 Estados Especiales o Pseudoestados Estado Inicial.  Un pseudo estado que indica el primer estado que toma un objeto cuando es creado  Es obligatorio  Sólo se permite uno Estado Final  Indica el final de la vida de un objeto  Es opcional  Puede existir más de uno Inicializando do/ Inicializar el objeto curso RegistroCompletado do/ Generar lista del curso

150 150 Transición de Estado Es un cambio del estado original a un estado sucesor como respuesta a un estímulo  El estado sucesor puede ser el estado original En respuesta a un evento Al cumplirse una condición Abierto entry/ Registrar un alumno Cerrado do/ Reportar que el curso esta cerrado agregarAlumno [ numAlumnos = 10 ] evento (argumentos) [condición] / acción ^ objetivo.enviarEvento (argumentos)

151 151 Eventos Es una ocurrencia que sucede en un instante de tiempo dado  El estado de un objeto determina la respuesta a diferentes eventos Inicialización Operación Apagada Apagar PC Encender PC

152 152 Condición de Guarda Es una expresión Booleana sobre el valor de los atributos de un objeto que se debe cumplir para que se dé la transición de estado Abierto Cerrado agregarAlumno [ numAlumnos = 10 ]

153 153 Acciones Es una operación que puede estar asociada a una transición o a un estado  Transición Instantáneas No interrumpibles  Estado No instantáneas Interrumpibles Se ejecutan a la entrada, durante, a la salida o al ocurrir un evento. Abierto Cerrado agregarAlumno [ numAlumnos = 10 ]

154 154 Estados Anidados o Compuestos Reducir la complejidad El superestado anida subestados Las transiciones comunes a los subestados se representan a nivel de superestado Anidamiento a cualquier nivel de profundidad Registrando Cerrado do/ Reportar que el curso esta cerrado NoAsignado do/ Asignar profesor al curso Abierto entry/ Registrar un alumno H agregarAlumno / numAlumnos = 0 [ numAlumnos = 10 ] agregarAlumno H

155 155 Historia Al regresar a un superestado, éste recuerda cual fue el último estado visitado e inicia ahí Si la característica de historia no es empleada, al regresar al superestado se ingresará siempre al estado inicial Registrando Cerrado do/ Reportar que el curso esta cerrado NoAsignado do/ Asignar profesor al curso Abierto entry/ Registrar un alumno H agregarAlumno / numAlumnos = 0 [ numAlumnos = 10 ] agregarAlumno H

156 156 Consideraciones Durante el análisis, se debe poner especial atención en las clases que presentan un comportamiento significativamente dinámico

157 157 Conclusiones Un diagrama de transición de estados sirve para mostrar los posibles estados y transiciones de un objeto. Una transición indica el posible cambio de un estado a otro cuando ocurre un evento y/o se cumple una condición. Los estados compuestos o súper estados agrupan un conjunto de estados.

158 158 El Modelo de Componentes

159 159 Objetivos El alumno aprenderá a modelar los componentes que conforman a un sistema Comprender qué es un componente de software Enlistar los beneficios de los componentes Aprender en qué consiste el desarrollo de software basado en componentes Apreciar los beneficios del desarrollo de software basado en componentes El alumno aprenderá a modelar la distribución del sistema en componentes de hardware

160 160 Desarrollo Basado en Componentes El desarrollo basado en componentes es la adopción e implantación de métodos, técnicas, herramientas, estándares y tecnologías de soporte para crear sistemas de software a partir de componentes predefinidos.

161 161 Componente de Software Los componentes son agregaciones de piezas más pequeñas de software (p.ej. Clases) Los componentes se utilizan como bloques de construcción de la estructura de un sistema Es una parte física reemplazable de un sistema de software que tiene una interfaz que proporciona acceso a sus servicios. Factura

162 162 Encapsulamiento en Componentes Un componente encapsula la complejidad de la implementación mostrando únicamente la interfaz.  La interfaz es todo aquello que puede ser visto y controlado por el usuario para hacer uso del componente

163 163 Beneficios de los Componentes Aumenta la productividad de la gente Aumenta la calidad Disminuye el tiempo de entrega Fáciles de utilizar

164 164 Tipos de Componentes Existen diferentes tipos de componentes  Librerías.cpp.h.java.class  Ejecutables.exe.dll El tipo de componente se indica como estereotipo del componente > Factura

165 165 Diagrama de Componentes Producto Solicitud Cotizacion Proveedor Productos.dll Cotizacion.dll Catalogo Cotizador Compras.exe Conta.exe Sistema Contable ProductoCtrlSolicitud Cotizacion CtrlProveedores

166 166 Interfaces Un especificador de las operaciones externamente visibles de una clase, componentes u otras entidades como los paquetes  Interface: IGestorVentas Servicios:  Registrar  Agregar Producto  Imprimir Un componente puede implementar una o más interfaces.  Se simboliza con un círculo asociado con una línea al componente Ventas IGestor Ventas

167 167 Implementación de Interfaces Equivale a una clase abstracta sin atributos ni métodos, únicamente contiene operaciones abstractas Características:  Estructura interna no especificada  No tienen implementación  No tienen atributos, estados o asociaciones  Sólo tienen operaciones (pero no métodos)  Pueden tener relaciones de generalización

168 168 Realización La clase que se ocupa de la implementación de las operaciones de una interface tiene una relación de realización con la interface (o con la clase abstracta) El componente donde está la clase que la implementa también tiene una relación de realización

169 169 Dependencia entre Componentes Si un componente depende de otro significa que una clase del primer componente utiliza los servicios de una clase del segundo componente  Factura depende de Productos  Factura no funciona si no existe Productos, pero lo contrario si es posible Productos Factura

170 170 Clases dentro de Componentes Tips para seleccionar las clases de cada componente:  Juntas forman un solo objeto más complejo desde la perspectiva del usuario  Existe mucha dependencia entre ellas  Si los servicios de una de las clases son requeridos por más de 1 componente entonces tal vez debería de estar en un componente aparte para poder ser utilizada por varios

171 171 Clases dentro de Componentes  Si una clase “es parte” únicamente de una clase X y de ninguna otra, entonces debería de encontrarse en el mismo componente.  El componente debe ofrecer pocos servicios y muy especializados hacia el exterior

172 172 Clases en Componentes Empleado Empresa Dirección Venta Nómina Producto Cliente Impuestos Factura

173 173 Componente: CtasCliente.dll CtasCliente

174 174 Comunicación con Interfaces

175 175 Ejercicio Agrupa las clases del caso de estudio y define los componentes en un diagrama de distribución

176 176 Conclusiones Un componente es una parte física reemplazable de un sistema Los componentes agrupan clases lógicamente relacionadas entre sí Los componentes pueden implementar una o varias interfaces Una interface es un conjunto de servicios con un nombre La dependencia entre componentes indica que una clase dentro de un componente utiliza a otra en otro componente

177 177 Diagrama de Distribución o Despliegue

178 178 Objetivos Que el alumno sea capaz de modelar la arquitectura física de un sistema Entenderá los elementos de un diagrama de distribución

179 179 Diagrama de Distribución Muestra la implementación física de los componentes de software en componentes de hardware, así como el tipo de conexión entre estos. Detalla:  Capacidad de la red, especificaciones de servidores, requerimientos de hardware y demás información necesaria para distribuir el sistema propuesto

180 180 Nodos Los nodos se utilizan para representar cualquier servidor, estación de trabajo o cualquier otro hardware utilizado para distribuir los componentes en el ambiente de producción  Ejemplo: Servidor 3PentiumIII, Cliente Pentium II, Servidor de BD.

181 181 Ligas Muestra la conexión entre dos dispositivos de hardware (nodos).  Se le pueden agregar notas o estereotipos para indicar el tipo de conección y/o protocolo utilizado.

182 182 Distribución de Componentes Pueden combinarse el diagrama de componentes con el de distribución para mostrar qué componentes de software irán en qué nodo de hardware  Algunas herramientas de modelado no soportan este tipo de notación

183 183 Ejemplo

184 184 Dispositivos Además de los nodos, que representan computadoras y/o procesadores en este diagrama pueden mostrarse los dispositivos especiales requeridos:  Lectores ópticos, monitores, sensores, etc. Se conectan mediante ligas al nodo que representa la computadora a la cual van conectados físicamente

185 185 Diagrama de Despliegue

186 186 Ejercicio: Desarrollar el Diagrama de Distribución para el caso de estudio.

187 187 Conclusiones El diagrama de distribución muestra la ubicación de los componentes de software en componentes de hardware El diagrama de distribución está compuesto de nodos y ligas Se puede mostrar en un nodo los componentes que corren en este