MODELO TRANSACCIONAL PARA APLICACIONES DE WORKFLOW.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "MODELO TRANSACCIONAL PARA APLICACIONES DE WORKFLOW."

Transcripción

1 MODELO TRANSACCIONAL PARA APLICACIONES DE WORKFLOW. Juan J. Moreno Quinteros. Universidad Pontificia de Salamanca, Campus de Madrid, Facultad de Informática, Madrid, España, Universidad Católica del Uruguay, Facultad de Ingeniería y Tecnologías. Montevideo, Uruguay, Ignacio Varese Isern. Universidad Católica del Uruguay, Facultad de Ingeniería y Tecnologías Montevideo, Uruguay, Luis Joyanes Aguilar. Universidad Pontificia de Salamanca, Campus de Madrid, Facultad de Informática, Madrid, España, ABSTRACT Workflow processes are long live processes that require an automatic, consistent and reliable recovering. In this article several ways to implement a transactional model for workflow applications are studied, in order to provide the Workflow Management System with the ability to recover automatically. Transactional models, Workflow failure and exceptions introductions are presented, as some approximations to the recovery implementation. Finally, rollbacks in a process instance are studied as well as the aspects involved when implementing compensators to provide a full recovery. Keywords: Transactions, Workflow, Long Life, Business Process Automation. RESUMEN Los procesos de Workflow son procesos de larga vida que requieren una recuperación automática en forma consistente y confiable. En este artículo se estudian las formas de implementar un modelo transaccional a las aplicaciones de Workflow de manera de poder dotar al Sistema de Gerenciamiento de Workflow con la capacidad para recuperar estás aplicaciones automáticamente. Se presentan los distintos modelos transaccionales, así como una introducción a las fallas y las excepciones que pueden ocurrir en Workflow, además de una primera aproximación a la implementación de la recuperación. Por último se estudia como realizar los Rollbacks en una instancia de proceso, así como los aspectos que se debe tomar en cuenta para los compensadores para una recuperación completa. Palabras claves: Transacciones, Workflow, Larga Vida, Automatización de Procesos de Negocios.

2 1 WORKFLOW Entre las nuevas tecnologías que han surgido en los últimos años, una de las que más ha contribuido a facilitar el crecimiento y mejora de las organizaciones, ha sido la de Workflow. Esta tecnología también a tenido un rol preponderante en el desarrollo del comercio electrónico, mediante la automatización de los procesos de negocios. El término Workflow es definido por la WfMC como: Automatización de un proceso de negocio, de forma completa o en parte, en donde documentos, información o tareas son pasadas desde un participante a otro para que tome acción, de acuerdo a un conjunto de reglas procedurales [1]. Así podemos identificar los conceptos más importantes [2]: Automatización: debe existir tecnología capaz de automatizar determinados aspectos del proceso de negocio. Proceso de negocio: conjunto de uno o más procedimientos o actividades directamente ligadas, que colectivamente realizan un objetivo del negocio, normalmente dentro del contexto de una estructura organizacional que define roles funcionales y relaciones entre los mismos [1] Documentos, información o tareas: elementos distribuidos a los participantes para que actúen. Participantes: pueden ser usuarios humanos de la aplicación o no (ejemplo: un fax). Acciones: son las que toman los participantes para poder lograr el objetivo del negocio. Reglas: las que rigen el proceso automatizado. 1.1 Sistema de Gerenciamiento de Workflow (WMS) Para implementar un Workflow, se requiere un Workflow Management System (WMS), o Sistema de Gerenciamiento de Workflow: "Sistema que define, crea y administra la ejecución de Workflows mediante el uso de software, ejecutando uno o más motores de Workflow, los cuales son capaces de interpretar la definición del proceso, interactuar con los participantes del Workflow, y de ser requerido, invocar el uso de herramientas de tecnologías de información y aplicaciones" [1]. El WMS es el que le da la vida al Workflow, definiendo y coordinando los participantes (humanos o no) y sus permisos, los motores de Workflow, las excepciones, recursos, etc., con el objetivo de cumplir el objetivo de negocio en cuestión. 2 TRANSACCIONES Una transacción de negocio se puede definir como una interacción en el mundo real, usualmente entre una persona y una empresa, intercambiando elementos tales como dinero, información, servicios o simplemente objetos. En todo intercambio, se requieren al menos dos partes. Cada una de ellas a la vez recibe y concede un elemento. Para que dicho intercambio sea exitoso o completado es necesario que ambas partes hayan cedido y recibido lo que correspondía, sin que acciones exteriores incidan en la transacción, la cual debe ocurrir en forma aislada e independiente de otros eventos y sucesos que no estén involucrados en el hecho. La administración de transacciones es generalmente aceptada con el objetivo de obtener procesos de datos de negocio confiables. 2.1 Definición Se define una transacción como una unidad de consistencia y de recuperación, por lo tanto, cuando cada acceso a la base de datos es hecho usando la interfase de transacción, se garantiza su estado consistente. Si se ejecuta una secuencia de operaciones dentro de una transacción se asegura que esas operaciones cumplan con las propiedades ACID (Atomicidad, Consistencia, aislamiento y Durabilidad): Atomicidad: todos los efectos de todas las operaciones de la transacción en la base de datos resultan con éxito o ninguno de ellas. Por lo tanto la transacción es indivisible, atómica, unidad de trabajo. Consistencia: una transacción deja la base de datos en un estado consistente, asumiendo que estaba consistente cuando comenzó. aislamiento: esta propiedad garantiza que la ejecución concurrente de transacciones no introducirá inconsistencias en la base de datos. Durabilidad: Los efectos de una transacción que ha hecho un Commit son permanentes en la base de datos, y garantiza que van a sobrevivir a subsecuentes errores.

3 Muchos sistemas de base de datos soportan transacciones, pero el modelo de transacciones es usualmente limitado a una Transacción Plana. Este tipo de transacciones son adecuadas para usar en transacciones administrativas, en este contexto como transacciones de corta duración, como operaciones típicas del tipo Debito-Crédito. [3] 2.2 Transacción Plana Se llama transacción plana porque todas las acciones que se llevan a cabo dentro de los límites de una transacción, ocurren al mismo nivel. Puede contener un número arbitrario de acciones que son tomadas como un todo y consideradas como única acción. Las primitivas necesarias para manejar este tipo de transacciones son: comenzar transacción, grabar transacción y abortar. La unidad de recuperación es la misma transacción en su totalidad, no se pueden grabar ni recuperar partes, el conjunto de acciones es indivisible, la filosofía es realizar todo o nada, y en un único nivel. Son útiles para modelar actividades breves. 2.3 Transacciones de Larga Vida Las transacciones de larga vida son transacciones de larga duración. Pueden prolongarse durante días, semanas, meses o hasta años, por lo que son factibles los problemas si se aplican las mismas propiedades que a las transacciones planas. Debido a estos motivos, al automatizar los procesos de negocios, se propone utilizar transacciones de larga vida Modelo Extendido para Transacciones de Larga Vida Se utilizan modelos extendidos de transacciones para aplicaciones avanzadas, por ejemplo las orientadas a procesos, en el cual las transacciones tienen una estructura interna, donde intervienen varios actores, y toman relativamente largo tiempo para ser completadas. En estos casos las transacciones planas con sus propiedades ACID no son adecuadas por los siguientes motivos: La atomicidad estricta, implica que los errores durante la ejecución de una transacción de larga vida, puedan causar grandes volúmenes de trabajo al deshacer el resultado de una transacción completa (Rollback). Además se presenta la grave falencia de perder una posiblemente gran cantidad de trabajo realizado en la aplicación de Workflow durante ese tiempo. El aislamiento estricto, implica que resultados intermedios de una transacción de larga vida se mantengan privados a la transacción, y no puedan ser usados para ejecutar transacciones concurrentemente hasta que la transacción halla finalizado, es decir que haya hecho un Commit. En una aplicación de Workflow con varios actores compitiendo por los recursos a través del tiempo, esta es una restricción demasiado significativa. Una estructura plana no permite un proceso transaccional estructurado o asignar partes de una transacción a diferentes actores. [3] Consecuentemente, los modelos de transacciones avanzados han sido diseñados con la meta de soportar aplicaciones con estructura, con procesos transaccionales de larga vida. Los modelos de transacciones extendida más importantes son los presentados a continuación Modelo de SAGAS En este modelo se define una transacción T como un conjunto de subtransacciones T1,...,Tn, donde cada componente de esa subtransacción, T1...Tn, tienen todas las propiedades ACID de las transacciones tradicionales, y estos pueden interrelacionarse entre los componentes de las subtransacciones [4]. Sin embargo cada subtransacción del SAGAS tiene que ser ejecutado en un orden predefinido, como se presentan en la Ilustración 1. Para cada subtransacción Tk (1<= k < n), se define una subtransacción compensadora. Una transacción compensadora CTk semánticamente deshace los efectos de la transacción Tk, por ejemplo si se corre T1 el compensador es CT1, y el CT1 semánticamente deshace los efectos de la transacción T1. El estado de la base de datos después de ejecutar la subtransacción Tk y luego el compensador CTk tiene como resultado la identidad. Para completar un SAGAS, se debe ejecutar de forma exitosa toda la secuencia o los efectos de las subtransacciones que realizaron Commit son deshechas por una secuencia de subtransacciones compensadoras. Las subtransacciones compensadoras son ejecutadas en orden inverso de los componentes de subtransacciones. La última subtransacción Tn no requiere una subtransaccioón compensadora, ya que cuando Tn realiza el Commit no hay otra subtransacción que pueda ejecutar y por lo tanto SAGAS realiza el Commit final. Este modelo es implementado en el proyecto Exotica [5] y el proyecto FlowBack [6].

4 Transacción T T1 T2 T3 T4 T5 CT1 CT2 CT3 CT4 Transacción T se subdivide en subtransacciones T1...T5, que tienen sus respectivas subtransacciones de compensación. Este es un caso exitoso del SAGAS. T1 T2 T3 T4 FALLA CT1 CT2 CT3 CT4 En este caso la ejecución del SAGAS no termina con éxito y se ejecutan las subtransacciones de compensación. Ilustración 1 Ejecución utilizando el modelo SAGAS Modelo Transacción Nested Consiste en una transacción T que se divide subtransacciones T1...Tn, en forma jerárquica formando un árbol de transacción, como se representa en la Ilustración 2 [7]. Una subtransacción que tiene subtransacciones es llamado padre, y sus subtransacciones son llamados hijos. Las hojas del árbol son transacciones planas. Cada subtransacción puede hacer un Commit o un Abort siempre que se consideren los siguientes aspectos: Una subtransacción hija puede empezar después que el padre halla empezado. Una subtransacción padre debe terminar sólo después que todos los hijos hallan terminado Si una subtransacción padre es abortada, todos los hijos son abortados Si una subtransacción hija es abortada, el padre puede elegir la forma de recuperarse, por ejemplo: o Ignorar la falla y proceder con otras tareas, en este caso el hijo es considerado no vital. o Reintentar la subtransacción que falló. o Ejecutar otra subtransacción que ejecuta una acción alternativa. o Abortar. Todas las propiedades ACID son preservadas en este modelo. En este caso se mantiene el aislamiento entre cada subtransacción y en caso de una falla se realiza el Rollback sin efectos en otras transacciones. Sin embargo, las subtransacciones si bien son atómicas y aisladas entre si, no son durables. Aún si una subtransacción realiza el Commit, sus efectos van a ser deshechos cuando el padre aborte. Las modificaciones hechas por una subtransacción llegan a ser permanentes sólo después que la raíz del árbol de transacción realiza el Commit. Similarmente los resultados de una subtransacción que realizó el Commit pueden ser usados por otra subtransacción antes que el padre realice el Commit, pero son exteriorizados sólo después del Commit de toda la transacción. Transacción Raíz T Sub Transacción T1 Sub Trn. T2 T3 T4

5 2.3.4 Modelo Transacción Open Nested Este modelo extiende el modelo NESTED, permitiendo que los requerimientos de aislamiento no sean tan rígidos, haciendo que los resultados de subtransacciones que realizaron el Commit sean visibles para otra transacción NESTED ejecutada concurrentemente. De esta manera un alto grado de concurrencia es obtenido. Para evitar inconsistencias en el uso de los resultados de subtransacciones que realizaron un Commit, sólo a las subtransacciones que conmutan las que realizaron el Commit se les permite usar los resultados. Dos transacciones se dice que conmutan, si los efectos, por ejemplo, las salidas y el estado final de la base de datos, son independientes del orden en que son ejecutadas. En sistemas convencionales, solo operaciones de lectura conmutan. Basado en ésta semántica, sin embargo, pueden también definirse operaciones de modificación como conmutativas (por ejemplo la operación de incrementar en un contador)[8]. Este modelo es implementado en el proyecto WAMO [9] y el proyecto METEOR [10] Subtransacciones Multi-Padre Extiende el modelo de transacción NESTED permitiendo que cada subtransacción tenga un número arbitrario de transacciones padres. Una subtransacción puede ser ejecutada en paralelo con algunas o todas las transacciones padres. Por lo que el modelo permite múltiples transacciones para comenzar una subtransacción en cooperación. La principal ventaja del modelo es que la combinación de eventos puede ser incrustado dentro de transacciones Modelo Nested Sagas Este modelo permite estructuras NESTED dentro de cada subtransacción de SAGAS, definiendo interiormente cada una de ellas como estructuras del modelo de transacción NESTED. Este modelo es implementado por el proyecto WIDE [3] Modelo de Transacciones Flexible Este modelo ha sido propuesto como un modelo de transacción adecuado para ambientes de múltiples bases de datos. Es un conjunto de tareas, con un conjunto de funcionalidades equivalentes para cada subtransacción y un conjunto de dependencias de ejecución sobre las transacciones, incluyendo dependencias de fallas, dependencia de éxito, o dependencias externas. Para disminuir la rigidez de los requerimientos de aislamiento, usa compensación y disminuye la rigidez de los requerimientos de atomicidad, permitiendo al diseñador de la transacción especificar estados aceptables para la terminación de la transacción flexible, en cual algunas subtransacciones pueden abortar. [8] 3 TRANSACCIONES EN WORKFLOW Para garantizar la ejecución correcta y confiable de instancias de procesos de Workflow bajo ciertas circunstancias, el WMS debe soportar ejecución consistente, control concurrente y recuperación a fallas. Se utilizará el concepto de Transacción de forma de describir los requerimientos de correctitud y la confiabilidad de aplicaciones de Workflow individuales.

6 Para tratar un proceso de Workflow como una transacción plana hay que aplicarle las propiedades ACID (Atomicidad, Consistencia, aislamiento y Durabilidad), pero éstas propiedades son demasiados restrictivas para aplicaciones de Workflow como se presentó anteriormente. Una instancia de proceso de Workflow puede ser de una larga vida, por lo tanto especialmente en las propiedades de atomicidad y de aislamiento se encuentran graves restricciones. En la atomicidad, todos los efectos de las operaciones de una transacción o bien son instalados en la base de datos o ninguno de ellos es instalado, mientras que con la propiedad de aislamiento se garantiza la ejecución concurrente de las transacciones donde no se introducen inconsistencias en la base de datos. Ya que las aplicaciones de Workflow pueden durar días, meses o años, las propiedades de atomicidad y aislamiento no cumplen con la idea de un proceso de negocio automatizado. Por lo tanto, hay que flexibilizar el problema, utilizando un modelo extendido de transacciones, como se utilizan para transacciones de larga vida. El término Workflow Transaccional es usado para enfatizar la relevancia de las propiedades transaccionales en un WMS. Un Workflow Transaccional involucra ejecución coordinada de tareas que pueden requerir acceso a sistemas de base de datos heterogéneas, autónomas y distribuidas. Los requerimientos de coordinación son expresados por la dependencia del control de flujo, que especifica una precondición para la ejecución de cada tarea. Una instancia de proceso debe ser ejecutada íntegramente o no. Generalmente se desea que todas las tareas sean terminadas con éxito o ninguna de ellas. No deben existir resultados parciales después de una terminación insatisfactoria de una instancia de proceso. Existen varios métodos para ejecutar errores de atomicidad. Estos incluyen recuperación hacia adelante (Forward Recovery), recuperación hacia atrás (Backward Recovery) y compensadores. Recuperación hacia adelante, significa que luego de un error en el Workflow el estado es recuperado de los archivos de log, y la ejecución continua. La recuperación hacia atrás, asume que los efectos de las tareas interrumpidas por un error pueden aplicar un Rollback, o ser removidas del sistema. Finalmente, los compensadores son técnicas para deshacer los efectos de tareas que ya fueron realizadas, ejecutando otras tareas que realizan efectos inversos, obteniendo de esta forma la identidad. 3.1 Diferencia entre Workflows y Transacciones Un proceso de Workflow es fundamentalmente diferente de una transacción de base de datos. Un ambiente de Workflow es más complejo que uno de base de datos pues involucra componentes heterogéneos y distribuidos, incluyendo interacciones humanas. A su vez, un proceso de Workflow es estructuralmente más complejo que una transacción de base de datos, y la ejecución de un proceso puede producir dependencias de control complejas y flujos de datos entre las actividades del proceso. Una especificación de proceso de Workflow puede incluir ramificaciones, ejecución concurrente de actividades, bucles, y otras estructuras complejas de control. 3.2 Correctitud y Confiabilidad del Workflow La correctitud en el área de Workflow principalmente trata con la ejecución correcta y consistente de instancias de procesos. Los siguientes aspectos son relevantes: Consistencia de tareas individuales: Usualmente la persona que implementa una tarea es responsable de su correctitud, aceptando que la tarea es ejecutada sola y no interpolada con otras tareas. Consistencia de Workflows Individuales: Es razonable asumir que si una tarea correcta es ejecutada una tras otra, en un orden especificado previamente, entonces la ejecución de la instancia de proceso preserva la consistencia. Sin embargo, si 2 o más tareas de la misma instancia de proceso son ejecutadas en paralelo, y comparten recursos comunes, las operaciones individuales pueden superponerse, de esa manera produciendo resultados incorrectos. Consistencia entre ejecuciones de diferentes Workflows: Adicionalmente el problema de concurrencia es más complejo si las tareas corresponden a diferentes tipos de instancias de procesos (o incluso otras aplicaciones) y acceden a recursos comunes. 3.3 Fallas en Workflow Las fallas interrumpen la ejecución normal de una o varias instancias de proceso, y una acción correctiva es necesaria para continuar ejecutando [11]. La confiabilidad consiste en restablecer la consistencia si alguna falla ocurre, pudiendo clasificarlas en: Fallas Básicas, producidas a nivel del Sistema (en el DBMS, Sistema Operativo, Red, etc.)

7 Fallas de la Aplicación, producidas en aplicaciones invocadas por el WMS para ejecutar determinada tarea Fallas básicas Las Fallas básicas corresponden a fallas del WMS o de su plataforma subyacente, como fallas de Hardware, fallas de Red, o fallas del DBMS soporte del WMS. Por ejemplo las fallas básicas son manejadas a nivel del sistema contando con la capacidad subyacente del DBMS para mantener un estado persistente y consistente, soportando así recuperación hacia delante. En particular la comunicación entre el WMS y las aplicaciones del cliente de Workflow y el registro de esas operaciones en la base de datos no son operaciones atómicas. Análogamente las notificaciones de las ejecuciones de tareas completadas que vienen del cliente y de la transacción de base de datos correspondiente, registran el evento en el servidor, lugar donde las operaciones no son ejecutadas en forma atómica. Además las tareas recién despachadas por el motor de Workflow pueden empezar y ejecutar mientras el motor esta caído. De esa manera cuando se hace reinicia el sistema, el motor evalúa el estado de ejecución del Workflow, ya que puede no estar correcto, y debe reconstruir el estado, comunicado con el cliente de Workflow Fallas de aplicación Las Fallas de Aplicación se deben al mal funcionamiento de las aplicaciones invocadas por el WMS. Las aplicaciones externas deben mantenerse corriendo sin el retorno de ningún valor al motor de Workflow, o poder retornar un código de error (ejemplo: fuera de memoria, sistema inalcanzable). Este tipo de situaciones excepcionales no son procesos de negocio específicos. Estas fallas son relevantes para el administrador de Workflow, dado que resultan de las fallas de las tareas. Aunque el administrador de modificaciones requerido por las aplicaciones para ejecutar correctamente esté fuera del dominio del Workflow, el administrador de las fallas del negocio que resultan de las fallas de aplicación, es ciertamente un problema del negocio. Una aproximación genérica para el manejo de las fallas de las tareas involucra la integración del modelo de workflow con modelos de transacciones extendidas. De hecho si el modelo de Workflow tiene la capacidad transaccional tradicional, como realizar un Rollback parcial o total de un proceso, las fallas de las tareas pueden ser manejadas volviendo para atrás la ejecución del proceso hasta que un punto de decisión es alcanzado, desde el cual una ejecución hacia delante (Forward) puede ser resumida a lo largo del camino. 3.4 Excepciones en Workflow También pueden ocurrir Excepciones durante una instancia de Workflow: Excepciones esperadas, correspondientes a desviaciones previsibles a partir del comportamiento normal de un proceso. Excepciones inesperadas, correspondientes a inconsistencias entre el proceso de negocio en el mundo real y su correspondencia con la descripción en el Workflow Excepciones esperadas Las excepciones esperadas son derivaciones predecibles del comportamiento normal del proceso. Ejemplos de excepciones esperadas son: En el proceso de presentación de una propuesta, la fecha de presentación expiró. En el proceso de alquiler de un auto, un accidente le ocurre al auto rentado, el cual no esta disponible para subsecuentes alquileres. La diferencia de las fallas básicas y de aplicación con las excepciones esperadas es que estas últimas están estrictamente relacionadas con el dominio del Workflow, éstas son parte de la semántica del proceso, y debe ser posible modelarlas con el proceso. Las fallas esperadas pueden ser divididas en cuatro clases, según el evento que causan: Con el principio o complemento de tareas e instancias del proceso. Excepciones de Datos.

8 Excepciones Temporales. Excepciones Externas Excepciones Inesperadas Las excepciones inesperadas corresponden a inconsistencias entre un proceso de negocios en el mundo real y su representación en workflow. Ejemplo, se asume un nuevo acuerdo entre Uruguay y Estados Unidos que requiere que turistas uruguayos viajen a Estados Unidos con previo pedido y obtención de una visa. Si la reserva del viaje en la aplicación de Workflow no fue modificada aún, de acuerdo con la nueva reglamentación su ejecución no conduce al éxito complemento del proceso de negocio. 3.5 Principales características de transacciones en Workflow Las principales características de transacciones en Workflow [3] pueden ser resumidas en: Analogía: Una transacción plana es una secuencia de operaciones que transfiere de una base de datos de estado consistente a otro estado consistente. En analogía de esto, una transacción de Workflow es una secuencia de actividades de Workflow que transfiere un proceso de negocio de un estado consistente en el próximo estado consistente. Atomicidad: Desde que las actividades de Workflow son en general de larga vida, la meta es no deshacer todo en caso de una falla. En lugar de eso se debe realizar selectivamente un Rollback a partes del trabajo realizado hasta que la mayoría de los estados consistentes son alcanzados. Con el propósito de encontrar ese estado consistente el administrador de transacciones de Workflow necesita soporte de un humano experto (por ejemplo, el diseñador de Workflow). Consistencia: Al igual que en las transacciones, el alcance de las ejecuciones consistentes no se enfoca en el trabajo que es hecho dentro de la actividad, sólo considera el orden correcto de ejecución de actividades. El Commit de una actividad es tomado como una garantía que la actividad produjo un resultado consistente. Si una actividad falla, entonces un estado inconsistente puede ser la consecuencia. En la transacción plana esas situaciones no deben ocurrir y deben ser removidas automáticamente. Si las actividades de compensación están involucradas en el proceso de recuperación entonces las actividades deben terminar satisfactoriamente de manera de preservar la consistencia. Aislamiento: Ya que la naturaleza de las aplicaciones de Workflow es de larga vida, de cooperación y de concurrencia, no es posible ejecutar transacciones en Workflow totalmente aisladas a partir de transacciones concurrentes. El criterio de serialización y la correctitud para el tratamiento concurrente es demasiado restrictiva. La meta es explotar la semántica de las actividades definiendo especificaciones de compatibilidad entre las actividades. Adicionalmente el aislamiento se hace menos restrictivo en el sentido de subactividades que hacen externo su resultado tan pronto como realizan el Commit de manera de incrementar la concurrencia y por ende el rendimiento. Durabilidad: Tan pronto como las subtransacciones de Workflow realizan el Commit, los efectos son persistentes. Por supuesto, esos efectos pueden ser semánticamente deshechos más tarde si una actividad aborta o es Compensada. 4 CONCEPTOS DE RECUPERACIÓN EN WORKFLOW La confiabilidad es de importancia crítica para los sistemas de Workflow. El WMS no sólo debe ser correcto funcionalmente, también tiene que ser robusto desde el punto de vista de fallas [8]. Confiabilidad en el contexto de Workflow, requiere que esas tareas, sus datos asociados, y el WMS mismo, deben ser recuperables ante la ocurrencia de una falla, y para ello disponer de un método de recuperación. Un proceso de Workflow es dependiente de la estructura de la organización, y de sus políticas de negocio. Las aplicaciones de Workflow son de naturaleza horizontales y se extienden a través del espectro de la organización, comparando con las actividades de procedimientos de transacción (ej: Transacciones en Base de datos) que son en naturaleza más verticales o jerárquicas y puede llegar a formar parte sólo del proceso. En otras palabras, la descomposición jerárquica usada en el modelo de transacciones extendida, no es suficiente para modelar los procesos. Un WMS necesita soportar la recuperación en cada una de las tareas, datos asociados y la instancia de proceso completa. La naturaleza heterogénea de las tareas de Workflow y las entidades de procesamiento pueden llegar a imposibilitar cualquier semántica transaccional que sea requerida para asegurar el comportamiento transaccional.

9 Un mecanismo de recuperación viable debe ser consistente y debe soportar todos los objetivos del proceso de negocio. 4.1 Conceptos de Transacción en el modelado de recuperación de workflow Definimos la recuperación como recuperación a un estado. Así, los modelo de recuperación de NESTED o SAGAS usan un modelo de recuperación pensando en recuperación Backward de algunas de las transacciones hijas para deshacer los efectos de una transacción global que ha fallado. La recuperación Backward tiene a veces una aplicación limitada en los ambientes de Workflow, dado que existen casos en que no es posible seguir las acciones en reversa, o puede no ser factible (desde la perspectiva del negocio), ya que puede llegar a involucrar una sobrecarga inaceptable o conflicto con las políticas del de la organización Noción de compensación La noción de compensación es importante en los sistemas de Workflow. Deshacer transacciones incompletas, o recuperación Backward, son mecanismos para reparar transacciones abortadas. Sin embargo este concepto no es directamente aplicable en la mayoría de las tareas reales de Workflow, las cuales son gobernadas por acciones que son en general permanentes ( ej: acciones humanas). Es posible definir una tarea semánticamente inversa (comúnmente referida a una tarea de compensación), o encadenar tareas que puede deshacerse efectivamente, o reparando el daño ocurrido por la tarea que fallo dentro del Workflow. En modelos transaccionales, la unidad de recuperación es otra transacción. Cada transacción tiene un conjunto predefinido de semánticas que obedecen a los procesamientos de una transacción. El modelo para recuperación en un sistema de Workflow es más que eso, el proceso de recuperación no sólo debe recuperar al estado consistente, sino que también debe proceder hacia adelante de manera de cumplir con el proceso organizacional completo. 4.2 Recuperación de Tareas de Workflow Una tarea (o actividad) forma una unidad básica de ejecución dentro del modelo de Workflow. Una tarea es una unidad lógica de trabajo que es usada para satisfacer los requerimientos del proceso de negocio que define el Workflow. En los sistemas de base de datos, es suficiente mantener imágenes antes y después de los datos afectados por una transacción en el caso de fallas. La recuperación de tareas, por consiguiente, debe ser dirigida desde una perspectiva más amplia. Las tareas dentro del Workflow pueden ser arbitrariamente complejas y heterogéneas como las tareas transaccionales o no transaccionales Tareas transaccionales Son usadas para modelar tareas que cumplen con la propiedad de atomicidad y soporte máximo a todas las semánticas de las transacciones tradicionales. Muchos modelos de tareas han sido definidos por los sistemas de Workflow. A pesar de este hecho, es difícil determinar el estado exacto de ejecución de una tarea dado que estos modelos de tareas no modelan detalles de tareas de ejecución. Existen implementaciones envolviendo tareas especiales que revelan el estado interno del la capa del WMS, sin embargo estas soluciones no son en general suficientes para manejar tareas que son diversas y arbitrariamente complejas. Por lo tanto, la recuperación de tareas debe ser dirigida a partir de una perspectiva amplia. Se debe enfocar en todo el modelo de proceso de negocio cuando se trata de decidir la próxima acción que debe ser ejecutada cuando se resuelven las fallas de las tareas Tareas no transaccionales Una tarea no transaccional es usada para modelar tareas que no cumplen con la propiedad de atomicidad por transacciones. Las tareas de humanos (usuarios) son típicamente no transaccional, y así las aplicaciones que interactúan con los recursos no transaccionales. En el caso de tareas no transaccionales, es complejo monitorear el estado exacto de la tarea cuando había sido sometido para la ejecución. Esta falta de control puede dejar al sistema en un estado no determinado desde el punto de vista de las fallas. En ese escenario, la recuperación automática de una tarea que halla fallado, se convierte en imposible, debido a la falta de retroalimentación en tiempo de ejecución o las garantías transaccionales de las entidades de procesamiento. El rol del humano (ej: Administrador de Workflow) es importante en dichas situaciones para determinar el estado de la tarea que fallo basado en la información que es externa al WMS.

10 4.3 Recuperación de los datos de workflow Los datos juegan un rol importante en los sistemas de Workflow. La recuperación de datos ha sido estudiada extensamente en el contexto de los sistemas de base de datos. El Logging y el Shadow son mecanismos en el procesamiento de una transacción para registrar el estado de datos críticos persistentes. Varios mecanismos de Checkpoints (puntos de chequeo) han sido discutidos para aumentar el rendimiento del proceso de recuperación. Estos principios pueden ser aplicados en sistemas de Workflow en situaciones relacionadas haciendo que los componentes persistentes de Workflow y que los procesos de recuperación sean más eficientes. En el caso de WMS distribuidos, es también importante replicar los datos a través de máquinas para incrementar la disponibilidad de los datos desde el punto de vista de las fallas de hardware y red. 5 ROLLBACK Y COMPENSADORES Cuando ocurre una falla en una tarea, el estado del Workflow puede quedar inconsistente, si esto ocurre, dependiendo el caso se debe realizar una recuperación hacia delante (Forward), o una recuperación hacia atrás (Backward). En el caso de la recuperación hacia delante se ejecuta una tarea compensadora, o si es una tarea transaccional dentro de una base de datos esta se realiza automáticamente, y luego se continua con la instancia de proceso. Si ocurre que la tarea tiene que hacer un Rollback se tiene que volver el camino inverso con las tareas de compensación diseñadas por el administrador. En esta sección se analiza el problema de la ocurrencia de una falla en una tarea de workflow y como realizar el Rollback correspondiente, además de como crear los compensadores de las tareas, para deshacer lo anteriormente realizado. 5.1 Modelo de Tareas de Workflow para solución de Rollback y Compensadores Una tarea se puede clasificar entre las siguientes categorías Compensable (Requiere deshacer, con un proceso de Rollback) Reversibles (Sí ocurre una falla no afecta más que a la propia tarea, con una recuperación Forward) No Compensable No requiere deshacer Forzable En el caso de las tareas compensables, se pueden crear compensadores correspondientes a la tarea, que a su vez afecta otras tareas. Si es una tarea reversible, sólo se ejecuta una recuperación de la tarea, ya que no afecta otras tareas. Cuando es una tarea no compensable, no existe una tarea compensadora correspondiente, por ejemplo enviar un . Hay tareas que no requieren deshacer, por ejemplo una tarea que sólo observa la existencia de algún recurso. Las tareas Forzables garantizan que la tarea va a ser exitosa. En un administrador de transacciones, cada transacción requiere que todas las tareas sean ejecutadas exitosamente o que ninguna de ellas lo haga. Además las tareas pueden ser vitales o no vitales. Las tareas vitales son las tareas que si todas realizan el Commit, todo el proceso ha realizado el Commit, mientras que otras tareas pueden ser abortadas o no ser ejecutadas. Se pueden especificar tareas que no necesitan ser deshechas aunque el proceso haya abortado, como las tareas no vitales. En el caso de abortar una tarea vital se aborta la instancia que esta corriendo y se corre un proceso de Rollback. De esta forma se define que un proceso de Workflow es correcto si se garantiza que todas las tareas vitales han realizado el Commit, de otra manera cuando el proceso aborta los efectos de esas tareas que no requieren deshacerse pueden persistir. Una tarea puede ser ejecutada de forma automática (por un programa) o manualmente (por un humano). Así es que las tareas ejecutadas por agentes, pueden ser de dos tipos Agentes de interacción de humanos que interactúan con humanos Agentes de aplicación que manejan la ejecución automática de las aplicaciones. Los agentes de aplicación interactúan con el motor de Workflow que traen los datos requeridos por la instancia para la tarea y comunican el resultado de la tarea. Las aplicaciones entre ellas acceden a diferentes manejadores de recursos, del cual algunos pueden ser transaccionales, como DBMSs, o no.

11 Cada tarea tiene un conjunto de parámetros de entrada y salida, y un flujo de control que determina el camino que tiene que tomar durante la ejecución del proceso. Las aristas en el grafo directo especifican un orden parcial para la ejecución de las tareas. Cualquier ejecución debe satisfacer el orden de las restricciones. En el proceso se debe especificar que la tarea t1 es ejecutada antes que t2, eso no significa que la tarea t1 debe realizar el Commit antes que t2, pero debe alcanzar el estado de Listo antes que t2 ejecute. Varios tipos de ramificaciones pueden ser especificados en los requerimientos de flujo de control: Secuencial Condicional Paralelo Bucles Opcional Para la ramificación condicional, un predicado es asociado en el control de flujo, que se evalúa en tiempo de ejecución para determinar que rama debe tomar En el caso de la ramificación paralela, el control de flujo es a través de todas las ramas dan éxito a una tarea. Los bucles son usados para repetir la ejecución de un conjunto de tareas. Después que el conjunto de tareas haya sido ejecutado un número deseado de veces, el control de flujo sale del bucle y procede con el resto del proceso. Una tarea opcional esta compuesta por un conjunto de tareas, eligiendo una de las tareas opcionales en tiempo de ejecución. Las propiedades de la tarea opcional son las propiedades de la tarea que es ejecutada. Los flujos de datos y de control especifican la ejecución de dependencias entre las tareas. La dependencia de datos entre tareas de la misma o de diferentes instancias de proceso es causada por el acceso a recursos compartidos. La dependencia de datos se produce cuando una tarea requiere de datos para producir otros. A su vez las tareas pueden ser compuestas ya que una tarea puede contener otras tareas. El control de flujo en los bucles no es permitido, por esto los bucles no pueden superponerse, aunque pueden ser contenidos unos en otros, por ejemplo en tareas compuestas. El mínimo número de tarea (cerca al comienzo de la tarea) es considerado el comienzo de la tarea para un bucle. 5.2 Ocurrencia de fallas Las fallas interrumpen la ejecución normal de una instancia y una acción correctiva es necesaria para ejecutar la instancia desde el punto de la falla. Al ocurrir una falla en la tarea (de algunos de los tipos explicados anteriormente), si ésta es vital se debe aplicar una recuperación Forward o el proceso de Rollback y compensación de la tarea. Una de las opciones que pueden ocurrir cuando ocurre una falla y la tarea es vital, es ejecutar una tarea alternativa, en vez de compensarla y correr un proceso de Rollback Tarea Alternativa Una tarea alternativa es otra tarea que puede ser simple o una tarea compuesta, que es ejecutada cuando ocurre una falla en la tarea original Rollback Al ocurrir una falla y ser necesario un Rollback, se debe encontrar el camino inverso al que ejecutó para recuperar los datos. En ese camino se ejecutan las tareas compensadas de las tareas ejecutadas inicialmente. En este caso hay que tener en cuenta que las tareas pueden tener dependencias entre tareas. Por lo que puede ocurrir que cuando se realiza el Rollback y se llega a una tarea que tiene dependencias, se tenga que deshacer las tareas en el orden de dependencia. Por ejemplo si la tarea B tiene a la tarea E como dependencia al abortar, y a su vez la tarea E tiene a la tarea M también como dependencia al abortar, por lo que el orden de ejecución de las tareas de compensación va a ser la tarea compensadora de M luego la de E y luego la de B. Luego que se ejecutaron las tareas compensadoras de la dependencias se continua con el orden, es así que luego de ejecutar la tarea compensadora de B sería la de A Puntos de Salvado Se le llama a una tarea punto de salvado cuando una tarea es un punto seguro del proceso, es decir que desde esa tarea para atrás todos lo resultados son correctos.

12 Los puntos de salvado son necesarios ya que es una manera de no deshacer toda la instancia, y sólo deshacer hasta un punto seguro, dónde se sabe que de ahí hacia adelante si ocurre alguna falla, los datos anteriores al punto de salvado no serán afectados. Se utiliza en el caso de procesos largos, donde deshacer toda la instancia puede resultar un costo excesivo. En el caso que se haga un Rollback hasta el punto de salvado y luego se vuelva a reejecutar, se le llama Rollback parcial, si el Rollback es de toda la instancia se llama Rollback completo Compensación Como se describió anteriormente, la compensación es una técnica para tratar las fallas de tareas de un proceso. Cuando una instancia de proceso falla, el WMS es responsable de brindar la ejecución de un proceso a un punto de compensación final designado. Un punto final compensado es el paso de ejecución previo de los procesos que representan un estado de ejecución intermedia aceptable y también a un punto de decisión donde cierta acción puede ser tomada para corregir el problema que ha causado la falla o elegir una camino de ejecución alternativo para evitar el problema. Notar que la compensación y luego la reejecución de una tarea es considerada semánticamente equivalente a la ejecución original, pero puede no ser idéntica Compensación Completa Desde que el punto final de compensación esta siempre compensado y reejecutado, todas las instancias que han sido afectadas deben también ser compensadas. Por esto una estrategia de compensación es completada si todas las instancias de tareas son completadas previamente, directamente o indirectamente afectadas por el punto de compensación final que es compensado Preservación del orden de ejecución Otro aspecto importante de un proceso de compensación correcto es el orden de compensación. Básicamente la secuencia de compensación debe representar la semántica inversa de la ejecución original. En general, una secuencia particular de una ejecución de tareas de proceso es una reflexión de las semánticas de procesos (por medio de los datos o de la dependencia de ejecución) Proceso aceptable de compensación La completitud y la preservación del orden son dos aspectos del proceso de compensación, hay ejecuciones que son completas pero no preservando el orden al tiempo que existen ejecuciones que conservan el orden pero no son completas. Estas dos propiedades juntas garantizan la correctitud del proceso de ejecución y la compensación Requerimientos para una tarea de Compensación Dada una tarea T en un Workflow W, T es compensable si cumple con: Forzable: Permite a C ser la tarea de compensación de la tarea T. Luego después de que T es invocada y ejecutada en la instancia W i de W, la ejecución de C (Compensador) debe garantizar que sea exitosa, dentro de un periodo de tiempo especificado, o en un número de reintentos hasta que la compensación sea exitosa. Relajación del aislamiento: Después de que T es invocada y ejecutada en cualquier instancia W i de W, los recursos de datos que T haya accedido serán liberados. Esta relajación de aislamiento sobre recursos de datos compartidos es requerida con el propósito de introducir compensación para evitar esperas de larga duración, de otra manera, se debe usar un nivel de sistema para deshacer, en vez de la compensación. 5.3 Dependencias entre tareas Una vez que las tareas constituyen una especificación de workflow, la estructura interna del Workflow puede ser definida especificando las dependencias ínter tareas[14]. Las dependencias pueden ser especificadas usando una variedad de paradigmas de software (reglas, restricciones, programas, etc.) En general las dependencias pueden ser definidas a priori estáticamente o dinámicamente durante la ejecución. En el primer caso las tareas y las dependencias entre ellas son definidas antes que la ejecución de Workflow comience. Una generalización de la estrategia estática, es tener una precondición para la ejecución de cada tarea en el Workflow o transiciones especificas de las tareas, por lo que todas las tareas posibles y sus

13 dependencias son conocidas por anticipado, pero sólo las tareas cuyas precondiciones son satisfactorias son ejecutadas. Diferentes parámetros iniciales para la tarea pueden resultar en ejecuciones diferentes de una tarea. Las precondiciones pueden ser definidas en términos de estados de ejecución de otras tareas, valores de salida de otras tareas, variables externas incluyendo estados de tiempo y de datos. Los términos dependencias de ejecución, dependencias de datos o valores y dependencias temporales son usados para referir las precondiciones. Una tarea esta directamente afectada por otra por medio de la dependencia de datos, si una tarea leyó datos que luego fueron modificados. Una tarea esta directamente afectada por otra por medio de la dependencia de ejecución, si la ejecución de la tarea más reciente fue implicada por una tarea anterior. En el caso dinámico, las dependencias de tareas son creadas durante la ejecución de las instancias de proceso, muchas veces ejecutando un conjunto de reglas. Las tareas de un Workflow pueden comunicarse entre ellas a través de variables, locales al Workflow y hechas persistentes por el WMS. Estas variables (incluyendo variables temporales) pueden también mantener los parámetros de los programas de tareas. El flujo de datos entre las tareas es determinado asignando valores a las variables de entrada y de salida. La ejecución de una tarea tiene efectos sobre el estado de la base de datos y el valor de su variable de salida. 6 CONCLUSIONES Para que una instancia de Workflow sea ejecutada correctamente el WMS debe soportar tolerancia a fallas. Entonces para que el proceso de Workflow sea una unidad de consistencia y recuperación, se implementa un modelo transaccional para el soporte a fallas de las instancias de procesos de Workflow. Así se trata de dividir el proceso de Workflow en tareas individuales, para dividir en transacciones y no aplicar las propiedades ACID a un proceso completo. En este artículo se ha presentado el estudio de cómo implementar un modelo transaccional, el manejo de las tareas y la utilización de Rollback. También se estudió como formar las tareas compensadoras, ya que éstas deben tener en cuenta las dependencias entre las tareas ejecutadas inicialmente. Es importante el estudio de las dependencias entre tareas, ya que estás pueden determinar errores en el proceso de recuperación, si éstas no se ejecutan correctamente el resultado de la recuperación puede ser equivocado. Hay que tener en cuenta que no siempre que exista una falla es necesario realizar un Rollback, ya que este puede producir una gran perdida de tiempo y de recursos, por lo tanto cuando se define las excepciones y las tareas a ser compensadas, hay que tomar en cuenta que el costo es grande y por lo tanto debe ser realmente inevitable. En ciertas ocasiones, recuperando la tarea sin realizar un Rollback, o mediante una tarea alternativa se soluciona el problema. 7 TRABAJO FUTURO Es importante continuar con las investigaciones para que esta tecnología avance. Este modelo es un aporte a la comunidad donde surgen algunos estudios. Siguiendo con la línea del modelo propuesto, el mismo puede ser extendido y estudiar el funcionamiento de las dependencias de las tareas en los distintos casos de definiciones de procesos. También los casos de Rollbacks específicos, estudiar si todos ocurren de esta manera. Surge además la pregunta de la sobrecarga inducida en los WMS por proveer soporte transaccional, será rentable?. Otro campo de investigación son las diversas formas de manejar una excepción que pueda llegar a ejecutar un Rollback. También es importante como manejar las excepciones en Workflow y contar con reglas activas para prevenir los Rollbacks. Por lo que prevenir, sería una solución del WMS óptima.. Los sistemas de workflow de larga escala pueden ser un problema dependiendo el tamaño de información manejada. Esto ocurre si por ejemplo un Workflow maneja un número muy grande de usuarios concurrentes, y esto pueda a llegar a ser un problema si no se busca una solución de optimización. Este sería el caso si se ejecutaran miles de instancias de procesos simultáneamente, y se requiriera una sólida recuperación en caso de producirse errores. 8 REFERENCIAS 1 The Workflow Management Coalition. Terminology & Glossary. The Workflow Management Coalition Specification. Issue 3.0 (1999). pp Moreno, J. y Ocampo, E. Comunidad de Práctica en Automatización de Procesos de Negocios en la Universidad Católica del Uruguay II Congreso Internacional de la Sociedad y el

14 la Universidad Católica del Uruguay. II Congreso Internacional de la Sociedad y el Conocimiento. Majadahonda, Madrid, España. (2003). 3 P. Grefen, B. Pernici y G. Sánchez, Database Support For Workflow Management. Kluwer Academic Publisher. (1999). 4 Garcia-Molina, H. and K. Salem, Sagas, Proc. ACM SIGMOD Conf. (1987) 5 G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R Günthor, C. Mohan. Advanced Transaction Models in Workflow Context. (1996) 6 B. Kiepuszewski, R. Muhlberger, M. Orlowska. Flowback: Providing backward recovery for workflow system. In proceeding of the ACM SIGMOD International Conference on Management on Data pages (1998) 7 J. Moss, Nested Transactions: An Approach To Reliable Distributed Computing MIT laboraty for Computer Science, MIT/LCS/TR-260. (1981) 8 D. Worah y A. Sheth, Transactions in Transactional Workflows. In S. Jajodia and L.Kershberg, editors, Advanced Transaction Models and Architectures. Kluwer Academic Publishers. (1997). 9 J. Eder y W. Liebhart, The Workflow Activity Model WAMO. In Proc. Of the 3er Int. Conference on Cooperative Information System, Vienna, Austria (1995). 10 D. Worah, A. Sheth, K. Kochut, J. Miller. An Error Handling Framework for the ORBWork Workflow Enactment Service of METEOR. Technical Report, LSDIS Lab. Dept. of Computer Science, Univ. of Georgia. (1997). 11 F. Casati, A Discussion on Approaches to Handling Exceptions in Workflows. (1998). 12 J. Eder y W. Liebhart, Workflow Recovery. In 1 st IFCIS Int. Conference on Cooperative Information Systems, Brussels, Belgium. (1996). 13 J.Eder y W. Liebhart, Workflow Management and Databases. (1996) 14 Sheth and M. Rusinkiewicz. On Transactional Workflow. Bulletin of Technical Committee on Data Engineering, 16(2). (1993)

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC.

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow Palabras claves: Groupware, Workflow, BPCM, WfMC. Introducción A partir de la llegada de las computadoras personales al ambiente empresarial

Más detalles

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: TIPOS DE SI: SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS, GROUPWARE, SISTEMA DE WORKFLOW Material diseñado y elaborado por: Prof. Anna Cecilia Grimán SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS Los Sistemas

Más detalles

Francisco Pérez Sorrosal. Tutores: Ricardo Jiménez Péris y Marta Patiño Martínez

Francisco Pérez Sorrosal. Tutores: Ricardo Jiménez Péris y Marta Patiño Martínez Francisco Pérez Sorrosal Tutores: Ricardo Jiménez Péris y Marta Patiño Martínez Introducción Con la irrupción y gradual implantación de Internet en la sociedad, la visión empresarial de los negocios ha

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

BASES DE DATOS TEMA 5 RECUPERACIÓN DE FALLAS

BASES DE DATOS TEMA 5 RECUPERACIÓN DE FALLAS BASES DE DATOS TEMA 5 RECUPERACIÓN DE FALLAS 5.1 Clasificación de fallas El sistema debe estar preparado para recuperarse no sólo de fallas puramente locales, como la aparición de una condición de desborde

Más detalles

Bases de Datos I. Cursada 2008. Clase 7: Recuperación de BD. Introducción a la Seguridad. Introducción a la Seguridad

Bases de Datos I. Cursada 2008. Clase 7: Recuperación de BD. Introducción a la Seguridad. Introducción a la Seguridad Bases de Datos I Cursada 2008 Clase 7: Recuperación de BD Facultad de Ciencias Exactas Universidad Nac. Centro de la Pcia. de Bs. As. 1 Introducción a la Seguridad Una base de datos es: Un conjunto de

Más detalles

Tema 6. Transacciones y seguridad

Tema 6. Transacciones y seguridad Tema 6. Transacciones y seguridad Las aplicaciones de bases de datos a gran escala, con bases de datos de gran tamaño y con cientos de usuarios concurrentes, como los sistemas de reservas, los bancos,

Más detalles

CONCEPTOS DE PROCESAMIENTO DE TRANSACCIONES

CONCEPTOS DE PROCESAMIENTO DE TRANSACCIONES Tema 6. CONCEPTOS DE PROCESAMIENTO DE TRANSACCIONES TRANSACCIONES Una transacción es una unidad lógica de trabajo o procesamiento (ejecución de un programa que incluye operaciones de acceso a la base de

Más detalles

Workflow: Tecnología Para la Innovación Organizacional. Workflow: Tecnología Para la Innovación Organizacional

Workflow: Tecnología Para la Innovación Organizacional. Workflow: Tecnología Para la Innovación Organizacional Workflow: Tecnología Para la Innovación Organizacional Lic. Elizabeth Acosta Gonzaga Profesora del CIDETEC-IPN M. en C. Abraham Gordillo Mejia Profesor de UPIICSA-IPN L a búsqueda de mayor productividad

Más detalles

M.T.I. Arturo López Saldiña

M.T.I. Arturo López Saldiña M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

1. PROCESOS DEL PROJECT MANAGEMENT

1. PROCESOS DEL PROJECT MANAGEMENT INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas SGBD Base de Un Sistema Gestor de consiste en: Datos Una colección de datos interrelacionados Un conjunto de programas para acceder a los datos Objetivo Principal de un SGBD: Proporcionar una forma práctica

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Universidad Politécnica de Madrid. Facultad de Informática

Universidad Politécnica de Madrid. Facultad de Informática Universidad Politécnica de Madrid Facultad de Informática Departamento de Lenguajes, Sistemas Informáticos e Ingeniería del Software Trabajo de Investigación del Programa de Doctorado Estudio de Modelos

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles

Asignación de Procesadores

Asignación de Procesadores INTEGRANTES: Asignación de Procesadores Un sistema distribuido consta de varios procesadores. Estos se pueden organizar como colección de estaciones de trabajo personales, una pila pública de procesadores

Más detalles

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi BPMN 2.0 Bizagi Suite BPMN 2.0 1 Tabla de Contenido Scope... 2 BPMN 2.0... 2 Qué es BPMN?... 2 Por qué es importante modelar con BPMN?... 3 Conceptos clave... 3 Proceso De Solicitud De Crédito... 3 Proceso

Más detalles

Concurrencia. Bibliografía: Introducción a los Sistemas de Bases de Datos Date, C.J.

Concurrencia. Bibliografía: Introducción a los Sistemas de Bases de Datos Date, C.J. Concurrencia Bibliografía: Introducción a los Sistemas de Bases de Datos Date, C.J. Concurrencia La mayor parte de los DBMS son sistemas para múltiples usuarios Se permite a cualquier cantidad de transacciones

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

TEMA 5 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 5. CONFIABILIDAD

TEMA 5 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 5. CONFIABILIDAD 1 1 BASES DE DATOS DISTRIBUIDAS TEMA 5 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 5. CONFIABILIDAD 5.1 Conceptos básicos de confiabilidad 5.2 Protocolos Redo - Undo 5.3 Puntos de verificación - checkpoints

Más detalles

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 Prof. Edgardo Adrián Franco Martínez http://computacion.cs.cinvestav.mx/~efranco efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

IMPLEMENTACIÓN DE UNA HERRAMIENTA WORKFLOW PARA LA AUTOMATIZACIÓN DE PROCESOS ENTRE LAS UNIDADES ACADÉMICAS Y ADMINISTRATIVAS DE LA ESPOL

IMPLEMENTACIÓN DE UNA HERRAMIENTA WORKFLOW PARA LA AUTOMATIZACIÓN DE PROCESOS ENTRE LAS UNIDADES ACADÉMICAS Y ADMINISTRATIVAS DE LA ESPOL IMPLEMENTACIÓN DE UNA HERRAMIENTA WORKFLOW PARA LA AUTOMATIZACIÓN DE PROCESOS ENTRE LAS UNIDADES ACADÉMICAS Y ADMINISTRATIVAS DE LA ESPOL Carlos Mera Gómez 1, Francisco Ramírez Méndez 2, Galo Valverde

Más detalles

SISTEMAS DE ARCHIVOS DISTRIBUIDOS

SISTEMAS DE ARCHIVOS DISTRIBUIDOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS Tema # VII Sistemas de operación II Abril-Julio 2008 Yudith Cardinale Introducción Requisitos Aspectos de Diseño Servicios de archivos Servicios de directorios Módulo

Más detalles

Modelado de Procesos de Negocio con BPMN Francisco Ruiz http://alarcos.inf

Modelado de Procesos de Negocio con BPMN Francisco Ruiz http://alarcos.inf Modelado de Procesos de Negocio con BPMN Francisco Ruiz http://alarcos.inf alarcos.inf-cr.uclm.escr.uclm.es Universidad de Castilla-La Mancha Procesos de Negocio y su Tecnología Procesos de Negocio Un

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

La Gestión por Procesos en las Organizaciones La forma en la que los resultados se logran

La Gestión por Procesos en las Organizaciones La forma en la que los resultados se logran La Gestión por Procesos en las Organizaciones La forma en la que los resultados se logran Deloitte S.C. 2014 Reflexiones Aplicando la Gestión por Procesos en nuestras organizaciones Por qué adoptar un

Más detalles

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler Bizagi Process Modeler Copyright 2011 - bizagi Contenido 1. INTRODUCCIÓN A LAS TRANSACCIONES... 3 2. DIAGRAMA DEL PROCESO... 4 SUB PROCESO RESERVA... 5 SUB PROCESO REPORTE DE GASTOS... 8 3. MODELO DE DATOS...

Más detalles

Manejo de Transacciones

Manejo de Transacciones Bases de Datos Transacciones 1 Manejo de Transacciones Jorge Pérez Rojas Universidad de Talca, II Semestre 2006 Bases de Datos Transacciones 2 Transacciones Hasta ahora el modelo de operación en la BD

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

15. Recuperación de fallos del sistema

15. Recuperación de fallos del sistema 15. Recuperación de fallos del sistema Objetivos Apreciar la necesidad de establecer un producto fiable, capaz de proteger la información frente a fallos del sistema Identificar los tipos de fallos que

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE

EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE DAVID CHAPPELL OCTUBRE DE 2010 PATROCINADO POR MICROSOFT CORPORATION CONTENIDOS Por qué crear un nuevo modelo de programación?... 3 Las tres reglas del modelo

Más detalles

Modelado de Procesos

Modelado de Procesos Modelado de Procesos Material desarrollado por -An. Miguel Brunnello y Cr. Marcelo Rocha Vargas (1ra.versión 2010) -Cr. Marcelo Rocha Vargas (Actualización 2011) Introducción En los orígenes de las TICs,

Más detalles

COMUNIDAD DE PRÁCTICA EN AUTOMATIZACION DE PROCESOS DE NEGOCIOS EN LA UNIVERSIDAD CATÓLICA DEL URUGUAY.

COMUNIDAD DE PRÁCTICA EN AUTOMATIZACION DE PROCESOS DE NEGOCIOS EN LA UNIVERSIDAD CATÓLICA DEL URUGUAY. COMUNIDAD DE PRÁCTICA EN AUTOMATIZACION DE PROCESOS DE NEGOCIOS EN LA UNIVERSIDAD CATÓLICA DEL URUGUAY. Juan J. Moreno. Universidad Pontificia de Salamanca, Campus de Madrid, Facultad de Informática, Madrid,

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006.

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006. Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 2 Calidades del producto y del proceso Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar]

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Bases de Datos Especializadas

Bases de Datos Especializadas Bases de Datos Especializadas 1 Sesión No.5 Nombre: Fallas y control de concurrencia en un modelo distribuido Objetivo: Al término de la sesión, el alumno explicará elementos de las bases de datos distribuidas.

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización Renato de Laurentiis Gianni Director IBERICA IT Group Introducción Cada vez más los Sistemas BPMS-Business Process

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Conceptos de Q-flow Enterprise Edition

Conceptos de Q-flow Enterprise Edition Q-flow 2.2 Código de Manual: Qf22008ESP Versión del Manual: 1.1 Última revisión: 17/3/2006 Se aplica a: Q-flow 2.2 Enterprise Edition Conceptos de Q-flow Enterprise Edition Qf22008ESP v1.1 Q-flow Conceptos

Más detalles

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS Dámaso López Aragón Introducción En la actualidad, la orientación a objetos es una nueva forma de comprender los problemas y modelar el negocio de una empresa,

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la

Más detalles

Base de Datos. Profesor: José Miguel Rubio L. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING.

Base de Datos. Profesor: José Miguel Rubio L. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING. INFORMÁTICA Base de Datos Usuario A Programa de Aplicación Bodega Usuario B Usuario N Insumo Proveedor Profesor: José Miguel

Más detalles

COMPUTACIÓN DE ALTA PERFORMANCE

COMPUTACIÓN DE ALTA PERFORMANCE COMPUTACIÓN DE ALTA PERFORMANCE 2011 1 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE Curso 2011 Sergio Nesmachnow (sergion@fing.edu.uy) Santiago Iturriaga (siturria@fing.edu.uy) Gerardo Ares (gares@fing.edu.uy)

Más detalles

Unidad IV: Operación y mantenibilidad 4.1 Bitácoras de trabajo del DBMS

Unidad IV: Operación y mantenibilidad 4.1 Bitácoras de trabajo del DBMS Unidad IV: Operación y mantenibilidad 4.1 Bitácoras de trabajo del DBMS En caso de que sea multiusuario existen muchas ventajas adicionales, donde la BD es con toda probabilidad mucho más grande y compleja.

Más detalles

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

Autores: LSI. Vilma Caicedo & Augusto Barriga

Autores: LSI. Vilma Caicedo & Augusto Barriga Pagina - 1 - Resumen de la Tecnología KMS Esta tecnología nació producto de las necesidades que tienen las organizaciones de mejorar sus procesos de negocios utilizando en forma recursiva los conocimientos

Más detalles

Programación generativa

Programación generativa ujuarez@itorizaba.edu.mx Instituto Tecnológico de Orizaba 15 de octubre de 2010 Agenda 1 Introducción Panorama general Problemática 2 Implementación generativa Bibliotecas activas Bibliotecas activas:

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS Autores: Introducción Diego R. López RedIRIS diego.lopez@rediris.es El trabajo necesario para mantener un servidor de información

Más detalles

24.3. BASES DE DATOS EN MEMORI A P RI NC I P AL

24.3. BASES DE DATOS EN MEMORI A P RI NC I P AL FUNDAMENTOS DE BASES DE DATOS 24.2.4. Recuperación de los flujos de trabajo El objetivo de la recuperación de los flujos de trabajo es hacer que se cumpla la atomicidad ante fallos de los flujos de trabajo.

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

5. RECUPERACIÓN DE FALLAS

5. RECUPERACIÓN DE FALLAS 5. RECUPERACIÓN DE FALLAS 5.1 Clasificación de fallas 5.2 Modelo de transacciones 5.3 Recuperación por bitácora 5.4 Puntos de verificación 5.1 Clasificación de fallas TIPOS DE FALLAS. El sistema debe estar

Más detalles

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow?

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow? Qué significa workflow? Es un término en inglés para proceso de negocio. Su uso en ese idioma se extendió para todo lo vinculado a herramientas informáticas que contribuyen a la automatización y al control

Más detalles

Servicios de Mantenimiento y Soporte Técnico de IBM. Un enfoque innovador del mantenimiento y soporte técnico

Servicios de Mantenimiento y Soporte Técnico de IBM. Un enfoque innovador del mantenimiento y soporte técnico IBM Global Technology Services Mantenimiento y Soporte Técnico Servicios de Mantenimiento y Soporte Técnico de IBM Un enfoque innovador del mantenimiento y soporte técnico 2 Servicios de Mantenimiento

Más detalles

Memoria Virtual. Figura 1: Memoria Virtual

Memoria Virtual. Figura 1: Memoria Virtual 1 Memoria Virtual. Qué podemos hacer si un programa es demasiado grande para caber en la memoria disponible? Una posibilidad es usar superposiciones (overlays), como en MS-DOS: dividimos el programa en

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

Más detalles

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Rafael Rodríguez-Puente 1, Eliana B. Ril-Valentin 2 1 Departamento de Técnicas de

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Microsoft. Febrero de 2006

Microsoft. Febrero de 2006 Microsoft Febrero de 2006 Tabla de contenido Información general de Microsoft Office InfoPath 2007...1 Incorpore eficacia a sus formularios comerciales...1 Amplíe el alcance de sus formularios comerciales...2

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

SQL Server 2000 está diseñado para trabajar con dos tipos de bases de datos :

SQL Server 2000 está diseñado para trabajar con dos tipos de bases de datos : Introducción a SQL Server 2000 SQL Server 2000 es un sistema de gestión de bases de datos relacionales (SGDBR o RDBMS: Relational Database Management System) diseñado para trabajar con grandes cantidades

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

CAPÍTULO 2 DATA WAREHOUSES

CAPÍTULO 2 DATA WAREHOUSES CAPÍTULO 2 DATA WAREHOUSES Un Data Warehouse (DW) es un gran repositorio lógico de datos que permite el acceso y la manipulación flexible de grandes volúmenes de información provenientes tanto de transacciones

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

Más detalles

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que

Más detalles

GENERALIDADES DE LA COMUNICACIÓN DE DATOS

GENERALIDADES DE LA COMUNICACIÓN DE DATOS Comunicaciones I Capítulo 1 GENERALIDADES DE LA COMUNICACIÓN DE DATOS 1 El Sistema de Comunicación Sistema de comunicación: Lleva a cabo el intercambio de información entre dos entes ubicados en los extremos

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles