um sistema de recomendaÇÃo de mÉtricas e regras luiz...
TRANSCRIPT
UM SISTEMA DE RECOMENDAÇÃO DE MÉTRICAS E REGRAS
Luiz Fernando Cardoso Tomaz
Dissertação de Mestrado apresentada ao Programa de
Pós-graduação em Engenharia de Sistemas e
Computação, COPPE, da Universidade Federal do Rio
de Janeiro, como parte dos requisitos necessários à
obtenção do título de Mestre em Engenharia de
Sistemas e Computação.
Orientador: Jano Moreira de Souza
Rio de Janeiro
Setembro de 2011
UM SISTEMA DE RECOMENDAÇÃO DE MÉTRICAS E REGRAS
Luiz Fernando Cardoso Tomaz
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ
COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE) DA
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS
NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM
ENGENHARIA DE SISTEMAS E COMPUTAÇÃO
Examinada por:
________________________________________________
Prof. Jano Moreira de Souza, Ph D.
________________________________________________
Prof. Geraldo Zimbrão da Silva, D.Sc.
________________________________________________
Profª. Ana Cristina Bicharra da Silva, Ph D.
________________________________________________
Prof. Alberto Sulaiman Sade Júnior, D.Sc.
RIO DE JANEIRO, RJ – BRASIL
SETEMBRO DE 2011
iii
Tomaz, Luiz Fernando Cardoso
Um Sistema de Recomendação de Métricas e Regras/ Luiz
Fernando Cardoso Tomaz. – Rio de Janeiro: UFRJ/COPPE,
2011.
XIV, 102 p.: il.; 29,7 cm.
Orientador: Jano Moreira de Souza
Dissertação (mestrado) – UFRJ/ COPPE/ Programa de
Engenharia de Sistemas e Computação, 2011.
Referencias Bibliográficas: p. 70-78.
1. Sistemas de Recomendação. 2. Computação
Autonômica. 3. Gestão Estratégica. I. Souza, Jano Moreira de. II.
Universidade Federal do Rio de Janeiro, COPPE, Programa de
Engenharia de Sistemas e Computação. III. Titulo.
iv
Agradecimentos
Agradeço em primeiro lugar ao meu orientador Jano Moreira de Souza e ao meu co-
orientandor José Augusto Rodrigues Neto a toda ajuda dada no desenvolvimento desta
dissertação.
Aos professores Zimbrão, Ana Cristina e Alberto Sulaiman por aceitarem participar da
banca de avaliação.
À empresa GPE - Gestão de Processos Estratégicos por me apresentar o tema da
dissertação e pelo apoio durante todo o desenvolvimento da mesma.
À Fundação Coppetec, pela oportunidade de trabalho durante boa parte do mestrado.
À minha namorada Isabel Cristina Vieira da Silva, pelo apoio e compreensão durante
o desenvolvimento da dissertação.
Por último, mas não menos importante, eu agradeço à minha família e aos meus
amigos pelo apoio dado no decorrer deste trabalho.
v
Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos necessários
para a obtenção do grau de Mestre em Ciências (M. Sc.)
UM SISTEMA DE RECOMENDAÇÃO DE MÉTRICAS E REGRAS
Luiz Fernando Cardoso Tomaz
Setembro/2011
Orientador: Jano Moreira de Souza
Programa: Engenharia de Sistemas e Computação
Essa disertação apresenta técnicas de sistemas de recomendação para auxiliar o
processo de desenvolvimento do BSC de uma organização, apoiando os membros do comitê
estratégico da organização na tarefa de definir as métricas de uma meta e como as mesmas
devem ser acompanhadas. Para tal, foram criados dois sistemas de recomendação, um para
recomendar métricas e outro para recomendar regras de acompanhamento para metas. Foi
gerado um sistema, chamado ECRAN (Editor Colaborativo de Regras Autonômicas de
Negócio) que possui tais técnicas de recomendação.
vi
Abstract of dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements
for the degree of Master of Science (M.Sc.)
A RECOMMENDER SYSTEM OF METRICS AND RULES
Luiz Fernando Cardoso Tomaz
September/2011
Advisor: Jano Moreira de Souza
Department: System Engineering and Computer Science
This dissertation presents recommender systems for assisting in the development of an
organization’s BSC, supporting the members of the organization strategic committee on their
task of defining metrics to BSC goals and how they should be tracked. We created two
recommender systems, one to recommend metrics to goals and another to recommend
tracking rules to goals. Also, we developed a system, called ECRAN (Editor Colaborativo de
Regras Autonômicas de Negócio) that uses the proposed recommender systems.
vii
Índice
1. Introdução .......................................................................................................................................... 1
1.1. Motivação ..................................................................................................................................... 1
1.2. Problema ...................................................................................................................................... 3
1.3. Objetivos ...................................................................................................................................... 5
1.4. Justificativa .................................................................................................................................. 6
1.5. Contribuições ............................................................................................................................... 7
1.6. Definição de Escopo..................................................................................................................... 7
1.7. Estrutura da Dissertação ............................................................................................................... 8
2. Conceitos Relacionados ..................................................................................................................... 9
2.1. Balanced Scorecard ...................................................................................................................... 9
2.2. Computação Autonômica ........................................................................................................... 11
2.3. Regra .......................................................................................................................................... 18
2.3.1. Regras ECA ......................................................................................................................... 21
2.3.2. Regras PRR ......................................................................................................................... 23
2.4. Linguagens para Especificação de Regras ................................................................................. 23
2.4.1. PDL ..................................................................................................................................... 24
2.4.2. Ponder ................................................................................................................................. 24
2.4.3. CQL ..................................................................................................................................... 25
2.4.4. XACML .............................................................................................................................. 25
2.4.5. IBM ACPL .......................................................................................................................... 26
2.4.6. CIM SPL ............................................................................................................................. 26
2.5. Sistemas de Recomendação ....................................................................................................... 27
2.5.1. Recomendações Baseadas em Conteúdo ............................................................................. 29
2.5.2. Recomendações Colaborativas ............................................................................................ 30
2.5.3. Abordagem Híbrida ............................................................................................................. 31
2.6. Regras de Associação ................................................................................................................. 32
3. Recomendação de Métricas e Regras ............................................................................................... 36
3.1. Sistema de Recomendação para as Métricas da Meta ............................................................... 36
viii
3.2. Sistema de Recomendação para as Regras de Acompanhamento ............................................. 42
3.2.1. Variáveis.............................................................................................................................. 43
3.2.2. Pontuação Inicial da Regra .................................................................................................. 44
3.2.3. Pontuação de Utilização da Regra ....................................................................................... 44
3.2.4. Pontuação de Influência da Regra ....................................................................................... 45
3.2.5. Pontuação Total da Regra ................................................................................................... 45
4. Experimento ..................................................................................................................................... 47
4.1. Simulação para Recomendação de Métricas .............................................................................. 47
4.1.1. Processo de Simulação ........................................................................................................ 48
4.1.2. Execução da Simulação ....................................................................................................... 50
4.1.3. Resultados ........................................................................................................................... 51
4.1.4. Análise dos Resultados ........................................................................................................ 62
4.2. Simulação para Recomendação de Regras ................................................................................. 63
4.2.1. Processo de Simulação ........................................................................................................ 63
4.2.2. Execução da Simulação ....................................................................................................... 65
4.2.3. Resultados ........................................................................................................................... 65
4.2.4. Análise dos Resultados ........................................................................................................ 66
5. Conclusão ......................................................................................................................................... 67
6. Trabalhos Futuros ............................................................................................................................ 69
Referências Bibliográficas .................................................................................................................... 70
APÊNDICE A. Editor Colaborativo de Regras Autonômicas de Negócio ..................................... 79
A.I. Arquitetura ................................................................................................................................. 79
A.II. Diagrama de Classes do ECRAN ............................................................................................. 82
A.III. Funcionamento ........................................................................................................................ 85
A.III.i. Associação de Métricas à Meta ......................................................................................... 86
A.III.ii. Associação de Regras de Acompanhamento à Meta ........................................................ 89
A.IV. Implementação do ECRAN ..................................................................................................... 92
A.IV.i. Tecnologias Utilizadas ...................................................................................................... 92
A.IV.ii. Processo Associação de Métricas à Meta ........................................................................ 92
ix
A.IV.iii. Processo Indicação de Regras de Acompanhamento para as Metas ............................... 96
x
Índice de Figuras
Figura 1: Perspectivas de um BSC ................................................................................................... 11
Figura 2: Elemento Autonômico ....................................................................................................... 17
Figura 3: Relações entre diferentes tipos de regra ............................................................................ 21
Figura 4: Análise posição média da métrica nas configurações do Grupo I no cenário aleatório. ... 51
Figura 5: Análise do percentual de acerto no top 10 das configurações do Grupo I no cenário
aleatório............... .................................................................................................................................. 52
Figura 6: Análise posição média da métrica nas configurações do Grupo I no cenário agrupado. .. 53
Figura 7: Análise do percentual de acerto no top 10 das configurações do Grupo I no cenário
agrupado.......... ...................................................................................................................................... 54
Figura 8: Análise posição média da métrica nas configurações do Grupo II no cenário aleatório. .. 55
Figura 9: Análise do percentual de acerto no top 10 das configurações do Grupo II no cenário
aleatório........... ...................................................................................................................................... 56
Figura 10: Análise posição média da métrica nas configurações do Grupo II no cenário
agrupado.......... ...................................................................................................................................... 57
Figura 11: Análise do percentual de acerto no top 10 das configurações do Grupo II no cenário
agrupado.......... ...................................................................................................................................... 58
Figura 12: Análise posição média da métrica nas configurações do Grupo III no cenário
aleatório........... ...................................................................................................................................... 59
Figura 13: Análise do percentual de acerto no top 10 das configurações do Grupo III no cenário
aleatório........... ...................................................................................................................................... 60
Figura 14: Análise do percentual de acerto no top 10 das configurações do Grupo III no cenário
agrupado.......... ...................................................................................................................................... 61
Figura 15: Análise posição média da métrica nas configurações do Grupo III no cenário
agrupado........... ..................................................................................................................................... 61
Figura 16: Quantidade de vêzes que a melhor regra aparece nas 5 primeiras posições em cada
configuração.... ...................................................................................................................................... 66
Figura 17: Team .............................................................................................................................. 80
Figura 18: Arquitetura ECRAN ...................................................................................................... 81
Figura 19: Diagrama de Classes do core do ECRAN ..................................................................... 83
Figura 20: Processo referente a associação de métricas à meta ...................................................... 88
xi
Figura 21: Processo referente a associação de regras de acompanhamento à meta ........................ 91
Figura 22: Tela de escolha de meta para associar às métricas ........................................................ 93
Figura 23: Tela para associação de métricas à meta. ...................................................................... 94
Figura 24: Tela para criação de métricas. ....................................................................................... 95
Figura 25: Tela para escolha de metas para indicar regras de acompanhamento. .......................... 96
Figura 26: Tela para associação de regras de acompanhamento à meta. ........................................ 97
Figura 27: Tela de criação de regra de acompanhamento. .............................................................. 99
Figura 28: Tela para criar nova expressão, com o 2º operando sendo um valor ........................... 100
Figura 29: Tela para criar nova expressão, com o 2º operando sendo uma métrica ..................... 101
Figura 30: Tela para criar nova expressão, sendo a expressão uma expressão composta ............ 102
xii
Índice de Tabelas
Tabela 1. Níveis da Computação Autonômica .................................................................................. 16
Tabela 2. Análise de cestas de compras ............................................................................................ 34
Tabela 3. Regras de Associação ........................................................................................................ 35
Tabela 4. Configurações utilizadas na simulação ............................................................................. 65
xiii
Lista de Siglas
ABSC– Autonomic Balanced Scorecard
ACPL – Autonomic Computing Policy Language.
BSC – Balanced Scorecard.
CIM – Common Information Model.
CIM-SPL – Simple Policy Language for CIM.
CQL – CIM Query Language.
DMTF – Distributed Management Task Force.
ECA – Event Condition Action.
ECAA – Event Condition Action Alternative.
ECAP – Event Condition Action Postcondition.
ECRAN – Editor Colaborativo de Regras Autonômicas de Negócio.
PCIM – Policy Core Information Model.
PDL – Policy Description Language.
PRR – Production Rule Representation.
RIF – Rule Interchange Format.
SQL – Structured Query Language.
TEAM – Tool for Enterprise Autonomic Management.
TI – Tecnlogia da Informação.
UML – Unified Modeling Language.
WfMC – Workflow Management Coalition.
xiv
W3C – World Wide Web Consortium.
XACML – eXtensible Access Control Markup Language.
XPDL – XML Process Description Language.
YAWL – Yet Another Workflow Language.
1
1. INTRODUÇÃO
Este capítulo se inicia com a apresentação da motivação, do problema, dos
objetivos, da justificativa e das contribuições da dissertação. Posteriormente, é exibida a
definição do escopo da proposta. Por fim, é exposta a estrutura de divisão do trabalho.
1.1. MOTIVAÇÃO
Nessas últimas 5 décadas é inegável que a sociedade tem requerido, cada vez
mais, resultados imediatos (MURCH, 2004) e, isso se reflete diretamente nos negócios.
Uma organização não pode desperdiçar tempo a espera de uma resposta. Como um
exemplo disso, citado por Murch em (MURCH, 2004), existem alguns locais no mundo
onde, devido ao fato de os patrões quererem que os empregados desperdicem o mínimo
de tempo possível nas refeições, os restaurantes cobram pelo tempo que o freguês
permanece dentro do mesmo, ao invés de cobrarem pelo que consomem. Dessa forma,
os trabalhadores ficam mais tempo na empresa.
Esse mundo, agora, é confrontado com a nova economia baseada em
conhecimento, onde o dinamismo do processo é alto e seu impacto no gerenciamento é
inevitável. A Computação Autonômica (HORN, 2001) surgiu para lidar com o aumento
da complexidade dos sistemas computacionais. Essa dissertação propõe a utilização da
computação autonômica para dar suporte à gestão de um plano estratégico de uma
organização, pois é um modelo adequado nesse cenário dinâmico.
Para uma organização ter sucesso, é necessário que a mesma possua uma maior
eficiência e eficácia nos seus processos, bem como uma maior atenção ao seu
planejamento estratégico (PORTER, 2001).
2
Empresas tradicionalmente utilizam indicativos financeiros para avaliar seus
desempenhos e preparar as suas estratégias. No entanto, a evolução da gestão
organizacional levou ao surgimento de outras formas de gestão baseadas em indicadores
de desempenho variados, chamadas genericamente gestão baseada em valor. Uma das
principais técnicas de gestão baseada em valor é o BSC (Balanced Scorecard)
(KAPLAN et al., 1996), utilizado em conjunto com os Mapas Estratégicos (KAPLAN et
al., 2004).
No entanto, apesar de toda a atenção recebida e da real necessidade das
organizações de implementarem suas estratégias, a implantação de métodos de gestão
de desempenho, como o BSC, para dar suporte à gestão estratégica das organizações ,
não tem tido o grau de sucesso que se esperava (EVANS, 2004) (WAAL, 2007).
Existem informações de taxas de insucesso em torno de 70% (ATKINSON, 2006).
Considerando que um BSC tem em geral algumas dezenas de métricas
associadas, pode-se perceber a complexidade em estabelecer ligações claras e confiáveis
entre essas e as metas atinentes (ITTNER et al., 2003) (NEELY et al., 2000). Tal
complexidade fica ainda mais evidente quando se deixa o plano teórico, para considerar
a prática. Por ser o BSC uma ferramenta originalmente para suporte ao nível estratégico
de uma organização, as métricas utilizadas são em sua maioria compostas e, portanto,
demandam a sumarização de indicadores e resultados obtidos nos níveis inferiores da
organização.
Assim sendo, consideramos que para a real utilização do BSC como uma
ferramenta de gestão organizacional, especificamente a gestão estratégica, existe a
necessidade de se criar uma infraestrutura capaz de apoiar a utilização do mesmo,
promovendo a integração de metas e indicadores, a automação da coleta de medidas e
da indicação de desvios, e mesmo da tomada de ações corretivas, visando a reduzir a
3
complexidade para os responsáveis pela gestão organizacional. Portanto, a utilização de
regras autonômicas para apoiar o acompanhamento da execução do planejamento
estratégico da organização ao nível da meta torna o mesmo mais visível e abre novas
oportunidades a serem exploradas.
Por outro lado, essa infraestrutura deve conter meios para facilitar o trabalho do
comitê estratégico, principalmente na integração entre metas e indicadores e no
acompanhamento do desempenho das metas. Dessa forma, a combinação de um sistema
de recomendação para apoiar a associação entre metas e indicadores pode facilitar esse
trabalho.
1.2. PROBLEMA
A realidade econômica atual, onde a globalização aumentou a concorrência, e
onde inovações e intervenções governamentais alteram constantemente os seus cenários
de atuação, demanda alta flexibilidade e capacidade de resposta às empresas. Dentro
desse contexto, torna-se de fundamental importância para uma organização, além da sua
capacidade de criar uma boa estratégia, ser eficaz na sua implementação (WAGNER,
2004). Por outro lado, devido ao fato de um BSC possuir algumas dezenas de métricas
associadas, a dificuldade em associar metas com métricas é enorme.
O problema em estudo considera a ocorrência de metas similares dentro de um
mesmo BSC ou de BSC relativos a estratégias distintas dentro da mesma organização.
Nesse caso, cada comitê estratégico fica responsável por definir suas métricas e sua
forma de acompanhamento. Tal forma de trabalho pode levar a uma mesma meta ser
avaliada de formas diferentes dentro de uma organização, o que levaria a interpretação
errada do andamento do plano estratégico da empresa. Além de se escolher as métricas
4
corretas, é necessário também que as mesmas sejam acompanhadas corretamente, ou
seja, os valores que cada métrica tem que atingir durante a execução do plano
estratégico devem ser parecidos, o que resulta em uma interpretação homogênea da
meta por todos os setores da organização. Adicionalmente, o fato de metas e métricas
serem definidas e associadas de formas variadas demanda um esforço que pode ser
reduzido se as mesmas forem trabalhadas de forma colaborativa.
Essa mesma dinâmica da economia mundial demanda que as organizações
possuam estratégias que sejam capazes de se autogerenciar e se autoadaptar as
mudanças e aos desafios do mercado. Dessa forma, um meio eficiente de se solucionar
esse problema é deixar a responsabilidade da administração da estratégia para o sistema
que a apoia, de acordo com regras estabelecidas pelos administradores (KEPHART et
al., 2003). A IBM introduziu essa visão em 2001 quando lançou seu manifesto sobre
Computação Autonômica (HORN, 2001).
Entretanto, para os sistemas serem capazes de se autogerenciar, as pessoas que
possuem o conhecimento devem expressá-lo de forma que os sistemas possam entendê-
lo. Esse conhecimento normalmente é expressado através de regras ou políticas, que
expressam o conhecimento do administrador do sistema sobre os possíveis cenários e as
ações que devem ser executadas quando um evento ocorre e altera esse cenário
(KEPHART, 2005).
Atualmente, um problema da Computação Autonômica está na metodologia de
desenvolvimento da regra autonômica. Esse processo de transferência de conhecimento
deveria ser um processo iterativo, com uma interface amigável, tornando mais simples a
tarefa de capturar o conhecimento dos administradores sobre regras e restrições
(KEPHART, 2005).
5
Hoje em dia, existem diversas pesquisas nesse âmbito, porém, a maioria delas
está voltada para descrição de regras que refletem diretamente ações de baixo nível, i.e.,
ações que devem ser feitas se as condições passadas forem satisfeitas (KEPHART,
2005).
1.3. OBJETIVOS
O objetivo principal é contribuir para tornar mais eficiente a associação de
métricas às metas de um BSC, bem como auxiliar aos membros do comitê estratégico
na criação de mecanismos para o acompanhamento das metas de um BSC, através da
utilização de regras autonômicas.
Considerando esses objetivos, espera-se que, quando os membros do comitê
estratégico definirem uma nova meta, seja recomendado aos mesmos quais as métricas
que devem ser associados à meta, com base em outras associações de metas e métricas
existentes dentro da mesma organização. Dessa forma, o processo de associação de
meta e métricas se torna mais ágil e eficiente. Por outro lado, com essa associação feita,
espera-se que seja recomendado aos membros do comitê a forma com que cada meta
deve ser acompanhada, essa recomendação também deve ser de acordo com regras
estabelecidas para acompanhar metas que possuam o mesmo conjunto de métricas
anteriormente na organização.
Com as regras autonômicas, espera-se que a infraestrutura em que a estratégia se
encontra seja capaz de agir quando determinadas situações ocorrerem, o que aumenta a
visibilidade do andamento do planejamento estratégico.
6
Com o intuito de atingir esses objetivos, propomos técnicas para a
recomendação de métricas e regras autonômicas de acompanhamento para as metas de
um BSC.
1.4. JUSTIFICATIVA
A associação entre indicadores e metas do BSC bem como o acompanhamento
de desempenho dos mesmos podem ser realizados de maneira “artesanal”. Entretanto,
sua qualidade será mais baixa pela falta de padrão em seu desenvolvimento. Dessa
forma, a execução da estratégia de uma organização será avaliada de maneira deficiente,
o que pode gerar decisões erradas e, consequentemente, o insucesso do planejamento
estratégico.
Por outro lado, dentro de uma mesma organização existem diversos setores, que
podem possuir metas similares com métodos de avaliação similares. Sem essa premissa,
metas iguais dentro de uma mesma organização serão avaliadas de forma diferente, o
que pode gerar resultados de desempenho equivocados.
Com um sistema de recomendação apoiando a associação de metas com métricas
e seu acompanhamento podemos ter uma maior qualidade nas mesmas, tornando mais
eficiente o planejamento estratégico da organização. Assim, com regras para
acompanhamento eficientes, a organização pode prever que determinada meta não será
atingida e realizar ações para evitar isso.
7
1.5. CONTRIBUIÇÕES
Algumas contribuições foram geradas no decorrer do trabalho. Uma primeira
contribuição é a criação de um sistema de recomendação de métricas para metas de um
BSC com base no histórico de utilização das métricas.
Outra contribuição do trabalho é a criação de um sistema de recomendação de
regras autonômicas para o acompanhamento da performance das metas de um BSC, i.e.,
regras que indiquem se uma determinada meta será atingida ou não. Esse sistema de
recomendação utiliza o histórico de utilizações das regras para a recomendação das
mesmas.
Por fim, como consequência disso, um sistema para definição e associação de
métricas e regras de acompanhamento à metas foi gerado, incluindo sua arquitetura e
modelo.
1.6. DEFINIÇÃO DE ESCOPO
Essa dissertação se propõe a apoiar todo o acompanhamento autonômico do
desempenho das metas de um BSC, desde a indicação de métricas para as metas, bem
como o desenvolvimento de regras de acompanhamento do desempenho de cada meta.
Esse trabalho é parte de um projeto maior, chamado TEAM (Tool for Enterprise
Autonomic Management) (MONTEIRO JR et al., 2008). A ideia desse projeto é prover
uma Empresa Autonômica, ou seja, a partir dos processos de negócio, a organização
pode obter graus elevados de gerência autonômica, como no caso do ABSC (Autonomic
Balanced Scorecard) (RODRIGUES NT, J.A. et al., 2007) ou, então, com a mineração
de um arquivo de log com as regras e os problemas encontrados, para assim o sistema
8
extrair alguma conclusões e reconfigurar o processo, seja em seu fluxo ou recursos
utilizados. Também está inserida no TEAM a rede social autonômica (SILVA, R. T. et
al., 2008) e o Autonomic Data Killing (PINHEIRO et al., 2009), que elimina da
organização os dados desnecessários, facilitando assim a análise de informações.
1.7. ESTRUTURA DA DISSERTAÇÃO
Essa dissertação está divida da seguinte forma: primeiramente uma introdução
seguida do Capítulo 2 com os conceitos relacionados. No capítulo 3 são descritos os
sistemas de recomendação propostos para a solução do problema. Posteriormente, no
capítulo 4, é apresentado um experimento, realizado através de simulações, para testar a
eficácia dos sistemas de recomendação propostos. Por fim, a dissertação é encerrada
com a conclusão e com propostas para trabalhos futuros.
9
2. CONCEITOS RELACIONADOS
Esse capítulo trata de alguns conceitos fundamentais para o entendimento dessa
dissertação. Os principais assuntos da pesquisa são descritos. Inicialmente iremos
apresentar o Balanced Scorecard (BSC), seguido por Computação Autonômica, Regras
e Linguagens para a descrição de Regras. Por fim, estão apresentados os conceitos de
Sistemas de Recomendação e Regras de Associação.
2.1. BALANCED SCORECARD
A colisão entre a necessidade de uma organização ser competitiva e se manter
competitiva ao longo dos anos com a imobilidade do modelo de contabilidade baseado
em ganhos históricos criou o Balanced Scorecard (BSC) (KAPLAN et al., 1996).
O BSC mantém a tradicional medida financeira, mas, essa medida apresenta
apenas eventos passados, o que a torna inadequada para ser a única medida para guiar e
avaliar a estratégia de uma organização. O BSC complementa a medida financeira com
medidas que avaliam o desempenho dos bens intangíveis da organização. Atualmente, o
BSC é utilizado por 53 % das organizações.
A missão de uma companhia é um texto inspiracional, que deve passar energia e
motivação para toda companhia. Por outro lado, apenas frases motivacionais e slogans
não são suficientes para que toda a companhia compreenda corretamente a estratégia da
mesma. Para resolver esse problema, o BSC provê um framework, uma linguagem, para
a comunicação da missão e da estratégia para toda organização.
10
O BSC proposto por Kaplan e Norton em (KAPLAN et al., 1992) é um sistema
de gestão organizacional que provê mecanismos para transformar a visão e a estratégia
de uma companhia em um conjunto coerente de medidas de desempenho.
Esse mecanismo consiste na construção de objetivos e indicadores que são
utilizados para indicar aos empregados qual o caminho para o sucesso atual e futuro.
Os objetivos são um conjunto de assertivas que indicam qual o desejo da
organização, i.e., aonde a organização planeja estar no fim da execução de seu
planejamento estratégico, enquanto que os indicadores são utilizados para se medir se o
objetivo foi atingido ou não, estes podem ser indicadores de tendência ou de resultado.
O BSC, como proposto por Kaplan e Norton, analisa uma organização em quatro
diferentes perspectivas, utilizando tais perspectivas para derivar métricas, colher dados e
analisá-los. Essas perspectivas ou dimensões básicas são apresentadas na Figura 1.
As perspectivas não são de forma alguma limitadas, já sendo atualmente comum
encontrar organizações que utilizam outras perspectivas, como a sustentabilidade ou
meio-ambiente (NIVEN, 2002).
Nas suas diversas perspectivas, o BSC utiliza indicadores que permitem tanto a
avaliação do que foi executado como a previsão do que deverá ocorrer. Por outro lado,
esses indicadores são também utilizados como uma forma de articular a estratégia da
organização, de comunicar a estratégia da organização e, de ajudar a alinhar as
iniciativas dos empregados e dos setores da companhia em um objetivo comum.
11
2.2. COMPUTAÇÃO AUTONÔMICA
O termo autonômico significa, de acordo com o dicionário Michaelis
(MELHORAMENTOS, 2009), que algo que seja autonômico é algo que possua
autonomia, ou seja, um sistema autonômico é aquele que possui independência
funcional. Esse termo é originado da medicina, onde, o sistema nervoso humano pode
ser considerado o mais complexo sistema autonômico existente, onde ele integra os
diversos “sensores” dos seres humanos e responde a cada estímulo de forma apropriada
(HARIRI et al., 2006).
A IBM foi quem pela primeira vez introduziu esse conceito na área da
computação, divulgando seu trabalho de pesquisa em Computação Autonômica em
Figura 1: Perspectivas de um BSC
12
Março de 2001, através de um manifesto, onde todos os conceitos dessa nova tecnologia
são explicados (HORN, 2001).
O manifesto da IBM (HORN, 2001) enumera algumas características que um
sistema deve possuir para ser considerado um sistema autonômico:
1. Conhecer a si mesmo e seus relacionamentos: O sistema deve conhecer de
forma completa seus componentes, seu estado atual, sua capacidade, e todos
os seus relacionamentos para conhecer a si mesmo. Ele precisa saber a
extensão de sua “propriedade”, quais recursos deve pegar emprestado ou
emprestar e quais que devem ser compartilhados ou isolados.
2. Saber se configurar e reconfigurar de acordo com condições variáveis e não
previsíveis: O sistema deve ser capaz de realizar sua configuração
automaticamente, bem como ajustes dinâmicos em sua configuração para se
adequar ao ambiente.
3. Não se estabilizar com o estado atual, sempre deve procurar melhorias: O
sistema deve monitorar seus componentes para atingir objetivos pré-
determinados, ajustando os mesmos de forma que os objetivos possam ser
alcançados.
4. Possuir propriedades de cura: O sistema deve ser capaz de descobrir
problemas ou potenciais problemas e buscar alternativas através de seus
recursos ou reconfigurações para assegurar que o sistema continue em
execução.
5. Se proteger: O sistema deve ser capaz de detectar, identificar e proteger a si
próprio de ataques maliciosos, de forma a manter a segurança e a integridade
de todo o sistema.
13
6. Conhecer o ambiente externo e o contexto que cerca as suas atividades: O
sistema deve ser capaz de interagir com os sistemas vizinhos, sendo capaz de
negociar o uso de recursos de outros sistemas.
7. Não deve existir isolado no mundo: O sistema autonômico deve operar em
um ambiente heterogêneo e implementar padrões abertos, em outras
palavras, por definição, um sistema autonômico não deve utilizar soluções
proprietárias.
8. Sempre aperfeiçoar seus recursos: O sistema deve ocultar dos usuários sua
complexidade.
No entanto, como é observado em (PARASHAR et al., 2006), a existência de
tais características ocorre somente em sistemas autonômicos maduros, ou seja, que
implementam de forma integral todos os conceitos da computação autonômica,
preservando seu enfoque original – com o propósito de prover características auto-*
para infraestrutura de TI. Assim, definem os requisitos abaixo como sendo os
necessários para sistemas autonômicos:
Ser robusto, ou seja, capaz de se proteger de ameaças externas e, caso seja
afetado por alguma ameaça, ser capaz de se recuperar;
Ser de fácil utilização, se adaptando ou sugerindo mudanças de acordo com as
alterações do ambiente, reduzindo a intervenção dos usuários;
Ser proativo, agindo na direção dos objetivos do sistema, independente do
controle direto de seus usuários;
Ser transparente, apresentando suas ações e explicando-as quando necessário;
Permitir a alocação flexível de responsabilidades, de acordo com o desejo do
usuário; e
14
Ser reversível, no sentido de permitir que uma ação executada seja revertida, o
máximo possível.
A computação autonômica tem algumas divisões, e, a mais aceita no meio
comercial e acadêmico é a em quatro dimensões: autoconfiguração (self-configuration),
autocura (self-healing), autootimização (self-optimization) e autoproteção (self-
protection) (MURCH, 2004). Essas dimensões são conhecidas pela sigla CHOP, onde
cada letra representa o nome de uma dimensão em inglês. Alguns trabalhos como
(BABAOĞLU, 2005) propõem outras, até mesmo a chamada auto* (autoestrela), que
inclui qualquer capacidade que um sistema é capaz de fazer automaticamente. Abaixo,
serão descritas as quatro principais dimensões da computação autonômica de acordo
com (KEPHART et al., 2003).
A autoconfiguração é a capacidade do sistema autonômico de se configurar
automaticamente de acordo com políticas de alto nível, políticas essas que podem
representar objetivos do negócio, que especificam o que é desejado, não como isso será
alcançado. Ele deve ser capaz de realizar todas as configurações necessárias para a
plataforma e usuários.
A auto-otimização é a capacidade do sistema autonômico de sempre buscar
melhorar sua operação, de forma proativa, identificando e medindo oportunidades para
se tornar mais eficiente. Assim como os músculos ficam mais fortes após uma longa
série de exercícios, os sistemas autonômicos devem monitorar e experimentar variações
em seus parâmetros, de forma a aprender a realizar as escolhas corretas.
A autocura é a capacidade do sistema autonômico de detectar, diagnosticar e
reparar problemas resultantes de “bugs” ou falhas em software ou hardware. Utilizando
seu conhecimento sobre sua configuração o sistema deve analisar arquivos de logs de
seus sensores para buscar diagnosticar problemas. Com o problema diagnosticado, o
15
sistema deve buscar resolver o problema, seja através de atualizações de software ou
trocando o componente falho por outro redundante.
A autoproteção é a capacidade do sistema autonômico de se defender de ataques
maliciosos ou de impedir que falhas corrigidas de forma errada sejam replicadas para os
outros componentes. Ele deve se antecipar aos problemas se baseando em relatórios
entregues por seus sensores, tomando medidas para evitar ou atenuar problemas.
Essas propriedades de um sistema autonômico são baseadas nas propriedades de
agentes de software ou hardware identificadas por (WOOLDRIDGE et al., 1995) que
são descritas a seguir:
Autonomia – Os agentes operam sem a intervenção direta de humanos e
possuem controle sobre suas ações e seu estado interno.
Habilidade Social – Agentes interagem com outros agentes, através de algum
tipo de linguagem.
Reatividade – Agentes percebem seu ambiente e respondem em tempo hábil às
mudanças que ocorrem nele.
Proatividade – Agentes não atuam somente respondendo ao ambiente, mas
também estão aptos a se comportarem direcionados a um objetivo, através de iniciativas
próprias.
Por outro lado, (MURCH, 2004) define cinco níveis para a implementação da
computação autonômica em uma organização, através de seu modelo de maturidade,
apresentado na Tabela 1.
De acordo com (KEPHART et al., 2003), um sistema autonômico será, na
verdade, composto de uma coleção de elementos autonômicos que são definidos como
sistemas individuais que contém recursos e entregam serviços a humanos ou outros
elementos autonômicos. Seu comportamento interno bem como seus relacionamentos
16
serão gerenciados de acordo com políticas estabelecidas pelos humanos ou por outros
sistemas autonômicos.
A representação do elemento autonômico, de acordo com (KEPHART et al.,
2003), é vista na Figura 2, onde, na parte inferior se encontra o elemento gerenciado que
pode ser de mais baixo nível como um recurso de TI (hardware ou software) ou de mais
alto nível como um processo de negócio. A ideia é que esse elemento gerenciado e o
ambiente no qual ele se encontra sejam monitorados e, a partir da análise dos dados e
informações coletadas, juntamente com os conhecimentos que o elemento autonômico
possui, sejam propostos planos de ação para uma posterior execução, facilitando assim
aquele que seria responsável pela supervisão do elemento gerenciado.
Tabela 1. Níveis da Computação Autonômica
Nível Características
1
(Básico)
Componentes da infraestrutura de TI são geridos de forma
independente, pelos profissionais de TI. Toda a gestão é executada
de forma “manual”.
2
(Gerenciado)
Sistemas de gerenciamento da infraestrutura permitem o
agrupamento de informações sobre o funcionamento de sistemas
diversos.
3
(Preditivo)
Tecnologias são utilizadas para permitir a integração de elementos
da infraestrutura, permitindo que consigam identificar padrões de
funcionamento, recomendando ações aos responsáveis pela gestão. .
4
(Adaptativo)
O progresso das tecnologias do nível anterior e a mudança de
cultura sobre seus usos permitem que os sistemas de gerenciamento
passem a tomar decisões sobre a operação da infraestrutura
baseadas em seu conhecimento do ambiente e em seu estado.
5
(Autonômico)
A operação da infraestrutura de TI passa a ser executada
automaticamente com base nas políticas estabelecidas pelos
usuários.
17
Atualmente, existem diversas pesquisas e livros sobre computação autonômica.
O livro de (PARASHAR et al., 2006) tem grande destaque na pesquisa, reunindo
trabalho de diversos autores. Esse livro é divido em duas partes: na primeira, são
reunidos trabalhos que visam explicar o que é computação autonômica e, na segunda
parte, são descritas arquiteturas e aplicações provenientes desse paradigma, mostrando
como a computação autonômica vem sendo estudada e implementada.
Também existem diversos surveys com o objetivo de definir o estado da arte da
computação autonômica. Em (NAMI et al., 2007), os autores focam nos sistemas de
computação autonômica descrevendo suas características, arquiteturas, desafios e seus
efeitos em medidas de qualidade como usabilidade, funcionalidade, segurança,
sustentabilidade e portabilidade. Já em (HUEBSCHER et al., 2008), os autores mostram
que a computação autonômica não é apenas uma sigla da moda, mas sim um paradigma
que está sendo usado amplamente na área de ciência da computação. Para isso eles
GESTOR AUTONÔMICO
ANALISAR PLANEJAR
EXECUTAR MONITORAR CONHECIMENTO
ELEMENTO GERENCIADO
Figura 2: Elemento Autonômico
18
descrevem trabalhos já desenvolvidos que contribuem para a melhoria da computação,
como o gerenciamento autonômico de energia elétrica para sistemas computacionais.
Por outro lado, em (KEPHART, 2005) são apontados os desafios na pesquisa
dos elementos autonômicos e sistemas autonômicos. São elencadas as dificuldades na
comunicação entre elementos autonômicos e a falta de padronização na representação
dos dados monitorados pelos mesmos. Outros importantes pontos citados são os
desafios na interação dos humanos com o sistema autonômico e na geração de políticas
para os mesmos.
Por fim, em (ZHAO, Z. et al., 2009), os autores descrevem o estado da arte da
computação autonômica e apontam desafios futuros, como a arquitetura de um sistema
autonômico, a falta de ferramentas para analisar, planejar, desenvolver e testar sistemas
autonômicos.Em (DOBSON et al., 2010), o autor discute sobre se a visão de Khepart e
Chess de 2001 sobre computação autonômica foi atingida e continua válida, ele aponta
outros temas de pesquisa, como o Knowledge Plane (CLARK et al., 2003), e a
utilização da ideia de enxames ou colônias de formigas para coordenar o
comportamento de robôs. Por fim, em (KEPHART, 2011), Khephart discute sobre a
primeira década da computação autonômica.
2.3. REGRA
Regras são essenciais para a computação autonômica, visto que é a forma com
que os humanos expressam seus objetivos para o sistema autonômico, essas regras são
chamadas de regras autonômicas. Segundo (KEPHART et al., 2004), existem três tipos
diferentes de regras: as regras baseadas em ações, objetivos e funções de utilidade.
19
Primeiro iremos descrever cada tipo de regra e, em seguida, iremos descrever
melhor dois tipos de regras baseadas em ações, as regras do tipo ECA (Event Condition
Action) e as regras do tipo PRR (Production Rule Representation), pois as regras
baseadas em ações são as comumente utilizadas na computação autonômica
(KEPHART et al., 2004). Por fim, iremos descrever os formatos para troca de regras.
As regras baseadas em ações representam a ação que deve ser tomada pelo
sistema caso ele se encontre em uma determinada situação. Tipicamente são regras do
tipo IF (condição) THEN (ação), onde a condição especifica um estado específico ou
um conjunto de estados que satisfazem a condição. Vale lembrar que o estado que será
alcançado após ser executadECAa uma ação não é definido, presume-se que o autor da
regra sabe qual o estado que será atingido depois de executada determinada ação.
Existem diversos trabalhos sobre regras baseadas em ação, como pode ser visto em
(EFSTRATIOU et al., 2002), (LUTFIYYA et al., 2001), (LYMBEROPOULOS et al.,
2002) e (PONNAPPAN et al., 2002).
As regras baseadas em metas, diferentemente das regras baseadas em ações que
especificam o que deve ser feito no estado atual, indicam um estado desejado ou um
conjunto de estados desejados, onde qualquer um estado do conjunto de estados
desejados é igualmente aceito. Com esse tipo de regra o sistema autonômico é
responsável por executar uma ação ou um conjunto de ações que levem o sistema de um
estado atual para um estado desejado. Esse tipo de regra permite uma maior
flexibilidade e libera os “humanos” do conhecimento dos detalhes de baixo nível do
sistema, por outro lado, exige um planejamento mais sofisticado e algoritmos de
modelagem. Diversos trabalhos tratam de regras baseadas em metas, como pode ser
visto em (WANG et al., 2001), (YOON et al., 1996), (CHANDRA et al., 2003) e
(BERGLUND et al., 2008).
20
Por fim, existem as regras baseadas em funções de utilidade, que tem como
objetivo expressar o valor de cada estado possível do sistema. Esse tipo de regra é uma
generalização das regras baseadas em metas. Invés de possuir uma classificação dos
estados desejados e indesejados, esse tipo de regra calcula dinamicamente o quanto cada
estado é desejado. Devido ao fato do estado mais desejado não ser previamente
conhecido, ele é calculado baseado na utilidade atual de cada estado, é o estado com
maior valor de utilidade. Regras baseadas em funções de utilidade proveem uma maior
granularidade e maior flexibilidade na especificação das regras em comparação com os
outros tipos de regras. Enquanto que regras baseadas em metas permitem situações em
que metas sejam conflitantes, i.e., não podem ser atingidas de forma simultânea, regras
baseadas em funções de utilidade permitem que a ambiguidade seja removida, que o
sistema tome uma decisão mais racional, através da especificação de compensações
entre os estados. Em outras palavras, regras desse tipo requerem que seus autores
especifiquem um conjunto multidimensional de preferências, o que pode ser difícil de
ser elicitado, e, além disso, exigem o uso de modelagens, otimizações e, possivelmente,
outros algoritmos. Diversos trabalhos tratam de regras baseadas em funções de
utilidade, como pode ser visto em (CHASE et al., 2001) e (WALSH et al., 2004).
Na Figura 3 é ilustrada a relação entre os diferentes tipos de regra. Regras
baseadas em Funções de utilidadade são as regras com o nível de especificação mais
alto, e podem dar origem a regras baseadas em metas ou em regras baseadas em ações.
Já as regras baseadas em metas podem apenas originar regras baseadas em ações, que
são as regras de mais baixo nível.
21
Existem diversas pesquisas nessa área, entretanto, essa pesquisa está concentrada
em regras de baixo nível baseadas em ações que devem ser tomadas quando
determinadas condições forem satisfeitas (KEPHART, 2005). Dentre as regras baseadas
em ações, um dos principais desafios é a geração da mesma. Segundo (KEPHART,
2005), a regra autonômica deve ser gerada em um processo iterativo, com interface
amigável, tornando mais simples a elicitação de regras.
Por fim, desde que regras são criadas em diferentes sistemas e distribuídas pela
Web, se faz necessária a criação de uma linguagem padrão para a troca de regras.
Adicionalmente, um formato único para as regras facilita a tomada de decisão em um
ambiente com diferentes formatos de regras (HU, Y.-J. et al., 2009). Para solucionar
esse problema, foi proposto o RIF (Rule Interchange Format) (KIFER, 2008), pelo
W3C.
2.3.1. Regras ECA
Segundo (CASATI et al., 1999), regras do tipo ECA são regras com o seguinte
formato: ON Event IF Condition DO Action. Isso significa que a ação Action será
executada somente se o evento Event ocorrer e desde que a condição Condition seja
satisfeita. Um exemplo de uma regra do tipo ECA é a invocação de Triggers em um
Figura 3: Relações entre diferentes tipos de regra
Nível das especificações do comportamento
Ações Metas Funções de Utilidade
22
banco de dados baseados em SQL, onde o evento é representado pela atualização nos
dados, a condição é a condição necessária para executar as alterações contidas na ação.
A parte do evento possui um duplo objetivo: detectar eventos de interesse e
selecionar dados de suas representações. Diferentes tipos de eventos são suportados,
variando de eventos de baixo nível, passando por eventos relacionados a manipulação
de dados e indo até eventos de alto nível, como o atraso de um vôo. Dependendo da
linguagem, eventos simples (eventos atômicos) ou eventos compostos (um conjunto de
eventos simples) são permitidos.
A parte da condição consulta o estado do mundo atual, ou seja, ela pode
consultar dados em aplicações Web ou base de dados legada, e pode ser expressa em
diversas linguagens de consulta. Da mesma forma como no evento, a condição também
seleciona dados que serão utilizados pela ação.
Por fim, a parte da ação aceita diferentes tipos, como atualização nos dados
(inserção na base de dados), alterações na regra (uma regra pode ser removida da lista
de regras a serem verificadas) chamada de novos eventos ou chamadas de rotinas
externas a regra (por exemplo, o envio de um email).
Ainda, apesar de não serem comuns, existem variações das regras ECA, existem
as regras ECAA (Event Condition Action Alternative), que indica a ação que deve ser
realizada se a condição não for satisfeita e as regras ECAP (Event Condition Action
Postcondition), que especifica uma condição que deverá ser satisfeita após a execução
da ação (BOLEY et al., 2007).
23
2.3.2. Regras PRR
Segundo (BOLEY et al., 2007), regras do tipo PRR são regras com o seguinte
formato: IF Condition DO Action. Nesse tipo de regra, a ação é executada sempre que
uma mudança no ambiente torna a condição verdadeira.
A condição consulta a memória do trabalho, memórias essas que possuem os
dados em que as regras operam. Os dados selecionados são então utilizados para
executar as ações especificadas na parte Action. Uma ação comumente contêm
operações na memória de trabalho (por exemplo, inserção de um novo dado) ou
declarações de programação procedural (por exemplo, atribuições de valor, loops).
Apesar de regras de produção e regras ECA serem regras baseadas em ações,
cada uma tem sua particularidade. Enquanto que regras ECA são mais indicadas para
aplicações distribuídas que dependem de comunicações baseadas em eventos entre seus
componentes, enquanto que as regras de produção são mais indicadas para codificar
aplicações que mantêm seu estado (BOLEY et al., 2007)
Por fim, existem algumas implementações do PRR que aceitam regras do tipo IF
Condition DO Action ELSE Alternative Action (OMG, 2009).
2.4. LINGUAGENS PARA ESPECIFICAÇÃO DE REGRAS
Nessa seção iremos falar sobre as principais linguagens para especificação de
regras de acordo com (AGRAWAL, D. et al., 2008).
24
2.4.1. PDL
A primeira linguagem que iremos citar é a PDL (Policy Description Language)
(LOBO et al., 1999), que foi desenvolvida pelo “Bell Labs” e é uma das primeiras
linguagens que especificam regras declarativas ou proposições.
As regras descritas em PDL são compostas de quatro partes principais: A regra,
o evento, a condição e a ação a ser tomada. O evento se refere ao que pode acontecer no
sistema, a condição se refere a um estado do sistema e a ação se refere ao que o sistema
deve fazer. A PDL é uma das primeiras linguagens a implementar regras do tipo ECA
(event-condition-action ou evento-condição-ação) e sua implementação do ECA foi
adotada posteriormente em diversas outras linguagens e implementações.
Por outro lado, o modelo implementado pela PDL não dá suporte a noção de
grupos de regas. Cada regra é tratada individualmente, totalmente independente das
outras regras.
2.4.2. Ponder
A Ponder é uma linguagem geral para definição de regras que define regras de
controle acesso como XACML (chamadas regras de autorização), regras de
gerenciamento utilizando PDL (chamadas obrigações), e regras relacionadas a papéis.
As regras de autorização são definidas com o sujeito, o objeto alvo, a ação a ser
executada e um conjunto de argumentos que especificam se o sujeito está autorizado a
executar a ação no objeto alvo descriminado.
Em conjunto com as regras de autorização, podem ser descritas as regras de
delegação (onde um sujeito pode, temporariamente, conceder direito de acesso a outros
25
sujeitos), as regras de filtragem de informação e as regras de abstenção (que indica que
um sujeito pode se abster de executar determinadas ações).
Por fim, o Ponder também possui o conceito de meta-regra, i.e., regras sobre
como deve se comportar um conjunto de regras.
2.4.3. CQL
A CQL (CIM Query Language) (DMTF, 2006a) foi projetada inicialmente para
consultar o modelo de informação CIM (Common Information Model) (DMTF, 2011) e
não como uma linguagem para descrição de regras. CQL é o primeiro padrão do DMTF
para facilitar a escrita de consultas para extração de dados de uma infraestrutura de
gerenciamento de dados do CIM. CQL está para o CIM assim como o SQL está para os
bacos de dados.
O documento incial do padrão CQL sugere que, para montar as regras definidas
no padrão CIM, a linguagem seja utilizada para especificar tanto as condições como as
ações de uma regra.
2.4.4. XACML
O XACML (MOSES, 2005) provê meios para a descrição de regras de controle
de acesso e também propõe um padrão para acesso a requests e responses de requisições
de controle de acesso. A regra escrita em XACML possui uma estrutura do tipo
condição-efeito, similar ao PDL, mas com a diferença que o efeito possui no máximo
dois valores: “Permitir” ou “Negar”.
26
Esse tipo de regra também possui a definição do componente alvo da regra, que
pode ser um conjunto de recursos, sujeitos, ações e ambientes em que a regra é
aplicável. Uma significante diferença entre XACML e PDL é que no XACML os
autores podem indicar a ordem em que as regras devem ser avaliadas, enquanto que em
PDL a ordem é irrelevante. Por fim, em XACML as regras podem ser organizadas de
forma hierárquica.
2.4.5. IBM ACPL
O ACPL (Autonomic Computing Policy Language) da IBM (IBM, 2005) é uma
tentativa de suportar o gerenciamento de sistemas distribuídos através da extensão do
modelo PCIM (Policy Core Information Model) (MOORE et al., 2001) e (MOORE,
2003).
O ACPL suporta dois diferentes formatos de definição de regras: um formato
XML para facilitar a distribuição e suportado pelo padrão XML incluindo todas as suas
capacidades, como validação, parser, etc, e o formato texto, podendo ser especificada
em qualquer editor de texto. A versão XML do ACPL possui as mesmas características
da versão texto do mesmo. Diferentemente de outras linguagens, o ACPL permite ao
usuário estender a linguagem e criar novas operações.
2.4.6. CIM SPL
O CIM-SPL (Simple Policy Language for CIM) (DMTF, 2006b) foi projetado
para seguir os padrões do CIM Policy Model e incorporar completamente as premissas
do CIM. Seu projeto inclui várias características das outras linguagens descritas
27
anteriormente. Ela também provê um meio de realçar os aspectos relevantes do CIM e
do CIM Policy Model.
2.5. SISTEMAS DE RECOMENDAÇÃO
Uma grande quantidade de informação disponível na Internet torna a busca por
informações relevantes uma tarefa difícil. Sistemas de recomendação são propostos
como uma saída para recuperar e agrupar informações de uma maneira eficaz
(VIVACQUA et al., 2009).
Em sistemas de recomendação, os itens existentes são ordenados de acordo com
sua utilidade e a recomendação dos mesmos para um usuário é realizada de acordo com
essa ordenação. A utilidade de um item é normalmente representada por uma taxa, que
indica o quanto um usuário gosta de um determinado item. O sistema de recomendação
provê meios de se “prever” a utilidade de um item para um determinado usuário. A
utilidade de um item pode ser estimada de acordo com três abordagens diferentes
(BALABANOVIĆ et al., 1997).
Recomendações baseadas em conteúdo (Content-based recommendations):
Recomenda ao usuário itens similares aos que ele “preferiu” anteriormente.
Recomendações colaborativas (Collaborative recommendations):
Recomenda ao usuário ítens que usuários com preferências similares
“preferiram” no passado.
Abordagens híbridas (Hybrid approaches): Nessas abordagens, os métodos
combinam características das abordagens anteriores.
Por outro lado, as abordagens citadas acima, apesar de serem as principais,
partem do princípio que existem dados históricos sobre os itens suficientes para o
28
sistema realizar a previsão da utilidade do mesmo. Em contrapartida, em (HAN, E.-H. et
al., 2005), é proposto um sistema de recomendação baseado em característica, onde
cada item possui características e, sua similaridade é feita utilizando essa informação.
Esse sistema parte da seguinte premissa: “Pessoas que compraram produtos com certas
características podem querer comprar produtos com as mesmas características”.
Segundo o autor, uma utilização dessa abordagem seria em uma loja de
eletrônicos, onde uma pessoa que compra uma TV com entrada HDMI também compra
itens que possam ser utilizados com a interface HDMI. Nesse caso, o interesse foi na
característica HDMI, não em cada item em si.
Ainda, outra importante tema de pesquisa dentro de sistemas de recomendação é
a confiança na recomendação dos itens. Quando a recomendação depende basicamente
da avaliação dos itens pelas pessoas, como pode ser visto no sistema de recomendação
proposto em (TOMAZ et al., 2009) , é necessário se criar mecanismos para premiar o
usuário que avalia os itens honestamente. Em (GARCIA et al., 2004) e (EKSTROM et
al., 2005) esse tema é discutido amplamente e é proposto um mecanismo para resolver
esse problema, chamado HYRIWYG (How you rate influence what you get, ou, em
português, Como você avalia influencia o que você recebe), premiando os usuário que
avaliam honestamente os itens e punindo os demais.
Esse sistema foi utilizado em trabalhos como (GARCIA et al., 2005), (TOMAZ
et al., 2009) e (TOMAZ et al., 2011) (TOMAZ et al., 2011), onde, para um sistema de
recomendação de modelos de processo, não existe apenas a pontuação do modelo, mas
também dos modeladores, que é chamada de reputação do modelador, que interfere
diretamente no peso da nota dada por um modelador a um modelo.
Hoje em dia, sistemas de recomendação são largamente utilizados, desde em
aplicações de compra e venda, como o site da Amazon, softwares de apoio a engenharia
29
de software, como pode ser visto em (TOMAZ et al., 2011) e (ROBILLARD et al.,
2010) ou sistemas para recomendar páginas que substituem links quebrados na web
(MARTINEZ-ROMO et al., 2011).
2.5.1. Recomendações Baseadas em Conteúdo
Em métodos de recomendação baseados em conteúdo, a utilidade de um item i
para um usuário u é estimada com base no grau de utilidade dado pelo usuário u,
anteriormente, a outros itens similares ao item i. Esse tipo de método tem sua origem
em técnicas de Recuperação da Informação (BAEZA-YATES et al., 1999) e (SALTON,
1988) e pesquisas de filtragem de informação (BELKIN et al., 1992), onde são
diferenciados pela utilização de informação pelos usuários.
Essa abordagem possui alguns problemas, como o fato das técnicas baseadas em
conteúdo serem limitadas pelas características que são explicitamente associadas com os
objetos recomendados. Portanto, para possuir uma quantidade significante de
características, essas devem ser retiradas do objeto automaticamente ou devem ser
associadas a ele. Outro problema é que, se dois itens diferentes possuem o mesmo
conjunto de características, a abordagem não consegue diferenciá-los.
Outra importante característica dessa abordagem é que o usuário necessita
recomendar certa quantidade de itens para o sistema ser capaz de “aprender o gosto” do
mesmo, como em um treinamento, e ser capaz de realizar recomendações eficientes.
Em (PAZZANI, MICHAEL J. et al., 2007), são apresentados diversos
algoritmos para recomendações baseadas em conteúdo bem como as tendências de
pesquisa nessa área. Segundo os autores, a nova tendência desse tipo de recomendação é
utilizar modelos relacionados às buscas feitas pelos usuários, invés do tradicional tf*idf,
30
podendo assim sempre recuperar novas informações sobre os interesses do usuário. Essa
abordagem é utilizada em outros trabalhos, como em (ZHANG, Z.-K. et al., 2008), onde
uma rede de colaboração é criada com base em palavras chaves utilizadas em buscas, e,
em (ALBANESE et al., 2010), onde um sistema de recomendação de imagens é
apresentado, sendo que esse sistema não recomenda imagens apenas por similaridade de
imagens, mas também das buscas por imagens feitas pelos usuários.
2.5.2. Recomendações Colaborativas
Em métodos colaborativos, os sistemas buscam prever a utilidade de itens para
um usuário específico com base nas recomendações de itens feitas por outros usuários
similares a ele, i.e., com as mesmas preferências. De acordo com (BREESE et al.,
1998), os algoritmos desse tipo de abordagem podem ser classificados em dois grupos:
os baseados em memória e os baseados em modelo.
Os algoritmos baseados em memória são essencialmente heurísticos e fazem as
predições das avaliações baseados em toda a coleção de itens recomendados pelos
usuários similares. Em contraste a esses estão os baseados em modelo, que são
algoritmos que usam tais coleções para montarem um modelo, e o mesmo é utilizado
para realizar as predições.
Esse método também apresenta problemas ao absorver um novo usuário, pois ele
não é capaz de identificar os usuários similares a ele, visto que o novo usuário ainda não
realizou recomendações.
Outro problema parecido é a absorção de novos itens pelo sistema. Quando um
item é criado ele ainda não recebeu recomendações, o que impede que o sistema
recomende o item.
31
Por fim, esse método também pode ter um problema relativo ao pouco número
de recomendações feitas em relação ao número que seria necessário para ser realizada
uma predição eficaz. Isso ocorre principalmente em uma coleção onde o número de
recomendações por item é bastante reduzido (ADOMAVICIUS et al., 2005).
2.5.3. Abordagem Híbrida
A abordagem híbrida combina técnicas das abordagens colaborativas com
técnicas das abordagens baseadas em conteúdo. Segundo (ADOMAVICIUS et al.,
2005), esta combinação pode acontecer de quatro formas diferentes:
Implementando as abordagens colaborativas e baseadas em conteúdo
separadamente e combinando suas predições ou ter ambas disponíveis, sendo a
predição utilizada determinada por algumas métricas.
Incorporando características da abordagem baseada em conteúdo em uma
abordagem colaborativa. Em geral se adiciona o conteúdo do perfil do usuário
para refinamento do algoritmo de recomendação.
Incorporando características da abordagem colaborativa em uma abordagem
baseada em conteúdo. Nesse caso, são utilizadas visões para agrupar perfis de
usuários com conteúdo semelhantes.
Construindo um método único que incorpore características de ambas as
abordagens.
A abordagem híbrida é utilizada na tentativa de evitar algumas limitações
impostas pelas abordagens colaborativas e baseadas em conteúdo. As diferentes formas
de combinação das abordagens são utilizadas para priorizar as qualidades que a
abordagem híbrida deve possuir.
32
Por fim, existem diversos trabalhos que comparam a abordagem híbrida com as
outras duas e, através de experimentos, mostram que ela obtém um desempenho
superior se comparado com as abordagens puras (BALABANOVIĆ et al., 1997),
(MELVILLE et al., 2002), (PAZZANI, M. J, 1999), (NICHOLAS, I. S. C. et al., 1999),
(TORRES et al., 2004) e (SU et al., 2007).
Ainda, a abordagem híbrida é utilizada em diversos trabalhos, como em
(SHAHABI et al., 2003), onde um sistema de recomendação híbrido é utilizado para a
recomendação de produtos.
2.6. REGRAS DE ASSOCIAÇÃO
Regras de associação (AGRAWAL, R. et al., 1993) (HAN, J. et al., 2011) é uma
das várias metodologias de data mining, e, desde sua concepção por Agrawal e outros,
tem sido alvo de intenso interesse científico, tendo se tornado rapidamente uma grande
área de pesquisa (TANG et al., 2008). A metodologia consiste em encontrar regras que
descrevem o comportamento dos dados. Com essas regras é possível descobrir, com o
embasamento de certas métricas e parâmetros, informações sobre dados frequentes.
Essa metodologia é também conhecida como a análise de cestas de compras e,
historicamente, foi uma das metodologias mais importantes para pesquisa em data
mining. Sua importância é devido ao fato de que os produtos presentes em compras em
lote, ou seja, diversos produtos comprados em conjunto, são uma informação de grande
valor para as empresas, visto que essas podem otimizar suas vendas entendendo o
comportamento de compra.
Além da análise de vendas em conjunto, a técnica de regras de associação pode
ser empregada juntamente com técnicas de diversas outras áreas de pesquisa, como
33
análise de sites web (TAM et al., 2005), ontologias (BI et al., 2003) e recuperação da
informação (KOURIS et al., 2005).
O resultado da aplicação dessa metodologia sobre um conjunto de dados é a
geração de regras simples (apenas um componente ocorrendo em ambos os lados da
regra) ou compostas (implicação composta por mais de um componente em um ou
ambos os lados da regra).
As regras são formadas por operadores lógicos separados entre o antecedente e o
consequente da regra. Regras de associação são formadas basicamente a partir do ajuste
de dois parâmetros: o suporte e a confiança:
Suporte: Dada uma regra A →a sua medida de suporte – sup(A → –
representa a porcentagem de transações da base de dados que contêm os itens de
A e B, indicando a relevância da mesma. O suporte é uma medida relativa à
frequência de ocorrência da regra na massa de dados, ou seja, indica a sua
significância estatística.
Confiança: Dada uma regra A →a sua medida de confiança – conf(A →
– representa, dentre as transações que possuem os itens de A, a porcentagem de
transações que possuem também os itens de B, indicando a validade da regra.
Assim sendo, a confiança é um parâmetro que indica a força de uma regra.
Através do ajuste dos parâmetros de suporte e confiança é possível filtrar as
regras obtidas. Em geral, um valor de suporte muito baixo gera uma grande quantidade
de regras e, a medida que esse suporte vai sendo aumentado, uma conjunto de regras
mais frequentes na base vai sendo apresentado. O parâmetro confiança também é de
suma importância, porque não necessariamente as regras mais frequentes na base de
dados são as de maior confiança.
34
Muitas vezes confiança e suporte altos não indicam necessariamente uma regra
que já não se conheça. Na realidade, regras como essas, de alto suporte e alta confiança,
podem facilmente ser identificadas pelo especialista do domínio da aplicação, sem a
necessidade de ferramentas para a extração de conhecimento em geral, mas somente por
observação e experiência.
Por essa razão, existem algumas métricas que visam identificar o grau de
interesse das regras. Há diversas métricas como all-confidence (BRIN; MOTWANI;
ULLMAN; et al., 1997), conviction (PIATETSKY-SHAPIRO, 1991), leverage
(AGGARWAL et al., 1998), collective strength (BRIN; MOTWANI; ULLMAN; et al.,
1997) e o comumente utilizado lift (BRIN; MOTWANI; SILVERSTEIN, 1997).
Contudo, essas são métricas estatísticas. Muitas vezes, essas métricas se baseiam na
imprevisibilidade de algum componente no antecedente ou no consequente da regra,
sem levar em conta aspectos do domínio do problema tratado. Assim sendo, a análise de
regras pode ser fruto de uma mineração de dados ou de um trabalho manual, sendo este
mais custoso e, por ser manual é mais subjetivo e necessita de consultas especialista do
domínio (AGRAWAL, R. et al., 1993).
Para exemplificar as regras e como são geradas, na tabela 3 são apresentadas as
regras de associação entre produtos, com base nas compras descritas na tabela 2.
Tabela 2. Análise de cestas de compras
Compra Items comprados em conjunto
1 {pão, leite}
2 {pão, fralda, cerveja, ovo}
3 {pão, fralda, cerveja, refrigerante}
4 {pão, leite, fralda, cerveja}
5 {pão, leite, fralda, refrigerante}
35
Tabela 3. Regras de Associação
Regra Suporte Confiança
{leite, fralda} → {cerveja} 0.2 0.34
{leite, cerveja} → {fralda} 0.2 1.0
{fralda, cerveja} → {leite} 0.2 0.34
{cerveja} → {leite, fralda} 0.2 0.34
{fralda} → {leite, cerveja} 0.2 0.5
{leite} → {fralda, cerveja} 0.2 0.5
36
3. RECOMENDAÇÃO DE MÉTRICAS E REGRAS
Nesse capítulo, serão descritos os sistemas de recomendação indicados na seção
1.3. Inicialmente será descrito o funcionamento do sistema de recomendação de
métricas para a meta e, em seguida, o funcionamento do sistema de recomendação de
regras autonômicas para a meta do BSC.
3.1. SISTEMA DE RECOMENDAÇÃO PARA AS MÉTRICAS DA META
Como descrito no capítulo 1, indicar as métricas para as metas do BSC de uma
organização pode ser uma tarefa árdua, visto que podem existir diversas metas
diferentes no BSC, e um conjunto de métricas ainda maior. Ainda, existem conjuntos de
métricas que devem ser utilizadas em conjunto, aumentando a complexidade dessa
escolha. Para solucionar esse problema, propomos a utilização de um sistema de
recomendação. Nessa seção iremos descrever nossa proposta de sistema de
recomendação para as métricas da meta.
Antes do detalhamento do sistema de recomendação, é necessária a apresentação
do conceito de “cesta de compras”, que norteia todo o projeto do nosso sistema de
recomendação. Esse conceito foi apresentado incialmente em (AGRAWAL, R. et al.,
1993), onde o autor define cesta de compras como os itens que são comprados juntos
por um usuário. Para resolver esse problema comumente é utilizado o modelo de regras
de associação.
Existem diversos trabalhos relacionando sistemas de recomendação com regras
de associação. Em (LIN et al., 2002), é criado um algoritmo para regras de associação
específico para um sistema de recomendação. Já em (SANDVIG et al., 2007), o autor
37
utiliza das regras de associação para melhorar a confiança no resultado de um sistema
de recomendação baseado apenas em modelos de usuário. Por outro lado, em (KIM et
al., 2011), as regras de associação são utilizadas em um sistema de recomendação de
produtos em um e-commerce, onde são geradas regras entre produtos clicados, produtos
incluídos na cesta de compras e produtos comprados.
De outra forma, as regras de associação são utilizadas em conjunto com sistemas
de recomendação para evitar o problema de cold-start, que existe quando não há
histórico suficiente sobre determinado item ou pessoa, dependendo do tipo do sistema
de recomendação (SHAW et al., 2009). Como não há uma base histórica, as
recomendações iniciais possuem menos eficácia e, com o aumento dessa base, o sistema
de recomendação se torna mais eficaz.
Voltando ao nosso sistema de recomendação, o problema na recomendação de
métricas consiste em recomendar a próxima métrica a ser escolhida para uma meta, com
base nas métricas previamente escolhidas para a meta que está sendo trabalhada e na
utilização das demais métrcias pelas outras metas da organização. Esse sistema de
recomendação foi desenvolvido com base em regras de associação.
Nosso problema se assemelha bastante com o problema da cesta de compras,
onde podemos considerar o comprador como a meta e, os produtos como as métricas,
por isso decidimos utilizar as regras de associação. Nosso sistema tem a finalidade de
recomendar métricas para a meta, de acordo com as utilizações passadas das métricas
em outras metas. Para tal, iremos criar regras de associação entre as métricas de acordo
com suas utilizações em cada meta.
Por outro lado, para solucionar o problema de cestas de compras, as regras de
associação são geradas completamente, i.e., dado um conjunto de vendas, são geradas
todas as regras possíveis para aquele conjunto, com um suporte e confiança mínimos, o
38
que, em um sistema de recomendação é ineficiente, pois a recomendação é feita
direcionada para um usuário (LIN et al., 2002). Para resolver esse problema foi proposto
em (LIN et al., 2002) um algoritmo para geração de regras de associação onde já se
conhece o antecedente da regra, o que diminui a quantidade de regras geradas,
aumentanto a performance do algoritmo. Outra característica dessa proposta é a não
utilização de um suporte mínimo para a geração das regras, o suporte é ajustado
dinâmicamente, de acordo com a quantidade de sugestões que o usuário deseja receber.
O sistema possuirá três comportamentos distintos, um para o caso de
recomendar a primeira métrica para meta, outro para o caso de não existir regras de
associação entre as métricas escolhidas e não escolhidas e, por fim, um último para o
caso de existir regras de associação entre as métricas escolhidas e não escolhidas.
Para o primeiro caso, como nenhuma métrica ainda foi escolhida, não existem
regras de associação disponíveis. Devido a isso, as métricas são ordenadas de acordo
com sua utilização total em todas as metas, i.e., a métrica que mais foi utilizada em
metas é a que vem em primeiro, e assim por diante.
O segundo caso ocorre quando, para um conjunto de métricas selecionadas A
para a meta m, não existe nenhum conjunto de métricas B onde exista a regra A → B,
i.e., sup(A→B) = 0. Esse caso se assemelha ao caso anterior, onde não existem regras
de associação disponíveis, e, possui o mesmo comportamento, a recomendação é
realizada de acordo com a utilização total da métrica por todas as metas.
Por fim, o último caso é o caso onde para o conjunto de métricas selecionadas A
para a meta m, existe ao menos uma métrica i onde a regra A → i existe. Nesse caso, as
métricas são ordenadas de acordo com a confiança da regra A → i, conf(A → i),onde A
é o conjunto de métricas já escolhidas para a meta m e i a métrica listada.
39
Como proposto em (LIN et al., 2002), não consideramos o suporte na geração da
regra e, também optamos por não considerar o suporte da regra na ordenação da mesma,
pois quanto maior a confiança de uma regra, maior o seu suporte, logo, apenas a
utilização da confiança já nos indica a regra mais recorrente.
Dado isso, podemos definir a fórmula de pontuação de cada métrica, mas,
primeiro, precisamos definir algumas variáveis:
m – métrica;
M – Conjunto de métricas de uma organização;
g – meta;
AMg – Conjunto de métricas associadas a meta g;
Um – Qtde de utilizações da métrica m por todas as metas da organização.
PUm – Pontos de utilização da métrica m.
PRm – Pontuação de recomendação da métrica m.
conf(A → m) – Confiança da regra onde A implica em m.
Então, podemos definir PUm como:
∑ | |
Como descrito acima, a pontuação de utilização de uma métrica m é definida
com base na utilização da métrica m e na utilização de todas as as métricas da
organização. Como o numerador da fração sempre será menor ou igual ao denominador,
a fração sempre terá como resultado valores entre 0 e 1. Para facilitar a leitura da
40
pontuação pelo usuário, multiplicamos esse valor por 100, o que deixa a pontuação de
utilização de uma métrica com valores entre 0 e 100.
Agora, podemos definir Pm como:
{
| |
{ }
( ) | |
Como descrito anteriormente, se nenhuma métrica for associada a meta, a
pontuação da métrica é sua quantidade de utilizações entre todas as metas da
organização. Caso o conjunto de métricas escolhidas não seja utilizado em conjunto
com nenhuma outra métrica, a pontuação das métricas recomendadas também é a
quantidade de utilizações entre todas as metas da organização, caso contrário, é a
confiança da regra onde o conjunto de métricas associadas à meta implicam na métrica.
Assim como na fórmula de pontuação de utilização da métrica, a confiança da regra
sempre possuirá valores entre 0 e 1, então, multiplicamos esse valor por 100 para
facilitar a leitura da potuação pelo usuário, agora, o valor sempre será entre 0 e 100.
Abaixo iremos descrever um exemplo do comportamento do algoritmo, dado:
Conjunto de metas G = {g1, g2, g3, g4, g5};
Conjunto de métricas M = {m1, m2, m3, m4, m5};
Conjunto de associações entre metas e métricas AMg = representa as métricas da
meta g.
AMg1 = {m1, m2}, AMg2 = {m1, m3, m4, m5}, AMg3 = {m1, m2, m3, m5};
Utilização Um representa a utilização da métrica m.
Nesse caso, ocorrerão os seguintes passos ao escolher a meta m4 para indicar
métricas:
41
1. O sistema irá, inicialmente, recomendar a escolha da métrica m1, pois é a
métrica mais utilizada (é utilizada por todas as metas), Ug1 = 3.
2. Após a escolha da primeira métrica, vamos considerar que foi escolhida a
métrica m1, o sistema irá recomendar a métrica que mais vezes apareceu junto
com m1, que são as métricas m2, m3 e m5 pois as regras mais frequentes são m1
→ m2, m1 → m3 e m1 → m5, i.e., conf(m1 → m2) = conf(m1 → m3) = conf(m1
→ m5) = 0,28.
3. Após a escolha da segunda métrica, vamos considerar que foi escolhida a
métrica m2, serão recomendadas apenas as métricas m3 e m5. Note que m4 foi
ignorada, visto que em nenhuma meta existe a combinação m1, m2 e m4, i.e., não
existe a regra {m1, m2} → m4.
Por outro lado, ao escolher as métricas para a meta m5, podem ocorrer os
seguintes passos:
1. O sistema irá, inicialmente, recomendar a escolha da métrica i1, pois é a métrica
mais utilizada (é utilizada por todas as metas) , Ug1 = 3.
2. Após a escolha da primeira métrica, vamos considerar que foi escolhida a
métrica m2, o sistema irá recomendar a métrica que mais vezes apareceu junto
com m2, que é a métrica m1, pois a regra mais frequente é m2 => m1, i.e.,
conf(m2 → m1) = 1. Vale notar que a métrica m4 não foi recomendada, visto que
nunca foi utilizada em conjunto com m2.
3. Após a escolha da segunda métrica, vamos considerar que foi escolhida a
métrica m4, o sistema irá recomendar novamente a métrica mais utilizada, a
métrica m1. Isso ocorreu pois {m2, m4} => ∅.
42
3.2. SISTEMA DE RECOMENDAÇÃO PARA AS REGRAS DE ACOMPANHAMENTO
Após a recomendação das métricas, temos um novo problema, que é recomendar
a melhor forma de acompanhar cada métrica, aumentando a chance de sucesso no
alcance da meta. Para resolver esse problema, propomos novamente a utilização de um
sistema de recomendação. Nessa seção iremos descrever nossa proposta de sistema de
recomendação para as regras de acompanhamento das metas.
Em nosso trabalho, as regras de acompanhamento serão implementadas por
regras autonômicas, logo, nosso problema se resume em recomendar regras
autonômicas de acordo com a meta escolhida e as métricas associadas a mesma.
Nosso sistema de recomendação para as regras de acompanhamento funcionará
da seguinte forma: Para uma dada meta o sistema irá recomendar regras que possuam as
métricas associadas à meta em sua expressão de verificação, entretanto, a regra não
precisa utilizar todas as métricas, mas não pode utilizar nenhuma métrica diferente das
métricas da meta. As regras recomendadas serão ordenadas de acordo com as suas
pontuações totais.
A pontuação total de uma regra é um indicador do grau de utilização da mesma.
Para calcular tal pontuação são considerados três fatores, a utilização da regra nas metas
da organização, a quantidade de regras que a regra influenciou e a influência recebida
pela regra através de suas regras base, i.e., as regras que contribuiram para sua geração.
Quanto maior a pontuação total de uma regra, maior será seu grau de utilização.
Para ilustrar melhor esse sistema, nas seções seguintes iremos descrever como
deve ser realizado o cálculo da pontuação total de uma regra. Na seção 3.2.1 iremos
definir algumas variáveis que serão utilizadas nas fórmulas. Em seguida, na seção 3.2.2
será descrita a fórmula para o cálculo da pontuação inicial de uma regra, na seção 3.2.3
43
será descrita a fórmula para o cálculo da pontuação por utilização da regra e, na seção
3.2.4 será descrita a fórmula para o cálculo da pontuação de influência da regra. Por
fim, na seção 3.2.4, é descrita a fórmula para o cálculo da pontuação total de uma regra.
3.2.1. Variáveis
Nessa seção serão definidas algumas variáveis necessárias para o entendimento
do sistema, elas seguem abaixo:
R – Representa o conjunto total de regras existentes na base de dados.
K – Representa o conjunto de regras que influenciaram na criação de uma nova
regra, K R.
G – Representa o conjunto total de metas existentes na organização.
AGr – Representa o conjunto de metas que utilizam a regra r como regra de
acompanhamento, AGr M.
RCr - Representa o conjunto de regras que foram criadas com base na regra r,
RCr R.
PIr – É a pontuação inicial de uma regra r.
PUr – É a pontuação de utilização de uma regra r.
PNr – É a pontuação de influência de uma regra r.
PTr – É a pontuação total de uma regra r.
wi – Peso da pontuação inicial da regra.
wu – Peso da pontuação de utilização da regra.
wn - Peso da pontuação de influência da regra.
44
3.2.2. Pontuação Inicial da Regra
Para o cálculo da pontuação inicial da regra serão consideradas a pontuação
inicial de todas as regras que influenciaram na criação da nova regra, como descrito
abaixo.
∑ | |
| |
A pontuação inicial de uma regra é baseada na pontuação total de todas as regras
que influenciaram em sua criação. Isso é feito por considerarmos que, se uma regra é
uma evolução de outras regras, ela deve carregar um percentual da pontuação das regras
nas quais foi baseada. Ela pode ser vista como o DNA da regra. Ela é calculada através
da média aritmética do somatório das pontuações totais de todos as k regras que
influenciaram na criação da regra r.
3.2.3. Pontuação de Utilização da Regra
Para o cálculo da pontuação de utilização da regra serão consideradas todas as
suas utilizações pelas metas da organização.
∑
| |
A pontuação de utilização de uma regra é baseada diretamente na quantidade de
metas que utilizam a regra dentre suas regras de acompanhamento. Cada utilização da
45
regra incrementa de 1 a pontuação de utilização da regra. Isso é feito por considerarmos
que, quanto maior a utilização de uma regra, maior a sua importância e padronização,
assim como a qualidade de sua descrição.
3.2.4. Pontuação de Influência da Regra
Para o cálculo da pontuação de influência da regra serão consideradas todas as
regras que foram influenciadas na criação pela mesma.
∑
| |
A pontuação de influência de uma regra é baseada diretamente na quantidade de
regras que foram influenciadas pela regra na sua criação. Cada regra influenciada
incrementa de 1 a pontuação de influência da regra. Isso é feito por considerarmos que,
quanto maior a influência de uma regra, maior a sua importância e padronização, assim
como a qualidade de sua descrição.
3.2.5. Pontuação Total da Regra
Para o cálculo da pontuação total de uma regra, consideramos a pontuação
inicial da regra, sua pontuação de utilização e sua pontuação de influência, podendo, a
critério do administrador do sistema, serem indicados pesos diferentes para cada
pontuação.
46
( ) ( ) ( )
A pontuação total da regra é a soma aritmética da pontuação inicial, da
pontuação de utilização e da pontuação de influência da mesma. Para cada pontuação
pode ser atribuído um peso diferente, sendo possível atribuir maior importância para
determinado tipo de pontuação. Isso é feito para a pontuação total representar melhor a
vontade da organização, i.e., se a ideia for reutilizar ao máximo as regras, as pontuações
de utilização e de influência devem possuir um peso maior, por outro lado, se for
priorizada uma melhor construção das regras, a pontuação inicial deve ser destacada.
47
4. EXPERIMENTO
Para comprovar ou não a eficiência no processo de indicação de métricas para a
meta e na indicação de regras de acompanhamento para a meta, foram realizadas
simulações da utilização da ferramenta. A técnica de simulação utilizada foi a simulação
de Monte Carlo (METROPOLIS et al., 1949) e (LAW et al., 1999). Primeiro iremos
descrever a simulação realizada sobre o sistema de recomendação de métricas e, em
seguida, a simulação realizada sobre o sistema de recomendação de regras.
4.1. SIMULAÇÃO PARA RECOMENDAÇÃO DE MÉTRICAS
Essa simulação foi realizada para responder a seguinte pergunta:
A métrica nas primeiras posições da recomendação são métricas úteis para a
meta?
Para avaliar o resultado da simulação utilizamos 2 indicadores:
Posição média da métrica recomendada em uma lista de métricas disponíveis; e
Quantidade de vêzes em que a métrica desejada aparece na lista das 10 primeiras
(top ten).
Ainda, para verificar a significância do resultado obtido, utilizamos o teste
estatístico de hipótese descrito em (WACKERLY et al., 2007), a execução do mesmoi é
descrita abaixo:
μa = Posição média da métrica desejada no sistema de recomendação por
utilização.
μb = Posição média da métrica desejada no sistema de recomendação proposto.
H0 = μa = μb
48
Ha = μa ≠ μb.
Α = .05.
Para realizar a simulação nós consideramos que os membros do comitê
estratégico de uma organização irão desenvolver um novo BSC, incluindo a associação
de métricas a meta.
As seções seguintes estão organizadas da seguinte forma: Inicialmente iremos
descrever o processo de simulação. Em seguida, os valores utilizados nas simulações
são descritos e, por fim, os resultados obtidos são discutidos.
4.1.1. Processo de Simulação
A simulação será divida em 2 etapas. Na primeira etapa, chamada de etapa I, um
BSC fictício, abstrato é desenvolvido, na segunda etapa, chamada de etapa II, o
algoritmo proposto é comparado com outras formas de recomendação, utilizando o BSC
fictício como referência.
Voltando a etapa I, a construção do BSC é feita considerando dois cenários
diferentes:
Cenário Aleatório – Nesse cenário as métricas são escolhidas aletatoriamente.
Esse formato representa o pior caso possível, onde não existe qualquer relação
entre as métricas e dificilmente será encontrado no mundo real. A simulação
nesse caso visa demonstrar que, mesmo no pior caso, onde não há a relação
explícita entre as métricas, a utilização de regras de associação pode ser
benéfica.
Cenário Agrupado – Agora, as méticas serão separadas em 4 grupos
aleatoriamente e, quando for escolhida a primeira métrica de uma meta, o grupo
49
selecionado será utilizado para escolher todas as outras métricas da meta. As
métricas dentro do grupo serão escolhidas de forma aleatória. Esse formato se
aproxima mais da realidade, pois considera que existem métricas que são
utilizadas em conjunto. Nesse caso, a simulação procura reproduzir mais
fielmente um ambiente real, onde as métricas são relacionadas explicitamente.
Na etapa II, foi simulado um ambiente onde os membros do comitê possuem o
auxílio de um sistema de recomendação que ordena as métricas por utilização e um
ambiente onde as métricas são ordenadas de acordo com o sistema de recomendação
proposto nessa dissertação.
O processo de simulação é apresentado a seguir. O passo incial é a definição de
algumas variáveis necessárias à execução, elas estão descritas abaixo:
qtdeMetas – Quantidade de metas do BSC.
qtdeMetricas – Quantidade de métricas existentes na organização.
qtdeMetricasMeta – Quantidade de métricas associadas à uma meta do BSC.
Após as variáveis serem inicializadas, é executada a etapa I, i.e., o BSC fictício é
gerado, sem a ajuda de nenhum sistema de recomendação. Após o desenvolvimento do
BSC fictício, na etapa II, o mesmo BSC é contruído com o auxílio do sistema de
recomendação onde as métricas são ordenadas pela sua utilização e do sistema de
recomendação proposto nessa dissertação. Esses diferentes desenvolvimentos são
realizados de forma tal que, no fim do processo, todos os BSC gerados devem ser
iguais.
50
4.1.2. Execução da Simulação
Para executar a simulação, foram atribuídos valores diferentes às variáveis
iniciais, sendo cada execução repetida 100 vezes. Abaixo são listados os valores
utilizados em cada variável.
qtdeMetas – 2, 5, 8, 10, 20, 30, 50, 80, 100, 200 e 800.
qtdeMetricas – 80.
qtdeMetricasMeta – 2, 5, 10 e 20.
Será executada uma simulação para cada tupla (qtdeMetas, qtdeMetricas,
qtdeMetricasMeta) existente, sempre que nos referirmos a uma dada configuração,
faremos através do formato qtdeMetas/ qtdeMetricas/qtdeMetricasMeta.
Os valores foram escolhidos de forma a verificar se, a quantidade de metas
existentes e o número de métricas por meta influenciam no desempenho de nosso
sistema de recomendação.
Sobre a escolha do número de metas, pode-se perceber que existem números
muito baixos, como 2 e 5, que buscam avaliar o comportamento do nosso sistema de
recomendação com relação ao cold-start. Por outro lado, existem valores bem altos,
como 800, que busca avaliar se, ao longo da utilização do mesmo por uma organização
o nosso sistema de recomendação continua apresentando bom rendimento.
51
4.1.3. Resultados
Nessa seção iremos apresentar os resultados obtidos com as diversas simulações.
Para facilitar a análise dos resultados, agrupamos os mesmos de acordo com a
quantidade de metas. Para cada cenário, agrupamos as execuções da seguinte forma:
Grupo I – execuções com 2, 5, 8 e 10 metas.
Grupo II – execuções com 20, 30, 50 e 80 metas.
Grupo III – execuções com 100, 200 e 800 metas.
Inicialmente comparamos o desempenho dos sistemas de recomendação para as
configurações presentes no Grupo I, para o cenário aleatório. O gráfico que apresenta a
compração da posição média da métrica desejada é apresentado na Figura 4 e o
percentual de acerto no top 10 é apresentado na Figura 5.
Como pode ser visto no gráfico, com apenas 2 métricas por meta, para todas as
configurações do grupo, os dois sistemas se comportam de maneira similar, pois nosso
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 4: Análise posição média da métrica nas configurações do Grupo I no cenário
aleatório.
52
sistema pode recomendar apenas a segunda métrica e, como poucas métricas são
escolhidas ao todo, são geradas poucas regras de associação.
Ainda, na configuração com apenas 2 metas, não existe diferença entre utilizar
nosso sistema de recomendação ou o sistema que apenas ordena por utilização. Por
outro lado, com o, com o aumento no número de métricas por meta, podemos ver que
nosso sistema de recomendação começa de apresentar algum ganho em relação ao
outro. Isso ocorre pois no ínicio, ambos os sitemas possuem o problema do cold-start,
entretanto, como podemos perceber, nosso sistema de recomendação “esquenta” mais
rápido que o que apenas ordena pela utilização.
Por outro lado, analisando o percentual de acerto no top 10, podemos perceber o
mesmo comportamento do outro gráifco, onde nosso sistema de recomendação possui
um desempenho superior apenas com o aumento do número de metas e de métricas por
meta.
0%
5%
10%
15%
20%
25%
30%
35%P
erc
en
tual
de
ace
rto
no
to
p 1
0
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 5: Análise do percentual de acerto no top 10 das configurações do Grupo I no
cenário aleatório.
53
Ainda, com o teste estatístico de hipótese, podemos afirmar que apenas nas
configurações 5/80/20, 8/80/10, 8/80/20, 10/80/10 e 10/80/20 nosso sistema de
recomendação possui um desempenho superior em relação ao outro.
Agora, nas Figuras 6 e 7, iremos analisar o resultado do Grupo I no cenário
agrupado.
Na Figura 6 podemos ver o comportamento dos sistemas de recomendação co
relação à posição média da métrica no cenário agrupado. Pode-se perceber que o
comportamento é bem parecido com o do cenário aleatório, sendo o desempenho igual
com apenas 2 metas e bastante parecido com apenas 2 métricas por meta nas demais
configurações. Por outro lado, ao aumentar o número de métricas por meta, nosso
sitema de recomendação começa a ser superior de forma mais rápida, i.e., ele
“esquenta” mais rápido nesse cenário do que no aleatório.
Essa diferença de ganho acontece pois, como as métricas são dividas em 4
grupos, ao aumentar o número de métricas por meta, a utilização das métricas aumenta.
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 6: Análise posição média da métrica nas configurações do Grupo I no cenário
agrupado.
54
Esse comportamento confunde o sistema de recomendação que se baseia somente na
utilização das métricas, visto que existem regras sem associação entre elas com
pontuação alta. Nesse cenário nosso sistema de recomendação tem atuação bastante
superior.
Ainda, analisando o percentual de acerto no top 10, percebemos que com 2
metas ou com 2 métricas por meta o desempenho foi novamente similar ao cenário
aleatório.
Por fim, utilizando o teste estatístico de hipótese, temos um resultado um pouco
diferente, onde podemos afirmar que nas configurações 5/80/10, 5/80/20, 8/80/5,
8/80/10, 8/80/20, 10/80/5, 10/80/10 e 10/80/20 nosso sistema de recomendação possui
um desempenho superior em relação ao outro. Nesse cenário, quase metade das
configurações puderam ter sua significância comprovada.
Agora, iremos analisar os resultados do Grupo II para o cenário aleatório. Na
Figura 8 apresentamos a análise da posição média da métrica desejada. Como podemos
0%
10%
20%
30%
40%
50%
60%
70%P
erc
en
tual
de
ace
rto
no
to
p 1
0
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 7: Análise do percentual de acerto no top 10 das configurações do Grupo I no
cenário agrupado.
55
perceber, novamente, com 2 métricas por meta, não há diferença entre nosso sistema de
recomendação e o outro. Por outro lado, ao aumentar o número de métricas por meta,
nosso sistema sempre possui um desempenho superior em relação ao sistema que
apenas ordena por utilização. Isso ocorre por conta do aumento do número de
recomendações, gerando uma grande quantidade de regras, melhorando nosso sistema.
Ainda, podemos perceber que o os resultados do Grupo II foram similares aos
obtidos no Grupo I, indicando que a quantidade de metas não influencia diretamente no
desempenho dos sistemas de recomendação.
Por outro lado, podemos perceber na Figura 9, que representa o resultado do
Grupo II no cenário aleatório, que com relação ao percentual de acerto da métrica
desejada no top 10, execto na configuração com 2 metas ou com 2 métricas por meta do
Grupo I, os resultados foram melhores no Grupo II, com algumas configurações
chegando ao valor de 23% de acerto no top 10.
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 8: Análise posição média da métrica nas configurações do Grupo II no cenário
aleatório.
56
Agora, podemos perceber que com o aumento do número de métricas por meta,
o percentual de acerto também aumenta, comportamento diferente do Grupo I. Isso
ocorre pois agora existe um número razoavel de recomendações em todas as
configurações, diferentemente do Grupo I, onde, com 2 métricas por meta, o número de
recomendações era muito baixo, gerando valores estranhos para o percentual de acerto
no top 10.
Por fim, com o teste estatístico de hipótese, podemos afirmar que em todas as
configurações, exceto as que possuem 2 métricas por meta, o desempenho do nosso
sistema de recomendação é superior ao do sistema que apenas ordena por utilização.
Para o cenário agrupado, os resultados do Grupo II são apresentados nas Figuras
10 e 11.
Como podemos perceber na Figura 10, novamente, com 2 métricas por meta a
diferença entre nosso sistema de recomendação e o sistema que apenas ordena por
utilização é bem pequena, entretanto, ela é maior que no Grupo I no cenário agrupado.
0%
5%
10%
15%
20%
25%P
erc
en
tual
de
ace
rto
no
to
p 1
0
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 9: Análise do percentual de acerto no top 10 das configurações do Grupo II no
cenário aleatório.
57
Outro importante ponto é o desempenho do sistema de recomendação que ordena por
utilização, podemos notar que o desempenho é bastante similar ao desempenho de
ambos os cenários do Grupo I e do cenário aleatório do Grupo II.
Por outro lado, o desempenho do nosso sistema de recomendação tem um ganho
bastante acentuado, sendo nosso sistema de recomendação bastante superior já com 5
métricas por meta. Isso ocorre pois agora, com um maior número de metas, são geradas
mais regras de associação, enquanto que o sistema que apenas ordena por utilização é
confundido, visto que existem várias métricas com utilização alta e que não possuem
associação entre elas.
Agora, analisando as informações sobre o percentual de acerto da métrica
desejada no top 10, podemos, na Figura 11, novamente perceber que o sistema de
recomendação que apenas ordena as métricas por utilização possui o mesmo
comportamento do cenário aleatório do Grupo II e de ambos os cenários do Grupo I.
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 10: Análise posição média da métrica nas configurações do Grupo II no cenário
agrupado.
58
Por outro lado, o nosso sistema de recomendação apresenta valores bastante
expressivos, sendo sempre bem superior em relação ao outro sistema de recomendação,
chegando a atingir quase 50% com 80 metas e 5 métricas por meta e aproximadamente
90% na configuração 80/80/20.
Por fim, com a utilização do teste estatístico de hipótese, podemos afirmar que
todas as configurações, exceto 20/80/2, 30/80/2, 50/80/2, nosso sistema de
recomendação possui um desempenho superior com relação ao outro.
Finalizando o experimento, vamos analisar o resultado da simulação feita com as
configurações do Grupo III. Inicialmente, para o cenário aleatório, podemos ver na
Figura 12 o resultado para a posição média da métrica desejada.
Como podemos perceber no gráfico, o comportamento do Grupo III no cenário
aleatório é bastante similar ao Grupo II no cenário aleatório, desde o ganho de
desempenho com o aumento do número de métricas por meta ao valor exato da posição
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%P
erc
en
tual
de
ace
rto
no
to
p 1
0
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 11: Análise do percentual de acerto no top 10 das configurações do Grupo II no
cenário agrupado.
59
média em cada configuração. Esse comportamento ocorreu para ambos os sistemas de
recomendação.
Ainda, analisando o gráfico da Figura 13 que representa o percentual de acerto
no top 10 nas configurações do Grupo III no cenário aleatório, novamente podemos
perceber valores e comportamentos similares ao do Grupo II no mesmo cenário.
Isso ocorre pois, para o cenário aleatório, a quantidade de metas, depois de um
certo valor, não influencia no desempenho de nenhum dos sistemas de recomendação.
Ainda, através do teste de hipótese, podemos afirmar que em todas as
configurações, exceto 100/80/2 e 200/80/2, nosso sistema de recomendação possui um
desempenho superior em relação ao sistema que apenas ordena as métricas por sua
utilização.
Por fim, vamos agora analisar os resultados da execuação da simulação para as
configurações do Grupo III no cenário agrupado, o resultado é apresentado nas Figuras
14 e 15.
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 12: Análise posição média da métrica nas configurações do Grupo III no cenário
aleatório.
60
Inicialmente, sobre a posição média da métrica desejada, podemos perceber no
gráfico da Figura 14 que o Grupo III possui um comportamento similar ao Grupo II,
onde, a cada aumento de metas e de métricas por meta, a diferença de desempenho entre
nosso sistema de recomendação e o que apenas ordena por utilização aumenta. Podemos
perceber que, com 5 métricas por meta, nosso sistema de recomendação tem um
desempenho 2 vezes superior ao do outro sistema de recomendação.
Esse comportamento é esperado, pois com o aumento do número de
recomendações, mais regras de associação são geradas, melhorando o desempenho do
nosso sistema de recomendação.
Agora, na Figura 15, sobre o percentual de acerto no top 10, podemos perceber o
mesmo comportamento da posição média da métrica, com o percentual aumentando a
medida que o número de metas e o número de métricas por meta aumenta, chegando a
quase 100% na configuração com 800 metas, 800 métricas e 20 métricas por meta.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%P
erc
en
tual
de
ace
rto
no
to
p 1
0
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 13: Análise do percentual de acerto no top 10 das configurações do Grupo III no
cenário aleatório.
61
Por fim, com o teste estatístico de hipótese, podemos afirmar que em todas as
configurações do Grupo III no cenário agrupado nosso sistema de recomendação possui
um desempenho superior ao sistema que apenas ordena as métricas por utilização.
0369
1215182124273033363942
Po
siçã
o m
éd
ia d
a m
étr
ica
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 15: Análise posição média da métrica nas configurações do Grupo III no cenário
agrupado.
0%
20%
40%
60%
80%
100%
120%
Pe
rce
ntu
al d
e a
cert
o n
o t
op
10
qtdeMetas / qtdeMetricas / qtdeMetricasMeta
Ordenação por Utilização Regras de Associação
Figura 14: Análise do percentual de acerto no top 10 das configurações do Grupo III no
cenário agrupado.
62
4.1.4. Análise dos Resultados
Como visto na seção anterior, o sistema de recomendação proposto foi superior
em todas as medições e em todos cenários em comparação com um sistema de
recomendação que utilize apenas a utilização das métricas como criterio para a
ordenação.
Apesar do cenário aleatório representar um ambiente bastante ruim para o nosso
sistema e bem distante da realidade, em todas as medições nosso sistema de
recomendação foi superior ao outro, seja em posição média da métrica ou em percentual
de posicionamento da métrica desejada nas 10 primeiras. No cenário agrupado, um
ambiente mais próximo do real é utilizado e, nesse caso, nosso sistema de
recomendação foi bastante superior em relação ao outro.
Em ambos os casos, nosso sistema de recomendação se comporta melhor a
medida que aumenta o número de recomendações realizadas, entretanto, esse
comportamento é melhor sinalizado no cenário agrupado. Isso ocorre pois, quanto maior
o número de regras de associação geradas, mais preciso pode ser nosso sistema de
recomendação.
Por fim, podemos concluir que com a utilização de nosso sistema de
recomendação para as métricas, o trabalho de associar as métricas à meta é facilitado,
visto que ele possui a menor posição média da métrica e o maior percentual de métricas
desejadas recomendadas entre as 10 primeiras da recomendação.
63
4.2. SIMULAÇÃO PARA RECOMENDAÇÃO DE REGRAS
Essa simulação foi realizada para responder a seguinte pergunta:
A regra com maior pontuação total é a regra de maior qualidade?
Para avaliar o resultado da simulação utilizamos 1 indicador:
Posição final da regra de maior qualidade.
Para realizar a simulação nós consideramos que os membros do comitê
estratégico de uma organização irão desenvolver regras de acompanhamento para um
BSC, e, cada regra possuirá um certo número de novas versões publicadas, que pode
melhorar ou não a qualidade da regra anterior.
As seções seguintes estão organizadas da seguinte forma: Inicialmente iremos
descrever o processo de simulação. Em seguida, os valores utilizados nas simulações
são descritos e, por fim, os resultados obtidos são discutidos.
4.2.1. Processo de Simulação
A simulação será divida em 2 etapas. Na primeira etapa, chamada de etapa I,
serão geradas as primeiras versões das regras de acompanhamento, em seguida, na
segunda etapa, chamada de etapa II, novas versões das regras previamente criadas são
geradas, a fim de descobrir se a regra de maior qualidade aparece entre as primeiras da
recomendação, cada regra gerada possui um fator de qualidade.
Sobre o fator de qualidade, ele é um número que é utilizado para indicar a
qualidade de cada regra gerada, ele é atribuído a regra de forma diferente de acordo com
a etapa da simulação.
64
Na etapa I, o fator de qualidade é atribuído de acordo com a seguinte
distribuição:
DU(80,100) – Um valor entre 80 e 100 caso a regra possua uma qualidade boa;
DU(40,79) – Um valor entre 40 e 79 caso a regra possua uma qualidade média; e
DU(0,39) – Um valor entre 0 e 39 caso a regra possua uma qualidade baixa.
Por outro lado, durante a etapa II, o fator de qualidade da nova versão de uma
regra pode ser acrescido ou decrescido de 5 do fator de qualidade da regra original, de
acordo com a seguinte distribuição empírica de probabilidade:
p(aumentar) – 0.2;
p(naoAlterar) – 0.6; e
p(diminuir) – 0.2;
Ainda, ao criar a nova versão de uma regra, cada regra existente possui uma
certa probabilidade de ser importada, essa probabilidade é baseada na relação entre a
pontuação da regra e a pontuação de todas as regras existentes, sendo a probabilidade
PUr a probabilidade de uma regra r ser importada descrita abaixo:
( )
Onde u é a quantidade de regras já importadas e Rr a relação entre a pontuação
da regra e a pontuação de todas as regras existentes, sendo definido por:
∑ | |
65
4.2.2. Execução da Simulação
Para executar a simulação, foram atribuídos diversos pesos diferentes aos pesos
de cada pontuação que participa da pontuação total de uma regra, esses valores são
apresentados na Tabela 4.
Ainda, consideramos que inicialmente existem 5 regras na base de dados, sendo
1 regra boa, 3 médias e 1 ruim.
Tabela 4. Configurações utilizadas na simulação
Configuração wi wn wu
A 0.3 0.6 0.1
B 0.3 0.1 0.6
C 0.6 0.3 0.1
D 0.6 0.1 0.3
E 0.1 0.3 0.6
F 0.1 0.6 0.3
4.2.3. Resultados
Nessa seção iremos apresentar os resultados obtidos com as diversas simulações,
na Figura 16 apresentamos o resultado obtido.
Como podemos perceber, as configurações A, B, E e F foram as que
posicionaram mais vezes a regra de melhor qualidade na primeira posição da
recomendação.
Ainda, podemos perceber que as configurações A e F são as que apresentam o
melhor resultado, e, ambas são as que possuem um maior peso para a pontuação de
66
influência, i.e., a configuração que favorece as regras que mais são utilizadas na criação
de novas regras propicia um melhor desempenho para nosso sistema de recomendação.
4.2.4. Análise dos Resultados
Como podemos perceber, com a utilização do nosso sistema de recomendação,
as regras de maior qualidade aparecem nas primeiras posições com uma maior
frequência, sendo essa frequência maior quando a pontuação de influência possui um
peso maior com relação as outras na composição da pontuação total da regra.
Devido a isso, podemos concluir que nosso sistema de recomendação promove a
reutilização das melhores regras.
0
10
20
30
40
50
60
A B C D E F
Qtd
e d
e v
êze
s e
m c
ada
po
siçã
o
Configuração
1
2
3
4
5
Figura 16: Quantidade de vêzes que a melhor regra aparece nas 5 primeiras posições em
cada configuração.
67
5. CONCLUSÃO
Esse capítulo apresenta as considerações finais, relembrando o problema,
mostrando a solução proposta juntamente com as contribuições.
Nos dias atuais, a nova economia baseada em conhecimento e alto dinamismo
dos processos exige com que as organizações sejam capazes de lidar com mudanças
constantes, sempre procurando melhorar as suas estratégias. Esse cenário demanda
novas abordagens para a gestão organizacional. Os princípios da Computação
Autonômica podem ser adaptados para ajudar as organizações a sobreviverem nesse
cenário. Então, aplicando a computação autonômica à gestão estratégica, tem-se um
paradigma onde a própria gestão estratégica é responsável por detectar e prever
problemas na execução da mesma.
Por outro lado, utlizando o BSC na gestão estratégica organizacional, são
geradas uma grande quantidade de metas, onde cada meta deve possuir suas próprias
métricas e regras de acompanhamento. Como metas diferentes podem possuir métricas e
regras de acompanhamento similares, seria interessante a reutilização do conhecimento
já existente na organização ao se definir novas métricas ou regras. Sistemas de
Recomendaçao podem ser adaptados para facilitar essa tarefa, bem como a Computação
Autonômica pode ser adaptada para o acompanhamento do desempenho das métricas.
Esse trabalho apresentou uma proposta de sistemas de recomendação para a
indicação de métricas e regras de acompanhamento para as metas de um BSC. Os
sistemas propostos consideram as utilizações anteriores das métricas e regras para
efetuar as recomendações, buscando assim padronizar suas utilizações por toda a
organização.
Para suportar esses sistemas de recomendação foi proposto o ECRAN. Esse
sistema possui meios para permitir aos membros do comitê estratégico criar / reutilizar
68
métricas e regras de acompanhamento durante a criação do planejamento estratégico de
uma organização.
Além do ECRAN, outros artefatos foram gerados como contribuição desse
trabalho: um sistema de recomendação de métricas para uma meta do BSC, um sistema
de recomendação de regras de acompanhamento para uma meta do BSC e a arquitetura
de um sistema para a edição colaborativa das regras, incluindo seus diagramas de
classes e diagramas de atividades dos principais processos da aplicação.
Sobre os sistemas de recomendação, podemos concluir que com a utilização de
nosso sistema de recomendação para métricas a tarefa de se associar métricas à meta é
facilitada e, com a utilização do sistema de recomendação para as regras de
acompanhamento, as regras também são melhor geradas e reaproveitadas.
Por fim, devido a isso, podemos concluir que a utilização dos sistemas de
recomendação propostos o desenvolvimento e acompanhamento do BSC da organização
é mais eficiente.
69
6. TRABALHOS FUTUROS
Como uma primeira proposta de trabalho futuro, seria necessário um estudo de
caso detalhado, em uma organização real, que possua uma estratégia complexa, para
assim conseguir dados de utilização da ferramente em um ambiente real e adverso.
Já está em andamento a integração do ECRAN com o TEAM, para que seja
possível a criação de regras autonômicas de mais alto nível, onde o resultado de uma
métrica possa gerar uma alteração em um processo da organização, de forma a não
apenas avisar que a meta não será atingida, mas também alterar o ambiente de forma a
facilitar o alcance da meta.
Uma outra possível evolução da ferramenta seria a inserção de um dashboard,
onde fosse possível visualizar, para uma determinada meta, o andamento de todas as
suas métricas.
Outra evolução seria no sistema de recomendação para as métricas, onde, dada
as nomenclaturas da seção 3.1, quando ocorrer o caso onde {AIm} => ∅ para a meta m,
o sistema invés de recomendar com base na utilização das métricas, utilize subconjuntos
de AIm, por exemplo, se a meta m possui 5 métricas associadas, o sistema buscaria as
regras existem gerando-se dentre as 5 métricas subconjuntos de 4, e assim por diante,
até que ele não ache nenhuma regra e volte a utilizar a utilização das métricas para a
recomendação das mesmas.
Ainda, sobre o sistema de recomendação para as métricas, podemos alterar a
geração das regras para a mesma utilizar de Lógica Fuzzy para tal, assim como proposto
em (KAYA et al., 2002).
70
REFERÊNCIAS BIBLIOGRÁFICAS
ADOMAVICIUS, G.; TUZHILIN, A. Toward the Next Generation of Recommender
Systems: A Survey of the State-of-the-art and Possible Extensions. IEEE
Transaction on Knowledge and Data Engineering, v. 17, n. 6, p. 734-749,
2005.
AGGARWAL, C. C.; YU, P. S. A New Framework for Itemset Generation.
Proceedings of the seventeenth ACM SIGACT-SIGMOD-SIGART
symposium on Principles of database systems, p.18–24. Seattle, Washington,
USA, 1998.
AGRAWAL, D.; CALO, S.; LEE, K.; LOBO, J.; VERMA, D. Policy Technologies for
Self-Managing Systems. 1o ed. IBM Press, 2008.
AGRAWAL, R.; IMIELINSKI, T.; SWAMI, A. Mining Association Rules between
Sets of Items in Large Databases. In Proceedings of the 1993 ACM SIGMOD
international conference on Management of data (SIGMOD ’93), p. 207-
216., 1993.
ALBANESE, M.; CHIANESE, A.; D’ ACIERNO, A.; MOSCATO, V.; PICARIELLO,
A. A multimedia recommender integrating object features and user behavior.
Multimedia Tools and Applications, v. 50, n. 3, p. 563-585., 2010.
ATKINSON, H. Strategy implementation: a role for the balanced scorecard?
Management Decision, v. 44, n. 10, p. 1441-1460., 2006.
BABAOĞLU, Ö. Self-star properties in complex information systems: conceptual
and practical foundations. Springer, 2005.
BAEZA-YATES, R.; RIBEIRO-NETO, B. Modern information retrieval. ACM press
New York, 1999.
BALABANOVIĆ, M.; SHOHAM, Y. Fab: Content-Based, Collaborative
Recommendation. Commun. ACM, v. 40, n. 3, p. 66-72., 1997.
BELKIN, N. J.; CROFT, W. B. Information Filtering and Information Retrieval: Two
Sides of the Same Coin? Communications of the ACM, v. 35, n. 12, p. 29-38.,
1992.
BERGLUND, A.; BJURLING, B.; DANTAS, R.; ENGBERG, S.; GIAMBIAGI, P.;
OHLMAN, B. Toward Goal-Based Autonomic Networking. GLOBECOM
Workshops, 2008 IEEE, p.1-5., 2008.
71
BI, Y.; ANDERSON, T.; MCCLEAN, S. A rough set model with ontologies for
discovering maximal association rules in document collections. Knowledge-
Based Systems, v. 16, n. 5-6, p. 243-251., 2003.
BOLEY, H.; KIFER, M.; PĂTRÂNJAN, P.-L.; POLLERES, A. Rule Interchange on
the Web. In: G. Antoniou; U. Aßmann; C. Baroglio; S. Decker; N. Henze; P.-L.
Patranjan; R. Tolksdorf (Orgs.); Reasoning Web v. 4636, p.269-309. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2007.
BREESE, J. S.; HECKERMAN, D.; KADIE, C. Empirical Analysis of Predictive
Algorithms for Collaborative Filtering. Proceedings of the 14th conference on
Uncertainty in Artificial Intelligence, p.43–52., 1998.
BRIN, S.; MOTWANI, R.; SILVERSTEIN, C. Beyond Market Baskets: Generalizing
Association Rules to Correlations. Proceedings of the 1997 ACM SIGMOD
international conference on Management of data, p.265–276. Tucson,
Arizona, United States: ACM, 1997.
BRIN, S.; MOTWANI, R.; ULLMAN, J. D.; TSUR, S. Dynamic Itemset Counting and
Implication Rules for Market Basket Data. Proceedings of the 1997 ACM
SIGMOD international conference on Management of data, , SIGMOD ’97.
p.255–264. Tucson, Arizona, United States: ACM, 1997.
CASATI, F.; CERI, S.; PARABOSCHI, S.; POZZI, G. Specification and
Implementation of Exceptions in Workflow Management Systems. ACM
Transactions on Database Systems, v. 24, p. 405-451., 1999.
CHANDRA, A.; GONG, W.; SHENOY, P. Dynamic Resource Allocation for Shared
Data Centers Using Online Measurements. Proceedings of the 2003 ACM
SIGMETRICS international conference on Measurement and modeling of
computer systems, p.300-301., 2003.
CHASE, J. S.; ANDERSON, D. C.; THAKAR, P. N.; VAHDAT, A. M.; DOYLE, R. P.
Managing Energy and Server Resources in Hosting Centers. Proceedings of the
eighteenth ACM symposium on Operating systems principles, p.103–116.,
2001.
CLARK, D. D.; PARTRIDGE, C.; RAMMING, J. C.; WROCLAWSKI, J. T. A
Knowledge Plane for the Internet. Proceedings of the 2003 conference on
Applications, technologies, architectures, and protocols for computer
communications - SIGCOMM ’03, p.3-10. Karlsruhe, Germany, 2003.
DMTF. CIM Query Language. ,2006a.
72
DMTF. CIM Simplified Policy Language (CIM-SPL). Version 1.4.5 edition. ,2006b.
DMTF. CIM - Common Information Model - Versão 2.29.1. 2011. Disponível em:
http://dmtf.org/standards/cim. Acesso em: 8 set 2011.
DOBSON, S.; STERRITT, R.; NIXON, P.; HINCHEY, M. Fulfilling the Vision of
Autonomic Computing. Computer, v. 43, n. 1, p. 35-41., 2010.
EFSTRATIOU, C.; FRIDAY, A.; DAVIES, N.; CHEVERST, K. Utilising the Event
Calculus for Policy Driven Adaptation on Mobile Systems. Policies for
Distributed Systems and Networks, 2002. Proceedings. Third International
Workshop on, p.13-24., 2002.
EKSTROM, M.; GARCIA, A. C. .; BJORNSSON, H. Rewarding Honest Ratings
Through Personalised Recommendations in Electronic Commerce.
International journal of electronic business, v. 3, n. 3, p. 392–410., 2005.
EVANS, J. R. An Exploratory Study of Performance Measurement Systems and
Relationships with Performance Results. Journal of Operations Management,
v. 22, n. 3, p. 219-232., 2004.
GARCIA, A. C. B.; CIUFFO, L. N. Applying the HYRIWYG Incentive Mechanism in
a Recommender System. Web Intelligence, IEEE / WIC / ACM International
Conference on, v. 0, p.770-773. Los Alamitos, CA, USA: IEEE Computer
Society, 2005.
GARCIA, A. C. B.; EKSTROM, M.; BJ\ÖRNSSON, H. HYRIWYG: Leveraging
Personalization to Elicit Honest Recommendations. Proceedings of the 5th
ACM conference on Electronic commerce, p.232–233., 2004.
HAN, E.-H.; KARYPIS, G. Feature-based Recommendation System. Proceedings of
the 14th ACM international conference on Information and knowledge
management, p.446–452. Bremen, Germany: ACM, 2005.
HAN, J.; KAMBER, M.; PEI, J. Data Mining: Concepts and Techniques, Third
Edition. 3o ed. Morgan Kaufmann, 2011.
HARIRI, S.; KHARGHARIA, B.; CHEN, H.; YANG, J.; ZHANG, Y.; PARASHAR,
M.; LIU, H. The Autonomic Computing Paradigm. Cluster Computing, v. 9, n.
1, p. 5-17., 2006.
HORN, P. Autonomic Computing. IBM Manifesto, 2001.
HU, Y.-J.; YEH, C.-L.; LAUN, W. Challenges for Rule Systems on the Web. Rule
Interchange and Applications v. 5858, p.4-16. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2009.
73
HUEBSCHER, M. C.; MCCANN, J. A. A Survey of Autonomic Computing-Degrees,
Models and Applications. ACM Comput. Surv., v. 40, n. 3, p. 1-28., 2008.
IBM. An Introduction to Policy for Autonomic Computing. ,2005.
ITTNER, C. D.; LARCKER, D. F. Coming Up Short on Nonfinancial Performance
Measurement. Harvard Business Review, v. 81, n. 11, p. 88–95., 2003.
JAVA.NET. JavaServer Faces Community — Java.net. 2006. Disponível em:
http://javaserverfaces.java.net/. Acesso em: 10 set 2011.
KAPLAN, R. S.; NORTON, D. P. The Balanced Scorecard–Measures that Drive
Performance. Harvard business review, v. 70, n. 1, p. 71–79., 1992.
KAPLAN, R. S.; NORTON, D. P. The Balanced Scorecard: Translating Strategy
into Action. 1o ed. Harvard Business Press, 1996.
KAPLAN, R. S.; NORTON, D. P. Strategy Maps: Converting Intangible Assets into
Tangible Outcomes. Harvard Business Press, 2004.
KAYA, M.; ALHAJJ, R.; POLAT, F.; ARSLAN, A. Efficient Automated Mining of
Fuzzy Association Rules. In: A. Hameurlain; R. Cicchetti; R. Traunmüller
(Orgs.); Database and Expert Systems Applications v. 2453, p.133-142.
Berlin, Heidelberg: Springer Berlin Heidelberg, 2002.
KEPHART, J. O. Research Challenges of Autonomic Computing. Proceedings of the
27th international conference on Software engineering, p.15-22. St. Louis,
MO, USA: ACM, 2005.
KEPHART, J. O. Autonomic Computing: The First Decade. Proceedings of the 8th
ACM international conference on Autonomic computing - ICAC ’11, p.1.
Karlsruhe, Germany, 2011.
KEPHART, J. O.; CHESS, D. M. The Vision of Autonomic Computing. Computer, v.
36, n. 1, p. 41-50., 2003.
KEPHART, J. O.; WALSH, W. E. An Artificial Intelligence Perspective on Autonomic
Computing Policies. Policies for Distributed Systems and Networks, 2004.
POLICY 2004. Proceedings. Fifth IEEE International Workshop on, p.3-
12., 2004.
KIFER, M. Rule Interchange Format: The Framework. Rule Representation,
Interchange and Reasoning on the Web v. 5321, p.1-2. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2008.
74
KIM, Y. S.; YUM, B.-J. Recommender System Based on Click Stream Data Using
Association Rule Mining. Expert Systems with Applications, v. 38, n. 10, p.
13320-13327., 2011.
KOURIS, I. N.; MAKRIS, C. H.; TSAKALIDIS, A. K. Using Information Retrieval
Techniques for Supporting Data Mining. Data & Knowledge Engineering, v.
52, n. 3, p. 353-383., 2005.
LAW, A.; KELTON, W. D. Simulation Modeling and Analysis. 3o ed. McGraw-Hill
Science/Engineering/Math, 1999.
LIN, W.; ALVAREZ, S. A.; RUIZ, C. Efficient Adaptive-Support Association Rule
Mining for Recommender Systems. Data Mining and Knowledge Discovery,
v. 6, n. 1, p. 83–105., 2002.
LOBO, J.; BHATIA, R.; NAQVI, S. A Policy Description Language. Proceedings of
the National Conference on Artificial Inteligence, p.291–298., 1999.
LUTFIYYA, H.; MOLENKAMP, G.; KATCHABAW, M.; BAUER, M. Issues in
Managing Soft QoS Requirements in Distributed Systems Using a Policy-Based
Framework. Policies for Distributed Systems and Networks, p. 185–201.,
2001.
LYMBEROPOULOS, L.; LUPU, E.; SLOMAN, M. An Adaptive Policy Based
Management Framework for Differentiated Services Networks. Policies for
Distributed Systems and Networks, 2002. Proceedings. Third International
Workshop on, p.147-158., 2002.
MARTINEZ-ROMO, J.; ARAUJO, L. Updating Broken Web Links: An Automatic
Recommendation System. Information Processing & Management, v. In
Press, Corrected Proof., 2011.
MELHORAMENTOS. Dicionário Michaelis. Melhoramentos, 2009.
MELVILLE, P.; MOONEY, R. J.; NAGARAJAN, R. Content-Boosted Collaborative
Filtering for Improved Recommendations. Proceedings of the National
Conference on Artificial Intelligence, p.187–192., 2002.
METROPOLIS, N.; ULAM, S. The Monte Carlo Method. Journal of the American
Statistical Association, v. 44, n. 247, p. 335-341., 1949.
MONTEIRO JR, P. C.; RODRIGUES NT, J. A.; OLIVEIRA, J.; SOUZA, J. M. ABPM:
Autonomic Business Process Manager. LAACS 2008, ,2008.
MOORE, B. Policy Core Information Model (PCIM) Extensions (RFC3460). ,2003.
75
MOORE, B.; ELLESSON, E.; STRASSNER, J.; WESTERINEN, A. Policy Core
Information Model -- Version 1 Specification. ,2001.
MOSES, T. Extensible Access Control Markup Language (XACML) version 2.0. Oasis
Standard, v. 200502., 2005.
MURCH, R. Autonomic Computing. IBM Press, 2004.
NAMI, M. R.; BERTELS, K. A Survey of Autonomic Computing Systems. Autonomic
and Autonomous Systems, 2007. ICAS07. Third International Conference
on, p.26., 2007.
NEELY, A.; BOURNE, M. Why Measurement Initiatives Fail. Measuring Business
Excellence, v. 4, n. 4, p. 3-7., 2000.
NICHOLAS, I. S. C.; NICHOLAS, C. K. Combining Content and Collaboration in Text
Filtering. In Proceedings of the IJCAI’99 Workshop on Machine Learning
for Information Filtering, p. 86-91., 1999.
NIVEN, P. R. Balanced Scorecard Step By Step: Maximizing Performance and
Maintaining Results. John Wiley and Sons, 2002.
OMG. Production Rule Representation (PRR) Version 1.0. 2009. Disponível em:
http://www.omg.org/spec/PRR/1.0/. Acesso em: 8 set 2011.
ORACLE. Java 1.5. 2004. Disponível em:
http://www.oracle.com/technetwork/java/javase/downloads/index-jdk5-jsp-
142662.html. Acesso em: 10 set 2011.
ORACLE. EJB, Enterprise Java Beans. 2008a. Disponível em:
http://www.oracle.com/technetwork/java/docs-135218.html. Acesso em: 10 set
2011.
ORACLE. MySQL :: Download MySQL Community Server. 2008b. Disponível em:
http://dev.mysql.com/downloads/mysql/5.1.html. Acesso em: 10 set 2011.
PARASHAR, M.; HARIRI, S. Autonomic Computing: Concepts, Infrastructure,
and Applications. CRC Press, 2006.
PAZZANI, M. J. A Framework for Collaborative, Content-Based and Demographic
Filtering. Artificial Intelligence Review, v. 13, n. 5, p. 393–408., 1999.
PAZZANI, MICHAEL J.; BILLSUS, D. Content-Based Recommendation Systems.
The Adaptive Web v. 4321, p.325-341. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2007.
76
PIATETSKY-SHAPIRO, G. Discovery, Analysis, and Presentation of Strong Rules.
Knowledge Discovery in Databases AAAI/MIT Press, 1991.
PINHEIRO, W. A.; SILVA, M.; BARROS, R.; XEXEO, G.; SOUZA, J. Autonomic
Collaborative RSS: An Implementation of Autonomic Data Using Data Killing
Patterns. 13th International Conference on Computer Supported
Cooperative Work in Design, 2009. CSCWD 2009, p.492-497. IEEE, 2009.
PONNAPPAN, A.; YANG, L.; PILLAI, R.; BRAUN, P. A Policy Based QoS
Management System for the IntServ/DiffServ Based Internet. Policies for
Distributed Systems and Networks, 2002. Proceedings. Third International
Workshop on, p.159-168., 2002.
PORTER, M. E. Strategy and the Internet. Harvard business review, v. 79, n. 3, p. 62–
79., 2001.
REDHAT. JBoss Application Server Downloads - JBoss Community. 2009. Disponível
em: http://www.jboss.org/jbossas/downloads/. Acesso em: 10 set 2011.
ROBILLARD, M.; WALKER, R.; ZIMMERMANN, T. Recommendation Systems for
Software Engineering. IEEE Software, v. 27, n. 4, p. 80-86., 2010.
RODRIGUES NT, J.A.; MONTEIRO JR, P. C. L.; OLIVERIA, J.; SOUZA, J.M.;
ZIMBRÃO, G. Towards an Autonomic Enterprise: From Autonomic Business
Processes to Autonomic Balanced Scorecard. WBPM 2007, Gramado, Brasil,
2007.
RODRIGUES NT, J. A.; SOUZA, J. M.; ZIMBRÃO, G.; XEXEO, G. B.; MIRANDA,
M. Business Process Reuse and Standardization with P2P Technologies.
Handbook of Research on Virtual Workplaces and the New Nature of
Business Practices p.516-529. IGI Global, 2008.
SALTON, G. Automatic text processing. Addison-Wesley Longman Publishing Co.,
Inc. Boston, MA, USA, p. 450., 1988.
SANDVIG, J. J.; MOBASHER, B.; BURKE, R. Robustness of Collaborative
Recommendation Based on Association Rule Mining. Proceedings of the 2007
ACM conference on Recommender systems, , RecSys ’07. p.105–112.
Minneapolis, MN, USA: ACM, 2007.
SHAHABI, C.; CHEN, Y.-SHIN; BENATALLAH, R. B. An Adaptive
Recommendation System without Explicit Acquisition of User Relevance
Feedback. Distributed and Parallel Databases, v. 14, p. 173--192., 2003.
77
SHAW, G.; XU, Y.; GEVA, S. Investigating the use of Association Rules in Improving
Recommender systems. Proc. of ADCS’09, p. 106-109., 2009.
SILVA, R. T.; SAMPAIO, J. O.; SOUZA, J. M. Enabling Knowledge Flow on Social
Networks Through Autonomic Computing. 12th International Symposium on
the Management of Industrial and Corporate Knowledge - ISMICK, ,2008.
SU, X.; GREINER, R.; KHOSHGOFTAAR, T. M.; ZHU, X. Hybrid Collaborative
Filtering Algorithms Using a Mixture of Experts. Proceedings of the
IEEE/WIC/ACM International Conference on Web Intelligence, p.645–649.
Washington, DC, USA: IEEE Computer Society, 2007.
TAM, K. Y.; HO, S. Y. Web Personalization as a Persuasion Strategy: An Elaboration
Likelihood Model Perspective. Info. Sys. Research, v. 16, n. 3, p. 271–291.,
2005.
TANG, K.; CHEN, Y.-L.; HU, H.-W. Context-Based Market Basket Analysis in a
Multiple-Store Environment. Decision Support Systems, v. 45, n. 1, p. 150-
163., 2008.
TOMAZ, L. F. .; RODRIGUES NT, J. A; SOUZA, J. M; XEXEO, G. B. Bringing
Knowledge into Recommendation Systems. 2011 15th International
Conference on Computer Supported Cooperative Work in Design
(CSCWD), p.246-252. IEEE, 2011.
TOMAZ, L. F. .; RODRIGUES, J. A.; XEXEO, G. B.; SOUZA, J. M. Collaborative
Process Modeling and Reuse Evaluation. 5th International Conference on
Collaborative Computing: Networking, Applications and Worksharing,
2009. CollaborateCom 2009, p.1-9. IEEE, 2009.
TORRES, R.; MCNEE, S. M.; ABEL, M.; KONSTAN, J. A.; RIEDL, J. Enhancing
Digital Libraries with TechLens+. Proceedings of the 4th ACM/IEEE-CS
joint conference on Digital libraries, p.228–236. New York, NY, USA: ACM,
2004.
VIVACQUA, A. S.; RODRIGUES NT, JOSE A.; MACHADO, M.; PADULA, R.;
PAES, M.; BARROS, P.; XEXEO, GERALDO; SOUZA, JANO M. DE;
MIRANDA, MUTALECI. Community-Supported Collaborative Navigation
with FoxPeer. International Journal of Web Based Communities, v. 5, n. 1, p.
126 - 138., 2009.
78
WAAL, A. A. Successful Performance Management? Apply the Strategic Performance
Management Development Cycle! Measuring Business Excellence, v. 11, n. 2,
p. 4-11., 2007.
WACKERLY, D.; MENDENHALL, W.; SCHEAFFER, R. L. Mathematical Statistics
with Applications. 7o ed. Duxbury Press, 2007.
WAGNER, C. Enterprise Strategy Management Systems: Current and Next Generation.
The Journal of Strategic Information Systems, v. 13, n. 2, p. 105-128., 2004.
WALSH, W. E.; TESAURO, G.; KEPHART, J. O.; DAS, R. Utility Functions in
Autonomic Systems. First International Conference on Autonomic
Computing (ICAC’04), p.70-77., 2004.
WANG, S.; XUAN, D.; BETTATI, R.; ZHAO, W. Providing Absolute Differentiated
Services for Real-Time Applications in Static-Priority Scheduling Networks.
INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE
Computer and Communications Societies. Proceedings. IEEE, v. 2, p. 669-
678., 2001.
WOOLDRIDGE, M.; JENNINGS, N. R. Intelligent Agents: Theory and Practice. The
Knowledge Engineering Review, v. 10, n. 02, p. 115-152., 1995.
YOON, J.; BETTATI, R. A Three-Pass Establishment Protocol for Real-Time
Multiparty Communication. Citeseer, 1996.
ZHANG, Z.-K.; LÜ, L.; LIU, J.-G.; ZHOU, T. Empirical Analysis on a Keyword-Based
Semantic System. The European Physical Journal B, v. 66, n. 4, p. 557-561.,
2008.
ZHAO, Z.; GAO, C.; DUAN, F. A Survey on Autonomic Computing Research.
Computational Intelligence and Industrial Applications, 2009. PACIIA
2009. Asia-Pacific Conference on, v. 2, p.288-291., 2009.
79
APÊNDICE A. EDITOR COLABORATIVO DE REGRAS AUTONÔMICAS DE NEGÓCIO
O ECRAN é uma ferramenta Web de apoio a gestão estratégica de uma
organização, provendo meios de facilitar a associação de métricas às metas do BSC da
mesma e de criar regras de acompanhamento para as métricas da meta. O ECRAN
também possui meios para realizar a validação das regras de acompanhamento,
possuindo uma interface para a descrição completa de uma métrica, incluindo a forma
da mesma ser extraída do sistema legado da organização, e um sistema para extração
das medidas referentes às métricas dos sistemas legados.
Nesse capítulo será descrito o desenvolvimento do ECRAN. Primeiro será
explicado todo o projeto de concepção do ECRAN, i.e., sua arquitetura, seu modelo de
dados e sua proposta de funcionamento. Por fim serão descritas todas as suas
funcionalidades e interfaces com o usuário.
A.I. ARQUITETURA
O ECRAN faz parte de um projeto maior, chamado TEAM (conforme explicado
na seção 1.7), cuja arquitetura pode ser vista na Figura 17. O ECRAN tem sua camada
Web fazendo parte do ABSC Controller, e seu “core” fazendo parte do ABSC Console
dentro do ABSC Engine, e sua arquitetura é apresentada na Figura 18.
Como pode se perceber o ECRAN é um sistema divido em 2 camadas, uma Web
que contém toda a interface com o usuário e outra, chamada “core” que é responsável
pelo armazenamento dos dados e pelo versionamento das regras. Em seguida, iremos
descrever qual o papel de cada elemento da arquitetura.
80
1. Editor de Métricas – É o responsável por prover as funcionalidades para a
descrição de métricas. É através dele que o usuário irá criar novas métricas e
associá-las à meta que está sendo trabalhada. Por fim, também é o
responsável por sugerir as métricas para a escolha do usuário.
2. Visualizador de Métricas – É o responsável por prover as funcionalidades
para a visualização das métricas existentes. É necessário para o usuário,
antes de associar uma métrica existente à meta, visualizar seus atributos e
decidir corretamente pela associação.
3. Editor de Regras Autonômicas – É o responsável por prover as
funcionalidades para a descrição de regras autonômicas de acompanhamento
das metas. É através dele que o usuário irá criar novas regras ou escolher
regras existentes sugeridas pelo sistema.
Figura 17: Team
81
4. Visualizador de Regras Autonômicas – É o responsável por prover as
funcionalidades para a visualização das regras autonômicas de
acompanhamento existentes. É necessário para o usuário, antes de utilizar
uma regra, visualizar seus atributos e decidir corretamente pela utilização.
5. Recomendador – É o responsável por gerar a recomendação das métricas e
regras para a camada Web.
Figura 18: Arquitetura ECRAN
82
6. Versionador – É o responsável pelas funcionalidades de versionamento das
regras autonômicas.
7. Pontuador - É o responsável por manipular as pontuações de cada regra.
Esse elemento que é o responsável por aplicar o algoritmo de ranking às
regras, definindo a pontuação de cada uma.
8. ETL – É o responsável por armazenar como cada métrica deve ser extraída
da base de dados legada. Também é o responsável por realizar a extração dos
dados referentes às métricas de tempos em tempos.
A.II. DIAGRAMA DE CLASSES DO ECRAN
Nessa seção será apresentado o diagrama de classes do ECRAN, ele está descrito
na Figura 19. Esse diagrama de classe não é somente aplicável ao TEAM. Pode também
ser aplicado a qualquer sistema que necessite de recomendação de regras autonômicas e
suas métricas, bastando para tal adaptar as associações existentes entre Métricas e Meta,
caracterizando assim mais uma contribuição deste trabalho.
Inicialmente, vale ressaltar que esse modelo foi extraído do modelo de um
sistema maior, o TEAM, e que existem simplificações nele. A classe “Meta” é um
exemplo, pois ela deve estar ligada a um BSC, mas essa classe não foi representada
nesse modelo.
83
Voltando a classe “Meta”, ela representa as metas do BSC de uma organização,
uma meta pode possuir várias métricas e regras de acompanhamento. A classe
“Metrica” reprensenta as métricas de uma meta e a classe “RegraAutonomica”
representa as regras de acompanhamento.
Sobre uma métrica, podemos destacar que além de possuir um nome e uma
descrição, ela possui a indicação da periodicidade de avaliação e de quantos períodos
devem ser respeitados entre as avaliações. A periodicidade de avaliação possui um
Figura 19: Diagrama de Classes do core do ECRAN
84
conjunto fixo de valores, que podem ser: a cada minuto, a cada hora, a cada dia, a cada.
Por fim, toda métrica possui um conjunto de medicões, que no modelo é representado
pela associação com a classe “Medicao”.
Voltando a meta, como as regras de acompanhamento possuem prioridades
diferentes, i.e., deve ser respeitada uma certa ordem para a validação das regras,e, como
uma mesma regra pode ser utilizada em diferentes metas, se faz necessária a formação
de uma classe de associação para representar a ligação entre metas e regras, essa classe
é representada por “MetaRegraAutonomica”.
Voltando a regra, como a mesma é uma regra autonômica, ela deve possuir uma
dimensão autonômica, que é representada pela classe “DimensaoAutonomica”, que
indica em quais as dimensões autonômicas (auto-cura, auto-proteção, auto-configuração
ou auto-otimização) a regra autonômica está inserida. Ainda, uma regra autonômica
possui várias ações, que são representadas pela classe “AcaoAutonomica”. Uma ação,
além de possuir um nome e uma descrição, possui um tipo e um parâmetro. O atributo
tipo indica o tipo da ação, i.e., se é envio de email, alteração de regra, e assim por
diante, por outro lado, o atributo parâmetro indica os parâmetros que devem ser
passados para a ação, por exemplo, no caso da ação ser um envio de email, o
parâmnetro seria o endereço de email que deve receber a mensagem.
Ainda sobre a regra autonômica, uma regra possui uma condição, representada
pela classe “Condicao” que irá verificar se a regra continua válida ou não. Caso a regra
fique inválida, as ações associadas a regra são invocadas.
Uma condição possui uma expressão, que é representada pela classe
“Expressao”. Uma expressão pode ser uma expressão composta que é representada pela
classe “ExpressaoComposta” ou uma cláusula que é representada pela classe
“Clausula”.
85
Uma expressão composta é utilizada para o caso de uma expressão ser
representada por um conjunto de expressões, ela é associada a um operador lógico que é
representado pela classe “OperadorLogico” e, pode conter os seguintes valores: AND,
OR ou XOR. Devido ao fato do operador lógico ser um operador binário, a classe
“ExpressaoComposta” também agrega duas expressões, a parte esquerda e a parte
direita da expressão composta. Dessa forma é possível formar a expressão “Expressao1
OperadorLogico Expressao2”.
A cláusula é utilizada para o caso de uma expressão ser representada por uma
expressão simples, i.e., um operador e dois operandos. O operador é representado pela
classe “OperadorNumerico” e pode conter os seguintes valores: > (maior), < (menor),
>= (maior ou igual), <= (menor ou igual), = (igual) ou <> (diferente). Devido ao fato
dos operadores numéricos escolhidos também serem binários, uma cláusula é composta
de dois operandos, a parte esquerda e a parte direita da cláusula, possibilitando a
formação da cláusula “Operando1 OperadorNumerico Operando2”.
Por fim, um operando pode ser uma métrica, um valor ou um texto, para
representar isso existe a classe “Operando”, que é uma generalização da métrica (classe
“Metrica”, de “Numero” e “Texto”. Foram criadas essas diversas especializações para
uma maior flexibilidade na especificação da regra autonômica.
A.III. FUNCIONAMENTO
O ECRAN foi projetado para apoiar os membros do comitê estratégico de uma
organização na tarefa de indicar métricas para as metas do BSC e na criação de regras
de acompanhamento para as mesmas. Seu processo básico de funcionamento possui 2
funcionalidades distintas.
86
Para apoiar a associação de métricas à metas, o ECRAN provê um sistema de
recomendação capaz de recomendar métricas para o usuário associar à meta.
Inicialmente o sistema recomenda as métricas mais utilizadas, em, seguida, de acordo
com as métricas escolhidas pelo usuário, o sistema recomenda as métricas que mais
foram utilizadas em conjunto com as métricas previamente selecionadas pelo usuário.
Esse processo está descrito na Figura 6 e será detalhado na seção 4.3.1.
Por outro lado, após associar as métricas à meta, o sistema é capaz de
recomendar as regras autonômicas de acompanhamento das métricas. Se o usuário optar
por desenvolver uma nova regra, o sistema provê uma interface amigável e intuitiva
para tal. Esse processo está descrito na Figura 7 e será detalhado na seção 4.3.2.
A.III.i. Associação de Métricas à Meta
Nessa seção será descrito o processo referente a associação de métricas à meta,
processo que está descrito na Figura 20.
Inicialmente, o usuário deve acessar o ECRAN e indicar a meta para a qual
deseja associar métricas e, em seguida, acessar a tela de associação de métricas.
Ao acessar a tela, o sistema irá listar todas as métricas existentes, ordenadas de
acordo com o sistema de recomendação descrito em 3.1. Nesse momento o usuário pode
optar por escolher uma métrica existente ou criar uma nova métrica. Se o usuário optar
por criar uma nova métrica, ele deve preencher os dados da métrica e, em seguida, o
ECRAN irá inserir a nova métrica no banco de dados da aplicação. Após esse passo, a
métrica é associada à meta.
Após essa escolha inicial, o usuário deve decidir se irá escolher novas métricas
ou não. Caso ele decida escolher novas métricas, o sistema irá listar todas as métricas
87
existentes, exceto as já escolhidas, ordenadas de acordo com o sistema de recomendação
descrito em 3.1. Durante o processo de escolha de métricas, a qualquer momento o
usuário pode optar por inserir uma nova métrica.
A qualquer momento durante a escolha das métricas, o usuário pode optar por
remover uma métrica escolhida de sua lista de métricas selecionadas. Caso isso ocorra,
a métrica é desassociada da meta e o sistema irá listar todas as métricas existentes,
exceto as já escolhidas, ordenadas de acordo com o sistema de recomendação descrito
em 3.1.
Por fim, a qualquer momento, após escolher as métricas que irão avaliar a meta,
o sistema marca as métricas selecionadas como utilizadas, i.e., a utilização de cada
métrica é incrementada de 1 e o processo é encerrado. Agora, o usuário pode optar por
indicar as métricas para as outras metas de seu BSC ou por indicar as regras de
acompanhamento das metas que já possuem métricas associadas.
88
Figura 20: Processo referente a associação de métricas à meta
89
A.III.ii. Associação de Regras de Acompanhamento à Meta
Nessa seção será descrito o processo referente a associação de regras de
acompanhamento à meta, processo que está descrito na Figura 21.
Inicialmente, o usuário deve acessar o ECRAN e indicar a meta para a qual
deseja associar regras de acompanhamento e, em seguida, acessar a tela de associação
de regras.
Ao acessar a tela, o sistema irá listar todas as regras existentes que utilize ao
menos uma das métricas associadas a meta. Essa recomendação é realizada com base no
sistema de recomendação descrito em 3.2. Vale lembrar que regras que utilizem
métricas que não estão no conjunto de métricas associadas à meta não serão
recomendadas. Nesse momento o usuário pode optar por visualizar uma regra, escolher
uma regra ou por criar uma nova regra.
Se o usuário optar por criar uma nova regra ele deve preencher os dados da
regra, como sua condição e sua ação e indicar se a regra é baseada em alguma outra
regra existente. Após isso, o ECRAN salva a nova regra no banco de dados, pontua as
regras nas quais a nova regra foi baseada a associa a nova regra à meta. Caso o usuário
opte por escolher uma regra recomendada, o sistema associa a regra à meta.
Após essa escolha inicial o usuário deve decidir se irá continuar indicando regras
de acompanhamento para a meta ou não. Caso ele decida continuar escolhendo regras, o
sistema irá listar as regras existentes de acordo com o sistema de recomendação descrito
em 3.2. Durante o processo de escolha de regras de acompanhamento, a qualquer
momento o usuário pode optar por inserir uma nova regra.
Por outro lado, a qualquer momento durante a escolha das regras de
acompanhamento, o usuário pode optar por remover uma regra escolhida de sua lista de
regras selecionadas. Caso isso ocorra, a regra é desassociada da meta e o sistema irá
90
listar todas as regras existentes, exceto as já escolhidas, ordenadas de acordo com o
sistema de recomendação descrito em 3.2.
Por fim, após escolher as regras que irão acompanhar o desempenho da meta, o
sistema pontua as regras utilizadas de acordo com o sistema de recomendação descrito
em 3.2 e o processo é encerrado.
91
Figura 21: Processo referente a associação de regras de acompanhamento à meta
92
A.IV. IMPLEMENTAÇÃO DO ECRAN
Nessa seção iremos descrever como o ECRAN foi implementado. Primeiro
iremos descrever as tecnologias utilizadas em cada camada de sua arquitetura. Em
seguida, iremos descrever detalhadamente a implementação de cada processo da
aplicação, iniciando pelo processo de associação de métricas à meta e finalizando com o
processo de indicação de regras de acompanhamento para as metas do BSC.
A.IV.i. Tecnologias Utilizadas
O ECRAN foi totalmente desenvolvido como uma aplicação Web em uma
arquitetura MVC, podendo ser acessado de qualquer lugar através da Internet.
Para a implementação foi utilizada a linguagem de programação Java, na versão
1.5 (ORACLE, 2004). Para a impementação da camada Web foi utilizado o JSF (Java
Server Faces), na versão 1.2 (JAVA.NET, 2006). Para a implementação da camada
CORE foi utilizado o EJB (Enterprise Java Beans) na versão 3.0 (ORACLE, 2008a).
Para o banco de dados, foi utilizado o MySql, na versão 5.1 (ORACLE, 2008b). A
aplicação foi feita para se utilizada em conjunto com qualquer servidor de aplicação.
Nós utilizamos o JBoss na versão 5.1 (REDHAT, 2009).
A.IV.ii. Processo Associação de Métricas à Meta
Nessa seção iremos descrever detalhadamente a implementação de todas as telas
do processo de associação de métricas à meta descrito na Figura 20.
93
Inicialmente o usuário deve acessar a tela de onde deve escolher a meta em que
deseja trabalhar, essa tela está representada na Figura 22. Nessa tela existe uma árvore
onde a raiz da mesma é o nome do planejamento estratégico da organização, no caso,
“GPE – ScrumHalf – Ano 2 SH”. Como filhas da raiz aparecem as pespectivas do BSC
e, dentro de cada perspectiva, são apresentadas as metas existentes. Dentro de cada meta
são listadas as métricas já associadas à meta. Para escolher uma meta basta clicar sobre
o nome da mesma.
Após a escolha da meta, é apresentada a tela para associação de métricas à meta,
essa tela é apresentada na Figura 23. Essa é a principal tela desse processo, pois é a tela
que associa as métricas à meta.
Na parte superior da tela são exibidas algumas informações da meta para auxiliar
no trabalho de escolher as métricas, essas informações são o nome e a perspectiva da
mesma. Ainda, na parte superior, existe um botão para a inserção de uma nova métrica.
Logo abaixo são exibidas duas listas, uma contendo as métricas existentes e outra com
as métricas associadas à meta.
Na lista de métricas existentes são exibidas as métricas ordenadas pelo sistema
de recomendação proposto na seção 3.1. A métrica recomendada é apresentada no
Figura 22: Tela de escolha de meta para associar às métricas
94
formato “Pontos – Nome”. Por outro lado, na listagem de métricas selecionadas, a
pontuação da métrica não é exibida.
Para associar ou desassociar métricas basta utilizar os botões entre as duas
listagens, sendo que o botão “»”, ao ser pressioado, associa todas as métricas
recomendadas à meta, o botão “►” associa apenas as métricas selecionadas à meta, o
botão “◄”, dessasocia da meta todas as méticas selecionadas na lista de métricas da
meta e, por fim, o botão “«”, desassocia da meta todas as métricas previamente
selecionadas.
Ainda, no canto inferior esquerdo da tela, existe o botão “Salvar”, que indica
para a aplicação que o usuário finalizou a escolha das metas e, após ser pressionado,
associa definitivamente as métricas à meta e incrementa de 1 a utilização das métricas
selecionadas.
Figura 23: Tela para associação de métricas à meta.
95
Por fim, no canto superior esquerdo existe o botão “Nova métrica”, que, ao ser
clicado abre uma tela para a inserção de uma nova métrica, tela essa que está
representada pela Figura 24.
Nessa tela, existem quatro informações que devem ser preenchidas: o nome, que
representa o nome dado a métrica; a descrição, que deve conter uma explicação do
objetivo da métrica; a periodicidade de avaliação da métrica; e a quantidade de períodos
entre as avaliações.
Ainda, existem dois botões, o “Cancelar” e o “Salvar”. O botão “Cancelar”
apenas fecha a tela e descarta as informações indicadas pelo usuário enquanto que o
botão “Salvar” armazena a nova métrica no banco de dados e fecha a tela. Em ambos os
casos a aplicação retorna para a tela de associação de métricas, sendo que no segundo
caso, a métrica criada já aparece na lista de métricas recomendadas.
Figura 24: Tela para criação de métricas.
96
A.IV.iii. Processo Indicação de Regras de Acompanhamento para as Metas
Nessa seção iremos descrever detalhadamente a implementação de todas as telas
do processo de associação de métricas à meta descrito na Figura 21.
Inicialmente o usuário deve acessar a tela de onde deve escolher a meta em que
deseja trabalhar, essa tela está representada na Figura 25. Nessa tela existe uma árvore
onde a raiz da mesma é o nome do planejamento estratégico da organização, no caso,
“GPE – ScrumHalf – Ano 2 SH”. Como filhas da raiz aparecem as pespectivas do BSC
e, dentro de cada perspectiva, são apresentadas as metas existentes. Dentro de cada meta
são listadas as regras de acompanhamento já indicadas à meta. Para escolher uma meta
basta clicar sobre o nome da mesma.
Após a escolha da meta é apresentada a tela para indicação de regras de
acompanhamento para a meta, essa tela é representada pela Figura 26. Essa é a principal
tela desse processo, pois é a tela que permite ao usuário definir o método de
acompanhamento do desempenho de cada meta do BSC.
Na parte superior da tela são exibidas algumas informações da meta para auxiliar
no trabalho de escolher as regras de acompanhamento, essas informações são o nome e
Figura 25: Tela para escolha de metas para indicar regras de acompanhamento.
97
a perspectiva da mesma. Ainda, na parte superior, existe um botão para a inserção de
uma nova regra. Logo abaixo são exibidas duas listas, uma contendo as regras existentes
e outra com as regras de acompanhamento associadas à meta.
Na listagem de regras existentes são apresentadas todas as regras que existem na
organização que possuem em sua expressão apenas métricas associadas à meta
escolhida. As regras são ordenadas de acordo com sistema de recomendação descrito
em 3.2 e, é apresentada à direita do botão para visualização da mesma no formato
“Pontos – Nome”.
Para associar ou desassociar regras basta utilizar os botões entre as duas
listagens, sendo que o botão “»”, ao ser pressioado, associa todas as regras
recomendadas à meta, o botão “►” associa apenas as regras selecionadas à meta, o
botão “◄”, dessasocia da meta todas as regras selecionadas na lista de regras da meta e,
por fim, o botão “«”, desassocia da meta todas as regras previamente selecionadas.
Ainda, a tela também permite a prioridade das regras seja alterada, i.e., é
possível indicar quais as regras mais prioritárias. Essa operação é realizada através dos
Figura 26: Tela para associação de regras de acompanhamento à meta.
98
botões que estão à direita da lista de regras selecionadas. O botão com “2 setas para
cima”, ao ser clicado, move todas as regras selecionadas para o topo da lista,
analogamente, o botão com “2 setas para baixo”, move todas as regras selecionadas para
o fim da lista, o botão com “1 seta para cima” move as regras selecionadas uma linha
para cima e, o botão com “1 seta para baixo” move as regras selecionadas uma linha
para baixo.
Ainda, no canto inferior esquerdo da tela, existe o botão “Salvar”, que indica
para a aplicação que o usuário finalizou a escolha das regras e, após ser pressionado,
associa definitivamente as regras de acompanhamento à meta e pontua as regras
utilizadas de acordo com o sistema de recomendação descrito em 3.2.
Por fim, no canto superior esquerdo existe o botão “Nova Regra”, que, ao ser
clicado abre uma tela para a inserção de uma nova regra de acompanhamento, tela essa
que está representada pela Figura 27.
Nessa tela existem seis campos à serem preenchidos, que serão descritos a
seguir. A primeira informação é o nome da regra, esse nome serve para identificar a
regra e seu preenchimento é obrigatório.
Em seguida, existe um campo para o usuário inserir uma descrição para a regra,
esse campo não possui preenchimento obrigatório e deve ser uma breve explicação da
utilidade da regra. O terceiro campo indica qual a dimensão autonômica a que a regra
pertence e seu preenchimento é obrigatório.
Após esses campos, vêm dois campos referentes a ação a ser executada caso a
regra fique inválida, o primeiro é o tipo da ação e, em seguida, vem o campo parâmetro,
que indica um parâmetro a ser passado para a ação. No caso da imagem, como a ação é
o envio de um email, o parâmetro é o endereço de email que deve receber a mensagem.
Os campos referentes a ação são obrigatórios.
99
Em seguida é apresentada a expressão que valida a regra. Essa expressão é
montada a partir do botão “Inserir Expressão” presente na parte inferior da tela. A
indicação de uma expressão é obrigatória para a inserção da regra.
Ainda, existe duas listagens, uma com as regras existentes e outra com as regras
selecionadas como regras base da nova regra. As regras existentes são apresentadas
ordenadas de acordo com o sistema de recomendação proposto em 3.2.
Para associar ou desassociar regras basta utilizar os botões entre as duas
listagens, sendo que o botão “»”, ao ser pressioado, marca todas as regras
recomendadas como regras base da nova regra, o botão “►” marca apenas as regras
selecionadas como regras base, o botão “◄”, desmarca da nova regra todas as regras
base e, por fim, o botão “«”, desmarca da nova regra as regras base selecionadas.
Figura 27: Tela de criação de regra de acompanhamento.
100
Por fim, existem três botões, o botão “Ok” que salva a regra, o “Cancelar” que
desfaz toda a operação e retorna para a tela de associação de regras à meta e o botão
“Nova Expressão” que, ao ser pressionado, abre uma tela para o usuário montar a
expressão da regra. Essa tela é representada pela Figura 28.
Essa tela possui um comportamento diferente dependendo do tipo de expressão
escolhido, a Figura 28 representa a escolha de uma nova Clásula, com o segundo
operador da mesma sendo um valor. As outras configurações da tela serão descitas
posteriormente.
Ao criar uma nova expressão, deve ser informada o tipo dela (clausula ou
expressão). No caso de clausula, existem três informações que precisam ser
preenchidas. O primeiro operando, que sempre é uma métrica, deve ser escolhido, são
listadas todas as métricas da meta selecionada no início do processo de associar regras
de acompnhamento à meta. Em seguida, deve ser selecionado o operador da clausula, e,
por fim, o segundo operador da clausula deve ser escolhido. O segundo operador pode
ser um valor ou uma métrica, na Figura 28 a tela apresentada possui um valor como o
Figura 28: Tela para criar nova expressão, com o 2º operando sendo um valor
101
segundo operando e, na Figura 29 é apresentada a tela com a métrica como o segundo
operando.
Se na tela de criar expressão o tipo escolhido for “Expressão”, o usuário deve
apenas escolher o operador lógico da expressão como pode ser visto na Figura 30. Se
alguma expressão já estiver definida para a regra, ao criar uma nova expressão
composta, ela fica como a parte da esquerda da expressão e a parte da direita fica com o
valor “Expressão 2”, que indica que a mesma ainda deve ser definida. Após confirmar a
tela, a expressão fica com o valor “((Valor arrecadado > Valor arrecadado Recurso
Extra) AND Expressao 2)”. Para definir essa expressão basta clicar sobre a mesma que
a tela de “Nova Expressão” é aberta.
Em ambos os casos, existem dois botões na parte inferior da tela, o botão “Ok”
que confirma a expressão e a associa a regra e o botão “Cancelar” que cancela as
alterações e retorna a tela de criação de regra.
Figura 29: Tela para criar nova expressão, com o 2º operando sendo uma métrica
102
Figura 30: Tela para criar nova expressão, sendo a expressão uma expressão composta