WebC-Docs/Wf - Gestão Documental com Mecanismos de Workflow. Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores - PDF
WebC-Docs/Wf - Gestão Documental com Mecanismos de Workflow. Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores
Download "WebC-Docs/Wf - Gestão Documental com Mecanismos de Workflow. Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores"
Luna Carreiro Caldeira
1 WebC-Docs/Wf - Gestão Documental com Mecanismos de Workflow Carlos Manuel Calisto Rocha Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Orientador: Vogal: Professor Doutor José Manuel Nunes Salvador Tribolet Professor Doutor Alberto Manuel Rodrigues da Silva Professor Doutor António Manuel Ferreira Rito da Silva Outubro de 2010
3 Agradecimentos Começo por agradecer ao Professor Alberto Silva, pela orientação e assistência ao longo de todo o trabalho. Uma palavra de apreço ao João Saraiva e David Ferreira, pela disponibilidade na discussão de ideias e no suporte da fase de implementação. Por fim, um agradecimento profundo à minha família, a quem devo a formação académica que estou prestes a concluir.
5 Resumo A administração eficaz e eficiente da informação é hoje uma preocupação importante nas organizações. Os sistemas de gestão documental contribuem nesta área com o suporte do ciclo de vida dos documentos, desde a sua criação até ao seu arquivo ou eliminação. Um dos aspectos importantes nestes sistemas é também o controlo da circulação dos documentos entre as pessoas, cujo suporte pode ser feito através de mecanismos de workflow. Neste trabalho, além da identificação dos principais componentes que devem figurar nesta classe de sistemas, apresenta-se uma solução de gestão de workflows orientados ao conteúdo, focada nos aspectos fundamentais que caracterizam um processo documental. Palavras-Chave Documento Sistema de Gestão Documental Workflow orientado ao conteúdo WebC-Docs/Wf
7 Abstract An effective and efficient administration of the information is now a major concern in organizations. The document management systems contribute in this area with the support of the documents life cycle, from its creation to its disposal or archive. One important aspect of these systems is also the flow of documents between people, which can be supported by workflow engines. In this work, besides identifying the key components that must be included in this class of systems, it s also presented a content-oriented workflow solution, focused on the fundamental aspects that characterize a document process. Keywords Document Document Management System Content-oriented Workflow WebC-Docs/Wf
9 Índice Índice... 1 Lista de Figuras Introdução Contexto Problemas Objectivos Estrutura do Relatório Trabalho Relacionado Modelo de Referência Noção de Documento Tarefas Comuns da Gestão Documental Workflows em Sistemas de Gestão Documental Análise de Sistemas Documentais WebC-Docs Knowledge Tree Alfresco DSpace Comparação de Sistemas Documentais WebC-Docs/Wf Aspectos de Concepção Cenários de Utilização Revisão e aprovação de artigos Registo e notificação de correspondência Pedido de Compras Conceitos e Modelo de Domínio Pacotes de domínio Vista Geral
10 3.2.3 Definição de Workflows Execução de Workflows Formulários Actores e Casos de Uso Actores Casos de Uso WebC-Docs/Wf Aspectos de Implementação Plataforma WebComfort e o WebC-Docs Componentes do WebC-Docs/Wf Definição de Workflows Definição de Formulários Execução e Participação em Workflows Componentes lógicos Validação Registo e notificação de correspondência Conclusões Trabalho Futuro Referências Anexos
11 Lista de Figuras Fig. 1.1 Componentes do Enterprise Content Management, incluindo a gestão documental Document Management (DM) Fig. 1.2 Crescimento exponencial da informação ao longo dos anos... 8 Fig. 2.1 Tarefas Comuns da Gestão Documental Fig Estrutura genérica de um produto de workflow Fig Distribuição num motor de workflow orientado à tarefa Fig. 2.4 Ilustração de um workflow orientado ao conteúdo Fig Conceitos principais do WebC-Docs Fig. 2.6 APIs do Alfresco Fig Dependências entre os pacotes de domínio Fig Visão geral da arquitectura do WebC-Docs/Wf, segundo os conceitos e relações principais Fig. 3.3 Vista da definição de workflows Fig. 3.4 Vista da definição de uma regra de participação Fig. 3.5 Vista da definição de uma pré-condição Fig. 3.6 Vista da execução de workflows Fig. 3.7 Integração da entidade informacional com o WebC-Docs Fig. 3.8 Aplicação de workflows directamente a documentos do WebC-Docs Fig. 3.9 Vista de definição das Forms e de instanciação dos Fields Fig Actores do WebC-Docs/Wf Fig Casos de uso na fase de definição Fig Casos de uso na fase de execução Fig Casos de uso de configuração Fig. 4.1 Visão geral da arquitectura do WebC-Docs Fig. 4.2 Visão geral da integração do WebC-Docs com o WebComfort Fig. 4.3 Componentes do WebC-Docs/Wf Fig. 4.4 Componentes de definição de workflows Fig. 4.5 Módulo de gestão de definições de workflow Fig. 4.6 Página de criação ou edição de definições de workflow Fig. 4.7 Ecrãs de definição dos conceitos presentes no contexto de um estado
12 Fig Componentes de definição de formulários Fig. 4.9 Aspecto do módulo e páginas de definição de formulários Fig Componentes de execução de workflows Fig Módulo de configuração documental Fig Páginas de edição de pastas e documentos Fig Aspecto do módulo e páginas de notificação e encaminhamento de workflows Fig. 5.1 Estados e transições do processo de registo e notificação da empresa XPTO. 57 Fig. 5.2 Definição do workflow de registo e notificação de correspondência parte Fig Definição do workflow de registo e notificação de correspondência parte Fig. 5.4 Histórico de execução de uma das instâncias do workflow de registo e notificação de correspondência Fig. 5.5 Entidade informacional subjacente a uma das instâncias do workflow de registo e notificação de correspondência Fig. 8.1 Workflow Definition do processo de revisão e aprovação de artigos Fig Workflow Definition do processo do pedido de compra parte Fig. 8.3 Workflow Definition do processo do pedido de compra parte
13 1 Introdução Hoje em dia os sistemas de informação são determinantes na condução dos negócios nas empresas. A sobrevivência nas diversas indústrias torna-se impossível sem recurso às tecnologias de informação. As organizações procuram ser mais competitivas e eficientes, suportando digitalmente os processos de negócio e as relações com os clientes, fornecedores e empregados [1]. Resultante desta economia cada vez mais global e digital, a informação apresenta-se como um dos principais activos das organizações: representa o conhecimento necessário e constantemente adquirido na construção dos produtos e serviços; suporta os processos e a execução das respectivas actividades; providencia os dados imprescindíveis à gestão dos recursos e direcciona as empresas, fundamentando as decisões de mudança [2]. Neste sentido, gerir a informação revela-se como uma preocupação prioritária dentro das empresas e pode, numa perspectiva estratégica, traduzir-se numa vantagem competitiva nos mercados ferozes de hoje. Parte deste valor intangível reserva-se na forma de documentos. Genericamente, os documentos são classificados como conteúdos pouco estruturados [4] porque, ao contrário dos dados registados em campos de bases de dados, não mantêm um modelo ou estrutura que classifique claramente o seu conteúdo. Com o intuito de facilitar a gestão dos documentos, da sua vasta quantidade e do seu acesso diário, surgiram os sistemas de gestão documental, acompanhados pelos avanços tecnológicos na área do processamento de imagem, pela crescente capacidade e fiabilidade no armazenamento de dados e pelo aumento da largura de banda nos canais de comunicação [7]. O principal objectivo destes sistemas é suportar o ciclo de vida dos documentos, desde a sua criação até à sua eliminação ou arquivo [4, 7, 13]. A aplicação destes sistemas nas organizações resulta em inúmeros benefícios. A produtividade é incentivada, devido ao rápido acesso à informação pretendida e ao suporte dos processos de produção, revisão e aprovação de documentos. A segurança é reforçada, através de mecanismos de auditoria e controlo de acesso, difíceis de empregar nos arquivos físicos. Os custos são reduzidos, pela diminuição da compra do papel e do tempo associado à circulação da informação entre as pessoas. A gestão documental, mesmo reconhecida e evocada como uma área independente, é, muitas vezes, referida como uma componente integrante no ambiente do Enterprise 5
14 Content Management (ECM) [4]. Focado no papel da informação ao longo de toda uma organização, o ECM adopta uma visão de integração de múltiplas tecnologias de gestão de conteúdos. Além da gestão documental, o ECM pode combinar as seguintes áreas aplicacionais [3, 4]: Workflow/Business Process Management (BPM), Collaboration, Web Content Management (WCM) e Record Management (RM). Fig. 1.1 Componentes do Enterprise Content Management, incluindo a gestão documental Document Management (DM). Segundo a WfMC, os sistemas BPM definem, suportam e monitorizam a execução dos processos de negócio, automatizando a sequência das suas actividades e gerindo a atribuição dos recursos humanos e tecnológicos ao longo do fluxo [5]. Os processos são modelados ao nível conceptual das entidades informacionais e das aplicações empresariais, permitindo o mapeamento dos conteúdos e a evocação dos serviços necessários à realização das tarefas. Os sistemas colaborativos suportam o trabalho em grupo, ou seja, o trabalho realizado por um conjunto de pessoas com o mesmo objectivo, através de interfaces com acesso a ambientes partilhados, mecanismos de anotação e ferramentas de comunicação baseadas nas redes [14]. A gestão de conteúdos Web inclui os portais e manipula essencialmente páginas HTML ou XML, focando-se na produção de conteúdos sobre templates, separando a informação das questões de apresentação e oferecendo mecanismos de reutilização e publicação dinâmica [6, 4]. 6
15 Os sistemas RM direccionam-se na retenção de transacções e dados com valor estratégico a longo prazo, de formato electrónico, de acordo com regulamentos externos ou práticas internas, regras de retenção e direitos [4]. Esta recente terminologia do ECM surge sobretudo devido à proliferação de novos formatos de conteúdos, resultantes da expansão da Internet, e da concepção da gestão informacional a um nível empresarial, entre departamentos. Integrados em sistemas ECM ou implementados de forma mais independente, os sistemas de gestão documental devem partilhar desta filosofia transversal, baseada na relação intrínseca entre os documentos e os processos de negócio de uma organização. Neste sentido, e de forma a transformar os escritórios em espaços de trabalho menos dependentes do papel e das suas inconveniências, estas ferramentas podem englobar parte das funcionalidades dos domínios anteriormente descritos. À classificação, ao controlo de versões, à gestão de acessos e à facilidade de pesquisa juntam-se mecanismos de workflow e de colaboração, na procura de uma administração cada vez mais eficaz e eficiente dos documentos e dos seus fluxos. 1.1 Contexto O presente relatório descreve o trabalho desenvolvido durante o ano lectivo de 2009/2010 para a cadeira de Dissertação do Mestrado em Engenharia Informática e de Computadores do IST. A tese foi realizada no contexto de um estágio na SIQuant, empresa proprietária do WebComfort e do WebC-Docs, plataformas que serviram de base tecnológica para este projecto. O WebComfort é um Content Management System (CMS) desenvolvido e suportado pelas tecnologias Microsoft ASP.NET 2.0 (C#) e SQL Server 2005 [8]. Permite operar e integrar aplicações Web, disponibilizando ferramentas e mecanismos para gestão de conteúdos, estruturados ou não estruturados, através de browsers [9]. Tal como a maioria dos CMS, a plataforma WebComfort apresenta uma independência entre o conteúdo e a sua apresentação e possui como grandes vantagens a extensibilidade, a reutilização e a modularidade [8]. O WebC-Docs é um toolkit de gestão documental para a plataforma WebComfort [10]. Além da funcionalidade típica de arquivo de ficheiros, este sistema possui inúmeras funcionalidades, entre as quais: especificação de metadados dinâmicos para cada pasta ou documento; indexação e procura através de um motor de busca baseado no 7
16 Lucene.NET, ou através de outros motores adicionalmente integrados; e definição de permissões para cada pasta ou documento, inspirado no mecanismo ACL [10]. Um dos marcos deste trabalho firma-se na apresentação de uma proposta de extensão deste sistema de gestão documental. 1.2 Problemas A gestão de informação é um assunto crucial nas organizações. O tempo gasto em tarefas nesta área é grande e, com a crescente adesão da Internet pela sociedade, tende a agravar-se. A velocidade das transacções electrónicas tornou a produção de informação massiva, e as suas trocas intensas. A reorganização e redesenho das operações nas empresas devem ser impulsionadas por estes factores de mudança. Neste contexto, o consumo de tempo envolvido nas tarefas de criação, procura, pesquisa, recuperação, actualização e arquivo de documentos são preocupações de destaque, principalmente nas empresas historicamente orientadas à produção documental, como a banca, as seguradoras e a saúde. O descontrolo na gestão destes conteúdos, tanto internos como externos, aumenta o tempo atribuído às tarefas documentais, bem mais valioso na execução dos processos de negócio de valor acrescentado. Fig. 1.2 Crescimento exponencial da informação ao longo dos anos [15]. O tempo gasto nas tarefas documentais deve-se aos seguintes problemas [9, 15, 13, 16]: Os documentos são difíceis de encontrar. A imensa quantidade de informação nas empresas torna a procura em tempo útil complicada. Os documentos são difíceis de actualizar. A gestão inadequada das suas versões dificulta a localização dos conteúdos na última ou antigas versões. 8
17 Os documentos são difíceis de partilhar. O acesso simultâneo não é trivial e, por outro lado, a inexistência de um sítio central e seguro impossibilita a implementação de mecanismos de auditoria e autorização fiáveis, eficazes e bem definidos. Os processos orientados ao conteúdo, associados à circulação de documentos entre diversos actores, não estão muitas vezes especificados, tornando-se ineficientes e descontrolados. A importância do conteúdo de um documento não é óbvia. A falta de metodologias de classificação complica o acesso à informação necessária. O arquivamento físico dos documentos em papel é caro e ineficiente e fomenta a suas constantes perdas e duplicação de cópias. Documento electrónico e gestão documental não são sinónimos. Os múltiplos ficheiros gravados nos discos individuais, as várias versões, a indefinição dos seus períodos de retenção e a incompatibilidade de formatos a longo prazo representam mais custos de espaço e de tempo. Identificados os principais problemas nesta área, é natural que grande parte do esforço das organizações se concentre no corte da despesa e no aumento da eficiência dos processos documentais. No entanto, esta perspectiva mais táctica é limitada e muitas vezes insuficiente. Os documentos não devem ser considerados unicamente como um obstáculo ou um custo a conter, mas como uma oportunidade e um activo de valor. É fundamental que cada organização defina uma estratégia documental, vital na monitorização, direcção e melhoria da forma como a informação é usada. No contexto destes problemas foi desenvolvido o sistema WebC-Docs. Este sistema satisfaz alguns dos pontos referidos acima mas, como principal falta, não possibilita a especificação de workflows que suportem processos documentais. Actualmente, o WebC- Docs disponibiliza apenas mecanismos de gestão de documentos e pastas, de acordo com as permissões de cada utilizador. Por conseguinte, as questões fundamentais que estão na génese deste trabalho são: Como definir workflows orientados ao conteúdo, capazes de suportar processos típicos da área documental (ex: encaminhamentos, revisões, notificações)? Como modelar as dimensões principais de um processo documental, isto é, o fluxo, os participantes e a entidade informacional subjacente? 9
18 Como processar participações concorrentes de diferentes intervenientes, numa determinada fase do workflow? Como gerir, monitorizar e intervir como participante numa execução de workflow? Estas são outras questões que ao longo do relatório encontrarão resposta, no sentido de adaptar o WebC-Docs a cenários de aplicação mais complexos na temática documental. 1.3 Objectivos Contextualizado o tema da presente tese e identificados os principais problemas existentes na área da gestão documental, clarificam-se os objectivos que se pretendem ver alcançados com a realização deste trabalho: Análise, avaliação e comparação da tecnologia de sistemas de gestão documental, em particular no seu suporte a workflows. Análise e avaliação do WebC-Docs e apresentação de uma proposta de extensão com mecanismos de workflow, referida como WebC-Docs/Wf. Concepção e implementação do WebC-Docs/Wf. Teste e avaliação do sistema concebido. 1.4 Estrutura do Relatório Este relatório tem a seguinte estrutura: Capítulo 1. Introdução Este capítulo contextualiza os principais aspectos da tese e apresenta os objectivos do trabalho. Capítulo 2. Trabalho Relacionado Este capítulo apresenta a análise efectuada a algumas ferramentas de gestão documental, segundo um modelo de referência. Capítulo 3. WebC-Docs/Wf Aspectos de Concepção Este capítulo apresenta os actores, os casos de uso, os conceitos da arquitectura e alguns cenários de aplicação que motivam a utilização do WebC-Docs/Wf. Capítulo 4. WebC-Docs/Wf Aspectos de Implementação O quarto capítulo descreve os componentes implementados. 10
19 Capítulo 5. Validação Este capítulo descreve a validação do sistema com base nos cenários considerados. Capítulo 6. Conclusão Esta secção apresenta as conclusões da tese e um conjunto de aspectos para trabalho futuro. 11
21 2 Trabalho Relacionado Neste capítulo descreve-se o estado de arte dos sistemas de gestão documental e, em particular, dos aspectos ligados ao suporte de workflows. A primeira secção apresenta um modelo de referência e introduz os principais conceitos e funcionalidades deste tipo de sistemas. A segunda secção analisa, com base no modelo de referência proposto, alguns sistemas concretos, designadamente o WebC-Docs, o Knowledge Tree, o Alfresco e o DSpace. No final, são comparados e discutidos alguns aspectos dos sistemas referidos. 2.1 Modelo de Referência O modelo de referência seguidamente apresentado baseia-se na descrição e suporte de três aspectos essenciais que um sistema de gestão documental deve considerar: noção de documento, tarefas da gestão documental e workflows Noção de Documento Apesar de por vezes desvalorizada, uma das dúvidas mais comuns nesta área é a própria noção de documento. O conceito tem sofrido constantes evoluções e a visão tradicional do papel é já insuficiente no mundo informatizado de hoje. A noção moderna de documento orienta-se, cada vez mais, no sentido de tornar o conceito mais abrangente. Assim, várias questões podem ser colocadas: será que um documento é definido segundo a forma como se apresenta (papel ou digital)? Ou baseia-se na função que desempenha (facturas, livros, cartas, etc.)? Será que o áudio, os s, as páginas Web ou mesmo os vídeos devem ser considerados documentos? O que diferencia um documento dos milhares de ficheiros de uma organização? Um documento pode ser descrito como um simples registo de informação para consumo humano [17]. Por outro lado, um documento pode também ser definido segundo um conjunto de atributos, guardados e geridos como uma unidade [16]. Olhando com maior detalhe para a segunda perspectiva, um documento, como conjunto de informação, pode [16]: englobar diversos tipos de informação complexos, incluindo dados de vídeo ou anotações de voz; existir em múltiplos sítios ao longo de uma rede; depender de outros documentos; e ser acedido e modificado por várias pessoas em simultâneo, caso possuam as devidas permissões. Numa organização, os documentos que satisfazem esta definição exemplificam-se em diversas formas, tais como: contratos, relatórios, manuais, 13
22 formulários, correspondência, artigos, desenhos, fotografias, correio electrónico, mensagens de voz, vídeos, apresentações, etc. Estas definições incluem tanto o documento em papel como em versão electrónica, apesar de cada um dos formatos exigir diferentes métodos de gestão. Outro dos aspectos essenciais na compreensão de um documento é a sua função. Os documentos podem desempenhar diferentes papéis numa organização, categorizados nos três critérios seguintes [16]: Meio de comunicação Os documentos são meios de comunicação fundamentais à actividade organizacional, considerando as cartas e os anúncios como exemplo. Além disto, dada a sua função de comunicar e representar, os documentos podem igualmente ser descritos como um produto, dando como exemplo os manuais ou os relatórios de consultoria de uma empresa. Veículo de um processo de negócio Outra das funções de um documento é o suporte ao negócio de uma organização. Muitos dos processos de negócio de uma empresa consistem em fluxos documentais, baseados no processamento de informação com diversos intervenientes. Os formulários, os ficheiros a circular entre departamentos e os registos de dados ao longo de um processo são alguns exemplos deste facto. Memória organizacional Os documentos constituem a maior parte da memória de uma organização. A par das bases de dados, os documentos são o principal mecanismo para manter e transmitir a informação de uma empresa. Estas categorias não são necessariamente exclusivas: um documento pode servir diferentes papéis ao longo do seu ciclo de vida. Por exemplo, tanto a correspondência como os relatórios servem como mecanismo de comunicação numa primeira fase. No entanto, acabam depois por ser mantidos e guardados como memória da organização. Além de esclarecer o conceito de documento, a classificação anterior permite identificar os principais aspectos que um sistema de gestão documental deve contemplar no suporte às necessidades da área. A próxima subsecção apresenta esses aspectos Tarefas Comuns da Gestão Documental Resultante da análise de diversos sistemas de gestão documental, dos problemas que devem solucionar e baseado no modelo de ECM [3, 4] proposto pela AIIM e ainda noutras referências da área, considera-se que as principais etapas que este tipo de aplicações 14
23 deve suportar são a captura, o processamento, o arquivo e a disseminação de documentos. Fig. 2.1 Tarefas Comuns da Gestão Documental. Captura Nesta categoria enquadram-se as funcionalidades e componentes para capturar, gerar e preparar os documentos electrónicos no sistema. Estes documentos podem ter origem manual ou automática. O primeiro caso refere-se à informação presente nos documentos em papel, nos ficheiros produzidos através de aplicações de escritório, nos formulários, etc., todos criados ou tratados por pessoas. Por outro lado, as diversas aplicações empresariais representam também múltiplas fontes de produção automática de conteúdos e podem obrigar a definir estratégias de integração com os sistemas de gestão documental. Existem várias técnicas de digitalização de documentos físicos. Os sistemas Optical Character Recognition (OCR) convertem texto de imagem em caracteres reconhecidos e manipuláveis pelas máquinas. A escrita de mão pode ser tratada através de sistemas Handprint Character Recognition (HCR). Apesar de resultados pouco satisfatórios em texto corrido, tornam-se bastante fiáveis na leitura de campos curtos, previamente estruturados. Nesta área, destacam-se também as ferramentas Intelligent Character Recognition (ICR) que resultam da evolução das tecnologias anteriores e utilizam mecanismos de auto-aprendizagem e padrões de escrita, melhorando progressivamente os resultados. Cada vez mais os documentos electrónicos atingem o valor jurídico do papel [4], justificando a conversão do formato físico para o digital, através destes sistemas de processamento de imagem. Com os enormes volumes de informação presentes nas organizações, os documentos, e mais importante, o conhecimento que detêm, tornam-se difíceis de localizar. Não são raras a vezes quando só os próprios autores ficam com a noção correcta da sua utilidade e conteúdo. Desta forma, além de componentes de digitalização, os sistemas de gestão documental devem suportar metodologias de classificação aplicados na captura dos documentos. A classificação pode ser automática, através de mecanismos de análise e 15
24 extracção de informação contida nos documentos. A sua avaliação é feita por critérios pré-definidos ou através de processos de contínua aprendizagem. Por outro lado, os documentos devem estar associados a descrições, constituídos por metadados. Os metadados são essenciais no refinamento da procura e na compreensão da estrutura, qualidade e relevância da informação [19]. Os seus valores são normalmente introduzidos manualmente, pelos autores dos documentos, ou seja, por quem os criou e melhor os conhece. Existem também outros métodos de classificação baseados na criação colaborativa de tags e tag clouds. Uma tag é um termo não hierarquizado, atribuído a uma peça de informação, escolhido informalmente e segundo os critérios pessoais do autor ou de quem visualiza e acede à informação [18]. Processamento Nesta categoria discute-se como são geridos, processados e usados os documentos. Em primeiro, qualquer sistema desta classe deve gerir as versões dos conteúdos, acompanhando e guardando as sucessivas actualizações de um documento. No sentido de garantir a sua consistência, deve igualmente disponibilizar mecanismos de check in/ check out. A visualização é outro aspecto a considerar. As interfaces e estruturas de navegação são fundamentais no acesso e na interacção com os documentos. Por outro lado, a gestão de workflows representa hoje um tópico fundamental nestes sistemas. Além da entidade documento, os sistemas de gestão documental devem controlar os fluxos que os envolvem. Muitos dos processos das empresas são baseados na circulação de conteúdos entre várias pessoas, de diferentes departamentos. A melhoria de produtividade na produção, revisão, aprovação e encaminhamento de documentação surge com a aplicação de técnicas e métodos desta área. Este será um tópico discutido com maior detalhe mais adiante, na respectiva subsecção. Arquivo Os documentos e a meta informação podem ser guardados em repositórios, nos sistemas de ficheiros ou em bases de dados. Para fins de auditoria, os conteúdos são gravados juntamente com os respectivos registos de acesso e edição. Já numa perspectiva a longo prazo, as técnicas de preservação são uma garantia à disponibilidade da informação no futuro. A contínua migração dos dados, metadados e objectos dos sistemas antigos para novos pode ser trabalhosa, mas garante a acessibilidade e usabilidade da informação e permite a eliminação da que se torna 16
25 irrelevante. Por outro lado, a emulação de software antigo é sempre uma forma de acesso aos dados originais. Disseminação O objectivo desta categoria é apresentar a informação ao utilizador. As funcionalidades de pesquisa são importantes no acesso aos documentos necessários e são suportadas por mecanismos de indexação executados na entrada dos conteúdos no sistema. Relacionadas com esta categoria estão igualmente tecnologias de transformação [3]. Os documentos podem ser entregues noutros formatos, mais genéricos e flexíveis, como o PDF, ou comprimidos para reduzirem o espaço ocupado. Por fim, os mecanismos de atribuição de permissões, a encriptação de documentos confidenciais, as assinaturas electrónicas e a gestão da propriedade intelectual são alguns dos tópicos sobre segurança que um sistema documental pode contemplar Workflows em Sistemas de Gestão Documental O termo workflow refere-se à automação computorizada de um processo de negócio, parcial ou total, onde documentos, informação e tarefas são trocados entre participantes de acordo com um conjunto de regras definidas, no sentido de atingir ou contribuir para um determinado objectivo de negócio [5]. Normalmente, associado a este termo está o conceito de reengenharia de processos, que aborda as fases de avaliação, análise, modelação, definição e implementação operacional dos processos de negócio de uma organização [5]. Os sistemas de gestão de workflow oferecem mecanismos concretos e apropriados no suporte destas fases. Segundo a WfMC, a estrutura genérica de um produto desta classe é a seguinte: 17
26 Fig Estrutura genérica de um produto de workflow [5] As ferramentas de definição são usadas na fase de modelação dos processos. Neste momento, os processos de negócio são traduzidos do contexto real para uma definição formal e possível de ser processada. Nesta definição figuram as actividades, a classificação dos respectivos recursos humanos e tecnológicos atribuídos e regras que governam a progressão do processo. A definição é expressa textualmente, graficamente ou através de linguagens formais de notação. A classificação dos recursos humanos serve para especificar quem pode executar uma determinada tarefa. A existência de várias pessoas disponíveis para as realizar obriga a decidir. Existem duas formas de resolução [11]: o sistema executa a decisão e atribui a cada tarefa um utilizador específico (abordagem push control). A escolha é baseada em estatísticas, cargas de trabalho e outras heurísticas. No segundo caso, o sistema envia uma cópia da tarefa a todos os utilizadores com responsabilidade para a resolver (abordagem pull control). Quando alguém selecciona a tarefa, as restantes cópias desaparecem. Esta abordagem é a preferida em grande parte das situações, por ser a mais flexível e por não transmitir tanto a sensação de controlo abusivo do sistema sobre as pessoas. 18
27 Os motores de workflow interpretam as definições de processos e são responsáveis pela criação e controlo das suas instâncias operacionais, agendando cada actividade e invocando os recursos apropriados. Estes componentes actuam como ponte entre a lógica de negócio e o suporte operacional tecnológico e humano. As interacções com as aplicações cliente, que apresentam as listas de tarefas atribuídas aos utilizadores, ou as invocações aos serviços das aplicações permitem a transferência de controlo entre actividades. Ainda em tempo de execução, as ferramentas de administração são usadas para visualizar o progresso dos processos, detectar pontos que influenciem o seu desempenho e lidar com casos excepcionais que condicionem o seu normal fluxo, redistribuindo manualmente, por exemplo, tarefas por novas pessoas. Fig Distribuição num motor de workflow orientado à tarefa [5]. Ao longo do tempo, inúmeras linguagens surgiram com o objectivo de modelar e executar workflows. O BPMN é um dos standards actuais na especificação de processos de negócio [20], fornecendo uma notação gráfica de fluxos similar aos diagramas de actividade do UML. O objectivo desta notação passa sobretudo por alcançar uma linguagem compreendida tanto por utilizadores mais técnicos como de negócio, mantendo a capacidade de representar semânticas complexas tipicamente existentes nos processos das empresas. De certa forma, o BPMN serve como ponte de comunicação entre a concepção de processos e a sua implementação. No entanto, como linguagem meramente gráfica, não pode ser directamente interpretada por aplicações. O xpdl, notação baseada em schemas XML, aparece com o intuito de solucionar esta questão e, fundamentalmente, de normalizar a definição e a troca destes diagramas entre diferentes produtos de workflow [21]. Apesar de suportar a especificação de informação de execução, como temporizadores ou chamadas a Web Services, este formato orienta-se principalmente na declaração dos aspectos e conceitos gráficos de um esquema BPMN. 19
28 Outra linguagem de modelação de relevo são as Petri Nets. Referidas como uma representação matemática para descrever sistemas distribuídos, baseada em grafos constituídos por nós de posição, nós de transição e arcos direccionados, as Petri Nets são igualmente consideradas na área do BPM porque suportam vários dos conceitos necessários a um processo, como a escolha, a iteração ou a concorrência [11]. Por outro lado, como linguagens exclusivamente de execução, pode-se dar como principal exemplo o BPEL. Este standard da OASIS caracteriza-se como uma linguagem de orquestração que define a troca de mensagens entre sistemas, adoptando os Web Services como mecanismo central de comunicação [22]. Os tipos de workflows até agora apresentados focam-se, fundamentalmente, nas actividades ou tarefas de um processo. No entanto, apesar de não ser concretamente coberto pela WfMC, existem sistemas que implementam workflows orientados ao conteúdo. Nestes casos, cada passo do workflow altera o estado do objecto informacional associado. Na verdade, sem objecto não se pode definir um workflow deste género. Apesar de mais restritivos, por não descreverem processos sem um conteúdo como entidade central, este tipo de workflows pode ser considerado na gestão documental, onde os processos são representados por fluxos de documentos. Fig. 2.4 Ilustração de um workflow orientado ao conteúdo. Na figura 2.4 exemplifica-se um processo de aprovação documental assente num workflow orientado ao conteúdo. O documento circula entre o seu autor, um revisor e um editor. Cada transição altera o estado do documento. 20
29 2.2 Análise de Sistemas Documentais Durante o trabalho de investigação foram analisados diversos sistemas, incluindo alguns da área do BPM, como o Intalio [23] e o jbpm [24]. No entanto, este capítulo descreve as seguintes ferramentas, focadas sobretudo no contexto documental: WebC-Docs O WebC-Docs é um sistema de gestão documental implementado como um toolkit sobre a plataforma WebComfort. Os conceitos fundamentais deste sistema estão sintetizados na seguinte figura: Fig Conceitos principais do WebC-Docs [10]. O conceito de documento guarda ficheiros, normalmente associados a conteúdos criados nas aplicações de escritório ou a digitalizações. Cada documento está contido numa pasta. De modo a serem acedidos por mais do que uma pasta, criam-se atalhos, meros ponteiros para documentos. A especificação das acções que cada papel do WebComfort pode realizar sobre estes conceitos é feita através da atribuição de permissões. Fundamentada nestas entidades, a interface principal é similar a um explorador de ficheiros típico, apresentando no lado esquerdo a hierarquia de pastas, no lado direito a lista dos documentos da pasta seleccionada. A simplicidade de utilização é um ponto favorável desta aplicação. 21
30 Outra das vantagens deste sistema é a sua integração com um CMS. Vários conceitos, como o de utilizador, de papel e de permissão são oferecidos pela plataforma e não precisam de ser redefinidos. Além disto, apesar de implementado sobre o WebComfort, não utiliza conceitos exclusivos dele, logo facilmente pode ser migrado para qualquer outra plataforma CMS, desde que forneça um suporte adequado ao desenvolvimento de aplicações Web. Associados aos documentos e pastas, o WebComfort permite especificar metadados. Este mecanismo assenta na definição de tipos de atributos, baseados em tipos primitivos (e.g. inteiros, datas, strings, enumerados), posteriormente agrupados em conjuntos. A associação de atributos é feita de forma dinâmica, através da aplicação destes conjuntos. A qualquer momento, em tempo de execução e a partir da criação de um documento, pode-se adicionar-lhe novos conjuntos de atributos. Os atributos são preenchidos com valores fornecidos pelos utilizadores e são indexados pelo motor de pesquisa. O módulo de procura permite localizar documentos através da submissão de alguma informação sobre eles e dispõem de dois tipos de pesquisa: a regular, idêntica a qualquer outro motor do género, e a avançada, que admite a introdução de filtros para reduzir o número de resultados falso positivos. Além dos atributos, também o conteúdo dos ficheiros dos documentos é indexado, caso o respectivo formato seja suportado. Os documentos são guardados num servidor local, sobre um sistema de ficheiros. Já os metadados são armazenados numa base de dados [10]. No entanto, o WebC-Docs está igualmente preparado para interagir com repositórios externos. Todas as interacções são mediadas através de classes intermediárias, escondendo possíveis falhas temporárias dos servidores. Como funcionalidades de relevo, destacam-se ainda os mecanismos de auditoria e de gestão de versões. Qualquer acção executada é gravada pelo Webcomfort e, se for sobre um documento, é igualmente registada pelo WebC-Docs. O histórico de registo não é modificável e pode ser lido nos detalhes do documento por qualquer pessoa com as permissões necessárias. Por outro lado, o mecanismo de versões permite reverter um documento até um estado passado, nunca se perdendo versões antigas. Uma das faltas mais notórias deste sistema é a ausência de mecanismos de workflow. A gestão centra-se unicamente nos documentos e nas pastas, não suportando os processos associados à circulação dos conteúdos entre as pessoas. A produção e edição desses conteúdos também não é suportada, nem mesmo através de integrações com ferramentas de escritório, sendo apenas possível alterar os atributos ou mudar o ficheiro associado ao documento. Ainda sobre esta questão, verifica-se que a edição simultânea não é controlada. Se dois utilizadores alteram os atributos ou o ficheiro de um dado 22
31 documento, nenhum deles sabe que o faz em concorrência. No final são incrementadas duas novas versões ordenadas segundo a rapidez de cada utilizador, podendo não ser este o resultado que se esperaria. Por fim, a ausência de uma interface baseada em Web Services impede outros sistemas de interagir com o WebC-Docs sem a sua interface Web [10] Knowledge Tree O Knowledge Tree é um sistema de gestão documental desenvolvido em PHP, open source, disponível em versões comerciais ou através de licenças sem custo [25]. Ao contrário de outros sistemas, a solução deste produto baseia-se num cliente de janela combinado com uma aplicação Web, oferecendo vantagens ao nível da interface e permitindo operações de arrasto entre os documentos das máquinas locais e os repositórios remotos. Esta abordagem suporta igualmente a integração com as ferramentas Microsoft Office, permitindo a captura imediata de um documento elaborado no Word, algo que não é possibilitado pelo WebC-Docs. Além destes formatos, esta aplicação indexa muitos outros, como o de PDF, XML, HTML, RTF e de texto, alguns já fora dos formatos tradicionais no tema documental. Os conceitos internos do Knowledge Tree são idênticos aos do WebC-Docs, nomeadamente os de documento e de pasta. A adopção desta metáfora por outros produtos reforça a sua validade nesta classe de sistemas. No Knowledge Tree, os documentos podem estar relacionados com outros documentos, possibilitando a existência de anexos. Além disto, também podem estar associados a fóruns, fomentando a discussão e a valorização dos conteúdos. O WebC-Docs não fornece esta funcionalidade. No entanto, a vantagem de estar implementada sobre o WebComfort facilita a integração dessa função, normalmente existente num CMS. O mecanismo de tratamento dos metadados é poderoso e permite a definição de atributos de vários tipos, igualmente indexados pelo motor de pesquisa. Outro conceito interessante modelado neste sistema é o de document type. A utilização deste mecanismo obriga a normalizar e estruturar antecipadamente os documentos, procedimento necessário para se retirar maior proveito das potencialidades da informação. De certa maneira, o WebC- Docs também implementa indirectamente este conceito, através da aplicação de conjuntos de atributos a pastas. Além dos meta-dados, o Knowledge Tree suporta tags e tag clouds. O WebC-Docs também refere o conceito. Porém, modela-o mais como categorias hierarquizadas, previamente definidas no módulo de configuração dos metadados, onde são especificados os tipos de atributos e os conjuntos de atributos. Os 23
32 documentos só podem ser classificados pelo utilizador através destas categorias prédefinidas. A edição simultânea de documentos é suportada por mecanismos de check in/check out. Antes da actualização de um documento, o utilizador pode reservá-lo, impedindo que outros lhe escrevam durante a edição. Por fim, o Knowledge Tree permite também definir workflows orientados ao conteúdo. O sistema suporta a definição e execução do ciclo de vida de um documento através de quatro conceitos principais: State, Transition, Action e Trigger. Um workflow tem diversos estados, um inicial e pelo menos outro final. Cada estado pode ter várias transições para outros estados, desencadeadas por Triggers definidos por condições. Nos estados, tanto à entrada como à saída, podem ser definidas acções a ser executadas. Grande parte desta solução é baseada nas máquinas de estados UML, que servirão de base à solução apresentada no próximo capítulo. Por fim, os workflows podem ser automaticamente associados a documentos quando criados numa determinada pasta ou segundo o seu document type Alfresco O Alfresco é um ECMS, desenvolvido sobre a plataforma Java, e oferece serviços nas áreas da gestão documental, conteúdos Web, RM e colaboração [26]. Na área que mais interessa a este trabalho, a solução dispõem de muitas das funcionalidades até aqui mencionadas: gestão de versões e mecanismos de check in/check out como garantia da consistência dos documentos; integração com o Microsoft Office; procura de conteúdos através de metadados e tags indexados; conversão de formatos, entre outros. No entanto, uma das características que torna esta solução mais global é a interoperabilidade, ou seja, a capacidade de interagir com outros sistemas. O Alfresco suporta múltiplos protocolos para acesso dos conteúdos geridos pelo seu repositório, incluindo o FTP, WebDAV e o CIFS (Common Internet File System). Todos estes protocolos expõem o modelo de pastas e ficheiros, igualmente mapeado neste sistema. O FTP e o WebDAV são bastante conhecidos mas é a implementação do CIFS que mais relevo tem. Este protocolo transforma o repositório do Alfresco num sistema de ficheiros standard, possibilitando a interacção com qualquer ferramenta com serviços de leitura e escrita de ficheiros. Por exemplo, no Windows, é simples e possível montar o repositório como um disco partilhado, sem qualquer aplicação cliente pelo meio. Todas as propriedades e opções típicas de ficheiros estão disponíveis pelo CIFS, como a data, a hora, o título, o autor, os comentários, etc. e são visíveis no Explorer e capturadas automaticamente pelo Alfresco. O sistema de autenticação entre o CIFS e o Internet 24
33 Explorer pode ser partilhado e, além disto, o trabalho offline é suportado, através de mecanismos de sincronização da Microsoft (Offline Synchronization e Microsoft Briefcase). Além destes protocolos, o Alfresco apresenta três APIs de serviços bem definidas e resumida na seguinte ilustração: Fig. 2.6 APIs do Alfresco A camada inferior de serviços, o Repository Foundation Services, é um conjunto de interfaces Java que cobre todas as funcionalidades necessárias aos clientes que pretendam embeber o repositório do Alfresco nas suas aplicações. Sobre esta camada, definem-se duas APIs: os Web Services permitem o acesso remoto de sistemas externos, não só implementados sobre Java. Os princípios SOA são também reconhecidos e suportados pelo Alfresco, através do BPEL, como uma forma de integração entre sistemas empresariais. Por fim, a API JCR permite o acesso normalizado a repositórios de conteúdos, sobre RMI, entre clientes Java DSpace O DSpace é uma solução para aceder, gerir, preservar e partilhar conteúdos essencialmente académicos [27]. O sistema foi desenhado no sentido de respeitar standards da área. Por exemplo, os schemas de metadados associados aos diferentes tipos de conteúdos estão definidos segundo a convenção da Dublin Core [28], com o intuito de tornar a procura de informação mais eficaz. Os conteúdos são guardados segundo uma hierarquia em árvore fixa, definida por comunidades, colecções, itens e ficheiros. A comunidade é o contentor de maior nível e pode representar departamentos, laboratórios, centros de pesquisa, escolas, etc. Uma 25
34 comunidade tem colecções que organiza itens relacionados. Estes últimos guardam ficheiros e descrições, definidas pelos metadados. A imposição de uma estrutura rígida como esta pode limitar a aplicação do DSpace a casos mais genéricos, não académicos. Em relação aos sistemas anteriores, o aspecto do DSpace que talvez tenha mais destaque é a forma como arquiva e preserva os documentos. Para esta finalidade, a aplicação guarda o binário do ficheiro, visto que os bits do documento serão sempre os mesmos, ou, de forma contínua, adapta os conteúdos aos novos formatos que vão surgindo ao longo do tempo. Por outro lado, a cada recurso guardado é atribuído um identificador único, válido por muito tempo e gerido formalmente através do sistema Handle [28]. 2.3 Comparação de Sistemas Documentais As tabelas seguintes comparam directamente os sistemas descritos previamente, segundo os principais tópicos do modelo de referência: Tabela 1 Análise da forma como cada sistema define um documento. Conceito de documento WebC-Docs Knowledge Tree Alfresco D-Space Documento representado por um ficheiro e atributos dinâmicos; Vista pasta-documento. Documento representado por um ficheiro e atributos dinâmicos; Vista pasta-documento; Document type. Documento representado por um ficheiro e atributos dinâmicos; Vista pasta-documento; Document type. Baseado na estrutura comunidades, colecções, itens e ficheiros. O conceito de documento é praticamente idêntico entre todos os sistemas. Tanto o WebC- Docs, como o Knowledge Tree e o Alfresco consideram um documento como um ficheiro associado a um conjunto de metadados, disponibilizado dentro do contexto das pastas. Os atributos podem ser definidos de forma flexível, ao contrário do DSpace, que direcciona-se na aplicação de schemas normalizados e pré-definidos. Tabela 2 Análise das funcionalidades de suporte às tarefas comuns de gestão documental. Suporte às tarefas de gestão documental WebC-Docs Knowledge Tree Alfresco D-Space Mecanismos de digitalização não sim sim não Aplicação de metadados sim sim sim sim Atribuição de tags não sim sim não Registo de histórico de acessos sim sim sim sim 26
35 Gestão de versões sim sim sim sim Check in/check out não sim sim sim Mecanismos de transformação não sim sim sim Pesquisa sim sim sim sim Definição de permissões sim sim sim não Os mecanismos de digitalização do Alfresco e Knowledge Tree são adquiridos como componentes separados das aplicações documentais. De notar apenas que mais uma vez, o DSpace disponibiliza um conjunto de papéis e permissões normalizados e focados no ambiente académico, ao contrário dos restantes sistemas, cuja definição personalizada garante maior flexibilidade. Tabela 3 Análise de outros aspectos. Outros aspectos WebC-Docs Knowledge Tree Alfresco D-Space Web-based sim sim sim sim Definição de Papeis sim sim sim não Interoperabilidade (APIs de acesso) Integração com ferramentas de escritório não sim sim sim não sim sim não Todos os sistemas são web-based. Além disso, tanto o Knowledge Tree como o Alfresco oferecem um vasto conjunto de API s para integração com outras aplicações, além de possibilitarem a captura directa de documentos produzidos nas ferramentas de escritório. Tabela 4 Suporte aos componentes de workflow. WebC-Docs Knowledge Tree Alfresco D-Space Definição de tipos de workflow não sim (baseado numa máquina estados) sim (jpdl, derivado do xpdl) não Workflow Monitorização e controlo não sim sim não Execução e Participação em workflows não sim sim não (processos de submissão e aprovação built-in) Apenas o Alfresco e o Knowledge Tree permitem definir workflows. O primeiro pode ser integrado com o módulo BPM, cuja linguagem de definição deriva do xpdl, e centra-se nos workflows orientados à tarefa. Já a notação do Knowledge Tree baseia-se nas máquinas de estado UML e foca-se na definição de fluxos orientados ao documento. 27
37 3 WebC-Docs/Wf Aspectos de Concepção Este capítulo apresenta uma proposta de extensão do WebC-Docs, centrada na construção de um sistema de gestão de workflows enquadrado nos problemas de gestão documental. De seguida, introduz-se alguns cenários de utilização que motivam a concepção de um sistema deste género. A segunda secção apresenta os principais conceitos do WebC-Docs/Wf e, no final do capítulo, são descritos os actores e casos de uso. 3.1 Cenários de Utilização Muitos dos processos de negócio de uma empresa baseiam-se em fluxos documentais com diversos intervenientes. As notificações, os encaminhamentos, as aprovações e revisões são alguns exemplos deste tipo de processos. De seguida, apresentam-se três cenários concretos de fluxos documentais, que esclarecem e motivam a necessidade de utilizar um sistema como o WebC-Docs/Wf. Os casos descritos servirão também de validação ao projecto Revisão e aprovação de artigos Numa das cadeiras do curso de informática, os alunos devem escrever e submeter artigos sobre diversos temas. Como muitos dos artigos são depois apresentados em conferências, é fundamental que sejam revistos e aprovados com todo o cuidado. Assim, sempre que um aluno submete um artigo no sistema documental da cadeira, o documento deve passar por um processo de revisão bem definido. Após a submissão de um artigo, o documento é encaminhado para os dois professores das aulas práticas. Cada professor pode aprovar o artigo ou pedir a correcção de alguns aspectos. Sempre que um dos professores execute o segundo despacho, o documento é imediatamente remetido para o autor, que deve enviar novamente o artigo para apreciação, quando os erros e aspectos indicados no despacho de correcção estiverem resolvidos. Quando os professores estão de acordo e todos aprovam o artigo, o documento é encaminhado para o responsável da cadeira. Ao responsável cabe-lhe a decisão final de aceitar o artigo para ser apresentado na próxima conferência, ou, pelo contrário, de o rejeitar. 29
38 3.1.2 Registo e notificação de correspondência Na empresa XPTO chega, todos os dias, grandes quantidades de correspondência. A sua recepção é tratada por um administrativo que tem, como primeira função, registar o documento recebido. Este registo passa por preencher um formulário onde se submete o número de entrada, a data, o emissor, o tipo (carta, fax, etc.), algumas observações e a digitalização do documento em concreto. O número de entrada e o ficheiro são campos obrigatórios. Após o registo, o administrativo deve encaminhar a correspondência para as pessoas ou departamentos apropriados, de acordo com o tipo da correspondência, notificando-os respectivamente. O processo termina quando todos os notificados indicam que tomaram conhecimento do documento Pedido de Compras Outros dos processos importantes na empresa XPTO é o processo de compras. O bom funcionamento dos diversos departamentos depende, em parte, das compras internas de serviços e materiais. O departamento SI, por exemplo, adquire servidores, computadores e licenças de software de forma a suportar as necessidades informáticas da empresa. O processo de compras inicia-se com a identificação de uma necessidade. Quando tal acontece, um engenheiro do departamento deve submeter, através do sistema documental, um pedido onde clarifica o que deve ser comprado, a sua justificação e o montante aproximado do valor do que requisita. A informação é encaminhada para o chefe que pode aprovar, rejeitar, pedir esclarecimentos adicionais ou propor o pedido à aprovação superior, caso não possua competência de aprovar directamente, face ao valor expectável do equipamento. Quando um pedido é aprovado num determinado departamento segue para a secção de compras. Nesta secção, o administrativo tem a responsabilidade de identificar alguns fornecedores, contacta-los e anexar as diferentes propostas de cada um. De seguida, a análise e escolha das propostas é feita pelo engenheiro, de forma a considerar as diferentes questões técnicas e os preços finais. Depois de escolhida e justificada a proposta, a compra segue para adjudicação final, passando primeiro pelo chefe e depois, caso necessário, pelo responsável do departamento. Adjudicado um pedido, a secção de compras deve formalizar a aquisição com o fornecedor escolhido e, na entrega do equipamento, anexar a factura. 30
39 3.2 Conceitos e Modelo de Domínio Como foi referido na introdução, a gestão dos documentos nas empresas pode afectar consideravelmente a produtividade dos trabalhadores. Um dos maiores factores de custo nesta área é a circulação constante dos documentos, associados à sua revisão, aprovação e encaminhamento, processos cujas actividades estão focadas unicamente nos conteúdos. No entanto, o WebC-Docs não possui qualquer suporte a este tipo de processos. Neste sentido, desde logo se considerou a concepção do WebC-Docs/Wf, capaz de definir, executar e controlar os fluxos típicos de documentos nas organizações. A primeira decisão a tomar na concepção deste sistema foi a escolha entre a especificação de workflows orientados à actividade ou ao conteúdo. O primeiro executa a sequência de actividades de um processo de negócio. Em cada actividade define-se quem é o seu responsável, que sistemas devem ser evocados e que entidades informacionais são acedidas. O segundo tipo baseia-se numa máquina de estados segundo as fases que um documento atravessa no processo. Em cada fase, o documento é atribuído a alguém, responsável por realizar acções sobre a informação. No geral, a circulação dos documentos pode ser suportada pelos dois tipos. No entanto, a primeira abordagem enquadra-se sobretudo nos sistemas BPM, onde a integração e orquestração dos serviços entre as várias aplicações empresariais (incluindo as de gestão documental) é um requisito presente. A adopção de iniciativas tão ambiciosas pelas empresas envolve maior risco, sobretudo pelos custos e factores de mudança organizacionais [1]. Por outro lado, a implementação de mecanismos de workflow orientados ao conteúdo enquadra-se melhor com a problemática documental, porque foca-se exclusivamente nos participantes que devem ser evocados e na entidade informacional que deve ser gerida pelo sistema. Trata-se de uma abordagem menos complexa e igualmente eficaz no suporte à circulação dos documentos. A solução que se apresenta de seguida recai sobre os workflows orientados ao conteúdo e centra-se no suporte à sua definição e execução Pacotes de domínio Para melhor compreender o modelo de domínio deste projecto, os conceitos foram divididos em três pacotes, apresentados no seguinte diagrama: 31
40 Fig Dependências entre os pacotes de domínio. Pacote de Definição É o pacote onde figuram os conceitos que permitem criar definições de workflow e formulários; Pacote de Execução Os conceitos aqui presentes suportam a criação e execução de instâncias de workflow, com base numa definição de workflow; Pacote WebC-Docs Este pacote é usado ao longo da documentação do modelo de domínio, para agrupar as entidades oferecidas pelo WebC-Docs e o WebComfort, necessárias aos dois pacotes anteriores Vista Geral Os conceitos e relações fundamentais do WebC-Docs/Wf são introduzidos na seguinte figura: 32
41 Fig Visão geral da arquitectura do WebC-Docs/Wf, segundo os conceitos e relações principais A definição de workflows no WebC-Docs/Wf é suportada pelo conceito Workflow Definition. A definição de um workflow implica a definição de States e Transitions. Cada estado pode ter, tanto à entrada como à saída, um conjunto de Actions associadas, executadas depois em tempo de execução. Como exemplo, estas acções podem ser envios automáticos de s, notificações, mudanças de documentos entre pastas, etc. A definição de Conditions é outra etapa fundamental na definição de workflows. Além de acções, um estado pode ter várias transições de entrada e saída. Cada transição de saída só é desencadeada pela satisfação de uma das condições associada. De referir que os conceitos até agora mencionados baseiam-se sobretudo no modelo de máquina de estados UML [12] e nos mecanismos de workflow usados no Knowledge Tree. Quando uma definição de workflow está em condições de ser instanciada, pode-se executar instâncias de workflow. A execução de um workflow guarda o estado actual e está associado a uma entidade informacional. Esta entidade, tendo o objectivo de ser a 33
42 mais genérica possível, define-se unicamente como um conjunto de atributos, ou seja, de Fields. Estes atributos podem ser de diferentes tipos, desde inteiros e texto, até ficheiros Definição de Workflows Compreendidos os principais elementos e respectivas relações, é importante detalhar os conceitos que completam a definição de um workflow. A seguinte vista introduz a noção de Choice, Participation Rule e Form, e explica, em concreto, como se constitui uma Condition: Fig. 3.3 Vista da definição de workflows. Em primeiro, a definição de um estado implica a determinação do seu tipo. Um estado pode ser inicial, final ou intermédio. O estado inicial é o estado de criação do objecto informacional central ao workflow. Os estados finais determinam o fim do fluxo e, como tal, não devem possuir transições de saída. Além do tipo, a definição de um estado contempla a definição dos despachos que um participante pode executar nessa etapa. Assim, um estado não final deve ter pelo menos 34
43 uma Choice. Uma escolha reflecte a decisão de encaminhamento que um participante pretende dar ao workflow. Associado a um estado pode também estar um formulário. O objectivo dos formulários é processar informação, criando ou actualizando atributos da entidade informacional subjacente. O formulário é preenchido pelos participantes associados ao estado em questão. Como referido, no contexto dos estados são também definidas condições. Cada transição de saída deve estar associada a pelo menos uma condição. A transição é executada quando uma das condições associadas está satisfeita. No seguimento deste raciocínio, uma condição está satisfeita quando todas as suas regras estão igualmente satisfeitas. Estas regras podem ser vistas de forma abstracta, no sentido de contemplar todo o tipo de lógica que se pretenda. No entanto, de forma a identificar os participantes de um estado e de definir execuções de transições segundo combinações dos seus despachos, foi necessário concretizar as regras de participação. Como mostra a figura 3.4, uma regra deste tipo refere uma das escolhas do estado, um papel e o número de despachos, sobre a escolha referida, que têm de ser executados por indivíduos com o tal papel, de forma a tornar a regra válida. Fig. 3.4 Vista da definição de uma regra de participação. Esta solução revela-se muito flexível porque permite a definição de múltiplas situações. Cada condição, através da conjunção de várias regras de participação, pode definir um conjunto imenso de combinações, baseadas em diferentes despachos de quantos indivíduos se queira, concorrentemente e de diferentes papéis. Por outro lado, a disjunção 35
44 é também suportada. Considerando as várias condições possivelmente associadas a uma transição, apenas uma tem de estar satisfeita para desencadeá-la, e assim executar a mudança de estado pretendida no workflow. Por fim, é importante verificar que o desencadear imediato de uma transição pode não ser o pretendido. Apesar de uma condição estar satisfeita, podem não ter participando ainda todos os intervenientes referenciados por todas as condições e respectivas regras de participação do estado. Assim, e caso seja somente necessário, podem-se definir précondições. Como explicitado na figura seguinte, uma pré-condição indica quantos despachos de indivíduos com um determinado papel devem já ter sido executados, garantindo um número mínimo de participações, antes de se verificar a validade das condições. Fig. 3.5 Vista da definição de uma pré-condição. Após a validação das pré-condições pode ocorrer que várias condições se apresentem imediatamente satisfeitas. Dada esta possibilidade, as condições devem ser definidas segundo uma ordenação, desencadeando-se a transição associada à primeira condição satisfeita Execução de Workflows Concluída a notação de definição é necessário compreender como são executados os workflows e como estão integrados com o WebC-Docs. Assim, cada instância de workflow está sempre associada a uma entidade informacional, constituída por atributos. Os atributos são criados, preenchidos e actualizados através dos formulários criados em tempo de definição e apresentados ao longo da passagem dos estados. 36
45 Durante a execução de um workflow é guardado o histórico dos estados anteriores, mantendo-se sempre uma referência para o actual. Juntamente com estes registos guardam-se os despachos (conceito de Vote) efectuados pelos participantes individualmente, com os comentários e justificações da decisão tomada. O workflow transita quando os votos actuais satisfazem uma das condições especificadas no estado, na definição de workflow. Fig. 3.6 Vista da execução de workflows. Um dos desafios presentes durante a concepção do WebC-Docs/Wf foi a integração com os conceitos já existentes do WebC-Docs, nomeadamente com as entidades pasta e documento. As figuras 3.7 e 3.8 clarificam este aspecto. Uma das limitações dos documentos no WebC-Docs é a sua associação a, no máximo, um ficheiro. A entidade informacional surgiu, em parte, com o objectivo de resolver esta questão. Definindo-se unicamente como um conjunto de atributos, e tratando um ficheiro simplesmente como mais um tipo de informação, as entidades informacionais podem assim endereçar diversos ficheiros no contexto de todo um workflow. Respeitando a arquitectura de base, a forma mais elegante de implementar esta entidade foi associar-lhe 37
46 uma pasta. Assim, todos os Fields do tipo ficheiro são geridos como documentos do WebC-Docs, mantidos na pasta da entidade informacional respectiva. Por outro lado, numa perspectiva mais colaborativa, seria também interessante aplicar workflows directamente a documentos do WebC-Docs. Deste modo, cada pasta pode estar associada a várias definições de workflow. Por omissão, uma delas é instanciada quando um documento é criado dentro da pasta. No entanto, caso o utilizador tenha permissões, pode escolher que workflow dos possíveis pretende atribuir ao documento em criação. Fig. 3.7 Integração da entidade informacional com o WebC-Docs. Fig. 3.8 Aplicação de workflows directamente a documentos do WebC-Docs. 38
47 3.2.5 Formulários Uma das funcionalidades mais poderosas deste novo sistema é a possibilidade de criar formulários, de uma forma personalizada e ajustada às necessidades de processamento de informação de um workflow documental. Este mecanismo baseia-se nas noções de Form, Form Type e Form Definition, ilustradas na seguinte figura: Fig. 3.9 Vista de definição das Forms e de instanciação dos Fields. Uma Form consiste num grupo de Field Types. Um Field Type é responsável por definir um tipo de dados (ex: inteiros, datas, strings, enumerados, ficheiros, etc.). A associação entre uma Form e um Field Type é chamada de Form Definition. Esta definição permite configurar a aplicação de um Field Type a uma Form, através da atribuição de um nome e de outras opções, como a obrigatoriedade do preenchimento de um campo. 39
48 Os formulários são associados a definições de estados, de forma a serem preenchidos nessa etapa do workflow. Os Fields ficam atribuídos a entidades informacionais e, à excepção dos que derivam do tipo ficheiro, guardam directamente o valor submetido. 3.3 Actores e Casos de Uso O objectivo desta secção é compreender quem e como será usado o WebC-Docs/Wf. Assim, identificam-se os actores e os casos de uso principais deste sistema de gestão de workflows: Actores Uma das primeiras tarefas deste trabalho consistiu na identificação dos actores e respectiva hierarquia, esquematizada no seguinte diagrama: Fig Actores do WebC-Docs/Wf. User Este actor representa todos os utilizadores autenticados no sistema. Workflow Designer Utilizador responsável por modelar os processos documentais da organização e, assim, criar as respectivas definições de workflow. Deve compreender os conceitos e relações de definição do WebC-Docs/Wf. 40
49 Workflow Participant Interveniente no despacho de instâncias de workflow. Está associado a papéis, de acordo com a responsabilidade e função na organização que integra. Workflow Manager Responsável por controlar e configurar aspectos de execução de workflows Casos de Uso Vários casos de uso foram identificados neste trabalho. De forma a melhor compreendelos, apresentam-se três diagramas separados segundo as etapas de definição, configuração, controlo e execução: Fig Casos de uso na fase de definição. Create Workflow Definitions Os designers podem criar definições de workflow. Esta definição inclui a especificação dos intervenientes, despachos e condições de transição do fluxo documental, bem como a associação de formulários para processamento de informação. Como suporte à definição, o sistema deve garantir uma validação mínima das especificações criadas. Define Forms Os designers podem criar formulários. Os formulários devem ser definidos de forma flexível, como um conjunto de campos de diferentes tipos de informação, incluindo ficheiros. 41
50 Fig Casos de uso na fase de execução. Start a Workflow Um utilizador pode iniciar workflows, quando participante nos estados iniciais. Dispatch a Workflow Quando notificado num determinado estado, um utilizador deve aceder a mecanismos de despacho. Para encaminhar devidamente o processo, o participante pode consultar o histórico de despachos e respectivos comentários/ justificações, a entidade informacional sobre a qual decide e, ainda, preencher formulários no sentido de lhe criar ou actualizar informação. O despacho pode levar a transições e, naturalmente, a notificações de outros utilizadores, suportadas pelo sistema. Consult Workflows Um participante pode consultar workflows concluídos ou ainda em execução, de forma a verificar o estado de um determinado processo em que participou. 42
51 Fig Casos de uso de configuração. Manage Workflow Executions O gestor pode gerir e controlar execuções de workflow. Esta gestão inclui aspectos como cancelar instâncias, lidar com casos excepcionais e consultar dados estatísticos para suporte de reengenharia de processos e análise de eficiência. Configure Workflow Options O gestor deve activar as definições que pretende ver instanciadas na organização e configurar o seu contexto, ou seja, se o workflow deve ser visualizado e associado directamente a documentos do módulo das pastas ou, por outro lado, se deve ser manipulado no dashboard de notificação e processado através de formulários, onde a entidade informacional subjacente é mais genérica e contém um conjunto de atributos, incluindo ficheiros. 43
53 4 WebC-Docs/Wf Aspectos de Implementação Este capítulo apresenta a arquitectura e implementação do WebC-Docs/Wf. O capítulo está dividido em duas secções. A primeira descreve as principais características do WebComfort, a plataforma de suporte onde já corria o WebC-Docs. A segunda secção apresenta a estrutura do sistema, nomeadamente os componentes e módulos desenvolvidos. 4.1 Plataforma WebComfort e o WebC-Docs O WebC-Docs/Wf, como nova versão do WebC-Docs, foi desenvolvido sobre a plataforma WebComfort O WebComfort é um CMS desenvolvido e suportado pelas tecnologias Microsoft ASP.NET 2.0 (C#) e SQL Server 2005 [8]. Permite fazer a operação e gestão integrada de aplicações Web, disponibilizando ferramentas e mecanismos para gestão de conteúdos através de browsers. Tal como a maioria dos CMS, a plataforma WebComfort apresenta uma independência entre o conteúdo e a sua apresentação e possui como grandes vantagens a extensibilidade, reutilização e modularidade. Uma aplicação WebComfort é constituída por páginas dinâmicas e páginas estáticas. Cada página dinâmica (ou secção) pode ser configurada e editada, sendo que os conteúdos são definidos através de tipos de módulos pré-definidos, tais como, lista de links, lista de anúncios, documentos ou uma imagem [8]. Os módulos são um dos componentes mais importantes desta plataforma, pois contêm a definição do conteúdo e conferem extensibilidade através da definição e adição de novos tipos de módulos. A disposição espacial destes módulos é manipulada numa estrutura flexível de contentores dinâmicos consoante as necessidades específicas da organização ou dos designers [8]. Também é possível definir e gerir temas visuais que estabelecem os aspectos da apresentação gráfica de toda a aplicação, de uma página ou somente de um módulo [8]. Entre outros aspectos, o WebComfort apresenta as seguintes funcionalidades [8]: administração e configuração geral da aplicação Web; gestão integrada de utilizadores; permissões e controlo de acessos; gestão integrada de páginas dinâmicas com múltiplos conteúdos; gestão integrada de conteúdos; suporte e gestão de temas visuais; suporte e gestão de toolkits de módulos; suporte na extensibilidade da plataforma; e suporte multi- 45
54 língua. Os principais componentes do WebComfort estão esquematizados na figura seguinte: Fig. 4.1 Visão geral da arquitectura do WebC-Docs [8]. O WebC-Docs está implementado como um toolkit do WebComfort e, como tal, pode ser instanciado em qualquer instalação deste CMS de forma automática e simples. A figura 4.2 mostra uma visão geral em camadas, da integração do WebC-Docs e de outros toolkits relacionados com a plataforma WebComfort. Um dos aspectos que mais caracteriza a integração do WebC-Docs com a plataforma é a implementação dos pontos de interacção através de módulos do WebComfort [10]. Além disso, o mecanismo de permissões deste sistema documental reutiliza os conceitos de papel e utilizador já presentes na plataforma, em vez de os definir novamente. Como também está explícito na figura, o WebC-Docs/Wf foi construído como uma extensão do WebC-Docs, integrando-se assim com os conceitos do toolkit existente e com os mecanismos da plataforma CMS. 46
55 Fig. 4.2 Visão geral da integração do WebC-Docs com o WebComfort (adaptado de [10]). 4.2 Componentes do WebC-Docs/Wf De forma a implementar a infra-estrutura e as funcionalidades do WebC-Docs/Wf, novos módulos e páginas do WebComfort foram concebidos. Outros foram actualizados, já existentes no WebC-Docs. Com base na vista geral dos componentes apresentada em baixo, verifica-se que os módulos e páginas implementados são suportados por APIs e por componentes lógicos. As APIs abstraem a camada de dados, permitindo um acesso simples, elegante e eficaz às bases de dados. Os componentes lógicos implementam algum do comportamento crítico para o bom funcionamento deste sistema. Além de um motor que executa os workflows, baseado nos despachos em tempo real dos participantes, estes componentes suportam mecanismos de validação de Workflow Definitions e garantem a integração dos novos conceitos do WebC-Docs/Wf com as pastas e documentos do sistema já existente. Cada um dos componentes está descrito com maior detalhe, no seguimento desta secção, organizados segundo as três grandes etapas de interacção com o WebCdocs/Wf: a definição de workflows, a definição de formulários e a execução e participação em workflows. 47
56 Fig. 4.3 Componentes do WebC-Docs/Wf Definição de Workflows A figura seguinte ilustra o módulo e a página desenvolvidos para suportar a definição de workflows: Fig. 4.4 Componentes de definição de workflows. 48
57 Ao nível da apresentação, estes componentes estão estruturados como ilustram as figuras 4.5, 4.6 e 4.7. Fig. 4.5 Módulo de gestão de definições de workflow. O módulo de definição permite criar, editar ou apagar definições de workflow. De notar que além do nome, o módulo apresenta o estado das definições criadas, ou seja, se estão em condições de ser instanciadas ou, se pelo contrário, ainda não satisfazem as regras mínimas de um workflow válido. Estas regras são verificadas pelo componente lógico de validação e serão explicadas mais adiante. Fig. 4.6 Página de criação ou edição de definições de workflow. 49
58 A página de criação ou edição de definições de workflow apresenta duas secções. A primeira, denominada por Info, serve para introduzir alguns dados sobre o workflow, como o seu nome e descrição. Tal como o título indica, a secção States and Transitions suporta a definição destas entidades. As transições são definidas como simples ligações entre um estado de partida e outro de chegada. Já os estados, e todos os conceitos envolvidos, são explorados através dos seguintes ecrãs: Fig. 4.7 Ecrãs de definição dos conceitos presentes no contexto de um estado. Mais uma vez, a definição de um estado apresenta uma secção para submissão de dados informativos. Neste ponto, é de realçar a obrigatoriedade da identificação do tipo que estamos a modelar. Um estado pode ser inicial, intermédio ou final. Esta classificação é 50
59 fundamental para validarmos as transições de saída e de entrada que são depois definidas. Por outro lado, um estado final não pode ter formulários, despachos ou participantes associados. Um estado final determina unicamente a conclusão de um workflow. Quanto aos restantes conceitos, a definição de um estado engloba: a definição de Choices, que modelam o tipo de despachos que se apresentarão como opção de encaminhamento; a definição de Participation Rules, segundo o explicado no capítulo anterior, referindo as Choices já determinadas; a definição de Conditions, aglomerados de regras de participação, associadas às transições de saída; e, por fim, a associação de formulários. De notar, por último, que a edição de um estado não é feita numa página separada da edição de uma definição de workflow. Esta decisão justifica-se com a importância de não perder o contexto de toda a definição actual, permitindo que o utilizador assimile e compreenda melhor todas as fases do processo Definição de Formulários A figura seguinte demonstra o módulo e as páginas desenvolvidas para suportar a definição de formulários: Fig Componentes de definição de formulários. O módulo de definição de formulários permite definir Forms e Field Types. Esta separação resulta no facto de se poder reutilizar um Field Type em várias Forms. Relativamente ao nível da apresentação, estes componentes estão estruturados como ilustram as próximas figuras: 51
60 Fig. 4.9 Aspecto do módulo e páginas de definição de formulários. O módulo Define Forms apresenta as Forms e os Field Types criados. Os Field Types, como se pode ver na respectiva página de edição, são definidos através de tipos de dados que o sistema disponibiliza. A criação/edição de formulários é feita através de referências para os Field Types primeiramente criados, juntamente com a indicação do nome dos campo e da sua obrigatoriedade Execução e Participação em Workflows A figura seguinte demonstra os módulos e as páginas desenvolvidas para suportar as funcionalidades de execução dos workflows definidos: 52
61 Fig Componentes de execução de workflows. O módulo Configure Document Management já existia no WebC-Docs e foi actualizado com uma nova entrada para configuração de opções de workflow. Para já, cada definição de workflow válida pode ser activa e, caso se pretenda, instanciada unicamente no contexto das pastas e documentos do módulo Manage Documents. Fig Módulo de configuração documental. Para o caso dos workflows ficarem configurados ao contexto estrito das pastas e documentos, foi necessário actualizar outras páginas já existentes. A próxima figura mostra as páginas Edit Folder e Edit Document. Além de suportar a edição dos aspectos antigos de uma pasta, a primeira página permite associar-lhe várias definições de workflow e seleccionar uma como principal. Desta forma, qualquer documento criado na pasta configurada fica imediatamente associado a uma nova instância do workflow escolhido. 53
62 A página Edit Document suporta a criação e edição de documentos. Se o documento está associado a um processo, o utilizador pode executar despachos pela tab Workflow, caso seja participante do estado actual e ainda não tenha executado qualquer encaminhamento. Fig Páginas de edição de pastas e documentos. Por outro lado, os workflows podem ser configurados no sentido de executarem e notificarem através do módulo User Worklist, abstraindo as pastas e documentos do WebC-Docs. O módulo de notificação Document Dashboard apresenta os workflows antigos e os que devem ser despachados naquele momento pelo utilizador autenticado. De notar que a abordagem seguida é a de pull control, ou seja, todos os utilizadores com o papel associado ao estado actual são notificados. A partir do momento em que os despachos efectuados são suficientes para validar uma condição e, consequentemente, transitar o workflow, as notificações antigas desaparecem, dando lugar a novas, de acordo com os papéis do novo estado. 54