O Decision Maker é uma aplicação web desenvolvida através do IDE Eclipse Indigo, utilizando a linguagem de programação Java, estruturada em três camadas lógicas (Figura 4):
Apresentação: Contendo páginas e formulários WEB, construídos baseados nas tecno- logias JSF e Prime Faces;
Negócio: Promovendo o gerenciamento da lógica do negócio da aplicação, abrangendo as regras e a inteligência do negócio. Nesta camada, foi utilizado o framework jColibri (http://gaia.fdi.ucm.es/research/colibri/jcolibri), escolhido para criação de funcionalida- des relacionadas ao RBC, no intuito de atender a necessidade de identificação de pro- blemas similares
Persistência: Promovendo a integração entre a camada de negócio e o banco de dados, através da tecnologia JPA, que proporciona a execução de todas as operações necessá- rias para efetuar a comunicação com o banco MySQL 5.5.
Figura 4: Arquitetura do Decision Maker
Como servidor de aplicação, foi utilizado o TomCat 7, devido a sua confiabilidade, disponibilidade e facilidade de uso.
No intuito de organizar as funcionalidades disponibilizadas pela ferramenta, foram de- finidos quatro casos de uso (Figura 5):
Cadastrar Problema: permitindo que o decisor efetue a consulta, inclusão, alteração ou mesmo exclusão de um problema no sistema.
Cadastrar Solução: permitindo que o decisor efetue a consulta, inclusão, alteração, ex- clusão ou mesmo avaliação de alternativas de um problema.
Procurar Situações Similares: permitindo a sugestão ao decisor de um grupo de situa- ções semelhantes ao problema informado, auxiliando-o na escolha da melhor solução pra o problema.
Reutilizar Solução: permitindo ao decisor a utilização de uma solução atribuída à um problema anterior de forma completa ou mesmo adaptável.
Conforme tópicos descritos anteriormente, o caso, no que tange sistemas de RBC, é o registro de uma experiência passada, composto, de forma bruta, pela descrição do problema vivenciado e de sua solução. Dessa forma, a proposta desse trabalho é a agregação, à esse registro, das informações relacionadas as alternativas pensadas (juntamente com suas justifi- cativas, sejam elas de escolha ou descarte).
No contexto desta proposta, o caso pode ser representado através da identificação de sua categoria, assunto e complexidade além de seu nome, contextualização do projeto a que pertence e breve descrição do problema e de seu cenário.
Após o cadastro do problema, o sistema, através das funcionalidades construídas com o auxílio do jColibri, deve apresentar uma lista de casos considerados similares ao represen- tado. Para tal atividade, as funcionalidades de resolução de problemas são acionadas visando resgatar registros que atendam as seguintes perguntas: (i) quais problemas são similares ao registrado? (ii) qual o nível de similaridade de cada atributo?
Para auxiliar a identificação desses critérios, foram definidas funções para similarida- des (globais e locais), que proporcionaram a divisão de três níveis para a determinação do grau de similaridade de cada registro. Dessa forma, somente serão apresentados ao usuário do sistema aqueles casos considerados Muito semelhantes ou mesmo semelhantes, ordenados de forma crescente em relação a seu grau (Quadro 4).
Quadro 4: Grau de similaridade
Grau Similaridade
Muito semelhante 60% ≤ x < 100% Semelhante 40% ≤ x < 60% Pouco Semelhante 0% ≤ x < 40%
Diante das sugestões apresentadas, o usuário do sistema avalia se alguma delas soluci- ona o problema por ele apresentado. Em caso positivo, o decisor seleciona a escolhida para reutilizar na resolução do seu problema. Vale lembrar que uma solução reutilizada não precisa resolver totalmente um problema, pois esta pode servir apenas como base para a definição de uma nova. Assim, casos apresentados como semelhantes podem auxiliar o decisor na resolu- ção do seu problema apenas servindo como inspiração.
O decisor deve representar tantas quanto forem as alternativas consideradas como so- lução do seu problema, mesmo as não escolhidas, proporcionando futuramente uma visão mais detalhada daquela situação.
Após a escolha da solução, o decisor efetua a sua implementação. No entanto, assim como ocorre durante o teste de um software, a solução do problema pode sofrer inúmeros
ajustes até atingir seu formato correto. Nesta atividade, mais conhecida como revisão de pro- blema, o decisor altera informações de problema e alternativas conforme necessário.
O final deste processo de tomada de decisão se dá através da avaliação da solução. Pa- ra isso, o decisor, considerando o grau de satisfação que obteve com a resolução do problema, avalia o caso, atribuindo uma nota de 0 a 10. Essa avaliação também servirá para assinalar que o caso foi concluído e que pode ser disponibilizado como sugestão para novos problemas.
Visando auxiliar a implementação do Decision Maker um diagrama de classes foi es- pecificado (Figura 6).
Figura 6: Diagrama de classes
Os domínios Categoria (Quadro 5) e Complexidade (Quadro 6) e Tecnologias (Quadro 7) do Problema foram identificados baseados em conceitos consolidados, associados com a experiência profissional de alguns colaboradores atuantes na área de desenvolvimento de sof- tware.
Quadro 5: Domínio – Categoria do problema
Categoria Descrição
Programação Problemas relacionados à codificação. Arquitetura de Solução
Problemas relacionados à arquitetura, seja ela envolvendo a solução arquitetural escolhida para o projeto ou mesmo a adoção de padrões.
Realização Problemas relacionados à realização dos artefatos de análise do sistema, tais como diagramas de sequência, atividade ou classe.
Gestão Problemas de natureza gerenciais, podendo corresponder a posturas e estratégias relacionadas a equipe do projeto. Estratégia de Negócio Problemas envolvendo as ações que a organização realiza para alcançar posição que busca no mercado. Execução de Atividade Problemas relacionado ao uso efetivo de um recurso, seja ele documental ou mesmo físico.
Quadro 6: Domínio – Complexidade do problema
Complexidade Descrição
Baixa Problemas que não interferiam em custo e prazo do projeto. Média Problemas que interferiam em custo ou prazo do projeto. Alta Problemas que interferiam em custo e prazo do projeto
Quadro 7: Domínio – Tecnologia de projeto
Tecnologia BPM DotNet Glassfish Java Jdeveloper JSF MSProject MySQL Oracle PHP PrimeFaces RMC TomCat
Na implementação do mecanismo de raciocínio baseado em casos, o algoritmo de re- cuperação do vizinho mais próximo foi utilizado devido a percepção de confiança em uso dentre os trabalhos correlatos pesquisados.
Para o cálculo de similaridade local dos atributos, foram utilizadas as seguintes fun- ções, apresentadas na Tabela 10.
Tabela 10: Similaridade local dos atributos
Atributo Similaridade Peso
Categoria Equal() 0,5
Assunto Jaccard Coefficient() 0,5
Complexidade Equal() 0,5
Tecnologia Equal() 0,5
Antes da aplicação do estudo de caso, foram feitas várias simulações alterando de forma aleatória os pesos e funções no sentido de encontrar uma configuração que melhor identificasse a similaridade entre os casos. Após esse momento, foi realizado um pré-teste da funcionalidade de identificação de problemas similares com o auxílio de um grupo de especia- listas na área de desenvolvimento de software, que testaram essa funcionalidade fornecendo feedbacks dos casos retornados. A partir desses feedbacks e observando os exemplos utiliza- dos para as simulações foram realizados ajustes na configuração entre pesos e funções visan- do aumentar a precisão na identificação de problemas similares.
Dessa forma, ao final desse ciclo de testes, foram alteradas, para os atributos do pro- blema, algumas funções de similaridade e pesos, conforme apresentado na Tabela 11.
Tabela 11: Similaridade local dos atributos ajustada
Atributo Similaridade Peso
Categoria Equal() 0,5
Assunto OverlapCoefficient () 1,0
Complexidade Equal() 0,5
Tecnologia Equal() 0,5
Nome do Problema CosineCoefficient () 0,5
No entanto, esses pesos e funções ainda podem ser reajustados, visando aumentar a precisão dessa identificação.