Este trabalho apresenta uma arquitetura para Ambientes de Desenvolvimento de Software (ADS). Esta arquitetura é baseada em produtos comerciais de prateleira (COTS), principalmente em um Sistema de Gerência de Workflow – SGW (Microsoft Exchange 2000 Server – E2K) - e tem como plataforma de funcionamento a Internet, integrando também algumas ferramentas que fazem parte do grande conjunto de aplicativos que é utilizado no processo de desenvolvimento de software. O desenvolvimento de um protótipo (WOSDIE – WOrkflow-based Software Development Integrated Environment) baseado na arquitetura apresentada é descrito em detalhes, mostrando as etapas de construção, funções implementadas e dispositivos necessários para a integração de um SGW, ferramentas de desenvolvimento, banco de dados (WSS – Web Storage System) e outros, para a construção de um ADS. O processo de software aplicado no WOSDIE foi extraído do RUP (Rational Unified Process – Processo Unificado Rational). Este processo foi modelado na ferramenta Workflow Designer, que permite a modelagem dos processos de workflow dentro do E2K. A ativação de ferramentas a partir de um navegador Web e o armazenamento dos artefatos produzidos em um projeto de software também são abordados. O E2K faz o monitoramento dos eventos que ocorrem dentro do ambiente WOSDIE, definindo, a partir das condições modeladas no Workflow Designer, quais atividades devem ser iniciadas após o término de alguma atividade anterior e quem é o responsável pela execução destas novas atividades (assinalamento de atividades). A arquitetura proposta e o protótipo WOSDIE são avaliados segundo alguns critérios retirados de vários trabalhos. Estas avaliações mostram em mais detalhes as características da arquitetura proposta e proporcionam uma descrição das vantagens e problemas associados ao WOSDIE.

Sistemas de gerência de workflow estão sendo amplamente utilizados para a modelagem e a execução dos processos de negócios das organizações. Tipicamente, esses sistemas interpretam um workflow e atribuem atividades a participantes, os quais podem utilizar ferramentas e aplicativos para sua realização. Recentemente, XML começou a ser utilizada como linguagem para representação dos processos bem como para a interoperação entre várias máquinas de workflow. Os processos de negócio são, na grande maioria, dinâmicos, podendo ser modi- ficados devido a inúmeros fatores, que vão desde a correção de erros até a adaptação a novas leis externas à organização. Conseqüentemente, os workflows correspondentes devem também evoluir, para se adequar às novas especificações do processo. Algumas propostas para o tratamento deste problema já foram definidas, enfocando principalmente as alterações sobre o fluxo de controle. Entretanto, para workflows representados em XML, ainda não foram definidos mecanismos apropriados para que a evolução possa ser realizada. Este trabalho apresenta uma estratégia para a evolução de esquemas de workflow representados em XML. Esta estratégia é construída a partir do conceito de versionamento, que permite o armazenamento de diversas versões de esquemas e a consulta ao hist´orico de versões e instâncias. As versões são representadas de acordo com uma linguagem que considera os aspectos de evolução. As instâncias, responsáveis pelas execuções particulares das versões, também são adequadamente modeladas. Além disso, é definido um método para a migração de instâncias entre versões de esquema, no caso de uma evolução. A aplicabilidade da estratégia proposta é verificada por meio de um estudo de caso.

Sistemas de gerência de workflow estão sendo amplamente utilizados para a modelagem e a execução dos processos de negócios das organizações. Tipicamente, esses sistemas interpretam um workflow e atribuem atividades a participantes, os quais podem utilizar ferramentas e aplicativos para sua realização. Recentemente, XML começou a ser utilizada como linguagem para representação dos processos bem como para a interoperação entre várias máquinas de workflow. Os processos de negócio são, na grande maioria, dinâmicos, podendo ser modi- ficados devido a inúmeros fatores, que vão desde a correção de erros até a adaptação a novas leis externas à organização. Conseqüentemente, os workflows correspondentes devem também evoluir, para se adequar às novas especificações do processo. Algumas propostas para o tratamento deste problema já foram definidas, enfocando principalmente as alterações sobre o fluxo de controle. Entretanto, para workflows representados em XML, ainda não foram definidos mecanismos apropriados para que a evolução possa ser realizada. Este trabalho apresenta uma estratégia para a evolução de esquemas de workflow representados em XML. Esta estratégia é construída a partir do conceito de versionamento, que permite o armazenamento de diversas versões de esquemas e a consulta ao hist´orico de versões e instâncias. As versões são representadas de acordo com uma linguagem que considera os aspectos de evolução. As instâncias, responsáveis pelas execuções particulares das versões, também são adequadamente modeladas. Além disso, é definido um método para a migração de instâncias entre versões de esquema, no caso de uma evolução. A aplicabilidade da estratégia proposta é verificada por meio de um estudo de caso.

Este trabalho apresenta uma arquitetura para Ambientes de Desenvolvimento de Software (ADS). Esta arquitetura é baseada em produtos comerciais de prateleira (COTS), principalmente em um Sistema de Gerência de Workflow – SGW (Microsoft Exchange 2000 Server – E2K) - e tem como plataforma de funcionamento a Internet, integrando também algumas ferramentas que fazem parte do grande conjunto de aplicativos que é utilizado no processo de desenvolvimento de software. O desenvolvimento de um protótipo (WOSDIE – WOrkflow-based Software Development Integrated Environment) baseado na arquitetura apresentada é descrito em detalhes, mostrando as etapas de construção, funções implementadas e dispositivos necessários para a integração de um SGW, ferramentas de desenvolvimento, banco de dados (WSS – Web Storage System) e outros, para a construção de um ADS. O processo de software aplicado no WOSDIE foi extraído do RUP (Rational Unified Process – Processo Unificado Rational). Este processo foi modelado na ferramenta Workflow Designer, que permite a modelagem dos processos de workflow dentro do E2K. A ativação de ferramentas a partir de um navegador Web e o armazenamento dos artefatos produzidos em um projeto de software também são abordados. O E2K faz o monitoramento dos eventos que ocorrem dentro do ambiente WOSDIE, definindo, a partir das condições modeladas no Workflow Designer, quais atividades devem ser iniciadas após o término de alguma atividade anterior e quem é o responsável pela execução destas novas atividades (assinalamento de atividades). A arquitetura proposta e o protótipo WOSDIE são avaliados segundo alguns critérios retirados de vários trabalhos. Estas avaliações mostram em mais detalhes as características da arquitetura proposta e proporcionam uma descrição das vantagens e problemas associados ao WOSDIE.

A demanda por aplicações de workflow tem crescido rapidamente. Por um lado há uma evolução em ambientes com plataformas de sistemas maduras e disseminadas, por outro, processos de redesenho administrativo têm contribuído no aumento desta demanda. Apesar disto, profissionais de TI ainda encontram alguns problemas, e por isto, têm se aproximado de workflow com receio. Na administração pública de Porto Alegre, a otimização dos processos organizacionais de atendimento às demandas individuais dos cidadãos - que geram um registro em papel que constitui o que se denomina processo administrativo ou expediente, ou seja, um volume físico de papéis tramitando manualmente pelas estruturas que atuam no atendimento da demanda - redundou no emprego de ferramentas de automação para introduzir maior produtividade e eficiência na mudança dos métodos de trabalho. Mas alguns problemas se destacaram quando foi iniciado o desenvolvimento de aplicações de automação de processos. Uma face deles se mostrou em problemas conceituais que vão desde a confusão entre workflow e outras áreas, como BPR ou GED, à falta de domínio sobre as abstrações fundamentais na elicitação de workflow. Outra face se mostrou nos WMS, verdadeiros ambientes proprietários, fechados e pesados, de difícil utilização e pouco flexíveis para os desenvolvedores utilizarem em seu ambiente. Finalmente, outro problema foi a integração de aplicações de workflow com sistemas de informação, buscando informações e eventos em aplicações legadas, algumas existentes por décadas. Frente a isto, este trabalho aborda a produção de workflow sob a ótica dos desenvolvedores - analistas, projetistas e programadores - que necessitam criar aplicações corporativas em seus ambientes de Engenharia de Software. Neste cenário, a linha divisória entre a elaboração de uma aplicação de workflow e um sistema de informação se torna tênue, e compreender os aspectos envolvidos, dominá-los e utilizá-los neste ambiente é primordial para o sucesso e disseminação de aplicações de automação de processos. Este trabalho propõe uma extensão do Diagrama de Atividades da UML para modelar e elicitar o controle de atividades, a criação de um motor de workflow para executar a máquina de estados do Diagrama de Atividades, a ser utilizado como componente na arquitetura das aplicações. A utilização do motor de workflow e do Diagrama de Atividades estendido são apresentados num case de automação de um processo da Secretaria do Planejamento Municipal da Prefeitura Municipal de Porto Alegre que atende a solicitações diretas dos cidadãos.

A demanda por aplicações de workflow tem crescido rapidamente. Por um lado há uma evolução em ambientes com plataformas de sistemas maduras e disseminadas, por outro, processos de redesenho administrativo têm contribuído no aumento desta demanda. Apesar disto, profissionais de TI ainda encontram alguns problemas, e por isto, têm se aproximado de workflow com receio. Na administração pública de Porto Alegre, a otimização dos processos organizacionais de atendimento às demandas individuais dos cidadãos - que geram um registro em papel que constitui o que se denomina processo administrativo ou expediente, ou seja, um volume físico de papéis tramitando manualmente pelas estruturas que atuam no atendimento da demanda - redundou no emprego de ferramentas de automação para introduzir maior produtividade e eficiência na mudança dos métodos de trabalho. Mas alguns problemas se destacaram quando foi iniciado o desenvolvimento de aplicações de automação de processos. Uma face deles se mostrou em problemas conceituais que vão desde a confusão entre workflow e outras áreas, como BPR ou GED, à falta de domínio sobre as abstrações fundamentais na elicitação de workflow. Outra face se mostrou nos WMS, verdadeiros ambientes proprietários, fechados e pesados, de difícil utilização e pouco flexíveis para os desenvolvedores utilizarem em seu ambiente. Finalmente, outro problema foi a integração de aplicações de workflow com sistemas de informação, buscando informações e eventos em aplicações legadas, algumas existentes por décadas. Frente a isto, este trabalho aborda a produção de workflow sob a ótica dos desenvolvedores - analistas, projetistas e programadores - que necessitam criar aplicações corporativas em seus ambientes de Engenharia de Software. Neste cenário, a linha divisória entre a elaboração de uma aplicação de workflow e um sistema de informação se torna tênue, e compreender os aspectos envolvidos, dominá-los e utilizá-los neste ambiente é primordial para o sucesso e disseminação de aplicações de automação de processos. Este trabalho propõe uma extensão do Diagrama de Atividades da UML para modelar e elicitar o controle de atividades, a criação de um motor de workflow para executar a máquina de estados do Diagrama de Atividades, a ser utilizado como componente na arquitetura das aplicações. A utilização do motor de workflow e do Diagrama de Atividades estendido são apresentados num case de automação de um processo da Secretaria do Planejamento Municipal da Prefeitura Municipal de Porto Alegre que atende a solicitações diretas dos cidadãos.

Este trabalho apresenta uma arquitetura para Ambientes de Desenvolvimento de Software (ADS). Esta arquitetura é baseada em produtos comerciais de prateleira (COTS), principalmente em um Sistema de Gerência de Workflow – SGW (Microsoft Exchange 2000 Server – E2K) - e tem como plataforma de funcionamento a Internet, integrando também algumas ferramentas que fazem parte do grande conjunto de aplicativos que é utilizado no processo de desenvolvimento de software. O desenvolvimento de um protótipo (WOSDIE – WOrkflow-based Software Development Integrated Environment) baseado na arquitetura apresentada é descrito em detalhes, mostrando as etapas de construção, funções implementadas e dispositivos necessários para a integração de um SGW, ferramentas de desenvolvimento, banco de dados (WSS – Web Storage System) e outros, para a construção de um ADS. O processo de software aplicado no WOSDIE foi extraído do RUP (Rational Unified Process – Processo Unificado Rational). Este processo foi modelado na ferramenta Workflow Designer, que permite a modelagem dos processos de workflow dentro do E2K. A ativação de ferramentas a partir de um navegador Web e o armazenamento dos artefatos produzidos em um projeto de software também são abordados. O E2K faz o monitoramento dos eventos que ocorrem dentro do ambiente WOSDIE, definindo, a partir das condições modeladas no Workflow Designer, quais atividades devem ser iniciadas após o término de alguma atividade anterior e quem é o responsável pela execução destas novas atividades (assinalamento de atividades). A arquitetura proposta e o protótipo WOSDIE são avaliados segundo alguns critérios retirados de vários trabalhos. Estas avaliações mostram em mais detalhes as características da arquitetura proposta e proporcionam uma descrição das vantagens e problemas associados ao WOSDIE.

[pt] Muitos experimentos científicos são elaborados como fluxos de tarefas computacionais, que podem ser implementados através do uso de linguagens de programação. Na área de bioinformática é muito comum o uso de scripts ad-hoc para construir fluxos de tarefas. Os Sistemas de Gerência de Workflow Científico (SGWC) surgiram como uma alternativa a estes scripts. Uma das funcionalidades desses sistemas que têm recebido bastante atenção pela comunidade científica é a captura automática de dados de proveniência. Estes permitem averiguar quais foram os recursos e parâmetros utilizados na geração dos resultados, dentre muitas outras informações indispensáveis para a validação e publicação de um experimento. Neste trabalho foram levantados alguns desafios na área de proveniência de dados em SGWCs, como por exemplo (i) a heterogeneidade de formas de representação dos dados nos diferentes sistemas, dificultando a compreensão e a interoperabilidade; (ii) o armazenamento de dados consumidos e produzidos e (iii) a reprodutibilidade de uma execução específica. Estes desafios motivaram a elaboração de um esquema conceitual de proveniência de dados para a representação de workflows. Foi implementada também uma extensão em um SGWC específico (BioSide) para incluir dados de proveniência e armazená-los utilizando o esquema conceitual proposto. Foram priorizados neste trabalho alguns requisitos comumente encontrados em workflows de Bioinformática. / [en] Many scientific experiments are designed as computational workflows, which can be implemented using traditional programming languages. In the Bioinformatics domain ad-hoc scripts are often used to build workflows. Scientific Workflow Management Systems (SWMS) have emerged as an alternative to those scripts. One particular SWMS feature that has received much attention by the scientific community is the automatic capture of provenance data. These allow users to track which resources and parameters were used to obtain the results, among many other required information to validate and publish an experiment. In the present work we have elicited some data provenance challenges in the SWMS context, such as (i) the heterogeneity of data representation schemes that hinders the understanding and interoperability; (ii) the storage of consumed and produced data and (iii) the reproducibility of a specific execution. These challenges have motivated the proposal of a data provenance conceptual scheme for workflow representation. We have implemented an extension of a particular SWMS system (Bioside) to include provenance data and store them using the proposed conceptual scheme. We have focused on some requirements commonly found in bioinformatics workflows.

The diploma thesis is a business case of a company that focuses on technical solution and specification of a process optimalization of incoming consignments and other kind of incoming documents processing. The objective of the thesis is considering all „pros and cons“ in order to be recommended either to go or not to go of the project.

Indiana University-Purdue University Indianapolis (IUPUI) / Reproducible computing and research are of great importance for scientific investigation in any discipline. This thesis presents a general approach to provenance in the context of workflows for widely used script languages. Our solution is based on system integration, and is demonstrated by integrating MATLAB with VisTrails, an open source scientific workflow system. The integrated VisTrails-MATLAB system supports reproducible computing with truly prospective and retrospective provenance at multiple granularity levels as scientists choose for their scripts, and at the same time, is very easy to use.