Modelos dinamicos Orientado a Objetos

CAPIS REPORTES TECNICOS

MODELO DINAMICO EN ORIENTACION A OBJETOS

Maestrando: Ing. Alejandro Hossian

1. INTRODUCCIÓN Este artículo tiene como objetivo presentar una breve introducción acerca del modelado de los aspectos dinámicos de un sistema bajo el paradigma de la Orientación a Objetos para el Análisis y el Diseño, proporcionando un caso práctico a tal efecto. Es importante destacar el papel fundamental que juega el modelo dinámico en el desarrollo de sistemas, ya que a través del mismo podemos examinar aquellos aspectos de comportamiento de un sistema que cambian con el tiempo. El presente artículo, tratará de proporcionar un marco general sobre los conceptos fundamentales que nos servirán de guía en el modelado de los aspectos dinámicos de un sistema. Los temas que abordaremos en éste artículo son los siguientes: En el ítem 2 comenzaremos con una breve introducción acerca del modelo dinámico y su relación con el modelo de objetos, que es el modelo sobre el cuál operará el modelo dinámico. Luego se hará una breve mención sobre las ventajas que ofrece el modelo dinámico (ítem 2.1) para después abordar en forma general aquellos conceptos que nos permitirán la construcción del modelo dinámico, cómo ser los sucesos y estados (ítem 2.2), escenarios (ítem 2.3) y diagramas de estado (ítem 2.4) . Luego en el ítem 3 trataremos de aplicar éstos conceptos para la construcción del modelo dinámico a un caso práctico. Comenzamos por la construcción del modelo de objetos (ítem 3.1), siguiendo con la realización de los diagramas de escenarios (ítem 3.2) y los diagramas de estado (ítem 3.3). Luego se refinarán aquellos diagramas de estado que se consideren relevantes en el dominio de la aplicación, realizando los diagramas de estados anidados correspondientes (ítem 3.4). También haremos mención a la concurrencia y sincronización de estados dentro de un objeto (ítem 3.5) En el ítem 3.6, trataremos de explicar tres elementos que contribuyen al enriquecimiento del modelo dinámico, aportando detalles adicionales a los diagramas de estado. En el ítem 4, presentamos las conclusiones del artículo y en el ítem 5 la bibliografía consultada. 2. MODELO DINÁMICO Y MODELO DE OBJETOS Algunos principios fundamentales del modelado son los siguientes: - Un modelo constituye una abstracción de la realidad. - Dado que los modelos omiten los detalles no esenciales, resulta más sencillo

manipularlos a ellos que a la entidad original. - Un modelo puede expresarse a diferentes niveles de precisión.


A partir de éstas consideraciones, se desprende que al Modelo Dinámico no le resultan ajenos los requisitos expuestos, cabiéndole la importante responsabilidad de describir aquellos aspectos de un sistema que cambian con el tiempo. Es decir, que el Modelo Dinámico se utiliza para especificar e implementar los aspectos del control del sistema, colaborando de ésta manera en describir las secuencias de operaciones que se producen, sin tener en cuenta lo que hagan éstas operaciones, aquello a lo que afecten o la forma en que las mismas estén implementadas. Cabe aclarar, que el modelado del aspecto dinámico de un sistema no constituye una característica exclusiva del paradigma orientado a objetos, dado que también puede ser abordado a través del enfoque del Análisis Estructurado. En el caso que nos ocupa, nuestro Modelo Dinámico operará sobre el Modelo de Objetos que resulta ser el más importante, dado que bajo el enfoque de orientación a objetos, la construcción de nuestro sistema se hará en torno a ellos y no a la funcionalidad del mismo. Y será precisamente la identificación de los objetos procedentes del dominio de la aplicación, el principal centro de atención del analista, para luego ajustarle a dichos objetos los procedimientos. Tales afirmaciones, están sustentadas en principios fundamentales del modelado orientado a objetos, como ser la expresa necesidad del Modelo de Objetos para poder describir “QUE” está cambiando o transformándose, antes de describir “CUANDO” y “COMO” cambia. Así cómo también el mejor soporte de la evolución de los requisitos que provee el enfoque orientado a objetos, dado que está basado en el entorno subyacente del dominio de la aplicación en sí, más que en los requisitos funcionales de un único problema. El Modelo de Objetos cumple la función primordial de capturar la estructura estática (de datos), de los objetos del sistema (identidad, atributos y operaciones), así cómo también sus relaciones. La metodología OMT (Técnica de Modelado de Objetos), cuyo creador es James Rumbaugh, incorpora el llamado Modelo Funcional después de haber modelado la estructura estática (Modelo de Objetos) y la estructura dinámica (Modelo Dinámico). Este modelo funcional describe las transformaciones de valores de datos que ocurren dentro del sistema es decir, que es responsable de capturar lo que hace el sistema independientemente de cuándo se haga o de la forma en qué se haga. OMT emplea tres clases de modelos para describir el sistema, a saber: DESCRIBE “QUE” ESTÁ CAMBIANDO EL MODELO DE OBJETOS CONTIENE DIAGRAMAS DE OBJETOS DESCRIBE “CUANDO” CAMBIA EL MODELO DINAMICO CONTIENE DIAGRAMAS DE ESTADO DESCRIBE “COMO” CAMBIA EL MODELO FUNCIONAL CONTIENE DIAGRAMAS DE FLUJOS DE DATOS


2.1 Ventajas del Modelo Dinámico Las relaciones dinámicas no resultan sencillas de comprender en muchas aplicaciones, por lo que la fase de análisis dinámico es una etapa importante en lo que se refiere a los cambios de los objetos y sus relaciones en el tiempo, en ella se pretende describir: - Las relaciones temporales y de eventos entre los objetos del sistema. - Los estados de los objetos, es decir, lo que se refiere a sus cambios

internos a lo largo del desarrollo de la aplicación . - Las acciones efectuadas por los objetos en un cierto contexto. - Las acciones de los sistemas externos sobre los objetos del sistema en

estudio, así como las reacciones de dichos objetos . 2.2 Sucesos y Estados Los conceptos más importantes del Modelo Dinámico son los sucesos, que representan estímulos externos, y los estados que hacen referencia a los valores de los objetos. Más precisamente podemos afirmar, que un suceso es un estímulo individual proveniente de un objeto y que llega a otro, pudiendo ser éste un objeto del sistema o externo al mismo. Sea cual fuera su origen, un evento puede dirigirse hacia uno o más objetos, o incluso no poseer un destino preciso en el sistema, con lo que ciertos objetos del sistema pueden captarlo. La respuesta de un objeto a un suceso que le llega depende del estado del objeto receptor, el cual reaccionará en función del contexto de la aplicación, pudiendo ocurrir lo siguiente: - Un cambio de estado en el objeto receptor. - Desencadenar un mensaje (envío de otro suceso) al remitente ó a un

tercer objeto . Un suceso se produce en un instante dado, y si bien podemos afirmar que no tienen duración (a diferencia de los estados) , decimos que se produce muy rápidamente en comparación con la granularidad de la escala temporal de un abstracción determinada . En cuánto a los estados, decimos que constituyen una abstracción de los valores de los atributos y de los enlaces de un objeto. Durante el transcurso del desarrollo de una aplicación y en función de las opciones elegidas por los usuarios, un objeto puede pasar por varios estados o mantenerse en un estado inicial. El estado tiene duración, se corresponde con un intervalo de tiempo entre dos sucesos recibidos por un objeto y se lo asocia con actividades continuas, como puede ser el sonido de una alarma o con actividades que demoren un cierto tiempo en concluir, tal como un viaje en auto entre dos lugares. El suceso no tiene duración y decimos que representan puntos temporales, como ser pulsar un botón para desactivar la alarma o encender el auto. Por lo que podemos concluir que sucesos y estados son duales entre sí, es decir que un suceso separa a dos estados y un estado separa a dos sucesos.


Esto se puede observar en el diagrama de estados de FIG 1 en página 7, dónde el suceso conexión separa los dos estados del foco del automóvil (Apagado y Desconexión), mientras que el estado Encendido, por ejemplo, separa los dos sucesos de Conexión y Desconexión. 2.3 Escenarios Un escenario constituye una secuencia de sucesos ordenados en el tiempo que simulan una ejecución particular del sistema. Utiliza dos conceptos importantes: - Objetos que forman parte del sistema (no necesariamente todos se van a representar en el diagrama de escenarios) y objetos externos al sistema y que interactúan con éste . - Sucesos emitidos y recibidos por los objetos implicados en el escenario. Los escenarios permiten experimentar las ejecuciones del sistema, por lo que resultan muy útiles para las fases de pruebas y mantenimiento. Posteriormente veremos la aplicación de los diagramas de escenarios en un caso práctico, los cuáles están referenciados en FIG 5 y FIG. 2.4 Diagramas de Estado Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones entre estados causadas por sucesos. De ésta definición se desprende que una transición constituye un cambio de estado causado por un suceso, es decir que si un objeto se encuentra en un cierto estado y se produce un suceso cuyo nombre corresponda al de una de sus transiciones, entonces el objeto pasa al estado que se encuentra en el extremo de destino de la transición. Decimos que la transición se dispara. El Modelo Dinámico consta de múltiples diagramas de estados, con un diagrama para cada clase que tenga un comportamiento dinámico relevante dentro del dominio de la aplicación, mostrándonos la trama de actividad de todo el sistema. Es decir, que debemos concentrarnos en clases de objetos que tengan interacciones importantes, de lo que se desprende que no todas las clases necesitan un diagrama de estados, así por ejemplo, si el objeto solo posee un estado inicial y otro final, no será de utilidad su diagrama de estados. Los estados los representamos por un rectángulo de esquinas redondeadas con el nombre del estado y las transiciones por medio de flechas desde el estado receptor hasta el estado destino, dónde el rótulo de la flecha hace referencia al nombre del suceso que da lugar a la transición, debiéndose destacar que todas las transiciones que salgan de un estado deben de corresponder a sucesos distintos. Por ejemplo, éste podría ser el diagrama de estados de un foco de automóvil, dónde el suceso conexión – desconexión es la secuencia del suceso conexión seguido por el suceso desconexión.


Conexión Apagado Encendido Desconexión

FIG 1 A su vez, los diagramas de estado pueden representar ciclos vitales únicos o bien bucles continuos. Los diagramas de un solo uso representan objetos de duración finita y poseen estados iniciales y finales, entrándose en el estado inicial al crear el objeto y cuándo se ingresa en el estado final se implica la destrucción del objeto. El estado inicial se representa mediante un círculo negro, el cuál puede estar rotulado para indicar diferentes condiciones iniciales. El estado final se expresa por un círculo blanco con centro negro, cuyo rótulo también indicaría distintas condiciones finales. Cómo ejemplo de diagrama de un solo uso, podemos ver el ciclo vital simplificado de un juego de ajedrez representado en la FIG 2. Comienzo Jaque Mate Ganan Piensan las las Blancas Rey Ahogado Negras Mueven las Mueven las Negras Blancas Tablas Piensan las Rey Ahogado Ganan Negras las Jaque Mate Blancas FIG 2 Cabe aclarar, que los diagramas de un solo uso los podemos considerar cómo una subrutina del diagrama de estados, a la cuál se puede hacer alusión desde diferentes lugares en un diagrama de alto nivel. En los diagramas que representan bucles continuos, en general se desconoce y carece de importancia la forma en que comienza el bucle. Por ejemplo, el diagrama de estados que describe el comportamiento de una línea telefónica representado en FIG 3 constituye un bucle continuo que muestra la utilización normal del teléfono. El diagrama de FIG 3, contiene las secuencias asociadas a llamadas normales así cómo algunas secuencias anormales, tales cómo que se agotó el tiempo mientras se marca.


También podemos observar, que el suceso “colgar” da lugar a una transición desde cualquier estado hasta el estado en reposo , circunstancia ésta que se manifiesta en el diagrama con una cuantas transiciones que llevan hasta el reposo . Colgar Colgar Libre Descolgar Tiempo Agotado Tiempo Tono de Marcar Agotado Dígito n Tiempo Agotado Dígito n Mensaje Marcando Número no Válido Grabado Número Número Válido Línea Ocupado Ocupada Mensaje Conectado Finalizado Señal de Red Ocupado Sobrecargada Encaminando Sonando Responde el Teléfono Llamado Conectado Cuelga el Teléfono Llamado Desconectado

FIG 3 3. CONSTRUCCIÓN DEL MODELO DINÁMICO Para ilustrar éstos conceptos básicos acerca del Modelo Dinámico, se desarrollará un caso práctico simple a partir del modelo de objetos y se avanzará sobre algunos conceptos mas avanzados del Modelo Dinámico, como anidamiento de estados, atributos, centinelas y operaciones.


3.1 Modelo de Objetos Supongamos un objeto persona que posee un nombre, una dirección y un cargo y que puede trabajar o no para una empresa y que también podrá ser contactado por una agencia de colocación para recibir una o mas propuestas de empleos. Las palabras subrayadas indican las clases de objetos a modelar. Representamos la asociación “muchos a muchos” entre la clase Persona y la clase Agencia por un asterisco * en ambos extremos de clase, y la asociación muchos a uno entre la clase Persona y la clase Empresa por un asterisco * en el extremo Persona y 0..1 en el extremo Empresa (que denota que una persona podrá trabajar para ninguna o a lo sumo para una empresa). Construyamos el modelo de objetos para ésta aplicación en FIG 4: Persona Contactar Para * Nombre * Trabajar Para Dirección Propuesta Cargo * 0..1 Agencia Empresa Nombre Nombre Dirección Dirección FIG 4 Los símbolos * y 0..1 se refieren a las cardinalidades, así es que el símbolo * lo utilizamos para representar un conjunto de valores potencialmente infinito, es decir 0 o más. Por ejemplo, en el diagrama de objetos de FIG 4 se indica que una persona puede ser contactada por 0 o más agencias y que una agencia puede contactar a 0 más personas. Así como también, que en una empresa pueden trabajar 0 más personas. El símbolo 0..1 indica que 0 o 1 objetos de la clase a la que le corresponde la cardinalidad pueden estar relacionados con los objetos de otra clase. Para el diagrama de objetos en FIG 4 tenemos que una persona puede trabajar para 0 o una empresa a lo sumo. 3.2 Diagramas de Escenarios o de Secuencia de Sucesos Este diagrama muestra cada objeto como una línea vertical y cada suceso como una flecha horizontal que va desde el objeto emisor hasta el objeto receptor, efectuándose la lectura secuencial en orden descendente. El tiempo va en aumento desde arriba hacia abajo, aunque debemos aclarar que el espacio entre las flechas representativas de los sucesos, carece de importancia. Es decir, que lo único que se visualizan son las secuencias de sucesos sin hacer referencia a su temporización exacta. Es de destacar, que los objetos que intervienen en los escenarios son instancias, por lo que es necesario especificar su nombre y su clase, a partir de lo cual podemos afirmar que:


“Un escenario es al Modelo Dinámico lo que un diagrama de instancias es a un Modelo de Objetos” En el marco de la aplicación que gestiona la asignación de puestos, cuyo diagrama de clases es el que se presenta en la FIG 4 el siguiente escenario hace intervenir a los tres objetos del sistema , a saber : la instancia Costas de la clase Persona , la instancia Baner de la clase Empresa y la instancia Sima de la clase Agencia . El suceso original de éste escenario es la búsqueda de un perfil de desarrollador en Java efectuada por la empresa Baner a la agencia Sima. Trás la correspondiente petición, Sima envía la propuesta al señor Costas quien establece contacto con Baner para solicitar entrevista. Luego de la convocatoria efectuada por la empresa al señor Costas, éste acude a la entrevista. Posteriormente, la empresa Baner realiza un balance de dicha entrevista y decide asignar el puesto al señor Costas, quien lo notifica a la agencia Sima. La traza de sucesos de FIG 5 representa una asignación de puesto: Buscar desarrollador en Java Llegada Propuesta Petición de Entrevista Convocatoria Asistencia a Entrevista Perfil del Entrevistado Asignación de Puesto Notificación de Contratación Sima (Agencia) Costas (Persona) Baner (Empresa)

FIG 5 Supongamos ahora una situación dónde una instancia del objeto Empresa rechaza la asignación de una instancia del objeto Persona. Dicha situación sería de utilidad ilustrarla con la implementación de otro modelo de escenario. En éste caso, la secuencia de sucesos podría ser la siguiente: un suceso disparador similar al caso anterior, en el cuál la Empresa Soft.SA se dirige a la agencia Zeta para un puesto de Gerente de Sistemas. Como respuesta, ésta agencia le envía a Soft.SA el currículum – vitae del señor Tass.


Entonces la empresa convoca al postulante para una entrevista, tras la cuál Soft .SA , luego de efectuar un balance de la misma , decide no asignar el puesto al señor Tass y le comunica su decisión . Asimismo, la empresa Soft.SA le notifica a la agencia Zeta el rechazo de asignación. La traza de sucesos de FIG 6 representa un rechazo de asignación de puesto: Buscar Gerente de Sistemas Enviar Curriculum vitae del señor Tass para éste puesto Convocatoria Asistencia a Entrevista Perfil del Entrevistado Rechazo de Asignación de Puesto Notificación de Rechazo de Asignación Zeta (Agencia) Tass (Persona) Soft .SA (Empresa) FIG 6 Basados en un formalismo claro e intuitivo, los escenarios facilitan la comprensión del funcionamiento del sistema, y en particular son útiles en la descripción de los casos de error y casos límite de uso del sistema. 3.3 Diagramas de Estado Siempre dentro del contexto del modelo de objetos de nuestro ejemplo, nos interesaremos más acerca de los estados del objeto Persona. Identificamos tres estados diferentes, dependiendo por una parte del valor del atributo Cargo y por otra de los enlaces de éste objeto Persona con un objeto Empresa y con uno o más objetos Agencia. - Estado CONTRATADO: el objeto persona pasa a éste estado cuándo: el atributo Cargo tiene un valor distinto de “Sin Cargo” , cómo por ejemplo “administrativo” , “gerencial” , “informático” , etc ; y por otra parte cuándo el objeto Persona posee un enlace Trabajar Para con un objeto Empresa. Además de éstas dos características, el objeto Persona en el estado Contratado puede poseer un enlace Contactar Para con uno o más objetos Agencia. - Estado BUSQUEDA: el objeto Persona pasa a éste estado cuándo: el valor del atributo Cargo es “sin Cargo” y además el objeto Persona, no tiene ningún enlace Trabajar Para con un objeto Empresa ni tampoco Contactar Para con uno o más objetos Agencia. - Estado SELECCIÓN: el objeto Persona pasa a éste estado cuándo: el valor del atributo Cargo es “sin Cargo” y no tiene un enlace Trabajar Para con un objeto Empresa, pero tiene un enlace con uno o más objetos Agencia.


Los sucesos asociados con los cambios de estado son los siguientes: - El “Despido” efectuado por una Empresa sobre un objeto Persona. - La llegada de una “Propuesta de Trabajo” desde una agencia (externo). - La “Asignación de un Puesto” a una Persona por una Empresa. - El “Rechazo de Asignación” de un puesto por parte de una Empresa. - La “Dimisión” de una Persona en una Empresa. La trama de sucesos, estados y transiciones de éstos estados para el objeto Persona , se representa en el diagrama de estados de FIG 7 : Llegada Propuesta CONTRATADO Dimisión Asignación Despido Puesto Llegada Propuesta BUSQUEDA Rechazo Asignación SELECCION

FIG 7 3.4 Diagramas de Estados Anidados A los diagramas de estado como los de FIG 7 en página 13, se los llama diagramas de estados planos o no estructurados. Dichos diagramas aportan información general sobre los estados por los que atraviesa un objeto y puede que dicha información sea suficiente en algunos casos. Pero en determinadas circunstancias, puede ser necesario asociarle a un determinado estado de un objeto diversos subestados, a efectos de poder precisar con mayor detalle dicho estado. Esta necesidad de obtener mayor información acerca de un estado, se tratará de satisfacer asociándole diferentes subestados a cada estado que el analista considere que le corresponden niveles de granularidad distintos. Lo que se conoce como anidamiento de diagramas de estados. Así es que al estado SELECCIÓN del objeto Persona lo podemos precisar por los trés subestados : Candidato a Entrevista, Entrevistado y Evaluado . Los subestados de un objeto se relacionan entre sí en un diagrama dinámico, de igual manera que los estados que precisan o especializan. El anidamiento unos en otros de los diagramas de estado, facilita una lectura más profunda acerca del comportamiento dinámico de los objetos. El diagrama de estado anidado del estado SELECCIÓN lo podemos observar en FIG 8 en página 14:


Llegada Propuesta Convocatoria Candidato a Entrevista Entrevistado Nueva Propuesta Perfil del Entrevistado Asignación Puesto Evaluado Rechazo Asignación FIG 8 El estado inicial que se representa en éste diagrama por un disco negro lleno, indica el punto de entrada en el estado SELECCIÓN. Observando el diagrama de estado de FIG 7 para el objeto Persona, se ve que el punto de entrada es la transición Llegada Propuesta del estado BUSQUEDA al estado SELECCIÓN. Y siguiendo el mismo hilo de razonamiento, se deduce que los estados finales representados en el diagrama por un disco negro rodeado por un círculo corresponden a las transiciones Rechazo Asignación y Asignación Puesto, las cuáles desencadenan los cambios desde el estado SELECCIÓN a los estados BUSQUEDA y CONTRATADO respectivamente. En éste último diagrama de FIG 8 en página 14, se puede observar que el postulante podrá ser citado nuevamente a otra entrevista si la empresa así lo considera, después que dicho postulante haya asistido a la entrevista y la empresa haya realizado el correspondiente balance de la misma. Esta circunstancia se vislumbra en el diagrama a través del suceso Nueva Propuesta, el cuál desencadena la transición desde el estado Evaluado al estado Candidato a Entrevista. Cabe destacar que previamente, el postulante pasó al estado Evaluado desde el estado Entrevistado a causa del suceso Perfil del Entrevistado, que es el que desencadena dicha transición. 3.5 Concurrencia y Sincronización de Estados Nos referiremos a la concurrencia dentro de un objeto, esto se debe a que en ciertas situaciones de modelado es preciso especificar subestados concurrentes, los cuáles a su vez, permiten especificar dos o más estados que se ejecutan en paralelo en el contexto del objeto que las contiene y en un mismo estado. Si los subdiagramas están en concurrencia, el primer subdiagrama que permite que se efectúe la transición del estado englobante hacia otro estado, interrumpe los demás subdiagramas causando la salida del estado englobante. Cuándo el objeto Persona está en el estado BUSQUEDA, podemos imaginarla realizando diversas operaciones en paralelo, cómo ser las gestiones pertinentes en la Agencia de colocación (supongamos que la persona deba inscribirse en la agencia y de ser aceptada su inscripción deberá proceder a realizar un curso de capacitación) y las gestiones individuales que dicha persona realiza en el marco de su búsqueda de empleo (cómo la búsqueda en periódicos etc). La FIG 9 nos muestra la concurrencia para el estado BUSQUEDA:


BUSQUEDA Inscripción en Inscripción Realizar Llegada Propuesta Agencia Aceptada Curso por Agencia - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ó SELECCION Búsqueda en Periódicos Llegada Propuesta por Periódico

FIG 9 Los subestados Inscripción en Agencia y Realizar Curso son secuenciales, es decir que en el marco de las gestiones que el postulante realiza en la Agencia, su estado es de Inscripción ó de Realizar Curso. Ambos estados, a su vez, están en concurrencia con el subestado Búsqueda en Periódicos, ya que dos tipos de eventos independientes pueden encontrarse en el origen de la transición hacia el estado SELECCIÓN: una Llegada de Propuesta por Agencia Ó una Llegada de Propuesta por Periódico. Cualquiera de las dos transiciones que se dé primero, hará que concluyan los subdiagramas concurrentes, ya que ambos forman parte de un mismo estado compuesto BUSQUEDA y solamente se encuentran activados cuándo el diagrama de estados de más alto nivel está en ese estado. Los diagramas de estados concurrentes son útiles si un objeto dado tiene conjuntos de comportamientos independientes. Si los subdiagramas están sincronizados, la transición del estado englobante hacia otro estado solo se efectúa cuándo todos los subdiagramas lo permiten, sin poder interrumpir ningún subdiagrama. Llevado a nuestro caso práctico, podemos precisar el estado CONTRATADO del objeto Persona por dos subestados: Trabajando y Licencia, siendo Trabajando el estado englobante que contiene dos subdiagramas que están sincronizados: Pedir Licencia y Ejercer Función. Es decir, que cuándo un objeto Persona se halla en el subestado Trabajando del estado CONTRATADO, pueden desarrollarse dos diagramas de estado simples en paralelo, cómo ser el que gestiona el Pedido de Licencia (Pedir Licencia) y el que describe sus actividades profesionales (Ejercer Función). Asumimos como requisito impuesto por la empresa para que una persona entre en estado de licencia, que se manifiesten dos eventos : el Pedido de Licencia debe ser aceptado Y además que ciertas funciones que le competen a esa persona, deben estar concluidas (por ejemplo, si la persona es la encargada de liquidar sueldos, dicha tarea debe estar terminada antes de que la persona entre en licencia) . El orden en que éstos sucesos se manifiesten carece de relevancia, es decir que los pasos internos de las actividades no están sincronizados, pero dichas actividades deben estar finalizadas antes de que el objeto pueda avanzar hacia el estado siguiente.


La FIG 10 nos muestra la sincronización para el subestado Trabajando : Trabajando Aceptación Pedir Licencia de Licencia - - - - - - - - - - - - - - - - - - - - - - - - - - - Y Licencia Ejercer Función Tareas Terminadas

FIG 10 3.6 Atributos Centinelas y Operaciones Estos tres elementos enriquecen el modelo dinámico, aportando detalles adicionales a los diagramas de estado. Los atributos y centinelas (condiciones) permiten precisar una transición. Así es que los atributos son los valores de datos aportados por un suceso al igual que los valores de datos que contienen los objetos. Es decir, que constituyen la información llevada por los eventos y se representan entre paréntesis después del nombre de la clase de suceso. Los centinelas o condiciones son funciones booleanas lógicas que devuelven verdadero o falso y vendrían a ser cómo protecciones de las transiciones también llamadas guardias, de tal manera que una transición con protección se dispara cuándo se produce su suceso y si el guardia se resuelve como “verdadero” . Esta guardia o protección va entre corchetes después de la lista de atributos del suceso. El suceso se podría representar: suceso (atributos)[centinela], por ejemplo en el subdiagrama del estado CONTRATADO, el suceso Entrada en Licencia puede tener los atributos número de licencia (que indica la cantidad de licencias que tomó el empleado en un período determinado) y cantidad de días solicitada y para que la transición al estado Licencia se dispare, debe cumplirse que éste número esté por debajo de un cierto valor (4 por ejemplo) y que además, la cantidad de días solicitada no sea mayor de una cierta cantidad (10 por ejemplo), así es que podemos tener más de un centinela. El suceso quedaría: Entrada en Licencia (Nº Licencia, Cantidad de días) [Nº Licencia< 4 && Cantidad días < 10]. Las operaciones describen la respuesta de un objeto ante un suceso, así es que las operaciones asociadas a estados o transiciones se efectúan en respuesta a los correspondientes estados o sucesos. Las operaciones asociadas a estados son las actividades, que requieren un cierto tiempo. Podemos citar las operaciones continuas, cómo la actividad “Ejercer Función” del objeto Persona en el subestado Trabajando del estado CONTRATADO. Se inscribe dentro del rectángulo del estado, precedido por la notación “do” . También están las actividades secuenciales, que terminan por sí mismas después de un cierto intervalo de tiempo, cómo el cierre de una válvula.


Las acciones son operaciones “instantáneas” y pueden estar asociadas a una transición o también al estado de un objeto, pudiendo intervenir en la entrada del estado (prefijo entry/), en la salida del estado (prefijo exit/), en respuesta a un evento desencadenante (prefijo nombre evento/), o bien en el transcurso de una transición (la acción figura tras la lista de centinelas precedida por el signo / ). Supongamos nuestro objeto Persona cuándo ingresa en el estado CONTRATADO, la misma efectúa su primera acción que es firmar su contrato de trabajo, contrato éste que se rompe cuándo la persona sale del estado CONTRATADO. Por otra parte, durante el tiempo de su contrato la persona se encarga de realizar una actividad consistente en ejercer su función para la que fue contratado. Además, mientras la persona permanece en éste estado pueden producirse varios eventos de distinta naturaleza, cómo ser la llegada de una propuesta proveniente de una agencia de empleo (debiendo responder la persona a ésa solicitud) ó la notificación de un cambio (la persona cambia de asignación). Para nuestro caso, tendríamos para el estado CONTRATADO el siguiente diagrama completo representado en FIG 11 en página 18 :

CONTRATADO entry / firmar contrato de trabajo do : ejercer función

llegada propuesta /responder a la propuesta cambio / cambiar de asignación exit / romper contrato de trabajo

FIG 11 Y de una forma más general tendríamos la siguiente situación, que representamos en la FIG 12 ESTADO 1 entry / acción al entrar en estado do : actividad durante el estado evento 1 / acción 1 evento 2 / acción 2 . . . . exit / acción al salir del estado suceso (atributos) [centinelas] /acción ESTADO 2

FIG 12


4. Conclusiones El modelo dinámico describe los aspectos de comportamiento de un sistema que cambia con el tiempo y es de utilidad para implementar los aspectos de control, es decir aquella parte del sistema que describe las secuencias de operaciones que se producen en respuesta a estímulos externos. La importancia del modelo dinámico dependerá de la naturaleza de la aplicación, así por ejemplo, dicho modelo no será preponderante para un depósito de datos puramente estático cómo una base datos, adquiriendo mayor importancia para sistemas interactivos. Los sucesos que representamos en los diagramas de estado correspondiente a un objeto, suelen implementarse como operaciones para ése objeto en el modelo de objetos. Según algunos autores, como James Rumbaugh, los sucesos son más expresivos que las operaciones, ya que el efecto de un suceso depende tanto de la clase del objeto cómo de su estado. El modelo dinámico constituye un soporte muy útil para el paso a la fase de diseño, ya que permite describir los encadenamientos de los métodos. 5. Bibliografía Martin Fowler con Kendall Scott - “UML GOTA A GOTA” - Ed Eyrolles Gestión 2000. 1997 López Nathalie, Migueis Jorge, Pichon Emmanuel - “Integrar UML en los proyectos” - Ed Eyrolles Gestión 2000 . 1998 Rossi Bibiana, Britos Paola, García Martínez - “Modelado de Objetos” Revista del Instituto Tecnológico de Buenos Aires Nº 21. 1998 Rumbaugh James , Blaha Michael, Premerlani William , Eddy Frederick , Lorensen William - “Modelado y diseño orientados a objetos” Ed Prentice - Hall . 1991 Muller Pierre Alain - “Modelado de objetos con UML” - Ed Eyrolles Gestión 2000. 1997 Grady Booch, James Rumbaugh, Ivar Jacobson - “El Lenguaje Unificado de Modelado” - Ed Addison Wesley. 1999 Piattini Mario G , Calvo - Manzano José A , Cervera Joaquín , Fernández Sanz Luis - “Análisis y diseño detallado de Aplicaciones Informáticas de Gestión” - Ed Rama. 1996

Modelos dinamicos Orientado a Objetos

Education

Transcript of Modelos dinamicos Orientado a Objetos