Aspectos Avanzados de la Tecnología de Objetos

Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

1 Aspectos Avanzados de la Tecnología de Objetos
2. Fundamentos del modelo de objetos 3ra parte: UML – Diagramas de estado, de actividad, de interacción y de colaboración, Dr. Juan José Aranda Aboy

2 Dr. Juan José Aranda Aboy
Contenidos Ingeniería del software con componentes. Conceptos de objetos. El proceso de desarrollo. El lenguaje unificado de modelado (Unified Modeling Language – UML): Fundamentos de los modelos de casos de uso. Fundamentos de los modelos de clases. Fundamentos de los diagramas de estado y de actividad. Fundamentos de los diagramas de interacción y colaboración. Diagramas de implementación. Paquetes, subsistemas, modelos. Dr. Juan José Aranda Aboy

3 Objetivos específicos
Definir los conceptos de objeto, clase y componente. Caracterizar el proceso de desarrollo. Conocer y emplear adecuadamente el lenguaje unificado de modelado (UML) Dr. Juan José Aranda Aboy

4 Dr. Juan José Aranda Aboy
Introducción Hasta este momento, la unidad 2 – Fundamentos, de nuestro curso ha revisado: Cómo describir los requisitos de un sistema utilizando casos de uso. Cómo modelar la estructura estática del sistema, incluyendo qué clases hay y cuáles mensajes aceptan los objetos de esas clases, utilizando un modelo de clases. Nuestros siguientes pasos son: Modelar las decisiones de los objetos sobre qué hacer cuando se recibe un mensaje, o sea, cuáles son las dependencias existentes entre el estado de un objeto y su reacción ante los mensajes. Modelar la interacción entre objetos para satisfacer los requisitos del sistema, describiendo los mensajes que se intercambian mediante los diagramas de interacción: secuencia y colaboración. Dr. Juan José Aranda Aboy

5 Diagrama de transición de estados
Es un grafo compuesto básicamente por estados y transiciones entre éstos. Cada diagrama de transición de estados: Si se asocia a una clase: Describe la forma en que una instancia de una clase reaccionará ante los eventos que recibe. Recoge todas las posibles “historias de vida” de una clase: sus cursos, típico y alternativos. Si se asocia a un caso de uso: Describe la forma en que funcionará ese caso de uso cuando se ejecute en el sistema. Este diagrama es útil para reflejar el ciclo de vida de clases complejas. Dr. Juan José Aranda Aboy

6 Elementos del diagrama de estados (1)
Evento: Es una ocurrencia que tiene lugar en un momento preciso del tiempo, pero que no tiene duración. Es algo que se le realiza y afecta a un objeto. Suele representarse como un mensaje que una clase envía a otra del sistema. Provocan las transiciones entre estados. Estado: Es el período de tiempo que tiene lugar entre la recepción de dos eventos consecutivos por parte de una clase del sistema. Durante el tiempo que dura, pueden ocurrir: Una acción a la entrada del estado. Una acción durante el tiempo que dura el estado. Una acción al salir de dicho estado. Dr. Juan José Aranda Aboy

7 Elementos del diagrama de estados (2)
Transición: Tiene lugar entre dos estados en los que puede encontrarse una clase. Puede tener una acción y / o una condición de guarda asociada. Además, puede disparar un Evento. Acción: Es un comportamiento que ocurre cuando tiene lugar una transición entre estados. Es algo que hace, que realiza el objeto, como enviar un mensaje. Condición de guarda: Es una expresión lógica (si ó no) formada a partir de combinar valores de los atributos mediante expresiones que permiten que se produzca la transición de estados sólo si se cumple la condición. Siempre que se instancia un objeto de una clase, dicho objeto estará en su estado inicial. Este hecho se denota mediante una marca de creación. De igual manera, el diagrama puede incluir una marca de destrucción asociada con el final de la vida útil del objeto en el sistema. Sin embargo, y a diferencia de cuando se instancia al objeto, puede que existan varias marcas de destrucción ó estados finales del objeto, y también puede ocurrir que no exista ninguna. Dr. Juan José Aranda Aboy

8 Íconos del diagrama de estados
Dr. Juan José Aranda Aboy

9 Ejemplo de la Biblioteca: Estados de las clases Copia y Libro
Dr. Juan José Aranda Aboy

10 Dr. Juan José Aranda Aboy
Tipos de eventos Evento de llamada (<<call>>): El receptor de un mensaje solicita que se ejecute una operación. Evento de cambio (<<when>>): ocurre cuando cambia una condición de falso a verdadero. Útil para describir situación de cambio de estado por que el objeto altera el valor de sus atributos después de recibir la respuesta a un mensaje que envió, en vez de cómo resultado inmediato del objeto que recibe un mensaje. Evento de señal (<<signal>>): Producto de la recepción de una señal. Puede tener parámetros. Evento de tiempo (<<after>>): Expresión que denota el tiempo que tiene que pasar después de un evento con nombre. Dr. Juan José Aranda Aboy

11 Ejemplo con diagrama detallado
Dr. Juan José Aranda Aboy

12 Dr. Juan José Aranda Aboy
Comentarios Los diagramas de estado son útiles para comprender como depende del estado en que está el objeto su reacción ante un mensaje. A veces, la ocurrencia del mismo evento en el mismo estado puede o no provocar cambio de estado. El diagrama de estados de una clase debe ser muy simple: mientras exista mayor dependencia del comportamiento, es mas difícil comprenderlo, escribir correctamente el código y probar la clase. También se dificulta mas para el código externo utilizar una clase correctamente si el comportamiento de la clase depende de una entrada compleja. En algunos casos es aconsejable dividir una clase con muchos estados en varias clases con comportamiento mas sencillo, lo que – según las circunstancias- puede resultar en una mejora, particularmente si se muestran como clases correctas. Puede ser mas fácil crear y borrar nuevos objetos transformando un objeto de una clase en objeto de otra. Probablemente lleve a un buen diseño. Dr. Juan José Aranda Aboy

13 Diagramas de actividad (1)
Describen como se coordinan las actividades. Almacenan las dependencias que existen entre actividades, tales como cuáles tareas pueden desarrollarse concurrentemente (en paralelo) y qué debe estar terminado para que otra tarea pueda comenzar. Pueden utilizarse para indicar cómo puede implementarse una operación. Su bloque fundamental es una actividad. La transición entre actividades indica que se completó una actividad. Su utilidad está cuando se conoce que una operación tiene que alcanzar varias cosas distintas y se quiere modelar cuáles son las dependencias fundamentales entre ellas, por lo que debe decidirse en que orden se realizan. También son útiles para describir cómo se exponen los casos de uso individuales y su dependencia con otros casos de uso, debido a que los casos de uso no suceden arbitrariamente, sino como parte del flujo de trabajo general de un área de actividades. Son muy útiles para modelar el negocio. Dr. Juan José Aranda Aboy

14 Diagramas de actividad (2)
Los restantes elementos presentes en estos diagramas son: Barra de sincronización: Describe la coordinación entre actividades. Una vez terminadas todas las actividades que tienen transiciones dirigidas a la barra, puede continuarse. Equivale a que todas las actividades dirigidas a la barra se han activado. Proporciona una manera de expresar cosas: Unión: Esperar a que terminen subtareas antes de continuar. División: Empezar varias tareas en paralelo. Diamante de decisión: Utilizado para representar decisiones, como alternativa a las guardas de transición separadas que abandonan el mismo estado. Marcas de creación y destrucción: Se utilizan como en el diagrama de estados. Dr. Juan José Aranda Aboy

15 Diagramas de actividad (3)
Las principales diferencias entre los diagramas de actividad y los de estado son: Los diagramas de actividad no incluyen eventos, dado que el único evento de interés es el final de las actividades, que no tiene que aparecer de forma explícita. El diagrama de actividad pretende mostrar la continuidad, siguiendo el flujo descrito por el diagrama. Ejemplo: Si hay guardas en las transiciones salientes de una actividad, normalmente sólo se cumple una de ellas. Esto es diferente a la filosofía de los diagramas de estado, donde es posible a menudo que un objeto no alcance nunca alguno de sus estados potenciales: no hay ninguna secuencia correcta de estados especificada. Dr. Juan José Aranda Aboy

16 Ejemplo: Actividad de la Biblioteca a nivel de negocio
Dr. Juan José Aranda Aboy

17 Colaboración entre objetos
Los diagramas de interacción permiten almacenar en detalle como interactúan los objetos para ejecutar una tarea. Muestran como el sistema realiza casos de uso, o un escenario en particular en un caso de uso. Ayudan a la comunicación entre desarrolladores. Existen dos tipos: Diagramas de colaboración. Diagramas de secuencia. Dr. Juan José Aranda Aboy

18 Diagrama de colaboración (1)
Los objetos que interactúan para ejecutar una tarea, así como los enlaces entre ellos se conocen como colaboraciones. El diagrama de colaboración es útil para mostrar los efectos que puede tener un objeto sobre los demás, así como para el diseño de bajo nivel, en seudo código, de los procedimientos. Contiene la misma información en dinámica que el diagrama de secuencia, pero suele ser mas legible. Muestra: Objetos: instancias de clases. Puede haber mas de un objeto de la misma clase. Enlaces: operaciones que realizan los objetos, las cuáles aparecen como asociaciones en el modelo de clases. Actores: Si la colaboración describe un caso de uso, corresponden con los actores del caso de uso. Puede haber varios actores, pero siempre habrá uno que inicia la colaboración: actor iniciador del caso de uso. Dr. Juan José Aranda Aboy

19 Diagrama de colaboración (2)
Dr. Juan José Aranda Aboy

20 Colaboraciones de la Biblioteca con NetBeans 5.5
Dr. Juan José Aranda Aboy

21 Diagramas de secuencia (1)
Representa la interacción entre clases del modelo ordenada temporalmente. Se lee de izquierda a derecha y de arriba hacia abajo. Muestra los objetos y actores que participan en una colaboración, así como la línea de vida, que representa el tiempo visto por el objeto. Se supone que el tiempo pasa desde arriba hacia abajo, según lo vemos en el modelo. Este modelo será mas legible si se colocan los objetos participantes de izquierda a derecha según su orden de participación. Los mensajes aparecen como flechas entre la línea de vida del objeto emisor y la del objeto receptor. Dr. Juan José Aranda Aboy

22 Diagramas de secuencia (2)
Normalmente, cada caso de uso tiene asociado varios diagramas de secuencia: Representando al caso típico y uno ó mas por cada posible alternativa. Se recomienda hacer al menos el caso típico, ya que ayudará a comprender el funcionamiento del sistema. Reflejan el comportamiento del sistema al vincular implicaciones entre clases. Se utilizan especialmente cuando se trata de sistemas en tiempo real. Pueden ser excesivamente grandes si intervienen muchas clases, lo cual hace que se pierda visibilidad. NOTA: ArgoUML no los ha desarrollado plenamente. Dr. Juan José Aranda Aboy

23 Ejemplo de secuencia en la Biblioteca
Dr. Juan José Aranda Aboy

24 Variantes del envío de mensajes en un diagrama de secuencia
Tipo de interacción Símbolo Significado Sincrónico o llamada (call) Situación procedural normal. El emisor pierde el control hasta que el receptor termina de mantener el mensaje. Entonces recupera el control. Retorno (return) No es un mensaje, sino que es el retorno de un mensaje anterior. Desbloquea un envío sincronizado. Plano El mensaje no espera una respuesta. El control pasa del emisor al receptor de manera que el siguiente mensaje en este hilo será enviado por el receptor de este mensaje. Asincrónico El mensaje no espera una respuesta, pero el emisor permanece activo y puede enviar mas mensajes. Dr. Juan José Aranda Aboy

25 Creación y borrado de objetos
El conjunto de objetos implicados en una interacción es dinámico: pueden crearse y / o borrarse objetos. Los diagramas de colaboración muestran que objetos se crean (new) y se destruyen (destroy). De igual modo, los diagramas de secuencia muestran los puntos donde se crea ó se destruye un objeto. Los mecanismos para creación y borrado de objetos son dependientes del lenguaje: Java y SmallTalk son colectores de basura (garbage collector), por lo que se destruyen automáticamente los objetos no referenciados en un tiempo. En otros lenguajes, como C++, debe explicitarse el proceso de destrucción. El diseño debe especificar donde está la responsabilidad de destruir cada objeto. Dr. Juan José Aranda Aboy

26 Dr. Juan José Aranda Aboy
Ley de Demeter ¿Dónde deben colocarse los mensajes? La ley de Demeter establece que, como respuesta a un mensaje M, un objeto O debería enviar mensajes solamente a: Si mismo (self). Los objetos enviados como argumentos en el mensaje M. Los objetos que O crea como parte de su reacción ante M. Los objetos que son accesibles directamente desde O, es decir, utilizando los valores de los atributos de O. Esta ley ayuda a desarrollar modelos que son mas fáciles de mantener. Dr. Juan José Aranda Aboy

27 Comportamiento condicional e iteración
Un mensaje puede ser guardado por una condición: sólo se envía si la guarda es verdadera cuando el sistema llega a ese punto en la interacción. Varios mensajes pueden partir del mismo punto de la línea de vida del emisor, guardados pos condiciones diferentes. En un sistema secuencial se debe asegurar que las diferentes condiciones son excluyentes: sólo una condición puede ser verdadera. En otro caso, se describe un sistema concurrente, donde se envían varios mensajes a la vez. Si un objeto envía un mensaje repetidas veces a otro, y este número es fijo para todos los escenarios del caso de uso, se puede colocar este número en los diagramas de interacción. Se necesita una estructura de bucle ó iteración. Dr. Juan José Aranda Aboy

28 Dr. Juan José Aranda Aboy
Concurrencia Si con cada mensaje el objeto emisor espera por una respuesta para continuar sus acciones, el sistema se llama procedural ó mono-hilo (thread), debido a que hay un procedimiento paso a paso con un único hilo ó secuencia de ejecución. Es el caso típico en la mayoría de los sistemas que desarrollamos. Sin embargo, existen muchos sistemas que no son mono hilo: Sistemas distribuidos, donde el cálculo se realiza de forma simultánea en y por diferentes procesadores. Aplicaciones multihilo, en las que varios hilos de ejecución actúan en paralelo, como el caso del los servidores de páginas Web. Sistemas reactivos, que obtienen la entrada (datos ó eventos) del entorno de varias maneras, y tienen que reaccionar, a menudo, satisfaciendo restricciones de tiempo real. Ejemplo: juegos. Estos tópicos se estudiarán en la unidad 7: Concurrencia y Distribución. Dr. Juan José Aranda Aboy

29 Referencias en Internet
Desarrollo Orientado a Objetos con UML Tutorial de UML DCC UChile (versión ZIP) Introducción a UML UML con ArgoUML y Poseidon UML® Resource Page TOUR POR UML Programación: Ingeniería de Software: ¿Qué es UML? UML: Análisis y Diseño Orientado a Objetos UML Guía Visual Base de Datos y UML Dr. Juan José Aranda Aboy

30 Referencias sobre herramientas para UML (en inglés)
ArgoUML Tutorial ArgoUML: Building a Use Case Diagram NetBeans 5.5 UML Modeling Documentation EclipseUML Free Edition MyEclipse UML (comercial) Poseidon for UML (comercial) Rational software (comercial) Visual Paradigm for UML (comercial) MagicDraw UML (comercial) Borland® Together® Visual Modeling for Software Architecture Design (comercial) Enterprise Architect Modelado avanzado con UML 2.1 (comercial) (versión demostrativa) (Recursos) Objects by design: UML Products by Price Dr. Juan José Aranda Aboy