Descoberta de Processos em Tempo Real

Tamanho: px
Começar a partir da página:

Download "Descoberta de Processos em Tempo Real"

Transcrição

1 Descoberta de Processos em Tempo Real João Jaime Redondo de Oliveira Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Presidente: Orientador: Vogais: Júri Prof. Doutor José Delgado Prof. Doutor Diogo R. Ferreira Prof. Doutor Artur Caetano Julho de 2011

2

3 Agradecimentos Agradeço ao Professor Doutor Diogo R. Ferreira, na excelência com que me acompanhou na orientação, disponibilidade demonstrada, apoio, creatividade e visão, sem as quais não tornariam esta dissertação possível. Agradeço à minha família, que sempre me apoiou e ajudou nas decisões a tomar, pela dedicação e compreensão e por todos os sacrifícios que fizeram para tornar o meu caminho académico possível. Agradeço aos meus colegas de investigação, pela importante partilha de conhecimentos e companheirismo, nomeadamente à Diana Soares e Susana Alves. Não menos importante, a todos os meus colegas e amigos que me ajudaram a crescer como pessoa e estiveram sempre presentes, não só nos bons mas também nos maus momentos. A todos, e a cada um em especial, um muito obrigado.

4

5 Abstract The process mining research field is fairly recent, however it counts with numerous techniques that enable extraction of business process models, based on event logs produced in information systems. Typically, these events are extracted to a log file and then analyzed with proper tools, such as ProM. This type of analysis is made over historical data, and by the time it is performed, results could, eventually, be outdated, in the case that business rules/routines had changed or evolved. The main objective of this dissertation is to develop a process mining tool that can be used in real time as the events are being produced. Furthermore, it is imperative to study the behavior of the tool, as the events occur, being incorporated in real time and updating the models instantaneously. Keywords Process Mining, Complex Event Processing, Event-Driven Architecture, ECA Rules iii

6 Resumo A área de process mining é relativamente recente, mas conta já com inúmeras técnicas que possibilitam a extracção de modelos de processos de negócio, a partir de registos de eventos produzidos em sistemas de informação. Tipicamente, estes eventos são extraídos para um ficheiro log que posteriormente é analisado em ferramentas próprias, tais como a ferramenta ProM. Este tipo de análise é efectuada sobre dados históricos e, no momento em que estiver concluída, os resultados poderão eventualmente já estar desactualizados, no caso das práticas/regras de negócio terem entretanto mudado ou evoluído. O objectivo deste trabalho é desenvolver uma ferramenta de process mining que possa ser usada em tempo real, à medida que os eventos são produzidos. Interessa também estudar o comportamento desta ferramenta, à medida que os eventos surjam, sendo incorporados em tempo real, actualizando-se os modelos do processo. Palavras-Chave Process Mining, Complex Event Processing, Event-Driven Architecture, ECA Rules iv

7 Conteúdo 1 Introdução Enquadramento Objectivos Estrutura do Documento Descoberta e Análise de Processos Extracção do Fluxo do Processo Perspectiva Organizacional Ferramentas de Workflow Conclusão Processamento de eventos em tempo real Conceitos de CEP Tipos de Eventos Paradigmas relacionados Ferramentas Conclusão Abordagem Proposta Arquitectura Global da Solução Estruturas de Dados Algoritmos Pós-processamento Implementação Conclusão Caso de Estudo Descrição do Processso Implementação do Processo em BizAgi Execução do Processo Extracção do log de eventos v

8 5.5 Monitorização do processo em tempo real Controlo de Fluxo Redes Sociais Conclusão Conclusão Principais Contribuições Trabalho Futuro vi

9 Lista de Figuras 1.1 Fragmento de um log de eventos (adaptado de [6]) Perspectiva global do process mining (adaptado de [17] ) Exemplo de um modelo de processo antes e depois de aplicar o algoritmo Fuzzy [24] Exemplo modelação em YAWL Informação obtida através da simulação nas ferramentas CPN [27] Processo de desenvolvimento no BizAgi Visão geral da ferramenta ProM [12] Enquadramento da ferramenta ProMImport [28] Combinação de ferramentas para simulação e análise de processos [29] Eventos complexos [42] Event-Condition-Action (ECA) UML da estrutura do padrão Observer [51] Modelo Event-driven Architecture (EDA) [55] Arquitectura Esper Aplicação Oracle CEP [61] Arquitectura geral StreamInsight [63] Arquitectura da Solução Exemplo Matriz de Ocorrência de Transições entre Actividades Exemplo Matriz de Percentagem de Transição entre Actividades Exemplo de Processo Exemplo de duas Matrizes Exemplo dos modelos de rede social produzidos pela aplicação Exemplo da aplicação de thresholds Fila de Mensagens da aplicação Observer Pattern vii

10 5.1 Business Process Model and Notation (BPMN) do Caso de estudo Exemplo de um log de eventos Modelo de Dados Exemplo de Construção de Interfaces Exemplo Regras de Negócio Exemplo atribuição de tarefas a recursos Configuração dos recursos como membros da organização Aviso de tarefa pendente Exemplo preenchimento de formulário de actividade Log de Eventos produzido no BizAgi Modelo Relacional das tabelas seleccionadas Tabela WISTATELOG Interface Aplicacional Exemplo de comparação entre duas matrizes Matriz Inicial Control Flow (CF) Modelo Inicial CF Matriz Intermédia CF Modelo Intermédio CF Matriz Contagem CF Matriz Final CF Modelo Final CF Matriz Inicial Handover of Work (HW) Modelo Inicial HW Matriz Intermédia HW Modelo Intermédio HW Matriz Final HW Modelo Final HW Matriz Inicial Working Together (WT) Modelo Inicial WT Matriz Intermédia WT Modelo Intermédio WT Matriz Final WT Modelo Final WT viii

11 Lista de Acrónimos SML Standard ML MXML Mining XML CPN Coloured Petri Nets YAWL Yet Another Workflow Language LINQ CEP ESP EDA HW WT CF Language-Integrated Query Complex Event Processing Event Stream Processing Event-driven Architecture Handover of Work Working Together Control Flow BPMN Business Process Model and Notation XML EPL extensible Markup Language Event Processing Language BPEL Business Process Execution Language EPC ECA Event-driven Process Chain Event-Condition-Action DSMS Data Stream Management System BAM Business Activity Monitoring ix

12 BPM EPL CQL EQL SQL RFID Business Process Management Event Processing Language Continuous Query Language Event Query Language Structured Query Language Radio-Frequency Identification DBMS Database Management System UML ERP CRM SCM PAIS Unified Modeling Language Enterprise Resource Planning Customer Relationship Management Supply Chain Management Process-Aware Information Systems x

13 1 Introdução Conteúdos 1.1 Enquadramento Objectivos Estrutura do Documento

14 1. Introdução A monitorização dos processos de negócio é essencial para que as organizações consigam melhorar a eficiência dos seus processos. Os sistemas de informação orientados aos processos (PAIS) possibilitam o registo dos eventos no log de eventos que vão sendo gerados pela organização, através da execução dos processos de negócio. Exemplos destes sistemas são os ERP, CRM ou SCM, entre os demais que existem na actualidade [1 3]. Tipicamente a descoberta de processos é feita com recurso a ficheiros de log. Estes ficheiros contêm dados históricos, sendo assim a base para as diferentes análises. Considerando que, os eventos acontecem a todo o momento, poderá, no entanto, não ser possível aceder aos mais antigos, por outro lado poderá ser de todo o interesse aceder aos mais recentes. Isto sugere que seria muito útil aplicar técnicas para a descoberta de processos tendo por base os eventos que acontecem em tempo real. Esta é a base para este trabalho cujo objectivo principal é aplicar as técnicas tradicionais de process mining em tempo real, à medida que os eventos se vão produzindo. 1.1 Enquadramento Para este trabalho têm especial importância as áreas de Complex Event Processing (CEP) [4] e process mining [5]. Estas duas áreas têm sido desenvolvidas em separado. Neste trabalho serão combinadas, de modo a possibilitar a aplicação de técnicas de Process Mining em tempo real. Relativamente ao CEP, este consiste em derivar conhecimento útil de alto-nível em tempo real, a partir de eventos de baixo nível. Para identificar a ocorrência de um evento de alto-nível a partir de eventos baixo nível é necessário utilizar padrões de eventos, que permitem obter essa informação. Para consultar um fluxo de eventos de baixo nível, muitas das ferramentas actuais utilizam como base uma sintaxe SQL. Com esta linguagem é possivel definir operações a realizar sobre janelas de eventos. Os eventos fora da janela de eventos e que já foram processados, serão descartados. Por outro lado, a área de Process Mining permite extrair modelos de processos a partir de logs. Contudo, a maioria das ferramentas só permite aplicar estas técnicas sobre um log estático, o que significa que quando for concluída a análise, eventualmente os modelos já não estão de acordo com a realidade, textiti.e., poderá haver eventos posteriores que entretanto já foram produzidos e que não chegaram a ser analisados. Este trabalho, insere-se na área da análise e descoberta de processos, tendo por objectivo desenvolver técnicas que permitem o mesmo tipo de análise mas com base em eventos recebidos em tempo real. 1.2 Objectivos Um log de eventos geralmente contém informação sobre os eventos referentes a várias instâncias de processo (também conhecidas por casos ). Por exemplo, um pedido de encomenda de produto 2

15 1.2 Objectivos Figura 1.1: Fragmento de um log de eventos (adaptado de [6]) por parte de um cliente, uma candidatura a emprego, participação de um sinistro (seguro), uma licença para construção, etc. A figura 1.1 ilustra um fragmento de um log de eventos. O log de eventos tal como é mostrado na Figura 1.1 é usado como ponto de partida para a aplicação de técnicas de Process Mining. Os eventos fazem menção a uma actividade (activity) e a um caso (case). O caso é o objecto que está a ser tratado, ex:. um pedido de encomenda de um cliente. A actividade (também conhecida como tarefa, operação, acção ou item de trabalho) é uma determinada operação efectuada no caso, i.e., contactar o cliente. Um evento é usualmente denotado por um tuplo (c, a, p, t), onde c é o caso, a é a actividade, p é a pessoa que executa a actividade e t (timestamp) é a data/hora da execução da actividade. Normalmente este log representa um histórico de eventos e a aplicação de técnicas de process mining sobre este log é o que permite descobrir e analisar o processo. Este log é por isso estático, i.e., o conjunto de eventos capturados é fixo. Neste trabalho, o log será tratado, como um conjunto de eventos dinâmico, que cresce à medida que novos eventos são produzidos. Dado ser impossível manter em memória um conjunto infindável de eventos, torna-se preferível fazer uso de abordagens semelhantes ao CEP, em que tipicamente o processamento é feito por janelas de eventos, podendo ser descartados os anteriores à actual janela. Fazendo uma comparação com os sistemas de bases de dados, em que os dados são armazenados, sendo posteriormente definido o processamento a aplicar. Em CEP o processamento é definido a priori e os dados surgem em tempo real. Tendo em conta este enquadramento, os objectivos deste trabalho são os seguintes: Adquirir uma visão da área de process mining e das ferramentas existentes; Desenvolver ou adaptar técnicas de process mining que possam ser utilizadas em tempo real; 3

16 1. Introdução Estudar o comportamento dessas técnicas à medida que os eventos são processados em tempo real; Desenvolver uma ferramenta para processamento de eventos em tempo real. Demonstrar a utilização dessas técnicas num caso de estudo realista. Para concretizar estes objectivos, será necessário estudar problemas adicionais, como formas de medir a qualidade dos resultados obtidos. Será necessário verificar, se é possível construir modelos de processos de negócio em tempo real, e se estes obtêm um nível de precisão satisfatória. 1.3 Estrutura do Documento O documento encontra-se organizado da seguinte forma: No Capítulo 2 Descoberta e Análise de Processos são enumerados e descritos os algoritmos que permitem realizar Process Mining, nas suas principais perspectivas controlo de fluxo, análise de sequências e organizacional. É também realizada uma exposição quanto às ferramentas mais relevantes nesta área de conhecimento. Em seguida, no Capítulo 3 Processamento de eventos em tempo real são descritas as tecnologias e ferramentas existentes na área do processamento de eventos em tempo real, sendo dado foco particular ao motor Esper. No Capítulo 4 Abordagem Proposta é apresentada a arquitectura da solução proposta, onde se descrevem as estruturas de dados implementadas, bem como os algoritmos adaptados e desenvolvidos e as tecnologias empregues. No Capítulo 5 Caso de Estudo é descrito o processo utilizado no caso de estudo, bem como a sua implementação e execução. São também exibidos os resultados produzidos pela ferramenta desenvolvida no presente trabalho. Por último, no Capítulo 6 Conclusão é apresentado um resumo dos objectivos propostos no início do trabalho, bem como as principais contribuições e sugestões para trabalho futuro. 4

17 2 Descoberta e Análise de Processos Conteúdos 2.1 Extracção do Fluxo do Processo Perspectiva Organizacional Ferramentas de Workflow Conclusão

18 2. Descoberta e Análise de Processos A área de process mining preocupa-se com a descoberta, monitorização e optimização dos processos reais através da extracção de informação do log de eventos [7]. Desta forma assume-se que é possível registar eventos tal que (i) cada evento é uma actividade (i.e., uma fase bem definida do processo), (ii) cada evento faz referência a um case (i.e, uma instância do processo), (iii) cada evento pode ter um performer também referido como um originator (a pessoa que executa ou inicia a actividade) e por último os eventos têm um atributo timestamp e estão totalmente ordenados. Distinguem-se três perspectivas principais: (1) perspectiva do processo, (2) perspectiva organizacional e por último perspectiva do caso [6, 8, 9]. A perspectiva do processo preocupa-se com o controlo de fluxo, i.e., o ordenamento das actividades. O objectivo da mineração(em inglês mining) através desta perspectiva é encontrar uma boa caracterização de todos os caminhos possíveis, ex:., expresso em termos de redes de Petri ou EPC [10]. A perspectiva organizacional [11] dá enfoque ao campo originator, i.e., que actores estão envolvidos e como se relacionam. O objectivo aqui é estruturar a organização através da classificação das pessoas em termos dos papéis que desempenham e unidades organizacionais ou então, apresentar as relações entre os actores individualmente (i.e. construir uma rede social). A perspectiva de caso [12 14] concentra-se nas propriedades do caso. Os casos podem ser caracterizados pelo seu caminho no processo ou então pelos originators que trabalham no caso. Contudo, os casos podem também ser caracterizados pelos valores dos elementos de dados correspondentes. Por exemplo, se um caso representar um pedido de reposição de stock, é interessante saber a identificação do fornecedor ou o número de produtos pedidos. As técnicas de process mining podem ser usadas para: (1) Descoberta, i.e., gerar um novo modelo baseado na informação registada no Log de Eventos; (2) Verificação de Conformidade, expor as diferenças entre um determinado modelo a-priori e um modelo real do processo gerado através de um log de Eventos; e (3) Extensão, i.e., enriquecer um modelo a-priori e extênde-lo com novos aspectos e perspectivas de um Log de Eventos [2, 15, 16]. Estes aspectos estão ilustrados na Figura 2.1. Uma das mais conhecidas ferramentas na área do process mining é o ProM (secção 2.3), podendo ser consultada informação formal em [12, 17]. Neste trabalho, as perspectivas em foco serão as duas primeiras, sendo que a última, está fora deste âmbito, não sendo por isso aprofundada. 2.1 Extracção do Fluxo do Processo Nesta secção vão ser apresentadas as técnicas mais utilizadas em process mining para extrair o controlo de fluxo dos processos. 6

19 2.1 Extracção do Fluxo do Processo Figura 2.1: Perspectiva global do process mining (adaptado de [17] ) Algoritmo α Neste algoritmo é criada uma rede de Petri que modela o fluxo do processo. A rede de Petri estabelece um conjunto de relações entre as actividades e assume que o log de eventos é completo (todo o comportamento possível está presente). Este algoritmo apresenta alguns defeitos técnicos, nomeadamente não é robusto ao ruído e não é possível realizar a mineração de processos com ciclos curtos, tarefas invisíveis e tarefas duplicadas/tarefas implícitas. Alguma investigação foi realizada para extender este algoritmo, resultando no algoritmo α++, para resolver a questão dos ciclos curtos [18] e para detectar dependências implícitas [19]. Algoritmo Heurístico Este algoritmo é particularmente útil para lidar com o ruído presente no log de eventos, expressando apenas o comportamento principal presente no mesmo. Isto significa que nem todos os detalhes são apresentados ao utilizador, sendo os casos menos frequentes/excepções ignorados [20]. Algoritmo Genético As técnicas até aqui introduzidas, tinham em comum o facto de serem algoritmos de procura local, i.e., quando analisam as relações de uma determinada actividade apenas são observadas as actividades que lhe estão adjacentes (que lhe sucedam ou precedam directamente no log de eventos). Isto representa uma limitação na descoberta de determinados padrões que impliquem dependências longas, dado exigir uma análise mais abrangente. 7

20 2. Descoberta e Análise de Processos Assim sendo, o problema visado pelos algoritmos Genéticos pode ser definido como a procura num espaço de hipóteses candidatas também denominada por população com o intuito de identificar as melhores. A melhor hipótese é definida como aquela que maximiza uma medida numérica para o problema em questão, a qual é denominada por fitness. Contextualizando no cenário de process mining, uma hipótese pode ser vista como um modelo de processo e a função de fitness como uma métrica que permite avaliar se o modelo reproduz o comportamento registado no log. Desta forma, o algoritmo irá gerar vários modelos (o espaço de hipótese) e, avaliando cada uma através da função de fitness, escolher aquele que melhor representar o log. Este tipo de algoritmos actua de forma iterativa, actualizando a cada passo a população. A cada iteração, os elementos da população são avaliados pela função de fitness, originando uma nova população, gerada a partir dos elementos, da actual população, com melhor fitness. Enquanto alguns elementos (com melhor classificação) avançam directamente para a nova população, sem sofrerem alterações, já outros são submetidos a um conjunto de alterações, obtidas através da aplicação de operadores genéticos: (i) Elitismo, (ii) Cruzamento, (iii) Mutação [10, 21, 22]. Uma apresentação mais formal deste algoritmo pode ser encontrada em [21, 23]. Algoritmo Fuzzy Os algoritmos descritos acima, são produzidos para inferir os modelos de processo, tão completo/meticuloso quanto possível, estando estes de acordo com o comportamento registado no log de eventos. Contudo, na realidade, para logs menos estruturados podem resultar modelos muito complexos e de difícil compreensão, usualmente referidos como spaghetti models (informação mais detalhada pode ser consultada em [24,25]). Assim, é este algoritmo é utilizado para representar o comportamento mais relevante no log de eventos, através do cálculo da relevância das actividades e suas relações. De forma a realizar este cálculo, duas métricas são utilizadas: (1) significância, que mede o nível de interesse que se tem nos eventos (por exemplo, pelo cálculo da sua ocorrência no log) e (2) correlação, que determina quão relacionados dois eventos que se sucedem estão, logo, os eventos fortemente relacionados podem ser agregados. Na Figura 2.2 é apresentado um modelo spaghetti e o modelo depois de ser aplicado o algoritmo Fuzzy. 2.2 Perspectiva Organizacional A sociometria, também referida como sociografia, refere-se aos métodos que apresentam os dados das relações interpessoais através de gráficos ou através de matrizes. A SNA (Social Network Analysis) refere-se à colecção de métodos, técnicas e ferramentas de sociometria cujo objectivo é a análise das redes sociais. Quando se inferem os papéis e outras entidades 8

21 2.2 Perspectiva Organizacional Figura 2.2: Exemplo de um modelo de processo antes e depois de aplicar o algoritmo Fuzzy [24] organizacionais, a partir do log de eventos, o foco está na relação entre pessoas ou grupos de pessoas [11]. A questão que se impõe para esta perspectiva é: Como derivar sociogramas significantes/expressivos a partir dos logs de eventos?. A resposta concentra-se em quatro tipos de métricas : (1) métricas baseadas na (possível) causalidade, (2) métricas baseadas em casos comuns, (3) métricas baseadas em actividades realizadas em conjunto e, (4) métricas baseadas em tipos de eventos particulares [11, 14]. Métricas baseadas na (possível) causalidade monitorizam, para casos individuais, como é que o trabalho é transferido entre as pessoas que o executam. Um dos exemplos, e ao qual é dado enfoque neste trabalho, é o Handover of Work. O Handover of Work apresenta quem entrega o trabalho a quem, sendo possível, através do log de eventos inferir esta conclusão através de duas actividades subsequentes num mesmo caso ou instância de processo. Por exemplo, no caso 1 a Maria inicia e conclui a actividade A e, logo a seguir no mesmo caso o João inicia e completa a actividade B. Neste caso o pressuposto é que a Maria delegou ou passou trabalho para o João. Métricas baseadas em casos comuns ignoram dependências causais, fazendo a contagem relativa ao quão frequentemente dois indivíduos executam actividades para o mesmo caso. A métrica Working Together é um exemplo desta abordagem. Na métrica Working Together, se os indivíduos trabalharem num mesmo caso, então terão uma relação mais forte comparativamente com indivíduos que trabalhem raramente num mesmo caso. Métricas baseadas em actividades realizadas em conjunto não consideram como os indivíduos trabalham em conjunto em casos partilhados, mas dá enfoque às actividades em que eles estão envolvidos. Por cada indivíduo é criado um perfil, que identifica a frequência que determinada actividade é efectuada pelo indivíduo em questão. O pressuposto aqui, é que pessoas que realizem tarefas similares detêm uma relação mais forte do que as pessoas que realizam tarefas diferentes. Tomando como exemplo três indivíduos: Maria só executa actividades do tipo A em seguida o João que só realiza actividades do tipo B e por último Antónia - só desempenha actividades do tipo A. Neste simples caso de estudo, observa-se que a Antónia e a Maria têm uma relação mais sólida, 9

22 2. Descoberta e Análise de Processos Figura 2.3: Exemplo modelação em YAWL 1 pelo facto de executarem o mesmo tipo de actividades, contrastando por exemplo com a relação entre a Maria e o João, que detêm um perfil completamente oposto [26]. Métricas baseadas em tipos de eventos particulares considera o tipo de evento. Fazendo uso destas métricas, obtêm-se observações que são particularmente interessantes para a análise de redes sociais, devido a representarem relações hierárquicas explícitas [26]. Neste trabalho serão usadas as métricas de Handover of Work e Working Together. 2.3 Ferramentas de Workflow Para obter uma compreensão das funcionalidades típicas de um sistema de workflow e os eventos que este permite registar, serão apresentados nesta secção alguns casos representativos de ferramentas, nomeadamente uma ferramenta académica (YAWL) e uma ferramenta comercial, o BizAgi. Também serão descritas nesta secção, as ferramentas de process mining disponíveis para análise dos eventos registados por esses sistemas de workflow. Yet Another Workflow Language O YAWL, como foi referido, é uma ferramenta académica, que consiste num sistema de workflow. Esta tem por base as redes de Petri e os padrões de controlo de fluxo 1. As redes de Petri conseguem capturar alguns dos padrões de controlo de fluxo já conhecidos, mas falta-lhes suporte para padrões de várias instâncias, padrões de cancelamento e o OR-join geral. Assim sendo, o Yet Another Workflow Language (YAWL) extende as redes de Petri através de construtores específicos, para lidar com estes padrões. Na figura 2.3, pode ser visualizado um exemplo sobre a modelação de um processo, especificamente de um processo de pedido de cartão de crédito. O processo é despoletado quando um cliente 1 retirado de M. Adams, YAWL - Technical Manual,

23 2.3 Ferramentas de Workflow submete o pedido (com a quantidade pretendida). Um funcionário acusa a recepção do pedido e verifica se o documento está bem preenchido (checklist). Se não estiver correctamente preenchido, solicita informação adicional, esperando até que a informação seja recebida, antes de passar ao próximo passo. Para o pedido ser considerado completo, o funcionário realiza verificações adicionais para validação de critérios como o do rendimento do requerente, experiência creditícia, informação na central de risco do Banco Central e histórico bancário. Diferentes validações são efectuadas, dependendo do montante pedido. Passadas estas verificações, e validado o pedido de crédito, este é encaminhado para um gestor. Este último tem como função decidir a aceitação ou rejeição do pedido. Sendo o seu parecer favorável, o requerente é notificado da decisão, sendo produzido o cartão de crédito com a respectiva entrega ao cliente. A recusa da proposta, despoleta a notificação ao cliente e respectivo arquivo do processo 2. A principal vantagem desta ferramenta é a extrema flexibilidade que oferece no controlo de fluxo dos processos. Redes de Petri coloridas De facto, o conceito de Redes de petri já era conhecida, são no entanto aqui apresentados os aspectos que constituem esta linguagem. Trata-se de uma linguagem que permite a modelação e validação de sistemas em que critérios como a concorrência, comunicação e sincronização são extremamente importantes. Um modelo de redes de Petri coloridas (em inglês coloured Petri nets, normalmente abreviado para CPN) traduz-se como sendo uma representação gráfica executável que enumera os estados possíveis que um sistema pode apresentar bem como os eventos (transições) que motivam a mudança de estado. Esta linguagem torna possível organizar um modelo como um conjunto de módulos e, inclui o conceito de cronómetro de forma a representar o tempo que é necessário para executar os eventos no sistema modelado. Ferramentas CPN As ferramentas CPN são usadas para construir e analisar modelos CPN, com recurso à linguagem anteriormente descrita. Através destas, é possível investigar o comportamento do sistema modelado através da simulação, para verificar as propriedades por meio de métodos de transições entre estados e verificação do modelo e, também, análises de desempenho baseadas em simulação [27]. Na Figura 2.4 é apresentado o resultado da simulação efectuada sobre o sistema modelado. De referir, que existe a possibilidade da modelação do sistema ser realizada na ferramenta YAWL (ver secção 2.3). Como se pode verificar, estas ferramentas apresentam a informação de forma gráfica, destacando 2 Exemplo retirado de 11

24 2. Descoberta e Análise de Processos Figura 2.4: Informação obtida através da simulação nas ferramentas CPN [27] as actividades que estão a ser executadas, bem como a informação que daí advém, durante o processo de simulação. De acordo com a notação definida para a linguagem utilizada pelas ferramentascoloured Petri Nets (CPN), o estado do sistema modelado é representado por locais. Cada local pode ser marcado por um ou mais tokens, e cada token tem um valor a ele associado. Estes valores são designados de cores dos tokens. Por convenção, os nomes dos locais são colocados dentro de elipses. Na Figura anteriormente mencionada, a forma círcular em tamanho pequeno, preenchida a verde, indica o número de tokens que foram atribuídos a cada local (neste caso, assinaladas em tons de rosa e vermelho) numa marcação, sendo que a forma rectangular (a cor verde), perto do círculo descrito anteriormente, representa o valor dos dados, como foi referido. De referir que a marcação resulta da ocorrência de uma acção despoletada através das múltiplas ligações com outros elementos/locais. Tomando como exemplo o local DataReceived, observa-se que contém um token com o valor COL. O número de tokens e as cores dos tokens em cada local, representam em conjunto o estado actual do sistema. BizAgi BPM Suite Debruçando agora sobre uma ferramenta que é bem representativa das capacidades dos sistemas de workflow actuais. O conceito do BizAgi BPM concentra-se na geração automática de uma aplicação web, baseada e despoletada por um modelo de processo, sem recorrer a qualquer tipo de programação. De acordo com a Figura 2.5, esta solução informática abarca o ciclo de vida completo de um processo de negócio, sendo as etapas enumeradas e descritas de seguida: 12

25 2.3 Ferramentas de Workflow Modelação: Este é o primeiro passo a executar, através da definição do processo de negócio, utilizando-se para tal um padrão globalmente aceite e conhecido pela comunidade, o BPMN. Esta ferramenta permite esquematizar e documentar o processo em questão, de uma forma ágil e extremamente simples. Automatização, i.e., converter todas as actividades que constituem o processo numa aplicação tecnológica. São nesta fase definidos alguns componentes, como fluxo do diagrama, regras de negócio, interface de utilizador, actores que executam as diferentes actividades, entre outros. Posteriormente, este modelo é armazenado na base de dados, interpretado e executado em ambiente de produção através de uma aplicação web inserida no servidor BizAgi. Uma das vantagens desta ferramenta surge quando o processo é modificado no editor, sendo estas alterações repercutidas instantaneamente na aplicação web. Execução: Nesta etapa, o servidor BizAgi baseado no modelo previamente guardado, observa e verifica a correcção e adequação da execução nas diversas actividades e tarefas intrínsecas ao processo de negócio. É neste passo efectuado o controlo e verificação de que as tarefas são executadas no momento correcto, pela pessoa/recurso correcta(o) e, de acordo com as orientações da organização, objectivos e outras regras primordiais. Manutenção, sendo esta fase alcançada sobretudo através do conjunto de relatórios de desempenho e indicadores sobre os processos, permite uma análise completa e minuciosa do estado do negócio, identificando-se assim algumas falhas que possam existir e suas causas, como também identificar oportunidades para refinar o processo. Figura 2.5: Processo de desenvolvimento no BizAgi 3 3 bizagi, Bizagi bpm suite functional description, bizagi, Tech. Rep.,

26 2. Descoberta e Análise de Processos Framework ProM Enquanto as ferramentas anteriores suportam modelação e execução dos processos, a partir daqui são apresentadas ferramentas que se destinam à análise dos dados de execução dos processos. Como já foi referido anteriormente o ProM é uma framework de código livre genérica para implementação de ferramentas de process mining num ambiente padronizado. Como se pode observar na Figura 2.6, o ProM tem a capacidade de ler ficheiros no formato extensible Markup Language (XML) através do componente Log Filter. Este componente é capaz de lidar com grandes quantidades de dados, aplicando-lhes um filtro, mesmo antes de aplicar as técnicas de mining. Outros plug-ins são descritos em seguida [12]: plug-ins para importar ficheiros, implementam uma funcionalidade aberta para objectos específicos, por exemplo, carregar modelos BPEL a partir de WebSphere 4. plug-ins de mining implementam algoritmos de mining, por exemplo, Algoritmo α para inferir modelo de redes de Petri ou redes sociais. plug-ins de análise, tipicamente, implementam determinadas análises de propriedades em certos resultados de mining. Tomam-se como exemplo as redes de Petri, que têm um plug-in que constrói invariantes de lugar, invariantes de transição e gráfico de abrangência. Contudo, existem também plug-ins de análise para comparar um log e um modelo, i.e., verificação de conformidade, ou um log e uma fórmula LTL (Linear Temporal Logic). Além disso, existem também plug-ins de análises relacionadas com a medida de desempenho. plug-ins de conversão, implementam conversões entre diferentes formatos de dados, por exemplo, de EPC para redes de Petri. plug-ins para exportar ficheiros, implementam funcionalidades com uma certa similaridade com o guardar como, para objectos específicos no ProM. Posteriormente ao processamento realizado, os plug-ins na sua grande maioria geram um resultado em formato Frame, sendo possivel visualizar os resultados na ferramenta ProM. ProMImport Para ser possível analisar os dados de execução de processos, é necessário que estes tenham certas características, nomeadamente um identificador do caso, um identificador de cada actividade e um timestamp. Estes dados são normalmente representados numa estrutura XML. O formato largamente aceite e desde cedo adoptado pela comunidade de process mining designa-se como MXML. O MXML 4 14

27 2.3 Ferramentas de Workflow Figura 2.6: Visão geral da ferramenta ProM [12] armazena os logs produzidos pelos sistemas de informação, para posteriormente serem analisados com recurso às técnicas de process mining. Uma das grandes lacunas observadas, concentrava-se na conversão dos logs, produzidos nos mais diversos sistemas, para o formato MXML, pelo facto de não existirem ferramentas capazes de fazer uma tradução mais correcta e precisa e, consequentemente, da não percepção que as técnicas de process mining ofereciam nomeadamente através da globalmente conhecida ferramenta de process mining ProM sobre o real comportamento dos processos de negócio, que não era realista, pelo facto de não incluir determinadas informações na sua análise. Portanto, a ferramenta ProMImport, neste contexto, surgiu como uma ferramenta que se posicionou entre os diversos formatos de logs produzidos pelos sistemas de informação e as ferramentas que processam esse logs através das técnicas de process mining ver Figura 2.7, realizando a conversão correcta e rigorosa desses logs para o formato Mining XML (MXML) [28]. Figura 2.7: Enquadramento da ferramenta ProMImport [28] 15

28 2. Descoberta e Análise de Processos Simulação de processos de negócio Normalmente, os dados usados para análise de processos são recolhidos durante a execução dos mesmos. Uma forma alternativa de obter grandes quantidades de dados para análise, é através da simulação de modelos. Como se pode observar pela Figura 2.8, para gerar um modelo de simulação rigoroso e correcto são necessários três tipos de informação, (i) informação de especificação do processo, (ii) informação do histórico (logs de eventos) e (iii) informação do estado actual. Para efectuar a simulação de um determinado processo, é necessário executar alguns passos iniciais. Em primeiro lugar é necessário desenvolver as especificações do processo, designadamente a perspectiva de fluxo de trabalho, perspectiva dos dados/atributos de cada actividade e perspectiva organizacional, sendo esta concepção realizada com recurso ao YAWL. Após todos os requisitos do processo estarem correctamente criados, esta especificação é exportada para um ficheiro XML, podendo este ser usado pelo motor YAWL para determinar o fluxo de trabalho a ser executado. A próxima etapa consiste na conversão dos logs produzidos pelo YAWL em MXML, através da ferramenta ProMImport. É também necessário exportar os dados do modelo organizacional do processo desenhado, útil para construir o modelo de processo no ProM, sendo os dados do modelo armazenados num ficheiro XML. Em seguida, é preciso exportar também os dados referentes ao estado actual sob o formato SML, para posteriormente ser utilizado nas ferramentas CPN, para inicializar a simulação. Criadas e exportadas as três fontes de informação, a partir das quais se constrói o modelo de simulação: o ficheiro do motor YAWL, o log em formato MXML e o ficheiro com o modelo organizacional, são estes ficheiros posteriormente importados pelo ProM e conjugados, formando um modelo de alto nível baseado no YAWL. Este modelo é convertido num processo de alto nível baseado nas redes de Petri, que pode ser exportado do ProM e utilizado pelas ferramentas CPN, com o formato cpn. As ferramentas CPN ao longo da simulação produzem logs, que são importados para o ProMImport, que os converte para o formato MXML, sendo posteriormente realizado o process mining sobre esses logs. Através da junção destes três tipos de informação informação de especificação do processo, informação do histórico e informação do estado actual num modelo de simulação, é possível construir um modelo exacto com base no comportamento observado em vez de um modelo construído manualmente que se aproxima do comportamento antecipado do fluxo. Além do descrito, a informação sobre o corrente estado suporta uma capacidade preditiva, em que a simulação pode ser usada para explorar diversos cenários relativamente ao seu efeito num futuro próximo. Desta forma, a simulação pode ser usada para tomar decisões a nível operacional. 16

29 2.4 Conclusão Figura 2.8: Combinação de ferramentas para simulação e análise de processos [29] 2.4 Conclusão Neste capítulo foram referidas as técnicas e ferramentas para a modelação, simulação, execução e análise de processos de negócio. A visão geral destas ferramentas é importante, para se compreender as funcionalidades que elas tipicamente oferecem e, para sublinhar o facto de a análise de processos ser feita com recurso a dados históricos (sejam obtidos por execução ou simulação). No entanto, o principal objectivo deste trabalho é demonstrar a capacidade de realizar esta análise em tempo real, à medida que os eventos são gerados. Por esse motivo, o próximo capítulo é dedicado ao estudo dos paradigmas e ferramentas relacionados com o processamento de eventos em tempo real. 17

30 3 Processamento de eventos em tempo real Conteúdos 3.1 Conceitos de CEP Tipos de Eventos Paradigmas relacionados Ferramentas Conclusão

31 3.1 Conceitos de CEP As técnicas de análise apresentadas no Capítulo 2, destinam-se ao processamento de dados históricos, com vista a extrair modelos com base em instâncias completas. No entanto, no seu recente livro [30], o professor Wil van der Aalst menciona a possibilidade de análise de processos ser realizada em modo online em vez de do tradicional modo offline. Este processamento online corresponde precisamente ao processamento em tempo real, que se desenvolveu neste trabalho, estando este tema intimamente ligado à área de processamento de eventos complexos (CEP), que também advoga o processamento de eventos em tempo real. 3.1 Conceitos de CEP Os sistemas de informação orientados a eventos exigem um processamento de eventos sistemático e automatizado. O CEP engloba métodos, técnicas e ferramentas para processar eventos em tempo real. É o conhecimento útil obtido de alto-nível, tendo como ponto de partida eventos de baixo-nível. São diversas as implementações académicas e comerciais neste campo de conhecimento, o que na actualidade, variando em grande medida na expressividade das regras e consultas de dados, facilidade de utilização, desempenho e na forma como são integradas na estrutura global das tecnologias de informação da organização [31]. A incubadora da tecnologia CEP foi o projecto de investigação RA- PIDE [32]. Neste projecto, concretizou-se a percepção de que os eventos tinham de ser apresentados através de hierarquias. Foi também percepcionado que os eventos complexos eram derivados através de relações como a causalidade, e onde eram necessários mapeamentos entre padrões de eventos, de forma a modelar uma arquitectura de sistemas multi-camada. Os conceitos básicos, derivados do projecto RAPIDE que formam o CEP são os seguintes [32, 33]: Hierarquias de Eventos ou abstracção hierárquica, i.e., os eventos produzidos pelos sistemas são de baixo nível, no entanto, o nível de detalhe é elevado. É necessário separar os eventos por várias camadas, em que por cada camada os eventos da camada inferior que contenham uma relação próxima são agregados, gerando uma camada de mais alto-nível, de forma a que se obtenha uma melhor percepção. Isto foi introduzido no projecto RAPIDE [34]. Modelação causal de eventos, o CEP opera não só nos conjuntos de eventos mas também nas relações entre eventos. O Tempo, com respeito ao relógio do sistema, representa uma relação, i.e., evento A ocorreu antes do evento B, usualmente o timestamp vem como atributo na informação dos eventos; Causa é outra relação: evento A causou o evento B a acontecer. E inversamente, A e B são independentes se estes eventos não são causalmente relacionados. A causalidade é modelada com ordem parcial entre os eventos. Padrões de eventos e correspondência entre padrões, estes permitem a detecção de relações 19

32 3. Processamento de eventos em tempo real entre eventos que são baseados na ordenação temporal. Mapeamento de padrões de eventos, consiste na observação de eventos num determinado nível da hierarquia e tenta detectar correspondências entre os padrões de eventos e os de entrada. O resultado será um novo evento, ou num caso geral, um conjunto destes relacionados entre si por causalidade. Este novo evento estará representado na camada acima do nível a que pertencem os eventos de entrada [33]. Restrição do padrão de eventos, é uma condição booleana, que deve ser respeitada pelos eventos observados no sistema 1. Contudo, foi nas comunidades de bases de dados activas que o CEP teve as suas raízes [32,35,36]. Essas comunidades desenvolveram conceitos como ECA e DSMS, apresentados no presente documento. Posteriormente, o CEP começou a ser aplicado em diversas áreas: BAM, BPM, entre outras. Enquanto o CEP emprega a abordagem inbound para processar o fluxo de eventos como fonte de dados de entrada, por oposição, as bases de dados tomam uma abordagem de processamento outbound. A diferença está no facto de que enquanto o processamento outbound requere o armazenamento prévio de todos os dados antes do processamento, o primeiro permite que os dados sejam processados logo quando são recebidos e só depois armazenados, caso seja necessário, resultando assim num aumento significativo de desempenho [31]. As três mais comuns e relevantes relações que ocorrem entre eventos são: Tempo, sendo esta uma relação que ordena os eventos, i.e., evento A ocorre antes do evento B. Causalidade, esta é uma relação de dependência entre actividades de um sistema. Agregação, concentra-se na relação de abstracção, i.e., se o Evento A representa a actividade das actividades de um conjunto de eventos, sendo eles {B1,B2,B3}, então A é a agregação de todos os eventos de B. Para consulta dos fluxos de dados, foram desenvolvidas várias abordagens, sendo a baseada na sintaxe SQL, a que mais sucesso atingiu, que é suportada de forma eficiente e escalável por diversos produtos. Os mais conhecidos são o Oracle CEP (ver secção 3.4), Borealis [37], Aurora [38], Coral8, StreamBase, Aleri e o projecto de código-aberto Esper [39]. Foi criado o termo geral Event Processing Language (EPL) para classificar as linguagens de consulta de dados. As mais conhecidas são o Continuous Query Language (CQL) do projecto STREAM e Event Query Language (EQL) do projecto Esper. Estas linguagens têm em comum a utilização das cláusulas básicas da sintaxe Structured Query Language (SQL), como o SELECT, FROM, WHERE. Mas neste caso, os fluxos de dados substituem as tabelas como fonte de dados, com os eventos a substituir os tuplos como unidade básica de dados. 1 Retirado de mambowiki/itemid,85/ 20

33 3.1 Conceitos de CEP Dado que os eventos são compostos essencialmente de dados, os conceitos relativos à correlação SQL são representados através de joins (intersecção de dados), filtragem (filtering) e agregação através da cláusula group by podem ser influenciados por esta notação. No entanto, como já foi afirmado, é necessário derivar eventos complexos de alto nível, o que levou à necessidade de criação de linguagens próprias [40]. Até à data, não existe um padrão comum para a linguagem de processamento de eventos que reúna a informação detalhada de estruturas e sintaxe, o que provoca uma enorme diversidade de linguagens para atingir um mesmo objectivo que tem uma base comum, mas que cada uma delas, oferece diferentes sintaxes e também diferentes funcionalidades [39]. Será aprofundado o motor Esper, pelo facto de este ser utilizado neste trabalho. A comunidade de base de dados foi precursora no processamento de eventos em tempo real, devido ao facto de se terem verificado, que estas eram extremamente lentas para realizar este processamento 2. Então, começou-se a investigar a ideia de realizar as consultas no fluxo de dados, utilizando janelas de tempo que deslizam sobre o este para acelerar as interrogações. O processamento de eventos em tempo real constitui na actualidade um enorme desafio para as organizações. É necessário extrair conhecimento útil a partir de eventos que estão a ser continuamente produzidos por diversos sistemas de informação, identificando as actividades que estão a ser efectuadas, de forma a retratar o que realmente está a acontecer. Esta complexidade resulta da proliferação de sistemas distribuídos, comunicando estes através de mensagens/eventos. Como resultado, é produzida uma quantidade enorme de eventos, onde é difícil identificar informação útil, problemas, tendências ou efeitos em determinados domínios IT-blindness [4] designado este conjunto de eventos de nuvem de eventos. Para obter um bom nível de IT-Insight [4], i.e., a percepção dos padrões dos eventos complexos é necessária, pelo facto destes serem gerados por diversos componentes de diferentes camadas das tecnologias de informação. É aqui necessário, fazer uma distinção entre fluxo de eventos e uma nuvem de eventos. Relativamente ao primeiro, é uma sequência de eventos ordenados por tempo, como por exemplo um feed da bolsa de valores. Já uma nuvem de eventos é o resultado da execução concorrente de muitas actividades que tiveram lugar em diversos componentes de um sistema de informação. Um fluxo de eventos é um caso particular de uma nuvem. Os conceitos de Event Stream Processing (ESP) (ver secção 3.3) e CEP (ver secção 3.3) surgem como uma possível solução para responder à questão essencial de como subscrever e processar eventos em tempo real. Nesta secção, será também mostrado, que algumas das ideias subjacentes ao CEP/ESP já existiam no passado, sob outros tópicos como, a visualização de eventos por humanos, middleware orientado a mensagens (EDA) para o transporte de mensagens, sistemas de regras para especificação de comportamento reactivo (ECA) e Business Process Management (BPM) (informação sobre BPM pode ser encontrada em [41]). 2 s-the-difference-between-esp-and-cep/ 21

34 3. Processamento de eventos em tempo real 3.2 Tipos de Eventos Alguns conceitos fundamentais para compreender a área de CEP, são descritos de seguida. Evento Complexo, significa uma abstracção de outros eventos, designados como membros. Dado o exemplo da chegada de mercadoria a uma organização, e usando como tecnologia o RFID. Um evento complexo pode ser deduzido a partir de outros eventos de baixo nível, através da leitura de identificadores RFID dos produtos 3 por certos sensores. Os eventos complexos são derivados através de operadores de álgebra de eventos. Na Figura 3.1 pode ser observado o método como se produzem os eventos complexos. Figura 3.1: Eventos complexos [42] Evento Primitivo, é a ocorrência atómica mais pequena, gerada num sistema, que requer uma resposta. É importante referir que neste trabalho, usaremos eventos registados em logs de sistemas de informação, sendo que estes eventos, correspondem a um nível de abstracção das actividades definidas no processo que lhes deu origem. Não existe assim, uma distinção entre eventos primitivos e eventos complexos, no entanto o grau de abstracção dos que são considerados, situa-se algures entre esses dois níveis. Na próxima secção serão enumerados e descritos os principais tópicos relacionados com o CEP e ESP. 3 Tecnologia explicada em 22

35 3.3 Paradigmas relacionados 3.3 Paradigmas relacionados Os conceitos subjacentes ao CEP, não são inteiramente novos, na medida em que já eram implementados em outros tipos de abordagem. Regras ECA Este conceito foi originalmente introduzido pela comunidade de bases de dados, no final dos anos 80 [43, 44]. As bases de dados quando foram concebidas, denominadas de passivas, tinham como funcionalidade, armazenar uma quantidade significativa de dados importantes para as diversas organizações. Com o uso cada vez mais generalizado destes mecanismos de persistência de dados, as funções que estas desempenhavam, começaram a ser bastante escassas para as necessidades demonstradas pelos utilizadores [45]. Os utilizadores necessitavam de ter bases de dados que fossem reactivas face às transacções realizadas. Isto implicaria conferir autonomia à base de dados, libertando o utilizador de realizar manualmente tarefas repetitivas e morosas. Muitas foram as aplicações ad-hoc desenvolvidas, oferecendo estas novas funcionalidades, que complementavam as tradicionais proporcionadas pelas bases de dados. Contudo, o tempo de execução das tarefas ficava aquém das expectativas, face à evolução do mercado global e foi decidido por parte dos fabricantes que era necessário extender as funcionalidades tradicionais, adicionado inteligência ao seu motor de base de dados [45]. A metodologia baseou-se na detecção de eventos específicos sem intervenção do utilizador ou de aplicações externas, automatizando o motor de base de dados de maneira a que este, de acordo com as condições previamente estabelecidas, fosse capaz de avaliar as condições face aos eventos de entrada e, caso se verificasse que a condição era verdadeira, fossem despoletadas acções em resposta esses eventos. Desde então, muitos foram os grupos de investigação a dissertar sobre esta problemática, tendo sido desenvolvidos alguns protótipos sendo os mais conhecidos o SAMOS, ACOOD e HiPAC [45]. A metodologia foi concretizada, tomando como designação regras ECA [43, 44, 46, 47]. Outra designação dada a este modelo foi Production Rules [39, 48]. Nas regras ECA, o evento é uma alteração realizada sobre a base de dados, a condição corresponde a uma consulta sobre a base de dados para fazer uma verificação da regra e, se essa verificação tiver um resultado positivo então a acção é realizada, o que corresponderá a um conjunto de operações a efectuar. Estas regras são definidas e armazenadas na base de dados, o que confere o benefício destas poderem ser partilhadas por muitas outras aplicações. Uma regra ECA é definida da seguinte forma: on event if condition then action 23

36 3. Processamento de eventos em tempo real De forma resumida tem-se que [48, 49]: A parte event da regra descreve um acontecimento ao qual a regra está capacitada para responder. A parte condition da regra examina o contexto no qual o evento está inserido. A parte action descreve a tarefa a ser executada pela regra se estiver a ser processado um evento relevante e se a condição tiver uma avaliação positiva. Figura 3.2: ECA A Figura 3.2 apresenta um exemplo da aplicação das regras ECA. As potencialidades evidenciadas pelas regraseca, apareceram em vários produtos desde Oracle, Sybase e nas linguagens SQL2 e SQL3 [47]. Data Stream Management System Este termo diz respeito a ferramentas que controlam e interrogam fluxos de dados [50]. O uso do Data Stream Management System (DSMS) para gerir um fluxo de dados é análogo ao Database Management System (DBMS) para gerir uma base de dados convencional. Tipicamente, 24

37 3.3 Paradigmas relacionados uma consulta a uma base de dados é executada uma vez, retornando um conjunto de resultados, para um dado período no tempo. Em contraste, um DSMS executa uma consulta contínua sobre os dados do fluxo, estando assim a informação sempre actualizada ao longo da produção dos eventos. Estes sistemas foram concebidos para lidarem com certas questões, tais como, a celeridade do fluxo de dados, variações no decorrer do tempo inerentes às características de cada fluxo e consulta de carga e, também, a existência de recursos limitados. Dois dos mais referidos sistemas, categorizados neste conceito, são o STREAM [50] e Aurora [38]. Padrão Observer O padrão Observer [51] é um padrão de desenho de software que define uma dependência umpara-muitos entre objectos, para que, quando um objecto sofre uma alteração no seu estado, todos os interessados sejam notificados. Os conceitos-chave que compõe este padrão são dois: subject e observer. O primeiro pode ter um número ilimitado de observers dependentes de si. Todos os observers são notificados sempre que se verifica uma alteração no estado do subject. Em resposta, cada observer irá interrogar o subject de forma a sincronizar o seu estado com o estado do subject. Este comportamento está representado na Figura 3.3. Figura 3.3: UML da estrutura do padrão Observer [51] Este tipo de interacção é também conhecido por Publish-Subscribe [52], onde o subject se comporta como o publisher das notificações. Este envia as notificações sem qualquer conhecimento prévio sobre quem são seus observers. Os subscritores têm a possibilidade de expressar o seu interesse num determinado evento, ou padrão de eventos, e consequentemente são notificados quando um evento do seu interesse é capturado. Implementações deste padrão usualmente, na transmissão do subject, anexam informação adicional acerca da alteração de estado. O subject passa essa informação como argumento na função Update. Esta informação varia consoante o modelo que é escolhido: modelo push ou modelo pull. No primeiro caso, o subject envia aos seus subscritores informação detalhada 25

38 3. Processamento de eventos em tempo real sobre a alteração registada. Relativamente ao segundo caso, o subject envia apenas a informação mínima, relativa à notificação, tendo os observadores posteriormente de requerir a informação em mais detalhe, relativa a essa notificação. De realçar que o subject regista os observers, sendo cada um deles um concretesubject. Já os concreteobservers herdam a função Update, onde recebem informação de notificação relativa a um novo evento. BAM Este termo foi originalmente introduzido pela organização Gartner [53], como referindo o conjunto de ferramentas que realizam o processamento de eventos em tempo real (agregação e análise) produzidos pelos diversos sistemas da organização e apresentação de informação sobre as actividades. A informação produzida baseia-se nos indicadores de desempenho mais críticos para a organização (Key Performance Indicators), identificando o estado dos diversos componentes e processos da organização. EDA Este conceito foi introduzido pela organização Gartner em 2003 [54], para descrever um novo paradigma baseado na transmissão de eventos entre componentes desagregados e serviços. Nesta arquitectura existem três estilos de processamento de eventos: (1) simples, (2) de fluxo e (3) complexos [54, 55]. No processamento de eventos simples, quando um evento ocorre, inicia uma acção de downstream (i.e., onde as consequências do evento são apresentadas) ou, são despoletadas uma série de acções. O processamento de eventos simples é usado para conduzir os fluxos em tempo real a eliminar o tempo de latência e assim reduzir o custo. O processamento do fluxo de eventos (ESP) é usado para propagar os fluxos de eventos a todos os subscritores, para que estes recebam a notificação. É normalmente usado para auxiliar na tomada de decisão num curto espaço de tempo. O processamento de eventos complexos lida com a avaliação da confluência dos eventos, podendo ser a correlação destes causal, temporal ou espacial. Nesta arquitectura orientada a eventos, um evento é disseminado para todos os interessados nesse tipo de eventos, sendo os seus subscritores a avaliar o evento e decidir se é necessário despoletar alguma acção. O produtor de eventos não tem qualquer conhecimento do processamento subsequente do evento nem das partes interessadas. Na Figura 3.4, encontra-se representado um modelo onde são indicados os módulos que compõe o EDA, onde se verifica que o CEP já está incluído neste conjunto de componentes. Desta maneira, o CEP é uma poderosa adição ao EDA, devido ao facto de que pode detectar situações complexas em tempo real. 26

39 3.4 Ferramentas Figura 3.4: Modelo EDA [55] 3.4 Ferramentas É nesta secção realizada a enumeração, bem como a descrição, das ferramentas mais relevantes na àrea de processamento de eventos complexos. As ferramentas descritas, foram seleccionadas por estarem em constante evolução, relativamente às funcionalidades bem como na optimização a que são sujeitas. Para além desta motivação, outra também surge como importante, que é a da maturidade que já atingiram relativamente ao seu desempenho. Esper Este motor é um software de código-aberto, que combina dois estilos de processamento de eventos: ESP e CEP. O módulo CEP foi desenvolvido com base no modelo de comportamento máquina de estados, por ser uma base intuitiva para expressar os padrões de eventos CEP. Relativamente ao ESP, teve como base as redes delta (para uma definição formal sobre redes delta consultar [56]). O Esper 4 trabalha de forma idêntica a uma base de dados invertida, i.e., em vez de armazenar os dados e posteriormente fazer a consulta sobre os dados, possibilita às aplicações armazenar expressões de consulta de dados que se mantêm estáticas interrogando os dados com as instruções já especificadas. O modelo de execução é, assim, contínuo em vez de ser realizado apenas quando a query é submetida [57]. O motor oferece ainda dois mecanismos principais, para processar eventos: padrões de eventos e consultas ao fluxo de eventos. A sua linguagem de consulta de eventos, é baseado no SQL, designando-se EQL, e é usada para 4 27

40 3. Processamento de eventos em tempo real expressar cláusulas de filtering, joins, aggregation, sobre múltiplos fluxos de dados, enquanto que a linguagem de padrão é usada para definir padrões mais complexos nos diferentes tipos de eventos. Um exemplo de uma expressão de um padrão tem a seguinte configuração (Equação 3.1): every a = EventX every b = EventY (objectid = a.objectid) (3.1) Neste exemplo é observado que vai ser gerado um novo evento, de mais alto-nível, sempre que se verificar a transição do EventX para EventY tendo estes identificadores iguais. Uma das funcionalidades promovida neste projecto foi a utilização de views. Estas, definem os dados dos fluxos que estão disponíveis para consulta e filtragem, existindo reutilização das views para outras instruções EQL. Esta sintaxe permite criar uma instrução EQL, como está patente no Algoritmo 3.1 [42]. Algorithm 3.1 Exemplo instrução EQL( [42]) select a. id, count ( ) from p a t t e r n [ every a=status > ( t i m e r : i n t e r v a l (10 sec ) and not Status ( i d =a. i d ) ] group by i d De acordo com o Algoritmo referido, pode verificar-se uma cláusula de agregação (group by), tem-se também um padrão, que permite capturar eventos complexos, em que para cada condição, é verificado se o atributo Status é precedido de um não status num intervalo de 10 segundos, onde os identificadores são iguais. Figura 3.5: Arquitectura Esper 5 5 retirado de 28

41 3.4 Ferramentas Como se pode verificar pela Figura 3.5, o Esper inclui uma camada de acesso a dados históricos, para estabelecer conexão com as bases de dados mais populares, sendo possível combinar dados históricos com os dados de tempo real numa simples consulta [58]. Oracle Complex Event Processing (CEP) Esta é outra ferramenta de relevo para processamento de eventos complexos. Conhecida formalmente como WebLogic Event Server (ver [59] para informação em mais detalhe), é um servidor Java para desenvolvimento e instalação de aplicações orientadas a eventos de alto desempenho. É um Java container aplicacional extremamente leve, baseado na implementação Equinox OSGi (ver [60] para informação em detalhe), com serviços partilhados, incluindo o motor de Oracle CEP que oferece um ambiente rico e declarativo, firmado sobre a Oracle Continous Query Language (Oracle CQL) uma linguagem de consulta muito similar ao SQL, com adição de construtores, direccionada para o suporte ao fluxo de dados para optimizar a eficiência e eficácia da gestão das operações envolvidas no negócio. O Oracle CEP suporta taxas de transferência de dados ultra - rápidas e latência de micro-segundos, adoptando para tal a máquina virtual Java mais rápida do mundo, JRockit Real Time. Oferece como outras vantagens, o Oracle CEP Visualizer e o Oracle CEP IDE um plug-in SDK (Software Development Kit) para o Eclipse, oferecendo assim uma plataforma de desenvolvimento completa [61]. As essenciais características do Oracle CEP incluem correspondência entre padrões, janelas de eventos definidas pelo utilizador, para análise de eventos (incluindo janelas temporais, janelas de linhas, janelas de predicados e janelas de referências) e, enriquecimento dos resultados através da avaliação contextual dos eventos [62]. Uma aplicação Oracle CEP é, tipicamente, composta pelos componentes primordiais adaptadores, canais, processadores e Event Beans, como se observa na Figura 3.6. Figura 3.6: Aplicação Oracle CEP [61] Um benefício desta ferramenta encontra-se no facto de permitir fazer alterações no sistema e colocálas em produção, sem que seja necessário parar o sistema. 29

42 3. Processamento de eventos em tempo real Microsoft SQL Server 2008 Stream Insight O servidor CEP StreamInsight inclui um motor nuclear desenvolvido para processar uma grande quantidade de dados em tempo real. O motor alcança um alto desempenho através da execução de consultas paralelas de dados, e, usando a memória cache para evitar incorrer em overhead através do armazenamento de dados para processamento. O motor permite tratar os dados que chegam numa taxa constante ou intermitente, como também tratar dos dados que cheguem fora da sua sequência normal. As consultas de dados podem também englobar fontes de dados que não as de streaming (transmissão contínua de dados), tal como master reference data ou dados históricos mantidos numa data warehouse. Para desenvolver aplicações CEP, podem ser usadas linguagens de programação contidas na Framework.NET, tal como C#. Nestas aplicações, estão embebidas consultas de dados declarativas, usando expressões Language-Integrated Query (LINQ) para fazer o processamento de dados para análise. Inclui também outras ferramentas para administração e desenvolvimento de aplicações CEP. A arquitectura do servidor StreamInsight (ver Figura 3.7), contém os seguintes componentes: Figura 3.7: Arquitectura geral StreamInsight [63] 30

43 3.5 Conclusão Adaptadores de entrada: É nestes adaptadores feita uma conversão dos dados de entrada para o formato pretendido. Adaptadores de saída: Estes têm de realizar a função inversa dos adaptadores de entrada, ou seja, convertem o formato dos eventos processados para o formato requerido pelos subscritores. Instâncias da Query: As consultas de dados que foram desenvolvidas, estando estas a correr em tempo real, recebem os fluxos de dados do adaptador de entrada, aplicam a lógica de negócio aos dados (por ex. como uma agregação) e, por fim, enviam os resultados para os adaptadores de saída. As regras de negócio são encapsuladas numa instância de query designado query template, desenvolvido com recurso à combinação entre as linguagens LINQ e.net. Após a instanciação de uma query, esta pode ser iniciada, parada ou efectuar somente a sua gestão. As operações que se podem efectuar com as consultas de dados deste motor CEP são a projecção, filtragem, janelas de eventos, agregação, TopK, agrupamento/combinação, joins, unions e também, recorrer a funções ad-hoc, sendo estas últimas desenvolvidas para uma tarefa mais específica. No Algoritmo 3.2, observa-se um tipo de janela de eventos, a janela hopping, onde é necessário especificar o tempo abrangido pela janela também conhecido como tamanho da janela e o tempo entre o inicio de uma janela e o inicio da próxima designado como intervalo entre janelas. Neste caso, o tamanho da janela é de uma hora, sendo iniciada uma nova janela a cada quinze minutos, obtendo-se como resultado o número de eventos observados por cada janela de eventos. Para mais informação, ver [63]. Algorithm 3.2 Exemplo de uma Janela de Eventos no StreamInsight var outputstream = from eventwindow in inputstream.hoppingwindow(timespan.fromhours(1), TimeSpan.FromMinutes(15)) select new { count = eventwindow.count() }; 3.5 Conclusão Trata este capítulo do processamento de eventos complexos, dos conceitos associados a este processamento e das principais ferramentas, que hoje em dia suportam este paradigma. Dado que o objectivo principal deste trabalho é a análise de processos em tempo real, os próximos capítulos irão debruçar-se sobre a adaptação das técnicas de process mining, de forma a permitir esse tipo de processamento. O capítulo 4, descreve a abordagem proposta, e o capítulo 5, descreve a aplicação dessa abordagem num processo de exemplo que serve como caso de estudo (case study). 31

44 4 Abordagem Proposta Conteúdos 4.1 Arquitectura Global da Solução Estruturas de Dados Algoritmos Pós-processamento Implementação Conclusão

45 4.1 Arquitectura Global da Solução Neste trabalho, é proposta uma abordagem orientada a eventos, resultando estes últimos da execução dos processos de negócio da organização. Neste capítulo será realizada uma breve introdução à solução concebida, sendo concretizada através de uma descrição de alto-nível (na secção 4.1), materializando esta visão geral, através da exposição dos detalhes mais técnicos na secção 4.5. Para além do mencionado, serão também apresentadas as estruturas que armazenam os dados provenientes dos eventos de entrada, na secção 4.2, bem como os algoritmos que efectuam o processamento de eventos, desenvolvidos através de técnicas de process mining adaptadas para processamento de dados em tempo real, produzindo modelos de controlo de fluxo e de rede social. 4.1 Arquitectura Global da Solução Os conceitos fundamentais desta abordagem são (1) os eventos, uma mensagem contendo informação sobre uma operação realizada pelo/no sistema (2) canais de eventos, fluxos de eventos que ocorrem entre os emissores e os consumidores, (3) processos de negócio, conjunto de actividades cujo objectivo é produzir valor para o cliente e (4) técnicas de process mining, que permitem extrair informação útil a partir de um log de eventos. A arquitectura, apresentada na Figura 4.1, é separada em duas etapas: (1) produção de eventos e (2) processamento de eventos. Na primeira etapa desta arquitectura, estes são encaminhados para um canal de eventos que suporta o fluxo entre os sistemas de informação que executam os processos e o log de eventos onde serão posteriormente registados. O número de canais de eventos, dependerá da especificação de cada sistema de informação, uma vez que é nesta fase que é efectuada a análise relativa à necessidade de criação de um novo log, e, por conseguinte, um novo canal de evento, ou caso contrário, reutilização dos componentes em uso. Estes canais serão a fonte de eventos de entrada para a ferramenta desenvolvida no presente trabalho, que efectua o seu processamento. Através de um mecanismo de publicação/subscrição, os eventos são publicados pelo canal e subscritos pela ferramenta de processamento de eventos. Já na segunda etapa, os eventos são analisados individualmente e, caso se verifique a existência de um subscritor para o tipo de evento em análise, será enviado para esse componente, que posteriormente aplicará a técnica de process mining, tendo como resultado um modelo, podendo ser de controlo de fluxo do processo ou de redes sociais. De sublinhar o facto, de que neste trabalho, o process mining é realizado em tempo real, em contraste com as ferramentas existentes, que processa um log de eventos estático, sendo este o principal contributo desta dissertação. 33

46 4. Abordagem Proposta 4.2 Estruturas de Dados Figura 4.1: Arquitectura da Solução Neste trabalho haverá necessidade de armazenar os dados resultantes do processamento em estruturas de dados próprias, que servirão de suporte aos modelos apresentados. A estrutura de dados que será usada mais recorrentemente, tem a forma de uma matriz de transições que pode representar transições entre actividades no caso dos modelos de CF ou, entre actores no caso dos modelos de redes sociais. Será mostrado adiante, que o processamento de eventos em tempo real resulta numa actualização constante destas estruturas de dados. O cálculo das transições, resulta da aplicação da propriedade das cadeias de Markov de primeira ordem, aos eventos de entrada. Na aplicação desenvolvida neste trabalho, as matrizes foram implementadas numa estrutura de dados designada por dicionário. Estes ditos dicionários, são compostos por um par chave-valor, que estabelecem uma relação directa entre si. A chave é o elemento principal deste par, pelo facto de que no pressuposto de existir uma colecção de dicionários, este será o atributo pelo qual o par será inequivocamente identificado. Controlo de Fluxo Para suportar os modelos de CF recorre-se a uma Matriz de Ocorrência de Transições entre Actividades, que armazena informação relativa à contagem de transições entre actividades. Esta 34

47 4.2 Estruturas de Dados matriz é mantida em memória ao longo do funcionamento da aplicação fazendo a correlação entre actividades, de acordo com a data de execução das actividades, dentro de cada instância de processo. Um exemplo da aplicação, em termos práticos, desta matriz é exibido na Figura 4.2. Como se pode observar, a coluna que está destacada a vermelho i representa a primeira actividade do processo, sendo que as duas linhas realçadas a vermelho o simbolizam as actividades terminais do mesmo. De referir que, o elemento comum que sobressai das linhas e colunas realçadas é o facto da soma de todos os seus elementos ser zero. Figura 4.2: Exemplo Matriz de Ocorrência de Transições entre Actividades Para armazenar todos os nomes das actividades observadas, recorre-se a uma Lista de Actividades, que contém uma lista das não duplicadas, construída ao longo do processamento dos eventos de entrada. Para se efectuar o armazenamento de uma lista, em que por cada instância é determinada uma lista de actividades executadas, relacionadas com a instância em questão, tem-se a estrutura Listas com Informação sobre Instâncias de Processo, sendo ordenadas as actividades por data de execução, de forma ascendente. O conjunto de listas anteriormente referidas, é também mantido em memória e permite, após ser aplicado o algoritmo de CF, e realizada a comparação com a Matriz de Ocorrência de Transições entre Actividades, a geração/actualização de uma matriz de transições (ver Figura 4.2). Esta última, é posteriormente convertida para uma Matriz de Percentagem de Transição entre Actividades (Figura 4.3), que define a percentagem de transição observada, de acordo com os eventos registados, entre actividades. Figura 4.3: Exemplo Matriz de Percentagem de Transição entre Actividades A percentagem da transição entre um par de actividades (representado por a ij ) resulta da divisão entre o número de transições ocorridas entre cada par de actividades (representado por n ij ) sobre a 35

48 4. Abordagem Proposta soma total da linha em análise (representado por j n ij), tal como é demonstrado na Equação 4.1. a ij = n ij j n ij (4.1) Um exemplo da aplicação desta equação, pode ser verificado na transição da actividade A1 para A4, onde se observa que a transição entre as duas actividades ocorreu 3 vezes, então, utilizando a fórmula referida, tem-se cujo resultado é 0,12. Cada nova matriz de percentagem de transições produzida tem de ser armazenada, para que se mantenha um histórico de matrizes, recorrendo-se então, a uma Lista de Matrizes. Como culminar deste processamento, obtém-se um modelo, apresentado na Figura 4.4. Figura 4.4: Exemplo de Processo Redes Sociais Tal como no caso dos modelos de Controlo de Fluxo, também para dar suporte aos modelos de redes sociais, serão usadas estruturas de dados em forma de matriz. Como as estruturas de dados para o processamento de eventos nas técnicas de Handover of Work e Working Together são similares, será realizada uma abordagem mais generalizada. Inicialmente é utilizada uma Lista de actores, que como o próprio nome indica, é uma enumeração de todos os nomes não duplicados de actores observados. É também necessário um conjunto de listas, designada Lista de Actores por Instância de Processo, que permite fazer uma associação entre uma instância e os actores que executaram actividades na mesma. Por forma a conjugar os dados anteriormente armazenados, é necessária uma Matriz de Ocorrência de Interacção entre Actores (Figura 4.5), que representa o número de entregas de trabalho (Handover of Work) entre actores ou o número de interacções estabelecidas entre os pares de actores envolvidos relativamente às instâncias do processo observadas (Working Together). De referir, que a matriz que representa a técnica de Working Together, é simétrica, e basta apenas considerar o triângulo superior ou inferior, i.e., se a Rita trabalhou em 1 caso com a Maria, então é sabido que a Maria trabalhou num caso com a Rita. É necessário também manter um histórico das matrizes produzidas no processamento efectuado em cada uma das técnicas aqui enfatizadas, sendo este materializado através de uma Lista de Matrizes. Como último passo deste processamento, obtêm-se os modelos exibidos na Figura

49 4.2 Estruturas de Dados (a) Exemplo Matriz HW (b) Exemplo Matriz WT Figura 4.5: Exemplo de duas Matrizes (a) Exemplo Modelo HW (b) Exemplo Modelo WT Figura 4.6: Exemplo dos modelos de rede social produzidos pela aplicação 37

50 4. Abordagem Proposta 4.3 Algoritmos Para processar os eventos em tempo real e construir os modelos do processo é necessário adaptar os algoritmos tradicionais de process mining. Para o modelo de controlo de fluxo, usa-se o Algoritmo 4.1. Basicamente, este algoritmo mantém um conjunto de estruturas de dados que vão sendo actualizadas à medida que surgem novos eventos. Como resultado, obtém-se uma matriz de probabilidades que pode ser representada de forma gráfica. Esta matriz contém a probabilidade de transição entre cada dois eventos. Algorithm 4.1 Controlo de Fluxo do processo em tempo real X é o conjunto de estados possíveis E(id) é a sequência de estados para a instância de processo id C é uma matriz e C(a, b) é o número de vezes que foi observada a transição do estado a para estado b P é uma matriz e P (a, b) é a probabilidade de transição do estado a para o estado b Para um novo evento (id, x, y, z) em que id é a instância do processo, x é o estado do evento, y é o actor que executa a acção e z é o timestamp da conclusão da execução da actividade if x / X then acrescentar o estado x à lista X criar a linha para x e a coluna para x nas matrizes C e P if id / E then criar uma nova lista E(id) com um único elemento que é o estado x else incrementar C(a, b) em que a é o último estado em E(id) recalcular a linha P (a, b) em que a é o último estado em E(id) e em que b são todos os estados possiveis acrescentar o estado x no fim da lista E(id) ordenar de forma ascendente E(id) tendo como critério z O algoritmo relativo ao Handover of Work, apresentado no Algoritmo 4.2, é similar ao que foi apresentado no de controlo de fluxo do processo. Este contém também um conjunto de estruturas de dados, que são actualizadas quando surgem novos eventos. Mas, neste caso em particular, em vez de produzir uma matriz de probabilidades, produz uma outra com a contabilização do número de tarefas transferidas entre os pares de actores e o respectivo fluxo. Esta matriz é posteriormente representada de forma gráfica. Foi também adaptado o algoritmo Working Together (ver algoritmo 4.3),de forma a processar even- 38

51 4.4 Pós-processamento Algorithm 4.2 Algoritmo Handover of Work Y é o conjunto de actores H(id) é a lista de actores que trabalham na instância do processo id C é uma matriz e C(a, b) é o número de vezes que foi observada a transferência de trabalho entre dois actores Para um novo evento (id, x, y, z) em que id é a instância do processo, x é o estado do evento e y é o actor que executa a acção e z é o timestamp da conclusão da execução da actividade if y / Y then acrescentar actor y à lista Y criar a linha para y e a coluna para y na matriz C if id / H then criar uma nova lista H(id) com um único elemento que é o actor y else incrementar C(a, b) em que a é o último actor em H(id) acrescentar o actor y no fim da lista H(id) tos em tempo real. A matriz M contém agora o número M(a, b), de casos em que o actor a trabalhou em conjunto com o actor b. Esta, pode ser representada de forma gráfica, como um gráfico não direccionado. Dado que a matriz é simétrica, basta considerar apenas o triângulo superior ou inferior, i.e., se a trabalhou em 20 casos com b, então é sabido que b trabalhou em 20 casos com a. 4.4 Pós-processamento À medida que os eventos são processados, com recurso aos algoritmos anteriormente apresentados, são produzidos novos modelos. Contudo, podem ser observadas instâncias de processo com um grande número de casos e uma elevada diversidade de comportamentos, obtendo-se assim, modelos extremamente confusos e, como tal, de difícil compreensão. Estes modelos são usualmente designados de spaghetti models (modelos esparguete). Para desbloquear esta situação, as técnicas de pré-processamento e pós-processamento, podem constituir duas formas de lidar com a questão referida. Relativamente à primeira solução, foram estas desenvolvidas e testadas, para resolver este problema, como se pode constatar em [25],. No artigo previamente mencionado, a abordagem seguida, passou por remover do log de eventos, estados (eventos) e sequências indesejados. As condições visadas foram as seguintes: (i) Tipo de evento, i.e., as actividades registadas no log MXML, represen- 39

52 4. Abordagem Proposta Algorithm 4.3 Algoritmo Working Together Y é o conjunto de actores conhecidos. W (id) é o conjunto de actores que participa na instância do processo id. Este conjunto não tem elementos repetidos e, são ordenados por nome. M é uma matriz e M(a, b) é o número de vezes que o actor a trabalhou com o actor b. Para cada novo evento (id, x, y, z) em que id é a instância do processo, x é o estado do evento e y é o actor que executa a acção e z é o timestamp da conclusão da execução da actividade if y / Y then acrescentar o actor y à lista Y. if id / W then criar uma novo conjunto W (id) if y / W (id) then acrescentar y ao conjunto W (id) ordenar conjunto W (id) for b W (id) if b y then incrementar M(y, b) incrementar M(b, y) tam as várias etapas do ciclo de vida das mesmas, como tal são só considerados os eventos do tipo complete; (ii) Frequência dos eventos, sendo removidos os eventos infrequentes ou que ocorrem com elevada frequência; (iii) Repetições consecutivas, sendo estas removidas, por exemplo: a sequência A B B C torna-se em A B C. (iv) Comprimento da sequência, limita o tamanho da sequência a uma determinada extensão e, (v) Frequência de sequências, à imagem do ponto ii, as sequências mais raras ou únicas serão descartadas. Todos estes limites, materializados através dos thresholds, são configuráveis pelo utilizador, antes de aplicar qualquer técnica de process mining, portanto, este pré-processamento efectua-se antes de gerar a matriz de transições entre estados. Relativamente às técnicas de pós-processamento, estas, permitem ao analista ajustar o modelo gerado à posteriori, i.e., é aplicado o mesmo tipo de thresholds, mas somente depois de já se terem efectuado os cálculos da matriz de transições. Assim, à medida que os modelos vão sendo gerados, o utilizador pode impor determinados limites, sendo estes automaticamente reflectidos no modelo seguinte. Com isto, é permitido ao analista, ajustar o que é apresentado no modelo gráfico através da remoção de elementos indesejados. Na Figura 4.7, é exemplificado o que foi descrito anteriormente. Neste exemplo, observam-se ini- 40

53 4.5 Implementação Figura 4.7: Exemplo da aplicação de thresholds cialmente três estados A, B e C e respectivas transições entre eles. Aplicando um threshold de 25 T = 25 verifica-se que é gerado um modelo com um valor de transições superiores ao especificado. 4.5 Implementação Esta secção oferece uma perspectiva mais técnica, sobre as ferramentas e tecnologias que foram usadas para implementar a abordagem proposta. Assumindo que os dados dos eventos estão armazenados numa base de dados relacional, os dois únicos métodos para extrair os dados são através de um trigger ou de uma consulta periódica à base de dados. Na abordagem do presente trabalho, optou-se por uma consulta à base de dados, de forma a não comprometer o desempenho do sistema. Os dados são retornados, com o seguinte formato: identificador de instância de processo, nome do actor, timestamp da conclusão da actividade e nome da actividade, representando estas, as informações necessárias para realizar process mining. A condição desenvolvida para reconhecer a existência de novos eventos, prende-se com a última data de execução do evento recolhido, armazenada no registo do Windows (Windows Registry). Caso se confirme a presença de novos eventos, estes são enviados para uma fila de mensagens privada do sistema Microsoft Message Queue (vulgarmente denominado MSMQ), exibindo uma interface como a que está patente na Figura 4.8. As mensagens são codificadas como Unicode, para que todos os caracteres sejam reconhecidos, sem que ocorra qualquer perda de caracteres relevantes. Como o mecanismo de comunicação entre a ferramenta concebida neste trabalho e o sistema de fila de mensagens funciona sobre um modelo assíncrono (callback), as novas, logo que são recebidas na fila de mensagens, invoca um adaptador, que está continuamente à escuta de novas mensagens, obtendo assim a mensagem para a qual foi invocada. O evento, posteriormente é convertido para um objecto (efectivado no componente Parser), especificamente criado para guardar as informações do evento. Este objecto é enviado para o motor Esper (ver secção 3.4), que está configurado para despoletar os restantes módulos da aplicação, por cada novo evento que receba, através da instrução EPL, 41

54 4. Abordagem Proposta Figura 4.8: Fila de Mensagens da aplicação representada no Algoritmo 4.4. As expressões EPL têm de ser configuradas para que apenas sejam recebidos e processados os eventos subscritos. Foi para tal utilizado como base o padrão Observer (ver secção 3.3), de forma a subscrever só os eventos que são essenciais. Na Figura 4.9 encontra-se um exemplo de como o padrão Observer é adaptado para este trabalho. Cada um dos Listeners corresponde a uma expressão EPL. O método Update Listener, depois de verificada alguma expressão como verdadeira é invocado, sendo enviado posteriormente para o(s) subscritores(s), o(s) evento(s) respectivo(s). Os subscritores são materializados em três módulos, a saber: (i) Controlo de Fluxo, (ii) Handover of Work e (iii) Working Together. Cada um destes módulos, após receber novos eventos, e através dos algoritmos referidos na secção 4.3, efectua o processamento, actualizando as estruturas de dados (descritas na secção 4.2) e, por último, faz a tradução das referidas estruturas para modelos gráficos. De sublinhar que os modelos produzidos, são actualizados, sendo apresentado o resultado ao utilizador, sempre que seja recebido um novo evento na ferramenta desenvolvida no presente trabalho. Como é exibido no algoritmo 4.4, apenas é despoletada qualquer acção quando se verifica a condição o número de eventos na janela, referido como NumEventos é igual ao especificado pelo utilizador num ficheiro de configuração XML. Esse ficheiro pode ser alterado, quando a aplicação está a correr, sendo estas alterações imediatamente reflectidas no funcionamento desta. A escolha do comando recaiu sobre o length batch, pelo facto de se traduzir numa janela de eventos, com um número específico destes, em detrimento de uma janela que captura eventos num determinado intervalo de tempo. Este comando, permite assim, obter um maior controlo sobre os eventos processados. A tradução de estruturas de dados para a visualização gráfica, efectua-se através da ferramenta 42

55 4.5 Implementação Figura 4.9: Observer Pattern Algorithm 4.4 Instrução EPL h SELECT FROM log. win : l e n g t h b a t c h ( +NumEventos+ ) GraphViz 1, necessitando para tal, de converter as matrizes para a linguagem Dot, fornecendo esses dados à referida ferramenta, onde automaticamente é produzido um modelo. Para que se obtenha uma percepção em tempo real sobre o comportamento da ferramenta, foi implementado também um componente que produz logs de eventos à medida que é efectuado o processamento, recorrendo para tal à tecnologia Log4Net. A ferramenta desenvolvida neste trabalho foi implementada na Linguagem C# e foi utilizada a API NEsper, para implementar o motor Esper

56 4. Abordagem Proposta 4.6 Conclusão Foi apresentada neste capítulo, uma visão global dos aspectos técnicos intrínsecos ao desenvolvimento desta ferramenta. Como foi referido, os algoritmos tradicionais aplicados de process mining, tratam de logs de eventos históricos, pelo que foi necessário fazer uma adaptação destes para o processamento de eventos em tempo real. Estes algoritmos, foram implementados na ferramenta descrita neste trabalho, sendo uma das principais contribuições aqui apresentada. 44

57 5 Caso de Estudo Conteúdos 5.1 Descrição do Processso Implementação do Processo em BizAgi Execução do Processo Extracção do log de eventos Monitorização do processo em tempo real Conclusão

58 5. Caso de Estudo Neste capítulo, será descrito o caso de um processo que se pretende que seja um exemplo realista da aplicação da abordagem proposta. Será apresentada uma descrição geral do processo, ao que se seguirá a respectiva implementação, utilizando uma ferramenta comercial, existente no mercado. O processo executado neste ferramenta, gera um log de eventos que é passível de ser processado em tempo real. O objectivo último deste processamento, é fornecer ao analista os modelos de controlo de fluxo e de rede social que são construídos à medida que surge cada evento. No entanto, para que isto aconteça, é necessário ter uma forma de extrair os eventos do sistema, um problema que também será abordado em detalhe neste capítulo. 5.1 Descrição do Processso É, nesta secção, elaborada uma exposição concisa de um processo de exemplo, relativo a um conjunto de actividades executadas para aquisição de produtos. O modelo BPMN, na Figura 5.1, indica as actividades que se encontram no domínio deste processo. A actividade inicial que despoleta o processo em análise é o preenchimento de uma requisição. Esta requisição tem a informação relativa ao produto que se pretende encomendar, bem como a quantidade, entre outros atributos necessários ao processamento da mesma. Em seguida, o documento tem de ser validado actividade aprovar requisição pelo gestor responsável. Caso a requisição seja aprovada, então o produto é encomendado. Segue-se a realização do pagamento pelo departamento de contabilidade e, em paralelo, a nível do armazém, a mercadoria é registada como recebida e actualizado o stock dos produtos recebidos. Por último, o departamento de contabilidade fecha a requisição. Caso a requisição não receba a aprovação, então o documento é arquivado, de forma a manter um histórico de requisições. Figura 5.1: BPMN do Caso de estudo 1 46

59 5.2 Implementação do Processo em BizAgi A execução deste processo dá origem a um log de eventos semelhante ao que é apresentado na Figura 5.2. No log, identificam-se as principais informações que são necessárias para efectuar process mining, a saber: identificador da instância do processo, nome da actividade, nome do actor e o timestamp da conclusão da execução da actividade. É a partir deste log de eventos que se podem extrair os modelos de controlo de fluxo e de rede social associados a este processo. Caso Actividade Utilizador timestamp 123 Preencher Requisição Ana : Aprovar Requisição Mariana : Requisiçao Aprovada? Pedro : Encomendar Produto João : Receber Mercadoria Mariana : Figura 5.2: Exemplo de um log de eventos 5.2 Implementação do Processo em BizAgi É nesta secção, explicado o processo de modelação e execução de um processo na ferramenta BizAgi (ver secção 2.3). O primeiro passo neste processo, consiste na modelação do processo de negócio, tal como mostra a Figura 5.1. No segundo passo, criam-se os atributos, entidades e relações entre estas últimas. No caso de estudo apresentado no presente trabalho, tem-se uma entidade Purchase com vários atributos, como se pode visualizar na Figura 5.3. O utilizador, para conseguir interagir com o sistema, necessita de uma interface que possibilite a comunicação entre o sistema e interacções externas. Para tal, é necessário criar/parametrizar dois componentes: modelos de dados e os formulários. Para que o processo se torne o mais realista possível, optou-se por alguns atributos que se observam em muitos dos sistemas actuais, e que serão em seguida enumerados e descritos. Aprovado 2 : um atributo essencial no processo, uma vez que possibilita ao decisor identificar se é um pedido de mercadoria válido. DataPedido: Permite identificar qual a data do pedido a efectuar. Fornecedor: Permite indicar qual o fornecedor ao qual se pretende efectuar o pedido de mercadoria. 1 Exemplo adaptado de Ferreira, D.R.: Mineração de processos - o elo que faltava na gestão de processos de negócio (Junho 2010), Marabá, Pará, Brasil, palestra realizada por ocasião do VI Simpósio Brasileiro de Sistemas de Informação (SBSI 2010) 2 Estes atributos são do tipo boolean. 47

60 5. Caso de Estudo IdProduto: Identifica qual o produto que se pretende encomendar. PrecoTotal: Informação relativa ao preço total dos produtos pedidos. PrecoUnitario: Informação relativa ao preço de cada produto individual. Pago 2 : Permite verificar se a factura foi paga ou não. QuantidadeProd: Indica qual a quantidade a pedir por cada produto. Recebida 2 : Indica se a mercadoria já foi recebida ou não. Figura 5.3: Modelo de Dados O terceiro passo, consiste na construção de interfaces de utilizador, tal como é apresentado na Figura 5.4, sendo utilizados os atributos criados anteriormente. Figura 5.4: Exemplo de Construção de Interfaces Em seguida, são definidas as regras de negócio que permitem indicar qual o caminho a seguir no processo em questão, sendo apresentado na Figura 5.5 um exemplo de regras de negócio. Neste caso, a regra diz que o caminho a seguir quando o gestor não aprovar a requisição, esta será arquivada. 48

61 5.2 Implementação do Processo em BizAgi Figura 5.5: Exemplo Regras de Negócio No quarto passo, são definido(s) o(s) recurso(s) que desempenha(m) cada actividade individual, tal como é demonstrado na Figura 5.6, onde se verifica que a condição é o da identificação entre os recursos Mariana e João, do primeiro que estiver disponível para a actividade Preencher Requisição. Figura 5.6: Exemplo atribuição de tarefas a recursos Quando se definem os recursos, também é necessário especificar a hierarquia, bem como as localizações e departamentos/áreas da organização, sendo exibido na Figura 5.7 as especificações efectuadas para o processo em apreciação. Verifica-se que existem três áreas: (i) Contabilidade, (ii) Operacional e (iii) Gestão. Em cada uma das áreas estão atribuídos os actores que tem permissões para executar determinadas tarefas, sendo estas específicas à posição a que estão associados. 49

62 5. Caso de Estudo Figura 5.7: Configuração dos recursos como membros da organização Nesta fase, é possível escolher o método de atribuição, tendo como opções: pela (i) carga, (ii) todos, (iii) sequencial e o (iv) primeiro disponível. Relativamente à carga, esta significa que a tarefa vai ser atribuída ao actor que apresentar uma cargo de trabalho inferior. Na opção todos, tal como indica a designação, efectua a atribuição da tarefa a todos os actores configurados para executar a mesma. Em relação ao terceiro ponto (sequencial), a tarefa é imputada de acordo com o historial de execução de actividades, i.e., se tivermos dois actores (1) João e (2) Diogo, se o João já tiver executado uma tarefa, então da próxima vez a mesma tarefa vai ser executada pelo Diogo. Por último, o ponto primeiro disponível refere-se ao actor, numa lista de actores de uma determinada tarefa, que se apresente imediatamente disponível para executar a actividade. Como último passo, é a execução do processo, através de uma aplicação Web, que apresentará a informação certa à pessoa certa no momento certo. Esta aplicação Web, pode ser executada em três ambientes distintos: (i) desenvolvimento, (ii) teste e (iii) produção. No caso de ser um ambiente de desenvolvimento, este não tem de fazer a instalação do processo criado ou alterações efectuadas (tal como acontece para os restantes ambientes), quando pretende testar o referido processo. É neste ambiente que são modelados os processos, tal como o modelo de dados, e onde se criam também os formulários e regras de negócio O ambiente de teste permite simular o ambiente de produção, sendo utilizado para efectuar os testes de aceitação das funcionalidades do processo desenvolvido. Por último, o ambiente de produção, representa o ambiente de operação real, onde os processos são executados efectivamente pelos actores a quem se destina a execução das actividades. Posteriormente, no backoffice da aplicação Web, é necessário criar utilizadores (nome e dados de autenticação) e já dentro de aspectos organizacionais, definir quais os cargos de responsabilidade a 50

63 5.3 Execução do Processo atribuir, papéis e área de acção, tendo estas configurações sido criadas num passo anterior. Com esta configuração no backoffice, é pretendido que se estabeleça uma relação entre os actores criados na aplicação Web com as especificações realizadas no BizAgi Studio (papéis, cargos, entre outras), para que nos eventos apareçam os nomes dos actores que realmente executam as tarefas e não o actor admon, que é quem executa todas as actividades dos processos por defeito. 5.3 Execução do Processo O processo é despoletado através do preenchimento do formulário de pedido de novos produtos. No processo em questão, os colaboradores cuja função está ao nível operacional são notificados, tal como se mostra na Figura 5.8, quando um colaborador, com privilégios de administrador, inicia um novo processo. Figura 5.8: Aviso de tarefa pendente Ao abrir a tarefa, será apresentado ao utilizador uma interface, que, terá que preencher com a informação respectiva para o perfil do colaborador, tal como é demonstrado na Figura 5.9. Na Figura referida, verifica-se que o actor, no caso em particular o gestor, tem de tomar uma decisão se irá aprovar ou não o pedido de requisição de mercadoria, o que, se for favorável, é realizada a encomenda do produto, e no caso inverso é arquivado o pedido. De salientar que cada actor, tem de se autenticar no sistema, para poder visualizar as tarefas que lhe foram atribuídas e dessa feita, executá-las. Figura 5.9: Exemplo preenchimento de formulário de actividade 51

64 5. Caso de Estudo Os eventos que vão sendo gerados durante a execução, são registados num log de eventos, apresentado na Figura Figura 5.10: Log de Eventos produzido no BizAgi De salientar, para que o processo avance nas actividades, é obrigatório que exista interacção do sistema com o utilizador. 5.4 Extracção do log de eventos Durante a execução do processo é possível extrair os eventos que vão sendo gerados, para tal, recorre-se a uma consulta periódica à base de dados do BizAgi, que é suportado por uma base de dados Sql Server 2008 que regista todas as informações relativas aos processos. Para extrair informação dos eventos do sistema BizAgi, foi necessário realizar uma análise minuciosa sobre a base de dados do BizAgi. Existe um conjunto muito vasto de tabelas, sendo só algumas consideradas importantes para a aplicação desenvolvida neste trabalho. Na Figura 5.11, é apresentado um modelo relacional das tabelas mais adequadas para o process mining a realizar. Pode ser observado que a tabela WFCASE está directamente relacionada com a maioria das outras tabelas, pelo facto de que regista a primeira actividade executada no processo, bem como o actor que realizou essa tarefa e o identificador de instância do processo, para além de outras informações, que não se aplicam neste trabalho, tais como a duração da execução da actividade, o timestamp do inicio da execução da actividade, entre outras. A tabela que armazena os dados referentes a todas as actividades realizadas para uma determinada instância de processo é a WORKITEM. Os dados que mais importa extrair desta tabela são: o identificador da instância de processo, as tarefas executas para cada instância, os actores envolvidos e o timestamp de conclusão das actividades. A tabela anteriormente mencionada estabelece relação de forma directa ou indirecta com as tabelas seguintes: (i) CURRENTASSIGNEE, efectua uma 52

65 5.4 Extracção do log de eventos Figura 5.11: Modelo Relacional das tabelas seleccionadas associação entre o identificador de cada actividade e o actor que a executou. O identificador permite fazer a relação entre esta e a tabela WORKITEM. Esta tabela permite também que se constitua a associação entre as tabelas WORKITEM e WFUSER; (ii) A tabela WFUSER, armazena a informação referente a cada actor. Esta tabela está ligada à WFCASE, através do identificador único do actor. Este último, possibilita a obtenção do nome do actor envolvido na execução de cada actividade; (iii) A tabela TASK, armazena uma lista das actividades referentes a cada um dos processos, bem como as informações que lhe estão associadas, i.e, identificador único, descrição, nome, entre outras. Esta estabelece relações com as tabelas WFCASE e WORKITEM, através do identificador único da actividade. Através desta associação directa, utilizando o identificador da actividade, é possível obter o nome das tarefas, informação necessária para a ferramenta desenvolvida neste trabalho. Contudo as tabelas WFCASE e CURRENTASSIGNEE não foram aplicadas neste trabalho, porque não forneciam os dados necessários para posteriormente efectuar uma análise de process mining correcta. No primeiro caso, mais concretamente por apresentar um custo mais elevado em termos de tempo de 53

66 5. Caso de Estudo processamento e utilização mais acentuada dos recursos computacionais, i.e, esta tabela, como foi mencionado anteriormente, só regista a primeira actividade executada por cada instância de processo, por conseguinte, seria necessário estar sempre a analisar todas as instâncias armazenadas, para verificar se alguma nova actividade foi realizada. Relativamente à CURRENTASSIGNEE, esta não regista todos os identificadores de actividades - designados como idworkitem executados e portanto, não fornece uma completude de dados exigida para a análise ser o mais real e precisa possível. Por este conjunto de motivos, a tabela seleccionada, que mais se adequou ao trabalho exigido, designa-se de WISTATELOG, sendo esta apresentada na Figura Esta tabela, permite obter os utilizadores que executam as actividades, registando também os tipos de actividades onde se toma uma decisão, mais vulgarmente conhecidos como Gateways ou pontos de decisão. Figura 5.12: Tabela WISTATELOG Existe uma tabela principal WORKITEM que regista uma grande parte dos dados necessários, sendo que, através do identificador único idworkitem é possível obter o identificador do actor que executou a actividade WISTATELOG e, através deste, extrair o nome do actor WFUSER. Como a tabela WORKITEM facilita o identificador da tarefa, é possível adquirir o nome da actividade TASK. Relativamente à consulta periódica referida no início da presente secção, esta é apresentada no Algoritmo 5.1, onde se observa que é reunida a informação necessária para realizar o process mining através de quatro tabelas, sendo elas o WISTATELOG, WORKITEM, WFUSER e TASK. Destas são extraídos os dados relativos à instância do processo (coluna idcase), timestamp da execução da actividade (coluna timestamp), nome do actor que executou a actividade (coluna username) e o nome da actividade (coluna taskname). Esta consulta, é efectuada a cada cinco segundos, ficando registada a data de execução da última actividade recebida na ferramenta desenvolvida no presente trabalho, sendo a partir desta que se verifica se existem novos eventos. Este conjunto de dados, depois de ser agregado, é ordenado por data de execução. 54

67 5.5 Monitorização do processo em tempo real Algorithm 5.1 query sql para retornar os últimos eventos registados no BizAgi SELECT DISTINCT WI. idcase as idcase, WFUsr. fullname as username, WI. w i s o l u t i o n D a t e as timestamp, Tsk. tskdisplayname as taskname FROM [ D e f a u l t B i z A g i P r o j e c t ]. [ dbo ]. [ WISTATELOG] as WISL, [ D e f a u l t B i z A g i P r o j e c t ]. [ dbo ]. [ WORKITEM] as WI, [ D e f a u l t B i z A g i P r o j e c t ]. [ dbo ]. [ WFUSER] as WFUsr, [ D e f a u l t B i z A g i P r o j e c t ]. [ dbo ]. [ TASK] as Tsk WHERE WISL. idworkitem = WI. idworkitem AND WI. idtask = Tsk. idtask AND WISL. iduser = WFUsr. iduser AND Tsk. tskdisplayname IS NOT NULL AND WI. w i s o l u t i o n D a t e >? ORDER BY WI. w i s o l u t i o n D a t e 5.5 Monitorização do processo em tempo real Nesta secção serão apresentados os resultados produzidos pela ferramenta desenvolvida na presente dissertação. De referir que foi realizada uma criteriosa selecção de modelos em três fases distintas de processamento (inicial, intermédia e final), num determinado intervalo de tempo, de forma a realçar as diferenças, durante o processamento dos eventos em tempo real. Nesta análise foram processados 91 eventos e 8 instâncias. A interface de utilizador oferecida pela ferramenta desenvolvida no presente trabalho, pode ser observada na Figura A interface anteriormente referida, apresenta ao utilizador três painéis independentes entre si, que permitem a visualização dos modelos de process mining CF, WT e HW que vão sendo gerados ao longo do processamento efectuado pela ferramenta desenvolvida. Outras funcionalidades oferecidas pela ferramenta, a saber: Event Data, onde é possível observar algumas estatisticas, bem como os dados do último evento processado. Threshold, painel que permite ajustar os modelos de acordo com as necessidades do utilizador, i.e., se o utilizador preferir visualizar um modelo onde não constam valores inferiores aos que deseja, basta configurar o painel com as configurações que mais se adequam às suas necessidades. Por defeito, todos os valores são exibidos. A necessidade deste painel justifica-se, pelo 55

68 5. Caso de Estudo facto de que à medida que se vão processando os eventos, o modelo vai ficando gradualmente mais confuso e de difícil compreensão, tal como é referido e justificado na secção 4.4. Os valores no caso do CF estão compreendidos entre 0 100%, já os valores relativos aos modelos de HW e WT estão compreendidos entre 0 100, sendo a unidade referente aos edges entre actores. Matrices Comparison (Figura 5.14), que é apresentado como um botão verde no canto inferior esquerdo de cada painel de modelo, permite efectuar comparações entre matrizes. Figura 5.13: Interface Aplicacional Uma das utilidades desta ferramenta é a rastreabilidade, por manter em memória as matrizes que são geradas ao longo do seu funcionamento, o que permite também fazer a comparação entre diferentes matrizes, tal como é demonstrado na Figura

Oracle BPM 11g. Análise à Plataforma

Oracle BPM 11g. Análise à Plataforma Oracle BPM 11g Análise à Plataforma Maio de 2010 Tive o privilégio de ser convidado a participar no "EMEA BPM 11g beta bootcamp" em Abril de 2010, no qual tive contacto mais próximo com a última versão

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação O Business Analytics for Microsoft Business Solutions Navision ajuda-o a ter maior controlo do seu negócio, tomar rapidamente melhores decisões e equipar os seus funcionários para que estes possam contribuir

Leia mais

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS WORKFLOW Mapeamento de Processos de Negócio Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS É proibido a reprodução total ou parcial de qualquer forma ou por qualquer meio sem a expressa autorização

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Extracto on Line Aplicação Local Guia do Utilizador

Extracto on Line Aplicação Local Guia do Utilizador Extracto on Line Aplicação Local Guia do Utilizador Índice 1. Sobre o Guia... 4 1.1 Objectivo... 4 1.2 Utilização do Guia... 4 1.3 Acrónimos e Abreviações... 4 2. Introdução ao Extracto on Line Aplicação

Leia mais

Enunciado do Projecto

Enunciado do Projecto C O M P U T A Ç Ã O M Ó V E L 2 0 0 7 / 2 0 0 8 Enunciado do Projecto 17 de Março de 2008 1. Objectivos Desenvolver uma aplicação num domínio aplicacional específico que envolva replicação e sincronização

Leia mais

5.7.6 Internet/Intranet 176 5.7.7 Gestão logística 177 CAPÍTULO 6. DESENVOLVIMENTO DE SISTEMAS DE WORKFLOW 181 6.1 Métodos de Desenvolvimento 181

5.7.6 Internet/Intranet 176 5.7.7 Gestão logística 177 CAPÍTULO 6. DESENVOLVIMENTO DE SISTEMAS DE WORKFLOW 181 6.1 Métodos de Desenvolvimento 181 SUMÁRIO SUMÁRIO PREFÁCIO AGRADECIMENTOS VII XI XIII INTRODUÇÃO CAPÍTULO 1. ORGANIZAR WORKFLOWS 1 1.1 Ontologia da gestão de workflows 1.2 Trabalho 1 1 1.3 Processos de Negócio 3 1.4 Distribuir e Aceitar

Leia mais

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem:

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem: Descrição de Serviços Serviços de Planeamento e Empresarial Os Serviços de Planeamento e Empresarial fornecem serviços de consultoria e prototipagem para facilitar a agenda do Licenciado relativa à inovação

Leia mais

Bases de Dados. Bibliografia. 1. Parte I Componente Teórica. Pedro Quaresma

Bases de Dados. Bibliografia. 1. Parte I Componente Teórica. Pedro Quaresma Índice Bases de Dados Pedro Quaresma Departamento de Matemática Universidade de Coimbra 2010/2011 1. Parte I Componente Teórica 1.1 Introdução 1.2 Modelo ER 1.3 Modelo Relacional 1.4 SQL 1.5 Integridade

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Arquitecturas de Sistemas de Informação

Arquitecturas de Sistemas de Informação Arquitecturas de Sistemas de Informação Arquitectura Tecnológica Arquitectura Tecnológica O que é: É a escolha dos tipos de tecnologia que devem ser utilizados para dar suporte a cada um dos sistemas e

Leia mais

Tecnologias de Informação

Tecnologias de Informação Sistemas Empresariais Enterprise Resource Planning (ERP): Sistema que armazena, processa e organiza todos os dados e processos da empresa de um forma integrada e automatizada Os ERP tem progressivamente

Leia mais

SOA 2.0 ou Event-Driven SOA

SOA 2.0 ou Event-Driven SOA SOA SOA 2.0 ou Event-Driven SOA 1 Introdução Recentemente, a Oracle anuciou o termo SOA 2.0. E já deu para imaginar a repercussão que isto teve. Estamos em um momento onde SOA (Service-Oriented Architecture),

Leia mais

PALAVRAS CHAVE RESUMO

PALAVRAS CHAVE RESUMO ESIG2001 SPATIAL INTELLIGENCE INFORMAÇÃO GEOGRÁFICA COMO MEIO DE SUPORTE À DECISÃO João Machado Costa, Rui Marques Ferreira Novabase www.novabase.pt joao.machado@novabase.pt PALAVRAS CHAVE Spatial Information

Leia mais

Extracção e Avaliação de Fluxo de Processos. Engenharia de Informática e Computadores

Extracção e Avaliação de Fluxo de Processos. Engenharia de Informática e Computadores Extracção e Avaliação de Fluxo de Processos Pedro Miguel dos Santos Martins Dissertação para obtenção do Grau de Mestre em Engenharia de Informática e Computadores Presidente: Orientador: Vogal: Prof.

Leia mais

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD) Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS. As dinâmicas de grupo e os perfis de consumo

COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS. As dinâmicas de grupo e os perfis de consumo COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS As dinâmicas de grupo e os perfis de consumo O uso de perfis na empresa Os perfis são conjuntos de dados que caracterizam categorias de indivíduos destinados a serem

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Universidade do Minho Licenciatura em Engenharia Informática

Universidade do Minho Licenciatura em Engenharia Informática Universidade do Minho Licenciatura em Engenharia Informática Disciplina de Desenvolvimento de Sistemas de Software Trabalho Prático Fase 1 Ano Lectivo de 2009/10 GereComSaber Grupo 15 Cláudio Manuel Rigueiro

Leia mais

Unified Software Development Process

Unified Software Development Process 59/170 Unified Software Development Process Sumário Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unified Process) 60/170 Breve História do Unified

Leia mais

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos.

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. 1. Introdução aos Sistemas de Bases de Dados Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. O conceito de base de dados faz hoje parte do nosso

Leia mais

ILM e as Arquitecturas Empresariais por Pedro Sousa

ILM e as Arquitecturas Empresariais por Pedro Sousa ILM e as Arquitecturas Empresariais por Pedro Sousa Neste artigo clarifica-se os objectivos do ILM (Information Life Cycle Management) e mostra-se como estes estão dependentes da realização e manutenção

Leia mais

Processo de análise estruturada - Abordagem clássica

Processo de análise estruturada - Abordagem clássica Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo

Leia mais

Aula Prática #1. Sumário Aula #1. Modelo de avaliação Apresentação do Projecto

Aula Prática #1. Sumário Aula #1. Modelo de avaliação Apresentação do Projecto Aula Prática #1 SEI 2004/2005 DEI, LEIC Taguspark Instituto Superior Técnico SEI 2004/2005 - DEI, IST [Artur Caetano] 2 Sumário Aula #1 Modelo de avaliação Apresentação do Projecto Objectivos Metodologia

Leia mais

TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO ACCESS 2010 Conceitos Básicos Ficha Informativa Professor : Vanda Pereira módulo didáctico Conceitos Básicos Necessidade das base de dados Permite guardar dados

Leia mais

Modelação dos mecanismos de controlo de acesso numa arquitectura empresarial

Modelação dos mecanismos de controlo de acesso numa arquitectura empresarial Modelação dos mecanismos de controlo de acesso numa arquitectura empresarial Tópicos de Investigação, MEIC, 27/01/2011 Ricardo Martins, 55391 Agenda Enquadramento e problema Objectivos e perguntas de investigação

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA Sandra CARVALHO 1, Pedro GALVÃO 2, Cátia ALVES 3, Luís ALMEIDA 4 e Adélio SILVA 5 RESUMO As empresas de abastecimento de água gerem diariamente

Leia mais

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

Ricardo Gomes Clemente. Uma arquitetura para processamento de eventos de log em tempo real. Dissertação de Mestrado

Ricardo Gomes Clemente. Uma arquitetura para processamento de eventos de log em tempo real. Dissertação de Mestrado 1 Ricardo Gomes Clemente Uma arquitetura para processamento de eventos de log em tempo real Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo

Leia mais

OCL: Object Constraint Language

OCL: Object Constraint Language OCL: Amílcar Domingos Rodrigues Santy Fernandes, Girson César Silva Monteiro, Rui Sá Guerra, Simão Castro Faculdade de Engenharia da Universidade Do Porto, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

Leia mais

GESTÃO. Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) CLF

GESTÃO. Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) CLF GESTÃO Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) Informação e Decisões Gerir envolve tomar muitas e frequentes decisões Para decidir com eficácia

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite

Leia mais

Relatório Técnico do projecto ARIADNE. Interface de utilizador do NewsSearch

Relatório Técnico do projecto ARIADNE. Interface de utilizador do NewsSearch Relatório Técnico do projecto ARIADNE Praxis XXI Interface de utilizador do NewsSearch Carlos Correia Norman Noronha Daniel Gomes Junho de 2000 Índice 1. INTRODUÇÃO...3 1.1 MOTIVAÇÃO...3 1.2 PROPOSTO...3

Leia mais

O desafio de uma visão mais ampla

O desafio de uma visão mais ampla com SAP NetWeaver BPM Descrição de Solução A competição acirrada tem levado as organizações a adotar novas disciplinas de gestão e empregar recursos tecnológicos avançados, a fim de atingir melhores índices

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G Escola Superior de Gestão de Santarém Pedido de Registo do CET Instalação e Manutenção de Redes e Sistemas Informáticos Peça Instrutória G Conteúdo programático sumário de cada unidade de formação TÉCNICAS

Leia mais

An enterprise distributed system

An enterprise distributed system An enterprise distributed system 2º Trabalho Prático Tecnologias de Distribuição e Integração 4º Ano do Mestrado Integrado em Engenharia Informática e Computação João Carlos Figueiredo Rodrigues Prudêncio

Leia mais

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Capítulo 7 Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Liliana Ferreira, António Teixeira e João Paulo da Silva Cunha Luís Costa, Diana Santos e Nuno

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Gestão Total da Manutenção: Sistema GTM

Gestão Total da Manutenção: Sistema GTM Gestão Total da Manutenção: Sistema GTM por Engº João Barata (jbarata@ctcv.pt), CTCV Inovação Centro Tecnológico da Cerâmica e do Vidro 1. - INTRODUÇÃO Os sub-sistemas de gestão, qualquer que seja o seu

Leia mais

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction Bases de Dados II 6638: BSc in Information Systems and Technologies Cap. 1 Module Introduction Objectivos O propósito e a origem da arquitectura de base de dados a três níveis. O conteúdo dos níveis externo,

Leia mais

Bases de Dados! 2014/15! http://ssdi.di.fct.unl.pt/bd!! João Leite (jleite@fct.unl.pt)!!!

Bases de Dados! 2014/15! http://ssdi.di.fct.unl.pt/bd!! João Leite (jleite@fct.unl.pt)!!! Bases de Dados 2014/15 http://ssdi.di.fct.unl.pt/bd João Leite (jleite@fct.unl.pt) Capítulo 1: Introdução Função dos Sistemas de Bases de Dados Visão dos dados Modelos de dados Linguagem de Definição de

Leia mais

PÓS-GRADUAÇÃO Lato Sensu. Gestão e Tecnologia da Informação

PÓS-GRADUAÇÃO Lato Sensu. Gestão e Tecnologia da Informação IETEC - INSTITUTO DE EDUCAÇÃO TECNOLÓGICA PÓS-GRADUAÇÃO Lato Sensu Gestão e Tecnologia da Informação BAM: Analisando Negócios e Serviços em Tempo Real Daniel Leôncio Domingos Fernando Silva Guimarães Resumo

Leia mais

PROJECTO DE NORMA REGULAMENTAR

PROJECTO DE NORMA REGULAMENTAR PROJECTO DE NORMA REGULAMENTAR Princípios aplicáveis ao desenvolvimento dos Sistemas de Gestão de Riscos e de Controlo Interno das Empresas de Seguros As melhores práticas internacionais na regulamentação

Leia mais

Software para Controlo de Assiduidade

Software para Controlo de Assiduidade Innux Time O cenário de constante mudança que caracteriza o mercado globalizado tem um impacto profundo na forma como as empresas gerem os seus recursos humanos. Reduzir custos, aumentar os níveis de desempenho,

Leia mais

PHC Workflow CS. O controlo e a automatização de processos internos

PHC Workflow CS. O controlo e a automatização de processos internos PHC Workflow CS O controlo e a automatização de processos internos A solução que permite que um conjunto de acções a executar siga uma ordem pré-definida, de acordo com as normas da empresa, aumentando

Leia mais

De Arte a Ciência: Regras para o Desenho de Software

De Arte a Ciência: Regras para o Desenho de Software De Arte a Ciência: Regras para o Desenho de Software Neste artigo é apresentado um conjunto de regras de desenho um padrão de desenho universal associado ao princípio fundamental e aos requisitos axiomáticos.

Leia mais

1. Contratos de aluguer automóvel

1. Contratos de aluguer automóvel 1. Contratos de aluguer automóvel Pretende-se desenvolver um Sistema Informático para apoio à gestão de Contratos de Aluguer automóvel de Longa-duração (SICAL) que permita efectuar, cancelar e modificar

Leia mais

.Net Remoting Pizzaria

.Net Remoting Pizzaria .Net Remoting Pizzaria 1º Trabalho Prático Tecnologias de Distribuição e Integração 4º Ano do Mestrado Integrado em Engenharia Informática e Computação João Carlos Figueiredo Rodrigues Prudêncio ei07111@fe.up.pt

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

A gestão de processos de negócio: conceitos e ferramentas BPM

A gestão de processos de negócio: conceitos e ferramentas BPM FACULDADE DE LETRAS DA UNIVERSIDADE DO PORTO A gestão de processos de negócio: conceitos e ferramentas BPM Trabalho realizado por: Ana Luisa Veiga Filipa Ramalho Doutora Maria Manuela Pinto GSI 2007 AGENDA:

Leia mais

Motor de Pesquisa Baseado na Web Semântica

Motor de Pesquisa Baseado na Web Semântica Motor de Pesquisa Baseado na Web Semântica Rui Gaspar, Ricardo Clemente {ruiandre, ricjorge}@student.dei.uc.pt Resumo: Com este projecto pretende-se desenvolver um motor de pesquisa, que implemente conceitos

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projectos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual Engenharia de Software Sistemas Distribuídos 2º Semestre, 2007/2008 Departamento Engenharia Informática Enunciado do projecto: Loja Virtual Fevereiro de 2008 Índice Índice...2 Índice de Figuras...3 1 Introdução...4

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

PHC Workflow. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa

PHC Workflow. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa PHCWorkflow DESCRITIVO O PHC Workflow permite que o conjunto de acções a executar, sigam uma ordem pré- -definida de acordo com as normas da empresa, aumentando a agilidade e produtividade dos colaboradores.

Leia mais

USE CASES: continuação

USE CASES: continuação USE CASES: continuação Balcão de Companhia Aérea Fazer Check-in de Passageiro Funcionário Inserir Reserva de Voo Cancelar Reserva de Voo Os primeiros diagramas de Use Case (DUC) de um Sistema, descrevem

Leia mais

WorkinProject 8 Manual de Referência Rápida

WorkinProject 8 Manual de Referência Rápida WorkinProject 8 Manual de Referência Rápida Flagsoft, Lda 2015 Índice 1. Introdução...3 2. Integrador - Interface com o utilizador...4 3. Registo de actividade - Folha de horas...5 4. Agenda e colaboração...7

Leia mais

PHC Workflow CS. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa

PHC Workflow CS. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa PHCWorkflow CS DESCRITIVO O PHC Workflow permite que o conjunto de acções a executar, sigam uma ordem pré- -definida de acordo com as normas da empresa, aumentando a agilidade e produtividade dos colaboradores.

Leia mais

Análise real de dados

Análise real de dados Análise real de dados Para tacógrafos analógicos e digitais www.siemensvdo.com 1 Maximize todas as potencialidades dos tacógrafos digitais Novas obrigações, novas opções de análise Para si e para a sua

Leia mais

Os Investigadores da Universidade de Coimbra e as plataformas

Os Investigadores da Universidade de Coimbra e as plataformas Os Investigadores da Universidade de Coimbra e as plataformas & 1 Índice 2 Introdução...3 3 A Plataforma de Curricula DeGóis...3 3.1 É utilizada porque...3 3.2 Com a utilização do DeGóis ganho...4 3.1

Leia mais

Análise da Arquitetura de Software

Análise da Arquitetura de Software Análise da Arquitetura de Software Essencial para Arquitetura de Software De que se trata o artigo? Apresenta o uso de requisitos arquiteturais na análise da arquitetura de software e a destaca no desenvolvimento

Leia mais

Grupo 34. Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software

Grupo 34. Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software Desenvolvimento de Sistemas de Software DSS - 2009/2010 Grupo 34 Guilherme Silva 47048 Rui Meira

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projetos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

3. Engenharia de Requisitos

3. Engenharia de Requisitos Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton)

Leia mais

Microsoft Access. Nível I. Pedro Fernandes

Microsoft Access. Nível I. Pedro Fernandes Microsoft Access Nível I Introdução Objectivos Introdução; Criar tabelas; Fazer consultas; Elaborar formulários; Executar relatórios. 2 Introdução aos Sistemas de Gestão de Bases de Dados (SGBD) Desde

Leia mais

Lisboa, 18 de Janeiro de 2004

Lisboa, 18 de Janeiro de 2004 Lisboa, 18 de Janeiro de 2004 Realizado por: o Bruno Martins Nº 17206 o Cátia Chasqueira Nº 17211 o João Almeida Nº 17230 1 Índice 1 Índice de Figuras... 3 2 Versões... 4 3 Introdução... 5 3.1 Finalidade...

Leia mais

Engenharia de Software. Enunciado da Primeira Parte do Projecto

Engenharia de Software. Enunciado da Primeira Parte do Projecto LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Engenharia de Software 2 o Semestre 2014/2015 Enunciado da Primeira Parte do Projecto 1. Primeira Parte do Projecto ES Este enunciado descreve o trabalho a realizar

Leia mais

Elsa Cardoso, DCTI - ISCTE

Elsa Cardoso, DCTI - ISCTE Elsa Cardoso, DCTI - ISCTE 25 Maio 2004 elsa.cardoso@iscte.pt Sumário Perspectiva de Desenho do Sistema: Diagrama de classes numa perspectiva de Desenho: Estereótipos Relação de Dependência Relação de

Leia mais

Ferramentas de Modelação e Análise de Sistemas baseadas em Redes de Petri (RdP)

Ferramentas de Modelação e Análise de Sistemas baseadas em Redes de Petri (RdP) Ferramentas de Modelação e Análise de Sistemas baseadas em Redes de Petri (RdP) Existem inúmeras ferramentas (software) baseadas em RdP que permitem desenvolver modelar e analisar sistema de RdP. Algumas

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 ASPECTOS DE MUDANÇA CULTURAL

Leia mais

Direcção Regional de Educação do Algarve

Direcção Regional de Educação do Algarve MÓDULO 1 Folha de Cálculo 1. Introdução à folha de cálculo 1.1. Personalização da folha de cálculo 1.2. Estrutura geral de uma folha de cálculo 1.3. O ambiente de da folha de cálculo 2. Criação de uma

Leia mais

E se conseguisse reduzir os seus custos de energia até 20%?

E se conseguisse reduzir os seus custos de energia até 20%? E se conseguisse reduzir os seus custos de energia até 20%? Uma solução eficaz de Gestão Energética para o Retalho Eficiência Energética no Retalho Será que está a gastar mais em energia do que necessita?

Leia mais

Computação Paralela. Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho.

Computação Paralela. Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho. Computação Paralela Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Outubro 2005 Desenvolvimento de Aplicações Paralelas Uma Metodologia

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

EXCEL. Listas como Bases de Dados

EXCEL. Listas como Bases de Dados Informática II Gestão Comercial e da Produção EXCEL Listas como Bases de Dados (TÓPICOS ABORDADOS NAS AULAS DE INFORMÁTICA II) Curso de Gestão Comercial e da Produção Ano Lectivo 2002/2003 Por: Cristina

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

As Ferramentas de SCM e o Suporte do CMM

As Ferramentas de SCM e o Suporte do CMM As Ferramentas de SCM e o Suporte do CMM Como é que as ferramentas de SCM (Software Configuration Management) podem ajudar na melhoria de processos de acordo com o modelo CMM (Capability Maturity Model)?

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

NOTIFICAÇÃO DE NEGÓCIO

NOTIFICAÇÃO DE NEGÓCIO NOTIFICAÇÃO DE NEGÓCIO O Microsoft Business Solutions for Supply Chain Management Navision Business Notification ajudao a gerir a sua empresa mais facilmente e eficazmente. Pode identificar qualquer problema

Leia mais

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023 DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 David Barbosa 47076 Ricardo Boas 47023 Rui Fonseca 47081 Vítor Martins 47121 GRUPO 10 2009/2010 1 Índice 1. Introdução... 2 1.1 Visão Geral do Problema... 2

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

Gestão de Processos de Negócio

<Insert Picture Here> Gestão de Processos de Negócio Gestão de Processos de Negócio Susana Santos Principal Sales Consultant Agenda Quais os Desafios Business Process Management Modelação Execução Interacção Humana Monitorização Resumo

Leia mais

7 Conclusões. 7.1 Retrospectiva do trabalho desenvolvido. Capítulo VII

7 Conclusões. 7.1 Retrospectiva do trabalho desenvolvido. Capítulo VII Capítulo VII 7 Conclusões Este capítulo tem como propósito apresentar, por um lado, uma retrospectiva do trabalho desenvolvido e, por outro, perspectivar o trabalho futuro com vista a implementar um conjunto

Leia mais

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 Segundo Exame 16 de Julho de 2010, 9:00H 11:30H (Versão A) Nome:

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Informática. Conceitos Básicos. Informação e Sistemas de Informação. Aula 3. Introdução aos Sistemas

Informática. Conceitos Básicos. Informação e Sistemas de Informação. Aula 3. Introdução aos Sistemas Informática Aula 3 Conceitos Básicos. Informação e Sistemas de Informação Comunicação Empresarial 2º Ano Ano lectivo 2003-2004 Introdução aos Sistemas A Teoria dos Sistemas proporciona um meio poderoso

Leia mais

manual instalação e configuração v13 1

manual instalação e configuração v13 1 manual instalação e configuração v13 1 Conteúdo Introdução... 3 Conteúdo do DVD:... 3 Instalação e configuração do ERP... 4 Instalação do ERP... 4 Configuração do ERP... 6 Como actualização de versão...

Leia mais

Guia de utilização. Acesso Universal

Guia de utilização. Acesso Universal Guia de utilização Março de 2009 Índice Preâmbulo... 3 Acesso à Plataforma... 4 Área de Trabalho... 5 Apresentar Propostas... 12 Classificar Documentos... 20 Submeter a Proposta... 21 Solicitação de Esclarecimentos/Comunicações...

Leia mais

PORQUÊ O PHC ENTERPRISE CS?

PORQUÊ O PHC ENTERPRISE CS? PORQUÊ O PHC ENTERPRISE CS? Um ERP, como qualquer software, pode vir em várias medidas. Quer se chamem soluções, serviços, formatos, ou gamas como no caso da PHC, existem diversas possibilidades para uma

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

ZS Rest. Manual de Iniciação. BackOffice

ZS Rest. Manual de Iniciação. BackOffice Manual de Iniciação BackOffice 1 1. Índice 2. Introdução... 2 3. Iniciar o ZSRest... 3 a) BackOffice:... 4 b) Acesso BackOffice:... 4 4. Zonas... 6 c) Criar Zona:... 7 d) Modificar Zona:... 8 e) Remover

Leia mais

Base de dados I. Base de dados II

Base de dados I. Base de dados II Base de dados I O que é? Uma base de dados é um simples repositório de informação, relacionada com um determinado assunto ou finalidade, armazenada em computador em forma de ficheiros Para que serve? Serve

Leia mais