Uma Infraestrutura para Registro e Notificação de Eventos No Ambiente

UNIVERSIDADE FEDERAL DO PAR
INSTITUTO DE CINCIAS EXATAS E NATURAIS

FACULDADE DE COMPUTAO
CURSO DE BACHARELADO EM CINCIA DA COMPUTAO
Leandro Bezerra Coutinho
Uma Infraestrutura para Registro e Notificao de Eventos no

Ambiente WebAPSEE 2.0
Belm
2011


Trabalho
de
Concluso
de
Curso
apresentado para obteno do grau de

Bacharel em Cincia da Computao.
Orientador: Prof. Dr. Rodrigo Quites Reis.
Belm
2011


Trabalho
de
Concluso
de
Curso
apresentado para obteno do grau de

Bacharel em Cincia da Computao.
Orientador: Prof. Dr. Rodrigo Quites Reis.
Data da defesa: ___ de Dezembro de 2011.

Conceito: _____
Banca Examinadora
Prof. Dr. Rodrigo Quites Reis.

Faculdade de Computao/UFPA Orientador
Prof. Dr. Roberto Samarone dos Santos Arajo

Faculdade de Computao/UFPA Membro
Prof. Ms. Ernani de Oliveira Sales

Faculdade de Computao/UFPA - Membro
AGRADECIMENTOS
Agradeo a Deus por me proporcionar sade, confiana e inteligncia para a

realizao deste trabalho.
Aos meus pais, Antnio e Maria, e minhas irms Larissa e Laura, que sempre
estiverem presentes me apoiando e incentivando em todos os momentos. Obrigado pelas
oportunidades oferecidas, pela educao, pelas oraes e momentos de diverso.
minha amiga e namorada, Silvia, que esteve comigo em todos os momentos
bons e ruins durante a graduao, sempre me oferecendo ateno e carinho quando
precisei. Obrigado por todo o amor e companheirismo nesses anos todos.
Ao prof. Rodrigo Quites Reis por ter me convidado para participar do LABES,
pela confiana depositada em mim, pela pacincia, pelas crticas e pela orientao
oferecida durante a realizao deste e outros trabalhos.
profa. Carla por todo apoio e contribuies oferecidas nos trabalhos.
Aos amigos do LABES, por toda a ajuda oferecida desde quando me tornei
membro do LABES. Em especial, ao Adailton Lima, Ernani Sales, Anderson Costa,
Liken Lima e Breno Frana que estiveram sempre disponveis quando precisei de apoio.
Obrigado tambm pelos momentos de descontrao e confraternizao.
Aos professores da UPFA por todo conhecimento transmitido durante as
disciplinas do curso.
Aos amigos dos CBCC 2007, pelo companheirismo, pelas partidas do La Pelota
na Waldecis International Arena, pelas viagens e por todos os momentos de diverso e
tenso compartilhados durante o curso.
Aos amigos do Centro Acadmico, que trabalharam pesado junto comigo pra
oferecer nossa faculdade uma representao estudantil eficiente. Fico feliz pelo
trabalho que conseguimos realizar e pelo esprito de trabalho que conseguimos despertar
em outros alunos que vo continuar com o nosso trabalho.
Por fim, meu muito obrigado a todas a pessoas que de alguma forma me
ajudaram ou torceram para que eu atingisse este objetivo.
RESUMO
Mecanismos de registro de eventos so uma parte importante de qualquer sistema de

informao. Esses mecanismos geralmente registram os eventos importantes para o
sistema como, por exemplo, as aes dos usurios, o estado de execuo da aplicao, a
utilizao dos recursos do sistema e as alteraes nos dados, permitindo o
Administrador do Sistema realizar aes como encontrar anomalias, ameaas
segurana e medir o desempenho do sistema. As notificaes de eventos permitem que
pessoas sejam informadas sobre a ocorrncia de um evento que lhes interessa assim que
este ocorrer. A utilizao de um mecanismo de notificao de eventos permite que o
Administrador do Sistema e os usurios em geral tirem proveito dos eventos registrados
sem precisar ficar consultando os registros manualmente e constantemente. No contexto
do ambiente WebAPSEE 2.0, que um Ambiente de Engenharia de Software Centrado
em Processos, esses mecanismos tambm podem ser aplicados como ferramentas de
apoio tomada de deciso com base no histrico dos processos de uma organizao.
Sabendo disso, este trabalho vem apresentar uma proposta de infraestrutura para registro
automtico de eventos e para notificao de eventos no ambiente WebAPSEE 2.0.
PALAVRAS-CHAVE: Registro de Eventos, Notificao de Eventos, WebAPSEE 2.0,
Segurana, Histrico de Processo.
ABSTRACT
Log mechanisms are an important part of any information system. These mechanisms
generally record the important events for the system, for example, the users' actions, the
execution state of application, resource consumption and data changes, allowing the
System Administrator performs actions such as detection of anomalies, security threats
and measure system performance. Event notifications allow people to be informed about
the occurrence of an event that interests them as soon as this occurs. The use of an event
notification mechanism allows the System Administrator and general users to take
advantage of recorded events without consulting the records manually and constantly.
In the context of the environment WebAPSEE 2.0, which is a Process-Centered
Software Engineering Environment, these mechanisms can also be applied as tools to
support decision making based on the historical basis of the processes of an
organization. Knowing this, this paper presents an infrastructure to automatic record of
events and notification of events in the environment WebAPSEE 2.0.
KEYWORDS: Event Log, Event Notification, WebAPSEE 2.0, Security, Process
History.
LISTA DE FIGURAS
Figura 1 Camadas que compe a arquitetura do ambiente WebAPSEE 1.x [LABES

2006]. .............................................................................................................................. 20
Figura 2 Editor visual de processos do Manager Console e exemplo de formulrio. . 22
Figura 3 Interface grfica da Task Agenda. ................................................................. 23
Figura 4 Interface grfica da Web Agenda. ................................................................. 24
Figura 5 Viso geral dos componentes e da comunicao no WebAPSEE 2.0. ......... 26
Figura 6 Modelo de persistncia de dados do registro de eventos atual...................... 31
Figura 7 Classes de acesso aos dados do registro de eventos atual. ............................ 33
Figura 8 Classe Logging atual. .................................................................................... 34
Figura 9 Infraestrutura de notificao de eventos atual (Pacote Mail). ....................... 35
Figura 10 Relacionamento do usurio com a infraestrutura proposta. ........................ 38
Figura 11a Exemplo do funcionamento do registro de eventos. ................................. 39
Figura 11b Exemplo do funcionamento da notificao de eventos. ............................ 40
Figura 12 Diagrama de casos de uso do registro de eventos. ...................................... 44
Figura 13 Diagrama geral de casos de uso da notificao de eventos. ........................ 48
Figura 14 Especificao do caso de uso Gerenciar Notificaes............................. 48
Figura 15 Modelo de dados do componente de registro de eventos. ........................... 50
Figura 16 Classes de acesso aos dados do componente de registro de eventos. ......... 52
Figura 17 Interface de servios do mecanismo de registro de eventos. ...................... 53
Figura 18 Implementao da interface de servios do mecanismo de registro de
eventos. ........................................................................................................................... 54
Figura 19 Comportamento do mecanismo de registro de eventos............................... 55
Figura 20 Modelo de dados do componente de notificao de eventos. ..................... 57
Figura 21 Classes de acesso aos dados do componente de notificao de eventos ..... 60
Figura 22 Interface de servios do mecanismo de notificao de eventos. ................. 61
Figura 23 Implementao da interface de servios do mecanismo de notificao de
eventos. ........................................................................................................................... 62
Figura 24 Comportamento do mecanismo de notificao interna Criao de
notificao. ..................................................................................................................... 63
Figura 25 Comportamento do mecanismo de notificao externa Envio de

notificao. ..................................................................................................................... 64
Figura 26 Prottipo de interface grfica para a busca de registros de evento. ............ 66
Figura 27 Prottipo de interface grfica para o Gerenciador de Notificaes. ........... 67
Figura 28 Prottipo de interface grfica para o cadastro de notificaes. ................... 68
Figura 29 Prottipo de interface grfica para visualizao de notificaes cadastradas.
........................................................................................................................................ 69
Figura 30 Prottipo de interface grfica para visualizao de notificaes recebidas. 70
Figura 31 Diagrama de casos de uso do registro de eventos. .................................... 100
Figura 32 Diagrama geral de casos de uso da notificao de eventos. ...................... 102
Figura 33 Especificao do caso de uso Gerenciar Notificaes........................... 104
LISTA DE QUADROS
Quadro 1 Exemplo de configurao de notificao no arquivo XML. ....................... 36

Quadro 2 Requisitos do componente de registro de eventos (continua). .................... 42
Quadro 3 Requisitos do componente de notificao de eventos (continua). ............... 44
Quadro 4 Eventos identificados no ambiente WebAPSEE (continua). ....................... 85
Quadro 5 Eventos disponveis para notificao externa. ............................................. 98
Quadro 6 Modelo de quadro utilizado na descrio dos casos de uso. ....................... 99
Quadro 7 Descrio do caso de uso UC 1. ................................................................ 100
Quadro 10 Descrio do caso de uso UC 4. .............................................................. 101
Quadro 11 Matriz de relacionamento entre os requisitos e casos de uso de registro de
eventos. ......................................................................................................................... 101
Quadro 16 Descrio do caso de uso UC 4.1. ........................................................... 104
Quadro 25 Matriz de relacionamento entre os requisitos e casos de uso de notificao
de eventos. .................................................................................................................... 109
SUMRIO
1 INTRODUO ........................................................................................................... 9
1.1 MOTIVAO .................................................................................................................................. 11
1.2 PROBLEMA .................................................................................................................................... 12
1.3 OBJETIVOS ..................................................................................................................................... 13
1.4 ORGANIZAO DO TEXTO ........................................................................................................ 13
2 TECNOLOGIA DE PROCESSO DE SOFTWARE .............................................. 15

2.1 AMBIENTES DE ENGENHARIA DE SOFTWARE CENTRADOS EM PROCESSOS .............. 16
2.2 AMBIENTE WEBAPSEE ............................................................................................................... 18
2.2.1 WEBAPSEE 1.8 ..................................................................................................................... 19
2.2.2 WEBAPSEE 2.0 ..................................................................................................................... 24
3 REGISTRO E NOTIFICAO DE EVENTOS .................................................... 27

3.1 MINERAO DE PROCESSO....................................................................................................... 28
3.2 MECANISMO ATUAL DE REGISTRO DE EVENTOS NO WEBAPSEE .................................. 30
3.3 MECANISMO ATUAL DE NOTIFICAO DE EVENTOS NO WEBAPSEE ........................... 34
4 INFRAESTRUTURA PROPOSTA ......................................................................... 38

4.1 REQUISITOS ................................................................................................................................... 41
4.2 ARQUITETURA PROPOSTA PARA REGISTRO DE EVENTOS ............................................... 48
4.2.1 Modelo de Dados ................................................................................................................... 49
4.2.2 Mecanismo de Registro de Eventos...................................................................................... 53
4.2.3 Viso Comportamental do Registro de Eventos ................................................................. 54
4.3 ARQUITETURA PROPOSTA PARA NOTIFICAO DE EVENTOS........................................ 56
4.3.1 Modelo de Dados ................................................................................................................... 57
4.3.2 Mecanismo da Notificao de Eventos................................................................................. 60
4.3.3 Viso Comportamental da Notificao de Eventos ............................................................ 63
4.4 PROTTIPOS DE INTERFACE GRFICA .................................................................................. 65
4.5 APLICAES DO REGISTRO DE EVENTOS NO WEBAPSEE 2.0 .......................................... 71
5 CONSIDERAES FINAIS .................................................................................... 73

5.1 DIFICULDADES ENCONTRADAS .............................................................................................. 73
5.2 TRABALHOS FUTUROS ............................................................................................................... 74
REFERNCIAS BIBLIOGRFICAS ....................................................................... 75

APNDICE A EVENTOS IDENTIFICADOS NO AMBIENTE WEBAPSEE .. 84
APNDICE B DESCRIO DOS CASOS DE USO ............................................ 99
B.1. Casos de Uso do Registro de Eventos .................................................................................... 99
B.2. Casos de Uso da Notificao de Eventos ............................................................................. 102
1 INTRODUO
Em 2004, Tim OReilly citou o termo Web 2.0 pela primeira vez e definiu a
Web 2.0 como a mudana para a Internet como plataforma [OReilly 2007]. Alguns
pesquisadores da rea, como Tim Berners-Lee (considerado o pai da World Wide Web),
discordaram de OReilly dizendo que a Web continuava a mesma de sempre j que no
houve mudana na infraestrutura da Internet e nos padres utilizados, como HTML
(HyperText Markup Language) e Javascript.
verdade que no houve nenhuma alterao na infraestrutura nem nos padres
utilizados na Internet, entretanto, a forma como a Internet passou a ser utilizada mudou
perceptivelmente. No incio da Internet, as pginas eram estticas, apresentando apenas
textos e algumas imagens. Atualmente, em 2011, muito comum encontrar na Internet
sites interativos, aplicaes multimdia, internet banking, redes sociais, aplicaes onde
os usurios podem trabalhar de forma cooperativa e outros vrios tipos de sites e
aplicaes Web. So esses sites e aplicaes Web que definem a Web 2.0 e a Internet
no apenas como um meio para compartilhar informaes e se comunicar com outras
pessoas, mas como uma necessidade diria.
Nesse contexto de Web 2.0, est sendo desenvolvido no Laboratrio de
Engenharia de Software da Universidade Federal do Par o ambiente WebAPSEE 2.0.
O WebAPSEE um Ambiente de Engenharia de Software Centrado em Processos que
teve sua primeira verso desenvolvida em 2004 e desde ento vem evoluindo e
recebendo novas funcionalidades. O ambiente permite a modelagem grfica de modelos
de processo, execuo e acompanhamento da execuo atravs do editor de processos e
de diversos relatrios que podem ser gerados. Alm disso, o ambiente tambm permite
o cadastro de informaes da organizao como projetos, agentes, papis, artefatos,
recursos e vrias outras. Em sua primeira verso, o ambiente foi projetado baseado
numa arquitetura cliente e servidor, em um ambiente de intranet, a fim de permitir que o
gerenciamento do projeto e a execuo das atividades por seus colaboradores pudessem
ser desenvolvidas de forma distribuda em uma empresa. Contudo, com o advento da
Web 2.0 e do sucesso de inmeras tecnologias do tipo Rich Internet Applications (RIA)
possibilitou-se vislumbrar a evoluo desse ambiente como um portal para gesto de
10
processos totalmente na Web, podendo atender diversas empresas de forma mais

simples e menos custosa.
Entretanto, aplicaes Web que esto disponveis na Internet e lidam com
informaes privadas de pessoas e/ou empresas, como o ambiente WebAPSEE 2.0,
precisam se preocupar com a confidencialidade e a integridade dessas informaes. Essa
garantia, normalmente, realizada utilizando mecanismos de autenticao e
autorizao, porm nem sempre suficiente, uma vez que existem na Internet usurios
mal intencionados que podem tentar obter acesso s informaes confidenciais de forma
ilegal. Uma forma de verificar a confidencialidade e a integridade das informaes est
sendo mantida por meio da auditoria do sistema. Entretanto, para que seja possvel
realizar essa atividade de auditoria necessrio que o sistema possua algum mecanismo
que registre as aes dos usurios, o estado do sistema, e outros eventos importantes
que ocorrem constantemente.
Mecanismos de registro de eventos so uma parte importante de qualquer
sistema de informao. Esses mecanismos geralmente registram os eventos importantes
para o sistema como, por exemplo, as aes dos usurios, o estado de execuo da
aplicao, a utilizao dos recursos do sistema e as alteraes nos dados. Esses registros
oferecem uma valiosa viso dos estados anteriores e do estado atual do sistema, o que
permite, por exemplo, encontrar anomalias, ameaas segurana e medir o desempenho
do sistema [Ma e Tsudik 2009]. No ambiente WebAPSEE 2.0, o registro de eventos
poderia ter vrias outras aplicaes alm da auditoria, entre elas esto o registro de
aes de modelagem e de execuo do processo de software, e a notificao de eventos.
A verso atual do ambiente WebAPSEE (verso desktop) possui uma infraestrutura para
registro de eventos, mas que est limitada a armazenar apenas determinados eventos e
tipos de eventos. A nova verso do ambiente (verso Web) ter vrios outros eventos
que vo precisar ser armazenados e para isso necessrio que o ambiente possua uma
infraestrutura de registro de eventos mais flexvel.
A notificao de eventos, que tambm abordada neste trabalho, importante
para o ambiente, pois permite que pessoas sejam informadas sobre a ocorrncia de um
evento que lhes interessa assim que este ocorrer. A notificao de eventos trabalha junto
com o registro de eventos para garantir que o Administrador do Sistema e os usurios
em geral tirem proveito dos eventos registrados sem precisar ficar consultando os
registros manualmente e constantemente.
11
Sabendo disso, este trabalho vem apresentar uma proposta de infraestrutura de

software composta por dois componentes: um componente para registro de eventos, que
modificou a infraestrutura atual permitindo que o ambiente registre novos eventos e
tipos de eventos, alm de permitir sua extenso de forma mais facilitada; e um
componente para notificao de eventos, a qual estende em vrios pontos o mecanismo
atual. A seguir so apresentadas as motivaes deste trabalho, o problema tratado, os
objetivos e, por fim, a organizao do restante do texto.
1.1 MOTIVAO
Segundo Ma e Tsudik (2009), as informaes armazenadas pelos registros de

eventos podem ser utilizadas em diversas atividades como, por exemplo, deteco de
falhas no sistema, auditoria do sistema, controle de acesso ao sistema, entre vrias
outras. No contexto do ambiente WebAPSEE 2.0, duas formas de utilizao do registro
de eventos se destacaram inicialmente: a Auditoria de Segurana e a Minerao de
Processos. Essas foram as motivaes iniciais para buscar propor uma nova
infraestrutura de software para registro de eventos no ambiente.
Como j foi dito anteriormente, o ambiente WebAPSEE 2.0 uma aplicao
Web que estar disponvel na Internet para seus usurios e, por isso, o acesso s
informaes desses usurios deve ser muito bem controlado para que a
confidencialidade e a integridade dessas informaes sejam mantidas. Uma forma de
verificar se as informaes no ambiente esto sendo acessadas por pessoas autorizadas
por meio da auditoria de segurana. Desde que o registro de eventos seja capaz de
registrar todas as aes de todos os usurios do ambiente, ser possvel criar um
histrico das aes realizadas pelos usurios, o que deve fornecer informaes
suficientes para que seja realizada auditoria sobre a segurana do ambiente.
A outra motivao inicial para este trabalho est relacionada com rea de
pesquisa em Minerao de Processo. O conceito de minerao de processos est
relacionado descoberta de conhecimento em processos a partir da anlise de registros
de atividades realizadas e eventos ocorridos durante a execuo do processo [Van der
Aalst e Weijters 2004]. Um registro de eventos no ambiente WebAPSEE 2.0 abrir
margem para vrias outras pesquisas nesta rea utilizando o ambiente.
12
Buscando atender, inicialmente, essas necessidades do ambiente WebAPSEE

2.0, a infraestrutura proposta estende a infraestrutura atual de registro de eventos do
ambiente WebAPSEE, com o objetivo principal de oferecer maior flexibilidade para a
adio de novos eventos e tipos de evento no modelo de dados. A infraestrutura
proposta para notificao de eventos, que faz uso do registro de eventos, tambm
estende uma infraestrutura que existe atualmente para notificao de eventos, buscando
oferecer mais opes de notificaes e maior facilidade na configurao das
notificaes que devem ser enviadas.
Durante o desenvolvimento do trabalho outras aplicaes foram identificadas
para o registro de eventos. Algumas dessas aplicaes so apresentadas mais a frente
neste trabalho.
1.2 PROBLEMA
Segundo Alves et al. (2007), registro de eventos (log) um servio complexo e

um instrumento altamente requisitado pelos desenvolvedores para promover a qualidade
dos servios oferecidos pelas suas aplicaes. Essa apenas mais uma afirmao que
prova a importncia do ambiente WebAPSEE 2.0 possuir um registro de eventos. A
partir dessa necessidade surgiu a seguinte questo: Como registrar automaticamente
todas as aes dos usurios no ambiente WebAPSEE 2.0?
A verso atual do ambiente WebAPSEE possui um componente responsvel por
registrar eventos de execuo de processo e alguns eventos de modelagem de processo
[Paxiba et al. 2005], o que pouco comparado a todos os eventos que so disparados
por aes dos usurios. Alm disso, a pouca flexibilidade no modelo de persistncia de
dados atual no permite que novos eventos sejam adicionados com facilidade o que
dificulta sua atualizao.
O componente de notificao de eventos, tambm presente na verso atual do
ambiente, faz uso dos eventos registrados para enviar as notificaes. A partir da surgiu
a ideia de desenvolver, junto com o novo registro de eventos, um componente de
notificao de eventos para o ambiente WebAPSEE 2.0 com mais funcionalidades e
opes de configurao. Essa nova demanda acabou por gerar mais uma questo para o
trabalho: Como notificar o usurio sobre a ocorrncia de um evento importante?
13
Cada um dessas perguntas gera vrias outras, por exemplo: Quais so as aes
dos usurios que devem ser registradas? O que um evento importante para o usurio?
As respostas para essas e outras perguntas acabaram gerando a proposta que
apresentada neste trabalho.
1.3 OBJETIVOS
Este trabalho tem como o objetivo propor uma infraestrutura de software

composta por dois componentes: o primeiro deve ser capaz de registrar
automaticamente eventos relacionados a segurana, modelagem de processos, execuo
de processos, entre outros eventos no contexto do ambiente WebAPSEE 2.0; e o
segundo deve enviar notificaes sobre a ocorrncia desses eventos aos usurios de
acordo com suas necessidades de informao.
1.4 ORGANIZAO DO TEXTO
Este trabalho est dividido em cinco captulos. O captulo atual fez uma
introduo sobre os principais assuntos relacionados ao trabalho, apresentou a
motivao do trabalho, o problema que a proposta tenta resolver e os objetivos do
trabalho.
O captulo 2 d uma viso geral sobre Tecnologia de Processo de Software e
sobre Ambientes de Engenharia de Software Centrados em Processos. Em seguida, o
ambiente WebAPSEE apresentado na verso atual e na verso para a Web 2.0.
O captulo 3 inicialmente faz uma introduo registro e notificao de eventos.
Em seguida, apresentada a rea de pesquisa de Minerao de Processos, na qual
muitas pesquisas fazem uso de registros de eventos para descobrir conhecimento sobre
processos. A infraestrutura atual de registro e de notificao de eventos do ambiente
WebAPSEE tambm apresentada nesse captulo.
No captulo 4 apresentada a proposta do trabalho, onde inicialmente so
apresentados os requisitos e os casos de uso da proposta e, em seguida, a arquitetura da
infraestrutura proposta na viso estrutural e comportamental. Na ltima seo do
14
captulo, so listadas algumas possveis aplicaes do registro de eventos no ambiente

WebAPSEE 2.0.
O captulo 5 trs as consideraes finais do trabalho, as principais dificuldades
encontradas durante desenvolvimento do mesmo. Aps esse captulo so apresentadas
as referncias bibliogrficas, sites e outros materiais consultados durante o
desenvolvimento do trabalho.
15
2 TECNOLOGIA DE PROCESSO DE SOFTWARE
Desde a dcada 1980, quando a ideia de processo de software comeou a se

difundir [Osterweil 1987; Boehm 1988; Curtir et al. 1988; Humphrey 1989], a
Academia e a Indstria vm investindo na construo de ferramentas que auxiliem no
gerenciamento do processo de desenvolvimento de software, o que acabou dando
origem rea de pesquisa denominada Tecnologia de Processo de Software.
Durante a dcada de 1990, a Tecnologia de Processo de Software ganhou maior
ateno a partir da nfase dada ao uso de modelos de maturidade de processo, como o
CMM (Capability Maturity Model) [Paulk et al. 1995] e seu sucessor o CMMI
(Capability Maturity Model Integrated) [SEI 2011], utilizados para avaliar a qualidade
do software a partir da maturidade dos processos organizacionais adotados pelos
desenvolvedores.
Segundo Reis (2002), os principais objetivos da Tecnologia de Processo de
Software so:
Definir ferramentas para modelagem, acompanhamento e execuo de
processos, registrando e detectando anomalias que possam ser corrigidas em
projetos futuros;
Facilitar a adoo de uma estratgia de melhoria da maturidade dos processos de

uma organizao, a partir da prescrio, monitorao e registro automatizado de
eventos;
Permitir o registro do conhecimento produzido acerca dos processos bem

sucedidos na organizao, para ser reutilizado em contextos similares no futuro;
Proporcionar um controle preciso na alocao e consumo de recursos durante o

desenvolvimento de software;
Coletar mtricas dos projetos da organizao e torn-las disponveis para

consultas posteriores.
Neste contexto de Tecnologia de Processo de Software, uma categoria de
ambiente se destaca quando se trata de coordenar as atividades e os recursos envolvidos

no processo de desenvolvimento de software, so os chamados Ambientes de
Engenharia de Software Centrados em Processos [Gruhn 2002]. Utilizando esses
ambientes possvel coordenar atividades de equipes dispersas geograficamente,
16
acompanhar os prazos e o consumo de recursos, alm de facilitar a reutilizao de boas

prticas gerenciais em diferentes projetos [Lima et al. 2006].
A seguir, a seo 2.1 apresenta com mais detalhes os Ambientes de Engenharia
de Software Centrados em Processos. E na seo 2.2 apresentado o ambiente
WebAPSEE e suas duas verses.
2.1 AMBIENTES
DE
ENGENHARIA
DE
SOFTWARE
CENTRADOS
EM
PROCESSOS
Os Ambientes de Engenharia de Software Centrados em Processos (mais

conhecidos pela sua sigla em ingls PSEE de Process-Centered Software Engineering
Environment [Gimenes 1994]) possuem como principal caracterstica auxiliar a
definio e execuo de processos de forma a auxiliar a gerncia das atividades, pessoas
e recursos envolvidos na produo e manuteno de um software [Lima Reis 2003].
Lima et al. (2006) afirma que:
As solues desenvolvidas nesta rea devem levar em considerao elementos
especficos do contexto de processos de software, tais como: o carter criativo do
processo, a grande tendncia a mudanas, a impossibilidade de se reutilizar
imediatamente processos executados e a falta de visibilidade do produto resultante.
Primordialmente, um PSEE composto por trs componentes [Lima Reis 2003]:

1. Uma infraestrutura de interao com o usurio (como um editor de modelagem de
processos, por exemplo) baseado em uma ou mais Linguagens de Modelagem de
Processos (ou PML, sigla em ingls para Process Modeling Language). Essas
linguagens visam oferecer os elementos necessrios para a especificao do
modelo de processo como, por exemplo, recursos, pessoas, procedimentos,
produtos e restries.
2. Uma infraestrutura capaz de executar o modelo de processo descrito pelo usurio
utilizando a(s) PML(s);
3. Um repositrio de dados para armazenar os dados relacionados com o processo.
Alm desses trs componentes principais, um PSEE tambm pode integrar
outras infraestruturas que ofeream suporte para reas de processo especficas, por
exemplo, para gerncia de requisitos ou para gerncia de configurao. Mais detalhes
sobre os requisitos de um PSEE podem ser encontrados em [Lima Reis 2003].
17
Em 2000, o pesquisador Alfonso Fuggetta citou que naquele momento as

pesquisas estavam centradas no estudo e melhoria do processo pelo qual o software era
desenvolvido, pois os pesquisadores estavam pressupondo que havia uma correlao
direta entre a qualidade do processo e a qualidade do software desenvolvido [Fuggetta
2000]. Atualmente, em 2011, temos esse pressuposto como verdade uma vez que
empresas de desenvolvimento de software avaliadas por algum modelo de maturidade
de processo, como o MR-MPS [SOFTEX 2011] que o Programa de Melhoria de
Processos do Software Brasileiro, mostram tendncias de melhoria em relao
qualidade, custo, cronograma, produtividade e satisfao dos clientes [Santos et al.
2010; Travassos e Kalinowski 2010]. Esses ndices acabam influenciando muitas
empresas a buscar a utilizao de tecnologias como os PSEEs, na tentativa de melhorar
continuamente seus processos de desenvolvimento de software.
Desde o incio das pesquisas nessa rea, diversos PSEEs foram propostos e
desenvolvidos, tanto de iniciativa acadmica como EPOS [Conradi et al. 1994], OPSIS
[Avrilionis et al. 1996], Serendipty-II [Grundy et al. 1998], OZ [Ben-Shaul e Kaiser
1998], Spearmint [Rsch et al. 1998], E [Jaccheri et al. 1999], PIE [Cugola et al.
2000], Estao TABA [Montoni et al. 2006], Projeto Spider [Spider 2011], quanto de
iniciativa comercial como Endeavors [Bolcer e Taylor 1996], Rational Team Composer
[RTConcert 2011] e Project Koach [PKoach 2011].
Apesar de vrias PMLs e PSEEs terem sido criados, Fuggetta (2000) explica que
a alta complexidade, a falta de flexibilidade e outros problemas relacionados com as
PMLs so refletidos para os PSEEs, o que cria barreiras significantes para a utilizao
dos ambientes pela indstria.
No trabalho de Lima Reis (2003) proposta uma nova PML que visa aumentar a
flexibilidade na modelagem e execuo de processos de software. Este trabalho deu
origem ao ambiente WebAPSEE, que um PSEE desenvolvido desde 2004 no
Laboratrio de Engenharia de Software da Universidade Federal do Par. A seguir, o
ambiente WebAPSEE e suas verses so apresentados com mais detalhes.
18
2.2 AMBIENTE WEBAPSEE
O WebAPSEE um Ambiente de Engenharia de Software Centrado em

Processos desenvolvido no Laboratrio de Engenharia de Software da Universidade
Federal do Par [WebAPSEE 2011]. Segundo Lima et al. (2006), o ambiente foi
originado a partir de uma experincia no desenvolvimento de um PSEE chamada
APSEE [Lima Reis et al. 2001] que adotava solues inovadoras para problemas
crticos relacionados com a gerncia e execuo automatizada de processos de software.
Lima et al. (2006) relata que:
Com o surgimento de tecnologias baseadas em Web Services houve uma evoluo
significativa no desenvolvimento de software baseado na Internet, ao facilitar a
intercomunicao de sistemas atravs de um middleware aberto, multiplataforma, e
baseado em padres da Web. Havia, ento, uma oportunidade de se desenvolver um
novo PSEE baseado na noo de uma arquitetura flexvel que acomode novos
componentes, seja multiplataforma, e disponvel para evoluo contnua atravs da
comunidade de Software Livre. A integrao das ideias e modelos gerados com o
projeto APSEE aliado tecnologia dos Web Services resultou no ambiente
WebAPSEE.
A construo da primeira verso da ferramenta foi iniciada em 2004 em um projeto

cooperativo de estudantes e pesquisadores do Laboratrio de Engenharia de Software da
UFPA e da Fakultt Informatik der Universitt Stuttgart (Alemanha). Desde ento o
ambiente vem evoluindo e recebendo novas funcionalidades. O projeto do ambiente foi
criado com base no trabalho de Lima Reis (2003). A ideia original era que o ambiente
pudesse ser acessado por meio da Internet. Entretanto, devido a decises de projeto, a
primeira verso do ambiente WebAPSEE foi implementada como uma aplicao
desktop baseada numa arquitetura cliente-servidor, cuja comunicao era realizada
atravs de protocolos de comunicao remota.
O ambiente WebAPSEE tem como principal caracterstica a flexibilidade
oferecida durante a execuo do processo. O ambiente permite que o processo seja
modificado em tempo de execuo, adicionando e removendo atividades, conexes,
pessoas, recursos e artefatos, por exemplo. Permite ainda iniciar a execuo do processo
mesmo que alguns componentes estejam faltando, como atividades, conexes e detalhes
de alocao. As informaes sobre pessoas e recursos para atividades podem ser
definidas durante a execuo, possibilitando que a alocao de pessoas e recursos seja
adiada [Lima Reis 2003].
19
Entre as outras funcionalidades que fazem o diferencial do ambiente

WebAPSEE esto o apoio a reutilizao de processos [Sales e Costa 2007] e controle de
verso de artefatos [Sales et al. 2007], alm de funcionalidades inerentes ferramentas
de gerenciamento de projetos, como visualizao do processo com grfico de Gantt,
gerao de caminho crtico, Estrutura Analtica do Projeto e gerao de relatrios
gerenciais, como cronograma de atividades com desvio de esforo e prazos, plano de
custos e recursos humanos, dentre outros.
A definio de processos no WebAPSEE feita utilizando uma linguagem
visual de modelagem de processos definida em Lima Reis (2003) chamada
WebAPSEE-PML. Essa linguagem capaz de descrever os elementos inerentes ao
processo de software como: artefatos, agentes, recursos, atividades, entre outros. Possui
uma semntica formal, o que permite que os processos modelados utilizando a
linguagem sejam interpretados e executados pela mquina de execuo do ambiente.
Ainda h um editor grfico, integrado ao ambiente, que permite a modelagem visual dos
modelos de processo e auxilia no monitoramento da execuo dos mesmos.
O ambiente WebAPSEE continua evoluindo a partir de pesquisas realizadas
pelos membros do Laboratrio de Engenharia de Software. Durante a realizao deste
trabalho, a verso Web 2.0 do ambiente est sendo desenvolvida.
2.2.1 WEBAPSEE 1.8
Como relatado anteriormente, o ambiente WebAPSEE foi inicialmente projetado

para ser desenvolvido com base em padres Web e possuir interoperabilidade com
sistemas externos por meio de Web Services. A partir da surgiu o nome WebAPSEE,
pois a ideia era utilizar Web Services como evoluo do ambiente APSEE [Lima Reis
2003].
Entretanto, durante a implementao do projeto original do ambiente
WebAPSEE,
foram
encontradas
dificuldades
relacionadas
principalmente
ao
desempenho da aplicao, o que acabou dificultando a realizao da comunicao com

a utilizao de Web Services. Por isso, a primeira verso o ambiente WebAPSEE foi
implementada como uma aplicao desktop utilizando a arquitetura cliente-servidor e as
seguintes tecnologias: a
linguagem de programao Java [Oracle 2011a] para
20
implementao dos servios; a biblioteca Java/Swing [Oracle 2011b] para

desenvolvimento da interface grfica do usurio; o protocolo RMI (Remote Method
Invocation) [Oracle 2011c] para realizar a comunicao cliente/servidor; e o banco de
dados MySQL [MySQL 2011] para armazenar as informaes das organizaes e dos
processos.
A verso atual (release 1.8) do ambiente WebAPSEE ainda mantm as mesmas
tecnologias e a mesma arquitetura cliente-servidor. Essa arquitetura est dividida em
trs camadas principais [LABES 2006], que so descritas a seguir e apresentadas na
Figura 1:
A) Camada Servidora: prov servios de persistncia, verificao de consistncia
para modelagem, controle e armazenamento de artefatos e execuo de modelos
de processos de software;
B) Camada Cliente: oferece uma infraestrutura para acesso aos servios da
camada servidora;
C) Camada de Ferramentas Clientes: possui os componentes que fornecem a
interface grfica para o usurio realizar a entrada de dados, modelagem de
modelos de processos e visualizaes de informaes obtidas do servidor.
Figura 1 Camadas que compe a arquitetura do ambiente WebAPSEE 1.x [LABES

2006].
Desde a primeira verso o ambiente WebAPSEE vem recebendo melhorias e

vrias ferramentas e mecanismos foram integrados ao ambiente, adicionando novos
servios e funcionalidades. As melhorias so realizadas constantemente pela equipe de
21
desenvolvimento do ambiente, enquanto as ferramentas e mecanismos so resultados,

principalmente, de trabalhos de concluso de curso e dissertaes de mestrado de
membros do Laboratrio de Engenharia de Software da UFPA.
Na verso atual, de acordo com Sales et al. (2010), a Camada Servidora do
ambiente fornece os seguintes servios: gerncia da organizao (gerncia dos recursos
humanos, materiais e tecnolgicos), planejamento do projeto (definio e implantao
de processos), controle e monitorao de projetos (acompanhamento de processos em
tempo real, modificao dinmica do processo, diferentes visualizaes do processo),
gerncia de configurao (controle de verso dos artefatos), medio e anlise do
projeto (coleta de mtricas, estimativas de componentes do processo, gerao de
relatrios), e gerncia integrada de projeto (orientao na realizao de tarefas,
visualizao das tarefas e artefatos, obteno de feedback do processo). Alm disso,
ainda h outros dois mdulos que apoiam determinadas reas de processo, o WebAPSEE
Requirement Manager (WARM) que apoia a Gerncia de Requisitos [Sales 2008] e o
WebAPSEE Knowledge Manager (WKM) que apoia a Gerncia de Conhecimento
[Oliveira 2010]. Esses servios so disponibilizados para os usurios atravs de trs
ferramentas clientes: o Manager Console, a Task Agenda e a Web Agenda.
O Manager Console a ferramenta voltada para a gerncia do processo. Possui
um editor visual de processos integrado por onde o gerente pode modelar e instanciar
processos, ou seja, definir as atividades do processo, o fluxo das atividades, os
documentos que devem ser produzidos e consumidos, os recursos e ferramentas que
devem ser utilizados e as pessoas e grupos envolvidos. Fornece um conjunto de
formulrios que permitem a definio de prazos, custos, estimativas e mtricas a serem
utilizadas, alm de formulrios para cadastro de informaes sobre a organizao e o
processo como um todo. Ainda possvel realizar o acompanhamento da execuo do
processo atravs do editor visual (em tempo real) e atravs de relatrios gerenciais. A
Figura 2 apresenta o editor de processos do Manager Console e um exemplo de
formulrio da ferramenta.
22
Figura 2 Editor visual de processos do Manager Console e exemplo de formulrio.
A Task Agenda a ferramenta voltada para os desenvolvedores e outros

colaboradores do processo. Na Task Agenda o processo apresentado como uma lista
de atividades a serem realizadas e permitido ao usurio delegar atividades aos seus
subordinados, fazer download e upload de artefatos (documentos, cdigos, entre outros
dados concretos geralmente voltados documentao de um projeto) e visualizar os
recursos a serem utilizados. Durante a execuo do processo, o desenvolvedor pode
enviar para o gerente, por meio das Task Agenda, o feedback sobre o estado de suas
atividades (iniciada, pausada ou finalizada). Esse feedback refletido imediatamente no
editor de processos do Manager Console, o que permite o gerente acompanhar o
andamento do processo. A Figura 3 apresenta a interface grfica da Task Agenda com a
lista de atividade de um desenvolvedor.
23
Figura 3 Interface grfica da Task Agenda.
A Web Agenda foi desenvolvida em 2007 e a verso Web da Task Agenda. A

interface grfica foi reprojetada e desenvolvida utilizando uma tecnologia nova na
poca, o Adobe Flex [Flex 2011]. No lado do servidor, os servios continuaram sendo
implementados com a linguagem Java. A Web Agenda possui as mesmas
funcionalidades da Task Agenda, a principal diferena entre as Agendas est no
protocolo utilizado para comunicao com o servidor, j que a Task Agenda utiliza o
protocolo RMI, enquanto a Web Agenda se comunica com o servidor atravs da Internet
utilizado o protocolo HTTP (Hypertext Transfer Protocol). A Figura 4 apresenta a
interface grfica da Web Agenda.
24
Figura 4 Interface grfica da Web Agenda.
2.2.2 WEBAPSEE 2.0
O verso 2.0 do ambiente WebAPSEE encontra-se em desenvolvimento durante

a realizao deste trabalho. As informaes apresentadas nesta seo foram extradas
dos documentos do projeto do ambiente.
O WebAPSEE 2.0 uma aplicao Web que vem sendo desenvolvida desde
2010, com financiamento do SEBRAE/FINEP e da FAPESPA, e quando estiver
disponvel ir fornecer na Internet as funcionalidades inovadores do ambiente
WebAPSEE atual, alm de uma srie de novas funcionalidades. A nova verso mantm
a arquitetura cliente-servidor, mas a partir de agora a comunicao ser realizada por
meio da Internet utilizando o protocolo HTTP.
25
Alm de migrar o ambiente para a Web 2.0, um modelo de negcio diferenciado

est sendo implementado, mais baseado em promover a colaborao entre os usurios e
a integrao entre diferentes servios existentes na Internet do que investir somente em
funcionalidades embarcadas. Nesse novo modelo, denominado internamente como
Software Process Marketplace, os processos e seus elementos estaro associados com
um frum de discusso, alm de permitir o registro da sua utilizao e de suas verses.
Espera-se que essas funcionalidades tragam para o mundo de processos de software a
noo de colaborao existente em aplicaes atuais como Blogger, Flickr e Youtube.
Deste modo, componentes de processos de diferentes origens podem ser compartilhados
entre mltiplos projetos. Por exemplo, isto pode permitir que uma empresa
especializada em Teste possa usar o WebAPSEE para disseminar sua concepo em
termos de processos e artefatos, e o seu processo ser til para outros usurios.
A arquitetura do ambiente WebAPSEE 2.0 ser dividida em camadas e o estilo
arquitetural Model-View-Controller (MVC) foi escolhido para implementar essa
arquitetura devido flexibilidade oferecida pelo estilo, entre outras vantagens [Burbeck
1987; Buschmann et al. 1996; Fowler 2002]. O MVC conhecido por facilitar o
desenvolvimento de aplicaes Web, pois separa a lgica de negcio da lgica de
apresentao (interface grfica do usurio) em diferentes camadas, permitindo realizar o
desenvolvimento, teste e manuteno das camadas sem que uma dependa da outra.
A seleo das tecnologias que esto sendo utilizadas no desenvolvimento do
WebAPSEE 2.0 foi realizada em etapas, visando s camadas do MVC. Foram
selecionadas vrias tecnologias candidatas e identificadas as vantagens e desvantagens
de cada uma delas. A partir das informaes reunidas sobre as tecnologias candidatas
foram selecionadas as seguintes tecnologias para serem utilizadas:
Camada Model: os servios esto sendo implementado utilizando a linguagem
de programao Java e a tecnologia Enterprise JavaBeans 3.0 (EJB 3.0). O EJB
um componente que fica no lado servidor da aplicao e permite o
desenvolvimento de aplicaes distribudas, transacionais, seguras e portteis
baseadas em Java [Oracle 2011e].
Camada View e Controller: a interface grfica do usurio e as funes da
Camada Controller sero implementadas utilizado o Google Web Toolkit
(GWT). O GWT um conjunto de ferramentas livres, desenvolvido pela
Google, que permite o desenvolvimento de interfaces grficas de aplicaes
Web utilizando Java e um compilador que converte o cdigo Java para um
26
cdigo HTML/JavaScript otimizado [GWT 2011]. Apenas o editor de processos

do Web Manager Console est sendo desenvolvido utilizando a tecnologia
Adobe Flex [Flex 2011], pois o GWT ainda no fornece os recursos necessrios
para o desenvolvimento de determinadas funcionalidades do editor.
Outras tecnologias: como servidor de aplicao foi escolhido o JBoss
Application Server 5.0, o qual totalmente baseado em Java [JBoss 2011]. O
sistemas para gerenciamento de banco de dados ser novamente o MySQL e as
ferramentas de controle de verso tambm sero as mesmas da verso atual,
CVS [CVS 2011] e Subversion [Subversion 2011].
A Figura 5 apresenta uma viso geral dos componentes do ambiente WebAPSEE
2.0 e da comunicao entre eles.
Figura 5 Viso geral dos componentes e da comunicao no WebAPSEE 2.0.
Como j foi dito anteriormente, o ambiente WebAPSEE 2.0 poder ser acessado
por meio da Internet, e diferente da verso atual onde as funcionalidades do ambiente
esto divididas entre trs ferramentas (Manager Console, Task Agenda e Web Agenda),
na verso 2.0 do ambiente todas funcionalidades estaro reunidas em uma nica
aplicao Web. Ento quando um usurio acessar o site do ambiente e fornecer suas
credenciais de acesso a tela exibida ser de acordo com o papel do usurio no processo,
por exemplo, um desenvolvedor ter acesso apenas a interface grfica da Web Agenda,
enquanto um gerente poder ter acesso tanto a Web Agenda como ao editor de processos
e as outras funcionalidades do Web Manager Console.
O Web Manager Console ter o editor de processos e os formulrios de cadastro
de informaes reformulados para que atendam princpios que usabilidade que no so
atendidos na verso atual do ambiente WebAPSEE. Essa reformulao est sendo
realizada com base em um relatrio escrito por um bolsista de iniciao cientfica, que
aplicou a tcnica de Avaliao Heurstica [Nielsen e Molich 1990] no ambiente para
identificar problemas de usabilidade e propor sugestes de melhoria.
27
3 REGISTRO E NOTIFICAO DE EVENTOS
Mecanismos de registro de eventos so uma parte importante de qualquer

sistema de informao. Esses mecanismos geralmente registram eventos importantes
para o sistema como, por exemplo, aes dos usurios, estado de execuo da aplicao,
utilizao dos recursos do sistema e alteraes nos dados. Esses registros oferecem uma
valiosa viso dos estados anteriores e do estado atual do sistema, o que permite, por
exemplo, encontrar anomalias, ameaas segurana e medir o desempenho do sistema
[Ma e Tsudik 2009].
Em geral, aplicaes que realizam registro de eventos utilizam arquivos de log
para armazenar os eventos ocorridos, onde cada linha do arquivo de log contm
informaes sobre um evento. Entre as informaes que so geralmente armazenadas
esto informaes como data e hora, informaes do usurio, informaes da aplicao
e informaes do evento [Nagapan e Vouk 2010].
Segundo Rubin et al. (2007), sistemas de informaes e software continuam se
tornando cada vez mais complexos, o que explicado pelo aumento do nmero de
funcionalidades e a maior integrao e interao entre diferentes tipos de software e
sistemas. Devido esse aumento da complexidade dos sistemas, a quantidade de eventos
que so registrados pelos sistemas muito grande o que torna os arquivos de log
grandes demais para serem analisado manualmente [Nagapan e Vouk 2010].
Buscando facilitar a extrao e a anlise de informaes contidas em arquivos de
log, diversos algoritmos e ferramentas de minerao de dados foram propostos nos
ltimos anos [Van der Aalst et al. 2004; Dongen e Van der Aalst 2004; Rubin et al.
2007; Nurminen et al. 2007; Wen et al. 2009; Nagappan e Vouk 2010]. Nesse contexto,
uma rea de pesquisa que se destaca a Minerao de Processos. As pesquisas nessa
rea tm como principal objetivo extrair informaes de arquivos de log de modelos de
processo, analisar essas informaes para destilar conhecimentos teis e aplicar esses
conhecimentos para realizar, por exemplo, descoberta de processos ou melhoria de
processos.
Sabendo da importncia do mecanismo de registro de eventos e do valor dos
eventos registrados, essencial que haja alguma forma imediata de informar s pessoas
interessadas sobre a ocorrncia de determinados eventos. A notificao de eventos
28
possui exatamente esse objetivo, notificar pessoas sobre a ocorrncia de eventos assim
que estes ocorrerem. Desta forma, o Administrador do Sistema, por exemplo, no
precisa ficar monitorando manualmente os eventos registrados para saber se o sistema
est operando normalmente, basta que este configure o mecanismo de notificao para
notific-lo caso alguma anomalia no funcionamento do sistema seja detectada.
Este captulo tem como principal objetivo apresentar a infraestrutura de registro
e de notificao de eventos existente no ambiente WebAPSEE atual. Alm disso, dada
uma viso geral da rea de minerao de processos. E, por fim, apresentada uma lista
de possveis aplicaes do registro de eventos no ambiente WebAPSEE 2.0, que foram
identificadas a partir de reunies com a equipe responsvel pelo desenvolvimento do
ambiente.
3.1 MINERAO DE PROCESSO
O conceito de minerao de processos est relacionado descoberta de

conhecimento em processos a partir da anlise de registros de atividades realizadas e
eventos ocorridos durante a execuo do processo [Van der Aalst e Weijters 2004]. Esse
conceito de minerao de processos no novo [Agrawal et al. 1998; Herbst 1999;
Weijters e Van der Aalst 2001; Maruster et al. 2002; Van der Aalst et al. 2003], os
estudos iniciaram com o objetivo auxiliar organizaes a identificar e entender melhor,
para analisar, otimizar, e executar seus processos de negcio. Essa subrea da
minerao de processos conhecida como Minerao de Fluxo de Trabalho ou
Minerao de Workflow (Workflow Mining) [Van der Aalst et al. 2003; Van der Aalst
2010].
A ideia de aplicar os conceitos de minerao de processos na rea de processos
de software surgiu com a pesquisa de Cook e Wolf (1998) que tinha como objetivo
oferecer um apoio automatizado para a definio de processos de software, que
considerada uma atividade complexa, custosa e sujeita a erros. As pesquisas nessa
subrea concentram-se principalmente em trs problemas [Van der Aalst 2011]: i)
descoberta de processo ou sntese de processo [Rubin 2007]; ii) verificao de
conformidade [Rozinat e Van der Aalst 2006] e; iii) melhoria de processo [Samalikova
et al. 2011].
29
Durante os anos de pesquisa, diversas ferramentas foram propostas pra auxiliar

nas atividades de minerao de processos: InWoLvE [Herbst 2001], MiMe [Van der
Aalst et al. 2002], Process Miner [Schimm 2002], Little Thumb [Weijters e Van der
Aalst 2003], EMiT [Dongen e Van der Aalst 2004], ProM [Dongen et al. 2005; Van der
Aalst et al. 2009]. Essas ferramentas geralmente realizam a minerao de processo a
partir de arquivos de log gerados por sistemas que representem informaes
transacionais ou registro de atividade como ERP (Enterprise Resource Planning), CRM
(Customer Relationship Management), SCM (Software Configuration Management) ou
WMS (Workflow Management Systems) [Van der Aalst e Weijters 2004]. Para
minerao de processos de software comum a utilizao de arquivos de log gerados
por Sistemas de Controle de Verso [Rubin et al. 2007].
Apesar de vrias solues terem sido propostas, a rea de minerao de
processos se apresenta como uma rea cheia de possibilidades de inovao,
principalmente no que diz respeito minerao de processos de software. Segundo
Rubin et al. (2007), a engenharia de software tornou-se mais complicada que a
engenharia tradicional de produtos fsicos. Processos de software apresentam situaes
peculiares que podem tornar a anlise de processos atravs da minerao uma tarefa no
trivial, j que diferentes projetos podem possuir abordagens de trabalho bastante
distintas, o que torna difcil a generalizao dos procedimentos a serem seguidos [da
Cruz e Ruiz 2008]. Vrias publicaes que apresentam estudos de caso e experincias
na indstria comprovam a aplicabilidade das tcnicas de minerao de processos [Van
Beest e Mruter 2007; Van der Aalst et al. 2007; Goedertier et al. 2010; Samalikova et
al. 2011]. No contexto do ambiente WebAPSEE, a construo de uma infraestrutura
para registro de eventos o primeiro passo para que o ambiente possa evoluir nesta
rea, principalmente com ferramentas para apoio tomada de deciso com base no
histrico dos processos de uma organizao.
No Web site do grupo de pesquisa de Minerao de Processo da Eindhoven
University of Technology pode-se encontrar uma viso sobre o estado da arte na rea de
minerao de processos e suas aplicaes [ProcessMining 2011].
30
3.2 MECANISMO ATUAL DE REGISTRO DE EVENTOS NO WEBAPSEE
A infraestrutura atual de registro de eventos do ambiente WebAPSEE foi

incorporada ao ambiente aps a liberao da primeira verso e resultado do trabalho
descrito por Paxiba et al. (2005). A principal utilizao dessa infraestrutura at hoje foi
na dissertao de mestrado de Carla Paxiba [Paxiba 2007], onde o objetivo era
utilizar os eventos registrados para realizar o acompanhamento de projetos de software.
A partir dos eventos registrados era possvel gerar relatrios gerenciais que permitiam o
gerente de projeto acompanhar os custos, prazos e esforo reais do projeto, comparar
com os valores estimados, analisar os desvios e tomar aes corretivas quando
necessrio. A ferramenta criada para gerar os relatrios, denominada Monitoring
Process, acabou no sendo incorporada ao ambiente WebAPSEE pois muitos dos
relatrios gerados pela ferramenta apresentavam informaes j existentes em outros
relatrios no ambiente WebAPSEE.
Essa infraestrutura de registro de eventos pode ser dividida em duas partes: a
primeira o Pacote Log, que contm as classes que compem o modelo de persistncia
de dados e as classes de acesso aos dados do registro de eventos, e a segunda parte a
classe Logging, que implementa os servios de registro de eventos. O modelo de dados
da infraestrutura atual, apresentado na Figura 6, capaz de armazenar informaes
sobre o que aconteceu (atributo What), quando aconteceu (atributo When), quem foi o
responsvel, neste caso pode ser a mquina de execuo de processos (atributo isApsee
indica se o responsvel foi o Apsee Manager), ou o agente ou atividade (atributo Who),
e a razo da ocorrncia do evento (atributo Why). O valor do atributo What est
relacionado com uma instncia especfica do catlogo de eventos (classe
EventsCatalog) ou pode armazenar a identificao da regra que foi responsvel pela
ocorrncia [Paxiba 2007].
Todas as figuras apresentadas nesta seo e na seo 3.3 foram geradas
automaticamente utilizando a funcionalidade de engenharia reversa da ferramenta
Visual Paradigm [VP Suite 2011]. Optou-se por utilizar engenharia reversa porque a
documentao existente sobre a infraestrutura atual escassa. Alm disso, com a
engenharia reversa os diagramas ficam completos, mostrando como os atributos e os
relacionamentos esto realmente implementados.
31
A seguir, a Figura 6 apresenta as classes contidas no pacote log.classes do

ambiente WebAPSEE.
Figura 6 Modelo de persistncia de dados do registro de eventos atual.
32
Cada processo de software no ambiente WebAPSEE (instncia da classe

Process) tem um log associado (instncia da classe Log), que composto por eventos
(instncias da classe Event). Cada evento pode estar relacionado a um dos seguintes
componentes do ambiente WebAPSEE [Paxiba 2007]:
Modelos de processos (classe ProcessModelEvent);
Atividades (viso do desenvolvedor classe AgendaEvent, viso global classe
GlobalActivityEvent, e eventos de modelagem classe ModelingActivityEvent);
Conexes entre atividades (classe ConnectionEvent);
Recursos (classe ResourceEvent);
Processo de software (classe ProcessEvent).
Os tpicos a seguir resumem as funcionalidades das principais classes do Pacote
Log (tpicos adaptados a partir dos tpicos em [Paxiba 2007]):
Event: a classe principal para descrever ocorrncias em um log de processo.
Cada instncia de Event est relacionada a um tipo de componente do ambiente
WebAPSEE (classe EventType).
ProcessModelEvent: armazena as mudanas de estado para modelos de
processos e atividades decompostas. Cada processo composto por um modelo
de processo, que pode ser definido de uma maneira recursiva, ou seja,
composto de atividades que podem ser decompostas em novos modelos de
processos (chamadas de atividades decompostas).
AgendaEvent: no ambiente WebAPSEE, um agente pode participar de vrios
processos e ser alocado para vrias atividades, e tudo isso exibido na agenda
do agente. O modelo utiliza a classe AgendaEvent para registrar os eventos de
atividades simples de acordo com a viso dos agentes.
GlobalActivityEvent: no ambiente WebAPSEE, uma atividade por ser executada
por vrios agentes ou grupos, e o estado global da execuo da atividade pode
ser diferente do estado da atividade para um determinado agente. As instncias
da classe GlobalActivityEvent registram os eventos de mudana no estado global
de atividades simples. Ao contrrio dos objetos da classe AgendaEvent que
registram as mudanas de estado de uma atividade com relao um
determinado agente ou grupo.
ModelingActivityEvent: registra os eventos relacionados modelagem de
atividade durante a execuo do processo.
33
ConnectionEvent: registra os eventos relacionados conexes. As conexes so

utilizadas no ambiente WebAPSEE para estabelecer ligaes entre atividades e
para descrever controle de processo e fluxo de dados.
ResourceEvent: armazena os eventos relacionados mudana de estados de
recursos, possuindo relacionamento com o meta-modelo do WebAPSEE por
meio do pacote Resources.
ProcessEvent: o processo um elemento de primeira ordem no ambiente
WebAPSEE, sendo definido como uma composio de todos os tipos
mencionados. Todas as mudanas de estado nos processos modelados no
ambiente WebAPSEE so registradas como eventos na classe ProcessEvent.
EventsCatalog: um catlogo com a descrio de todos os eventos que podem
ocorrer para componentes de processo no ambiente WebAPSEE. Portanto, esta
classe contm todos os possveis valores do atributo What.
As classes de acesso aos dados do registro de eventos atual implementam o
padro de projeto Data Access Object (DAO) [Nock 2003], e esto localizadas no
pacote log.dao do ambiente WebAPSEE. Nesse pacote h uma classe DAO para cada
um dos tipos de evento citados anteriormente, e essas classes so responsveis por
realizar operaes de busca, salvamento e excluso de informaes no banco de dados.
Figura 7 Classes de acesso aos dados do registro de eventos atual.
34
A segunda parte da infraestrutura atual de registro de eventos est na classe

Logging, localizada no pacote util do ambiente WebAPSEE, que implementa todos os
servios do registro de eventos atual. A Figura 8 apresenta a classe Logging e os oito
servios fornecidos pela mesma.
Figura 8 Classe Logging atual.
Os servios fornecidos pela classe so implementados nos mtodos com prefixo

register e cada mtodo responsvel por registrar um determinado tipo de evento, por
exemplo, o mtodo registerProcessEvent registra apenas os eventos relacionados s
mudanas de estado nos processos de software, o mtodo registerResourceEvent
registra apenas os eventos relacionados s mudanas de estado de recursos e da mesma
forma para os outros. Esses mtodos so invocados em vrias partes do cdigo do
ambiente WebAPSEE sempre que executada uma ao que precisa ser registrada no
log.
A infraestrutura para registro de eventos proposta neste trabalho foi criada com
base na infraestrutura descrita acima, inclusive algumas classes apresentadas foram
incorporadas proposta com algumas modificaes.
3.3 MECANISMO ATUAL DE NOTIFICAO DE EVENTOS NO WEBAPSEE
A infraestrutura atual de notificao de eventos do ambiente WebAPSEE foi

criada aps a infraestrutura de registro de eventos e tinha como objetivo notificar por e-
35
mail os agentes envolvidos em uma atividade sobre eventos importantes que ocorressem
com a mesma como, por exemplo, a falha ou o cancelamento da atividade. Essa
notificao de eventos depende do registro de eventos, pois sempre que um evento
registrado o mecanismo de notificao invocado para verificar se era necessrio enviar
uma notificao, e caso seja necessrio, as informaes armazenadas no log so
utilizadas para compor a mensagem de notificao.
Essa infraestrutura de notificao de eventos define apenas um mecanismo para
captura de eventos e envio de e-mails de notificao, e no utiliza nenhum modelo de
persistncia de dados. composta pelo Pacote Mail, o qual contm as classes onde as
notificaes so criadas e enviadas, e por um arquivo XML que contm as
configuraes que determinam para quais eventos devem ser notificados e que pessoas
devem receber essas notificaes. Abaixo, a Figura 9 apresenta o Pacote Mail,
localizado em br.ufpa.labes.server.mail no ambiente WebAPSEE, contendo as trs
classes responsveis pela criao e envio das notificaes.
Figura 9 Infraestrutura de notificao de eventos atual (Pacote Mail).
A classe EventNotification responsvel por criar as mensagens que so

enviadas nos e-mails de notificao. Essa classe implementa o padro de projeto
36
Singleton1 [Gamma et al. 1995] e invocada sempre que um evento registrado. A

classe ainda possui seis mtodos de notificao, um para cada tipo de evento
(apresentados na seo 3.2), exceto para os eventos relacionados a conexes, pois foi
considerado desnecessrio enviar uma notificao sempre que uma conexo for
adicionada ou excluda no modelo de processo. O mtodo notifyEvent, que invocado
quando se deseja enviar uma notificao, o responsvel analisar o tipo do evento
registrado e invocar o mtodo de notificao adequado, por exemplo, se o evento
registrado for uma instncia de AgendaEvent o mtodo de notificao invocado pelo
notifyEvent ser o notifyAgendaEvent e da mesma forma para os outros.
A classe NotifyThread foi criada para permitir que o envio das notificaes de
forma concorrente, ou seja, enquanto o envio de um e-mail de notificao est sendo
processado outros procedimentos tambm esto realizados ao mesmo tempo. Aps criar
a mensagem de notificao, uma instncia dessa classe NotifyThread criada recebendo
como parmetros os destinatrios da notificao e a mensagem. Essa instncia de
NotifyThread responsvel apenas por invocar o mtodo sendMessageToUsers da
classe Mail passando como parmetros as mesmas informaes recebidas junto com o
assunto do e-mail. O envio dos e-mails de notificao feito na classe Mail pelo
mtodo sendMessageToUsers.
O arquivo XML onde so feitas as configuraes das notificaes, chamado
event-notification-config.xml. Neste arquivo possvel ativar e desativar o servio de
envio de notificaes, definir os eventos que devem ser notificao e os destinatrios de
cada notificao. Abaixo, o Quadro 1 exemplifica como feita a definio das
notificaes e destinatrios no arquivo XML.
Quadro 1 Exemplo de configurao de notificao no arquivo XML.
1 <event class="log.classes.AgendaEvent" what="ToFailed" constraint="any">
2
<destination type="all-agents"
3
messageKey="util.Mail.SendMail.sendToFailAct"/>
4 </event>
No cdigo do Quadro 1 definido que quando eventos do tipo AgendaEvent

com o atributo What igual a ToFailed forem registrados todos os agentes envolvidos
na atividade devem ser notificados.
Este padro garante a existncia de apenas uma instncia de uma classe, mantendo um ponto global de
acesso ao seu objeto. Na classe EventNotification o ponto global de acesso o mtodo getInstance que
retorna a instncia da classe EventNotification para quem o invocar.
37
Apesar desse mecanismo atual de notificao de eventos possuir essa

infraestrutura, os mtodos de notificao no esto totalmente implementados. Na
infraestrutura atual do ambiente WebAPSEE, apenas dois mtodos de notificao
possuem implementao (notifyGlobalActivityEvent e notifyAgendaEvent), por isso o
mecanismo capaz de enviar apenas notificaes sobre mudana de estado de
atividades. Alm disso, a configurao do mecanismo de notificao s pode ser feita
em nvel de cdigo, por meio da adio de novas regras no arquivo XML, como a
apresentada no Quadro 1. Essas alteraes no cdigo do ambiente exigem um
profissional que conhea o cdigo do ambiente e seja capaz de realizar as
configuraes. Atualmente, o mecanismo de notificao de eventos raramente
utilizado devido dificuldade para configurao do mecanismo, o que um grande ponto
fraco da infraestrutura atual.
A infraestrutura para notificao de eventos proposta neste trabalho estende em
vrios pontos as funcionalidades da atual, oferendo outros tipos de notificao e uma
interface grfica para configurao do mecanismo. Essa proposta apresentada em
detalhes na seo 4 deste trabalho.
38
4 INFRAESTRUTURA PROPOSTA
Este trabalho prope uma infraestrutura para o ambiente WebAPSEE 2.0

composta por dois componentes: o primeiro para realizar o registro de eventos e o
segundo, que depende do primeiro, para enviar notificaes de eventos.
No contexto deste trabalho, considerado como evento qualquer ao
realizada pelo usurio no ambiente, o que inclui, por exemplo, aes de modelagem de
processo, execuo de processo, cadastro e alterao de entidades como agentes, papis
e artefatos, entre outras aes. O Apndice A deste trabalho apresenta um quadro
contendo todos os eventos identificados no ambiente WebAPSEE. A seguir, a Figura 10
ilustra em alto nvel o relacionamento do usurio com o ambiente WebAPSEE 2.0 e dos
componentes internos do ambiente com a infraestrutura proposta.
Figura 10 Relacionamento do usurio com a infraestrutura proposta.
Como ilustrado na Figura 10, o usurio ir se comunicar com o ambiente por

meio de um navegador, ou seja, as aes realizadas pelo usurio so enviadas pela
Internet para o servidor de aplicao do ambiente WebAPSEE. No lado do servidor,
cada ao do usurio corresponde a um evento no ambiente e cada evento dispara a
execuo de um mtodo especfico de um componente interno do ambiente. Para
registrar os eventos ocorridos, os componentes internos do ambiente dependem do
componente de Registro de Eventos. J a infraestrutura de Notificao de Eventos
configurada pelo usurio para definir que notificaes devem ser enviadas e essas
notificaes so recebidas quando o usurio acessa o ambiente ou atravs da sua caixa
39
de e-mail. O componente de Notificao de Eventos depende do componente de

Registro de Eventos para saber quando uma notificao deve ser enviada.
O componente de registro de eventos proposto tem como objetivos: registrar os
eventos ocorridos e permitir que os usurios do ambiente realizem a busca e a
exportao desses registros. Abaixo, a Figura 11a apresenta um diagrama de atividades
que ilustra um exemplo do funcionamento do registro de eventos.
Figura 11a Exemplo do funcionamento do registro de eventos.
Na Figura 11a, o evento Finalizar atividade foi utilizado como exemplo, o

qual ocorre quando o agente finaliza uma atividade. A mquina de execuo de
processos do ambiente chamada para executar o mtodo correspondente a esta ao do
usurio, que no exemplo o mtodo finishTask. Aps realizar o procedimento padro, a
mquina de execuo invoca o mecanismo de registro de eventos solicitando o registro
do evento ocorrido e informando as informaes necessrias. O mecanismo de registro
de eventos cria um objeto para armazenar as informaes do evento, adiciona o evento
ao log, em seguida, solicita a classe de acesso aos dados que persista o objeto criado.
Vale destacar, que esse comportamento o mesmo para o registro de qualquer evento
ocorrido no ambiente.
40
O componente de notificao de eventos proposto tem como objetivo principal

permitir que o usurio escolha as notificaes que deseja receber. A proposta inclui um
Gerenciador de Notificaes onde o usurio poder cadastrar as notificaes que deseja
receber, como deseja receber, visualizar notificaes cadastradas e recebidas, enviar
notificaes recebidas para e-mail, entre outras opes. O mecanismo de notificao
utiliza monitores de evento para saber quando uma notificao deve ser enviada.
Sempre que um usurio cadastra uma notificao que deseja receber, um monitor
criado para aguardar pelo evento. A seguir, a Figura 11b apresenta um exemplo do
funcionamento do mecanismo de notificao de eventos proposto.
Figura 11b Exemplo do funcionamento da notificao de eventos.
O mecanismo de notificao depende do mecanismo de registro de eventos para

saber quando uma notificao deve ser enviada, por isso as trs primeiras atividades no
diagrama da Figura 11b so atividades relacionadas com o registro do evento ocorrido.
O evento Upload de Artefato foi utilizado como exemplo neste diagrama. Aps
realizar o registro do evento, o mecanismo de registro de eventos informa o mecanismo
notificaes sobre a ocorrncia do evento, atravs da invocao de um mtodo
especfico. O mecanismo de notificao busca entre os monitores existentes quais esto
esperando pelo evento ocorrido e notifica estes monitores. O monitor executa o
procedimento de notificao, primeiro verificando a forma de notificao escolhida pelo
41
usurio, que pode ser por e-mail ou por mensagem no ambiente WebAPSEE, e depois
criando e enviando as notificaes adequadas. A proposta deste trabalho tambm inclui
quatro formas de notificaes que so apresentadas mais a frente neste captulo.
Neste captulo, a seo 4.1 apresenta os requisitos definidos para os
componentes propostos e os casos de uso identificados. As sees 4.2 e 4.3 apresentam
a arquitetura da proposta na viso estrutural e comportamental. A seo 4.4 apresenta
alguns prottipos de interface grfica criados. Por fim, a seo 4.5 trs ideias de
possveis aplicaes do registro de eventos no ambiente WebAPSEE 2.0.
4.1 REQUISITOS
Nesta seo so apresentados os requisitos e os casos de uso para os dois

componentes propostos neste trabalho. Os requisitos foram levantados com base na
anlise crtica das infraestruturas de registro e de notificao de eventos do ambiente
WebAPSEE atual, e por meio de reunies realizadas com a equipe de desenvolvimento
do ambiente WebAPSEE.
A seguir, os requisitos dos componentes so apresentados em dois quadros. O
Quadro 2 apresenta os requisitos do componente de registro de eventos e o Quadro 3 os
requisitos do componente de notificao de eventos. Os requisitos apresentados so
divididos em duas categorias: Requisitos Funcionais (RF) e Requisitos No Funcionais
(RNF).
42
Quadro 2 Requisitos do componente de registro de eventos (continua).

REQUISITOS FUNCIONAIS
Requisito
Descrio
RF-01
O componente deve registrar inicialmente os seguintes tipos de eventos:

Acesso ao repositrio de artefatos;
Cadastro e alterao de entidades;
Modelagem de processo;
Execuo de processo;
Gerncia de conhecimento;
Modelo;
Segurana;
Reutilizao de processo.
RF-02
O componente deve registrar todos os eventos apresentados no Apndice A deste

trabalho.
RF-03
O componente deve guardar as seguintes informaes sobre os eventos

ocorridos:
O que aconteceu (atributo what);
Data e hora quando ocorreu o evento (atributo when);
Tipo de evento (atributo kind);
Identificador da entidade afetada pelo evento (atributo which deve
guardar um identificador nico capaz de diferenciar entidades do mesmo
tipo);
Quem foi o responsvel (atributo who caso tenha um usurio envolvido
no evento, deve ser guardado o identificador do usurio que realizou a
ao);
Endereo de IP (atributo ip caso tenha um usurio envolvido no
evento, deve ser guardado o endereo de IP do usurio que realizou a
ao).
RF-04
O componente deve guardar tambm, para eventos de modelagem e execuo de

processo, o local o ocorreu o evento (atributo where), especificando o processo
ou subprocesso onde ocorreu o evento.
RF-05
O componente deve permitir o usurio buscar os registros de evento

armazenados no banco de dados.
RF-06
O mecanismo de busca deve permitir o usurio filtrar quais registros de evento

deseja visualizar. Deve ser permitido filtrar os registros por: processo, evento,
tipo de evento, data e usurio (responsvel pela ocorrncia do evento).
RF-07
O mecanismo de busca deve exibir para o usurio os resultados de uma busca no

formato de uma lista contendo as seguintes informaes: data, evento e tipo do
evento. As demais informaes devem ser exibidas em uma tela de detalhes.
43
Quadro 2 Requisitos do componente de registro de eventos (concluso).

equisito
Descrio
RF-08
O componente deve permitir o usurio exportar os registros de evento retornados

como resultado de uma busca. A exportao pode ser realizada para fins de
backup, para importao dos registros em outro software, e outras finalidades.
RF-09
O mecanismo de exportao deve permitir o usurio exportar os registros de

evento apresentados como resultado de uma busca para os seguintes formatos:
TXT, XLS e XML.
RF-10
O mecanismo de exportao deve ordenar os registros de evento por data e hora

nos arquivos exportados. Aps a data as informaes devem aparecer na seguinte
ordem, separadas por uma barra vertical: tipo de evento, evento, identificador da
entidade afetada, identificador do responsvel pela ocorrncia do evento, outras
informaes especficas.
REQUISITOS NO FUNCIONAIS
RNF-01
O componente deve fornecer uma interface pblica com mtodos que permitam
os outros componentes internos do ambiente WebAPSEE 2.0 registrarem eventos
em momentos especficos definidos no sistema. A interface tambm deve
fornecer os servios de busca e exportao de eventos.
RNF-02
O componente deve permitir o registro de vrios tipos de eventos e ser flexvel o

suficiente para permitir a adio de novos tipos de eventos futuramente.
RNF-03
O componente deve permitir que apenas usurios autenticados como

Administrador ou Gerente de Projeto possam acessar as funcionalidades do
Registro de Eventos.
RNF-04
O componente deve permitir que o Administrador tenha acesso total s

funcionalidades do Registro de Eventos.
RNF-05
O componente deve garantir que os usurios autenticados como Gerente de

Projeto tenham acesso apenas aos eventos dos tipos: Acesso ao Repositrio de
Artefatos, Modelagem de Processo e Execuo de Processo, e apenas dos
projetos nos quais tiver papel de gerente.
O diagrama da Figura 12 apresenta os casos de uso identificados para o registro

de eventos. A descrio dos casos de uso presentes na figura feita no Apndice B
deste trabalho.
44
Figura 12 Diagrama de casos de uso do registro de eventos.
Abaixo, o Quadro 3 apresenta os requisitos do componente de notificao de

eventos.
Quadro 3 Requisitos do componente de notificao de eventos (continua).
REQUISITOS FUNCIONAIS
Requisito
Descrio
RF-01
O componente deve oferecer dois tipos de notificao: interna e externa.

Notificao interna: cadastrada por componentes internos do ambiente.
Notificao externa: cadastrada por usurios do ambiente.
RF-02
O componente deve fornecer uma interface de servios que permita aos

componentes internos do ambiente WebAPSEE se registrarem para receber
notificaes internas.
RF-03
O componente deve permitir o usurio cadastrar as notificaes que deseja

receber e/ou enviar para outro(s) usurio(s).
RF-04
O componente deve permitir o usurio visualizar todas as notificaes pendentes

cadastradas por ele.
RF-05
O componente deve permitir o usurio editar a configurao de uma notificao

cadastrada por ele.
RF-06
O componente deve permitir o usurio cancelar uma notificao cadastrada por

ele.
RF-07
O componente deve permitir o usurio visualizar todas as notificaes recebidas

na forma de um histrico. Quando uma notificao no histrico for selecionada,
os detalhes da notificao devem ser exibidos.
RF-08
O componente deve permitir o usurio limpar o histrico de notificaes

recebidas.
RF-09
O componente deve permitir o usurio excluir uma notificao recebida.
45

Requisito
Descrio
RF-10
O componente deve permitir o usurio enviar uma notificao recebida para um

e-mail.
RF-11
O componente deve permitir o usurio escolher, no momento do cadastro da

notificao, se deseja receber/enviar a notificao por e-mail e/ou por meio de
um alerta no ambiente WebAPSEE.
RF-12
O componente deve ser capaz de enviar inicialmente notificaes externas sobre

eventos dos seguintes tipos:
Eventos de Acesso ao Repositrio de Artefatos;
Eventos de Execuo de Processo;
Eventos de Segurana.
Os eventos especficos que podem ser notificados so listados no Apndice A
desde trabalho.
RF-13
O componente deve enviar notificaes internas apenas sobre eventos do tipo

Execuo de Processo.
RF-14
O componente deve oferecer o seguinte tipo de notificao independente do tipo

de evento a ser notificado:
Notificao simples: com esta notificao o usurio/componente ser
notificado apenas uma vez, assim que o evento ocorrer. Por exemplo, o
usurio/componente deseja ser notificado quando a atividade X finalizar.
RF-15
continua
O componente deve oferecer os seguintes tipos de notificao apenas para

eventos relacionados com mudana de estado de atividade:
Notificao contnua: o usurio/componente ser notificado sempre que
ocorrer uma mudana no estado de uma determinada atividade durante
um perodo especfico. Por exemplo, o usurio/componente deseja ser
notificado sempre que atividade Y mudar de estado no perodo de 01/08
at 01/10. Utilizado para acompanhar o andamento de determinada
atividade. Uma notificao enviada sempre que a atividade escolhida
mudar de estado, at quando for finalizada.
Notificao de estado: o usurio/componente ser notificado sobre
todas as atividades que mudarem para determinado estado durante um
perodo especfico. Por exemplo, o usurio/componente deseja ser
notificado sempre que qualquer atividade mudar para o estado Ready no
perodo de 01/08 at 01/10. Utilizado quando um usurio/componente
desejar saber quando qualquer atividade do processo muda para
determinado estado, por exemplo, um usurio deseja ser notificado sobre
a finalizao de atividades para que este possa realizar uma reviso dos
documentos.
46

Requisito
Descrio
RF-15
concluso
Notificao de processo: o usurio/componente ser notificado sobre

todas as atividades de um determinado processo que mudarem de estado
durante um perodo especfico. Por exemplo, o usurio/componente
deseja ser notificado sobre todas as mudanas de estado no perodo de
01/08 at 01/10. Utilizado para acompanhar o andamento do processo
como um todo. Uma notificao enviada sempre que qualquer
atividade no processo mudar de estado.
RF-16
O componente deve solicitar as seguintes informaes durante o

cadastro/configurao de uma notificao interna:
Processo: o identificador do processo onde est a entidade que deve ser
monitorada.
Entidade: entidade que deve ser monitorada.
Tipo de notificao (opes disponveis dependem da entidade
informada): simples, contnua, de estado ou de processo.
Evento: evento que deve ser notificado.
Perodo de monitorao (apenas para notificaes contnuas, de
estado e de processo): data de incio e data de fim do monitoramento.
Retorno: componente interno notificao atravs da chamada de um
mtodo. Para isso devem ser armazenas as informaes do mtodo que
deve ser chamado: classe, nome do mtodo e parmetros.
RF-17
O componente deve solicitar as seguintes informaes durante o cadastro de uma

notificao externa:
Tipo de evento: acesso ao repositrio, execuo de processo ou
segurana.
Processo (apenas quando tipo de evento for execuo de processo):
processo que deve ser monitorado ou processo onde est a entidade que
deve ser monitorada.
Entidade (exceto quando tipo de evento for segurana): entidade que
deve ser monitorada.
Tipo de notificao (opes disponveis dependem do tipo de evento
informado): simples, contnua, de estado ou de processo.
Evento: qual evento deve ser notificado.
Perodo de monitorao (apenas para notificaes contnuas, de
estado e de processo): data de incio e data de fim do monitoramento.
Meio de notificao: e-mail e/ou alerta no WebAPSEE.
Destinatrios: usurios que devem receber a notificao.
47
Quadro 3 Requisitos do componente de notificao de eventos (concluso).

Requisito
Descrio
RF-18
O componente deve enviar notificaes externa sobre eventos de segurana

contendo as seguintes informaes:
Data e hora de envio da notificao (mesmos da ocorrncia do evento);
Evento ocorrido;
Identificador e endereo de IP do responsvel pela ocorrncia do evento
(se houver).
RF-19
O componente deve enviar notificaes externas sobre eventos que no sejam de

segurana contendo as seguintes informaes:
Data e hora de envio da notificao;
Evento ocorrido;
Nome da entidade;
Estado atual da entidade;
Local onde est localizada a entidade (se houve);
Responsvel pela ocorrncia do evento.
RF-20
O componente deve oferecer para o usurio uma central de gerenciamento de

notificaes de eventos, onde o usurio poder, por exemplo, cadastrar,
visualizar e excluir notificaes. Todas as aes sobre notificaes de eventos
devem estar disponveis nessa central de gerenciamento.
REQUISITOS NO FUNCIONAIS
RNF-01
O componente deve determinar um tempo de vida para as notificaes geradas,

onde aps esse tempo a notificao removida do banco de dados. Esse requisito
busca evitar problema futuros de escalabilidade. Notificaes que foram enviadas
e lidas pelos usurios no precisam ficar armazenas por muito tempo, por isso
so excludas para desocupar o espao ocupado no banco de dados.
RNF-02
O componente deve disponibilizar as funcionalidades de notificao de eventos

para qualquer usurio do ambiente WebAPSEE 2.0.
RNF-03
O componente deve garantir que apenas o Administrador

cadastrar/configurar notificaes sobre eventos de Segurana.
possa
A Figura 13 apresenta o diagrama geral dos casos de uso identificados para a

notificao de eventos. Aps a Figura 13, a Figura 14 apresenta um diagrama que
especifica o caso de uso Gerenciar Notificaes. Esse diagrama de especificao
contm 9 casos de uso que representam as funcionalidade disponveis para os usurios
no Gerenciador Notificaes. A descrio de todos esses casos de uso tambm feita no
Apndice B deste trabalho.
48
Figura 13 Diagrama geral de casos de uso da notificao de eventos.
Figura 14 Especificao do caso de uso Gerenciar Notificaes.
4.2 ARQUITETURA PROPOSTA PARA REGISTRO DE EVENTOS
Durante o projeto arquitetural da infraestrutura do componente de registro de

eventos, foram considerados como prioritrios os requisitos relacionados flexibilidade
49
da infraestrutura (relacionado com o RNF-02). Uma das deficincias da infraestrutura

atual o fato do nmero de eventos que podem ser capturados estar bem abaixo do
nmero total de eventos causados por aes do usurio e, alm disso, a infraestrutura
no permite que novos eventos e tipos de eventos sejam adicionados facilmente ao
modelo. Por isso, a flexibilidade, quanto a adio de novos eventos e tipos de eventos
que venham a surgir no ambiente WebAPSEE, foi uma das principais preocupaes
durante o projeto desta infraestrutura proposta.
A interao do usurio com o registro de eventos proposto acontece de duas
formas: indiretamente quando o usurio est utilizando outras funcionalidades do
ambiente e suas aes causam eventos que so armazenados automaticamente, e
diretamente quando o usurio utiliza o mecanismo de busca de registros de evento para
consultar os eventos registrados.
Nas subsees a seguir, a infraestrutura do componente de registro de eventos
proposto apresentada, primeiramente, a partir de uma viso estrutural e depois a partir
de uma viso comportamental. Os diagramas foram criados utilizando a Unified
Modeling Language (UML) para representar a estrutura e o comportamento da
infraestrutura. Foram utilizados esteretipos e cores para destacar os elementos
propostos pelo trabalho, os adaptados da verso atual e os importados de outros pacotes.
Abaixo so listados os esteretipos e as cores utilizadas em cada um desses elementos:
<< Novo >> e Verde: utilizado nas classes e interfaces novas propostas neste
trabalho.
<< Adaptado >> e Amarelo: utilizado nas classes que j existem no ambiente
WebAPSEE e foram adaptadas para atender a proposta deste trabalho.
<< Importado >> e Rosa: utilizado nas classes e pacote que no fazem parte do
diagrama que est sendo apresentado. So elementos importados para
representar algum tipo de relacionamento com os elementos do diagrama.
4.2.1 Modelo de Dados
O modelo de persistncia de dados do componente de registro de eventos,

apresentado na Figura 15, possui seis classes novas e uma que foram adaptadas do
50
modelo de dados atual de registro de eventos. Este modelo foi proposto com base nos
seguintes requisitos: RF-01, RF-02, RF-03, RF-04, RNF-01 e RNF-02.
Figura 15 Modelo de dados do componente de registro de eventos.
A classe Event representa possui os parmetros que vo armazenar as

informaes dos eventos. Para cada evento ocorrido, uma instncia da classe Event
gerada para armazenar as informaes do evento. Essa classe possui seis atributos e trs
relacionamentos que foram propostos para atender ao requisito RF-03 e RF-04
(requisitos que definem as informaes que devem ser guardadas em cada registro de
evento), e so descritos a seguir:
Relacionamento com EventKind (kind): utilizado para indicar o tipo do evento.
A classe EventKind contm uma constante representando cada tipo de evento
especificado no requisito RF-01.
Relacionamento com EventsCatalog (what): utilizado para indicar qual o
evento registrado. A classe EventsCatalog contm uma constante para cada
evento apresentado no Apndice A (requisito RF-02).
Relacionamento com Log (log): utilizado para indicar a qual log o evento
registrado pertence. Um evento pode ser do Sistema (por exemplo, eventos de
51
segurana), da organizao (por exemplo, eventos de gerncia de conhecimento)

ou do processo (por exemplo, eventos de modelagem e execuo de processo).
Atributo when: salva a data e hora em que o evento foi registrado.
Atributo which: indica a entidade do processo com a qual ocorreu o evento.
Recebe o valor de um identificador nico da entidade. O identificador deve ser
capaz de diferenciar a entidade das outras do mesmo tipo.
Atributo who: salva o login do usurio responsvel pela ocorrncia do evento.
Caso seja um evento causado por algum componente interno do ambiente
WebAPSEE o atributo who ter o valor WebAPSEE.
Atributo where: utilizado apenas em eventos de processo, servindo para
armazenar o local especfico dentro do processo onde ocorreu o evento.
Atributo ip: salva o endereo de IP do computador do usurio responsvel pelo
evento.
Atributo info: utilizado para armazenar informaes complementares.
A classe Log uma classe abstrata que tem como objetivo centralizar os eventos
ocorridos. Para isso ela possui um conjunto de eventos e cada evento ocorrido
adicionado a esse conjunto. Essa classe Log possui trs especializaes, que so
descritas a seguir:
Classe SystemLog: centraliza eventos relacionados com o sistema como um
todo, por exemplo, eventos de segurana e eventos sobre o estado do sistema.
Classe OrgEnvironmentLog: centraliza eventos relacionados com um
determinada organizao, pois nem todos os eventos esto relacionados com
processos de software, alguns esto relacionados com a organizao como um
todo, como o caso dos eventos de gerncia de conhecimento, templates de
processo e de entidades da organizao (agentes, papis, recursos, entre outros).
Classe ProcessLog: centraliza eventos relacionados com um determinado
processo de determinada organizao. Inclui eventos de modelagem de processo,
execuo de processo e controle de verso de artefatos.
A classe Process representa um processo no ambiente WebAPSEE e entre seus
atributos esto o modelo de processo, um conjunto de atividades, um conjunto de
agentes e outros atributos. A classe Process possui uma instncia da classe ProcessLog
onde todos os eventos registrados sobre o processo sero adicionados ao conjunto de
eventos dessa instncia de ProcessLog. J a classe OrgEnvironment representa uma
52
organizao no ambiente WebAPSEE e seus atributos armazenas as informaes da

organizao, seus processos, seus agentes, seus recursos e outros atributos. Essa classe
possui uma instncia da classe OrgEnvironmentLog que armazena no seu conjunto de
eventos todos os eventos relacionados com a organizao.
Caso seja necessrio, este modelo pode ser adaptado para armazenar novos
eventos ou tipos de eventos. Assim, ao adicionar um novo evento basta adicionar uma
constante na classe EventsCatalog para representar o novo evento. O mesmo para a
adio de um novo tipo de evento, onde basta que uma constante seja adicionada na
classe EventKind.
A Figura 16 apresenta as classes de acesso aos dados do componente de registro
de eventos.
Figura 16 Classes de acesso aos dados do componente de registro de eventos.
As classes proposta para permitir o acesso aos dados implementam o padro de

projeto DAO [Nock 2003], assim como na infraestrutura atual. H uma classe DAO
para cada classe do modelo de dados, exceto para as classes que possuem apenas
constantes (EventsCatalog e EventKind). Todas as classes DAO so subclasses da
classe BaseDAO, que uma classe que implementa genericamente operaes bsicas
53
sobre o banco de dados (tais como salvar, atualizar, excluir e recuperar dados). Para que
as classes DAO no precisem reimplementar essas operaes bsicas, elas apenas
estendem a classe BaseDAO. As operaes presentes nas classes DAO servem para
recuperar instncias das classes do modelo de dados.
4.2.2 Mecanismo de Registro de Eventos
O mecanismo de registro de eventos proposto composto por pela interface

chamada ILogging e a classe que implementa os servios fornecido pela interface,
chamada LoggingImpl. A seguir, a Figura 17 apresenta a interface de servios ILogging
que foi proposta para atender aos requisitos RF-05, RF-06, RF-08, RF-09 e RNF-01.
Figura 17 Interface de servios do mecanismo de registro de eventos.
A interface proposta oferece os cinco servios que so descritos as seguir:

registerEvent e registerProcessEvent: mtodos para registro de eventos. Esses
mtodos so chamados em lugares especficos no cdigo do ambiente
WebAPSEE, sempre que necessrio registrar um evento. O mtodo
registerEvent utilizado para registrar qualquer tipo de evento, exceto eventos
de Modelagem de Processo e de Execuo de Processo que so registrados pelo
mtodo registerProcessEvent.
searchEvents: mtodo utilizado quando o usurio deseja buscar registros de
evento. Filtros de busca selecionados pelo usurio so utilizados como
parmetros para a busca. Este mtodo busca atender aos requisitos RF-05 e RF06, que trata de busca de registros de evento.
exportEvents: mtodo para exportao de registros de evento. Usurio pode
exportar os resultados de uma busca. Este mtodo busca atender aos requisitos
RF-08 e RF-09, que tratam de exportao de registros de evento.
54
getEvent: mtodo utilizado para recuperar um registro de evento especfico.

Utilizado quando o usurio deseja visualizar detalhes de um registro de evento.
A exibio de detalhes de registro de evento citada no requisito RF-07.
A Figura 18 apresenta a classe LoggingImpl que implementa a interface descrita.
Para implementar os servios fornecidos pela interface a classe LoggingImpl precisa
utilizar as classes DAO contidas no pacote dataAccess.impl.log.
Figura 18 Implementao da interface de servios do mecanismo de registro de eventos.
4.2.3 Viso Comportamental do Registro de Eventos
A viso comportamental do mecanismo de registro de eventos apresentada por

meio de um diagrama de sequncia. A Figura 19 apresenta o comportamento do
mecanismo de registro de eventos em um cenrio onde ocorreu o evento de upload de
artefato. Apesar de o diagrama representar o comportamento do mecanismo para um
cenrio especfico, esse comportamento o mesmo para o registro de qualquer evento.
No diagrama de sequncia da Figura 19 e em alguns dos prximos que sero
exibidos, as primeiras mensagens enviadas so omitidas, pois no so importantes para
o contexto apresentado. Essas mensagem incluem aes do usurio na interface grfica,
envio de requisio ou arquivo pela Internet, procedimentos de verificao do ambiente
WebAPSEE, entre outras mensagens. Por questes de legibilidade do diagrama, os
parmetros de alguns mtodos no so exibidos no corpo da mensagem, ao invs disso
so exibidos prximo da mensagem em uma anotao.
55
Figura 19 Comportamento do mecanismo de registro de eventos.
56
O procedimento de registro do evento inicia aps o Gerenciador de Artefatos

(ArtifactManagerImpl) receber uma solicitao de upload e realizar o procedimento de
upload de artefato. Depois de realizado o procedimento de upload, este gerenciador
solicita ao LoggingImpl que o evento ocorrido seja registrado. O LoggingImpl criar uma
instncia da classe Event repassando para este as informaes do evento ocorrido. O
prximo passo consiste em adicionar a instncia de Event criada ao Log do processo.
Para isso, o LoggingImpl busca, por meio do ProcessDAO, o processo onde ocorreu o
evento. A partir do processo a instncia de Log adquirida e a instncia de Event
adicionada ao conjunto de eventos. A ltima parte do procedimento consiste em salvar o
evento criado, o que feito por meio do EventDAO.
4.3 ARQUITETURA PROPOSTA PARA NOTIFICAO DE EVENTOS
A infraestrutura do componente proposto para notificao de eventos busca

oferecer ao usurio do ambiente WebAPSEE a possibilidade de cadastrar notificaes,
ou seja, o usurio poder escolher que notificaes deseja receber e como deseja receber.
Isso est relacionado com aos requisitos RF-03 e RF-11. Alm disso, so oferecidas
todas as formas de notificao descritas nos requisitos RF-14 e RF-15 para que o
usurio escolha a que mais se adequa as suas necessidades. Por fim, a proposta oferece
um Gerenciador de Notificaes que onde o usurio gerencia suas notificaes
realizando operaes como cadastrado, cancelamento, visualizao, excluso de
notificaes, entre outras.
Esta seo est organizada da mesma forma que a seo 4.2. Inicialmente,
apresentada a viso estrutural da infraestrutura do componente de notificao de eventos
e em seguida a viso comportamental. O padro de colorao dos diagramas tambm
o mesmo da seo 4.2.
57
4.3.1 Modelo de Dados
O modelo de persistncia de dados do componente de notificao de eventos

apresentado na Figura 20. Esse modelo prope seis classes novas ao ambiente
WebAPSEE, buscando atender aos requisitos RF-01, RF-11, RF-12, RF-13, RF-14, RF15, RF-16, RF-17 e RNF-01.
Figura 20 Modelo de dados do componente de notificao de eventos.
Esse modelo introduz o conceito de monitor de notificao. Um monitor de

notificao um objeto que contm a definio de uma notificao que deve ser
enviada, ou seja, um monitor o objeto que armazena as configuraes da notificao
58
fornecidas pelo usurio. Por isso, para cada notificao cadastrada pelos usurios um
objeto monitor criado. Sempre que um evento registrado, o mecanismo de
notificao verifica os monitores existentes para identificar se algum h algum
esperando pelo evento ocorrido. Os monitores que estiverem esperando pelo evento
registrado so informados e as notificaes so criadas e enviadas.
Na
Figura
20,
dois
tipos
de
monitores
de
notificao:
InternalNotificationMonitor para notificaes internas; e ExternalNotificationMonitor

para notificaes externas. Ambos os monitores so subclasses da classe abstrata
NotificationMonitor que define os atributos e relacionamentos comuns aos dois tipos de
monitor. Esses atributos e relacionamentos comuns so descritos a seguir:
Relacionamento com EventKind (eventKind): utilizado para identificar o tipo
de evento que o monitor est esperando que ocorra. Est relacionado aos
requisitos RF-12 e RF-13, que definem os tipos de evento disponveis para
notificao.
Relacionamento com NotificationKind (notificationKind): utilizado para
identificar o tipo de notificao escolhida pelo usurio. Est relacionado aos
requisitos RF-14 e RF-15, que definem os tipos de notificao.
Relacionamento com EventsCatalog (event): classe importada do modelo de
registro de eventos. Utilizada para identificar o evento que o monitor est
aguardando.
Atributo process: identifica o processo onde est localizada a entidade
relacionada com o evento. Este atributo s utilizado quando a notificao
cadastrada tem o tipo de evento igual a Execuo de Processo ou Acesso ao
Repositrio de Artefatos.
Atributo entity: identifica a entidade relacionada com o evento. Este atributo s
utilizado quando a notificao cadastrada tem o tipo de evento igual a
Execuo de Processo ou Acesso ao Repositrio de Artefatos. Entidade pode ser
um processo, atividade, recurso ou artefato.
Atributos startData e endDate: so atributos do tipo data, utilizados para
identificar o perodo em que deve ocorrer o monitoramento. Estes atributos s
so utilizados quando a notificao cadastrada tem tipo de notificao igual a
Continua, de Estado ou de Processo (esses tipos so definidos no requisito RF15).
59
Atributo active: utilizada para indicar se o monitor est ativo ou ainda

aguardando pela ocorrncia do evento.
A classe ExternalNotificationMonitor possui apenas atributos relacionados com
a forma de envio da notificao, o que definido no requisito RF-11 como por e-mail
ou por alerta no ambiente WebAPSEE. A classe InternalNotificationMonitor possui trs
atributos que so utilizados para chamar um mtodo de uma classe. O atributo
className guarda o nome da classe, o methodName guarda o nome do mtodo e o args
guarda os parmetros do mtodo. Diferente das notificaes externas onde so enviadas
mensagens de notificao, as notificaes internas so realizadas atravs da chamada de
mtodos.
A classe Notification representa as notificaes recebidas pelos usurios. Possui
atributos relacionados com o evento ocorrido, a entidade afetada e a data de envio da
notificao. O atributo expirationDate define a data em que a notificao ser
descartada do banco de dados. Esse atributo foi criado para atender ao requisito de
escalabilidade RNF-01, o qual define que as notificaes devem ter um tempo de vida.
A classe Agent representa o agente que cria as notificaes e recebe as notificaes.
Cada agente cadastrado no ambiente possui uma caixa de notificaes, representada no
diagrama pela classe Inbox. Todas as notificaes enviadas para um agente so
adicionadas na sua caixa de notificaes e ficam disponveis para o agente consult-las.
A Figura 21 apresenta as classes de acesso aos dados do componente de
notificao de eventos.
60
Figura 21 Classes de acesso aos dados do componente de notificao de eventos
A estrutura desse conjunto de classes bem similar estrutura apresentada na

Figura 14. As classes tambm implementam o padro de projeto DAO e todas so
subclasses da classe BaseDAO. As operaes presentes nas classes servem para
recuperar objetos dos monitores e de notificaes.
4.3.2 Mecanismo da Notificao de Eventos
O mecanismo de notificao de eventos proposto composto por uma interface

e uma classe que implementa a interface, assim como no registro de eventos. A Figura
22 apresenta a interface de servios de notificao de eventos, que busca atender aos
requisitos RF-02, RF-03, RF-04, RF-05, RF-06, RF-07, RF-08, RF-09 e RF-10.
61
Figura 22 Interface de servios do mecanismo de notificao de eventos.
Na
Figura
22,
os
mtodos
createInternalNotificationMonitor
createExternalNotificationMonitor tiveram alguns parmetros omitidos para que a

figura pudesse ser apresentada em um tamanho legvel. A seguir, a lista completa de
parmetros dos dois mtodos apresenta.
A interface proposta IEventNotification
oferece os dez servios que so descritos as seguir:

notifyEventOccurrence: este mtodo invocado pelo registro de eventos
sempre que um evento registrado. Ele responsvel por verificar se h algum
monitor esperando o evento ocorrido, se houve o monitor notificado.
createInternalNotificationMonitor:
mtodo
utilizado
para
criao
de
notificaes internas. Componentes internos invocam este mtodo passando as

configuraes desejadas (relacionado com o requisito RF-02). Lista de
parmetros do mtodo (process : String, entity : String, noteKind :
NotificationKind, eventKind : EventKind, event : EventsCatalog, startDate :
Date, endDate : Date, className : String, MethodName : String, args :
Object[]).
createExternalNotificationMonitor:
mtodo
utilizado
para
criao
de
notificaes externas. invocado pela interface grfica de cadastro de

notificao sempre que o usurio salva uma nova notificao (relacionado com o
requisito RF-03). Lista de parmetros do mtodo (eventKind : EventKind,
process : String, entity : String, noteKind : NotificationKind, event :
EventsCatalog, startDate : Date, endDate : Date, sendEmail : boolean,
sendAlert : boolean, agents : String, emails : String).
cancelNotificationCreated: mtodo utilizado para cancelamento de notificaes
criadas, o que definido no requisito RF-06.
62
deleteNotificationReceived:
mtodo
utilizado
para
excluir
notificaes
recebidas, o que definido no requisito RF-09.

clearAgentNotificationsReceivedHistory: mtodo utilizado para limpar o
histrico de notificaes recebidas, o que definido no requisito RF-08.
sendReceivedNotificationToEmail:
mtodo
utilizado
para
enviar
uma
notificao recebida para um endereo de e-mail, o que definido no requisito

RF-10.
Mtodos com prefixo get: mtodos utilizados para recuperar notificaes
criadas, recebidas e notificaes especficas. Esto relacionados aos requisitos
RF-04, RF-07 e RF-20.
A Figura 23 apresenta a classe EventNotificationImpl que implementa a interface
descrita. Para implementar os servios fornecidos pela interface a classe
EventNotificationImpl
precisa
utilizar
as
classes
DAO
contidas
no
pacote
dataAccess.impl.notificationLog e o servio de envio de e-mail oferecido pelo pacote

notifications.mail como representado na figura.
Figura 23 Implementao da interface de servios do mecanismo de notificao de

eventos.
63
4.3.3 Viso Comportamental da Notificao de Eventos
A viso comportamental do mecanismo de notificao de eventos apresentada

em dois diagramas de sequncia. O diagrama de sequncia representado na Figura 24
apresenta o comportamento do mecanismo para envio de notificaes internas e o
diagrama da Figura 25 apresenta o comportamento para envio de notificaes externas.
Os dois diagramas representam as atividade realizadas em um cenrio especfico, mas o
procedimento sempre o mesmo independente do cenrio.
Figura 24 Comportamento do mecanismo de notificao interna Criao de

notificao.
A Figura 24 ilustra o comportamento do mecanismo de notificao ao receber

uma solicitao de criao de notificao interna. Apesar de o diagrama mostrar o
procedimento para notificaes internas, para as notificaes externas o procedimento
o mesmo.
O procedimento para registro de uma notificao inicia quando o componente
interno ou o usurio envia uma solicitao de criao de notificao, na Figura 19 a
solicitao feita por meio da chamada do mtodo createInternalNotificationMonitor.
Ao receber a solicitao, o EventNotificationImpl, imediatamente, cria uma instncia do
monitor de eventos necessrio e repassa pra este as informaes cadastradas pelo
componentes interno ou o usurio. Neste momento, o procedimento encerrado e a
64
partir de agora o monitor ser consultado sempre que ocorrer um evento, para saber se o
evento ocorrido o evento esperado pelo monitor.
A seguir, a Figura 25 apresenta o comportamento do mecanismo para envio de
notificaes externas.
Figura 25 Comportamento do mecanismo de notificao externa Envio de notificao.
65
O diagrama na Figura 25 inicia quando a mquina de execuo de processo

(EnactmentEngineImpl) solicita que o evento ocorrido (atividade iniciada) seja
registrado, o que feito por meio da chamada do mtodo registerProcessEvent. O
LoggingImpl registra o evento e em seguida informa o EventNotificationImpl, por meio
mtodo notifyEventOccurrence, que um evento foi registrado. O EventNotificationImpl
busca, por meio do ExternalNotificationMonitorDAO, todos os monitores que esto
interessados no evento interessado. Essa busca feita utilizando o processo e a entidade
afetada pelo evento ocorrido. Aps obter o conjunto de monitores interessados no
evento, o EventNotificationImpl percorre o conjunto para verificar quais precisam ser
notificados, e quando encontra um interessado invoca o mtodo notify para notificar o
monitor. Na Figura 25, ilustrado o cenrio em que o usurio cadastrou uma
notificao por envio de e-mail. Para enviar o e-mail o mtodo sendMessage invocado
passando nos parmetros a mensagem de notificao, o e-mail dos destinatrios e o
assunto do e-mail. Outro cenrio seria para notificaes internas, onde a notificao
feita
por
meio
da
chamada
de
mtodos.
Neste
segundo
cenrio,
InternalNotificationMonitor possui armazenados o nome da classe, o nome do mtodo e

os argumentos que devem ser enviados. A partir dessas informaes possvel enviar a
notificao atravs da chamada do mtodo.
4.4 PROTTIPOS DE INTERFACE GRFICA
Nesta seo so apresentados cinco prottipos de interface grfica que foram

produzidos com base nos requisitos apresentados na seo 4.1. Esses prottipos foram
criados, principalmente, para mostrar a ideia inicial da interface grfica que o usurio
ter para buscar os registros de evento e para gerenciar suas notificaes.
O primeiro prottipo, na Figura 26, apresenta a interface grfica para busca de
registros de evento. Nessa interface o usurio pode selecionar os filtros de busca do lado
direito e visualizar os resultados encontrados no lado esquerdo, podendo tambm
visualizar detalhes de um registro de evento e exportar os resultados encontrados.
66
Figura 26 Prottipo de interface grfica para a busca de registros de evento.
Os outros quatro prottipos esto relacionados com o Gerenciador de

Notificaes. A Figura 27 apresenta a interface grfica inicial do Gerenciador de
Notificaes, mostrando no lado esquerdo as notificaes recebidas pelo usurio no
ltimo ms e no lado direito trs abas, a primeira (Principal) para cadastro de
67
notificaes, a segunda (Cadastradas) para visualizar as notificaes cadastradas, e a

terceira (Recebidas) para visualizar as notificaes recebidas.
Figura 27 Prottipo de interface grfica para o Gerenciador de Notificaes.
A Figura 28 apresenta o cadastro de notificaes. As opes so apresentadas

quando o usurio seleciona a aba Principal. O cadastro de uma notificao feito em
etapas, por isso nem todas as opes apresentadas na Figura 28 so apresentadas
inicialmente, algumas so mostradas dependendo de uma escolha anterior.
68
Figura 28 Prottipo de interface grfica para o cadastro de notificaes.
A Figura 29 apresenta a visualizao das notificaes cadastradas. As opes

so apresentadas quando o usurio seleciona a aba Cadastradas. Nessa interface o
usurio pode buscar as notificaes cadastradas por ele, editar uma notificao
cadastrada e cancelar um cadastro. A busca das notificaes feita a partir dos filtros
selecionados no lado direito da interface.
69
Figura 29 Prottipo de interface grfica para visualizao de notificaes cadastradas.
A Figura 30 apresenta a visualizao das notificaes recebidas. As opes so

apresentadas quando o usurio seleciona a aba Recebidas. Nessa interface o usurio
pode buscar as notificaes recebidas, visualizar detalhes, excluir notificaes e enviar
uma notificao recebida para um endereo de e-mail. A busca das notificaes feita a
partir dos filtros selecionados no lado direito da interface. As notificaes recebidas
70
ficam disponveis para consulta por um ms aps o recebimento, depois deste prazo elas
so automaticamente excludas do banco de dados.
Figura 30 Prottipo de interface grfica para visualizao de notificaes recebidas.
71
4.5 APLICAES DO REGISTRO DE EVENTOS NO WEBAPSEE 2.0
A partir de reunies com a equipe de desenvolvimento do ambiente WebAPSEE,

foram identificadas diversas possibilidade de utilizao do registro de eventos no
ambiente WebAPSEE 2.0. A notificao de eventos apenas uma dessas aplicaes que
foi escolhida para demostrar a importncia do registro de eventos para o ambiente. A
seguir, so listadas algumas das aplicaes mais promissoras do registro de eventos:
Monitoramento de acesso ao repositrio: os eventos relacionados com
download e upload de artefatos podem oferecer ao gerente, por exemplo, uma
viso de como est ocorrendo a produo, a atualizao ou a reviso dos
artefatos do projeto. Outra opo a gerao de um relatrio que permita o
gerente acompanhar o andamento do projeto a partir dos artefatos produzidos.
Histrico de entidades: esse histrico inclui todos os eventos de cadastros,
modificao e excluso de entidades no ambiente. O objetivo seria mostrar a
evoluo ou as atualizaes de uma entidade ao longo do tempo. A utilidade
dessa aplicao destaca-se quando se utiliza a entidade agente como exemplo.
O histrico do agente na organizao mostraria, por exemplo, quando o agente
foi cadastrado no ambiente, quando adquiriu uma nova habilidade, quando
recebeu novos papis ou quando foi includo em um grupo, at o dia em o
agente fosse desativado.
Histrico de modelagem de processo: esse histrico inclui todos os eventos
relacionados com a modelagem do modelo de processo. Poderia ser utilizado em
mais de uma aplicao, por exemplo, realizar a reconstruo do modelo de
processo, para implementar a funcionalidade de desfazer e refazer aes de
modelagem, entre outras aplicaes.
Histrico de execuo de processo: esse histrico inclui todos os eventos
relacionados com a execuo das atividades do processo. Tambm pode ser
utilizado em mais de uma aplicao, por exemplo, uma aplicao simples seria a
gerao de um relatrio que oferecesse uma viso diferente das vises
disponveis atualmente para o acompanhamento da execuo das atividades.
72
Outras aplicaes seriam na rea de anlise post-mortem2 e simulao de

processo.
Auditoria: essa uma aplicao clssica de qualquer registro de eventos. Os
eventos registrados podem ser utilizados para gerar relatrios que permitam, por
exemplo, a auditoria da modelagem e da execuo do processo, das entidades da
organizao (agentes, artefatos, recursos, projetos e outros) e da segurana do
ambiente. A auditoria tambm poderia ser realizada manualmente, utilizando
apenas a interface grfica para consulta e visualizao dos eventos registrados.
Todas essas aplicaes citadas buscam oferecer ao gerente de projeto novas
formas de controlar, visualizar e analisar os projetos e o andamento dos mesmos. Vale
lembrar que o registro de eventos no est limitado a essa aplicaes, essas so s ideias
iniciais que servem para destacar sua importncia.
Anlise que feita aps a finalizao do projeto.
73
5 CONSIDERAES FINAIS
Este trabalho apresentou uma proposta de infraestrutura de registro e de

notificao de eventos para o ambiente WebAPSEE 2.0. O objetivo inicial do trabalho
era registrar automaticamente os eventos ocorridos no ambiente e enviar notificaes
para os usurios sobre a ocorrncia de determinados eventos.
A soluo proposta neste trabalho foi alm dos objetivos iniciais. Em relao ao
registro de eventos, a proposta oferece o registro automtico dos eventos no ambiente, e
um mecanismo para busca de registros armazenados em banco de dados e um
mecanismo para realizar a exportao dos registros. Durante o projeto arquitetural da
infraestrutura, foram considerados como prioritrios os requisitos relacionados
flexibilidade. Por isso, a infraestrutura proposta permite que seja realizada com
facilidade a adio de novos eventos e tipos de eventos ao modelo.
Em relao notificao de eventos, foi proposta uma infraestrutura que permite
o usurio cadastrar as notificaes que deseja receber. Alm do cadastro das
notificaes o usurio tem vrias outras interaes possveis por meio do Gerenciador
de Notificaes como, por exemplo, cancelar notificaes, visualizar histrico de
notificaes recebidas, entre outras. Alm disso, a infraestrutura tambm permite que
componentes internos do ambiente WebAPSEE tambm se registrem para serem
notificados.
5.1 DIFICULDADES ENCONTRADAS
A principal dificuldade encontrada durante o trabalho estava relacionada falta

de trabalhos correlatos. Nas pesquisas realizadas no foram encontrados trabalhos
relacionados com a utilizao ou implementao de registro de eventos em PSEEs,
ferramentas de gerncia projeto, ou outras ferramentas do gnero. Na verdade, h
muitas pesquisas envolvendo o registro de eventos nas reas de minerao de dados,
usabilidade, segurana e outras, mas nenhuma foi encontrada em contexto similar ao
deste trabalho.
74
5.2 TRABALHOS FUTUROS
Como trabalhos futuros em relao infraestrutura proposta neste trabalho,

pretende-se definir melhor as funcionalidades de exportao de registro de eventos e de
notificaes para componentes internos, que so duas funcionalidades definidas nos
requisitos deste trabalho, mas que no tratadas adequadamente pela arquitetura
proposta. Em seguida, pretende-se implementar um prottipo da proposta no ambiente
WebAPSEE 2.0. Essa implementao no foi realizada durante o trabalho, pois o
ambiente encontra-se na fase de desenvolvimento e no seria possvel realizar testes
para avalia o prottipo j que o ambiente ainda no est em estado funcional.
Alm disso, importante identificar outras possibilidades de utilizao do
registro de eventos no ambiente WebAPSEE, alm das possibilidades apresentadas
anteriormente. A implementao dessas funcionalidades identificadas vai permitir
avaliar se a infraestrutura de registro de eventos atende as necessidades do ambiente
conforme o planejado ou se precisa de melhorias.
Na rea de minerao de processos, os registros podem ser aplicados
futuramente em vrias funcionalidades como, por exemplo, para gerao de relatrios,
simulao de processo, criao de uma linha do tempo (timeline) mostrando como
ocorreu a execuo do processo, entre outras possibilidades.
75
REFERNCIAS BIBLIOGRFICAS
ADOBE. Adobe Flex, 2011. Disponivel em: <http://www.adobe.com/br/products/flex/

>. Acesso em: 01 nov. 2011.
AGRAWAL, R.; DIMITRIOS, G.; LEYMANN, F. Mining Process Models from

Workow Logs. EDBT '98 Proceedings of the 6th International Conference on
Extending Database Technology: Advances in Database Technology, Londres, p.
469-483, Janeiro 1998.
ALVES, M. P. et al. MiddLog: Uma Infra-estrutura de servios de log de aplicaes

baseadas em tecnologias de middleware. Simpsio Brasileiro de Redes de
Computadores. Belm: [s.n.]. 2007.
AVRILIONIS, D.; CUNIN, R.; FERNSTRN, C. OPSIS: A view mechanism for

software process which supports their evolution and reuse. Proceedings oh the 18th
International Conference on Software Engineering, Berlim, Maro 1996.
BEN-SHAUL, I.; KAISER, G. Federating Process-Centered Environments: The OZ

Experience. Automated Software Engineering, v. 5, p. 97-132, 1998 Janeiro 1998.
BOEHM, B. A spiral model of software development and enhancement. Computer, v.
21, n. 5, p. 61-72, 1988.
BOLCER, G.; TAYLOR, R. Endeavors: A Process System Integration Infrastructure.

Proceedings of the 4th International Conference on the Software Process,
Dezembro 1996.
BOSS, E. JBoss Community, 2011. Disponivel em: <http://www.jboss.org/>. Acesso

em: 01 nov. 2011.
BURBECK, S. Applications Programming in Smalltalk-80: How to use ModelView-Controller (MVC). [S.l.]: Softsmarts, 1987.
76
BUSCHMANN, F. et al. Pattern-Oriented Software Architecture: A System of

Patters. [S.l.]: Addison-Wiley, v. Wiley Serieis in software Design Patterns 1, 1996.
CONRADI, H. et al. EPOS: object-oriented cooperative process modelling. In:

FINKELSTEIN, A.; KRAMER, J.; NUSEIBEH, B. Software process modelling and
technology. Taunton: Publisher Research Studies Press Ltd., 1994. p. 33-70.
COOK, J.; WOLF, A. Discovering Models of Software Process from Event-Based Data.
ACM Transactions on Software Engineering, 1998. 215-249.
CORPORATION, O. Core J2EE Patterns - Data Access Object, 2010. Disponivel em:
<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>.
Acesso em: 25 nov. 2011.
CUGOLA, G. et al. Support for Software Federations: the PIE Plataform. European
Workshop on Software Process Tecnology. Kaprun: [s.n.]. 2000.
CURTIS, B.; KRASNER, H.; ISCOE, N. A Field Study of the Software Design Process
for Large Systems. Coomunications of ACM, 1988.
CVS.
CVS
Concurrent
Versions
System,
2011.
Disponivel
em:
<http://cvs.nongnu.org/>. Acesso em: 19 dez. 2011.
DA CRUZ, J.; DUNCAN, R. Uma experincia em minerao de processos de

manuteno de software. XIV Brasilian Symposium on Multimedia and the Web.
Vila-Velha: [s.n.]. 2008.
FOWLER, M. Patterns of Enterprise Aplication Architecture. [S.l.]: AddisonWesley, 2002.
FUGGETTA, A. Software Process: A Roadmap. International Conference of Software

Engineering. Limerick: [s.n.]. 2000.
77
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software.

1. ed. [S.l.]: Addison-Wesley, 1995.
GIMENES, I. M. O Processo de Engenharia de Software: Ambientes e Formalismos.

XIII Jornada de Atualizao em Informmtica, XIV Congresso da SBC. Caxamb:
[s.n.]. 1994.
GOEDERTIER, S. et al. Process Discovery in Event logs: An Application in the

Telecom Industry. Applied Soft Computing, 2010.
GOOGLE. Google Web Toolkit, 2011. Disponivel em: <http://code.google.com/intl/ptBR/webtoolkit/ >. Acesso em: 01 nov. 2011.
GRUHN, V. Process-Centered Software Engineering Environments: A brief history and

future Challenges. Annals of Software Engineering, v. 14, p. 363-382, 2002.
GRUNDY, J. et al. An architecture and enviroment for descentralized, internet-wide

software process modeling and enactment. IEEE Internet Computing: Special Issue
on Software Engineering via the Internet, v. 2, n. 5, 1998.
HERBST, J. An inductive approach to the acquisition and adaptation of workflow

models. Proceedings of the IJCAI'99. Workshop on Intelligent Workflow and Process
Management: the New Frontier for AI Business. Stockholm: [s.n.]. 1999. p. 52-57.
HERBST, J. Ein induktiver Ansatz zur Akquisition und Adaption von WorkflowModellen. Universitt Ulm. Berlin. 2001.
JACCHERI, M.; PICCO, G.; LAGO, P. Eliciting software process models with the E3
language. ACM Transactions on Software Engineering and Methodology
(TOSEM), New York, Outubro 1998. 368 - 410.
LABES. Documentao de Referncia do Sistema WebAPSEE 1.0 (beta), 2011.

Disponivel
em:
78
<http://www3.ufpa.br/webapsee/images/documentacaoWebAPSEE/doc%20de%20refer
encia.pdf>. Acesso em: 31 out. 2011.
LIMA REIS, C. A. Uma Abordagem Flexvel para Gesto de Processos de

Software. Universidade Federal do Rio Grande do Sul. Porto Alegre, p. 277. 2003.
LIMA REIS, C.; REIS, R. Q.; NUNES, D. APSEE: Uma Abordagem Integrada para
Automao de Processos de Software. Simpsio Brasileiro de Automao Inteligente.
[S.l.]: [s.n.]. 2001.
LIMA, A. et al. Gerncia Flexve de Processos de Software com o Ambiente

WebAPSEE. Simpsio Brasileiro de Engenharia de Software. Florianpolis: [s.n.].
2006.
MA, D.; TSUDIK, G. A New Approach to Secure Logging. ACM Transactions on

Storage, Maro 2009.
MARUSTER, L. et al. Process Mining: discovering direct succesors in process logs.

Proceedings of the 5th International Conference on Discovery Science. Berlin: [s.n.].
2002. p. 364-373.
MONTONI, M. et al. Uma Abordagem de Garantia de Qualidade de Processos e

Produtos de Software com Aopio de Gerncia de Conhecimento na Estao TABA.
V Simpsio Brasileiro de Qualidade de Software. Vila Velha: [s.n.]. 2006.
MYSQL. MYSQL, 2011. Disponivel em: <http://www.mysql.com/ >. Acesso em: 31

out. 2011.
NAGAPPAN, M.; VOUK, M. Abstrating log lines to log event types for mining
software logs. The proceedings 7th Working Conference on Mining Software
Repositories. Cape Town: [s.n.]. 2010. p. 114-117.
79
NIELSEN, J.; MOLICH, R. Heuristic evaluation of user interfaces. Proceedings of

the SIGCHI Conference on Human Factors in Computing Systems: Empowering
People. Seattle: [s.n.]. 1990.
NOCK, C. Data Access Patterns: Database Interactions in Object-Oriented

Applications. [S.l.]: Addison-Wesley Professional, 2003.
NURMINEN, M.; HONKARANTA, A.; KRKKINEN, T. ProcMiner: Advancing

Process Analysis and Management. IEEE 23th International Conference on Data
Engineering Workshops. Istambul: [s.n.]. 2007.
OLIVEIRA, J. F. Abordagem para Implantao de Gerncia do Conhecimento com

Apoio de um Ambiente de Desenvolvimento de Software Centrado em Processos.
Universidade Federal do Par. Belm. 2010.
ORACLE.
Enterprise
JavaBeans
Technology,
2011.
Disponivel
em:
<http://www.oracle.com/technetwork/java/javaee/ejb/index.html >. Acesso em: 27 nov.

2011.
ORACLE. Java, 2011a. Disponivel em: <http://www.java.com/pt_BR>. Acesso em: 31

out. 2011.
ORACLE.
The
Swing
Tutorial,
2011b.
Disponivel
em:
<http://download.oracle.com/javase/tutorial/uiswing/ >. Acesso em: 31 out. 2011.
ORACLE.
Remote
Method
Invocation,
2011c.
Disponivel
em:
<http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html >. Acesso

em: 31 out. 11.
O'REILLY, T. What is web 2.0: Design Patters and Business Models for the Next
Generation of Software. Communications & Strategies, 2007. 17.
OSTERWEIL, L. Software processes are software too. Proceedings of the 9th

International Conference on Software Engineering. Monterey: [s.n.]. 1987.
80
PARADIGM,
V.
Visual
Paradism
Products
Page,
2011.
Disponivel
em:
<http://www.visual-paradigm.com/product/?favor=vpuml.>. Acesso em: 25 nov. 2011.

PAULK, M. C. et al. The Capability Maturity Model: Guidelines for Improving the
Software Process. 1. ed. [S.l.]: Addison-Wesley Professioal, 1995.
PAXIBA, C. Acompanhamento e Avaliao de Projetos atravs da Monitorao

de Eventos em um Ambiente de Gesto de Processos de Software. Universidade
Federal do Par. Belm. 2007.
PAXIBA, C. et al. Towards an Event Recording Mechanism for a Process-based

Enviroment. Seminrio Integrado de Software e Hardware. So Leopoldo: [s.n.]. 2005.
PKOACH. Project Koach, 2011. Disponivel em: <http://www.projectkoach.com >.
Acesso em: 30 out. 2011.
PROCESS MINING GROUP, M. D. E. U. O. T. Process Mining, 2009. Disponivel em:

<http://www.processmining.org/>. Acesso em: 25 nov. 2011.
REIS, R. Q. APSEE-Reuse: Um Meta-Modelo para Apoiar a Reutilizao de

Processos de Software. Universidade Federal do Rio Grande do Sul. Porto Alegre.
2002.
RSCH, P. et al. The Spearmint Software Process Modeling Enviroment.

International Conference on Software Engineering. Kyoto: [s.n.]. 1998.
ROZINAT, A.; VAN DER AALST, W. Conformance Testing: Measuring the Fit and
Appropriateness of Event Logs and Process Models. Workshop on Bisuness Process
Intelligence. [S.l.]: [s.n.]. 2006.
RTCONCERT. Rational Team Concert, 2011. Disponivel em: <http://www01.ibm.com/software/rational/products/rtc/ >. Acesso em: 27 nov. 2011.
RUBIN, V. A Workflow Mining Approach for Deriving Software Process Models.

University of Paderborn. Paderborn. 2007.
81
RUBIN, V. et al. Process Mining Framework for Software Processes. International

Conference on Software Process. [S.l.]: [s.n.]. 2007.
SALES, E. et al. WebAPSEE Pro: Um Ambiente de Apoio a Gerncia de Processos de

Software. VI Worlshop Anual do MPS. Campinas: [s.n.]. 2010.
SALES, E.; COSTA, A. Uma Proposta para Reutilizao de Processos de Software

para o Ambiente WebAPSEE. Universidade Federal do Par. Belm. 2007.
SALES, E.; LIMA REIS, C.; LIMA, A. Gesto de Configurao integrada a

Gerncia de Processos de Software no Ambiente WebAPSEE. Conferncia Latino
Americana de Informtica - CLEI. San Jose: [s.n.]. 2007.
SALES, M. F. Gerncia de Requisitos Integrada Gerncia de Projetos de

Software no Ambiente WebAPSEE. Universidade Federal do Par. Belm. 2008.
SAMALIKOVA, J.; KUSTERS, R.; WEIJTERS, T. Towards Objective Software

Process Information: Experiences from a Case Study. Software Quality Journal,
Maro 2011. 101-120.
SANTOS, G. et al. MPS.BR: A Tale of Software Process Improvement and

Performance Results in the Brazilian Industry. Quality of Information and
Communications Technology, 7th International Conference on the Quality of
Information and Communications Technology. Porto: [s.n.]. 2010.
SCHIMM, G. Process Miner - A Tool for Mining Process Schemes from Eventbased Data. European Conference on Logics in Artificial Intelligence. Corenza: [s.n.].
2002.
SEI. CMMI, 2002. Disponivel em: <http://www.sei.cmu.edu/cmmi/ >. Acesso em: 29

nov. 2011.
82
SOFTEX. MPS.BR, 2009. Disponivel em: <www.softex.br/mpsbr/ >. Acesso em: 31

out. 2011.
SUBVERSION.
Tigris.org
Project
Subversion,
2011.
Disponivel
em:
<http://subversion.tigris.org/>. Acesso em: 19 dez. 2011.
TRAVASSOS, G.; KALINOWSKI, M. Resultados Iniciais iMPS 2010: Variao de

Desempenho nas Empresas que Adotaram o Modelo MPS. Workshop Anual do MPS.
Campinas: [s.n.]. 2010.
VAN DE AALST, W. Challenges in Business Process Mining. Applied Stochastic

Models in Business and Process Management. [S.l.]: [s.n.]. 2010.
VAN DER AALST, W. Workflow Mining: Which Processes can be Rediscovered?.

BETA Working paper Series, Eindhoven, 2002.
VAN DER AALST, W. Process Mining Discovery, Conformance and Enhacement

of Business Process. 1. ed. [S.l.]: Springer, 2011.
VAN DER AALST, W. et al. Workflow Mining: A Survey of Issues and Approaches.
Data and Knowledge Engineering, v. 47, p. 237-267, Julho 2003.
VAN DER AALST, W. et al. Business Process Mining: An Industrial Application.

Information Systems , v. 32, n. 5, p. 713-732, Julho 2007.
VAN DER AALST, W. et al. ProM: The Process Mining Toolkit. Workshop CEUR.
[S.l.]: [s.n.]. 2009. p. 1-4.
VAN DER AALST, W.; WEIJTERS, A. Process mining: a research agenda.

Computers in Industry, v. 53, p. 231-244, 2004.
VAN DER AALST, W.; WEIJTERS, T.; MARUSTER, L. Workflow Mining:

Discovering Process Models from Event Logs. IEEE Transactions on Knowledge and
Data Engineering, v. 16, Setembro 2004.
83
VAN DER BEEST, N.; MARUSTER, L. A Process Mining Approach to Redesign

Business Process - a case study in gas industry. 9th International Symposium on
Symbolic and Numeric Algorithms for Scientific Computing. Timisoara: [s.n.]. 2007.
VAN DONGEN, B. et al. The ProM framework: A New Era in Process Mining Tool
Support. International Conference on Applications and Theory of Petri Nets. Miami:
Springer. 2005.
VAN DONGEN, B.; VAN DER AALST, W. EMiT: A process mining tool.
International Conference on Applications and Theory of Petri Nets. Bolonha: [s.n.].
2004.
WATTS, H. Managing the Software Process. 1. ed. [S.l.]: Addison-Wesley

Professional, 1989.
WEBAPSEE.
WebAPSEE,
2011.
Disponivel
em:
<http://www3.ufpa.br/webapsee/index.php?option=com_content&view=article&id=47
&Itemid=103&lang=br>. Acesso em: 30 out. 2011.
WEIJTERS, A. Process Mining: discovering workflow models form event-based data.

Proceedings of the 13th Belgium-Netherlands Conference on Artificial Intelligence.
[S.l.]: [s.n.]. 2001. p. 283-290.
WEIJTERS, A.; VAN DER AALST, W. Rediscovering workflow models from eventbased data using Little Thumb. Integrated Computer-Aided Engineering 10, v. 2, p.
151-162, 2003.
WEN, L. et al. A Novel Approach for Process Mining Based on Event Types. Journal
of Intelligent Information, 2009.
84
APNDICE A Eventos Identificados no Ambiente WebAPSEE
Este apndice tem como objetivo apresentar os eventos identificados no

ambiente WebAPSEE. Os eventos esto divididos entre os seguintes tipos:
Acesso ao repositrio de artefatos;
Cadastro e alterao de entidades;
Modelagem de processo;
Execuo de processo;
Gerncia de conhecimento;
Modelo;
Segurana;
Reutilizao de processo.
Esses eventos foram identificados a partir de uma anlise do cdigo fonte do
ambiente WebAPSEE atual. Foram analisadas as classes que implementam os servios
fornecidos pelo ambiente, localizadas no pacote br.ufpa.labes.server.impl.
O Quadro 4 possui trs colunas: a primeira para o tipo de evento (classe onde
esto implementados os servios); a segunda para o nome do evento; e a terceira para o
mtodo no cdigo fonte que executado quando o evento ocorre.
85
Quadro 4 Eventos identificados no ambiente WebAPSEE (continua).

EVENTOS DO AMBIENTE WEBAPSEE
Tipo de Evento
Evento
Upload
Acesso ao repositrio de
Mtodo
de performImport
artefato
artefatos
(ArtifactManagerImpl)
Download
de performCheckout
artefato
Salvar entidade
save
Atualizar
update
entidade
Excluir entidade
Salvar
Cadastro e alterao de
entidades
(DataSourceDBImpl)
delete
coleo saveRelationshipsOidsCollection
de
relacionamentos
Salvar
saveRelationshipsOid
relacionamentos
Excluir coleo deleteRelationshipsOidsCollection
de
relacionamentos
Excluir
relacionamentos
deleteRelationshipsOid
86

Tipo de Evento
Evento
Mtodo
Criar atividade newNormalActivity

normal
Criar atividade newDecomposedActivity
decomposta
Criar atividade newAutomaticActivity
automtica
Definir
como defineAsDecomposed
decomposta
Definir
como defineAsAutomatic
automtica
Modelagem de processo
Definer
(DynamicModelingImpl)
normal
como defineAsNormal
Definir artefato defineInputArtifact

de entrada
Definir artefato defineOutputArtifact
de sada
Definir
defineAutomatic
automtica
script
Definir
automtica
mtodo
defineAutomatic
87

Tipo de Evento
Evento
Mtodo
Deletar
deleteActivity
atividade
Criar conexo newArtifactConnection
de artefato
Definir tipo do defineType_ArtifactConnection
artefato
Alterar tipo do changeType_ArtifactConnection
artefato
Definir
instncia
defineInstance_ArtifactConnection
do
artefato
Remover
instncia
removeInstance_ArtifactConnection
do
artefato
Definir
defineOutput_ArtifactConnection
conexo
de
sada
do
artefato
Remover
removeOutput_ArtifactConnection
conexo
de
sada
do
artefato
Definir
defineInput_ArtifactConnection_Activity
conexo
de
entrada
em
atividade
88

Tipo de Evento
Evento
Mtodo
Remover
removeInput_ArtifactConnection_Activity
conexo
de
entrada
em
atividade
Definir
conexo
defineInput_ArtifactConnection_Multiple
de
entrada
mltipla
Remover
conexo
removeInput_ArtifactConnection_Multiple
de
entrada
mltipla
Deletar
conexo
Adicionar
deleteConnection
addSimpleConnection
conexo
simples
Adicionar
conexo
addFeedbackConnection
de
feedback
Criar
Join newJoinAND
AND
Criar Join OR
Criar
newJoinOR
Join newJoinXOR
XOR
Criar Branch newBranchAND
AND
89

Tipo de Evento
Evento
Criar
Mtodo
Branch newBranchOR
OR
Criar
Branch newBranchXOR
XOR
Remover
removeMultiConPredecessorConnection
predecessor de
conexo
mltipla
quando
conexo
Remover
removeMultiConPredecessorActivity
predecessor de
conexo
mltipla
quando
atividade
removeMultiConSuccessorConnection
Remover
sucessor
de
conexo
mltipla
quando
conexo
Remover
sucessor
conexo
mltipla
quando
atividade
removeMultiConSuccessorActivity
de
90

Tipo de Evento
Evento
Mtodo
Definir destino defineJoinTo_Activity

Join
para
atividade
Definir destino defineJoinTo_Connection
Join
para
conexo
Definir origem defineJoinFrom_Connection
Join de conexo
Definir origem defineJoinFrom_Activity
Join
de
atividade
Definir origem defineBranchFromActivity
Branch
atividade
de
Definir origem defineBranchFromConnection

Branch
de
conexo
Definir destino defineBranchToActivity
Branch
para
atividade
Definir destino defineBranchToConnection
Branch
para
conexo
Adicionar papel
Adicionar
de grupo
addRequiredRole
tipo addRequiredGroupType
91

Tipo de Evento
Evento
Mtodo
Remover papel
removeRequiredRole
Definir agente
defineRequiredAgent
Remover agente
removeRequiredAgent
Definir grupo
defineRequiredGroup
Remover grupo
removeRequiredGroup
Remover
tipo removeRequiredGroupType
de grupo
Adicionar
tipo addRequiredResourceType
de recurso
Alterar tipo de changeRequiredResourceType

recurso
Remover
tipo removeRequiredResourceType
de recurso
Definer recurso
defineRequiredResource
Remover
removeRequiredResource
recurso
Criar
conexo newArtifactConnection
de artefato
Adicionar
newAgent
agente
Adicionar grupo
newGroup
92

Tipo de Evento
Evento
Adicionar
Mtodo
newResource
recurso
Remover
removeCompleteRequiredAgent
completamente
agente
Remover
removeCompleteRequiredGroup
completamente
grupo
Remover
removeCompleteRequiredResource
completamente
grupo
Adicionar
addAgentToGroup
agente ao grupo
Remover agente removeAgentFromGroup
do grupo
Replanejar datas
replanningDates
Copiar atividade
copyActivity
93

Tipo de Evento
Evento
Mtodo
Executar
executeProcess
processo
Reiniciar
resetProcess
processo
Iniciar
beginTask
atividade
Finalizar
finishTask
atividade
Pausar
pauseTask
atividade
Delegar
Execuo de processo
atividade
(EnactmentEngineImpl)
Falhar
delegateTask
failActivity
atividade
Cancelar
cancelActivity
atividade
Tornar recurso makeUnavailable
indisponvel
Tornar recurso makeAvailable
disponvel
Registrar
defeito
registerDefect
em
recurso
Refazer
atividade
createNewVersion
94

Tipo de Evento
Evento
Mtodo
Criar plano de createSpreadKMPlan

disseminao
de
conhecimento
Criar plano de createAcquisitionKMPlan
aquisio
de
conhecimento
Criar
createHomologationResponsibles
responsveis
pela
homologao
Insirir
Gerncia de Conhecimento
(KnowledgeManagementImpl)
para
marco insertIntoTheKnowledgeMilestones
gerncia
de
conhecimento
Remover marco removeFromTheKnowledgeMilestones
para
gerncia
de
conhecimento
Desativar item disableKnowledgeItems
de
conhecimento
Criar
registro createChatRegister
de chat
Salvar item de saveKnowledgeItem
conhecimento
95

Tipo de Evento
Evento
Mtodo
Recuperar itens getKnowledgeItensByAgent

de
conhecimento
por agente
Recuperar item getKnowledgeItem
de
conhecimento
Deletar item de deleteKnowledgeItem
conhecimento
Gerncia de Conhecimento
(KnowledgeManagementImpl)
Salvar
avaliao
saveUtilityEvaluation
de
utilidade
Salvar
saveEvaluation
avaliao
Realizar
exportao
performCheckoutAttachment
de
anexo
Realizar
importao
performImportAttachment
de
anexo
Definir unidade setOrganizationalUnitAgents
organizacional
Modelo
de agentes
(ModelImpl)
Remover
unidade
organizacional
removeOrganizationUnits
96

Tipo de Evento
Evento
Alterar
Mtodo
horas changeTaskWorkingHours
trabalhas
em
atividade
Aplicar
Modelo
alocao
(ModelImpl)
processo
applyAllocationToProcess
ao
Aplicar
applyAllocationToProcessModel
alocao
ao
modelo
de
processo
Entrar
no login
ambiente
(autenticao)
Sair
do logoff
ambiente
Solicitao
Segurana
(SecurityFacadeImpl)
de
recuperao de
senha
Falha
na
tentativa
de
acesso
Eventos no existentes na verso atual do

ambiente
devido
senha ou nome
de
usurio
incorreto
Reutilizao de processo
Criar
verso
(TemplatesImpl)
template
nova createNewVersion
de
97

Tipo de Evento
Evento
Destilar
Mtodo
processDistilling
processo
Destilar
decomposedDistilling
atividade
decomposta
Reutilizao de processo
(TemplatesImpl)
Instanciar
processInstantiation
processo
Compor
processComposition
processo
Definir
toBecomeDefined
template
A seguir, no Quadro 5, apresentada a lista de eventos que estaro disponveis

para a notificao inicialmente.
98
Quadro 5 Eventos disponveis para notificao externa.

EVENTOS PARA NOTIFICAO EXTERNA
Tipo de Evento
Evento
Upload de artefato
Acesso ao repositrio de artefatos

Download de artefato
Executar processo
Reiniciar processo
Iniciar atividade
Finalizar atividade
Pausar atividade
Delegar atividade
Execuo de processo
Falhar atividade
Cancelar atividade
Tornar recurso indisponvel
Tornar recurso disponvel
Registrar defeito em recurso
Refazer atividade
Acessar o ambiente (autenticao)
Sair do ambiente
Segurana
(disponveis apenas para o Administrador)
Solicitao de recuperao de senha

Falha na tentativa de acesso devido senha ou
nome de usurio incorreto
99
APNDICE B Descrio dos Casos de Uso
O objetivo deste apndice apresentar a descrio dos casos de uso apresentados

na seo 4.1 deste trabalho. A descrio de cada caso de uso feita em um quadro
composto por um identificador, nome, descrio, atores, pr-condies e requisitos
relacionados. O Quadro 6 apresenta o modelo de quadro utilizado para descrever os
casos de uso.
Quadro 6 Modelo de quadro utilizado na descrio dos casos de uso.
Identificador:
<Id>
Descrio:
<Descrio textual do caso de uso>
Atores:
<Atores envolvidos no caso de uso>
Pr-condies:
<Pr-condies para realizao do caso de uso>
Requisitos
relacionados:
<Requisito(s) relacionado(s) com a criao do caso de uso>
Caso de Uso:
<Nome do caso de uso>
Este apndice divido em duas sees: a primeira apresenta a descrio dos

casos de uso de registro de eventos e a segunda apresenta a descrio dos casos de uso
de notificao de eventos. Ao final de cada subseo apresentada uma matriz
mostrando os relacionamentos entre os casos de uso e os requisitos da proposta
apresentados na seo 4.1.
B.1. Casos de Uso do Registro de Eventos
O diagrama da Figura 31 apresenta os casos de uso identificados para o registro

de eventos. Aps a Figura 31 so apresentadas as descries dos casos de uso presentes
na figura.
100
Figura 31 Diagrama de casos de uso do registro de eventos.

Quadro 7 Descrio do caso de uso UC 1.
Identificador:
UC 1
Descrio:
Caso de uso relacionado com a busca de registros de evento armazenados

em banco de dados. Inclui o UC 2 e estendido pelos UC 3 e UC 4. O
Administrador possui permisso para buscar qualquer tipo de registro de
evento. O Gerente de Projetos possui permisso para buscar apenas
registros dos tipos: Acesso ao Repositrio de Artefatos, Modelagem de
Processo e Execuo de Processo.
Atores:
Administrador e Gerente de Projetos.
Pr-condies:
1. Usurio deve estar autenticado como Administrador ou Gerente de

Projetos.
2. Usurio deve acessar a tela de busca de registros de evento.
3. Usurio deve selecionar filtros de busca.
Requisitos
relacionados:
RF-05, RF-07, RNF-03, RNF-04 e RNF-05.
Caso de Uso:
Buscar Registros de Eventos

Identificador:
UC 2
Descrio:
Caso de uso relacionado com a seleo de filtros de busca. Est includo

no UC 1. Usurio pode filtrar os registros de evento por: processo, evento,
tipo de evento, data e responsvel. Mais de um filtro pode ser selecionado
ao mesmo tempo.
Atores:
Pr-condies:

Projetos.
2. Usurio deve acessar a tela de busca de registros de eventos.
Requisitos
relacionados:
RF-06.
Caso de Uso:
Selecionar Filtros para Busca
101

Identificador:
UC 3
Descrio:
Caso de uso relacionado com a visualizao dos detalhes de um registro de

evento. Estende o UC 1. Usurio seleciona um dos resultados da busca e
clica que Detalhes.
Atores:
Pr-condies:

Projetos.
2. Usurio deve ter realizado uma busca e obtido resultados.
Requisitos
relacionados:
RF-07.
Caso de Uso:
Visualizar Detalhes do Registro de Evento

Selecionado

Identificador:
UC 4
Descrio:
Caso de uso relacionado com a exportao dos resultados de uma busca.

Estende o UC 1. Usurio seleciona os registros que deseja exporta e clica
em Exportar. Em seguida solicitado que o usurio escolha o formato
para o qual os registros devem ser exportados: TXT, XLS ou XML.
Atores:
Pr-condies:

Projetos.
2. Usurio deve ter realizado uma busca e obtido resultados.
Requisitos
relacionados:
RF-08 e RF-09.
Caso de Uso:
Exportar Registros de Eventos
Abaixo, o Quadro 11 apresenta a matriz de relacionamento entre os requisitos e

casos de uso de registro de eventos. Os requisitos que no aparecem na matriz esto
relacionados com o modelo de dados e por isso no possuem relacionamento com casos
de uso.
Quadro 11 Matriz de relacionamento entre os requisitos e casos de uso de registro de
eventos.
Requisito/
Caso de Uso
UC 1
RF-05
UC 3
UC 4
RF-06
RF-07
UC 2
RF-08
RF-09
RNF-03
RNF-04
102
B.2. Casos de Uso da Notificao de Eventos
A Figura 32 apresenta o diagrama geral dos casos de uso identificados para a

notificao de eventos. Aps a figura so apresentadas as descries dos casos de uso
presentes na figura.
Figura 32 Diagrama geral de casos de uso da notificao de eventos.

Identificador:
UC 1
Descrio:
Caso de uso relacionado com o recebimento de uma notificao interna. O

componente interno, por meio da interface de servios fornecida pelo
componente de notificao de eventos, registra-se para ser notificado da
ocorrncia de um determinado evento. Quando este evento ocorrer o
componente interno ser notificado por meio da chamada de um mtodo,
que indicado no momento da configurao da notificao.
Atores:
Componente Interno do WebAPSEE.
Pr-condies:
No possui.
Requisitos
relacionados:
RF-01, RF-02, RF-13, RF-14, RF-15 e RF-16.
Caso de Uso:
Receber Notificao Interna
103

Identificador:
UC 2
Descrio:
Caso de uso relacionado ao recebimento de notificao. estendido pelo

UC 3. Ao acessar o ambiente, o usurio recebe imediatamente as
notificaes pendentes, caso haja alguma. Ao receber uma notificao o
usurio pode visualizar os detalhes clicando em Detalhes ou acessar a
notificao depois por meio do Gerenciador de Notificaes. O usurio
tambm pode receber uma notificao por e-mail.
Atores:
Usurio.
Pr-condies:
1. Usurio precisa estar autenticado no ambiente.
Requisitos
relacionados:
RF-11.
Caso de Uso:
Receber Notificao

Identificador:
UC 3
Descrio:
Caso de uso relacionado com a visualizao de detalhes da notificao

recebida. Estende o UC 2. Ao receber uma notificao o usurio pode
clicar em Detalhes para visualizar todas as informaes sobre o evento
ocorrido.
Atores:
Usurio.
Pr-condies:
Requisitos
relacionados:
RF-07, RF-18, RF-19 e RNF-01.
Caso de Uso:
Visualizar Notificao

Identificador:
UC 4
Descrio:
Caso de uso relacionado com o Gerenciador de Notificaes. Este caso de

uso subdividido em 9 casos de uso, que correspondem s aes que
podem ser realizadas pelo usurio no Gerenciador de Notificaes. Este
caso de uso especificado na Figura 33.
Atores:
Usurio.
Pr-condies:

2. Usurio precisa acessar o Gerenciador de Notificaes.
Requisitos
relacionados:
RF-20.
Caso de Uso:
Gerenciar Notificaes
A seguir, a Figura 33 apresenta um diagrama que especifica o caso de uso

Gerenciar Notificaes (UC 4). Esse diagrama de especificao contm 9 casos de
uso que representam as funcionalidade disponveis para os usurios no Gerenciador
Notificaes.
104
Figura 33 Especificao do caso de uso Gerenciar Notificaes.

Quadro 16 Descrio do caso de uso UC 4.1.
Identificador:
UC 4.1
Descrio:
Caso de uso relacionado com o cadastro de notificao externa. Usurio

acessa o formulrio de cadastro de notificao clicando em Nova
Notificao, informa as configuraes solicitadas no formulrio e clica
em Salvar para finalizar. Apenas o Administrador tem permisso para
cadastrar notificaes sobre eventos de segurana.
Atores:
Usurio.
Pr-condies:

3. Usurio precisa acessar o formulrio de cadastro de notificao.
Requisitos
relacionados:
RF-01, RF-03, RF-11, RF-12, RF-14, RF-15, RF-17, RNF-02 e RNF-03.
Caso de Uso:
Cadastrar Notificao Externa
105

Identificador:
UC 4.2
Descrio:
Caso de uso relacionado com a visualizao das notificaes. Possui duas

especializaes, o UC 4.3 sobre visualizao de notificaes recebidas e o
UC 4.6 sobre a visualizao de notificaes cadastradas. Usurio possui
interfaces separadas para visualizao de notificaes recebidas e
cadastradas.
Atores:
Usurio.
Pr-condies:

3. Usurio precisa acessar uma das telas de visualizao de notificaes.
Requisitos
relacionados:
RF-04 e RF-07.
Caso de Uso:
Visualizar Notificaes

Identificador:
UC 4.3
Descrio:
Caso de uso relacionado com a visualizao das notificaes recebidas.

Especializao do UC 4.2. Ao acessar a tela de notificaes recebidas, o
usurio visualiza o histrico de notificaes recebidas. A partir desse
histrico o usurio pode: visualizar detalhes de uma notificao
selecionada clicando em Detalhes; excluir uma notificao selecionada
clicando em Excluir; e limpar o histrico de notificaes clicando em
Limpar Histrico. Este caso de uso estendido pelos UC 4.4, UC 4.5 e
UC 4.6.
Atores:
Usurio.
Pr-condies:

3. Usurio precisa acessar a tela de visualizao de notificaes
recebidas.
Requisitos
relacionados:
RF-07, RF-18, RF-19 e RNF-01.
Caso de Uso:
Visualizar Notificaes Recebidas
106

Identificador:
UC 4.4
Descrio:
Caso de uso relacionado com a limpeza do histrico de notificaes

recebidas. Estende o UC 4.3. Na tela de visualizao de notificaes
recebidas, o usurio clica em Limpar Histrico e recebe uma pergunta
de confirmao, caso responda positivamente todas as notificaes
recebidas so excludas do histrico e do banco de dados.
Atores:
Usurio.
Pr-condies:

recebidas.
Requisitos
relacionados:
RF-08.
Caso de Uso:
Limpar Histrico de Notificaes Recebidas

Identificador:
UC 4.5
Descrio:
Caso de uso relacionado com a excluso de notificaes individuais do

histrico de notificaes recebidas. Estende o UC 4.3. Usurio seleciona
notificaes na tela de visualizao de notificaes recebidas e clica em
Excluir para remov-las do histrico. Antes da excluso o usurio recebe
um pergunta de confirmao, se confirmar positivamente as notificaes
selecionadas so excludas do histrico e do banco de dados. Essa
excluso tambm pode ser realizada a partir da tela de detalhes de uma
notificao clicando em Excluir.
Atores:
Usurio.
Pr-condies:

recebidas
4. Usurio precisa acessa a tela de detalhes da notificao recebida
(opcional).
Requisitos
relacionados:
RF-09.
Caso de Uso:
Excluir Notificao
107

Identificador:
UC 4.6
Descrio:
Caso de uso relacionado com o envio de uma notificao recebida para um

endereo de e-mail. Estende o UC 4.3. A partir da tela de detalhes de uma
notificao recebida, o usurio clica em Enviar para E-mail para enviar
os detalhes da notificao para um ou mais endereos de e-mail. Uma
janela aberta solicitando o(s) endereo(s) de e-mail para onde a
notificao deve ser enviada (obrigatrio) e uma mensagem do usurio
(opcional).
Atores:
Usurio.
Pr-condies:

recebidas.
4. Usurio precisa acessar os detalhes de uma notificao recebida.
Requisitos
relacionados:
RF-10.
Caso de Uso:
Enviar Notificao para E-mail

Identificador:
UC 4.7
Descrio:
Caso de uso relacionado com a visualizao das notificaes cadastradas.

Ao acessar a tela de notificaes cadastradas, o usurio visualiza todas as
notificaes que cadastrou e que ainda esto pendentes ou ativas
(notificaes j enviadas no aparecem nessa lista). A partir dessa tela o
usurio pode: visualizar detalhes de uma notificao selecionada clicando
em Detalhes; editar as configuraes de uma notificao selecionada
clicando em Editar; e cancelar as notificaes selecionadas clicando em
Cancelar. Este caso de uso estendido pelos UC 4.4, UC 4.5 e UC 4.6.
Atores:
Usurio.
Pr-condies:

cadastradas.
Requisitos
relacionados:
RF-04.
Caso de Uso:
Visualizar Notificaes Cadastradas
108

Identificador:
UC 4.8
Descrio:
Caso de uso relacionado com a edio das configuraes de uma

notificao cadastrada. Estende o UC 4.7. Usurio acessa a tela de detalhes
de uma notificao cadastrada e clica em Editar. Aps a edio o usurio
clica em Salvar para salvar as modificaes feitas nas configuraes da
notificao.
Atores:
Usurio.
Pr-condies:

cadastradas ou a tela de detalhes de uma notificao cadastrada.
4. Usurio precisa acessar a tela de detalhes de uma notificao
cadastrada.
Requisitos
relacionados:
RF-05.
Caso de Uso:
Editar Cadastro de Notificao

Identificador:
UC 4.9
Descrio:
Caso de uso relacionado com o cancelamento de uma notificao

cadastrada. Estende o UC 4.7. Usurio acessa a tela de detalhes de uma
notificao cadastrada e clica em Cancelar. Antes do cancelamento o
usurio recebe um pergunta de confirmao, caso a responda
positivamente a notificao excluda da lista e do banco de dados.
Atores:
Usurio.
Pr-condies:

cadastradas ou a tela de detalhes de uma notificao cadastrada.
4. Usurio precisa acessar a tela de detalhes de uma notificao
cadastrada.
Requisitos
relacionados:
RF-06.
Caso de Uso:
Cancelar Notificao
Abaixo, o Quadro 25 apresenta a matriz de relacionamento entre os requisitos e

casos de uso de notificao de eventos.
109
Quadro 25 Matriz de relacionamento entre os requisitos e casos de uso de notificao de

eventos.
Requisito/
Caso de
Uso
RF-01
UC
1
RF-02
UC
2
UC
3
UC
4
UC
4.1
UC
4.2
UC
4.3
UC
4.4
UC
4.5
UC
4.6
UC
4.8
UC
4.9
RF-03
RF-04
X
X
RF-05
RF-06
X
RF-07
X
X
RF-08
RF-09
RF-10
X
RF-11
X
X
RF-12
RF-13
RF-14
RF-15
RF-16
X
X
RF-17
RF-18
RF-19
X
X
RF-20
RNF-01
UC
4.7
RNF-02
RNF-03

Uma Infraestrutura para Registro e Notificação de Eventos No Ambiente

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Infraestrutura para Registro e Notificação de Eventos No Ambiente

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO PAR

INSTITUTO DE CINCIAS EXATAS E NATURAIS

Leandro Bezerra Coutinho

Uma Infraestrutura para Registro e Notificao de Eventos no

UNIVERSIDADE FEDERAL DO PAR

Leandro Bezerra Coutinho

Uma Infraestrutura para Registro e Notificao de Eventos no

apresentado para obteno do grau de

UNIVERSIDADE FEDERAL DO PAR

Leandro Bezerra Coutinho

Uma Infraestrutura para Registro e Notificao de Eventos no

apresentado para obteno do grau de

Data da defesa: ___ de Dezembro de 2011.

Prof. Dr. Rodrigo Quites Reis.

Prof. Dr. Roberto Samarone dos Santos Arajo

Prof. Ms. Ernani de Oliveira Sales

Agradeo a Deus por me proporcionar sade, confiana e inteligncia para a

Mecanismos de registro de eventos so uma parte importante de qualquer sistema de

Figura 1 Camadas que compe a arquitetura do ambiente WebAPSEE 1.x [LABES

Figura 25 Comportamento do mecanismo de notificao externa Envio de

Quadro 1 Exemplo de configurao de notificao no arquivo XML. ....................... 36

2 TECNOLOGIA DE PROCESSO DE SOFTWARE .............................................. 15

3 REGISTRO E NOTIFICAO DE EVENTOS .................................................... 27

4 INFRAESTRUTURA PROPOSTA ......................................................................... 38

5 CONSIDERAES FINAIS .................................................................................... 73

REFERNCIAS BIBLIOGRFICAS ....................................................................... 75

processos totalmente na Web, podendo atender diversas empresas de forma mais

Sabendo disso, este trabalho vem apresentar uma proposta de infraestrutura de

Segundo Ma e Tsudik (2009), as informaes armazenadas pelos registros de

Buscando atender, inicialmente, essas necessidades do ambiente WebAPSEE

Segundo Alves et al. (2007), registro de eventos (log) um servio complexo e

Este trabalho tem como o objetivo propor uma infraestrutura de software

1.4 ORGANIZAO DO TEXTO

captulo, so listadas algumas possveis aplicaes do registro de eventos no ambiente

2 TECNOLOGIA DE PROCESSO DE SOFTWARE

Desde a dcada 1980, quando a ideia de processo de software comeou a se

Facilitar a adoo de uma estratgia de melhoria da maturidade dos processos de

Permitir o registro do conhecimento produzido acerca dos processos bem

Proporcionar um controle preciso na alocao e consumo de recursos durante o

Coletar mtricas dos projetos da organizao e torn-las disponveis para

ambiente se destaca quando se trata de coordenar as atividades e os recursos envolvidos

acompanhar os prazos e o consumo de recursos, alm de facilitar a reutilizao de boas

Os Ambientes de Engenharia de Software Centrados em Processos (mais

Primordialmente, um PSEE composto por trs componentes [Lima Reis 2003]:

Em 2000, o pesquisador Alfonso Fuggetta citou que naquele momento as

2.2 AMBIENTE WEBAPSEE

O WebAPSEE um Ambiente de Engenharia de Software Centrado em

A construo da primeira verso da ferramenta foi iniciada em 2004 em um projeto

Entre as outras funcionalidades que fazem o diferencial do ambiente

2.2.1 WEBAPSEE 1.8

Como relatado anteriormente, o ambiente WebAPSEE foi inicialmente projetado

desempenho da aplicao, o que acabou dificultando a realizao da comunicao com

linguagem de programao Java [Oracle 2011a] para

implementao dos servios; a biblioteca Java/Swing [Oracle 2011b] para

Figura 1 Camadas que compe a arquitetura do ambiente WebAPSEE 1.x [LABES

Desde a primeira verso o ambiente WebAPSEE vem recebendo melhorias e

desenvolvimento do ambiente, enquanto as ferramentas e mecanismos so resultados,

Figura 2 Editor visual de processos do Manager Console e exemplo de formulrio.

A Task Agenda a ferramenta voltada para os desenvolvedores e outros

Figura 3 Interface grfica da Task Agenda.

A Web Agenda foi desenvolvida em 2007 e a verso Web da Task Agenda. A

Figura 4 Interface grfica da Web Agenda.

2.2.2 WEBAPSEE 2.0