Programacin Orientada a Objetos ANALISIS Y DISEO UML

Programación Orientada a Objetos ANALISIS Y DISEÑO UML

UML • Un sistema orientado a objetos está conformado por objetos • Pero es lo mismo que decir que una circuito electrónico está hecho con diodos, transistores, resistencias, capacitores, etc • De la misma manera que para construir un circuito necesitamos especificar que componentes, sus valores y las interconexiones entre ellos (un esquemático), para construir un sistema OO necesitamos saber cuales son los objetos, sus atributos y métodos y cómo se interrelacionan entre sí 2

UML • Un esquemático esta formado por símbolos estándar que pueden ser comprendidos por cualquier ingeniero o técnico electrónico • Así también un sistema OO necesita ser representado de una manera estándar para que este pueda ser entendido por diseñadores y programadores 3

UML • A la acción de construir estos diagramas se lo conoce como modelamiento • Al producto se lo conoce como modelo • Modelo es una abstracción que se construye para entender y resolver problemas • Los modelos limitan nuestra vista a un subconjunto de la realidad 4

UML Hardware Real Modelo - Hardware o Software prototipo Software Modelo en papel o Herramienta CASE 5

¿Para que A&D OO? § El cambio a OO no es fácil, los lenguajes de modelamiento OO ayudan de alguna manera para que el cambio de paradigma sea un poco más sencillo. § Uno de los grandes retos en el desarrollo es construir el sistema correcto. Los lenguajes de modelamiento OO ayudan a lograr buena comunicación con los clientes y los expertos en el dominio. 6

UML l ¿Qué es Lenguaje de Modelamiento Unificado? l Lenguaje de modelamiento estándar para: l Modelar sistemas (no solo software) usando OO l Establecer un modo de acoplamiento explícito entre los modelos conceptuales y ejecutables l Manejar las complejidades de sistemas de misión crítica l Proveer un lenguaje de modelamiento que pueda ser utilizado tanto por humanos como por las máquinas. 7

UML l Los modelos se caracterizan por ser: l Precisos l Consistentes l Fácil de comunicar l Fácil de cambiar l Entendibles 8

UML l La Guerra de los modelos (80 s-90 s): – Booch - Grady Booch – OMT - James Rumbaugh – OOSE/Objectory - Ivar Jacobson – Fusion - David Coleman – OOA/OOD - Coad & Yourdon 9

UML Método Boch 10

UML Método OMT 11

UML Método UML 12

Lenguaje Unificado de Modelamiento § El lenguaje unificado de modelamiento (UML) unifica las notaciones de Booch, Rumbaugh (OMT) y Jacobson (OOSE) § Notación es la representación gráfica de diferentes modelos, es la sintaxis del lenguaje de modelamiento. § El UML es un estándar aprobado por la OMG y es ampliamente aceptado en la industria. § UML es un lenguaje de modelamiento, no un proceso de desarrollo de software; su intención es ayudar a las diferentes acercamientos para la producción de software OO. 13

UML l Se utiliza UML en diferentes tipos de sistemas: l Sistemas de información l Técnicos l Tiempo real l Distribuidos l Software l Sistemas de negocios 14

UML i. Hay tres dimensiones para entender los modelos OO: i¿Por qué se construyen los modelos? i¿Qué hay en el modelo? i¿Cómo se relacionan los modelos? 15

UML l Fases en el desarrollo de sistemas: l Análisis de requerimientos l Análisis del sistema l Diseño l Implementación (programación) l Pruebas de aceptación. 16

UML Los Modelos se utilizan para…. Entender y especificar el problema Análisis OO Resolver el problema Diseño OO Construir la solución Construcción OO 17

UML l Para cada una de estas fases existen modelos UML: l Análisis i Foco: Especificar el dominio o el problema i Perspectiva: Desde el punto de vista del cliente o usuario i Actividades típicas: Entendimiento de los requerimientos, entendimiento del dominio del problema, identificar límites del sistema, etc. l Diseño i Foco: Resolver el problema i Perspectiva: Del arquitecto, analista, diseñador, programador i Actividades típicas: Definición de arquitectura del software, escoger estructura de datos, desarrollar algoritmos, implementar relaciones, etc. l Implementación y Pruebas i Foco: Construir la solución para soportar el modelo del diseño i Perspectiva: Del arquitecto, analista, diseñador, programador i Actividades típicas: Implementar clases, manejo de persistencias, concurrencia, pruebas, funcionamiento 18

UML l Para cada una de estas fases existen modelos UML: l Análisis de requerimientos l Casos de Uso l Escenarios l Análisis del sistema l Diagrama Análisis Interacción l Modelo de Análisis de Objetos l Diseño l Diagrama Diseño Interacción l Modelo de Diseño de Objetos l Diagrama de Estados l Implementación (programación) l Diseño Descripción de Clases l Instalación l Diagrama de Puesta en Producción 19

UML • Diferentes modelos dan diferentes vistas de un problema, enfocados a responder preguntas particulares – Modelos estáticos i¿Cuáles son los objetos (entidades o cosas) en el problema? i¿Cuáles son sus características? i¿Qué tienen en común? i¿Cuáles son las relaciones estructurales entre ellos? i Modelos dinámicos i¿Qué pasa cuando el sistema esta corriendo? i¿Cuáles son las colaboraciones entre objetos i¿Cuál es la secuencia de eventos? i¿Cómo se comportan los objetos? 20

UML Modelos estáticos ladra guau mueve la cola Es un tiene cola tiene nariz húmeda Es un perro tiene 4 patas Modelos estáticos se concentran en la estructura y similitudes 21

UML Modelo dinámico muchacho entrega periódico perro persigue al muchacho perro muerde al muchacho perro entrega el periódico Modelos dinámicos se concentran en el flujo de control y secuencia de eventos 22

Diagramas UML § Diagramas de Caso de Uso § Diagramas de Clase § Diagramas de Interacción § Diagramas de secuencia § Diagramas de colaboración § § Diagrama de Estados Diagramas de Actividad Diagramas de Componentes Diagrama de Puesta en Producción 23

UML • Modelos Estáticos: – – – Modelo de Análisis de Objetos Modelo de Diseño de Objetos Diseño de Descripción de Clases Diagrama de Componentes Diagrama de Puesta en Producción • Modelos Dinámicos: – – – Casos de Uso Escenarios Diagrama de Análisis Interacción Diagrama de Diseño Interacción Diagramas de Estado 24

Herramientas CASE • Dibujar Diagramas • Actúan como repositorio • Ayudan a la navegación • Soporte Multiusuario • Genéran código • Ingeniería Reversa • Integración con otras herramientas 25

CASOS DE USO

Casos de Uso • Requerimientos del Sistema i. Requerimientos son el conjunto de frases que describen el comportamiento externo esperado de un sistema, cuando este sea puesto en operación. 27

Casos de Uso i Los requerimientos pueden ser expresados como: i. Requerimientos funcionales: comportamiento observable de lo que hará el sistema. Ej: • cliente renta un vídeo. i. Requerimientos no funcionales: limitaciones en el sistema y/o criterios aceptables como rendimiento, confiabilidad, utilidad, costo, disponibilidad, etc. Ej. : i. El sistema debería poder ser utilizado por alguien que no sabe de computadoras, después de 2 horas de entrenamiento. i. Un usuario del sistema debería poder procesar un reclamo en no más de 3 minutos. 28

Casos de Uso i Un caso de uso es la secuencia de transacciones en un sistema cuya tarea es producir un resultado con valor medible para un actor del sistema i Sistema: Entidad encapsulada cuyos requerimientos han sido descritos (programa, computador) i Actor: Entidad fuera del sistema que interactúa con este (usuario, otro sistema) i Secuencia de transacciones: Serie de interacciones entre el sistema y el actor que lo usa. i Resultado con valor medible: objetivo logrado con valor no trivial para el actor. i El conjunto de casos de uso puede ser utilizado para documentar los requerimientos funcionales del sistema 29

Casos de Uso Sistema Caso de Uso Entidad fuera del sistema quien interactúa con este Serie de transacciones de valor para el actor 30

Casos de Uso La Empresa Sistema Usuario del sistema Cliente (usuario de la empresa) Casos de uso del sistema Casos de uso de la empresa 31

Casos de Uso Banco (empresa) Sistema computacional Cajera Hace depósito Añade cliente Retira fondos Procesa préstamo Deposita cheque Agente Adquiere préstamo Cliente 32

Casos de Uso i ¿Quiénes son los actores? i Un actor es una entidad que interactúa con el sistema. Ejm: i. Un usuario humano i. Otro sistema que requiere de servicios i. Otro sistema que provee de servicios i. El tiempo i El actor esta fuera de los límites del sistema - No es un objeto dentro del sistema i Un actor es una abstracción de un rol - No es un sola persona o el puesto de una persona i. Un usuario puede jugar múltiples roles i. Dos personas diferentes podrían jugar el mismo rol. 33

Casos de Uso i ¿Qué son la secuencia de transacciones? i. Una secuencia es una serie de interacciones i. El foco esta en las interacciones que cruzan los límites del sistema, no son acciones internas del sistema i. La atención esta en las interacciones entre el actor y el sistema, no entre actores i. La implementación precisa de las interacciones no deben describirse en el caso de uso i. La serie de interacciones es iniciada por algún evento. 34

Casos de Uso Sistema Organizador de Reuniones Planifica reunión María (usuario del sistema) Juega el rol de registradora María (usuario del sistema) Juega el rol de planificadora Registra invitado a reunión 35

Casos de Uso Sistema Organizador de Reuniones Planificador (actor primario) Planifica reunión Registrador (actor primario) Registra invitado a reunión Sistema Verificador de tarjeta de crédito (actor secundario) 36

Casos de Uso Sistema de registros médicos Actualiza ficha de paciente Enfermero Respaldo de información en tape 37

Casos de Uso i. Una lista de casos de uso incluye: i. Lista de casos de uso utilizando el formato de objetos. i. Descripción de cada caso de uso i. Descripción de cada actor i(opcional) Diagrama o tabla de relaciones entre casos de uso y actores. 38

Casos de Uso 1. Caso de Uso A 2. Caso de Uso B 3. Caso de Uso C …………. Nombre: _________ Descripción: ___________________ Notas: ________________________ Descripción de Casos de Uso Nombre: _________ Descripción: ___________________ Notas: ________________________ Descripción de Actores Caso de Uso A Lista de Casos de Uso Caso de Uso B Caso de Uso C Diagrama de Casos de Uso 39

Casos de Uso i. Para identificar actores i. Buscar primero los actores primarios (los actores secundarios pueden ser descubiertos a medida que se elabora el comportamiento de los casos de uso) i. Buscar por roles, no usuarios individuales o títulos i. El nombre debería enfocar en el rol de actor, con respecto a su interacción con el sistema. 40

Casos de Uso Diagrama de Casos de Uso Sistema Rol Y Rol Z Rol X 41

Casos de Uso i Identificación de los roles de los actores i. Los casos de uso documentan lo que el sistema debe hacer para satisfacer los objetivos de los actores que interactúan con el sistema i. Los objetivos del actor deben reflejar un valor medible - no pasos individuales para alcanzar un objetivo de valor o interacciones triviales i. Ordena pizza - es un objetivo de valor para el actor que juega el rol de cliente i. Selecciona aceitunas - es solo un paso en ordenar pizza i. Presionar ENTER es una interacción trivial 42

Casos de Uso i. Los objetivos pueden ser descritos desde la perspectiva de un actor quien utiliza el sistema - o desde la perspectiva del sistema i. Ordena pizza es un objetivo desde la perspectiva del actor cliente i. Envía la orden de pizza a la cocina es un objetivo desde la perspectiva del sistema i. Cada objetivo de valor puede ser descrito con los casos de uso. 43

Casos de Uso Diagrama de Casos de Uso Sistema Objetivo c Rol Y Rol Z Objetivo b Objetivo e Objetivo d Rol X 44

Casos de Uso Sistema Objetivo c Rol Y Objetivo b Objetivo d Rol Z Objetivo e Rol X Nombre: Caso de uso D Descripción: Describe funcionalidad y aplicabilidad dentro del contexto Notas: Describe limitaciones y decisiones Describe reglas y políticas del negocio Nombre: Caso de uso E Descripción: Describe funcionalidad y aplicabilidad dentro del contexto Notas: Describe limitaciones y decisiones Describe reglas y políticas del negocio Descripción de Casos de Uso 45

Ejemplo: Carreteras 46

Ejemplo: Carreteras (1) § La compañía Pague&Maneje administra una red de carreteras. La red consiste en número de segmentos de vía. Cada segmento de vía esta delimitados por dos nodos que están descritos normalmente con su posición geográfica. La distancia entre los nodos delimitantes de un segmento de vía es conocido. § Algunos de los nodos están equipados con estaciones de control de acceso que pueden ser usadas para entrar y salir de la red de carreteras. Algunos de los nodos están equipados como puntos de servicio (estación de gasolina, baños, etc) § Una trayecto es una secuencia consecutiva de segmentos de vía. Comienza y termina en nodos con 47 control de acceso.

Ejemplo: Carreteras (2) § Los clientes pueden registrarse con Pague&Maneje y obtener hasta 3 tarjetas. Los clientes pueden usar estas tarjetas para viajar en trayectorias en la red vial. § Las tarjetas regulares son válidas por un período y se envían facturas por cada uso de la tarjeta. El valor de la facturas se calculada a partir de la longitud de la trayectoria recorrida y el precio unitario esta asociado con cada tarjeta. § Además de las tarjetas regulares existe un número de tarjetas especiales. Las tarjetas Mini. Viaje son tarjetas prepagadas, válidas para una sola trayectoria. Están expiran cuando se recorre la trayectoria. Las tarjetas temporales son también prepagadas, son válidas por un tiempo dado y pueden dar acceso a toda la red vial. 48

De captura de requerimientos a Análisis § Descubrir los potenciales casos de uso de un sistema, las interacciones típicas que el usuario tiene con el sistema para alcanzar sus objetivos. § Un caso de uso está escrito como un para de párrafos de texto, UML provee diagramas de caso de uso. § Desarrollar un modelo conceptual del domino, explorar el vocabulario del domino, dar una descripción del mundo en el cual deberá encajar. § Un diagrama de clases conceptual es útil aquí y algunos diagramas UML de actividad podrían ser útiles cuando el proceso de workflow es parte del mundo del usuario. 49

Análisis y Diseño de Métodos § El diagrama de clases conceptual resultante del análisis del domino junto con los casos de uso constituyen un modelo de análisis. § Un modelo de diseño comprende tanto la información de los conceptos del dominio como el comportamiento en los casos de uso, añade las clases que realmente hacen el trabajo y provee cierta arquitectura. § Un diagrama UML de especificación puede ser usado junto con diagramas UML de interacción y/o estado que muestran como las clases implementan los casos de uso. 50

Modelo de Caso de Uso: Actores § Los actores NO son parte del sistema, representan a cualquier persona o cosa que deba interactuar con el sistema. § El afiliado a la biblioteca “presta una copia del libro” § El bibliotecario “actualiza el catálogo” § Un actor puede: § Solamente ingresar información al sistema § Solamente recibir información del sistema § Ingresar y recibir información del sistema § Los actores leen, crean, destruyen y modifican información § Los actores son encontrados en la declaración del problema y en conversaciones con los clientes y expertos del dominio § Un solo actor puede realizar muchos casos de uso y un solo caso de uso puede tener varios actores realizándolo 51

Modelo de Casos de Uso: Casos de Uso (1) § Un caso de uso modela un dialogo entre un actor y el sistema. § Un editor de texto: “marca un texto en negrillas”, “crea un indice” § Un sistema bibliotecario: “presta una copia del libro”, “actualiza el catálogo” § Un caso de uso representa la funcionalidad provista por el sistema, ej. Las capacidades que el sistema proveerá al actor. § La suma de todos los casos de uso es la figura externa del sistema. § Un caso de uso es una secuencia de transacciones realizadas por un sistemas que conducen a un valores de resultado mesurables para un determinado actor. 52

Modelo de Casos de Uso: Casos de Uso (2) § Un caso de uso puede ser pequeño o grande pero logra un objetivo discreto para algún usuario. § Un caso de uso tipicamente representa una parte importante de la funcionalidad que se completa de principio a fin. Un caso de uso debe proveer algo de valor para el actor. § Definición de un caso de uso: curso básico de eventos, número de cursos de acción excepcionales o alternativos § No existe estandar para ellos en UML 53

Modelo de Casos de Uso: Casos de Uso (3) § Ejemplos de definición de un caso de uso: § Nombre: nombre usado para referirse al caso de uso § Resumen: una descripción corta § Actores: todos los actores involucrados § Precondiciones: condiciones del sistema al comienzo de un caso de uso. § Descripción: la descripción completa § Excepciones: casos especiales § Resultado: condición del sistema al final del caso 54 de uso

Ejemplo: Carreteras Casos de Uso (1) § Una persona puede aplicar para registrarse como cliente § Alguna información personal deber ser entregada y registrada en el sistema, el cliente comienza con una cuenta en cero. § Un cliente puede aplicar a una tarjeta § El sistema verifica la cuenta, cuando el límite de crédito es excedido, la tarjeta es negada, sino una nueva tarjeta es entregada y el sistema lo registra. § Un cliente puede aplicar por una tarjeta prepago § El sistema verifica la cuenta, cuando el límite de crédito es excedido la tarjeta es rechazada, sino una nueva tarjeta es entregada y el sistema lo registra. § El sistema imprime una factura para la nueva tarjeta y actualiza la cuenta del cliente. 55

Ejemplo: Carreteras Casos de Uso (2) § Un cliente puede (tratar de) viajar una trayectoria en una fecha dada con una tarjeta regular. § El cliente entra a la red vial a través de algún tipo de control de acceso. § El sistema verifica la validez de las tarjetas y la cuenta del cliente; Cuando se aprueba, el sistema registra el nodo de entrada y la fecha de entrada para la tarjeta y permite el acceso; Cuando no esta ok, el acceso es denegado. § El cliente deja la red vial en algún punto con otro nodo de control. § El sistema calcula el precio total, lo imprime como una factura, actualiza la cuenta de cliente y permite la salida. 56

Ejemplo: Carreteras Casos de Uso (3) § Un cliente puede (intentar) viajar una trayectoria en una fecha dada con un tarjeta de vacaciones. § Es una variación del caso previo, a la salida no se imprime factura la cuenta del cliente no es actualizada. § Un cliente puede (intentar) viajar una trayectoria en un día dado con una tarjeta minitrip. § Es una extensión del caso de uso anterior, los nodos de entrada y salida son verificados contra la trayectoria para la cual esta hecha la tarjeta. § Un ingeniero puede actualizar la red de carreteras § Un fiscalizador o auditor puede registrar el pago de una factura. 57

Apply For Card <<includes>> customer Apply For Prepaid Card Travel Trajectory With Season With Minitrip <<extends>> Card engineer Update Road Network Register Payment Of Invoices Travel Trajectory With Regular Card bookkeeper 58

Diagramas de Casos de Uso Relaciones de Actores § La relación de “asociación” entre un actor y un caso de uso § La participación de un actor en un caso de uso § Es la única relación entre los actores y los casos de uso § La “generalización” de un actor A a un actor B § Indica que una instancia de A puede comunicarse con la misma clase de instancias de casos de uso que una instancia de B 59

Diagramas de Casos de Uso Relaciones de Casos de Uso § La relación <<incluye>> permite factorizar una porción de comportamiento que es similar a través de dos o más casos de uso para evitar copiar descripciones de ese comportamiento § La relación <<extiende>> provee una forma más controlada de extensión del comportamiento de un caso de uso que la relación de generalización. El caso de uso base declara un número de puntos de extensión. El caso de uso extendido puede solamente alterar el comportamiento de esos puntos de extensión. § La relación de “generalización” indica que uno de los casos de uso es una variación del otro. Permite a un caso de uso especializado cambiar cualquier aspecto del caso de uso base. 60

Analyze Risk Price Deal <<includes>> Trader Valuation Request Catalog Capture Deal _____ <<extends>> Extension points After creation of the deal Limits Exceeded Sales. Person 61

Relaciones de Casos de Uso Reglas empíricas § Usar incluir cuando se esta repitiendo dos o más casos de uso y se quiere evitar la repetición § Use generalización cuando esta describiendo una variación de un comportamiento normal y desea describirlo brevemente § Use extender cuando este describiendo la variación de un comportamiento normal y se desea hacerlo de una manera más controlado, declarando los puntos de extensión en el caso base. 62

Objeto: Estado, Comportamient e Identidad (1) § Representación de una entidad § Mundo real § Conceptual § Algo concreto o un concepto ÞConcepto, abstracción o cosa con límites bien definidos y significado para una aplicación 63

Objeto: Estado, Comportamient e Identidad (2) § Estado § Una de las posibles condiciones en las cuales puede existir § Cambia con el tiempo § Define un conjunto de propiedades, con los valores de las propiedades más las relaciones que el objeto tiene. § Comportamiento § Como un objeto responde a una petición § Implementado por un conjunto de operaciones § Identidad § Cada objeto es único 64

Diagrama de Clase

Encontrar Objetos (Clases) • El primer paso para construir un modelo de objetos es identificar las clases de objeto presentes en un problema • La primera regla es que los objetos se deben tomar del ámbito del problema, no de la herramienta de solución 66

Clase § Descripción de un grupo de objeto con propiedades comunes (atributos), comportamiento común (operaciones), relaciones comunes con otros objetos y semántica común. § Una buena clase captura una y solamente una abstracción § Las clases deben ser nombradas usando el vocabulario del dominio. 67

Encontrar Objetos (Clases) • Las clases se encuentran principalmente en los requerimientos del problema • Son generalmente substantivos. • No hay que ser demasiado selectivos, elija todas las clases que le vengan a la mente y en un paso posterior se las filtra 68

Encontrar Objetos (Clases) Clases Candidatas Requerimientos Dominio de Problema Extraer substantivos Clases Eliminar malas clases 69

Encontrar Objetos (Clases) • No hay que preocuparse demasiado por herencia, encapsulación, mensajes o polimorfismo en esta etapa • Luego procederemos a armar las interrelaciones entre los objetos • Lo importante ahora es no olvidar a ningún objeto que pueda ser importante 70

Pulir Clases • Hay varias reglas a seguir para poder filtrar a los objetos candidatos. Debemos eliminar: – – – – Clases Redundantes Clases Irrelevantes Clases ambiguas Atributos Operaciones Roles Detalles de Implementación 71

Pulir Clases • Clases Redundantes – Si dos clases expresan la misma información, la más descriptiva debe quedarse. – Por ejemplo: un cliente puede describir a la persona que compra un ticket de vuelo, pero pasajero es una clase más descriptiva – Por lo tanto si tanto cliente como pasajero están presentes se deberá eliminar uno de los dos, dejando el más descriptivo para el problema 72

Pulir Clases • Clases Irrelevantes – Si una clase tiene muy poco o nada que ver con el problema, debe ser eliminada – Esto involucra el juicio del experto, porque en otro contexto la clase tal vez es importante. – Ejemplo: En un sistema de reservaciones de entradas a un teatro, las esposas de los que asisten no son importantes para el sistema. Pero en caso de un sistema de rol de pagos, si son importantes las esposas de los empleados. 73

Pulir Clases • Clases Ambiguas – Una clase debe ser específica. Algunas clases candidatas tienen límites mal definidos o demasiado grandes. – Por ejemplo una clase Almacenamiento es vaga mientras que Base de Datos es mas específica 74

Pulir Clases • Atributos – No se debe elevar los atributos al nivel de clases. – Por ejemplo: edad, peso, dirección son generalmente atributos. – Si se necesita el atributo hay que envolverlo con una clase 75

Pulir Clases • Operaciones – De la misma manera, un método no se debe tomar por una clase – Por ejemplo: llamada telefónica es una secuencia de acciones entre el Usuario y la red Telefónica, no un objeto – Pero por ejemplo si estamos haciendo un sistema de facturación, llamada si sería un objeto 76

Pulir Clases • Detalles de Implementación – Cualquier construcción extraña al mundo real debe ser eliminada del modelo de análisis. – Se pueden utilizar luego, en el diseño, pero no ahora. – Por ejemplo: CPU, subrutina, proceso, algoritmo, interrupción, etc son detalles de implementación 77

Identificar Asociaciones • Esta es una etapa en la que se trata de encontrar relaciones entre los objetos. • Las más comunes son las de herencia “es un” • Otras relaciones – “tiene un” – “controla a” – “trabaja para” – etc 78

Identificar Asociaciones • Estas relaciones nos van a ayudar generar el famoso diagrama estático de objetos del sistema. 79

Características de las Asociaciones Modelamiento de Asociaciones Asociación Clase A Persona empleada por empleado Clase B Compañía empleador 80

Multiplicidad • Un factor importante que se debe considerar es el número de asociaciones en las que un objeto puede participar en cualquier instante 81

Multiplicidad • También se debe de tomar en consideración las restricciones que se pueden dar, como por ejemplo que un rectángulo no puede pertenecer a más de un diagrama a la vez 82

Multiplicidad • En ese caso en el diagrama se deben de incluir estas restricciones como propiedades de la asociación • Ej. : Las siguientes restricciones se aplican: – Una Herramienta Rectángulo debe esa asociada con solo un diagrama a la vez – Un diagrama puede o no tener una Herramienta Rectángulo asociada – Un diagrama puede contener o estar asociado a cero o más rectángulos – Todo rectángulo debe pertenecer a un diagrama únicamente. 83

Multiplicidad • En ese caso en el diagrama se deben de incluir estas restricciones como propiedades de la asociación • Las siguientes restricciones se aplican al diagrama anteriormente mostrado: – Una Herramienta Rectángulo debe esa asociada con solo un diagrama a la vez – Un diagrama puede o no tener una Herramienta Rectángulo asociada – Un diagrama puede contener o estar asociado a cero o más rectángulos – Todo rectángulo debe pertenecer a un diagrama únicamente. 84

Multiplicidad 85

Multiplicidad 86

Tipos de Relaciones • Además de la Asociación existen otros tipos de Relaciones entre los objetos – Agregación – Composición – Generalización 87

Agregación • La agregación se usa para mostrar que una clase es parte de otra. • Podríamos decir que es una asociación “contiene a”, “es contenido por” • Ej: La clase computador contiene a la clase CPU y a la clase memoria • La multiplicidad también se especifica en las agregaciones 88

Agregación 89

Composición • La composición es similar a la agregación • Se basa en una relación de posesión A contiene a B • La diferencia estriba en que B no tienen sentido si no pertenece a A • Por ejemplo: La clase ventana posee a la clase marco de ventana. Pero si no existiera la clase ventana, no tendríamos ninguna utilidad para la case marco de ventana 90

Composición 91

Composición 92

Generalización • La generalización es una relación “es un” • Es la representación de la herencia de clases • Se representa con una línea y una flecha 93

Generalización 94

ama de Clases 95

Diagrama de Clases (Preliminar) • Taller: Constuir el diagrama de Clases del Ascensor 96

Diagrama de Clases (Preliminar) • Taller: Constuir el diagrama de Clases del Ascensor 97

Clases y Diagramas de Clase § Un diagrama de clases describe los tipos de objetos en un sistema y las varias clases de relaciones estáticas que existen entre ellos. § Asociación y subtipo (generalización / especialización) son los dos principales tipos de relaciones estáticas § Los diagramas de clase también muestran los atributos y métodos de una clase y las restricciones que se aplican a la manera en que los objetos se conectan. § Un diagrama de objetos es una fotografía de los objetos en un sistema en un momento en el tiempo. También se conoce como diagrama de instancias. 98

Customer 1 1. . 3 Name registered-to Address Account Check. Account Update. Account 1 Node Description begin 1 end Card Valid. From Valid. Thrue Unit. Price Valid? 1 * Road. Segment card-used Distance * {ordered} 1. . * * Access Node Enter Leave Control 1 entry 1 exit * Trajectory Date. Of. Entry * * Print. Invoice Compute. Total 99

a Card registered-to Unit. Price: 4 Valid. From: 1/1/00 Valid. To: 30/6/01 a Customer Name: “Viviane” Address: “Paris” Account: -500 a Card Unit. Price: 5 registered-to Valid. From: 1/1/01 Valid. To: 31/12/01 registered-to a Card Unit. Price: 5 Valid. From: 1/1/01 Valid. To: 30/6/01 a Customer Name: “Michel” Address: “Lion” Account: 0 100

a Node end Description: “Orleans” begin a Node Description: “Olivet”begin a Road. Segment Distance: 90 a Road. Segment Distance: 120 A Trajectory Date. Of. Entry: 1/4/01 end a Node Description: “Meung” begin end a Node Description: ”Mer” a Road. Segment Distance: 20 101

Asociaciones § Las asociaciones representan las relaciones entre las instancias de las clases § Cada asociación tiene dos roles; siendo el rol una dirección en la asociación § Un rol pude ser nombrado explícitamente con una etiqueta, si no hay etiqueta el nombre de la clase es usado. § Un role tiene multiplicidad, una indicación de cuantos objetos pueden participar en una relación dada. En general la multiplicidad indica límites inferiores y superiores. 102

Asociaciones y Prespectivas § Desde una perspectiva conceptual las asociaciones representan relaciones conceptuales: un usuario trabaja para un solo departamento, el departamento tiene varios usuarios trabajando para él. § Dentro de la especificación las asociaciones en perspectiva representan responsabilidades: un usuario es responsable de saber en que departamento trabaja. Un departamento es responsable de saber quienes son sus empleados. Con buenas convenciones las interfaces pueden ser deducidas del diagrama. § En un modelo de implementación la asociaciones podrían mostrar punteros: un puntero de un usuario al departamento donde trabaja, una colección de punteros de un departamento hacia sus empleados. 103

Navegación § Las flechas pueden ponerse en las asociaciones para indicar navegabilidad § La navegabilidad no sirve a ningún propósito en los diagramas conceptuales, aparecen en el cambio de la especificación a la implementación. § En un modelo de especificación las flechas indican responsabilidades asimétricas: una versión de la herramienta conoce su estatus, un estatus no conoce a que versión está asociada. § En un diagrama de implementación las flechas indican punteros de una clase a otras solamente: un puntero de la versión de la herramienta al estatus, no hay puntero de regreso. 104

Customer 1 1. . 3 Name registered-to Address Account Check. Account Update. Account Node 1 Description begin 1 end * * Card Valid. From Valid. Thrue Unit. Price Valid? 1 Road. Segment Distance card-used {ordered} 1. . * * Access Node Enter Leave Control 1 entry 1 exit * Trajectory Date. Of. Entry * * Print. Invoice Compute. Total 105

Navegación y Convenciones § Cuando la navegabilidad es en una dirección solamente se conoce como asociación unidireccional. § Cuando la navegabilidad es en ambas direcciones se conoce como asociación bidireccional. § Las asociaciones sin flechas son, de acuerdo con UML, o bidireccionales o de navegabilidad no dicha. § Las asociaciones bidireccionales implican una restricción extra en la cual los dos roles son el inverso el uno del otro. 106

Asociaciones y Nombres § Las Asociaciones pueden tener un nombre § Los modeladores de datos tradicionales usan una frase verbal para una asociación de tal manera que las relaciones pueden utilizar frases como: “es empleado por” “esta casado con” § Los modeladores de objetos prefieren sustantivos para uno u otro rol de la asociación, este corresponde mejor con las responsabilidades y operaciones: “empleado” “esposa” § Nombre una asociación cuando mejore su compresión, evite poner “tiene” o “esta relacionado” 107

Atributos § Los atributos son similares a las asociaciones § A nivel conceptual, un atributo es solamente otra notación para una asociación de valor simple. § Al nivel de especificación, los atributos implican navegabilidad de los objetos a los atributos solamente. § A nivel de implementación, usar un atributo implica que los objetos contienen su propia copia del objeto atributo. Ej. : semántica de valor más que de referencia para tipos usados como atributos (cadenas, números, etc) § visibilidad nombre: tipo = valorpordefecto § Existe notación para: visibilidad, ámbito 108

Operaciones § Las operaciones son procesos que una clase sabe como llevar a cabo. § A nivel de especificación las operaciones corresponden a los métodos públicos de un tipo; las operaciones que solamente manipulan atributos no son mostradas, estas pueden ser inferidas. § En el modelo de implementación las operaciones privadas y protegidas deben ser mostradas también; la notación de visibilidad es inspirada en C++: +(público), -(privado), #(protegido), el significado de estos indicadores es a menudo dependiente del lenguaje § Una pregunta es una operación que obtiene un valor sin cambiar el estado del sistema 109

Operaciones § La sintaxis completa de UML para las operaciones es: visibilidad nombre(lista-parametros) : expresióntipo-retorno {cadena-propiedades} § visibilidad es + (pública), # (protegida), o – (privada) § nombre es una cadena § lista-parametros contiene parámetros separados por comas, sintaxis: § dirección nombre: tipo = valor-defecto direction: in, out, inout § Expresión-tipo-retorno: lista separada por comas de los tipos retornados § Cadena-propiedades: valores de propiedades 110 aplicadas a la operación dada.

Asociaciones Derivadas y Atributos § Las asociaciones derivadas y los atributos son aquellos que pueden ser calculados de otros atributos o asociaciones § “la edad de una persona puede ser calculada a partir de su fecha de nacimiento” § En los diagramas conceptuales, los marcadores derivados solamente recuerdan que la derivación (y por tanto la restricción) existe § En la especificación las características derivadas indican una restricción entre valores, no una sentencia acerca que es calculado o almacenado explícitamente § En la implementación las valores derivados son útiles para anotar los campos que son usados como caché por razones de desempeño. 111

Objetos Referencia y Objetos de Valor § Para los objetos referencia la identidad es importante. Existe usualmente un objeto de software para designa un objeto del mundo real. Para objetos de valor la identidad es menos importante, múltiples objetos de valor pueden ser referenciados por el mismo objeto del mundo real. § Los objetos referencia son los mismos cuando tienen la misma identidad, los objetos de valor son los mismos cuando representan el mismo valor. § Los objetos de valor son creados y destruidos frecuentemente pero deberían ser inmutables o la compartición debe evitarse. § Dentro de UML los atributos son usualmente usados para objetos de valor y las asociaciones son usadas para referenciar a los objetos de referencia. 112

Customer Name: string Address: string Account: integer 1. . 3 Card 1 registered-to Check. Account(): boolean Update. Account(n: integer) Register. Card(): void Print. Address(): void Valid. From: Date Valid. Thrue: Date Unit. Price: integer Card. Id: number Valid? (d: Date): boolean Get. New. Card. Id(): number Get. Card(n: number): Card Date Day: integer Month: integer Year: integer Is. Before(d: Date) : boolean Is. After(d: Date): boolean Equal(d: Date): boolean Date is a utility class 113

Customer -Name: string -Address: string -Account: integer -Cards: Set(Card) +Register. Card(): void +Check. Credit(): boolean {query} +Update. Account(n: integer) +Print. Address(): void Trajectory Date. Of. Entry: Date Card-Used: Card /Customer: Customer Entry: Node Exit: Node Card. Id: number Valid. From: Date Valid. Thrue: Date Unit. Price: integer Registered-to: Customer Valid? (d: Date): boolean Set. Valid. From(d: Date) : void Set. Valid. Thue(d: Date) : void Set. Unit. Price(d: Date): void Get. Valid. From(d: Date) : boolean Get. Valid. Thue(d: Date) : boolean Get. Unit. Price(d: Date): integer Get. New. Card. Id(): number Get. Card(n: number): Card Check. Trajectory(): boolean Print. Invoice (): void 114

Generalización § Conceptualmente una clase es una generalización de otra si cada instancia de la última es por definición una instancia de la primera. § Dentro de la especificación, la generalización significa que la herencia de un subtipo incluye todos los elementos de la interfase del supertipo. § En la implementación la generalización es asociada con la herencia en los lenguajes de programación y así con subclases y no con subtipos 115

Clases Abstractas § Una clase abstracta es una clase con declaración de métodos pero sin cuerpo de métodos. Sirve a un propósito esencial como lo es la especificación de interfaces. Las subclases deben proveer la implementación (cuerpo de los métodos) antes de la inicialización. § Para una clase o método abstracto, al convención de UML es italizar el ítem abstracto y usar la restricción {abstract} 116

Card {abstract} A regular card is valid on a given. Valid? date if the date is between the validfrom and the validthrue Regular Card Valid. From Valid. Thrue Unit. Price Prepaid Card Price. Paid A minitrip card is valid if the trajectory matches Valid? What to do if trajectory is exited : printinvoice, invalidate, nothing? Minitrip Card Used? Trajectory Valid? Invalidate Season Card Valid. From Valid. Thrue Valid? 117

Interfaces § Order. Reader necesita Data. Input § Data. Input. Stream implementa las interfaces Data. Input e Input. Stream y es subclase de la última. § Si la interfaz de Data. Input cambia, el Order. Reader deberá cambiar también. 118

Agregación y Composición § Agregación es una relación part-de § “un carro tiene un motor y llantas como sus partes” § La diferenciación entre agregación y asociación es un tópico muy debatido (usualmente dependiente del dominio) § “una compania no es la agregación de sus clientes” § La composición es una variedad más fuerte de agregación, los objetos parte pertenecen a un solo objeto completo, viven y mueren con el todo; el borrado del todo borra a las partes. § Una multiplicidad 1. . 1 en una asociación o una 119 agregación implica borrado en cascada

Reglas de Restricción § Las construcciones básicas de asociación, atributos y generalización especifican restricciones importantes, pero no pueden indicar todas las restricciones en el dominio del problema. § Las restricciones pueden ser escritas en el diagrama de clases entre { } ya sea usando lenguaje informal o una notación más formal. 120

Customer Name: string Address: string Date. Of. Birth: Date /Age(): number Node 1 Description begin 1 end Road. Segment Distance * * {age() >= 18} {begin <> end} Access Control Node 1 Traffic Light 1 Barrier 1 Card Reader 1. . 12 Access Control Station 121

Coleciones para Roles Multivalor § Un rol multivalor es uno donde el límite superior de la multiplicidad es mayor que 1. § La convención es que los roles multivalor son mentalizados como conjuntos: no existe orden implícito y los objetos destino no aparecen en el más que una vez. § Este valor por defecto puede ser cambiado con las restricciones: {ordered}, {bag}, {ordered bag}, {hierarchy} 122

Restricción congelada § {frozen} es una restricción que puede será aplicada a un atributo, un rol o una clase. § En un atributo o rol, este indica que el valor de ese atributo o rol no puede cambiar durante el tiempo de vida del objeto fuente, cuando se aplica a una clase, indica que todos los roles y atributos asociados con la clase son inmutables. § El valor es un conjunto al tiempo de la creación del objeto; espere un argumento en un constructor, no espere operaciones que actualicen el valor. § La gente comete errores, vigile esta restricción en el modelo de especificación 123

Estereotipos § Un estereotipo indica un nivel superior de clasificación § Jacobson, por ejemplo, distingue los 3 tipos de clases: objetos interfaz, objetos de control y entidades de objetos con íconos especiales para cada una § UML usa estereotipos como un mecanismo de extensión en lenguaje natural <<algún tipo>> § Dentro de los diagramas de clase pueden existir estereotipos para clases, asociaciones y generalizaciones. 124

Clasificación Múltiple y Dinámica § La clasificación simple y estática de los objetos es muy restrictiva para el modelamiento conceptual. § En la clasificación múltiple un objeto puede ser descrito por muchos tipos que no están necesariamente conectados por herencia (≠ herencia múltiple) § Los subtipos con el mismo discriminador (nombre del rol) son disjuntos. § El discriminador puede marcarse como {complete} § No todos las combinaciones de subtipos son legales § La clasificación dinámica permite a un objeto cambiar de tipo dentro de la estructura de subtipos, se anota como <<dynamic>> 125

126

{complete} Male sex Customer Female <<dynamic>>type Frequent Customer Corporate Customer Transport Customer Name: string Address: string Sex: {Male, Female} Print. Address(): void 127

Clases Asociación § Las clases asociación permiten añadir atributos, operaciones y características a una asociación. § Es útil modelar la información que pertenece a una asociación dentro de ella misma y no dentro de los cualquiera de los dos o más objetos participantes. § Añada restricciones extras en comparación con el caso más general de tener a clase entre dos clases participantes: existe solamente una instancia de la clase asociación entre dos objetos participantes 128

129

Node 1 Description begin 1 end * Road. Segment * Distance: integer owns * Open. Since: Date Company * Exists. Since: Date owner Ownership Since: Date 130

Asociaciones Calificadas § Una asociación calificada es el equivalente en UML de las construcciones como listasdeasociación, mapas y diccionarios. § Un calificador es llevado con la clase fuente, una multiplicidad puede ser mostrada en el rol destino. § En un modelo conceptual indica una restricción § En el modelo de especificación indica que el acceso al destino se hace a través de una búsqueda bajo llave. § En el modelo de implementación muestra el uso de una estructura de datos asociativos. 131

132

Node Description Enter Leave Control Service Node Description Access Node Company Exists. Since: Date 0. . 1 manages 133

Clases Parmetrizadas • Esta inspirada en la noción de clases parametrizadas (plantillas) de C++ • Es un concepto útil cuando se trabaja con colecciones en lenguajes estáticos. • En UML una clase parametrizada obtiene un parámetro template • Ya sea una sintaxis similar a la de C++ en el nombre de la clase o un estereotipo <<bind>> en una relación refinada puede ser usada para mostrar un elemento unido. • Usar un elemento unido es diferente de subtipo, se trata de restringir el tipo solamente, no las nuevas 134 características que pueden ser añadidas

T Sequenc e Insert(T) Remove( <<bind>> T) <Road. Segment> Road. Segment Distance Insert(T) Remove( T) {ordered} 1. . * Sequence<Road. Seg ment> 1 * Trajectory Date. Of. Entry Print. Invoice Compute. Total T Road. Sequence Distance * {ordered} Trajectory Date. Of. Entry * Print. Invoice Compute. Total Trajectory Date. Of. Entry Print. Invoice Compute. Total 135

Relaciones Avanzadas: Dependencia § Relación “usa” § El cambio en la especificación de una cosa afecta a otra que la usa. § 17 estereotipos pueden ser aplicado a las relaciones de dependencia. 136

Paquetes § ¿Como se divide un sistema grande en sistemas más pequeños? § Agrupar elementos del modelo juntos, por ejemplo clases § Paquete es una colección de elementos del modelo, por ejemplo una colección de paquetes relacionados y/o clases § Cada paquete debe contener una interfaz, conformada por el conjunto de sus clases públicas. § El resto de clases en un paquete son implementación, ej. No se comunican con otras clases en otros paquetes 137

Relaciones entre Paquetes § Importar: una manera de acceso que especifica que los contenidos públicos del paquete importado entren al espacio de nombre del paquete importador, como si hubieran sido declarados en este. § Acceso: especifica que al paquete fuente se le otorga el derecho de referenciar los elementos del paquete destino. § Generalización: familias de paquetes 138

139

Diagramas de Interacción § Los diagramas de interacción son los modelos que describen como los grupos de objetos colaborar en algún comportamiento. § Típicamente, un diagrama de interacción captura el comportamiento de un solo caso de uso. § Existe dos clases de diagramas de interacción: diagramas de secuencia y diagramas de colaboración § Ambos tipos de diagramas muestran un número de objetos ejemplo y los mensajes que son pasados entre estos objetos. 140

Diagramas de Secuencia (1) § Los objetos se muestran como cajas en la parte superior de las líneas de vida usando el esquema de nombre de UML un. Nombre. Clase o Nombre. Objeto: Nombre. Clase § Los mensajes son representados por flechas entre las líneas de vida de dos objetos. Los mensajes son rotulados con el nombre del mensaje y opcionalmente con los argumentos. § El orden el cual los mensajes ocurren es mostrado de arriba a abajo. § Delegación-propia o llamada-propia: un mensaje que un objeto se envía a si mismo, es mostrado como una flecha que regresa a la línea de vida. 141

Diagramas de Secuencia (2) § Información de control puede ser añadida: § Condiciones, ej. [check. Ok] : el mensaje solo es enviado si la condición es verdadera. § Marcadores de Iteración. Ej. * Do. Something : muestra que un mensaje ha sido enviado varias veces a múltiples objetos receptores. § Las respuestas pueden ser mostradas a través de líneas punteadas, estas pueden ser omitidas para evitar congestionar el diagrama § Para mostrar que un objeto esta activo, una caja de activación puede ser usada, esta hace el diagrama más difícil de leer, pero más fácil de entender. § La delegación de objetos puede mostrarse con una grande x 142

an Access Control Node Enter a Card a Customer a Road Segment is. Valid==Valid? account. OK==check. Account [is. Valid And account. OK] New Leave a Trajectory Compute. Total * Get. Distance Get. Unit. Price Print. Invoice Update. Account X

an Access Control Node Enter a Card a Customer a Road Segment is. Valid==Valid? account. OK==check. Account [is. Valid And account. OK] New a Trajectory Leave Compute. Total * Get. Distance Get. Unit. Price Print. Invoice Update. Account X

Procesos Concurrentes en Diagramas de Secuencia § Las cajas de activación aparecen explícitamente en la línea de vida para indicar ya sea ejecución o espera por la respuesta a un mensaje sincrónico. § Puntas de flecha indican mensajes asincrónicos: § Crear un nuevo hilo (flecha arriba de activación) § Crear un nuevo objeto (flecha a caja de objeto) § Comunicación con un hilo que ya está corriendo § La consecuencias de delegación propia pueden ser mostradas más claramente a través de activaciones apiladas § Dos escenarios para un caso de uso pueden ser dibujados en dos diagramas o en un diagrama usando lógica condicional 145

a Card Reader a Barrier a Traffic Light an Access Control Node a Card a Customer Enter Read is. Valid==Valid? account. OK==Check. Account [is. Valid And account. OK] New Open Put. Green [after 30 sec] Put. Red a Trajectory

a Card Reader Read an Access Control Node a Card a Customer Enter Card. Valid? Account. Ok? Card. Valid Checks. Complete? Account. Ok Checks. Complete? a Trajectory

Diagramas de Colaboración § Objetos ejemplo son mostrados como íconos usando el esquema de UML un. Nombrede. Clase o Nombre. Objeto: Nombre. Clase § Las flechas indican los mensajes enviados y la secuencia es indicada al numerar esos mensajes. § El esquema de numeración simple muestra la secuencia general solamente. § El esquema de numeración decimal hace más claro que operación llama a que otra operación. § La información de control aparece como en el diagrama de secuencia. 148

Diagramas de Colaboración: Enlaces § Los enlaces son instancias de una asociación § El nombre del rol puede ser mostrado a cada fin de enlace § El nombre de la asociación puede ser mostrado cerca del camino (subrayado) § Estereotipos pueden ser agregados al fin de un enlace para indicar varios tipos de implementación: § § § Asociación Parámetro (parámetro de método) Local (variable local de un método) Global (variable global) Self (enlace a si mismo) 149

a Card 8. Get. Unit. Price 2. is. Valid==Valid? a Road Segment 7. * Get. Distance 1. Enter 4. [is. Valid And account. OK] New an Access Control Node 6. Compute. Total a Trajectory 5. Leave 9. Print. Invoice 3. account. OK==Check. Account a Customer 10. Update. Account 150

a Card 2. 1. 2. Get. Unit. Price 1. 1. is. Valid==Valid? a Road Segment 2. 1. 1. * Get. Distance 1. Enter 1. 3. [is. Valid And account. OK] New an Access Control Node 2. 1. Compute. Total a Trajectory 2. Leave 2. 2. Print. Invoice 1. 2. account. OK==Check. Account a Customer 2. 3. Update. Account 151

Comparación D. de Secuencia y D. de Colaboración § Los diagramas de secuencia ponen mayor énfasis en la secuencia. § Los diagramas de colaboración permiten posicionar a los objetos de acuerdo a su relación estática. § Cualquier forma es ayudada por la simplicidad: cuando se representan muchos condicionales o lazos de comportamiento el método no sirve. § Cuando existe gran cantidad de comportamiento condicional es recomendable usar diagramas separados para cada escenario. § Los diagramas de interacción son buenos para buscar en el comportamiento de varios objetos dentro de un caso de uso simple; no son buenos para precisar la 152 definición del comportamiento.

Un diagrama de interacción bien estructurado § Se enfoca en comunicar un aspecto de la dinámica del sistema. § Contiene solo aquellos elementos que son escenciales para comprender ese aspecto. § Provee detalles consistentes con el nivel de abstracción y deber exponer solo aquellos adornos que sean escenciales para comprenderlo. § No es tan minimalístico que desinforma al lector acerca de las semánticas que son importantes. 153

Diagramas de estado § Los diagramas de estados describen todos los posibles estados de en los que un objeto pude esta y como el objeto cambia de estado como resultados de eventos que llegan al objeto. § Los diagramas de estados son dibujados para una sola clase para mostrar el comportamiento a lo largo de la vida del objeto. § Usar diagramas de estado para aquellas clases que exhiben un comportamiento interesante solamente. § Interfaces de Usuario y objetos de control son candidatos populares. 154

Estados § Los estdos son una condición o situación durante la vida de un objeto durante el cual: § Satisface alguna condición, § Realiza alguna actividad o § Espera por algún evento § Los objetos permanecen en un estado por un período finito de tiempo. 155

Estados § Diferentes partes de un estado: § Nombre: cadena textual; un estado pude ser anónimo § Acciones de Entrada/Salida: acciones que son ejecutadas al entrar o salir un estado. § Transiciones internas: transiciones que son manejadas sin causar un cambio de estado § Subestados: estructura anidada de un estado, involucrando subestados disjuntos (secuencialmente activos) o concurrentes (concurrentemente activos) 156

Estados Inicial y Final § El estado Inicial indica el punto por defecto en el cual comienza la máquina de estados o subestado (circulo lleno en negro) § El estado final indica que la ejecución de la máquina de estados ha sido completado (círculo lleno en negro rodeado de un círculo vacío) § Los estados inicial y final son seudo-estados. Ninguno tiene las partes de un estado normal, excepto por el nombre. 157

Transiciones § La transición es una relación entre dos estados que indica que: § Un objeto en el primer estado realizará cierta acción y § Entrará al segundo estado cuando un evento específico ocurra y condiciones específicas sean satisfechas. § Cuando se cambia de estado, se dice que se ha disparado la transición. 158

Transiciones § Las transiciones tienen 5 partes: § Estado fuente: este es el estado afectado por la transición; si un objeto esta en el estado fuente, una transición de salida pude dispararse cuando el objeto recibe el evento disparador de la transición y si las condiciones de guarda son satisfechas. § Estado destino: el estado que esta activo luego de haber completado la transición 159

Transiciones § Evento [Guarda] / Acción § Evento disparador: el evento cuya recepción por parte del objeto en el estado fuente hace que la transición se pueda disparar, dado que se cumpla con las condiciones de guarda. § Condiciones de Guarda: una expresión booleana que es evaluada cuando la transición es disparada por la recepción de un evento disparador; si la expresión evalúa verdadero, la transición se dispara, si la expresión evalúa falso, la transición no se dispara y si no hay otras transiciones disparadas por el mismo evento, el evento se pierde. § Acción : una cálculo ejecutable de manera atómica que puede actuar directamente en el objeto. 160

Eventos § Nombre-evento ‘(‘ lista-parametros ‘)’ § Nombre-parametro ‘: ’ tipo-expresion § Eventos por lapso de tiempo after(5 segundos) after(10 segundos desde la salida de estado A) § Las condiciones que se vuelven verdaderas a través de la palabra reservada when seguida de una expresión booleana. (prueba continua de la condición hasta que sea verdadera) § Transiciones sin un evento dentro de su rótulo ocurren tan pronto la actividad asociada con el estado se termina 161

Condiciones de Guarda § Expresiones booleanas encerradas entre corchetes y puestas después de un evento disparador. § Evaluadas solamente después de que el evento dispara la transición § Es posible tener múltiples transiciones desde el mismo estado fuente y con el mismo evento disparador, siempre y cuando las condiciones no sean las mismas. § Dentro de la expresión booleana, es posible incluir condiciones acerca del estado de un objeto. 162

Acción § Una acción es un cálculo ejecutable atómicamente. § Las acciones pueden incluir: § Llamadas a operaciones del objeto que posee el diagrama de estado u otros objetos visibles. § Creación y destrucción de otro objeto § Las acciones son atómicas, Ej. : no pueden ser ininterrumpidas por un evento y deben ejecutarse hasta su finalización. Una actividad pude ser interrumpida por otros eventos! 163

[Ok] / New, Put. Green, Open Enter idle Do/display welcome mess [after 30 sec] checking Do/Checks Do/display wait mess [not Ok] refusing-access Do/display refusal mess 164

165

[Account. Ok] / New, Put. Green, Open Enter / Card. Ok? idle checking-card [after 30 sec] [not Card. Ok] refusing-access [Card. Ok] / Account. Ok? checking-account [not Account. Ok] 166

Estados Avanzados y Transiciones § Los diagramas de estado UML tiene características avanzadas que ayudan a: § Manejar modelos de comportamiento complejos § Reducir el número de estados y transiciones § Codificar un número de “frases” comunes y algo complejas § Acciones Entrada/Salida, transiciones interna, actividades. 167

Acciones Entrada/Salida § Enviar la misma acción cada vez que entra a un estado: § En el símbolo poara el estado, incluir una acción de entrada marcada con la palabrar reservada entry § Enviar la misma acción cada vez que se sale del estado. § En el símbolo para el estado, incluir una acción de salida marcándola con la palabra reservada exit § Las acciones de entrada y saldia pueen no tener argumentos o condiciones de guarda. 168

Transiciones Internas § Los eventos ocurren dentro del estado pero son manejados sin salir del estado. § Diferente que auto-transiciones § Auto-transiciones: un evento dispara la transición, el estado es abandonado, una acción (si existe) es despachada, el mismo estado es reingresado. Una auto-transición despacha la acción de salida del estado y despacha la acción de entrada al estado. § Transición interna: si el evento es disparado, la acción correspondiente es despachada SIN abandonar y reentrar al estado. § Las transiciones internas pueden tener eventos con parámetros y condiciones de guarda, las transiciones 169

Actividades § Las actividades son las que se ejecutan mientras el objeto está en un estado, esperando que un evento ocurra. § La transición Do especifica el trabajo que necesita ser realizado dentro de un estado luego que la acción de entrada es despachada. § La actividad de una transición do podría ser § Nombrar otra máquina de estados, § Especificar una secuencia de acciones. § Las acciones no son interrumpibles pero las secuencias de acciones sí. 170

Sensorwarning / Blockmotor Stop-bell ringing silent opening Do/activate-motor-till-closed Entry/Ring-bell Exit/Stop-bell Ring-bell Open closed open closing Do/Activate-motor-till-open Sensor. Warning/Blockmotor Entry/Ring-bell Exit/Stop-bell Close 171

Subestados § Superestados pueden ser introducidos para agrupar un número de estados. Todos los subestados heredan cualquier transición de los superestados. El uso de superestados hace los diagramas más leíbles. § Los diagramas de estados concurrentes combinan diferentes comportamientos diferentes de un objeto dado. Un objeto pude estar en diferentes estados, cada uno forma una sección concurrente en el diagrama 172

Subestados Secuenciales (1) § Subestados Secuenciales: los estados compuestos pueden ser introducidos para agrupar a varios estados. § Si el objeto es un estado compuesto, es solamente uno de sus subestados a un tiempo dado. (subestados son disjuntos) § Transiciones que llevan fuera de un estado compuesto pueden tener como fuente el estado compuesto o un subestado. En el primer caso, el control primero deja el estado animado, luego deja el estado compuesto. § De una fuente fuera del estado compuesto, una transición pude ser destino de un estado compuesto 173 o subestado.

Subestados Secuenciales (2) § Si el destino es un estdo compuesto, este debe incluir toda el estado inicial al cual pasar el control leugo de entrar al estado compuesto y luego despachar su acción de entrada (si existe) § Si en el destino hay un subestado, el control pasa al subestdo luego de despachar la acción de netrada (si existe) del estado compuesto y luego la acción de entrada (si exsite) del subestado. 174

[Account. Ok] / New, Put. Green, Open Cancel Enter / Card. Ok? idle Cancel checking-card [Card. Ok] / Account. Ok? Cancel [after 30 sec] [not Card. Ok] refusing-access checking-account [not Account. Ok] 175

[Account. Ok] / New, Put. Green, Open Cancel idle Enter / Card. Ok? active checking-card [after 30 sec] [not Card. Ok] refusing-access [Card. Ok] / Account. Ok? checking-account [not Account. Ok] 176

Stop-bell ringing silent opening Ring-bell Open Do/activate-motor-till-closed Entry/Ring-bell Exit/Stop-bell closed closing Do/Activate-motor-till-open Entry/Ring-bell Exit/Stop-bell open Close 177

Estados Concurrentes (1) § Estos subestados permiten especificar dos o más máquinas de estados que se ejecutan en paralelo en el contexto de un objeto englobante. § Si un subestado concurrente alcanza el estado final antes que el otro, el control en ese subestado espera a su estado fina. Cuando ambas máquinas de estado anidnadas alcanza su estado final, el control de los subestados concurrentes se une de nuevo en un solo flujo. 178

/ New, Put. Green, Open idle Cancel checking Enter Card. Ok? checking-card [Card. Ok] Account. Ok? checking-account [Account. Ok] 179

Estados Concurrentes (2) § Las transiciones a un estado compuesto se descompone en subestados concurrentes. El control se divide entre tantos flujos concurrentes como subestado concurrentes existen. § La transición de un subestado compuesto descompuesto en subestados concurrentes, el control se une de nuevo en un solo flujo. § Si todos los subestados concurrentes llegan a su fin, o si existe una transición específica fuera del estado compuesto englobante, el control se une de nuevo en un solo flujo. 180

Máquina de estados bien estructurada (1) § Una máquina de estados representa el aspecto dinámico de un objeto individual, representa por ejemplo una instancia de una clase, un caso de uso o todo un sistema. § Es simple y por lo tanto no debería contener estados o transiciones superfluas. § Tiene un contexto limpio y por lo tanto puede tener acceso a todos los objetos visibles a su objeto englobante. § Es eficiente y por lo tanto puede llevar a cabo su comportamiento con un balance óptimo entre tiempo y recursos requeridos por las acciones que despacha. 181

Máquina de estados bien estructurada (2) § Es comprensible y por lo tanto debe nombrarse sus estado y transiciones con vocabulario del sistema § No está profundamente anidado. § Usa pocos subestados concurrentes. 182